Method for adapting a transmission power of a transmitter device and associated electronic device

Abstract

The invention relates to a 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 comprises: obtaining a value representative of a quality of service parameter of at least one portion of a connection between a user terminal (UE) and an application (cApp) accessed by the user terminal (UE) and connected to the core network via a data network (DN); and adapting the transmission power of the transmitter device according to the obtained value.

Description

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 to wireless communications implemented on radio networks such as mobile networks (e.g., 4G, 5G, B5G, etc.). More specifically, it relates to a method for adapting the 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. Previous technique

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

[0003] The architecture of currently deployed or being deployed wireless telecommunications networks 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, network architectures defined by the 3GPP consortium most often rely on specific equipment, dedicated to precise functionalities, whether at the access network level or the core network level, particularly 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 adopting more flexible architectures for the generation of so-called "5G" wireless networks, in order to be able to meet 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 segmentation of network functions into services and on the virtualization of these network functions. Network function virtualization involves deploying functions usually performed by dedicated and specific equipment onto generic servers located in data centers. These functions are then implemented as computer programs that can be easily activated, deactivated, and configured according to needs. Memory resources or computing capacity can then be allocated dynamically.

[0007] The segmentation 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 anticipated. Recent studies on energy consumption in such networks show, however, that approximately 80% of the energy is consumed by the base stations. Therefore, various strategies have been defined to adapt the transmission power of a base station, or even to put it into standby mode when not in use.

[0008] Thus, a base station is, for example, put into sleep mode or woken up depending on the distance between user terminals and the base station to which they are connected. Other strategies aim to put a base station into sleep mode when the volume of data exchanged is below a predetermined value. A base station can also be put into sleep mode for a specific period of time when it has been previously established—for example, using statistics—that the volume of data exchanged is relatively low during that period (for example, overnight). Finally, other strategies are called multi-criteria because they aim, for example, to minimize a certain amount of energy consumption while maximizing the profit of the operators in charge of these networks.

[0009] However, these sleep and wake 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 various strategies for adapting the transmission power of base stations considered so far do not allow for improving the energy efficiency of a radio access network, while also ensuring a certain quality of service to a given user terminal. Description of the invention

[0010] The present invention aims to remedy all or part of the disadvantages 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 a certain quality of service to a given user terminal.

[0011] To this end, and according to a first aspect, the invention relates to a method for adapting the transmission power of a transmitting device in a radio access network, the radio access network being connected to a core network. The method is implemented by a computer application of a radio access network controller and comprises: - obtaining a representative value of a quality of service parameter for at least a 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, 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 adaptation process may also include one or more of the following characteristics, taken individually or in all technically possible combinations.

[0014] In certain implementation modes, the quality of service parameter is latency, and the adaptation includes an increase in power emission of the emitting device if the representative value of the latency has a value greater than a first threshold value, and a decrease in the emission power of the emitting device if the representative value 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 modes of implementation, the quality of service parameter is a throughput, and the adaptation includes an increase in the transmitting power of the transmitting device if the representative value of the throughput has a value less than a first threshold value, and a decrease in the transmitting power of the transmitting device if the representative value of the throughput 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 achieved, 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.

[0017] Thus, these characteristics allow the base station to consume less energy when the quality of service required by a given user terminal is reached (i.e., when it exceeds a given threshold value). Furthermore, these characteristics aim to improve the quality of service offered to the user terminal when it falls below a certain threshold value.

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

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

[0020] In specific implementation modes, the adaptation process further includes, prior to the step of obtaining a value, a step of identifying a user terminal for which the transmission power of the The transmitting device must be adapted, the identified user terminal corresponding to the user terminal previously mentioned.

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

[0022] In particular implementation modes, the user terminal(s) for which the transmitting 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 current data transmission [i.e., in 5G].

[0023] In particular modes of implementation, the adaptation process further includes 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 implementation modes, said at least one portion of connection 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 includes receiving said value from a core network module called the "end-to-end performance indicator evaluation module", and the transmission power is adapted when units of frequency and / or time resources allocated to said user terminal are used.

[0026] Using an end-to-end performance criterion offers the advantage of reliably reflecting network performance. Furthermore, end-to-end latency and / or throughput values ​​quantify the quality of data actually received by the user terminal. In addition, these characteristics allow the transmission power of a transmitting device—such as a base station—to be adjusted 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 so-called "input module" is specifically 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 terminal's point of view.

