Patent Description:
In a typical wireless communication network, wireless devices, also known as wireless communication devices, mobile stations, stations (STA) and/or User Equipment (UE), communicate via a Local Area Network such as a Wi-Fi network or a Radio Access Network (RAN) to one or more core networks (CN). The RAN covers a geographical area which is divided into service areas or cell areas, which may also be referred to as a beam or a beam group, with each service area or cell area being served by a radio network node such as a radio access node e.g., a Wi-Fi access point or a radio base station (RBS), which in some networks may also be denoted, for example, a NodeB, eNodeB (eNB), or gNB as denoted in <NUM>. A service area or cell area is a geographical area where radio coverage is provided by the radio network node. The radio network node communicates over an air interface operating on radio frequencies with the wireless device within range of the radio network node.

Specifications for the Evolved Packet System (EPS), also called a Fourth Generation (<NUM>) network, have been completed within the 3rd Generation Partnership Project (3GPP) and this work continues in the coming 3GPP releases, for example to specify a Fifth Generation (<NUM>) network also referred to as <NUM> New Radio (NR). The EPS comprises the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), also known as the Long Term Evolution (LTE) radio access network, and the Evolved Packet Core (EPC), also known as System Architecture Evolution (SAE) core network. E-UTRAN/LTE is a variant of a 3GPP radio access network wherein the radio network nodes are directly connected to the EPC core network rather than to RNCs used in <NUM> networks. In general, in E-UTRAN/LTE the functions of a <NUM> RNC are distributed between the radio network nodes, e.g. eNodeBs in LTE or gNBs in <NUM>, and the core network. As such, the RAN of an EPS has an essentially "flat" architecture comprising radio network nodes connected directly to one or more core networks, i.e. they are not connected to RNCs. To compensate for that, the E-UTRAN specification defines a direct interface between the radio network nodes, this interface being denoted the X2 interface.

<NPL>, discloses a system for synchronization distribution.

<NPL>, discloses the generalized precision time protocol (gPTP). It also specifies performance requirements addressing audio and video applications.

<NPL>), discloses a <NUM> System supporting TSN, including functional as well as performance requirements related to TSN use-cases.

Time Sensitive Networking is based on the IEEE <NUM> Ethernet standard. The TSN provides deterministic services through IEEE <NUM> networks, such as e.g. time synchronization, guaranteed low latency transmissions and high reliability to make legacy Ethernet, designed for best-effort communication, deterministic. The TSN features available today may be grouped into the following categories:.

The configuration and management of the TSN network may be implemented in different manners, either in a centralized or in a distributed setup as defined in IEEE <NUM>. The different configuration models are shown in <FIG>, <FIG> and <FIG>. <FIG> shows a distributed TSN configuration model, <FIG> shows a centralized TSN configuration model, and <FIG> shows a fully centralized TSN Configuration Model, as defined in IEEE P802.1Qcc/D2.

The communication endpoints inside the TSN are referred to as Talker and Listener. A TSN network comprises multiple entities and features. All switches, which are referred to as bridges in the <FIG>, in between the Talker and the Listener need to support certain TSN features, like e.g. IEEE <NUM>. 1AS time synchronization. A TSN domain enables synchronized communication among nodes. The communication between Talker and Listener is performed in streams. A stream is based on certain requirements in terms of data rate and latency given by an application implemented at the Talker and/or the Listener. The TSN configuration and management features are used to setup the stream and guarantee the stream's requirements across the network. In the distributed model shown in <FIG>, the Talker and Listener may for example use a Stream Reservation Protocol (SRP) to setup and configure a TSN stream in every switch along the path from Talker to Listener in the TSN network. Nevertheless, some TSN features require a central management entity referred to as Centralized Network Configuration (CNC) tool as shown in <FIG>. The CNC may for example use Netconf and YANG models to configure the switches in the network for each TSN stream. This also allows the use of time-gated queueing as defined in IEEE <NUM>. 1Qbv that enables data transport in a TSN network with deterministic latency. With time-gated queueing on each switch, queues are opened or closed following a precise schedule that allows high priority packets to pass through the switch with minimum latency and jitter if it arrives at ingress port within the time the gate is scheduled to be open. In the fully centralized model, as shown in <FIG>, a Centralized User Configuration (CUC) entity is further added that is used as a point of contact for Listener and Talker. The CUC collects stream requirements and endpoint capabilities from the devices and communicates with the CNC directly. The details about TSN configuration is explained in further detail in IEEE <NUM>.

<FIG> shows a sequence chart of the procedure of TSN stream configuration using the fully centralized configuration model as shown in <FIG>. The steps performed to setup a TSN stream in the TSN network in fully centralized configuration mode are the following:.

In a TSN network, a stream identity (streamID) may be used to uniquely identify stream configurations. It is used to assign TSN resources to a user's stream. The streamlD comprises two tuples, namely:.

In the distributed configuration model as illustrated in <FIG>, there is no CUC and no CNC. The Talker is therefore responsible for initiation of a TSN stream. As no CNC is present, the bridges are configuring themselves which does not allow the use of for example time-gated queuing as defined in <NUM>.

In the centralized model as depicted in <FIG> the Talker is responsible for stream initialization but the bridges are configured by CNC.

To connect devices wirelessly to a TSN network, <NUM> is a promising solution. The <NUM> standard addresses factory use cases through a lot of new features, especially on the RAN to make it more reliable and reduce the transmit latency compared to <NUM>. The <NUM> network comprises three main components, which are the UE, the RAN instantiated as the gNB and nodes, such as a User Plane Function (UPF) within the <NUM> core network (5GCN). The <NUM> network architecture is illustrated in <FIG>. A control plane of the <NUM> network further comprises a Network Repository Function (NRF), an Access Management Function (AMF), a Session Management Function (SMF), a Network Exposure Function (NEF), a Policy Control Function (PCF) and a Unified Data Management (UDF).

An ongoing research challenge is the inter-working of <NUM> and TSN as illustrated in <FIG>. Both technologies define their own methods for network management and configuration and different mechanisms to achieve communication determinism that must somehow be arranged to enable end-to-end deterministic networking for industrial networks. In the following the device connected to the <NUM> network is referred to as <NUM> endpoint. A device connected to the TSN domain is referred to as a TSN endpoint.

Despite what is shown in <FIG> it is also possible that the UE is not connected to a single endpoint but instead to a TSN network comprising of at least one TSN bridge and at least one endpoint. The UE is in such a situation part of a TSN-<NUM> gateway, in which end stations communicate with UEs within the context of a local TSN network that is isolated from the primary TSN network by the <NUM> network.

