WO2023104724A1 - Procédé d'émission d'un flux de données dans un réseau de communications, procédé de traitement d'un flux de données, procédé de contrôle du traitement d'un flux de données, dispositifs, équipement terminal, entité d'exécution, entité de contrôle, système et programmes d'ordinateur correspondants. - Google Patents

Procédé d'émission d'un flux de données dans un réseau de communications, procédé de traitement d'un flux de données, procédé de contrôle du traitement d'un flux de données, dispositifs, équipement terminal, entité d'exécution, entité de contrôle, système et programmes d'ordinateur correspondants. Download PDF

Info

Publication number
WO2023104724A1
WO2023104724A1 PCT/EP2022/084438 EP2022084438W WO2023104724A1 WO 2023104724 A1 WO2023104724 A1 WO 2023104724A1 EP 2022084438 W EP2022084438 W EP 2022084438W WO 2023104724 A1 WO2023104724 A1 WO 2023104724A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
data stream
processing
network slice
data
Prior art date
Application number
PCT/EP2022/084438
Other languages
English (en)
Inventor
Nicolas Bihannic
Pierre-Alexandre MASSON
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2023104724A1 publication Critical patent/WO2023104724A1/fr

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/64Routing or path finding of packets in data switching networks using an overlay routing layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/74Admission control; Resource allocation measures in reaction to resource unavailability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/74Admission control; Resource allocation measures in reaction to resource unavailability
    • H04L47/748Negotiation of resources, e.g. modification of a request
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/76Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/78Architectures of resource allocation
    • H04L47/783Distributed allocation of resources, e.g. bandwidth brokers
    • H04L47/787Bandwidth trade among domains