[0028] In particular implementation modes, the radio access network controller application includes an HTTP client, the evaluation module includes an HTTP server, and at least one function for obtaining a representative value of a quality of service parameter implemented by the module is exposed to the radio access network controller application through an application programming interface, and the method further includes the following steps, prior to receiving the value: - access, via the computer application of the radio access network controller, to said application programming interface, and, - a transmission, by the computer application of the radio access network controller and to the evaluation module, of a request to obtain a result from an application of at least one function.

[0029] In general, 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 essentially connects a service provider to service consumers (e.g., xApp computer applications) without the consumers needing to know the implementation details of those services.

[0030] These features are advantageous because they allow the application to communicate with the core network module without needing to know the details of how that module's functions are implemented. Furthermore, these features allow the functions implemented by the performance indicator evaluation module to be presented as services accessible via HTTP / 1 or HTTP / 2.

[0031] In particular implementation modes, the radio access network controller includes an HTTP client accessible by the radio access network controller application; the evaluation module includes an HTTP server; and at least one function for obtaining a representative value 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 includes the following steps, prior to receiving the value: - access, by the radio access network controller, to said application programming interface, - a transmission, by the radio access network controller and to the evaluation module, of a request to obtain a result from an application of at least one function.

[0032] 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 - then needs to be implemented.

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

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

[0035] In specific implementation modes, the value obtained is representative of a prediction of the latency or throughput of the connection.

[0036] This feature offers the advantage of allowing the computer application to anticipate changes in latency or throughput, and consequently to adapt the transmission power of the transmitting device accordingly.

[0037] In certain implementation modes, the core network input module is a "User Plan Function" module. This input module, for example, conforms to the 3GPP TS 33.513 standard, version 17.1.0, published on January 6, 2023.

[0038] In specific implementation modes, the radio access network controller is of the "Near Real Time R1C" type. The controller then conforms, for example, to the O-RAN Near-RT R1C Architecture 4.0 specification, "0-RAN.WG3.RlCARCH-R003-v04.00", release 3, published in March 2023.

[0039] In specific implementation modes, the controller application is of type "xApp". An "xApp" application is configured to control radio access network functionalities within a short time frame (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. For example, the xApp application conforms to the O-RAN Study on Security for Near Real Time RIC and xApps 2.0 specification, "O-RAN.WGll.Security-Near-RT-RlC-xApps-TR.0-R003-v02.00", version 3, published in March 2023.

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

[0041] According to a second aspect, the invention relates to a computer program comprising instructions for implementing an adaptation process, 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 the 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 including: - a module for obtaining a representative value of the latency or throughput 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 features and advantages of the present invention will become apparent from the description below, with reference to the accompanying drawings, which illustrate an example of an embodiment without being limiting in any way. In the figures:

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

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

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

[0048] [Fig.4] Figure 4 illustrates, in the form of a flowchart, the main steps of an adaptation process, according to an example of implementation of the invention;

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

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

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

[0052] [Fig.8] Figure 8 schematically represents an example of a request issued by the controller to the performance indicator evaluation module. Description of the implementation methods

[0053] Figure 1 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) including 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 computer, a personal digital assistant, a connected object, or a smartphone.

[0055] In this embodiment, and for the sake of simplicity, the wireless communication system is considered to comprise a single user terminal (UE) and a radio access network (RAN) with a single transmitting device (gNB). It should be noted, however, that there is no limitation on the number of transmitting devices (gNBs) or user terminals (UEs). The following developments can be readily generalized by those skilled in the art to cases where more than one transmitting device (gNB) and one user terminal (UE) are involved.

[0056] The radio access network (RAN) and the core network (CN) belong to a wireless telecommunications network (not shown in Figure 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 this description, this telecommunications network is considered, without limitation, to be a 5G mobile network (the fifth generation of mobile network standards) conforming to the "O-RAN Architecture Description 8.0" specification, 0-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 comprises 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... allow equipment and / or software modules from different vendors to communicate.

[0057] 11 However, it should 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 telephony 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), for example, conforms to the C-RAN paradigm (Cloud-RAN). This architecture combines the virtualization and centralization of base station functionalities using cloud computing. In a C-RAN architecture, the baseband units (BBUs) are no longer located in the immediate vicinity of the base station, but are decentralized and centralized within a centralized pool (BBU).

