Configuration interface for time-sensitive network (TSN)-based communication networks

Abstract

This disclosure provides techniques for implementing a configuration module associated with a communication network that supports time-sensitive deterministic communications based on a time-sensitive network (TSN) mechanism. A disclosed configuration module associated with a first network domain in a communication network may include an interface configured to communicate with a plurality of configuration modules associated with different network domains in the communication network to share configuration data between the configuration module and the plurality of configuration modules. The configuration data includes parameters required for each TSN stream to support time-sensitive deterministic communications of the respective TSN stream in accordance with the configuration data. The configuration module and the plurality of configuration modules configure one or more communication network components as one or more TSN blocks based on configuration data to support communication for each individual TSN stream, each individual TSN stream flowing through a first network domain and a different network domain in the communication network.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to time sensitive network (TSN) based communication systems, and more particularly, for example, to configuration and configuration interfaces for TSN based communication systems. BACKGROUND

[0002] Some applications, such as industrial automation and manufacturing, require ubiquitous and seamless connectivity with strict, deterministic timing requirements for communication between various devices or components of the application (e.g., industrial controllers, sensors, actuators, etc.). To meet such requirements, a TSN system that provides deterministic communication with relatively strict quality of service (QoS) parameters such as latency, jitter, and reliability requirements can be integrated with a 3GPP compliant wireless communication system that provides high reliability services (e.g., ultra-reliable low latency communication (URLLC) services). Further, typical configuration interfaces for configuring a TSN network allow for defining transmission selection and redundancy characteristics of TSN data flows, but do not provide for automatic configuration of other features such as time aware scheduling and policing features on a per flow basis. SUMMARY

[0003] The technology, systems, and processes described herein relate to a configuration module associated with a first network domain in a communication network, the configuration module including an interface to communicate with a plurality of configuration modules associated with different network domains in the communication network to share configuration data between the configuration module and the plurality of configuration modules. The communication network supports time sensitive deterministic communication based on time sensitive network (TSN) mechanisms. The configuration data includes parameters required for each TSN flow to support time sensitive deterministic communication of the respective TSN flow in accordance with the configuration data. The configuration module and the plurality of configuration modules configure one or more communication network (CN) components as one or more TSN blocks to support communication of each individual TSN flow that flows through the first network domain and the different network domains in the communication network based on the configuration data. In some implementations, the configuration data includes a time aware scheduling (TAS) parameter that indicates whether to schedule each individual TSN flow using TAS, information that indicates whether to apply cyclic queuing and forwarding (CQF) to each individual TSN flow. In some implementations, the TAS parameter is in a Boolean format. In some implementations, the configuration data includes information that indicates whether to police each individual TSN flow in the communication network using per-flow filtering and policing (PSFP). In some implementations, at least one of the configuration module and the plurality of configuration modules receives information from a configuration element module in the communication network that indicates whether to police each individual TSN flow in the communication network using per-flow filtering and policing (PSFP).

[0004] In one aspect, a communication network for supporting time sensitive deterministic communication based on time sensitive network (TSN) mechanisms includes a first configuration module associated with a first network domain in the communication network configured to support time sensitive deterministic communication, a second configuration module associated with a second network domain in the communication network configured to support time sensitive deterministic communication, and an interface between the first configuration module and the second configuration module. The interface is to send configuration data from the first configuration module to the second configuration module such that the second configuration module configures one or more of a plurality of communication network (CN) components in the communication network as one or more TSN blocks based on the configuration data. The configuration data includes parameters required for each TSN stream to support time sensitive deterministic communication of the respective TSN stream according to the configuration data. In some implementations, the configuration data represents one or more TSN features required for each individual TSN stream, the one or more TSN features including at least one of time aware scheduling (TAS), per stream filtering and policing (PSFP), and cyclic queuing and forwarding (CQF). In some implementations, the configuration data includes information representing whether to use TAS to schedule traffic on the communication network. In some implementations, the configuration data includes information representing whether to use PSFP to police each individual TSN stream in the communication network. In some implementations, the configuration data includes information representing whether to apply CQF to each individual TSN stream. Each individual TSN stream flows through the first network domain and the second network domain in the communication network. The communication network can include a configuration element module configured to provide configuration elements to at least one of the first configuration module and the second configuration module, including one or more TSN features required for each individual TSN stream, the one or more TSN features including at least one of time aware scheduling (TAS), per stream filtering and policing (PSFP), and cyclic queuing and forwarding (CQF). In some implementations, the communication network includes a wireless network configured according to standards defined by 3GPP.

[0005] In another aspect, a configuration module associated with a communication network supporting time sensitive deterministic communication based on time sensitive network (TSN) mechanisms is provided. The configuration module can include a first configuration module associated with a source device or a destination device and configured to provide configuration data for each individual TSN flow transmitted via at least some of a plurality of communication network (CN) components in the communication network, and a second configuration module associated with the plurality of CN components. In some implementations, the first configuration module is further configured to communicate with the second configuration module via an API such that the second configuration module configures one or more of the plurality of CN components as one or more TSN blocks based on the configuration data. The configuration data represents one or more TSN features required for each individual TSN flow, the one or more TSN features including at least one of time aware scheduling (TAS), per-flow filtering and policing (PSFP), and cyclic queuing and forwarding (CQF). The configuration data further includes a TAS parameter representing whether time aware scheduling (TAS) is used to schedule each individual TSN flow, and information representing whether cyclic queuing and forwarding (CQF) is applied to each individual TSN flow. In some implementations, the communication network includes one or more network domains through which each individual TSN flow flows according to the configuration data. The first configuration module and the second configuration module are associated with a same network domain of the plurality of network domains. The second configuration module is further configured to share the configuration data with a plurality of configuration modules associated with different network domains of the plurality of network domains. In some implementations, the TAS parameter is in a Boolean format. The configuration data further includes information representing whether per-flow filtering and policing (PSFP) is used to police each individual TSN flow in the communication network. In some implementations, the second configuration module is further configured to receive, from a configuration element module in the communication network, information representing whether per-flow filtering and policing (PSFP) is used to police each individual TSN flow in the communication network. BRIEF DESCRIPTION OF DRAWINGS

[0006] Some of the features of the present disclosure technology are set forth in the appended claims. However, for purpose of explanation, several aspects of the present disclosure technology are set forth in the following drawings.

[0007] Figure 1 An example of a conventional integrated TSN-5G system is shown in accordance with one or more implementations.

[0008] Figure 2 A block diagram of an example integrated TSN-5G system architecture is shown in accordance with one or more implementations.

[0009] Figure 3 An example of an integrated TSN-5G system is shown in accordance with one or more implementations.

[0010] Figure 4A block diagram illustrating an example TSN block, in accordance with one or more implementations, is shown.

[0011] Figure 5 A block diagram illustrating an example TSN block, in accordance with one or more implementations, is shown.

[0012] Figure 6A 、 6B A block diagram illustrating an example integrated TSN-5G system architecture including MEC, in accordance with one or more implementations, is shown.

[0013] Figure 7 An electronic system for which one or more implementations of the disclosure technology can be implemented is shown.

[0014] Figure 8 A block diagram illustrating an example integrated TSN-5G system architecture, in accordance with one or more implementations, is shown.

[0015] Figure 9 A non-limiting example of a TSN communication network system, in accordance with one or more implementations, is shown.

[0016] Figure 10 A non-limiting example of configuration data, in accordance with one or more implementations, is shown.

[0017] Figure 11 A block diagram illustrating an example of an integrated TSN communication network system architecture, in accordance with one or more implementations, is shown.

[0018] Figure 12 A block diagram illustrating an example of an integrated TSN communication network system architecture, in accordance with one or more implementations, is shown. DETAILED DESCRIPTION

[0019] The following detailed description is intended to be read in connection with the drawings, which are part of the detailed description. Specific structural and functional details disclosed herein are presented as representative examples. The description is intended to provide a thorough understanding of the disclosure technology for the appropriate beneficiaries. However, the disclosure technology is not limited to the specific details described herein and can be practiced with one or more other implementations. In some implementations, structures and components are shown in block diagram form in order to avoid obscuring the concepts of the disclosure technology.

[0020] As described above, for some applications such as, but not limited to, industrial automation, manufacturing, and aerospace and automotive in-vehicle communications, TSN systems that provide deterministic communication can be integrated with fifth-generation (5G) or sixth-generation (6G) wireless communication systems (or any communication network or system defined according to the 3GPP standard or the IEEE 802.1 standard). However, typically, in such integrated TSN-5G systems, the entire 5G system is configured to operate as a single TSN component (e.g., a TSN bridge), and the integrated system is configured in a fully centralized configuration model, such as using a centralized TSN configuration controller. Therefore, such integrated systems may not support the flexibility of deploying 5G systems that include various components provided by different vendors or decentralized TSN configurations for the integrated system. In addition, 5G systems can support reliable communication by using redundant paths for data transmission. However, as the 5G system is configured as a TSN component in a typical TSN-5G integrated system, redundant paths are configured throughout the 5G system through all its components (e.g., from user equipment (UE) to user plane function (UPF)). This does not allow the flexibility to set up redundant data transmission paths for only part of the 5G system, e.g., parts of the 5G system that are more susceptible to data delays and / or errors, such as the air interface between the UE and the Radio Access Network (RAN) / gNodeB.

[0021] In order to address the above-mentioned problems in the integrated TSN-5G system, the disclosed technology provides a novel architecture in which the 5G system is not configured as a single TSN component or block, but as a set of discrete 5G components, each of which is configured as a discrete TSN block. In other words, the present disclosure provides an architecture in which the 5G system in the integrated TSN-5G system is divided into multiple TSN blocks, each of which is configured according to the TSN specification (e.g., according to IEEE 802.1Q and related standards), such as a TSN bridge, a TSN terminal device, or a combination of the two. In addition, instead of having a centralized configuration controller to control the TSN-5G system, the disclosed technology provides multiple distributed configuration modules in the TSN-5G system. The configuration modules can be interconnected in one or more topologies (including mesh, star, tree, or random), and each configuration module can be responsible for communicating with and configuring one or more TSN blocks.

[0022] As discussed in detail below, each of the plurality of TSN blocks of the 5G system includes a parameter set describing the capabilities to support and execute data flows (e.g., carrying URLLC data traffic) through that TSN block. Further, each TSN block can include at least one configuration interface configured to support interaction of the TSN block with its respective configuration module. The configuration interface can be used to provide the parameter set of the TSN block to the respective configuration module, and to receive configuration data (e.g., transmission schedule, data flow identity, policing rules, etc.) from the configuration module to support one or more data flows through the TSN block. Each TSN block can be configured to execute or operate according to the configuration data (received via the configuration interface), and to transmit data of each data flow according to the specification provided in the configuration data. Finally, each TSN block can also include a monitoring and diagnostic module configured to monitor the runtime behavior of the TSN block and report that behavior through the configuration interface or via a separate interface of the TSN block.

[0023] Each of the plurality of distributed configuration modules can be an external utility responsible for configuring one or more TSN blocks, or can be configured as a software module within a TSN block that configures only that TSN block. Each configuration module can be configured to determine configuration data including TSN schedules for one or more data flows to be transmitted through a TSN block, and to provide that configuration data to the TSN block controlled by the configuration module. The configuration modules can exchange information with each other using standardized application programming interfaces (APIs). The exchanged information can include information about the cycle times of the TSN system (e.g., supported administrative cycle times (ACTs) including discrete levels of ACT buckets corresponding to particular data flows, respectively, maximum / minimum cycle times), configuration data including transmission schedules for one or more TSN blocks (including time offsets / durations / resources for transmissions), and information for requesting resource allocations or responding to requests for resource allocations. In some implementations, one or more of the plurality of configuration modules can be adapted as a “controller” or “controller module,” which can include a component configured or adapted to provide instructions, control, operation, or any form of communication to an operable component to affect operation of the operable component. The controller module can include any known processor, microcontroller, or logic device, including but not limited to: a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a full authority digital engine control (FADEC), an avionics 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 combinations thereof.

[0024] 3GPP Release 8 classifies self-organizing networks (SON) into three main categories: self-configuration, self-optimization, and self-healing. Self-organization is viewed as a mechanism or process that enables a system or network to change its organization during execution without explicit commands. Self-configuration is defined as the process of bringing new network elements (NEs) into service requiring minimal human operator intervention, where a network element is a manageable logical entity that unites one or more physical devices together. In some implementations, a TSN block (discussed below) can be self-configured and brought into a 5G system as an NE with minimal human intervention. This can be accomplished by automatically sharing its TSN flow characteristics and latency requirements with TSN applications that the TSN block shares. The TSN blocks can collaborate to share flow characteristics and determine a feasible TSN schedule.

[0025] 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 according to 3GPP standards or IEEE 802.1 standards), configured to support time-sensitive deterministic communication based on time-sensitive network (TSN) mechanisms. Any reference to a “communication network,” “wireless network,” and “communication / wireless network” in the context of the present disclosure indicates 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 through the network, with at least a portion of the communication being accomplished wirelessly. Thus, various components of such a network can 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 / channels implemented in hardware, software, and combinations of hardware and software.

[0026] The communication network can include a plurality of discrete communication network (CN) components. Each CN component can be configured to provide a discrete function for communication of data from a source device through the network to a destination device. The communication / wireless network can also include a processor arranged to configure at least one (or each) of the plurality of CN components with a TSN parameter set of a TSN mechanism. Upon configuration with the TSN parameter set, at least one (or each) of the plurality of CN components can support time-sensitive deterministic communication as a TSN block in a TSN network according to the TSN parameter set. In other words, at least one (or each) of the plurality of CN components can operate as a typical TSN block in a TSN network.

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

[0028] The communication network can include a configuration module configured to determine a set of TSN parameters for 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 latency 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.

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

[0030] In some implementations, the present disclosure provides a system including a first communication (e.g., 5G / 6G) network, a second communication (e.g., 5G / 6G) network, and a TSN transport channel connected with the first communication network and the second communication network. The first network can include a first plurality of discrete communication network (CN) components each configured to provide a discrete function of 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 according to a first set of TSN parameters. The second network can include a second plurality of discrete CN components each configured to provide a discrete function of 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 according to a second set of TSN parameters. The TSN transport channel can be configured to facilitate time-sensitive deterministic communication of data exchanged between the first network and the second network according to a third set of TSN parameters. In some implementations, 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.

