Method of handling time precision and synchronization status reports and services

Abstract

Methods, core network functions and a radio access network node are provided in which the radio access network node obtains a time precision / synchronization status report configuration from a first core network function of a core network and sends a time precision / synchronization status report to the first core network function according to the TASR configuration, and wherein the time accuracy / synchronization status report comprises one or more of a time accuracy and a time synchronization status. The TASSR configuration may be triggered by a request from a second core network function.

Description

[0001] Related applications

[0002] This application claims the benefit of provisional patent application serial number 63 / 446143, filed on February 16, 2023, the disclosure of which is hereby incorporated by reference in its entirety. Background Art

[0003] In 3GPP TR 23.700-25, "Study on Time Resilience, TSC and URLLC Enhancements" (Release 18), it was agreed that user equipment (UE) with a corresponding subscription can be informed about changes in time synchronization status. Among other things, agreement was reached on how time synchronization status information should be reported to the UE, as described in 3GPP S2-2301421, which is incorporated by reference:

[0004] “Support for network time synchronization status monitoring enables the 5G System (5GS) to modify the time synchronization service for a UE or a group of UEs based on the current synchronization status and to notify service updates. There are three possible consumers of this information:

[0005] -TSCTSF can receive node-level information about time synchronization status from NG-RAN and / or UPF / NW-TT, either directly from OAM or alternatively, if supported by the node, using node-level control plane signaling. Node-level signaling uses UMIC for UPF / NW-TT cases and AMF services for reporting N2 node-level information for NG-RAN cases.

[0006] - The AF may subscribe to time synchronization status notifications for a UE or a group of UEs that the AF requests or has requested time synchronization services (for 5G access stratum time distribution or (g)PTP services).

[0007] - For 5G access stratum time synchronization services, the UE may receive clock quality information from the NG-RAN based on the UE subscription data stored in the UDM (see clause 5.27.1.11 of TR 23.700-25, incorporated herein by reference) or an AF request for clock quality reporting to the UE.

[0008] A prerequisite for this feature is that the NG-RAN and UPF are able to locally detect and report time synchronization degradation or improvement events. However, the exact details of how this detection is done are outside the scope of 3GPP and will not be discussed: "While the time synchronization service is provided by the 5G system, based on the time distribution of the 5G access layer or (g)PTP time distribution, the network time synchronization status of the nodes involved in the operation (e.g., NG-RAN nodes and / or UPF / NW-TT) may change. The NG-RAN and UPF / NW-TT can locally detect the degradation or improvement of time synchronization."

[0009] However, for this feature to work, the NG-RAN is required to report node-level information about its time synchronization status to the core network (CN), specifically the Time Sensitive Communications and Time Synchronization Function (TSCTSF), so that the TSCTSF can identify the affected services and UEs affected by the time synchronization status degradation / failure / improvement event. However, it is still unclear what parameters the NG-RAN can use when reporting / describing the current time synchronization information, which requires feedback from the RAN working group, see 3GPP S2-2301421:

[0010] “If supported, the RAN node may be pre-configured with thresholds for each attribute described in Table 5.27.1.X-1. When the network time synchronization status exceeds the threshold (i.e., the status deteriorates), or when the network time synchronization status again satisfies the threshold (i.e., the status improves), the RAN node notifies the TSCTSF of the RAN node ID and the corresponding network time synchronization status attributes as described in this clause.

[0011] Table 5.27.1.X-1: Information elements included in NG-RAN or UPF time synchronization status information [Note 1]

[0012]

[0013] ”

[0014] Here we emphasize that not all time synchronization status characterization elements are available or can even be estimated / obtained at the NG-RAN node. Next, it is important to emphasize that the level of information that can be provided to the UE may be different and depends on the UE's subscription. If the UE has a subscription to a time synchronization service (e.g. Access Stratum-based Time Synchronization (ASTI)) and in order to be notified about changes in the time synchronization status, the "Access and Mobility Subscription Data" at the UDM also includes "Clock Quality Report Control Information" that specifies what may be reported to the UE, see 3GPP S2-2301421 reproduced below: "For 5G Access Stratum Time Synchronization Service, Clock Quality Report Control Information governs the NG-RAN time synchronization status notification to the UE." When the AMF provides the 5G Access Stratum Time Allocation Indication and Uu Time Synchronization Error Budget to the NG-RAN, the AMF also includes the Clock Quality Report Control Information provided by the TSCTSF or received from the UDM. The Clock Quality Report Control Information may be present in the AF Request or Access and Mobility Subscription Data at the UDM and contains the following fields:

[0015] -Clock quality detail level. It indicates whether and which clock quality information is to be provided to the UE and can take one of the following values: clock quality metric or acceptable / unacceptable indication.

[0016] - If the clock quality detail level is equal to "Clock quality metrics", the NG-RAN provides the UE with clock quality metrics reflecting its current time synchronization status. Clock quality metrics refer to the following information: clock accuracy, traceability to UTC and GNSS, frequency stability, parent time source, synchronization status.

[0017] - If the clock quality detail level is equal to "Acceptable / Unacceptable Indication", the UE's clock quality acceptance criteria. If the NG-RAN time synchronization status matches the acceptance criteria received from the AMF, the NG-RAN provides an acceptable indication to the UE; otherwise, the NG-RAN indicates "Unacceptable" to the UE. The acceptance criteria can be defined based on one or more of the following attributes: parent time source, traceability to UTC and GNSS, synchronization status, clock accuracy, and frequency stability.

[0018] Editor’s Note: The attributes that can be used for clock quality acceptance criteria are dependent on the RAN capabilities that determine them and pending RAN WG feedback.”

[0019] Here, it is important to highlight two aspects:

[0020] 1) Clock Quality Report Control Information Management notifies the UE of the NG-RAN time synchronization status;

[0021] 2) The attributes that can be used for clock quality acceptance criteria depend on RAN capabilities.

[0022] Finally, it is worth noting that this feature does not apply to 3GPP pre-Rel18 UEs. That is, to ensure backward compatibility with Rel-17 UEs, time synchronization status reports can only be sent to UEs if the UE has a corresponding subscription and the subscription data contains "clock quality report control information". If the AF is the requester of the ASTI service, the "clock quality report control information" can also be provided by the AF. In any case, which clock quality information to provide to the UE depends on the needs of the time service consumer, so an appropriate agreement (i.e., SLA) should exist between the 5G network operator and the client network operator, see Note 5 of 3gpp S2-2301461, which is incorporated herein by reference:

[0023] “Note 5: Whether and which clock quality information is provided to the UE depends on the needs of the time service consumer (hereinafter referred to as the client network operator). Therefore, the clock quality detail level and the clock quality acceptance criteria are based on the parameters and their values ​​specified in the agreement between the 5G operator and the client network operator. The clock quality acceptance criteria refers to the quality with which the 5G access stratum time needs to be delivered to and received by the UE (i.e., also taking into account propagation delay). Additional inaccuracies in the UE, e.g. if the 5G access stratum time is delivered to a device attached to the UE, are not included in the clock quality acceptance criteria, as they are assumed to have been budgeted by the client network operator when agreeing on the required clock accuracy with the 5G network operator.” Summary of the Invention

[0024] Certain aspects of the present disclosure and embodiments thereof may provide solutions to the foregoing or other challenges.

[0025] This disclosure proposes a solution for:

[0026] The NG-RAN / gNB indicates its support for time synchronization status reporting or how information about these NG-RAN / gNB capabilities can be reported to the CN;

[0027] The CN instructs the NG-RAN / gNB on how time accuracy / synchronization status reporting (TASSR) should be performed;

[0028] NG-RAN / gNB performs TASSR;

[0029] The UE provides information to the NG-RAN / gNB that it can receive time synchronization services (in particular, ASTI with Time Synchronization Status Report), so that the NG-RAN / gNB can direct it or use it during handover at a later stage;

[0030] The NG-RAN / gNB makes the decision to serve the UE providing ASTI service(s) or to steer it away;

[0031] The NG-RAN / gNB informs the CN (in particular, the TSCTSF via the AMF) in the event that the UE is served by an NG-RAN / gNB that does not support TASSR, so that the AF requesting the service is aware that the feature is not available and therefore its request is rejected or modified by the TSCTSF;

[0032] How to send TASSR information / capabilities to RRC connected UEs and between source and target NG-RAN / gNB.

[0033] In some embodiments, a method performed by a first core network function providing access and mobility management services is provided. The method includes the steps of providing a time accuracy / synchronization status reporting configuration to a radio access network (RAN) node to trigger a time accuracy / synchronization status report by the RAN node, and receiving, by the first core network function, one or more time accuracy / synchronization status reports generated by the RAN node based on the time accuracy / synchronization status reporting configuration. For example, the first core network function is an access mobility management function in a 5G system.

[0034] In another example, the one or more time accuracy / synchronization status reports include one or more of clock accuracy and synchronization status.

[0035] In another aspect, the method includes the steps of: upon receiving a time accuracy / synchronization status report from a RAN node, providing to the RAN node information indicating whether the RAN node is able or unable to serve a user equipment (UE) based on an access stratum time synchronization (ASTI) subscription obtained for the UE, the access stratum time synchronization subscription being obtained or triggered by a request from another core network function. The CN node may alternatively or additionally instruct the RAN node to handover the UE to a target RAN node.

[0036] In some aspects, a time accuracy / synchronization status report obtained by the first core network function from the RAN node is provided to the second network function.

[0037] In some embodiments, a method is provided which is performed by a second core network function providing a time synchronization service (e.g., a TSCSF in a 5G system), the method comprising the steps of receiving a time accuracy / synchronization status report (TASSR) request or an access stratum time synchronization (ASTI) service request originating from an application function (AF) for one or more UEs, and then receiving a time accuracy / synchronization status report generated by a radio access network (RAN) node for the one or more UEs from a first core network function (e.g., an AMF in a 5G system), and determining based on the time accuracy / synchronization status report whether the one or more UEs are served by the RAN node that supports the requested time synchronization status report from the AF, and the second core network function providing instructions to be applied to the RAN node based on the determination, for example via a first core network function such as an AMF in a 5G system.