Definitions

  • the invention lies in the field of telecommunications, and in particular in that of communications networks structured in network slices.
  • the invention relates to the transmission, processing and control of the data streams routed in such a network slice.
  • the digitization of industrial processes contributes to diversifying the nature of the data that passes through an operator's networks.
  • the Internet of Things IoT
  • IoT Internet of Things
  • new services such as predictive maintenance with the aim of seeking operational efficiency.
  • These new services are not necessarily real-time but are becoming more and more important for a customer.
  • augmented technician which allows a technician to visualize various data allowing him to enrich the context of an intervention scene. This is, for example, a history of the interventions made on a selected industrial part, or even a process for handling the selected industrial part.
  • This technician also has the possibility of benefiting from voice assistance with a remote expert.
  • a business application called "digital twin” which allows the feedback of operating information measured by connected sensors to a customer information system in order to build a so-called virtual representation of the execution environment of these sensors. .
  • This business application also allows a user located near these sensors to have voice assistance with a remote expert in the event of a malfunction or need to reconfigure one or more of these sensors.
  • Each of these applications described by way of example generally implements data flows of different natures which are not necessarily real-time but are becoming increasingly important for the customer and for the service providers.
  • non-real-time services such as professional application updates, entertainment and gaming applications for the consumer market, or mapping for the connected car sector.
  • Network slicing technology notably introduced in the 5G specifications, is promising for the implementation of specialized networks and the differentiated routing of application data, in particular for the support of IoT services which have varied requirements in terms of throughput, availability, or energy consumption.
  • a network slice is a Software-Defined Network subnet whose operation is specifically configured to meet the needs of a customer and/or endpoint and/or of an application, and in particular to implement new services. This technology therefore makes it possible in particular to meet the specific needs of the operator's various customers by reserving one or more sections of its communications network for each of them.
  • a network slice consists of physical and/or virtual PNF/VNF (Physical Network Functions/Virtual Network Functions) network functions that are interconnected and can belong to the access part and/or to the core part of the communications network.
  • the synthesis of a network slice therefore serves a particular functional purpose and, once instantiated, it is used to support certain communication services for a so-called "vertical" dedicated client (e.g. a company, a service offer, etc. ) by providing it with a given quality of service guarantee.
  • Each network slice can have its own architecture, its own management of FCAPS operations (for “Fault-management, Configuration, Accounting, Performance, and Security”, in English ) and its own security corresponding to a particular use case.
  • the state of the art in the network slice specification allows a network slice to be selected for a given client application, according to a mechanism implemented via the URSP rules for “ User Equipment Route Selection Policies ” defined in the specifications [ 3GPP TS 24.526] and [3GPP TS 23.503].
  • Several attributes can be used to direct data flows (or " data flow ") from a given client application to the corresponding network slice: - the identifier of the application " Application ID ", the FQDN ( Fully Qualified Domain Name ), the triplet " IP address, port number, protocol ID ", the DNN ( Data Network Name ).
  • an API_TA augmented technician application implements three data streams of different natures, including: a type of voice over IP or VoIP data stream STR_1 (Voice over IP); - a type of stream STR_2 of video streaming data; - a type of enriched data stream STR_3.
  • an API_JN digital twin application implements two streams of different natures, including: - a type of stream STR_1' of voice over IP or VoIP data; - a type of sensor data stream STR_2'.
  • the referral mechanism via URSP rules is essentially static. It does not make it possible to dynamically configure, nor to control a routing priority of a data stream compared to another data stream of the same client application whose data streams are routed in a specific network slice. However, we understand that the customer would like to be able to dynamically associate different priorities with these different streams so that STR_1 type streams are processed with high priority and routed in real time, STR_2 type streams are routed with a standard priority and data streams of type STR_3 are routed with low priority.
  • the routing of data packets in a network slice must meet several criteria, including: - a resource criterion which specifies whether the throughput must be guaranteed, - a priority level criterion which specifies the priority level of the packet, - a transfer delay criterion (“Packet Delay Budget”) which specifies the authorized end-to-end transfer delay (including the radio and core network segments), - an error rate criterion (from English, “Packet Error Rate”) which specifies the error rate in the transmission of the packet, - an average window criterion (from English, “Averaging window”) which specifies the duration of maintenance in memory of the packet at the level of a device of the network transfer plan, a criterion of maximum volume of burst data volume (“Maximum Data Burst Volume”) which characterizes the nature of the data volume.
  • a resource criterion which specifies whether the throughput must be guaranteed
  • - a priority level criterion which specifies the priority level of the packet
  • the data packet priority criterion of the 5QI indicator is configured to take about twenty fixed values associated with standardized packet types, for example, a conversational voice type packet. or a conversational video type packet.
  • a drawback of this mechanism for prioritizing data packets in a network slice is that it cannot be adapted to the specific needs of a customer who would like to dynamically define his own priority levels for his own types of flow of data according to the targeted application and possibly changing their respective priority levels according to the real situation (nominal or alarm for example).
  • the invention improves the situation.
  • the invention meets this need by proposing a method for transmitting a data stream received from a software application running on a terminal equipment, in a communications network to which said terminal equipment is connected, said network being cut into a plurality of network slices, characterized in that said method is implemented at said terminal equipment and comprises - the selection of a network slice of said plurality at least according to information included in a header of the data stream, - obtaining a type of said flow, said type belonging to a group comprising at least a first type and a second type of flow, and - the insertion of a priority indicator associated with the type of stream in the data stream, the priority indicator belonging to a group comprising at least a first indicator associated with the first type of stream and a second indicator associated with the second type flow, the first indicator and the second priority indicator having distinct values; - the transmission of the data stream comprising the priority indicator in the selected network slot.
  • the invention is based on an entirely new and inventive approach which consists of inserting a priority indicator in a data stream sent by an application of a client eligible to be routed via a given network slice.
  • This priority indicator is for example inserted in a header or in the useful part of the data stream. It is intended to be detected by one or more network entities in charge of processing the routing of the data flow in the network slice and to be used to decide how to process the data flow according to the available network resources and in particular whether or not it can be routed through the selected network slice.
  • it is thus possible to prioritize the data streams sent by a software application running on the terminal equipment in a particular network slice. This network slice may or may not be dedicated to the software application.
  • the network slice can be dedicated to this application or to several applications of this client or to all the flows sent by this client in general.
  • the invention then allows the customer to assign the desired level of priority to each of the types of application flows implemented in his software application(s).
  • software application we mean here a business application associated for example with a client, this business application comprising different flows (voice, data, streaming, management, etc.) requiring different priorities according to their needs.
  • the software application is configured to implement a specific service from an operator, such as the "Voice over IP" service
  • the network slice in question can be reserved for routing the flows of the Voice application over IP transmitted by this software application, regardless of the terminal equipment or the client using this terminal equipment.
  • the operator advantageously configures different types of Voice over IP streams, for example according to a level of quality of service to which each customer has access in connection with the subscription to which he has subscribed.
  • the software application is an application, for example of the VoIP type, and the priorities are associated, for example, with customers having, for example, separate contracts and therefore different priorities for the Voice over IP software application. .
  • parameters of the data stream header can be used separately or in combination, including an identifier of the software application, such as the identifier of the protocol used (for example the RTP protocol – Real Time Protocol), the sender's IP address or even the recipient's IP address.
  • an identifier of the software application such as the identifier of the protocol used (for example the RTP protocol – Real Time Protocol), the sender's IP address or even the recipient's IP address.
  • the network slice can be configured by the operator to group the data streams sent by the software applications of several distinct customers, which for example have common requirements in terms of availability or isolation of the data streams, etc.
  • the operator can define several types of data streams and values of priority indicators associated in common to all the customers who share the network slice.
  • Another advantage of the invention is that it makes it possible to select the network slice to be used for a data flow at the level of the terminal equipment, rather than at the level of an equipment of the communications network itself. The load is thus moved from the network to the terminal.
  • this selection is simpler to implement and better meets scalability constraints. "). Indeed, thanks to the implementation of network slices on the terminals, it is possible to associate data flows from the terminal to distinct slices, which is more difficult to implement when the network slice is instantiated on operator network equipment where the flows are more numerous and also potentially encrypted, making it impossible to use header data.
  • the customer owning the terminal can manage the slices himself, whereas he will not have the possibility during instantiation on network equipment, as may be the case when implementing the private network.
  • Virtual Private Network the network slice architecture also offering greater flow isolation capabilities than virtual private networks in particular.
  • the method further comprises: - the prior reception of at least one routing rule for a data stream transmitted by said software application, said rule comprising at least one identifier of said software application, said type of stream, said priority indicator associated with said type of flow and an identifier of a said network slice; - the storage in memory of said at least one routing rule and - the application of said at least one routing rule during the implementation of said selection and said insertion.
  • this prioritization of the data streams transmitted by the software application is implemented by the prior installation of rules defining the value of the priority indicator to be inserted into the data stream in addition to the network slice to be used. .
  • the network slice is identified by an S-NSSAI parameter. It is noted that the 5G mobile access network keeps a context of the network slices for which the terminal has previously registered and that it is not necessary to insert this information field in a header of the flow of data.
  • the software application is a customer application
  • the customer can define its own stream types and the priority flag values it associates with each of them.
  • the software application implements an operator service, such as a voice over IP service, then it is the operator who defines the types of data streams, for example by customer type or level. subscription and associates them with a priority indicator value.
  • the method further comprises obtaining an operating mode of said software application, said operating mode belonging to a group comprising at least a first operating mode and a second operating mode, and said at at least one routing rule is associated with said operating mode.
  • An advantage is that the rules for prioritizing data flows relative to each other can be modified according to a current operating mode of the application.
  • these operating modes are previously defined by the customer and include at least a first so-called “nominal” mode and a second so-called “alarm” mode and specific processing rules for the data streams are associated with each of these modes. They can also include a third "Priorized Reporting" type mode which, unlike the alarm mode, can be scheduled, or even recurring over a given time slot. Such a procedure can be advantageously implemented in all sectors of activity for monitoring operational performance.
  • a data stream of type "sensor data” is associated with a minimum to average value of the "nominal” operating mode priority indicator, but a maximum value of the priority indicator in “alarm” mode of operation.
  • this sensor data is useful to manage a crisis and must be received in real time with maximum priority in the "alarm” mode.
  • a current operating mode for example corresponding to a nominal situation, can be defined beforehand at the level of the user's terminal which will apply the routing rules associated with this operating mode, but that it can be modified over time by notification of a client entity connected to the network.
  • the user's terminal Upon receipt of a notification of a change in the operating mode, for example switching to an alarm-type operating mode, the user's terminal will apply the routing rules associated with this new operating mode for future data flows. data transmitted by the software application in the network slice.
  • the invention also relates to a device for transmitting a data stream by a software application running on a terminal equipment, in a communications network to which said terminal is connected, said network being divided into a plurality of network slices .
  • Said device is configured to implement at the level of the terminal equipment: - the selection of a network slice of said plurality at least according to information included in a header of the data stream; - obtaining a type of said flow, said type belonging to a group comprising at least a first type and a second type of flow), and - the insertion of a priority indicator associated with the type of stream in the data stream, the priority indicator belonging to a group comprising at least a first indicator associated with the first type of stream and a second indicator associated with the second type flow, the first indicator and the second priority indicator having distinct values; And the transmission of the data stream comprising said priority indicator, in the selected network slot.
  • said device configured to implement the steps of the transmission method as described previously.
  • said device is integrated into terminal equipment connected to the communications network, such as a user terminal or a connected object.
  • said terminal equipment is included in a data flow control system routed in a communications network.
  • the system, the terminal equipment and the transmission device have at least the same advantages as those conferred by the aforementioned transmission method.
  • the invention also relates to a method for processing a data stream in a communications network, said network being divided into a plurality of network slices, said data stream having been received in a said network slice of said plurality coming from a software application running on a terminal equipment connected to said network.
  • Said method is implemented by a network execution entity and comprises: - the detection of a priority indicator of said stream in said data stream; - evaluation of a level of resources available in the network slice; - the execution of at least one processing action of said data stream at least as a function of said priority indicator and of the level of network resources available in said network slice, said processing action belonging to a group comprising at least a first action of letting the data stream pass in said network slice, when the level of available resources is sufficient to route the data stream according to the priority indicator, and a second action of blocking the data stream in said slice of network, intended to be implemented when the level of available network resources is insufficient.
  • the invention is based on an entirely new and inventive approach to the processing of a data stream received from a client application by an execution entity of the communications network, which consists in detecting a priority indicator of the stream in a header of this stream and using it to decide, based on a level of available resources compared to a level of resources required to route the data stream with the priority level associated with it, whether this flow may be forwarded in the network slice to its destination or whether it should be discarded.
  • the invention is not limited to the two actions of allowing and blocking which have just been stated.
  • Other actions can be decided in particular when the assessed level of resources is insufficient to route the data flow under the conditions associated with the priority level.
  • other possible actions would be to defer the routing of the data stream to let other higher priority data streams pass, to clip the stream before transmitting it so that it requires fewer resources, to slow down or speed up the routing of the data flow by allocating fewer or more resources to it according to its priority level, etc.
  • the method comprises the prior obtaining of at least one rule for processing a data stream received from said software application, said rule comprising said data stream priority indicator, said network slice identifier and said at least one processing action of said stream, and extracting the processing action from said rule.
  • the node equipment applies processing rules that it has previously received and stored.
  • An advantage is that it is able to process the incoming data stream without delay. This embodiment is suitable for the implementation of simple rules.
  • said method when no processing rule has previously been obtained to process said data stream, said method further comprises notifying said priority indicator to a control entity of said network and receiving, from said control entity, said at least one processing action to be executed.
  • the execution entity does not have at its level rules for processing the data streams that it receives from the client application.
  • the basic rule that it applies is that of notifying a control entity which responds with the processing action(s) to be carried out on a case-by-case basis.
  • This embodiment is suitable for the implementation of more complex rules.
  • the intelligence of the network is concentrated at the level of the controlling entity(ies).
  • the execution entity being configured to manage the network slice and at least one other network slice of said communications network, when the processing action is the second blocking action of the data flow in the network slice, the method comprises, prior to the execution of the second processing action: - evaluation of a level of resources in the other network section; - the decision of at least a third processing action, called the action of transferring the data stream into the other network slice, as a function of said level of resources and of the priority indicator.
  • An advantage is to give certain data flows, for example the highest priority ones, an additional chance to be routed in the communications network, when the network slice in which they are is short of resources and when there is another network slice with a sufficient level of available resources to route the data stream under the conditions corresponding to its associated priority level.
  • the invention also relates to a device for processing a data stream in a communications network, said network being divided into a plurality of network slices, said data stream having been received in a said network slice of said plurality, in coming from a software application running on a terminal equipment (UE, IoT) connected to said network.
  • UE terminal equipment
  • Said device is configured to implement at the level of a network execution entity: - the detection of a priority indicator of said stream in said data stream; - evaluation of a level of resources available in the network slice; - the execution of at least one processing action of said data stream at least as a function of said priority indicator and of the level of network resources available in said network slice, said processing action belonging to a group comprising at least a first action of allowing data flow in said network slice, when the level of available resources is sufficient and a second action of blocking data flow in said network slice, intended to be implemented when the level of resources available network is insufficient.
  • said device configured to implement the steps of the processing method as described above.
  • said device is integrated into an execution entity of the communications network, included for example in the transfer plan of this network.
  • said execution entity is included in the data flow control system routed in a communications network.
  • the system, the execution entity and the processing device have at least the same advantages as those conferred by the aforementioned processing method.
  • the invention also relates to a method for controlling the processing of a data stream in a communications network, said communications network being divided into a plurality of network slices, said data stream having been transmitted by a terminal equipment and received by an execution entity of said network in a network slice of said plurality.
  • Said method is implemented by a control entity of said network, said control entity being configured to control the implementation of a policy for processing the data streams routed in said network and said method comprises: - the receipt from the execution entity of a notification of a priority indicator associated with said data stream received; - Obtaining a level of resources available in the network slice; - the decision of at least one processing action of said flow at least according to the priority indicator received and the level of available resources, said processing action belonging to a group comprising at least a first pass action of the flow of data in said network slice intended to be implemented when the level of available network resources is sufficient and a second action of blocking the flow of data in said network slice intended to be implemented when the level of network resources available is insufficient; And - sending a response to said execution entity, said response comprising said processing action.
  • the control entity itself applies the rules for processing the data streams received from the software application of the client by the execution entity, on notification of the entity of execution and sends the processing action to be executed to this execution entity. In this way, it controls the processing of all data flows sent by the client application in the network slice and the decision intelligence is concentrated at the level of the control plane.
  • said method comprises, prior to the transmission of the second processing action to the execution entity: - obtaining a level of resources available in the other network slice; - the decision of at least a third processing action, called the action of transferring the data stream into the other network slice, as a function of said level of resources and of the priority indicator.
  • a fallback mode is implemented for the highest priority data streams which could not be routed in the network slice initially planned. If another network slice to which the customer is eligible has sufficient network resources to route the data stream under the conditions of its priority level, then the control entity can decide to transfer the data stream to another slice of the network for which the client application is eligible.
  • the invention also relates to a device for controlling the processing of a data stream in a communications network, said communications network being divided into a plurality of network slices, said data stream having been transmitted by a terminal equipment and received by an execution entity of said network in a network slice of said plurality.
  • Said device is configured to implement at the level of a control entity of said network, said control entity being configured to control the implementation of a processing policy for the data streams routed in said network: - the receipt from the execution entity of a notification of a priority indicator associated with said data stream received; - Obtaining a level of resources available in the network slice; - the decision of at least one processing action of said flow at least according to the priority indicator received and the level of available resources, said processing action belonging to a group comprising at least a first pass action of the data flow in said network slice intended to be implemented when the level of available network resources is sufficient to route said data flow according to the priority indicator and a second action of blocking the data flow in said network slice intended to be implemented when the level of available network resources is insufficient; And - sending a response to said execution entity, said response comprising said processing action.
  • said device configured to implement the steps of the control method as described above.
  • said device is integrated into a control entity of the communications network, included for example in the control plane of this network.
  • said control entity is included in the data flow control system routed in a communications network.
  • the system, the control entity and the control device have at least the same advantages as those conferred by the aforementioned control method.
  • the invention finally relates to a data flow control system routed in a communications network comprising the aforementioned transmission device, the aforementioned processing device and the aforementioned control device.
  • control system also comprises a rules management entity, configured to define routing, processing and control rules for the data streams transmitted by a software application in a slice of the network, and to transmit them to the transmission, processing and control devices according to the invention.
  • a rules management entity configured to define routing, processing and control rules for the data streams transmitted by a software application in a slice of the network, and to transmit them to the transmission, processing and control devices according to the invention.
  • the invention also relates to computer program products comprising program code instructions for the respective implementation of the transmission, processing and control methods as described above, when it is executed by a processor.
  • a program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in partially compiled form, or in any other desirable form.
  • the invention also relates to at least one recording medium readable by a computer on which is recorded a computer program comprising program code instructions for the execution of the steps of the methods according to the invention as described above. .
  • Such recording medium can be any entity or device capable of storing the program.
  • the medium may include a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording medium, for example a mobile medium (memory card) or a hard drive or SSD.
  • such a recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means, so that the program computer it contains is executable remotely.
  • the programs according to the invention can in particular be downloaded from a network, for example the Internet network.
  • the recording medium(s) can be one or more integrated circuits in which each program is incorporated, the circuit(s) being adapted to execute or to be used in the execution of the aforementioned method(s).
  • the present technique is implemented by means of software and/or hardware components.
  • module may correspond in this document to a software component, a hardware component or a set of hardware and software components.
  • a software component corresponds to one or more computer programs, one or more sub-programs of a program, or more generally to any element of a program or software capable of implementing a function or a set of functions, as described below for the module concerned.
  • Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, set-top-box, router, etc.) and is likely to access the hardware resources of this physical entity (memories, recording media, communication bus, electronic input/output cards, user interfaces, etc.).
  • resources means all sets of hardware and/or software elements supporting a function or service, whether unitary or combined.
  • a hardware component corresponds to any element of a hardware assembly (or hardware) able to implement a function or a set of functions, according to what is described below for the module concerned. It can be a hardware component that can be programmed or has an integrated processor for executing software, for example an integrated circuit, a smart card, a memory card, an electronic card for executing firmware ( "firmware" in English), etc.
  • FIG. 1 there schematically illustrates an example of the architecture of a data flow control system transmitted in a communications network according to one embodiment of the invention
  • FIG. 1 there schematically illustrates an example of the architecture of a communications network, comprising a plurality of execution entities configured to process the routing of a data stream sent by terminal equipment in at least one slice of the communication, a plurality of control entities configured to control the processing of this flow by the execution entities and a plurality of management entities configured to send processing and control rules to these plurality of entities according to a mode of carrying out the invention;
  • the invention relates to a communications network structured in a plurality of network slices.
  • the general principle of the invention is based on the insertion of a priority indicator in a data stream transmitted by a software application running on a terminal equipment connected to the communications network, before its transmission in the communications network of this operator, and on the use of this indicator to handle the routing of this data flow in a particular network slice of the communications network.
  • This network slice can be dedicated to this customer in order to enable it to route the data flows generated by one or more of its own software applications, or business applications, or on the contrary shared between several of the operator's customers to route the data flows from different software applications of these customers, or even be dedicated to the implementation of a particular service of the operator, such as for example a voice over IP service.
  • the priority indicator is detected by an entity for executing a transfer plan of the operator's network and exploited to decide, according to a level of resources available in the network slice at the level of this execution entity and the resource requirements corresponding to this level of priority, whether or not the data stream will be able to be routed in this network slice.
  • the value of the priority indicator associated with each type of data stream transmitted by the software application is defined beforehand according to the needs of the software application.
  • the client defines its own flow types and their associated priority level.
  • the value of the priority indicator may change over time, in particular following a change in the operating mode of the software application.
  • the invention thus makes it possible to more finally adapt the technology of network slices to the increased needs of the customers and to the diversity of the data flows relating to one or more of these customers.
  • the invention allows the operator to apply its differentiated quality of service policy within a network slice.
  • the invention also allows the operator to group together within the same network slice the applications of different customers who share common requirements and to apply to them the same strategy for allocating the resources of the network slice. These include requirements in terms of availability of the data streams that the applications send (real time, non-real time) or in terms of isolation, i.e. the level of protection against typical disturbances congestion or potential attacks on the communications network).
  • the invention finds a very particular application in a mobile communications network whose architecture complies with the 3GPP 5G standard and allows this network to be structured in slices.
  • the invention is not limited to this example and extends to any other communications network architecture implementing a technology making it possible, such as the URSP rules for 3GPP terminal equipment, to discriminate the data streams from of a software application.
  • this notion of priority indicator designates a value, for example an integer, included in an interval of possible values.
  • this interval comprises a small number of values, for example equal to the number of distinct data stream types for the software application(s) associated with the network slice considered.
  • network resource of a network slice denotes both hardware resources and software resources at the level of the core network and of an access network, for example of a mobile radio access network RAN ( from English, "Radio Access Network”) of the communication network.
  • resource encompasses the access equipment or the node equipment itself, other resources of this equipment, such as a data modulation module, a time slot allocation module for the transmission of data, a quality of service management module associated with the different types of data transmitted (voice, IoT (Internet of Things), video, etc.).
  • a data modulation module for the transmission of data
  • a time slot allocation module for the transmission of data for the transmission of data
  • a quality of service management module associated with the different types of data transmitted (voice, IoT (Internet of Things), video, etc.).
  • PRB Physical Resource Block
  • modules for modulation allocation of time slots for data transmission
  • QoS Quality of Service
  • the availability of these resources is evaluated from data traffic information relating to a bandwidth, a data rate, a data volume, a number of frequency resource units or PRB (of the English, "Physical Resource Blocks"), etc., already allocated or on the contrary available, at the level of a mobile access equipment such as a base station or a node equipment of a transfer plan (or " user plane” in English) of the core network.
  • data traffic information relating to a bandwidth, a data rate, a data volume, a number of frequency resource units or PRB (of the English, "Physical Resource Blocks"), etc., already allocated or on the contrary available, at the level of a mobile access equipment such as a base station or a node equipment of a transfer plan (or " user plane” in English) of the core network.
  • FIG. 1 There schematically illustrates an example of the architecture of a system S for controlling a data stream transmitted by a software application executing on terminal equipment in an operator's RC communications network, divided into a plurality of network slices, according to an embodiment of the invention.
  • terminal equipment denotes both a user terminal, such as a mobile phone, of the smart phone type (in English, "smartphone"), a laptop computer, a tablet, a connected watch, etc. connected type IoT, such as a temperature data measurement sensor, vibration, etc. or an autonomous robot such as an AGV (Automated Guided Vehicle), for example installed in an industrial environment.
  • a user terminal such as a mobile phone, of the smart phone type (in English, "smartphone")
  • a laptop computer such as a laptop computer, a tablet, a connected watch, etc. connected type IoT, such as a temperature data measurement sensor, vibration, etc. or an autonomous robot such as an AGV (Automated Guided Vehicle), for example installed in an industrial environment.
  • AGV Automate Guided Vehicle
  • the terminal equipment UE, or IoT is connected to the network RC by an access network, such as for example a mobile radio access network via radio access equipment.
  • an access network such as for example a mobile radio access network via radio access equipment.
  • the invention applies to other access technologies, wireless or wired. Consequently, the terminal equipment can in a non-restrictive way be connected to the RC network via a base station, a femto cell associated with this base station, a multiplexer equipment for access to the DSLAM digital subscriber line (of English, "Digital Subscriber Line Access Multiplexer”) for an ADSL-type access network, a Wifi access point (or “hotspot", in English) or a Wifi repeater associated with this terminal, a ONT (Optical Network Termination) optical link for a fiber access network, PON type (Passive Optical Network), etc.
  • DSLAM digital subscriber line of English, "Digital Subscriber Line Access Multiplexer”
  • Wifi access point or "hotspot", in
  • the system S comprises this terminal equipment, which comprises a device 100 for transmitting a data stream in the network RC, configured to select a network slot from said plurality of slots, at least as a function of information included in a header of the data stream, obtaining information relating to a type of said stream, said type belonging to a group comprising at least a first type and a second type of stream, inserting a priority indicator associated with the type of stream in the data stream, the priority indicator belonging to a group comprising at least a first indicator associated with the first type of stream and a second indicator associated with the second type of stream, the first indicator and the second priority flag having distinct values and emit the data stream in the selected network slice.
  • this terminal equipment comprises a device 100 for transmitting a data stream in the network RC, configured to select a network slot from said plurality of slots, at least as a function of information included in a header of the data stream, obtaining information relating to a type of said stream, said type belonging to a group comprising at least a first type and
  • the core network configures the terminal equipment UE with all the network slices to which it is authorized to connect.
  • Each of these slices is identified by an S-NSSAI (Single – Network Slice Selection Assistance Information) identifier.
  • S-NSSAI Single – Network Slice Selection Assistance Information
  • the device 100 is configured to receive at least one data flow routing rule for said software application, said rule comprising at least one identifier of said software application, said type of flow, said priority indicator associated with said type and an identifier of a said network slice, storing in memory of said at least one routing rule and applying it during the implementation of said selection of said insertion.
  • this rule R_UE is stored in a memory of the device 100 or of the terminal equipment UE, IoT.
  • the device 100 thus implements the method for transmitting a data stream according to the invention which will be detailed below in relation to the .
  • the system S also comprises an execution entity EXE of the communications network, configured to manage the routing or routing of data streams transmitted by terminal equipment in at least one slice of the network RC communications.
  • an execution entity belongs to a transfer plan (or "User Plane", in English) of the RC communications network, according to the terminology defined in the standard ETSI TS 123 501, published in September 2018. It is an access device or a core network node device.
  • the execution entity EXE can be instantiated in the form of physical equipment dedicated or not to the respective functions of the execution entity EXE, or else in the form of virtualized entities, such as virtual functions for example.
  • this execution entity comprises a device 200 for processing a data stream transmitted by a software application of a terminal equipment UE, IoT in a said network slice.
  • This device 200 is configured to obtain a level of resources available to route the data stream in the network slice, detect a priority indicator of said stream in said data stream, and perform at least one processing action of said data stream at the at least as a function of said priority indicator and of a level of network resources available in said network slice, said processing action belonging to a group comprising at least a first action of blocking the flow of data in said network slice, intended to be implemented when the level of available network resources is insufficient and a second action of passing the data flow in said network slice, when the level of available resources is sufficient.
  • the device 200 is configured to obtain at least one R_UP processing rule for a data stream received from said software application, said rule comprising said data stream priority indicator, said network slice identifier and said au least one processing action of said stream, storing it in memory and applying it to the processing of the data stream.
  • This rule R_UP is advantageously stored in a memory of the device 200 or of the execution entity EXE.
  • the device 200 thus implements the method for processing a data stream according to the invention which will be detailed below in relation to the .
  • the system S also comprises a control entity CTR of the communications network RC, configured to control the implementation of a data flow processing policy routed in said network by one or more execution entities.
  • entity is part of a so-called control plane. It can be part of the access network or the core network.
  • ENM network management element Element Network Manager
  • NMS network management system 'English, 'Network Management System', associated with 5G/4G base stations, also known as 'gNodeB' or 'eNodeB' respectively.
  • this control entity may be the SMF (of the "Session Management Function") that controls the UPF (User Plane Function) through the N4 interface according to the 3GPP TS 23.501 specification.
  • the CTR control entity can be instantiated as a physical equipment dedicated or not to the respective functions of the controller CTR, or else in the form of virtualized entities.
  • a device 300 for controlling the processing by the execution entity EXE of a data stream transmitted by a software application of the terminal equipment UE, IoT in a slice of the communications network Said device is configured to receive, from the execution entity, a notification of a priority indicator associated with said received data stream, obtain a level of resources available to route the data stream in the network slice, decide at least one processing action of said stream to be executed, at least as a function of the priority indicator received and of a processing policy for the data streams transmitted by the software application, said processing action belonging to a group comprising at least a first action of blocking the flow of data in said network slice intended to be implemented when the level of available network resources is insufficient and a second action of letting the flow of data pass in said network slice intended to be implemented when the level of available network resources is sufficient, and sending a response to said execution entity, comprising said at least one processing action.
  • the device 300 is configured to obtain at least one R_CP control rule for processing a data stream received from said software application, said rule comprising said data stream priority indicator, said network slot identifier and said at least one processing action of said stream, storing it in memory and applying it to the control of the processing of the data stream.
  • This rule R_CP is advantageously stored in a memory of the device 300 or of the control entity CTR.
  • the device 300 thus implements the method for controlling the processing of a data stream according to the invention which will be detailed below in relation to the .
  • the system S finally comprises a management entity EMG of the plurality of slices of the communication network RC. It is part of an RC communication network management plan.
  • a management entity EMG implements the Network Slice Management Functions as described in document ETSI GR NFV-EVE 012 on the support of network slices in a virtualized environment, published in December 2017.).
  • the management entity EMG can also be instantiated in the form of physical equipment dedicated or not to the respective functions of the management entity, or else in the form of virtualized entities.
  • this management entity comprises a device 400 for managing rules, configured to obtain business information from a client of a software application intended to be executed by a terminal equipment, said information comprising at least types of data streams intended to be sent by the software application and priority indicators associated with each of the stream types, transmitting the rules respectively to the terminal equipment, to the execution entity EXE and to the control entity CTR.
  • the communications network RC is divided into several slices SL_1 to SL_N, with N greater than 2.
  • N the number of slices SL_1 and SL_2 are dedicated to the uses of a given client, which notably implements the API_TM and API_JM software applications.
  • These software applications are specific business applications of the client, which has defined the different types of data flows implemented and their associated priority levels.
  • the invention is not limited to this use case, but applies to any other strategy for allocating slices of the communications network of an operator to clients, terminals, software applications , services, etc
  • the operator defines a network slice dedicated to the routing of data streams transmitted within the framework of one of the services that it offers to its customers, such as the Voice over IP service.
  • it defines different types of Voice over IP data streams associated with distinct levels of quality of service, in connection with different levels of subscriptions taken out by customers (for example, gold, silver or bronze) and it assigns them separate priority flag values, with the VOIP stream type "gold" having the highest priority and the VOIP stream type "bronze" having the lowest priority.
  • rules R_UE for routing data streams originating from this software application API_TA, API_JM are received at 30, for example originating from the management entity EMG. These rules make it possible to associate a priority indicator with each data stream sent by the software application API_TA, API_JM.
  • such a rule includes an identifier of the software application API_TA, API_JM, an identifier of the type of data stream STR_ID, an identifier of the network slice to be used to send the data stream in the communication network RC and the value of the associated IP priority indicator.
  • a rule for business application "Augmented Technician”, data stream of type STR_1, network slice SL_1, the structure of such a rule is as follows: "IP Priority Flag - Business Software Application API_TA - Slice type SL_1 – Data stream type STR_1”. They are stored in a memory, for example a memory M1 of the device 100 or a memory of the terminal equipment UE, IoT.
  • the rules UE_R received at 30 are associated with an operating mode of the software application API_TA, AP_JM.
  • an operating mode of the software application API_TA, AP_JM there are three distinct operating modes: - a nominal operating mode MO_1, which corresponds to a normal operating situation; - an alarm operating mode MO_2, which corresponds to an alarm situation; And - a post-alarm operating mode MO_3, which corresponds to a situation of return to normal or restart following the alarm.
  • the indicator can take at least the following values: - IP_1, for example equal to 1 for a high priority real-time stream; - IP_2, for example equal to 2, for a non-real-time or deferred stream, of high priority; - IP_3, for example equal to 3, for a non-real-time or deferred flow, of low priority.
  • the UE_R rules can for example comprise an additional attribute corresponding to the operating mode associated with them.
  • API_TA current operating mode of the software application
  • API_JM nominal operating mode
  • an STR data stream is received at 32 from the software application API_TA, API_JM.
  • the network slice is selected, based on at least one item of information included in a header of the data stream. For example, it is the so-called destination IP address which identifies the equipment which will receive this data stream and/or an identifier of the API_TA application, API_JM.
  • this information is extracted from a header of a signaling protocol, such as the NAS (Non Access Stratum) protocol implemented in the exchanges between the terminal equipment and the 5G core network, and defined by the procedure "4.16.12.2 EU Policy Association Modification initiated by the PCF" of 3GPP TS 23.502.
  • the type of data stream STR_ID (e.g. voice, video streaming or data exchange) is obtained, for example from the 2-tuple “(destination) IP address; protocol ID" extracted from a stream header or from the attribute triplet "(destination) IP address, port number, protocol ID".
  • the use of the attribute triplet is used, for example, to more finely differentiate two distinct streams from the same application on the basis of their distinct port numbers.
  • this application is configured to transmit these streams to the same application server, located on the first line, but when the latter retransmits each of them to separate specialized servers, located on the second line.
  • a server specializing in pattern recognition receives video streaming streams
  • another server specializing in technical documentation indexing receives enriched data streams
  • yet another server specialized in interpersonal connection services receives voice over IP streams.
  • the value of the current operating mode MO_1 is obtained, if applicable.
  • the rule UE_R stored in memory corresponding to the software application API_TA, API_JM which sent the stream STR, to the type of data stream STR_ID and possibly to the current operating mode MO_1 is retrieved, which makes it possible to obtain the value of the IP priority indicator associated with this STR data flow.
  • the IP priority indicator is inserted into the STR data stream. For example, it is inserted in a header of the STR data stream, such as a header of the application protocol used by the software application API_TA, API_JM. For example, the IP priority indicator is inserted into a variable in an HTTP GET request header.
  • It can also be inserted in a header of an IP packet, an Ethernet frame, or a 3GPP network context (PDP context, EPB bearer, session PDU). Alternatively, it can also be inserted into the useful part of such a packet, frame or context of the STR data stream.
  • the data stream STR thus modified is transmitted in the data slot SL_1 of the communication network RC.
  • API_TA the value of the priority indicator to be inserted in the next data stream sent by the software application API_TA, API_JM is updated and becomes that associated with the new current operating mode .
  • this data stream STR is received by an execution entity EXE of the transfer plane UP of the communications network RC and the method is implemented by the device 200 integrated into this execution entity EXE configured to manage at least the SL_1 network slice of the RC network.
  • the network RC is a mobile communications network compliant with 5G, it is for example an equipment of the radio access network RAN, for example, in an O-RAN architecture, this equipment can be the one implementing the O-CU-UP (“ O-RAN Central Unit – User Plane ” [O-RAN]) function, or core network equipment.
  • O-CU-UP O-RAN Central Unit – User Plane ” [O-RAN]
  • the execution entity EXE is configured to manage the slices SL_1 and SL_2 of the network RC.
  • the STR data stream is received.
  • an IP priority indicator is detected in the data stream, for example in a header or in a useful part of this data stream.
  • an evaluation of a level of NRS_1 resources available to route the data stream STR in the network slice SL_1 is obtained.
  • This evaluation can be implemented locally or obtained from a remote device, for example another device in the transfer plane.
  • the execution entity EXE is aware of the resources at its disposal and that it can use for each SL network slice for which it is responsible. Indeed, in a 5G architecture, when implementing network slices, the management plane configures each access and core network equipment according to the characteristics of each slice. These characteristics include in particular the bandwidth allocated to each slice.
  • each processing rule R_UP specifies the bandwidth necessary for the correct operation of each type of data flow likely to be sent by the business application API_TA, API_JM considered.
  • the execution entity EXE evaluates whether the resources available for a given slice SL are sufficient to ensure the routing of the data stream received given the value of the IP priority indicator associated with it. It does this by comparing the amount of resources needed to route the received stream to the amount of resources available. This is, for example, a number of PRBs at the level of a radio access network, a bit rate in kbits/s or Mbits/s for the core network.
  • a second level of prioritization can be applied, in the case where several real-time streams use the same network slice and are received at the same time by the execution entity EXE, for example by first processing the high priority real-time streams compared to low priority real-time streams.
  • This is particularly the case for an operator's "Voice over IP" application which distinguishes between priority VoIP data streams and non-priority VoIP data streams.
  • VoIP over IP Voice over IP
  • the low-priority real-time streams will remain given priority over the non-real-time streams and in particular over the high-priority non-real-time streams.
  • an AC processing action to be performed to process the routing of this data stream is obtained.
  • the processing action AC is executed.
  • the processing action AC can be obtained by the execution entity EXE in different ways, which will now be detailed.
  • At least one processing rule R_UP of the data stream STR received from the software application API_TA, API_JM is obtained at 430. It is assumed for example that a set of rules has been received from the management entity EGM in a prior configuration phase not shown. Such rules indicate the AC processing action to be performed for the STR data stream.
  • a processing rule R_UP comprises an identifier of the software application API_TA, API_JN, an identifier of the type of data stream STR_1, an identifier of the network slice SL_1 to be used to send the data stream in the network of communication RC, the value of the associated priority indicator IP_1 and an identifier of the action AC to be executed.
  • the memory in question is organized as a database and the processing rule to be applied to the received STR data stream is obtained by querying the database using the identifier of the software application and/ or the identifier of the data stream and the priority indicator detected in the stream.
  • the treatment action AC can take at least one of the following two values: - passing (AC1, for example equal to 1) the data stream and transferring it to the network slice SL_1; - block (AC2, for example equal to 2) the data stream STR and remove it from the network slice SL_1.
  • the actions AC_1, AC_2 are the two basic actions to be executed at 44. They have the advantage of being simple to implement, on the basis of simple rules, because they are based on taking binary decision. Of course, other actions can be taken into consideration to implement an enriched strategy, when the resources are assessed as insufficient. For example, another possible action would be to speed up or delay the transfer of the STR data stream or assign less or more resources to it, or to limit or clip the data stream before transmitting it to adapt to the available resources. . In the case where two streams of the same priority are received simultaneously, it would thus be possible to transfer them both while allocating fewer resources to each.
  • the processing action AC is extracted from the obtained rule R_UP, then applied at 44.
  • the execution entity EXE has therefore been configured beforehand to decide locally on the processing action to be executed.
  • it may have previously received a first processing rule R_UP0 indicating to it whether it should decide locally on the processing action to be executed or whether it should notify another entity of the communication network RC.
  • R_UP0 a first processing rule
  • it can simply search in memory if it has an R_UP rule for the software application from which the received data stream originates and for the detected IP priority indicator. If no corresponding R_UP rule is found, then it notifies another entity or else it applies a default R_UP_D rule which defines the processing action to be executed for a data flow originating from the software application in question or from all the network slice client software applications SL_1, associated with the lowest priority level IP_3.
  • the execution entity EXE is configured to notify another entity of the communications network RC.
  • it is a control entity CTR of the control plane of the network RC, configured to control the implementation of a processing policy for the data streams routed in said network RC.
  • the first rule R_UP0 identifies this control entity CTR to be notified and the information to be transmitted to it.
  • the execution entity obtains this first rule R_UP0 and therefore extracts from it the identity of the control entity to be notified.
  • it notifies the control entity CTR that it has received the data stream STR, associated with the priority indicator IP in the network slice SL_1. It should be noted that it can trigger this notification following the detection of the IP priority indicator in the data stream STR, that is to say systematically notify the control entity CTR in a message comprising a single indicator of priority associated with a single data stream received, or, alternatively, transmit a single NTF notification message at the expiration of a given time period grouping the priority indicators detected in data streams received on the network slice SL_1 during this period.
  • At 432' it receives in return the processing action to be performed. For example, it is one of the two actions AC_1, AC_2 previously mentioned or else, according to the enriched strategy, another action, for example delaying or accelerating the transfer of the data stream STR or else limiting or clipping of the data stream before transfer.
  • it executes the received processing action.
  • control plane which applies the data flow processing rules according to the priority indicators associated with these flows.
  • an NTF notification is received by the control entity CTR from the execution entity EXE of the transfer plan of the communications network RC. It relates to a data stream STR received by this execution entity EXE and comprises at least one identifier of the type of data stream STR_1, an associated priority indicator IP_1 and the identifier of the network slice SL_1. For example, this notification is transmitted to the control entity in a message conforming to a protocol of the radius, diameter or http/2 type. In the case of a service-based architecture or SBA (Service Based Architecture) for 5G, the http/2 protocol is used.
  • control entity CTR obtains an evaluation of a level of resources available in the network slice SL_1 with respect to the need for resources to transmit the data stream STR received under the conditions provided for the level of priority which it receives. is associated, the mechanisms implemented are similar to those described for step 42 and will not be detailed further.
  • the CTR control entity or function retrieves the available resource information for each network slice from the O-CU- CP.
  • the CTR control entity or function retrieves this available resource information from a session management function SMF (Session Management Function) which controls the transfer plan function UPF ( English, "User Plane Function") corresponding to the EXE execution entity or function in question, via the N4 interface as defined by the 3GPP in the TS23.501 specification (section 5.8.2.11 "Parameters for N4 session management")
  • SMF Session Management Function
  • UPF English, "User Plane Function”
  • a control rule R_CP of the data streams routed on the network slice SL_1 and associated with the received IP priority indicator it is assumed that a set of rules R_CP has been received from the management entity EMG in a prior configuration phase, not shown. Such rules indicate the AC processing action to perform for the STR data stream based on the value of its associated priority flag.
  • a control rule R_CP comprises an identifier of the network slice SL_1, the value of the priority indicator IP_1 and an identifier of the action AC to be executed.
  • this control rule R_CP is very close in its structure and content to a processing rule R_UP.
  • the R_CP control rules can be more complex because the CTR control entity or function generally has a broader view of the domain for which it is responsible than the EXE execution entity or function which does not is aware only of its own resources and therefore a scope of action limited to its function.
  • the memory in question is organized as a database and the control rule R_CP to be applied to the received NTF notification is obtained by querying the database using the identifier of the data slice SL_1 and the IP priority indicator received in the notification.
  • the processing action AC is extracted from the rule received, then at 54 a response is transmitted to the execution entity in a message comprising at least the processing action AC.
  • this message conforms to the JSON format and is sent using the http/2 protocol.
  • the mechanism in question is therefore triggered following obtaining 43 of the action AC at the level of the execution entity EXE when this action is an action AC2 blocking the flow of data in the network slice SL_1 or more generally , when the available resources are assessed as insufficient and an action to limit the flow or to delay the transfer of the flow has been taken, or further to the decision 53 to execute this action AC at the level of the control entity CTR.
  • the processing action to be executed remains action AC2 of blocking, therefore of suppressing the data flow of the network slice SL_1 or of limiting the flow according to the resources available for routing.
  • this fallback rule is available for the current data stream, then the availability of the resources in another network slice accessible to the client of the software application, here the slice SL_2, is evaluated at 61. A quantity of available resources is obtained and then compared with a given minimum threshold TH or with the resource requirements for routing the data stream STR at 62. If this other network slice SL_2 has sufficient resources and/or more resources available than the network slice SL_1 to route the data stream STR, i.e. if the quantity of resources evaluated is greater than or equal to the threshold TH, then the data stream STR is transferred to the other slice of SL_2 network.
  • such a fallback rule R_UP_FK, R_CP_FK is associated with priority indicators corresponding to high priority levels.
  • R_UP_FK, R_CP_FK is associated with priority indicators corresponding to high priority levels.
  • IP_1 For example, for the software application API_TA, AP_JN, only data flows associated with a priority indicator IP_1 can benefit from this fallback solution to another network slice SL_2.
  • STR_1 in nominal mode MO_1 can benefit from the fallback solution, but that on the other hand all types of streams STR_1, STR_2 and STR_3 in MO2 alarm mode can benefit from it.
  • This mechanism therefore has the advantage of offering an additional chance for a priority data stream to be routed when the resources of the transfer plane UP are not sufficient in the network slice SL_1 selected for the application which has it. issued.
  • the fallback mechanism which comes to be described can either be executed locally also on the basis of a fallback rule R_UP_FK provided that the execution entity is in charge of managing at least two network slices SL_1, SL_2 accessible to the software application concerned , either the decision to block the STR data flow or even to limit the STR data flow, triggers the emission of a notification intended for the control entity CTR so that it implements the fallback mechanism in question.
  • the notification includes the priority indicator, the identifier of the software application API_TA, API_JN, the identifier of the selected network slice SL_1.
  • the control entity CTR implements the fallback mechanism and responds to the notification by transmitting either a confirmation of the blocking action (or limitation of routing) AC_2 or the transfer action AC_3 specifying the network slice SL_2 to which to transfer the data stream; - in the case of the second embodiment, according to which the execution entity EXE notifies the control entity CTR on which it depends of the priority indicator detected in the data stream STR that it has received, and of the network slice SL_1 in which it received it, the fallback mechanism is advantageously implemented by the control entity CTR following the decision 52 to have the entity EXE execute the decision AC_2 to block the flow of STR data. In this way, the control entity only sends the transfer action AC_3 in its response to the NTF notification from the execution entity EXE, associated with the network slice SL_2 towards which this transfer must be carried out
  • the management plane MP comprises a plurality of management entities EMG_1, EMG_2, EMG_3 configured to define routing, processing and data flow control rules in the different slices SL_1, SL_2 of the network RC.
  • the management entities are configured to transmit data flow routing rules to UE, IoT terminal equipment connected to the RC network, processing rules to a plurality of execution entities EXE_1, EXE_2, EXE_3 of the transfer plane UP, and of the control rules to a plurality of control entities CTR_1, CTR_2, CTR_3 of the control plane CP of the network RC.
  • Some of these execution entities can be configured to manage several slices SL_1, SL_2 of the RC network, others only one. Those configured to manage at least two slices of the RC network will be able to implement the fallback mechanism described in relation to the and apply it to the highest priority data streams.
  • this fallback mechanism can, as a variant, be implemented by control entities CTR_1, CTR_2, CTR_3 when the execution entities that they control manage at least two network slices.
  • the execution entity EXE_1 detects an "alarm" operating mode and informs the control entity CTR_1 which manages the entity EXE_1.
  • This entity CTR_1 can then decide to duplicate the flows to another network slice SL_2 which is controlled by an execution entity EXE_1' (not shown) for the transfer plane and by this same entity CTR_1 for the control plane.
  • the execution entities of the transfer plane are placed along the path or the route taken by an STR data stream emitted by the terminal equipment UE, IoT towards its destination. It is therefore understood that each of them is configured to implement the process for processing a data stream which has just been described under the control of the control entity CTR_1, CTR_2, CTR_3 on which it depends.
  • control entity which takes the decision relating to the routing of the data flow can receive information relating to a level of resources available in this network slice of another operator from a control managed by this other operator.
  • a device 100 for transmitting a data stream in a telecommunications network to which terminal equipment is connected, said network being divided into a plurality of network slices, said device comprising a module for selecting a network slice from said plurality at least as a function of the identifier of the software application, a module for obtaining a type of said stream, said type belonging to a group comprising at least a first type and a second type of stream, and a module for inserting a priority indicator associated with the type of stream in a header of the data stream, the priority indicator belonging to a group comprising at least a first indicator associated with the first type of stream and a second indicator associated with the second type of stream, the first indicator and the second priority indicator having distinct values and a transmission module of the data stream in the selected network slice.
  • the device 100 comprises a module for receiving at least one data flow routing rule for said software application, said rule comprising at least one identifier of said software application, said type of flow, said indicator of priority associated with said type of flow and an identifier of a said network slice; a module for storing said at least one processing rule in memory, the selection and insertion modules being configured to apply said at least one rule.
  • the device 100 also comprises a module for obtaining an operating mode of said software application, said operating mode belonging to a group comprising at least a first operating mode and a second operating mode, said at least one routing rule being associated with said procedure.
  • module can correspond both to a software component and to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or sub-programs or in a more general to any element of a program able to implement a function or a set of functions.
  • such a device 100 comprises a random access memory 103 (for example a RAM memory), a processing unit 102 equipped for example with a processor, and controlled by a computer program Pg1, representative of the selection modules, d obtaining, insertion, reception, storage, stored in a read only memory 101 (for example a ROM memory or a hard disk).
  • a computer program Pg1 representative of the selection modules, d obtaining, insertion, reception, storage, stored in a read only memory 101 (for example a ROM memory or a hard disk).
  • the code instructions of the computer program are for example loaded into the random access memory 103 before being executed by the processor of the processing unit 102.
  • the random access memory 103 can also contain for example the identifier of the software application, the type of data stream and the operating mode obtained.
  • the device 100 performs the steps of the method for transmitting a data stream as detailed above, in relation to the , in its various embodiments. Indeed, these steps can be carried out either on a reprogrammable calculation machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated calculation machine (for example a set of logic gates like an FPGA or an ASIC, or any other hardware module).
  • a reprogrammable calculation machine a PC computer, a DSP processor or a microcontroller
  • a program comprising a sequence of instructions
  • a dedicated calculation machine for example a set of logic gates like an FPGA or an ASIC, or any other hardware module.
  • the corresponding program (that is to say the sequence of instructions) could be stored in a removable storage medium (such as for example an SD card , a USB key, a CD-ROM or a DVD-ROM) or not, this storage medium being partially or totally readable by a computer or a processor.
  • a removable storage medium such as for example an SD card , a USB key, a CD-ROM or a DVD-ROM
  • a connectivity gateway generally serves as an interface between so-called light IoT modules (that is to say equipped with a low on-board processing capacity) and the communications network RC. It is for example implemented for energy management.
  • IoT sensors send user energy consumption measurement data to a connectivity gateway, which is typically configured to aggregate around ten IoT sensors.
  • a device 200 for processing a data stream received in a telecommunications network said network being divided into a plurality of network slices, said data stream having been received from a software application executing on a terminal equipment connected to said network in a said network slice of said plurality, said device comprising a module for obtaining an evaluation of a level of resources available in the network slice, a module for detecting a priority indicator in a header of said data stream and a module for executing at least one processing action of said data stream at least as a function of said priority indicator and of the level of network resources available in said slot network, said processing action belonging to a group comprising at least a first action of letting the data flow pass in said network slice, when the level of available resources is sufficient and a second action of blocking the data flow in said network slice, intended to be implemented when the level of available network resources is insufficient.
  • the device 200 comprises a module for obtaining beforehand at least one rule for processing a data stream received from said software application, said rule comprising said priority indicator of a data stream, said slice identifier network and said at least one processing action of said flow, and an extraction module (of the processing action of said rule).
  • said device also comprises a module for notifying said priority indicator to a control entity of said network, configured to be implemented when no processing rule has previously been obtained to process said data stream, and a module receipt, from said control entity, of said at least one processing action to be executed.
  • the device 200 finally comprises a module for obtaining an evaluation of a level of resources in another network slice and a module for deciding at least one third processing action, called the action of transferring the flow of data, according to said level of resources (and the priority indicator, replacing the second processing action).
  • These modules are configured to be implemented when the execution entity being configured to manage the network slice and said at least one other network slice of said communication network and when the processing action is the second blocking action of the data flow in the network slice.
  • module can correspond both to a software component and to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or sub-programs or in a more general to any element of a program able to implement a function or a set of functions.
  • such a device 200 comprises a random access memory 203 (for example a RAM memory), a processing unit 202 equipped for example with a processor, and controlled by a computer program Pg2, representative of the aforementioned modules, stored in a read only memory 201 (for example a ROM memory or a hard disk).
  • a random access memory 203 can also contain for example the identifier of the software application, the priority indicator, the network slice, the level of resources evaluated for the network slice, the type of data stream obtained. It can also include the previously received processing rules, the level(s) of resources evaluated for the network slice(s), the decision threshold(s) implemented to decide whether the level(s) of resources evaluated are sufficient to route the data flow.
  • the device 200 performs the steps of the method for controlling the processing of a data stream as detailed above, in relation to FIGS. 4, 4A, 4B and 6, in its various embodiments. Indeed, these steps can be carried out either on a reprogrammable calculation machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated calculation machine (for example a set of logic gates like an FPGA or an ASIC, or any other hardware module).
  • a reprogrammable calculation machine a PC computer, a DSP processor or a microcontroller
  • a dedicated calculation machine for example a set of logic gates like an FPGA or an ASIC, or any other hardware module.
  • the corresponding program (that is to say the sequence of instructions) can be stored in a removable storage medium (such as for example an SD card , a USB key, a CD-ROM or a DVD-ROM) or not, this storage medium being partially or totally readable by a computer or a processor.
  • a removable storage medium such as for example an SD card , a USB key, a CD-ROM or a DVD-ROM
  • a device 200 integrated in an execution entity of the communications network RC for example a node equipment of the access network, for example a base station of a mobile radio access network or core network router equipment.
  • a device 300 for controlling the processing of a data stream received in a telecommunications network, said network being divided into a plurality of network slices, said data stream having been transmitted by a device terminal and received by an execution entity of said network in a network slice of said plurality, said device comprising a module for receiving from the execution entity a notification of an associated priority indicator (IP) to said data stream received, a module for obtaining a level of resources available in the network slice, a module for deciding at least one processing action of said stream at least as a function of the priority indicator received and the level of available resources, and a module for sending a response to said execution entity, said response comprising said processing action.
  • IP priority indicator
  • the device 300 comprises a module for obtaining beforehand at least one rule for controlling the processing of a data stream received from said software application, said rule comprising said priority indicator of a data stream, said identifier network slice and said at least one processing action of said flow, and a storage module of said at least one rule in memory.
  • said device 300 also comprises a module for obtaining a level of resources available in another network slice, a module for deciding at least one third processing action, called the data stream transfer action, in based on said level of resources and the priority indicator, replacing the second processing action.
  • modules are configured to be implemented prior to the transmission of the second processing action to the execution entity, when the decided processing action is the action of blocking said data flow in the network slice and when the execution entity is configured to manage another network slice of said plurality.
  • the term "module" can correspond both to a software component and to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or sub-programs or in a more general to any element of a program able to implement a function or a set of functions.
  • such a device 300 comprises a random access memory 303 (for example a RAM memory), a processing unit 302 equipped for example with a processor, and controlled by a computer program Pg3, representative of the aforementioned modules, stored in a read only memory 301 (for example a ROM memory or a hard disk).
  • a random access memory 303 for example a RAM memory
  • a processing unit 302 equipped for example with a processor
  • a computer program Pg3 representative of the aforementioned modules
  • the code instructions of the computer program are for example loaded into the random access memory 303 before being executed by the processor of the processing unit 302.
  • the random access memory 303 can also contain, for example, the rules received previously, the identifier of the software application, the priority indicator, the network slice, the level of resources evaluated for the network slice, the type of data stream obtained. It can also include the level of resources assessed for the other network slice, the decision threshold(s) implemented to decide whether the level(s) of resources assessed are sufficient to route the data flow.
  • the device 300 performs the steps of the method for controlling the processing of a data stream as detailed above, in relation to FIGS. 5 and 6, in its different embodiments. Indeed, these steps can be carried out either on a reprogrammable calculation machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated calculation machine (for example a set of logic gates like an FPGA or an ASIC, or any other hardware module).
  • a reprogrammable calculation machine a PC computer, a DSP processor or a microcontroller
  • a dedicated calculation machine for example a set of logic gates like an FPGA or an ASIC, or any other hardware module.
  • the corresponding program (that is to say the sequence of instructions) can be stored in a removable storage medium (such as for example an SD card , a USB key, a CD-ROM or a DVD-ROM) or not, this storage medium being partially or totally readable by a computer or a processor.
  • a removable storage medium such as for example an SD card , a USB key, a CD-ROM or a DVD-ROM
  • this device 300 is implemented in an O-CU-CP functional entity of a mobile access network according to the O-RAN specifications.
  • this device 300 can be implemented in an SMF functional entity according to the 3GPP specifications of the 5G architecture.

Abstract

L'invention concerne un procédé d'émission d'un flux de données reçu d'une application logicielle s'exécutant sur un équipement terminal, dans un réseau de communications auquel est connecté ledit équipement terminal, ledit réseau étant découpé en une pluralité de tranches de réseau, caractérisé en ce que ledit procédé est mis en œuvre au niveau dudit équipement terminal et comprend - la sélection (33) d'une tranche de réseau de ladite pluralité au moins en fonction d'une information comprise dans un en-tête du flux de données, - l'obtention (34) d'un type dudit flux, ledit type appartenant à un groupe comprenant au moins un premier type (et un deuxième type de flux), et - l'insertion (37) d'un indicateur de priorité (IP) associé au type de flux (STR_ID) dans ledit flux de données, l'indicateur de priorité appartenant à un groupe comprenant au moins un premier indicateur associé au premier type de flux et un deuxième indicateur associé au deuxième type de flux, le premier indicateur et le deuxième indicateur de priorité ayant des valeurs distinctes; -l'émission (38) du flux de données comprenant l'indicateur de priorité dans la tranche de réseau sélectionnée.

Description

Procédé d’émission d’un flux de données dans un réseau de communications, procédé de traitement d’un flux de données, procédé de contrôle du traitement d’un flux de données, dispositifs, équipement terminal, entité d’exécution, entité de contrôle, système et programmes d’ordinateur correspondants. 1. Domaine de l'invention
L'invention se situe dans le domaine des télécommunications, et notamment dans celui des réseaux de communications structurés en tranches de réseau.
En particulier, l’invention concerne l’émission, le traitement et le contrôle des flux de données acheminés dans une telle tranche de réseau.
Elle s’applique notamment mais non exclusivement à un réseau de télécommunications mobiles dont l’architecture est conforme à la norme 3GPP (pour « Third Generation Partnership Project », en anglais), dans sa version 5G ou dans une version future.
2. Art antérieur et ses inconvénients
La digitalisation des processus industriels contribue à diversifier la nature des données qui transitent sur les réseaux d’un opérateur. Par exemple, l’internet des objets (Internet of Things ou IoT en anglais) permet la mise en œuvre de nouveaux services comme la maintenance prédictive dans un objectif de recherche d’efficacité opérationnelle. Ces nouveaux services ne sont pas forcément temps-réel mais deviennent de plus en plus importants pour un client.
On connaît par exemple une application métier dite « technicien augmenté » qui permet à un technicien de visualiser des données diverses lui permettant d’enrichir le contexte d’une scène d’intervention. Il s’agit par exemple d’un historique des interventions faites sur une pièce industrielle sélectionnée, ou encore un processus de manipulation de la pièce industrielle sélectionnée. Ce technicien dispose aussi de la possibilité de bénéficier d’une assistance vocale avec un expert distant. On connaît aussi une application métier dite « jumeau numérique » qui permet la remontée d’informations de fonctionnement mesurées par des capteurs connectés vers un système d’informations du client afin de construire une représentation dite virtuelle de l’environnement d’exécution de ces capteurs. Cette application métier permet aussi à un utilisateur situé à proximité de ces capteurs de disposer d’une assistance vocale avec un expert distant en cas de dysfonctionnement ou de besoin de reconfiguration d’un ou plusieurs de ces capteurs. Chacune de ces applications décrites à titre d’exemple met généralement en œuvre des flux de données de natures différentes qui ne sont pas forcément temps-réel mais deviennent de plus en plus importants pour le client et pour les fournisseurs de services.
En dehors de l’IoT, on voit émerger d’autres exemples de services non temps-réel tels que par exemple les mises à jour d’applications professionnelles, les applications de divertissement et de jeu pour le marché grand-public, ou de cartographie pour le secteur de la voiture connectée.
La technologie en tranches de réseau (ou network slicing en anglais), notamment introduite dans les spécifications 5G, est prometteuse pour la mise en œuvre de réseaux spécialisés et l’acheminement différencié de données applicatives, notamment pour le support des services IoT qui ont des exigences variées en termes de débit, de disponibilité, ou encore de consommation énergétique. Une tranche de réseau est un sous-réseau défini de manière logicielle (de l’anglais, « Software-Defined Network ») dont le fonctionnement est spécialement configuré pour répondre aux besoins d’un client et/ou d’un terminal et/ou d’une application, et notamment pour mettre en œuvre de nouveaux services. Cette technologie permet donc notamment de répondre aux besoins spécifiques des différents clients de l’opérateur en réservant à chacun d’eux une ou plusieurs tranches de son réseau de communications. Selon la norme 5G du 3GPP, une tranche de réseau se compose de fonctions de réseau physiques et/ou virtuelles PNF/VNF (pour « Physical Network Functions/Virtual Network Functions », en anglais) qui sont interconnectées et peuvent appartenir à la partie accès et/ou à la partie cœur du réseau de communications. La synthèse d'une tranche de réseau sert donc un objectif fonctionnel particulier et, une fois instanciée, elle est utilisée pour soutenir certains services de communication pour un client dit « vertical » dédié (ex. une entreprise, une offre de service, etc.) en lui assurant une garantie de qualité de service donnée. Chaque tranche de réseau peut avoir sa propre architecture, sa propre gestion des opérations FCAPS (pour « Fault-management, Configuration, Accounting, Performance, and Security », en anglais) et sa propre sécurité correspondant à un cas d’usage particulier.
L’état de l’art dans la spécification des tranches de réseau permet de sélectionner une tranche de réseau pour une application client donnée, selon un mécanisme mis en œuvre via les règles URSP pour « User Equipment Route Selection Policies” définies dans les spécifications [3GPP TS 24.526] et [3GPP TS 23.503]. Plusieurs attributs peuvent être utilisés pour aiguiller les flux de données (ou « data flow » en anglais) issus d’une application client donnée vers la tranche de réseau correspondante :
- l’identifiant de l’application « Application ID », le FQDN (Fully Qualified Domain Name), le triplet « IP address, port number, protocol ID », le DNN (Data Network Name).
Par exemple, comme illustré par la , une application de technicien augmenté API_TA met en œuvre trois flux de données de natures différentes, comprenant :
- un type de flux STR_1 de données voix sur IP ou VoIP (de l’anglais, « Voice over IP ») ;
- un type de flux STR_2 de données de streaming vidéo ;
- un type de flux STR_3 de données enrichies.
A titre d’autre exemple, une application de jumeau numérique API_JN met en œuvre deux flux de natures différentes, comprenant :
- un type de flux STR_1’ de données voix sur IP ou VoIP ;
- un type de flux STR_2’ de données de capteurs.
Cependant, le mécanisme d’aiguillage via les règles URSP est essentiellement statique. Il ne permet pas de configurer dynamiquement, ni de contrôler une priorité d’acheminement d’un flux de données par rapport à un autre flux de données d’une même application client dont les flux de données sont acheminés dans une tranche de réseau spécifique. Pourtant, on comprend que le client aimerait pouvoir associer dynamiquement des priorités différentes à ces différents flux de sorte que les flux de type STR_1 soient traités de façon très prioritaire et acheminés en temps réel, les flux de type STR_2 soient acheminés avec une priorité standard et les flux de données de type STR_3 soient acheminés avec une priorité basse.
On connaît aussi une politique de gestion de la qualité de service basée sur une spécification 5QI définie par le 3GPP dans la spécification [3GPP TS 23.501 – section 5.7.3.1] et qui s’applique au niveau des paquets de données traités par un réseau de communication conforme à la norme 3GPP. Selon cette spécification, l’acheminement de paquets de données dans une tranche de réseau doit respecter plusieurs critères parmi lesquels :
-un critère de ressources (de l’anglais, « resource type ») qui précise si le débit doit être garanti,
- un critère de niveau de priorité (de l’anglais, « priority level ») qui précise le niveau de priorité du paquet,
- un critère de délai de transfert (de l’anglais, « Packet Delay Budget ») qui précise le délai de transfert de bout-en-bout autorisé (incluant les segments radio et cœur de réseau),
- un critère de taux d’erreur (de l’anglais, « Packet Error Rate ») qui précise le taux d’erreur dans la transmission du paquet,
-un critère de fenêtre moyenne (de l’anglais, « Averaging window ») qui précise la durée de maintien en mémoire du paquet au niveau d’un équipement du plan de transfert du réseau,
- un critère de volume maximal de volume de données en rafale (de l’anglais), « Maximum Data Burst Volume ») qui caractérise la nature du volume de données.
Le critère de priorité du paquet de données de l’indicateur 5QI est configuré pour prendre une vingtaine de valeurs figées associées à des types de paquets standardisés, par exemple, un paquet de type voix conversationnelle (de l’anglais, « conversational voice ») ou un paquet de type vidéo conversationnelle (de l’anglais, « conversational video »).
Un inconvénient de ce mécanisme de priorisation des paquets de données dans une tranche de réseau est qu’il ne permet pas de s’adapter aux besoins spécifiques d’un client qui voudrait définir de façon dynamique ses propres niveaux de priorité pour ses propres types de flux de données en fonction de l’application visée et éventuellement faire évoluer leurs niveaux de priorités respectifs selon la situation réelle (nominale ou alarme par exemple).
L’invention vient améliorer la situation.
3. Présentation de l’invention
L’invention répond à ce besoin en proposant un procédé d’émission d’un flux de données reçu d’une application logicielle s’exécutant sur un équipement terminal, dans un réseau de communications auquel est connecté ledit équipement terminal, ledit réseau étant découpé en une pluralité de tranches de réseau, caractérisé en ce que ledit procédé est mis en œuvre au niveau dudit équipement terminal et comprend
- la sélection d’une tranche de réseau de ladite pluralité au moins en fonction d’une information comprise dans un en-tête du flux de données,
- l’obtention d’un type dudit flux, ledit type appartenant à un groupe comprenant au moins un premier type et un deuxième type de flux, et
- l’insertion d’un indicateur de priorité associé au type de flux dans le flux de données, l’indicateur de priorité appartenant à un groupe comprenant au moins un premier indicateur associé au premier type de flux et un deuxième indicateur associé au deuxième type de flux, le premier indicateur et le deuxième indicateur de priorité ayant des valeurs distinctes ;
-l’émission du flux de données comprenant l’indicateur de priorité dans la tranche de réseau sélectionnée.
L’invention repose sur une approche tout-à-fait nouvelle et inventive qui consiste à insérer un indicateur de priorité dans un flux de données émis par une application d’un client éligible pour être acheminée via une tranche de réseau donnée. Cet indicateur de priorité est par exemple inséré dans un en-tête ou dans la partie utile du flux de données. Il est destiné à être détecté par une ou plusieurs entités du réseau en charge de traiter l’acheminement du flux de données dans la tranche de réseau et à être utilisé pour décider comment traiter le flux de données en fonction des ressources réseau disponibles et en particulier s’il peut être acheminé ou non par la tranche de réseau sélectionnée. Avec l’invention, il est ainsi possible de prioriser les flux de données émis par une application logicielle s’exécutant sur l’équipement terminal dans une tranche de réseau particulière. Cette tranche de réseau peut être dédiée ou non à l’application logicielle. S’il s’agit d’une application logicielle d’un client, la tranche de réseau peut être dédiée à cette application ou à plusieurs applications de ce client ou encore à l’ensemble des flux émis par ce client en général. L’invention permet alors au client d’affecter le niveau de priorité souhaité à chacun des types de flux applicatifs mis en œuvre dans sa ou ses applications logicielles. Par application logicielle, on entend ici une application métier associée par exemple à un client, cette application métier comprenant différents flux (voix, données, streaming, gestion…) requérant des priorités différentes selon leurs besoins.
Si l’application logicielle est configurée pour mettre en œuvre un service spécifique d’un opérateur, comme par exemple le service « Voix sur IP », la tranche de réseau en question peut être réservée à l’acheminement des flux de l’application Voix sur IP émis par cette application logicielle, quel que soit l’équipement terminal ou le client utilisant cet équipement terminal. Dans ce cas, l’opérateur configure avantageusement différents types de flux de Voix sur IP par exemple en fonction d’un niveau de qualité de service auquel chaque client accède en lien avec l’abonnement auquel il a souscrit. Dans ce cas-là, l’application logicielle est une application, par exemple de type VoIP, et les priorités sont associées par exemple à des clients ayant par exemple des contrats distincts et donc des priorités différentes pour l’application logicielle de Voix sur IP. Ainsi différents paramètres de l’en-tête du flux de données peuvent être utilisées distinctement ou en combinaison parmi lesquels un identifiant de l’application logicielle, tel que l’identifiant du protocole utilisé (par exemple le protocole RTP – Real Time Protocol), l’adresse IP de l’émetteur voire l’adresse IP du destinataire.
La tranche de réseau peut enfin être configurée par l’opérateur pour regrouper les flux de données émis par les applications logicielles de plusieurs clients distincts, qui ont par exemple des exigences communes en termes de disponibilité ou d’isolation des flux de données, etc. Dans ce cas, l’opérateur peut définir plusieurs types de flux de données et des valeurs d’indicateurs de priorité associés de façon commune à tous les clients qui partagent la tranche de réseau.
Un autre avantage de l’invention est qu’elle permet de sélectionner la tranche de réseau à utiliser pour un flux de données au niveau de l’équipement terminal, plutôt qu’au niveau d’un équipement du réseau de communications proprement dit. La charge est ainsi déplacée du réseau vers le terminal. En outre, du fait que l’équipement terminal n’a que ses propres flux de données à gérer, cette sélection est plus simple à mettre en œuvre et répond mieux aux contraintes de passage à l’échelle (de l’anglais, « scalability »). En effet, grâce à la mise en œuvre de tranches de réseau sur les terminaux, il est possible d’associer des flux de données du terminal à des tranches distinctes, ce qui est plus difficile à mettre en œuvre lorsque la tranche de réseau est instanciée sur un équipement du réseau d’opérateur où les flux sont plus nombreux et en outre potentiellement chiffrés, rendant impossible l’exploitation de données d’en-tête. En outre, le client possédant le terminal peut lui-même gérer les tranches alors qu’il n’aura pas la possibilité lors d’une instanciation sur un équipement du réseau, comme cela peut être le cas lors de mise en œuvre du réseau privé virtuel (en anglais VPN – Virtual Private Network), l’architecture en tranche de réseau proposant en outre des capacités d’isolation des flux plus importante que les réseaux privés virtuels notamment.
Selon un aspect de l’invention, le procédé comprend en outre :
- la réception préalable d’au moins une règle d’acheminement d’un flux de données émis par ladite application logicielle, ladite règle comprenant au moins un identifiant de ladite application logicielle, ledit type de flux, ledit indicateur de priorité associé audit type de flux et un identifiant d’une dite tranche de réseau;
- le stockage en mémoire de ladite au moins une règle d’acheminement et
- l’application de ladite au moins une règle d’acheminement lors de la mise en œuvre de ladite sélection et de ladite insertion .
Avantageusement, cette priorisation des flux de données émis par l’application logicielle est mise en œuvre par l’installation préalable de règles définissant la valeur de l’indicateur de priorité à insérer dans le flux de données en plus de la tranche de réseau à utiliser.
Par exemple, dans une architecture 5G, la tranche de réseau est identifiée par un paramètre S-NSSAI. On note que le réseau d’accès mobile 5G garde un contexte des tranches de réseau pour lesquelles le terminal s’est préalablement enregistré et qu’il n’est pas nécessaire d’insérer ce champ d’informations dans un en-tête du flux de données.
Si l’application logicielle est une application d’un client, c’est le client qui peut définir ses propres types de flux et les valeurs d’indicateur de priorité qu’il associe à chacun d’eux. Si l’application logicielle met en œuvre un service de l’opérateur, comme par exemple un service de voix sur IP, alors c’est l’opérateur qui définit les types de flux de données, par exemple par type de client ou de niveau d’abonnement et leur associe une valeur d’indicateur de priorité.
Selon un autre aspect de l’invention, le procédé comprend en outre l’obtention d’un mode opératoire de ladite application logicielle, ledit mode opératoire appartenant à un groupe comprenant au moins un premier mode opératoire et un deuxième mode opératoire, et ladite au moins une règle d’acheminement est associée audit mode opératoire.
Un avantage est que les règles de priorisation des flux de données les uns par rapport aux autres peuvent être modifiés en fonction d’un mode opératoire courant de l’application.
Par exemple, lorsque l’application logicielle est celle d’un client, ces modes opératoires sont préalablement définis par le client et comprennent au moins un premier mode dit « nominal » et un deuxième mode dit « alarme » et des règles de traitement spécifiques des flux de données sont associées à chacun de ces modes. Ils peuvent comprendre en outre un troisième mode de type « Reporting Priorisé » qui, contrairement au mode alarme, peut être planifié, voir récurrent sur une plage horaire donnée. Un tel mode opératoire peut être avantageusement mis en œuvre dans tous les secteurs d’activité pour le suivi de performance opérationnelle.
Par exemple, pour une application de « jumeau numérique », un flux de données de type « données de capteur » est associé à une valeur minimale à moyenne de l’indicateur de priorité en mode opératoire « nominal », mais à une valeur maximale de l’indicateur de priorité en mode opératoire « alarme ». En effet, ces données de capteur sont utiles pour gérer une crise et doivent être reçues en temps réel avec une priorité maximale dans le mode « alarme ».
On comprend donc qu’un mode opératoire courant, par exemple correspondant à une situation nominale peut être défini de façon préalable au niveau du terminal de l’utilisateur qui va appliquer les règles d’acheminement associées à ce mode opératoire, mais qu’il peut être modifié au cours du temps par notification d’une entité du client connectée au réseau. Sur réception d’une notification de changement du mode opératoire, par exemple de passage à un mode opératoire de type alarme, le terminal de l’utilisateur va mettre en application les règles d’acheminement associées à ce nouveau mode opératoire pour les futurs flux de données émis par l’application logicielle dans la tranche de réseau.
L’invention concerne également un dispositif d’émission d’un flux de données par une application logicielle s’exécutant sur un équipement terminal, dans un réseau de communications auquel est connecté ledit terminal, ledit réseau étant découpé en une pluralité de tranches de réseau. Ledit dispositif est configuré pour mettre en œuvre au niveau de l’équipement terminal :
- la sélection d’une tranche de réseau de ladite pluralité au moins en fonction d’une information comprise dans un en-tête du flux de données ;
- l’obtention d’un type dudit flux, ledit type appartenant à un groupe comprenant au moins un premier type et un deuxième type de flux), et
- l’insertion d’un indicateur de priorité associé au type de flux dans le flux de données, l’indicateur de priorité appartenant à un groupe comprenant au moins un premier indicateur associé au premier type de flux et un deuxième indicateur associé au deuxième type de flux, le premier indicateur et le deuxième indicateur de priorité ayant des valeurs distinctes ; et
-l’émission du flux de données comprenant ledit indicateur de priorité, dans la tranche de réseau sélectionnée.
Avantageusement, ledit dispositif configuré pour mettre en œuvre les étapes du procédé d’émission tel que décrit précédemment.
Avantageusement, ledit dispositif est intégré dans un équipement terminal connecté au réseau de communications, tel qu’un terminal utilisateur ou un objet connecté.
Avantageusement, ledit équipement terminal est compris dans un système de contrôle de flux de données acheminés dans un réseau de communications.
Le système, l’équipement terminal et le dispositif d’émission présentent au moins les mêmes avantages que ceux conférés par le procédé d’émission précité.
Corrélativement, l’invention concerne aussi un procédé de traitement d’un flux de données dans un réseau de communications, ledit réseau étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été reçu dans unedite tranche de réseau de ladite pluralité en provenance d’une application logicielle s’exécutant sur un équipement terminal connecté à audit réseau. Ledit procédé est mis en œuvre par une entité d’exécution du réseau et comprend :
- la détection d’un indicateur de priorité dudit flux dans un ledit flux de données ;
- l’évaluation d’un niveau de ressources disponibles dans la tranche de réseau ;
- l’exécution d’au moins une action de traitement dudit flux de données au moins en fonction dudit indicateur de priorité et du niveau de ressources réseau disponibles dans ladite tranche de réseau, ladite action de traitement appartenant à un groupe comprenant au moins une première action de laisser-passer du flux de données dans ladite tranche de réseau, lorsque le niveau de ressources disponibles est suffisant pour acheminer le flux de données selon l’indicateur de priorité, et une deuxième action de blocage du flux de données dans ladite tranche de réseau, destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant.
L’invention repose sur une approche tout-à-fait nouvelle et inventive du traitement d’un flux de données reçu d’une application client par une entité d’exécution du réseau de communications, qui consiste à détecter un indicateur de priorité du flux dans un en-tête de ce flux et à l’utiliser pour décider, en fonction d’un niveau de ressources disponibles par rapport à un niveau de ressources requis pour acheminer le flux de données avec le niveau de priorité qui lui est associé, si ce flux peut être acheminé dans la tranche de réseau vers sa destination ou s’il doit être rejeté.
Bien sûr, l’invention ne se limite pas aux deux actions de laisser -passer et de blocage qui viennent d’être énoncées. D’autres actions peuvent être décidées notamment lorsque le niveau de ressources évalué est insuffisant pour acheminer le flux de données dans les conditions associées au niveau de priorité. Par exemple, d’autres actions possibles seraient de différer l’acheminement du flux de données pour laisser-passer d’autres flux de données plus prioritaires, d’écrêter le flux avant de le transmettre pour qu’il nécessite moins de ressources, de ralentir ou d’accélérer l’acheminement du flux de données en lui affectant moins ou plus de ressources selon son niveau de priorité, etc.
Selon un aspect de l’invention, le procédé comprend l’obtention préalable d’au moins une règle de traitement d’un flux de données reçu de ladite application logicielle, ladite règle comprenant ledit indicateur de priorité d’un flux de données, ledit identifiant de tranche de réseau et ladite au moins une action de traitement dudit flux, et l’extraction de l’action de traitement de ladite règle.
Pour décider de l’action à exécuter, l’équipement nœud met en application des règles de traitement qu’il a préalablement reçues et stockées. Un avantage est qu’il est capable de traiter le flux de données entrant sans délai. Ce mode de réalisation est adapté à la mise en œuvre de règles simples.
Selon un autre aspect de l’invention, lorsqu’aucune règle de traitement n’a été préalablement obtenue pour traiter ledit flux de données, ledit procédé comprend en outre la notification dudit indicateur de priorité à une entité de contrôle dudit réseau et la réception, en provenance de ladite entité de contrôle, de ladite au moins une action de traitement à exécuter.
Selon au moins un autre mode de réalisation de l’invention, l’entité d’exécution ne dispose pas à son niveau de règles de traitement des flux de données qu’il reçoit en provenance de l’application client. La règle de base qu’il applique est celle de notifier une entité de contrôle qui lui répond par la ou les actions de traitement à exécuter au cas par cas. Ce mode de réalisation est adapté à la mise en œuvre de règles plus complexes. L’intelligence du réseau est concentrée au niveau de la ou des entités de contrôle.
Selon encore un autre aspect de l’invention, l’entité d’exécution étant configurée pour gérer la tranche de réseau et au moins une autre tranche de réseau dudit réseau de communications, lorsque l’action de traitement est la deuxième action de blocage du flux de données dans la tranche de réseau, le procédé comprend, préalablement à l’exécution de la deuxième action de traitement :
- l’évaluation d’un niveau de ressources dans l’autre tranche de réseau ;
- la décision d’au moins une troisième action de traitement, dite action de transfert du flux de données dans l’autre tranche de réseau, en fonction dudit niveau de ressources et de l’indicateur de priorité.
Un avantage est de donner à certains flux de données, par exemple les plus prioritaires une chance supplémentaire d’être acheminés dans le réseau de communications, lorsque la tranche de réseau dans laquelle ils sont est à court de ressources et lorsqu’il existe une autre tranche de réseau avec un niveau de ressources disponibles suffisant pour acheminer le flux de données dans les conditions correspondant à son niveau de priorité associé.
L’invention concerne également un dispositif de traitement d’un flux de données dans un réseau de communications, ledit réseau étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été reçu dans unedite tranche de réseau de ladite pluralité, en provenance d’une application logicielle s’exécutant sur un équipement terminal (UE, IoT) connecté à audit réseau. Ledit dispositif est configuré pour mettre en œuvre au niveau d’une entité d’exécution du réseau :
- la détection d’un indicateur de priorité dudit flux dans ledit flux de données ;
- l’évaluation d’un niveau de ressources disponibles dans la tranche de réseau ;
- l’exécution d’au moins une action de traitement dudit flux de données au moins en fonction dudit indicateur de priorité et du niveau de ressources réseau disponibles dans ladite tranche de réseau, ladite action de traitement appartenant à un groupe comprenant au moins une première action de laisser-passer du flux de données dans ladite tranche de réseau, lorsque le niveau de ressources disponibles est suffisant et une deuxième action de blocage du flux de données dans ladite tranche de réseau, destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant.
Avantageusement, ledit dispositif configuré pour mettre en œuvre les étapes du procédé de traitement tel que décrit précédemment.
Avantageusement, ledit dispositif est intégré dans une entité d’exécution du réseau de communications, comprise par exemple dans le plan de transfert de ce réseau.
Avantageusement, ladite entité d’exécution est comprise dans le système de contrôle de flux de données acheminés dans un réseau de communications.
Le système, l’entité d’exécution et le dispositif de traitement présentent au moins les mêmes avantages que ceux conférés par le procédé de traitement précité.
Corrélativement, l’invention concerne aussi un procédé de contrôle du traitement d’un flux de données dans un réseau de communications, ledit réseau de communications étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été émis par un équipement terminal et reçu par une entité d’exécution dudit réseau dans une tranche de réseau de ladite pluralité. Ledit procédé est mis en œuvre par une entité de contrôle dudit réseau, ladite entité de contrôle étant configurée pour contrôler la mise en œuvre d’une politique de traitement des flux de données acheminés dans ledit réseau et ledit procédé comprend :
- la réception en provenance de l’entité d’exécution d’une notification d’un indicateur de priorité associé audit flux de données reçu ;
- l’obtention d’un niveau de ressources disponibles dans la tranche de réseau ;
- la décision d’au moins une action de traitement dudit flux au moins en fonction de l’indicateur de priorité reçu et du niveau de ressources disponibles, ladite action de traitement appartenant à un groupe comprenant au moins une première action de laisser-passer du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est suffisant et une deuxième action de blocage du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant ; et
- l’envoi d’une réponse à ladite entité d’exécution, ladite réponse comprenant ladite action de traitement.
Selon un mode de réalisation de l’invention, l’entité de contrôle applique elle-même les règles de traitement des flux de données reçus de l’application logicielle du client par l’entité d’exécution, sur notification de l’entité d’exécution et envoie l’action de traitement à exécuter à cette entité d’exécution. De la sorte, elle contrôle le traitement de tous les flux de données émis par l’application client dans la tranche de réseau et l’intelligence de décision est concentrée au niveau du plan de contrôle.
Selon un aspect de l’invention, lorsque l’action de traitement décidée est l’action de blocage dudit flux de données dans la tranche de réseau et lorsque l’entité d’exécution est configurée pour gérer une autre tranche de réseau de ladite pluralité, ledit procédé comprend, préalablement à la transmission de la deuxième action de traitement à l’entité d’exécution:
- l’obtention d’un niveau de ressources disponibles dans l’autre tranche de réseau;
- la décision d’au moins une troisième action de traitement, dite action de transfert du flux de données dans l’autre tranche de réseau, en fonction dudit niveau de ressources et de l’indicateur de priorité.
Avantageusement, un mode repli est mis en œuvre pour les flux de données les plus prioritaires qui n’ont pas pu être acheminés dans la tranche de réseau initialement prévue. Si une autre tranche de réseau à laquelle le client est éligible dispose de ressources réseau suffisantes pour acheminer le flux de données dans les conditions de son niveau de priorité, alors l’entité de contrôle peut décider, de transférer le flux de données vers une autre tranche du réseau à laquelle l’application client est éligible.
L’invention concerne également un dispositif de contrôle du traitement d’un flux de données dans un réseau de communications, ledit réseau de communications étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été émis par un équipement terminal et reçu par une entité d’exécution dudit réseau dans une tranche de réseau de ladite pluralité. Ledit dispositif est configuré pour mettre en œuvre au niveau d’une entité de contrôle dudit réseau, ladite entité de contrôle étant configurée pour contrôler la mise en œuvre d’une politique de traitement des flux de données acheminés dans ledit réseau:
- la réception en provenance de l’entité d’exécution d’une notification d’un indicateur de priorité associé audit flux de données reçu ;
- l’obtention d’un niveau de ressources disponibles dans la tranche de réseau ;
- la décision d’au moins une action de traitement dudit flux au moins en fonction de l’indicateur de priorité reçu et du niveau de ressources disponibles, ladite action de traitement appartenant à un groupe comprenant au moins une première action de laisser-passer du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est suffisant pour acheminer ledit flux de données selon l’indicateur de priorité et une deuxième action de blocage du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant ; et
- l’envoi d’une réponse à ladite entité d’exécution, ladite réponse comprenant ladite action de traitement.
Avantageusement, ledit dispositif configuré pour mettre en œuvre les étapes du procédé de contrôle tel que décrit précédemment.
Avantageusement, ledit dispositif est intégré dans une entité de contrôle du réseau de communications, comprise par exemple dans le plan de contrôle de ce réseau.
Avantageusement, ladite entité de contrôle est comprise dans le système de contrôle de flux de données acheminés dans un réseau de communications.
Le système, l’entité de contrôle et le dispositif de contrôle présentent au moins les mêmes avantages que ceux conférés par le procédé de contrôle précité.
Alternativement, l’invention concerne enfin un système de contrôle de flux de données acheminés dans un réseau de communications comprenant le dispositif d’émission précité, le dispositif de traitement précité et le dispositif de contrôle précité.
Avantageusement, le système de contrôle selon l’invention comprend aussi une entité de gestion de règles, configurée pour définir des règles d’acheminement, de traitement et de contrôle des flux de données émis par une application logicielle dans une tranche du réseau, et pour les transmettre aux dispositifs d’émission, de traitement et de contrôle selon l’invention.
L’invention concerne également des produits programmes d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre respective des procédés d’émission, de traitement et de contrôle tels que décrit précédemment, lorsqu’il est exécuté par un processeur.
Un programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
L’invention vise également au moins un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes des procédés selon l’invention tel que décrits ci-dessus.
Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un support mobile (carte mémoire) ou un disque dur ou un SSD.
D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau par exemple le réseau Internet.
Alternativement, le ou les supports d'enregistrement peuvent être un ou des circuits intégrés dans lesquels chaque programme est incorporé, le ou les circuits étant adaptés pour exécuter ou pour être utilisé dans l'exécution du ou des procédés précités.
Selon un exemple de réalisation, la présente technique est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set-top-box, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.). Par la suite, on entend par ressources tous ensembles d’éléments matériels et/ou logiciels support d’une fonction ou d’un service, qu’ils soient unitaires ou combinés.
De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (« firmware » en anglais), etc.
Chaque composante du système précédemment décrit met bien entendu en œuvre ses propres modules logiciels.
Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de la présente technique.
4. Brève description des figures
D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :
 : la illustre de façon schématique des exemples de types de flux de données mis en œuvre dans des applications clients et destinés à être acheminés dans une tranche d’un réseau de communications ;
 : la illustre de façon schématique un exemple d’architecture d’un système de contrôle de flux de données émis dans un réseau de communications selon un mode de réalisation de l’invention ;
 : la décrit sous forme d’un logigramme les étapes d’un procédé d’émission d’un flux de données dans une tranche d’un réseau de communications, selon un exemple de réalisation de l’invention ;
 : la décrit sous forme d’un logigramme les étapes d’un procédé de traitement d’un flux de données émis dans une tranche d’un réseau de communications, selon un exemple de réalisation de l’invention ;
 : la détaille l’obtention d’une action de traitement du flux de données selon un premier mode de réalisation de l’invention ;
 : la détaille l’obtention d’une action de traitement du flux de données selon un deuxième mode de réalisation de l’invention ;
 : la décrit sous forme d’un logigramme les étapes d’un procédé de contrôle du traitement d’un flux de données émis dans une tranche d’un réseau de communications, selon un exemple de réalisation de l’invention ;
 : la illustre de façon schématique le traitement d’un flux de données émis dans une tranche de réseau par une entité d’exécution du plan de transfert d’un réseau de communications selon un mode de réalisation de l’invention ;
