Method of mobile device, method of base station, mobile device and base station

Abstract

A method performed by a mobile device is described, the method comprising attempting to select a first cell for acquiring a system information block 1 (SIB1) receiving, via a second cell, configuration information for requesting the first cell to acquiring the SIB1 on-demand after a failure of the attempting to select the first cell; and performing a cell reselection of the first cell for acquiring the SIB1 on-demand, after receiving the configuration information.

Description

METHOD OF MOBILE DEVICE, METHOD OF BASE STATION, MOBILE DEVICE AND 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 3rdGeneration 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 mechanisms for acquiring uplink wakeup signal (UL WUS) configurations and enhancements for mobility scenarios in the context of a communication system comprising network energy saving (NES) 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 (CN).

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

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

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

[0010] 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 (WUS) 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 Synchronization Signal / Physical Broadcast Channel (PBCH) Blocks (SS Blocks / 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 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.

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

[0012] In the case of on-demand SIB1 (OD-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.

[0013] 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'.

[0014] 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., a base station to base station interface, such as 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'.

[0015] It will be appreciated that in the above cases, a single anchor cell (Cell A) can provide a respective UL WUS configuration for each of multiple NES cells, and so a single UE could acquire multiple UL WUS configurations at a given time. Similarly, a UE could store (and maintain) one, or multiple, UL WUS configurations locally.

[0016] It should also be appreciated that cell (re)selection with OD-SIB1 is a mobility procedure which is performed by UEs in RRC IDLE mode (i.e., it is not a handover (HO) procedure), and that the UE performs initial access after a successful OD-SIB1 procedure, which finishes with the UE camping on the (re)selected cell. Consequently, the UE context is usually discarded. Conversely, any UL WUS configuration and / or acquired (OD-)SIB1 could be kept as part of the UE context when performing a legacy HO, e.g., when moving to a legacy cell, which may or may not be an anchor cell (Cell A) that provides UL WUS from NES neighbour cells.

[0017] However, it is still a subject of discussion as regards to how UL WUS signals should be provisioned, and when OD-SIB provision should occur. For instance, the UL WUS configuration could be provided in system information (SI) in the anchor cell (Cell A) (as in Cases 2 and 3) - which could be either on demand SI or 'constantly broadcast' SI (i.e. SI that it is up to the RAN node to always broadcast).

[0018] As regards OD-SIB1, the SIB1 request could be before cell reselection, in which case a UE may request and store multiple WUS configurations for a predetermined (e.g. long) period, as well as performing OD-SIB1 on multiple NES cells and storing the acquired SIB1s for those cells. Alternatively, the SIB1 request could be made during cell reselection, after cell ranking, where one (OD-)SIB1 would be acquired at a time and the UE would camp as soon as the first best-ranked cell is suitable (it will be appreciated that this does not preclude the UE having obtained multiple UL WUS configurations for nearby NES cells).

[0019] Nevertheless, while procedures for controlling UE cell (re)selection in the context of NES cells, as well as procedures concerning the provision of OD-SIB1, such as those outlined above have been proposed, the currently proposed procedures do not consider a number of scenarios. For instance, how a given UE ought to behave in the case where the best-ranked cell during a cell (re)selection procedure is an OD-SIB1 cell.

[0020] For example, in a scenario in which a UE measures cells during cell selection and the best-ranking cell is an OD-SIB1 cell, then it may not be possible to camp on that cell due to a lack of directly acquirable SIB1. Conventionally, when a SIB1 cannot be decoded, a UE would bar the cell for which SIB1 could not be decoded, and then try the next best cell until a suitable available cell is found to camp on. In the case of NES OD-SIB1 cells, they may not be barred (by certain NES capable UEs at least) but, because a SIB1 cannot be decoded, the UE will, nevertheless, move onto the next best cell until a suitable available cell is found. From both the network and the UE perspective, however, it would in general be better if the UE camped on the best-ranked cell even if it is an NES OD-SIB1 cell.

[0021] Similarly, whilst agreements have been reached during standardisation as to the provision of an UL WUS Configuration as part of an anchor cell's system information, it is possible that a RAN node will not automatically transmit this information in the anchor cell. If this information is not automatically transmitted, it is not clear how a UE can acquire it.

[0022] Moreover, it is not clear how UL WUS configurations obtained for neighbouring OD-SIB1 cells during mobility from an anchor cell should be managed.

[0023] Accordingly, development of procedures to account for these scenarios 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.

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

[0025] The disclosure has a method performed by a mobile device, the method comprising attempting to select a first cell for acquiring a system information block 1 (SIB1) receiving, via a second cell, configuration information for requesting the first cell to acquiring the SIB1 on-demand after a failure of the attempting to select the first cell; and performing a cell reselection of the first cell for acquiring the SIB1 on-demand, after receiving the configuration information.

[0026] The disclosure has a method performed by a base station, the method comprising transmitting, via a second cell, configuration information for requesting a first cell to acquiring a system information block 1 (SIB1) on-demand after a failure, by a mobile device, of attempting to select the first cell for acquiring the SIB1, and wherein the configuration information is used by the mobile device in performing a cell reselection of the first cell for acquiring the SIB1 on-demand.

[0027] The disclosure has a mobile device comprising means for attempting to select a first cell for acquiring a system information block 1 (SIB1) means for receiving, via a second cell, configuration information for requesting the first cell to acquiring the SIB1 on-demand after a failure of the attempting to select the first cell; and means for performing a cell reselection of the first cell for acquiring the SIB1 on-demand, after receiving the configuration information.

[0028] The disclosure has a base station comprising means for transmitting, via a second cell, configuration information for requesting a first cell to acquiring a system information block 1 (SIB1) on-demand after a failure, by a mobile device, of attempting to select the first cell for acquiring the SIB1, and wherein the configuration information is used by the mobile device in performing a cell reselection of the first cell for acquiring the SIB1 on-demand.

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

[0030] 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 any of the methods described below. The computer implementable instructions may be provided as a signal or on a tangible computer readable medium.

[0031] Examples of apparatus and methods will now be described, by way of example, with reference to the accompanying drawings in which:

[0032] 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 flow chart illustrating a procedure by which a UE may attempt to camp on a cell during a cell (re)selection process that may be implemented in the communication system of Fig. 1;Fig. 4 illustrates a simplified sequence diagram of an example procedure by which a UE requests UL WUS Configuration information from a cell;Fig. 5 schematically illustrates an example coverage scenario comprising an anchor cell and NES cells that may be provided by the communication system of Fig. 1;Fig. 6 illustrates a simplified sequence diagram of an example procedure for the management / provision of UL WUS configurations for a UE performing a mobility procedure;Fig. 7 illustrates schematically illustrates another example coverage scenario comprising anchor cells and a NES cell that may be provided by the communication system of Fig. 1;Fig. 8 illustrates a simplified sequence diagram of another example procedure for the management / provision of UL WUS configurations for a UE performing a mobility procedure;Fig. 9 schematically illustrates another example coverage scenario comprising anchor cells and a NES cell that may be provided by the communication system of Fig. 1;Fig. 10 illustrates a simplified sequence diagram of another example procedure for the management / provision of UL WUS configurations for a UE performing a mobility procedure;Fig. 11 is a schematic block diagram illustrating the main components of a UE as shown in Fig. 1; andFig. 12 is a schematic block diagram illustrating the main components of a RAN node for implementation in the communication system of Fig. 1.

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

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

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

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

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

[0038] Each RAN node 5-1, 5-2 illustrated is a non-distributed base station (e.g., an integrated base station). 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 (e.g. 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).

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

[0040] 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 3 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0056] <Synchronisation Signal 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).

