Data communications management component and method for performing guaranteed performance data communications

Abstract

According to one embodiment, in a data processing device configured to execute a plurality of applications and having physical ports to a communication network, a data communications management component is described, configured to establish an internal network of components connecting the applications to the physical ports between them. The data communications management component is further configured to generate a representation of the internal network as a network of data link layer interfaces according to a data communications protocol for data communications with guaranteed performance and provide the generated representation to a network controller, the network controller being configured to provide control information for the data link layer interfaces to enable data communications according to the data communications protocol, and further configured to receive control information (e.g., scheduling) for the data link layer interfaces of the representation generated by the controller and configure the internal network of the data processing device according to the control information.

Description

[Technical Field]

[0001] The present disclosure relates to a data communications management component and method for performing data communications. [Background technology]

[0002] IEEE Time Sensitive Networking (TSN) is a family of standards used to enable deterministic communication. It provides non-negotiable time bounds for end-to-end transmission latency and jitter. As such, it includes components to provide synchronization, reliability, latency, and resource management.

[0003] A fully centralized TSN control plane is comprised by a Centralized Network Configurator (CNC) and a Centralized User Configurator (CUC), which provide configuration and control information (e.g., related to scheduling) to TSN interfaces on network devices and TSN Talker / Listeners (data processing devices), respectively. Fully distributed configuration and a centralized network / distributed user model for configuration of network devices and TSN Talker / Listeners are also possible. Summary of the Invention

[0004] However, data processing devices may run multiple applications and have complex internal structures for routing application traffic between interfaces, physical ports, and applications, and as a result, the data processing device does not simply map to a single TSN interface where scheduling information is provided.

[0005] Therefore, in the case of complex internal structures of data processing devices running multiple applications, mechanisms are desired that allow supporting data communication technologies and protocols such as TSN (generally a data communication protocol for data communication with guaranteed performance).

[0006] According to one embodiment, in a data processing device configured to execute a plurality of applications and having a physical port to a communications network, there is provided a data communications management component configured to establish an internal network of components of the data processing device, to make available to each application data intended for that application received from the communications network via the physical port, and to provide to the physical port, for each application, data that the application intends to send via the communications network, and to enable communication between the applications through the internal network.

[0007] The data communications management component is further configured to generate a representation of the internal network as a network of data link layer interfaces according to a data communications protocol for data communications with guaranteed performance and provide the generated representation to a network controller, the network controller being configured to provide control information for the data link layer interfaces to enable data communications according to the data communications protocol, and further configured to receive scheduling information for the data link layer interfaces of the representation generated by the scheduler and configure the internal network of the data processing device according to the scheduling information.

[0008] The data communications management component is further configured to generate a representation of the internal network as a network of data link layer interfaces according to a data communications protocol for data communications with guaranteed performance and provide the generated representation to a network controller, the network controller being configured to provide control information for the data link layer interfaces to enable data communications according to the data communications protocol, receive scheduling information for the data link layer interfaces of the representation generated by the scheduler, and configure the internal network of the data processing device according to the scheduling information.

[0009] According to another embodiment, a method is provided for performing data communications in accordance with the data communications management component described above. [Brief explanation of the drawings]

[0010] In the drawings, like reference numbers generally refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention. In the following description, various aspects are described with reference to the following drawings: [Figure 1] 1 illustrates a communication system for providing TSN. [Figure 2] 1 shows the queuing structure of a TSN port when 802.1Qbv is used. [Figure 3] The TSN control plane for a fully centralized system is shown. [Figure 4] 1 shows host machines hosting virtualized and non-virtualized applications published to a CUC. [Figure 5] Refers to a host machine on which multiple virtual network functions (VNFs) are deployed in the form of virtual machines. [Figure 6] 1 illustrates a TSN deployment according to one embodiment. [Figure 7]1 illustrates the operation of a TSN Manager Function (TMF) according to one embodiment. [Figure 8] 1 illustrates a first mode for configuring the internal TSN network of a host machine. [Figure 9] A second mode for configuring the internal TSN network of a host machine is shown. [Figure 10] 1 illustrates the operation of a TSN Proxy Function (TPF) according to one embodiment when management and orchestration based on the ETSI NFV-MANO framework is used. [Figure 11] A flow diagram illustrating the creation of an (abstract) TSN talker that includes the ETSI NFV-MANO framework is shown. [Figure 12] A flow diagram showing the configuration of a virtual TSN (vTSN, virtual TSN) talker is shown. [Figure 13] 1 shows a first deployment model for TPF. [Figure 14] A second deployment model for TPF is presented. [Figure 15] A third deployment model for TPF is presented. [Figure 16] A deployment model is shown where each TPF communicates with a single TMF. [Figure 17] Illustrates a deployment model where a TPF communicates with multiple TMFs. [Figure 18] We present a deployment model that takes into account the framework of the O-RAN (Open Radio Access Network) Alliance. [Figure 19] 1 shows a flow diagram illustrating a method for performing data communications according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0011] The following detailed description refers to the accompanying drawings, which show, by way of example, specific details and aspects of the present disclosure in which the invention may be practiced. Other aspects may be utilized, and structural, logical, and electrical changes may be made, without departing from the scope of the present invention. Various aspects of the present disclosure are not necessarily mutually exclusive, as some aspects of the present disclosure may be combined with one or more other aspects of the present disclosure to form new aspects.

[0012] Various examples corresponding to aspects of the present disclosure are described below.

[0013] Example 1 is the data communications management component mentioned above.

[0014] Example 2 is the data communications management component of example 1, where the data communications management component is configured to provide the generated representation to a management and orchestration system external to the data processing device and to receive data communications protocol information from the orchestration and management system regarding traffic requirements for one or more of the applications.

[0015] Example 3 is the data communications management component of example 1 or 2, wherein the guaranteed performance includes at least a guaranteed maximum latency and / or a guaranteed maximum jitter.

[0016] Example 4 is the data communications management component of any one of Examples 1-3, wherein the plurality of applications includes at least one application running in a virtual machine on the data processing device and / or at least one application running in an application containerization container on the data processing device.

[0017] Example 5 is the data communications management component of any one of Examples 1-4, wherein the applications include at least one application running in a virtual machine on the data processing device and / or at least one application running in a container on the data processing device, and the data communications management component is configured to map a connection point abstraction of the application's virtual network interface card to one of the data link layer interfaces.

[0018] Example 6 is the data communications management component of any one of Examples 1-5, wherein one of the data link layer interfaces is attached to a physical port, and an internal network connects each application to another of the applications and to the data link layer interface attached to the physical port.

[0019] Example 7 is the data communications management component of any one of Examples 1-6, wherein the data processing device includes a plurality of physical ports and a plurality of sets of applications, each application associated with one of the interfaces of the internal network, and the component's internal network, for each application, makes available to the application data received from the communications network via the interface associated with that application and provided to the interface associated with that application data that the application intends to transmit via the communications network.

[0020] Example 8 is the data communications management component of any one of Examples 1-7, configured to establish and manage an internal network of components of the data processing device according to data communications requirements received from a proxy component that manages the mapping of each of the applications to a corresponding data communications endpoint of a data communications protocol.

[0021] Example 9 is the data communications management component of any one of Examples 1-8, wherein the data link layer interface is a time-sensitive networking-enabled interface.

[0022] Example 10 is the data communications management component of example 9, wherein the network controller is a centralized user configurator or a centralized network configurator with time-sensitive networking.

[0023] Example 11 is the data communications management component of any one of Examples 1 to 10, wherein the communications network is Ethernet.

[0024] Example 12 is a method for performing data communications in a data processing device running multiple applications and having physical ports to a communications network, including the steps of establishing an internal network of components of the data processing device, making available to each application, for each application, data destined for that application received from the communications network via the physical port, and for each application, providing to the physical port data that the application intends to send via the communications network, thereby enabling communication between the applications through the internal network; generating a representation of the internal network as a network of data link layer interfaces in accordance with a data communications protocol for data communications with guaranteed performance; providing the generated representation to a network controller, the network controller providing scheduling information for the data link layer interfaces to enable data communications in accordance with the data communications protocol; receiving scheduling information for the data link layer interfaces of the representation generated by the scheduler; and configuring the internal network of the data processing device in accordance with the scheduling information.

[0025] It should be noted that one or more features of any of the above examples may be combined with any one of the other examples. In particular, examples described in relation to devices are equally valid for methods.

[0026] According to further embodiments, there is provided a computer program and computer readable medium comprising instructions which, when executed by a computer, cause the computer to perform the method of any one of the above examples.

[0027] Various examples are described in more detail below.

[0028] FIG. 1 shows a communication system 100 for providing TSN functionality.

[0029] In this example, communication system 100 includes a server 101 connected to a router 103 via a first TSN switch 102. It should be noted that the TSN switch implements a TSN bridging function. These terms are used interchangeably herein.

[0030] The router 103 is connected to the Internet 104. The communication system 100 further includes first terminal devices 105, each of which is connected to the router 103 via a respective second TSN switch .

[0031] Additionally, in this example, a second terminal device 107 is connected to the router 103 via a third switch 108 .

[0032] The server 101 and the terminal devices 105, 107 are (TSN) endpoint devices (typically called TSN Talkers or TSN Listeners).

[0033] Each switch 102 , 106 , 108 can be considered to be a connection point between the router 103 and a respective local area network that includes one or more of the endpoint devices 101 , 105 , 107 .

[0034] Endpoint devices 101, 105, switches 102, 106, 108, and router 103 support TSN communication capabilities. TSN communication is communication between endpoints 101, 105, and 107 (one acting as a TSN talker and the other acting as a TSN listener). Endpoint device 107 may send / receive TSN traffic without supporting TSN communication capabilities. In this case, device 108 is the entry point to the TSN network.

[0035] TSN is a Layer 2 technology. Therefore, it resides below the network layer (Layer 3) and above the physical layer (Layer 1). For example, MPLS (Multiprotocol Label Switching), IPv4 / 6, etc. can run on top of TSN. It should be noted that the embodiments described herein are overlay network technology agnostic.

[0036] TSN functionality can operate on Ethernet ports (physical ports) of switches, routers, and endpoints in accordance with IEEE 802.1Q. TSN functionality can also be supported at the interface level attached to a physical port. Thus, TSN functionality may be implemented on each physical port 109. In other words, a TSN port (also called a TSN interface or virtual (TSN) port) 109 may be attached to each physical port or connected to other TSN ports.

[0037] To support TSN communication, the devices involved (terminal devices, routers, and switches) provide TSN ports (e.g., TSN 802.1Qbv ports). While the description of the embodiments focuses on TSN, it should be noted that the features described herein may also be applied to other guaranteed performance technologies, i.e., the embodiments may be generalized to other guaranteed performance technologies besides TSN.

[0038] FIG. 2 shows the queuing structure of a TSN (output) port, i.e. the functionality provided by a TSN port (or TSN interface) according to 802.1Qbv.

[0039] According to the queuing structure, there are eight gates 201 (in this example, according to 802.1Q2018). Each gate 201 is opened and closed according to a gate control list (GCL) 202.

[0040] Each network interface 201 is associated with a traffic class and has an associated queue 203 into which data of the traffic class is queued for transmission through the network interface 201. Additionally, a transmission selection algorithm 204 (e.g., a credit based shaper (CBS)) may be implemented for each network interface that serves to shape the traffic in the respective queue 203. A transmission selection mechanism 205 transmits data from the open network interface over a physical layer, e.g., an Ethernet PHY.

[0041] Figure 3 shows the TSN control plane.

[0042] As mentioned above, the TSN talker 301 and the TSN listener 302 may be connected via multiple TSN-enabled devices 303 (e.g., switches 102, 106, 108, or even corresponding to a router 103 with TSN bridging functionality).

[0043] Non-TSN talkers 304 and listeners 305 may also be connected to the TSN switch 303. According to a fully centralized model, a Centralized User Configurator (CUC) 305 configures the TSN talkers 301 and listeners 302 for TSN. A Centralized Network Configurator (CNC) 306 configures the switch 303 for TSN. Embodiments are also fully distributed but applicable when a centralized network / distributed user model according to 802.1Qcc is used.

[0044] CUC305 assumes that TSN applications (i.e., (software) applications that send or receive TSN traffic) are independent of each other.

[0045] However, within a host machine (or host device, i.e., an end device, e.g., a computer, that has a physical layer port to a communications network (e.g., Ethernet) that is external to the end device), TSN may operate at different levels (e.g., on a virtual interface within the kernel of a virtual machine, on a virtual interface on the host machine created by a virtual switch of a hypervisor, on an interface attached to a physical port, etc.).

[0046] FIG. 4 shows a host machine 400 (eg, a server).

[0047] A host machine 400 hosts two virtual network functions (VNFs) 401, 402. From a TSN perspective, these are TSN applications. The host machine hosts a further TSN application (e.g., another type of program that sends / receives TSN traffic) 403. Each VNF 401, 402 runs on a respective virtual machine 404, 405.

[0048] The host machine 400 has a physical port 406 (for example, an Ethernet port) and is connected to a switch 407 via the physical port.

[0049] The host machine 400 has an internal TSN network 408 that provides connectivity between TSN applications 401, 402, and 403 (denoted as "TSN App 1" through "TSN App 4") and also between applications 401, 402, and 403 and other applications external to the host through physical port 406. This includes virtual or regular interfaces and TSN interfaces 409 on physical ports. To achieve TSN functionality at the interface level, multiqueuing functionality enables support of TSN features such as 802.1Qbv in software and the execution of appropriate QoS mapping handlers. For interfaces attached to physical ports, a multiqueuing driver in the host machine 400 enables the network card to support this. The internal TSN network 408 may include additional components such as (e.g., Linux) bridges and OVS (Open Virtual Switch). Thus, the internal TSN network 408 may have a complex structure. Furthermore, in this example, the virtual machine 404 includes a TSN node 413. In the example of Figure 4, the TSN ports are attached to the two left physical ports.

[0050] Typically, however, the CUC 305 or CNC 306, respectively, will assume a simple structure such as that shown by 411 in the figure. For example, for the structure shown by box 416 of a TSN port and Linux bridge of TSN network 408 and a TSN node 413 of virtual machine 404, the CUC 305 or CNC 306, respectively, will assume that one (abstract) TSN node 414 hosting a TSN application is connected to the TSN network through a TSN port.

[0051] Furthermore, according to the ETSI NFV framework, for each VNF and each Virtual Link (VL) between two VNFs, an (abstract) Connection Point (CP) is defined as indicated by 412 in the figure.

[0052] Therefore, in such a scenario the following problems arise: 1. How to expose a VNF to the TSN control plane as a regular TSN talker / listener 2. How to map the abstract CP of a VNF to a virtualized TSN port (i.e., a TSN port implemented in software), in other words, how to translate a VNF into a TSN application. 3. How VNFs and associated orchestration and management entities (e.g., ETSI Network Functions Virtualization Management and Orchestration (NFV-MANO)) are connected to TSN control plane entities 4. How to address TSN multiplexing and TSN layers at the TSN node level (i.e., within a TSN node) 5. How to hide the complexity of the host node's internal TSN network from the TSN control plane 6. How CUC configures the TSN App when running on a shared virtualization infrastructure.

[0053] Figure 5 illustrates these issues for a host machine 500 on which three VNFs 501, denoted VNF1, VNF2 and VNF3, are deployed in the form of virtual machines and which has two physical ports 502 implementing TSN functions, denoted as port "1" and port "2", each connected to a respective physical port 503 of a switch 504. The switch 504 is connected via a further port 505 to a communications network 506 (which has a further switch 507).

[0054] As an example, assume that a first VNF ​​601 has two (TSN data) flows f1.1 and f1.2, VNF 602 has data flow f2, and VNF 603 has data flow f3.

[0055] Therefore, the VNF (as a TSN application) notifies the CUC as follows: VNF1: "Has f1.1 and f1.2" VNF2: "has f2" VNF3: "has f3" As shown, assume that VNF1 and VNF2 use port 1, and VNF3 uses port 2.

[0056] Therefore, CUC hereby notifies CNC as follows: From port 1: "has f1.1 and f1.2" From port 2: "has f3" As described with reference to FIG. 4 , host machine 500 has an internal TSN network 508 with TSN port 509 for connecting VNF 501 to physical port 502. Furthermore, VNF1 includes TSN port 510. Traditionally, the CUC and CNC are unaware of the existence of a local (i.e., internal) TSN network 508 within host machine 500. Therefore, traditionally, there is no management and control by the CUC and CNC over this TSN network 508. Furthermore, traditionally, the CUC and CNC are unaware of the TSN interface (from an additional perspective) provided by a VM-based TSN-aware application node with TSN port 510.

[0057] Therefore, traditionally, the CNC considers all VNFs together as being connected by one TSN port, so VNF CPs are not isolated from each other.

[0058] To address this issue and issues 1-6 above, various embodiments introduce a TSN Manager Function (TMF) and a TSN Proxy Function (TPF) (and the interface between the two), as shown in FIG. 6.

[0059] FIG. 6 illustrates a TSN deployment according to one embodiment.

[0060] The TSN architecture includes a host machine 600 that, similar to the host machine 400, hosts two virtual network functions 601, 602 and one or more further TSN applications 603, where each VNF 601, 602 runs on a respective virtual machine 604, 605. Typically, the host machine (or host device 600) hosts containerized or VM-based VNFs, but also other (non-VNF) applications deployed on the host machine operating system (similar concepts apply to bare metal containers and hypervisors).

[0061] Additionally, like host machine 400, host machine 600 has a physical port 606 (e.g., an Ethernet port) connected to a TSN switch 607 and has an internal TSN network 608 that provides connectivity between TSN applications 601, 602, 603 and between TSN applications 601, 602, 603 and physical port 606.

[0062] The TSN architecture further includes a TSN Manager Function (TMF) 609. The TMF 609: Manage the internal TSN network 608 (e.g., perform Create, Read, Update, Delete (CRUD) operations on managed objects and OAM (Operation, Administration and Maintenance)). Handles the deployment and supports the lifecycle management of the TSN stack deployed on either virtual or physical ports or virtual machines or containers on the host machine 600. Thus, the TMF 609 is responsible for creating, deploying, and managing abstract TSN resources for the VNFs 601, 602 deployed on top of the VMs 604, 605 or containers. Manages the mapping of host interfaces and bridges to virtual interfaces within VMs 604 and 605. Mapping abstract TSN resources to software or hardware-based TSN nodes.

[0063] Furthermore, the TSN architecture includes a TSN Proxy Function (TPF) 610. The TPF 610: Manages the creation and lifecycle of abstract TSN talkers / listeners mapped to VNFs. Acts as an intermediary between the TSN control plane (including the CUC 611 and CNC 612), the TMF 609 deployed on the physical node, and the virtualization management and orchestration system 613, such as ETSI NFV-MANO or O-RAN SMO (Service Management and Orchestration). For example, the TPF facilitates interaction with the TSN control plane without disrupting normal TSN control plane operation.

[0064] The TMF 609 and TPF 610 can be implemented as a single software entity running inside or outside the host machine 600. The operation of the TMF 609 and TPF 610 enables the creation and operation of a TSN overlay network. When considering the ETSI NFV framework, the VNFD (Virtual Network Function Descriptor) and NSD (Network Service Descriptor) may be updated to enable stream-level description for time-critical (or other guaranteed performance required) streams. In such cases, updates are introduced to the processes between the VIM (Virtualized Infrastructure Manager) and the NFVI (Network Functions Virtualization Infrastructure), which are responsible for host management and control to build the underlying Layer 2 network.

[0065] FIG. 7 illustrates in more detail the operation of the TMF 700 according to one embodiment.

[0066] The TSN Manager Function (TMF) 700 acts as a resource manager 701 and performs internal network virtualization and TSN resource abstraction and management 701. In particular, it: Responsible for creating and managing the internal TSN network structure (creating bridges, multi-queue interfaces, adding these to VMs, etc.). Responsible for OAM of abstract TSN resources and TSN node ports considered by the VNF. For example, it may analyze the internal TSN network and report back to the TSN-aware VIM for TSN OAM. Analyze TSN related CP / VL / VDU (Virtual Deployment Unit) requirements from VIM / NFVI (SDN (Software-Defined Networking)) or TPF. The control entity may operate as part of the TMF 700 that is used to decide and respond to requests from the orchestrator or VIM such as "Where can I add VNF-4?" This affects affinity and anti-affinity rules for the deployed VNFs. Preserve isolation and define TSN boundary controls for VNFs. Performs monitoring and lifecycle management, e.g., regarding security, and is responsible for upgrading VNF TSN interfaces (e.g., adding new TSN interfaces / capabilities to VNFs / VMs). In particular, it is responsible for the lifecycle management of TSN ports and TSN resources within the internal network.

[0067] Additionally, the TMF 700 supports mapping of VNF CPs 707 to internal TSN network TSN ports 703 and exposes these to the TPF or VIM 708. In the illustrated example, a first TSN port 705 supports 802.1Qbv and a second TSN port 706 performs preemption (802.1Qbu). One CP 707 considered by the VNF may be attached to TSN port 703 or 705 and operate under 802.1Qbv, while another CP 707 may be attached to an 802.1Qbu TSN port.

[0068] With respect to the actual TSN configuration of the ports (e.g., providing a gate control list in the case of 802.1Qbv), the TMF 700 can support two modes for TSN configuration of the internal TSN network 608 of the host machine 600.

[0069] FIG. 8 shows a first mode for configuring an internal TSN network 801 of a host machine 800.

[0070] According to this first mode, the TMF 802 contains a scheduler that locally resolves the schedule provided by the CUC (directly or via the TPF), and also performs the mapping to the correct TSN ports and physical ports, thus enabling local TSN resolution (if hierarchical TSN nodes exist within the host machine 800).

[0071] FIG. 9 shows a second mode for configuring the internal TSN network 901 of a host machine.

[0072] In this mode, the CNC 902 has a global view, including the structure of the internal TSN network 901 (without necessarily being aware that the internal TSN network 901 is running within the host machine). The TMF 903 still manages the internal TSN network 901, and the CNC 902 configures it (e.g., provides GCLs to TSN ports of the internal TSN network 901, possibly via intermediate components 904). The TMF 903 may fully or partially expose the structure of the internal TSN network 901.

[0073] FIG. 10 illustrates in more detail the operation of the TPF 1000 according to one embodiment.

[0074] The TPF 1000, together with the TMF 1001, runs on a virtual machine 1007 and enables TSN programmability of the VNF 1002 hosted by the host machine 1004.

[0075] The TSN control plane (specifically, CUC 1005), through its interaction with TPF 1000, sees only TSN talkers and listeners running on host machines 1004, such as VNFs 1002 and further (non-VNF) TSN applications 1006.

[0076] The TPF 1000 creates an abstract TSN endpoint that is mapped to the VNF or TSN application (for each VNF and each TSN application deployed on the host machine 1004). It exposes TSN endpoints for the VNFs 1002 and TSN applications 1006.

[0077] The TPF 1000 is further responsible for analyzing TSN-related stream requirements (from the VNF 1002 or the virtual machine 1007 on which the VNF 1002 is running) and sending these to the TMF 1001 (e.g., to optimize the local TSN network design).

[0078] The TPF 1000 is aware of all TSN applications 1002, 1006 and their TSN configuration and ability to run on the host machine 1004.

[0079] For each VNF 1002 and (non-VNF) TSN application, the TPF 1000 also passes the TSN configuration received by the CUC to the TMF. The TPF 1000 and TMF 1001 jointly orchestrate the actual configuration of the TSN application (e.g., TSN App 1) based on the CUC configuration. The internal TSN network configuration depends on the mode described in the previous figures.

[0080] Furthermore, a management and orchestration system based on, for example, the ETSI NFV-MANO framework may be considered. For example, a VIM 1009 (connected to a VNFM (VNF Manager) 1010 and an NFVO (NFV Orchestrator) 1011) may be connected to an OSS (Operation Support System) 1012 and communicate with the TMF 1001 as follows: Direct: VIM → (Network controller such as SDN1013) → TMF Via TPF: VIM → TPF → TMF FIG. 11 shows a flow diagram 1100 illustrating the creation of a VNF-based TSN talker when considering the ETSI NFV-MANO framework.

[0081] For example, as shown in Figure 10, OSS 1101, NFVO 1102, VNFM 1103, VIM 1104, TSN application 1105 (hosted by VNF), TPF 1106, TMF 1107 and CUC 1108 are involved in the flow.

[0082] At 1109, the OSS 1101 sends a request to the NFVO 1102 to instantiate VNFs with reference to the respective VNFDs. The NFVO 1102 parses the VNFDs at 1110 and triggers the VNFM 1103 to create the corresponding VNFs at 1111. The VNFs host TSN applications 1105.

[0083] At 1112, the VNFM 1103 or TSN application 1105 notifies the TPF 1106 that a new TSN application 1105 is hosted by the VNF. At 1113, the TPF 1106 creates an (abstract) TSN endpoint (listener or talker) for the TSN application 1105. At 1114, the TPF 1106 establishes a connection between the established TSN endpoint and the CUC 1108 (i.e., the TSN application 1105).

[0084] At 1115, the NFVO 1102 sends a request for a TSN capable connection point (CP) to the VIM 1104, which forwards the request to the TMF 1107 at 1116. It should be noted that the VIM 1104 can also forward the request to the TPF 1106, which then forwards it to the TMF 1107. The NFVO request to the VIM for a CP can also be initiated by the VNFM towards the VIM.

[0085] At 1117, the TPF 1106 connects to the TSN application 1105 in the manner of a CUC. At 1118, the TSN application 1105 passes the stream requirements to the TPF 1106, which forwards them to the TMF 1107 at 1119 and to the CUC 1108 at 1120.

[0086] At 1121, the TMF 1107 performs TSN resource allocation, which includes creating or updating an internal TSN network (including interfaces between components of the TSN network).

[0087] At 1122, the TPF 1106 and TMF 1107 perform mapping between connection points and virtual and / or physical TSN ports and TSN resource allocations.

[0088] At 1123, the TMF 1107 sends the status notification to the VIM 1104 (possibly via the TPF 1106), which at 1124 forwards the status notification to the NFVO 1102, which at 1125 forwards the status notification to the OSS 1101. If a request to the VIM for a CP is initiated by the VNFM, the status notification is sent to the VNFM.

[0089] FIG. 12 shows a flow diagram 1200 illustrating the configuration of a TSN talker hosted in a VNF according to a first configuration mode when considering the ETSI MANO architecture.

[0090] For example, as shown in FIG. 10, OSS 1201, NFVO 1202, VNFM 1203, TSN application or virtual network function 1205, TPF 1205, TMF 1206, CUC 1207 and CNC 1208 are involved in the flow.

[0091] At 1209, the CNC 1208 determines the TSN configuration and sends it to the CUC 1207 at 1210.

[0092] At 1211, the CUC 1207 forwards the configuration to the TPF 1205.

[0093] At 1212, the TPF 1205 parses the configuration for configuration information of the abstract TSN ports mapped to the abstract VNF ​​CPs and forwards the found configuration information to the TSN application or virtual network function 1204 at 1213. Additionally, at 1214, the TPF 1205 forwards the configuration information to the TMF 1206.

[0094] At 1214, the TSN application or virtual network function 1205 performs application or thread behavior tuning according to the configuration information provided by the TPF 1205.

[0095] At 1216, the TMF 1206 generates configuration information for the TSN port resources in the internal network and configures them accordingly at 1217.

[0096] At 1218, the TMF 1206 sends an indication of the operational status of the TSN ports used in the internal network to the TPF 1105.

[0097] At 1219, the TMF 1206 sends an indication of the operational status of the TSN ports used in the internal network to the TPF 1205, and the TPF 210 notifies the CUC 1207 about the configuration status.

[0098] FIG. 13 shows a first deployment model for the TPF.

[0099] In this deployment model, the TPF 1301 and the TMF 1302 are separated. The TPF 1301 functions as a TSN plug-in. For example, the TSN plug-in may be implemented inside the SDN controller.

[0100] FIG. 14 shows a second deployment model for the TPF.

[0101] In this deployment model, a local TSN proxy instance 1401 runs within each VNF 1402 or TSN application 1403.

[0102] FIG. 15 shows a third deployment model for the TPF.

[0103] In this deployment model (from an implementation perspective), the TMF 1501 and the TPF 1502 are realized as a single software entity, i.e., the TMF 1501 and the TPF 1502 are implemented together (e.g., in a host machine 1503 or operating system (OS) responsible for virtualization, etc.), and shared functionality may exist. Alternatively, they may run on a data processing device outside (external to) the host machine 1503.

[0104] FIG. 16 shows a deployment model in which each TPF 1601 communicates with a management and orchestration system 1603 and a single TMF 1602.

[0105] FIG. 17 shows a deployment model in which a TPF 1701 communicates with a management and orchestration system 1603 and multiple TMFs 1702.

[0106] Figure 18 shows the deployment model for the O-RAN framework.

[0107] The TPF 1801 and TMF 1802 are implemented on a host machine 1803 which also implements a VNF 1804 and associated distributed units 1805 (applications).

[0108] The TMF 1802 is connected to an O-Cloud 1806, which includes Infrastructure Management Services (IMS) and Deployment Management Services (DMS). The O-Cloud is connected to Service Management & Orchestration (SMO) 1807.

[0109] In summary, according to various embodiments, a method for performing data communications is provided as shown in FIG.

[0110] FIG. 19 shows a flow diagram 1900 illustrating a method for performing data communications.

[0111] In 1901, in a data processing device configured to run multiple applications (e.g., including one or more virtual network functions) and having a physical port to a communications network, an internal network of components of the data processing device includes: for each application, making available to that application data received from the communications network via a physical port that is intended for that application; for each application, providing a physical port on which data that the application intends to transmit over the communications network is established; Enables communication between applications through an internal network, for example, making available to each application data destined for the application received from a communication network via the internal network without using a physical port.

[0112] At 1902, a representation of the internal network is generated as a network of data link layer interfaces according to a data communication protocol for data communication with guaranteed performance.

[0113] At 1903, the generated representation is provided to a network controller, which provides control information for a data link layer interface to enable data communication according to a data communication protocol.

[0114] At 1904, control information for a data link layer interface of a representation generated by a network controller is received.

[0115] At 1905, an internal network of the data processing device is configured according to the control information.

[0116] In other words, according to various embodiments, a data communications management component is provided in the data processing device (which may be implemented internally or externally to the data processing device) that maps the internal connectivity structure to nodes (e.g., TSN ports used in the internal network) according to a communication protocol for which the network controller provides control information. Upon receiving the control information, the data communications management component translates it back into control information for the components of the internal connectivity structure.

[0117] According to various embodiments, the data communication is TSN (i.e., Time Sensitive Networking according to IEEE, specifically 802.1Q-802.1 taking into account amendments such as 802.1Qbv, 2018Qbu, 802.1Qcr, etc.) data communication.

[0118] Various embodiments enable the provision of abstract TSN resources to the orchestration and management layer of an integrated virtualized system and the wiring of TSN functions to Virtualized Network Function (VNF) Connection Points (CPs).

[0119] Various embodiments further enable TSN for containerized VM-based VNFs and enable TSN control plane connectivity with mobile network virtualization management systems. This allows for node-level isolation and slicing of TSN resources, enabling LCM (life cycle management) and OAM processing per abstract TSN resource. These simplify the resolution of TSN problems from the CUC / CNC perspective. Thus, various embodiments enable telecom operators to enhance their orchestration mechanisms with methods, mechanisms, and interfaces that can treat TSN technologies as telecom resources. Thus, TSN programmable infrastructure can be part of a unified orchestration plane that is available as a service and managed by the OSS. Network services can be designed using TSN ports for real-time VNFs.

[0120] It can be assumed that TSN will become increasingly important not only for industrial networks but also for use cases such as RAN virtualization (in O-DU (O-RAN Distributed Unit)). As a fundamental methodology, SDN (Software-Defined Networking) can be used to control any type of underlying network resource using standard interfaces such as Netconf or YANG. Furthermore, TSN is already integrated into 5G systems, with the entire 5G Core (5GC) exposed as a TSN bridge.

[0121] The data link layer interface may be a multi-queue interface having queues for multiple traffic types.

[0122] The internal network of a component may include, for example, at least one bridge and / or at least one multi-queue interface as components.

[0123] The method may be performed and the components of the data communication management component may be implemented, for example, by one or more circuits. A "circuit" may be understood as any kind of logic implementation entity, which may be a dedicated circuit or a processor that executes software stored in memory, firmware, or any combination thereof. Thus, a "circuit" may be a hardwired logic circuit or a programmable processor, e.g., a programmable logic circuit such as a microprocessor. A "circuit" may also be a processor that executes software, e.g., any kind of computer program. Any other kind of implementation of each of the above functions may also be understood as a "circuit".

[0124] According to various embodiments, a method is provided for enabling TSN functionality for virtualized and non-virtualized network functions operating on a shared physical infrastructure, the method comprising: receiving a request to deploy or update a real-time VNF with TSN features requested from an orchestration system or generated due to LCM operations; receiving, publishing, and translating information about the capabilities and status of physical and virtual TSN interfaces and ports of a node (e.g., a communication device or a host machine); creating abstract TSN resources allocated to VNF CPs and mapping these to virtual or physical TSN resources; determining TSN resource allocation according to QoS requirements, determining the TSN multiplexing architecture on the node according to interaction with the infrastructure manager, and allocating the correct resources; Includes:

[0125] While particular embodiments have been described, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the embodiments of the present disclosure as defined by the appended claims. The scope is therefore indicated by the appended claims, and all changes that come within the meaning and range of equivalents of the claims are therefore intended to be embraced.

Claims

1. A data processing device configured to run a plurality of software applications, the data processing device having a physical port to a communications network external to the data processing device, comprising: a data communications management component internal or external to the data processing device, the data communications management component comprising: The data communication management component configured in the data processing device to establish an internal time-sensitive network (TSN) of components of the data processing device; The component for each of the plurality of software applications, making available to the respective software application data received from the communications network via the physical port and intended for that respective software application; for each of the plurality of software applications, providing to the physical port data that each of the plurality of software applications intends to transmit over the communications network; configured to enable communication between the plurality of software applications over the internal TSN; The data communication management component Generate a logical representation of the internal TSN in the data processing device according to a configuration of a data link layer interface, which is layer 2 of the Open Systems Interconnection (OSI) model, according to a TSN communication protocol, which is a data communication protocol for data communication with guaranteed performance; configured to provide the generated logical representation of the internal TSN to a network controller, the network controller configured to provide control information for the data link layer interface to enable data communication in accordance with the TSN communication protocol; receiving the control information for the data link layer interface provided by the network controller; Configure the internal TSN according to the received control information A data communications management component configured to:

2. The data communications management component of claim 1 , wherein the guaranteed performance includes at least a guaranteed maximum latency and / or a guaranteed maximum jitter.

3. 2. The data communications management component of claim 1, wherein the plurality of software applications includes at least one software application running in a virtual machine (VM) on the data processing device and / or at least one software application running in an application containerization container on the data processing device.

4. 2. The data communications management component of claim 1, wherein the plurality of software applications includes at least one software application running in a virtual machine on the data processing device and / or at least one software application running in a container on the data processing device, and the data communications management component is further configured to map a connection point abstraction of a virtual network interface card of the at least one software application to one of the data link layer interfaces.

5. 2. The data communications management component of claim 1, wherein one of the data link layer interfaces is attached to the physical port, and the internal TSN is configured to connect each software application of the plurality of software applications to others of the plurality of software applications and to one of the data link layer interfaces attached to the physical port.

6. 2. The data communications management component of claim 1, wherein the physical port comprises a plurality of physical ports, each software application of the plurality of software applications being associated with one of the data link layer interfaces, and the internal TSN is configured, for each of the plurality of software applications, to make available to the respective software application data received from the communications network via the data link layer interface associated with the respective software application and to provide data that the respective software application intends to transmit over the communications network to the data link layer interface associated with the respective software application.

7. 2. The data communications management component of claim 1, further configured to establish and manage the internal TSN according to data communications requirements received from a proxy component configured to manage a mapping of each of the plurality of software applications to a corresponding data communications endpoint of the TSN communications protocol.

8. The data communications management component of claim 1 , wherein the data link layer interface is a TSN-enabled interface.

9. The data communication management component of claim 8 , wherein the network controller is a Centralized User Configurator (CUC) or a Centralized Network Configurator (CNC) according to TSN.

10. The data communications management component of claim 1 , wherein the communications network is an Ethernet.

11. 1. A method for performing data communications, comprising: In a data processing device running a plurality of software applications and having a physical port to a communications network, establishing an internal time sensitive network (TSN) of a component of the data processing device, wherein the component makes available to each of the plurality of software applications data received from the communications network via the physical port and provides to the physical port, for each of the plurality of software applications, data that the respective software application intends to transmit over the communications network, enabling communication between the plurality of software applications through the internal TSN; generating a logical representation of the internal TSN in the data processing device according to a configuration of a data link layer interface, which is layer 2 of the Open Systems Interconnection (OSI) model, according to a TSN communication protocol, which is a protocol for data communication with guaranteed performance; providing the generated logical representation of the internal TSN to a network controller, the network controller providing control information for a data link layer interface to enable data communication in accordance with the TSN communication protocol; receiving the control information for a data link layer interface provided by the network controller; configuring the internal TSN according to the received control information; A method comprising:

Images