Content for TS 26.114 Word version: 18.5.0

0… 3… 4… 5… 6… 6.2.3… 6.2.5… 6.2.7… 6.2.10… 7… 7.5… 8… 9… 10… 10.2.1.6… 10.2.2… 10.3… 10.4… 11… 12… 12.3… 12.7… 13a… 16… 16.5… 17… 18… 19… A… A.3… A.4… A.5… A.10… A.14… A.15… B… C… C.1.3… C.1.3.5 C.2… D E… E.18… E.31… G… K… L… M… N… O… P… P.3 Q… R… S… T… U… V… W… X… Y… Y.6… Y.6.4… Y.6.5… Y.7…

12.3 GERAN/UTRAN CS inter-working 12.3.0 3G-324M 12.3.1 Codecs for MTSI media gateways 12.3.1.1 Speech interworking between 3GPP PS access and CS GERAN/UTRAN 12.3.1.1a Speech inter-working between fixed access and CS GERAN/UTRAN 12.3.1.2 Text 12.3.2 RTP payload formats for MTSI media gateways 12.3.2.1 Speech 12.3.2.2 Text 12.3.3 Explicit Congestion Notification 12.3.4 Codec switching procedures with SRVCC 12.4 PSTN 12.4.1 3G-324M 12.4.2 Text 12.5 GIP inter-working 12.5.1 Text 12.5.2 Speech
...

12.3 GERAN/UTRAN CS inter-working p. 135

This clause defines requirements only for the PS side of the MGW, i.e. for the PS session in-between the MTSI client in a terminal and the MGW. The CS side of the MGW, i.e. in-between the MGW and the CS terminal, is out of scope of this clause.

This clause applies for MTSI MGWs supporting inter-working between a CS terminal using CS GERAN/UTRAN access or an MTSI client in terminal performing SRVCC to CS and:

an MTSI client in terminal using 3GPP access; or:
an MTSI client in terminal using fixed access; or:
a non-MTSI client.

The requirements and recommendations for these three cases are harmonized to enable using the same procedures regardless of the type of PS client and what access it uses, as long as it uses IP based access.

The target for this clause is to enable tandem-free operation when the same codec (AMR or AMR-WB) is used by both end-points.

An MTSI MGW may also support the other codecs listed in clause 18.2.2 for inter-working between an MTSI client in terminal using fixed access and a CS terminal using GERAN or UTRAN access. This means that tandem coding will be used and then the PS side and the CS side operate independently of each other. This further means that the requirements and recommendations for the PS side of the MGW are the same as for an MTSI client in terminal using fixed access, as described in clause 18, unless it is explicitly defined below.

12.3.0 3G-324M p. 135

If 3G-324M is supported in the GERAN/UTRAN CS, then the inter-working can be made as specified in clause 12.2.

12.3.1 Codecs for MTSI media gateways p. 135

12.3.1.1 Speech interworking between 3GPP PS access and CS GERAN/UTRAN p. 135

This clause applies to MTSI MGWs used for interworking between an MTSI client in terminal using 3GPP access and a CS GERAN/UTRAN UE.

MTSI media gateways supporting speech communication between an MTSI client in terminal using 3GPP access and terminals operating in the CS domain in GERAN and UTRAN should support Tandem-Free Operation (TFO) for AMR or AMR-WB according to TS 28.062, and Transcoder-Free Operation (TrFO), see TS 23.153.

MTSI media gateways supporting speech communication and supporting TFO and/or TrFO shall support:

AMR speech codec modes 12.2, 7.4, 5.9 and 4.75 (TS 26.071, TS 26.090, TS 26.073 and TS 26.104) and source-controlled rate operation (TS 26.093).

MTSI media gateways should also support the other AMR codec types and configurations as defined in clause 5.4 in TS 26.103.

In the receiving direction, from the MTSI client in the terminal, the MTSI media gateway shall be capable of restricting codec mode changes to be aligned to every other frame border and shall be capable of restricting codec mode changes to neighbouring codec modes within the negotiated codec mode set.

MTSI media gateways supporting wideband speech communication at 16 kHz sampling frequency and supporting TFO and/or TrFO for wideband speech shall support:

AMR wideband codec 12.65, 8.85 and 6.60 (TS 26.171, TS 26.190, TS 26.173 and TS 26.204) and source controlled rate operation (TS 26.193).

MTSI media gateways supporting wideband speech communication at 16 kHz sampling frequency should also support the other AMR-WB codec types and configurations as defined in TS 26.103.

MTSI MGWs supporting wideband speech communication shall also support narrowband speech communications. When offering both wideband speech and narrowband speech communication, wideband shall be listed as the first payload type in the m line of the SDP offer (RFC 4566).

