Timing edge service from lead UE over PC5

Field of the invention

The present disclosure relates to time synchronization. In particular, it relates to time synchronization for UEs using proximity services.

Abbreviations

3GPP 3 ^rd Generation Partnership Project

5G/6G/7G 5 ^th /6 ^th /7 ^th Generation

5GC 5G Core network

5GS 5G System

AF Application Function

APN Access Point Name

BMCA Best Master Clock Algorithm

CAG Closed Access Group

CP Control Plane

D2D Device to Device

DN Data Network

DNN Data Network Name

DS-TT Device-side TT eNB evolved NodeB

GM Grand Master clock gNB Next Generation NodeB

GNSS Global Navigation Satellite System

GPS Global Positioning System gPTP Generalized PTP

HPLMN Home PLMN

ID Identifier

IE Information Element l_IC In-coverage Indicator

HoT Industrial Internet of Things

InC In Coverage

NAS Non-Access Stratum

NG-RAN Next Generation RAN NR New Radio

NSSAI Network Slice Selection Assistance Information

NW-TT Network-side TT

OoC Out of Coverage

PC5 Direct communication between devices (e.g. V2V.V2I)

PDU Protocol Data Unit

PLMN Public Land Mobile Network

PMIC Port Management Information Container

ProSE Proximity based Services

PSBCH Physical Sidelink Broadcast Channel

PTP Precision Timing Protocol

RAN Radio Access Network

RRC Radio Resource Control

RSRP Reference Signal Received Power

SD-RSRP Sidelink Discovery Reference Signal Received Power

SFN System Frame Number

SIB9 System Information Block 9

SL Sidelink

SLSS Sidelink Synchronization Signals

SSB Synchronization Signal Block

TA Tracking Area

TS Technical Specification

TSN Time-sensitive Networks

TSCTSF Time Sensitive communication Time Synchronization function

TT TSN Translator

UE User Equipment

UMIC User Node Management Information Container

UPF User Plane Function

UTC Coordinated Universal Time

VPLMN Visited PLMN

WAN Wide Area Network

Background Using D2D/ProSE, mobile users can use operator authorized spectrum for direct communication using PC5 interface, without the support of infrastructure (RAN). In 5G NR sidelink, there can be communication using PC5 interface even when there is no NG-RAN coverage. A User/UE (Relay UE called “Lead UE”) can provide edge services to other UEs (Remote UEs) who are in its proximity using D2D/ProSE communication. This is shown in Fig. 1.

To achieve synchronization among all the UEs and eNBs/gNBs (if there is RAN coverage), there are two types of sidelink synchronization procedures: Global Navigation Satellite System (GNSS) based and gNB/eNB based synchronization (also named RAN based synchronization).

• If a UE becomes a synchronization source (called “SyncRef UE”), it transmits its Synchronization Signal Block (SSB) on PSBCH.

• The SLSS ID and l_IC help distinguish whether a SyncRef UE is directly or indirectly synchronized to GNSS or a gNB/eNB.

• l_IC also indicates whether the SyncRef UE is either one hop or several hops away from a gNB/eNB or GNSS, where each hop corresponds to another SyncRef UE.

In Rel-17, the 5G System supports Time Synchronization and Time Sensitive communications for any application. The 5G System architecture enables any Application Function (AF) - in the same or different trust domain - to provide its requirements for QoS, traffic characteristics for QoS scheduling optimization, time synchronization activation and deactivation.

If the AF is in a different trust domain from the 5G System, then it provides input via exposure framework, NEF API, to the Time Sensitive Communication Time Synchronization Function (TSCTSF). If the AF is in the same trust domain as the 5G System, then it provides input directly via TSCTSF to PCF.

The 3GPP network may be integrated in a TSN network to connect one or more end station devices of the TSN network to the remainder of the TSN network, considered as a DN from the 3GPP network’s point of view. In this case, the 3GPP network may act like a bridge for the TSN network. The 3GPP network provides an interface NW-TT on the network side (typically at the UPF) to the DN, and an interface DS-TT to the end station device of the TSN network. DS-TT is typically implemented in the UE.

Currently, available ProSe UE-to-Network Relay discovery parameters are

• ProSe application user ID, Layer 2 ID, Source User Info (Source UE's ProSe Application Layer ID, ProSe Application Layer Group ID); Target User Info (Target UE's ProSe Application Layer ID)

• Service and application information that is enabled or authorised to be relayed e.g. Mission Critical Voice, Game A, Game B, Taxi Communications company Y; Relay Service Code

• Slicing information (e.g. Allowed NSSAI) the UE-to-Network Relay is enabled or authorised to be relayed; Data Network Name (DNN) information^. g. APN) the UE-to-Network Relay is authorised to access;

• The HPLMN or VPLMN for the UE-to-Network Relay; Mobility restrictions related information such as CAG cell and TA; Relay UE serving cell information like Cell ID

