The method is implemented by computers and machines to manage the use of energy-saving applications for cells, and the means are readable by computers.

Abstract

The invention relates to a method performed by a computer to manage the use of energy-saving applications for cells in a communication network. Each energy-saving application is capable of operating to reduce the energy consumption of a cell in the communication network, and each energy-saving application has a corresponding energy model relating network traffic levels to the energy savings provided by the energy-saving application.This method consists of, for the first cell in the communication network: predicting (901) the network traffic in the first cell in at least two time frames; using (903) the corresponding energy models and the predicted network traffic in at least two time frames to predict the energy savings provided by each energy-saving application for each time frame; and selecting (905) one of the energy-saving applications for use to reduce energy consumption in the cell based on the predicted energy savings. The invention also relates to a machine for managing the use of energy-saving applications for cells in the communication network and a machine-readable means.

Description

[0001] MANAGING USE OF ENERGY SAVING APPLICATIONS FOR CELLS

[0002] Technical Field

[0003] This disclosure relates to energy saving applications that are operable to reduce energy consumption in a cell of a communication network, and in particular to techniques for managing use of a plurality of energy saving applications for a cell.

[0004] Background

[0005] Mobile communication network operators across the globe are constantly expanding their network infrastructure to address the growing demand for data connectivity. The advent of new 5thGeneration (5G) network technologies and the rising number of base stations in the network is introducing new challenges to manage energy use in a cost-effective and sustainable manner. Whilst mobile operators strive to provide seamless user experience, operators also want to minimise the cost of supplying power to networks.

[0006] As the industry evolves towards Radio Access Network (RAN) virtualization, with virtual RAN or Open RAN (O-RAN), it is important to consider energy saving solutions to reduce energy carbon footprint and minimise mobile operator costs. The new architectural standardisation by the O-RAN Alliance has enabled the potential of Artificial Intelligence (Al) to be leveraged (e.g. as described in “AI / ML workflow description and requirements” by O-RAN Working Group 2; O- RAN.WG2.AIML-vO1 .03) due to a new modular design that aims to introduce virtualised network elements, openness, and intelligence to RAN management. The O-RAN architecture can unlock new potential solutions. However, considering the openness of O-RAN components, novel mechanisms to enable resource management and conflict mitigation are required. Conflict mitigation is a key component of the Service Management and Orchestration (SMO) component. This conflict mitigation challenge has been highlighted in “Understanding O-RAN: Architecture, interfaces, algorithms, security, and research challenges” by Polese, Michele, et al., IEEE Communications Surveys & Tutorials (2023).

[0007] The 5G network RAN is divided into a multitude of components that network across standardised interfaces and well-defined Application Program Interfaces (APIs). The O-RAN architecture specifies components including the concept of xApps and rApps. The O-RAN architecture and reference design of the Non-real time RAN Intelligent Controller (Non-RT RIC) and Near-real time RIC (Near-RT RIC) as a framework contains a multitude of xApps and rApps. The O-RAN architecture makes it accessible for a myriad of different xApps and rApps with different designs to work in parallel, controlling different areas, different User Equipments (UEs), and be activated / deactivated based on network conditions. A challenge arises when xApps and rApps with similar functionality (e.g. energy saving) work in parallel while controlling a cell. There is a trade-off between Quality of Service (QoS) and energy saving / cost, as noted in “Understanding O-RAN: Architecture, interfaces, algorithms, security, and research challenges” mentioned above.

[0008] Some attempts have been made to develop cost-optimal solutions for energy saving and tackle similar problems in slightly different approaches. There are several offerings for RAN software (SW) features in Long Term Evolution (LTE) RAN and New Radio (NR) RAN products for saving energy, each of which manages energy saving strategy arrangements differently, based on myriad future horizon traffic behaviour. The energy saving applications can optimise the use of RAN components in the network through predictive models. The horizon of predicted traffic behaviour may vary depending on the targeted RAN component and strategy to reduce energy.

[0009] The patent applications WO 2021 / 239238 and WO 2022 / 240320 propose a method to adjust power consumption of a telecommunications network based on a combined traffic model for traditional 4thGeneration (4G) telecom networks. However, these approaches don’t discuss leveraging combined software offerings for RAN software features. Moreover, the methods do not take O-RAN into consideration.

[0010] Summary

[0011] There are several energy saving features available in the market today, and currently the decision to activate each energy saving feature can rely on different parameters or information such as traffic prediction. In a particular situation, it may be possible for any of several energy saving features / applications to be selected and used, but the features / applications would conflict with each other if activated at the same time. Therefore, there is a need to mitigate this type of conflict.

[0012] The patent application US 2022 / 116799 proposes a method for performance prediction under O-RAN. However, the techniques in US 2022 / 116799 focus on optimising network parameters based on prediction, and does not consider dependencies and conflicts between energy saving applications such as rApps and xApps.

