Method and access network node

Abstract

The present disclosure relates a method performed by a first access network node, the method comprising transmitting, to a second access network node, information for network energy saving (NES) configuration at the first access network node, wherein the information for the NES configuration is used by the second access network node for cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration or handover configuration at the second access network node.

Description

METHOD AND ACCESS NETWORK NODE

[0001] The present disclosure relates to a communication system.

[0002] The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (including Long Term Evolution (LTE)-Advanced, Next Generation or 5G networks, future generations, and beyond). The disclosure has particular, although not necessarily exclusive, relevance to providing for the exchange of appropriate information between nodes of different radio access networks, and / or different nodes of the same radio access network, in the context of network energy saving (NES) enhancements such as cell discontinuous reception (DRX) and cell discontinuous transmission (DTX) and the provision of on-demand SIB1 for UEs in idle / inactive mode.

[0003] Earlier developments of the 3GPP standards were referred to as the Long-Term Evolution (LTE) of Evolved Packet Core (EPC) network and Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), also commonly referred as '4G'. More recently, the term '5G' and 'new radio' (NR) is used to refer to an evolving communication technology that supports a variety of applications and services. Various details of 5G networks are described in, for example, the 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, which document is available from https: / / www.ngmn.org / 5g-white-paper.html. 3GPP intends to support 5G by way of the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and the 3GPP NextGen core network.

[0004] Under the 3GPP standards, a NodeB (or an eNB in LTE, and gNB in 5G) is the radio access network (RAN) node (or simply 'access node', 'access network node' or 'base station') via which communication devices (user equipments or 'UEs') connect to a core network and communicate with other communication devices or remote servers. For simplicity, the present application may use the term access network node, RAN node (or simply RAN) or base station to refer to any such access nodes.

[0005] For simplicity, the present application will use the term mobile device, user device, or UE, to refer to any communication device that is able to connect to the core network via one or more base stations. Although the present application may refer to mobile devices in the description, it will be appreciated that the technology described can be implemented on any communication devices (mobile and / or generally stationary) that can connect to a communication system for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0006] In the current 5G architecture, the RAN architecture may be distributed with the base station structure split into two or more parts. In some RAN implementations there are two parts, known as the Central Unit (CU or gNB-CU) - sometimes referred to as a 'control unit' - and the Distributed Unit (DU or gNB-DU), connected by an F1 interface. This enables the use of a 'split' architecture in which the typically 'higher' CU layers (for example, but not necessarily or exclusively, Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) layers) and the, 'lower' DU layers (for example, but not necessarily or exclusively, Radio Link Control (RLC), Media (sometimes referred to as 'Medium') Access Control (MAC), and Physical (PHY) layers) are separated between a particular CU, and one or more DUs that are connected to and controlled by that CU via the F1 interface. Thus, for example, the higher layer CU functionality for a number of base stations may be implemented centrally (for example, by a single processing unit, or in a cloud-based or virtualised system), whilst retaining the lower layer DU functionality locally separately for each base station.

[0007] In more recently proposed RAN distributed architectures, in addition to the CU and DU, the concept of a Radio Unit (RU) - sometimes referred to as a 'remote unit' - has been introduced. In this architecture the RU is responsible for handling the digital front end (DFE), digital beamforming functionality and, typically, the functionality of the lower parts of the PHY layer, whilst the DU typically handles the higher parts of the PHY layer and the RLC and MAC layers. The CU in this architecture continues to be responsible for controlling one or more DUs (each DU corresponding to a different respective gNB) and to handle higher layer signalling (typically RRC and PDCP layers).

[0008] The actual functional split between the CU and DUs (and potentially RUs where applicable) of these distributed architectures is flexible allowing the functionality to be optimised for different use cases. Effectively, the split architecture enables a 5G network to use a different distribution of protocol stacks between CU and DUs (and potentially RUs) depending on, for example, midhaul availability and network design.

[0009] In 5G, core network entities comprise logical nodes (or 'functions') including control plane functions (CPFs) and one or more user plane functions (UPFs). The CPFs include, amongst other things, one or more Access and Mobility Management Functions (AMFs), a session management function (SMF), an Authentication Server Function (AUSF), a Unified Data Management (UDM) entity for managing user specific data, a Policy Control Function (PCF), an Application Function (AF), a Security Anchor Function (SEAF), an Authentication credential Repository and Processing Function (ARPF), and / or the like. The AMF generally corresponds to the mobility management entity (MME) in 4G and performs many of the functions performed by the MME. Each UPF combines functionality of both the S-GW and P-GW - specifically user plane functionality of the S-GW (SGW-U) and user plane functionality of the P-GW (PGW-U). The SMF provides session management functionality (that formed part of MME functionality in 4G). The SMF also combines the some of the functionality provided by the S-GW and P-GW - specifically control plane functionality of the S-GW (SGW-C) and control plane functionality of the P-GW (PGW-C). The SMF also allocates IP addresses to each UE.

[0010] As cellular communication systems evolve, there is an increasing need for wireless communication networks having improved energy efficiency. This need is being driven, for example, by the fact that 5G (and beyond) communication systems are becoming more pervasive across industries and geographical areas, handling more advanced services and applications requiring very high data rates. Moreover, networks are becoming denser, use more antennas, larger bandwidths, and more frequency bands.

[0011] A reduction in the amount of energy needed to operate a communication network beneficially reduces both the operational expenditure or (OPEX), and the environmental impact, of operating the system. Moreover, for battery-powered devices (for example, a UE) reduced power consumption extends the battery life of the device. However, more recent developments of cellular communication systems (for example to implement wide channel bandwidths, to enable operations at significantly higher frequencies than previously, to provide improved capacity, and the like) tend to increase, rather than reduce, power demand and thus present significant challenges when it comes to energy saving.

[0012] In this context, a number of network energy saving (NES) techniques are typically implemented in cellular communication systems, and improvements to those NES techniques and completely new techniques are being developed. The NES techniques being considered include time, frequency, spatial, and power domain adaptation techniques.

[0013] One method of achieving energy savings in a cellular communication system is to reduce the energy requirements associated with communication between a UE and an associated RAN node. The energy consumption arising from such communication includes a dynamic part that is associated with data transmission and reception, and a static part that is associated with operations of the UE, and the RAN node, that are performed even when there is no ongoing data transmission or reception. The static part may include, for example, the power required to operate a UE in a mode in which the UE is able to receive and decode a physical downlink control channel (PDCCH) transmitted by a RAN node.

[0014] Energy saving modes may be configured for one or more devices in the system (e.g., a UE). For example, a UE may be configured to operate in an energy saving mode (which may also be referred to as a sleep mode) in which the UE performs a reduced number of transmissions, or in which the UE is configured not to attempt to transmit and / or to receive signals during a particular time period. Such operation is commonly referred to as DRX / DTX which stands for Discontinuous Reception (DRX) and Discontinuous Transmission (DTX). DRX for a UE includes idle mode DRX and connected mode DRX (C-DRX). In idle mode DRX, the UE periodically wakes up to monitor for paging messages and goes back to a sleep mode if paging message is not intended for it. In C-DRX, the UE powers down most of its circuitry when there are no packets to be received or transmitted. During this time, the UE nevertheless still monitors for a physical downlink control channel (PDCCH) occasionally during a DRX 'active' state, or DRX 'ON' period. The time during which UE does not monitor the PDCCH is often called a DRX 'sleep' or 'inactive' state, or DRX 'OFF' period.

[0015] NPL 1: The 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, available from https: / / www.ngmn.org / 5g-white-paper.html.

[0016] However, most of the energy consumption (and associated OPEX), comes from the radio access network. In view of this, therefore, there remains an ongoing need to develop techniques for achieving more efficient operation (dynamically and / or semi-statically) at the RAN side, and potentially adaptation of transmissions and / or receptions for NES in time, frequency, spatial, and / or power domains with a finer granularity than is currently possible.

[0017] One NES technique that is being developed to help address this involves discontinuous operation of the cell or cells provided by a RAN node in a similar manner to DTX / DRX at the UE. This is often referred to as 'cell DTX / DRX'. With cell DTX / DRX, the RAN node operating a cell stops transmitting and receiving in that cell during certain periods of time. The UEs that are served by the cell may be provided with information that allows them to determine when the RAN node is in an active or 'ON' state (and is therefore able to communicate with the UE) and when it is in an inactive or 'OFF' state (and is therefore not able to communicate with the UE).

[0018] Currently, cell DTX / DRX is applied to at least UEs in an RRC connected state. A periodic cell DTX / DRX pattern (i.e., active and non-active periods) for Cell DTX / DRX is typically configured by a RAN node using UE specific RRC signalling in a serving cell. The pattern configuration for cell DTX / DRX is, nevertheless, common for the UEs configured with the cell DTX / DRX functionality in the cell. A cell DTX / DRX configuration typically defines a periodicity, start slot / offset, on duration, and a configuration type (i.e., whether the configuration applies to cell DTX only, cell DRX only, or cell DTX and cell DRX jointly). An activation status for cell DTX / DRX indicates whether the UE shall activate the configuration according to the received parameters. The Cell DTX / DRX mode may, for example, be activated / de-activated via dynamic layer 1 (L1) / layer 2 (L2) signalling and / or UE-specific RRC signalling.

[0019] Previous NES development has also focused, primarily, on NES enhancements aimed at reducing energy associated with connected mode UEs during a low cell load scenario. These enhancements deliberately avoided any impact on idle or legacy UE operation and focused on reducing energy associated with user specific signals and channels. However, this focus has limited the NES gains that are potentially achievable, especially in the RAN.

[0020] More recently, therefore, a number of procedures have been developed to reduce the amount of energy expenditure associated with idle / inactive mode UEs selecting, camping on, and / or reselecting cells. Much of the energy expenditure associated with these procedures arises from the transmission, reception, and processing of the minimum system information that a RAN node periodically sends to provide a UE with the parameters required for initial access to the cell and acquisition of any other system information.

[0021] Part of the minimum system information is carried by synchronisation signal / physical broadcast channel (PBCH) blocks (SSBs) which are periodically in the cells of the communication system. Each SSB includes both synchronisation signals (SSs) - e.g., a primary synchronisation signal (PSS) and a secondary synchronisation signal (SSS) - and the PBCH. SSBs are, therefore, sometimes referred to as an 'SS / PBCH blocks'. The PBCH in the SSB carries a master information block (MIB) that provides an initial part of the minimum system information. The MIB typically includes, for example, information identifying whether the cell is or is not barred for access, and information allowing subsequent acquisition of the remaining minimum system information (carried by system information block 1 (SIB1)). The minimum system information carried by the MIB and SIB1 effectively provides the UE with the parameters required for initial access to the cell and acquisition of any other system information.

[0022] To help reduce energy expenditure associated with the transmission, reception, and processing of the minimum system information, therefore, techniques / procedures are being developed to avoid unnecessary SSB and / or SIB1 transmission. By way of example, such techniques / procedures may include: - The application of 'SSB-less' or 'SIB1-less' operation in certain 'non-anchor' cells, which involves not transmitting SSBs or SIB1s in those cells. Instead, a UE may rely on an SSB or SIB1 transmission in a different 'anchor' cell for acquiring synchronisation and / or minimum (or remaining minimum) system information. - The use of on-demand transmission, rather than automatic (periodic) transmission, of SSBs for camping onto certain cells (e.g., secondary cells (SCells) and / or non-serving cells) by UEs configured to connect to, and use, such cells; and - The use of on-demand transmission, rather than automatic (periodic) transmission, of system information block 1 (SIB1) for certain cells in which a UE is able to retrieve the system information carried by SIB1 by sending an uplink wake-up signal (WUS) to a corresponding RAN node and can perform synchronization based on another cell in which SIB1 is transmitted.

[0023] Moreover, a number of different possible NES modes of operation have been considered for RAN nodes. The possible NES modes may include, for example, simple 'on' or 'off' states. Nevertheless, the possible NES modes may include different predefined energy / power consumption states for the RAN node including: a number of different 'sleep' states in which the RAN node is at least partially off / not fully on but may perform certain operations. These sleep states may be characterised by different relative power levels, for example: 'deep' sleep (lowest power); 'light' sleep (higher power relative to deep sleep); and micro sleep (higher power relative to both deep and light sleep). Moreover, the possible NES modes may include an active uplink state and an active downlink state in which the RAN node is respectively 'on' for communication in the uplink direction only, or for communication in the downlink direction only.

[0024] Currently, the consensus is that coordination of cell DTX / DRX between RAN nodes should not be supported because of concerns that the required exchange of information could lead to frequent changes in activation status and, consequently, high signalling overhead between nodes. Similarly, procedures have not been developed for supporting any coordination RAN nodes in respect of any on-demand transmission of minimum system information (e.g., SIB1) or the NES operational modes that may be employed at those RAN nodes, for example, by exchanging information on the WUS configuration and / or NES mode.

[0025] Nevertheless, the lack of knowledge at a first RAN node of NES related (e.g., cell DTX / DRX) configuration information for a cell of a neighbouring RAN node has the potential to lead to non-optimal configuration of a corresponding NES related (e.g., cell DTX / DRX) configuration for a cell of the first RAN node, and / or non-optimal configuration for handover of a UE from a cell of the first RAN node. The lack of efficient procedures for the exchange of NES related configuration information therefore has the potential to impact overall network performance.

[0026] The disclosure aims to provide one or more apparatus and / or one or more associated methods that overcomes or at least partially ameliorates the above issues.

[0027] The various functional means described below that are part of the UE may be provided by a memory and one or more processors that execute instructions stored in the memory. Similarly, the various functional means described below that are part of the access network node may be provided by a memory and one or more processors that execute instructions stored in the memory.

[0028] Various example described below may be implemented by means of a computer program product comprising computer implementable instructions for causing a programmable computer to carry out the any of the methods described below. The computer implementable instructions may be provided as a signal or on a tangible computer readable medium.

[0029] The disclosure has a method performed by a first access network node, the method comprising transmitting, to a second access network node, information for network energy saving (NES) configuration at the first access network node, wherein the information for the NES configuration is used by the second access network node for cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration or handover configuration at the second access network node.

[0030] The disclosure has a method performed by a second access network node, the method comprising receiving, from a first access network node, information for network energy saving (NES) configuration at the first access network node; and determining for cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration or handover configuration at the second access network node using the information for the NES configuration.

[0031] The disclosure has a first access network node comprising means for transmitting, to a second access network node, information for network energy saving (NES) configuration at the first access network node, wherein the information for the NES configuration is used by the second access network node for cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration or handover configuration at the second access network node.

[0032] The disclosure has a second access network node, the method comprising means for receiving, from a first access network node, information for network energy saving (NES) configuration at the first access network node; and means for determining for cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration or handover configuration at the second access network node using the information for the NES configuration.

[0033] Example embodiments of the disclosure will now be described, by way of example, with reference to the accompanying drawings in which:

[0034] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') telecommunication system;Fig. 2 illustrates a typical frame structure that may be used in the communication system of Fig. 1;Fig. 3 illustrates a functional framework for artificial intelligence (AI) / machine learning (ML) (AI / ML) models, and how various entities of the framework may interact with one another, that may be implemented in the communication system of Fig. 1;Fig. 4 schematically illustrates of a method of training an AI / ML model, and of monitoring the performance of the AI / ML model, that may be implemented in the communication system of Fig. 1;Fig. 5 illustrates an Abstract Syntax Notation One (ASN.1) representation of a possible implementation of an information element that may be used for configuring a WUS in the communication system of Fig. 1;Fig. 6 illustrates an example of a DRX / DTX cycle or pattern that may be used in the communication system of Fig. 1;Fig. 7 illustrates an Abstract Syntax Notation One (ASN.1) representation of a possible implementation of an information element that may be used for configuring cell DTX / DRX related parameters in the communication system of Fig. 1;Fig. 8 is a simplified sequence diagram illustrating different inter-node information exchange procedures for cell DTX / DRX configuration information that may be implemented in the communication system of Fig. 1;Fig. 9 is a simplified sequence diagram illustrating an inter-node information exchange procedure for cell DTX / DRX activation status related information that may be implemented in the communication system of Fig. 1;Fig. 10 is a simplified sequence diagram illustrating different intra-RAN, inter-node, information exchange procedures for cell DTX / DRX configuration information that may be implemented in the communication system of Fig. 1;Fig. 11 is a simplified sequence diagram illustrating an intra-RAN, inter-node, information exchange procedure for cell DTX / DRX activation status related information that may be implemented in the communication system of Fig. 1;Fig. 12 is a simplified sequence diagram illustrating different master RAN node led inter-node information exchange procedures for cell DTX / DRX configuration information that may be implemented, in the context of dual connectivity, in the communication system of Fig. 1;Fig. 13 is a simplified sequence diagram illustrating a master RAN node led inter-node information exchange procedure for cell DTX / DRX activation status related information that may be implemented, in the context of dual connectivity, in the communication system of Fig. 1;Fig. 14 is a simplified sequence diagram illustrating different secondary RAN node led inter-node information exchange procedures for cell DTX / DRX configuration information that may be implemented, in the context of dual connectivity, in the communication system of Fig. 1;Fig. 15 is a simplified sequence diagram illustrating a secondary RAN node led inter-node information exchange procedure for cell DTX / DRX activation status related information that may be implemented, in the context of dual connectivity, in the communication system of Fig. 1;Fig. 16 is a simplified sequence diagram illustrating an AI / ML enhanced procedure for performing NES actions at one RAN node based on cell DTX / DRX related information from another RAN node that may be implemented in the communication system of Fig. 1;Fig. 17 is a simplified sequence diagram illustrating another AI / ML enhanced procedure for performing NES actions at one RAN node based on cell DTX / DRX related information from another RAN node that may be implemented in the communication system of Fig. 1;Fig. 18 is a simplified sequence diagram illustrating different inter-node information exchange procedures for NES mode information that may be implemented in the communication system of Fig. 1;Fig. 19 is a simplified sequence diagram illustrating different intra-RAN, inter-node, information exchange procedures for NES mode information that may be implemented in the communication system of Fig. 1;Fig. 20 is a simplified sequence diagram illustrating different inter-node information exchange procedures for WUS configuration information that may be implemented in the communication system of Fig. 1;Fig. 21 is a schematic block diagram illustrating the main components of a UE the communication system of Fig. 1;Fig. 22 is a schematic block diagram illustrating the main components of a non-distributed RAN node for the communication system of Fig. 1; andFig. 23 is a schematic block diagram illustrating the main components of a distributed RAN node for the communication system of Fig. 1.

[0035] Overview 　　An exemplary telecommunication system will now be described in general terms, by way of example only, with reference to Figs. 1 to 7.

[0036] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system (e.g. communication system 1) to which examples of the present disclosure are applicable.

[0037] In the communication system 1, user equipment (UEs) 3 (3-1, 3-2, 3-3) (e.g. mobile telephones and / or other mobile devices) can communicate with each other via a corresponding (radio) access network ((R)AN) node 5-1, 5-2 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, each RAN node 5 (5-1, 5-2) comprises a base station or 'gNB' that respectively operates one or more associated cells 9 (9-1, 9-2). In the illustrated communication system 1, the coverage provided by each RAN node 5 may be by means of a plurality of beams B (B1, B2… Br, Br+1… BN). It will be appreciated that while, for clarity of illustration, only a selection of possible beams B are shown for one of the RAN nodes 5, the set of beams may include any suitable number of beams and each RAN node 5 may operate a respective set of beams or may provide coverage in a non-beamformed manner.

[0038] Communication via each RAN node 5 is typically routed through a core network 7 (e.g. a 5G or later generations core network or evolved packet core network (EPC)).

[0039] As those skilled in the art will appreciate, whilst three UEs 3 and two RAN nodes 5 are shown in Figure 1 for illustration purposes, the system, when implemented, will typically include other RAN nodes and UEs 3.

[0040] Each RAN node 5 controls one or more associated cells 9 either directly, or indirectly via one or more other nodes (such as home base stations, relays, remote radio heads, distributed units, and / or the like). It will be appreciated that the RAN nodes 5 may be configured to support 4G, 5G, 6G, and / or later generations and / or any other 3GPP or non-3GPP communication protocols.

[0041] In this example one of the illustrated RAN nodes 5 is a RAN node 5-2 that forms part of a distributed RAN (which may be referred to as a 'distributed base station' or distributed 'RAN node'). The RAN node 5-2 of a distributed RAN comprises at least one distributed unit (DU) 5-2DU(e.g., a gNB-DU or the like), and a central unit (CU) 5-2CU(e.g., a gNB-CU or the like). The CU 5-2CUemploys a separated control plane and user plane and so is, itself, split between a control plane function (CU-CP) and a user plane function (CU-UP) which respectively communicate, with the DU 5-2DUvia appropriate interfaces (e.g. an F1-C interface and an F1-U interface (together forming an F1 interface (or 'reference point'))), and with one another via an appropriate interface (e.g. an E1 logical interface). It will be appreciated that while, in this example, the DU 5-2DUincludes the physical and virtual elements required to provide the functionality of the lower parts of the PHY layer and hence communicate with the UEs 3 over the air interface, the distributed RAN node 5-2 may alternatively (or additionally) include one or more separate radio units (RUs) (e.g., providing this functionality of the lower parts of the PHY layer).

[0042] Whilst one non-distributed ('integrated') RAN node 5-1 and one distributed RAN node 5-2 are shown, it will, nevertheless, be appreciated that either (or both) of the RAN nodes 5 may be provided in a distributed or non-distributed form. It will also be appreciated that whilst the term 'RAN node' is generally used herein to refer to a whole base station, the CU 5-2CUand DU 5-2DUare also both parts of a corresponding distributed RAN and are therefore each a distinct 'RAN node' 5 albeit that they each form part of the same RAN, and that each may have only a subset of the functionality provided by a whole base station. References to a RAN node 5 as used herein should, therefore, be understood, accordingly.