Requirements applicable to MTSI media gateways for DTMF events are described in Annex G.

12.3.1.1a Speech inter-working between fixed access and CS GERAN/UTRAN |R12| p. 136

This clause applies to MTSI MGWs used for interworking between an MTSI client in terminal using fixed access and a CS GERAN/UTRAN UE.

Media codecs for MTSI MGWs for speech inter-working between fixed access and CS GERAN/UTRAN are specified in ETSI TS 181 005 [98] in clause 6.2 for narrow-band codecs and in clause 6.3 for wide-band codecs.

MTSI MGWs for speech inter-working between fixed access and CS GERAN/UTRAN supporting AMR and AMR-WB shall follow clause 12.3.1.1 for the AMR and AMR-WB codecs. Tandem-free inter-working should be used whenever possible.

For the other codecs, the MTSI MGW shall follow the recommendations and requirements defined in clause 18 for the respective codec. For these codecs, tandem-free inter-working is not possible when interworking with CS GERAN/UTRAN.

Requirements applicable to MTSI media gateways for DTMF events are described in Annex G.

12.3.1.2 Text p. 136

The CTM coding format defined in TS 26.226 is used for real time text in CS calls. In order to arrange inter-working, a transcoding function between CTM and RFC 4103 is required in the MTSI media gateway. A buffer shall be used for rate adaptation between receiving text from a real-time text transmitter according to the present document and transmitting to a CTM receiver. A gateway buffer of 2K characters is considered sufficient according to clause 13.2.4 in ETSI EG 202 320 [51].

12.3.2 RTP payload formats for MTSI media gateways p. 136

12.3.2.1 Speech p. 136

For RTP payload formats, see clause 18.4.3.

MTSI media gateways supporting AMR or AMR-WB shall support the bandwidth-efficient payload format and should support the octet-aligned payload format. When offering both payload formats, the bandwidth-efficient payload format shall be listed before the octet-aligned payload format in the preference order defined in the SDP.

The MTSI media gateway should use the SDP parameters defined in Table 12.1 for the session.

For all access technologies and for normal operating conditions, the MTSI media gateway should encapsulate the number of non-redundant speech frames in the RTP packets that corresponds to the ptime value received in SDP from the other MTSI client, or if no ptime value has been received then according to "Recommended encapsulation" defined in Table 12.1. The MTSI media gateway may encapsulate more non-redundant speech frames in the RTP packet but shall not encapsulate more than 4 non-redundant speech frames in the RTP packets. The MTSI media gateway may encapsulate any number of redundant speech frames in an RTP packet but the length of an RTP packet, measured in ms, shall never exceed the maxptime value.

Table 12.1: Recommended encapsulation parameters

Access technology	Recommended encapsulation (if no ptime and no RTCP_APP_REQ_AGG has been received)	ptime	maxptime when redundancy is not supported	maxptime when redundancy is supported
Default	1 non-redundant speech frame per RTP packet Max 4 or 12 speech frames in total depending on whether redundancy is supported but not more than a received maxptime value requires	20	80	240
HSPA E-UTRAN NR	1 non-redundant speech frame per RTP packet Max 4 or 12 speech frames in total depending on whether redundancy is supported but not more than a received maxptime value requires	20	80	240
EGPRS	2 non-redundant speech frames per RTP packet but not more than a received maxptime value requires Max 4 or 12 speech frames in total depending on whether redundancy is supported but not more than a received maxptime value requires	40	80	240
GIP	1 to 4 non-redundant speech frames per RTP packet but not more than a received maxptime value requires Max 12 speech frames in total but not more than a received maxptime value requires	20, 40, 60 or 80	N/A	240

When the access technology is not known to the MTSI media gateway, the default encapsulation parameters defined in Table 12.1 shall be used.

The SDP offer shall include an RTP payload type where octet-align=0 is defined or where the octet-align parameter is not specified and should include another RTP payload type with octet-align=1. MTSI media gateways offering wide-band speech shall offer these parameters and parameter settings also for the RTP payload types used for wide-band speech.

MTSI media gateways should support the RTCP-APP signalling defined in clause 10.2.1. The Codec Mode Request (RTCP_APP_CMR) is only relevant when AMR or AMR-WB is used but the Redundancy Request and the Frame Aggregation Request can be used for all codecs. When RTCP-APP is not supported or cannot be used in the session then adaptation can also be based on RTCP Receiver Reports/Sender Reports.

MTSI media gateways should support redundancy according to clause 9.

12.3.2.2 Text p. 137

Both CTM according to TS 26.226 and RFC 4103 make use of ITU-T Recommendation T.140 presentation and character coding. Therefore inter-working is a matter of payload packetization and CTM modulation/demodulation.