PTP provides a hierarchical master-slave architecture for clock distribution. Under this architecture, a time distribution system comprises one or more communication media (network segments), and one or more clocks. An ordinary clock is a device with a single network connection and is either the source (master or leader) of a synchronization reference or destination (slave or follower) for a synchronization reference. A boundary clock has multiple network connections and can accurately synchronize one network segment to another. A synchronization master is selected for each of the network segments in the system. The root timing reference is called the grandmaster. The grandmaster transmits synchronization information to the clocks residing on its network segment. The boundary clocks with a presence on that segment then relay accurate time to the other segments to which they are also connected.

PTP is a protocol for time delivery, and gPTP is a profile of the PTP protocol. A PTP profile is a set of required options, prohibited options, and the ranges and defaults of configurable attributes. Thus, gPTP defines a subset of optional/mandatory features of PTP. For Rel-17, two time synchronization processes are supported in 5GS: 5GS internal clock synchronization and (generic) Precision Time Protocol ((g)PTP) time synchronization. These processes can be considered independent from each other, and the gNB only needs to be synchronized to the 5G grandmaster (GM) clock.

• For the 5GS internal clock synchronization, the 5G clock is delivered to the UE via referenceTimelnfo IE (over SIB9/RRC) that, together with the estimation of the UE frame boundary (SFN) reference, enables the UE to be absolute time synchronized to the 5G clock.

• For the (g)PTP time synchronization, (g)PTP messages are transferred via user plane. The TSN translators at the edge of the 5GS support (g)PTP operation to distribute the PTP time domain through NW-TT/DS-TT. The 5G internal system clock shall be made available to DS-TT by the UE and to the UPF/NW-TT via the underlying PTP compatible transport network. Currently, such mechanisms are defined outside the scope of 3GPP. To configure (g)PTP operation at the TTs, the TSCTSF or the TSN AF uses the Port Management Information Container (PMIC) or User Node Management Information Container (UMIC) (see 3GPP TS 23.501 , clause 5.27.1.4).

UE, gNB, User Plane Function (UPF), Network-side TT (NW-TT), and Device-side TT (DS-TT) are synchronized with the 5G GM (i.e. the 5G internal system clock) which shall serve to keep these elements synchronized. The source for 5G timing is often GPS (or another GNSS) in the current networks and specifications.

A key component of PTP systems is the GM clock. GM clock serves as the Grandmaster and it provides time to other clocks on the network. Therefore, GM clock shall provide the best source of time when several sources of time are available. To select the GM, PTP has the Best Master Clock Algorithm (BMCA). The BMCA compares a set of PTP properties (e.g. clock accuracy, GM priority, etc) received in the PTP announce messages provided by the time sources and determines the GM for a PTP domain. As a result, the PTP domain constructs a time-synchronization spanning tree with the GM as the root.

In Rel-17, the 5GS supports two methods for determining the PTP GM and the time synchronization spanning tree: a) using the BMCA procedure, or b) based on local configuration.

The BMCA procedure compares data sets comprising the information of the sources from different PTP instances. For the comparison, it uses the priorities defined, clock identities, clock class, GM accuracy and other parameters (see Table 29 of IEEE Std 1588-2019). As a result of the BMCA, the port states are derived (e.g. the port should be passive, slave or master). The PTP Port states (Table 27 of IEEE Std 1588-2019) may be: initializing, faulty, disabled, listening, pre-master, master, passive, uncalibrated, slave. When the Method a) is used (PTP port states are determined by BMCA procedure), the NW-TT processes the received Announce messages (from NW- TT port(s) and over user plane from the DS-TT(s)) for BMCA procedure, determines port states within the 5GS, determines the PTP GM, and maintains the Master-Slave hierarchy.

Via network functions service procedures, the AF can retrieve the 5GS time synchronization capabilities prior to sending a time synchronization service request. Table 1 (extracted from 3GPP TS 23.502, Table 5.2.6.25.6-1) describes the time synchronization capability the 5GS can expose to the AF.

Table 1 : Time Synchronization capability event

3GPP TS 22.104 has further specific service requirements for time synchronization service and direct device connection or indirect network connection, like:

• The 5G system shall be able to support clock synchronization (working clock domain) between the UEs within the group of UEs using direct device connection ProSe communication.

• The 5G system shall be able to support Precision Time Protocol-based (IEEE 802.1AS or another applicable IEEE Std 1588 profile) or 5G sync domain-based clock synchronization among the group of UEs using direct device connection. • The 5G system shall be able to support the sync master of the working clock domain being connected to one of the UEs or being hosted at one of the UEs in the group of UEs using direct device connection.

• For direct device connection, the 5G system shall be able to support a 5GS synchronicity budget for clock synchronization according to TS 22.104 Table 7.2.3.2-1. In this case, the sync master and sync device are located at or connected to two UEs which are connected via direct device connection.

