Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TR 23.700-60  Word version:  18.0.0

Top   Top   None   None   Next
1…   5…

 

1  Scopep. 15

The Technical Report studies key issues, solutions and conclusions on the support of advanced media services, e.g. High Data Rate Low Latency (HDRLL) services, AR/VR/XR services, and tactile/multi-modality communication services. The objectives include:
Enhancements for supporting multi-modality service:
  • Study whether and how to enable delivery of related tactile and multi-modal data (e.g. audio, video and haptic data related to a specific time) with an application to the user at a similar time, focusing on the need for policy control enhancements (e.g. QoS policy coordination).
Enhancements of network exposure to support interaction between 5GS and application:
  • Study whether and how interaction between AF and 5GS is needed for application synchronization and QoS policy coordination among multiple UEs or between multiple QoS flows per UE.
  • Study exposure of 5GS QoS information (e.g. QoS capabilities) and network conditions to the Application to enable quick codec/rate adaptation help to provide desired QoE (e.g. such as assist in alleviating 5GS congestion).
Study whether and how the following QoS and policy enhancements for XR service and media service transmission are performed:
  • Study the traffic characteristics of media service enabling improved network resources usage and QoE.
  • Enhance QoS framework to support PDU Set granularity (e.g. video/audio frame/tile, Application Data Unit, control information), where a PDU Set consists of PDUs that have the same QoS requirements.
  • Support differentiated QoS handling considering different importance of PDU Sets. e.g. eligible drop packets belong to a less important PDU Set to reduce the resource wasting.
  • Whether and how to support uplink-downlink transmission coordination to meet RTT (Round-Trip Time) latency requirements between UE and N6 termination point at the UPF.
  • Potential policy enhancements to minimize the jitter, focusing on i.e. requirement provisioning from AF, extension of PCC rule.
Study potential enhancements of power management considering traffic pattern of media services:
  • Power saving enhancement e.g. support trade-off of throughput/latency/reliability considering device battery life, whether and how to enhance CDRX, considering XR/media traffic pattern.
Up

