Method for adapting the transmission power of a transmitting device and associated electronic device

Abstract

Method for adapting the transmission power of a transmitting device and associated electronic device. The invention relates to a method for adapting the transmission power of a transmitting device (gNB) of a radio access network (RAN), the radio access network (RAN) being connected to a core network (CN). The method comprises: obtaining a value representative of a quality of service parameter for at least a portion of the connection between a user terminal (UE) and an application (cApp) accessed by said user terminal (UE) and connected to the core network via a data network (DN); and adapting the transmission power of the transmitting device according to the value obtained. Figure for the abstract: Fig. 1.

Description

Title of the invention: Method for adapting the transmission power of a transmitting device and associated electronic device Technical field

[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 adapting a transmission power of a transmitting device. 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, different technologies are currently being implemented and are still being improved with a view to optimal exploitation in the years to come.

[0003] The architecture of wireless telecommunications networks currently deployed or in the process of being deployed is defined by the standardization consortium known as 3GPP (Third Generation Partnership Project). This is particularly the case for so-called 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, in particular with regard to the transmission of packets from or to a mobile terminal.

[0005] The lack of flexibility and scalability inherent in this type of architecture has led the 3GPP consortium to consider the adoption of 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 meet 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 center" according to Anglo-Saxon terminology). These functions are then implemented in the form of computer programs that can be easily activated, deactivated and configured according to the needs. Memory resources or computing capacity can then be allocated dynamically.

[0007] The division of network functions into services and the virtualization of these network functions aim in particular to improve the energy efficiency of a 5G cellular network. This efficiency criterion is crucial in the context of 5G where a significant increase in data traffic is envisaged. Recent studies relating to energy consumption in such networks show, however, that approximately 80% of the energy is consumed by the base stations of these networks. Also, different strategies have been defined which aim to adapt the transmission power of a base station, or even to put it on standby when not in use.

[0008] Thus, a base station is, for example, put on standby or woken up depending on a distance between user terminals and the base station to which they are attached. Other strategies aim to put a base station on standby when the volume of data exchanged is less than a predetermined value. A base station can also be put on standby for a determined period of time when it has been previously established - for example using statistics - that the volume of data exchanged is relatively low during this period (for example, during the night). Finally, other strategies are said to be multi-criteria since they aim, for example, to minimize a certain energy consumption, while maximizing the profit of the operators in charge of these networks.

[0009] However, these standby and wake-up decisions are implemented at a high level, i.e., for a large number of user terminals, and are therefore not specific to a given user terminal. A fortiori, the different strategies for adapting the transmission power of the base stations considered up to now do not make it possible to improve the energy efficiency of a radio access network, while also ensuring a certain quality of service for a given user terminal. Statement of the invention

[0010] 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 makes it possible both to improve the energy efficiency of a radio access network, while also ensuring that a certain quality of service is provided to a given user terminal.

[0011] To this end, and according to a first aspect, the invention relates to a method for adapting a transmission power of a transmitting device of a radio access network, the radio access network being connected to a core network. The method is implemented by a computer application of a controller of the radio access network and comprises: • obtaining a value representative of a quality of service parameter of at least one portion of the connection between a user terminal attached to the transmitting device and an application accessed by said user terminal and connected to the core network via a data network; and, • an adaptation of the transmission power of the transmitting device according to the value obtained.

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

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

[0014] In particular embodiments, the quality of service parameter is a latency, and the adaptation comprises an increase in the transmission power of the transmitting device if the value representative of the latency has a value greater than a first threshold value, and a decrease in the transmission power of the transmitting device if the value representative of the latency has a value less than a second threshold value, the second threshold value being less than the first threshold value.

[0015] In particular embodiments, the quality of service parameter is a flow rate, and the adaptation comprises an increase in the transmission power of the transmitting device if the value representative of 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 value representative of the flow rate has a value greater than a second threshold value, the second threshold value being greater than the first threshold value.

[0016] In other words, if a quality of service actually provided to the user terminal is reached, 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.

[0017] 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 greater 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.

[0018] In particular modes of implementation, the first threshold value corresponds to a quality of service required by said user terminal.

[0019] In particular modes of implementation, the adaptation method further comprises a step of transmission, by the computer application of the controller and to destination of a distributed unit associated with the transmitting device, of an instruction aimed at adapting the transmission power of said transmitting device.

[0020] In particular embodiments, the adaptation method further comprises, prior to the step of obtaining a value, a step of identifying a user terminal for which the transmission power of the transmitting device must be adapted, the identified user terminal corresponding to the previously mentioned user terminal.

[0021] This characteristic makes it possible to determine the user terminal(s) for which values ​​representative of a quality of service parameter must be obtained, and thus to adapt the transmission power of the transmitting device as a function of values ​​specific to these same user terminals.

[0022] In particular modes of implementation, the user terminal(s) for which the transmission power of the transmitting device must be adapted are in a connected RCC (acronym for Radio Resource Control) state (i.e., in 3G, 4G, 5G) or in an inactive RCC state with a current data transmission (i.e., in 5G).

[0023] In particular modes of implementation, the adaptation method further comprises a step of transmission, by the computer application of the controller and to a graphical interface, of an instruction aimed at displaying the adapted transmission power and / or the representative value of the quality of service parameter.

[0024] In particular modes of implementation, said at least one connection portion corresponds to the connection between the user terminal and an input module of the core network, or to the connection between the user terminal and the application accessed by said user terminal.

[0025] Obtaining the value then comprises receiving, from a module of the core network called “end-to-end performance indicator evaluation module” of said value, and the transmission power is adapted when frequency and / or time resource units allocated to said user terminal are used.

[0026] The use of an end-to-end performance criterion offers the advantage of reliably reflecting the performance of a network. Furthermore, the end-to-end latency and / or throughput values ​​make it possible to quantify the quality of the data actually received by the user terminal. Furthermore, these characteristics make it possible to adapt 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 with each other.

[0027] As mentioned below, the module called “input module” is in particular 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 from the terminal view.

[0028] In particular embodiments, the application of the radio access network controller comprises an HTTP client, the evaluation module comprises an HTTP server, and at least one function for obtaining a value representative of a quality of service parameter implemented by the module is exposed to the application of the radio access network controller through an application programming interface, 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 evaluation module, of a request to obtain a result of an application of the at least one function.

[0029] Generally speaking, an application programming interface (or API) is a set of tools, definitions and protocols that facilitate the creation of application functions configured to manage the radio access network here. An API connects a service provider to service consumers (eg, xApp computer applications) without the latter having to know the implementation details of these services.

[0030] 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 make it possible to present the functions implemented by the performance indicator evaluation module as services accessible via the HTTP / 1 or HTTP / 2 protocol.

[0031] 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 evaluation module comprises an HTTP server; and at least one function for obtaining a value representative of a quality of service parameter implemented by this evaluation module is exposed to the controller through an application programming interface, and the method further comprises the following steps, prior to receiving the value: access, by the radio access network controller, to said application programming interface, a transmission, by the controller of the radio access network and to the evaluation module, of a request to obtain a result of an application of the at least one function.

[0032] In addition to the advantages previously mentioned, these characteristics are advantageous when the controller comprises 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.

[0033] In particular modes of implementation, the value obtained is representative of a current state of the latency or the flow rate of the connection.

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

[0035] In particular modes of implementation, the value obtained is representative of a prediction of the latency or the flow rate of the connection.

[0036] This characteristic offers the advantage of allowing the computer application to anticipate a change in latency or throughput, and a fortiori to adapt the transmission power of the transmitting device accordingly.

[0037] In particular modes of implementation, the input module of the core network 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.

[0038] In particular implementation modes, the controller of the radio access network 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, “0-RAN.WG3.RICARCH-R003-v04.00”, release 3, published in March 2023.

[0039] In particular implementation modes, the controller application is of the “xApp” type. An “xApp” type application is configured to control radio access network functionalities within a short time (e.g., less than 1 second). It is conventionally 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 Study on Security for Near Real Time RIC and xApps 2.0, “0-RAN.WGll.Security-Near-RT-RIC-xApps-TR.0-R003-v02.00”, version 3, published in March 2023.

[0040] In particular embodiments, the core network input module is configured as a gateway between the radio access network and a data network of the core network.

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

[0042] 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.

[0043] According to a fourth aspect, the invention relates to an electronic device comprising a radio access network controller configured to adapt a transmission power of a transmitting device of a radio access network, the radio access network being connected to a core network, the controller comprising a computer application comprising: • a module for obtaining a value representative of a latency or a flow rate of at least a portion of the connection between a user terminal and an application accessed by said user terminal and connected to the core network via a data network; and, • a module for adapting the transmission power of the transmitting device according to the value obtained. Brief description of the drawings

[0044] 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:

[0045] [Fig-1] [Fig.l] is an example of a wireless communication system in which an adaptation method according to the invention is implemented;

[0046] [Fig.2] [Fig.2] schematically represents modules embedded in an ap plication of a controller of a radio access network, according to an exemplary implementation of the invention;

[0047] [Fig.3] [Fig.3] represents an example of hardware architecture of an electronic device comprising a controller of a radio access network;

[0048] [Fig.4] [Fig.4] illustrates, in the form of a flowchart, the main stages of a adaptation method, according to an exemplary implementation of the invention;

[0049] [Fig.5] [Fig.5] illustrates, in the form of a flowchart, an example of obtaining a value representative of an end-to-end latency or throughput;

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

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

[0052] [Fig.8] [Fig.8] schematically represents an example of a request sent by the controller to the module for evaluating a performance indicator. Description of the embodiments

[0053] [Fig.l] is an example of a wireless communication system in which an adaptation method according to the invention is implemented.

[0054] 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.

[0055] 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 can indeed be generalized without difficulty by those skilled in the art to the case where more than one transmitting device (gNB) and one user terminal (UE) are considered.

[0056] The radio access network (RAN) and the core network (CN) belong to a wireless telecommunications network (not shown in [Fig.l]) to which the user terminal (UE) is connected, and are able to communicate 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.0AD-R003-v08.00, version 3, published in March 2023 by the O-RAN alliance (acronym for “Open Radio Access Network”). The O-RAN alliance is composed of mobile network operators, manufacturers, suppliers and research and academic organizations working in the field of telecommunications.It 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.

[0057] It should however be specified 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").

[0058] 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 loosely coupled services.

[0059] Thus, the radio access network (RAN) is for example compliant with the C- paradigm RAN ("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") are no longer located in the immediate vicinity of the base station, but are relocated and centralized within a centralized pool ("BBU pool" in English terminology).

[0060] 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 makes it possible to create isolated subnetworks (network slices or “slices” according to English terminology), which coexist simultaneously on the same hardware equipment.

[0061] As illustrated in [Fig.l], the radio access network (RAN) comprises a radio unit (O-RU), a distributed unit (O-DU) and a central unit (O-CU).

[0062] The radio unit (O-RU) is for example deployed on a transmitting device (gNB), and the distributed (O-DU) and central (O-CU) units are deployed on remote servers. Alternatively, the radio (O-RU), distributed (O-DU) and central (O-CU) units are all three implemented by the transmitting device (gNB).

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

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

[0065] This distribution is for example in accordance with one of the options described in the 3GPP specification “Study on new radio access technology: Radio access architecture and interfaces”, TR 38.801, release 14, vl4.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 and 8.

[0066] According to 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 division of the low physical layer at the level of the radio unit (O-RU), and a division of the high physical layer at the level of the distributed unit (O-DU). These divisions are notably defined in the specification “0-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.

[0067] The radio unit (0-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 (0-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") and also known as IEEE-1588 and IEC 61588. This PTP protocol is for example defined in the document "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems," in IEEE Std 1588-2019 (Revision of IEEE Std 1588-2008), pp. 1-499, published June 16, 2020.

[0068] Still in accordance with option 7.2, the distributed unit (O-DU) is configured to manage the high physical sub-layers, MAC (acronym for "Media Access Control") and RLC (acronym for "Radio LinkControl"). The centralized unit (O-CU) is, for its part, 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") sub-layers. The MAC sub-layer is in particular configured to establish a correspondence between the logical channels and the transport channels. The RLC sub-layer is in particular configured to manage the transfer of PDU (acronym for "Packet Data Unit") packets originating 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.

[0069] As illustrated by [Fig. 1], the radio access network further comprises a radio access network (RAN) controller (CTRL) in which a plurality of xApp application functions, hereinafter referred to as “third-party computing applications,” are embedded. This controller is, for example, compliant with the O-RAN Near-RT RIC Architecture 4.0 specification, “0-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).

[0070] 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 (O-DU) and centralized (O-CU) units through E2 interfaces. To do this, it integrates third-party IT applications (xApps) that automate and optimize these control and optimization operations. These IT applications (xApps) operate as micro-services, and are also deployed on a cloud network.

[0071] 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 [Fig.2]. The input module (UPF) is connected to the centralized unit (O-CU) through an N3 interface.

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

[0073] The input module (UPF) and the data network (DN) are connected through an interface N6. In addition, at least one application (cApp) is connected to this data network (DN). It is important to note here that although [Fig.l] 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).

[0074] As illustrated in [Fig.l], the transmitting device (gNB) is a base station of the radio access network (RAN). It can be either an "lAB-donor" type base station connected to the core network, or an intermediate base station between the user terminals and such an "lAB-donor" type 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.

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

[0076] The controller (CTRL) is a software component. As illustrated in [Fig.2], this radio access network (RAN) controller (CTRL) comprises an application (xApp) including the MOD_OBT and M0D_AD modules whose functionalities are described with reference to [Fig.3].

[0077] [Fig.3] represents an example of hardware architecture of an electronic device (D_CTRL) comprising a controller of a radio access network.

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

[0079] 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 the execution of steps of the adaptation 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 include in particular: • a module for obtaining (MOD_OBT) a value representative of a quality of service parameter of at least one portion of the connection between a user terminal (UE) attached to the transmitting device and an application (cApp) accessed by said user terminal and connected to the core network via a data network (DN). In the remainder of the description, end-to-end quality of service parameters are considered to be a latency or a throughput. However, the invention can be applied to other quality of service parameters; and, • an adaptation module (M0D_AD) of the transmission power of the transmitting device (gNB) according to the value obtained.

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

[0081] [Fig.4] illustrates, in the form of a flowchart, the main steps of an adaptation method, according to an example of implementation of the invention. In this example, a latency criterion is considered. The method for adapting the transmission power of a transmitting device is an iterative algorithm implemented by a computer application xApp of the controller (CTRL).

[0082] As illustrated by [Fig.4], the adaptation method comprises a first initialization step S1000 during which the flag value slarljlag is initialized to 0. This value at 0 makes it possible to determine whether this is a first iteration - and in this case start^flag=0 - or not.

[0083] Then, during a step S1010, a message of type RMR (acronym for “RIC Message Router”) is received by the xApp application implementing the method according to the invention. This message is typically sent by an application called “kpimon xApp” configured to collect information from the O-DU and O-CU units using an E2 interface. This message is for example received after each connection of the base station (gNB) to the “kpimon xApp” application.

[0084] This message is for example compliant with the format defined on the page https: / / wiki.o-ran-sc.org / displav / RICP / RMR+Message+Conventions or on the page https: / / docs.o-ran-sc.org / projects / o-ran-sc-ric-plt-lib-rmr / en / latest / user-guide.html. It is typically composed of a header including a base station identifier (named "Global gNB ID" by the 3GPP consortium, for example "NYN0001246"), and useful data. This useful data includes in particular data relating to the latency of a specific data stream for a given user terminal, or instructions for the transmitting device to adapt its transmission power.

[0085] This message is decoded, then during a step S1020, its content is analyzed in order to identify, during a step S1020, a user terminal (UE) for which the transmission power of the transmitting device must be adapted.

[0086] If the identified user terminal (UE) is not connected to the telecommunications network, then step S1030 is implemented during which the flag value startjlag is initialized to 0, the value start_lat is also initialized to 0, and the parameter SLA_L1M1T is initialized as a global variable having a given value (eg, SIA_L1M1T=15ms). Then the method resumes waiting for the reception of a new message of type RMR.

[0087] If, on the other hand, the identified user terminal (UE) is connected to the telecommunications network via a base station controlled by said controller (CTRL) - eg, if the identified user terminal (UE) is in a connected RCC (acronym for Radio Resource Control) state (i.e., in 3G, 4G, 5G) or in an inactive RCC state with a current data transmission (i.e., in 5G), for example in the context of an instant messaging application or for low-volume data transmissions ("Small Data Transmission", SDT) -, a step S1040 is implemented during which a value representative of a latency of at least a portion 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) is obtained.

