13 Conversational services, Streaming and TV

21.9163GPPRelease 16Release descriptionTS

13.1 Conversational services

13.1.1 Coverage and Handoff Enhancements for Multimedia (CHEM)

810003

Coverage and Handoff Enhancements for Multimedia

CHEM

S4

SP-180664

Nikolai Leung

Summary based on the input provided by Qualcomm Incorporated in SP-190865.

The Coverage and Handoff Enhancements for Multimedia (CHEM) feature enables the network to delay or reduce handoffs of a Multimedia Telephony Service for IMS ( MTSI) terminal by providing the eNB/gNB additional information about the robustness to packet losses of the negotiated media configurations. The eNB/gNB can set handoff thresholds that allow the MTSI terminal to remain on the current sector, cell, access technology, or domain (packet-switched vs. circuit-switched) and avoid a handoff even when the MTSI terminal experiences higher packet loss on the traffic channel as the media configuration robustness will help mitigate the effects of the additional packet losses.

The feature is structured with a baseline core functionality and some optional enhancements as illustrated in Figure 1. The optional enhancements can be independently used with the core CHEM feature and each other. TR 26.959 [1] has also been updated to explain the operation and interaction of these options and the core feature.

Figure 1: Core function and optional enhancements of the CHEM feature
(references are to clauses in TS 26.114 [6]).

The core CHEM functionality specified in clauses W.1 and W.2 of TS 26.114 [2] introduces the ‘PLR_adapt’ SDP attribute that is used to negotiate the CHEM feature between the MTSI clients. MNOs choosing not to enable the feature can remove the attribute in the SDP negotiation. The attribute is also used by the PCRF/PCF to determine whether it can expect the MTSI clients to adapt to the most robust configurations that have been negotiated without relying in application layer redundancy. The PCRF/PCF uses this information to determine the appropriate PLR thresholds, i.e., choosing the PLR of the most robust mode when ‘PLR_adapt’ is negotiated, and communicate the PLR thresholds to the eNB/gNB.

An optional enhancement specified in clause W.4 of TS 26.114 [2] enables the MTSI clients to indicate the maximum tolerable end-to-end PLRs for particular codec configurations and then negotiate how this end-to-end PLR can be budgeted across their respective uplinks and downlinks. Indicating maximum tolerable end-to-end PLR thresholds can be useful to account for differing client implementations of features, e.g., such as the de-jitter buffer and Packet-Loss-Concealment (PLC) in the media receiver, which can affect the maximum tolerable PLR for achieving a certain Quality of Experience (QoE). This enhancement uses the defined ‘MAX-e2e-PLR’ attribute and associated parameters to perform the necessary indication and negotiation. The PCRF/PCF uses the ‘MAX-e2e-PLR’ attribute information in the SDP answer to determine and communicate the appropriate PLR thresholds to the eNB/gNB.

Another optional enhancement for speech media specified in clause W.3 of TS 26.114 [2] is to support use of application layer redundancy to improve media robustness that, when used with the CHEM feature, can delay or avoid handing off an MTSI terminal. The optional ‘ALR’ parameter for the ‘PLR_adapt’ attribute has been specified to enable this option and allows the MTSI clients to use newly specified in-band RTP CMR codepoints to request application layer redundancy without having to use RTCP-APP messages. The PCRF/PCF uses the presence of the ‘PLR_adapt: ALR’ attribute and parameter in the SDP answer to determine the appropriate PLR thresholds based on the maximum tolerable PLRs of the codec configurations (among those that both use, and do not use, application layer redundancy), then communicates this to the eNB/gNB.

An Annex of TS 26.114 [2] provides example PLR values that can be used for different speech codecs and their configurations. The annex also provides SDP examples for using the specified SDP attributes and parameters.

References

[1] TR 26.959 “Study on enhanced Voice over LTE (VoLTE) performance”

[2] TS 26.114 “IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction”

CRs related to this Feature: Select "TSG Status = approved" in: https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=810003

13.1.2 Single radio voice continuity from 5GS to 3G

810041

Single radio voice continuity from 5GS to 3G

5G_SRVCC

 

SP-180737

Chi Ren, China Unicom

790010

Study for single radio voice continuity from 5GS to 3G

