WO2023012196A1

WO2023012196A1 - Synchronicity budget in 3gpp time sensitive communications

Info

Publication number: WO2023012196A1
Application number: PCT/EP2022/071762
Authority: WO
Inventors: Stefano Ruffini; Marilet DE ANDRADE JARDIM; John Walter Diachina; Shabnam Sultana
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2021-08-04
Filing date: 2022-08-02
Publication date: 2023-02-09

Abstract

Disclosed herein is a method performed by a core network node (408) in a core network (110) of a cellular communications system (100) that operates as a Time-Sensitive Communication (TSC) node (400). The method comprises: determining (600) a network part of a synchronicity budget of the cellular communications system (100); determining (602) a radio interface part (e.g., per Uu interface part) of the synchronicity budget of the cellular communications system (100) based on the determined network part of the synchronicity budget of the cellular communications system (100); and performing (604) one or more actions that involve the determined radio interface part of the synchronicity budget of the cellular communications system (100).

Description

SYNCHRONICITY BUDGET IN 3GPP TIME SENSITIVE COMMUNICA HONS

BACKGROUND

Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features, and advantages of the enclosed embodiments will be apparent from the following description.

In Third Generation Partnership Project (3GPP) Technical Specification (TS) 23.501 v17.0.0, clauses 4.4.8, 5.27.1 , and 5.28.3 give a background on the way that Time Sensitive Networking (TSN) and a more general case of Time Sensitive Communications (TSC) can be supported in the Fifth Generation System (5GS). The idea is that the 5GS can act as a TSN bridge (or a TSC node) by using translators at the user plane and at the control plane such that the 5GS can interoperate with other TSN/TSC nodes and be able to handle the Quality of Service (QoS) required and Time Synchronization related signaling. In the 5GS, the translators at the user plane are currently called a device-side TSN Translator (DS-TT) located at User Equipment (UE) and a network-side TSN translator (NW-TT) located at the User Plane Function (UPF), but the names may change to TSC translators. The translators at the control plane are provided using a TSN Application Function (AF) for TSN or using the Time Sensitive Communication and Time Synchronization Function (TSCTSF) for TSC).

The 5GS TSN Bridge (or 5GS TSC node) internally is modeled with a single UPF and a single co-located NW- TT, and DS-TTs at the UEs. Every DS-TT port is associated to a single/unique Protocol Data Unit (PDU) session. The NW-TT can have multiple ports. In 3GPP Release 16, the Port Management Information Container (PMIC) and Bridge Management Information Container (BMIC) were conceived to allow the 5GS to internally signal configuration information that is provided by the TSN external controller (known as Centralized Network Controller (CNC)) so that it is able to read and configure the 5GS TSN bridge and its ports. The BMIC is exchanged between the TSN AF and NW-TT, and the PMIC is exchanged between TSN AF and DS-TT and between TSN AF and NW-TT. From Release 17, with the inclusion of more general support for TSC to serve for example Video, Imaging and Audio for Professional Applications (VIAPA), the system reuses many aspects of TSN from Release 16 such as DS-TT, NW-TT, PMIC, and BMIC. Note that BMIC has changed its name in Release 17 to User plane node Management Information Container (UMIC). Then, it is considered that the UMIC and PMIC can be terminated at the TSCTSF for TSC case.

Time synchronization service for TSC supported by the 5GS has been specified in 3GPP TS 23.501 v17.0.0. A series of parameters are exchanged between the 5GS and an TSCTSF in order to negotiate the requirements for a time sensitive communication and be able to expose the 5GS time synchronization capabilities toward the Application Function (AF) and obtain time synchronization requirements from AF.