[0038] In one example, the instructions from the second core network function include notifying the first network function of a new or modified clock quality detail level. Alternatively or additionally, the instructions include providing information to the RAN node indicating that the RAN node is capable or incapable of serving the user equipment in accordance with a requested time accuracy / synchronization status report or an ASTI service request.

[0039] According to some aspects, based on the received time accuracy / synchronization status report, the second core network function performs steps including instructions to execute a handover from a RAN node providing time accuracy / synchronization status reports for one or more UEs to a target RAN node.

[0040] In some embodiments, a method performed by a radio access network (RAN) node is provided, the method comprising: obtaining a time accuracy / synchronization status reporting configuration from a first core network function of a core network; and sending a time accuracy / synchronization status report to the first core network function according to the time accuracy / synchronization status reporting configuration, wherein the time accuracy / synchronization status report includes one or more of time accuracy and time synchronization status.

[0041] In some embodiments, the method includes the step of receiving instructions to be applied as a result of the provided time accuracy / synchronization status report.

[0042] For example, the instructions include information indicating that the RAN node can or cannot serve the user equipment (UE) according to the requested access stratum time synchronization (ASTI) subscription or UE subscription.

[0043] Alternatively or additionally, the instructions include performing a handover to a target RAN node.

[0044] In some embodiments, the method further comprises sending capability information to the core network indicating whether the RAN node is capable of performing time accuracy / synchronization status reporting.

[0045] In other aspects, the method further includes sending a time accuracy / synchronization status reporting preference to the core network.

[0046] In some embodiments, a network node or server and a radio access network node are provided and are adapted for or comprise one or more processors and a memory comprising instructions which, when executed by the one or more processors, perform any of the embodiments described herein.

[0047] In some embodiments, a non-transitory computer-readable storage medium is provided, comprising executable instructions that, when executed by a processor, cause the processor to perform any one of the embodiments appended herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] The accompanying drawings incorporated in and forming a part of this specification illustrate several aspects of the disclosure and together with the description serve to explain the principles of the disclosure.

[0049] Figure 1 An example of a wireless communication system in which embodiments of the present disclosure may be implemented is shown;

[0050] Figure 2 An example of a core network of a wireless communication system supporting time synchronization in which embodiments of the present disclosure may be implemented is shown;

[0051] Figure 3 Another example of a core network of a wireless communication system is shown, illustrating a 5G system (5GS) in a service-based architecture supporting time synchronization;

[0052] Figure 4A shows a procedure for CN procedures based on ASTI services activated by subscription according to some embodiments;

[0053] Figure 4B shows a procedure for CN procedures for ASTI services based on activation by AF request according to some embodiments;

[0054] Figure 4C shows a procedure for CN procedures for ASTI services based on activation by AF request according to some embodiments;

[0055] Figure 4D shows different TASS reporting options according to some embodiments;

[0056] Figure 4EA process for providing time accuracy information to a UE according to some embodiments is shown;

[0057] Figure 4F A process for providing time accuracy information to a UE according to other embodiments is shown;

[0058] Figure 4G A procedure for handing over a UE to a target NG-RAN node for ASTI services according to some embodiments is shown;

[0059] Figure 5A A flowchart of a method performed at an AMF according to some embodiments is shown.

[0060] Figure 5B A flow chart illustrating a method performed at a TSCTSF according to some embodiments is shown.

[0061] Figure 6 A flow chart of a method performed at an NG-RAN node according to some embodiments is shown.

[0062] Figure 7 、 8 and 9 are schematic block diagrams of example embodiments of a network node.

[0063] Figure 10 、 11 12 are schematic block diagrams of example embodiments of NG-RAN nodes. DETAILED DESCRIPTION

[0064] Generally, all terms used in this article should be interpreted according to their ordinary meaning in the relevant technical field, unless clearly given and / or different meanings are implied from the context in which they are used. Unless otherwise clearly stated, all references to element, device, assembly, device, step, etc. should be publicly interpreted as referring to at least one instance of element, device, assembly, device, step, etc. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless a step is clearly described as after or before another step and / or implicitly a step must be after or before another step. Any feature of any embodiment disclosed herein can be applied to any other embodiment where appropriate. Similarly, any advantage of any embodiment can be applied to any other embodiment, and vice versa. Other purposes, features and advantages of the attached embodiments will be apparent from the following description.

[0065] Although the embodiments are described using a 5G core network, it will be apparent to those skilled in the art that any core network that supports edge computing can implement these embodiments, including 4G, 6G, and more.

[0066] Some embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. However, other embodiments are within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as being 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.

[0067] Radio Node: As used herein, a "radio node" is a radio access node or wireless communication device.

[0068] 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 communication network that operates to transmit and / or receive signals wirelessly. Some examples of radio access nodes include, but are not limited to, a base station (e.g., a new radio (NR) base station (gNB) in a 3rd 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, etc.), 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.

[0069] Core network node: As used herein, a "core network node" is any type of node in the core network or any node that implements a core network function. Some examples of core network nodes include nodes that implement the Access and Mobility Management Function (AMF), User Plane Function (UPF), Session Management Function (SMF), Authentication Server Function (AUSF), Network Slice Selection Function (NSSF), Network Exposure Function (NEF), Network Function (NF) Storage Function (NRF), Policy Control Function (PCF), Unified Data Management (UDM), TSCTSF, and AF, among others.

[0070] Communication device: As used herein, a "communication device" is any type of device that can access an access network. Some examples of communication devices include, but are not limited to, mobile phones, smartphones, sensor devices, meters, vehicles, home appliances, medical devices, media players, cameras, or any type of consumer electronic device, such as, but not limited to, televisions, radios, lighting fixtures, tablet computers, laptop computers, or personal computers (PCs). A communication device can be a portable, handheld, computer-included, or vehicle-mounted mobile device capable of transmitting voice and / or data via a wireless or wired connection.

[0071] Wireless Communication Device: One type of communication device is a wireless communication device, which can be any type of wireless device that accesses a wireless network (e.g., a cellular network). Some examples of wireless communication devices include, but are not limited to, user equipment devices (UEs) in 3GPP networks, machine type communication (MTC) devices, and Internet of Things (IoT) devices. Such wireless communication devices can be, or can be integrated into, a mobile phone, a smartphone, a sensor device, a meter, a vehicle, a home appliance, a medical device, a media player, a camera, or any type of consumer electronic device such as, but not limited to, a television, a radio, a lighting device, a tablet, a laptop, or a PC. A wireless communication device can be a portable, handheld, computer-included, or vehicle-mounted mobile device capable of transmitting voice and / or data via a wireless connection.

[0072] Network node: As used herein, a "network node" is any node that is part of the RAN or core network of a cellular communication network / system.

[0073] Note that the description given herein focuses on 3GPP cellular communication systems and, as such, 3GPP terminology or terminology similar to 3GPP terminology is often used. However, the concepts disclosed herein are not limited to 3GPP systems.

[0074] Note that in the description herein, reference may be made to the term "cell"; however, particularly with respect to 5G NR concepts, beams may be used instead of cells, so it is important to note that the concepts described herein apply equally to both cells and beams.

[0075] Figure 1An example of a cellular communication system 100 in which embodiments of the present disclosure may be implemented is shown. In the embodiments described herein, the cellular communication system 100 is a 5G system (5GS) comprising a next generation RAN (NG-RAN) and a 5G core (5GC). In this example, the RAN includes base stations 102-1 and 102-2, which in the 5GS include NR base stations (gNBs), controlling respective (macro) cells 104-1 and 104-2. Base stations 102-1 and 102-2 are generally referred to herein as base stations 102, and individually as base stations 102. Similarly, (macro) cells 104-1 and 104-2 are generally referred to herein as (macro) cells 104, and individually as (macro) cells 104. The RAN may also include a plurality of low power nodes 106-1 to 106-4 that control corresponding small cells 108-1 to 108-4. The low power nodes 106-1 to 106-4 may be small base stations (such as pico or femto base stations) or RRHs, etc. It is noteworthy that, although not illustrated, one or more of the small cells 108-1 to 108-4 may alternatively be provided by the base station 102. The low power nodes 106-1 to 106-4 are generally referred to herein as low power nodes 106 and individually as low power nodes 106. Similarly, the small cells 108-1 to 108-4 are generally referred to herein as small cells 108 and individually as small cells 108. The cellular communication system 100 also includes a core network 110, which is referred to as 5GC in the 5G system (5GS). The base station 102 (and optionally the low power node 106) is connected to the core network 110.

[0076] Base station 102 and low power node 106 provide services to wireless communication devices 112-1 through 112-5 in respective cells 104 and 108. Wireless communication devices 112-1 through 112-5 are generally referred to herein collectively and individually as wireless communication devices 112. In the following description, wireless communication device 112 is generally a UE, but the present disclosure is not limited thereto.

[0077] Figure 2 A wireless communication system represented as a 5G network architecture consisting of core network functions (NFs) is shown, where the interaction between any two NFs is represented by point-to-point reference points / interfaces. Figure 2 can be considered as Figure 1 A specific implementation of the cellular communication system 100 is provided.

[0078] A network function (NF) can be implemented as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on a suitable platform, such as a cloud infrastructure.

[0079] From the access side, Figure 2The 5G network architecture shown includes multiple UEs 112 connected to either the RAN 102 or the access network (AN) and the AMF 200. Typically, the RAN 102 includes a base station, such as an eNB or gNB or the like. From the core network side, Figure 2 The 5GC NF shown includes NSSF 202, AUSF 204, UDM 206, AMF 200, SMF 208, PCF 210, Application Function (AF) 212, NEF and TSCTSF.