[0013] Another challenge is to automate the process of selection and management of energy saving applications / features. This is challenging because there are many energy saving applications / features, and they can run over different time scales and can have different constraints, e.g. different wake up times. This makes the selection process more challenging because, for example, the energy saving application / feature with the highest potential for energy saving could not be activated due to other reasons such as a higher wake up time (e.g. for instance when a high load in the network is expected shortly).

[0014] Thus, in light of the above challenges related to conflict management in O-RAN, and the diversity and independence of software features for energy saving, it is important to develop a technique to adequately address energy challenges that account for the openness and flexibility within O-RAN.

[0015] The techniques described herein aim to manage and mitigate conflicts between different energy saving applications such as xApps / rApps that aim to optimise energy saving. The techniques select a suitable, or the most suitable, energy saving application for each cell. The technique may also select the activation duration for the energy saving application for the cell. Embodiments of the techniques use a Decentralised Machine Learning Model based on hierarchical Time-Series Transformers (TSTs) to predict future traffic patterns for multiple time horizons, and then find the optimal configuration activation settings for the energy saving applications. In some embodiments, a set of energy saving applications / features that correspond to one time horizon is determined. Then, within this set, a policy can be provided that elaborates which application / feature should be activated.

[0016] In a specific embodiment of the techniques described herein, a computer implemented method, or a logical unit (orchestrator) executing such method, can be deployed and used to resolve conflicts between energy saving applications. The inputs to this unit can be the set of rApps / xApps, their dependencies (e.g. an indication that energy saving feature 1 cannot be activated at the same time as energy saving feature 2), etc. For example, the dependencies can indicate that two particular energy saving features / applications for the same RAN module may not be activated at the same time. Based on a predicted traffic load, a predicted energy saving, a time horizon over which the energy saving are being considered, and given conflicts, a suitable energy saving application / feature can be selected and activated.

[0017] According to a first aspect, there is provided a computer-implemented method for managing use of a plurality of energy saving applications for cells in a communication network. Each energy saving application is operable to reduce energy consumption of a cell in the communication network. Each energy saving application has a respective energy model relating network traffic levels to energy savings provided by the energy saving application. The method comprises, for a first cell in the communication network, predicting network traffic in the first cell for at least two time horizons; using the respective energy models and the predicted network traffic for the at least two time horizons to predict the energy savings provided by each energy saving application by each time horizon; and selecting one of the energy saving applications for use to reduce energy consumption in the cell based on the predicted energy savings. According to a second aspect, there is provided a computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method according to the first aspect or any embodiment thereof.

[0018] According to a third aspect, there is provided an apparatus configured to perform the method according to the first aspect or any embodiment thereof.

[0019] According to a fourth aspect, there is provided an apparatus comprising a processor and a memory, said memory containing instructions executable by said processor whereby said apparatus is operative to perform the method according to the first aspect or any embodiment thereof.

[0020] Certain embodiments may provide one or more of the following technical advantage(s). For example, in an O-RAN implementation, as O-RAN provides an open interface to drive innovation, energy saving rApps / xApps can evolve to produce richer and more sophisticated energy consumption decision-making process, with the techniques described herein enabling these rApps / xApps to work in harmony with each other.

[0021] Traffic Prediction models, such as Time-Series Transformers, allow reliable short-term and long-term predictions to be produced, and allow decisions to be taken with good confidence. A Time-Series Transformer modelling approach can produce better predictions than other types of modelling architectures, but the techniques are not limited to the use of Time-Series Transformers, and other prediction architectures can be used.

[0022] While prior techniques focus on adjusting parameters and the algorithms based on traffic prediction, the techniques described herein address the need for conflict mitigation between different energy saving applications / features.

[0023] The proposed method encompasses multi-domain energy saving feature selection policies. One domain can propose a policy to select applicable features depending on the time horizon, and the second domain can propose a policy to select the feature among applicable features.

[0024] Brief Description of the Drawings

[0025] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings, in which:

[0026] Fig. 1 shows an example of a communication system in which the techniques described herein can be applied;

[0027] Fig. 2 illustrates part of an O-RAN architecture including an orchestrator for managing a plurality of rApps; Fig. 3 is a flow chart illustrating a method in accordance with some embodiments;

[0028] Fig. 4 is a graph showing exemplary network traffic for one cell over a period of four days;

[0029] Fig. 5 illustrates the normalisation of multiple horizons;

[0030] Fig. 6 is a diagram illustrating the selection of an rApp / xApp according to an exemplary method;

[0031] Fig. 7 illustrates predicted amounts of energy saving for multiple energy saving applications at multiple time horizons;

[0032] Fig. 8 is a diagram illustrating an exemplary policy used to select an energy saving application;

[0033] Fig. 9 is a flow chart illustrating a method in accordance with some embodiments;

[0034] Fig. 10 is a block diagram illustrating a virtualization environment in which functions implemented by some embodiments may be virtualized; and

[0035] Fig. 11 is a simplified block diagram of an apparatus that can implement the techniques described herein.

