TITLE:

SYNCHRONIZATION ACCURACY ENHANCEMENT WITH COMMON 5GS TIME FOR SIDELINK DEVICES

TECHNICAL FIELD:

[0001] Some example embodiments may generally relate to mobile or wireless telecommunication systems, such as Long Term Evolution (LTE), fifth generation (5G) radio access technology (RAT), new radio (NR) access technology, and/or other communications systems. For example, certain example embodiments may relate to systems and/or methods for enhancing synchronization accuracy.

BACKGROUND:

[0002] Examples of mobile or wireless telecommunication systems may include 5G RAT, the Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), LTE Evolved UTRAN (E-UTRAN), LTE-Advanced (LTE- A), LTE-A Pro, NR access technology, and/or MulteFire Alliance. 5G wireless systems refer to the next generation (NG) of radio systems and network architecture. A 5G system is typically built on a 5G NR, but a 5G (or NG) network may also be built on E- UTRA radio. It is expected that NR can support service categories such as enhanced mobile broadband (eMBB), ultra-reliable low-latency-communication (URLLC), and massive machine type communication (mMTC). NR is expected to deliver extreme broadband, ultra-robust, low latency connectivity, and massive networking to support the Internet of Things (loT). The next generation radio access network (NG-RAN) represents the RAN for 5G, which may provide radio access for NR, LTE, and LTE-A. It is noted that the nodes in 5G providing radio access functionality to a user equipment (e.g., similar to the Node B in UTRAN or the Evolved Node B (eNB) in LTE) may be referred to as next-generation Node B (gNB) when built on NR radio, and may be referred to as next-generation eNB (NG-eNB) when built on E-UTRA radio.

SUMMARY:

[0003] In accordance with some embodiments, a method may include receiving at least one configuration. The method may further include receiving at least one reference time. The method may further include determining whether to apply the received at least one reference time as an egress time stamp to at least one generalized precision time protocol (gPTP) message.

[0004] In accordance with certain embodiments, an apparatus may include means for receiving at least one configuration. The apparatus may further include means for receiving at least one reference time. The apparatus may further include means for determining whether to apply the received at least one reference time as an egress time stamp to at least one generalized precision time protocol (gPTP) message.

[0005] In accordance with various embodiments, an apparatus may include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code may be configured to, with the at least one processor, cause the apparatus to at least receive at least one configuration. The at least one memory and the computer program code may be further configured to, with the at least one processor, cause the apparatus to at least receive at least one reference time. The at least one memory and the computer program code may be further configured to, with the at least one processor, cause the apparatus to at least determine whether to apply the received at least one reference time as an egress time stamp to at least one generalized precision time protocol (gPTP) message.

[0006] In accordance with some embodiments, a non-transitory computer readable medium may be encoded with instructions that may, when executed in hardware, perform a method. The method may include receiving at least one configuration. The method may further include receiving at least one reference time. The method may further include determining whether to apply the received at least one reference time as an egress time stamp to at least one generalized precision time protocol (gPTP) message.

[0007] In accordance with certain embodiments, a computer program product may perform a method. The method may include receiving at least one configuration. The method may further include receiving at least one reference time. The method may further include determining whether to apply the received at least one reference time as an egress time stamp to at least one generalized precision time protocol (gPTP) message.

[0008] In accordance with various embodiments, an apparatus may include circuitry configured to receive at least one configuration. The circuitry may further be configured to receive at least one reference time. The circuitry may further be configured to determine whether to apply the received at least one reference time as an egress time stamp to at least one generalized precision time protocol (gPTP) message. [0009] In accordance with some embodiments, a method may include transmit at least one reference timing to a slave user equipment.

[0010] In accordance with certain embodiments, an apparatus may include means for transmitting at least one reference timing to a slave user equipment.

[0011] In accordance with various embodiments, an apparatus may include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code may be configured to, with the at least one processor, cause the apparatus to at least transmit at least one reference timing to a slave user equipment.

[0012] In accordance with some embodiments, a non-transitory computer readable medium may be encoded with instructions that may, when executed in hardware, perform a method. The method may include transmitting at least one reference timing to a slave user equipment.

[0013] In accordance with certain embodiments, a computer program product may perform a method. The method may include transmitting at least one reference timing to a slave user equipment.