• The 5G system shall be able to support clock synchronization (working clock domain) for UEs using indirect network connection.

• The 5G system shall be able to support Precision Time Protocol-based (IEEE 802.1AS or another applicable IEEE Std 1588 profile) or 5G sync domain-based clock synchronization for UEs using indirect network connection.

• The 5G system shall be able to support the sync master of the working clock domain being connected to one of the UEs or being hosted at one of the UEs using indirect network connection.

• For indirect network connection between UEs using one UE-to-network relay, the 5G system shall be able to support a 5GS synchronicity budget for clock synchronization according to TS 22.104 Table 8.2.3.2-1.

Summary

It is an object of the present invention to improve the prior art.

According to a first aspect of the invention, there is provided an apparatus comprising: one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: offering a timing service of a first terminal to a second terminal via a direct interface between the first terminal and the second terminal; monitoring if an acceptance of the offer is received from the second terminal; providing the timing service to the second terminal via the direct interface if the acceptance is received.

The timing service may include that the first terminal may act as a grandmaster clock. The offering the timing service may comprise additionally indicating at least one of the following capabilities:

• an accuracy of the timing service,

• a time synchronization source of the timing service,

• a time synchronization method,

• a minimum message generation rate,

• a maximum number of clients supported at the minimum message generation rate,

• a protocol version of the timing service,

• a redundancy of the grandmaster clock,

• a support of a best master clock algorithm,

• a support of a PMIC container framework, and

• a holdover capability.

The instructions, when executed by the one or more processors, may further cause the apparatus to perform: providing the timing service via a user plane message or via control plane signalling via the direct interface.

The instructions, when executed by the one or more processors, may further cause the apparatus to perform: receiving a first time synchronization from a network via a control plane; converting the received first time synchronization into a second time synchronization; providing, as the timing service, the second time synchronization to the second terminal on the user plane.

The instructions, when executed by the one or more processors, may further cause the apparatus to perform: the converting such that the second time synchronization is corrected for a time difference between the first time synchronization and a timing of a PTP instance to which the second terminal belongs.

The timing service may be offered during a discovery procedure. According to a second aspect of the invention, there is provided an apparatus comprising: one or more processors, and memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: monitoring whether a second terminal receives an offer of a timing service of a first terminal via a direct interface between the first terminal and the second terminal; providing an acceptance of the offer to the first terminal if the offer is received; receiving the timing service from the first terminal.

The offer of the timing service may include that the first terminal may act as a grandmaster clock, and the instructions, when executed by the one or more processors, may further cause the apparatus to perform selecting the first terminal as the grandmaster clock for the second terminal if the offer of the timing service is received.

The offer of the timing service may comprise additionally indicating at least one of the following capabilities:

• an accuracy of the timing service,

• a time synchronization source of the timing service,

• a time synchronization method,

• a minimum message generation rate,

• a maximum number of clients supported at the minimum message generation rate,

• a protocol version of the timing service,

• a redundancy of the grandmaster clock,

• a support of a best master clock algorithm,

• a support of a PMIC container framework, and

• a holdover capability.

The instructions, when executed by the one or more processors, may further cause the apparatus to perform: checking whether the second terminal receives more than one offers of the timing service from different first terminals via respective direct interfaces; selecting one of the first terminals as the master clock based on the indicated at least one of the capabilities. The instructions, when executed by the one or more processors, may further cause the apparatus to perform: receiving the timing service via a user plane message or via control plane signaling on the direct interface.

The instructions, when executed by the one or more processors, may further cause the apparatus to perform: receiving, as the timing service, a first time synchronization from the first terminal on the control plane of the direct interface; converting the received first time synchronization into a second time synchronization; providing the second time synchronization to an end station.

According to a third aspect of the invention, there is provided a method comprising: offering a timing service of a first terminal to a second terminal via a direct interface between the first terminal and the second terminal; monitoring if an acceptance of the offer is received from the second terminal; providing the timing service to the second terminal via the direct interface if the acceptance is received.

The timing service may include that the first terminal may act as a grandmaster clock.

The offering the timing service may comprise additionally indicating at least one of the following capabilities:

• an accuracy of the timing service,

• a time synchronization source of the timing service,

• a time synchronization method,

• a minimum message generation rate,

• a maximum number of clients supported at the minimum message generation rate,

• a protocol version of the timing service,

• a redundancy of the grandmaster clock,

• a support of a best master clock algorithm,

• a support of a PMIC container framework, and a holdover capability.

The method may further comprise: providing the timing service via a user plane message or via control plane signalling via the direct interface.

The method may further comprise: receiving a first time synchronization from a network via a control plane; converting the received first time synchronization into a second time synchronization; providing, as the timing service, the second time synchronization to the second terminal on the user plane.

The method may further comprise: the converting such that the second time synchronization is corrected for a time difference between the first time synchronization and a timing of a PTP instance to which the second terminal belongs.

