High-precision time-sensitive network (TSN)-based 5g system

Abstract

A communication quantum network, configured to support timesensitive deterministic communication based on a time-sensitive network (TSN) mechanism. The system may include a plurality of network devices configured to provide functionality for data communication from a source device across a communication network to a destination device, at least some of the plurality of network devices being configured to use a legacy TSN mechanism, and a controller arranged to configure a high time resolution network device of the plurality of network devices with a high time resolution TSN parameter for time-sensitive deterministic communication from the source device to the destination device based on a high time resolution TSN mechanism, wherein in accordance with the high time resolution TSN parameter, an operational timing associated with the high time resolution network device, and an operational timing associated with a legacy network device of the plurality of network devices configured with the legacy TSN mechanism.

Description

HIGH-PRECISION TIME-SENSITIVE NETWORK (TSN)-BASED 5G SYSTEMTECHNICAL FIELD

[0001] The present description relates generally to integration of a wireless communication system and a time-sensitive network (TSN), and, more particularly, for example, to a system and method for a high-precision TSN.BACKGROUND

[0002] Some applications such as industrial automation and manufacturing require ubiquitous and seamless connectivity with strict, deterministic timing requirements for communications between various devices or components (e.g., an industrial controller, a sensor, an actuator, etc.) of the application. To meet such requirements, a TSN system, which provides deterministic communication with relatively stringent quality of service (QoS) parameters, such as latency, jitter and reliability requirements for data traffic, may be integrated with a 5G wireless communication system, which provides a high reliability service, such as an ultrareliable low latency communication (URLLC) service. A high-precision TSN mechanism is developed to provide higher fidelity reconstruction of more rapidly changing signals enabling improved stability of higher frequency networked control systems. The TSN mechanism (or standard TSN mechanism) is currently limited to ~40 nanoseconds precision, at best, with respect to scheduling but the high-precision TSN mechanism can provide picosecond precision. The high-precision TSN mechanism is backward compatible with legacy TSN.SUMMARY

[0003] Accordingly, there is a need for systems, devices and methods to support timesensitive deterministic communication based on a time-sensitive network (TSN) mechanism. In one aspect, some implementations include a system to support time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism. The system includes a plurality of network devices configured to provide functionality for data communication from asource device across a communication network to a destination device, at least some of the plurality of network devices being configured to use a legacy TSN mechanism and a controller arranged to configure a high time resolution network device of the plurality of network devices with a high time resolution TSN parameter for time-sensitive deterministic communication from the source device to the destination device based on a high time resolution TSN mechanism, wherein in accordance with the high time resolution TSN parameter, an operational timing associated with the high time resolution network device is set in picoseconds, and an operational timing associated with a legacy network device of the plurality of network devices configured with the legacy TSN mechanism is set in nanoseconds.

[0004] In another aspect, some implementations include a method controlling a communication network based on a time-sensitive network (TSN) mechanism. The method includes: receiving signals from a source device, determining whether to configure a high time resolution network device of a plurality of network devices with a high time resolution TSN parameter based on Wavelet or Fourier Transform analysis of the signals from the source device, wherein the plurality of network devices configured to provide functionality for data communication from the source device across a communication network to a destination device, at least some of the plurality of network devices being configured to use a legacy TSN mechanism, and in response to determination, configuring the high time resolution network device of the plurality of network devices with the high time resolution TSN parameter for time-sensitive deterministic communication from the source device to a destination device based on a high time resolution TSN mechanism, wherein in accordance with the high time resolution TSN parameter, an operational timing associated with the high time resolution network device is set in picoseconds, and an operational timing associated with a legacy network device of the plurality of network devices configured with the legacy TSN mechanism is set in nanoseconds.

[0005] In another aspect, some implementations include a non-transitory computer readable medium storing instructions that, when executed by a processor, cause the processor to: determine whether to configure a high time resolution network device of a plurality of network devices with a high time resolution TSN parameter based on Wavelet or Fourier Transform analysis of the signals from the source device, wherein the plurality of network devices configured to provide functionality for data communication from the source device across a communication network to a destination device, at least some of the plurality of network devices being configuredto use a legacy TSN mechanism and in response to determination, configure the high time resolution network device of the plurality of network devices with a high time resolution TSN parameter for time-sensitive deterministic communication from the source device to a destination device based on a high time resolution TSN mechanism, wherein in accordance with the high time resolution TSN parameter, an operational timing associated with the high time resolution network device is set in picoseconds, and an operational timing associated with a legacy network device of the plurality of network devices configured with the legacy TSN mechanism is set in nanoseconds.

[0006] In another aspect, some implementations include a system configured to support time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism. The system includes a plurality of network devices configured to provide functionality for data communication from a source device across a communication network to a destination device and a controller arranged to configure at least one of the plurality of network devices with a TSN parameter for time-sensitive deterministic communication from the source device to the destination device based on a TSN schedule, monitor noise in the communication network and dynamically adjust the TSN schedule based on the noise such that the at least one of the plurality of network devices supports the time-sensitive deterministic communication in accordance with the adjusted TSN schedule.

[0007] In another aspect, some implementations include a method for controlling a communication network based on a time-sensitive network (TSN) mechanism. The method includes configuring at least one of a plurality of network devices with a TSN parameter for timesensitive deterministic communication from the source device to a destination device based on a TSN schedule, the plurality of network devices configured to provide functionality for data communication from a source device across a communication network to a destination device, monitoring noise in the communication network, and dynamically adjusting the TSN schedule based on the noise such that the at least one of the plurality of network devices supports the timesensitive deterministic communication in accordance with the adjusted TSN schedule.

[0008] In another aspect, some implementations include a non-transitory computer readable medium storing instructions that, when executed by a processor, cause the processor to: configure at least one of a plurality of network devices with a TSN parameter for time-sensitive deterministic communication from the source device to a destination device based on a TSN schedule, the plurality of network devices configured to provide functionality for datacommunication from a source device across a communication network to a destination device, monitor noise in the communication network, and dynamically adjust the TSN schedule based on the noise such that the at least one of the plurality of network devices supports the time-sensitive deterministic communication in accordance with the adjusted TSN schedule.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Certain features of the subject technology are set forth in the appended claims. However, for purpose of explanation, several aspects of the subject technology are set forth in the following figures.

[0010] Fig. 1 illustrates an example of a conventional integrated TSN-5G system in accordance with one or more implementations.

[0011] Fig. 2 illustrates a block diagram of an example integrated TSN-5G system architecture in accordance with one or more implementations.

[0012] Fig. 3 illustrates an example of an integrated TSN-5G system in accordance with one or more implementations.

[0013] Fig. 4 illustrates a block diagram of an example TSN block in accordance with one or more implementations.

[0014] Fig. 5 illustrates an example set of parameters for an example TSN block in accordance with one or more implementations.

[0015] Figs. 6A, 6B illustrate a block diagram of an example integrated TSN-5G system architecture including ME in accordance with one or more implementations.

[0016] Fig. 7 illustrates an electronic system with which one or more implementations of the subject technology may be implemented.

[0017] Fig. 8 illustrates a block diagram of an example integrated TSN-5G system architecture in accordance with one or more implementations.

[0018] Fig. 9 is an example system in accordance with one or more implementations.

[0019] Fig. 10 illustrates example multiple TSN domains in accordance with one or more implementations.

[0020] Fig. 11 illustrates examples high-precision data bus in accordance with one or more implementations.

[0021] Fig. 12 illustrates example monitoring operations in accordance with one or more implementations.

[0022] Fig. 13 is an example TSN scheduling abstraction in accordance with one or more implementations.

[0023] Fig. 14 illustrates a block diagram of dynamic TSN scheduling in accordance with one or more implementations.

[0024] Fig. 15 illustrates an example high-precision TSN gate control operation for a quantum network in accordance with one or more implementations.

[0025] Fig. 16 illustrates example quantum nodes in accordance with one or more implementations.

[0026] Fig. 17 illustrates example quantum nodes in accordance with one or more implementations.

[0027] Fig. 18 illustrates a flow diagram of example operations of a system in accordance with one or more implementations.

[0028] Fig. 19 illustrates a flow diagram of example operations of a system in accordance with one or more implementations.DETAILED DESCRIPTION

[0029] The detailed description set forth below is intended as a description of various configurations of the subject technology and is not intended to represent the only configurationsin which the subject technology can be practiced. The appended drawings are incorporated herein and constitute a part of the detailed description. The detailed description includes specific details for the purpose of providing a thorough understanding of the subject technology. However, the subject technology is not limited to the specific details set forth herein and can be practiced using one or more other implementations. In one or more implementations, structures and components are shown in block diagram form in order to avoid obscuring the concepts of the subject technology.

[0030] As noted above, for some applications such as, but not limited to, industrial automation, manufacturing, and aerospace and automotive in-vehicle communications, a TSN system, which provides deterministic communication may be integrated with a fifth-generation (5G) or sixth-generation (6G) wireless communication system (or any communication network or system defined per a 3GPP standard or IEEE 802.1 standard). However, typically, in such an integrated TSN-5G system, the entire 5G system is configured to operate as one single TSN component (e.g., a TSN bridge), and the integrated system is set up as a fully centralized configuration model, e.g., that uses one centralized TSN configuration controller. Accordingly, such an integrated system may not support flexibility of deploying a 5G system that includes various components provided by different vendors or for a decentralized TSN configuration of the integrated system. Further, a 5G system may support reliable communication by using redundant paths for data transmission. However, with the 5G system being set up as one TSN component in a typical TSN-5G integrated system, the redundant paths are configured across the entire 5G system through all its components (e.g., from user equipment (UE) to user plane function (UPF)). This does not allow for flexibility of setting up redundant data transmission paths for only for a portion of the 5G system, e.g., the 5G system portion (such as an air interface between UE and radio access network (RAN)ZgNodeB) that is more susceptible to data delay and / or errors.

[0031] To address the above-discussed issues in an integrated TSN-5G system, the subject technology provides for a novel architecture in which, instead of being configured as a single TSN component or block, the 5G system is configured as a set of discrete 5G components where each 5G component is configured as one discrete TSN block. In other words, the disclosure provides for an architecture in which the 5G system in an integrated TSN-5G system ispartitioned into a plurality of TSN blocks, where each TSN block is configured in accordance with TSN specifications (e.g., per IEEE 802. IQ and related standards), e.g., as a TSN bridge, TSN end device, or a combination of two. Further, instead of having a centralized configuration controller to control the TSN-5G system, the subject technology provides for a plurality of distributed configuration modules in the TSN-5G system. The configuration modules may be interconnected in one or more topologies (including mesh, star, tree, or random) and each configuration module may be responsible to communicate with, and configure, one or more TSN blocks.

[0032] As is discussed in detail below, each TSN block of the plurality of TSN blocks of the 5G system includes a set of parameters describing the capabilities to support and execute a data flow (e.g., carrying URLLC data traffic) through that TSN block. Further, each TSN block may include at least one configuration interface configured to support interaction of the TSN block with its respective configuration module. The configuration interface may be used to provide the set of parameters of the TSN block to the respective configuration module, and receive from the configuration module configuration data (e.g., transmission schedule, data flow identities, policing rules, etc.) to support one or more data flows through the TSN block. Each TSN block may be configured to execute or operate according to the configuration data (received via the configuration interface) and transmit data for each data flow according to the specifications provided in the configuration data. Lastly, each TSN block may also include a monitoring and diagnostics module configured to monitor run-time behavior of the TSN block and report the behavior either through the configuration interface or via a separate interface of the TSN block.

[0033] Each configuration module of the plurality of distributed configuration modules may be either an external utility responsible for configuring one or more TSN blocks or may be configured as a software module within the TSN block that only configures that TSN block. Each configuration module may be configured to determine and provide to TSN blocks controlled by the configuration module configuration data including a TSN schedule for one or more data flows to be transmitted through the TSN blocks. The configuration modules may exchange information with each other using a standardized Application Programming Interface (API). The exchanged information may include information regarding cycles times for the TSN system (e.g., supported admin cycle times (ACTs) including discrete levels of ACT buckets eachcorresponding to a specific data flow, max / min cycle times), configuration data including transmission schedule (include time offsets / duration / resources for transmission) for one or more TSN blocks, and information to request or respond to requests for resource allocations. In some implementations, one or more of the plurality of configuration modules may be adapted as a “controller” or “controller module,” which may include a component configured or adapted to provide instruction, control, operation, or any form of communication for operable components to affect the operation thereof. A controller module may include any known processor, microcontroller, or logic device, including, but not limited to: field programmable gate arrays (FPGA), an application specific integrated circuit (ASIC), a full authority digital engine control (FADEC), an aviation system, a proportional controller (P), a proportional integral controller (PI), a proportional derivative controller (PD), a proportional integral derivative controller (PID controller), a hardware-accelerated logic controller (e.g. for encoding, decoding, transcoding, etc.), the like, or a combination thereof.

[0034] 3GPP Release 8 classifies self-organizing networks (SON) into three main categories: self-configuration, self-optimization, and self-healing. Self-organization is regarded as a mechanism or a process that enables a system or network to change its organization without explicit command during its execution time. Self-configuration is defined as a process of incorporating a new Network Element (NE) into a service requiring minimal human operator intervention where a network element is a manageable logical entity uniting one or more physical devices. In some implementations, a TSN block (discussed below) may be selfconfiguring and incorporated into a 5G system as a NE with minimum human intervention. This can be accomplished by TSN applications that automatically share their TSN flow (stream) characteristics and latency requirements with the TSN block. The TSN blocks may collaborate to share the flow characteristics and determine feasible TSN schedules.

[0035] In some implementations, the present disclosure provides a communication network, e g., a wireless network such as a fifth-generation (5G) or sixth-generation (6G) wireless communication system or network (or any communication network or system defined per a 3GPP standard or IEEE 802.1 standard) that is configured to support time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism. In the context of the present disclosure, any reference to a “communication network,” “wireless network,” and“communication / wireless network” denotes a network of various components designed, arranged and / or configured for communication of data, signals, or information from a source node or device to a destination node or device across the network, where at least a portion of the communication is completed wirelessly. Accordingly, the various components of such a network may be communicatively interconnected via wireless links or channels and / or via wired links or channels. The various components of the network include modules and channels / links implemented in hardware, software, and in a combination of hardware and software.

[0036] The communication network may include a plurality of discrete communication network (CN) components. Each CN component may be configured to provide a discrete functionality for data communication from a source device across the network to a destination device. The communication / wireless network may further include a processor arranged to configure at least one (or each) of the plurality of CN components with a set of TSN parameters of the TSN mechanism. Configured with the set of TSN parameters, the at least one (or each) of the plurality of CN components may support time-sensitive deterministic communication as a TSN block in a TSN network in accordance with the set of TSN parameters. In other words, the at least one (or each) of the plurality of CN components may operate as a typical TSN block in a TSN network.

[0037] The plurality of discrete CN components of the 5G network may include a user equipment (UE), a radio access network (RAN), a user plane function (UPF), a control plane function, and transport network channels connecting CN components including a transport network channel connecting the RAN and the UPF. In some implementations, the at least one of the plurality of CN components that is configured with the TSN parameter(s) is the 5G transport network channel connecting the RAN and the UPF.

[0038] The communication network may include a configuration module configured to determine the set of TSN parameters for the at least one of the plurality of CN components, the set of TSN parameters including one or more of a TSN stream identification, a transmission schedule, a deadline or delay budget, a filtering configuration, and a redundancy scheme. In some implementations, the configuration module is configured within a session management function (SMF) of a control plane of the 5G network.

[0039] In some implementations, the present disclosure provides a communication network, e.g., a wireless network such as a 5G network, includes a plurality of configuration modules interconnected in a certain arrangement and configured to provide a unique set of TSN parameters to each of the plurality of CN components such that each of the plurality of CN components supports time-sensitive deterministic communication as a corresponding TSN block in a TSN network in accordance with the respective unique set of TSN parameters. The plurality of configuration modules may be interconnected in a hierarchical arrangement, a mesh arrangement, a star arrangement, a tree arrangement, or a combination thereof.

[0040] In some implementations, the present disclosure provides a system including a first communication (such as 5G / 6G) network, a second communication (such as a 5G / 6G) network, and a TSN transport channel in connection with the first and second communication networks. The first network may include a first plurality of discrete communication network (CN) components, each CN component configured to provide a discrete functionality for data communication via the first network, wherein at least one of the first plurality of CN components is configured to provide time-sensitive deterministic communication in accordance with a first set of TSN parameters. The second network may include a second plurality of discrete CN components, each CN component configured to provide a discrete functionality for data communication via the second network, wherein at least one of the second plurality of CN components is configured to provide time-sensitive deterministic communication in accordance with a second set of TSN parameters. The TSN transport channel may be configured to facilitate time-sensitive deterministic communication of data exchanged between the first network and the second network, in accordance with a third set of TSN parameters. In some implementation, the TSN transport channel is communicatively connected with a first TSN translator of the first wireless network and a second TSN translator of the second wireless network.

[0041] A high-precision TSN mechanism can implement more TSN flows, with smaller messages, and more precise TSN flow latencies (high-precision TSN flows). With greater resolution and precision in the allocation of the message latency time budget for each TSN flow comes greater applicability of TSN to more challenging applications. In some implementations, the high-precision TSN mechanism can be referred to as high time resolution TSN mechanism, the high-precision TSN flow can be referred to as a high time resolution TSN flow. The high-precision TSN mechanism is developed to provide higher fidelity reconstruction of more rapidly changing signals enabling improved stability of higher frequency networked control systems. TSN mechanism (or standard TSN mechanism) is currently limited to ~40 nanoseconds precision, at best, with respect to scheduling but the high-precision TSN mechanism can provide picoseconds precision. The high-precision TSN mechanism is a Bridged Local Area Network with VLANs (specified in IEEE 802. IQ) that uses Ethernet (IEEE 802.3) to interconnect switches and nodes, and an extension incorporated into the 2019 revision of IEEE 1588 standard by the P1588 Working Group (IEEE Standard 1588-2019, in 2020 [4, Annex M]). The high- precision TSN mechanism is backward compatible with legacy TSN specified in IEEE 802. I Q. In such context, the present disclosure introduces a system to integrate high-precision TSN mechanism with legacy TSN functionalities so that the system enables seamless interoperation among high-precision and legacy TSN network components.

[0042] In some implementations, the present disclosure provides a system configured to support time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism comprising: a plurality of network devices configured to provide functionality for data communication from a source device across a communication network to a destination device, at least some of the plurality of network devices being configured to use a legacy TSN mechanism; and a controller arranged to configure a high time resolution network device of the plurality of network devices with a high time resolution TSN parameter for time-sensitive deterministic communication from the source device to the destination device based on a high time resolution TSN mechanism, wherein in accordance with the high time resolution TSN parameter, an operational timing associated with the high time resolution network device is different from an operational timing associated with the legacy network device of the plurality of network devices configured with the legacy TSN mechanism, wherein the operational timing associated with the high time resolution network device is faster than 40 nanoseconds and wherein the operational timing associated with the legacy TSN mechanism is up to 40 nanoseconds.