[0043] The UEs 3 and their serving RAN node 5 are connected via an appropriate air interface (for example the so-called 'Uu' interface and / or the like). Neighbouring RAN nodes 5 may be connected to each other via an appropriate RAN node to RAN node interface (such as the so-called 'X2' interface, 'Xn' interface and / or the like).

[0044] The core network 7 includes a number of logical nodes (or 'functions') for supporting communication in the communication system 1. In this example, the core network 7 comprises control plane functions (CPFs) 10 and one or more network node entities for the communication of user data (e.g. user plane functions (UPFs) 11). The CPFs 10 include one or more network node entities for the communication of control signalling (e.g. Access and Mobility Management Functions (AMFs) 10-1), one or more network node entities for session management (e.g. Session Management Functions (SMFs) 10-2) and a number of other functions 10-n. Additional functions may include, for example: an Authentication Server Function (AUSF) which facilitates security processes; a Unified Data Management (UDM) entity for managing user specific data (e.g., for access authorization, user registration, and data network profiles); a Policy Control Function (PCF); an Application Function (AF); a Security Anchor Function (SEAF) which is in a serving network and acts as a "middleman" during an authentication process between a UE and its home network; an Authentication credential Repository and Processing Function (ARPF) which maintains the authentication credentials; and / or the like. It will be appreciated that the nodes or functions may have different names in different systems.

[0045] The communication system 1 also includes an Operations, Administration and Maintenance (OAM) system 14 comprising one or more OAM functions for provisioning and managing network or elements within the wider communication system 1. The OAM 14 may be responsible for the storage and analysis of some radio-related measurements and may perform some data analytics functions including some RAN analytics. The OAM may, for example, communicate with one or more of the core network CPFs via a network data analytics function (NWDAF) or the like (not shown).

[0046] Each RAN node 5 is respectively connected to the core network nodes via appropriate interfaces (or 'reference points') such as an N2 reference point between the RAN node 5 and the AMF 10-1 for the communication of control signalling, and an N3 reference point between the RAN node 5 and each UPF 11 for the communication of user data. The UEs 3 are each connected to the AMF 10-1 via a non-access stratum (NAS) connection over an appropriate interface (e.g. an N1 reference point (analogous to the S1 reference point in LTE)). It will be appreciated, that N1 communications are routed transparently via the RAN node 5.

[0047] Each UPF 11 is respectively connected to an external data network (e.g. an IP network such as the internet) via an appropriate interface (e.g. an N6 reference point) for communication of the user data.

[0048] The AMF 10-1 performs mobility management related functions, maintains the NAS connection with each UE 3 and manages UE registration. The AMF 10-1 is also responsible for managing paging.

[0049] The SMF 10-2 is connected to the AMF 10-1 via an appropriate interface (e.g. an N11 reference point). The SMF 10-2 provides session management functionality (that formed part of MME functionality in LTE) and additionally combines some control plane functions (provided by the serving gateway and packet data network gateway in LTE). The SMF 10-2 also allocates IP addresses to each UE 3. The SMF 10-2 uses user information provided via the AMF 10-1 to determine what session manager would be best assigned to the user. The SMF 10-2 may be considered effectively to be a gateway from the user plane to the control plane of the network. The SMF 10-2 also allocates IP addresses to each UE 3.

[0050] Each RAN node 5 is also configured for transmission of, and the UEs 3 are configured for the reception of, control information and user data via a number of downlink (DL) physical channels and for transmission of a number of physical signals. The DL physical channels correspond to resource elements (REs) carrying information originated from a higher layer, and the DL physical signals are used in the physical layer and correspond to REs which do not carry information originated from a higher layer.

[0051] The physical channels may include, for example, a physical downlink shared channel (PDSCH), a physical broadcast channel (PBCH), and a physical downlink control channel (PDCCH). The PDSCH carries data sharing the PDSCH's capacity on a time and frequency basis. The PDSCH can carry a variety of items of data including, for example, user data, UE-specific higher layer control messages mapped down from higher channels, system information blocks (SIBs), and paging. The PDCCH carries downlink control information (DCI) for supporting a number of functions including, for example, scheduling the downlink transmissions on the PDSCH and also the uplink data transmissions on a physical uplink shared channel (PUSCH). The PBCH provides at least the UEs 3 with the Master Information Block (MIB). It also, in conjunction with the PDCCH, supports the synchronisation of time and frequency, which aids cell acquisition, selection and re-selection. Specifically, a UE 3 may receive a Synchronization Signal / Physical broadcast Channel (PBCH) Block (SSB) (also referred to as an 'SS / PBCH block'), and the UE 3 may assume that reception occasions of a PBCH, primary synchronization signal (PSS) and secondary synchronization signal (SSS) are in consecutive symbols and form that SSB. The RAN node 5 may transmit a number of SSBs corresponding to different DL beams. The total number of SSBs may be confined, for example, within a 5ms duration as an SS burst.

[0052] The DL physical signals may include, for example, reference signals (RSs) and synchronization signals (SSs). A reference signal (sometimes known as a pilot signal) is a signal with a predefined special waveform known to both the UE 3 and the RAN node 5. The reference signals may include, for example, cell specific reference signals, UE-specific reference signal (UE-RS), downlink demodulation signals (DMRS), and channel state information reference signal (CSI-RS).

[0053] Similarly, the UEs 3 are configured for transmission of, and the RAN node 5-1 is configured for the reception of, control information and user data via a number of uplink (UL) physical channels corresponding to REs carrying information originated from a higher layer, and UL physical signals which are used in the physical layer and correspond to REs which do not carry information originated from a higher layer. The physical channels may include, for example, the PUSCH, a physical uplink control channel (PUCCH), and / or a physical random-access channel (PRACH). The UL physical signals may include, for example, demodulation reference signals (DMRS) for a UL control / data signal, and / or sounding reference signals (SRS) used for UL channel measurement.

[0054] When the UE 3 initially establishes a radio resource control (RRC) connection with a RAN node 5 via a cell 9 it registers with an appropriate core network node (e.g., AMF 10-1, MME). The UE 3 is in the so-called RRC connected state and an associated UE context is maintained by the network. When the UE 3 is in the so-called RRC idle state, or is in the RRC inactive state, it selects an appropriate cell for camping so that the network is aware of the approximate location of the UE 3 (although not necessarily on a cell level).

[0055] Frame Structure 　　Referring to Fig. 2, which illustrates a typical frame structure that may be used in the communication system 1, the RAN node 5 and UEs 3 of the communication system 1 communicate with one another using resources that are organised, in the time domain, into frames of length 10ms. Each frame comprises ten equally sized subframes of 1ms length. Each subframe is divided into one or more slots comprising 14 Orthogonal frequency-division multiplexing (OFDM) symbols of equal length.

[0056] As seen in Fig. 2, the communication system 1 supports multiple different numerologies (subcarrier spacing (SCS), slot lengths and hence OFDM symbol lengths). Specifically, each numerology is identified by a parameter, μ, where μ=0 represents 15 kHz (corresponding to the LTE SCS). Currently, the SCS for other values of μ can, in effect, be derived from μ=0 by scaling up in powers of 2 (i.e. SCS = 15 x 2μkHz). The relationship between the parameter, μ, and SCS (Δf) is as shown in Table 1:

[0057] Control Information 　　In the communication system 1, the RAN node 5 is configured to transmit control information to the UE 3 using one or more control resource sets (CORESETs). A CORESET is a set of time-frequency resources within which the UE 3 can search for DCI transmitted by the RAN node 5 on a PDCCH. A CORESET is analogous to the control region at the start of subframes in earlier generations of communication technology. Unlike earlier generations, however, in which the frequency domain of the control region typically corresponded to the total system bandwidth, the frequency domain location for CORESET is localised to a specific region in the frequency domain and has a variable width that can be set to any suitable value (typically in multiples of six resource blocks where each resource block comprises twelve subcarriers in the frequency domain).

[0058] A number of different DCI formats can be used by the RAN node 5, depending on requirements, for transmission on a PDCCH corresponding to one of the PDCCH candidates in one of the search spaces configured for a given UE 3. For example, the RAN node 5 may be able to transmit DCI using one or more of the currently standardised DCI formats as set out in Table 2.

[0059] Different DCI formats may or may not have the same DCI size. Moreover, DCI may be addressed (scrambled) using different radio network temporary identifiers (RNTIs) that a UE 3 may monitor for. Typically, a UE 3 is capable of monitoring up to three different DCI sizes for DCI formats using a cell RNTI (C-RNTI) - typically used as an identifier for scheduling purposes. Additionally, a UE 3 is typically capable of monitoring one additional DCI size using other RNTIs for specific purposes (e.g., a slot format indication RNTI (SFI-RNTI), interruption RNTI (INT-RNTI), or the like). This constraint is sometimes referred to as the "3+1" size budget and is imposed because a DCI scrambled with a C-RNTI is, generally, more time critical than a DCI scrambled with a RNTI used for another specific purpose, and so requires the UE 3 to decode it promptly in order to be able to process the scheduled data transmission.

[0060] To take account of the constraint imposed by the DCI size budget, the sizes of some DCI formats may be aligned by padding, truncation, and / or determining a frequency domain resource assignment field differently.

[0061] A UE 3 may monitor a set of PDCCH candidates in one or more control resource sets (CORESETs) on an active DL bandwidth part, where monitoring implies decoding each PDCCH candidate according to the monitored DCI formats. The number of blind decodes (BDs) may be restricted on a per carrier basis of a serving cell. The number of BDs may refer to the number of monitored PDCCH candidates or the number of PDCCH candidates the UE 3 is capable of decoding within a certain time frame, such as a slot or span of consecutive symbols in a slot. As an example, at a 15 kHz subcarrier spacing (SCS), the maximum number of BDs per slot per serving cell supported by the UE 3 may be 44 BDs.

[0062] Support for Artificial Intelligence (AI) / Machine Learning (ML) 　　The communication system 1 supports the use of artificial intelligence (AI) and machine learning (ML), often abbreviated to AI / ML in accordance with recent developments in cellular communication technology (e.g., as part of the work of the 3GPP) that those skilled in the art will be familiar with. These AI / ML features make use of trained AI / ML models to make one or more predictions or inferences, from a set of one or more input vectors, that can be used in the network (e.g., for improving the reliability or efficiency of communication in the network).

[0063] In respect of the communication system 1, for example, AI / ML models could potentially be trained and used for predicting the path of a UE 3 based on previous mobility of the UE 3, used for beam management, or used in methods of encoding and transmitting information. An AI / ML model may be hosted at a RAN node 5 (or any other suitable network node), and the RAN node 5 may perform control of communication resources for UEs 3 it serves, and / or perform control related to the status of a UE 3 (e.g. control of UE mobility, or control of a radio resource control, RRC, state of the UE 3) based on an inference (e.g. determination or prediction) generated using the AI / ML model. The RAN node 5 may also transmit an inference generated using the model to another node in the network, for use at the other node. An AI / ML model may also be hosted the UE 3, or at a plurality of locations within the network, for example at both the RAN node 5 and at the UE 3. For example, the RAN node 5 and the UE 3 may both make determinations and / or predictions using the same model or different models.

[0064] The support for such AI / ML features may involve different levels of collaboration between the network (RAN node 5 and / or core network 7) and a UE 3 served by the network when deploying and using such AI / ML features. For example, three possible 'network-UE collaboration levels' that may be supported are: - Level x: Involving no collaboration between the network and the UE 3. Specifically, level x is an implementation-based AI / ML operation without any dedicated AI / ML-specific enhancement. - Level y: Signalling-based collaboration without AI / ML model transfer. For example, this level is applicable when model training is performed offline, and models are registered to both a RAN node 5 and the UE 3. Here, the RAN node 5 and the UE 3 are aware of available models (before operation), and the RAN node 5 is only required to activate / deactivate the models residing at the UE 3 when needed. - Level z: Signalling-based collaboration with AI / ML model transfer (e.g., where an AI / ML model is transferred to the UE 3 when needed).

[0065] The AI / ML model types that are supported in the communication system 1 may include, for example: - Single-sided model: A single-sided AI / ML model is an AI / ML model that is deployed (hosted) only at the UE side or at the network side. An example of this type of model is an AI / ML model for beam prediction in time, which can be deployed at the UE side. However, even when the model is a single-sided model, it will be appreciated that the model need not necessarily be trained at the node at which it is deployed (e.g. a UE 3 or a RAN node 5). For example, the model could be trained at the RAN node 5 (or at another node in the network such as a core network node / function), and then is transferred to the UE 3 for use at the UE 3. - Two-sided model: A 'two-sided' model is an AI / ML model (or model pair) that has one AI / ML model hosted at one node (e.g., the UE 3), and a corresponding AI / ML model hosted at another node (e.g., the RAN node 5) - it will be appreciated that any pair of network nodes may be used. Such a two-sided model may also be referred to as a 'paired' AI / ML model. Inference using a two-sided model is performed jointly across the nodes at which the AI / ML models of the two-sided model are deployed. The joint inference may comprise, for example, a first part of the inference being performed at one node (e.g. the UE 3 or the RAN node 5), and then the remaining part may be performed by the other (e.g., the RAN node 5 or the UE 3). It will be appreciated that whilst the AI / ML model hosted at the different nodes may be the same AI / ML model, they need not necessarily be the same model. One example of this type of model is, for example only, channel state information (CSI) compression, where the UE performs CSI compression and network performs CSI decompression. As with the single-sided model case, the two-sided model (or models) may be trained at any suitable network node, and then transmitted to the UE 3 and the RAN node 5 (or other respective node or nodes).

[0066] A general discussion of how AI / ML may be implemented in the communication system 1 will now be provided, by way of example only, with reference to Figs. 3 and 4.

[0067] Fig. 3 illustrates a functional framework for AI / ML models, and how various entities of the framework may interact with one another, that may be implemented in the communication system 1.

[0068] The entities include a data collection entity 341, a model training function 343, a model inference function 345, an actor 347, a management function 349, and a model storage entity 351.

[0069] The model storage entity 351 may be a reference point for protocol terminations for model transfer and delivery. The AI / ML models could be stored at any suitable node in the network.

[0070] The data collection entity 341 provides training data to the model training function 343, inference data to the model inference function 345, and monitoring data to the management function 349. The collected data may be, for example, data regarding mobility (e.g. handover of a UE 3, or a location of the UE 3). The data may be obtained, for example, by the UE 3 or the RAN node 5 (e.g. by receiving a measurement report from the UE 3, or by receiving data from another RAN node 5 or a core network node / function) and transmitted to another RAN node 5 or core network node that generates the AI / ML model inference output (or alternatively, the same RAN node 5 that obtains the data may generate the AI / ML model output).

[0071] The model training function 343 performs the ML model training, validation, and testing, and may generate model performance metrics as part of a model testing procedure. The model training function 343 may output a trained AI / ML model to the model storage entity 351 (though it will be appreciated that the output model may be stored at locations other than model storage entity 351).

[0072] The model inference function 345 provides AI / ML model inference output (e.g., predictions or decisions), and the actor 347 is a function or node that receives the output from the model inference function 345 and triggers or performs corresponding actions (e.g. the RAN node 5 that increases / reduces its transmit power, or initiates a handover procedure for the UE 3). The AI / ML model inference output may be, for example, a prediction of mobility (e.g. expected path, route or trajectory, inter-cell, or inter-beam mobility, or expected handover) of the UE 3, or one or more parameters for use in encoding or decoding transmissions between the RAN node 5 and the UE 3. The model inference function 345 may receive an AI / ML model from the model storage entity 351, and inference data from the data collection entity 341 for use with the AI / ML model. The model inference function 345 may also output monitoring data for use at the management function 349, and receive information indicating an AI / ML to activate or deactivate from the management function 349.

[0073] The management function 349 receives monitoring data from the data collection entity 341, and may also receive monitoring data from the model inference function 345. The management function 349 may transmit, to the model storage entity 351, an indication of an AI / ML model to be transmitted for use at the model inference function 345. The management function 349 may also transmit, to the model training function 343, performance feedback or a retraining request for the AI / ML model.

[0074] The functions illustrated in Fig. 3 may be co-located at a single node of the communication system 1 (e.g. at a RAN node 5 or core network node / function), or may be distributed amongst a plurality of network nodes (e.g. a plurality of RAN nodes 5).

[0075] By way of example only, terms referred to by 3GPP in the context of this framework include: - AI / ML model training: A process to train an AI / ML Model [by learning the input / output relationship] in a data driven manner and obtain the trained AI / ML Model for inference. Model training can be performed offline or online or combination of both. - AI / ML model validation: A subprocess of training, to evaluate the quality of an AI / ML model using a dataset different from one used for model training, that helps selecting model parameters that generalize beyond the dataset used for model training. - AI / ML model testing: A subprocess of training, to evaluate the performance of a final AI / ML model using a dataset different from one used for model training and validation. Differently from AI / ML model validation, testing does not assume subsequent tuning of the model. - AI / ML model Inference: A process of using a trained AI / ML model to produce a set of outputs based on a set of inputs. - Data collection: A process of collecting data by the network nodes, management entity, or UE for the purpose of AI / ML model training, data analytics and inference. - Model monitoring: A procedure that monitors the inference performance of the AI / ML model. - Model activation: Enable an AI / ML model for a specific function. - Model deactivation: Disable an AI / ML model for a specific function. - Model switching: Deactivating a currently active AI / ML model and activating a different AI / ML model for a specific function. - Supervised learning: A process of training a model from input and its corresponding labels. - Unsupervised leaning: A process of training a model without labelled data. - Semi-supervised learning: A process of training a model with a mix of labelled data and unlabelled data. - Reinforcement Learning (RL): A process of training an AI / ML model from input (also referred to as 'state') and a feedback signal (also referred to as 'reward') resulting from the model's output (also referred to as 'action') in an environment the model is interacting with.

[0076] The data collection by the data collection entity 341 may be performed at various nodes of the communication system 1 (e.g., at one or more RAN nodes 5 or UEs 3). Particularly advantageous methods of obtaining, at the UE 3, data for an AI / ML model, and transmitting the AI / ML data from the UE 3 to the RAN node 5, will be described in more detail later.

[0077] Fig. 4 schematically illustrates of a method of training an AI / ML model, and of monitoring the performance of the AI / ML model. As illustrated in Fig. 4, stored data / features may first be extracted in a data extraction step. In the data validation step, a determination of whether to proceed with training or retraining the AI / ML model is made (e.g., based on the extracted data). In the data preparation stage, the data is prepared for use in training the AI / ML model. For example, the data may be cleaned (e.g., filtered), subject to a transformation, or modified in any other suitable manner. The data may also be divided in training data, validation data and test data sets in the data preparation stage.

[0078] In the model training step, the AI / ML model is trained (or retrained) using training data prepared in the data preparation step. It will be appreciated that any suitable training method can be used to train the AI / ML model (e.g. a method that comprises supervised learning or unsupervised learning). In the model evaluation step, the AI / ML model is evaluated (e.g. a prediction accuracy of the AI / ML model is evaluated) using a test data set (which may be generated in the data preparation step). In the model validation step, a determination of whether the AI / ML model is suitable for deployment in the communication system 1 is made (e.g. based on the results of the model evaluation step).

[0079] In the model serving step, the AI / ML model is deployed for use in the communication system 1. AI / ML model deployment may comprise compiling a trained AI / ML model, packaging the model into an executable format, and delivering the AI / ML model to a target device. For example, the AI / ML model may be transmitted to the RAN node 5 and / or the UE 3, for use at the RAN node 5 and / or the UE 3 to generate predictions or determinations using the AI / ML model as part of a prediction service step, as illustrated in Fig. 4. In the performance monitoring step, the performance of the deployed AI / ML model is monitored. The predictive performance of the AI / ML model may be monitored by comparing predictions generated using the model with one or more measurements. For example, when the AI / ML model is used to predict a location of the UE 3, the prediction accuracy of the AI / ML model may be assessed using a measurement of an actual location of the UE 3. If the AI / ML model is used for predicting future measurement results (e.g., the measured RSRP of reference signals) at some point in time, the prediction accuracy of the AI / ML model may be assessed using actual measurement results acquired by the UE 3 when that point in time is reached. If the AI / ML model is used for determining parameters for use in encoding and decoding data transmitted between the RAN node 5 and the UE 3, the model may be assessed based on the performance of the encoding and / or decoding processes. In the retraining trigger step, retraining of the AI / ML model is triggered (e.g. because the prediction accuracy of the AI / ML model has fallen below an acceptable threshold accuracy, or because a performance of a method that uses inferences from the AI / ML model has fallen below an acceptable threshold performance), and the method returns to the data extraction step.

[0080] As described above with reference to Fig. 3, each step of the method of Fig. 4 may be executed at a single node of the communication system 1 (including at the UE 3), or alternatively steps of the method may be distributed between a plurality of different nodes (or indeed one or more of these steps may be performed online or offline).

[0081] As discussed above with reference to Figs. 3 and 4, information collected by nodes / functions in the communication system 1 (e.g. at a UE 3) can be used as training data for an AI / ML model, and used as inference data for use in generating one or more model inferences using the AI / ML model. The information used as training data, monitoring data, and / or to generate the one or more model inferences may be referred to as 'AI / ML information' or 'AI / ML data'.

[0082] Carrier Aggregation (CA)

