Patent Description:
For high speed ethernet interfaces, 25Gbps and above, time stamping of ethernet frames can be operationally complex when high accuracy is needed. To manage Bit Error Ratio IEEE <NUM> uses a Forward Error Correction (FEC) sublayer which may alter the time a frame traverses between a reference plane and a generic Reconciliation Sublayer (gRS) layer where TSSI enables timestamping to be performed. Time stamping delay management has not been considered when the FEC operations were defined in the IEEE <NUM>-<NUM> release.

For high order PHY functions with multi lane are addressed in a task force called IEEE802.3cx and which is scheduled to be settled during autumn <NUM>.

Currently, different ethernet component vendors have implemented time stamping with unique proprietary operations for high speed interfaces. Differences in the proprietary time stamping operations can result in a time stamping error of about 100ns or more when two ethernet network nodes communicate using different time stamping operations.

The invention is defined by independent claims <NUM> and <NUM>-<NUM>. Further details are defined by dependent claims <NUM> and <NUM>.

Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art, in which examples of embodiments of inventive concepts are shown.

As explained above, different ethernet component vendors have implemented time stamping with unique proprietary operations for high speed interfaces. Existing network nodes are not adapted to understand from another network node which of numerous differing time stamping has been selected to be used by the other network node, which results in unpredictable time stamping error and can cause time sensitive applications to operationally fail. Examples of time sensitive applications include New Radio (NR) Time Division Duplex (TDD), Long Term Evolution (LTE) TDD, NR Carrier aggregation, LTE carrier aggregation, positioning, etc..

To improve time stamping accuracy and interworking, various embodiments of the present disclosure are directed to a protocol through which a network node announces its time stamping to another network node, and may further negotiate with the other network node which of the respective the time stamping capabilities will be used for interworking and/or to determine the time stamping error which can occur when interworking.

A network node can operate to announce to another network node a list of time stamping capabilities the network node operationally supports, and may further announce which of the time stamping capabilities is selected for use when communicating with the other network node. The time stamping capabilities information can be announced (shared) on a link layer protocol, e.g., a Slow protocol, the PTP protocol, and/or using out-of-band communications. Alternatively or additionally, a network node may be manually configured with the time stamping capabilities of other network nodes at the time of installation.

Some embodiments of the present disclosure are directed to three operational steps: (<NUM>) defining time stamping capabilities which are supported; (<NUM>) announcing the time stamping capabilities to another network node; and (<NUM>) selecting a time stamping capability which can reduce time stamping error when communicating with the other network node.

The time stamping error caused by time stamping incompatibilities between network nodes (also referred to as devices) interoperating may be reduced from <NUM> of ns to single digit ns. In cases when it is not possible to reduce time stamping error to single digit ns, operations can make nodes aware of the time stamping incompatibilities and/or estimate time stamping error, and which can be used to log an event or alarm indicating to an operator of the network the potential for additional time stamping error caused by incompatible nodes in the network.

The term "network node" broadly refers to any type of device that performs time stamping operations in communications with another network node. Two network nodes may reside on a common semiconductor substrate, a common circuit board, different circuit boards connected through a backplane network, and/or networked devices which are spaced apart by meters, kilometers, or greater distances.

Some embodiments may become particularly important in the near future as IEEE <NUM>. CX becomes implemented and deployed in a larger scale alongside the already installed base of none IEEE <NUM>. 3CX implementations, priority implementations based on IEEE <NUM>-<NUM> or IEEE <NUM>-<NUM> with changes for interfaces with FEC sublayers.

Various embodiments of the present disclosure may be performed with Link Layer Discovery Protocol (LLDP). LLDP is a vendor-neutral link layer protocol used by network devices for advertising their identity, capabilities, and neighbors on a local area network based on IEEE <NUM> technology, principally wired Ethernet. LLDP enables Ethernet network devices to transmit and/or receive descriptive information, and to store such information learned about other devices. For LLDP, TLV and the TLV PTP protocol may be used instead of the Ethernet Synchronization Message Channel (ESMC) protocol or a newly defined protocol. A TLV added to the Link Layer Discovery Protocol may have some advantages over defining a TLV appended to the PTP Announce message. Adding TLV for <NUM> and <NUM> the PCS lane distribution and merging can also increase the accuracy. Accordingly, a network node may send an announcement indicating time stamping capabilities of the network node using a TLV added to the LLDP, to another network node.