[0031] In some implementations, the integrated TSN-5G system can provide multiple configuration modules in a distributed controller to control the integrated TSN-5G system. The multiple configuration modules can be interconnected in one or more topologies (mesh, star, tree), and each configuration module configures network components as TSN blocks to support TSN features specified by TSN specifications (e.g., IEEE 802.1Q). In the integrated TSN-5G system, at least two of the multiple configuration modules (e.g., centralized network configuration (CNC)) can exchange configuration data (e.g., transmission schedule, data flow identity, policing rules, etc.) through a standardized API to support one or more data flows through the TSN blocks. This is not limited to TSN-5G systems, but also applies to TSN systems integrated with 3GPP compliant wireless communication systems. The configuration data can be specified by TSN specifications (e.g., IEEE 802.1Q), and the standardized API can be based on IEEE 802.1Q clause 46.2.3 standard. IEEE 802.1Q is incorporated herein in its entirety by reference. The configuration data is provided on a flow-by-flow basis, i.e., for each individual TSN flow in the TSN network, a configuration, e.g., regarding transmission selection and redundancy features for each TSN flow. Accordingly, the configuration modules configure one or more TSN blocks (e.g., TSN bridges) to perform or operate according to the configuration data. In some implementations, the integrated TSN-5G system can employ one or more TSN features (e.g., time-aware scheduling (TAS), per-flow filtering and policing (PSFP), cyclic queuing and forwarding (CQF), etc.) according to TSN specifications (IEEE 802.1Q, IEEE 802.1Qbv, IEEE 802.1Qci, etc.) that are required for each individual TSN flow. However, the configuration data shared from one configuration module to another configuration module does not include or provide configuration of such TSN features as parameters required for each individual TSN flow. Rather, such TSN features such as TAS, policing, cyclic queuing, etc. are determined by the network configuration modules based on user input.

[0032] To address the above issues in an integrated TSN communication network system, the present disclosure provides a new improved interface or enhanced API, for example, between a first configuration module (e.g., CUC) associated with an end station or user equipment and a second configuration module (e.g., CNC) associated with a network device such as a network bridge. The new improved interface or enhanced API between the CUC and the CNC allows for detailed description of requirements for each flow. Specific examples of requirements include explicit requirements for scheduling a flow in the network using a time-aware shaper or similar shaper, explicit requirements regarding latency, jitter, and loss, and explicit requirements for filtering and policing a flow in the network. The new improved interface or enhanced API can provide explicit and fine-grained definition of flow requirements between the CUC and the CNC. The new interface or enhanced API is configured to share TSN configuration parameters, features, and requirements between the first configuration module and the second configuration module, including configuration parameters, features, and flow requirements needed to implement TAS, policing, cyclic queuing, etc. for each individual TSN flow communicated via the communication network. Thus, this configuration parameters or features for TAS, policing, cyclic queuing, etc. can be additional parameters or features to the regular parameters shared between regular TSN configuration modules (e.g., CUC and CNC). In some embodiments, such additional configuration parameters can be used by the configuration module receiving such parameters to determine whether time-aware shaping or scheduling is to be implemented for a particular TSN flow on the communication network, whether policing is to be implemented, etc., and to configure the TSN network devices (e.g., bridges) accordingly to handle the particular TSN flow. In some embodiments, the additional configuration parameters related to TAS, policing, and cyclic queuing features can be Boolean parameters. The API can describe flow requirements for each flow beyond the requirements currently defined in TSN specifications (e.g., Clause 46 of IEEE 802.1Q). These flow requirements can include delivery modes such as deadline-based delivery mode or latency-based delivery mode. In the case of deadline-based delivery mode, the requirement can specify an absolute or relative time by which frames belonging to the flow must be delivered to the final destination. In the case of latency-based delivery mode, the requirement can include a maximum tolerable latency for a frame to be transmitted from a source to be received at a destination. In yet another embodiment, the CUC can inform the CNC of a jitter requirement for a flow through the inter-configuration API, which specifies a maximum deviation from a fixed delivery time.

[0033] As mentioned above, the CUC in a respective network domain communicates with one or more CNCs of the same network domain via a new interface or enhanced API. This communication is limited between the CUC and CNCs of the same network domain even in cases where a subset of the configuration data needs to be shared with other network domains to support the TSN features or requirements of each TSN flow. Therefore, to support data flow / streams that interoperate in a standard manner across multiple domains, another interface or API is necessarily required for sharing configuration data (including the requirements of each flow) between configuration modules (CNCs) in multiple network domains.

[0034] To address the above-mentioned problems, the present technology provides yet another new interface between a first configuration module (CNC) associated with a first domain and a second configuration module (CNC) associated with a second domain. The new interface or enhanced API between the two CNCs enables configuration of a TSN network consisting of multiple domains. In some embodiments, the new interface or enhanced API performs the following two specific functions: the new interface or enhanced API enables the communication of flow requirements from a CUC in a first network domain to a CNC in a second network domain via the CNC of the first network domain. This is necessary because the CUC only communicates (communicates flow requirements) with the CNCs of the network domain. Some subset of these requirements need to be communicated to the rest of the CNCs in the communication network. The new interface or enhanced API allows the configuration modules (CNCs) to coordinate the configuration to meet the flow requirements. For example, if there is a latency budget and each CNC has used some of the budget in scheduling the flow through its domain, they need to share this information via the inter-CNC API. These two functions in combination enable the configuration of the entire communication network (including multiple network domains) to meet the requirements of each flow. Therefore, the new interface or enhanced API is configured to share TSN configuration parameters, features, and requirements between the first configuration module and the second configuration module for each individual TSN flow that flows / propagates / transitions between the first domain and the second domain. This TSN configuration information can include configuration parameters or features required to implement TAS, policing, cyclic queuing, forwarding, shaping, metering, filtering for each TSN flow.

[0035] Figure 1A non-limiting example of a conventional integrated TSN-5G system 100 is shown, 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 controllers 104) via the 5G system 106 (emulated as a TSN bridge) and one or more (conventional) TSN bridges 108 and by using a TSN controller 110. The system 100 is configured based on standard methods for time synchronization and traffic management, allowing for deterministic communication between end devices (e.g., I / O devices 102 and controllers 104) via a standard Ethernet network. For example, the system 100 can operate in accordance with the IEEE 802.1Q TSN suite of specifications, which sets standards for Layer 2 communication of Internet Protocols that provide deterministic communication in the context of sharing the same fabric. For example, multiple standards establish various technical paradigms for TSN systems - clock synchronization (802.1AS, Generalized Precision Time Protocol (gPTP)), frame preemption (802.3br and 802.1Qbu), scheduled traffic (802.1Qbv), 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 performed in a manner that meets their respective end deadlines and constraints. As another implementation, a similar integrated system can be configured to implement TSN technology 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.

[0036] For example, the 802.1Qbv TSN standard provides for scheduled transmission of safety-critical data frames in a predetermined manner, and is incorporated herein in its entirety. As used herein, a “TSN mode” can refer to, without limitation, a network, component, element, unit, node, hub, switch, control, module, path, data, data frame, traffic, protocol, operation, transmission, and combinations thereof, that complies with, is configured for, or is compliant with one or more IEEE 802.1 TSN standards. The 802.1Qbv TSN standard addresses the transmission of critical data traffic and non-critical data traffic within TSN. Critical data traffic is ensured to be delivered at a predetermined time, while non-critical data traffic is generally given a lower priority. Various traffic classes have been established in accordance with IEEE 802.1Q, which are used to prioritize different types of traffic.

[0037] Ethernet frame pre-emption is defined by IEEE 802.3br and IEEE 802.1Qbu standards, which can pause transmission of non-critical Ethernet frames, also beneficial to reduce latency and latency variation of critical traffic. The resource management foundation is defined by the TSN configuration model (IEEE 802.1Qcc). Centralized network configuration (CNC) 112 can be applied to network devices (bridges, e.g., 5G system bridge 106, bridge 108), while centralized user configuration (CUC) 114 can be applied to user devices (end stations, e.g., I / O device 102), e.g., as specified in IEEE 802.1Qdj[xx]. The fully centralized configuration model follows the software-defined networking (SDN) approach. In other words, CNC 112 and CUC 114 in controller 110 provide the control plane instead of distributed protocols. In contrast, in the fully distributed model, a distributed control protocol is applied, in which there can be no CNC or CUC.

[0038] As a result of ultra-reliability, high availability can be provided to data flows by FRER (IEEE 802.1CB) through per-packet level reliability mechanisms. This provides reliability by transmitting multiple copies of the same data packet via disjoint paths in the network. Per-flow policing and policing (802.1Qci) improves reliability by protecting against bandwidth violations, faults, and malicious behavior. Furthermore, time synchronization in TSN systems can be defined by gPTP (802.1AS) as a profile of the Precision Time Protocol standard (IEEE 1588). gPTP provides reliable time synchronization, which can be used by other TSN tools such as scheduled traffic (802.1Qbv).

[0039] To achieve a desired level of reliability, TSN employs time synchronization and time-aware data traffic shaping. Data traffic shaping uses scheduling to control the gating of transmissions on network switches and bridges (e.g., nodes). In some aspects, the scheduling of such data traffic in TSN can be determined prior to network operation. In other aspects, the scheduling of data traffic can be determined based on system requirements during an initial design phase and can be updated as needed. For example, in addition to defining a TSN topology (including communication paths, bandwidth reservations, and various other parameters), a network-wide synchronization time for data transmissions can be predefined. Such a plan for data transmissions on the communication paths of a network is often referred to as a “communication schedule” or simply a “schedule.” The scheduling of data traffic on TSN can be determined for a particular data packet on a particular path, at a particular time, for a particular duration. Non-limiting examples of techniques for generating a schedule of TSN data traffic are discussed in U.S. Application No. 17 / 100,356, which is incorporated by reference herein in its entirety.

[0040] Time critical communications between end devices or nodes (e.g., I / O devices 102 and controllers 104) in TSN include “TSN flows,” also referred to as “data flows” or simply “flows.” For example, a data flow can include datagrams, such as data packets or data frames. Each data flow is unidirectional, from a first originating or source end device (e.g., I / O device 102) to a second destination end device (e.g., controller 104) in the system, with a unique identification and time requirements. These source and destination devices are often referred to as “talkers” and “listeners.” Specifically, the “talkers” and “listeners” are the source and destination, respectively, of a data flow, and each data flow is uniquely identified by an end device operating in the system. It will be understood that for a given network topology including multiple interconnected devices, a set of data flows between the interconnected devices or nodes can be defined. For example, a set of data flows can be located between the interconnected devices. For a set of data flows, various subsets or permutations of data flows can additionally be defined. Moreover, time critical communications between end devices or nodes in TSN include “TSN streams” or “streams,” where each TSN stream can originate at a particular talker node that is intended to communicate with one or more listener nodes. Thus, each TSN stream can include one or more data flows, where each data flow is located between the talker node (where the TSN stream originates) and a listener node.

[0041] Both end devices (e.g., 102, 104) and switches (often referred to as “bridges” or “switching nodes”) (e.g., 106, 108) transmit and receive data (in one non-limiting example, Ethernet frames) in data flows based on a predetermined time schedule. The switching nodes and end devices must be time synchronized to ensure that the predetermined time schedule for data flows is properly followed throughout the network. For example, in Figure 1 In some aspects, clock 116 represents time synchronization of various switching nodes and end devices in TSN system 100 (including in 5G system 106) with reference to a global clock (master clock timing). In some other aspects, only switches can transmit data based on a predetermined schedule, while end devices (e.g., legacy devices) can transmit data in a non-scheduled manner.

[0042] Data flows within TSN can be scheduled using a single device (e.g., controller 110) that assumes a fixed, unchanging path through the network between talker / listener devices and switching nodes in the network. Alternatively, a set of devices or modules can be used to schedule data flows. Whether one device or multiple sets of devices, the scheduling devices can be arranged to define a centralized scheduler. In other aspects, the scheduling devices can include a distributed arrangement. TSN can also receive non-time sensitive communications, such as rate-limited communications. In one non-limiting example, the scheduling devices can include an offline scheduling system or module.

[0043] TSN traffic can be labeled using various mechanisms, including VLAN tags, Ethernet addresses, IP header information, and combinations of VLAN tags, Ethernet addresses, and IP header information. Traffic can be identified and labeled anywhere in the system before protocol data unit (PDU) identification is required. TSN talkers can create multiple TSN flows (streams) with different TSN latency and determinism requirements, and can be assigned different paths that satisfy the requirements. In some embodiments of the present disclosure, latency and determinism values can be specified as a finite set of static discrete values and provided to the TSN application, rather than providing an infinite set of continuous values.

[0044] In some implementations, the I / O end devices 102 can be complex mechanical entities, such as a production line of a factory, a gas power plant, an avionics data bus on an airplane, a jet engine on one of a fleet of airplanes (e.g., two or more airplanes), a digital backbone in an airplane, an avionics system, a mission or flight network, a wind farm, a locomotive, etc. In various embodiments, the I / O end devices 102 can include any number of end devices, such as sensors, actuators, motors, and software applications. The sensors can include any conventional sensor or transducer, such as a camera that generates video or image data, an X-ray detector, an acoustic pickup, a tachometer, a global positioning system receiver, a wireless device that transmits wireless signals and detects reflections of the wireless signals in order to generate image data, or another device.

[0045] Further, actuators (e.g., devices, equipment, or machines that move to perform one or more operations of the I / O devices 102) can communicate using the TSN system 100. Non-limiting examples of actuators can include brakes, throttles, robotic devices, medical imaging devices, lights, turbines, etc. The actuators can communicate state 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 state data can represent a position, a state, a health, etc. of the actuator that sent the state data. The actuators can receive command data from one or more other devices of the TSN system 100 (e.g., other I / O devices 102, the controller 104). The command data can represent instructions that dictate how or when the actuator moves, operates, etc.

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

