Project

General

Profile

CSD » History » Revision 18

Revision 17 (osmith, 04/19/2023 11:19 AM) → Revision 18/22 (fixeria, 07/20/2023 06:47 PM)

{{include(MacroNotImplementedYet)}} 

 {{>toc}} 

 h1. Circuit Switched Data (CSD) 

 CSD is a way to transport user data over circuit-switched GSM calls.    It is the cellular equivalent of the use of analog modems or ISDN TA over wired telephony networks: You dial a number, the usual call control protocol for signaling creates a dedicated, circuit switched connection to the destination.    If they answer the call, a transparent communication channel is established between both sides. 

 GSM CSD (in its single-slot variants, excluding HSCSD) implements 

 |_.22.002 Bearer Service|_.22.003 Teleservice|_.43.010 model|_.Description| 
 |BS20T|?|2b|transparent synchronous data| 
 |BS30T|?|1b|transparent asynchronous data. first converted aysnc->sync, then treated like sync| 
 |BS20NT|?|3b|non-transparent asynchronous data. Uses RLP (ARQ) protocol for less errors, but creates variable delay.| 
 |?|TS62T|5a|transparent facsimile group 3| 

 h2. Bearer Services 

 |_.Bearer Service|_.Speed (bit/s)|_.sync/async|_.Mandatory in GSM-R| 
 |BS21|300|async|| 
 |BS22|1200|async|| 
 |BS23|1200/75|async|| 
 |BS24|2400|async|transparent| 
 |BS25|4800|async|transparent| 
 |BS26|9600|async|transparent| 
 |BS31|1200|sync|| 
 |BS32|2400|sync|| 
 |BS33|4800|sync|| 
 |BS34|9600|sync|| 

 h2. Facsimile / Telefax 

 CSD is also what is used to implement Facsimile (Telefax) services over GSM. 

 h2. Interworking 

 When CSD services (sync/async/fax) are used between two GSM subscribers, no interworking is required.    The data is passed transparently end-to-end. 

 However, when interworking with the wired network is required, an interworking function (IWF) is required. 

 h3. Interworking with ISDN data calls 

 This is the situation where a GSM mobile subscriber is establishing a CSD call to a native ISDN subscriber. 

 In this case, the [[retronetworking:V110|V.110]] signal is rate-adapted at the IWF to the 64kBps of the ISDN bearer chanel. 

 In the traditional GSM architecture, there are multiple rate adaptations happening in the path: 
 * from the Um interface to TRAU data frames on 16k sub-slots over the Abis interface 
 * from the TRAU data frames on 16k sub-slots to the standard V.110 on 64k B-channels on the A interface 

 In case of a modern, IP based GSM (like with [[OsmoBTS:]]), the entire rate adaptation would happen in the BTS, before it outputs V.110 frames on 64k RFC4040 CLEARMODE RTP. 

 To do so, the BTS must (in uplink) 
 * perform convolutional decoding, de-puncturing, de-interleaving, etc. 
 * perform the RA1' to RA1 rate adaptation function (modified V.110 frames to normal V.110 frames) 
 * perform the RA2 rate adaptation function (V.110 frames on 8k/16k/32k sub-slot to 64k) 
 * put the resulting data in RTP packets according    to RFC4040 

 h3. Interworking with analog modems in POTS or ISDN 

 In this case, the IWF terminates the V.110 from the GSM RAN and implements a modem towards the external POTS/ISDN subscriber.    V.110 is used in _synchronous_ mode for Fax, carrying 64bit frames defined in TS 43.045 Section 5.2.2.1. 

 h3. Interworking with analog Telefax in POTS or ISDN 

 This is similar to the analog modem situation above. 

 h2. Rate Adaptation functions 

 h3. RA0 

 * only used with asynchronous interfaces 
 * async data padded by stop elements to fit the nearest higher synchronous bit rate 

 

 h2. Radio channel types 

 |_.Name|_.radio interface rate (kbit/s)|_.service rate (kbit/s)|_.information bits|_.frame duration|_.coding/interleaving (see 3GPP TS 45.003)|_.service| duration|_.coding|_.interleaving|_.service| 
 |TCH/F9.6|12.0|9.6|60|5ms|section 3.3: rate 1/2 puncturing 32 bits; |TCH/F2.4|3.6|>= 2.4|36|10ms|2 blocks (72 bits); 4 tail bits (75 bits); rate1/6; 456 coded bits, interleaved like TCH/FS|TS 45.003 3.6|?| 
 |TCH/F4.8|6.0|4.8|60|10ms|rate 1/3; 456 coded bits, interleaved over 22 bursts|TS 45.003 3.4|TS 43.010 6.4.1| 
 |TCH/F4.8|6.0|4.8|60|10ms|section 3.4: rate 1/3; |TCH/F9.6|12.0|9.6|60|5ms|rate 1/2 puncturing 32 bits; 456 coded bits, interleaved over 22 bursts|TS 45.003 3.3|TS 43.010 6.4.1| 
 |TCH/H4.8|6.0|4.8|60|10ms|section 3.5: 4 blocks (240 bits) + 4 |TCH/F14.4|14.5|14.4|290|20ms|+4 tail bits = 294 bits; rate 1/2 1/2, puncturing 32 132 bits; 456 coded bits interleaved like TCH/FS|?| TCH/FS|TS 45.003 3.8|TS 43.010 6.4.2| 
 |TCH/F2.4|3.6|>= 2.4|36|10ms|section 3.6: 2 blocks (72 bits); 4 tail bits (75 bits); rate1/6; 456 coded bits, interleaved like TCH/FS|?| 
 |TCH/H2.4|3.6|<= 2.4|36|10ms|section 3.7: 2 2.4|36|10ms|2 blocks (72 bits + 4 tail bits each) = 152 bits; 456 coded bits, interleaved over 22 bursts|?| bursts|TS 45.003 3.7|?| 
 |TCH/F14.4|14.5|14.4|290|20ms|section 3.8: +4 |TCH/H4.8|6.0|4.8|60|10ms|4 blocks (240 bits) + 4 tail bits = 294 bits; rate 1/2, 1/2 puncturing 132 32 bits; 456 coded bits interleaved like TCH/FS|TS 43.010 6.4.2| 

 45.003 3.5|?| 

 h2. Representation in RTP 

 See 3GPP TS 48.103 section 5.4.2.2 "RTP payload" as well as Section 5.6. 

 It specifies CSData uses Clear mode pseudo-codec a per RFC4040, either 
 * without redundancy (redundancy level 1) / RTP PT 120 
 * with redundancy (redundancy level 2 or 3) / RTP PT 121 

 General comments: 
 * SDP uses "CLEARMODE/8000" 
 * 64kBps stream, i.e. 160 octets every 20ms 

 h2. Implementation Status 

 We currently don't implement these features yet, but we are aiming at implementing them in 2023.    For details, see "all Issues tagged with CSD":https://osmocom.org/issues?f%5B%5D=tags&f%5B%5D=status_id&fields%5B%5D=tags&fields%5B%5D=status_id&op%5Bstatus_id%5D=o&op%5Btags%5D=%3D&operators%5Bstatus_id%5D=o&operators%5Btags%5D=%3D&set_filter=1&v%5Bstatus_id%5D%5B%5D=&v%5Btags%5D%5B%5D=ASCI&values%5Bstatus_id%5D%5B%5D=&values%5Btags%5D%5B%5D=CSD 

 h2. Relevant specifications 

 |_.Number|_.Description| 
 |3GPP TS 22.002|CS Bearer Services| 
 |3GPP TS 22.003|CS Teleservices| 
 |3GPP TS 22.004| 
 |3GPP TS 27.002|L2RCOP (protocol beween async characters and RLP in non-transparent mode)| 
 |3GPP TS 43.010|Description of connection types. Note particularly Table 4 + section    6.4| 
 |3GPP TS 43.045|Fax G3| 
 |3GPP TS 44.021|Rate adaptation on MS-BSS interface; RA0; RA1/RA1' single-slot| 
 |3GPP TS 44.022|RLP protocol (for non-transparent async)| 
 |3GPP TS 27.001|TA functions in MS (incl. filtering of status bits)| 
 |3GPP TS 27.002|TA functions for async bearers (incl. data compression)| 
 |3GPP TS 27.003|TA functions for sync bearers| 
 |3GPP TS 48.020|Rate adaptation on BSS-MSC interface; RA1/RA1' multi-slot, RA1''| 
 |3GPP TS 48.060|TRAU frame format for classic E1 BTS (Section 5.3, 5.5.3, 6.7)| 
 |3GPP TS 29.007|Interworking between PLMN and ISDN| 
 |IETF RFC4040|RTP payload format for    64kbps transparent call| 
 |ITU-T V.110|Rate adaptation|
Add picture from clipboard (Maximum size: 48.8 MB)