20 All other Release 16 Features

21.9163GPPRelease 16Release descriptionTS

20.1 Service Interactivity

770020

Service Interactivity

SerInter

S4

SP-170796

Lo, Charles, Qualcomm

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

This summarizes the progress of the normative specifications accomplished during the course of the SerInter work item [1]. The related agreed CRs can be found in the Tdocs [2], [3], [4], [5] and [6].

The service interactivity feature enables dynamic user engagement and resulting auxiliary content presentation during the consumption of a streaming service or content item, received over unicast or broadcast. Interactive service capabilities can be further personalized to the end user consuming the service. Examples of service interactivity functionality include voting, rating, purchasing, online chats, and reception of targeted advertisements and other content, in real-time during the viewing of a streaming program.

Technical functionality to enable and support dynamic and personalized service interactivity are added to TS 26.247 [7], TS 26.346 [8] and TS 26.347 [9] and comprise the following components:

  • Signaling of upcoming interactivity events to native or Web app based interactivity applications. Such interactivity event signaling, which could be sent at specific and potentially arbitrary times during the consumption of an associated 3GPP User Service, contain metadata of upcoming interactivity events and which enable an interactivity application to perform its intended task. The interactivity event signaling is defined by the DASH Industry Forum upon request from 3GPP, and is implemented as either a DASH Event stream, or as samples of a ISOBMFF timed metadata track.
  • Processing model and rules for the 3GP-DASH Client to extract metadata contained in interactivity event signaling.
  • WebIDL APIs exposed by the 3GP-DASH Client to an interactivity application, for the subscription by and delivery to, the application, of interactivity event metadata.

(The above functionalities are defined by the DASH Industry Forum, based on request from 3GPP to support the Service Interactivity work item, in the specification “DASH Player’s Application Events and Timed Metadata Processing Model and APIs” [10].)

  • For DASH-formatted streaming services, signaling via the DASH MPD of the intended measurement and reporting of interactivity-related usage by the user/device. This signaling enables the service provider to: a) specify the parameters and criteria regarding interactivity consumption reporting; b) specify the type of interactivity usage report to be submitted by the DASH client, and c) employ either random or selective control of the user/device population to perform the reporting. In addition, the XML-based interactivity usage report format and HTTP POST based reporting protocol are defined. The above functionality are specified in TS 26.247 [7].
  • Clarifications to the MBMS APIs specification TS 26.347 [9] that an MBMS-Aware Application providing an auxiliary service interactivity feature is expected to acquire, from the MBMS client, a multiplicity of Application User Services. These Application User Services provide the media content of the DASH-over-MBMS application service as well as media content and/or metadata of adjunct application service(s) that provide the service interactivity functionality.

An architecture illustrating the high level interactions between the relevant entities, in the delivery of DASH-formatted content and interactivity event signaling from the network to the 3GP-DASH Client, forwarding of event signaling data from the 3GP-DASH Client to the interactivity application, and subsequent execution by the application of its interactivity task, is shown in the diagram below, which is copied from TR 26.953 [11].

References

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

[1] Tdoc SP-170796, “New WID on Service Interactivity” (SerInter).

[2] Tdoc S4-180854, CR 26.247-0145, “Signaling and Reporting of Interactivity Usage in 3GP-DASH”.

[3] Tdoc S4-190182, CR 26.346-0625, “TS 26.346 Changes Pertaining to Service Interactivity Feature”.

[4] Tdoc S4-190196, CR 26.347-0006, “Changes Pertaining to Service Interactivity”.

[5] Tdoc S4-191314, CR 26.247-0163, “Support for Service Interactivity via Event Signaling and DASH APIs”.

[6] Tdoc S4-191318, CR 26.346-0629, “Service Interactivity Support in DASH-over-MBMS Service”.

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

[8] TS 26.346 “Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs”.

[9] TS 26.347 “Multimedia Broadcast/Multicast Service (MBMS); Application Programming Interface and URL”.

[10] DASH Industry Forum specification “DASH Player’s Application Events and Timed Metadata Processing Model and APIs”.