[0036] Detailed Description

[0037] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0038] While the techniques presented herein are discussed with reference to O-RAN in a 5G / NR network, it will be appreciated that the techniques are applicable to any type of network in which multiple energy saving applications can be used, and which may conflict with each other.

[0039] Fig. 1 shows an example of a communication system 100 that the techniques described herein can be applied to. In the example, the communication system QQ100 includes a telecommunication network 102 that includes an access network 104, such as a radio access network (RAN), and a core network 106, which includes one or more core network nodes 108. The access network 104 includes one or more access network nodes, such as access network nodes 110a and 110b (which are interchangeably referred to as RAN network nodes 110 herein), or any other similar 3rdGeneration Partnership Project (3GPP) access node or non-3GPP access point (AP). Moreover, as will be appreciated by those of skill in the art, a RAN network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 102 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 102 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 102, including one or more network nodes 110 and / or core network nodes 108.

[0040] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O-CU-CP) or an O- CU user plane (O-CU-UP), a RAN intelligent controller (RIC) (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1 , F1 , W1 , E1 , E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an 0-2 interface defined by the O-RAN Alliance or comparable technologies.

[0041] The access network nodes 110 facilitate direct or indirect connection of wireless devices (also referred to interchangeably herein as user equipment (UE)), such as by connecting UEs 112a and 112b (one or more of which may be generally referred to as UEs 112) to the core network 106 over one or more wireless connections. The access network nodes 110 may be, for example, access points (APs) (e.g. radio access points), base stations (BSs) (e.g. radio base stations, Node Bs, evolved Node Bs (eNBs) and New Radio (NR) NodeBs (gNBs)).

[0042] Unless otherwise indicated, the general term ‘network node’ as used herein refers to access network nodes 110 and core network nodes 108.

[0043] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. The communication system 100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system. The wireless devices / UEs 112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with the network nodes 110 and other communication devices. Similarly, the access network nodes 110 are arranged, capable, configured, and / or operable to communicate directly or indirectly with the UEs 112 and / or with other network nodes or equipment in the telecommunication network 102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunication network 102.

[0044] In the depicted example, the core network 106 connects the access network nodes 110 to one or more hosts, such as host 116. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 106 includes one more core network nodes (e.g. core network node 108) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the wireless devices / UEs, access network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 108. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0045] The host 116 may be under the ownership or control of a service provider other than an operator or provider of the access network 104 and / or the telecommunication network 102, and may be operated by the service provider or on behalf of the service provider. The host 116 may host a variety of applications to provide one or more services. Examples of such applications include the provision of live and / or pre-recorded audio / video content, data collection services, for example, retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0046] As a whole, the communication system 100 of Fig. 1 enables connectivity between the wireless devices / UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2ndGeneration (2G), 3rdGeneration (3G), 4thGeneration (4G), 5thGeneration (5G) standards, or any applicable future generation standard (e.g. 6thGeneration (6G)); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0047] In some examples, the telecommunication network 102 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 102. For example, the telecommunications network 102 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC)ZMassive Internet of Things (loT) services to yet further UEs.

[0048] In some examples, the UEs 112 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 104. Additionally, a UE may be configured for operating in single- or multi-radio access technology (RAT) or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved- UTRA (UMTS Terrestrial Radio Access) Network) New Radio - Dual Connectivity (EN-DC).

[0049] Fig. 2 shows part of an O-RAN architecture 200 including an orchestrator 202 for managing a plurality of rApps 204 according to the techniques described herein. As described above, the O-RAN architecture 200 comprises a Non-Real Time RAN intelligent controller (RIC) 206 that is associated with the plurality of energy saving (ES) rApps 204, a Near Real Time RIC 208, an Open-Central Unit (O-CU) 210, an Open-Distributed Unit (O-DU) 212, an Open-Radio Unit (O- RU) 214 and a Cloud Infrastructure Manager 216. The orchestrator 202, rApps 204 and non-real time RIC 206 are part of a Service Management and Orchestration (SMO) component 218.

[0050] O-RAN provides an open interface for telecommunication software vendors to enable many energy saving capabilities. Many software vendors started porting energy saving in a form of rApps / xApps that can provide a richer and more sophisticated energy consumption decisionmaking process. Ericsson has already delivered two rApps for Energy Saving, namely Ericsson Radio Energy Control rApp (https: / / www.ericsson.com / 49957f / assets / local / core- network / doc / ericsson-radio-energy-control-rapp.pdf) and Ericsson Radio Energy Cockpit rApp (https: / / www.ericsson.com / 498142 / assets / local / core-network / doc / ericsson-radio-energy-cockpit- rapp.pdf). The dependencies and conflicts between the rApps 204 and / or xApps are a challenge.

[0051] The techniques described herein are not dependent on specific internal implementations for energy saving, and the solution is independent of the specific energy saving rApp or xApp, and more generally independent of the specific energy saving application.