In some embodiments, the sending <NUM> of the first announcement to the second network node includes sending the first announcement to the second network node using LLDP.

In some embodiments, sending <NUM> of the first announcement to the second network node further includes embedding the first announcement in a TLV field attached to a Link Layer Discovery (LLD) message.

In some embodiments, the first announcement embedded in the TLV field is attached to an egress LLD message.

In some embodiments, the first announcement is embedded in a dataField of the TLV field.

In some embodiments, the operations further include receiving from the second network node a LLD message with an attached TLV field providing a second announcement indicating time stamping capabilities of the second network node. The operations also include extracting from the TLV field the second announcement indicating the time stamping capabilities of the second network node. The operations also include generating a new message comprising the second announcement indicating the time stamping capabilities of the second network node. The operations also include forwarding the new message to a third network node.

However, TLV and the TLV PTP protocol may be implemented in any protocol, both current protocol and a newly defined protocol.

<FIG> illustrates a system overview of a first network node and a second network node which announce their respective time stamping capabilities through an ethernet network in accordance with some embodiments of inventive concepts.

Potential advantages of enabling a network node to announce its time stamping capabilities to another network node is to negotiate which time stamping operations are used for communications in order to reduce time stamping error and/or to allow estimation of time stamping error that can occur in time stamped communications. Because time stamping operations of network nodes can be implemented in silicon, these operations can be difficult to retroactively change without replacement of hardware components. Therefore, operations that can announce and may further negotiate selection of time stamping capabilities can enable network nodes to be more resilient to interworking with differing time stamping capabilities, enable identification of incompatibilities, and enable estimation of time stamping error which can occur when interworking. Making network nodes aware of each other's time stamping capabilities can enable their time stamping operations to be adapted to reduce time stamping error.

In order to reduce or minimize time stamping error caused by different operations for implementing time stamping of ethernet frames by different network nodes, the network nodes can be configured (adapted) to announce their time stamping capabilities through exchanged information messages. A network node receiving the information message identifying the time stamping capabilities of another network node, may select among its available time stamping capabilities and/or adjust how it performs time stamping when communicating with the other network node so as to reduce or minimize time stamping error.

The network node may inform the other network node which time stamping capability it has selected to use and/or indicate its adaptation of a time stamping capability in an outgoing time stamping capability information message.

The time stamping capabilities of network nodes may be exchanged based on using existing protocols.

The PTP protocol enables a network node to attach additional information to the PTP messages by use of a Type, Length, Value (TLV) field. In accordance with some embodiments, a PTP capable network node uses the TLV field to indicate its time stamping capabilities. The TLV field is adapted to indicate the time stamping capabilities of the PTP network node, and may be attached to all PTP messages or attached to only a subset of PTP messages sent by the PTP network node.

<FIG> illustrates a flow chart of operations and associated methods by a first network node according to some embodiments of inventive concepts.

Referring to <FIG>, the first network node generates <NUM> a first announcement indicating time stamping capabilities of the first network node. The first network node sends <NUM> the first announcement to a second network node.

<FIG> illustrates a further flow chart of operations and associated methods by the first network node according to some embodiments of inventive concepts.

Referring to <FIG>, the first network node also receives <NUM> a second announcement from the second network node indicating time stamping capabilities of the second network node. The first network node compares <NUM> the time stamping capabilities of the first and second network nodes.

In some further embodiments, the first network node communicates <NUM> with the second network node to negotiate which of the respective time stamping capabilities will be used for time stamping communications between the first and second network nodes based on the comparison <NUM>.

<FIG> illustrates a flow chart of operations and associated methods by the first network node according to some embodiments of inventive concepts.