[0060] Alternatively, the radio access network (RAN) can, for example, conform to the VRAN (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 points 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 subnets (network slices) that coexist simultaneously on the same hardware.

[0061] As illustrated in Figure 1, 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 unit [O-DU) and central unit [O-CU) are deployed on servers remote. Alternatively, the radio unit (O-RU), distributed unit (O-DU) and central unit (O-CU) are all three implemented by the transmitting device (gNB).

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

[0064] 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's usage context.

[0065] This distribution, for example, conforms to 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, V14.0.0, published in April 2017, each with its own advantages and disadvantages in terms of latency, throughput, and implementation complexity. These options are referenced as 1 to 6, 7.1, 7.2, 7.3, and 8.

[0066] In another example, this distribution conforms to Option 7.2 as defined by the O-RAN Alliance. The O-RAN Alliance relied on Option 7.2, defined by the 3GPP consortium, to propose a division of the lower physical layer at the radio unit (O-RU) level and a division of the upper physical layer at the distributed unit (O-DU) level. These divisions are specifically defined in the specification "O-RAN Hardware Reference Design Specification for Outdoor Macrocell with Split Architecture Option 7.2 2.0", 0-RAN.WG7.0MAC-HRD.0-R003-v02.00, release R003, published in March 2023.

[0067] 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 lower physical layer (e.g., the RF chain(s)), analog / digital precoding, data transport according to the eCPRI protocol (evolved Common Public Radio Interface), and synchronization, for example, according to the PTP protocol (Precision Time Protocol), also known as IEEE-1588 and IEC 61588. This PTP protocol is... 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 on June 16, 2020.

[0068] Also in accordance with option 7.2, the distributed unit [O-DU] is configured to manage the upper physical sublayers, MAC (Media Access Control) and RLC (Radio Link Control). The centralized unit [O-CU] is configured to manage the PDCP (Packet Data Convergence Protocol), SDAP (Service Data Adaptation Protocol), and RRC (Radio Resource Control) sublayers. The MAC sublayer is specifically configured to map logical channels to transport channels. The RLC sublayer is specifically configured to manage the transfer of PDU (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 radio medium.

[0069] As illustrated in Figure 1, the radio access network also includes 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, for example, conforms to the O-RAN Near-RT R1C 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 a "near-real-time RIC" for its ability to handle events requiring action within a relatively short timeframe (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. It integrates third-party software applications [xApp] that automate and optimize these control and optimization operations. These software applications [xApp] function as microservices, 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] also includes a module (MOD_KP1) 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] via an N3 interface.

[0072] The input module corresponds for example to the UPF module [acronym for the English “User Plane Function”] defined by the 3GPP specification 23.501 “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 via an N6 interface. Furthermore, 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).

[0074] As illustrated in Figure 1, the transmitting device (gNB) is a base station in 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 user terminals and such an "IAB-donor" base station. A base station is sometimes called a "nodeB" in 3G networks, an "eNodeB" according to the LTE standard (acronym for "Long Term Evolution"), and a "gNodeB" in 5G networks.

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

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

[0077] Figure 3 represents an example of the hardware architecture of an electronic device [D_CTRL] comprising a controller for a radio access network.

[0078] As illustrated in Figure 3, 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.

[0079] The read-only memory 3 of the electronic device (D_CTRL) constitutes a storage medium as proposed, readable by the processor 1, on which a computer program PROG, according to the invention, is stored, comprising instructions for executing steps of the adaptation process as proposed below. The PROG program defines one or more functional modules of the device, which rely on or control the hardware elements 1 to 5 mentioned above, and which include, in particular: - a module for obtaining (MOD_OBT) a value representative of a quality of service parameter for at least a 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 following description, latency or throughput is considered to be end-to-end quality of service parameters. However, the invention can be applied to other quality of service parameters; and, - an adaptation module [MOD_AD] of the transmission power of the transmitting device (gNB) according to the value obtained.

[0080] Furthermore, the electronic device [D_CTRL] may include other modules, in particular to implement specific modes of the adaptation process, as described in more detail later.

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

[0082] As illustrated by Figure 4, the adaptation process includes a first initialization step S1000 during which the flag value start_flag is initialized to 0. This value of 0 determines whether it is a first iteration - and in this case start_flag=0 - or not.

[0083] Then, during step S1010, an RMR (R1C Message Router) type message 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 received, for example, after each connection of the base station (gNB) to the "kpimon xApp" application.

[0084] This message, for example, conforms to the format defined on the page https: / / wiki.o-ran-sc.org / display / 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 typically consists of a header including a base station identifier (called the "Global gNB ID" by the 3GPP consortium, for example, "NYN0001246"), and payload data. This payload data includes, in particular, information about the latency of a specific data stream for a given user terminal, or instructions for the transmitting device to adjust its transmission power.