[0047] Referring now to the 5G system 106 within the system 100, the 5G network or system 106 is a wireless communication network or system for carrying TSN traffic between various TSN terminal devices, such as the I / O devices 102 and the controller 104. In some implementations, the 5G system 106 is configured to emulate one TSN bridge per UPF (similar to the TSN bridge 108, in accordance with the TSN standards described above). The 5G system 106 can be a New Radio (NR) network implemented in accordance with the 3GPP 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 (e.g., v17.1.1 and v17.2.0), which are incorporated herein in their entirety. As shown, the 5G system 106 can include various CN components, for example, in the 5G user plane, the UE 118, RAN (gNB) 120, UPF 122, and in the 5G control plane, the Application Function (AF) 124, as well as the SMF and Policy Control Function (PCF) 126, among other components, as defined in the 3GPP 23.501 standard. In some implementations, the 5G system 106 can be configured to provide URLLC services. The NR interface-based 5G system 106 includes several features to enable low latency for selected data flows. NR makes the slots in a wireless subframe shorter, which benefits low latency applications. NR also introduces mini-slots, where priority transmissions can start without waiting for a slot boundary, further reducing latency. As part of giving priority and faster radio access to URLLC traffic, NR introduces pre-emption, where URLLC data transmissions can pre-empt ongoing non-URLLC transmissions. Additionally, NR applies very fast processing, enabling retransmissions even within the short latency bounds.

[0048] In some implementations, 5G defines an additional robust transmission mode that adds reliability for both data and control radio channels. Reliability is further improved by various techniques, such as multi-antenna transmission based on multiple-input multiple-output (MIMO) technology, use of multiple carriers on independent radio links, and packet duplication.

[0049] Time synchronization is embedded in the 5G cellular radio system as a fundamental part of its operation, as has been common practice for earlier generations of cellular networks. Radio network components themselves are also time-synchronized, for example, through the Precision Time Protocol telecommunication profile, for example, based on the 5G internal system clock 190. This provides a good basis for producing synchronization for time-critical applications. For URLLC services, the 5G system 106 uses time synchronization for its own operation, as well as multiple antennas and radio channels that provide reliability. In addition to 5G RAN features, the 5G system 106 can also provide solutions for Ethernet networking and URLLC in the core network. The 5G core network supports local Ethernet PDU sessions. The 5G assists in establishing redundant user plane paths through the 5GS, including the RAN, core network, and transport network. The 5GS also allows separate redundant user planes between RAN and core network nodes and between the UE and RAN nodes.

[0050] As mentioned above, in the integrated system 100, the 5G system 106 includes one TSN (virtual) bridge per UPF. The 5G system 106 includes a TSN translator (TT) function for 5G system 106 adaptation to the TSN domain, for both user plane and control plane, hiding the 5G system 106 internal procedures from the TSN bridge network awareness. The 5G system 106 provides TSN bridge ingress and egress port operations through the TT function. For example, the TT supports keep-and-forward de-jitter functionality. Figure 1 The 5G system 106 is shown connecting end stations 102 to the bridge network 108; however, the 5G system 106 can also interconnect bridge networks 108.

[0051] To integrate the 5G system 106 into the TSN system 100, the requirements of the TSN flows are met only if resource management allocates network resources for each hop on the whole path. In accordance with the TSN configuration (802.1Qcc), this is done through the 5G system 106 and the configuration controller (e.g., the centralized configuration controller 110 (including the CUC 114 and the CNC 112) and / or a set of decentralized controller modules (as described below with respect to FIG. 4) and the 5G system 106. Figure 2The interface between the 5G system 106 and the CNC allows the CNC 112 to learn the characteristics of the 5G virtual bridge and allows the 5G system 106 to establish a connection with specific parameters based on the information received from the CNC 112. The bounded latency requires deterministic delay from 5G and QoS alignment between the TSN domain and the 5G domain. For example, if the 5G virtual bridge acts as a TSN bridge, the 5G system 106 emulates time-controlled packet transmission in accordance with, for example, Scheduled Traffic of 802.1Qbv. For the 5G control plane, the TT in the AF 124 receives transmission time information for 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 can adjust time-based packet transmission accordingly. Different TSN traffic classes can 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 domain and the 5G domain, and different 5QIs are handled according to their QoS requirements.

[0052] With respect to time synchronization, the 5G system 106 can implement gPTP for connected TSN networks. The 5G system 106 can act as a virtual gPTP time-aware system and support forwarding of gPTP time synchronization information between the end stations 102 and the bridge 108 through the 5G user plane TT. The entirety of all various 3GPP and TSN standards mentioned herein are incorporated by reference herein.

[0053] Reference is now made to Figure 2which shows a block diagram of an architecture of a system 200 according to some implementations of the disclosed technology. In general, 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 further includes physical components similar to those in the system 100 described 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 through 202-N, where each TSN block 202 is configured according to TSN specifications (e.g., in compliance with IEEE 802.1 and related standards described above), such as a TSN bridge, a TSN end device (i.e., a TSN talker and / or a TSN listener), or a combination of both. Further, rather than having a centralized configuration controller 110 to control the TSN-5G system, the disclosed technology provides a plurality of distributed configuration modules 215 in distributed controllers 210 in the TSN-5G system 200. The configuration modules 215-a through 215-f can be interconnected in one or more topologies (mesh, star, tree), and each configuration module 215 can be responsible for communicating with and configuring one or more TSN blocks 202. In some implementations, one or more of the configuration modules 215-a through 215-f can be implemented within or as part of a function of the control plane of the 5G system 106 (e.g., the SMF 126). As used herein, a “topology” can refer to one or more arrangements 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 wireless communication links) between the nodes in the network. Each link can communicatively couple a respective pair of nodes. A set of links can be sequentially coupled through their respective nodes to define a link path, e.g., between a start node and a destination node. Topologies can include, but are not limited to, one or more of a mesh, a star, a bus, a ring, and a tree topology.

[0054] 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 according to TSN configurations, including TSN schedules determined by one or more of the configuration modules 215. The data source 204 and the data destination 206 can include one or more of the I / O devices 102 and the controller 104. Although not shown, the system 200 can also include the TSN bridges 108 and other TSN components.

[0055] In some implementations, in the disaggregated structure, each of the plurality of TSN blocks 202 - 1 to 202 -N may correspond to a specific component of the 5G system, e.g. Figure 1 5G network or system 106 as shown and described above. Figure 3 As shown, the UE 118 can be configured to simulate a TSN block 202-1, the RAN 120 can be configured to simulate a TSN block 202-2, the 5G transport network link 140 between the RAN 120 and the UPF 122 can be configured to simulate a TSN block 202-3, the UPF 122 can be configured to simulate a TSN block 202-4, and the core network and / or other typical components of the 5G system (e.g., fronthaul, backhaul, or MEC modules) can be configured to simulate one or more TSN blocks 202-N. Each TSN block 202-1 to 202-N is configured according to the TSN specification (e.g., according to IEEE 802.1 and the above-mentioned related standards), for example, configured as a TSN bridge, a TSN terminal device (TSN talker and / or TSN listener), or a combination of the two.

[0056] In some implementations, such as Figure 4 As shown, each TSN block 202 includes a processor 402, a storage device 404, an internal configuration interface (ICI) 406, a transmission module 408, a reporting module 410, and TSN TT-1 412-1, TT-2 412-2, and TT-3 412-3. The processor 402 can be a microprocessor or a multi-core processor, an integrated circuit, a field programmable gate array, etc., which processes TSN configuration data and executes instructions (e.g., stored in the storage device 404) to process and transmit TSN data traffic from one or more TSN data flows according to the TSN configuration data.

[0057] The storage device 404 can store a set of parameters describing the ability to support and execute data flow (e.g., carrying URLLC data traffic) through the corresponding TSN block 202. In some implementations, the set of parameters includes, but is not limited to, identification, link quality, and link bandwidth. The identification parameter may include the device type (i.e., whether the TSN block 202 is a TSN bridge or a TSN terminal station). The delay parameter may include at least port-to-port (from the start of the TSN block to the end of the TSN block) delay and delay variation (commonly referred to as "jitter"). The link quality parameter may include at least the packet error rate. The link bandwidth parameter may include at least the available bandwidth per second.

[0058] In some implementations, the parameter set of the TSN block 202 can include a subset of parameters specific to the 5G RAN, including short transmission time intervals, TSC Assistance Information (TSCAI), Configured Grant (CG) information, Semi-Persistent Scheduling (SPS) allocations, and / or other parameters as specified in 3GPP TS 28.540. Further, in some implementations, the parameter set of the TSN block 202 can include a subset of parameters specific to TSN, including time synchronization properties, scheduled transmission (Qbv) properties, redundancy properties (including number of connected RANs, number of paths to UPF, path diversity, number of available frequencies, propagation characteristics, available radios, different physical media (e.g., free space optical communication)). As an example, Figure 5 An example parameter set 502 of an example TSN block 202 is shown.

[0059] In some implementations, the parameter set of the TSN block 202 can define a worst-case time synchronization error, a worst-case gate operation error, a maximum gate list size, a maximum cycle time, a maximum gate interval duration, a transmission start delay, similar items, or a combination thereof. The parameter set can include a discrete set of deterministic parameters that can vary depending on the type of traffic being handled by the TSN block 202. The parameter set can be used, at least in part, to generate a TSN schedule, configuration, or similar item that can be implemented on the hardware of the TSN block 202. Without such a parameter set, the TSN scheduling module must employ a least common denominator approach, where all devices of the system 200 (including the TSN block 202) are assumed to have the most restrictive characteristics, resulting in a suboptimal solution. In this sense, the parameter set enables a better scheduling solution to be implemented in the TSN system 200, resulting in improved performance metrics, including latency, jitter, packet delay variation, and bandwidth utilization.

[0060] In some implementations, the parameter set of the TSN block 202 can also describe or relate to devices created, programmed, or otherwise operated by different operators or manufacturers. In this sense, the parameter set can define a set or subset of different devices (e.g., heterogeneous, from multiple vendors) rather than homogenous or all similar devices. For example, the parameter set can include, but is not limited to, a definition of specific configuration models, error margins, hardware limitations, software limitations, and firmware options for each end node and switching node in the system 200. In this sense, the parameter set enables a heterogeneous network from multiple vendors and with different characteristics to be scheduled and configured.

[0061] In some implementations, the parameter set for a TSN block 202 can further describe particular TSN features supported by each end node and switching node in the TSN system 200. For example, the parameter set can define whether the 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 parameter set can also define a specific version or variant of a feature or standard supported by the end nodes and switching nodes in the TSN system 200. This parameter set enables scheduling and configuration of mixed capability networks where end nodes and switching nodes differ in their support of desired TSN features and versions, including no support.

[0062] Further non-limiting examples of parameter sets for TSN block 202 devices can include, but are not limited to, additional parameters used to encode the functionality of the respective TSN block 202. For example, an additional parameter set can define or enable programming of the respective TSN block 202 using a generated or scheduled TSN configuration. Non-limiting examples of parameter sets that can define or enable 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 scheduling file format, the like, or combinations thereof. In this sense, this parameter set or subset (collectively referred to as “programming parameters”) that defines or enables programming of the respective TSN block 202 using a generated or scheduled TSN configuration enables or allows the system 200 to update, install, program, configure, or otherwise revise the set of TSN blocks 202 to operate in response to or in accordance with a schedule or configuration of the TSN system 200.

[0063] Further, each TSN block 202 can include at least one ICI 406 configured to support interaction of the TSN block 202 with, for example, its respective configuration module 215. The ICI 406 can be used to provide some or all of the parameter set of the TSN block 202 to the respective configuration module 215, and to receive configuration data (e.g., transmission schedules, data flow identifications, policing rules, etc.) from the configuration module 215 to support one or more data flows through the TSN block 202. Each TSN block 202 can 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.

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

[0065] TSN talker information can be split into different frequency components that require different TSN stream latency and determinism requirements. Conversely, TSN streams from different TSN talkers can be aggregated into a single TSN stream in order to achieve greater capacity and higher channel utilization. Having discrete cycle times in the integrated TSN-5G system can help ensure ease of use of TSN stream aggregation.

[0066] In some implementations, each TSN block 202 can include a transmission module 408 configured to transmit a transmission of a particular data stream according to a schedule, deadline, latency budget, or data rate received in the configuration data from the configuration module 215 via the ICI 406. In one example where the TSN block 202-1 corresponds to a UE 118 of a 5G system, the transmission module 408 is configured to transmit the data transmission based on a resource schedule of the 5G air interface (between the UE 118 and the RAN 120). The resource schedule of the 5G air interface can be phase-aligned with the cycle time of the integrated TSN-5G system. The transmission module 408 can allocate resource elements of the 5G component corresponding to the TSN block 202 (of which 408 is a part) in order to be able to meet the scheduled transmission of each Qbv stream. For example, instead of using classic 802.1Qbv style gate control, the UE 118 corresponding to the TSN block 202-1 can use a phase offset (with respect to the cycle time) to align the transmission of the TSN data stream with the allocated schedule. In this example, the UE 118 does not obtain this phase offset from the CNC, but can obtain the phase offset as a special command from the RAN 120.

[0067] In some implementations, each TSN block 202 can also include a reporting module 410 configured to monitor the runtime behavior of the TSN block 202 and report that behavior over the ICI 406 or via a separate interface of the TSN block 202. Such behavior monitoring includes metrics including, but not limited to, packet loss and transmission loss windows.

[0068] Returning to Figure 2The disclosed technology provides multiple distributed configuration modules 215 in the distributed controller 210 in a TSN-5G system 200. The configuration modules 215-a through 215-f can be interconnected in one or more topologies (mesh, star, tree), and each configuration module (CM) 215 can be responsible for communicating with and configuring one or more TSN blocks 202. For example, CM 215-a can be responsible for and operatively and communicatively connected to TSN blocks 202-1 and 202-2. CM 215-b can be responsible for and operatively and communicatively connected to TSN block 202-3. CM 215-c can be responsible for and operatively and communicatively connected to TSN blocks 202-3 and 202-N. Thus, TSN block 202-3 can be configured and controlled by both CM 215-b and CM 215-c. For example, a portion of the functionality at TSN block 202-3 (e.g., with respect to a first type of TSN application) can be configured and controlled by CM 215-b, and another portion of the functionality at TSN block 202-3 (e.g., with respect to a second type of TSN application) can be configured and controlled by CM 215-c.

[0069] In Figure 2 In the example shown, the configuration modules 215 are arranged in a tree structure, with CM 215-f forming the highest level of the tree structure, CMs 215-a, 215-b, and 215-c forming the lowest level of the tree structure, and CMs 215-d and 215-e being between the highest and lowest levels of the tree structure. However, the configuration modules 215 are operatively and communicatively connected to each other through API 230. In some implementations, in a tree structure (e.g., as shown), the configuration modules 215 can communicate with other configuration modules 215 of adjacent tree levels (one level higher or one level lower). However, in other topologies (e.g., in a mesh or point-to-point structure), any two configuration modules 215 in the distributed controller 210 can be directly connected to each other and communicate. Figure 2