[0052] Nevertheless, an advantageous embodiment of the techniques described herein manages and orchestrates different energy saving rApps and / or xApps. The energy saving features are located in different places, e.g. in the near real time RIC 208, the CU 210 and / or the DU 212. For instance, the energy saving application ‘Massive Multiple Input, Multiple Output (mMIMO) sleep’ is located in DU 212, while the energy saving application ‘Booster Carrier Sleep’ is located in the CU 210. As depicted in Fig. 2, A1 and 01 are interfaces that can connect between the Energy Saving Orchestrator 202 and the Energy Saving Features rApps 204 in the SMO 218 and the software features / configurations in the node.

[0053] The mMIMO Sleep Mode energy saving application reconfigures mMIMO cells, i.e. muting sub arrays, depending on the load level. The Booster Carrier Sleep energy saving application puts low loaded carriers and radios into a deep sleep mode.

[0054] Some other energy saving applications that are currently available and / or are envisaged for optimising / reducing energy consumption in a cell include:

[0055] - Micro / milli-Sleep: The transmitter (TX) reduces energy consumption by switching off component(s) (e.g. power amplifiers) when no transmission is required.

[0056] - Radio Deep Sleep: Some components of the radio are turned off for a certain duration of time depending on the load.

[0057] - MIMO Sleep Mode: MIMO cells are reconfigured, i.e. an antenna branch is muted, depending on the load level.

[0058] - Cell Sleep Mode: Traffic-controlled sleep on the capacity cells.

[0059] - Leveraging multi-band functionality by moving traffic to the most energy efficient bands.

[0060] The Orchestrator 202 may itself be in the form of an rApp. However, it may be implemented differently, and may not be located in the SMO 218. In that case, the orchestrator 202 is to communicate with the energy saving applications (e.g. rApps 204) over open interfaces such as A1 , 01 , F1-C, F1-U, etc.

[0061] Fig. 3 is a flow chart illustrating a method in accordance with some embodiments of the techniques described herein. This method can be performed by the orchestrator 202, or any other suitable function or node in a communication network. It will be noted that this exemplary method includes steps relating to the training of the model used to predict the network traffic (specifically steps 301 and 302), but it will be appreciated that the method can use a pre-trained model, and thus steps 301 and 302 are not required.

[0062] In step 301 , traffic information / data and information on the frequency of connected UE (e.g. a count of the number of UEs connected to the cell at a given time, data volume in downlink, data volume in uplink, etc.) is obtained for a plurality of cells / radio network sites (e.g. base stations / gNBs) in an operational communication network.

[0063] Information / data on the performance of the network for the UEs is also obtained in step 301. Again, the data is collected from a live / operational network. The data can consist of measurements / observations of Key Performance Indicators (KPIs) relating to the performance of each cell. Table 1 below shows an exemplary list of KPIs that can be used to measure traffic.

[0064] Table 1

[0065] In addition, information regarding the network configuration can be obtained. The network configuration information can include Configuration Management data (denoted CM). CM can include information about the physical location of the site and / or cell configuration attributes. This network configuration information is useful as the communication network consists of a set of interconnected nodes located on physical sites, where each cell in a site provides coverage in a geographical area and often is linked to neighbouring cells to facilitate handover functionalities. The density of the network, and the hardware used in each site can have an impact on network traffic.

[0066] In step 302, the information collected in step 301 is used to train a model to predict network traffic at one or more future time horizons. Telecommunication network traffic prediction is the process of forecasting traffic in the future based on historical patterns. For instance, given the past predefined number of hours of traffic (history), the task is to forecast the future traffic for another pre-defined time period or time point (referred to as the “time horizon” or simply “horizon”). In this disclosure, a set of horizons MH comprising at least two time horizons is considered which represents different future times.

[0067] The goal of the model is to find a short time or long time when the traffic is low. The low traffic period, in this context, refers to the period of time during the day when a site is exposed to a minimal number of requests or traffic. A low traffic period can be related to the location of the site (e.g. a site that is located ‘downtown’ or in tourist places can have different peak hours and non-peak hours to those located in business districts).

[0068] Briefly, the information collected in step 301 is formed into a dataset that includes historical traffic time-series data and known values, and this is divided into a training dataset and a test dataset that are used to train the model to estimate traffic. The output of the trained model is an estimated traffic value, and the value can be a positive value. The model is a machine learning (ML) model that is trained to predict traffic based on historical traffic data. The ML model may be a Time-series Transformers (TST) model; a Long Short-Term Memory (LSTM) architecture; a Traffic Prediction Machine Learning, TPML, Model; a Convolutional Neural Network, CNN; or any other suitable type of model.

[0069] The graph in Fig. 4 shows exemplary measured network traffic levels in one cell over a period of four days. In Fig. 4 the y-axis represents the values of the traffic PM counter, and the x-axis is the relative time-period. Data such as that shown in Fig. 4 is used to train the model, and the aim of the trained model is to be able to predict traffic levels up to at least two defined time horizons, e.g. one of which is shown by the line in the section labelled 401 in Fig. 4.