FS_5G-SRVCC

S2

SP-180239

Chi Ren, China Unicom

810007

Single radio voice continuity from 5GS to 3G

5G_SRVCC

S2

SP-180897

Chi Ren, China Unicom

820008

Security aspects of single radio voice continuity from 5GS to UTRAN

5GS_UTRAN_SEC

S3

SP-181037

Feng Gao, China Unicom

820069

RAN aspects of 5G_SRVCC

SRVCC_NR_to_UMTS

R2

RP-200151

China Unicom

820169

Core part: Single Radio Voice Call Continuity from 5G to 3G

SRVCC_NR_to_UMTS-Core

R2

RP-200151

China Unicom

830270

Perf. part: Single Radio Voice Call Continuity from 5G to 3G

SRVCC_NR_to_UMTS-Perf

R4

RP-200151

China Unicom

840004

CT aspect of 5G_SRVCC

5G_SRVCC

ct

CP-191062

Chi Ren, China Unicom

840058

CT1 aspect of 5G_SRVCC

5G_SRVCC

C1

CP-191062

Chi Ren, China Unicom

840059

CT4 aspect of 5G_SRVCC

5G_SRVCC

C4

CP-191062

Chi Ren, China Unicom

Summary based on the inputs provided by China Unicom in SP-200129 for global aspects and in RP-200152 for the radio aspects.

The work item of 5G_SRVCC introduced a mechanism to support single radio voice call continuity (SRVCC) from 5GS to UTRAN for the following scenarios:

– Operators with both 5G Voice over IMS and LTE enabled, but no VoLTE.

– Operators with no LTE (nor VoLTE).

– Operators with both 5G Voice over IMS and VoLTE enabled, but the voice service continuity may not be guaranteed if the VoLTE coverage provided by the operators is not (ideal) complete, i.e. there are some “holes” of VoLTE coverage.

This work item implemented the conclusion of the study for single radio voice continuity from 5GS to 3G (FS_5G-SRVCC) which is specified in TR 23.756[4]. The main enhancements introduced by this work item are specified in TS 23.216[3].

The architecture of 5G-SRVCC is illustrated in Figure 2-1. A simplified MME function (MME_SRVCC) was introduced to facilitate session transfer (SRVCC) of the voice component to the CS domain. The support of N26 interface and Sv interface is required for the MME_SRVCC.

Figure 1: 5G-SRVCC architecture

The 5G-SRVCC mechanism defined by this work item is an indirect SRVCC from NG-RAN to UTRAN. When an UE moves out of the coverage of NG-RAN while a 5G voice session over IMS (either a normal voice session or an emergency session) is ongoing, a PS to CS handover procedure between 5GS and 3G CS is triggered by the NG-RAN. The 5G-SRVCC procedure including two main parts:

– 5GS to EPS handover using N26 procedure triggered by the NG-RAN.

– PS-CS handover procedure initiated by the selected MME_SRVCC.

No E-UTRAN involved during the whole process. All the PDU sessions is released by the request of AMF at the end of the 5G-SRVCC procedure.

References for global part

[1] SP-180897, Single radio voice continuity from 5GS to 3G.

[2] CP-193014, CT aspect of 5G_SRVCC.

[3] TS 23.216, Single Radio Voice Call Continuity (SRVCC); Stage 2.

[4] TR 23.756, Study for single radio voice continuity from 5G to 3G.

Radio part

In Rel-16, the WI “Single Radio Voice Call Continuity from 5G to 3G” was approved (latest WID in RP-200151). This work item aims to specify the support of SRVCC from 5GS to UTRAN in RAN. More specifically, the main objectives are as follows:

– Inter-RAT measurement to support voice service continuity from 5GS to UTRAN [RAN2, RAN1].

– Specify that the NG-RAN and UE in NR RRC connected mode support the UTRAN cell measurement procedure, e.g. measurement configuration of target UTRAN cells, and the measurement performing and reporting by UE.

– Indirect Inter-RAT handover procedure to support voice service continuity from 5GS to UTRAN [RAN2, RAN3].

– Specify the procedures of SRVCC (including emergency call) in RAN, which includes handover preparation between gNB and AMF, gNB and UE, and Handover execution between UE to RNS etc.