[0070] ​In some implementations, each configuration module 215 can be an external utility responsible for configuring one or more respective TSN blocks 202, or can be configured as a software module within a TSN block 202. Each configuration module 215 can be configured to determine and provide configuration data to the TSN block 202 controlled by the configuration module 215, including TSN schedules for one or more data flows to be transmitted through the TSN block 202. The configuration modules 215 can exchange information with each other using a standardized API 230. The exchanged information can include information about the cycle time of the TSN system (e.g., supported ACTs, including discrete levels of ACT buckets each corresponding to a particular data flow, maximum / minimum cycle time), configuration data including transmission schedules (including time offsets / durations / resources of transmissions) from one or more TSN blocks 202, and information for requesting resource allocations or responding to resource allocation requests. In some implementations, one or more configuration modules 215 can be configured as the CNC 112 and / or CUC 114 of the TSN controller 110 described above. In some implementations, one or more of the configuration modules 215-a through 215-f can be implemented within or as part of a function of the control plane (e.g., SMF 126) and / or an element or function of the user plane (e.g., 5G transport network 202-3) of the 5G system 106. For example, the SMF 126 can be configured to support the functionality of the CUC 114 and / or CNC 112. In some implementations, the 5G transport network 202-3 can be configured to support the functionality of the CNC 112.

[0071] In some implementations, each configuration module (CM) 215 receives some or all of the set of parameters of a TSN block 202 from the ICI 406 of the TSN block 202 controlled by the CM 215 (as described above). The CM 215 also receives information about data flows to be configured through the TSN block 202 from another entity in the system 200 through the API 230. In one non-limiting example, the data source 204 and / or data destination 206 make a request to the CM 215 for data flows between the data source 204 and the data destination 206, either directly or through an intermediary such as the CUC 114. In some implementations, the CM itself can allow a user to define a set of data flows to be configured via a user interface. As used herein, information about data flows can include or define a set of data flows, data streams, transmission paths (predetermined or otherwise adapted), etc., to define a desired TSN communication path between a data source 202 and a data destination 206. A non-limiting set of examples of information about data flows can include maximum allowed latency, data rate, data frame size (“payload”), data frame destination, bandwidth allocation gap, etc., or combinations thereof.

[0072] Based at least on the received data flow information and the parameter set of the TSN block 202, the CM 215 determines a “solution” (or configuration data), where the solution will indicate how to handle each data flow through the TSN block 202. The solution can include time-aware scheduling, policing rules, etc., as discussed in U.S. Application No. 17 / 100,356, which is incorporated by reference herein in its entirety. The CM 215 can then send the solution or configuration data to the TSN block 202 through the ICI 406. The TSN block 202 can then execute the solution and transmit data for each flow according to its configuration. In some implementations, as an example process for the distributed CM 215 to compute a solution, at each level of the tree structure of the CM 215, the same system model theory (SMT) solver can be used, where the data flows and their requirements are expressed as constraints, and a linear programming method is used to solve for a feasible solution. The solution from a lower level of the CM tree is input as used resources (again represented by constraints) at a higher level of the CM tree. This process is repeated until the top level of the CM tree is reached, at which the global solution is determined.

[0073] In some implementations, different data sources (e.g., data sources 204) and their applications operate with different cycle times or intervals. Relatedly, different data sources and destinations (and their applications) require different levels of temporal determinism for many of the data flows between them. In conventional TSN systems, a converged cycle time (often referred to as a“management cycle time”) is determined that applies to all data flows in the network. However, in some implementations of the present disclosure, an integrated TSN-5G system can use a set of discrete / quantized cycle times in the network. Each data flow selects one of the available quantized cycle times to operate with. The scheduling for scheduling transmissions in the TSN-5G system 100 can be based on the set of quantized / discrete cycle times. As one example, the integrated TSN-5G system 100 can limit the available inter-stream intervals, and thus the corresponding cycle times, to a set of discrete values, including but not limited to substantially 1, 10, 100, 1000 milliseconds. Similarly, the stream or data flow requirements can be limited, e.g., the jitter (packet delay variation) requirements can be limited to a set of predetermined discrete values, including but not limited to substantially 1, 10, 100, 1000 microseconds. In some implementations, different sets of discrete values can be used depending on the applications and use cases supported by the integrated TSN-5G system. For example, geographically dispersed systems can use discrete cycle times in the millisecond scale. In yet another example, systems limited in a local factory can use discrete cycle times in the microsecond scale. The members of this discrete set can be regularly or irregularly spaced, or follow other statistical distributions (including but not limited to logarithmic, linear, Gaussian), without defaulting to a continuous set of cycle times. In another implementation, a set of cycle times is standardized such that all TSN blocks have cycle times that are products of elements selected from a small set of common prime numbers. This ensures that all composite cycle times will be easily computed by the TSN scheduler and result in a common network cycle time.

[0074] Each TSN block in an integrated TSN-5G system can support a set of cycle times (where the set includes one or more cycle times). The CM 215 configures the TSN-5G system 106 or 200 to enable scheduled transmissions of data flow across TSN blocks 202 operating with different cycle times. In some implementations, TSN blocks 202 can need to operate with compatible cycle times, where compatibility means that the cycle times are integer harmonics of each other. When the application request interval cannot be directly mapped to the available set of discrete cycle times on the set of TSN blocks 202 that the flow traverses, the CM 215 can adapt to the closest available cycle time. The closest available cycle time will be an integer multiple or integer divisor of the available cycle times. The CM 215 can exchange the supported set of quantized / discrete cycle time information with each other during the configuration process. In this case, the present disclosure allows a disaggregated TSN-5G system to create feasible configurations for a large number of data flows / flows. Without quantized cycle / interval, the configuration typically requires a large amount of computation time and can even prevent finding a feasible solution.

[0075] In some instances, each integrated TSN-5G network slice in the 5G system 106 can have a predefined set of supported cycle times and jitter bounds. In some instances, the network slice can have a finer granularity than a typical 5G network slice according to 3GPP specification 23.501, which is incorporated by reference herein. In some implementations, the TSN-5G system 106 or 200 can slice based on TSN cycle times. For example, a 5G network supporting multiple critical services can have a URLLC slice dedicated to the periodicity of the applications and their flows. For example, a service with an application running with a period of approximately 1 millisecond can have a dedicated slice running with a cycle time of 1 millisecond. Similarly, a service and application running with a period (or interval) of 100 milliseconds can have a dedicated slice running with a cycle time of 100 milliseconds in the integrated TSN-5G system. Such cycle time slicing improves the speed of configuration as well as overall network performance. In some implementations, a TSN block 202 discloses one or more supported cycle times for a given slice through its ICI 406 to its respective CM 215. The CM 215 in turn can create a configuration solution for the TSN-5G system being sliced by exchanging the supported cycle times of the TSN blocks under their management through the mutual configuration module API 230.

[0076] In some implementations, the solution or configuration data determined by the CM 215 can include, but is not limited to, a group or set of configurations, timings, commands, controls, instructions, the like, or combinations thereof, for operating the respective TSN block 202 in accordance with the characteristics (e.g., defined by the numerology) of the TSN block 202. In some aspects, the configuration data can include specific transmission information for individual or collective (e.g., “global”) data frame transmissions of one or more respective TSN blocks 202. The transmission information can include time information for transmission of the data frame. In one or more aspects, the configuration data for the data frame can include a transmission start time. For example, the transmission start time can be a time at which the respective TSN block 202 begins transmitting the data frame. In one aspect, transmission of the data frame can be initiated by selectively opening 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, transmission of the data frame can be stopped or prevented by selectively closing the gate of the respective TSN block 202 to transmit the data frame. The configuration data can also define or assign a specific path or link communicatively coupling the respective TSN block 202 and another node for the data flow to be transmitted thereon. Additionally, the configuration data can define a transmission duration of the respective data flow from the respective TSN block 202. In one aspect, the data flow transmission duration can be defined by a time period between selective opening of the gate of the respective node (i.e., transmitting the data frame) and selective closing of the gate (i.e., stopping transmission of the data frame to the destination node).

[0077] In conventional TSN systems, TSN schedules are expressed as absolute time offsets in a periodic cycle in which the TSN block transmits data. However, this can be too rigid for a 5G system 106 composed of components from multiple vendors. In some implementations, a deadline-based schedule is determined by the CM 215 and provided configuration data. The deadline-based schedule can indicate that the TSN block 202 transmit data of a configured data flow no later than a deadline, which is expressed in absolute time in a periodic cycle. In some implementations, a delay budget-based approach would indicate that the TSN block transmit data frames of a configured data flow within a delay budget. Thus, under the delay budget-based approach, the TSN block 202 is required to send data frames that it receives at its ingress port to its egress port within a certain time. Such a scheme would not require each 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 data frames of a given data flow in a manner that the average or peak transmission rate (bits per second) does not exceed a configured value (according to the configuration data from the CM 215).

[0078] In some 5G systems, a TSN block can be a shared resource set made available by a network slice based on service profiles that define network latency, periodic cycles (including but not limited to delay / budgets). In such implementations, there can be two levels of scheduling, where in addition to slice-level TSN scheduling, the 5GS TSN-AF can enable configuration of TSN blocks 202 to share resources. In either case, configuration attributes such as resource identifiers can identify TSN blocks for proper configuration. For example, a service provider can have multiple service profiles with specific periodic cycles, and multiple tenants of the service provider can use the same TSN blocks as specified by the 5GS TSN-AF configuration and can perform TSN flow aggregation. In some implementations, a service provider can provide a set of non-shared TSN blocks, where there is only one layer of service profiles. Device-specific operational / resource sharing patterns required can be available to the CNC 112 through the TSN-AF.

[0079] As an example implementation of the deadline / delay budget approach for TSN blocks 202, when a data frame arrives at an ingress port of a TSN block 202, the TSN block 202 will note the arrival time of the data frame using its local clock. The TSN block 202 can then identify the frame as belonging to a configured data flow and can then start a countdown timer equal to the delay budget configured for that data flow. Using the transport module 408, the TSN block 202 can prioritize data with the least remaining time for transmission. If a packet’s timer expires before the packet is transmitted, the event is recorded as a transmission loss and considered in the monitoring metrics by the logging module 410.

[0080] In some implementations, with respect to scheduled transmissions between TSN block 202-1 (corresponding to UE 118) and TSN block 202-2 (corresponding to RAN 120), there can be “enhanced” allocation (assignment and transmission) of uplink and downlink transmissions between UE 118 and RAN 120 in order to meet the schedule assigned by CM 215-a to TSN block 202-1 corresponding to UE 118. In some implementations, CM 215-a can take into account UE 118 buffer status and radio conditions reported by RAN 120 when instantiating TSN schedules and can adjust or report required changes in the requested schedule. In other implementations, CM 215-a can send real-time feedback about radio conditions received from RAN 120 to a master CM, such as CM 215-d. This feedback loop can support recalculation of TSN schedules to meet packet delay budgets on a given end-to-end path for this particular TSN block or across TSN blocks.

[0081] In this implementation, link quality can be monitored and the CM 215-a can continuously adjust radio resources in the configuration data to meet the transmission schedule. Radio resources can include, but are not limited to, logical channels, transmission power, and UE-specific slot duration. In some implementations, a static allocation of uplink and downlink slots can be made for a given UE 118 that is fixed / deterministic, such that, for example, all UEs connected to a given RAN slice are given scheduled transmission slots. 5G native air scheduling can be used to determine whether a transmission from a UE 118 will meet the transmission deadline. If not, the UE 118 can request elevated access to the RAN 120 to enable a scheduled transmission. In some implementations, scheduling for a predetermined transmission in the 5G system 106 can be based on a quantized / discrete set of cycle times, where the set includes at least a 100 millisecond administrative cycle time. According to the techniques of this disclosure, a radio link between a UE (e.g., represented by TSN block 202-1) and a RAN (e.g., represented by TSN block 202-2) can be sliced based on cycle times. In some implementations, uplink and downlink between the TSN block 202-1 and the TSN block 202-2 can allocate radio resources for each network slice according to the cycle times of the slices. For example, a 1 millisecond cycle time slice would require radio resources (channels, air time, etc.) that are capable of transmitting data at a rate of 1 millisecond.

[0082] In some implementations, 5G resource elements (e.g., frequency and time slots) can be scheduled such that, in addition to the “standard” 5G scheduling traffic priority requirements, they also meet the TSN flow latency requirements. More specifically, 5G slots for TSN flows can be assigned such that they transmit messages of the TSN flows with the correct cycle time offset (phase) and within the time limit (TSN window time) required by TSN scheduling. In this case, the 5G scheduler differs from a “legacy” TSN Ethernet port in that multiple messages can exit simultaneously if transmitted on different frequencies. In some aspects, in the presence of poor RF channel conditions, the 5G system 106 can send multiple copies of a message on different frequencies in order to increase the probability of meeting the transmission schedule and / or deadline.

[0083] To enable reliable data transmission in the system 200, redundant flow paths can be implemented. The disaggregated TSN blocks 202 of the 5G system 106 allow for better handling of errors (delayed, dropped, or corrupted frames) in a better way. In some implementations, the UE 118 can initiate two redundant disaggregated PDU sessions to the UPF 122 for redundancy, in which case the 5GC can configure the NG-RAN for dual connectivity according to 3GPP 38.300. In some other implementations, FRER can be used between some TSN blocks 202 but not others. For example, redundant flows can be implemented over the air interface between the UE 118 (TSN block 202-1) and the RAN 120 (TSN block 202-2), then combined at the RAN 120, and if needed, split again over the core network (TSN blocks 202-3, 202-4). As Figure 1 illustrated, current redundancy requirements according to 3GPP 23.501 are for the maximum disjoint paths between the UE 118 and the UPF 122. However, according to the disclosed techniques, it is not necessary to establish redundant disjoint paths throughout the 5G system, but rather can be implemented for only a portion of the 5G system. For example, in the case of the air interface between the UE 118 and the RAN 120, the redundancy requirement can specify that the two paths should be on different frequencies or different MIMO channels or different time slots. In some instances, the present 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 for TSN blocks with different degrees of redundancy capability.

