FreeCalypso > hg > freecalypso-tools

comparison doc/ARFCN-mapping @ 760:e1c8c5bcb233

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
ARFCN conversion tools documented
author Mychaela Falconia <falcon@freecalypso.org>
date Sat, 28 Nov 2020 00:32:41 +0000
parents
children
comparison
equal deleted inserted replaced
759:d2fccd82a83e 760:e1c8c5bcb233
1 Frequency bands and band-pairs
2 ==============================
3
4 TI's TCS211 L1 (meaning Layer1 component of TI's TCS211 reference fw and of all
5 FreeCalypso firmwares that are based on TCS211) can operate either in a single
6 frequency band or in a pair of bands (one low band and one high band)
7 corresponding to a regional standard. TI's G23M protocol stack (specifically
8 its ALR component) commands L1 to operate in a given "standard" (single band or
9 pair of bands) by way of MPHC_INIT_L1_REQ primitive, which appears in L1 debug
10 trace output (seen via rvtdump or rvinterf) as a BAND_R trace. The "standard"
11 number that appears in this BAND_R trace is one of the following 8
12 possibilities:
13
14 STD 1 (GSM)
15
16 This STD tells L1 to operate only in the GSM900 band by itself (not
17 paired with DCS1800), and furthermore to use the old definition of this
18 GSM900 band with only 124 channels. TI's code supports this option in
19 order to support old RF hardware that was made for this old definition
20 of the GSM900 band, but none of the phones, modems or development boards
21 we work with in FreeCalypso are this old - thus this STD 1 should never
22 get activated unless something is misconfigured somewhere.
23
24 STD 2 (GSM_E)
25
26 This STD tells L1 to operate in the EGSM band, i.e., the new extended
27 definition of the 900 MHz band with 174 channels total - but it still
28 specifies only the EGSM band by itself, not paired with DCS1800. We
29 don't have any FC hardware targets that support the 900 MHz band but
30 don't support DCS1800, thus this STD can only get selected if the DCS
31 band is artificially disabled - and we do not currently know of any use
32 case for disabling DCS while keeping EGSM enabled - thus this STD should
33 not be seen in practice either.
34
35 STD 3 (PCS1900)
36
37 This STD tells L1 to operate in the PCS band by itself. This STD
38 selection occurs in regular operation on devices like the Pirelli DP-L10
39 and the tri900 version of our FCDEV3B: on such tri900 platforms the G23M
40 protocol stack switches L1 back and forth between STD 6 (900+1800 MHz
41 band pair, see below) and STD 3 for PCS. Because tri900 platforms have
42 no support for the GSM850 band, the PCS1900 band gets selected as a
43 singleton (not a band pair) when the device operates on the "US" side
44 of its multi-region frequency band support.
45
46 STD 4 (DCS1800)
47
48 This STD tells L1 to operate in the DCS band by itself, not paired with
49 900 MHz GSM or EGSM. Triband devices built in the tri850 configuration
50 (GTA02-850 and FCDEV3B-850) will select this STD when looking for
51 possible DCS1800 cells - however, our expected user pattern is such that
52 a user living or operating in EU-band lands (EGSM and/or DCS bands)
53 would not be using a tri850 device, much in contrast with the reverse
54 situation where tri900 devices are commonly used in the PCS1900 band.
55
56 STD 5 (DUAL)
57
58 This STD selects a band pair consisting of the old 124-channel
59 definition of the GSM900 band plus the DCS1800 band. Because all hw
60 platforms targeted by FreeCalypso support the 900 MHz band in its new
61 EGSM definition if they support it at all, this STD 5 should never get
62 activated unless something is misconfigured somewhere.
63
64 STD 6 (DUALEXT)
65
66 This STD selects the classic "EU" band pair of EGSM + DCS1800. This STD
67 selection will occur in normal operation on EU dual-band devices like
68 the EU versions of Motorola C1xx and Huawei GTM900-B, as well as tri900
69 and quadband devices operating on the "EU" side of their multi-region
70 frequency band support.
71
72 STD 7 (GSM850)
73
74 This STD tells L1 to operate in the GSM850 band by itself. We don't
75 have any FC hardware targets that support the 850 MHz band but don't
76 support PCS1900, thus this STD can only get selected if the PCS band is
77 artificially disabled.
78
79 STD 8 (DUAL_US)
80
81 This STD selects the full "US" band pair of GSM850 + PCS1900. This STD
82 selection will occur in normal operation on US dual-band devices like
83 the US versions of Motorola C1xx and Huawei GTM900-P, as well as tri850
84 and quadband (but not tri900!) devices operating on the "US" side of
85 their multi-region frequency band support. Note that tri900 devices
86 will go into STD 3 (PCS1900 band by itself) instead!
87
88 ARFCN munging
89 =============
90
91 When L1 operates in one of single-band standards 1 (GSM), 3 (PCS1900), 4
92 (DCS1800) or 7 (GSM850), its internal radio_freq numbers that appear in L1 debug
93 traces are exactly equal to standard ARFCNs for that band as defined by ETSI.
94 However, when it operates in STD 2 (EGSM by itself) or in any of the dual-band
95 standards, it uses its own radio_freq numbers which are different from standard
96 ARFCNs. Non-standard internal radio_freq numbers are used in these cases
97 because L1 needs a continuous number range for indexing arrays, and the mappings
98 are given below. STD 6 (DUALEXT) and STD 2 (GSM_E) use the following mapping:
99
100 Band Standard ARFCN TCS211 L1 radio_freq
101 --------------------------------------------
102 EGSM 1-124 1-124
103 EGSM 975-1023 125-173
104 EGSM 0 174
105 DCS 512-885 175-548
106
107 The internal radio_freq number for the DUALEXT band pair ranges continuously
108 from 1 to 548. STD 2 (EGSM by itself) uses the same mapping without the DCS
109 subrange, with radio_freq ranging continously from 1 to 174. DUAL_US band pair
110 (STD 8) uses a continuous radio_freq range from 1 to 423 as follows:
111
112 Band Standard ARFCN TCS211 L1 radio_freq
113 --------------------------------------------
114 GSM850 128-251 1-124
115 PCS 512-810 125-423
116
117 Because these internal radio_freq numbers appear in L1 debug traces, power users
118 who like to understand these traces and see what their phone is doing need to
119 be able to work with these numbers. I (Mother Mychaela) currently use a Pirelli
120 DP-L10 running its original proprietary fw as my everyday phone, for lack of
121 anything better, and because it is a tri900 device, it operates in STD 3 for
122 PCS1900 band by itself. In this configuration all radio_freq numbers that
123 appear in the debug trace output are native PCS band ARFCNs without any munging,
124 thus no conversion tools are needed. However, I am now starting to work more
125 with quadband Tango modules and development boards (iWOW DSK and FC Caramel2),
126 and we also have a few FCDEV3B-850 boards; these platforms support both GSM850
127 and PCS1900 bands and thus go into STD 8 for DUAL_US, and this dual-band STD
128 involves ARFCN munging as detailed above. Furthermore, anyone who lives or
129 operates in EU-band lands would normally be operating in dual-band STD 6
130 (DUALEXT), and that one also involves ARFCN munging.
131
132 Because there is a need to translate back and forth between standard ARFCNs and
133 L1 radio_freq numbers, a pair of utilities has been written for this purpose:
134 arfcn2ti and ti2arfcn. Their usage and operation is straightforward; each
135 utility takes two command line arguments: a keyword of "eu" or "us" selecting
136 the band pair being mapped, and the number to be converted. The output of the
137 conversion (the other number) is printed on stdout.