– Signalling of source RAT to target RAT at incoming SRVCC [RAN3].

– UE capability reporting for supporting SRVCC [RAN2, RAN3].

– Specify the transfer of UE capability information between UE, NG-RAN and AMF.

– RRM requirements to support voice service continuity from 5GS to UTRAN [RAN4].

– Requirements of NR handover to UMTS.

– Requirements of NR- UMTS inter-RAT measurements.

The key functionalities are:

– Support of the UTRAN cell measurement procedure for NR node and UE in NR RRC connected mode. A new measurement object for UTRA is defined to include only UTRA-FDD. – The UE is only required to measurement and report the listed cells. Periodic and event triggered (event B1/B2) reporting for UTRA measurement are both supported. The same measurement gap configuration for UTRA is reused in measurement in NR as in LTE.

– Support of inter-RAT handover procedure of SRVCC. MobilityFromNRCommand message is reused for SRVCC from NR to UTRAN. SRVCC to UTRAN is also supported for UEs configured with NR-DC and NE-DC, network can trigger SRVCC to UTRAN procedure directly irrespective of the whether the bearer for the voice call is anchored in SN or MN. When and how to perform the return procedure from UTRAN to NR after the UE completes the voice service depends on UE implementation.

– Support of Signalling of source RAT to target RAT at incoming SRVCC. Add 5G-SRVCC possible into Initial Context Setup Request, HO Request, Path Switch Request Ack. Clarify the source to target transparent container is source RNC to target RNC Transparent Container in 5G-SRVCC. Clarify the target to source transparent container is Target RNC to Source RNC Transparent Container in 5G-SRVCC.

– Support of UE capability reporting for supporting SRVCC, including SRVCC handover capability with FR1/FR2 and TDD/FDD split, and UTRA-FDD band list is also reported.

– RRM Requirements have also been specified, including measurement gap applicability requirement for SRVCC, Measurement capability, CSSF, UMTS inter-RAT measurement requirements and handover requirements for SRVCC.

References for the radio part

[1] R2-2000325 Introduction of SRVCC from 5G to 3G Ericsson, ZTE

[2] R2-2000335 Introduction of SRVCC from 5G to 3G Ericsson

[3] R2-2000542 Introduction of SRVCC from 5G to 3G Huawei, HiSilicon, China Unicom

[4] R2-2000651 Introduction of SRVCC from 5G to 3G China Unicom, Huawei, HiSilicon

[5] R3-194169 Support SRVCC from 5G to 3G Ericsson

[6] R3-194171 Support SRVCC from 5G to 3G Ericsson

[7] R3-200071 Support SRVCC from 5G to 3G Ericsson

[8] R3-200073 Support SRVCC from 5G to 3G Huawei, China Unicom, Ericsson, Nokia, Nokia Shanghai Bell, ZTE, Qualcomm Incorporated

Overall References, for both the radio and the general parts

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=810041,790010,810007,820008,820069,820169,830270,840004,840058,840059

13.1.3 Volume Based Charging Aspects for VoLTE

840066

Volume Based Charging Aspects for VoLTE

VBCLTE

S5

SP-180813

Chen, Ai, China Mobile

Summary based on the input provided by China Mobile in SP-191277.

Based on the Study Item FS_VBCLTE (TR 32.848) which has investigated potential charging requirements and possible mechanisms to support volume based charging for VoLTE, the WI VBCLTE is the enhancement of online and offline charging aspects of volume based charging for VoLTE.

Stage 2 work on WI VBCLTE for TS 32.251 [1] and TS 32.260 [4]:

– Clarify that IMS charging only supports duration based charging for VoLTE.

– Introduce volume based charging for VoLTE in PS offline and online charging.

– Introduce VoLTE Information parameter for volume based charging for VoLTE in PGW-CDR.

– Add Bindings of CDR parameter, Information Element and AVP for VoLTE Information parameter.

Stage 3 work on WI VBCLTE for 32.298 [3] and 32.299 [4]:

– Introduce two new values for Change-Condition AVP to indicate the status of VoLTE service delivery.

– Introduce two new reasons of Cause for Record Closing field in the CDR to indicate the status of VoLTE service delivery.

– Introduce VoLTE Information parameter including Caller Information and Callee Information for volume based charging for VoLTE in PS domain CDRs.