[0070] In order to identify a low traffic period, the model (e.g. a Time-Series Transformer (TST) model) is used to estimate traffic in the long time horizon and short time horizon. A threshold expressed as a percentage of the amount of traffic at the highest level, e.g. 0.01%, can be used to find the level of low traffic (denoted as “low traffic level”).

[0071] To test the usefulness of a TST model for the purpose described herein, a TST model and a Long Short Term Memory (LSTM) model was trained using data from an operational network that spans a period of seven months. The models were trained on the same features described herein. The LSTM was as described in the paper “Long short-term memory” by Schmidhuber, Jurgen, and Sepp Hochreiter, Neural Comput 9.8 (1997): 1735-1780, and the TST model was as described in the paper “Transformers in Time Series: A Survey” by Qingsong Wen et al., https: / / arxiv.org / abs / 2202.07125.

[0072] Time-Series Transformers (TSTs) are transformer-based models that have been specifically adapted to tackle time-series problems. They make three key network modifications to a standard transformer in order to better exploit the unique properties of time-series data. Namely, they employ:

[0073] 1. An enhanced positional encoding scheme which leverages the timestamp information to extract a global representation of each time-step’s position within the time-series.

[0074] 2. An efficient attention mechanism, designed to model long-term dependencies in timeseries data.

[0075] 3. A deep decomposition architecture, which uses series-decomposition sub-modules to model / predict both the trend and seasonality components of the time-series separately.

[0076] Empirical experiments showed that the TST outperformed the other models, including the LSTM, particularly when it comes to predicting longer horizons, as shown by Tables 2 and 3 below, which were compared to live network data.

[0077] Table 2 - Traffic Prediction Results - long horizon in downtown area

[0078] Table 3: Traffic Prediction Results - short horizon in suburban area

[0079] Techniques for training a TST model to predict network traffic levels are known to those skilled in the art, and further details are not provided herein.

[0080] Energy saving applications / features have different activation times (i.e. how long the energy saving feature is activated for), deactivation times and different sleep durations (some will be of the order of milliseconds, while some will be of the order of minutes), which can affect both the short term and long term energy saving performance. Therefore, in step 303 of Fig. 3, traffic prediction for multiple time horizons is performed for a site (e.g. a cell) in the network using the trained TST Model. That is, a traffic prediction is generated for a cell for each of multiple time horizons, e.g. 1 second, 1 hour, 12 hours, 24 hours, etc.

[0081] In some embodiments the number of horizons is two (effectively a ‘short’ / ’shorter’ horizon and a ‘long’ / ’longer’ horizon). In other embodiments more than two horizons can be used and the traffic predicted for each of those horizons. However, having multiple (i.e. more than 2) and asynchronous (i.e. different) horizons for each energy saving feature is very costly (as there is a cost attached to machine learning (ML) model lifecycle management (i.e. training, model storage, inference, etc)). A high number of horizons may therefore create scalability issues when a large number of different energy saving applications are to be considered / evaluated. Preferably, the same set of time horizons is used for each of the energy saving applications being evaluated.

[0082] As the energy saving applications can have different horizons to each other (i.e. different sleep durations), in some embodiments an intermediate step (i.e. prior to step 304) can be performed to project the time horizon to each energy saving application horizon. The time interval to use as a common horizon is a configurable parameter. This normalisation of multiple horizons is illustrated in Fig. 5. Fig. 5 shows how a default, relatively long, horizon for an Energy Saving Application 1 (ES1) is projected to a ‘short term’ time horizon TO. Likewise, Fig. 5 shows how a default, relatively short, horizon for an Energy Saving Application 2 (ES2) is projected to a ‘long term’ time horizon T1.

[0083] In step 304 of Fig. 3, an appropriate / suitable energy saving application is selected for use in the cell based on the outputs of the TST model. To select an energy saving application, in step 304 an energy model (that models the energy saving provided by the associated energy saving application) is evaluated at each time horizon to predict the energy savings provided by the respective energy saving application at each time horizon. One of the energy saving applications can then be selected for use in step 304.

[0084] In some embodiments, as described further below, the selection of the energy saving application in step 304 can be according to a policy or rule. A policy or rule aims to manage the conflict between energy saving applications and also benefit from better energy saving performance with a lower risk of affecting user experience. In some embodiments, the energy saving applications / features (both in xApps and rApps) can be categorised into short term or long term energy saving.

[0085] A policy or rule can be used to selectively activate an energy saving application according to (1) an energy saving application’s recommended configuration, and (2) a prediction of traffic for multiple horizons. Fig. 7 illustrates the process of selecting an energy saving application according to a policy according to some embodiments. The selection policy in these embodiments can be used to configure what energy saving application to use when there is predicted to be low traffic for a short time (the shorter time horizon) or for a long time (the longer time horizon). In Fig. 6 the traffic prediction model 601 (e.g. the TST model) outputs a traffic level prediction for at least two time horizons. These predictions are shown in blocks 602 and 603 respectively. A selection policy block 604 receives the predictions, along with information 605 on the recommended configurations for the available energy saving applications. The use of the selection policy 604 results in an energy saving application being identified and this is activated at block 606.