[0057] 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 3. 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 3 differentiate between neighbouring cells and synchronize with the correct cell).

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

[0059] 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 (SI) transmitted on the PDSCH. Other SI is also known as On-Demand SI because RAN node 5 may transmit / broadcast these SIBs when explicitly requested by one or more UEs 3. 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 the RAN node 5.

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

[0061] 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 base station of the RAN 5 to the UE 3. Moreover, a UE 3 and the RAN node 5 of the communication system 1 may perform a two-step RACH procedure (e.g., as described in the introduction).

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

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

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

[0065] 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 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 (e.g., the cell that provides the best service quality - in the case of Fig. 2, cell 9-1).

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

[0067] Such NES cells (whether provided by the same, or a different RAN from the anchor cell on which the 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. A 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.

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

[0069] 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 a NES cell, one of the RAN nodes 5, has to provide an appropriate SSB / SIB for that NES cell.

[0070] <Mechanisms for Acquiring UL WUS Configuration and Enhancements for Mobility Scenarios> 　　Beneficially, the communication system 1 is configured to support one or more mechanisms for acquiring an UL WUS configuration and / or one or more enhancements for UE mobility scenarios in the context of a communication network having one or more NES cells.

[0071] Several enhanced procedures and techniques will now be described, by way of example only, with reference to Figs 3 to 10.

[0072] <Cell (Re)Selection Procedures when a Best-Ranked Cell cannot be Camped on> 　　Fig. 3 is a simplified flow chart illustrating a procedure by which a UE 3 may attempt to camp on a cell during a cell (re)selection process that may be implemented in the communication system 1.

[0073] In step S300, the UE 3 is in RRC IDLE mode. The UE 3, if not already camped on any cell, initiates a cell selection procedure. Alternatively, if the UE 3 is already camped on a cell but starts moving away from that cell, the UE 3 initiates a cell reselection procedure. During the (re)selection procedure, the UE 3 scans for nearby cells, determines and rank-orders which cells would be the most suitable to camp on (e.g. based on quality metrics of signals received from the nearby cells).

[0074] Once the nearby cells have been rank-ordered, the UE 3 then attempts to camp on the best-ranked cell in step S301. If the UE 3 can decode a SIB1 transmitted in the cell on which it wishes to camp, the UE 3 may then (re)select this cell to camp on in step S302, ending the cell (re)selection procedure.

[0075] If the UE 3 fails to camp on the best-ranked cell at step S303 (e.g., due to failure to detect / decode SIB1 of the best-ranked cell), the UE 3 stores / maintains (remembers) that cell's information (e.g. a cell identity), along with a (validity) timer (or time stamp) and possibly appropriate cell measurements, for future cell reselection procedures. The UE 3 maintains this information for a time period determined by the timer / timestamp. The time period may be adjustable and based on e.g. RSRP of the best-ranked cell and / or the RSRP difference between the best-ranked cell (which in this case is a NES Cell) and the second best-ranked cell (with a longer time period being set for a bigger difference).

[0076] During this time period the UE 3 looks through the list of rank-ordered cells for a potential anchor cell to camp on, and camps on that anchor cell if found (step S304) in an attempt to obtain a WUS configuration for the best-ranked cell. It will be appreciated that if a UL WUS configuration for the best-ranked cell is not explicitly provided in the anchor cell, then the UE 3 can request the RAN node that is providing the anchor cell for the UL WUS configuration for the best-ranked cell.

[0077] If during step S303 the UE 3 knows that the best-ranked cell on which the UE 3 attempted to camp is a NES OD-SIB1 cell (for instance, this NES cell broadcasts this information in a MIB / DCI or the UE 3 has already stored this information locally), then the UE 3 may leave the cell unbarred whilst it seeks to obtain a WUS configuration, from the anchor cell until the time period expires.

[0078] If during step S303 the UE 3 does not know whether the best-ranked cell on which the UE 3 attempted to camp is a NES OD-SIB1 cell, then the UE 3 may bar that cell while it attempts to establish whether that cell is an OD-SIB1 cell during the time period (e.g., by attempting to find an anchor cell to camp on in order to enquire whether the cell is an OD-SIB1 cell). If the cell is established to be an OD-SIB1 cell, then the UE 3 can unbar it.

[0079] Thus, for the UE 3 that knows that the best-ranked cell is an OD-SIB1 cell the time period acts as a limit to obtain a WUS configuration to initiate OD-SIB1 after which the UE 3 can give up and bar the cell. However, for the UE 3 that does not know that the best-ranked cell is an OD-SSB cell, the time period acts as a time during which the UE 3 can enquire about the cell and unbar it if found to be an OD-SIB1 cell by an anchor cell.

[0080] It will be appreciated that, if it is possible for the UE 3 to directly find an anchor cell (Cell A) that can provide the targeted OD-SIB1 cell's UL WUS configuration to obtain the targeted cell's SIB1, the UE 3 can attempt to camp on this cell. The UE 3 may be configured to perform this procedure regardless of Cell A's potential ranking in the list of rank-ordered cells. This is beneficial because whilst such a Cell A could be a low ranked cell (e.g. the 50th) because it is a relatively far away coverage cell, the cells having a higher rank order may be capacity cells that cannot provide the UE 3 with an UL WUS configuration for the targeted OD-SIB1 cell. In many cases, the next best-ranked suitable cell will be an anchor cell any way (e.g. because all previous best-ranked cells were capacity cells and potentially OD-SIB1 cells (and hence not suitable for the UE 3 to camp on)).

[0081] The UE 3 may attempt to find such an anchor cell by using specific information when communicating with the RAN node that provides that cell. The specific information may, for instance, take the form of: -　　NES Cell information (broadcast in a MIB, in DCI, or via another means); -　　UE historical information (e.g. information on NES cells obtained during Cell Reselection procedures and stored locally by the UE 3 as it moves through the network. Alternately, such information could be preconfigured at the UE 3); -　　Information identifying coverage cells as opposed to capacity cells. Specifically, to avoid scanning all cells by ranking, the UE 3 seeking to obtain SIB1 for a NES OD-SIB1 cell could scan coverage cells (which can provide the targeted NES cells UL WUS configuration) based on e.g. frequency location and SSB / MIB / DCI for such coverage cells that could provide the required information.

[0082] If the time period expires before any anchor cell providing an UL WUS configuration can be found (S305), then the UE 3 may bar the best-ranked cell and simply camp on the next best-ranked cell (S309).

[0083] If, however, the initial best-ranked cell was an OD-SIB1 cell, and the UE 3 successfully camps on an anchor cell that provides it with an UL WUS configuration for that cell before the time period expires, then the UE 3 may initiate OD-SIB1 acquisition to acquire a valid SIB1 for that cell (S306).

[0084] It will be appreciated that if the time period expires during or after acquisition of the UL WUS configuration, then the UE can still perform OD-SIB1 acquisition, but may discard previous measurements and reacquire cell measurements for cell reselection. This way, the time period may also be used to indicate whether the cell ranking (and associated measurements for measured cells) are still valid and can thus remove the need for the UE 3 to perform an unnecessary full cell reselection procedure after a short amount of time (governed by time period). As noted above, the time period may be adjustable and based on e.g. RSRP of the best-ranked cell and / or the RSRP difference between the best-ranked cell and the second best-ranked cell. The bigger the difference, the longer the cell ranking will remain valid and hence the longer the time period.

[0085] If a valid SIB1 is acquired (and the cell is suitable), then the UE 3 can then either perform legacy cell reselection using the acquired SIB1 of the original best-ranked cell (step S307) (if the time period has expired). Nevertheless, if the time period started in step S300 has not expired, the original best-ranked cell can still be considered to be the best-ranked and the UE 3 can immediately camp on the OD-SIB1 cell (i.e. no cell reselection is needed) in step S308.

[0086] It will be appreciated that where a RAN node provides UL WUS Configuration information in an anchor cell automatically (e.g., via "constantly broadcast" SI), then a UE 3 can always obtain up-to-date UL WUS configuration information, with a conventional system information (SI) update mechanism, albeit that such a configuration may be large because it will include RACH configuration information and potential information on, for instance, SIB1 monitoring, amongst other things.

[0087] Accordingly, it may be that a RAN node 5 does not provide UL WUS Configuration information in an anchor cell automatically.

[0088] The communication system 1 may configured to support a procedure, by which the UE 3 may request UL WUS Configuration information from a cell. Fig. 4 is a simplified signalling diagram illustrating such a procedure, by which the UE 3 may request UL WUS Configuration information in the event that the information is not automatically provided in a cell, that may be implemented in the communication system 1.

[0089] The RAN node 5-1 operating anchor cell 9-1, in step S400, transmits a system information block (e.g. SIBXX) to the UE 3. Whilst the RAN node 5-1 does not provide an UL WUS Configuration automatically, the RAN node 5-1 nevertheless is configured to provide basic information in this SIB to assist the UE 3 to obtain UL WUS configuration information for NES cells (e.g. NES cell 9-3 operated by a RAN node 5-3). The basic information may comprise, for example, at least an indication of the PCI and frequency of NES Cells (e.g. NES cells neighbouring anchor cell 9-1). The basic information may, nevertheless, further comprise access restriction information which indicates one or more cells which the UE 3 is restricted from accessing.

[0090] Upon receipt of the SIBXX, and to obtain UL WUS configuration information from the anchor cell 9-1, the UE 3 in step S401 triggers transmission of an UL WUS configuration request message to the anchor cell 9-1 (step S402). Transmission of an UL WUS configuration request may, for example be triggered in response to occurrence of a given event and / or a particular criterion being met. For example, transmission of an UL WUS configuration request may be triggered in any of the following scenarios: -　　Option 0: Upon camping on the anchor cell 9-1 (i.e. similar to broadcasting UL WUS configuration information, but beneficially network resources may be saved); -　　Option 1: Upon camping on the anchor cell 9-1 if the UE 3 learns from the received SIBXX that a NES cell is suitable (i.e. the UE is not restricted from accessing one or more NES cells); -　　Option 2: According to cell measurements, e.g. if one or more NES cells are detected by the UE 3 as being above a signal quality threshold relative to the signal quality received with respect to the anchor cell 9-1; -　　Option 3: Before Cell reselection (to save time of requesting UL WUS configuration information during later stages of cell reselection); and / or -　　Option 4: During Cell reselection just before OD-SIB1 request (i.e. UL WUS config request and OD-SIB1 are performed in a row).

[0091] If the basic information provided in the earlier SIB comprises access restriction information then, to reduce the number of requests for UL WUS Configuration information where there is a plurality of NES cells, the UE 3 may be configured to only transmit an UL WUS configuration request message S402 in respect of cells which it can access, thereby simplifying the cell reselection procedure and reducing resource utilisation at the UE 3 and at the network-side.

[0092] Having received the UL WUS configuration request message, the anchor cell 9-1 provides, in step S403, a UL WUS configuration request response message comprising the UL WUS configuration information requested by the UE 3. Note that for Case 3, the RAN node 5-1 may (alternatively or additionally) be configured to provide SIB1 for each NES cell that the UE 3 requested UL WUS Configuration information for.

[0093] Once in receipt of UL WUS Configuration information for respective NES cells, the UE 3 may then obtain, in step S404, NES OD-SIB1 for one or more NES cells for which UL WUS Configuration information was requested (unless, of course, the RAN node 5-1 has provided the SIB1 in the anchor cell).

[0094] It will be appreciated that the above-described UL WUS Configuration Request procedures may be applicable to specific types of UEs 3 (e.g. NES-capable UEs). A newly dedicated SIB which indicates access to OD-SI for the above procedures can be provided to UEs 3 to ensure this. However, a further indication in SIB1 may be included to indicate that the resources are only reserved for the UEs 3 that are capable of making a NES OD-SIB1 request.

[0095] To ensure that UEs 3 have the most up to date information, the UL WUS configuration information provided in step S403 (or the SIB1 in respect of Case 3) may be provided with a validity timer (not shown in Fig. 4). The validity timer is provided with a predetermined time until its expiry, upon which the UE 3 may re-acquire that UL WUS configuration information (and / or SIB1 in Case 3) from the anchor cell (e.g. when there is an occurrence of a given event and / or a particular criterion being met, such as in respect of options 0 to 4 presented above, or the like). Beneficially, therefore, the network need not update all its (potentially many) NES configurations either periodically, or whenever one configuration changes, and instead only UEs 3 having received a validity timer which subsequently expires would request the updated NES configuration / updated SIB1.

[0096] The validity timer may remain valid as long as a UE 3 remains in its serving cell, or may remain valid once the UE 3 leaves its serving cell as will be described in the following.

[0097] As described above, a UE 3 can obtain UL WUS configuration information (or a SIB1) for suitable NES cells. However, the UE 3 may be moving through the network and hence UL WUS configurations may be acquired, discarded, and reacquired regularly. Moreover, UL WUS configurations may become obsolete in a cell due to UL WUS configuration changes.

[0098] Accordingly, the validity of the UL WUS configuration information would benefit from being managed. The management of UL WUS configuration validity for other OD-SIB1 Cells during mobility from a Cell A falls into one of the following scenarios: 　　Scenario A: The UE 3 moves to a NES Cell that does not provide neighbouring OD-SIB1 Cell UL WUS configurations; 　　Scenario B: The UE 3 moves to a second anchor cell that provides neighbouring OD-SIB1 Cell UL WUS configurations for neighbouring cells in an original anchor cell; and 　　Scenario C: The UE 3 moves to a second anchor cell that does not provide neighbouring NES Cell UL WUS configurations for some cells in an original anchor cell. 　　Each of these scenarios will now be described in detail in the following.

[0099] <Scenario A> 　　To better illustrate scenario A, reference will now be made to Fig. 5, which schematically illustrates a network environment in which a UE 3 may initially be located. As illustrated, the UE 3 is initially located within the coverage area of a large anchor cell 9Aprovided by a RAN node 5A. Within that anchor cell 9Athere may also be several smaller (capacity) cells provided by other RAN nodes 5 (e.g., NES cell 9Band NES cell 9Cprovided by a RAN node 5Band a RAN node 5Crespectively) which the UE 3 may wish to camp on as the UE 3 moves through the network 1 in the RRC_IDLE state. The UE's mobility in the network will now be described with reference to the signalling diagram illustrated in Fig. 6.

[0100] In scenario A, in step S601 the UE 3 performs a mobility procedure when moving to a cell 9Boperated by the RAN node 5B. The RAN node 5Bdoes not provide the UE 3 with the UL WUS configuration for neighbouring OD-SIB1 cells, e.g. that of cell 9Coperated by the RAN node 5C, although the UE 3 may have acquired cell 9C's UL WUS configuration from the cell 9A(in step S600). However, upon connecting to the cell 9Bfrom RRC_IDLE the UE 3 may discard information about the cell 9C.

[0101] Upon switching from the cell 9Ato the cell 9Bthe UE 3 has two options. In option 1, upon switching to the new cell (in this case to the cell 9B) at step S602, the UE 3 simply discards previously acquired UL WUS configurations (and possibly also SIB1 from other neighbouring cells). Hence, it can be considered that the UE 3 in this option "forgets everything" with respect to the previously acquired UL WUS configurations (and possibly also SIB1 from other neighbouring cells).

[0102] In the alternative option 2, upon switching to the new cell (again in this case to the cell 9B) at step S603, the UE 3 starts a validity timer for any previously acquired UL WUS configuration (and SIB1) (it will be appreciated that if UE 3 already received a timer with the UL WUS Configuration information, as set out above, then this timer may be used instead of starting another timer at S603). This timer can be indicated by the anchor cell 9A(e.g. during the mobility procedure) or may be a general hardcoded timer which the UE 3 starts upon switching cells. Upon expiry of the validity timer, the UE 3 can either 1) simply discard stored information in step S604 (i.e. behave analogously to the UE 3 in option 1), or 2) Attempt to reacquire UL WUS configuration (and potentially SIB1 information) in step S605 (and hence the UE 3 in this option can be considered to remember UL WUS configuration (and potentially SIB1 information) for a predetermined period of time dictated by the validity timer).