– Introduce VoLTE-Information AVP including Calling-Party-Address AVP and Callee-Information AVP for volume based charging for VoLTE in PS domain online charging messages.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=840066

[1] TS 32.251: "Packet Switched (PS) domain charging"

[2] TS 32.260: "IP Multimedia Subsystem (IMS) charging"

[3] TS 32.298: "Charging Data Record (CDR) parameter description"

[4] TS 32.299: "Diameter charging application"

13.1.4 EVS Floating-point Conformance for Non Bit-Exact

820001

EVS Floating-point Conformance for Non Bit-Exact

EVS_FCNBE

S4

SP-180983

Fabrice, Plante, Intel

Summary based on the input provided by Intel in SP-191328.

The EVS_FCNBE work item provides improvements related to the 3GPP EVS codec: this codec is standardized in three code versions such that it can be implemented on processors with either fixed-point (TS 26.442, TS 26.452) or floating-point arithmetic (TS 26.443). Implementations can be conformance-tested using “bit-exact” methods that have been specified already when the EVS codec was first standardized. These methods are suitable for fixed-point implementations but their applicability is limited for floating-point implementations. EVS_FCNBE provides methods which enable conformance testing also for “non bit-exact” floating-point implementations.

During Rel-15, the FS_EVS_FCNBE study item investigated tools, conformance process, and criteria for EVS floating-point non bit-exact conformance, and documented in TR 26.843 [1] several recommendations. Based on the agreed conclusions and recommendations of TR 26.843, the EVS_FCNBE work item conducted normative work on TS 26.444 to introduce the non bit-exact conformance process and criteria in the CR 26.444-0027.

The conformance process uses three specific tests:

– Decoder test comparing the implementation decoder with TS 26.443 decoder.

– Encoder test comparing the implementation encoder with TS 26.443 encoder.

– MOS-LQO verification comparing the coder implementation with TS 26.442 coder.

These three tests allow to compare the implementation with the reference floating point code in TS 26.443, and interoperability with the fixed-point code in TS 26.442. All three tests shall pass for the implementation to be declared conformant.

The decoder test relies on a set of signal-based metrics (RMS, SNR, and Spectral Distortion). The encoder test uses a loudness metric. The MOS-LQO test uses a set of metrics using objective quality measurements.

To define a range of acceptable variation for the various metrics, a set of 10 reference implementations (based on mainstream compilers and platforms) has been used to define reference values.

Annex B of CR 26.444-0027 provides details on the tests as well as the conformance process and criteria.

The results obtained during the course of the normative work indicate that this conformance process correctly discriminates implementations with functional code changes and aggressive compiler optimization.

References

[1] TR 26.843 “Study on non-bit-exact conformance criteria and tools for floating-point EVS codec”

List of related CRs: select "TSG Status = Approved" in https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=820001

13.1.5 Media Handling Extensions for 5G Conversational Services

810040

Media Handling Extensions for 5G Conversational Services

5G_MEDIA_MTSI_ext

S4

SP-180663

Oyman, Ozgur, Company: Intel

Summary based on the input provided by Intel in SP-200036.

During Rel-15, the FS_5G_MEDIA_MTSI study item investigated media handling aspects of conversational services in 5G, and documented in TR 26.919 several recommendations on Multimedia Telephony Service over IMS (MTSI) in TS 26.114 around media rate adaptation, NR access and profiles for 5G deployments.

Based on the agreed conclusions and recommendations of TR 26.919, 5G_MEDIA_MTSI_ext conducted normative work, mostly on TS 26.114, to introduce the following functionality:

– For media rate adaptation, the CR 26.114-0436 [2] recommended additional speech and video adaptation capabilities based on access network bitrate recommendation (ANBR) (a.k.a. RAN-assisted codec adaptation) support. In particular, this CR makes ANBR-triggered speech adaptation a recommended feature in MTSI clients for Rel-16 and beyond. Moreover, it provides additional recommendations for MTSI receivers to generate CMR/RTCP-APP (for speech) and TMMBR (for video) and for MTSI senders to generate TMMBN (for video) messages in response to receiving ANBR information.