It has been proposed in 3GPP SA2 to add synchronization accuracy as part of the requirements coming from the AF, since accuracy impacts the service to be provided by the 5GS (see S2-2102358, “Time synchronization accuracy discussion,” Nokia, 3GPP SA2 meeting #144E, April 2021.) and it lets the Radio Access Network (RAN) know the synchronicity budget for the Uu interface (i.e., the budgeted accuracy associated with the next generation Node B (gNB) sending the UE 5G reference time (i.e., the 5GS Telecom GM clock) information that is used for performing time-stamping). Note that the budgeted accuracy is the upper bound of the synchronicity budget applicable when conveying 5G reference time information to UEs over the radio interface (i.e., the Uu interface). Implementation of the proposal in the specifications for 5GS was presented in S2-2104121 , “Exposure of Time synchronization as a service - policy,” Nokia, 3GPP SA2 meeting #145E, May 2021 and S2- 2104122, “Time synchronization accuracy - description,” Nokia, 3GPP SA2 meeting #145E, May 2021 .

The proposals made in S2-2104121 and S2-2104122 involve having a new container besides UMIC/PMIC, namely a Time Synchronization assistance container with information on the accuracy and the synchronicity budget per UE (per Uu interface), which is delivered to the RAN as part of UE context management procedures. The issue triggering the potential need for this new information is that there is a use case scenario where UE-to-UE communication may be involved in distributing a Grand Master (GM) clock. In such a case, there are two Uu interfaces where each is limited to using half of the synchronicity budget that was otherwise to be applied in other use cases involving a single Uu interface (i.e., where communication of a GM clock is from UE to UPF, or vice versa). Based on Best Master Clock Algorithm results (which is running in NW-TT clause 5.27.1 , 3GPP TS 23.501 ) shared via UMIC to the TSCTSF, the TSCTSF can obtain the ports states which allows for determining the location of the TSC GM clock, which leads to defining the clock distribution path (i.e., determining if the UE-to-UE scenario applies in which case there are two Uu interfaces or determining if other scenarios apply in which case there is a single Uu interface) applicable to that TSC GM clock.

The proposals made in S2-2104121 and S2-2104122 state that the Session Management Function (SMF) can have knowledge of network components in the distribution chain and can, for each TSC GM clock, compute the accuracy/error budget available for the RAN and the Network segments. However, there is no indication on how the SMF obtains this information and how it uses the information.

For RAN, these three scenarios are under consideration:

• Scenario 1 (one Uu interface): In the control-to-control communication use case, TSC devices behind a target UE are synchronized to any time domain (TD), from a GM behind the Core Network (CN). The 5GS-introduced-error is caused by the relative time-stamping inaccuracy at the NW-TT and the DS- TTs.

• Scenario 2 (two Uu interfaces): In the control-to-control communication use case, TSC devices behind a target UE are synchronized to any TD, from a GM behind the UE. The 5GS-introduced-error is caused by the relative time-stamping inaccuracies at the involved DS-TTs.

• Scenario 3 (one Uu interface): In the smart grid use case, the TSC devices behind a target UE are synchronized to the 5G GM TD. The 5GS-introduced-error is caused by the synchronization of the 5G clock to the DS-TT.

RAN2 is evaluating the synchronicity budget by dividing the 5GS End-to-End (E2E) path into three parts: Network, Device, and Uu interface, where the Uu interface is understood as the maximum 5GS time synchronization error between the UE and the radio interface of the gNB Distributed Unit (gNB-DU).

According to RAN2, the Uu interface budget for Scenarios 1 , 2 and 3 shall be respectively calculated as follows:

• Scenario 1 : Uu budget = 900 nanoseconds (ns) - Device - Network scenariol

• Scenario 2: Uu budget = (900ns - 2xDevice - 2xNetwork scenario2)/2 (assumption is based on gPTP)

• Scenario 3: Uu budget = 1000ns - Device - Networkscenario3 (baseline assumption that this is based on GNSS).

Then the proposals made in S2-2104121 and S2-2104122 provide the following assumptions for the Network part time synchronization accuracy budget for Scenario 1 , 2, and 3: • Scenario 1 : ±120 to ±200ns (NetworkScenariol ) (assuming 3-5 hops worst case scenario

• Scenario 2: ±240 to ±400ns (2xNetworkScenario2) (assuming 6-1 Ohops worst case scenario)

• Scenario 3: ±100ns (NetworkScenario3).

The Device part time synchronization accuracy budget is assumed to be in the range ±50 to ±100ns. This applies to all three scenarios.

The following TLV (type, length, value) information elements have been standardized for use with the Precision Timing Protocol (PTP) (see IEEE 1588-2019, IEEE standard for a precision clock synchronization protocol for networked measurement and control systems):

• Path Trace TLV (see section 16.2 of IEEE1588). It can be used for tracing the route of a PTP Announce message through the PTP Network. This is achieved by carrying the list of the clock identities of the PTP route. This option is also included in G.8275.1 (see Annex D). According to G.8275.1 , both Boundary clocks and Transparent clocks can add their own clock identity.

• Enhanced synchronization accuracy metrics TLV: (see 16.12 of IEEE1588). It carries accumulated values of constant time error and dynamic time error (in the IEEE1588 specification these are indicated as maxStaticInstancelnaccuracy, and varDynamicInaccuracy respectively).

SUMMARY

There currently exist certain challenge(s). The proposed solution in the proposals made in S2-2104121 and S2-2104122 state that there are three parts in the calculation of the synchronicity budget (time error budget) over the end-to-end path in the 5GS:

• Device (UE to DS-TT),

• Uu interface (air interface between UE and gNB), and

• Network (gNB to UPF/NW-TT).

The concept supported by the proposals made in S2-2104121 and S2-2104122 is to calculate the time error budget required for the Uu interface based on some arbitrary fixed assumptions on the time error budget to be allocated to the network side of the 5GS (e.g., assumptions based on the worst-case number of hops between the 5GS Telecom GM and the NW-TT). However, a more precise method is needed for determining the synchronicity budget allocated to the network portion of the 5GS since it will allow for more precisely determining the synchronicity budget that remains available for the Uu interface. This more precise determination of the available Uu synchronicity budget is critical towards the gNB selecting the appropriate method for determining the downlink propagation delay value used to adjust the 5G reference time information (i.e., the 5GS Telecom GM clock).

Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. In one embodiment, the Network-part of the synchronicity budget is calculated by the TSCTSF with enhanced accuracy. In this manner, the portion of the overall 5GS synchronicity budget available for the Uu interface can be calculated more precisely.

Depending on the use case scenario (Scenario 1 , 2, or 3 above), details about the internal 5G time synchronization can be provided to the RAN (e.g., to a RAN node) so that it can know the portion of the overall 5GS synchronicity budget allocated to a Uu interface and, based on that, make the most effective decision (e.g., acceptance of the service, and in this case what radio link propagation delay (PD) compensation method to apply).

In one embodiment, a method is provided that uses information about the internal 5G time distribution to calculate the network-part of the overall 5GS synchronicity budget. This network-part allows for more precisely calculating the synchronicity budget applicable to the Uu interface (i.e., the target value for the per Uu interface synchronicity budget is provided to RAN). This can allow the gNB to make important decisions such as, e.g., whether or not to support the service based on the calculated per Uu interface synchronicity budget requirement and/or which PD method is most effective to compensate the 5G reference time to reflect the radio link delay.

In one embodiment, the information about the internal 5G time distribution is transferred to the TSCTSF such that: i) the per-Uu synchronicity budget calculation is performed based on the applicable internal 5G time distribution scenario that only TSCTSF is aware of, ii) gNB receives the required accuracy (synchronization error budget) for a single Uu interface (or alternatively is provided with the network budget and applicable scenario), and iii) a feedback can be provided to the external entity (AF) in case the calculated per-Uu synchronicity budget can/cannot be provided/supported. There are, proposed herein, various embodiments which address one or more of the issues disclosed herein.

Certain embodiments may provide one or more of the following technical advantage(s). Embodiments of the present disclosure may provide a more precise calculation of the Uu interface synchronicity budget by the core network, which is beneficial towards determining the per Uu interface accuracy requirement to be provided to RAN. With this information, the RAN (e.g., gNB) can then select the appropriate signaling method to be used for determining the propagation delay applicable to each UE, where the determined propagation delay is used for adjusting 5G reference time information (i.e. , the 5GS Telecom GM clock) which a UE uses for performing ingress/egress time-stamping.

In one embodiment, this information can also be used by the RAN (e.g., gNB) to verify whether the specific synchronization service can be supported at all. For example, the RAN (e.g., gNB) may determine that the per Uu interface accuracy requirement cannot be satisfied using any of the signaling methods available for determining propagation delay.

In one embodiment, the TSCTSF may as well determine when the requirement cannot be satisfied and give a notification to the AF.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other objects, features and advantages of the disclosure will become apparent from the following detailed description of illustrative embodiments thereof, which are to be read in connection with the accompanying drawings.

FIG. 1 illustrates one example of a cellular communications system 100 according to some embodiments of the present disclosure;

FIG. 2 illustrates a wireless communication system represented as a 5G network architecture composed of core Network Functions (NFs);

FIG. 3 illustrates a 5G network architecture using service-based interfaces between the NFs in the control plane;

FIG. 4 is a modified version of Figure 4.4.8.3-1 3GPP TS 23.501 v17.1.1 that shows one example of an architecture in which a 5GS appears as a TSC node 400; FIG. 5 shows example(s) of two scenarios (TE1 and TE2) in accordance with embodiments of the main solution described herein;

FIG. 6 is a flow chart that illustrates the operation of a core network node (e.g., the TSCTSF 408) in accordance with one embodiment of the present disclosure;

FIG. 7 is a signaling diagram that illustrates an example method performed by the TSCTSF 408 in accordance with an embodiment of the present disclosure;

FIG. 8 is a schematic block diagram of a network node 800 according to some embodiments of the present disclosure;

FIG. 9 is a schematic block diagram that illustrates a virtualized embodiment of the network node 800 according to some embodiments of the present disclosure;

FIG. 10 is a schematic block diagram of the network node 800 according to some other embodiments of the present disclosure.

DETAILED DESCRIPTION

Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

Radio Node: As used herein, a “radio node” is either a radio access node or a wireless communication device. Radio Access Node: As used herein, a “radio access node” or “radio network node” or “radio access network node” is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station (e.g., a network node that implements a gNB Central Unit (gNB-CU) or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node. Core Network Node: As used herein, a “core network node” is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

Communication Device: As used herein, a “communication device” is any type of device that has access to an access network. Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC). The communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless or wireline connection.

Wireless Communication Device: One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (loT) device. Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC. The wireless communication device may be a portable, hand-held, computer- comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless connection.

