8 User plane interworking

29.1633GPPInterworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networksTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

8.1 Interworking between IM CN subsystem and bearer independent CS network

When the IM CN subsystem interworks with the bearer independent CS networks (e.g. CS domain of a PLMN, 3GPP TS 29.414 [25], 3GPP TS 29.415 [26], 3GPP TS 23.205 [27]), then the Transport Network Layer (TNL) of the bearer independent CS network can be based e.g. on IP/UDP/RTP, or IP/UDP/RTP/IuFP, or ATM/AAL2/ framing protocol (e.g. Iu framing) transport techniques. Figure 31 shows the user plane protocol stacks for the IM CS subsystem and bearer independent CS network interworking. If the same or TrFO-compatible codec configuration(s) is/are used on the CS network side and on the IMS side, then transcoding is not required. However, there is still a need to interwork between RTP/UDP/IP/L2/L1 to TNL/L1.

Figure 31/1: IM CN subsystem to bearer independent CS network user plane protocol stack

8.1.1 Transcoder-less Mb to Nb Interworking

Figure 31/2: IM CN subsystem to bearer independent CS network user plane protocol stack (optional in the event the codecs on both sides are the same)

If no transcoder is inserted, the IM-MGW shall interwork the following procedures between the Nb and Mb interfaces.

8.1.1.1 Initialisation

There is no need to interwork initialisation procedures between Nb and Mb interfaces see 3GPP TS 29.415 [26].

8.1.1.2 Time alignment

The purpose of the time alignment procedure on the Nb interface is to minimise the buffer delay in the RNC for downlink transmissions by adjusting the vocoder time reference within the network. No such procedure exists on the Mb interface, so the IM-MGW shall return NACK indication time alignment not supported according to 3GPP TS 29.415 [26].

8.1.1.3 Rate control

8.1.1.3.1 General

The rate control procedure signals to the peer entity the maximum rate among the currently allowed rates at which it can receive codec frames. Rate control only applies to AMR, AMR-WB and EVS codec configurations with multiple active modes. For the EVS codec, the rate control procedure also signals to the peer entity the maximum mode among the currently allowed modes at which it can receive codec frames.

8.1.1.3.2 Rate control for AMR and AMR-WB codecs

For AMR and AMR-WB codecs:

– On the Nb interface, IuFP provides for rate control via the exchange of RATE CONTROL and RATE CONTROL ACK PDUs

– On the Mb interface, IETF RFC 4867 [23] provides for in-band rate control via the Codec Mode Request (CMR) field of every codec frame (Speech or SID) and CMR-Only frames.

– Interworking of rate control procedures at an IM-MGW between an Mb interface and a corresponding Nb interface only applies when the IM-MGW bridges compatible codec configurations between the interfaces without applying a transcoding function.

– An IM-MGW receiving a CMR from an Mb interface shall initiate the IuFP rate control procedure on the corresponding Nb interface.

– An IM-MGW receiving a rate control request on an Nb interface shall adjust the CMR field of outgoing speech frames on the corresponding Mb interface.

8.1.1.3.3 Rate and Mode control for the EVS codec

For the EVS codec:

– On the Nb interface, CMR for EVS (EVS-CMR) as specified in 3GPP TS 26.453 [152] subclause 4.5 provides for in-band rate and mode control via the Codec Mode Request (CMR) field of every codec frame (Speech or SID) and CMR-Only frame.

– On the Mb interface, EVS-CMR as specified in 3GPP TS 26.445 [147] subclause A.2.2.1.1 provides for in-band rate and mode control via the Codec Mode Request (CMR) field of the codec frame in RTP. Alternatively RTCP-APP packets may be used with corresponding control commands as specified in 3GPP TS 26.114 [104]. The rate and mode control on the Mb interface depends on the SDP offer/answer procedure. It may also be disabled, in which case transcoding is mandatory.

– An IM-MGW receiving an EVS-CMR from an Nb interface may filter and modify the EVS-CMR contents based on configured policies and shall perform one of the following alternatives:

1)if CMR in RTP is required in every RTP packets on the Mb interface (cmr=1),include the resulting contents into the EVS-CMR field of the corresponding outgoing frame or CMR-Only frame on the Mb interface;

2)if CMR in RTP is enabled "on demand" on the Mb interface (cmr=0 or omitted), include the resulting contents into the EVS-CMR field of the outgoing codec frame or CMR-Only frame on the corresponding Mb interface only if it is different from the previously sent EVS-CMR value, and send the new EVS-CMR value at least 3 times within the next 100 ms to provide a minimum of error robustness, if necessary using also additional CMR-Only frames in speech pauses;

3)if CMR in RTP is disabled on the Mb interface (cmr=-1) and if RTCP-APP is enabled on the Mb interface, translate the resulting contents into a corresponding RTCP-APP command and send it at least 3 times within the next 100 ms to provide a minimum of error robustness, if the resulting RTCP-APP command is different from the previously sent RTCP-APP command; or

4)if CMR in RTP is disabled on the Mb interface (cmr=-1) and if RTCP-APP is disabled on the Mb interface, applying a transcoding function. In this case the rate and mode control on the Nb interfaceis terminated in the IM-MGW.

– An IM-MGW receiving an EVS-CMR on an Mb interface may filter and modify the EVS-CMR contents based on configured policies and shall include the resulting contents into the EVS-CMR field of the outgoing codec frame or CMR-Only frame on the corresponding Nb interface.

– The rules by which the IM-MGW may filter and modify the EVS-CMR contents consist of the following:

1) The IM-MGW shall not modify the EVS-CMR to increase the maximum bit rate;

2) If the IM-MGW observes the incoming stream of speech frames or packets and determines that a lower EVS mode is more appropriate, the IM-MGW may modify the EVS-CMRs sent in the opposite direction of the observed speech flow;

3) If the IM-MGW modifies the EVS-CMR to decrease the maximum bit rate and the resulting maximum bit rate no longer support the originally requested maximum audio bandwidth, then the maximum audio bandwidth may be reduced by the IM-MGW to the next lower one that fits to the reduced maximum bit rate;

4) The IM-MGW shall not modify the EVS-CMR in a way that results in a change of the major operation mode (EVS primary mode or EVS AMR-WB IO mode);

NOTE: The IM-MGW can be forced to change the major operation mode of an incoming EVS-CMR when interworking between EVS and AMR-WB, during handover or after handover.

5) When channel-aware mode is used, if the IM-MGW observes the incoming stream of speech frames or packets and determines that other channel-aware mode parameters are more appropriate, the IM-MGW may modify the EVS-CMRs, flowing in the opposite direction of the observed speech flow to change the received channel-aware offset to a bigger one (e.g. from 2 to 3) and the received channel-aware depth to a lower, more robust one;

6) When channel-aware mode is used, the IM-MGW shall not reduce the received channel-aware offset or modify the received channel-aware depth a less robust one;

7) The IM-MGW should not block the channel-aware mode;

8) The IM-MGW may modify the EVS primary mode in the received EVS-CMR to the EVS Variable Bit Rate mode.

8.1.1.3.4 Interworking of rate control between compatible AMR-WB and EVS codec configurations

The EVS codec includes the EVS AMR-WB IO major operation mode and is therefore TrFO-compatible to the AMR-WB codec, if the mode-set and mode-change-period parameters are TrFO-compatible. For example, AMR-WB on one IM-MGW termination and EVS on the other IM-MGW termination are TrFO-compatible codecs, if the mode-set parameters are TrFO-compatible and mode-change-period=2 on both sides.

If the IM-MGW bridges compatible EVS codec configurations and AMR-WB codec configurations:

– If the codec of the incoming termination is EVS and the codec of the outgoing termination is AMR-WB, then the rate control procedure for AMR-WB shall apply at the outgoing termination, with the maximum rate equal to or lower than the maximum rate received in the EVS-CMR. The IM-MGW shall map received EVS-CMRs to the selected mode-set of the outgoing AMR-WB termination.

– If the codec of the incoming termination is AMR-WB and the codec of the outgoing termination is EVS, then the rate control procedure for AMR-WB shall apply on the incoming termination and shall determine the maximum rate included in the EVS-CMR sent by the IM-MGW. The IM-MWG shall request the EVS AMR-WB IO major operation mode in the outgoing EVS-CMR.

– The IM-MGW may filter and modify the CMR contents according to the following rules:

1) The IM-MGW shall not modify the EVS-CMR to increase the maximum bit rate;

If the IM-MGW bridges EVS codec configurations and AMR-WB codec configurations which are not compatible, the IM-MGW shall apply transcoding and shall handle the independent rate and mode control procedures towards the incoming and the outgoing networks.

8.1.1.3.5 Interworking between rate control and RTCP-APP-CMR messages for MTSI

An IM-MGW may support the MTSI service defined in 3GPP TS 24.173 [88] and may then support codecs according to 3GPP TS 26.114 [104].

NOTE 1: Alternative codec specifications for the MTSI service are listed in 3GPP TS 24.173 [88].

If the IM-MGW supports the MTSI service with the codecs according to 3GPP TS 26.114 [104] the IM-MGW should support reception of RTCP-APP-CMR messages as specified in the clause 10.2.1 of 3GPP TS 26.114 [104] which can be sent by a MTSI client in the terminal. If the IM-MGW is in TrFO then RTCP-APP-CMR messages should be translated to the appropriate rate control method on the CS side (e.g. IuFP rate control or RTP based CMR) in the same way as for an RTP based CMR, described in the preceding subclauses.

NOTE 2: When the IM-MGW is transcoding at the Mb interface then any RTCP-APP-CMR requests received from the MTSI client in the terminal when the IM-MGW is transcoding will result in a change to to DL codec mode towards the MTSI client terminal.

8.1.1.4 Frame quality indication

The Nb interface signals frame quality with the Frame Quality Classification (FQC) field of each speech frame PDU. See 3GPP TS 26.102 [50] and 3GPP TS 29.415 [26] for details. The FQC may have possible values: 0=frame_good; 1=frame_bad; 2=frame_bad_due_to_radio; and 3=spare. The Mb interface signals frame quality with the Q bit (frame quality indicator) field of each speech frame, as defined in IETF RFC 4867 [23]. The Q bit may have values: 1=speech_good; and 0=speech_bad or sid_bad.

Tables 24a and 24b provide the mapping between Mb and Nb interfaces.

Table 24a: Mapping of Mb (Q bit) onto Nb (FQC)

Mb – Qbit	Mb – FT	Nb – FQC
1	X	0
0	X	1

Table 24b: Mapping Nb onto Mb

Nb – FQC	Mb – Qbit	Mb – FT
0	1	NC
1	0	NO_DATA
2	0	NC

8.1.1.5 Framing

Even when the IM-MGW bridges compatible codec configurations between the Nb and Mb interfaces, the IM-MGW shall perform translation between the frame formats defined for the two interfaces, since all codec configurations have different framing procedures for the two interfaces. The framing details for Nb are defined in 3GPP TS 26.102 [50] and 3GPP TS 29.415 [26], although they do not describe the framing for ITU-T codecs other than G.711. The framing details for Mb are defined in IETF RFC 4867 [23], IETF RFC 3550 [51], IETF RFC 3551 [52] and IETF RFC 3555 [53].

8.1.1.6 Transcoding

Transcoding at the IM-MGW is avoided when the IM-MGW bridges compatible codec configurations between the Nb and Mb interfaces. Otherwise transcoding is necessary, which eliminates the need to interwork other user plane procedures between the interfaces.

8.1.1.7 Discontinuous transmission