: la illustre de façon schématique un exemple d’architecture d’un réseau de communications, comprenant une pluralité d’entités d’exécution configurées pour traiter l’acheminement d’un flux de données émis par un équipement terminal dans au moins une tranche du réseau de communication, une pluralité d’entités de contrôle configurées pour contrôler le traitement de ce flux par les entités d’exécution et une pluralité d’entités de gestion configurées pour envoyer des règles de traitement et de contrôle à ces pluralités d’entités selon un mode de réalisation de l’invention ;
: la décrit un exemple de structure matérielle d’un dispositif d’émission d’un flux de données dans une tranche d’un réseau de communications selon l’invention ;
: la décrit un exemple de structure matérielle d’un dispositif de traitement d’un flux de données émis dans une tranche d’un réseau de communications selon l’invention ;
: la décrit un exemple de structure matérielle d’un dispositif de contrôle du traitement d’un flux de données dans une tranche d’un réseau de communications selon l’invention.
5. Description détaillée de l'invention
L’invention concerne un réseau de communications structuré en une pluralité de tranches de réseau. Le principe général de l’invention repose sur l’insertion d’un indicateur de priorité dans un flux de données émis par une application logicielle s’exécutant sur un équipement terminal connecté au réseau de communications, avant son émission dans le réseau de communications de cet opérateur, et sur l’utilisation de cet indicateur pour traiter l’acheminement de ce flux de données dans une tranche de réseau particulière du réseau de communications. Cette tranche de réseau peut être dédiée à ce client afin de lui permettre d’acheminer les flux de données générés par une ou plusieurs de ses propres applications logicielles, ou applications métier, ou au contraire partagée entre plusieurs clients de l’opérateur pour acheminer les flux de données issus de différentes applications logicielles de ces clients, ou encore être dédié à la mise en œuvre d’un service particulier de l’opérateur, comme par exemple un service de voix sur IP.
Dans le réseau de communications, l’indicateur de priorité est détecté par une entité d’exécution d’un plan de transfert du réseau de l’opérateur et exploité pour décider, en fonction d’un niveau de ressources disponibles dans la tranche de réseau au niveau de cette entité d’exécution et des besoins en ressources correspondant à ce niveau de priorité, si le flux de données va pouvoir ou non être acheminé dans cette tranche de réseau.
Avantageusement, la valeur de l’indicateur de priorité associée à chaque type de flux de données émis par l’application logicielle est préalablement définie en fonction des besoins de l’application logicielle. En particulier, dans le cas d’une application métier d’un client, le client définit ses propres types de flux et leur niveau de priorité associé. La valeur de l’indicateur de priorité peut évoluer au cours du temps, notamment suite à un changement de mode opératoire de l’application logicielle.
L’invention permet ainsi d’adapter plus finalement la technologie de tranches de réseau aux besoins accrus des clients et à la diversité des flux de données relatifs à un ou plusieurs de ces clients.
Dans le cas où l’application logicielle considérée met en œuvre un service de l’opérateur, l’invention permet à l’opérateur de mettre en application sa politique de qualité de service différenciée au sein d’une tranche de réseau.
L’invention permet aussi à l’opérateur de regrouper au sein d’une même tranche de réseau les applications de différents clients qui partagent des exigences communes et de leur appliquer une même stratégie d’affectation des ressources de la tranche de réseau. Il s’agit notamment d’exigences en termes de disponibilité des flux de données que les applications émettent (temps réel, non temps réel) ou en termes d’isolation, c’est-à-dire de niveau de protection contre des perturbations type congestion ou attaques potentielles du réseau de communications).
L’invention trouve une application toute particulière dans un réseau de communications mobiles dont l’architecture est conforme à la norme 5G du 3GPP et permet une structuration de ce réseau en tranches. Bien sûr, l’invention n’est pas limitée à cet exemple et s’étend à toute autre architecture de réseau de communications mettant en œuvre une technologie permettant, comme les règles URSP pour les équipements terminaux 3GPP, de discriminer les flux de données issus d’une application logicielle.
Dans la suite, on désigne par cette notion d’indicateur de priorité une valeur, par exemple entière, comprise dans un intervalle de valeurs possibles. Avantageusement, cet intervalle comprend un faible nombre de valeurs, par exemple égal au nombre de types de flux de données distincts pour la ou les applications logicielles associées à la tranche de réseau considérée.
Dans la suite on désigne par ressource réseau d’une tranche de réseau aussi bien des ressources matérielles que des ressources logicielles au niveau du réseau cœur que d’un réseau d’accès, par exemple d’un réseau d’accès radio mobile RAN (de l’anglais, « Radio Access Network ») du réseau de communication.
Cette notion de ressource englobe l’équipement d’accès ou l’équipement nœud lui-même, d’autres ressources de cet équipement, comme un module de modulation de données, un module d’allocation d’intervalles de temps pour la transmission de données, un module de gestion de la qualité de service associée aux différents types de données transmises (voix, IoT (de l’anglais, « Internet of Things »), vidéo, etc). Pour une station de base d’un réseau d’accès cellulaire par exemple, il s’agit par exemple de composants particuliers de cette antenne radio, tels que des unités de ressources PRB (de l’anglais, « Physical Ressource Block »), des modules de modulation, d’allocation d’intervalles de temps pour la transmission de données, de gestion de la qualité de service QoS (de l’anglais, « Quality of Service ») pour les différents types de données transmises, etc. La disponibilité de ces ressources est évaluée à partir d’informations de trafic de données relatives à une bande-passante, à un débit de données, à un volume de données, à un nombre d’unités de ressources fréquentielles ou PRB (de l’anglais, « Physical Resource Blocks »), etc, déjà alloués ou au contraire disponibles, au niveau d’un équipement d’accès mobile tel qu’une station de base ou d’un équipement nœud d’un plan de transfert (ou « user plane », en anglais) du cœur de réseau.
La illustre de façon schématique un exemple d’architecture d’un système S pour le contrôle d’un flux de données émis par une application logicielle s’exécutant sur un équipement terminal dans un réseau de communications RC d’un opérateur, découpé en une pluralité de tranches de réseau, selon un mode de réalisation de l’invention.
On désigne ici par équipement terminal aussi bien un terminal utilisateur, tel qu’un téléphone mobile, de type téléphone intelligent (de l’anglais, « smartphone »), un ordinateur portable, une tablette, une montre connectée, etc qu’un objet connecté de type IoT, comme par exemple un capteur de mesures de données de température, de vibration, etc ou encore un robot autonome comme un AGV (de l’anglais, « Automated Guided Vehicle »), par exemple installé dans un environnement industriel.
On suppose que l’équipement terminal UE, ou IoT est connecté au réseau RC par un réseau d’accès, tel que par exemple un réseau d’accès radio mobile par l’intermédiaire d’un équipement d’accès radio. Bien sûr, et comme déjà évoqué, l’invention s’applique à d’autres technologies d’accès, sans fil ou filaires. En conséquence, l’équipement terminal peut de façon non restrictive être connecté au réseau RC via une station de base, une femto cellule associée à cette station de base, un équipement multiplexeur d'accès à la ligne d'abonné numérique DSLAM (de l’anglais, « Digital Subscriber Line Access Multiplexeur ») pour un réseau d’accès de type ADSL, une borne d’accès Wifi (ou « hotspot », en anglais) ou un répéteur Wifi associé à cette borne, un équipement de terminaison de liaison optique ONT (de l’anglais, « Optical Network Termination ») pour un réseau d’accès fibre, de type PON (de l’anglais, « Passive Optical Network »), etc.
Selon ce mode de réalisation de l’invention, le système S comprend cet équipement terminal, lequel comprend un dispositif 100 d’émission d’un flux de données dans le réseau RC, configuré pour sélectionner une tranche de réseau de ladite pluralité de tranches, au moins en fonction d’une information comprise dans un en-tête du flux de données, obtenir une information relative à un type dudit flux, ledit type appartenant à un groupe comprenant au moins un premier type et un deuxième type de flux, insérer un indicateur de priorité associé au type de flux dans le flux de données, l’indicateur de priorité appartenant à un groupe comprenant au moins un premier indicateur associé au premier type de flux et un deuxième indicateur associé au deuxième type de flux, le premier indicateur et le deuxième indicateur de priorité ayant des valeurs distinctes et émettre le flux de données dans la tranche de réseau sélectionnée. A cet égard, on note que dans le cas d’une architecture 5G, le cœur de réseau configure l’équipement terminal UE avec l’ensemble des tranches de réseaux auxquelles il est autorisé à se connecter. Chacune de ces tranches est identifiée par un identifiant S-NSSAI (de l’anglais, « Single – Network Slice Selection Assistance Information »).
Avantageusement le dispositif 100 est configuré pour recevoir au moins une règle d’acheminement d’un flux de données pour ladite application logicielle, ladite règle comprenant au moins un identifiant de ladite application logicielle, ledit type de flux, ledit indicateur de priorité associé audit type et un identifiant d’une dite tranche de réseau, stocker en mémoire de ladite au moins une règle d’acheminement et l’appliquer lors de la mise en œuvre de ladite sélection de ladite insertion. Par exemple, cette règle R_UE est stockée dans une mémoire du dispositif 100 ou de l’équipement terminal UE, IoT.
Le dispositif 100 met ainsi en œuvre le procédé d’émission d’un flux de données selon l’invention qui sera détaillé ci-après en relation avec la .
Selon ce mode de réalisation de l’invention, le système S comprend aussi une entité d’exécution EXE du réseau de communications, configurée pour gérer l’acheminement ou routage de flux de données émis par des équipements terminaux dans au moins une tranche du réseau de communications RC. Une telle entité d’exécution appartient à un plan de transfert (ou « User Plane », en anglais) du réseau de communications RC, selon la terminologie définie dans la norme ETSI TS 123 501, publiée en septembre 2018. Il s’agit d’un équipement d’accès ou bien d’un équipement nœud du réseau cœur. L’entité d’exécution EXE peut être instanciée sous la forme d’un équipement physique dédié ou non aux fonctions respectives de l’entité d’exécution EXE, ou bien sous forme d’entités virtualisées, comme par exemple des fonctions virtuelles.
Selon l’invention, cette entité d’exécution comprend un dispositif 200 de traitement d’un flux de données émis par une application logicielle d’un équipement terminal UE, IoT dans une dite tranche de réseau. Ce dispositif 200 est configuré pour obtenir un niveau de ressources disponibles pour acheminer le flux de données dans la tranche de réseau, détecter un indicateur de priorité dudit flux dans ledit flux de données, et exécuter au moins une action de traitement dudit flux de données au moins en fonction dudit indicateur de priorité et d’un niveau des ressources réseau disponibles dans ladite tranche de réseau, ladite action de traitement appartenant à un groupe comprenant au moins une première action de blocage du flux de données dans ladite tranche de réseau, destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant et une deuxième action de laisser-passer du flux de données dans ladite tranche de réseau, lorsque le niveau de ressources disponibles est suffisant.
Avantageusement le dispositif 200 est configuré pour obtenir au moins une règle de traitement R_UP d’un flux de données reçu de ladite application logicielle, ladite règle comprenant ledit indicateur de priorité d’un flux de données, ledit identifiant de tranche de réseau et ladite au moins une action de traitement dudit flux, la stocker en mémoire et l’appliquer au traitement du flux de données. Cette règle R_UP est avantageusement stockée dans une mémoire du dispositif 200 ou de l’entité d’exécution EXE.
Le dispositif 200 met ainsi en œuvre le procédé de traitement d’un flux de données selon l’invention qui sera détaillé ci-après en relation avec la .
Le système S comprend également une entité de contrôle CTR du réseau de communications RC, configurée pour contrôler la mise en œuvre d’une politique de traitement de flux de données acheminés dans ledit réseau par une ou plusieurs entités d’exécution. Une telle entité fait partie d’un plan dit de contrôle (ou « control plane », en anglais). Elle peut faire partie du réseau d’accès ou du réseau cœur. Par exemple, dans un réseau d’accès radio, il s’agit d’un élément de gestion de réseau ENM (de l’anglais, « Element Network Manager ») faisant partie d’un système de gestion de réseau NMS (de l’anglais, ‘Network Management System’, associé aux stations de base de 5G/4G, aussi appelées respectivement « gNodeB » ou « eNodeB ». Par exemple, dans un réseau cœur, cette entité de contrôle peut être la fonction SMF (de l’anglais, « Session Management Function ») qui contrôle la fonction UPF (en anglais, « User Plane Function ») à travers l’interface N4 selon la spécification 3GPP TS 23.501. L’entité de contrôle CTR peut être instanciée sous la forme d’un équipement physique dédié ou non aux fonctions respectives du contrôleur CTR, ou bien sous forme d’entités virtualisées.
Selon l’invention, elle comprend un dispositif 300 de contrôle du traitement par l’entité d’exécution EXE d’un flux de données émis par une application logicielle de l’équipement terminal UE, IoT dans une tranche du réseau de communications. Ledit dispositif est configuré pour recevoir, en provenance de l’entité d’exécution une notification d’un indicateur de priorité associé audit flux de données reçu, obtenir un niveau de ressources disponibles pour acheminer le flux de données dans la tranche de réseau, décider d’au moins une action de traitement dudit flux à exécuter, au moins en fonction de l’indicateur de priorité reçu et d’une politique de traitement des flux de données émis par l’application logicielle, ladite action de traitement appartenant à un groupe comprenant au moins une première action de blocage du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant et une deuxième action de laisser-passer du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est suffisant, et envoyer une réponse à ladite entité d’exécution, comprenant ladite au moins une action de traitement.
Avantageusement le dispositif 300 est configuré pour obtenir au moins une règle de contrôle R_CP du traitement d’un flux de données reçu de ladite application logicielle, ladite règle comprenant ledit indicateur de priorité d’un flux de données, ledit identifiant de tranche de réseau et ladite au moins une action de traitement dudit flux, la stocker en mémoire et l’appliquer au contrôle du traitement du flux de données. Cette règle R_CP est avantageusement stockée dans une mémoire du dispositif 300 ou de l’entité de contrôle CTR.
Le dispositif 300 met ainsi en œuvre le procédé de contrôle du traitement d’un flux de données selon l’invention qui sera détaillé ci-après en relation avec la .
Avantageusement, le système S comprend enfin une entité de gestion EMG de la pluralité de tranches du réseau de communication RC. Elle fait partie d’un plan de gestion du réseau de communication RC. Dans le contexte d’une architecture en tranches de réseaux, une telle entité met en œuvre les fonctions de gestion des tranches de réseaux (de l’anglais, « Network Slice Management Functions) telle que décrites dans le document ETSI GR NFV-EVE 012 relatif au support des tranches de réseau en environnement virtualisé, publié en décembre 2017.). L’entité de gestion EMG peut elle aussi être instanciée sous la forme d’un équipement physique dédié ou non aux fonctions respectives de l’entité de gestion, ou bien sous forme d’entités virtualisées.
Selon l’invention, cette entité de gestion comprend un dispositif 400 de gestion de règles, configuré pour obtenir des informations métier d’un client d’une application logicielle destinée à être exécutée par un équipement terminal, lesdites informations comprenant au moins des types de flux de données destinés à être émis par l’application logicielle et des indicateurs de priorité associées à chacun des types de flux, transmettre les règles respectivement à l’équipement terminal, à l’entité d’exécution EXE et à l’entité de contrôle CTR.
Dans la suite, on décrit de façon plus détaillée des modes de réalisation de l’invention dans un réseau de télécommunications mobiles, dont l’architecture est conforme à la version 5G ou une version future de la norme 3GPP et met en œuvre le découpage du réseau en tranches de réseau. Bien sûr, et comme déjà évoqué, l’invention n’est pas limitée aux exemples décrits et s’applique aussi bien à d’autres types de réseaux de télécommunications fixes ou mobiles et à d’autres technologies d’accès, sans fil ou filaires.
On présente désormais, en relation avec la , sous une forme de logigramme, un exemple de mise en œuvre d’un procédé d’émission d’un flux de données reçu d’une application logicielle API_TA, API_JM s’exécutant sur l’équipement terminal UE, IoT, dans le réseau de communications RC, selon un mode de réalisation de l’invention. Avantageusement, le procédé est mis en œuvre par le dispositif 100 intégré dans l’équipement terminal UE, IoT.
Dans la suite, on suppose que le réseau de communications RC est découpé en plusieurs tranches SL_1 à SL_N, avec N supérieur à 2. On s’attache plus particulièrement à décrire le cas où les tranches SL_1 et SL_2 sont dédiées aux usages d’un client donné, lequel met notamment en œuvre les applications logicielles API_TM et API_JM. Ces applications logicielles sont des applications métier spécifiques du client, lequel a défini les différents types de flux de données mis en œuvre et leurs niveaux de priorité associés.
Bien sûr, comme précédemment évoqué, l’invention ne se limite pas à ce cas d’usage, mais s’applique à toute autre stratégie d’affectation des tranches du réseau de communications d’un opérateur à des clients, terminaux, applications logicielles, services, etc. En particulier, selon au moins un autre mode de réalisation de l’invention, l’opérateur définit une tranche de réseau dédiée à l’acheminement des flux de données émis dans le cadre d’un des services qu’il propose à ses clients, comme par exemple le service de Voix sur IP. Dans ce cas, il définit différents types de flux de données de Voix sur IP associés à des niveaux de qualité de service distincts, en lien avec différents niveaux d’abonnements souscrits par les clients (par exemple, or, argent ou bronze) et il leur associe des valeurs d’indicateurs de priorité distinctes, le type de flux de données Voix sur IP « or » étant le plus prioritaire et le type de flux de données Voix sur IP « bronze » étant le moins prioritaire.
Dans une phase préalable, des règles R_UE d’acheminement de flux de données en provenance de cette application logicielle API_TA, API_JM sont reçues en 30, par exemple en provenance de l’entité de gestion EMG. Ces règles permettent d’associer un indicateur de priorité à chaque flux de donnée émis par l’application logicielle API_TA, API_JM.
Typiquement, une telle règle comprend un identifiant de l’application logicielle API_TA, API_JM, un identifiant du type de flux de données STR_ID, un identifiant de la tranche de réseau à utiliser pour émettre le flux de données dans le réseau de communication RC et la valeur de l’indicateur de priorité IP associée. Par exemple, pour l’application métier « Technicien Augmenté », un flux de données de type STR_1, la tranche de réseau SL_1, la structure d’une telle règle est la suivante : « Indicateur de priorité IP - Application logicielle Métier API_TA – Tranche de réseau SL_1 – Type de flux de données STR_1 ». Elles sont stockées dans une mémoire, par exemple une mémoire M1 du dispositif 100 ou une mémoire de l’équipement terminal UE, IoT.
Optionnellement, les règles UE_R reçues en 30 sont associées à un mode opératoire de l’application logicielle API_TA, AP_JM. Par exemple, on compte trois modes opératoires distincts :
- un mode opératoire nominal MO_1, qui correspond à une situation de fonctionnement normale ;
- un mode opératoire d’alarme MO_2, qui correspond à une situation d’alarme ; et
- un mode opératoire post-alarme MO_3, qui correspond à une situation de retour à la normale ou de redémarrage suite à l’alarme.
Le fait de distinguer différents modes opératoires permet de modifier les niveaux de priorité respectifs de chacun des types de flux de données utilisés par une application logicielle à la situation de chacun de ces modes.
Par exemple, l’indicateur peut prendre au moins les valeurs suivantes :
- IP_1, par exemple égal à 1 pour un flux temps-réel de priorité haute ;
- IP_2, par exemple égal à 2, pour un flux non temps-réel ou différé, de priorité haute ;
- IP_3, par exemple égal à 3, pour un flux non temps-réel ou différé, de priorité faible.
On présente ci-après, dans la table 1, un exemple d’affectation de niveaux de priorité aux flux des applications métiers « technicien augmenté » et « jumeau numérique » pour les trois modes opératoires précédemment définis.
Application métier Valeurs de l’indicateur de priorité par type de flux et par mode opératoire
Type de flux Mode opératoire « nominal » Mode opératoire « alarme » Mode opératoire « Post-alarme »
« Technicien Augmenté » Voix sur IP (STR_1) IP_1 IP_1 IP_1
Streaming vidéo (STR_2) IP_2 IP_1 IP_2
Données enrichies (STR_3) IP_3 IP_1 IP_3
« Jumeau Numérique » Voix sur IP (STR_1’) IP_1 IP_1 IP_1
Données de capteurs (STR_2’) IP_3 IP_1 IP_3
[Table 1]
Dans ce cas, les règles UE_R peuvent par exemple comprendre un attribut supplémentaire correspondant au mode opératoire qui leur est associé.
En 31, une information relative à un mode opératoire courant de l’application logicielle API_TA, API_JM est reçue. On suppose ici qu’il s’agit du mode opératoire nominal MO_1.
Dans une phase de fonctionnement, un flux de données STR est reçu en 32 de l’application logicielle API_TA, API_JM. En 33, la tranche de réseau est sélectionnée, à partir d’au moins une information comprise dans un en-tête du flux de données. Par exemple, il s’agit de l’adresse IP dite de destination qui identifie l’équipement qui recevra ce flux de données et/ou d’un identifiant de l’application API_TA, API_JM. Par exemple, cette information est extraite d’un en-tête d’un protocole de signalisation, tel que le protocole NAS (de l’anglais, « Non Access Stratum ») mis en œuvre dans les échanges entre l’équipement terminal et le réseau cœur 5G, et défini par la procédure « 4.16.12.2 UE Policy Association Modification initiated by the PCF » du 3GPP TS 23.502.
En 34, le type de flux de données STR_ID (par exemple voix, streaming vidéo ou échange de données) est obtenu, par exemple à partir du 2-uplet « adresse IP (de destination) ; protocole ID » extrait d’un en-tête du flux ou du triplet d’attributs « adresse IP (de destination), numéro de port, protocole ID ». L’utilisation du triplet d’attributs sert par exemple à différencier plus finement deux flux distincts d’une même application sur la base de leurs numéros de ports distincts.
C’est notamment le cas lorsque cette application est configurée pour transmettre ces flux à un même serveur applicatif, situé en première ligne, mais que ce dernier retransmet chacun d’eux à des serveurs spécialisés distincts, situés en deuxième ligne. Par exemple, pour l’application API_TA « technicien augmenté », un serveur spécialisé dans la reconnaissance de formes reçoit les flux de streaming vidéo, un autre serveur spécialisé dans l’indexation de documentation technique reçoit les flux de données enrichies et encore un autre serveur spécialisé dans les services interpersonnels de mise en relation reçoit les flux de voix sur IP.
En 35, la valeur du mode opératoire courant MO_1 est obtenue, le cas échéant. En 36, la règle UE_R stockée en mémoire correspondant à l’application logicielle API_TA, API_JM qui a émis le flux STR, au type de flux de données STR_ID et éventuellement au mode opératoire courant MO_1 est récupérée, ce qui permet d’obtenir la valeur de l’indicateur de priorité IP associée à ce flux de données STR. En 37, l’indicateur de priorité IP est inséré dans le flux de données STR. Par exemple, il est inséré dans un en-tête du flux de données STR, tel qu’un en-tête du protocole applicatif utilisé par l’application logicielle API_TA, API_JM. Par exemple, l’indicateur de priorité IP est inséré dans une variable d’un en-tête d’une requête HTTP GET. Il peut aussi être inséré dans un en-tête d’un paquet IP, d’une trame Ethernet, ou d’un contexte de réseau 3GPP (PDP context, EPB bearer, PDU session). En variante, il peut également être inséré dans la partie utile d’un tel paquet, trame ou contexte du flux de données STR.
En 38, le flux de données STR ainsi modifié est transmis dans la tranche de donnée SL_1 du réseau de communication RC.
On comprend que, suite à un changement du mode opératoire, la valeur de l’indicateur de priorité à insérer dans le prochain flux de données émis par l’application logicielle API_TA, API_JM est mise à jour et devient celle associée au nouveau mode opératoire courant.
On présente désormais, en relation avec la , sous une forme de logigramme, un exemple de mise en œuvre d’un procédé de traitement d’un flux de données reçu d’une application logicielle API_TA, API_JM s’exécutant sur l’équipement terminal UE, IoT, dans une tranche SL_1 de réseau de communications RC, selon un mode de réalisation de l’invention. Avantageusement, ce flux de données STR est reçu par une entité d’exécution EXE du plan de transfert UP du réseau de communications RC et le procédé est mis en œuvre par le dispositif 200 intégré dans cette entité d’exécution EXE configurée pour gérer au moins la tranche de réseau SL_1 du réseau RC. Si le réseau RC est un réseau de communications mobiles conforme à la 5G, il s’agit par exemple d’un équipement du réseau d’accès radio RAN, par exemple, dans une architecture O-RAN, cet équipement peut être celui implémentant la fonction O-CU-UP (« O-RAN Central Unit – User Plane » en anglais [O-RAN]), ou un équipement du cœur de réseau.
Avantageusement, on suppose ici que l’entité d’exécution EXE est configurée pour gérer les tranches SL_1 et SL_2 du réseau RC.
En 40, le flux de données STR est reçu. En 41, un indicateur de priorité IP est détecté le flux de données, par exemple dans un en-tête ou dans une partie utile de ce flux de données.
En 42, une évaluation d’un niveau de ressources NRS_1 disponibles pour acheminer le flux de données STR dans la tranche de réseau SL_1 est obtenue. Cette évaluation peut être mise en œuvre localement ou obtenue d’un équipement distant, par exemple un autre équipement du plan de transfert. L’entité d’exécution EXE a connaissance des ressources dont elle dispose et qu’elle peut utiliser pour chaque tranche de réseau SL dont elle a la charge. En effet, dans une architecture 5G, lors de la mise en œuvre des tranches de réseau, le plan de gestion configure chacun des équipements réseaux d’accès et de cœur en fonction des caractéristiques de chaque tranche. Ces caractéristiques incluent notamment la bande passante allouée à chaque tranche.
Ensuite, chaque règle de traitement R_UP précise la bande passante nécessaire pour le fonctionnement correct de chaque type de flux de données susceptible d’être émis par l’application métier API_TA, API_JM considérée.
Enfin, l’entité d’exécution EXE évalue si les ressources disponibles pour une tranche SL donnée sont suffisantes pour assurer l’acheminement du flux de données reçu compte tenu de la valeur de l’indicateur de priorité IP qui lui est associé. Pour ce faire, elle compare la quantité de ressources nécessaire pour acheminer le flux reçu à la quantité de ressources disponible. Il s’agit par exemple d’un nombre de PRB au niveau d’un réseau d’accès radio, d’un débit en kbits/s ou Mbits/s pour le cœur de réseau.
On note que si plusieurs flux de données sont reçus en même temps, leur traitement peut avantageusement être hiérarchisé en fonction de leur niveau de priorité associé. Par exemple, les flux temps réel sont priorisés par rapport aux flux non temps réel.
Si besoin, un deuxième niveau de priorisation peut être appliqué, dans le cas où plusieurs flux temps-réel utilisent la même tranche de réseau et sont reçus en même temps par l’entité d’exécution EXE, par exemple en traitant d’abord les flux temps-réel haute priorité par rapport aux flux temps-réel basse priorité. C’est le cas notamment pour une application « Voix sur IP » de l’opérateur qui distingue des flux de données VoIP prioritaires et des flux de données VoIP non prioritaires. On note qu’il est possible de faire de même pour des flux non temps-réel, en distinguant des flux non temps réel à haute priorité par rapport à des flux non temps-réel à plus faible priorité. Dans ce cas, on note que les flux temps-réel basse priorité resteront prioritaires sur les flux non-temps réel et notamment sur les flux non temps-réel à haute priorité.
En 43, une action de traitement AC à exécuter pour traiter l’acheminement de ce flux de données est obtenue. En 44, l’action de traitement AC est exécutée.
Selon l’invention, l’action de traitement AC peut être obtenue par l’entité d’exécution EXE de différentes façons, qui vont maintenant être détaillées.
Selon un premier mode de réalisation de l’invention, illustré par la , au moins une règle de traitement R_UP du flux de données STR reçu en provenance de l’application logicielle API_TA, API_JM est obtenue en 430. On suppose par exemple qu’un ensemble de règles a été reçu de l’entité de gestion EGM dans une phase de configuration préalable non représentée. De telles règles indiquent l’action de traitement AC à exécuter pour le flux de données STR. Avantageusement, une telle règle de traitement R_UP comprend un identifiant de l’application logicielle API_TA, API_JN, un identifiant du type de flux de données STR_1, un identifiant de la tranche de réseau SL_1 à utiliser pour émettre le flux de données dans le réseau de communication RC, la valeur de l’indicateur de priorité IP_1 associée et un identifiant de l’action AC à exécuter.
Par exemple, la mémoire en question est organisée comme une base de données et la règle de traitement à appliquer au flux de données STR reçu est obtenue en interrogeant la base de données à l’aide de l’identifiant de l’application logicielle et/ou de l’identifiant du flux de données et de l’indicateur de priorité détecté dans le flux.
Avantageusement, l’action de traitement AC peut prendre au moins l’une des deux valeurs suivantes :
- laisser passer (AC1, par exemple égal à 1) le flux de données et le transférer dans la tranche de réseau SL_1 ;
- bloquer (AC2, par exemple égal à 2) le flux de données STR et le supprimer de la tranche de réseau SL_1.
On comprend que les actions AC_1, AC_2 sont les deux actions de base à exécuter en 44. Elles présentent l’avantage d’être simples à mettre en œuvre, sur la base de règles simples, du fait qu’elles reposent sur une prise de décision binaire. Bien sûr, d’autres actions peuvent être prises en considération pour mettre en œuvre une stratégie enrichie, lorsque les ressources sont évaluées comme insuffisantes. Par exemple, une autre action possible serait d’accélérer ou retarder le transfert du flux de données STR ou lui affectant moins ou plus de ressources, ou encore de limiter ou écrêter le flux de données avant de le transmettre pour s’adapter aux ressources disponibles. Dans le cas où deux flux de même priorité sont reçus simultanément, on pourrait ainsi les transférer tous les deux en affectant moins de ressources à chacun.
En 431, l’action de traitement AC est extraite de la règle R_UP obtenue, puis mise en application en 44.
Selon ce premier mode de réalisation, l’entité d’exécution EXE a donc été préalablement configurée pour décider localement de l’action de traitement à exécuter.
Avantageusement, elle peut avoir reçu préalablement une première règle de traitement R_UP0 lui indiquant si elle devait décider localement de l’action de traitement à exécuter ou si elle devait notifier une autre entité du réseau de communication RC.
En variante, elle peut simplement rechercher en mémoire si elle dispose d’une règle R_UP pour l’application logicielle d’où provient le flux de données reçu et pour l’indicateur de priorité IP détecté. Si aucune règle R_UP correspondante n’est trouvée, alors elle notifie une autre entité ou bien elle applique une règle par défaut R_UP_D qui définit l’action de traitement à exécuter pour un flux de données issu de l’application logicielle considérée ou de toutes les applications logicielles du client de la tranche de réseau SL_1, associé au niveau de priorité IP_3 le plus faible.
Selon un deuxième mode de réalisation de l’invention illustré par la , on considère que l’entité d’exécution EXE est configurée pour notifier une autre entité du réseau de communications RC. Avantageusement, il s’agit d’une entité de contrôle CTR du plan de contrôle du réseau RC, configurée pour contrôler la mise en œuvre d’une politique de traitement des flux de données acheminés dans ledit réseau RC. Par exemple, la première règle R_UP0 identifie cette entité de contrôle CTR à notifier et les informations à lui transmettre.
En 430’ (de la ), l’entité d’exécution obtient cette première règle R_UP0 et en extrait donc l’identité de l’entité de contrôle à notifier.
En 431’, elle notifie à l’entité de contrôle CTR qu’elle a reçu le flux de données STR, associé à l’indicateur de priorité IP dans la tranche de réseau SL_1. On note qu’elle peut déclencher cette notification suite à la détection de l’indicateur de priorité IP dans le flux de données STR, c’est-à-dire notifier systématiquement l’entité de contrôle CTR dans un message comprenant un seul indicateur de priorité associé à un seul flux de données reçu, ou, en variante, transmettre un seul message de notification NTF à l’expiration d’une période temporelle donnée regroupant les indicateurs de priorité détectés dans des flux de données reçus sur la tranche de réseau SL_1 pendant cette période.
En 432’, elle reçoit en retour l’action de traitement à exécuter. Par exemple, il s’agit d’une des deux actions AC_1, AC_2 précédemment évoquées ou bien selon la stratégie enrichie, d’une autre action, par exemple de retard ou d’accélération du transfert du flux de données STR ou encore de limitation ou d’écrêtage du flux de données avant transfert. En 44, elle exécute l’action de traitement reçue.
Selon ce deuxième mode de réalisation de l’invention, c’est donc le plan de contrôle qui applique les règles de traitement des flux de données en fonction des indicateurs de priorités associés à ces flux.
On présente désormais, en relation avec la , sous une forme de logigramme, un exemple de mise en œuvre d’un procédé de contrôle d’un flux de données reçu d’une application logicielle API_TA, API_JN dans une tranche de réseau SL1 du réseau de communications, selon ce deuxième mode de réalisation de l’invention. Avantageusement, le procédé est mis en œuvre par le dispositif 300 intégré dans l’entité de contrôle CTR du plan de contrôle du réseau de communication RC.
En 50, une notification NTF est reçue par l’entité de contrôle CTR en provenance de l’entité d’exécution EXE du plan de transfert du réseau de communications RC. Elle concerne un flux de données STR reçu par cette entité d’exécution EXE et comprend au moins un identifiant du type de flux de données STR_1, un indicateur de priorité IP_1 associé et l’identifiant de la tranche de réseau SL_1. Par exemple, cette notification est transmise à l’entité de contrôle dans un message conforme à un protocole de type radius, diameter ou http/2. Dans le cas d’une architecture basée service ou SBA (de l’anglais, « Service Based Architecture ») pour la 5G, c’est le protocole http/2 qui est utilisé.
En 51, l’entité de contrôle CTR obtient une évaluation d’un niveau de ressources disponibles dans la tranche de réseau SL_1 Par rapport au besoin de ressources pour transmettre le flux de données STR reçu dans les conditions prévues pour le niveau de priorité qui lui est associé, les mécanismes mis en œuvre sont similaires à ceux décrits pour l’étape 42 et ne seront pas détaillés plus avant.
Dans le réseau d’accès d’une architecture 5G mettant en œuvre une implémentation de type O-RAN, l’entité ou fonction de contrôle CTR récupère les informations de ressources disponibles pour chaque tranche de réseau à partir de la fonction O-CU-CP.
Dans le réseau cœur, l’entité ou fonction de contrôle CTR récupère ces informations de ressources disponibles auprès d’une fonction de gestion de session SMF (de l’anglais « Session Mangement Function ») qui contrôle la fonction de plan de transfert UPF (de l’anglais, « User Plane Function ») correspondant à l’entité ou fonction d’exécution EXE en question, via l’interface N4 telle que définie par le 3GPP dans la spécification TS23.501 (section 5.8.2.11 « Parameters for N4 session management »)
En 52, elle obtient une règle de contrôle R_CP des flux de données acheminés sur la tranche de réseau SL_1 et associés à l’indicateur de priorité IP reçu. Avantageusement, on suppose qu’un ensemble de règles R_CP a été reçu de l’entité de gestion EMG dans une phase de configuration préalable non représentée. De telles règles indiquent l’action de traitement AC à exécuter pour le flux de données STR en fonction de la valeur de son indicateur de priorité associé. Avantageusement, une telle règle de contrôle R_CP comprend un identifiant de la tranche de réseau SL_1, la valeur de l’indicateur de priorité IP_1 et un identifiant de l’action AC à exécuter.
On comprend que cette règle de contrôle R_CP est très proche dans sa structure et son contenu d’une règle de traitement R_UP. Une différence est que les règles de contrôle R_CP peuvent être plus complexes car l’entité ou fonction de contrôle CTR dispose généralement d’une vision plus large sur le domaine dont elle a la responsabilité que l’entité ou fonction d’exécution EXE qui n’a connaissance que de ses propres ressources et donc un périmètre d’action limité à sa fonction.
Par exemple, la mémoire en question est organisée comme une base de données et la règle de contrôle R_CP à appliquer à la notification NTF reçue est obtenue en interrogeant la base de données à l’aide de l’identifiant de la tranche de donnée SL_1 et de l’indicateur de priorité IP reçu dans la notification.
En 53, l’action de traitement AC est extraite de la règle reçue, puis en 54 une réponse est transmise à l’entité d’exécution dans un message comprenant au moins l’action de traitement AC. Par exemple, ce message est conforme au format JSON et il est envoyé selon le protocole http/2.
On présente désormais, en relation avec la , sous une forme de logigramme, un autre mode de réalisation de l’invention mis en œuvre lorsque l’action de traitement décidée pour le flux de données STR est de bloquer ce flux dans la tranche de réseau SL_1. En particulier, on décrit ci-après un mécanisme qui peut être mis en œuvre soit au niveau de l’entité d’exécution EXE dans le cadre du procédé de traitement d’un flux de données qui vient d’être décrit en relation avec la , soit au niveau de l’entité de contrôle CTR dans le cadre du procédé de contrôle du traitement d’un flux de données qui vient d’être décrit en relation avec la .
Le mécanisme en question est donc déclenché suite à l’obtention 43 de l’action AC au niveau de l’entité d’exécution EXE lorsque cette action est une action AC2 de blocage du flux de données dans la tranche de réseau SL_1 ou plus généralement, lorsque les ressources disponibles sont évaluées comme insuffisantes et qu’une action de limitation du flux ou de retard du transfert du flux a été prise, ou encore suite à la décision 53 d’exécuter cette action AC au niveau de l’entité de contrôle CTR.
En 60, il est vérifié s’il existe une autre règle de traitement R_UP_FK ou de contrôle R_CP_FK pour un flux de données de l’application logicielle API_TA, API_JM, associé à l’indicateur de priorité IP dans la tranche de réseau SL_1, qui prévoit une troisième action de traitement AC_3 consistant à transférer le flux de données bloqué dans une autre tranche de réseau SL_2 accessible au client de l’application logicielle considérée. Par exemple, cette règle supplémentaire, qu’on appelle règle de repli, est obtenue en interrogeant la base de données de la mémoire locale, comme précédemment décrit.
On suppose d’abord que cette règle de repli n’est pas disponible. Dans ce cas, l’action de traitement à exécuter reste l’action AC2 de blocage donc de suppression du flux de données de la tranche de réseau SL_1 ou de limitation du flux suivant les ressources disponibles pour l’acheminement.
Lorsqu’au contraire cette règle de repli est disponible pour le flux de données courant, alors on évalue en 61 la disponibilité des ressources dans une autre tranche de réseau accessible au client de l’application logicielle, ici la tranche SL_2. Une quantité de ressources disponibles est obtenue puis comparée à un seuil minimum TH donné ou aux besoins en ressources pour l’acheminement du flux de données STR en 62. Si cette autre tranche de réseau SL_2 dispose de ressources suffisantes et/ou de plus de ressources disponibles que la tranche de réseau SL_1 pour acheminer le flux de données STR, c’est-à-dire si la quantité de ressources évaluée est supérieure ou égale au seuil TH, alors le flux de données STR est transféré dans l’autre tranche de réseau SL_2.
Avantageusement, une telle règle de repli R_UP_FK, R_CP_FK est associée aux indicateurs de priorité correspondant à des niveaux de priorité élevée. Par exemple, pour l’application logicielle API_TA, AP_JN, seuls les flux de données associés à un indicateur de priorité IP_1 peuvent bénéficier de cette solution de repli vers une autre tranche de réseau SL_2. Lorsque des modes opératoires sont mis en œuvre, on note que ce sont les seuls flux de données de type STR_1 en mode nominal MO_1 qui peuvent bénéficier de la solution de repli, mais qu’en revanche tous les types de flux STR_1, STR_2 et STR_3 en mode alarme MO2 peuvent en bénéficier.
Ce mécanisme présente donc l’avantage d’offrir une chance supplémentaire à un flux de données prioritaire d’être acheminé lorsque les ressources du plan de transfert UP ne sont pas suffisantes dans la tranche de réseau SL_1 sélectionnée pour l’application qui l’a émis.
Il s’articule avec les deux modes de réalisation précédemment décrits de la façon suivante :
- dans le cas du premier mode de réalisation, selon lequel l’entité d’exécution EXE décide localement de l’action à exécuter en appliquant des règles de traitement obtenues au préalable de l’entité de gestion EMG, le mécanisme de repli qui vient d’être décrit peut soit être exécuté localement lui aussi sur la base d’une règle de repli R_UP_FK pourvu que l’entité d’exécution soit en charge de gérer au moins deux tranches de réseau SL_1, SL_2 accessibles à l’application logicielle concernée, soit la décision de bloquer le flux de données STR ou encore de limiter le flux de données STR, déclenche l’émission d’une notification à destination de l’entité de contrôle CTR pour qu’elle mette en œuvre le mécanisme de repli en question. Par exemple, la notification comprend l’indicateur de priorité, l’identifiant de l’application logicielle API_TA, API_JN, l’identifiant de la tranche de réseau sélectionnée SL_1. A réception, l’entité de contrôle CTR met en œuvre le mécanisme de repli et répond à la notification en transmettant soit une confirmation de l’action de blocage (ou limitation de l’acheminement) AC_2 soit l’action de transfert AC_3 en précisant la tranche de réseau SL_2 vers laquelle transférer le flux de données ;
- dans le cas du deuxième mode de réalisation, selon lequel l’entité d’exécution EXE notifie l’entité de contrôle CTR dont elle dépend de l’indicateur de priorité détecté dans le flux de données STR qu’elle a reçu, et de la tranche de réseau SL_1 dans laquelle elle l’a reçu, le mécanisme de repli est avantageusement mis en œuvre par l’entité de contrôle CTR suite à la décision 52 de faire exécuter à l’entité EXE la décision AC_2 de blocage du flux de données STR. De la sorte, l’entité de contrôle envoie uniquement l’action de transfert AC_3 dans sa réponse à la notification NTF de l’entité d’exécution EXE, associée à la tranche de réseau SL_2 vers laquelle ce transfert doit être réalisé.
On présente maintenant, en relation avec la , un exemple d’architecture d’un réseau de communications RC mettant en œuvre l’invention. Il comprend un plan de gestion MP, un plan de transfert UP et un plan de contrôle CP. Le plan de gestion MP comprend une pluralité d’entités de gestion EMG_1, EMG_2, EMG_3 configurées pour définir des règles d’acheminement, de traitement et de contrôle de flux de données dans les différentes tranches SL_1, SL_2 du réseau RC. En particulier, les entités de gestion sont configurées pour transmettre des règles d’acheminement de flux de données à des équipements terminaux UE, IoT connectés au réseau RC, des règles de traitement à une pluralité d’entités d’exécution EXE_1, EXE_2, EXE_3 du plan de transfert UP, et des règles de contrôle à une pluralité d’entités de contrôle CTR_1, CTR_2, CTR_3 du plan de contrôle CP du réseau RC.
Ces règles permettent de décider, en fonction d’un niveau de ressources disponibles dans une tranche de réseau et d’un niveau de priorité de ce flux, si un flux de données peut être acheminé ou s’il doit être bloqué.
Certaines de ces entités d’exécution peuvent être configurées pour gérer plusieurs tranches SL_1, SL_2 du réseau RC, d’autres une seule. Celles qui sont configurées pour gérer au moins deux tranches du réseau RC pourront mettre en œuvre le mécanisme de repli décrit en relation avec la et l’appliquer aux flux de données les plus prioritaires.
Comme précédemment décrit, ce mécanisme de repli peut, en variante, être mis en œuvre par des entités de contrôle CTR_1, CTR_2, CTR_3 lorsque les entités d’exécution qu’elles contrôlent gèrent au moins deux tranches de réseau. Par exemple, l’entité d’exécution EXE_1 détecte un mode opératoire « alarme » et en informe l’entité de contrôle CTR_1 qui gère l’entité EXE_1. Cette entité CTR_1 peut alors décider de dupliquer les flux vers une autre tranche de réseau SL_2 qui est contrôlée par une entité d’exécution EXE_1’ (non représentée) pour le plan de transfert et par cette même entité CTR_1 pour le plan de contrôle.
Les entités d’exécution du plan transfert sont placés le long du chemin ou de la route empruntée par un flux de données STR émis par l’équipement terminal UE, IoT vers sa destination. On comprend donc que chacune d’entre elles est configurée pour mettre en œuvre le procédé de traitement d’un flux de données qui vient d’être décrit sous le contrôle de l’entité de contrôle CTR_1, CTR_2, CTR_3 dont elle dépend.
On note que l’invention s’applique également dans un contexte multi-opérateurs et que de ce fait, certaines entités d’exécution ou de contrôle peuvent être configurées pour avoir une connaissance des ressources d’une tranche de réseau d’un autre opérateur et prendre une décision de transfert d’un flux de données vers cette tranche de réseau. Par exemple, l’entité de contrôle qui prend la décision relative à l’acheminement du flux de données peut recevoir des informations relatives à un niveau de ressources disponibles dans cette tranche de réseau d’un autre opérateur de la part d’une entité de contrôle gérée par cet autre opérateur.
On présente désormais, en relation avec la , un exemple de structure matérielle d’un dispositif 100 d’émission d’un flux de données dans un réseau de télécommunications, auquel est connecté un équipement terminal, ledit réseau étant découpé en une pluralité de tranches de réseau, ledit dispositif comprenant un module de sélection d’une tranche de réseau de ladite pluralité au moins en fonction de l’identifiant de l’application logicielle, un module d’obtention d’un type dudit flux, ledit type appartenant à un groupe comprenant au moins un premier type et un deuxième type de flux, et un module d’insertion d’un indicateur de priorité associé au type de flux dans un en-tête du flux de données, l’indicateur de priorité appartenant à un groupe comprenant au moins un premier indicateur associé au premier type de flux et un deuxième indicateur associé au deuxième type de flux, le premier indicateur et le deuxième indicateur de priorité ayant des valeurs distinctes et un module d’émission du flux de données dans la tranche de réseau sélectionnée.
Avantageusement, le dispositif 100 comprend un module de réception d’au moins une règle d’acheminement d’un flux de données pour ladite application logicielle, ladite règle comprenant au moins un identifiant de ladite application logicielle, ledit type de flux, ledit indicateur de priorité associé audit type de flux et un identifiant d’une dite tranche de réseau; un module de stockage en mémoire de ladite au moins une règle de traitement , les modules de sélection et d’insertion étant configurés pour appliquer ladite au moins une règle. Avantageusement, le dispositif 100 comprend aussi un module d’obtention d’un mode opératoire de ladite application logicielle, ledit mode opératoire appartenant à un groupe comprenant au moins un premier mode opératoire et un deuxième mode opératoire, ladite au moins une règle d’acheminement étant associée audit mode opératoire.
Le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions.
Plus généralement, un tel dispositif 100 comprend une mémoire vive 103 (par exemple une mémoire RAM), une unité de traitement 102 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg1, représentatif des modules de sélection, d’obtention, d’insertion, de réception, de stockage, stocké dans une mémoire morte 101 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 103 avant d'être exécutées par le processeur de l'unité de traitement 102. La mémoire vive 103 peut aussi contenir par exemple l’identifiant de l’application logicielle, le type de flux de données et le mode opératoire obtenus.
La illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 100 afin qu’il effectue les étapes du procédé d’émission d’un flux de données tel que détaillé ci-dessus, en relation avec la , dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où le dispositif 100 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
Les différents modes de réalisation ont été décrits ci-avant en relation avec un dispositif 100 intégré dans un équipement terminal connecté à un réseau de communications RC, mais il peut aussi être intégré dans un équipement d’accès à ce réseau, par exemple une passerelle de connectivité qui intègre ce dispositif 100. Une telle passerelle de connectivité sert généralement d’interface entre des modules IoT dit légers (c’est-à-dire dotés d’une faible capacité de traitement embarqué) et le réseau de communications RC. Elle est par exemple mise en œuvre pour la gestion de l’énergie. Des capteurs IoT remontent des données de mesures de consommation d’énergie d’usagers à une passerelle de connectivité, qui est typiquement configurée pour agréger une dizaine de capteurs IoT.
On présente ensuite, en relation avec la , un exemple de structure matérielle d’un dispositif 200 de traitement d’un flux de données reçu dans un réseau de télécommunications, ledit réseau étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été reçu d’une application logicielle s’exécutant sur un équipement terminal connecté audit réseau dans une dite tranche de réseau de ladite pluralité, ledit dispositif comprenant un module d’obtention d’une évaluation d’un niveau de ressources disponibles dans la tranche de réseau , un module de détection d’un indicateur de priorité dans un en-tête dudit flux de données et un module d’exécution d’au moins une action de traitement dudit flux de données au moins en fonction dudit indicateur de priorité et du niveau de ressources réseau disponibles dans ladite tranche de réseau, ladite action de traitement appartenant à un groupe comprenant au moins une première action de laisser-passer du flux de données dans ladite tranche de réseau, lorsque le niveau de ressources disponibles est suffisant et une deuxième action de blocage du flux de données dans ladite tranche de réseau, destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant.
Avantageusement, le dispositif 200 comprend un module d’obtention préalable d’au moins une règle de traitement d’un flux de données reçu de ladite application logicielle, ladite règle comprenant ledit indicateur de priorité d’un flux de données, ledit identifiant de tranche de réseau et ladite au moins une action de traitement dudit flux, et un module d’extraction (de l’action de traitement de ladite règle). Avantageusement, ledit dispositif comprend aussi un module de notification dudit indicateur de priorité à une entité de contrôle dudit réseau, configuré pour être mis en œuvre lorsqu’aucune règle de traitement n’a été préalablement obtenue pour traiter ledit flux de données, et un module de réception, en provenance de ladite entité de contrôle, de ladite au moins une action de traitement à exécuter. Avantageusement, le dispositif 200 comprend enfin un module d’obtention d’une évaluation d’un niveau de ressources dans une autre tranche de réseau et un module de décision d’au moins une troisième action de traitement, dite action de transfert du flux de données, en fonction dudit niveau de ressources (et de l’indicateur de priorité, en remplacement de la deuxième action de traitement). Ces modules sont configurés pour être mis en œuvre lorsque l’entité d’exécution étant configurée pour gérer la tranche de réseau et ladite au moins une autre tranche de réseau dudit réseau de communication et lorsque l’action de traitement est la deuxième action de blocage du flux de données dans la tranche de réseau.
Le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions.
Plus généralement, un tel dispositif 200 comprend une mémoire vive 203 (par exemple une mémoire RAM), une unité de traitement 202 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg2, représentatif des modules précités, stocké dans une mémoire morte 201 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 203 avant d'être exécutées par le processeur de l'unité de traitement 202. La mémoire vive 203 peut aussi contenir par exemple l’identifiant de l’application logicielle, l’indicateur de priorité, la tranche de réseau, le niveau de ressources évalué pour la tranche de réseau, le type de flux de données obtenus. Elle peut comprendre aussi les règles de traitement préalablement reçues, le ou les niveaux de ressources évalués pour la ou les tranches de réseau, le ou les seuils de décision mis en œuvre pour décider si le ou les niveaux de ressources évalués sont suffisants pour acheminer le flux de données.
La illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 200 afin qu’il effectue les étapes du procédé de contrôle du traitement d’un flux de données tel que détaillé ci-dessus, en relation avec les figures 4, 4A, 4B et 6, dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où le dispositif 200 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
Les différents modes de réalisation ont été décrits ci-avant en relation avec un dispositif 200 intégré dans une entité d’exécution du réseau de communications RC, par exemple un équipement nœud du réseau d’accès, par exemple une station de base d’un réseau d’accès radio mobile ou un équipement routeur du réseau cœur.
On présente enfin, en relation avec la , un exemple de structure matérielle d’un dispositif 300 de contrôle du traitement d’un flux de données reçu dans un réseau de télécommunications, ledit réseau étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été émis par un équipement terminal et reçu par une entité d’exécution dudit réseau dans une tranche de réseau de ladite pluralité, ledit dispositif comprenant un module de réception en provenance de l’entité d’exécution d’une notification d’un indicateur de priorité (IP) associé audit flux de données reçu, un module d’obtention d’un niveau de ressources disponibles dans la tranche de réseau, un module de décision d’au moins une action de traitement dudit flux au moins en fonction de l’indicateur de priorité reçu et du niveau de ressources disponibles, et un module d’envoi d’une réponse à ladite entité d’exécution, ladite réponse comprenant ladite action de traitement.
Avantageusement, le dispositif 300 comprend un module d’obtention préalable d’au moins une règle de contrôle du traitement d’un flux de données reçu de ladite application logicielle, ladite règle comprenant ledit indicateur de priorité d’un flux de données, ledit identifiant de tranche de réseau et ladite au moins une action de traitement dudit flux, et un module de stockage de ladite au moins une règle en mémoire. Avantageusement, ledit dispositif 300 comprend aussi un module d’obtention d’un niveau de ressources disponibles dans une autre tranche de réseau, un module de décision d’au moins une troisième action de traitement, dite action de transfert du flux de données, en fonction dudit niveau de ressources et de l’indicateur de priorité, en remplacement de la deuxième action de traitement. Ces modules sont configurés pour être mis en œuvre préalablement à la transmission de la deuxième action de traitement à l’entité d’exécution, lorsque l’action de traitement décidée est l’action de blocage dudit flux de données dans la tranche de réseau et lorsque l’entité d’exécution est configurée pour gérer une autre tranche de réseau de ladite pluralité.
Le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions.
Plus généralement, un tel dispositif 300 comprend une mémoire vive 303 (par exemple une mémoire RAM), une unité de traitement 302 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg3, représentatif des modules précités, stocké dans une mémoire morte 301 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 303 avant d'être exécutées par le processeur de l'unité de traitement 302. La mémoire vive 303 peut aussi contenir par exemple les règles de contrôle préalablement reçues, l’identifiant de l’application logicielle, l’indicateur de priorité, la tranche de réseau, le niveau de ressources évalué pour la tranche de réseau, le type de flux de données obtenus. Elle peut comprendre aussi le niveau de ressources évalué pour l’autre tranche de réseau, le ou les seuils de décision mis en œuvre pour décider si le ou les niveaux de ressources évalués sont suffisants pour acheminer le flux de données.
La illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le dispositif 300 afin qu’il effectue les étapes du procédé de contrôle du traitement d’un flux de données tel que détaillé ci-dessus, en relation avec les figures 5 et 6, dans ses différents modes de réalisation. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où le dispositif 300 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une carte SD, une clé USB, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
Les différents modes de réalisation ont été décrits ci-avant en relation avec un dispositif 300 intégré dans une entité de contrôle du réseau de communications RC, par exemple un équipement de contrôle du réseau d’accès ou un équipement de contrôle du réseau cœur. Par exemple, ce dispositif 300 est implémenté dans une entité fonctionnelle O-CU-CP d’un réseau d’accès mobile suivant les spécifications O-RAN. S’agissant du réseau cœur mobile, ce dispositif 300 peut être implémenté dans une entité fonctionnelle SMF suivant les spécifications 3GPP de l’architecture 5G.