[0014] In accordance with various embodiments, an apparatus may include circuitry configured to transmit at least one reference timing to a slave user equipment.

BRIEF DESCRIPTION OF THE DRAWINGS:

[0015] For proper understanding of example embodiments, reference should be made to the accompanying drawings, wherein:

[0016] FIG. 1 illustrates an example of a 5G system for supporting TSN time synchronization.

[0017] FIG. 2 illustrates an example of a 5GS clock used to time stamp gPTP messages of a TSN clock domain.

[0018] FIG. 3 illustrates an example of a distribution of UL time synchronization information.

[0019] FIG. 4 illustrates an example of UE and gNB frame misalignment due to propagation delay over an air interface.

[0020] FIG. 5 illustrates a diagram according to some embodiments.

[0021] FIG. 6 illustrates an example of a signaling diagram according to certain embodiments.

[0022] FIG. 7 illustrates an example of a flow diagram of a method according to various embodiments. [0023] FIG. 8 illustrates an example of a flow diagram of another method according to various embodiments.

[0024] FIG. 9 illustrates an example of various network devices according to some embodiments.

[0025] FIG. 10 illustrates an example of a 5G network and system architecture according to certain embodiments.

DETAILED DESCRIPTION:

[0026] It will be readily understood that the components of certain example embodiments, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of some example embodiments of systems, methods, apparatuses, and computer program products for enhancing synchronization accuracy is not intended to limit the scope of certain embodiments, but is instead representative of selected example embodiments.

[0027] 3GPP Release (Rel)-16 describes 5G and time sensitive network (TSN) clock distribution models via 5GS for time sensitive communications, as shown in FIG. 1 . Such models may include a 5GS synchronization layer for synchronizing 5G network nodes (/.e., user equipment (UE), network entity (NE), user plane function (UPF)) with each other, while the TSN domain synchronization layer may synchronize TSN devices with each other.

[0028] The TSN domain synchronization may be achieved by distributing TSN domain clocks to various TSN devices using generic precision time protocol (gPTP) messages. When processed by a 5G system as a time-aware relay, the amount of time gPTP messages spend within a 5GS may be calculated, and appropriate corrections may made to the (g)PTP messages during egress from the 5GS. This may be performed by the 5GS clock timestamping each gPTP message during ingress and egress at the 5GS. In 3GPP Rel-16, the TSN working clock, such as a grandmaster (GM), may be provided from the network; for example, the ingress timestamp may be from a network-side TSN translator (NW-TT), while the egress timestamp may be from the device-side TSN translator (DS-TT), as shown in FIG. 2.

[0029] 3GPP has included some enhancements to support industrial internet of things (HoT), including uplink synchronization via 5GS, multiple working clock domains connected to the UE, and time synchronization of UEs with the TSN GM clock attached to the UE side via a 5G system. Such time synchronization of UEs with the TSN GM clock may include support for TSN GM originating from the UE side (DS-TT), with the ingress on the DS-TT of the UE providing TSN GM, and the egress from the DS-TT of another UE or at the UPF/NW-TT, as shown in FIG. 3.

[0030] In order for a 5GS to calculate the residence time of a gPTP message, the ingress and the egress node of the network, /.e., DS-TT and NW-TT, respectively, may need to have a common understanding of the 5GS time. In a 3GPP system, 5GS time may be distributed in a 5G network using an underlying gPTP infrastructure, and may be transmitted from a network entity (NE) to each UE using radio resource control (RRC) signaling, whether broadcast or unicast. Underlying 5G radio frame timing at the NE and UE may be used as a common reference for delivering 5G timing information. In this way, when a UE receives an SIB9/RRC message, the UE may associate received time information with its own reference system frame number (SFN) boundary. However, radio frame boundaries at the NE and UE may not exactly match each other; for example, the downlink frame boundary illustrated in FIG. 4 at the UE may be shifted by the propagation delay (PD) with respect to the corresponding frame boundary at the NE.

[0031] While 3GPP Rel-17 may include PD compensation enhancements, this may not always improve the accuracy of acquired time synchronizations if the estimation of PD is insufficient. For example, when using UE timing advance (TA) information, due to the limitations of TA granularity and update intervals, TA-based PD compensation may cause errors for time synchronization correction.

