WO2023281181A1 - Procede et dispositif de configuration d'une unite d'acces dans un environnement virtualise - Google Patents

Procede et dispositif de configuration d'une unite d'acces dans un environnement virtualise Download PDF

Info

Publication number
WO2023281181A1
WO2023281181A1 PCT/FR2022/051228 FR2022051228W WO2023281181A1 WO 2023281181 A1 WO2023281181 A1 WO 2023281181A1 FR 2022051228 W FR2022051228 W FR 2022051228W WO 2023281181 A1 WO2023281181 A1 WO 2023281181A1
Authority
WO
WIPO (PCT)
Prior art keywords
software application
operating software
unit
communication network
message
Prior art date
Application number
PCT/FR2022/051228
Other languages
English (en)
Inventor
Emile Stephan
Romuald CORBEL
Bini ANGUI
Veronica Quintuna Rodriguez
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
Priority to EP22743523.7A priority Critical patent/EP4367854A1/fr
Publication of WO2023281181A1 publication Critical patent/WO2023281181A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/34—Signalling channels for network management communication
    • H04L41/342—Signalling channels for network management communication between virtual entities, e.g. orchestrators, SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/20—Arrangements for monitoring or testing data switching networks the monitoring system or the monitored elements being virtualised, abstracted or software-defined entities, e.g. SDN or NFV
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements

Definitions

  • the invention relates to the automated deployment or updating of a communications network access infrastructure in a virtualized environment based on a service platform based on operating software applications, such as containers or virtual machines.
  • the automated deployment of the access infrastructure takes into account parameters of network performance, security, energy, entity costs for the functional and geographical distribution of the entities making up this infrastructure.
  • Communication network access architectures and more particularly mobile network access infrastructures, are subject to significant changes. From an infrastructure where all the processing (resource allocation, modulation, encoding, etc.) allowing access to terminals was distributed in the radio sites, as close as possible to the antennas, we are moving towards more or less centralization. less important of some of these treatments according to criteria of availability, quality of service and in particular latency. Thus, in particular at 3GPP and within the Open RAN alliance, work is being carried out to specify these new access infrastructures. We distinguish in these new infrastructures three entities identified CU (in English Centralized Unit), RU (in English Radio Unit) and DU (in English Distributed Unit).
  • CU in English Centralized Unit
  • RU in English Radio Unit
  • DU in English Distributed Unit
  • the masters (in English masters) allowing to manage all the deployments in a group of servers. It is composed of three parts, namely an ETCD database (in English /etc distributed) storing all the data of the group of servers, a server (in English API server) which allows among other things the master to communicate with the nodes comprising containers, and controllers whose purpose is to check the proper functioning of the group as well as deployments and updates.
  • the nodes which can be physical machines or virtual machines. Containers are instantiated on nodes.
  • a node includes a kublet which allows communication with the master and manage deployments on the node, a kube-proxy allowing communication external to the group of servers and a Pod in which a container is executed.
  • cluster used in such a containerization solution corresponds to a Masters/Nodes set as described above.
  • the architecture chosen must make it possible to meet the performance criteria and in particular a maximum delay of 1 ms between a DU and a RU - A start of the Cloud RAN and therefore of the containers of the entities CU, DU, RU, is allowed by initial configurations. So the DU must know the IP address of the RU, the DU must know the IP address of the CU etc...
  • Constraints specific to a containerization solution such as Kuberenetes, in such a distributed environment are also recalled below:
  • the containerization solution does not make it possible to manage allocations external to the solution itself and in particular not the allocation of antennas to the RU container
  • the solution also does not allow the exchange of configurations between the different containers allowing the deployment of the Cloud RAN and in particular the sharing of container addressing information comprising the CU, DU and RU entities of the Cloud RAN
  • Verification that the deployment of containers supporting the CU, DU and RU functions makes it possible to respect the performance constraints of such distributed access infrastructure architectures.
  • the present invention aims to provide improvements over the state of the art.
  • the invention improves the situation with the aid of a method for configuring at least one access unit of a communication network in a virtualized environment comprising at least one operating software application, said method being implemented in an administration entity of the communication network and comprising
  • a deployment of an access unit of a communication network, in particular of the mobile type, in a virtualized environment, such as a virtualized architecture requires the instantiation of operating software applications, which can be containers or virtual machines or any other solutions allowing the installation of software solutions ensuring the routing of data in a network.
  • Such a deployment requires ensuring that the positioning of the unit makes it possible to comply with placement constraints and in particular routing constraints, but also that the unit can have sufficient configuration information to send and receive data from another infrastructure unit.
  • the DU unit must be deployed in a container making it possible to respect a certain throughput or a certain latency for example, but also that the DU unit be configured with identifiers, such as IP addresses, of a CU and a RU.
  • the configuration method thus makes it possible on the one hand to obtain identifiers of operating software applications and of nodes, physical or virtualized, supporting these containers, which makes it possible to route the data of a node and of a operating software application to another.
  • the method also makes it possible to ensure compliance with deployment constraints of a unit with respect to the position and the capacity of the operating software applications and therefore of the nodes comprising these operating software applications thanks to a determination of the operating software application from a test. From the result of this test, it is then possible to be able to configure the unit (CU, DU, or RU in the example) in a determined operating software application, since it has been determined that the software application of exploitation could effectively satisfy the need.
  • the access infrastructure can also be initialized using configuration information since each unit holds configuration information from another unit with which the configured unit sends and receives data from or to terminals attached to the network. access infrastructure.
  • the placement criterion relating to a data stream corresponds to one or more of the criteria from the following list:
  • a container is advantageously determined according to a criterion relating to a criterion of security and confidentiality of data managed by a container comprising a unit, to a criterion of QoS of data routing, of availability of an operating software application and therefore of the unit supported by the operating software application, of energy consumption of the operating software application in the virtualized environment to route the data stream, or even of latency of data passing through the operating software application.
  • the determination and availability of a network node through which a data flow must pass can also be used as placement criteria. Several of these criteria can advantageously be considered in the test to determine the optimal operating software application that can host the unit to be configured.
  • the test relating to a placement criterion comprises a comparison of a delivery time of a data stream coming from, respectively going to, the other at least one operating software application and to, respectively coming from another operating software application of the virtualized environment, with a routing value of a reference data stream.
  • the test relating to a placement criterion comprises a comparison of a routing delay and a quality of service measurement of a data stream originating, respectively to the destination of at least one operating software application and to, respectively coming from, another software application for operating the virtualized environment, with theoretical routing values specific to a specific architecture of the network Communication.
  • the architectures of the infrastructures, and in particular the choice of the positioning of the various functions (modulation, coding, etc.) in a unit induce specific routing and quality of service capacities between the units.
  • specific routing needs such as throughput, latency or more generally quality of service, for example.
  • the comparison of test measurements with such needs makes it possible to determine the most suitable operating software application(s) to host a communication network access unit.
  • the at least one operating software application is also determined according to the geographical position of an attachment device of the communication network.
  • the choice of an operating software application takes account of the position of the attachment equipment for reasons of deployment, data latency, and compliance with routing conditions linked to the services whose data is routed over the communication network comprising the operating software applications.
  • the configuration method further comprises
  • the method can advantageously comprise steps allowing the administration entity of the communication network to regularly obtain an update of the virtualized environment and a list of the nodes actually deployed supporting a operating software application that can theoretically accommodate a unit of an access infrastructure. These steps, repeated over time periodically or not, provide the communication network administration entity with up-to-date knowledge of the virtualized environment used for deploying or updating the access infrastructure. .
  • the administration entity of the virtualized environment is, according to one example, a “master Kubemetes” node.
  • the response message further comprises location data of the at least one node.
  • the response message received from the administration entity of the virtualized environment can advantageously include node location data, particularly with a view to being able to deploy a unit of the infrastructure as close as possible to an equipment of attachment or to manage the necessary interactions between the units of the infrastructure taking into account the geographical constraints of their instantiation in the containers included in the nodes.
  • the configuration method further comprises the reception of a command message for an update of the communication network comprising geographical data of at least one access unit of the network.
  • the response message received from the administration entity of the virtualized environment can advantageously include node location data, particularly with a view to being able to deploy a unit of the infrastructure as close as possible to an equipment of attachment or to manage the necessary interactions between the units of the infrastructure taking into account the geographical constraints of their instantiation in the containers included in the nodes.
  • the configuration method further comprises the reception of a command message for an update of the communication network comprising geographical data of at least one access unit of the network.
  • the command message corresponds for example to a new affiliation of an access unit.
  • the communication network administration entity receives an update command, which may correspond to an initial instantiation, of a communication network access infrastructure, for example a deployment of a CU unit, a DU unit and one RU unit.
  • the command includes geographical data, for example GPS data, of an access unit to cover or improve the coverage of a new geographical area for example.
  • This command message can be issued by a network administrator or external software such as ONAP (Open Network Automation Platform) software.
  • the configuration message further comprises a configuration parameter relating to a device attached to the communication network.
  • Configuration parameters relating to the attachment equipment can advantageously be transmitted to a mediation entity, in particular if it is a mediation entity of a unit in charge of the functions to be activated as close as possible to the attachment equipment, such as an RU unit in a Cloud RAN infrastructure.
  • a mediation entity a unit in charge of the functions to be activated as close as possible to the attachment equipment, such as an RU unit in a Cloud RAN infrastructure.
  • an attachment device such as an antenna
  • the RU obtains a minimum of information on the type of antenna.
  • an FPGA code which executes in the antenna is necessary and it is advantageous to have the precise version of the antenna to execute the correct code or even how to contact the antenna (port USB, network interface, etc.).
  • the configuration method further comprises a message for obtaining from a database a set of operating software applications, said set being relative to the geographical datum of an infrastructure access unit.
  • the administration entity of the communication network requests a database comprising the nodes and the operating software applications of the virtualized environment.
  • the database returns to the administration entity operating software applications and possibly identifiers of the nodes supporting the operating software applications corresponding to geographical data, for example GPS data, of an access unit , for example located closest to an antenna of the access infrastructure.
  • the database returns the IP addresses of the operating software applications that can accommodate units of the communication network as well as the IP addresses of the nodes comprising these operating software applications.
  • the administration entity has a list of possible operating software applications among which it will determine the operating software applications in charge of hosting the respective units as a function of test results.
  • the database can also advantageously understand and return parameters of an attachment device (antenna), the type of attachment device can influence the location of the infrastructure units in operating software applications.
  • the invention also relates to a method for managing at least one access unit of a communication network in a virtualized environment comprising at least one operating software application, said method being implemented in a mediation entity of the at least one operating software application and comprising
  • the invention also relates to a device for configuring at least one access unit of a communication network in a virtualized environment comprising at least one operating software application, and comprising
  • a receiver able to receive from a mediation entity of the at least one operating software application a recording message from the at least one operating software application associating an identifier of the at least one operating software application and an identifier of at least one node supporting the at least one operating software application,
  • a determination module capable of determining, before or following receipt of the registration message, the at least one operating software application for accommodate the at least one unit according to a result of a test relating to a placement criterion relating to a data stream routed by the at least one unit,
  • a transmitter capable of transmitting to the mediation entity of the at least one determined operating software application a configuration message from the at least one unit in the at least one software application of determined operation, said configuration message comprising an identifier of at least one other access unit of the communication network.
  • This device capable of implementing in all its embodiments the configuration method which has just been described, is intended to be implemented in an administration equipment of a communication network or else in an equipment of management of an access infrastructure, such as a C-RAN infrastructure.
  • the invention also relates to a device for managing at least one access unit of a communication network in a virtualized environment comprising at least one operating software application, comprising
  • a transmitter capable of transmitting to an administration entity of the communication network, a registration message of the at least one operating software application associating an identifier of the at least one software application of exploitation and an identifier of at least one node supporting the at least one exploitation software application,
  • a receiver able to receive from the administration entity of the communication network, a configuration message of the at least one unit in the at least one operating software application determined by the entity of administration, said configuration message comprising an identifier of at least one other unit of the communication network,
  • a configurator capable of configuring the at least one operating software application on the basis of the configuration message received
  • an activator capable of activating the at least one access unit in the at least configured operating software application.
  • This device capable of implementing the management method which has just been described, is intended to be implemented in physical or virtualized equipment, such as a server or an unmarked docking station.
  • the invention also relates to a system for configuring at least one access unit of a communication network in a virtualized environment comprising at at least one operating software application, and comprising a configuration device and a management device.
  • the invention also relates to computer programs comprising instructions for implementing the steps of the respective configuration and management methods which have just been described, when these programs are both executed by a processor and a recording medium respectively readable by a configuration and management device on which the computer programs are recorded.
  • the programs mentioned above 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 n any other desirable shape.
  • a medium may comprise a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording medium.
  • a storage medium such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording medium.
  • Such a storage means can for example be a hard disk, a flash memory, etc.
  • an information medium can be a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means.
  • a program according to the invention can in particular be downloaded from an Internet-type network.
  • an information carrier may be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of the methods in question.
  • FIG 1 presents a simplified view of a communication network in which the configuration method and the management method are implemented according to one aspect of the invention
  • FIG 2 presents a simplified view of a communication network in which the configuration method and the management method are implemented according to another aspect of the invention
  • FIG 3 presents an overview of the configuration method and the management method according to one embodiment of the invention
  • FIG 4 shows a configuration device according to one embodiment of the invention
  • FIG 5 presents a management device according to one embodiment of the invention.
  • This network can be implemented to route communication data to fixed or mobile terminals.
  • the invention may be intended to deploy or update access units of a communications network, the access units being defined as units allowing terminals to route data to data servers or other terminals via the communications network.
  • FIG 1 presents a simplified view of a communication network in which the configuration method and the management method are implemented according to one aspect of the invention.
  • a communication network 20 is composed of an access unit RU, of an entity DU and of an entity CU allowing data streams to be routed to and from a core network CN.
  • the network 20 further comprises an attachment equipment 130, represented by a cellular type antenna according to this example, allowing a terminal 120 to be able to transmit and receive data via the network 20.
  • the attachment equipment 130 may comprise a plurality of antennas.
  • a single unit of type RU, DU, CU as well as a single attachment equipment is represented but a network can comprise a plurality of units and attachment equipment can be included in this network 20. This structuring in three units RU/DU/CU of a network is also identified in the prior art as a Cloud-RAN architecture.
  • the distribution of functions and processing allowing the routing of data in the network 20 in one or other of the RU/DU/CU units gives rise to discussions and to specifications.
  • Split around ten options, also called Split, have been defined within 3GPP depending on whether certain functions are centralized or not, considering the impact on the links between units and on services for users.
  • the split 7.3 plans to encode and decode the signals in the DU unit and thus reduce the financial cost of the links between the RU unit and the DU unit, also called Fronthaul.
  • That structuring of the network 20 into units is also accompanied by virtualization of the RU/DU/CU units making it possible to reduce the cost thereof and to facilitate the deployment and/or the updating thereof by the use of unmarked nodes , in the form of computer servers, and software deployed on these nodes, in the form of VNFs (in English Virtual Network Functions) or CNFs (in English Cloud Native Network Functions) depending on the type of infrastructure selected for the implementation of the network 20.
  • VNFs in English Virtual Network Functions
  • CNFs in English Cloud Native Network Functions
  • a network 20 of the RAN cloud type is based on a division into three geographical areas, the regional data spaces (in English clouds), the end data spaces (in English edge clouds), the data spaces edge (in English far edge clouds) defined in particular by the O-RAN alliance (in English Open Radio Access Network).
  • a virtualized environment 10 is based on a Kubemetes platform, representing an orchestration solution for operating software applications represented here by containers, but it could also be a separate virtualization platform from Kubemetes.
  • This virtualized environment is composed of a Kubemetes KM master and nodes KN 1 , KN2, KN3 which can be physical machines or even virtual machines.
  • the attachment equipment 130 comprising one or more antennas
  • this embodiment is particularly relevant for the deployment of the RU unit in equipment also having one or more antennas, so as to reduce the data transmission latency time between an antenna and the UK unit.
  • Each node contains the services needed to run Pods, that is, places to run operating software applications.
  • FIG 1 are represented three nodes KN1, KN2 and KN3 but a greater number of nodes can be included in the virtualized environment 20.
  • the nodes KN1, KN2 and KN3 respectively comprise the operating software applications C1, C2 , C3.
  • the Kubemetes KM master is deployed in the regional dataspace and the KN1, KN2 and KN3 nodes are deployed in the regional dataspaces or the dataspaces of edge or edge data spaces.
  • a network administrator or even third-party software for example of the ONAP (Open Network Automation Platform) type, requires the Kubemetes KM master to deploy operating software applications C1, C2, C3 in the nodes KN1, KN2, KN3.
  • the operating software applications C1, C2 and C3 are not activated and are not able to route data.
  • This step initializes the operating software applications.
  • These operating software applications include mediation entities making it possible to be able to interact with the master KM.
  • a CU type unit is deployed in an operating software application Cl of the regional KN1 node
  • a DU type unit is deployed in an operating software application C3 of an end node KN3
  • an RU unit is deployed in a C2 operating software application of an edge KN2 node.
  • the configuration method makes it possible to determine the most suitable container C1, C2 or C3 to accommodate a given access unit and to be able to configure this unit on the most suitable operating software application, in particular with respect to the geographical location of the attachment equipment and/or placement criteria relating to a data stream, for example transmitted or received by the terminal 120, routed by a given access unit.
  • the positioning of the RU unit with respect to the attachment equipment is in particular to be considered knowing that it is important to avoid excessive latency between the antenna and the RU unit.
  • FIG 2 a simplified view of a communication network is presented in which the configuration method and the management method according to another aspect of the invention are implemented.
  • This administration entity 100 which can also be called BCRS (Bootstrapper cloud-RAN server in English) can be, according to one example, be deployed in a regional data space and makes it possible in particular to manage the list of hardware resources and to ensure their management. It also makes it possible to link the various elements of the RAN Cloud and in particular the various RU/DU/CU units, as well as performance management and in particular the performance measurements between the RU/DU/CU units.
  • This entity is distinct from a KM master but alternatively it can be instantiated in a KM master.
  • mediation entities EM1, EM2, and EM3 of the respective operating software applications C1, C2, C3.
  • a mediation entity EM1 or EM2 or EM3 is also called B CRC (in English Bootstrapper Cloud-RAN client) and notably allows an operating software application (C1 or C2 or C3) to interact with the administration entity 100 .
  • the administration entity prior to receiving from a mediation entity one of the operating software applications EM1, EM2, EM3 can, according to one example, request from the master KM a list of nodes KN1 , KN2 and KN3 that it manages.
  • the master KM returns to the administration entity 100 a list of identifiers, such as IP addresses if it is an IP network, nodes KN1, KN2 and KN3, as well as a information or a label on the geographical area in which a communication network is deployed at 3 levels: regional, end and border in which the KN1, KN2 or KN3 node is located, as well as possibly a state of the node to indicate whether it is actually active or not in the virtualized space 10.
  • IP addresses if it is an IP network, nodes KN1, KN2 and KN3, as well as a information or a label on the geographical area in which a communication network is deployed at 3 levels: regional, end and border in which the KN1, KN2 or KN3 node is located
  • This information received by the administration entity 100 can then be saved in a database, and thus be available when needed.
  • the search for all the access equipment, here represented by the antenna 130 is carried out. This search is carried out by soliciting the nodes among the nodes KN1, KN2, KN3 being in an edge data space and furthermore in an active or ready or still ready state in a time interval, knowing that only a data space edge is adapted to include an antenna to which the terminal 120 can attach.
  • the administration entity 100 requests the node KN2 to find whether an antenna is available but according to an example where a plurality of nodes located in data spaces border are available, the administration entity 100 would request these different nodes.
  • the requested nodes transmit to the administration entity 100 the connection parameters to an antenna such as the USB ports, the FPGA type information (in English Field Programmable Gate Array) specific to the antenna, the type of antenna and the location coordinates of the edge data space, such as GPS (Global Positioning System) location information.
  • the administration entity 100 can transmit a request to a topological database comprising all the information on the deployments of physical equipment in an area to obtain information on the antennas available in data spaces border.
  • the identifiers of the nodes of the border data spaces can, according to an example, be transmitted as a parameter of the request transmitted.
  • the administration entity 100 can also save this information received on the antennas in a database. These different stages of discovery of nodes and antennas by the administration entity 100 can be repeated so that the administration entity 100 has an up-to-date map.
  • the administration entity 100 can also proceed with the configuration of a unit in the absence of these steps, for example by resorting to a database that it has itself updated or updated by a other entity.
  • a network administrator or even third-party software requests the administration entity 100 to deploy one or more units CU/ DU/RU in the virtualized space 20.
  • information on the location of a RU unit is transmitted as a parameter of this request, for example to cover or improve the coverage of the given three-level communication network corresponding to the location information of the RU entity, close to a reception antenna.
  • the administration entity 100 can thus request from a database, which it itself will have previously updated or not, a list of nodes KN1, KN2, KN3 likely to meet the needs of the request for deployment.
  • the database can search for the KN1, KN2, KN3 nodes closest to the location information received during the deployment request and transmitted to the database.
  • the database sends back to the administration entity 100 the node associations (KN1, KN2, KN3)/operating software applications (C1, C2, C3) that it deems possible for deployment or updating.
  • RAN cloud day The set of combinations for the CU unit, i.e. an identifier of the CU unit and the identifier of the KN1 or KN2 or KN3 node, and in the same way for the DU unit and the RU unit . Attachment equipment parameters can also be transmitted.
  • the administration entity 100 carries out a CU/DU/RU/antenna affiliation according to the response received from the database.
  • the nodes selected at this stage are then candidates for selection to assess their ability to comply with placement criteria or even location criteria.
  • the mediation entities EM 1 , EM2 and EM3 of the respective containers Cl, C3, C3 transmit respectively to the administration entity 100 messages registration of containers C1, C2, C3.
  • These registration messages sent individually by each mediation entity EM1, EM2 and EM3 comprise an identifier of the container considered, such as an IP address as well as an identifier of the node on which the container is deployed.
  • the mediation entities EM1, EM2, EM3 will respectively transmit an identifier, such as an IP address, of the nodes KN1, KN2 and KN3.
  • only one or more mediation entities among EM1, EM2, EM3 can transmit a registration message to the administration entity 100.
  • the identifiers, here the IP addresses are for example dynamically allocated to the containers Cl, C2 and C3 as well as to the nodes KN1, KN2, KN3 and cannot be known to the administration entity 100 before this sending and the effective start. of the container.
  • the mediation entity 100 can save the data received during step El and relating to the containers in a database, for example identical to that described in [Fig 2] , thus making it possible to be reused if necessary.
  • this registration step can occur after the container initialization step as described in [Fig. 1]
  • this step E 1 can be executed following or previously to a CU/DU/RU/antenna affiliation step as described in [Fig 2]
  • the administration entity 100 determines a container to accommodate a CU/DU/RU unit according to a result of a test relating to a placement criterion linked to a data stream routed by the unit to be deployed in a container. It should be noted that this determination step E3 can occur before step El and following the initialization and affiliation steps described in [Fig 1] and [Fig 2].
  • the administration entity 100 requests the master KM (not shown in [Fig 3] but shown in [Fig 1] and [Fig 2]), the creation of all the containers necessary to simulate traffic from a RAN cloud and to obtain the information resulting from this simulation.
  • the Master KM creates the following containers in a regional data space: a transmitter to send the data to simulate the downstream data flow (in English download), a receiver to receive the data in the upstream direction (in English upload), a test unit CU making it possible to route the data of a stream to a test DU in the downstream direction and to the regional data space receiver in the upstream direction.
  • the Master KM further creates a DU unit in an end data space to route data to a RU unit in the downstream direction and to the CU unit in the upstream direction.
  • the KM master further creates in an edge data space a receiver to receive data from a stream in the downstream direction, a transmitter to send data from a simulated stream in the upstream direction, and an RU to route the data. data to the edge data space receiver in the downstream direction and to the test DU in the upstream direction.
  • a test data stream is generated and transmitted by the respective transmitters of the data spaces to the destinations of the respective receivers to simulate the downstream and upstream data streams.
  • the data streams characterizing the architectural options of a Cloud RAN infrastructure are transmitted, these data streams being able to be differentiated according to the direction of transmission, upstream or downstream, and according to the technologies of the interfaces between the entities of infrastructure.
  • the administration entity 100 retrieves the information recorded in the various test entities created in the regional, end and border spaces.
  • This recorded information includes, for example, data stream routing quality parameters such as, for example, the actual throughput achieved, unit availability criteria, energy criteria such as the unit's energy consumption to route the data stream, a latency criterion, jitter of the data stream, a data loss criterion or even a routing criterion by a particular device or not.
  • data stream routing quality parameters such as, for example, the actual throughput achieved, unit availability criteria, energy criteria such as the unit's energy consumption to route the data stream, a latency criterion, jitter of the data stream, a data loss criterion or even a routing criterion by a particular device or not.
  • the test relating to one or more placement criteria can advantageously comprise a comparison with a reference value for the data stream, such as for example a reference routing delay.
  • a reference value for the data stream such as for example a reference routing delay.
  • the administration entity 100 can compare a delivery time of a data stream in a unit deployed in a container C1, C2, C3 of the virtualized environment with a reference value of a specific architecture of the Cloud RAN communication network, as for example presented in the table above, and using the result of this comparison, determining whether the container C1, C2 or C3 is suitable for accommodate a CU or DU or RU unit.
  • the reference value relates to a specific data stream, for example a data stream requiring a particular requirement in terms of reliability and/or routing delay and/or latency.
  • the container can also be determined according to a geographical position of an attachment equipment, such as an antenna of a cellular network for example.
  • the container among the containers C1, C2, C3 can be selected to accommodate a unit RU according to the geographical position of an antenna so as to reduce as much as possible the data transit delay between the antenna and the entity UK.
  • the administration entity 100 requests from the nodes data spaces on which the various test entities have been instantiated the deletion of these entities (transmitters, receivers, test CUs, test DUs, test RUs ) created to carry out the tests required for the determination of the containers C1, C2, C3 able to accommodate the units CU/DU/RU according to the criteria used and possibly the location information mentioned above.
  • new candidate nodes to host containers may be selected and evaluated in accordance with the determination step described above. These new nodes would then be identified in a new affiliation step.
  • the administration entity 100 sends to the mediation entities EM1, EM2, EM3 respective containers C1, C2, C3 selected following the determination step E3 and duly registered on the respective nodes KN1, KN2, KN3 a configuration message for a CU unit in the C1 container, a DU unit in the C3 container and a RU unit in the C2 container.
  • the configuration message includes, according to one example, the IP addresses of the units, the software version used in the units, the antenna to be used for the RU unit or even specific network configurations such as protocols and port numbers, even vore a lifetime of mediating entities.
  • the configuration message transmitted to the mediation entity EM1 of the container Cl, aimed at configuring a unit CU, comprises furthermore an identifier, such as for example an IP address, of the unit DU thus allowing the unit CU to know the entity DU with which it will exchange the stream data.
  • the configuration message transmitted to the mediation entity EM3 of the container C3, aimed at configuring a unit DU further comprises an identifier, such as for example an IP address, of the unit CU as well as an identifier (IP address) of a RU unit.
  • IP address IP address
  • the configuration message transmitted to the mediation entity EM2 of the container C2, aimed at configuring a unit RU, further comprises an identifier, such as for example an IP address, of the unit DU thus allowing the unit RU to know the DU entity with which it will exchange flow data.
  • This configuration message, transmitted to the mediation entity EM2 further comprises data characterizing an attachment equipment, such as an antenna, if only so that the unit RU can communicate with the equipment of attachment using the correct interface and data encoding/decoding algorithm.
  • the mediation entities EM1, EM2 and EM3 having received the configuration information of the containers C1, C2, C3 allowing them to actually accommodate the respective entities CU, RU and DU configure these containers with the information obtained so that the Cloud RAN infrastructure can be initialized or updated.
  • the entities EM1, EM2 and EM3 start the software applications corresponding to the units CU/DU/RU in the respective containers C1, C3 and C2.
  • the steps E5 and E6 can be executed jointly and the starting of the software applications can be carried out during the configuration of the units C1, C2, C3 by the respective mediation entities EM1, EM2 and EM3.
  • Such a configuration device can be implemented in administration equipment, such as the network administration entity 100 according to [Fig 2] and (Fig 3], of a communication network or else in equipment for managing an access infrastructure, such as a C-RAN infrastructure.
  • the device 500 comprises a processing unit 530, equipped for example with an mR microprocessor, and controlled by a computer program 510, stored in a memory 520 and implementing the configuration method according to the invention.
  • a computer program 510 stored in a memory 520 and implementing the configuration method according to the invention.
  • the code instructions of the computer program 510 are for example loaded into a RAM memory, before being executed by the processor of the processing unit 530.
  • Such a configuration device 500 comprises:
  • a receiver 501 capable of receiving from a mediation entity of the at least one operating software application an Enr message recording the at least one operating software application associating an identifier of the at least one operating software application and an identifier of at least one node supporting the at least one operating software application,
  • a determination module 502 capable of determining, before or following receipt of the registration message, the at least one operating software application to accommodate the at least one unit as a function of a result of a test relating to a placement criterion relating to a data stream routed by the at least one unit,
  • a transmitter 503 capable of transmitting to the mediation entity of the at least one determined operating software application a configuration message Conf from the at least one unit in the at least one software application determined operating mode, said configuration message comprising an identifier of at least one other access unit of the communication network.
  • FIG 5 shows a management device 600 according to one embodiment of the invention.
  • a management device can be implemented in is intended to be implemented in physical or virtualized equipment, such as a server or an ordinary docking station.
  • the device 600 comprises a processing unit 630, equipped for example with a microprocessor mR, and controlled by a computer program 610, stored in a memory 620 and implementing the configuration method according to the invention.
  • the code instructions of the computer program 610 are for example loaded into a RAM memory, before being executed by the processor of the processing unit 630.
  • Such a configuration device 600 comprises: - a transmitter 601, capable of transmitting to an administration entity of the communication network, an Enr message for recording the at least one operating software application associating an identifier of the at least one software application operating system and an identifier of at least one node supporting the at least one operating software application,
  • a receiver 602 capable of receiving from the administration entity of the communication network, a configuration message Conf from the at least one unit in the at least one operating software application determined by the entity administration, said configuration message comprising an identifier of at least one other unit of the communication network,
  • a configurator 603 capable of configuring the at least one operating software application on the basis of the configuration message received
  • an activator 604 capable of activating the at least one access unit in the at least configured operating software application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé de configuration d'au moins une unité d'accès d'un réseau de communication dans un environnement virtualisé comprenant au moins une application logicielle d'exploitation. Le procédé est mis en œuvre dans une entité d'administration du réseau de communication et comprenant une réception en provenance d'une entité de médiation de l'au moins une application logicielle d'exploitation d'un message d'enregistrement de l'au moins une application logicielle d'exploitation associant un identifiant de l'au moins une application logicielle d'exploitation et un identifiant d'au moins un nœud supportant l'au moins une application logicielle d'exploitation. Préalablement ou suite à la réception du message d'enregistrement, l'entité d'administration détermine au moins une application logicielle d'exploitation pour accueillir l'au moins une unité en fonction d'un résultat d'un test relatif à un critère de placement relatif à un flux de données acheminé par l'au moins une unité. L'entité d'administration émet alors à destination de l'entité de médiation de l'au moins une application logicielle d'exploitation déterminée un message de configuration de l'au moins une unité dans l'au moins une application logicielle d'exploitation déterminée, ledit message de configuration comprenant un identifiant d'au moins une autre unité accès du réseau de communication.

