view doc/ARFCN-mapping @ 963:b515a97e5dff

sms-pdu-decode family: fix VP-Relative header spacing When VP-Relative is small enough to be reckoned in 5 min or 30 min units, it was printed incorrectly, with a cosmetic defect of one extra space. Fix this bug.
author Mychaela Falconia <falcon@freecalypso.org>
date Mon, 28 Aug 2023 03:52:53 +0000
parents e1c8c5bcb233
children
line wrap: on
line source

Frequency bands and band-pairs
==============================

TI's TCS211 L1 (meaning Layer1 component of TI's TCS211 reference fw and of all
FreeCalypso firmwares that are based on TCS211) can operate either in a single
frequency band or in a pair of bands (one low band and one high band)
corresponding to a regional standard.  TI's G23M protocol stack (specifically
its ALR component) commands L1 to operate in a given "standard" (single band or
pair of bands) by way of MPHC_INIT_L1_REQ primitive, which appears in L1 debug
trace output (seen via rvtdump or rvinterf) as a BAND_R trace.  The "standard"
number that appears in this BAND_R trace is one of the following 8
possibilities:

STD 1 (GSM)

	This STD tells L1 to operate only in the GSM900 band by itself (not
	paired with DCS1800), and furthermore to use the old definition of this
	GSM900 band with only 124 channels.  TI's code supports this option in
	order to support old RF hardware that was made for this old definition
	of the GSM900 band, but none of the phones, modems or development boards
	we work with in FreeCalypso are this old - thus this STD 1 should never
	get activated unless something is misconfigured somewhere.

STD 2 (GSM_E)

	This STD tells L1 to operate in the EGSM band, i.e., the new extended
	definition of the 900 MHz band with 174 channels total - but it still
	specifies only the EGSM band by itself, not paired with DCS1800.  We
	don't have any FC hardware targets that support the 900 MHz band but
	don't support DCS1800, thus this STD can only get selected if the DCS
	band is artificially disabled - and we do not currently know of any use
	case for disabling DCS while keeping EGSM enabled - thus this STD should
	not be seen in practice either.

STD 3 (PCS1900)

	This STD tells L1 to operate in the PCS band by itself.  This STD
	selection occurs in regular operation on devices like the Pirelli DP-L10
	and the tri900 version of our FCDEV3B: on such tri900 platforms the G23M
	protocol stack switches L1 back and forth between STD 6 (900+1800 MHz
	band pair, see below) and STD 3 for PCS.  Because tri900 platforms have
	no support for the GSM850 band, the PCS1900 band gets selected as a
	singleton (not a band pair) when the device operates on the "US" side
	of its multi-region frequency band support.

STD 4 (DCS1800)

	This STD tells L1 to operate in the DCS band by itself, not paired with
	900 MHz GSM or EGSM.  Triband devices built in the tri850 configuration
	(GTA02-850 and FCDEV3B-850) will select this STD when looking for
	possible DCS1800 cells - however, our expected user pattern is such that
	a user living or operating in EU-band lands (EGSM and/or DCS bands)
	would not be using a tri850 device, much in contrast with the reverse
	situation where tri900 devices are commonly used in the PCS1900 band.

STD 5 (DUAL)

	This STD selects a band pair consisting of the old 124-channel
	definition of the GSM900 band plus the DCS1800 band.  Because all hw
	platforms targeted by FreeCalypso support the 900 MHz band in its new
	EGSM definition if they support it at all, this STD 5 should never get
	activated unless something is misconfigured somewhere.

STD 6 (DUALEXT)

	This STD selects the classic "EU" band pair of EGSM + DCS1800.  This STD
	selection will occur in normal operation on EU dual-band devices like
	the EU versions of Motorola C1xx and Huawei GTM900-B, as well as tri900
	and quadband devices operating on the "EU" side of their multi-region
	frequency band support.

STD 7 (GSM850)

	This STD tells L1 to operate in the GSM850 band by itself.  We don't
	have any FC hardware targets that support the 850 MHz band but don't
	support PCS1900, thus this STD can only get selected if the PCS band is
	artificially disabled.

STD 8 (DUAL_US)

	This STD selects the full "US" band pair of GSM850 + PCS1900.  This STD
	selection will occur in normal operation on US dual-band devices like
	the US versions of Motorola C1xx and Huawei GTM900-P, as well as tri850
	and quadband (but not tri900!) devices operating on the "US" side of
	their multi-region frequency band support.  Note that tri900 devices
	will go into STD 3 (PCS1900 band by itself) instead!

ARFCN munging
=============

When L1 operates in one of single-band standards 1 (GSM), 3 (PCS1900), 4
(DCS1800) or 7 (GSM850), its internal radio_freq numbers that appear in L1 debug
traces are exactly equal to standard ARFCNs for that band as defined by ETSI.
However, when it operates in STD 2 (EGSM by itself) or in any of the dual-band
standards, it uses its own radio_freq numbers which are different from standard
ARFCNs.  Non-standard internal radio_freq numbers are used in these cases
because L1 needs a continuous number range for indexing arrays, and the mappings
are given below.  STD 6 (DUALEXT) and STD 2 (GSM_E) use the following mapping:

Band	Standard ARFCN	TCS211 L1 radio_freq
--------------------------------------------
EGSM	1-124		1-124
EGSM	975-1023	125-173
EGSM	0		174
DCS	512-885		175-548

The internal radio_freq number for the DUALEXT band pair ranges continuously
from 1 to 548.  STD 2 (EGSM by itself) uses the same mapping without the DCS
subrange, with radio_freq ranging continously from 1 to 174.  DUAL_US band pair
(STD 8) uses a continuous radio_freq range from 1 to 423 as follows:

Band	Standard ARFCN	TCS211 L1 radio_freq
--------------------------------------------
GSM850	128-251		1-124
PCS	512-810		125-423

Because these internal radio_freq numbers appear in L1 debug traces, power users
who like to understand these traces and see what their phone is doing need to
be able to work with these numbers.  I (Mother Mychaela) currently use a Pirelli
DP-L10 running its original proprietary fw as my everyday phone, for lack of
anything better, and because it is a tri900 device, it operates in STD 3 for
PCS1900 band by itself.  In this configuration all radio_freq numbers that
appear in the debug trace output are native PCS band ARFCNs without any munging,
thus no conversion tools are needed.  However, I am now starting to work more
with quadband Tango modules and development boards (iWOW DSK and FC Caramel2),
and we also have a few FCDEV3B-850 boards; these platforms support both GSM850
and PCS1900 bands and thus go into STD 8 for DUAL_US, and this dual-band STD
involves ARFCN munging as detailed above.  Furthermore, anyone who lives or
operates in EU-band lands would normally be operating in dual-band STD 6
(DUALEXT), and that one also involves ARFCN munging.

Because there is a need to translate back and forth between standard ARFCNs and
L1 radio_freq numbers, a pair of utilities has been written for this purpose:
arfcn2ti and ti2arfcn.  Their usage and operation is straightforward; each
utility takes two command line arguments: a keyword of "eu" or "us" selecting
the band pair being mapped, and the number to be converted.  The output of the
conversion (the other number) is printed on stdout.