Patent Description:
IEEE Time Sensitive Networking (TSN) is a family of standards used to enable deterministic communications. It provides non-negotiable time boundaries for end-to-end transmission latencies and jitter. For this, it includes components to provide synchronization, reliability, latency and resource management.

The fully centralized TSN control plane is included by a Centralized Network Configurator (CNC) and a Centralized User Configurator (CUC) which provide configuration and control information (for example related to scheduling) to TSN interfaces on the network devices and the TSN Talkers/Listeners (data processing devices) respectively. Fully distributed configuration and Centralized Network / Distributed User Model are also possible for the configuration of the network devices and the TSN Talkers/Listeners.

Document: <NPL>, discusses the following: a first mapping of the IEC <NUM> protocols to the TSN traffic classes, based on the analysis of both TSN and IEC <NUM> protocols; and developing an exact worst-case delay (WCD) analysis for ET traffic.

However, a data processing device may run multiple applications and have a complex internal structure for routing application traffic between interfaces and physical ports and the applications such that the data processing device does not simply map to a single TSN interface for which scheduling information is provided.

Accordingly, mechanisms are desirable which allow supporting data communication techniques and protocols like TSN (in general data communication protocol for data communication with guaranteed performance) in case of complex internal structures of data processing devices running multiple applications.

According to one embodiment, a data communication managing component is provided which is configured to establish, in a data processing device configured to run multiple applications and having a physical port to a communication network, an internal network of components of the data processing device to make, for each of the applications, data destined for the application received from the communication network via the physical port available for the application, supply, to the physical port, for each of the applications, data that the application intends to send via the communication network and enable communication between the applications through the internal network.

The data communication managing component is further configured to generate a representation of the internal network as a network of data link layer interfaces in accordance with a data communication protocol for data communication with guaranteed performance, provide the generated representation to a network controller, wherein the network controller is configured to provide control information for data link layer interfaces to enable data communication in accordance with the data communication 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 in accordance with the scheduling information.

According to another embodiment, a method for performing data communication according to the data communication managing components described above is provided.

The following detailed description refers to the accompanying drawings that show, by way of illustration, specific details and aspects of this 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 invention. The various aspects of this disclosure are not necessarily mutually exclusive, as some aspects of this disclosure can be combined with one or more other aspects of this disclosure to form new aspects.

Various examples corresponding to aspects of this disclosure are described below:.

It should be noted that one or more of the features of any of the examples above may be combined with any one of the other examples. In particular, the Examples described in context of the device are analogously valid for the method.

According to further embodiments, a computer program and a computer readable medium including instructions, which, when executed by a computer, make the computer perform the method of any one of the above examples are provided.

In the following, various examples will be described in more detail.

<FIG> shows a communication system <NUM> for providing TSN functionality.

The communication system <NUM> includes, in this example, servers <NUM>, which are connected via a first TSN switch <NUM> to a router <NUM>. It should be noted that a TSN switch implements a TSN bridge functionality. These terms are used interchangeably herein.

The router <NUM> is connected to the Internet <NUM>. The communication system <NUM> further includes first terminal devices <NUM>, wherein each first terminal device <NUM> is connected via a respective second TSN switch <NUM> to the router <NUM>.

Further, in this example, second terminal devices <NUM> are connected via a third switch <NUM> to the router <NUM>.

The servers <NUM> and terminal devices <NUM>, <NUM> are (TSN) endpoint devices (typically referred as TSN Talkers or TSN Listeners).

Each switch <NUM>, <NUM>, <NUM> can be seen to be the connection point between the router <NUM> and a respective local area network which includes one or more of the endpoint devices <NUM>, <NUM>, <NUM>.

The endpoint devices <NUM>, <NUM>, the switches <NUM>, <NUM>, <NUM> and the router <NUM> support TSN communication functionality. A TSN communication is a communication between endpoints <NUM>, <NUM>, <NUM> (wherein one acts as TSN Talker and the other as a TSN Listener). The endpoint devices <NUM> may send/receive TSN traffic, without however supporting TSN communication functionality. In that case device <NUM> is the entry point to the TSN network.

TSN is a Layer <NUM> technology. It is thus located below the network layer (layer <NUM>) and above the physical layer (layer <NUM>). For example, on top of TSN, MPLS (Multiprotocol Label Switching), IPv4/<NUM> etc. can operate. It should be noted that the embodiments described herein are agnostic to the overlaying network technology.