The timing service may be offered during a discovery procedure.

According to a fourth aspect of the invention, there is provided a method comprising: monitoring whether a second terminal receives an offer of a timing service of a first terminal via a direct interface between the first terminal and the second terminal; providing an acceptance of the offer to the first terminal if the offer is received; receiving the timing service from the first terminal.

The offer of the timing service may include that the first terminal may act as a grandmaster clock, and the method may further comprise selecting the first terminal as the grandmaster clock for the second terminal if the offer of the timing service is received.

The offer of the timing service may comprise additionally indicating at least one of the following capabilities:

• an accuracy of the timing service,

• a time synchronization source of the timing service, • a time synchronization method,

• a minimum message generation rate,

• a maximum number of clients supported at the minimum message generation rate,

• a protocol version of the timing service,

• a redundancy of the grandmaster clock,

• a support of a best master clock algorithm,

• a support of a PMIC container framework, and

• a holdover capability.

The method may further comprise: checking whether the second terminal receives more than one offers of the timing service from different first terminals via respective direct interfaces; selecting one of the first terminals as the master clock based on the indicated at least one of the capabilities.

The method may further comprise: receiving the timing service via a user plane message or via control plane signaling on the direct interface.

The method may further comprise: receiving, as the timing service, a first time synchronization from the first terminal on the control plane of the direct interface; converting the received first time synchronization into a second time synchronization; providing the second time synchronization to an end station.

Each of the methods of the third and fourth aspects may be a method of a timing edge service.

According to a fifth aspect of the invention, there is provided a computer program product comprising a set of instructions which, when executed on an apparatus, is configured to cause the apparatus to carry out the method according to any of the third and fourth aspects. The computer program product may be embodied as a computer-readable medium or directly loadable into a computer. According to some embodiments of the invention, at least one of the following advantages may be achieved:

• time synchronization of remote UEs even if they are out of coverage;

• Most suitable time synchronization source may be selected;

• no need to modify RAN.

It is to be understood that any of the above modifications can be applied singly or in combination to the respective aspects to which they refer, unless they are explicitly stated as excluding alternatives.

Brief description of the drawings

Further details, features, objects, and advantages are apparent from the following detailed description of the preferred embodiments of the present invention which is to be taken in conjunction with the appended drawings, wherein:

Fig. 1 shows a basic ProSe configuration;

Fig. 2 depicts scenario 1 according to some example embodiments of the invention;

Fig. 3 depicts scenario 2a according to some example embodiments of the invention;

Fig. 4 depicts scenario 2b (option i) according to some example embodiments of the invention;

Fig. 5 depicts scenario 2b (option ii) according to some example embodiments of the invention;

Fig. 6 depicts scenario 2c according to some example embodiments of the invention;

Fig. 7 shows a message flow according to some example embodiments of the invention;

Fig. 8 shows a flow chart according to some example embodiments of the invention;

Fig. 9 shows an apparatus according to an example embodiment of the invention;

Fig. 10 shows a method according to an example embodiment of the invention;

Fig. 11 shows an apparatus according to an example embodiment of the invention;

Fig. 12 shows a method according to an example embodiment of the invention; and

Fig. 13 shows an apparatus according to an example embodiment of the invention.

Detailed description of certain embodiments Herein below, certain embodiments of the present invention are described in detail with reference to the accompanying drawings, wherein the features of the embodiments can be freely combined with each other unless otherwise described. However, it is to be expressly understood that the description of certain embodiments is given by way of example only, and that it is by no way intended to be understood as limiting the invention to the disclosed details.

Moreover, it is to be understood that the apparatus is configured to perform the corresponding method, although in some cases only the apparatus or only the method are described.

RAN based synchronization is an alternative to directly relying on the GPS receivers for achieving the precise time synchronization. GPS signals could be obstructed or GPS could fail due to several reasons - natural disasters, spoofing etc. However, even in case of RAN based synchronization (i.e. providing time service through NR), the time service may be interrupted when there are wireless coverage issues. As time synchronization in WAN and HoT (like NR robots in a factory setup) is crucial, an uninterrupted and accurate time service is a basic requirement in many scenarios.

Currently, there is no solution for (a) remote UE(s) to discover a relay UE that can act as a Lead UE that offers timing capability. Thus, currently, when there is neither a GPS signal nor NG-RAN coverage, a NR device does not have any possibility to have any time synchronous service. Additionally there is no way to select a local application service provider (Lead UE) in the PC5 network based on its service capabilities.

Some example embodiments of the invention provide a time synchronization service via PC5. For example, a UE may include its timing service capability information (especially when it can act as GM) as part of the Discovery procedure over PC5. As another option, the UE may indicate its timing service capability information in a control message or a user plane message over the established PC5 interface.