[0086] Thus at block 604, the orchestrator 202 should decide which of the energy saving features is to be selected. As noted above, each energy saving application has its own energy model that can model or predict the energy savings that use of the application can provide. Different models can have different inputs, but each makes use of the predicted traffic level, and each outputs an indication / prediction of the energy savings. It will be appreciated that the energy model can provide the output in terms of an amount of energy saved by using the application, or it can provide the output in terms of the amount of energy consumed when the application is being used (which indirectly indicates the energy that would be saved when compared to the energy consumed without using the application). The energy models can be data-driven or analytical.

[0087] Thus, the energy models provide the estimated / predicted energy savings (or energy consumption) for each time horizon for each energy saving feature.

[0088] With reference to Fig. 7, it is assumed that there are F energy saving features / applications (labelled ES 1 to ES F), and L time horizons. Each entry in Fig. 7 shows the amount of predicted energy saving forthat energy saving application and that time horizon. A higher number indicates high energy savings, and it can be seen that at different time horizons different energy saving features can be superior to others. For example, ES 1 provides the highest energy saving for time horizon 1 , but for time horizon L energy saving application ES F provides the highest energy savings out of the available energy saving applications.

[0089] Based on the output of the energy models, a ‘best’ energy saving application / feature is selected according to the policy or rule. One example policy is to check the best energy saving application / feature per time horizon, and select the energy saving application / feature that appears the most. This result in selecting the energy saving application / feature that is more energy efficient over more horizons. In case it is not possible to select an energy saving application using this policy, other criteria and / or priorities can be added. For example, short-term energy savings can be prioritised, in which case the energy saving application providing the highest energy savings at shorter time horizon(s) is selected. This policy is beneficial as it allows to benefit from better energy saving for this shorter time horizon, and predicted energy savings can be reevaluated for a subsequent time horizon, where it can be decided whether to continue with that feature or switch to another one. Another example policy is to give a score to each energy saving feature based on the weighted sum up of energy saving across different horizons and select the energy saving feature with the best score. The weight can be proportional to the confidence level of the traffic level prediction. The higher the confidence in the traffic prediction for that time horizon, the higher the weight applied to the energy savings at that horizon.

[0090] As another example, also based on Fig. 7, consider there to be F energy saving features that are split into two categories, one category of energy saving features that are designed for short term energy saving (this category is referred to as ST), and another category of energy saving features that are designed for long term energy saving (this category is referred to as LT). In Fig. 7, ES1 can be considered as providing long-term energy savings, and ES2 can be considered as providing short-term energy savings. In this example the policy uses the result of the traffic prediction, and finds the longest consecutive energy saving traffic prediction that is above a threshold for an amount of energy saved (that can be defined), and select the energy saving feature accordingly. In this example the algorithm can consider the weighted sum of the predicted traffic (i.e. weighted according to the confidence of the prediction) since the scale of time horizons are different.

[0091] It will be appreciated that a network operator can optimise or influence the selection of the energy saving application to use, for example by the operator providing a ranking that prioritises the selection of energy saving applications based on external criteria (e.g. regulations, service quality, etc).

[0092] Finally, once the energy saving application is selected in step 304, in step 305 of Fig. 3 the selected energy saving application is activated.

[0093] The following example, which refers to Fig. 8, illustrates how to manage activation of energy saving features for two time horizons, Horizon 1 and Horizon 2. Horizon 1 is shorter (closer) than Horizon 2. A short-term traffic prediction for Horizon 1 is determined (block 801). This traffic prediction is evaluated in block 802. Subsequently, the traffic prediction for Horizon 2 is determined and evaluated in block 803 (if the predicted traffic at Horizon 1 is low) or evaluated in block 804 (if the predicted traffic at Horizon 1 is high). In blocks 803 and 804 it is determined whether the predicted traffic at Horizon 2 is high or low.

[0094] If the forecasted / predicted network traffic for Horizon 1 and Horizon 2 is identified to be low (e.g. zero, or below a certain threshold), deep sleep energy features can be activated (block 805). Such features can reduce energy by up to 70%.

[0095] If the forecasted traffic for Horizon 2 is identified to be low and traffic at Horizon 1 to be high, the cell may be exposed to a temporarily high load (e.g., when a train full of users passes a rural area, it can lead to spiky or burst traffic pattern). In this case, a short-term energy saving application can be used to reduce the energy consumption.

[0096] If the forecasted traffic for Horizon 2 is identified to be high and Horizon 1 to be low, the site can benefit from short-term energy saving, and an energy saving application can be activated that provides energy saving in the short term.