Description

DESCRIPTION
Titre de l'invention : Procédé et dispositif de configuration d’une unité d’accès dans un environnement virtualisé
1. Domaine technique
L'invention concerne le déploiement automatisé ou la mise à jour d’une infrastructure d’accès d’un réseau de communications dans un environnement virtualisé basé sur une plate-forme de services s’appuyant sur des applications logicielles d’exploitation, telles que des conteneurs ou des machines virtuelles. Le déploiement automatisé de l’infrastructure d’accès prend en compte des paramètres de performances réseau, sécurité, énergie, coûts d’entités pour la distribution fonctionnelle et géographique des entités composant cette infrastructure.
2. Etat de la technique
Les architectures d’accès de réseaux de communications, et plus particulièrement les infrastructures d’accès de réseaux mobiles sont sujettes à des évolutions importantes. D’une infrastructure où l’ensemble des traitements (allocation de ressources, modulation, encodage...) permettant l’accès des terminaux étaient distribués dans les sites radio, au plus près des antennes, on s’oriente vers une centralisation plus ou moins importante de certaines de ces traitements en fonction de critères de disponibilité, de qualité de service et notamment de latence. Ainsi, notamment au 3GPP et au sein de l’alliance Open RAN, des travaux sont menés pour spécifier ces nouvelles infrastructures d’accès. On distingue dans ces nouvelles infrastructures trois entités identifiées CU (en anglais Centralized Unit), RU (en anglais Radio Unit) et DU (en anglais Distributed Unit). Ces unités se différencient par leur position dans le réseau de communication et donc également par leur nombre dans le réseau puisque plus une unité est proche de la station radio, plus il faut en déployer. Pour envisager le déploiement de telles nouvelles infrastructures, les traitements doivent être mis en œuvre dans l’une ou l’autre de ces entités. Il apparaît assez clairement que si une centralisation d’un traitement est plus avantageuse en termes de coût et de gestion, il présente également des inconvénients en termes de vulnérabilité et de latence notamment. De telles infrastructures d’accès peuvent donc avoir différentes instanciations selon le placement des traitements retenu dans les différentes unités et donc selon les interfaces requises entre les unités. Ces nouvelles infrastructures, nommées Cloud RAN (en anglais Cloud Radio Access Networks), sont en outre caractérisées par des mises en œuvre de logiciels déployés sur des serveurs informatiques banalisés, à moindre coût, l’intelligence et les services avancés étant mis en œuvre à partir des logiciels. Le déploiement de ces nouvelles architectures, notamment dans le cadre du développement des nouvelles architectures 5 G mais aussi pour les versions futures des réseaux mobiles, repose sur des techniques de virtualisation qui peuvent plus spécifiquement être des techniques de conteneurisation, cette dernière technique se caractérisant par l’absence d’hyperviseur en charge de gérer les différentes machines virtuelles. Une technique de gestion de conteneurs, par exemple mise en œuvre à partir d’une solution telle que Kubemetes, d’ores et déjà très utilisée dans les centres de données pourrait s’avérer très pertinente pour déployer au mettre à jour de façon automatique de telles architectures Cloud RAN. Kubemetes est une plate-forme permettant d'automatiser le déploiement, la montée en charge et la mise en œuvre de conteneurs d'application sur des groupes (ou clusters) de serveurs. Kubemetes est composé de deux parties, à savoir
- Les maîtres (en anglais masters) permettant de gérer l’ensemble des déploiements dans un groupe de serveurs. Il est composés de trois parties, à savoir une base de données ETCD (en anglais /etc distributed) stockant toutes les données du groupe de serveurs, un serveur (an anglais API server) qui permet entre autres au master de communiquer avec les nœuds comprenant les conteneurs, et les contrôleurs qui ont pour objet de vérifier le bon fonctionnement du groupe ainsi que les déploiements et les mises à jour.
- Les nœuds, qui peuvent être des machines physiques ou des machines virtuelles. Les conteneurs sont instanciés sur les nœuds. Un nœud comprend un kublet qui permet de communiquer avec le master et de gérer les déploiements sur le nœud, un kube-proxy permettant une communication externe au groupe de serveurs et un Pod dans lequel est exécuté un conteneur.
Le terme de cluster utilisé dans une telle solution de conteneurisation correspond à un ensemble Masters/Nodes tel que décrit ci-dessus.
Si la mise en œuvre d’une infrastructure Cloud RAN à partir d’une solution de conteneurisation, telle que Kubemetes, présente un intérêt certain, une telle mise en œuvre présente cependant quelques problèmes notamment relatifs au déploiement d’une telle solution sur des sites distribués. Une telle solution doit permettre de déployer un Cloud RAN dont certaines caractéristiques sont rappelées ci-après :
- une association unique entre un CU et un DU ainsi qu’entre un DU, un RU et une antenne doit être instanciée
L’architecture retenue doit permettre de respecter les critères de performance et notamment un délai maximal de 1 ms entre un DU et un RU - Un démarrage du Cloud RAN et donc des conteneurs des entités CU, DU, RU, est permis par des configurations initiales. Ainsi le DU doit connaître l’adresse IP du RU, le DU doit connaître l’adresse IP du CU etc...
Des contraintes spécifiques à une solution de conteneurisation, telle que Kuberenetes, dans un tel environnement distribué sont en outre rappelées ci-dessous:
La solution de conteneurisation ne permet pas de gérer des allocations externes à la solution elle-même et notamment pas l’allocation des antennes au conteneur du RU
La solution ne permet pas non plus l’échange de configurations entre les différents conteneurs permettant le déploiement du Cloud RAN et notamment le partage des informations d’adressage des conteneurs comprenant les entités CU, DU et RU du Cloud RAN
La vérification que le déploiement de conteneurs supportant les fonctions CU, DU et RU permettent de respecter les contraintes de performance de telles architectures distribuées d’infrastructure d’accès.
La présente invention a pour objet d’apporter des améliorations par rapport à l’état de la technique.
3. Exposé de l'invention
L'invention vient améliorer la situation à l'aide d'un procédé de configuration d’au moins une unité d’accès d’un réseau de communication dans un environnement virtualisé comprenant au moins une application logicielle d’exploitation, ledit procédé étant mis en œuvre dans une entité d’administration du réseau de communication et comprenant
- une réception en provenance d’une entité de médiation de l’au moins une application logicielle d’exploitation d’un message d’enregistrement de l’au moins une application logicielle d’exploitation associant un identifiant de l’au moins une application logicielle d’exploitation et un identifiant d’au moins un nœud supportant l’au moins une application logicielle d’exploitation,
- préalablement ou suite à la réception du message d’enregistrement, une détermination de l’au moins une application logicielle d’exploitation pour accueillir l’au moins une unité en fonction d’un résultat d’un test relatif à un critère de placement relatif à un flux de données acheminé par l’au moins une unité,
- une émission à destination de l’entité de médiation de l’au moins une application logicielle d’exploitation déterminée d’un message de configuration de l’au moins une unité dans l’au moins une application logicielle d’exploitation déterminée, ledit message de configuration comprenant un identifiant d’au moins une autre unité accès du réseau de communication.
Un déploiement d’une unité d’accès d’un réseau de communication, notamment de type mobile, dans un environnement virtualisé, tel qu’une architecture virtualisée requiert l’instanciation d’ applications logicielles d’exploitation, qui peuvent être des conteneurs ou des machines virtuelles ou toutes autres solutions permettant d’installer des solutions logicielles assurant l’acheminement de données dans un réseau. Un tel déploiement requiert de s’assurer que le positionnement de l’unité permette de respecter des contraintes de placement et notamment d’acheminement mais aussi que l’unité puisse avoir les informations de configuration suffisantes pour émettre et recevoir des données d’une autre unité de l’infrastructure. Typiquement, dans une architecture Cloud RAN, l’unité DU doit être déployée dans un conteneur permettant de respecter un certain débit ou une certaine latence par exemple, mais aussi que l’unité DU soit configurée avec des identifiants, tel que des adresses IP, d’un CU et d’un RU. Le procédé de configuration permet ainsi d’une part d’obtenir des identifiants d’applications logicielles d’exploitation et de nœuds, physiques ou virtualisés, supportant ces conteneurs, ce qui permet d’acheminer les données d’un nœud et d’une application logicielle d’exploitation à une autre. Le procédé permet en outre de s’assurer du respect de contraintes de déploiement d’une unité par rapport à la position et à la capacité des applications logicielles d’exploitation et donc des nœuds comprenant ces applications logicielles d’exploitation grâce à une détermination de l’application logicielle d’exploitation à partir d’un test. A partir du résultat de ce test, il est alors possible de pouvoir configurer l’unité (CU, DU, ou RU dans l’exemple) dans une application logicielle d’exploitation déterminée, puisqu’il a été déterminé que l’application logicielle d’exploitation pouvait effectivement satisfaire le besoin. L’infrastructure d’accès peut en outre être initialisée grâce aux informations de configuration puisque chaque unité détient une information de configuration d’une autre unité avec laquelle l’unité configurée émet et reçoit des données en provenance ou à destination de terminaux attachés à l’infrastructure d’accès.
Selon un aspect de l'invention, dans le procédé de configuration, le critère de placement relatif à un flux de données correspond à un ou plusieurs des critères de la liste suivante :
- une sécurité du flux du flux de données,
- une qualité de service d’acheminement du flux de données,
- une consommation énergétique lié au flux de données,
- une latence du flux de données, - une gigue du flux de données,
- une perte de données dans le flux,
- un acheminement du flux de données par l’intermédiaire d’un nœud du réseau de communication,
- un acheminement du flux de données par l’intermédiaire d’une suite ordonnée de nœuds du réseau de communications.
Le déploiement d’unités d’infrastructure d’accès, qu’il s’agisse d’un déploiement initial ou d’une mise à jour d’une infrastructure d’accès avec de nouvelles unités, doit respecter certaines contraintes. Ainsi, le choix d’un conteneur est avantageusement déterminé en fonction d’un critère relatif à un critère de sécurité et de confidentialité de données gérées par un conteneur comprenant une unité, à un critère de QoS d’acheminement des données, de disponibilité d’une application logicielle d’exploitation et donc de l’unité supportée par l’application logicielle d’exploitation, de consommation énergétique de l’application logicielle d’exploitation dans l’environnement virtualisé pour acheminer le flux de données, ou bien encore de latence des données transitant par l’application logicielle d’exploitation. La détermination et la disponibilité d’un nœud du réseau par lequel un flux de données doit transiter peut également être utilisé comme critère de placement. Plusieurs de ces critères peuvent avantageusement être considérés dans le test pour déterminer l’application logicielle d’exploitation optimal pouvant héberger l’unité à configurer.
Selon un autre aspect de l’invention, dans le procédé de configuration, le test relatif à un critère de placement comprend une comparaison d’un délai d’acheminement d’un flux de données en provenance, respectivement à destination, de l’au moins une application logicielle d’exploitation et à destination, respectivement en provenance d’une autre application logicielle d’exploitation de l’environnement virtualisé, avec une valeur d’acheminement d’un flux de données de référence.
De façon plus spécifique, et parce que le délai d’acheminement doit être pris en compte par rapport à un trafic type (par exemple de type IoT (en anglais Internet of Things), de type streaming vidéo, de type voix...), il peut être avantageux d’évaluer une application logicielle d’exploitation par sa capacité à effectivement assurer un acheminement correspondant aux prérequis d’un trafic type sélectionné, par exemple en choisissant le service le plus contraignant en terme de délai de transit dans un ensemble de données associées à une pluralité de services. Selon un autre aspect de l’invention, dans le procédé de configuration, le test relatif à un critère de placement comprend une comparaison d’un délai d’acheminement et une mesure de qualité de service d’un flux de données en provenance, respectivement à destination, de l’au moins une application logicielle d’exploitation et à destination, respectivement en provenance d’une autre application logicielle d’exploitation de l’environnement virtualisé, avec des valeurs théoriques d’acheminement propres à une architecture spécifique du réseau de communication.
Les architectures des infrastructures, et notamment le choix du positionnement des différentes fonctions (modulation, codage...) dans une unité induit des capacités d’acheminement et de qualité de service spécifiques entre les unités. Par exemple, dans le cadre d’une architecture Cloud RAN, différents scénarios de déploiement ont été spécifiés, donnant lieu à des besoins spécifiques d’acheminement, telle que de débit, de latence ou plus globalement de qualité de service, par exemple. La comparaison de mesures de tests avec de tels besoins permet de déterminer le ou les application(s) logicielle(s) d’exploitation le(s) plus adapté(s) pour héberger une unité d’accès du réseau de communication.
Selon un autre aspect de l’invention, dans le procédé de configuration, l’au moins une application logicielle d’exploitation est en outre déterminée en fonction de la position géographique d’un équipement d’attachement du réseau de communication.
Notamment, pour la détermination de l’application logicielle d’exploitation apte à accueillir une entité positionnée au plus près d’un équipement d’attachement, tel qu’une antenne, le choix d’une application logicielle d’exploitation tient compte de la position de l’équipement d’attachement pour des raisons de déploiement, de latence des données, et de respects de conditions d’acheminement lié aux services dont les données sont acheminées sur le réseau de communication comprenant les applications logicielles d’exploitation.
Selon un autre aspect de l’invention, le procédé de configuration comprend en outre
- au moins une émission à destination d’une entité d’administration de l’environnement virtualisé d’un message de requête de l’au moins un nœud dans l’environnement virtualisé
- au moins une réception en provenance de l’entité d’administration de l’environnement virtualisé d’un message de réponse comprenant un identifiants de l’au moins un nœud. Le procédé peut avantageusement comprendre des étapes permettant à l’entité d’administration du réseau de communication d’obtenir régulièrement une mise à jour de l’environnement virtualisé et une liste des nœuds effectivement déployés supportant une application logicielle d’exploitation pouvant théoriquement accueillir une unité d’une infrastructure d’accès. Ces étapes, répétées dans le temps de façon périodique ou non, procure à l’entité d’administration du réseau de communication une connaissance à jour de l’environnement virtualisé utilisé pour le déploiement ou la mise à jour de l’infrastructure d’accès. L’entité d’administration de l’environnement virtualisé est, selon un exemple, un nœud « master Kubemetes ».
Selon un autre aspect de l’invention, dans le procédé de configuration, le message de réponse comprend en outre une donnée de localisation de l’au moins un nœud.
Le message de réponse reçu en provenance de l’entité d’administration de l’environnement virtualisé peut avantageusement comprendre des données de localisation des nœuds notamment dans la perspective de pouvoir déployer une unité de l’infrastructure au plus près d’un équipement d’attachement ou pour gérer les interactions nécessaires entre les unités de l’infrastructure en tenant compte des contraintes géographiques de leur instanciation dans les conteneurs compris dans les nœuds.
Selon un autre aspect de l’invention, le procédé de configuration comprend en outre la réception d’un message de commande d’une mise à jour du réseau de communication comprenant une donnée géographique d’au moins une unité d’accès du réseau.
Le message de réponse reçu en provenance de l’entité d’administration de l’environnement virtualisé peut avantageusement comprendre des données de localisation des nœuds notamment dans la perspective de pouvoir déployer une unité de l’infrastructure au plus près d’un équipement d’attachement ou pour gérer les interactions nécessaires entre les unités de l’infrastructure en tenant compte des contraintes géographiques de leur instanciation dans les conteneurs compris dans les nœuds.
Selon un autre aspect de l’invention, le procédé de configuration comprend en outre la réception d’un message de commande d’une mise à jour du réseau de communication comprenant une donnée géographique d’au moins une unité d’accès du réseau.
Le message de commande correspond par exemple à une nouvelle affiliation d’une unité d’accès. L’entité d’administration du réseau de communication reçoit une commande de mise à jour, pouvant correspondre à une instanciation initiale, d’une infrastructure d’accès du réseau de communication par exemple, un déploiement d’une unité CU, d’une unité DU et d’une unité RU. La commande comprend une donnée géographique, par exemple une donnée GPS, d’une unité d’accès pour couvrir ou améliorer la couverture d’une nouvelle zone géographique par exemple. Ce message de commande peut être émis par un administrateur réseau ou un logiciel externe tel qu’un logiciel ONAP (en anglais Open Network Automation Platform).
Selon un autre aspect de l’invention, dans le procédé de configuration, le message de configuration comprend en outre un paramètre de configuration relatif à un équipement d’attachement au réseau de communication.
Des paramètres de configuration relatifs à l’équipement d’attachement, par exemple à une antenne, peuvent être avantageusement transmis à une entité de médiation, notamment s’il s’agit d’une entité de médiation d’une unité en charge des fonctions devant être activées au plus près de l’équipement d’attachement, tel qu’une unité RU dans une infrastructure Cloud RAN. Il existe une dépendance forte entre un équipement d’attachement, tel qu’une antenne et un RU en particulier. Pour que le système d’accès déployé fonctionne correctement, le RU obtient un minimum d’information sur le type de l’antenne. Par exemple, concernant les paramètres de configuration, un code FPGA qui s’exécute dans l’antenne est nécessaire et il est avantageux d’avoir la version précise de l’antenne pour exécuter le bon code ou encore comment contacter l’antenne (port USB, interface réseau,...).
Selon un autre aspect de l’invention, le procédé de configuration comprend en outre un message d’obtention auprès d’une base de données d’un ensemble d’applications logicielles d’exploitation, ledit ensemble étant relatif à la donnée géographique d’une unité d’accès de l’infrastructure.
Notamment lorsqu’il a reçu un message de commande d’une mise à jour, l’entité d’administration du réseau de communication sollicite une base de données comprenant les nœuds et les applications logicielles d’exploitation de l’environnement virtualisé. La base de données retourne à l’entité d’administration des applications logicielles d’exploitation et possiblement des identifiants des nœuds supportant les applications logicielles d’exploitation correspondant à une donnée géographique, par exemple une donnée GPS, d’une unité d’accès, par exemple située au plus proche d’une antenne de l’infrastructure d’accès. Avantageusement, la base de données renvoie les adresses IP des applications logicielles d’exploitation pouvant accueillir des unités du réseau de communication ainsi que les adresses IP des nœuds comprenant ces applications logicielles d’exploitation. Ainsi, l’entité d’administration dispose d’une liste d’applications logicielles d’exploitation possibles parmi lesquels il déterminera les applications logicielles d’exploitation en charge d’accueillir les unités respectives en fonction de résultats de tests. La base de données peut en outre avantageusement comprendre et renvoyer des paramètres d’un équipement d’attachement (antenne), le type d’équipement d’attachement pouvant influer sur la localisation des unités de l’infrastructure dans applications logicielles d’exploitation.
Les différents aspects du procédé de configuration qui viennent d'être décrits peuvent être mis en œuvre indépendamment les uns des autres ou en combinaison les uns avec les autres.
L’invention concerne également un procédé de gestion d’au moins une unité d’accès d’un réseau de communication dans un environnement virtualisé comprenant au moins une application logicielle d’exploitation, ledit procédé étant mis en œuvre dans une entité de médiation de l’au moins une application logicielle d’exploitation et comprenant
- une émission à destination d’une entité d’administration du réseau de communication d’un message d’enregistrement de l’au moins une application logicielle d’exploitation associant un identifiant de l’au moins une application logicielle d’exploitation et un identifiant d’au moins un nœud supportant l’au moins une application logicielle d’exploitation,
- une réception en provenance de l’entité d’administration du réseau de communication d’un message de configuration de l’au moins une unité dans l’au moins une application logicielle d’exploitation déterminée par l’entité d’administration, ledit message de configuration comprenant un identifiant d’au moins une autre unité du réseau de communication,
- une configuration de l’au moins une application logicielle d’exploitation sur la base du message de configuration reçu,
- une activation de l’au moins une unité d’accès dans l’au moins application logicielle d’exploitation configurée.
L’invention concerne également un dispositif de configuration d’au moins une unité d’accès d’un réseau de communication dans un environnement virtualisé comprenant au moins une application logicielle d’exploitation, et comprenant
- un récepteur, apte à recevoir en provenance d’une entité de médiation de l’au moins une application logicielle d’exploitation d’un message d’enregistrement de l’au moins une application logicielle d’exploitation associant un identifiant de l’au moins une application logicielle d’exploitation et un identifiant d’au moins un nœud supportant l’au moins une application logicielle d’exploitation,
- un module de détermination, apte à déterminer, préalablement ou suite à la réception du message d’enregistrement, l’au moins une application logicielle d’exploitation pour accueillir l’au moins une unité en fonction d’un résultat d’un test relatif à un critère de placement relatif à un flux de données acheminé par l’au moins une unité,
- un émetteur, apte à émettre à destination de l’entité de médiation de l’au moins une application logicielle d’exploitation déterminée d’un message de configuration de l’au moins une unité dans l’au moins une application logicielle d’exploitation déterminée, ledit message de configuration comprenant un identifiant d’au moins une autre unité accès du réseau de communication.
Ce dispositif, apte à mettre en œuvre dans tous ses modes de réalisation le procédé de configuration qui vient d'être décrit, est destiné à être mis en œuvre dans un équipement d’administration d’un réseau de communication ou bien dans un équipement de gestion d’une infrastructure d’accès, telle qu’une infrastructure C-RAN.
L’invention concerne également un dispositif de gestion d’au moins une unité d’accès d’un réseau de communication dans un environnement virtualisé comprenant au moins une application logicielle d’exploitation, comprenant
- un émetteur, apte à émettre à destination d’une entité d’administration du réseau de communication, un message d’enregistrement de l’au moins une application logicielle d’exploitation associant un identifiant de l’au moins une application logicielle d’exploitation et un identifiant d’au moins un nœud supportant l’au moins une application logicielle d’exploitation,
- un récepteur, apte à recevoir en provenance de l’entité d’administration du réseau de communication, un message de configuration de l’au moins une unité dans l’au moins une application logicielle d’exploitation déterminée par l’entité d’administration, ledit message de configuration comprenant un identifiant d’au moins une autre unité du réseau de communication,
- un configurateur, apte à configurer l’au moins une application logicielle d’exploitation sur la base du message de configuration reçu,
- un activateur, apte à activer l’au moins une unité d’accès dans l’au moins application logicielle d’exploitation configurée.
Ce dispositif, apte à mettre en œuvre le procédé de gestion qui vient d'être décrit, est destiné à être mis en œuvre dans un équipement physique ou virtualisé, tel qu’un serveur ou une station d’accueil banalisée.
L’invention concerne également un système de configuration d’au moins une unité d’accès d’un réseau de communication dans un environnement virtualisé comprenant au moins une application logicielle d’exploitation, et comprenant un dispositif de configuration et un dispositif de gestion.
L'invention concerne aussi des programmes d'ordinateur comprenant des instructions pour la mise en œuvre des étapes des procédés respectifs de configuration et de gestion qui viennent d’être décrits, lorsque ces programmes sont l’un et l’autre exécutés par un processeur et un support d’enregistrement lisible respectivement par un dispositif de configuration et de gestion sur lesquels sont enregistrés les programmes d’ordinateurs. Les programmes mentionnés ci-dessus peuvent 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.
Les supports d’informations mentionnés ci-dessus peuvent être n’importe quelle entité ou dispositif capable de stocker le programme. Par exemple, un 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.
Un tel moyen de stockage peut par exemple être un disque dur, une mémoire flash, etc. D’autre part, un support d’informations 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. Un programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, un support d'informations peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l’exécution des procédés en question.
4. Brève description des dessins
D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :
La [Fig 1] présente une vue simplifiée d’un réseau de communication dans lequel sont mis en œuvre le procédé de configuration et le procédé de gestion selon un aspect de l’invention,
La [Fig 2] présente une vue simplifiée d’un réseau de communication dans lequel sont mis en œuvre le procédé de configuration et le procédé de gestion selon un autre aspect de l’invention, La [Fig 3] présente un aperçu du procédé de configuration et du procédé de gestion selon un mode de réalisation de l’invention,
La [Fig 4] présente un dispositif de configuration selon un mode de réalisation de l'invention,
La [Fig 5] présente un dispositif de gestion selon un mode de réalisation de l’invention.
5. Description des modes de réalisation
Dans la suite de la description, on présente des modes de réalisation de l’invention dans un réseau de communication. Ce réseau peut être mise en œuvre pour acheminer des données de communication à destination de terminaux fixes ou mobiles. L’invention peut être destinée à déployer ou mettre à jour des unités d’accès d’un réseau de communications, les unités d’accès étant définies comme des unités permettant à des terminaux d’acheminer des données à destination de serveurs de données ou d’autres terminaux via le réseau de communications.
On se réfère tout d’abord à la [Fig 1] qui présente une vue simplifiée d’un réseau de communication dans lequel sont mis en œuvre le procédé de configuration et le procédé de gestion selon un aspect de l’invention.
Un réseau 20 de communication est composé d’une unité d’accès RU, d’une entité DU et d’une entité CU permettant que des flux de données soient acheminés à destination et en provenance d’un réseau cœur CN. Le réseau 20 comprend en outre un équipement d’attachement 130, représenté par une antenne de type cellulaire selon cet exemple, permettant à un terminal 120 de pouvoir transmettre et recevoir des données via le réseau 20. L’équipement d’attachement 130 peut comprendre une pluralité d’antennes. Sur la [Fig 1], une seule unité de type RU, DU, CU ainsi qu’un seul équipement d’attachement n’est représenté mais un réseau peut comprendre une pluralité d’unités et d’équipement d’attachement peuvent être compris dans ce réseau 20. Cette structuration en trois unités RU/DU/CU d’un réseau est également identifiée dans l’art antérieur comme une architecture Cloud-RAN. Ainsi, au sein de l’organisme de normalisation 3GPP, la distribution des fonctions et des traitements permettant l’acheminement de données dans le réseau 20 dans l’une ou l’autre des unités RU/DU/CU donnent lieu à des discussions et à des spécifications. Ainsi, une dizaine d’options aussi appelées Split ont été définies au sein du 3GPP selon que l’on centralise ou non certaines fonctions en considérant l’impact sur les liens entre les unités et sur les services pour les utilisateurs. Par exemple, le split 7.3 prévoit d’encoder et de décoder les signaux dans l’unité DU et ainsi de réduire le coût financier des liaisons entre l’unité RU et l’unité DU, aussi appelée Fronthaul. Cette structuration du réseau 20 en unités s’accompagne par ailleurs d’une virtualisation des unités RU/DU/CU permettant d’en réduire le coût et d’en faciliter le déploiement et/ou la mise à jour par l’utilisation de nœuds banalisés, sous forme de serveurs informatiques, et de logiciels déployés sur ces nœuds, sous formes de VNFs (en anglais Virtual Network Functions) ou CNFs (en anglais Cloud Native Network Functions) selon le type d’infrastructure sélectionnée pour la mise en œuvre du réseau 20. Ces logiciels permettent ainsi de mettre en œuvre les différentes fonctions et traitement requis pour l’acheminement des données. Le déploiement d’un tel réseau 20 de type cloud RAN repose sur un découpage en trois zones géographiques, les espaces de données (en anglais clouds) régionaux, les espaces de données d’extrémité (en anglais edge clouds), les espaces de données de bordure (en anglais far edge clouds) notamment définie par l’alliance O-RAN (en anglais Open Radio Access Network). Dans la [Fig 1], est également représenté un environnement virtualisé 10. Selon cet exemple, l’environnement virtualisé 10 est basé sur une plate-forme Kubemetes, représentant une solution d’orchestration d’applications logicielles d’exploitation représentées ici par des conteneurs, mais il pourrait également s’agir d’une plate-forme de virtualisation distincte de Kubemetes. Cet environnement virtualisé est composé d’un maître Kubemetes KM et de nœuds KN 1 , KN2, KN3 qui peuvent être des machines physiques ou bien des machines virtuelles. Selon une alternative, l’équipement d’attachement 130, comprenant une ou plusieurs antennes, peut lui-même être un nœud tel que les nœuds KN1, KN2, KN3 et peut accueillir une unité CU, DU ou RU. Il est à noter que ce mode de réalisation est notamment pertinent pour le déploiement de l’unité RU dans un équipement disposant également d’une ou plusieurs antennes, de façon à réduire le temps de latence de transmission de données entre une antenne et l’unité RU. Chaque nœud contient les services nécessaires à l’exécution de Pods, c’est-à-dire des lieux d’exécution des applications logicielles d’exploitation. Sur la [Fig 1] sont représentés trois nœuds KN1, KN2 et KN3 mais un plus grand nombre de nœuds peuvent être compris dans l’environnement virtualisé 20. Les nœuds KN1, KN2 et KN3 comprennent respectivement les applications logicielles d’exploitation Cl, C2, C3. Conformément à l’architecture du réseau Cloud RAN décrit ci-dessus, le maître Kubemetes KM est déployé dans l’espace de données régional et les nœuds KN1, KN2 et KN3 sont déployés dans les espaces de données régionaux ou les espaces de données d’extrémité ou les espaces de données de bordure. Un administrateur réseau ou bien encore un logiciel tiers, par exemple de type ONAP (en anglais Open Network Automation Platform) requiert auprès du maître Kubemetes KM le déploiement d’applications logicielles d’exploitation Cl, C2, C3 dans les nœuds KN1, KN2, KN3. A ce stade, les applications logicielles d’exploitation Cl, C2 et C3 ne sont pas activées et ne sont pas en mesure d’acheminer des données. Cette étape permet d’initialiser les applications logicielles d’exploitation. Ces applications logicielles d’exploitation comprennent des entités de médiation permettant de pouvoir interagir avec le maître KM. Ainsi, une unité de type CU est déployée dans une application logicielle d’exploitation Cl du nœud KN1 régional, une unité de type DU est déployée dans une application logicielle d’exploitation C3 d’un nœud KN3 d’extrémité et une unité RU est déployée dans une application logicielle d’exploitation C2 d’un nœud KN2 de bordure. Le procédé de configuration, selon ce mode de réalisation, permet de déterminer le conteneur Cl, C2 ou C3 le plus adapté pour accueillir une unité d’accès donnée et de pouvoir configurer cette unité sur l’application logicielle d’exploitation la plus adaptée, notamment par rapport à la situation géographique de l’équipement d’attachement et/ou de critères de placement relatif à un flux de données, par exemple émis ou reçu par le terminal 120, acheminé par une unité d’accès donnée. Le positionnement de l’unité RU par rapport à l’équipement d’attachement est en particulier à considérer sachant qu’il est important d’éviter une latence trop forte entre l’antenne et l’unité RU.
En relation avec la [Fig 2], on présente une vue simplifiée d’un réseau de communication dans lequel sont mis en œuvre le procédé de configuration et le procédé de gestion selon un autre aspect de l’invention.
Dans cette [Fig 2], on retrouve les mêmes entités que celles présentées dans la [Fig 1] ainsi qu’une entité 100 d’administration du réseau 20 de communications. Cette entité 100 d’administration, qui peut également être dénommée BCRS (en anglais Bootstrapper cloud-RAN server) peut être, selon un exemple, être déployée dans un espace de données régional et permet notamment de gérer la liste des ressources hardware et d’assurer leur gestion. Il permet en outre de mettre en relation les différents éléments du Cloud RAN et notamment les différentes unités RU/DU/CU, ainsi que la gestion des performances et notamment les mesures de performances entre les unités RU/DU/CU. Cette entité est distincte d’un maître KM mais selon une alternative, il peut être instancié dans un maître KM. Dans la [fig 2] sont également représentés des entités de médiation EM1, EM2, et EM3 des applications logicielles respectives d’exploitation Cl, C2, C3. Une entité de médiation EM1 ou EM2 ou EM3 est également dénommée B CRC (en anglais Bootstrapper Cloud-RAN client) et permet notamment à une application logicielle d’exploitation (Cl ou C2 ou C3) d’interagir avec l’entité 100 d’administration.
L’entité d’administration, préalablement à la réception en provenance d’une entité de médiation de l’une des applications logicielles d’exploitation EM1, EM2, EM3 peut, selon un exemple, requérir auprès du maître KM une liste de nœuds KN1, KN2 et KN3 qu’il gère. En retour, le maître KM retourne à l’entité d’administration 100 une liste d’ identifiants, tels que des adresses IP s’il s’agit d’un réseau IP, des nœuds KN1, KN2 et KN3, ainsi qu’une information ou un label sur la zone géographique dans laquelle est déployée un réseau de communication à 3 niveaux : régional, extrémité et bordure dans laquelle se trouve le nœud KN1, KN2 ou KN3 ainsi que possiblement un état du nœud pour indiquer s’il est effectivement actif ou non dans l’espace virtualisé 10. Ces informations reçues par l’entité 100 d’administration pourront être sauvegardées ensuite dans une base de données, et ainsi être disponibles en cas de besoin. Durant cette phase de découverte de l’environnement virtualisé 10 par l’entité 100 d’administration, la recherche de l’ensemble des équipements d’accès, ici représentés par l’antenne 130 est effectuée. Cette recherche est effectuée en sollicitant les nœuds parmi les nœuds KN1, KN2, KN3 se trouvant dans un espace de données de bordure et en outre dans un état actif ou prêt ou encore prêt dans un intervalle de temps, sachant que seul un espace de données de bordure est apte à comprendre une antenne à laquelle le terminal 120 peut s’attacher. En l’occurrence, selon l’exemple décrit pour la [Fig 1], l’entité 100 d’administration sollicite le nœud KN2 pour rechercher si une antenne est disponible mais selon un exemple où une pluralité de nœuds localisés dans des espaces de données de bordure sont disponibles, l’entité 100 d’administration solliciterait ces différents nœuds. En retour, les nœuds sollicités transmettent à l’entité 100 d’administration les paramètres de connexion à une antenne tels que les ports USB, les informations de types FPGA (en anglais Field Programmable Gâte Array) propre à l’antenne, le type d’antenne et les coordonnées de localisation de l’espace de données de bordure, tel qu’une information de localisation GPS (en anglais Global Positioning System). Selon une alternative, l’entité 100 d’administration peut transmettre une requête à une base de données topologique comprenant l’ensemble des informations des déploiements d’équipements physiques d’une zone pour obtenir les informations sur les antennes disponibles dans des espaces de données de bordure. Pour cibler ces espaces de données de bordure, les identifiants des nœuds des espaces de données de bordure peuvent selon un exemple être transmis en paramètre de la requête transmise. L’entité 100 d’administration peut également sauvegarder ces informations reçues sur les antennes dans une base de données. Ces différentes étapes de découvertes de nœuds et d’antennes par l’entité 100 d’administration peuvent être répétées pour que l’entité 100 d’administration ait une cartographie à jour. L’entité 100 d’administration peut également procéder à la configuration d’une unité en l’absence de ces étapes, par exemple en recourant à une base de données qu’il aura lui- même mis à jour ou mise à jour par une autre entité.
Selon une alternative, ou pour mettre à jour un réseau d’accès dans un environnement virtualisé, un administrateur réseau ou bien encore un logiciel tiers, par exemple de type ONAP sollicite l’entité 100 d’administration pour déployer une ou plusieurs unités CU/DU/RU dans l’espace virtualisé 20. Selon un exemple, une information de localisation d’une unité RU est transmise en paramètre de cette sollicitation par exemple pour couvrir ou améliorer la couverture du réseau de communication à trois niveaux donnée correspondant à l’information de localisation de l’entité RU, proche d’une antenne de réception. L’entité 100 d’administration peut ainsi requérir auprès d’une base de données, qu’il aura lui-même précédemment mis à jour ou non, une liste de nœuds KN1, KN2, KN3 susceptibles de répondre aux besoins de la demande de déploiement. La base de données peut rechercher les nœuds KN1, KN2, KN3 les plus proches de l’information de localisation reçue lors de la demande de déploiement et transmise à la base de données. La base de données transmet en retour à l’entité 100 d’administration les associations nœuds (KN1, KN2, KN3)/applications logicielles d’exploitation (Cl, C2, C3) qu’elle juge possible pour le déploiement ou la mise à jour du cloud RAN. L’ensemble des combinaisons pour l’unité CU, c’est-à-dire un identifiant de l’unité CU et identifiant du nœud KN1 ou KN2 ou KN3, et de la même façon pour l’unité DU et l’unité RU. Les paramètres de l’équipement d’attachement peuvent également être transmis. L’entité 100 d’administration procède à une affiliation CU/DU/RU/antenne en fonction de la réponse reçue de la base de données. Les nœuds retenus à cette étape sont alors candidats à une sélection pour évaluer leur capacité à être conforme à des critères de placement voire des critères de localisation.
En lien avec la [Fig 3], on présente un aperçu du procédé de configuration et du procédé de gestion selon un mode de réalisation de l’invention. Dans ce mode de réalisation, les applications logicielles d’exploitation sont des conteneurs. Dans cette [Fig 3], on retrouve les mêmes entités que celles présentées dans la [Fig 1] et le [Fig 2]
Fors d’une étape E 1 , les entités de médiation EM 1 , EM2 et EM3 des conteneurs respectifs Cl, C3, C3 transmettent respectivement à l’entité 100 d’administration des messages d’enregistrement des conteneurs Cl, C2, C3. Ces messages d’enregistrement envoyés individuellement par chaque entité de médiation EM1, EM2 et EM3 comprennent un identifiant du conteneur considéré, tel qu’une adresse IP ainsi qu’un identifiant du nœud sur lequel est déployé le conteneur. Selon ce mode de réalisation, et en cohérence avec les [Fig 1] et [Fig 2], les entités de médiation EM1, EM2, EM3 transmettront respectivement un identifiant, tel qu’une adresse IP, des nœuds KN1, KN2 et KN3. Il est à noter que selon une alternative, seule une ou plusieurs entités de médiation parmi EM1, EM2, EM3 peuvent transmettre un message d’enregistrement à l’entité 100 d’administration. Les identifiants, ici les adresses IP, sont par exemple allouées dynamiquement aux conteneurs Cl, C2 et C3 ainsi qu’aux nœuds KN1, KN2, KN3 et ne peuvent être connues de l’entité 100 d’administration avant cet envoi et le démarrage effective du conteneur.
De façon optionnelle, lors d’une étape E2, l’entité 100 de médiation peut sauvegarder les données reçues lors de l’étape El et relatives aux conteneurs dans une base de données, par exemple identique à celle décrite dans la [Fig 2], permettant ainsi de pouvoir être réutilisées le cas échéant.
Il est à noter que cette étape d’enregistrement peut se produire après l’étape d’initialisation des conteneurs telle que décrite dans la [Fig. 1]
En outre, cette étape E 1 peut être exécutée suite ou précédemment à une étape d’ affiliation CU/DU/RU/antenne telle que décrite dans la [Fig 2]
Lors d’une étape E3, l’entité 100 d’administration détermine un conteneur pour accueillir une unité CU/DU/RU en fonction d’un résultat d’un test relatif à un critère de placement lié à un flux de données acheminé par l’unité à déployer dans un conteneur. Il est à noter que cette étape E3 de détermination peut se produire avant l’étape El et suite aux étapes d’initialisation et d’affiliation décrites dans les [Fig 1] et [Fig 2]
Un exemple d’étape de détermination est décrit ci-dessous. Afin de déterminer les conteneurs aptes à accueillir une unité CU et/ou une unité DU et/ou une unité RU, l’entité 100 d’administration demande au master KM (non représenté sur la [Fig 3] mais représentés sur les [Fig 1] et [Fig 2]), la création de l’ensemble des conteneurs nécessaires pour simuler un trafic d’un cloud RAN et en obtenir les informations résultant de cette simulation. Le Master KM crée les conteneurs suivantes dans un espace de données régional : un émetteur pour émettre les données pour simuler le flux de données en aval (en anglais download), un récepteur pour recevoir les données dans le sens amont (en anglais upload), une unité CU de test permettant de router les données d’un flux vers une unité DU de test dans le sens aval et vers le récepteur de l’espace de données régional dans le sens amont. Le Master KM crée en outre une unité DU dans un espace de données d’extrémité pour que celui-ci route les données vers une unité RU dans le sens aval et vers l’unité CU dans le sens amont. Le master KM crée en outre dans un espace de données de bordure un récepteur pour réceptionner les données d’un flux dans le sens aval, un émetteur pour envoyer des données d’un flux simulé dans le sens amont et une unité RU pour acheminer les données vers le récepteur de l’espace de données de bordure dans le sens aval et vers l’unité DU de test dans le sens amont.
Un flux de données de test est généré et transmis par les émetteurs respectifs des espaces de données à destinations des récepteurs respectifs pour simuler les flux de données aval et amont. Selon un exemple, les flux de données caractérisant des options d’architecture d’une infrastructure Cloud RAN sont émis, ces flux de données pouvant être différenciés selon le sens de transmission, amont ou aval, et selon les technologies des interfaces entre les entités de l’infrastructure.
L’entité 100 d’administration récupère ensuite les informations enregistrées dans les différentes entités de tests créées dans les espaces régionaux, d’extrémité et de bordure. Ces informations enregistrées comprennent par exemple des paramètres de qualité d’acheminement du flux de données tel que par exemple le débit réel atteint, des critères de disponibilité de l’unité, des critères énergétiques tels que la consommation énergétique de l’unité pour acheminer le flux de données, un critère de latence, de gigue du flux de données, un critère de perte de données voire un critère d’acheminement par un équipement en particulier ou non. Ces critères de placement obtenus permettent de pouvoir qualifier une unité et son bon ou mauvais placement dans l’environnement virtualisé.
Le test relatif à un ou plusieurs critères de placement peut avantageusement comprendre une comparaison avec une valeur de référence pour le flux de données, tel que par exemple un délai d’acheminement de référence. Notamment, pour déterminer un conteneur apte à accueillir une unité, l’entité 100 d’administration peut comparer un délai d’acheminement d’un flux de données dans une unité déployé dans un conteneur Cl, C2, C3 de l’environnement virtualisé avec une valeur de référence d’une architecture spécifique du réseau de communication Cloud RAN, comme par exemple présentée dans le tableau ci-dessus, et à l’aide du résultat de cette comparaison, déterminer si le conteneur Cl, C2 ou C3 est apte à accueillir une unité CU ou DU ou RU. Selon une autre alternative, la valeur de référence est relative à un flux de données spécifique, par exemple d’un flux de données requérant une exigence particulière en termes de fiabilité et/ou de délai d’acheminement et/ou de latence.
Il est à noter que selon une alternative, le conteneur peut être également déterminé en fonction d’une position géographique d’un équipement d’attachement, tel qu’une antenne d’un réseau cellulaire par exemple. Notamment, le conteneur parmi les conteneurs Cl, C2, C3 pourra être sélectionné pour accueillir une unité RU en fonction de la position géographique d’une antenne de façon à réduire au maximum le délai de transit de données entre l’antenne et l’entité RU.
De façon optionnel, l’entité 100 d’administration requiert auprès des nœuds des espaces de données sur lesquels ont été instanciés les différents entités de tests la suppression de ces entités (émetteurs, récepteurs, CU de test, DU de test, RU de test) créées pour effectuer les tests requis pour la détermination des conteneurs Cl, C2, C3 aptes à accueillir les unités CU/DU/RU en fonction des critères utilisés et possiblement des informations de localisation citées ci-dessus.
Il est à noter que le mode de réalisation développé ci-dessus pour déterminer un ou plusieurs conteneurs est cité à titre d’exemple et que d’autres options sont possibles pour déterminer le(s) conteneur(s) tels que des résultats d’enregistrement de données relatives à des conteneurs déjà déployés ou déployés précédemment ou bien encore en utilisant des valeurs théoriques par exemple à partir d’abaques.
Dans le cas où aucun conteneur ne répond aux exigences (débit, latence, fiabilité...), de nouveaux nœuds candidats pour accueillir des conteneurs pourront être sélectionnés et évalués conformément à l’étape de détermination décrite ci-dessus. Ces nouveaux nœuds seraient alors identifiés dans une nouvelle étape d’affiliation.
Lors d’une étape E4, l’entité 100 d’administration émet à destination des entités de médiation EM1, EM2, EM3 des conteneurs Cl, C2, C3 respectifs sélectionnés suite à l’étape E3 de détermination et dûment enregistrés sur les nœuds respectifs KN1, KN2, KN3 un message de configuration d’une unité CU dans le conteneur Cl, d’une unité DU dans le conteneur C3 et d’une unité RU dans le conteneur C2. Le message de configuration comprend, selon un exemple, les adresses IP des unités, la version de logiciels utilisés dans les unités, l’antenne à utiliser pour l’unité RU voire des configurations réseau spécifiques tels que des protocoles et des numéros de ports, vore même une durée de vie des entités de médiation. Le message de configuration transmis à l’entité de médiation EM1 du conteneur Cl, visant à configurer une unité CU, comprend en outre un identifiant, tel que par exemple une adresse IP, de l’unité DU permettant ainsi à l’unité CU de connaître l’entité DU avec laquelle il échangera les données des flux. Le message configuration transmis à l’entité de médiation EM3 du conteneur C3, visant à configurer une unité DU, comprend en outre un identifiant, tel que par exemple une adresse IP, de l’unité CU ainsi qu’un identifiant (adresse IP) d’une unité RU. L’entité DU connaît ainsi les entités CU et RU avec lesquelles il communique dès son initialisation et sans configuration statique des conteneurs Cl et C3. Le message de configuration transmis à l’entité de médiation EM2 du conteneur C2, visant à configurer une unité RU, comprend en outre un identifiant, tel que par exemple une adresse IP, de l’unité DU permettant ainsi à l’unité RU de connaître l’entité DU avec laquelle il échangera les données des flux. Ce message de configuration, transmis à l’entité de médiation EM2 comprend en outre des données caractérisant un équipement d’attachement, tel qu’une antenne, ne serait-ce que pour que l’unité RU puisse communiquer avec l’équipement d’attachement en utilisant la bonne interface et le bon algorithme de codage/décodage des données.
Lors d’une étape E5, les entités de médiation EM1, EM2 et EM3 ayant reçu les informations de configuration des conteneurs Cl, C2, C3 leur permettant d’effectivement accueillir les entités respectives CU, RU et DU configurent ces conteneurs avec les informations obtenues de façon à ce que l’infrastructure Cloud RAN puisse être initialisée ou bien mise à jour.
Lors de l’étape suivante E6, les entités EM1, EM2 et EM3 démarrent les applications logicielles correspondant aux unités CU/DU/RU dans les conteneurs Cl, C3 et C2 respectifs. Le service d’accès au réseau élaboré à partir des unités d’accès CU/DU/RU dans les conteneurs Cl, C3, C2 déterminés en fonction de leur capacité à satisfaire des critères de placement, voire à répondre à une contrainte de localisation et déployés sur des nœuds physiques ou virtualisés KN1, KN3 et KN2, peut démarrer.
Selon une alternative, les étapes E5 et E6 peuvent être exécutées conjointement et le démarrage des applications logicielles peut être effectué lors de la configuration des unités Cl, C2, C3 par les entités de médiation respectives EM1, EM2 et EM3.
En relation avec la [Fig 4], on présente un dispositif 500 de configuration selon un mode de réalisation de l'invention.
Un tel dispositif de configuration peut être mis en œuvre dans un équipement d’administration, tel que l’entité 100 d’administration du réseau selon les [Fig 2] et (Fig 3], d’un réseau de communication ou bien dans un équipement de gestion d’une infrastructure d’accès, telle qu’une infrastructure C-RAN.
Par exemple, le dispositif 500 comprend une unité de traitement 530, équipée par exemple d'un microprocesseur mR, et pilotée par un programme d'ordinateur 510, stocké dans une mémoire 520 et mettant en œuvre le procédé de configuration selon l’invention. A l’initialisation, les instructions de code du programme d’ordinateur 510 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 530. Un tel dispositif 500 de configuration comprend :
- un récepteur 501, apte à recevoir en provenance d’une entité de médiation de l’au moins une application logicielle d’exploitation d’un message Enr d’enregistrement de l’au moins une application logicielle d’exploitation associant un identifiant de l’au moins une application logicielle d’exploitation et un identifiant d’au moins un nœud supportant l’au moins une application logicielle d’exploitation,
- un module 502 de détermination, apte à déterminer, préalablement ou suite à la réception du message d’enregistrement, l’au moins une application logicielle d’exploitation pour accueillir l’au moins une unité en fonction d’un résultat d’un test relatif à un critère de placement relatif à un flux de données acheminé par l’au moins une unité,
- un émetteur 503, apte à émettre à destination de l’entité de médiation de l’au moins une application logicielle d’exploitation déterminée d’un message Conf de configuration de l’au moins une unité dans l’au moins une application logicielle d’exploitation déterminée, ledit message de configuration comprenant un identifiant d’au moins une autre unité accès du réseau de communication.
La [Fig 5] présente un dispositif 600 de gestion selon un mode de réalisation de l'invention. Un tel dispositif de gestion peut être mis en œuvre dans est destiné à être mis en œuvre dans un équipement physique ou virtualisé, tel qu’un serveur ou une station d’accueil banalisée.
Par exemple, le dispositif 600 comprend une unité de traitement 630, équipée par exemple d'un microprocesseur mR, et pilotée par un programme d'ordinateur 610, stocké dans une mémoire 620 et mettant en œuvre le procédé de configuration selon l’invention. A l’initialisation, les instructions de code du programme d’ordinateur 610 sont par exemple chargées dans une mémoire RAM, avant d’être exécutées par le processeur de l’unité de traitement 630. Un tel dispositif 600 de configuration comprend : - un émetteur 601, apte à émettre à destination d’une entité d’administration du réseau de communication, un message Enr d’enregistrement de l’au moins une application logicielle d’exploitation associant un identifiant de l’au moins une application logicielle d’exploitation et un identifiant d’au moins un nœud supportant l’au moins une application logicielle d’exploitation,
- un récepteur 602, apte à recevoir en provenance de l’entité d’administration du réseau de communication, un message Conf de configuration de l’au moins une unité dans l’au moins une application logicielle d’exploitation déterminée par l’entité d’administration, ledit message de configuration comprenant un identifiant d’au moins une autre unité du réseau de communication,
- un configurateur 603, apte à configurer l’au moins une application logicielle d’exploitation sur la base du message de configuration reçu,
- un activateur 604, apte à activer l’au moins une unité d’accès dans l’au moins application logicielle d’exploitation configurée.