[11] TR 26.953 “(MBMS and PSS) Interactivity Support for 3GPP-Based Streaming and Download Services”.

20.2 RTCP Verification for Real-Time Services

850003

RTCP Verification for Real-Time Services

RTCPVer

S4

SP-190639

Burman, Bo, Ericsson LM

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

This summarizes the progress of the new, normative specification accomplished during the course of the RTCPVer work item [1].

The RTCP verification for real-time services feature enables verification of the most important parts of the RTP/RTCP and SRTP/SRTCP protocols used by current 3GPP conversational and real-time services.

Technical functionality to enable and support this verification are added to a new TS 26.139 [2] and comprise the following aspects:

– Explicitly allowing for and describing examples of different, possible test architectures.

– Test cases needed to ensure an adequate level of RTP operation and RTP stream monitoring.

– Test methods capable to verify that information contained in the RTP header and in RTCP is correct and consistent with the observed characteristics of the related RTP streams:

o Between RTP/RTCP within the scope of a single RTP stream (e.g. between an RTP stream and the corresponding RTCP reporting from the remote party, or between an RTP stream and the corresponding RTCP metadata, e.g. for sampling clock accuracy compensation between RTP sender and RTP receiver).

o Between RTP/RTCP across RTP streams in the same RTP session (e.g. between sent and received RTP streams, or between audio RTP streams and video RTP streams).

– Requirements on what constitutes acceptable RTP/RTCP protocol field values, including RTP payload header and RTP payload length, based on the observed characteristics of the related RTP streams.

– A method for an RTP/RTCP implementation to announce that it has passed the necessary tests and conforms to the new specification at call setup and during the call.

References

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

[1] Tdoc SP-190639, "New WID on ‘RTP/RTCP Verification for Real-Time Services’" (RTCPVer).

[2] TS 26.139 "Real-time Transport Protocol (RTP) / RTP Control Protocol (RTCP) verification procedures".

20.3 Stage-3 SAE Protocol Development for Rel16

820042

Stage-3 SAE Protocol Development for Rel16

SAES16

C1

CP-183088

Aghili, Behrouz, InterDigital Communications

820038

IMS Stage-3 IETF Protocol Alignment

IMSProtoc16

C1

CP-183084

Leis, Peter, Nokia

The description of these WIDs has not changed at all from its predecessors, e.g. SAES6, SAES5, etc.

The contents of the WID are exact copies of the ones before as it is an “ongoing” WID at CT1, meaning that it keeps existing for every new release until CT1 makes a decision that it is no longer needed. The only thing that happened this time, i.e. for the Rel-16 version, was that we decided to align the “x” in SAESx with the corresponding release so, as of Rel-16, the WID is called SAES16 and it will be SAES17 for Rel-17.

Same with IMSProtocolx.

References

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

20.4 Reliable Data Service Serialization Indication

840017

Reliable Data Service Serialization Indication

RDSSI

S2

SP-190446

Michael Starsinic, Convida Wireless LLC

Summary based on the input provided by Convida Wireless LLC in SP-200057.

This work item enhances the Reliable Data Service by adding support to the Reliable Data Service for indicating the serialization format of the data that will be sent in a NIDD session

The Reliable Data Service was added to EPS in Rel-14 as part of the “Extended architecture support for Cellular Internet of Things” work item and added to 5GS in Rel-16 as part of the “Cellular IoT support and evolution for the 5G System” work item.

The work was motivated by an LS from oneM2M and resulted in TS 23.682, TS 23.501, and TS 23.502 CRs which added support to the Reliable Data Service for indicating the serialization format of the data that will be sent in a NIDD session. The CRs also updated the NIDD Configuration procedure so that the SCS/AS can indicate to the SCEF or NEF the serialization format(s) that are supported by the SCS/AS.

References

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

[1] S2-1903031, NIDD RDS API enhancement, LS from oneM2M Technical Plenary to CT3

[2] S2-1903039, LS Reply on NIDD RDS API enhancement, LS from CT3 to SA2 and oneM2M Technical Plenary

