Control of time synchronization in wireless network
By enabling time synchronization and path delay compensation only when necessary, the method optimizes resource usage in 5G RANs, addressing inefficiencies and errors in existing 5G networks.
Patent Information
- Application Number
- JP2025086647
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2021-06-30
- Filing Date
- 2025-05-23
- Publication Date
- 2025-08-26
- Estimated Expiration
- 2042-05-04
AI Technical Summary
Existing 5G networks face challenges in ensuring accurate time synchronization in the Radio Access Network (RAN) due to the need for path delay compensation, which increases signaling and processing overhead, particularly in scenarios where the error introduced by path delay compensation can be higher than without it.
A method to enable and disable time synchronization and path delay compensation in the RAN only when necessary, optimizing resource usage by reducing signaling and processing in the RAN.
This approach reduces unnecessary signaling and processing in the RAN, improving resource efficiency and maintaining accurate time synchronization where needed, thereby addressing the inefficiencies and errors associated with constant path delay compensation.
Smart Images

Figure 2025124735000001_ABST
Abstract
Description
[Technical Field]
[0001] The present invention relates generally to controlling time synchronization in wireless networks, and more particularly to controlling time synchronization between user equipment (UE) and base stations in a Radio Access Network (RAN) of a wireless network. [Background technology]
[0002] The uses of the Internet of Things (IoT) are expanding, and each use comes with certain constraints.
[0003] One of the applications of IoT is industry, for example, production plants, power plants, etc. that use critical machines and multiple sensors and actuators. IoT or Industrial IoT (IIoT) makes it possible, for example, to precisely track production lines by implementing the following functions (non-exhaustive list): predictive maintenance (avoiding production interruptions by early identification of impending failures and proactively planning maintenance interventions), intelligent diagnostics (by recording operational data and repair history via sensors), optimization of production lines, optimization of production machines, etc.
[0004] With the development of 5G technology, a new generation of IoT is being developed that uses 5G as the access network. However, there is still a need to ensure that 5G networks are compatible with the time-sensitive applications implemented by IoT elements.
[0005] Therefore, accurate time synchronization is required within 5G networks. A challenging aspect of time synchronization in 5G systems is ensuring synchronization in the radio part (Radio Access Network (RAN)) of the 5G system, which involves resource sharing and random time for accessing the medium. The time synchronization process in the RAN is based on the transmission of a reference time by a base station (e.g., referred to as gNB in 5G) to user equipment (UE) devices to share a common time among all nodes in the same cell. Furthermore, to improve the accuracy of the time synchronization, path delay compensation can be performed. This path delay compensation attempts to compensate for the effect of signal propagation between the UE and the base station. Because the path delay is related to the UE-gNB distance, it will be different for each UE. Path delay compensation requires calculating the path delay between the UE and its associated gNB. The path delay calculation can be performed by various methods (e.g., timing advance, RTT-based) and is usually performed by the gNB. The obtained path delay value is then applied to the reference time to compensate for the effect of the path delay. This additional feature is only mandatory for certain scenarios with strict delay requirements. For example, the 3GPP® Consortium (RAN2 Group) has agreed that for the air interface (Uu) synchronization budget, the UE-UE synchronization budget can be ±145 ns to ±275 ns in a control-to-control scenario (machine-to-machine) and ±795 ns to ±845 ns in a power grid scenario. Furthermore, when the distance between the UE and the base station is short (e.g., less than 30 meters), the error introduced by the path delay can be considered negligible. It has been argued that path delay compensation is not mandatory in each situation (e.g., path or propagation delay compensation may be required in an indoor factory scenario but not for a power grid scenario). For example, 3GPP document R2-2006922 from Nokia suggests that a gNB (base station) should be able to enable and disable path delay compensation, but provides few details on how this can be achieved.
[0006] A time synchronization process based on the transmission of a reference time by the base station helps to ensure synchronization in the radio part of a 5G system, but it comes at a cost in terms of additional message exchanges, i.e., periodic transmission of the reference time from the base station to the UE and individual signals to estimate and carry the path delay, and in terms of additional processing for each node involved in the time synchronization process.
[0007] Therefore, it is desirable to provide improved time synchronization procedures and services between UEs and base stations (eg, in the RAN). Summary of the Invention
[0008] According to a first aspect of the present invention, there is provided a method for controlling time synchronization in a wireless network including a user equipment (UE) and a base station, comprising: determining a requirement for time synchronization between the UE and the base station; generating a time synchronization control message for controlling a time synchronization process between the UE and the base station based on the determined time synchronization requirement; transmitting the time synchronization control message to the base station; A method is provided that includes:
[0009] According to a second aspect of the present invention, there is provided a method for controlling time synchronization in a wireless network including a user equipment (UE) and a base station, the method comprising: determining a requirement for time synchronization between the UE and the base station; generating a time synchronization control message for controlling a time synchronization process between the UE and the base station based on the determined time synchronization requirement; and transmitting the time synchronization control message to the UE.
[0010] According to a third aspect of the present invention, there is provided a method for controlling time synchronization in a wireless network including a user equipment (UE) and a base station, comprising: receiving a time synchronization control message from the base station; Controlling a time synchronization process based on the received time synchronization control message; A method is provided which includes:
[0011] According to a fourth aspect of the present invention, there is provided a method for controlling time synchronization in a wireless network including a user equipment (UE) and a base station, the method comprising: receiving a time synchronization control message from the UE; and controlling a time synchronization process based on the received time synchronization control message, wherein the controlling of the time synchronization process includes: Enabling the time synchronization process in the base station; or Disabling the time synchronization process in the base station, or A method is provided that includes modifying the time synchronization process at the base station by enabling or disabling path delay compensation.
[0012] According to a fifth aspect of the present invention, there is provided a User Equipment (UE) for controlling time synchronization between the UE and a base station of a wireless network, as set out in claim 30 of the accompanying claims.
[0013] According to a sixth aspect of the present invention, there is provided a base station for controlling time synchronization between a UE and a base station of a wireless network, as set out in claim 31 of the accompanying claims.
[0014] According to a seventh aspect of the present invention, there is provided a time synchronization control message for controlling time synchronization between a UE and a base station of a wireless network, as set out in claim 32 of the accompanying claims.
[0015] A node in a radio access network receives a message that triggers the generation of a time synchronization control message, which includes a field that controls whether the time synchronization process is enabled or disabled. The node then transmits the message to control whether the time synchronization process is enabled or disabled.
[0016] Therefore, according to the present invention, signaling shall make it possible to enable and disable clock synchronization in the RAN (UE and gNB) only when necessary.
[0017] To optimize the use of resources in the RAN of a wireless network (such as a 5G network) (e.g., signaling between a UE and a base station and processing in the UE and the base station), embodiments of the present invention are configured to enable time synchronization in the RAN only when necessary and disable time synchronization at other times to reduce the amount of signaling and processing in the RAN. In some examples, path delay compensation (PDC) may also be enabled only when necessary and disabled at other times. By using PDC only when necessary, this can provide an additional reduction in the amount of signaling and processing in the RAN and also avoid problems where the error introduced by PDC can be higher than the error without PDC.
[0018] The claims refer to "activation," for example, with respect to time synchronization and PDC. The description also refers to "activation" in the description, and also refers to "startup" or "starting." It will be understood that these terms are intended to be equivalent and interchangeable. Similarly, the claims refer to "disablement," and the description also refers to "disablement," and also refers to "disabling" and "stopping." It will be understood that these terms are intended to be equivalent and interchangeable.
[0019] Further features of the invention are characterized by the other independent and dependent claims.
[0020] Any feature of one aspect of the invention may be applied to other aspects of the invention in any appropriate combination, in particular method aspects may be applied to apparatus / device / unit aspects and vice versa.
[0021] Furthermore, features implemented in hardware may be implemented in software and vice versa. Any references herein to software and hardware features should be construed accordingly. For example, according to another aspect of the present invention, there is provided a computer-readable storage medium storing at least one computer program comprising instructions that, when executed by a processing unit, cause the processing unit to perform a method according to any aspect or example described above.
[0022] It should also be understood that specific combinations of the various features described and defined in any aspect of the present invention may be implemented and / or provided and / or used independently. [Brief explanation of the drawings]
[0023] Various aspects of the present invention will now be described, by way of example only, with reference to the following drawings: [Figure 1] FIG. 1 is a block schematic diagram illustrating a 5G network interconnecting connected end devices. [Figure 2] FIG. 2 is a block schematic diagram illustrating an example structure of a base station of the illustrated 5G network of FIG. [Figure 3] FIG. 2 is a block schematic diagram showing an example structure of a user terminal of the 5G network illustrated in FIG. 1. [Figure 4a] FIG. 4a is a flow diagram of a method for controlling time synchronization in a wireless network according to a first aspect of the present invention. [Figure 4b] FIG. 4b is a flow diagram of a method for controlling time synchronization in a wireless network according to a second aspect of the present invention. [Figure 5a]FIG. 5a is a flow diagram of an example method performed by a UE when triggered by the establishment of a PDU session, according to one embodiment. [Figure 5b] FIG. 5b is a flow diagram of an example method performed by a UE when triggered by the release of a PDU session, according to one embodiment. [Figure 5c] FIG. 5c is a flow diagram of an example method performed by a UE when triggered by a PDU session change, according to one embodiment. [Figure 5d] FIG. 5d is a flow diagram of an example method performed by a UE when triggered by an SMF synchronization notification, according to one embodiment. [Figure 6a] FIG. 6a is a flow diagram of an exemplary method performed by a gNB when reference time information is transmitted in unicast mode, according to one embodiment. [Figure 6b] Figure 6b is a flow diagram of an exemplary method performed by a gNB when reference time information is transmitted in unicast mode and path delay is guaranteed by the gNB, according to one embodiment. [Figure 6c] Figure 6c is a flow diagram of an exemplary method performed by a gNB when reference time information is transmitted in broadcast mode, according to one embodiment. [Figure 7a] FIG. 7a is a flow diagram of an exemplary method performed by a gNB when triggered by the establishment of a PDU session, according to one embodiment. [Figure 7b] FIG. 7b is a flow diagram of an exemplary method performed by a gNB when triggered by the release of a PDU session, according to one embodiment. [Figure 7c] Figure 7c is a flow diagram of an exemplary method performed by a gNB when triggered by a PDU session change, according to one embodiment. [Figure 7d] Figure 7d is a flow diagram of an exemplary method performed by a gNB when triggered by an SMF synchronization notification, according to one embodiment. [Figure 8] FIG. 8 is a flow diagram of an exemplary method performed by a UE in response to a time synchronization control message received from a gNB, according to one embodiment. [Figure 9] Figure 9 is a schematic diagram illustrating the system frame of a 5G network. [Figure 10] FIG. 10 is a schematic diagram illustrating the message flow between the UE and the base station for updating the UE's time counter. [Figure 11] FIG. 11 is a schematic diagram illustrating an exemplary MAC CE signaling frame format used as a time synchronization control message according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION
[0024] Embodiments of the present invention are intended to be implemented in a wireless network, such as a fifth generation (5G) network, used to interconnect connected objects or terminals or end devices of a communication system 110 such as that shown in FIG.
[0025] The 5G network 100 includes multiple user equipments (UEs) 104a, 104b, also called mobile stations, that are wirelessly connected (as shown by the dashed lines) to at least one base station 102 (gNB or gNodeB). The gNB 102 is connected to a wired core network 101, for example, using optical fiber (e.g.,) or wirelessly. The gNB 102 is part of the Radio Access Network of the 5G network 100 and uses radio frequencies to provide wireless connectivity to the UEs 104a, 104b.
[0026] In this 5G network 100, a common time reference is provided by a Grand Master clock (5G-GM) 103, which is defined in section 5.27 of TS23.501.
[0027] The 5G GM clock 103 may be connected to the core network 101 as shown in Figure 1, but may also be connected directly to a gNB or to one or more UEs 104a, 104b, such that devices connecting with the 5G GM clock 103 share the common time reference provided by the 5G GM clock 103 with other devices in the network.
[0028] According to some embodiments, the common time reference provided by the 5G GM clock 103 may be or be based on a universal time reference, in which case the universal time reference may be obtained by the gNB 102 directly from a satellite system (not shown in FIG. 1).
[0029] As described above, the 5G network 100 may be used to connect end devices 105a, 105b, and 105c, e.g., connected devices of an IoT network. The end devices may be, for example, devices for industrial appliances, such as sensors and actuators. As can be seen in FIG. 1 , the end devices 105a, 105b, and 105c are connected to UEs 104a, 104b or to a core network 101 of the 5G network 100. The end devices 105b and 105c are connected to the UEs 104a, 104b through Device Side Time Sensitive Network (TSN) translators (DS-TT) 107b, 107c. The end device 105a is connected to the network core 101 of the 5G network 100 through a Network Side Time Sensitive Network (TSN) translator (NW-TT) 106. According to some embodiments, the end devices 105a, 105b, and 105c are wired connected to the DS-TT 107a, 107b or the NW-TT 106. According to some other embodiments, the end devices are directly connected to the UE and to the core network without using any translator device.
[0030] According to some embodiments, one end device and one UE may be integrated into one device.
[0031] In this manner, end devices 105a, 105b, and 105c share data using the 5G network. When implementing time-sensitive applications in IoT networks, accurate time synchronization between UEs is essential, especially within 5G networks. In other words, a Time Sensitive Network (TSN) that implements time-sensitive applications or services requires accurate time synchronization so that TSN nodes or elements have the same understanding of time and communication packets can be delivered within a time budget.
[0032] The internal architecture of a base station, such as the gNB 102 of FIG. 1, is shown in block schematic diagram form in FIG. 2.
[0033] The gNB 200 has a communication interface 205, such as a 5G New Radio (NR) interface 205, that allows it to communicate with the UEs 104a, 104b of the 5G network 100. The gNB may also have several different types of radio interfaces, such as LTE (4G) or other types of radio interfaces.
[0034] To communicate with the core network 101, the gNB also has a core network interface 204 as defined in section 4.2 of TS23.501.
[0035] Synchronization of the gNB with the 5G GM clock is handled by the 5G Time Synchronization Manager 203.
[0036] According to some embodiments, the 5G time synchronization manager 203 implements a time counter or timer (not shown) that is incremented by a local clock oscillator (not shown). The 5G time synchronization manager 203 continuously evaluates the clock difference between the time counter and the 5G GM clock. This evaluation may be performed using the IEEE 1588 Precise Time Synchronization Protocol, implemented through the exchange of time synchronization packets with the 5G GM via the core network interface 204. In this manner, the evaluated difference allows the 5G time synchronization manager 203 to determine a value by which to adjust its time counter.
[0037] According to some embodiments, the 5G time synchronization manager 203 continuously evaluates the clock misalignment between the time counter and a reference time received from a satellite system such as GPS.
[0038] In this way, the 5G time synchronization manager 203 provides the current time to the UE synchronization manager 201 based on its local time counter.
[0039] The UE synchronization manager 201 is configured to handle synchronization between the base stations of the 5G network 100 and the UEs 104a, 104b, with the aim of synchronizing the time counters of all of these devices as accurately as possible.
[0040] To that end, the UE synchronization manager 201 may implement one or more mechanisms, such as one or more of the mechanisms described below in connection with Figure 10. The UE synchronization manager 201 is also configured to estimate and record the propagation delay between the gNB and each UE 104a, 104b for synchronization purposes.
[0041] The gNB further comprises a control manager 202 in which the gNB control protocols are implemented. The control protocols include at least the following protocols: RLC (Radio Link Control, TS38.322), PDCP (Packet Duplication Control Protocol, TS38.323), RRC (Radio Resources Control, TS38.331), and NAS (Network Access Stratum, TS24.501). Thus, the control manager 202 handles the generation of protocol packets that are exchanged with the core network 101 and the UEs via the core network interface 204 and 5G NR interface 205, respectively.
[0042] The elements of the gNB 200 described above may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored or transmitted as one or more instructions or code via a computer-readable medium and executed by a hardware-based processing unit. The processing unit (not shown) may be a single processor or may include two or more processors that perform the processing necessary for the operation of the gNB 200. The number of processors and the allocation of processing functions to the processing units are design choices for those skilled in the art.
[0043] The internal architecture of a UE, such as the UEs 104a, 104b of FIG. 1, is shown in FIG. 3 using a block schematic diagram.
[0044] The UE 300 has a communication interface 305, such as a 5G NR interface 305, through which the UE 300 can communicate with the gNB 200, 102. The UE 300 may have several different types of radio interfaces, such as LTE (4G) or other types of radio interfaces.
[0045] Synchronization of the UE with the 5G GM clock is handled by the 5G Time Synchronization Manager 303.
[0046] According to some embodiments, the 5G time synchronization manager 303 implements a time counter or timer (not shown) that is incremented by a local clock oscillator (not shown). The 5G time synchronization manager 303 may correct or change the time counter when it receives a time counter calibration from the gNB synchronization manager 301 via the 5G NR interface 305.
[0047] Indeed, the gNB synchronization manager 301 stores the parameters required for synchronization provided by the gNB 102 and determined by the UE synchronization manager 201 of the gNB 102. Furthermore, the gNB synchronization manager 301 is also configured to estimate and record the propagation delay between the UE 300 and the gNB 102.
[0048] A register in the UE 300 (which may be part of the gNB synchronization manager 301 or the 5G time synchronization manager 303) may have a RAN synchronization flag or field to indicate the current state of time synchronization in the UE 300 (i.e., RAN synchronization state). It may also have a RAN PDC flag or field to indicate the current state of PDC in the UE 300 (i.e., PDC state). When the RAN synchronization flag is set to "on", this corresponds to the RAN synchronization state in the UE 300 when the time synchronization process is operational and the UE is performing an operation according to the enabled time synchronization process (e.g., acquiring a reference time). When the RAN synchronization flag is set to "off", this corresponds to the RAN synchronization state in the UE 300 when the time synchronization process is inactive (i.e., disabled) and not used in the UE 300. When the RAN PDC flag is set to "on", this corresponds to the PDC state in the UE 300 when the PDC is operational and the UE is performing an operation for PDC (e.g., acquiring PDC information and calculating a path delay value). When the RAN PDC flag is set to "off", this corresponds to the PDC state in the UE 300 when the PDC is inactive (disabled) and not in use in the UE 300. The 5G time synchronization manager 303 in the UE 300 may set the RAN synchronization flag and the RAN PDC flag in the registers. As will be described below, each time a time synchronization control message is sent to change the time synchronization and / or PDC state, the 5GS time synchronization manager 303 changes the state (RAN PDC state and / or RAN synchronization state) in the UE accordingly.
[0049] The UE 300 further comprises a control manager 302 in which the gNB control protocols are implemented, including at least the following protocols: RLC (Radio Link Control, TS38.322), PDCP (Packet Duplication Control Protocol, TS38.323), RRC (Radio Resources Control, TS38.331), and NAS (Network Access Stratum, TS24.501). The control manager 302 handles the generation of protocol packets that are exchanged with the gNB 200, 102 via the 5G NR interface 305.
[0050] The elements of the UE 300 described above may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over a computer-readable medium as one or more instructions or code and executed by a hardware-based processing unit. The processing unit (not shown) may be a single processor or may have two or more processors that perform the processing necessary for the operation of the UE 300. The number of processors and the allocation of processing functions to the processing units are design matters for those skilled in the art.
[0051] Data exchanged between the gNB and the UE of the network 100 via the 5G NR interfaces 205, 305 conforms to the frame format specified by the 3GPP NR PHY and MAC protocols, as defined in clauses 5 and 6 of TS38.300.
[0052] The exchanged frames, hereafter referred to as system frames, are organized in time and have a structure as shown in FIG.
[0053] The system frames follow one another in time, each having a duration of 10 ms.
[0054] System frames may be numbered using a system frame number (SFN), also called a system frame index. As can be seen in Figure 9, the first system frame numbered #0 is followed by system frames #1, #2, and #3. As shown in Figure 9, the numbering of system frames may be done incrementally. In other words, every 10 ms, the system frame number is incremented, going from 0 to 1023, at which point the numbering starts again at 0.
[0055] Thus, the gNB numbers the system frames using the SFN, which is signaled to the UE using a System Frame Synchronization Signal, which is periodically transmitted from the gNB to the UE by signaling the most significant 6 bits of the so-called Master Information Block (MIB) field in the transmitted system frame and the restart 4 bits of the so-called PBCH field in the transmitted system frame.
[0056] Each system frame consists of 10 subframes ranging from 0 to 9.
[0057] Each subframe has a flexible number of slots, for example up to 64 slots, each of which contains several Orthogonal Frequency Division Multiplexing (OFDM) slots, resulting in a maximum of 14 OFDM slots.
[0058] In this way, the system frame constitutes a common reference for the UE and the gNB, and the system frame of a particular SFN is therefore used for conventional adjustment of the time counter of a UE (such as UE 300).
[0059] A conventional adjustment of a time counter of a UE (such as UE 300) is shown in FIG.
[0060] Conventional time counter adjustment involves sending a reference time value (T R ) The reference time value corresponds to the transmission time of the system frame used as a reference.
[0061] After receiving a request from the UE for a reference time value for updating the time counter, or on its own initiative, the gNB selects a future reference system frame during which the gNB forces the UE to update its time counter with the reference time value provided by the gNB.
[0062] The reference time value may be, for example, the intended start or end time of transmission of the reference system frame by the gNB.
[0063] According to some embodiments, the reference time value is a planned or intended value of a time counter of the gNB that corresponds to the intended start or end transmission time of a reference system frame by the gNB.
[0064] As can be seen in FIG. 10, the reference time is - The current time of the gNB's time counter, which is continuously synchronized with the 5G GM clock thanks to the Synchronization Manager 203, - a period T representing the delay (in time counter units) that the gNB waits before transmitting a reference system frame to the UE; is equal to the sum of
[0065] According to some embodiments, the reference time may be, for example: - Current time of the gNB's time counter synchronized to the 5G Grand Master clock thanks to the Synchronization Manager 203; - the remaining time before the start of the next system frame. Since a new system frame occurs every 10 ms, the remaining time can be obtained using an alarm counter set to 10 ms for each system frame start; and - 10ms * (referenceSFN-nextSFN), where referenceSFN is the SFN of the specified reference system frame and nextSFN is the SFN of the next system frame. Note that referenceSFN can be nextSFN. In this case, the reference time is calculated just before the transmission of the reference system frame and is included in the reference system frame, which is the case when SIB9 messages are used. Usually, referenceSFN refers to a future reference system frame, i.e., referenceSFN-nextSFN>0. It can be determined by the gNB as the sum of
[0066] And the reference time T R and an indication of the reference system frame number, e.g., referenceSFN, is provided to the UE. Both of these elements may be transmitted together or separately.
[0067] According to some embodiments, the gNB may R An information element (referenceTimeInfo IE) including the referenceSFN and the referenceSFN is prepared. The referenceTimeInfo IE is then encapsulated in a System Information (SI) or Radio Resource Control (RRC) message such as an SIB9 or DLInformationTransfer message.
[0068] The DLInformationTransfer message is sent prior to the reference system frame, as shown in FIG.
[0069] The SIB9 type reference system frame is a reference time T R Therefore, no other messages related to the reference system frame are transmitted first by the gNB.
[0070] Therefore, as shown in Figure 10, when a message with reference time information is broadcast, the gNB transmits the message to the requesting UE or UEs.
[0071] When the DLInformationTransfer message is sent, a reference system frame is later generated by the gNB when its time counter is equal to the reference time, and the reference system frame is sent to the UE (or multiple UEs if the reference time information is broadcast).
[0072] When the UE detects the reference system frame based on the referenceSFN, the UE (its managers 301 and 302) that previously received the reference time (or obtains the reference time from the SIB9 reference system frame) sets its time counter to the reference time.
[0073] In the particular case of SIB9, the reference time corresponds to the ending boundary of the system frame.
[0074] However, there is a delay between the moment the gNB transmits the reference system frame and the moment the UE receives it, as shown by the timing difference labeled "Error" in Figure 10. This delay, also called propagation delay or path delay, represents the time of propagation of the radio signal between the UE and the gNB.
[0075] Therefore, the above synchronization mechanism is based on the assumption that the propagation delay of the reference system frame used as a trigger for the UE to set its local time counter to the reference time provided by the gNB can be ignored.
[0076] It can be seen that when the UE sets its time counter using the reference time provided by the gNB, a persistent synchronization error occurs due to the propagation delay. This may not be compatible with some applications (e.g., time-sensitive applications), especially those that require accurate timestamps of the arrival or departure times of some packets. Indeed, the persistent synchronization error due to the propagation delay may result in errors in the timestamps of those packets, which may not meet the requirements of time-sensitive applications.
[0077] To overcome this disadvantage, one of many different path or propagation delay compensation (PDC) processes, mechanisms, or procedures may be used to correct or compensate for this error in adjusting the UE's conventional time counter. One example of a PDC process includes the Timing Advance mechanism defined in TS 38.211, section 4.3.1. Another example is the Round Trip Time (RTT) approach.
[0078] A Timing Advance (TA) mechanism may be used to allow the UE to calculate the propagation delay, as shown in FIG.
[0079] Essentially, the TA mechanism is used by the gNB to control the timing of the UE's uplink frames. To do so, the gNB provides the UE with a TA command, which contains several parameters. These parameters, including the TA parameter, determine the time T before the next gNB downlink frame at which the UE should start transmitting its uplink frame. TA This allows the determination of
[0080] The TA command is provided by the gNB to the UE over the 5G NR interface. For its transmission, the TA command is encapsulated in various types of Protocol Data Units (PDUs), among the following types, all defined in TS38.321: - a Random Access Response MAC Protocol Data Unit (PDU), as defined in TS 38.321 clauses 6.1.5, 6.2.3, and 6.2.3a; and - Absolute Timing Advance Command MAC Control Element or Timing Advance Command MAC Control Element as defined in TS 38.321 clauses 6.1.3.4 and 6.1.3.4a.
[0081] Depending on the type of TA command, the parameters provided are of different nature: In the case of a Random-Access Response and an Absolute Timing Advance Command, the absolute value of the parameter TA is provided; in the case of a Timing Advance Command, only the modification of the previously provided TA is included in the TA command.
[0082] Thus, according to some embodiments, the TA command is then given by the instant T TA The UE may include an absolute value of the TA in the TA command field, which is used to determine: T TA =(N TA +N TA,offset )×T C , where: N TA =TA×16×64 / 2 μ , and μ is the subcarrier spacing setting Δf = 2μ × 15kHz defined in Table 4.2-1 of Section 4.2 of TS38.211, N TA,offset is a fixed offset used to calculate the timing advance, T C is the base time unit for New Radio defined in Section 4.1 of TS38.211.
[0083] According to another embodiment defined in TS38.213, section 4.2, the TA command is executed with the previously provided TA value (TA previous ) of TA correction In this case, the previous T TA The adjustment to be applied to (TA correction -31)×16×64 / 2 μ is equal to.
[0084] Therefore, to control the UE's uplink timing, the gNB sends a TA command to the UE in a control message in the network. The TA command is specific to a given UE, as it reflects the propagation delay of that UE. The UE then determines the T TA Calculate.
[0085] Interestingly, the parameter N TA It can be seen that N is proportional to the round trip time between the gNB and the UE. TA can help determine the propagation delay, assuming that the propagation delay is symmetric. For example, the propagation delay between the UE and the gNB is (N TA ×T C ) / 2.
[0086] In this way, when the UE receives the TA command, it may be able to determine the propagation delay during transmission of the TA command, and the calculated propagation value may be used in adjusting the time counter as described above with the reference time and reference system frame transmitted by the gNB.
[0087] As can be seen in Figure 10, a first TA command is received from the gNB and used by the UE to calculate the propagation delay. Then, when the reference system frame is detected, the time counter is adjusted to the reference time T using the calculated propagation delay. R For example, if the time counter is set using T R It is set to a value corresponding to the plus propagation delay.
[0088] As can be seen from the above discussion, to ensure accurate time synchronization for time-sensitive communications (TSC), a time synchronization process based on periodic transmission of a reference time from a gNB to a UE is used in communication networks implementing time-sensitive applications, including, for example, a wireless network as an access network (such as the 5G network 100 described above with reference to FIG. 1). To improve the accuracy of the time synchronization process, path delay compensation (PDC) may be performed based on a dedicated signal exchange between the UE and the gNB to estimate and communicate path delay values. Thus, the time synchronization process and PDC require radio and processing resources in the RAN of the 5G network.
[0089] As mentioned above, path delay compensation (PDC) requires the calculation of the path delay between a UE and its associated gNB. The path delay is related to the UE-gNB distance and is therefore different for each UE. The path delay calculation can be performed according to various methods (e.g., timing advance, RTT-based) and is usually performed by the gNB. The obtained path delay value is then applied to the reference time to compensate for the effect of the path delay. The path delay value may be applied by the gNB, i.e., the reference time is modified with the path delay value before transmitting the reference time to the UE. In this case, the modification of the reference time by the gNB is called pre-compensation. Otherwise, the path delay value is transmitted individually to each UE and applied by the UE. For the pre-compensation case, the reference time is potentially different for each UE and is therefore transmitted in a unicast message. When the UE applies the path delay, the reference time is the same for all UEs in the cell and can be transmitted in a broadcast or multicast message. For example, in some implementations of wireless networks where the UE and gNB are separated by a short distance (such as less than 30 meters), using PDC may not be required, and in fact may be undesirable, and for example, the error caused by PDC may be higher than the error without PDC.
[0090] To optimize resource usage (e.g., signaling between UEs and base stations and processing therein) in a RAN of a wireless network (such as the 5G network 100 described above with reference to FIG. 1), embodiments of the present invention are configured to enable time synchronization in the RAN only when necessary and disable time synchronization at other times to reduce the amount of signaling and processing in the RAN. In some examples, path delay compensation (PDC) may be enabled only when necessary and disabled at other times. By using PDC only when necessary, this can provide an additional reduction in the amount of signaling and processing in the RAN and also avoid problems where errors due to PDC can be higher than errors without PDC.
[0091] 4a illustrates steps of a method 400 for controlling time synchronization in a wireless network (such as the 5G network 100 described above with reference to FIG. 1) including a UE and a base station. The method 400 may be performed in a UE (such as the UEs 104a, 104b, 300 described above) or in a base station (such as the base stations 102, 200 described above). For example, for a UE, a gNB synchronization manager 301 in the UE may perform the method 400. For a base station or a gNB, a UE synchronization manager 201 may perform the method 400.
[0092] Briefly, the method 400 includes, in step 402, determining a time synchronization request between the UE 104a, 104b, 300 and the base station 102, 200. In step 404, a time synchronization control message for controlling a time synchronization process or service between the UE and the base station (e.g., for controlling time synchronization in a RAN including the UE and the base station) is generated based on the determination in step 402. The time synchronization control message may include information for controlling enabling of the time synchronization process, information for controlling disabling of the time synchronization process, or information for changing or modifying the time synchronization process when the time synchronization is in an operational state (e.g., changing or modifying options or additional features of the time synchronization process). The options or additional features may include path delay compensation (PDC) of the time synchronization process, whereby changing the time synchronization process may include enabling or activating PDC or disabling or deactivating PDC. The options or additional features may also include various types or procedures of PDC (e.g., TA, RTT, advance compensation, etc., some of which are described above). Thus, the time synchronization control message may include information for controlling activation of a time synchronization process with a specific type of PDC, such that the time synchronization process is activated or activated with a specific type of PDC (e.g., TA, RTT, pre-compensation, etc.), or for modifying the time synchronization process to use a different type of PDC. Also, the options or additional features may include one or more of: different types of transport messages for transferring reference time information; different periodicities for transmission of reference time information by the base station; and different periodicities for transmission of PDC information by the base station. Thus, the time synchronization control message may include information for controlling activation of a time synchronization process with one or more features of the time synchronization process, and, if a PDC is required, information for controlling activation of a PDC with one or more specific features for the PDC.If the time synchronization process is already in an operational state, the time synchronization control message may include information for modifying the time synchronization process to use different functions for the time synchronization process, and / or for enabling or disabling a PDC with specific PDC functions, or for deactivating a PDC, and / or for modifying a PDC to use different functions for the PDC when the PDC is already in an operational state. In step 406, the time synchronization control message is transmitted to a base station (if method 400 is performed in a UE) or to the UE (if the method is performed in a base station). Also, if the method is performed in a UE, the UE may enable, disable, or modify the time synchronization process in the UE in response to determining a request for time synchronization. Also, if the method is performed in a base station, the base station may enable, disable, or modify the time synchronization process in the base station in response to determining a request for time synchronization.
[0093] The time synchronization process is based on the base station transmitting a reference time to the UE (and potentially other UEs or other nodes in the RAN) to achieve time synchronization between the UE (and potentially other UEs or other nodes in the RAN) and the base station (e.g., gNB) when the base station and the UE share a common time or have the same understanding of time. Options or additional features of the time synchronization process, such as path delay compensation, may be enabled or operational for use in the time synchronization process, or may be disabled or inactive and unused based on a time synchronization request. When the time synchronization process is activated or operational or enabled in the base station, the base station (e.g., periodically) transmits reference time information to the UE (e.g., in an RRC or SIB9 message) to synchronize time at the UE and the base station. In one example, if path delay compensation is also required to improve the accuracy of the time synchronization process, the base station may also transmit path delay compensation (PDC) information. When the time synchronization process is disabled or inactive in the base station, the base station does not transmit reference time information to the UE, thereby reducing the amount of signaling between the base station and the UE and the amount of processing in the UE and the base station. Similarly, when the PDC process is disabled or inactive in the base station, the base station does not transmit PDC information to the UE, thereby reducing the amount of signaling between the base station and the UE and the amount of processing in the UE and the base station. When the time synchronization process is activated or active or enabled in the UE, the UE operates to obtain reference time information transmitted from the base station, process the received reference time information, and update the time counter of the UE. In one example, when path delay compensation is also required to improve the accuracy of the time synchronization process, the UE may operate to obtain path delay compensation (PDC) information transmitted from the base station, process the received PDC information, and update the time counter of the UE to compensate for the path or propagation delay. When the time synchronization process is disabled or inactive in the UE, the UE does not perform the operation of obtaining and processing the reference time information sent from the base station, thereby reducing the amount of signaling between the base station and the UE, and also the amount of processing in the UE and the base station.Similarly, when the PDC is disabled or inactive in the UE, the UE does not perform an operation to obtain and process PDC information from the base station, thereby reducing the amount of signaling between the base station and the UE and the amount of processing in the UE and the base station. Therefore, by controlling the time synchronization process in the UE and the base station based on the determined time synchronization requirement, accurate time synchronization can be achieved when needed, while ensuring that radio resources and processing resources are used only when needed, rather than continuously. This can help reduce the amount of radio resources and processing resources needed in the RAN to achieve accurate time synchronization.
[0094] 4a, the method 400 may further include receiving a message for triggering generation and / or transmission of a time synchronization control message in step 408. And, the determining in step 402 may include determining a request for time synchronization between the UE and the base station based on the received message. In one example, the message may be received from a core network entity of the wireless network.
[0095] The message may include a duration value corresponding to the duration for which the time synchronization process will be operational. In response to receiving the message, the UE or gNB may send a time synchronization control message to enable the time synchronization process, and then, upon expiration of the duration, send a time synchronization control message to disable the time synchronization process. This means that the UE or gNB can automatically disable the time synchronization process without requiring a further message from the core network entity to disable the time synchronization process.
[0096] The message from the core network entity may include information to indicate a request for time synchronization in the RAN (i.e., between the UE and the base station).
[0097] For example, the message may be a synchronization notification sent from a Session Management Function (SMF) of a core network of a wireless network (such as core network 101 of 5G network 100 in FIG. 1). If method 400 is performed in a UE, the synchronization notification may include information or a command (such as Port Management Information Container (PMIC) information) to enable or disable a Device Side TSN translator (DS-TT) function (such as DS-TT 107b, 107c in FIG. 1). If the command is to enable DS-TT, the UE determines that time synchronization is required. In this case, the time synchronization process may be activated or enabled. If the command is to disable DS-TT, the UE determines that time synchronization is not required. In this case, the time synchronization process may be deactivated or disabled. If method 400 is performed in a base station, the message may be a synchronization notification including an information element (IE), such as an AN_Synchronization_Notification IE, described below with reference to FIG. 7d, to indicate a request for time synchronization between the UE and the base station. For example, a first information element indicates the identity of the UE (or all UEs in the base station's cell, if appropriate) to be configured, a second information element indicates whether time synchronization processing should be enabled or disabled, and a third information element indicates whether path delay compensation should be enabled or disabled.
[0098] In another example, the message sent from a core network entity such as an SMF may be a message associated with a Packet Data Unit (PDU) session between the UE and the base station, and may include one or more of: QoS information for indicating the Quality of Service (QoS) required for the PDU session; or session identity information for indicating whether the PDU session is a PDU session for Time Sensitive Communication (TSC) for a Time Sensitive Network (TSN) application; or Single-Network Slice Selection Assistance Information (S-NSSAI) for indicating whether the PDU session is linked to a network slice for TSC. For example, as described in more detail below with reference to Figures 5a-5c and 7a-7c, the message may be a PDU SESSION ESTABLISHMENT ACCEPT message or a PDU SESSION MODIFICATION COMMAND message when received at the UE, or a PDU SESSION RESOURCE SETUP message or a PDU SESSION RELEASE REQUEST message or a PDU SESSION RESOURCE MODIFY REQUEST message when received at the gNB. The QoS information may include QoS flow description information, such as a 5QI value (described in more detail below), which indicates a guaranteed bit rate (GBR) and a packet delay budget that defines the maximum time a packet will spend in the network between the UE and the N6 termination point in the UPF (5.7.3.4 of TS23.501). Furthermore, to derive the packet delay budget to be applied to the air interface (between the UE and the gNB), the fixed delay for the delay between the UPF terminating N6 and the 5G-AN (gNB) should be subtracted from the given packet delay budget (PDB). Some examples of fixed delays are given in the notes associated with Table 5.7.4-1 of TS 23.501.If the QoS information indicates that the PDU session requires a QoS that meets a predetermined time delay criterion or threshold, such as having a delay-critical guaranteed bit rate (GBR), the PDU session may be detected as being for a TSC that requires time synchronization. If the QoS information indicates that the PDU session requires a QoS that meets a second (stricter) time delay criterion or threshold, such as having a delay-critical guaranteed bit rate (GBR) with a very short or low packet delay budget, or a very short or low (e.g., very short or low may be less than 10 ms or less than 5 ms) packet delay budget that applies to the radio interface between the UE and the gNB, the PDU session may be detected as being for a TSC that requires time synchronization and PDC. The session identity information may include a session identity or identifier that is associated with the PDU session once it is determined that the PDU session is for a TSC.
[0099] In another example (not shown in FIG. 4a), the method may further include detecting a Packet Data Unit (PDU) session for Time Sensitive Communication (TSC) for a Time Sensitive Network (TSN) application. And, determining in step 402 may include determining a request for time synchronization based on the time synchronization request of the detected PDU session for the TSC. In another example, the method may include detecting a Packet Data Unit (PDU) session for Time Sensitive Communication (TSC) and determining a change to the PDU session for the TSC. Determining in step 402 may include determining that the request for time synchronization includes determining a change to the time synchronization request based on the change to the PDU session for the TSC. In both of these examples, detecting a PDU for the TSC may include determining a required Quality of Service (QoS) for the PDU session and detecting a PDU session for the TSC if the requested Quality of Service meets a predetermined time delay criterion (e.g., as described above), or determining session identity information associated with the PDU session and detecting a PDU session for the TSC if the session identity information indicates that the PDU session is for the TSC (e.g., as discussed above with respect to session identity or identifier).
[0100] In one example, the time synchronization control message includes at least one field for controlling the time synchronization process. For example, the time synchronization control message may include a first field for indicating whether the time synchronization process is active or inactive (or enabled or disabled) and a second field for indicating whether the path delay compensation process is active or inactive (or enabled or disabled). In one example, the time synchronization control message is a MAC Control Element (MAC CE) having a Time Synchronization field or flag (e.g., bit 8) indicating whether the time synchronization process is active or inactive and a Path Delay Compensation (PDC) field or flag (e.g., bit 7) indicating whether the path delay compensation process is active or inactive. In another example (in which the UE transmits the time synchronization control message), the time synchronization control message is an RRC message, such as a UE Assistance Information message, with an Information Element (IE) for providing information for controlling the time synchronization process, such as time synchronization and PDC configuration and activation information. The IE of the UE Assistance Information message may include a refTime-activation field indicating whether time synchronization processing is activated or deactivated and a pdc-Activation field indicating whether path delay compensation is activated or deactivated. In another example, the time synchronization control message may be an RRC reconfiguration message. The RRC reconfiguration message may include a RAN_synchronization field indicating whether time synchronization processing is activated or deactivated and a RAN_pdc field indicating whether PDC is activated or deactivated.A time synchronization control message sent by a UE (whether it is a MAC CE message or an RRC message such as a UE AssistanceInformation message or an RRC reconfiguration message) may include one or more additional fields, each having one or more additional fields indicating the preferences / configuration of the particular UE for time synchronization. For example: an additional field may indicate a preferred (unicast or broadcast) type of transport message for transferring reference time information from the gNB to the UE; an additional field may indicate a required or preferred periodicity for the transmission of the reference time by the gNB (e.g., a value in ms or only once); an additional field may indicate a type of PDC supported by the UE (pre-compensated, RTT, TA, extended TA, etc.); an additional field may indicate a periodicity for the transmission of PDC information by the gNB (e.g., a value in ms or on-demand); an additional field may indicate a scenario or environment in which the UE is operating, such as a control-control scenario or a power grid scenario or other operating scenario in which the UE is used; an additional field may indicate whether the UE should follow a timing error (Te-preference); an additional field may indicate a preferred TA granularity value (value of the step of TA correction); etc. A time synchronization control message transmitted by a gNB (whether it is a MAC CE message or an RRC message) may include one or more additional fields, each having one or more additional fields indicating a specific configuration for time synchronization. For example: An additional field may indicate the type of PDC used by the gNB for time synchronization processing (pre-compensation, RTT, TA, extended TA, etc.). Details of example time synchronization control messages are provided below.
[0101] 4b illustrates steps of a method 420 for controlling time synchronization in a wireless network (such as the 5G network 100 described above with reference to FIG. 1) including a UE and a base station. The method 420 may be performed by a UE (such as the UEs 104a, 104b, 300 described above) or in a base station (such as the base stations 102, 200 described above). For a UE, for example, a gNB synchronization manager 301 of the UE may perform the method 420. For a base station or a gNB, the UE synchronization manager 201 may perform the method 420.
[0102] Briefly, in step 422, a time synchronization control message is received. Then, in step 424, a time synchronization process is controlled according to the received time synchronization control message. When method 420 is performed in a UE, the UE receives the time synchronization control message from a base station, and the UE controls the time synchronization process in the UE according to the received time synchronization control message. When method 420 is performed in a base station, the base station receives the time synchronization control message from the UE, and the base station controls the time synchronization process in the base station according to the received time synchronization control message. Controlling the time synchronization process in the UE or the base station may include activating or deactivating (or enabling or disabling) the time synchronization process in the UE or the base station, respectively, and may also include modifying the time synchronization process (e.g., changing options or additional features of the time synchronization process), such as activating or deactivating path delay compensation (PDC) in the UE and the base station, respectively, if the time synchronization process is already active. In this way, time synchronization in the RAN is activated or enabled only when necessary and deactivated or disabled otherwise, which helps reduce the amount of signaling and processing in the RAN.
[0103] As mentioned above, according to an embodiment of the present invention, the time synchronization control message can be transmitted from the UE to the base station (e.g., gNB) or from the base station (e.g., gNB) to the UE. Further details of the present invention are provided below.
[0104] In a first embodiment, a UE (e.g., UE 104a, 104b in FIG. 1, UE 300 in FIG. 3—for simplicity, the reference numeral 300 will be used for the UE hereinafter) determines a request for time synchronization between the UE and a base station (e.g., gNB 102 in FIG. 1 and gNB 200 in FIG. 2—for simplicity, the reference numeral 200 will be used for the base station or the gNB hereinafter) and generates a time synchronization control message accordingly. For example, the UE 300 determines whether time synchronization is required or whether a change to an already-operating time synchronization process (e.g., activation or deactivation of PDC) is required. The UE 300 may receive a message that triggers the generation of the time synchronization control message. The time synchronization control message includes information for controlling the time synchronization process, such as activation or deactivation of the time synchronization process, or for changing the operating time synchronization process (e.g., changing options or additional features of the time synchronization process), such as activation or deactivation of path delay compensation. For example, this time synchronization control message may include a field for controlling activation / deactivation of a time synchronization process in the gNB 200. The time synchronization process is based on the transmission of a reference time by the gNB 200 to the UE 300 in order to share a common time among all nodes in the same cell. Furthermore, path delay compensation may be performed to improve the accuracy of the time synchronization.
[0105] In one example, determining the request for time synchronization between UE300 and gNB200 may be based on detecting a Packet Data Unit (PDU) session for Time Sensitive Communication (TSC) for TSN applications and determining a request for time synchronization for the PDU session for TSC (e.g., during a PDU session establishment sequence), or may be based on detecting a Packet Data Unit (PDU) session for Time Sensitive Communication (TSC) for TSN applications and determining a change to the TSC PDU session, such as during a PDU session release procedure or a PDU session modification procedure.
[0106] Reference is now made to FIG. 5a, which illustrates a flow diagram of an exemplary method according to an embodiment of the present invention, executed in a UE 300, triggered by the establishment of a PDU session.
[0107] First, in step 501a, the UE 300 requests the establishment of a PDU session as described in section 6.4.1 of TS24.501. The PDU SESSION ESTABLISHMENT REQUEST is sent from a core network entity, such as a Session Management Function (SMF), that is part of a core network (such as the 5G core network 101 of FIG. 1). This PDU SESSION ESTABLISHMENT REQUEST message contains all the information necessary to establish a PDU session. In step 502a, a determination is made as to whether this PDU session has some specific time synchronization requirements in terms of time synchronization (i.e., whether time synchronization is required or not, and, if time synchronization is required or not, whether PDC is used or not). For example, in step 502a, a determination is made as to whether a Packet Data Unit (PDU) session for Time Sensitive Communication (TSC) has been detected. In the context of a Time Sensitive Network application, a 5G system is aggregated with a TSN system as a TSN bridge. Several specific entities, namely, DS-TT (Device Side TSN Translator 107b, 107c) and NW-TT (Network Side TSN Translator 106), are responsible for translation between the TSN domain and the 5G domain. The DS-TT is associated with a UE specific to a TSN application (e.g., attached to or embedded in the UE 300), and the NW-TT is attached to a User Plane Function (UPF) in the core network. The presence of the DS-TT in the UE 300 is related to Time Sensitive Communication (TSC), and therefore, it can be inferred that there is a need for time synchronization for the TSC. To configure the DS-TT, the 5G core network uses a Port Management Information message, which is a control message containing information for configuring the DS-TT.Therefore, if a DS-TT is linked to UE 300, the PDU SESSION ESTABLISHMENT REQUEST message includes DS-TT parameters: that is, the TPMIC (Transfer of Port Management Information Containers, clause 9.11.4.12 of TS24.501) bit is set in the 5GSM Capability Information Element and the Port Management Information Container (9.11.4.27) is located. Therefore, if the PDU SESSION ESTABLISHMENT REQUEST includes DS-TT parameters, the RAN will also require time synchronization. In other words, in an exemplary implementation, if UE 300 is linked or associated with a DS-TT, when requesting establishment of a PDU session, UE 300 includes the DS-TT parameters in the PDU SESSION ESTABLISHMENT REQUEST message to detect that the requested PDU session is for a TSC and therefore time synchronization between UE 300 and gNB 200 in the RAN is required.
[0108] The PDU SESSION ESTABLISHMENT REQUEST also includes a PDU session identity or identifier used to identify the PDU session. This PDU session ID is present in all messages for controlling the PDU session. If the PDU session is classified using the need for time synchronization during step 502a, the UE 300 also associates the PDU session identity with the need for time synchronization. As a result, in the following PDU session procedures, the UE can know whether the session is classified using the need for time synchronization based solely on the PDU session identity.
[0109] Otherwise, if time synchronization is not required (no branch in step 502a), the UE proceeds to end step 508a. In this case, because it was determined in step 502a that the PDU session does not require time synchronization, it is assumed that time synchronization is not in an operational state and has not been previously activated because the messages sent as part of the PDU session establishment procedure are some of the first messages that can exchange data between UE300 and gNB200. In another example, if time synchronization processing is enabled by default in the RAN and is therefore in an operational state when the determination in step 502 is made, UE300 may generate and send a time synchronization control message to gNB200 to inform the gNB that the UE does not require time synchronization and that time synchronization processing may be deactivated or disabled.
[0110] When UE300 determines its need for time synchronization, it shall notify the gNB200 of the time synchronization request, so that the gNB200 can configure and activate the time synchronization. Thus, when requesting the establishment of a PDU session, which is determined to require or require time synchronization during step 502a (yes branch in step 502a), UE300 creates or generates a time synchronization control message in step 503a. After creating or generating the time synchronization control message (step 503a), UE300 waits for core network feedback on the establishment of the PDU session in order to determine whether the establishment of the PDU session is accepted (step 504a). In response to receiving a PDU SESSION ESTABLISHMENT ACCEPT message from the core network SMF (yes for step 504a), UE300 sends a time synchronization control message to its associated gNB200 during step 506a and activates the time synchronization process during step 507a.
[0111] In other words, during step 507a, the UE 300 sets the RAN synchronization and RAN PDC states to "on" (e.g., as described above, the 5G time synchronization manager 303 sets the RAN synchronization flag and the RAN PDC flag in the UE's register to "on") and tracks the reception of messages related to the reference time and possibly path delay compensation from the gNB. Otherwise, in response to receiving a PDU SESSION ESTABLISHMENT REJECT (no branch in step 504a), the UE 300 deletes the time synchronization control message (step 505a) and terminates the method (step 508a).
[0112] In another example implementation, the UE 300 may use the QoS parameters included in the PDU SESSION ESTABLISHMENT ACCEPT message to determine in step 502a whether the PDU session has some specific requirements in terms of time synchronization (i.e., whether it requests or needs time synchronization). For example, the determination may be made whether a Packet Data Unit (PDU) session for Time Sensitive Communication (TSC) has been detected. The UE analyzes the QoS flow description information element (9.11.4.12.1 of TS24.501) included in the PDU SESSION ESTABLISHMENT ACCEPT to check the 5QI parameter. For example, if the 5QI value corresponds to a delay-critical GBR (#82, #83, #84, #85) or other value (new 5QI value) that indicates the need for time synchronization, the UE 300 determines that there is a request or need for time synchronization (e.g., the PDU session is for TSC), determines the request for time synchronization, and sends the Radio Access A time synchronization control message is prepared to request the activation of time synchronization processing in the RAN (Routing Area Network). The need for time synchronization can be determined if a PDU session is accepted using QoS parameters 5QI #82, #83, #84, or #85. The mapping of standardized 5QIs to QoS characteristics is described in Table 5.7.4-1 of 3GPP Technical Standard TS23.501. The smart grid scenario defined in the 3GPP Consortium (RAN2 Group) is similar to power distribution (5QI #85), and the control-control is similar to the individual automation defined in the delay-critical GBR 5QI (5QI #82 or #83). One of the most important QoS characteristics for time-sensitive communication is the packet delay budget, which defines the maximum time a packet spends in the network between the UE and the N6 termination point in the UPF (5.7.3.4 of TS23.501).Furthermore, a fixed delay for the delay between the UPF terminating N6 and the 5G-AN (gNB) should be subtracted from the given packet delay budget (PDB) to derive the packet delay budget applied to the air interface (between the UE and the gNB). Examples of fixed delays are provided in the notes associated with Table 5.7.4-1 of TS 23.501. For example, 5QI#85 may have a packet delay budget equal to 5 ms and may be considered to require time synchronization at the RAN level, while 5QI#3 may have a packet delay budget equal to 50 ms and may be considered to have no need for time synchronization at the RAN level. When the UE determines the need for time synchronization, it sends a signaling message (e.g., a time synchronization control message) to the gNB to initiate RAN time synchronization. For example, the need for time synchronization may be determined when a PDU session is accepted using a QoS parameter that reflects a packet delay budget value (or a packet delay budget applied to the radio interface between the UE and the gNB) that is below a threshold or time delay criterion (e.g., less than 10 ms or less than 5 ms).
[0113] The need for time synchronization may be determined for a Single Network Slice Selection Assistance Information (S-NSSAI) value having a Slice Service Type (SST) configured for Ultra Reliable Low Latency Communication (URLLC).
[0114] In another example implementation, UE 300 may use Single Network Slice Selection Assistance Information (S-NSSAI, section 9.11.2.8 of TS 24.501) included in the PDU SESSION ESTABLISHMENT ACCEPT message to determine in step 502a whether the PDU session has specific requirements regarding time synchronization (requests or requires time synchronization). Network slices enable the creation of several logical networks with different requirements on the same physical infrastructure. Network slice identification is performed using the S-NSSAI. The S-NSSAI (as defined in section 5.12.2.1 of TS 23.501) consists of two fields: a Slice Service Type (SST), which is mandatory and indicates the expected behavior of the network slice in terms of features and services; and a Slice Differentiator (SD), which is optional information that complements the slice / service type and allows differentiation between multiple network slices of the same slice / service type. Currently, five different values of the service are standardized, as shown in Table 5.15.2.2-1 in TS 23.501. For example, to determine whether a Packet Data Unit (PDU) session for Time Sensitive Communication (TSC) is detected, the UE checks the S-NSSAI value. If the S-NSSAI value corresponds to a value indicating the need for time synchronization, the UE 300 determines that there is a request or need for time synchronization and prepares a time synchronization control message to request activation of a time synchronization process in the Radio Access Network (RAN).The S-NSSAI indicating the need for time synchronization can be, for example, a new SST value for Time Sensitive Communication among the unused values of the standardized SST (0 to 127); or it can be an SST value for a dedicated operator-supported TSC service in the operator-specific range (128 to 255); or it can use a specific SD value to identify the current standardized service, for example, SST=2 for Ultra Reliable Low Latency Communication with SD=1 for Time Sensitive addon. Knowledge of the specific value for Time Sensitive Communication can be standardized or shared during the preparation procedure (as described in TS 23.501, clause 5.15), for example, during the UE's registration with the core network.
[0115] In an alternative example to that shown in FIG. 5a, a time synchronization control message may be sent by UE300 to gNB200 immediately after it is generated or created in step 503a and before the acceptance of the PDU session establishment (e.g., before the acceptance of the PDU SESSION ESTABLISHMENT ACCEPT) to initiate the time synchronization process before the establishment.
[0116] In some cases, if a PDU session has a high priority, the probability of acceptance of the PDU session is high, and finally, if the PDU session is rejected (e.g., in response to receiving a PDU SESSION ESTABLISHMENT REJECT message), the UE 300 can send another time synchronization control message to stop or terminate the time synchronization process.
[0117] Reference is now made to FIG. 5b, which illustrates a flow diagram of an exemplary method performed by UE 300 when triggered by a PDU session release, according to one embodiment of the present invention.
[0118] First, in step 501b, UE 300 requests the release of a PDU session as described in section 6.4.3 of TS 24.501. The PDU SESSION RELEASE REQUEST is sent to the Session Management Function (SMF), a core network entity. The message mainly contains the reason for the release and the identity of the PDU session.
[0119] As explained above, a PDU session identity or identifier is used to identify a PDU session. Furthermore, during the establishment of a PDU session, the UE associates the need for time synchronization with the PDU session ID (step 502a in FIG. 5c). Thus, in step 502b, to determine whether the PDU session for which release is requested is a PDU session with a need for time synchronization, the UE 300 uses the PDU session ID to verify whether the PDU session is flagged as requiring time synchronization.
[0120] If the PDU session is identified as one requiring time synchronization (yes branch of step 502b), the UE 300 creates or generates a time synchronization control message to stop or terminate the time synchronization process in the RAN (503b).
[0121] UE 300 proceeds to end step 508b. Otherwise, if the session is not a session with time synchronization (no branch of step 502b), the UE proceeds to end step 508b. After creating or generating the time synchronization control message during step 504b, UE 300 waits for feedback from the core network for PDU session release. If, upon receiving the PDU SESSION RELEASE REQUEST message and the PDU session ID, the SMF (core network entity) accepts the release of the PDU session, it performs the PDU session release procedure requested by the network (as specified in clause 6.3.3 of TS 24.501), i.e., it shall return a PDU SESSION RELEASE COMMAND to UE 300, and the UE responds with a PDU SESSION RELEASE COMPLETE. As a result, upon receiving the PDU SESSION RELEASE COMMAND (yes branch in step 504b), the UE 300 considers the release accepted, and then the UE sends a time synchronization control message to the gNB associated with the UE (step 505b). Then, before disabling time synchronization (step 506b), the UE checks whether other PDU sessions requiring time synchronization are always active. If there are no more active PDU sessions requiring time synchronization, the UE disables or terminates the time synchronization process in step 506b. In other words, the UE stops tracking the reception of messages related to the reference time and, possibly, path delay compensation from the gNB. The 5G time synchronization manager 303 also sets the RAN synchronization flag and the RAN PDC flag in the UE register to "off" (e.g., as described above, the 5G time synchronization manager 303 sets the RAN synchronization flag and the RAN PDC flag in the UE register to "off"). Otherwise, if at least one PDU session requiring time synchronization is always active, time synchronization remains enabled or active.
[0122] Otherwise, upon receiving the PDU SESSION RELEASE REJECT (no branch in step 504b), the UE 300 deletes the time synchronization control message (507b) and ends the method (step 508b).
[0123] In an alternative example, in step 501b, the release request procedure is initiated by the network instead of the UE by receiving a PDU SESSION RELEASE COMMAND message from the core network and checking whether the PDU session identity or identifier in the PDU SESSION RELEASE COMMAND message is associated with a time synchronization need, as described above. The UE then performs the same steps from 502b to 508b (except omitting steps 504b and 507b).
[0124] Reference is now made to FIG. 5c, which illustrates a flow diagram of an exemplary method performed by UE 300 when triggered by a PDU session modification, in accordance with an embodiment of the present invention.
[0125] First, in step 501c, UE 300 requests or receives a PDU session modification (as described in TS 24.501 clause 6.4.2 for the UE-requested PDU session modification procedure and clause 6.3.2 for the network-requested PDU session modification procedure). A PDU SESSION MODIFICATION REQUEST is sent to a core network entity, the Session Management Function (SMF). As for the PDU session establishment procedure, the message includes a Requested QoS flow description field with a QoS flow description information element (clause 9.11.4.12.1 in TS 24.501). UE 300 can check the 5QI parameter included in the QoS flow description. If the 5QI value corresponds to a delay-critical guaranteed bit rate GBR (#82, #83, #84, #85) or any other value indicating the need for time synchronization, the UE can determine that there is a need for time synchronization, and in particular a need or request for time synchronization. The PDU SESSION MODIFICATION REQUEST may also contain the DS-TT parameters, i.e., the Port Management Information Container and the 5GSM Capabilities with TPMIC bits, as described above with reference to Fig. 5a for the PDU session establishment procedure. During step 502c, the UE 300 checks, for example based on QoS parameters or DS-TT parameters, whether the modification affects the time synchronization needs (i.e., whether the modified PDU session requests or requires a modified time synchronization request). If the modification of the PDU session modifies the time synchronization needs or requirements (yes branch of step 502c), there are two different cases:
[0126] Case 1: The PDU session is modified from one requiring time synchronization to one not requiring time synchronization (step 502c: yes branch, step 503c: no branch). For example, the 5QI may be modified from a value associated with a low packet delay budget (e.g., 5QI#85 with PDB=5 ms) to a value associated with a high packet delay budget (e.g., 5QI#3 with PDB=50 ms), i.e., time synchronization may no longer be required for the modified PDU session. In this case, the UE 300 creates or generates a time synchronization control message requesting the RAN to stop or terminate the time synchronization process (step 504c). The UE then waits for feedback from the core network entity for the PDU session modification (505c).
[0127] If, upon receiving the PDU SESSION MODIFICATION REQUEST message, the SMF accepts the request to modify the PDU session, the SMF (core network entity) shall perform the PDU session modification procedure requested by the network (as specified in clause 6.3.2 of TS 24.501), i.e. the SMF returns a PDU SESSION MODIFICATION COMMAND to the UE 300, which responds with a PDU SESSION MODIFICATION COMPLETE or a PDU SESSION MODIFICATION COMMAND REJECT (which is unlikely to occur if the modification was requested by the UE). Thus, upon receiving the PDU SESSION MODIFICATION COMMAND, the UE 300 considers the modification accepted (yes branch of step 505c) and thereafter the UE 300 sends a time synchronization control message to the associated gNB (step 506c). Before disabling time synchronization, UE300 then checks whether other PDU sessions requiring time synchronization are still active. If there are no active PDU sessions requiring time synchronization, UE300 disables or deactivates the time synchronization process in the UE (step 507c). In other words, UE300 stops tracking the reception of messages related to the reference time and, possibly, path delay compensation from the gNB. The UE also sets the state of RAN synchronization and RAN PDC to "off." Otherwise, if at least one PDU session requiring time synchronization is still active, time synchronization remains enabled or active.
[0128] Upon receiving the PDU SESSION MODIFICATION REJECT (no branch in step 505c), the requested modification is rejected and the UE deletes the time synchronization control message (step 512c) and ends the method (step 513c).
[0129] Case 2: The PDU session is modified from one that does not require time synchronization to one that requires time synchronization or to one with an adaptation that requires time synchronization (yes branch in step 502c, yes branch in step 503c). For example, DS-TT parameters are added in the PDU SESSION MODIFICATION REQUEST message, while they were initially absent during the establishment of the PDU session. In another example, the 5QI may be modified from a value associated with a high packet delay budget (e.g., 5QI#3 with PDB=50ms) to a value associated with a low packet delay budget (e.g., 5QI#85 with PDB=5ms), i.e., the modified PDU session requires time synchronization. The PDU session may be modified using a packet delay budget that requires time synchronization, but may have stricter budget requirements. With stricter budget requirements, time synchronization may require, for example, path delay compensation in addition to the main time synchronization process. On the other hand, the modifications may remove the constraint on the packet budget delay, so that path delay compensation may become useless and unnecessary.
[0130] UE300 then creates or generates a time synchronization control message to reflect the requested modification (step 508c). For example, in the case of a modification requiring time synchronization with path delay compensation, UE300 generates a time synchronization control message to request initiation of a time synchronization process with path delay compensation in the RAN. The time synchronization control message generated by UE300 may be based on the MAC CE described below with reference to FIG. 11. Using such a MAC CE time synchronization control message, the time synchronization field or flag (bit 8) of the time synchronization control message is enabled or set to "on," and the path delay compensation field or flag (bit 7) of the time synchronization control message is also enabled or set to "on." UE300 then waits for feedback from the core network entity regarding the modification of the PDU session.
[0131] Upon receiving the PDU SESSION MODIFICATION REQUEST message, if the SMF accepts the request to modify the PDU session, the SMF (core network entity) shall perform the network requested PDU session modification procedure (specified in clause 6.3.2 of TS 24.501), i.e. the SMF returns a PDU SESSION MODIFICATION COMMAND to UE 300, which responds with a PDU SESSION MODIFICATION COMPLETE or (unlikely if the modification is requested by the UE) a PDU SESSION MODIFICATION COMMAND REJECT. Consequently, upon receiving the PDU SESSION MODIFICATION COMMAND, UE 300 considers the modification accepted (yes branch in step 509c), after which UE 300 transmits (in step 510c) a time synchronization control message to its associated gNB. Then, in step 511c, depending on whether the PDU session is changed from a PDU session that does not require time synchronization to a PDU session that requires time synchronization or a PDU session with an adaptation that requires time synchronization, UE300 initiates time synchronization or adapts its time synchronization process based on the required correction (e.g., tracks the state of the reference time and path delay compensation message, RAN synchronization and RAN PDC).
[0132] Upon receiving the PDU SESSION MODIFICATION REJECT (no branch in step 509c), the requested modification is rejected and the UE 300 deletes the time synchronization control message (step 512c) and ends the method (513c).
[0133] In another example, the UE 300 can determine the time synchronization requirement and any changes to the time synchronization requirement based on the S-NSSAI in a message received from a core network entity. For example, the message can be a CONFIGURATION UPDATE COMMAND received by the UE 300 from an Access and Mobility Function (AMF) in the core network. The S-NSSAI can be changed through this message as described in the Generic UE Configuration Update procedure (section 5.4.4 in TS 24.501). In such a case, UE300 may determine from the message received from the AMF that the S-NSSAI value has changed from a value associated with time-sensitive communication (e.g., SST value = 5 for Ultra-Reliable Low-Latency Communication or a new SSST value = 6 for Time-Sensitive Communication) to an S-NSSAI with a value that does not require time synchronization (e.g., SST value = 1 for 5G Enhanced Mobile Broadband) or an existing SST value (e.g., SST = 5 for Ultra-Reliable Low-Latency Communication) and to no SD field in the SD value or message, i.e., that the PDU session no longer requires time synchronization from the SD indicating the need for time synchronization. In this case, as in case 1 in step 504c above, UE300 creates or generates a time synchronization control message to request the RAN to stop or terminate the time synchronization process.
[0134] Reference is now made to Figure 5d, which illustrates a flow diagram of an exemplary method performed by UE 300 in accordance with an embodiment of the present invention when triggered by a synchronization notification received from a core network entity of a wireless network (e.g., a core network entity of core network 101 of 5G network 100 of Figure 1). In other words, the UE may be instructed by an entity in the core network to initiate RAN time synchronization.
[0135] In a first step 501d, the UE 300 receives a synchronization notification from a core network entity, such as a Session Management Function (SMF), for example in the form of a Port Management Information Container (PMIC) message as defined in clause 9.11.4.27 of TS 24.501.
[0136] The PMIC carries information defined in TS 23.501, subclause 5.28.3.1. The information carried in the PMIC is for configuring the Precision Time Protocol, which ensures synchronization of DS-TT and, in particular, TSN applications. This includes port information elements such as "PTP instance ID," "defaultDS.clockIdentity," and "defaultDS.instanceEnable." The port information "PTP instance ID," "defaultDS.clockIdentity," and "defaultDS.instanceEnable" in the PMIC message can be used to notify the UE about the start or activation and stop or deactivation of time synchronization processes or services, as described in TS 23.501, subclause K.2.2. The "PTP instance ID," "defaultDS.clockIdentity," and "defaultDS.instanceEnable" port information can be exchanged between the core network and the UE to activate RAN time synchronization. Another parameter of the configuration information provided by the PMIC message is the PTP profile (defined in IEEE Std 1588-2019, subclause 20.3.3). Each PTP profile defines a set of parameters to support applications that are more or less stringent in terms of synchronization accuracy, and can be used to determine the need for PDC in addition to time synchronization.
[0137] In step 502d, the UE 300 checks the "defaultDS.instanceEnable" port information in the received synchronization notification PMIC message.
[0138] If "defaultDS.instanceEnable" is "True", in step 503d, UE300 checks the state of RAN synchronization. If RAN synchronization is set to "off" (no branch in step 503d), in step 507d, a time synchronization control message is created or generated to start or initiate the time synchronization process between UE300 and gNB200. In other words, the SMF may instruct the UE to start RAN clock synchronization (or RAN time synchronization) through the writing of Port Management Information. If RAN synchronization is "on" (yes branch in step 503d), in step 505d, UE300 checks the value of the port information received in the synchronization notification PMIC message (in step 501d) to determine whether the time synchronization requirements have changed such that the time synchronization process needs to be modified, for example by changing an option or additional feature such as PDC (path delay compensation). If the time synchronization requirement has changed (yes branch in step 505d), then in step 506d, UE 300 generates or creates a time synchronization control message to change the RAN synchronization option. If the time synchronization requirement has not changed (no branch in step 505d), then there is no need to send a time synchronization control message, and UE 300 proceeds to end step 510d.
[0139] If "defaultDS.instanceEnable" is "False" in step 502d (no branch), then in step 504d, UE300 checks the state of RAN synchronization. If the state is "On" (yes branch in step 504d), then in step 508d, a time synchronization control message is created or generated between UE300 and gNB200 to stop, terminate, or disable time synchronization processing in the RAN. If RAN synchronization is "Off" (no branch in step 504d), there is no need to send a time synchronization control message, and UE300 proceeds to end step 510d.
[0140] Step 505d includes checking both the RAN PDC state in the UE 300 and the port information "PTP Profile" (Precision Time Protocol Profile) of the received synchronization notification PMIC message. If the RAN PDC state is "ON" and the "PTP Profile" indicates a less demanding PTP profile, such as the "Default Delay Request-Response" profile, the PDC must be stopped. On the other hand, if the PDC state is OFF and the "PTP Profile" indicates a more demanding profile, such as the "802.1AS" profile, the PDC must be started. PTP profiles are defined in Section 20.3.3 of IEEE Std 1588-2019. Each PTP profile defines a set of parameters to support applications that are more or less demanding in terms of synchronization accuracy, for example. In other words, the necessity of the PDC (e.g., whether the PDC should be operational or inactive, and depending on the current state of the PDC, whether it should be started / activated (to make it operational), maintained in an active state, stopped / deactivated (to make it inactive), or maintained in an inactive state) can be determined based on the PTP profile parameters provided by the PMIC message.
[0141] In step 506d, a time synchronization control message is created or generated. The time synchronization control message generated by UE 300 may be based on the MAC CE, which will be described later with reference to FIG. 11 . Using such a MAC CE time synchronization control message, in step 506d, a time synchronization field or flag (bit 8) in the time synchronization control message is enabled or set to “on.” If the RAN PDC state is “inactive” or “off” due to a change in synchronization requirements, as determined in step 505d, a path delay compensation (PDC) field or flag (bit 7) in the time synchronization control message is enabled or set to “on.” Thus, if the RAN PDC state is active or “on,” the PDC field in the time synchronization control message is set to “off.” The RAN PDC state in UE 300 changes to “on,” and the time synchronization control message is transmitted in step 509d. In another example, the time synchronization control message generated by UE 300 may be based on an RRC message, such as a UE Assistance Information message, which will be described later. For example, the IE of the UE Assistance Information message may include a refTime-activation field for indicating whether time synchronization processing is active or inactive, and a pdc-Activation field for indicating whether path delay compensation is active or inactive.
[0142] In step 507d, a time synchronization control message is created or generated. The time synchronization control message generated in UE 300 may be based on the MAC CE, which will be described later with reference to FIG. 11. Using this MAC CE time synchronization control message, in step 507d, a time synchronization field or flag (bit 8) in the time synchronization control message is set to be enabled or set to “on,” and the RAN synchronization state in UE 300 is set to an operational state or “on.” If the port information “PTP Profile” indicates a less demanding PTP profile, such as the “Default Delay Request-Response” profile, a path delay compensation (PDC) field or flag (bit 7) in the time synchronization control message is set to be disabled or set to “off,” and the RAN PDC state in UE 300 is set to a non-operational state or “off.” On the other hand, if the “PTP Profile” indicates a more strict profile, such as the 802.1AS profile, both the PDC field in the time synchronization control message and the RAN PDC state in UE 300 are set to “on.” Then, in step 509d, a time synchronization control message is transmitted. In another example, the time synchronization control message generated by UE 300 may be based on an RRC message such as a UE Assistance Information message described below. For example, the IEs of the UE Assistance Information message may include a refTime-activation field for indicating whether time synchronization processing is activated or deactivated, and a pdc-Activation field for indicating whether path delay compensation is activated or deactivated.
[0143] In step 508d, a time synchronization control message is created or generated. The time synchronization control message generated by UE300 may be based on the MAC CE described below with reference to FIG. 11. Using such a time synchronization control message of the MAC CE, in step 508d, both the time synchronization field or flag (bit 8) and the path delay compensation (PDC) field or flag (bit 7) of the time synchronization control message are set to "off," along with both the RAN synchronization and RAN PDC states in UE300. Then, in step 509d, a time synchronization control message is transmitted to stop, deactivate, or disable time synchronization processing in the RAN between UE300 and gNB200. In another example, the time synchronization control message generated by UE300 may be based on an RRC message such as a UE Assistance Information message described below. For example, the IEs in the UE Assistance Information message may include a refTime-activation field for indicating whether time synchronization processing is activated or deactivated, and a pdc-Activation field for indicating whether path delay compensation is activated or deactivated.
[0144] In another example, a duration value corresponding to the duration for which the time synchronization process should be in an active state may be transmitted to UE 300 together with a synchronization notification from a core network entity. When the time synchronization process is activated or started based on the synchronization notification, the time synchronization process may be deactivated autonomously or automatically by UE 300 after the duration expires without requiring a deactivation message to be transmitted from the SMF. For example, the duration may be used to set a timer in UE 300, and when the timer expires, the UE transmits a time synchronization control message to stop, deactivate, or disable the time synchronization process in the RAN between UE 300 and gNB 200.
[0145] The gNB 200 receives a time synchronization control message from the UE 300. This time synchronization control message includes information for controlling a time synchronization process in the RAN between the UE and the base station. For example, the time synchronization control message may control the activation or termination of the time synchronization process in the RAN. In addition to the main process of time synchronization, i.e., the transmission of a reference time, the time synchronization control message may also control options or additional functions of the time synchronization process, such as whether path delay compensation should be activated.
[0146] Reference is now made to FIG. 6a, which illustrates a flow diagram of an exemplary method for controlling time synchronization in a wireless network, according to an embodiment of the present invention, performed by a gNB 200.
[0147] First, in step 601a, the gNB 200 receives a time synchronization control message from the UE 300. The time synchronization control message may be a MAC CE message as described below with reference to Figure 11, or an RRC message (such as, but not limited to, an RRC reconfiguration complete, an RRC resume complete, an RRC resume message, etc., that includes time synchronization parameters similar to those described for the UE Assistance Information message).
[0148] As described above, the time synchronization control message may include at least a first field or a time synchronization field for indicating whether the time synchronization process is active or inactive, and may include a second field or a PDC field for indicating whether the path delay compensation is active or inactive. For example, if the time synchronization control message generated by UE 300 is based on a MAC CE described later with reference to FIG. 11, the time synchronization control message of such a MAC CE includes a time synchronization field or flag (bit 8) and a path delay compensation field or flag (bit 7). For example, if the time synchronization control message generated by UE 300 is based on a UE Assistance Information message, the time synchronization control message includes a refTime-activation field for indicating whether the time synchronization process is active or inactive, and a pdc-Activation field for indicating whether the path delay compensation is active or inactive. Each field can be set to "on" or "off." The gNB200 then analyzes the time synchronization control message and checks whether a first field (e.g., a time synchronization field) is set to "on" (yes branch in step 602a). If the time synchronization field in the time synchronization control message is set to "on", then in step 603a, the gNB200 enables or activates a time synchronization process, thereby scheduling the transmission of a reference time to the UE300 that emits or transmits the time synchronization control message. The reference time information is carried by an RRC message (such as a DLInformationTransfer message) or an SIB9 message (e.g., in a unicast message).The time synchronization control message (whether it is a MAC CE message or a UE Assistance Information RRC message) may include an additional field indicating the UE preference / configuration (e.g., unicast or broadcast, a predetermined periodicity for transmission of the reference time information, the type of PDC supported (pre-compensated, RTT, TA, etc.), or the like) for transmission of the reference time information (and PDC information, if necessary) by the gNB200. The gNB200 may transmit the reference time information to the UE300 based on the information in the additional field in the time synchronization control message.
[0149] Otherwise, if the time synchronization field is set to "off" (no branch in step 602a), in step 607a, gNB200 disables or terminates the time synchronization process, thereby disabling or terminating the transmission of reference time information to UE300, and in step 608a, stops transmitting PDC messages for UE300 (if PDC is in an operational state).
[0150] After step 603a, gNB200 checks whether the PDC field or flag is set to "on" (step 604a). If the PDC field or flag is set to "on" in the time synchronization control message (yes branch in step 604a), gNB200 starts a process of calculating a path delay value between itself and the UE, and schedules the transmission of a path delay compensation message including the path delay value or information representing the path delay value to UE300 (step 606a).
[0151] If the PDC field or flag is set to "off" (no branch in step 604a), the gNB200 stops sending path delay compensation messages to the UE if the PDC was previously set to "on" (step 605a).
[0152] Reference is now made to Figure 6b, which illustrates a flow diagram of an exemplary method for controlling time synchronization in a wireless network, according to an embodiment of the present invention, performed by a gNB200.
[0153] In the case of pre-compensation, the PDC is applied directly to the reference time by the gNB 200 before transmitting the reference time to the UE 300. Pre-compensation is used when the reference time is to be transmitted to one UE (in a unicast message) because it takes into account propagation delays that may differ for different UEs.
[0154] First, in step 601b, gNB200 (e.g., UE synchronization manager 201 of the gNB) receives a time synchronization control message from UE300.
[0155] The gNB200 then analyzes the time synchronization control message to determine whether the time synchronization field or flag is set to "on" (yes branch in step 602b). If the time synchronization field or flag in the time synchronization control message is set to "on," the gNB200 schedules the transmission of the reference time to the UE300 that emits the time synchronization control message (step 603b). The reference time information is carried by an RRC message (such as a DLInformationTransfer message) or an SIB9 message. The time synchronization control message (whether it is a MAC CE message or a UE AssistanceInformation RRC message) may include an additional field indicating the UE preference / configuration for the transmission of the reference time information (and PDC information, if necessary) by the gNB200 (e.g., unicast or broadcast, a predetermined periodicity for the transmission of the reference time information, the type of PDC supported (pre-compensated, RTT, TA, etc.), or the like). The gNB200 may transmit the reference time information to the UE300 based on the information in the additional field in the time synchronization control message. If the UE only supports pre-compensation as a PDC type, the gNB must apply pre-compensation.
[0156] Otherwise, if time synchronization is set to "off" (no branch in step 602b), gNB200 disables the transmission of reference time information to UE300 (step 607b).
[0157] After step 603b, gNB200 checks whether the PDC field or flag is set to "on" (step 604b). If the PDC field or flag is set to "on" in the time synchronization control message, gNB200 starts (in step 606b) a process to calculate a path delay value between UE300 and itself and applies the path delay value to the reference time.
[0158] For example, the gNB can calculate the last calculated and transmitted TA and the formula (T TA -T C ×N TA,offset ) / 2, where T TA is the timing advance between the downlink and uplink frames, and T C is the basic time unit for New Radio as defined in TS38.211, section 4.1. TA is subsequently determined by the gNB, which calculates the TA to be transmitted within the TA command. Thus, the determination of the guaranteed reference time is performed after the transmission of the TA command by the gNB. The gNB determines the compensated reference time by adjusting (adding) the reference time with the calculated path delay value.
[0159] If the PDC field or flag is set to "off" (no branch in step 604b), the gNB200 stops the process of calculating the path delay if PDC processing was previously set to "on" and stops applying the path delay to the reference time information (step 605b).
[0160] In another example, instead of completely disabling the transmission of reference time information to the UE in step 607b, the gNB200 may not completely disable the transmission of the reference time, but may, for example, reduce the periodicity of the transmission of the reference time information to the UE300.
[0161] Reference is now made to Figure 6c, which illustrates a flow diagram of an exemplary method for controlling time synchronization in a wireless network, according to an embodiment of the present invention, performed by gNB200.
[0162] In this example, the reference time is broadcast to all UEs in the cell, so the gNB 200 checks whether there are no more UEs requesting time synchronization before disabling or terminating the time synchronization process and stopping the transmission of the reference time. As mentioned above, because the reference time is broadcast, pre-compensation for path delay cannot be used.
[0163] First, in step 601c, the gNB 200 receives a time synchronization control message from the UE 300. The message may be a MAC CE as described with reference to Figure 11 or an RRC message (UE Assistance Information with information elements dedicated to time synchronization configuration and activation as described further in the description).
[0164] The gNB200 then parses the time synchronization control message to determine whether a time synchronization field or flag is set to "on" (step 602c). If the field or flag in the time synchronization control message is set to "on," the gNB200 performs another step (603c) to determine whether the time synchronization process has begun.
[0165] If time synchronization has not yet started (no branch in step 603c), gNB200 schedules the transmission of the reference time (step 607c). The reference time information is broadcast in an RRC message or an SIB9 message. Step 608c is then performed as described below. The time synchronization control message (whether it is a MAC CE message or a UE Assistance Information RRC message) may include an additional field indicating a specific UE preference / configuration (e.g., unicast or broadcast, a predetermined periodicity for the transmission of the reference time information, the type of PDC supported (pre-compensated, RTT, TA, etc.), or the like) for the transmission of the reference time information (and PDC information, if necessary) by gNB200. gNB200 may transmit the reference time information to UE300 based on the information in the additional field in the time synchronization control message.
[0166] Returning now to step 603c, if time synchronization has already started (yes branch in step 603c), gNB200 proceeds directly to step 608c and checks whether the PDC field or flag is set to "on" in the time synchronization control message. If the PDC field or flag is set to "on" in the time synchronization control message, gNB200 performs a process of calculating a path delay value between UE300 and itself, and schedules the transmission of path delay compensation including the path delay value or including information representing the path delay value (step 610c).
[0167] If the PDC field or flag is set to "off" (no branch in step 608c), the gNB300 stops calculating the path delay and stops sending path delay messages to the UE200 if the PDC was previously set to "on" (step 609c).
[0168] Returning to step 602c, if the time synchronization field or flag is set to "off" (no branch in step 602c), the gNB200 performs another step (step 604c) to check whether at least one UE300 in the cell requires time synchronization. If there are no UEs in the cell requiring time synchronization (no branch in step 604c), the gNB200 terminates the operation of the time synchronization process, thereby disabling the transmission of reference time information to UEs in the cell in step 605c and stopping the transmission of PDC messages to UEs (if PDC was previously enabled). Otherwise, if at least one UE requires time synchronization, the gNB200 stops only the PDC process for UEs that emit or transmit time synchronization control messages (606c).
[0169] FIG. 11 illustrates an exemplary MAC CE signaling frame format used as a time synchronization control message according to an embodiment of the present invention.
[0170] This signaling frame is transmitted from UE300 to gNB200 or from gNB200 to UE300 as described herein.
[0171] The synchronization control message conforms to the MAC CE format described in TS38.321 clause 6.1.3. As an example, the LCID field is shown here, and the MAC CE can also use an extended LCID field.
[0172] The MAC CE time synchronization control message includes at least a first field (e.g., a time synchronization field or flag (Time sync)) for indicating whether the time synchronization process is in an active state or an inactive state. The Time sync field can be set to "on" or "off" to start / activate / enable or stop / terminate / disable the time synchronization process in the RAN.
[0173] The MAC CE time synchronization control message may further include a second field (e.g., a PDC field or flag) to activate or deactivate the PDC. The PDC field shall be set to "off" if the Time sync field is "off", otherwise it may be set to "on" or "off" depending on whether path delay compensation should be activated or not.
[0174] The MAC CE time synchronization control message may include additional information indicating specific UE preferences / configurations for the transmission of reference time information (and PDC information, if necessary) by gNB200 (e.g., unicast or broadcast, a predetermined periodicity for the transmission of reference time information, the type of PDC supported (pre-compensation, RTT, TA, etc.), or the like).
[0175] In another example, the time synchronization control message may be an RRC message, such as a UE Assistance Information message, with an Information Element (IE) for providing information for controlling the time synchronization process, such as time synchronization and PDC configuration and activation information. For example, the IE may include a first field (e.g., a refTime-activation field) for indicating whether the time synchronization process is active or inactive, and a second field (e.g., a pdc-Activation field) for indicating whether the PDC is active or inactive. The IE may include additional fields indicating specific UE preferences / configurations for transmission of reference time information (and PDC information, if necessary) by the gNB 200 (e.g., unicast or broadcast, a predetermined periodicity for transmission of reference time information, a type of PDC supported (e.g., pre-compensated, RTT, TA, etc.), or the like).
[0176] As described in section 6.2.2 of TS38.331, "The UEAssistanceInformation message is used to indicate UE assistance information to the network."
[0177] To set time synchronization in the RAN (RAN synchronization), a UEAssistanceInformation-v17 information element (IE) is added, and the information element includes a field related to PDC and a field related to refTime (RAN synchronization).
[0178] For RAN synchronization, the UEAssistanceInformation-v17 IE contains the following fields: refTime-activation, which can be either "on" or "off" and instructs the gNB to start or stop synchronization to the radio network (e.g., to start / enable or deactivate / disable the time synchronization process in the UE or gNB); referenceTimeInfo-Periodicity to inform the gNB whether the UE needs the reference time every few ms or only once, and referenceTimeInfo-transfer, which can be either broadcast or unicast to inform the gNB of the UE's preference for the type of message to transfer reference time information.
[0179] For PDC, the UEAssistanceInformation-v17 IE contains the following fields: "pdc-Activation", which can be either "on" or "off" and instructs the gNB to start or stop path delay compensation for radio network synchronization (e.g., to activate / enable or deactivate / disable the PDC in the UE or gNB); "pdc-Type", an array giving the types of PDC supported by the UE, each pdc-type is set to true if the UE supports this PDC type. For example: "pdc-Type" can be "Pre-compensation" if the path delay is applied by the gNB, "Legacy TA" if the path delay compensation scheme to be applied follows the Release-16 TA standard, or "Extended TA" if the path delay compensation scheme to be applied follows the Release-17 Timing Advance based standard, or "RTT" if the path delay compensation scheme to be applied follows the Release-17 Round Trip Time based standard; Control - "pdc-scenario" which informs the gNB in which scenario the UE is to be used (this information can be obtained from the application layer), e.g., to determine if PDC is required, such as control scenario / environment, power grid environment scenario / environment, etc. "pdc-periodicity" to inform the gNB whether the UE requires PDC every few ms or only on demand.
[0180] Several other fields related to synchronization can be either "on" or "off", including "Te-preference" to instruct the gNB whether the UE should follow the timing error Te defined in either Release 16 or Release 17 (low timing error), and "TA-granularity" to inform the gNB of the preferred TA granularity value (value of the TA correction step). Te is the UE transmit timing error as defined in TS38.133, section 7.1.2. The TA granularity is the correction step to be applied to the TA command (discussed in more detail above and described in TS38.211, section 4.3.1) to obtain the path delay value. The configurable TA granularity allows adaptation of the TA precision selected according to the type of use (scenario) or type of message (e.g., coarse granularity selected for the absolute timing advance command MAC CE (TS38.321 clause 6.1.3.4a) and finest granularity selected for the Update TA command MAC CE (TS38.321 clause 6.1.3.4)). For more details on TA granularity, see also 3GPP document R2-2100941 submitted by Canon Research Centre France.
[0181] All or some of the above-mentioned fields may be placed in other RRC messages, such as an RRC reconfiguration complete, an RRC resume complete, or an RRC resume request message.
[0182] The UEAssistanceInformation message looks like this (additional information elements are in bold, mainly at the end): TIFF2025124735000002.tif245161TIFF2025124735000003.tif239161TIFF2025124735000004.tif245161TIFF2025124735000005.tif245161TIFF2025124735000006.tif97161In another example, the time synchronization control message may be an RRC reconfiguration message with an Information Element (IE) for providing information for controlling time synchronization processing such as time synchronization and PDC configuration and startup information.
[0183] As stated in section 6.2.2 of TS38.311, "The RRCReconfiguration message is a command to modify the RRC connection. It may carry information for measurement configuration, mobility control, radio resource configuration (including RB, MAC primary configuration, and physical channel configuration), and AS security configuration."
[0184] To configure RAN synchronization, an RRCReconfiguration-v17 information element is added. The IE may include a first field (e.g., a RAN_synchronization field) for indicating whether the time synchronization process is active or inactive, and a second field (e.g., a RAN_pdc field) for indicating whether the PDC is active or inactive. The RAN_synchronization field can be either "on" or "off" and instructs the UE to start or stop synchronization with the radio network. The RAN_pdc field can also be either "on" or "off" and instructs the UE to start or stop path delay compensation for synchronization with the radio network. Finally, the IE may include a third field (e.g., a RAN_pdc_type) for indicating the type of path delay compensation scheme to be applied. For example, this RAN_pdc_type field can be R16 if the path delay compensation scheme to be applied is to comply with the Release 16 standard, R17_TA if the path delay compensation scheme to be applied is to comply with the Release 17 Timing Advance based standard, or R17_RTT if the path delay compensation scheme to be applied is to comply with the Release 17 Round Trip Time based standard.
[0185] The RRCReconfiguration message looks like this (additional information elements at the end): TIFF2025124735000007.tif245161TIFF2025124735000008.tif245161TIFF2025124735000009.tif244161TIFF2025124735000010.tif86161In the second embodiment, a base station (such as gNB 102 in Figure 1 or gNB 200 in Figure 2 - for simplicity, only reference number 200 will be used for the base station or gNB below) determines a request for time synchronization between a UE (such as UE 104a, 104b in Figure 1 or UE 300 in Figure 3 - for simplicity, only reference number 300 will be used for the UE below) and the base station, and generates a time synchronization control message accordingly. For example, the gNB 200 determines whether time synchronization is required or whether a change (such as activating or deactivating PDC) is required to an already active time synchronization process. The gNB 200 may receive a message that triggers the creation of a time synchronization control message. The time synchronization control message includes information for controlling the time synchronization process, such as for activating or deactivating the time synchronization process, or for modifying the active time synchronization process (e.g., changing options or additional features of the time synchronization process), such as by activating or deactivating path delay compensation. In one example, the time synchronization control message includes a field for controlling the activation / deactivation of the time synchronization process in the UE.
[0186] Reference is now made to Figure 7a, which illustrates a flow diagram of an exemplary method according to an embodiment of the present invention, performed by gNB200 when triggered by the setup of a PDU session resource.
[0187] First, in step 1301, the gNB 200 receives a PDU SESSION RESOURCE SETUP REQUEST message (described in section 9.2.1.1 of TS38.413). The purpose of the PDU Session Resource Setup procedure is to allocate resources in Uu and Ng-U for one or more PDU sessions and corresponding QoS flows, and to configure the corresponding DRB for a given UE. The PDU SESSION RESOURCE SETUP REQUEST is received from a core network entity, such as the Access and Mobility Management Function (AMF). This message contains all of the information required to set up a PDU session related to NG-RAN. To determine the time synchronization requirements between the UE 300 and the gNB 200, a check is made in step 1302 as to whether this PDU session has certain requirements in terms of time synchronization (i.e., whether it requests or requires time synchronization, and possibly whether it requests or requires time synchronization with or without a PDC). For example, the PDU SESSION RESOURCE SETUP REQUEST message contains the PDU SESSION RESOURCE SETUP REQUEST Transfer (TS38.413 clause 9.3.4.1) Information Element (IE) implemented by the SMF. This IE contains at least the QoS Flow Level QoS Parameters (TS38.413 clause 9.3.1.12) that indicate the need for time synchronization for the RAN. The QoS parameters include the Dynamic 5QI Descriptor (also known as non-standardized or non-preconfigured 5QI) (TS38.413 clause 9.3.1.18) and Non-Dynamic 5QI Descriptor (also known as standardized 5QI) (TS38.413 clause 9.3.1.28) descriptions.These descriptors allow for the definition of QoS parameters, such as 5QI for non-dynamic 5QI, where there is a correspondence between the 5QI value and the packet delay budget, as defined in Table 5.7.4-1 of TS 23.501. For dynamic 5QI, the packet delay budget and delay criticality parameters are directly accessible and can be specified independently of the 5QI value. For example, in step 1302, the gNB 200 determines the need or requirement for time synchronization if the new 5QI value corresponds to a delay-critical GBR (#82, #83, #84, #85) or other value, e.g., in non-dynamic 5QI, or for a low packet delay budget (<10 ms) or delay-critical QoS flow in dynamic 5QI. The need for time delay can be determined when a PDU session is set up using QoS parameters of GBR #82, #83, #84, #85.
[0188] Also, for step 1302, an optional parameter, a Time Sensitive Communication (TSC) QoS Flow Information Element (IE), may be present in the PDU SESSION RESOURCE SETUP REQUEST Transfer. This IE provides traffic characteristics of the TSC QoS flow through TSC Assistance Information, which includes information such as traffic periodicity and burst arrival time. The TSC Assistance information may include information indicating the status of the NW-TT and DS-TT, or more generally, the status of the time synchronization process or service, for notification to the gNB200. Furthermore, the TSC Assistance information may include a duration value corresponding to the duration for which the time synchronization process is operational. Based on the presence of the TSC QoS Flow, the gNB200 may consider that time synchronization is required. For example, in step 502a, based on the presence of the TSC QoS Flow, the gNB200 may detect a Packet Data Unit (PDU) session for Time Sensitive Communication (TSC).
[0189] In another example, in step 1302, the gNB 200 may use the Single Network Slice Selection Assistance Information (S-NSSAI, clause 9.3.1.24 of TS38.413) included in the PDU SESSION RESOURCE SETUP REQUEST message to determine whether the PDU session has certain requirements in terms of time synchronization (i.e., requests or requires time synchronization). Network slices enable the creation of several logical networks with different requirements on the same physical infrastructure. The network slice is identified using the S-NSSAI. The S-NSSAI as defined in TS 23.501, subclause 5.12.2.1, consists of two fields: SST, which represents the Slice Service Type, which is mandatory and indicates the expected network slice behavior in terms of functions and services; and SD, which is the Slice Differentiator, which is optional information that complements the Slice / Service type to distinguish between multiple network slices of the same Slice / Service type. Currently, five different service values are standardized, as shown in Table 5.15.2.2-1 of TS 23.501. For example, to determine whether a Packet Data Unit (PDU) session for Time Sensitive Communication (TSC) is detected, the gNB 200 checks the S-NSSAI value. If the S-NSSAI value corresponds to a value indicating that time synchronization is required, the gNB 200 determines that there is a request or need for time synchronization and then prepares a time synchronization control message to request the activation of the time synchronization process in the Radio Access Network (RAN).The S-NSSAI indicating the need for time synchronization can be, for example, the SST value corresponding to Ultra Reliable Low Latency Communication (SST value = 2) or a new SST value (from 0 to 127) for Time Sensitive Communication among the values not used as standardized SST values; or the use of one SST value within the range of operator-specific values (from 128 to 255) for TSC services supported by dedicated operators; or the use of a specific SD value to detail a currently standardized service, for example, SST value = 2 for Ultra Reliable Low Latency Communication with SD = 1 for the Time Sensitive addon. Knowledge of the specific value for Time Sensitive Communication may be standardized or shared during the preparation procedure (as described in TS 23.501, clause 5.15).
[0190] The PDU SESSION RESOURCE SETUP REQUEST also includes a PDU session identity or identifier used to identify the PDU session. This PDU session ID is present in all messages for controlling the PDU session. Also, if the PDU session is classified using a time synchronization requirement (step 1302), the gNB 200 associates the PDU session identity with the time synchronization requirement. Thus, in the following PDU session procedures, the gNB 200 can know whether the session is classified with a time synchronization requirement or requirement based solely on the PDU session identity.
[0191] Based on the previous characteristics, the gNB 200 determines in step 1302 that time synchronization is required. If the PDU session resource setup is successful (yes branch in step 1303), the gNB 200 creates a time synchronization control message to initiate the time synchronization process in the RAN (step 1304). In response to determining that time synchronization is required, the gNB transmits a signaling message (e.g., a time synchronization control message) to the UE to initiate RAN time synchronization. In one example, the time synchronization control message includes a time synchronization field set to enabled or "on" and, optionally, a PDC field set to enabled or "on" if strict synchronization is required. The time synchronization control message may be a MAC Control Element (MAC CE) message, such as described with reference to FIG. 11 for the MAC CE. In another example, the time synchronization control message may be an RRC reconfiguration message, as described above. Then, in step 1305, gNB200 transmits a time synchronization control message to the associated UE, for example, the UE identified in the RAN UE NGAP ID parameter (defined in the PDU SESSION RESOURCE SETUP REQUEST). Then, in step 1306, gNB200 enables or activates the time synchronization process, i.e., starts transmitting the reference time and, if the time synchronization control message includes a PDC field, starts calculating the path delay according to the PDC state set in the PDC field of the time synchronization control message. Some UE preferences, such as the type of transmission (unicast or broadcast), the periodicity of the reference time transmission, and the periodicity of the PDC information transmission, may have been previously received by gNB200 from UE300, for example, via a UE Assistance Information RRC message. These preferences allow gNB200 to adapt or modify the time synchronization process performed at gNB200 according to the UE preferences.
[0192] Otherwise, if time synchronization is not required (no branch at step 1302) or if PDU session resource setup fails (no branch at step 1303), gNB200 proceeds to end step 1307.
[0193] Reference is now made to Figure 7b, which illustrates a flow diagram of an exemplary method according to an embodiment of the present invention, performed by gNB200 when triggered by the release of PDU session resources.
[0194] First, in step 1401, the gNB 200 receives a PDU session release as described in section 8.2.2 of TS38.413. A PDU SESSION RESOURCE RELEASE REQUEST is received from a core network entity, the Access and Mobility Management Function (AMF). The message primarily contains the cause of the release and the identity or identifier of the PDU session.
[0195] As explained above, a PDU session identity or identifier (ID) is used to identify a PUD session. Furthermore, during the setup of PDU session resources, gNB200 associates the need for time synchronization with the PDU session ID (step 1302). Therefore, to determine whether the PDU session for which release is being requested is a PDU session that needs or requests time synchronization, gNB200 uses the PDU session ID to verify whether the PDU session is flagged as requiring time synchronization (step 1402).
[0196] If the PDU session is identified as a session that requests or requires time synchronization, and if the resources of the PDU session are successfully released (yes branch in step 1403), gNB200 creates a time synchronization control message to stop or disable time synchronization processing in the RAN (step 1404).
[0197] Then, the gNB200 transmits a time synchronization control message to the UE300 associated with itself (in step 1405). Before disabling or terminating time synchronization, the gNB200 checks in step 1406 whether other PDU sessions requiring time synchronization are constantly active. If there are no more active PDU sessions requiring time synchronization, the gNB200 disables or terminates the time synchronization process in step 1406. In other words, the gNB200 stops broadcasting the reference time and, in some cases, stops processing related to path delay compensation. In other cases, time synchronization remains enabled or active because at least one PDU session requiring time synchronization is constantly active.
[0198] Otherwise, if the session does not require time synchronization (no branch in step 1402) or if the release of resources for the PDU session fails (no branch in step 1403), the gNB proceeds to end step 1407.
[0199] Reference is now made to Figure 7c, which illustrates a flow diagram of an exemplary method according to an embodiment of the present invention, performed by gNB200 when triggered by a modification of a PDU session resource.
[0200] First, in step 1501, the gNB 200 receives a PDU session resource modification (described in section 8.2.3 of TS 38.413). A PDU SESSION RESOURCE MODIFY REQUEST is received from a core network entity, the Access and Mobility Management Function (AMF). Like the PDU SESSION RESOURCE SETUP REQUEST procedure, the message includes QoS flow-level QoS parameters with dynamic 5QI and non-dynamic 5QI descriptors, along with TSC Traffic Characteristics (PDU Session Resource Modify Request Transfer, included in section 9.3.4.3 of TS 38.413). The message may include an S-NSSAI to indicate whether the PDU session is linked to a network slice for the TSC. Based on these parameters, gNB200 may check in step 1502 whether the modification affects the time synchronization requirement (i.e., whether the modified PDU session requests or needs time synchronization, and possibly whether the modified PDU session requires PDUs if the PDU session requires time synchronization). There are two different cases: when the modification of the PDU session results in a modification of the time synchronization requirement or need (yes branch in step 1502) and when the modification of the PDU session's resources is accepted (yes branch in step 1503).
[0201] Case 1: A PDU session is modified from one requiring time synchronization to one that does not require time synchronization (yes branch in step 1502, yes branch in step 1504). For example, the 5QI may be modified from a value associated with a low packet delay budget (e.g., 5QI#85 with PDB=5ms) to a value associated with a high packet delay budget (5QI#3 with PDB=50ms), i.e., the modified PDU session no longer requires time synchronization. In another example, the S-NSSAI value may be modified from a value associated with time-sensitive communication (e.g., SST value = 5 for ultra-reliable low-latency communication or a new SST value = 6 for time-sensitive communication) to a value that does not require time synchronization (e.g., SST value = 1 for 5G enhanced mobile broadband), or from an S-NSSAI value with an existing SST value (e.g., SST = 5 for ultra-reliable low-latency communication) and an SD indicating that time synchronization is required to an SD value or to an absent SD field in the message, i.e., the PDU session no longer requires time synchronization. In this case, the gNB 200 creates a time synchronization control message to request the RAN to stop or terminate the time synchronization process (step 1505). The gNB 200 then transmits the time synchronization control message to the UE associated with the gNB 200 (step 1506). Before disabling the time synchronization process in step 1507, the gNB 200 checks whether other PDU sessions requiring time synchronization are constantly active. If there are no more PDU sessions requiring time synchronization, the gNB 200 disables or terminates the time synchronization process (step 1507). Otherwise, if at least one PDU session requiring time synchronization remains in an active state, time synchronization remains enabled or in an active state.
[0202] Case 2: A PDU session is modified from a PDU session with PDUs that do not require time synchronization to a PDU session with PDUs that require time synchronization or some adaptation of the need or requirement for time synchronization (yes branch in step 1502, no branch in step 1504). For example, a Time Sensitive Communication (TSC) parameter is added to the PDU SESSION RESOURCE MODIFY REQUEST message, whereas it was not present during resource setup of the initial PDU session. In such a case, the gNB 200 detects that the PDU session being modified is a PDU session for TSC and therefore requires time synchronization. In another example, the packet delay budget value is dropped from 50 ms to 2 ms, i.e., the modified PDU session requires time synchronization. In the last example, a PDU session is modified with a packet delay budget that requires time synchronization, but with a stricter budget requirement. With a stricter requirement, time synchronization may require, for example, path delay compensation in addition to the main time synchronization process. On the other hand, the modification may be that the packet delay budget constraint (eg, PDB from 2 ms to 15 ms) is lifted, so that path delay compensation becomes useless and is not required.
[0203] In that case, in step 1508, gNB200 creates a time synchronization control message to reflect the required correction. For example, gNB200 requests the initiation of time synchronization processing in the RAN with path delay compensation. Then, in step 1509, gNB200 transmits the time synchronization control message to UE300 associated with itself, and in step 1510, adapts its own synchronization processing (e.g., starts broadcasting a reference time and performs path delay compensation for some UEs, if necessary).
[0204] Otherwise, if there are no corrections related to time synchronization (no branch in step 1502) or if the correction of PDU session resources fails (no branch in step 1503), gNB200 proceeds to end step 1511.
[0205] In an alternative example, QoS monitoring (QoS Monitoring Request field in QoS Flow Level Parameters, section 9.3.1.12 of TS38.413) may be requested by the network during PDU session resource setup or PDU session resource modification. During monitoring, gNB200 may detect that the time synchronization requirement is no longer achieved for some UEs and may accordingly enable or activate path delay compensation (if it is not already enabled or operational) by sending time synchronization control messages to those UEs. Accordingly, gNB200 may report this modification of QoS parameters using PDU session resource notification.
[0206] Reference is now made to Figure 7d, which illustrates a flow diagram of an exemplary method, in accordance with an embodiment of the present invention, performed by gNB200 when triggered by a synchronization notification sent by a core network entity.
[0207] For each UE 300, the core network entity (SMF (Session Management Function)) sends a start synchronization notification to the gNB 200. This synchronization notification is sent transparently to the gNB 200 via the AMF (Application Management Function). The format of this notification is as follows: RAN_UE_NGAP_ID uniquely identifies the UE for which the gNB 200 should perform configuration. Such identifiers are described in clause 9.3.3.1 of TS38.413. If the identifier is equal to 0xFFFFFFFF, all UEs known to the gNB should be configured.
[0208] RAN_synchronization can be either "on" or "off" and instructs the gNB to start or stop (e.g., start / enable or deactivate / disable) synchronization of the UE with the radio network.
[0209] RAN_pdc can be either "on" or "off" and indicates the starting or stopping (e.g., activation / enabling or deactivation / disabling) of path delay compensation for UE synchronization to the wireless network.
[0210] RAN_pdc_type can be R16 if the applied path delay compensation scheme should comply with the Release 16 standard, which means that the gNB 200 should primarily instruct the UE to initiate or activate / enable PDC.
[0211] RAN_pdc_type can be R17_TA if the applied path delay compensation scheme should follow the Release 17 Timing Advance based standard, which means that the gNB 200 should instruct the UE to follow the same PDC scheme and the gNB should initiate or activate / enable related signaling including pre-compensation as necessary.
[0212] RAN_pdc_type can be R17_RTT if the applied path delay compensation scheme should follow the Round Trip Time based standard of Release 17. The operation of the gNB is similar to that described above.
[0213] In the first step 1601, the gNB200 receives a synchronization notification from the SMF.
[0214] Then, in step 1602, the gNB 200 checks the RAN_synchronization field in the synchronization notification. If this field is set to "on" (yes branch in step 1602), in step 1603, the gNB 200 creates or generates a time control synchronization message (such as the MAC CE time control synchronization message as described with reference to FIG. 11) directed to the UE referenced by the field RAN_UE_NGAP_ID with the Time sync field set to "on" and the PDC field set to the same value as the RAN_pdc field. In another example, the time control synchronization message can be transmitted as an RRC reconfiguration message as described above.
[0215] Then, in step 1604, a time synchronization control message is sent to the referenced UE.
[0216] In step 1605, the gNB 200 initiates the time synchronization process by scheduling the transmission of a reference time. The reference time information is transmitted in an RRC message or an SIB9 message. The gNB 200 may also initiate a path delay compensation process as reflected by the RAN_pdc and RAN_pdc_type fields.
[0217] Returning to step 1602, if the RAN_synchronization field is set to "off" (no branch in step 1602), in step 1606 the gNB200 creates or generates a time control synchronization message (MAC CE time control synchronization message as described with reference to Figure 8) directed to the UE referenced by the field RAN_UE_NGAP_ID with the Time sync field set to "off" and the PDC field set to "off".
[0218] In step 1607, a time synchronization control message is sent to the referenced UE.
[0219] In step 1608, the gNB 200 stops or disables the time synchronization process by disabling the transmission of the reference time. The reference time information is transmitted in an RRC message or an SIB9 message. The gNB 200 also stops, disables, or deactivates the path delay compensation process.
[0220] In another example, a duration value corresponding to a duration for which the time synchronization process should be in an operating state may be transmitted from a core network entity (SMF) along with the synchronization notification. Once the time synchronization process is activated or started based on the time notification, the time synchronization process may be deactivated autonomously or automatically by the gNB 200 after the duration has elapsed without requiring a deactivation message to be transmitted from the SMF. For example, the duration may be used to set a timer in the gNB 200, and upon expiration of the timer, the gNB transmits a time synchronization control message to the UE to stop, terminate, or disable the time synchronization process in the RAN between the UE 300 and the gNB 200.
[0221] FIG. 8 shows a flow diagram of an exemplary method performed by a UE 300 for controlling time synchronization in a wireless network according to an embodiment of the present invention.
[0222] First, in step 1701, the UE 300 receives a time synchronization control message from the associated gNB 200. The time synchronization control message may be a MAC CE message as described above with reference to Figure 11 or an RRC reconfiguration message as described above.
[0223] As described above, the time synchronization control message may include at least a first field for indicating whether the time synchronization process is enabled or disabled, and may include a second field for indicating whether the path delay compensation process is enabled or disabled. The time synchronization control message generated by the gNB 200 may be based on the MAC CE described with reference to FIG. 11. Such a time synchronization control message of the MAC CE includes a time synchronization field or flag (bit 8) and a path delay compensation field or flag (bit 7). Each field may be set to “on” or “off.” The UE 300 then analyzes the time synchronization control message and determines whether the first field (e.g., the time synchronization field) is set to “on.” If the time synchronization field in the time synchronization control message is set to “on” (yes branch in step 1702), the UE 300 activates or enables the time synchronization process in the UE 300 in step 1703. Then, in step 1704, UE300 checks whether a second field (e.g., a path delay compensation field) in the time synchronization control message is set to "on". If the PDC field in the time synchronization control message is set to "on" (yes branch in step 1704), UE300 activates or enables path delay compensation in UE300 in step 1706. If the PDC field in the time synchronization control message is set to "off" (no branch in step 1704), UE300 deactivates or disables path delay compensation in UE300 in step 1706.
[0224] Otherwise, if the time synchronization field is set to "off" (no branch at step 1702), at step 1707, UE300 disables or deactivates the time synchronization process at UE300.
[0225] Solutions have been proposed to control the activation of the PDC on the UE side, and more generally the activation of synchronization in the RAN. The above proposals show that this can be achieved without requiring additional information from the core network, such as a time synchronization error budget.
[0226] To ensure accurate time synchronization for time-sensitive communications (TSC), the time synchronization process is based on periodic transmission of a reference time from the gNB to the UE. To improve the accuracy of the time synchronization process, path delay compensation (PDC) can be performed, which is based on the exchange of dedicated signals between the UE and the gNB to estimate and convey path delay values. Thus, the time synchronization process and PDC require radio and processing resources in the RAN of the 5G network.
[0227] According to one aspect of the invention, signaling allows for enabling and disabling clock synchronization in the RAN (UE and gNB) only when necessary.
[0228] The NR IIoT Study Item (SI) concludes that specific enhancements to RAN functionality at various layers should be identified for Rel-16 to support new use cases such as factory automation, transportation, and power distribution. This leads to new QoS parameters for latency-critical applications in 5QI (TS23.501-Table 5.7.4-1). As explained above, smart grid scenarios are similar to power distribution, and control-control is similar to the discrete automation defined in GBR 5QI where latency is critical.
[0229] The UE or gNB may use the QoS parameters included in the PDU SESSION message to determine whether the PDU session has any specific requirements regarding time synchronization (i.e., whether time synchronization is necessary or required). The UE or gNB may analyze the QoS flow description information element included in the PDU SESSION message to check the 5QI parameter. If the 5QI value corresponds to a delay-critical GBR (#82, #83, #84, #85), the UE or gNB may determine that there is a request or need for time synchronization (accurate reference time with or without PDC).
[0230] According to an aspect of the present invention, the need for time synchronization can be determined when a PDU session is accepted with QoS parameters of GBR#82, #83, #84, or #85.
[0231] In the context of Time Sensitive Network applications, 5G systems are aggregated into TSN systems as TSN bridges. Two specific entities, namely the Device Side TSN Translator (DS-TT) and the Network Side TSN Translator (NW-TT), are responsible for translation between the TSN and 5G domains. To configure DS-TT, the 5G Core uses the Port Management Information message, a control message containing information for configuring the Precision Time Protocol (PTP), which ensures synchronization of DS-TT and, in particular, TSN applications. One of the configuration parameters is the PTP profile (defined in Section 20.3.3 of IEEE Std 1588-2019). Each PTP profile defines a set of parameters to support applications with more or less stringent synchronization accuracy.
[0232] According to an aspect of the present invention, the need for a PDC may be determined based on PTP profile parameters provided by a PMIC message.
[0233] When the UE determines the need for time synchronization, it notifies the gNB of the time synchronization request so that the gNB can configure and activate the time synchronization, i.e., send reference time information and optionally perform PDC calculations.
[0234] According to an aspect of the present invention, in response to determining the need for time synchronization, the UE sends a signaling message (e.g., a time synchronization control message) to the gNB to initiate RAN time synchronization.
[0235] Although the present invention has been described above with reference to embodiments and examples, it should be understood that the present invention is not limited to the above embodiments and examples. It will be apparent to those skilled in the art that various changes and modifications can be made without departing from the scope of the present invention, as defined in the appended claims. All features disclosed herein (including the appended claims, abstract, and drawings) and / or all steps of any method or process so disclosed may be combined in any combination, except combinations in which at least some of such features and / or steps are mutually exclusive. Each feature disclosed herein (including the appended claims, abstract, and drawings) may be replaced by an alternative feature serving the same, equivalent, or similar purpose, unless otherwise specified. Thus, unless otherwise specified, each feature disclosed is merely one example of a generic series of equivalent or similar features.
[0236] It should also be understood that the results of any of the above-mentioned comparisons, decisions, evaluations, selections, executions, actions, or considerations, e.g., selections made during the encoding or filtering process, may be indicated in or determinable / inferable from data in the bitstream, e.g., flags or data indicating the results, so that the indicated or determined / inferred results can be used in processing instead of actually performing the comparisons, decisions, evaluations, selections, executions, actions, or considerations, e.g., during the decoding process.
[0237] In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite articles "a" or "an" do not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be used to advantage.
[0238] In the above-described embodiments and examples, the described functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit.
[0239] Computer-readable media may include computer-readable storage media, which correspond to tangible media such as data storage media, or communication media, including any medium that facilitates transfer of a computer program from one place to another, for example, according to a communications protocol. In this manner, computer-readable media may generally correspond to (1) non-transitory tangible computer-readable storage media or (2) communication media such as signals or carrier waves. Data storage media may be any available medium that can be accessed by one or more computers or one or more processors to obtain instructions, code, and / or data structures for implementing the techniques described in this disclosure. A computer program product may include computer-readable media.
Claims
1. 1. A method for controlling time synchronization in a wireless network including a user equipment (UE) and a base station, comprising: determining a requirement for time synchronization between the UE and the base station; generating a time synchronization control message for controlling a time synchronization process between the UE and the base station based on the determined time synchronization requirement; transmitting the time synchronization control message to the UE; A method comprising:
2. 1. A method for controlling time synchronization in a wireless network including a user equipment (UE) and a base station, comprising: determining a requirement for time synchronization between the UE and the base station; generating a time synchronization control message for controlling a time synchronization process between the UE and the base station based on the determined time synchronization requirement; transmitting the time synchronization control message to the base station; A method comprising:
3. Determining a requirement for time synchronization between the UE and the base station includes: determining that time synchronization between the UE and the base station is required; or determining that time synchronization between the UE and the base station is not required; or determining that time synchronization between the UE and the base station is required with path delay compensation; or determining that time synchronization between the UE and the base station is required without path delay compensation; 3. The method of claim 1 or 2, comprising:
4. generating the time synchronization control message determining when the time synchronization process should be disabled based on the determined time synchronization requirement, and generating the time synchronization control signal accordingly to disable the time synchronization process; or determining when the time synchronization process should be enabled based on the determined time synchronization requirement, and generating the time synchronization control signal for enabling the time synchronization process accordingly; or determining when the time synchronization process should be enabled and path delay compensation should be enabled based on the determined time synchronization requirement, and generating the time synchronization control signal accordingly to enable the time synchronization process and path delay compensation; or determining when the time synchronization process without path delay compensation should be enabled based on the determined time synchronization requirement, and generating the time synchronization control signal accordingly to enable the time synchronization process without path delay compensation; or determining when the time synchronization process is valid and should be changed based on the determined time synchronization requirements, and generating the time synchronization control signal accordingly to change the time synchronization process; 4. The method of claim 1, comprising:
5. generating the time synchronization control message determining when the time synchronization process is enabled and should be changed based on the determined time synchronization requirement, and generating the time synchronization control signal for changing the time synchronization process accordingly, wherein the time synchronization control signal includes information for enabling or disabling path delay compensation, or information for changing a type of path delay compensation if the path delay compensation is enabled.
4. The method according to any one of claims 1 to 3.
6. receiving a message from a core network entity of the wireless network; transmitting the time synchronization control message includes transmitting the time synchronization control message in response to receiving the message.
6. The method according to any one of claims 1 to 5.
7. receiving a message from a core network entity of the wireless network, the message including a duration time value corresponding to a duration time for which a time synchronization process is to be activated; transmitting the time synchronization control message includes transmitting a first time synchronization control message for enabling the time synchronization process, and transmitting a second time synchronization control message for disabling the time synchronization process when the duration time expires.
6. The method according to any one of claims 1 to 5.
8. receiving a message from a core network entity of the wireless network, the message including information indicating a request for the time synchronization between the UE and the base station; determining a request for time synchronization includes determining a request for time synchronization based on the received message; 8. The method according to any one of claims 1 to 7.
9. 9. The method of claim 8 when dependent on claim 2, wherein the message is a Port Management Information Container (PMIC) message that includes an information element indicating a request for the time synchronization between the UE and the base station.
10. 9. The method of claim 8 dependent on claim 2, wherein the message is a synchronization notification including information for enabling or disabling a Device Side-Time Sensitive Network Translator (DS-TT) function associated with the UE.
11. 9. The method of claim 8 dependent on claim 1, wherein the message is a synchronization notification including information elements for indicating a request for the time synchronization between the UE and the base station, a first information element indicating an identity of the UE to be configured, a second information element indicating whether the time synchronization process should be enabled or disabled, and a third information element indicating whether path delay compensation should be enabled or disabled.
12. The method of any one of claims 6 to 8, wherein the message is a message associated with a Packet Data Unit (PDU) session between the UE and the base station.
13. 9. The method according to claim 6, wherein the message is associated with a Packet Data Unit (PDU) session between the UE and the base station, and the message includes at least one of Quality of Service (QoS) information for indicating a Quality of Service (QoS) required for the PDU session and session identity information for indicating whether the PDU session is for Time Sensitive Communication (TSC) for a Time Sensitive Network (TSN) application.
14. 9. The method of claim 1, further comprising detecting a Packet Data Unit (PDU) session for Time Sensitive Communication (TSC) for a Time Sensitive Network (TSN) application, wherein determining a requirement for time synchronization between the UE and the base station is based on the time synchronization requirement of the detected PDU session for a TSC application.
15. 9. The method of claim 1, further comprising: detecting a Packet Data Unit (PDU) session for a Time Sensitive Communication (TSC) for a Time Sensitive Network (TSN) application; and determining a change to the PDU session for the TSC; wherein determining the time synchronization requirement comprises determining a change to the time synchronization requirement based on the change to the PDU session for the TSC.
16. Detecting a PDU session for the TSC, Determining a Quality of Service (QoS) required for a PDU session, and detecting a PDU session for a TSC if the required Quality of Service satisfies a predetermined time delay criterion; or Determining session identity information associated with the PDU session, and detecting a PDU session for a TSC if the session identity information indicates that the PDU session is for a TSC; 16. The method of claim 14 or 15, comprising:
17. receiving a message from a core network entity of the wireless network, the message being associated with a Packet Data Unit (PDU) session between the UE and the base station, the message including Single Network Slice Selection Assistance Information (S-NSSAI) for indicating the request for the time synchronization for the PDU session between the UE and the base station; determining a request for time synchronization includes determining a request for time synchronization based on the S-NSSAI in the received message; 3. The method according to claim 1 or 2.
18. 18. The method of claim 1, wherein the time synchronization control message includes information for controlling activation of the time synchronization process using a specific type of Path Delay Compensation (PDC), the PDC being one of a plurality of types of PDC including Timing Advance (TA) Round Trip Time (RTT) advance compensation.
19. 19. The method of claim 1, wherein the time synchronization control message includes information for enabling or disabling path delay compensation.
20. 20. The method of claim 1, wherein the time synchronization control message includes a field for indicating a type of path delay compensation for the time synchronization process.
21. 21. The method of claim 1, wherein the time synchronization control message includes a first field for controlling the time synchronization process and a second field for indicating whether path delay compensation is enabled or disabled.
22. The method of claim 2 , wherein the time synchronization control message includes a field for indicating a type of path delay compensation supported by the UE.
23. 19. The method of claim 1, wherein the time synchronization control message includes a first field for indicating whether the time synchronization process is in an operational state or a non-operational state, and a second field for indicating whether path delay compensation is in an operational state or a non-operational state.
24. The time synchronization control message is an additional field indicating the type of message for conveying reference time information from the base station to the UE; an additional field indicating the period during which reference time information is transmitted by the base station; an additional field for indicating the type of path delay compensation supported by the UE; an additional field indicating the periodicity with which path delay compensation information is transmitted by the base station; an additional field to indicate the scenario or environment in which the UE is operating; an additional field to indicate whether the UE should follow a timing error, Te-preference; An additional field to indicate the recommended Timing Advance (TA) granularity value; 24. The method of claim 23 when dependent on claim 2, further comprising at least one additional field:
25. 24. The method of claim 23 when dependent on claim 1, wherein the time synchronization control message includes an additional field for indicating a type of path delay compensation for the time synchronization process.
26. 25. The method according to claim 1, wherein the time synchronization control message is an information element (IE) in a UE Assistance Information message.
27. 26. The method of claim 1, wherein the time synchronization control message is a MAC Control Element (MAC-CE) message or an RRC message.
28. 1. A method for controlling time synchronization in a wireless network including a user equipment (UE) and a base station, comprising: receiving a time synchronization control message from the base station; Controlling a time synchronization process based on the received time synchronization control message; A method comprising:
29. Controlling the time synchronization process Enabling the time synchronization process in the UE; or Disabling the time synchronization process in the UE, or Modifying the time synchronization process in the UE by enabling or disabling path delay compensation; 29. The method of claim 28, comprising:
30. 30. The method of claim 28 or 29, wherein the time synchronization control message includes a first field for indicating whether the time synchronization process is operational or inoperative, and a second field for indicating whether path delay compensation is operational or inoperative.
31. 31. The method of claim 30, wherein the time synchronization control message includes an additional field to indicate a type of path delay compensation for the time synchronization process.
32. 1. A method for controlling time synchronization in a wireless network including a user equipment (UE) and a base station, comprising: receiving a time synchronization control message from the UE; and controlling a time synchronization process based on the received time synchronization control message; Controlling the time synchronization process Enabling the time synchronization process in the base station; or Disabling the time synchronization process in the base station, or Modifying the time synchronization process at the base station by enabling or disabling path delay compensation; A method comprising:
33. 33. The method of claim 32, wherein the time synchronization control message includes a first field for indicating whether the time synchronization process is enabled or disabled and a second field for indicating whether path delay compensation is enabled or disabled.
34. The time synchronization control message is an additional field indicating the type of message for conveying reference time information from the base station to the UE; an additional field indicating the period during which reference time information is transmitted by the base station; an additional field for indicating the type of path delay compensation supported by the UE; an additional field indicating the periodicity with which path delay compensation information is transmitted by the base station; an additional field to indicate the scenario or environment in which the UE is operating; an additional field to indicate whether the UE should follow a timing error, Te-preference; An additional field to indicate the recommended Timing Advance (TA) granularity value; 34. The method of claim 33, further comprising at least one additional field:
35. 1. A user equipment (UE) for controlling time synchronization between the UE and a base station of a wireless network, comprising: a communication interface; a processing unit configured to perform the method of any one of claims 2 to 10, 12 to 16, 18 to 24, 26 to 31; and A UE having:
36. 1. A base station for controlling time synchronization between a user equipment (UE) and a base station of a wireless network, the base station comprising: a communication interface; a processing unit configured to perform the method according to any one of claims 1 to 8, 11 to 21, 23, 25, 27, 32 to 34; A base station having
37. A time synchronization control message for controlling time synchronization between a UE and a base station of a wireless network, the time synchronization control message including information for controlling activation of a time synchronization process using a specific type of Path Delay Compensation (PDC), the specific type being one of a plurality of types of PDC including Timing Advance (TA) Round Trip Time (RTT) advance compensation; The time synchronization control message includes a field for indicating whether path delay compensation is enabled or disabled. Time synchronization control messages.
38. 38. The time synchronization control message of claim 37, wherein the time synchronization control message includes a first field for controlling the time synchronization process and a second field for indicating whether path delay compensation is enabled or disabled.
39. 39. The time synchronization control message according to claim 37 or 38, wherein the time synchronization control message includes a field indicating a type of path delay compensation for the time synchronization process.
40. A time synchronization control message for controlling time synchronization between a UE and a base station in a wireless network, the time synchronization control message including a first field for indicating whether a time synchronization process is in an operating state or a non-operating state, and a second field for indicating whether a path delay compensation is in an operating state or a non-operating state.
41. The time synchronization control message is an additional field indicating the type of message for conveying reference time information from the base station to the UE; an additional field indicating the period during which reference time information is transmitted by the base station; an additional field for indicating the type of path delay compensation supported by the UE; an additional field indicating the periodicity with which path delay compensation information is transmitted by the base station; an additional field to indicate the scenario or environment in which the UE is operating; an additional field to indicate whether the UE should follow a timing error, Te-preference; An additional field to indicate the recommended Timing Advance (TA) granularity value; 41. The time synchronization control message of claim 40, further comprising at least one additional field:
42. The time synchronization control message according to claim 40 or 41, wherein the time synchronization control message is an Information Element (IE) in a UE Assistance Information message.
43. The time synchronization control message according to any one of claims 37 to 41, wherein the time synchronization control message is a MAC Control Element (MAC-CE) message or an RRC message.
44. A computer program comprising instructions which, when executed by a computer, cause the computer to carry out the method of any one of claims 1 to 34.
45. 45. A computer readable storage medium carrying a computer program according to claim 44.
Citation Information
Patent Citations
Time synchronization method, UE, base station, equipment and computer readable storage medium
CN111565083A
User equipment and wireless base station
WO2020217480A1