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
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.
Add picture from clipboard (Maximum size: 48.8 MB)