[0103] The UE 3 can then attempt to obtain the UL WUS configuration / SIB1 information of neighbouring NES cells in one of two ways.

[0104] In a first alternative, the UE attempts to reacquire the UL WUS configuration / SIB1 information from system information being broadcast in the anchor cell 9Aby the RAN node 5A, in step S606. It will be appreciated that the anchor cell 9Ais available to / suitable for the UE 3, as otherwise the UE 3 stops the procedure and discards the stored information.

[0105] In a second alternative, the UE 3 attempts to acquire the information via the NES cell 9Bwith dedicated signalling requesting the specific NES Cell 9cinformation (or information for a plurality of the NES cells, as may be needed) in step S607. The serving NES Cell 9Bmay then acquire this information for UE 3 e.g. via a RAN node to RAN node interface (e.g., Xn) with the cell 9Aor the cell 9C, or via the NG interface with an AMF 10-1. The UE 3 may continue to run the validity timer until it acquires the relevant information from the cell 9B.

[0106] <Scenario B> 　　To better illustrate scenario B, reference will now be made to Fig. 7, which schematically illustrates that a UE 3 may initially be located within the coverage area of a large anchor cell 9A1provided by a RAN node 5A1, and the coverage area of another large anchor cell 9A2provided by a RAN node 5A2. Within the anchor cells 9A1, 9A2there may also be one or more smaller (capacity) cells provided by other RAN nodes 5 (e.g., a NES cell 9Cprovided by a RAN 5C) which the UE 3 may wish to camp on as the UE 3 moves through the communication system 1 in the RRC_IDLE state. The UE's mobility in the network will now be described with reference to the signalling diagram illustrated in Fig. 8.