[0080] The reference points of the 5G network architecture represent detailed call flows used in developing standardization specifications. The N1 reference point is defined as carrying signaling between the UE 112 and the AMF 200. Reference points for connecting the AN 102 and the AMF 200, and between the AN 102 and the UPF 214, are defined as N2 and N3, respectively. Reference point N11 exists between the AMF 200 and the SMF 208, indicating that the SMF 208 is at least partially controlled by the AMF 200. Reference point N4 is used by both the SMF 208 and the UPF 214, enabling the UPF 214 to be configured using control signals generated by the SMF 208 and reporting its status to the SMF 208. N9 is a reference point for connections between different UPFs 214, and N14 is a reference point for connections between different AMFs 200. N15 and N7 are defined for the PCF 210 to apply policies 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 the SMF 208. Figure 2 The 5G architecture supporting time-sensitive communication and time synchronization services based on IEEE Standard 802.1AS or IEEE Standard 1588 for Ethernet or IP type PDU sessions is further shown. DS-TT, NW-TT and Time Sensitive Communication and Time Synchronization Function (TSCTSF) are required to support the features of IEEE Standard 802.1AS or IEEE Standard 1588. TSCTSF 216 supports other functions of associating time synchronization service requests from users to AF sessions with PCF (sessions between PCF and TSCTSF). TSCTSF 216 controls (one or more) DS-TT and NW-TT for time synchronization services based on (g)PTP. In addition, TSCTSF 216 supports TSC auxiliary container related functions. If the AF is considered to be operator trusted, the AF can interact with TSCTSF 216 directly over the N85 reference point, otherwise it interacts with TSCTSF 216 via NEF over the N33 reference point. For simplicity, Figure 2The connection between AF and TSCTSF 216 is not depicted in the architecture diagram. NEF discloses the 5GS capability of supporting time synchronization services, as described in clause 5.27.1.8 of 3GPP TS 23.501.

[0081] The 5GC network is designed to separate UP and CP. UP carries user services, while CP carries signaling in the network. Figure 2 In this architecture, the UPF 214 is located in the UP, and all other NFs, namely the AMF 200, SMF 208, Policy Control Function (PCF) 210, AF 212, Network Slice Selection Function (NSSF) 202, Authentication Server Function (AUSF) 204, and UDM 206, are located in the CP. Separating the UP and CP ensures that each plane's resources can be scaled independently. It also allows the UPF to be deployed separately from the CP functions in a distributed manner. In this architecture, the UPF can be deployed very close to the UE to reduce the round-trip time (RTT) between the UE and the data network for some applications that require low latency. Figure 2 The UPF / NW-TT distributes (g)PTP messages to the DS-TT. When the UPF supports one or more NW-TTs, there is a one-to-one association between the NW-TT and the network instance or between the NW-TT and the network instance and the DNN / S-NSSAI in the UPF. When there are multiple network instances within the UPF, each network instance is considered to be logically separated. During the PDU session establishment process, for a given PDU session, the network instance of the N6 interface can be indicated by the SMF to the UPF. The UPF allocates resources based on the network instance and the S-NSSAI. For a given PDU session during the PDU session establishment process, the DNN / S-NSSAI can be indicated by the SMF together with the network instance to the UPF.

[0082] For a given DNN / S-NSSAI, the same NW-TT is used for all PDU sessions in the UPF; the NW-TT is unique according to the DNN / S-NSSAI. This ensures that the UPF selects the N4 session associated with the correct TSCTSF 216 when the NW-TT initiates a User Plane Node Management Information Container (UMIC) or Port Management Information Container (PMIC). Port management information is transparently transferred via the 5GS between the TSN AF or TSCTSF 216 inside the PMIC and the DS-TT or NW-TT, respectively. User plane node management information is transparently transferred via the 5GS between the TSN AF or TSCTSF 216 and the NW-TT inside the UMIC. At any given time, the NW-TT is associated with a single TSCTSF.

[0083] The core 5G network architecture consists of modular functions. For example, AMF 200 and SMF 208 are independent functions in CP. Separating AMF 200 and SMF 208 allows independent evolution and scaling. Other CP functions such as PCF 210 and AUSF 204 can be Figure 2 The modular functional design enables the 5GC network to flexibly support various services.

[0084] Each NF interacts directly with another NF. Messages can be routed from one NF to another using intermediate functions. In the CP, a set of interactions between two NFs is defined as a service, enabling reuse. This service supports modularity. The UP supports interactions such as forwarding operations between different UPFs.

[0085] Figure 3 shows a 5G network architecture using service-based interfaces between NFs in the CP, rather than in Figure 2 Point-to-point reference points / interfaces used in the 5G network architecture. Figure 2 The NF described corresponds to Figure 3 The services (one or more) provided by the NF to other authorized NFs can be exposed to the authorized NF through a service-based interface. Figure 3 In the NF, the service-based interface is indicated by the letter “N” followed by the name of the NF, such as Namf for the service-based interface of AMF 200 and Nsmf for the service-based interface of SMF 208, etc. However, it should be clarified that Figure 2 All NFs depicted in the can be used with Figure 3 The NEF and NRF interact, although Figure 2 There is no clear instruction.

[0086] Figure 2 and Figure 3Some properties of the NFs shown in the figure can be described as follows. The AMF 200 provides UE-based authentication, authorization, mobility management, etc. Even UEs using multiple access technologies are basically connected to a single AMF because the AMF 200 is independent of the access technology. The SMF is responsible for session management and allocates an Internet Protocol (IP) address to the UE. It also selects and controls the UPF for data transmission. If the UE has multiple sessions, a different SMF can be assigned to each session to manage them separately, and each session may provide different functions. The AF provides information about packet flows to the PCF responsible for policy control in order to support QoS. Based on this information, the PCF determines policies regarding mobility and session management so that the AMF 200 and SMF operate correctly. The AUSF supports the authentication function of the UE or the like and therefore stores data for authentication of the UE or the like, while the UDM 206 stores the subscription data of the UE. The data network (DN) is not part of the 5GC network and provides Internet access or operator services, etc. TSCTSF 216 provides multiple services via Ntsctsf API, primarily Ntsctsf_TimeSynchronization, which provides a time synchronization service based on (g)PTP or 5G access layer time allocation method, and allows NF consumers to subscribe to UE and 5G core (5GC) capabilities for (g)PTP or 5G access layer time synchronization services, and allows NF consumers to configure UE and 5GC for (g)PTP-based time synchronization services. TSCTSF 216 also supports Ntsctsf_ASTI service, which provides support for Ntscfor time synchronization service based on 5G access layer time allocation method as described in Section 5.27.1.8 of 3GPP TS23.501V.17.6.0 (incorporated herein by reference), and allows NF consumers to configure 5G core and RAN for 5G access layer-based time synchronization service for UE. AF can access the service directly via Ntsctsf API or via NEF using Nnef API.

[0087] NFs can be implemented as network elements on dedicated hardware, as software instances running on dedicated hardware, or as virtualized functions instantiated on a suitable platform such as a cloud infrastructure.

[0088] The description now turns to some specific embodiments of the present disclosure. There are currently one or more challenges. Current solutions do not describe signaling support for providing NG-RAN time synchronization capability information from the gNB to the CN. As a result, the CN is effectively unaware of the gNB's time synchronization capabilities (particularly, time accuracy).

[0089] Solutions are needed for situations including the following:

[0090] a. gNB that does not support time synchronization status reporting, or

[0091] b. The gNB is not able to provide any of the information elements specified by the “Clock Quality Metrics” agreed between the 5G Network Operator and the Client Network Operator, or

[0092] c. When the gNB cannot provide a certain time accuracy as a service.

[0093] This feature is optional, so not all gNBs may be mandated to provide this support, similar to UEs, where it has been agreed in 3GPP that this feature does not apply to pre-Rel 18 UEs as described in 3GPP TR 23.700-25 V.18.0.0.

[0094] Figure 4A is a flow chart illustrating how time accuracy / synchronization status reporting (TASSR) may be configured in NG-RAN / gNB 102 according to one or more embodiments.

[0095] exist Figure 4A In step 1, the NG-RAN / gNB 102 may indicate to the CN (AMF 200 or SMF, the embodiments herein are described using AMF, but may not be limited thereto) through the NG-AP its ability to support time accuracy / synchronization status (TASSR) reporting or how it may perform TASSR reporting. The NG-RAN / gNB 102 may indicate its support for TASSR and, optionally, its preference for TASSR reporting in the NG Setup Request message. However, other appropriate NG-AP messages may also be used. The CN (AMF) determines the TASSR configuration based on different inputs including NG-RAN / gNB capabilities, UE subscription and / or O&M information. In Figure 4A At step 2 of the NG-RAN / gNB 102, the CN (AMF) sends a TASSR configuration to the gNB 102 indicating how TASSR should be performed (e.g., on-demand reporting, periodicity, event triggering such as threshold-based). The CN (AMF) may provide the TASSR configuration in the NG Setup Response message as part of the NG Setup procedure. Alternatively, other NG-AP procedures may be used. Based on the request from the CN and the NG-RAN / gNB capabilities, the NG-RAN / gNB 102 performs TASSR. Additionally, the NG-RAN / gNB 102 may indicate its support for certain slices (e.g., based on the range of time accuracy it supports).

[0096] Figure 4AThe steps in step 1 may not follow the specific order described. For example, the AMF 200 may trigger a report request (i.e., without a request from the NG-RAN / gNB), and the NG-RAN / gNB 102 may provide feedback as in step 1. In this case, other appropriate NG-AP messages or new procedures may be used to implement the solution.

[0097] Figure 4B and 4C Two options are described for CN behavior when NG / RAN / gNB 102 reports time synchronization status according to some embodiments (option 1: subscription-based, and option 2: AF-request-based).

[0098] The following diagram shows Option 1 (subscription based): Figure 4B :

