Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TR 23.700-70  Word version:  19.0.0

Top   Top   None   None   Next
1…   5…

 

1  Scopep. 10

The Technical Report studies key issues, solutions and conclusions for support of advanced media services, e.g. High Data Rate Low Latency (HDRLL) services, AR/VR/XR services. The objectives include study of whether and how to:
  • Enhance PDU Set based QoS handling.
  • Enhance QoS handling for XR services.
  • Enhance support of XR based on non-3GPP access.
  • Expose XR related network capability/information towards the application layer.

2  Referencesp. 10

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: "Policies and Charging control framework for the 5G System; Stage 2".
[5]
RFC 3711:  "The Secure Real-time Transport Protocol (SRTP)", March 2004.
[6]
RFC 6904:  "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)".
[7]
RFC 9335:  "Completely Encrypting RTP Header Extensions and Contributing Sources".
[8]
draft-ietf-avtcore-rtp-over-quic-00:  "RTP over QUIC (RoQ)".
[9]
draft-ietf-moq-transport-00:  "Media over QUIC Transport".
[10]
draft-ietf-avtext-framemarking-00:  "Frame Marking RTP Header Extension".
[11]
RFC 9000:  "QUIC: A UDP-Based Multiplexed and Secure Transport".
[12]
TR 26.926: v18.1.0 "Traffic Models and Quality Evaluation Methods for Media and XR Services in 5G Systems".
[13]
TR 26.925: v18.1.0 "Typical traffic characteristics of media services on 3GPP networks".
[14]
RFC 9330:  "Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture.
[15]
RFC 9331:  "The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)".
[16]
draft-ietf-tsvwg-ecn-encap-guidelines-22:  "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP".
[17]
TS 23.316: "Wireless and wireline convergence access support for the 5G System (5GS)".
[18]
CableLabs DOCSIS MULPI: "Data-Over-Cable Service Interface Specifications DOCSIS 3.1, MAC and Upper Layer Protocols Interface Specification".
[19]
RFC 9332:  "Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S)".
[20]
TS 26.522: "5G Real-time Media Transport Protocol Configurations".
[21]
draft-ietf-tsvwg-udp-options-00:  "Transport options for UDP".
[22]
RFC 6363:  "Forward Error Correction (FEC) Framework".
[23]
RFC 6364:  "Session Description Protocol Elements for the Forward Error Correction (FEC) Framework".
[24]
RFC 6681:  "Raptor Forward Error Correction (FEC) Schemes for FECFRAME".
[25]
RFC 6682:  "RTP Payload Format for Raptor Forward Error Correction (FEC) ".
[26]
RFC 6695:  "Methods to Convey Forward Error Correction (FEC) Framework Configuration Information".
[27]
RFC 6816:  "Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME".
[28]
RFC 6865:  "Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME".
[29]
RFC 8680:  "Forward Error Correction (FEC) Framework Extension to Sliding Window Codes".
[30]
RFC 8681:  "Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME".
[31]
TS 38.300: "NR; NR and NG-RAN Overall description; Stage-2".
[32]
RFC 8627:  "RTP Payload Format for Flexible Forward Error Correction (FEC)".
[33]
RFC 7656:  "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources".
[34]
S2-2210181: "Reply LS on further details on XR traffic".
[35]
TS 29.244: "Interface between the Control Plane and the User Plane Nodes; Stage 3".
[36]
TS 38.415: "NG-RAN; PDU Session User Plane Protocol".
[37]
TS 33.210: "Network Domain Security (NDS); IP network layer security".
[38]
RFC 9298:  "Proxying UDP in HTTP".
[39]
RFC 9297:  "HTTP Datagrams and the Capsule Protocol".
[40]
draft-ietf-masque-quic-proxy-03:  "QUIC-Aware Proxying Using HTTP".
[41]
RFC 5761:  "Multiplexing RTP Data and Control Packets on a Single Port".
[42]
RFC 5764:"Datagram  Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)".
[43]
RFC 7983:  "Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)".
[44]
RFC 8872:  "Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams".
[45]
RFC 9443:  "Multiplexing Scheme Updates for QUIC".
[46]
RFC 3550:  "RTP: A Transport Protocol for Real-Time Applications".
[47]
RFC 6040:  "Tunnelling of Explicit Congestion Notification".
[48]
TS 23.548: "5G System Enhancements for Edge Computing; Stage 2".
Up

3  Definitions of terms, symbols and abbreviationsp. 12

3.1  Termsp. 12

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.
Fully Encrypted Media Flow:
A media flow where both the media header and media payload are encrypted from end-to-end. Fully encrypted headers and payload are not visible in the network. Examples include RTP cryptex (RFC 9335), RTP over QUIC (RoQ) (draft-ietf-avtcore-rtp-over-quic [8]) and Media over QUIC (MoQ) (draft-ietf-moq-transport [9]).
Partially Encrypted Media Flow:
A media flow where some media headers (e.g. base header) are not encrypted. Other media headers (e.g. extension header) and media payload are encrypted from end-to-end. The payload and headers that are encrypted from end-to-end are not visible in the network. Examples include SRTP (RFC 3711) with partially encrypted header extensions (RFC 6904, draft-ietf-avtext-framemarking [10]).
Up

3.2  Symbolsp. 12

For the purposes of the present document, the following symbols apply:

3.3  Abbreviationsp. 12

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. 12

4.1  Architectural Assumptionsp. 12

  • 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 for both 3GPP access and non-3GPP access. The procedures for XRM in 3GPP Rel-18 are described in TS 23.501, TS 23.502 and TS 23.503.
  • The functional split in 5GS between UE/5G-RG, AN and CN remains unchanged.
  • End-to-end media flows may be fully or partially encrypted.
  • The interface between 3GPP UE and tethered devices behind the UE is outside of scope.
Up

4.2  Architectural Requirementsp. 13

The following architectural requirements are applicable to this study:
  • Solutions shall build on the 5G System architectural principles as in TS 23.501.

Up   Top   ToC