– On profiles for 5G deployments, the CR 26.114-0438 [3] defined the constrained MTSI client terminal to address codec requirements for IMS/VoLTE/ViLTE/VoNR conversational services in the low end 5G verticals such as wearables and IoT. In particular, this CR relaxed the Rel-15 speech and video codec requirements for these constrained terminals, e.g., resulting in optional support for super-wideband for speech and HEVC for video, exceptionally only for this special category of constrained terminals (support for SWB for speech and HEVC for video is otherwise mandatory for Rel-15 and beyond).

– To realize further RAN-assisted codec adaptation enhancements, the CR 26.114-0461 [4] and CR 26.114-0480 [5] introduced ANBR capability signalling into MTSI. In particular, the CRs standardized a new SDP attribute ‘anbr’ to enable end-to-end signaling and coordination of ANBR capabilities (both at the radio level and application level) across the UEs, Access Networks, and PCRF/PCF. According to the adopted solution, the MTSI client in terminal supporting "anbr" signals this attribute in the SDP only if: (i) MTSI client in terminal supports ANBR at the application layer, including the use of ANBR with dynamic bitrate adaptation. (ii) The UE of the MTSI client in terminal is capable of RAN-assisted codec adaptation at the radio layer, including the ability to query and receive ANBR information (both downlink and uplink ANBR) from its eNB/gNB. (iii) The P-CSCF has indicated to the UE of the MTSI client in terminal its ability to handle this SDP attribute through the respective SIP registration procedures specified in TS 24.229 via the corresponding feature capability indicator g.3gpp.anbr.

– The low and ultra-low latency of 5G will enable new types of use cases with real-time communication and interaction needs where it will be desirable to not only have voice, text and video calling connectivity but also delivery of any kind of data stream and real-time interaction within the same IMS multimedia session. This is already enabled as part of the IMS-based Tele-Presence service in TS 26.223 toward the exchange of CLUE messages and has been introduced to MTSI in TS 26.114 as part of this work item to provide a generic and flexible data channel support for IMS-based multimedia telephony. In particular, CR 26.114-0496 [6] adds necessary UNI procedures to support MTSI data channel based on WebRTC data channel and web scripting techniques as a new MTSI media. This provides a generic and flexible data channel for MTSI in TS 26.114 that allows both UE-to-UE and UE-to-network generic data transfers, in addition to and in parallel with the existing MTSI media such as audio, video, and text. Accordingly, TS 26.223 was also updated via CR 26.223-0013 [7] to align the data channel support of a Tele-Presence (TP) UE with that specified in MTSI.

References

[1] Tdoc SP-180663, New WID on “Media Handling Extensions for 5G Conversational Services” (5G_MEDIA_MTSI_ext)

List of related CRs: select "TSG Status = Approved" in https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=810040

This includes:

[2] Tdoc SP-180975, CR 26.114-0436, “Recommendations on Media Rate Adaptation”

[3] Tdoc SP-180975, CR 26.114-0438, “MTSI Client Profiles”

[4] Tdoc S4-190489, CR 26.114-0461, “Signaling of ANBR Capabilities”

[5] Tdoc S4-190603, CR 26.114-0480, “Updates on ANBR Capability Signaling”

[6] Tdoc S4-200266, CR 26.114-0496, “Addition of MTSI Data Channel Media”

[7] Tdoc S4-200269, CR 26.223-0013, “Alignment with MTSI on IMS Data Channel Support”

13.1.6 VR QoE metrics

840000

VR QoE metrics

VRQoE

S4

SP-190331

Gunnar HEIKKILÄ , Ericsson

Summary based on the input provided by Ericsson in SP-200128.

The experienced Virtual Reality (VR) quality is dependent on a good service implementation as well as a fast and consistent transport network. To help service providers and operators to measure and optimize aspects related to the delivered VR service quality, specific VR-related metrics are useful.

The VRQoE Work Item added the following functionality:

– Defined VR metrics observation points.

– Metrics describing the characteristics of the VR device, such as resolution, FOV etc.

– Metrics describing the interaction delay, related to the time between head movements and update of the visible content.

– Extensions to the DASH Metrics configuration and reporting to support the new metrics.

Also, the following metrics have been added into TS 26.118 [1]:

– Comparable quality viewport switching latency: Reports the delay from head movement until the media quality is restored to a similar quality level as before the move.