Claims

REVENDICATIONS
1. Procédé de configuration d’au moins une unité d’accès (CU, DU, RU) d’un réseau (20) de communication dans un environnement (10) virtualisé comprenant au moins une application logicielle d’exploitation (Cl, C2, C3), ledit procédé étant mis en œuvre dans une entité (100) d’administration du réseau (20) de communication et comprenant
- une réception en provenance d ’ une entité (EM 1 , EM2 , EM3 ) de médiation de 1 ’ au moins une application logicielle d’exploitation (Cl, C2, C3) d’un message d’enregistrement (Enr) de l’au moins une application logicielle d’exploitation (Cl, C2, C3) associant un identifiant de l’au moins une application logicielle d’exploitation et un identifiant d’au moins un nœud (KN1, KN2, KN3, 130) supportant l’au moins une application logicielle d’exploitation (Cl, C2, C3),
- préalablement ou suite à la réception du message d’enregistrement (Enr), une détermination de l’au moins une application logicielle d’exploitation (Cl, C2, C3) pour accueillir l’au moins une unité (CU, DU, RU) en fonction d’un résultat d’un test relatif à un critère de placement relatif à un flux de données acheminé par l’au moins une unité (CU, DU, RU),
- une émission à destination de l’entité de médiation (EM1, EM2, EM3) de l’au moins une application logicielle d’exploitation (Cl, C2, C3) déterminée d’un message (Conf) de configuration de l’au moins une unité (CU, DU, RU) dans l’au moins une application logicielle d’exploitation déterminée (Cl, C2, C3), ledit message de configuration comprenant un identifiant d’au moins une autre unité (CU, DU, RU) d’accès du réseau de communication.
2. Procédé de configuration, selon la revendication 1 , où le critère de placement relatif à un flux de données correspond à un ou plusieurs des critères de la liste suivante :
- une sécurité du flux du flux de données,
- une qualité de service d’acheminement du flux de données,
- une consommation énergétique lié au flux de données,
- une latence du flux de données,
- une gigue du flux de données,
- une perte de données dans le flux,
- un acheminement du flux de données par l’intermédiaire d’un nœud (KN1, KN2, KN3) du réseau de communication,
- un acheminement du flux de données par l’intermédiaire d’une suite ordonnée de nœuds (KN1, KN2, KN3, 130) du réseau de communications.
3. Procédé de configuration, selon la revendication 1 ou la revendication 2, où le test relatif à un critère de placement comprend une comparaison d’un délai d’acheminement d’un flux de données en provenance, respectivement à destination, de l’au moins une application logicielle d’exploitation et à destination, respectivement en provenance d’une autre application logicielle d’exploitation de l’environnement virtualisé, avec une valeur d’acheminement d’un flux de données de référence.
4. Procédé de configuration, selon l’une des revendications 1 à 3, où le test relatif à un critère de placement comprend une comparaison d’un délai d’acheminement et une mesure de qualité de service d’un flux de données en provenance, respectivement à destination, de l’au moins une application logicielle d’exploitation et à destination, respectivement en provenance d’une autre application logicielle d’exploitation de l’environnement virtualisé, avec des valeurs théoriques d’acheminement propres à une architecture spécifique du réseau de communication.
5. Procédé de configuration, selon l’une des revendications 1 à 4, où l’au moins une application logicielle d’exploitation est en outre déterminée en fonction de la position géographique d’un équipement (130) d’attachement du réseau de communication.
6. Procédé de configuration, selon l’une des revendications 1 à 5, comprenant en outre
- au moins une émission à destination d’une entité (KM) d’administration de l’environnement virtualisé d’un message de requête de l’au moins un nœud (KN1, KN2, KN3) dans l’environnement virtualisé
- au moins une réception en provenance de l’entité d’administration (KM) de l’environnement virtualisé d’un message de réponse comprenant un identifiant de l’au moins un nœud (KN1, KN2, KN3, 130).
7. Procédé de de configuration, selon la revendication 6, où le message de réponse comprend en outre une donnée de localisation de l’au moins un nœud (KN1, KN2, KN3, 130).
8. Procédé de configuration, selon l’une des revendications 1 à 7, comprenant en outre la réception d’un message de commande d’une mise à jour du réseau de communication comprenant une donnée géographique d’au moins une unité d’accès (CU, DU, RU) du réseau.
9. Procédé de configuration, selon l’une des revendications 1 à 8, où le message de configuration comprend en outre un paramètre de configuration relatif à un équipement (130) d’attachement au réseau de communication.
10. Procédé de configuration, selon l’une des revendications 1 à 9, comprenant en outre un message d’obtention auprès d’une base de données (BDD) d’un ensemble d’applications logicielles d’exploitation, ledit ensemble étant relatif à la donnée géographique d’une unité d’accès de l’infrastructure.
11. Procédé de gestion d’au moins une unité d’accès (CU, DU, RU) d’un réseau (20) de communication dans un environnement virtualisé comprenant au moins une application logicielle d’exploitation (Cl, C2, C3), ledit procédé étant mis en œuvre dans une entité de médiation (EM1, EM2, EM3) de l’au moins une application logicielle d’exploitation (Cl, C2, C3) et comprenant
- une émission à destination d’une entité (100) d’administration du réseau (20) de communication d’un message d’enregistrement (Enr) de l’au moins une application logicielle d’exploitation (Cl, C2, C3) associant un identifiant de l’au moins une application logicielle d’exploitation (Cl, C2, C3) et un identifiant d’au moins un nœud (KN1, KN2, KN3) supportant l’au moins une application logicielle d’exploitation (Cl, C2, C3),
- une réception en provenance de l’entité (100) d’administration du réseau (20) de communication d’un message (conf) de configuration de l’au moins une unité (CU, DU, RU) dans l’au moins une application logicielle d’exploitation (Cl, C2, C3) déterminée par l’entité (100) d’administration, ledit message de configuration comprenant un identifiant d’au moins une autre unité d’accès (CU, DU, RU) du réseau (20) de communication,
- une configuration de l’au moins une application logicielle d’exploitation (Cl, C2, C3) sur la base du message de configuration reçu,
- une activation de l’au moins une unité d’accès (CU, DU, RU) dans l’au moins application logicielle d’exploitation (Cl, C2, C3) configurée.
12. Dispositif (500) de configuration d’au moins une unité d’accès (CU, DU, RU) d’un réseau (20) de communication dans un environnement (10) virtualisé comprenant au moins une application logicielle d’exploitation (Cl, C2, C3), et comprenant
- un récepteur (501), apte à recevoir en provenance d’une entité de médiation (EM1, EM2, EM3) de l’au moins une application logicielle d’exploitation (Cl, C2, C3) d’un message d’enregistrement (Enr) de l’au moins une application logicielle d’exploitation (Cl, C2, C3) associant un identifiant de l’au moins une application logicielle d’exploitation (Cl, C2, C3) et un identifiant d’au moins un nœud (KN1, KN2, KN3, 130) supportant l’au moins une application logicielle d’exploitation (Cl, C2, C3),
- un module (502) de détermination, apte à déterminer, préalablement ou suite à la réception du message d’enregistrement, l’au moins une application logicielle d’exploitation (Cl, C2, C3) pour accueillir l’au moins une unité (CU, DU, RU) en fonction d’un résultat d’un test relatif à un critère de placement relatif à un flux de données acheminé par l’au moins une unité (CU, DU, RU),
- un émetteur (503), apte à émettre à destination de l’entité de médiation (EM1, EM2, EM3) de l’au moins une application logicielle d’exploitation (Cl, C2, C3) déterminée d’un message (Conf) de configuration de l’au moins une unité (CU, DU, RU) dans l’au moins une application logicielle d’exploitation (Cl, C2, C3) déterminée, ledit message de configuration comprenant un identifiant d’au moins une autre unité accès (CU, DU, RU) du réseau (20) de communication.
13. Dispositif (600) de gestion d’au moins une unité d’accès (CU, DU, RU) d’un réseau (20) de communication dans un environnement (10) virtualisé comprenant au moins une application logicielle d’exploitation (Cl, C2, C3), comprenant
- un émetteur (601), apte à émettre à destination d’une entité (100) d’administration du réseau de communication, un message (Enr) d’enregistrement de l’au moins une application logicielle d’exploitation (Cl, C2, C3) associant un identifiant de l’au moins une application logicielle d’exploitation (Cl, C2, C3) et un identifiant d’au moins un nœud (KN1, KN2, KN3, 130) supportant l’au moins une application logicielle d’exploitation (Cl, C2, C3),
- un récepteur (602), apte à recevoir en provenance de l’entité (100) d’administration du réseau de communication, un message (Conf) de configuration de l’au moins une unité (CU, DU, RU) dans l’au moins une application logicielle d’exploitation (Cl, C2, C3) déterminée par l’entité (100) d’administration, ledit message (Conf) de configuration comprenant un identifiant d’au moins une autre unité d’accès (CU, DU, RU) du réseau (20) de communication,
- un configurateur (603), apte à configurer l’au moins une application logicielle d’exploitation (Cl, C2, C3) sur la base du message (Conf) de configuration reçu,
- un activateur (604), apte à activer l’au moins une unité d’accès (CU, DU, RU) dans l’au moins application logicielle d’exploitation (Cl, C2, C3) configurée.
14. Système de configuration d’au moins une unité d’accès d’un réseau de communication dans un environnement virtualisé comprenant au moins une application logicielle d’exploitation, et comprenant
- un dispositif de configuration selon la revendication 12,
- un dispositif de gestion selon la revendication 13.
15. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de configuration selon l'une quelconque des revendications 1 à 10, lorsque le programme est exécuté par un processeur.
PCT/FR2022/051228 2021-07-08 2022-06-23 Procede et dispositif de configuration d'une unite d'acces dans un environnement virtualise WO2023281181A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP22743523.7A EP4367854A1 (fr) 2021-07-08 2022-06-23 Procede et dispositif de configuration d'une unite d'acces dans un environnement virtualise

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2107382 2021-07-08
FR2107382A FR3125187A1 (fr) 2021-07-08 2021-07-08 Procédé et dispositif de configuration d’une unité d’accès dans un environnement virtualisé