[0084] The concept of dividing the 5GS into multiple TSN blocks (e.g., as described above with respect to Figure 2discussed) can enhance security in cases where strict scheduling can hinder the flow of malicious traffic between the blocks. However, enabling 5GS to operate as multiple TSN blocks can introduce security vulnerabilities, mainly via configuration. Specifically, TSN users can become aware of internal 5GS details and connectivity that affect other users sharing the same physical and logical architecture. This can happen during the required TSN network discovery phase (e.g., information returned via link layer discovery protocol). TSN users can also misconfigure their own or other users’ configurations. This can be partially addressed by using the security sub-tree concept of NETCONF, where users have a limited view of their own data model sub-tree. The 5G system can inherently have the concept of isolated network slices, for example, depending on whether the TSN is implemented virtually (by software) or physically (by hardware). The architecture provider can have to limit what physical and logical functions are exposed to each TSN user. This can be done through 5G network exposure functions. The present disclosure provides a solution to the security problem by using “virtual TSN blocks.” A virtual TSN block is an internal 5G TSN block that contains only the capabilities provided by the user’s 5G network slice. In other words, the user can only see and configure TSN block information exposed via the 5G network slice, and only that information. In this sense, the internal 5G TSN block is the intersection of the information set contained by the internal TSN block and the 5G network slice provided to the user.

[0085] In some implementations, the IETF DETNET standard (as provided in IETF: “Deterministic Networking Working Group,” https: / / datatracker.ietf.org / wg / detnet / about / ) can be implemented or integrated into the 5GS to interconnect islands of TSN-compliant Ethernet. The 5GS can leverage DETNET to enable TSN messages to be transported on IP layer 3 (rather than layer 2). Envisioning such a system, the techniques discussed in the present disclosure include a 5GS that supports DETNET edge, relay, and transit nodes that interconnect spatially separated TSN networks to create a larger composite TSN over 5G. All aspects of the integrated TSN-5G system provided in the present disclosure apply to (but are not limited to) TSN islands of 5G DETNET, particularly disaggregated TSN TSN blocks.

[0086] DETNET consists of the following components: (1) TSN end system: IEEE compliant end system that communicates with the DETNET edge node; (2) DETNET edge node: processes TSN frames into DETNET; (3) DETNET relay node; and (4) DETNET transit node: provides congestion avoidance for time sensitive messages. DETNET is routed, not bridged, enabling TSN messages to be routable between TSN LANs. Basic TSN Ethernet frame information is either transmitted between LANs or reconstructed in transmission. DETNET implements its higher layer functionality by adding the following sub-layers: (1) DETNET service sub-layer: provides DETNET services (e.g., service protection) to higher layers and applications in the protocol stack; and (2) DETNET transport sub-layer: supports DETNET services in the underlying network (e.g., by providing explicit routing and congestion protection) for DETNET flows and encapsulates TSN Ethernet frames. DETNET routing incorporates IP headers that are modified according to standard router behavior (e.g., time to live (TTL handling)), where TTL specifies the maximum time a routable IP message is allowed to live, which is obviously related to the TSN maximum latency requirements.

[0087] The DETNET components can reside within any computing element of the 5GS, specifically within the 5G MEC or core. Thus, in one implementation, the 5GS can be fully compatible with DETNET, interconnecting TSN LANs. To provide determinism, DETNET can reserve data plane resources for a DETNET flow in some or all of the intermediate nodes along the path of the DETNET flow. DETNET can provide explicit routing for the DETNET flow. DETNET can distribute data from a DETNET flow packet in time and / or space to ensure that the data of each packet is delivered despite an immediate path loss. Thus, the TSN CNC / DNC and scheduler as described above can need to interact with DETNET, specifically the ability to configure flow paths (including redundant flow paths) and TTLs, and to obtain routing latency and jitter. TSN traffic shapers, time-aware shaping, and network calculus can be used to achieve the required level of determinism in the 5G DETNET.

[0088] It should also be noted that a hybrid 5GS where a portion is TSN (layer 2) and a portion is DETNET (layer 3) can coexist and interoperate. In this case, as described above, the DETNET portion of the network can itself be considered a TSN block (or multiple TSN blocks) 202.

[0089] With respect to caching within the 5GS to minimize latency and increase determinism for TSN applications, the amount, location, and naming of information in the 5GS can be managed to enable fast and short proximity access to minimize jitter. Each piece of information can be cryptographically signed to improve its security, and access provided through the cryptographic signature and information stored in 5GS components such as MECs. A cache forwarding unit will track each data request to allow optimal forwarding, placement, and provision of cached data. TSN CNC / DNC and schedulers can compute the location to place cached information within the network, specifically the 5GS, to maximize access and minimize jitter (packet latency variation) among 5G applications.

[0090] Real-time MEC applications typically have well-defined characteristic profiles of their behavior. Cloud (cloud computing) and fog (fog computing) 5G MEC applications can be divided into microservices with hard, real-time constraints that are provided to the TSN scheduler. The constraints can be a longest (worst-case) time to complete a call to a service, or a well-defined statistical description of arrival curves or service curves according to network calculus requirements. In some implementations, microservices can be linked together to create a complete MEC application. By breaking the computation into a series of smaller microservices, each service can be better controlled and managed, and more determinism can be provided. Each microservice can be abstracted as an internal TSN block consisting of deterministic inputs, outputs, schedulable operations, and cooperation with 5G-TSN AFs. Microservices can reside on the same or spatially different processing systems interconnected via TSN scheduling communications.

[0091] Such hard real-time processing can include 5G MEC and 5G core functions. Messages enter and leave the MEC TSN block according to a deterministic schedule that can be computed by a TSN scheduler. It should be noted that such TSN block will be referred to as a “computing TSN block”. Given that the messages generated by the MEC and their corresponding size and sending times can vary depending on the computational complexity of the MEC processing tasks, processing load and application state, the TSN scheduling component can leverage the internal model of the MEC processor (which is a simulation model, an analog model or a pure analytical model or a mix thereof) for TSN scheduling purposes (also referred to as digital twin). The TSN scheduling component can then generate a complete end-to-end TSN schedule for all messages flowing between the 5G UE, MEC and 5G core and any cloud processing required by the real-time application, where the 5G core and cloud processing are similarly modeled by the TSN scheduler. The TSN schedule can dynamically recalculate the required schedule to maintain the determinism required by the 5G TSN real-time MEC / cloud application in case of variations in the effective processing rate (and thus, output message sending times). The TSN scheduler can provide feedback to the application developers (and for management and deployment) regarding the optimal location of each processing component of the real-time 5G application (UE, MEC, cloud), taking into account link speeds, variations, processing capabilities, available memory, etc. The TSN system can employ gate-based methods or rate control mechanisms, such as leaky bucket, and can use any number of optimization techniques or network calculus to determine a feasible schedule. Thus, the complete flow of a TSN application includes not only the end-to-end path through the network for a particular message, but also the complete processing path through all the computing TSN blocks (microservices) that act on the information in the message. IEEE 802.1CB redundant paths can be configured through redundant or parallel computing TSN blocks (microservices). It is conceivable that in this disclosure the complete real-time processing activity is encoded in the TSN schedule, where the computing TSN blocks appear as Ethernet bridges, with the difference that they process messages or can create new messages that exit on a deterministic schedule.

[0092] MEC applications are configured to use TSN flows (as TSN talkers or listeners participating) using NETCONF, RESTCONF or RESTful APIs. The messages defined in the above protocols contain the IEEE 802.1Qcc information needed to configure the TSN flows used by the MEC applications. In addition, MEC applications are designed to move from one MEC platform to another and a RESTful API is defined to query the TSN configuration of the current platform to verify that it has the required deterministic communication requirements, specifically including latency and jitter. It also has a RESTful API containing the above information needed to inform the TSN CNC of its new location and the information needed to dynamically reschedule TSN traffic to its new location. As mentioned above, IEEE 802.1CB can be used to establish redundant TSN flows to the intended location where the MEC application can be migrated. The TSN scheduler (i.e., CNC or Distributed Network Configurator (DNC)) can be a MEC application that provides 5G TSN scheduling as a service and configuration as a service, which is useful for dynamic rescheduling that requires low latency.

[0093] The TSN application can transmit a timing performance profile query microservice request, the purpose of which is to determine statistical information about processing time. When responding to such a request, the microservice will execute the request and return both the result and the timing performance profile. The timing performance profile can contain at least the network start and end times of the microservice call and optionally the start and end times of all called sub-functions. This information can also contain the average of the MEC processor load during the timing performance profile. The TSN application can use the timing performance profile to improve TSN scheduling where the microservice is required to process TSN traffic flows. The timing performance profile information can be obtained during real-time operation, where the output from the profile is used normally, or as a special test sample before real-time operation. The timing performance profile information can be used to determine which MEC hardware to use for current and future operation and as constraint information for the TSN scheduler.

[0094] The present disclosure also provides additional new aspects, including (1) 5G core functionality for TSN scheduling; (2) ensuring that central processing units are directly time synchronized with Ethernet hardware timestamping mechanisms; (3) being able to conduct specific 5G network functions and procedures for TSN scheduling; (4) adding new time-aware programming features, such as time-based event handling; and (5) integration of time-based conditional handling, such as implementing real-time programming to implement service links through YANG configuration microservice scheduling (see http: / / www.rfc-editor.org / rfc / pdfrfc / rfc7758.txt.pdf for an example of YANG scheduling operations).

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

[0096] The present disclosure also contemplates a virtualized network function (VNF-TSN) that can reside as software within the 5G system. It can require dedicated processor hardware to support real-time operations. In some implementations, the TSN can be provided as a software-defined TSN (SDN-TSN) and 5G TSN as a service. In some implementations, the VNF-TSN can be configured in each 5G subcomponent (TSN block): UE, Radiohead, CU / DU, RAN, MEC, Core, etc. As described above, microservices can be chained together as part of TSN scheduling. Each microservice can expose its service time characterization to the TSN scheduling. The service is part of the latency, but it can have more variation than the communication link. In such an implementation, the service is the link in this integration of microservices with TSN scheduling. Network calculus can be used to combine the processing latency. The TSN input provides a clear arrival curve. The processor execution time provides a service curve (assuming the 5G device has well-characterized processing time).

[0097] In another aspect of the disclosure, a time-aware MEC platform is defined as a platform that acts as a PTP client (compliant with 802.1AS end-station) and as a PTP bridge (compliant with 802.1AS bridge) if needed. For a virtualized MEC platform running multiple slices (operating systems, virtual machines, containers) in parallel, a PTP bridge is needed in addition to the network bridging functionality. Typically, virtual bridges / switches are used in virtualized computing platforms. In this disclosure, a TSN-enabled virtual switch is defined that includes time awareness. The time-aware PTP client in the MEC platform runs the PTP state machine and the servo to synchronize the locally available clock with the master clock in the network. In addition, the MEC platform synchronizes the system clock with the PTP clock, where the system includes the operating system, network stack, application stack, or any other software and hardware elements that use the clock. This enables each MEC application to operate on a synchronized PTP time. In one example, the MEC host operates this PTP client and provides the synchronized time to all MEC applications through the virtualization architecture (e.g., as the system / host time). In another example, each MEC application can run a separate instance of the PTP client connected to the host via the time-aware bridge.

[0098] As a configuration interface, 3GPP 23.501 specifies a centralized configuration model where the CNC configures the 5GS as a time-aware bridge. Similarly, the MEC platform should be configurable as a time-aware end-station or time-aware bridge by the CNC. This MEC can support the use of the 802.1Qcw yang model to configure the TSN features, including time-aware shaping, forwarding, and frame replication and elimination for redundancy. In addition, the MEC host can have a CUC component that uses the 802.1Qcc interface to provide the CNC with the data flow requirements of the resident applications. The MEC can also provide information to the CNC about its TSN capabilities so that the CNC can accurately model the MEC. For example, the MEC can present itself as a TSN end-station that initiates a set of data flows. The CNC will model the MEC appropriately in the network and generate the correct configuration. The MEC should support the identification of data flows in collaboration with the operating system and applications. The specific functionality depends on the TSN awareness of the MEC components. TSN-unaware applications on the MEC host need IP flow identification in the MEC bridge.

[0099] TSN fronthaul / backhaul (e.g., TSN block 202) can be directly connected to MEC, providing determinism to MEC. However, MEC applications are intended to continuously migrate, or more intuitively, “float,” to the edge of the 5G network to remain closest to their potential mobile clients. Thus, MEC applications requiring determinism will dictate a minimum acceptable packet delay variation (MPDV) threshold. MPDV can be incorporated into the specification of all MEC applications, which can limit viable application locations to those MEC platforms that exist as TSN blocks within the 5GS. Applications must ensure that proper TSN stream identification and translation rules are implemented on the new MEC platform (which can be a single processor or subnetwork of processors) so that MEC talker / listener message frames are correctly labeled and processed. MEC applications can wish to carry their own configuration instructions, when possible, in order to “self-install” when they migrate to a new MEC platform. It should be noted that load balancing mechanisms can be employed to ensure that users do not overwhelm any set of MEC applications and that MEC applications are distributed in an optimal manner. In other scenarios, redundant MEC platforms and applications can be instantiated, and / or MEC applications migrate due to noise, rather than just mobility. Multiple MECs can also be connected as TSN redundant systems.

[0100] Figure 6A and Figure 6B An integrated TSN-5G system 600 (similar to system 200) is shown that includes a TSN block 605 (similar to TSN blocks 202-N) representing or corresponding to a 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, rather than being disposed at the edge of the 5G system 106. The TSN block 605 can be configured as a bridge end station.

[0101] Referring to Figure 8 , application data streams can span multiple integrated TSN-5G systems 805 and 810. In this case, TSN blocks can be geographically distributed, interconnecting more than one 5G system using TSN compatible transport 820 (including, but not limited to, a 5G backbone, a private network tunnel, or other wide area network). In this disclosure, TSN blocks are configured by their respective CM 215. In some implementations, configuration across two TSN-5G systems 805, 810 can be coordinated by the CNC 112. In some other implementations, CMs 215 between two TSN-5G systems 805, 810 can communicate directly with each other. In some implementations, multiple CUCs and CNCs can be used to capture user requirements and generate TSN solutions and techniques (e.g., TSN scheduling, forwarding instructions, etc.) provided in this disclosure.