[0083] In the communication system 1, increases in bandwidth, and thereby bitrate can be achieved through carrier aggregation (CA), whereby multiple frequency blocks, i.e., component carriers (CCs), are assigned to the same UE 3 for use. Each CC in turn serves a cell which provides a particular bandwidth and set of services to the UE 3. For example, in CA each UE 3 has a first CC that provides a primary cell (PCell) that carries traffic and RRC signalling messages and may additionally any number of other CCs that each provide their own corresponding secondary cell (SCell) which carry traffic alone. The SCells are optional, and are added, removed, and / or reconfigured are required by the UE 3 and the network.

[0084] In CA, when initially scanning for a cell to camp on each UE 3 scans for a PCell. The PCell is serves as the main point of communication between the UE 3 and the RAN node 5 and is responsible for all control information signalling (e.g., RRC Configuration signalling), non-access stratum (NAS) signalling, and the like, between the UE 3 and the network, as well as initial data transmissions. The PCell typically offers a high bandwidth for low latency data transmission. It will be appreciated that when initially scanning for a PCell to camp on each UE 3 searches for SSB as described previously to enable efficient cell searching for, and initial access to the PCell.

[0085] As and when required, the UE 3 may be triggered to search for, and camp on one or more secondary cells (SCells) to provide additional capacity and adaptability in the network. For example, the UE 3 may be triggered to search for, and camp on one or more SCells to provide extra bandwidth when the network is experiencing high data traffic or congestion. Additionally, or alternatively, SCells may be camped on to provide specific specialist services, for example, the UE 3 may camp onto a SCell that caters for Internet-of-Things (IoT) devices, high-definition data streaming, or the like.

[0086] Dual Connectivity (DC) 　　The UEs 3 and RAN nodes 5 of the communication system are also mutually configured for dual connectivity in which the UE 3 can be configured to connect and communicate via (at least) two different RAN nodes 5 known as a master RAN node 5 and a secondary RAN node 5 that are themselves interconnected via an appropriate RAN node to RAN node interface (e.g., Xn or X2). It will be appreciated that, in dual connectivity, the master RAN node 5 and the secondary RAN node 5 may be configured to use the same, or a different, radio access technology (e.g., the RAN nodes 5 may each use a different one of a 4G, 5G, 6G (or later generations or other) radio access technology).

[0087] CA can also be used by a UE 3, in the context of dual connectivity. For example, the UE 3 may be configured to communicate via one, or multiple (carrier aggregated) cells of the master RAN node 5 and via one, or multiple (carrier aggregated) cells of the secondary RAN node 5.

[0088] A group of serving cells associated with the master RAN Node 5 may be referred to as a master cell group (MCG). The MCG typically comprises a so called special cell (SpCell) which is the PCell (Primary Cell), and one or more SCells. A group of serving cells associated with the secondary RAN Node 5 may be referred to as a secondary cell group (SCG). The SCG typically comprises an SpCell, which is known as a primary SCell (PSCell) in this case, and one or more SCells.

[0089] It will be appreciated that whilst CA and DC are conceptually similar, there are a number of differences. For example, in CA the user traffic is typically split between different carriers at the MAC layer, whereas in DC user traffic is typically split at the PDCP layer.

[0090] Network Energy Saving (NES) 　　The UEs 3 and RAN nodes 5 of the communication system 1 are mutually configured to be able to coordinate with one another appropriately to implement one or more NES techniques. The NES techniques may include, for example, conventional DTX / DRX at the UE 3, cell DTX / DRX at the RAN node 5, the use of SSB-less cells in which SSBs are not transmitted, the use of SIB1-less cells in which SIB1s are not transmitted, the provision of SSBs on-demand in one or more cells, and / or the provision of one remaining minimum system information (SIB1) transmissions on-demand in one or more cells.

[0091] The communication system 1 may, for example, support SSB-less / SIB1-less operation for intra-band CA scenarios, for example, where the UE 3 is able to retrieve system information from, and can perform synchronisation based on, another intra-band cell that transmits SSB and SIB1. For the non-CA scenario, the UE 3 may obtain system information from other associated carriers / cells and synchronise from other associated carriers / cells and / or synchronise from other signals transmitted in the cell. A cell in which the RAN node 5 transmits, and the UE 3 is capable of receiving, an SSB, system information and paging may be referred to as an anchor cell. Access may occur only via an anchor cell, or directly via the non-anchor NES cell if supported. Where access directly via a non-anchor NES cell is supported, system information transmitted in the anchor cell may also include the necessary information to access the non-anchor NES cell. The UE 3 will camp on an anchor cell rather than a non-anchor NES cell in which there is no SIB1 transmission (or no SSB or SIB1 transmission).

[0092] The communication system 1 may nevertheless support on-demand SSB / SIB1 transmissions (e.g., in an otherwise SSB-less or SIB1-less cell) to enable longer periods of cell inactivity to achieve network energy saving. SSB / SIB1 transmission in a serving cell may, for example, be triggered on-demand, for example by the UE 3 (or the RAN node 5). The UE 3 and RAN node 5 of the communication system 1 may, for example, be mutually configured to support the transmission of dedicated SSBs and / or SIB1s in (non-anchor NES) SCells on-demand.

[0093] The triggering of an on-demand SSB / SIB1 may, for example, be facilitated by the transmission, by the UE 3, of an appropriate trigger signal (or 'wake-up' signal (WUS)) in the uplink to cause the RAN node 5 to 'wake-up' from its current sleep state (or at least transition into a more awake / higher power level sleep state) and begin to transmit SSBs in the corresponding non-anchor / secondary cell. The configuration of the uplink WUS, for example, the configuration of when and / or where in frequency the WUS can be transmitted, may be predefined or may be configured by the RAN node 5 (e.g., via system information and / or DCI).

[0094] A WUS may, for example be configured by appropriate common radio resource configuration information, comprising WUS configuration information (e.g., in a dedicated WUS configuration information element), provided as part of system information.

[0095] A simplified example of an Abstract Syntax Notation One (ASN.1) representation of a possible implementation of a conventional WUS configuration information element / field that may be used for configuring a WUS is shown in Fig. 5 by way of illustration only. In this example, the WUS configuration configures the time / and frequency resources in which the UE 3 may monitor for reception of a downlink WUS from the network to indicate that the UE 3 should wake up (e.g., to receive paging). As will be described in more detail later, the communication system 1 beneficially employs an enhanced WUS configuration that configures the time / and frequency resources via which the UE 3 is to request SSB transmission and / or SIB1 transmission (by means of an uplink WUS or the like), where the SSB / SIB1 transmission is on-demand in a particular cell. The enhance WUS configuration may form part of a modified version of the WUS configuration illustrated in Fig. 5 or may form part of a new dedicated WUS configuration.

[0096] As seen in Fig. 5 the example information element is labelled 'WUS-Config' and includes a number of information elements / fields that are summarised in Table 3 below. It will be appreciated that the names of the information elements are purely examples and could be different depending on the nature of the communication system in which the configuration is implemented.

[0097] On-demand SSB / SIB1 transmission may, for example, be enabled semi-statically or dynamically. For example, common channel adaptation and / or on-demand SSB may be enabled via dedicated RRC signalling on a PCell and / or PScell if the UE 3 has a PCell and / or PScell connection. On-demand SSB / SIB1 may be enabled via system information (e.g., where the content of system information includes a carrier indication field to indicate the applicable carrier / cell for the enabling of on-demand SSB transmission). On-demand SSB / SIB1 may be enabled via a DCI with an appropriate DCI format.

[0098] At the RAN node 5, depending on what energy saving technique is being implemented, and how that technique is being implemented, the RAN node 5 (and / or a specific subset of one or more cells that it operates) may be operated in one of a number of different NES modes or states. The possible NES modes may include, for example, simple 'on' or 'off' states. Nevertheless, the possible NES modes may include different predefined energy / power consumption states for the RAN node 5 (or one or more cells operated by that RAN node 5) including: a number of different 'sleep' states in which the RAN node 5 is at least partially off / not fully on but may perform certain operations. These sleep states may be characterised, for example, by different relative power levels, for example: 'deep' sleep (lowest power); 'light' sleep (higher power relative to deep sleep); and micro sleep (higher power relative to both deep and light sleep). Moreover, the possible NES modes may include an active uplink state and an active downlink state in which the RAN node 5 is respectively 'on' for communication in the uplink direction only, or for communication in the downlink direction only.

[0099] It will be appreciated that whilst a number of specific techniques are described, a given UE 3 or RAN node 5 need not implement every NES technique mentioned, and or may implement one or more other such NES techniques.

[0100] A more detailed introduction to a number of NES techniques will now be provided way of example only.

[0101] General DTX / DRX at the UE 　　A UE 3 may be configured to operate using a discontinuous reception (DRX) method. In a DRX method, the UE 3 is configured with a DRX configuration that includes a DRX pattern and a periodicity (DRX cycle) and optionally a number of DRX cycles. The DRX pattern defines "ON durations" in which the UE 3 is configured for receiving transmissions and "OFF durations" in which the UE 3 is not configured for receiving transmissions (e.g., transmissions from a RAN node 5). During the OFF durations, the physical layer processing may be turned off within the UE 3. Advantageously, the energy consumption of the UE 3 is reduced in the periods in which the UE 3 is not configured for receiving transmissions.

[0102] The UE 3 is typically provided with its DRX configuration by or via the RAN node 5. A DRX configuration provided to the UE 3 (for example, using a DRX configuration information element (IE) included in a transmission from the RAN node 5 to the UE 3) may include, as mentioned above, an indication of a time period (OFF duration) for which the UE 3 is to be configured in a state in which the UE 3 does not receive and decode downlink transmissions, and an indication of a time period (ON duration) for which the UE 3 is to be configured for receiving downlink transmissions (e.g., a multicast or unicast transmission from the RAN node 5). The DRX configuration may also include a time offset, which may be useful for controlling the relative timing of the DRX configurations of different UEs 3 (e.g., to synchronise or offset the DRX patterns). The DRX configuration may also include an indication of a time period in which the UE 3 is to remain configured for receiving transmissions following the reception of a PDCCH.

[0103] The ON duration may also be referred to as the 'DRX active time', and the OFF duration may also be referred to as a 'sleep period', or a 'DRX inactive time'. An example of a DRX pattern having an ON duration of t1, and an OFF duration of t2, and which is repeated in accordance with a DRX cycle is illustrated in Fig. 6.

[0104] DRX may be configured per UE 3 by the network (e.g., via any suitable signalling from the RAN node 5). For example, the timing and / or duration of the ON durations in the DRX cycle may be different for different UEs 3. During the OFF durations, the UE 3 may be configured to not monitor a PDCCH but may initiate an uplink transmission based on configured resources (for example, using a PUCCH, a random access channel (RACH), scheduling request (SR) or a configured grant PUSCH (CG-PUSCH)). During an OFF duration, the system may be configured for no transmission / reception between the UE 3 and the RAN node 5 in a corresponding cell. The RAN node 5 may nevertheless be configured for reduced or limited transmission / reception in the cell during the OFF duration of the DRX cycle. For example, the RAN node 5 may be configured to transmit only a subset of periodic signals or channels, such as common channels / signals or UE-specific channels / signals that would normally be transmitted in the cell.

[0105] DRX may be used when the UE 3 is in an RRC idle mode or when the UE 3 is in an RRC connected mode. For example, DRX may be used when the UE 3 is in an RRC idle mode to control the monitoring of paging messages transmitted by the RAN node 5. This advantageously prevents the UE 3 from monitoring all of the PDCCH transmission opportunities, thereby reducing the energy usage of the UE 3. Similarly, DRX may be used when the UE 3 is in the RRC connected state (referred to as connected mode DRX or 'C-DRX') to reduce the energy usage of the UE 3, for example by configuring periods in which the UE 3 is not required to monitor a PDCCH.

[0106] Within a C-DRX cycle, when the UE 3 is in an RRC connected state, the UE 3 periodically monitors the PDCCH during the ON durations, and does not monitor PDCCH outside of the ON durations (i.e., in the DRX inactive periods), thereby beneficially reducing the power consumption of the UE 3. Currently, during a C-DRX inactive time, the UE 3 is allowed to initiate an uplink transmission based on configured resources (for example, using a PUCCH, a random access channel (RACH), scheduling request (SR) or on a configured grant PUSCH (CG-PUSCH)).

[0107] A DRX configuration may also include a long DRX cycle in which the time between the ON durations is relatively large (t2 shown in Fig. 6 is relatively large), and a short DRX cycle in which the time between the ON durations is relatively small (t2 shown in Fig. 6 is relatively small). Whilst the long DRX cycle improves the energy efficiency of the system (because the overall percentage of time in which the UE 3 is in the ON state is smaller), latency of communications may be increased because the RAN node 5 cannot communicate with the UE 3 via downlink transmissions when the UE 3 is in the sleep state (the DRX inactive state). When the UE 3 is configured to use DRX after a period of inactivity following a data transfer, the UE 3 may be configured to initially use the short DRX cycle configuration, and after a further period of time (which may be defined by a Short DRX Cycle timer) the UE 3 may then operate using the long DRX cycle configuration. The short and long DRX configurations may be indicated to the UE 3, for example, using any suitable signalling from the RAN node 5 (or alternatively could be preconfigured in the UE 3).

[0108] Whilst DRX has been described above with reference to discontinuous reception performed by the UE 3, a similar DTX pattern can be defined to control the discontinuous transmission of data by the UE 3. When defined, the UE DTX pattern typically overlaps with the UE DRX pattern - so that when the UE 3 is not receiving data it is also normally not transmitting data.

[0109] Cell DTX / DRX 　　A RAN node 5 may also operate one or more of its cells in a DTX / DRX mode in substantially the same way as UE DTX / DRX - stopping the RAN node's transmissions and receptions during periods of time (OFF (or 'inactive' duration) when the RAN node 5 is inactive or asleep and resuming transmissions and receptions with the UEs 3 during periods of time (ON (or 'active') duration) when the RAN node 5 is active.

[0110] The cell DTX / DRX configuration can be defined by a number of parameters such as, for example, the periodicity (DTX / DRX cycle), the start slot / offset, the ON (or 'active') duration (e.g., corresponding to t1 in Fig. 6), and the configuration type (e.g., DTX only, DRX only, or both DTX and DRX), for example to define a cycle for cell DTX / DRX that is similar to the DRX cycle illustrated in Fig. 6.

[0111] A simplified example of an Abstract Syntax Notation One (ASN.1) representation of a possible implementation of an information element / field that may be used for configuring cell DTX / DRX related parameters is shown in Fig. 7 by way of illustration only.

[0112] As seen in Fig. 7 the example information element is labelled 'CellDTXDRX-Config' and includes a number of information elements / fields that are summarised in Table 4 below. It will be appreciated that the names of the information elements are purely examples and could be different depending on the nature of the communication system in which the configuration is implemented.

[0113] The periodic cell DTX / DRX configuration may be explicitly signalled to the UEs 3. For example, in the communication system 1, one or more periodic joint cell DTX / DRX configurations comprising one or more periodic cell DTX / DRX patterns may be configured by UE specific (dedicated) signalling (e.g., RRC signalling). It can be seen, however, that cell DTX and cell DRX modes may be configured and operated separately (e.g., one (RRC) configuration set may be provided for the DL and another configuration set may be for provided for the UL). Nevertheless, (common) cell DTX / DRX may also be configured and operated together. It will be appreciated that the network may, or may not, allow legacy UEs to access cells with Cell DTX / DRX. Cell DTX / DRX may be configured on a per serving cell basis and may be applicable for different cells in the context of CA.

[0114] As a baseline, a given cell DTX / DRX configuration may be activated / deactivated implicitly by the configuration signalling (e.g., activated immediately once configured by an RRC configuration and deactivated once the RRC configuration is released). Nevertheless, a periodic cell DTX / DRX configuration may beneficially be explicitly activated / deactivated by L1 (or possibly L2) signalling and / or UE specific signalling.

[0115] Specifically, the communication system 1 also supports dynamic signalling (e.g., layer 1 (L1) / physical (PHY) layer signalling) by the RAN node 5, for at least activation / deactivation of a cell DTX and / or a cell DRX configuration at the UE 3 (e.g., in terms of enabling / disabling the cell DTX / DRX). In the exemplary communication system 1, this is achieved by means of L1 signalling that is addressable to one or more UEs 3 (e.g., using group common signalling), using a PDCCH, for cell DTX / DRX activation / deactivation. Specifically, DCI in accordance with a DCI format 2_9 may be used for the purpose of cell DTX and / or DRX configuration activation / deactivation of one or multiple serving cells for one or more UEs 3, and / or for providing an NES-mode indication of a primary cell (PCell) for one or more UEs 3.

[0116] Inter-node configuration exchange for NES 　　Beneficially, as described in more detail later, the communication system 1 is configured to support one or more techniques for inter-node exchange of NES related information, for example, between RAN nodes 5 of different RANs, and / or between different nodes of the same RAN (e.g., between a DU and a CU).

[0117] The inter-node exchange techniques that may be supported include: techniques for exchanging cell DTX / DRX configuration information between different nodes; techniques for exchanging activation status related information associated with cell DTX / DRX between different nodes; techniques for exchanging information identifying an NES mode between different nodes; and / or techniques for exchanging WUS configuration information between different nodes.

[0118] Where the RAN nodes 5 involved in the information exchange are of different RANs they may, for example, be 'neighbouring' RAN nodes 5 operating neighbouring cells (e.g., including adjacent, partially or fully overlapping, and / or nearby cells). Moreover, each RAN node 5 may be configured to operate as a master RAN node 5, or as a secondary RAN node 5, for supporting DC at the UE 3.

[0119] Where the RAN nodes 5 involved in the information exchange are different nodes of the same RAN, the RAN nodes 5 may, for example, include a DU and a CU (e.g., CU 5-2CU, DU 5-2DU).

[0120] Beneficially, as described in more detail later, the communication system 1 may also support one or more AI / ML enhanced procedures for performing NES actions at a first RAN node 5 based on cell DTX / DRX related information received from another RAN node 5. In one such procedure, for example, the first RAN node 5 beneficially performs an NES related action based on a cell DTX / DRX configuration inferred, by an AI / ML model that is deployed at the first RAN node 5 but that was trained elsewhere, based on the cell DTX / DRX related information received from another RAN node 5. In another such procedure, for example, the first RAN node 5 beneficially performs an NES related action based on a cell DTX / DRX configuration inferred, by an AI / ML model that is deployed at the first RAN node 5 and that was also trained at the first RAN node 5, based on the cell DTX / DRX related information received from another RAN node 5.

[0121] Beneficially, by allowing the exchange of NES related information (e.g., cell DTX / DRX configuration information) between RAN nodes 5 of different RANs, and / or between different nodes of the same RAN, the network node receiving the NES related information can use the received information to help determine its own NES configuration (e.g., its own cell DTX / DRX configuration) optimally which can help, for example, with inter-cell interference mitigation. Beneficially, this coordination of NES configuration (e.g., cell DTX / DRX configuration) between nodes, can also further help with load and coverage optimization of the network.

[0122] It will be appreciated that the various different techniques and procedures involving the exchange of NES related information described herein are neither mutually exclusive nor interdependent on one another. All, or a subset of one or more, of the techniques and procedures may be implemented in the communication system 1. For example, the various devices involved may be configured to use different techniques and procedures in different scenarios as appropriate.

[0123] Cell DTX / DRX Configuration Information Exchange (RAN Node to RAN Node Interface) 　　As mentioned above, the communication system 1 is configured to support one or more techniques for inter-node exchange of NES related information between RAN nodes 5 of different RANs. Moreover, as mentioned above the exchanged NES related information may comprise cell DTX / DRX configuration information.

[0124] A number of techniques / procedures for exchanging cell DTX / DRX configuration information between RAN nodes 5 of different RANs will now be described, by way of example only, with reference to Fig. 8, which is a simplified sequence diagram illustrating different inter-node information exchange procedures for cell DTX / DRX configuration information that may be implemented in the communication system 1.

[0125] In the examples illustrated in Fig. 8, the RAN nodes 5 include a first RAN node 5-1 and a second RAN node 5-2 that are interconnected by an appropriate RAN node (base station) to RAN node (base station) interface (e.g., an X2 or Xn interface and / or the like). It will be appreciated that the RAN nodes 5 may each use the same, or a different, one of a 4G, 5G, 6G (or later generations or other) radio access technology.

[0126] General RAN Node Configuration Update Procedure 　　In a first example illustrated in Fig. 8, the RAN nodes 5 are configured to engage in a general RAN node configuration update procedure 810a to support the information exchange. This procedure may, for example, be a modified form of a conventional Xn application protocol (XnAP) based RAN node configuration update procedure. As those skilled in the art will appreciate, the RAN node configuration update procedure is specified for 5G or later generations systems, for updating application level configuration data needed for two RAN nodes 5 (e.g., gNBs) to interoperate correctly over the Xn control plane (Xn-C) interface.

[0127] As part of the RAN node configuration update procedure 810a, the first RAN node 5-1 sends, at S812a, the cell DTX / DRX configuration information to the second RAN node 5-2 in an appropriate RAN node configuration update message (for example, an NG-RAN node configuration update message).

[0128] As seen in Fig. 8, the RAN node configuration update message may, for example, include a set of cell DTX / DRX related information which is common to a given serving cell such as information indicating: the periodicity; the start slot / offset; the on duration; and the configuration type. It will, nevertheless, be appreciated that the RAN node configuration update message may include only a subset of one or more of these items of information.