[0088] According to a particular embodiment, said at least one connection portion between the user terminal (UE) and the application (cApp) corresponds to the connection between the radio unit (O-RU) and the centralized unit (O-CU) of the radio access network (RAN) of the telecommunications network.

[0089] Alternatively, said at least one connection portion between the user terminal (UE) and the application (cApp) corresponds to the end-to-end connection between the user terminal (UE) and the application (cApp) or to the end-to-end connection between the user terminal (UE) and an input module (UPF) of the core network (CN). This variant is described in more detail with reference to [Fig.5].

[0090] The method for adapting the transmission power of a transmitting device further comprises a step S1050 during which it is determined whether it is of a first iteration of the algorithm or not.

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

[0092] If this is not a first iteration (eg, if start^flag^O), then step S1090 is implemented. During this step, it is tested whether the latency value obtained during step S1040 is less than the value of the start_lat parameter. If this is the case, then step S1100 is implemented during which the value of the start_lat parameter is set as being equal to the value obtained during step S1040. Once this value is set, the controller implements step S1080.

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

[0094] Step S1080 consists of determining threshold and lat_alert values ​​in function of the value of the start_lat parameter. In a particular embodiment, - start_lat x Ml and lat_alert - start_lat x M2, with M2 > Ml. Thus, Ml is for example equal to 1.3, and M2 to 1.6.

