Configuring a system

Abstract

In an example, method of configuring a system is provided. The method comprises determining a representation of the system, wherein the representation comprises one or more network nodes, wherein each network node comprises a network bridge or network router. The method also comprises determining a configuration for the one or more network nodes based on a distribution of delays of data through the system, and causing the system to be configured based on the configuration for the one or more network nodes.

Description

[0001] CONFIGURING A SYSTEM

[0002] Technical Field

[0003] Example embodiments of this disclosure relate to configuring a system, such as for example a 5G wireless communications system or a virtualization system.

[0004] Background

[0005] The 3rd Generation Partnership Project (3GPP) introduced the time-sensitive communications (TSO) framework in 5G in order to support deterministic type of communications that have been standardized by the Institute of Electrical and Electronics Engineers (IEEE), namely Time-Sensitive Networking (TSN), and by the Internet Engineering Task Force (IETF), namely Deterministic Networking (DetNet).

[0006] Per-Stream Filtering and Policing (PSFP) is a mechanism that polices ingress ports of Time Sensitive Networking (TSN) bridges. PSFP is defined per TSN stream. It defines the time window by which arriving packets of a stream are allowed to enter, while any packets outside of the window will be dropped. On the other hand, Scheduled Traffic, also referred to as IEEE 802.1Qbv or simply Qbv, defines similar windows for egress ports and on a per traffic class basis (i.e. for multiple TSN streams belonging to the same traffic class). Qbv can be used to define the time window in which packets stored in a Qbv queue (of an egress port for a traffic class) are allowed to be transmitted out to the next network node. Both mechanisms (PSFP and Qbv) are therefore based on gates that open during the allowed time window and let pass corresponding packets, either to be transmitted out of an egress port or being received at an ingress port. The gate closes at the end of the window. When the gate is closed, PSFP drops packets, while Qbv queues them until they can be transmitted through an open gate again. Most TSN streams are periodic, which implies also periodic gating.

[0007] The main enabler to support these technologies in a 3GPP Radio Access Network (RAN) is Ultra Reliable Low Latency Communications (URLLC), which guarantees a bounded delay, delay-critical type of quality of service (QoS), and reliable communication.

[0008] With TSC, the 5G wireless communication system is modelled as a node which mimics the behavior of a regular fixed node that supports time-sensitive communication. For example, the 5G system is modelled as a logical or virtual TSN bridge. Figure 1 shows an example of a network 100 in which a 5G system is modelled as a logical TSN bridge 102. Specifically, the 5G logical TSN bridge 102 is connected to other TSN bridge(s) 104 or TSN end stations (such as TSN Talker 106 or TSN Listener 108). In this example, only one other TSN bridge 104 is shown, though there may be any number of other TSN bridges in other examples. The 5G logical bridge 102 also interfaces with an external control plane management entity, in this case the TSN controller (aka Centralized Network Configuration (CNC) 110). Note that in the case of a fully centralized architecture in TSN, applications in the Talker 106 or Listener 108 (aka TSN end stations) communicate with a Centralized User Configuration (CUC) 112 which oversees user configurations, which then is passed in terms of communication requirements to the CNC 110, the network controller. After the CNC 110 has collected all TSN flows’ requirements from the CUC 112 and the capabilities of all of the bridges 102 and 104, the CNC 110 sets the configuration for all the bridge components (e.g. TSN bridges and TSN end station Network Card Interfaces (NICs)) using a configuration protocol such as NETCONF or RESTCONF.

[0009] To interface the 5G system with the other TSN nodes, 3GPP introduced TSN translators (TT) at the device side (DS-TT) and at the network side (NW-TT), as shown in Figure 2, which shows an example of a 5G system 200 and TSN CNC 202. The DS-TT 204 and NW- TT 206 in the 5G system 200 provide the TSN Ethernet interface and mimic the expected behavior of a number of TSN features (such as Qbv and PSFP), without the need to radically modify the functionalities of the nodes and functions of the 5G system 200. To interface with the CNC 202, a TSN application function (TSN AF) 208 was defined. The TSN AF 208 obtains the 5G bridge capabilities and provides them to the CNC 202, while the CNC configures the 5G bridge via the TSN AF 208. This configuration may include control information to be able to support features such as PSFP and Qbv. The TSN AF 208 translates the capabilities to the parameters that the CNC 202 handles and translates the configuration from the CNC 202 into a flow set up in the 5G system. Finally, the TSN AF 208 also handles the typical time synchronization data sets that can be configured by the CNC 202.

[0010] Note that TSN is a specific case of TSC. In general, TSC would involve the use of a similar entity to the TSN AF 208, known as the TSC and Time Synchronization Function (TSCTSF). TSCTSF performs similar tasks as the TSN AF 208 but with a generalized exposure interface that is proxied via the Network Exposure Function (NEF), unless the external Application Function (AF) is a trusted entity for the 5G system, in which case the NEF is not used. In the general case, any AF can request a deterministic service via 5G and the 5G system is considered a network node. A similar technology to TSN has been standardized in IETF, namely Deterministic Networking (DetNet), which is implemented in layer 3 of the OSI reference model supporting IP-based communications. Similarly, 3GPP has modeled 5G system as a logical DetNet node. In the case of DetNet, the general TSO framework was reused where the TSCTSF interacts with a DetNet controller without the need for NEF since the controller is considered a trusted entity. The information used in the TSCTSF-DetNet controller interface uses the defined Yet Another Next Generation (YANG) models for DetNet. TSCTSF translates the configuration from the DetNet controller into requirements for the 5G system, similarly as in the case of the TSN AF. With DetNet there is no requirement for a DS-TT since the interface is IP-based which is already supported in 5G, and no additional translation is needed. If a time synchronization service is required, then the DS-TT will be used.

[0011] For TSN, DetNet and TSC in general, it is possible to have UE-to-UE communications. As per clause 5.28.2 of 3GPP TS 23.501 V18.5.0:

[0012] “If the TSN AF determines that the TSN stream is for UE-llE communication (i.e. ingress and egress ports are in DS-TTs), the TSN AF divides the stream into one uplink stream and one or more downlink streams and provides the streams on AF Session basis to the PCF(s). The SMF applies local switching as specified in clause 5.8.2.13 or clause 5.8.2.5.3 in order to enable UPF locally forward uplink stream from one PDU session as downlink stream in another PDU session.”

[0013] As per clause 5.27.5 of 3GPP TS 23.501 V18.5.0:

[0014] “TSN AF deduces the port pair(s) consisting of two DS-TT ports connecting to the same 5GS bridge and determines the 5GS bridge delay as sum of bridge delays related to PDU Sessions of two DS-TT ports.”

[0015] The per-traffic class bridge delays between the UE and the UPF / NW-TT are pre-configured in the TSN AF in its pre-configured QoS tables. Usually a bridge delay (or 5GS delay in the case of TSC) is the sum of Packet Delay Budget (PDB) + DS-TT residence time. In the case of UE-to-UE communication, then it will be the summation of PDB and DS-TT residence time for one PDU session leg, and PDB and DS-TT residence time for the other PDU session leg.

[0016] As per clause 5.28.5.3 of 3GPP TS 23.501 V18.5.0: “If the flow is UE-to-UE, two PDU Sessions will be affected for the flow, and the TSCTSF breaks up the requirements to individual requirements for the PDU Sessions.”

[0017] For the case of TSC, a TSC assistance container (TSCAC) can be generated based on information provided in the AF session request with QoS. Assuming that all requests are authorized and individual QoS parameters are provided, a simplified procedure is as follows.

[0018] 1 . The AF sends a request to the NEF and provides its traffic pattern as assistance parameters

[0019] According to clause 4.15.6.6 of TS 23.502 V18.5.0, “Setting up an AF session with required QoS procedure”:

[0020] “If the TSCTSF receives a Requested 5GS Delay, the TSCTSF calculates a Requested PDB by subtracting the UE-DS-TT Residence Time (either provided by the PCF or pre-configured at TSCTSF) from the Requested 5GS Delay and sends the Requested PDB to the PCF instead of the Requested 5GS Delay. If the TSCTSF receives any of the following parameters: flow direction, Burst Arrival Time, Periodicity, Time domain, Survival Time, Capability for BAT adaptation or BAT Window, Periodicity Range from the NEF, the TSCTSF determines the TSC Assistance Container and sends it to the PCF instead of these parameters.”

[0021] 2. The NEF forwards the received individual QoS params to the TSCTSF

[0022] 3. The TSCTSF calculates a Requested PDB = Requested 5G Delay - UE-DS-TT Residence Time

[0023] 4. The TSCTSF sends a Requested PDB, TSC Assistance Container and other received individual QoS params to the PCF. TSCTSF specified parameter values are used to over-ride default values for the 5QI corresponding to the TSCTSF provided QoS Reference

[0024] 5. The PCF derives the required QoS params and determines whether this QoS is allowed, (if) It derives the Alternative QoS parameters set(s).

[0025] 6. The PCF sets the PBD and MDBV according to the Requested PDB, priority, and Burst Size received from the TSCTSF. 7. After the message exchange between the PCF, the TSCTSF and the NEF, the NEF sends the AF a message indicating whether the request is granted or not.

[0026] In the case of TSN, the TSN AF has a preconfigured QoS mapping table to translate TSN QoS parameters into 5G QoS parameters. Among these parameters, there is the Packet Delay Budget (PDB). With this, the TSN AF then sends a request to the Policy Control Function (PCF). The TSC Assistance container can also be generated by the TSN AF based on PSFP information or via preconfiguration, as described below.

[0027] The derivation of TSCAI for TSN AF or TSCTSF is as follows:

[0028] 1 . TSC Assistance Container:

[0029] • TSCTSF determines the TSC Assistance Container including

[0030] Burst Arrival Time, Periodicity, Flow Direction, Survival Time, and Time Domain

[0031] • Time domain refers to the time domain for these parameters. It might be needed to perform correct conversion from time domain clock to the 5G clock in the SMF

[0032] • (for TSN case) TSN AF determines the TSC Assistance Container using the IEEE PSFP configuration parameters provided by the

[0033] CNC to extract the traffic characteristics, yet the Survival Time may be pre-configured

[0034] 2. TSCTSF / TSN AF provides the TSC Assistance container to the PCF

[0035] 3. PCF forwards the container to the SMF as a part of PCC rules

[0036] 4. SMF binds the PCC rules with the container and use it to derive TSCAI on a per QoS Flow basis

[0037] • Converting the Burst Arrival Time (BAT), Periodicity and Survival Time from an external clock to the 5G clock using the latest time offset and cumulative rateRatio from the UPF (relative to the given Time domain)

[0038] 5. SMF sends the mapped TSCAI to the NG-RAN

[0039] Cloudification of applications (i.e., running an application instance in a virtualized environment) enables utilization of generic advantages of a virtualization system (which may for example be located in the cloud or at a remote location), such as dynamic and elastic resource handling and scaling, flexible, adaptive application deployment management, robustness, etc. Edge computing and real-time cloud features provide reduced latency between the client and the server application, enabling the cloudification of applications (e.g. TSN endpoints) with real-time requirements, such as industrial motion control or robot control. Several industrial organizations have recognized the opportunities of cloudification, so that there is already a shift of time-critical applications from dedicated, specialized execution environments to virtualized hardware systems.

[0040] An example of a process of configuring a new TSN stream in a TSN network based on a service request is shown in Figure 3. First, the TSN network is explored by the CNC, according to IEEE 802.1Qcc, obtaining the per-QoS class port-to-port min and max bridge delay of every TSN bridge. Additionally, the latency between each link in the TSN network is obtained. Using this information, the CNC can have a global view of the network with corresponding latency parameters. If a new service request (TSN flow) should be established, the CUC collects the required service parameters - step 1 in Figure 3 - and forwards the request description to the CNC together with the end station capabilities (e.g., Earliest / Latest Transmit Offset) - step 2. Then the CNC calculates the 802.1Qbv end-to-end schedule and distributes the schedule configuration to the TSN bridges - step 3. The CNC also informs the CUC about the schedule - step 4 - and the CUC configures the Talker and Listener (TSN endpoints) according to the IEEE 802.1Qdj - step 5.

[0041] In an illustrative example, in Smart Manufacturing, in the edge cloud-enabled control of Automated Guided Vehicles (AG s) the usage of IEEE 802.1Qbv concept ensures the synchronized (control) data forwarding towards the AGV devices on the shopfloor from the Automated Guided Vehicle (AGV) Swarm coordination application deployed in the edge domain, which provides the operation of the AGVs as a coordinated swarm. In the Occupational Exoskeletons use case, the low-level control functions may be offloaded to the edge domain, meaning that there is a 1ms budget for the control loop, considering the compute and network domains. In this case, on one hand, the usage of IEEE 802.1Qbv ensures predictable timing in the communication network domain, on the other hand, this predictability in the network domain provides more time budget for the compute domain, which is crucial considering the very tight 1ms time budget requirement.