12.3.3 Explicit Congestion Notification |R9| p. 138

An MTSI MGW can be used to enable ECN between the MTSI client in terminal and the MTSI MGW when inter-working with CS GERAN/UTRAN.

If ECN is supported in the MTSI MGW, then the MTSI MGW shall also:

support ECN as described in this specification for the MTSI client in terminal, except that the MTSI MGW does not determine whether ECN can be used based on the Radio Access Technology that is used towards the MTSI client in terminal;
support RTP/AVPF and SDPCapNeg if the MTSI MGW supports RTCP AVPF ECN feedback messages;
be capable of enabling end-to-end rate adaptation between the MTSI client in terminal and the CS terminal by performing the following:
- negotiate the use of ECN with the MTSI client in terminal, if it can be confirmed that the network used towards the MTSI client in terminal properly handles ECN-marked packets;
- inter-work adaptation requests between the MTSI client in terminal and the CS GERAN/UTRAN;

12.3.4 Codec switching procedures with SRVCC |R12| p. 138

An MTSI client in terminal (hereinafter "local client") using 3GPP PS access may be handed over to CS access. By that SRVCC procedure, the end-point of the IP connection moves from the local client to a CS MGW in the CS network, as described in TS 23.216 (SRVCC).

In order to achieve this handover, the MSC server, controlling the CS MGW, sends a SIP INVITE message:

either to the remote client (in case of SRVCC handover without SRVCC enhancement);
or to the ATCF (in case of SRVCC handover with ATCF enhancement),

to change the communication end from the MTSI client in terminal to the CS MGW as described in TS 23.237.

If EVS is used between local and remote client before SRVCC and if AMR-WB is used after SRVCC by the local CS UE, an MTSI MGW (e.g. MSC/CS-MGW or ATCF/ATGW) can send the RTCP_APP_EP2I request message, (see clause 10.1.2.10), or a CMR in the RTP payload requesting an EVS AMR-WB IO mode, to the remote client to request that it switches from the EVS Primary mode to the EVS AMR-WB IO mode. The mode-set used in CS shall be included in the RTCP_APP_EP2I request message. Furthermore, the RTCP_APP_EP2I request message also supports signalling to restrict the timing and destination of codec mode changes. An SDP offer/answer negotiation between the MTSI MGW and the remote client can also be performed to align the mode-sets and to optimize the resource usage and also to request switching to the EVS AMR-WB IO mode.

Correspondingly, the RTCP_APP_EI2P request message can be used to switch from the EVS AMR-WB IO mode to the EVS Primary mode, e.g. in case an SRVCC handover to a CS access and a switch to the EVS AMR-WB IO mode is followed by a reverse SRVCC to perform handover back to the PS access. An SDP offer/answer negotiation can also be performed to restore the session, e.g. bitrates, bandwidths and other configuration parameters, to what was used before SRVCC.

12.4 PSTN p. 139

12.4.1 3G-324M p. 139

If 3G-324M is supported in the PSTN, then the inter-working can be made as specified in clause 12.2.

12.4.2 Text p. 139

PSTN text telephony inter-working with PS environments is described in ITU-T Recommendation H.248.2 [50] and further elaborated in ETSI EG 202 320 [51].

Text telephony modem tones are sensitive to packet loss, jitter and echo canceller behaviour. Therefore, conversion of modem based transmission of real-time text is best done at the border of the PSTN. If PSTN text telephone tones need to be carried audio coded in a PS network, considerations must be taken to carry them reliably as for example specified in ITU-T Recommendations V.151 [54] and V.152 [55].

When inter-working with PSTN text telephones, it must be considered that in PSTN most text telephone communication methods do not allow simultaneous speech and text transmission. An MTSI client in terminal indicating text capability shall not automatically initiate text connection efforts on the PSTN circuit. Instead, either a requirement for text support should be required from the MTSI client in terminal, active transmission of text from the MTSI client in terminal, or active transmission of text telephone tones from the PSTN terminal. See clause 13 of ETSI EG 202 320 [51].

Note that the primary goal of real-time text support in MTSI is not to offer a replica of PSTN text telephony functionality. On the contrary, real-time text in MTSI is aiming at being a generally useful mainstream feature, complementing the general usability of the Multimedia Telephony Service for IMS.

12.5 GIP inter-working p. 139

12.5.1 Text p. 139

RFC 4103 and T.140 are specified as default real-time text codec in SIP telephony devices in RFC 4504. When GIP implements this codec, the media stream contents are identical for the two environments. Packetization will also in many cases be equal, while consideration must be taken to cope with different levels of redundancy and possible use of different media security and integrity measures.

12.5.2 Speech |R8| p. 139

See clause 12.7.