Network Node: As used herein, a “network node” is any node that is either part of the RAN or the core network of a cellular communications network/system.

Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system. Figure 1

Embodiments described herein relate to using the 5GS as a virtual Time Sensitive Communication (TSC) node (e.g., a virtual Time Sensitive Networking (TSN) bridge). Thus, before describing embodiments of the present disclosure in more detail, a brief discussion of a 5GS is beneficial. In this regard, Figure 1 illustrates one example of a cellular communications system 100 according to some embodiments of the present disclosure. In the embodiments described herein, the cellular communications system 100 is a 5GS. In this example, the cellular communications system 100 includes Radio Access Network (RAN) including base stations 102-1 and 102-2, which in the Next Generation RAN (NG-RAN) of the 5GS are referred to as gNBs, controlling corresponding macro cells 104-1 and 104-2. The base stations 102-1 and 102-2 are generally referred to herein collectively as base stations 102 and individually as base station 102. In much of the description below, the base stations 102 are gNBs and, as such, the base stations 102 are sometimes referred to herein as gNBs 102. Likewise, the macro cells 104-1 and 104-2 are generally referred to herein collectively as macro cells 104 and individually as macro cell 104. The cellular communications network 100 may also include a number of low power nodes 106-1 through 106-4 controlling corresponding small cells 108-1 through 108-4. The low power nodes 106-1 through 106-4 can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like. Notably, while not illustrated, one or more of the small cells 108-1 through 108-4 may alternatively be provided by the base stations 102. The low power nodes 106-1 through 106-4 are generally referred to herein collectively as low power nodes 106 and individually as low power node 106.

Likewise, the small cells 108-1 through 108-4 are generally referred to herein collectively as small cells 108 and individually as small cell 108. The base stations 102 (and optionally the low power nodes 106) are connected to a core network 110, which in the 5GS is the 5G core (5GC).

The base stations 102 and the low power nodes 106 provide service to wireless communication devices 112-1 through 112-5 in the corresponding cells 104 and 108. The wireless communication devices 112-1 through 112-5 are generally referred to herein collectively as wireless communication devices 112 and individually as wireless communication device 112. The wireless communication devices 112 are also sometimes UEs and, as such, are also referred to herein as UEs 112.

Figure 2

Figure 2 illustrates a wireless communication system represented as a 5G network architecture composed of core Network Functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point/interface. Figure 2 can be viewed as one particular implementation of the system 100 of Figure 1.

Seen from the access side the 5G network architecture shown in Figure 2 comprises a plurality of UEs 112 connected to either a RAN 102 or an Access Network (AN) as well as an Access and Mobility Function (AMF) 200. Typically, the R(AN) 102 comprises base stations, e.g. such as eNBs or gNBs or similar. Seen from the core network side, the 5G Core (5GC) NFs shown in Figure 2 include a NSSF 202, an Authentication Server Function (AUSF) 204, a UDM 206, the AMF 200, a Session Management Function (SMF) 208, a PCF 210, and an Application Function (AF) 212.

Reference point representations of the 5G network architecture are used to develop detailed call flows in the normative standardization. The N1 reference point is defined to carry signaling between the UE 112 and AMF 200. The reference points for connecting between the AN 102 and AMF 200 and between the AN 102 and UPF 214 are defined as N2 and N3, respectively. There is a reference point, N11 , between the AMF 200 and SMF 208, which implies that the SMF 208 is at least partly controlled by the AMF 200. N4 is used by the SMF 208 and UPF 214 so that the UPF 214 can be set using the control signal generated by the SMF 208, and the UPF 214 can report its state to the SMF 208. N9 is the reference point for the connection between different UPFs 214, and N14 is the reference point connecting between different AMFs 200, respectively. N15 and N7 are defined since the PCF 210 applies policy to the AMF 200 and SMF 208, respectively. N12 is required for the AMF 200 to perform authentication of the UE 112. N8 and N10 are defined because the subscription data of the UE 112 is required for the AMF 200 and SMF 208.

The 5GC network aims at separating user plane and control plane. The user plane carries user traffic while the control plane carries signaling in the network. In Figure 2, the UPF 214 is in the user plane and all other NFs, i.e., the AMF 200, SMF 208, PCF 210, AF 212, NSSF 202, AUSF 204, and UDM 206, are in the control plane. Separating the user and control planes guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from control plane functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.

The core 5G network architecture is composed of modularized functions. For example, the AMF 200 and SMF 208 are independent functions in the control plane. Separated AMF 200 and SMF 208 allow independent evolution and scaling. Other control plane functions like the PCF 210 and AUSF 204 can be separated as shown in Figure 2. Modularized function design enables the 5GC network to support various services flexibly.

Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF. In the control plane, a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity. The user plane supports interactions such as forwarding operations between different UPFs.

Figure 3

Figure 3 illustrates a 5G network architecture using service-based interfaces between the NFs in the control plane, instead of the point-to-point reference points/interfaces used in the 5G network architecture of Figure 2. However, the NFs described above with reference to Figure 2 correspond to the NFs shown in Figure 3. The service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In Figure 3 the service based interfaces are indicated by the letter “N” followed by the name of the NF, e.g. Namf for the service based interface of the AMF 200 and Nsmf for the service based interface of the SMF 208, etc. The NEF 300 and the NRF 302 in Figure 3 are not shown in Figure 2 discussed above. However, it should be clarified that all NFs depicted in Figure 2 can interact with the NEF 300 and the NRF 302 of Figure 3 as necessary, though not explicitly indicated in Figure 2.

Some properties of the NFs shown in Figures 2 and 3 may be described in the following manner. The AMF 200 provides UE-based authentication, authorization, mobility management, etc. A UE 112 even using multiple access technologies is basically connected to a single AMF 200 because the AMF 200 is independent of the access technologies. The SMF 208 is responsible for session management and allocates Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF 214 for data transfer. If a UE 112 has multiple sessions, different SMFs 208 may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF 212 provides information on the packet flow to the PCF 210 responsible for policy control in order to support Quality of Service (QoS). Based on the information, the PCF 210 determines policies about mobility and session management to make the AMF 200 and SMF 208 operate properly. The AUSF 204 supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM 206 stores subscription data of the UE 112. The Data Network (DN), not part of the 5GC network, provides Internet access or operator services and similar. An NF may be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.

Figure 4

Embodiments of the present disclosure more specifically relate to the 5GS appearing as a TSC node for integration with a TSC network (e.g., a TSN bridge for integration with a TSN network). In this regard, Figure 4, which is a modified version of Figure 4.4.8.3-1 3GPP TS 23.501 v17.1 .1 , shows one example of an architecture in which a 5GS appears as a TSC node 400. The architecture includes an AF 402, a device side TT (DS-TT) 404, a network side TT (NW-TT) 406, and a TSCTSF 408. In this example, the TT at the UE side, which is denoted in Figure 4 as the DS-TT 404 and also referred to herein as a UE side TT or UE/TT, is shown outside of the UE 112, and the TT at the UPF side, which is denoted in Figure 4 as the NW-TT 406 and also referred to herein as a UPF side TT or UPF/TT, is shown inside of the UPF 214. However, in other embodiments, the DS-TT 404 at the UE side is alternatively implemented within the UE 112 and/or the NW-TT 406 at the UPF side is alternatively implemented outside of the UPF 214.

