L1A L23 Interface » History » Version 7
fixeria, 01/21/2019 04:07 AM
1 | 1 | laforge | h1. Minimalistic L1 interface |
---|---|---|---|
2 | 6 | zecke | |
3 | 7 | fixeria | {{>toc}} |
4 | 1 | laforge | |
5 | 7 | fixeria | This is the description of the minimal interface between L1 and higher layers (L23) necessary to establish a dedicated channel with the cell and perform procedures like |
6 | 1 | laforge | LOCATION UPDATE or AUTHENTICAITON. |
7 | |||
8 | 6 | zecke | h2. Message Types |
9 | |||
10 | h3. SYNC_NEW_CCCH_REQ |
||
11 | |||
12 | 1 | laforge | Triggers the following actions in L1: |
13 | 6 | zecke | * switch to new ARFCN |
14 | * perform AGC + AFC |
||
15 | * synchronize to FCCH |
||
16 | * decode SCH and determine frame number |
||
17 | 1 | laforge | |
18 | |||
19 | 6 | zecke | h4. parameters |
20 | 1 | laforge | |
21 | 6 | zecke | * ARFCN + BAND |
22 | 1 | laforge | |
23 | 6 | zecke | |
24 | h4. response |
||
25 | |||
26 | * SYNC_NEW_CCCH_RESP |
||
27 | |||
28 | |||
29 | |||
30 | h3. SYNC_NEW_CCCH_RESP |
||
31 | |||
32 | 1 | laforge | Sent from the L1 to the L23 after it has synchronized to a new cell (FCCH and SCH acquisition) |
33 | |||
34 | |||
35 | 6 | zecke | h4. parameters |
36 | 1 | laforge | |
37 | 6 | zecke | * struct l1_info_dl |
38 | ** ARFCN + BAND |
||
39 | ** GSM frame number (t1/t2/t3) |
||
40 | ** Rx Level |
||
41 | ** SNR |
||
42 | * BSIC |
||
43 | 1 | laforge | |
44 | 6 | zecke | |
45 | |||
46 | h3. CCCH_INFO_IND |
||
47 | |||
48 | |||
49 | 1 | laforge | Sent by the L1 to the L23 whenever it has successfully decoded four consecutive bursts on |
50 | the CCCH. |
||
51 | |||
52 | It is up to the L23 to decide whether the burst belongs to BCCH, AGCH, PCH or SDCCH/4. |
||
53 | |||
54 | |||
55 | 6 | zecke | h4. parameters |
56 | 1 | laforge | |
57 | 6 | zecke | * ARFCN + BAND |
58 | * GSM frame number |
||
59 | * Rx Level |
||
60 | * SNR |
||
61 | * 23 bytes L1 payload |
||
62 | 1 | laforge | |
63 | 6 | zecke | |
64 | |||
65 | h3. RACH_REQ |
||
66 | |||
67 | |||
68 | 1 | laforge | Sent from the L23 to the L1 to instruct the L1 to send a RACH request to the current cell. |
69 | |||
70 | |||
71 | 6 | zecke | h4. parameters |
72 | 1 | laforge | |
73 | 6 | zecke | * struct l1_info_ul |
74 | ** Tx power |
||
75 | ** TDMA frame number |
||
76 | ** channel type |
||
77 | ** channel number (timeslot, subslot) |
||
78 | * 8 bit RA Reference |
||
79 | |||
80 | |||
81 | |||
82 | h4. response |
||
83 | |||
84 | 1 | laforge | No response by L1. |
85 | |||
86 | The response by the serving cell will be an IMMEDIATE ASSIGNMENT in the AGCH on |
||
87 | the CCCH downlink. |
||
88 | |||
89 | |||
90 | |||
91 | 6 | zecke | h3. DEDIC_MODE_EST_REQ |
92 | |||
93 | |||
94 | 1 | laforge | Sent from the L23 to the L1 to instruct switching from CCCH mode to a dedicated |
95 | channel. |
||
96 | |||
97 | Initially we only implement SDCCH/4 and SDCCH/8 on a non-hopping cell. |
||
98 | |||
99 | |||
100 | 6 | zecke | h4. parameters |
101 | 1 | laforge | |
102 | 6 | zecke | * struct l1_info_ul |
103 | * (arfcn|hsn,maio) |
||
104 | 1 | laforge | |
105 | 6 | zecke | |
106 | |||
107 | h3. DEDIC_MODE_DATA_IND |
||
108 | |||
109 | |||
110 | 1 | laforge | Sent by the L1 to the L23 to convey the successful reception of four |
111 | consecutive bursts on the dedicated channel. |
||
112 | |||
113 | It is up to the L23 to do the time demultiplex of multiple SDCCHs in the same |
||
114 | on-air timeslot. |
||
115 | |||
116 | |||
117 | 6 | zecke | h4. parameters |
118 | 1 | laforge | |
119 | 6 | zecke | * struct l1_info_dl |
120 | * 23 bytes L1 payload |
||
121 | |||
122 | |||
123 | |||
124 | h3. DEDIC_MODE_DATA_REQ |
||
125 | |||
126 | 1 | laforge | Sent by the L23 to the L1 to send payload data on a dedicated channel such as |
127 | SDCCH. |
||
128 | |||
129 | 2 | spaar | |
130 | 6 | zecke | h4. parameters |
131 | |||
132 | * struct l1_info_ul |
||
133 | * 23 byte L1 payload |
||
134 | |||
135 | |||
136 | h3. LAYER1_RESET |
||
137 | |||
138 | 3 | laforge | Sent on (re)start of the Layer1. It indicates that all previous state was lost... |
139 | |||
140 | |||
141 | 6 | zecke | h4. parameters |
142 | 3 | laforge | |
143 | 6 | zecke | ** struct l1_info_dl |
144 | ** Only the msg_type has valid data. |
||
145 | |||
146 | |||
147 | h2. Implementation over RS232 |
||
148 | |||
149 | |||
150 | 4 | laforge | When we transport the messages of this interface over RS232, we have to consider |
151 | 6 | zecke | * multiplexing of L1A<->L23 messages with console/debug messages |
152 | * bandwidth management |
||
153 | 3 | laforge | |
154 | |||
155 | 6 | zecke | h3. Multiplexing with console messages |
156 | |||
157 | |||
158 | 3 | laforge | Instead of a protocol with a fixed header (including length of payload), we chose a minimalistic |
159 | subset of HDLC. This has the advantage that it provides multiplexing between up to 255 different |
||
160 | channels, and it is auto-synchronzing, i.e. when data is lost, the next frame start will still be |
||
161 | recognized by the other siede. |
||
162 | |||
163 | The minimal subset of HLDC consists of UI frames only, with no CRC. |
||
164 | |||
165 | |||
166 | 6 | zecke | h3. Bandwidth management |
167 | |||
168 | |||
169 | 3 | laforge | The UART in the Calypso DBB can only run up to 115200bps with standards-compliant baud rates. |
170 | Higher baud rates are possible (up to 812500bps), but only as non-standard rates. While there |
||
171 | are serial chips like FTDI's chip that can support this, regular serial ports and popular |
||
172 | PL2303 based cables don't support it. |
||
173 | |||
174 | Therfore, we have to assume that the RS232 link runs at 115200bps. |
||
175 | 6 | zecke | * 115200bps means roughly 11,520 characters per second |
176 | * at a TDMA frame interval of 4.615ms, this means 53 characters per TDMA frame |
||
177 | * however, since four TDMA frames are merged into one L1 payload, we have about 212 |
||
178 | 1 | laforge | bytes of RS232 bandwidth for each L1 payload that we receive (260 bits == 32.5 bytes) |
179 | |||
180 | This means that regular L1A operation on a single dedicated timeslot is very well possible |
||
181 | even with lots of overhead for protocol layers, anciliary data as well as a bit of debug |
||
182 | output. |
||
183 | |||
184 | But it also means that we can not print much debug info from L1 during every TDMA irq. |
||
185 | |||
186 | Also, actual L1A messaging should have a higher priority than serial console messages. |
||
187 | It would be great to have a strict priority between those two in the serial driver layer |
||
188 | of the phone software. |