[0107] In scenario B, the UE 3 moves to the anchor cell 9A2that provides OD-SIB1 Cell UL WUS configurations for nearby NES cells (in this case, the NES cell 9C) in step S801, e.g. on completion of the UE 3 switching from the anchor cell 9A1to the anchor cell 9A2(optionally, the UE 3 may instead have the acquired cell 9C's UL WUS configuration from the anchor cell 9A1, in step S800, prior to the mobility procedure). The anchor cell 9A1may also inform the anchor cell 9A2of one or more NES cells whose information the UE 3 wishes to be updated (e.g. NES Cell 9C).

[0108] During the mobility procedure between the anchor cell 9A1and the anchor cell 9A2, synchronization issues may arise, leading the UE 3 to have out-of-date configuration information for NES cells. For instance, if UL WUS configuration was updated during cell switch, or if there are some base station to base station interface (e.g. Xn interface) or NG interface synchronization issues and the anchor cell 9A1and the anchor cell 9A2do not receive UL WUS configuration updates at the same time (e.g. the anchor cell 9A2received an update before the anchor cell 9A1when UE 3 was still in the anchor cell 9A1). To avoid such issues the UE 3 may, according to a first option, be configured to discard all information acquired in the anchor cell 9A1in step S803, and reacquire any relevant configuration from the anchor cell 9A2in step S804.

[0109] Alternately, according to a second option, the UE 3 may instead be configured to commence a timer upon switching to the anchor cell 9A2in step S805 to keep the UL WUS configuration acquired when the UE 3 was in the anchor cell 9A1valid, before subsequently reacquiring any relevant configuration information from the anchor cell 9A2in step S806.

[0110] <Scenario C> 　　To better illustrate scenario C, reference will now be made to Fig. 9, which schematically illustrates that a UE 3 may initially be located within the coverage area of a large anchor cell 9A1provided by a RAN node 5A1, and the coverage area of another large anchor cell 9A2provided by a RAN node 5A2. Within the anchor cells 9A1, 9A2there may also be one or more smaller (capacity) cells provided by other RAN nodes 5 (e.g., a NES cell 9Cprovided by a RAN 5C) which the UE 3 may wish to camp on as the UE 3 moves through the communcation system 1 in the RRC_IDLE state. The UE's mobility in the network will now be described with reference to the signalling diagram illustrated in Fig. 10.

[0111] In scenario C, the UE 3 moves to the anchor cell 9A2that does not provide neighbouring OD-SIB1 Cell UL WUS configurations for a nearby NES cells (in this case, the NES cell 9C) on completion of the UE 3 switching from the cell 9A1to the cell 9A2in step S1001. Optionally, however, the UE 3 may instead have acquired Cell 9C's UL WUS configuration from the anchor cell 9A, in step S1000, prior to the mobility procedure.

[0112] The anchor cell 9A2may not provide UL WUS configuration information for all of the nearby NES cells (e.g. the cell 9C), to reduce the signalling burden at both the RAN-side and at the base station to base station (Xn / X2) level. Accordingly, even though the UE 3 may be able to scan and know about the presence of the NES cell 9Cas it moves through the network, the UE 3 cannot attempt to switch to the NES cell 9Cas it does not have an UL WUS Configuration / SIB1 for this cell.

[0113] Accordingly, once the UE 3 has camped on the anchor cell 9A2after switching from anchor cell 9A1, and provided that the anchor cell 9A1is still available for the UE 3, the UE 3 can make a specific request, e.g. via dedicated signalling, in step S1002 for the anchor cell 9A1to provide UL WUS configuration / SIB1 of the NES cell 9Cvia the anchor cell 9A2. For instance, the UE 3 may make a request for the the anchor cell 9A2to acquire such a configuration, which can be acquired e.g. via a base station to base station interface (e.g. Xn interface) between the anchor cell 9A2and the anchor cell 9A1, or via a core network node (such as an AMF 10-1) via an NG interface, and provide this information directly to the requesting UE 3 via dedicated signalling. This information may be provisioned periodically based on a validity timer initiated by the UE 3 when switching cells. Alternatively, the anchor cell 9A2may instead add the NES cell 9Cto its broadcast list for the UE 3 to obtain the UL WUS Configuration / SIB1 of the NES cell 9C, hence obviating the need for the procedure to be performed subsequently for UEs 3 switching to the anchor cell 9A2.

[0114] Another option (option 2) arises during cell reselection, wherein the UE 3 may rank-order NES cell 9Cas the best-ranked cell, and hence the UE 3 is considering camping on NES cell 9C. In this scenario the UE 3 may attempt to acquire the UL WUS Configuration / SIB1 of the NES cell 9Cfrom the anchor cell 9A1without camping on that anchor cell (S1003).

[0115] In a third option, if it transpires that after the mobility procedure in step S1001, the UE 3 is unable to obtain a UL WUS configuration / SIB1 for one or more NES cells in step S1004, then either: 1) upon switching of cells, or 2) upon expiry of a UE-initiated timer of predefined length for attempting to obtain such information, the UE 3 discards any UL WUS information it already has as this is considered invalid (as it may be out of date) and bars the one or more cells whose UL WUS information the UE 3 was unable to obtain in step S1005.