Referring to <FIG>, the first network node negotiates which of the respective time stamping capabilities will be used for communications between the first and second network nodes, which includes selecting <NUM> which of the time stamping capabilities of the first and second network nodes will provide a least time stamping error relative to the other time stamping capabilities when used for time stamped communications between the first and second network nodes. The negotiation of which of the respective time stamping capabilities will be used for communications between the first and second network nodes, includes configuring <NUM> the first network node to use the selected time stamping capability for the first network node. The negotiation further includes sending <NUM> an indication of the selected time stamping capability for the second network node to the second network node.

In some further embodiments, the sending <NUM> of the first announcement to the second network node includes embedding the first announcement in a type, length, value (TLV) field attached to a precision time protocol (PTP) message. The first announcement embedded in the TLV field may be attached to an egress PTP message. Alternatively, the first announcement may be embedded in the dataField of the TLV field.

In some embodiments, the time stamping capabilities indicated in the TLV field received with an incoming PTP message is not forwarded by a first PTP network node, e.g., at least the time stamping capabilities indicated by the TLV field is removed from the incoming PTP message before being forwarded by the first PTP network node. As explained above, the received TLV field indicates the time stamping capabilities of a second PTP network node which sent the incoming PTP message. Thus, in some embodiments, the first PTP network node removes the TLV field from an incoming PTP message before forwarding the modified PTP message to a third PTP network node (e.g., a PTP network node other than the second PTP network node). The modified PTP message therefore does not include an indication of the time stamping capabilities of the second PTP network node which sent the original incoming PTP message.

Accordingly, in some embodiments, the first network node receives <NUM> from the second network node a PTP message with an attached TLV field providing a second announcement indicating time stamping capabilities of the second network node. The first network node removes the TLV field from the PTP message, and then forwards the PTP message to a third network node.

In some embodiments, the TLV field indicating time stamping capabilities is only sent between PTP network nodes that are directly connected by an ethernet link. Thus in some embodiments, a PTP network node selectively operates to use a TLV field which it attaches to a PTP message to indicate its time stamping capabilities, based on determining that the PTP message will be communicated using ethernet protocol.

In some embodiments, the operation to embed the first announcement in the TLV field attached to a PTP message includes performing the embedding of the first announcement in the TLV field attached to the PTP message, based on determining that the PTP message will be sent to the second network node using ethernet protocol.

The PTP generates a master-slave relationship among the PTP.

For master ports of a PTP network node that will be sending an egress PTP message toward an ethernet link, the TLV field indicating the time stamping capabilities can be attached to a PTP Announcement message, to a PTP Sync message, a PTP Follow-up message, or a PTP Delay Request message, in accordance with some embodiments. A master port may correspond to a port of a local link of the network node through which the RouterOS will communicate the time stamping capabilities to other ports of one or more other network nodes.

In some corresponding embodiments, responsive to when the first announcement will be sent <NUM> to the second network node through a master port of the first network node, the first announcement embedded in the TLV field is attached to one of the following: an egress PTP message, a PTP sync message, a PTP follow-up message, or a PTP delay request message.

In some embodiments, for PTP ports in a slave state that will be sending an egress PTP message toward an ethernet link, the TLV field indicating the time stamping capabilities can be attached to a PTP Delay request message. The "master" and "slave" ports may be defined as IEEE <NUM>-<NUM>/<NUM>.

In some embodiments, responsive to when the first announcement will be sent <NUM> to the second network node through a slave port of the first network node, the first announcement embedded in the TLV field is attached to a PTP delay request message.

For a PTP network node implementing a peer delay mechanism PTP which will be sending an egress PTP message toward an ethernet link, the TLV field indicating the time stamping capabilities can be attached to a PTP Pdelay_request message, Pdelay_Resp message, or Pdelay_Resp_Follow_Up message, in accordance with some embodiments.

In some corresponding embodiments, responsive to when the first announcement will be sent <NUM> to the second network node through a slave port of the first network node, the first announcement embedded in the TLV field is attached to a PTP delay request message.

In some other embodiments the TLV field indicating the time stamping capabilities is attached to a PTP signaling message.

In some embodiments, operations to generate <NUM> the first announcement include indicating whether the first network node accounts for physical coding sublayer (PCS) multi-lane distribution when determining time stamping for a message.