TSN functionality can run on an Ethernet port (physical port) of a switch, router and endpoint according to IEEE <NUM>. TSN functionality can also be supported on the interface level, attached to physical ports. Thus, on each physical port <NUM>, TSN functionality may be implemented. In other words, a TSN port (also referred to as TSN interface or virtual (TSN) port) <NUM> may be attached to each physical port or be connected to other TSN ports.

For supporting TSN communication, the involved devices (terminal devices, router and switches) provide TSN ports (e.g., TSN <NUM>. 1Qbv ports). It should be noted that the description of the embodiments focuses on TSN, but the features described herein may also be applied to other guaranteed performance techniques, i.e. embodiments may be generalized to other guaranteed performance techniques other than TSN.

<FIG> illustrates a queuing structure of a TSN (output) port, i.e. the functionality provided by a TSN port (or TSN interface) according to <NUM>.

According to the queuing structure, there are eight gates <NUM> (according to <NUM>. 1Q2018 in this example). Each gate <NUM> is either opened or closed in accordance with a gate control list (GCL) <NUM>.

Each gate <NUM> is associated with a traffic class and has an associated queue <NUM> into which the data of the traffic class to be transmitted via the gate <NUM> is put. Further, a transmission selection algorithm <NUM> (e.g. a credit based shaper (CBS)) may be performed for each gate which is responsible for shaping the traffic of the respective queue <NUM>. A transmission selection mechanism <NUM> transmits data from open gates via the physical layer, e.g. an Ethernet PHY.

<FIG> illustrates the TSN control plane.

