Patent Description:
The manufacturing industry is undergoing a digital transformation towards the "Fourth Industrial Revolution" (Industry <NUM>) towards smart manufacturing. Flexible connectivity infrastructure is a key enabler for manufacturing to interconnect machines, products, and all kinds of other devices in a flexible, secure, and consistent manner.

The Third Generation Partnership Project (3GPP) Fifth Generation (<NUM>) system, as an alternative to or complementing the wired connectivity solution, should support new requirements and challenges coming from these vertical domains. 3GPP has a study on Communication for Automation in Vertical Domains (Technical Report (TR) <NUM>), where many use cases from vertical domains are analyzed. Industrial automation applications such as motion control have extremely stringent service requirements on high availability, ultra-reliable, low latency, low jitter, and determinism, e.g., <NUM>-<NUM> milliseconds (ms) end-to-end latency, <NUM>-<NUM> microsecond (µs) packet delay variation.

Today, wireline fieldbus solutions such as PROFINET®, EtherCAT®, and Ethernet/Internet Protocol (IP) are mostly used in the factory shop floor to interconnect sensors, actuators, and controllers in an automation system. Institute of Electrical and Electronics Engineers (IEEE) <NUM> Time-Sensitive Networking (TSN) as a novel technology will be able to provide manufacturing industries with deterministic, guaranteed latencies and extremely low packet loss services through standard IEEE <NUM> networks in the near future. Improved ways of conveying time synchronization are needed.

In the 3GPP standard contribution entitled "<NPL>et al. disclose enablers for time synchronization based on alignment with upcoming IEEE802.1AS-rev, and propose changes to the standard to implement time synchronization at TSN endstation via 5GS.

Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. Systems and methods to enable Fifth Generation (<NUM>) system support for conveying time synchronization are provided.

In particular, the present invention provides method performed by a wireless device, in accordance with claim <NUM>, and a method performed by a node, in accordance with claim <NUM>.

In some embodiments, timing information is included into a General Packet Radio Service Tunneling Protocol (GTP) payload and the wireless device can get timing information directly from the data payload. This minimizes the Radio Access Network (RAN) and/or New Radio Base Station (gNB) impact and adds the potential for multiple time domain support.

In some embodiments, the <NUM> system can relay multiple time domain information to the Industrial End-stations that are belonging to different time domains.

In some embodiments, the first time domain is a <NUM> time domain. In some embodiments, the second time domain is a Time-Sensitive Networking (TSN) time domain.

In some embodiments, conveying information about the second time domain to another node comprises conveying information about the second time domain to an end station in the TSN time domain.

In some embodiments, the message comprises a GTP payload.

In some embodiments, conveying information about the second time domain to another node comprises conveying information about the second time domain to a translator/ adaptor node that can interface between the first time domain and the second time domain.

In some embodiments, the method also includes determining that the received message includes external time domain information by inspecting a field in the received message. In some embodiments, inspecting a field in the received message comprises inspecting an EtherType field in the received message.

In some embodiments, the method also includes receiving a message in the first time domain used by the wireless device, the message comprising external time domain information for at least a third time domain.

In some embodiments, a method performed by a node for conveying external time domain information is provided. The method includes receiving a message in a second time domain based on the external time domain information; determining external time domain information about the second time domain; and conveying information about the second time domain to another node in a first time domain used by the node, the message comprising the external time domain information.

<FIG> illustrates an example of Time-Sensitive Networking (TSN) integration with <NUM>. The timing information from TSN working domain (external clock) is delivered via the UEs to the respective End stations. This external clock is illustrated in the Figures as a dashed clock. This option assumes the <NUM> internal system clock (shown in the Figures as a solid clock) is made available to all nodes in the <NUM> system, thereby allowing the User Plane Function (UPF) (Transport Network Function (TP) function) to relay the TSN external clock along with the information of the time stamp of the TP (using <NUM> internal system clock) to the UE. The <NUM> internal system clock can be made available to the TP function at UPF through the underlying transport network between gNB and UPF. The <NUM> internal system clock can be made available to UE with signalling of time information related to absolute timing of radio frames (i.e., using System information Block (SIB)/Radio Resource Control (RRC) based methods described for LTE Rel-<NUM>).

The timing information (generalized Precision Time Protocol (gPTP) messages, including the information on the incoming sync message timestamping) can be carried from the UPF to the UE as data packets (e.g., payload). As an example, UPF can be configured with packet specific forwarding rules to do that.

