Methods and time-sensitive network systems that consider configuring a set of processing flows for a time-sensitive network

Abstract

The present disclosure relates to a method and a product for handling stream requests. Upon obtaining a stream request (S1), an initial TSN schedule is computed (S2) at the CNC based on initial TSN capabilities obtained from a dynamic bridge (DB). Then, a loop is initiated. In each iteration, it is determined (S4) whether to provide the CNC with information related to updated TSN capabilities of the DB based on information related at least to the last computed TSN schedule. If it is decided to provide said information, the CNC computes (S6) an updated TSN schedule based on said information. Otherwise, the loop is exited (S7). It is determined (S8) whether to configure (S8a) a TSN according to one of the at least one computed TSN schedule or to request (S8b) an adjustment of at least one stream request based on at least one computed TSN schedule.

Description

TECHNICAL FIELD

[0001] The present disclosure is in the field of telecommunications.

[0002] In particular, a method of handling a set of stream requests of a time sensitive network (e.g. 3GPP / 5G system) considering configuration of a time sensitive network, such as a wireline time sensitive (TS) bridged network comprising a wireless bridge, is disclosed. A corresponding time sensitive network system, an entity of such a system, a computer program, a computer readable storage medium and a processing circuit are also disclosed. BACKGROUND

[0003] Fast and reliable communication and information networking, in particular Time Sensitive Networking (TSN), is of paramount importance for smart factory environments. It enables the integration of the whole factory by tightly connecting the various production steps as well as production planning and logistics.

[0004] In order to provide the sought connectivity, industrial networks need to support various types of traffic, including Time Sensitive (TS) traffic for real-time control of machines and services that require deterministic performance.

[0005] Time Sensitive Networking (TSN) is standardized in IEEE 802.1Q to provide deterministic latency to industrial networks to handle TS traffic. End-to-end communication deadlines and bounded jitter are guaranteed through a variety of mechanisms, such as time synchronization and TSN scheduling (e.g. according to per-flow and per-port gating lists generated for all components within the network) of individual frames and streams standardized in IEEE 802.1Qcc.

[0006] Initially, TSN networking was intended for wireline networks, enabling high-speed communication between sensors / controllers and IT centers. The shift from wireline sensors and actuators to wireless sensors and actuators provides additional advantages, such as mobility, scalability in size and reduced maintenance costs.

[0007] In order to connect wireless devices to TSN networks, wireless transmission technologies such as those defined in 3GPP are needed.

[0008] The integration between wireline and wireless technologies poses a number of challenges that are not fully solved yet, such as standard compatibility and characteristics of data transmission over (bounded) wireline and (open) wireless media.

[0009] Although the description of wireless networks below focuses on 3GPP / 5G networks, it can be generalized to any wireless communication system.

[0010] Some TSN use cases are computationally complex and require time-consuming calculations of gating lists per flow and / or per port for each component within the entire network. To accommodate such TSN use cases, it is beneficial to concentrate the calculations in a single centralized entity that is able to collect information about the entire network in order to find the best network configuration and schedule for each component therein. This model is commonly referred to as centralized.

[0011] In Figure 1 this configuration cycle for wired TSN in IEEE 802.1Qcc is schematically shown, the detailed workflow of which is shown in Figure 2 .

[0012] In this centralized model, the Centralized User Configuration (CUC) entity (3) discovers (10) End Stations (ESs) (1), gets (11, 12) ES capabilities and user requirements, and configures TSN features in the End Stations by creating (13) a set of flow requests. Then, the configuration information is provided (14) to the Centralized Network Configuration (CNC) entity (2).

[0013] The CNC can access (15) (if already accessible) or discover (16) the network physical topology. The CNC can also access (17) (if already accessible) or read (18) the TSN capabilities of all bridges on the network.

[0014] After obtaining all the required configuration information, the CNC generates (19) a schedule that is tested (20) for compliance with the requirements of the set of flow requests. If successful, the CUC prepares (22) all End Stations, and the CNC configures (23) all bridges of the TSN flow. The CNC has a complete view of the network’s physical topology and the capabilities of all bridges.

[0015] In the case that the CNC cannot find a schedule that meets the requirements of all flow requests provided by the CUC, a new iteration of the TSN configuration cycle is initiated, which includes the step of adjusting (21) the initial flow requests.

[0016] Figure 1 The implementation in assumes that the TSN capabilities of all components (= bridges) and the network physical topology are fixed and independent of the traffic load. The static nature of wired components allows the CNC to read the network physical topology and the bridge TSN capabilities only once, and then use this data for the TSN scheduling process, regardless of the number of iterations needed to generate a successful schedule corresponding to the initial (or adjusted) flow requests.

[0017] In principle, this implementation allows seamless integration between TSN and 5G networks, provided that the internal functioning of the latter is hidden from the CNC. This can be done, for example, using a so-called TSN Translator (TT) entity, which implements bidirectional communication between the CNC and the 5GS for both data and control information, thanks to the translation of the TSN commands (for example, defined by IEEE 802.1) provided by the CNC into specification parameters understood by the wireless network (for example, defined by 3GPP) and vice versa. This allows the CNC to treat the 5GS like a virtual TSN bridge having the same properties as a normal wired TSN bridge.

[0018] While the use of TTs simplifies the integration between TSN and 5GS, it does not provide means to configure the 5GS whose performance characteristics are different from those of a static wired bridge, but depend on the traffic load and the Radio Allocation (RA) used by the 5GS to support said traffic.

[0019] The dynamic nature is intrinsic to wireless bridges, and in particular to 3GPP / 5GS, since all internal links between the ports of such virtual bridges go through a shared wireless medium. To avoid crosstalk between different ports leading to flow collisions, different RAs and time / frequency multiplexing techniques are used, resulting in different TSN capabilities of the 5GS, which are a function of the traffic load.

[0020] This makes the network configuration procedure illustrated in Figure 1 and Figure 2 inefficient at least when it comes to selecting the proper internal configuration of the 5GS among the different possible configurations available through different RA allocations.

[0021] The freedom to select different RAs provides the 5GS with flexibility that is not available to wired TSN bridges. However, currently the CNC cannot exploit these additional degrees of freedom due to the limitations of the existing TSN configuration procedure.

[0022] No available solution has so far addressed these issues, which constitute the bottleneck of the effective integration between wired TSN and 5GS networks. These issues are intrinsic to any TSN network comprising a 5GS wireless bridge, or more generally to any TSN network comprising at least one dynamic component, characterized by supporting at least two different internal configurations associated with two different TSN capabilities.

[0023] As mentioned above, it is highly desirable to ensure that the 5G system is used in the best possible conditions within the TSN network.

[0024] The established TSN configuration and scheduling procedures for TSN networks assume that all components (links and bridges) are static, in the sense that each component can be characterized by a single set of parameters describing its TSN capabilities that remain constant and independent of the traffic load on said component. This assumption is generally true for wired links and bridges, but not for wireless components, which are typically characterized by having variable TSN capabilities depending on the traffic load and the internal configuration of said component to support the required traffic load. This leads to a bottleneck for the effective integration between wired (e.g. IEEE 802.1) and wireless networks (e.g. 3GPP / 5G).

[0025] More specifically, the established TSN configuration and scheduling methods do not provide means for the CNC to assess different internal configurations of a wireless component, which typically provide conservative values of its TSN capabilities defined for assumed worst-case scenarios rather than actual traffic loads. This impacts the overall end-to-end (e2e) delay and hinders the wireless network to work at its best, which ultimately impacts the overall performance of the TSN network.

[0026] It should be noted that the above constraints of the prior art are inherent to any hybrid TSN network comprising at least one dynamic component characterized by having at least two different TSN capabilities associated with different internal configurations. Solving said constraints can pave the way for next generation TSN networks comprising dynamic components (wired or wireless) characterized by their ability to adapt their TSN capabilities according to the intended use. SUMMARY

[0027] The present application is defined by the appended independent claims. Additional features and advantages of the concepts disclosed herein are set forth in the description that follows.

[0028] It is an object of the present application to overcome the above-mentioned limitations.