[0095] Once these two threshold values ​​have been determined, the controller implements a step SI 110 during which it is determined whether the threshold value is lower than the value obtained during step S1040. If this is not the case (i.e., if the threshold value is greater than or equal to the latency value obtained during step S1040), then step S1 120 is implemented during which it is determined that the transmission power of the transmitting device must be reduced according to a step, for example predetermined. 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 determined that the transmission power must be reduced, the controller implements step S1 170.

[0096] Returning to step S1110, if on the other hand the threshold value is lower than the value obtained during step S1040, the controller implements step S1130 during which it is determined whether the value obtained during step S1040 is lower than or equal to the value of SIA_LIMIT or (or logic) whether the value obtained during step S1040 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 retaining the current power value makes it possible to avoid a continuous oscillation (ping pong effect) around a certain value.

[0097] If, on the other hand, the latency value obtained during step S1040 is greater than the value of SLA_L1M1T or if the value obtained during step S1040 is greater than the threshold value lat_alert, then the controller implements step S1 140. Step S1 140 consists of a test to determine whether or not the transmitting device (gNB) transmits a certain transmission power (eg, whether currj>ower = 0 or not). If the transmitting device (gNB) has zero transmission power, then step S1 160 is implemented (the transmission power of the transmitting device does not change). If the transmitting device (gNB) has a positive transmission power, then the transmission power curr j>ower is increased by a certain step, for example predetermined, during a step SI 150. This step aims to improve the quality of service offered to the user terminal when the latter is lower than a certain threshold value.