When the IM-MGW bridges compatible codec configurations between the Nb and Mb interfaces, the DTX procedures are normally interworked transparently by translating between the framing formats on the interfaces. All the ITU-T, AMR, AMR-WB and EVS codecs have configurations that are compatible between the Mb and Nb interfaces.

For the AMR, AMR-WB and EVS codecs, DTX is always enabled on the CS radio Interface in the uplink direction and the transport channel for DTX in the downlink is always provided.

If the IMS side requires interworking without DTX in its media-receive direction, then the IM-MGW shall insert transcoding in this direction. The IMS side may apply in its media-sending direction DTX or not, the CS side is prepared for both alternatives without transcoding.

8.1.1.8 Timing and sequence information

The IM-MGW shall always correct out-of-sequence delivery between Nb and Mb interfaces, either by re-ordering frames, or by dropping frames that are out of sequence.

When the IuFP frame numbers are based on time and if the IM-MGW bridges compatible codec configurations between the Nb and Mb interfaces, it shall either correct jitter before forwarding PDUs or interwork the RTP timestamp (see RFC 3550 [51]) with the IuFP Frame Number (see 3GPP TS 29.415 [26]) so that both the RTP timestamp and IuFP frame number similarly reflect the nominal sampling instant of the user data in the packet.

NOTE: Correcting jitter may cause additional delay.

The RTP sequence number (see RFC 3550 [51]) is handled independently on Mb, i.e. it is not interworked with the IuFP Frame Number (see 3GPP TS 29.415 [26]).

8.2 Interworking between IM CN subsystem and TDM-based CS network

It shall be possible for the IM CN subsystem to interwork with the TDM based CS networks (e.g. PSTN, ISDN or CS domain of a PLMN). Figure 32 describes the user plane protocol stack to provide the particular interworking.

Figure 32: IM CN subsystem to TDM-based CS network user plane protocol stack

8.3 Transcoding requirements

The IM CN subsystem supports the AMR codec as the native codec for basic voice services. For IM CN subsystem terminations, the IM MGW shall support the transport of AMR over RTP according to IETF RFC 4867 [23]. The MGCF shall support the options of IETF RFC 4867 [23] listed within subclause 12.3.1 of 3GPP TS 26.114 [104].

It shall be possible for the IM CN subsystem to interwork with the CS networks (e.g. PSTN, ISDN or a CS domain of a PLMN) by supporting AMR to G.711 transcoding (see ITU-T Recommendation G.711 [1]) in the IM-MGW. The IM-MGW may also perform transcoding between AMR and other codec types supported by CS networks.

8.4 Diffserv code point requirements

The IM-MGW shall perform DiffServ Code Point (DSCP) markings (see RFC 2474 [21]) on the IP packets sent towards the IM CN subsystem entity like UE or MRFP across the Mb interface to allow DiffServ compliant routers and GGSNs to schedule the traffic accordingly.

The IETF Differentiated Services architecture (see RFC 2475 [22]) shall be used to provide QoS for the external bearer service.

The DSCP shall be operator configurable.

8.5 DTMF handling

When sending DTMF inband towards the CS network, the MGW shall comply with the encoding requirements in 3GPP TS 23.014 [103]; in particular the requirements for the minimum length of a tone and for the minimum gap between two subsequent tones shall be ensured.

When detecting DTMF digits arriving from the CS side, the MGW shall comply with 3GPP TS 23.014 [103] (by checking that a valid digit with minimum duration and minimum gap has been received) before initiating an RTP Telephony Event to the IMS interface.

When sending DTMF towards the IMS side according to the IETF RFC 4733 [105] RTP Payload format, the MGW shall comply with the DTMF encoding requirements of Annex G.2 of 3GPP TS 26.114 [104], in particular the minimum duration of 65ms shall be ensured. It is optional if the RTP Telephony Event is sent as a number of "RTP Events" with interim durations (e.g. every 20ms or 40ms in line with the speech packetisation time) or as a single "RTP Event" with the at least 65ms duration.