[0043] In some implementations, the controller is configured to determine whether to configure the high time resolution network device with the high time resolution TSN parameter based on Wavelet or Fourier Transform analysis of the signals. In some implementations, thesystem includes a first TSN domain to support one or more high time resolution TSN flows based on the high time resolution TSN mechanism and a second TSN domain to support one or more TSN flows based on the legacy TSN mechanism, the first TSN domain including the high time resolution network device, the second TSN domain including the legacy network device of the plurality of network devices. In some implementations, the system includes a boundary clock configured to provide time synchronization between the first TSN domain and the second TSN domain so that at least one of the one or more high time resolution TSN flows passes from the first TSN domain to the second TSN domain. In some implementations, the operational timing associated with the high time resolution network device is set in picoseconds, and the operational timing associated with the legacy network device is set in nanoseconds. In some implementations, the high time resolution TSN parameter includes a gate accuracy parameter indicating accuracy with which gate operations associated with the high time resolution network device are consistently applied, a time resolution parameter indicating time resolution with which gate operations associated with the high time resolution network device are configured and reported. In some implementations, the controller is configured to provide digital input / output (DIO) parameters including: a DIO enabled parameter indicating whether the DIO is enabled, a DIO value parameter indicating whether timestamps or digital signal values are placed in Ethernet fames of the high time resolution TSN flow, a DIOstreamID parameter identifying a steam of DIO, and a DIOnumberSamples parameter indicating a number of DIO samples placed in each Ethernet fame of the high time resolution TSN flow. In some implementations, the controller is configured to provide dynamically changing TSN schedule for high time resolution TSN flows which periodically vary in a determined cycle time. In some implementations, the high time resolution network device includes a high time resolution TSN data bus to implement gate operations based on the dynamically changing TSN schedule. In some implementations, the high time resolution network device is configured to provide monitoring operations for monitoring the high time resolution TSN flow based on arrival time of each frame of the high time resolution TSN flow. In some implementations, the monitoring operations determine if errors in the high time resolution TSN flow exceeds thresholds, in response to the determination that the errors in the high time resolution TSN flow exceeds thresholds, the monitoring operations output signal indicating the errors in the high time resolution TSN flow. In some implementations, the communication network includes a wireless network configured inaccordance with a 3GPP-defmed standard. In some implementations, the communication network includes a quantum network. In some implementations, the controller is configured to generate a gate control list to control gate open and close time of each gate in the at least one network device based on dynamically changing TSN schedule of the high time resolution TSN mechanism. In some implementations, a cycle of gate open and close time of each gate is configured to implement a quantum operation to process a single photon in the quantum network corresponding to a respective high time resolution TSN flow.

[0044] In some implementations, the present disclosure provides a method for controlling a communication network based on a time-sensitive network (TSN) mechanism, comprising determining whether to configure a high time resolution network device with a high time resolution TSN parameter based on Wavelet or Fourier Transform analysis; and in response to determination, configuring the high time resolution network device of the plurality of network devices with the a high time resolution TSN parameter for time-sensitive deterministic communication based on a high time resolution TSN mechanism, wherein in accordance with the high time resolution TSN parameter, an operational timing associated with the high time resolution network device is different from an operational timing associated with a legacy network device of the plurality of network devices configured with a legacy TSN mechanism. In some implementations, the present disclosure provides a non-transitory computer readable medium storing instructions that, when executed by a processor, cause the processor to: determine whether to configure a high time resolution network device with a high time resolution TSN parameter based on Wavelet or Fourier Transform analysis; and in response to determination, configure the high time resolution network device of the plurality of network devices with the a high time resolution TSN parameter for time-sensitive deterministic communication based on a high time resolution TSN mechanism, wherein in accordance with the high time resolution TSN parameter, an operational timing associated with the high time resolution network device is different from an operational timing associated with a legacy network device of the plurality of network devices configured with a legacy TSN mechanism.

[0045] In some implementations, the present disclosure provides a system configured to support time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism, the system comprising: a plurality of network devices configured to providefunctionality for data communication from a source device across a communication network to a destination device; and a controller arranged to configure at least one of the plurality of network devices with a TSN parameter for time-sensitive deterministic communication from the source device to the destination device based on a TSN schedule, monitor noise in the communication network and dynamically adjust the TSN schedule based on the noise such that the at least one of the plurality of network devices supports the time-sensitive deterministic communication in accordance with the adjusted TSN schedule.

[0046] In some implementations, the TSN parameter includes a high time resolution TSN parameter which is used to configure a high time resolution TSN network of the plurality of network devices based on a high time resolution TSN mechanism. An operational timing associated with the high time resolution network device is different from an operational timing associated with a legacy network device of the plurality of network devices configured with a legacy TSN mechanism, wherein the high time resolution TSN parameter includes a gate accuracy parameter indicating accuracy with which gate operations associated with the high time resolution network device are consistently applied, a time resolution parameter indicating time resolution with which gate operations associated with the high time resolution network device are configured and reported.

[0047] In some implementations, the communication network includes a quantum network. The controller may be configured to generate a gate control list to control gate open and close time of each gate associated with the at least one network device based on the adjusted TSN schedule. In some implementations, a cycle of gate open and close time of each gate is configured to implement a quantum operation to process a single photon in the quantum network corresponding to a respective TSN flow. In some implementations, the system includes a first TSN domain to support one or more high time resolution TSN flows based on the high time resolution TSN mechanism and a second TSN domain to support one or more TSN flows based on the legacy TSN mechanism, the first TSN domain including the high time resolution network device, the second TSN domain including the legacy network device of the plurality of network devices.

[0048] Fig. 1 illustrates a non-limiting example of a conventional integrated TSN-5G system 100 in which a 5G network or system 106 is configured to be emulated as a single TSN component (e.g., a TSN bridge). Overall, the system 100 is configured as a deterministic TSN system to communicate data between end-devices, e.g., input / output (I / O) devices 102 and a controller 104, via the 5G system 106 (emulating as a TSN bridge) and one or more (conventional) TSN bridges 108 and using a TSN controller 110. The system 100 is configured based on standard methods for time synchronization and traffic management, allowing deterministic communication over standard Ethernet networks between end-devices, e.g., the I / O devices 102 and the controller 104. For example, the system 100 may operate in accordance with the IEEE 802. IQ TSN specification suite, which standardizes layer-2 communication for networking protocols providing deterministic communication while sharing the same infrastructure. For example, a number of standards establish various technological paradigms for a TSN system - clock synchronization (802. IAS, generalized Precision Time Protocol (gPTP)), frame preemption (802.3br and 802. IQbu), scheduled traffic (802. IQbv), and redundancy management (Frame Replication and Elimination for Reliability (FRER) IEEE 802.1CB). These standards work together at the Ethernet layer-2 to ensure that control and safety functions are executed while meeting their respective deadlines and constraints. As another implementation, similar integrated system may be configured to implement TSN techniques over a wireless local area network (wireless LAN) such as a Wi-Fi network, e.g., based on Wi-Fi 6 and other common wireless LANs.

[0049] For example, the 802. IQbv TSN standard provides scheduled transmissions for safety-critical data frames in a predetermined manner, and is incorporated herein in its entirety. As used herein, “TSN schema” can refer, without limitation, to networks, components, elements, units, nodes, hubs, switches, controls, modules, pathways, data, data frames, traffic, protocols, operations, transmissions, and combinations thereof, that adhere to, are configured for, or are compliant with, one or more of IEEE 802.1 TSN standards. The 802. IQbv TSN standard addresses the transmission of critical and non-critical data traffic within a TSN. Critical data traffic is guaranteed for delivery at a scheduled time while non-critical data traffic is usually given lower priority. Various traffic classes have been established according to IEEE 802. IQ that are used to prioritize different types of data traffic.

[0050] Ethernet frame preemption is defined by the IEEE 802.3br and IEEE 802. IQbu standards, which can suspend the transmission of a non-critical Ethernet frame, is also beneficial to decrease latency and latency variation of critical traffic. Resource management basics are defined by the TSN configuration models (IEEE 802.1Qcc). Centralized Network Configuration (CNC) 112 can be applied to the network devices (bridges, e.g., the 5G system bridge 106, bridges 108), whereas, Centralized User Configuration (CUC) 114 can be applied to user devices (end stations, e.g., the I / O devices 102), e.g., as specified in IEEE 802.1Qdj [xx], The fully centralized configuration model follows a software-defined networking (SDN) approach. In other words, the CNC 1 12 and the CUC 1 14 in the controller 110 provide the control plane instead of distributed protocols. In contrast, distributed control protocols are applied in the fully distributed model, where there may be no CNC or CUC.

[0051] High availability, as a result of ultra-reliability, may be provided by Frame Replication and Elimination for Reliability (FRER) (IEEE 802.1CB) for data flows through a per-packet-level reliability mechanism. This provides reliability by transmitting multiple copies of the same data packets over disjoint paths in the network. Per-Stream Filtering and Policing (802.1Qci) improves reliability by protecting against bandwidth violation, malfunctioning and malicious behavior. Further, the time synchronization in the TSN system may be defined by the generalized Precision Time Protocol (gPTP) (802. IAS), which is a profile of the Precision Time Protocol standard (IEEE 1588). The gPTP provides reliable time synchronization, which can be used by other TSN tools, such as Scheduled Traffic (802.1Qbv).

[0052] To achieve desired levels of reliability, TSNs employ time synchronization, and time- aware data traffic shaping. The data traffic shaping uses the schedule to control gating of transmissions on the network switches and bridges (e.g., nodes). In some aspects, the schedules for such data traffic in TSNs can be determined prior to operation of the network. In other aspects, the schedules for data traffic can be determined during an initial design phase based on system requirements, and updated as desired. For example, in addition to defining a TSN topology (including communication paths, bandwidth reservations, and various other parameters), a networkwide synchronized time for data transmission can be predefined. Such a plan for data transmission on communication paths of the network is typically referred to as a “communication schedule” or simply “schedule.” The schedule for data traffic on a TSN can bedetermined for a specific data packet over a specific path, at a specific time, for a specific duration. A non-limiting example of a technique for generating schedule for TSN data traffic is discussed in U.S. Application No. 17 / 100,356, which is incorporated herein in its entirety by reference.

[0053] Time-critical communication between end devices or nodes (e.g., the I / O devices 102 and the controller 104) in TSNs includes “TSN flows” also known as “data flows” or simply, “flows.” For example, data flows can comprise datagrams, such as data packets or data frames. Each data flow is unidirectional, going from a first originating or source end device (e.g., the I / O device 102) to a second destination end device (e.g., the controller 104) in a system, having a unique identification and time requirement. These source devices and destination devices are commonly referred to as “talkers” and “listeners.” Specifically, the “talkers” and “listeners” are the sources and destinations, respectively, of the data flows, and each data flow is uniquely identified by the end devices operating in the system. It will be understood that for a given network topology comprising a plurality of interconnected devices, a set of data flows between the inter-connected devices or nodes can be defined. For example, the set of data flows can be between the interconnected devices. For the set of data flows, various subsets or permutations of the dataflows can additionally be defined. Further, time-critical communication between end devices or nodes in TSNs includes “TSN streams” or “streams,” where each TSN stream may originate at a specific talker node intended to be communicated to one or more listener nodes. As such, each TSN stream may include one or more data flows, where each data flow is between the talker node (where the TSN stream originated) and a listener node.

[0054] Both end devices (e.g., 102, 104) and switches (commonly called “bridges” or “switching nodes”) (e.g., 106, 108) transmit and receive the data (in one non-limiting example, Ethernet frames) in a data flow based on a predetermined time schedule. The switching nodes and end devices must be time-synchronized to ensure the predetermined time schedule for the data flow is followed correctly throughout the network. For example, in Fig. 1, the clocks 116 represent that the various switching nodes and end devices in the TSN system 100 (including in the 5G system 106) are be time-synchronized with reference to a global clock (grandmaster clock timing). In some other aspects, only the switches can transmit the data based on the pre-determined schedule, while the end devices, for example legacy devices, can transmit data in an unscheduled manner.

[0055] The data flows within a TSN can be scheduled using a single device (e.g., the controller 110) that assumes fixed, non-changing paths through the network between the talker / listener devices and switching nodes in the network. Alternatively, the data flows can be scheduled using a set of devices or modules. The scheduling devices, whether a single device or a set of devices, can be arranged to define a centralized scheduler. In still other aspects, the scheduler devices can comprise a distributed arrangement. The TSN can also receive non-time sensitive communications, such as rate-constrained communications. In one non-limiting example, the scheduling devices can include an offline scheduling system or module.

[0056] TSN traffic may be tagged using a variety of mechanisms, including VLAN tag Ethernet address IP header information, and a combination of VLAN tag Ethernet address and IP header information. Traffic may be identified and tagged anywhere in the system before protocol data unit (PDU) identification is required. A TSN Talker may create multiple TSN flows (streams) with different TSN latency and determinism requirements and may be assigned different paths that meet the requirements. In some implementations of the subject invention, the latency and determinism values may be specified and offered to TSN applications as a limited set of static, discrete values, rather than an offering to accept an unlimited set of continuous values.

[0057] In some implementations, the I / O end device 102 may be, in various aspects, a complex mechanical entity such as the production line of a factory, a gas-fired electrical generating plant, avionics data bus on an aircraft, a jet engine on an aircraft amongst a fleet (e.g., two or more aircraft), a digital backbone in an aircraft, an avionics system, mission or flight network, a wind farm, a locomotive, etc. In various implementations, the I / O end device 102 may include any number of end devices, such as sensors, actuators, motors, and software applications. The sensors may include any conventional sensor or transducer, such as a camera that generates video or image data, an x-ray detector, an acoustic pick-up device, a tachometer, a global positioning system receiver, a wireless device that transmits a wireless signal and detects reflections of the wireless signal in order to generate image data, or another device.

[0058] Further, the actuators (e.g., devices, equipment, or machinery that move to perform one or more operations of the I / O device 102) can communicate using the TSN system 100. Nonlimiting examples of the actuators may include brakes, throttles, robotic devices, medical imaging devices, lights, turbines, etc. The actuators can communicate status data of the actuators to one or more other devices (e g., other I / O devices 102, the controller 104 via the TSN system 100). The status data may represent a position, state, health, or the like, of the actuator sending the status data. The actuators may receive command data from one or more other devices (e.g., other I / O devices 102, the controller 104) of the TSN system 100. The command data may represent instructions that direct the actuators how or when to move, operate, etc.

[0059] In some implementations, the controller 104 can communicate a variety of data between or among the I / O end devices 102 via the TSN 100. For example, the control system 104 can communicate the command data to one or more of the devices 102 or receive data, such as status data or sensor data, from one or more of the devices 102. Accordingly, the controller 104 may be configured to control operations of the I / O devices 102 based on data obtained or generated by, or communicated among the I / O devices 102 to allow for, e.g., automated control of the VO devices 102 and provide information to operators or users of the I / O devices 102. The controller 104 may define or determine the data flows and data flow characteristics in the TSN system 100.

[0060] Referring now to the 5G system 106 within the system 100, the 5G network or system 106 is a wireless communication network or system used to carry TSN traffic between various TSN end devices, e.g., the I / O devices 102 and the controller 104. In some implementations, the 5G system 106 is configured to emulate as one TSN bridge per User Plane Function (UPF) (similar to TSN bridges 108, according to the TSN standards discussed above). The 5G system 106 may be a New Radio (NR) network implemented in accordance with 3 GPP 23 and 38 series specifications (which are incorporated herein in their entirety), and integrated into the system 100 in accordance with the 3GPP Release 17 23.501 standard (for example, vl7.1.1 and V17.2.0), which is incorporated herein in entirety. As shown, the 5G system 106 may include various communication network (CN) components such as, in the 5G user plane, User Equipment (UE) 118, RAN (gNB) 120, User Plane Function (UPF) 122, and in the 5G control plane, application function (AF) 124, and session management function (SMF) and policycontrol function (PCF) 126, among other components, as defined in the 3GPP 23.501 standard. In some implementations, the 5G system 106 may be configured to provide an ultra-reliable low latency communication (URLLC) service. The 5G system 106 based on the New Radio (NR) interface includes several functionalities to achieve low latency for selected data flows. NR enables shorter slots in a radio subframe, which benefits low-latency applications. NR also introduces mini-slots, where prioritized transmissions can be started without waiting for slot boundaries, further reducing latency. As part of giving priority and faster radio access to URLLC traffic, NR introduces preemption - where URLLC data transmission can preempt ongoing non- URLLC transmissions. Additionally, NR applies very fast processing, enabling retransmissions even within short latency bounds.

[0061] In some implementations, 5G defines extra-robust transmission modes for increased reliability for both data and control radio channels. Reliability is further improved by various techniques, such as multi-antenna transmission based on multiple-input and multiple-output (MIMO) techniques, the use of multiple carriers and packet duplication over independent radio links.

[0062] Time synchronization is embedded into the 5G cellular radio systems as an essential part of their operation, which has already been common practice for earlier cellular network generations. The radio network components themselves are also time synchronized, for instance, through the precision time protocol telecom profile, e.g., based on a 5G internal system clock 190. This provides a good basis to provide synchronization for time-critical applications. For URLLC service, the 5G system 106 uses time synchronization for its own operations, as well as the multiple antennas and radio channels that provide reliability. Besides the 5G RAN features, the 5G system 106 may also provide solutions in the core network for Ethernet networking and URLLC. The 5G core network supports native Ethernet protocol data unit (PDU) sessions. 5G assists the establishment of redundant user plane paths through the 5GS, including RAN, the core network, and the transport network. The 5GS also allows for a redundant user plane separately between the RAN and core network nodes, as well as between the UE and the RAN nodes.

[0063] As noted above, in the integrated system 100, the 5G system 106 includes one TSN (virtual) bridge per UPF. The 5G system 106 includes TSN Translator (TT) functionality for theadaptation of the 5G system 106 to the TSN domain, both for the user plane and the control plane, hiding the 5G system 106’s internal procedures from the TSN bridged network. The 5G system 106 provides TSN bridge ingress and egress port operations through the TT functionality. For instance, the TTs support hold and forward functionality for de-jittering. Fig. 1 illustrates the case when the 5G system 106 connects an end station 102 to a bridged network 108; however, the 5G system 106 may also interconnect bridges 108.

[0064] For the 5G system 106 to be integrated into the TSN system 100, requirements of a TSN stream can be fulfilled only when resource management allocates the network resources for each hop along the whole path. In line with TSN configuration (802.1Qcc), this is achieved through interactions between the 5G system 106 and a configuration controller, e.g., a centralized configuration controller 110 (including the CUC 114 and the CNC 112) and / or a set of decentralized controller modules (e.g., as discussed below with respect to Fig. 2). The interface between the 5G system 106 and the CNC allows for the CNC 112 to learn the characteristics of the 5G virtual bridge, and for the 5G system 106 to establish connections with specific parameters based on the information received from the CNC 112. Bounded latency requires deterministic delay from 5G as well as QoS alignment between the TSN and 5G domains. For instance, if a 5G virtual bridge acts as a TSN bridge, then the 5G system 106 emulates time-controlled packet transmission in line with Scheduled Traffic per 802. IQbv for example. For the 5G control plane, the TT in the AF 124 receives the transmission time information of the TSN traffic classes from the CNC 112. In the 5G user plane, the TT at the UE 118 and the TT at the UPF 122 may regulate the time-based packet transmission accordingly. The different TSN traffic classes may be mapped to different 5G QoS Indicators (5QIs) in the AF 124 and the PCF 126 as part of the QoS alignment between the TSN and 5G domains, and the different 5QIs are treated according to their QoS requirements.

