Tsn-aware 5g edge enabler application performance monitoring

Abstract

Systems, methods, techniques, and other embodiments are disclosed related to systems associated with a communication network configured to support time sensitive deterministic communication based on time sensitive network (TSN) mechanisms. The system includes a plurality of network devices configured to provide functionality to enable an edge-enabled application to provide an edge service, the edge-enabled application including microservices distributed and implemented on network resources in the communication network, each microservice configured to provide a different process function of the edge application, and a controller configured to obtain application performance parameters associated with one or more process functions of the application and determine a TSN schedule based on the application performance parameters such that the one or more process functions are configured to process data flows for the edge application based on the TSN schedule.

Description

Cross-reference to related applications

[0001] This application claims priority to U.S. Provisional Patent Application 63 / 596,716, filed November 7, 2023, which is incorporated herein by reference in its entirety. Technical Field

[0002] This specification generally relates to the integration of wireless communication systems with Time-Sensitive Networks (TSNs), and more specifically, for example, to the integration of TSNs into edge-enabled applications. Background Technology

[0003] Applications such as industrial automation and manufacturing require ubiquitous and seamless connectivity, where communication between various devices or components of the application (e.g., industrial controllers, sensors, actuators, etc.) has stringent deterministic timing requirements. To meet these requirements, TSN systems providing deterministic communication with relatively stringent Quality of Service (QoS) parameters (e.g., latency, jitter, and reliability requirements for data traffic) can be integrated with communication networks conforming to 3GPP specifications (e.g., 5G, 6G, etc.) that provide highly reliable services, such as Ultra-Reliable Low-Latency Communication (URLLC). Edge computing places such communication networks and computing resources closer to the user, facilitating URLLC applications. Scheduled TSN streams can occur simultaneously and redundantly to both the original and new edge locations during edge relocation, ensuring no messages are lost during the relocation process. Attached Figure Description

[0004] Some features of this subject matter are set forth in the appended claims. However, for purposes of explanation, several aspects of this subject matter are illustrated in the following figures.

[0005] Figure 1 An example of a conventional integrated TSN-5G system according to one or more implementation methods is illustrated.

[0006] Figure 2 The diagram illustrates a block diagram of an example integrated TSN-5G system architecture according to one or more implementation methods.

[0007] Figure 3 An example of an integrated TSN-5G system according to one or more implementations is illustrated.

[0008] Figure 4 A block diagram of an example TSN block according to one or more embodiments is shown.

[0009] Figure 5 The illustration shows an example set of parameters for an example TSN block according to one or more embodiments.

[0010] Figure 6A and Figure 6B The diagram illustrates a block diagram of an example integrated TSN-5G system architecture including multi-access edge computing (MEC) according to one or more embodiments.

[0011] Figure 7 The illustration shows an electronic system that can implement one or more embodiments of the technology of this subject.

[0012] Figure 8 The diagram illustrates a block diagram of an example integrated TSN-5G system architecture according to one or more implementation methods.

[0013] Figure 9 An exemplary architecture for enabling applications is illustrated according to one or more implementations.

[0014] Figure 10 An exemplary architecture for enabling applications is illustrated according to one or more implementations.

[0015] Figure 11 An exemplary API for enabling an application is illustrated according to one or more implementations.

[0016] Figure 12 An exemplary architecture for enabling applications is illustrated according to one or more implementations.

[0017] Figure 13 The illustration shows a flowchart for service provision according to one or more embodiments.

[0018] Figure 14 The diagram illustrates a data flow diagram of data provided with the controller according to one or more embodiments.

[0019] Figure 15 The illustration shows a flowchart of an example method for providing edge services according to one or more embodiments.

[0020] Figure 16 A block diagram of an example system according to one or more embodiments is shown. Detailed Implementation

[0021] The specific embodiments described below are intended as descriptions of various configurations of the subject matter and are not intended to represent the only configuration in which the subject matter can be practiced. The accompanying drawings are incorporated herein and form part of the specific embodiments. The specific embodiments include detailed descriptions to provide a thorough understanding of the subject matter. However, the subject matter is not limited to the specific details set forth herein and can be practiced using one or more other embodiments. In one or more embodiments, structures and components are shown in block diagram form to avoid obscuring the concepts of the subject matter.

[0022] As mentioned above, for some applications (such as, but not limited to, industrial automation, manufacturing, and airborne communications in aerospace and automotive), a TSN system providing deterministic communication can be integrated with fifth-generation (5G) or sixth-generation (6G) wireless communication systems (or any communication network or system defined according to 3GPP standards or IEEE 802.1 standards). However, typically in such integrated TSN-5G systems, the entire 5G system is configured to operate as a single TSN component (e.g., a TSN bridge), and the integrated system is configured as a fully centralized configuration model, for example, using a centralized TSN configuration controller. Therefore, such integrated systems may not support the flexibility of deploying 5G systems that include various components from different vendors, nor do they support distributed TSN configurations of the integrated system. Additionally, 5G systems can support reliable communication by using redundant paths for data transmission. However, since the 5G system is configured as a single TSN component in a typical TSN-5G integrated system, redundant paths are configured across the entire 5G system through all its components (e.g., from User Equipment (UE) to User Plane Function (UPF)). This prevents the flexibility to set up redundant data transmission paths only for a portion of the 5G system (e.g., the portion of the 5G system that is more prone to data latency and / or errors, such as the air interface between the UE and the radio access network (RAN) / gNodeB)).

[0023] To address the aforementioned issues in integrated TSN-5G systems, this subject matter provides a novel architecture in which the 5G system is configured as a set of discrete 5G components (each 5G component being configured as a discrete TSN block), rather than as a single TSN component or block. In other words, this disclosure provides an architecture in which the 5G system integrated into a TSN-5G system is divided into multiple TSN blocks, each TSN block being configured according to TSN specifications (e.g., according to IEEE 802.1Q and related standards) as, for example, a TSN bridge, a TSN end device, or a combination of both. Furthermore, this subject matter provides multiple distributed configuration modules in the TSN-5G system, rather than having a centralized configuration controller control the TSN-5G system. These configuration modules can be interconnected in one or more topologies (including mesh, star, tree, or random), and each configuration module can be responsible for communicating with and configuring one or more TSN blocks.

[0024] As discussed in detail below, each of the plurality of TSN blocks in a 5G system includes a set of parameters describing the capabilities to support and execute data flows (e.g., carrying URLLC data traffic) through that TSN block. Additionally, each TSN block may include at least one configuration interface configured to support interaction between the TSN block and its corresponding configuration module. The configuration interface can be used to provide the parameter set of the TSN block to the corresponding configuration module and receive configuration data (e.g., transport scheduling, data flow identifiers, policing rules, etc.) from the configuration module to support one or more data flows through the TSN block. Each TSN block can be configured to perform or operate according to the configuration data (received via the configuration interface) and to send data for each data flow according to the specifications provided in the configuration data. Finally, each TSN block may also include a monitoring and diagnostic module configured to monitor the runtime behavior of the TSN block and report this behavior via the configuration interface or a separate interface of the TSN block.

[0025] Each of the plurality of distributed configuration modules may be an external utility responsible for configuring 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 identify the TSN blocks controlled by the configuration module and provide them with configuration data, including TSN scheduling for one or more data streams to be sent through those TSN blocks. The configuration modules may exchange information with each other using a standardized application programming interface (API). The exchanged information may include: information about the cycle time of the TSN system (e.g., supported administrative cycle times (ACTs), including discrete levels of ACT buckets (each corresponding to a specific data stream), maximum / minimum cycle times), configuration data including transmission scheduling for one or more TSN blocks (including time offsets / durations / resources for transmission), and information for requesting or responding to resource allocation requests. In some implementations, one or more of the plurality of configuration modules may be adapted as a “controller” or “controller module,” which may include components configured or adapted to provide instructions, control, operation, or any form of communication to operable components to influence the operation of those operable components. The controller module may include any known processor, microcontroller, or logic device, including but not limited to: field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), full authority digital engine control (FADEC), aerospace systems, proportional controller (P), proportional-integral controller (PI), proportional-derivative controller (PD), proportional-integral-derivative controller (PID controller), hardware-accelerated logic controller (e.g., for encoding, decoding, transcoding, etc.), or combinations thereof.

[0026] 3GPP Release 8 categorizes self-organizing networks (SONs) into three main types: self-configuration, self-optimization, and self-healing. Self-organization is considered a mechanism or process that enables a system or network to change its organization during its execution time without explicit command. Self-configuration is defined as the process of incorporating new network elements (NEs) into a service, requiring minimal human intervention. A network element is a manageable logical entity that combines one or more physical devices. In some implementations, TSN blocks (discussed below) can be self-configured and incorporated into the 5G system as NEs with minimal human intervention. This can be achieved by TSN applications that automatically share their TSN flow (stream) characteristics and latency requirements with the TSN block. TSN blocks can cooperate to share flow characteristics and determine feasible TSN scheduling.

[0027] In some embodiments, this disclosure provides a communication network, such as a wireless network, like a 5G or 6G wireless communication system or network (or any communication network or system defined according to 3GPP standards or IEEE 802.1 standards), configured to support time-sensitive deterministic communication based on TSN mechanisms. In the context of this disclosure, any references to “communication network,” “wireless network,” and “communication / wireless network” refer to a network having various components designed, arranged, and / or configured for transmitting data, signals, or information across the network from a source node or device to a destination node or device, wherein at least a portion of the communication is performed wirelessly. Thus, the various components of such a network can be communicatively interconnected via wireless links or channels and / or via wired links or channels. The various components of the network include modules and channels / links implemented in hardware, software, and combinations of hardware and software.

[0028] A communication network may include multiple discrete communication network (CN) components. Each CN component may be configured to provide discrete functionality for data communication across the network from a source device to a destination device. The communication / wireless network may further include a processor arranged to configure at least one (or each) of the multiple CN components using a TSN parameter set of a TSN mechanism. After configuration using the TSN parameter set, the at least one (or each) of the multiple CN components can support time-sensitive deterministic communication as a TSN block in the TSN network, based on the TSN parameter set. In other words, the at least one (or each) of the multiple CN components can operate as a typical TSN block in the TSN network.

[0029] The plurality of discrete CN components in a 5G network may include a UE, RAN, UPF, control plane functions, and transport network channels connecting the CN components, including transport network channels connecting the RAN and UPF. In some embodiments, at least one CN component configured with TSN parameters is a 5G transport network channel connecting the RAN and UPF.

[0030] The communication network may include a configuration module configured to determine a set of TSN parameters for at least one of the plurality of CN components, the TSN parameter set including one or more of the following: TSN stream identifier, transmission scheduling, deadline or delay budget, filtering configuration, and redundancy scheme. In some embodiments, the configuration module is configured within the Session Management Function (SMF) of the control plane of the 5G network.

[0031] In some embodiments, this disclosure provides a communication network, such as a wireless network (e.g., a 5G network), comprising a plurality of configuration modules interconnected in some arrangement, and configured to provide each of the plurality of CN components with a unique TSN parameter set, such that each of the plurality of CN components supports time-sensitive deterministic communication as a corresponding TSN block in the TSN network based on the corresponding unique TSN parameter set. The plurality of configuration modules may be interconnected in a hierarchical arrangement, a mesh arrangement, a star arrangement, a tree arrangement, or a combination thereof.

[0032] In some embodiments, this disclosure provides a system including a first communication (e.g., 5G / 6G) network, a second communication (e.g., 5G / 6G) network, and a TSN transport channel connected to the first and second communication networks. The first network may include a first plurality of discrete CN components, each CN component configured to provide discrete functionality for data communication via the first network, wherein at least one of the first plurality of CN components is configured to provide time-sensitive deterministic communication according to a first TSN parameter set. The second network may include a second plurality of discrete CN components, each CN component configured to provide discrete functionality for data communication via the second network, wherein at least one of the second plurality of CN components is configured to provide time-sensitive deterministic communication 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 embodiments, the TSN transport channel is communicatively connected to a first TSN converter of the first wireless network and a second TSN converter of the second wireless network.

[0033] Edge-enabled applications (or edge applications) are becoming increasingly distributed, and scaling (e.g., using multiple servers distributed across multiple edge layers to execute a single application) is becoming a technology for achieving more advanced architectures. In some implementations, edge applications facilitate network services (e.g., edge services) via edge networks (e.g., distributed computing infrastructure, as described further below), which include network devices (e.g., UEs, 3GPP networks, edge servers, etc.). Network services (e.g., edge services) are provided by service providers and can be requested by network devices (e.g., UEs). Edge applications provide edge computing capabilities and can include any number and / or type of microservices, where each microservice runs in its own process / computation and communicates using protocols (e.g., Hypertext Transfer Protocol (HTTP) resource APIs) to provide edge services. Thus, each microservice can provide different functionalities for the edge application. Such microservices are chained together to create a complete edge application and can be configured as a logical channel consisting of deterministic inputs, outputs, and schedulable operations combined with TSN scheduling communication. However, there has been no discussion yet about how time-sensitive networking will be integrated into the edge-enabled computing specified by 3GPP.

[0034] To address the problems discussed above, this subject matter provides a system associated with a communication network configured to support time-sensitive deterministic communication based on a TSN mechanism. The system includes multiple network devices configured to provide functionality for enabling edge-enabled applications to provide edge services. The edge-enabled applications include microservices distributed and implemented on network resources within the communication network. Each microservice is configured to provide a different process function of the edge application. A controller is configured to acquire application performance parameters associated with one or more process functions of the application and determine a TSN schedule based on the application performance parameters, such that the one or more process functions are configured to process data streams for the edge-enabled application based on the TSN schedule.

[0035] In some implementations, application performance parameters include a maximum response time associated with the edge-enabled application, which includes the round-trip time for request and response packets for the edge service, the processing time of at least one network device, and the time required for the at least one network device to consume communication network capabilities. In some implementations, the controller is configured to determine whether to merge at least two microservices in a microservice into a single microservice. In some implementations, the controller is configured to determine whether to split the edge service into microservices. In some implementations, the system may include a monitoring module configured to monitor the edge-enabled application at least by determining whether an event associated with a process function indicates that a specified time threshold has been exceeded, wherein the event indicates the state of the system (e.g., anomaly, error, etc.) when the process function takes longer than the specified time threshold. In some implementations, the monitoring module is configured to monitor each microservice. In some implementations, the edge-enabled application is configured to support time-sensitive deterministic communication between a source device and a destination device, and the controller configures the microservices to send at least two distinct TSN streams between the source and destination devices. In some implementations, the controller is configured to recalculate a new TSN schedule in response to a change in the geographic location of at least one network device. In some implementations, the communication network is a wireless network according to the specifications defined by 3GPP.