In some other embodiments the TLV field indicating the time stamping capabilities is attached to a PTP management message.

In some embodiments, the generating <NUM> of the first announcement includes indicating whether a transmit path data delay is measured from a beginning of a start frame delimiter.

Alternatively, the time stamping capabilities may be conveyed to another PTP device by use of a new type of ethernet slow protocol.

In some embodiments, the sending <NUM> of the first announcement to the second network node includes sending the first announcement using an ethernet slow protocol.

Alternatively, the time stamping capabilities may be conveyed to another PTP device by use of a TLV configured to carry the time stamping capability information in the existing slow protocol delivering ESMC messages (specified in ITU-T G. <NUM> "Distribution of timing information through packet networks").

In some embodiments, the sending <NUM> of the first announcement to the second network node includes sending the first announcement using an ethernet synchronization message channel (ESMC) protocol data unit (PDU).

<FIG> illustrates OSI reference model layers and further ethernet layers which can be configured to operate in accordance with some embodiments of inventive concepts. The TimeSync capability requires measurement of data delay in the transmit and receive paths, as shown in <FIG>. The transmit path data delay is measured from the beginning of the SFD at the xMII input to the beginning of the SFD at the MDI output. The receive path data delay is measured from the beginning of the SFD at the MDI input to the beginning of the SFD at the xMII output.

<FIG> is a table illustrating magnitude of potential timestamp accuracy impairments which can be reduced by operations in accordance with some embodiments of inventive concepts. In <FIG>, the ethernet rate is the data transfer rate over ethernet. The mismatched message timestamp point advertises that the network node supports using a timestamping point at the last bit of a message preamble or at a first bit of the message payload. The values shown only account for the time between the two message timestamp point options when they are adjacent. The idle insertion/removal may advertise rate compensation. Idle compensation will inject idle packets between payload packets to maintain line rates. The IEEE <NUM> standards have not specified whether the idle packets should be inserted before or after a time stamping point has been inserted into the message. The values shown correspond to the effect of a single idle insertion/removal. The path data delay of a TimeSync message is only affected when the message coincides with an alignment marker (AM), code word marker (CWM), or Idle insertion/removal event.

In some embodiments, the first announcement includes indicating whether the first network node supports inserting a time stamping point into a message before or after insertion of any idle packets into the message for rate compensation.

In some embodiments, the generating <NUM> of the first announcement includes indicating where the first network node inserted an AM for forward error correction (FEC) of a message.

In some embodiments, the generating <NUM> of the first announcement includes indicating whether the first network node accounts for removal of an AM from a message when determining a location of a time stamping point in the message.

In some embodiments, the generating <NUM> of the first announcement includes indicating whether the first network node accounts for physical coding sublayer (PCS) multi-lane distribution when determining time stamping for a message.

The AM/CWM insertion/removal moves the marker which shifts the data.

The physical coding sublayer (PCS) lane distribution/merging can advertise whether the network node is taking multilane into consideration when performing time stamping.

The following table illustrates the PTP organization specific TLV.

In some example embodiments, time stamping capabilities of a network node can be indicated through use of an organization specific TLV using one or more of the groups of bits shown in the above table.

The TLV can be attached to any PTP message, and for this example it is attached to the PTP announce message. The time stamping capabilities may be contained in the dataField illustrated in the following Table. The following table illustrates the PTP organization specific TLV dataField description.

<FIG> illustrates the effect of accounting or not accounting for the shift of bit position on the receiver or sender side in accordance with some embodiments of inventive concepts. There is a difference in receive time if transcoding is included. This is then exemplified with the start of packet in three different locations illustrated by the spacing between the apparent and actual transcoded positions.

<FIG> is a block diagram of sending (TX) and receiving (RX) operational blocks which can be configured to operate in accordance with some embodiments of inventive concepts. In the condition the TX and RX operational blocks are locked the effect of the above transcoding is cancelled because RX and TX process is the same with exception of sign. A problem can arise if one of the RX or TX operational blocks implements according to Clause <NUM> of IEEE <NUM> and the other one of the RX or TX operational blocks implements according to Clause <NUM> IEEE <NUM>-<NUM>.