[0032] 3GPP Rel-17 also considers a TSN GM attaching to the UE side via the 5G system. Here, ingress timestamping (TSi) and egress timestamping (TSe) for gPTP event messages may both be performed on the UE side by using 5G clock timing. When PD compensation is applied to the synchronization and timing information, it may be subject to an error associated with inaccurate PD estimation on each of the air interface links that a gPTP message traverses, such as a link between a UE providing TSN GM and a NE, as well as the link between a NE and a UE receiving TSN GM. While sidelink (SL) operations may be enabled among relevant UEs in proximity, and PD over SL may be negligible compared to PD between the NE and UE, more accurate common 5G timing among relevant UEs may be provided over SL rather than over a Uu interface between the UE and NE.

[0033] Certain embodiments described herein may have various benefits and/or advantages to overcome the disadvantages described above. For example, certain embodiments may avoid introduction of PD compensation related errors when 5GS residence time of the gPTP message is calculated on the UE side, which may increase the accuracy of synchronization. More accuracy gains may be achieved in an environment where it is not possible to apply PD compensation to the reference time information when e.g., the UEs and/or the NEs do not have such capability. In such a case, the synchronization accuracy error would be even higher, especially if the distance between the UE and the NE becomes larger. Thus, certain embodiments discussed below are directed to improvements in computer-related technology.

[0034] As noted above, since UEs may be in close proximity, PD on SL between UE may be negligible or smaller than the error related to when propagation delay compensation is applied to the 5GS time stamps at the master UE and at the slave UE for the 5GS timing received from the NE. Using this principle, some embodiments described herein may include a UE (/.e., master UE), which provides TSN GM, forwarding 5GS time (/.e., reference time information) received from a serving NE via sidelink to other UE (/.e., slave UE). The master UE may add a TSi to gPTP messages using the 5GS time, which it receives from its serving NE. The 5GS time which is forwarded on the sidelink and used for timestamping may be either compensated for PD by the UE, pre-compensated for PD by the NE, or not compensated for the PD. Herein, “PD” may refer to the propagation delay between the master UE and its serving NE. The determination regarding compensation may be based upon any of network node (e.g., gNB) and UE capabilities to perform PD compensation; the distance of the master and/or slave UE from their serving NEs; the location and type of the devices receiving the time information, e.g., whether the target TSN devices are located only behind other UEs or also behind the UPF and the core network; and/or whether the reference time information needs to be provided to out of coverage UEs. Furthermore, the master UE may use the uncompensated 5GS time, but its PD may be known to other devices, e.g., via sidelink signalling, by appending it to gPTP message, or by using UE-to-network and network-to-UE signalling. Subsequently, when the gPTP message is received by the slave UE, it may check the proximity condition to verify whether 5GS time forwarded by the master UE can be used to determine the TSe and calculate the residence time of the gPTP message. Otherwise, it may use the 5GS time provided by the serving NE. [0035] FIG. 6 illustrates an example of a signaling diagram depicting how to improve synchronization accuracy. NE 630, NE 660, and UPF/NW-TT 670 may be similar to NE 920, and slave LIE 640 and master UE 650 may be similar to UE 910, as illustrated in FIG. 9, according to certain embodiments. At 601 , the serving NE 630 may configure slave UE 640 the relevant configurations related to the synchronization timing to be used for egress timestamping. The configuration may be at least one threshold. In some embodiments, thresholds may be a sidelink reference signal received power (RSRP) threshold, a zone configuration including “zone threshold,” and/or a distance threshold, which is used by the slave UE to determine which synchronization timing information (e.g. received from the master UE 650 or received from the serving NE 630) is used for egress timestamping. At 603, as another alternative, master UE 650 instead of the serving NE 630 may transmit to slave UE 640 the sidelink RSRP threshold.

[0036] At 605, the serving NE 660 may transmit zone configurations to master UE 650, which, in response, may transmit to slave UE 640 zone ID advertisements at 607. It is noted that 605-607 may be in response to slave UE 640 receiving zone configurations from NE 630 at 601. Zone ID advertisements may be similar to those specified in 3GPP Rel-16 for vehicle-to-X (V2X) sidelink. At 609, master UE 650 may transmit to slave UE 640 GNSS position advertisements. The zone ID advertisement at 607 or GNSS position advertisement at 609 may be transmitted periodically or transmitted together with 5G_M reference times, later discussed at 619.