Publications (1)

Publication Number Publication Date
WO2023281181A1 true WO2023281181A1 (fr) 2023-01-12

Family

ID=78649349

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2022/051228 WO2023281181A1 (fr) 2021-07-08 2022-06-23 Procede et dispositif de configuration d'une unite d'acces dans un environnement virtualise

Country Status (3)

Country Link
EP (1) EP4367854A1 (fr)
FR (1) FR3125187A1 (fr)
WO (1) WO2023281181A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3081582A1 (fr) * 2018-06-18 2019-11-29 Orange Procede d'installation d'une fonction reseau virtualisee
WO2020174156A1 (fr) * 2019-02-27 2020-09-03 Orange Procédé d'évaluation des dispositifs d'une infrastructure de réseau en vue du déploiement d'une fonction virtualisée

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3081582A1 (fr) * 2018-06-18 2019-11-29 Orange Procede d'installation d'une fonction reseau virtualisee
WO2020174156A1 (fr) * 2019-02-27 2020-09-03 Orange Procédé d'évaluation des dispositifs d'une infrastructure de réseau en vue du déploiement d'une fonction virtualisée

Also Published As

Publication number Publication date
FR3125187A1 (fr) 2023-01-13
EP4367854A1 (fr) 2024-05-15

Similar Documents