<FIG> is a block diagram illustrating elements of a communication device UE <NUM> (also referred to as a mobile terminal, a mobile communication terminal, a wireless device, a wireless communication device, a wireless terminal, mobile device, a device, a wireless communication terminal, user equipment, UE, a user equipment node/terminal/device, etc.) configured to provide wireless communication according to embodiments of inventive concepts. (Communication device <NUM> may be provided, for example, as discussed below with respect to wireless devices UE 1212A, UE 1212B, and wired or wireless devices UE 1212C, UE 1212D of <FIG>, UE <NUM> of <FIG>, virtualization hardware <NUM> and virtual machines 1608A, 1608B of <FIG>, and UE <NUM> of <FIG>, all of which should be considered interchangeable in the examples and embodiments described herein and be within the intended scope of this disclosure, unless otherwise noted. ) As shown, communication device UE may include one or more antenna(s) (e.g., corresponding to antenna <NUM> of <FIG>), and transceiver circuitry <NUM> (also referred to as a transceiver, e.g., corresponding to interface <NUM> of <FIG> having transmitter <NUM> and receiver <NUM>) including a transmitter and a receiver configured to provide uplink and downlink radio communications with a base station(s) (e.g., corresponding to network node 1210A, 1210B of <FIG>, network node <NUM> of <FIG>, and network node <NUM> of <FIG> also referred to as a RAN node) of a radio access network. Communication device UE may also include processing circuitry <NUM> (also referred to as a processor, e.g., corresponding to processing circuitry <NUM> of <FIG>, and control system <NUM> of <FIG>) coupled to the transceiver circuitry, and memory circuitry <NUM> (also referred to as memory, e.g., corresponding to memory <NUM> of <FIG>) coupled to the processing circuitry. The memory circuitry <NUM> may include computer readable program code that when executed by the processing circuitry <NUM> causes the processing circuitry to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry <NUM> may be defined to include memory so that separate memory circuitry is not required. Communication device UE may also include an interface (such as a user interface) coupled with processing circuitry <NUM>, and/or communication device UE may be incorporated in a vehicle.

As discussed herein, operations of communication device UE may be performed by processing circuitry <NUM> and/or transceiver circuitry <NUM>. For example, processing circuitry <NUM> may control transceiver circuitry <NUM> to transmit communications through transceiver circuitry <NUM> over a radio interface to a radio access network node (also referred to as a base station) and/or to receive communications through transceiver circuitry <NUM> from a RAN node over a radio interface. Moreover, modules may be stored in memory circuitry <NUM>, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry <NUM>, processing circuitry <NUM> performs respective operations (e.g., operations discussed below with respect to Example Embodiments relating to wireless communication devices and wireless communication network nodes). According to some embodiments, a communication device UE <NUM> and/or an element(s)/function(s) thereof may be embodied as a virtual node/nodes and/or a virtual machine/machines. Various operations by the UE in accordance with embodiments of the present disclosure may be performed by discrete logic such as an application-specific integrated circuit (ASIC), which may include a field programmable gate array (FPGA), neural processing unit (NPU), etc., or may be performed by a central processing unit (CPU), a graphics processing unit (GPU), a line card, etc. The UE may contain a network node (e.g., PTP node) which is configured to operate in accordance with one or more embodiment disclosed herein, such as in accordance with any of the flowcharts of <FIG>.