[0085] This message is decoded, then during an S1020 step, its content is analyzed in order to identify, during an S1020 step, 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 start_flag value is initialized to 0, the start at value is also initialized to 0, and the SLA_LIMIT parameter is initialized as a global variable with a given value (e.g., SLA_LIMIT=15ms). The process then resumes waiting for the receipt of a new RMR message.

[0087] If, however, the identified user terminal [UE] is connected to the telecommunications network through a base station controlled by said controller (CTRL) - e.g., if the identified user terminal (UE) is in a connected RCC (Radio Resource Control) state (Le., in 3G, 4G, 5G) or in an inactive RCC state with a current data transmission (Le., in 5G), for example within an instant messaging application or for small data transmissions ("Small Data Transmission", SDT) -, an S1040 step is implemented during which a representative value of a latency of at least one connection portion 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 portion of the connection 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, this at least one portion of the connection 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 alternative is described in more detail with reference to Figure 5.

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

[0091] If this is the first iteration (e.g., stc!rt_flag=O), then step S1060 is implemented. During this step, the current transmit power (curr_poiver) of the transmitting device (gNB) to which the user terminal (UE) is attached is obtained. Then, during step S1070, the start_flag value is set to 1, and the start_lat parameter value is set to the value obtained during step S1040. Once these values ​​are set, the controller implements step S1080.

[0092] If this is not the first iteration (e.g., if start lag is 0), 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 startjat parameter. If so If this is the case, then step SI 100 is implemented during which the value of the startjat parameter is set to be equal to the value obtained during step S1040. Once this value is set, the controller implements step S1080.

[0093] If, however, the value obtained during step S1040 is greater than or equal to the value of the startjat parameter, the controller implements step S1080.

[0094] Step S1080 consists of determining threshold values ​​for lat_imit and lat_alert based on the value of the start_at parameter. In a particular embodiment, lat_imit = start_jat x M1 and lat_alert = start_jat x M2, with M2 > M1. Thus, M1 is, for example, equal to 1.3, and M2 to 1.6.

[0095] Once these two threshold values ​​are determined, the controller implements step S1110, during which it determines whether the latency threshold value is less than the value obtained in step S1040. If it is not (i.e., if the latency threshold value is greater than or equal to the latency value obtained in step S1040), then step S1120 is implemented, during which it determines that the transmitting power of the transmitting device should be reduced by a predetermined step. This step aims to make the transmitting device less energy-intensive when the quality of service required by a given user terminal is largely achieved. Once it is determined that the transmitting power should be reduced, the controller implements step S1170.

[0096] Returning to step S1110, if the threshold value lat_alert is lower than the value obtained in step S1040, the controller executes step S1130. During this step, it determines whether the value obtained in step S1040 is less than or equal to the SLAJAMIT value, or (logically) whether the value obtained in step S1040 is less than or equal to the threshold value lat_alert. If neither of these is the case, then step S1160 is executed, during which the transmit power of the transmitting device remains constant. In this way, maintaining the current power value prevents continuous oscillation (the "ping-pong" effect) around a certain value.

[0097] If, however, the latency value obtained during step S1040 is greater than the SLAJAMIT value, or if the value obtained during step S1040 is greater than When the threshold value `lat_alert` is reached, the controller implements step S1140. Step S1140 consists of a test to determine whether the transmitting device (gNB) is emitting a certain transmission power (e.g., whether `curr_power` is 0 or not). If the transmitting device (gNB) has zero transmission power, then step S1160 is implemented (the transmitting power of the transmitting device remains unchanged). If, on the other hand, the transmitting device (gNB) has positive transmission power, then the transmission power `curr_power` is increased by a certain step, for example, a predetermined one, during step S1150. This step aims to improve the quality of service offered to the user terminal when it is below a certain threshold value.

[0098] In other words, steps S1110 to S1160 can be summarized as follows when a latency value is reached: the transmitting power of the transmitting device is increased if the latency is greater than a first threshold value (SLA_Iimit or Iat_alert), and conversely, the transmitting power of the transmitting device is reduced if the latency is less than a second threshold value (latencyjimit), the second threshold value being lower than the first threshold value. Thus, if a quality of service effectively delivered to the user terminal is achieved (e.g., if the end-to-end latency value is less than the second threshold value), the transmitting power of the transmitting device is reduced, and conversely, if the quality of service actually delivered to the user terminal is less than a required (or expected) quality of service, then the transmitting power of the transmitting device is increased.