[0037] At 611 , slave UE 640 and master UE 650 may establish sidelink unicast communications. The sidelink unicast communication may be established either for synchronization timing purpose or for other sidelink services. At 613, slave UE 640 and master UE 650 may perform groupcast communications to determine the difference between slave UE 640’s PD towards its serving NE 630 and master UE 650’s PD towards its serving NE 660. At 615, serving NE 630 may transmit to slave UE 640 5G_S reference times, and at 617, serving NE 660 may transmit to master UE 650 5G_M reference times, either of which may be sent periodically, e.g. using broadcasted or dedicated RRC signalling. At 619, master UE 650 may transmit to slave UE 640 the received 5G_M reference times over sidelink. At 621 , master UE 650 may initiate the transmission of gPTP messages to slave UE 640 via NE 660, UPF/NW-TT 670, and NE 630.

[0038] At 623, slave UE 640 may determine whether to use 5G_S received from its serving NE 630 or 5G_M receiving from master UE 650 over sidelink as an egress timestamp for the gPTP messages. In certain embodiments, the determination may be performed by upon the successful or unsuccessful establishment of unicast communications at 611. In various embodiments, slave UE 640 may use 5G_M upon determining that slave UE 640 and slave UE 650 satisfy various, predetermined criteria as configured at 601. For example, slave UE 640 may determine whether the received power of the 5GS time transmission (or other transmission) received from master UE 650 is above configured SL RSRP thresholds. Additionally or alternatively, the configured SL RSRP threshold may be associated with the transmission power of sidelink transmission of 5G_M from master UE 650. By determining that the power loss of the transmission between slave UE 640 and master UE 650 is below a certain limit (/.e. the received SL RSRP from master UE is higher than the configured SL RSRP threshold), slave UE 640 may determine that slave UE 640 and master UE 650 are sufficiently close to each other.

[0039] In another example, slave UE 640 may estimate its distance from master UE 650 by reading the sidelink zone ID advertised by master UE 650 at 607. For instance, slave UE 640 may estimate the difference of its own zone ID and the received sidelink zone ID from master UE 650. If the difference of zone ID of its own and master UE 650 is smaller/larger than the configured zone threshold (e.g., only if slave UE 640 estimates that it is in the same zone or at least one adjacent zone to master UE 650), slave UE 640 may determine to use 5G_M.

[0040] In a further example, if slave UE 640 receives GNSS position advertisements from master UE 650 at 609, slave UE 640 may calculate its distance from master UE 650 based on the GNSS position of slave UE 640. In addition, when the distance is below a configured threshold, slave UE 640 may use 5G_M received from master UE 650.

[0041] In yet another example, slave UE 640 may establish unicast communications with master UE 650, for example, by using sidelink unicast establishment procedures described in 3GPP Rel-16. Furthermore, upon establishing unicast communications with master UE 650, slave UE 640 may determine that it is sufficiently close to master UE 650 to use 5G_M. In an additional example, slave UE 640 may use sidelink groupcast communication initiated by master UE 650 to estimate the difference between the PD of slave UE 640 towards its serving NE 630 and PD of master UE 650 towards its serving NE 660. Based on the estimated PD difference, slave UE 640 may determine to use 5G_M or not. [0042] In various embodiments, if slave UE 640 determines that it is more than a predefined distance from master UE 650, slave UE 640 may then use the 5GS time (5G_S) received from NE 630. In order to improve accuracy for this 5GS time, slave UE 640 may apply PD compensation to both ingress and egress timestamps if master UE 650 doesn’t apply PD compensation to ingress timestamps. Since slave UE 640 may only know PD between slave UE 640 and serving NE 630, rather than PD between master UE 650 and its respective serving NE 660, master UE 650 may transmit PD information between master UE 650 and serving NE 660 to slave UE 640. This may be performed by adding PD information to the gPTP message and/or transmitting information via sidelink to slave UE 640. Alternatively, master UE 650 may adjust the 5GS timing by using PD compensation before transmission to slave UE 640 via sidelink, and use 5GS time compensated for PD when adding an ingress timestamp to the gPTP message.