<FIG> is a block diagram illustrating elements of a radio access network RAN node <NUM> (also referred to as a network node, base station, eNodeB/eNB, gNodeB/gNB, etc.) of a Radio Access Network (RAN) configured to provide cellular communication according to embodiments of inventive concepts. (RAN node <NUM> may be provided, for example, as discussed below with respect to network node 1210A, 1210B of <FIG>, network node <NUM> of <FIG>, hardware <NUM> or virtual machine 1608A, 1608B of <FIG>, and/or base station <NUM> of <FIG>, all of which should be considered interchangeable in the examples and embodiments described herein and be within the intended scope of this disclosure, unless otherwise noted. ) As shown, the RAN node may include transceiver circuitry <NUM> (also referred to as a transceiver, e.g., corresponding to portions of RF transceiver circuitry <NUM> and radio front end circuitry <NUM> of <FIG>) including a transmitter which transmits through one or more antenna(s) <NUM> (e.g., MIMO configured plurality of antennas) and a receiver configured to provide uplink and downlink radio communications with mobile terminals. The RAN node may include network interface circuitry <NUM> (also referred to as a network interface, e.g., corresponding to portions of communication interface <NUM> of <FIG>) configured to provide communications with other nodes (e.g., with other base stations) of the RAN and/or core network CN. The network node may also include processing circuitry <NUM> (also referred to as a processor, e.g., corresponding to processing circuitry <NUM> of <FIG>) coupled to the transceiver circuitry, and memory circuitry <NUM> (also referred to as memory, e.g., corresponding to memory <NUM> of <FIG>) coupled to the processing circuitry. The memory circuitry <NUM> may include computer readable program code that when executed by the processing circuitry <NUM> causes the processing circuitry to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry <NUM> may be defined to include memory so that a separate memory circuitry is not required. Various operations by the RAN node in accordance with embodiments of the present disclosure may be performed by discrete logic such as a FPGA. The RAN node may contain a network node (e.g., PTP node) which is configured to operate in accordance with one or more embodiment disclosed herein, such as in accordance with any of the flowcharts of <FIG>.

As discussed herein, operations of the RAN node may be performed by processing circuitry <NUM>, network interface <NUM>, and/or transceiver <NUM>. For example, processing circuitry <NUM> may control transceiver <NUM> to transmit downlink communications through transceiver <NUM> over a radio interface to one or more mobile terminals UEs and/or to receive uplink communications through transceiver <NUM> from one or more mobile terminals UEs over a radio interface. Similarly, processing circuitry <NUM> may control network interface <NUM> to transmit communications through network interface <NUM> to one or more other network nodes and/or to receive communications through network interface from one or more other network nodes. Moreover, modules may be stored in memory <NUM>, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry <NUM>, processing circuitry <NUM> performs respective operations (e.g., operations discussed below with respect to Example Embodiments relating to RAN nodes). According to some embodiments, RAN node <NUM> and/or an element(s)/function(s) thereof may be embodied as a virtual node/nodes and/or a virtual machine/machines.

According to some other embodiments, a network node may be implemented as a core network CN node without a transceiver. In such embodiments, transmission to a wireless communication device UE may be initiated by the network node so that transmission to the wireless communication device UE is provided through a network node including a transceiver (e.g., through a base station or RAN node). According to embodiments where the network node is a RAN node including a transceiver, initiating transmission may include transmitting through the transceiver.

<FIG> is a block diagram illustrating elements of a core network (CN) node <NUM> (e.g., an SMF (session management function) node, an AMF (access and mobility management function) node, etc.) of a communication network configured to provide cellular communication according to embodiments of inventive concepts. (CN node <NUM> may be provided, for example, as discussed below with respect to core network node <NUM> of <FIG>, hardware <NUM> or virtual machine 1608A, 1608B of <FIG>, all of which should be considered interchangeable in the examples and embodiments described herein and be within the intended scope of this disclosure, unless otherwise noted) As shown, the CN node may include network interface circuitry <NUM> configured to provide communications with other nodes of the core network and/or the radio access network RAN. The CN node may also include a processing circuitry <NUM> (also referred to as a processor,) coupled to the network interface circuitry, and memory circuitry <NUM> (also referred to as memory) coupled to the processing circuitry. The memory circuitry <NUM> may include computer readable program code that when executed by the processing circuitry <NUM> causes the processing circuitry to perform operations according to embodiments disclosed herein. According to other embodiments, processing circuitry <NUM> may be defined to include memory so that a separate memory circuitry is not required.