Based on the example, for a given Packet Data Unit (PDU) Session (clock update performed for each UE via point-to-point) for that UE, one of the Ethernet destination addresses could be specific to support the gPTP operation (note, as described in IEEE <NUM>, the specific value 0x88F7 for the EtherType field is allocated for the case where Precision Time Protocol (PTP) messages are carried therein and could be used to simplify this operation). In some embodiments, EtherType is a two-octet field in an Ethernet frame. It is used to indicate which protocol is encapsulated in the payload of the frame. In other embodiments, this same information could be carried in a different field or in a different way.

When the timing information (e.g., TSN clock "follow_up" and "sync" messages) arrives at the UE, the UE adjusts the "follow_up" message based on the difference between time stamp of the UPF (TP) and of the UE (in this case taken when the sync message is sent to the End Station). The time stamps of UPF and UE are based on the <NUM> internal system clock.

There are two pieces of timing information available at UPF:.

Those two pieces of information need to be delivered from the UPF to the UE.

There currently exist certain challenge(s). Timing information can be transferred from the UPF to the UE in multiple ways.

All those solutions will have impact on the gNB. Improved ways of conveying time synchronization are needed.

Systems and methods to enable <NUM> system support for conveying time synchronization are provided. In some embodiments, a method performed by a wireless device for conveying external time domain information is provided. The method includes receiving a message in a first time domain used by the wireless device, the message comprising external time domain information; determining information about a second time domain based on the external time domain information; and conveying information about the second time domain to another node. In some embodiments, timing information is included into a GTP payload and the wireless device can get timing information directly from the data payload. This minimizes the RAN and/or gNB impact and adds the potential for multiple time domain support.

<FIG> illustrates one example of a cellular communications network <NUM> according to some embodiments of the present disclosure. In the embodiments described herein, the cellular communications network <NUM> is a <NUM> NR network. In this example, the cellular communications network <NUM> includes base stations <NUM>-<NUM> and <NUM>-<NUM>, which in LTE are referred to as eNBs and in <NUM> NR are referred to as gNBs, controlling corresponding macro cells <NUM>-<NUM> and <NUM>-<NUM>. The base stations <NUM>-<NUM> and <NUM>-<NUM> are generally referred to herein collectively as base stations <NUM> and individually as base station <NUM>. Likewise, the macro cells <NUM>-<NUM> and <NUM>-<NUM> are generally referred to herein collectively as macro cells <NUM> and individually as macro cell <NUM>. The cellular communications network <NUM> may also include a number of low power nodes <NUM>-<NUM> through <NUM>-<NUM> controlling corresponding small cells <NUM>-<NUM> through <NUM>-<NUM>. The low power nodes <NUM>-<NUM> through <NUM>-<NUM> can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like. Notably, while not illustrated, one or more of the small cells <NUM>-<NUM> through <NUM>-<NUM> may alternatively be provided by the base stations <NUM>. The low power nodes <NUM>-<NUM> through <NUM>-<NUM> are generally referred to herein collectively as low power nodes <NUM> and individually as low power node <NUM>. Likewise, the small cells <NUM>-<NUM> through <NUM>-<NUM> are generally referred to herein collectively as small cells <NUM> and individually as small cell <NUM>. The base stations <NUM> (and optionally the low power nodes <NUM>) are connected to a core network <NUM>.

<FIG> illustrates a wireless communication system represented as a <NUM> network architecture composed of core Network Functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point/interface. <FIG> can be viewed as one particular implementation of the system <NUM> of <FIG>.

Seen from the access side the <NUM> network architecture shown in <FIG> comprises a plurality of User Equipment (UEs) connected to either a Radio Access Network (RAN) or an Access Network (AN) as well as an Access and Mobility Management Function (AMF). Typically, the R(AN) comprises base stations, e.g., such as evolved Node Bs (eNBs) or <NUM> base stations (gNBs) or similar. Seen from the core network side, the <NUM> core NFs shown in <FIG> include a Network Slice Selection Function (NSSF), an Authentication Server Function (AUSF), a Unified Data Management (UDM), an AMF, a Session Management Function (SMF), a Policy Control Function (PCF), and an Application Function (AF).

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

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

The core <NUM> network architecture is composed of modularized functions. For example, the AMF and SMF are independent functions in the control plane. Separated AMF and SMF allow independent evolution and scaling. Other control plane functions like the PCF and AUSF can be separated as shown in <FIG>. Modularized function design enables the <NUM> core network to support various services flexibly.