Publication Publication Date Title
US10244059B2 (en) Systems and methods for the demand-driven deployment of location-neutral software
EP2137836B1 (fr) Procede et dispositif de gestion de canaux de communication pour des echanges de donnees a partir d'un aeronef
US20230300069A1 (en) System and Method for IOT Systems of Logic Across a Continuum of Computers
KR20220038740A (ko) 5g 라이브 업링크 스트리밍용 프레임워크(flus) 제어를 통한 네트워크 기반 미디어 처리(nbmp) 작업흐름 관리
EP3807760B1 (fr) Procédé d'installation d'une fonction réseau virtualisée
WO2023281181A1 (fr) Procede et dispositif de configuration d'une unite d'acces dans un environnement virtualise
EP3931694A1 (fr) Procédé d'évaluation des dispositifs d'une infrastructure de réseau en vue du déploiement d'une fonction virtualisée
WO2022034273A1 (fr) Procede de traitement d'un service de transport de donnees
WO2018065705A1 (fr) Procédé d'audit d'une ressource virtualisée déployée dans un réseau informatique en nuage
EP4058892A1 (fr) Procédés de commande d'un réseau informatique de périphérie a accès multiple
Corno et al. On the advanced services that 5G may provide To IoT applications
US11936757B1 (en) Pull-based on-demand application deployment to edge node
WO2023135043A1 (fr) Procédé, dispositif et système de modification d'une infrastructure de communication
EP3846416B1 (fr) Procédé de partage ordonnancé de fonctionnalités des iots et dispositif de partage ordonnancé
WO2024002868A1 (fr) Procédés de fourniture et de collecte, station de base, dispositif de collecte et d'analyse de données et système
EP3542589B1 (fr) Délégation d'instructions à un dispositif en fonction de ses ressources
US20240114347A1 (en) Dynamic radio access network sharing
WO2023217639A1 (fr) Procédé, dispositif et système d'élaboration dynamique d'une infrastructure de données
EP1681833A1 (fr) Procédés et dispositifs de diffusion et d'accès à une offre de service spécifique à une zone géographique dans un réseau de télécommunications sans fil
EP3839738A1 (fr) Procede de gestion des requetes d'allocation d'une ressource informatique
WO2023217638A1 (fr) Procédé, dispositif et système de certification d'une ressource
EP4373059A1 (fr) Infrastructure de communication munie d'un maillage de services étendu ; procédé et produit programme d ordinateur associés
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.
EP3520324A1 (fr) Procédé de contrôle de la répartition des dispositifs d'enregistrement déployés dans les infrastructures virtualisées de deux entités

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: 22743523

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18576919

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2022743523

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE