Method of access network node, access network node, method of distributed unit of base station, and distributed unit of base station

Abstract

A method performed by an access network node is described, comprising transmitting, to another access network node, a message including information of one cell to request to at least one other cell in the another access network node to transmit configuration information for mobile devices to transmit a wakeup signal for requesting an on-demand system information block 1 (SIB1) of the one cell; and receiving, from the another access network node, a response message including information indicating whether one of the at least one other cell in the another access network node will provide the configuration information to the mobile devices.

Description

METHOD OF ACCESS NETWORK NODE, ACCESS NETWORK NODE, METHOD OF DISTRIBUTED UNIT OF BASE STATION, AND DISTRIBUTED UNIT OF BASE STATION

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

[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 / 6G networks, future generations, and beyond). The present disclosure in particular, but not exclusively, relates to the triggering of on-demand system information block 1 (SIB1) and on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB) transmissions for non-anchor cells (e.g., network energy saving (NES) cells) for network energy gains when multiple NES cells fall under the coverage of a single anchor cell, or when a single NES cell falls under the coverage of multiple anchor cells.

[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) has started to be used to refer to an evolving communication technology that is expected to support 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 will use the term access network node, RAN node 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 RAN nodes. 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 network 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 gNB structure may be 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 gNBs 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 gNB.

[0007] With the increasing usage of mobile communication for a wide range of different use cases, additional frequencies and bands are needed to accommodate this increasing demand. Accordingly, a variety of different frequency bands are available for 5G NR. These frequency bands include many of the existing frequency bands used by previous generations of telecommunication technology and many new frequency bands including bands in the millimetre wave region. The bandwidth available for frequency bands in the millimetre wave region is very much higher than for frequency bands used by earlier generations and thus allow for greater data speeds to be achieved albeit at the expense of the range of the signals.

[0008] The available frequency bands are grouped into two different frequency ranges referred to as frequency range 1 (FR1) containing the lower frequency bands and frequency range 2 (FR2) containing the higher frequency bands. FR1 bands are likely to carry much of the traditional cellular mobile communication traffic whereas the FR2 bands are aimed at providing short range very high data rate capability for 5G radio. Originally the FR1 band was intended to define bands below 6 GHz, but with anticipated additional spectrum allocations, the FR1 range has now been extended to 7.125 GHz.

[0009] Further, as the usage of 5G mobile communication for a wide range of different use cases increases, their complexity and energy demands are also expected to increase. With this in mind, efforts are being made to enhance network energy saving (NES) approaches that afford significant power savings in an industry standardized manner. To that end, techniques / procedures have been evaluated that have shown to bring substantial NES gains. By way of example only, such techniques / procedures may include: -　　The adaption of transmission patterns; -　　The use of downlink (DL) (or uplink (UL)) wake-up signals (WUSs) to allow devices such as UEs (or RAN nodes) to enter reduced transmission / reception modes, (for example discontinuous transmission / reception modes); -　　The use of on-demand SSBs (and possibly other DL signals) for camping onto secondary cells (SCells) by UEs configured to connect to, and use, such SCells; -　　The use of on-demand synchronisation signal / physical broadcast channel (PBCH) blocks (SSBs), and possibly other DL signals, for camping onto non-serving cells by UEs configured to connect to, and use, such non-serving cells; and -　　The use of on-demand system information block 1 (SIB1) for non-anchor cells supporting UEs in RRC INACTIVE / IDLE mode.

[0010] It will be appreciated that in the techniques / procedures listed above, SCells, non-serving cells, and / or non-anchor cells that implement some form of energy saving enhancement may also be referred to as NES cells - for example, cells that do not automatically (and / or periodically) transmit SSBs and / or system information (e.g., SIB1) to afford energy saving in the network. In the case of on-demand SIB1 transmissions for non-anchor cells (e.g., NES cells) supporting UEs in RRC INACTIVE / IDLE mode, mechanisms, and procedures on how and when to transmit on-demand SIB1 transmissions are being considered.

[0011] In the case of on-demand SIB1 transmissions for NES cells, one example procedure being considered involves a UE obtaining an UL WUS configuration from a serving cell (e.g., 'Cell A') that indicates to the UE appropriate resources, and the like, for the transmission of a WUS signal to an NES cell to wake-up that NES cell. Once the NES cell has been woken up by the WUS signal sent by the UE, the NES cell transmits an on-demand SIB1 transmission associated with the NES cell to the UE. This example may be referred to as 'Case-2 on-demand SIB1 transmissions'.

[0012] Another example procedure being considered involves the serving cell (Cell A) rather than the NES cell providing the on-demand SIB1. This procedure still involves a UE obtaining an UL WUS configuration from the serving cell (Cell A) that indicates, to the UE, appropriate resources, and the like, for the transmission of a WUS signal to an NES cell to wake-up that NES cell. Once the NES cell has been woken up by the WUS signal sent by the UE, however, the serving cell (Cell A) (rather than the NES cell) transmits an on-demand SIB1 transmission associated with the NES cell to the UE. It will be appreciated that in this example, the NES cell may provide Cell A with an appropriate UL WUS configuration in advance that indicates appropriate resources that may be used by the UE for transmission of the WUS signal to the NES cell. The UL WUS configuration thus may be provided to Cell A by the NES cell over an appropriate interface (e.g., an Xn interface) before the NES cell enters an on-demand SIB1 mode and / or when the UL WUS configuration is updated / changed. This example may be referred to as 'Case-3 on-demand SIB1 transmissions'.

[0013] In the case of demand SSBs (and possibly other DL signals) for camping onto SCells by UEs configured to connect to, and use, such SCells mechanisms and procedures on how and when to transmit on-demand SSB transmissions are also being considered.

[0014] In one example, an SCell is configured to provide no 'always-on' SSB transmissions over the SCell, while in another example, an SCell is configured to provide 'always-on' periodic SSB transmissions over the SCell. In the case of no 'always-on' SSB transmissions, the SCell is configured such that SSB transmissions for the SCell are only ever transmitted on an on-demand basis, and hence the UE signals to the SCell when it wishes to receive SSB transmissions over the SCell. On the other hand, in the case of always-on' periodic SSB transmissions, the SCell is configured such that SSB transmissions for the SCell are sent periodically, however the UE can nevertheless request on-demand SSB transmissions if the periodic SSB transmissions are not sufficient.

[0015] In both of the on-demand SSB transmission examples described above, whether a SCell should provide on-demand SSB transmissions may be indicated to the SCell via two distinct separate signalling messages (e.g., RRC, MAC Control Element (CE), etc.) that provide i) a SCell activation / deactivation indication and ii) an on-demand SSB transmission indication. Alternatively, whether a SCell should provide on-demand SSB transmissions may be indicated to the SCell via a single signalling message (e.g., RRC, MAC CE, etc.) that indicates both an SCell activation / deactivation indication and an on-demand SSB transmission indication.

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

[0017] Nevertheless, while procedures for implementing on-demand SIB1 / SSB transmissions for an NES cell such as those outlined above have been proposed, currently proposed procedures do not consider a number of scenarios in which a plurality of serving cells and NES cells have an overlapping service coverage for example scenarios in which: multiple NES cells are provided within the coverage of a single anchor cell; or multiple anchor cells overlap with a single NES cell.

[0018] Moreover, in the context of on-demand SSB, mechanisms for supporting on-demand SSB triggering (by the network) and operation for both non-split (non-distributed) and split (distributed) RAN architectures still need to be developed. Moreover, radio resource management (RRM) measurement procedures need to be enhanced due to take account of the impact of on-demand SSB.

[0019] Accordingly, further adaptations of those procedures are still needed to improve system performance and increase network energy savings further, especially in the context of a communication system that provides a plurality of serving cells and NES cells with overlapping service coverage.

[0020] The present specification aims to disclose apparatus and methods that at least contribute to addressing one or more of the above needs and / or issues.

[0021] The disclosure has a method performed by an access network node, the method comprising transmitting, to another access network node, a message including information of one cell to request to at least one other cell in the another access network node to transmit configuration information for mobile devices to transmit a wakeup signal for requesting an on-demand system information block 1 (SIB1) of the one cell; and receiving, from the another access network node, a response message including information indicating whether one of the at least one other cell in the another access network node will provide the configuration information to the mobile devices.

[0022] The disclosure has a method performed by an access network node, the method comprising receiving, from another access network node, a message including information of one cell to request to at least one other cell in the access network node to transmit configuration information for mobile devices to transmit a wakeup signal for requesting an on-demand system information block 1 (SIB1) of the one cell; and transmitting, to the another access network node, a response message including information indicating whether one of the at least one other cell in the access network node will provide the configuration information to the mobile devices.

[0023] The disclosure has an access network node comprising means for transmitting, to another access network node, a message including information of one cell to request to at least one other cell in the another access network node to transmit configuration information for mobile devices to transmit a wakeup signal for requesting an on-demand system information block 1 (SIB1) of the one cell; and receiving, from the another access network node, a response message including information indicating whether one of the at least one other cell in the another access network node will provide the configuration information to the mobile devices.

[0024] The disclosure has an access network node comprising means for receiving, from another access network node, a message including information of one cell to request to at least one other cell in the access network node to transmit configuration information for mobile devices to transmit a wakeup signal for requesting an on-demand system information block 1 (SIB1) of the one cell; and means for transmitting, to the another access network node, a response message including information indicating whether one of the at least one other cell in the access network node will provide the configuration information to the mobile devices.

[0025] The disclosure has a method performed by a distributed unit of a base station, the method comprising receiving, from a central unit of the base station, a message including information of at least one cell for the at least one cell in the distributed unit to transmit an on-demand synchronizatrion signal / physical broadcast channel (PBCH) block (SSB) of the at least one cell; and determining to activate or deactivate to transmit the on-demand SSB of the at least one cell.

[0026] The disclosure has a distributed unit of a base station comprising means for receiving, from a central unit of the base station, a message including information of at least one cell for the at least one cell in the distributed unit to transmit an on-demand synchronizatrion signal / physical broadcast channel (PBCH) block (SSB) of the at least one cell; and means for determining to activate or deactivate to transmit the on-demand SSB of the at least one cell.

[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 examples 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] Examples of apparatus and methods will now be described, by way of example, with reference to the accompanying drawings in which:

[0030] Fig. 1 schematically illustrates a ('cellular' or 'wireless') communication system;Fig. 2 schematically illustrates an example coverage scenario comprising anchor cells and NES cells that may be provided by the communication system of Fig. 1;Fig. 3 illustrates a simplified sequence diagram illustrating an inter-RAN node information exchange procedure for indicating anchor cell support of UL WUS configurations for on-demand SIB1 transmissions;Fig. 4 illustrates another simplified sequence diagram illustrating an inter-RAN node information exchange procedure for indicating anchor cell support of UL WUS configurations for on-demand SIB1 transmissions;Fig. 5A illustrates a simplified sequence diagram of an example procedure for UL WUS configuration provision for the transmission of a WUS to an NES cell that supports on-demand SIB transmissions;Fig.5B illustrates a simplified sequence diagram of an example procedure for UL WUS configuration provision for the transmission of a WUS to an NES cell that supports on-demand SIB transmissions;Fig. 6A illustrates a simplified sequence diagram of an example procedure for UL WUS configuration provision for the transmission of a WUS to an NES cell that supports on-demand SIB transmissions;Fig. 6B illustrates a simplified sequence diagram of an example procedure for UL WUS configuration provision for the transmission of a WUS to an NES cell that supports on-demand SIB transmissions;Fig. 7A illustrates a simplified sequence diagram of an example procedure for UL WUS configuration provision for the transmission of a WUS to an NES cell that supports on-demand SIB transmissions;Fig. 7B illustrates a simplified sequence diagram of an example procedure for UL WUS configuration provision for the transmission of a WUS to an NES cell that supports on-demand SIB transmissions;Fig. 8 illustrates a simplified sequence diagram of an example on-demand SSB transmissions procedure that may be implemented in the communication system illustrated in Fig. 1;Fig. 9 illustrates a simplified sequence diagram of another example on-demand SSB transmissions procedure that may be implemented in the communication system illustrated in Fig. 1;Fig. 10 is a simplified block schematic illustrating the main components of a UE for implementation in the communication system of Fig. 1;Fig. 11 is a simplified block schematic illustrating the main components of a non-distributed RAN node for implementation in the communication system of Fig. 1; andFig. 12 is a schematic block diagram illustrating the main components of a distributed RAN node for the communication system of Fig. 1.

[0031] <Overview> 　　An exemplary communication system will now be described in general terms, by way of example only, with reference to Figs. 1 and 2.

[0032] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system 1 to which the examples described herein are applicable.

[0033] In the communication system 1, user equipments (UEs) 3 (3-1, 3-2, 3-3) (e.g., mobile telephones and / or other mobile or stationary devices) can communicate with each other via a (radio) access network ((R)AN) node 5 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, the RAN node 5 comprises a base station 5 operating one or more associated cells 9. Communication via the RAN node 5 is typically routed through a core network 7 (e.g., a 5G / 6G / later generation core network or evolved packet core network (EPC)) or any other core network.

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

[0035] Each RAN node 5-1, 5-2 controls one or more associated cells 9-1, 9-2 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-1, 5-2 may be configured to support 4G, 5G, 6G and / or later generations, and / or any other 3GPP or non-3GPP communication protocols.

[0036] Each RAN node 5-1, 5-2 illustrated is a non-distributed base station (e.g., an integrated base station 5). Nevertheless it will be appreciated that one or both of the RAN nodes 5-1, 5-2 may be a distributed base station comprising at least one distributed unit (DU) (e.g., a gNB-DU or the like), and a central unit (CU) (e.g., a gNB-CU or the like). In such a distributed base station the CU employs 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 via 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 (an E1 interface). It will be appreciated that while the DU may include 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 base station 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).

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

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

[0039] The communication system 1 also includes an Operations, Administration and Maintenance (OAM) 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 14 may, for example, communicate with a network data analytics function (NWDAF) or the like (not shown).

[0040] The RAN nodes 5-1, 5-2 are 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 reference point (e.g. N1 reference point (analogous to the S1 reference point in LTE)). It will be appreciated that N1 communication are routed transparently via the RAN node 5.

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

[0042] 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. The AMF 10-1 receives user information sent through the network and forwards the information to the SMF 10-2.

[0043] The SMF 10-2 is connected to the AMF 10-1 via an appropriate reference point (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 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.

[0044] The RAN nodes 5-1, 5-2 of the communication system 1 is configured to operate at least one cell 9 on an associated time-division duplex (TDD) carrier that operates in unpaired spectrum and / or at least one cell 9 on an associated frequency-division duplex (FDD) carrier that operates in paired spectrum.

[0045] The RAN nodes 5-1, 5-2 are 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.

[0046] The DL 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 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.

[0047] The RAN nodes 5-1, 5-2 also transmit DL physical signals that do not carry any data, such as, 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-1, 5-2. 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).

[0048] Similarly, the UEs 3 are configured for transmission of, and the RAN node 5 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 an UL control / data signal, and / or sounding reference signals (SRS) used for UL channel measurement.

[0049] < 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 a 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).

[0050] 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 1.

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

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

[0053] 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 a UE 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 a UE 3 may be 44 BDs.

[0054] <Synchronisation Signal / Physical Broadcast Channel (PBCH) Blocks (SSBs)> 　　The RAN nodes 5-1, 5-2 are also configured to transmit synchronisation signal / physical broadcast channel (PBCH) blocks (SSBs) periodically in the cells 9-1, 9-2 that they operate. The SSB includes both synchronisation signals (e.g., a primary synchronisation signal (PSS) and a secondary synchronisation signal (SSS)) and the PBCH carrying a MIB that provides at least part of the minimum system information for accessing the corresponding cell 9 (e.g., parameters required for acquiring system information block 1 (SIB1) which carries other minimum system information).

[0055] Each UE 3 may receive an SSB, and the UE 3 may assume that reception occasions of a PBCH, PSS and SSS are in consecutive symbols from the SSB (also referred to as a SS / PBCH block). The PSS is a part of the SSB that aids in initial cell detection and synchronization. It provides coarse timing and frequency synchronization for UEs. The PSS consists of a predefined sequence of complex-valued symbols transmitted over a specific frequency range. The SSS is another component of the SSB that provides additional information for fine-grained synchronization and cell identification. It carries the cell identity group and provides the necessary information to determine the exact physical cell ID (PCI) of the serving cell (e.g., a unique identifier assigned to each cell within the network that helps UEs differentiate between neighbouring cells and synchronize with the correct cell.

[0056] The RAN node 5 may transmit several SSBs corresponding to different DL beams. The total number of SSBs may be confined, for example, within a 5 ms duration as an SS burst. The periodicity of the SSB transmissions may be indicated to the UE using any suitable signalling (e.g., per serving cell using ssb-periodicityServingCell). The periodicity value for the SSB may be, for example, greater than or equal to 20 ms. For initial cell selection, the UE 3 may be configured to assume that an SS burst occurs with a periodicity of 2 frames. The UE 3 may also be provided with an indication of which SSBs within a 5 ms duration are transmitted (e.g., using ssb-PositionsInBurst). The UE 3 may also be provided with an indication of an absolute transmit power value of the SSS (e.g., using ss-PBCH-BlockPower) which may range from -60 to 50 dBm. Furthermore, the UE 3 may also be provided with an indication of the subcarrier spacing (SCS) used for the SSB (e.g., using ssbSubcarrierSpacing). It will be appreciated that all indications to the UE 3 about the SSB may be indicated to the UE 3 via any appropriate information element (IE) (e.g., ServingCellConfigCommon provided in a SIB1 message, or any other appropriate dedicated message).

[0057] Each UE 3 is configured to search for SSBs when scanning for an anchor cell to camp on and to decode the associated PBCH before proceeding to decode other system information transmitted on the PDSCH. Each UE 3 is also configured to perform measurements on specific resources configured for the SSBs, for example measurements of reference signal received power (RSRP), reference signal received quality (RSRQ), and / or signal to interference and noise ratio (SINR) measurements or the like. Each UE 3 may also be configured to perform radio resource management (RRM) measurements when triggered to do so by a RAN node 5.

[0058] < Random access channel (RACH) procedures> 　　The UEs 3 and RAN node 5 of the communication system 1 are mutually configured for performing RACH procedure for the UE 3 to access the network. Specifically, on detection and selection of a cell (and / or a beam in the case of 5G) the UE 3 is able to attempt access to that cell and / or beam using an initial radio resource control (RRC) connection setup procedure comprising a random-access procedure. Prior to attempting initial access the UE 3 chooses random access resources (including, for example, a preamble) to use to initiate the RACH procedure. The UE 3 sends the selected preamble (e.g., in 'Msg1') to the RAN node 5 over a physical random-access channel (PRACH) for initiating the process to obtain synchronization in the uplink (UL). In response, the the RAN node 5 responds with a random-access response (RAR) (or 'Msg2'). The RAR indicates reception of the preamble and includes: a timing-alignment (TA) command for adjusting the transmission timing of the UE based on the timing of the received preamble; an uplink grant field indicating the resources to be used in the uplink for a physical uplink shared channel (PUSCH); a frequency hopping flag to indicate whether the UE is to transmit on the PUSCH with or without frequency; a modulation and coding scheme (MCS) field from which the UE 3 can determine the MCS for the PUSCH transmission; and a transmit power control (TPC) command value for setting the power of the PUSCH transmission. The UE 3 then sends a third message ('Msg3') to the network over a physical uplink shared channel (PUSCH) based on the information in the RAR. The specific message sent by the UE in this step, and the content of the message, depends on the context in which the random-access procedure is being used. In the example of initial radio RRC connection setup, however, Msg3 typically comprises an RRC Setup request or similar message carrying a temporary randomly generated UE identifier. The network responds with a fourth message ('Msg4') which carries the randomly generated UE identifier received in Msg3 for contention purposes to resolve any collisions between different UEs 3 using the same preamble sequence. When successful, Msg4 also transfers the UE 3 to a connected state.

[0059] While a four-step contention-based RACH procedure is described it will be appreciated that a UE 3 and the RAN node 5 of the communication system 1 may also perform a non-contention based (or 'contention free') procedure in which a dedicated preamble is assigned by the RAN node 5 to the UE. Moreover, a UE 3 and the RAN 5 node of the communication system 1 may perform a two-step RACH procedure (e.g., as described in the introduction).

[0060] It will be appreciated that while the UE 3 can trigger initiation of the RACH procedure itself (e.g., when the UE 3 needs to connect to the network), initiation of the RACH procedure may be by the network. For example, a RACH procedure may be initiated via a message sent via downlink control information (DCI) with an appropriate DCI format (e.g. 1_0) in a physical downlink control channel (PDCCH) - such a message is commonly known as a PDCCH order. A RACH procedure may be also initiated by the RAN node 5 when handover is required (e.g., using a handover command message).

[0061] Fig. 2 schematically illustrates an example coverage scenario comprising anchor cells and NES cells that may be provided by the communication system 1.

[0062] As shown in Fig. 2, a first RAN node 5-1 that connects to an external data network 20 via the core network 7 provides a first cell 9-1. It will be appreciated that the first RAN node 5-1 may also provide other cells (not shown) via carrier aggregation (CA). The first cell 9-1, in this example, is an anchor cell (e.g., a cell where the UE 3 can receive SSBs, system information, paging messages, and the like). A second RAN node 5-2 that connects to an external data network 20 via the core network 7 provides a second cell 9-2. It will be appreciated that the second RAN node 5-1 may also provide other cells (not shown) via CA or the like. The second cell 9-2, in this example, is also an anchor cell.

[0063] Typically, upon switch on, a UE 3 in RRC_IDLE mode may perform a cell search procedure to identify a cell onto which it can camp. For example, the UE 3 may scan for a cell 9 to camp onto by searching for SSBs and perform measurements on specific resources configured for the SSBs, for example RSRP and / or RSRQ. Based on those SSBs and measurements, the UE 3 (or the first RAN node 5-1 in response to measurement reports from the UE 3) may decide that the UE 3 should camp onto a specific cell 9 (e.g., the cell that provides the best service quality - in the case of Fig. 2, cell 9-1).

[0064] Moreover, as shown in Fig. 2, NES (non-anchor) cells that the UE 3 may camp onto are provided by RAN nodes 5 other than the first and second RAN node 5-1, 5-2. Specifically, RAN nodes 5-3, 5-4 provide NES cells 9-3, 9-4, respectively. It will be appreciated that whilst the RAN nodes 5-1, 5-2, 5-3, 5-4 (5) are described in the context of a scenario in which they each form part of a different respective RAN, in some scenarios, an anchor cell (which may be referred to as 'Cell A') and one or more NES cells may be provided by the same RAN. For example, the anchor cell and one or more NES cells may be provided via different nodes of a distributed RAN (e.g., an anchor cell may be provided by one distributed (or remote) unit of a RAN and an NES cell may be provided by another distributed (or remote) unit of the same RAN).

[0065] Such NES cells (whether provided by the same, or a different RAN from the anchor cell on which a UE 3 is camped) may be neighbouring cells to the anchor cell, or may be smaller cells overlapping with, or wholly incorporated within, the anchor cell. An NES cell, unlike an anchor cell, is a cell over which UEs 3 cannot (or at least cannot routinely) receive SSBs and / or system information (e.g., SIB messages). For example, a non-anchor cell may be an SSB-less / SIB1-less / SIB-less cell in which SSBs and / or SIB1 (and other SIBs) are not sent (and may instead be sent via the anchor cell). It will, nevertheless, be appreciated that an NES cell may be configured as a cell in which SIB1 is sent on-demand. Initially attaching on an anchor cell and allowing the UE 3 to subsequently use an NES cell may be referred to as a 'multi-cell' scenario.

[0066] It will be appreciated that while a UE 3 is described above as initially camping on an anchor cell 9-1and then switching / being handed over to an NES cell 9-3, 9-4, it will nevertheless be appreciated that a UE 3 may initially attach to an NES cell (e.g., cell 9-3) from the outset.

[0067] The use of such SSB-less / SIB1-less / SIB-less NES cells 9-3, 9-4, beneficially offer energy gains in the communication system 1 as the associated RAN node 5-3, 5-4, does not need to periodically send SSBs / SIBs associated with the corresponding NES cell 9-3, 9-4. It will be appreciated however that for the UE 3 to be able to use an NES cell, one of the RAN nodes 5, has to provide an appropriate SSB / SIB for the that NES cell.

[0068] <Enhancements for Supporting On-Demand (OD) SIB1 / SSB> 　　Beneficially, the communication system 1 is configured to support one or more mechanisms for on-demand SIB1 / SSB transmissions for the NES cells that cater for scenarios in which: - Multiple NES cells (e.g., cells 9-3 and 9-4) are provided within the coverage of a single anchor cell (e.g., cell 9-1) or; - Multiple anchor cells (e.g., cells 9-1 and 9-2) overlap with a single NES cell (e.g., like cell 9-3 in Fig. 2).

[0069] Specifically, to provide further energy gains and maintain high system performance the communication system 1 beneficially supports one or enhancements to on-demand SIB1 transmission procedures that facilitate, for on-demand SIB1 transmissions, co-ordination between multiple NES cells within the coverage of a single anchor cell and / or co-ordination between multiple anchor cells that overlap a single NES cell coverage area.

[0070] It will be appreciated that whilst the enhancements are described primarily in the context of on-demand SIB1, similar enhancements may also be implemented in the context of on-demand SSB transmissions in communication systems 1 where multiple NES cells (e.g., cells 9-3 and 9-4) are provided within the coverage of a single anchor cell (e.g., cell 9-1) or multiple anchor cells (e.g., cells 9-1 and 9-2) overlap with a single NES cell (e.g., cell 9-2).

[0071] Furthermore, the communication system 1 is further beneficially configured to support on-demand SSB transmissions for NES cells in a communication system 1 with a non-split, or a split architecture (e.g., a split RAN architecture, or the like), and to provide RRM measurement enhancements for on-demand SSB transmissions.

[0072] Several enhanced procedures and techniques for implementing on-demand SIB1 transmissions for NES cells in the communication system 1 will now be described, by way of example only, with reference to Figs 3 to 7.

[0073] < Implementation of On-demand SIB1 Transmissions for NES Cells> <Indicating anchor cell support of UL WUS configuration / on-demand SIB1 transmission> 　　Fig. 3 illustrates a simplified sequence diagram illustrating an inter-RAN node information exchange procedure for indicating anchor cell (e.g., 'Cell A') support of UL WUS configurations and / or associated on-demand SIB1 transmission for on-demand SIB1 transmissions that may be implemented in the communication system of Fig. 1.

[0074] As shown in Fig. 3, the RAN node 5-1 providing an anchor cell 9-1 and the RAN node 5-3 providing an NES cell 9-3 are configured to engage in a dedicated setup procedure for exchanging information (e.g., indicating whether or not the anchor cell 9-1 supports provision of on-demand SIB1 for the NES cell / provision of associated UL WUS configurations). This procedure may, for example, be a modified form of a conventional RAN node to RAN node interface (e.g., 'Xn') based application protocol (e.g., 'XnAP') based setup procedure. As those skilled in the art will appreciate, such setup procedures are generally specified for communication systems, for updating application-level configuration data needed for two RAN nodes 5 to interoperate correctly over a RAN node to RAN node control plane interface (e.g. 'Xn-C').

[0075] As part of the dedicated setup procedure for exchanging information, the RAN node 5-1 providing an anchor cell 9-1 sends, at step S302, an appropriate RAN node to RAN node interface (e.g., 'Xn') based setup request message, or the like, to the RAN node 5-3 providing an NES cell 9-3. The RAN node to RAN node interface (e.g., 'Xn') based setup request message includes an indicator (for the anchor cell 9-1) of whether or not the RAN node 5-1 providing the anchor cell 9-1 supports provision of an UL WUS configuration and / or an associated on-demand SIB1 in that anchor cell 9-1.

[0076] The RAN node to RAN node interface (e.g., 'Xn') based setup request message may include the indicator as part of an information element (e.g., a served cell information IE) for the anchor cell, which may itself form part of a list of similar such information for each of a plurality of served cells (where applicable).

[0077] It will be appreciated that whilst the message sent at step S302 may be a RAN node to RAN node interface (e.g., 'Xn') based setup request message based on an existing RAN node to RAN node interface (e.g., 'Xn') based setup procedure, it may alternatively be a new dedicated message for the purposes of indicating whether or not the RAN node 5 sending that message (e.g., RAN node 5-1) supports provision of an UL WUS configuration and / or an associated on-demand SIB1in the anchor cell 9-1.

[0078] At step S304, the RAN node 5-3 providing the NES cell 9-3, having received the RAN node to RAN node interface (e.g., 'Xn') based setup request message at step S302, sends an appropriate RAN node to RAN node interface (e.g., 'Xn') based response message, or the like, to the RAN node 5-1 that provides the anchor cell 9-1 to confirm successful receipt of the RAN node to RAN node interface (e.g., 'Xn') based setup request message.

[0079] Having transmitted the RAN node to RAN node interface (e.g., 'Xn') based setup response message, the RAN node 5-3 records the respective indicator (e.g., whether or not provision of an UL WUS configuration and / or an associated on-demand SIB1 is supported), for each cell for which such an indicator is provided, in a neighbour relation table (NRT) stored at the RAN node 5-3. Thus the NRT may include corresponding entries for one or more cells provided by RAN node 5-1 (e.g., cell 9-1) indicating whether UL WUS configuration and / or an associated on-demand SIB1 provision is supported in that cell. The NRT may also include a priority for each cell (e.g., an order of preference of cells for which an UL WUS configuration and / or an associated on-demand SIB1 may be provided).

[0080] Fig. 4 illustrates another simplified sequence diagram illustrating an inter-RAN node information exchange procedure for indicating anchor cell (e.g., 'Cell A') support of UL WUS configurations and / or an associated on-demand SIB1 transmission for on-demand SIB1 transmissions that may be implemented in the communication system of Fig. 1.

[0081] As shown in Fig. 4, the RAN node 5-1 providing an anchor cell 9-1 and the RAN node 5-3 providing an NES cell 9-3 are configured to engage in a dedicated setup procedure for exchanging information (e.g., indicating whether or not the anchor cell 9-1 supports provision of on-demand SIB1 for the NES cell / provision of associated UL WUS configurations).

[0082] This procedure may, for example, be a modified form of a conventional RAN node to RAN node interface (e.g., 'Xn') based application protocol (e.g., 'XnAP') based setup procedure. As those skilled in the art will appreciate, such setup procedures are generally specified for communication systems, for updating application-level configuration data needed for two RAN nodes to interoperate correctly over a RAN node to RAN node control plane interface (e.g. 'Xn-C').

[0083] As part of the dedicated setup procedure for exchanging information, the RAN node 5-3 providing an NES cell 9-3 sends, at step S402, an appropriate RAN node to RAN node interface (e.g., 'Xn') based setup request message, or the like, to the RAN node 5-1 (providing an anchor cell 9-1). The RAN node to RAN node interface (e.g., 'Xn') based setup request message includes a request for an indicator (for the anchor cell 9-1) of whether or not the RAN node 5-1 providing the anchor cell 9-1 supports provision of an UL WUS configuration and / or an associated on-demand SIB1 in the anchor cell 9-1.

[0084] It will be appreciated that the RAN node to RAN node interface (e.g., 'Xn') based setup request message sent at step S402 may, by way of example only, be the same as a Xn setup request message used in a conventional XnAP based NG-RAN node Xn setup procedure, or alternatively, it may be a new dedicated message for the purposes of indicating whether or not the RAN node 5-1 that provides the anchor cell 9-1 supports provision of an UL WUS configuration and / or an associated on-demand SIB1 in the anchor cell 9-1.

[0085] At step S404, the RAN node 5-3, having received RAN node to RAN node interface (e.g., 'Xn') based setup request message at step S402, sends an appropriate RAN node to RAN node interface (e.g., 'Xn') based response message, or the like, to the RAN node 5-1 providing the anchor cell 9-1 to confirm successful receipt of the RAN node to RAN node interface (e.g., 'Xn') based request message.

[0086] That RAN node to RAN node interface (e.g., 'Xn') based setup response message includes an indicator (for the anchor cell 9-1) of whether or not the RAN node 5-1 providing the anchor cell 9-1 supports provision of an UL WUS configuration and / or an associated on-demand SIB1 in that anchor cell 9-1. For example, the RAN node to RAN node interface (e.g., 'Xn') based setup request message may include the indicator as part of an information element (e.g., a served cell information IE) for the anchor cell, which may itself form part of a list of similar such information for each of a plurality of served cells (where applicable).

[0087] Having received the RAN node to RAN node interface (e.g., 'Xn') based response message, the RAN node 5-3 records the respective indicator (e.g., whether or not provision of an UL WUS configuration and / or an associated on-demand SIB1 is supported), for each cell for which such an indicator is provided, in a NRT stored at the RAN node 5-3. Thus the NRT may include corresponding entries for one or more cells provided by RAN node 5-1 (e.g., cell 9-1) indicating whether UL WUS configuration and / or an associated on-demand SIB1 provision is supported in that cell. The NRT may also include a priority for each cell (e.g., an order of preference of cells for which an UL WUS configuration may be provided).

[0088] <UL WUS configuration provision for the transmission of a WUS to an NES cell that supports on-demand SIB1 transmissions (Case-2)> 　　Fig. 5 illustrates a simplified sequence diagram of an example procedure for UL WUS configuration provision for the transmission of a WUS to an NES cell that supports on-demand SIB transmissions.

[0089] As shown in Fig. 5, there is provided a first RAN node 5-1 providing a first anchor cell 9-1, a second RAN node 5-2, providing a second anchor cell 9-2, and a third RAN node 5-3 providing an NES cell 9-3.

[0090] At step S502, the third RAN node 5-3 providing the NES cell 9-3 selects a neighbouring RAN node (e.g., the first RAN node 5-1) providing a neighbouring anchor cell (e.g., the first anchor cell 9-1) that could be used to provide an UL WUS configuration for the NES cell 9-3 to a UE 3 (not shown) of the communication system 1. For example, at step S502, the third RAN node 5-3 may select the first RAN node 5-1 and provide that first RAN node 5-1 with an appropriate UL WUS configuration (e.g., using a dedicated UL WUS configuration message, a conventional (modified) RAN node configuration update message, or the like) for the NES cell 9-3. That UL WUS configuration may, for example, include appropriate information to configure resources for the transmission of an UL WUS by the UE 3 to the third RAN node 5-3 providing the NES cell 9-3 at some future time to wake-up that RAN node 5-3 when the NES cell it provides is wanted / needs to be accessed by the UE 3.

[0091] It will be appreciated that the third RAN node 5-3 may select the neighbouring RAN node (e.g., the first RAN node 5-1) providing the neighbouring anchor cell (e.g., first anchor cell 9-1) based on one or more criteria. In one example, the third RAN node 5-3 may select the neighbouring RAN node based on the third RAN node 5-3 being pre-configured to select a specific neighbouring RAN node (e.g., the first RAN node 5-1) by the OAM 14 of the communication system 1.

[0092] In another example, the third RAN node 5-3 may select a neighbouring RAN node 5 (e.g., the first RAN node 5-1) based on information stored during a pre-coordination between the third RAN node 5-3 and that neighbouring RAN node 5. For example, based on an automatic neighbour relation (ANR) between the third RAN node 5-3 and the neighbouring RAN node 5 that is stored in an NRT at the third RAN node 5-3 (e.g., during a procedure such as that disclosed in Fig. 3 or Fig. 4).

[0093] In yet another example, the third RAN node 5-3 may select a neighbouring RAN node 5 (e.g., the first RAN node 5-1) based on a random selection procedure.

[0094] At step S504, having received the UL WUS configuration for the NES cell 9-3 from the third RAN node 5-3, the selected neighbouring RAN node 5 (e.g., the first RAN node 5-1) may decide / determine whether it can support on-demand (OD) SIB1 transmissions for the NES cell 9-3. For example, the selected neighbouring RAN node 5 may decide / determine that it can support OD SIB1 transmissions for the NES cell 9-3 if the first RAN node 5-1 can provide an UL WUS configuration to a UE 3 in the first anchor cell 9-1 (for configuring resources for the transmission of an UL WUS by the UE 3 in the NES cell 9-3 to wake-up the third RAN node 5-3 / activate the NES cell 9-3).

[0095] As part of deciding / determining whether or not it can support OD SIB1 transmissions for the NES cell 9-3, the selected neighbouring RAN node (e.g., the first RAN node 5-1 providing the first anchor cell 9-1) may check whether it can support UL WUS configuration provision to the UE 3 by checking the status of OD SIB1 transmissions for any other NES cells that the first RAN node 5-1 may currently be supporting. It will be appreciated, for example, that where the first RAN node 5-1 is already supporting (on-going) OD SIB1 transmissions for another NES cell or NES cells, the first RAN node 5-1 may not have capacity to support OD SIB1 transmissions for the NES cell 9-3 provided by the third RAN node 5-3.

[0096] At step S506, the first RAN node 5-1 sends an appropriate response message (e.g., a dedicated UL WUS configuration response message, a RAN configuration update acknowledgement message, or the like) to the third RAN node 5-3 to acknowledge receipt of the UL WUS configuration sent at step S502. The response message may, for example, include an appropriate indication (e.g., a flag, or the like) as to whether or not the first RAN node 5-1 supports UL WUS configuration provision to the UE 3 for the NES cell 9-3 e.g., whether or not the first RAN node 5-1 can provide the UL WUS configuration for the NES cell 9-3 to the UE 3 to configure resources for the transmission of an UL WUS by the UE 3 to the third RAN node 5-3.

[0097] Where the response message indicates that the first RAN node 5-1 can support UL WUS configuration provision to the UE 3 for NES cell 9-3, the response message may include a suggested OD SIB1 transmission activation time for the NES cell 9-3, and the third RAN node 5-3, at step S508, may activate the NES cell 9-3 for OD SIB1 transmissions e.g., the third RAN node 5-3 may begin 'listening' for an UL WUS from the UE 3. It will be appreciated that upon receiving such an UL WUS from the UE 3, the third RAN node 5-3 may begin transmission of one or more OD SIB1s.

[0098] It will be appreciated that where the response message includes a suggested OD SIB1 transmission activation time for the NES cell 9-3 (e.g., a time at which the third RAN node 5-3 should begin 'listening' for an UL WUS), the third RAN node 5-3, at step S508, may activate the NES cell 9-3 for OD SIB1 transmissions at that indicated activation time (or sometime after that activation time) - for example, the third RAN node 5-3 may begin 'listening' for an UL WUS from the UE 3 at, or shortly after, that activation time.

[0099] Where the response message indicates that the first RAN node 5-1 does not support UL WUS configuration provision for the UE 3 for NES cell 9-3, the response message may include, for example, a cause value indicating why UL WUS configuration provision is not supported. For example, response message may indicate that the first RAN node 5-1 does not support UL WUS configuration provision, or that the first RAN node 5-1 is already supporting OD SIB1 transmissions for an NES cell or cells and does not have capacity to support NES cell 9-3, etc.

[0100] Where the response message indicates that the first RAN node 5-1 does not support UL WUS configuration provision for the UE 3 for NES cell 9-3, the third RAN node 5-3, at step S510, may select another (a different) neighbouring RAN node (e.g., RAN node 5-2) providing another (a different) neighbouring anchor cell (e.g., a second anchor cell 9-2) that could be used to provide an UL WUS configuration for the NES cell 9-3 to the UE 3 (not shown) of the communication system 1.

[0101] For example, at step S510, the third RAN node 5-3 may select the second RAN node 5-2 and provide that second RAN node 5-2 with an appropriate UL WUS configuration (e.g., using a dedicated UL WUS configuration message, a conventional (modified) RAN node configuration update message, or the like). It will be appreciated that the appropriate UL WUS configuration provided to the second RAN node 5-2 may be the same as (or different to) the UL WUS configuration provided previously to the first RAN node 5-1 at step S502.

[0102] It will be appreciated that the third RAN node 5-3 may select the the neighbouring RAN node 5 (e.g., the second RAN node 5-2) providing the neighbouring anchor cell (e.g., the second anchor cell 9-2) based on one or more criteria. In one example, the third RAN node 5-3 may select the neighbouring RAN node based on the third RAN node 5-3 being pre-configured to select the neighbouring RAN node by the OAM 14 of the communication system 1.

[0103] In another example, the third RAN node 5-3 may select the neighbouring RAN node 5 (e.g., RAN node 5-2) based on information stored during a pre-coordination between the third RAN node 5-3 and the neighbouring RAN node 5. For example, based on an ANR between the third RAN node 5-3 and the neighbouring RAN node 5 that is stored in an NRT at the third RAN node 5-3 (e.g., during a procedure such as that disclosed in Fig. 3 or Fig. 4).

[0104] In yet another example, the third RAN node 5-3 may select the neighbouring RAN node 5 (e.g., RAN node 5-2) based on a random selection procedure.

[0105] At step S512, having received the UL WUS configuration for the NES cell 9-3 from the third RAN node 5-3, the selected neighbouring RAN node 5 (e.g., the second RAN node 5-2) may decide / determine whether it can support OD SIB1 transmissions for the NES cell 9-3. For example, the selected neighbouring RAN node 5 may decide / determine that it can support OD SIB1 transmissions for the NES cell 9-3 if the second RAN node 5-2 can provide an UL WUS configuration to the UE 3 in the second anchor cell 9-2 to configure resources for the transmission of an UL WUS by the UE 3 in the NES cell 9-3 to wake-up the third RAN node 5-3 / activate the NES cell 9-3.

[0106] As part of deciding / determining whether or not it can support OD SIB1 transmissions for the NES cell 9-3, the selected neighbouring RAN node 5 (e.g., the second RAN node 5-2 providing the second anchor cell 9-2) may check whether it can support UL WUS configuration provision to the UE 3 by checking the status of OD SIB1 transmissions for any other NES cells that the second RAN node 5-2 may currently be supporting. It will be appreciated for example that where the second RAN node 5-2 is already supporting (on-going) OD SIB1 transmissions for another NES cell or NES cells, the second RAN node 5-2 may not have capacity to support OD SIB1 transmissions for the NES cell 9-3 provided by the third RAN node 5-3.

[0107] At step S514, the second RAN node 5-2 sends an appropriate response message (e.g., a dedicated UL WUS configuration response message, a RAN configuration update acknowledgement message, or the like) to the third RAN node 5-3 to acknowledged receipt of the UL WUS configuration sent at step S510. That response message may, for example, include an appropriate indication (e.g., a flag, or the like) as to whether or not the second RAN node 5-2 supports UL WUS configuration provision for the NES cell 9-3.

[0108] Where the response message indicates that the second RAN node 5-2 can support UL WUS configuration provision to the UE 3 for NES cell 9-3, the response message may include a suggested OD SIB1 transmission activation time for the NES cell 9-3, and the third RAN node 5-3, at step S516, may activate the NES cell 9-3 for OD SIB1 transmissions e.g., the third RAN node 5-3 may begin 'listening' for an UL WUS from the UE 3. It will be appreciated that upon receiving such an UL WUS from the UE 3, the third RAN node 5-3 may begin transmission of one or more OD SIB1s to the UE 3.

[0109] It will be appreciated that where the response message includes a suggested OD SIB1 transmission activation time for the NES cell 9-3 (e.g., a time at which the third RAN node 5-3 should begin 'listening' for an UL WUS), the third RAN node 5-3, at step S508, may activate the NES cell 9-3 for OD SIB1 transmissions at that indicated activation time (or sometime after that activation time) - for example, the third RAN node 5-3 may begin 'listening' for an UL WUS from a UE 3 at, or shortly after, that activation time.

[0110] Where the response message indicates that the second RAN node 5-2 does not support UL WUS configuration provision for the UE 3 for NES cell 9-3, the response message may include, for example, a cause value indicating why UL WUS configuration provision is not supported. For example, response message may indicate that the second RAN node 5-2 does not support UL WUS configuration provision, or that the second RAN node 5-2 is already supporting OD SIB1 transmissions for an NES cell or cells and does not have capacity to support NES cell 9-3, etc.

[0111] Where the response message indicates that the second RAN node 5-2 does not support UL WUS configuration provision for the UE 3 for NES cell 9-3, the third RAN node 5-3 may select yet another (a different) neighbouring RAN node 5 providing yet another (a different) neighbouring anchor cell that could be used to provide an UL WUS configuration for the NES cell 9-3 to the UE 3 (not shown) of the communication system 1.

[0112] It will be appreciated that the procedure at steps S510 to S516 may be repeated with different selected neighbouring RAN nodes 5 providing neighbouring anchor cells until the third RAN node 5-3 receives a response message indicating that a specific neighbouring RAN node 5 supports UL WUS configuration provision for the NES cell 9-3.

[0113] Having received a response message indicating that a specific neighbouring RAN node 5 supports UL WUS configuration provision for the NES cell 9-3, it will be appreciated that the third RAN node 5-3 may occasionally need to send an updated UL WUS configuration to that specific neighbouring RAN node 5 (step S518). For example, in response to the third RAN node 5-3 updating its UL WUS configuration, it may forward that updated UL WUS configuration to the specific neighbouring RAN node 5.

[0114] It will be appreciated that in response to receiving the updated UL WUS configuration the full procedure of Fig. 5 may be re-started at step S502.

[0115] Fig. 6 illustrates a simplified sequence diagram of another example procedure for UL WUS configuration provision for the transmission of a WUS to an NES cell that supports on-demand SIB transmissions.

[0116] As shown in Fig. 6, there is provided a first RAN node 5-1 providing a first anchor cell 9-1, a second RAN node 5-2, providing a second anchor cell 9-2, and a third RAN node 5-3 providing an NES cell 9-3.

[0117] At step S602a the third RAN node 5-3 providing the NES cell 9-3 sends an appropriate (e.g., dedicated) UL WUS configuration, RAN node configuration update, or the like to the first RAN node 5-1 that could be used to provide an UL WUS configuration for the NES cell 9-3 to the UE 3 (not shown) of the communication system 1. Similarly, at step S602b the third RAN node 5-3 providing the NES cell sends the same UL WUS configuration, RAN node configuration update, or the like to the second RAN node 5-2 that could be used to provide an UL WUS configuration for the NES cell 9-3 to the UE 3 (not shown) of the communication system 1. Those UL WUS configurations, which may be sent to the first and second RAN nodes 5-1, 5-2 using e.g., a dedicated UL WUS configuration message, a conventional (modified) RAN node configuration update message, or the like, may include appropriate information to configure resources for the transmission of an UL WUS by the UE 3 to the third RAN node 5-3 providing the NES cell 9-3 at some future time to wake-up that RAN node 5-3 when the NES cell it provides is wanted / needs to be accessed by the UE 3.

[0118] Additionally, those UL WUS configurations may include a candidate cell list, or the like, that lists all of the anchor cells (and thus all of the corresponding RAN nodes 5) to which the UL WUS configuration has been sent to allow for inter-cell coordination.

[0119] It will be appreciated that the transmission of the UL WUS configuration to two RAN nodes 5 is by way of example only, and that where the communication system 1 is provided with a plurality of RAN nodes 5, the third RAN node 5-3 may send an appropriate UL WUS configuration to each RAN node 5 of the plurality of RAN nodes 5.

[0120] At step S604a, having received the UL WUS configuration from the third RAN node 5-3, the first RAN node 5-1 may decide / determine whether it can support OD SIB1 transmissions for the NES cell 9-3. Similarly, at step S604b, having received the UL WUS configuration from the third RAN node 5-3, the second RAN node 5-2 may decide / determine whether it can support OD SIB1 transmissions for the NES cell 9-3.

[0121] For example, the first and second RAN nodes 5-1, 5-2 may each decide / determine that it can support OD SIB1 transmissions for the NES cell 9-3 if they can provide an UL WUS configuration to a UE 3 in the first anchor cell 9-1 or the second anchor cell 9-2 respectively (for configuring resources for the transmission of an UL WUS by the UE 3 in the NES cell 9-3 to wake-up the third RAN node 5-3 / activate the NES cell 9-3.

[0122] As part of deciding / determining whether or not it can support OD SIB1 transmissions for the NES cell 9-3, the first and second RAN nodes 5-1, 5-2 may each check whether they can support UL WUS configuration provision to the UE 3 by checking the status of OD SIB1 transmissions for any other NES cells that they may currently be supporting. It will be appreciated for example that where the first RAN node 5-1 and / or the second RAN node 5-2 is already supporting (on-going) OD SIB1 transmissions for another NES cell or NES cells, the first RAN node 5-1 and / or second RAN node 5-2 may not have capacity to support OD SIB1 transmissions for the NES cell 9-3 provided by the third RAN node 5-3.

[0123] At step S606a, the first RAN node 5-1 sends an appropriate response message (e.g., a dedicated UL WUS configuration response message, a RAN configuration update acknowledgement message, or the like) to the third RAN node 5-3 to acknowledge receipt of the UL WUS configuration sent at step S602a. Similarly, at step S606b the second RAN node 5-2 sends an appropriate response message (e.g., a dedicated UL WUS configuration response message, a RAN configuration update acknowledgement message, or the like) to the third RAN node 5-3 to acknowledge receipt of the UL WUS configuration sent at step S602b.

[0124] Those response messages may, for example, include an appropriate indication (e.g., a flag, or the like) as to whether or not the first RAN node 5-1 and second RAN node 5-2 support UL WUS configuration provision to the UE 3 for the NES cell 9-3 e.g., whether or not the first RAN node 5-1 and the second RAN node 5-2 can provide the UL WUS configuration for the NES cell 9-3 to the UE 3 to configure resources for the transmission of an UL WUS by the UE 3 to the third RAN node 5-3.

[0125] For example, the response sent at step S606a may include an indication that the first RAN node 5-1 can support UL WUS configuration provision for the NES cell 9-3 (e.g., a yes / no indicator set to 'yes', a true / false indicator set to 'true', a single bit flag set to '1', or the like). In this scenario, the response message may also include a suggested OD SIB1 transmission activation time for the NES cell 9-3 at which, or shortly thereafter, the third RAN node 5-3 may begin 'listening' for an UL WUS from the UE 3 at, or shortly after, that activation time.

[0126] Alternatively, the response message sent at step S606a may include an indication that the first RAN node 5-1 does not support UL WUS configuration provision for the NES cell 9-3 (e.g., a yes / no indicator set to 'no', a true / false indicator set to 'false', a single bit flag set to '0', or the like). In this scenario, the response message may also include a cause value indicating why UL WUS configuration provision for the NES cell 9-3 is not supported. For example, UL WUS configuration response message may indicate that the first RAN node 5-1 does not support UL WUS configuration provision, or that the first RAN node 5-1 is already supporting OD SIB1 transmissions for an NES cell or cells and does not have capacity to support NES cell 9-3, etc.

[0127] Similarly, the response message sent at step S606b may include an indication that the second RAN node 5-2 can support UL WUS configuration provision for the NES cell 9-3 (e.g., a yes / no indicator set to 'yes', a true / false indicator set to 'true', a single bit flag set to '1', or the like) . In this scenario, the response message may also include a suggested OD SIB1 transmission activation time for the NES cell 9-3 provided by the third RAN node 5-3 at which, or shortly thereafter, the third RAN node 5-3 may begin 'listening' for an UL WUS from the UE 3 at, or shortly after, that activation time.

[0128] Alternatively, the response sent at step S606b may include an indication that the second RAN node 5-2 does not support UL WUS configuration provision for the NES cell 9-3 (e.g., a yes / no indicator set to 'no', a true / false indicator set to 'false', a single bit flag set to '0', or the like). In this scenario, the response message may also include a cause value indicating why UL WUS configuration provision for the NES cell 9-3 is not supported. For example, response message may indicate that the second RAN node 5-2 does not support UL WUS configuration provision, or that the second RAN node 5-2 is already supporting OD SIB1 transmissions for an NES cell or cells and does not have capacity to support NES cell 9-3, etc.

[0129] At step S608, whether or not a specific neighbouring RAN node (e.g., first RAN node 5-1 and / or second RAN node 5-2) supports UL WUS configuration provision for the NES cell 9-3 is recorded at the third RAN node 5-3.

[0130] By way of example only, if a response message sent at step S606a and / or S606b indicates that corresponding RAN node supports UL WUS configuration provision for the NES cell 9-3, the third RAN node 5-3 may record, in a candidate cell list, that UL WUS configuration provision for the NES cell 9-3 is supported in the corresponding anchor cell e.g., the corresponding anchor cell may be recorded in the candidate cell list, and may where appropriate, also include other appropriate information to identify the RAN node that provides the that anchor cell.

[0131] Similarly, by way of example only, if a response message sent at step S606a or S606b indicates that the corresponding RAN node does not support UL WUS configuration provision for the NES cell 9-3, the third RAN node 5-3 may record, in a non-candidate cell list, that UL WUS configuration provision for the NES cell 9-3 is not supported in the corresponding anchor cell e.g., the corresponding anchor cell may be recorded in the non-candidate cell list, and may where appropriate, also include other appropriate information to identify the RAN node 5 that provides that anchor cell. RAN nodes 5 providing a cell 9 that is listed in the non-candidate cell list may, for example, not expect to receive another UL WUS configuration relating to that cell for a period of time (which may be a pre-configured or hardcoded period of time).

[0132] Alternatively, if a response message sent at step S606a and / or S606b indicates that the corresponding RAN node 5 does not support UL WUS configuration provision for the NES cell 9-3, the third RAN node 5-3 may simply ignore that RAN node 5 and the corresponding anchor cell or cells it provides.

[0133] Optionally, where two or more neighbouring RAN nodes 5 (e.g., the first RAN node 5-1 and the second RAN node 5-2) that provide respective anchor cells (e.g., the first anchor cell 9-1 and the second anchor cell 9-2) have indicated to the third RAN node 5-3 that they can support UL WUS configuration provision for the NES cell 9-3, the third RAN node 5-3, at step S610 may select one of those anchor cells from the candidate cell list (and thus the corresponding RAN node 5 providing the selected anchor cell) for UL WUS configuration provision. For example, at step S610, the third RAN node 5-3 may select the first anchor cell 9-1 from the candidate cell list (and thus the first RAN node 5-1 providing that first anchor cell 9-1) for UL WUS configuration provision for the NES cell 9-3.

[0134] At step S612, which may occur around the same time as step S610, having selected one of the anchor cells from the candidate cell list for UL WUS configuration provision (e.g., the first anchor cell 9-1), the third RAN node 5-3 may send an appropriate cancellation message (e.g., a UL WUS configuration cancellation, or the like) to the other neighbouring RAN nodes 5 to which it initially sent the dedicated UL WUS configuration to and which do not provide the selected anchor cell (e.g., second RAN node 5-2). The cancellation message may, for example indicate to the other neighbouring RAN nodes 5 that do not provide the selected anchor cell (e.g., second RAN node 5-2) that they do not need to provide the UL WUS configuration they received from the third RAN node 5-3 to the UE 3.

[0135] Alternatively, the RAN node 5 that provides the selected anchor cell (e.g., first RAN node 5-1) and the other neighbouring RAN nodes 5 (e.g., second RAN node 5-2) may coordinate amongst each other to inform each other of which anchor cell was selected, thereby implicitly informing each other of which anchor cells were not selected. By being aware of which cell was selected and which cells were not, the other neighbouring RAN nodes 5 that do not provide the selected anchor cell (e.g., second RAN node 5-2) are aware that they do not need to provide the UL WUS configuration they received from the third RAN node 5-3 to a UE 3.

[0136] At step S614 the third RAN node 5-3 may activate the NES cell 9-3 for OD SIB1 transmissions i.e., the third RAN node 5-3 may begin 'listening' for an UL WUS from the UE 3. It will be appreciated that upon receiving such an UL WUS from the UE 3, the third RAN node 5-3 may begin transmitting OD SIB1s to the UE 3.

[0137] It will be appreciated that where the response message includes a suggested OD SIB1 transmission activation time for the NES cell 9-3 (i.e., a time at which the third RAN node 5-3 should begin 'listening' for an UL WUS), the third RAN node 5-3, at step S508, may activate the NES cell 9-3 for OD SIB1 transmissions at that indicated activation time (or sometime after that activation time). It will be appreciated that upon receiving such an UL WUS from the UE 3, the third RAN node 5-3 may begin transmission of one or more OD SIB1s to the UE 3.

[0138] Having received the response message indicating that a specific neighbouring RAN node supports UL WUS configuration provision for the NES cell 9-3, it will be appreciated that the third RAN node 5-3 may occasionally need to send an updated UL WUS configuration to that specific neighbouring RAN node 5 (step S616). For example, in response to the third RAN node 5-3 updating its UL WUS configuration, it may forward that updated UL WUS configuration to the specific neighbouring RAN node.

[0139] It will be appreciated that in response to receiving the updated UL WUS configuration the full procedure of Fig. 6 may be re-started at step S602.

[0140] Fig. 7 illustrates a simplified sequence diagram of an example procedure for UL WUS configuration provision for the transmission of a WUS to an NES cell that supports on-demand SIB transmissions.

[0141] As shown in Fig. 7, there is provided a first RAN node 5-1 providing a first anchor cell 9-1, a second RAN node 5-2, providing a second anchor cell 9-2, and a third RAN node 5-3 providing an NES cell 9-3.

[0142] At step S702a the third RAN node 5-3 sends an appropriate UL WUS configuration request message, or the like to the first RAN node 5-1. Similarly, at step S702b the third RAN node 5-3 sends the same appropriate UL WUS configuration request message, or the like to the second RAN node 5-2. Those UL WUS configuration request messages may, for example, include a candidate cell list, or the like, that lists all of the anchor cells (and thus all of the corresponding RAN nodes 5) to which the UL WUS configuration request message has been sent to allow for inter-cell coordination.

[0143] It will be appreciated that the transmission of the UL WUS configuration request message to two RAN nodes 5 is by way of example only, and that where the communication system 1 has more than two of RAN nodes, the third RAN node 5-3 may send an appropriate UL WUS configuration request message to each RAN node 5 of the RAN nodes 5.

[0144] At step S704a, having received the UL WUS configuration request message from the third RAN node 5-3, the first RAN node 5-1 may decide / determine whether (and when) it can support OD SIB1 transmissions for the NES cell 9-3. Similarly, at step S704b, having received the UL WUS configuration request message from the third RAN node 5-3, the second RAN node 5-2 may decide / determine whether it can support OD SIB1 transmissions for the NES cell 9-3.

[0145] For example, the first and second RAN nodes 5-1, 5-2 may each decide / determine that it can support OD SIB1 transmissions for the NES cell 9-3 (and when it can support OD SIB1 transmissions for the NES cell 9-3) if they can provide a (yet-to-be received) UL WUS configuration to a UE 3 to configure resources for the transmission of an UL WUS, by the UE 3, in the NES cell 9-3 (to the third RAN node 5-3).

[0146] As part of deciding / determining whether or not it can support OD SIB1 transmissions for the NES cell 9-3, the first and second RAN nodes 5-1, 5-2 may each check whether they can (and when they can) support UL WUS configuration provision to the UE 3 by checking the status of OD SIB1 transmissions for any other NES cells that they may currently be supporting. It will be appreciated for example that where the first RAN node 5-1 and / or the second RAN node 5-2 is already supporting (on-going) OD SIB1 transmissions for another NES cell or NES cells, the first RAN node 5-1 and / or second RAN node 5-2 may not have capacity to support OD SIB1 transmissions for NES cell 9-3 as well.

[0147] At step S706a the first RAN node 5-1 sends an appropriate UL WUS configuration response message, or the like, to the third RAN node 5-3 to acknowledge receipt of the UL WUS configuration request message sent at step S702a. Similarly, at step S706b the second RAN node 5-2 sends an appropriate acknowledgement message to the third RAN node 5-3 to acknowledge receipt of the UL WUS configuration request message sent at step S702b.

[0148] Those UL WUS configuration response messages may, for example, include an appropriate indication (e.g., a flag, or the like) as to whether or not the first RAN node 5-1 and second RAN node 5-2 support UL WUS configuration provision to the UE 3 for the NES cell 9-3 e.g.,, whether or not the first RAN node 5-1 and the second RAN node 5-2 can forward a yet-to-be received UL WUS configuration for the NES cell 9-3 to the UE 3 to configure resources for the transmission of an UL WUS by the UE 3 to the third RAN node 5-3.

[0149] For example, the UL WUS configuration response message sent at step S706a may include an indication that the first RAN node 5-1 can support UL WUS configuration provision for the NES cell 9-3 (e.g., a yes / no indicator set to 'yes', a true / false indicator set to 'true', a single bit flag set to '1', or the like). In this scenario, the UL WUS configuration response message may also include a suggested OD SIB1 transmission activation time for the NES cell 9-3.

[0150] Alternatively, the UL WUS configuration response message sent at step S706a may include an indication that the first RAN node 5-1 does not support UL WUS configuration provision for the NES cell 9-3 (e.g., a yes / no indicator set to 'no', a true / false indicator set to 'false', a single bit flag set to '0', or the like). In this scenario, the UL WUS configuration response message may also include a cause value indicating why UL WUS configuration provision for the NES cell 9-3 is not supported. For example, UL WUS configuration response message may indicate that the first RAN node 5-1 does not support UL WUS configuration provision, or that the first RAN node 5-1 is already supporting OD SIB1 transmissions for an NES cell or cells and does not have capacity to support NES cell 9-3, etc.

[0151] Similarly, the UL WUS configuration response message sent at step S706b may include an indication that the second RAN node 5-2 can support UL WUS configuration provision for the NES cell 9-3 (e.g., a yes / no indicator set to 'yes', a true / false indicator set to 'true', a single bit flag set to '1', or the like). In this scenario, the UL WUS configuration response message may also include a suggested OD SIB1 transmission activation time for the NES cell 9-3 provided by the third RAN node 5-3.

[0152] Alternatively, the UL WUS configuration response message sent at step S706b may include an indication that the second RAN node 5-2 does not support UL WUS configuration provision for the NES cell 9-3 (e.g., a yes / no indicator set to 'no', a true / false indicator set to 'false', a single bit flag set to '0', or the like). In this scenario, the UL WUS configuration response message may also include a cause value indicating why UL WUS configuration provision for the NES cell 9-3 is not supported. For example, UL WUS configuration response message may indicate that the second RAN node 5-2 does not support UL WUS configuration provision, or that the second RAN node 5-2 is already supporting OD SIB1 transmissions for an NES cell or cells and does not have capacity to support NES cell 9-3, etc.

[0153] At step S708, whether or not a specific neighbouring RAN node 5 (e.g., first RAN node 5-1 and / or second RAN node 5-2) supports UL WUS configuration provision for the NES cell 9-3 is recorded at the third RAN node 5-3.

[0154] By way of example only, if an UL WUS configuration response message sent at step S706a and / or S706b indicates that the corresponding RAN node 5 supports UL WUS configuration provision for the NES cell 9-3, the third RAN node 5-3 may record, in a candidate cell list, that UL WUS configuration provision for the NES cell 9-3 is supported in the corresponding anchor cell e.g., the corresponding anchor cell may be recorded in the candidate cell list, and may where appropriate, also include other appropriate information to identify the RAN node 5 that provides that anchor cell.

[0155] Similarly, by way of example only, if an UL WUS configuration response message sent at step S706a or S706b indicates that the corresponding RAN node 5 does not support UL WUS configuration provision for the NES cell 9-3, the third RAN node 5-3 may record, in a non-candidate cell list, that UL WUS configuration provision for the NES cell 9-3 is not supported in the corresponding anchor cell e.g., the corresponding anchor cell may be recorded in the non-candidate cell list, and may where appropriate, also include other appropriate information to identify the RAN node 5 that provides that anchor cell. RAN nodes 5 providing a cell that is listed in the non-candidate cell list may, for example, not expect to receive another UL WUS configuration relating to that cell for a period of time (which may be a pre-configured or hardcoded period of time).

[0156] Alternatively, if an UL WUS configuration response message sent at step S706a and / or S706b indicates that the corresponding RAN node 5 does not support UL WUS configuration provision for the NES cell 9-3, the third RAN node 5-3 may simply ignore that RAN node 5 and the corresponding anchor cell or cells it provides.

[0157] At step S710 the third RAN node 5-3 selects one of those anchor cells from the candidate cell list (and thus the corresponding RAN node 5 providing the selected anchor cell) for UL WUS configuration provision for the NES cell 9-3. For example, at step S710, the third RAN node 5-3 may select the first anchor cell 9-1 from the candidate cell list (and thus the first RAN node 5-1 providing that first anchor cell 9-1) for UL WUS configuration provision for the NES cell 9-3.

[0158] At step S712, which may occur around the same time as step S710, having selected one of the anchor cells from the candidate cell list for UL WUS configuration provision (e.g., the first anchor cell 9-1), the third RAN node 5-3 may provide that RAN node 5 that provides the selected anchor cell (e.g., the first RAN node 5-1) with an appropriate UL WUS configuration (or NG-RAN node configuration update, or the like) for the NES cell 9-3. That UL WUS configuration (or NG-RAN node configuration update, or the like) may, for example, include appropriate information to configure resources for the transmission of an UL WUS by the UE 3 to the third RAN node 5-3 providing the NES cell 9-3 at some future time to wake-up that RAN node 5-3 when the NES cell it provides is wanted / needs to be accessed by the UE 3.

[0159] At step S714, the RAN node 5 that was provided with an appropriate UL WUS configuration (or NG-RAN node configuration update, or the like) for the NES cell 9-3 (e.g., the first RAN node 5-1) may optionally send an UL WUS configuration response message to the third RAN node 5-3 to acknowledge receipt of the UL WUS configuration (or NG-RAN configuration update, or the like) sent at step S710.

[0160] At step S716, the third RAN node 5-3 may activate the NES cell 9-3 for OD SIB1 transmissions e.g., the third RAN node 5-3 may begin 'listening' for an UL WUS from the UE 3. It will be appreciated that upon receiving such an UL WUS from the UE 3, the third RAN node 5-3 may begin transmitting OD SIB1s to the UE 3.

[0161] Having received an UL WUS configuration response message indicating that a specific neighbouring RAN node 5 supports UL WUS configuration provision for the NES cell 9-3, it will be appreciated that the third RAN node 5-3 may occasionally need to send an updated UL WUS configuration to that specific neighbouring RAN node 5 (step S718). For example, in response to the third RAN node 5-3 updating its UL WUS configuration, it may forward that updated UL WUS configuration to the specific neighbouring RAN node 5.

[0162] It will be appreciated that in response to receiving the updated UL WUS configuration the full procedure of Fig. 7 may be re-started at step S702.

[0163] Providing an UL WUS configuration to a RAN node for the provision of a WUS to an NES cell for on-demand SIB1 transmissions (Case-3).

[0164] It will be appreciated that whilst the procedures shown in Figs. 5 to 7 and described above related primarily to Case-2 OD SIB1 transmissions (i.e., OD SIB1 transmissions for the NES cell that are performed in the NES cell after that NES cell has been woken up / activated via an UL WUS from the UE 3) those procedures may be appropriately adapted for Case-3 OD SIB1 transmissions (i.e., OD SIB1 transmissions for the NES cell that are provided in an anchor cell).

[0165] <Procedure of Fig. 5 - Adaptations> 　　In the procedure shown in Fig. 5, at step S502, the UL WUS configuration for the NES cell 9-3 provided to the selected neighbouring RAN node 5 (e.g., the first RAN node 5-1) may additionally include appropriate SIB1 content for the NES cell 9-3. The selected neighbouring RAN node 5 (e.g., the first RAN node 5-1) may then use that appropriate SIB1 content for OD SIB1 transmissions for the NES cell 9-3 to the UE 3 when they are triggered.

[0166] Alternatively, rather than including the appropriate SIB1 content for the NES cell 9-3 in the UL WUS configuration sent at S502, a separate message (e.g., an OD SIB1 Transfer message, or the like) may be sent to the selected RAN node 5 (e.g., the first RAN node 5-1) that includes the appropriate SIB1 content for the NES cell 9-3.

[0167] <Procedure of Fig. 6 - Adaptations> 　　In the procedure shown in Fig. 6, at steps S602a and S602b, the UL WUS configurations for the NES cell 9-3 provided to the plurality of RAN nodes 5 (e.g., the first RAN node 5-1 and the second RAN node 5-2) may additionally include appropriate SIB1 content for the NES cell 9-3. The selected neighbouring RAN node 5 (e.g., the first RAN node 5-1 selected at step S610) may then use that appropriate SIB1 content for OD SIB1 transmissions for the NES cell 9-3 to the UE 3 when they are triggered.

[0168] Alternatively, rather than including the appropriate SIB1 content for the NES cell 9-3 in the UL WUS configurations sent at S602a and S602b, a separate message (e.g., a OD SIB1 Transfer message, or the like) may be sent to the to the plurality of RAN nodes 5 (e.g., the first RAN node 5-1 and the second RAN node 5-2) that includes the appropriate SIB1 content for the NES cell 9-3.

[0169] < Procedure of Fig. 7 - Adaptations> 　　In the procedure shown in Fig. 7, having selected one of the anchor cells from the candidate cell list (and thus the corresponding RAN node 5 providing the selected anchor cell) for UL WUS configuration provision for the NES cell 9-3 at step S710, the third RAN node 5-3 may send appropriate SIB1 content for the NES cell 9-3 to the RAN node 5 providing the selected anchor cell (e.g., the first RAN node 5-1) with the UL WUS configuration or in a dedicated message (e.g., a OD SIB1 Transfer message, or the like).

[0170] <Implementation of Split CU / DU RAN architectures in the procedures of Figs. 6 and 7> 　　It will be appreciated that whilst the procedures described above with reference to Figs. 6 and 7 have been described in the context of a non-split RAN architecture, one or more of the RAN nodes 5 (e.g., the first, second, and third RAN nodes 5-1, 5-2, 5-3) may, nevertheless, be distributed RAN nodes 5, each comprising a central unit (CU) and one or more distributed units (DUs). In this scenario, appropriate adaptations of the procedures of Figs. 5 to 7 may need to be implemented to facilitate CU / DU coordination, and the like.

[0171] <Procedure of Fig. 6 - Adaptations> 　　In the procedure shown in Fig. 6, where the third RAN node 5-3 is a distributed RAN node with a CU and at least one DU, it will be appreciated that the UL WUS configurations sent to neighbouring RAN nodes at steps S602a, S602b, may be sent by the CU of the third RAN node 5-3. However, a DU of the third RAN node 5-3 may send the UL WUS Configuration message to the CU for subsequent transmission to the RAN node 5 providing the selected cell. It will be appreciated that the CU of the third RAN node 5-3 may include, in the UL WUS configuration to be sent, the candidate cell list, or the like, that lists all of the anchor cells (and thus all of the corresponding RAN nodes 5) to which the UL WUS configuration request message has been sent to allow for inter-cell coordination.

[0172] Moreover, in the procedure shown in Fig. 6, following steps S606a and S606b in which the first and second RAN nodes 5-1, 5-2, provide respective response messages, the CU of the third RAN node 5-3 may co-ordinate all of the NES cells currently being supported by that RAN node 5-3, and decide which NES cells can use / activate OD SIB1 transmissions. The CU of the third RAN node 5-3 may then send a list of those NES cells to the DU (or DUs) of the third RAN node 5-3.

[0173] It will be appreciated that such co-ordination of the NES cells currently being supported by the third RAN node 5-3 may be performed by the CU-control place (CU-CP) which may send appropriate indications of which NES cells should be used / activated to its DU (or DUs).

[0174] In the procedure shown in Fig. 6, where the third RAN node 5-3 is a distributed RAN node, it will be appreciated that a DU of the third RAN node 5-3 may select one of the candidate cells from the candidate cell list at step S610. In this scenario, any UL WUS configuration cancellation message that is to be sent to a RAN node 5 that provide any cell other than the selected one may be sent by the DU to the CU of the third RAN node 5-3 first, for subsequent transmission to the other RAN nodes 5.

[0175] <Procedure of Fig. 7 - Adaptations> 　　In the procedure shown in Fig. 7, where the third RAN node 5-3 is a distributed RAN node with a CU and at least one DU, it will be appreciated that the UL WUS configuration requests sent to neighbouring RAN nodes 5 at steps S702a, S702b, may be sent by the CU of the third RAN node 5-3. However, a DU of the third RAN node 5-3 may send the UL WUS configuration requests to the CU of the third RAN node 5-3 for subsequent transmission to the neighbouring RAN nodes 5.

[0176] Moreover, in the procedure shown in Fig. 7, following steps S706a and S706b in which the first and second RAN nodes 5-1, 5-2, provide respective response messages, the CU of the third RAN node 5-3 may co-ordinate all of the NES cells currently being supported by that RAN node 5-3, and decide which NES cells can use / activate OD SIB1 transmissions. The CU of the third RAN node 5-3 may then send a list of those NES cells to the DU (or DUs) of the third RAN node 5-3.

[0177] It will be appreciated that such co-ordination of the NES cells currently being supported by the third RAN node 5-3 may be performed by the CU-control place (CU-CP) which may send appropriate indications of which NES cells should be used / activated to its DU (or DUs).

[0178] In the procedure shown in Fig. 7, where the third RAN node 5-3 is a distributed RAN node, it will be appreciated that a DU of the third RAN node 5-3 may select the cell to which to transmit the UL WUS configuration at step S710. In this case, the UL WUS Configuration message may be transmitted from the DU to the CU for subsequent transmission to the RAN node 5 providing the selected cell.

[0179] Several enhanced procedures and techniques for implementing on-demand SSB transmissions for NES cells in the communication system 1 will now be described, by way of example only, with reference to Figs. 8 and 9.

[0180] <Implementation of On-demand SSB Transmissions for NES Cells> 　　Fig. 8 illustrates a simplified sequence diagram of an example on-demand SSB transmissions procedure that may be implemented in the communication system illustrated in Fig. 1. As shown in Fig. 8, there is provided a first RAN node 5-1 comprising a CU 5-1CUand a DU 5-1DUand a UE 3. At step S802, the first RAN node CU 5-1CUsends an appropriate on-demand (OD) SSB indication to the first RAN node DU 5-1DUto indicate to the first RAN node DU 5-1DUthat it should trigger OD SSB transmissions to the UE 3 of the communication system 1 for a SCell (e.g., a SCell provided by the first RAN node 5-1 through carrier aggregation techniques, or the like).

[0181] The OD SSB indication sent to the first RAN node DU 5-1DUmay, for example, include a list of SCells for which the first RAN node DU 5-1DUshould provide OD SSB transmissions to the UE 3.

[0182] The OD SSB indication may also include, for example, an indication of an SSB operation mode, or the like. For example, the OD SSB indication may include an indication that OD SSB transmissions for one or more SCells indicated in the list of SCells should be activated / deactivated for the UE 3. Additionally, where the OD SSB indication indicates that OD SSB transmissions for a specific SCell should be activated, the OD SSB indication may also indicate whether the SCell should operate with 'no-always-on' SSB transmissions, 'always-on' SSB transmissions with a long periodicity, or 'always-on' SSB transmissions with a normal (legacy) periodicity.

[0183] The OD SSB indication may also include suggested OD SSB operation parameters, or the like. For example, the OD SSB indication may include appropriate operational parameters for OD SSB transmissions for a SCell such as, e.g. an SSB broadcast periodicity, and / or a UE measurement timing configuration (periodicity, duration, SSB burst time instance, etc.).

[0184] It will be appreciated that where the operational parameters for OD SSB transmissions for a SCell includes a UE measurement timing configuration, that UE measurement timing configuration will need to be forwarded to the UE 3 for the UE 3 to implement that UE measurement timing configuration. For example, the UE measurement timing configuration may be forwarded to the UE 3 by the first RAN node DU 5-1DUwith an appropriate SCell activation command, OD SSB activation indication, or the like.

[0185] At step S804, based on the OD SSB indication received at step S802, the first RAN node DU 5-1DUdecided whether (and when) to activate / de-active OD SSB transmissions for one or more SCells provided by the first RAN node DU 5-1DU.

[0186] It will be appreciated that once the first RAN node DU 5-1DUhas decided to activate / de-active OD SSB transmissions for one or more SCells, the first RAN node DU 5-1DUmay send (not shown) and appropriate SCell activation / deactivation command, an OD SSB activation / deactivation indication, or the like to the UE 3. That command / indication may also include a UE measurement timing configuration where appropriate.

[0187] At step S806, the first RAN node DU 5-1DUmay then send appropriate SSB transmissions to the UE 3 for activated SCells.

[0188] Fig. 9 illustrates a simplified sequence diagram of another example on-demand SSB transmissions procedure that may be implemented in the communication system illustrated in Fig. 1. As shown in Fig. 9, there is provided a first RAN node 5-1, a second RAN node 5-2 comprising a CU 5-2CUand a DU 5-2DUand a UE 3.

[0189] At step S902, the first RAN node 5-1 sends an appropriate cell activation request, on-demand SSB activation request, or the like, to the second RAN node CU 5-2CUto indicate to the second RAN node CU 5-2CUthat it should trigger OD SSB transmissions to the UE 3 of the communication system 1 for a SCell (e.g., a SCell provided by the first RAN node 5-1 through carrier aggregation techniques, or the like).

[0190] The appropriate cell activation request, on-demand SSB activation request, or the like, sent to the second RAN node CU 5-2CUmay, for example, include a list of SCells for which the first RAN node DU 5-1DUshould provide OD SSB transmissions to the UE 3.

[0191] The cell activation request, on-demand SSB activation request, or the like may also include, for example, an indication of an SSB operation mode, or the like. For example, the cell activation request, on-demand SSB activation request, or the like may include an indication that OD SSB transmissions for one or more SCells indicated in the list of SCells should be activated / deactivated for the UE 3. Additionally, where the cell activation request, on-demand SSB activation request, or the like, indicates that OD SSB transmissions for a specific SCell should be activated, it may also indicate whether the SCell should operate with 'no-always-on' SSB transmissions, 'always-on' SSB transmissions with a long periodicity, or 'always-on' SSB transmissions with a normal (legacy) periodicity.

[0192] The cell activation request, on-demand SSB activation request, or the like, may also include suggested OD SSB operation parameters, or the like. For example, it may include appropriate operational parameters for OD SSB transmissions for a SCell such as, e.g. an SSB broadcast periodicity, and / or a UE measurement timing configuration (periodicity, duration, SSB burst time instance, etc.).

[0193] It will be appreciated that where the operational parameters for OD SSB transmissions for a SCell includes a UE measurement timing configuration, that UE measurement timing configuration will need to be forwarded to the UE 3 for the UE 3 to implement that UE measurement timing configuration. For example, the UE measurement timing configuration may be forwarded to the UE 3 by the second RAN node CU 5-2CUwith an appropriate SCell activation command, OD SSB activation indication, or the like.

[0194] At step S904, the second RAN node CU 5-2CU, having received the cell activation request, on-demand SSB activation request, or the like, may send an appropriate CU configuration update, on-demand SSB activation request, or the like to a second RAN node DU 5-2DUof the second RAN node 5-2. For example, the second RAN node CU 5-2CUmay use existing F1 setup procedures and / or RAN node CU configuration update procedures over an appropriate interface (e.g., an F1 interface) between the second RAN node CU 5-2CUand the second RAN node DU 5-2DU.

[0195] Using those existing F1 setup procedures and / or RAN node CU configuration update procedures, at step S904, an appropriate CU configuration update, on-demand SSB activation request, or the like to the second RAN node DU 5-2DUto indicate the information that was sent by the first RAN node 5-1 to the second RAN node CU 5-2CUat step S902 to the second RAN node DU 5-2DU.

[0196] At step S906, based on the appropriate CU configuration update, on-demand SSB activation request, or the like received at step S904, the second RAN node DU 5-2DUdecides whether (and when) to activate / de-active OD SSB transmissions for one or more SCells provided by the first RAN node DU 5-1DU.

[0197] It will be appreciated that once the second RAN node DU 5-2DUhas decided to activate / de-active OD SSB transmissions for one or more SCells, the second RAN node DU 5-2DUmay send (not shown) and appropriate SCell activation / deactivation command, an OD SSB activation / deactivation indication, or the like to the UE 3. That command / indication may also include a UE measurement timing configuration where appropriate.

[0198] At step S908, the second RAN node DU 5-2DUmay then send appropriate SSB transmissions to the UE 3 for activated SCells.

[0199] <Devices of the Communication System> <User Equipment> 　　Fig. 10 is a schematic block diagram illustrating the main components of a UE 3 as shown in Fig. 1.

[0200] 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 (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.

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

[0202] The communication control module 43 is operable to control the communication between the UE 3 and its serving RAN node or RAN nodes 5 (and other communication devices connected to the RAN node 5, such as further UEs 3 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.

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

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

[0205] <RAN node (non-distributed)> 　　Fig. 11 is a schematic block diagram illustrating the main components of a RAN node 5N for the communication system 1 shown in Fig. 1. As shown, the RAN node 5N 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 5N may also be coupled to other RAN nodes via an appropriate interface (e.g., the so-called 'Xn' interface in NR). The RAN node 5N has a controller 57 to control the operation of the RAN node 5N. 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 5N by, in this example, program instructions or software instructions stored within memory 59.

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

[0207] The communications control module 63 is operable to control the communication between the RAN node 5N and UEs 3 and other network entities that are connected to the RAN node 5N. 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.

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

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

[0210] <RAN node (distributed)> 　　Fig. 12 is a simplified block schematic illustrating the main components of a distributed RAN node 5D comprising a distributed type of base station for implementation in the system of Fig. 1. As shown, the RAN node 5D includes a central unit (RAN node CU) 5DCUand a distributed unit (RAN node DU) 5DDU(although it may include other RAN node DUs 5DDUas described above). Each unit 5DCU, 5DDUincludes respective transceiver circuitry 51c, 51d.

[0211] The transceiver circuitry 51d of the distributed unit 5DDUis 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 5DCUvia an interface, for example the distributed unit side of an F1 interface (which may be provided over a satellite radio interface).

[0212] The transceiver circuitry 51c of the central unit 5DCUis operable to transmit signals to and to receive signals from functions of the core network 7 and / or other RAN nodes 5 via a network interface 55c. The network interface typically includes an 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 5. The transceiver circuitry 51c of the central unit 5DCUis also operable to transmit signals to and to receive signals from one or more distributed units 5DDU, for example the central unit side of the F1 interface provided.

[0213] Each unit 5DCU, 5DDUincludes 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 5DCUand the distributed unit 5DCU. 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.

[0214] Each communications control module 63c, 63d is operable to control the communication of its corresponding unit 5DCU, 5DDUincluding the communication from one unit to the other. The communications control module 63d of the distributed unit 5DDUcontrols communication between the distributed unit 5DDUand the UEs 3, and the communications control module 63c of the central unit 5DCUcontrols communication between the central unit 5DCUand other network entities that are connected to the distributed RAN node 5D.

[0215] The communications control modules 63c, 63d also respectively control the part played by the central unit 5DCUand distributed unit 5DDUin 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 5D 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 5DCUand distributed unit 5DDUin 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 5DCUand distributed unit 5DDUin 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 5DCUand distributed unit 5DDUin 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.

[0216] 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 5DCUand distributed unit 5DDU. 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 5DCUand distributed unit 5DDUappropriately depending on where the functional split is configured between the central unit 5DCUand distributed unit 5DDU.

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

[0218] <Modifications and Alternatives> 　　Detailed examples been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above examples whilst still benefiting from the concepts embodied therein.

[0219] It will be appreciated that description of features of and actions performed by a RAN node (base station), apply equally to distributed type base stations as to non-distributed type base stations.

[0220] It will also be appreciated that whilst information elements having specific names have been described differently named information elements but having a similar purpose may be used.

[0221] In the above description the UE and the base station 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 disclosed enhancements, 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.

[0222] In the above examples, 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 to the UE or base station 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 UE or the base station in order to update their functionalities.

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

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

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

[0226] 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 an extended period of time.

[0227] 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; moulds 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.).

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

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

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

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

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

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

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

[0235] 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 an extended 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.

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

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

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

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

[0240] 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 an access network node, the method comprising: 　　transmitting, to another access network node, a message including information of one cell to request to at least one other cell in the another access network node to transmit configuration information for mobile devices to transmit a wakeup signal for requesting an on-demand system information block 1 (SIB1) of the one cell; and 　　receiving, from the another access network node, a response message including information indicating whether one of the at least one other cell in the another access network node will provide the configuration information to the mobile devices. 　　(Supplementary note 2) 　　　　The method according to supplementary note 1, wherein 　　the message includes the configuration information . 　　(Supplementary note 3) 　　　　The method according to supplementary note 1 or 2, wherein 　　the message includes information indicating the at least one other cell in the another access network node for requesting the transmitting the configuration information. 　　(Supplementary note 4) 　　The method according to any one of supplementary notes 1 to 3, wherein 　　the message includes information indicating to start or stop the transmitting the configuration information. 　　(Supplementary note 5) 　　The method according to any one of supplementary notes 1 to 4, wherein 　　the one of the at least one other cell in the another access network node is selected by the access network node, based on at least one of: 　　　　information configured by an Operations, Administration, and Management (OAM) functiton, 　　　　an automatic neighbour relation (ANR), or 　　　　random selection by the access network node. 　　(Supplementary note 6) 　　The method according to any one of supplementary notes 1 to 5, wherein 　　the response message includes at least one of: 　　　　information indicating a cause value to indicate a reason of reject to transmit the configuration information, or 　　　　information indicating a time indicating when transmitting the configuration information should be activated. 　　(Supplementary note 7) 　　The method according to any one of supplementary notes 1 to 6, wherein 　　the response message includes information indicating at least one cell in one access network node whose configuration information of on-demand SIB1 should be transmitted. 　　(Supplementary note 8) 　　The method according to any one of supplementary notes 1 to 7, wherein 　　the access network node is a first base station, and 　　the another access network node is a second base station. 　　(Supplementary note 9) 　　The method according to any one of supplementary notes 1 to 7, wherein 　　the access network node is a distributed unit of a distributed base station, and 　　the another access network node is a central unit of the distributed base station. 　　(Supplementary note 10) 　　A method performed by an access network node, the method comprising: 　　receiving, from another access network node, a message including information of one cell to request to at least one other cell in the access network node to transmit configuration information for mobile devices to transmit a wakeup signal for requesting an on-demand system information block 1 (SIB1) of the one cell; and 　　transmitting, to the another access network node, a response message including information indicating whether one of the at least one other cell in the access network node will provide the configuration information to the mobile devices. 　　(Supplementary note 11) 　　An access network node comprising: 　　means for transmitting, to another access network node, a message including information of one cell to request to at least one other cell in the another access network node to transmit configuration information for mobile devices to transmit a wakeup signal for requesting an on-demand system information block 1 (SIB1) of the one cell; and 　　receiving, from the another access network node, a response message including information indicating whether one of the at least one other cell in the another access network node will provide the configuration information to the mobile devices. 　　(Supplementary note 12) 　　An access network node comprising: 　　means for receiving, from another access network node, a message including information of one cell to request to at least one other cell in the access network node to transmit configuration information for mobile devices to transmit a wakeup signal for requesting an on-demand system information block 1 (SIB1) of the one cell; and 　　means for transmitting, to the another access network node, a response message including information indicating whether one of the at least one other cell in the access network node will provide the configuration information to the mobile devices. 　　(Supplementary note 13) 　　A method performed by a distributed unit of a base station, the method comprising: 　　receiving, from a central unit of the base station, a message including information of at least one cell for the at least one cell in the distributed unit to transmit an on-demand synchronizatrion signal / physical broadcast channel (PBCH) block (SSB) of the at least one cell; and 　　determining to activate or deactivate to transmit the on-demand SSB of the at least one cell. 　　(Supplementary note 14) 　　A distributed unit of a base station comprising: 　　means for receiving, from a central unit of the base station, a message including information of at least one cell for the at least one cell in the distributed unit to transmit an on-demand synchronizatrion signal / physical broadcast channel (PBCH) block (SSB) of the at least one cell; and 　　means for determining to activate or deactivate to transmit the on-demand SSB of the at least one cell.

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

[0242] 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 53 ANTENNA 55 CORE NETWORK INTERFACE 57 CONTROLLER 59 MEMORY 61 OPERATING SYSTEM 63 COMMUNICATIONS CONTROL MODULE 51c TRANSCEIVER CIRCUIT (CU) 51d TRANSCEIVER CIRCUIT (DU) 53d AIR INTERFACE 55c NETWORK INTERFACE 57c CU CONTROLLER 57d DU CONTROLLER 59c CU MEMORY 59d DU MEMORY 61c CU OPERATING SYSTEM 61d DU OPERATING SYSTEM 63c CU COMMUNICATIONS CONTROL MODULE 63d DU COMMUNICATIONS CONTROL MODULE

Claims

1. A method performed by an access network node, the method comprising: 　　transmitting, to another access network node, a message including information of one cell to request to at least one other cell in the another access network node to transmit configuration information for mobile devices to transmit a wakeup signal for requesting an on-demand system information block 1 (SIB1) of the one cell; and 　　receiving, from the another access network node, a response message including information indicating whether one of the at least one other cell in the another access network node will provide the configuration information to the mobile devices.

2. The method according to claim 1, wherein 　　the message includes the configuration information .

3. The method according to claim 1 or 2, wherein 　　the message includes information indicating the at least one other cell in the another access network node for requesting the transmitting the configuration information.

4. The method according to any one of claims 1 to 3, wherein 　　the message includes information indicating to start or stop the transmitting the configuration information.

5. The method according to any one of claims 1 to 4, wherein 　　the one of the at least one other cell in the another access network node is selected by the access network node, based on at least one of: 　　　　information configured by an Operations, Administration, and Management (OAM) functiton, 　　　　an automatic neighbour relation (ANR), or 　　　　random selection by the access network node.

6. The method according to any one of claims 1 to 5, wherein 　　the response message includes at least one of: 　　　　information indicating a cause value to indicate a reason of reject to transmit the configuration information, or 　　　　information indicating a time indicating when transmitting the configuration information should be activated.

7. The method according to any one of claims 1 to 6, wherein 　　the response message includes information indicating at least one cell in one access network node whose configuration information of on-demand SIB1 should be transmitted.

8. The method according to any one of claims 1 to 7, wherein 　　the access network node is a first base station, and 　　the another access network node is a second base station.

9. The method according to any one of claims 1 to 7, wherein 　　the access network node is a distributed unit of a distributed base station, and 　　the another access network node is a central unit of the distributed base station.

10. A method performed by an access network node, the method comprising: 　　receiving, from another access network node, a message including information of one cell to request to at least one other cell in the access network node to transmit configuration information for mobile devices to transmit a wakeup signal for requesting an on-demand system information block 1 (SIB1) of the one cell; and 　　transmitting, to the another access network node, a response message including information indicating whether one of the at least one other cell in the access network node will provide the configuration information to the mobile devices.

11. An access network node comprising: 　　means for transmitting, to another access network node, a message including information of one cell to request to at least one other cell in the another access network node to transmit configuration information for mobile devices to transmit a wakeup signal for requesting an on-demand system information block 1 (SIB1) of the one cell; and 　　receiving, from the another access network node, a response message including information indicating whether one of the at least one other cell in the another access network node will provide the configuration information to the mobile devices.

12. An access network node comprising: 　　means for receiving, from another access network node, a message including information of one cell to request to at least one other cell in the access network node to transmit configuration information for mobile devices to transmit a wakeup signal for requesting an on-demand system information block 1 (SIB1) of the one cell; and 　　means for transmitting, to the another access network node, a response message including information indicating whether one of the at least one other cell in the access network node will provide the configuration information to the mobile devices.

13. A method performed by a distributed unit of a base station, the method comprising: 　　receiving, from a central unit of the base station, a message including information of at least one cell for the at least one cell in the distributed unit to transmit an on-demand synchronizatrion signal / physical broadcast channel (PBCH) block (SSB) of the at least one cell; and 　　determining to activate or deactivate to transmit the on-demand SSB of the at least one cell.

14. A distributed unit of a base station comprising: 　　means for receiving, from a central unit of the base station, a message including information of at least one cell for the at least one cell in the distributed unit to transmit an on-demand synchronizatrion signal / physical broadcast channel (PBCH) block (SSB) of the at least one cell; and 　　means for determining to activate or deactivate to transmit the on-demand SSB of the at least one cell.

Images