[0099] Step 1. One or more UEs register with the core network. As part of the registration, the Access Stratum Time Synchronization (ASTI) service should be activated based on one or more UE subscriptions. The details of the registration are omitted as they are described in 3GPP TS 23.502 V.18.0.0.

[0100] Step 2. As part of the registration process, the AMF 200 obtains one or more UE subscription data from the UDM 206. The subscription data includes clock quality report control information. The one or more UEs may be individually identified or may be identified by a group identifier.

[0101] Step 3. The NG-RAN / gNB 102 reports the TASSR information to the AMF 200 in the core network. The NG-RAN / gNB 102 may have several options to report the time synchronization status (TASSR report) to the core network (CN), such as Figure 4D As illustrated in , the options include, for example, indicating that the information is not available, or providing a range of values ​​for the time precision that it can support (e.g., 100ns-250ns, 500ns-900ns, etc.), or providing specific values ​​for each / some of the metrics. If some metrics that need to be reported are not available at the NG-RAN node (due to implementation limitations, etc.), the NG-RAN node may report that metric as "not available" while reporting other metrics that are available, or may not report anything at all.

[0102] Step 4. Upon receiving the information from the NG-RAN / gNB, the CN / AMF 200 may perform the following actions for Option 1, i.e., when activating the ASTI service based on the UE's subscription (i.e., without an AF request). The CN (AMF) determines whether the current NG-RAN / gNB 102 is capable of serving the one or more UEs with the subscribed ASTI service. If the determination is positive, the CN (AMF) proceeds to Step 5; otherwise, it stops.

[0103] Step 5. The CN (AMF) sends to the NG-RAN the identities of one or more UEs that can or cannot be served or should be handed over to another NG-RAN / gNB 102 based on the status of the subscription to the ASTI service for the one or more UEs.

[0104] Step 6. Each of the one or more UEs receives the ASTI service (with time synchronization status report) to which it has subscribed.

[0105] It should be noted that Figure 4B The process in may be performed for a group of UEs or for one UE.

[0106] Note that step 5 may be triggered by the AMF 200 if the AMF 200 receives a change in subscription to the ASTI service for any one of the one or more UEs 112 previously indicated to the NG-RAN / gNB.

[0107] The actual messages used between the CN and the NG-RAN / gNB 102 nodes may be any suitable NG-AP messages or new messages may be used.

[0108] Option 2 (request-based AF) is now described in detail. Figure 4C :

[0109] Step 0: One or more UEs register with the core network. The one or more UEs may or may not establish a PDU session.

[0110] Step 1. The AF sends a request to the TSCTSF 216 (optionally via the Network Exposure Function NEF, not shown in the figure) to request the ASTI service with time synchronization status report, and may include "Clock Quality Report Control Information".

[0111] Step 2. The TSCTSFF obtains one or more UE subscription data from the UDM 206. The subscription data includes clock quality report control information. The TSC TSF 216 may also check whether the AF request complies with the UE's subscription. The AF may identify an individual UE, or one or more UEs, via a list of group identifiers or an array of UE identifiers.

[0112] Step 3. One or more NG-RAN / gNB reports are TASSR information to the AMF 200 or one or more AMFs in the core network. The AMF 200 corresponds to the gNB 102 from which it receives the reporting configuration information ( Figure 4A ) and one or more UEs register with its AMF 200 at step 0. The NG-RAN / gNB 102 may have several options to report the time synchronization status (TASSR reporting) to the core network (CN), such as Figure 4D As illustrated in , the options include, for example, indicating that the information is not available, or providing a range of values ​​for the time precision that it can support (e.g., 100ns-250ns, 500ns-900ns, etc.), or providing specific values ​​for each / some of the metrics.

[0113] Step 4. Upon receiving the information from the NG-RAN / gNB, the CN / AMF 200 (directly or via the PCF) forwards the received TASSR information to the TSCTSF 216 reported by the NG-RAN / gNB.

[0114] Step 5. The TSCTSF 216 determines whether the one or more UEs are served by (one or more) NG-RAN / gNBs that can support the requested time synchronization status reporting.

[0115] Step 6. If the NG-RAN / gNB lacks the required TASSR capabilities, the TSCTSF 216 may

[0116] (a) lowering the level of time synchronization status information set for the UE,

[0117] (b) decide not to perform the report while maintaining the ASTI service,

[0118] (c) triggering a UE handover (as in step 5 of option 1),

[0119] (d) Deactivate the ASTI Service.

[0120] Step 7. (Optional and conditional on step 6) TSCTSF 216 may inform AF of the result of step 6 and instruct the action to be taken by TSCTSF. In addition, it may also request confirmation of the indicated action from AF.

[0121] Step 8. (Optional and conditional on step 6) After deciding on the action (and optionally after receiving confirmation from the AF when requested), the TSCTSF 216 either informs the AMF 200 (directly or via the PCF) about the new "modified" clock quality detail level or the TSCTSF 216 notifies the AMF 200 (directly or via the PCF) about the new "modified" clock quality detail level. Figure 4B Triggered at step 5 of (Option 1).

[0122] Step 9. Each of the one or more UEs receives the ASTI service with the requested time synchronization status report, a modified reporting level of the ASTI service, or the requested ASTI service is not provided / supported.

[0123] The messages used between the CN and the NG-RAN / gNB 102 nodes may be any suitable NG-AP messages or new messages may be used.

[0124] Figure 4D Different TASSR reporting options from NG-RAN / gNB 102 to the core network are shown. Figure 4B and Figure 4C As indicated in step 3 of , the NG-RAN / gNB 102 may have several options for reporting the time synchronization status (TASSR reporting) to the core network (CN), including

[0125] Step 1a. NG-RAN / gNB 102 performs TASSR reporting indicating that the time synchronization status is unavailable, or

[0126] Step 1b. The NG-RAN / gNB 102 performs TASSR reporting indicating a time synchronization status value range with low and high bounds (e.g., 100ns-250ns, 500ns-900ns, etc.), or

[0127] Step 1c. The NG-RAN / gNB 102 performs TASSR reporting and provides specific time synchronization status values ​​for each / some metrics.

[0128] The following table shows an example of what the NG-RAN node may indicate to the AMF 200 in a report:

[0129] Information elements included in NG-RAN or UPF time synchronization status information

[0130]

[0131] Figure 4E 1 shows a flow diagram of providing time accuracy information to UE 112 according to some embodiments. Note that Figure 4E The process in Figure 4B and Figure 4C Either option 1 or option 2 as described in . For option 2, although Figure 4E Only the AMF 200 is shown, but it will be understood that signaling from the AMF 200 can be triggered by the TSCTSF.

[0132] Step 1. The CN (AMF) signals to the NG-RAN / gNB 102 one or more UEs that are subscribed to the ASTI service and includes time accuracy information. The CN (AMF) may take into account the information from the NG-RAN / gNB 102 and only provision the UE(s) at the NG-RAN / gNB 102 that supports the required TASSR capabilities. The CN (AMF) may signal the NG-RAN / gNB 102 using the Initial Context Setup Request message after UE registration (other suitable NG-AP messages may also be used).

[0133] Step 2. The NG-RAN / gNB 102 supports UEs with subscribed services and sends time accuracy information (obtained from the CN (AMF) or provided by the NG-RAN / gNB) to the UE 112 using SRB, for example, in an RRC reconfiguration message or other RRC messages.

[0134] Figure 4F 1 shows a flow chart of providing time accuracy information to UE 112 according to other embodiments. Note that Figure 4E The process in Figure 4B and Figure 4C Either option 1 or option 2 described in . For option 2, although Figure 4E Only the AMF 200 is shown, but it will be understood that signaling from the AMF 200 can be triggered by the TSCTSF.

[0135] exist Figure 4F In the example, the CN (AMF) does not necessarily have information indicating that the NG-RAN / gNB 102 supports UE 112 with ASTI service. This information is received after step 1.

[0136] Step 1. The CN (AMF) signals the NG-RAN / gNB 102 to one or more UEs that have subscribed to the ASTI service.

[0137] Step 2. The NG-RAN / gNB 102 indicates to the CN (AMF) whether it supports or that it supports the ASTI service for the UE 112 or that support for the service may be at the NG-RAN / gNB level instead of the UE level.

[0138] Step 3. When the AMF 200 receives an indication that the NG-RAN / gNB 102 supports the ATIS service, it sends time accuracy information to the NG-RAN / gNB 102 to be provided to the UE. The time accuracy information may be included in an NG-AP message, which the NG-RAN then provides to the UE 112 in an RRC message. Alternatively, the time accuracy information may be included in a NAS PDU message included in an appropriate NG-AP message (e.g., DL NAS Transfer, Context Modification, etc.), which the NG-RAN / gNB 102 relays to the UE 112 in step 4.

[0139] Figure 4G A flow chart is shown for triggering handover of a UE 112 with an active ASTI subscription from a source NG-RAN / gNB to a target NG-RAN / gNB according to other embodiments. Note that Figure 4E The process in Figure 4B and Figure 4C Either option 1 or option 2 described in . For option 2, although Figure 4E Only the AMF 200 is shown, but it will be understood that signaling from the AMF 200 can be triggered by the TSCTSF.

[0140] The NG-RAN node / gNB 102 may steer the UE 112 to suit ASTI services and may use the UE ASTI information to enhance handover and dual connectivity.

[0141] Step 1. The source NG-RAN (gNB) (102S) triggers a handover request to the target NG-RAN / gNB. The handover request indicates that the handover is for a UE 112 that has an ASTI subscription or for a UE 112 that requires ASTI services. An information element may be included to explicitly indicate that the UE 112 has an ASTI subscription or requires ASTI services.

[0142] Step 2. The target NG-RAN / gNB (102T) determines that it supports the time accuracy service and accepts the handover request. If the target NG-RAN / gNB (102T) does not support the time accuracy service and the service is indicated as critical in the handover request, it rejects the handover request.