[0065] With respect to time synchronization, the 5G system 106 may implement the gPTP of the connected TSN network. The 5G system 106 may act as a virtual gPTP time-aware system and support the forwarding of gPTP time synchronization information between end stations 102 and bridges 108 through the 5G user plane TTs. All of the various 3GPP and TSN standards mentioned in this disclosure are incorporated herein by reference in their entireties.

[0066] Referring now to Fig. 2, which illustrates a block diagram of a system 200 architecture in accordance with some implementations of the subject technology. Broadly, the system 200 depicts a block diagram of an example implementation of an integrated TSN-5G system similar to the system 100 described above, and also include similar physical components as in the system 100 discussed above. However, unlike the system 100, the system 200 provides a novel architecture for an integrated TSN-5G system in which the 5G system 106 is configured as a set of discrete 5G components where each 5G component is configured to emulate as one discrete TSN block or element 202. In other words, in the system 200, the 5G system 106 is configured as a disaggregated structure including a plurality of TSN blocks 202-1 to 202-N, where each TSN block 202 is configured in accordance with TSN specifications (e.g., per IEEE 802. 1 and related standards discussed above), e.g., as a TSN bridge, TSN end device (i. e. , as a TSN Talker and / or a TSN Listener), or a combination of two. Further, instead of having a centralized configuration controller 110 to control the TSN-5G system, the subject technology provides for a plurality of distributed configuration modules 215 in a distributed controller 210 in the TSN-5G system 200. The configuration modules 215-a to 215-f may be interconnected in one or more topologies (mesh, star, tree) and each configuration module 215 may be responsible to communicate with and configure one or more TSN blocks 202. In some implementations, one or more of the configuration modules 215-a to 215-f may be implemented within or as part of a function (e.g., SMF 126) of the control plane of the 5G system 106. As used herein, a “topology” can refer to one or more arrangement(s) of a network which can include a plurality of nodes (e.g., sender devices, receiver devices, switches, or bridges) and connecting lines (e.g., communication links, or “hops” including wired communication links or wire-less communication links) between the nodes in the network. Each link can communicatively couple a corresponding pair of nodes. A set of links can be coupled in sequence via their respective nodes to define a link path, for example between an originating node and a destination node. Topologies may comprise, but are not limited to, one or more of mesh, star, bus, ring, and tree topologies.

[0067] In some implementations, the system 200 is configured to support and manage deterministic TSN data flows between a data source 204 (“source device”) and a data destination device 206 (“destination device”) via the 5G system 106 in accordance with TSN configurationincluding a TSN schedule determined by one or more of the configuration modules 215. The data source 204 and the data destination 206 may include one or more of the I / O devices 102 and the controller 104. Although not shown, the system 200 may also include TSN bridges 108 and other TSN components.

[0068] In some implementations, in the disaggregated structure, each of the plurality of TSN blocks 202-1 to 202-N may correspond to one specific component of the 5G system, e.g., the 5G network or system 106 shown in Fig. 1 and discussed above. For example, as shown in Fig. 3, the UE 118 may be configured to emulate as the TSN block 202-1, the RAN 120 may be configured to emulate as the TSN block 202-2, the 5G transport network link 140 between the RAN 120 and the UPF 122 may be configured to emulate as the TSN block 202-3, the UPF 122 may be configured to emulate as the TSN block 202-4, and the core network and / or other typical components of a 5G system (e.g., fronthaul, backhaul, Multi-access Edge Computing (MEC) module) may be configured to emulate as one or more TSN blocks 202-N. Each TSN block 202- 1 to 202-N is configured in accordance with TSN specifications (e.g., per IEEE 802.1 and related standards discussed above), e.g., as a TSN bridge, TSN end device (TSN Talker and / or TSN Listener), or a combination of two.

[0069] In some implementations, as shown in Fig. 4, each TSN block 202 includes a processor 402, a memory device 404, an internal configuration interface (ICI) 406, a transmission module 408, a reporting module 410, and TSN translators (TT)-l 412-1, TT-2 412- 2, and TT-3 412-3. The processor 402 may be a microprocessor or multi-core processor, an integrated circuit, a field programmable gate array, etc. that processes TSN configuration data and executes instructions (stored in memory device 404, for example) to process and transmit TSN data traffic from one or more TSN data flows in accordance with the TSN configuration data.

[0070] The memory device 404 may store a set of parameters describing the capabilities to support and execute a data flow (e.g., carrying URLLC data traffic) through the corresponding TSN block 202. In some implementations, the set of parameters include, but are not limited to, identity, link quality, link bandwidth. The identity parameter(s) may include the device type (i.e., whether the TSN block 202 is a TSN bridge or a TSN end station). The latency parameter(s) mayinclude at least port-to-port (start of TSN block to end of TSN block) latency, and latency variation (commonly known as “jitter”). The link quality parameter(s) may include at least packet error rate. The link bandwidth parameter(s) may include at least the available bandwidth in bits per second.

[0071] In some implementations, the set of parameters for a TSN block 202 may include a subset of parameters specific to 5G RAN including short transmission-time intervals, TSC assistance information (TSCAI), configured grant (CG) information, semi-persistent scheduling (SPS) allocation and / or other parameters as specified in, e.g., 3GPP TS 28.540. Further, in some implementations, the set of parameters for a TSN block 202 may include a subset of parameters specific to TSN including time synchronization properties, scheduled transmissions (Qbv) attributes, redundancy attributes including a number of RANs connected to, number of paths to UPF, path diversity, number of available frequencies, propagation characteristics, available radios, different physical media (e.g., free space optics). As an example, Fig. 5 illustrates an example set of parameters 502 for an example TSN block 202.

[0072] In some implementations, the set of parameters for a TSN block 202 may define a worst case time synchronization error, a worst case gate operation error, a maximum gate control list size, a maximum cycle time, a maximum gate interval duration, a transmission start delay, the like, or a combination thereof. The set of parameters may include a discrete set of deterministic parameters that may vary by the type of traffic handled by the TSN block 202. The set of parameters may be at least partially utilized to generate a TSN Schedule, configuration, or the like, that is realizable on the hardware of the TSN block 202. In the absence of such set of parameters, a TSN scheduling module has to take a lowest common denominator approach, wherein all devices of the system 200 including TSN blocks 202 are assumed to have the most limiting characteristics resulting in a sub-optimal solution. In this sense, the set of parameters enable better scheduling solution in the TSN system 200 resulting in improved performance metrics including latency jitter, packet delay variation, and bandwidth utilization.

[0073] In some implementations, the set of parameters for a TSN block 202 may further describe or relate to devices created, programmed by, or otherwise of different operation or manufacturer. In this sense, the set of parameters may define a set or subset of disparate devices(e g. heterogenous, as from multiple vendors), as opposed to homogenous or all-similar devices. For example, the set of parameters may include, but are not limited to, definitions of specific configuration models, error tolerances, hardware limitations, software limitation, and firmware options of each end node and switching node in the system 200. In this sense, the set of parameters enable scheduling and configuration of a heterogenous network comprising of devices from multiple vendors and of varying characteristics.

[0074] In some implementations, the set of parameters for a TSN block 202 may further the specific TSN features supported by each end node and switching node in the TSN system 200. For example, the set of parameters may define if a node or TSN block 202 supports one or more of time synchronization, time aware shaping, asynchronous shaping, frame replication and elimination for reliability, frame pre-emption, ingress policing, and other TSN features. The set of parameters may further define the specific version or variant of the feature or standard supported by end nodes and switching nodes in the TSN system 200. These set of parameters enable scheduling and configuration of a mixed capability network wherein end nodes and switching nodes have varying degree of support (including no support) for the desired TSN features and version.

[0075] Further non-limiting examples of the set of parameters for a TSN block 202 device may include, but is not limited to, additional parameters utilized for programming functionality of the respective TSN block 202. For example, additional set of parameters may define or enable for the programming of the respective TSN block 202 with a generated or scheduled TSN configuration. Non-limiting examples of the set of parameters may define or enable for the programming of the respective TSN block 202 can include, but are not limited to, a programming method, a communication protocol, a device login name, a device login password, a device programming port, a device programming file structure or file path for programming data, a device programming file format, a device configuration file format, a device schedule file format, the like, or a combination thereof. In this sense, this set or subset of parameters defining or enabling for the programming of the respective TSN block 202 with a generated or scheduled TSN configuration (collectively, “programming parameters”) and enable or allow for the system 200 to update, install, program, configure, or otherwise modify the set of TSN blocks 202 tooperate in response to, or in accordance with, a schedule or a configuration for the TSN system 200.

[0076] Further, each TSN block 202 may include at least one internal configuration interface (ICI) 406 configured to support interaction of the TSN block 202 with, e.g., its respective configuration module 215. The ICI 406 may be used to provide some or all of the set of parameters of the TSN block 202 to the respective configuration module 215, and receive from the configuration module 215 configuration data (e.g., transmission schedule, data flow identities, policing rules, etc.) to support one or more data flows through the TSN block 202. Each TSN block 202 may be configured to execute or operate according to the configuration data (received via the ICI 406) and transmit data for each data flow according to the specifications provided in the configuration data.

[0077] In some implementations, the configuration data received via the ICI 406 at a TSN block 202 from its respective configuration module 215 may include stream identification information, transmission schedule or a deadline or delay budget or (for rate-constrained traffic) a data rate, filtering and policing configuration information, redundancy scheme and / or other TSN configuration information.

[0078] TSN Talker information may be separated into different frequency components that require different TSN flow latency and determinism requirements. Conversely, TSN flows from different TSN Talkers may be aggregated into a single TSN flow in order to achieve greater capacity and higher channel utilization. Having discrete cycle times in the integrated TSN-5G system may help ensure ease of TSN flow aggregation.

[0079] In some implementations, each TSN block 202 may include the transmission module 408 that is configured to send the transmission of the specific data flow as per the schedule, deadline, delay budget, or data rate received in the configuration data from the configuration module 215 via the ICI 406. In one example in which the TSN block 202-1 corresponds to a UE 118 of the 5G system, the transmission module 408 is configured to send the data transmission based on the resource scheduling of the 5G air interface (between the UE 118 and the RAN 120). The resource scheduling of the 5G air interface may be phase aligned with the integrated TSN-5G system’s cycle time. The transmission module 408 may assign resource elements of the 5G component corresponding to the TSN block 202 (of which 408 is a part) in such a manner as to be able to meet schedule transmissions for each Qbv stream. For example, instead of using classical 802.1Qbv style gate control, the UE 118 corresponding to the TSN block 202-1 may use a phase offset (in reference to a cycle time) to align the transmission of a TSN data stream with the assigned schedule. In this example, instead of the UE 118 getting this phase offset from the CNC, the UE 118 may get the phase offset as a special command from the RAN 120.

[0080] In some implementations, each TSN block 202 may also include a reporting module 410 configured to monitor run-time behavior of the TSN block 202 and report the behavior either through the ICI 406 or via a separate interface of the TSN block 202. This behavior monitoring includes metrics including but not limited to packet drops and missed transmission windows.

[0081] Referring back to Fig. 2, the subject technology provides for a plurality of distributed configuration modules 215 in a distributed controller 210 in the TSN-5G system 200. The configuration modules 215-a to 215-f may be interconnected in one or more topologies (mesh, star, tree) and each configuration module (CM) 215 may be responsible to communicate with and configure one or more TSN blocks 202. For example, the CM 215-a may be responsible for and operatively and communicatively connected to the TSN blocks 202-1 and 202-2. The CM 215-b may be responsible for and operatively and communicatively connected to the TSN blocks 202-3. The CM 215-c may be responsible for and operatively and communicatively connected to the TSN blocks 202-3 and 202-N. As such, the TSN block 202-3 may be configured and controlled by both the CM 215-b and the CM 215-c. For example, a portion of functionalities (e g., with respect to a first type of TSN applications) at the TSN block 202-3 may be configured and controlled by the CM 215-b, and another portion of functionalities (e.g., with respect to a second type of TSN applications) at the TSN block 202-3 may be configured and controlled by the CM 215-c.

[0082] In the example shown in Fig. 2, the configuration modules 215 are arranged in a tree structure where the CM 215-f forms the highest level of the tree structure, the CM 215-a, 215-b, and 215-c form the lowest level of the tree structure, and the CM 215-d and 215-e are between the highest and lowest levels of the tree structure. The configuration modules 215, however, areoperatively and communicatively connected to each other via an API 230. In some implementations, in a tree structure (e.g., as shown in Fig. 2), the configuration modules 215 may communicate with other configuration modules 215 at an adjacent tree level (one tree level higher or lower). However, in other topologies (e.g., in a mesh or peer-to-peer structure), any two configuration modules 215 in a distributed controller 210 may be operatively connected to and communicate with each other directly.

[0083] In some implementations, each configuration module 215 may be either an external utility responsible for configuring one or more corresponding TSN blocks 202 or may be configured as a software module within the TSN block 202. Each configuration module 215 may be configured to determine and provide to TSN blocks 202 controlled by the configuration module 215 configuration data including a TSN schedule for one or more data flows to be transmitted through the TSN blocks 202. The configuration modules 215 may exchange information with each other using a standardized API 230. The exchanged information may include information regarding cycles times for the TSN system (e.g., supported admin cycle times (ACTs) including discrete levels of ACT buckets each corresponding to a specific data flow, max / min cycle times), configuration data including transmission schedule (include time offsets / duration / resources for transmission) for one or more TSN blocks 202, and information to request or respond to requests for resource allocations. In some implementations, one or more of the configuration modules 215 may be configured as the CNC 112 and / or the CUC 114 of the TSN controller 110 discussed above. In some implementations, one or more of the configuration modules 215-a to 215-f may be implemented within or as part of a function (e.g., SMF 126) of the control plane and / or an element or function (e.g., the 5G transport network 202-3) of the user plane of the 5G system 106. For example, the SMF 126 may be configured to support functionalities of the CUC 114 and / or the CNC 112. In some implementations, the 5G transport network 202-3 may be configured to support functionalities of the CNC 112.

[0084] In some implementations, each configuration module (CM) 215 receives from the ICI 406 of the TSN block 202 controlled by the CM 215 some or all of the set of parameters (discussed above) of the TSN block 202. The CM 215 also receives, from another entity in the system 200 through the API 230, information on the data flows to be configured through the TSN block 202. In a non-limiting example, the data source 204 and / or the data destination 206provide requirements for a data flow between the data source 204 and the data destination 206 to the CM 215 either directly or via an intermediary such as a CUC 114. In some implementations, the CM itself may allow users to define the set of data flows to be configured via a user interface. As used herein, the information on the data flows may include or define a set of data flows, data streams, transmission pathways (predetermined or otherwise adapted), or the like, to define the desired TSN communication pathways between the data source 202 and the data destination 206. A set of non-limiting examples of the information on the data flows may include a maximum allowable latency, data rate, data frame sizes ("payload"), data frame destinations, band allocation gaps, the like, or a combination thereof.

[0085] Based at least on the received data flow information and the set of parameters for the TSN block 202, the CM 215 determines a “solution” (or configuration data), wherein the solution would indicate how to handle each data flow through the TSN block 202. This solution may include time aware schedule, policing rules, amongst other things, as discussed in U.S. Application No. 17 / 100,356, which is incorporated herein in its entirety by reference. The CM 215 may then send this solution or configuration data to the TSN block 202 via the ICI 406. The TSN block 202 may then executes this solution and transmits data for each flow according to its configuration. In some implementations, as an example process to make the distributed CMs 215 compute a solution, at each level of the tree structure of the CMs 215, a same system modulo theory (SMT) solver may be used, wherein the data flows and their requirements are expressed as constraints and a linear programming methodology is used to solve for a feasible solution. The solution from a lower level of the CM tree is input as used resources (represented again by constraints) at the one-level higher on the CM tree. This process is repeated until the top-most level of the CM tree is reached, where a global solution is determined.

[0086] In some implementations, different data sources (e.g., the data source 204) and their applications operate at different cycle times or intervals. Relatedly, different data sources and destinations (and their applications) require different levels of time determinism for many data flows therebetween. In a conventional TSN system, a converged cycle time (commonly known as “admin cycle time”) is determined that works for all the data flows in the network. However, in some implementations of the subject disclosure, the integrated TSN-5G system may use a set of discrete / quantized cycle times in the network. Each data flow chooses one of the availablequantized cycle times to operate on. The scheduling in the TSN-5G system 100 for scheduled transmissions may be based on quantized / discrete set of cycle times. As an example, the integrated TSN-5G system 100 may limit the available stream intervals and therefore the corresponding cycle times to a set of discrete values including, but not limited to, essentially 1, 10, 100, 1000 milliseconds. Similarly, the stream or data flow requirements may be restricted, e.g., jitter (packet delay variation) requirements could be limited to a predetermined set of discrete values including, but not limited to, essentially 1, 10, 100, 1000 microseconds. In some implementation, a different set of discrete values may be used depending on the applications and use cases supported by the integrated TSN-5G system. For example, geographically dispersed system may use discrete cycles times in the order of milliseconds. In yet another example, a system restricted to a local factory may use discrete cycle times in the order of microseconds. The members of this discrete set may be regularly or irregularly spaced or follow other statistical distribution (including but not limited to logarithmic, linear, gaussian) without defaulting to continuous set of cycle times. In another implementation, set of cycle times are standardized in such a manner that all TSN blocks have cycle times that are a product of elements chosen from a small, common set of prime numbers. This ensures that all composite cycle times will be easily computed by the TSN scheduler and results in one common network cycle time.

[0087] Each TSN block in the integrated TSN-5G system may support a set (wherein a set includes one or more) of cycle times. The CMs 215 configure the TSN-5G system 106 or 200 to enable scheduled transmission of data flows across TSN blocks 202 operating at different cycle times. In some implementations, the TSN blocks 202 may be required to operate with compatible cycle times, where compatibility implies the cycle times are an integer harmonic of each other. When an application requests an interval that does not directly map to the available set of discrete cycle times across the set of TSN blocks 202 the flow traverses, the CMs 215 may fit to the closest available cycle time. The closest available cycle time would be an integer multiple or integer divisor of the available cycle times. The CMs 215 may exchange the supported quantized / discrete set of cycle time information with each other during the configuration process. In this instance, the subject disclosure allows a disaggregated TSN-5G system to create feasible configuration for a large number of data stream s / flows. In the absence of a quantizedcycle / interval, the configuration typically requires large computation time and may even prevent the discovery of a feasible solution.

[0088] In some instances, each integrated TSN-5G network slice in the 5G system 106 may have a predefined set of supported cycle times and jitter bounds. In some instances, network slices might be more granular than the typical 5G network slice as per 3GPP specification 23.501, which is incorporated herein by reference. In some implementations, the TSN-5G system 106 or 200 may be sliced based on the TSN cycle times. For example, a 5G network supporting multiple critical services may have URLLC slices dedicated to the periodicity of the applications and their streams. For example, services that have applications operating at approximately 1 msec period may have a dedicated slice which operates at 1 msec cycle time. Similarly, services and applications operating at 100 msec period (or interval) may have a dedicated slice in the integrated TSN-5G system that operates at 100 msec cycle time. Such cycle-time slicing improves both the speed of configuration as well as the overall network performance. In some implementations, the TSN block 202 exposes the supported cycle time(s) for a given slice to its respective CM 215 though its ICI 406. The CMs 215 in turn may exchange with each other the supported cycle times for the TSN blocks under their management via inter-config module API 230 in order to create a configuration solution for the sliced TSN-5G system.

