Project

General

Profile

L1A L23 Interface » History » Version 4

laforge, 02/19/2016 10:48 PM
we use HDLC now.

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