In the following, an example of how Ethernet transport in a <NUM> system (5GS) according to the scenario shown in <FIG> may work shall be described.

Many TSN features are based on precise time synchronization between all peers. Also, a lot of industrial applications rely on a precise synchronization. As introduced above this is achieved using e.g. IEEE <NUM>. 1AS or IEEE P802.1AS-rev. Within the TSN network it is therefore possible to achieve a synchronization with sub-microsecond error. In order to achieve this level of accuracy a hardware support might be required; e.g. for timestamping of packets.

In the network, a grandmaster (GM) is a node that transmits timing information to all other nodes in a master-slave architecture. The GM may be elected out of several potential nodes, by certain criteria that make the selected grandmaster superior.

In a TSN-extension of <NUM>. 1AS (i.e. P802.1AS-rev), it has been defined that next to a main GM also a second redundant backup GM may be configured. In case the main GM fails for any reason, devices in the TSN domain may be synched to the second redundant GM. The redundant GM might work in a hot-standby configuration.

In TSN based on IEEE P802.1AS-rev, which is also referred to as a generalized Precise Timing Protocol (gPTP) there may be multiple time domains and associated gPTP domains supported in a TSN network. The gPTP supports two timescales:.

Devices in the TSN network may be synched to multiple time domains. A local arbitrary time domain may also be referred to as a working clock.

One of the initial steps for setting up the TSN stream, as explained above, and shown in <FIG>, is the establishment of a TSN domain by the CNC, by grouping endpoints, such as talkers and listeners, that are supposed to exchange time-sensitive streams. This list is provided by the CUC to the CNC. The CNC further configures the bridges connecting these endpoints such that each TSN domain, such as talkers, listeners and bridges, has its own working clock. Technically this may be done according to IEEE P802.1AS-rev, by configuring an external port role configuration mechanism.

<FIG> shows a PTP header used for every PTP packet (note, interpretation of some fields is being revised in the new edition of the IEEE1588 and correspondingly in the IEEE P802.1ASRev). The domain number (domainNumber) defines for each frame, which time domain the frame belongs to. PTP time domains allow using multiple independent PTP clocks on a single network infrastructure. These numbers need to be configured at each end-station so that each end-station is aware about which time domain it requires.

The PTP header in <FIG> comprises the following fields:.

As per IEEE P802.1AS-Rev/D7. <NUM>, it is specified that the destination address of announce and signaling messages shall be reserved a multicast address <NUM>-<NUM>-C2-<NUM>-<NUM>-0E. Furthermore, also the destination MAC address of SYNC, Follow-Up, Pdelay_Request, Pdelay_Response and Pdelay_Response_Follow_Up which are all used for peer-to-peer synchronization shall be reserved the multicast address <NUM>-<NUM>-C2-<NUM>-<NUM>-0E. It shall be noted that as per IEEE802.1Q, frames with this address may never be forwarded, non-forwardable address, but must be terminated by the bridge. As Source address they shall use the MAC address of any egress physical port.

As introduced above, the TSN domain works with different clocks, such as e.g. global and working clocks. Furthermore, the clocks of each TSN domain are not necessarily synchronized and a factory network may comprise of several TSN domains. Therefore, across a factory network there might be several independent TSN domains with arbitrary timescales where different maybe overlapping subsets of devices need to be synchronized. As shown in <FIG>, each TSN domain may have its own working clock. <FIG> depicts four TNS domains. Each TSN domain represented by a line/cell also referred to as a working group, has its own working clock. A line/cell when used herein means a group of devices, e.g. robots, in the factory plant, often comprises a single machine or a set of neighbouring machines that physically collaborate, which means all devices within the group need to be synchronized and coordinated.

The four respective TNS domains <NUM>, <NUM>, <NUM> and <NUM> shown in <FIG>, has its own working clock, working clock domain <NUM>, working clock domain <NUM>, working clock domain <NUM>, working clock domain <NUM>.

To satisfy time synchronization requirements for TSN in manufacturing use cases, a cellular network is required to provide a time reference to which all machines, such as e.g. sensors or actuators, can be synchronized. Currently in 3GPP standardization release <NUM> for LTE radio, a mechanism has been developed that allows time synchronization between Base Stations (BSs) and UEs with a sub-microseconds accuracy. It has been proposed in 3GPP RAN <NUM>, to add two Information Elements (IE) into System Information Block (SIB)<NUM>, such as e.g. a time reference with a certain granularity, such as e.g. <NUM>, and uncertainty value, and the DL Radio Resource Control (RRC) message UETimeReference to transmit a GPS time to the UE with three IEs added in an RRC message. The main purpose of this procedure is to transfer GPS based time reference information to UEs along with inaccuracy of that information.

LTE defines several SIBs, related to timing information in SIB <NUM> or any other suitable SIBx, which contains information related to GPS time and Coordinated Universal Time (UTC). The SIBs are transmitted over a Downlink Shared Channel (DL-SCH). The presence of a SIB in a subframe is indicated by the transmission of a corresponding Physical Downlink Control Channel (PDCCH) marked with a special System-Information RNTI (SI-RNTI). The Information Element (IE) SIB <NUM> contains information related to GPS time and UTC. The UE may use the parameter blocks to obtain the GPS and the local time.

The structure of the SIB <NUM> message is shown below:
<IMG>.

Another way of providing time synchronization may be to use a time reference information message in RRC signaling to transmit the GPS time to the UE.

The release <NUM> work is ongoing and different options are discussed to address the needs for time synchronization as required by TSN and industrial applications. Especially the support of multiple time domains in <NUM> is an open topic.

An object of embodiments herein is to improve the way of handling BWP a wireless communications network.

According to an aspect of embodiments herein, the object is achieved by a method performed by a transmitting device, in a 3GPP wireless communication system, for handling generalized Precise Timing Protocol, gPTP, signaling, from a Time Sensitive Network, TSN. The transmitting device receives a gPTP frame from the TSN network. The gPTP frame comprises time information, an indication of a time domain related to the time information and/or a Medium Access Control, MAC, address of a second end station connected to a receiving device. Based on the indication of the time domain and/or the MAC address, the transmitting device determines the receiving device which the gPTP frame relates to. The transmitting device transmits to the determined receiving device, the gPTP frame in a PDU session related to the determined receiving device.