[0102] Figure 7An electronic system 700 is shown that can implement one or more implementations of the present disclosure. The electronic system 700 can be part of the TSN block 202 and / or the configuration module 215. The electronic system 700 can include 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(s)), 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 a subset or variation thereof.

[0103] The bus 708 generally represents a communication path between the various subsystems and components 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 present disclosure. In different implementations, the one or more processing unit(s) 712 can be single-processor or multi-core processors.

[0104] 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, can be a read-and-write memory device. The permanent storage device 702 can be a non-volatile memory unit that stores instructions and data even when the electronic system 700 is off. In one or more embodiments, a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) can be used as the permanent storage device 702.

[0105] In one or more embodiments, a removable storage device (such as a floppy disk, flash drive, and its corresponding disk drive) can be used as the permanent storage device 702. Like the permanent storage device 702, the system memory 704 can be a read-and-write memory device. However, unlike the permanent storage device 702, the system memory 704 can be a volatile read-and-write memory, such as a random access memory. The system memory 704 can store any instructions and data that one or more processing unit(s) 712 can need at runtime. In one or more embodiments, the processes of the present disclosure are stored in the system memory 704, the permanent storage device 702, and / or the ROM 710 (which are each 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.

[0106] Bus 708 also connects to input and output devices interfaces 714 and 706. Input devices interface 714 enables the user to communicate information and select commands to electronic system 700. Input devices that can be used with input devices interface 714 include, for example, alphanumeric keyboards and pointing devices (also called “cursor control devices”). Output devices interface 706 can enable, for example, a display of images generated by electronic system 700. Output devices that can be used with output devices interface 706 include, for example, printers and display devices, such as liquid crystal displays (LCDs), light emitting diode (LED) displays, organic light emitting diode (OLED) displays, flexible displays, flat panel displays, solid-state displays, projectors, or any other device for outputting information. One or more implementations can 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 user input can be received in any form, including acoustic, speech, or tactile input.

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

[0108] The 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 include mobile devices and be 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 can be implemented using quantum computing, pulse coupled oscillation (PCO) / Ising computing.

[0109] Some implementations include electronic components, such as microprocessors, storage and memory that store computer readable instructions (also referred to as computer-readable storage media, machine-readable media, or machine-readable storage media) in a machine readable or computer- readable format, such as firmware, read only memory, magnetic tape, or hard disk. Some examples of such computer-readable media include RAM, ROM, read only compact discs, recordable compact discs, erasable compact discs, read-only digital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), a variety of recordable / rewritable DVD (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD card, mini-SD card, micro-SD card, etc.), magnetic and / or solid state hard drives, read-only and recordable Blu-ray

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

[0111] As used in the specification and any claims of this disclosure, the terms “computer”, “server”, “processor”, and “memory” all refer to electronic or other technological devices. These terms do not encompass humans or groups of humans. For the purposes of this specification, the term “display” means to display on an electronic device. As used in the specification and any claims of this disclosure, the term “computer-readable medium” is limited to tangible, physical objects that store information in a computer-readable format. These terms exclude any wireless signals, wired download signals, and any other transitory signals.

[0112] 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 cathode ray tube (CRT) or liquid crystal display (LCD) 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; for example, 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; for example, by sending web pages to a web browser on a user's client device in response to requests received from the web browser, a computer can display and interact with a user. 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 and a wide area network, an inter-network (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0113] 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 and a wide area network, an inter-network (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0114] According to aspects of the present disclosure, a wireless network (e.g., 5G network 106) is provided that is configured to support time-sensitive deterministic communication based on a TSN mechanism. The wireless network can include a plurality of discrete CN components, such as the components 110, 118, 120, 122, 124, 126, 140, 190, etc. discussed above. Each CN component can be configured to provide a discrete function for data communication across the wireless network (e.g., 106) from a source device (e.g., 102) to a destination device (e.g., 104). A processor (e.g., 402) can be arranged to configure at least one of the plurality of CN components (e.g., 140) with a TSN parameter set of a 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 according to the TSN parameter set. The at least one of the plurality of CN components configured with the TSN parameter set 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 TSN parameter set 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 according to the respective TSN parameter set.

[0115] The wireless network can also include a configuration module (e.g., 110 or 210) configured to determine a TSN parameter set for at least one of the plurality of CN components. The TSN parameter set can include one or more of a TSN stream identification, a transmission schedule, a deadline or latency budget, a filtering configuration, and a redundancy scheme. In some implementations, the processor is configured to allocate one or more CN resources for data transmission by the at least one of the plurality of CN components according to the transmission schedule or the deadline or latency budget. In some implementations, the configuration module is configured within a control plane component (e.g., SMF 126) of the plurality of CN components.

[0116] In some implementations, the configuration module is configured to determine the TSN parameter set based on one or more CN attributes allocated to the at least one of the plurality of CN components, wherein the one or more CN attributes are related to the discrete function provided by the at least one of the plurality of CN components.

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

[0118] According to aspects of the present disclosure, a wireless network (e.g., 5G network 106) configured to support time sensitive deterministic communications based on TSN mechanisms is provided. The wireless network can include a plurality of discrete CN components, such as components 110, 118, 120, 122, 124, 126, 140, 190, etc. discussed above. Each CN component can be configured to provide discrete functionality for data communications 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 can include a plurality of configuration modules (e.g., 210, 215) interconnected in some arrangement (e.g., via 230) and configured to provide each of the plurality of CN components with a unique set of TSN parameters such that each of the plurality of CN components supports time sensitive deterministic communications as a corresponding TSN block in a TSN network according to the respective unique set of TSN parameters. The plurality of configuration modules can be interconnected in a hierarchical arrangement, a mesh arrangement, a star arrangement, a tree arrangement, or a combination thereof.

[0119] As shown and discussed above with respect to Figure 2 A corresponding TSN block (e.g., 202-3) can be configured to receive its unique set of TSN parameters 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 can include one or more of a TSN stream identification, a transmission schedule, a deadline or latency budget, a filtering configuration, and a redundancy scheme.

[0120] In some implementations, at least one of the plurality of configuration modules is configured as the CUC 114 and / or the CNC 112, and is implemented within the SMF 126 of the control plane and / or within the TSN block 202-3, which represents TSN configuration of the 5G transport channel 140. In implementations of configuring the 5G transport channel 140 with TSN parameters in accordance with various aspects of the disclosure, both the RAN 120 and the UPF 122 can be configured to support the functionality of TSN talkers and / or listeners as defined in IEEE P802.1Qdj[xx]. The SMF 126 / CUC 114 can be responsible for converting from / to parameters in IEEE P802.1Qdj[xx] to / from 5GS parameters. The SMF 126 / CUC 114 can be configured to communicate with the TSN talkers and / or listeners in the RAN 120 and the UPF 122 to exchange data sets defined in IEEE P802.1Qdj[xx]. In some implementations, during QoS flow establishment or modification, the SMF 126 / CUC 114 creates talker groups and listener groups for each QoS flow as defined in Appendix I.x and sends them to the TSN CNC 112. The TSN CNC 112 uses the talker groups and listener groups as input to select one or more paths and compute a schedule in TSN. The TSN CNC 112 provides a state group to the SMF 126 / CUC 114. The SMF 126 / CUC 114 provides the state group to the TSN talkers and / or listeners in the RAN 120 and the UPF 122, respectively. After receiving the state group, the TSN talkers and / or listeners send data to the N3 interface according to the configuration in the state group.

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

[0122] According to aspects of the disclosure, a system (e.g., as Figure 8The illustrated and described system 100). The system includes a first wireless network (e.g., 805) and a second wireless network (e.g., 810). The first wireless network can include a first plurality of discrete CN components each configured to provide a discrete function 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 according to a first TSN parameter set. The second wireless network can include a second plurality of discrete CN components each configured to provide a discrete function 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 according to a second TSN parameter set.

[0123] In some implementations, a TSN transport channel (e.g., 820) is provided that is configured to facilitate time sensitive deterministic communication of data exchanged between the first wireless network and the second wireless network according to a third TSN parameter set. The TSN transport channel can 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.

[0124] According to aspects of the present 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 TSN parameter set of a 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 according to the TSN parameter set. The at least one of the plurality of CN components can be a 5G transport network channel connecting a RAN and a UPF.

[0125] The method can further include determining the TSN parameter set for the at least one of the plurality of CN components, e.g., at one or more configuration modules. The TSN parameter set can include one or more of a TSN stream identification, a transmission schedule, a deadline or latency budget, a filtering configuration, and a redundancy scheme. The method can further include allocating one or more CN resources for data transmission by the at least one of the plurality of CN components according to the transmission schedule or the deadline or latency budget. The method can further include monitoring data transmission by the at least one of the plurality of CN components and reporting any changes in the TSN parameter set or one or more CN properties to the configuration modules, wherein the TSN parameter set is updated based on the reported changes.

[0126] As described above, the integrated TSN-5G system can provide an API for providing configuration data for each individual TSN flow in the TSN network according to the TSN specification (e.g., IEEE 802.1Q). In some implementations, the integrated TSN-5G system can employ one or more TSN features (e.g., time-aware scheduling (TAS), per-flow filtering and policing (PSFP), cyclic queuing and forwarding (CQF), etc.) required for each individual TSN flow according to the TSN specification (IEEE 802.1Q, IEEE 802.1Qbv, IEEE 802.1Qci, etc.). However, the configuration data shared from one configuration module to another configuration module does not include or provide configuration of such TSN features as parameters required for each individual TSN flow. Rather, such TSN features such as TAS, policing, cyclic queuing, etc. are determined by the network configuration module based on user input.

[0127] To address the above issues in the integrated TSN communication network system, the techniques of the present disclosure provide a new improved interface or enhanced API, for example, between a first configuration module (e.g., CUC) associated with an end station or user device and a second configuration module (e.g., CNC) associated with a network device such as a network bridge. The new improved interface or enhanced API between the CUC and the CNC allows for a detailed, verbose description of requirements for each flow. In some embodiments, the requirements can include explicit requirements for scheduling the flow in the network using a time-aware shaper or similar shaper, explicit requirements regarding latency, jitter, and loss, and explicit requirements for filtering and policing the flow in the communication network. Thus, the new improved interface or enhanced API can provide an explicit and fine-grained definition of the flow requirements between the CUC and the CNC. The new interface is configured to share TSN configuration parameters, features, and / or requirements between the first configuration module and the second configuration module in order to implement TAS, policing, cyclic queuing, etc. for each individual TSN flow communicated via the communication network. Thus, the configuration parameters or features for TAS, policing, cyclic queuing, etc. can be additional parameters or features to the regular parameters shared between regular TSN configuration modules (e.g., CUC and CNC). In some embodiments, such additional configuration parameters can be used by the configuration module (e.g., CNC) receiving these parameters to determine whether to implement time-aware shaping or scheduling for a particular TSN flow on the communication network, whether to implement policing, etc., and to configure the TSN network device (e.g., bridge) accordingly for processing the particular TSN flow. In some embodiments, the additional configuration parameters related to the TAS, policing, and cyclic queuing features can be Boolean parameters.

[0128] As mentioned above, the CUC in a respective network domain communicates with one or more CNCs in the same network domain via a new interface or enhanced API. This communication is limited between the CUC and CNCs of the same network domain even in the case where a subset of the configuration data needs to be shared with other network domains to support the TSN features or requirements of each TSN flow. Therefore, to support the data flow / stream between multiple domains (network domains) that interoperate in a standard manner, another interface or API is necessarily required for sharing the configuration data (including per-flow requirements) between the configuration modules (CNCs) in multiple network domains. In some implementations, a network domain refers to a service provider or network owner that can have a specific periodic cycle and different TSN configuration features to provide different services. However, the configuration modules (e.g., CUCs and / or CNCs) associated with multiple network domains need to communicate with each other to support time-sensitive deterministic communication for TSN flows that flow through multiple network domains.

[0129] To address the above-mentioned problems, the present disclosure provides another new interface or enhanced API between a first configuration module (CNC) associated with a first network domain and a second configuration module (CNC) associated with a second network domain. The new interface or enhanced API between the two CNCs enables configuration of a TSN network that includes multiple network domains. In some embodiments, the new interface or enhanced API provides the following two functions. First, the new interface or enhanced API enables the communication of flow requirements from a CUC in the first network domain to a CNC in the second network domain via the CNC of the first network domain. This is necessary because the CUC can only communicate (flow requirements) to the CNC of the same network domain. Some subset of those requirements need to be communicated to the remaining CNCs in the other network domains. The new interface or enhanced API allows the configuration modules (CNCs) to coordinate the configuration to meet the flow requirements. For example, if there is a latency budget, and each configuration module (CNC) uses some of the budget when scheduling each TSN flow through its domain, they need to share this information via the new interface or enhanced API. These two functions can be combined and enable configuration of the entire communication network that includes multiple network domains to meet the requirements of each flow. Therefore, the new interface or enhanced API is configured to share TSN configuration parameters, features, and requirements between the first and second configuration modules (CNCs) for each individual TSN flow that flows / propagates / transitions between different network domains. This TSN configuration information can include configuration parameters or features required to implement the TAS, policing, cyclic queuing, forwarding, shaping, metering, filtering of each TSN flow.