<FIG> illustrates a <NUM> network architecture using service-based interfaces between the NFs in the control plane, instead of the point-to-point reference points/interfaces used in the <NUM> network architecture of <FIG>. However, the NFs described above with reference to <FIG> correspond to the NFs shown in <FIG>. The service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In <FIG> the service based interfaces are indicated by the letter "N" followed by the name of the NF, e.g., Namf for the service based interface of the AMF and Nsmf for the service based interface of the SMF etc. The Network Exposure Function (NEF) and the Network Repository Function (NRF) in <FIG> are not shown in <FIG> discussed above. However, it should be clarified that all NFs depicted in <FIG> can interact with the NEF and the NRF of <FIG> as necessary, though not explicitly indicated in <FIG>.

Some properties of the NFs shown in <FIG> and <FIG> may be described in the following manner. The AMF provides UE-based authentication, authorization, mobility management, etc. A UE even using multiple access technologies is basically connected to a single AMF because the AMF is independent of the access technologies. The SMF is responsible for session management and allocates Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF for data transfer. If a UE has multiple sessions, different SMFs may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF provides information on the packet flow to the PCF responsible for policy control in order to support Quality of Service (QoS). Based on the information, the PCF determines policies about mobility and session management to make the AMF and SMF operate properly. The AUSF supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM stores subscription data of the UE. The Data Network (DN), not part of the <NUM> core network, provides Internet access or operator services and similar.

There are several options for (g)PTP transport. Some embodiments herein relate to two variations. <FIG> illustrates an embodiment where (g)PTP is sent over Ethernet.

When carried over Ethernet, the first byte of the (g)PTP occupies the first byte of the client data field of the ETH frame. The ETH type field is set to 0x88F7 and identifies the client data field as a (g)PTP message.

UPF / UE can use 0x88F7 to detect it is a (g)PTP message. Timing information is transferred as payload, and (g)PTP, TS is handled by a Translator. In this option, the translator/adaptor function between the TSN bridge and the UPF will have the functions to support time stamping and (g)PTP protocol. The translator/adaptor is synced with the <NUM> clock (solid clock). This can be done through underlying transport network. The <NUM> clock can come from gNB to UPF then to translator.

<FIG> illustrates an example of using a suffix in the (g)PTP message to carry the timestamp information. The translator/adaptor function can be either implemented as a standalone entity as <FIG> shows, or it can be included as part of the UPF and the UE as is shown in <FIG>.

<FIG> illustrates an embodiment with a <NUM> blackbox model. In some embodiments, the entire <NUM> system can be kept untouched, therefore there will be minimal impact on the <NUM> system nodes. The translator/adaptor function located at the edge of the <NUM> system can take care of all <NUM>. 1AS related functions. For example, the (g)PTP support, time stamping, and/or Best Master Clock Algorithm (BMCA) can be all implemented in the translator. The translator function can be implemented either as part of UPF/UE, or as a stand-alone entity.

<FIG> illustrates an embodiment where the <NUM> system acts as a compliant TSN "time-aware relay. " In some embodiments, it is a type of "distributed boundary clock" implementation, or in a <NUM>. 1AS term "distributed time-aware relay". In some embodiments, only the network elements at the edges of the <NUM> system (e.g., the UE on the left and the Transport Network Function (TP) of the UPF on the right) need to support the IEEE <NUM>. 1AS operations. The <NUM> internal system clock will keep these network elements synchronized so that the timestamping of the gPTP event messages is done correctly. In some embodiments, the <NUM> system has to properly handle the BMCA (in particular, handling the gPTP Announce messages) in order to properly set up the state of the (g)PTP ports and select the Grand Master (GM). The location of BMCA function can be implementation independent. Given the specific operation described by the IEEE <NUM> AS, the actual timing operation consists in the processing of the correction field in the sync message (as well as of the proper handling of the peer-to-peer delay operations). The correct operation is guaranteed by keeping the UE clock and the TP clock supporting the UPF, synchronous among them (in this case synchronous to the <NUM> internal system clock).