[0043] In various embodiments, the 5GS timing acquired via SL by slave UE 640 should be the same as the 5GS timing acquired from its serving NE 630 with PD compensation. However, if 5GS timing from the serving NE with PD compensation is not the same as 5GS timing acquired over SL while slave UE 640 determines to use 5GS timing acquired from master UE 650, slave UE 640 may use the 5GS timing acquired over SL from master UE 650 to adjust PD compensation offsets towards its serving NE 630. When slave UE 640 determines that it is more than a predetermined distance from master UE 650 and needs to utilize 5GS timing received from serving NE 630, the adjusted PD compensation offset may be used at least until a next updated PD value is determined.

[0044] In certain embodiments, reference time information related to 5GS time provided by the NE may further indicate SFNs of the NE. For example, there may be situations where SFNs of the NE serving master UE 650 are not synchronized with the SFN at the NE serving slave UE 640.

[0045] In a first example, prior to forwarding on SL the 5GS time received from NE 660 at 619, master UE 650 may translate the 5GS time referenced at the SFN of NE 660 to the 5GS time referenced at the time of SL transmission of the reference time information.

[0046] In a second example, slave UE 640 may track the frame timing in NE 660 from which the reference time information forwarded by master UE 650 comes from. To make it possible, master UE 650 may indicate to slave UE 640 the identification of NE 660 or cell which should be tracked by slave UE 640, such as indicating physical cell identifier (PCI) of the cell served by serving NE 660.

[0047] FIG. 7 illustrates an example of a flow diagram of a method that may be performed by a slave UE, such as UE 910 illustrated in FIG. 9, according to various embodiments. At 701 , the slave UE may receive relevant configurations related to the synchronization timing to be used for egress timestamping. The configuration may be received either from the slave UE’s serving NE, which may be similar to NE 920 in FIG.9 or from a master UE, which may also be similar to UE 910 in FIG. 9. The configuration may be at least one threshold. In some embodiments, thresholds may be a sidelink RSRP threshold, a zone configured with “zone threshold,” and/or a distance threshold, which is used by the slave UE to determine which synchronization timing information (e.g. received from the master UE or received from the serving NE) is used for egress timestamping. At 703, the slave UE may receive from the master UE sidelink RSRP thresholds, which may be in response to the slave UE receiving sidelink RSRP thresholds from a NE, which may be similar to NE 920 in FIG. 9.

[0048] At 705, the slave UE may receive from the master UE zone ID advertisements. Zone ID advertisements may be similar to those specified in 3GPP Rel-16 for vehicle-to-X (V2X) sidelink. At 707, the slave UE may receive from the master UE GNSS position advertisements, which may be transmitted periodically or transmitted together with 5G_M reference times.

[0049] At 709, the slave UE and the master UE may establish sidelink unicast communications. The sidelink unicast communication may be established either for synchronization timing purpose or for other sidelink services. The successful or unsuccessful establishment of unicast communications may be used for determination. At 711 , the slave UE and master UE may perform groupcast communications to determine the difference between the slave UE’s PD towards its serving NE and the master UE’s PD towards its serving NE. At 713, the slave UE may receive from the serving NE 5G_S reference times, e.g., using broadcasted or dedicated RRC signalling, and at 715, may receive from the master UE 5G_M reference times over sidelink, both of which may be received periodically. At 717, the slave UE may receive gPTP messages from the NE.

[0050] At 719, the slave UE may determine whether to use 5G_S or 5G_M as an egress timestamp for the gPTP messages. In various embodiments, the slave UE may use 5G_M upon determining that the slave UE and the master UE satisfy various, predetermined criteria. For example, the slave UE may determine whether the received power of the 5GS time transmission (or other transmission) received from the master UE is above a configured SL RSRP threshold. Additionally or alternatively, the configured SL RSRP threshold may be associated with the transmission power of sidelink transmission of 5G_M from the master UE. By determining that the power loss of the transmission between the slave UE and master UE is below a certain limit (/.e., the received SL RSRP from master UE is higher than the configured SL RSRP threshold), the slave UE may determine that the slave UE and the master UE are sufficiently close to each other.

[0051] In another example, the slave UE may estimate the distance from the master UE by reading the sidelink zone ID advertised by the master UE. For example, the slave UE may estimate the difference of its own zone ID and the received sidelink zone ID from the master UE. If the difference of the zone ID of its own and master UE is smaller/larger than the configured zone threshold (e.g., only if the slave UE estimates that it is in the same zone or at least one adjacent zone to the master UE), the slave UE may determine to use 5G_M.