[0116] In another option (not shown in Fig. 10), upon switching to the new cell, the UE 3 may start a validity timer for any previously acquired UL WUS configuration (and SIB1). This timer can be indicated by the anchor cell 9A1. Upon expiry of the validity timer, the UE 3 can either simply discard stored information, or attempt to reacquire the UL WUS configuration (and potentially SIB1 information).

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

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

[0119] 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 communication control module 43.

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

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

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

[0123] <RAN node> 　　Fig. 12 is a simplified block schematic illustrating the main components of a RAN node 5 for implementation in the communication system 1 of Fig. 1.

[0124] As shown, the RAN node 5 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 antenna 53 (e.g., a single or multi-panel antenna array / massive antenna), and a core network interface 55 for transmitting signals to and for receiving signals from network nodes in the core network 7. Although not shown, the RAN node 5 may also be coupled to other RAN nodes 5 via an appropriate interface (e.g., the so-called 'X2' interface in LTE or the 'Xn' interface in NR). The RAN node 5 has a controller 57 to control the operation of the RAN node 5. The controller 57 is associated with a memory 59. Software may be pre-installed in the memory 59 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The controller 57 is configured to control the overall operation of the RAN node 5 by, in this example, program instructions or software instructions stored within memory 59. As shown, these software instructions include, among other things, an operating system 61, and a communication control module 63.

