Method for managing a radio access network and associated electronic device

Abstract

The invention relates to a method for managing a radio access network (RAN) which is connected to a core network (CN), the method being implemented by a computer application (xApp) of a controller (CTRL) of the radio access network and comprising: receiving, from a module (MOD_KPI) of the core network (CN), a value representative of an end-to-end quality of service parameter of a connection between a user terminal (UE) and an input module (UPF) of the core network (CN), or of a connection between the user terminal (UE) and an application (cApp) which is accessed by the user terminal and connected to the input module of the core network via a data network (DN); and, managing the radio access network (RAN) as a function of the value obtained.

Description

DescriptionTitle of the invention: Method for managing a radio access network and associated electronic device D omaine Technique

[0001] The present invention belongs to the general field of telecommunications, and in particular wireless communications implemented on radio-type networks such as mobile networks (e.g. 4G, 5G, B5G etc.), etc. It relates more particularly to a method for managing a radio access network. It also relates to an electronic device comprising a radio access network controller configured to implement such a method.Prior art

[0002] In order to adapt to the continuous and ever-increasing growth of data traffic emitted by wireless telecommunications systems, various technologies are currently being implemented and are still being improved for optimal operation in the years to come.

[0003] The architecture of wireless telecommunications networks currently deployed or being deployed is defined by the standards consortium known as 3GPP (Third Generation Partnership Project). This is particularly the case for second-generation ("2G or GSM"), third-generation ("3G"), and fourth-generation ("4G") wireless networks.

[0004] Up to the fourth generation, the network architectures defined by the 3GPP consortium are most often based on specific equipment, dedicated to precise functionalities, whether at the level of the access network or the core network, particularly with regard to the transmission of packets from or to a mobile terminal.

[0005] The inherent lack of flexibility and scalability of this type of architecture has led the 3GPP consortium to consider adopting more flexible architectures for the so-called "5G" generation of wireless networks, in order to be able to respond quickly to extremely diverse demands in terms of traffic and / or quality of service.

[0006] To address these extremely diverse constraints, 5G relies in particular on the division of network functions into services, and on the virtualization of these network functions. The virtualization of network functions consists of deploying functions usually performed by dedicated and specific equipment on generic servers located in data centers ("data centers" in English terminology). These functions are then implemented in the form of computer programs that can be easily activated, deactivated and configured according to needs. Memory resources or computing capacity can then be dynamically allocated.

[0007] The target performance requirements of a 5G cellular network have been defined by the IMT-2020 recommendation of the International Telecommunications Union (ITU). More specifically, maximum theoretical values in terms of latency and throughput have been defined. However, the architecture currently defined by the 3GPP consortium does not make it possible to obtain end-to-end latency and / or throughput values, and a fortiori to adapt the configuration of the telecommunications network according to these values.Disclosure of the invention

[0008] The present invention aims to remedy all or part of the drawbacks of the prior art, in particular those set out above, by proposing a solution which allows a computer application of a radio access network controller to obtain a value representative of an end-to-end quality of service parameter determined by a module of the core network, so as to optimize the configuration of this radio access network.

[0009] To this end, and according to a first aspect, the invention relates to a method for managing a radio access network connected to a core network, the method being implemented by a computer application of a controller of the radio access network and comprising: - a reception, from a module of the core network, called "end-to-end performance indicator evaluation module", of a value representative of an end-to-end quality of service parameter of a connection between a user terminal and an input module of the core network, or of a connection between the user terminal and an application accessed by said user terminal and connected to the input module of the core network through a data network,; and, - a management of the radio access network as a function of the value obtained.

[0010] An end-to-end performance criterion offers the advantage of reliably reflecting the performance of a network. Furthermore, the values of an end-to-end quality of service parameter make it possible to quantify the quality of the data actually received by the user terminal.

[0011] As mentioned below, the module called "input module" is notably configured to route data from the user terminal through the core network, and is in this case considered as an input module of the core network, from the point of view of the terminal.

[0012] Generally speaking, it is considered that the steps of a process should not be interpreted as being linked to a notion of temporal succession.

[0013] In particular modes of implementation, the management method may further comprise one or more of the following characteristics, taken in isolation or in all technically possible combinations.

[0014] In particular implementation modes, the value considered may be representative of a current state of the quality of service parameter or of a prediction.

[0015] Thus, for example, in particular implementations, said parameter corresponds to a latency or a throughput, and the value is representative of a current state of the latency or throughput of the connection.

[0016] This feature offers the advantage of allowing the computer application to control the radio access network in real time.

[0017] In particular modes of implementation, said parameter corresponds to a latency or a flow rate, and the value is representative of a prediction of the latency or the flow rate of the connection, and the method according to the invention further comprises a step of prediction, by the core network, of the latency or the flow rate of the connection.

[0018] This feature offers the advantage of allowing the computer application to anticipate a change in latency or throughput, and a fortiori to adapt the configuration of the radio access network accordingly.

[0019] In particular embodiments, the application of the radio access network controller comprises an HTTP client, the core network module comprises an HTTP server, and at least one function for obtaining a value representative of a quality of service parameter implemented by said module is exposed to the application of the radio access network controller through an application programming interface (or API for "Application Programming Interface" in English), and the method further comprises the following steps, prior to receiving the value: - access, by the computer application of the radio access network controller, to said application programming interface, and, - transmission, by the computer application of the radio access network controller and to the core network module, of a request to obtain a result of an application of said at least one obtaining function.

[0020] These features are advantageous in that they allow the computer application to communicate with the core network module without having to know the implementation details of the functions of this module. In addition, these features allow the functions implemented by the performance indicator evaluation module to be presented as services accessible through the HTTP / 1 or HTTP / 2 protocol.

[0021] In particular embodiments, the controller of the radio access network comprises an HTTP client accessible by the application of the controller of the radio access network; the module of the core network comprises an HTTP server; at least one function for obtaining a value representative of a quality of service parameter implemented by said module is exposed to the controller through an application programming interface, and the method according to the invention further comprises the following steps, prior to receiving the value: - access, by the controller of the radio access network, to said application programming interface, - transmission, by the controller of the radio access network and to the module of the core network, of a request to obtain a result of an application of said at least one obtaining function.