[0052] In a further example, if the slave UE receives GNSS position advertisements from the master UE, the slave UE may calculate the distance from the master UE based on the GNSS position of the slave UE. In addition, when the distance is below a configured threshold, the slave UE may use 5G_M received from the master UE. [0053] In yet another example, the slave UE may establish unicast communications with the master UE, for example, by using sidelink unicast establishment procedure described in 3GPP Rel-16. Furthermore, upon establishing unicast communications with the master UE, the slave UE may determine that it is sufficiently close to the master UE to use 5G_M. In an additional example, the slave UE may use sidelink groupcast communication initiated by the master UE to estimate the difference between the slave UE PD towards its servicing NE and the master UE’s PD towards its serving NE. Based on the estimated PD difference, the slave UE may determine whether to use 5G_M or not.

[0054] In various embodiments, if the slave UE determines that it is more than a predefined distance from the master UE, the slave UE may then use the 5GS time received from the NE. In order to improve accuracy for this 5GS time (5G_S), the slave UE may apply PD compensation to both ingress and egress timestamps if the master UE does not apply PD compensation to ingress timestamps. Since the slave UE may only know PD between the slave UE and its serving NE, rather than PD compensation between the master UE its respective serving NE, the master UE may transmit PD information between the master UE and the serving NE of the slave UE. This may be performed by adding PD information to the gPTP message and/or transmitting information via sidelink to the slave UE. Alternatively, the master UE may adjust the 5GS timing before transmission to the slave UE via sidelink, and use 5GS time compensated for PD when adding an ingress timestamp to the gPTP message.

[0055] In various embodiments, the 5GS timing acquired via SL by the slave UE may be the same as the 5GS timing acquired from its own NE via PD compensation. For example, if the slave UE determines that 5GS timing from its own NE with PD compensation is not the same as 5GS timing acquired over SL, the slave UE may use the 5GS timing acquired over SL to adjust PD compensation offsets. When the slave UE determines that it is more than a predetermined distance from the master UE and needs to utilize 5GS received from the NE, the adjusted PD compensation offset may be used at least until a next updated PD value is determined.

[0056] In certain embodiments, reference time information related to 5GS time provided by the NE may further indicate SFNs of the NE. For example, there may be situations where SFNs of the NE serving the master UE are not synchronized with the SFN timing of the SFN at the NE serving the slave UE.

[0057] In a first example, prior to forwarding on SL the 5GS time received from its NE, the master UE may translate the 5GS time referenced at the SFN of its NE to the 5GS time referenced at the time of SL transmission of the reference time information.

[0058] In a second example, the slave UE may track the frame timing in the NE from which the reference time information forwarded by the master UE originates. To make it possible, the master UE may indicate the identification of the NE or cell which should be tracked by the slave UE, such as indicating PCIs of the cell.

[0059] FIG. 8 illustrates an example of a flow diagram of a method that may be performed by a master UE, such as UE 910 illustrated in FIG. 9, according to various embodiments. At 801 , the master UE may configure a slave UE, which may also be similar to UE 910 illustrated in FIG. 9, with relevant configurations related to the synchronization timing to be used for egress timestamping. The configuration may be at least one threshold.

[0060] At 803, the master UE may receive zone configurations from a NE, and in response, may transmit zone ID advertisements to the slave UE at 805. Zone ID advertisements may be similar to those specified in 3GPP Rel-16 for vehicle-to-X (V2X) sidelink. At 807, the master UE may transmit to the slave UE GNSS position advertisements.

[0061] At 809, the slave UE and the master UE may establish unicast communications. The successful or unsuccessful establishment of unicast communications may be used by the slave UE to determine whether to use 5G_S received from its serving NE or 5G_M received from the master UE over sidelink as an egress timestamp for the gPTP messages. At 811 , the slave UE and master UE may perform groupcast communications to determine the difference of PD between the slave UE and master UE. At 813, the master UE may receive from the NE 5G_M reference times, which may be received periodically, e.g., using broadcasted or dedicated RRC signaling, and then transmitted to the slave UE at 815. At 817, the master UE may initiate the transmission of gPTP messages to the NE.

[0062] FIG. 9 illustrates an example of a system according to certain example embodiments. In one example embodiment, a system may include multiple devices, such as, for example, UE 910 and/or NE 920.