Now, some example embodiments of the present disclosure will be described.

Solution A: Main Solution

Figure 6

Figure 6 is a flow chart that illustrates the operation of a core network node (e.g., the TSCTSF 408) in accordance with one embodiment of the main solution described herein. In much of the description below, the core network node is the TSCTSF 408 and, as such, the description below oftentimes refers to the TSCTSF 408. As illustrated, the core network node determines a network part of the synchronicity budget of the 5GS (step 600). More specifically, in one embodiment, the core network node receives information about internal 5GS time distribution parameters that are used to calculate the network part of the 5GS synchronicity budget (step 600A). Details regarding this information are provided below. The core network node computes the network part of the 5GS synchronicity budget based on the information about the internal 5GS time distribution parameters (step 600B). The core network node uses the determined network part of the 5GS synchronicity budget to determine a per Uu interface budget (i.e., the part of the 5GS synchronicity budget consumed by the interface between a respective UE 112 and the base station 102) (step 602). The core network node then performs one or more actions involving the determined per Uu interface budget (step 604). For example, in one embodiment, the core network node sends assistance information to the base station(s) 102, where this assistance information includes a most stringent synchronicity budget to be satisfied for each Uu interface (step 604A). Additionally or alternatively, the core network node makes a decision about whether or not a service(s) requiring TSN GM synchronization can be supported based on the determined budget per Uu interface and may send corresponding feedback to the AF 402 (step 404B). In the case that the service(s) requiring TSN GM synchronization can be supported, the core network node may further determine which of a set of radio link propagation delay compensation methods/schemes is most appropriate and applies it (step 604C). If the case that the service(s) requiring TSN GM synchronization cannot be supported, the core network node may further send a reject message to the AF 402 (e.g., if the per Uu interface budget is a value that a gNB cannot realize or is a negative value) (step 604D). Further details regarding each of the steps of Figure 6 are provided below and are applicable to the process of Figure 6.

In regard to step 600, the determination of the network part of the 5GS synchronicity budget is based on information and/or parameters that can be provided to the core network node (e.g., to the TSCTSF 408) for use in determining the portion of the overall 5GS synchronicity budget consumed by the Network part (between the base station 102 (i.e., the gNB in NR) and the UPF 214 / N6 interface in case of scenario 1 or between a pair of base stations 102 (i.e., a pair of gNBs in NR) in case of scenario 2). Similarly, in case of scenario 3, determination of the portion of the overall 5GS synchronicity budget consumed by the Network part allows for the TSCTSF 408 to estimate the actual synchronization accuracy budget allowed over the radio interface (Uu interface).

In regard to step 604, after the TSCTSF 408 determines the synchronicity budget consumed by the Network part, the TSCTSF 408 can then send time synchronization assistance information to the base stations 102 (i.e., gNBs in the case of NR) consisting of the most stringent synchronicity budget to be satisfied for each Uu interface. Note that, for a single Uu interface, there might be multiple time domains with different synchronicity use case scenarios applicable for each. So, it is the task of the TSCTSF 408 to choose the most critical/demanding Uu interface synchronicity budget value applicable to the time domains of interest for each UE 112 and provide it to the RAN on a per UE basis. In regard to determining the per Uu interface budget in step 602, the three synchronicity scenarios (described in the Introduction section above) have the following time error constraints:

• Scenario 1 : Uu budget = 900ns - Device - NetworkScenariol (1 )

• Scenario 2: Uu budget = (900ns - 2xDevice - NetworkScenario2) / 2 (2)

• Scenario 3: Uu budget = 1000ns - Device - NetworkScenario3 (3)

The value for the device part (“Device”) of the synchronicity budget (i.e., UE 112 to DS-TT 404) can be preconfigured in the TSCTSF 408. Safe assumptions can as well be made about the device part of the budget. The network part (“NetworkScenariol”, “NetworkScenario2”, and “NetworkScenario3”) depends on the number of hops involved in the synchronization distribution from the TSC GM to the nodes that handle the delivery of the synchronization service (e.g., between the UPF 214 and the base station 102 (i.e., gNB in NR)).

Assumptions for the network part may be largely inaccurate. Therefore, embodiments of the present disclosure provide the means to accurately calculate the network part of the overall 5GS synchronicity budget. Once this network part has been determined in step 600, then the per Uu interface budget can be calculated in step 602 using the determined network part and the, e.g., preconfigured device part, in accordance with Equation (1), (2), or (3) above, depending on the scenario.

With the budget information, the TSCTSF 408 (or the base station 102, or gNB in NR, as described in Solution A.2 below) is able to determine how much of the overall 5GS synchronicity budget is left for each Uu interface in the overall 5GS path and can make a decision about whether or not it can support the services requiring TSC GM time synchronization. In case the service can be supported, in one embodiment, which radio link propagation delay compensation method is more appropriate is identified (e.g., by the RAN) and applied.

In one embodiment, the TSCTSF 408 receives information about internal 5GS time distribution parameters that are used to calculate the Network-part of the budget. This information may be received from, e.g., the UPF 214 and/or the base station(s) 102 (i.e., gNB(s) in NR). Then, the TSCTSF 408 calculates the per Uu interface budget using Equation (1), (2), or (3) above, where applicable. If the value of the per Uu interface budget is set to a value that a gNB cannot realize or is a negative value, then the TSCTSF may reject the request from AF or provide corresponding feedback to the AF.

In one embodiment, the TSCTSF 408 receives the information about the internal 5GS time distribution parameters that are used to calculate the Network-part of the budget from, e.g., the base station(s) 102 (i.e., gNB(s) in NR) and/or the UPF 214. Note that the present disclosure is not focused on how the TSCTSF 408 obtains the information from base station(s) 102 (i.e., gNB(s) in NR) and/or the UPF 214. It has already been suggested that the SMF 208 knows the TSN GM clock topology. So, for example, the SMF 208 can receive updates from the UPF 214 indicating the internal time synchronization parameters at the UPF 214 and at the base station 102 (i.e., gNB in NR) related to a PDU session, which is related to a UE address. This can in turn be reported to the TSCTSF 408. Also, using maintenance is possible. UMIC can be reused to report the data with indication on a per-UE basis.

Concerning estimation of the value of the “NetworkScenarioX” where “X” is 1 , 2, or 3 depending on the scenario, the following fundamental information can be provided to the 5G core network (to the TSCTSF 408) in step 600A based on basic Precision Time Protocol (PTP) information, e.g.:

• 5GS T-GM id used by the NW-TT 406,

• 5GS T-GM used by the base station 102 (i.e., gNB in NR) (it may be the same used by the NW-TT 406,.

• Path Trace option if available for detailed information on the PTP path,

• Number of hops between 5GS T-GM and gNB (could be based on the Steps removed, or based on information carried by the Enhanced accuracy TLV if available),

• Number of hops between 5GS T-GM and NW-TT 406 (could be based on the Steps removed, or based on information carried by the Enhanced accuracy TLV if available), and/or

• When Enhanced Accuracy TLV is available, it can directly provide estimated time error across the PTP distribution chain).