As discussed herein, operations of the CN node <NUM> may be performed by processing circuitry <NUM> and/or network interface circuitry <NUM>. For example, processing circuitry <NUM> may control network interface circuitry <NUM> to transmit communications through network interface circuitry <NUM> to one or more other network nodes and/or to receive communications through network interface circuitry from one or more other network nodes. Moreover, modules may be stored in memory <NUM>, and these modules may provide instructions so that when instructions of a module are executed by processing circuitry <NUM>, processing circuitry <NUM> performs respective operations (e.g., operations discussed below with respect to Example Embodiments relating to core network nodes). According to some embodiments, CN node <NUM> and/or an element(s)/function(s) thereof may be embodied as a virtual node/nodes and/or a virtual machine/machines. Various operations by the CN node <NUM> in accordance with the present disclosure may be performed by discrete logic such as a FPGA. The CN node <NUM> may contain a PTP network node which is configured to operate in accordance with one or more embodiment disclosed herein, such as in accordance with any of the flowcharts of <FIG>.

In the description herein, while the communication device may be any of the communication device <NUM>, wireless device 1212A, 1212B, wired or wireless devices UE 1212C, UE 1212D, UE <NUM>, virtualization hardware <NUM>, virtual machines 1608A, 1608B, or UE <NUM>, the communication device shall be used to describe the functionality of the operations of the communication device. Operations of the communication device may be implemented according to one or more of the flowcharts of <FIG> according to some embodiments of inventive concepts. For example, modules may be stored in memory <NUM> of <FIG>, and these modules may provide instructions so that when the instructions of a module are executed by respective communication device processing circuitry <NUM>, processing circuitry <NUM> performs respective operations of the flow chart. Alternatively or additionally, the operations may be implemented in a FPGA or other digital logic device.

In the description herein, while the network node may be any of the RAN node <NUM>, network node 1210A, 1210B, <NUM>, <NUM>, hardware <NUM>, or virtual machine 1608A, 1608B, the RAN node <NUM> shall be used to describe the functionality of the operations of the network node. Operations of the RAN node <NUM> may be implemented according to one or more of the flowcharts of <FIG> according to some embodiments of inventive concepts. For example, modules may be stored in memory <NUM> of <FIG>, and these modules may provide instructions so that when the instructions of a module are executed by respective RAN node processing circuitry <NUM>, processing circuitry <NUM> performs respective operations of the flow chart. Alternatively or additionally, the operations may be implemented in a FPGA or other digital logic device.

In the description herein, while the core network node may be any of the core network node <NUM>, core network node <NUM>, hardware <NUM>, or virtual machine 1608A, 1608B, the core network node <NUM> shall be used to describe the functionality of the operations of the network node. Operations of the Core Network CN node <NUM> may be implemented according to one or more of the flowcharts of <FIG> according to some embodiments of inventive concepts. For example, modules may be stored in memory <NUM> of <FIG>, and these modules may provide instructions so that when the instructions of a module are executed by respective CN node processing circuitry <NUM>, processing circuitry <NUM> performs respective operations of the flow chart. Alternatively or additionally, the operations may be implemented in a FPGA or other digital logic device.

<FIG> shows an example of a communication system <NUM> in accordance with some embodiments.

In the example, the communication system <NUM> includes a telecommunication network <NUM> that includes an access network <NUM>, such as a radio access network (RAN), and a core network <NUM>, which includes one or more core network nodes <NUM>. The access network <NUM> includes one or more access network nodes, such as network nodes 1210a and 1210b (one or more of which may be generally referred to as network nodes <NUM>), or any other similar 3rd Generation Partnership Project (3GPP) access node or non-3GPP access point. The network nodes <NUM> facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 1212a, 1212b, 1212c, and 1212d (one or more of which may be generally referred to as UEs <NUM>) to the core network <NUM> over one or more wireless connections.

In some examples, the UEs <NUM> are configured to transmit and/or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network <NUM> on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network <NUM>. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

In the example, the hub <NUM> communicates with the access network <NUM> to facilitate indirect communication between one or more UEs (e.g., UE 1212c and/or 1212d) and network nodes (e.g., network node 1210b). In some examples, the hub <NUM> may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub <NUM> may be a broadband router enabling access to the core network <NUM> for the UEs. As another example, the hub <NUM> may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes <NUM>, or by executable code, script, process, or other instructions in the hub <NUM>. As another example, the hub <NUM> may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub <NUM> may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub <NUM> may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub <NUM> then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, the hub <NUM> acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy IoT devices.