A (potential) Lead UE (Service provider) may offer its capability to act as a grand master clock as a timing service to one or more other Remote UEs over PC5 interface. Similarly to an AF retrieving 5GS time synchronization capability (as shown in Table 1) in Rel-17, the relay UE that can be a potential lead UE describes to the remote UEs what capabilities it has for time synchronization. The relay UE may include additional information assisting the remote UE in determining the GM UE (e.g. holdover capabilities).

Considering (g)PTP user plane time synchronization process, remote UEs can receive (g)PTP configuration via PC5. There are two options, e.g. depending on implementation: i. Local configuration of the remote UEs can be enabled via user plane PC5 traffic between the network element (PTP management node behind N6) that is configuring the PTP network and the remote UE. In this case, the relay UE is just transparently forwarding user plane traffic to/from the remote UE. ii. Alternatively, relay UE may act as a proxy to forward PMIC from/to remote UEs via PC5. In this case, Relay UE may trigger NAS signaling (on top of the PDU Session established for the remote UE) to forward the PMIC of the remote UE to the 5GC (following Rel-17 PMIC transmission method). Using the PMIC, the 5GC (i.e. TSCTSF) can configure remote UE’s (g)PTP operation and keep track of the time synchronization spanning tree including out of coverage UEs.

If a 5G clock is delivered via C-plane (SIB9/RRC), Relay UE may act as a proxy to forward the 5G reference timing information received from the network via SIB9/RRC signaling through PC5. In this case, there is no PMIC to configure the UEs. In this case, the remote UEs may determine the relay UE that will act as lead UE (what UE should be the GM) during discovery procedure over PC5 or by some dedicated (user plane or control plane) message.

When there are more than one service providers UEs (potential Lead/Relay UEs) offering a service that doesn’t need an IP termination in the remote UE (in case other parameters than signal strength become relevant of relay UE selection (e.g. if user plane traffic is not critical), selection of lead UE offering the timing service shall be based on the service capabilities, e.g, holdover time, accuracy etc.

• For (g)PTP operation (i.e., if the relay UE just transparently forwards PTP user plane traffic to/from the remote UE), the selection of the GM at the remote UE shall preferably be compatible with the time synchronization spanning tree and 5GS PTP instance operation the 5GS may determine for the PTP domain, if available (that is, if (g)PTP time synchronization is configured for UEs via PC5 using PMIC and controlled by the TSCTSF). The forwarded (g)PTP messages and PMIC from the NW-TT towards the remote UE (via the relay UE) preferably dictate (g)PTP operation.

In case of Time Synchronization Service, following information could be included by the lead UE as part of PC5 Discovery procedure:

• Time synchronization accuracy

• Time Synchronization source based on SLSS ID employed by the lead UE

• supported time synchronization methods (user plane or control plane).

• Minimum gPTP or PTP message generation rate supported, and maximum number of clients that can be supported at the minimum gPTP or PTP message generation rate. o supported (g)PTP versions:

IEEE Std 802.1AS (i.e. gPTP), and/or

PTP over UDP/IPv4 according to IEEE Std 1588- 2019 Annex C, and/or

PTP over UDP over IPv6 according to IEEE Std 1588- 2019 Annex D.

• Timing source redundancy availability

• Support for BMCA, support for configuration via PMIC framework

• Holdover capabilities

The remote UE may use this information to select, in case of plural potential lead UEs, one of them as the actual lead UE providing GM clock.

Lead UE may offer a grand master clock as timing service to Remote UE over PC5. This works even in out of coverage scenario, i.e. where both the lead UE and the remote UE are out of coverage of the network. Note that in the out of coverage scenario, any of the relay UE and the remote UE may become a lead UE. If the remote UE (i.e., the UE not setting up the PC5 link) is the lead UE, it offers a grand master clock as timing service to Relay UE over PC5. The relay UE acting as lead UE can offer its timing service to the other UE in one of the following ways:

1) Forward (g)PTP message received from the Network to the remote UE.

2) Generate (g)PTP message and send it to the remote UE.

3) Forward 5G timing reference information received from the Network to the remote UE and the remote UE generates (g)PTP message for synchronization with the end station.

4) Use 5G timing reference information received from the Network and generate (g)PTP message and send both towards the remote UE.

Lead UE can provide the above mentioned information towards the remote UE either over control plane or user plane. Therefore, different scenarios can be considered for sidelink and time synchronization. Hereinafter, several scenarios according to some example embodiments of the invention are described at greater detail:

Scenario 1 (Fig. 2):

SL sync based on C-plane synchronization with SL UE Out of Coverage (OoC)

It is assumed that UE2 is out of coverage and UE1 is in coverage (InC). UE1 receives from network C-plane synchronization, i.e., based on referenceTimelnfo received from the gNB via SIB9/RRC at the relay UE (UE1). There are some implementation options, e.g.:

1. Relay UE (UE1) may perform a conversion of absolute time reference in terms of SIB9 to PC5. Relay UE may act as a proxy to forward the 5G reference timing information received from the network via SIB9/RRC signaling through PC5.

