Project

General

Profile

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