[0097] If the forecasted traffic for both Horizon 1 and Horizon 2 prediction is identified to be high, use of an energy saving application may not be appropriate, and a separate component can be used to check whether neighbouring cells are down or in a deep sleep mode. Such scenarios usually occur when a cell is exposed to high traffic, or when traffic from neighbouring cells (that are down) offloads to the cell. In this state, a load balancing policy can be applied across multiple cells, although the cell can still benefit from short duration sleeping (micro level sleeping).

[0098] Once the choice of short / long-term energy saving is determined in Fig. 8, the aforementioned policy can be evaluated to select the energy saving feature within the chosen category.

[0099] Fig. 9 is a flow chart illustrating a method for managing use of a plurality of energy saving applications for cells in a communication network according to various embodiments. This method can be performed by an apparatus such as orchestrator 202, or any other suitable node in a communication network. The orchestrator 202 or other node may perform the method in response to executing suitably formulated computer readable code. The computer readable code may be embodied or stored on a computer readable medium, such as a memory chip, optical disc, or other storage medium. The computer readable medium may be part of a computer program product.

[0100] The energy saving applications are operable to reduce energy consumption of a cell in the communication network, and each energy saving application has a respective energy model relating network traffic levels to energy savings provided by the energy saving application.

[0101] Of the plurality of energy saving applications, at least one may be for use by a RIC in an O- RAN architecture. A particular energy saving application may be for use by a Non-RT RIC or a Near-RT RIC. Of the plurality of energy saving applications, at least one energy saving application is one of an rApp or an xApp. Of the plurality of energy saving applications, at least one energy saving application is for use in one of a DU or CU.

[0102] The method described below is applied to or for a first cell in the communication network.

[0103] In step 901 , network traffic in the first cell for at least two time horizons is predicted. The network traffic may be predicted using a ML model. The model may have been trained using historical data on network traffic levels. The model can be any of a TST model, a TPML Model, a LSTM model, a CNN, or any other suitable type of model. In some embodiments, in predicting the network traffic, the model further takes account of the configuration of the first cell and / or the configuration of the communication network.

[0104] In step 903, the respective energy models and the predicted network traffic for the at least two time horizons are used to predict the energy savings provided by each energy saving application by each time horizon.

[0105] In step 905, one of the energy saving applications is selected for use in the cell based on the predicted energy savings.

[0106] The method can further comprise using the selected energy saving application in the first cell. That is, the operations associated with the selected energy saving application are used or activated in the cell. For example, if the selected energy saving application is the Booster Carrier Sleep energy saving application, low loaded carriers and radios in the first cell are put into a deep sleep mode.

[0107] Step 905 can comprise selecting the energy saving application that provides higher or the highest energy saving in the shorter one of the at least two time horizons, or higher or the highest energy saving in the longer one of the at least two time horizons. Whether energy saving in the shorter or longer horizons is prioritised can depend on a policy.

[0108] Step 905 can comprise forming a score for each energy saving application based on the predicted energy saving by each time horizon. The energy saving application with the best score can be selected. The score for each energy saving application may be a weighted sum of the predicted energy saving by each time horizon, with the weighting being based on a confidence level in the predicted energy saving by each time horizon.

[0109] Step 905 may also take into account whether any neighbouring cells of the first cell are using an energy saving application.

[0110] Fig. 10 is a block diagram illustrating a virtualization environment 1000 in which functions implemented by some embodiments may be virtualized. In particular virtualization environment 1000 can be used to implement the functions / method described herein with respect to orchestrator 202.

[0111] In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1000 hosted by one or more of hardware nodes, such as a hardware computing device that operates as an access network node, a wireless device / UE, a core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g. a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 1100 includes components defined by the Open-RAN (O-RAN) Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an 0-2 interface.

[0112] Applications 1002 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 1000 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0113] Hardware 1004 includes processing circuitry, memory that stores software and / or instructions executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1006 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1008a and 1008b (one or more of which may be generally referred to as VMs 1008), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1006 may present a virtual operating platform that appears like networking hardware to the VMs 1008.

[0114] The VMs 1008 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1006. Different embodiments of the instance of a virtual appliance 1002 may be implemented on one or more of VMs 1008, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0115] In the context of NFV, a VM 1008 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1008, and that part of hardware 1004 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1008 on top of the hardware 1004 and corresponds to the application 1002.

[0116] Hardware 1004 may be implemented in a standalone network node with generic or specific components. Hardware 1004 may implement some functions via virtualization. Alternatively, hardware 1004 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1010, which, among others, oversees lifecycle management of applications 1002. In some embodiments, hardware 1004 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signalling can be provided with the use of a control system 1012 which may alternatively be used for communication between hardware nodes and radio units.

[0117] Fig. 11 is a simplified block diagram of an apparatus 1100 according to some embodiments that can be used to implement one or more of the techniques described herein. The apparatus

[0118] 1100 may be an orchestrator 200, part of an O-RAN architecture, part of a non-O-RAN architecture, or part of a core network of the communication network, and may be configured to operate according to the methods described above and shown in the preceding figures.