[0099] The preceding developments can be easily adapted by a person skilled in the art to other quality of service parameters, for example, in the case where a representative value of a throughput is obtained. In this case, the transmission power of the transmitting device is increased if the throughput has a value lower than a first threshold value, and conversely, the transmission power of the transmitting device is reduced if the throughput has a value higher than a second threshold value, the second threshold value being higher than the first threshold value.

[0100] The determination process further includes a step S1170 during which the controller determines whether a change in transmission power is required (e.g., if one of the steps S1120 or S1150 has been implemented). If so, then the CTRL controller transmits an instruction to the O-DU. aimed at adapting the transmission power of the transmitting device (gNB) during step S1180. Then, during step S1190, the variable curr_power is set to the new transmission power value. Once the variable curr_power is set to the new power value, step S1200 is implemented.

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

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

[0103] In some implementation modes, the user interface is adapted to allow a user (e.g., a user in charge of managing the radio access network of a device on which the interface is displayed) to adjust the step size for increasing or decreasing 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 process resumes waiting for the reception of a new RMR type message.

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

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

[0106] This step occurs, for example, within a discovery mechanism where the application (xApp) consults a service registry containing all instances of services accessible by that application (xApp), such as an end-to-end performance indicator evaluation service implemented by the MOD_KPI module, as well as the means to access these services. These access means might correspond, for example, to a web address (URL) of the HTTP server associated with that service, or to a web address of the application (xApp) associated with that service.

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

[0108] The management process further includes an S110 step during which the computer application (xApp) transmits, to the MOD_KPI evaluation module, a REQ_AP1 request aimed at obtaining the list of functions implemented by this MOD_KP1 evaluation module of a performance indicator.

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

[0110] The management process further includes an S130 step during which the computer application (xApp) transmits a REQ_F request to the MOD_KP1 evaluation module. This request aims to obtain the result of applying one of the functions exposed by the APL and listed in the RESP_APL response. Figure 8, described below, illustrates an example of a REQ_F request. This REQ_F request is received by the MOD_KPI module during an S220 step and then analyzed during an S230 step to verify that the syntax used conforms to the expected syntax.

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

[0112] If the query is correctly formed, an S250 step is implemented by the MODJCPI 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).

[0113] If it is a current state, the S260 step is implemented by the MOD_PROBE module of the CTRL controller. During this S260 step, 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 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 REQ_F request aims to obtain a value representative of a current state of the latency (resp. throughput) of the connection between the user terminal (UE) and the input module (UPF) of the core network, a latency (resp. throughput) measurement command such as the pingf command (resp. iperfff) is applied between the user terminal (UE) and the input module (UPF) of the core network. The pingf and iperff commands are known to those skilled in the art and are not described further here.

[0115] Alternatively, if the REQ_F request aims to obtain a value representative of a current state of the latency (resp. throughput) of the connection between the user terminal (UE) and the application (cApp) accessed by this user terminal, a latency (resp. throughput) measurement command such as the ping command (resp. iperf(J)) 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 value T UE-UPF The representative end-to-end latency between the user terminal [UE] and the core network input module [UPF] is expressed as: TUE -u PP — T'UE-ORU + T ORU-ODU + T ODU-OCU + T ocu UPP with T A -B the latency value between component A and component B.

[0117] The value T UE-cApprepresentative 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: T 1 UE-cApp — TUE-UPF + TUPF-CAPP

[0118] If a prediction is involved, step S270 is implemented, during which a representative value for the predicted latency or throughput of the connection between the user terminal (UE) and the core network input module (UPF), 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.

[0119] 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 neural network trained 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).

[0120] In one specific implementation example, the MOD_PROBE module takes as input historical data concerning latency, throughput, transmission power, the geographic locations of user terminals, and other data such as network load. An objective function of the MOD_PROBE module is then configured to predict a quality of service (e.g., latency and / or throughput) using the input data, thereby enabling the CTRL controller to make better decisions regarding transmission power control. The objective function aims to either minimize latency, maximize throughput, or achieve a compromise between these two measures. Finally, it is important to note that the learning phase is implemented, for example, using cloud computing practices.

[0121] The management process further includes an S280 step during which the M0D_KPI evaluation module transmits a RESP_F response, including the required representative value, to the computer application (xApp). The format of this RESP_F response is relatively similar to that of the REQ_F query. This value is received by the MOD_RX module of the computer application during an S150 step.

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

[0123] 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 well known, 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 a PRB (Physical Resource Block). Thus, for 4G, a PRB lasts, for example, 0.5 ms and consists of several (e.g., 7) OFDM symbols, and the bandwidth of a PRB is 12 subcarriers.