[0036] In some embodiments, this subject matter provides a method for providing edge services in a system associated with a communication network configured to support time-sensitive deterministic communication based on a TSN mechanism. The method includes: obtaining application performance parameters associated with one or more process functions of an edge-enabled application from a plurality of network devices configured to provide functionality for enabling the edge-enabled application, the edge-enabled application including microservices distributed and implemented on network resources in the communication network, each microservice being configured to provide a different process function of the edge-enabled application; and determining a TSN schedule based on the application performance parameters, such that the one or more process functions are configured to process data streams for the edge-enabled application based on the TSN schedule.

[0037] In some embodiments, the present invention provides a non-transitory computer-readable medium storage device configured to store one or more instructions that, when executed by a processor, cause the processor to perform the method described above.

[0038] Figure 1The illustration depicts a non-limiting example of a conventional integrated TSN-5G system 100 in which the 5G network or system 106 is configured to emulate a single TSN component (e.g., a TSN bridge). Generally, system 100 is configured as a deterministic TSN system to transmit data between end devices (e.g., input / output (I / O) devices 102 and controller 104) via the 5G system 106 (emulated as a TSN bridge) and one or more (conventional) TSN bridges 108 and using a TSN controller 110. System 100 is configured based on standard methods for time synchronization and traffic management, thereby allowing deterministic communication between end devices (e.g., I / O devices 102 and controller 104) over a standard Ethernet network. For example, system 100 can operate according to the IEEE 802.1Q TSN specification suite, which standardizes Layer 2 communication for networking protocols that provide deterministic communication while sharing the same infrastructure. For example, many standards have established various technical paradigms for TSN systems—clock synchronization (802.1AS, General Precision Time Protocol (gPTP)), frame preemption (802.3br and 802.1Qbu), traffic scheduling (802.1Qbv), and redundancy management (Frame Replication and Deletion for Reliability (FRER) IEEE 802.1CB). These standards work together at Ethernet Layer 2 to ensure that control and security functions simultaneously meet their respective deadlines and constraints. As another implementation, similar integrated systems can be configured to implement TSN technology over wireless local area networks (wireless LANs), such as Wi-Fi networks (e.g., based on Wi-Fi 6 and other common wireless LANs).

[0039] For example, the 802.1Qbv TSN standard provides scheduled transmission of security-critical data frames in a predetermined manner and is incorporated herein in its entirety. As used herein, "TSN mode" can be used without limitation to refer to networks, components, elements, units, nodes, hubs, switches, controllers, modules, paths, data, data frames, traffic, protocols, operations, transports, and combinations thereof that conform to, are configured for, or comply with one or more standards in the IEEE 802.1 TSN standard. The 802.1Qbv TSN standard addresses the transmission of critical and non-critical data traffic within a TSN. Critical data traffic is guaranteed to be delivered at the scheduled time, while non-critical data traffic is typically assigned lower priority. Various traffic categories have been established according to IEEE 802.1Q for prioritizing different types of data traffic.

[0040] Ethernet frame preemption, defined by the IEEE 802.3br and IEEE 802.1Qbu standards, can suspend the transmission of non-critical Ethernet frames and also helps reduce latency and latency variations in critical traffic. The resource management foundation is defined by the TSN configuration model (IEEE 802.1Qcc). For example, as specified in IEEE 802.1Qdj [xx], centralized network configuration (CNC) 112 can be applied to network devices (bridges, such as 5G system bridges 106 and 108), while centralized user configuration (CUC) 114 can be applied to user equipment (end stations, such as I / O devices 102). The fully centralized configuration model follows a software-defined networking (SDN) approach. In other words, CNC 112 and CUC 114 in controller 110 provide the control plane rather than a distributed protocol. In contrast, distributed control protocols are applied in a fully distributed model, where there may be no CNC or CUC.

[0041] As a result of ultra-reliability, high availability can be provided by FRER (IEEE 802.1CB) for data flows through a per-packet reliability mechanism. This provides reliability by sending multiple copies of the same data packets on disjoint paths in the network. Flow filtering and policing (802.1Qci) enhances reliability by preventing bandwidth violations, failures, and malicious behavior. Additionally, time synchronization in a TSN system can be defined by gPTP (802.1AS), a brief version of the Precision Time Protocol standard (IEEE 1588). gPTP provides reliable time synchronization, which can be used by other TSN tools, such as traffic scheduling (802.1Qbv).

[0042] To achieve the desired level of reliability, TSN employs time synchronization and time-aware data traffic shaping. Data traffic shaping uses scheduling to control gating of transmissions on network switches and bridges (e.g., nodes). In some respects, this data traffic scheduling in the TSN can be determined before network operation. In other respects, data traffic scheduling can be determined based on system requirements during the initial design phase and updated as needed. For example, in addition to defining the TSN topology (including communication paths, bandwidth reservations, and various other parameters), the network-wide synchronization time for data transmission can be predefined. This data transmission plan for communication paths on the network is commonly referred to as "communication scheduling" or simply "scheduling." The scheduling of data traffic on the TSN can be determined for specific packets at specific times, on specific paths, and for specific durations. Non-limiting examples of techniques for generating TSN data traffic scheduling are discussed in U.S. Application No. 17 / 100,356, which is incorporated herein by reference in its entirety.

[0043] Time-critical communication between end devices or nodes in a TSN (e.g., I / O device 102 and controller 104) comprises a “TSN flow,” also known as a “data flow” or simply a “flow.” For example, a data flow can include datagrams, such as packets or data frames. Each data flow is unidirectional, from a first initiating 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 a unique identifier and timing requirements. These source and destination devices are typically referred to as the “talker” and the “listener.” Specifically, the “talker” and the “listener” are the source and destination of the data flow, respectively, and each data flow is uniquely identified by the end device operating in the system. It should be understood that for a given network topology comprising multiple interconnected devices, a set of data flows can be defined between the interconnected devices or nodes. For example, this set of data flows can be between interconnected devices. Various subsets or permutations of the data flows can be additionally defined for this set of data flows. Additionally, time-critical communication between end devices or nodes in a TSN includes "TSN streams" or "streams," where each TSN stream can originate from a specific speaking node intended to transmit to one or more listening nodes. Therefore, each TSN stream can include one or more data streams, each between the speaking node (the node from which the TSN stream originates) and the listening node.

[0044] End devices (e.g., 102, 104) and switches (often referred to as "bridges" or "switching nodes") (e.g., 106, 108) both send and receive data (Ethernet frames in a non-limiting example) in a data stream based on a predetermined time schedule. Switching nodes and end devices must be time-synchronized to ensure that the predetermined time schedule of the data stream is correctly followed throughout the network. For example, in... Figure 1 In this context, clock 116 indicates that the various switching nodes and end devices in the TSN system 100 (included in the 5G system 106) are time-synchronized with reference to a global clock (the highest-level master clock timing). In some other respects, only the switches can send data based on a predetermined schedule, while end devices (such as legacy devices) can send data in an unscheduled manner.

[0045] A single device (e.g., controller 110) can be used to schedule data flows within a TSN, taking a fixed, invariant path across the network between the speaking / listening device and the switching nodes in the network. Alternatively, a set of devices or modules can be used to schedule data flows. The scheduling device (whether a single device or a set of devices) can be arranged to define a centralized scheduler. In other aspects, the scheduler device can include a distributed arrangement. The TSN can also receive non-time-sensitive communication, such as rate-limited communication. In a non-limiting example, the scheduling device can include an offline scheduling system or module.

[0046] Various mechanisms can be used to label TSN traffic, including VLAN tags, Ethernet addresses, IP header information, and combinations of VLAN tags, Ethernet addresses, and IP header information. Traffic can be identified and labeled anywhere in the system before requiring Protocol Data Unit (PDU) identification. TSN speakers can create multiple TSN streams with different TSN latency and deterministic requirements, and these streams can be assigned different paths to meet those requirements. In some embodiments of the invention, latency and deterministic values ​​can be specified and provided to the TSN application as a finite set of static discrete values, rather than providing an infinite set of continuous values.

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

[0048] Additionally, actuators (e.g., devices, equipment, or machinery that move to perform one or more operations on I / O device 102) can communicate using TSN system 100. Non-limiting examples of actuators may include brakes, throttle valves, robotic devices, medical imaging equipment, lamps, turbines, etc. The actuator can transmit status data to one or more other devices (e.g., via TSN system 100 to other I / O devices 102, controller 104). The status data may represent the position, status, health, etc., of the actuator sending the status data. The actuator can receive command data from one or more other devices of TSN system 100 (e.g., other I / O devices 102, controller 104). The command data may represent instructions instructing the actuator how or when to move, operate, etc.

[0049] In some implementations, controller 104 can transmit various data between or among I / O devices 102 via TSN 100. For example, control system 104 can transmit command data to or from one or more devices in I / O 102, or receive data, such as status data or sensor data, from one or more devices in I / O 102. Therefore, controller 104 can be configured to control the operation of I / O devices 102 based on data acquired or generated by I / O devices 102 or transmitted between I / O devices, to achieve, for example, automatic control of I / O devices 102 and to provide information to operators or users of I / O devices 102. Controller 104 can define or determine data flows and data flow characteristics within TSN system 100.

[0050] The 5G system 106 within reference system 100, or 5G network or system 106, is a wireless communication network or system for carrying TSN traffic between various TSN end devices (e.g., I / O device 102 and controller 104). In some implementations, 5G system 106 is configured to emulate a TSN bridge for each UPF (similar to TSN bridge 108 according to the TSN standard discussed above). 5G system 106 may be a new radio (NR) network implemented according to the 3GPP 23 and 38 series of specifications (which are incorporated herein in their entirety) and integrated into system 100 according to 3GPP Release 17 23.501 standards (e.g., v17.1.1 and v17.2.0) (which are incorporated herein in their entirety). As shown in the figure, the 5G system 106 may include various CN components, such as the UE 118, RAN (gNB) 120, and UPF 122 in the 5G user plane, and application functions (AF) 124, SMF, and policy control functions (PCF) 126 in the 5G control plane, as defined in the 3GPP 23.501 standard. In some implementations, the 5G system 106 may be configured to provide URLLC services. The NR-based 5G system 106 includes several functions for achieving low latency for selected data streams. NR enables shorter time slots in radio electronic frames, which is beneficial for low-latency applications. NR also introduces micro-slots, where priority transmission can begin without waiting for slot boundaries, further reducing latency. As part of prioritizing and faster radio access URLLC traffic, NR introduces preemption—where URLLC data transmission can preempt ongoing non-URLLC transmissions. In addition, NR applies very fast processing, enabling retransmissions even within short latency limits.

[0051] In some implementations, 5G defines an ultra-robust transmission mode to improve the reliability of both data channels and control radio channels. Reliability is further enhanced through various techniques, such as multi-antenna transmission based on multiple-input multiple-output (MIMO), the use of multiple carriers, and packet duplication on independent radio links.

[0052] Embedding time synchronization as an essential part of operation in 5G cellular radio systems is a common practice in earlier generations of cellular networks. Radio network components themselves are also time-synchronized, for example, through precise time protocol telematics profiles, such as based on the 5G internal system clock 190. This provides a good foundation for providing synchronization for time-critical applications. For URLLC services, the 5G system 106 uses time synchronization for its own operation, as well as for multiple antennas and radio channels to provide reliability. In addition to 5G RAN features, the 5G system 106 can also provide solutions for Ethernet networking and URLLC in the core network. The 5G core network supports local Ethernet PDU sessions. 5G assisted establishment of redundant user plane paths via 5GS (including RAN, core network, and transport network). 5GS also allows for redundant user planes between RAN and core network nodes and between UE and RAN nodes, respectively.

[0053] As described above, in the integrated system 100, the 5G system 106 includes a TSN (virtual) bridge for each UPF. The 5G system 106 includes a TSN converter (TT) function to adapt the 5G system 106 to the TSN domain (both user plane and control plane), thereby hiding the internal processes of the 5G system 106 from the TSN bridging network. The 5G system 106 provides TSN bridge inbound and outbound port operation through the TT function. For example, TT supports hold and forwarding functions for jitter reduction. Figure 1 The illustration shows a scenario where the 5G system 106 connects the terminal station 102 to the bridging network 108; however, the 5G system 106 can also interconnect the bridges 108.

[0054] For the 5G system 106 to be integrated into the TSN system 100, the TSN streaming requirements can only be met if resource management allocates network resources for each hop along the entire path. This is achieved through the 5G system 106 in conjunction with a configuration controller (e.g., a centralized configuration controller 110 (including CUC 114 and CNC 112)) and / or a set of distributed controller modules (e.g., as described below regarding...). Figure 2The interaction between the discussed components is used to achieve this. The interface between the 5G system 106 and the CNC allows the CNC 112 to learn the characteristics of the 5G virtual bridge and allows the 5G system 106 to establish a connection with specific parameters based on the information received from the CNC 112. Bounded latency requires deterministic latency from 5G and QoS alignment between the TSN domain and the 5G domain. For example, if the 5G virtual bridge acts as a TSN bridge, the 5G system 106 simulates time-controlled packet transmission conforming to, for example, 802.1Qbv scheduled traffic. For the 5G control plane, the TT in AF 124 receives transmission time information for the TSN traffic category from the CNC 112. In the 5G user plane, the TT at UE 118 and the TT at UPF 122 can be adjusted accordingly for time-based packet transmission. As part of the QoS alignment between the TSN domain and the 5G domain, different TSN traffic categories can be mapped to different 5G QoS indicators (5QIs) in AF 124 and PCF 126, and the different 5QIs are processed according to their QoS requirements.

[0055] Regarding time synchronization, the 5G system 106 can implement gPTP on the connected TSN network. The 5G system 106 can act as a virtual gPTP time-aware system and supports forwarding gPTP time synchronization information between the terminal station 102 and the bridge 108 via the 5G user plane TT. All various 3GPP and TSN standards mentioned in this disclosure are incorporated herein by reference in their entirety.

