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

Abstract

This disclosure provides techniques for implementing configuration modules associated with a communication network to support time-sensitive deterministic communication 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 share configuration data between the configuration module and multiple configuration modules by communicating with multiple configuration modules associated with different network domains in the communication network. The configuration data includes per-TSN stream request parameters to support time-sensitive deterministic communication for each TSN stream in accordance with the configuration data. The configuration module and multiple configuration modules configure communication network (CN) components as TSN blocks based on the configuration data to support communication for each individual TSN stream flowing through the first network domain and different network domains in the communication network.

Description

Technical Field

[0001] This description generally relates to a communication system based on a Time-Sensitive Network (TSN), and more particularly, for example, to the configuration and configuration interface of a TSN-based communication system.

Background Art

[0002] In some applications such as industrial automation and manufacturing, a ubiquitous and seamless connection with strict and deterministic timing requirements for communication between various devices or components of each application (e.g., industrial controllers, sensors, actuators, etc.) is required. 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 for data traffic can be integrated with a 3GPP (registered trademark) compatible wireless communication system that provides high reliability services such as Ultra-Reliable Low Latency Communication (URLLC) services. Furthermore, a typical configuration interface for configuring a TSN network makes it possible to define transmission selection and redundancy functions for TSN data streams, but may not provide per-stream automatic configuration of other functions such as time-aware scheduling and policing functions.

Summary of the Invention

[0003] The technologies, systems, and processes described herein relate to a configuration module associated with a first network domain in a communication network, which includes an interface for sharing configuration data between the configuration module and multiple configuration modules by communicating with multiple configuration modules associated with multiple different network domains in the communication network. The communication network supports time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism. The configuration data includes per-TSN stream request parameters to support time-sensitive deterministic communication for each TSN stream in accordance with the configuration data. The configuration module and multiple configuration modules configure one or more communication network (CN) components as one or more TSN blocks based on the configuration data and support communication for each individual TSN stream. Each individual TSN stream flows through the first network domain and different network domains in the communication network. In some implementations, configuration data includes a TAS parameter indicating whether each individual TSN stream is scheduled using Time-Aware Scheduling (TAS), and information indicating whether cyclic queuing and forwarding (CQF) is applied to each individual TSN stream. In some implementations, the TAS parameter is in Boolean form. In some implementations, configuration data includes information indicating whether each individual TSN stream in the communication network is policed ​​using per-stream filtering and policing (PSFP). In some implementations, a configuration module and at least one of several configuration modules receive information from a configuration element module in the communication network indicating whether each individual TSN stream in the communication network is policed ​​using per-stream filtering and policing (PSFP).

[0004] In one embodiment, a communication network for supporting time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism includes: a first configuration module associated with a first network domain configured to support time-sensitive deterministic communication in the communication network; a second configuration module associated with a second network domain configured to support time-sensitive deterministic communication in the communication network; and an interface between the first and second configuration modules. The interface is used to transmit configuration data from the first configuration module to the second configuration module, which configures one or more communication network (CN) components in the communication network as one or more TSN blocks based on the configuration data. The configuration data includes per-TSN stream request parameters to support time-sensitive deterministic communication for each TSN stream in accordance with the configuration data. In some implementations, configuration data represents one or more TSN functions required for each individual TSN stream, and these one or more TSN functions include at least one of Time-Aware Scheduling (TAS), Stream-by-Stream Filtering and Policing (PSFP), and Periodic Queuing and Forwarding (CQF). In some implementations, configuration data includes information indicating whether or not traffic on the communication network is scheduled with TAS. In some implementations, configuration data includes information indicating whether or not each individual TSN stream in the communication network is policed ​​with PSFP. In some implementations, configuration data includes information indicating whether or not CQF is applied to each individual TSN stream. Each individual TSN stream flows through a first network domain and a second network domain in the communication network.The communication network may include a configuration element module configured to provide a configuration element containing one or more TSN functions required for each individual TSN stream in at least one of a first configuration module and a second configuration module, the one or more TSN functions including at least one of time-aware scheduling (TAS), stream-based filtering and policing (PSFP), and periodic queuing and forwarding (CQF). In some implementations, the communication network includes a wireless network configured according to standards defined by 3GPP.

[0005] In other embodiments, a configuration module is provided associated with a communication network to support time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism. The configuration module may include a first configuration module associated with a source or destination device and a second configuration module associated with the multiple CN components, to provide configuration data for each individual TSN stream communicated through at least one of a plurality of communication network (CN) components in the communication network. In some implementations, the first configuration module communicates with the second configuration module via an API, and the second configuration module is further configured to configure one or more of the multiple CN components as one or more TSN blocks based on the configuration data. The configuration data represents one or more TSN functions required for each individual TSN stream, and the one or more TSN functions include at least one of time-aware scheduling (TAS), stream-based filtering and policing (PSFP), and periodic queuing and forwarding (CQF). The configuration data further includes Time-Aware Scheduling (TAS) parameters indicating whether each individual TSN stream is scheduled by TAS, and information indicating whether periodic queuing and forwarding (CQF) is applied 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 and second configuration modules are associated with the same network domain among the one or more network domains. The second configuration module is further configured to share configuration data with multiple configuration modules associated with different network domains among the one or more network domains. In some implementations, the TAS parameters are in Boolean form. The configuration data further includes information indicating whether each individual TSN stream in the communication network is policed ​​with Stream-by-Stream Filtering and Policing (PSFP).In some implementations, the second configuration module is further configured to receive information from a configuration element module within the communication network indicating whether or not each individual TSN stream in the communication network should be policed ​​with per-stream filtering and policing (PSFP).

[0006] The specific features of this technology are described in the attached claims. However, for illustrative purposes, some aspects of the subject technology are shown in the following figures. [Brief explanation of the drawing]

[0007] [Figure 1] This figure shows an example of a conventional integrated TSN-5G system with one or more implementations. [Figure 2] This is a block diagram of an example of an integrated TSN-5G system architecture with one or more implementations. [Figure 3] This figure shows an example of an integrated TSN-5G system with one or more implementations. [Figure 4] This is a block diagram of an exemplary TSN block with one or more implementations. [Figure 5] This figure shows an exemplary parameter set for an exemplary TSN block with one or more implementations. [Figure 6A] This is a block diagram of an exemplary integrated TSN-5G system architecture including MEC with one or more implementations. [Figure 6B] This is a block diagram of an exemplary integrated TSN-5G system architecture including MEC with one or more implementations. [Figure 7] This figure shows an electronic system in which one or more implementations of this technology may be carried out. [Figure 8] This is a block diagram of an exemplary integrated TSN-5G system architecture with one or more implementations. [Figure 9] This figure shows a non-limiting example of a TSN communication network system with one or more implementations. [Figure 10] This figure shows non-exclusive examples of configuration data from one or more implementations. [Figure 11] This is a block diagram of an example of an integrated TSN communication network system architecture using one or more implementations. [Figure 12] This is a block diagram of an exemplary integrated TSN (Transportation Signal Network) system architecture with one or more implementations. [Modes for carrying out the invention]

[0008] The following detailed description is intended to illustrate various configurations of the technology and not to represent the only possible configuration. The accompanying drawings are incorporated herein and constitute part of the detailed description. The detailed description includes specific details to ensure a full understanding of the technology. However, the technology is not limited to the specific details described herein and can be implemented using one or more other implementations. In one or more implementations, the structure and components are shown in block diagrams to avoid obscuring the concepts of the technology.

[0009] As mentioned above, but not limited to, in some applications such as industrial automation, manufacturing, aerospace, and automotive communications, a TSN system providing deterministic communication may be integrated with a fifth-generation (5G) or sixth-generation (6G) wireless communication system (or any communication network or system defined in accordance with 3GPP or IEEE 802.1 standards). However, typically, in such an integrated TSN-5G system, the entire 5G system is configured to operate as a single TSN component (e.g., a TSN bridge), and the integrated system is set up as a fully centralized configuration model using, for example, a single centralized TSN configuration controller. Therefore, such an integrated system may not support the flexibility of deploying a 5G system that includes various components provided by various vendors, or the flexibility for a distributed TSN configuration of the integrated system. Also, 5G systems can support reliable communication by using redundant paths for data transmission. However, in a typical TSN-5G integrated system, when the 5G system is configured as a single TSN component, redundant paths are configured throughout the entire 5G system, across all components of the 5G system (e.g., from User Equipment (UE) to User Plane Function (UPF)). This does not provide the flexibility to configure redundant data transmission paths for only a portion of the 5G system, such as a portion of the 5G system that is susceptible to data delay and / or error (e.g., the air interface between the UE and the Radio Access Network (RAN) / gNodeB).

[0010] To address the above issues in integrated TSN-5G systems, this technology provides a novel architecture in which the 5G system is configured as a set of discrete 5G components, each configured as a discrete TSN block, instead of being configured as a single TSN component or block. In other words, this disclosure provides an architecture in which the 5G system in an integrated TSN-5G system is divided into multiple TSN blocks, each TSN block being configured, for example, as a TSN bridge, a TSN end device, or a combination of the two, according to the TSN specification (e.g., IEEE 802.1Q and related standards). Furthermore, instead of having a centralized configuration controller that controls the TSN-5G system, the TSN-5G system has multiple distributed configuration modules. The configuration modules may be interconnected in one or more topologies (including mesh, star, tree, or random), and each configuration module may communicate with and be responsible for configuring one or more TSN blocks.

[0011] As described in detail below, each TSN block in a 5G system includes a set of parameters that describe its ability to support and execute data flows (e.g., carrying URLLC data traffic) through that TSN block. Furthermore, each TSN block may include at least one configuration interface, which is configured to support interaction between the TSN block and its respective configuration module. The configuration interface may be used to provide the parameter set of the TSN block to each configuration module and to receive configuration data (e.g., transmission schedule, data flow identifier, polysingle rules, etc.) from the configuration module to support one or more data flows through the TSN block. Each TSN block may be configured to execute or operate according to the configuration data (received via the configuration interface) and to transmit data for each data flow according to the specifications provided in the configuration data. Finally, each TSN block may include a monitoring and diagnostic module configured to monitor the runtime behavior of the TSN block and report that behavior via the configuration interface or via a separate interface of the TSN block.

[0012] Each of the multiple distributed configuration modules may be an external utility that configures one or more TSN blocks, or it may be configured as a software module within a TSN block that configures only that TSN block. Each configuration module may be configured to determine and provide to the TSN block configuration data, including TSN schedules for one or more data flows transmitted through the TSN block controlled by the configuration module. The configuration modules may exchange information with each other using a standardized Application Programming Interface (API). The information exchanged may include information about the cycle time of the TSN system (e.g., supported Admin Cycle Time (ACT), including discrete levels of ACT buckets corresponding to a particular data flow, maximum / minimum cycle times), configuration data including transmission schedules for one or more TSN blocks (including time offsets / duration / resources for transmission), and information for resource allocation requests or responses. In some implementations, one or more of the multiple configuration modules may be adapted as a “controller” or “controller module.” A controller or controller module may include components configured or adapted to provide instructions, controls, actions, or any form of communication to operable components to influence their operation.The controller module may include, but is not limited to, any known processor, microcontroller, or logic device, including field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), full-authority digital engine control (FADECs), aerospace systems, proportional controllers (Ps), proportional-integral controllers (PIs), proportional-derivative controllers (PDs), proportional-integral-derivative controllers (PID controllers), hardware-accelerated logic controllers (e.g., encode, decode, transcode, etc.), or any combination thereof.

[0013] 3GPP Release 8 classifies Self-Organizing Networks (SONs) into three main categories: self-configuration, self-optimization, and self-healing. Self-organization is considered a mechanism or process that allows a system or network to change its organization during runtime without explicit commands. Self-configuration is defined as the process of incorporating a new Network Element (NE) into a service that requires minimal human operator intervention. A Network Element is a manageable logical entity that combines one or more physical devices. In some implementations, a TSN block (described below) can be self-configurable and invoked as an NE in a 5G system with minimal human intervention. This can be achieved by the TSN application automatically sharing TSN flow (stream) characteristics and latency requirements with the TSN block. The TSN blocks may share flow characteristics and collaborate to determine feasible TSN schedules.

[0014] In some implementations, this disclosure provides a communication network configured to support time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism, such as a fifth-generation (5G) or sixth-generation (6G) wireless communication system or network (or any communication network or system as defined in accordance with the 3GPP or IEEE 802.1 standards). In the context of this disclosure, references to “communication network,” “wireless network,” and “communication / wireless network” mean a network of various components designed, deployed, and / or configured to perform communications over the network, in the form of data, signals, or information, from a source node or source device to a destination node or destination device, with at least a portion of the communication being completed wirelessly. The various components of such a network may be communicated via wireless links or wireless channels and / or wired links or wired channels. The various components of the network include modules and channels / links implemented in hardware, software, and combinations of hardware and software.

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

[0016] The multiple discrete CN components of a 5G network include a transport network channel connecting user equipment (UE), a radio access network (RAN), a user plane function (UPF), a control plane function, and CN components including a transport network channel connecting the RAN and the UPF. In some implementations, at least one of the multiple CN components for which TSN parameters are set is a 5G transport network channel connecting the RAN and the UPF.

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

[0018] In some implementations, the present disclosure provides a communication network, such as a wireless network such as a 5G network. The communication network includes a plurality of configuration modules, the plurality of configuration modules being interconnected in a predetermined arrangement and configured to provide a unique set of TSN parameters for each of the multiple CN components. Each of the multiple CN components supports time-sensitive deterministic communication as a corresponding TSN block in the TSN network according to its respective unique set of TSN parameters. The plurality of configuration modules may be interconnected with each other in a hierarchical arrangement, a mesh arrangement, a star arrangement, a tree arrangement, or a combination thereof.

[0019] In some implementations, the Disclosure provides a system comprising a first communication (e.g., 5G / 6G) network, a second communication (e.g., 5G / 6G) network, and a TSN transport channel connected to the first and second communication networks. The first network may comprise a plurality of first CN (communication network) components, each configured to provide a distinct function for data communication over the first network, with at least one of the CN components configured to provide time-sensitive deterministic communication according to a first TSN parameter set. The second network comprises a plurality of second CN components configured to provide a distinct function for data communication, with at least one of the second CN components configured to provide time-sensitive deterministic communication according to a second TSN parameter set. The TSN transport channel may be configured to facilitate time-sensitive deterministic communication of data exchanged between the first and second networks according to a third TSN parameter set. In some implementations, the TSN transport channel is communicated with a first TSN translator in a first wireless network and a second TSN translator in a second wireless network.