[0089] In some implementations, the solution or configuration data determined by a CM 215 may include, but is not limited to, a collective or set of configurations, timings, commands, controls, instructions, the like, or a combination thereof, for operating the respective TSN block 202 in accordance with the characteristics (e.g., as defined by the set of parameters) of the TSN block 202. In some aspects, the configuration data may include a specific transmission information for individual or collective (e.g. “global”) data frame transmission for one or more respective TSN blocks 202. The transmission information can include temporal information for the transmission of the data frame. In one or more aspects, the configuration data for a data frame can include a transmission start time. For example, the transmission start time can be the time at which the transmission of the data frame from the respective TSN block 202 initiates. In an aspect, the transmission of the data frame can be initiated by a selective opening of a gate of the respective TSN block 202 to transmit the data frame, as a data flow to a destination node (e.g., another TSN block 202). Conversely, the transmission of the data frame can be ceased orprevented by a selective closing of the gate of the respective TSN block 202 to transmit the data frame. The configuration data may also define or assign a specific path or link communicatively coupling the respective TSN block 202 and another node to transmit the data flow thereon. Additionally, the configuration data may define a duration of the transmission of the respective data flow from the respective TSN block 202. In an aspect, the duration of the data flow transmission can be defined by a time period between the selective opening of the gate (i.e., to transmit the data frame) and the selective closing of the gate of the respective node (i.e., to cease transmission of the data frame to the destination node).

[0090] In a conventional TSN system, the TSN schedule is expressed as an absolute time offset in a periodic cycle at which a TSN block is instructed to transmit that data. However, that may be too restrictive for a 5G system 106 composed of components from multiple vendors. In some implementations, a deadline-based schedule is determined and provided with the configuration data by a CM 215. The deadline-based schedule may instruct the TSN block 202 to transmit the data of a configured data flow no later than a deadline (which is expressed in terms of absolute time in a periodic cycle). In some implementations, the delay budget based approach would instruct the TSN block to transmit the data frame of a configured data flow within a delay budget. As such, under the delay budget based approach, the TSN block 202 is required to send a data frame arriving at its ingress port within a certain duration to its egress port. Such a scheme would not require every TSN block 202 to be time synchronized. In some implementations in which the TSN block 202 is configured under a rate constraint, the TSN block 202 is configured to transmit the data frames of a given data flow in a manner that the average or peak transmission rate (in bits per second) does not exceed a configured value (per the configuration data from the CM 215).

[0091] In some 5G systems, TSN blocks may be a set of shared resources made available by network slicing based on service profiles bounding network latency, periodic cycle including but not limited to delay / budget. In such implementations, two level scheduling may exist where the 5GS TSN-AF may enable configuring the TSN blocks 202 as a shared resource in addition to slice level TSN scheduling. In either case, the configuration attributes such as resource identifier may identify the TSN blocks for the appropriate configuration. As an example, a service provider may have multiple service profiles with specific periodic cycles, and multiple tenants of theservice provider may utilize the same TSN blocks as specified by the 5GS TSN-AF configuration and may perform TSN flow aggregation. In some implementations, a service provider may provide a set of non-shared TSN blocks where only a single layer of service profile may exist. Device specific operating / required resource sharing mode may be available to the CNC 112 through TSN-AF.

[0092] As an example implementation of the deadline / delay budget approach by a TSN block 202, when a data frame arrives at an ingress port of the TSN block 202, the TSN block 202 would note the arrival time of the data frame using its local clock. The TSN block 202 may then identify the frame as belonging to a configured data flow, and may then start a countdown timer equal to the configured delay budget for that data flow. Using the transmission module 408, the TSN block 202 may prioritize the transmissions of data with least amount of time left. If the timer of a packet expires before it is transmitted, that event is recorded as a missed transmission and be accounted in the monitoring metrics by the recording module 410.

[0093] In some implementations, with respect to scheduled transmissions between the TSN block 202-1 (corresponding to the UE 118) and the TSN block 202-2 (corresponding to the RAN 120) may involve “enhanced” allocation (assignment and transmission) of uplink and downlink transmissions between the UE 118 and the RAN 120 in order meet the schedule assigned by the CM 215-a to the TSN block 202-1 corresponding to the UE 118. In some implementations, the CM 215-a may take into account of UE 118 buffer status and radio conditions as reported by RAN 120 when instantiating the TSN schedule and may adjust or report the required change in requested schedule. In some other implementation, the CM 215-a may send a real-time feedback on the radio conditions as received from RAN 120 to a master CM, e.g., the CM 215-d. This feedback loop may support re-calculating the TSN schedule to meet the packet delay budget either at this specific TSN block or across the TSN blocks on a given end-to-end path.

[0094] In this implementation, the link quality may be monitored and the CM 215-a may continuously adjust the radio resources in the configuration data to meet the transmission schedule. Radio resources may include but not limited to a logical channel, transmission power, and UE specific slot duration. In some implementations, a static assignment of fixed / determini Stic uplink and downlink slots for a given UE 118 may be made such that, e.g., allUEs connected to a given RAN slice are given a scheduled transmission slot. 5G native over- the-air scheduling may be used to determine if the transmission from the UE 118 will meet the transmission deadline. If not, the UE 118 may request elevated access to the RAN 120 to achieve the schedule transmission. In some implementations, the scheduling in the 5G system 106 for scheduled transmissions may be based on quantized / discrete set of cycle times, wherein the set includes at least a 100 msec admin cycle time. In accordance with the subject technology, the radio link between the UE (e.g., represented by TSN block 202-1) and RAN (e.g., represented by TSN block 202-2) may be sliced based on the cycle time. In some implementations, the uplink and downlink between TSN block 202-1 and TSN block 202-2 may have radio resources allocated to each network slice based on the cycle time of the slice. For example, a 1 msec cycle time slice would require radio resources (channels, airtime, etc.) capable of delivering data at the 1 msec rate.

[0095] In some implementations, 5G resource elements (e.g., frequency and time slots) may be scheduled such that they meet TSN flow latency requirements in addition to "standard" 5G scheduling traffic prioritization requirements. More specifically, 5G timeslots for a TSN flow may be allocated such they transmit the TSN flow's messages at both the proper cycle time offset (phase) and within the time limit (TSN window time) required by the TSN schedule. In this case, the 5G scheduler differs from a "traditional" TSN Ethernet port in that multiple messages may egress simultaneously if transmitted on different frequencies. In some aspects, under the presence of poor RF channel conditions, the 5G system 106 may send multiple copies of a messages over different frequencies in order to increase the probability of meeting the transmission schedule and / or deadline.

[0096] To achieve reliable data transmissions in the system 200, redundant flow paths may be implemented. Disaggregated TSN blocks 202 of the 5G system 106 allow handling error (delayed, dropped, or corrupted frames) in a better way. In some implementations, UE 118 may initiate two redundant disjoint PDU Sessions to UPF 122 for redundancy in which case 5GC may configure the NG-RAN for dual connectivity according to 3GPP 38.300. In some other implementations, FRER may be used between some TSN blocks 202, but not others. For example, redundant streams may be implemented over the air interface between the UE 118 (TSN block 202-1) and the RAN 120 (TSN block 202-2) and then combined at the RAN 120,and can be split again over the core network (TSN block 202-3, 202-4), if needed. As shown in Fig. 1, current redundancy requirement according to 3GPP 23.501 is maximally disjoint paths between the UE 118 and the UPF 122. However, in accordance with the subject technology, there is no need to establish redundant disjoint paths across the entire 5G system, and instead may be implemented for only a portion of the 5G system. For example, in case of the over-the- air interface between the UE 118 and the RAN 120, the redundancy requirement may specify that the two paths should be on different frequencies or different MEMO channels or different time slots. In some instances, the subject disclosure allows for flexible use of redundancy including but not limited to more than two data paths, merging and splitting of data flows between TSN blocks, and support of TSN blocks with varying degree of redundancy capabilities.

[0097] The concept of partitioning the 5GS into multiple TSN blocks (e.g., as discussed above with respect to Fig. 2) may potentially enhance security if strict scheduling can impede the flow of malicious traffic between said blocks. However, enabling the 5GS to operate as multiple TSN blocks may introduce security vulnerabilities, primarily via configuration. Specifically, TSN users may become aware of internal 5GS details and connectivity that impact other users sharing the same physical and logical infrastructure. This may occur during the required TSN network discovery phase (e.g., via information returned by the link layer discovery protocol (LLDP)). TSN users may also misconfigure either their own or other users’ configuration. This may be partially addressed using NETCONF’s notion of secure subtrees, where users have a limited view into their own data model subtree. The 5G system may inherently have a notion of isolated network slices, depending, for example, on whether TSN is implemented virtually (via software) or physically (via hardware). The infrastructure provider may have to set limits on what physical and logical capabilities are exposed to each TSN user. This may be done via the 5G network exposure function (NEF). The subject disclosure provides a solution to the security problem by using “virtual TSN blocks.” Virtual TSN blocks are internal 5G TSN blocks that contain only the capabilities offered by the user’s 5G network slice. In other words, users may only see and can configure the TSN block information that is exposed via the 5G network slice, and no more than that. In this sense, the internal 5G TSN block is the intersection of the set of information contained by the internal TSN block and the 5G network slice offered to the user.

[0098] In some implementations, IETF DETNET standards (as provided at IETF: "Deterministic Networking Working Group" - https: / / datatracker.ietf.org / wg / detnet / about / ) may be implemented or integrated into a 5GS to interconnect islands of smaller Ethernets conforming to TSN. The 5GS may utilize DETNET to enable the transport of TSN messages over IP layer 3 (rather than layer 2). Envisioning such a system, techniques discussed in the present disclosure include a 5GS that supports a DETNET edge, relay, and transit nodes interconnecting spatially separated TSN networks, to create a larger, composite TSN over 5G. All of the aspects of an integrated TSN-5G system provided in this disclosure are applicable to (but are not restricted to) the TSN islands of the 5G DETNET, and in particular, the TSN blocks of disaggregated TSN.

[0099] DETNET is comprised of the following components: (1) TSN End System: the IEEE conformant end-system that communicates with the DETNET Edge Node (2) DETNET Edge Nodes: process TSN frames into the DETNET (3) DETNET Relay Nodes: (4) DETNET Transit Nodes: provides congestion avoidance for time-sensitive messages. DETNET is routed, rather than bridged, thus, enabling routable TSN messages between TSN LANs. Essential TSN Ethernet frame information is either transported or reconstructed in the transport among LANs. DETNET accomplishes its higher layer functions by adding sublayers: (1) DetNet service sublayer: provides DetNet service (e.g., service protection), to higher layers in the protocol stack and applications and (2) DetNet transport sub-layer: supports DetNet service in the underlying network (e.g., by providing explicit routes and congestion protection) to DetNet flows and encapsulating the TSN Ethernet frames. DETNET routing incorporates IP headers are modified per standard router behavior, e.g., time-to-live (TTL handling), where TTL specifies the maximum time the routable IP message is allowed to survive, clearly related to the TSN maximum latency requirement.

[0100] The DETNET components may reside within any computational element of the 5GS, specifically within the 5G MEC or Core. Thus, in one implementation, the 5GS may be a fully compliant DETNET that interconnects TSN LANs. In order to provide determinism, DETNET may reserve data plane resources for DetNet flows in some or all of the intermediate nodes along the path of the flow. DETNET may provide explicit routes for DetNet flows. DETNET may distribute data from DetNet flow packets over time and / or space to ensure delivery of each packet’s data in spite of the loss of a path. Thus, the TSN CNC / DNC and scheduler, as describedabove, may require interaction with DETNET, specifically the ability to configure flow paths (including redundant flow paths), TTL, and acquire routing latency and jitter. TSN traffic shapers, time-aware shaping, and network calculus may be used to achieve the required level of determinism in the 5G DETNET.

[0101] It is also noted that a hybrid 5GS, in which portions are TSN (layer 2) and portions are DETNET (layer 3) may coexist and interoperate. In such cases, the DETNET portion of the network may itself be treated as a TSN block (or blocks) 202, as discussed above n.

[0102] Further with respect to caching within the 5GS to minimize latency and increase determinism for TSN applications, the amount of storage, location, and naming of information in the 5GS may be managed in such a manner to enable rapid and shorter proximity access to minimize jitter. Each piece of information may be cryptographically signed to increase its security and access provided through a hash of encrypted signature and the information stored in 5GS components such as the MEC. A cache forwarding unit will track each data request to allow optimal forward, placement, and service of the cached data. The TSN CNC / DNC and scheduler may compute where to position cached information within the network (specifically the 5GS) to maximize access and minimize jitter (packet delay variance) among 5G applications.

[0103] Real-time MEC applications typically have well-defined characterizations of their behavior. Cloud (cloud computing) and fog (fog computing) 5G MEC applications may be partitioned into microservices with hard, real-time constraints that are provided to the TSN scheduler. The constraints may be the longest (worst-case) time to complete a call to the service or a clearly defined statistical description as per a network calculus requirements for an arrival or service curve. In some implementations, microservices may be chained together to create a complete MEC application. By breaking computation down into a series of smaller microservices, each service may be better controlled and managed and able to provide more determinism. Each microservice may be abstracted as an internal TSN block, comprised of deterministic input, output, schedulable operation, and coordination with the 5G-TSN AF. The microservices may reside on the same or spatially distinct processing systems interconnected via TSN-scheduled communication.

[0104] Such hard real-time processing may include the 5G MEC and 5G Core functions. Messages ingress and egress from MEC TSN blocks following a deterministic schedule that can be computed by the TSN scheduler. Note that such TSN blocks will be referred to as “computational TSN blocks.” Given that messages generated by the MEC and their corresponding size and transmit times may vary depending upon the computational complexity of the MEC processing task, processing load, and application state, the TSN scheduling component can utilize an internal model, such model being a simulation, emulation, or purely analytical or a hybrid of each, of the MEC processor for TSN scheduling purposes (aka a digital twin). The TSN scheduling component can then generate a complete, end-to-end TSN schedule for all messages flowing among the 5G UE, MEC, and 5G Core, and any cloud processing that is required for a real-time application, where 5G Core and cloud processing are similarly modeled by the TSN scheduler. The TSN schedule can dynamically recompute schedules as required to maintain the required determinism for the 5G TSN real-time MEC / cloud application as the effective processing rate, and thus output message transmission time, varies. The TSN scheduler can provide feedback to the application developer (and for management and deployment) regarding the best location (UE, MEC, cloud) for each processing component of a real-time 5G application, considering link speeds, variation, processing capability, available memory, etc. The TSN system may employ a gate-based approach or a rate-control mechanism such as leaky bucket and may use any number of optimization techniques or network calculus to determine feasible schedules. Thus, a complete flow for a TSN application will include not only an end-to- end path through the network for a specific message, but also the complete processing path through all computational TSN blocks (microservices) acting on the information in the message. IEEE 802.1CB redundant paths can be configured through either redundant or parallel computational TSN blocks (microservices). One should be able to visualize the complete realtime processing activity encoded in the TSN schedule in this invention, where computational TSN blocks appear as Ethernet bridges with the difference that they either process messages or can create new messages that egress on a deterministic schedule.

[0105] MEC applications are configured to use TSN flows (to participate as TSN Talkers or Listeners) using NETCONF, RESTCONF, or a RESTful API. Messages defined in the aforementioned protocols contain IEEE 802. IQcc information required to configure the TSNflows used by MEC applications. Additionally, a MEC application is designed to move from one MEC platform to another and a RESTful API is defined to query the current platform’s TSN configuration to verify that it has the required deterministic communication requirements, specifically including latency and jitter. It also has a RESTful API containing the aforementioned information required to notify the TSN CNC of its new location and required information to dynamicall reschedule TSN traffic to its new location. As mentioned, IEEE 802.1CB may be used to establish redundant TSN flows to anticipated locations the MEC application may migrate. The TSN scheduler, i.e., the Centralized Network Configurator (CNC) or Distributed Network Configurator (DNC), may be a MEC application offering 5G TSN scheduling-as-a- service and configuration-as-a-service, useful for dynamic rescheduling, where low latency is required.

[0106] A TSN application may transmit a timing performance profile-query microservice request with the goal of determining statistical information regarding processing time. When responding to such a request, the microservice will execute the request and return both the result and a timing performance profile. The timing performance profile may contain at least the network start and end time of the microservice call, and may optionally contain the start-time and end-time of all called subfunctions. The information may also contain an average of the MEC processor load during the timing performance profile. The timing performance profile may be used by the TSN application to refine TSN scheduling where microservices are required to process TSN traffic flow. The timing performance profile may be obtained during live operation, where output from the profile is used normally, or as a special test sample prior to live operation. The timing performance profile information may be used to determine which MEC hardware to employ for current and future operations and as constraint information for the TSN scheduler.

[0107] The subject disclosure also provides additional new aspects including: (1) TSN- scheduled 5G core functions; (2) Ensuring the CPU has direct time synchronization with the Ethernet hardware timestamping mechanism; (3) Enabling TSN scheduling of specific 5G network function and processes; (4) Adding new time-aware programming features e.g., timebased event processing; (5) Integrating conditional processing based upon time, e.g., real-time programming implemented via YANG configuration of microservice scheduling to implementservice chaining (see httpsj / / www rfc~editor;o^^ / pdf^ / rfc7758.LtxL df for example of YANG scheduled operation).

[0108] Further, a LinkDelayStatistic (implemented as a YANG model) cumulative distribution function data model may be implemented within the TSN-5G system 106 or 200. In such an implementation, wireless links may collect and feed information to the CNC’s scheduler which would then utilize it for scheduling variable speed links. The LinkDelayStatistic YANG model may also provide information regarding whether the link delay is stationary and ergodic. The scheduler may use this information to rely on a given sample to predict the future and create an accurate schedule. The CNC may then utilize this knowledge for each TSN block to deploy the best possible TSN traffic shaping or gate schedule, including the use of network calculus in determining the result.

[0109] The subject disclosure also envisions a virtualized network function (VNF-TSN), capable of residing as software within the 5G system. It may require specialized processor hardware to support real-time operation. In some implementations, TSN may be provided as software-defined TSN (SDN-TSN) and 5G TSN-as-a-service (TaaS). In some implementations, VNF-TSN may be configured within every 5G sub-component (TSN block): UE, Radiohead, CU / DU, RAN, MEC, Core, etc. As discussed above, microservices may be chained together as part of TSN scheduling. Each microservice can expose its service time characterization to the TSN schedule. The service is part of the delay, but it may have more variance than a communication link. In such an implementation, the service is the link in this integration of microservices with TSN scheduling. Network calculus may be used to incorporate processing delay. TSN input provides a clear arrival curve. Processor execution time provides a service curve (we assume 5G equipment has a well-characterized processing time).