[0029] Therefore, a method of considering a set of processing flow requests to configure a time sensitive network, said time sensitive network comprising at least a centralized network configuration entity operatively connected to a plurality of end station entities and a dynamic bridge entity is disclosed herein,

[0030] The method comprises, upon obtaining a set of flow requests from at least a part of the plurality of end station entities and / or obtaining a set of flow requests to at least a part of the plurality of end station entities:

[0031] - computing, at the centralized network configuration entity, an initial time sensitive network schedule based on initial time sensitive network capabilities obtained at least from the dynamic bridge entity, said initial time sensitive network schedule setting the time of transmission and reception of packets through the network at least from one end station to another end station of the plurality of end stations,

[0032] - performing the following sequence:

[0033] o determining whether to provide the centralized network configuration entity with information about updated time sensitive network capabilities of the dynamic bridge based on at least information related to the last computed time sensitive network schedule,

[0034] o then, if information about updated time sensitive network capabilities of the dynamic bridge is to be provided to the centralized network configuration entity, providing said information to the centralized network configuration entity, at which place the updated time sensitive network schedule is computed based on the provided information about updated time sensitive network capabilities and the sequence is restarted, and

[0035] o if information about updated time sensitive network capabilities is not provided to the centralized network configuration entity, ending the sequence; and

[0036] - determining whether to configure the time sensitive network according to one of the at least one computed time sensitive network schedule or to request an adjustment of at least one flow request considering the configuration of the time sensitive network based on the resulting set of adjusted flow requests based on at least one computed time sensitive network schedule.

[0037] The above sequence is a modification of the established TSN configuration process intelligence selection in the form of a new logical function that enables the intelligent selection of whether new TSN capabilities of dynamic components within the TSN network, such as wireless dynamic bridges, have to be tested. This selection is at least driven by the output of the TSN-CNC scheduler and targets the performance improvement of the TSN network as a whole. In time sensitive networks, dynamic bridge entities are entities that allow communication with multiple end stations and whose TSN capabilities vary depending on the traffic load. For example, a dynamic bridge entity can be configured to adapt its radio resource allocation to best support a given traffic load.

[0038] The implementation of the logical function enabling the intelligent selection is either a standalone node, or integrated within the CNC or the dynamic bridge (DB), or split and partially implemented within both nodes. Depending on the implementation, the logical function has access to basic or more complete knowledge of the CNC and / or DB. This knowledge is gathered, for example, through new interfaces and signaling. The more knowledge is obtained, the more intelligent the selection is.

[0039] The intelligent selection allows for the best discovery configuration of the dynamic bridge (DB) to be applied before proceeding with the usual processing: if the TSN scheduling fails, go back to the CUC and adjust the original flow requests, and if the requirements are met, apply the overall TSN configuration. The above method can be considered in a more general sense as a method for intelligent resource management in an information network comprising dynamic components characterized by having access to a shared limited resource and having at least two different internal configurations associated with different networking capabilities provided due to different repartitioning of said shared resource.

[0040] More details on the different options are provided below.

[0041] The main intended advantage of the present invention is an improved overall performance of a hybrid TSN network comprising at least a dynamic bridge (DB) achieved thanks to the selection of the appropriate internal configuration of said DB.

[0042] An additional advantage achieved thanks to the introduction of a DB configuration loop within the established TSN scheduling process can be a reduction of the time of the scheduling process.

[0043] In one example, processing the set of flow requests comprises:

[0044] - obtaining information related to a selected time sensitive network scheduling, and

[0045] - determining, based on said obtained information, whether to configure the time sensitive network according to the selected computed time sensitive network scheduling or to request adjustment of at least a part of the set of flow requests.

[0046] This allows for configuring the time sensitive network according to the computed TSN scheduling only if the information related to the computed TSN scheduling meets pre-set criteria for the best discovery configuration of the dynamic bridge.

[0047] In one example, the information related to the initial time sensitive network scheduling comprises at least information related to a value of a figure of merit function representing a degree of success of the initial time sensitive network scheduling in meeting at least a part of the set of flow requests.

[0048] In one example, the information related to the at least one computed time sensitive network scheduling comprises a parameter representing a degree of success of said at least one computed time sensitive network scheduling as a whole in responding to the set of flow requests. For example, each parameter can be a single binary success / failure parameter or a single real value parameter representing a "degree of success" of the TSN scheduling process considered as a whole.

[0049] In one example, the information related to the at least one computed time sensitive network schedule comprises a set of parameters, each parameter representing a success degree of the at least one computed time sensitive network schedule in response to a corresponding flow request of the set of flow requests. For example, the parameters can be a set of values (binary or real valued) representing a "success degree" of the schedule per flow.

[0050] In one example, at least part of the information related to the at least one computed time sensitive network schedule is also related to the dynamic bridge entity.

[0051] For example, the obtained information related to the TSN schedule can also include information related to the TSN schedule itself (e.g. gating list, per-flow priority, etc.), such as information generated for at least one port of the DB. As a result, in this example, it is decided whether to provide the information related to the updated time sensitive network capabilities to the CNC based on the information related to the role of the dynamic bridge entity in handling the flows. For example, as mentioned above, in some implementations, obtaining information indicating that at least one flow request is not satisfied can be sufficient to determine that the information related to the updated time sensitive network capabilities should be provided to the CNC. However, in other implementations, additional information related to the TSN schedule itself can also be further obtained. Examples of such additional information can include whether the problematic flow actually passed through the dynamic bridge. Using such additional information, additional logical conditions can be defined. For example, it can be determined that:

[0052] - if the problematic flow passed through the dynamic bridge, the updated time sensitive network capabilities should be provided to the CNC, and

[0053] - on the contrary, if the problematic flow did not pass through the dynamic bridge, the sequence should be ended without providing any further updated time sensitive network capabilities to the CNC.

[0054] The above example allows to configure the time sensitive network according to the computed TSN schedule only if the computed TSN schedule successfully satisfies a sufficient number of requests of the set of flow requests to a sufficient degree, for the best discovery configuration of the dynamic bridge.

[0055] In one example, the method further comprises having computed a plurality of time sensitive network schedules through previous iterations of the sequence, determining whether to provide the information related to the updated time sensitive network capabilities to the centralized network configuration entity also based on a comparison of the number of computed time sensitive network schedules with a predetermined threshold.

[0056] In one example, determining whether to provide the information related to the updated time sensitive network capabilities to the centralized network configuration entity based on the information related to the at least one computed time sensitive network schedule comprises:

[0057] - based on the information relating to the last computed time sensitive network scheduling, retrieving, processing or computing information relating to the overall success of the last computed time sensitive network scheduling, and

[0058] - based on the information relating to the overall success of the last computed time sensitive network scheduling, determining whether to provide information relating to an updated time sensitive network capability to the centralized network configuration entity.

[0059] The retrieved, processed or computed success can be a result of a failure / success of the last computed time sensitive network scheduling. This result is determined and provided by the centralized network configuration entity and can be stored together with the configuration of the dynamic bridge that was tested. Storing such results can be used for long term statistics.

[0060] The retrieved or computed success can comprise more detailed information than a global result of a failure / success. In this case, the same entity can perform the computation of the result of a failure / success and use it immediately as “information relating to the last computed time sensitive network capability” to determine whether to provide information relating to an updated time sensitive network capability to the centralized network configuration entity.

[0061] More generally, the decision not to give out the new TSN capability of the DB can be the result of meeting one of the following criteria.

[0062] One criterion can be that the obtained information relating to the TSN scheduling indicates that the last computed TSN scheduling was successful. One criterion can be that a figure of merit (FoM) result on the information relating to the TSN scheduling is above a predetermined threshold.

[0063] Meeting one of these criteria leads to exiting the TSN scheduling loop as soon as the requirements associated with the set of flow requests are met and allows to start the TSN configuration procedure immediately.

[0064] One criterion can be that a maximum number of new attempted configurations is reached. The effect of this criterion is to set a time limit to the processing time allowed for computing a possible TSN scheduling.

[0065] In one example, the method further comprises, in response to at least one request of the set of flow requests, processing information relating to a success of at least one computed time sensitive network scheduling in meeting the at least one request, and