[0130] Figure 9A non-limiting example of a typical TSN communication network system is shown. The TSN communication network system 900 depicts a block diagram of an example implementation of an integrated TSN-5G system similar to system 200, and also includes similar 5G components as in system 200 as discussed above. Reference is made to Figure 2 at least one 5G component is configured to emulate as one TSN block according to TSN specification (e.g., IEEE 802.1Qcc), such as a TSN bridge (e.g., bridge in Figure 9

[0131] The TSN communication network system 900 can provide a configuration controller 910 (e.g., centralized configuration controller 110, distributed controller 210) to control the TSN-communication network system 900. The configuration controller includes a CUC (e.g., CUC 114) and a CNC (e.g., CNC 112) that operate according to TSN specification (e.g., IEEE 802.1Qcc). The CUC and CNC can exchange configuration data (or configuration information) through a standardized API (e.g., User Network Interface (UNI)). The talker / listener located in the TSN end station represents the user side of the API, while the TSN bridge represents the network side of the API. The configuration data can include user configuration data and network configuration data specified in IEEE 802.1Qcc. The user configuration data can include configuration data from the user side to the network, and the network configuration data can include configuration data from the network for the user side. Thus, the CUC is configured to communicate with the talker and / or listener, create talker groups and listener groups for each QoS flow, and send the talker groups and / or listener groups as user configuration data to the CNC via a standardized API (e.g., User Network Interface (UNI)). The CNC provides the status groups as network configuration data to the CUC, and the CUC provides the status groups to the talker and / or listener.

[0132] ​The speaker group specifies the speaker's behavior with respect to the flow, the speaker's requirements from the network, and the TSN capabilities of the speaker's interface. The listener group specifies the listener's requirements from the network and the TSN capabilities of the listener's interface. The state group provides the state of the configuration of the flow from the network to each user (speaker or listener). The speaker group may include, but is not limited to, the following groups: flow ID, end station interface, user to network requirements, interface capabilities, flow class, data frame specifications, and traffic specifications, as specified in IEEE 802.1Qcc. The listener group includes, but is not limited to, the following groups: flow ID elements, end station interface, user to network requirements, and interface capabilities, as specified in IEEE 802.1Qcc. The state group includes, but is not limited to, the following groups: state information, accumulated delay, interface configuration, and fault interface, as specified in IEEE 802.1Qcc. In some implementations, additional elements describing flow requirements (including TSN features such as time-aware shaping, filtering and policing, policy-based forwarding, frame duplication and elimination for redundancy, and other features) can be shared between CUCs and CNCs via an API. In some implementations, additional elements providing a fine-grained set of per-flow requirements (including requested delivery mode, latency budget, jitter tolerance, and loss tolerance) can be shared between CUCs and CNCs via an API.

[0133] In some implementations, the configuration controller includes multiple distributed configuration modules (e.g., multiple distributed configuration modules 215), as described above. In some implementations, one or more configuration modules can be configured as a CNC and / or CUC as described above. The configuration modules can exchange information with each other using a standardized API (e.g., Inter-ConfigModule API 230). The exchanged information can include, but is not limited to, configuration data. Thus, the configuration is transferred between at least two configuration modules via the standardized API. The configuration module then provides the configuration data to at least one TSN block to support TSN features for each TSN flow passing through the at least one TSN block.

[0134] In some implementations, the configuration module can be configured as a module within the TSN block (e.g., at least one internal configuration interface (ICI) 406) to support interaction between the TSN block and one or more other configuration modules. The configuration module within the TSN block is provided to receive configuration data from one or more other configuration modules. In some implementations, the configuration module within the TSN block can provide configuration data to other configuration modules configured as modules within other TSN blocks.

[0135] Figure 10Non-limiting examples of configuration data are shown in accordance with one or more implementations. As described above, configuration data can be passed between a first configuration module (CM-10) and a second configuration module (CM-20) of a plurality of configuration modules 215-x. Configuration data includes user configuration data (such as stream requirements) and network configuration data (such as stream / ES (elementary stream) configuration). The first and second configuration modules 215-x can be configured as a CNC and / or a CUC. Thus, CM-10 and CM-20 exchange configuration data via a standardized API 230 (e.g., UNI). For example, CM-10 (e.g., CUC in Figure 10 ) sends stream requirements to CM-20 (e.g., CNC in Figure 10 ), which configures TSN blocks 202-x in network domain 1 based on the stream requirements. In some embodiments, at least one TSN block 202-x includes one or more TSN switches. CM-20 sends stream / ES configuration to CM-10. Stream requirements include, but are not limited to, listener groups and talker groups in accordance with TSN specifications (e.g., IEEE 802.1Qcc). Stream / ES (elementary stream) configuration includes, but is not limited to, status groups in accordance with TSN specifications (e.g., IEEE 802.1Qcc). In some embodiments, configuration data passed from CM-10 to CM-20 via the API includes traffic specification elements and traffic specification time-aware elements as described in clause 46.2.3.5 of IEEE 802.1Q. Traffic specification elements can also include a TimeAwareScheduling parameter provided in a Boolean format. In some embodiments, configuration data passed from CM-10 to CM-20 via the API also includes a UserToNetworkRequirements element as described in clause 46.2.3.6 of IEEE 802.1Q.

[0136] A TSN communication network system (e.g., TSN communication network system 900) can employ TSN features such as Time-Aware Scheduling (TAS) in accordance with TSN specifications (e.g., IEEE 802.1Qbv). A TSN-5G system further employs TSN features such as Per-Stream Filtering and Policing (PSFP) in accordance with TSN specifications (e.g., IEEE 802.1Qci) and Cyclic Queuing and Forwarding (CQF) in accordance with TSN specifications (e.g., IEEE 802.1Q). These TSN features can be required for each TSN stream in a communication network, as required. As described above, a TSN communication network system can use configuration data to deliver configuration for each individual stream in a TSN network. Configuration data shared from a first configuration module to a second configuration module also includes configuration parameters for providing at least one of the TSN features required for each TSN stream.

[0137] In some implementations, the configuration of each individual stream includes a configuration of TSN features required for each individual TSN stream, such that the CM-20 decides whether to configure one or more TSN blocks to support the TSN features required for each individual TSN stream based on the configuration data. In some implementations, the configuration parameters of the required TSN features are implemented in a Boolean format, but are not limited thereto. In some implementations, if a configuration parameter in Boolean format (e.g., TimeAwareScheduling parameter) is specified in the API and has a value of “True”, the CM-20 will schedule it with TAS from source to destination throughout the network. For example, the configuration data can include information related to TAS (e.g., TimeAwareScheduling) in Figure 9 some implementations, the configuration data can include information related to PSFP as additional configuration data, which indicates whether to police each individual TSN stream in the communication network with PSFP. In some implementations, the configuration data can include information related to CQF as additional configuration data, which indicates whether to apply CQF to each individual TSN stream. Since the configuration data is shared between the two configuration modules, the shared configuration data allows the corresponding configuration module to decide and configure the corresponding TSN blocks to support the required TSN features based on the shared configuration data, even if one of the configuration modules does not configure the CUC.

[0138] In some implementations, the TSN communication network system can include a configuration element (or configuration element module) (not shown in Figure 10 ), which provides configuration information including configuration up to each individual TSN stream. In some implementations, the configuration includes one or more requirements (e.g., TAS, PSFP, CQF, etc.). The configuration element is an entity independent of the configuration modules in the TSN network. The configuration element is configured to determine the configuration information and provide the configuration information to the corresponding configuration module (e.g., CNC).

[0139] Figure 11 A block diagram of an example integrated TSN communication network system architecture is shown in accordance with one or more implementations. The TSN communication network system 1100 depicts a block diagram of an example implementation of an integrated TSN communication network system similar to the system 200, TSN communication network system 900 described above. Reference is made to Figure 2, the TSN communication network system 1100 may include a plurality of configuration modules (CM) 215-x. The plurality of CMs 215-x include CM-100, CM-200, CM-300, CM-400, and CM-500. In some implementations, CM-100 and CM-300 are configured as CUCs, and CM-200, CM-400, and CM-500 are configured as CNCs. Figure 11 In FIG, dashed line 1120 represents data communication from a source device (eg, a speaker) to a destination device (eg, a listener) across a communication network. Figure 11 , line 1130 connecting network domain 1, network domain 2, and network domain 3 represents the communication network through which each individual TSN flow flows.

[0140] In some implementations, the communication network comprises a wireless network configured according to standards defined by 3GPP. CM-100 is configured to communicate with speakers in a data source 204 and create configuration data (e.g., speaker groups). The configuration data is passed to CM-200 via API 230-1, causing CM-200 to configure network domain 1. Network domain 1 comprises a series of TSN blocks or a disaggregated structure comprising multiple TSN blocks 202-1 through 202-N, which are configured by communication network (CN) components in the communication network. As described above, at least one of the multiple configuration modules (e.g., CM-100) can send configuration data including a configuration for each individual TSN flow communicated by the communication network. The configuration for each individual TSN flow includes one or more TSN features (e.g., TAS, PSFP, CQF, etc.) required for each individual TSN frame in the communication network to another configuration module (e.g., CM-200, CM-500) via an API (e.g., API 230-1, API 230-2).

[0141] Therefore, the configuration data shared from CM-100 to CM-200 may include additional configuration data for providing one or more TSN features required for each individual TSN frame. In some implementations, the one or more required TSN features include at least one of time-aware scheduling (TAS), per-stream filtering and policing (PSFP), and round-robin queuing and forwarding (CQF). The configuration data includes information indicating whether TAS is used to schedule traffic on the communication network, information indicating whether PSFP is used to police each individual TSN flow in the communication network, and / or information indicating whether CQF is applied to each individual TSN flow. Based on the configuration data, CM-200 determines whether the required TSN features are applied to each individual TSN flow and configures the TSN blocks to implement the required TSN features.

[0142] CM-300 is configured to communicate with listeners in data destination 206 and create configuration data (e.g., listener groups). The configuration data is passed to CM-400 via API 230-3, such that CM-400 configures network domain 3. Network domain 3 includes a series of TSN blocks or a de-aggregated structure including multiple TSN blocks 202-1 to 202-N, which are configured by CN components in the wireless network.

[0143] CM-200 and CM-400 can send configuration data to CM-500 via API 230-2, respectively. CM-500 configures network domain 2 based on the received configuration data. Network domain 2 includes a series of TSN blocks or a de-aggregated structure including multiple TSN blocks 202-1 to 202-N, which are configured by CN components in the wireless network. The configuration data shared from CM-200 to CM-500 can include additional configuration data for providing required TSN features, which CM-500 decides whether to apply the required TSN features and configure TSN blocks based on the shared configuration data. As mentioned above, CM-500 can send the configuration data received from CM-200 to CM-400, such that CM-400 decides whether to apply the required TSN features and configure network domain 3. In addition, CM-500 can send additional configuration data originated from CM-500 to CM-400. For example, when computing flow schedules, each domain can exhaust a portion of the latency budget. Therefore, CM-500 needs to inform CM-400 how much of the latency budget has been consumed. In addition, CM-500 can send the configuration data received from CM-400 to CM-200. In some implementations, the API (e.g., API 230-2) for communicating between configuration modules (e.g., CM-200, CM-400, and CM-500) can be, but is not limited to, a direct interface associated with each configuration module, or an interface provided via a third entity (e.g., a central office or a core network).

[0144] In some implementations, the TSN communication network system 1100 can include a configuration element 1110 (network policy configuration element) that provides configuration element information including configuration of each individual TSN flow communicated by the communication network. The configuration includes one or more TSN features (e.g., TAS, CQF, etc.) to at least one configuration module (e.g., CM-300, CM-500) of the plurality of CMs 215-x. For example, the configuration element 1110 can provide configuration information to all CMs or selectively provide configuration element information to at least one CM that does not have a CUC configured. As an example implementation, certain TSN features (e.g., TAS, CQF) can be provided by a configuration module and other TSN features (e.g., PSFP) can be provided by the configuration element 1110. The configuration element 1110 can provide policy rules that direct / instruct the CMs 215-x (e.g., CM-200, CM-400, CM-500) to select the correct TSN features. For example, the configuration element 1110 can dictate that PSFP should be applied to all flows shaped with credit-based shapers at the data source.

[0145] Figure 12A block diagram illustrating an example integrated TSN communication network system architecture is shown in accordance with one or more implementations. The TSN communication network system 1200 is an example implementation of an integrated TSN communication network system similar to the system 200, the TSN communication network system 900, and the TSN communication network system 1100 discussed above. The integrated TSN communication network system 1200 includes a network policy module 1210 as an example implementation of the configuration element 1110 discussed above. The network policy module 1210 provides configuration element information to the configuration modules 215-x respectively configuring the network domains (e.g., the first network domain 1, the second network domain 2) including the configuration of each individual TSN stream communicated by the communication network. The network policy module 1210 can also provide policy rules that guide / instruct the CMs 215-x (e.g., CM-500, CM-600, CM-700, and CM-800, etc.) to select the correct TSN features. For example, the configuration element 1110 can dictate that a PSFP should be applied to all streams shaped with a credit-based shaper at the data source. The CM-500 configured as a CUC can receive the configuration information from the network policy module 1210, and then the CM-500 can send the configuration information to the CM-600 through the standardized API 230-4 to support one or more data streams from a talker system in the data source 204 through the TSN block 202-x to a listener system in the data destination 206 in the first network domain 1. In the same / similar manner, the CM-700 can receive the configuration information from the network policy module 1210, and can send the configuration information to the CM-800 through the standardized API 230-5 to support one or more data streams from a talker system in the data source 204 through the TSN block 202-x to a listener system in the data destination 206 in the second network domain 2. In some embodiments, the CM-600 associated with the first network domain 1 and the CM-800 associated with the second network domain 2 can exchange / share configuration data through the standardized API 230-6 to support data flow / streams between multiple domains. As described above, the API 230-6 is provided to share configuration information including configuration parameters (TSN configuration parameters), features, and requirements of each individual TSN stream flowing / transiting between the first network domain 1 and the second network domain 2. Based on the configuration information shared via the API 230-6, the CM-600 and the CM-800 coordinate the configuration of each of the first network domain and the second network domain to meet the requirements of each individual TSN stream. Configuration parameters or features are provided for implementing the TAS, policing, round-robin, forwarding, shaping, metering, filtering of each TSN stream as described above.

[0146] The techniques described herein provide a method of configuring a first network domain (e.g., the first network domain 1) in a communication network (e.g., the communication network 100) in accordance with one or more implementations. Figure 11 and Figure 12configuration modules (e.g., CM-200, CM-400, CM-500) associated with network domain 1, network domain 2, network domain 3 in FIG. 1, Figure 11 configuration modules (e.g., CM-200, CM-400, CM-500) associated with network domain 1, network domain 2, network domain 3 in FIG. 1, Figure 12 configuration modules (e.g., CM-200, CM-400, CM-500) associated with network domain 1, network domain 2, network domain 3 in FIG. 1, Figure 11 configuration modules (e.g., CM-200, CM-400, CM-500) associated with network domain 1, network domain 2, network domain 3 in FIG. 1, Figure 12 configuration modules (e.g., CM-200, CM-400, CM-500) associated with network domain 1, network domain 2, network domain 3 in FIG. 1, Figure 10 configuration modules (e.g., CM-200, CM-400, CM-500) associated with network domain 1, network domain 2, network domain 3 in FIG. 1, Figure 11 configuration modules (e.g., CM-200, CM-400, CM-500) associated with network domain 1, network domain 2, network domain 3 in FIG. 1, Figure 12 configuration modules (e.g., CM-200, CM-400, CM-500) associated with network domain 1, network domain 2, network domain 3 in FIG. 1, Figure 2 configuration modules (e.g., CM-200, CM-400, CM-500) associated with network domain 1, network domain 2, network domain 3 in FIG. 1,The plurality of distributed configuration modules 215 in the distributed controller 210 under discussion, but are not limited thereto. In some implementations, the interface is configured as a direct interface associated with the configuration module or is configured as an interface provided by a third party. In some implementations, each network domain in the communication network refers to a service provider or network owner that provides different services with different TSN parameters.

[0147] In one aspect, some implementations include a communication network (e.g., a communication network of the integrated TSN communication network system 200, 1100, 1200) that supports time sensitive deterministic communication based on time sensitive network (TSN) mechanisms, the communication network including a first configuration module (e.g., CM-200, CM-400, CM-500 in Figure 11 and Figure 12 network domain 1, network domain 2, network domain 3 in Figure 11 CM-200, CM-400, CM-500 in Figure 12 CM-600, CM-800 in associated with a second network domain (e.g., network domain 1, network domain 2, network domain 3 in Figure 11 and Figure 12 network domain 1, network domain 2, network domain 3 in Figure 11 CM-200, CM-400, CM-500 in Figure 12 CM-600, CM-800 in and a second configuration module. The interface is used to send configuration data from the first configuration module to the second configuration module, such that the second configuration module configures one or more of a plurality of communication network (CN) components in the communication network as one or more TSN blocks based on the configuration data. The configuration data includes parameters required for each TSN stream to support time sensitive deterministic communication of the respective TSN stream according to the configuration data. In some implementations, the configuration data represents one or more TSN features required for each individual TSN stream, the one or more TSN features including at least one of time aware scheduling (TAS) according to a TSN specification (e.g., IEEE 802.1Qbv), per stream filtering and policing (PSFP) according to a TSN specification (e.g., IEEE 802.1Qci), and cyclic queuing and forwarding (CQF) according to a TSN specification (e.g., IEEE 802.1Q), as described with respect to Figure 10 , Figure 11 and Figure 12discussed. In some implementations, the configuration data includes information representing whether to schedule traffic on the communication network with TAS. In some implementations, the configuration data includes information representing whether to police each individual TSN flow in the communication network with PSFP. In some implementations, the configuration data includes information representing whether to apply CQF to each individual TSN flow. Each individual TSN flow flows through a first network domain and a second network domain in the communication network (e.g., line 1130 connecting network domain 1, network domain 2, and network domain 3). The communication network can include a configuration element module (e.g., configuration element 1110, network policy module 1210) configured to provide at least one of the first configuration module and the second configuration module with configuration elements included in one or more TSN features required for each individual TSN flow, the one or more TSN features including at least one of time-aware scheduling (TAS), per-flow filtering and policing (PSFP), and cyclic queuing and forwarding (CQF). In some implementations, the communication network includes a wireless network configured according to standards defined by 3GPP. In some implementations, at least one configuration module is configured to de-aggregate a structure (e.g., as discussed with respect to Figure 2 the plurality of distributed configuration modules 215 in the distributed controller 210 discussed, but is not limited thereto. In some implementations, the interface is configured as a direct interface associated with the configuration module or is configured as an interface provided by a third party. In some implementations, each network domain in the communication network refers to a service provider or a network owner providing different services with different TSN parameters.

[0148] In another aspect, a configuration module associated with a communication network supporting time sensitive deterministic communication based on time sensitive network (TSN) mechanisms is provided. The configuration module can include a first configuration module (e.g., CM-10 in Figure 10 CM-100, CM-300 in Figure 11 CM-500, CM-700 in Figure 12 associated with a source device or a destination device and configured to provide configuration data for each individual TSN flow communicated via at least some of a plurality of communication network (CN) components in the communication network; and a second configuration module (e.g., CM-20, CM-200, CM-400, CM-500 in Figure 11 CM-20, CM-200, CM-400, CM-500 in Figure 12CM-600 and CM-700 in FIG. 6). In some implementations, the first configuration module is further configured to communicate with the second configuration module via an API (e.g., API 230, API 230-1, API 203-3, API 230-4, API 230-5) such that the second configuration module configures one or more of the plurality of CN components as one or more TSN blocks based on the configuration data. The configuration data represents one or more TSN features required for each individual TSN stream. The one or more TSN features include at least one of time-aware scheduling (TAS) according to a TSN specification (e.g., IEEE 802.1Qbv), per-stream filtering and policing (PSFP) according to a TSN specification (e.g., IEEE 802.1Qci), and cyclic queuing and forwarding (CQF) according to a TSN specification (e.g., IEEE 802.1Q) as discussed with respect to Figure 10 , Figure 11 and Figure 12 . The configuration data further includes a time-aware scheduling (TAS) parameter representing whether to use TAS to schedule each individual TSN stream and information representing whether to apply cyclic queuing and forwarding (CQF) to each individual TSN stream. In some implementations, the communication network includes one or more network domains through which each individual TSN stream flows according to the configuration data. The first configuration module and the second configuration module are associated with a same network domain of the one or more network domains (e.g., network domain 1, network domain 2, network domain 3 in Figure 11 and Figure 12 . The second configuration module is further configured to share the configuration data with a plurality of configuration modules (e.g., CM-200, CM-400, CM-500 in Figure 11 , Figure 12 CM-600 and CM-700 in FIG. 6) associated with different network domains of the one or more network domains. As discussed with respect to Figure 11 and Figure 12 , the second configuration module is configured to share the configuration data via an interface (e.g., API 230-2, API 230-6). In some implementations, the interface is configured as a direct interface associated with the configuration modules or is configured as an interface provided by a third entity. In some implementations, the TAS parameter is in a Boolean format. The configuration data further includes information representing whether to use per-stream filtering and policing (PSFP) to police each individual TSN stream in the communication network. In some implementations, the second configuration module is further configured to receive the information representing whether to use per-stream filtering and policing (PSFP) to police each individual TSN stream in the communication network from a configuration element module (e.g., configuration element 1110, network policy module 1210) in the communication network. In some implementations, the configuration module is configured to de-aggregate a structure (e.g., as discussed with respect to Figure 2The plurality of distributed configuration modules 215) in the distributed controller 210 under discussion, but are not limited thereto. In some implementations, each network domain in the communication network refers to a service provider or network owner that provides different services with different TSN parameters.

[0149] Those skilled in the art will appreciate that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein can be implemented as electronic hardware, computer software, or combinations of both. To illustrate the 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. Skilled artisans can implement the described functionality in varying ways for each particular application. Various components and blocks can be arranged differently or eliminated from the configuration schematically depicted in the drawings. Additionally, the division of functionality between the action components is for illustrative purposes. For example, one or more blocks can perform one or more actions described as being performed by multiple blocks.

[0150] It should be understood that the particular order or hierarchy of steps in the processes disclosed is an example. Based upon design preferences, it should be understood that specific order or hierarchy of steps in the processes can be re-arranged, or that specific personal steps can be performed at the same time. The accompanying method claims present elements of the various steps in the example order, and are not meant to be limited to the specific order or hierarchy presented.

[0151] 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 can 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. Singular referents include the plural, and plural referents include the singular. Headings and subheadings (if any) are used for convenience only and do not limit the disclosure described herein.

[0152] 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 synonymous with other appropriate phrases indicating mechanical modification or activation, e.g., "suitable to", "adapted to", "made to", "activated to", "activated for", "activated by", "made in active form for", "made in active form to", or other similar phrases. For example, a processor configured to monitor and control operations or components can also mean that the processor is activated to monitor and control operations or the processor is made in active form to monitor and control operations. As another example, a processor configured to execute code can also mean that the processor is programmed to execute code or the processor is made in active form to execute code.

[0153] The term "automatic" as used herein can include performed by a computer or machine without user intervention; for example, by instructions in response to a predicate action or other initiation mechanism of the computer or machine. 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.

[0154] The phrase "aspect" does not imply that a particular aspect is essential to the subject technology, or that all configurations must include the aspects of the subject technology. Disclosures relating to one aspect can be applicable to all configurations, or one or more configurations. An aspect can provide one or more examples. The phrase "aspect" can refer to one or more aspects, and vice versa. The phrase "embodiment" does not imply that a particular embodiment is essential to the subject technology, or that all configurations must include the embodiments of the subject technology. Disclosures relating to one embodiment can be applicable to all embodiments, or one or more embodiments. An embodiment can provide one or more examples. The phrase "embodiment" can refer to one or more embodiments, and vice versa. The phrase "configuration" does not imply that a particular configuration is essential to the subject technology, or that all configurations must include the configurations of the subject technology. Disclosures relating to one configuration can be applicable to all configurations, or one or more configurations. A configuration can provide one or more examples. The phrase "configuration" can refer to one or more configurations, and vice versa.

[0155] All structures and functions described herein in connection with various aspects described herein are intended to be encompassed by the phrase "means for" unless otherwise specifically stated. Furthermore, any aspects disclosed herein are intended to be encompassed by the phrase "comprising at least one of the elements disclosed herein," unless otherwise specifically stated. Moreover, although the terms "first," "second," "third," etc. can be used herein to describe various elements, these elements should not be limited by these terms since such elements can be named in different orders or by different terms in different examples. Additionally, although the terms "first," "second," "third," etc. can be used herein to describe various elements, these elements should not be limited by these terms since such elements can be named in different orders or by different terms in different examples.

Claims

1. A configuration module associated with a first network domain in a communication network that supports time sensitive deterministic communication based on time sensitive network (TSN) mechanisms, comprising: an interface configured to communicate with a plurality of configuration modules associated with different network domains in the communication network to share configuration data between the configuration module and the plurality of configuration modules, wherein the configuration data includes parameters required for each TSN flow to support time sensitive deterministic communication of a respective TSN flow in accordance with the configuration data, the configuration module and the plurality of configuration modules configure one or more communication network (CN) components as one or more TSN blocks based on the configuration data to support communication of each individual TSN flow that flows through the first network domain and the different network domains in the communication network.

2. The configuration module of claim 1, wherein, the configuration data includes a TAS parameter that indicates whether time aware scheduling (TAS) is used to schedule each individual TSN flow, information that indicates whether cyclic queuing and forwarding (CQF) is applied to each individual TSN flow.

3. The configuration module of claim 2, wherein, the TAS parameter is in a Boolean format.

4. The configuration module of claim 1, wherein, the configuration data includes information that indicates whether per-flow filtering and policing (PSFP) is used to police each individual TSN flow in the communication network.

5. The configuration module of claim 1, wherein, at least one of the configuration module and the plurality of configuration modules receives information from a configuration element module in the communication network that indicates whether per-flow filtering and policing (PSFP) is used to police each individual TSN flow in the communication network.

6. A communication network that supports time sensitive deterministic communication based on time sensitive network (TSN) mechanisms, comprising: a first configuration module associated with a first network domain in the communication network that is configured to support time sensitive deterministic communication, and; a second configuration module associated with a second network domain in the communication network that is configured to support time sensitive deterministic communication; and an interface between the first configuration module and the second configuration module, wherein the interface is used to send configuration data from the first configuration module to the second configuration module such that the second configuration module configures one or more of a plurality of communication network (CN) components in the communication network as one or more TSN blocks based on the configuration data, the configuration data includes parameters required for each TSN flow to support time sensitive deterministic communication of a respective TSN flow in accordance with the configuration data.

7. The communication network of claim 6, wherein, the configuration data indicates one or more TSN features required for each individual TSN flow, the one or more TSN features including at least one of time aware scheduling (TAS), per-flow filtering and policing (PSFP), and cyclic queuing and forwarding (CQF).

8. The communication network of claim 7, wherein, the configuration data includes information that indicates whether TAS is used to schedule traffic on the communication network.

9. The communication network of claim 7, wherein, the configuration data includes information that indicates whether PSFP is used to police each individual TSN flow in the communication network.

10. The communication network of claim 7, wherein, the configuration data includes information that indicates whether CQF is applied to each individual TSN flow.

11. The communication network of claim 6, wherein, each individual TSN flow flows through the first network domain and the second network domain in the communication network.

12. The communication network according to claim 6, comprising: A configuration element module is configured to provide a configuration element to at least one of the first configuration module and the second configuration module, the configuration element including one or more TSN features required for each individual TSN flow, the one or more TSN features including at least one of time-aware scheduling (TAS), per-stream filtering and policing (PSFP), and round-robin queuing and forwarding (CQF).

13. The communication network of claim 6, wherein, The communication network includes a wireless network configured according to standards defined by 3GPP.

14. A configuration module associated with a communication network supporting time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism, comprising: a first configuration module associated with the source device or the destination device and configured to provide configuration data for each individual TSN flow transmitted via at least some of a plurality of communication network (CN) components in the communication network; as well as a second configuration module, which is associated with the plurality of CN components, The first configuration module is configured to communicate with the second configuration module via an API so that the second configuration module configures one or more of the plurality of CN components into one or more TSN blocks based on the configuration data, wherein the configuration data represents one or more TSN features required for each individual TSN flow, the one or more TSN features comprising at least one of time-aware scheduling (TAS), per-stream filtering and policing (PSFP), and round-robin queuing and forwarding (CQF), The configuration data includes a Time Aware Scheduling (TAS) parameter indicating whether to use TAS to schedule each individual TSN flow, and information indicating whether to apply Cyclic Queuing and Forwarding (CQF) to each individual TSN flow.

15. The configuration module of claim 14, wherein, The communication network comprises one or more network domains through which each individual TSN flow flows according to the configuration data.

16. The configuration module of claim 15, wherein, The first configuration module and the second configuration module are associated with a same network domain of the one or more network domains.

17. The configuration module of claim 14, wherein, The second configuration module is further configured to share the configuration data with a plurality of configuration modules associated with different ones of the one or more network domains.

18. The configuration module of claim 14, wherein, TAS parameters are in Boolean format.

19. The configuration module of claim 14, wherein, The configuration data also includes information indicating whether each individual TSN flow in the communication network is policed ​​using per-stream filtering and policing (PSFP).

20. The configuration module of claim 14, wherein, The second configuration module is configured to receive information from a configuration element module in the communication network indicating whether to police each individual TSN flow in the communication network using per-stream filtering and policing (PSFP).

Images