In some embodiments, the timing information from TSN working domain (external clock) is delivered via the UEs to the respective End stations. In some embodiments, this option assumes the <NUM> internal system clock (solid clock) is made available to all nodes in the <NUM> system, thereby allowing the UPF (and/or TP function) to relay the TSN external clock along with the information of the time stamp of the TP (using <NUM> internal system clock) to the UE. The <NUM> internal system clock can be made available to the TP function at UPF through the underlying transport network between gNB and UPF. The <NUM> internal system clock can be made available to the UE with signalling of time information related to absolute timing of radio frames (e.g., using SIB/RRC based methods described for LTE Rel-<NUM>). The timing information (gPTP messages, including the information on the incoming sync message timestamping) can be carried from the UPF to the UE as data packets (e.g., payload). As an example, the UPF can be configured with packet specific forwarding rules to do that. For a given PDU Session for that UE, one of the destination addresses could be specific to support the gPTP operation (note, in some embodiments, a specific Ethertype is allocated to (g)PTP messages and could be used to simplify this operation). In some embodiments, when the timing information (e.g., TSN clock "fol|ow_up" and "sync" messages) arrive at the UE, the UE adjusts the "follow_up" message based on the difference between time stamp of the UPF (TP) and of the UE (in this case taken when the sync message is sent to the End Station). The time stamp of UPF and UE are based on the <NUM> internal system clock.

<FIG> illustrates an example of how <NUM> system can transparently convey the TSN timing to the UE. There are two time domains in the figure, the <NUM> time domain (solid clocks) and TSN time domain (dashed clocks). The <NUM> system is modelled as one transparent clock.

The <NUM> system has its own clock reference, e.g., a <NUM> Grand Master (GM), serving for the radio related functions. gNBs are synchronized with the <NUM> GM. The <NUM> clock can be made available for UEs with signalling of time information related to absolute timing of radio frames. In some embodiments, the transport network function (TP) of UPF can be synchronized with the <NUM> clock through underlayer transport network between gNB and UPF using (g)PTP. In some embodiments, the transport network function (TP) of the UPF performs time stamping using <NUM> clock when (g)PTP flow enter the TP.

The TSN bridge and end stations belong to the same TSN working time domain. The bridge and end station on the right side of the <NUM> system are synchronized with TSN GM. In order to transfer the TSN timing from the bridge to the End station on the left side of <NUM> system, the <NUM> system in the example is modelled as a transparent clock such as defined in IEEE <NUM>. In these embodiments, the bridge port connected to the UPF is acting as master, the End station act as Slave Only Ordinary Clock (SOOC) connected to the UE. In these embodiments, the UPF can timestamp the incoming (g)PTP messages from the TSN bridge and relay the stamped time together with TSN timing information to the UE as part of data transmission. In some embodiments, the UE adjusts the TSN "follow_up" message with the difference between time stamp of the UPF (TP) and the UE at arrival of the TSN clocks.

It should be noted that IEEE <NUM>. 1AS does not describe the use of (g)PTP clocks compliant with the operation of an IEEE <NUM> transparent clocks. In fact, in gPTP there are only two types of time-aware systems: time-aware end stations and time-aware relays, while IEEE <NUM> has ordinary clocks, boundary clocks, end-to-end transparent clocks, and P2P transparent clocks. A time-aware end station corresponds to an IEEE <NUM> ordinary clock, and a time-aware relay is a type of IEEE <NUM> boundary clock.

In some embodiments, another way to implement the transparent sync channel is by equalizing the delays in both directions of the <NUM> system (e.g., uplink and downlink). In practice the <NUM> system emulates the behavior of a (direct) (g)PTP link.

In some embodiments, there could also be a new GTP-U Message Type Value. (g)PTP packets can be embedded within Ethernet PDUs using a Type field = 0x88F7 (PTP over Ethernet per IEEE <NUM>) and delivered to the UPF. The UPF normally deals with the delivery of Ethernet PDU containing user plane payload (i.e., UE specific Ethernet PDUs) whereas in this case the UPF is required to relay non-device specific control information (i.e., working clock information carried within an Ethernet PDU) to a gNB for further distribution to UEs. One possible solution can be as follows:.

The same embodiments described herein can also be applied to multidomain use cases. In some embodiments, an industrial automation network consists of two or more time domains. Therefore, the integration of <NUM> in industrial automation requires that the <NUM> system shall be able to support different time domains for synchronization. <FIG> illustrates an example of three time domains in an industrial automation network. In part (A) of <FIG>, the first time domain is "universal time domain" which is used to align operations and events chronologically in the factory. There are also two working clock domains that consists of one or a set of machines. Different working clock domains may have different timescales and synchronisation accuracy.

Due to the mobility, different working clock domains may interact with each other. Part (B) of <FIG> illustrates an embodiment where the Working Clock domains merge into one. Part (C) of <FIG> illustrates an embodiment where the members of the different Working Clock domains interact while keeping their own separate time synchronizations.