[0098] In other words, steps SI 110 to SI 160 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 (latencyjimif), 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, then the transmission power of the transmitting device is increased.

[0099] The preceding developments can be adapted without difficulty by a person skilled in the art to other quality of service parameters, for example in the case where a value representative of a flow rate is obtained. 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.

[0100] The determining method further comprises a step SI 170 during which the controller determines whether a change in the transmission power is required (eg, whether one of steps SI 120 or SI 150 has been implemented). If this is the case, then the controller CTRL transmits an instruction to the distributed unit (0-DU) to adapt the transmission power of the transmitting device (gNB) during a step SI 180. Then, during a step SI 190, the variable currj>ower is set as now being equal to the new transmission power value. Once the variable curr j>ower set to the new power value, step S1200 is implemented.

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

[0102] 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 via a dedicated user interface.

[0103] In embodiments, the user interface is adapted to allow a user (eg, a user in charge of managing said radio access network of a device on which said interface is displayed) 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 ​​and lat_alert during step S1080. Then the method resumes waiting for the reception of a new RMR type message.

[0104] [Fig.5] illustrates, in the form of a flowchart, an example of a method for obtaining a value representative of an end-to-end latency or throughput. This method is implemented between a module for evaluating a performance criterion (M0D_KPI) of the core network (CN) and the previously mentioned xApp computer application, or between the evaluation module and another xApp computer application, distinct from the xApp application and also belonging to the CTRL controller, and implementing the adaptation method. In the latter case, the two xApp applications interact with each other through an E2 interface.