[0056] Now for reference Figure 2The diagram illustrates a block diagram of the architecture of system 200 according to some embodiments of the subject matter. In a broader sense, system 200 depicts a block diagram of an example embodiment of an integrated TSN-5G system similar to system 100 described above, and also includes physical components similar to those in system 100 discussed above. However, unlike system 100, system 200 provides a novel architecture for an integrated TSN-5G system in which 5G system 106 is configured as a set of discrete 5G components, each of which is configured to emulate a discrete TSN block or element 202. In other words, in system 200, 5G system 106 is configured as a de-aggregated structure comprising multiple TSN blocks 202-1 to 202-N, wherein each TSN block 202 is configured according to TSN specifications (e.g., according to IEEE 802.1 and the relevant standards discussed above) as, for example, a TSN bridge, a TSN end device (i.e., as a TSN speaker and / or TSN listener), or a combination of both. Furthermore, this subject matter provides multiple distributed configuration modules 215 in the distributed controller 210 of the TSN-5G system 200, instead of having a centralized configuration controller 110 control the TSN-5G system. Configuration modules 215-a to 215-f can be interconnected in one or more topologies (mesh, star, tree), and each configuration module 215 can be responsible for communicating with and configuring one or more TSN blocks 202. In some implementations, one or more of the configuration modules 215-a to 215-f can be implemented within or as part of the functions of the control plane of the 5G system 106 (e.g., SMF 126). As used herein, "topology" can refer to one or more arrangements of a network, which may include multiple nodes in the network (e.g., transmitting devices, receiving devices, switches, or bridges) and connections between nodes (e.g., communication links or "hops," including wired or wireless communication links). Each link can communicatively couple a corresponding pair of nodes. A set of links can be sequentially coupled via their respective nodes 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 following: mesh topology, star topology, bus topology, ring topology and tree topology.

[0057] In some implementations, system 200 is configured to support and manage deterministic TSN data flows between data source 204 (“source device”) and data destination device 206 (“destination device”) via 5G system 106, based on a TSN configuration including TSN scheduling determined by one or more of the configuration modules 215. Data source 204 and data destination 206 may include one or more of I / O device 102 and controller 104. Although not shown, system 200 may also include TSN bridge 108 and other TSN components.

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

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

[0060] Memory device 404 may store a set of parameters describing the ability to support and execute data flows (e.g., carrying URLLC data traffic) through the corresponding TSN block 202. In some implementations, this set of parameters includes, but is not limited to, identification, link quality, and link bandwidth. Identification parameters may include device type (i.e., whether TSN block 202 is a TSN bridge or a TSN end station). Latency parameters may include at least port-to-port (from the beginning to the end of the TSN block) latency and latency variation (often referred to as "jitter"). Link quality parameters may include at least packet error rate. Link bandwidth parameters may include at least available bandwidth in bits per second.

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

[0062] In some implementations, the parameter set for TSN block 202 may define worst-case time synchronization error, worst-case gate operation error, maximum gating list size, maximum period time, maximum gate interval duration, transmission start delay, etc., or combinations thereof. This parameter set may include a discrete deterministic set of parameters that varies depending on the type of traffic processed by TSN block 202. This parameter set can be used at least in part to generate TSN scheduling, configuration, etc., that are hardware-implementable for TSN block 202. In the absence of such a parameter set, the TSN scheduling module must employ a least common denominator approach, where all devices in system 200 (including TSN block 202) are assumed to have the most restrictive characteristics, leading to suboptimal solutions. In this sense, the parameter set enables better scheduling solutions to be implemented in TSN system 200, resulting in improved performance metrics, including latency, jitter, packet delay variation, and bandwidth utilization.

[0063] In some implementations, the parameter set for TSN block 202 may further describe or relate to devices created, programmed, or otherwise operated by different operators or manufacturers. In this sense, the parameter set may define a collection or subset of different devices (e.g., heterogeneous devices from multiple vendors) rather than homogeneous or all-similar devices. For example, the parameter set may include, but is not limited to, definitions of specific configuration models, error tolerances, hardware limitations, software limitations, and firmware options for each end node and switching node in system 200. In this sense, the parameter set enables the scheduling and configuration of heterogeneous networks comprising devices from multiple vendors and with different characteristics.

[0064] In some implementations, the parameter set for TSN block 202 can further define specific TSN features supported by each end node and switching node in TSN system 200. For example, the parameter set can define whether a node or TSN block 202 supports one or more of the following: time synchronization, time-aware shaping, asynchronous shaping, frame duplication and elimination for reliability, frame preemption, incoming policing, and other TSN features. The parameter set can further define specific versions or variants of features or standards supported by the end nodes and switching nodes in TSN system 200. This parameter set enables the scheduling and configuration of hybrid capability networks where end nodes and switching nodes have varying degrees of support (including no support) for desired TSN features and versions.

[0065] Further non-limiting examples of the parameter set for the TSN block 202 device may include, but are not limited to, additional parameters for programming the functionality of the corresponding TSN block 202. For example, the additional parameter set may define or enable programming of the corresponding TSN block 202 using a generated or scheduled TSN configuration. Non-limiting examples of parameter sets that can define or enable programming of the corresponding 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 scheduling file formats, and combinations thereof. In this sense, the parameter set or subset of parameters defines or enables programming of the corresponding TSN block 202 using a generated or scheduled TSN configuration (collectively, “programming parameters”), and enables or allows system 200 to update, install, program, configure, or otherwise modify a set of TSN blocks 202 in response to or according to the scheduling or configuration of TSN system 200.

[0066] Additionally, each TSN block 202 may include at least one ICI 406, which is configured to support interaction between the TSN block 202 and, for example, its corresponding configuration module 215. The ICI 406 may be used to provide some or all of the parameter set of the TSN block 202 to the corresponding configuration module 215, and to receive configuration data (e.g., transport scheduling, data stream identifiers, policing rules, etc.) from the configuration module 215 to support one or more data streams passing through the TSN block 202. Each TSN block 202 may be configured to perform or operate according to the configuration data (received via the ICI 406) and to send data for each data stream according to the specifications provided in the configuration data.

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

[0068] TSN speaker information can be divided into different frequency components with varying TSN stream delay and deterministic requirements. Conversely, TSN streams from different TSN speakers can be aggregated into a single TSN stream to achieve greater capacity and higher channel utilization. Discrete cycle times in integrated TSN-5G systems help ensure the ease of TSN stream aggregation.

[0069] In some implementations, each TSN block 202 may include a transmission module 408 configured to transmit a specific data stream based on a schedule, deadline, delay budget, or data rate received from configuration data received via ICI 406 from configuration module 215. In one example where TSN block 202-1 corresponds to UE 118 of a 5G system, transmission module 408 is configured to transmit data based on resource scheduling of the 5G air interface (between UE 118 and RAN 120). The resource scheduling of the 5G air interface may be phase-aligned with the cycle time of the integrated TSN-5G system. Transmission module 408 may assign resource elements of the 5G component corresponding to TSN block 202 (of which 408 is a part) in a manner that allows scheduled transmission of each Qbv stream to be satisfied. For example, UE 118 corresponding to TSN block 202-1 may use a phase offset (reference cycle time) to align the transmission of TSN data streams with the assigned schedule, rather than using classic 802.1 Qbv-style gating. In this example, UE 118 can obtain this phase offset from RAN 120 as a special command, instead of UE 118 obtaining the phase offset from CNC.

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

[0071] Return to reference Figure 2This technical subject provides multiple distributed configuration modules 215 in a distributed controller 210 of a TSN-5G system 200. 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, CM 215-a can be responsible for TSN blocks 202-1 and 202-2 and is operatively and communicatively connected to these TSN blocks. CM 215-b can be responsible for TSN block 202-3 and is operatively and communicatively connected to this TSN block. CM 215-c can be responsible for TSN blocks 202-3 and 202-N and is operatively and communicatively connected to these TSN blocks. Therefore, TSN block 202-3 can be configured and controlled by both CM 215-b and CM 215-c. For example, a portion of the functionality at TSN block 202-3 (e.g., regarding TSN applications of the first type) can be configured and controlled by CM 215-b, while another portion of the functionality at TSN block 202-3 (e.g., regarding TSN applications of the second type) can be configured and controlled by CM 215-c.

[0072] exist Figure 2 In the example shown, configuration modules 215 are arranged in a tree structure, where CM 215-f forms the highest level of the tree structure, CMs 215-a, 215-b, and 215-c form the lowest level of the tree structure, and CMs 215-d and 215-e are located between the highest and lowest levels of the tree structure. However, configuration modules 215 are operatively and communicatively connected to each other via API 230. In some embodiments, in the tree structure (e.g., as...), Figure 2 As shown), configuration module 215 can communicate with other configuration modules 215 at adjacent tree levels (one tree level higher or lower). However, in other topologies (e.g., in mesh or peer-to-peer structures), any two configuration modules 215 of the distributed controller 210 can be directly and operatively connected to and communicate with each other.

[0073] In some implementations, each configuration module 215 may be an external utility responsible for configuring one or more corresponding TSN blocks 202, or it may be configured as a software module within the TSN block 202. Each configuration module 215 may be configured to identify the TSN block 202 controlled by the configuration module 215 and provide it with configuration data, including TSN scheduling for one or more data streams to be transmitted through the TSN block 202. 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 discrete-level ACT buckets, each corresponding to a specific data stream), maximum / minimum cycle time), configuration data including transmission scheduling for one or more TSN blocks 202 (including time offsets / durations / resources for transmission), and information for requesting resource allocation or responding to resource allocation requests. In some implementations, one or more of the configuration modules 215 may be configured as the CNC 112 and / or CUC 114 of the TSN controller 110 discussed above. In some implementations, one or more of configuration modules 215-a to 215-f may be implemented within or as part of a control plane function (e.g., SMF 126) and / or user plane element or function (e.g., 5G transport network 202-3) of the 5G system 106. For example, SMF 126 may be configured to support the functions of CUC 114 and / or CNC 112. In some implementations, 5G transport network 202-3 may be configured to support the functions of CNC 112.

[0074] In some implementations, each configuration module (CM) 215 receives some or all of the parameter set of TSN block 202 (discussed above) from ICI 406 of TSN block 202 controlled by CM 215. CM 215 also receives information about the data flow to be configured via TSN block 202 from another entity in system 200 via API 230. In a non-limiting example, data source 204 and / or data destination 206 provide CM 215 with requirements for the data flow between data source 204 and data destination 206, directly or via an intermediary such as 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, information about the data flows may include or define a set of data flows, data streams, transport paths (pre-defined or otherwise adapted), etc., to define the desired TSN communication path between data source 202 and data destination 206. A set of non-limiting examples of information about a data stream may include maximum permissible latency, data rate, data frame size (“payload”), data frame destination, bandwidth allocation gaps, etc., or combinations thereof.

[0075] Based at least on the received data stream information and the parameter set for TSN block 202, CM 215 determines a "solution" (or configuration data) that indicates how to process each data stream passing through TSN block 202. This solution may include time-aware scheduling, regulatory rules, etc., as discussed in U.S. Application No. 17 / 100,356, which is incorporated herein by reference in its entirety. CM 215 can then send the solution or configuration data to TSN block 202 via ICI 406. TSN block 202 can then execute the solution and send data for each stream according to its configuration. In some implementations, as an example process for enabling the distributed CM 215 to compute solutions, the same System Modulo Theory (SMT) solver can be used at each level of the tree structure of CM 215, where data streams and their requirements are expressed as constraints, and a linear programming method is used to solve for feasible solutions. Solutions from lower levels of the CM tree are input as used resources (again represented by constraints) to higher levels of the CM tree. Repeat this process until the top level of the CM tree is reached, where the global solution is determined.

[0076] In some implementations, different data sources (e.g., data source 204) and their applications operate with different periodic times or intervals. Correspondingly, different data sources and destinations (and their applications) require different levels of time determinism for the numerous data streams between them. In conventional TSN systems, a convergence periodic time (often referred to as the “administrative periodic time”) is determined for all data streams in the network. However, in some implementations disclosed in this subject matter, an integrated TSN-5G system can use a set of discrete / quantized periodic times in the network. Each data stream selects one of the available quantized periodic times to operate. Scheduling of scheduled transmissions in the TSN-5G system 100 can be based on a set of quantized / discrete periodic times. As an example, the integrated TSN-5G system 100 can limit the available stream intervals and therefore the corresponding periodic times to a discrete set of values, including but not limited to substantially 1, 10, 100, 1000 milliseconds. Similarly, stream or data stream requirements can be limited; for example, jitter (packet delay variation) requirements can be limited to a predetermined discrete set of values, including but not limited to substantially 1, 10, 100, 1000 microseconds. In some implementations, different discrete value sets may be used depending on the applications and use cases supported by the integrated TSN-5G system. For example, geographically dispersed systems may use discrete cycle times on the order of milliseconds. In yet another example, systems confined to a local facility may use discrete cycle times on the order of microseconds. Members of this discrete set may be regularly or irregularly spaced or follow other statistical distributions (including but not limited to logarithmic, linear, and Gaussian), rather than being assumed to be a continuous set of cycle times. In another implementation, a set of cycle times is normalized such that all TSN blocks have a cycle time as the product of elements selected from a smaller common set of prime numbers. This ensures that the TSN scheduler will easily compute all composite cycle times and produce a common network cycle time.

[0077] Each TSN block in an integrated TSN-5G system can support a set of period times (where a set may include one or more). CM 215 configures TSN-5G system 106 or 200 to enable scheduled transmission of data streams across TSN blocks 202 operating with different period times. In some implementations, TSN blocks 202 may need to operate with compatible period times, where compatibility means that the period times are integer harmonics of each other. When an application requests an interval that is not directly mapped to a set of discrete period times available on a set of TSN blocks 202 traversed by the stream, CM 215 can fit to the nearest available period time. The nearest available period time will be an integer multiple or integer divisor of the available period times. CM 215 can exchange information about the supported quantized / discrete set of period times with each other during the configuration process. In this case, this subject matter disclosure allows de-aggregated TSN-5G systems to create feasible configurations for large data streams / streams. In the absence of quantized period / intervals, configuration typically requires significant computation time and may even prevent the discovery of feasible solutions.

[0078] In some instances, each integrated TSN-5G network slice in 5G system 106 may have a predefined set of supported period times and jitter limits. In some instances, network slicing may be more granular than typical 5G network slices according to 3GPP specification 23.501, which is incorporated herein by reference. In some implementations, TSN-5G systems 106 or 200 may be sliced ​​based on TSN period times. For example, a 5G network supporting multiple critical services may have periodic URLLC slices dedicated to applications and their streams. For example, a service with an application operating at a period of approximately 1 millisecond may have a dedicated slice operating at a period time of 1 millisecond. Similarly, services and applications operating at a period (or interval) of 100 milliseconds may have dedicated slices operating at a period time of 100 milliseconds in the integrated TSN-5G system. Such period time slicing improves configuration speed and overall network performance. In some implementations, TSN block 202 exposes the supported period times of a given slice to its corresponding CM 215 via its ICI 406. CM 215 can then exchange the supported cycle times of the TSN blocks under its management with each other via the configuration module inter-module API 230 in order to create a configuration solution for the sliced ​​TSN-5G system.

[0079] In some implementations, the solution or configuration data determined by CM 215 may include, but is not limited to, a set or group of configurations, timings, commands, controls, instructions, etc., or combinations thereof, for operating the corresponding TSN block 202 according to its characteristics (e.g., characteristics defined by a parameter set). In some aspects, the configuration data may include specific transmission information for individual or collective (e.g., “global”) data frame transmissions of one or more corresponding TSN blocks 202. The transmission information may include timing information for transmitting the data frames. In one or more aspects, the configuration data for the data frames may include a transmission start time. For example, the transmission start time may be the time from which data frame transmission of the corresponding TSN block 202 is initiated. In one aspect, data frame transmission can be initiated by selectively opening a gate in the corresponding TSN block 202 for sending the data frame as a data stream to a destination node (e.g., another TSN block 202). Conversely, data frame transmission can be stopped or blocked by selectively closing a gate in the corresponding TSN block 202 for sending the data frame. The configuration data can also define or assign specific paths or links that communicatively couple the corresponding TSN block 202 and another node for transmitting data streams. Additionally, the configuration data can define the duration for transmitting the corresponding data stream from the corresponding TSN block 202. In one aspect, the duration of data stream transmission can be defined by the time interval between selectively opening the door of the corresponding node (i.e., to send data frames) and selectively closing the door (i.e., to stop transmitting data frames to the destination node).

[0080] In traditional TSN systems, TSN scheduling is represented as an absolute time offset within a periodic period, under which a TSN block is instructed to send the data. However, this can be too restrictive for a 5G system 106 composed of components from multiple vendors. In some implementations, deadline-based scheduling is determined by CM 215 and provided along with configuration data. Deadline-based scheduling can instruct TSN block 202 to send the configured data stream no later than the deadline (represented by absolute time within a periodic period). In some implementations, a delay budget-based approach instructs TSN blocks to send the configured data stream data frames within the delay budget. Therefore, under the delay budget-based approach, TSN block 202 is required to send data frames arriving at its inbound port to its outbound port within a certain duration. This scheme does not require each TSN block 202 to be time-synchronized. In some implementations where TSN block 202 is configured under rate constraints, TSN block 202 is configured to transmit data frames for a given data stream at an average or peak transmission rate (in bits per second) not exceeding a configured value (based on configuration data from CM215).

[0081] In some 5G systems, a TSN block can be a set of shared resources available through network slicing based on service profiles that define network latency and periodicity (including but not limited to latency / budget). In such implementations, two levels of scheduling can exist, where, in addition to slice-level TSN scheduling, 5GS TSN-AF can also enable the configuration of TSN block 202 as a shared resource. In either case, configuration attributes such as resource identifiers can identify the TSN block used for appropriate configuration. As an example, a service provider can have multiple service profiles with specific periodicity, and multiple tenants of the service provider can utilize the same TSN blocks as specified by the 5GS TSN-AF configuration and can perform TSN flow aggregation. In some implementations, a service provider can provide a set of non-shared TSN blocks, where only a single-layer service profile may exist. Device-specific operational / required resource sharing modes can be made available to CNC 112 via TSN-AF.

[0082] As an example implementation of the deadline / delay budget method for TSN block 202, when a data frame arrives at the incoming port of TSN block 202, TSN block 202 records the arrival time of the data frame using its local clock. TSN block 202 can then identify the frame as belonging to the configured data stream and can then start a countdown timer equal to the configured delay budget for that data stream. Using transmission module 408, TSN block 202 can prioritize transmitting data with the least remaining time. If the packet's timer expires before it is sent, the event is recorded as a missed transmission and included in the monitoring metric by recording module 410.

[0083] In some implementations, scheduling transfers between TSN block 202-1 (corresponding to UE 118) and TSN block 202-2 (corresponding to RAN 120) may involve "enhanced" allocation (assignment and transfer) of uplink and downlink transfers between UE 118 and RAN 120 to satisfy the scheduling assigned by CM 215-a to TSN block 202-1 corresponding to UE 118. In some implementations, CM 215-a may consider the buffer state and radio conditions of UE 118, as reported by RAN 120, when instantiating TSN scheduling, and may adjust or report desired changes to the requested scheduling. In some other implementations, CM 215-a may send real-time feedback to the master CM (e.g., CM 215-d) regarding radio conditions received from RAN 120. This feedback loop may support recalculation of TSN scheduling to meet the packet delay budget at that particular TSN block or across a given end-to-end path.

[0084] In this implementation, link quality can be monitored, and CM 215-a can continuously adjust radio resources in the configuration data to meet transmission scheduling. Radio resources may include, but are not limited to, logical channels, transmit power, and UE-specific time slot durations. In some implementations, fixed / deterministic uplink and downlink time slots for a given UE 118 can be statically assigned, such that, for example, all UEs connected to a given RAN slice are assigned scheduled transmission time slots. 5G native over-the-air scheduling can be used to determine whether a transmission from UE 118 will meet a transmission deadline. If not, UE 118 can request an upgrade to RAN 120 to achieve the scheduled transmission. In some implementations, scheduling of scheduled transmissions in 5G system 106 can be based on a quantized / discrete set of periodic times, wherein the set includes at least a 100-millisecond management periodic time. According to the subject matter, 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) can be sliced ​​based on periodic times. 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 slice period time. For example, a 1-millisecond period time slice would require radio resources (channel, air interface time, etc.) capable of transmitting data at a rate of 1 millisecond.

[0085] In some implementations, 5G resource elements (e.g., frequencies and time slots) can be scheduled such that they satisfy TSN flow latency requirements in addition to meeting "standard" 5G scheduling traffic priority requirements. More specifically, 5G time slots can be allocated for TSN flows such that these time slots transmit TSN flow messages at appropriate periodic time offsets (phase) and within the time constraints (TSN window time) required for TSN scheduling. In this case, the 5G scheduler differs from a "traditional" TSN Ethernet port in that multiple messages can be transmitted simultaneously if sent on different frequencies. In some aspects, in the presence of poor RF channel conditions, the 5G system 106 can transmit multiple copies of messages on different frequencies to increase the probability of meeting transmission scheduling and / or deadlines.

[0086] To achieve reliable data transmission in system 200, redundant flow paths can be implemented. The de-aggregation of TSN blocks 202 in 5G system 106 enables better handling of errors (delayed, dropped, or corrupted frames). In some implementations, UE 118 can initiate two redundant disjoint PDU sessions to UPF 122 for redundancy; in this case, 5GC can configure NG-RAN for dual connectivity according to 3GPP 38.300. In some other implementations, FRERs can be used between some TSN blocks 202 but not between others. For example, redundant streams can be implemented on the air interface between UE 118 (TSN block 202-1) and RAN 120 (TSN block 202-2) and then combined at RAN 120, and can be further split on the core network (TSN blocks 202-3, 202-4) if necessary. Figure 1 As shown, the current redundancy requirement according to 3GPP 23.501 is the maximum number of disjoint paths between UE 118 and UPF 122. However, according to the techniques of this subject matter, it is not necessary to establish redundant disjoint paths across the entire 5G system; instead, it can be implemented only for a portion of the 5G system. For example, in the case of the air interface between UE 118 and RAN 120, the redundancy requirement can specify that the two paths should be on different frequencies, different MIMO channels, or different time slots. In some instances, this subject matter discloses that allows for flexible use of redundancy, including but not limited to more than two data paths, merging and splitting data streams between TSN blocks, and supporting TSN blocks with different levels of redundancy capabilities.

[0087] The concept of dividing 5GS into multiple TSN blocks (e.g., as mentioned above) Figure 2As discussed, if strict scheduling can prevent malicious traffic from flowing between the blocks, security can potentially be enhanced. However, enabling 5GS to operate as multiple TSN blocks can introduce security vulnerabilities, primarily through configuration. Specifically, TSN users may learn internal 5GS details and connectivity affecting other users sharing the same physical and logical infrastructure. This can occur during the required TSN network discovery phase (e.g., via information returned by the link-layer discovery protocol). TSN users may also misconfigure their own or other users' configurations. This can be partially addressed using the NETCONF concept of a secure subtree, where users have a limited view of their own data model subtree. 5G systems can inherently have the concept of isolated network slices, depending on whether, for example, the TSN is implemented virtually (via software) or physically (via hardware). Infrastructure providers may have to set restrictions on the physical and logical functions open to each TSN user. This can be done via 5G network open functions. This topic discloses a solution to the security problem by using "virtual TSN blocks." A virtual TSN block is an internal 5G TSN block that contains only the capabilities provided by the user's 5G network slice. In other words, users can only see and configure the TSN block information exposed via 5G network slices, but cannot see or configure anything more. In this sense, the internal 5G TSN block is the intersection of a set of information contained in the internal TSN block and the 5G network slices provided to the user.

[0088] In some implementations, the IETF DETNET standard (as provided at IETF: “Deterministic Networking Working Group” (https: / / datatracker.ietf.org / wg / detnet / about / )) can be implemented or integrated into 5GS to interconnect smaller Ethernet islands compliant with TSN. 5GS can leverage DETNET to enable the transmission of TSN messages over IP Layer 3 (instead of Layer 2). Envisioning such a system, the technologies discussed in this disclosure include 5GS supporting DETNET edge nodes, relay nodes, and hop nodes that interconnect spatially separated TSN networks to create a larger composite TSN over 5G. All aspects of the integrated TSN-5G system provided in this disclosure are applicable to (but not limited to) 5G DETNET TSN islands, and particularly to TSN blocks that de-aggregate TSNs.

[0089] 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 into DETNET; (3) DETNET relay nodes; and (4) DETNET transit nodes: which provide congestion avoidance for time-sensitive messages. DETNET is routed rather than bridged, thus enabling routable TSN messages between TSN LANs. In the transmission between LANs, critical TSN Ethernet frame information is either transmitted or reconstructed. DETNET achieves its higher-level functions by adding sublayers: (1) DETNET service sublayer: which provides DETNET services (e.g., service protection) to higher layers in the protocol stack and applications; and (2) DETNET transport sublayer: which provides DETNET service support for DETNET flows in the underlying network (e.g., by providing explicit routing and congestion protection) and encapsulates TSN Ethernet frames. DETNET routing incorporates IP headers modified according to standard router behavior, such as Time to Live (TTL) handling, where TTL specifies the maximum time a routable IP message is allowed to live, which is clearly related to the maximum latency requirement of TSN.

[0090] DETNET components can reside within any computing element of the 5GS, specifically within the 5G MEC or core. Therefore, in one implementation, the 5GS can be a fully compatible DETNET that interconnects TSN LANs. To provide determinism, DETNET can reserve data plane resources for DETNET flows in some or all intermediate nodes along the flow path. DETNET can provide explicit routing for DETNET flows. DETNET can distribute data from DETNET flow packets temporally and / or spatially to ensure that data for each packet is delivered even if a path is lost. Therefore, as mentioned above, the TSN CNC / DNC and scheduler may require interaction with DETNET, specifically the ability to configure flow paths (including redundant flow paths) and TTL, as well as to obtain routing latency and jitter. TSN traffic shapers, time-aware shaping, and network calculus can be used to achieve the required level of determinism in 5G DETNET.

[0091] It should also be noted that a hybrid 5GS, consisting of part TSN (Layer 2) and part DETNET (Layer 3), can coexist and interoperate. In this case, the DETNET portion of the network can itself be considered as TSN block 202, as discussed above.

[0092] Furthermore, regarding caching within 5GS to minimize latency and increase the determinism of TSN applications, the storage, location, and naming of information within 5GS can be managed to minimize jitter in a way that enables fast and shorter proximity access. Each message can be cryptographically signed to enhance its security, and access can be provided through the hash of the encrypted signature and information stored in 5GS components such as MEC. The cache forwarding unit will track each data request to allow for optimal forwarding, placement, and service of cached data. The TSN CNC / DNC and scheduler can calculate where to locate cached information within the network (specifically 5GS) to maximize access and minimize jitter (packet latency variance) between 5G applications.

[0093] Real-time MEC applications typically have well-defined characteristics of their behavior. Cloud (cloud computing) and fog (fog computing) 5G MEC applications can be partitioned into microservices with hard real-time constraints, which are provided to the TSN scheduler. Constraints can be the longest (worst-case) time to complete a call to a service, or a well-defined statistical description of network computation requirements based on arrival or service curves. In some implementations, microservices can be chained together to create complete MEC applications. By decomposing computation into a series of smaller microservices, each service can be better controlled and managed, and each service can provide more determinism. Each microservice can be abstracted as an internal TSN block, consisting of deterministic inputs, outputs, schedulable operations, and coordination with 5G-TSN AF. Microservices can reside on the same or spatially distinct processing systems interconnected via communications scheduled by the TSN.

[0094] This hard real-time processing can include 5G MEC and 5G core functions. Messages entering and leaving the MEC TSN block follow a deterministic schedule that can be computed by the TSN scheduler. Note that this TSN block will be referred to as a "compute TSN block". Given that the messages generated by the MEC and their corresponding sizes and transmission times can vary depending on the computational complexity, processing load, and application state of the MEC processing tasks, the TSN scheduling component can utilize the internal model of the MEC processor to achieve TSN scheduling objectives. This model can be simulation, emulation, pure analysis, or a hybrid of each (aka 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 any cloud processing required for real-time applications, where the 5G core and cloud processing are similarly modeled by the TSN scheduler. As the effective processing rate and therefore the output message transmission time change, the TSN schedule can be dynamically recomputed as needed to maintain the determinism required for 5G TSN real-time MEC / cloud applications. Taking into account link speed, variations, processing power, available memory, etc., the TSN scheduler can provide application developers with feedback (and for management and deployment) on the optimal location of each processing component (UE, MEC, cloud) for a real-time 5G application. TSN systems can employ gate-based methods or rate control mechanisms (such as leaky buckets) and can use any number of optimization techniques or network calculus to determine feasible scheduling. Therefore, the complete flow of a TSN application will include not only the end-to-end path of a specific message across the network, but also the complete processing path through all computed TSN blocks (microservices) acting on the information in the message. IEEE 802.1CB redundant paths can be configured through redundant or parallel computed TSN blocks (microservices). In this invention, it should be possible to visualize the complete real-time processing activity encoded in TSN scheduling, where computed TSN blocks are represented as Ethernet bridges, the difference being that these computed TSN blocks either process messages or can create new messages to be sent out under deterministic scheduling.

[0095] MEC applications are configured to use NETCONF, RESTCONF, or a RESTful API to utilize TSN flows (for participation as a TSN speaker or listener). The messages defined in the aforementioned protocols contain the IEEE 802.1Qcc information required to configure the TSN flows used by the MEC application. Additionally, the MEC application is designed to migrate from one MEC platform to another, and the RESTful API is defined to query the current platform's TSN configuration to verify that it meets the required deterministic communication requirements, specifically latency and jitter. It also has a RESTful API that contains the aforementioned information required to notify the TSN CNC of its new location, as well as the information required to dynamically reschedule TSN traffic to its new location. As mentioned, IEEE 802.1CB can be used to establish redundant TSN flows to the intended location to which the MEC application can migrate. The TSN scheduler (i.e., the CNC or Distributed Network Configurator (DNC)) can be an MEC application that provides 5G TSN scheduling-as-a-service and configuration-as-a-service for dynamic rescheduling requiring low latency.

[0096] TSN applications can send timing performance profile query requests to microservices with the goal of determining statistics about 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 can at least contain the network start and end times of microservice calls, and optionally, the start and end times of all called sub-functions. This information may also include the average MEC processor load during the timing performance profile period. TSN applications can use the timing performance profile to refine TSN scheduling where microservices are required to handle TSN traffic flows. The timing performance profile can be obtained during live operation (where the output from the profile is used normally) or as a special test sample prior to live operation. The timing performance profile information can be used to determine which MEC hardware to use for current and future operations and can be used as constraint information for the TSN scheduler.

[0097] This topic disclosure also provides additional new aspects, including: (1) 5G core functions of TSN scheduling; (2) ensuring direct time synchronization between the central processing unit and the Ethernet hardware timestamp mechanism; (3) implementing TSN scheduling for specific 5G network functions and processes; (4) adding new time-aware programming features, such as time-based event processing; and (5) integrating time-based conditional processing, such as real-time programming implemented via YANG configuration for microservice scheduling to implement service chains (see https: / / www.rfc-editor.org / rfc / pdfrfc / rfc7758.txt.pdf (To obtain an example of YANG scheduling operation).

[0098] Additionally, a LinkDelayStatistic (implemented as a YANG model) cumulative distribution function data model can be implemented within the TSN-5G system 106 or 200. In this implementation, the radio links can collect information and feed it to the CNC's scheduler, which then uses this information to schedule variable-speed links. 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 accurate scheduling. The CNC can then utilize this knowledge for each TSN block to deploy the best possible TSN traffic shaping or gate scheduling, including using network calculus when determining the outcome.

[0099] This disclosure also envisions Virtualized Network Functions (VNF-TSNs) capable of residing as software within a 5G system. These may require dedicated processor hardware to support real-time operation. In some implementations, the TSN can be provided as a software-defined TSN (SDN-TSN) and 5G TSN as a service. In some implementations, VNF-TSNs can be configured within each 5G sub-component (TSN block): UE, radio head, CU / DU, RAN, MEC, core, etc. As discussed above, microservices can be chained together as part of the TSN schedule. Each microservice can expose its service time characteristics to the TSN schedule. This service is part of the latency, but it can have a larger variance than the communication link. In this implementation, the service is the link between the microservice and the TSN schedule in this integration. Network calculus can be used to incorporate processing latency. TSN inputs provide a clear arrival curve. Processor execution time provides the service curve (we assume that 5G devices have well-defined processing times).

[0100] In another aspect of this disclosure, a time-aware MEC platform is defined as a platform that acts as a PTP client (802.1AS compliant end station) and (if needed) as a PTP bridge (802.1AS compliant bridge). Virtualized MEC platforms running multiple slices (OS, VMs, containers) in parallel require PTP bridges and bridging functionality. Typically, virtual bridges / switches are used in virtualized computing platforms. In this disclosure, a virtual switch supporting TSN is defined, which includes time-aware capabilities. The time-aware PTP client in the MEC platform runs a PTP state machine and servo mechanisms to synchronize the locally available clock with the highest-level master clock in the network. Furthermore, the MEC platform synchronizes the system clock to the PTP clock, where the system includes the operating system, network stack, application stack, or any other software and hardware components that utilize the clock. This enables each MEC application to run at synchronized PTP time. In one example, the MEC host runs this PTP client and provides synchronized time (e.g., as system / host time) to all MEC applications via the virtualization infrastructure. In another instance, each MEC application can run a separate instance of a PTP client, which is connected to the host via a time-aware bridge.

[0101] As a configuration interface, 3GPP 23.501 specifies a centralized configuration model where the CNC configures the 5GS as a time-aware bridge. Similarly, the MEC platform should be able to utilize the CNC to be configured as a time-aware end station or a time-aware bridge. This MEC can support configuring TSN features using the 802.1Qcc model, including time-aware shaping, forwarding, and frame duplication and elimination for redundancy. Furthermore, the MEC host can have a CUC component that uses the 802.1Qcc interface to provide the CNC with data flow requirements for resident applications. The MEC can also provide the CNC with information about its TSN capabilities, enabling the CNC to accurately model the MEC. For example, the MEC can present itself as a TSN end station initiating a set of data flows. The CNC will then appropriately model the MEC within the network and generate the correct configuration. The MEC should support collaboration with the OS and applications to identify data streams. Specific functionalities depend on the TSN awareness capabilities of the MEC components. Non-TSN-aware applications on the MEC host require IP stream identifiers in the MEC bridge.

[0102] TSN fronthaul / backhaul (e.g., TSN block 202) can directly connect to the MEC, providing deterministic input to the MEC. However, MEC applications are destined to continuously migrate, or perhaps more intuitively, “float” to the edge of the 5G network to remain closest to the clients they may move to. Therefore, deterministic MEC applications will specify a minimum acceptable packet delay variance (MPDV) threshold. MPDV can be incorporated into the specifications of all MEC applications, which limits the viable application locations to those MEC platforms that exist as TSN blocks within 5GS. Applications must ensure that the correct TSN stream identification and translation rules are implemented on the new MEC platform (which could be a single processor or a processor subnet), so that MEC speaker / listener message frames are correctly labeled and processed. MEC applications may want to carry their own configuration instructions, where possible, for “self-installation” when migrating to a new MEC platform. It should be noted that load balancing mechanisms can be employed to ensure that users do not overload any set of MEC applications and to ensure that MEC applications are distributed optimally. In other scenarios, redundant MEC platforms and applications can be instantiated, and / or MEC applications can migrate due to noise rather than strictly due to mobility. Multiple MECs can also be connected as a TSN redundant system.

[0103] Figure 6A and Figure 6B The illustration depicts an integrated TSN-5G system 600 (similar to system 200), which includes 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 / data destination (i.e., as a TSN terminal), but is located within the 5G system 106, rather than at its edge. The TSN block 605 can be configured as a bridging terminal.

[0104] refer to Figure 8 Application data streams can span multiple integrated TSN-5G systems 805 and 810. In this case, TSN blocks can be geographically distributed, interconnecting more than one 5G system using TSN-compatible transports 820 (including but not limited to 5G backbones, private network tunnels, or other wide area networks). In this invention, TSN blocks are configured by their respective CMs 215. In some embodiments, the configuration across two TSN-5G systems 805, 810 can be coordinated via a CNC 112. In some other embodiments, the CMs 215 between the two TSN-5G systems 805, 810 can communicate directly. In some embodiments, multiple CUCs and CNCs can be used to capture user requirements and generate the TSN solutions and technologies (e.g., TSN scheduling, forwarding instructions, etc.) provided in this disclosure.

[0105] Figure 7An electronic system 700 is illustrated that can be used to implement one or more embodiments of the present subject matter. The electronic system 700 may be part of a TSN block 202 and / or a configuration module 215. The electronic system 700 may include various types of computer-readable media and interfaces for various other types of computer-readable media. The electronic system 700 includes a bus 708, one or more processing units 712, a system memory 704 (and / or a buffer), a ROM 710, a permanent storage device 702, an input device interface 714, an output device interface 706, and one or more network interfaces 716, or subsets and variations thereof.

[0106] Bus 708 collectively represents all system buses, peripheral buses, and chipset buses that communicatively connect the numerous internal devices of electronic system 700. In one or more embodiments, bus 708 communicatively connects one or more processing units 712 to ROM 710, system memory 704, and permanent storage device 702. From these various memory units, one or more processing units 712 obtain instructions to be executed and data to be processed in order to perform the processes disclosed in this subject matter. In different embodiments, the one or more processing units 712 may be a single processor or a multi-core processor.

[0107] ROM 710 stores static data and instructions required by one or more processing units 712 and other modules of electronic system 700. On the other hand, permanent storage device 702 can be a read-write memory device. Permanent storage device 702 can be a non-volatile memory cell that stores instructions and data even when electronic system 700 is powered off. In one or more embodiments, a mass storage device (such as a magnetic disk or optical disk and its corresponding disk drive) can be used as permanent storage device 702.

[0108] In one or more embodiments, a removable storage device (such as a floppy disk, flash memory drive, and its corresponding disk drive) can be used as permanent storage device 702. Like permanent storage device 702, system memory 704 can be a read-write memory device. However, unlike permanent storage device 702, system memory 704 can be volatile read-write memory, such as random access memory. System memory 704 can store any instructions and data that one or more processing units 712 may need during operation. In one or more embodiments, the processes disclosed in this subject matter are stored in system memory 704, permanent storage device 702, and / or ROM 710 (each implemented as a non-transitory computer-readable medium). From these various memory units, one or more processing units 712 retrieve instructions to be executed and data to be processed in order to perform the processes of one or more embodiments.

[0109] Bus 708 is also connected to input device interface 714 and output device interface 706. Input device interface 714 enables a user to transmit information and select commands to electronic system 700. Input devices that can be used with input device interface 714 may include, for example, an alphanumeric keypad and a pointing device (also known as a "cursor control device"). Output device interface 706 enables, for example, the display of images generated by electronic system 700. Output devices that can 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 embodiments may include a device that acts as both an input device and an output device, such as a touchscreen. In these embodiments, the feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, voice, or tactile input.

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

[0111] These functionalities can be implemented in computer software, firmware, or hardware. These technologies can be implemented using one or more computer program products. Programmable processors and computers can be included in or packaged as mobile devices. Processes and logical flows can be executed by one or more programmable processors and one or more programmable logic circuits. General-purpose computing devices, special-purpose computing devices, and storage devices can be interconnected via communication networks. The functionalities disclosed herein can be implemented using quantum computing, pulse-coupled oscillation (PCO) / Ising computing.

[0112] Some implementations include electronic components, such as microprocessors, storage devices, and memories, that store computer program instructions in a machine-readable or computer-readable medium (also known as a computer-readable storage medium, machine-readable medium, or machine-readable storage medium). Examples of such computer-readable media include RAM, ROM, read-only optical discs, recordable optical discs, rewritable optical discs, read-only digital universal discs (e.g., DVD-ROM, dual-layer DVD-ROM), various erasable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and / or solid-state drives, read-only and recordable Blu-ray® discs, ultra-high-density optical discs, any other optical or magnetic media, and floppy disks. The computer-readable medium can store a computer program that can be executed by at least one processing unit and includes a set of instructions for performing various operations. Examples of computer programs or computer code include, for example, machine code generated by a compiler and files containing high-level code executed by a computer, electronic components, or microprocessor using an interpreter.

[0113] While the above discussion primarily concerns microprocessors or multi-core processors that execute software, some implementations utilize 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 on the circuit itself.

[0114] As used in this specification and any claim of this application, the terms "computer," "server," "processor," and "memory" all refer to electronic devices or other technical devices. These terms do not include people or groups of people. For the purposes of this specification, the term "display" means display on an electronic device. As used in this specification and any claim of this application, the term "computer-readable medium" is entirely limited to tangible physical objects that store information in a computer-readable form. These terms do not include any wireless signals, wired download signals, or any other transient signals.

[0115] To provide user interaction, embodiments of the subject matter described in this specification can be implemented on a computer having a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide user interaction; for example, feedback provided to the user can be any form of sensory feedback, such as visual, auditory, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. Additionally, the computer can interact with the user by sending and receiving documents from the device used by the user; for example, 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.

[0116] The aspects of the subject matter described in this specification can be implemented in a computing system that includes back-end components (e.g., as a data server), middleware components (e.g., an application server), front-end components (e.g., a client computer with a graphical user interface or a web browser through which a user can interact with embodiments of the subject matter described in this specification), or any combination of one or more such back-end, middleware, or front-end components. Components of the system can be interconnected via digital data communication (e.g., a communication network) of any form or medium. Examples of communication networks include LANs and WANs, interconnected networks (e.g., the Internet), and peer-to-peer networks (e.g., self-organizing peer-to-peer networks).

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

[0118] The wireless network may further include a configuration module (e.g., 110 or 210) configured to determine a set of TSN parameters for at least one of the plurality of CN components. The TSN parameter set may include one or more of the following: TSN stream identifier, transmission scheduling, deadline or delay budget, filtering configuration, and redundancy scheme. In some embodiments, the processor is configured to assign one or more CN resources for the at least one of the plurality of CN components to perform data transmission according to the transmission scheduling or deadline or delay budget. In some embodiments, the configuration module is configured within a control plane component (e.g., SMF 126) of the plurality of CN components.

[0119] In some implementations, the configuration module is configured to determine a set of TSN parameters based on one or more CN attributes assigned to at least one of the plurality of CN components, wherein the one or more CN attributes are associated with discrete functions provided by at least one of the plurality of CN components.

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

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

[0122] As mentioned above Figure 2 As illustrated and discussed, the corresponding TSN block (e.g., 202-3) can be configured to receive its unique TSN parameter set from the configuration module (e.g., 215-b and / or 215-c) assigned to the corresponding TSN block from among multiple configuration modules. This unique TSN parameter set may include one or more of the following: TSN stream identifier, transmission schedule, deadline or delay budget, filtering configuration, and redundancy scheme.

[0123] In some implementations, at least one of the multiple configuration modules is configured as CUC 114 and / or CNC 112, and implemented within the SMF 126 of the control plane and / or within TSN block 202-3 (which represents the TSN configuration of the 5G transport channel 140). In implementations according to various aspects of this disclosure, wherein the 5G transport channel 140 is configured with TSN parameters, RAN 120 and UPF 122 may each be configured to support TSN speaker and / or listener functions as defined in IEEE P802.Qdj [xx]. SMF 126 / CUC 114 may be responsible for converting 5GS parameters to and from parameters in IEEE P802.1Qdj [xx]. SMF 126 / CUC 114 may be configured to communicate with the TSN speaker and / or listener in RAN 120 and UPF 122 to exchange datasets defined in IEEE P802.1Qdj [xx]. In some implementations, during the establishment or modification of a QoS flow, the SMF 126 / CUC 114 creates a speaker group and a listener group for each QoS flow as defined in Appendix Ix and sends them to the TSN CNC 112. The TSN CNC 112 uses the speaker group and listener group as input to select a path and calculate the schedule in the TSN. The TSN CNC 112 provides a status group to the SMF 126 / CUC 114. The SMF 126 / CUC 114 provides the status group to the TSN speakers and / or listeners in RAN 120 and UPF 122, respectively. Upon receiving the status group, the TSN speakers and / or listeners send data to the N3 interface according to the configuration in the status group.

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

[0125] According to various aspects of this disclosure, a system is provided (e.g., as per [reference to...]). Figure 8The illustrated and described system 100 includes a first wireless network (e.g., 805) and a second wireless network (e.g., 810). The first wireless network may include a first plurality of discrete CN components, each CN component being configured to provide discrete functions for data communication via the first wireless network, wherein at least one of the first plurality of CN components is configured to provide time-sensitive deterministic communication according to a first TSN parameter set. The second wireless network may include a second plurality of CN components, each CN component being configured to provide discrete functions for data communication via the second wireless network, wherein at least one of the second plurality of CN components is configured to provide time-sensitive deterministic communication according to a second TSN parameter set.

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

[0127] According to various aspects of this disclosure, a method is provided that includes configuring at least one (or each) of a plurality of CN components of a wireless network (e.g., a 5G network) using a TSN parameter set of a TSN mechanism, such that the at least one (or each) of the plurality of CN components supports or provides time-sensitive deterministic communication as a TSN block in the TSN network, based on the TSN parameter set. The at least one CN component may be a 5G transport network channel connecting the RAN and UPF.

[0128] The method may further include, for example, determining a TSN parameter set for the at least one of the plurality of CN components at one or more configuration modules. The TSN parameter set may include one or more of the following: TSN stream identifier, transmission schedule, deadline or delay budget, filtering configuration, and redundancy scheme. The method may further include assigning one or more CN resources for the at least one of the plurality of CN components to perform data transmission according to the transmission schedule or deadline or delay budget. The method may also include monitoring data transmission performed by at least one of the plurality of CN components and reporting any changes to the TSN parameter set or one or more CN attributes to the configuration module, wherein the TSN parameter set is updated based on the reported changes.

[0129] Edge computing is computing performed at or near the physical location of a user or data source. Edge computing includes MEC (Multi-access Edge Computing), which is specified in ETSI GS MEC 003 V3.1.1 (2022-03). The 3GPP 5G System Edge Computing Enhancement; Phase 2 (3GPP TS 23.548 Release 17.2.0) specifies how UEs will discover and utilize MEC resources via the network. The specification entitled "Architecture for Enabling Edge Applications" (3GPP TS 23.558 Release 17.6.0) specifies how ETSI MEC adapts to 3GPP 5GS. ETSI GS MEC 003 V3.1.1 (2022-03), 3GPP TS 23.548 Release 17.2.0, and 3GPP TS 23.558 Release 17.6.0 are incorporated herein by reference in their entirety. In addition, MEC; Traffic Management API ETSI GS MEC 015 V2.2.1 (2022-12), MEC; Radio Network Information API ETSI GS MEC 012 V2.2.1 (2022-02), and MEC; Edge Platform Application Enablement ETSI GS MEC 011 V3.1.1 (2022-09) are incorporated herein by reference in their entirety.

[0130] Edge applications (or edge-enabled applications) are becoming increasingly distributed, and scaling (e.g., using multiple servers distributed across multiple edge layers to execute a single application) is becoming a technology for achieving more advanced architectures. In some implementations, edge applications facilitate network services (e.g., edge services) via edge networks (e.g., distributed computing infrastructure, as described further below), which include network devices (e.g., UEs, 3GPP networks, edge servers, etc.). Network services (e.g., edge services) are provided by service providers and can be requested by network devices (e.g., UEs). Edge applications provide edge computing capabilities and can include any number and / or type of microservices, where each microservice runs in its own process / computation and communicates using protocols (e.g., HTTP resource APIs) to provide edge services. Thus, each microservice can provide different functionalities for the edge application. Such microservices are chained together to create a complete edge application and can be configured as a logical channel consisting of deterministic inputs, outputs, and schedulable operations combined with TSN scheduling communication. However, how TSN will be integrated into edge-enabled computing (applications) as specified in 3GPP specifications has not yet been discussed.

[0131] To address the problems discussed above, this subject matter provides a system associated with a communication network configured to support time-sensitive deterministic communication based on a TSN mechanism. The system includes multiple network devices configured to provide functionality for enabling edge-enabled applications to provide edge services. The edge-enabled applications include microservices distributed and implemented on network resources within the communication network. Each microservice is configured to provide a different process function of the edge-enabled application. A controller is configured to acquire application performance parameters associated with one or more process functions of the application and determine a TSN schedule based on the application performance parameters, such that the one or more process functions are configured to process data streams for the edge application based on the TSN schedule.

[0132] Figure 9 An exemplary architecture for enabling applications is illustrated according to one or more implementations.

[0133] The architecture 900 used to enable applications is called EDGEAPP, which is defined in 3GPP TS 23.558. In some implementations, the applications include edge-enabled applications. Here, edge-enabled applications include MEC applications (or 5GMC applications) as discussed above. In some implementations, architecture 900 is deployed in an integrated manner within systems (e.g., 100, 200, 600) associated with communication networks according to specifications defined by 3GPP (e.g., 5G, 6G, etc.) to support time-sensitive deterministic communication based on TSN mechanisms (e.g., 106). Therefore, all the functionality associated with the 3GPP-defined specifications that provide MEC applications can be applied to this architecture 900 in a similar manner. The system includes multiple network devices (or entities) configured to provide functionality for enabling one or more applications to provide one or more network services (e.g., edge services). These multiple network devices are configured to communicate with each other via the 3GPP core network 920. In some implementations, the 3GPP core network 920 is a wireless network according to specifications defined by 3GPP (e.g., a 5G network or system 106). In some implementations, the 3GPP core network 920 refers to a network or system that may include the plurality of network devices. These network devices include UE 910 (e.g., UE 118), Edge Application Server (EAS) 930, Edge Enabled Server (EES) 940, and Edge Configuration Server (ECS) 950. In some implementations, the 3GPP core network 920 may operate as a network device to provide edge services. UE 910 includes Application Client (AC) 910-1 and Edge Enabled Client (EEC) 910-2. In some implementations, EAS 930 and EES 940 are included within an Edge Data Network (EDN) 960. In some implementations, EAS 930, EES 940, and ECS 950 may be referred to as edge servers. In some implementations, EDN 960 may be part of the 3GPP core network 930, or a separate and / or independent network configured to support communication between EAS 930 and EES 940. In some implementations, these multiple network devices may interact with each other as specified in 3GPP TS 23.558. For example, ECS 950 provides configuration related to EES940, including details of the EDN hosting EES 940. AC 910-1 may interact with EAS930 via the 3GPP core network 920, and EEC 910-2 may interact with EES 940 and ECS 950 via the 3GPP core network 920. EAS 930, EES940, and ECS 950 may interact with the 3GPP core network 920.

[0134] EDGE-x represents a reference point that enables interaction between multiple network devices, as specified in 3GPP TS 23.558. For example, reference point EDGE-1 enables interaction between EES 940 and EEC 910-2. Reference point EDGE-2 enables interaction between EES 940 and 3GPP core network 920 functions and APIs for obtaining network capability information. Reference point EDGE-3 enables interaction between EES 940 and EAS 930. Reference point EDGE-4 enables interaction between ECS 950 and EEC 910-2. Reference point EDGE-5 enables interaction between AC 910-1 and EEC 910-2. Reference point EDGE-6 enables interaction between ECS 950 and EES 940. Reference point EDGE-7 enables interaction between EAS 930 and 3GPP core network 920 functions and APIs for obtaining network capability information. The EDGE-8 reference point enables interaction between the ECS 950 and the 3GPP core network 920 functions and APIs to obtain network capability information. The EDGE-9 reference point enables interaction between the two EES 940s.

[0135] Figure 10 An exemplary architecture for enabling applications is illustrated according to one or more implementations.

[0136] Figure 10 The architecture 1000 described in the text includes Figure 9 The architecture (EDGEAPP) 900 described in the document. Figure 10 This illustrates how EDGEAPP (3GPP SA6 architecture) and ETSI MEC architecture 970 (e.g., MEC 605) can complement each other, as shown in Figure C.2-1 of Informative Appendix B of 3GPP TS 23.558 Release 17.6.0 and in 3GPP TS 23.958 Release 18 V1.1.0 (2023-09). Figure 5 As shown in .2-1. 3GPP TS 23.958 version 18 V1.1.0 (2023-09) is incorporated herein by reference in its entirety. Figure 10 This demonstrates how to view ETSI MEC within the context of 5GS. The MEC platform and applications in the ETSI MEC architecture 970 can reside in 5G edge devices (e.g., EAS 930, EES 940), as close as possible to the UE 910 and as directly connected as possible to the 5G user data plane to minimize overhead. However, 5GS adds new functionalities to allow the UE 910 to discover and manage applications within the MEC 970.

[0137] Figure 11 An exemplary API for enabling an application is illustrated according to one or more implementations.

[0138] like Figure 11 As shown in block diagram 1100, the API is used to expose capabilities utilized by one or more network devices (EAS930, EES940, and ECS950) in an architecture (e.g., architecture 900, architecture 1000) defined by 3GPP TS 23.558 for enabling applications (e.g., edge-enabled applications). In some implementations, the 3GPP core network 920 is configured to expose its network capabilities to one or more network devices (EAS930, EES940, ECS950), and one or more network devices are configured to expose their capabilities to meet the needs of edge-enabled application operations (or edge service operations).

[0139] Figure 12 An exemplary architecture for enabling applications is illustrated according to one or more implementations. Figure 12 The diagram illustrates a layered application architecture with a general service enablement layer architecture and application enablement server functionality available at the edge in communication between UE-1 (e.g., UE 910) and the edge data network (e.g., EDN 960) via a 3GPP network system (e.g., 3GPP core network 920), as specified in 3GPP TS 23.558.

[0140] Figure 13 The illustration shows a flowchart for service provision according to one or more embodiments.

[0141] Figure 13 Flowchart 1300 illustrates the operation of network devices for service provisioning as specified in 3GPP TS 23.558. Service provisioning allows the configuration of information about available network services (e.g., edge computing services or edge services) for the EEC 910-2 based on the location, service requirements, service preferences, and connectivity of the managed UE. This configuration includes address information required for the EEC (e.g., 910-2) to establish a connection with the EES (e.g., 940).

[0142] In operation 1310, UE 910 is given configuration information that enables it to connect to ECS 950. In operation 1320, UE 910 can then request initial provision from ECS 950 to obtain the configuration required to connect to EDN 960. In operation 1330, once provided, UE 910's EEC (e.g., 910-2) registers with the selected EES from the list of provided EES 940 received from ECS 950, if the EEC registration configuration in the EES profile indicates that EEC registration is required. In operation 1340, UE 910 further consumes network services (edge ​​computing services) and performs various operations such as EAS discovery, edge application communication, application context relocation (ACR), etc. In operation 1350, while UE 910 is consuming network services, several triggers may occur that could result in service provision being triggered by UE 910 or by ECS 950.

[0143] The triggers used for service provision are categorized as follows: A. Examples of triggers at UE 910 include: AC910-1 related updates available at EEC 910-2 due to AC installation / reinstallation; AC 910-1 requesting application server access (e.g., via an internet browser); EEC 910-2 supporting one or more AC 910-1s potentially being updated due to EEC reinstallation; and the expiration of the EDN configuration information's lifetime, or EEC 910-2 detecting that UE 910 has moved out of the EDN service area in the EDN configuration information. B. Examples of triggers at ECS 950 include: EES 940 updates received due to EAS 930 installation / reinstallation / relocation; and ECS 950 receiving EDN / DNAI change notifications from 5GC 920 for UE 910 when ECS 950 subscribes to user plane path management events.

[0144] Following the operations for service provision, a registration process is performed to allow entities in the edge deployment to transmit information to other entities, as specified in 3GPP TS 23.558. For example, the registration process includes registration of the EEC to the EES 940, registration of the EAS to the EES 940, and registration of the EES to the ECS 950. During the EAS registration process, the EAS 930 determines that registration with the EES 940 is necessary. The EAS 930 sends an EAS registration request to the EES 940. This request should include an EAS profile and may include a proposed expiration date for registration. In some implementations, the EAS profile includes information about the EAS 930 used to describe the services and service characteristics provided. The EAS profile may be provided by the application service provider, and the EAS profile includes EAS service key performance indicators (KPIs). EAS service KPIs provide information about the service characteristics of the network services provided by the EAS 930, such as application parameters associated with one or more procedural functions of edge-enabled applications. The table below includes EAS service KPIs as specified in 3GPP TS 23.558.

[0145]

[0146] The EES 940 performs an authorization check to verify whether the EAS 930 has the authorization registered on the EES 940. Upon successful authorization, the EES 940 stores the EAS profile for later use (e.g., for serving EAS discovery requests received from the EEC), and replies to the EAS 930 with an EAS registration response.

[0147] Following the registration process, a discovery process is performed, as specified in 3GPP TS 23.558. This discovery process enables entities in the edge deployment to obtain information about EAS 930 and its available services based on specified criteria of interest. EAS discovery enables EEC 910-2 to obtain information about available EAS 930s of interest (e.g., instantiated EAS registered with EES 940, and instantiable EAS 930s that can be created as needed). EAS discovery is based on matching the EAS discovery filters provided in the request.

[0148] When multiple EAS 930s are discovered for a specific AC 910-1, EEC 910-2 can select one or more EAS 930s to enable communication between the AC and one of the selected EAS 930s. The selection algorithm is not within the scope of this specification. Once an EAS 930 is selected, EEC 910-2 can subscribe to ACR event notifications at the EES 940 of the selected EAS 930, as specified in 3GPP TS23.558. EDN configuration information received from ECS 950 can be used to establish a connection to the EAS 930.

[0149] EAS discovery can be initiated by EEC 910-2 when a certain triggering condition at UE 910 is met. The EAS discovery process includes a request-response procedure and a subscription-notification procedure for EAS discovery and EAS dynamic information subscription. During the request-response procedure, EES 940 can send an EAS discovery response to EEC 910-2. This EAS discovery response includes the EAS profile and EAS service KPIs.

[0150] Figure 14 The diagram illustrates a data flow diagram of data provided with the controller according to one or more embodiments.

[0151] Applications (e.g., edge-enabled applications) can be partitioned into microservices. In some implementations, microservices are small, independent process functions (or service functions) that communicate with each other. In some implementations, microservices describe an architectural approach to software development that constructs an application from loosely coupled services that communicate with each other via APIs or messaging protocols. Each microservice is autonomous and self-contained and runs a unique process. Microservices are typically designed to be stateless, meaning they do not maintain any state across calls. They process requests without retaining any state information. This means that stateless microservices are “forgetful.” In other words, no “memory” of previous transactions is stored after a completed transaction. As shown in box 1410, microservices operate with hard real-time constraints and are configured as communication channels that transform data flowing through the channels for the application. Microservices are distributed across available network resources (e.g., 5G UE 118, MEC and 5G core, and any cloud processing) and are executed to provide process functions. Such microservices are chained together; a microservice is configured to receive input data, process that data, and output the processed data to the next microservice corresponding to the next process in the processing chain. Therefore, such inputs and outputs should be provided in a deterministic manner to reduce latency throughout the application's overall process functionality.

[0152] As discussed above, the controller can configure each microservice as an internal TSN block (or computed TSN block), consisting of deterministic inputs and outputs based on TSN scheduling. Therefore, the process functions provided by the microservice are configured to support the deterministic data flow of the application. In some implementations, the controller further considers application performance parameters (e.g., EAS service KPIs) associated with one or more functions of the edge-enabled application to determine the TSN scheduling. As discussed above, each application (e.g., a 3GPP edge-enabled application) will be required to publish its own key performance indicators (e.g., EAS service KPIs). In some implementations, key performance indicators may be referred to as application performance parameters. As discussed above, key performance indicators include KPIs for the maximum response time published for AC 910-1 service requests. In some implementations, both the edge application (as a whole) and each component microservice have a maximum response time, which is the time from receiving all necessary inputs to generating an output message on its outgoing port. The TSN controller (or controller 110) currently processes the scheduling of messages once they arrive at the output port. The TSN controller is scheduling processing time to ensure deterministic message generation at the output. In some implementations, the TSN controller has application performance parameters, including a maximum response time that includes message processing time and message transmission time. The TSN controller can also generate a more comprehensive application performance schedule. In some implementations, the maximum response time includes the round-trip time of request packets from AC 910-1 or EEC 910-2 and response packets from EES940, as well as the processing time at the server (e.g., EAS 930) and the time required for that server (e.g., EAS 930) to consume 3GPP core network capabilities (if present). In some implementations, the controller (e.g., TSN controller 110, TSN scheduler) is configured to discover, collect, and utilize key performance metrics such as information about the maximum response time of edge services provided by the application to determine the TSN schedule, in which the application's microservices are considered communication channels that happen to transform data flowing through the channel. Therefore, microservices are configured to process data for the application based on TSN scheduling to carry complete data streams (e.g., TSN streams). Consequently, the controller can be enhanced to create not only feasible deterministic flows through the network, but also feasible deterministic processing chains within the network, where KPIs for maximum response time are incorporated into the TSN scheduler algorithm to compute feasible schedules.

[0153] In some implementations, if there is no automated process for providing configuration information (network services, application performance parameters) in real time, a human operator manually provides the required network services (e.g., edge services) to the controller, and calculates the TSN schedule using the manually provided network services and the application performance parameters for each network service (e.g., maximum response time for each network service). There is also a maximum required rate as part of the edge application server API, and this must also be satisfied by the TSN scheduler's algorithm. However, the TSN scheduler can also be made more intelligent and enabled to infer which edge applications are needed.

[0154] In some implementations, as shown in boxes 1430, 1430-1, and 1430-2, a fitness function can be provided to the controller, which can then discover which combination of edge application services is needed and in what order to achieve the optimal solution fitness. The fitness function is only used in optional enhancements where artificial intelligence / machine learning (AI / ML) methods are used to learn the appropriate combination of microservices and scheduling to achieve optimal performance. In some implementations, the system may include an AI / ML module to execute the fitness function. In some implementations, the AI / ML module / function may be embedded in controller 110. The fitness function is a specific type of objective function used to generalize the closeness of a given design solution to achieving a set objective to a single quality factor. This can be used in some type of genetic algorithm, swarm intelligence, or other AI-based techniques, as well as simple gradient descent. The optimal solution may require more than just sequential edge service processing (e.g., microservices); it may require the scheduler to enable parallel edge service processing where feasible. In some implementations, microservices are considered atomic components (indivisible parts) of the edge application. An edge application is a single application composed of smaller, modular microservices. The optimal solution may also require the combination of inputs from parallel edge services, or the splitting of results from a single edge process (a single edge service or a single edge application). Therefore, a microservice is considered an atomic (indivisible) component of a potentially larger edge service. An edge service can be broken down into smaller microservices. Such smaller microservices represent smaller independent process functions or smaller independent edge services. Therefore, the controller can split and merge process functions (e.g., microservices) within a process. However, this is analogous to the splitting and merging that occurs for redundant parallel TSN streams in IEEE 802.1CB, and can be easily handled by the controller (e.g., the TSN scheduler). For example, the controller can determine whether to merge at least two microservices into a single microservice (a larger process). For example, the controller can determine whether to split a single microservice into multiple sub-microservices (smaller processes).

[0155] Monitoring and managing the edge services will also be necessary for the system (e.g., 100, 300). In some implementations, as shown in box 1440, the system may include a monitoring module to monitor the performance of the edge services (edge-enabled applications). As shown in box 1450, performance monitoring is typically subscription-based, i.e., non-requestive, rather than polling-based. In some implementations, subscription-based monitoring simply means that a client or user must register (request) to receive notifications. There are many examples of subscription-based protocols; for example, an SNMP client can register to receive TRAP messages. Therefore, it is necessary to characterize the types of events for which the subscription is of interest. In some implementations, as shown in box 1440-1, the monitoring module may perform time-bound characterization. Time-bound characterization is a characterization associated with deterministic communication and processing (e.g., TSN) and may include any event that exceeds a specified time bound. In other words, time-bound characterization means determining which types of events should be monitored and whether that event has exceeded a specified time bound. In some implementations, the event is a condition or state of the system of interest, or an anomalous condition (network state) that requires investigation or adaptation of the system to correct. Often, too many events cannot be monitored simultaneously, so the system can filter which events are actually reported. In this case, an event is defined as the state of the system when a message takes longer than expected. These are often anomalies that may require further investigation to resolve or fix. In some implementations, specifying time bounds means assigning time constraints to microservices. In some implementations, the monitoring module can monitor edge services (or edge-enabled applications) by characterizing the events to be monitored during processing and determining whether these events exceed specified time bounds. Characterizing time bounds is crucial for achieving a perfect level of specificity. Receiving too many events will incur overhead, while too few may lead to life-threatening control errors. A typical approach to characterizing time bounds is to request all events within a relatively wide bound, generate a histogram, and determine how to refine the characterization based on the distribution obtained from the histogram. This assumes that the edge processing computer (MEC) is synchronized with the network time. Therefore, there must be a way to confirm which time domain the MEC is synchronized to. Processing in the MEC may not be as deterministic as processing in the network. Processing may also be divided into individual tasks (e.g., microservices or process functions) that can be monitored and characterized independently. Therefore, there may be multiple time distributions that can be monitored and characterized. In some implementations, the monitoring module can monitor each microservice by characterizing it based on specified time boundaries. Therefore, the application is divided into microservices, and each microservice is monitored and characterized.

[0156] In some implementations, as a possible hardware configuration, the MEC (e.g., 605) may have a TSN host interface from which the MEC guarantees deterministic output. In this case, it may only be necessary to configure the TSN flows entering and leaving the MEC. In this scenario, there is deterministic data exchange between the UE (e.g., 910) and the MEC. The UE is then responsible for sending and receiving TSN messages at precisely the correct time. A UE's failure to send at the correct time will cause the MEC to miss the necessary inputs required to generate the correct output. In such a case, the MEC may either not respond or respond with a null message or an error message at the correctly scheduled time. More complex arrangements of UE and MEC interconnection with TSN flows may exist, where the probability of error increases with the size of such a system. If processing time varies excessively within the edge application, it may be necessary to modify the TSN scheduling to accommodate this situation. This would likely violate the terms of service provided by the published edge application KPIs and should be documented for forensic and billing purposes.

[0157] Edge applications are likely to exist as part of a real-time feedback loop. Therefore, edge services are configured to support data communication between source and destination devices. According to the standard, TSN streams are considered unidirectional end-to-end streams. Therefore, any producer-consumer (sensor-actuator) system will require at least two distinct TSN streams, and potentially many more when utilizing edge microservices. For example, one of these at least two distinct TSN streams might be from the sensor to the control system controller and from the control system controller to the actuator. The controller must ensure that events in any such loop are properly phased relative to each other. For example, all microservices must begin operating at a precise offset from common absolute time. In some implementations, the controller configures the microservices to send at least two distinct TSN streams between the source and destination devices.

[0158] The impact of UE movement (or other events) on edge application relocation needs to be minimized. Several methods can achieve this. One approach is to establish multiple parallel TSN flows to possible addresses that can change location. Another approach requires the edge server to announce a potential relocation within a sufficient timeframe to enable the controller (TSN scheduler) to recalculate the new schedule. In other words, there must be a sufficient minimum warning time. For example, the controller is configured to recalculate the new TSN schedule when at least one network device is relocated.

[0159] In some implementations, controllers (e.g., CUC 114 and CNC 112) may reside in 5GS as edge application services and will be required to publish their own KPIs, including maximum request rate, maximum response time, availability, available compute, available graphics compute, available memory, available storage devices, and connection bandwidth according to Table 5.2.2-1 of 3GPP TS 28.538 V18.1.0 (2022-12), which is incorporated herein by reference in its entirety.

[0160] Figure 15 The illustration shows a flowchart of an example method for providing edge services according to one or more embodiments.

[0161] Flowchart 1500 describes the operations for providing edge services in systems (e.g., 100, 900) associated with a communication network configured to support time-sensitive deterministic communication based on a TSN mechanism.

[0162] These operations include operation 1510, which retrieves application performance parameters associated with the edge application from multiple network devices (e.g., 910, 930, 940, 950, 960, etc.). In some embodiments, the multiple network devices are configured to provide functionality for enabling the edge application. In some embodiments, the edge application includes microservices distributed and implemented on network resources in the communication network, and each microservice is configured to provide different procedural functions of the edge application. As discussed above, the controller (110) is configured to discover, collect, and retrieve application performance parameters (e.g., KPIs for edge services) provided by the edge application. Application performance parameters include, but are not limited to, information about the maximum response time for providing network services by the application. In some embodiments, information about the maximum response time includes, but is not limited to, the round-trip time of request and response packets for the edge service, the processing time at at least one network device, and the time required for the at least one network device to consume communication network capacity.

[0163] These operations include operation 1520, which determines a TSN schedule based on the application performance parameters, such that the one or more process functions are configured to process data streams for edge-enabled applications based on the TSN schedule. In some implementations, the controller may determine whether to merge at least two microservices in a microservice into a single microservice. In some implementations, the controller may determine whether to split an edge service into microservices. In some implementations, the system may include a monitoring module configured to monitor edge-enabled applications. In some implementations, the monitoring module may determine whether an event associated with a process function indicates an exceedance of an associated specified time limit. In some implementations, the event indicates the state of the system when the process function takes longer than a specific time limit, and the specified time limit refers to the time constraint assigned to the process function. In some implementations, the monitoring module is configured to monitor each process function (e.g., each microservice). In some implementations, the controller is configured to recalculate a new TSN schedule in response to a change in the geographic location of at least one network. In some implementations, the communication network is a wireless network according to specifications defined by 3GPP.

[0164] In some embodiments, a non-transitory computer-readable medium storage device is configured to store one or more instructions that, when executed by a processor, cause the processor to perform... Figure 15 The method described in [the document / article].

[0165] Figure 16 A block diagram of an example system according to one or more embodiments is shown.

[0166] Figure 16 A non-limiting example of system 1600 is illustrated, in which architecture 900 is deployed in an integrated manner. System 1600 is similar to systems 100, 200, and 600, which are associated with communication networks according to specifications defined by 3GPP (e.g., 5G, 6G, etc.) to support time-sensitive deterministic communication based on TSN mechanisms. Generally, system 1600 is configured as a deterministic TSN system to provide one or more process functions of edge-enabled application 1620 in a deterministic manner using controller 110 and monitoring module 1630. In some implementations, controller 110 is referred to as a TSN controller and includes CUC 114 and CNC 112 as discussed above. Figures 9 to 15As discussed above, system 1600 is configured based on standard methods for time synchronization and for enabling edge-enabled applications. For example, system 1600 includes multiple network devices (e.g., UE 1650 and edge server 1610) configured to provide the capability to enable edge-enabled application 1620. In some embodiments, UE 1650 includes UE 910, UE 118, etc. In some embodiments, edge server 1610 includes EAS 930, EES940, and ECS 950, as discussed above. UE 910 and edge server 1610 can communicate with each other via a 3GPP core network 1640 as specified in 3GPP TS 23.558. In some embodiments, the 3GPP core network 1640 is a communication network according to specifications defined by 3GPP (e.g., 106, 920). In some implementations, the 3GPP core network 1640 may include the plurality of network devices (e.g., UE 1650, edge server 1610). In some implementations, the 3GPP core network 1640 may not include the plurality of network devices (e.g., UE 1650, edge server 1610) and may be configured as separate components (e.g., network devices) to provide edge services. As discussed above, the edge enabling application 1620 may be divided into a plurality of microservices 1620-1, 1620-2, 1620-3, and 1620-4. Each microservice is configured to provide different process functions or service functions of the edge enabling application 1620 to provide complete edge services. The plurality of microservices 1620-1, 1620-2, 1620-3, and 1620-4 reside within system 1600. The multiple microservices 1620-1, 1620-2, 1620-3, and 1620-4 are linked together such that the inputs provided to each microservice and the outputs from each microservice are provided in a deterministic manner to reduce latency throughout the process functionality of the edge-enabled application. Therefore, controller 110 is configured to determine TSN scheduling to support the deterministic process performed by the multiple microservices. As discussed above, each edge-enabled application is required to publish its application performance parameters (e.g., EAS KPIs as specified in 3GPP TS23.558) associated with one or more process functions of the edge-enabled application by edge server 1610. In some implementations, controller 110 obtains the application performance parameters and determines the TSN scheduling based on those parameters. Therefore, each of the multiple microservices 1620-1, 1620-2, 1620-3, and 1620-4 can be configured as a TSN block based on the TSN schedule, such that one or more process functions provided by microservices 1620-1, 1620-2, 1620-3, and 1620-4 are configured to process data streams for edge-enabled applications based on the TSN schedule.Such TSN blocks 1620-1, 1620-2, 1620-3, and 1620-4 are referred to as computed TSN blocks. As discussed above, the controller can manually acquire application performance parameters associated with one or more process functions of an edge-enabled application.

[0167] In some implementations, system 1600 may include a monitoring module 1630. As discussed above, monitoring module 1630 is configured to monitor the performance of edge-enabled applications. Therefore, monitoring module 1630 is configured to communicate with controller 110 and 3GPP core network 920. In some implementations, monitoring module 1630 is configured to characterize events related to deterministic communication and processing (e.g., TSN scheduling) that may occur throughout the processing and to determine whether such events exceed specified time limits. In some implementations, monitoring module 1630 may monitor each microservice by characterizing events based on TSN scheduling. In some implementations, monitoring module 1630 provides monitoring results to the controller, and the controller may reschedule TSN scheduling based on these monitoring results. The monitoring results may include any changes in the geographical location of the UE. The monitoring results may include location (e.g., movement within a region) or link status (creation of a new link or deletion of an existing link).

[0168] Various embodiments of this disclosure are described in accordance with the following terms.

[0169] Article 1: A system associated with a communication network configured to support time-sensitive deterministic communication based on a time-sensitive networking (TSN) mechanism, the system comprising: a plurality of network devices configured to provide functionality for enabling edge-enabled applications to provide edge services, the edge-enabled applications including microservices distributed and implemented on network resources in the communication network, each microservice being configured to provide a different process function of the edge-enabled application; and a controller configured to: acquire application performance parameters associated with one or more process functions of the edge-enabled application, and determine a TSN schedule based on the application performance parameters, such that the one or more process functions are configured to process data streams for the edge-enabled application based on the TSN schedule.

[0170] Article 2: The system according to Article 1, wherein: the application performance parameters include the maximum response time associated with the edge-enabled application; and the maximum response time includes the round-trip time for request and response packets for the edge service, the processing time of at least one network device, and the time required for the at least one network device to consume communication network capabilities.

[0171] Article 3: The system according to Clause 1, wherein the controller is configured to determine whether to merge at least two microservices in the microservices into a single microservice.

[0172] Article 4: The system according to Clause 1, wherein the controller is configured to determine whether to split the edge service into the microservice.

[0173] Article 5: The system according to Article 1 further includes: a monitoring module configured to monitor the edge-enabled application at least by determining whether an event associated with a process function indicates that a specified time limit has been exceeded, wherein: the event indicates the state of the system when the process function takes longer than the specified time limit, the specified time limit being a time constraint assigned to the process function.

[0174] Article 6: The system according to Clause 5, wherein the monitoring module is configured to monitor each of the one or more process functions.

[0175] Article 7: The system according to Article 1, wherein: the edge-enabled application is configured to support the time-sensitive deterministic communication from the sensor to the actuator; and the controller configures the microservice to send at least two distinct TSN streams between the sensor and the actuator.

[0176] Article 8: The system according to Article 1, wherein the controller is configured to recalculate a new TSN schedule in response to a change in the geographical location of at least one network device.

[0177] Article 9: The system described in Clause 1, wherein the communication network is a wireless network according to the specifications defined by 3GPP.

[0178] Article 10: A method for providing edge services in a system associated with a communication network, the communication network being configured to support time-sensitive deterministic communication based on a time-sensitive networking (TSN) mechanism, the method comprising: obtaining application performance parameters associated with one or more process functions of an edge-enabled application from a plurality of network devices, the plurality of network devices being configured to provide functionality for enabling the edge-enabled application, the edge-enabled application comprising microservices distributed and implemented on network resources in the communication network, each microservice being configured to provide a different process function of the edge-enabled application; and determining a TSN schedule based on the application performance parameters, such that the one or more process functions are configured to process data streams for the edge-enabled application based on the TSN schedule.

[0179] Article 11: The method according to Article 10, wherein: the application performance parameters include the maximum response time associated with the edge-enabled application; and the maximum response time includes the round-trip time for request and response packets for the edge service, the processing time of at least one network device, and the time required for the at least one network device to consume communication network capabilities.

[0180] Article 12: The method described in Article 10 further includes determining whether to merge at least two of the microservices into a single microservice.

[0181] Article 13: The method described in Article 10 further includes determining whether to split the edge service into the microservice.

[0182] Article 14: The method according to Article 10 further includes: monitoring the edge-enabled application at least by determining whether an event associated with a process function indicates that a specified time limit has been exceeded, wherein: the event indicates the state of the system when the process function takes longer than the specified time limit, the specified time limit being a time constraint assigned to the process function.

[0183] Article 15: The method described in Article 14, wherein the monitoring includes monitoring each of the one or more process functions.

[0184] Article 16: The method according to Article 10, wherein: the edge-enabled application is configured to support the time-sensitive deterministic communication from the sensor to the actuator.

[0185] Article 17: The method described in Article 16 further includes: configuring the microservice to send at least two different TSN streams between the sensor and the actuator.

[0186] Article 18: The method described in Article 10 further includes recalculating a new TSN schedule in response to a change in the geographical location of at least one network device.

[0187] Article 19: The method described in Article 10, wherein the communication network is a wireless network according to the specifications defined by 3GPP.

[0188] Article 20: A non-transitory computer-readable medium storage device configured to store one or more instructions, which, when executed by a processor, cause the processor to perform the method described in accordance with Article 10.

[0189] Those skilled in the art will understand that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein can be implemented as electronic hardware, computer software, or a combination of both. To illustrate this interchangeability between hardware and software, the various illustrative blocks, modules, elements, components, methods, and algorithms have been described above generally according to their functionality. Whether this functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the system as a whole. The described functionality can be implemented in different ways for each specific application. Without departing from the scope of the subject matter, the various components and blocks can be arranged in different ways (e.g., arranged in different orders, or partitioned in different ways).

[0190] It should be understood that the specific order or hierarchy of steps in the disclosed process is an illustration of the example method. Based on design preferences, it should be understood that the specific order or hierarchy of steps in the process can be rearranged. Some of these steps may be performed simultaneously. The appended method claims present the elements of each step in an illustrative order and are not intended to limit one to the presented specific order or hierarchy.

[0191] The preceding description is provided to enable any person skilled in the art to practice the various aspects described herein. The preceding description provides various examples of the subject matter, and the subject matter is not limited to these examples. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein may also be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but are intended to conform to the full scope consistent with the language of the claims, wherein reference to an element in the singular is not intended to mean “one and only one,” but rather “one or more,” unless specifically stated otherwise. Unless specifically stated otherwise, the term “some” refers to one or more. Masculine pronouns (e.g., his) include feminine and neutral genders (e.g., her and its), and vice versa. Titles and subtitles (if any) are used for convenience only and do not limit the disclosure described herein.

[0192] The predicates “configured as,” “operable for,” and “programmed as” do not imply any specific tangible or intangible modification to the subject, but are intended to be used interchangeably. For example, a processor configured to monitor and control operations or components can also mean that the processor is programmed to monitor and control operations, or that the processor is operable for monitoring and controlling operations. Similarly, a processor configured to execute code can be interpreted as being programmed to execute code or being operable for executing code.

[0193] As used herein, the term "automatic" can include actions performed by a computer or machine without user intervention; for example, actions performed in response to instructions made by a predicate action by a computer or machine or other initiation mechanism. The word "example" is used herein to mean "serving as an example or illustration." Any aspect or design described herein as an "example" is not necessarily to be construed as being more preferred or advantageous than other aspects or designs.

[0194] For example, phrases such as "aspect" do not imply that such an aspect is essential to the art, or that such an aspect applies to all configurations of the art. Disclosure relating to one aspect may apply to all configurations or one or more configurations. One aspect may provide one or more examples. For example, phrases such as "one aspect" may refer to one or more aspects, or vice versa. For example, phrases such as "embodiment" do not imply that such an embodiment is essential to the art, or that such an embodiment applies to all configurations of the art. Disclosure relating to one embodiment may apply to all embodiments or one or more embodiments. One embodiment may provide one or more examples. For example, phrases such as "one embodiment" may refer to one or more embodiments, or vice versa. For example, phrases such as "configuration" do not imply that such a configuration is essential to the art, or that such a configuration applies to all configurations of the art. Disclosure relating to one configuration may apply to all configurations or one or more configurations. One configuration may provide one or more examples. For example, phrases such as "one configuration" may refer to one or more configurations, or vice versa.

[0195] All structural and functional equivalents of the elements throughout the various aspects described in this disclosure that are known or subsequently known to a person skilled in the art are expressly incorporated herein by reference and are intended to be covered by the claims. Furthermore, nothing disclosed herein is intended to be offered to the public, whether or not such disclosure is expressly stated in the claims. No claim element shall be construed in accordance with 35 USC § 112(f) unless the element expressly states the phrase “means for” or, in the case of a method claim, uses the phrase “step for”.

Claims

1. A system associated with a communication network configured to support time-sensitive deterministic communication based on a time-sensitive networking (TSN) mechanism, the system comprising: Multiple network devices are configured to provide functionality for enabling edge-enabled applications to provide edge services. The edge-enabled applications include microservices distributed and implemented on network resources within the communication network. Each microservice is configured to provide different process functions for the edge-enabled application; as well as The controller is configured to: Obtain application performance parameters associated with one or more process functions of the edge-enabled application, and The TSN schedule is determined based on the application performance parameters, such that the one or more process functions are configured to process data streams for the edge-enabled applications based on the TSN schedule.

2. The system according to claim 1, wherein: The application performance parameters include the maximum response time associated with the edge-enabled application; and The maximum response time includes the round-trip time for request and response packets for the edge service, the processing time of at least one network device, and the time required for the at least one network device to consume communication network capabilities.

3. The system of claim 1, wherein, The controller is configured to determine whether to merge at least two microservices into a single microservice.

4. The system according to claim 1, wherein, The controller is configured to determine whether to split the edge service into the microservice.

5. The system according to claim 1, further comprising: A monitoring module is configured to monitor the edge-enabled application at least by determining whether an event associated with a process function indicates that a specified time limit has been exceeded, wherein: The event represents the state of the system when the process function takes longer than the specified time limit. The specified time limit refers to the time constraint assigned to the process function.

6. The system according to claim 5, wherein, The monitoring module is configured to monitor each of the one or more process functions.

7. The system according to claim 1, wherein: The edge-enabled application is configured to support time-sensitive deterministic communication from the sensor to the actuator; and The controller configures the microservice to send at least two different TSN streams between the sensor and the actuator.

8. The system according to claim 1, wherein, The controller is configured to recalculate a new TSN schedule in response to a change in the geographical location of at least one network device.

9. The system according to claim 1, wherein, The communication network is a wireless network defined according to the specifications of 3GPP.

10. A method for providing edge services in a system associated with a communication network configured to support time-sensitive deterministic communication based on a time-sensitive networking (TSN) mechanism, the method comprising: Application performance parameters associated with one or more process functions of an edge-enabled application are obtained from multiple network devices configured to provide functions for enabling the edge-enabled application, which includes microservices distributed and implemented on network resources in the communication network, each microservice being configured to provide a different process function of the edge-enabled application. as well as The TSN schedule is determined based on the application performance parameters, such that the one or more process functions are configured to process data streams for the edge-enabled applications based on the TSN schedule.

11. The method of claim 10, wherein: The application performance parameters include the maximum response time associated with the edge-enabled application; and The maximum response time includes the round-trip time for request and response packets for the edge service, the processing time of at least one network device, and the time required for the at least one network device to consume communication network capabilities.

12. The method of claim 10, further comprising determining whether to merge at least two of the microservices into a single microservice.

13. The method of claim 10, further comprising determining whether to split the edge service into the microservice.

14. The method of claim 10, further comprising: The edge-enabled application is monitored at least by determining whether an event associated with a process function indicates that a specified time limit has been exceeded, wherein: The event represents the state of the system when the process function takes longer than the specified time limit. The specified time limit refers to the time constraint assigned to the process function.

15. The method according to claim 14, wherein, The monitoring includes monitoring each of the one or more process functions.

16. The method of claim 10, wherein: The edge-enabled application is configured to support the time-sensitive deterministic communication from the sensor to the actuator.

17. The method of claim 16, further comprising: Configure the microservice to send at least two different TSN streams between the sensor and the actuator.

18. The method of claim 10, further comprising recalculating a new TSN schedule in response to a change in the geographical location of at least one network device.

19. The method according to claim 10, wherein, The communication network is a wireless network defined according to the specifications of 3GPP.

20. A non-transitory computer-readable medium storage device configured to store one or more instructions, which, when executed by a processor, cause the processor to perform the method according to claim 10.

Images