[0125] The communication control module 63 is operable to control the communication between the RAN node 5 and UEs 3 and other network entities (e.g., core network nodes) that communicate with the RAN node 5. The communication control module 63 is configured for the overall control of the reception and decoding of uplink communication, 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 communication control module 63 is also configured for the overall control of the transmission of downlink communication 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-persistent scheduling (e.g., SPS). The communication control module 63 is responsible, for example: for determining where to configure the UE 3 to monitor for downlink control information (e.g., the location of search spaces, CORESETs, and associated PDCCH candidates to monitor); for determining the resources to be scheduled for UE transmission / reception of UL / DL communication (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the RAN node side; for configuring slots / symbols appropriately (e.g., for UL, DL or full duplex communication, or the like); for configuring bandwidth parts for the UE 3; for providing related configuration signalling to the UE 3; and the like.

[0126] It will be appreciated that the communication control module 63 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 63 may include, for communicating with the UE 3, a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an RRC sub-module, etc. Moreover, the communication control module 63 may include, for communicating with a core network entity such as an MME (or similar node such as an AMF 10-1), an S1 application protocol (S1-AP) sub-module, a stream control transmission protocol (SCTP) sub-module, an IP sub-module, a layer 1 (L1) sub-module, a layer 2 (L2) sub-module, etc (or corresponding sub-modules for communicating with an AMF 10-1).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0150] For example, the whole or part of the exemplary embodiments disclosed above can be described as, but not limited to, the following supplementary notes. 　　(Supplementary note 1) 　　A method performed by a mobile device, the method comprising: 　　attempting to select a first cell for acquiring a system information block 1 (SIB1); 　　receiving, via a second cell, configuration information for requesting the first cell to acquiring the SIB1 on-demand after a failure of the attempting to select the first cell; and 　　performing a cell reselection of the first cell for acquiring the SIB1 on-demand, after receiving the configuration information. 　　(Supplementary note 2) 　　The method according to supplementary note 1, wherein 　　the acquiring the SIB1 on-demand is performed in a case where a timer is still running. 　　(Supplementary note 3) 　　The method according to supplementary note 1 or 2, wherein 　　the configuration information is valid in the cell reselection from the second cell. 　　(Supplementary note 4) 　　The method according to supplementary note 2, wherein 　　the timer is adjusted based on a reference signal received power (RSRP). 　　(Supplementary note 5) 　　The method according to any one of supplementary notes 1 to 4, wherein 　　update of the configuration information or the SIB 1 on-demand is received. 　　(Supplementary note 6) 　　A method performed by a base station, the method comprising: 　　transmitting, via a second cell, configuration information for requesting a first cell to acquiring a system information block 1 (SIB1) on-demand after a failure, by a mobile device, of attempting to select the first cell for acquiring the SIB1, and 　　wherein the configuration information is used by the mobile device in performing a cell reselection of the first cell for acquiring the SIB1 on-demand. 　　(Supplementary note 7) 　　A mobile device comprising: 　　means for attempting to select a first cell for acquiring a system information block 1 (SIB1); 　　means for receiving, via a second cell, configuration information for requesting the first cell to acquiring the SIB1 on-demand after a failure of the attempting to select the first cell; and 　　means for performing a cell reselection of the first cell for acquiring the SIB1 on-demand, after receiving the configuration information. 　　(Supplementary note 8) 　　A base station comprising: 　　means for transmitting, via a second cell, configuration information for requesting a first cell to acquiring a system information block 1 (SIB1) on-demand after a failure, by a mobile device, of attempting to select the first cell for acquiring the SIB1, and 　　wherein the configuration information is used by the mobile device in performing a cell reselection of the first cell for acquiring the SIB1 on-demand.

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