[0105] As illustrated by [Fig.5], the obtaining method comprises a first step S100 of obtaining, by the computer application (xApp) of the controller (CTRL) implementing said obtaining method, a means of accessing the module M0D_KPI for evaluating a performance indicator.

[0106] 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 a service for evaluating an end-to-end performance indicator implemented by the M0D_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.

[0107] 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.

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

[0109] 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 RESP_API response to the computer application (xApp). This RESP_API response includes for example the list of functions exposed to this computer application (xApp), and the manner in which these functions can be accessed (for example the name of a specific function to be called, as well as the input parameters of this function). This RESP_API response is received by the computer application (xApp) during a step S120.

[0110] The management method further comprises a step S130 during which the computer application (xApp) transmits, to the evaluation module M0D_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. [Fig.8], described below, illustrates an example of a request REQ_F. This request REQ_F is received by the module M0D_KPI during a step S220, then analyzed during a step S230 in order to verify whether the syntax used is consistent with that expected.

[0111] 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.

[0112] 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 which is required by the computer application (xApp).

[0113] If it is a current state, step S260 is implemented by the MOD_PROBE module of the CTRL controller. 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.

[0114] 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. iperfO) 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. profession and are not described further here.

[0115] 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.

[0116] Thus, with reference to Figure 1, the Tue-upf value representative of the end-to-end latency between the user terminal (UE) and the input module (UPF) of the core network is expressed in the form:

[0117] TUE-UPF ~ ^UEORU+ ORU-ODU + ODU-OCU + T()CU_UPF

[0118] with TA_B the latency value between component A and component B.

[0119] The TTJE-cApp value representative of the end-to-end latency between the terminal uti user terminal (UE) and the application accessed by said user terminal (UE) is expressed in the form:

[0120] T UE-eApp — T UE-UPF + UPF-cApp

[0121] 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 MOD_PRED module of the CTRL controller.

[0122] 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 quality of service required by the user terminal (UE).

[0123] According to a particular example of implementation, the MOD_PROBE module takes as input a history of data concerning the latency, the throughput, the transmission power, the geographical positions of the user terminals, other data such as the network load. An objective function of the MOD_PROB module is then configured so as 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 the latency, or to maximize the 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.

[0124] The management method further comprises a step S280 during which the evaluation module M0D_KPI transmits, to the computer application (xApp), a response RESP_F including the required representative value. The format of this response RESP_F is relatively similar to that of the request REQ_F. This value is received by the module M0D_RX of the computer application during a step S150.

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

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

[0127] Thus, the transmission power of the transmitting device (gNB) is only controlled (and where appropriate 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.

[0128] [Fig.6] schematically represents a client-server configuration of the controller and the evaluation module of a performance indicator, according to a first example of implementation.

[0129] As illustrated in [Fig.6], the radio access network controller (CTRL) comprises a computer application (xApp) including an HTTP client. The M0D_KPI module for evaluating a performance indicator comprises two sub-modules MOD_PROBE and MOD_PRED as well as an HTTP server connected to the MOD_PROBE and MOD_PRED modules and coupled to an application programming interface (API).

[0130] The MOD_PROBE sub-module is 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.

[0131] Alternatively or in combination, the MOD_PROBE submodule 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 the application (cApp) 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 (resp. throughput) value.

[0132] The MOD_PRED sub-module is 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 the user terminal (UE). 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.

[0133] 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 via 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).

[0134] 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 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 flow rate 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 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 the user terminal (UE).

[0135] [Fig.7] 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.

[0136] The module (MOD_KPI) for evaluating a performance indicator is identical to that described with reference to [Fig.6], and is therefore not re-described, for the sake of conciseness.

[0137] As illustrated in [Fig.7], the controller (CTRL) comprises an HTTP client as well as a computer application (xApp) connected to the HTTP client.

[0138] 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 by the controller (CTRL) - and not one HTTP client per application of the plurality -.

[0139] The APIs presented with reference to Figures 6 and 7 are, for example, of the REST type. The use of a REST type API (the acronym for “REpresentational State Transfer”) is advantageous in that it constitutes a standardized means of communication using the HTTP protocol between the HTTP client and the HTTP server.

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

[0141] As illustrated by [Fig.8], the request includes: • an 810 field including the name of the function called (for example GET E2E_KPI_latency or GET E2E_KPI_throughput); • a field 820 including an identifier of the xApp application having issued this request; • a field 830 comprising a flag (“flag” according to Anglo-Saxon terminology) 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 including a time corresponding to the current time; • a field 860 including an identifier of the cApp application accessed by the terminal. This value is only necessary in the case where a value representative of a throughput or latency of a connection between the user terminal (UE) and this cApp application is required by the application in- xApp computing; 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 cApp application is required by the xApp computer application.

Claims

Claims