[0124] Thus, the transmitting 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.

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

[0126] As illustrated in Figure 6, the radio access network controller (CTRL) includes a computer application (xApp) that includes an HTTP client. The MOD_KPI module for evaluating a performance indicator includes 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).

[0127] The MOD_PROBE submodule is configured to obtain a value (E2E_KP1#1) representative of the current latency or connection throughput between the user terminal (UE) and the core network's input module (UPF). To achieve this, the evaluation module (MOD_KP1) is connected to the output of the input module (UPF) and, for example, configured to execute the pingQ command between the input module and the input module. (UPF) and the user terminal (UE) to obtain a latency value, or the iperf(J) command between the input module (UPF) and the user terminal (UE) to obtain a throughput value.

[0128] Alternatively, or in combination with other methods, the MOD_PROBE submodule is configured to obtain a value (E2E_KPI#2) representative of the current 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 pingQ (resp. iperfQ) command between this server and the user terminal (UE) to obtain a latency (resp. throughput) value.

[0129] The MOD_PRED submodule is configured to determine a value representing 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 representing 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). To do this, the 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 neural network trained to predict future latency and / or throughput values, based on past values ​​and / or the type of data expected to be exchanged.

[0130] Using a client-server architecture between the application (xApp) and the performance indicator evaluation module (MOD_KPI) allows the functions implemented by this MOD_KPI module to be presented as services accessible via HTTP / 1 or HTTP / 2. Furthermore, the API exposes the functionalities offered by the HTTP server (and more generally, implemented by the performance indicator evaluation module (MOD_KP1)) to the HTTP client without requiring the client to know the implementation details of these functionalities. The API also exposes how these functionalities can be accessed (for example, the name of a specific function to call, as well as the input parameters for that function).

[0131] These functionalities correspond to those offered by the MOD_PROBE and MOD_PRED modules: - obtaining a value representative of a current state of latency or connection throughput between the user terminal [UE] and the input module (UPF) of the core network, - obtaining a value representative of a current state of latency or connection throughput 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 connection throughput 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].

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

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

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

[0135] This configuration proves particularly advantageous when the controller (CTRL) includes multiple applications (xApps) configured to access the core network module (or other modules). Indeed, the implementation of the applications (xApps) is then simplified since only one HTTP client is embedded by the controller (CTRL) – and not one HTTP client per application in the plurality.

[0136] The APIs shown with reference to Figures 6 and 7 are, for example, of the REST type. Using a REST API (the acronym stands for "Representational State Transfer") is advantageous because that it constitutes a standardized means of communication using the HTTP protocol between the HTTP client and the HTTP server.

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

[0138] As illustrated in Figure 8, the query includes: - an 810 field containing the name of the function called [for example GET E2E_KPIJatency or GET E2E_KPI_throughput]; - an 820 field containing an identifier of the xApp application that issued this request; - a field 830 including a flag [“flag” according to Anglo-Saxon terminology] whose value characterizes whether a current state or a prediction of a performance criterion is required; - a field 840 including 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 containing an identifier of the cApp application accessed by the terminal. This value is only necessary if the xApp application requires a value representing the throughput or latency of a connection between the user terminal [UE] and this cApp application; and, - a field 870 containing a time corresponding to a future instant. This value is only necessary in the case where a value representing a prediction of a throughput or 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 (S1040) a value representative of a quality of service parameter of at least one portion of 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 (S1120, S1150, S1160) of the transmission power of the transmitting device (gNB) according to the value obtained.

2. The adaptation method of claim 1, wherein the quality of service parameter is a latency, and the adaptation (S1120, S1150, S1160) comprises an increase (S1150) in 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 (S1120) in 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. The adaptation method of claim 1, wherein the quality of service parameter is a flow rate, and the adaptation (S1120, S1150, S1160) comprises an increase (S1150) 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 (S1120) 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. 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 (S1160), 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. Adaptation method according to one of claims 1 to 5, further comprising, prior to the step (S1040) of obtaining a value, a step (S1020) 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 (S1200), 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 (S1040) the value comprising receiving (S150), from a module (MOD_KP1) 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. Adaptation method according to claim 8, 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 the module (MODJCPI) 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 (S150) the value: - 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 (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_KP1) 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 receiving (S150) the value: - 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_KP1) of the core network, of a request [REQ_F for obtaining a result from an application of 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 radio access network [RAN] controller [CTRL] 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.

Images