[0063] UE 910 may include one or more of a mobile device, such as a mobile phone, smart phone, personal digital assistant (PDA), tablet, or portable media player, digital camera, pocket video camera, video game console, navigation unit, such as a global positioning system (GPS) device, desktop or laptop computer, single-location device, such as a sensor or smart meter, or any combination thereof.

[0064] NE 920 may be one or more of a base station, such as an eNB or gNB, a serving gateway, a server, and/or any other access node or combination thereof. Furthermore, UE 910 and/or NE 920 may be one or more of a citizens broadband radio service device (CBSD).

[0065] NE 920 may further comprise at least one gNB-CU, which may be associated with at least one gNB-DU. The at least one gNB-CU and the at least one gNB-DU may be in communication via at least one F1 interface, at least one X _n -C interface, and/or at least one NG interface via a 5GC.

[0066] UE 910 and/or NE 920 may include at least one processor, respectively indicated as 911 and 921. Processors 911 and 921 may be embodied by any computational or data processing device, such as a central processing unit (CPU), application specific integrated circuit (ASIC), or comparable device. The processors may be implemented as a single controller, or a plurality of controllers or processors.

[0067] At least one memory may be provided in one or more of the devices, as indicated at 912 and 922. The memory may be fixed or removable. The memory may include computer program instructions or computer code contained therein. Memories 912 and 922 may independently be any suitable storage device, such as a non- transitory computer-readable medium. A hard disk drive (HDD), random access memory (RAM), flash memory, or other suitable memory may be used. The memories may be combined on a single integrated circuit as the processor, or may be separate from the one or more processors. Furthermore, the computer program instructions stored in the memory, and which may be processed by the processors, may be any suitable form of computer program code, for example, a compiled or interpreted computer program written in any suitable programming language.

[0068] Processors 911 and 921 , memories 912 and 922, and any subset thereof, may be configured to provide means corresponding to the various blocks of FIGS. 6-8. Although not shown, the devices may also include positioning hardware, such as GPS or micro electrical mechanical system (MEMS) hardware, which may be used to determine a location of the device. Other sensors are also permitted, and may be configured to determine location, elevation, velocity, orientation, and so forth, such as barometers, compasses, and the like.

[0069] As shown in FIG. 9, transceivers 913 and 923 may be provided, and one or more devices may also include at least one antenna, respectively illustrated as 914 and 924. The device may have many antennas, such as an array of antennas configured for multiple input multiple output (MIMO) communications, or multiple antennas for multiple RATs. Other configurations of these devices, for example, may be provided. Transceivers 913 and 923 may be a transmitter, a receiver, both a transmitter and a receiver, or a unit or device that may be configured both for transmission and reception.

[0070] The memory and the computer program instructions may be configured, with the processor for the particular device, to cause a hardware apparatus, such as UE, to perform any of the processes described above (/.e., FIGS. 6-8). Therefore, in certain embodiments, a non-transitory computer-readable medium may be encoded with computer instructions that, when executed in hardware, perform a process such as one of the processes described herein. Alternatively, certain embodiments may be performed entirely in hardware.

[0071] In certain embodiments, an apparatus may include circuitry configured to perform any of the processes or functions illustrated in FIGS. 6-8. For example, circuitry may be hardware-only circuit implementations, such as analog and/or digital circuitry. In another example, circuitry may be a combination of hardware circuits and software, such as a combination of analog and/or digital hardware circuitry with software or firmware, and/or any portions of hardware processors with software (including digital signal processors), software, and at least one memory that work together to cause an apparatus to perform various processes or functions. In yet another example, circuitry may be hardware circuitry and or processors, such as a microprocessor or a portion of a microprocessor, that includes software, such as firmware, for operation. Software in circuitry may not be present when it is not needed for the operation of the hardware.

[0072] FIG. 10 illustrates an example of a 5G network and system architecture according to certain embodiments. Shown are multiple network functions that may be implemented as software operating as part of a network device or dedicated hardware, as a network device itself or dedicated hardware, or as a virtual function operating as a network device or dedicated hardware. The UE and NE illustrated in FIG. 10 may be similar to UE 910 and NE 920, respectively. The user plane function (UPF) may provide services such as intra-RAT and inter-RAT mobility, routing and forwarding of data packets, inspection of packets, user plane quality of service (QoS) processing, buffering of downlink packets, and/or triggering of downlink data notifications. The application function (AF) may primarily interface with the core network to facilitate application usage of traffic routing and interact with the policy framework.