Combining this information would allow the TSCTSF 408 to estimate the relative time error between the relevant interfaces, e.g., the NW-TT interface and the input of the gNB. Additional error component dependent on the specific gNB used may be considered.

Figure 5

An example is shown in Figure 5. As shown in Figure 5, the relevant time error from the network for Scenario 1 is indicated as TE1 , while for Scenario 2 this is indicated as TE2.

In one embodiment, the network contribution to the total 5GS time error budget in the examples can be estimated by the TSCTSF 408 based on the information carried by the “Enhanced synchronization accuracy metrics TLV” (“ATLV”) and “Path Trace TLV” (“PathTLV”). The UPFs 214 and the base stations 102 (i.e., gNBs in NR) send, to the TSCTSF 408, the relevant information carried by the TLVs. In one embodiment, the relevant information carried by the TLVs is the accumulated time error and the related sync route.

More details are provided below for the two relevant scenarios.

Scenario 1 (controi-to-controi use case with one Uu interface):

In the example of Figure 5, the Enhanced synchronization accuracy metrics TLV at the UPF 214 carries the accumulated constant time error and dynamic time error across switch #2 and #3. In this example, it would be according to G.8273.2 class B and C clocks respectively. The NW-TT 406 adds its own contribution and combines the two types of errors (namely a constant time error component and a dynamic time error component) as described in G.8271.1 Appendix IV. Some additional budget may be taken into account for link asymmetries. This may also be carried in one specific field of the Enhanced synchronization accuracy metrics TLV. The 5G GM’s own contribution to the time error is carried by a special field of the TLV (G/W/naccuracy). However, in this example, this is not impacting TE1 as it is common to both the NW-TT 406 and gNB. The detail on the sync route (as well as on the GM) is known via the Path Trace TLV.

The same happens at gNB1 . In this case, the time error is added by switch #2. gNB 1 combines the dynamic and constant time errors, dTE and cTE respectively, including its own contribution.

Both gNB1 and UPF 214 would send all this information to the TSCTSF 408, where this info is received by the TSCTSF in step 600A