2  Referencesp. 15

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
TS 23.501: "System Architecture for the 5G System (5GS); Stage 2".
[3]
TS 23.502: "Procedures for the 5G System; Stage 2".
[4]
TS 23.503: "Policy and charging control framework for the 5G System (5GS); Stage 2".
[5]
TS 22.261: "Service requirements for the 5G system; Stage 1".
[6]
TR 22.847: "Study on supporting tactile and multi-modality communication services; Stage 1".
[7]
IEEE SA P1918.1: "Tactile Internet: Application Scenarios, Definitions and Terminology, Architecture, Functions, and Technical Assumptions", https://standards.ieee.org/project/1918_1.html.
[8]
TS 38.300: "NR and NG-RAN Overall Description; Stage 2".
[9]
RFC 3550:  "RTP: A Transport Protocol for Real-Time Applications", STD 64, July 2003.
[10]
RFC 3711:  "The Secure Real-time Transport Protocol (SRTP)", March 2004.
[11]
draft-ietf-avtext-framemarking-xx:  "IETF experimental draft-ietf-avtext-framemarking-13 - Frame Marking RTP Header Extension".
[12]
RFC 6184:  "RTP Payload Format for H.264 Video", May 2011.
[13]
RFC 6190:  "RTP Payload Format for Scalable Video Coding", May 2011.
[14]
RFC 6437:  "IPv6 Flow Label Specification", November 2011.
[15]
RFC 8285:  A General Mechanism for RTP Header Extensions.
[16]
TS 29.281: "General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)".
[17]
TS 38.321: "NR; Medium Access Control (MAC) protocol specification".
[18]
TS 38.323: "NR; Packet Data Convergence Protocol (PDCP) specification".
[19]
ITU-T Recommendation H.264: "Advanced video coding for generic audiovisual services".
[20]
RFC 3551:  "RTP Profile for Audio and Video Conferences with Minimal Control", July 2003.
[21]
RFC 7798:  "RTP Payload Format for High Efficiency Video Coding (HEVC)", March 2016.
[22]
ISO/IEC 14496-12 | 15444-12: "Information technology - Coding of audio-visual objects - Part 12: ISO base media file format".
[23]
TS 26.244: "Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP)".
[24]
TS 38.415: "NG-RAN; PDU Session User Plane Protocol".
[25]
RFC 1889:  "RTP: A Transport Protocol for Real-Time Applications", January 1996.
[26]
TS 29.998: "Open Services Architecture (OSA) Application Programming Interface (API) part 2".
[27]
TR 26.926: "Traffic Models and Quality Evaluation Methods for Media and XR Services in 5G Systems".
[28]
TS 26.114: "IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction".
[29]
RFC 4566  (2006): "SDP: Session Description Protocol", M. Handley, V. Jacobson and C. Perkins.
[30]
RFC 5888  (2010): "The Session Description Protocol (SDP) Grouping Framework", G. Camarillo, H. Schulzrinne.
[31]
RFC 3261  (2002): "SIP: Session Initiation Protocol", J. Rosenberg et al.
[32]
TS 29.513: "5G System; Policy and Charging Control signalling flows and QoS parameter mapping; Stage 3".
[33]
RFC 3665:  "Session Initiation Protocol (SIP) Basic Call Flow Examples", A. Johnston et al.
[34]
[35]
RFC 7272:  "Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP)".
[36]
RFC 8311:  Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation.
[37]
draft-ietf-tsvwg-arch-l4s:  "Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture", Briscoe et al, Nov 2020, https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4s-arch/.
[38]
draft-ietf-tsvwg-ecn-l4s:  "Explicit Congestion Notification (ECN) Protocol for Ultra-Low Queuing Delay (L4S)", Briscoe et. al, Internet draft, IETF, Mar 2021, https://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-ecn-l4s-id/.
[39]
EU project RITE: "Data Center to the Home", https://riteproject.eu/dctth/.
[40]
L4S: "Linux Kernel tree containing patches for TCP Prague and the dualpi2 qdisc", https://github.com/L4STeam/linux/.
[41]
RFC 2616:  "Hypertext Transfer Protocol -- HTTP/1.1", June 1999.
[42]
RFC 7540:  "Hypertext Transfer Protocol Version 2 (HTTP/2)", May 2015.
[43]
draft-ietf-quic-http-34:  "Hypertext Transfer Protocol Version 3 (HTTP/3)", February 2021.
[44]
RFC 6994:  "Shared Use of Experimental TCP Options", August 2013.
[45]
draft-ietf-tsvwg-udp-options-18:  "Transport Options for UDP", March 2022.
[46]
ITU-T Recommendation H.265: "High efficiency video coding".
[47]
ITU-T Recommendation H.266: "Versatile video coding.
[48]
draft-ietf-avtcore-rtp-vvc-14:  "RTP Payload Format for Versatile Video Coding (VVC)".
[49]
TS 29.244: "Interface between the Control Plane and the User Plane Nodes; Stage 3".
[50]
RFC 9000:  "QUIC: A UDP-Based Multiplexed and Secure Transport".
[51]
RFC 9001:  "Using TLS to Secure QUIC".
[52]
RFC 9002:  "QUIC Loss Detection and Congestion Control".
[53]
RFC 9221:  "An Unreliable Datagram Extension to QUIC".
[54]
draft-ietf-masque-connect-udp-xx:  "UDP Proxying Support for HTTP".
[55]
draft-ietf-quic-http-xx:  "Hypertext Transfer Protocol Version 3 (HTTP/3)".
[56]
draft-ietf-masque-h3-datagram-xx:  "Using Datagrams with HTTP".
[57]
draft-ietf-httpbis-h3-websockets-xx:  "Bootstrapping WebSockets with HTTP/3".
[58]
TR 38.838: "Study on XR (Extended Reality) evaluations for NR".
[59]
TS 23.288: "Architecture enhancements for 5G System (5GS) to support network data analytics services".
[60]
TS 38.331: "NR; Radio Resource Control (RRC); Protocol specification".
[61]
TS 23.548: "5G System Enhancements for Edge Computing; Stage 2".
[62]
IETF Internet-draft-L4S: "Explicit Congestion Notification (ECN) Protocol for Very Low Queuing Delay (L4S)" Briscoe et al, July 2022, https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/.
[63]
draft-gruessing-moq-requirements-02:  "Media over QUIC - Use Cases and Requirements for Media Transport Protocol Design".
[64]
draft-lcurley-warp-01:  "Warp - Segmented Live Media Transport".
[65]
draft-schinazi-masque-connect-udp-ecn-02:  "An ECN Extension to CONNECT-UDP".
[66]
TS 29.514: "5G System; Policy Authorization Service; Stage 3".
[67]
TS 29.522: "5G System; Network Exposure Function Northbound APIs; Stage 3".
[68]
AOM: RTP Payload Format for AV1 (v1.0) https://aomediacodec.github.io/av1-spec/av1-spec.pdf.
Up