[0129] As seen in Fig. 8, the RAN node configuration update message may also include, for example, an indication of whether, or not, an activation status associated with the cell DTX / DRX configuration has been updated (by means of group common signalling (L1 or RRC)). This allows the second (neighbouring) RAN node 5-2 that receives the RAN node configuration update message to take this into account appropriately, for example: when determining whether to (further) update an NES configuration (e.g., the cell DTX / DRX configuration) for one or more cells operated by the second RAN node 5-2; and / or when making a handover decision for a UE 3 (e.g., whether or not to handover to a cell of the first RAN node 5-1).

[0130] Specifically, if the activation status associated with the cell DTX / DRX configuration is updated, then the second (neighbouring) RAN node 5-2 receiving the cell DTX / DRX configuration information may consider the cell DTX / DRX configuration as a reference for the purposes of a (further) configuration update or a handover decision (taking the updated activation status into consideration). If, on the other hand, the activation status associated with the cell DTX / DRX configuration is not updated, then the second (neighbouring) RAN node 5-2 receiving the cell DTX / DRX configuration information may make its own decision as to whether to use the received cell DTX / DRX configuration as a reference.

[0131] Accordingly, where group common signalling has been used by the first RAN node 5-1 to implement an activation status update for all or a group of UEs 3 within a given cell then, following the activation status update, the first RAN node 5-1 can send an updated cell DTX / DRX configuration (e.g., including an indication that the activation is updated by group common signalling) to the second RAN node 5-2 (and / or other neighbouring RAN nodes) as indicated at S812a.

[0132] As seen in Fig. 8, the RAN node configuration update message may optionally include activation status related information. This activation status related information may, for example, include an initial activation status for each UE 3 (e.g., each UE 3 served by a cell that is configured using the associated cell DTX / DRX configuration). This may, for example, be by means of: a list of UE IDs for UEs 3 for which the DTX / DRX configuration is activated (e.g., with those associated with a deactivated mode being implicit); a list of UE IDs for UEs 3 for which the DTX / DRX configuration is deactivated (with those associated with an activated mode being implicit); or a full list of UE IDs for UEs 3 that are configured using the associated cell DTX / DRX configuration together with a separate associated activation status for each UE. Each UE ID, for example, may be a temporary mobile subscriber identity (TMSI) - e.g., a serving TMSI (S-TMSI). Nevertheless, the UE ID may be of a type associated with a specific application protocol for the interface between the RAN nodes 5, or associated with the RAN (e.g., a UE XnAP ID or a RAN UE ID). Alternatively, or additionally, the number of UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included. Alternatively, or additionally, the percentage (or, proportion, or fraction) of the UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included.

[0133] The second RAN node 5-2 may acknowledge receipt of the RAN node configuration update message, at S814a, by sending an appropriate RAN node configuration update acknowledge message (for example an NG-RAN node configuration update acknowledge message).

[0134] Dedicated Cell DTX / DRX Configuration Update Procedure over RAN Node to RAN Node Interface 　　In a second example illustrated in Fig. 8, the RAN nodes 5 are configured to engage in a dedicated cell DTX / DRX configuration update procedure 810b to support the information exchange.

[0135] As part of the dedicated cell DTX / DRX configuration update procedure 810b the first RAN node 5-1 sends, at S812b, the cell DTX / DRX configuration information to the second RAN node 5-2 in a dedicated cell DTX / DRX configuration update message (e.g., using XnAP signalling, or similar signalling defined by a similar RAN node to RAN node interface application protocol).

[0136] As seen in Fig. 8, the dedicated cell DTX / DRX configuration update message may, for example, include a set of cell DTX / DRX related information which is common to a given serving cell such as information indicating: the periodicity; the start slot / offset; the on duration; and the configuration type. It will, nevertheless, be appreciated that the dedicated cell DTX / DRX configuration update message may include only a subset of one or more of these items of information.

[0137] As seen in Fig. 8, the dedicated cell DTX / DRX configuration update message may also include, for example, an indication of whether, or not, an activation status associated with the cell DTX / DRX configuration has been updated (by means of group common signalling (L1 or RRC)). This allows the second (neighbouring) RAN node 5-2 that receives the dedicated cell DTX / DRX configuration update message to take this into account appropriately, for example: when determining whether to (further) update an NES configuration (e.g., the cell DTX / DRX configuration) for one or more cells operated by the second RAN node 5-2; and / or when making a handover decision for the UE 3 (e.g., whether or not to handover to a cell of the first RAN node 5-1).

[0138] Specifically, if the activation status associated with the cell DTX / DRX configuration is updated, then the second (neighbouring) RAN node 5-2 receiving the cell DTX / DRX configuration information may consider the cell DTX / DRX configuration as a reference for the purposes of a (further) configuration update or a handover decision (taking the updated activation status into consideration). If, on the other hand, the activation status associated with the cell DTX / DRX configuration is not updated, then the second (neighbouring) RAN node 5-2 receiving the cell DTX / DRX configuration information may make its own decision as to whether to use the received cell DTX / DRX configuration as a reference.

[0139] Accordingly, where group common signalling has been used by the first RAN node 5-1 to implement an activation status update for all or a group of UE's within a given cell then, following the activation status update, the first RAN node 5-1 can send an updated cell DTX / DRX configuration (e.g., including an indication that the activation is updated by group common signalling) to the second RAN node 5-2 (and / or other neighbouring RAN nodes 5) in a dedicated cell DTX / DRX configuration update message as indicated at S812b.

[0140] As seen in Fig. 8, the dedicated cell DTX / DRX configuration update message may optionally include activation status related information. This activation status related information may, for example, include an initial activation status for each UE 3 (e.g., each UE 3 served by a cell that is configured using the associated cell DTX / DRX configuration). This may, for example, be by means of: a list of UE IDs for UEs 3 for which the DTX / DRX configuration is activated (e.g., with those associated with a deactivated mode being implicit); a list of UE IDs for UEs 3 for which the DTX / DRX configuration is deactivated (with those associated with an activated mode being implicit); or a full list of UE IDs for UEs 3 that are configured using the associated cell DTX / DRX configuration together with a separate associated activation status for each UE 3. Each UE ID, for example, may be a TMSI (e.g., an S-TMSI). Nevertheless, the UE ID may be of a type associated with a specific application protocol for the interface between the RAN nodes 5, or associated with the RAN (e.g., a UE XnAP ID or a RAN UE ID). Alternatively, or additionally, the number of UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included. Alternatively, or additionally, the percentage (or, proportion, or fraction) of the UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included.

[0141] The second RAN node 5-2 may acknowledge receipt of the dedicated cell DTX / DRX configuration update message, at S814b, by sending an appropriate dedicated cell DTX / DRX configuration update acknowledge message.

[0142] Cell DTX / DRX activation status exchange (RAN Node to RAN Node Interface) 　　As mentioned above, the communication system 1 is configured to support one or more techniques for inter-node exchange of NES related information between RAN nodes of different RANs. Moreover, as mentioned above the exchanged NES related information may comprise cell DTX / DRX activation status related information.

[0143] As described with reference to the examples illustrated in Fig. 8, the RAN nodes 5 may be configured to be able to, optionally, include cell DTX / DRX activation status related information together with related cell DTX / DRX configuration information in a RAN node configuration update message and / or in a dedicated cell DTX / DRX configuration update message.

[0144] Hence, in a case where group common signalling is used for an activation status update, after the update, the first RAN node 5-1 can send an updated cell DTX / DRX configuration (optionally including the activation status related information) to one or more neighbour RAN nodes 5 as described with reference to Fig. 8.

[0145] Nevertheless, the RAN nodes 5 may additionally (or alternatively) be configured to (only) be able to exchange cell DTX / DRX activation status related information independently of any cell DTX / DRX configuration information using a separate technique / procedure.

[0146] One such independent technique / procedure for exchanging cell DTX / DRX activation status related information between RAN nodes 5 of different RANs will now be described, by way of example only, with reference to Fig. 9, which is a simplified sequence diagram illustrating an inter-node information exchange procedure for cell DTX / DRX activation status related information that may be implemented in the communication system 1.

[0147] In the example illustrated in Fig. 9, the RAN nodes 5 include a first RAN node 5-1 and a second RAN node 5-2 that are interconnected by an appropriate RAN node (base station) to RAN node (base station) interface (e.g., an X2 or Xn interface and / or the like). It will be appreciated that the RAN nodes 5 may each use the same, or a different, one of a 4G, 5G, 6G (or later generations or other) radio access technology.

[0148] As seen in Fig. 9, the RAN nodes 5 are configured to engage in a dedicated cell DTX / DRX activation status update procedure 910.

[0149] As part of the dedicated cell DTX / DRX activation status update procedure 910, the first RAN node 5-1 sends, at S912, the cell DTX / DRX activation status related information to the second RAN node 5-2 in a dedicated cell DTX / DRX activation status update message (e.g., using XnAP signalling, or similar signalling defined by a similar RAN node to RAN node interface application protocol).

[0150] The activation status related information carried by the dedicated cell DTX / DRX activation status update message may, for example, include a list of UE IDs for UEs 3 for which the DTX / DRX configuration activated status has changed, or a full list of UE IDs for UEs 3 that are configured using the associated cell DTX / DRX configuration together with a separate associated activation status for each UE 3. Each UE ID, for example, may be a TMSI (e.g., an S-TMSI). Nevertheless, the UE ID may be of a type associated with a specific application protocol for the interface between the RAN nodes 5, or associated with the RAN (e.g., a UE XnAP ID or a RAN UE ID). Alternatively, or additionally, the number of UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included. Alternatively, or additionally, the percentage (or, proportion, or fraction) of the UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included.

[0151] It will be appreciated that, in a case where a dedicated cell DTX / DRX activation status update procedure is used, after a cell DTX / DRX activation status update at the first RAN node 5-1, the first RAN node 5-1 may store the activation status (and / or related information) at the first RAN node 5-1. The first RAN node 5-1 may be configured to be able to send the associated activation status related information to one or more neighbouring RAN nodes 5 (e.g., the second RAN node 5-2) periodically and / or on demand. For periodic reporting of the activation status related information, the reporting interval may be decided by the first RAN node 5-1 based on for example, an AI / ML inferred prediction result (e.g., an output of the AI / ML model referred to in the description of the examples of Figs. 16 and / or 17).

[0152] Nevertheless, it will be appreciated that whilst a dedicated cell DTX / DRX activation status update procedure (as shown in Fig. 9) is described above for providing updated activation status related information periodically or on demand, alternatively, or additionally, a dedicated cell DTX / DRX configuration update procedure (similar to that shown in Fig. 8) may be used for providing updated activation status related information periodically or on demand (by itself or with an updated cell DTX / DRX configuration).

[0153] The second RAN node 5-2 may acknowledge receipt of the dedicated cell DTX / DRX activation status update message, at S914, by sending an appropriate dedicated cell DTX / DRX activation status update acknowledge message.

[0154] Cell DTX / DRX Configuration Information Exchange (DU to CU Node Interface) 　　As mentioned above, the communication system 1 is configured to support one or more techniques for inter-node exchange of NES related information between different nodes of the same RAN (e.g., between a CU and a DU). Moreover, as mentioned above the exchanged NES related information may comprise cell DTX / DRX configuration information.

[0155] Specifically, in a CU-DU split deployment, if the cell DTX / DRX configuration is decided by the DU itself, the DU may inform the cell DTX / DRX configuration to the CU using an appropriate DU configuration update procedure and / or using a dedicated cell DTX / DRX configuration update procedure.

[0156] A number of techniques / procedures for exchanging cell DTX / DRX configuration information between different nodes of the same RAN (e.g., between a CU and a DU) will now be described, by way of example only, with reference to Fig. 10, which is a simplified sequence diagram illustrating different intra-RAN, inter-node, information exchange procedures for cell DTX / DRX configuration information that may be implemented in the communication system 1.

[0157] In the examples illustrated in Fig. 10, the RAN node 5-2 include a DU 5-2DUand a CU 5-2CUthat are interconnected by an appropriate DU to CU interface (e.g., an F1 interface and / or the like).

[0158] General DU Configuration Update Procedure 　　In a first example illustrated in Fig. 10, the DU 5-2DUand CU 5-2CUare configured to engage in a general DU configuration update procedure 1010a to support the information exchange. This procedure may, for example, be a modified form of a conventional F1 application protocol (F1AP) based gNB-DU configuration update procedure. As those skilled in the art will appreciate, the gNB-DU configuration update configuration procedure is specified for 5G systems, for updating application level configuration data needed for a gNB-DU and a gNB-CU to interoperate correctly on the F1 interface.

[0159] As part of the DU configuration update procedure 1010a, the DU 5-2DUsends, at S1012a, the cell DTX / DRX configuration information to the CU 5-2CUin an appropriate DU configuration update message (for example a gNB-DU configuration update message).

[0160] As seen in Fig. 10, the DU configuration update message may, for example, include a set of cell DTX / DRX related information which is common to a given serving cell such as information indicating: the periodicity; the start slot / offset; the on duration; and the configuration type. It will, nevertheless, be appreciated that the DU configuration update message may include only a subset of one or more of these items of information.

[0161] As seen in Fig. 10, the DU configuration update message may also include, for example, an indication of whether, or not, an activation status associated with the cell DTX / DRX configuration has been updated (by means of group common signalling (L1 or RRC)). This allows the CU 5-2CUthat receives the DU configuration update message to take this into account appropriately, for example when determining whether to (further) update an NES configuration (e.g., the cell DTX / DRX configuration) for one or more cells operated by the RAN node 5-2 that the CU 5-2CUforms part of (e.g., a cell operated via the DU 5-2DUor a cell operated via another DU 5-2DUof the RAN node 5-2). Similarly, the CU 5-2CUthat receives the DU configuration update message may take this into account appropriately when making a handover decision for a UE 3 (e.g., whether or not to handover between cells operated via one or more DUs 5-2DUof the distributed RAN node 5-2).

[0162] Specifically, if the activation status associated with the cell DTX / DRX configuration is updated, then the CU 5-2CUreceiving the cell DTX / DRX configuration information may consider the cell DTX / DRX configuration as a reference for the purposes of a (further) configuration update or a handover decision (taking the updated activation status into consideration). If, on the other hand, the activation status associated with the cell DTX / DRX configuration is not updated, then the CU 5-2CUreceiving the cell DTX / DRX configuration information may make its own decision as to whether to use the received cell DTX / DRX configuration as a reference.

[0163] Accordingly, where group common signalling has been used by the DU 5-2DUto implement an activation status update for all or a group of UEs 3 within a given cell then, following the activation status update, the DU 5-2DUcan send an updated cell DTX / DRX configuration (e.g., including an indication that the activation is updated by group common signalling) to the CU 5-2CUas indicated at S1012a.

[0164] As seen in Fig. 10, the DU configuration update message may optionally include activation status related information. This activation status related information may, for example, include an initial activation status for each UE (e.g., each UE 3 served by a cell that is configured using the associated cell DTX / DRX configuration). This may, for example, be by means of: a list of UE IDs for UEs 3 for which the DTX / DRX configuration is activated (e.g., with those associated with a deactivated mode being implicit); a list of UE IDs for UEs 3 for which the DTX / DRX configuration is deactivated (with those associated with an activated mode being implicit); or a full list of UE IDs for UEs 3 that are configured using the associated cell DTX / DRX configuration together with a separate associated activation status for each UE 3. Each UE ID, for example, may be a temporary mobile subscriber identity (TMSI) - e.g., a serving TMSI (S-TMSI). Nevertheless, the UE ID may be of a type associated with a specific application protocol for the interface between the DU 5-2DUand CU 5-2CU, or associated with the RAN (e.g., a UE F1AP ID or a RAN UE ID). Alternatively, or additionally, the number of UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included. Alternatively, or additionally, the percentage (or, proportion, or fraction) of the UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included.

[0165] The CU 5-2CUmay acknowledge receipt of the DU configuration update message, at S1014a, by sending an appropriate DU configuration update acknowledge message (for example a gNB-DU configuration update acknowledge message).

[0166] Dedicated Cell DTX / DRX Configuration Update Procedure over DU to CU Interface 　　As seen in Fig. 10, in a second example the DU 5-2DUand CU 5-2CUare configured to engage in a dedicated cell DTX / DRX configuration update procedure 1010b.

[0167] As part of the dedicated cell DTX / DRX configuration update procedure 1010b the DU 5-2DUsends, at S1012b, the cell DTX / DRX configuration information to the CU 5-2CUin a dedicated cell DTX / DRX configuration update message (e.g., using F1AP signalling, or similar signalling defined by a similar application protocol).

[0168] As seen in Fig. 10, the dedicated cell DTX / DRX configuration update message may, for example, include a set of cell DTX / DRX related information which is common to a given serving cell such as information indicating: the periodicity; the start slot / offset; the on duration; and the configuration type. It will, nevertheless, be appreciated that the dedicated cell DTX / DRX configuration update message may include only a subset of one or more of these items of information.

[0169] As seen in Fig. 10, the dedicated cell DTX / DRX configuration update message may also include, for example, an indication of whether, or not, an activation status associated with the cell DTX / DRX configuration has been updated (by means of group common signalling (L1 or RRC)). This allows the CU 5-2CUthat receives the dedicated cell DTX / DRX configuration update message to take this into account appropriately, for example when determining whether to (further) update an NES configuration (e.g., the cell DTX / DRX configuration) for one or more cells operated by the RAN node 5-2 that the CU 5-2CUforms part of (e.g., a cell operated via the DU 5-2DUor a cell operated via another DU of the RAN node 5-2). Similarly, the CU 5-2CUthat receives the dedicated cell DTX / DRX configuration update message may take this into account appropriately when making a handover decision for a UE 3 (e.g., whether or not to handover between cells operated via one or more DUs of the distributed RAN node 5-2).

[0170] Specifically, if the activation status associated with the cell DTX / DRX configuration is updated, then the CU 5-2CUreceiving the cell DTX / DRX configuration information may consider the cell DTX / DRX configuration as a reference for the purposes of a (further) configuration update or a handover decision (taking the updated activation status into consideration). If, on the other hand, the activation status associated with the cell DTX / DRX configuration is not updated, then the CU 5-2CUreceiving the cell DTX / DRX configuration information may make its own decision as to whether to use the received cell DTX / DRX configuration as a reference.

[0171] Accordingly, where group common signalling has been used by the DU 5-2DUto implement an activation status update for all or a group of UEs 3 within a given cell then, following the activation status update, the DU 5-2DUcan send an updated cell DTX / DRX configuration (e.g., including an indication that the activation is updated by group common signalling) to the CU 5-2CUas indicated at S1012b.

[0172] As seen in Fig. 10, the dedicated cell DTX / DRX configuration update message may optionally include activation status related information. This activation status related information may, for example, include an initial activation status for each UE 3 (e.g., each UE 3 served by a cell that is configured using the associated cell DTX / DRX configuration). This may, for example, be by means of: a list of UE IDs for UEs 3 for which the DTX / DRX configuration is activated (e.g., with those associated with a deactivated mode being implicit); a list of UE IDs for UEs 3 for which the DTX / DRX configuration is deactivated (with those associated with an activated mode being implicit); or a full list of UE IDs for UEs 3 that are configured using the associated cell DTX / DRX configuration together with a separate associated activation status for each UE 3. Each UE ID, for example, may be a temporary mobile subscriber identity (TMSI) - e.g., a serving TMSI (S-TMSI). Nevertheless, the UE ID may be of a type associated with a specific application protocol for the interface between the DU 5-2DUand CU 5-2CU, or associated with the RAN (e.g., a UE F1AP ID or a RAN UE ID). Alternatively, or additionally, the number of UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included. Alternatively, or additionally, the percentage (or, proportion, or fraction) of the UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included.

[0173] The CU 5-2CUmay acknowledge receipt of the dedicated cell DTX / DRX configuration update message, at S1014b, by sending an appropriate dedicated cell DTX / DRX configuration update acknowledge message.

[0174] Cell DTX / DRX activation status exchange (DU to CU Node Interface) 　　As mentioned above, the communication system 1 is configured to support one or more techniques for inter-node exchange of NES related information between different nodes of the same RAN. Moreover, as mentioned above the exchanged NES related information may comprise cell DTX / DRX activation status related information.

[0175] As described with reference to the examples illustrated in Fig. 10, a DU 5-2DUand a CU 5-2CUmay be configured to be able to, optionally, include cell DTX / DRX activation status related information together with related cell DTX / DRX configuration information in a DU configuration update message and / or in a dedicated cell DTX / DRX configuration update message.

[0176] Hence, in a case where group common signalling is used for an activation status update, after the update, the DU 5-2DUcan send an updated cell DTX / DRX configuration (optionally including the activation status related information) to the CU 5-2CUas described with reference to Fig. 10.

[0177] Nevertheless, the DU 5-2DUand CU 5-2CUmay additionally (or alternatively) be configured to (only) be able to exchange cell DTX / DRX activation status related information independently of any cell DTX / DRX configuration information using a separate technique / procedure.

[0178] One such independent technique / procedure for exchanging cell DTX / DRX activation status related information between the DU 5-2DUand CU 5-2CUwill now be described, by way of example only, with reference to Fig. 11, which is a simplified sequence diagram illustrating an intra-RAN, inter-node, information exchange procedure for cell DTX / DRX activation status related information that may be implemented in the communication system 1.

[0179] In the example illustrated in Fig.11, the RAN node 5-2 include a DU 5-2DUand a CU 5-2CUthat are interconnected by an appropriate DU to CU interface (e.g., an F1 interface and / or the like).

[0180] As seen in Fig. 11, the DU 5-2DUand CU 5-2CUare configured to engage in a dedicated cell DTX / DRX activation status update procedure 1110.

[0181] As part of the dedicated cell DTX / DRX activation status update procedure 1110, the DU 5-2DUsends, at S1112, the cell DTX / DRX activation status related information to the CU 5-2CUin a dedicated cell DTX / DRX activation status update message (e.g., using F1AP signalling, or similar signalling defined by a similar application protocol).