Claims (15)

  1. Procédé d’émission d’un flux de données reçu d’une application logicielle s’exécutant sur un équipement terminal (UE, IoT), dans un réseau de communications (RC) auquel est connecté ledit équipement terminal, ledit réseau étant découpé en une pluralité de tranches de réseau (SL_1, SL_2) , caractérisé en ce que ledit procédé est mis en œuvre au niveau dudit équipement terminal et comprend
    - la sélection (33) d’une tranche de réseau (SL_1) de ladite pluralité au moins en fonction d’une information comprise dans un en-tête du flux de données,
    - l’obtention (34) d’un type dudit flux, ledit type appartenant à un groupe comprenant au moins un premier type (STR_1) et un deuxième type de flux (STR_2), et
    - l’insertion (37) d’un indicateur de priorité (IP) associé au type de flux (STR_ID) dans le flux de données, l’indicateur de priorité appartenant à un groupe comprenant au moins un premier indicateur (IP_1) associé au premier type de flux (STR_1) et un deuxième indicateur (IP_2) associé au deuxième type de flux (STR_2), le premier indicateur et le deuxième indicateur de priorité ayant des valeurs distinctes ;
    -l’émission (38) du flux de données comprenant l’indicateur de priorité dans la tranche de réseau (SL_1) sélectionnée.
  2. Procédé d’émission d’un flux de données selon la revendication 1, caractérisé en ce qu’il comprend :
    - la réception préalable (30) d’au moins une règle d’acheminement (R_UE) d’un flux de données émis par ladite application logicielle, ladite règle comprenant au moins un identifiant de ladite application logicielle, ledit type de flux, ledit indicateur de priorité (IP) associé audit type de flux et un identifiant (SL_1) d’une dite tranche de réseau;
    - le stockage en mémoire de ladite au moins une règle d’acheminement et
    - l’application de ladite au moins une règle d’acheminement lors de la mise en œuvre de ladite sélection (33) et de ladite insertion (37).
  3. Procédé d’émission d’un flux de données selon la revendication 2, caractérisé en ce qu’il comprend en outre l’obtention (35) d’un mode opératoire de ladite application logicielle, ledit mode opératoire appartenant à un groupe comprenant au moins un premier mode opératoire (MO_1) et un deuxième mode opératoire (MO_2), et en ce que ladite au moins une règle d’acheminement est associée audit mode opératoire.
  4. Procédé de traitement d’un flux de données (STR) dans un réseau de communication (RC), ledit réseau étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été reçu dans une dite tranche de réseau de ladite pluralité en provenance d’une application logicielle s’exécutant sur un équipement terminal (UE, IoT) connecté à audit réseau, caractérisé en ce que le procédé est mis en œuvre par une entité d’exécution (EXE) du réseau et en ce qu’il comprend :
    - la détection (41) d’un indicateur de priorité (IP) dudit flux dans un ledit flux de données ;
    - l’évaluation (42) d’un niveau de ressources disponibles dans la tranche de réseau  ;
    - l’exécution (44) d’au moins une action de traitement (AC) dudit flux de données au moins en fonction dudit indicateur de priorité (IP) et du niveau (NRS_1)de ressources réseau disponibles dans ladite tranche de réseau (SL_1), ladite action de traitement (AC) appartenant à un groupe comprenant au moins une première action (AC_1) de laisser-passer du flux de données dans ladite tranche de réseau, lorsque le niveau de ressources disponibles est suffisant pour acheminer le flux de données selon l’indicateur de priorité (IP) et une deuxième action (AC_2) de blocage du flux de données dans ladite tranche de réseau, destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant.
  5. Procédé de traitement d’un flux de données selon la revendication précédente, caractérisé en ce qu’il comprend l’obtention préalable (430) d’au moins une règle de traitement (R_UP) d’un flux de données reçu de ladite application logicielle, ladite règle comprenant ledit indicateur de priorité (IP) d’un flux de données, ledit identifiant de tranche de réseau (SL_1) et ladite au moins une action de traitement (AC) dudit flux, et l’extraction (431) de l’action de traitement de ladite règle.
  6. Procédé de traitement d’un flux de données selon la revendication 4, caractérisé en ce que, lorsqu’aucune règle de traitement n’a été préalablement obtenue pour traiter ledit flux de données, ledit procédé comprend en outre la notification (431’) dudit indicateur de priorité à une entité de contrôle (CTR) dudit réseau et la réception (432’), en provenance de ladite entité de contrôle, de ladite au moins une action de traitement à exécuter.
  7. Procédé de traitement d’un flux de données selon l’une quelconque des revendications 4 à 6, caractérisé en ce que, l’entité d’exécution étant configurée pour gérer la tranche de réseau (SL_1) et au moins une autre tranche de réseau (SL_2) dudit réseau de communication (RC), lorsque l’action de traitement est la deuxième action (AC_2) de blocage du flux de données dans la tranche de réseau (SL_1), le procédé comprend, préalablement à l’exécution de la deuxième action de traitement :
    - l’évaluation (60) d’un niveau de ressources (NRS_2) dans l’autre tranche de réseau (SL_2) ;
    - la décision (61) d’au moins une troisième action de traitement, dite action de transfert (AC_3) du flux de données dans l’autre tranche de réseau (SL_2), en fonction dudit niveau de ressources (NRS_2) et de l’indicateur de priorité (IP).
  8. Procédé de contrôle du traitement d’un flux de données (STR) dans un réseau de communications, ledit réseau de communications étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été émis par un équipement terminal (UE, IoT) et reçu par une entité d’exécution (EXE) dudit réseau dans une tranche de réseau (SL_1) de ladite pluralité, caractérisé en ce que ledit procédé est mis en œuvre par une entité de contrôle (CTR) dudit réseau, ladite entité de contrôle étant configurée pour contrôler la mise en œuvre d’une politique de traitement des flux de données acheminés dans ledit réseau et en ce que ledit procédé comprend :
    - la réception (50) en provenance de l’entité d’exécution d’une notification (NTF) d’un indicateur de priorité (IP) associé audit flux de données (STR) reçu ;
    - l’obtention (51) d’un niveau de ressources (NRS_1) disponibles dans la tranche de réseau (SL_1) ;
    - la décision (53) d’au moins une action de traitement dudit flux au moins en fonction de l’indicateur de priorité (IP) reçu et du niveau de ressources disponibles (NRS_1), ladite action de traitement appartenant à un groupe comprenant au moins une première action (AC_1) de laisser-passer du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est suffisant pour acheminer le flux de données selon l’indicateur de priorité (IP) et une deuxième action (AC_2) de blocage du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant ; et
    - l’envoi (54) d’une réponse à ladite entité d’exécution, ladite réponse comprenant ladite action de traitement.
  9. Procédé de contrôle d’un flux de données selon la revendication précédente, caractérisé en ce que, lorsque l’action de traitement décidée est l’action (AC_2) de blocage dudit flux de données dans la tranche de réseau et lorsque l’entité d’exécution est configurée pour gérer une autre tranche de réseau (SL_2) de ladite pluralité, ledit procédé comprend, préalablement à la transmission de la deuxième action de traitement à l’entité d’exécution (EXE) :
    - l’obtention d’un niveau de ressources (NRS_2) disponibles dans l’autre tranche de réseau (SL_2) ;
    - la décision (61) d’au moins une troisième action de traitement, dite action de transfert (AC_3) du flux de données dans l’autre tranche de réseau (SL_2), en fonction dudit niveau de ressources (NRS_2) et de l’indicateur de priorité (IP).
  10. Dispositif (100) d’émission d’un flux de données par une application logicielle s’exécutant sur un équipement terminal (UE, IoT), dans un réseau de communications auquel est connecté ledit terminal, ledit réseau étant découpé en une pluralité de tranches de réseau, caractérisé en ce que ledit dispositif est configuré pour mettre en œuvre au niveau de l’équipement terminal :
    - la sélection d’une tranche de réseau (SL_1) de ladite pluralité au moins en fonction d’une information comprise dans un en-tête du flux de données ;
    - l’obtention d’un type dudit flux, ledit type appartenant à un groupe comprenant au moins un premier type (STR_1) et un deuxième type de flux (STR_2), et
    - l’insertion d’un indicateur de priorité (IP) associé au type de flux (STR_ID) dans le flux de données, l’indicateur de priorité appartenant à un groupe comprenant au moins un premier indicateur (IP_1) associé au premier type de flux (STR_1) et un deuxième indicateur (IP_2) associé au deuxième type de flux (STR_2), le premier indicateur et le deuxième indicateur de priorité ayant des valeurs distinctes ; et
    -l’émission (38) du flux de données (STR) comprenant ledit indicateur de priorité, dans la tranche de réseau (SL_1) sélectionnée.
  11. Dispositif (200) de traitement d’un flux de données (STR) dans un réseau de communication (RC), ledit réseau étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été reçu dans unedite tranche de réseau de ladite pluralité, en provenance d’une application logicielle s’exécutant sur un équipement terminal (UE, IoT) connecté à audit réseau, caractérisé en ce que le dispositif est configuré pour mettre en œuvre au niveau d’une entité d’exécution (EXE) du réseau:
    - la détection (41) d’un indicateur de priorité (IP) dudit flux dans ledit flux de données ;
    l’évaluation (42) d’un niveau de ressources disponibles dans la tranche de réseau ;
    - l’exécution (44) d’au moins une action de traitement (AC) dudit flux de données au moins en fonction dudit indicateur de priorité (IP) et du niveau (NRS) de ressources réseau disponibles dans ladite tranche de réseau (SL_1), ladite action de traitement (AC) appartenant à un groupe comprenant au moins une première action (AC_1) de laisser-passer du flux de données dans ladite tranche de réseau, lorsque le niveau de ressources disponibles est suffisant et une deuxième action (AC_2) de blocage du flux de données dans ladite tranche de réseau, destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant.
  12. Dispositif (300) de contrôle du traitement d’un flux de données (STR) dans un réseau de communications, ledit réseau de communications étant découpé en une pluralité de tranches de réseau, ledit flux de données ayant été émis par un équipement terminal (UE, IoT) et reçu par une entité d’exécution (EXE) dudit réseau dans une tranche de réseau (SL_1) de ladite pluralité, caractérisé en ce que ledit dispositif est configuré pour mettre en œuvre au niveau d’une entité de contrôle (CTR) dudit réseau, ladite entité de contrôle étant configurée pour contrôler la mise en œuvre d’une politique de traitement des flux de données acheminés dans ledit réseau:
    - la réception en provenance de l’entité d’exécution d’une notification (NTF) d’un indicateur de priorité (IP) associé audit flux de données (STR) reçu ;
    - l’obtention d’un niveau de ressources (NRS_1) disponibles dans la tranche de réseau (SL_1) ;
    - la décision d’au moins une action de traitement dudit flux au moins en fonction de l’indicateur de priorité (IP) reçu et du niveau de ressources disponibles (NRS_1), ladite action de traitement appartenant à un groupe comprenant au moins une première action (AC_1) de laisser-passer du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est suffisant et une deuxième action (AC_2) de blocage du flux de données dans ladite tranche de réseau destinée à être mise en œuvre lorsque le niveau de ressources réseau disponibles est insuffisant ; et
    - l’envoi d’une réponse à ladite entité d’exécution, ladite réponse comprenant ladite action de traitement.
  13. Equipement terminal (UE, IoT) connecté à un réseau de communications (RC), ledit réseau étant découpé en une pluralité de tranches de réseau, caractérisé en ce qu’il comprend un dispositif (100) d’émission d’un flux de données dans une tranche de réseau de ladite pluralité selon la revendication 10.
  14. Système (S) de contrôle de flux de données acheminés dans un réseau de communications (RC), caractérisé en ce qu’il comprend au moins un dispositif (100) d’émission d’un flux de données selon la revendication 10, un dispositif (200) de traitement d’un flux de données selon la revendication 11 et un dispositif (300) de contrôle du traitement d’un flux de données selon la revendication 12.
  15. Programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé selon l'une quelconque des revendications 1 à 9, lorsqu’il est exécuté par un processeur.