2. Remote UE (UE2), based on the time synchronization service datasets received during the PC5 discovery phase, may select the best synchronization source (i.e., the lead UE) if plural UEs offer their synchronization services.

Scenario 2a (Fig. 3):

SL sync based on U-plane (i.e. (g)PTP) messages with SL UE OoC and outside 5G

PTP instance It is assumed that UE2 (OoC) is a (g)PTP end station outside the 5GS domain (out of the PTP instance we have in 5GS; e.g. its GM clock may be in another 5GS). That is, UE2 cannot reach its GM clock via 5GS. Accordingly, it synchronizes with the UE1/DS- TT acting as GM (e.g. UE1) if UE1 offers such a service. Since the absolute time of the PtP hierarchy to which UE2 belongs is not known, UE2/DS-TT may receive (g)PTP messages from the GM without any additional timestamping for corrections. Since UE1/DS-TT and UE2/DS-TT are working within PTP domains of separate GM clocks, the 5GS controls operation of UETs DS-TT but it does not control UE2’s DS-TT.

Scenario 2b (Figs. 4 and 5):

SL sync based on Il-plane (i.e. (g)PTP) with SL UE OoC and inside 5G PTP instance

It is assumed that UE2 (OoC of the 5GS) is a (g)PTP end station but still part of the 5G PTP instance. Therefore, different options can be considered here: i. (Fig. 4) Following Rel-17 PTP instance operation: UE2/DS-TT should preferably perform some corrections based on 5G clock timestamping if it is synchronized with internal 5G clock via the SL link. For example, such synchronization may be achieved using scenario 1 based on C-plane or some other way the UE2 to get absolutely synchronized to 5G clock.

As still another option, UE1/DS-TT may provide 5G clock and SFN reference info when it forwards the (g)PtP message to the UE2/DS-TT. In this case, the UE2/DS-TT will be able to compute the absolute timing information for 5G clock in order to perform corrections and determine residence time based on 5G clock time stamping. The residence time is the time the PTP packet spent within the 5GS (a PTP instance). To estimate it, the TT that is the entry point of the PTP instance (either NW-TT or DS-TT) may perform an ingress timestamping, later, at the egress, TT does another timestamp (egress timestamp), and the residence time within the PTP instance is derived. ii. (Fig. 5) As another option, (different from the behavior as described in Rel- 17), UE1/DS-TT may perform the corrections based on 5G clock (as UE1 has access to 5G clock via llu interface). UE1 may just forward the corrected (g)PTP message to the UE2/DS-TT. In contrast to the scenario 2a, UE2 is still inside the 5G PTP instance. Therefore, the 5GS controls UE2’s DS-TT operation (e.g. via PMIC)

Scenario 2c (Fig. 6):

SL sync based on Il-plane (i.e. (g)PTP) with SL UE in coverage

It is assumed that both UE1 and UE2 are in 5GS coverage. They are (g)PTP end stations (e.g. DS-TTs). As UE2 has coverage, it can sync with the gNB to the 5G clock. The DS-TTs can exchange (g)PTP messages to sync to the vertical clock (i.e. the clock used by the end stations) indirectly via llu interfaces (UL sync process enabled in R17) or directly via PC5 (extension of UL sync from R17 for SL). This scenario may not have a significant impact in 5G specification as PC5 is only used for (g)PTP traffic but still the 5G PTP instance may be configured based on R17 methods. As another option, the 5G PTP instance of one of the UEs may be configured via PC5 interface.

When there are more than one potential Lead/Relay UEs that offer time services, selection of a lead UE shall be based on the service capabilities, e.g. whether a certain UE acts as GM or slave. Example service capabilities in case of time service are Time Synchronization Accuracy, Holdover capabilities, priority, BMCA, time synchronization source based on SLSS ID employed, etc.

Fig. 7 shows an example embodiment of the invention to explain the procedure. In Fig. 7, it is assumed that UE1 and UE3 offer its capability to act as a GM to UE2. The actions are substantially as follows:

1) Actions 1 and 2 for both UE1 and UE3: In action 1, USER#1(UE1) gets the ProSe/PC5 related identifier and/or application code, to be used in action 2. In action 2, UE1 is authenticated and ProSe/PC5 related parameters are provided to the UE as a lead UE. In this case, the existing ProSe UE-to-NW relay procedure may be reused. USER#3 (UE3) performs actions 1 and 2 correspondingly. UE1 and UE3 are potential lead UEs.

