CSD » History » Version 15
laforge, 02/27/2023 10:06 PM
1 | 1 | laforge | {{include(MacroNotImplementedYet)}} |
---|---|---|---|
2 | 10 | laforge | |
3 | {{>toc}} |
||
4 | 1 | laforge | |
5 | h1. Circuit Switched Data (CSD) |
||
6 | |||
7 | 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. |
||
8 | |||
9 | 3 | laforge | GSM CSD (in its single-slot variants, excluding HSCSD) implements |
10 | 1 | laforge | |
11 | 3 | laforge | |_.22.002 Bearer Service|_.22.003 Teleservice|_.43.010 model|_.Description| |
12 | |BS20T|?|2b|transparent synchronous data| |
||
13 | |BS30T|?|1b|transparent asynchronous data. first converted aysnc->sync, then treated like sync| |
||
14 | 14 | osmith | |BS20NT|?|3b|non-transparent asynchronous data. Uses RLP (ARQ) protocol for less errors, but creates variable delay.| |
15 | 3 | laforge | |?|TS62T|5a|transparent facsimile group 3| |
16 | |||
17 | 6 | laforge | h2. Bearer Services |
18 | 1 | laforge | |
19 | 9 | laforge | |_.Bearer Service|_.Speed (bit/s)|_.sync/async|_.Mandatory in GSM-R| |
20 | |BS21|300|async|| |
||
21 | |BS22|1200|async|| |
||
22 | |BS23|1200/75|async|| |
||
23 | |BS24|2400|async|transparent| |
||
24 | |BS25|4800|async|transparent| |
||
25 | |BS26|9600|async|transparent| |
||
26 | |BS31|1200|sync|| |
||
27 | |BS32|2400|sync|| |
||
28 | |BS33|4800|sync|| |
||
29 | |BS34|9600|sync|| |
||
30 | 6 | laforge | |
31 | 1 | laforge | h2. Facsimile / Telefax |
32 | |||
33 | CSD is also what is used to implement Facsimile (Telefax) services over GSM. |
||
34 | |||
35 | h2. Interworking |
||
36 | |||
37 | When CSD services (sync/async/fax) are used between two GSM subscribers, no interworking is required. The data is passed transparently end-to-end. |
||
38 | |||
39 | However, when interworking with the wired network is required, an interworking function (IWF) is required. |
||
40 | |||
41 | h3. Interworking with ISDN data calls |
||
42 | |||
43 | This is the situation where a GSM mobile subscriber is establishing a CSD call to a native ISDN subscriber. |
||
44 | |||
45 | 4 | laforge | In this case, the [[retronetworking:V110|V.110]] signal is rate-adapted at the IWF to the 64kBps of the ISDN bearer chanel. |
46 | 1 | laforge | |
47 | 13 | laforge | In the traditional GSM architecture, there are multiple rate adaptations happening in the path: |
48 | * from the Um interface to TRAU data frames on 16k sub-slots over the Abis interface |
||
49 | * from the TRAU data frames on 16k sub-slots to the standard V.110 on 64k B-channels on the A interface |
||
50 | |||
51 | 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. |
||
52 | |||
53 | To do so, the BTS must (in uplink) |
||
54 | * perform convolutional decoding, de-puncturing, de-interleaving, etc. |
||
55 | * perform the RA1' to RA1 rate adaptation function (modified V.110 frames to normal V.110 frames) |
||
56 | * perform the RA2 rate adaptation function (V.110 frames on 8k/16k/32k sub-slot to 64k) |
||
57 | * put the resulting data in RTP packets according to RFC4040 |
||
58 | |||
59 | 1 | laforge | h3. Interworking with analog modems in POTS or ISDN |
60 | |||
61 | In this case, the IWF terminates the V.110 from the GSM RAN and implements a modem towards the external POTS/ISDN subscriber. |
||
62 | |||
63 | h3. Interworking with analog Telefax in POTS or ISDN |
||
64 | |||
65 | 2 | laforge | This is similar to the analog modem situation above. |
66 | |||
67 | 6 | laforge | h2. Rate Adaptation functions |
68 | |||
69 | h3. RA0 |
||
70 | |||
71 | * only used with asynchronous interfaces |
||
72 | * async data padded by stop elements to fit the nearest higher synchronous bit rate |
||
73 | |||
74 | h2. Radio channel types |
||
75 | |||
76 | 7 | laforge | |_.Name|_.radio interface rate (kbit/s)|_.service rate (kbit/s)|_.information bits|_.frame duration|_.coding|_.interleaving|_.service| |
77 | |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|?| |
||
78 | |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| |
||
79 | |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| |
||
80 | |TCH/F14.4|14.5|14.4|290|20ms|+4 tail bits = 294 bits; rate 1/2, puncturing 132 bits; 456 coded bits interleaved like TCH/FS|TS 45.003 3.8|TS 43.010 6.4.2| |
||
81 | |TCH/H2.4|3.6|<= 2.4|36|10ms|2 blocks (72 bits + 4 tail bits each) = 152 bits; 456 coded bits, interleaved over 22 bursts|TS 45.003 3.7|?| |
||
82 | |TCH/H4.8|6.0|4.8|60|10ms|4 blocks (240 bits) + 4 tail bits; rate 1/2 puncturing 32 bits; 456 coded bits interleaved like TCH/FS|TS 45.003 3.5|?| |
||
83 | 6 | laforge | |
84 | h2. Representation in RTP |
||
85 | |||
86 | 12 | laforge | See 3GPP TS 48.103 section 5.4.2.2 "RTP payload" as well as Section 5.6. |
87 | 11 | laforge | |
88 | It specifies CSData uses Clear mode pseudo-codec a per RFC4040, either |
||
89 | * without redundancy (redundancy level 1) / RTP PT 120 |
||
90 | * with redundancy (redundancy level 2 or 3) / RTP PT 121 |
||
91 | |||
92 | General comments: |
||
93 | 6 | laforge | * SDP uses "CLEARMODE/8000" |
94 | * 64kBps stream, i.e. 160 octets every 20ms |
||
95 | |||
96 | 1 | laforge | h2. Implementation Status |
97 | 3 | laforge | |
98 | 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 |
||
99 | |||
100 | h2. Relevant specifications |
||
101 | |||
102 | |_.Number|_.Description| |
||
103 | |3GPP TS 22.002|CS Bearer Services| |
||
104 | |3GPP TS 22.003|CS Teleservices| |
||
105 | 8 | laforge | |3GPP TS 22.004| |
106 | 15 | laforge | |3GPP TS 27.002|L2RCOP (protocol beween async characters and RLP in non-transparent mode)| |
107 | 5 | laforge | |3GPP TS 43.010|Decription of connection types. Note particularly Table 4 + section 6.4| |
108 | 3 | laforge | |3GPP TS 43.045|Fax G3| |
109 | 1 | laforge | |3GPP TS 44.021|Rate adaptation on MS-BSS interface; RA0; RA1/RA1' single-slot| |
110 | |3GPP TS 44.022|RLP protocol (for non-transparent async)| |
||
111 | 6 | laforge | |3GPP TS 27.001|TA functions in MS (incl. filtering of status bits)| |
112 | |3GPP TS 27.002|TA functions for async bearers (incl. data compression)| |
||
113 | 1 | laforge | |3GPP TS 27.003|TA functions for sync bearers| |
114 | 5 | laforge | |3GPP TS 48.020|Rate adaptation on BSS-MSC interface; RA1/RA1' multi-slot, RA1''| |
115 | 1 | laforge | |3GPP TS 48.060|TRAU frame format for classic E1 BTS (Section 5.3, 5.5.3, 6.7)| |
116 | |3GPP TS 29.007|Interworking between PLMN and ISDN| |
||
117 | 6 | laforge | |IETF RFC4040|RTP payload format for 64kbps transparent call| |
118 | |ITU-T V.110|Rate adaptation| |