PCT/EP2022/084438 2021-12-08 2022-12-05 Procédé d'émission d'un flux de données dans un réseau de communications, procédé de traitement d'un flux de données, procédé de contrôle du traitement d'un flux de données, dispositifs, équipement terminal, entité d'exécution, entité de contrôle, système et programmes d'ordinateur correspondants. WO2023104724A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2113160 2021-12-08
FR2113160A FR3130049A1 (fr) 2021-12-08 2021-12-08 Procédé d’émission d’un flux de données dans un réseau de communications, procédé de traitement d’un flux de données, procédé de contrôle du traitement d’un flux de données, dispositifs, équipement terminal, entité d’exécution, entité de contrôle, système et programmes d’ordinateur correspondants.

Publications (1)

Publication Number Publication Date
WO2023104724A1 true WO2023104724A1 (fr) 2023-06-15

Family

ID=80999118

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/084438 WO2023104724A1 (fr) 2021-12-08 2022-12-05 Procédé d'émission d'un flux de données dans un réseau de communications, procédé de traitement d'un flux de données, procédé de contrôle du traitement d'un flux de données, dispositifs, équipement terminal, entité d'exécution, entité de contrôle, système et programmes d'ordinateur correspondants.

Country Status (2)

Country Link
FR (1) FR3130049A1 (fr)
WO (1) WO2023104724A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160352645A1 (en) * 2015-06-01 2016-12-01 Huawei Technologies Co., Ltd. Systems and Methods for Managing Network Traffic with a Network Operator
US20190007899A1 (en) * 2015-06-01 2019-01-03 Huawei Technologies Co., Ltd. System and method for virtualized functions in control and data planes
CN111698725A (zh) * 2020-06-23 2020-09-22 腾讯科技(深圳)有限公司 动态确定网络切片的方法及电子设备
US20210037544A1 (en) * 2018-03-27 2021-02-04 Nokia Solutions And Networks Oy Network slicing based on one or more token counters

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160352645A1 (en) * 2015-06-01 2016-12-01 Huawei Technologies Co., Ltd. Systems and Methods for Managing Network Traffic with a Network Operator
US20190007899A1 (en) * 2015-06-01 2019-01-03 Huawei Technologies Co., Ltd. System and method for virtualized functions in control and data planes
US20210037544A1 (en) * 2018-03-27 2021-02-04 Nokia Solutions And Networks Oy Network slicing based on one or more token counters
CN111698725A (zh) * 2020-06-23 2020-09-22 腾讯科技(深圳)有限公司 动态确定网络切片的方法及电子设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
3GPP TS 23.502