[0066] based on the information relating to the success of the at least one computed time sensitive network scheduling in meeting the at least one request, determining whether to provide information relating to an updated time sensitive network capability of the dynamic bridge to the centralized network configuration entity.

[0067] For example, the network can comprise a centralized user configuration (CUC) entity and the obtained failure / success information about the TSN schedule can be fed back to the centralized user configuration entity.

[0068] Further, if success is fed back, the centralized user configuration entity can for example validate the set of flow requests.

[0069] Conversely, if overall failure is fed back for the best discovery configuration, the centralized user configuration entity can for example modify the set of flow requests to improve the chances of computing a schedule that allows to reach the sought connectivity.

[0070] In one example, the method further comprises obtaining a predefined set of time sensitive network configurations of the dynamic bridge entity, wherein the initial time sensitive network capability and each subsequent updated time sensitive network capability each correspond to a respective configuration in the predefined set of time sensitive network configurations of the dynamic bridge entity.

[0071] Indeed, the TSN capabilities of the dynamic bridge can be derived from the TSN configurations of the dynamic bridge.

[0072] Considering all possible TSN configurations of the dynamic bridge, how to select a particular updated TSN capability of the dynamic bridge can be performed differently depending on the nature of the available information related to at least the last computed TSN schedule.

[0073] If only a failure indication, a success indication or a global quality factor function related to at least the last computed TSN schedule is obtained from the centralized network configuration entity, the updated TSN capability to be provided to the centralized network configuration entity can be selected from a set of the predefined set of TSN configurations.

[0074] Alternatively, the updated TSN capability to be provided to the centralized network configuration entity can be selected from a random set of the preselected set of TSN configurations. In other words, in one example, the method further comprises, upon determining that information related to an updated time sensitive network capability is to be provided to the centralized network configuration entity, providing information related to a randomly selected internal configuration in the predefined set of internal configurations as the information related to the updated time sensitive network capability. The internal configuration is a configuration stored at least in one or more storage units internal to the dynamic bridge.

[0075] Alternatively, the updated TSN capabilities to be provided to the centralized network configuration entity can be obtained by using an optimization algorithm, e.g. based on a genetic genetic algorithm approach, and using information about already tested dynamic bridge configurations. For example, the first parameter perturbation loop can be based on storing the effects of parameter perturbations and selecting the best TSN configuration from said parameter perturbations as a new starting point for the next parameter perturbation loop. In other words, in one example, the method further comprises, upon determining to provide information about updated time sensitive network capabilities to the centralized network configuration entity, providing information about a configuration selected in a predefined set of time sensitive network configurations based on the results of the optimization algorithm as the information about updated time sensitive network capabilities.

[0076] If more information is obtained from the centralized network configuration entity, such as per flow information or such as non-binary success degrees, several additional possibilities can be used to select the updated TSN capabilities to be provided to the centralized network configuration entity.

[0077] In one example, the optimization algorithm is implemented on an entity configured to:

[0078] - obtain, for a given configuration of a dynamic bridge, information about a success degree of a given time sensitive network schedule in meeting at least one flow request of a set of flow requests,

[0079] - based on the obtained information, predict information about a success degree of a modified time sensitive network schedule to be computed for a given modified configuration of the dynamic bridge in response to at least one request of the set of flow requests, and

[0080] - based on the predicted information, output, as a result of the optimization algorithm, an updated time sensitive network capability corresponding to the given modified configuration of the dynamic bridge.

[0081] As a result, the TSN configuration can be optimized for a single flow or for a predetermined subset of the set of flows in terms of quality of service.

[0082] In one example, the optimization algorithm is implemented on an entity configured to:

[0083] - identify at least one entity within a time sensitive network having a higher contribution to end station to end station delay relative to other entities of said time sensitive network,

[0084] - select at least one flow request of a set of flow requests based on the identified entity,

[0085] - obtain, for a given configuration of a dynamic bridge, information about a success degree of a given time sensitive network schedule in meeting the selected at least one flow request,

[0086] - based on the obtained information, predict information related to the success of a selected at least one request of the set of flow requests in response to the modified time sensitive network schedule that would be computed for the given modified configuration of the dynamic bridge, and

[0087] - based on the predicted information, output the updated time sensitive network capabilities corresponding to the given modified configuration of the dynamic bridge as a result of the optimization algorithm.

[0088] For example, the component within the network that contributes the most locally to the e2e delay of at least one flow can be identified. Then, if the component is served by the dynamic bridge, the corresponding served end station can be identified. The selection of the updated TSN capabilities to be provided to the centralized network configuration entity can take into account a particular improvement of the performance of the dynamic bridge for at least one flow path serving said end station. The improvement of the performance can refer for example to a reduction of the latency within the dynamic bridge.

[0089] For example, if the dynamic bridge is a 5G system, the end station is associated with a user equipment (UE) and the parameters of this UE (resource allocation, handover, quality of service, etc.) can be changed.

[0090] Similarly, the component served by the DB that has the highest contribution to the e2e delay among all flows considered can be identified. Then, the selection of the updated TSN capabilities to be provided to the centralized network configuration entity can take into account a particular improvement of the performance of the dynamic bridge for the flow path served by said component.

[0091] Similarly, the performance of two (or more) components served by the dynamic bridge can be optimized according to the priority computed from the information obtained from the centralized network configuration entity.

[0092] In one example, the step of determining whether to provide information related to updated time sensitive network capabilities to the centralized network configuration entity is performed at the centralized network configuration entity.

[0093] The decision is thus performed by an entity that has full access to the information stored at the centralized network configuration entity. Such stored information can include information related to the computed TSN schedule results (e.g. list of gates for all elements in the network), and / or information related to the network (e.g. topology and TSN capabilities of all static components), and / or the TSN schedule itself, and / or results of the quality function associated with the TSN scheduling process.

[0094] The entity performing the decision also has external links and specific signaling to the dynamic bridge entity to obtain information from the dynamic bridge, such as the set of available configurations of the dynamic bridge or the current configuration parameters.

[0095] In one example, the step of determining whether to provide information related to the updated time sensitive network capabilities to the centralized network configuration entity is performed at the dynamic bridge.

[0096] In this example, the decision is performed by an entity that has full access to the information stored at the dynamic bridge, and thus full access to the possible configurations of the dynamic bridge. This entity also has an external link to the centralized network configuration entity to get information about any computed TSN schedule (e.g. a success / failure indicator or a “degree of success” of the schedule per flow), or information related to the TSN schedule itself (e.g. the list of gates, the priority per flow), or the current configuration parameters of the dynamic bridge.

[0097] In one example, the step of determining whether to provide information related to the updated time sensitive network capabilities to the centralized network configuration entity is performed at a separate entity operatively connected to the dynamic bridge and to the centralized network configuration entity.

[0098] This separate node has both an external link to the centralized network configuration entity and an external link to the dynamic bridge, and can fit neatly into a pre-existing network.

[0099] In one example, the step of determining whether to provide information related to the updated time sensitive network capabilities to the centralized network configuration entity is performed at an entity comprising a first module embedded in the dynamic bridge and a second module embedded in the centralized network configuration entity, the first module being operatively connected to the second module.

[0100] The link between the first module and the second module is an internal link.

[0101] This entity can have full access to the information stored at the centralized network configuration entity and to the information stored at the dynamic bridge, to more accurately predict which TSN configuration of the dynamic bridge should be tested next, and to reduce the number of possible configurations to be tested to find a successful configuration that meets the requirements associated with the set of flow requests.

[0102] A time sensitive network system is also disclosed, the time sensitive network system comprising at least one centralized network configuration entity operatively connected to a plurality of end station entities and to a dynamic bridge entity,

[0103] - the centralized network configuration entity being configured for

[0104] o upon obtaining a set of flow requests from at least a part of the plurality of end station entities and / or obtaining a set of flow requests to at least a part of the plurality of end station entities, computing an initial time sensitive network schedule based on at least the initial time sensitive network capabilities obtained from the dynamic bridge entity, the initial time sensitive network schedule setting times of transmission and reception of packets through the network at least from one end station of the plurality of end stations to another end station of the plurality of end stations;