[0182] The activation status related information carried by the dedicated cell DTX / DRX activation status update message may, for example, include a list of UE IDs for UEs 3 for which the DTX / DRX configuration activated status has changed, or a full list of UE IDs for UEs 3 that are configured using the associated cell DTX / DRX configuration together with a separate associated activation status for each UE 3. Each UE ID, for example, may be a TMSI (e.g., an S-TMSI). Nevertheless, the UE ID may be of a type associated with a specific application protocol for the interface between the DU 5-2DUand CU 5-2CU, or associated with the RAN (e.g., a UE F1AP ID or a RAN UE ID) (e.g., a UE F1AP ID or a RAN UE ID). Alternatively, or additionally, the number of UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included. Alternatively, or additionally, the percentage (or, proportion, or fraction) of the UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included.

[0183] It will be appreciated that, in a case where a dedicated cell DTX / DRX activation status update procedure is used, after a cell DTX / DRX activation status update at the DU 5-2DU, the DU 5-2DUmay store the activation status (and / or related information) at the DU 5-2DU. The DU 5-2DUmay be configured to be able to send the associated activation status related information to the CU 5-2CUperiodically and / or on-demand.

[0184] The CU 5-2CUmay acknowledge receipt of the dedicated cell DTX / DRX activation status update message, at S1114, by sending an appropriate dedicated cell DTX / DRX activation status update acknowledge message.

[0185] Cell DTX / DRX Configuration Information Exchange (Dual Connectivity - Master Led) 　　As mentioned above, the communication system 1 is configured to support one or more techniques for inter-node exchange of NES related information between RAN nodes 5 of different RANs, where each RAN node 5 may be configured to operate as a master RAN node 5-1M, or as a secondary RAN node 5-2S, for supporting DC at the UE 3. It will be appreciated that these techniques may include techniques in which the inter-node exchange of NES related information is led by the master RAN node 5-1M. Moreover, as mentioned above the exchanged NES related information may comprise cell DTX / DRX configuration information.

[0186] Specifically, when DC is configured for a UE 3, a Cell DTX / DRX configuration may be sent from the master node 5-1Mto the secondary node 5-2Susing an appropriate secondary RAN node modification request procedure and / or using a dedicated cell DTX / DRX configuration update procedure.

[0187] A number of master RAN node 5-1Mled techniques / procedures for exchanging cell DTX / DRX configuration information between a master RAN node 5-1Mand a secondary RAN node 5-2S, in the context of dual connectivity, will now be described, by way of example only, with reference to Fig. 12, which is a simplified sequence diagram illustrating different master RAN node 5-1Mled inter-node information exchange procedures for cell DTX / DRX configuration information that may be implemented, in the context of dual connectivity, in the communication system 1.

[0188] In the examples illustrated in Fig. 12, the RAN nodes 5 include a master RAN node 5-1Mand a secondary RAN node 5-2Sthat are interconnected by an appropriate RAN node (base station) to RAN node (base station) interface (e.g., an X2 or Xn interface and / or the like). It will be appreciated that the RAN nodes 5 may each use the same, or a different, one of a 4G, 5G, 6G (or later generations or other) radio access technology.

[0189] General Secondary RAN Node Modification Request Procedure (Dual Connectivity) 　　In a first example illustrated in Fig. 12, the master RAN node 5-1Mand the secondary RAN node 5-2Sare configured to engage in a general secondary RAN node modification request procedure 1210a (which may also be referred to as a master RAN node initiated secondary RAN node modification preparation procedure) to support the information exchange. This procedure may, for example, be a modified form of a conventional X2 application protocol (X2AP) based SgNB modification request procedure (also referred to as an 'M-NG-RAN node initiated S-NG-RAN node Modification Preparation' procedure) or a conventional Xn application protocol (XnAP) based S-Node modification request procedure (also referred to as an 'MeNB initiated SgNB Modification Preparation' procedure). As those skilled in the art will appreciate, the SgNB modification request procedure is specified in the context of E-UTRA-NR dual connectivity (EN-DC) between a 4G base station (eNB) operating as a master node 5-1Mand a 5G base station (en-gNB) operating as a secondary node 5-2S. The SgNB modification request procedure is typically used by a master node (eNB) 5-1Mto request a secondary node (en-gNB) 5-2Sto modify the UE context at the secondary node 5-2S, to query a current SCG configuration for supporting delta signalling in a master node initiated secondary node change, or to provide the radio link failure (RLF) related information to the secondary node (en-gNB) 5-2S. Similarly, as those skilled in the art will appreciate, the S-Node modification request procedure is specified in the context of NR-NR dual connectivity (NR-DC) between 5G base stations (NG-RAN nodes) 5 operating as a both master node 5-1Mand secondary node 5-2S. The S-Node modification request procedure is typically used by a master NG RAN node (M-NG-RAN node) 5-1Mto request a secondary NG RAN node (S-NG-RAN node) 5-2Sto modify the UE context at the secondary node 5-2S, to query a current SCG configuration for supporting delta signalling in a master NG RAN node initiated secondary NG RAN node change, or to provide the radio link failure (RLF) related information to the secondary node (NG RAN node) 5-2S.

[0190] As part of the secondary RAN node modification request procedure 1210a, the master RAN node 5-1Msends, at S1212a, the cell DTX / DRX configuration information to the secondary RAN node 5-2Sin an appropriate secondary RAN node modification request message (for example, an SgNB modification request or an S-Node modification request message).

[0191] As seen in Fig. 12, the secondary RAN node modification request message may, for example, include a set of cell DTX / DRX related information which is common to a given serving cell such as information indicating: the periodicity; the start slot / offset; the on duration; and the configuration type. It will, nevertheless, be appreciated that the secondary RAN node modification request message may include only a subset of one or more of these items of information.

[0192] As seen in Fig. 12, the secondary RAN node modification request message may also include, for example, an indication of whether, or not, an activation status associated with the cell DTX / DRX configuration has been updated (by means of group common signalling (L1 or RRC)). This allows the secondary RAN node 5-2Sthat receives the secondary RAN node modification request message to take this into account appropriately, for example when determining whether to (further) update an NES configuration (e.g., the cell DTX / DRX configuration) for one or more cells operated by the secondary RAN node 5-2S.

[0193] Specifically, if the activation status associated with the cell DTX / DRX configuration is updated, then the secondary RAN node 5-2Sreceiving the cell DTX / DRX configuration information may consider the cell DTX / DRX configuration as a reference for the purposes of a (further) configuration update for one or more cells of the SCG. If, on the other hand, the activation status associated with the cell DTX / DRX configuration is not updated, then the secondary RAN node 5-2Sreceiving the cell DTX / DRX configuration information may make its own decision as to whether to use the received cell DTX / DRX configuration as a reference.

[0194] Accordingly, where group common signalling has been used by the master RAN node 5-1Mto implement an activation status update for all or a group of UEs 3 within a given cell then, following the activation status update, the master RAN node 5-1Mcan send an updated cell DTX / DRX configuration (e.g., including an indication that the activation is updated by group common signalling) to the secondary RAN node 5-2Sas indicated at S1212a.

[0195] As seen in Fig. 12, the secondary RAN node modification request may optionally include activation status related information. This activation status related information may, for example, include an initial activation status for each UE 3 (e.g., each UE 3 served by a cell that is configured using the associated cell DTX / DRX configuration). This may, for example, be by means of: a list of UE IDs for UEs 3 for which the DTX / DRX configuration is activated (e.g., with those associated with a deactivated mode being implicit); a list of UE IDs for UEs 3 for which the DTX / DRX configuration is deactivated (with those associated with an activated mode being implicit); or a full list of UE IDs for UEs 3 that are configured using the associated cell DTX / DRX configuration together with a separate associated activation status for each UE 3. Each UE ID, for example, may be a temporary mobile subscriber identity (TMSI) - e.g., a serving TMSI (S-TMSI). Nevertheless, the UE ID may be of a type associated with a specific application protocol for the interface between the master RAN node 5-1Mand the secondary RAN node 5-2S, or associated with the RAN (e.g., a UE XnAP ID or a RAN UE ID). Alternatively, or additionally, the number of UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included. Alternatively, or additionally, the percentage (or, proportion, or fraction) of the UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included.

[0196] The secondary RAN node 5-2Smay acknowledge receipt of the secondary RAN node modification request, at S1214a, by sending an appropriate secondary RAN node modification request acknowledge message (for example an SgNB modification request acknowledge message or S-Node modification request acknowledge message).

[0197] Dedicated Cell DTX / DRX Configuration Update Procedure (Dual Connectivity - Master Led) 　　In a second example illustrated in Fig. 12, the master RAN node 5-1Mand the secondary RAN node 5-2Sare mutually configured to engage in a dedicated cell DTX / DRX configuration update procedure 1210b.

[0198] As part of the dedicated cell DTX / DRX configuration update procedure 1210b, the master RAN node 5-1Msends, at S1212b, the cell DTX / DRX configuration information to the secondary RAN node 5-2Sin a dedicated cell DTX / DRX configuration update message (e.g., using XnAP signalling, or similar signalling defined by a similar RAN node to RAN node interface application protocol).

[0199] As seen in Fig. 12, the dedicated cell DTX / DRX configuration update message may, for example, include a set of cell DTX / DRX related information which is common to a given serving cell such as information indicating: the periodicity; the start slot / offset; the on duration; and the configuration type. It will, nevertheless, be appreciated that the dedicated cell DTX / DRX configuration update message may include only a subset of one or more of these items of information.

[0200] As seen in Fig. 12, the dedicated cell DTX / DRX configuration update message may also include, for example, an indication of whether, or not, an activation status associated with the cell DTX / DRX configuration has been updated (by means of group common signalling (L1 or RRC)). This allows the secondary RAN node 5-2Sthat receives the dedicated cell DTX / DRX configuration update message to take this into account appropriately, for example: when determining whether to (further) update an NES configuration (e.g., the cell DTX / DRX configuration) for one or more cells operated by the secondary RAN node 5-2S; and / or when making a decision to modify the SCG for a UE 3.

[0201] Specifically, if the activation status associated with the cell DTX / DRX configuration is updated, then the secondary RAN node 5-2Sreceiving the cell DTX / DRX configuration information may consider the cell DTX / DRX configuration as a reference for the purposes of a (further) configuration update for one or more cells of the SCG or a decision to start a secondary RAN node initiated procedure to change the SCG (taking the updated activation status into consideration), e.g., via a secondary RAN node modification procedure / SCG change procedure with the master RAN node 5-1M. If, on the other hand, the activation status associated with the cell DTX / DRX configuration is not updated, then the secondary RAN node 5-2Sreceiving the cell DTX / DRX configuration information may make its own decision as to whether to use the received cell DTX / DRX configuration as a reference.

[0202] Accordingly, where group common signalling has been used by the master RAN node 5-1Mto implement an activation status update for all or a group of UEs 3 within a given cell then, following the activation status update, the master RAN node 5-1Mcan send an updated cell DTX / DRX configuration (e.g., including an indication that the activation is updated by group common signalling) to the secondary RAN node 5-2S(and / or other neighbouring RAN nodes 5) in a dedicated cell DTX / DRX configuration update message as indicated at S1212b.

[0203] As seen in Fig. 12, the dedicated cell DTX / DRX configuration update message may optionally include activation status related information. This activation status related information may, for example, include an initial activation status for each UE 3 (e.g., each UE 3 served by a cell that is configured using the associated cell DTX / DRX configuration). This may, for example, be by means of: a list of UE IDs for UEs 3 for which the DTX / DRX configuration is activated (e.g., with those associated with a deactivated mode being implicit); a list of UE IDs for UEs 3 for which the DTX / DRX configuration is deactivated (with those associated with an activated mode being implicit); or a full list of UE IDs for UEs 3 that are configured using the associated cell DTX / DRX configuration together with a separate associated activation status for each UE 3. Each UE ID, for example, may be a TMSI (e.g., an S-TMSI). Nevertheless, the UE ID may be of a type associated with a specific application protocol for the interface between the master RAN node 5-1Mand the secondary RAN node 5-2S, or associated with the RAN (e.g., a UE XnAP ID or a RAN UE ID). Alternatively, or additionally, the number of UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included. Alternatively, or additionally, the percentage (or, proportion, or fraction) of the UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included.

[0204] The secondary RAN node 5-2Smay acknowledge receipt of the dedicated cell DTX / DRX configuration update message, at S1214b, by sending an appropriate dedicated cell DTX / DRX configuration update acknowledge message.

[0205] Cell DTX / DRX activation status exchange (Dual Connectivity - Master Led) 　　As mentioned above, the communication system 1 is configured to support one or more techniques for inter-node exchange of NES related information between RAN nodes 5 of different RANs, where each RAN node 5 may be configured to operate as a master RAN node 5-1M, or as a secondary RAN node 5-2S, for supporting DC at the UE 3. It will be appreciated that these techniques may include techniques in which the inter-node exchange of NES related information is led by the master RAN node 5-1M. Moreover, as mentioned above the exchanged NES related information may comprise cell DTX / DRX activation status related information.

[0206] Specifically, when DC is configured for a UE 3, a Cell DTX / DRX configuration may be sent from the secondary node 5-2Sto the master node 5-1Musing an appropriate secondary RAN node modification required procedure and / or using a dedicated cell DTX / DRX configuration update procedure. For example, as described with reference to the examples illustrated in Fig. 12, a master RAN node 5-1Mand a secondary RAN node 5-2Smay be configured to be able to, optionally, include cell DTX / DRX activation status related information together with related cell DTX / DRX configuration information in a RAN node configuration update message and / or in a dedicated cell DTX / DRX configuration update message.

[0207] Hence, in a case where group common signalling is used for an activation status update, after the update, the master RAN node 5-1Mcan send an updated cell DTX / DRX configuration (optionally including the activation status related information) to one or more secondary RAN nodes 5-2Sas described with reference to Fig. 12.

[0208] Nevertheless, the master RAN node 5-1Mand the secondary RAN node 5-2Smay additionally (or alternatively) be configured to (only) be able to exchange cell DTX / DRX activation status related information independently of any cell DTX / DRX configuration information using a separate technique / procedure.

[0209] One master RAN node 5-1Mled independent technique / procedure for exchanging cell DTX / DRX activation status related information between the master RAN node 5-1Mand the secondary RAN node 5-2Swill now be described, by way of example only, with reference to Fig. 13, which is a simplified sequence diagram illustrating a master RAN node 5-1Mled inter-node information exchange procedure for cell DTX / DRX activation status related information that may be implemented in the communication system 1. In the example illustrated in Fig. 13, the RAN nodes 5 include a master RAN node 5-1Mand a secondary RAN node 5-2Sthat are interconnected by an appropriate RAN node (base station) to RAN node (base station) interface (e.g., an X2 or Xn interface and / or the like). It will be appreciated that the RAN nodes 5 may each use the same, or a different, one of a 4G, 5G, 6G (or later generations or other) radio access technology.

[0210] As seen in Fig. 13, the master RAN node 5-1Mand the secondary RAN node 5-2Sare configured to engage in a master RAN node 5-1Mled dedicated cell DTX / DRX activation status update procedure 1310.

[0211] As part of the dedicated cell DTX / DRX activation status update procedure 1310, the master RAN node 5-1Msends, at S1312, the cell DTX / DRX activation status related information to the secondary RAN node 5-2Sin a dedicated cell DTX / DRX activation status update message (e.g., using XnAP signalling, or similar signalling defined by a similar RAN node to RAN node interface application protocol).

[0212] The activation status related information carried by the dedicated cell DTX / DRX activation status update message may, for example, include a list of UE IDs for UEs 3 for which the DTX / DRX configuration activated status has changed, or a full list of UE IDs for UEs 3 that are configured using the associated cell DTX / DRX configuration together with a separate associated activation status for each UE 3. Each UE ID, for example, may be a TMSI (e.g., an S-TMSI). Nevertheless, the UE ID may be of a type associated with a specific application protocol for the interface between the master RAN node 5-1Mand the secondary RAN node 5-2S, or associated with the RAN (e.g., a UE XnAP ID or a RAN UE ID). Alternatively, or additionally, the number of UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included. Alternatively, or additionally, the percentage (or, proportion, or fraction) of the UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included.

[0213] It will be appreciated that, in a case where a dedicated cell DTX / DRX activation status update procedure is used, after a cell DTX / DRX activation status update at the master RAN node 5-1M, the master RAN node 5-1Mmay store the activation status (and / or related information) at the master RAN node 5-1M. The master RAN node 5-1Mmay be configured to be able to send the associated activation status related information to one or more secondary RAN nodes 5-2Speriodically and / or on-demand. For periodic reporting of the activation status related information, the reporting interval may be decided by the master RAN node 5-1Mbased on for example, an AI / ML inferred prediction result (e.g., an output of the AI / ML model referred to in the description of the examples of Figs. 16 and / or 17).

[0214] Nevertheless, it will be appreciated that whilst a dedicated cell DTX / DRX activation status update procedure (as shown in Fig. 13) is described above for providing updated activation status related information periodically or on-demand, alternatively, or additionally, a dedicated cell DTX / DRX configuration update procedure (similar to that shown in Fig. 12) may be used for providing updated activation status related information periodically or on-demand (by itself or with an updated cell DTX / DRX configuration).

[0215] The secondary RAN node 5-2Smay acknowledge receipt of the dedicated cell DTX / DRX activation status update message, at S1314, by sending an appropriate dedicated cell DTX / DRX activation status update acknowledge message.

[0216] Cell DTX / DRX Configuration Information Exchange (Dual Connectivity - Secondary Led) 　　As mentioned above, the communication system 1 is configured to support one or more techniques for inter-node exchange of NES related information between RAN nodes 5 of different RANs, where each RAN node 5 may be configured to operate as a master RAN node 5-1M, or as a secondary RAN node 5-2S, for supporting DC at the UE 3. It will be appreciated that these techniques may include techniques in which the inter-node exchange of NES related information is led by the secondary RAN node 5-2S. Moreover, as mentioned above the exchanged NES related information may comprise cell DTX / DRX configuration information.

[0217] A number of master RAN node 5-1Mled techniques / procedures for exchanging cell DTX / DRX configuration information between a master RAN node 5-1Mand a secondary RAN node 5-2S, in the context of dual connectivity, will now be described, by way of example only, with reference to Fig. 14, which is a simplified sequence diagram illustrating different secondary RAN node 5-2Sled inter-node information exchange procedures for cell DTX / DRX configuration information that may be implemented, in the context of dual connectivity, in the communication system 1.

[0218] In the examples illustrated in Fig. 14, the RAN nodes 5 include a master RAN node 5-1Mand a secondary RAN node 5-2Sthat are interconnected by an appropriate RAN node (base station) to RAN node (base station) interface (e.g., an X2 or Xn interface and / or the like). It will be appreciated that the RAN nodes 5 may each use the same, or a different, one of a 4G, 5G, 6G (or later generations or other) radio access technology.

[0219] General Secondary RAN Node Modification Required Procedure (Dual Connectivity) 　　In a first example illustrated in Fig. 14, the master RAN node 5-1Mand the secondary RAN node 5-2Sare configured to engage in a general secondary RAN node modification required procedure 1410a (which may also be referred to as a secondary RAN node initiated secondary RAN node modification procedure) to support the information exchange. This procedure may, for example, be a modified form of a conventional X2 application protocol (X2AP) based SgNB modification required procedure (also referred to as an 'SgNB initiated SgNB Modification' procedure) or a conventional Xn application protocol (XnAP) based S-Node modification required procedure (also referred to as an 'S-NG-RAN node initiated S-NG-RAN node Modification' procedure). As those skilled in the art will appreciate, the SgNB modification required procedure is specified in the context of E-UTRA-NR dual connectivity (EN-DC) between a 4G base station (eNB) operating as a master node 5-1Mand a 5G base station (en-gNB) operating as a secondary node 5-2S. The SgNB modification required procedure is typically used by a secondary node (en-gNB) 5-2Sto modify the UE context at the secondary node 5-2S. Similarly, as those skilled in the art will appreciate, the S-Node modification required procedure is specified in the context of NR-NR dual connectivity (NR-DC) between 5G base stations (NG-RAN nodes) 5 operating as a both master node 5-1Mand secondary node 5-2S. The S-Node modification required procedure is typically used by a secondary node (NG RAN node (S-NG-RAN node)) 5-2Sto modify the UE context at the secondary node 5-2S.

[0220] As part of the secondary RAN node modification required procedure 1410a, the secondary RAN node 5-2Ssends, at S1412a, the cell DTX / DRX configuration information to the master RAN node 5-1Min an appropriate secondary RAN node modification required message (for example, an SgNB modification required message or an S-Node modification required message).

[0221] As seen in Fig. 14, the secondary RAN node modification required message may, for example, include a set of cell DTX / DRX related information which is common to a given serving cell such as information indicating: the periodicity; the start slot / offset; the on duration; and the configuration type. It will, nevertheless, be appreciated that the secondary RAN node modification required message may include only a subset of one or more of these items of information.

[0222] As seen in Fig. 14, the secondary RAN node modification required message may also include, for example, an indication of whether, or not, an activation status associated with the cell DTX / DRX configuration has been updated (by means of group common signalling (L1 or RRC)). This allows the master RAN node 5-1Mthat receives the secondary RAN node modification required message to take this into account appropriately, for example when determining whether to (further) update an NES configuration (e.g., the cell DTX / DRX configuration) for one or more cells operated by the master RAN node 5-1M.

[0223] Specifically, if the activation status associated with the cell DTX / DRX configuration is updated, then the master RAN node 5-1Mreceiving the cell DTX / DRX configuration information may consider the cell DTX / DRX configuration as a reference for the purposes of a (further) configuration update for one or more cells of the MCG. If, on the other hand, the activation status associated with the cell DTX / DRX configuration is not updated, then the master RAN node 5-1Mreceiving the cell DTX / DRX configuration information may make its own decision as to whether to use the received cell DTX / DRX configuration as a reference.

[0224] Accordingly, where group common signalling has been used by the secondary RAN node 5-2Sto implement an activation status update for all or a group of UEs 3 within a given cell then, following the activation status update, the secondary RAN node 5-2Scan send an updated cell DTX / DRX configuration (e.g., including an indication that the activation is updated by group common signalling) to the master RAN node 5-1Mas indicated at S1412a.

[0225] As seen in Fig. 14, the secondary RAN node modification required message may optionally include activation status related information. This activation status related information may, for example, include an initial activation status for each UE 3 (e.g., each UE 3 served by a cell that is configured using the associated cell DTX / DRX configuration). This may, for example, be by means of: a list of UE IDs for UEs 3 for which the DTX / DRX configuration is activated (e.g., with those associated with a deactivated mode being implicit); a list of UE IDs for UEs 3 for which the DTX / DRX configuration is deactivated (with those associated with an activated mode being implicit); or a full list of UE IDs for UEs 3 that are configured using the associated cell DTX / DRX configuration together with a separate associated activation status for each UE 3. Each UE ID, for example, may be a temporary mobile subscriber identity (TMSI) - e.g., a serving TMSI (S-TMSI). Nevertheless, the UE ID may be of a type associated with a specific application protocol for the interface between the master RAN node 5-1Mand the secondary RAN node 5-2S, or associated with the RAN (e.g., a UE XnAP ID or a RAN UE ID). Alternatively, or additionally, the number of UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included. Alternatively, or additionally, the percentage (or, proportion, or fraction) of the UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included.

[0226] If the master RAN node 5-1Mis able to perform a change requested by the secondary RAN node modification required message sent by the secondary RAN node 5-2S, then the master RAN node 5-1Mmay confirm this, at S1414a, by sending an appropriate secondary RAN node modification confirm message (for example an SgNB modification confirm message or S-Node modification confirm message).

[0227] Dedicated Cell DTX / DRX Configuration Update Procedure (Dual Connectivity - Secondary Led) 　　In a second example illustrated in Fig. 14, the secondary RAN node 5-2Sand the master RAN node 5-1Mare mutually configured to engage in a dedicated cell DTX / DRX configuration update procedure 1410b.

[0228] As part of the dedicated cell DTX / DRX configuration update procedure 1410b, the secondary RAN node 5-2Ssends, at S1412b, the cell DTX / DRX configuration information to the master RAN node 5-1Min a dedicated cell DTX / DRX configuration update message (e.g., using XnAP signalling, or similar signalling defined by a similar RAN node to RAN node interface application protocol).

[0229] As seen in Fig. 14, the dedicated cell DTX / DRX configuration update message may, for example, include a set of cell DTX / DRX related information which is common to a given serving cell such as information indicating: the periodicity; the start slot / offset; the on duration; and the configuration type. It will, nevertheless, be appreciated that the dedicated cell DTX / DRX configuration update message may include only a subset of one or more of these items of information.

[0230] As seen in Fig. 14, the dedicated cell DTX / DRX configuration update message may also include, for example, an indication of whether, or not, an activation status associated with the cell DTX / DRX configuration has been updated (by means of group common signalling (L1 or RRC)). This allows the master RAN node 5-1Mthat receives the dedicated cell DTX / DRX configuration update message to take this into account appropriately, for example: when determining whether to (further) update an NES configuration (e.g., the cell DTX / DRX configuration) for one or more cells operated by the secondary RAN node 5-2S; and / or when making a handover decision and / or a decision to modify the MCG for a UE 3.

[0231] Specifically, if the activation status associated with the cell DTX / DRX configuration is updated, then master RAN node 5-1Mreceiving the cell DTX / DRX configuration information may consider the cell DTX / DRX configuration as a reference for the purposes of a (further) configuration update for one or more cells of the MCG, or a handover decision, or a decision to change the MCG (taking the updated activation status into consideration). If, on the other hand, the activation status associated with the cell DTX / DRX configuration is not updated, then the master RAN node 5-1Mreceiving the cell DTX / DRX configuration information may make its own decision as to whether to use the received cell DTX / DRX configuration as a reference.

[0232] Accordingly, where group common signalling has been used by the secondary RAN node 5-2Sto implement an activation status update for all or a group of UEs 3 within a given cell then, following the activation status update, the secondary RAN node 5-2Scan send an updated cell DTX / DRX configuration (e.g., including an indication that the activation is updated by group common signalling) to the master RAN node 5-1M(and / or other neighbouring RAN nodes 5) in a dedicated cell DTX / DRX configuration update message as indicated at S1412b.

[0233] As seen in Fig. 14, the dedicated cell DTX / DRX configuration update message may optionally include activation status related information. This activation status related information may, for example, include an initial activation status for each UE 3 (e.g., each UE 3 served by a cell that is configured using the associated cell DTX / DRX configuration). This may, for example, be by means of: a list of UE IDs for UEs 3 for which the DTX / DRX configuration is activated (e.g., with those associated with a deactivated mode being implicit); a list of UE IDs for UEs 3 for which the DTX / DRX configuration is deactivated (with those associated with an activated mode being implicit); or a full list of UE IDs for UEs 3 that are configured using the associated cell DTX / DRX configuration together with a separate associated activation status for each UE 3. Each UE ID, for example, may be a TMSI (e.g., an S-TMSI). Nevertheless, the UE ID may be of a type associated with a specific application protocol for the interface between the master RAN node 5-1Mand the secondary RAN node 5-2S, or associated with the RAN (e.g., a UE XnAP ID or a RAN UE ID). Alternatively, or additionally, the number of UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included. Alternatively, or additionally, the percentage (or, proportion, or fraction) of the UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included.

[0234] The master RAN node 5-1Mmay acknowledge receipt of the dedicated cell DTX / DRX configuration update message, at S1414b, by sending an appropriate dedicated cell DTX / DRX configuration update acknowledge message.

[0235] Cell DTX / DRX activation status exchange (Dual Connectivity - Secondary Led) 　　As mentioned above, the communication system 1 is configured to support one or more techniques for inter-node exchange of NES related information between RAN nodes 5 of different RANs, where each RAN node 5 may be configured to operate as a master RAN node 5-1M, or as a secondary RAN node 5-2S, for supporting DC at the UE 3. It will be appreciated that these techniques may include techniques in which the inter-node exchange of NES related information is led by the secondary RAN node 5-2S. Moreover, as mentioned above the exchanged NES related information may comprise cell DTX / DRX activation status related information.

[0236] For example, as described with reference to the examples illustrated in Fig. 14, a master RAN node 5-1Mand a secondary RAN node 5-2Smay be configured to be able to, optionally, include cell DTX / DRX activation status related information together with related cell DTX / DRX configuration information in a RAN node configuration update message and / or in a dedicated cell DTX / DRX configuration update message.

[0237] Hence, in a case where group common signalling is used for an activation status update, after the update, the secondary RAN node 5-2Scan send an updated cell DTX / DRX configuration (optionally including the activation status related information) to one or more master RAN nodes 5-1Mas described with reference to Fig. 14.

[0238] Nevertheless, the master RAN node 5-1Mand the secondary RAN node 5-2Smay additionally (or alternatively) be configured to (only) be able to exchange cell DTX / DRX activation status related information independently of any cell DTX / DRX configuration information using a separate technique / procedure.

[0239] One secondary RAN node 5-2Sled independent technique / procedure for exchanging cell DTX / DRX activation status related information between the secondary RAN node 5-2Sand the master RAN node 5-1Mwill now be described, by way of example only, with reference to Fig. 15, which is a simplified sequence diagram illustrating a secondary RAN node 5-2Sled inter-node information exchange procedure for cell DTX / DRX activation status related information that may be implemented in the communication system 1.

[0240] In the example illustrated in Fig. 15, the RAN nodes 5 include a master RAN node 5-1Mand a secondary RAN node 5-2Sthat are interconnected by an appropriate RAN node (base station) to RAN node (base station) interface (e.g., an X2 or Xn interface and / or the like). It will be appreciated that the RAN nodes 5 may each use the same, or a different, one of a 4G, 5G, 6G (or later generations or other) radio access technology.

[0241] As seen in Fig. 15, the master RAN node 5-1Mand the secondary RAN node 5-2Sare configured to engage in a master RAN node 5-1Mled dedicated cell DTX / DRX activation status update procedure 1510.

[0242] As part of the dedicated cell DTX / DRX activation status update procedure 1510 the secondary RAN node 5-2Ssends, at S1512, the cell DTX / DRX activation status related information to the master RAN node 5-1Min a dedicated cell DTX / DRX activation status update message (e.g., using XnAP signalling, or similar signalling defined by a similar RAN node to RAN node interface application protocol).

[0243] The activation status related information carried by the dedicated cell DTX / DRX activation status update message may, for example, include a list of UE IDs for UEs 3 for which the DTX / DRX configuration activated status has changed, or a full list of UE IDs for UEs 3 that are configured using the associated cell DTX / DRX configuration together with a separate associated activation status for each UE 3. Each UE ID, for example, may be a TMSI (e.g., an S-TMSI). Nevertheless, the UE ID may be of a type associated with a specific application protocol for the interface between the master RAN node 5-1Mand the secondary RAN node 5-2S, or associated with the RAN (e.g., a UE XnAP ID or a RAN UE ID). Alternatively, or additionally, the number of UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included. Alternatively, or additionally, the percentage (or, proportion, or fraction) of the UEs 3 that are configured with an activated (or deactivated) mode DTX / DRX configuration may be optionally included.

[0244] It will be appreciated that, in a case where a dedicated cell DTX / DRX activation status update procedure is used, after a cell DTX / DRX activation status update at the secondary RAN node 5-2S, the secondary RAN node 5-2Smay store the activation status (and / or related information) at the secondary RAN node 5-2S. The secondary RAN node 5-2Smay be configured to be able to send the associated activation status related information to the master RAN node 5-1Mperiodically and / or on-demand. For periodic reporting of the activation status related information, the reporting interval may be decided by the secondary RAN node 5-2Sbased on for example, an AI / ML inferred prediction result (e.g., an output of the AI / ML model referred to in the description of the examples of Figs. 16 and / or 17).

[0245] Nevertheless, it will be appreciated that whilst a dedicated cell DTX / DRX activation status update procedure (as shown in Fig. 15) is described above for providing updated activation status related information periodically or on-demand, alternatively, or additionally, a dedicated cell DTX / DRX configuration update procedure (similar to that shown in Fig. 14) may be used for providing updated activation status related information periodically or on-demand (by itself or with an updated cell DTX / DRX configuration).

[0246] The master RAN node 5-1Mmay acknowledge receipt of the dedicated cell DTX / DRX activation status update message, at S1514, by sending an appropriate dedicated cell DTX / DRX activation status update acknowledge message.

[0247] AI / ML enhanced procedure for performing NES actions 　　As mentioned above, the communication system 1 may also support one or more AI / ML enhanced procedures for performing NES actions at a first RAN node based on cell DTX / DRX related information received from another RAN node 5.

[0248] In one such procedure, for example, the first RAN node 5 beneficially performs an NES related action based on a cell DTX / DRX configuration inferred, by an AI / ML model that is deployed at the first RAN node 5 but that was trained elsewhere, based on the cell DTX / DRX related information received from another RAN node 5. In another such procedure, for example, the first RAN node 5 beneficially performs an NES related action based on a cell DTX / DRX configuration inferred, by an AI / ML model that is deployed at the first RAN node 5 and that was also trained at the first RAN node 5, based on the cell DTX / DRX related information received from another RAN node 5.

[0249] The AI / ML model may take as input, for example, cell DTX / DRX related information including, for example, a respective cell DTX / DRX activation status of each serving cell and / or each of one or more neighbouring cells. The AI / ML model may be trained, for example, to provide, based on the input, an output including predicted or inferred cell DTX / DRX parameters to be applied (e.g., including an on duration timer value, a cycle start offset, a slot offset value, a configuration type, an activation status, and / or an activation status reporting interval (e.g., as described with reference to the earlier examples)). Following application of the predicted or inferred cell DTX / DRX parameters at by a given RAN node 5, that RAN node 5 may generate appropriate feedback for allowing refinement / optimisation of the AI / ML model. The feedback may include an indication of issues that have arisen (or are predicted will arise) as a result of applying the predicted or inferred cell DTX / DRX parameters such as, for example, interference issue, a coverage hole, a UE handover failure (e.g., due to attempted handover during a cell DTX / DRX off cycle).

[0250] A first possible AI / ML enhanced procedure will now be described, by way of example only, with reference to Fig. 16, which is a simplified sequence diagram illustrating an AI / ML enhanced procedure for performing NES actions at one RAN node 5 based on cell DTX / DRX related information from another RAN node 5 that may be implemented in the communication system 1.

[0251] In the example illustrated in Fig. 16, the RAN nodes 5 include a first RAN node 5-1 and a second RAN node 5-2 that are interconnected by an appropriate RAN node (base station) to RAN node (base station) interface (e.g., an X2 or Xn interface and / or the like). It will be appreciated that the RAN nodes 5 may each use the same, or a different, one of a 4G, 5G, 6G (or other) radio access technology. In this example an OAM 14 is also involved in the procedure.

[0252] As seen in Fig. 16, at S1600, the second RAN node 5-2 may have an (optional) AI / ML model, which is able to provide can provide the OAM 14 with information that may be used as an input for inference by an AI / ML deployed at the first RAN node 5-1.

[0253] Initially the first RAN node 5-1 sends a measurement configuration message to the UE 3, at S1602, that contains measurement configuration information for configuring the UE 3 to perform measurements (and / or acquire other relevant information) and to perform associated measurement reporting. The measurement configuration information may include, for example, information for configuring the UE 3 to record and report cell DTX / DRX information for each serving cell and / or one or more neighbouring cells.

[0254] The UE 3 performs, at S1604, one or more configured measurements and / or acquires the other relevant cell DTX / DRX related information (e.g., cell DTX / DRX activation status of the UE 3 for each serving cell and / or one or more neighbouring cells). The UE 3 reports, at S1606, the one or more measurement results and / or the other acquired relevant cell DTX / DRX related information, in one or more appropriate messages (e.g., measurement reports) to the first RAN node 5-1 including the cell DTX / DRX related information for each serving cell and / or one or more neighbouring cells.

[0255] At S1608, the first RAN node 5-1 sends, to the OAM 14, at least a subset of the measurement results and / or other cell DTX / DRX related information reported by the UE 3, including the cell DTX / DRX information for each serving cell and / or one or more neighbouring cells, for use as inputs for AI / ML model training.

[0256] In this example, the second RAN node 5-2 (which may also, optionally, have an AI / ML model 1500) also sends, at S1610, cell DTX / DRX related information (e.g., cell DTX / DRX activation status of the UEs 3 for one or more cells (serving and / or neighbouring) provided by the second RAN node 5-2) to the OAM 14 for the purposes of AI / ML model training.

[0257] Other information, for example, interference information, coverage information, UE Trajectory information (which may be provided by the first RAN node 5-1, by the second RAN node 5-2, and / or acquired from elsewhere) may additionally (or alternatively) be used as an AI / ML model training input.

[0258] The OAM 14 uses the received cell DTX / DRX related information (e.g., activation status of the UEs) from the first RAN node 5-1 and / or the second RAN node 5-2 for AI / ML model training at S1612. Once the AI / ML model is appropriately trained the OAM deploys the trained AI / ML model (or provides an update for a previously deployed AI / ML model) at S1614.

[0259] The second RAN node 5-2 sends, at S1616, a cell DTX / DRX configuration to the first RAN node 5-1 for use as input data to the deployed / updated AI / ML model at the first RAN node 5-1 for the purposes of model inference of AI / ML-based network energy saving related information (e.g., of a cell DTX / DRX configuration to be deployed at the first RAN node 5-1). The UE 3 may also send, at S1618, a measurement report, to the first RAN node 5-1, carrying the results of measurements (e.g., of reference signals or the like) in respect of the serving and / or neighbouring cells. It will be appreciated that these measurement results (and / or information derived from them by the first RAN node 5-1) may also be used as inputs for the purposes of inference.

[0260] At S1620, based on local input data acquired at the first RAN node 5-1 and received inputs from the second RAN node 5-2, the first RAN node 5-1 generates a model inference output (e.g., a predicted / inferred optimal cell DTX / DRX configuration).

[0261] The first RAN node 5-1 may send, at S1622, model performance feedback to the OAM 14 (if applicable) for the purposes of monitoring the performance of the AI / ML model at the OAM 14.

[0262] At S1624, the first RAN node 5-1 performs an appropriate network energy saving action based on the model inference output (e.g., updating the cell DTX / DRX configuration based on the inferred cell DTX / DRX configuration).

[0263] Appropriate feedback may be provided, to the OAM 14, by the second RAN node 5-2 (at S1626) and / or the first RAN node 5-1 and (at S1628), to be used for optimising the performance of the AI / ML model. The feedback may, for example, identify one or more issues associated with implementation of the inferred cell DTX / DRX configuration such as, for example, an interference issue, a coverage hole, and / or a UE handover failure (e.g., due to attempted handover during a cell DTX / DRX off cycle).

[0264] It will be appreciated that the cell DTX / DRX configuration may include any of the information described earlier (e.g., including an on duration timer value, a cycle start offset, a slot offset value, a configuration type, an activation status, and / or an activation status reporting interval).

[0265] It will be appreciated that whilst the OAM 14 in the example of Fig. 16 perform model training, and the first RAN node 5-1 performs model inference, the OAM 14 may be a central node for both model training and the model inference.

[0266] A second possible AI / ML enhanced procedure will now be described, by way of example only, with reference to Fig. 17, which is a simplified sequence diagram illustrating another AI / ML enhanced procedure for performing NES actions at one RAN node 5 based on cell DTX / DRX related information from another RAN node 5 that may be implemented in the communication system 1.

[0267] As seen in Fig. 17, at S1700, the second RAN node 5-2 may have an (optional) AI / ML model, which is able to provide can provide the first RAN node 5-1 with information that may be used as an input for inference at an AI / ML model deployed at the first RAN node 5-1.

[0268] As seen in Fig. 17 initially a first RAN node 5-1 sends a measurement configuration message to the UE 3, at S1702, that contains measurement configuration information for configuring the UE 3 to perform measurements (and / or acquire other relevant information) and to perform associated measurement reporting. The measurement configuration information may include, for example, information for configuring the UE 3 to record and report cell DTX / DRX information for each serving cell and / or one or more neighbouring cells.

[0269] The UE 3 performs, at S1704, one or more configured measurements and / or acquires the other relevant information (e.g., cell DTX / DRX activation status of each serving cell and / or one or more neighbouring cells. The UE 3 reports, at S1706, the one or more measurement results and / or the other acquired relevant information, in one or more appropriate messages (e.g., measurement reports) to the first RAN node 5-1 including the cell DTX / DRX information for each serving cell and / or one or more neighbouring cells.

[0270] At S1708, the second RAN node 5-2 sends cell DTX / DRX related information (e.g., cell DTX / DRX activation status of the UEs 3 for one or more cells provided by the second RAN node 5-2) to the first RAN node 5-1or the purposes of AI / ML model training for AI / ML-based network energy saving. Other information, for example, interference information, coverage information, UE Trajectory information (which may be provided by the second RAN node 5-2 or acquired from elsewhere) may additionally (or alternatively) be used as an AI / ML model training input.

[0271] The first RAN node 5-1 then trains, at S1710 the AI / ML model (e.g., to infer a cell DTX / DRX configuration) based on at least a subset of the received data from UE 3 and / or second RAN node 5-2. It will be appreciated that the second RAN node 5-2 may also have an AI / ML model for inferring a cell DTX / DRX configuration, which can also generate predicted results / actions.

[0272] At S1712, the second RAN node 5-2 may send the required input data (e.g., cell DTX / DRX information) to the first RAN node 5-2 for input to the AI / ML model for inference of a cell DTX / DRX configuration.

[0273] The UE 3 may also send, at S1714, a measurement report, to the first RAN node 5-1, carrying the results of measurements (e.g., of reference signals or the like) in respect of the serving and / or neighbouring cells. It will be appreciated that these measurement results (and / or information derived from them by the first RAN node 5-1) may also be used as inputs for the purposes of inference.

[0274] At S1716, based on local input data acquired at the first RAN node 5-1 and received inputs from the second RAN node 5-2, the first RAN node 5-1 generates a model inference output (e.g., a predicted / inferred optimal cell DTX / DRX configuration).

[0275] At S1718, the first RAN node 5-1 performs an appropriate network energy saving action based on the model inference output (e.g., updating the cell DTX / DRX configuration based on the inferred cell DTX / DRX configuration).

[0276] Appropriate feedback may be provided, first RAN node 5-1, by the second RAN node 5-2 at S1720, to be used for optimising the performance of the AI / ML model. The feedback may, for example, identify one or more issues associated with implementation of the inferred cell DTX / DRX configuration such as, for example, an interference issue, a coverage hole, and / or a UE handover failure (e.g., due to attempted handover during a cell DTX / DRX off cycle).

[0277] NES Mode Information Exchange (RAN Node to RAN Node Interface) 　　As mentioned above, the communication system 1 is configured to support one or more techniques for inter-node exchange of NES related information between RAN nodes 5 of different RANs. Moreover, as mentioned above the exchanged NES related information may comprise NES mode information, for example information identifying an NES mode or state associated with a cell of the RAN node 5 providing the information, and / or other NES mode related information.

[0278] A number of techniques / procedures for exchanging information identifying an NES mode or state associated with a cell between RAN nodes 5 of different RANs will now be described, by way of example only, with reference to Fig. 18, which is a simplified sequence diagram illustrating different inter-node information exchange procedures for NES mode information that may be implemented in the communication system 1.

[0279] In the examples illustrated in Fig. 18, the RAN nodes 5 include a first RAN node 5-1 and a second RAN node 5-2 that are interconnected by an appropriate RAN node (base station) to RAN node (base station) interface (e.g., an X2 or Xn interface and / or the like). It will be appreciated that the RAN nodes 5 may each use the same, or a different, one of a 4G, 5G, 6G (or other) radio access technology.

[0280] It will be appreciated that by exchanging the NES mode information, whenever mobility is triggered (e.g., cell (re)selection by a UE 3 in idle / inactive mode and / or handover to a cell of another RAN node 5), the NES mode of the target cell can beneficially be taken into consideration, for example to avoid a UE 3 (successfully) selecting cells engaged in NES in an NES mode (or one or more particular NES modes) when there is another (e.g., more suitable non-NES) cell available.

[0281] General RAN Node Configuration Update Procedure 　　In a first example illustrated in Fig. 18, the RAN nodes 5 are configured to engage in a general RAN node configuration update procedure 1810a to support the information exchange. This procedure may, for example, be a modified form of a conventional Xn application protocol (XnAP) based NG-RAN node configuration update procedure. As those skilled in the art will appreciate, the NG-RAN node configuration update procedure is specified for 5G systems, for updating application level configuration data needed for two NG-RAN nodes (e.g., gNBs) to interoperate correctly over the Xn control plane (Xn-C) interface.

[0282] As part of the RAN node configuration update procedure 1810a the first RAN node 5-1 sends, at S1812a, the NES mode information to the second RAN node 5-2 in an appropriate RAN node configuration update message (for example an NG-RAN node configuration update message).

[0283] As seen in Fig. 18, the RAN node configuration update message may, for example, be configurable to include NES mode related information indicating that NES (or a particular type of NES) for a cell is either 'on' or 'off'. Alternatively (or additionally), the RAN node configuration update message may, for example, be configurable to include NES mode related information indicating a specific sleep level (or 'sleep state') for a cell, for example a sleep level from among the following set of options: a deep sleep; a light sleep; micro sleep; active downlink; for active uplink. It will, nevertheless, be appreciated that the sleep level may be selected from any suitable set of options for example a selected subset of the set of options described in the previous sentence, or a larger set including additional options depending on requirements. Alternatively (or additionally), the RAN node configuration update message may, for example, be configurable to include NES mode related information indicating a SIB1 transmission status for a cell, e.g. that SIB1-less transmission is configured, or that on-demand SIB1 transmission is configured (or possibly that conventional SIB1 transmission is configured).

[0284] The second RAN node 5-2 may acknowledge receipt of the RAN node configuration update message, at S1814a, by sending an appropriate RAN node configuration update acknowledge message (for example an NG-RAN node configuration update acknowledge message).

[0285] Dedicated NES mode Update Procedure over RAN Node to RAN Node Interface 　　In a second example illustrated in Fig. 18, the RAN nodes 5 are configured to engage in a dedicated NES mode update procedure 1810b.

[0286] As part of the dedicated NES mode update procedure 1810b, the first RAN node 5-1 sends, at S1812b, the NES mode information to the second RAN node 5-2 in a dedicated NES mode update message (e.g., using XnAP signalling, or similar signalling defined by a similar RAN node to RAN node interface application protocol).

[0287] As seen in Fig. 18, the dedicated NES mode update message may, for example, be configurable to include NES mode related information indicating that NES (or a particular type of NES) for a cell is either 'on' or 'off'. Alternatively (or additionally), the NES mode update message may, for example, be configurable to include NES mode related information indicating a specific sleep level (or 'sleep state') for a cell, for example a sleep level from among the following set of options: a deep sleep; a light sleep; micro sleep; active downlink; for active uplink. It will, nevertheless, be appreciated that the sleep level may be selected from any suitable set of options for example a selected subset of the set of options described in the previous sentence, or a larger set including additional options depending on requirements. Alternatively (or additionally), the NES mode update message may, for example, be configurable to include NES mode related information indicating a SIB1 transmission status for a cell, e.g. that SIB1-less transmission is configured, or that on-demand SIB1 transmission is configured (or possibly that conventional SIB1 transmission is configured).

[0288] The second RAN node 5-2 may acknowledge receipt of the dedicated NES mode update message, at S1814b, by sending an appropriate dedicated NES mode update acknowledge message.

[0289] NES mode Information Exchange (DU to CU Node Interface) 　　As mentioned above, the communication system 1 is configured to support one or more techniques for inter-node exchange of NES related information between different nodes of the same RAN (e.g., between a CU and a DU). Moreover, as mentioned above the exchanged NES related information may comprise NES mode information.

[0290] Specifically, in a CU-DU split deployment, if the NES mode is decided by the DU itself, the DU may inform the NES mode to the CU using an appropriate DU configuration update procedure and / or using a dedicated NES mode update procedure.

[0291] A number of techniques / procedures for exchanging NES mode information between different nodes of the same RAN (e.g., between a CU and a DU) will now be described, by way of example only, with reference to Fig. 19, which is a simplified sequence diagram illustrating different intra-RAN, inter-node, information exchange procedures for NES mode information that may be implemented in the communication system 1.

[0292] In the examples illustrated in Fig. 19, the RAN node 5-2 include a DU 5-2DUand a CU 5-2CUthat are interconnected by an appropriate DU to CU interface (e.g., an F1 interface and / or the like).

[0293] General DU Configuration Update Procedure 　　In a first example illustrated in Fig. 19, the DU 5-2DUand CU 5-2CUare configured to engage in a general DU configuration update procedure 1910a to support the information exchange. This procedure may, for example, be a modified form of a conventional F1 application protocol (F1AP) based gNB-DU configuration update procedure. As those skilled in the art will appreciate, the gNB-DU configuration update configuration procedure is specified for 5G systems, for updating application level configuration data needed for a gNB-DU and a gNB-CU to interoperate correctly on the F1 interface.

[0294] As part of the DU configuration update procedure 1910a the DU 5-2DUsends, at S1912a, the NES mode information to the CU 5-2CUin an appropriate DU configuration update message (for example a gNB-DU configuration update message).

[0295] As seen in Fig. 19, the dedicated DU configuration update message may, for example, be configurable to include NES mode related information indicating that NES (or a particular type of NES) for a cell is either 'on' or 'off'. Alternatively (or additionally), the DU configuration update message may, for example, be configurable to include NES mode related information indicating a specific sleep level (or 'sleep state') for a cell, for example a sleep level from among the following set of options: a deep sleep; a light sleep; micro sleep; active downlink; for active uplink. It will, nevertheless, be appreciated that the sleep level may be selected from any suitable set of options for example a selected subset of the set of options described in the previous sentence, or a larger set including additional options depending on requirements. Alternatively (or additionally), the DU configuration update message may, for example, be configurable to include NES mode related information indicating a SIB1 transmission status for a cell, e.g. that SIB1-less transmission is configured, or that on-demand SIB1 transmission is configured (or possibly that conventional SIB1 transmission is configured).

[0296] The CU 5-2CUmay acknowledge receipt of the DU configuration update message, at S1914a, by sending an appropriate DU configuration update acknowledge message (for example a gNB-DU configuration update acknowledge message).

[0297] Dedicated NES mode Update Procedure over DU to CU Interface 　　As seen in Fig. 19, in a second example the DU 5-2DUand CU 5-2CUare configured to engage in a dedicated NES mode update procedure 1910b.

[0298] As part of the dedicated NES mode update procedure 1910b, the DU 5-2DUsends, at S1912b, the NES mode information to the CU 5-2CUin a dedicated NES mode update message (e.g., using F1AP signalling, or similar signalling defined by a similar application protocol).

[0299] As seen in Fig. 19, the dedicated NES mode update message may, for example, be configurable to include NES mode related information indicating that NES (or a particular type of NES) for a cell is either 'on' or 'off'. Alternatively (or additionally), the NES mode update message may, for example, be configurable to include NES mode related information indicating a specific sleep level (or 'sleep state') for a cell, for example a sleep level from among the following set of options: a deep sleep; a light sleep; micro sleep; active downlink; for active uplink. It will, nevertheless, be appreciated that the sleep level may be selected from any suitable set of options for example a selected subset of the set of options described in the previous sentence, or a larger set including additional options depending on requirements. Alternatively (or additionally), the NES mode update message may, for example, be configurable to include NES mode related information indicating a SIB1 transmission status for a cell, e.g. that SIB1-less transmission is configured, or that on-demand SIB1 transmission is configured (or possibly that conventional SIB1 transmission is configured).

[0300] The CU 5-2CUmay acknowledge receipt of the NES mode update message, at S1914b, by sending an appropriate NES mode update acknowledge message.

[0301] WUS Configuration Information Exchange (RAN Node to RAN Node Interface) 　　As mentioned above, the communication system 1 is configured to support one or more techniques for inter-node exchange of NES related information between RAN nodes of different RANs. Moreover, as mentioned above, the exchanged NES related information may comprise WUS configuration information for configuring an uplink WUS, and the WUS configuration information may comprise an enhanced WUS configuration for configuring a UE 3 (that supports such a WUS) with the time and / or frequency location that the UE 3 may use to attempt to request on-demand SSBs and / or SIB1s.

[0302] The enhanced WUS configuration may take any of number of different forms and may form part of a modified existing WUS configuration element (e.g., as illustrated in Fig. 5), albeit that the WUS configuration information in this case is for an uplink WUS rather than a downlink WUS. It will also be appreciated that the enhanced WUS configuration may form part of a stand-alone dedicated information element for configuring the uplink WUS for on-demand SSBs and / or SIB1s.

[0303] A simplified example of an ASN.1 representation of a first possible implementation of the relevant information elements of an enhanced WUS configuration information element / field for specifying the uplink WUS configuration is provided below by way of example only: WUS-Config-r19::= SEQUENCE { … cellDTXDRXConfig-r18　　　　OPTIONAL, freqLocation-19 　　　　　　enumerated {n1, n2, n3, n4, spare} timeoffset-cellDRX-r19 　　　　INTEGER (0…cellDTXDRXOnDuration}, / / time offset 　　　　　　　　　　relative to start of cell DRX active duration }

[0304] As seen in this first possible implementation, the WUS configuration may, optionally, include a relevant cell DTX / DRX configuration (labelled 'cellDTXDRXConfig-r18' in this example). Moreover, the WUS configuration includes information identifying a frequency location for the WUS (labelled 'freqLocation-19' in this example). The frequency location in this example is indicated by means of a value taken from the set (n1,n2, n3, n4), which effectively selects a frequency location from a PRACH / PUCCH frequency configuration. Moreover, the WUS configuration includes information identifying a time location for for the WUS by means, in this example, of a time offset relative to start of cell DRX active duration (labelled 'timeoffset-cellDRX-r19' in this example) where the value of the time offset is less than a cell DTX / DRX on duration.

[0305] A simplified example of an ASN.1 representation of a second possible implementation of the relevant information elements of an enhanced WUS configuration information element / field for specifying the WUS configuration is provided below by way of example only: WUS-Config-r19::= SEQUENCE { … cellDTXDRXConfig-r18　　　　OPTIONAL, freqLocation-19 　　　　　　enumerated {n1, n2, n3, n4, spare} timeLocation-cellDRX-r19 　　　　enumerated {n0, n1, n2, n3, spare} , / / time occasion from start of cell DRX active duration }

[0306] As seen in this second possible implementation, the WUS configuration may, optionally, include a relevant cell DTX / DRX configuration (labelled 'cellDTXDRXConfig-r18' in this example). Moreover, the WUS configuration includes information identifying a frequency location for the WUS (labelled 'freqLocation-19' in this example). The frequency location in this example is indicated by means of a value taken from the set (n1,n2, n3, n4), which effectively selects a frequency location from a PRACH / PUCCH frequency configuration. Moreover, the WUS configuration includes information identifying a time location for for the WUS by means, in this example, of an information element (labelled 'timeLocation-cellDRX-r19' in this example) having a value taken from the set (n0, n1,n2, n3), which effectively specifies a specific UE transmit occasion (e.g., 1st, 2nd, 3rd , 4th) or the like from the start of a cell DRX active duration.

[0307] A simplified example of an ASN.1 representation of a third possible implementation of the relevant information elements of an enhanced WUS configuration information element / field for specifying the WUS configuration is provided below by way of example only: WUS-Config-r19::= SEQUENCE { … cellDTXDRXConfig-r18　　　　OPTIONAL, Wus-RACH-ConfigCommon　　OPTIONAL, Wus-PUCCH-ConfigCommon OPTIONAL, PCI-ID　　　　　　　　　　INTEGER 　　 / / Cell ID }

[0308] As seen in this third possible implementation, the WUS configuration may, optionally, include a relevant cell DTX / DRX configuration (labelled 'cellDTXDRXConfig-r18' in this example). Moreover, the WUS configuration may, optionally, include information identifying a specific PRACH configuration for the WUS (labelled 'Wus-RACH-ConfigCommon' in this example). The WUS configuration may also, optionally, include information identifying a specific PUCCH configuration for the WUS (labelled 'Wus-PUCCH-ConfigCommon' in this example). The WUS configuration may also include a physical cell identifier (PCI-ID) for the corresponding cell.

[0309] A number of techniques / procedures for exchanging information identifying a WUS configuration associated with a cell between RAN nodes 5 of different RANs will now be described, by way of example only, with reference to Fig. 20, which is a simplified sequence diagram illustrating different inter-node information exchange procedures for WUS configuration information that may be implemented in the communication system 1.

[0310] In the examples illustrated in Fig. 20, the RAN nodes 5 include a first RAN node 5-1 and a second RAN node 5-2 that are interconnected by an appropriate RAN node (base station) to RAN node (base station) interface (e.g., an X2 or Xn interface and / or the like). It will be appreciated that the RAN nodes 5 may each use the same, or a different, one of a 4G, 5G, 6G (or other) radio access technology.

[0311] It will be appreciated that by exchanging the WUS configuration information, the receiving RAN node 5-2 (e.g., in a coverage layer for the UE 3) may send the received WUS configuration to UEs 3 for a transmitting RAN node 5-1 that is engaged in NES in an NES mode.

[0312] General RAN Node Configuration Update Procedure 　　In a first example illustrated in Fig. 20, the RAN nodes 5 are configured to engage in a general RAN node configuration update procedure 2010a to support the information exchange. This procedure may, for example, be a modified form of a conventional Xn application protocol (XnAP) based NG-RAN node configuration update procedure. As those skilled in the art will appreciate, the NG-RAN node configuration update procedure is specified for 5G systems, for updating application level configuration data needed for two NG-RAN nodes (e.g., gNBs) to interoperate correctly over the Xn control plane (Xn-C) interface.

[0313] As part of the RAN node configuration update procedure 2010a the first RAN node 5-1 sends, at S2012a, the WUS configuration to the second RAN node 5-2 in an appropriate RAN node configuration update message (for example an NG-RAN node configuration update message).

[0314] As seen in Fig. 20, the RAN node configuration update message may, for example, be configurable to include the WUS configuration indicating, for example: the frequency location; the time location; and / or the cell DTX / DRX configuration (e.g., using one of the enhanced WUS configurations described above or the like).

[0315] The second RAN node 5-2 may acknowledge receipt of the RAN node configuration update message, at S2014a, by sending an appropriate RAN node configuration update acknowledge message (for example an NG-RAN node configuration update acknowledge message).

[0316] RAN Node to RAN Node Interface Application Protocol (AP) based Setup Procedure 　　In a second example illustrated in Fig. 20, the RAN nodes 5 are configured to engage in a RAN node to RAN node interface AP based setup procedure 2010b. In the illustrated example the procedure is an XnAP based procedure over the Xn interface, but it could be another similar AP based procedure (e.g., and X2AP based procedure or other RAN node to RAN node interface AP based procedure).

[0317] As part of the dedicated RAN node to RAN node interface AP based setup procedure 2010b the first RAN node 5-1 sends, at S2012b, the WUS configuration to the second RAN node 5-2 in a RAN node to RAN node interface AP setup request message (e.g., using an XnAP based Xn Setup Request as shown, or similar signalling defined by a similar RAN node to RAN node interface AP).

[0318] As seen in Fig. 20, the RAN node to RAN node interface AP setup request message may, for example, be configurable to include the WUS configuration indicating, for example: the frequency location; the time location; and / or the cell DTX / DRX configuration (e.g., using one of the enhanced WUS configurations described above or the like).

[0319] The second RAN node 5-2 may respond to the RAN node to RAN node interface AP setup request message, at S2014b, by sending an appropriate RAN node to RAN node interface AP setup response message (e.g., using an XnAP based Xn Setup Response as shown, or similar signalling defined by a similar RAN node to RAN node interface AP).

[0320] Dedicated WUS configuration Update Procedure over RAN Node to RAN Node Interface 　　In a third example illustrated in Fig. 20, the RAN nodes 5 are configured to engage in a dedicated WUS configuration update procedure 2010c.

[0321] As part of the dedicated WUS configuration update procedure 2010c the first RAN node 5-1 sends, at S2012c, the WUS configuration to the second RAN node 5-2 in a dedicated WUS configuration update message (e.g., using XnAP signalling, or similar signalling defined by a similar RAN node to RAN node interface application protocol).

[0322] As seen in Fig. 20, the dedicated WUS configuration update message may, for example, be configurable to include the WUS configuration indicating, for example: the frequency location; the time location; and / or the cell DTX / DRX configuration (e.g., using one of the enhanced WUS configurations described above or the like).

[0323] The second RAN node 5-2 may acknowledge receipt of the dedicated WUS configuration update message, at S2014c, by sending an appropriate dedicated WUS configuration update acknowledge message.

[0324] User Equipment 　　Fig. 21 is a schematic block diagram illustrating the main components of a UE 3 as shown in Fig. 1.

[0325] As shown, the UE 3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a RAN node 5 via one or more antennas 33 (e.g., comprising one or more antenna elements). The UE 3 has a controller 37 to control the operation of the UE 3. The controller 37 is associated with a memory 39 and is coupled to the transceiver circuit 31. Although not necessarily required for its operation, the UE 3 might, of course, have all the usual functionality of a conventional UE 3 (e.g., a user interface 35, such as a touch screen / keypad / microphone / speaker and / or the like for, allowing direct control by and interaction with a user) and this may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 39 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

[0326] The controller 37 is configured to control overall operation of the UE 3 by, in this example, program instructions or software instructions stored within memory 39. As shown, these software instructions include, among other things, an operating system 41, and a communications control module 43.

[0327] The communication control module 43 is operable to control the communication between the UE 3 and its serving RAN node or RAN nodes 5-1 (and other communication devices connected to the RAN node 5-1, such as further UEs and / or core network nodes). The communication control module 43 is configured for the overall handling of uplink communications via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), random access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 43 is also configured for the overall handling of receipt of downlink communications via associated downlink channels (e.g., of DCI via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-persistent scheduling (e.g., SPS). The communication control module 43 is responsible, for example: for determining where to monitor for downlink control information; for determining the resources to be used by the UE 3 for transmission / reception of UL / DL communications (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the UE side; for determining how slots / symbols are configured (e.g., for UL, DL or full duplex communication, or the like); for determining which bandwidth parts are configured for the UE 3; for determining how uplink transmissions should be encoded and the like.

[0328] It will be appreciated that the communication control module 43 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 43 may include a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an RRC sub-module, etc.

[0329] The communication control module 43 is configured, in particular, to control the UE's communications, where applicable, in accordance with any of the methods described herein.

[0330] RAN node (non-distributed) 　　Fig. 22 is a schematic block diagram illustrating the main components of a RAN node 5-1 for the communication system 1 shown in Fig. 1. As shown, the RAN node 5-1 has a transceiver circuit 51 for transmitting signals to and for receiving signals from the communication devices (such as UEs 3) via one or more antennas 53 (e.g. a single or multi-panel antenna array / massive antenna), and a core network interface 55 (e.g. comprising the N2, N3 and other reference points / interfaces) for transmitting signals to and for receiving signals from network nodes in the core network 7. Although not shown, the RAN node 5-1 may also be coupled to other RAN nodes via an appropriate interface (e.g. the so-called 'Xn' interface in NR). The RAN node 5-1 has a controller 57 to control the operation of the RAN node 5-1. The controller 57 is associated with a memory 59. Software may be pre-installed in the memory 59 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The controller 57 is configured to control the overall operation of the RAN node 5-1 by, in this example, program instructions or software instructions stored within memory 59.

[0331] As shown, these software instructions include, among other things, an operating system 61, and a communications control module 63.

[0332] The communications control module 63 is operable to control the communication between the RAN node 5-1 and UEs 3 and other network entities that are connected to the RAN node 5-1. The communications control module 63 is configured for the overall control of the reception and decoding of uplink communications, via associated uplink channels (e.g. via a physical uplink control channel (PUCCH), a random-access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communications control module 63 is also configured for the overall handling the transmission of downlink communications via associated downlink channels (e.g. via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-static signalling (e.g., CSI-RS, SSBs etc.). The communications control module 63 is also responsible, for example, for determining and scheduling the resources to be used by the UE 3 for receiving in DL / transmitting in UL, for configuring slots / symbols appropriately (e.g., for UL, DL, flexible, full duplex communication, or the like), for configuring one or more bandwidth parts for the UE 3, and for providing related configuration signalling to the UE 3.

[0333] It will be appreciated that the communications control module 63 may include a number of sub-modules (or 'layers') to support specific functionalities. For example, the communications control module 63 may include a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an SDAP sub-module, an IP sub-module, an RRC sub-module, etc.

[0334] The communication control module 63 is configured, in particular, to control the RAN node's communications, where applicable, in accordance with any of the methods described herein.

[0335] RAN node (distributed) 　　Fig. 23 is a simplified block schematic illustrating the main components of a distributed RAN node 5-2 comprising a distributed type of base station for implementation in the system of Fig. 1. As shown, the RAN node 5-2 includes a central unit (CU) 5-2CUand a distributed unit (DU) 5-2DU(although it may include other DUs as described above). Each unit 5-2CU, 5-2DUincludes respective transceiver circuitry 51c, 51d.

[0336] The transceiver circuitry 51d of the distributed unit 5-2DUis operable to transmit signals to and to receive signals from UEs 3 via an air interface 53d and one or more antennas and is also operable to transmit signals to and to receive signals from the central unit 5-2CUvia an interface, for example the distributed unit side of an F1 interface (which may be provided over a satellite radio interface).

[0337] The transceiver circuitry 51c of the central unit 5-2CUis operable to transmit signals to and to receive signals from functions of the core network 7 and / or other RAN nodes via a network interface 55c. The network interface typically includes an N1, N2 and / or N3 interfaces for communicating with the core network and a RAN node to RAN node (e.g. Xn) interface for communicating with other RAN nodes. The transceiver circuitry 51c of the central unit 5-2CUis also operable to transmit signals to and to receive signals from one or more distributed units 5-2DU, for example the central unit side of the F1 interface provided.

[0338] Each unit 5-2CU, 5-2DUincludes a respective controller 57c, 57d which controls the operation of the corresponding transceiver circuitry 51c, 51d in accordance with software stored in the respective memories 59c and 59d of the central unit 5-2CUand the distributed unit 5-2CU. The software of each unit may be pre-installed in the memory 59c, 59d and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The software of each unit includes, among other things, a respective operating system 61c, 61d, and a respective communications control module 63c, 63d.

[0339] Each communications control module 63c, 63d is operable to control the communication of its corresponding unit 5-2CU, 5-2DUincluding the communication from one unit to the other. The communications control module 63d of the distributed unit 5-2DUcontrols communication between the distributed unit 5-2DUand the UEs 3, and the communications control module 63c of the central unit 5-2CUcontrols communication between the central unit 5-2CUand other network entities that are connected to the distributed RAN 5-2.

[0340] The communications control modules 63c, 63d also respectively control the part played by the central unit 5-2CUand distributed unit 5-2DUin the flow of uplink and downlink user traffic and control data to be received from and transmitted to the communications devices served by the RAN node 5-2 including, for example, control data for managing operation of the UEs 3. Each communication control module 63c, 63d is responsible, for example, for controlling the respective part played by the central unit 5-2CUand distributed unit 5-2DUin the reception and decoding of uplink communications, via associated uplink channels (e.g. via a physical uplink control channel (PUCCH), a random-access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). Each communication control module 63c, 63d is responsible, for example, for controlling the respective part played by the central unit 5-2CUand distributed unit 5-2DUin the overall handling the transmission of downlink communications via associated downlink channels (e.g. via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-static signalling (e.g., CSI-RS, SSBs etc.). Each communication control module 63c, 63d is responsible, for example, for controlling the respective part played by the central unit 5-2CUand distributed unit 5-2DUin determining and scheduling the resources to be used by the UE 3 for receiving in DL / transmitting in UL, for configuring slots / symbols appropriately (e.g., for UL, DL, flexible, full duplex communication, or the like), for configuring one or more bandwidth parts for the UE 3, and for providing related configuration signalling to the UE 3.

[0341] It will be appreciated that each communication control module 63c, 63d may include a number of sub-modules (or 'layers') to support specific functionalities supported by the by the central unit 5-2CUand distributed unit 5-2DU. For example, a communications PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an SDAP sub-module, an IP sub-module, an RRC sub-module, etc may be distributed between the central unit 5-2CUand distributed unit 5-2DUappropriately depending on where the functional split is configured between the central unit 5-2CUand distributed unit 5-2DU.

[0342] Each communication control module 63c, 63d is configured, in particular, to control the respective communications of the central unit 5-2CUand distributed unit 5-2DU, where applicable, in accordance with any of the methods described herein.

[0343] Modifications and Alternatives 　　As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above embodiments whilst still benefiting from the disclosure embodied therein.

[0344] Whilst above examples have been described with reference to an AI / ML model, it will be appreciated that the above described methods are advantageous even when the model is not an AI / ML model. Any other suitable type of model or function may be used to generate inferences (e.g. determinations or predictions).

[0345] It will be appreciated, for example, that whilst cellular communication generation (2G, 3G, 4G, 5G, 6G etc.) specific terminology may be used, in the interests of clarity, to refer to specific communication entities, the technical features described for a given entity are not limited to devices of that specific communication generation. The technical features may be implemented in any functionally equivalent communication entity regardless of any differences in the terminology used to refer to them.

[0346] In the above description, the UEs and the RAN nodes are described for ease of understanding as having a number of discrete functional components or modules. Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the disclosure, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities.

[0347] In the above example embodiments, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied as a signal over a computer network, or on a recording medium. Further, the functionality performed by part, or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the RAN node or the UE in order to update their functionalities.

[0348] Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input / output (IO) circuits; internal memories / caches (program and / or data); processing registers; communication buses (e.g. control, data and / or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and / or timers; and / or the like. Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0349] The User Equipment (or "UE", "mobile station", "mobile device" or "wireless device") in the present disclosure is an entity connected to a network via a wireless interface.

[0350] It should be noted that the present disclosure is not limited to a dedicated communication device and can be applied to any device having a communication function as explained in the following paragraphs.

[0351] The terms "User Equipment" or "UE" (as the term is used by 3GPP), "mobile station", "mobile device", and "wireless device" are generally intended to be synonymous with one another, and include standalone mobile stations, such as terminals, cell phones, smart phones, tablets, cellular IoT devices, IoT devices, and machinery. It will be appreciated that the terms "mobile station" and "mobile device" also encompass devices that remain stationary for a long period of time.

[0352] A UE may, for example, be an item of equipment for production or manufacture and / or an item of energy related machinery (for example equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal power generators; nuclear electricity generators; batteries; nuclear systems and / or associated equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; oil hydraulic equipment; pneumatic equipment; metal working machinery; manipulators; robots and / or their application systems; tools; molds or dies; rolls; conveying equipment; elevating equipment; materials handling equipment; textile machinery; sewing machines; printing and / or related machinery; paper converting machinery; chemical machinery; mining and / or construction machinery and / or related equipment; machinery and / or implements for agriculture, forestry and / or fisheries; safety and / or environment preservation equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubricating equipment; valves; pipe fittings; and / or application systems for any of the previously mentioned equipment or machinery etc.).

[0353] A UE may, for example, be an item of transport equipment (for example transport equipment such as: rolling stocks; motor vehicles; motorcycles; bicycles; trains; buses; carts; rickshaws; ships and other watercraft; aircraft; rockets; satellites; drones; balloons etc.). A UE may, for example, be an item of information and communication equipment (for example information and communication equipment such as: electronic computer and related equipment; communication and related equipment; electronic components etc.).

[0354] A UE may, for example, be a refrigerating machine, a refrigerating machine applied product, an item of trade and / or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, a consumer electronic and electronic appliance (for example a consumer electronic appliance such as: audio equipment; video equipment; a loud speaker; a radio; a television; a microwave oven; a rice cooker; a coffee machine; a dishwasher; a washing machine; a dryer; an electronic fan or related appliance; a cleaner etc.).

[0355] A UE may, for example, be an electrical application system or equipment (for example an electrical application system or equipment such as: an x-ray system; a particle accelerator; radio isotope equipment; sonic equipment; electromagnetic application equipment; electronic power application equipment etc.).

[0356] A UE may, for example, be an electronic lamp, a luminaire, a measuring instrument, an analyser, a tester, or a surveying or sensing instrument (for example a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.), a watch or clock, a laboratory instrument, optical apparatus, medical equipment and / or system, a weapon, an item of cutlery, a hand tool, or the like.

[0357] A UE may, for example, be a wireless-equipped personal digital assistant or related equipment (such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).

[0358] A UE may be a device or a part of a system that provides applications, services, and solutions described below, as to "internet of things (IoT)", using a variety of wired and / or wireless communication technologies.

[0359] Internet of Things devices (or "things") may be equipped with appropriate electronics, software, sensors, network connectivity, and / or the like, which enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may comprise automated equipment that follow software instructions stored in an internal memory. IoT devices may operate without requiring human supervision or interaction. IoT devices might also remain stationary and / or inactive for a long period of time. IoT devices may be implemented as a part of a (generally) stationary apparatus. IoT devices may also be embedded in non-stationary apparatus (e.g. vehicles) or attached to animals or persons to be monitored / tracked.

[0360] It will be appreciated that IoT technology can be implemented on any communication devices that can connect to a communication system for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0361] It will be appreciated that IoT devices are sometimes also referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices. It will be appreciated that a UE may support one or more IoT or MTC applications. Some examples of MTC applications are listed in the following table. This list is not exhaustive and is intended to be indicative of some examples of machine type communication applications.

[0362] Applications, services, and solutions may be an MVNO (Mobile Virtual Network Operator) service, an emergency radio communication system, a PBX (Private Branch eXchange) system, a PHS / Digital Cordless Telecommunications system, a POS (Point of sale) system, an advertise calling system, an MBMS (Multimedia Broadcast and Multicast Service), a V2X (Vehicle to Everything) system, a train radio system, a location related service, a Disaster / Emergency Wireless Communication Service, a community service, a video streaming service, a femto cell application service, a VoLTE (Voice over LTE) service, a charging service, a radio on-demand service, a roaming service, an activity monitoring service, a telecom carrier / communication NW selection service, a functional restriction service, a PoC (Proof of Concept) service, a personal information management service, an ad-hoc network / DTN (Delay Tolerant Networking) service, etc.

[0363] Further, the above-described UE categories are merely examples of applications of the technical ideas and example embodiments described in the present document. Needless to say, these technical ideas and example embodiments are not limited to the above-described UE and various modifications can be made thereto.

[0364] Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0365] For example, the whole or part of the exemplary embodiments disclosed above can be described as, but not limited to, the following supplementary notes. 　　　　(Supplementary note 1) 　　A method performed by a first access network node, the method comprising: 　　transmitting, to a second access network node, information for network energy saving (NES) configuration at the first access network node, wherein 　　the information for the NES configuration is used by the second access network node for cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration or handover configuration at the second access network node. 　　　　(Supplementary note 2) 　　The method according to supplementary note 1, wherein 　　the information for the NES configuration includes information for wakeup signal (WUS) configuration, and 　　the information for the WUS configuration is sent to a mobile device. 　　　　(Supplementary note 3) 　　The method according to supplementary note 2, wherein 　　the information for the WUS configuration includes at least one of: 　　　　information for a location on a frequency domain used for a WUS, 　　　　information for a location on a time domain used for the WUS, or 　　　　information for cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration at the first access network node. 　　　　(Supplementary note 4) 　　The method according to supplementary note 3, wherein 　　the information for the location on the time domain includes a time offset relative to start of cell DRX active duration. 　　　　(Supplementary note 5) 　　The method according to any one of supplementary notes 1 to 4, wherein 　　the information for the NES configuration includes information for cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration at the first access network node, 　　the information for the cell DRX / DTX configuration includes at least one of: 　　　　information for a periodicity of cell DRX / DTX, 　　　　information for a location on a time domain for the cell DRX / DTX, or 　　　　information for a configuration type which is common per serving cell. 　　　　(Supplementary note 6) 　　The method according to supplementary note 5, wherein 　　the information for the NES configuration includes indication information indicating whether an activation status of the cell DRX / DTX is updated by a group common signaling, and 　　the indication information is used by the second access network node for determining to use the activation status for cell DRX / DTX or handover decision at the second access network node. 　　　　(Supplementary note 7) 　　The method according to supplementary note 5 or 6, wherein 　　the information for the NES configuration includes information indicating a respective initial activation status for the cell DRX / DTX for each of mobile devices. 　　　　(Supplementary note 8) 　　The method according to supplementary note 7, wherein 　　the information indicating the respective initial activation status includes at least one of: 　　　　information indicating at least one mobile device in an activated status of the cell DRX / DTX, 　　　　information indicating at least one mobile device in a deactivated status of the cell DRX / DTX, 　　　　information indicating at least one mobile device configured using the information for the cell DRX / DTX configuration, 　　　　information indicating a number of mobile devices configured as the activated status of the cell DRX / DTX, or 　　　　information indicating a percentage of mobile devices configured as the activated status. 　　　　(Supplementary note 9) 　　The method according to any one of supplementary notes 5 to 8, wherein 　　the transmitting the information for the NES configuration is performed upon update of the activation status of the cell DRX / DTX. 　　　　(Supplementary note 10) 　　The method according to any one of supplementary notes 5 to 9, further comprising: 　　transmitting the information indicating a respective updated activation status for the cell DRX / DTX upon update of the activation status of the cell DRX / DTX. 　　　　(Supplementary note 11) 　　The method according to supplementary note 10, wherein 　　the information indicating the respective updated activation status includes at least one of: 　　　　information indicating at least one mobile device that activated status has been changed, 　　　　information indicating at least one mobile device configured using the information for the cell DRX / DTX configuration, 　　　　information indicating a number of mobile devices configured as the activated status of the cell DRX / DTX, or 　　　　information indicating a percentage of mobile devices configured as the activated status. 　　　　(Supplementary note 12) 　　The method according to any one of supplementary notes 1 to 11, wherein 　　the information for the NES configuration includes at least one of: 　　　　information indicating ON / OFF of the NES, 　　　　information indicating a level of sleep regarding the NES, 　　　　information for power configuration regarding the NES, or 　　　　information indicating a transmission status of system information block 1 (SIB1). 　　　　(Supplementary note 13) 　　The method according to any one of supplementary notes 1 to 12, wherein 　　the information for the NES configuration is used by the second access network node for inferencing cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration at the second access network node, using an artificial intelligence (AI) / machine learning (ML) model. 　　　　(Supplementary note 14) 　　The method according to any one of supplementary notes 1 to 13, wherein 　　the first access network node includes a distributed unit of a distributed base station, and 　　the second access network node includes a central unit of the distributed base station. 　　　　(Supplementary note 15) 　　The method according to any one of supplementary notes 1 to 13, wherein 　　the first access network node includes a master base station which provides dual connectivity with the second access network node, and 　　the second access network node includes a secondary base station which provides the dual connectivity with the first access network node. 　　　　(Supplementary note 16) 　　A method performed by a second access network node, the method comprising: 　　receiving, from a first access network node, information for network energy saving (NES) configuration at the first access network node; and 　　determining for cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration or handover configuration at the second access network node using the information for the NES configuration. 　　　　(Supplementary note 17) 　　A first access network node comprising: 　　means for transmitting, to a second access network node, information for network energy saving (NES) configuration at the first access network node, wherein 　　the information for the NES configuration is used by the second access network node for cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration or handover configuration at the second access network node. 　　　　(Supplementary note 18) 　　A second access network node, the method comprising: 　　means for receiving, from a first access network node, information for network energy saving (NES) configuration at the first access network node; and 　　means for determining for cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration or handover configuration at the second access network node using the information for the NES configuration.

[0366] This application is based upon and claims the benefit of priority from Great Britain Patent Application No. 2403406.8, filed on March 8, 2024, the disclosure of which is incorporated herein in its entirety by reference.

[0367] 1 COMMUNICATION SYSTEM 3 USER EQUIPMENT 5 BASE STATION 7 CORE NETWORK 9 CELL 10 CONTROL PLANE FUNCTIONS 11 USER PLANE FUNCTIONS 20 EXTERNAL DATA NETWORK 31 TRANSCEIVER CIRCUIT 33 ANTENNA 35 USER INTERFACE 37 CONTROLLER 39 MEMORY 41 OPERATING SYSTEM 43 COMMUNICATIONS CONTROL MODULE 51 TRANSCEIVER CIRCUIT 51c TRANSCEIVER CIRCUIT(CU) 51d TRANSCEIVER CIRCUIT(DU) 53 ANTENNA 53d AIR INTERFACE 55 CORE NETWORK INTERFACE 55c NETWORK INTERFACE 57 CONTROLLER 57c CU CONTROLLER 57d DUCONTROLLER 59 MEMORY 59c CU MEMORY 59d DU MEMORY 61 OPERATING SYSTEM 61c CU OPERATING SYSTEM 61d DU OPERATING SYSTEM 63 COMMUNICATIONS CONTROL MODULE 63c CU COMMUNICATIONS CONTROL MODULE 63d DU COMMUNICATIONS CONTROL MODULE 341 DATA COLLECTION 343 MODEL TRAINING 345 INFERENCE 347 ACTOR 349 MANAGEMENT 351 MODEL STORAGE

Claims

1. A method performed by a first access network node, the method comprising: 　　transmitting, to a second access network node, information for network energy saving (NES) configuration at the first access network node, wherein 　　the information for the NES configuration is used by the second access network node for cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration or handover configuration at the second access network node.

2. The method according to claim 1, wherein 　　the information for the NES configuration includes information for wakeup signal (WUS) configuration, and 　　the information for the WUS configuration is sent to a mobile device.

3. The method according to claim 2, wherein 　　the information for the WUS configuration includes at least one of: 　　　　information for a location on a frequency domain used for a WUS, 　　　　information for a location on a time domain used for the WUS, or 　　　　information for cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration at the first access network node.

4. The method according to claim 3, wherein 　　the information for the location on the time domain includes a time offset relative to start of cell DRX active duration.

5. The method according to any one of claims 1 to 4, wherein 　　the information for the NES configuration includes information for cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration at the first access network node, 　　the information for the cell DRX / DTX configuration includes at least one of: 　　　　information for a periodicity of cell DRX / DTX, 　　　　information for a location on a time domain for the cell DRX / DTX, or 　　　　information for a configuration type which is common per serving cell.

6. The method according to claim 5, wherein 　　the information for the NES configuration includes indication information indicating whether an activation status of the cell DRX / DTX is updated by a group common signaling, and 　　the indication information is used by the second access network node for determining to use the activation status for cell DRX / DTX or handover decision at the second access network node.

7. The method according to claim 5 or 6, wherein 　　the information for the NES configuration includes information indicating a respective initial activation status for the cell DRX / DTX for each of mobile devices.

8. The method according to claim 7, wherein 　　the information indicating the respective initial activation status includes at least one of: 　　　　information indicating at least one mobile device in an activated status of the cell DRX / DTX, 　　　　information indicating at least one mobile device in a deactivated status of the cell DRX / DTX, 　　　　information indicating at least one mobile device configured using the information for the cell DRX / DTX configuration, 　　　　information indicating a number of mobile devices configured as the activated status of the cell DRX / DTX, or 　　　　information indicating a percentage of mobile devices configured as the activated status.

9. The method according to any one of claims 5 to 8, wherein 　　the transmitting the information for the NES configuration is performed upon update of the activation status of the cell DRX / DTX.

10. The method according to any one of claims 5 to 9, further comprising: 　　transmitting the information indicating a respective updated activation status for the cell DRX / DTX upon update of the activation status of the cell DRX / DTX.

11. The method according to claim 10, wherein 　　the information indicating the respective updated activation status includes at least one of: 　　　　information indicating at least one mobile device that activated status has been changed, 　　　　information indicating at least one mobile device configured using the information for the cell DRX / DTX configuration, 　　　　information indicating a number of mobile devices configured as the activated status of the cell DRX / DTX, or 　　　　information indicating a percentage of mobile devices configured as the activated status.

12. The method according to any one of claims 1 to 11, wherein 　　the information for the NES configuration includes at least one of: 　　　　information indicating ON / OFF of the NES, 　　　　information indicating a level of sleep regarding the NES, 　　　　information for power configuration regarding the NES, or 　　　　information indicating a transmission status of system information block 1 (SIB1).

13. The method according to any one of claims 1 to 12, wherein 　　the information for the NES configuration is used by the second access network node for inferencing cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration at the second access network node, using an artificial intelligence (AI) / machine learning (ML) model.

14. The method according to any one of claims 1 to 13, wherein 　　the first access network node includes a distributed unit of a distributed base station, and 　　the second access network node includes a central unit of the distributed base station.

15. The method according to any one of claims 1 to 13, wherein 　　the first access network node includes a master base station which provides dual connectivity with the second access network node, and 　　the second access network node includes a secondary base station which provides the dual connectivity with the first access network node.

16. A method performed by a second access network node, the method comprising: 　　receiving, from a first access network node, information for network energy saving (NES) configuration at the first access network node; and 　　determining for cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration or handover configuration at the second access network node using the information for the NES configuration.

17. A first access network node comprising: 　　means for transmitting, to a second access network node, information for network energy saving (NES) configuration at the first access network node, wherein 　　the information for the NES configuration is used by the second access network node for cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration or handover configuration at the second access network node.

18. A second access network node, the method comprising: 　　means for receiving, from a first access network node, information for network energy saving (NES) configuration at the first access network node; and 　　means for determining for cell discontinuous reception (DRX) / discontinuous transmission (DTX) configuration or handover configuration at the second access network node using the information for the NES configuration.

Images