[0022] In addition to the advantages previously mentioned, these characteristics are advantageous when the controller includes a plurality of applications configured to be able to access the core network module (or other modules) since only one HTTP client embedded by the controller – and not by each application of the plurality – must then be implemented.

[0023] In particular embodiments, said parameter corresponds to a latency or a throughput, and the at least one function is one of: − obtaining a value representative of a current state of the latency or throughput of the connection between the user terminal and the input module of the core network, − obtaining a value representative of a current state of the latency or throughput of the connection between the user terminal and the application accessed by said user terminal, − obtaining a value representative of a prediction of the latency or throughput of the connection between the user terminal and the input module of the core network, and − obtaining a value representative of a prediction of the latency or throughput of the connection between the user terminal and the application accessed by said user terminal.

[0024] In particular implementation modes, the application programming interface (or API) is of the REST type.

[0025] Using a REST (REpresentational StateTransfer) type API is advantageous in that it provides a standardized means of communication using the HTTP protocol between the HTTP client and the HTTP server.

[0026] In particular modes of implementation, the management method according to the invention further comprises a step of obtaining, by the HTTP client, an IP address of the HTTP server.

[0027] This step occurs, for example, within the framework of a discovery mechanism during which the controller's computer application consults a service registry in which all instances of the services accessible by this application (such as a service for evaluating an end-to-end performance indicator) are recorded, as well as the means of accessing these services. These means of access correspond, for example, to a web address (URL) of the HTTP server associated with said service, or to a web address of the API associated with said service.

[0028] The computer application then accesses a domain name system (DNS) in order to obtain the IP address of the HTTP server.

[0029] In particular embodiments, the radio access network comprises a first transmitting device and a second transmitting device distinct from the first transmitting device, and the management of the radio access network comprises: − an adaptation of time and frequency resources allocated to the user terminal; or − a connection switch of the user terminal from the first transmitting device to the second transmitting device.

[0030] In particular embodiments, the radio access network comprises at least one transmitting device, such as a base station, and the management of the radio access network comprises a determination of the transmission power of the transmitting device as a function of the value obtained, when data is exchanged with said user terminal.

[0031] In this way, the transmission power of the transmitting device is adapted according to the quality of service expected by the user terminal.

[0032] In particular embodiments, the management step comprises increasing the transmission power of the transmitting device if the latency has a value greater than a first threshold value, and decreasing the transmission power of the transmitting device if the latency has a value less than a second threshold value, the second threshold value being less than the first value. seuil.

[0033] In particular embodiments, the management step comprises an increase in the transmission power of the transmitting device if the flow rate has a value lower than a first threshold value, and a decrease in the transmission power of the transmitting device if the flow rate has a value greater than a second threshold value, the second threshold value being greater than the first threshold value.

[0034] In other words, if a quality of service actually provided to the user terminal is reached (eg, if the end-to-end latency value is lower than the second threshold value), the transmission power of the transmitting device is reduced, and conversely, if the quality of service actually provided to the user terminal is lower than a required (or expected) quality of service, then the transmission power of the transmitting device is increased.

[0035] Thus, these characteristics make it possible to make the base station less energy-consuming when the quality of service required by a given user terminal is reached (i.e., by being higher than a given threshold value). Furthermore, these characteristics aim to improve the quality of service offered to the user terminal when the latter is lower than a certain threshold value.

[0036] In particular modes of implementation, the transmission power is adapted when time and frequency resource units allocated to said user terminal are used.

[0037] This feature offers the advantage of adapting the transmission power of a transmitting device such as a base station, for a given user terminal, only when this base station and this user terminal are capable of exchanging data between them.

[0038] In particular implementations, the core network ingress module is configured as a gateway between the radio access network and a data network of the core network.

[0039] In particular implementations, the core network input module is a "User Plan Function" module. This input module is, for example, compliant with the 3GPP TS 33.513 standard, version 17.1.0, published on January 6, 2023.

[0040] In particular implementations, the radio access network controller is of the “Near Real Time RIC” type. The controller is then, for example, compliant with the O-RAN Near-RT RIC Architecture 4.0 specification, “O-RAN.WG3.RICARCH-R003-v04.00”, release 3, published in March 2023.

[0041] In particular implementations, the controller application is of type “xApp”. An application of type “xApp” is configured to control radio access network functionalities in a short time (e.g., less than 1 second). It is typically administered either by the telecommunications operator in charge of the telecommunications network, or by a service provider. The xApp application is for example compliant with the O-RAN specification O-RAN Studyon Security for Near Real Time RIC and xApps 2.0, “O-RAN.WG11.Security-Near-RT-RIC-xApps-TR.0-R003-v02.00”, version 3, published in March 2023.

[0042] According to a second aspect, the invention relates to a computer program comprising instructions for implementing a management method, when said program is executed by a processor.

[0043] According to a third aspect, the invention relates to a computer-readable recording medium on which the computer program according to the invention is recorded.

[0044] According to a fourth aspect, the invention relates to an electronic device comprising a radio access network controller configured to manage a radio access network connected to a core network, the controller including a computer application comprising:−a module for receiving a value representative of an end-to-end quality of service parameter of a connection between a user terminal and an input module of the core network, or of a connection between the user terminal and an application accessed by said user terminal and connected to the input module of the core network through a data network; and−a module for managing the radio access network as a function of the value.Brief description of the drawings

[0045] Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the appended drawings which illustrate an exemplary embodiment thereof without any limiting character. In the figures:

[0046] [Fig.1] Figure 1 is an example of a wireless communication system in which a management method according to the invention is implemented;

[0047] [Fig.2] Figure 2 schematically represents sub-modules embedded in a module for evaluating a performance indicator, according to an example of implementation of the invention;

[0048] [Fig.3] Figure 3 schematically represents a client-server configuration of the controller and the evaluation module of a performance indicator, according to a first example of implementation of the invention;

[0049] [Fig.4] Figure 4 schematically represents a client-server configuration of the controller and the evaluation module of a performance indicator, according to a second example of implementation of the invention;