[0110] In another aspect of the subject disclosure, a time-aware MEC platform is defined to be a platform that acts as a PTP client (conformant to 802.1 AS End Station) and if needed a PTP bridge (conformant to 802. IAS Bridge). A PTP bridge along with a network bridge functionality is needed for a virtualized MEC platform that runs multiple slices (OSes, VMs, containers) in parallel. Typically, a virtual bridge / switch is used in virtualized compute platforms. In this disclosure, a TSN-enabled virtual switch is defined, which includes Time awareness. The Timeaware PTP client in a MEC platform runs a PTP state machine along with a servo to synchronize the locally available clock with grandmaster clock in the network. Furthermore, the MEC platform synchronizes the system clock to PTP clock, wherein system includes operating system, network stack, application stack or any other software and hardware elements that utilize a clock. This enables each MEC application to operate on the synchronized PTP time. In one example, MEC host operates this PTP client and provides all MEC applications with the synchronized time via the virtualization infrastructure (say as system / host time). In another instance, every MEC application may run an individual instance of PTP client connected to the host via a time aware bridge.

[0111] As a configuration interface, 3GPP 23.501 specifies a centralized configuration model in which a CNC configures the 5GS as a time aware bridge. Similarly, a MEC platform should be configurable with a CNC as a time aware end station or a time aware bridge. This MEC may support configuration using 802. IQcw yang models for TSN features including time aware shaping, forwarding, and frame replication and elimination for redundancy. Furthermore, the MEC host may have a CUC component that provides the data flow requirements of the resident applications to a CNC using the 802.1Qcc interface. MEC may also provide the information about its TSN capabilities to the CNC so that CNC can model the MEC accurately. For example, a MEC can present itself as a TSN end station originating a certain set of data flows. The CNC will model MEC appropriately in the network and generate the correct configurations. The MEC shall support identification of data streams in collaboration with the OS and applications. The specific functionality varies depending on the TSN awareness of MEC components. TSN unaware applications on a MEC host requires a IP stream identification in a MEC bridge.

[0112] TSN fronthaul / backhaul (e.g., TSN block 202) may connect directly to the MEC, providing deterministic input to the MEC. However, MEC applications are meant to continuously migrate, or perhaps more intuitively “float,” to the edge of the 5G network to remain closest to their potentially mobile clients. Thus, MEC applications that require determinism will specify a minimum acceptable packet delay variance (MPDV) threshold. A MPDV may be incorporated into the specification of all MEC applications, which may limit feasible application locations to those MEC platforms that exist as TSN blocks within the 5GS. The application must ensure that the proper TSN stream identification and translation rules areimplemented on the new MEC platform (which may be a single processor or a subnetwork of processors) such that the MEC Talker / Listener message frames are properly tagged and handled. MEC applications may want to carry their own configuration instructions when possible in order to “self-install” as they migrate to new MEC platforms. It is noted that a load balancing mechanism may be employed to ensure users do not overwhelm any set of MEC applications and MEC applications are distributed in an optimal manner. In other scenarios, redundant MEC platforms and applications may be instantiated and / or MEC applications migrate due to noise, rather than due strictly to mobility. Multiple MECs may also be connected as TSN redundant systems.

[0113] Figs. 6A and 6B illustrate an integrated TSN-5G system 600 (similar to the system 200) including a TSN block 605 (similar to the TSN block 202-N) representing or corresponding to a Multi-access Edge Computing (MEC) module. The TSN block 605 is configured as a data source / sink (i.e., as a TSN end station), but is located within the 5G system 106 as opposed to arranged at the edge of 5G system 106. The TSN block 605 may be configured as a bridged end station.

[0114] Referring to Fig. 8, an application data stream may span multiple integrated TSN-5G systems 805 and 810. In this case, TSN blocks may be geographically distributed interconnecting more than one 5G systems using a TSN compatible transport 820 including but not limited to a 5G backbone, private network tunnel or other wide area networks. In this subject invention, the TSN blocks are configured by their respective CMs 215. In some implementations, the configuration across the two TSN-5G systems 805, 810 may be coordinated through a centralized configuration utility (CNC) 112. In some other implementations, the CMs 215 between the two TSN-5G systems 805, 810 may communicate directly. In some implementations, multiple CUC’s and CNC’s may be used to capture the user requirements and generate TSN solutions and techniques provided in this disclosure (e.g., TSN Schedule, forwarding instruction, etc ).

[0115] Fig. 7 illustrates an electronic system 700 with which one or more implementations of the subject technology may be implemented. The electronic system 700 can be, and / or can be a part of the TSN block 202 and / or the configuration module 215. The electronic system 700 mayinclude various types of computer readable media and interfaces for various other types of computer readable media. The electronic system 700 includes a bus 708, one or more processing unit(s) 712, a system memory 704 (and / or buffer), a ROM 710, a permanent storage device 702, an input device interface 714, an output device interface 706, and one or more network interfaces 716, or subsets and variations thereof.

[0116] The bus 708 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the electronic system 700. In one or more implementations, the bus 708 communicatively connects the one or more processing unit(s) 712 with the ROM 710, the system memory 704, and the permanent storage device 702. From these various memory units, the one or more processing unit(s) 712 retrieves instructions to execute and data to process in order to execute the processes of the subject disclosure. The one or more processing unit(s) 712 can be a single processor or a multi-core processor in different implementations.

[0117] The ROM 710 stores static data and instructions that are needed by the one or more processing unit(s) 712 and other modules of the electronic system 700. The permanent storage device 702, on the other hand, may be a read-and-write memory device. The permanent storage device 702 may be a non-volatile memory unit that stores instructions and data even when the electronic system 700 is off. In one or more implementations, a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) may be used as the permanent storage device 702.

[0118] In one or more implementations, a removable storage device (such as a floppy disk, flash drive, and its corresponding disk drive) may be used as the permanent storage device 702. Like the permanent storage device 702, the system memory 704 may be a read-and-write memory device. However, unlike the permanent storage device 702, the system memory 704 may be a volatile read-and-write memory, such as random access memory. The system memory 704 may store any of the instructions and data that one or more processing unit(s) 712 may need at runtime. In one or more implementations, the processes of the subject disclosure are stored in the system memory 704, the permanent storage device 702, and / or the ROM 710 (which are each implemented as a non-transitory computer-readable medium). From these various memory units,the one or more processing unit(s) 712 retrieves instructions to execute and data to process in order to execute the processes of one or more implementations.

[0119] The bus 708 also connects to the input and output device interfaces 714 and 706. The input device interface 714 enables a user to communicate information and select commands to the electronic system 700. Input devices that may be used with the input device interface 714 may include, for example, alphanumeric keyboards and pointing devices (also called “cursor control devices”). The output device interface 706 may enable, for example, the display of images generated by electronic system 700. Output devices that may be used with the output device interface 706 may include, for example, printers and display devices, such as a liquid crystal display (LCD), a light emitting diode (LED) display, an organic light emitting diode (OLED) display, a flexible display, a flat panel display, a solid state display, a projector, or any other device for outputting information. One or more implementations may include devices that function as both input and output devices, such as a touchscreen. In these implementations, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.

[0120] Finally, as shown in FIG. 7, the bus 708 also couples the electronic system 700 to one or more networks and / or to one or more network nodes through the one or more network interface(s) 716. In this manner, the electronic system 700 can be a part of a network of computers (such as a LAN, a wide area network (“WAN”), or an Intranet, or a network of networks, such as the Internet). Any or all components of the electronic system 700 can be used in conjunction with the subject disclosure.

[0121] These functions described above can be implemented in computer software, firmware or hardware. The techniques can be implemented using one or more computer program products. Programmable processors and computers can be included in or packaged as mobile devices. The processes and logic flows can be performed by one or more programmable processors and by one or more programmable logic circuitry. General and special purpose computing devices and storage devices can be interconnected through communication networks.The functions disclosed herein may be implemented using quantum computing, pulse-coupled oscillation (PCO) / Ising computing.

[0122] Some implementations include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (also referred to as computer-readable storage media, machine- readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, read-only compact discs (CD-ROM), recordable compact discs (CD- R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD-ROM, duallayer DVD-ROM), a variety of recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and / or solid state hard drives, read-only and recordable Blu-Ray® discs, ultra-density optical discs, any other optical or magnetic media, and floppy disks. The computer-readable media can store a computer program that is executable by at least one processing unit and includes sets of instructions for performing various operations. Examples of computer programs or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.

[0123] While the above discussion primarily refers to microprocessor or multi-core processors that execute software, some implementations are performed by one or more integrated circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some implementations, such integrated circuits execute instructions that are stored on the circuit itself.

[0124] As used in this specification and any claims of this application, the terms “computer”, “server”, “processor”, and “memory” all refer to electronic or other technological devices. These terms exclude people or groups of people. For the purposes of the specification, the terms display or displaying means displaying on an electronic device. As used in this specification and any claims of this application, the terms “computer readable medium” and “computer readable media” are entirely restricted to tangible, physical objects that store information in a form that isreadable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals.

[0125] To provide for interaction with a user, implementations of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; e.g., feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; e.g., by sending web pages to a web browser on a user’s client device in response to requests received from the web browser.

[0126] Aspects of the subject matter described in this specification can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), an inter-network (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0127] In accordance with aspects of the disclosure, a wireless network (e.g., the 5G network 106) is provided, the wireless network being configured to support time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism. The wireless network may include a plurality of discrete communication network (CN) components, e.g., components 110, 118, 120, 122, 124, 126, 140, 190, etc., discussed above. Each CN component may be configured to provide a discrete functionality for data communication from a source device (e.g., 102)across the wireless network (e g., 106) to a destination device (e.g., 104). A processor (e.g., 402) may be arranged to configure at least one (e g., 140) of the plurality of CN components with a set of TSN parameters of the TSN mechanism such that the at least one of the plurality of CN components supports time-sensitive deterministic communication as a TSN block (e.g., 202-3) in a TSN network in accordance with the set of TSN parameters. The at least one of the plurality of CN components that is being configured with the set of TSN parameters is the 5G transport network channel 140 connecting the RAN 120 and the UPF 122. In some implementations, the processor is arranged to configure each of the plurality of CN components with a respective set of TSN parameters of the TSN mechanism such that each of the plurality of CN components supports time-sensitive deterministic communication as a corresponding TSN block in the TSN network in accordance with the respective set of TSN parameters.

[0128] The wireless network may further include a configuration module (e.g., 110 or 210) configured to determine the set of TSN parameters for the at least one of the plurality of CN components. The set of TSN parameters may include one or more of a TSN stream identification, a transmission schedule, a deadline or delay budget, a filtering configuration, and a redundancy scheme. In some implementations, the processor is configured to assign one or more CN resources for data transmission by the at least one of the plurality of CN components in accordance with the transmission schedule or the deadline or delay budget. In some implementations, the configuration module is configured within a control plane component (e.g., SMF 126) of the plurality of CN components.

[0129] In some implementations, the configuration module is configured to determine the set of TSN parameters based on one or more CN attributes assigned to the at least one of the plurality of CN components, wherein the one or more CN attributes relate to the discrete functionality provided by the at least one of the plurality of CN components.

[0130] The processor may be configured to monitor data transmission by the at least one of the plurality of CN components and report to the configuration module any change to the set of TSN parameters or the one or more CN attributes, and the configuration module is configured to update the set of TSN parameters based on the reported change.

[0131] In accordance with aspects of the disclosure, a wireless network (e.g., the 5G network 106) configured to support time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism is provided. The wireless network may include a plurality of discrete communication network (CN) components, e.g., components 110, 118, 120, 122, 124, 126, 140, 190, etc., discussed above. Each CN component may be configured to provide a discrete functionality for data communication from a source device (e.g., 102, 204) across the wireless network (e.g., 106) to a destination device (e.g., 104, 206). The wireless network may include a plurality of configuration modules (e.g., 210, 215) interconnected (e.g., via 230) in a certain arrangement and configured to provide a unique set of TSN parameters to each of the plurality of CN components such that each of the plurality of CN components supports time-sensitive deterministic communication as a corresponding TSN block in a TSN network in accordance with the respective unique set of TSN parameters. The plurality of configuration modules may be interconnected in a hierarchical arrangement, a mesh arrangement, a star arrangement, a tree arrangement, a combination thereof.

[0132] As illustrated and discussed above in relation to Fig. 2, the corresponding TSN block (e.g., 202-3) may be configured to receive the unique set of TSN parameters thereof from a configuration module (e.g., 215-b and / or 215-c) of the plurality of configuration modules assigned to the corresponding TSN block. The unique set of TSN parameters may include one or more of a TSN stream identification, a transmission schedule, a deadline or delay budget, a filtering configuration, and a redundancy scheme.

[0133] In some implementations, at least one of the plurality of configuration modules is configured as a CUC 114 and / or a CNC 112 and implemented within the SMF 126 of the control plane and / or within the TSN block 202-3 (which represents the TSN configuration of the 5G transport channel 140). In implementations in which the 5G transport channel 140 is being configured with TSN parameters in accordance with various aspects of this disclosure, the RAN 120 and the UPF 122 each may be configured to support the functionality of a TSN Talker and / or Listener as defined in IEEE P802.Qdj [xx]. The SMF 126 / CUC 114 may be responsible to convert the 5GS parameters from / to the parameters in IEEE P802.1Qdj [xx]. The SMF 126 / CUC 114 may be configured to communicate with the TSN Talker and / or Listener in the RAN 120 and the UPF 122 to exchange data sets defined in IEEE P802. IQdj [xx]. In someimplementations, during the Qos flow establishment or modification, the SMF 126 / CUC 114 creates the Talker Group and Listener Group per QoS Flow as defined in the Annex I.x and sent to TSN CNC 112. The TSN CNC 112 uses the Talker Group and Listener Group as input to select path(s) and calculate schedules in TSN. The TSN CNC 112 provides a Status group to the SMF 126 / CUC 114. The SMF 126 / CUC 114 provides the Status group to the TSN Talker and / or Listener in the RAN 120 and the UPF 122, respectively. After receiving the Status group, the TSN Talker and / or Listener send the data to N3 interface according to the configuration in the Status group.

[0134] In some implementations, a processor (e.g., 402) is configured to assign one or more CN resources for data transmission by at least one of the plurality of CN components in accordance with the transmission schedule or the deadline or delay budget.

[0135] In accordance with aspects of the disclosure, a system (e.g., system 100 as illustrated and described with respect to Fig. 8) is provided. The system includes a first wireless network (e.g., 805) and a second wireless network (e.g., 810). The first wireless network may include a first plurality of discrete communication network (CN) components, each CN component configured to provide a discrete functionality for data communication via the first wireless network, wherein at least one of the first plurality of CN components is configured to provide time-sensitive deterministic communication in accordance with a first set of TSN parameters. The second wireless network may include a second plurality of discrete CN components, each CN component configured to provide a discrete functionality for data communication via the second wireless network, wherein at least one of the second plurality of CN components is configured to provide time-sensitive deterministic communication in accordance with a second set of TSN parameters.

[0136] In some implementations, a TSN transport channel (e.g., 820) is provided, which is configured to facilitate time-sensitive deterministic communication of data exchanged between the first wireless network and the second wireless network, in accordance with a third set of TSN parameters. The TSN transport channel may be communicatively connected with a first TSN translator (e.g., NW-TT in 122 of 805) of the first wireless network and a second TSN translator (e g., NW-TT in 122 of 810) of the second wireless network.

[0137] In accordance with aspects of the disclosure, a method is provided that includes configuring at least one (or each) of a plurality of CN components of a wireless network (e.g., a 5G network) with a set of TSN parameters of the TSN mechanism such that the at least one (or each) of the plurality of CN components supports or provides time-sensitive deterministic communication as a TSN block in a TSN network in accordance with the set of TSN parameters. The at least one of the plurality of CN components may be the 5G transport network channel connecting the RAN and the UPF.

[0138] The method may further include determining the set of TSN parameters for the at least one of the plurality of CN components, e.g., at one or more configuration modules. The set of TSN parameters may include one or more of a TSN stream identification, a transmission schedule, a deadline or delay budget, a filtering configuration, and a redundancy scheme. The method may further include assigning one or more CN resources for data transmission by the at least one of the plurality of CN components in accordance with the transmission schedule or the deadline or delay budget. The method may also include monitoring data transmission by the at least one of the plurality of CN components and reporting to the configuration module any change to the set of TSN parameters or the one or more CN attributes, wherein the set of TSN parameters is updated based on the reported change.

[0139] A high-precision TSN mechanism can implement more TSN flows, with smaller messages, and more precise TSN flow latencies (high-precision TSN flows). With greater resolution and precision in the allocation of the message latency time budget for each TSN flow comes greater applicability of TSN to more challenging applications. In some implementations, the high-precision TSN mechanism can be referred to as high time resolution TSN mechanism, the high-precision TSN flow can be referred to as a high time resolution TSN flow. The high- precision TSN mechanism is developed to provide higher fidelity reconstruction of more rapidly changing signals enabling improved stability of higher frequency networked control systems. TSN mechanism (or standard TSN mechanism) is currently limited to ~40 nanoseconds precision, at best, with respect to scheduling but the high-precision TSN mechanism can provide picoseconds precision. The high-precision TSN mechanism is a Bridged Local Area Network with VLANs (specified in IEEE 802. IQ) that uses Ethernet (IEEE 802.3) to interconnect switches and nodes, and an extension incorporated into the 2019 revision of IEEE 1588 standardby the P1588 Working Group (IEEE Standard 1588-2019, in 2020 [4, Annex M]). The high- precision TSN mechanism is backward compatible with legacy TSN specified in IEEE 802. IQ. In such context, the present disclosure introduces a system to integrate high-precision TSN mechanism with legacy TSN functionalities so that the system enables seamless interoperation among high-precision and legacy TSN network components. In such context, the present disclosure introduces a system to integrate high-precision TSN with legacy TSN functionalities so that the system enables seamless interoperation among high-precision and legacy TSN network components. The present disclosure is also provided to anticipate how standards will change to implement such system.

[0140] Fig. 9 is an example system in accordance with one or more implementations.

[0141] Fig. 9 illustrates an example system which is configured to support time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism. The system is also configured to support time-sensitive deterministic communication based on a high- precision TSN mechanism (high time resolution TSN mechanism) based on standard methods for time synchronization and traffic management in accordance with IEEE 802.1 TSN specification suite and IEEE 802. IAS, which is a profile of IEEE 1588 Precision Time protocol.

[0142] In some implementations, the system 900 is configured to support and manage deterministic high-precision TSN flows or TSN flows between a source device 910 and a destination device 920 via communication network (including a wireless network configured in accordance with a 3 GPP-defined standard) in accordance with high-precision TSN configuration (high-precision TSN parameters) including a high-precision TSN schedule determined by a controller 110 or TSN configuration including a TSN schedule determined by the controller 110. The source device 910 and the destination device 920 may include one or more of the I / O devices 102 and the controller 104. The system 900 include a plurality of network devices which includes legacy network device (e.g., the 5G system bridge 106, bridges 108) configured with legacy TSN mechanism and at least one high time resolution network device 930 configured with the high-precision parameters. Here, high-precision TSN flow refers to data communication between the source device 910 and the destination device 920. Referring to Fig. 2 and Fig.3, at least one communication network component (e.g., 5G component) is configured to emulate as aTSN block in accordance with TSN specifications (e.g., IEEE 802.1Qcc) such as a network device and end devices 102.

[0143] In some implementations, the controller 110 is configured to provide functionalities to control a plurality of network devices in accordance with TSN specifications (e.g., IEEE 802. IQcc). For example, the CUC 114 communicates with the CNC 112 using a user / network configuration interface to initiate a request to the CNC 112 to discover the physical topology, discovering end devices 102 and network devices for high-precision TSN mechanism and TSN mechanism and how they are connected. The CUC 114 also communicates with the end devices 102 to receive communications requirements from the end devices 102. The CNC 112 communicates with both the CUC 114 and the plurality of network devices. The CNC 112 communicates with the CUC 114 to receive communications requirements that the network must provide. The CNC 112 aggregates all communications requests, computes the route for each communication request, schedule the end-to-end transmission for each TSN flow. The CNC 112 provides TSN parameters that the end devices 102 and network devices need to know to configure TSN. For example, the TSN parameters may include a unique identifier for each TSN flow. This unique identifier is used by the network devices to differentiate one TSN flow from another. The unique identifier may include further information identifying the TSN flow (e.g., destination MAC address, VLAN ID, etc.). The TSN parameters may be provided to the CUC 114 and the CUC 114 can provide TSN parameters to the end devices and network devices. For example, the TSN parameters may include start and end of transmit window at each end device 102 (e.g., source device), network devices, start and end of receive window at each end device 102 (e.g., destination device) and network devices, and end-to-end latency as computed, etc. The plurality of network devices switches TSN ethernet packets or frame between the source device 102 and the destination device 104.

[0144] The system 900 supports the high-precision TSN mechanism and TSN mechanism simultaneously, the controller 110 can determine whether to use the high-precision TSN mechanism. In some implementations, the controller 110 can apply Wavelet and / or Fourier Transform techniques to determine whether to use the high-precision TSN mechanism. For example, the controller 110 may partition a signal which originates from the source device (e.g., 910) into frequency components to compute loss and gain by using the high-precision TSNmechanism and TSN mechanism. The controller 110 can identify the impact of the high- precision TSN mechanism and TSN mechanism on the real-time fidelity of the signal. If the signal requires high precision and resolution to reconstruct the signal, the controller 110 can determine to apply the high-precision TSN mechanism. Thus, the controller 110 may take various factors into account, such as, but not limited to, an amount of bandwidth available, application requirements for signal fidelity and the number of competing TSN flows requesting access through each link, etc. The actual decision process by the controller is generally a represented as a constraint satisfaction problem with many possible formulations and solutions. In some implementations, the controller 110 may determine whether to use of the high-precision TSN mechanism based on user requirements provided to CUC 114 and capabilities of network devices (e.g., 930). In some implementations, network devices may advertise such capabilities (including device information) via a LLDP (Link Layer Discovery Protocol) which is a layer 2 neighbor discovery protocol. This protocol may allow network devices to advertise device information to their directly connected peers or neighbors. Based on the various factors and information including capabilities of network devices, the controller 110 can identify or distinguish which network devices among the plurality of network devices to be configured based on the high-precision TSN mechanism and how they are connected. Here, such network device can be referred to as a high-precision network device, a high time resolution network device. For example, the controller 110 can identify one or more high time resolution network devices 930 among the plurality of network devices to be configured based on the high-precision TSN mechanism. In some implementations, a high time resolution network device 930 includes switches commonly called “bridges” or “nodes”) which transmit and receive the data (in one non-limiting example, Ethernet frames) in a high-precision TSN flow. The controller 110 can compute novel high-precision TSN parameters and schedule the end-to-end transmission for each high-precision TSN flow. In some implementations, interface and API used in standard TSN (e.g., IEEE 802.1) may change to enable interoperability, including CLI, SNMP, NETCONF / YANG configuration. The controller 110 can configure one or more high time resolution network device 930 with high-precision TSN parameters for time-sensitive deterministic communication based on a high time resolution TSN mechanism based on determined high-precision TSN schedule. In accordance with the high time resolution TSN parameter, an operational timing associated with the high time resolution network device isdifferent from an operational timing associated with a legacy network device of the plurality of network devices configured with a legacy TSN mechanism.

[0145] The below table includes example high-precision TSN parameters for configuration of the high-precision TSN mechanism and TSN parameters for configuration of the TSN mechanism provided by the controller 110. In some implementations, high-precision TSN parameters may be referred to as high time resolution TSN parameters.

[0146] [Table 1]

[0147] In some implementations, the table above may use YANG language provided byYANG models. In some implementations, the YANG models may reside on both the networkdevice (e.g., 930) being configured and the controller 110 (e g., CNC 112). In some implementations, the high-precision TSN parameters may include a gate accuracy parameter (gatePrecision) indicating accuracy with which gate operations associated with the high time resolution network device are consistently applied, a time resolution parameter (gateResolution) indicating time resolution with which gate operations associated with the high time resolution network device are configured and reported. In some implementations, the high-precision TSN parameters may include parameters for delay (e.g., asymmetricUpDelay, asymmetricDonwDelay, cableDelay etc.), a fiberlength parameter (e.g., fiberLength etc.) and wavelength parameters (e.g., wavelengthUp, wavelengthDown, etc.). The high-precision TSN mechanism provides increased resolutions from nanoseconds to picoseconds, the operational timing associated with the high time resolution network device is set in picoseconds, and the operational timing associated with the legacy network device is set in nanoseconds, the gate accuracy parameter and time resolution parameter of the high time resolution network 930 are provided in picoseconds. As shown in Fig. 9, the controller 110 (e.g., CNC 112) provides high- precision TSN parameters to high time resolution network device 930.

[0148] In some implementations, the high-precision TSN parameters further include parameters related to digital input / output (DIO) parameters including: a DIO enabled parameter indicating whether the DIO is enabled (tsnDIOenabled), a DIO value parameter indicating whether timestamps or digital signal values are placed in Ethernet fames of the high time resolution TSN flow (tsnDIOvalues), a DIOstreamID parameter identifying a steam of DIO (tsnDIOstreamID), and a DIOnumberSmaples parameter indicating a number of DIO samples placed in each Ethernet fame of the high time resolution TSN flow (snDIOnumberSamples). In some implementations, the controller 110 may be cognizant of DIO (DIO parameters) integrated into with TSN. In some implementations, the DIO parameters may be present in the YANG model and be supported by the network device (e.g., 930).

[0149] In some implementations, DIO, or Digital Input / Output (or DIO signals), is a simple form of interface used in a wide range of systems to effectively relay digital signals from sensors, transducers and mechanical equipment to other network devices (electrical circuits and devices). DIO utilizes a logic signal to transfer information. Unlike an analog signal which might be comprised of varying voltages, the digital signals used by DIO have two possible values (0 (zero) or 1) and are generally represented as either OFF or ON. This makes it ideal for sensingswitch contacts, reacting to motion sensors, limit switches, operator buttons or machinery status indicators. It can also be used to control indicator lights, small relays or PLCs within equipment. In some implementations, the system 900 may include a converter (ethemet to digital I / O converter) which is configured to sample signal(s) over consecutive time periods and distribute DIO to the high time resolution network 930. The converter may be implemented in the controller 110 or as separate from the controller 110.

[0150] In some implementations, the controller 110 (e.g., CUC 114) may transmit the digital input / output (DIO) parameters (e.g., 950) to the source device 910 and the destination device 920 and / or the high time resolution network device 930 so that the high time resolution network device 930 transmit frames of each high-precision TSN flow from the source device 910 to the destination device 920.

[0151] Fig. 10 illustrates example multiple TSN domains in accordance with one or more implementations.

[0152] In some implementations, the system 900 may configure multiple TSN domains 1000 in accordance with TSN / high-precision TSN configurations. In some implementations, the TSN network may be referred to as a TSN domain which include a set of TSN components (e.g., network device) that are under a common TSN / high-precision TSN configuration and management scheme and responsibility. In some implementations, one or more TSN networks may be configured by the same controller (controller 110) or by different controller.

[0153] The multiple TSN domains 1000 include a first TSN domain 1010 (TSN domain 1) and a second TSN domain 1020(TSN domain 2). The first TSN domain is configured to support one or more high time resolution TSN flows based on the high time resolution TSN mechanism and a second TSN domain is configured to support one or more TSN flows based on the legacy TSN mechanism. For example, the first TSN domain may include the high time resolution network device, the second TSN domain may include the legacy network device of the plurality of network devices.

[0154] The first TSN domain 1010 and the second TSN domain 1020 may coexist along with their corresponding time synchronization precisions. However, the TSN mechanism does not allow for sub-nanosecond (picoseconds) configuration or reporting and assumes lower clock stability. The TSN mechanism does also assumes core IEEE 802. IAS is used rather than thehigh-precision annex, where there could be a mix of standard and high-precision time synchronization clocks. For time synchronization precisions, the system 900 includes a boundary clock 1030 (or a clock) which is specified by IEEE 1588 standard which is incorporated herein in its entirety. Particularly, IEEE 1588 Annex 1.5.3 PTP options identify a clock capable of supporting high-precision TSN. The boundary clock enables legacy TSN and high precision- TSN to share a common time so that TSN Time Aware Shapers have a knowledge of the absolute current time. Each TSN domain (e.g., the first TSN domain 1010, the second TSN domain 1020) may have a different clock protocol with its network clock. Such network clock may be limited by hardware and link capabilities of corresponding TSN domain. The boundary clock 1030 serves as a time transfer standard between the subnets defined by high-precision TSN domain (e.g., the first TSN domain 1010) and TSN domain (e.g., the second TSN domain 1020). All messages specified in IEEE 1588 are blocked from transport across the boundary clock domains. The boundary clock 1030 has a network connection to each of the domains. When viewed from a subnet, the boundary clock 1030 appears exactly like any other (ordinary) 1588 clock in a system (e.g., the system 900). Within a domain the ordinary clocks and the portion of the boundary clock 1030 visible from the subnet synchronize with each other as though they were all ordinary (high or standard precision) clocks. The boundary clock 1030 itself resolves all the times of the several domains by establishing a parent child hierarchy of clocks.

[0155] In some implementations, the high-precision TSN flow may passes from the first TSN domain 1010 to the second TSN domain 1020, vice versa. In the simplest case, all time units should have increased resolution from nanoseconds to picoseconds. Increased resolution enables a larger number of TSN flows with smaller latencies (message sizes). In addition, just as higher stratum clocks are master clocks, high-precision TSN should also have a notion of being in a higher stratum since precision and resolution, once lost, cannot (easily) be regained. Thus, the controller 110 (e.g., CNC 112) must identify and distinguish between high-precision network device (e.g., at least one high time resolution network device 930) and standard network devices before feeding TSN flows to legacy TSN. If high-precision TSN flows cross high-precision TSN domains and TSN standard domains (from higher to lower precision), however, the impact on meeting latency determinism will clearly be impacted by such boundary crossings and should be flagged to alert network requirement or a system user during configuration to make they are aware of the change in precision between high-precision TSN and legacy TSN. For example, thiscould be indicated by the resolution of the maximum latency parameter (either nanosecond or picoseconds). The controller 110 (CNC 112) should return a “determinism budget” that illustrates jitter accumulation along such TSN flow path. The controller 110 may have a maximum jitter threshold requirement and know accumulated jitter along the TSN flow path. In addition, high-precision TSN flows may exist within time slots that are smaller and more precision than those for standard TSN flows. It may be possible to specify a bundling of such high-precision TSN flows into one larger, standard TSN (lower-precision) flow. In some implementations, larger lower-precision (standard TSN) flows may be partitioned into smaller, higher-precision (high-precision TSN) flows. In some implementations, IEEE 802.1 CB (redundant flow segments configured for increased reliability) in the system 900 supporting hybrid High Precision TSN-legacy TSN may occur as well.

[0156] The present disclosure is provided to extend TSN gate operation enabled and encouraged by high-precision TSN. Many middleware standards such as OPC Unified Architecture (OPC UA) 1 and Data Distribution Service (DDS) 2 have developed standard mechanisms to integrate with standard TSN. The OPC UA is a cross-platform, open-source, IEC62541 standard for data exchange from sensors to cloud applications developed by the OPC Foundation. The DDS for real-time systems is an Object Management Group (OMG) machine- to-machine (sometimes called middleware or connectivity framework) standard that aims to enable dependable, high-performance, interoperable, real-time, scalable data exchanges using a publish-sub scribe pattern. The present disclosure also considers how these standard interfaces will change with our novel High Precision TSN. For example, a pub-sub system should be modified to have the ability request picosecond TSN resolution. It should have the ability to leverage different precision TSN domains.

[0157] Fig. 11 illustrates examples high-precision data bus in accordance with one or more implementations.