[0152] 1 RADIO FREQUENCY IDENTIFICATION (RFID) 2 COMMUNICATION SYSTEM 3 USER EQUIPMENT 5 RAN NODE 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

Claims

1. A method performed by a mobile device, the method comprising: 　　attempting to select a first cell for acquiring a system information block 1 (SIB1); 　　receiving, via a second cell, configuration information for requesting the first cell to acquiring the SIB1 on-demand after a failure of the attempting to select the first cell; and 　　performing a cell reselection of the first cell for acquiring the SIB1 on-demand, after receiving the configuration information.

2. The method according to claim 1, wherein 　　the acquiring the SIB1 on-demand is performed in a case where a timer is still running.

3. The method according to claim 1 or 2, wherein 　　the configuration information is valid in the cell reselection from the second cell.

4. The method according to claim 2, wherein 　　the timer is adjusted based on a reference signal received power (RSRP).

5. The method according to any one of claims 1 to 4, wherein 　　update of the configuration information or the SIB 1 on-demand is received.

6. A method performed by a base station, the method comprising: 　　transmitting, via a second cell, configuration information for requesting a first cell to acquiring a system information block 1 (SIB1) on-demand after a failure, by a mobile device, of attempting to select the first cell for acquiring the SIB1, and 　　wherein the configuration information is used by the mobile device in performing a cell reselection of the first cell for acquiring the SIB1 on-demand.

7. A mobile device comprising: 　　means for attempting to select a first cell for acquiring a system information block 1 (SIB1); 　　means for receiving, via a second cell, configuration information for requesting the first cell to acquiring the SIB1 on-demand after a failure of the attempting to select the first cell; and 　　means for performing a cell reselection of the first cell for acquiring the SIB1 on-demand, after receiving the configuration information.

8. A base station comprising: 　　means for transmitting, via a second cell, configuration information for requesting a first cell to acquiring a system information block 1 (SIB1) on-demand after a failure, by a mobile device, of attempting to select the first cell for acquiring the SIB1, and 　　wherein the configuration information is used by the mobile device in performing a cell reselection of the first cell for acquiring the SIB1 on-demand.

Images