[0119] The apparatus 1100 comprises processing circuitry (or logic) 1101. It will be appreciated that the apparatus 1100 may comprise one or more virtual machines running different software and / or processes. The apparatus 1100 may therefore comprise, or be implemented in or as one or more servers, switches and / or storage devices and / or may comprise cloud computing infrastructure that runs the software and / or processes.

[0120] The processing circuitry 1101 controls the operation of the apparatus 1100 to implement the relevant part of the methods described herein. The processing circuitry 1101 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the apparatus 1100 in the manner described herein. In particular implementations, the processing circuitry 1101 can comprise a plurality of software and / or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the apparatus 1100.

[0121] The apparatus 1100 also comprises a communications interface 1102. The communications interface 1102 is for use in enabling communications with one or more of: RICs, O-RAN apparatus, non-O-RAN apparatus, core network nodes, computers, servers, etc. The communications interface 1102 can use any suitable communication technology for the type of communications to be performed.

[0122] The processing circuitry 1101 may be configured to control the communications interface

[0123] 1102 to transmit to and / or receive from RICs, O-RAN apparatus, non-O-RAN apparatus, core network nodes, computers, servers, etc., requests, acknowledgements, information, data, signals, or similar, according to the methods described herein.

[0124] The apparatus 1100 may comprise a memory 1103. In some embodiments, the memory

[0125] 1103 can be configured to store program code that can be executed by the processing circuitry

[0126] 1101 to perform the methods described herein in relation to the apparatus 1100. Alternatively or in addition, the memory 1103 can be configured to store any requests, acknowledgements, information, data, signals, or similar that are described herein. The processing circuitry 1101 may be configured to control the memory 1103 to store such information therein.

[0127] Although the computing devices described herein (e.g. UEs, RAN network nodes, core network node, orchestrator 202, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0128] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device- readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0129] The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the scope of the disclosure. Various exemplary embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.

Claims

Claims1. A computer-implemented method for managing use of a plurality of energy saving applications for cells in a communication network, wherein each energy saving application is operable to reduce energy consumption of a cell in the communication network, and wherein each energy saving application has a respective energy model relating network traffic levels to energy savings provided by the energy saving application; the method comprising, for a first cell in the communication network: predicting (901) network traffic in the first cell for at least two time horizons; using (903) the respective energy models and the predicted network traffic for the at least two time horizons to predict the energy savings provided by each energy saving application by each time horizon; and selecting (905) one of the energy saving applications for use to reduce energy consumption in the cell based on the predicted energy savings.

2. A method as claimed in claim 1 , wherein the method further comprises: using the selected energy saving application in the first cell.

3. A method as claimed in claim 1 or 2, wherein the step of selecting (905) comprises selecting the energy saving application that provides: higher energy saving in the shorter one of the at least two time horizons; or higher energy saving in the longer one of the at least two time horizons.

4. A method as claimed in any of claims 1-3, wherein the step of selecting (905) comprises forming a score for each energy saving application based on the predicted energy saving by each time horizon, and selecting the energy saving application to use as the energy saving application with the best score.

5. A method as claimed in claim 4, wherein the score for each energy saving application is a weighted sum of the predicted energy saving by each time horizon, wherein the weighting is based on a confidence level in the predicted energy saving by each time horizon.

6. A method as claimed in any of claims 1-5, wherein the step of selecting (905) is further based on whether one or more neighbouring cells of the first cell are using an energy saving application.

7. A method as claimed in any of claims 1-6, wherein the step of predicting network traffic comprises using a machine learning model.

8. A method as claimed in claim 7, wherein the machine learning model is trained using historical network traffic levels.

9. A method as claimed in claim 7 or 8, wherein the model is any of: a time-series transformer, TST, model; a Traffic Prediction Machine Learning, TPML, Model, a Long Short Term Memory, LSTM, model; a Convolutional Neural Network, CNN.

10. A method as claimed in any of claims 7-9, wherein the model further takes account of the configuration of the first cell and / or the configuration of the communication network.

11. A method as claimed in any of claims 1-10, wherein the energy saving applications are for use by a Radio Intelligent Controller, RIC, in an Open-Radio Access Network, O-RAN, architecture.

12. A method as claimed in claim 11 , wherein each energy saving application is for use in a non-real time, Non-RT, RIC or a Near real time, Near-RT, RIC.

13. A method as claimed in any of claims 1-12, wherein each energy saving application is an rApp or an xApp.

14. A method as claimed in any of claims 1-13, wherein each energy saving application is used in one of a distributed unit, DU, or a central unit, CU, in a Radio Access Network, RAN, node.

15. A computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of claims 1-14.

16. An apparatus (1100) configured to perform the method according to any of claims 1-14.

17. An apparatus comprising a processor and a memory, said memory containing instructions executable by said processor whereby said apparatus is operative to perform the method according to any of claims 1-14.

Images