[0042] To summarize, the usage of 802.1Qbv may be considered to be a central building block for ensuring time-critical, dependable communication. It should be emphasized that for the proper scheduling calculation the timing information about the network should be precise. Otherwise, the scheduling plan may not be adequate, which may cause significant negative impact on the services. To ensure end-to-end (E2E) timeliness, in Release 16 (Rel-16), 3GPP started to work on 5G-TSN integration in order to ensure a converged communication solution for time-critical services over wired and 5G wireless network domains. However, if precise E2E timeliness is required in the case of an application in the cloud, it may not be enough to properly configure the TSN and / or 5G-TSN domains, but the characteristics of a cloud deployment and the effect of virtualization should also be considered.

[0043] Figure 4 shows an example of a virtualization system (host 400). In the case of a hardwarebased controller, the controller software and hardware of an end-host are designed to guarantee deterministic performance for the application, and there is a tight relationship between the application function and the Network Interface Controller (NIC) of the end-host. This guarantees, for instance, that in the case of 802.1Qbv scheduled traffic, the application timing and NIC traffic handling configurations, configured by the CNC and CUC can be fully and precisely enforced.

[0044] In contrast, in case of a cloudified application (App), for example using the virtualization system as shown in Figure 4, the effect of virtualization, the shared resource paradigm, and handling of the timing of multiple application instances by the cloud management should be considered. Furthermore, in the case of a cloudified application, the application instance is linked to the virtual Ethernet port of the container, instead of the host Ethernet interface and there is a networking in the virtualized environment between the application instance and the NIC. The first problem here is that the timing of the virtualized networking is not deterministic due to the shared resource paradigm, and may change if there are changes in the cloud deployment. Additionally, there could be different deployment options (bare metal, Virtual Machine-based, container-based) in a cloud ecosystem, which have different characteristics and capabilities.

[0045] Another aspect in the context of TSN communication is that details of the cloud deployment (e.g. virtualized networking capabilities, resource scheduling) are hidden from the CNC. The management of the cloud system or virtualization system is not TSN-aware (i.e. does not contain a TSN-aware entity), so there is no way to explore and configure the cloud deployment according to the above mentioned TSN standards (e.g. IEEE 802.1Qcc and IEEE 802.1Qdj). This means that the virtualization system, e.g. the virtual Ethernet interfaces and the networking in the virtualized domain, cannot be configured directly by the TSN control plane. A wireless communication system such as a 5G system has an intrinsic packet delay variation (PDV) which is not acceptable to several use cases, and especially for periodic traffic. A typical example of the distribution of delays of data through a 5G wireless communication system is shown in Figure 5, which shows an example of a graph of the normalized probability of data experiencing each of a plurality of different delays through the 5G system.

[0046] One of the most prominent TSN features for deterministic transmission of time-bounded critical traffic is time scheduling, IEEE802.1Qbv, also referred to as time-aware shaping. Egress gates of a bridge (including a virtual or logical bridge representing a wireless communication system such as a 5G or 6G system) may be configured as gating mechanisms that open and close gates for different queues at the egress port. By proper configuration, critical traffic can therefore be isolated from other traffic, if the gate is exclusively opened for the queue containing the critical traffic at certain periodic instances. Exclusive means that other queue gates at that port or egress point are closed and other traffic cannot interfere with the critical traffic.

[0047] With the large PDV of a wireless communication network such as a 5G or 6G network, Wi-Fi network etc, or in nodes where application processing takes non-deterministic amounts of time, the exclusive Qbv gating is very inefficient due to the large time period that needs to be reserved exclusively to the critical traffic.

[0048] When attempting a time-aware traffic handling solution in a virtualization system or cloud deployment, two major issues arise. Firstly, there is currently no way to explore the details of a cloud ecosystem towards the TSN control plane in a standardized way. However, this is indispensable for constructing the proper 802.1Qbv scheduling plan by the CNC. In order to calculate the schedule, the following characteristics of the cloud ecosystem should have been exposed towards the CNC:

[0049] Secondly, 802.1 Qbv scheduling is TSN specific, and as such it does not contain any specific details for configuring a virtualization system. Hence, TSN configuration cannot be directly used for configuring a virtualization system.

[0050] One possible solution could be to extend the IEEE TSN control plane modelling with cloudspecific descriptors. Practically, this means the extension of the 802.1Qcc and 802.1Qdj standards with new, cloud deployment specific parameters. However, this solution has major drawbacks. Firstly, a lot of parameters would need to be exposed, which would result a very complex data model. Secondly, there would be very high deployment dependency regarding the parameters. In the case of different deployments, different parameters are needed to describe the deployment characteristics and to configure traffic application treatment and traffic handling in the virtualized domain. Finally, the required extensions in IEEE to standardize cloud-specific, complex data models are very difficult to propose and handle.

[0051] Summary

[0052] Examples of this disclosure may have certain advantages. For example, one or more of the above-mentioned problems may be solved or mitigated by embodiments of this disclosure. In some examples, embodiments may enable effective prioritization of time-critical traffic at nodes that introduce large packet delay variation (e.g. wireless communications such as 5G or 6G systems, edge cloud or virtualization systems, Wi-Fi, networks, etc.), which may avoid excessively low utilization due to exclusive gate configurations over large packet delay probabilities. Example embodiments may enable construction of a configuration, such as an IEEE 802.1Qbv traffic scheduling configuration, that can be applied to virtualization systems. Example embodiments may provide an abstraction of a virtualization system that is independent from the underlying deployment, making it transparent to the TSN control plane for example. This may ensures that any kind of cloud deployment can be integrated in an E2E TSN deployment in a seamless way.

[0053] One aspect of the present disclosure provides a method of configuring a system. The method comprising determining a representation of the system, wherein the representation comprises one or more network nodes, wherein each network node comprises a network bridge or network router. The method also comprises determining a configuration for the one or more network nodes based on a distribution of delays of data through the system, and causing the system to be configured based on the configuration for the one or more network nodes.

[0054] Another aspect of the present disclosure provides a tangible, non-transient computer- readable medium comprising instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations. The operations comprise determining a representation of the system, wherein the representation comprises one or more network nodes, wherein each network node comprises a network bridge or network router. The operations also comprise determining a configuration for the one or more network nodes based on a distribution of delays of data through the system, and causing the system to be configured based on the configuration for the one or more network nodes.

[0055] A further aspect of the present disclosure provides apparatus for configuring a system. The apparatus comprises processing circuitry and a memory. The apparatus is configured to determine a representation of the system, wherein the representation comprises one or more network nodes, wherein each network node comprises a network bridge or network router. The apparatus is also configured to determine a configuration for the one or more network nodes based on a distribution of delays of data through the system, and cause the system to be configured based on the configuration for the one or more network nodes.

[0056] Brief Description of the Drawings

[0057] For a better understanding of examples of the present disclosure, and to show more clearly how the examples may be carried into effect, reference will now be made, by way of example only, to the following drawings in which:

[0058] Figure 1 shows an example of a network in which a 5G system is modelled as a logical TSN bridge;

[0059] Figure 2 shows an example of a 5G system and a TSN CNC;

[0060] Figure 3 shows an example of a process of configuring a new TSN stream based on a service request;

[0061] Figure 4 shows an example of a virtualization system;

[0062] Figure 5 shows an example of a graph of the normalized probability of data experiencing each of a plurality of different delays through a 5G system;

[0063] Figure 6 is a flow chart of an example of a method of configuring a system;

[0064] Figure 7 illustrates an example of a virtualization system and a representation of the virtualization system; and

[0065] Figure 8 is a schematic of an example of an apparatus for configuring a system.

[0066] Detailed Description

[0067] The following sets forth specific details, such as particular embodiments or examples for purposes of explanation and not limitation. It will be appreciated by one skilled in the art that other examples may be employed apart from these specific details. Figure 6 is a flow chart of an example of a method 600 of configuring a system. The method 600 may be performed by a network node, such as for example a node within the system (e.g. a TSN AF or other node in a wireless communication system), or a node outside of the system, such as for example a network controller, CNC, CUC or other node.

[0068] The method 600 comprises, in step 602, determining a representation of the system, wherein the representation comprises one or more network nodes, wherein each network node comprises a network bridge or network router. The representation of the system may be for example an abstract representation of the system. The representation of the system may thus be for example an abstract representation that comprises a network including one or more routers or bridges, such as for example one or more DetNet routers and / or one or more TSN bridges, and / or one or more network nodes with deterministic latency. The representation may for example represent certain behaviour of data in the system, such as for example between ingress and egress ports or points of the system, or between an ingress / egress port / point and a data endpoint (e.g. TSN Talker or TSN Listener). Each network node in the representation may be a logical or virtual network node, such as for example a logical or virtual router or a logical or virtual bridge. The data may comprise one or more data units, packets, service data units, SDlls, protocol data units, PDlls, and / or network streams.

[0069] Step 604 of the method 600 comprises determining a configuration for the one or more network nodes based on a distribution of delays of data through the system. The configuration may be for example one or more of a DetNet configuration, 802.1Qbv configuration of egress port(s) of the network node(s), PSFP configuration of ingress port(s) of the network node(s), and / or other configuration. The configuration may for example also be determined based on requirements for the system or the representation, e.g. the requirements for the throughput, latency, jitter etc. of data through the system or representation. As used herein, a “configuration” may be for example information, such as settings, that can be applied to or is intended to be applied to the one or more network nodes in order to configure those network nodes, even if in some examples the configuration is not applied directly to the network nodes to configure the network nodes.

[0070] Step 606 of the method 600 comprises causing the system to be configured based on the configuration for the one or more network nodes. For example, the configuration may be translated from a configuration for the representation to a configuration for the system, e.g. a configuration for one or more nodes or components of the system. Thus, in some examples, the representation may present a standardized view of the system which may then be configured in an implementation-independent or standard manner.

[0071] In some examples, the system may be a wireless communications system such as a 5G system 6G system, Wi-Fi network or other type of wireless communications system.

[0072] In examples where the system experiences or demonstrates packet delay variation (PDV), such as in a wireless communication network or a 5G or 6G network, the distribution of delays of the data through the system comprises a respective proportion of data that experiences each of a plurality of delays through the system. That is, for example, data moving through the system may experience a range of possible delays as shown in Figure 5. In some examples, determining the configuration for the one or more network nodes based on the delays of data through the system comprises determining the configuration for the one or more network nodes based on a window of at least a threshold proportion of the distribution of delays for the data through the system. That is, for example, the window (e.g. the smallest window) may be the range of delays that contains at least X% of the probability that the delay will be one of those values within that window.

[0073] In some examples, causing the system to be configured based on the configuration for the one or more network nodes in step 606 of the method 600 comprises causing timing of an egress window of the data from the system to be configured based on the configuration for the one or more network nodes. This may be for example an 802.11Qbv window.

[0074] Determining the configuration for the one or more network nodes based on the delays of the data through the system in step 604 of the method 600 may in some examples comprise determining the configuration for the one or more network nodes based on timing of the data entering the system (e.g. at an ingress or PSFP window, or being created at a TSN Talker). That is, for example, defining some properties of one or more of the network nodes (e.g. timing of an egress window or Qbv window) may in some examples be additionally based on timing of the data entering the system, for example at an ingress point. For example, the configuration may be based on the timing of an ingress window or PSFP window. In this way, the timing of an egress or Qbv window of one or more of the network node(s) can be configured appropriately such that it is “open” to critical data at times when the critical data is expected to reach the egress or Qbv window taking into account the timing of the data entering the system. In some examples, the system comprises a plurality of network nodes, and causing the system to be configured based on the configuration for the one or more network nodes of the representation comprises causing one or more of the network nodes of the system to be configured based on the configuration for the one or more network nodes of the representation. That is, for example, the configuration for the representation may be translated to a configuration for the nodes of the system.

[0075] In some examples, the representation of the system comprises one network node. For example, where the system is a wireless communication network such as a 5G or 6G network, the representation may be one network node such as a TSN bridge or DetNet router. Alternatively, in some examples, the representation may comprise a plurality of network nodes, such as a network of network nodes. This may be appropriate for example where the system comprises a virtualization system.

[0076] In such examples, the distribution of the delays of the data through the system comprises a respective delay due to each of a plurality of components of the virtualization system. The components may be hardware or software components and may include, for example, application(s), container(s), physical or virtual NIC(s), hypervisor(s), host operating system(s) (host OS(s)), and / or one or more other hardware and / or software components. Each of these components, and / or any interfaces between them, may have a respective delay or other communication characteristics that may be modelled as a network node such as a router or bridge. Therefore, in some examples, the representation of the system may include a plurality of routers and / or bridges representing the delays of the components and / or interfaces, and thus represent a distribution of delays of data through the system.

[0077] In some examples, for example in a virtualization system, the representation may include one or more network endpoints (e.g. TSN Talker(s) and / or TSN Listener(s)), each network endpoint representing a respective application in the virtualization system. Each network endpoint may be connected to one of the network nodes in the representation for example.

[0078] The properties of each of the network endpoints may in some examples represent characteristics of the virtualization system. For example, the properties of each of the network endpoints comprise delay and / or delay variation of each of the network endpoints, and / or the characteristics of the virtualization system comprise timings of scheduling of the applications in the virtualization system, such as for example scheduling on a processing apparatus (e.g. one or more CPUs) and / or scheduling by an operating system. In some examples, causing the system to be configured based on the configuration for the one or more network nodes comprises causing the timings of scheduling of the applications to be configured based on the properties of the network endpoints. For example, where a network endpoint in the representation is configured with a certain timing window, such as a PSFP window or Qbv window, this may in some examples be translated to scheduling of the application that is represented by that network endpoint.

[0079] In some examples, properties of each of the network nodes (e.g. delay and / or delay variation of each of the network nodes) represent characteristics (e.g. delay and / or delay variation characteristics) of the virtualization system. The characteristics of the virtualization system may in some examples comprise one or more of the following non-limiting examples:

[0080] • characteristics of an interface between an application and container orchestration of the virtualization system;

[0081] • characteristics of an interface between an application and a virtual Network Interface Card, vNIC, of the containerized virtualization system;

[0082] • characteristics of an interface between a virtual machine containing an application and a hypervisor of the virtualization system;

[0083] • characteristics of an interface between container orchestration and a hypervisor of the virtualization system;

[0084] • characteristics of an interface between container orchestration and / or a hypervisor and an operating system of the virtualization system; and / or

[0085] • characteristics of an interface between a physical network interface card, NIC, of the virtualization system and one or more of a hypervisor, operating system, container orchestration, virtual machine, and / or application of the virtualization system.

[0086] The above non-exhaustive list includes interfaces that may in some examples incorporate components of the virtualization system. For example, an interface between an application and a virtual NIC may incorporate or take into account a container in which the application is executing, where the container is effectively between the application and the virtual NIC. In some examples, the distribution of delays of the data through the system comprise a respective delay for the data due to each of the interfaces of the virtualization system (or at least the interfaces represented by the representation of the system).

[0087] In some examples, causing the system to be configured based on the configuration for the one or more network nodes in step 606 of the method 600 may comprise causing the characteristics of the virtualization system to be configured based on the properties of the network nodes. That is, for example, where possible, the timing (e.g. delay and / or delay variation) of the components of the virtualization system may be configured based on the configuration for the representation. For example, the configuration for the representation may be translated to a configuration for the characteristics of the virtualization system.

[0088] In some examples, determining the representation of the system in step 602 of the method 600 comprises receiving the representation from a network node (eg. a network node in the system). This may be the case for example where the method 600 is performed by a node outside of the system, such as for example a network controller, CNC or CUC. In such examples, the node performing the method 600 may determine the configuration for the one or more network nodes by generating the configuration for the one or more network nodes based on the distribution of the delays of the data through the system. Causing the system to be configured based on the configuration for the one or more network nodes in step 606 of the method 600 may comprise sending the configuration to the system.

[0089] In some examples, determining the representation of the system in step 602 of the method 600 may comprise generating the representation. This may the case for example where the node performing the method 600 is a node in the system or otherwise is a node with access to detailed information regarding the system. In some examples, causing the system to be configured based on the configuration for the one or more network nodes in step 602 of the method 600 may comprise configuring the system based on the configuration (e.g. translating the configuration for the representation to a configuration for the system). This may be the case for example where the node performing the method 600 is a node that configures the system, such as for example a node within the system (e.g. TSN AF) or a controller of the system. The configuration for the representation may for example be received from another node such as a network controller, CNC or CUC. In such examples, determining the configuration for the one or more network nodes in step 604 of the method 600 may comprise for example sending the representation to a network node and receiving the configuration from the network node.

[0090] The following describes specific illustrative example embodiments where the system referred to above is a wireless communication system, specifically a 5G communication system.

[0091] In examples of this disclosure, a Qbv configuration for TSN bridges may be determined that is effective for nodes or systems with large PDV, and provides a good trade-off between critical latency performance and efficiency of exclusive access to the egress link. For a (virtual or logical) bridge (e.g. representing a 5G system, a 6G system, a Wi-Fi network, a virtualization system or part thereof), the packet delay characteristics may be estimated (e.g. probability distribution I histogram) at the egress bridge port. This information may be reported to a node such as a network controller or CNC. At this node, a latency range may be identified, in which the majority of the packet delay can be expected. For example, the smallest range may be identified in which there is at least X% probability that data moving through the system experiences a delay in that range. The node may define an exclusive gate configuration for the critical traffic queue that matches the dense latency range. That is, for example, timing of an egress window or gate for exclusive use by critical traffic may be defined.

[0092] Optionally, in some examples, the gate for the critical traffic queue may remain open during times other than the window. One benefit is that a late arriving packet of the critical queue does not interfere with the next occurrence of the exclusive window. Optionally, a reduced priority for the critical traffic queue may be defined for times outside of the window, e.g. when gates are intended / planned for other traffic queues. One benefit is that the other traffic is not significantly impacted by the critical traffic outside of the window times.

[0093] In some examples, the gating at the egress point from the system may have a third state, referred to as “drop”. For example, the gate may be open for exclusive use by critical traffic inside the window and closed (where critical traffic is queued) outside of the window. For the third state “drop,” critical traffic may be dropped. With this state, which may for example occur after the state where critical traffic is queued and before the next open state inside the window, the upper part of the packet delay distribution (e.g. as shown in Figure 5), for example above a threshold packet delay value, the critical traffic is dropped. The threshold value may be chosen in some examples such that the packet delay accumulated probability between the threshold value and the maximum possible delay is below the probability value of acceptable packet losses for the critical traffic. The threshold value may in some examples be received at the node (e.g. CNC or network controller) from the system.

[0094] In some examples, identifying the latency range, in which for example at least X% of the packet delay can be expected, can be performed either at the node (e.g. CNC or network controller) or at a node in the system. If performed in the system, the range itself can be reported to the node (e.g. CNC or network controller), otherwise the packet delay distribution (e.g. as shown in Figure 5) can be reported to or otherwise obtained by the node (e.g. CNC or network controller). Above examples are described in the context of TSN Qbv, though these examples can also be applied to different technologies, such as DetNet or others.

[0095] The following describes specific illustrative example embodiments where the system referred to above is a virtualization system, which may be referred to below as a cloud system (though the virtualization system or cloud system may not necessarily be located at a remote location).

[0096] Examples of this disclosure propose an abstraction of the virtualization system for the TSN control plane, which can model and describe any kind of cloud deployment, for example according to the 802.1Qcc and 802.1Qdj standards. The abstraction may in some examples include:

[0097] • A set of virtual TSN endpoints, or virtual TSN endpoints, each endpoint connected to a virtual TSN bridge and representing an application instance.

[0098] • A set of virtual TSN bridges for representing components of the virtualization system, and / or interfaces between those components.

[0099] The abstraction enables for example the conversion of a virtualization system deployment to a virtual view (i.e. the representation of the system referred to above), which can be exposed towards the TSN control plane, e.g. according to 802.1Qcc and 802.1Qdj. Furthermore, some examples provide a TSN-aware management entity, which is responsible to build, maintain, and parameterize the abstracted representation, including:

[0100] • Collect the required, cloud deployment specific information for the abstraction.

[0101] • Construct and parameterize the abstracted representation.

[0102] • Expose the abstracted view towards the TSN control plane, e.g. according to IEEE 802.1Qcc and 802.1Qdj.

[0103] Furthermore, the TSN-aware management entity may also in some examples be responsible for:

[0104] • receiving the 802.1 Qbv traffic scheduling plan from a node such as a CNC or network controller

[0105] • translating the 8021.Qbv specific configuration to cloud deployment specific settings

[0106] • enforcing the required configuration in the cloud domain, including the required settings in application scheduling and configuration of traffic handling schemes in the virtualized domain. Figure 7 illustrates an example of a virtualization system 700 and a representation 702 of the virtualization system 700. The virtualization system 700 (labelled as host in Figure 7) shows several types of example deployments. These comprise bare metal deployment 704, virtual machine (VM)-based deployment 706, and containerized deployment 708, when a container execution environment is deployed in a VM. A virtualization system may include one or more of any one or more of these example types of deployment, and / or one or more other types of deployment.

[0107] In some examples, for each deployment, the representation 702 of the system includes a corresponding deployment or corresponding (virtual or logical) network nodes. For example, as shown in Figure 7, the representation 702 of the virtualization system 704 includes nodes corresponding to a bare metal deployment 710, virtual machine (VM)-based deployment 712, and containerized deployment 714.

[0108] The representation 702 may in some examples include the following components:

[0109] 1. Virtual TSN endpoints 716 (labelled as apps in Figure 7): these elements represent the application instances 718 in the virtualization system 700, for example in a one-to-one mapping manner. These may provide application timing / scheduling information, which represents the application scheduling capabilities in the virtualization system 700. If the precise timing of the scheduling of an application instance 718 can be guaranteed by a virtualization system management entity (e.g. cloud management 720), in some examples, then the latency on a link between the TSN endpoint 716 and the connected virtual TSN bridge can be considered in the representation 702 as a Transmit offset for a certain application instance 718. If there is some uncertainty or variance in the scheduling of an application, then the Earliest Transmit Offset and the Latest Transmit Offset (please see Figure 1 and the related description) can be reported towards the CUC. In some cases, a more detailed description of application scheduling would be needed. In this case an alternative application modeling can also be applied, where an application is represented by a TSN endpoint and a virtual bridge (green virtual bridges in Figure 4). In this case, the reported min and max bridge delay can represent further characteristics / uncertainties of the application scheduling.

[0110] 2. Virtual TSN bridges 722: These nodes represent networking characteristics, depending on the cloud deployment option. For example, each virtual TSN bridge 722 may represent a component in the virtualization system 700, or an interface between components. In some examples, networking in each domain of the host (e.g., host networking, networking in the guest OS, container network interface (CNI), etc.) is represented by respective virtual TSN bridge(s) 722. The virtual bridge 722 that represents networking in the host OS is directly connected to a representation 724 of the system’s NIC 726. If, in some examples, there are multiple NICs, then two alternatives are possible: a. only a single virtual bridge 722 is used, with multiple southbound interface ports, which are connected to the NICs respectively; or b. multiple virtual bridges 722 are used, one per NIC.

[0111] The networking on the different levels of the representation 702 may also in some examples be represented by separate virtual bridges 722, as shown in the VM-based deployment 712 in the representation 702 in Figure 7. That is, for example, separate bridges 722 are used for the different VMs due to the isolation between VMs. Thus, in some examples, at least some of the virtual bridges 722 may form a tree structure, where the root is the virtual bridge 722 that represents the host networking and is connected directly to the representation 724 of the physical NIC 726.

[0112] In some examples, TSN-aware management entity (e.g. the cloud management 720 shown in Figure 7) may be present with the following functionalities:

[0113] • It is fully aware of the cloud deployment (e.g. arrangement of the virtualization system and its components and interfaces) and able to explore and collect all the details of the deployment and its characteristics, such as application scheduling and networking. To this end, the TSN-aware cloud management entity may be able to control or influence CPU scheduling of the virtualization system. Furthermore, it can obtain information about the time characteristics / uncertainties of the networking on various virtualization levels, e.g. the delays and delay variations.

[0114] • Based on this information, the TSN-aware cloud management entity is able to construct the abstracted representation of the virtualization system with the TSN endpoints and virtual bridges, and able to parameterize the representation using properties of the virtualization system, such as for example the time characteristics / uncertainties of the networking on various virtualization levels.

[0115] • Towards the network controller (e.g. TSN control plane, CUC or CNC), the TSN- aware cloud management entity may act as a proxy with the capability to expose the abstract representation of the virtualization system, e.g. according to the IEEE 802.1Qcc and IEEE802.1Qdj standards. • The TSN-aware cloud management entity may also be responsible to receive the 802.1Qbv scheduled traffic configuration and application configuration provided by the network controller.

[0116] • Additionally, leveraging its cloud-awareness, the TSN-aware cloud management entity may be able to translate the 802.1Qbv scheduling plan to a virtualization system specific configuration, and may also be able to enforce configurations in (1) application scheduling, and (2) traffic handling in the different levels of virtualized networking, in order to ensure the 802.1Qbv-aware traffic handling in the virtualization system.

[0117] An example of construction of the system representation (i.e. representation of the virtualization system) and the 802.1Qbv-aware configuration is described below. Certain steps are described as being performed by a TSN-aware cloud management function, though in other examples any other node or nodes may perform each of the steps. Furthermore, references herein to the “cloud” and “cloudified applications” is merely exemplary, and the virtualization system and applications executing thereon may not necessarily be located in the cloud or at a remote location.

[0118] Step 1 : Explore the cloud deployment by the TSN-aware cloud management function. As an example, bare metal and VM-based deployments on the host are used, but the operation steps are the same in the case of any other cloud deployment option. Initially, the TSN-aware cloud management function starts to explore the characteristics of the cloud deployment, including performing the following actions

[0119] • explore the type of virtualization used in the virtualization system, which is used to determine the structure (topology) of the virtual TSN bridges in the abstraction model

[0120] • explore the networking configuration capabilities in the virtualized domain and in the host.

[0121] • Using a monitoring solution, the TSN-aware cloud management function will measure the network capabilities, such as latency, latency variation, and / or jitter in the virtualized networking domains. This information can be used to calculate the minimum and maximum bridge delay parameters for every virtual TSN bridge in the representation of the virtualization system. Any kind of monitoring option that is able to determine the latency and variation / jitter in a virtualization system can be used for this purpose. • In order to provide the Earliest Transmit Offset and the Latest Transmit Offset parameters for each application instance, the TSN-aware cloud management function may obtain the details about the application scheduling plan and possible uncertainties. First of all, the type of scheduling used (FIFO, Earliest Deadline First (EDF), etc.) and the scheduler configuration is obtained, and then the possible application scheduling timing is determined, considering the application execution time. Based on this information, the Earliest Transmit Offset and the Latest Transmit Offset parameters are calculated for the abstract representation of the system. If the combination of a TSN endpoint and a virtual TSN bridge is used for representing an application, as in some examples, the minimum and maximum bridge delays can also determined in this step, based on the scheduling capabilities / limitations.

[0122] Step 2: Build the abstracted representation of the virtualization system and expose it towards the TSN control plane. Using the collected information, the abstracted representation is constructed and parameterized. To this end, the TSN-aware cloud management function emulates a virtual TSN segment that consists of (virtual) TSN endpoints (representing the application instances) and (virtual) TSN bridges (representing networking in the virtualization environment). The virtual TSN segment is emulated towards the TSN control plane, which treats each component (endpoint or bridge) as a fully-fledged TSN network component. The topology and parameters of this abstract view are transmitted from the TSN-aware cloud management entity to a network controller, e.g. CNC and / or CUC, using for example the standard NETCONF protocol. Based on the information the network controller is able to calculate the 802.1Qbv scheduling plan.

[0123] Step 3: Receive and process the 802.1Qbv configuration information from the network controller (e.g. CNC and / or CUC). Whan the network controller determines a 802.1Qbv scheduling plan, it initiates the determination of a configuration for the bridges in the network. In an E2E deployment, it includes the configuration for physical bridges, and in addition, includes the configuration for the virtual bridges of the abstracted representation of the virtualization system. This means that for the egress port of each of the virtual TSN bridges (that represent the networking in the virtualization domain), the corresponding 802.1Qbv scheduling configuration is provided by the CNC.

[0124] Step 4: The final step is to configure the virtualization system based on the configuration for the representation, e.g. to perform translation of the TSN specific 802.1Qbv configuration information to a cloud-deployment specific configuration. For example: • The Interval and Transmit offset parameters provided by the network controller (e.g. CUC and / or CNC) are translated to application scheduling configuration. In the case of Earliest Deadline First (EDF) scheduling - considered as an illustrative example - the Interval is used to specify the period parameter of EDF, while the Transmit offset is used to calculate the deadline parameter.

[0125] • The per (virtual TSN bridge) port 802.1Qbv configuration is translated to cloudspecific time-aware traffic handling solutions. For example, if a Linux TAPRIO- based per-container gating scheme is applied, then opening times for each per- container gate are configured in a coordinated manner, based on the 802.1Qbv scheduling information and the application scheduling. If a centralized 802. Qbv- aware traffic scheme is used, traffic shaping realized by the usage of Linux qdisc discipline is also configured based on the 802.1Qbv scheduling information.

[0126] It should be noted that while the above examples are presented in the context of 802.1Qbv scheduled traffic, the generic manner of the abstract representation of the system may in some examples allow for the use of other traffic handling solutions of the TSN. For example, the IEEE 802.1Qci - Per Stream Filtering and Policing mechanism - provides mechanisms for filtering and policing individual data streams to ensure robust performance by preventing congestion and ensuring compliance with predefined traffic policies. In the case of 802.1Qci, per-stream filtering is configured to the ingress port of a TSN bridge. Using the abstract representation, the 802.1Qci configuration can also be determined for the ingress ports of the virtual bridges.

[0127] In some examples, the CUC, based on the received information from the CNC, is responsible for configuring the TSN endpoints. The CUC may for example send this configuration information to the TSN-aware cloud management entity or other appropriate node performing one or more of the steps described herein. This information may include for example the Interval and Transmit offset parameters.

[0128] Figure 8 is a schematic of an example of an apparatus 800 for configuring a system. The apparatus 800 comprises processing circuitry 802 (e.g. one or more processors) and a memory 804 in communication with the processing circuitry 802. In some examples, the apparatus 800 is configured (e.g. the memory 804 contains instructions executable by the processing circuitry 802 such that the apparatus 800 is operable / configured) to determine a representation of the system, wherein the representation comprises one or more network nodes, wherein each network node comprises a network bridge or network router; determine a configuration for the one or more network nodes based on a distribution of delays of data through the system; and cause the system to be configured based on the configuration for the one or more network nodes. In some examples, the apparatus 800 is operable / configured to carry out the method 600 described above with reference to Figure 6. It should be noted that the above-mentioned examples illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative examples without departing from the scope of the appended statements. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the statements below. Where the terms, “first”, “second” etc. are used they are to be understood merely as labels for the convenient identification of a particular feature. In particular, they are not to be interpreted as describing the first or the second feature of a plurality of such features (i.e., the first or second of such features to occur in time or space) unless explicitly stated otherwise. Steps in the methods disclosed herein may be carried out in any order unless expressly otherwise stated. Any reference signs in the statements shall not be construed so as to limit their scope.

Claims

Claims1. A method of configuring a system, the method comprising: determining a representation of the system, wherein the representation comprises one or more network nodes, wherein each network node comprises a network bridge or network router; determining a configuration for the one or more network nodes based on a distribution of delays of data through the system; causing the system to be configured based on the configuration for the one or more network nodes.

2. The method of claim 1 , wherein the system is a wireless communications system.

3. The method of claim 1 or 2, wherein the distribution of delays of the data through the system comprises a respective proportion of data that experiences each of a plurality of delays through the system.

4. The method of claim 1 or 2, wherein determining the configuration for the one or more network nodes based on the delays of data through the system comprises determining the configuration for the one or more network nodes based on a window of at least a threshold proportion of the distribution of delays for the data through the system.

5. The method of claim 3, wherein determining the configuration for the one or more network nodes based on the delays of data through the system comprises determining the configuration for the one or more network nodes based on a smallest window of at least a threshold proportion of the distribution of delays for the data through the system6. The method of any of claims 1 to 5, wherein causing the system to be configured based on the configuration for the one or more network nodes comprises causing timing of an egress window of the data from the system to be configured based on the configuration for the one or more network nodes.

7. The method of any of claims 1 to 6, wherein determining the configuration for the one or more network nodes based on the delays of the data through the system comprises determining the configuration for the one or more network nodes based on timing of the data entering the system.

8. The method of any of claims 1 to 7, wherein the system comprises a plurality of network nodes, and causing the system to be configured based on the configuration for the one or more network nodes comprises causing one or more of the network nodes to be configured based on the configuration for the one or more network nodes.

9. The method of any of claims 1 to 8, wherein the representation of the system comprises one network node.

10. The method of any of claims 1 to 8, wherein the representation comprises a network of network nodes.11 . The method of claim 10, wherein the system comprises a virtualization system.

12. The method of claim 11 , wherein the distribution of the delays of the data through the system comprises a respective delay due to each of a plurality of components of the virtualization system.

13. The method of claim 11 or 12, wherein the representation comprises one or more network endpoints, each network endpoint representing a respective application in the virtualization system.

14. The method of claim 13, wherein each network endpoint is connected to one of the network nodes in the representation.

15. The method of any of claims 11 to 14, wherein properties of each of the network endpoints represent characteristics of the virtualization system.

16. The method of claim 15, wherein the properties of each of the network endpoints comprise delay and / or delay variation of each of the network endpoints, and / or the characteristics of the virtualization system comprise timings of scheduling of the applications in the virtualization system.

17. The method of claim 16, wherein causing the system to be configured based on the configuration for the one or more network nodes comprises causing the timings of scheduling of the applications to be configured based on the properties of the network endpoints.

18. The method of any of claims 13 to 17, wherein the network endpoints comprise time sensitive networking, TSN, endpoints.

19. The method of any of claims 11 to 18, wherein properties of each of the network nodes represent characteristics of the virtualization system.

20. The method of claim 19, wherein the properties of each of the network nodes comprise delay and / or delay variation of each of the network nodes.21 . The method of claim 19 or 20, wherein the characteristics of the virtualization system comprise one or more of: characteristics of an interface between an application and container orchestration of the virtualization system; characteristics of an interface between an application and a virtual Network Interface Card, vNIC, of the containerized virtualization system; characteristics of an interface between a virtual machine containing an application and a hypervisor of the virtualization system; characteristics of an interface between container orchestration and a hypervisor of the virtualization system; characteristics of an interface between container orchestration and / or a hypervisor and an operating system of the virtualization system; and / or characteristics of an interface between a physical network interface card, NIC, of the virtualization system and one or more of a hypervisor, operating system, container orchestration, virtual machine, and / or application of the virtualization system.

22. The method of claim 21 , wherein the distribution of delays of the data through the system comprise a respective delay for the data due to each of the interfaces of the virtualization system.

23. The method of any of claims 19 to 22, wherein the characteristics of the virtualization system comprise one or more of delay and / or delay variation characteristics.

24. The method of any of claims 19 to 23, wherein causing the system to be configured based on the configuration for the one or more network nodes comprises causing the characteristics of the virtualization system to be configured based on the properties of the network nodes.

25. The method of any of claims 1 to 24, wherein determining the representation of the system comprises receiving the representation from a network node.

26. The method of claim 25, wherein the network node is a network node in the system.

27. The method of any of claims 1 to 26, wherein causing the system to be configured based on the configuration for the one or more network nodes comprises sending the configuration to the system.

28. The method of any of claims 1 to 27, wherein determining the configuration for the one or more network nodes comprises generating the configuration for the one or more network nodes based on delays of data through the system.

29. The method of any of claims 1 to 28, wherein determining the representation of the system comprises generating the representation.

30. The method of any of claims 1 to 24 and 29, wherein causing the system to be configured based on the configuration for the one or more network nodes comprises configuring the system based on the configuration.31 . The method of any of claims 1 to 27 and 29 to 30, wherein determining the configuration for the one or more network nodes comprises sending the representation to a network node and receiving the configuration from the network node.

32. The method of any of claims 1 to 31 , wherein the data comprises one or more data units, packets, service data units, SDlls, protocol data units, PDlls, and / or network streams.

33. The method of any of claims 1 to 32, wherein the configuration for the one or more network nodes comprises an IEEE 802.1Qbv configuration.

34. The method of any of claims 1 to 33, wherein the one or more network nodes comprise one or more time sensitive networking, TSN, bridges, Deterministic Networking, DetNet, bridges, and / or network nodes with deterministic latency.

35. A tangible, non-transient computer-readable medium comprising instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations comprising: determining a representation of the system, wherein the representation comprises one or more network nodes, wherein each network node comprises a network bridge or network router; determining a configuration for the one or more network nodes based on a distribution of delays of data through the system; causing the system to be configured based on the configuration for the one or more network nodes.

36. The computer-readable medium of claim 35, comprising instructions that, when executed by processing circuitry, cause the processing circuitry to perform the method of any of claims 2 to 34.

37. A computer program, comprising instructions that, when executed by processing circuitry, cause the processing circuitry to carry out the method according to any of claims 1 to 34.

38. A computer-readable medium comprising instructions that, when executed by processing circuitry, cause the processing circuitry to carry out the method according to any of claims 1 to 34.

39. A carrier containing the computer program of claim 38, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer-readable medium.

40. An apparatus for configuring a system, the apparatus comprising processing circuitry and a memory, the apparatus configured to: determine a representation of the system, wherein the representation comprises one or more network nodes, wherein each network node comprises a network bridge or network router; determine a configuration for the one or more network nodes based on a distribution of delays of data through the system; cause the system to be configured based on the configuration for the one or more network nodes.41 . The apparatus of claim 40, wherein the apparatus is configured to perform the method of any of claims 2 to 34.

Images