In step 600/600B, the TSCTSF 408 determines the network part (“NetworkScenariol” for Scenario 1) of the 5GS synchronicity budget. In one embodiment, the TSCTSF 408 determines the network part (“NetworkScenariol” for Scenario 1) of the 5GS synchronicity budget by adding the two time errors as calculated by the gNB1 and NW-TT 406. In case some equipment is common to both paths (e.g., additional switch between 5G GM #1 and switch #2 in the example of Figure 5), there might be some time error duplication. This is, however, known by the TSCTSF 408 via the route details and, therefore, the TSCTSF 408 could make some adjustments to compensate for any time error duplication.

Note: In the example of Figure 5, Switch #2 is common to paths between the 5G GM and gNB1 and between the 5G GM and NW-TT, and a relative time error between PTP ports of switch #2 should be considered. This has been specified for G.8273.2 class C but not for class B. In case of class B, then it is correct to consider twice the error contribution of Switch #2 (i.e., in the path towards the gNB1 and in the path towards the NW-TT 408).

For a numerical example, based on G.8273.2 specification (class C cTE= 10 ns; dTE = 5 ns; class B cTE: 20 ns, dTE= 20 ns) and the G.8271.1 indication (linear accumulation for cTE, and quadratic accumulation for dTE), the following applies (it is also assumed that TSCTSF 308 itself adds linearly a budget of 200 ns:

TE1 =

TE (NW-TT path) +TE (gNB1 path) =

[20 ns + 20 ns + 10 ns + sqr (20² + 20² + 5² ns)] + [20 ns + 20 ns + 200 ns] = 79 ns + 240 ns = 319 ns

Scenario 2 (controi-to-controi use case with two Uu interfaces):

Again referring to the example of Figure 5, in the case of Scenario 2, the relevant information is sent to the TSCTSF 408 by the involved gNBs (g NB 1 and gNB2) so that the TSCTSF 408 can estimate TE2 as the network contribution to the overall 5GS time error budget. In one embodiment, this information is extracted by the Enhanced synchronization accuracy metrics TLV (“ATLV”) and Path Trace TLV (“PathTLV”) in a similar way as described for Scenario 1 .

In this case, a numerical example would give:

TE2=

TE (gNB1 path) + TE (gNB2 path)=

[20 ns + 20 ns + 200 ns] + [20 ns + 10 ns + 10 ns +10 ns+ sqr (20² + 5² + 5² + 5² ns) + 200 ns]= 240 ns + [50 ns +22 ns + 200 ns] = 512 ns

In the example shown in Figure 5, the same 5G GM is the master for all gNBs and NW-TTs 408. Other scenarios are possible in case of independent 5G GMs are used. The procedure would be the same in this case as the TLV would carry the details of the clock IDs involved in each sync path including details on the 5G GMs.

Uu budget Calculation

After the network part (NetworkScenarioX) of the 5GS synchronicity budget is estimated, in step 602, the

TSCTSF 408 calculates the per Uu interface budget (i.e., the device part of the 5GS synchronicity budget) using Equation (1) or (2) above, respectively, depending on the applicable scenario. In one embodiment, the TSCTSF 408 sends assistance information to gNB1 and gNB2 indicating the required per Uu interface budget in step 604.

As an example, with the assumption that the budget for the Device (i.e., UE 112 to DS-TT 404) is 50 ns, the following can be calculated by the TSCTSF 408 and then sent to the corresponding gNB(s) as assistance information:

• As related to the Scenario 1 example where TE1 = 319ns, from Equation (1) we get: o Per Uu interface time error budget = 900 ns - Device - Network Scenario 1= 900 ns - 50 ns - 319 ns = 531 ns o This could, for example, result in a decision to support the service with a legacy TA (Timing Advance) PD method as there is sufficient margin of error for that.

• As related to the Scenario 2 example, where TE2 = 512ns, from (2) we get: o Per Uu interface time error budget = (900ns - 2xDevice - NetworkScenario2) / 2 = (900 ns - 100 ns - 512 ns) /2 = 144 ns o The decision could be to reject the service, since even when the most accurate radio link propagation delay compensation method is used there is a risk of the actual time error accuracy not satisfying the allowed per Uu interface time error budget.

The TSCTSF 408 may also be able to send feedback to AF in case a preconfigured threshold for the Uu interface time error budget cannot be achieved, or when the calculation produces a negative value (see solution A.1).

Scenario 3 (smart grid use case)

Similar examples can be made with Scenario 3.

Solution A.1 - solution involving feedback to AF

Given that for Scenarios 1 and 2 the minimum accuracy/error budget in the 5GS that can be provided is, e.g., 900 ns, and for Scenario 3 the minimum accuracy/error budget in the 5GS is, e.g., 1000 ns, a solution that relies on the fact that the 5GS guarantees a minimum error budget value for the whole internal 5GS path could be used. More specifically, the TSCTSF 408 provides the RAN (e.g., the base station 102) with error budget information when the accuracy/error budget is demanding (such as, e.g., scenario 2) and provides the AF 402 with feedback on whether the requested accuracy/error budget can be satisfied (or just rejects the request in the case it is not compliant with the minimum supported error budget). Note that for this feedback there is no need to get notifications from the RAN.

In one embodiment, when TSCTSF 408 receives a 5GS accuracy request from the AF 402 for a UE 112, the TSCTSF 408 proceeds as follows. Note that TSCTSF 408 has knowledge of which time synchronization use case scenarios the UE 112 needs to support.

1 . If the UE 112 is only interested in a set of TSC GM clocks (where each has a corresponding PTP Domain/Profile) that operate according to Scenario 1 and/or 3 and the requested error budget is below the minimum supported in the 5GS (e.g., 900 ns for scenario 1 , 1000 ns for scenario 3), then the TSCTSF 408 notifies the AF 402 (via NEF 300 for a 3^rd party AF) that the request is invalid or the error budget cannot be fulfilled. No further action/information toward RAN is required. However, as an option, the TSCTSF 408 could be instructed to verify first whether the network allows to meet error budget below the one standardized.

2. If the UE 112 is interested in at least one TSC GM clock that operates according to Scenario 2 and the requested error budget is below the minimum supported in the 5GS (e.g., 900 ns), then the TSCTSF 408 can notify the AF 402 (via NEF 300 for a 3^rd party AF) that the request is invalid or the error budget cannot be fulfilled. No further action/information toward RAN is required. However, as an option the TSCTSF 408 could be instructed to verify first whether the network allows to meet error budget below the one standardized. a. If the requested error budget is equal or larger than the minimum supported in the 5GS (e.g., 900 ns), then the request is acceptable but further action/information toward RAN is required. The per-Uu interface error budget can be calculated (e.g., by applying solution A to calculate network-part of the budget and then applying equation (2) for scenario 2). The value of the required error budget is transferred to RAN for gNB to decide which delay adjustment method to apply.

Solution A.2 — Alternative Approach

Figure 7

An alternative approach is where the TSCTSF 408 sends all the details to the base station 102 (i.e., gNB in

NR), which can then make related decisions (e.g., whether to deny the service for certain connections; and/or define which propagation delay compensation method to use). An example method performed by the TSCTSF 408 for this solution is illustrated in Figure 7. As illustrated, the TSCTSF 408 determines the network part of the 5GS synchronicity budget (step 700). This may be done as described above. In one embodiment, the network part is determined for each of the Scenarios. The TSCTSF 408 sends information including the determined network part to the base station 102 (e.g., gNB), on a per UE basis (step 702). Examples of this information are provided below. The base station 102 may then determine the per Uu interface part of the 5GS synchronicity budget based on the received information including the network part for the applicable scenario (step 704) and may perform one or more actions that involve the determined per Uu interface part (step 706). The action(s) may include, e.g., determining whether to deny the service for certain connections and/or determining which propagation delay compensation method to use.

As an example, the container sent by the TSCTSF 408 to the base station 102 (i.e., gNB in NR) could include the following series of structured data, per UE 112:

UE1 :

[PTP domain #1 /Profile; Scenario #1; Network budget #1 ; PTP domain #2/Profile; Scenario #2; Network budget #2;

PTP domain #2/Profile; Scenario #2; Network budget #2]

In one embodiment, the TSCTSF also informs the base station 102 (i.e., gNB in NR) on the expected budget taken by the UE 112 / DS-TT 404. As an example:

UE1:

[PTP domain 1/ 802. 1AS; Scenario 1; 230 ns; PTP domain 21802. 1AS; Scenario 1; 490 ns; PTP domain 3/ 802. 1AS; Scenario 2; 340 ns; PTP domain 1/ SMPTE; Scenario 1; 230 ns; PTP domain 1/ Power Profile; Scenario 3; 780 ns ; Expected UE/DS-TT budget: 70 ns ]

UE2:

[PTP domain 1/ 802. 1AS; Scenario 1; 320 ns; PTP domain 2/ 802. 1AS; Scenario 1; 180 ns; PTP domain 3/ 802. 1AS; Scenario 2; 110ns;

Expected UE/DS-TT budget: 70 ns ]

UE3:

PTP domain 1/ Power Profile; Scenario 3; 540 ns ;

Expected UE/DS-TT budget: 120 ns ]

As per examples above, there could be use cases (i.e., PTP domai ns/profiles) that, for a specific UE 112, cannot be supported even if the most accurate delay compensation method is selected and at the same time other use cases that can be supported when a less stringent delay compensation method is selected. In this case, the gNB could decide to use the less stringent method (so that only the latter use cases can be supported), as in any case even using the most stringent method would not help with the most demanding use cases.

Additional Aspects

Figure 8

Figure 8 is a schematic block diagram of a network node 800 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node 800 may be, for example, a core network node (e.g., the TSCTSF 408, a network node that implements the functionality of the TSCTSF 408 described herein, a base station 102, or a network node that implements all or part of the functionality of the base station 102 or gNB described herein. As illustrated, the network node 800 includes a control system 802 that includes one or more processors 804 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 806, and a network interface 808. The one or more processors 804 are also referred to herein as processing circuitry. In addition, if the network node 800 is a radio access node (e.g., a base station 102, gNB, or network node that implements at least some of the functionality of the base station 102 or gNB), the network node 800 may include one or more radio units 810 that each includes one or more transmitters 812 and one or more receivers 814 coupled to one or more antennas 816. The radio units 810 may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) 810 is external to the control system 802 and connected to the control system 802 via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s) 810 and potentially the antenna(s) 816 are integrated together with the control system 802. The one or more processors 804 operate to provide one or more functions of the network node 800 as described herein (e.g., one or more functions of a core network node or TSCTSF 408 described herein or one or more functions of a base station 102 or gNB described herein). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 806 and executed by the one or more processors 804.

Figure 9

Figure 9 is a schematic block diagram that illustrates a virtualized embodiment of the network node 800 according to some embodiments of the present disclosure. Again, optional features are represented by dashed boxes. As used herein, a “virtualized” network node is an implementation of the network node 800 in which at least a portion of the functionality of the network node 800 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, if the network node 800 is a radio access node, the network node 800 may include the control system 802 and/or the one or more radio units 810, as described above. The control system 802 may be connected to the radio unit(s) 810 via, for example, an optical cable or the like. The network node 800 includes one or more processing nodes 900 coupled to or included as part of a network(s) 902. If present, the control system 802 or the radio unit(s) are connected to the processing node(s) 900 via the network 902. Each processing node 900 includes one or more processors 904 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 906, and a network interface 908.

In this example, functions 910 of the network node 800 described herein (e.g., one or more functions of a core network node or TSCTSF 408 described herein or one or more functions of a base station 102 or gNB described herein) are implemented at the one or more processing nodes 900 or distributed across the one or more processing nodes 900 and the control system 802 and/or the radio unit(s) 810 in any desired manner. In some particular embodiments, some or all of the functions 910 of the network node 800 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 900. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 900 and the control system 802 is used in order to carry out at least some of the desired functions 910. Notably, in some embodiments, the control system 802 may not be included, in which case the radio unit(s) 810 communicate directly with the processing node(s) 900 via an appropriate network interface(s). In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node 800 or a node (e.g., a processing node 900) implementing one or more of the functions 910 of the network node 800 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non- transitory computer readable medium such as memory).

Figure 10