[0105] o upon obtaining the provided information related to the updated time sensitive network capabilities of the dynamic bridge, computing an updated time sensitive network schedule based on the provided information; and

[0106] o based on the at least one computed time sensitive network schedule, determining whether to configure the time sensitive network according to one of the at least one computed time sensitive network schedule or requesting an adjustment of at least one flow request in view of the obtained adjusted set of flow requests,

[0107] - at least one entity of the time sensitive network system is configured for performing the following sequence:

[0108] o based on at least information related to the last computed time sensitive network schedule, determining whether to provide information related to the updated time sensitive network capabilities of the dynamic bridge to the centralized network configuration entity,

[0109] o then, if the information related to the updated time sensitive network capabilities is to be provided to the centralized network configuration entity, providing said information to the centralized network configuration entity and restarting the sequence, and

[0110] o if the information related to the updated time sensitive network capabilities is not provided to the centralized network configuration entity, ending the sequence.

[0111] It is also disclosed a computer program comprising one or more stored sequences of instructions accessible to a processing unit, and the instruction sequences, when executed by the processing unit, cause the processing unit to perform the above-described method.

[0112] It is also disclosed a processing circuitry, the processing circuitry being equipped with a processing unit operably connected to a memory, the processing circuitry being configured to perform the above-described method. BRIEF DESCRIPTION OF DRAWINGS

[0113] [ Figure 1 ]

[0114] Figure 1 A typical TSN configuration cycle corresponding to a fully centralized model is illustrated.

[0115] [ Figure 2 ]

[0116] Figure 2 a flow chart illustrating a TSN scheduling workflow according to an example of the present disclosure. Figure 1

[0117] [ Figure 3 ]

[0118] Figure 3 a flow chart illustrating an example of suggested modifications to the established TSN configuration procedure.

[0119] [ Figure 4 ]

[0120] Figure 4 a modified workflow illustrating an example of a dynamic bridge configuration loop triggered by a logical function.

[0121] [ Figure 5 ]

[0122] Figure 5 a flow chart illustrating an example of a method considering processing flow requests for configuring a time sensitive network.

[0123] [ Figure 6 ]

[0124] Figure 6 an example of a processing circuit of an entity configured to perform the method of Figure 5 DETAILED DESCRIPTION

[0125] The present disclosure relates generally to a method for processing a set of flow requests considering configuring a TSN network. In the framework of the present disclosure, a TSN network comprises at least two end stations (1), a centralized network configuration entity (CNC) (2) and dynamic components (5), e.g. wireless bridges, e.g. 3GPP / 5G systems (5GS). In one embodiment, the TSN network can further comprise a centralized user configuration (CUC) entity (3), which is an optional node that discovers end stations (ES) and their capabilities and user requirements and configures their latency deterministic TSN features. In return, the CNC discovers the capabilities of the network infrastructure (e.g. bridges) and configures these features.

[0126] Unlike the prior art, which relates to a TSN configuration procedure assuming that all components (= bridges) have a fixed configuration (in the sense that their features can consist in having a fixed TSN capability defined by a single set of TSN parameters (e.g. minimum / maximum latency per port or per port pair)), the objective of the present disclosure is to enable a new generation of so-called dynamic components (= bridges) capable of supporting at least 2 different TSN capabilities.

[0127] ​​Generally, a dynamic bridge can be characterized by the ability to access a shared limited resource (e.g. a wireless medium for data transmission characterized by a limited frequency bandwidth or a memory characterized by a limited capacity) that can be reallocated in favor of one port (or flow) at the cost of reducing the amount of said resource available to other ports (or flows). Such DB can rely on wired or wireless technologies.

[0128] In some embodiments, such dynamic bridge (DB) can represent a wireless network (e.g. 3GPP / 5GS) whose TSN capabilities can vary according to the radio resource allocation (RA) selected by said DB to support requested data traffic with guaranteed quality of service (QoS).

[0129] Other types of dynamic components (wired or wireless) whose features are generally characterized by their ability to support at least two different internal configurations associated with different TSN capabilities can also be envisioned by the skilled person.

[0130] The TSN capabilities of a DB can be described using a set of TSN parameters (e.g. the minimum and maximum values of the independent delay and related delay per port of said DB, and the transmission delay defined for all links connecting said DB with adjacent components). It can also be described for each traffic type supported by the network according to any other information needed to define the deterministic data path, latency and packet delay variation (jitter) per port or per port pair of said DB.

[0131] The TSN capabilities of a DB can be estimated for each internal configuration. It can also depend on the traffic load related to both TSN and non-TSN services supported by said DB. If the bridge TSN capabilities vary based on the configuration of the internal features of the DB, the TSN capabilities are returned according to the current internal configuration of the DB.

[0132] In the following, the term “internal configuration” is used to denote the final configuration of the internal features of a DB that defines its TSN capabilities, described by a set of TSN parameters (e.g. minimum / maximum delay, jitter, bandwidth, etc. per port or per port pair).

[0133] Note that the “internal configuration” is different from the “TSN configuration”, the latter being imposed by the CNC to the DB upon discovery and execution of a successful TSN schedule. Unlike the “internal configuration”, the TSN configuration provided by the CNC includes instructions per port and / or per flow described e.g. according to a gate control list.

[0134] In some embodiments, DB denotes a 3GPP / 5G system (5GS) acting as a wireless bridge, characterized by comprising a core network, at least one base station connected to the core network, and at least two user equipments (UEs) connected to the at least one base station by using wireless communication links, the UEs acting as ingress and egress ports of the wireless bridge. It can also comprise a TSN translator (TT) entity capable of hiding the internal setup of the 5GS from the CNC.

[0135] Such a wireless bridge can be integrated in a wired TSN network intended for, for example, factory automation (FA) use cases. To meet the requirements of such challenging use cases, a centralized configuration model is proposed in IEEE 802.1Qcc, and is characterized by a sequence of steps performed by CUC and CNC entities as shown in Figure 2

[0136] More specifically, in the centralized model, a centralized user configuration (CUC) entity first discovers end stations (ESs), gets ES capabilities and user requirements, and configures TSN features in the end stations. Then, configuration information is provided to a centralized network configuration (CNC) entity, which discovers the physical topology of the network (i.e., components, number of ports per component, length / speed / bandwidth of links between components, etc.), reads TSN capabilities of each bridge (e.g., related delay and independent delay per port and traffic class), and uses this information to generate a per-port and / or per-flow schedule for each component within the TSN domain of the network, aiming at satisfying at least one flow request provided by the CUC.

[0137] If successful, the schedule is used for time-sensitive communication after two additional steps of configuring the ESs and the bridges according to the successful TSN schedule generated by the CNC, performed by the CUC and the CNC, respectively, are completed.

[0138] Alternatively, if the CNC fails to find a schedule satisfying all flow requests provided by the CUC, an additional iteration of the TSN configuration procedure is initiated, which includes a step of adjusting the initial flow requests. This adjustment typically involves relaxing the end-to-end (e2e) delay of at least one flow.

[0139] The centralized model typically assumes that the CNC has a complete view of the physical topology of the network (NW) and of the TSN capabilities of all components within the TSN domain of the network. Under the assumption that all components are static, the steps of reading out the static bridge TSN capabilities and NW discovery can be done only once for each new (or adjusted) flow request provided by the CUC. To save time, these two steps (i.e., discovery and readout) are typically skipped during later iterations, unless the physical topology of the network changes for some purpose. ​

[0140] This established procedure does not provide the CNC with means to obtain information about the configuration of the internal features of the DB that lead to different TSN capabilities. Moreover, it does not provide the CNC with means to test these different internal configurations characterized by different TSN capabilities and find the TSN capability that leads to the most efficient TSN schedule overall.

[0141] These limitations prevent the DB from performing at its best when integrated in a TSN network and thus reduce the TSN network performance overall.

[0142] To overcome these constraints, a new method of configuring a TSN network comprising at least a DB is proposed based on a new logic function (4) that implements control over the DB configuration loop. The logic scheme of the modified TSN configuration procedure is shown in Figure 3 The workflow of the modified TSN configuration procedure is shown in Figure 4