[0020] In some implementations, an integrated TSN-5G system may have multiple configuration modules in a distributed controller to control the integrated TSN-5G system. These configuration modules may be interconnected in one or more topologies (mesh, star, tree), and each configuration module configures network components as a TSN block to support TSN functions defined by the TSN specification (e.g., IEEE 802.1Q). In an integrated TSN-5G system, at least two of the configuration modules (e.g., Centralized Network Configuration (CNC)) can support one or more data flows through a TSN block by exchanging configuration data (e.g., transmission schedules, data flow identifiers, polysingle rules, etc.) via a standardized API. This is not limited to TSN-5G systems but also applies to TSN systems integrated with 3GPP-compatible wireless communication systems. The configuration data may be defined by the TSN specification (e.g., IEEE 802.1Q), and the standardized API may be based on Section 46.2.3 of IEEE 802.1Q. The full text of IEEE 802.1Q is incorporated herein by reference. Configuration data provides settings on a per-TSN stream basis, i.e., for each individual TSN stream in the TSN network, with respect to, for example, the transmit selection and redundancy functions of each TSN stream. Thus, a configuration module configures one or more TSN blocks (e.g., TSN bridges) that perform or operate according to the configuration data. In some implementations, an integrated TSN-5G system may employ one or more TSN functions (e.g., time-aware scheduling (TAS), per-stream filtering and policing (PSFP), periodic queuing and forwarding (CQF), etc.) according to the TSN specifications required for each individual TSN stream (e.g., IEEE 802.1Q, IEEE 802.1Qbv, IEEE 802.1Qci, etc.).However, the configuration data shared from one configuration module to another does not include or provide the configuration of TSN functions as the required parameters for each individual TSN stream. Instead, TSN functions such as TAS, policing, periodic queuing, etc. are determined by the network configuration module based on user input.

[0021] To address the aforementioned challenges in integrated TSN communication network systems, this technology provides a new and improved interface or extended API between a first configuration module associated with an end station or end-user device (e.g., Centralized User Configuration (CUC)) and a second configuration module associated with a network device such as a network bridge (e.g., CNC). The new and improved interface or extended API between the CUC and CNC enables detailed description of per-stream requirements. Specific examples of requirements include explicitly requiring the scheduling of streams within the network using a time-aware shaper or similar shaper, explicit requirements regarding latency, jitter, and loss, and explicit requirements for filtering and policing streams within the network. The new and improved interface or extended API can provide explicit and granular definitions of stream requirements between the CUC and CNC. The new interface or extended API includes TSN configuration parameters, functions, and stream requirements necessary to implement TAS, policing, periodic queuing, etc., for each individual TSN stream communicated over the communication network. The system is configured to share meters, functions, and requirements between the first and second configuration modules. Therefore, configuration parameters and functions such as TAS, policing, and periodic queuing exist in addition to conventional parameters shared between conventional TSN configuration modules (e.g., CUC and CNC). In some embodiments, such additional configuration parameters may be used by a configuration module receiving such parameters to determine whether to perform time-aware shaping or time-aware scheduling, whether to perform policing, etc., for a particular TSN stream on the communication network, and to configure a TSN network device (e.g., a bridge) to process that particular TSN stream.In some embodiments, additional configuration parameters relating to TAS, policing, and periodic queuing functions may be Boolean parameters. The API may describe stream requirements for each stream beyond those defined in the current TSN specification (e.g., Section 46 of IEEE 802.1Q). These stream requirements may include delivery modes such as deadline-based delivery modes and latency-based delivery modes. In the case of a deadline-based delivery mode, the requirement may specify an absolute or relative time by which frames belonging to the stream must be delivered to their final destination. In the case of a latency-based delivery mode, the requirement may include a maximum allowable latency from the start of transmission of a frame at the source to the reception of the frame at the destination. In yet another embodiment, the CUC may inform the CNC via the inter-configuration API of stream jitter requirements specifying a maximum deviation from a fixed delivery time.

[0022] As described above, each network domain's CUC communicates with one or more CNCs within the same network domain via a new interface or an extended API. Even in situations where it is necessary to share a subset of configuration data with other network domains to support TSN functionality or requirements for each TSN stream, such communication is limited to CUCs and CNCs within the same network domain. Therefore, a separate interface or API for sharing configuration data (including per-stream requirements) between configuration modules (CNCs) in multiple network domains is necessarily required to support data flows / streams between multiple domains that interoperate in a standard manner.

[0023] To address the above issues, this technology provides a 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 extended API between the two CNCs enables the configuration of a multi-domain TSN network. In some embodiments, the new interface or extended API provides two specific functions: The new interface or extended API enables communication of stream requirements from a CUC in the first network domain to a CNC in the second domain via the CNC in the first network domain. This is because the CUC only communicates (stream requirements) with CNCs in network domains. Some of these requirements need to be communicated to other CNCs in the communication network. The new interface or extended API enables configuration modules (CNCs) to adjust their configurations to meet stream requirements. For example, if there is a latency budget and each CNC exhausts part of the budget when scheduling streams through its own domain, that information needs to be shared via the inter-CNC API. By combining these two functions, the configuration of an entire communication network, including multiple network domains, can meet the requirements of each stream. Therefore, the new interface or extended API is configured to share TSN configuration parameters, functions, and requirements between the first and second configuration modules for each individual TSN stream flowing / propagating / transitioning between the first and second domains. This TSN configuration information may include the configuration parameters or functions necessary to implement TAS, policing, periodic queuing, forwarding, shaping, metering, and filtering for each TSN stream.

[0024] Figure 1 shows a non-limiting example of a conventional integrated TSN-5G system 100 configured such that the 5G network or system 106 is emulated as a single TSN component (e.g., a TSN bridge). System 100 is configured as a deterministic TSN system that communicates data between end devices, e.g., input / output (I / O) devices 102 and controller 104, and uses a TSN controller 110, via the 5G system 106 (acting as a TSN bridge) and one or more (conventional) TSN bridges 108. System 100 is configured based on standard methods for time synchronization and traffic management, enabling deterministic communication over a standard Ethernet network between end devices such as I / O devices 102 and controller 104. For example, system 100 may operate in accordance with the IEEE 802.1Q TSN standard family, which standardizes Layer 2 communication for networking protocols that provide deterministic communication while sharing the same infrastructure. For example, many standards establish various technical paradigms for TSN systems, namely 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 Ethernet Layer 2 to ensure that their respective control and safety functions are performed while meeting their respective deadlines and constraints. Similar integrated systems may be configured to implement TSN technology over wireless local area networks (wireless LANs), such as Wi-Fi 6 or other common wireless LAN-based Wi-Fi networks.

[0025] For example, the 802.1Qbv TSN standard provides pre-scheduled transmissions for security-critical data frames, and this specification utilizes the entire standard. As used herein, “TSN schema” can refer, without limitation, to networks, components, elements, units, nodes, hubs, switches, controls, modules, paths, data, data frames, traffic, protocols, operations, transmissions, and combinations thereof that comply with, conform to, or are configured to conform to one or more IEEE 802.1 TSN standards. The 802.1Qbv TSN standard addresses the transmission of critical and non-critical data traffic within a TSN. Critical data traffic typically has a higher priority than non-critical data traffic and is guaranteed to be delivered at scheduled times. Various traffic classes are established according to IEEE 802.1Q, which are used to prioritize different types of data traffic.

[0026] Ethernet frame preemption is defined by the IEEE 802.3br and IEEE 802.1Qbu standards, and allows for the temporary suspension of transmission of non-critical Ethernet frames, which is also beneficial in reducing latency and latency fluctuations for critical traffic. The basis of resource management is defined by the TSN configuration model (IEEE 802.1Qcc). The centralized network configuration (CNC) 112 applies to network devices (bridges, e.g., 5G system bridge 106, bridge 108), while the centralized user configuration (CUC) 114 can apply to user devices (end stations, e.g., I / O device 102), as specified in, for example, IEEE 802.1Qdj[xx]. The fully centralized configuration model follows a Software-Defined Networking (SDN) approach. In other words, the CNC 112 and CUC 114 within the controller 110 provide the control plane instead of distributed protocols. In contrast, in a fully distributed model, there may be no CNC or CUC, and a distributed control protocol is applied. High availability resulting from ultra-high reliability can be provided to data flows by FRER (IEEE 802.1CB) via packet-level reliability mechanisms. This provides reliability by sending multiple copies of the same data packet through non-intersecting paths within the network. Stream-level filtering and policing (802.1Qci) improve reliability by protecting against bandwidth violations, malfunctions, and malicious activity. Furthermore, time synchronization in TSN systems can be defined by gPTP (802.1AS), a profile of the Precision Time Protocol standard (IEEE 1588). gPTP provides reliable time synchronization that can be used by other TSN tools (e.g., Scheduled Traffic (802.1Qbv)).

[0027] To achieve the desired reliability level, the TSN employs time synchronization and time-aware data traffic shaping. Data traffic shaping uses scheduling to control the gating of transmissions at network switches and bridges (e.g., nodes). In some embodiments, the scheduling of such data traffic in the TSN may be determined before the network is operational. In other embodiments, the scheduling of data traffic is determined at the initial design stage based on system requirements and is updatable as needed. For example, in addition to defining the TSN topology (including communication paths, bandwidth reservations, and various other parameters), synchronized times across the network for data transmission can be predefined. Such a plan for data transmission on the communication paths of a network is typically called a “communication schedule” or simply a “schedule.” The scheduling of data traffic in the TSN may be determined for a particular data packet, on a particular path, at a particular time, and over a particular period of time. A non-limiting example of the techniques for generating TSN data traffic scheduling is discussed in U.S. Patent Application No. 17 / 100,356, which is incorporated herein by reference in its entirety.

[0028] Time-sensitive communications between end devices or nodes in a TSN (e.g., I / O device 102 and controller 104) include "TSN flows," also called "data flows" or simply "flows." For example, a data flow can include data packets or datagrams such as data frames. Each data flow is unidirectional, moving from a first originating or source end device in the system (e.g., I / O device 102) to a second destination end device (e.g., controller 104), and has unique identification information and time requirements. These source and destination devices are commonly referred to as "talkers" and "listeners." Specifically, the "talkers" and "listeners" are the source and destination of the data flow, respectively, and each data flow is uniquely identified by the end devices operating in the system. If a given network topology includes multiple interconnected devices, it will be understood that a set of data flows can be defined between interconnected devices or nodes. For example, a set of data flows may be between interconnected devices. Regarding a set of data flows, various subsets or permutations of data flows can be additionally defined. Furthermore, time-critical communication between end devices or nodes in a TSN includes a "TSN stream" or "stream," each TSN stream may be initiated at a specific talker node intended to communicate with one or more listener nodes. Thus, each TSN stream may contain one or more data flows, each data flow being between a talker node (the node that initiated the TSN stream) and a listener node.

[0029] End devices (e.g., 102, 104) and switches (commonly called "bridges" or "switching nodes") (e.g., 106, 108) transmit and receive data (in one non-limiting example, Ethernet frames) in the data flow based on a predetermined time schedule. Switching nodes and end devices must be time-synchronized to ensure that the predetermined time schedule for the data flow is correctly observed throughout the network. For example, in Figure 1, clock 116 indicates that the various switching nodes and end devices of the TSN system 100 (including the 5G system 106) are time-synchronized with reference to a global clock (grandmaster clock timing). In some other embodiments, only switches may transmit data based on a predetermined schedule, while end devices, such as legacy devices, may transmit data in an unscheduled manner.

[0030] Data flows within a TSN can be scheduled using a single device (e.g., controller 110) that assumes a fixed, unchanging path between talker / listener devices and switching nodes in the network. Alternatively, data flows can be scheduled using a set of devices or modules. The scheduling device, whether a single device or a set of devices, can be configured to define a centralized scheduler. In yet another embodiment, the scheduler device can include a distributed configuration. The TSN can also receive non-time-sensitive communications, such as rate-constrained communications. As a non-limiting example, the scheduling device can include an offline scheduling system or module.

[0031] TSN traffic can be tagged using various mechanisms, including VLAN tagged Ethernet address IP header information, and combinations of VLAN tagged Ethernet address and IP header information. Traffic can be identified and tagged anywhere in the system before the identification of a Protocol Data Unit (PDU) is required. A TSN talker can generate multiple TSN flows (streams) with different TSN latency and determinism requirements, and different paths that satisfy these requirements can be assigned. In some implementations of the present invention, latency and determinism values ​​may be specified and provided to the TSN application as a limited set of static discrete values, rather than proposing to accept an unlimited set of continuous values.

[0032] In some implementations, the I / O end device 102 may, in various embodiments, be a complex mechanical entity such as a factory production line, a gas-fired power plant, an aircraft avionics data bus, an aircraft jet engine in a group of aircraft (e.g., two or more aircraft), an aircraft digital backbone, an avionics system, a mission network or flight network, a wind farm, or a locomotive. In various implementations, the I / O end device 102 may include any number of end devices, such as sensors, actuators, motors, and software applications. Sensors may include conventional sensors or transducers, such as cameras that generate video or image data, X-ray detectors, acoustic pickup devices, tachometers, global positioning system receivers, radio devices that transmit radio signals and detect reflections of radio signals to generate image data, or other devices.

[0033] Furthermore, actuators (e.g., devices, apparatus, or machines that move to perform one or more actions of I / O device 102) can communicate using the TSN system 100. Non-limiting examples of actuators may include brakes, throttles, robotic devices, medical imaging devices, lighting, turbines, etc. Actuators can communicate their state data to one or more other devices (e.g., other I / O devices 102, controller 104 via the TSN system 100). The state data may represent the position, state, health, etc., of the actuator transmitting the state data. Actuators may receive command data from one or more other devices of the TSN system 100 (e.g., other I / O devices 102, controller 104). The command data may represent instructions that tell the actuator how or when to move, act, etc.

[0034] In some implementations, the controller 104 can communicate various data between I / O end devices 102 via the TSN 100. For example, the control system 104 can communicate command data to one or more devices 102, or receive data such as status data or sensor data from one or more devices 102. Therefore, the control unit 104 is configured to control the operation of the I / O devices 102 based on data acquired, generated, or communicated by the I / O devices 102, enabling, for example, automatic control of the I / O devices 102 and providing information to the operator or user of the I / O devices 102. The controller 104 may define or determine data flow and data flow characteristics in the TSN system 100.