[0158] A system bus 1100 is used in standard TSN, a high-precision TSN Data bus 1110 may replace the system bus 1100 to support a high-precision TSN mechanism such as Peripheral Component Interconnect (PCI) bus. The high-precision TSN Data bus 1110 may be placed in the network device (e.g., bridge, switch). The table below is computer data bases that can be replaced with a more configurable high-precision TSN.[00159J [Table 2]

[0160] In the present disclosure, the high-precision TSN is designed to align with the unique aspects of higher-precision use cases such as data buses discussed above, which typically have their own clocks, where TSN frames should align with bus clock rates. Higher precision and higher communication rates can also experience thermal, intermodulation, crosstalk, impulse and shotnoise as well as varying noise introduced from mobility. The technique of varying a deterministic schedule to minimize overlap with noise is required.

[0161] In addition, the high-precision TSN mechanism encourages implementing more TSN flows, with smaller messages, and more precise TSN flow latencies (high-precision TSN flows). With greater resolution and precision in the allocation of the message latency time budget for each TSN flow comes greater applicability of TSN to more challenging applications; TSN can act more like a high-speed data bus, for example. There may also be more room in the time budget for time varying TSN flows. Legacy TSN mechanism only allows for fixed TSN schedules. Such fixed TSN schedules can be dynamically changed, but this requires disruption and is generally not seamless. In this disclosure, the controller 110 (CNC 112) is configured to provide dynamically changing TSN schedules for high-precision TSN flows. For example, TSN scheduled time slots may expand, contract, or slide over time as a built-in part of the schedule. In essence, TSN scheduled time slots have “physical” properties analogous to size, weight, and momentum, allowing them to accelerate or decelerate within a given TSN admin cycle time allowing to model a changing control law, for example. Thus, the TSN schedule may oscillate or converge to a final state and would do so in synchrony with other devices on the network. For example, in a mobile TSN network, the schedule may automatically adjust to match the changing link delay dynamics. In fact, scheduling should inherently be done in terms relative to link delay rather than absolute time.

[0162] In some implementations, a dynamically changing TSN schedule can vary periodically within the determined cycle time. Advanced optimization techniques are used to compose the dynamic time-aware shapers along the path while avoiding the same frame egressing the same part at the same time using optimization with time-varying constraints. Thus, the dynamically changing TSN flow schedule avoid collision with other TSN flows which may also be dynamically changing.

[0163] In the system 900, the controller 110 (or CNC 112) may configure a dynamically changing time-aware shaper (TAS) for at least network device (e.g., 930). In some implementations, the dynamically changing TAS may reside on the egress ports of the at least network device and must be capable of supporting dynamic schedules. A dynamic schedule is no longer a static list of gate open / close times (as in the legacy TSN), but instead, a schedule that changes as a function of time or other environmental, such as 3 GPP channel quality indicator(CQI). The dynamically changing TAS is one whose frame output control varies over time and is coordinated with all other time-aware shapers in the network to obtain desired latency and jitter characteristics for TSN flows (high-precision TSN flows). The dynamically changing time-aware shaper is provided to dynamically change TSN schedules for high-precision TSN flows. As discussed above, the TSN schedules for high-precision TSN flows is no longer a simple static gate control list and is a gate control which is a function of time or other network environmental parameters. The gate control list may be represented as a function or time or signal quality, for example.

[0164] In some implementations, a Command Line Interface (CLI) is used to specify a periodically changing TSN flow (or high-precision TSN flow). The CLI is configured as an interface to receive direct input by a system user. The CLI may be an API that allows for automated input. In some implementations, a network device (e.g., 930) may have some forms of CLI access. Thus, the dynamically changing Time Aware Shaper and gate control applies to the egress ports of network devices along any TSN flow: from the TSN Talk (e.g., source device 910) through switches, toward the TSN Listener (e.g., a destination device 920). The CLI could be enhanced to accept gate open and close durations specified in the form of a function rather than fixed values. There is one function input variable, time t. This variable has a range of zero through some given maximum t. Maximum TSN flow latency is defined as a function of t where the function must be periodic and may have transcendental including trigonometric values as well as a polynomial with some limited degree. The controller 110 (e g., CNC 112) shall find time-aware shaping solutions which may be periodic for the egress port of each device (e.g., network device 920, 108) along the path of a TSN flow such that, when operating sequentially, deliver the TSN flow messages with the requested function.

[0165] The dynamically changing TSN flows act as “shock absorbers” for changing network latencies e.g., due to mobility or time-varying noise. A good model of the network environment, particularly wireless (e.g., 5G) environments, can determine predictable time-varying performance patterns and the TSN schedule can vary to minimize overlap with noise. As mobile nodes change location, their propagation delay to the base station / cell tower changes accordingly. An AI / ML system can be used to learn mobility patterns that could instantiate a dynamic TSN schedule that compensates for varying propagation delay. The AI / ML system is provided to learning suchpatterns and determining the time varying TSN schedule. In some implementations, such AI / ML system is included in the system 900.

[0166] The standard TSN system does not have an internal mechanism to monitor TSN flow performance. Instead, the standard TSN system requires costly test and measurement devices to verify correct operation. The standard TSN mechanism typically achieves ~40ns accuracy (at best) while a high-precision TSN mechanism is in the sub-nanosecond (picosecond) range. Often such external TSN test devices are of questionable quality, setting them up is error-prone, and external TSN test devices must be removed during “normal” operation. The external TSN test devices often lack the resolution and precision required for high-precision measurement (limited to tens of nanoseconds resolution, in general). In addition, the standard TSN (legacy TSN) monitoring tools often do not have the precision required. It is also costly and error prone to install special test equipment to verify operation. IEEE 802.1Qci performs ingress filtering and policing, which may offer a similar check on TSN performance, however, it is again limited in resolution. A simple, efficient, and reliable monitoring system is invaluable. Thus, this present disclosure provides high- precision TSN built-in performance monitoring operations to address the problem of efficiently testing and continuously validating high-precision TSN flow.

[0167] Fig. 12 illustrates example monitoring operations in accordance with one or more implementations.

[0168] In some implementations, the system 900 may provide monitoring operations (high- precision TSN built-in performance monitoring operations) 1200 to monitor a high-precision TSN flow. In some implementations, a high-precision TSN device which is configured to support timesensitive deterministic communication based on a high-precision TSN mechanism, such as a high time resolution network device 930 (e.g., bridge), etc., is configured to provide monitoring operations 1200 which monitors a high-precision TSN flow (or TSN flow). In some implementations, the monitoring operations 1200 can be automated, implemented as part of the controller 110 so that the monitoring operations 12000 can automatically validate all high- precision TSN flows passing through all high-precision TSN devices. Thus, the high-precision TSN mechanism enables very high level of confidence such monitoring operations 1200. The monitoring operations 1200 are built in the high-precision TSN device, the monitoring operations 1200 can assume that time synchronization itself is perfect, in other words, it cannot monitor or verify the precision and accuracy of the underlying network time synchronization quality. In someimplementations, the monitoring operations 1200 are implemented as software or tool (e.g., monitoring module) that can be used in the high-precision TSN device.

[0169] In some implementations, the monitoring operations 1200 are bare metal performance and data collection of a high precision TSN flow. Here, the data collection refers to part of monitoring operations 1200 to collect necessary information from Ethernet Frames (e.g., TSN stream identifiers) to be monitored. In some implementations, the data collection would attempt to collect enough information to verify correct operation of the system as per user requests. This would likely include information about Ethernet frames derived from their headers. In some implementations, the data collection should minimize interference and overhead, thus it should ideally output short pulses in a standard manner to another, non-network device. The monitoring operations 1200 offer a built-in Wireshark or Pendulum-like performance monitoring capability. For example, the monitoring operations 1200 are implemented on the high-precision switch port and maintains a running set of statistics in memory that can be reported using a standards-based network management tool, namely NETCONF / YANG or SNMP. The monitoring operations 1200 can be implemented to send a signal to an external frequency measuring device every time an Ethernet frame arrives. Results may also be stored and processed for query by SNMP, NETCONF / YANG, or other network management protocol. In some implementations, the monitoring operations 1200 are enable the ability to set thresholds on both latency and jitter. When a threshold is reached, an unsolicited message (e.g., NETCONF notification) should alert the system to potential anomalous behavior. The analysis may take the form of a histogram, raw time-stamped list of frame arrival times, or RMS jitter in comparison with the desired TSN schedule.

[0170] As shown in Fig. 12, the monitoring operations 1200 monitor a high-precision TSN flow. Scheduled vs unscheduled Ethernet frame latency and variance at the receiving port with sub-nanosecond resolution. Distance will be significant, ranging from ~20km to ~70km as well as Ethernet frame size. Thus, the monitoring operations 1200 monitor some type of unique fame identifier. The high-precision TSN flow is specified by any or all the following information (Ethernet frames TSN stream identifier) 1210:• Input port number• Source media access control (MAC) address• Destination MAC address• Virtual Local Area Network (VLAN) Identifier (ID)• L2 priority - Priority Code Point (PCP)• Internet Protocol (IP) source address• IP destination address• Next protocol User Datagram Protocol / Transport Control Protocol (UDP / TCP)• Source port number• Destination port number• Differentiated Services Code Point (DSCP).

[0171] The monitoring operations 1200 include operation 1220 to monitor the above information 1210 in an ethernet frame. The operation 1220 can record the time of arrival of the first bit of each target Ethernet frame. Ethernet frames comprise the messages within the TSN flow and flows are identified based upon the IEEE 802. IQ TSN standard for stream identification, which has multiple options but can include VLAN ID and the PCP tags of the Ethernet frame header. As discussed above, the resolution of the system 900 to support time-sensitive deterministic communication based on a high-precision TSN mechanism is picoseconds or higher. In some implementations, the system 900 may control configuration parameters 1250 for the operation 1220 1200. The operation 1220 may be performed according to the configuration parameters 1225. In some implementations, the configuration parameters 1220 include, but are not limited to, information indicating whether to reset the monitoring operations 1200, information indicating whether to enable or disable the monitoring operations 1200, information regarding maximum internal data storage (megabytes), output rate information and jitter threshold which may be used to determine errors in the target high-precision TSN flow. In some implementations, the internal storage for the monitoring operations 1200 in a network device is generally a limitation, the data collection is limited to a finite value and may be implemented as a moving window. The monitoring operations 1200 includes operation 1230 to output signal (unsolicited alerts) indicating errors in the high-precision TSN flow when a targeting high-precision TSN flow error exceeds a given threshold. The signal (unsolicited alerts) may be a NETCONF / YANG notification that contains the type of flow validation error, the specific TSN flow, and the amount of error. In some implementations, the monitoring operations 1200 include operations 1240 to visualize monitoring result (or validation result of the high-precision TSN flow) as histogram, realtime strip chart, etc. such operation 1240 may be performed by a visualization processor in the system 900 or an external device.

[0172] In some implementations, the monitoring operations 1200 may be cognizant of the local TSN schedule, including the TSN absolute cycle start time, TSN gate entries, the TSN cycle time length, the specific TSN flow identifiers (stream ids), egress ports, etc. and compare against these values when verifying flow quality. In some implementations, the local TSN schedule is referring to the TSN schedule of the TSN domain being monitored. For example, the system 900 may monitor a TSN domain (e.g., the first TSN domain 1010 (TSN domain 1) which support the same high-precision TSN mechanism, lower precision TSN mechanism or legacy TSN mechanism and use the monitoring result of that TSN domain to monitor other TSN domains. It may be referred to as the TSN schedule under test.

[0173] In some implementations, the monitoring operations 1200 can be used to test and verify standard TSN flow. For example, the monitoring operations 1200 can be an ideal tool for measuring plain (lower, legacy precision) TSN flows routed through the device implementing monitoring operations 1200. The monitoring operations 1200 can provide high resolution timing results for standard TSN message latency and jitter validating legacy TSN equipment and operation. Thus, the monitoring operations 1200 result in a lower-cost replacement for more expensive TSN test equipment (e.g., Keysight, IXIA, etc.). To validate absolute time and phase of legacy TSN flows within a cycle, our invention requires interoperation with the same grandmaster as the TSN system. In other words, it joins the same clock domain as the lower-precision IEEE 802. IAS clock domain.

[0174] In some implementations, the system 900 is configured to support data communication from a source device across a quantum network to a destination device. The quantum network may include a plurality of quantum components, a plurality of network devices include the plurality of quantum components, each quantum component may be configured to provide a functionality for data communication from the source device 910 across the network to the destination device 920. In the quantum network, a single photon for each TSN flow can travel along a path between the source device 910 and the destination device 920 in the quantum network, and the path can be based on synchronized quantum components. In the quantum network, new types of synchronized activity are required such as creating simultaneous message arrivals, tracking coincidences, and managing random events in fixed time-bins e.g., entangled qubit management. Ethernet framesimultaneous time of arrival testing is a built-in test to check whether Ethernet frames arrive (either at the switch or end-stations) at precisely the same time (within network synchronization performance capabilities). Thus, new scheduling for controlling the networked single photon and synchronizing quantum components is required.

[0175] In this disclosure, novel TSN (high-precision TSN) scheduling abstraction and configuration representations for the quantum network are provided, but also applicable to complex scheduling requirements for any networked control system. While TSN offers “deterministic” message communication, “deterministic” does not imply “fixed,” rather, a deterministic system is a system in which no randomness is involved in the development of future states of the system. A deterministic system will thus always produce the same output from a given starting condition or initial state. Thus, TSN schedules may be “dynamic” in the sense of configurable, predetermined, periodic change.

[0176] Fig. 13 is an example TSN scheduling abstraction in accordance with one or more implementations.

[0177] Fig. 13 illustrates a Petri net diagram as TSN scheduling abstraction to represent timing constraints for TSN scheduling in the system 900 to support time-sensitive deterministic communication based on a high-precision TSN mechanism. The Petri net is a mathematical modeling language for description of distributed system which can be used to map out a TSN flow through a calculation. The Petri net is an abstraction that can represent both a control system (e.g., the system 900) and the network (e.g., quantum network). In some implementations, the Petri net can be used for representing TSN synchronization requirements for quantum components (e.g., network device 920). Events that should occur with well-defined relationships relative to one another can be entered into the controller 110 (CNC 112) in order to construct a schedule that enforces those requirements. This differs significantly from existing TSN schedulers where only the maximum allowed latency between source devices (Talkers) and destination devices (Listeners) is specified. In some implementations, the system 900 may use an AI / ML system to learn synchronous activity and constraints. The Petri net approach may also be a good abstraction for such AI / ML system to represent and leam timing constraints for the system 900.

[0178] Fig. 14 illustrates a block diagram of dynamic TSN scheduling in accordance with one or more implementations.

[0179] The block diagram 1400 represents dynamic TSN scheduling operations of the system 900. A communication network (e.g., a wireless network configured in accordance with a 3 GPP-defined standard, a quantum network, etc.) associated with the system may dynamically change due to noise (noise signals). A wireless propagation model 1410 shows various paths of communications from the source device (e.g., 910) and the destination device (e.g., 920) which may be affected by the noise caused by physical environment between the source device (e.g., 910) and the destination device (e.g., 920). Wireless communication system suffers from various unwanted effects of fading which may be caused due to multipath propagation, path loss, shadowing, Doppler spread and cochannel interference. In such environment, the system 900 monitors the communication network and TSN flow performance based on the TSN schedule, etc. and dynamically changes or continuously varies the TSN schedule to compensate the noise and avoid any randomness in the development of future states of the system. Thus, the system 900 will thus always produce the same output from a given starting condition or initial state. In the present disclosure, TSN schedules may be “dynamic” in the sense of configurable, predetermined, periodic change. In some implementations, the system 900 (e.g., the controller 110) may perform operations to create simultaneous message arrivals, track coincidences, and manage random events in fixed time-bins e.g., entangled qubit management in the quantum network. In some implementations, the system 900 (e.g., the controller 110) may perform Ethernet frame simultaneous time of arrival testing as a built-in test to check whether Ethernet frames arrive (either at a switch (e.g., network device 930) or end-stations (e.g., source device 910, destination device 920) at precisely the same time (within network synchronization performance capabilities).

[0180] As discussed above, TSN flows (high-precision TSN flows) will dynamically change as a function of time as illustrated in a box 1410-1. Here, dynamically changing TSN flows can be referred to as dynamically changing high-precision TSN flows. In some implementations, the controller 110 (CNC 112) may monitor wireless noise on a network channel in a communication network (e.g., a wireless network configured in accordance with a 3GPP-defined standard, a quantum network, etc.) and dynamically change or adjust TSN schedules to meet user requirements while avoiding and / or compensating for frame loss and delay caused by the noise 1420. The wireless noise is additive and hence at a receiver (e.g., destination device 920), thereceived signal contains both the transmitted data and noise. The noise includes any unwanted disturbance that degrades the quality of the desire signal. The noise may interfere the signal and reduce the speeds at which data is transmitted within the network and cause the delay. The noise may include thermal, quantum, electronic, impulse and intermodulation noise as well as other forms of noise. Environmental factors, such as temperature and humidity, can also affect noise levels. If the noise is significant enough in comparison to the desired signal, thus, a signal to noise ratio is low, then it can disrupt a wide rage of data transfers. For example, the noise may cause interference in the transmission of the data, it could cause the network to loss packets or frame. If the noise is too high, it can reduce the speed with which the signal travels and such low speed may cause propagation delay (the amount of the time required for a signal to be received after it has been sent).

[0181] In some implementations, the controller 110 may generate a High-Performance Gate Control List (a gate control list) to control gate open and close time of each gate in the at least one network device based on dynamically changing TSN schedule of the high-precision TSN mechanism 1430. Each instance, or operational High-Performance Gate Control List, that implements a flow will be a static sample or snapshot of a continuously changing schedule. In the High-Performance Gate Control List, gate open and close times can be expressed as a rational number represented by an integer numerator and denominator of nanoseconds. Ideally the user need not worry about the details of maintaining a rational value and instead provide an arbitrary function of time where the controller 110 attempts to sample the function as closely as possible to implement the High-Performance Gate Control List. The time parameter used in the function is the time in picoseconds (e.g., gate accuracy parameter, time resolution parameter) since gate operation begins, that is, from the IEEE 802. IQ TSN absolute start time. The system 900 provides time-varying traffic via a network (e.g., quantum network). For example, ethernet frames arrive at deterministic, but controlled and varying times. The system 900 is configured to ensure that schedules are valid, that there is never a frame transmission overlap in both space (Ethernet port) and time when providing the dynamically changing TSN schedules. In the quantum network, each TSN flow (e.g., the dynamically changing TSN flow) may correspond to a quantum operation to process a single photon in the quantum network, but is not limited to this.Thus, the gate control list may be provided to process / control the single photon for the quantum network.

[0182] Thus, a system configured to support time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism (e.g., the system 900) comprises a plurality of network devices (e.g., 106, 108, 930) configured to provide functionality for data communication from a source device across a communication network to a destination device and a controller (e.g., 110) arranged to configure at least one of the plurality of network devices with a TSN parameter for time-sensitive deterministic communication from the source device to a destination device based on a TSN schedule. The controller can monitor the communication network (e.g., TSN built-in performance monitoring operations as discussed in Fig. 12) and dynamically adjust the TSN schedule based on change in the communication network such that the at least one of the plurality of network devices supports the time-sensitive deterministic communication in accordance with the adjusted TSN schedule. In some implementations, the controller may receive a Petri net diagram as TSN scheduling abstraction to represent timing constraints for TSN scheduling and dynamically adjust the TSN schedule.

[0183] As discussed above, the TSN mechanism is used to schedule around noise including multipath. Such multipath reflections are leveraged to sense locations and potentially shape of objects by UE (e.g., a destination device 920) as similar to RADAR. In some implementations, TSN may be used to schedule either a “void” that is no communication over a specific time period or to schedule a specific flow to achieve optimal feedback for sensing purposes, by ensuring a transmission followed by a pause in wireless sensing technologies provided by 3GPP TR 22.837 (v.19.1.10, 2023-09). 3GPP TR 22.837 (v.19.1.10, 2023-09) is incorporated herein in its entirety. In some implementations, the high-precision TSN may be incorporated into wireless sensing technologies to provide the level of timing to optimize integrated sensing and communication.

[0184] Fig. 15 illustrates an example high-precision TSN gate control operation for a quantum network in accordance with one or more implementations. In some implementations, a system (e.g., the system 900) is associated with the quantum network. In some implementations, components in the system (e.g., network device 930, etc.) are configured as quantum componentsto provide TSN scheduled quantum operations for processing at least one photon in the quantum network to support data communication from the source device (e.g., 910) across a communication network (e.g., the quantum network) to a destination device (e.g., 920) based on TSN schedule. In some implementations, but is not limited to, each TSN flow is configured to correspond to each quantum operation for processing single photon. In some implementations, photons may be entangled with other remote photons in the quantum network. However, a system (e.g., the system 900) may not know which photon is entangled with which photon. Thus, the system can keep track of photons via time (e.g., TSN flows) by keeping track of time bins. As discussed above, the gate control list is provided to process each TSN flow corresponding to at least one quantum operation which is based on upon time offset within an overall cycle time. For example, a TSN admin cycle time represents the overall cycle time of gate open and close time of each gate in the at least one network device (920, 108) to process the single photon. Thus, each TSN admin cycle time is for each controls a different photon and thus photons are uniquely identified by the number of cycles since the absolute start time. Each “quantum operation N” must occur in the order and at the gate control times configured by the controller 110.

[0185] Fig. 16 illustrates example quantum nodes in accordance with one or more implementations.

[0186] Fig. 16 illustrates example two quantum nodes 1610, 1620 in a high-precision TSN controlled quantum network 1600. In some implementations, the system 900 is associated with the quantum network 1600. Thus, the two quantum nodes 1610, 1620 are configured as part of the system 900. The two nodes 1610, 1620 are configured to support data communication between end devices 1610-4, 1620-4 based on a high-precision TSN mechanism. Each of two nodes 1610, 1620 may include quantum optics 1610-1, 1620-2, workstations 1610-2, 1620-2 including the controller 110, network devices 1610-3, 1620-3 and the end devices 1610-4, 1620-4. The quantum optics 1610-1, 1620-1 may be, but are not limited to, “bulk” or “PIC” photonic integrated circuits. The quantum optics 1610-1, 1620-1 may be a table of quantum optics components, a rack mounted quantum optic system, or a photonic integrated circuit on a chip that is integrated in another device. In some implementations, the quantum optics 1610-1, 1620-1 may involve controlling devices such a interferometer, Bell state analyzers, quantum memory, quantum switches, etc. The workstations 1610-2, 1620-2 include the controller 110 to control the quantum network to support the high-precision TSN mechanism. As discussed above, the controller 110 may generate a TSNschedule (e.g., dynamically changing high-precision TSN schedule) and the gate control list, and provide TSN output including the TSN schedule and the gate control list to the network devices 1610-3, 1620-3. The network devices 1610-3, 1620-3 include network devices 910, 108, etc. The network devices 1610-3, 1620-3 are configured to operate or provide functionality to support TSL flow based on the TSN output. For example, the network devices 1610-3, 1620-3 may operate gates open / close according to the gate control list and transmit frames of a high-precision TSN flow from the end device 1610-4 to the end device 16020-4 over the quantum network based on the TSN schedule. The network devices 1610-3, 1620-3 include switches that provide subnanosecond Ethernet frame control over a quantum network at two end devices 1610-4, 1620-4 separated by ~20km to 70km. The gate control list allows Ethernet frames to arrive at precise times to control configure, monitor, and control quantum optics equipment. The end devices 1610- 4, 1620-4 include the source device 910, the destination devices 920, input / output (I / O) devices 102 and a controller 104, etc. In some implementations, each of two nodes 1610, 1620 may include control electronics. The control electronics are provided to perform quantum operations on single photons in the quantum optics.

[0187] Fig. 17 illustrates example quantum nodes in accordance with one or more implementations.

[0188] Fig. 17 is similar to Fig. 16 and illustrates two nodes 1710, 1720 in a high-precision TSN controlled quantum network 1700. Particularly, Fig. 17 illustrates how high-precision TSN can be used to both sample, transport, and reconstruct digital input / output (DIO) to implement a quantum network. The two nodes 1710, 1720 are configured to communicate with each other in the high-precision TSN controlled quantum network 1700 and provide functionality for a high- precision TSN flow from a source device (e.g., 910) across a quantum network to a destination device (e.g., 920) based on a TSN schedule (e.g., dynamically changing high-precision TSN schedule, etc.). The two nodes 1710, 1720 can communicate with a converter (ethernet to digital I / O converter) 1730 which is configured to sample quantum signal(s) over consecutive 10 ns periods and distribute Digital Input / output (DIO) to network devices 1710-1, 1720-1. As discussed above, DIO parameters are part of high-precision TSN parameters and provided to configure the network devices 1710-1, 1720-1. Digital Input / Output (DIO) is enabled by TSN and used to control the optical components of the quantum network (e.g., quantum operation as discussed above). Samples of DIO values (or their timestamps) are placed in TSN Ethernetframes and deterministically transmitted to their destination DIO port of network devices 1710-1, 1720-1, where they are replayed as output or otherwise analyzed or processed to enable quantum operation based on the TSN schedule (e.g., dynamically changing high-precision TSN schedule, etc.) as discussed in Fig. 1 -Fig. 16. In some implementations, the converter 1730 may be implemented as part for each of network devices 1710-1, 1720-1. The network devices 1710-1, 1720-1 include network devices 910, 108, etc. In some implementations, the network device 1710-1 may package timestamps (or DIO values) in Ethernet frame. As discussed above, the controller 110 (not shown) may configure the network device 1710-1 with high-precision TSN parameters (or TSN parameters) including DIO values to send frames in 10ns transmission window such that signals can be reconstructed seamlessly (with 10ns delay). As discussed above, the controller 110 may provide the network devices 1710-1, 1720-1 with TSN schedules. In some implementations, the network device 1720-1 receives frames including DIO values and covert back to DIO signals to reconstruct DIO signals with 10ns delay. The converter 1730 may output reconstructed DIO signals and provide reconstructed signals to the network device 1720- 1. DIO signals are the individual Is and 0s that control a device (network devices 1710-1, 1720- 1) and typically transmitted in analog form directly over RF cables since that allows for very fast, precise control that could not be achieved using Ethernet. In the present disclosure, DIO signals are transmitted in the Ethernet frame so it is transmitted with the same level of timing control (e.g., TSN parameters) over Ethernet. Thus, the network device 1720-1 receives frames including DIO values and covert back to DIO signals virtually (without reconstruction) to compute quantum control decision so that the network device 1720-1 is configured to perform quantum operations based on the high-precision TSN schedule.

[0189] Fig. 18 illustrates a flow diagram of example operations of a system in accordance with one or more implementations.

[0190] A flow diagram 1800 illustrates operations of a system (e.g., the system 900) as discussed in Fig. 1- Fig. 17. In some implementations, the operations of the system can be implemented by a processor (e.g., the controller 110) which is coupled with a memory. In some implementations, the memory can store one or more instructions which when executed by the processor causes the processor to perform following operations as described in the flow diagram 1800. In some implementations, a processor and a memory are communicatively coupled witheach other. The processor may be a microprocessor or multi-core processor, an integrated circuit, a field programmable gate array, etc. that executes instructions (stored in memory device 1320, for example). The memory stores computer program instructions in a machine-readable or computer-readable medium (also referred to as computer-readable storage media, machine- readable media, or machine-readable storage media).

[0191] The operations include operation 1810 to receive signals from a source device (e.g., 910).

[0192] The operations include operation 1820 to determine whether to configure a high time resolution network device with a high time resolution TSN parameter based on Wavelet or Fourier Transform analysis of the signals from the source device. As discussed above, the system supports the high-precision TSN mechanism and TSN mechanism simultaneously, the controller 110 can determine whether to use the high-precision TSN mechanism. In some implementations, the controller 110 can apply Wavelet and / or Fourier Transform techniques to determine whether to use the high-precision TSN mechanism. For example, the controller 110 may partition a signal into frequency components to compute lose and gain by using the high-precision TSN mechanism and TSN mechanism. The controller 110 can identify the impact of the high- precision mechanism and TSN mechanism on the real-time fidelity of the signal. If the signal requires high precision and resolution to reconstruct the signal, the controller 110 can determine to apply the high-precision TSN mechanism.

[0193] The operations include operation 1830 to the high time resolution network device of the plurality of network devices with a high time resolution TSN parameter for time-sensitive deterministic communication based on a high time resolution TSN mechanism. In accordance with the high time resolution TSN parameter, an operational timing associated with the high time resolution network device is set in picoseconds, and an operational timing associated with a legacy network device of the plurality of network devices configured with the legacy TSN mechanism is set in nanoseconds. For example, the operational timing associated with the high time resolution network device is different from the operational timing associated with a legacy network device of the plurality of network devices configured with a legacy TSN mechanism. For example, the operational timing associated with the high time resolution network device is faster than 40 nanoseconds and the operational timing associated with the legacy TSNmechanism is up to 40 nanoseconds. The controller 110 can identify which network devices among the plurality of network devices to be configured based on the high-precision TSN mechanism and how they are connected. For example, the controller 110 can identify or distinguish the at least one high time resolution network device 930 among the plurality of network devices to be configured based on the high-precision TSN mechanism. In some implementations, the at least one high time resolution network device 930 includes switches commonly called “bridges” or “nodes”) which transmit and receive the data (in one non-limiting example, Ethernet frames) in high-precision TSN flow. The controller 110 can compute novel high-precision TSN parameters and schedule the end-to-end transmission for each high-precision TSN flow.

[0194] Fig. 19 illustrates a flow diagram of example operations of a system in accordance with one or more implementations.

[0195] A flow diagram 1900 illustrates operations of a system (e.g., the system 900) as discussed in Fig. 1- Fig. 18. In some implementations, the operations of the system can be implemented by a processor (e.g., the controller 110) which is coupled with a memory. In some implementations, the memory can store one or more instructions which when executed by the processor causes the processor to perform following operations as described in the flow diagram 1900. In some implementations, a processor and a memory are communicatively coupled with each other. The processor may be a microprocessor or multi-core processor, an integrated circuit, a field programmable gate array, etc. that executes instructions (stored in memory device 1320, for example). The memory stores computer program instructions in a machine-readable or computer-readable medium (also referred to as computer-readable storage media, machine- readable media, or machine-readable storage media).

[0196] The operations include operation 1910 to configure at least one of a plurality of network devices (e.g., 106, 108, 930) with a TSN parameter for time-sensitive deterministic communication from the source device to a destination device based on a TSN schedule. In some implementations, the plurality of network devices configured to provide functionality for data communication from a source device across a communication network to a destination device.

[0197] The operations include operation 1920 to monitor noise in the communication network. For example, the system may perform TSN built-in performance monitoring operations as discussed in Fig. 12 A communication network (e.g., a wireless network configured in accordance with a 3GPP-defined standard, a quantum network, etc.) associated with the system may dynamically change due to the noise. In such environment, the system 900 monitor the communication network to check if there is any noise in the communication network.

[0198] The operations include operation 1930 to dynamically adjusting the TSN schedule based on the noise such that the at least one of the plurality of network devices supports the timesensitive deterministic communication in accordance with the adjusted TSN schedule while avoiding frame loss and delay caused by the noise. TSN flows (high-precision TSN flows) will dynamically change as a function of time.

[0199] In some implementations, the TSN parameter includes a high time resolution TSN parameter which is used to configure a high time resolution TSN network of the plurality of network devices based on a high time resolution TSN mechanism. As discussed above, an operational timing associated with the high time resolution network device is different from an operational timing associated with a legacy network device of the plurality of network devices configured with a legacy TSN mechanism. The high time resolution TSN parameter includes a gate accuracy parameter indicating accuracy with which gate operations associated with the high time resolution network device are consistently applied, a time resolution parameter indicating time resolution with which gate operations associated with the high time resolution network device are configured and reported.

[0200] In some implementations, the communication network includes a quantum network, the controller is configured to generate a gate control list to control gate open and close time of each gate associated with the at least one network device based on dynamically adjusted TSN schedule. In some implementations, a cycle of gate open and close time of each gate is configured to implement a quantum operation to process a single photon in the quantum network corresponding to a respective TSN flow.

[0201] In some implementations, the system includes a first TSN domain to support one or more high time resolution TSN flows based on the high time resolution TSN mechanism and a second TSN domain to support one or more TSN flows based on the legacy TSN mechanism, the first TSN domain including the high time resolution network device, the second TSN domain including the legacy network device of the plurality of network devices.

[0202] the high time resolution network device of the plurality of network devices with the a high time resolution TSN parameter for time-sensitive deterministic communication based on a high time resolution TSN mechanism. In accordance with the high time resolution TSN parameter, an operational timing associated with the high time resolution network device is different from an operational timing associated with a legacy network device of the plurality of network devices configured with a legacy TSN mechanism. For example, the operational timing associated with the high time resolution network device is faster than 40 nanoseconds and the operational timing associated with the legacy TSN mechanism is up to 40 nanoseconds. The controller 110 can identify which network devices among the plurality of network devices to be configured based on the high-precision TSN mechanism and how they are connected. For example, the controller 110 can identify or distinguish the at least one high time resolution network device 930 among the plurality of network devices to be configured based on the high- precision TSN mechanism. In some implementations, the at least one high time resolution network device 930 includes switches commonly called “bridges” or “nodes”) which transmit and receive the data (in one non-limiting example, Ethernet frames) in high-precision TSN flow. The controller 110 can compute novel high-precision TSN parameters and schedule the end-to- end transmission for each high-precision TSN flow.

[0203] Those of skill in the art would appreciate that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein may be implemented as electronic hardware, computer software, or combinations of both. To illustrate this interchangeability of hardware and software, various illustrative blocks, modules, elements, components, methods, and algorithms have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functionality may be implemented in varying ways for each particular application. Variouscomponents and blocks may be arranged differently (e.g., arranged in a different order, or partitioned in a different way) all without departing from the scope of the subject technology.

[0204] It is understood that the specific order or hierarchy of steps in the processes disclosed is an illustration of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged. Some of the steps may be performed simultaneously. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

[0205] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. The previous description provides various examples of the subject technology, and the subject technology is not limited to these examples. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. Pronouns in the masculine (e.g., his) include the feminine and neuter gender (e.g., her and its) and vice versa. Headings and subheadings, if any, are used for convenience only and do not limit the disclosure described herein.

[0206] The predicate words “configured to”, “operable to”, and “programmed to” do not imply any particular tangible or intangible modification of a subject, but, rather, are intended to be used interchangeably. For example, a processor configured to monitor and control an operation or a component may also mean the processor being programmed to monitor and control the operation or the processor being operable to monitor and control the operation. Likewise, a processor configured to execute code can be construed as a processor programmed to execute code or operable to execute code.

[0207] The term automatic, as used herein, may include performance by a computer or machine without user intervention; for example, by instructions responsive to a predicate actionby the computer or machine or other initiation mechanism. The word “example” is used herein to mean “serving as an example or illustration.” Any aspect or design described herein as “example” is not necessarily to be construed as preferred or advantageous over other aspects or designs.

[0208] A phrase such as an “aspect” does not imply that such aspect is essential to the subject technology or that such aspect applies to all configurations of the subject technology. A disclosure relating to an aspect may apply to all configurations, or one or more configurations. An aspect may provide one or more examples. A phrase such as an aspect may refer to one or more aspects and vice versa. A phrase such as an “embodiment” does not imply that such embodiment is essential to the subject technology or that such embodiment applies to all configurations of the subject technology. A disclosure relating to an embodiment may apply to all embodiments, or one or more embodiments. An embodiment may provide one or more examples. A phrase such as an “embodiment” may refer to one or more embodiments and vice versa. A phrase such as a “configuration” does not imply that such configuration is essential to the subject technology or that such configuration applies to all configurations of the subject technology. A disclosure relating to a configuration may apply to all configurations, or one or more configurations. A configuration may provide one or more examples. A phrase such as a “configuration” may refer to one or more configurations and vice versa.

[0209] All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. No claim element is to be construed under the provisions of 35 U.S.C. § 112(f), unless the element is expressly recited using the phrase “means for” or, in the case of a method claim, the element is recited using the phrase “step for”.

Claims

What is claimed is:

1. A system configured to support time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism, the system comprising: a plurality of network devices configured to provide functionality for data communication from a source device across a communication network to a destination device, at least some of the plurality of network devices being configured to use a legacy TSN mechanism; and a controller arranged to configure a high time resolution network device of the plurality of network devices with a high time resolution TSN parameter for time-sensitive deterministic communication from the source device to the destination device based on a high time resolution TSN mechanism, wherein in accordance with the high time resolution TSN parameter, an operational timing associated with the high time resolution network device is set in picoseconds, and an operational timing associated with a legacy network device of the plurality of network devices configured with the legacy TSN mechanism is set in nanoseconds.

2. The system of claim 1, wherein the controller is configured to determine whether to configure the high time resolution network device with the high time resolution TSN parameter based on Wavelet or Fourier Transform analysis of signals from the source device.

3. The system of claim 1, the system further comprising: a first TSN domain to support one or more high time resolution TSN flows based on the high time resolution TSN mechanism and a second TSN domain to support one or more TSN flows based on the legacy TSN mechanism, the first TSN domain including the high time resolution network device, the second TSN domain including the legacy network device of the plurality of network devices.

4. The system of claim 3, the system further comprising: a clock configured to provide time synchronization between the first TSN domain and the second TSN domain so that at least one of the one or more high time resolution TSN flows passes from the first TSN domain to the second TSN domain.

5. The system according to claim 4, wherein the controller is configured to provide a maximum latency parameter to represent a change in precision between the first TSN domain and the second TSN domain.

6. The system according to claim 5, wherein the controller is configured to bundle the at least one of the one or more high time resolution TSN flows into a single TSN flow based on the legacy TSN mechanism in the second TSN domain.

7. The system according to claim 5, wherein the controller is configured to partition the at least one TSN flow into a plurality of high-precision TSN flow based on the high precision TSN mechanism in the first TSN flow.

8. The system of claim 1, wherein the operational timing associated with the high time resolution network device is less than 40 nanoseconds, and the operational timing associated with the legacy network device is up to 40 nanoseconds.

9. The system of claim 1, wherein the high time resolution TSN parameter includes a gate accuracy parameter indicating accuracy with which gate operations associated with the high time resolution network device are consistently applied, a time resolution parameter indicating time resolution with which gate operations associated with the high time resolution network device are configured and reported.

10. The system according to claim 9, wherein the high time resolution TSN parameter further includes a delay parameter, a fiber length parameter and a wavelength parameter.

11. The system of claim 1, wherein the controller is configured to provide digital input / output (DIO) parameters including: a DIO enabled parameter indicating whether the DIO is enabled, a DIO value parameter indicating whether timestamps or digital signal values are placed in Ethernet fames of the high time resolution TSN flow, a DIOstreamID parameter identifying asteam of DIO, and a DIOnumberSamples parameter indicating a number of DIO samples placed in each Ethernet fame of the high time resolution TSN flow.

12. The system of claim 1, wherein the controller is configured to provide dynamically changing TSN schedule for high time resolution TSN flows which periodically vary in a determined cycle time.

13. The system of claim 12, wherein the high time resolution network device includes a high time resolution TSN data bus to implement gate operations based on the dynamically changing TSN schedule.

14. The system of claim 1, wherein the high time resolution network device is configured to provide monitoring operations for monitoring the high time resolution TSN flow based on arrival time of each frame of the high time resolution TSN flow.

15. The system of claim 14, wherein the monitoring operations determine if errors in the high time resolution TSN flow exceeds thresholds, in response to the determination that the errors in the high time resolution TSN flow exceeds thresholds, the monitoring operations output signal indicating the errors in the high time resolution TSN flow.

16. The system of claim 1, wherein the communication network includes a wireless network configured in accordance with a 3 GPP-defined standard.

17. The system of claim 1, wherein the communication network includes a quantum network.

18. The system of claim 17, wherein the controller is configured to generate a gate control list to control gate open and close time of each gate in the at least one network device based on dynamically changing TSN schedule of the high time resolution TSN mechanism.

19. The system of claim 18, wherein a cycle of gate open and close time of each gate is configured to implement a quantum operation to process a single photon in the quantum network corresponding to a respective high time resolution TSN flow.

20. The system according to claim 1, further comprising: an interface configured to receive an input for periodically changing at least one of high time resolution TSN flows based on the high time resolution TSN mechanism or TSN flows based on the legacy TSN mechanism.21 . A method for controlling a communication network based on a time-sensitive network (TSN) mechanism, comprising: receiving signals from a source device; determining whether to configure a high time resolution network device of a plurality of network devices with a high time resolution TSN parameter based on Wavelet or Fourier Transform analysis of the signals from the source device, wherein the plurality of network devices configured to provide functionality for data communication from the source device across a communication network to a destination device, at least some of the plurality of network devices being configured to use a legacy TSN mechanism; and in response to determination, configuring the high time resolution network device of the plurality of network devices with the high time resolution TSN parameter for time-sensitive deterministic communication from the source device to a destination device based on a high time resolution TSN mechanism, wherein in accordance with the high time resolution TSN parameter, an operational timing associated with the high time resolution network device is set in picoseconds, and an operational timing associated with a legacy network device of the plurality of network devices configured with the legacy TSN mechanism is set in nanoseconds.

22. A non-transitory computer readable medium storing instructions that, when executed by a processor, cause the processor to: determine whether to configure a high time resolution network device of a plurality of network devices with a high time resolution TSN parameter based on Wavelet or Fourier Transform analysis of the signals from the source device, wherein the plurality of networkdevices configured to provide functionality for data communication from the source device across a communication network to a destination device, at least some of the plurality of network devices being configured to use a legacy TSN mechanism; and in response to determination, configure the high time resolution network device of the plurality of network devices with a high time resolution TSN parameter for time-sensitive deterministic communication from the source device to a destination device based on a high time resolution TSN mechanism, wherein in accordance with the high time resolution TSN parameter, an operational timing associated with the high time resolution network device is set in picoseconds, and an operational timing associated with a legacy network device of the plurality of network devices configured with the legacy TSN mechanism is set in nanoseconds.

23. A system configured to support time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism, the system comprising: a plurality of network devices configured to provide functionality for data communication from a source device across a communication network to a destination device; and a controller arranged to configure at least one of the plurality of network devices with a TSN parameter for time-sensitive deterministic communication from the source device to the destination device based on a TSN schedule, monitor noise in the communication network and dynamically adjust the TSN schedule based on the noise such that the at least one of the plurality of network devices supports the time-sensitive deterministic communication in accordance with the adjusted TSN schedule.

24. The system according to claim 23, wherein the TSN parameter includes a high time resolution TSN parameter, in accordance with the high time resolution TSN parameter, the controller configures a high time resolution TSN network device of the plurality of network devices based on a high time resolution TSN mechanism.

25. The system according to claim 24, wherein an operational timing associated with the high time resolution network device is set in picoseconds.

26. The system according to claim 24, wherein the high time resolution TSN parameter includes a gate accuracy parameter indicating accuracy with which gate operations associated with the high time resolution network device are consistently applied and a time resolution parameter indicating time resolution with which gate operations associated with the high time resolution network device are configured and reported.

27. The system according to claim 24, further comprising: an interface configured to receive an input for periodically changing at least one of high time resolution TSN flows based on the high time resolution TSN mechanism.

28. The system of claim 23, wherein the communication network includes a quantum network, the controller is configured to generate a gate control list to control gate open and close time of each gate associated with the at least one network device based on the adjusted TSN schedule.

29. The system of claim 28, wherein a cycle of gate open and close time of each gate is configured to implement a quantum operation to process a single photon in the quantum network corresponding to a respective TSN flow.

30. The system of claim 24, wherein the controller is configured to: determines if errors in the high time resolution TSN flow exceed thresholds for jitter and latency, in response to the determination that the errors in the high time resolution TSN flow exceed the thresholds, output a signal indicating the errors in the high time resolution TSN flow.

31. A method for controlling a communication network based on a time-sensitive network (TSN) mechanism, comprising: configuring at least one of a plurality of network devices with a TSN parameter for timesensitive deterministic communication from the source device to a destination device based on a TSN schedule, the plurality of network devices configured to provide functionality for data communication from a source device across a communication network to a destination device;monitoring noise in the communication network; and dynamically adjusting the TSN schedule based on the noise such that the at least one of the plurality of network devices supports the time-sensitive deterministic communication in accordance with the adjusted TSN schedule.

32. A non-transitory computer readable medium storing instructions that, when executed by a processor, cause the processor to: configure at least one of a plurality of network devices with a TSN parameter for timesensitive deterministic communication from the source device to a destination device based on a TSN schedule, the plurality of network devices configured to provide functionality for data communication from a source device across a communication network to a destination device; monitor noise in the communication network; and dynamically adjust the TSN schedule based on the noise such that the at least one of the plurality of network devices supports the time-sensitive deterministic communication in accordance with the adjusted TSN schedule.

Images