2) Actions 1 and 3 for UE2: USER#2(UE2) performs action 1 in the same way as UE1 and UE3. Instead of action 2, UE2 performs action 3 where ProSe/PC5 related parameters are provided to the UE as a remote UE. 3) Action 4 for both UE1 and UE3: USER#1(UE1) and USER#3(UE3) send the announcing/discovery messages to allow the other UEs in proximity (e.g. UE2) to discover them as providers of time synchronization service following sidelink discovery model A. That is, each of UE1 and UE3 initiates the discovery of other users who are interested in using the application function and are in its proximity by using direct discovery. For example, USER#1 wants to provide time service to other users by using one to one communication over PC5 reference point. UE1 shall provide the Time Synchronization info and Service capabilities as a part of the discovery announcement. In one embodiment, the Lead UE could employ the sidelink synchronization signals to inform UEs of the resources and/or type of synchronization it can provide.

Current NR 3GPP specifications have split the 672 physical layer sidelink identities in two groups: i. UEs in coverage or UEs getting synchronization directly from a UE in coverage use Ids in 0-335 range. ii. UEs out of coverage with no direct connection to a UE in coverage use

Ids in the 336-671 range.

These two pre-established ranges could further be subdivided to reserve ranges, statically (defined in standards) or semi-statically (via System information, for example), for Lead UEs with providing different timing services and with different capabilities.

4) Action 5: USER#2(UE2) selects the lead UE based on the configured time synchronization criteria and other factors like signal strength. Note that a Lead/Relay UE selection algorithm is employed by other users (Remote UE/UE2) to decide which lead/relay UE services to exploit. This algorithm is described further below with respect to Fig. 8. In Fig. 7, UE2 selects UE1 as lead UE. The selection of the lead UE may be continuously repeated, e.g. once in every four discovery periods.

5) Action 6: USER#1(UE1) gets a response from some users (e.g. UE2/Remote UE) who want to use its time service (i.e. selected UE1 as lead UE).

6) (optional, not shown in Fig. 7) USER#1(UE1) (i.e. the lead/relay UE selected by

UE2) creates a service user list including the users that sent a response to the discovery message, and checks with an Application Server associated with the application function regarding which of the stated users are authorized to participate in the one to one communication. After checking, the Application Server provides a Service Member List and various information for this service communication including Application Layer Group ID and Destination IP address to the lead UE(UE1). The lead UE(UE1) provides the Application Layer Group ID and Destination Layer-2 ID to other member UEs in the Service Member List (e.g. to UE2).

Lead/Relay UE selection algorithm in Remote UE

Currently, Remote UE selects the Lead UE (Service provider) based on many factors like RSRP of PC5, relay/lead UE capability (e.g.: time synchronization capability), Uu channel condition, etc. According to some example embodiments, this procedure may be enhanced to consider new factors such as timing service availability by the Lead UE. In case of discovery Model A, most of the information needed for lead/relay UE selection decision are received in the announcement message of the lead UE (announcing UE). Model A is one of the models for direct discovery. In Model A, the UE (e.g. lead UE in our case) sends the announcing/discovery message to allow the other UE in proximity to discover it. The announcing/discovery message can be something like „l am here". Another discovery model (model B) defines that a UE (e.g. remote UE in the present case) sends a discovery solicitation message and the other UEs (e.g. lead UE) in proximity send the discovery response message to allow the remote UE to discover it.

Fig. 8 shows a method of lead UE selection according to some example embodiments of the invention. In this method, in a first decision, for UEs, it is decided based on the conventional criteria (e.g. radio criteria) if they are candidates as lead UEs. If only one of the UEs is left as a candidate, this UE is selected. If more than 1 candidate remains, it is checked which of the UEs has the TimeSync capability. If only one of these candidates has the TimeSync capability it is selected. If there are more than one remaining candidates, the service performances of the timesync capability (e.g. holdover time, accuracy) are used to order the remaining candidates. The UE with the best performance is selected. In some example embodiments, the first selection based on conventional criteria may be omitted. I.e., the selection may be performed based on the availability of the timesync service and potentially its performance only.

Fig. 9 shows an apparatus according to an example embodiment of the invention. The apparatus may be a terminal (in particular: a UE), such as a UE offering timesync service, or an element thereof. Fig. 10 shows a method according to an example embodiment of the invention. The apparatus according to Fig. 9 may perform the method of Fig. 10 but is not limited to this method. The method of Fig. 10 may be performed by the apparatus of Fig. 9 but is not limited to being performed by this apparatus.

The apparatus comprises means for offering 110, means for monitoring 120, and means for providing 130. The means for offering 110, means for monitoring 120, and means for providing 130 may be an offering means, monitoring means, and providing means, respectively. The means for offering 110, means for monitoring 120, and means for providing 130 may be an offerer, monitor, and provider, respectively. The means for offering 110, means for monitoring 120, and means for providing 130 may be a offering processor, monitoring processor, and providing processor, respectively.

The means for offering 110 offers a timing service of a first terminal to a second terminal via a direct interface (e.g. PC5) between the first terminal and the second terminal (S110). The means for monitoring 120 monitors if an acceptance of the offer is received from the second terminal (S120). For example, the means for monitoring 120 may monitor if the acceptance is received via the direct interface.

