The objective of this Key Issue is to introduce support for Time Synchronization with TSN GM in the TSN network attached to the device. The TSN GM is assumed to be located in the network attached to the device. For this Key Issue the following areas should be studied:

1. Support for Time Synchronization with one or more TSN GM(s) in the TSN network attached to the device:
   1. Synchronizing TSN end stations behind 5G System (NW-TT) with the TSN GM in the network attached to the device.
   2. Synchronizing TSN end stations behind other UE(s) with the TSN GM in the network attached to the device side via 5G System.

This Key issue aims to address UE-UE TSC communication if the network determines that the two UE(s) (including two DS-TT(s) within the same UE) are served by the same UPF.

For this Key Issue the following areas should be studied:

1. How the 5GS know the UE/DS-TT pairs which can perform UE-UE communication?
2. 5G System bridge delay determination considering UE-UE communication via same UPF.
   1. How does the 5GS know whether to report the Bridge delay information for the port pair of two DS-TTs.
   2. How does the 5GS calculate and report the Bridge delay information for the port pair of two DS-TTs.
3. Configuration of Deterministic QoS for the QoS Flows of the two UEs served by the same UPF.
   1. The impact on the derivation and provision of QoS parameters and TSCAI in this scenario, if any.

The objective of this Key Issue is to allow wider and more flexible use of 5GS TSC and URLLC through the 5GS Network Exposure Function framework. The exposure framework can be used to expose network capabilities (i.e. enabling operator to offer certain capabilities as services) and also allow application to influence services offered by the network. This key issue is about enhancing the NEF (exposure) framework towards AF so that NEF can expose network capabilities to support Time Sensitive Communication.

Any AF that has knowledge of deterministic application requirements should be able to request TSC services from the 5GS and as authorized, be notified of pertinent network events. This key issue is intended to support in the 5GS, requirements from TS 22.104 where a TSN bridged network may not be needed and requirements from TS 22.263 for Video, Imaging and Audio for Professional Applications (VIAPA). Applications provide those requirements to 5GS for any type of PDU Session. This KI focuses on enhancing NEF framework. For this Key Issue, the following areas should be studied:

1. Ability for AF to request absolute delay and jitter requirements, and mechanisms to enable the PCF to determine the 5GS QoS parameters based on the requirements received from AF.
2. Ability for AF to indicate periodicity, burst size, burst arrival time (as defined in Rel-16 for TSC Assistance information) and Survival Time, optionally burst spread (variation of burst arrival time for DL traffic resulting from jitter on N6, if applicable) along with Time Domain (reference for these parameters) associated with these parameters to the NEF.
3. How to enable an application and 5GS to agree on a TSC configuration that addresses the applications needs and can be supported by 5GS.

Any AF that has knowledge of time synchronization requirements should be able to learn 5GS capabilities to support time synchronization, the AF may request time synchronization with specified requirements, and supply information that can be used to optimize and configure time synchronization procedure for connected devices. This key issue is intended to support in the 5GS, requirements from TS 22.104 where a TSN bridged network may not be needed and requirements from TS 22.263 for Video, Imaging and Audio for Professional Applications (VIAPA). Applications provide those requirements to 5GS for IP or Ethernet types of PDU Sessions. Four different time sources and methods for synchronization are foreseen:

1. assuming use of a gPTP client (IEEE 802.1 [18] Time Aware System) or PTP client (IEEE 1588-2008 [13] and gPTP protocol which conveys the timing information, e.g. located in the DN, and mapping to 5GS time in 5GC (time sync methods as defined in Rel-16).
2. assuming use of the 5GS time source by 5GS and AF (e.g. it could also be GPS time source used by both 5GS and AF); where UPF/NW-TT creates the time sync methods conveyed in gPTP messages as defined in Rel-16 or in PTP messages over UDP/IP as defined in IEEE 1588-2008 [13] for conveying the timing information.
3. assuming use of the 5GS time source by 5GS and AF (e.g. it could also be GPS time source used by both 5GS and AF); where the 5G-AN provides a 5GS reference time to the UE via 3GPP radio layer and UE may provide it to the applications or devices behind the UE by implementation specific means out of scope of 3GPP.
4. assuming use of the 5GS time source by 5GS and AF (e.g. it could also be GPS time source used by both 5GS and AF); where DS-TT creates the time sync methods conveyed in gPTP messages or in PTP messages over UDP/IP as defined in IEEE 1588-2008 [13] for conveying the timing information.

For these four methods, this key issue aims to support exposure for Time Synchronization service offered by 5GS:

1. Exposure of the 5GS capability to activate Time Synchronization from the AF for a TSN Domain GM or 5G GM (i.e. for VIAPA applications).
   1. Ability for network to expose the support for synchronization and the supported time synchronization method (i.e. method 1, 2, 3 or 4 as above) from NEF towards AF.
   2. Ability for AF to request activation/deactivation of Time Synchronization service targeting a UE or a group of UEs and indicate the clock domain (i.e. IEEE TSN Domain GM or 5G GM) and clock accuracy (with an accuracy of e.g. 1 microsecond).
   3. Ability to support the time synchronization service for IP and Ethernet types of PDU Sessions.

Fully distributed TSN model is defined in IEEE 802.1Qcc [7]. Unlike the fully centralized model supported in Rel-16, there is neither a Centralized Network Configuration (CNC) entity nor an entity that has the knowledge of the entire TSN network in fully distributed TSN model. The configuration information for stream resource registration is propagated along the paths from the Talker to Listeners. The 5G CP (i.e. PCF) cannot get the TSN stream requirements and configuration information from a TSN entity in control plane. In order to support integration of 5GS with the TSN network deployed in fully distributed model, the 5GS should be able to read the configuration information carried in the TSN stream resource registration messages (e.g. MSRP messages) and modify the messages as a TSN bridge based on the 5GS capability. The 5G CN CP should also be able to retrieve the TSN stream requirements from the messages transmitted in user plane. Therefore, the enhancements needs to be studied for 5GS to support fully distributed TSN model:

• Which IEEE protocols need to be supported?
• How the 5GS retrieves the TSN stream requirements?
• How to enforce the TSN stream requirements using 3GPP QoS parameters?
• Which entity, (e.g. the UE/DS-TT, UPF/NW-TT, SMF or PCF), is responsible for read/modify the TSN stream resource registration messages, and how the 5GS modifies the TSN stream resource registration message based on 5GS Bridge capability and the configuration information carried in the message?

The objective of this Key Issue is to introduce Use of Survival Time for Deterministic Applications in 5GS. Periodic deterministic communication service performance requirements are described in clause 5.2 of Rel-17 TS 22.104. Survival time is included in the requirements. This key issue aims at studying solutions on how to transfer the survival time to RAN. In more detail:

• how to deliver survival time to 5G system;
• How 5GS acquires the additional assistance information reflecting survival time, e.g. interworking with CNC and/or use of AF or NEF without interworking with CNC or with CUC or other method.

How and when to apply Survival Time assistance information is up to RAN WGs.