– Rendered viewports: Reports where the user mostly looks during the VR session.

– VR device information: Reports characteristics for the VR device.

The metrics are building on and extending the existing metrics in TS 26.247 [2], and are well aligned with the current proposal in MPEG [3]. Furthermore, a requirement has been added to TS 26.234 [4] specifying that a VR-capable PSS client should also support these metrics.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=840000

[1] TS 26.118 " Virtual Reality (VR) profiles for streaming applications"

[2] TS 26.247 "Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)"

[3] ISO/IEC CD 23090-6 "Immersive Media Metrics"

[4] TS 26.234 "Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs"

13.1.7 Media Handling Aspects of RAN Delay Budget Reporting in MTSI

810039

Media Handling Aspects of RAN Delay Budget Reporting in MTSI

E2E_DELAY

S4

SP-180662

Oyman, Ozgur, Company: Intel

780022

Study on E2E_DELAY

FS_E2E_DELAY

S4

SP-170837

Oyman, Ozgur, Company: Intel,

810001

Stage 2 of E2E_DELAY

E2E_DELAY

S4

SP-180662

Oyman, Ozgur, Company: Intel

830004

CT Aspects of E2E_DELAY

E2E_DELAY

ct

CP-190193

Luetzenkirchen, Thomas, Intel

830066

CT1 Aspects of E2E_DELAY

E2E_DELAY

C1

CP-190193

Luetzenkirchen, Thomas, Intel

830067

CT3 Aspects of E2E_DELAY

E2E_DELAY

C3

CP-190193

Luetzenkirchen, Thomas, Intel

830068

CT4 Aspects of E2E_DELAY

E2E_DELAY

C4

CP-190193

Luetzenkirchen, Thomas, Intel

Summary based on the input provided by Intel in SP-190322.

This summary reports on the normative specification progress accomplished during the course of the E2E_DELAY work item [1]. The related agreed CRs can be found in Tdocs S4-181176 (CR 26.114-0441) [2], S4-181452 (CR 26.114-0443) [3], S4-190167 (CR 26.114-0448) [4], S4-190497 (CR 26.114-0462) [5] and S4-190498 (CR 26.114-0463) [6].

RAN delay budget reporting is specified in TS 36.331 for E-UTRA and TS 38.331 for NR. RAN delay budget reporting through the use of RRC signalling to eNB / gNB allows UEs to locally adjust air interface delay. Based on the reported delay budget information, a good coverage UE on the receiving end (i.e., the UE that contains the MTSI receiver) can reduce its air interface delay, e.g., by turning off CDRX or via other means. This additional delay budget can then be made available for the sending UE (i.e., the UE that contains the MTSI sender), and can be quite beneficial for the sending UE when it suffers from poor coverage. When the sending UE is in bad coverage, it would request the additional delay from its local eNB / gNB, and if granted, it would utilize the additional delay budget to improve the reliability of its uplink transmissions in order to reduce packet loss, e.g., via suitable repetition or retransmission mechanisms, and thereby improve end-to-end delay and quality performance.

While RAN-level delay budget reporting as defined in TS 36.331 and TS 38.331 allows UEs (i.e., MTSI sender and MTSI receiver) to locally adjust air interface delay, such a mechanism does not provide coordination between the UEs on an end-to-end basis. To alleviate this issue, this work item defined a new RTCP feedback message type in clause 7.3.8 of TS 26.114 to realize the following capabilities on signalling of Delay Budget Information (DBI) across UEs as per CRs 26.114-0443 in Tdoc S4-181452, 26.114-0448 in Tdoc S4-190167 and 26.114-0462 in Tdoc S4-190497: (i) an MTSI receiver can indicate available delay budget to an MTSI sender, and (ii) an MTSI sender can explicitly request delay budget from an MTSI receiver. Such RTCP-based signaling of DBI can also be used by an MTSI receiver to indicate delay budget availability created via other means such as jitter buffer size adaptation. The recipient UE of the RTCP feedback message carrying DBI may then use this information in determining what delay budget adjustments it may request from its eNB / gNB over the RAN interface, e.g. by using RRC signalling based on UEAssistanceInformation as defined in TS 36.331 and TS 38.331.