[0035] The 5G system 106 within system 100 is described as a 5G network or system 106, which is a wireless communication network or system used to carry TSN traffic between various TSN end devices, e.g., I / O device 102 and controller 104. In some implementations, the 5G system 106 is configured to behave as one TSN bridge per UPF (similar to the TSN bridge 108 according to the TSN standard described above). The 5G system 106 is a New Radio (NR) network implemented in accordance with the 3GPP Series 23 and Series 38 specifications (these specifications are invoked in their entirety herein) and is integrated into system 100 according to the 3GPP Release 17 23.501 standard (e.g., v17.1.1 and v17.2.0), which is invoked in its entirety herein. As illustrated, the 5G system 106 may include various CN components in the 5G user plane, such as UE118, RAN(gNB)120, and UPF122, and in the 5G control plane, such as Application Function (AF)124, SMF, and Policy Control Function (PCF)126, and other components as defined in the 3GPP 23.501 standard. In some implementations, the 5G system 106 may be configured to provide URLLC services. The 5G system 106 based on the NR interface has several features to achieve low latency for selected data flows. NR enables shorter slots in radio subframes, which is advantageous for low-latency applications. NR also introduces mini-slots, which allow high-priority transmissions to start without waiting for slot boundaries, further reducing latency. As part of providing preferential and rapid radio access to URLLC traffic, NR introduces preemption, which allows URLLC data transmissions to replace non-URLLC transmissions in progress. Furthermore, NR applies extremely fast processing, enabling retransmission even within a short latency range.

[0036] In some implementations, 5G defines an ultra-high reliability transmission mode for improved reliability for both data and control radio channels. Reliability is further enhanced by various techniques such as multi-antenna transmission based on Multiple-Input Multiple-Output (MIMO) technology, the use of multiple carriers, and packet replication over independent radio links.

[0037] Time synchronization is incorporated as an integral part of the operation of 5G cellular radio systems, which was already a common practice in previous generations of cellular networks. The radio network components themselves are also time-synchronized, for example, via a precision time protocol telecommunications profile, based on the 5G internal system clock 190. This provides a good foundation for performing synchronization for time-critical applications. For URLLC services, the 5G system 106 uses time synchronization for its own operation, and multiple antennas and radio channels that provide reliability also use time synchronization. In addition to the functionality of the 5G RAN, the 5G system 106 can also provide solutions in the core network for Ethernet networking and URLLC. The 5G core network supports native Ethernet PDU sessions. 5G assists in establishing redundant user plane paths via the 5GS, which includes the RAN, core network, and transport network. The 5GS allows redundant user planes not only between UEs and RAN nodes, but also between RAN nodes and core network nodes.

[0038] As described above, in the integrated system 100, the 5G system 106 has one TSN (virtual) bridge per UPF. The 5G system 106 includes a TSN Translator (TT) function for adapting the 5G system 106 to the TSN domain in both the user plane and the control plane, hiding the internal procedures of the 5G system 106 from the TSN bridge network. The 5G system 106 provides input / output port operations of the TSN bridge via the TT function. For example, the TT supports a hold-and-forward function for jitter reduction. Figure 1 shows the case where the 5G system 106 connects the end station 102 to the bridge network 108, but the 5G system 106 can also interconnect the bridges 108.

[0039] For the 5G system 106 to be integrated into the TSN system 100, the requirements of the TSN stream can only be met if resource management allocates network resources to each hop along the entire path. According to the TSN configuration (802.1Qcc), this is achieved through interaction between the 5G system 106 and configuration controllers, e.g., a centralized configuration controller 110 (including CUC114 and CNC112) and / or a set of distributed controller modules (e.g., as described below with respect to Figure 2). The interface between the 5G system 106 and the CNC allows the CNC112 to learn the characteristics of the 5G virtual bridge and for the 5G system 106 to establish a connection with specific parameters based on the information received from the CNC112. Bounded latency requires deterministic delay from 5G and QoS matching between the TSN domain and the 5G domain. For example, when a 5G virtual bridge operates as a TSN bridge, the 5G system 106 emulates time-controlled packet transmission according to scheduled traffic in, for example, 802.1Qbv. In the 5G control plane, the TT in AF124 receives transmission time information for the TSN traffic class from CNC112. In the 5G user plane, the TT in UE118 and the TT in UPF122 may appropriately regulate time-based packet transmission. Different TSN traffic classes use different 5G QoS indicators (5QI: AF124 and PCF126) as part of QoS alignment between the TSN domain and the 5G domain. The 5QIs can be mapped to 5G QoS Indicators, and different 5QIs are handled according to their respective QoS requirements.

[0040] With regard to time synchronization, the 5G system 106 may implement gPTP on the connected TSN network. The 5G system 106 may operate as a virtual gPTP time-aware system and support the transfer of gPTP time synchronization information between the end station 102 and the bridge 108 via the 5G user plane TT. All the various 3GPP and TSN standards referred to in this disclosure are incorporated herein by reference in their entirety.

[0041] Refer to Figure 2, which shows a block diagram of the architecture of system 200 relating to several implementations of the present technology. Outline, system 200 is a block diagram showing an example implementation of an integrated TSN-5G system similar to system 100 described above, and includes similar physical components. However, unlike system 100, system 200 provides a novel architecture for an integrated TSN-5G system, where the 5G system 106 is configured as a set of discrete 5G components, each 5G component behaving as a discrete TSN block or element 202. In other words, in system 200, the 5G system 106 is configured as a disaggregated structure containing multiple TSN blocks 202-1 to 202-N, where each TSN block 202 is configured, for example, as a TSN bridge, a TSN end device (i.e., a TSN talker and / or TSN listener), or a combination thereof, according to the TSN specification (e.g., IEEE 802.1 and related standards described above). Furthermore, instead of having a centralized configuration controller 110 that controls the TSN-5G system, this technology provides a distributed controller 210 within the TSN-5G system 200 with a plurality of distributed configuration modules 215. The configuration modules 215-a to 215-f may be interconnected in one or more topologies (mesh, star, tree), and each configuration module 215 may communicate with one or more TSN blocks 202 and be responsible for configuring one or more TSN blocks 202. In some implementations, one or more of the configuration modules 215-a to 215-f may be implemented within or as part of the functionality of the control plane of the 5G system 106 (e.g., SMF126). As used herein, “topology” can refer to one or more arrangements of a network that may include a plurality of nodes (e.g., transmitting devices, receiving devices, switches, or bridges) and connecting lines between nodes in the network (e.g., communication links, or “hops” including wired communication links or wireless communication links). Each link may communicatively connect a corresponding pair of nodes.A set of links can be connected sequentially through each node to define, for example, a link path between an originating node and a destination node. The topology may include, but is not limited to, one or more of the mesh, star, bus, ring, and tree topologies.

[0042] In some implementations, system 200 is configured to support and manage deterministic TSN data flow between a data source 204 ("source device") and a data destination device 206 ("destination device") via 5G system 106, according to a TSN configuration that includes a TSN schedule determined by one or more configuration modules 215. The data source 204 and data destination 206 may include one or more of the I / O devices 102 and controllers 104. Although not shown, system 200 may also include a TSN bridge 108 and other TSN components.

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

[0044] In some implementations, as shown in Figure 4, each TSN block 202 includes a processor 402, a memory device 404, an Internal Configuration Interface (ICI) 406, a transmit module 408, a report module 410, and TSN TT-1 412-1, TT-2 412-2, and TT-3 412-3. The processor 402 may be a microprocessor or multicore processor, integrated circuit, field-programmable gate array, etc., that processes TSN configuration data and executes instructions (for example, stored in the memory device 404) to process and transmit TSN data traffic from one or more TSN data flows according to the TSN configuration data.