Also Published As

Publication number Publication date
FR3130049A1 (fr) 2023-06-09

Similar Documents

Publication Publication Date Title
EP1792447B1 (fr) Procede de preemption pour la gestion des ressources radio dans un reseau de communication mobile
WO2019002754A1 (fr) Procédé de communication quic via des chemins multiples
US8102879B2 (en) Application layer metrics monitoring
EP2148478B1 (fr) Méthode d'ordonnancement de paquets
EP3318023B1 (fr) Procédé d'optimisation de la charge d'un concentrateur de connexions réseau
EP2359546B1 (fr) Procede de configuration de parametres de gestion de paquets de donnees appartenant a un flux de donnees
FR3025387A1 (fr) Dispositif et procede de controle d'un coeur de reseau ip
EP2460322B1 (fr) Procede et systeme pour la selection automatique de media de transmission
FR2925808A1 (fr) Procede de communication dans un reseau comprenant un reseau primaire et un reseau secondaire
WO2023104724A1 (fr) Procédé d'émission d'un flux de données dans un réseau de communications, procédé de traitement d'un flux de données, procédé de contrôle du traitement d'un flux de données, dispositifs, équipement terminal, entité d'exécution, entité de contrôle, système et programmes d'ordinateur correspondants.
EP3539318B1 (fr) Equipement mandataire dans un système de télécommunication cellulaire
EP2206384B1 (fr) Procede de commutation de noeud d'acces
FR3105694A1 (fr) Procédé de configuration d’un équipement utilisateur, équipement utilisateur, et entité de gestion de règles
WO2023138968A1 (fr) Procédé de mise à jour d'une politique d'accès à un premier réseau de télécommunication, système, équipements et programmes d'ordinateurs correspondants
EP1517478B1 (fr) Procédé et système de contrôle de l'utilisation d'un point d'accès à un réseau, et supports d'enregistrement, point d'accès et équipement de contrôle pour la mise en oeuvre du procédé
WO2005107158A1 (fr) Systeme de controle dynamique de reseau ip
EP4203429A1 (fr) Procédé de traitement d'un paquet de données dans un réseau de communications, procédé de traitement d'une demande de changement de niveau de qualité de service d'une connexion, procédé de demande de changement de niveau de qualité de service d'une connexion, procédé de gestion d'une qualité de service, dispositifs, système et programmes d ordinateur correspondants
WO2020120850A1 (fr) Terminal pouvant être connecté simultanément à plusieurs réseaux d'accès, procédé de différentiation de trafic émis par le terminal, dispositif et procédé de gestion du trafic
WO2024068725A1 (fr) Procédé de gestion du trafic de données entre une entité source et une entité destinataire, entité et programme d'ordinateur correspondants
WO2023047068A1 (fr) Procede de controle d'un acces a un service applicatif mis en œuvre dans un reseau de telecommunications, procede de traitement d'un message de controle d'un acces audit service applicatif, dispositifs, equipement de controle, equipement client, systeme et programmes d'ordinateur correspondants
EP4335144A1 (fr) Parametrage d'un terminal
FR3124681A1 (fr) Procédé de traitement d’une connexion entre un équipement utilisateur et un équipement distant dans un réseau de communication, procédé de contrôle, dispositifs, satellite, station terrestre, système et programmes d’ordinateur correspondants.
FR3079995A1 (fr) Equipement orchestrateur dans un systeme de telecommunication cellulaire
FR3014281A1 (fr) Equipement de passerelle d'acces de mobiles a internet
FR2965132A1 (fr) Procede de configuration de parametres de gestion de paquets de donnees appartenant a un flux de donnees

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22823598

Country of ref document: EP

Kind code of ref document: A1