[0073] The features, structures, or characteristics of example embodiments described throughout this specification may be combined in any suitable manner in one or more example embodiments. For example, the usage of the phrases “various embodiments,” “certain embodiments,” “some embodiments,” or other similar language throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with an example embodiment may be included in at least one example embodiment. Thus, appearances of the phrases “in various embodiments,” “in certain embodiments,” “in some embodiments,” or other similar language throughout this specification does not necessarily all refer to the same group of example embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more example embodiments.

[0074] Additionally, if desired, the different functions or procedures discussed above may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the described functions or procedures may be optional or may be combined. As such, the description above should be considered as illustrative of the principles and teachings of certain example embodiments, and not in limitation thereof.

[0075] One having ordinary skill in the art will readily understand that the example embodiments discussed above may be practiced with procedures in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, although some embodiments have been described based upon these example embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the example embodiments.

[0076] Partial Glossary

[0077] 3GPP Third Generation Partnership Project

[0078] 5G Fifth Generation

[0079] 5GC Fifth Generation Core

[0080] 5GS Fifth Generation System

[0081] AMF Access and Mobility Management Function

[0082] ASIC Application Specific Integrated Circuit

[0083] BS Base Station

[0084] CBSD Citizens Broadband Radio Service Device

[0085] CCCH Common Control Channel

[0086] CN Core Network

[0087] CPU Central Processing Unit

[0088] DS-TT Device-Side Time Sensitive Network Translator

[0089] eMBB Enhanced Mobile Broadband

[0090] eMTC Enhanced Machine Type Communication

[0091] eNB Evolved Node B

[0092] eOLLA Enhanced Outer Loop Link Adaptation

[0093] EPS Evolved Packet System

[0094] GM Grandmaster

[0095] gNB Next Generation Node B

[0096] GNSS Global Navigation Satellite System

[0097] GPS Global Positioning System

[0098] gPTP Generalized Precision Time Protocol

[0099] HDD Hard Disk Drive

[0100] IEEE Institute of Electrical and Electronics Engineers

[0101] HoT Industrial Internet of Things [0102] LTE Long-Term Evolution

[0103] LTE-A Long-Term Evolution Advanced

[0104] MAC Medium Access Control

[0105] MBS Multicast and Broadcast Systems

[0106] MCS Modulation and Coding Scheme

[0107] MEMS Micro Electrical Mechanical System

[0108] Ml MO Multiple Input Multiple Output

[0109] MME Mobility Management Entity

[0110] mMTC Massive Machine Type Communication

[0111] NAS Non-Access Stratum

[0112] NB-loT Narrowband Internet of Things

[0113] NE Network Entity

[0114] NG Next Generation

[0115] NG-eNB Next Generation Evolved Node B

[0116] NG-RAN Next Generation Radio Access Network

[0117] NR New Radio

[0118] NR-U New Radio Unlicensed

[0119] NW-TT Network-Side Time Sensitive Network Translator

[0120] OLLA Outer Loop Link Adaptation

[0121] PDA Personal Digital Assistance

[0122] PD Propagation Delay

[0123] PHY Physical

[0124] RAM Random Access Memory

[0125] RAN Radio Access Network

[0126] RAT Radio Access Technology

[0127] RLC Radio Link Control

[0128] RRC Radio Resource Control

[0129] RSRP Reference Signal Received Power

[0130] SFN System Frame Number

[0131] SIB System Information Block

[0132] SL Sidelink

[0133] SMF Session Management Function

[0134] SRB Signaling Radio Bearer

[0135] SSB Synchronization Signal Block

[0136] TR Technical Report [0137] TS Technical Specification

[0138] TSe Egress Timestamp

[0139] TSi Ingress Timestamp

[0140] TSN Time Sensitive Network

[0141] TTI Transmission Time Interval

[0142] Tx Transmission

[0143] UCI Uplink Control Information

[0144] UE User Equipment

[0145] UL Uplink

[0146] UMTS Universal Mobile Telecommunications System

[0147] U PF User Plane Function

[0148] URLLC Ultra-Reliable and Low-Latency Communication

[0149] UTRAN Universal Mobile Telecommunications System Terrestrial

Radio Access Network

[0150] WLAN Wireless Local Area Network