[0050] [Fig.5] Figure 5 schematically represents modules embedded in an application of a controller of a radio access network, according to an exemplary implementation of the invention;

[0051] [Fig.6] Figure 6 represents an example of hardware architecture of an electronic device comprising a controller of a radio access network;

[0052] [Fig.7] Figure 7 illustrates, in the form of a flowchart, the main steps of a management method, according to an example of implementation of the invention;

[0053] [Fig.8] Figure 8 schematically represents an example of a request sent by the controller to the evaluation module of a performance indicator; et,

[0054] [Fig.9] Figure 9 illustrates, in the form of a flowchart, an example of management of a radio access network comprising the determination of the transmission power of the transmitting device. Description of the embodiments

[0055] Figure 1 is an example of a wireless communication system in which a management method according to the invention is implemented.

[0056] This system comprises a radio access network (RAN) comprising at least one transmitting device (gNB), a core network (CN) connected to the radio access network (RAN), and at least one user terminal (UE) connected to the radio access network (RAN). The user terminal (UE) corresponds for example to a laptop, a personal assistant, a connected object, or a mobile telephone of the "smartphone" type.

[0057] In the present embodiment, and for the purpose of simplifying the description, it is considered that the wireless communication system comprises a single user terminal (UE), as well as a radio access network (RAN) comprising a single transmitting device (gNB). It should however be noted that no limitation is attached to the number of transmitting devices (gNB) or to the number of user terminals (UE). The following developments are in fact generalizable without difficulty by those skilled in the art in the case where more than one transmitting device (gNB) and one user terminal (UE) are considered.

[0058] The radio access network (RAN) and the core network (CN) belong to a wireless telecommunications network (not shown in FIG. 1) to which the user terminal (UE) is connected, and are capable of communicating with each other in a frequency band associated with this wireless telecommunications network. For the remainder of the description, it is considered, in a non-limiting manner, that said telecommunications network is a 5G type mobile network (the fifth generation of mobile telephone network standards) compliant with the specification “O-RAN Architecture Description 8.0”, O-RAN.WG1.OAD-R003-v08.00, version 3, published in March 2023 by the O-RAN alliance (acronym for “Open Radio Access Network”).

[0059] The O-RAN Alliance is composed of mobile network operators, manufacturers, suppliers, and research and academic organizations working in the telecommunications field. It has defined the O-RAN architecture, which, while building on the architecture proposed by the 3GPP consortium, aims to facilitate the deployment of radio access network (RAN) virtualization. More generally, the O-RAN Alliance aims to define a radio access network (RAN) architecture that allows equipment and / or software modules from different vendors to communicate.

[0060] It should be noted, however, that the invention remains applicable to other types of telecommunications network, such as for example a 4G mobile network (the fourth generation of mobile telephone network standards), and / or B5G (acronym for "Beyond 5G").

[0061] Furthermore, the invention also remains applicable to other types of radio access network (RAN) which also rely on a division of functions into simple independent – or at least loosely coupled – services, which communicate via application programming interfaces (APIs).

[0062] Generally speaking, an Application Programming Interface (API) is a set of tools, definitions, and protocols that facilitate the creation of application functions configured to manage, in this case, the radio access network. An API connects a service provider to service consumers (e.g., xApp computer applications) without the latter having to know the implementation details of the services.

[0063] For example, the radio access network (RAN) complies with the C-RAN paradigm ("Cloud-RAN"). This architecture combines virtualization and centralization of the functionalities of a base station by means of cloud computing. In a C-RAN architecture, the processing units ("baseband units" according to English terminology) are no longer located in the immediate vicinity of the base station, but are relocated and centralized within a centralized pool ("BBU pool" according to English terminology).

[0064] Alternatively, the radio access network (RAN) is, for example, compliant with the V-RAN (Virtual-RAN) paradigm. A virtual radio access network (vRAN) is a radio access network (RAN) whose network functions are deployed as virtualized instances located at different locations on the network, for example, according to a deployment strategy of the telecommunications operator. This approach offers the advantage of limiting the use of expensive equipment, and allows the creation of isolated subnetworks (network slices), which coexist simultaneously on the same hardware.

[0065] As illustrated in Figure 1, the Radio Access Network (RAN) consists of a Radio Unit (O-RU), a Distributed Unit (O-DU), and a Central Unit (O-CU).

[0066] For example, the radio unit (O-RU) is deployed on a gNB, and the distributed (O-DU) and central (O-CU) units are deployed on remote servers. Alternatively, the radio unit (O-RU), distributed (O-DU) and central (O-CU) are all implemented by the gNB.

[0067] The radio unit (O-RU) is connected to the distributed unit (O-DU) through a so-called "fronthaul" link (OFH), and the distributed unit (O-DU) is connected to the centralized unit (O-CU) through a so-called "midhaul" link (OMH).

[0068] The network functions of a traditional base station (e.g., a 4G-compliant base station) are distributed among these three units according to a functional division of the OSI layers that best suits the requirements of the telecommunications network usage context.

[0069] This distribution is for example in line with one of the options described in the 3GPP specification "Study on new radio access technology: Radio access architecture and interfaces", TR38.801, release 14, v14.0.0, published in April 2017, each having its own advantages and disadvantages in terms of latency, throughput and implementation complexity. These options are referenced 1 to 6, 7.1, 7.2, 7.3 et 8.

[0070] In another example, this distribution is in accordance with Option 7.2 as defined by the O-RAN Alliance. The O-RAN Alliance has in fact relied on Option 7.2 defined by the 3GPP consortium to propose a splitting of the low physical layer at the radio unit (O-RU) level, and a splitting of the high physical layer at the distributed unit (O-DU) level. These splittings are notably defined in the specification "O-RAN Hardware Reference Design Specification for Outdoor Macrocell with Split Architecture Option 7.2 2.0", O-RAN.WG7.OMAC-HRD.0-R003-v02.00, release R003 published in March 2023.