In addition, the work item specified a few further media handling aspects of RAN delay budget reporting for MTSI in TS 26.114 to address the following:

1. SDP-based exchange of RAN capabilities in regards to delay budget reporting, this is specified in clause 6.2.8 and Annex V.3 of TS 26.114 as per CR 26.114-0441 in Tdoc S4-181176 and CR 26.114-0463 in Tdoc S4-190498. Accordingly, an MTSI client supporting DBI can offer this capability in SDP for all media streams containing speech and/or video by including the a=rtcp-fb attribute with the DBI type under the relevant media line scope as expressed with the parameter 3gpp-delay-budget.

2. Recommendations on when and how the UEs in an MTSI session should use RAN-based delay adjustment mechanisms in an end-to-end fashion also accounting other factors such as local radio conditions, various RAN capabilities and configurations, jitter buffer considerations, and UE battery constraints. These are provided as part of the informative signalling flows in Annex V of TS 26.114, as per CR 26.114-0443 in S4-181452.

3. Recommendations on when and how the various kinds of end-to-end quality metrics and other relevant information in the MTSI client could be used to trigger RAN delay budget reporting. These are provided as part of the informative signalling flows in Annex V of TS 26.114, as per CR 26.114-0443 in S4-181452.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=810039,780022,810001,830004,830066,830067,830068

[1] Tdoc SP-180662, New WID on “Media Handling Aspects of RAN Delay Budget Reporting in MTSI” (E2E_DELAY)

[2] Tdoc S4-181176, CR 26.114-0441, “Signaling of Delay Budget Information”

[3] Tdoc S4-181452, CR 26.114-0443, “Recommendations on use of RAN Delay Budget Reporting in MTSI”

[4] Tdoc S4-190167, CR 26.114-0448, “DBI Signaling Recommendations”

[5] Tdoc S4-190497, CR 26.114-0462, “Additional DBI Signaling Recommendations”

[6] Tdoc S4-190498, CR 26.114-0463, “SDP Examples on DBI Signaling”

[7] TS 36.331: "E-UTRA; Radio Resource Control (RRC); Protocol specification".

[8] TS 38.331: "NR; Radio Resource Control (RRC); Protocol Specification".

13.1.8 Removal of H.263 and MPEG-4 Visual from 3GPP Services

Summary based on the input provided by Qualcomm in SP-200801.

This work item has removed any normative statements related to H.263 and MPEG-4 Visual from Rel-16 specifications (including TS 26.114, TS 26.140, TS 26.234, TS 26.346 and TS 26.244).

H.263 was a state-of-the art codec in the last millennium and made mobile video possible and an actual reality. Many 3GPP specs adopted H.263, used for the first mobile video deployments. However, more than 20 years later, this format became obsolete and as such was removed from Rel-16 onwards.

In 2012 (Rel-11), 3GPP already addressed to change the status of H.263 and MPEG-4 Video in several specifications, but did not fully remove the technology for all services. Some leftover H.263 related statements remained, as in TS 26.140. MPEG-4 Visual did not have any status in any spec, but many leftovers still.

"Retiring" older codecs is needed due to the impact of codecs on hardware and/or softwareincluding area size, design and testing, and then on the cost. Supporting such codecs on 5G device would have reduced the available space for other, newer, codecs and technologies. One can note that, despite a phone’ OS provides a software codec for these formats, not all devices use this OS (e.g. watches do not use it) and hence would have required custom H.263 integration. Similar issues apply to MPEG-4 Visual.

The Technical Report is available in TR 26.928.

References

[1] Tdoc SP-200400, “Removal of H.263 and MPEG-4 Visual from 3GPP Services” (RM_H263_MP4V)

13.2 Streaming

13.2.1 Enhancement of LTE for Efficient delivery of Streaming Service

800008

Enhancement of LTE for Efficient delivery of Streaming Service

eLSTR

S1

SP-180322

Xia, Xu, China Telecom

740001

Study on eLSTR

FS_eLESTR

S1

SP-160960

China Telecommunications, XIA Xu

800054

Stage 1 of eLSTR

eLSTR

S1

SP-180322

Xia, Xu, China Telecom

Summary based on the input provided by China Telecom in SP-200XYZ.

