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