Project

General

Profile

L1A L23 Interface » History » Version 3

laforge, 02/19/2016 10:48 PM
additional notes about rs232 implementation

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