Mobile network operators are deciding to use LTE-base system to deliver great stream communication services (eg. Video/HD/AR/VR). As the great stream communication service (eg. video/HD/AR/VR)is a ideal type business to improve operator , but in the reality network, we(operators) find very little users to consume these services on LTE rather to use free wifi. The key factor of enabling the “anywhere, anytime” reachability is to reduce to cost of resource to consume video/HD/AR/VR services. Ideally, RAN may request delay tolerate data from GW or cache or any other entity when RAN has spare resource to save the network transmission resource. However, currently this mechanism is not successfully supported over LTE. The mechanism for OTT video may also need to be studied and defined on backhaul interfaces and potentially SGi interface.

This technical report is to study potential service requirements for optimization of both Over-The-Top and operator managed streaming service considering possible use cases e.g. caching, content-aware service delivery, delay tolerate delivery, local streaming transmission etc. Operators see benefit to include it in a new study.

Support of stream service have been accepted in TS22.115 [2] and TS22.278 [3]. No stage 2 and stage 3 changes were needed.

The work item eLSTR provides the stage 1 specifications to include

1) Identifying the potential new service scenarios and requirements for video/HD/AR/VR services over LTE-based system, eg. delay tolerant content delivery; UE caching; Video transmission optimization(video-aware by RAN);

2) Identifying related policy, charging and authentication requirements.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=800008,740001,800054

[1] Tdoc SP-180322, “Enhancement of LTE for Efficient delivery of streaming service (eLSTR)”

[2] TS 22.115 V16.3.0 (2019-06); “Service aspects; Charging and billing”

[3] TS 22.278 V16.3.0 (2019-06); “Service requirements for the Evolved Packet System (EPS)”

13.2.2 Enhancements to Framework for Live Uplink Streaming

800001

Enhancements to Framework for Live Uplink Streaming

E_FLUS

S4

SP-180285

Lo, Charles, Qualcomm

Summary not provided

13.2.3 Media streaming architecture

820002

Media streaming architecture

5GMSA

S4

SP-180984

Frédéric GABIN, Ericsson

840001

5G Media Streaming Stage 3 (5GMS3)

5GMS3

S4

SP-190464

Paul Szucs, Sony

Summary based on the input provided by Sony Europe B.V. in SP-200848.

This summary reports on the normative specification progress accomplished during the course of the 5GMS3 work item [1]. Three new specifications have been produced as a result of the work in 5GMS3, namely on the following aspects:

– Speech and audio profiles, in TS 26.117 [2];

– Profiles, Codecs and Formats, in TS 26.511 [3];

– Protocols, in TS 26.512 [4].

One change request on the existing specification TS 26.247 [5] has also been produced, which adds the specification of the usage of the Common Media Application Format (CMAF) for segmented media as the baseline container format for 5GMS downlink streaming services.

The work item 5GMS3 provides the stage 3 specifications to enable the realization of media streaming services based on the 5G Media Streaming Architecture, specified in TS 26.501 [6]. The stage 3 specifications cover speech, audio and video media formats and profiles, protocols – which are specified in accordance with the REST/HTTP principles adopted by the CT groups – and the ingest of media content into the 5GMS for downlink unicast content delivery services.

References

List of related CRs: select "TSG Status = Approved" in:
https://portal.3gpp.org/ChangeRequests.aspx?q=1&workitem=820002,840001

[1] Tdoc SP-180322, “Enhancement of LTE for Efficient delivery of streaming service (eLSTR)”

[2] TS 22.115 V16.3.0 (2019-06); “Service aspects; Charging and billing”

[3] TS 22.278 V16.3.0 (2019-06); “Service requirements for the Evolved Packet System (EPS)”

[1] Tdoc SP-190464, “3GPP™ Work Item Description – 5G Media Streaming stage 3 (5GMS3)”

[2] TS 26.117; 5G Media Streaming (5GMS); Speech and audio profiles

[3] TS 26.511; 5G Media Streaming (5GMS); Profiles, Codecs and Formats

[4] TS 26.512; 5G Media Streaming (5GMS); Protocols

[5] TS 26.247; Transparent end-to-end Packet-switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH) (Release 16)

[6] TS 26.501; 5G Media Streaming (5GMS); General description and architecture