Project

General

Profile

L1A L23 Interface » History » Revision 6

Revision 5 (zecke, 02/19/2016 10:48 PM) → Revision 6/9 (zecke, 02/19/2016 10:49 PM)

{{>toc}} 

 h1. [[PageOutline]] 
 = Minimalistic L1 interface 


 = 

 This is the description of the minimal interface between L1 and higher layers (L23) 
 neccessary to establish a dedicated channel with the cell and perform procedures like 
 LOCATION UPDATE or AUTHENTICAITON. 


 h2. 

 == Message Types 



 h3. == 

 === SYNC_NEW_CCCH_REQ 


 === 

 Triggers the following actions in L1: 
 
  * switch to new ARFCN 
 
  * perform AGC + AFC 
 
  * synchronize to FCCH 
 
  * decode SCH and determine frame number 


 h4. 

 ==== parameters 

 ==== 
  * ARFCN + BAND 


 h4. 

 ==== response 

 ==== 
  * SYNC_NEW_CCCH_RESP 



 h3. 


 === SYNC_NEW_CCCH_RESP 

 === 
 Sent from the L1 to the L23 after it has synchronized to a new cell (FCCH and SCH acquisition) 


 h4. 

 ==== parameters 

 ==== 
  * struct l1_info_dl 
 ** 
   * ARFCN + BAND 
 ** 
   * GSM frame number (t1/t2/t3) 
 ** 
   * Rx Level 
 ** 
   * SNR 
 
  * BSIC 



 h3. 


 === CCCH_INFO_IND 


 === 

 Sent by the L1 to the L23 whenever it has successfully decoded four consecutive bursts on 
 the CCCH. 

 It is up to the L23 to decide whether the burst belongs to BCCH, AGCH, PCH or SDCCH/4. 


 h4. 

 ==== parameters 

 ==== 
  * ARFCN + BAND 
 
  * GSM frame number 
 
  * Rx Level 
 
  * SNR 
 
  * 23 bytes L1 payload 



 h3. 


 === RACH_REQ 


 === 

 Sent from the L23 to the L1 to instruct the L1 to send a RACH request to the current cell. 


 h4. 

 ==== parameters 

 ==== 
  * struct l1_info_ul 
 ** 
   * Tx power 
 ** 
   * TDMA frame number 
 ** 
   * channel type 
 ** 
   * channel number (timeslot, subslot) 
 
  * 8 bit RA Reference 



 h4. 


 ==== response 

 ==== 
 No response by L1. 

 The response by the serving cell will be an IMMEDIATE ASSIGNMENT in the AGCH on 
 the CCCH downlink. 



 h3. 


 === DEDIC_MODE_EST_REQ 


 === 

 Sent from the L23 to the L1 to instruct switching from CCCH mode to a dedicated 
 channel. 

 Initially we only implement SDCCH/4 and SDCCH/8 on a non-hopping cell. 


 h4. 

 ==== parameters 

 ==== 
  * struct l1_info_ul 
 
  * (arfcn|hsn,maio) 



 h3. 


 === DEDIC_MODE_DATA_IND 


 === 

 Sent by the L1 to the L23 to convey the successful reception of four 
 consecutive bursts on the dedicated channel. 

 It is up to the L23 to do the time demultiplex of multiple SDCCHs in the same 
 on-air timeslot. 


 h4. 

 ==== parameters 

 ==== 
  * struct l1_info_dl 
 
  * 23 bytes L1 payload 



 h3. 


 === DEDIC_MODE_DATA_REQ 

 === 
 Sent by the L23 to the L1 to send payload data on a dedicated channel such as 
 SDCCH. 


 h4. 

 ==== parameters 

 ==== 
  * struct l1_info_ul 
 
  * 23 byte L1 payload 


 h3. 

 === LAYER1_RESET 

 === 
 Sent on (re)start of the Layer1. It indicates that all previous state was lost... 


 h4. 

 ==== parameters 

 ** ==== 
   * struct l1_info_dl 
 ** 
   * Only the msg_type has valid data. 


 h2. 

 == Implementation over RS232 


 == 

 When we transport the messages of this interface over RS232, we have to consider  
  
  * multiplexing of L1A<->L23 messages with console/debug messages 
 
  * bandwidth management 


 h3. 

 === Multiplexing with console messages 


 === 

 Instead of a protocol with a fixed header (including length of payload), we chose a minimalistic 
 subset of HDLC.    This has the advantage that it provides multiplexing between up to 255 different 
 channels, and it is auto-synchronzing, i.e. when data is lost, the next frame start will still be 
 recognized by the other siede. 

 The minimal subset of HLDC consists of UI frames only, with no CRC. 


 h3. 

 === Bandwidth management 


 === 

 The UART in the Calypso DBB can only run up to 115200bps with standards-compliant baud rates. 
 Higher baud rates are possible (up to 812500bps), but only as non-standard rates.    While there 
 are serial chips like FTDI's chip that can support this, regular serial ports and popular 
 PL2303 based cables don't support it. 

 Therfore, we have to assume that the RS232 link runs at 115200bps. 
 
  * 115200bps means roughly 11,520 characters per second 
 
  * at a TDMA frame interval of 4.615ms, this means 53 characters per TDMA frame 
 
  * however, since four TDMA frames are merged into one L1 payload, we have about 212 
    bytes of RS232 bandwidth for each L1 payload that we receive (260 bits == 32.5 bytes) 

 This means that regular L1A operation on a single dedicated timeslot is very well possible 
 even with lots of overhead for protocol layers, anciliary data as well as a bit of debug 
 output. 

 But it also means that we can not print much debug info from L1 during every TDMA irq. 

 Also, actual L1A messaging should have a higher priority than serial console messages. 
 It would be great to have a strict priority between those two in the serial driver layer 
 of the phone software.
Add picture from clipboard (Maximum size: 48.8 MB)