[0143] A new logic function (F1) (4) is introduced to implement control over the DB configuration loop that allows the CNC to perform (27) several TSN schedule attempts associated with different TSN capabilities of the DB and then select the best found configuration of the DB for further execution.

[0144] The logic function is characterized by its ability to obtain information related to the TSN schedule, in particular about the success of the TSN schedule procedure performed by the CNC for different internal configurations of the DB described by different TSN capabilities, and then decide (25) whether to test a new configuration of the DB based on this information.

[0145] In some embodiments, the F1 can be represented by a loop operator (e.g., a Do or Do while loop) that allows the CNC to sequentially read and evaluate all (or at least several) possible TSN capabilities of the DB.

[0146] The exit condition of the DB configuration loop triggered by the F1 can be, for example, a predefined number of iterations or a logical event related to the TSN schedule procedure.

[0147] • The former (i.e., the maximum number of iterations) can be arbitrarily defined or defined with respect to the maximum number of possible TSN capabilities supported by the DB.

[0148] • The latter (i.e., the logical event) can be associated with the value of a figure of merit (FoM) function related to the TSN schedule procedure performed by the CNC.

[0149] In some embodiments, this can be a binary event of success or failure. ​

[0150] Alternatively, this can be the implementation of a threshold associated with the value or the rate of convergence of the FoM function.

[0151] In case of success, the current attempted configuration of the DB can be used for further execution in line with the established workflow. Figure 2

[0152] Alternatively, in case of failure, the logic function F1 can trigger a new iteration of the DB configuration loop, which includes the steps of the CNC reading (26) new TSN capabilities of the DB and re-computing (24) the TSN schedule for at least one flow through the DB.

[0153] As mentioned above, the logic function F1 can use information related to the computed TSN schedule to decide whether to trigger a new iteration of the DB configuration loop or to exit the loop. More details about the information related to the computed TSN schedule are provided below.

[0154] Reference is now made to Figure 5 depicting an exemplary method considering the processing of requests for configuring a TSN network.

[0155] At an initial time, the CNC obtains a set of flow requests OBT REQ (S1) from one or more DBs. The one or more DBs have an initial configuration associated with initial TSN capabilities. The CNC also obtains at the initial time the TSN capabilities of the one or more DBs.

[0156] Upon obtaining the set of flow requests, the CNC computes a CMP INIT (S2) initial TSN schedule based on the initial TSN capabilities of the one or more DBs. The initial TSN schedule is a schedule of transmission / reception times of packets between different end stations in the TSN network.

[0157] Computing the initial TSN schedule also corresponds to initiating an INIT SEQ (S3) sequence or loop guided by the logic function F1 implemented at any entity of the TSN network.

[0158] The first iteration of the sequence or loop includes determining DET PROV (S4) whether to provide the CNC with further TSN capabilities of the one or more DBs, in other words, if the one or more DBs have a different configuration, whether to inform the CNC about potential TSN capabilities of the one or more DBs.

[0159] Determining whether to provide the CNC with further TSN capabilities of the one or more DBs is based on information related to the computed initial TSN schedule.

[0160] ​For example, the loop can be designed to repeat at most a given number of times. In other words, for each iteration of the loop, the count of the computed schedule can be incremented by 1. In this respect, the information related to the computed initial TSN schedule can be the initial value of the count of the computed schedule.

[0161] For example, the loop can be designed to repeat as long as the last tested TSN schedule does not comply with preset requirements associated with the set of flow requests. These requirements can typically involve one or more communication quality indicators, such as indicators of packet loss, latency, jitter, etc. Depending on the information that can be used as input of the entity implementing the logic function Fl, the communication quality indicators can relate to the overall communication between all end stations, or can each relate to a corresponding flow.

[0162] In this respect, the computed initial TSN schedule can be evaluated by the logic function Fl as to the compliance with said preset requirements, the result of the evaluation forming the information related to the computed initial TSN schedule.

[0163] If it is determined that further TSN capabilities should be provided to the CNC, the logic function (Fl) indicates to the CNC to provide PROV UPD (S5) updated TSN capabilities of one or more DBs as to the configuration of the DBs that have not been tested during the previous iteration of the loop.

[0164] Then, based on the updated TSN capabilities, the CNC computes CMP UPD (S6) an updated TSN schedule.

[0165] This computation initiates a subsequent iteration of the loop.

[0166] Each subsequent iteration of the loop comprises determining DET PROV (S4) whether to provide further TSN capabilities of one or more DBs to the CNC based on the information related to the last computed TSN schedule.

[0167] As mentioned above, the loop can be exited based on a criterion related to, for example, the compliance with the requirements associated with the set of flow requests, or based on a criterion related to, for example, the maximum number of DB configurations to be tested.

[0168] In this case, a sequence of determining END SEQ (S7) is determined, without providing any further TSN capabilities of one or more DBs to the CNC.

[0169] Then, the set of flow requests can be processed PROC REQ (S8) according to the computed TSN schedule corresponding to the best discovered configuration of one or more DBs, i.e. the configuration allowing the best quality of service.

[0170] If the best discovery configuration is compliant with the requirements, the CFG TSN (S8a) is configured by the CNC accordingly one or more DBs.

[0171] On the contrary, if none of the tested configurations is compliant with the requirements, the configuration search procedure fails for the set of flow requests that has been used as input. As a consequence, an ADJ REQ (S8b) can be requested to adjust the set of flow requests and repeat the whole procedure.

[0172] Reference will now be made to Figure 6 which depicts an example of a processing circuit implementing the above-mentioned logical function F1. The processing circuit can be incorporated in the CNC, or in a DB, or form a standalone node.

[0173] The processing circuit comprises a processing unit CPU (101) operatively connected to a memory MEM (102) and to one or more communication interfaces COM (103).

[0174] The memory comprises instructions of a program, the instructions comprising one or more stored sequences of instructions accessible to the processing unit, and when executed by the processing unit, cause the processing unit to perform the above-mentioned logical function F1.

[0175] The one or more communication interfaces COM allow the processing circuit to communicate with both the CNC and the one or more DBs.

[0176] Information related to TSN scheduling

[0177] In some embodiments, the information related to TSN scheduling can comprise a single value representative of a binary success / failure figure of merit (FoM) function of the TSN scheduling process as a whole, e.g.

[0178] If all flow requests are satisfied, P = 1, and

[0179] If at least one flow request fails, P = 0. (1)

[0180] Alternatively, the information related to TSN scheduling can comprise a real- valued parameter representative of the degree of success of the TSN scheduling as a whole. For instance, in the case of N flows, it can be defined as

[0181]

[0182] where P n is a per-flow binary function equal to 1 or 0 for success or failure state, respectively.

[0183] According to the definition provided in equation (2), the success criterion for the TSN schedule as a whole can be defined as P = 1, which corresponds to a success status for all N flow requests, while the failure criterion for the TSN schedule as a whole is defined as P < 1, which corresponds to a failure of at least one flow request.

[0184] In another embodiment, the information related to the TSN schedule can comprise a set of values (binary or real values) representing the "success degree" of each flow defined as the ratio between the requested end-to-end (e2e) delay and the delay provided by the TSN schedule, i.e.

[0185]

[0186] where n = 1, 2,..., N is the flow number.

[0187] According to the definition provided in equation (3), the per-flow success criterion and the per-flow failure criterion are defined as P n ≥ 1 and P n < 1, respectively.

[0188] Moreover, the information related to the TSN schedule can also comprise information on the TSN schedule itself (e.g. gating list, per-flow priority, etc.) generated for at least one port of said DB, or at least another component in the path of the flow through said DB, or DB and at least another component within the TSN domain. This supplementary information can be used, for example, to estimate the local contribution of each component to the overall e2e delay of each flow:

[0189]

[0190] where k(n) is the reference number of the component in the path of the n-th flow, and K(n) is the total number of components along the path of the n-th flow, and where D k(n)，n is the total delay incurred by the k(n)-th component in the n-th flow (a component is typically a bridge, which involves a delay independent of the frame length plus a delay depending on the frame length, e.g. the internal "processing", "queuing" and frame length dependent delay associated with the bridge, and the "propagation delay" associated with the link connecting adjacent bridges).

[0191] In general, when k(n) is related to one DB (k(n) = kDB), the delays D kDB,n are interdependent, e.g. they are linked by constraints such as:

[0192]

[0193] where N is the total number of flows through said DB.

[0194] It can thus be understood that the quality factors of all flows flowing through the DB are interdependent, i.e. changing the value of DN affects one D kDB,n value and thereby the quality factor of the nth flow will also change at least another D kDB,n value and thereby the quality factor of the nth flow will also change at least another D

[0195] In the real world, the situation is of course more complex, as different internal configurations of the DB can lead to the same TSN capabilities. At the same time, a change in a single feature in the internal configuration of the DB can affect the TSN capabilities of one port (or pair of ports associated with a flow) or multiple ports.

[0196] However, it is important that, because the shared resource is limited, allocating a larger portion of this resource to one port / flow naturally leads to less resource available for other ports / flows, which makes all ports “interdependent”. Depending on the amount of shared resource, the impact of a single parameter perturbation on other system parameters can be different: the larger the portion of shared resource in use, the stronger impact can be expected.

[0197] Combining the information on the scheduling delays per port and per component with the knowledge of the TSN capabilities of all components, the overall improvement potential in terms of cumulative delays per component and per flow can for example be further estimated as follows:

[0198]

[0199]

[0200] where and are the minimum per-port and / or per-port pair delay and the maximum per-port and / or per-port pair delay associated with the nth flow passing through the kth component.

[0201] Note that a zero improvement potential for a component means that the component works at its best.

[0202] The improvement potential for a component can also take into account per-port information related to multiple flows passing through each port and the cumulative traffic load on each port.

[0203] Finally, the improvement potential can also be estimated for the TSN schedule as a whole, e.g. as a weighted sum of the improvement potentials of all components within the TSN domain of the network.

[0204] Note that the exemplary definition of improvement potential per stream provided in equation (7) is valid for both successful stream requests (characterized by ImprovementPotentialStream(n) e [0,1]) and failed stream requests (characterized by ImprovementPotentialStream(n) < 0 or > 1), and can thus be effectively used in combination with a binary success criterion (e.g. equation (1) or (2)) to distinguish and rank different configurations of DBs that lead to overall failure and overall success of the TSN schedule as a whole.

[0205] Overall success / failure of the TSN scheduling process is obtained or computed

[0206] Depending on the type of information related to the TSN schedule received by the logic function, the overall success / failure information about the TSN schedule can be obtained or computed.

[0207] • For example, in case of a binary FoM function representing the success / failure of the TSN schedule as a whole, e.g. defined by equation (1) or (2), it can be directly obtained from the P value.

[0208] • Alternatively, if only the TSN schedule is available, one can first compute the e2e delay for each stream using equation (4), and then compare it to the e2e delay requested per stream. Finally, one can obtain overall success if Pn > 1 for all n.

[0209] In one embodiment, the results of all attempts (performed for different TSN capabilities of the DB) can be stored and later used to find the best DB configuration among the tested DB configurations. Then, the overall success / failure criterion of the TSN scheduling process can be obtained or computed for at least the best tested DB configuration as described above. If the best tested DB configuration is considered good enough (e.g. leads to overall success of the TSN schedule as a whole), this best DB configuration is used for further execution. Alternatively, if none of the tested DB configurations can simultaneously satisfy all stream requests, it is considered as a failure of the TSN schedule as a whole. According to the established workflow [2], in this case the CNC returns a failure status to the CUC, which can decide to adjust the stream requirements and start a new iteration of the TSN scheduling process.

[0210] In one embodiment, it can be beneficial to provide the network with at least one centralized user configuration (CUC) entity capable of discovering end stations (ESs), acquiring ES capabilities and user requirements, and configuring TSN features in said end stations. Said CUC can also receive acquired (or computed) success / failure information from the logical function and, depending on the received information, decide whether to configure the end stations to use the successful schedule generated by the CNC or to adjust the flow requests and start a new iteration of the TSN configuration procedure (see Figure 4 ).

[0211] In one embodiment, the intelligence of the logical function Fl can be further improved by collecting information related to the TSN schedule and using this information to guide the selection process.

[0212] In particular, instead of a single value of the FoM function describing the success of the scheduling procedure as a whole, said information related to the TSN schedule can include a set of values (binary or real-valued) representing the “degree of success” of the schedule for each flow. Moreover, when generating a TSN schedule for at least one port of said DB, information related to the TSN schedule itself can be included (e.g. per-port gating list, per-flow priority, etc.). Fl can use this additional information to select the next attempted configuration of said DB and / or to compute the success / failure status of at least one DB configuration (e.g. the best or last one among the tested DB configurations).

[0213] Implementation examples of definitions of binary and real-valued FoM functions describing the degree of success of the TSN scheduling procedure are provided in the previous part of this document.

[0214] Exit conditions for the DB configuration loop

[0215] Depending on the selected embodiment, different exit criteria can be used for the DB configuration loop controlled by Fl.

[0216] In one embodiment, the exit criterion can be defined in terms of a maximum number of iterations of the DB configuration loop. When the exit criterion is reached, Fl acquires or computes the success / failure criterion of the TSN scheduling procedure for at least one of the tested configurations and informs the CUC accordingly. This embodiment can beneficially rely on storing all (or at least the best) DB configurations.

[0217] Alternatively, the exit criterion can be defined based on a logical condition.

[0218] In one embodiment, if the obtained information related to the TSN schedule indicates an overall success of the TSN scheduling procedure, Fl can decide not to provide the CUC with a new TSN capability for the DB. In this case, the current attempted DB configuration can be considered a good enough configuration and used for further execution.

[0219] For example, if the information related to the TSN schedule only comprises a binary value of the FoM function defined by equation (1) or (2), the exit condition can be defined as P = 1.

[0220] In another embodiment, the exit criterion can be defined with respect to a real value of a figure of merit (FoM) function describing the “success degree” of the TSN scheduling process as a whole or per flow.

[0221] For example, if a stagnation of improvement of the FoM function is observed for a given number of unsuccessful iterations leading to an overall failure, Fl can make the decision not to provide the new TSN capabilities of the DB to the CNC, e.g.

[0222]

[0223] where P() is the FoM function defined by equation (2), i is the iteration number, M is an arbitrary number of past iterations considered, and δ p is an arbitrary threshold parameter related to a rate of convergence defined in terms of the relative improvement of P() during M iterations.

[0224] Alternatively, based on a stagnation criterion associated with the rate of improvement of the TSN schedule defined in terms of the latency or in terms of the relative improvement of the FoM, Fl can also make the decision not to provide the new TSN capabilities of the DB to the CNC after a series of successful attempts.

[0225] Moreover, the figure of merit and the stagnation criterion can be defined not in terms of TSN performance indicators (e.g., e2e latency) but in terms of a quality of service (QoS) related to the application using the time-aware communication with the TSN schedule. For example, if the application is related to a video stream, the QoS can be associated with the frame rate or resolution of the video. In the context of factory automation (FA), the QoS can be associated with the reaction time of a robot motion control.

[0226] In one embodiment, the comparison and ranking of successful DB configurations (e.g., characterized by P = 1 in equation (2)) can be made based on the improvement potential determined for at least one component (equation (5)) or one flow (equation (6)), respectively. In this case, a stagnation criterion for the improvement of the TSN schedule can be defined in terms of an iteration reduction of the improvement potential of the TSN schedule during a given number of iterations:

[0227]

[0228] where I() is the improvement potential of the component (eq. (6)) or of the flow (eq. (7)) or of the TSN schedule as a whole defined as the sum of the improvement potential of all components, i is the iteration number, M is any iteration number considered, and δ i is an arbitrary threshold parameter related to the convergence rate of the improvement potential defined in terms of the relative improvement of I() during the last M iterations.

[0229] When / if the threshold exit condition is met, F1 retrieves (or computes) the overall success / failure status of the TSN scheduling procedure for at least one tested internal configuration (e.g. the best or last one) and notifies CUC accordingly.

[0230] As above, this embodiment can also be provided with a device that stores information related to all tested DB configurations (or at least the best or last one) and uses this information, for example, to compute the impact of DB parameter perturbations on the evolution of the FoM function.

[0231] In turn, the correlation between the perturbation of TSN parameters (describing the different TSN capabilities of the DB) and the FoM function describing the success of the TSN scheduling procedure allows to implement an optimization routine aiming at continuous improvement of the quality of the TSN schedule as a whole by intelligently selecting each next attempted internal configuration of the DB from several possible configurations. Said improvement can be characterized, for example, in terms of the ratio of successful flows to the total number of requested flows as described by eq. (2).

[0232] Alternatively, the e2e latency reduction can be described in terms of the maximum value of the flow n characterized by eq. (3).

[0233] In one embodiment, a simple gradient-type optimization method can be implemented by iteratively tuning at least one TSN parameter and observing the impact of the parameter variation on the value of the FoM function associated with the success of the TSN scheduling procedure (e.g. as defined by eq. 2) and / or the improvement potential of the DB or of the TSN schedule as a whole.

[0234] This embodiment can also be enhanced with different methods for selecting the initial guess (e.g. based on random selection or maximum or minimum value of each control parameter), intelligent selection of the search direction (e.g. based on partial derivatives of the multi-parameter FoM function) and adaptive step size (e.g. based on the FoM gradient).

[0235] Alternatively, the optimization process can be based on a global (e.g. genetic) optimization method featuring a quasi-random perturbation of the TSN parameters describing the DB, estimating the impact of the perturbation and using one of the previously tested configurations as a new starting point for the next parameter perturbation cycle.

[0236] A simple illustrative example is provided below.

[0237] Let us consider an index kDB associated to a unique DB in the system. We assume that this DB is intrinsically defined by a base station sharing resources among several terminals. We determine the delay of one terminal n as where L n is the payload of information to be transmitted for the nth flow, F n (α n ) is the data rate function related to the pair of terminals associated to the nth flow when a fraction of resources α n is allocated. Here we assume that if no flow in the cell is linked to a terminal, no resources are allocated to this terminal. Assuming that the transmission resources are fully used and shared among several terminals, we can set the inter-flow constraint for example to ∑α n = 1. Then, the optimization problem is for example written as a search for the internal configuration of the DB aiming at reducing the e2e delay at least for the flows characterized by the largest e2e delay:

[0238]

[0239]

[0240] ∑α n = 1 (10)

[0241] When real values can be used to allocate resources, optimization theory such as gradient descent can be used to solve the optimization problem.

[0242] When resources are split into elementary blocks, this is a combinatorial optimization problem that can be solved using for example genetic algorithms.

[0243] Of course, cellular systems are more complex because:

[0244] • the rate of one terminal is not only a function of the amount of allocated resources but also of which resources in time and frequency are allocated (as a basic feature of OFDM transmission over a wireless channel),

[0245] • there can be several base stations in one DB, which involves that each terminal has to be attached to one of said base stations. This attachment parameter is tunable and impacts the delay because the number of terminals per cell, the link quality to the attached base station, the inter-cell interference impact the radio link quality and thus the transmission rate and transmission delay.

[0246] From this simple example, we understand how the DB creates the delay of the stream and the inter-dependence between the delays of the streams, and the specific optimizations involving the TSN network.

[0247] F1 makes a positive decision to provide the CNC with the new TSN capabilities of the DB

[0248] In case F1 makes a positive decision about the necessity of testing the new TSN capabilities of the DB, there are several options that can be used to select among the possible capabilities the new one to be tested.

[0249] In some embodiments, the new TSN capability of the DB can be chosen arbitrarily or randomly by F1 among the possible TSN capabilities of the DB. Alternatively, all the possible TSN capabilities of the DB can be tested sequentially. Both embodiments require F1 to be able to obtain information about the different TSN capabilities supported by the DB, characterized by different sets of TSN parameters (e.g. minimum and maximum values of the relevant delay and independent delay per port). Different sets can differ by at least one value of a TSN parameter.

[0250] The following illustrative example details possible ways of selecting the specific TSN capability to be tested.

[0251] The selection of the new attempted TSN capability by F1 can be done using reference numbers (assuming the presence of a standard interface between F1 and DB that allows matching the reference numbers with the unique set of TSN parameters of the DB) or using the full set of TSN parameters. In one embodiment, F1 can provide the set of TSN parameters to the DB and the DB applies only these parameters.

[0252] In one embodiment, it can be beneficial to sample the range of variation of each TSN parameter with a given number of samples (e.g. 2s samples, where s is an arbitrary integer).

[0253] The advantage of this approach is that it does not require knowledge of the absolute values of the range of variation of each TSN parameter. Instead, it only requires the value of the parameter s and the sampling method (e.g. a regular grid based on uniformity). Both parameters can be defined by a specification or arbitrarily chosen by the CNC or F1 or DB. Regardless of the sampling method, the total number of possible parameter combinations (encoding the different TSN capabilities of the DB) can be defined as

[0254]

[0255] where N param is the total number of TSN parameters per port, and N portis the total number of ports of the DB. The former is usually known from the specification, while the latter is read by the CNC during the network discovery step.

[0256] In one embodiment, it can be beneficial to pre-select a given number of TSN capabilities. For example, a pre-selected set of capabilities (i.e. a shortlist) can include a given number of configurations that are considered representative examples of a larger set of all possible configurations. For example, this can be a set of TSN capabilities that prioritize different ports or different pairs of ports for different flows of service. This set of TSN capabilities can also be complemented with a configuration that provides equal TSN capabilities to all ports of the DB.

[0257] In yet another embodiment, such a pre-selected set of TSN capabilities of the DB can include the most promising configurations selected by Fl according to a standard (e.g. leading to a higher degree of success of the TSN scheduling process of the network as a whole, e.g. using Equation (2) with the FoM obtained using a software model of the DB and / or CNC entities that allows to establish a correlation between the TSN capabilities of the DB and the degree of success of the TSN scheduling process). n The corresponding values of the FoM (representing the per-flow success / failure status) are estimated). Such a software model can represent a reduced version of the CNC that is able to provide at least a rough estimate of the FoM function for a given TSN capability of the DB.

[0258] Finally, in addition to random and forced methods of selecting a new trial configuration among a pre-selected set of configurations or among all possible configurations, it is possible to implement a more intelligent process based on local (e.g. gradient) or global (e.g. genetic) optimization methods, which are typically characterized by:

[0259] - selecting a first trial TSN capability of the DB (characterized by a set of TSN parameters) and obtaining information about the degree of success of the TSN scheduling process (characterized by a FoM function) from the CNC after the TSN scheduling process has been executed or from a software model,

[0260] - selecting a second trial configuration (characterized by another set of TSN parameters, differing from the first set of parameters by at least one parameter value) and obtaining information about the degree of success of the TSN scheduling process for said second configuration (characterized by a FoM function),

[0261] - evaluating the effect of the variation of said at least one parameter on the FoM function, and

[0262] - using at least one of said first and second configurations as a starting point for the next parameter perturbation cycle.

[0263] Implementation of the logical function

[0264] There are several options available for the implementation of the logic function.

[0265] For example, the logic function can be implemented as a standalone node between the CNC and the DB, embedded in the CNC, embedded in the DB or split between the CNC and the DB.

[0266] Regardless of the implementation chosen, it is assumed that the logic function has internal links to the host entity (e.g. to the CNC if implemented in the CNC) which allow full access to the information related to the host entity. It is also assumed that the logic function has external links to another entity different from the host entity, which are used to obtain (part or all of) the information related to the other entity through specific interfaces or signaling.

[0267] In case the logic function is implemented as a standalone node between the CNC and the DB, it should have external links to both entities.

[0268] Conversely, if the logic function is split between the CNC and the DB, it can have internal links to both entities and between the sub-blocks of the logic function (i.e. F1-CNC embedded in the CNC and F1-DB embedded in the DB).

[0269] The information related to the CNC that can be accessed by the F1, fully (in case of internal links) or at least partially (in case of external links), includes:

[0270] - information related to the TSN scheduling, including: information related to the FoM functions and the scheduling itself for the DB and for all the other components within the TSN domain of the network,

[0271] - information related to the flow requests, including end-station TSN capabilities, flow requests, per-flow e2e latency and deadlines, etc.

[0272] - information related to the network, including TSN capabilities of all the static components and NW physical topology,

[0273] - information related to the software model of the CNC, allowing to estimate the degree of success of the TSN scheduling process for a given TSN capability of the DB.

[0274] The information related to the DB that can be accessed by the F1, fully (in case of internal links) or at least partially (in case of external links), includes:

[0275] - information related to the topology of the DB, e.g. number of ports and links to neighboring components,

[0276] - information related to the TSN capabilities of the DB,

[0277] - information related to the current configuration of the DB,

[0278] - information related to the software model of the DN, allowing to predict the impact of a parameter perturbation on its TSN capabilities.

Claims

1. A method of considering a set of processing flow requests for configuring a time sensitive network, said time sensitive network comprising at least a centralized network configuration entity operatively connected to a plurality of end station entities and to a dynamic network bridge entity, The method comprises the following steps: - upon obtaining a set of flow requests from at least a part of said plurality of end station entities and / or upon obtaining a set of flow requests to at least a part of said plurality of end station entities: - at said centralized network configuration entity, computing an initial time sensitive network schedule based on at least an initial time sensitive network capability obtained from said dynamic network bridge entity, said initial time sensitive network schedule setting times of transmission and reception of packets through said network at least from one end station of said plurality of end stations to another end station, - performing the following sequence: o determining whether to provide to said centralized network configuration entity information related to an updated time sensitive network capability of said dynamic network bridge based on at least information related to a last computed time sensitive network schedule, o then, if said information related to said updated time sensitive network capability of said dynamic network bridge is to be provided to said centralized network configuration entity, providing said information to said centralized network configuration entity, at which an updated time sensitive network schedule is computed based on said provided information related to said updated time sensitive network capability and said sequence is restarted, and o if said information related to said updated time sensitive network capability is not to be provided to said centralized network configuration entity, ending said sequence; and - determining whether to configure said time sensitive network according to one of said at least one computed time sensitive network schedule or to request an adjustment of at least one flow request considering configuring said time sensitive network based on a resulting adjusted set of flow requests based on at least one computed time sensitive network schedule, said method being characterized in that: - said information related to at least one computed time sensitive network schedule comprises at least information related to a value of a figure of merit function representative of a degree of success of said at least one computed time sensitive network schedule in satisfying at least a part of said set of flow requests, and / or - a plurality of time sensitive network schedules have been computed through previous iterations of said sequence, said step of determining whether to provide to said centralized network configuration entity information related to an updated time sensitive network capability being further based on a comparison of a number of computed time sensitive network schedules with a predetermined threshold, and / or - said method further comprises a step of processing information related to a degree of success of at least one computed time sensitive network schedule in satisfying at least one request of said set of flow requests in response to said at least one request and said step of determining whether to provide to said centralized network configuration entity information related to an updated time sensitive network capability of said dynamic network bridge is based on said information related to a degree of success of said at least one computed time sensitive network schedule in satisfying said at least one request.

2. The method of claim 1, wherein, At least one part of the information related to at least one computed time-sensitive network schedule is also related to the dynamic network bridge entity.

3. The method of claim 1 or 2, further comprising the step of: In determining to provide information related to an updated time-sensitive network capability to the centralized network configuration entity, the information related to a randomly selected internal configuration in a predefined set of internal configurations is provided as the information related to the updated time-sensitive network capability.

4. The method of any one of claims 1 to 3, further comprising the step of: obtaining a set of predefined time-sensitive network configurations of the dynamic network bridge entity, wherein the initial time-sensitive network capability and each subsequent updated time-sensitive network capability each correspond to a respective configuration in the set of predefined time-sensitive network configurations of the dynamic network bridge entity.

5. The method of any one of claims 1 to 4, wherein, The step of determining whether to provide information related to an updated time-sensitive network capability to the centralized network configuration entity is performed at the centralized network configuration entity.

6. The method of any one of claims 1 to 5, wherein, The step of determining whether to provide information related to an updated time-sensitive network capability to the centralized network configuration entity is performed at the dynamic network bridge.

7. The method of any one of claims 1 to 6, wherein, The step of determining whether to provide information related to an updated time-sensitive network capability to the centralized network configuration entity is performed at a separate entity operably connected to the dynamic network bridge and the centralized network configuration entity.

8. The method of any one of claims 1 to 7, wherein, The step of determining whether to provide information related to an updated time-sensitive network capability to the centralized network configuration entity is performed at an entity comprising a first module embedded in the dynamic network bridge and a second module embedded in the centralized network configuration entity, the first module being operably connected to the second module.

9. The method of any one of claims 1 to 8, wherein, The step of determining whether to provide information related to an updated time-sensitive network capability to the centralized network configuration entity based on at least information related to a last computed time-sensitive network schedule comprises the steps of: - obtaining or computing an overall success of the last computed time-sensitive network schedule based on at least information related to the last computed time-sensitive network schedule, and - determining whether to provide information related to an updated time-sensitive network capability to the centralized network configuration entity based on the obtained or computed overall success of the last computed time-sensitive network.

10. A time-sensitive network system, the time-sensitive network system comprising at least one centralized network configuration entity operably connected to a plurality of end station entities and a dynamic network bridge entity, - the centralized network configuration entity being configured for: o computing an initial time-sensitive network schedule based on at least an initial time-sensitive network capability obtained from the dynamic network bridge entity upon obtaining a set of flow requests from and / or to at least a part of the plurality of end station entities, the initial time-sensitive network schedule setting times of transmission and reception of packets through the network at least from one end station to another end station in the plurality of end stations; o computing an updated time-sensitive network schedule based on the provided information upon obtaining provided information related to an updated time-sensitive network capability of the dynamic network bridge; and o determining, based on the at least one computed time-sensitive network schedule, whether to configure the time-sensitive network according to one of the at least one computed time-sensitive network schedule or requesting an adjustment of at least one flow request taking into account configuring the time-sensitive network based on the resulting adjusted set of flow requests, - the at least one entity of the time-sensitive network system being configured to perform the following sequence: o determining, based on information related to at least the last computed time-sensitive network schedule, whether to provide the centralized network configuration entity with information related to the updated time-sensitive network capabilities of the dynamic bridge, o then, if the information related to the updated time-sensitive network capabilities is to be provided to the centralized network configuration entity, providing the information to the centralized network configuration entity and restarting the sequence, and o if the information related to the updated time-sensitive network capabilities is not to be provided to the centralized network configuration entity, ending the sequence, - the time-sensitive network system being characterized in that: - the information related to at least one computed time-sensitive network schedule comprises at least information related to a value of a figure of merit function representing a degree of success of the at least one computed time-sensitive network schedule in satisfying at least a portion of the set of flow requests, and / or - a plurality of time-sensitive network schedules has been computed through previous iterations of the sequence, determining whether to provide the centralized network configuration entity with information related to the updated time-sensitive network capabilities is further based on a comparison of the number of computed time-sensitive network schedules with a predetermined threshold, and / or - the centralized network configuration entity is further configured to, in response to at least one request of the set of flow requests, process information related to a degree of success of at least one computed time-sensitive network schedule in satisfying the at least one request, and determining whether to provide the centralized network configuration entity with information related to the updated time-sensitive network capabilities of the dynamic bridge is based on the information related to the degree of success of the at least one computed time-sensitive network schedule in satisfying the at least one request.

11. A computer program comprising one or more stored sequences of instructions accessible to a processing unit and which, when executed by the processing unit, cause the processing unit to carry out the method according to any one of claims 1 to 9.

12. A processing circuitry, the processing circuitry being equipped with a processing unit operably connected to a memory, the processing circuitry being configured to carry out the method according to any one of claims 1 to 9.

Images