Figure 10 is a schematic block diagram of the network node 800 according to some other embodiments of the present disclosure. The network node 800 includes one or more modules 1000, each of which is implemented in software. The module(s) 1000 provide the functionality of the network node 800 described herein. This discussion is equally applicable to the processing node 900 of Figure 9 where the modules 1000 may be implemented at one of the processing nodes 900 or distributed across multiple processing nodes 900 and/or distributed across the processing node(s) 900 and the control system 802.

Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure. While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

SOME EMBODIMENTS

Some of the embodiments that have been described above may be summarized in the following manner:

1 . A method performed by a core network node (408) in a core network (110) of a cellular communications system (100) that operates as a Time-Sensitive Communication, TSC, node (400), the method comprising: determining (600) a network part of a synchronicity budget of the cellular communications system (100); determining (602) a radio interface part (e.g., per Uu interface part) of the synchronicity budget of the cellular communications system (100) based on the determined network part of the synchronicity budget of the cellular communications system (100); and performing (604) one or more actions that involve the determined radio interface part of the synchronicity budget of the cellular communications system (100).

2. The method of embodiment 1 wherein the network part of the synchronicity budget of the cellular communications system (100) is a part of the synchronicity budget of the cellular communications system (100) due to either:

(a) a first timing error, TE1 , between a base station (100; gNB1) in a radio access network, RAN, of the cellular communications system (100) and a network-side Time-Sensitive Networking, TSN, Translator, NW-TT, port of the TSC node (400) for a first scenario in which a TSC device(s) behind a particular target User Equipment, UE, (112) are synchronized to any time domain from a grand-master clock behind the core network (110); or

(b) a second timing error, TE2, between the base station (100; gNB1) and a second base station (100; gNB2) for a second scenario in which a TSC device(s) behind a particular target User Equipment, UE, (112) are synchronized to any time domain from a grand-master clock behind the particular target UE (112). 3. The method of embodiment 2 wherein the radio interface part of the synchronicity budget of the cellular communications system (100) is a maximum time synchronization error between the particular UE (112) and the radio interface of a distributed unit, DU, of the base station (102; gNB1) in the RAN of the cellular communications system (100).

4. The method of any of embodiments 1 to 3 wherein determining (600) the network part of the synchronicity budget of the cellular communications system (100) comprises: obtaining (600A) information about one or more internal timing distribution parameters of the cellular communications system (100); determining (600B) the network part of the synchronicity budget of the cellular communications system (100) based on the information about the one or more internal timing distribution parameters of the cellular communications system (100).

5. The method of embodiment 4 wherein the information about the one or more internal timing distribution parameters of the cellular communications system (100) comprises information from one or more information elements used with Precision Timing Protocol, PTP.

6. The method of embodiment 5 wherein the one or more information elements used with PTP comprise a Path Trace TLV, an Enhanced Synchronization Accuracy Metrics TLV, or both.

7. The method of embodiment 4 wherein the information about the one or more internal timing distribution parameters of the cellular communications system (100) comprises:

(i) 5GS T-GM id used by the NW-TT (406),

(ii) 5GS T-GM used by the base station (102),

(iii) Path Trace option if available for detailed information on the PTP path,

(iv) Number of hops between 5GS T -GM and the base station (102),

(v) Number of hops between 5GS T-GM and NW-TT (406),

(vi) when Enhanced Accuracy TLV is available, it can directly provide estimated time error across the PTP distribution chain, or

(vii) any combination of two or more of (i)-(vi). 8. The method of any of embodiments 1 to 7 wherein performing (604) the one or more actions that involve the determined radio interface part of the synchronicity budget of the cellular communications system (100) comprises:

A. sending (604A) assistance information to one or more base stations (102), the assistance information comprising information that is or is based on the determined radio interface part of the synchronicity budget of the cellular communications system (100);

B. making (604B) one or more decisions about whether one or more service(s) can be supported and sending feedback to one or more other nodes;

C. determining (604C) a radio link propagation delay compensation scheme to be applied, from a set of radio link propagation delay compensation schemes;

D. sending (604D) a reject message to another node upon determining that one or more services cannot be supported; or

E. any combination of two or more of A-D.

9. The method of any of embodiments 1 to 8 wherein the cellular communications system (100) is a Fifth Generation, 5G, system.

10. A method performed by a core network node (408) in a core network (110) of a cellular communications system (100) that operates as a Time-Sensitive Communication, TSC, node (400), the method comprising: determining (700) a network part of a synchronicity budget of the cellular communications system (100); and sending (702), to a base station (102), information comprising the determined network part of the synchronicity budget of the cellular communications system (100).

11 . The method of embodiment 10 wherein the network part of the synchronicity budget of the cellular communications system (100) is the part of the synchronicity budget of the cellular communications system (100) due to either:

(b) a second timing error, TE2, between the base station (100; gNB1) and a second base station (100; gNB2) for a second scenario in which a TSC device(s) behind a particular target User Equipment, UE, (112) are synchronized to any time domain from a grand-master clock behind the particular target UE (112).

12. The method of embodiment 10 or 11 wherein determining (700) the network part of the synchronicity budget of the cellular communications system (100) comprises: obtaining information about one or more internal timing distribution parameters of the cellular communications system (100); determining the network part of the synchronicity budget of the cellular communications system (100) based on the information about the one or more internal timing distribution parameters of the cellular communications system (100).

13. The method of embodiment 12 wherein the information about the one or more internal timing distribution parameters of the cellular communications system (100) comprises information from one or more information elements used with Precision Timing Protocol, PTP.

14. The method of embodiment 13 wherein the one or more information elements used with PTP comprise a Path Trace TLV, an Enhanced Synchronization Accuracy Metrics TLV, or both.

15. The method of embodiment 12 wherein the information about the one or more internal timing distribution parameters of the cellular communications system (100) comprises:

(i) 5GS T-GM id used by the NW-TT (406),

(ii) 5GS T-GM used by the base station (102),

(iii) Path Trace option if available for detailed information on the PTP path,

(iv) Number of hops between 5GS T -GM and the base station (102),

(v) Number of hops between 5GS T-GM and NW-TT (406),

(vii) any combination of two or more of (i)-(vi). 16. The method of any of embodiments 10 to 15 wherein the cellular communications system (100) is a Fifth Generation, 5G, system.

17. A core network node (408) for a core network (110) of a cellular communications system (100) that operates as a Time-Sensitive Communication, TSC, node (400), the core network node (408) adapted to perform the method of any of embodiments 1 to 16.

18. A core network node (408) for a core network (110) of a cellular communications system (100) that operates as a Time-Sensitive Communication, TSC, node (400), the core network node (408) comprising processing circuitry (804; 904) configured to cause the core network node (408) to perform the method of any of embodiments 1 to 16.

19. A method performed by network node (102) in a radio access network, RAN, of a cellular communications system (100) that operates as a Time-Sensitive Communication, TSC, node (400), the method comprising: receiving (702), from a core network node (408) in a core network of the cellular communications system (100), information comprising a network part of a synchronicity budget of the cellular communications system (100); determining (704) a radio interface part (e.g., per Uu interface part) of the synchronicity budget of the cellular communications system (100) based on the network part of the synchronicity budget of the cellular communications system (100); and performing (706) one or more actions that involve the determined radio interface part of the synchronicity budget of the cellular communications system (100).