[0071] The radio unit (O-RU) is then configured to convert a digital signal into a radio signal in the case of a downlink, and vice versa in the case of an uplink. More precisely, the radio unit (O-RU) is configured to manage the low physical layer (e.g., the RF chain(s), analog / digital precoding, data transport in accordance with the eCPRI protocol (acronym for "evolved Common Public Radio Interface") and synchronization, for example in accordance with the PTP protocol (acronym for "Precision Time Protocol"), also known as IEEE-1588 and IEC 61588. This PTP protocol is for example defined in the document "IEEE Standard for a Precision ClockSynchronization Protocol for Networked Measurement and Control Systems," in IEEE Std 1588-2019 (Revision of IEEE Std 1588-2008), pp. 1-499, published on June 16 2020.

[0072] Still in accordance with option 7.2, the distributed unit (O-DU) is configured to manage the upper physical sublayers, MAC (acronym for Media Access Control) and RLC (acronym for Radio Link Protocol). The centralized unit (O-CU) is configured to manage the PDCP (acronym for Packet Data Convergence Protocol), SDAP (acronym for Service Data Adaptation Protocol) and RRC (acronym for Radio Resource Control). The MAC sublayer is configured to establish a correspondence between logical channels and transport channels. The RLC sublayer is configured to manage the transfer of PDU (acronym for Packet Data Unit) packets from the upper layer. The PDCP sublayer is configured to handle packet sequence numbering, packet ordering, and header compression and decompression.The role of the SDAP layer is in particular to manage a correspondence between the quality of service of an IP flow and the radioelectric support.

[0073] As illustrated in Figure 1, the radio access network further comprises a radio access network (RAN) controller (CTRL) in which a plurality of application functions (xApp) are embedded. This controller is for example compliant with the O-RAN Near-RT RIC Architecture 4.0 specification, “O-RAN.WG3.RICARCH-R003-v04.00”, release 3, published in March 2023. It then operates as a service, for example, deployed on a cloud network, and is sometimes called “near-real-time RIC” for its ability to handle events requiring action within a relatively short time (e.g., from 10 milliseconds to 1 second).

[0074] The Radio Access Network (RAN) Controller (CTRL) is configured to control and optimize the spectral efficiency of the radio access network, by controlling the distributed units (O-DU) and centralized units (O-CU) through E2 interfaces. It integrates third-party computing applications (xApps) that automate and optimize these control and optimization operations. These computing applications (xApps) operate as services, and are also deployed on a network uage.

[0075] The telecommunications network further comprises a core network (CN). This core network (CN) includes an input module (UPF) acting as a gateway between the radio access network (RAN) and a data network (DN), such as the Internet or a local / private network. The core network (CN) further comprises a module (MOD_KPI) for evaluating an end-to-end performance indicator described with reference to Figure 2. The input module (UPF) is connected to the centralized unit (O-CU) through an N3 interface.

[0076] The input module corresponds for example to the UPF module (for “User PlaneFunction”) defined by the 3GPP 23.501 specification “System architecture for the 5GSystem (5GS)”, version 18.1.0, published in April 2023.

[0077] The input module (UPF) and the data network (DN) are connected through an N6 interface. In addition, at least one application (cApp) is connected to this data network (DN). It is important to note here that although Figure 1 illustrates the case where the application (cApp) does not belong to the core network (CN), it could also be considered the case where said application (cApp) is an application of said core network (CN).

[0078] As illustrated in Figure 1, the transmitting device (gNB) is a base station of the radio access network (RAN). It can be either an IAB-donor base station connected to the core network, or an intermediate base station between the user terminals and such an IAB-donor base station. A base station is sometimes called a "nodeB" in 3G networks, "eNodeB" according to the LTE standard (acronym for "Long Term Evolution") and "gNodeB" in 5G networks.

[0079] Figure 2 schematically represents sub-modules embedded in a module (MOD_KPI) for evaluating an end-to-end performance indicator, according to an exemplary implementation of the invention.

[0080] As illustrated in Figure 2, the module (MOD_KPI) for evaluating a performance indicator comprises a MOD_PROBE sub-module configured to obtain a value (E2E_KPI#1) representative of a current state of the latency or throughput of the connection between the user terminal (UE) and the input module (UPF) of the core network. To do this, the evaluation module (MOD_KPI) is connected to the output of the input module (UPF) and for example configured to launch the ping() command between the input module (UPF) and the user terminal (UE) to obtain a latency value, or the iperf() command between the input module (UPF) and the user terminal (UE) to obtain a throughput value. The ping() and iperf() commands are known to those skilled in the art and are not described in detail here.

[0081] Alternatively or in combination, the MOD_PROBE sub-module is configured to obtain a value (E2E_KPI#2) representative of a current state of the latency or throughput of the connection between the user terminal (UE) and an application (cApp) connected to the data network (DN) and accessed by said user terminal (UE). To do this, the evaluation module (MOD_KPI) is connected to the server on which the application (cApp) accessed by the user terminal (UE) is deployed, and configured to launch the ping() (resp. iperf()) command between this server and the user terminal (UE) to obtain a latency value (resp. débit).

[0082] As illustrated in Figure 2, the module (MOD_KPI) for evaluating a performance indicator further comprises a sub-module MOD_PRED configured to determine a value representative of a prediction of the latency or throughput of the connection between the user terminal (UE) and the input module (UPF) of the core network and / or to determine a value representative of a prediction of the latency or throughput of the connection between the user terminal (UE) and the application (cApp) accessed by said terminal. For this, the MOD_PRED module relies on a history of the latency and / or throughput values obtained by the MOD_PROBE module, and uses a machine learning mechanism, such as a trained neural network to predict future latency and / or throughput values, based on past values and / or based on the type of data that is planned to be exchanged.

[0083] Figure 3 schematically represents a client-server configuration of the controller and the module for evaluating a performance indicator, according to a first example of implementation of the invention.

[0084] As illustrated in Figure 3, the radio access network controller (CTRL) includes a computer application (xApp) including an HTTP client. The MOD_KPI module for evaluating a performance indicator includes the two previously described MOD_PROBE and MOD_PRED sub-modules, as well as an HTTP server connected to the MOD_PROBE and MOD_PRED modules and coupled to an application programming interface (API).

[0085] The use of a client-server architecture between the computer application (xApp) and the module (MOD_KPI) for evaluating a performance indicator makes it possible to present the functions implemented by this MOD_KPI module as services accessible through the HTTP / 1 or HTTP / 2 protocol. In addition, the API makes it possible to expose to the HTTP client the functionalities offered by the HTTP server (and more generally implemented by the module (MOD_KPI) for evaluating a performance indicator), without the HTTP client having to know the implementation details of these functionalities. The API also exposes the way in which these functionalities can be accessed (for example the name of a specific function to call, as well as the input parameters of this function).

[0086] These functionalities correspond to those offered by the MOD_PROBE and MOD_PRED modules: − obtaining a value representative of a current state of the latency or the throughput of the connection between the user terminal (UE) and the input module (UPF) of the core network, − obtaining a value representative of a current state of the latency or the throughput of the connection between the user terminal (UE) and the application (cApp) accessed by said user terminal (UE), − obtaining a value representative of a prediction of the latency or the throughput of the connection between the user terminal (UE) and the input module (UPF) of the core network, and − obtaining a value representative of a prediction of the latency or the throughput of the connection between the user terminal (UE) and the application (cApp) accessed by said user terminal (UE).

[0087] Figure 4 schematically represents a client-server configuration of the controller and the module for evaluating a performance indicator, according to a second example of implementation of the invention.

[0088] The module (MOD_KPI) for evaluating a performance indicator is identical to that described with reference to Figure 3, and is therefore not re-described, for the sake of brevity.

[0089] As illustrated in Figure 4, the controller (CTRL) includes an HTTP client and a computer application (xApp) connected to the HTTP client.

[0090] This configuration proves to be particularly advantageous when the controller (CTRL) comprises a plurality of applications (xApp) configured to access the core network module (or other modules). Indeed, the implementation of the applications (xApp) is then simplified since a single HTTP client is embedded in the controller (CTRL) − and not one HTTP client per application of the plurality –.

[0091] The APIs presented with reference to Figures 3 and 4 are, for example, REST-type APIs. As mentioned previously, using a REST-type API (the acronym for "REpresentational State Transfer") is advantageous in that it provides a standardized means of communication using the HTTP protocol between the HTTP client and the HTTP server.

[0092] Figure 5 schematically represents modules embedded in an application of a controller of a radio access network, according to an exemplary implementation of the invention.

[0093] The controller (CTRL) is a software component. As illustrated in Figure 5, this radio access network (RAN) controller (CTRL) includes an application (xApp) including the MOD_RX and MOD_PROC modules whose functionalities are described with reference to Figure 6.

[0094] Figure 6 represents an example of hardware architecture of an electronic device (D_CTRL) comprising a controller of a radio access network.

[0095] As illustrated in Figure 6, the electronic device (D_CTRL) has the hardware architecture of a computer. Thus, the electronic device (D_CTRL) includes, in particular, a processor 1, a random access memory 2, a read-only memory 3 and a non-volatile memory 4. It also includes a communication module 5.

[0096] The read-only memory 3 of the electronic device (D_CTRL) constitutes a recording medium as proposed, readable by the processor 1 and on which is recorded a computer program PROG in accordance with the invention, comprising instructions for executing steps of the management method as proposed below. The program PROG defines one or more functional modules of the device, which rely on or control the hardware elements 1 to 5 cited above, and which comprise in particular: − a MOD_RX module for receiving a value representative of an end-to-end quality of service parameter of a connection between a user terminal (UE) and an input module (UPF) of the core network (CN), or of a connection between the user terminal (UE) and an application (cApp) accessed by said user terminal and connected to the input module of the core network through a data network (DN).In the remainder of the description, latency or throughput are considered as end-to-end quality of service parameters. However, the invention can be applied to other quality of service parameters;e. t - a MOD_PROC module for managing the radio access network (RAN) based on the value.

[0097] Furthermore, the electronic device (D_CTRL) may also include other modules, in particular to implement particular modes of the management method, as described in more detail later.

[0098] Figure 7 illustrates, in the form of a flowchart, the main steps of a management method, according to an example of implementation of the invention.

[0099] As illustrated by Figure 7, the management method comprises a first step S100 of obtaining, by the computer application (xApp) of the controller (CTRL), a means of accessing the MOD_KPI module for evaluating a performance indicator.

[0100] This step occurs, for example, within the framework of a discovery mechanism during which the computer application (xApp) consults a service registry in which all instances of the services accessible by this computer application (xApp) are recorded, such as an end-to-end performance indicator evaluation service implemented by the MOD_KPI module, as well as the means of accessing these services. These means of access correspond, for example, to a web address (URL) of the HTTP server associated with said service, or to a web address of the API associated with said service.

[0101] The computer application (xApp) then accesses a domain name system (or Domain Name System, DNS in English terminology) in order to obtain the IP address of the HTTP server.

[0102] The management method further comprises a step S110 during which the computer application (xApp) transmits, to the evaluation module MOD_KPI, a request REQ_API aimed at obtaining the list of functions implemented by this module MOD_KPI for evaluating a performance indicator.

[0103] This request is received during a step S200 by the HTTP server of the evaluation module MOD_KPI, which, in return, transmits during a step S210 a response RESP_API to the computer application (xApp). This response RESP_API includes for example the list of functions exposed to this computer application (xApp), and the way in which these functions can be accessed (for example the name of a specific function to call, as well as the input parameters of this function). This response RESP_API is received by the computer application (xApp) during a step S120.

[0104] The management method further comprises a step S130 during which the computer application (xApp) transmits, to the evaluation module MOD_KPI, a request REQ_F aimed at obtaining the result of the application of one of the functions exposed by the API and listed in the response RESP_API. Figure 8, described below, illustrates an example of a request REQ_F. This request REQ_F is received by the module MOD_KPI during a step S220, then analyzed during a step S230 in order to verify whether the syntax used is consistent with that expected.

[0105] If the syntax used is not compliant, a FAIL message indicating that a syntax error has been made is transmitted by the evaluation module MOD_KPI to the application during a step S240, and received by this application during a step S140.

[0106] If the query is correctly formed, a step S250 is implemented by the MOD_KPI module during which it is determined whether it is a prediction or a current state of a performance indicator that is required by the computer application (xApp).

[0107] If it is a current state, step S260 is implemented by the module MOD_PROBE of the controller CTRL. During this step S260, a value representative of a current state of the latency or the throughput of the connection between the user terminal (UE) and the input module (UPF) of the core network or of the connection between the user terminal (UE) and the application (cApp) accessed by the user terminal is determined.

[0108] More specifically, if the request REQ_F aims to obtain a value representative of a current state of the latency (resp. of the flow rate) of the connection between the user terminal (UE) and the input module (UPF) of the core network, a latency measurement command (resp. of flow rate) such as the ping() command (resp. iperf()) is applied between the user terminal (UE) and the input module (UPF) of the core network. The ping() and iperf() commands are commands known to those skilled in the art and are not described further here.

[0109] Alternatively, if the request REQ_F aims to obtain a value representative of a current state of the latency (resp. of the flow rate) of the connection between the user terminal (UE) and the application (cApp) accessed by this user terminal, a latency measurement command (resp. of flow rate) such as the ping() command (resp.iperf()) is applied between the user terminal (UE) and the server on which the application (cApp) is deployed.

[0110] Thus, with reference to Figure 1, the value ^^^^ ^^^^ ^^^^− ^^^^ ^^^^ ^^^^ representative of the stand-to-end latency between the user terminal (UE) and the input module (UPF) of the core network is expressed in the form:^^^^ ^^^^ ^^^^− ^^^^ ^^^^ ^^^^ = ^^^^ ^^^^ ^^^^− ^^^^ ^^^^ ^^^^ + ^^^^ ^^^^ ^^^^ ^^^^− ^^^^ ^^^^ ^^^^ + ^^^^ ^^^^ ^^^^ ^^^^_ ^^^^ ^^^^ ^^^^with ^^^^ ^^^^− ^^^^ the latency value between component A and component B.

[0111] The value ^^^^^^^^ ^^^^− ^^^^ ^^^^ ^^^^ ^^^^representative of the end-to-end latency between the user terminal (UE) and the application accessed by said user terminal (UE) is expressed in the form:^^^^ ^^^^ ^^^^− ^^^^ ^^^^ ^^^^ ^^^^ = ^^^^ ^^^^ ^^^^− ^^^^ ^^^^ ^^^^ + ^^^^ ^^^^ ^^^^ ^^^^− ^^^^ ^^^^ ^^^^ ^^^^

[0112] If it is a prediction, step S270 is implemented during which a value representative of a prediction of the latency or the throughput of the connection between the user terminal (UE) and the input module (UPF) of the core network or of the connection between the user terminal (UE) and the application (cApp) accessed by the user terminal is determined. This step is implemented by the module MOD_PRED of the controller CTRL.

[0113] This MOD_PRED module relies on a history of latency and / or throughput values obtained by the MOD_PROBE module, and uses a machine learning mechanism, such as a trained neural network to predict future latency and / or throughput values, based on past values and / or based on the type of data or the quality of service required by the user terminal (UE).

[0114] According to a particular implementation example, the MOD_PROBE module takes as input a history of data concerning latency, throughput, transmission power, geographical positions of user terminals, and other data such as network load. An objective function of the MOD_PROB module is then configured to predict a quality of service (e.g., latency and / or throughput) using the input data, and thus allow the CTRL controller to make better decisions regarding transmission power control. The objective function aims either to minimize latency, or to maximize throughput, or to achieve a compromise between these two measures. Finally, it is important to note that the learning phase is for example implemented using the practice of cloud computing.The management method further comprises a step S280 during which the evaluation module MOD_KPI transmits, to the computer application (xApp), a response RESP_F including the required representative value. The format of this response RESP_F is similar to that of the request REQ_F. This value is received by the module MOD_RX of the computer application during a step S150, then used during a step S160 to manage the radio access network (RAN). This step S160 of managing the radio access network (RAN) is implemented by the module MOD_PROC of the controller (CTRL).

[0115] In particular implementations, step S160 comprises an adaptation of time and frequency resources allocated to the user terminal (UE).

[0116] According to a particular example implementation, during step S160, a specific MAC scheduling policy is determined by a MAC scheduler, and activated within the distributed unit (O-DU). Depending on the type of service, the MAC scheduler may associate a higher priority with data flows that do not match a target performance.

[0117] Thus, for a high bandwidth service for wireless connectivity (Enhanced Mobile Broadband, eMBB, according to the English terminology) having specific throughput requirements, if it is determined in step S160 that a representative value is lower than a desired objective, a higher priority is assigned to this service until the representative value received in step S150 is optimal, or even maximum.

[0118] The preceding developments can be adapted without difficulty by a person skilled in the art in the case of a service subject to strict requirements in terms of latence.

[0119] Alternatively, step S160 comprises a connection switch of the user terminal (UE) from a first transmitting device to a second transmitting device distinct from the first transmitting device.

[0120] Alternatively, step S160 comprises determining a transmission power of the transmitting device (gNB) as a function of the value obtained, when data is exchanged with said user terminal (UE). This variant is described in more detail with reference to FIG. 9.

[0121] In particular implementations, the transmission power is adapted only when time and frequency resource units (PRB) allocated to said user terminal (UE) are used.

[0122] The use of OFDMA (Orthogonal Frequency Division Multiple Access) now offers the possibility of allocating resources in both the time and frequency dimensions. As is known per se, the smallest unit of frequency resource that can be allocated to a user terminal (UE) by an orchestrator (not shown in Figure 1) is called PRB (the acronym for "Physical Resource Block"). Thus, for 4G, a PRB lasts for example 0.5 ms and consists of several (eg, 7) OFDM symbols, and the bandwidth of a PRB is 12 subcarriers.

[0123] Thus, the transmission power of the transmitting device (gNB) is only controlled (and if necessary adapted) when PRBs allocated to the user terminal (UE) are used, i.e. only when the user terminal (UE) and the transmitting device (gNB) are able to communicate.

[0124] Figure 8 schematically represents an example of a REQ_F request sent by the controller to the evaluation module of a performance indicator.

[0125] As illustrated in Figure 8, the request comprises:− a field 810 comprising the name of the called function (for example GETE2E_KPI_latency or GET E2E_KPI_throughput);− a field 820 comprising an identifier of the application xApp having issued this request;− a field 830 comprising a flag whose value characterizes whether it is a current state or a prediction of a performance criterion which is required;− a field 840 comprising an identifier of the user terminal (UE) for which the measurement is required;− a field 850 comprising a time corresponding to the current time;− a field 860 comprising an identifier of the application cApp accessed by the terminal.This value is only necessary in the case where a value representative of a flow rate or a latency of a connection between the user terminal (UE) and this application cApp is required by the computer application xApp; and, − a field 870 comprising a time corresponding to a future instant. This value is only necessary in the case where a value representative of a prediction of a flow rate or a latency of a connection between the user terminal (UE) and the UPF input module or the application cApp is required by the computer application xApp.

[0126] Figure 9 illustrates, in the form of a flowchart, an example of management of a radio access network including the determination of the transmission power of the transmitting device. In this example, a latency criterion is considered. This method is implemented by the computer application xApp previously mentioned, or by a separate computer application xApp. In the latter case, the two xApp applications interact with each other, for example, through an interface called "EastBound" or "WestBound" compatible with the O-RAN standard.

[0127] During an initialization step (not shown), the start_flag value is initialized to 0, the start_lat value is also initialized to 0, and the parameter SLA_LIMIT is initialized as a global variable with a given value (eg, S LA_LIMIT=15ms).

[0128] The method for determining the transmission power of a transmitting device is an iterative algorithm. As illustrated in FIG. 9, the method for determining the transmission power of a transmitting device comprises a first step S1050 in which it is determined whether it is a first iteration of the algorithm or not.

[0129] If this is a first iteration (eg, start_flag=0), then step S1060 is implemented. During this step, the current transmission power (curr_power) of the transmitting device (gNB) to which the user terminal (UE) is attached is obtained. Then, during a step S1070, the value start_flag is set to 1, and the value of the parameter start_lat is set to be equal to the value obtained during step S150. Once these values are set, the controller implements step S1080.

[0130] If this is not a first iteration (e.g., if start_flag≠0), then step S1090 is implemented. During this step, it is tested whether the value obtained in step S150 is less than the value of the start_lat parameter. If this is the case, then step S1100 is implemented in which the value of the start_lat parameter is set to be equal to the value obtained in step S150. Once this value is set, the controller implements step S1080.

[0131] If, on the other hand, the value obtained during step S150 is greater than or equal to the value of the start_lat parameter, the controller implements step S1080.

[0132] Step S1080 consists of determining threshold values lat_limit and lat_alert according to the value of the parameter start_lat. In a particular embodiment,^^^^ ^^^^ ^^^^_ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ = ^^^^ ^^^^ ^^^^ ^^^^^_ ^^^^ ^^^^ ^^^^ × ^^^^1 and ^^^^ ^^^^_ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ = ^^^^ ^^^^ ^^^^ ^^^^_ ^^^^ ^^^^ ^^^^ × ^^^^2 , with ^^^^2 > ^^^^1 . Thus, M1 is for example equal to 1.3, and M2 to 1.6.

[0133] Once these two threshold values have been determined, the controller implements a step S1110 during which it is determined whether the threshold value lat_limit is lower than the value obtained during step S150. If this is not the case (i.e., if the threshold value lat_limit is greater than or equal to the value obtained during step S150), then step S1120 is implemented during which it is determined that the transmission power of the transmitting device must be reduced by a certain step. This step aims to make the transmitting device less energy-consuming when the quality of service required by a given user terminal is largely achieved. Once it is determined that the transmission power must be reduced, the controller implements step S1170.

[0134] Returning to step S1110, if on the other hand the threshold value lat_limit is lower than the value obtained during step S150, the controller implements step S1130 during which it is determined whether the value obtained during step S150 is lower than or equal to the value of SLA_LIMIT or (or logic) whether the value obtained during step S150 is lower than or equal to the threshold value lat_alert. If this is not the case, then step S1160 is implemented during which the transmission power of the transmitting device does not change. In this way, – eg, if this is not the case –, the fact of maintaining the current power value makes it possible to avoid a continuous oscillation (“ping pong” effect) around a certain value.

[0135] If, on the other hand, the value obtained during step S150 is greater than the value of SLA_LIMIT or if the value obtained during step S150 is greater than the threshold value lat_alert, then the controller implements step S1140. Step S1140 consists of a test to determine whether or not the transmitting device (gNB) transmits a certain transmission power (e.g., whether curr_power = 0 or not). If the transmitting device (gNB) has zero transmission power, then step S1160 is implemented (the transmission power of the transmitting device does not change). If, on the other hand, the transmitting device (gNB) has a positive transmission power, then the transmission power curr_power is increased by a certain step, for example predetermined, during a step S1150. This step aims to improve the quality of service offered to the user terminal when the latter is less than a certain threshold value.

[0136] In other words, steps S1110 to S1160 can be summarized as follows in the case where a latency value is obtained: the transmission power of the transmitting device is increased if the latency has a value greater than a first threshold value (SLA_limit or lat_alert), and conversely, the transmission power of the transmitting device is reduced if the latency has a value less than a second threshold value (latency_limit), the second threshold value being less than the first threshold value. Thus, if a quality of service actually provided to the user terminal is reached (e.g., if the end-to-end latency value is less than the second threshold value), the transmission power of the transmitting device is reduced, and conversely, if the quality of service actually provided to the user terminal is less than a required (or expected) quality of service ...)., if the end-to-end latency value is greater than the first threshold value), then the transmit power of the transmitting device is increased.

[0137] The preceding developments can be adapted without difficulty by a person skilled in the art in the case where a value representative of another quality of service parameter is obtained, for example a value representative of a flow rate. In this case, the transmission power of the transmitting device is increased if the flow rate has a value lower than a first threshold value, and conversely, the transmission power of the transmitting device is reduced if the flow rate has a value greater than a second threshold value, the second threshold value being greater than the first threshold value.

[0138] The determining method further comprises a step S1170 in which the controller determines whether a change in the transmission power is required (eg, whether one of steps S1120 or S1150 has been implemented). If so, then the controller CTRL transmits an instruction to the distributed unit (O-DU) to adapt the transmission power of the transmitting device (gNB) in a step S1180. Then, in a step S1190, the variable curr_power is set as now equal to the new transmission power value. Once the variable curr_power is set to the new power value, step S1200 is implemented.

[0139] Returning to step S1170, if it has previously been determined that no transmission power modification is necessary, then step S1200 is directly implemented.

[0140] During step S1200 the latency and / or current throughput values as well as the value of the transmission power of the transmitting device are displayed through a dedicated user interface.

[0141] In implementation modes, the interface is adapted to allow a user (eg, a user in charge of managing said radio access network) of a device displaying said interface to adapt the step of increase or reduction of the transmission power, and / or to modify the values of the multipliers M1 and M2 used to determine the values lat_limit and lat_alert during step S1080.

Claims

Claims

1. Method for managing a radio access network (RAN) connected to a core network (CN), the method being implemented by a computer application (xApp) of a controller (CTRL) of the radio access network and comprising:−a reception (S150), from a module (MOD_KPI) of the core network (CN), of a value representative of an end-to-end quality of service parameter of a connection between a user terminal (UE) and an input module (UPF) of the core network (CN), or of a connection between the user terminal (UE) and an application (cApp) accessed by said user terminal and connected to the input module of the core network through a data network (DN); and,−a management (S160) of the radio access network (RAN) as a function of the value obtenue.

2. Management method according to claim 1, wherein said parameter corresponds to a latency or a throughput, and the value is representative of a current state of the latency or throughput of the connection.

3. Management method according to claim 1, wherein said parameter corresponds to a latency or a throughput, and the value is representative of a prediction of the latency or throughput of the connection, the method further comprising a step of prediction (S270), by the core network (CN), of the latency or throughput of the connection.

4. Management method according to one of claims 1 to 3, wherein the application (xApp) of the controller of the radio access network comprises an HTTP client, the module (MOD_KPI) of the core network comprises an HTTP server,and at least one function for obtaining a value representative of a quality of service parameter implemented by said module (MOD_KPI) is exposed to the application (xApp) of the controller of the radio access network through an application programming interface (API), the method further comprising the following steps, prior to the reception (S130) of the value: − an access (S120), by the computer application (xApp) of the controller (CTRL) of the radio access network (RAN), to said application programming interface (API), and, − a transmission (S130), by the computer application (xApp) of the controller (CTRL) of the radio access network (RAN) and to the module (MOD_KPI) of the core network, of a request to obtain a result of an application of said at least one obtaining function. 3,wherein the controller (CTRL) of the radio access network comprises an HTTP client accessible by the application (xApp) of the controller of the radio access network; the module (MOD_KPI) of the core network (CN) comprises an HTTP server; and at least one function for obtaining a value representative of a quality of service parameter implemented by said module (MOD_KPI) is exposed to the controller (CTRL) through an application programming interface (API), the method further comprising the following steps, prior to receiving (S130) the value: − an access (S120), by the controller (CTRL) of the radio access network (RAN), to said application programming interface (API), − a transmission (S130), by the controller (CTRL) of the radio access network (RAN) and to the module (MOD_KPI) of the core network, of a request to obtain a result of an application of said at least one obtaining function.

6. Management method according to claim 4 or 5,wherein said parameter corresponds to a latency or a throughput, and said at least one obtaining function is one of:−obtaining a value representative of a current state of the latency or throughput of the connection between the user terminal (UE) and the input module (UPF) of the core network,−obtaining a value representative of a current state of the latency or throughput of the connection between the user terminal (UE) and the application (cApp) accessed by said user terminal,−obtaining a value representative of a prediction of the latency or throughput of the connection between the user terminal (UE) and the input module (UPF) of the core network, and−obtaining a value representative of a prediction of the latency or throughput of the connection between the user terminal (UE) and the application (cApp) accessed by said user terminal (UE).

7. Management method according to one of claims 1 to 6,wherein the radio access network (RAN) comprises at least one transmitter device (gNB), and the management (S160) of the radio access network (RAN) comprises a determination of a transmission power of the transmitter device (gNB) as a function of the value obtained, when data is exchanged with said user terminal (UE).

8. Management method according to claim 7, wherein the management step (160) comprises an increase (1100) of the transmission power of the transmitter device (gNb) if the latency has a value greater than a first threshold value, and a decrease (1140) of the transmission power of the transmitter device (gNb) if the latency has a value less than a second threshold value, the second threshold value being less than the first threshold value.

9. Management method according to claim 7,wherein the management step (160) comprises an increase (1100) in the transmission power of the transmitting device (gNb) if the throughput has a value lower than a first threshold value, and a decrease (1140) in the transmission power of the transmitting device (gNb) if the throughput has a value greater than a second threshold value, the second threshold value being greater than the first threshold value.

10. Management method according to one of claims 7 to 9, wherein the transmission power is adapted when time and frequency resource units (PRB) allocated to said user terminal (UE) are used.

11. Management method according to one of claims 1 to 10, wherein the input module of the core network is a “user plane function” module.

12. Computer program comprising instructions for implementing a management method according to any one of claims 1 at 11,when said program is executed by a computer.

13. A computer-readable recording medium on which a computer program according to claim 12 is recorded.

14. An electronic device (D_CTRL) comprising a radio access network (RAN) controller (CTRL) configured to manage a radio access network (RAN) connected to a core network (CN), the controller including a computer application (xApp) comprising:−a module (MOD_RX) for receiving a value representative of an end-to-end quality of service parameter of a connection between a user terminal (UE) and an input module (UPF) of the core network (CN), or of a connection between the user terminal (UE) and an application (cApp) accessed by said user terminal and connected to the input module of the core network through a data network (DN);, et - a module (MOD_PROC) for managing the radio access network (RAN) depending on the value.

Images