As explained above, TSN talkers <NUM> and TSN listeners <NUM> may be connected via a plurality of TSN-enabled devices <NUM> (e.g. corresponding to the switches <NUM>, <NUM>, <NUM> or also the router <NUM> with TSN bridging capabilities.

Non-TSN talkers <NUM> and listeners <NUM> may also be connected to the TSN switches <NUM>. According to the fully centralized model, a Centralized User Configurator (CUC) <NUM> configures the TSN talkers <NUM> and listeners <NUM> with regard to TSN. A Centralized Network Configurator (CNC) <NUM> configures the switches <NUM> with regard to TSN. Embodiments are also applicable also when fully distributed but also Centralized Network / Distributed User Model according to <NUM>. 1Qcc are used.

The CUC <NUM> assumes TSN Applications (i.e. (software) applications sending or receiving TSN traffic) are independent from each other.

However, inside a host machine (or host device, i.e. a terminal device, e.g. a computer, having physical layer ports to a communication network (e.g. an Ethernet), which is external with respect to the terminal device) TSN may operate on different levels (e.g., on the virtual interface inside the kernel of a Virtual Machine, on a virtual interface on the host machine created by a hypervisor's virtual switch, on interfaces attached to physical ports etc.).

<FIG> illustrates a host machine <NUM> (e.g. a server).

The host machine <NUM> hosts two virtual network functions (VNFs) <NUM>, <NUM>. From the TSN perspective, these are TSN applications. The host machine hosts further TSN applications (e.g. other types of programs sending/receiving TSN traffic) <NUM>. Each VNF <NUM>, <NUM> runs on a respective virtual machine <NUM>, <NUM>.

The host machine <NUM> has physical ports <NUM> (e.g. Ethernet ports) via which it is connected to switches <NUM>.

The host machine <NUM> has an internal TSN network <NUM> which provides the connection between the TSN applications <NUM>, <NUM>, <NUM> (denoted as "TSN App <NUM>" to "TSN App <NUM>") and also between the applications <NUM>, <NUM>, <NUM> and other applications residing outside the host through the physical ports <NUM>. This involves TSN interfaces <NUM> on virtual or normal interfaces and physical ports. In order to realize TSN functionality on the interface level multiqueueing functionality is enabled to support TSN features like <NUM>. 1Qbv in software and perform appropriate QoS mapping handlers. For the case of interfaces attached to the physical port, multiqueueing drivers in the host machine <NUM> enable a network card to supports this. The internal TSN network <NUM> may involve further components like a (e.g. Linux) Bridge and an OVS (Open Virtual Switch). So, the internal TSN network <NUM> may have a complex structure. Furthermore, in this example, the virtual machine <NUM> includes a TSN node <NUM>. In the example of <FIG>, TSN ports are attached to the left two physical ports.

However, the CUC <NUM> or the CNC <NUM>, respectively, typically expect a simple structure like the one illustrated by the diagram <NUM>. For example, for the structure indicated by box <NUM> of a TSN port and a Linux bridge of the TSN network <NUM> as well as the TSN node <NUM> of the virtual machine <NUM>, the CUC <NUM> or the CNC <NUM>, respectively, expect that one (abstract) TSN node <NUM> hosting a TSN Application, is connected to the TSN network through a TSN port <NUM>.

Furthermore, according to ETSI NFV framework, for VNFs and each Virtual Links (VL) between two VNFs, (abstract) Connection Points (CP) are defined as illustrated by the diagram <NUM>.

So, the following issues arise in such a scenario.

<FIG> illustrates these issues for a host machine <NUM> on which three VNFs <NUM> denoted as VNF <NUM>, VNF2 and VNF3 are deployed in the form of virtual machine(s), and having two physical ports <NUM> implementing TSN functionality denoted as port "<NUM>" and port "<NUM>" connected each to a respective physical port <NUM> of a switch <NUM> which is connected via a further port <NUM> to a communication network <NUM> (having further switches <NUM>).

As an example, it is assumed that the first VNF <NUM> has two (TSN data) flows f1. <NUM> and f1. <NUM>, VNF has a data flow f2 and VNF <NUM> has a data flow f3.

So, the VNFs (as TSN applications) inform the CUC as follows:.

As illustrated, it is assumed that VNF <NUM> and VNF <NUM> use port <NUM> and VNF <NUM> uses port <NUM>.

As explained with reference to <FIG>, the host machine <NUM> has an internal TSN network <NUM> with TSN ports <NUM> for connecting the VNFs <NUM> to the physical ports <NUM>. Further, VNF1 includes a TSN port <NUM>. Conventionally, the CUC and the CNC are not aware that there is a local (i.e. internal) TSN network <NUM> in the host machine <NUM>. So, conventionally, there is no management and control over this TSN network <NUM> by the CUC and the CNC. Further, conventionally, the CUC and CNC are not aware of the (from their point of view additional) TSN interface provided by the VM-based TSN-aware application node with TSN port <NUM>.

So, conventionally, the VNF CPs are not isolated from each other since CNC considers all VNFs together as being connected by one TSN port.

To address this and the above issues <NUM> to <NUM>, according to various embodiments, a TSN Manager Function (TMF) and a TSN Proxy Function (TPF) (and an interface between the two) are introduced as illustrated in <FIG>.

<FIG> shows a TSN deployment according to an embodiment.

The TSN architecture includes a host machine <NUM> which, similarly to the host machine <NUM>, hosts two virtual network functions <NUM>, <NUM> and one or more further TSN applications <NUM> and each VNF <NUM>, <NUM> runs on a respective virtual machine <NUM>, <NUM>. In general the host machine (or host device <NUM>) hosts containerized or VM based VNFs but also other (non-VNF) applications deployed over the host machine operating system. (A similar concept applies for bare metal containers and hypervisors).

Further, similarly to the host machine <NUM>, the host machine <NUM> has physical ports <NUM> (e.g. Ethernet ports) via which it is connected to TSN switches <NUM> and has an internal TSN network <NUM> which provides the connection between the TSN applications <NUM>, <NUM>, <NUM> and between the TSN applications <NUM>, <NUM>, <NUM> and the physical ports <NUM>.

The TSN architecture further includes a TSN Manager Function (TMF) <NUM>. The TMF <NUM>.

Further, the TSN architecture includes a TSN Proxy Function (TPF) <NUM>. The TPF <NUM>.

TMF <NUM> and TPF <NUM> can be realized as a single software entity running inside or outside the host machine <NUM>. Operation of the TMF <NUM> and the TPF <NUM> enable the creation and operation of TSN overlay networks. When considering the ETSI NFV framework, VNFDs (Virtual Network Function Descriptors) and NSDs (Network Service Descriptors) may be updated to enable description on the stream level for time critical (or other guaranteed performance requirements) streams. In such a case, updates on the process between VIM (Virtualized Infrastructure Manager) and NFVI (Network Functions Virtualization Infrastructure) responsible for the Host management and control for building the underlying layer <NUM> network are introduced.

<FIG> illustrates an operation of a TMF <NUM> according to an embodiment in more detail.

The TSN Manager Function (TMF) <NUM> acts as resource manager <NUM> wherein it performs internal network virtualization and TSN resource abstraction and management <NUM>. In particular, it.

Further, the TMF <NUM> support mapping of VNF CPs <NUM> to the internal TSN network TSN ports <NUM> and exposes them to the TPF or the VIM <NUM>. In the example shown, a first TSN port <NUM> supports <NUM>. 1Qbv and a second TSN port <NUM> performs pre-emption(<NUM>. One CP <NUM> considered by a VNF (may be attached to a TSN port <NUM> or <NUM> and operate under <NUM>. 1Qbv, while another CP <NUM> may be attached to a <NUM>. 1Qbu TSN port.

Regarding the actual TSN configuration of the ports (e.g. provision of the gate control list in case of <NUM>. 1Qbv), the TMF <NUM> can support two modes regarding TSN configuration of the internal TSN network <NUM> of the host machine <NUM>.

<FIG> shows a first mode for configuring the internal TSN network <NUM> of a host machine <NUM>.

According to this first mode, the TMF <NUM> includes a scheduler to solve locally the schedules provided by CUC (directly or through TPF). It also performs the mapping to the correct TSN ports and the physical ports. It thus enables local TSN solving (when hierarchical TSN nodes exists inside the host machine <NUM>).

<FIG> shows a second mode for configuring the internal TSN network <NUM> of a host machine.

In this mode, the CNC <NUM> has a global view including the structure of the internal TSN network <NUM> (and does not necessarily know that the internal TSN network <NUM> is running in a host machine). The TMF <NUM> still manages the internal TSN network <NUM> and the CNC <NUM> configures it (e.g. supplies the GCL to the TSN ports of the internal TSN network <NUM>, possibly via an intermediate component <NUM>). The TMF <NUM> may fully or partially expose the structure of the internal TSN network <NUM>.

<FIG> illustrates an operation of a TPF <NUM> according to an embodiment in more detail.

The TPF <NUM> together with a TMF <NUM> enable TSN programmability for a VNF <NUM> running on a virtual machine <NUM> and hosted by host machine <NUM>.

The TSN control plane (in particular CUC <NUM>) only sees TSN Talkers and Listeners running on the host machine <NUM> like the VNF <NUM> and a further (non-VNF) TSN application <NUM> through interaction with the TPF <NUM>.

The TPF <NUM> creates an abstract TSN endpoint mapped to the VNF or the TSN application (for each VNF and each TSN application deployed on the host machine <NUM>). It exposes TSN endpoints for the VNF <NUM> and the TSN application <NUM>.

The TPF <NUM> is further responsible to parse stream requirements related to TSN (from the VNF <NUM> or the virtual machine <NUM> on which the VNF <NUM> is running) and sends them to the TMF <NUM> (e.g. for optimizing local TSN network design).

The TPF <NUM> knows all TSN applications <NUM>, <NUM> and their TSN configuration and capabilities running the host machine <NUM>.

For each VNF <NUM> and (non-VNF) TSN application, the TPF <NUM> passes the TSN configuration received by the CUC also to the TMF. TPF <NUM> and TMF <NUM> jointly orchestrate the actual configuration of the TSN application (e.g., TSN App <NUM>) based on CUC configuration. Internal TSN network configuration depends on the mode described in the previous figures.

In addition, a management and orchestration system, e.g., based on ETSI NFV-MANO framework may be considered, For instance, a VIM <NUM> (connected to a VNFM (VNF Manager) <NUM> and a NFVO (NFV Orchestrator) <NUM>, which is in turn connected to an OSS (Operation Support System) <NUM> may communicate with the TMF <NUM>:.

<FIG> shows a flow diagram <NUM> illustrating the creation of an VNF based TSN talker when considering the ETSI NFV-MANO framework.

An OSS <NUM>, an NFVO <NUM>, a VNFM <NUM>, a VIM <NUM>, a TSN application <NUM> (hosted by a VNF) , a TPF <NUM>, a TMF <NUM> and a CUC <NUM>, e.g. as in <FIG>, are involved in the flow.

In <NUM>, the OSS <NUM> sends a request to instantiate a VNF, referencing to a respective VNFD, to the NFVO <NUM>. The NFVO <NUM> parses the VNFD in <NUM> and triggers the VNFM <NUM> to create a corresponding VNF in <NUM>. The VNF hosts the TSN application <NUM>.

In <NUM>, the VNFM <NUM> or the TSN application <NUM> informs the TPF <NUM> that the new TSN application <NUM> is hosted by the VNF. In <NUM>, the TPF <NUM> creates an (abstract) TSN endpoint (Listener or Talker) for the TSN application <NUM>. In <NUM>, the TPF <NUM> establishes a connection between the established TSN endpoint (i.e. between TSN application <NUM>) and the CUC <NUM>.

In <NUM>, the NFVO <NUM> sends a request for a connection point (CP) with TSN capabilities to the VIM <NUM> which the VIM <NUM> forwards to the TMF <NUM> in <NUM>. It should be noted that the VIM <NUM> could also forward the request to TPF <NUM> and then from there to TMF <NUM>. NFVO requests towards the VIM for CP can be also originated by VNFM towards the VIM.

In <NUM>, the TPF <NUM> connects to the TSN application <NUM> in the manner of a CUC. In <NUM>, the TSN application <NUM> passes stream requirements to the TPF <NUM> which the TPF <NUM> forwards to the TMF <NUM> in <NUM> and to the CUC <NUM> in <NUM>.

In <NUM>, the TMF <NUM> performs TSN resource allocation. This includes the creation or update of an internal TSN network (including interfaces between the components of the TSN network).

In <NUM>, the TPF <NUM> and the TMF <NUM> perform a mapping between connection points and virtual and/or physical TSN Ports and TSN resource allocation.

In <NUM>, the TMF <NUM> sends a status notification to the VIM <NUM> (possibly via the TPF <NUM>) which the VIM <NUM> forwards to the NFVO <NUM> in <NUM> and which the NFVO <NUM> forwards to the OSS <NUM> in <NUM>. In case requests towards VIM for CP are originated by VNFM, status notification is sent to VNFM.

<FIG> shows a flow diagram <NUM> illustrating the configuration of a TSN Talker hosted in a VNF following the first configuration mode, when considering the ETSI MANO architecture.

An OSS <NUM>, an NFVO <NUM>, a VNFM <NUM>, a TSN application or virtual network function <NUM>, a TPF <NUM>, a TMF <NUM>, a CUC <NUM> and a CNC <NUM>, e.g. as in <FIG>, are involved in the flow.

In <NUM>, the CNC <NUM> determines a TSN configuration and sends it to the CUC <NUM> in <NUM>.

In <NUM>, the CUC <NUM> forwards the configuration to the TPF <NUM>.

In <NUM>, the TPF <NUM> parses the configuration for configuration information for the abstract TSN port which is mapped to the abstract VNF CP and forwards the found configuration information to the TSN application or virtual network function <NUM> in <NUM>. Further, the TPF <NUM> forwards the configuration information to the TMF <NUM> in <NUM>.

In <NUM>, the TSN application or virtual network function <NUM> performs application or thread operation tuning in accordance with the configuration information that the TPF <NUM> has provided.

In <NUM>, the TMF <NUM> generates configuration information for the TSN port resources in the internal network and configures them accordingly in <NUM>.

In <NUM>, the TMF <NUM> sends an indication of the operational status of the TSN ports used in the internal network to the TPF <NUM>.

In <NUM>, the TMF <NUM> sends an indication of the operational status of the TSN ports used in the internal network to the TPF <NUM>, which in turn informs CUC <NUM> about the configuration status.

<FIG> illustrates a first deployment model for a TPF.

In this deployment model, TPF <NUM> and TMF <NUM> are decoupled. TPF <NUM> acts as a TSN plug-in. For example, it may be implemented inside an SDN controller as a TSN plug-in.

<FIG> illustrates a second deployment model for a TPF.

In this deployment model, a local TSN proxy instance <NUM> runs inside each VNF <NUM> or TSN application <NUM>.

<FIG> illustrates a third deployment model for a TPF.

In this deployment model (from an implementation point of view) TMF <NUM> and TPF <NUM> are realized as a single software entity, i.e. TMF <NUM> and TPF <NUM> are implemented together (e.g., in the host machine <NUM> or operating system (OS) responsible for virtualization etc. and there may be shared functionality. Alternatively, they may run on a data processing device outside (external to) the host machine <NUM>.

<FIG> illustrates a deployment model where each TPF <NUM> communicates with a Management and Orchestration System <NUM> and with a single TMF <NUM>.

<FIG> illustrates a deployment model where a TPF <NUM> communicates with a Management and Orchestration System <NUM> and with multiple TMFs <NUM>.

<FIG> illustrates a deployment model for O-RAN framework.

A TPF <NUM> and a TMF <NUM> are implemented in a host machine <NUM> which further implements VNFs <NUM> and associated distributed units <NUM> (applications).

The TMF <NUM> is connected to an O-Cloud <NUM> including IMS (Infrastructure Management Services) and DMS (Deployment Management Services). The O-Cloud is connected to SMO (Service Management & Orchestration) <NUM>.

In summary, according to various embodiments, a method for performing data communication is provided as illustrated in <FIG>.

<FIG> shows a flow diagram <NUM> illustrating a method for performing data communication.

In <NUM>, 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 communication network, an internal network of components of the data processing device to.

In <NUM> a representation of the internal network as a network of data link layer interfaces in accordance with a data communication protocol for data communication with guaranteed performance is generated.

In <NUM>, the generated representation is provided to a network controller, wherein the network controller provides control information for data link layer interfaces to enable data communication in accordance with the data communication protocol.

In <NUM>, control information for the data link layer interfaces of the representation generated by the network controller is received.

In <NUM>, the internal network of the data processing device is configured in accordance with the control information.

According to various embodiments, in other words, a data communication managing component is provided for a data processing device (wherein the data communication managing component may be implemented internally in the data processing device or external with respect to the data processing device) which maps an internal connection structure to nodes (e.g. TSN ports used in the internal network) according to a communication protocol for which a network controller provides control information. Upon reception of the control information the data communication managing component translates this back to control information for the components of the internal connection structure.

According to various embodiments, the data communication is data communication according to TSN (i.e. Time Sensitive Networking according to IEEE, specifically <NUM>. 1Q-<NUM> considering amendments like <NUM>. 1Qbv, <NUM>. 1Qbu, <NUM>. 1Qcr etc,).

Various embodiments allow providing abstract TSN resources to the orchestration and management layer of an integrated virtualization system and the wiring of TSN functionality to VNF (Virtualized Network Function) Connection Points (CPs).

Various embodiments further enable TSN for containerized and VM-based VNFs and enables connectivity of the TSN control plane with mobile network virtualization Management systems. It allows isolation and slicing of TSN resources on the Node level and allows LCM (life cycle management) and OAM handling per abstract TSN resource. They simplify the TSN problem solving from CUC/CNC point of view. Thus, various embodiments allow enhancing the telecom operator orchestration mechanism with methods, mechanisms and interfaces which can handle TSN technology as a telecom resource. TSN programmable infrastructure can thus be exploited as a service and be part of an integrated orchestration plane managed by OSS. Network Services can be designed using TSN ports for real time VNFs.

TSN can be expected to be increasingly important for use cases like in Industrial Networks but also RAN virtualization (in O-DU (O-RAN Distributed Unit). As a basic methodology SDN (Software-Defined Networking) can be used to control any type of underlying network resources using a standard interface like Netconf or YANG. Furthermore, TSN is already integrated to the <NUM> system, where the entire 5GC (<NUM> Core) is a exposed as a TSN bridge.

The data link layer interfaces may be multi-queue interfaces having queues for multiple traffic types.

The internal network of components for example includes, as components, at least one bridge and/or at least one multi-queue interface.

The method may be performed and the components of the data communication managing component may for example be implemented by one or more circuits. A "circuit" may be understood as any kind of a logic implementing entity, which may be special purpose circuitry or a processor executing software stored in a memory, firmware, or any combination thereof. Thus a "circuit" may be a hard-wired logic circuit or a programmable logic circuit such as a programmable processor, e.g. a microprocessor. A "circuit" may also be a processor executing software, e.g. any kind of computer program. Any other kind of implementation of the respective functions described above may also be understood as a "circuit".

Claim 1:
A data communication managing component (<NUM>. <NUM>) configured to
establish, in a data processing device (<NUM>) configured to run multiple software applications and having a physical port (<NUM>) to a communication network, an internal network of components (<NUM>) of the data processing device (<NUM>) to
make, for each of the applications (<NUM>, <NUM>, <NUM>), data destined for the application (<NUM>, <NUM>, <NUM>) received from the communication network via the physical port (<NUM>) available for the application (<NUM>, <NUM>, <NUM>);
supply, to the physical port (<NUM>), for each of the applications (<NUM>, <NUM>, <NUM>), data that the application (<NUM>, <NUM>, <NUM>) intends to send via the communication network; and
enable communication between the applications (<NUM>, <NUM>, <NUM>) through the internal network (<NUM>),
generate a representation of the internal network (<NUM>) as a network of data link layer interfaces in accordance with a data communication protocol for data communication with guaranteed performance,
provide the generated representation to a network controller (<NUM>, <NUM>), wherein the network controller (<NUM>, <NUM>) is configured to provide control information for data link layer interfaces to enable data communication in accordance with the data communication protocol;
receive control information for the data link layer interfaces of the representation generated by the network controller (<NUM>, <NUM>); and
configure the internal network (<NUM>) of the data processing device (<NUM>) in accordance with the control information.