If the acceptance is received (S120 = yes), the means for providing 130 provides the timing service to the second terminal via the direct interface (S130).

In some example implementations, the acceptance of S120 may be received on the SL level and/or on the PTP level:

If the timing service is integrated to SL operation of SL discovery procedure or SL communication link establishment, the monitoring the acceptance may be detected by two ways: i) using model B SL discovery, the offering (S110) is performed by sending SL discovery solicitation message, the monitoring of acceptance (S120) may be performed by detecting DL discovery response message. After receiving SL discovery response message, the providing (S130) corresponds to setting up SL one-to-one communication link to the peer UE for providing the timing service. ii) using model A SL discovery, the offering (S110) is performed by sending model

A SL discovery message in which timing service related information is included. The acceptance may be monitored (S120) by receiving SL one-to- one communication link establishment request. The providing (S130) may correspond to accepting the connection establishment and providing the timing service via the established communication link.

On PTP level, the acceptance may be detected (S120) at the lead UE (master) if it receives PTP requests from the remote UE (slave). That is, in order to use PTP, the slave sends PTP Delay_Request messages and receives the corresponding PTP Delay_Responses from the master.

Fig. 11 shows an apparatus according to an example embodiment of the invention. The apparatus may be a terminal (in particular: a UE), such as a UE receiving a timing service, or an element thereof. Fig. 12 shows a method according to an example embodiment of the invention. The apparatus according to Fig. 11 may perform the method of Fig. 12 but is not limited to this method. The method of Fig. 12 may be performed by the apparatus of Fig. 11 but is not limited to being performed by this apparatus.

The apparatus comprises means for monitoring 310, means for providing 320, and means for receiving 330. The means for monitoring 310, means for providing 320, and means for receiving 330 may be a monitoring means, providing means, and receiving means, respectively. The means for monitoring 310, means for providing 320, and means for receiving 330 may be a monitor, identifier, and receiver, respectively. The means for monitoring 310, means for providing 320, and means for receiving 330 may be a monitoring processor, providing processor, and receiving processor, respectively. The means for monitoring 310 monitors whether a second terminal receives an offer of a timing service of a first terminal via a direct interface (e.g. PC5) between the first terminal and the second terminal (S310).

If the offer is received (S310 = yes), the means for providing 320 provides an acceptance of the offer to the first terminal (S320). For example, it may provide the acceptance via the direct interface. Then, the means for receiving 330 receives the timing service from the first terminal (S330).

S310 to S330 correspond to S110 to S130, respectively, such that the explanations of example implementations of S110 to S130 apply to S310 to S330 correspondingly.

Fig. 13 shows an apparatus according to an embodiment of the invention. The apparatus comprises at least one processor 810, at least one memory 820 including computer program code, and the at least one processor 810, with the at least one memory 820 and the computer program code, being arranged to cause the apparatus to at least perform at least the method according to at least one of Figs. 10 and 12 and related description.

Some example embodiments are explained with respect to a 5G network. However, the invention is not limited to 5G. It may be used in other service based networks providing mobility, too, e.g. in previous of forthcoming generations of 3GPP networks such as 4G, 6G, or 7G, etc. It may be used in non-3GPP mobile communication networks providing proximity services, too.

One piece of information may be transmitted in one or plural messages from one entity to another entity. Each of these messages may comprise further (different) pieces of information.

Names of network elements, network functions, protocols, and methods are based on current standards. In other versions or other technologies, the names of these network elements and/or network functions and/or protocols and/or methods may be different, as long as they provide a corresponding functionality. If not otherwise stated or otherwise made clear from the context, the statement that two entities are different means that they perform different functions. It does not necessarily mean that they are based on different hardware. That is, each of the entities described in the present description may be based on a different hardware, or some or all of the entities may be based on the same hardware. It does not necessarily mean that they are based on different software. That is, each of the entities described in the present description may be based on different software, or some or all of the entities may be based on the same software. Each of the entities described in the present description may be deployed in the cloud.

According to the above description, it should thus be apparent that example embodiments of the present invention provide, for example, a terminal (such as a UE) or a component thereof, an apparatus embodying the same, a method for controlling and/or operating the same, and computer program(s) controlling and/or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).

Implementations of any of the above described blocks, apparatuses, systems, techniques or methods include, as non-limiting examples, implementations as hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof. Each of the entities described in the present description may be embodied in the cloud.

It is to be understood that what is described above is what is presently considered the preferred example embodiments of the present invention. However, it should be noted that the description of the preferred example embodiments is given by way of example only and that various modifications may be made without departing from the scope of the invention as defined by the appended claims.

The phrase “at least one of A and B” comprises the options only A, only B, and both A and B. The terms “first X” and “second X” include the options that “first X” is the same as “second X” and that “first X” is different from “second X”, unless otherwise specified.