According to another aspect of embodiments herein, the object is achieved by a method performed by a receiving device, in a 3GPP wireless communication system, for handling generalized Precise Timing Protocol, gPTP, signaling, from a Time Sensitive Network, TSN. The receiving device receives a PDU session from a transmitting device. The PDU session comprises a gPTP frame which in turn comprises a time information an indication of a time domain related to the time information and/or a Medium Access Control, MAC, MAC, address of one or more second end stations connected to a receiving device. The receiving device determines, based on the indication of the time domain and/or the MAC address, one or more second end stations in the TSN network to transmit the received gPTP frame to. The receiving device transmits the gPTP frame to the one or more second end stations in the TSN network. The gPTP frame comprises the time information and the time domain related to the time information extracted from the 3GPP message.

According to another aspect of embodiments herein, the object is achieved by a transmitting device in a 3GPP wireless communication system, for handling generalized Precise Timing Protocol, gPTP, signaling, from a Time Sensitive Network, TSN. The transmitting device is configured to:.

According another an aspect of embodiments herein, the object is achieved by a receiving device in a wireless communication system, for handling generalized Precise Timing Protocol, gPTP, signaling, from a Time Sensitive Network, TSN. The receiving device is configured to:.

It is herein assumed that gPTP frames are transmitted transparently through the <NUM> network. This may involve a timestamping of packets at the ingress and afterwards at the egress to be able to correct the time carried in the gPTP frames.

The overall behavior may be described as gPTP frames being carried as Ethernet frames through the <NUM> network. In reality new gPTP frames must be regenerated at the egress points of the <NUM> system. In this case the 5GS does not participate in the IEEE802.1AS Best Mast Clock Algorithm (BMCA)s. An accurate transport of time information in gPTP frames may involve any kind of timestamping of gPTP frames at any point in the 5GS based on a common <NUM> time shared by all nodes in the 5GS.

gPTP messages are sent to synchronize slaves to a master. In gPTP, for example domain numbers are used to establish multiple time domains in parallel in a network. These numbers help a slave to synchronize its clock to a certain time domain master. Until now, there is no way a <NUM> system can efficiently support multiple time domains as required by industrial automation applications. This is particularly important in case a large number of domains need to be supported, such as e.g. <NUM> domains, and a large number of UEs are connected to the <NUM> system.

Depending on how time signals are transported in the 5GS, and especially what transmission type (Broadcast, Multicast, Unicast) is chosen at the RAN, RAN knowledge about which UE needs which time domain signal may be very important. This is however not supported today.

The embodiments herein provide a method by which a UE and a BS such as a radio network node, e.g. a gNB, can provide multiple time signals to e.g. a TSN application running either on UE side or BS side and then let the 5GS know to which time domain a signal belongs to.

<FIG> depicts an example of a communications network <NUM> according to a first scenario in which embodiments herein may be implemented. The communications network <NUM> is a wireless communication network such as e.g.an 5GS, an LTE, E-Utran, WCDMA, GSM network, any 3GPP cellular network, Wimax, or any cellular network or system.