[0143] Figure 5A is a flow chart illustrating an embodiment in a CN function (eg, AMF).

[0144] Step 500A. The core network (CN) function determines a TASSR configuration indicating that TASSR should be performed by the NG-RAN node and may indicate how reporting should be performed. Reporting can be on-demand, periodic, or event-triggered. For example, the CN function provides the NG-RAN node with thresholds and configurations to trigger reporting. In one embodiment, the CN function determines this based on O&M information, which may include information about support for time accuracy services / ASTI services in the NG-RAN node and the types of reports supported. Alternatively, the CN function obtains information indicating how the NG-RAN node supports TASSR, whether it is capable of performing TASS reporting or supporting ASTI service capabilities, and may obtain reporting preferences directly from the NG-RAN node itself. The NG-RAN node may have very stable time accuracy (e.g., an expensive oscillator) and indicate to the CN function that it only needs to report when there are significant variations (e.g., exceeding x% deviation), in which case the CN function should not request periodic reporting. Additionally, if the NG-RAN node performs periodic reporting, the NG-RAN node may indicate how often this should be reported for consideration by the CN function. In summary, the reporting preferences that may be indicated by the NG-RAN node to the CN function may be on-demand, periodic or event-triggered.

[0145] In another embodiment, the CN function receives from the NG-RAN node that it supports ASTI UE in some specific network slice NSSAI, and the CN function uses this information to set up the UE(s) at the correct network slice.

[0146] Step 520A. The CN function provides the determined TASSR configuration to the NG-RAN node.

[0147] In one embodiment, the CN function uses the NG setup procedure to provide TASSR configuration or obtain TASSR support and preferences from the NG_RAN node.

[0148] Step 540A. The CN function receives (one or more) TASSR reports from the NG-RAN node according to the TASSR configuration. More specifically, the CN function receives a time synchronization status report, for example, indicating that information is not available, or providing a range of values ​​for the time accuracy it can support (e.g., 100ns-250ns, 500ns-900ns, etc.), or providing specific values ​​for each / some of the metrics.

[0149] In a further embodiment, the CN function receives a registration from the UE 112 and obtains the UE subscription for access stratum time synchronization (ASTI). The UE subscription includes subscribed clock quality report control information, and after step 540A, the CN function determines whether the NG-RAN node providing TASSR (reporting) is able to serve the UE with the subscribed ASTI service.

[0150] In response to this determination, in one embodiment, the CN function may inform the NG-RAN node serving UE 112 that it can or cannot serve UE 112 according to its subscribed ASTI services. Alternatively, the CN function may inform the NG-RAN node that a handover to a target NG-RAN node may be performed.

[0151] In another embodiment, the CN function includes the time accuracy information in the initial context setup request. Alternatively, the CN function sends the time accuracy information to the NG-RAN node when establishing a specific service, for example, at PDU session establishment or context modification.

[0152] In another embodiment, the CN function receives from the NG-RAN node that it cannot perform TASSR, then the CN function uses information obtained from other sources, such as OAM, to make an estimate of the time accuracy and includes it in dedicated signaling to the UE, for example, by sending the time accuracy information in a dedicated NAS message relayed by the NG-RAN node to the UE. In another embodiment, if the NG-RAN node indicates that TASSR is not supported, then the CN function may trigger a handover from the source NG-RAN node to the target NG-RAN node.

[0153] In another embodiment, if the CN function receives a message from the NG-RAN node that it cannot perform TASSR, the CN function may send a UPF TASSR to the NG-RAN node to assist the NG-RAN node in calculating the network time accuracy.

[0154] In another embodiment, upon receiving the TASSR report from the NG-RAN node, the CN function determines whether the requested time synchronization status reporting level can be performed at the current UE location and the current NG-RAN node or should be modified, or whether a handover procedure should be triggered, etc. Figure 4B 、 4C and as described in 4G.

[0155] Figure 5B is a flow chart illustrating an embodiment in a second CN function (eg, TSCTSF) (option 2)

[0156] Step 500B. The second CN function receives the ASTI service request which may include clock quality reporting control information from the AF (via the NEF, optionally), retrieves subscription data including subscription lock quality reporting control information, and checks whether the AF request complies with the UE's subscription.

[0157] Step 520B. The second CN function receives (via another function, such as PCF) TASSR information generated from the NG-RAN node. More specifically, the TASSR information includes a time synchronization status report, for example, indicating that the information is not available, or providing a range of values ​​for the time accuracy that it can support (e.g., 100ns-250ns, 500ns-900ns, etc.), or providing specific values ​​for each / certain metrics.

[0158] Step 540B. The second CN function determines whether the UE is served by (one or more) NG-RAN nodes that can support the requested time synchronization status reporting (from the AF). In some embodiments, if the second CN function determines that the NG-RAN node lacks the required TASSR capability, the second CN function may (a) reduce the level of time synchronization status information set to the UE, (b) decide not to perform reporting while maintaining ASTI service, (c) trigger handover of the UE to the target NG-RAN, and (d) deactivate ASTI service. The second CN function may notify the AF of the selected action and may request confirmation of the indicated action(s) from the AF.

[0159] Step 560B. The second CN NF provides instructions to the CN function (e.g., AMF) to be executed with the NG-RAN node(s) and / or information to be provided to the NG-RAN node(s). For example, the second CN function may notify a new or modified clock quality detail level to be provided to the NG-RAN node. Alternatively, the second CN function may trigger the CN function (AMF) to notify the NG-RAN node serving UE 112 that it can or cannot serve UE 112 based on the requested time accuracy / synchronization status report or the ASTI service request from the AF. Alternatively, the CN function (AMF) may notify the NG-RAN node that a handover to the target NG-RAN node may be performed.

[0160] Figure 6 is a flow chart illustrating one or more embodiments in an NG-RAN node.

[0161] Step 600. The NG-RAN node obtains TASSR configuration. In one embodiment, before obtaining TASSR configuration from the CN, the NG-RAN node may indicate to the CN its support for time accuracy reporting or how it can provide reporting.

[0162] More specifically

[0163] NG-RAN nodes to indicate whether they support TASSR;

[0164] • The NG-RAN node to indicate how it supports TASSR, e.g. reporting a coarse value, reporting one or more ranges (low, high), or exact value(s).

[0165] NG-RAN nodes prefer to report based on event triggers, reporting when changes occur

[0166] NG-RAN nodes prefer periodic reporting and propose the correct periodicity value.

[0167] Step 610: The NG-RAN node sends a report TASSR to the CN according to the TASSR configuration.

[0168] Step 620. As a result of the report, the NG-RAN node may obtain further instructions or information as a result of the TASSR provided to the CN. More specifically, in one embodiment, when the NG-RAN node receives from the CN that the UE has subscribed to the ASTI, the NG-RAN node

[0169] The UE can be directed to a specific slice to handle the service, or

[0170] • The UE may be directed away, for example via handover or redirection.

[0171] In another embodiment, the NG-RAN node may store the UE ASTI information (sent by the CN) in the UE context and use it to enhance handovers, which may be instructed by the CN or initiated by the NG-RAN node, more specifically:

[0172] The NG-RAN node may select the correct target NG-RAN node based on its support for Access Stratum-based Time Distribution Service (ASTI) for the UE, or

[0173] The target NG-RAN node may accept or reject the UE handover based on its support for access stratum-based time-distributed services

[0174] In another embodiment, the NG-RAN node may store the UE ASTI information sent by the CN in the UE context and use it to enhance dual connectivity:

[0175] If dual connectivity is set up, the MN (Primary NG-RAN Node) can use this information to select the correct SN (Secondary NG-RAN Node)

[0176] • The SN can use this information to determine whether it accepts or rejects the addition.

[0177] In another embodiment, when the NG-RAN node receives a TASSR request from the CN, the TASSR request may include a validity period indicating how long the TASSR is valid or may include a validity condition. This will prevent frequent signaling of reports or frequent signaling of reports when no changes have occurred.

[0178] In another embodiment, the NG-RAN node may obtain UE ASTI related information through the RRC layer.

[0179] One or more advantages of the embodiments presented in this specification include enabling NG-RAN nodes to report their Time Accuracy / Synchronization Status Reporting (TASSR) capabilities to the Core Network (CN), allowing the CN to use this information to

[0180] (1) Modify the clock quality detail level provided to the UE,

[0181] (2) triggering UE handover to another gNB 102, i.e., an NG-RAN node with the required TASSR capabilities,

[0182] (3) inform the AF (if it is the requestor of the ASTI service) as to why the ASTI service was or will be denied following confirmation, and / or

[0183] (4) The time synchronization status report is rejected due to gNB (NG-RAN) node limitations (e.g., due to the UE's current location or the current serving gNB's own limitations).

[0184] Figure 77 is a schematic block diagram of a network node 700 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. Network node 700 may be, for example, a core network node that implements a NF (e.g., AMF 200, SMF 208, UDM 206, TSCTSF, AF, PCF) or a network node that implements all or part of the functionality of a NF (e.g., all or part of the functionality of the AMF 200, SMF 208, UDM 206, TSCTSF, AF, PCF described herein). As shown, network node 700 includes one or more processors 704 (e.g., a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and / or the like), a memory 706, and a network interface 708. The one or more processors 704 are also referred to herein as processing circuitry. The one or more processors 704 operate to provide one or more functions of network node 700 as described herein (e.g., one or more functions of the AMF 200, SMF 208, UDM 206, TSCTSF, AF, PCF described herein). In some embodiments, the functionality is implemented in software stored, for example, in memory 706 and executed by one or more processors 704 .