3  Definitions of terms, symbols and abbreviationsp. 18

3.1  Termsp. 18

For the purposes of the present document, the terms given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
PDU Set:
A PDU Set is composed of one or more PDUs carrying the payload of one unit of information generated at the application level (e.g. a frame or video slice for XRM Services, as used in TR 26.926 [27]). In some implementations all PDUs in a PDU Set are needed by the application layer to use the corresponding unit of information. In other implementations, the application layer can still recover parts all or of the information unit, when some PDUs are missing.
Multi-modal Data:
Multi-modal Data is defined to describe the input data from different kinds of devices/sensors or the output data to different kinds of destinations (e.g. one or more UEs) required for the same task or application. Multi-modal Data consists of more than one Single-modal Data, and there is strong dependency among each Single-modal Data. Single-modal Data can be seen as one type of data.
Tactile Internet:
A network (or network of networks) for remotely accessing, perceiving, manipulating, or controlling real or virtual objects or processes in perceived real time by humans or machines.
Data Burst:
A set of multiple PDUs generated and sent by the application in a short period of time.
Up

3.2  Symbolsp. 19

For the purposes of the present document, the following symbols apply:
PSDB
PDU-Set Delay Budget
PSER
PDU-Set Error Rate

3.3  Abbreviationsp. 19

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

4  Architectural Assumptions and Requirementsp. 19

4.1  Architectural Assumptionsp. 19

  • The architecture, framework and the QoS model as specified in TS 23.501, TS 23.502, and TS 23.503 are regarded as the baseline for this study.
  • The functional split in 5GS between UE, RAN and CN remains unchanged, i.e. packet classification of DL packets is performed in CN, and the packet classification of UL packets is performed in UE.
  • XRM services are assumed to use the IP PDU session types (however other PDU types are not excluded).
  • This study assumes that the UE may be able to use different PDU Sessions for different XRM services. This study also assumes that the UE uses a single PDU Session for a single XRM service i.e. all data traffic for this XRM service is only carried over this PDU Session.
  • XRM services shall be able to coexist within a PLMN or SNPN with existing services simultaneously
  • XRM services can be between client-server (i.e. UE - application server) and/or peer-to-peer (i.e. between two UEs routed via the 5G CN).
  • Architecture enhancements should support XRM applications and its traffic characteristics. However, specific media codec mechanisms are not in the scope of this study. Interested readers may check TR 26.926 [27] for related mechanisms.
  • The traffic characteristics can vary for different media applications, and application is aware of this.
  • XR and media application data may be encrypted by the client and/or server in some cases and unencrypted in other cases.
  • For downlink traffic the 5GS may be able to determine whether 5GS may discard or should not discard the remaining PDUs that follow a lost PDU of that same PDU Set.
Up

4.2  Architectural Requirementsp. 20

The following architectural requirements are applicable to this study:
  • Solutions shall build on the 5G System architectural principles as in TS 23.501, including:
    • flexibility and modularity for newly introduced functionalities.
    • existing methods for communicating the QoS profile (i.e. Standardized 5QI, Operator Pre-configured 5QI, Dynamically Signalled QoS Profile).
  • Any enhancements for this study shall not impact Emergency Services and other Priority Services (MPS, Mission Critical, etc) capabilities.
  • The existing specific 5GS services using existing QoS functions shall not require enhancement to co-exist with any QoS enhancement being specified for XRM services.
Up

Up   Top   ToC