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. |