[0045] The memory device 404 may store a set of parameters describing its ability to support and execute data flows (e.g., carrying URLLC data traffic) through the corresponding TSN block 202. In some implementations, the parameter set may include, but is not limited to, an identifier, link quality, and link bandwidth. The identifier parameter may include the device type (i.e., whether the TSN block 202 is a TSN bridge or a TSN end station). The latency parameter may include at least the latency between ports (from the start to the end of the TSN block) and the latency variation (commonly known 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 expressed in bits per second.

[0046] In some implementations, the parameter set for TSN block 202 may include a subset of 5G RAN-specific parameters, such as short transmit time intervals, TSC Assistance Information (TSCAI), Configured Grant (CG) information, Semi-Persistent Scheduling (SPS) allocation, and / or other parameters, as specified in 3GPP TS28.540. Furthermore, in some implementations, the parameter set for TSN block 202 may include a subset of TSN-specific parameters, such as time synchronization characteristics, Scheduled Transmit (Qbv) attributes, number of connected RANs, number of paths to UPF, path diversity, number of available frequencies, propagation characteristics, available radio, and redundancy attributes, including different physical media (e.g., free-space optics). As an example, Figure 5 shows an exemplary set of parameters 502 for an exemplary TSN block 202.

[0047] In some implementations, the parameter set for TSN block 202 may define the worst-case time synchronization error, worst-case gate operation error, maximum gate control list size, maximum cycle time, maximum gate interval length, transmit start delay, or a combination thereof. The parameter set may include a discrete deterministic parameter set that may vary depending on the type of traffic handled by TSN block 202. At least a portion of the parameter set can be used to generate TSN schedules, configurations, etc., that are feasible on the TSN block 202 hardware. Without such a parameter set, the TSN scheduling module must take a least common denominator approach, assuming that all devices in system 200, including TSN block 202, have the most restricted characteristics, which will result in a solution inferior to the optimal solution. In this sense, the parameter set enables a better scheduling solution in the TSN system 200, resulting in improvements in performance metrics including latency, jitter, packet delay variation, and bandwidth utilization.

[0048] In some implementations, the parameter set for TSN block 202 may further specify that it relates to devices that are created, programmed, or of different operation or manufacture. In this sense, the parameter set may define a set or subset of different devices (e.g., heterogeneous devices from multiple vendors) as opposed to homogeneous devices or all similar devices. For example, the parameter set may include, but is not limited to, definitions of specific configuration models, error tolerances, hardware limits, software limits, and firmware options for each end node and switching node in system 200. In this sense, the parameter set enables scheduling and configuration of heterogeneous networks, including devices from multiple vendors and devices with various characteristics.

[0049] In some implementations, the parameter set for TSN block 202 may further facilitate specific TSN features supported by each end node and each switching node of the TSN system 200. For example, the parameter set may define whether a node or TSN block 202 supports one or more of the following TSN features: time synchronization, time-aware shaping, asynchronous shaping, frame duplication and exclusion for reliability, frame preemption, ingress policing, and other TSN features. The parameter set may further define specific versions or variants of features or standards supported by end nodes and switching nodes in the TSN system 200. This parameter set enables end nodes and switching nodes to schedule and configure a mixed-capacity network with varying degrees of support (including no support) for desired TSN features and versions.

[0050] Further non-exclusive examples of parameter sets for devices in TSN block 202 may include, but are not limited to, additional parameters used to program the functionality of each TSN block 202. For example, additional parameter sets may define or enable the programming of each TSN block 202 using generated or scheduled TSN settings. Non-exclusive examples of parameter sets that may define or enable the programming of each TSN block 202 may include, but are not limited to, programming methods, communication protocols, device login names, device login passwords, device programming ports, device programming file structures or file paths for programming data, device programming file formats, device configuration file formats, device schedule file formats, or combinations thereof. In this sense, this set or subset of parameters that define or enable the programming of each TSN block 202 using generated or scheduled TSN settings (collectively, “Programming Parameters”) allows system 200 to update, install, program, configure, or otherwise modify a set of TSN blocks 202 according to a schedule or configuration of the TSN system 200.

[0051] Furthermore, each TSN block 202 may include at least one ICI 406 configured to support interaction between the TSN block 202 and, for example, its respective configuration module 215. The ICI 406 may provide some or all of the parameter set of the TSN block 202 to each configuration module 215 and receive configuration data (e.g., transmission schedule, data flow identifier, polysingle rule, etc.) from the configuration module 215 to support one or more data flows passing through the TSN block 202. Each TSN block 202 may be configured to execute or operate according to the configuration data (received via the ICI 406) and to transmit data for each data flow according to the specifications provided in the configuration data.

[0052] In some implementations, in TSN block 202, the configuration data received via ICI406 from each configuration module 215 may include stream identification information, transmission schedule or deadline or delay budget or data rate (for rate-constrained traffic), filtering and policing configuration information, redundancy scheme, and / or other TSN configuration information.

[0053] TSN talker information can be separated into different frequency components that require different latency and determinism requirements for different TSN flows. Conversely, TSN flows from different TSN talkers can be aggregated into a single TSN flow to achieve greater capacity and higher channel utilization. In an integrated TSN-5G system, having separate cycle times can help ensure the ease of TSN flow aggregation.

[0054] In some implementations, each TSN block 202 may include a transmit module 408 configured to transmit specific data flows according to the schedule, deadline, delay budget, or data rate contained in the configuration data received from the configuration module 215 via the ICI 406. In one example where TSN block 202-1 corresponds to the UE 118 of a 5G system, the transmit module 408 is configured to transmit data based on the resource scheduling of the 5G radio interface (between the UE 118 and the RAN 120). The resource scheduling of the 5G radio interface may be phase-synchronous with the cycle time of the integrated TSN-5G system. The transmit module 408 may allocate resource elements of the 5G component corresponding to TSN block 202 (which is part of 408) so that it can satisfy scheduled transmissions per Qbv stream. For example, instead of using classic 802.1Qbv-style gate control, the UE 118 corresponding to TSN block 202-1 may use a phase offset (reference to cycle time) to synchronize the transmission of TSN data streams to an allocated schedule. In this example, instead of UE118 obtaining this phase offset from the CNC, UE118 could obtain the phase offset from RAN120 as a special command.

[0055] In some implementations, each TSN block 202 may include a reporting module 410 configured to monitor the runtime behavior of the TSN block 202 and report its behavior via the ICI 406 or via a separate interface of the TSN block 202. This behavioral monitoring includes, but is not limited to, packet drop and lost transmission windows.

[0056] Returning to Figure 2, the technology in question includes a distributed controller 210 in a TSN-5G system 200 with multiple distributed configuration modules 215. The configuration modules 215-a to 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, CM215-a may be responsible for TSN blocks 202-1 and 202-2, and may be operationally and communicatively connected to TSN blocks 202-1 and 202-2. CM215-b may be responsible for TSN block 202-3, and may be operationally and communicatively connected to TSN block 202-3. CM215-c may be responsible for TSN blocks 202-3 and 202-N, and may be operationally and communicatively connected to TSN blocks 202-3 and 202-N. Therefore, TSN block 202-3 can be configured and controlled by both CM215-b and CM215-c. For example, some of the functions in TSN block 202-3 (e.g., functions relating to a first type of TSN application) can be configured and controlled by CM215-b, while other functions in TSN block 202-3 (e.g., functions relating to a second type of TSN application) can be configured and controlled by CM215-c.

[0057] In the example shown in Figure 2, the configuration modules 215 are arranged such that CM215-f forms the top level of the tree structure, CM215-a, 215-b, and 215-c form the bottom level, and CM215-d and 215-e are located in the tree structure between the top and bottom levels. However, the configuration modules 215 are connected to each other in an operable and communicative manner via the API 230. In some implementations, in a tree structure (e.g., as shown in Figure 2), configuration modules 215 can communicate with other configuration modules 215 at adjacent tree levels (one level above or below). However, in other topologies (e.g., mesh structure or peer-to-peer structure), any two configuration modules 215 within the distributed controller 210 can be directly connected to each other and communicate.

[0058] In some implementations, each configuration module 215 may be an external utility that configures one or more corresponding TSN blocks 202, or it may be configured as a software module within a TSN block 202. Each configuration module 215 may be configured to determine configuration data, including the TSN schedule for one or more data flows transmitted through the TSN block 202, and provide it to the TSN block 202 controlled by the configuration module 215. The configuration modules 215 may exchange information with each other using a standardized API 230. The exchanged information may include information about the cycle time of the TSN system (e.g., supported ACTs including each discrete level of ACT buckets corresponding to a particular data flow, maximum / minimum cycle time), configuration data including transmission schedules for one or more TSN blocks 202 (including time offsets / duration / resources for transmission), and information for resource allocation requests or responses to requests. In some implementations, one or more configuration modules 215 may 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 to 215-f may be implemented as part of or within the control plane functions (e.g., SMF126) and / or user plane elements or functions (e.g., 5G transport network 202-3) of the 5G system 106. For example, SMF126 may be configured to support the functions of CUC114 and / or CNC112. In some implementations, the 5G transport network 202-3 may be configured to support the functions of CNC112.

[0059] In some implementations, each configuration module (CM) 215 receives some or all of the parameter set (described above) of the TSN block 202 from the ICI 406 of the TSN block 202 controlled by the CM 215. The CM 215 also receives information about the data flow configured via the TSN block 202 from other entities in the system 200 via the API 230. As a non-limiting example, the data source 204 and / or data destination 206 provide the CM 215 with data flow requirements 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 may allow the user to define a set of data flows to be configured via a user interface. As used herein, the data flow information may include, or define, a set of data flows, data streams, transmit paths (predetermined or otherwise adapted), or similar, to define the desired TSN communication path between the data source 202 and the data destination 206. A non-exclusive set of examples of data flow information includes maximum allowable latency, data rate, data frame size ("payload"), data frame destination, bandwidth allocation gap, etc., or a combination thereof.

[0060] At a minimum, based on the received dataflow information and the parameter set for the TSN block 202, the CM215 determines a “solution” (or configuration data), which indicates how to process each dataflow through the TSN block 202. This solution may include time-aware schedules, polysingle rules, etc., as cited in U.S. Patent Application No. 17 / 100,356, which is incorporated herein by reference in its entirety. The CM215 may transmit this solution or configuration data to the TSN block 202 via the ICI406. The TSN block 202 may then execute this solution and transmit data for each flow according to the configuration. In some implementations, the same System Modulo Theory (SMT) solver may be used at each level of the CM215 tree structure as an exemplary process for causing the distributed CM215 to compute a solution, where the dataflow and its requirements are expressed as constraints, and a linear programming technique is used to find a feasible solution. Solutions from lower levels of the CM tree are input as used resources one level higher in the CM tree (represented again by constraints). This process is repeated until the top level of the CM tree is reached, where the global solution is determined.

[0061] In some implementations, different data sources (e.g., data source 204) and their applications operate with different cycle times or intervals. In this context, many data flows require different levels of temporal determinism depending on the data source and data destination (and their applications). In conventional TSN systems, a convergence cycle time (commonly known as the "management cycle time") is determined that operates for all data flows within the network. However, in some implementations of this disclosure, the integrated TSN-5G system can use a set of discretized / quantized cycle times within the network. Each data flow selects and operates within one of the available quantized cycle times. Scheduling in the TSN-5G system 100 for scheduled transmissions can be based on a set of quantized / discrete cycle times. As an example, the integrated TSN-5G system 100 can restrict the available stream intervals and therefore the corresponding cycle times to a set of discrete values, including but not limited to 1, 10, 100, and 1000 milliseconds. Similarly, the requirements for streams or data flows can be restricted. For example, the requirement for jitter (packet delay variation) may be restricted to a given set of discrete values, including but not limited to 1, 10, 100, and 1000 microseconds. In some implementations, different sets of discrete values ​​may be used depending on the application and use case supported by the integrated TSN-5G system. For example, geographically distributed systems may use discrete cycle times on the order of milliseconds. In yet another example, a system restricted to a local factory may use discrete cycle times on the order of microseconds. The elements of this set of discrete cycle times can be regularly or irregularly spaced, or follow other statistical distributions (including but not limited to logarithmic, linear, and Gaussian distributions), but they cannot be returned to a continuous set of cycle times. In other implementations, the set of cycle times is standardized so that every TSN block has a cycle time that is the product of elements selected from a small set of common primes.This allows all combined cycle times to be easily calculated by the TSN scheduler, resulting in a single common network cycle time.

[0062] Each TSN block in an integrated TSN-5G system may support a set of cycle times (the set containing one or more cycle times). CM215 configures the TSN-5G system 106 or 200 to enable scheduled transmission of data flows traversing TSN blocks 202 operating with different cycle times. In some implementations, TSN blocks 202 may be required to operate with compatible cycle times. Compatible means that the cycle times are integer harmonic of each other's periods. If an application requires intervals that do not directly map to the set of available discrete cycle times across the entire set of TSN blocks 202 through which a flow traverses, CM215 may adapt to the nearest available cycle time. The nearest available cycle time is an integer multiple or integer divisor of the available cycle time. During the configuration process, CM215 may exchange information about supported quantized / discretized cycle times with each other. In this case, the disclosure enables separate TSN-5G systems to create feasible configurations for a large number of data streams / flows. Without quantized cycles / intervals, the setup typically requires significant computation time, which can even hinder the discovery of a viable solution.

[0063] In some examples, each integrated TSN-5G network slice in a 5G system 106 may have a predefined set of supported cycle times and jitter boundaries. In some examples, the network slices may be finer in granularity than a typical 5G network slice according to 3GPP specification 23.501, which is incorporated herein by reference. In some implementations, a TSN-5G system 106 or 200 may be sliced ​​based on TSN cycle time. For example, a 5G network supporting multiple critical services may have URLLC slices dedicated to the periodicity of the applications and their streams. For example, a service with an application operating with a period of approximately 1 millisecond may have a dedicated slice operating with a cycle time of 1 millisecond. Similarly, services and applications operating with a period (or interval) of 100 milliseconds may have a dedicated slice in an integrated TSN-5G system operating with a cycle time of 100 milliseconds. Such cycle time slices improve both the speed of configuration and overall network performance. In some implementations, the TSN block 202 exposes the supported cycle times for a given slice to the respective CM215 via the ICI406. The CM215 may exchange the supported cycle times of the managed TSN blocks with each other via the configuration module API 230 to create a configuration solution for the sliced ​​TSN-5G system.

[0064] In some implementations, the solution or configuration data determined by CM215 includes, but is not limited to, a set of settings, timings, commands, controls, instructions, etc., or combinations thereof, for operating each TSN block 202 according to the characteristics of the TSN block 202 (e.g., characteristics defined by a parameter set). In some embodiments, the configuration data may include specific transmission information for individual data frame transmissions to one or more TSN blocks 202 or for collective (e.g., "global") data frame transmissions. The transmission information may include timing information regarding the transmission of data frames. In one or more embodiments, the data frame configuration data may include a transmission start time. For example, the transmission start time may be the time when the transmission of data frames begins from each TSN block 202. In one embodiment, the transmission of data frames may be initiated as a data flow by selectively opening the gates of each TSN block 202 to send the data frames toward a destination node (e.g., another TSN block 202). Conversely, the transmission of data frames can be stopped or prevented by selectively closing the gates of each TSN block 202 for sending data frames. Configuration data may define or assign specific paths or links that enable communication between each TSN block 202 and other nodes, and transmit data flows along such paths or links. Configuration data may also define the duration of transmission for each data flow from each TSN block 202. In one embodiment, the duration of data flow transmission may be defined by the period between the selective opening of a gate (i.e., selective opening for transmitting a data frame) and the selective closing of a gate at each node (i.e., selective closing to stop the transmission of a data frame to the destination node).

[0065] In conventional TSN systems, the TSN schedule is expressed as an absolute time offset in a periodic cycle in which TSN blocks are instructed to transmit their data. However, for a 5G system 106 composed of components from multiple vendors, this can be too restrictive. In some implementations, a deadline-based schedule is determined by CM215 and provided along with configuration data. The deadline-based schedule may instruct TSN blocks 202 to transmit the data of the configured data flow by the deadline (expressed as an absolute time in a periodic cycle). In some implementations, a delay-budget-based approach instructs TSN blocks to transmit the data frames of the configured data flow within a delay budget. Thus, in a delay-budget-based approach, TSN blocks 202 are required to transmit data frames arriving at the input port to the output port within a certain period. In such a scheme, it is not necessary to time-synchronize all TSN blocks 202. In some implementations where TSN block 202 is configured under rate constraints, TSN block 202 is configured to transmit data frames of a given data flow such that the average or peak transmission rate (bits per second) does not exceed a set value (a set value according to configuration data from CM215).

[0066] In some 5G systems, a TSN block may be a set of shared resources made available by network slicing based on service profiles that limit network latency and periodic cycles, including but not limited to delay / budget. In such implementations, there may be two levels of scheduling, where 5GS TSN-AF allows for the configuration of TSN blocks 202 as shared resources, in addition to slice-level TSN scheduling. In either case, configuration attributes such as resource identifiers may identify the TSN block for the appropriate configuration. As an example, a service provider may have multiple service profiles with specific periods, and multiple tenants of the service provider may utilize the same TSN block specified by the 5GS TSN-AF configuration to perform TSN flow aggregation. In some implementations, a service provider may provide a set of non-shared TSN blocks, in which only a single layer of service profiles may exist. Device-specific operational resource sharing modes / request resource sharing modes may be available to CNC112 via TSN-AF.

[0067] As an example of implementing the deadline / delay budget approach by TSN block 202, when a data frame arrives at the entry port of TSN block 202, TSN block 202 records the arrival time of the data frame using the local clock. TSN block 202 then identifies that the frame belongs to a configured data flow and may then start a countdown timer equal to the configured delay budget for that data flow. Using the transmit module 408, TSN block 202 may prioritize the transmission of the data with the shortest remaining time. If the packet timer expires before the packet is transmitted, the event is recorded as a transmission failure and taken into consideration in the monitoring metrics by the recording module 410.

[0068] In some implementations, with respect to scheduled transmissions between TSN block 202-1 corresponding to UE118 and TSN block 202-2 corresponding to RAN120, "extended" allocation (allocation and transmission) of uplink and downlink transmissions between UE118 and RAN120 may be performed to satisfy the schedule assigned to TSN block 202-1 corresponding to UE118 by CM215-a. In some implementations, when instantiating the TSN schedule, CM215-a may take into account the buffer state and radio state of UE118 reported by RAN120 and adjust or report any necessary changes in the requested schedule. In some other implementations, CM215-a may send real-time feedback on the radio state received from RAN120 to a master CM, e.g., CM215-d. This feedback loop may support recalculating the TSN schedule to satisfy the packet delay budget in this particular TSN block or in TSN blocks on a given end-to-end path.

[0069] In this implementation, link quality is monitored, and CM215-a may continuously adjust the radio resources of configuration data to meet the transmit schedule. Radio resources include, but are not limited to, logical channels, transmit power, and UE-specific slot lengths. In some implementations, static allocation of fixed / deterministic uplink and downlink slots may be performed for a given UE118, for example, so that all UEs connected to a given RAN slice are given a scheduled transmit slot. Using 5G native air scheduling, it may be determined whether the transmit from UE118 will meet the transmit deadline. If not, UE118 may request elevated access to RAN120 to achieve the scheduled transmit. In some implementations, scheduling in the 5G system 106 may be based on a set of quantized / discrete cycle times, which include a management cycle time of at least 100 milliseconds. According to this technology, the radio link between the UE (e.g., represented by TSN block 202-1) and the RAN (e.g., represented by TSN block 202-2) may be sliced ​​based on cycle time. In some implementations, the uplink and downlink between TSN block 202-1 and TSN block 202-2 may have radio resources allocated to each network slice based on the slice's cycle time. For example, a 1-millisecond cycle time slice requires radio resources (channel, airtime, etc.) capable of transmitting data at a rate of 1 millisecond.

[0070] In some implementations, 5G resource elements (e.g., frequency and time slots) may be scheduled to meet the latency requirements of TSN flows, in addition to the traffic priority requirements in “standard” 5G scheduling. More specifically, 5G time slots can be allocated to TSN flows so that messages in the TSN flow are transmitted with an appropriate cycle time offset (phase) and within the time limit (TSN window time) required by the TSN schedule. In this case, the 5G scheduler differs from a “conventional” TSN Ethernet port in that multiple messages can be output simultaneously if they are transmitted on different frequencies. In some embodiments, the 5G system 106 may transmit multiple copies of a message on different frequencies to increase the probability of meeting the transmit schedule and / or transmit deadline if the RF channel condition is poor.

[0071] To ensure reliable data transmission in system 200, redundant flow paths may be implemented. The unaggregated TSN block 202 of the 5G system 106 allows for better handling of errors (delays, drops, or corrupted frames). In some implementations, UE118 may initiate two redundant, non-intersecting PDU sessions for UPF122 for redundancy, in which case 5GC may configure dual connectivity for NG-RAN according to 3GPP 38.300. In some other implementations, FRER may be used between some TSN blocks 202 but not between others. For example, redundant streams may be implemented at the air interface between UE118 (TSN block 202-1) and RAN120 (TSN block 202-2), coupled at RAN120, and then, if necessary, split again in the core network (TSN blocks 202-3, 202-4). As shown in Figure 1, the current redundancy requirement according to 3GPP 23.501 is the most isolated path between UE118 and UPF122. However, according to this technology, it is not necessary to establish redundant isolated paths across the entire 5G system, but rather they can be implemented only for a portion of the 5G system. For example, for the radio interface between UE118 and RAN120, the redundancy requirement may specify that the two paths should be on different frequencies, different MIMO channels, or different time slots. In some examples, this disclosure enables flexible use of redundancy, including, but not limited to, support for three or more data paths, merging and splitting data flows between TSN blocks, and TSN blocks with varying degrees of redundancy capability.

[0072] The concept of dividing 5GS into multiple TSN blocks (as described above with respect to Figure 2, for example) may improve security if strict scheduling can prevent malicious traffic flows between these blocks. However, operating 5GS as multiple TSN blocks can introduce security vulnerabilities, primarily through configuration. Specifically, a TSN user may become aware of the details and connectivity of an internal 5GS that affect other users sharing the same physical and logical infrastructure. This may occur during the necessary TSN network discovery phase (e.g., via information returned by the Link Layer Discovery Protocol). A TSN user may also misconfigure either their own configuration or that of another user. This can be partially addressed by using the concept of a secure subtree in NETCONF, where a user has a limited view of their own data model subtree. A 5G system may inherently have the concept of isolated network slices, depending, for example, whether the TSN is implemented virtually (via software) or physically (via hardware). Infrastructure providers may need to impose restrictions on what physical and logical capabilities are exposed to each TSN user. This may be done through the 5G network exposure function. This disclosure provides a solution to security issues by using a “virtual TSN block.” A virtual TSN block is an internal 5G TSN block that contains only the functionality provided by the user’s 5G network slice. In other words, the user can only view and configure the TSN block information exposed via the 5G network slice, and nothing more. In this sense, the internal 5G TSN block is the intersection of the set of information contained in the internal TSN block and the 5G network slice provided to the user.

[0073] In some implementations, the IETF DETNET standard (provided by the IETF: “Deterministic Networking Working Group” (https: / / datatracker.ietf.org / wg / detnet / about / )) can be implemented or integrated into 5GS to interconnect small Ethernet islands that comply with TSN. 5GS may utilize DETNET to enable the forwarding of TSN messages at Layer 3 (IP layer) (rather than Layer 2). Assuming such a system, the technologies discussed in this disclosure include 5GS supporting DETNET edge nodes, relay nodes, and transit nodes that interconnect spatially isolated TSN networks to create larger composite TSNs over 5G. All aspects of the integrated TSN-5G systems provided in this disclosure are applicable to (but not limited to) TSN islands in 5G DETNETs, ​​and in particular to TSN blocks in isolated TSNs.

[0074] DETNET consists of the following components: (1) TSN end systems (IEEE-compliant end systems that communicate with DETNET edge nodes), (2) DETNET edge nodes (which process TSN frames for DETNET), (3) DETNET relay nodes, and (4) DETNET transit nodes (which provide congestion avoidance for time-sensitive messages). Because DETNET is routing rather than bridging, it enables routable TSN messages between TSN LANs. Essential TSN Ethernet frame information is carried or reconfigured during transport between LANs. DETNET adds sublayers to implement higher-layer functions, namely (1) the DETNET Services sublayer (a sublayer that provides DETNET services (e.g., service protection) to the higher layers of the protocol stack and applications) and (2) the DETNET Transport sublayer (a sublayer that provides DETNET services (e.g., explicit routing and congestion protection) in the lower network for DETNET flows and encapsulates TSN Ethernet frames). DETNET routing involves modifying the IP header according to standard router behavior, for example, in Time-To-Live (TTL) processing. TTL specifies the maximum time a routable IP message is allowed to live and is explicitly linked to the maximum latency requirements of the TSN.

[0075] The DETNET component may reside within any computational element of 5GS, specifically within the 5G MEC or core. Therefore, in one implementation, 5GS can be a fully compliant DETNET interconnecting TSN LANs. To provide determinism, the DETNET may reserve data plane resources for DETNET flows at some or all of the intermediate nodes along the flow path. The DETNET may provide explicit routes for DETNET flows. The DETNET may distribute data from DETNET flow packets over time and / or space to ensure data delivery for each packet despite path loss. Thus, as described above, the TSN CNC / DNC and scheduler may require interaction with the DETNET, specifically the ability to configure flow paths (including redundant flow paths) and TTLs, and the ability to obtain routing latency and jitter. The required level of determinism in 5G DETNETs can be achieved using TSN traffic shapers, time-aware shaping, and network calculus.

[0076] Furthermore, hybrid 5GS, which is partially TSN (Layer 2) and partially DETNET (Layer 3), may coexist and interoperate. In such cases, the DETNET portion of the network may be treated as a TSN block (or multiple TSN blocks) 202, as described above.

[0077] Furthermore, for caching within 5GS to minimize latency and improve determinism for TSN applications, the amount, location, and naming of information within 5GS can be managed to enable fast, short proximity access to minimize jitter. Each piece of information can be given a cryptographic signature to enhance security and provide access to information stored in each component of 5GS, such as MEC, via a hash of the cryptographic signature. Cache transfer units track each data request to enable optimal transfer, placement, and service of cached data. TSN CNC / DNC and schedulers may calculate where to place cached information within the network (specifically 5GS) to maximize access between 5G applications and minimize jitter (variation in packet delay).

[0078] Real-time MEC applications typically have clearly defined characterizations of their operation. 5G MEC applications in the cloud (cloud computing) and fog (fog computing) can be broken down into microservices with hard real-time constraints provided to the TSN scheduler. These constraints may be the longest (worst-case) time to complete a call to a service, or a clearly defined statistical description according to the requirements of a network calculus for an arrival curve or service curve. In some implementations, microservices may be chained together to create a complete MEC application. By breaking down computations into a series of smaller microservices, each service can be better controlled and managed, providing greater determinism. Each microservice can be abstracted as an internal TSN block consisting of deterministic inputs, outputs, schedulable operations, and coordination with the 5G-TSN AF. Microservices may reside in the same processing system or in spatially different processing systems interconnected by TSN scheduling communications.

[0079] Such hard real-time processing may include the functions of the 5G MEC and 5G core. Messages are input to and output from MECTSN blocks according to a deterministic schedule computable by the TSN scheduler. Note that such TSN blocks are called "computational TSN blocks". Given that the messages generated by the MEC, their corresponding sizes, and transmission times may vary depending on the computational complexity, processing load, and application state of the MEC processing task, the TSN scheduling component can utilize an internal model of the MEC processor (i.e., a simulation, emulation, or purely analytical model, or a hybrid model thereof) for the purpose of TSN scheduling (also called a 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, as well as for any cloud processing required by the real-time application, in which case the 5G core and cloud processing are similarly modeled by the TSN scheduler. The TSN schedule can dynamically recalculate the schedule as needed to maintain the determinism required for 5G TSN real-time MEC / cloud applications as the effective processing rate, and therefore the output message transmission time, changes. The TSN scheduler can provide feedback to application developers (and for management and deployment) regarding the optimal location (UE, MEC, cloud) of each processing component of a real-time 5G application, taking into account link speed, variability, processing capacity, available memory, etc. The TSN system may employ a gate-based approach or a rate control mechanism such as leaky bucketing, and may use any number of optimization techniques or network calculus to determine a feasible schedule.Therefore, the complete flow of a TSN application includes not only the end-to-end path of a particular message through the network, but also the complete processing path through all compute TSN blocks (microservices) that act on the information within the message. The redundant path in IEEE 802.1CB can be configured via either redundant or parallel compute TSN blocks (microservices). In this invention, it should be possible to visualize the complete real-time processing activity encoded in the TSN schedule, where compute TSN blocks appear as Ethernet bridges in that they can process messages or generate new messages to be output according to a deterministic schedule. MEC applications are configured to use TSN flows (to participate as a TSN talker or listener) using NETCONF, RESTCONF, or a RESTful API. Messages defined in the protocols described above contain IEEE 802.1Qcc information necessary to configure the TSN flows used by the MEC application. Furthermore, MEC applications are designed to move from one MEC platform to another, and the RESTful API is defined to query the TSN configuration of the current platform to ensure that it has the necessary deterministic communication requirements, particularly latency and jitter. It also has a RESTful API that contains the information necessary to notify the TSN CNC of the new location and the information necessary to dynamically reschedule TSN traffic to the new location. As mentioned above, IEEE 802.1CB may be used to establish redundant TSN flows to anticipated locations where the MEC application may migrate. A TSN scheduler, also known as a CNC or Distributed Network Configurator (DNC), can be an MEC application that provides scheduling-as-a-service and configuration-as-a-service for 5G TSNs, which is useful for dynamic rescheduling where low latency is required.

[0080] A TSN application may send a timing performance profile query microservice request for the purpose of determining statistics regarding processing time. In response to such a request, the microservice executes the request and returns both the result and the timing performance profile. The timing performance profile includes at least the network start and end times of the microservice call, and optionally the start and end times of all called sub-functions. The information may also include the average MEC processor load during the timing performance profile. The timing performance profile may be used by a TSN application to refine TSN scheduling when the microservice needs to handle TSN traffic flows. The timing performance profile may be taken during production and the output from the profile may be used as normal, or it may be taken as a special test sample before production. The timing performance profile information may be used to determine which MEC hardware to adopt for current and future operations, and may also be used as constraint information for the TSN scheduler.

[0081] This disclosure provides further novel aspects, including (1) TSN-scheduled 5G core functions, (2) ensuring that the central processing unit is directly time-synchronized with the Ethernet hardware time stamping mechanism, (3) enabling TSN scheduling of specific 5G network functions and processes, (4) adding new time-aware programming functions, e.g., time-based event processing, and (5) integrating time-based conditional processing, e.g., real-time programming implemented via YANG configuration of microservice scheduling to implement service chaining (see https: / / www.rfc-editor.org / rfc / pdfrfc / rfc7758.txt.pdf for an example of YANG-scheduled operation).

[0082] Furthermore, a LinkDelayStatistic cumulative distribution function data model (implemented as a YANG model) can be implemented within a TSN-5G system 106 or 200. In such an implementation, the wireless link can collect information and supply it to the CNC scheduler, which can then use this information to schedule the variable-speed link. The LinkDelayStatistic YANG model can also provide information on whether the link delay is stationary and ergodic. The scheduler can use this information to predict the future based on a given sample and create an accurate schedule. The CNC can then use this knowledge for each TSN block and develop the best possible TSN traffic shaping or gate scheduling, including determining the results using network calculus.

[0083] This disclosure also envisions a virtualized network function (VNF-TSN) that can exist as software within a 5G system. Dedicated processor hardware may be required to support real-time operation. In some implementations, the TSN may be provided as a software-defined TSN (SDN-TSN) and a 5G TSN as a service (5G TSN-as-a-service). In some implementations, the VNF-TSN may be configured within all 5G subcomponents (TSN blocks), such as the UE, radiohead, CU / DU, RAN, MEC, and core. As described above, microservices may be linked as part of the TSN scheduling. Each microservice can expose its service time characteristics to the TSN schedule. Service is part of the delay, but may vary more than the communication link. In such implementations, service is the link in the integration of microservices by TSN scheduling. Processing delays can be incorporated using network calculus. The TSN input provides a clear arrival curve. Processor execution time provides the service curve (5G equipment is assumed to have well-characterized processing times).

[0084] In another aspect of this disclosure, a time-aware MEC platform is defined as a platform that operates as a PTP client (compliant with 802.1AS end stations) and, if necessary, as a PTP bridge (compliant with 802.1AS bridges). PTP bridges, along with network bridging capabilities, are required in virtualized MEC platforms that run multiple slices (OS, VMs, containers) in parallel. Typically, virtual bridges / switches are used in virtualized computing platforms. This disclosure defines a TSN-enabled virtual switch that includes time awareness. The time-aware PTP client in the MEC platform runs a PTP state mechanism with a servo to synchronize a grandmaster clock in the network with locally available clocks. Furthermore, the MEC platform synchronizes the system clock to the PTP clock, where the system includes the operating system, network stack, application stack, or other software and hardware elements that utilize the clock. This allows each MEC application to operate on synchronized PTP time. For example, an MEC host operates this PTP client, providing synchronized time (referred to as system / host time) to all MEC applications via the virtualized infrastructure. In another example, all MEC applications may run separate instances of PTP clients connected to the host via a time-aware bridge.

[0085] As a configuration interface, 3GPP23.501 specifies a centralized configuration model in which the CNC configures 5GS as a time-aware bridge. Similarly, the MEC platform should allow the CNC to be configured as a time-aware end station or time-aware bridge. This MEC may support configuration using the 802.1Qcw YANG model for TSN functions, including time-aware shaping, forwarding, and frame duplication and elimination for redundancy. Furthermore, the MEC host may have a CUC component that provides the CNC with data flow requirements for the resident application using the 802.1Qcc interface. The MEC may also provide the CNC with information about the MEC's ​​TSN functions so that the CNC can accurately model the MEC. For example, the MEC may present itself as a TSN end station that originates a certain set of data flows. The CNC then appropriately models the MEC in the network and generates the correct configuration. The MEC shall work with the OS and applications to support the identification of data streams. Specific functions will vary depending on the TSN awareness of the MEC components. Non-TSN-enabled applications on MEC hosts require IP stream identification in the MEC bridge.

[0086] TSN fronthaul / backhaul (e.g., TSN block 202) may connect directly to the MEC and provide deterministic input to the MEC. However, MEC applications are intended to continuously migrate to the edge of the 5G network, or intuitively "float," in order to potentially remain closest to mobile clients. Therefore, MEC applications requiring determinism specify a minimum acceptable packet delay variance (MPDV) threshold. MPDV may be invoked in the specifications of all MEC applications and may limit the location of feasible applications to MEC platforms that exist as TSN blocks within 5GS. Applications must ensure that appropriate TSN stream identification and transformation rules are implemented on the new MEC platform (which may be a single processor or a subnetwork of processors) so that MEC talker / listener message frames are properly tagged and processed. MEC applications may want to carry their own configuration instructions, where possible, to "self-install" when migrating to a new MEC platform. Furthermore, by employing a load balancing mechanism, it can be ensured that users are not overwhelmed by the set of MEC applications, and that MEC applications are distributed in an optimal manner. In other scenarios, redundant MEC platforms and applications may be instantiated, and / or MEC applications may migrate, not due to mobility but due to noise. Multiple MECs may also be connected as a TSN redundant system.

[0087] Figures 6A and 6B show an integrated TSN-5G system 600 (similar to system 200) including a TSN block 605 (similar to TSN blocks 202-N) representing or corresponding to an MEC module. The TSN block 605 is configured as a data source / sink (i.e., a TSN end station) but is located within the 5G system 106 rather than at the edge of the 5G system 106. The TSN block 605 may be configured as a bridged end station.

[0088] Referring to Figure 8, an application data stream can span multiple integrated TSN-5G systems 805 and 810. In this case, the TSN blocks may be geographically distributed to interconnect two or more 5G systems using a TSN-compatible transport 820, which includes but is not limited to a 5G backbone, private network tunnel, or other wide-area network. In the present invention, each TSN block is comprised of a CM215. In some implementations, configurations across two TSN-5G systems 805 and 810 may be coordinated via a CNC 112. In some other implementations, the CM215s between the two TSN-5G systems 805 and 810 may communicate directly. In some implementations, multiple CUCs and CNCs may be used to acquire user requirements and generate TSN-based solutions and techniques provided in this disclosure (e.g., TSN schedules, transport instructions, etc.).

[0089] Figure 7 shows an electronic system 700 in which one or more implementations of the present technology may be carried out. The electronic system 700 may be part of the TSN block 202 and / or configuration module 215. The electronic system 700 may include interfaces for various types of computer-readable media and various other types of computer-readable media. The electronic system 700 includes a bus 708, one or more processing units 712, system memory 704 (and / or buffers), ROM 710, permanent storage 702, input device interface 714, output device interface 706, and one or more network interfaces 716, or subsets and variations thereof.

[0090] Bus 708 collectively represents all system buses, peripheral buses, and chipset buses that communicate with a number of internal devices of the electronic system 700. In one or more implementations, bus 708 communicates with one or more processing units 712, ROM 710, system memory 704, and permanent storage 702. From these various memory units, one or more processing units 712 obtain instructions for performing the disclosed processing and data to be processed. In various implementations, one or more processing units 712 may be a single processor or a multi-core processor.

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

[0092] In one or more implementations, a removable storage device (such as a floppy disk, flash drive, and corresponding disk drive) can be used as the permanent storage device 702. The system memory 704 may be a read-write memory device, similar to the permanent storage device 702. However, unlike the permanent storage device 702, the system memory 704 may be a volatile read-write memory, such as random access memory. The system memory 704 may store any of the instructions and data required by one or more processing units 712 at runtime. In one or more implementations, the processes of this disclosure are stored in the system memory 704, the permanent storage device 702, and / or ROM 710 (each implemented as a non-temporary computer-readable medium). From these various memory units, one or more processing units 712 obtain instructions for executing the processes of one or more implementations and the data to be processed.

[0093] Bus 708 is also connected to input and output device interfaces 714 and 706. Input device interface 714 allows a user to communicate information to the electronic system 700 and select commands. Input devices that may be used with input device interface 714 may include, for example, an alphanumeric keyboard and a pointing device (also called a "cursor control device"). Output device interface 706 may allow, for example, the display of images generated by the electronic system 700. Output devices that may be used with output device interface 706 may 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 may include a device that functions as both an input and output device, such as a touchscreen. In these implementations, the feedback provided to the user can be any form of sensory feedback, including visual, auditory, or haptic feedback. Furthermore, user input can be accepted in any form, including voice, speech, or haptic input.

[0094] Finally, as shown in Figure 7, the bus 708 connects the electronic system 700 to one or more networks and / or one or more network nodes via one or more network interfaces 716. Thus, the electronic system 700 can be part of a computer network (such as a local area network (LAN), wide area network (WAN), intranet, or internet). Any or all components of the electronic system 700 can be used in conjunction with the present disclosure.

[0095] These functions can be implemented in computer software, firmware, or hardware. This technology can be implemented using one or more computer program products. Programmable processors and computers can be contained in or packaged as mobile devices. These processes and logic flows can be performed by one or more programmable processors and one or more programmable logic circuits. General and dedicated computing and storage devices can be interconnected via communication networks. The functions disclosed herein may be implemented using quantum computing, pulse-coupled oscillation (PCO) / ising computing.

[0096] Some implementations include electronic components such as microprocessors, memory devices, and memory that store computer program instructions in machine-readable or computer-readable media (also called computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, read-only compact disks, recordable compact disks, rewritable compact disks, read-only digital multipurpose disks (e.g., DVD-ROM, dual-layer DVD-ROM), various recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, miniSD cards, microSD cards, etc.), magnetic and / or solid-state hard drives, read-only and recordable Blu-ray® discs, ultra-high-density optical discs, other optical or magnetic media, and floppy disks. Computer-readable media can store computer programs that can be executed by at least one processing unit and contain instruction sets for performing various operations. Examples of computer programs or computer code include files containing machine code generated by a compiler, and high-level code executed by a computer, electronic component, or microprocessor using an interpreter.

[0097] The above discussion primarily refers to microprocessors or multicore processors that run software, but some implementations are run by one or more integrated circuits, such as application-specific integrated circuits or field-programmable gate arrays. In some implementations, such integrated circuits execute instructions stored within the circuit itself.

[0098] As used herein and in the claims of this application, the terms “computer,” “server,” “processor,” and “memory” all refer to electronic or other technological devices. These terms exclude persons or groups of persons. In this specification, the terms “display” or “display” mean to display on an electronic device. As used herein and in the claims of this application, the term “computer-readable medium” is strictly limited to tangible physical objects that store information in a form readable by a computer. These terms exclude all wireless signals, wired download signals, and other transient signals.

[0099] To enable interaction with the user, the implementation of the subject matter described herein can be carried out on a computer equipped with a display device for displaying information to the user (e.g., a cathode ray tube or LCD monitor) and a keyboard and pointing device (e.g., a mouse or trackball, a means by which the user can provide input to the computer). Interaction with the user can also be provided using other types of devices. For example, the feedback provided to the user may take the form of visual, auditory, or haptic feedback, and input from the user may be accepted in any form, including acoustic, voice, or haptic input. The computer can also interact with the user by sending documents to and receiving documents from the user's device. For example, the computer can interact with the user by sending a web page to a web browser in response to a request received from a web browser on the user's client device.

[0100] Embodiments of the subject matter described herein can be implemented in a computing system including a backend component (e.g., a data server), a computing system including a middleware component (e.g., an application server), a computing system including a frontend component (e.g., a client computer having a graphical user interface or a web browser that allows a user to interact with an implementation of the subject matter described herein), or a computing system including one or more of these backend components, middleware components, or frontend components in any combination. The components of the system can be interconnected by digital data communication in any form or medium, such as a communication network. Examples of communication networks include LANs and WANs, internetworks (e.g., the Internet), and peer-to-peer networks (e.g., ad-hoc peer-to-peer networks).

[0101] According to aspects of this disclosure, a radio network (e.g., a 5G network 106) is provided that is configured to support time-sensitive deterministic communication based on a TSN mechanism. The radio network may include a plurality of discrete CN components, e.g., components 110, 118, 120, 122, 124, 126, 140, 190, etc., as described above. Each CN component may be configured to provide a separate function for data communication from a source device (e.g., 102) to a destination device (e.g., 104) over the radio network (e.g., 106). For example, a processor (402) is configured to configure at least one of the plurality of CN components (e.g., 140) using a TSN parameter set of the TSN mechanism, and at least one of the plurality of CN components supports time-sensitive deterministic communication in the TSN network as a TSN block (e.g., 202-3) according to the TSN parameter set. At least one of the multiple CN components, configured by the set TSN parameter set, is a 5G transport network channel 140 connecting RAN120 and UPF122. In some implementations, the processor is configured to configure each of the multiple CN components by the respective TSN parameter set of the TSN mechanism, and each of the multiple CN components supports time-sensitive deterministic communication in the TSN network as a corresponding TSN block, according to its respective TSN parameter set.

[0102] The wireless network may further include a configuration module (e.g., 110 or 210) configured to determine a TSN parameter set for at least one of several CN components. The TSN parameter set may include one or more of the following: TSN stream identification information, transmission schedule, deadline or delay budget, filtering settings, and redundancy scheme. In some implementations, the processor is configured to allocate one or more CN resources for data transmission by at least one of the several CN components according to the transmission schedule, or the deadline, or the delay budget. In some implementations, the configuration module is configured within a control plane component (e.g., SMF126) of the several CN components.

[0103] In some implementations, the configuration module is configured to determine the TSN parameter set based on one or more CN attributes assigned to at least one of several CN components, where one or more CN attributes relate to discrete functions provided by at least one of the several CN components.

[0104] The processor may be configured to monitor data transmission by at least one of several CN components, report changes to the TSN parameter set or one or more CN attributes to a configuration module, and update the TSN parameter set based on the reported changes.

[0105] According to aspects of the present disclosure, a radio network (e.g., a 5G network 106) is provided that is configured to support time-sensitive deterministic communication based on a TSN mechanism. The radio network may include a plurality of discrete CN components, e.g., components 110, 118, 120, 122, 124, 126, 140, 190, etc., as described above. Each CN component may be configured to provide a separate function for data communication from source devices (e.g., 102, 204) to destination devices (e.g., 104, 206) over the radio network (e.g., 106). The radio network includes a plurality of configuration modules (e.g., 210, 215) interconnected in a predetermined arrangement (e.g., via 230), and each of the plurality of CN components is configured to provide a set of TSN parameters specific to each of the plurality of CN components, according to a specific set of corresponding TSN parameters, to support time-sensitive deterministic communication as a corresponding TSN block in the TSN network. Multiple configuration modules may be connected to each other in a hierarchical, mesh-like, star-like, tree-like arrangement, or a combination thereof.

[0106] As illustrated in relation to Figure 2, a corresponding TSN block (e.g., 202-3) may be configured to receive a unique set of corresponding TSN parameters from one of several configuration modules (e.g., 215-b and / or 215-c) assigned to the corresponding TSN block. The unique set of TSN parameters may include one or more of the following: TSN stream identification information, transmission schedule, deadline or delay budget, filtering settings, and redundancy scheme.

[0107] In some implementations, at least one of several configuration modules is configured as CUC114 and / or CNC112 and implemented within the control plane's SMF126 and / or within TSN block 202-3 (a block representing the TSN configuration for the 5G transport channel 140). In various aspects of this disclosure, in implementations where the 5G transport channel 140 is configured with TSN parameters, RAN120 and UPF122 may be configured to support the functions of a TSN talker and / or listener as defined in IEEE P802.Qdj[xx], respectively. SMF126 / CUC114 may be responsible for the conversion of 5GS parameters from and to the parameters of IEEE P802.1Qdj[xx]. SMF126 / CUC114 may be configured to communicate with the TSN talker and / or listener in RAN120 and UPF122 and exchange datasets as defined in IEEE P802.1Qdj[xx]. In some implementations, during the establishment or modification of a QoS flow, the SMF126 / CUC114 creates a talker group and a listener group for each QoS flow, as defined in Appendix Ix and sent to the TSN CNC112. The TSN CNC112 uses the talker group and listener group as input to select a path in the TSN and calculate a schedule. The TSN CNC112 provides a status group to the SMF126 / CUC114. The SMF126 / CUC114 provides the status group to the TSN talkers and / or listeners in the RAN120 and UPF122. After receiving the status group, the TSN talkers and / or listeners send data to the N3 interface according to the status group's settings.

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

[0109] According to aspects of the present disclosure, a system (e.g., system 100 shown and described in relation to Figure 8) is provided. The system includes a first wireless network (e.g., 805) and a second wireless network (e.g., 810). The first wireless network includes a first plurality of CN components configured to provide discrete functionality for data communication over the first wireless network, at least one of the first plurality of CN components configured to provide time-sensitive deterministic communication according to a first TSN parameter set. The second wireless network includes a second plurality of CN components configured to provide discrete functionality for data communication over the second wireless network, at least one of the second plurality of CN components configured to provide time-sensitive deterministic communication according to a second TSN parameter set.

[0110] In some implementations, a TSN transport channel (e.g., 820) is provided, configured to facilitate time-sensitive deterministic communication of data exchanged between a first radio network and a second radio network, and is provided according to a third TSN parameter set. The TSN transport channel may be communicably connected to a first TSN translator of the first radio network (e.g., NW-TT at 805-122) and a second TSN translator of the second radio network (e.g., NW-TT at 810-122).

[0111] A part of the present disclosure provides a method comprising configuring at least one (or each) of a plurality of CN components of a wireless network (e.g., a 5G network) to have a TSN parameter set for a TSN mechanism such that at least one of a 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. At least one of the plurality of CN components may be a 5G transport network channel connecting the RAN and the UPF.

[0112] The method may further include, for example, determining a TSN parameter set for at least one of several CN components in one or more configuration modules. The TSN parameter set may include one or more of the following: TSN stream identification information, transmission schedule, deadline or delay budget, filtering settings, and redundancy scheme. The method may further include allocating one or more CN resources for data transmission by at least one of the several CN components according to the transmission schedule, or the deadline or delay budget. The method may also include monitoring data transmission by at least one of the several CN components, reporting changes to the TSN parameter set or one or more CN attributes to the configuration module, and updating the TSN parameter set based on the reported changes.

[0113] As described above, an integrated TSN-5G system may provide an API used to provide configuration data for each individual TSN stream within the TSN network, in accordance with the TSN specification (e.g., IEEE 802.1Q). In some implementations, the integrated TSN-5G system may employ one or more TSN functions (e.g., time-aware scheduling (TAS), stream-based filtering and policing (PSFP), periodic queuing and forwarding (CQF), etc.) in accordance with the TSN specification required for each individual TSN stream (e.g., IEEE 802.1Q, IEEE 802.1Qbv, IEEE 802.1Qci, etc.). However, configuration data shared from one configuration module to other configuration modules does not include or provide the configuration of TSN functions as required parameters for each individual TSN stream. Instead, TSN functions such as TAS, policing, and periodic queuing are determined by the network configuration module based on user input.

[0114] To address the aforementioned challenges in integrated TSN communication network systems, the technology provides a novel and improved interface or extended API 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 novel and improved interface or extended API between the CUC and CNC allows for a detailed description of per-stream requirements. In some embodiments, the requirements may include explicitly requesting the scheduling of streams in the network using a time-aware shaper or similar shaper, explicit requirements regarding latency, jitter, and loss, and explicit requests for filtering and policing streams in the communication network. Thus, the novel and improved interface or extended API can provide explicit and fine-grained definitions of stream requirements between the CUC and CNC. The new interface is configured to share TSN configuration parameters, functions, and / or requirements between the first and second configuration modules to implement TAS, policing, periodic queuing, etc., for each individual TSN stream communicated over the communication network. Therefore, configuration parameters and functions such as TAS, policing, and periodic queuing exist in addition to conventional parameters shared between conventional TSN configuration modules (e.g., CUC and CNC). In some embodiments, such additional configuration parameters may be used by a configuration module (e.g., CNC) receiving such parameters to determine whether to perform time-aware shaping or scheduling, whether to perform policing, etc., for a particular TSN stream on the communication network, and to configure a TSN network device (e.g., a bridge) to process that particular TSN stream. In some embodiments, the additional configuration parameters relating to TAS, policing, and periodic queuing functions may be Boolean parameters.

[0115] As described above, each network domain's CUC communicates with one or more CNCs within the same network domain via a new interface or extended API. Even in situations where it is necessary to share a subset of configuration data with other network domains to support TSN functionality or requirements for each TSN stream, such communication is limited to CUCs and CNCs within the same network domain. Therefore, a separate interface or API for sharing configuration data (including per-stream requirements) between configuration modules (CNCs) in multiple network domains is necessarily required to support data flows / streams between multiple domains (network domains) that interoperate in a standard manner. In some implementations, a network domain refers to a service provider or network owner that may have a specific period and different TSN configuration capabilities and can provide different services. However, because TSN streams flow through multiple network domains within the network from data source to data destination, configuration modules associated with multiple network domains (e.g., CUCs and / or CNCs) are required to communicate with each other to support time-sensitive deterministic communication of TSN streams flowing through multiple network domains.

[0116] To address the above issues, this technology provides a new interface or extended 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. It provides a new interface or extended API between two CNCs that enables the configuration of a TSN network including multiple network domains. In some embodiments, the new interface or extended API provides two functions. First, the new interface or extended API enables communication of stream requirements from a CUC in the first network domain to a CNC in the second network domain via the CNC in the first network domain. This is necessary because the CUC only communicates (stream requirements) with CNCs in the same network domain. A subset of these requirements may need to be communicated to other CNCs in other network domains. The new interface or extended API enables the configuration module (CNC) to adjust its configuration to meet the stream requirements. For example, if there is a latency budget and each configuration module (CNC) uses up part of the budget when scheduling each TSN stream through its own domain, that information needs to be shared via a new interface or an extended API. Combining these two functions allows the configuration of the entire communication network, including multiple network domains, to be tailored to the requirements of each stream. Therefore, the new interface or extended API is configured to share TSN configuration parameters, functions, and requirements between the first and second configuration modules (CNCs) for each individual TSN stream flowing / propagating / transitioning between different network domains. This TSN configuration information may include configuration parameters or functions necessary to implement TAS, policing, periodic queuing, forwarding, shaping, metering, and filtering for each TSN stream.

[0117] Figure 9 shows a diagram illustrating a non-limiting example of a typical TSN communication network system. The TSN communication network system 900 shows a block diagram of an exemplary implementation of an integrated TSN-5G system similar to system 200, and also includes 5G components similar to those of system 200 described above. Referring to Figure 2, at least one 5G component is configured to behave as a single TSN block, such as a TSN bridge (e.g., the bridge in Figure 9) and a TSN end system (i.e., a talker / listener), in accordance with the TSN specification (e.g., IEEE 802.1Qcc). IEEE 802.1Qcc is incorporated herein by reference in its entirety.

[0118] The TSN communication network system 900 may provide configuration controllers 910 (e.g., a centralized configuration controller 110, distributed controllers 210) for controlling the TSN communication network system 900. The configuration controllers include a CUC (e.g., CUC114) and a CNC (e.g., CNC112) that operate according to the TSN specification (e.g., IEEE802.1Qcc). The CUC and CNC may exchange configuration data (or configuration information) via a standardized API such as a User Network Interface (UNI). A talker / listener located at a TSN end station represents the user side of the API, and a TSN bridge represents the network side of the API. The configuration data may include user configuration data and network configuration data as defined in IEEE802.1Qcc. User configuration data may include configuration data from the user side to the network, and network configuration data may include configuration data from the network to the user side. Therefore, the CUC is configured to communicate with talkers and / or listeners, create talker groups and listener groups for each QoS flow, and send the talker groups and / or listener groups to the CNC as user configuration data via a standardized API (e.g., User Network Interface (UNI)). The CNC provides the CUC with status groups as network configuration data, and the CUC provides the status groups to the talkers and / or listeners.

[0119] The talker group specifies the talker's behavior for the stream, the talker's requirements from the network, and the TSN's capabilities for the talker's interface. The listener group specifies the TSN's capabilities for the listener's interface and the listener's requirements from the network. The status group provides the status of the stream configuration from the network to each user (talker or listener). The talker group includes, but is not limited to, the stream ID, end-station interface, UserToNetwork requirements, interface capabilities, stream rank, data frame specifications, and traffic specifications as defined in IEEE 802.1Qcc. The listener group includes, but is not limited to, the stream ID elements, end-station interface, UserToNetwork requirements, and interface capabilities as defined in IEEE 802.1Qcc. The status group includes, but is not limited to, status information, cumulative latency, interface configuration, and failed interfaces as defined in IEEE 802.1Qcc. In some implementations, additional elements to describe stream requirements, including TSN features such as time-aware shaping, filtering and policing, policy-based forwarding, frame duplication and elimination for redundancy, and other functionalities, may be shared via the API between the CUC and the CNC. In some implementations, additional elements to provide a granular set of per-stream requirements, including the requested delivery mode, latency budget, jitter tolerance, and loss tolerance, may also be shared via the API between the CUC and the CNC.

[0120] 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 may be configured as CNCs and / or CUCs as described above. The configuration modules may exchange information with each other using a standardized API (e.g., an inter-configuration module API 230). The information exchanged includes, but is not limited to, configuration data. Thus, configurations are passed between at least two configuration modules via the standardized API. The configuration modules then provide configuration data to at least one TSN block via at least one TSN block to support TSN functionality for each TSN stream.

[0121] In some implementations, a configuration module may be configured as a module within a TSN block (e.g., at least one Internal Configuration Interface (ICI) 406) and 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 may provide configuration data to other configuration modules configured as modules within the TSN block.

[0122] Figure 10 shows a non-limiting example of configuration data according to one or more implementations. As described above, configuration data may be exchanged between a first configuration module (CM-10) and a second configuration module (CM-20) of a plurality of configuration modules 215-x. The configuration data includes user configuration data such as stream requirements and network configuration data such as stream / elementary stream (ES) settings. The first and second configuration modules 215x may be configured as CNC and / or 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), and CM-20 configures the TSN block 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 transmits stream / ES configuration to CM-10. Stream requirements include, but are not limited to, listener groups and talker groups compliant with the TSN specification (e.g., IEEE 802.1Qcc). Stream / ES configuration includes, but are not limited to, status groups compliant with the TSN specification (e.g., IEEE 802.1Qcc). In some embodiments, configuration data transmitted from CM-10 to CM-20 via API includes Traffic Specification elements and Traffic Specification Time Aware elements as described in Section 46.2.3.5 of IEEE 802.1Q. Traffic Specification elements may include a TimeAwareScheduling parameter provided in Boolean form. In some embodiments, configuration data transmitted from CM-10 to CM-20 via API further includes UserToNetworkRequirements elements as described in Section 46.2.3.6 of IEEE 802.1Q.

[0123] A TSN communication network system (e.g., TSN communication network system 900) may employ TSN functions such as TimeAware Scheduling (TAS) in accordance with the TSN specification (e.g., IEEE 802.1Qbv). A TSN-5G system further employs TSN functions such as stream-based filtering and policing (PSFP) in accordance with the TSN specification (e.g., IEEE 802.1Qci) and periodic queuing and forwarding (CQF) in accordance with the TSN specification (e.g., IEEE 802.1Q). These TSN functions may be required for each TSN stream in the communication network. As described above, a TSN communication network system can distribute the configuration of each individual stream in the TSN network using configuration data. The configuration data shared from a first configuration module to a second configuration module further includes configuration parameters to provide at least one of the required TSN functions for each TSN stream.

[0124] In some implementations, the configuration of each individual stream includes the configuration of the TSN functionality required for each individual TSN stream, and the CM-20 determines, based on the configuration data, whether to configure one or more TSN blocks to support the required TSN functionality for each individual TSN stream. In some implementations, the configuration parameters for the required TSN functionality are implemented in Boolean form, but are not limited to that. In some implementations, if a Boolean configuration parameter (e.g., the TimeAwareScheduling parameter) is specified in the API and has a value of "True", the CM-20 uses TAS for scheduling across the entire network from source to destination. For example, the configuration data may include, as additional configuration data, information about TAS (TimeAwareScheduling, see Figure 9) indicating whether to schedule traffic on the communication network with TAS. In some implementations, the configuration data may include, as additional configuration data, information about PSFP indicating whether to police each individual TSN stream in the communication network with PSFP. In some implementations, the configuration data may include, as additional configuration data, information about CQF indicating whether to apply CQF to each individual TSN stream. Since the configuration data is shared between the two configuration modules, even if one configuration module is configured without using CUC, the shared configuration data allows the corresponding configuration module to determine and configure the corresponding TSN blocks to support the necessary TSN functions based on the shared configuration data.

[0125] In some implementations, the TSN communication network system may include a configuration element (or configuration element module) (not shown in Figure 10) that provides configuration information, including the settings for 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 it to each configuration module (e.g., CNC).

[0126] Figure 11 shows a block diagram of an exemplary integrated TSN-communication network system architecture relating to one or more implementations. The TSN communication network system 1100 is a block diagram of an example implementation of a TSN communication network system that integrates a system 200 similar to the TSN communication network system 900 described above. Referring to Figure 2, the TSN communication network system 1100 may include a plurality of configuration modules (CMs) 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. In Figure 11, the dotted line 1120 represents data communication from a source device (e.g., a talker) to a destination device (e.g., a listener) over the communication network. In Figure 11, the line 1130 connecting network domain 1, network domain 2, and network domain 3 represents the communication network through which each individual TSN stream flows.

[0127] In some implementations, the communication network includes a wireless network configured according to standards defined by 3GPP. CM-100 is configured to communicate with talkers in data source 204 and create configuration data (e.g., talker groups). The configuration data is passed to CM-200 via API 230-1, and CM-200 configures network domain 1. Network domain 1 includes a set of TSN blocks configured by communication network (CN) components in the communication network, or a separate structure containing multiple TSN blocks 202-1 to 202-N. As described above, at least one of the multiple configuration modules (e.g., CM-100) may transmit configuration data containing the configuration of each individual TSN stream communicated by the communication network. The configuration of each individual TSN stream includes one or more TSN functions (e.g., TAS, PSFP, CQF, etc.) required for each individual TSN frame to other configuration modules (e.g., CM-200, CM-500) via APIs (e.g., API 230-1, API 230-2) in the communication network.

[0128] The configuration data shared from CM-100 to CM-200 may include additional configuration data to provide one or more TSN functions required for each individual TSN frame. In some implementations, the one or more required TSN functions include at least one of Time-Aware Scheduling (TAS), Stream-by-Stream Filtering and Policing (PSFP), and Periodic Queuing and Forwarding (CQF). The configuration data includes information indicating whether to schedule traffic on the communication network using TAS, whether to police each individual TSN stream on the communication network using PSFP, and / or whether to apply CQF to each individual TSN stream. Based on the configuration data, CM-200 determines whether to apply the required TSN functions to each individual TSN stream and configures a TSN block to implement the required TSN functions.

[0129] The CM-300 is configured to communicate with the listener at data destination 206 and create configuration data (e.g., listener group). The configuration data is passed to the CM-400 via API 230-3, and the CM-400 configures network domain 3. Network domain 3 includes a series of TSN blocks or isolated structures, including multiple TSN blocks 202-1 to 202-N, which are composed of CN components in the wireless network.

[0130] CM-200 and CM-400 may each transmit configuration data to CM-500 via API 230-2. CM-500 configures network domain 2 based on the received configuration data. Network domain 2 includes a series of TSN blocks or isolated structures, including multiple TSN blocks 202-1 to 202-N, which are composed of CN components in the wireless network. The configuration data shared from CM-200 to CM-500 may include additional configuration data to provide the requested TSN functionality, and CM-500 determines whether to apply the requested TSN functionality and configure the TSN blocks based on the shared configuration data. As described above, CM-500 may transmit the configuration data received from CM-200 to CM-400 so that CM-400 can determine whether to apply the requested TSN functionality and configure network domain 3. CM-500 may also transmit additional configuration data originating from CM-500 to CM-400. For example, when calculating the stream schedule, each domain may use up a portion of the latency budget. Therefore, the CM-500 needs to notify the CM-400 of how much latency budget has already been consumed. The CM-500 may also send configuration data received from the CM-400 to the CM-200. In some implementations, the API (e.g., API230-2) used for communication between configuration modules (e.g., CM-200, CM-400, and CM-500) may be, but not limited to, a direct interface associated with each configuration module or an interface provided through a third entity (e.g., a central station or core network).

[0131] In some implementations, the TSN communication network system 1100 may include a configuration element 1110 (network policy configuration element) that provides configuration element information including the configuration of each individual TSN stream communicated by the communication network. This configuration includes one or more TSN functions (e.g., TAS, CQF, etc.) in at least one configuration module of multiple CM215-x (e.g., CM-300, CM-500). For example, the configuration element 1110 may provide configuration information to all CMs, or it may selectively provide configuration element information to at least one CM configured without using CUC. As an example implementation, certain TSN functions (e.g., TAS, CQF) may be provided by configuration modules, and other TSN functions (e.g., PSFP) may be provided by the configuration element 1100. The configuration element 1110 may also provide policy rules that guide / notify CM215-x (e.g., CM-200, CM-400, CM-500) to select the appropriate TSN function. For example, configuration element 1110 may specify that PSFP should be applied to all streams that are shaped by a credit-based shaper in the data source.

[0132] Figure 12 shows a block diagram of an exemplary integrated TSN-communication network system architecture in 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, TSN communication network system 900, and TSN communication network system 1100 described above. As described above, the integrated TSN communication network system 1200 includes a network policy module 1210 as an example implementation of the configuration element 1110. The network policy module 1210 provides configuration element information, including the configuration of each individual TSN stream communicated by the communication network, to configuration modules 215-x that each configure network domains (e.g., first network domain 1, second network domain 2). The network policy module 1210 may also provide policy rules that guide / notify CM215-x (e.g., CM-500, CM-600, CM-700, and CM-800, etc.) about the selection of appropriate TSN functions. For example, configuration element 1110 may specify that PSFP should be applied to all streams shaped by a credit-based shaper in the data source. A CM-500 configured as a CUC may receive configuration information from the network policy module 1210, and then transmit the configuration information to the CM-600 via the standardized API 230-4 to support one or more data flows through TSN block 202-x from the talker system of data source 204 to the listener system of data destination 206 in the first network domain 1. Similarly, a CM-700 may receive configuration information from the network policy module 1210 and transmit the configuration information to the CM-800 via the standardized API 230-5 to support one or more data flows through TSN block 202-x from the talker system of data source 204 to the listener system of data destination 206 in the second network domain 2.In some embodiments, a CM-600 associated with a first network domain 1 and a CM-800 associated with a second network domain 2 may exchange / share configuration data via a standardized API 230-6 to support data flows / streams between multiple domains. As described above, API 230-6 is provided for sharing configuration information, including configuration parameters (TSN configuration parameters), functions, and requirements, for each individual TSN stream flowing / propagating / transitioning between the first network domain 1 and the second network domain 2. Based on the shared configuration information via API 230-6, the CM-600 and CM-800 adjust the configurations of the first and second network domains respectively to satisfy the requirements of each individual TSN stream. The configuration parameters or functions are provided, as described above, to perform TAS, policing, periodic queuing, forwarding, shaping, metering, and filtering for each TSN stream.

[0133] The technology described herein provides configuration modules (e.g., CM-200, CM-400, CM-500 in Figure 11, and CM-600, CM-800 in Figure 12) associated with a first network domain in a communication network (e.g., network domain 1, network domain 2, and network domain 3 in Figures 11 and 12). The configuration modules include interfaces (e.g., API 230-2, API 230-6) for sharing configuration data between the configuration module and multiple configuration modules (e.g., CM-200, CM-400, CM-500 in Figure 11, and CM-600, CM-800 in Figure 12) associated with different network domains in the communication network. The communication network supports time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism. The configuration data includes request parameters for each TSN stream (for example, TSN functions such as time-aware scheduling (TAS) according to the TSN specification (e.g., IEEE 802.1Qbv), stream-based filtering and policing (PSFP) according to the TSN specification (e.g., IEEE 802.1Qci), and periodic queuing and forwarding (CQF) according to the TSN specification (e.g., IEEE 802.1Q), as described in Figures 10-12), and supports time-sensitive deterministic communication for each TSN stream according to the configuration data. The configuration module and multiple configuration modules configure one or more communication network (CN) components as one or more TSN blocks based on the configuration data, supporting communication for each individual TSN stream. Each individual TSN stream flows through a first network domain and different network domains in the communication network. In some implementations, configuration data includes time-aware scheduling (TAS) parameters indicating whether or not to schedule each individual TSN stream using TAS, and information indicating whether or not to apply periodic queuing and forwarding (CQF) to each individual TSN stream. In some implementations, the TAS parameters are in Boolean form.In some implementations, configuration data includes information indicating whether each individual TSN stream in the communication network should be policed ​​with stream-based filtering and policing (PSFP). In some implementations, a configuration module and at least one of multiple configuration modules receive information from a configuration element module in the communication network (e.g., configuration element 1110, network policy module 1210) indicating whether each individual TSN stream in the communication network should be policed ​​with stream-based filtering and policing (PSFP). In some implementations, configuration modules are configured in a decoupled structure (e.g., multiple distributed configuration modules 215 in a distributed controller 210, as described with respect to Figure 2), but are not limited to this. In some implementations, interfaces are configured as direct interfaces associated with configuration modules or as interfaces provided by a third entity. In some implementations, each network domain in the communication network refers to a service provider or network owner that provides different services using different TSN parameters.

[0134] In one embodiment, several implementations include a communication network (e.g., an integrated TSN communication network system 200, 1100, 1200), the communication network having first configuration modules (e.g., CM-200, CM-400, CM-500 in Figure 11, CM-600, CM-800 in Figure 12) associated with first network domains (e.g., network domain 1, network domain 2, network domain 3 in Figures 11 and 12) configured to support time-sensitive deterministic communication in the communication network, and time-sensitive The system supports time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism, which includes a second configuration module (e.g., CM-200, CM-400, CM-500 in Figure 11, CM-600, CM-800 in Figure 12) associated with a second network domain (e.g., network domain 1, network domain 2, network domain 3 in Figures 11 and 12) configured to support active deterministic communication, and an interface (e.g., API230-2, API230-6) between the first and second configuration modules. The interface is used to send configuration data from the first configuration module to the second configuration module, which configures one or more communication network (CN) components in the communication network as one or more TSN blocks based on the configuration data. The configuration data includes per-TSN stream request parameters to support time-sensitive deterministic communication for each TSN stream in accordance with the configuration data.In some implementations, configuration data represents one or more TSN functions required for each individual TSN stream, and one or more TSN functions include at least one of the following: time-aware scheduling (TAS) according to the TSN specification (e.g., IEEE 802.1Qbv), stream-based filtering and policing (PSFP) according to the TSN specification (e.g., IEEE 802.1Qci), and periodic queuing and forwarding (CQF) according to the TSN specification (e.g., IEEE 802.1Q), as described with respect to Figures 10, 11, and 12. In some implementations, configuration data includes information indicating whether or not traffic on the communication network is scheduled with TAS. In some implementations, configuration data includes information indicating whether or not each individual TSN stream in the communication network is policed ​​by PSFP. In some implementations, configuration data includes information indicating whether or not CQF is applied to each individual TSN stream. Each individual TSN stream 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 may include configuration element modules (e.g., configuration element 1110, network policy module 1210) configured to provide configuration elements containing one or more TSN functions required for each individual TSN stream in at least one of the first and second configuration modules, where one or more TSN functions include at least one of time-aware scheduling (TAS), stream-based filtering and policing (PSFP), and periodic 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 in a decoupled structure (e.g., multiple distributed configuration modules 215 in a distributed controller 210, as described with respect to Figure 2), but is not limited to this.In some implementations, interfaces are configured either as direct interfaces associated with a configuration module or as interfaces provided by a third entity. In some implementations, each network domain within a communication network refers to a service provider or network owner that provides different services using different TSN parameters.

[0135] In other embodiments, configuration modules are provided that are associated with a communication network to support time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism. The configuration modules may include a first configuration module associated with a source or destination device (e.g., CM-10 in Figure 10, CM-100 and CM-300 in Figure 11, and CM-500 and CM-700 in Figure 12), configured to provide configuration data for each individual TSN stream communicated in the communication network through at least one of a plurality of communication network (CN) components, and a second configuration module associated with a plurality of CN components (e.g., CM-20, CM-200, CM-400 and CM-500 in Figure 11, and CM-600 and CM-700 in Figure 12). In some implementations, the first configuration module is further configured to communicate with the second configuration module via APIs (e.g., API230, API230-1, API230-3, API230-4, API230-5) so that the second configuration module configures one or more of several CN components as one or more TSN blocks based on the configuration data. The configuration data represents one or more TSN functions required for each individual TSN stream. The one or more TSN functions include at least one of time-aware scheduling (TAS) according to the TSN specification (e.g., IEEE802.1Qbv), stream-based filtering and policing (PSFP) according to the TSN specification (e.g., IEEE802.1Qci), and periodic queuing and forwarding (CQF) according to the TSN specification (e.g., IEEE802.1Q), as described with respect to Figures 10, 11, and 12. The configuration data further includes TAS (Time-Aware Scheduling) parameters indicating whether or not each individual TSN stream is scheduled by TAS, and information indicating whether or not periodic queuing and forwarding (CQF) is applied 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 and second configuration modules are associated with the same network domain among one or more network domains (e.g., network domain 1, network domain 2, network domain 3 in Figures 11 and 12). The second configuration module is further configured to share configuration data with multiple configuration modules associated with different network domains among one or more network domains (e.g., CM-200, CM-400, CM-500 in Figure 11, CM-600, CM-700 in Figure 12). As described with respect to Figures 11 and 12, the second configuration module is configured to share configuration data via interfaces (e.g., API230-2, API230-6). In some implementations, the interfaces are configured as direct interfaces associated with the configuration module or as interfaces provided by a third entity. In some implementations, the TAS parameters are in Boolean form. The configuration data further includes information indicating whether each individual TSN stream in the communication network should be policed ​​with Stream-by-Stream Filtering and Policing (PSFP). In some implementations, a second configuration module is further configured to receive information from configuration element modules within the communication network (e.g., configuration element 1110, network policy module 1210) indicating whether each individual TSN stream in the communication network should be policed ​​by stream-by-stream filtering and policing (PSFP). In some implementations, the configuration modules are configured in a decoupled structure (e.g., multiple distributed configuration modules 215 in a distributed controller 210, as described with respect to Figure 2), but are not limited to this. In some implementations, each network domain within the communication network refers to a service provider or network owner that provides different services using different TSN parameters.

[0136] Those skilled in the art will understand that the various exemplary blocks, modules, elements, components, methods, and algorithms described herein can be implemented as electronic hardware, computer software, or a combination of both. To illustrate the compatibility of such hardware and software, various exemplary blocks, modules, elements, components, methods, and algorithms have been generally described in terms of their functions. Whether such functions are implemented as hardware or software depends on the design constraints imposed on the particular application and the overall system. The functions described can be implemented in various ways for each specific application. Various components and blocks can be arranged in various ways, for example, in different orders or in different ways, as long as this does not exceed the scope of the art.

[0137] It is understood that the specific order or hierarchy of steps in the disclosed process is an example of an exemplary approach. It is understood that the specific order or hierarchy of steps in the process may be rearranged based on design preferences. Some steps may be performed simultaneously. The attached claims for the method present elements of various steps in a sample order and are not intended to be limited to the specific order or hierarchy presented.

[0138] The above description is provided in a manner that can be understood by those skilled in the art, so that various embodiments of the present disclosure may be carried out. The above description provides various examples of the present technology, and the present technology is not limited to these examples. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may apply to other embodiments. Accordingly, the claims should be given the entire scope consistent with the wording of the claims, without being limited to the embodiments shown herein, and references to singular elements mean "one or more" unless specifically stated as "one only." Unless specifically stated, "several" means one or more. Masculine pronouns (e.g., his) include feminine and neuter (e.g., her and its), and vice versa. Where there are headings and subheadings, they are used for convenience only and do not limit the disclosures contained herein.

[0139] The predicates "configured to," "operable to," and "programmed to" do not imply any specific tangible or intangible change to the subject, but rather are intended to be used interchangeably. For example, a processor configured to monitor and control operations and components may also be a processor programmed to monitor and control operations, or a processor capable of operating to monitor and control operations. Similarly, a processor configured to execute code can be interpreted as a processor programmed to execute code, or a processor capable of operating to execute code.

[0140] As used herein, “automatic” may include being performed by a computer or machine without user intervention, for example, by a command in response to a predicate action or other initiation mechanism by a computer or machine. As used herein, “example” means “serving as an example or illustration.” Any embodiment or design described as an “example” is not necessarily construed as being preferable or advantageous to any other embodiment or design.

[0141] The phrase “aspect” does not mean that such an embodiment is essential to the present technology, or that such an embodiment applies to all configurations of the present technology. Disclosure relating to an embodiment may apply to all configurations, or to one or more configurations. An embodiment may provide one or more examples. The phrase “aspect” can refer to one or more embodiments, and vice versa. The phrase “embodiment” does not mean that such an embodiment is essential to the present technology, or that such an embodiment applies to all configurations of the subject technology. Disclosure relating to an embodiment may apply to all embodiments, or to one or more embodiments. An embodiment may provide one or more examples. The phrase “embodiment” may refer to one or more embodiments, and vice versa. The phrase “configuration” does not mean that such a configuration is essential to the subject technology, or that such a configuration applies to all configurations of the subject technology. Disclosure relating to a configuration may apply to all configurations, or to one or more configurations. A configuration may provide one or more examples. The phrase “configuration” may refer to one or more configurations, and vice versa.

[0142] All structural and functional equivalents of elements of various aspects of this disclosure, whether known to those skilled in the art or to become known thereafter, are expressly incorporated by reference herein and are intended to be encompassed by the claims. Furthermore, nothing disclosed herein is intended to be made generally available, whether expressly stated in the claims or not. No element of a claim should be construed under 35 U.S. SC § 112(f) unless the element is expressly described using the phrase “means for” or, in the case of a method claim, the element is described using the phrase “step for”.

Claims

1. A configuration module associated with a first network domain in a communication network to support time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism, The interface is configured to share configuration data between a configuration module and a plurality of configuration modules by communicating with a plurality of configuration modules associated with different network domains within the communication network, The configuration data includes request parameters for each TSN stream in order to support time-sensitive deterministic communication of each TSN stream according to 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 stream passing through the first network domain and the different network domains within the communication network. Configuration module.

2. The configuration data includes a TAS parameter indicating whether or not to schedule each individual TSN stream using time-aware scheduling (TAS), and information indicating whether or not to apply periodic queuing and forwarding (CQF) to each individual TSN stream. The setting module according to claim 1.

3. The aforementioned TAS parameter is in Boolean form. The setting module according to claim 2.

4. The configuration data includes information indicating whether or not to police each individual TSN stream within the communication network by stream-level filtering and policing (PSFP). The setting module according to claim 1.

5. The configuration module and at least one of the plurality of configuration modules receive information from a configuration element module in the communication network indicating whether or not to police each individual TSN stream in the communication network by stream-based filtering and policing (PSFP). The setting module according to claim 1.

6. A communication network that supports time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism, A first configuration module associated with a first network domain configured to support time-sensitive deterministic communication in the aforementioned communication network, A second configuration module associated with a second network domain configured to support time-sensitive deterministic communication in the aforementioned communication network, The interface between the first configuration module and the second configuration module is provided, The interface is used to transmit configuration data from the first configuration module to the second configuration module, and the second configuration module configures one or more of the multiple communication network (CN) components in the communication network as one or more TSN blocks based on the configuration data. The configuration data includes request parameters for each TSN stream in order to support time-sensitive deterministic communication of each TSN stream according to the configuration data. Communication network.

7. The configuration data represents one or more TSN functions required for each individual TSN stream, and the one or more TSN functions include at least one of Time-Aware Scheduling (TAS), Stream-Periodic Filtering and Policing (PSFP), and Periodic Queuing and Transfer (CQF). The communication network according to claim 6.

8. The aforementioned configuration data includes information indicating whether or not the TAS will schedule traffic in the communication network. The communication network according to claim 7.

9. The configuration data includes information indicating whether or not each individual TSN stream in the communication network is policed ​​by the PSFP. The communication network according to claim 7.

10. The aforementioned configuration data includes information indicating whether or not to apply the CQF to each individual TSN stream. The communication network according to claim 7.

11. Each individual TSN stream flows through the first network domain and the second network domain in the communication network. The communication network according to claim 6.

12. The first configuration module and at least one of the second configuration modules include a configuration element module configured to provide configuration elements including one or more TSN functions required for each individual TSN stream, The one or more TSN functions include at least one of time-aware scheduling (TAS), stream-based filtering and policing (PSFP), and periodic queuing and forwarding (CQF). The communication network according to claim 6.

13. The aforementioned communication network includes a wireless network established in accordance with standards defined by 3GPP. The communication network according to claim 6.

14. A configuration module associated with a communication network to support time-sensitive deterministic communication based on a time-sensitive network (TSN) mechanism, A first configuration module is configured to provide configuration data for each individual TSN stream associated with a source device or destination device and communicated through at least some of the multiple communication network (CN) components in the communication network, Includes a second configuration module associated with multiple CN components, The first configuration module is configured to communicate with the second configuration module via an API, and 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 functions required for each individual TSN stream, and the one or more TSN functions include at least one of Time-Aware Scheduling (TAS), Stream-Period Filtering and Policing (PSFP), and Periodic Queuing and Transfer (CQF). The configuration data includes a TAS parameter indicating whether or not to schedule each individual TSN stream using TAS, and information indicating whether or not to apply CQF to each individual TSN stream. Configuration module.

15. The aforementioned communication network includes one or more network domains through which individual TSN streams according to the configuration data flow. The setting module according to claim 14.

16. The first configuration module and the second configuration module are associated with the same network domain among the one or more network domains. The setting module according to claim 15.

17. The second configuration module is further configured to share the configuration data with multiple configuration modules associated with different network domains among the one or more network domains. The setting module according to claim 14.

18. The aforementioned TAS parameter is in Boolean form. The setting module according to claim 14.

19. The configuration data further includes information indicating whether or not to police each individual TSN stream within the communication network by stream-level filtering and policing (PSFP). The setting module according to claim 14.

20. The second configuration module is configured to receive information from the configuration element module in the communication network indicating whether or not to police each individual TSN stream in the communication network by stream-based filtering and policing (PSFP). The setting module according to claim 14.

Images