20. The method of embodiment 19 wherein the network part of the synchronicity budget of the cellular communications system (100) is a part of the synchronicity budget of the cellular communications system (100) due to either:

21 . The method of embodiment 20 wherein the radio interface part of the synchronicity budget of the cellular communications system (100) is a maximum time synchronization error between the particular UE (112) and a distributed unit, DU, of the base station (102; gNB1) in the RAN of the cellular communications system (100).

22. The method of any of embodiments 19 to 21 wherein performing (706) the one or more actions that involve the determined radio interface part of the synchronicity budget of the cellular communications system (100) comprises:

A. making (604B) one or more decisions about whether one or more service(s) can be supported and sending feedback to one or more other nodes;

B. determining (604C) a radio link propagation delay compensation scheme to be applied, from a set of radio link propagation delay compensation schemes;

C. sending (604D) a reject message to another node upon determining that one or more services cannot be supported; or

D. any combination of two or more of A-C.

23. The method of any of embodiments 19 to 22 wherein the cellular communications system (100) is a Fifth Generation, 5G, system.

24. A network node (102) for a radio access network, RAN, of a cellular communications system (100) that operates as a Time-Sensitive Communication, TSC, node (400), the network node (102) adapted to perform the method of any of embodiments 19 to 23.

25. A network node (102; 800) for a radio access network, RAN, of a cellular communications system (100) that operates as a Time-Sensitive Communication, TSC, node (400), the network node (102) comprising processing circuitry (804; 904) configured to cause the network node (102; 800) to perform the method of any of embodiments 19 to 23.

Claims

CLAIMS What is claimed is:

2. The method of claim 1 wherein the network part of the synchronicity budget of the cellular communications system (100) is a part of the synchronicity budget of the cellular communications system (100) due to either:

3. The method of claim 2 wherein the radio interface part of the synchronicity budget of the cellular communications system (100) is a maximum time synchronization error between the particular UE (112) and the radio interface of a distributed unit, DU, of the base station (102; gNB1) in the RAN of the cellular communications system (100).

4. The method of any one of claim 1 to 3 wherein determining (600) the network part of the synchronicity budget of the cellular communications system (100) comprises: obtaining (600A) information about one or more internal timing distribution parameters of the cellular communications system (100); determining (600B) the network part of the synchronicity budget of the cellular communications system (100) based on the information about the one or more internal timing distribution parameters of the cellular communications system (100).

5. The method of claim 4 wherein the information about the one or more internal timing distribution parameters of the cellular communications system (100) comprises information from one or more information elements used with Precision Timing Protocol, PTP.

6. The method of claim 5 wherein the one or more information elements used with PTP comprise a Path Trace TLV, an Enhanced Synchronization Accuracy Metrics TLV, or both.

7. The method of claim 4 wherein the information about the one or more internal timing distribution parameters of the cellular communications system (100) comprises:

(i) 5GS T-GM id used by the NW-TT (406),

(ii) 5GS T -GM used by the base station (102),

(iii) Path Trace option if available for detailed information on the PTP path,

(iv) Number of hops between 5GS T-GM and the base station (102),

(v) Number of hops between 5GS T-GM and NW-TT (406),

(vii) any combination of two or more of (i)-(vi).

8. The method of any one of claim 1 to 7 wherein performing (604) the one or more actions that involve the determined radio interface part of the synchronicity budget of the cellular communications system (100) comprises:

A. sending (604A) assistance information to one or more base stations (102), the assistance information comprising information that is or is based on the determined radio interface part of the synchronicity budget of the cellular communications system (100); B. making (604B) one or more decisions about whether one or more service(s) can be supported and sending feedback to one or more other nodes;

E. any combination of two or more of A-D.

9. The method of any one of claim 1 to 8 wherein the cellular communications system (100) is a Fifth Generation, 5G, system.

11 . The method of claim 10 wherein the network part of the synchronicity budget of the cellular communications system (100) is the part of the synchronicity budget of the cellular communications system (100) due to either:

(b) a second timing error, TE2, between the base station (100; g NB1 ) and a second base station (100; g N B2) for a second scenario in which a TSC device(s) behind a particular target User Equipment, UE, (112) are synchronized to any time domain from a grand-master clock behind the particular target UE (112).

12. The method of claim 10 or 11 wherein determining (700) the network part of the synchronicity budget of the cellular communications system (100) comprises: obtaining information about one or more internal timing distribution parameters of the cellular communications system (100); determining the network part of the synchronicity budget of the cellular communications system (100) based on the information about the one or more internal timing distribution parameters of the cellular communications system (100).

13. The method of claim 12 wherein the information about the one or more internal timing distribution parameters of the cellular communications system (100) comprises information from one or more information elements used with Precision Timing Protocol, PTP.

14. The method of claim 13 wherein the one or more information elements used with PTP comprise a Path Trace TLV, an Enhanced Synchronization Accuracy Metrics TLV, or both.

15. The method of claim 12 wherein the information about the one or more internal timing distribution parameters of the cellular communications system (100) comprises:

(i) 5GS T-GM id used by the NW-TT (406),

(ii) 5GS T -GM used by the base station (102),

(iii) Path Trace option if available for detailed information on the PTP path,

(iv) Number of hops between 5GS T-GM and the base station (102),

(v) Number of hops between 5GS T-GM and NW-TT (406),

(vii) any combination of two or more of (i)-(vi).

16. The method of any one of claim 10 to 15 wherein the cellular communications system (100) is a Fifth Generation, 5G, system.

17. A core network node (408) for a core network (110) of a cellular communications system (100) that operates as a Time-Sensitive Communication, TSC, node (400), the core network node (408) adapted to perform the method of any one of claim 1 to 16.

18. A core network node (408) for a core network (110) of a cellular communications system (100) that operates as a Time-Sensitive Communication, TSC, node (400), the core network node (408) comprising processing circuitry (804; 904) configured to cause the core network node (408) to perform the method of any one of claim 1 to 16.

20. The method of claim 19 wherein the network part of the synchronicity budget of the cellular communications system (100) is a part of the synchronicity budget of the cellular communications system (100) due to either:

21 . The method of claim 20 wherein the radio interface part of the synchronicity budget of the cellular communications system (100) is a maximum time synchronization error between the particular UE (112) and a distributed unit, DU, of the base station (102; gNB1) in the RAN of the cellular communications system (100).

22. The method of any one of claim 19 to 21 wherein performing (706) the one or more actions that involve the determined radio interface part of the synchronicity budget of the cellular communications system (100) comprises:

D. any combination of two or more of A-C.

23. The method of any one of claim 19 to 22 wherein the cellular communications system (100) is a Fifth Generation, 5G, system.

24. A network node (102) for a radio access network, RAN, of a cellular communications system (100) that operates as a Time-Sensitive Communication, TSC, node (400), the network node (102) adapted to perform the method of any one of claim 19 to 23.

25. A network node (102; 800) for a radio access network, RAN, of a cellular communications system (100) that operates as a Time-Sensitive Communication, TSC, node (400), the network node (102) comprising processing circuitry (804; 904) configured to cause the network node (102; 800) to perform the method of any one of claim 19 to 23.