The communications network <NUM> comprises a Radio Access Network (RAN) and a Core Network (CN). The communication network <NUM> may use a number of different technologies, such as Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, <NUM>, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/Enhanced Data rate for GSM Evolution (GSM/EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations.

In the communication network <NUM>, one or more UEs <NUM> may communicate via one or more Access Networks (AN), e.g. RAN, to one or more CNs. The UE <NUM> may e.g. be a wireless device (WD), a mobile station, a non-access point (non-AP) STA, a STA, and/or a wireless terminal. It should be understood by those skilled in the art that "wireless device" is a non-limiting term which means any terminal, wireless communication terminal, user equipment, Machine Type Communication (MTC) device, Device to Device (D2D) terminal, or node e.g. smart phone, laptop, mobile phone, sensor, relay, mobile tablets or even a base station communicating within a cell.

The UEs <NUM> may each be connected to one or more end stations such as one or more second end station. The second end station may e.g. be robots on a factory floor. In some embodiments, the UE <NUM> is connected to a group of end stations. One example of implementation may be a group of end stations being connected to a bridge, which bridge is connected to the UE <NUM>.

The RAN comprises a set of radio network nodes, such as network nodes <NUM>, <NUM> each providing radio coverage over one or more geographical areas, such as a cell <NUM>, <NUM> of a radio access technology (RAT), such as <NUM>, LTE, UMTS, Wi-Fi or similar. The radio network node <NUM>, <NUM> may be a radio access network node such as radio network controller or an access point such as a wireless local area network (WLAN) access point or an Access Point Station (AP STA), an access controller, a base station, e.g. a radio base station such as a gNB, a NodeB, an evolved Node B (eNB, eNodeB), a base transceiver station, Access Point Base Station, base station router, a transmission arrangement of a radio base station, a stand-alone access point or any other network unit capable of serving a wireless device within the cell, which may also be referred to as a service area, served by the radio network node <NUM>, <NUM> depending e.g. on the first radio access technology and terminology used.

The CN further comprises a core network node <NUM> which is configured to communicate with the radio network nodes <NUM>, <NUM>, via e.g. an S1 interface. The core network node may e.g. be a Mobile Switching Centre (MSC), a Mobility Management Entity (MME), an Operations & Management (O&M) node, an Operation, Administration and Maintenance (OAM) node, an Operations Support Systems (OSS) node and/or a Self-Organizing Network (SON) node. The core network node <NUM> may further be a distributed node comprised in a cloud <NUM>.

The UE <NUM> is located in the cell <NUM> of the network node <NUM>, which is referred to as the serving cell, whereas the cell <NUM> of the network nodes <NUM> are referred to as neighboring cells. Although, the network node <NUM> in <FIG> is only depicted providing a serving cell <NUM>, the network node <NUM> may further provide one or more neighboring cells <NUM> to the serving cell <NUM>.

The communications network <NUM> may according to some embodiments herein communicate with nodes in an external TSN network. The TSN network may be connected to one or more end stations such as a second end station.

Note that although terminology from 3GPP <NUM> and LTE has been used in this disclosure to exemplify the embodiments herein, this should not be seen as limiting the scope of the embodiments herein to only the aforementioned system. Other wireless systems, including WCDMA, WiMax, UMB, GSM network, any 3GPP cellular network or any cellular network or system, may also benefit from exploiting the ideas covered within this disclosure.

In the following, the embodiments herein will be described in further detail. In the below example, the wireless communications network is represented by 5GS.

According to some of the embodiments herein the 5GS such as a transmitting device in 5GS, may receive gPTP messages from an external network, such as a TSN network, in which e.g. a Grandmaster (GM) is deployed. The gPTP messages from the GM may be received either on a UE, such as the UE <NUM>, or UPF side of the 5GS.

As multiple time domains are used in industrial networks, such TSN networks, as introduced above, there may be multiple signals arriving at the 5GS.

In the embodiments herein it is assumed that the gPTP frames are transparently transported in the 5GS. The wording "transparently transported in the 5GS" when used herein means that the gPTP frames together with time stampings are encapsulated into GTP-U packets, then they are transported inside 5GS using existing procedures and protocols in the similar way as other data packets. A time stamp is a stamp of a current time.

In this case it is particularly important to know about which nodes require which time domain signals, i.e. gPTP frames carrying to a certain domain Number, for cases where a large number of UEs are connected and a significant number of gPTP domains need to be supported, such as e.g. more than two gPTP domains, which is addressed by embodiments herein. Solutions for both uplink and downlink transmission of time signals are introduced.

The information about the time domains and which UE belongs to which time domain is particularly important for cases where a large number of UEs are connected and a significant number of gPTP domains need to be supported, such as e.g. more than two gPTP domains, which is addressed by embodiments herein.

The embodiments herein have the benefit that they allow end-to-end time synchronization with multiple time-domains. Thereby the 5GS system is now able to forward time signals from multiple time domains efficiently.

First embodiments herein will be described in a more general way together with <FIG> and <FIG>. Then embodiments herein will be further exemplified and described more in detail together with <FIG>.

<FIG> depicts methods according to example embodiments herein seen in the respective view of a transmitting device.

<FIG> depicts methods according to example embodiments herein seen in the respective view of a sending device.

The transmitting device may e.g. be a transmitting device X010, such as e.g. the UE <NUM> during UL transmissions or the network node <NUM> or the UPF during DL transmissions.

The receiving device is connected to one or more second end stations. The receiving device may e.g. be a receiving device X020, such as e.g. the UE <NUM> connected to one or more second end stations during DL transmissions, or the radio network node <NUM> or the UPF connected to the one or more second end stations during UL transmissions.

According to a first example scenario relating to DL, a gPTP frame e.g. generated from a GM, is to be transmitted from the TSN network, via the transmitting device such as a network node <NUM> or the UPF in the 5GS network to the receiving device such as the UE <NUM> in the 5GS network to be forwarded to the second end station in this example operating connected to the receiving device such as the UE <NUM> in the 5GS network.

According to a second example scenario relating to UL, a gPTP frame is to be transmitted from a first end station connected to the transmitting device such as the UE <NUM>, via the transmitting device such as the UE <NUM> in the 5GS network to the receiving device such as the radio network node <NUM> or the UPF in the 5GS network to be forwarded to the second end station, in this example operating in the TSN network.

The TSN network uses multiple working clock domains, whereof one or more working clock domains are related to the gPTP frame.

When TSN uses multiple clock domains, the gPTP messages are coming from different working clock domains. One gPTP frame is only belonging to one working clock domain.

The wording "packets at ingress of a node" when used herein refers to any node(s) at <NUM> system that receives gPTP messages from TSN network.

The wording "packets at egress of a node" refers to any node(s) at <NUM> system from which gPTP messages are forwarded to the TSN network.

<FIG> depicts methods according to example embodiments herein seen in the view of a transmitting device. <FIG> illustrates method actions performed by a transmitting device in a wireless communication system <NUM>. The method is for handling gPTP signaling from the TSN.

The transmitting device may e.g. be the UE <NUM>, the network node <NUM>, the UPF and/or a translator function. The wireless communication system <NUM>, may as mentioned above e.g. be a 3GPP wireless communication system <NUM>, such as e.g. the <NUM> system.

The method may comprise one or more of the following actions which actions may be taken in any suitable order.

The transmitting device receives the gPTP frame from the TSN, e.g. generated from GM in the TSN network. The wording "gPTP frame" when used herein may be interpreted as an Ethernet frame that comprises a gPTP message.

The gPTP frame may e.g. be an Announce message or a sync message. The gPTP frame is to be transmitted to a second end station connected to a receiving device such as e.g. a UE such as the UE <NUM>. The transmitting device does not yet know who the receiving device is.

The gPTP frame comprises time information, and one of an indication of a time domain related to the time information or a MAC address of a second end station connected to a receiving device. This may mean that the gPTP frame may comprise any one out of:.

The transmitting device determines the receiving device which the gPTP frame relates to, based on the indication of the time domain and/or the MAC address.

When the transmitting device by some means may know some indications such as e.g. the second end station wanted domain indicator, then the UPF may determine the receiving device. If such a indication is not available, then the transmitting device will send all gPTP frames that is coming from different time domains to the UEs such as the UE <NUM>, it is connected to.

In some embodiments, the transmitting device determines the receiving device which the gPTP frame relates to by obtaining information regarding the time domain to which the receiving device and/or one or more second end stations connected to the receiving device are related. The transmitting device obtains the information by receiving the information from the receiving device. The transmitting device may obtain the information by receiving a pre-configuration indicating which receiving devices are related to a specific time domain. The transmitting device may further obtain the information regarding the time domain supported by the one or more second end stations in the TSN, by receiving information from a TSN network controller, wherein the information comprises a receiving device identifier, such as e.g. a UE identifier, or a MAC address of the one or more second end stations.

The transmitting device further determines the receiving device which the gPTP frame relates to, by determining that the received gPTP frame relates to a receiving device when the indication of the time domain or the MAC address comprised in the gPTP frame corresponds to the obtained information regarding the time domain to which the receiving device and/or the one or more second end stations connected to the receiving device are related.

Action <NUM>: The transmitting device may further set a first time stamp on the gPTP frame when the gPTP frame is received by the transmitting device, also referred to as time stamp ingress.

When transmitted, an egress time stamp is set, also referred to as recorded. The egress time stamp is not included in the gPTP frame. The time stamp information may not be a part of the gPTP frame which is different from when receiving it. When receiving the gPTP frame, the time stamp is set and included inside gPTP frame.

The first time stamp may be used to calculate a correction time for compensating for varying delays in the 3GPP wireless communication system <NUM>. This is in order to be able to "transparently" carry the PTP time information across the 5GS, such as e.g., acting as a distributed transparent clock, or equalizing the delays on both directions so as to create a symmetric channel. It is the different between first time stamp and a second time stamp that may be used as a correction time.

In some embodiments, the gPTP message will be updated, i.e. modified with the egress timestamping (TSe) minus the ingress timestamping (TSi), i.e. the <NUM> residence time, and all <NUM> nodes are using the same time grand master. The difference between TSi and TSe is considered as the calculated residence time spent within the <NUM> system for this gPTP message expressed in 5GS time. In this way, the modified gPTP message may pass through the <NUM> system via the normal PDU session. All <NUM> nodes may use the same GM, which is <NUM> GM. The first time stamp may be set at the <NUM> transmitting side, the second time stamp may be set at <NUM> the receiving side. Between <NUM> transmitting and receiving, a PDU session is used. After correction, the modified gPTP is sent to the second end stations at the receiving side.

Action <NUM>: The transmitting device transmits the gPTP frame to the determined receiving device, such as e.g. the radio network node <NUM> or the UPF in UL and/or the UE <NUM> in DL. The gPTP frame is transmitted in a PDU session related to the determined receiving device. The transmitting device may be a radio network node or a UPF, and the gPTP frame may be transmitted using broadcasting. The transmitting device may further transmit the gPTP frame using multicasting or unicasting.

In the embodiments where the gPTP message was modified with the TSe-TSi, i.e. the <NUM> residence time, the modified gPTP message will pass through the <NUM> system via the normal PDU session.

<FIG> depicts the methods according to example embodiments herein seen in the view of a receiving device. <FIG> illustrates the method actions performed by the receiving device, such as e.g. the UE <NUM>, the radio network node <NUM>, the UPF and/or the translator function, in the 3GPP wireless communication system <NUM>, such as e.g. the <NUM> system, for handling gPTP signaling from the TSN. The receiving device may herein also be referred to as a receiving entity.

The receiving device receives, from the transmitting device, such as e.g. the radio network node <NUM>, the UPF and/or the UE <NUM>, a PDU session comprising a gPTP frame. The gPTP frame in turn comprises a time information, and at least one of an indication of a time domain related to the time information or a MAC address of one or more second end stations connected to the receiving device. The PDU session may be received using multicasting, unicasting or broadcasting.

The receiving device determines, based on the indication of the time domain and/or the MAC address, one or more second end stations in the TSN network to transmit the received gPTP frame to.

When the PDU session is received, e.g. as a broadcasted message, the receiving device may further obtain information regarding the time domain supported by the one or more second end stations in the TSN network, which end stations are connected to the receiving device. The information regarding the time domain supported by the end stations in the TSN, may e.g. be obtained by receiving a gPTP message, such as e.g. a gPTP Announce message, delivered periodically by the one or more second end stations. The information regarding the time domain supported by the one or more end stations in the TSN, may in a further embodiment be obtained by receiving information from a TSN network controller, wherein the information comprises a receiving device identifier, such as e.g. a UE identifier, or a MAC address of the one or more second end stations.

The receiving device may further set a second time stamp on the gPTP frame when the PDU session comprising the gPTP frame is received and/or the gPTP frame is transmitted by the receiving device. The second time stamp may be used in combination with the first time stamp received on the gPTP frame, to calculate a correction time for compensating for varying delays in the 3GPP wireless communication system <NUM>.

The receiving device transmits the gPTP frame to the one or more second end stations in the TSN network. The gPTP frame comprises the time information and the time domain related to the time information comprised in the PDU session.

The receiving device may transmit, to the one or more second end stations, the broadcasted time information when the broadcasted PDU session relates to a time domain supported by the one or more second end stations of the TSN, based on the information obtained in action <NUM>. Hence, broadcasted time information relating to just the time domain supported by the end station of the TSN which is connected to the receiving device will be transmitted to the end station by the receiving device.

Embodiments herein may be implemented in the <NUM> network being designed to support various industry use cases such as replacing the wires for controlling endpoints such as the robots on the factory floor. Those kinds of control systems require very strict latency demands on the control data, which the <NUM> system is designed for. Further, the robots also often needs to be synchronized and hence are connected to a TSN. The TSN requires that the end-stations, e.g. robots are synchronized. The synchronization is done using gPTP, which carries various messages in order to provide the synch.

According to an example embodiment herein, the gPTP messages that are received at the network node <NUM>, UPF or the UE <NUM>, include a Time Translator. The gPTP message will be altered with the ingress and egress times of the message arrival time. At respective <NUM> endpoint such as the UE <NUM>, the network node <NUM> or the UPF, the gPTP message will be updated with the TSe-TSi, i.e. the <NUM> residence time, and all <NUM> nodes are using the same time grand master. The modified gPTP message will pass through the <NUM> system via the normal PDU session.

In the following, the embodiments herein will be described and explained in further detail.

The 5GS forwards gPTP frames end-to-end, i.e. a TSN source node, such as e.g. the first end station, supporting a given working clock exchanges gPTP frames with a receiving UE, such as e.g. the UE <NUM>, or with an receiving end station, such as e.g. the second end station, associated with that UE, which gPTP frames carry time information. Each gPTP frame may comprise the domainNumber header field which indicates the time domain the gPTP frame belongs to. The gPTP frames may need to be transported in PDU sessions to a UE, such as e.g. the UE <NUM>, or to a plurality of UEs. The details of the related solutions depend on the specific mechanism that is implemented in order to "transparently" carry the PTP time information across the 5GS, such as e.g., acting as a distributed transparent clock, or equalizing the delays on both direction so as to create a symmetric channel. In this case there is no need for the 5GS to participate in the BMCA.

In case a broadcast of gPTP frames is performed in the 5GS instead, e.g. by means of the gNB, such as the network node <NUM>, then the UE, such as e.g. the UE <NUM>, or UEs need to decide whether they are listening to a certain broadcast or not. This may be performed in a similar manner as in the first embodiment above by checking whether any device connected to the UE sends Announce messages belonging to a specific PTP domain. The UE may not listen to the specific gPTP time domain broadcast any longer or not forward any gPTP frames if the connected end stations or end stations is/are not operating in this PTP domain. This is illustrated in <FIG> for the case where the UE forwards all broadcasted gPTP frames or <FIG> where the UE only forwards relevant gPTP frames to the respective end stations. The UE may also send for example gPTP frames such as e.g. Announce messages to end-stations to check for replies to certain domain numbers in order to learn which end-stations needs which time domain signal.

According to the example of <FIG>, it is assumed that every UE already is connected to the UPF, e.g. has a PDU session. In DL the case, UPF knows the UEs such as the UE <NUM>, that the UPF is connected to. The UPF may simply forward all gPTP messages from TSN network to all UEs that are connected, similar to multicast/broadcast.

Every UE may have a translator, such as a device-side TSN Translator (see 3GPP TS <NUM>). see <NPL>, Figure <NUM>. <NUM>-<NUM>: System architecture view with 5GS appearing as TSN bridge. The translator may be either standalone or integrated inside UE. The UPF side Translator may be referred to as Network-Side TSN translator.

Ingress frames to the 5GS will carry a multicast destination MAC address - the <NUM> network (for example the UPF) needs to decide to which UE (i.e. PDU sessions) it will forward gPTP frames to; gPTP frames might be detected by the PTP-specific Ethertype field.

In one embodiment, an end station connected to a UE, such as e.g. the UE <NUM>, will generate Announce messages carrying information on the gPTP domain (domainNumber carried in the PTP header) it is operating or a 5GS node may use for example Announce messages to detect the interests of end stations. A node in the 5GS, like for example the UPF may learn which UE, respectively end stations behind a UE, such as e.g. the UE <NUM>, are interested in which gPTP messages and establish for example rules for routing incoming gPTP frames accordingly. Any follow up / sync messages are only transmitted to UEs interested in these gPTP packets, which are these ones that operate in that specific gPTP domain; a UE such as e.g. the UE <NUM>, will transparently forward gPTP messages from an end station or end stations it is connected to, to for example the UPF to learn about end-stations' needs. Example of this embodiment:.

According to another embodiment it may be pre-configured in the <NUM> network, which UEs will receive frames from a specific time domain; the frames may be forwarded in UPF to PDU sessions based on the domainNumber. The SMF may be an entity configuring filters in UPF at setup or modification of PDU sessions. In one way, the 5GS will obtain information from the TSN network about which time domain signal need to be directed to which UE i.e. UE identifier, or MAC address of an end station connected to the UE respectively. This may e.g. obtained from the external TSN CNC towards the Application Function (AF) when the CNC sets up TSN domains in the TSN network. The CNC may announce which time domain signals need to be forwarded to which port, i.e. UE or MAC address. AF may trigger any other core network function to set the right filter or rules in UPF to forward gPTP frames to the right PDU sessions using domainNumbers. This is illustrated in <FIG> below. In detail:.

For all embodiments described above, such as e.g. unicast or broadcast, it is further not relevant how the gPTP are transported in the 5GS, besides whether the gPTP frame is unicasted, multicasted or broadcasted to the UE, such as e.g. the UE <NUM>. This may comprise time stamping of gPTP frames in the 5GS ingress and egress to calculate a correction time and compensate varying delays in the 5GS. This is shown in <FIG>, <FIG> and <FIG> in which the time of the 5GS is added to the message when the message enters the 5GS.

It is not specified whether the 5GS may need to transmit all gPTP packets (Sync, Follow_up, Pdelay_request, Pdelay_response, PDelay_Response_Follow_up, Announce etc.) or just any subset of them over the RAN, like for example only Follow-Up messages containing the actual time stamps and then any not transmitted packet could been created, e.g. on the UE side, to ensure a valid gPTP communication handling with any connected end station. According to one embodiment, at least one gPTP frame will be transmitted periodically carrying all necessary information (domainNumber, timestamp, etc.). The gPTP frames may be transmitted as data packets. Furthermore, it is also possible that an Internet Protocol (IP) is used as for transporting the gPTP frames. All embodiments described herein may be applicable in a similar manner in the case where IP is used above Ethernet on Layer <NUM> (L3).

The translator function as illustrated in <FIG> and <FIG> may be an individual entity or may be part of the UPF function. The translator function may send clock/time domains to UEs via Point-to-Point PDU sessions or may send multiple flows inside the PDU session. The translator function may also be a transmitting device according to the example embodiments described herein. <FIG> shows an example of an embodiment in which the TSN CNC provides input to the UPF and/or the gNB, such as the network node <NUM>, on how to forward the time domain signals. In the scenario shown in <FIG> the gPTP frames are forwarded to the receiving device, such as e.g. the UE <NUM>, by the UPF using unicast and/or multicast.

If the grandmaster is located on the UE side of the 5GS, then the UE, such as e.g. the UE <NUM>, needs to forward the time information to the gNB, such as the network node <NUM>. In this case the UE may be the transmitting device, and the gNB and/or the UPF may be the receiving device. The UE may receive gPTP messages from the TSN and will therefore be time aware. The 5GS may require information regarding the time domains in order to be aware about to which time domain the time information forwarded from the UE belongs to.

The UE may always use unicast to forward gPTP frames to the <NUM> network. Based on the gPTP frame headers, the network is able to determine the time domain. According to one embodiment herein it might not be necessary to transmit all gPTP frames but only a subset and filter others at the UE side. The <NUM> network, for example at the UPF, may re-create any not transmitted gPTP frames.

According to a special case it may be necessary to forward the time signal to another UE instead of to an external TSN network, such as a Data Network. In this case the 5GS may use one of the methods introduced above in relation to the embodiments related to Downlink, obtaining the information regarding the time domain number from the frame headers it receives.

<FIG> is a block diagram depicting the transmitting device X010, such as e.g. the UE <NUM> during UL transmissions or the network node <NUM> or the UPF during DL transmissions, in a 3GPP wireless communication system <NUM>, such as e.g. a <NUM> system, for handling gPTP signaling from a TSN.

The transmitting device X010 may comprise a processing unit <NUM>, such as e.g. one or more processors, a receiving unit <NUM>, a transmitting unit <NUM>, a determining unit <NUM>, an obtaining unit <NUM>, and/or a stamping unit <NUM> as exemplifying hardware units configured to perform the method as described herein for the transmitting device X010.

The transmitting device X010 may be configured to, e.g. by means of the processing unit <NUM> and/or the receiving unit <NUM> being configured to, receive, from a TSN network, a gPTP frame, such as e.g. an Announce message or a sync message, wherein the gPTP frame comprises time information, an indication of a time domain related to the time information and/or a MAC address of a second end station connected to a receiving device.

The transmitting device X010 may be configured to, e.g. by means of the processing unit <NUM> and/or the determining unit <NUM> being configured to, determine, based on the indication of the time domain and/or the MAC address, the receiving device which the gPTP frame relates to.

The transmitting device X010 may be configured to, e.g. by means of the processing unit <NUM> and/or the transmitting unit <NUM> being configured to, transmit, to the determined receiving device, such as e.g. the radio network node <NUM> or the UPF in UL and/or the UE <NUM> in DL, the gPTP frame in a PDU session related to the determined receiving device.

The transmitting device X010 may be configured to, e.g. by means of the processing unit <NUM> and/or the obtaining unit <NUM> being configured to, obtain information regarding the time domain to which the receiving device and/or one or more second end stations connected to the receiving device are related.

The transmitting device X010 may be configured to, e.g. by means of the processing unit <NUM> and/or the obtaining unit <NUM> being configured to, obtain the information regarding the time domain supported by the one or more second end stations in the TSN, by being configured to receive information from a TSN network controller, wherein the information comprises a receiving device identifier, such as e.g. a UE identifier, or a MAC address of the one or more second end stations.

The transmitting device X010 may be configured to, e.g. by means of the processing unit <NUM> and/or the determining unit <NUM> being configured to, determine that the received gPTP frame relates to a receiving device when the indication of the time domain or the MAC address comprised in the gPTP frame corresponds to the obtained information regarding the time domain to which the receiving device and/or the one or more second end stations connected to the receiving device are related.

The transmitting device X010 may be configured to, e.g. by means of the processing unit <NUM> and/or the transmitting unit <NUM> being configured to, transmit, the PDU session comprising the gPTP frame using broadcasting.

The transmitting device X010 may be configured to, e.g. by means of the processing unit <NUM> and/or the transmitting unit <NUM> being configured to, transmit the PDU session comprising the gPTP frame using multicasting or unicasting.

The transmitting device X010 may be configured to, e.g. by means of the processing unit <NUM> and/or the stamping unit <NUM> being configured to, set a first time stamp on the gPTP frame when the gPTP frame is received and/or transmitted by the transmitting device, wherein the first time stamp may be used to calculate a correction time for compensating for varying delays in the 3GPP wireless communication system <NUM>.

The transmitting device X010 may be configured to, e.g. by means of the processing unit <NUM> and/or the obtaining unit <NUM> being configured to, obtain the information regarding the time domain to which the receiving device and/or one or more second end stations connected to the receiving device are related to by being configured to, e.g. by means of the processing unit <NUM> and/or the receiving unit <NUM> being configured to, receive the information from the receiving device.

The transmitting device X010 may be configured to, e.g. by means of the processing unit <NUM> and/or the obtaining unit <NUM> being configured to, obtain the information regarding the time domain to which the receiving device and/or end stations connected to the receiving device are related to by being configured to, e.g. by means of the processing unit <NUM> and/or the receiving unit <NUM> being configured to, receive a pre-configuration indicating which receiving devices are related to a specific time domain.

The embodiments herein may be implemented through a respective processor or one or more processors of a processing circuitry in the transmitting device X010 as depicted in <FIG>, which processing circuitry is configured to perform the method actions according to <FIG> and the embodiments described above for the transmitting device X010.

The embodiments may be performed by the processor together with respective computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the transmitting device X010. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as e.g. a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the transmitting device X010.

The transmitting device may further comprise a memory <NUM>. The memory may comprise one or more memory units to be used to store data on, such as e.g. information regarding the retransmissions, PUSCH resource table, software, patches, system information (SI), configurations, diagnostic data, performance data and/or applications to perform the methods disclosed herein when being executed, and similar.

The method according to the embodiments described herein for the transmitting device X010 may be implemented by means of e.g. a computer program product <NUM>, <NUM> or a computer program, comprising instructions, i.e., software code portions, which, when executed on at least one processor, cause at least one processor to carry out the actions described herein, as performed by the transmitting device X010. The computer program product <NUM>, <NUM> may be stored on a computer-readable storage medium <NUM>, <NUM>, e.g. a disc or similar. The computer-readable storage medium <NUM>, <NUM>, having stored there on the computer program, may comprise instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the transmitting device X010. In some embodiments, the computer-readable storage medium may be a non-transitory computer-readable storage medium. The computer program may also be comprised on a carrier, wherein the carrier is one of an electronic signal, optical signal, radio signal, or a computer readable storage medium.

As will be readily understood by those familiar with communications design, that functions means or units may be implemented using digital logic and/or one or more microcontrollers, microprocessors, or other digital hardware. In some embodiments, several or all of the various functions may be implemented together, such as in a single application-specific integrated circuit (ASIC), or in two or more separate devices with appropriate hardware and/or software interfaces between them. Several of the functions may be implemented on a processor shared with other functional components of the transmitting device X010.

Alternatively, several of the functional elements of the processing means discussed may be provided through the use of dedicated hardware, while others are provided with hardware for executing software, in association with the appropriate software or firmware. Thus, the term "processor" or "controller" as used herein does not exclusively refer to hardware capable of executing software and may implicitly include, without limitation, digital signal processor (DSP) hardware, read-only memory (ROM) for storing software, random-access memory for storing software and/or program or application data, and non-volatile memory. Designers of network nodes or devices will appreciate the cost, performance, and maintenance trade-offs inherent in these design choices.

<FIG> is a block diagram depicting the receiving device X020, such as e.g. the UE <NUM> during DL transmissions or the radio network node <NUM> or the UPF during UL transmissions, in a wireless communication system <NUM>, such as e.g. a <NUM> system, for handling gPTP signaling from a TSN.

The receiving device X020 may comprise a processing unit <NUM>, such as e.g. one or more processors, a receiving unit <NUM>, a determining unit <NUM>, a transmitting unit <NUM>, an obtaining unit <NUM>, and/or a stamping unit <NUM> as exemplifying hardware units configured to perform the method as described herein for the receiving device X020.

The receiving device X020 may be configured to, e.g. by means of the processing unit <NUM> and/or the receiving unit <NUM> being configured to, receive, from a transmitting device, such as e.g. the UE <NUM> during UL and/or the network node <NUM> or the UPF during DL, a PDU session comprising gPTP frame which in turn comprises a time information an indication of a time domain related to the time information and/or a MAC address of one or more second end stations connected to a receiving device.

The receiving device X020 may be configured to, e.g. by means of the processing unit <NUM> and/or the determining unit <NUM> being configured to, determine, based on the indication of the time domain and/or the MAC address, one or more second end stations in the TSN network to transmit the received gPTP frame to.

The receiving device X020 may be configured to, e.g. by means of the processing unit <NUM> and/or the transmitting unit <NUM> being configured to, transmit, to the one or more second end stations in the TSN network, the gPTP frame, wherein the gPTP frame comprises the time information and the time domain related to the time information extracted from the 3GPP message.

The receiving device X020 may be configured to, e.g. by means of the processing unit <NUM> and/or the obtaining unit <NUM> being configured to, obtain, when the PDU session is received as a broadcasted message, information regarding time domain supported by the one or more second end stations in the TSN network, which end stations are connected to the receiving device.

The receiving device X020 may be configured to, e.g. by means of the processing unit <NUM> and/or the transmitting unit <NUM> being configured to, transmit the broadcasted time information to the one or more second end stations, when the broadcasted PDU session relates to a time domain supported by the one or more second end stations of the TSN.

The receiving device X020 may be configured to, e.g. by means of the processing unit <NUM> and/or the obtaining unit <NUM> being configured to, obtain the information regarding the time domain supported by the one or more second end stations in the TSN, by being configured to receive a gPTP message, such as e.g. a gPTP Announce message, delivered periodically by the one or more second end stations.

The receiving device X020 may be configured to, e.g. by means of the processing unit <NUM> and/or the obtaining unit <NUM> being configured to, obtain the information regarding the time domain supported by the one or more second end stations in the TSN, by being configured to receive information from a TSN network controller, wherein the information comprises a receiving device identifier, such as e.g. a UE identifier, or a MAC address of the one or more second end stations.

The receiving device X020 may be configured to, e.g. by means of the processing unit <NUM> and/or the stamping unit <NUM> being configured to, set a second time stamp on the gPTP frame when the PDU session comprising the gPTP frame is received and/or the gPTP frame is transmitted by the receiving device. The second time stamp may be used in combination with the first time stamp received on the gPTP frame, to calculate a correction time for compensating for varying delays in the 3GPP wireless communication system <NUM>.

The embodiments herein may be implemented through a respective processor or one or more processors of a processing circuitry in the receiving device X020 as depicted in <FIG>, which processing circuitry is configured to perform the method actions according to <FIG> and the embodiments described above for the receiving device X020.

The embodiments may be performed by the processor together with respective computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the receiving device X020. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as e.g. a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the receiving device X020.

The receiving device may further comprise a memory <NUM>. The memory may comprise one or more memory units to be used to store data on, such as e.g. information regarding the retransmissions, PUSCH resource table, software, patches, system information (SI), configurations, diagnostic data, performance data and/or applications to perform the methods disclosed herein when being executed, and similar.

The method according to the embodiments described herein for the receiving device X020 may be implemented by means of e.g. a computer program product <NUM>, <NUM> or a computer program, comprising instructions, i.e., software code portions, which, when executed on at least one processor, cause at least one processor to carry out the actions described herein, as performed by the receiving device X020. The computer program product <NUM>, <NUM> may be stored on a computer-readable storage medium <NUM>, <NUM>, e.g. a disc or similar. The computer-readable storage medium <NUM>, <NUM>, having stored thereon the computer program, may comprise instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the receiving device X020. In some embodiments, the computer-readable storage medium may be a non-transitory computer-readable storage medium. The computer program may also be comprised on a carrier, wherein the carrier is one of an electronic signal, optical signal, radio signal, or a computer readable storage medium.

As will be readily understood by those familiar with communications design, that functions means or units may be implemented using digital logic and/or one or more microcontrollers, microprocessors, or other digital hardware. In some embodiments, several or all of the various functions may be implemented together, such as in a single application-specific integrated circuit (ASIC), or in two or more separate devices with appropriate hardware and/or software interfaces between them. Several of the functions may be implemented on a processor shared with other functional components of the receiving device X020.

It shall be noted that the nodes mentioned herein may be arranged as separate nodes or may be collocated within one or more nodes in the communications network. When a plurality of nodes are collocated in one node, the single node may be configured to perform the actions of each of the collocated nodes.

Access network <NUM> comprises a plurality of base stations 1912a, 1912b, 1912c, e.g. the radio network node <NUM>, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 1913a, 1913b, 1913c. Each base station 1912a, 1912b, 1912c is connectable to core network <NUM> over a wired or wireless connection <NUM>. A first UE <NUM>, such as the UE <NUM>, located in coverage area 1913c is configured to wirelessly connect to, or be paged by, the corresponding base station 1912c. A second UE <NUM> in coverage area 1913a is wirelessly connectable to the corresponding base station 1912a.

OTT connection <NUM> may be transparent in the sense that the participating communication devices through which OTT connection <NUM> passes are unaware of routing of uplink (UL) and downlink (DL) communications.

It is noted that host computer <NUM>, base station <NUM> and UE <NUM> illustrated in <FIG> may be similar or identical to host computer <NUM>, one of base stations 1912a, 1912b, 1912c and one of UEs <NUM>, <NUM> of <FIG>, respectively.

Wireless connection <NUM> between UE <NUM> and 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 UE <NUM> using OTT connection <NUM>, in which wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments may improve end-to-end time synchronization with multiple time-domains and thereby provide benefits such as improved performance and efficiency of the communications network, in particular when forward time signals from multiple time domains.

Claim 1:
A method, performed by a transmitting device, in a 3GPP wireless communication system (<NUM>) connected to one or more first end stations, for handling generalized Precise Timing Protocol, gPTP, signaling, from a Time Sensitive Network, TSN, the method comprising:
receiving (<NUM>), from a device in the 3GPP wireless communication system (<NUM>) connected to one or more second end stations in the TSN network, a gPTP frame, wherein the gPTP frame comprises:
- time information; and at least one of
- an indication of a time domain related to the time information;
- a Medium Access Control, MAC, address of the one or more second end stations connected to the receiving device;
determining (<NUM>), based on the indication of the time domain and/or the MAC address, the receiving device to which the gPTP frame relates to;
wherein the step of determining which receiving device the gPTP frame relates to comprises:
obtaining (1302a) information regarding the time domain related to the receiving device and/or one or more second end stations connected to the receiving device, by at least one of,
a) receiving the information regarding the time domain from the receiving device,
b) receiving a pre-configuration indicating which receiving devices are related to a specific time domain and
c) receiving information from a TSN network controller, wherein the information comprises a receiving device identifier:
- a UE identifier; or
- a MAC address of the one or more second end stations,
and wherein the step of determining (<NUM>) comprises determining (1302b) that the received gPTP frame relates to the receiving device when the indication of the time domain or the MAC address comprised in the gPTP frame corresponds to the obtained information regarding the time domain to which the receiving device and/or the one or more second end stations connected to the receiving device are related;
transmitting (<NUM>), to the determined receiving device, the gPTP frame in a PDU session related to the determined receiving device.