7.19 MTSI MT Voice Call / EVS / AMR-WB IO mode / 5GS

34.229-53GPPInternet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Part 5: Protocol conformance specification using 5G System (5GS)Release 16TSUser Equipment (UE) conformance specification

7.19.1 Test Purpose (TP)

(1)

with { UE having set up a voice call using EVS and being configured to use preconditions }

ensure that {

when { UE receives INVITE indicating to switch to EVS AMR-WB IO mode }

then { UE responds by accepting this switch }

}

7.19.2 Conformance Requirements

[TS 26.114, clause 5.2.1.1]:

MTSI clients in terminals offering speech communication shall support narrowband, wideband and super-wideband communication. The only exception to this requirement is for the MTSI client in constrained terminal offering speech communication, in which case the MTSI client in constrained terminal shall support narrowband and wideband, and should support super-wideband communication.

In addition, MTSI clients in terminals offering speech communication shall support:

– .AMR speech codec (3GPP TS 26.071 [11], 3GPP TS 26.090 [12], 3GPP TS 26.073 [13] and 3GPP TS 26.104 [14]) including all 8 modes and source controlled rate operation ‎3GPP TS 26.093 [15]. The MTSI client in terminal shall be capable of operating with any subset of these 8 codec modes. More detailed codec requirements for the AMR codec are defined in clause 5.2.1.2.

MTSI clients in terminals offering wideband speech communication at 16 kHz sampling frequency shall support:

– AMR-WB codec (3GPP TS 26.171 ‎‎[17], 3GPP TS 26.190 ‎[18], 3GPP TS 26.173 ‎[19] and 3GPP TS 26.204 [20]) including all 9 modes and source controlled rate operation ‎3GPP TS 26.193 [21]. The MTSI client in terminal shall be capable of operating with any subset of these 9 codec modes. More detailed codec requirements for the AMR-WB codec are defined in clause 5.2.1.3. When the EVS codec is supported, the EVS AMR-WB IO mode may serve as an alternative implementation of AMR-WB as defined in clause 5.2.1.4.

MTSI clients in terminals offering super-wideband or fullband speech communication shall support:

– EVS codec ( TS 26.441 [121], TS 26.444 [124], TS 26.445 [125], TS 26.447 [127], TS 26.451 [131], TS 26.442 [122], TS 26.452 [165] and TS 26.443 [123]) as described below including functions for backwards compatibility with AMR-WB ( TS 26.446 [126]) and discontinuous transmission ( TS 26.449 [129] and TS 26.450 [130]). More detailed codec requirements for the EVS codec are defined in clause 5.2.1.4.

Encoding of DTMF is described in Annex G.

[TS 26.114, clause 5.2.1.4]:

When the EVS codec is supported, the MTSI client in terminal may support dual-mono encoding and decoding.

When the EVS codec is supported, EVS AMR-WB IO may serve as an alternative implementation of the AMR-WB codec, [125]. In this case, the requirements and recommendations defined in this specification for the AMR-WB codec also apply to EVS AMR-WB IO.

NOTE: The DTX operation of EVS Primary and AMR-WB IO can be configured in sending direction with either a fixed SID update interval (from 3 to 100 frames) or an adaptive SID update interval – more details can be found in clauses 4.4.3 and 5.6.1.1 of TS 26.445 [125]. Implementers of MTSI clients are advised to take into account this SID flexibility of EVS.

[TS 26.114, clause 6.2.2.3]:

An MTSI client in terminal must understand all the payload format options that are defined in RFC 4867 [28], and in [125]. It does not have to support operating according to all these options but must be capable to properly accepting or rejecting all options.

…

Table 6.3a: Handling of SDP parameters common to EVS Primary and EVS AMR-WB IO in the received SDP offer and in the SDP answer

Parameter

Comments

Handling

ptime

maxptime

dtx

MTSI client in terminal shall not include dtx in the initial SDP offer. MTSI MGW may modify SDP offer to include dtx in order to disable DTX in the session.

dtx-recv

MTSI client in terminal shall not include dtx-recv. MTSI MGW may modify SDP offer or answer in order to disable DTX for the send direction of the receiver of dtx-recv.

hf-only