The hub <NUM> may have a constant/persistent or intermittent connection to the network node 1210b. The hub <NUM> may also allow for a different communication scheme and/or schedule between the hub <NUM> and UEs (e.g., UE 1212c and/or 1212d), and between the hub <NUM> and the core network <NUM>. In other examples, the hub <NUM> is connected to the core network <NUM> and/or one or more UEs via a wired connection. Moreover, the hub <NUM> may be configured to connect to an M2M service provider over the access network <NUM> and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes <NUM> while still connected via the hub <NUM> via a wired or wireless connection. In some embodiments, the hub <NUM> may be a dedicated hub - that is, a hub whose primary function is to route communications to/from the UEs from/to the network node 1210b. In other embodiments, the hub <NUM> may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 1210b, but which is additionally capable of operating as a communication start and/or end point for certain data channels.

<FIG> shows a UE <NUM> in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle-mounted or vehicle embedded/integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE.

A UE, when in the form of an Internet of Things (IoT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an IoT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door/window sensor, a flood/moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an IoT device comprises circuitry and/or software in dependence of the intended application of the IoT device in addition to other components as described in relation to the UE <NUM> shown in <FIG>.

In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone's speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g., by controlling an actuator) to increase or decrease the drone's speed. The first and/or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

<FIG> shows a network node <NUM> in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with a UE and/or with other network nodes or equipment, in a telecommunication network.

Applications <NUM> (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein.

Hardware <NUM> includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers <NUM> (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1608a and 1608b (one or more of which may be generally referred to as VMs <NUM>), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer <NUM> may present a virtual operating platform that appears like networking hardware to the VMs <NUM>.

Hardware <NUM> may be implemented in a standalone network node with generic or specific components. Hardware <NUM> may implement some functions via virtualization. Alternatively, hardware <NUM> may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration <NUM>, which, among others, oversees lifecycle management of applications <NUM>. In some embodiments, hardware <NUM> is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system <NUM> which may alternatively be used for communication between hardware nodes and radio units.

<FIG> shows a communication diagram of a host <NUM> communicating via a network node <NUM> with a UE <NUM> over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE 1212a of <FIG> and/or UE <NUM> of <FIG>), network node (such as network node 1210a of <FIG> and/or network node <NUM> of <FIG>), and host (such as host <NUM> of <FIG> and/or host <NUM> of <FIG>) discussed in the preceding paragraphs will now be described with reference to <FIG>.

In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection <NUM> between the host <NUM> and UE <NUM>, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host <NUM> and/or UE <NUM>. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection <NUM> passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection <NUM> may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node <NUM>. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host <NUM>. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or 'dummy' messages, using the OTT connection <NUM> while monitoring propagation times, errors, etc..

In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and/or by end users and a wireless network generally.

In the above description of various embodiments of present inventive concepts, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of present inventive concepts.

The term "and/or" (abbreviated "/") includes any and all combinations of one or more of the associated listed items.

Claim 1:
A method by a first network node, the method comprising:
generating (<NUM>) a first announcement indicating time stamping capabilities of the first network node;
sending (<NUM>) the first announcement to a second network node;
receiving (<NUM>) a second announcement from the second network node indicating time stamping capabilities of the second network node;
comparing (<NUM>) the time stamping capabilities of the first and second network nodes
based on the comparison (<NUM>), communicating (<NUM>) with the second network node to negotiate which of the respective time stamping capabilities will be used for time stamping communications between the first and second network nodes;
selecting (<NUM>) which of the time stamping capabilities of the first and second network nodes will provide the least time stamping error relative to the other time stamping capabilities when used for time stamped communications between the first and second network nodes;
configuring (<NUM>) the first network node to use the selected time stamping capability for the first network node; and
sending (<NUM>) an indication of the selected time stamping capability for the second network node to the second network node.