[3] S2-1906025, Adding Support for Indicating Serialization Format in RDS, TS 23.682 CR, Convida Wireless LLC, Intel, Deutsche Telekom, AT&T

[4] S2-1906027, Adding Support for Indicating Serialization Format in RDS, TS 23.502 CR, Convida Wireless LLC, Intel, Deutsche Telekom, AT&T

[5] S2-1906162, Adding Support for Indicating Serialization Format in RDS, TS 23.501 CR, Convida Wireless LLC, Intel, Deutsche Telekom, AT&T

20.5 Shared Data Handling on Nudm and Nudr

800046

Shared Data Handling on Nudm and Nudr

Shared_Data

C4

CP-181136

Wiehe, Ulrich, Nokia

Summary based on the input provided by Nokia, Nokia Shanghai Bell in CP-200143.

The problem of potential signalling floods on Nudm and Nudr service based interfaces that are caused by (identical) subscription data changes for a huge set of subscriptions (e.g. MTC devices) is solved by the concept of shared data.

Subscription data that are retrieved by serving nodes (AMF, SMF, SMSF) from the UDM (and by the UDM from the UDR) may contain a subset that is shared by a huge number of subscriptions (e.g. 1000 specific MTC devices). A simple example for such a subset is e.g. a subscribed periodic registration time with a value of 300 seconds. When the operator decides to modify the value for all these MTC devices to e.g. 400 seconds, a single notification per serving node is sent to update the shared subset; there is no need to send 1000 notifications addressing each single subscription.

The solution is a pure stage 3 signalling optimization issue and is not based on specific stage1 or stage 2 requirements.

CT4#84 decided to implement the solution already in Rel-15.

References

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

Impacted TSs:

TS 29.503: "Unified Data Management Services".

TS 29.504: "5G System; Unified Data Repository Services; Stage 3".

TS 29.505: "5G System; Usage of the Unified Data Repository Services for Subscription Data; Stage 3".

Main CRs:

29.503 CR 0008r4 C4-186497

29.504 CR 0010r1 C4-187507

29.505 CR 0019r1 C4-187506

20.6 New Services and Markets Technology Enablers – Phase 2

790001

New Services and Markets Technology Enablers – Phase 2

SMARTER_Ph2

S1

SP-180589

Li, Alice, Vodafone

Summary based on the input provided by Vodafone in SP-200224.

There are strong interests among 3GPP network operators not only on addressing various existing and emerging markets and services to increase and diversify revenue streams, but also on enabling new business models and different operational schemes to maximise the use of the operators’ networks.

TS 22.261 [1] specifies the requirements that define a 5G system in order to support new deployment scenarios to address diverse market segments, while the requirements for 5G E-UTRA-NR Dual Connectivity in E-UTRAN connected to EPC (i.e. “option 3”) are included in TS 22.278 [2]. This WI allows refinement of the identified stage 1 requirements in both specifications, including clarifications and extension due to the stage 2 developments in other WGs.

The clarifications and alignments are made with stage 2/3 progress in other WGs on the requirements carried forward from Release 15. The main updates include:

  • For the 5G system service requirements specified in TS 22.261
    • A statement is added to the Scope to clarify that TS 22.261 provides requirements related to a 5G Core, i.e., specifically excluding Option 3.
    • Clarifications are added on the performance requirements for low-latency and high-reliability scenarios.
    • Clarifications are added on unified access control requirements.
    • Support of legacy USIM in 5G is added.
    • Clarifications are added on communication service availability and reliability.
    • Alignments are added on higher-accuracy positioning.
  • For the requirements for 5G E-UTRA-NR Dual Connectivity in E-UTRAN connected to EPC (i.e. “option 3”) specified in TS 22.278
    • A statement is added to the Scope to clarify that TS 22.278 provides requirements related to 5G Option 3.
    • Added the 5G URLLC KPIs from Release 15 onwards to align with stage 2 agreements.
    • New service requirements are added corresponding to the enhancements developed in CIoT to align with stage2/3 progress.
    • Added the 5G requirements on service continuity.
    • Added the 5G requirements on context aware network.

References

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