In some embodiments, a single clock domain is sufficient and a suitable one could be provided by the <NUM> system itself (in fact, it normally has to operate synchronous with an internationally recognized standard such as GPS).

In some embodiments, the UE only receives <NUM> timing information through the gNB, and acts as the master clock to the TSN end stations. In some embodiments, the TSN bridges and End stations also receive timing information from the <NUM> GM via UPF and under layer transport network. Therefore, all connected domains are locked to the 5GS clock (same universal time; all working clock domains synchronous to the universal time).

In this case, each interface of the <NUM> system is seen by the connected TSN networks and by the End stations, as separate GMs, each of them operating in independent gPTP domains, but providing the same time to all the connected networks. For example, the <NUM> clock at the transport function (TP) of the UPF is acting as TSN GM and provides GM reference to the TSN Work Domains <NUM> and <NUM>. The <NUM> clock at UEs acts as TSN GM for the End stations that belong to TSN Work Domains <NUM> and <NUM> respectively. <FIG> illustrates an embodiment with two external clocks, according to some embodiments of the present disclosure.

<FIG> illustrates an embodiment with two external clocks (illustrated as a dashed clock similar to the previous figures and a clock with smaller dashes). Messages associated with the first external clock and the second external clock may be differentiated by the (g)PTP domainNumber attribute. The UE translator will handle both (g)PTP instances; one takes care of the first external clock domain, one takes care of the second external clock domain While only two external clocks are shown for simplicity, this disclosure is not limited thereto. In some embodiments, the End Stations select (g)PTP messages based on domainNumber.

An alternative option can be an implementation with <NUM> blackbox model as described above. In such an implementation, the entire <NUM> system can be kept untouched, therefore there will have minimal impact on the <NUM> system nodes. The translator/adaptor function located at the edge of <NUM> system can take care all <NUM>. 1AS related functions. For example, the (g)PTP support, time stamping, can be all implemented in the translator. The translator function can be implemented either as part of UPF/UE, or as a stand-alone entity.

<FIG> illustrates an example where an End Station A is communicating time synchronicity to an End Station B, both of which are in a TSN time domain. In this embodiment, the <NUM> system contributes to this End-to-End (E2E) synchronicity requirement by operating as an ingress and egress. As shown in <FIG>, in this embodiment, the UE acts as the ingress to the <NUM> system while the 5GC acts as the egress from the <NUM> system. Any of the embodiments discussed above could be used to communication this time related information.

<FIG> is a schematic block diagram of a translator node <NUM> according to some embodiments of the present disclosure. The translator node <NUM> may be, for example, a base station <NUM> or <NUM>. As illustrated, the translator node <NUM> includes a control system <NUM> that includes one or more processors <NUM> (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory <NUM>, and a network interface <NUM>. The one or more processors <NUM> are also referred to herein as processing circuitry. In addition, the translator node <NUM> includes one or more radio units <NUM> that each includes one or more transmitters <NUM> and one or more receivers <NUM> coupled to one or more antennas <NUM>. The radio units <NUM> may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) <NUM> is external to the control system <NUM> and connected to the control system <NUM> via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s) <NUM> and potentially the antenna(s) <NUM> are integrated together with the control system <NUM>. The one or more processors <NUM> operate to provide one or more functions of a translator node <NUM> as described herein. In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory <NUM> and executed by the one or more processors <NUM>.

<FIG> is a schematic block diagram that illustrates a virtualized embodiment of the translator node <NUM> according to some embodiments of the present disclosure.

As used herein, a "virtualized" radio access node is an implementation of the translator node <NUM> in which at least a portion of the functionality of the translator node <NUM> is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the translator node <NUM> includes the control system <NUM> that includes the one or more processors <NUM> (e.g., CPUs, ASICs, FPGAs, and/or the like), the memory <NUM>, and the network interface <NUM> and the one or more radio units <NUM> that each includes the one or more transmitters <NUM> and the one or more receivers <NUM> coupled to the one or more antennas <NUM>, as described above. The control system <NUM> is connected to the radio unit(s) <NUM> via, for example, an optical cable or the like. The control system <NUM> is connected to one or more processing nodes <NUM> coupled to or included as part of a network(s) <NUM> via the network interface <NUM>. Each processing node <NUM> includes one or more processors <NUM> (e.g., CPUs, ASICs, FPGAs, and/or the like), memory <NUM>, and a network interface <NUM>.