1. Method for adapting a transmission power of a transmitter device (gNB) of a radio access network (RAN), the radio access network (RAN) being connected to a core network (CN), the method being implemented by a computer application (xApp) of a controller (CTRL) of the radio access network (RAN) and comprising: • obtaining (S 1040) a value representative of a quality of service parameter of at least one connection portion between a user terminal (UE) and an application (cApp) accessed by said user terminal (UE) and connected to the core network via a data network (DN); and, • adapting (S 1120, S1150, S1160) the transmission power of the transmitter device (gNB) as a function of the obtained value.

2. An adaptation method according to claim 1, wherein the quality of service parameter is a latency, and the adaptation (SI 120, SI 150, SI 160) comprises an increase (SI 150) of the transmission power of the transmitting device (gNb) if the value representative of the latency has a value greater than a first threshold value, and a decrease (SI 120) of the transmission power of the transmitting device (gNb) if the value representative of the latency has a value less than a second threshold value, the second threshold value being less than the first threshold value.

3. An adaptation method according to claim 1, wherein the quality of service parameter is a flow rate, and the adaptation (SI 120, SI 150, SI 160) comprises an increase (SI 150) of the transmission power of the transmitting device (gNb) if the value representative of the flow rate has a value lower than a first threshold value, and a decrease (SI 120) of the transmission power of the transmitting device (gNb) if the value representative of the flow rate has a value greater than a second threshold value, the second threshold value being greater than the first threshold value.

4. Adaptation method according to claim 2 or 3, wherein the first threshold value corresponds to a quality of service required by said user terminal (UE).

5. Adaptation method according to one of claims 1 to 4, further comprising a step of transmission (SI 160), by the computer application (xApp) of the controller (CTRL) and to a distributed unit (O-DU) associated with the transmitting device (gNB), of an instruction aimed at adapting the transmission power of said transmitting device (gNB).

6. An adaptation method according to one of claims 1 to 5, further comprising, prior to the step (S 1040) of obtaining a value, a step (S 1020) of identifying a user terminal for which the transmission power of the transmitting device must be adapted, the identified user terminal corresponding to said user terminal (UE).

7. Adaptation method according to one of claims 1 to 6, further comprising a step of transmission (S 1200), by the computer application (xApp) of the controller (CTRL) and to a graphical interface, of an instruction aimed at displaying the adapted transmission power and / or the representative value of the quality of service parameter.

8. Adaptation method according to one of claims 1 to 7, wherein the at least one connection portion corresponds to the connection between the user terminal (UE) and an input module (UPF) of the core network (CN), or to the connection between the user terminal (UE) and the application (cApp) accessed by said user terminal (UE), obtaining (S 1040) the value comprising receiving (S 150), from a module (M0D_KPI) of the core network (CN), said value, and the transmission power being adapted when frequency and / or time resource units (PRB) allocated to said user terminal (UE) are used.

9. An adaptation method according to claim 8, wherein the application (xApp) of the controller of the radio access network comprises an HTTP client, the module (M0D_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 the module (M0D_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 receiving (S 150) the value: • access (S 120), by the computer application (xApp) of the controller (CTRL) of the radio access network (RAN), to said application programming interface (API), and, • 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 (REQ_F) to obtain a result of an application of the at least one function.

10. Adaptation method according to claim 8, 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 the module (MOD_KPI) is exposed to the controller (CTRL) through an application programming interface (API), the method further comprising the following steps, prior to the reception (S 150) of the value: • an access (S 120), 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 (REQ_F) for obtaining a result of an application of the at least one function.;

11. Adaptation method according to one of claims 1 to 10, in which the value obtained is representative of a prediction of the latency or the flow rate of the connection.

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

13. A computer-readable recording medium having a computer program recorded thereon according to claim 12.

14. Electronic device (D_CTRL) comprising a controller (CTRL) of radio access network (RAN) configured to adapt a transmission power of a transmitter device (gNB) of a radio access network (RAN), the radio access network (RAN) being connected to a core network (CN), the controller comprising a computer application (xApp) comprising: • a module for obtaining (MOD_OBT) a value representative of a quality of service parameter of at least one portion of the connection between a user terminal (UE) and an application (cApp) accessed by said user terminal (UE) and connected to the core network via a data network (DN); and, • an adaptation module (MOD_AD) of the transmission power of the transmitting device (gNB) according to the value obtained.