[0185] Figure 8 is a schematic block diagram illustrating a virtualized embodiment of a network node 700 according to some embodiments of the present disclosure. Likewise, optional features are represented by dashed boxes. As used herein, a "virtualized" network node is an implementation of a network node 700 in which at least a portion of the functionality of the network node 700 is implemented as a virtual component (e.g., via virtual machine(s) executing on physical processing nodes in the network(s)). As shown, in this example, the network node 700 includes one or more processing nodes 800 coupled to or included as part of network(s) 802. Each processing node 800 includes one or more processors 804 (e.g., CPUs, ASICs, FPGAs, and / or the like), memory 806, and a network interface 808. In this example, the functionality 810 of the network node 700 described herein (e.g., one or more of the functionality of the AMF 200, SMF 208, UDM 206, TSCTSF, AF, PCF described herein) is implemented at one or more processing nodes 800 or distributed across two or more processing nodes 800 in any desired manner. In some specific embodiments, some or all of the functionality 810 of the network node 700 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) 800 .

[0186] In some embodiments, a computer program comprising instructions is provided that, when executed by at least one processor, causes the at least one processor to perform the functions of a network node 700 or a node (e.g., processing node 800) that implements one or more functions 810 of a network node 600 in a virtual environment according to any of the embodiments described herein. 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 a memory).

[0187] Figure 9 is a schematic block diagram of a network node 700 according to some other embodiments of the present disclosure. The network node 700 includes one or more modules 900, each of which is implemented in software. (Multiple) modules 900 provide the functionality of the network node 700 described herein. This discussion also applies to Figure 8 800 , where module 800 may be implemented at one of processing nodes 800 or distributed across multiple processing nodes 800 .

[0188] Any appropriate steps, methods, features, functions or benefits disclosed herein may be performed by one or more functional units or modules of one or more virtual devices. Each virtual device may include a plurality of these functional units. These functional units may be implemented via processing circuits and other digital hardware, and the processing circuits may include one or more microprocessors or microcontrollers, and the other digital hardware may include digital signal processors (DSPs), dedicated digital logic, etc. The processing circuits may be configured to execute program codes stored in a memory, and the memory may include one or more types of memory, such as read-only memory (ROM), random access memory (RAM), cache memory, flash memory devices, optical storage devices, etc. The program codes stored in the memory include program instructions for executing one or more telecommunications and / or data communication protocols and instructions for executing one or more technologies described herein. In some embodiments, the processing circuit may be used to cause the corresponding functional units to perform the corresponding functions according to one or more embodiments of the present disclosure.

[0189] Figure 101 is a schematic block diagram of a radio access node 1100 according to some embodiments of the present disclosure. Radio access node 1100 may be, for example, base station 302 or 306. As shown, radio access node 1100 includes a control system 1102, which includes one or more processors 1104 (e.g., a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and / or the like), a memory 1106, and a network interface 1108. The one or more processors 1104 are also referred to herein as processing circuitry. Furthermore, radio access node 1100 includes one or more radio units 1110, each of which includes one or more transmitters 1112 and one or more receivers 1114 coupled to one or more antennas 1116. Radio unit 1110 may be referred to as, or part of, radio interface circuitry. In some embodiments, radio unit(s) 1110 are external to control system 1102 and connected to control system 1102 via, for example, a wired connection (e.g., a fiber optic cable). However, in some other embodiments, the radio unit(s) 1110 and potentially the antenna(s) 1116 are integrated with the control system 1102. The one or more processors 1104 operate to provide one or more functions of the radio access node 1100 as described herein. In some embodiments, the functions are implemented in software stored, for example, in the memory 1106 and executed by the one or more processors 1104.

[0190] Figure 12 1 is a schematic block diagram illustrating a virtualized embodiment of a radio access node 1100 according to some embodiments of the present disclosure. The discussion is also applicable to other types of network nodes. Further, other types of network nodes may have similar virtualized architectures.

[0191] As used herein, a "virtualized" radio access node is an implementation of a radio access node 1100 in which at least a portion of the functionality of the radio access node 1100 is implemented as virtual components (e.g., via virtual machines executing on physical processing nodes in a network). As shown, for example, the radio access node 1100 includes a control system 1102, which includes one or more processors 1104 (e.g., CPUs, ASICs, FPGAs, and / or the like), a memory 1106, and a network interface 1108, as well as one or more radio units 1110, each of which includes one or more transmitters 1112 and one or more receivers 1114 coupled to one or more antennas 1116, as described above. The control system 1102 is connected to the radio units 1110 via, for example, optical cables. The control system 1102 is connected to one or more processing nodes 1200, which are coupled to or included as part of the network(s) 1202 via a network interface 1108. Each processing node 1200 includes one or more processors 1204 (eg, CPUs, ASICs, FPGAs, and / or the like), memory 1206 , and a network interface 1208 .

[0192] In this example, the functionality 1210 of the radio access node 1100 described herein is implemented at one or more processing nodes 1200 or distributed across the control system 1102 and one or more processing nodes 1200 in any desired manner. In some specific embodiments, some or all of the functionality 1210 of the radio access node 1100 described herein is implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 1200. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node 1200 and the control system 1102 is used in order to perform at least some of the desired functionality 1210. Notably, in some embodiments, the control system 1102 may not be included, in which case the radio(s) 1110 communicate directly with the processing node(s) 1200 via appropriate network interface(s).

[0193] In some embodiments, a computer program comprising instructions is provided that, when executed by at least one processor, causes the at least one processor to perform the functions of the radio access node 1100 or a node (e.g., processing node 1200) in a virtual environment that implements one or more of the functions 1210 of the radio access node 1100 according to any embodiment described herein. 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 a memory).

[0194] Figure 11 is a schematic block diagram of a radio access node 1100 according to some other embodiments of the present disclosure. The radio access node 1100 includes one or more modules 1300, each of which is implemented in software. The modules 1300 provide the functionality of the radio access node 1100 described herein. This discussion also applies to Figure 12 1200 , where module 1300 may be implemented at one of processing nodes 1200 or distributed across multiple processing nodes 1200 and / or distributed across processing node(s) 1200 and control system 1102 .

[0195] Although the processes in the accompanying figures may illustrate 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 operations in a different order, combine certain operations, overlap certain operations, etc.).

[0196] Implementation method:

[0197] Following are several examples of similar embodiments of the non-limiting claims.

[0198] Group A: AMF

[0199] Embodiment 1. A method comprising:

[0200] Determine the Time Accuracy / Synchronization Status Report (TASSR) configuration;

[0201] providing the TASSR configuration to the NG-RAN node; and

[0202] Receive a time accuracy / synchronization status (TASS) report from the NG-RAN node according to the TASSR configuration.

[0203] Implementation 2. The method of implementation 1 further includes providing, in response to the received TASS report, information to the NG-RAN node indicating whether the NG-RAN node can or cannot serve the user equipment based on the UE's access stratum time synchronization (ASTI) subscription.

[0204] Embodiment 3. The method of embodiment 1 further includes instructing the NG-RAN node to hand over the UE to the target NG-RAN node in response to the received TASS report.

[0205] Group B: TSCTSF

[0206] Embodiment 4. A method comprising:

[0207] receiving a time accuracy / synchronization status report (TASSR) request or an access stratum time synchronization (ASTI) service request originating from an application function (AF) for one or more UEs;

[0208] receiving a time accuracy / synchronization status TASS report generated by the NG-RAN node(s) for the one or more UEs;

[0209] determining, based on the TASS report, whether the one or more UEs are served by an NG-RAN node that supports the requested time synchronization status reporting from the AF; and

[0210] providing instructions to be applied to the NG-RAN node based on the determination.

[0211] Embodiment 5. The method of embodiment 4, wherein the instructing includes notifying a second network function (eg, AMF) of the new or modified clock quality detail level.

[0212] Embodiment 6. A method as in embodiment 4, wherein the instruction includes providing information to the NG-RAN node indicating whether the NG-RAN node can or cannot serve the user equipment according to the requested time accuracy / synchronization status report / ASTI service request.

[0213] Embodiment 7. The method of embodiment 4, wherein based on the TASS report, it is determined not to perform reporting while maintaining ASTI service.

[0214] Embodiment 8. The method of embodiment 4, wherein based on the TASS report, determining an instruction to perform a handover from the NG-RAN node providing TASS reports for one or more UEs to a target NG-RAN node.

[0215] Group C: gNB

[0216] Embodiment 9. A method comprising:

[0217] Get the Time Accuracy / Synchronization Status Report (TASSR) configuration;

[0218] Send time accuracy / synchronization status TASS report to the core network (CN) according to TASSR configuration,

[0219] Instructions are received to be applied as a result of the provided TASS report.

[0220] Embodiment 10. The method of embodiment 9, wherein the instruction includes indicating that the NG-RAN node can or cannot serve the user equipment based on the requested time accuracy / synchronization status report or UE subscription.

[0221] Embodiment 11. The method of embodiment 9, wherein the instruction includes performing a handover to a target NG-RAN node.

[0222] Embodiment 12. The method of embodiment 9, wherein the method further comprises sending capability information to the CN indicating that the NG_RAN node is capable of performing TSSA reporting.

[0223] Embodiment 13. The method of embodiment 9, further comprising sending a TSSA reporting preference to the CN.

[0224] Embodiment 14. A network node adapted to perform the method of any one of embodiments 1 to 8.

[0225] Embodiment 15. A base station node, adapted to execute the method of any one of Embodiments 9 to 13.

[0226] Embodiment 16. A non-transitory computer-readable storage medium comprising executable instructions, which, when executed by a processor, cause the processor to perform the method of any one of Embodiments 1 to 8.

[0227] Embodiment 17. A non-transitory computer-readable storage medium comprising executable instructions that, when executed by a processor, cause the processor to perform the method of any one of Embodiments 9 to 13.

[0228] The following is a 3GPP proposal that is based on one or more embodiments described in this disclosure and includes additional details of the embodiments described in this disclosure.

[0229] 3GPP TSG-RAN WG3#119 R3-230319

[0230] Athens, Greece, February 27-March 3, 2023

[0231] Agenda item: 8.1

[0232] Source: Ericsson

[0233] Title: Discussion on Proposed Method for Reporting Time Synchronization Status to UE

[0234] Document purpose: discussion, decision

[0235] _________________________________________________________________

[0236] 1 Introduction

[0237] At the RAN3#118 meeting, we discussed the issue of obtaining the RAN time synchronization status from the NG-RAN via control plane signaling (KI#1) in the SA2 LS and concluded that:

[0238] Without knowing details such as the content of the RAN time synchronization status to be reported, RAN3 cannot comment on the possible impact on RAN3. Some information is implementation dependent.

[0239] The incoming LS from SA2 raises two questions to RAN3 regarding the proposed method for reporting time synchronization status to UE in [1].

[0240] _________________________________________________________________

[0241] 2 Discussion

[0242] 2.1 Feedback on the Report ID Range for Notifying UE of RAN Clock Quality Changes

[0243] The first question SA2 sought feedback from RAN3 was:

[0244]

[0245] In NR, any SIB, except SIB1, can be configured as cell-specific or region-specific via an indication in SIB1. A cell-specific SIB applies only to the cell in which it is provided, while a region-specific SIB applies to an area called an SI area, which consists of one or more cells.

[0246] Observation 1: Using the indication in SIB1, SIB9 can be configured as cell-specific or area-specific.

[0247] We understand that SA2's LS is actually intended to introduce some additional "ranges" for event IDs. We will conduct our analysis based on this assumption.

[0248] An obvious area for RAN3 to consider is the introduction of the concept of "cell groups" when applied across gNBs. In our view, a gNB has time synchronization knowledge of its own cells, but not of cells in other gNBs. Different gNBs may have different synchronization sources, different states in the complete path, and potentially very different radio conditions. Sending event IDs across gNBs could reduce their reliability.

[0249] Furthermore, a status report is included in the SIB, which indicates potential changes in status across multiple gNBs and is relevant to multiple UEs. If a status change occurs in any cell in a cell group belonging to multiple gNBs, this will cause more UEs to enter connected mode, posing a greater risk. The status change indication becomes less precise and cannot be targeted to specific affected UEs.

[0250] In LS, the motivation for introducing “scope” is: “The latter case can further reduce the amount of signaling, because when the UE moves to another gNB, there will be no need to re-acquire detailed information about the clock quality.”

[0251] With the "scope", SIB 9 signaling is not reduced, but the need for the UE to obtain the respective content is reduced. The problem is that the UE needs to be aware of the change in clock quality. For UEs in inactive / idle state, there should not be a strict requirement.

[0252] If the UE is required to be aware of the time synchronization information seamlessly, the UE should remain in connected mode.

[0253] When a UE enters a new cell, it will get the timing information from the SIB. It would be nice to have a single, unified solution so that the UE does not need to behave differently with respect to event IDs, sometimes getting it from the SIB and sometimes not.

[0254] Proposal 1: In response to SA2, RAN3 believes that it is not necessary to introduce a "scope" for the reporting ID to specify a cell group within or across gNBs. The "scope" information will not be required.

[0255] 2.2 Time attributes: time source, traceability to UTC or GNSS, synchronization status, clock accuracy, clock frequency stability, PTP clockClass (clock level).

[0256] The second question SA2 sought feedback from RAN3 was:

[0257]

[0258]

[0259] Time synchronization of NG-RAN nodes is an implementation issue. High time accuracy is usually associated with high costs.

[0260] Observation 2: The time synchronization status information available in NG-RAN and its accuracy are implementation dependent.

[0261] In [2], SA2 states:

[0262] The detection is based on information provided by the time synchronization protocol used for RAN and UPF in the transport network, or in the case of NG-RAN, using information provided by the local GNSS receiver. However, the specific details of how exactly the NG-RAN / UPF detects degradation / failure / improvement of time synchronization locally is outside the scope of 3GPP.

[0263] Observation 3: Detection of time synchronization degradation / failure in NG-RAN nodes is implementation dependent.

[0264] The UE obtains information related to GPS time, Coordinated Universal Time (UTC), local time and leap seconds from the NR SIB9.

[0265] In NR, a UE in idle mode or RRC inactive mode can obtain 5G time information through SIB9. For a UE in connected mode, it can also obtain TA / PDC through RRC messages.

[0266] Proposal 2: It is recommended that RAN3 indicate to SA2 that the NG-RAN node decides whether it is capable of performing Time Status Reporting and indicates this to the AMF.

[0267] See the SA2 discussion on time attributes:

[0268] Table 5.27.1.X-1: Information elements included in NG-RAN or UPF time synchronization status information [Note 1]

[0269]

[0270] Time source:

[0271] If the NG-RAN node is directly synchronized to an external clock, then it can provide this information. The value of this information can be "PTP", "GNSS", "Atomic Clock", "Terrestrial Radio" or "Other".

[0272] We understand that the time source information will be provided to the CN only when the gNB uses these time sources.

[0273] Depending on the implementation, the NG-RAN node may be indirectly synchronized to an external clock, in which case the "Other" option can be used.

[0274] Proposal 3: In response to SA2, it is proposed that the gNB can provide a time source when applicable, and its value can be "PTP", "GNSS", "Atomic Clock", "Terrestrial Radio" or "Other".

[0275] Traceability to UTC or GNSS:

[0276] PTP includes the difference between PTP time and UTC time (ie, the number of leap seconds since the start of the PTP epoch).

[0277] If the gNB is synchronized with a GNSS receiver, the number of leap seconds is already included in the current SIB 9.

[0278] In our view, there is no need to send traceability to UTC or GNSS to the AMF.

[0279] Proposal 4: It is proposed to reply to SA2 that no traceability to UTC or GNSS is required from the gNB.

[0280] Sync Status:

[0281] In TS 36.413, synchronization states are defined:

[0282]

[0283] In our opinion, what the CN needs to know is whether the NG-RAN node is synchronized with the external time source. Therefore, it is sufficient for the NG-RAN node to provide its synchronization status, i.e. "Sync / Async".

[0284] If the NG-RAN node is synchronized with the external clock, it is in the synchronous state. Otherwise, it is in the asynchronous state.

[0285] Proposal 5a: It is recommended that in response to SA2, the gNB can provide its synchronization status as "synchronized / asynchronous" or "time synchronized / not time synchronized".

[0286] For a directly connected GNSS receiver, the entire principle of GNSS relies on the correct time on the satellites. The GNSS status that a gNB can report is either “available” or “unavailable”.

[0287] For PTP GM, the gNB can also detect whether the PTP path is interrupted.

[0288] Proposal 5b: It is recommended to reply to SA2 that the gNB can provide the synchronization status of the time source as "available", "unavailable" or "path interrupted".

[0289] Clock accuracy:

[0290] Detection of time synchronization degradation is outside the scope of 3GPP, which means that the gNB clock status reporting may not be very accurate or mandatory.

[0291] If the RAN nodes are asynchronous, then clock accuracy does not even apply.

[0292] If the RAN nodes are synchronized, it is possible for the NG-RAN nodes to get information at a coarse or detailed level. This depends on the gNB implementation.

[0293] Proposal 6: It is recommended that in response to SA2, the gNB has the following options: 1) time synchronization status is unavailable; 2) report the time synchronization status in a value range (e.g., low to high); 3) report a specific time synchronization value.

[0294] Clock frequency stability:

[0295] Generally speaking, the clock frequency stability is related to the crystal oscillator. The higher the stability, the higher the cost.

[0296] It is not clear how AF will handle time synchronization status reports when the clock frequency is stable, less stable, or unstable.

[0297] Therefore, it is recommended not to provide such information.

[0298] Proposal 7: It is recommended to respond to SA2 that gNB does not provide clock frequency stability reports to CN.

[0299] PTP clockClass (clock class):

[0300] If the NG-RAN node is synchronized to an external clock using the Precision Time Protocol (PTP), it can provide this information.

[0301] Proposal 8: It is proposed to reply to SA2 that if the gNB is synchronized with PTP, then it can provide PTP clockClass.

[0302] Based on the above analysis of the attributes, we make the following recommendations:

[0303] Observation 1: Using the indication in SIB1, SIB9 can be configured as cell-specific or area-specific.

[0304] Proposal 1: In response to SA2, RAN3 believes that it is not necessary to introduce a "scope" for the reporting ID to specify a cell group within or across gNBs. The "scope" information will not be required.

[0305] Observation 2: The time synchronization status information available in NG-RAN and its accuracy are implementation dependent.

[0306] Observation 3: Detection of time synchronization degradation / failure in NG-RAN nodes is implementation dependent.

[0307] Proposal 2: It is recommended that RAN3 indicate to SA2 that the NG-RAN node decides whether it is capable of performing Time Status Reporting and indicates this to the AMF.

[0308] Proposal 3: In response to SA2, it is proposed that the gNB can provide a time source when applicable, and its value can be "PTP", "GNSS", "Atomic Clock", "Terrestrial Radio" or "Other".

[0309] Proposal 4: It is proposed to reply to SA2 that no traceability to UTC or GNSS is required from the gNB.

[0310] Proposal 5a: It is recommended that in response to SA2, the gNB can provide its synchronization status as "synchronized / asynchronous" or "time synchronized / not time synchronized".

[0311] Proposal 5b: It is recommended to reply to SA2 that the gNB can provide the synchronization status of the time source as "available", "unavailable" or "path interrupted".

[0312] Proposal 6: It is recommended that in response to SA2, the gNB has the following options: 1) time synchronization status is unavailable; 2) report the time synchronization status in a value range (e.g., low to high); 3) report a specific time synchronization value.

[0313] Proposal 7: It is recommended to respond to SA2 that gNB does not provide clock frequency stability reports to CN.

[0314] Proposal 8: It is proposed to reply to SA2 that if the gNB is synchronized with PTP, then it can provide PTP clockClass.

[0315] ____________________________________________________________________

[0316] 3 proposals

[0317] Proposal 1: In response to SA2, RAN3 believes that it is not necessary to introduce a "scope" for the reporting ID to specify a cell group within or across gNBs. The "scope" information will not be required.

[0318] Observation 2: The time synchronization status information available in NG-RAN and its accuracy are implementation dependent.

[0319] Observation 3: Detection of time synchronization degradation / failure in NG-RAN nodes is implementation dependent.

[0320] Proposal 2: It is recommended that RAN3 indicate to SA2 that the NG-RAN node decides whether it is capable of performing Time Status Reporting and indicates this to the AMF.

[0321] Proposal 3: In response to SA2, it is proposed that the gNB can provide a time source when applicable, and its value can be "PTP", "GNSS", "Atomic Clock", "Terrestrial Radio" or "Other".

[0322] Proposal 4: It is proposed to reply to SA2 that no traceability to UTC or GNSS is required from the gNB.

[0323] Proposal 5a: It is recommended that in response to SA2, the gNB can provide its synchronization status as "synchronized / asynchronous" or "time synchronized / not time synchronized".

[0324] Proposal 5b: It is recommended to reply to SA2 that the gNB can provide the synchronization status of the time source as "available", "unavailable" or "path interrupted".

[0325] Proposal 6: It is recommended that in response to SA2, the gNB has the following options: 1) time synchronization status is unavailable; 2) report the time synchronization status in a value range (e.g., low to high); 3) report a specific time synchronization value.

[0326] Proposal 7: It is recommended to respond to SA2 that gNB does not provide clock frequency stability reports to CN.

[0327] Proposal 8: It is proposed to reply to SA2 that if the gNB is synchronized with PTP, then it can provide PTP clockClass.

[0328] A draft reply to LS has been submitted at [3].

[0329] _________________________________________________________________

[0330] 4 References

[0331] [1] S2-2301463 Proposed method for reporting time synchronization status to UE

[0332] [2] 23.700-25 Technical Specifications Group Services and Systems Aspects; Study of Time Resilience and Enhancements for TSC and URLLC

[0333] [3] R3-230320 [Draft] Reply on Proposed Method for Reporting Time Synchronization Status to UE LS, Ericsson

[0334] 3GPP TSG-RAN WG3 Meeting#119 R3-230320 Athens, Greece, February 27-March 3, 2023

[0335] _________________________________________________________________

[0336] Title: [Draft] Response to LS regarding a proposed method for reporting time synchronization status to UE

[0337] Replying Party: S2-2301463

[0338] Version: Rel-18

[0339] Work item: FS_5TRS_URLLC

[0340] Source: Ericsson (to be submitted to RAN3)

[0341] Attachments: None

[0342] 1. General description:

[0343] RAN3 thanks SA2 for informing the LS of the time synchronization status to the UE on the proposed method of reporting the time synchronization status to the UE.

[0344] RAN3 would like to provide responses to two questions raised by RAN3:

[0345]

[0346] RAN3's reply 1:

[0347] RAN3 does not see the benefit of having a scope for the reporting ID to specify a group of cells within or across gNBs. The “scope” information is not required.

[0348]

[0349] RAN3's reply 2:

[0350] RAN3 wishes to state that the information about the time synchronization status available at the NG-RAN, its accuracy, and the detection of time synchronization degradation / failure are implementation dependent.

[0351] RAN3 wishes to indicate to SA2 that the NG-RAN node should decide whether it performs temporal status reporting and indicate it to the AMF.

[0352] RAN3's reply 3:

[0353] The gNB may provide a time source with the values ​​"PTP", "GNSS", "Atomic Clock", "Terrestrial Radio", "Other" when applicable;

[0354] The gNB may provide its synchronization status as "synchronous / asynchronous" or "time synchronized / not time synchronized".

[0355] The gNB can provide the time source synchronization status as "available, unavailable, disconnected path".

[0356] The gNB has the following options: 1) Time synchronization status unavailable; 2) Time synchronization report based on a value range (e.g., low to high); 3) Time synchronization report with a specific value

[0357] The gNB can provide the PTP clockClass if it is synchronized with PTP.

[0358] RAN3's reply 4:

[0359] “Traceability to UTC or GNSS” and “Clock frequency stability time synchronization report” are not required to be provided from the gNB.

[0360] 2. Action:

[0361] To SA2 group

[0362] Action: RAN3 kindly requests SA2 to take the above into consideration.

[0363] abbreviation

[0364] At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, the abbreviation used above shall take precedence. If listed multiple times below, the first listed shall take precedence over any subsequent listings.

[0365] 3GPP Third Generation Partnership Project

[0366] 5G fifth generation

[0367] 5GC fifth generation core

[0368] 5GS fifth generation system

[0369] AF application function

[0370] AMF access and mobility management function

[0371] AN Access Network

[0372] ASIC Application-Specific Integrated Circuit

[0373] ·ASTI Time Distribution Service based on access layer

[0374] AUSF authentication server function

[0375] CPU Central Processing Unit

[0376] DN Data Network

[0377] DSP digital signal processor

[0378] eNB Enhanced or evolved Node B

[0379] FPGA Field Programmable Gate Array

[0380] gNB New Radio Base Station

[0381] IP Internet Protocol

[0382] LTE Long Term Evolution

[0383] MN Primary NG-RAN Node

[0384] NEF network exposure function

[0385] NF Network Function

[0386] NR New Radio

[0387] NRF Network Function Repository functionality

[0388] OTT (Over-the-Top)

[0389] PC personal computer

[0390] PCF policy control function

[0391] PDU Packet Data Session Unit

[0392] PTP Precision Time Protocol

[0393] RAM Random Access Memory

[0394] RAN Radio Access Network

[0395] ROM Read Only Memory

[0396] RP receiving point

[0397] RRH Remote Radio Head

[0398] RTT round trip time

[0399] SN Secondary NG-RAN Node

[0400] SMF session management capabilities

[0401] TASSR Time Accuracy / Synchronization Status Report

[0402] (Capabilities / Information)

[0403] TSCTSF Time Sensitive Communication and Time Synchronization Function

[0404] UDM unified data management

[0405] UE User Equipment

[0406] UPF User Plane Function

[0407] VPLMN Access Public Land Mobile Network

Claims

1. A method performed by a first core network function providing access and mobility management services, the method comprising: providing a time accuracy / synchronization status reporting configuration to a radio access network (RAN) node to trigger a time accuracy / synchronization status report by the RAN node; as well as One or more time accuracy / synchronization status reports generated by a RAN node based on a time accuracy / synchronization status reporting configuration are received.

2. The method according to claim 1, wherein The one or more time accuracy / synchronization status reports include one or more of clock accuracy and synchronization status.

3. The method of any one of claims 1 to 2, further comprising providing, in response to the received time accuracy / synchronization status report, information to the RAN node indicating whether the RAN node is able or unable to serve a user equipment (UE) based on an access stratum time synchronization (ASTI) subscription obtained for the UE.

4. The method according to any one of claims 1 to 2, further comprising instructing the RAN node to hand over the UE to a target RAN node in response to the received time accuracy / synchronization status report.

5. The method of claim 1 , wherein the step of providing the time accuracy / synchronization status reporting configuration to the RAN node to trigger the time accuracy / synchronization status reporting of the RAN node is triggered by a request from a second network function.

6. The method according to claim 5, wherein: The time accuracy / synchronization status report obtained from the RAN node is provided to the second network function.

7. A method performed by a second core network function providing a time synchronization service, the method comprising: receiving a time accuracy / synchronization status report (TASSR) request or an access stratum time synchronization (ASTI) service request originating from an application function (AF) for one or more UEs; receiving, from the first core network function, a time accuracy / synchronization status report generated by a radio access network (RAN) node for the one or more UEs; determining, based on the time accuracy / synchronization status report, whether the one or more UEs are served by a RAN node that supports the requested time synchronization status reporting from the AF; as well as Instructions are provided to the RAN node to be applied based on the determination.

8. The method of claim 7, wherein: The instructions include notifying the first network function of a new or modified clock quality detail level.

9. The method of claim 7, wherein: The instructions include providing information to the RAN node indicating that the RAN node is able or unable to serve the user equipment based on the requested time accuracy / synchronization status report or ASTI service request.

10. The method of claim 7, wherein: Based on the time accuracy / synchronization status report, instructing to perform a handover from the RAN node that provides the time accuracy / synchronization status report for the one or more UEs to a target RAN node.

11. A method performed by a radio access network (RAN) node, the method comprising: Obtaining a time accuracy / synchronization status reporting configuration from a first core network function of the core network; sending a time accuracy / synchronization status report to the first core network function according to the time accuracy / synchronization status reporting configuration; The time accuracy / synchronization status report includes one or more of time accuracy and time synchronization status.

12. The method of claim 11, further comprising receiving instructions to be applied as a result of the provided time accuracy / synchronization status report.

13. The method of claim 12, wherein: The instructions include information indicating that the RAN node can or cannot serve a user equipment (UE) based on a requested access stratum time synchronization (ASTI) subscription or UE subscription from another network function.

14. The method of claim 12, wherein: The instructions include performing a handover to a target RAN node.

15. The method of claim 11, wherein the method further comprises sending capability information indicating whether the RAN node is capable of performing time accuracy / synchronization status reporting to a core network.

16. The method of claim 11, further comprising sending a time accuracy / synchronization status reporting preference to the core network.

17. A network node or server, adapted to perform the method according to any one of claims 1 to 10.

18. A radio access network node adapted to perform the method of any one of claims 10 to 16.

19. A network node or server comprising one or more processors and memory, the memory comprising instructions which, when executed by the one or more processors, perform the method of any one of claims 1 to 10.

20. A radio access network node comprising one or more processors, a transceiver for communicating with user equipment, and a memory comprising instructions which, when executed by the one or more processors, perform the method of any one of claims 11 to 16.

21. A non-transitory computer-readable storage medium comprising executable instructions that, when executed by a processor, cause the processor to perform the method of any one of claims 1 to 16.

Images