[1] TS 22.261, "Service requirements for the 5G system"

[2] TS 22.278, "Service requirements for the Evolved Packet System (EPS)"

20.7 Ambient noise test methodology for evaluation of acoustic UE performance

870010

Ambient noise test methodology for evaluation of acoustic UE performance

ANTeM

S4

SP-200051

Jan Reimes, HEAD acoustics GmbH

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

The work item ANTeM [1] was subsequently initiated to the feasibility study FS_ANTeM [2] in order to follow the conclusion of TR 26.921 [3] regarding handset speech quality testing under ambient noise conditions. Results of the round robin test conducted in FS_ANTeM indicated that an alternative noise field simulation provides test results equivalent to the currently specified method, while having a more efficient equalization procedure and less variance across labs at the same time. To include this new method in TS 26.132 [4], a corresponding change request [5] was agreed.

For speech quality evaluation of UEs under ambient noise conditions, the technical specification TS 26.132 [4] provides test methodologies. For measurements in handset mode, the background noise playback system according to ETSI ES 202 396-1 [6] is used. Within the study item FS_ANTeM, the applicability of the more recent ambient noise simulation according to ETSI TS 103 224 [7] was investigated, which provides the advantage of a fully automated calibration routine.

The so-called "flexible configurations" of ETSI TS 103 224 [7] were found to be useful, since they can be used in conjunction with the currently specified binaural noise types of TS 26.132 [4] to provide backward compatibility with the currently used simulation according to ETSI ES 202 396-1 [6].

The equivalency of the two noise field simulation systems was also shown by almost identical measurement results in the round robin test (comprehensive results of this study are provided in TR 26.921 [3]). The resulting CR [5] specified the flexible configurations of ETSI TS 103 224 [7] as an additional and preferred simulation method.

References

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

[1] S4-200192: "New WID on Ambient noise test methodology for evaluation of acoustic UE performance".

[2] S4-181230: "New SID on ambient noise test methodology for acoustic performance evaluation of UEs".

[3] TR 26.921: "Investigations on ambient noise reproduction systems for acoustic testing of terminals".

[4] TS 26.132: "Speech and video telephony terminal acoustic test specification".

[5] S4-200305: "Alternative noise field simulation method for terminal testing" (CR 0102 to TS 26.132).

[6] ETSI ES 202 396-1: "Speech and multimedia Transmission Quality (STQ); Speech quality performance in the presence of background noise; Part 1: Background noise simulation technique and background noise database".

[7] ETSI TS 103 224: "Speech and multimedia Transmission Quality (STQ); A sound field reproduction method for terminal testing including a background noise database".

20.8 KPI reporting

810031

Enhancement of performance assurance for 5G networks including network slicing

5G_SLICE_ePA

S5

SP-190247

Xiaowei Sun (China Mobile)

850055

Overall aspects of 5G_SLICE_ePA

5G_SLICE_ePA

S5

SP-190247

Xiaowei Sun (China Mobile)

850029

KPI reporting

5G_SLICE_ePA-KPI

S5

SP-190881

ZHU, Weihong, ZTE Corporation

Summary based on the input provided by ZTE in SP-200520.

The work item KPI reporting is the building block of work item 5G_SLICE_ePA (Enhancement of performance assurance for 5G networks including network slicing), it defined the use cases and requirements of KPI reporting, and enhanced the performance measurement job control related operations, performance measurement control NRM fragment and KPI template to enable the capability of KPI reporting.

The work item KPI reporting finished the enhancement on the performance measurement mechanism to enable the capability of KPI reporting, which includes:

– add the use cases and requirements of KPI reporting

– enhance the performance assurance Management Service (MnS) to support KPI collection and reporting

– enhance the KPI template and definitions to support KPI collection and reporting

– enhance the performance measurement control NRM fragment to support KPI collection and reporting

The work item resulted in a number of CRs on TS 28.550, 28.554, 28.622 and 28.623.

References

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

[1] WID: SP-190881

[2] CRs: S5-196410, S5-196748, S5-197571, S5-197572, S5-197575, S5-201522, S5-201581, S5-201582