Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TR 23.700-25  Word version:  18.1.0

Top   Top   None   None   Next
1…   5… 
1 Scope  2 References  3 Definitions of terms and abbreviations  4 Architectural Assumptions and Requirements 
...

 

1  Scope  p. 9

The objective of this Technical Report is to study and perform an evaluation of potential architecture enhancements for supporting 5G Timing Resiliency and TSC & URLLC enhancements for 5G System (5GS). The following aspects are covered:
  • Study how to report 5GS network timing synchronization status (such as divergence from UTC and 5GS network timing source degradation) to UEs and 3rd party applications (AFs):
    • Study how RAN and 5GC learn about network 5GS network timing synchronization status to be able to inform UEs and AFs.
    • Study if additional information needs to be provided to UEs and AFs to inform about 5GS network timing synchronization status.
  • Study how to enable AFs to request time synchronization service in a specific coverage area and how to enforce the coverage area.
  • Study how to control 5G time synchronization service based on subscription (i.e. introducing subscription parameter for time synchronization and enforcing it).
  • Study how to enable an AF to explicitly provide PER to NEF/PCF.
  • Study mechanisms for interworking with TSN transport networks. Study interworking mechanisms with TSN networks deployed in the transport network in order to support of E2E determinism and low latency communication and efficient N3 transmission.
  • Study if there is a need for applications to adapt downstream scheduling in order for 5GS to meet really low latency (e.g. 2 msecs) requirement and if there is a need to have feedback from RAN (e.g. for application to consider DL packet transmission time slots to avoid buffering in the RAN) for this purpose.
Up

2  References  p. 9

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 38.331: "NR; Radio Resource Control (RRC); Protocol specification".
[6]
IEEE 802.1Qcc: "IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks -- Amendment 31: Stream Reservation Protocol (SRP) Enhancements and Performance Improvements".
[7]
IEEE Std 802.1AS: "IEEE Standard for Local and Metropolitan Area Networks-Timing and Synchronization for Time-Sensitive Applications".
[8]
IEEE Std 1588: "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems".
[9]
TR 22.878: "Feasibility Study on 5G Timing Resiliency System".
[10]
IEEE P802.1Qdj d0.2: "Configuration Enhancements for Time-Sensitive Networking".
[11]
TS 38.321: "Medium Access Control (MAC) protocol specification".
[12]
TS 38.413: "NG-RAN; NG Application Protocol (NGAP)".
[13]
TS 38.300: "NR and NG-RAN Overall Description; Stage 2".
[14]
IEEE Std 802.1AB-2016: "IEEE Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery".
[15]
ITU-T Recommendation G.8271.1: "Network limits for time synchronization in packet networks with full timing support from the network".
[16]
TS 23.273: "5G System (5GS) Location Services (LCS); Stage 2".
[17]
TS 37.355: "LTE Positioning Protocol (LPP)".
Up

3  Definitions of terms and abbreviations  p. 10

3.1  Terms  p. 10

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.

3.2  Abbreviations  p. 10

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 Requirements  p. 10

4.1  Architectural Assumptions  p. 10

The following architectural assumptions apply:
  • The architecture defined in clause 4.4.8 of TS 23.501 is as a baseline for the study.
  • The TSN network deployed in the transport network supports the fully centralised model defined in IEEE 802.1Qcc [6].
  • Configuration and operation of the external synchronization network (i.e. timing synchronization provided by network external to 5GS network) and mitigation actions when time source fails or degrades are assumed to be outside the scope of 3GPP.
  • This study is assumed to inherit the time synchronization architecture, methods, and exposure framework as defined in Rel-17 for 5G System in TS 23.501. This includes the support for time synchronization service based on 5G Access Stratum timing distribution, (g)PTP time sync based on IEEE Std 802.1AS [7] with 5GS acting as Grand-master or PTP time sync with 5GS acting as grand-master based on IEEE Std 1588 [8], along with support for DS-TT, NW-TT and TSCTSF in the time synchronization architecture.
  • How the 5GS network is time synchronized is assumed to be deployment specific thus outside the scope of this study (e.g. 5GS may use local GNSS server, may be time synchronized with an external clock using transport network synchronization protocols, etc.).
  • The study assumes that sync network design complies with applicable performance requirements also during network rearrangements (for example, in the case of ITU-T Recommendation G.8271.1 [15], where budget is allocated to Sync network rearrangements).
Up

4.2  Architectural Requirements  p. 11

The following architectural requirements apply:
  • Solutions for timing resilience and time synchronization shall support the already defined time synchronization distribution methods as defined in clause 4.1.
  • Solutions for main 5G time resiliency use cases shall at least support that the UEs are static to address financial and power grid scenarios, see TR 22.878), but may also support the scenarios where the UEs may not be static.
Up

Up   Top   ToC