In this example, functions <NUM> of the translator node <NUM> described herein are implemented at the one or more processing nodes <NUM> or distributed across the control system <NUM> and the one or more processing nodes <NUM> in any desired manner. In some particular embodiments, some or all of the functions <NUM> of the translator node <NUM> described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) <NUM>. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) <NUM> and the control system <NUM> is used in order to carry out at least some of the desired functions <NUM>. Notably, in some embodiments, the control system <NUM> may not be included, in which case the radio unit(s) <NUM> communicate directly with the processing node(s) <NUM> via an appropriate network interface(s).

In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of translator node <NUM> or a node (e.g., a processing node <NUM>) implementing one or more of the functions <NUM> of the translator node <NUM> in a virtual environment according to any of the embodiments described herein is provided.

<FIG> is a schematic block diagram of the translator node <NUM> according to some other embodiments of the present disclosure. The translator node <NUM> includes one or more modules <NUM>, each of which is implemented in software. The module(s) <NUM> provide the functionality of the translator node <NUM> described herein.

<FIG> is a schematic block diagram of a UE <NUM> according to some embodiments of the present disclosure. As illustrated, the UE <NUM> includes one or more processors <NUM> (e.g., CPUs, ASICs, FPGAs, and/or the like), memory <NUM>, and one or more transceivers <NUM> each including one or more transmitters <NUM> and one or more receivers <NUM> coupled to one or more antennas <NUM>. The transceiver(s) <NUM> includes radio-front end circuitry connected to the antenna(s) <NUM> that is configured to condition signals communicated between the antenna(s) <NUM> and the processor(s) <NUM>, as will be appreciated by on of ordinary skill in the art. The processors <NUM> are also referred to herein as processing circuitry. The transceivers <NUM> are also referred to herein as radio circuitry. In some embodiments, the functionality of the UE <NUM> described above may be fully or partially implemented in software that is, e.g., stored in the memory <NUM> and executed by the processor(s) <NUM>. Note that the UE <NUM> may include additional components not illustrated in <FIG> such as, e.g., one or more user interface components (e.g., an input/output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and/or the like and/or any other components for allowing input of information into the UE <NUM> and/or allowing output of information from the UE <NUM>), a power supply (e.g., a battery and associated power circuitry), etc..

With reference to <FIG>, in accordance with an embodiment, a communication system includes a telecommunication network <NUM>, such as a 3GPP-type cellular network, which comprises an access network <NUM>, such as a RAN, and a core network <NUM>. The access network <NUM> comprises a plurality of base stations 1806A, 1806B, 1806C, such as NBs, eNBs, gNBs, or other types of wireless Access Points (APs), each defining a corresponding coverage area 1808A, 1808B, 1808C. Each base station 1806A, 1806B, 1806C is connectable to the core network <NUM> over a wired or wireless connection <NUM>. A first UE <NUM> located in coverage area 1808C is configured to wirelessly connect to, or be paged by, the corresponding base station 1806C. A second UE <NUM> in coverage area 1808A is wirelessly connectable to the corresponding base station 1806A.

It is noted that the host computer <NUM>, the base station <NUM>, and the UE <NUM> illustrated in <FIG> may be similar or identical to the host computer <NUM>, one of the base stations 1806A, 1806B, 1806C, and one of the UEs <NUM>, <NUM> of <FIG>, respectively.

The wireless connection <NUM> between the UE <NUM> and the base station <NUM> is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE <NUM> using the OTT connection <NUM>, in which the wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments may improve the e.g., data rate, latency, power consumption, etc. and thereby provide benefits such as e.g., reduced user waiting time, relaxed restriction on file size, better responsiveness, extended battery lifetime, etc..

The measurements may be implemented in that the software <NUM> and <NUM> causes messages to be transmitted, in particular empty or'dummy' messages, using the OTT connection <NUM> while it monitors propagation times, errors, etc..

Claim 1:
A method performed by a wireless device (<NUM>) in a telecommunication system (<NUM>) connected to an external (g)PTP domain for conveying external time domain information, the method comprising:
receiving, from a network translator (<NUM>) in the telecommunication system (<NUM>), a Precision Time Protocol, (g)PTP, message originated by the external (g)PTP domain, the (g)PTP message comprising:
a (g)PTP suffix; and
a correction field value, wherein the (g)PTP suffix and the correction field value are modified by the network translator in the telecommunication system (<NUM>);
determining a timestamp delta that indicates a difference between a first timestamp provided in the (g)PTP suffix and a second timestamp provided by the wireless device (<NUM>);
updating the correction field value to include the determined timestamp delta; and
conveying the updated correction field value to an end station.