11a Transport Protocols
29.0073GPPGeneral requirements on interworking between the Public Land Mobile Network (PLMN) and the Integrated Services Digital Network (ISDN) or Public Switched Telephone Network (PSTN)Release 17TS
11a.1 Core Network
11a.1.0 Overview
The Nb UP protocol is used to transport user data in BICC based Core Network, see 3GPP TS 29.415 [80].
The RTP protocol is used to transport user data in SIP-I based Core Network, see 3GPP TS 29.414 [93]. The CLEARMODE payload type shall be applied, see IETF RFC 4040 [92] for 64k data.
Figures 16 and 16a below show the different cases to consider:
1. Transport on the access side of the IWF
2. Transport beyond the IWF, i.e., between the IWF and the fixed network
Figure 16: Transport of data within the BICC based Core Network
Figure 16a: Transport of data within the SIP-I based Core Network
11a.1.1 Void
11a.1.2 Transport beyond the IWF
11a.1.2.1 UDI and RDI
The data is transported in a 64 kbit/s bit stream, formatted in SDUs of 40 octets and transmitted every 5 ms, in accordance with Annex P of ITU-T Recommendation I.366.2 [81]. For BICC based CS CN, PDU type 0 is used, i.e., payload CRC is applied.
At the border between the CN and the fixed (ISDN) network, for BICC based CS CN conversion between Nb UP and TDM shall be applied. For SIP-I based CS CN conversion between "CLEARMODE" payload type and TDM shall be applied. In case of RDI interworking, the 56 kbit/s RDI bit stream is transmitted within the CN as 64 kbit/s bit stream where the last bit of each octet is ignored. For this reason the octet alignment shall be preserved in the SDUs transported in the CN.
11a.1.2.2 Modem
The modem signals are PCM encoded and transported on a 64 kbit/s bit stream. The transmission is otherwise identical to the UDI/RDI case, see Section 11a.1.2.1
11a.1.3 Transport on the access side of the IWF
11a.1.3.0 Inter MSC-Relocation
After inter-MSC relocation, Clause 11 is applicable.
Furthermore,for the BICC based CS CN the Nb UP is used in support mode, for SIP-I CLEARMODE/RTP shall be used; all interim Server nodes are assumed not to be aware of the relocation case – i.e. receive BICC IAM with same information as for connections beyond the IWF (Clause 11a.1.2).
Figure 17 indicates the relevant connections, where MSC-A/MGW-A are the Anchor nodes and MSC-B/MGW-B are the Non-Anchor nodes. The CSD MGW Termination Properties for the terminations in Figure 17 shall be used as described in Tables 16 and 17.
Figure 17: Bearer Independent connections for Inter-MSC SRNS Relocation
The Iu UP for BICC based CS CN shall be initialised on each Nb leg in a forward direction (regardless if Forward Bearer or Backward Bearer procedures are used), i.e. in the direction of the IAM. For further details see TS 23.205 [83].
When setting up the call leg towards MSC-B, the anchor node MSC-A shall request an UDI bearer in out-of-band signalling. For UDI/RDI multimedia calls with fallback and service change according to 3GPP TS 23.172 [17], the anchor node MSC-A shall negotiate the multimedia dummy codec as specified in 3GPP TS 23.153 [91] .
Figure 18 shows the scenario where the IWF resides in a MGW directly interfacing an Iu or A interface, as encountered e.g. before an inter-MSC handover. The CSD MGW Termination Properties for the terminations in Figure 18 shall be used as described in Tables 16 and 17.
Figure 18: IWF in MGW interfacing Iu or A interface
11a.1.3.0a Several MGWs controlled by same MSC server
In other cases than inter-MSC relocation where the IWF is not interfacing an Iu UP layer protocol entity, the following bullets are applicable (For example, an MSC-server may control two MGWs and route the call through both, as one MGW interfaces Iu and the other one hosts the user plane part of the IWF):
– If the access network uses A/Gb mode, the same transport as described in Clause 11.1 shall be applied.
– If the access network uses Iu mode, the same transport as described in Clause 11.4 shall be applied.
Furthermore, for BICC CS CN the Nb UP is used in support mode.
Figure 19 indicates the relevant connections, where MGW-A is where the IWF resides. The CSD MGW Termination Properties for the terminations in Figure 19 shall be used as described in Tables 16 and 17.
Figure 19: Transport on the access side of the IWF if the same MSC server controls one MGW A hosting the IWF and another MGW B interfacing the radio access network
The MSC server selects the direction of the IuUP initialisation if BICC based CS CN.
11a.1.3.1 Non-Transparent CSD
Table 16: Non-Transparent CSD MGW Termination Properties For Inter-MSC SRNS Relocation
|
Termination Packages/Parameters |
MSC-A |
MSC-B |
Intermediate Nodes |
|||||
|
T0 |
T1 (lu) |
T1 (A) |
T2 |
T7 |
T8 (lu) |
T8 (A) |
T3, T4, T5, T6 |
|
|
TMR |
TMR (NOTE 5) |
– |
– |
UDI (NOTE 3) |
UDI |
UDI (NOTE 7) |
UDI (NOTE 3) |
UDI |
|
threegcsd:plmnbc |
– |
PLMN_BC |
PLMN_BC |
PLMN_BC |
– |
– |
– |
– |
|
threegup:interface |
CN (NOTE 2) |
RAN |
– |
CN (NOTE 2) |
CN (NOTE 2) |
RAN |
– |
CN (NOTE 2) |
|
threegup:initdir |
(NOTE 2) (NOTE 4) |
IN |
– |
OUT (NOTE 2) (NOTE 6) |
IN (NOTE 2) (NOTE 6) |
OUT |
– |
IN (NOTE 2) |
|
threegup:mode |
Support (NOTE 2) |
support |
– |
Support (NOTE 2) |
Support (NOTE 2) |
support |
– |
Support (NOTE 2) |
|
threegcsde:bitrate |
– |
– |
– |
– |
– |
BITRATE |
– |
– |
|
threegcsd:gsmchancod |
– |
– |
GSM CC |
GSM CC (NOTE 1) |
– |
– |
– |
– |
|
IP Interface Type |
NboIP(NOTE 8) |
– |
AoIP (NOTE 9) |
NboIP(NOTE 8) |
NboIP(NOTE 8) |
– |
AoIP (NOTE 9) |
NboIP(NOTE 8) |
|
Payload Type |
CLEARMODE [92], G711 [1,x], or T.38 [y,z] (NOTE 11) |
– |
AoIP (NOTE 10) |
CLEARMODE [92] (NOTE 11) |
CLEARMODE [92] (NOTE 11) |
– |
AoIP (NOTE 10) |
CLEARMODE [92] (NOTE 11) |
|
NOTE 1: GSM CC shall only be provided if T8 is an A interface. GSM CC shall not be provided if T8 is an Iu interface. NOTE 2: Only applicable for a BICC network. NOTE 3: Optional NOTE 4: Value depends on call direction: IN if terminating call, OUT if originating call. NOTE 5: TMR is set according to the value received from ISDN/BICC signalling. Im addition, a received USI may be supplied. If no TMR value from ISDN/BICC signalling is available, but the MSC determines with the help of PLMN_BCs exchanged with the UE that the call is a data call, it shall supply a value derived from the PLMN_BC. NOTE 6: If several MGWs are controlled by the same MSC server, the server may also select the other value. NOTE 7: For a data rate of 64 kbit/s, TMR “UDI” may be supplied. For other data rates, TMR “UDI” shall not be sent. NOTE 8: The parameter may be supplied with value "NboIP" for a termination towards a SIP-I based CS CN. For termination towards a BICC based CS CN, the parameter shall not be supplied. NOTE 9: For an A interface with TDM transport, the IP interface type shall not be supplied. For an A interface with IP transport, the value "AoIP" may be supplied as IP interface type. NOTE 10: For an A interface with TDM transport, the Payload Type shall not be supplied. For an A interface with IP transport, CLEARMODE (see IETF RFC 4040 [92]) or Redundant RTP payload for Audio Data as specified in IETF RFC 2198 [94] encapsulating the CLEARMODE payload shall be supplied as payload type. NOTE 11: The parameter shall be supplied for a termination towards a SIP-I based CS CN. For terminations towards a BICC based CS CN, the parameter shall not be supplied. |
||||||||
11a.1.3.2 Transparent CSD
Table 17: Transparent CSD MGW Termination Properties For Inter-MSC SRNS Relocation
|
Termination Packages/Parameters |
MSC-A |
MSC-B |
Intermediate Nodes |
|||||
|
T0 |
T1 (iu) |
T1 (A) |
T2 |
T7 |
T8 (iu) |
T8 (A) |
T3, T4, T5, T6 |
|
|
TMR |
TMR (NOTE 6) |
– |
– |
UDI (NOTE 4) (NOTE 10) |
UDI (NOTE 10) |
UDI (NOTE 8) |
UDI (NOTE 4) |
UDI |
|
threegcsd:plmnbc |
– |
PLMN_BC (NOTE 9) |
PLMN_BC |
PLMN_BC (NOTE 10) |
– |
– |
– |
– |
|
threegup:interface |
CN (NOTE 3) |
RAN |
– |
CN (NOTE 3) |
CN (NOTE 3) |
RAN |
– |
CN (NOTE 3) |
|
threegup:mode |
(NOTE 3) Support |
transparent |
– |
Support (NOTE 3) |
Support (NOTE 3) |
transparent |
– |
Support (NOTE 3) |
|
threegup:initdir |
(NOTE 3) (NOTE 5) |
– |
– |
OUT (NOTE 3) (NOTE 7) |
IN (NOTE 3) (NOTE 7) |
– |
– |
IN (NOTE 3) |
|
threegcsden:bitrate |
– |
– |
– |
– |
– |
BITRATE (NOTE 1) |
– |
– |
|
threegcsd:gsmchancod |
– |
– |
GSM CC |
GSM CC (NOTE 2) |
– |
– |
– |
– |
|
IP Interface Type |
NboIP(NOTE 11) |
– |
AoIP(NOTE 12) |
NboIP(NOTE 11) |
NboIP(NOTE 11) |
– |
AoIP (NOTE 12) |
NboIP(NOTE 11) |
|
Payload Type |
CLEARMODE [92] or G.711 [1,x] (NOTE 14) |
– |
AoIP (NOTE 13) |
CLEARMODE (NOTE 14) |
CLEARMODE (NOTE 14) |
– |
AoIP (NOTE 13) |
CLEARMODE (NOTE 14) |
|
NOTE 1: This is optional if rate is 64kb/s. In this case no rate adaptation is required. NOTE 2: GSM CC shall only be provided if T8 is an A interface. GSM CC shall not be provided if T8 is an Iu interface. NOTE 3: Only applicable for a BICC network. NOTE 4: Optional NOTE 5: Value depends on call direction: IN if terminating call, OUT if originating call. NOTE 6: TMR is set according to the value received from ISDN/BICC signalling. Im addition, a received USI may be supplied. If no TMR value from ISDN/BICC signalling is available, but the MSC determines with the help of PLMN_BCs exchanged with the UE that the call is a data call, it shall supply a value derived from the PLMN_BC. NOTE 7: If several MGWs are controlled by the same MSC server, the server may also select the other value. NOTE 8: For a data rate of 64 kbit/s, TMR “UDI” may be supplied. For other data rates, TMR “UDI” shall not be sent. NOTE 9: For a SCUDIF multimedia call, the MuMe codec shall be configured instead. NOTE 10: For a SCUDIF multimedia call, the MuMe codec shall be configured instead in case of BICC termination. NOTE 11: The parameter may be supplied with value " NboIP" for a termination towards a SIP-I based CS CN. For terminations towards a BICC based CS CN, the parameter shall not be supplied. NOTE 12: For an A interface with TDM transport, the IP interface type shall not be supplied. For an A interface with IP transport, the value "AoIP" may be supplied as IP interface type. NOTE 13: For an A interface with TDM transport, the Payload Type shall not be supplied. For an A interface with IP transport, CLEARMODE (see IETF RFC 4040 [92]) or Redundant RTP payload for Audio Data as specified in IETF RFC 2198 [94] encapsulating the CLEARMODE payload shall be supplied as payload type. NOTE 14: The payload type parameter shall be supplied for a termination towards a SIP-I based CS CN. For terminations towards a BICC based CS CN, the parameter shall not be supplied. |
||||||||
11a.2 NT services
11a.2.1 Iu interface and Nb interface at access side of IWF in a BICC based CS CN
On the Iu interface and if TDM or SIP-I is not used in the CN between the access network and the IWF, this paragraph is applicable, except for the Nb interface in the case of inter-MSC relocation. The Iu and Nb user planes are used in support mode, see 3GPP TS 25.415 [42] and 3GPP TS 29.415 [80]. Each SDU corresponds to one RLP frame and, consequently, is 576 bits long. In GERAN Iu mode another SDU size of 480 bits is possible. It carries two RLP frames of 240 bits and is used if TCH/F9.6 is used in GERAN. Each SDU is transported in one Iu or Nb UP PDU of Type 1. In UTRAN Iu mode, the range of RAB Subflow Combination bit rate values is 14,4 kbit/s, 28,8 kbit/s, 57,6 kbit/s, limited by the maximum bit rate, and varies with the transmission period on the Uu interface, which is 40 ms, 20 ms or 10 ms. In GERAN Iu mode these values are valid if TCH/F14.4, TCH/28.8 or TCH/F43.2 is used. In addition GERAN Iu mode has a RAB Subflow Combination bit rate of 43,2 kbit/s with a transmission period of 13⅓ ms. If TCH/F9.6 is used, the range of RAB Subflow Combination bit rate values is 12 kbit/s, 24 kbit/s, 36 kbit/s, 48 kbit/s, limited by the maximum bit rate, and varies with the transmission period on the Um interface, which is 40 ms, 20 ms, 13⅓ ms or 10 ms. A change in the transmission period is signalled to the IWF through the Iu and Nb UP protocols. The Iu or Nb UP primitive Iu‑ or Nb-UP‑DATA-REQUEST is invoked each time an RLP frame is ready to be sent from the IWF towards the UE. DTX indication is not used.
The following table shows the connection between the RAB subflow combination bit rate and the AIUR.
Table 18: Connection between the RAB subflow combination bit rate and AIUR for Non-Transparent CSD Services
|
RAB subflow combination bit rate |
AIUR |
Used number of traffic channels and channel coding for GERAN Iu mode |
Comment |
|
57,6 kbit/s |
57,6 kbit/s |
4xTCH/F14.4, 2xTCH/F28.8 |
(Note 1) |
|
43,2 kbit/s |
43,2 kbit/s |
3xTCH/F14.4, 1xTCH/F43.2 |
(Note 2) |
|
48 kbit/s |
38,4 kbit/s |
4xTCH/F9.6 |
(Note 2) |
|
36 kbit/s |
28,8 kbit/s |
3xTCH/F9.6 |
(Note 2) |
|
28,8 kbit/s |
28,8 kbit/s |
2xTCH/F14.4, 1xTCH/F28.8 |
(Note 1) |
|
24 kbit/s |
19,2 kbit/s |
2xTCH/F9.6 |
(Note 2) |
|
14,4 kbit/s |
14,4 kbit/s |
1xTCH/F14.4 |
(Note 1) |
|
12 kbit/s |
9,6 kbit/s |
1xTCH/F9.6 |
(Note 2) |
|
NOTE 1: RAB subflow combination bit rate is used in UTRAN Iu mode and GERAN Iu mode NOTE 2: RAB subflow combination bit rate is only used in GERAN Iu mode |
|||
11a.2.2 Nb interface at access side of IWF in a BICC based CS CN for Inter-MSC relocation
For Inter-MSC relocation this paragraph is applicable for the Nb interface in BICC based CS CN between the access network and the IWF. The Nb UP protocol is applied in support mode and the SDU size is 320 bits, transmitted every 5 ms. PDU type 0 is used. The data within the PDU is encoded as A-TRAU’ and A-TRAU" frames.
11a.2.3 Nb interface at network side of IWF in a BICC based CS CN
If TDM is not used, then between the IWF and the fixed network (ISDN or PSTN), for the BICC based CS CN the Nb UP protocol is applied in support mode and the SDU size is 320 bits, transmitted every 5 ms. PDU type 0 is used.
11a.2.4 Nb interface at access side of IWF in a SIP-I based CS CN
The CLEARMODE RTP payload type shall be used with a framing period of 20 msecs. The data within the CLEARMODE RTP payload type shall be transported in a 64 kbit/s bit stream and shall be encoded as for the TDM case of the A interface.
11a.2.5 Nb interface at network side of IWF in a SIP-I based CS CN
For non-transparent CSD calls CLEARMODE [92] shall be supported in addition to G.711 [1,x] as RTP payload type.
NOTE: G.711 will only be used if an offerer is not able to determine wether a call is a data call or a speech call.
For facsimile calls T.38 [y,z] may be supported in addition to G.711.
For SCUDIF (see TS 23.172 [83]), the "vnd.3gpp.clearmode" RTP payload type (see Annex C) shall be used.
The negotiation of payload types is described in Clause 15.
11a.2.6 A interface with IP transport
The CLEARMODE RTP payload type (see IETF RFC 4040[92]) or Redundant RTP payload for Audio Data as specified in IETF RFC 2198 [94] encapsulating the CLEARMODE payload shall be used. Transport without redundancy shall be supported. Transport with redundancy may be supported. Only the redundancy level 2 and level 3 are applicable on the AoIP interface.
Note: The redundancy level is signalled from the MSC server by the Mc interface as negotiated between the MSC server with the BSC.
The data within the CLEARMODE RTP payload type shall be transported with a framing period of 20 ms in a 64 kbit/s bit stream and shall be encoded as for the TDM case of the A interface.
11a.3 T services
11a.3.0 Iu interface
On the Iu interface, the Iu UP is used in transparent mode, see 3GPP TS 25.415 [42]. The payload of the Iu and Nb frames will consist of user data bits only for synchronous data, and RA0 synchronous bit streams for asynchronous data.
On the Iu interfaces, the payload (SDU) size is fixed, determined by the bit rate. Following table shows SDU sizes. AAL2 is used. The AAL2 SSCS layer shall be supported for segmentation and re-assembly.
Table 19: SDU sizes for Transparent CSD Services at Iu interface
|
Bit rate |
SDU size (= RLC PDU payload size) |
|
28.8 kbit/s |
576 bits |
|
33.6 kbit/s |
672 bits |
|
32 kbit/s |
640 bits |
|
56/64 kbit/s |
640 bits |
The primitive Iu-UP _UNIT-DATA-REQUEST is invoked at regular intervals in order to have a constant bit rate (every SDU).
11a.3.0a Nb interface in BICC based CS CN
If TDM is not used at the Nb interface, then the Nb UP protocol is applied in support mode and the SDU size is 320 bits, transmitted every 5 ms. PDU type 0 is used.
11a.3.1 Avoidance of delay at RNC
The TTI-to-CPS Packet packaging delay can be avoided by choosing the length of the CPS packet payload so that the payloads of an integer number of CPS Packets fill one TTI. The contents of the whole TTI can be sent further towards the MSC immediately after the reception without waiting for the next TTI.
11a.3.2 Recovery from the loss of ATM cells
The ATM cell loss rate is estimated to be very small (less than 10-6 … 10-8), the quality of transmission being comparable to that of a high quality ISDN.
The following happens if a cell is lost (see ITU-T Recommendation I.363.2 [87]):
– At least one CPS packet is distorted.
– The distorted CPS packet(s) is/are discarded by the receiver.
– If only one CPS packet is discarded, the upper layer can identify the event by the UUI/SSSAR sequence number, and consequently insert a fill sequence of the length of a CPS payload field to the correct place in the bit stream. ITU-T Recommendation I.366.1[88] (SSSAR) describes that UUI takes value between 0 and 26 for final data and value 27 for more data, but UUI should take value 26 for final data considering compatibility with other SSCS specifications. When UUI works as sequence number by repetition of 27 and 26, CPS packet payload size is equal to half a SDU size. This CPS packet payload size also satisfies the requirement described in subclause 6.2.1. CPS packet payload size is set by ITU-T Recommendation Q.2630.1 [89] over Iu interface.
– If more than one CPS packets are discarded, the upper layer can identify the event by monitoring the buffer level at the ATM/TDM interface or by monitoring the reception of CPS packets with a timer. (The modulo 2 sequence number cannot indicate the loss of two consecutive CPS packets). The following figures apply for the 40 octet payload field.
– Worst case: 2 packets lost => 2 × 40 octets × 8 bits/octet : 64 kbit/s = 10 ms, i.e. buffer level decreased by 80 octets.
– Consequently, recovery with fill inserted in the correct place is possible, if the ATM cell jitter (i.e. transmission delay variation) is less than 5 ms. With a bigger jitter fill may be inserted in a wrong place in the TDM bit stream.
11a.3.3 A interface with IP transport
The CLEARMODE RTP payload type (see IETF RFC 4040[92]) or Redundant RTP payload for Audio Data as specified in IETF RFC 2198 [94] encapsulating the CLEARMODE payload shall be used. Transport without redundancy shall be supported. Transport with redundancy may be supported. Only the redundancy level 2 and level 3 are applicable on the AoIP interface.
Note: The redundancy level is signalled from the MSC server by the Mc interface as negotiated between the MSC server with the BSC.
The data within the CLEARMODE RTP payload type shall be transported with a framing period of 20 ms in a 64 kbit/s bit stream and shall be encoded as for the TDM case of the A interface.
11a.3.4 Nb interface at access side of IWF in a SIP-I based CS CN
The CLEARMODE RTP payload type shall be used with a framing period of 20 msecs. The data within the CLEARMODE RTP payload type shall be transported in a 64 kbit/s bit stream and shall be encoded as for the TDM case of the A interface.
11a.3.5 Nb interface at network side of IWF in a SIP-I based CS CN
CLEARMODE [92] shall be supported in addition to G.711 [1,x] as RTP payload types.
The negotiation of payload types is described in Clause 15.