–

evs-mode-switch

This parameter is used by MTSI MGW either when starting in EVS AMR-WB IO mode instead of EVS Primary mode or when switching between EVS Primary mode and EVS AMR-WB IO mode, e.g., for SRVCC.

MTSI client in terminal shall not include evs-mode-switch in the initial SDP offer. When including evs-mode-switch in the SDP offer during a session, the offerer shall use the requested mode when sending EVS packets. However, if a media stream is already being received, the offerer needs to be prepared to receive packets in both EVS primary and EVS AMR-WB IO modes until receiving the answer. When including evs-mode-switch in the SDP answer during a session, the answerer shall use the requested mode when sending EVS packets. When receiving SDP answer including evs-mode-switch during a session, the offerer shall use the requested mode when sending EVS packets.

max-red

See Table 6.3

channels

See Table 6.3

Table 6.3b: Handling of the EVS Primary SDP parameters in the received SDP offer and in the SDP answer

Parameter

Comments

Handling

br

An MTSI client in terminal supporting the EVS codec is required to support the entire bit-rate range but may offer a smaller bit-rate range or even a single bit-rate.

br-send

br-recv

bw

The session should start with the maximum bandwidth supported by the initial bit-rate up to the maximum negotiated bandwidth. If a range of bandwidth is negotiated, the codec can operate in any bandwidth in the session but the maximum bandwidth in the range should be used after the start of or update of the session. If a single audio bandwidth higher than narrowband is negotiated, the codec operates in the negotiated bandwidth but can use lower bandwidth(s) in the session, depending on the input signal.

Both the offerer and the answerer shall send according to the bandwidth parameter in the answer.

bw-send

bw-recv

ch-send

ch-recv

cmr

In EVS AMR-WB IO mode, CMR to the bit-rates of EVS AMR-WB IO mode and NO_REQ is always enabled.

If cmr=-1 and the session is in the EVS Primary mode, MTSI client in terminal shall not transmit CMR. If cmr=-1 and the session is in the EVS AMR-WB IO, MTSI client in terminal shall restrict CMR to values of EVS AMR-WB-IO bit-rates and NO_REQ in the session.

MTSI client in terminal is required to accept CMR even when cmr=-1. MTSI client in terminal is required to accept RTP payload without CMR even when cmr=1.

ch-aw-recv

If a positive (2, 3, 5, or 7) value of ch-aw-recv is declared for a payload type and the payload type is accepted, the receiver of the parameter shall send partial redundancy (channel-aware mode) at the start of the session using the value as the offset. If ch-aw-recv=0 is declared or not present for a payload type and the payload type is accepted, the receiver of the parameter shall not send partial redundancy (channel-aware mode) at the start of the session. If ch-aw-recv=-1 is declared for a payload type and the payload type is accepted, the receiver of the parameter shall not send partial redundancy (channel-aware mode) in the session. If not present or a non-negative (0, 2, 3, 5, or 7) value of ch-aw-recv is declared for a payload type and the payload type is accepted, partial redundancy (channel-aware mode) can be activated or deactivated during the session based on the expected or estimated channel condition through adaptation signalling, such as CMR (see Annex A.2 of [125]) or RTCP based signalling (see clause 10.2). If not present or a non-negative (0, 2, 3, 5, or 7) value of ch-aw-recv is declared for a payload type and the payload type is accepted, the partial redundancy offset value can also be adjusted during the session based on the expected or estimated channel condition through adaptation signalling.

Table 6.3c: SDP parameters for the EVS AMR-WB IO parameters in the received SDP offer and in the SDP answer

Parameter

Comments

Handling

mode-set

See Table 6.3

mode-change-period

mode-change-neighbor

mode-change-capability

The default value is re-defined in comparison to that in [28].

As the default and the only allowed value of mode-change-capability is 2 in EVS AMR-WB IO, it is not required to include this parameter in the SDP offer or answer.

NOTE 2: ECN-triggered adaptation is currently undefined for EVS. This does not prevent ECN-triggered adaptation from being negotiated and used for AMR or AMR-WB.

[TS 26.114, clause 6.2.5.2]:

If an MTSI client includes an AMR or AMR-WB mode-set, or EVS Primary mode br or br-recv parameter in the SDP offer or answer, the MTSI client shall set the b=AS parameter to a value matching the maximum codec mode in the mode-set or the highest bit-rate in the br or br-recv, the packetization time (ptime), and the intended redundancy level. For example, b=AS for AMR-WB at IPv6 should be set to 38 if mode-set includes {6.60, 8.85, 12.65}, the packetization time is 20, and if no extra bandwidth is allocated for redundancy. Likewise, b=AS for EVS Primary mode at IPv4 should be set to 42 if br=7.2-24.4, the packetization is header-full payload format, ptime=20, and no extra bandwidth is allocated for redundancy.

If an MTSI client does not include an AMR or AMR-WB mode-set, or EVS Primary mode br or br-recv parameter in the SDP offer or answer, the MTSI client shall set the b=AS parameter in the SDP to a value matching the highest AMR/AMR-WB mode, i.e., AMR 12.2 and AMR-WB 23.85, or the highest bit-rate of EVS Primary mode depending on negotiated bandwidth(s), i.e., EVS 24.4 for NB and EVS 128 for WB, SWB and FB, respectively.

NOTE 1: When no mode-set is defined, then this should be understood as that the offerer or answerer is capable of sending and receiving all codec modes of AMR or AMR-WB. An MTSI client in terminal will not include the mode-set parameter in SDP offer in the initial offer-answer negotiation. See Clause 6.2.2.2, Tables 6.1 and 6.2. It is however expected that the mode-set is defined when an SDP offer is received from an MTSI MGW inter-working with CS GERAN/UTRAN, see Clause 6.2.2.3, Table 6.5.

The bandwidth to use for b=AS for AMR and AMR-WB, and EVS Primary mode should be computed as shown in Annexes K and Q respectively. Tables 6.7 and 6.8 shows the bandwidth for the respective AMR and AMR-WB codec when the packetization time is 20 and no extra bandwidth is allocated for redundancy. The b=AS value is computed without taking statistical variations, e.g., the effects of DTX, into account. Such variations can be considered in the scheduling and call admission control. Detailed procedures to compute b=AS of AMR and AMR-WB, and EVS Primary mode can be found in Annexes K and Q.

NOTE 2: For any payload format, b=AS of EVS Primary mode at 5.9 kbps source controlled variable bit-rate (SC-VBR) coding is computed as the b=AS of its highest component bit-rate, 8 kbps.

NOTE 3: b=AS of EVS AMR-WB IO mode can be computed as in the octet-aligned payload format of AMR-WB as shown in Annex K.

b=AS of EVS shall be equal to the maximum of b=AS of the highest included EVS primary mode and b=AS of the highest included EVS AMR-WB IO mode, regardless of the presence and configuration of evs-mode-switch.

Table 6.7: b=AS for each codec mode of AMR when ptime is 20

Payload format

Codec mode

4.75

5.15

5.9

6.7

7.4

7.95

10.2

12.2

Bandwidth-efficient

IPv4

22

22

23

24

24

25

27

29

IPv6

30

30

31

32

32

33

35

37

Octet-aligned

IPv4

22

22

23

24

25

25

28

30

IPv6

30

30

31

32

33

33

36

38

Table 6.8: b=AS for each codec mode of AMR-WB when ptime is 20

Payload format

Codec Mode

6.6

8.85

12.65

14.25

15.85

18.25

19.85

23.05

23.85

Bandwidth-efficient

IPv4

24

26

30

31

33

35

37

40

41

IPv6

32

34

38

39

41

43

45

48

49

Octet-aligned

IPv4

24

26

30

32

33

36

37

40

41

IPv6

32

34

38

40

41

44

45

48

49

Table 6.9: b=AS for each bit-rate of EVS Primary mode when ptime is 20

Payload format

Bit-rate

7.2

8

9.6

13.2

16.4

24.4

32

48

64

96

128

Header-full

IPv4

24

25

27

30

34

42

49

65

81

113

145

IPv6

32

33

35

38

42

50

57

73

89

121

153

7.19.3 Test description

7.19.3.1 Pre-test conditions

System Simulator:

– 1 NR Cell connected to 5GC, default parameters.

UE:

– UE contains either ISIM and USIM applications or only USIM application on UICC.

– UE is configured to register for IMS after switch on.

– UE is configured to use preconditions.

Preamble:

– The UE is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS.

7.19.3.2 Test procedure sequence

Table 7.19.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

UE is made to attempt an IMS voice call.

–

–

2-7

Steps 2-7 of generic procedure specified in Table 4.9.15.2.2-1 of TS 38.508-1 [21] are performed

–

–

–

EXCEPTION: In parallel with Step 8, parallel behaviour defined in table 7.19.3.2-2 takes place

–

–

–

–

8

Step 1 of Annex A.4.1 happens

–>

INVITE

9

Step 2 of Annex A.4.1 happens

<–

100 Trying

10

Step 3 of Annex A.4.1 happens

<–

183 Session Progress

11

Step 4 of Annex A.4.1 happens

–>

PRACK

12

Step 5 of Annex A.4.1 happens

<–

200 OK

12A

Step 10 of generic procedure specified in Table 4.9.15.2.2-1 of TS 38.508-1 [21] is performed.

–

–

–

–

–

EXCEPTION: In parallel to steps 12B and 12C below, step 13 occurs.

–

–

–

–

12B-12C

Steps 10 of generic procedure specified in Table 4.9.15.2.2-1 of TS 38.508-1 [21] are performed.

–

–

–

–

13

Step 6 of Annex A.4.1 happens

–>

UPDATE

14

Step 7 of Annex A.4.1 happens

<–

200 OK

15

Step 8 of Annex A.4.1 happens

<–

180 Ringing

16

Step 9 of Annex A.4.1 happens

–>

PRACK

17

Step 10 of Annex A.4.1 happens

<–

200 OK

18

Step 11 of Annex A.4.1 happens

<–

200 OK

19

Step 12 of Annex A.4.1 happens

–>

ACK

20

Step 1 of Annex A.5.1 happens

<–

INVITE

21

Step 2 of Annex A.5.1 happens

–>

100 Trying

22

Step 11 of Annex A.5.1 happens

–>

200 OK

1

P

23

Step 12 of Annex A.5.1 happens

<–

ACK

Table 7.19.3.2-2: Parallel behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The UE transmits an RRCReconfigurationComplete message.

–>

NR RRC: RRCReconfigurationComplete

–

–

7.19.3.3 Specific message contents

INVITE (Step 20)

Use the default message "INVITE (Step 1)" in annex A.5.1 with the following exceptions:

Header/param

Value/remark

Supported

option-tag

precondition

Message-body

SDP body copied from the previous 200 OK (step 12 or 14) and modified as follows:

– "o=" line identical to previous SDP sent by SS except that sess-version is incremented.

– "a=fmtp" line identical to previous SDP sent by SS except that "evs-mode-switch=1" is added.

200 OK (Step 22)

Use the default message "200 OK (Step 11)" in annex A.5.1 with the following exceptions:

Header/param

Value/remark

Require

option-tag

precondition

Content-Type

media-type

application/sdp

Content-Length

value

length of message-body

Message-body

The following SDP types and values.

Session description:

v=0

o=(user-name) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE) [Note 4]

s=(session name)

c=IN (addrtype) (connection-address for UE) [Note 1]

b=AS: (bandwidth-value)

Time description:

t=0 0

Media description:

m=audio (transport port) RTP/AVP (fmt) [Note 2]

c=IN (addrtype) (connection-address for UE) [Note 1]

b=AS: (bandwidth-value)

b=RS: (bandwidth-value)

b=RR: (bandwidth-value)

Attributes for media:

a=rtpmap:(payload type) EVS/16000 [Note 2]

a=fmtp:(format) evs-mode-switch=1; [Note 2, 3]

Attributes for preconditions:

a=curr:qos local sendrecv

a=curr:qos remote sendrecv

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

Note 1: At least one "c=" field shall be present.

Note 2: The values for fmt, payload type and format are not checked.

Note 3: The evs-mode-switch is checked, but no other codec parameters.

Note 4: "o=" line identical to previous SDP sent by UE except that sess-version is incremented by one.