Method performed by mobile device, method performed by access network node, mobile device and access network node

Abstract

A wireless communication system is described that consists of at least one RAN node, and at least one UE. In particular, herein is described are means and methods of enabling and performing on-demand SIB1 transmissions for non-anchor cells provided by the at least one RAN node to achieve network energy savings (NESs).

Description

METHOD PERFORMED BY MOBILE DEVICE, METHOD PERFORMED BY ACCESS NETWORK NODE, MOBILE DEVICE AND ACCESS NETWORK NODE

[0001] The present disclosure relates to a communication system and to parts thereof. 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 on-demand System Information Block 1 (SIB1) transmissions for non-anchor cells for network energy gains.

[0002] Earlier developments of the 3GPP standards were referred to as the 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.

[0003] NPL 1: 'NGMN 5G White Paper' Version 1.0, [online], February 17, 2015, The NGMN Alliance, [searched on January 15, 2025], Internet (URL:https: / / www.ngmn.org / 5g-white-paper.html)

[0004] Under the 3GPP standards, a NodeB (or an eNB in LTE, and gNB in 5G) is the 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 communications 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 communications 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 communications 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 wake-up signals (WUSs) to allow devices such as UEs to enter reduced transmission / reception modes, (for example discontinuous transmission / reception modes); 　　- The use of on-demand synchronization signal / physical broadcast channel (PBCH) blocks (SSBs) (and possibly other downlink (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 SIB1 for capacity / non-anchor cells supporting UEs in RRC INACTIVE / IDLE mode.

[0010] In the case of on-demand SIB1 transmissions for non-anchor cells supporting UEs in RRC INACTIVE / IDLE mode, mechanisms, and procedures on how to indicate to a RAN node that a UE requires on-demand SIB1 transmissions need to be developed. There is therefore a need to devise appropriate mechanisms and procedures to allow for the implementation of on-demand SIB1 transmissions for UEs to use non-anchor cells. The present specification also aims to disclose apparatus and methods that at least contribute to addressing one or more of the above needs and / or issues.

[0011] A method performed by a mobile device is provided. The method comprises: 　　receiving information indicating whether a SIB1 is transmitted periodically or on-demand.

[0012] A method performed by an access network node is provided. The method comprises: 　　transmitting information indicating whether a SIB1 is transmitted periodically or on-demand.

[0013] A mobile device is provided. The mobile device comprises: 　　means for receiving information indicating whether a SIB1 is transmitted periodically or on-demand.

[0014] An access network node is provided. The access network node comprises: 　　means for transmitting information indicating whether a SIB1 is transmitted periodically or on-demand.

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

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

[0017] Examples of apparatus and methods will now be described, by way of example, with reference to the accompanying drawings in which:Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system;Fig. 2 schematically illustrates a RAN node mobile communication system 1 of Fig. 1 and the anchor / non-anchor cell coverage provided by the RAN node;Fig. 3 depicts a simplified sequence diagram illustrating a procedure for on-demand SIB1 transmissions to a UE for a non-anchor cell that may be used in the communication system 1 of Fig. 1;Fig. 4 depicts a simplified sequence diagram illustrating another procedure for on-demand SIB1 transmissions to a UE for a non-anchor cell that may be used in the communication system 1 of Fig. 1;Fig. 5 depicts a simplified sequence diagram illustrating another procedure for on-demand SIB1 transmissions to a UE for a non-anchor cell that may be used in the communication system 1 of Fig. 1;Fig. 6 depicts a simplified sequence diagram illustrating another procedure for on-demand SIB1 transmissions to a UE for a non-anchor cell that may be used in the communication system 1 of Fig. 1;Fig. 7 depicts a simplified sequence diagram illustrating another procedure for on-demand SIB1 transmissions to a UE for a non-anchor cell that may be used in the communication system 1 of Fig. 1;Fig. 8 depicts a simplified sequence diagram illustrating another procedure for on-demand SIB1 transmissions to a UE for a non-anchor cell that may be used in the communication system 1 of Fig. 1;Fig. 9 depicts a simplified sequence diagram illustrating another procedure for on-demand SIB1 transmissions to a UE for a non-anchor cell that may be used in the communication system 1 of Fig. 1;Fig. 10 is a simplified block schematic illustrating the main components of a UE for implementation in the system of Fig. 1; andFig. 11 is a simplified block schematic illustrating the main components of a RAN node for implementation in the system of Fig. 1.

[0018] Overview 　　An exemplary communication system will now be described in general terms, by way of example only, with reference to Fig. 1.

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

[0020] In the communication system 1, user equipment (UEs) 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 or 'gNB' 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 or later generations core network or EPC network).

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

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

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

[0024] 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 (such as, for example an Authentication Server Function (AUSF) which facilitates security processes).

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

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

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

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

[0029] The RAN node 5 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.

[0030] The RAN node 5 is also configured for transmission of, and the UEs 3 are configured for the reception of, control information and user data via a number of 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.

[0031] The DL physical channels may include, for example, a physical downlink shared channel (PDSCH), a 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.

[0032] The RAN node 5 also transmits 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. 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).

[0033] 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, DMRS for an UL control / data signal, and / or sounding reference signals (SRS) used for UL channel measurement.

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

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

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

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

[0038] A UE 3 may monitor a set of PDCCH candidates in one or more 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.

[0039] Synchronisation Signal Blocks (SIBs) 　　The RAN node 5 is also configured to transmit SSBs periodically in the cell or cells 9 that it operates. 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 SIB1 which carries other minimum system information).

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

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

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

[0043] Fig. 2 schematically illustrates a RAN node 5 of the mobile ('cellular' or 'wireless') communication system 1 and anchor / non-anchor cell coverage provided by the RAN node 5 to a UE 3.

[0044] As shown in Fig. 2, the RAN node 5 that connects to an external data network 20 via the core network 7 may provide any number of cells for UEs to communicate over with the RAN node 5 via carrier aggregation (CA). For example, the RAN node 5 may provide an anchor cell (e.g., a cell where a UE is capable of receiving SSBs, system information, paging messages, and the like). 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 RSRQ. Based on those SSBs and measurements the UE 3 (or the RAN node 5 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). By way of example only, that specific cell may be an anchor cell. An anchor cell may be any cell over which UEs can receive SSBs and / or system information (e.g., SIB messages).

[0045] Additionally, the RAN node 5 may also provide one or more other cells (other than an anchor cell) for the UE 3 to communicate over with the RAN node 5 via CA. For example, the RAN node 5 may provide one or more non-anchor cells (also known as a non-anchor NES cell) that a UE 3 may camp onto at some later time after initially camping onto an anchor cell. For example, the UE 3 may, having initially camped onto an anchor cell may be switched / handed over to a non-anchor cell when the coverage / services provided by the non-anchor cell is desirable. Such non-anchor cells may be neighbouring cells to the anchor cell, or may be smaller cells overlapping with, or wholly incorporated within, the anchor cell. A non-anchor cell, unlike an anchor cell, is a cell over which UEs cannot receive SSBs and / or system information (e.g., SIB messages). Initially attaching on an anchor cell and allowing a UE to subsequently use a non-anchor cell may be referred to as a 'multi-cell' scenario.

[0046] While a UE 3 is described above as initially camping on an anchor cell and then switching / being handed over to a non-anchor cell, it will nevertheless be appreciated that a UE 3 may initially attach to a non-anchor cell from the outset.

[0047] Initially attaching on a non-anchor cell may be referred to as a 'single cell' scenario, as the UE 3 may only receive non-anchor cell specific signalling from the RAN node 5, while when the UE 3 is camped onto an anchor cell the UE 3 may receive signals from the RAN node 5 pertaining to either / both the anchor cell or / and the non-anchor cell.

[0048] Such SSB-less / SIB-less cells beneficially offer energy gains in the mobile ('cellular' or 'wireless') communication system 1 as the RAN node 5 does not periodically send SSBs / SIBs associated with the one or more non-anchor cells over those cells. It will be appreciated however that for the UE 3 to be able to use the one or more non-anchor cells, the RAN node 5 nevertheless has to send appropriate SSBs / SIBs for the one or more non-anchor cells over another cell (e.g., the anchor cell).

[0049] As such, while the provision of non-anchor cells brings energy gains at the RAN node 5, the requirement of the RAN node 5 to send appropriate SSBs / SIBs for the one or more non-anchor cells over another cell (e.g., the anchor cell) limits the scale of those energy gains. To bring further energy gains it would be beneficial to eliminate unnecessary transmissions of SIB1 associated with such non-anchor cells. For example, SIB1 transmissions for a non-anchor cell are unnecessary when there are no devices in RRC INACTIVE / IDLE mode present that would benefit from the signalling i.e., when there are no devices in RRC INACTIVE / IDLE mode present that may wish to communicate with the RAN node 5 over the non-anchor cell.

[0050] Nevertheless, it will be appreciated that simply eliminating such SIB1 transmissions would be deleterious as whether there are devices in RRC INACTIVE / IDLE mode present in the non-anchor cell that would benefit from SIB1 signalling may change over time as devices (e.g., UEs) move between cell coverage areas, or where a UE requires specific services that may be provided by a specific non-anchor cell. There is thus a need for techniques / procedures that allow SIB1 transmissions for non-anchor cells to be implemented on an 'on-demand' basis.

[0051] In one or more aspects of the disclosure below, the RAN node 5 may signal to the UE 3 that on-demand SIB1 transmissions are enabled for non-anchor cells in a MIB transmission to the UE 3. For example, the MIB transmitted to the UE 3 may be configured to include an indication that SIB1 transmissions for a non-anchor cell will be provided on an on-demand basis. That indication may, by way of example only, comprise a new information element in a spare bit of the MIB. Alternatively, the indication may, by way of example, comprise an indication as part of the kSSBoffset in the MIB.

[0052] In one or more other aspects of the disclosure below, the RAN node 5 may signal to the UE 3 that on-demand SIB1 transmissions are enabled for non-anchor cells in a DCI message to the UE 3. For example, a DCI Format 1_0 message to the UE 3 may be configured to include an indication that SIB1 transmissions for a non-anchor cell will be provided on an on-demand basis. That indication may, by way of example only, comprise a new 1-bit indication that defines whether SIB1 transmissions for a non-anchor cell is enabled. Where the SIB1 transmissions for non-anchor cells are implemented on an on-demand basis the new bit may be set to 'notBroadcasting'.

[0053] It will nevertheless be appreciated that the indication that on-demand SIB1 transmissions for a non-anchor cell provided by the anchor cell may take the form a multi-bit carrier indication (e.g., 2 or more bits, a bitmap indication, or a bit-string) to indicate the applicable carrier. That indication may take the form of a new IE in the DCI format 1_0 with cyclic redundancy check (CRC) scrambled by System Information RNTI (SI-RNTI) or in paging information to the UE or via RRC connection release (e.g., SIB1BroadcastStatus IE).

[0054] In one or more other aspects of the disclosure below, RAN node 5 may signal to the UE 3 that on-demand SIB1 transmissions are enabled for non-anchor cells in the DCI Format 1_0 message that is sent once to the UE 3, or alternatively, the DCI message may be sent periodically to update the UE 3 as to whether SIB1 transmissions for non-anchor cells are implemented on an on-demand basis. For example, the DCI message may be sent to the UE 3 every multiple of 160 ms (e.g. k-wus*160 ms), where 160 ms is the legacy periodicity of SIB1 transmissions.

[0055] Beneficially, by including an explicit indication in either the MIB or a DCI Format 1_0 message to indicate to the UE 3 that SIB1 transmissions for a non-anchor cell may be provided on-demand, the UE 3 does not have to regularly search for SIB1 transmissions for non-anchor cells, but rather can request such transmissions on an on-demand basis, thereby reducing the amount of energy used by the UE 3.

[0056] In one or more other aspects of the disclosure below, when SIB1 transmissions for a non-anchor cell are required, the UE 3 may trigger a wake-up signal (WUS) procedure that may involve requesting resources for a WUS message that requests on-demand SIB1 transmissions. For example, the UE 3 may request a WUS configuration from the RAN node 5 to indicate resources for a WUS message that requests on-demand SIB1 transmissions.

[0057] Alternatively, a WUS configuration message may be sent to the UE 3 by the RAN node 5 via appropriate RRC messages (e.g., an RRC connection release message, or the like). Nevertheless, it will be appreciated that if the UE 3 is in RRC_CONNECTED mode before cell re-selection, and has moved into RRC_INACTIVE mode, the WUS configuration may be provided to the UE 3 via an appropriate SIB transmission (e.g., SIB2 / 3 / 4 etc.,). Alternatively, the WUS configuration may be provided to the UE 3 via RRC (re)configuration messages transmitted to the UE 3 while the UE 3 was in RRC_CONNECTED mode.

[0058] Beneficially, by allowing the UE 3 to trigger a WUS procedure to send a WUS message to the RAN node to request on-demand SIB1 transmissions, the UE 3 does not have to regularly search for SIB1 transmissions for non-anchor cells, but rather can request such transmissions on an on-demand basis. Furthermore, the RAN node 5 may avoid having to provide any signalling over a non-anchor cell until the RAN node 5 is informed that a device wishes to access the non-anchor cell. That in turn reduces the amount of energy used by the UE 3 and RAN node 5, thereby providing further energy gains in the system.

[0059] In one or more other aspects of the disclosure below, when SIB1 transmissions for a non-anchor cell are required, the UE 3 may transmit a WUS message to the RAN node 5 that requests on-demand SIB1 transmissions using resources indicated to the RAN node 5 in a WUS configuration provided in a MIB transmission.

[0060] Beneficially, by providing the WUS configuration in a MIB transmission, the UE 3 may be provisioned with resources for sending a WUS message that requests on-demand SIB1 transmissions in advance. Therefore, the UE 3 does not have to explicitly request resources for a WUS message as part of the WUS procedure, thereby reducing the amount of signalling required between the UE 3 and the RAN node 5. By reducing the amount of signalling required the overall implementation of on-demand SIB1 transmissions is made more efficient.

[0061] In one or more other aspects of the disclosure below, when SIB1 transmissions for a non-anchor cell are required, the UE 3 may transmit a WUS message to the RAN node 5 that requests on-demand SIB1 transmissions using resources that are preconfigured (e.g., hardcoded) such that the UE 3 and RAN node 5 are aware of the resources to be used for the WUS message without receiving a WUS configuration.

[0062] Beneficially, by preconfiguring the resources to be used for the WUS message to be sent by the UE 3 to the RAN node 5, the amount of signalling required between the UE 3 and RAN node 5 is reduced. By reducing the amount of signalling required the overall implementation of on-demand SIB1 transmissions is made more efficient.

[0063] In one or more other aspects of the disclosure below, when SIB1 transmissions for a non-anchor cell are required, the UE 3 may transmit a WUS message to the RAN node 5 that requests on-demand SIB1 transmissions using preconfigured resources that are signalled to the UE 3 in a WUS configuration sent in paging information (e.g., in a paging message).

[0064] Beneficially, by indicating the preconfigured resources to be used for the WUS message to be sent by the UE 3 to the RAN node 5 in a WUS configuration sent as part of a paging message, dedicated WUS resource request procedures may be omitted thereby reducing the amount of signalling required between the UE 3 and RAN node 5. By reducing the amount of signalling required the overall implementation of on-demand SIB1 transmissions is made more efficient.

[0065] Summary 　　It can be seen, therefore, that the communication system 1 may include several beneficial features and enhancements. A number of these features will now be summarised, by way of example only.

[0066] The WUS resource allocation may be pre-configured or configured in any of a number of different ways although it will be appreciated that pre-configuration, e.g., by means of default values may be particularly applicable for a single cell case (i.e., because UE does not have an anchor cell and is not involved in a multicarrier scenario or cell re-selection).

[0067] In the time domain, for example, the WUS signal for on-demand SIB1 transmissions may have a pre-defined or configurable offset towards a DL signal such as a DRS or SSB signal. The WUS message for on-demand SIB1 transmissions may, for example, be transmitted a number nwusslot (greater than a minimum UE processing time) after the latest DRS or SSB reception.

[0068] In the frequency domain, for example, the WUS signal for on-demand SIB1 may be transmitted with a pre-defined or configurable offset to the following: 　　 (i) to the start of a frequency domain position of an SS / PBCH block or the associated CORESET Type 0 Common Search Space Set (e.g., for the single cell case); or 　　 (ii) to the start RB of an initial UL bandwidth part (BWP)

[0069] Furthermore, the UE 3 may be provided with an absolute radio frequency channel number (ARFCN) of 'Point A' for UL or supplementary UL (SUL). A simplified example of an Abstract Syntax Notation One (ASN.1) representation of a possible implementation of such IEs in SIB1 that may be used for a WUS configuration, is provided below by way of Illustration only (only showing relevant parts of the information element): 　　frequencyBandList MultiFrequencyBandListNR-SIB 　　OPTIONAL, 　　　　-- Cond FDD-OrSUL 　　absoluteFrequencyPointA ARFCN-ValueNR 　　OPTIONAL, 　　　　-- Cond FDD-OrSUL

[0070] In one option, when considering the single cell and multiple cell cases: 　　- For the single cell case (e.g., where the UE 3 camps on a non-anchor (NES) cell with on-demand SIB1 transmissions during initial cell selection), DCI format 1_0 may be transmitted to the UE 3 from the NES cell which can be used to indicate the WUS configuration to the UE 3; 　　- When a UE 3 has camped on the anchor cell (e.g., for a multicell case), the WUS configuration for on-demand SIB1 transmissions on the NES cell may be transmitted to the UE 3 via DCI format 1_0 from the anchor cell.

[0071] Nevertheless, it will be appreciated that for both cases, the UE 3 may send the WUS via the NES cell.

[0072] In this option, therefore, the WUS configuration may be sent via a PDSCH whenever DCI format 1_0 with CRC scrambled by SI-RNTI (sent within Common Search Space Type 0) indicates that on-demand SIB1 transmissions is used (e.g., an 'On demand SIB1' bit is set, which can occupy one (or more) of the currently reserved bits of DCI format 1_0) - it will be appreciated that currently 15 reserved bits are available.

[0073] The WUS configuration for on-demand SIB1 transmissions on the NES cell may be transmitted to the UE 3 via a pointer from DCI format 1_0. For example, DCI format 1_0 may allocate a PDSCH which contains the WUS configuration.

[0074] Nevertheless, the PDSCH may also contain just paging information configuration, and the WUS configuration may be sent via the paging information to the UE.

[0075] It will be appreciated that the time window and configuration to receive a WUS response from the network may alternatively or additionally be included. For example, this may include the start time and length of time window where UE shall monitor for such as response from the network.

[0076] In another option, for a multiple cell case, from an inter-cell coordination perspective, the anchor cell may be used to send a SIB1 on-demand request to the NES cell.

[0077] The anchor cell may, for example, be used to send this request to the NES cell when the UE 3 performs cell re-selection or handover of a UE 3 to the NES cell.

[0078] The anchor cell may, alternatively or additionally, be used to send this request to the NES cell when a WUS request is received from the UE 3. In this case, the anchor cell may be used to provide the WUS configuration to UE 3 where the WUS request is performed by the UE 3 on the anchor cell. The WUS request from the UE 3 may also contain the identity of an NES cell for which on-demand SIB1 is required.

[0079] The request from anchor cell to the NES cell may contain the cell identity or DU identity for which on-demand transmission is required.

[0080] In another option, for a multiple cell case, upon receipt of a RACH message 1 (MSG1 - e.g., a RACH preamble) by the anchor cell from a UE 3 to request a WUS configuration of an NES cell, the anchor cell may inform the UE 3 of the WUS configuration for the NES cell in RACH message 4 (MSG4) or RACH message 2 (MSG2 - e.g., a Random-Access Response (RAR)). The UE 3 may then send the WUS request to the NES cell accordingly.

[0081] A time delay may be configured before on-demand SIB1 transmissions starts in order to allow the UE 3 to camp on or to be served by the NES cell.

[0082] In another option, for the single-cell case, an NES cell with on-demand SIB1 transmissions may be selected by the UE 3 during initial cell selection. In this example, the following two possibilities may be used: 　　- The parameters of the WUS configuration may be predefined, known to both the UE 3 and RAN node 5. Then the UE 3 can send the WUS on the NES cell at a predefined time / frequency location via a preconfigured signal such as a PRACH signal or the like, identifying the SIB1 on-demand request; or 　　- The NES cell may send the WUS configuration via preconfigured paging information in a paging message to the UE 3. Then the UE 3 can send the WUS to the NES cell according to the configuration received in the paging message to indicate the SIB1 on-demand request.

[0083] It will be appreciated that, for FDD, an initial UL position for the WUS (or ARFCN for 'Point A') may be specified too.

[0084] There are also a number of options for signalling / determining the location of the transmitted on-demand SIB1.

[0085] For example, in one option, the location may be indicated via MSG2 / MSG4 based SIB1 scheduling. Specifically, PDSCH resources for SIB1, e.g., as allocated by a time domain resource allocation (TDRA) in DCI format 1_0, may be included in the standard RACH messages MSG2 / MSG4 / MSGB (if MSG1 / MSGA is used for the WUS) to indicate the location of on-demand SIB1. It will be appreciated that in this case, the SIB1 is not scheduled by DCI format 1_0.

[0086] In another option, the location may be indicated via DCI format 1_0 based SIB1 scheduling. In this option, the SIB1 locations as indicated via DCI format 1_0 remain the same for the on-demand case as for the broadcast case of SIB1. When receiving the WUS based on-demand SIB1 request, the RAN node may decide a duration for how long the SIB1 may be sent to the UE 3 (or this may be a preconfigured duration). This will beneficially help the UE 3 to obtain an exact timing to monitor the SIB1 transmissions. Hence, when SIB1 on-demand is requested, SIB1s can be transmitted by the network for a time window of one or more legacy SIB1 periodicities. For example, on-demand SIB1s may be repeated at an interval defined by an appropriate multiple of the time window as defined by an appropriate parameter (e.g. 'N-on-demand-SIB1'), e.g., it can be 1 / 4, 1 / 2, 1, 2, 4…etc.). It will be appreciated that this can be less than one, since there may be multiple repetitions within one legacy SIB1 periodicity.

[0087] One option for configuring this time window is that the exact time window for the UE 3 to monitor the SIB1 transmissions can be prespecified (e.g. as 'M-SIB1-monitoring x SIB1 periodicity') and standardised in the appropriate specifications. For example, the number 'M' of periodic SIB1 (e.g. M=4) in the time window may be predefined. Alternatively, this time window may be configured to the UE 3 within DCI format 1_0, or the WUS configuration, or a response message to the WUS.

[0088] The SIB1 transmission may be started following the transmission of DCI format 1_0 that indicates the SIB1 resources, or with a specified time delay window.

[0089] It will be appreciated that, in addition, the SIB1 on demand transmissions may be enabled during the inactive duration of Cell DTX / DRX operation only. For example, the on-demand SIB1 transmission may not be enabled during the active duration of a Cell DTX / DRX configuration. Instead, during Cell DTX / DRX active duration, legacy SIB1 transmission may resume.

[0090] It will also be appreciated that this mechanism may be extended to other SIBs, e.g. SIB2 / 3 / 4 etc.

[0091] It will also be appreciated that, the transmission of a WUS from the UE 3 (or another cell) may be requested usually during a cell DRX non-active duration.

[0092] Beneficially, this is applicable to a newly specified scenario where on-demand SIB1 transmission is activated in conjunction with Cell DTX, e.g. only during cell DTX inactive duration, so that a RAN node 5 may go into a deeper sleep during cell DTX inactive duration and allow legacy SIB1 transmission for quicker initial access for UEs during a cell DTX active duration.

[0093] Whilst the WUS may, ideally, be transmitted during Cell DRX active duration, due to the usual association between Cell DRX and Cell DTX, a WUS request may usually be monitored for during a cell DRX non-active duration also.

[0094] Each of the on-demand SIB1 transmission scenarios for UEs in idle / inactive outlined above will now be discussed in more detail with reference to Figs. 3 to 9.

[0095] On-demand SIB1 procedures for non-anchor cells 　　Fig. 3 depicts a simplified sequence diagram illustrating a procedure for on-demand SIB1 transmissions to a UE 3 for a non-anchor cell 9Non-anchorthat may be used in the communication system 1 of Fig. 1.

[0096] As shown in Fig. 3 there is provided a RAN node 5 and a UE 3 deployed in the communication system 1 of Fig. 1. The UE 3 may be camped on an anchor cell provided by the RAN node 5 to allow communication with the RAN node 5. Once camped on the anchor cell, the UE 3 may enter RRC IDLE mode or RRC INACTIVE mode.

[0097] When in RRC IDLE mode the UE 3 is unable to transfer application data with the RAN node 5. However, the UE 3 may receive system information from the RAN node 5 from the BCCH to allow the UE 3 to perform and complete cell (re)selection procedures and the like. The system information may also allow the UE 3 to access the network i.e., perform random access procedures and / or RRC Connection Setup procedures. The UE 3 may also monitor the PDCCH DCI Format 1_0 using a paging RNTI (P-RNTI) during specific paging frames and / or paging occasions that may be defined by a discontinuous reception (DRX) pattern implemented by the UE 3.

[0098] When in RRC INACTIVE mode the UE 3 is unable to transfer application data with the RAN node 5. However, the UE 3 may monitor for short messages transmitted with P-RNTI over DCI and may also perform small data transmission (SDT) procedures. SDT procedures allow data and / or signalling transmissions while the UE 3 is in RRC INACTIVE mode without transitioning to RRC CONNECTED mode. SDT is enabled on a radio bearer basis and is initiated by the UE 3 only if less than a configured amount of UL data awaits transmission across all radio bearers for which SDT is enabled.

[0099] At step S302 the RAN node 5 may transmit system information to the UE 3 such as a MIB. The MIB is transmitted to the UE 3 over the PBCH with a periodicity of 80 ms, and typically contains the information necessary for the UE 3 to receive a subsequent SIB1 transmission on the anchor cell.

[0100] For example, the MIB may contain indications of the most significant bits (MSBs) of a current system frame number (SFN) (e.g., systemFrameNumber IE), the subcarrier spacing to be used for the SIB1 message (e.g., subCarrierSpacingCommon IE), a subcarrier spacing offset (kSSB) that defines a subcarrier offset between the Common Resource Block grid and the SS / PBCH block, and the like. The subcarrier spacing offset (kSSB) may also be used to indicate whether or not the MIB has an associated CORESET which can be used by the PDCCH when allocating PDSCH resources for SIB1.

[0101] The MIB may also contain a pointer (e.g., controlReseourceSetZero IE) to aspects of standardised look-up tables that define a SS / PBCH block and CORESET multiplexing pattern, the number of resources belonging to the CORESET, the number of symbols belonging to the CORESET, and the frequency domain offset between the SS / PBCH block and the CORESET. In addition, the MIB may also contain a pointer (e.g., searchSpaceZero sub-IE) to aspects of standardised look-up tables that define the timing offset between the SS / PBCH block and the search space for SIB1, the number of search space sets per slot, and the first symbol belonging to the search space sets. Both the pointer (e.g., controlReseourceSetZero sub-IE) to aspects of standardised look-up tables, and the pointer (e.g., searchSpaceZero IE) to aspects of standardised look-up tables may be contained together in an IE of the MIB (e.g., pdcch-ConfigSIB1 IE).

[0102] In addition, a spare bit in the MIB may be used by the RAN node 5 to indicate to the UE 3 that the SIB1 transmissions for a non-anchor cell provided by the RAN node 5 may be provided to the UE 3 on-demand. For example, a new IE (e.g., WUS-SIB1Config IE) comprising of a one-bit indication may be provided in the MIB to indicate to the UE 3 that the SIB1 transmissions for a non-anchor cell provided by the RAN node 5 may be provided to the UE 3 on-demand.

[0103] Alternatively, or additionally, the subcarrier spacing offset (kSSB) that defines a subcarrier offset between the Common Resource Block grid and the SS / PBCH block may be adapted to include an indication as to whether SIB1 transmissions for a non-anchor cell provided by the RAN node 5 may be provided to the UE 3 on an on-demand basis. By way of example only, the kSSBmay be defined with a new value other than that used in legacy to indicate on-demand SIB1 transmission e.g., where kSSBis 30 for FR1 or kSSBis 14 for FR2, the kSSBcould be defined with the value of 16 * controlResourceSetZero + searchSpaceZerorequest + 'On-demand SIB1' indication.

[0104] Having received the MIB, the UE 3 decodes the MIB, at step S304, and may store the decoded MIB locally at the UE 3 for future use. Having decoded the MIB, the UE 3 may determine, based on the indication included in e.g., WUS-SIB1Config IE, that SIB1 transmissions for a non-anchor cell provided by the RAN node 5 are provided on an on-demand basis. Furthermore, the UE 3 may also determine, at step S304, that on-demand SIB1 transmissions are required. By way of example only, the UE 3 may request on-demand SIB1 transmissions when the UE 3 performs cell selection (or re-selection) towards a non-anchor cell. It will be appreciated that the non-anchor cell may be a neighbouring cell served by the same RAN node 5, or alternatively it may be a neighbouring cell served by a different RAN node (e.g., a neighbouring RAN node).

[0105] At step S306, having decided that on-demand SIB1 transmissions are required, the UE 3 may send an appropriate request message (e.g., a WUS resource request message) to the RAN node 5 to request a WUS configuration to enable the UE 3 to send an appropriate WUS message to the RAN node 5 to request on-demand SIB1 transmissions for the non-anchor node.

[0106] In one example, the WUS resource request message may be sent to the RAN node 5 as part of an appropriate PRACH preamble message selected by the UE 3 as part of a RACH procedure for initial attach onto the RAN node 5 if the UL between the UE 3 and RAN node 5 is not synchronised.

[0107] In another example, if the UL between the UE 3 and RAN node 5 is already synchronised, the WUS resource request message may be sent to the RAN node 5 as part of an appropriate scheduling request (SR) message. For example, the WUS resource request message may form part of an SR message that is sent to the RAN node 5 to request the RAN node 5 to send an UL grant (DCI Format 0) so that the UE 3 can transmit data on the PUSCH to the RAN node 5. The SR message may be sent to the RAN node over the PUCCH using a specific PUCCH format (e.g., PUCCH Format 0).

[0108] Having received the WUS resource request message, the RAN node 5, at step S308, may process the WUS resource request message and perform an appropriate resource allocation procedure to allocate appropriate resources for the UE 3 to use to send an appropriate WUS message to the RAN node 5 to request an on-demand SIB1 transmissions for the non-anchor node.

[0109] In one example, the RAN node 5 may configure the resources in the time domain such that the resources are offset in time relative to a DL signal sent from the RAN node 5 to the UE 3 (e.g., such as a discovery reference signal (DRS) and / or an SSB). That offset may be configurable by the RAN node 5, or alternatively, it may be pre-defined (e.g., hard coded). For example, the resources may be allocated such that the UE 3 can send the WUS message to the RAN node 5 nWUSslots after the latest DRS and / or SSB reception by the UE 3. The value of nWUSmay be selected to correspond to the minimum processing time capabilities of the UE 3.

[0110] I RAN node 5 may alternatively, or additionally configure the resources in the frequency domain such that the resources are offset to the start of a resource block (RB) of an initial UL BWP, or they may be offset to the start of the frequency domain position of the CORESET associated with the Type 0 Common Search Space Set i.e. the frequency domain position of the CORESET 0 that carries PDCCH / DCI for SIB1. That offset may be configurable by the RAN node 5, or alternatively, it may be pre-defined (e.g., hard coded).

[0111] At step S310, having allocated appropriate resources for the UE 3 to use to send an appropriate WUS message to the RAN node 5 to request an on-demand SIB1 transmissions for the non-anchor node, the RAN node 5 may send a configuration message to the UE 3. For example, the RAN node 5 may send an appropriate configuration message to indicate the allocated resources to the UE 3 (e.g., a WUS configuration message indicating the time offset, frequency offset, and / or other configuration information). The WUS configuration message may be sent to the UE 3 by the RAN node 5 via appropriate broadcast signalling (e.g., paging information signalling that sends paging information to the UE 3). Alternatively, the WUS configuration message may be sent to the UE 3 by the RAN node 5 via appropriate RRC messages (e.g., an RRC connection release message, or the like).

[0112] As well as indicating the allocated resources to the UE 3 (i.e., providing an UL grant for the allocated resources), the WUS configuration message may additionally include appropriate information to (re)configure the UL between the RAN node 5 and the UE 3. For example, the WUS configuration message may include an indication of the frequency of the uplink, the subcarrier spacing used, the initial uplink BWP, and the like, which may be contained within an appropriate IE (e.g., uplinkConfigCommon IE). That IE may also include all appropriate information pertaining to a RACH procedure (e.g., RACH-ConfigCommon IE), the PUSCH (e.g., PUSCH-ConfigCommon IE), and the PUCCH (e.g., PUCCH-ConfigCommon) to allow the UE 3 to send a WUS message to the RAN node 5 to request on-demand SIB1 transmissions for the non-anchor node.

[0113] Additionally, the WUS configuration message may also include a carrier indicator or a local cell ID to indicate the carrier over which the WUS message can be sent to the RAN node 5 (i.e., over the anchor cell carrier or the non-anchor cell carrier). Additionally, the WUS configuration message may also include an indication of an initial UL BWP (e.g., a InitialULBWP IE) that may be used by the UE 3 to perform initial access procedures. For example, the initial UL BWP may correspond to a specific part of the total channel bandwidth configured for a cell that is used for the UE 3 when performing initial access procedures.

[0114] Typically, SIB1 transmissions also contain indications of an ARFCN of 'Point A' ('Point A' is typically positioned at the starting point of the frequency grid for resource allocation and is associated with subcarrier 0 of CORESET block 0, regardless of the subcarrier spacing used in the system) for the UL or SUL to help establish a consistent framework for allocating subcarriers and resource blocks across different communication scenarios for UEs and RAN nodes. For example, SIB1 may contain appropriate IEs to indicate the ARFCN of 'Point A' for the UL or SUL to a UE.

[0115] A simplified example of an ASN.1 representation of a possible implementation of such an IE in the SIB1, is provided below by way of Illustration only (only showing relevant parts of the information element): 　　frequencyBandList MultiFrequencyBandListNR-SIB 　　OPTIONAL, -- Cond FDD-OrSUL 　　absoluteFrequencyPointA ARFCN-ValueNR 　　OPTIONAL, -- Cond FDD-OrSUL

[0116] It will be appreciated that, when SIB1 transmissions are on-demand (such as for a non-anchor cell), an indication of the ARFCN of 'Point A' for the UL or SUL may be provided in the WUS configuration message. By way of example only, in the frequency domain, as there is a known (pre-dined) offset between UL ARFCN and DL ARFCN for 'Point A', the offset to the start of the frequency domain position for a SS / PBCH block may be specified and can be used to determine an initial UL frequency position for resource allocation of the WUS message. In this scenario, although the UE 3 may not immediately know the position of 'Point A' after completing a band scan it will nevertheless be able to identify the SS / PBCH block. Accordingly, upon reception of the on-demand SIB1 transmission the UE 3 can proceed to decode the SIB1s without knowing 'Point A' because the air-interface resources allocated are signalled relative to the position of SS / PBCH block.

[0117] In the scenario described above, the WUS configuration is provided to the UE 3 using via appropriate broadcast signalling (e.g., paging information signalling that sends paging information to the UE 3). Alternatively, the WUS configuration message may be sent to the UE 3 by the RAN node 5 via appropriate RRC messages (e.g., an RRC connection release message, or the like). Nevertheless, it will be appreciated that if the UE 3 is in RRC_CONNECTED mode before cell re-selection, and has moved into RRC_INACTIVE mode, the WUS configuration may be provided to the UE 3 via an appropriate SIB transmission (e.g., SIB2 / 3 / 4 etc.,).Alternatively, the WUS configuration may be provided to the UE 3 via RRC (re)configuration messages transmitted to the UE 3 while the UE 3 was in RRC_CONNECTED mode

[0118] At step S312, having received the WUS configuration message, the UE 3 may use the allocated resources indicated in the WUS configuration message to transmit an appropriate WUS message to the RAN node 5 to request on-demand SIB1 transmissions for the non-anchor cell.

[0119] At step S314, having received the WUS message requesting on-demand SIB1 transmissions for the non-anchor cell, the RAN node 5 may (optionally) transmit a DCI message (e.g., a DCI format 1_0 message scrambled with SI-RNTI) to indicate to the UE 3 appropriate resources on which to expect to receive the SIB1 transmissions. For example, the DCI message may indicate that the on-demand SIB1s are to be transmitted to the UE 3 periodically within a specific SIB1 transmission period (e.g., a period of 160 ms) from a specific start time. The specific start time may, by way of example, correspond to the time immediately following transmission of the DCI format 1_0 message. Alternatively, the specific start time may, by way of example, correspond to the end of a specified time delay window. For example, the transmission start time for the SIB1s may be delayed until the start of a next SIB1 periodicity (i.e., the start of the next 160 ms period), following the transmission of the DCI format 1_0 that indicates the SIB1 resources.

[0120] Alternatively, or additionally, the DCI message may indicate that the on-demand SIB1s are to be transmitted to the UE 3 a specific number of times. For example, the DCI format 1_0 may indicate the SIB1 transmission period is 160 ms, and that the on-demand SIB1s are to be transmitted to the UE 3 once every 40 ms i.e., the RAN node 5 will transmit on-demand SIB1s to the UE 3 four times in the 160 ms SIB1 transmission period.

[0121] Alternatively, having received the WUS message requesting an on-demand SIB1 transmissions for the non-anchor cell, the RAN node 5 may not need to transmit a DCI message if the appropriate resources on which to expect to receive the on-demand SIB1 transmissions have already been indicated to the UE 3 by an earlier message. In one example, the appropriate resources may be indicated to the UE 3 in the WUS configuration sent at step S306. In another example, the appropriate resources may be indicated to the UE 3 in an appropriate response message (not shown) sent by the RAN node 5 to the UE 3 having received the WUS message to request on-demand SIB1 transmissions at step S312.

[0122] Alternatively, having received the WUS message requesting on-demand SIB1 transmissions for the non-anchor cell, the RAN node 5 may not need to transmit a DCI message even if the appropriate resources on which to expect to receive on-demand SIB1 transmissions has not been previously signalled to the UE 3 if a specific time window for receiving on-demand SIB1 transmissions is pre-configured (hard coded) at the UE 3. For example, the UE 3 may start to monitor for on-demand SIB1 transmissions from the RAN node 5 immediately after transmitting the WUS message, and it may expect the on-demand SIB1 transmissions to be transmitted using a legacy periodicity (e.g., 160 ms).

[0123] At step S316, the RAN node 5 transmits on-demand SIB1 transmissions to the UE 3 for the non-anchor cell. It will be appreciated that the on-demand SIB1 may be transmitted to the UE 3 over the anchor cell if the UE 3 is not yet able to communicate with the RAN node 5 over the non-anchor cell (e.g., when the UE 3 has not camped onto the cell). It will also be appreciated that the on-demand SIB1 may not be transmitted to the UE 3 over the anchor cell if the UE 3 able to communicate with the RAN node 5 over a different cell (e.g., the non-anchor cell).

[0124] Fig. 4 depicts a simplified sequence diagram illustrating another procedure for on-demand SIB1 transmissions to a UE 3 for a non-anchor cell 9Non-anchorthat may be used in the communication system 1 of Fig. 1.

[0125] As shown in Fig. 4 there is provided a RAN node 5 and a UE 3 deployed in the communication system 1 of Fig. 1. The UE 3 may be camped on an anchor cell provided by the RAN node 5 to allow communication with the RAN node 5. Once camped on the anchor cell, the UE 3 may enter RRC IDLE mode or RRC INACTIVE mode. The nature of RRC IDLE mode or RRC INACTIVE mode is previously described above with reference to Fig. 3.

[0126] At step S402 the RAN node 5 may transmit system information to the UE 3 such as a MIB. The MIB is transmitted to the UE 3 over the PBCH with a periodicity of 80 ms, and typically contains the information necessary for the UE 3 to receive a subsequent SIB1 transmission the anchor cell.

[0127] For example, the MIB may contain indications of the MSBs of a current SFN (e.g., systemFrameNumber IE), the subcarrier spacing to be used for the SIB1 message (e.g., subCarrierSpacingCommon IE), kSSBthat defines a subcarrier offset between the Common Resource Block grid and the SS / PBCH block, and the like. kSSBmay also be used to indicate whether or not the MIB has an associated CORESET which can be used by the PDCCH when allocating PDSCH resources for SIB1.

[0128] The MIB may also contain a pointer (e.g., controlReseourceSetZero IE) to aspects of standardised look-up tables that define a SS / PBCH block and CORESET multiplexing pattern, the number of resources bellowing to the CORESET, the number of symbols belonging to the CORESET, and the frequency domain offset between the SS / PBCH block and the CORESET. In addition, the MIB may also contain a pointer (e.g., searchSpaceZero sub-IE) to aspects of standardised look-up tables that define the timing offset between the SS / PBCH block and the search space for SIB1, the number of search space sets per slot, and the first symbol belonging to the search space sets. Both the pointer (e.g., controlReseourceSetZero sub-IE) to aspects of standardised look-up tables, and the pointer (e.g., searchSpaceZero IE) to aspects of standardised look-up tables may be contained together in an IE of the MIB (e.g., pdcch-ConfigSIB1 IE).

[0129] Having received the MIB, the UE 3 decodes the MIB, at step S404, and may store the decoded MIB locally at the UE 3 for future use.

[0130] Sometime later, the UE 3 may receive from the RAN node 5, at step S406, a DCI message (e.g., DCI format 1_0 with CRC scrambled by SI-RNTI) to schedule on-demand SIB1 transmissions (and possibly other SIB messages). In that DCI message, the RAN node 5 may include an indication in one of its reserved bits that SIB1 transmissions for one or more non-anchor cells are implemented on an on-demand basis. That 1-bit indication may take the form of a new IE in the DCI format 1_0 with CRC scrambled by SI-RNTI (e.g., SIB1BroadcastStatus IE). Where the SIB1 transmissions for non-anchor cells are implemented on an on-demand basis the new IE may be set to 'notBroadcasting'.

[0131] It will nevertheless be appreciated that the indication that SIB1 transmissions for a non-anchor cell provided in the DCI Format 1_0 message may take the form a multi-bit indication (e.g., 2 or more bits) - e.g., a bitmap indication, or a bit-string.

[0132] The DCI message sent at step S406, may be sent once to indicate to the UE 3 that the SIB1 transmissions for non-anchor cells are implemented on an on-demand basis, or alternatively, the DCI message may be sent periodically to update the UE 3 as to whether SIB1 transmissions for non-anchor cells are implemented on an on-demand basis. For example, the DCI message may be sent to the UE 3 every multiple of 160 ms (e.g. k-wus*160 ms), where 160 ms is the legacy periodicity of SIB1 transmissions.

[0133] Having decoded the MIB and having received the DCI message at steps S404 and S406, the UE 3 may, at step S407, the UE 3 may determine that on-demand SIB1 transmissions are required.

[0134] At step S408, having determined that on-demand SIB1 transmissions are required, the UE 3 may send an appropriate request message (e.g., a WUS resource request message) to the RAN node 5 to request a WUS configuration to enable the UE 3 to send an appropriate WUS message to the RAN node 5 to request on-demand SIB1 transmissions for the non-anchor node.

[0135] In one example, the WUS resource request message may be sent to the RAN node 5 as part of an appropriate PRACH preamble message selected by the UE 3 as part of a RACH procedure for initial attach onto the RAN node 5 if the UL between the UE 3 and RAN node 5 is not synchronised.

[0136] In another example, if the UL between the UE 3 and RAN node 5 is already synchronised, the WUS resource request message may be sent to the RAN node 5 as part of an appropriate SR message. For example, the WUS resource request message may form part of SR message that is sent to the RAN node 5 to request the RAN node 5 to send an UL grant (DCI Format 0) so that the UE 3 can transmit data on the PUSCH to the RAN node 5. The SR message may be sent to the RAN node over the PUCCH using a specific PUCCH format (e.g., PUCCH Format 0).

[0137] Having received the WUS resource request message the RAN node 5, at step S410, may process the WUS resource request message and perform an appropriate resource allocation procedure to allocate appropriate resources for the UE 3 to use to send an appropriate WUS message to the RAN node 5 to request on-demand SIB1 transmissions for the non-anchor node.

[0138] In one example, the RAN node 5 may configure the resources in the time domain such that the resources are offset in time relative to a DL signal sent from the RAN node 5 to the UE 3 (e.g., such as a DRS and / or an SSB. That offset may be configurable by the RAN node 5, or alternatively, it may be pre-defined (e.g., hard coded)). For example, the resources may be allocated such that the UE 3 can send the WUS message to the RAN node 5 nWUSslots after the latest DRS and / or SSB reception by the UE 3. The value of nWUSmay be selected to correspond to the minimum processing time capabilities of the UE 3.

[0139] The RAN node 5 may alternatively, or additionally configure the resources in the frequency domain such that the resources are offset to the start of a RB of an initial UL BWP, or they may be offset to the start of the frequency domain position of the CORESET associated with the Type 0 Common Search Space Set i.e. the frequency domain position of the CORESET 0 that carries PDCCH / DCI for SIB1. That offset may be configurable by the RAN node 5, or alternatively, it may be pre-defined (e.g., hard coded).

[0140] At step S412, having allocated appropriate resources for the UE 3 to use to send an appropriate WUS message to the RAN node 5, the RAN node 5 may send a configuration message to the UE 3. For example, the RAN node 5 may send an appropriate configuration message to indicate the allocated resources to the UE 3 (e.g., a WUS configuration message indicating the time offset, frequency offset, and / or other configuration information). The WUS configuration message may be sent to the UE 3 by the RAN node 5 via appropriate broadcast signalling (e.g., paging information signalling that sends paging information to the UE 3). Alternatively, the WUS configuration message may be sent to the UE 3 by the RAN node 5 via appropriate RRC messages (e.g., an RRC connection release message, or the like).

[0141] As well as indicating the allocated resources to the UE 3 (i.e., providing an UL grant for the allocated resources), the WUS configuration message may additionally include appropriate information to (re)configure the UL between the RAN node 5 and the UE 3. For example, the WUS configuration message may include an indication of the frequency of the uplink, the subcarrier spacing used, the initial uplink BWP, and the like, which may be contained within an appropriate IE (e.g., uplinkConfigCommon IE). That IE may also include all appropriate information pertaining to a RACH procedure (e.g., RACH-ConfigCommon IE), the PUSCH (e.g., PUSCH-ConfigCommon IE), and the PUCCH (e.g., PUCCH-ConfigCommon) to allow the UE 3 to send a WUS message to the RAN node 5 to request an on-demand SIB1 for the non-anchor node.

[0142] Additionally, the WUS configuration message may also include a carrier indicator or a local cell ID to indicate the carrier over which the WUS message can be sent to the RAN node 5 (i.e., over the anchor cell carrier or the non-anchor cell carrier). Additionally, the WUS configuration message may also include an indication of an initial UL BWP (e.g., a InitialULBWP IE) that may be used by the UE 3 to perform initial access procedures. For example, the initial UL BWP may correspond to a specific part of the total channel bandwidth configured for a cell that is used for the UE 3 when performing initial access procedures.

[0143] At step S414, having received the WUS configuration message, the UE 3 may use the allocated resources indicated in the WUS configuration message to transmit an appropriate WUS message to the RAN node 5 to request on-demand SIB1 transmissions for the non-anchor cell.

[0144] At step S416, having received the WUS message requesting on-demand SIB1 transmissions for the non-anchor cell, the RAN node 5 may (optionally) transmit a DCI message (e.g., a DCI format 1_0 message scrambled with SI-RNTI) to indicate to the UE 3 appropriate resources on which to expect to receive the on-demand SIB1 transmissions. For example, the DCI message may indicate that the on-demand SIB1 is to be transmitted to the UE 3 periodically within a specific SIB1 transmission period (e.g., a period of 160 ms) from a specific start time.

[0145] The specific start time may, by way of example, correspond to the time immediately following transmission of the DCI format 1_0 message. Alternatively, the specific start time may, by way of example, correspond to the end of a specified time delay window. For example, the transmission start time for the SIB1 may be delayed until the start of a next SIB1 periodicity (i.e., the start of the next 160 ms period), following the transmission of the DCI format 1_0 that indicates the SIB1 resources.

[0146] It will be appreciated that when receiving the WUS message requesting on-demand SIB1 transmissions, the network may need to decide for how long the on-demand SIB1 transmission are needed (i.e., a duration for how long the on-demand SIB1 transmissions should be sent to the UE 3). In one example, the on-demand SIB1 transmissions may be transmitted by the RAN node 5 for one or more legacy SIB1 periodicity. For example, on-demand SIB1s may be repeated at an interval defined by an appropriate multiple of the duration as defined by an appropriate parameter (e.g. 'N-on-demand-SIB1'), e.g., it can be 1 / 4, 1 / 2, 1, 2, 4…etc.). It will be appreciated that this can be less than one, since there may be multiple repetitions within one legacy SIB1 periodicity.

[0147] In one example, the exact timing window (e.g. M-SIB1-monitoring x SIB1 periodicity) for the UE to monitor the SIB1 transmission may be standardised. For example, the number of periodic SIB1s (e.g. M=4) may be predefined. Alternatively, the number of periodic SIB1s can be configured to the UE 3 within the DCI format 1_0, WUS configuration, or a response message to WUS.

[0148] Alternatively, or additionally, the DCI message may indicate that the on-demand SIB1 transmissions are to be transmitted to the UE 3 a specific number of times. For example, the DCI format 1_0 may indicate the SIB1 period is 160 ms, and that the SIB1s are to be transmitted to the UE 3 once every 40 ms i.e., the RAN node 5 will transmit the SIB1s to the UE 3 four times in the 160 ms SIB1 period.

[0149] Alternatively, having received the WUS message requesting on-demand SIB1 transmissions for the non-anchor cell, the RAN node 5 may not need to transmit a DCI message if the appropriate resources on which to expect to receive the on-demand SIB1 transmissions have already been indicated to the UE 3 by an earlier message. In one example, the appropriate resources may be indicated to the UE 3 in the WUS configuration sent at step S412. In another example, the appropriate resources may be indicated to the UE 3 in an appropriate response message (not shown) sent by the RAN node 5 to the UE 3 having received the WUS message to request on-demand SIB1 at step S414.

[0150] Alternatively, having received the WUS message requesting an on-demand SIB1 transmission for the non-anchor cell, the RAN node 5 may not need to transmit a DCI message even if the appropriate resources on which to expect to receive the SIB1 has not been previously signalled to the UE 3 if a specific time window is pre-configured (hard coded) at the UE 3 for receiving on-demand SIB1 transmissions. For example, the UE 3 may start to monitor for SIB1 transmissions from the RAN node 5 immediately after transmitting the WUS message, and it may expect the SIB1 transmissions to be transmitted using a legacy periodicity (e.g., 160 ms).

[0151] At step S418, the RAN node 5 transmits on-demand SIB1 transmissions to the UE 3 for the non-anchor cell. It will be appreciated that the on-demand SIB1s may be transmitted to the UE 3 over the anchor cell if the UE 3 is not yet able to communicate with the RAN node 5 over the non-anchor cell (e.g., when the UE 3 has not camped onto the cell).

[0152] Fig. 5 depicts a simplified sequence diagram illustrating another procedure for on-demand SIB1 transmissions to a UE 3 for a non-anchor cell 9Non-anchorthat may be used in the communication system 1 of Fig. 1.

[0153] As shown in Fig. 5 there is provided a RAN node 5 and a UE 3 deployed in the communication system 1 of Fig. 1. The UE 3 may be camped on an anchor cell provided by the RAN node 5 to allow communication with the RAN node 5. Once camped on the anchor cell, the UE 3 may enter RRC IDLE mode or RRC INACTIVE mode. The nature of RRC IDLE mode or RRC INACTIVE mode is previously described above with reference to Fig. 3.

[0154] At step S502 the RAN node 5 may transmit system information to the UE 3 such as a MIB. The MIB is transmitted to the UE 3 over the PBCH with a periodicity of 80 ms, and typically contains the information necessary for the UE 3 to receive a subsequent SIB1 transmission. For example, the MIB may contain indications of the MSBs of a current SFN (e.g., systemFrameNumber information element IE), the subcarrier spacing to be used for the SIB1 message (e.g., subCarrierSpacingCommon IE), kSSBthat defines a subcarrier offset between the Common Resource Block grid and the SS / PBCH block, and the like. kSSBmay also be used to indicate whether or not the MIB has an associated CORESET which can be used by the PDCCH when allocating PDSCH resources for SIB1.

[0155] The MIB may also contain a pointer (e.g., controlReseourceSetZero IE) to aspects of standardised look-up tables that define a SS / PBCH block and CORESET multiplexing pattern, the number of resources bellowing to the CORESET, the number of symbols belonging to the CORESET, and the frequency domain offset between the SS / PBCH block and the CORESET. In addition, the MIB may also contain a pointer (e.g., searchSpaceZero sub-IE) to aspects of standardised look-up tables that define the timing offset between the SS / PBCH block and the search space for SIB1, the number of search space sets per slot, and the first symbol belonging to the search space sets. Both the pointer (e.g., controlReseourceSetZero sub-IE) to aspects of standardised look-up tables, and the pointer (e.g., searchSpaceZero IE) to aspects of standardised look-up tables may be contained together in an IE of the MIB (e.g., pdcch-ConfigSIB1 IE).

[0156] Having received the MIB, the UE 3 decodes the MIB, at step S504, and may store the decoded MIB locally at the UE 3 for future use.

[0157] Sometime later, the UE 3 may receive from the RAN node 5, at step S506, a DCI message (e.g., DCI format 1_0 with CRC scrambled by SI-RNTI) to schedule SIB1 and other SIB messages. In that DCI message, the RAN node 5 may include an indication in one of its reserved bits that SIB1 transmissions for one or more non-anchor cells are implemented on an on-demand basis. That 1-bit indication may take the form of a new IE in the DCI format 1_0 with CRC scrambled by SI-RNTI (e.g., SIB1BroadcastStatus IE). Where the SIB1 transmissions for non-anchor cells are implemented on an on-demand basis the new IE may be set to 'notBroadcasting'.

[0158] It will nevertheless be appreciated that the indication that SIB1 transmissions for a non-anchor cell provided in the DCI Format 1_0 message may take the form a multi-bit indication (e.g., 2 or more bits) - e.g., a bitmap indication, or a bit-string.

[0159] In addition, the DCI message may also include a pointer indicating to the UE 3 resources associated with a PDSCH that may be used by the RAN node 5 at some future time to send a WUS configuration to the UE 3 if, and when, it requests such a WUS configuration.

[0160] The DCI message sent at step S506, may be sent once to indicate to the UE 3 that the SIB1 transmissions for non-anchor cells are implemented on an on-demand basis, or alternatively, the DCI message may be sent periodically to update the UE 3 as to whether SIB1 transmissions for non-anchor cells are implemented on an on-demand basis. For example, the DCI message may be sent to the UE 3 every multiple of 160 ms (e.g. k-wus*160 ms), where 160 ms is the legacy periodicity of SIB1 transmissions.

[0161] Having decoded the MIB and having received the DCI message at steps S504 and S506, the UE 3 may, at step S507, determine that on-demand SIB1 transmissions for a non-anchor cell are required.

[0162] At step S508, having decided that on-demand SIB1 transmissions for a non-anchor cell are required, the UE 3 may send an appropriate request message (e.g., a WUS resource request message) to the RAN node 5 to request a WUS configuration to enable the UE 3 to send an appropriate WUS message to the RAN node 5 to request on-demand SIB1 transmissions for the non-anchor node.

[0163] In one example, the WUS resource request message may be sent to the RAN node 5 as part of an appropriate PRACH preamble message selected by the UE 3 as part of a RACH procedure for initial attach onto the RAN node 5 if UL between the UE 3 and RAN node 5 is not synchronised.

[0164] In another example, if the UL between the UE 3 and RAN node 5 is already synchronised, the WUS resource request message may be sent to the RAN node 5 as part of an appropriate SR message. For example, the WUS resource request message may form part of SR message that is sent to the RAN node 5 to request the RAN node 5 to send an UL grant (DCI Format 0) so that the UE 3 can transmit data on the PUSCH to the RAN node 5. The SR message may be sent to the RAN node over the PUCCH using a specific PUCCH format (e.g., PUCCH Format 0).

[0165] Having received the WUS resource request message the RAN node 5, at step S510, may process the WUS resource request message and perform an appropriate resource allocation procedure to allocate appropriate resources for the UE 3 to use to send an appropriate WUS message to the RAN node 5 to request on-demand SIB1 transmissions for the non-anchor node.

[0166] In one example, the RAN node 5 may configure the resources in the time domain such that the resources are offset in time relative to a DL signal sent from the RAN node 5 to the UE 3 (e.g., such as a DRS and / or an SSB. That offset may be configurable by the RAN node 5, or alternatively, it may be pre-defined (e.g., hard coded). For example, the resources may be allocated such that the UE 3 can send the WUS message to the RAN node 5 nWUSslots after the latest DRS and / or SSB reception by the UE 3. The value of nWUSmay be selected to correspond to the minimum processing time capabilities of the UE 3.

[0167] The RAN node 5 may alternatively, or additionally, configure the resources in the frequency domain such that the resources are offset to the start of an RB of an initial UL BWP, or they may be offset to the start of the frequency domain position of the CORESET associated with the Type 0 Common Search Space Set i.e. the frequency domain position of the CORESET 0 that carries PDCCH / DCI for SIB1. That offset may be configurable by the RAN node 5, or alternatively, it may be pre-defined (e.g., hard coded).

[0168] At step S512, having allocated appropriate resources for the UE 3 to use to send an appropriate WUS message to the RAN node 5, the RAN node 5 may send a configuration message to the UE 3. For example, the RAN node 5 may send an appropriate configuration message to indicate the allocated resources to the UE 3 (e.g., a WUS configuration message indicating the time offset, frequency offset, and / or other configuration information). The WUS configuration message may be sent to the UE 3 by the RAN node 5 via the PDSCH using resources of the PDSCH indicated to the UE 3 by the RAN node 5 by a pointer in the DCI message sent at step S506.

[0169] Alternatively, if the PDSCH resources indicated to the UE 3 by the RAN node 5 by the pointer in the DCI message sent at step S506 correspond to PDSCH resources to be used by the RAN node 5 for transmitting a paging information configuration, then the RAN node 5 may send the WUS configuration message to the UE 3 via paging information.

[0170] As well as indicating the allocated resources to the UE 3, the WUS configuration message may additionally include appropriate information to (re)configure the UL between the RAN node 5 and the UE 3. For example, the WUS configuration message may include an indication of the frequency of the uplink, the subcarrier spacing used, the initial uplink BWP, and the like, which may be contained within an appropriate IE (e.g., uplinkConfigCommon IE). That IE may also include all appropriate information pertaining to a RACH procedure (e.g., RACH-ConfigCommon IE), the PUSCH (e.g., PUSCH-ConfigCommon IE), and the PUCCH (e.g., PUCCH-ConfigCommon) to allow the UE 3 to send a WUS message to the RAN node 5 to request an on-demand SIB1 for the non-anchor node.

[0171] Additionally, the WUS configuration message may also include a carrier indicator or a local cell ID to indicate the carrier over which the WUS message can be sent to the RAN node 5 (i.e., over the anchor cell carrier or the non-anchor cell carrier). Additionally, the WUS configuration message may also include an indication of an initial UL BWP (e.g., a InitialULBWP IE) that may be used by the UE 3 to perform initial access procedures. For example, the initial UL BWP may correspond to a specific part of the total channel bandwidth configured for a cell that is used for the UE 3 when performing initial access procedures.

[0172] At step S514, having received the WUS configuration message, the UE 3 may use the allocated resources indicated in the WUS configuration message to transmit an appropriate WUS message to the RAN node 5 to request on-demand SIB1 transmissions for the non-anchor cell.

[0173] At step S516, having received the WUS message requesting an on-demand SIB1 transmission for the non-anchor cell, the RAN node 5 may (optionally) transmit a DCI message (e.g., a DCI format 1_0 message scrambled with SI-RNTI) to indicate to the UE 3 appropriate resources on which to expect to receive the on-demand SIB1 transmissions. For example, the DCI message may indicate that the on-demand SIB1s are to be transmitted to the UE 3 periodically within a specific SIB1 transmission period (e.g., a period of 160 ms) from a specific start time. The specific start time may, by way of example, correspond to the time immediately following transmission of the DCI format 1_0 message. Alternatively, the specific start time may, by way of example, correspond to the end of a specified time delay window. For example, the transmission start time for the SIB1s may be delayed until the start of a next SIB1 periodicity (i.e., the start of the next 160 ms period), following the transmission of the DCI format 1_0 that indicates the SIB1 resources.

[0174] Alternatively, or additionally, the DCI message may indicate that the on-demand SIB1s are to be transmitted to the UE 3 a specific number of times. For example, the DCI format 1_0 may indicate the SIB1 period is 160 ms, and that the SIB1 is to be transmitted to the UE 3 once every 40 ms i.e., the RAN node 5 will transmit the SIB1 to the UE 3 four times in the 160 ms SIB1 period.

[0175] Alternatively, having received the WUS message requesting an on-demand SIB1 transmissions for the non-anchor cell, the RAN node 5 may not need to transmit a DCI message (e.g., a DCI format 1_0 message scrambled with SI-RNTI) to indicate to the UE 3 appropriate resources if the appropriate resources on which to expect to receive the on-demand SIB1 transmissions have already been indicated to the UE 3 by an earlier message. In one example, the appropriate resources may be indicated to the UE 3 in the WUS configuration sent at step S512. In another example, the appropriate resources may be indicated to the UE 3 in an appropriate response message (not shown) sent by the RAN node 5 to the UE 3 having received the WUS message to request on-demand SIB1 transmissions at step S516.

[0176] Alternatively, having received the WUS message requesting on-demand SIB1 transmissions for the non-anchor cell, the RAN node 5 may not need to transmit a DCI message even if the appropriate resources on which to expect to receive the SIB1 has not been previously signalled to the UE 3. if a specific time window for receiving on-demand SIB1 transmissions is pre-configured (hard coded) at the UE 3. For example, the UE 3 may start to monitor for on-demand SIB1 transmissions from the RAN node 5 immediately after transmitting the WUS message, and it may expect the on-demand SIB1 transmissions to be transmitted using a legacy periodicity (e.g., 160 ms).

[0177] At step S518, the RAN node 5 transmits on-demand SIB1s to the UE 3 for the non-anchor. It will be appreciated that the on-demand SIB1s may be transmitted to the UE 3 over the anchor cell if the UE 3 is not yet able to communicate with the RAN node 5 over the non-anchor cell (e.g., when the UE 3 has not camped onto the cell).

[0178] Fig. 6 depicts a simplified sequence diagram illustrating another procedure for on-demand SIB1 transmissions to a UE 3 for a non-anchor cell that may be used in the communication system 1 of Fig. 1.

[0179] As shown in Fig. 6 there is provided a RAN node 5 and a UE 3 deployed in the communication system 1 of Fig. 1. The UE 3 may be camped on a non-anchor cell provided by the RAN node 5 to allow communication with the RAN node 5 ('single cell' scenario). Once camped on the non-anchor cell, the UE 3 may enter RRC IDLE mode or RRC INACTIVE mode. The nature of RRC IDLE mode or RRC INACTIVE mode is previously described with reference to Fig. 3.

[0180] At step S602 the RAN node 5 may transmit system information to the UE 3 such as a MIB. The MIB is transmitted to the UE 3 over the PBCH with a periodicity of 80 ms, and typically contains the information necessary for the UE 3 to receive a subsequent SIB1 transmission on the anchor cell.

[0181] For example, the MIB may contain indications of the MSBs of a current SFN (e.g., systemFrameNumber IE), the subcarrier spacing to be used for the SIB1 message (e.g., subCarrierSpacingCommon IE), kSSBthat defines a subcarrier offset between the Common Resource Block grid and the SS / PBCH block, and the like. kSSBmay also be used to indicate whether or not the MIB has an associated CORESET which can be used by the PDCCH when allocating PDSCH resources for SIB1.

[0182] The MIB may also contain a pointer (e.g., controlReseourceSetZero IE) to aspects of standardised look-up tables that define a SS / PBCH block and CORESET multiplexing pattern, the number of resources belonging to the CORESET, the number of symbols belonging to the CORESET, and the frequency domain offset between the SS / PBCH block and the CORESET. In addition, the MIB may also contain a pointer (e.g., searchSpaceZero sub-IE) to aspects of standardised look-up tables that define the timing offset between the SS / PBCH block and the search space for SIB1, the number of search space sets per slot, and the first symbol belonging to the search space sets. Both the pointer (e.g., controlReseourceSetZero sub-IE) to aspects of standardised look-up tables, and the pointer (e.g., searchSpaceZero IE) to aspects of standardised look-up tables may be contained together in an IE of the MIB (e.g., pdcch-ConfigSIB1 IE).

[0183] Having received the MIB, the UE 3 decodes the MIB, at step S604, and may store the decoded MIB locally at the UE 3 for future use.

[0184] Sometime later, the UE 3 may receive from the RAN node 5, at step S606, a DCI message (e.g., DCI format 1_0 with CRC scrambled by SI-RNTI) to schedule SIB1 and other SIB messages. In that DCI message, the RAN node 5 may include an indication in one of its reserved bits that SIB1 transmissions for non-anchor cells are implemented on an on-demand basis. That 1-bit indication may take the form of a new IE in the DCI format 1_0 with CRC scrambled by SI-RNTI (e.g., SIB1BroadcastStatus IE). Where the SIB1 transmissions for non-anchor cells are implemented on an on-demand basis the new IE may be set to 'notBroadcasting'.

[0185] It will nevertheless be appreciated that the indication that SIB1 transmissions for a non-anchor cell provided in the DCI Format 1_0 message may take the form a multi-bit indication (e.g., 2 or more bits) - e.g., a bitmap indication, or a bit-string.

[0186] In addition, the DCI message may also include a pointer indicating to the UE 3 resources associated with a PDSCH that may be used by the RAN node 5 at some future time to send a WUS configuration to the UE 3 if, and when, it requests such a WUS configuration.

[0187] The DCI message sent at step S506, may be sent once to indicate to the UE 3 that the SIB1 transmissions for non-anchor cells are implemented on an on-demand basis, or alternatively, the DCI message may be sent periodically to update the UE 3 as to whether SIB1 transmissions for non-anchor cells are implemented on an on-demand basis. For example, the DCI message may be sent to the UE 3 every multiple of 160 ms (e.g. k-wus*160 ms), where 160 ms is the legacy periodicity of SIB1 transmissions.

[0188] Having decoded the MIB and having received the DCI message at steps S604 and S606, the UE 3 may, at step S607, determine that on-demand SIB1 transmissions for a non-anchor cell are required.

[0189] At step S608, having decided that it wants to camp on / access the non-anchor cell, the UE 3 may send an appropriate request message (e.g., a WUS resource request message) to the RAN node 5 to request a WUS configuration to enable to the UE 3 to send an appropriate WUS message to the RAN node 5 to request an on-demand SIB1 for the non-anchor node.

[0190] In one example, the WUS resource request message may be sent to the RAN node 5 as part of an appropriate PRACH preamble message selected by the UE 3 as part of a RACH procedure for initial attach onto the RAN node 5 if the UL between the UE 3 and RAN node 5 is not synchronised.

[0191] Having received the WUS resource request message the RAN node 5, at step S610, may process the WUS resource request message and perform an appropriate resource allocation procedure to allocate appropriate resources for the UE 3 to use to send an appropriate WUS message to the RAN node 5 to request an on-demand SIB1 transmissions for the non-anchor node.

[0192] In one example, the RAN node 5 may configure the resources in the time domain such that the resources are offset in time relative to a DL signal sent from the RAN node 5 to the UE 3 (e.g., such as a DRS and / or an SSB. That offset may be configurable by the RAN node 5, or alternatively, it may be pre-defined (e.g., hard coded). For example, the resources may be allocated such that the UE 3 can send the WUS message to the RAN node 5 nWUSslots after the latest DRS and / or SSB reception by the UE 3. The value of nWUSmay be selected to correspond to the minimum processing time capabilities of the UE 3.

[0193] The RAN node 5 may alternatively, or additionally, configure the resources in the frequency domain such that the resources are offset to the start of an RB of an initial UL BWP, or they may be offset to the start of the frequency domain position of the CORESET associated with the Type 0 Common Search Space Set i.e. the frequency domain position of the CORESET 0 that carries PDCCH / DCI for SIB1. That offset may be configurable by the RAN node 5, or alternatively, it may be pre-defined (e.g., hard coded).

[0194] At step S612, having allocated appropriate resources for the UE 3 to use to send an appropriate WUS message to the RAN node 5 to request on-demand SIB1 transmissions for the non-anchor node, the RAN node 5 may send a configuration message to the UE 3. For example, the RAN node 5 may send an appropriate configuration message to indicate the allocated resources to the UE 3 (e.g., a WUS configuration message indicating the time offset, frequency offset, and / or other configuration information). The WUS configuration message may be sent to the UE 3 by the RAN node 5 via the PDSCH using resources of the PDSCH indicated to the UE 3 by the RAN node 5 by a pointer in the DCI message sent at step S606.

[0195] Alternatively, if the PDSCH resources indicated to the UE 3 by the RAN node 5 by the pointer in the DCI message sent at step S606 correspond to PDSCH resources to be used by the RAN node 5 for transmitting a paging information configuration, then the RAN node 5 may send the WUS configuration message to the UE 3 via paging information.

[0196] As well as indicating the allocated resources to the UE 3 (i.e., providing an UL grant for the allocated resources), the WUS configuration message may additionally include appropriate information to (re)configure the UL between the RAN node 5 and the UE 3. For example, the WUS configuration message may include an indication of the frequency of the uplink, the subcarrier spacing used, the initial uplink BWP, and the like, which may be contained within an appropriate IE (e.g., uplinkConfigCommon IE). That IE may also include all appropriate information pertaining to a RACH procedure (e.g., RACH-ConfigCommon IE), the PUSCH (e.g., PUSCH-ConfigCommon IE), and the PUCCH (e.g., PUCCH-ConfigCommon) to allow the UE 3 to send a WUS message to the RAN node 5 to request an on-demand SIB1 for the non-anchor node.

[0197] Additionally, the WUS configuration message may also include a carrier indicator or a local cell ID to indicate the carrier over which the WUS message can be sent to the RAN node 5 (i.e., over the anchor cell carrier or the non-anchor cell carrier). Additionally, the WUS configuration message may also include an indication of an initial UL BWP (e.g., a InitialULBWP IE) that may be used by the UE 3 to perform initial access procedures. For example, the initial UL BWP may correspond to a specific part of the total channel bandwidth configured for a cell that is used for the UE 3 when performing initial access procedures.

[0198] At step S614, having received the WUS configuration message, the UE 3 may use the allocated resources indicated in the WUS configuration message to transmit an appropriate WUS message to the RAN node 5 to request on-demand SIB1 transmissions for the non-anchor cell.

[0199] At step S616, having received the WUS message requesting on-demand SIB1 transmissions for the non-anchor cell, the RAN node 5 may (optionally) transmit a DCI message (e.g., a DCI format 1_0 message scrambled with SI-RNTI) to indicate to the UE 3 appropriate resources on which to expect to receive the on-demand SIB1 transmissions. For example, the DCI message may indicate that the on-demand SIB1s are to be transmitted to the UE 3 periodically within a specific SIB1 transmission period (e.g., a period of 160 ms) from a specific start time. The specific start time may, by way of example, correspond to the time immediately following transmission of the DCI format 1_0 message. Alternatively, the specific start time may, by way of example, correspond to the end of a specified time delay window. For example, the transmission start time for the on-demand SIB1s may be delayed until the start of a next SIB1 periodicity (i.e., the start of the next 160 ms period), following the transmission of the DCI format 1_0 that indicates the SIB1 resources.

[0200] Alternatively, or additionally, the DCI message may indicate that on-demand SIB1 transmissions are to be transmitted to the UE 3 a specific number of times. For example, the DCI format 1_0 may indicate the SIB1 period is 160 ms, and that the on-demand SIB1s are to be transmitted to the UE 3 once every 40 ms i.e., the RAN node 5 will transmit the on-demand SIB1s to the UE 3 four times in the 160 ms SIB1 period.

[0201] Alternatively, having received the WUS message requesting on-demand SIB1 transmissions for the non-anchor cell, the RAN node 5 may not need to transmit a DCI message (e.g., a DCI format 1_0 message scrambled with SI-RNTI) to indicate to the UE 3 appropriate resources on which to expect to receive the SIB1 if the appropriate resources on which to expect to receive the SIB1 have already been indicated to the UE 3 by an earlier message. In one example, the appropriate resources may be indicated to the UE 3 in the WUS configuration sent at step S612. In another example, the appropriate resources may be indicated to the UE 3 in an appropriate response message (not shown) sent by the RAN node 5 to the UE 3 having received the WUS message to request on-demand SIB1 at step S614.

[0202] Alternatively, having received the WUS message requesting an on-demand SIB1 transmission for the non-anchor cell, the RAN node 5 may not need to transmit a DCI message even if the appropriate resources on which to expect to receive the SIB1 has not been previously signalled to the UE 3 if a specific time window is pre-configured (hard coded) for on-demand SIB1 transmissions at the UE 3. For example, the UE 3 may start to monitor for on-demand SIB1 transmissions from the RAN node 5 immediately after transmitting the WUS message, and it may expect on-demand SIB1 transmissions to be transmitted using a legacy periodicity (e.g., 160 ms).

[0203] At step S618, the RAN node 5 transmits on-demand SIB1 to the UE 3 for the non-anchor cell. It will be appreciated that the on-demand SIB1s may be transmitted to the UE 3 over the non-anchor cell if the UE 3 is already camped on the non-anchor cell as in this case.

[0204] Fig. 7 depicts a simplified sequence diagram illustrating another procedure for on-demand SIB1 transmissions to a UE 3 for a non-anchor cell that may be used in the communication system 1 of Fig. 1.

[0205] As shown in Fig. 7 there is provided a RAN node 5 and a UE 3 deployed in the communication system 1 of Fig. 1. The UE 3 may be camped on an anchor cell provided by the RAN node 5 to allow communication with the RAN node 5. Once camped on the anchor cell, the UE 3 may enter RRC IDLE mode or RRC INACTIVE mode. The nature of RRC IDLE mode or RRC INACTIVE mode is previously described with reference to Fig. 3.

[0206] At step S702 the RAN node 5 may transmit system information to the UE 3 such as a MIB. The MIB is transmitted to the UE 3 over the PBCH with a periodicity of 80 ms, and typically contains the information necessary for the UE 3 to receive a subsequent SIB1 transmission on the anchor cell.

[0207] For example, the MIB may contain indications of the MSBs of a current SFN (e.g., systemFrameNumber IE), the subcarrier spacing to be used for the SIB1 message (e.g., subCarrierSpacingCommon IE), kSSBthat defines a subcarrier offset between the Common Resource Block grid and the SS / PBCH block, and the like. kSSBmay also be used to indicate whether or not the MIB has an associated CORESET which can be used by the PDCCH when allocating PDSCH resources for SIB1.

[0208] The MIB may also contain a pointer (e.g., controlReseourceSetZero sub-IE) to aspects of standardised look-up tables that define a SS / PBCH block and CORESET multiplexing pattern, the number of resources bellowing to the CORESET, the number of symbols belonging to the CORESET, and the frequency domain offset between the SS / PBCH block and the CORESET. In addition, the MIB may also contain a pointer (e.g., searchSpaceZero sub-IE) to aspects of standardised look-up tables that define the timing offset between the SS / PBCH block and the search space for SIB1, the number of search space sets per slot, and the first symbol belonging to the search space sets. Both the pointer (e.g., controlReseourceSetZero sub-IE) to aspects of standardised look-up tables, and the pointer (e.g., searchSpaceZero IE) to aspects of standardised look-up tables may be contained together in an IE of the MIB (e.g., pdcch-ConfigSIB1 IE).

[0209] In addition, a spare bit in the MIB may be used by the RAN node 5 to indicate to the UE 3 that the SIB1 for a non-anchor cell provided by the RAN node 5 may be provided to the UE 3 on-demand. For example, a new IE (e.g., WUS-SIB1Config IE) comprising of a one-bit indication may be provided in the MIB to indicate to the UE 3 that the SIB1 for a non-anchor cell provided by the RAN node 5 may be provided to the UE 3 on-demand.

[0210] Alternatively, or additionally, kSSBthat defines a subcarrier offset between the Common Resource Block grid and the SS / PBCH block may be adapted to include an indication as to whether SIB1 transmission for a non-anchor cell provided by the RAN node 5 may be provided to the UE 3 on an on-demand basis. By way of example only, the kSSBmay be defined with a new value other than that used in legacy to indicate on-demand SIB1 transmission e.g., where kSSBis 30 for FR1 or kSSBis 14 for FR2, the kSSBcould be defined with the value of 16 * controlResourceSetZero + searchSpaceZerorequest + 'On-demand SIB1' indication.

[0211] In addition, the pointer in the MIB that defines the SS / PBCH block and CORESET multiplexing pattern (e.g., pdcch-ConfigSIB1 IE) may be adapted to indicate the SS / PBCH block, CORESET, and an appropriate configuration message (e.g., an WUS configuration) to enable the UE 3 to send an appropriate WUS message to the RAN node 5 to request an on-demand SIB1 transmissions for the non-anchor node. By way of example only, the pdcch-ConfigSIB1 IE may configured to include a dedicated pointer (e.g., wusConfig sub-IE) to aspects of standardised look-up tables that define the WUS configuration.

[0212] A simplified example of an ASN.1 representation of a possible implementation of a modified pdcch-ConfigSIB1 IE is provided below by way of Illustration only (only showing relevant parts of the information element): 　　PDCCH-ConfigSIB1 ::= SEQUENCE { 　　　　controlResourceSetZero ControlResourceSetZero-v2, 　　　　searchSpaceZero SearchSpaceZero-v2 　　　　wusConfig WUSConfig 　　}

[0213] Alternatively, or additionally, kSSBthat defines a subcarrier offset between the Common RB grid and the SS / PBCH block may be adapted to include an indication of an appropriate configuration message (e.g., an WUS configuration) to enable the UE 3 to send an appropriate WUS message to the RAN node 5 to request an on-demand SIB1 transmissions for the non-anchor node. By way of example only, kSSB(derived from the ssb_SubcarrierOffset IE in the MIB) may be used to specify a selected WUS configuration from standardised look-up tables that define the WUS configuration. It will be appreciated that the kSSBmay also jointly specify the selected WUS configuration (e.g., with the pdcch-ConfigSIB1 IE).

[0214] The WUS configuration may indicate resources to the UE 3 that have been allocated by the RAN node 5 for use by the UE 3 to transmit a WUS message to the RAN node 5 requesting on-demand SIB1 transmissions for a non-anchor cell. In one example, the RAN node 5 may configure the resources in the time domain such that the resources are offset in time relative to a DL signal sent from the RAN node 5 to the UE 3 (e.g., such as a DRS and / or an SSB. That offset may be configurable by the RAN node 5, or alternatively, it may be pre-defined (e.g., hard coded). For example, the resources may be allocated such that the UE 3 can send the WUS message to the RAN node 5 nWUSslots after the latest DRS and / or SSB reception by the UE 3. The value of nWUSmay be selected to correspond to the minimum processing time capabilities of the UE 3.

[0215] The RAN node 5 may alternatively, or additionally, configure the resources in the frequency domain such that the resources are offset to the start of an RB of an initial UL BWP, or they may be offset to the start of the frequency domain position of the CORESET associated with the Type 0 Common Search Space Set i.e. the frequency domain position of the CORESET 0 that carries PDCCH / DCI for SIB1. That offset may be configurable by the RAN node 5, or alternatively, it may be pre-defined (e.g., hard coded).

[0216] As well as indicating the allocated resources to the UE 3 (i.e., providing an UL grant for the allocated resources), the WUS configuration message may additionally include appropriate information to (re)configure the UL between the RAN node 5 and the UE 3. For example, the WUS configuration message may include an indication of the frequency of the uplink, the subcarrier spacing used, the initial uplink BWP, and the like, which may be contained within an appropriate IE (e.g., uplinkConfigCommon IE). That IE may also include all appropriate information pertaining to a RACH procedure (e.g., RACH-ConfigCommon IE), the PUSCH (e.g., PUSCH-ConfigCommon IE), and the PUCCH (e.g., PUCCH-ConfigCommon) to allow the UE 3 to send a WUS message to the RAN node 5 to request an on-demand SIB1 transmissions for the non-anchor node.

[0217] Additionally, the WUS configuration message may also include a carrier indicator or a local cell ID to indicate the carrier over which the WUS message can be sent to the RAN node 5 (i.e., over the anchor cell carrier or the non-anchor cell carrier). Additionally, the WUS configuration message may also include an indication of an initial UL BWP (e.g., a InitialULBWP IE) that may be used by the UE 3 to perform initial access procedures. For example, the initial UL BWP may correspond to a specific part of the total channel bandwidth configured for a cell that is used for the UE 3 when performing initial access procedures.

[0218] Having received the MIB, the UE 3 decodes the MIB, at step S704, and may store the decoded MIB locally at the UE 3 for future use. Having decoded the MIB, the UE 3 may determine, based on the indication included in e.g., WUS-SIB1Config IE, that SIB1 transmissions for a non-anchor cell are provided by the RAN node 5 on an on-demand basis. Furthermore, the UE 3 may also determine, at step S704, that on-demand SIB1 transmissions for a non-anchor cell are required.

[0219] At step S706, having received the MIB containing the WUS configuration message pointer, and having decided that on-demand SIB1 transmissions are required, the UE 3 may use the allocated resources indicated in the WUS configuration pointed to in the MIB in its wusConfig sub-IE to transmit an appropriate WUS message to the RAN node 5 to request on-demand SIB1 transmissions for the non-anchor cell.

[0220] At step S708, having received the WUS message requesting on-demand SIB1 transmissions for the non-anchor cell, the RAN node 5 may (optionally) transmit a DCI message (e.g., a DCI format 1_0 message scrambled with SI-RNTI) to indicate to the UE 3 appropriate resources on which to expect to receive the on-demand SIB1 transmissions. For example, the DCI message may indicate that the on-demand SIB1s are to be transmitted to the UE 3 periodically within a specific SIB1 transmission period (e.g., a period of 160 ms) from a specific start time. The specific start time may, by way of example, correspond to the time immediately following transmission of the DCI format 1_0 message. Alternatively, the specific start time may, by way of example, correspond to the end of a specified time delay window. For example, the transmission start time for the on-demand SIB1s may be delayed until the start of a next SIB1 periodicity (i.e., the start of the next 160 ms period), following the transmission of the DCI format 1_0 that indicates the SIB1 resources.

[0221] Alternatively, or additionally, the DCI message may indicate that on-demand SIB1 transmissions are to be transmitted to the UE 3 a specific number of times. For example, the DCI format 1_0 may indicate the SIB1 period is 160 ms, and that the on-demand SIB1s are to be transmitted to the UE 3 once every 40 ms i.e., the RAN node 5 will transmit the on-demand SIB1s to the UE 3 four times in the 160 ms SIB1 period.

[0222] Alternatively, having received the WUS message requesting on-demand SIB1 transmissions for the non-anchor cell, the RAN node 5 may not need to transmit a DCI message (e.g., a DCI format 1_0 message scrambled with SI-RNTI) to indicate to the UE 3 appropriate resources on which to expect to receive the SIB1 if the appropriate resources on which to expect to receive on-demand SIB1s have already been indicated to the UE 3 by an earlier message. In one example, the appropriate resources may be indicated to the UE 3 in the WUS configuration pointed to in the MIB in its wusConfig sub-IE. In another example, the appropriate resources may be indicated to the UE 3 in an appropriate response message (not shown) sent by the RAN node 5 to the UE 3 having received the WUS message to request on-demand SIB1 at step S706.

[0223] Alternatively, having received the WUS message requesting on-demand SIB1 transmissions for the non-anchor cell, the RAN node 5 may not need to transmit a DCI message even if the appropriate resources on which to expect to receive the on-demand SIB1s has not been previously signalled to the UE 3 if a specific time window for receiving the on-demand SIB1s is pre-configured (hard coded) at the UE 3. For example, the UE 3 may start to monitor for on-demand SIB1 transmissions from the RAN node 5 immediately after transmitting the WUS message, and it may expect the SIB1 transmissions to be transmitted using a legacy periodicity (e.g., 160 ms).

[0224] At step S710, the RAN node 5 transmits on-demand SIB1 to the UE 3 for the non-anchor cell. It will be appreciated that the on-demand SIB1 may be transmitted to the UE 3 over the anchor cell if the UE 3 is not yet able to communicate with the RAN node 5 over the non-anchor cell (e.g., when the UE 3 has not camped onto the cell).

[0225] Fig. 8 depicts a simplified sequence diagram illustrating another procedure for on-demand SIB1 transmissions to a UE 3 for a non-anchor cell that may be used in the communication system 1 of Fig. 1.

[0226] As shown in Fig. 8 there is provided a RAN node 5 and a UE 3 deployed in the communication system 1 of Fig. 1. The UE 3 may be camped on an anchor cell provided by the RAN node 5 to allow communication with the RAN node 5. Once camped on the anchor cell, the UE 3 may enter RRC IDLE mode or RRC INACTIVE mode. The nature of RRC IDLE mode or RRC INACTIVE mode is previously described with reference to Fig. 3.

[0227] At step S802 the RAN node 5 may transmit system information to the UE 3 such as a MIB. The MIB is transmitted to the UE 3 over the PBCH with a periodicity of 80 ms, and typically contains the information necessary for the UE 3 to receive a subsequent SIB1 transmission on the anchor cell.

[0228] For example, the MIB may contain indications of the MSBs of a current SFN (e.g., systemFrameNumber IE), the subcarrier spacing to be used for the SIB1 message (e.g., subCarrierSpacingCommon IE), kSSBthat defines a subcarrier offset between the Common Resource Block grid and the SS / PBCH block, and the like. kSSBmay also be used to indicate whether or not the MIB has an associated CORESET which can be used by the PDCCH when allocating PDSCH resources for SIB1.

[0229] The MIB may also contain a pointer (e.g., controlReseourceSetZero IE) to aspects of standardised look-up tables that define a SS / PBCH block and CORESET multiplexing pattern, the number of resources bellowing to the CORESET, the number of symbols belonging to the CORESET, and the frequency domain offset between the SS / PBCH block and the CORESET. In addition, the MIB may also contain a pointer (e.g., searchSpaceZero sub-IE) to aspects of standardised look-up tables that define the timing offset between the SS / PBCH block and the search space for SIB1, the number of search space sets per slot, and the first symbol belonging to the search space sets. Both the pointer (e.g., controlReseourceSetZero sub-IE) to aspects of standardised look-up tables, and the pointer (e.g., searchSpaceZero IE) to aspects of standardised look-up tables may be contained together in an IE of the MIB (e.g., pdcch-ConfigSIB1 IE).

[0230] In addition, a spare bit in the MIB may be used by the RAN node 5 to indicate to the UE 3 that the SIB1 for a non-anchor cell provided by the RAN node 5 may be provided to the UE 3 on-demand. For example, a new IE (e.g., WUS-SIB1Config IE) comprising of a one-bit indication may be provided in the MIB to indicate to the UE 3 that the SIB1 for a non-anchor cell provided by the RAN node 5 may be provided to the UE 3 on-demand.

[0231] Alternatively, or additionally, the subcarrier spacing offset (kSSB) that defines a subcarrier offset between the Common Resource Block grid and the SS / PBCH block may be adapted to include an indication as to whether SIB1 transmission for a non-anchor cell provided by the RAN node 5 may be provided to the UE 3 on an on-demand basis. By way of example only, the kSSBmay be defined with a new value other than that used in legacy to indicate on-demand SIB1 transmission e.g., where kSSBis 30 for FR1 or kSSBis 14 for FR2, the kSSBcould be defined with the value of 16 * controlResourceSetZero + searchSpaceZerorequest + 'On-demand SIB1' indication.

[0232] Having received the MIB, the UE 3 decodes the MIB, at step S804, and may store the decoded MIB locally at the UE 3 for future use. Having decoded the MIB, the UE 3 may determine, based on the indication included in e.g., WUS-SIB1Config IE, that SIB1 transmissions for a non-anchor cell provided by the RAN node 5 is provided on an on-demand basis. Furthermore, the UE 3 may also determine, at step S804, that on-demand SIB1 transmissions for a non-anchor cell are required.

[0233] At step S806, having determined that that on-demand SIB1 transmissions for a non-anchor cell are required, the UE 3 may send an appropriate request message (e.g., WUS resource request message) to the RAN node 5 to request a WUS configuration to enable the UE 3 to send an appropriate WUS message to the RAN node 5 to request on-demand SIB1 transmissions for the non-anchor node.

[0234] In one example, the WUS resource request message may be sent to the RAN node 5 as part of an appropriate PRACH preamble message selected by the UE 3 as part of a RACH procedure for initial attach onto the RAN node 5 if the UL between the UE 3 and RAN node 5 is not synchronised.

[0235] In another example, if the UL between the UE 3 and RAN node 5 is already synchronised, the WUS resource request message may be sent to the RAN node 5 as part of an appropriate SR message. For example, the WUS resource request message may form part of SR message that is sent to the RAN node 5 to request the RAN node 5 to send an UL grant (DCI Format 0) so that the UE 3 can transmit data on the PUSCH to the RAN node 5. The SR message may be sent to the RAN node over the PUCCH using a specific PUCCH format (e.g., PUCCH Format 0).

[0236] Having received the WUS resource request message the RAN node 5, at step S808, may process the WUS resource request message and perform an appropriate resource allocation procedure to allocate appropriate resources for the UE 3 to use to send an appropriate WUS message to the RAN node 5 to request an on-demand SIB1 transmissions for the non-anchor node.

[0237] In one example, the RAN node 5 may configure the resources in the time domain such that the resources are offset in time relative to a DL signal sent from the RAN node 5 to the UE 3 (e.g., such as a DRS and / or an SSB. That offset may be configurable by the RAN node 5, or alternatively, it may be pre-defined (e.g., hard coded). For example, the resources may be allocated such that the UE 3 can send the WUS message to the RAN node 5 nWUSslots after the latest DRS and / or SSB reception by the UE 3. The value of nWUSmay be selected to correspond to the minimum processing time capabilities of the UE 3.

[0238] The RAN node 5 may alternatively, or additionally, configure the resources in the frequency domain such that the resources are offset to the start of an RB of an initial UL BWP, or they may be offset to the start of the frequency domain position of the CORESET associated with the Type 0 Common Search Space Set i.e. the frequency domain position of the CORESET 0 that carries PDCCH / DCI for SIB1. That offset may be configurable by the RAN node 5, or alternatively, it may be pre-defined (e.g., hard coded).

[0239] At step S810, having allocated appropriate resources for the UE 3 to use to send an appropriate WUS message to the RAN node 5 to request on-demand SIB1 transmissions for the non-anchor node, the RAN node 5 may send a configuration message to the UE 3. For example, the RAN node 5 may send an appropriate configuration message to indicate the allocated resources to the UE 3 (e.g., a WUS configuration message indicating the time offset, frequency offset, and / or other configuration information). The WUS configuration message may be sent to the UE 3 by the RAN node 5 via appropriate broadcast signalling (e.g., paging information signalling that sends paging information to the UE 3). Alternatively, the WUS configuration message may be sent to the UE 3 by the RAN node 5 via appropriate RRC messages (e.g., an RRC connection release message, or the like).

[0240] As well as indicating the allocated resources to the UE 3 (i.e., providing an UL grant for the allocated resources), the WUS configuration message may additionally include appropriate information to (re)configure the UL between the RAN node 5 and the UE 3. For example, the WUS configuration message may include an indication of the frequency of the uplink, the subcarrier spacing used, the initial uplink BWP, and the like, which may be contained within an appropriate IE (e.g., uplinkConfigCommon IE). That IE may also include all appropriate information pertaining to a RACH procedure (e.g., RACH-ConfigCommon IE), the PUSCH (e.g., PUSCH-ConfigCommon IE), and the PUCCH (e.g., PUCCH-ConfigCommon) to allow the UE 3 to send a WUS message to the RAN node 5 to request an on-demand SIB1 for the non-anchor node.

[0241] Additionally, the WUS configuration message may also include a carrier indicator or a local cell ID to indicate the carrier over which the WUS message can be sent to the RAN node 5 (i.e., over the anchor cell carrier or the non-anchor cell carrier). Additionally, the WUS configuration message may also include an indication of an initial UL BWP (e.g., a InitialULBWP IE) that may be used by the UE 3 to perform initial access procedures. For example, the initial UL BWP may correspond to a specific part of the total channel bandwidth configured for a cell that is used for the UE 3 when performing initial access procedures.

[0242] At step S812, having received the WUS configuration message, the UE 3 may use the allocated resources indicated in the WUS configuration message to transmit an appropriate WUS message to the RAN node 5 to request on-demand SIB1 transmissions for the non-anchor cell. Additionally, the WUS message sent to the RAN node 5 to request on-demand SIB1 transmissions for the non-anchor cell may also include an indication of the identity of the non-anchor cell for which on-demand SIB1 transmissions are required.

[0243] Having sent the WUS message sent to the RAN node 5 to request on-demand SIB1 transmissions for the non-anchor cell, the UE 3 may perform an appropriate cell reselection procedure or handover procedure to camp on the non-anchor cell.

[0244] At step S814, having received the WUS message including the indication of the identity of the non-anchor cell for which on-demand SIB1 transmissions are required, the RAN node 5 may be configured to apply a time delay before it sends SIB1 transmissions (and optionally a DCI message to indicate to the UE 3 appropriate resources on which to expect to receive the on-demand SIB1s) to allow the UE 3 sufficient time to camp onto the non-anchor cell.

[0245] After that time delay, the RAN node 5 may (optionally) transmit a DCI message (e.g., a DCI format 1_0 message scrambled with SI-RNTI) to indicate to the UE 3 appropriate resources on which to expect to receive the SIB1. For example, the DCI message may indicate that the on-demand SIB1 transmissions are to be transmitted to the UE 3 periodically within a specific SIB1 transmission period (e.g., a period of 160 ms) from a specific start time. The specific start time may, by way of example, correspond to the time immediately following transmission of the DCI format 1_0 message. Alternatively, the specific start time may, by way of example, correspond to the end of a specified time delay window. For example, the transmission start time for the on-demand SIB1s may be delayed until the start of a next SIB1 periodicity (i.e., the start of the next 160 ms period), following the transmission of the DCI format 1_0 that indicates the SIB1 resources.

[0246] Alternatively, or additionally, the DCI message may indicate that the on-demand SIB1 transmissions are to be transmitted to the UE 3 a specific number of times. For example, the DCI format 1_0 may indicate the SIB1 period is 160 ms, and that the SIB1 is to be transmitted to the UE 3 once every 40 ms i.e., the RAN node 5 will transmit the SIB1 to the UE 3 four times in the 160 ms SIB1 period.

[0247] Alternatively, having received the WUS message requesting on-demand SIB1 transmissions for the non-anchor cell, the RAN node 5 may not need to transmit a DCI message (e.g., a DCI format 1_0 message scrambled with SI-RNTI) to indicate to the UE 3 appropriate resources on which to expect to receive the SIB1 if the appropriate resources on which to expect to receive on-demand SIB1s have already been indicated to the UE 3 by an earlier message. In one example, the appropriate resources may be indicated to the UE 3 in the WUS configuration sent at step S810. In another example, the appropriate resources may be indicated to the UE 3 in an appropriate response message (not shown) sent by the RAN node 5 to the UE 3 having received the WUS message to request on-demand SIB1s at step S812. By way of example only, as the UE 3 may perform an appropriate cell reselection procedure or handover procedure to camp on the non-anchor cell, the appropriate resources may be indicated to the UE 3 in a RACH message. For example, the appropriate resources may be indicated to the UE 3 in a 'message 4' ('MSG 4') of a RACH procedure, or alternatively the appropriate resources may be indicated to the UE 3 in a 'message 2' ('MSG 2') of a RACH procedure (such as, by way of example, a RAR message).

[0248] Alternatively, having received the WUS message requesting on-demand SIB1 transmissions for the non-anchor cell, the RAN node 5 may not need to transmit a DCI message even if the appropriate resources on which to expect to receive the SIB1 has not been previously signalled to the UE 3 if a specific time window for the on-demand SIB1 transmissions is pre-configured (hard coded) at the UE 3. For example, the UE 3 may start to monitor for SIB1 transmissions from the RAN node 5 immediately after transmitting the WUS message, and it may expect the on-demand SIB1 transmissions to be transmitted using a legacy periodicity (e.g., 160 ms).

[0249] At step S816, the RAN node 5 transmits on-demand SIB1 to the UE 3 for the non-anchor cell. It will be appreciated that the on-demand SIB1s may be transmitted to the UE 3 over the non-anchor cell if the UE 3 as the UE 3 has camped onto that cell.

[0250] Fig. 9 depicts a simplified sequence diagram illustrating another procedure for on-demand SIB1 transmissions to a UE 3 for a non-anchor cell that may be used in the communication system 1 of Fig. 1.

[0251] As shown in Fig. 9 there is provided a RAN node 5 and a UE 3 deployed in the communication system 1 of Fig. 1. The UE 3 may be camped on a non-anchor cell provided by the RAN node 5 to allow communication with the RAN node 5 ('single cell' scenario). Once camped on the non-anchor cell, the UE 3 may enter RRC IDLE mode or RRC INACTIVE mode. The nature of RRC IDLE mode or RRC INACTIVE mode is previously described with reference to Fig. 3.

[0252] At step S902 the RAN node 5 may transmit system information to the UE 3 such as a MIB. The MIB is transmitted to the UE 3 over the PBCH with a periodicity of 80 ms, and typically contains the information necessary for the UE 3 to receive a subsequent SIB1 transmission.

[0253] For example, the MIB may contain indications of the MSBs of a current SFN (e.g., systemFrameNumber IE), the subcarrier spacing to be used for the SIB1 message (e.g., subCarrierSpacingCommon IE), kSSBthat defines a subcarrier offset between the Common Resource Block grid and the SS / PBCH block, and the like. kSSBmay also be used to indicate whether or not the MIB has an associated CORESET which can be used by the PDCCH when allocating PDSCH resources for SIB1.

[0254] The MIB may also contain a pointer (e.g., controlReseourceSetZero IE) to aspects of standardised look-up tables that define a SS / PBCH block and CORESET multiplexing pattern, the number of resources bellowing to the CORESET, the number of symbols belonging to the CORESET, and the frequency domain offset between the SS / PBCH block and the CORESET. In addition, the MIB may also contain a pointer (e.g., searchSpaceZero sub-IE) to aspects of standardised look-up tables that define the timing offset between the SS / PBCH block and the search space for SIB1, the number of search space sets per slot, and the first symbol belonging to the search space sets. Both the pointer (e.g., controlReseourceSetZero sub-IE) to aspects of standardised look-up tables, and the pointer (e.g., searchSpaceZero IE) to aspects of standardised look-up tables may be contained together in an IE of the MIB (e.g., pdcch-ConfigSIB1 IE).

[0255] In addition, a spare bit in the MIB may be used by the RAN node 5 to indicate to the UE 3 that the SIB1 for a non-anchor cell provided by the RAN node 5 may be provided to the UE 3 on-demand. For example, a new IE (e.g., WUS-SIB1Config IE) comprising of a one-bit indication may be provided in the MIB to indicate to the UE 3 that the SIB1 for a non-anchor cell provided by the RAN node 5 may be provided to the UE 3 on-demand.

[0256] Alternatively, or additionally, kSSBthat defines a subcarrier offset between the Common Resource Block grid and the SS / PBCH block may be adapted to include an indication as to whether SIB1 transmission for a non-anchor cell provided by the RAN node 5 may be provided to the UE 3 on an on-demand basis. By way of example only, the kSSBmay be defined with a new value other than that used in legacy to indicate on-demand SIB1 transmission e.g., where kSSBis 30 for FR1 or kSSBis 14 for FR2, the kSSBcould be defined with the value of 16 * controlResourceSetZero + searchSpaceZerorequest + 'On-demand SIB1' indication.

[0257] Having received the MIB, the UE 3 decodes the MIB, at step S904, and may store the decoded MIB locally at the UE 3 for future use. Having decoded the MIB, the UE 3 may determine, based on the indication included in e.g., WUS-SIB1Config IE, that SIB1 transmissions for a non-anchor cell provided by the RAN node 5 is provided on an on-demand basis. Furthermore, the UE 3 may also determine that on-demand SIB1 transmissions for the non-anchor cell are required.

[0258] At step S906, the UE 3 transmits an appropriate WUS message to the RAN node 5 to request on-demand SIB1 transmissions for the non-anchor cell. The WUS message may be sent to the RAN node 5 at step S906 at a predefined time / frequency location that is preconfigured at the UE 3 and RAN node 5 for the transmission of such WUS messages. For example, the WUS message may be sent via a preconfigured signal such as a PRACH signal (e.g., a preamble / message 1 / 'MSG1') to indicate to the RAN node 5 that on-demand SIB1 transmissions are required.

[0259] For example, a WUS specific RACH occasion may be (pre)configured based on a WUS specific RACH configuration that is to be used for the transmission / reception of PRACH based WUS messages.

[0260] A simplified example of an ASN.1 representation of a possible implementation of a WUS specific RACH occasion IE, in which the WUS specific RACH occasion is set by the content of a WUS specific RACH configuration IE, is provided below by way of Illustration only (only showing relevant parts of the information element): 　　Rach-OccasionWus{ 　　　　Rach-ConfigWus { 　　　　prach-ConfigurationIndex, / / Fixed to e.g. index 0 　　　　Wus-FDM, / / Fixed to 1 　　　　Wus-FrequencyStart, / / Fixed offset 　　　　zeroCorrelationZoneConfig, / / Fixed based on small cell range, e.g. 1 　　　　preambleReceivedTargetPower, / / Fixed value 　　　　preambleTransmax, / / Fixed value 　　　　powerRampingStep, / / Fixed value 　　　　wus-ResponseWindow} / / Fixed window size 　　　　ssb-perRACHOccasion, / / Fixed to 1 　　　　si-RequestPeriod, / / the period between PRACH resources for 'On-demand' 　　　　　　　　 / / requests - e.g. fixed to 10ms 　　　　si-RequestResource / / specific MSG1 resources 　　}

[0261] It will be appreciated that whilst the WUS specific RACH occasion may be predefined based on configuration information (e.g., as illustrated above) stored at the UE 3 (and RAN node 5) the WUS specific RACH occasion may be configured by similar configuration information sent from the RAN node 5 to the UE 3 at an appropriate time.

[0262] It will also be appreciated that where the WUS message is sent via a preconfigured signal such as a PRACH signal (e.g., a preamble / message 1 / 'MSG1'), an initial UL position for the WUS message (or an ARFCN for 'Point A') will also need to be specified to indicate the frequency location. Alternatively, the WUS message may be sent to the RAN node 5 at step S906 at a predefined time / frequency location that is signalled to the UE 3 by the RAN node 5 using appropriate paging information. For example, the RAN node 5 may send paging messages to the UE 3 to indicate to the UE 3 a predefined time / frequency location at which the WUS message can be sent.

[0263] At step S908, having received the WUS message requesting an on-demand SIB1 transmission for the non-anchor cell, the RAN node 5 may (optionally) transmit a DCI message (e.g., a DCI format 1_0 message scrambled with SI-RNTI) to indicate to the UE 3 appropriate resources on which to expect to receive the SIB1. For example, the DCI message may indicate that on-demand SIB1s are to be transmitted to the UE 3 periodically within a specific SIB1 transmission period (e.g., a period of 160 ms) from a specific start time. The specific start time may, by way of example, correspond to the time immediately following transmission of the DCI format 1_0 message. Alternatively, the specific start time may, by way of example, correspond to the end of a specified time delay window. For example, the transmission start time for on-demand SIB1s may be delayed until the start of a next SIB1 periodicity (i.e., the start of the next 160 ms period), following the transmission of the DCI format 1_0 that indicates the SIB1 resources.

[0264] Alternatively, or additionally, the DCI message may indicate that on-demand SIB1s are to be transmitted to the UE 3 a specific number of times. For example, the DCI format 1_0 may indicate the SIB1 period is 160 ms, and that on-demand SIB1s are to be transmitted to the UE 3 once every 40 ms i.e., the RAN node 5 will transmit on-demand SIB1s to the UE 3 four times in the 160 ms SIB1 period.

[0265] Alternatively, having received the WUS message requesting an on-demand SIB1 transmissions for the non-anchor cell, the RAN node 5 may not need to transmit a DCI message if a specific time window in which the on-demand SIB1 transmission will be transmitted is pre-configured (hard coded) at the UE 3. For example, the UE 3 may start to monitor for on-demand SIB1 transmissions from the RAN node 5 immediately after transmitting the WUS message, and it may expect the on-demand SIB1 transmissions to be transmitted using a legacy periodicity (e.g., 160 ms).

[0266] At step S910, the RAN node 5 transmits on-demand SIB1 to the UE 3 for the non-anchor cell. It will be appreciated that the on-demand SIB1s may be transmitted to the UE 3 over the non-anchor cell if the UE 3 is already camped on the non-anchor cell as in this case.

[0267] DTX / DRX 　　In all of the procedures described above with reference to Figs. 2-9, the on-demand SIB1 transmissions may be enabled during an inactive duration of cell DTX / DRX operation only. That is to say on-demand SIB1 transmissions may not be enabled during an active duration of cell DTX / DRX operation. Instead, during such an active duration of cell DTX / DRX operation SIB1 transmissions legacy SIB1 transmissions may be resumed.

[0268] In all of the procedures described above with reference to Figs. 2-9, the on-demand SIB transmissions described refer specifically to SIB1 transmissions. However, it will nevertheless be appreciated that those procedures may apply equally to other SIBs (e.g., SIB2, SIB3, SIB4, etc.). In those scenarios the on-demand SIB2 / 3 / 4 transmissions may be enabled during an inactive duration of cell DTX / DRX operation only. That is to say on-demand SIB2 / 3 / 4 transmissions may not be enabled during an active duration of cell DTX / DRX operation. Instead, during such an active duration of cell DTX / DRX operation SIB2 / 3 / 4 transmissions legacy SIB2 / 3 / 4 transmissions may be resumed.

[0269] In all of the procedures described above with reference to Figs. 2-9, the transmission of the WUS message from the UE 3 may be scheduled to occur during a cell DTX / DRX inactive duration. Nevertheless, it will be appreciated that the RAN node 5 may monitor for the WUS message also during a cell DTX / DRX active duration.

[0270] Beneficially, on-demand SIB1 transmissions may be activated in conjunction with cell DTX, (e.g., only during cell DTX inactive duration), so that the RAN node 5 can go into a deeper sleep during cell DTX inactive duration and allow legacy SIB1 transmissions for quicker initial access for the UE 3 during the cell DTX active duration.

[0271] Devices of the Communication System 　　User Equipment 　　Fig. 10 is a simplified block schematic illustrating the main components of a UE 3 for implementation in the system of Fig. 1.

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

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

[0274] 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 communication via associated uplink channels (e.g., via a PUCCH, RACH, and / or a 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 PDCCH and / or a 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.

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

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

[0277] RAN node 　　Fig. 11 is a simplified block schematic illustrating the main components of a RAN node 5 for implementation in the system of Fig. 1.

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

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

[0280] 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 communications, via associated uplink channels (e.g., via a PUCCH, a RACH, and / or a 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 communications via associated downlink channels (e.g., via a PDCCH and / or a 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 communications (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.

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

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

[0283] 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 enhancements embodied therein.

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

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

[0286] The ON duration may also be referred to as the 'DRX active time', and the OFF duration may also be referred to as a 'sleep period', or a 'DRX inactive time'.

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

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

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

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

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

[0292] Other Modifications / Alternatives 　　It will also be appreciated, for example, that description of features of and actions performed by a RAN node / base station (or eNB or gNB), apply equally to distributed type RAN nodes / base stations as to non-distributed type RAN nodes / base stations.

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

[0294] In the above description the UE and the RAN node 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.

[0295] 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 RAN node 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 RAN node in order to update their functionalities.

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

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

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

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

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

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

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

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

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

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

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

[0307] It will be appreciated that IoT technology can be implemented on any communication devices 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.

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

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

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

[0311] Each of the drawings or figures is merely an example to illustrate one or more example embodiments. Each figure may not be associated with only one particular example embodiment, but may be associated with one or more other example embodiments. As those of ordinary skill in the art will understand, various features or steps described with reference to any one of the figures can be combined with features or steps illustrated in one or more other figures, for example, to produce example embodiments that are not explicitly illustrated or described. Not all of the features or steps illustrated in any one of the figures to describe an example embodiment are necessarily essential, and some features or steps may be omitted. The order of the steps described in any of the figures may be changed as appropriate.

[0312] The whole or part of the example 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: 　　receiving information indicating whether a system information block 1 (SIB1) is transmitted periodically or on-demand. 　　(Supplementary Note 2) 　　The method according to supplementary note 1, wherein 　　the information is included in a master information block (MIB) or a downlink control information (DCI) format 1_0. 　　(Supplementary Note 3) 　　The method according to supplementary note 2, wherein 　　the information includes a parameter k_ssb which has a specific value, included in the MIB. 　　(Supplementary Note 4) 　　The method according to any one of supplementary notes 1 to 3, further comprising: 　　determining whether to transmit a request for the SIB1 transmitted on-demand. 　　(Supplementary Note 5) 　　The method according to supplementary note 4, wherein 　　the request includes an uplink (UL) wake-up-signal (WUS). 　　(Supplementary Note 6) 　　The method according to supplementary note 4 or 5, wherein 　　the request is transmitted during an inactive duration of a cell discontinuous transmission (DTX) / discontinuous reception (DRX). 　　(Supplementary Note 7) 　　The method according to any one of supplementary notes 1 to 6, further comprising: 　　receiving configuration information for an uplink (UL) wake-up-signal (WUS) via at least one of: 　　　　a system information block (SIB) other than a SIB1; 　　　　a radio resource control (RRC) release message; 　　　　a RRC reconfiguration message; 　　　　a dedicated signaling; 　　　　a paging message; 　　　　a downlink control information (DCI) format 1_0; 　　　　a physical downlink shared channel (PDSCH); or 　　　　a master system information (MIB). 　　(Supplementary Note 8) 　　The method according to supplementary note 7, wherein 　　the configuration information includes at least one of: 　　　　an offset to latest downlink (DL) signal reception, 　　　　an offset to a start of frequency domain position of synchronization signal / physical broadcast (PBCH) block (SSB) or a control resource set (CORESET) type 0 common search space set, 　　　　a time window to receive a response to the UL WUS, 　　　　an offset to a start resource block of an initial uplink bandwidth part, 　　　　an absolute radio frequency channel number (FRFCN) for a "Point A", 　　　　a frequency band list, 　　　　a cell identity, 　　　　configuration information for an initial uplink bandwidth part, or 　　　　UplinkConfigCommonSIB information element. 　　(Supplementary Note 9) 　　The method according to supplementary note 7 or 8, further comprising: 　　transmitting a request for the configuration information for the UL WUS, and wherein 　　the receiving the configuration information is performed in response to the transmitting the request for the configuration information. 　　(Supplementary Note 10) 　　The method according to supplementary note 9, wherein 　　the transmitting the request is performed by transmitting the request to an anchor cell, and 　　the UL WUS is for requesting a network energy saving (NES) cell other than the anchor cell to transmit the SIB1 transmitted on-demand. 　　(Supplementary Note 11) 　　The method according to supplementary note 9 or 10, wherein 　　the request for the configuration information for the UL WUS is transmitted in a message 1 (Msg1), and 　　the configuration information for the UL WUS is transmitted in a message 2 (Msg2) or message 4 (msg4). 　　(Supplementary Note 12) 　　The method according to any one of supplementary notes 1 to 11, further comprising: 　　receiving the SIB1 transmitted on-demand in a position indicated by at least one of: 　　　　time domain resource allocation in a message 2 (Msg2), message 4 (Msg4) or message B (MsgB), 　　　　a downlink control information (DCI) format 1_0, 　　　　configuration information for an uplink (UL) wake-up-signal (WUS) for requesting the SIB1 transmitted on-demand, 　　　　a response message to the UL WUS, or 　　　　a master information block (MIB). 　　(Supplementary Note 13) 　　The method according to supplementary note 12, wherein 　　the position is indicated by the MIB in a case where a parameter k_ssb has a specific value. 　　(Supplementary Note 14) 　　The method according to any one of supplementary notes 1 to 13, wherein 　　transmission of the SIB1 transmitted on-demand is during an inactive duration of cell discontinuous transmission (DTX) discontinuous reception (DRX). 　　(Supplementary Note 15) 　　The method according to any one of supplementary notes 1 to 14, wherein 　　the mobile terminal is in a radio resource control (RRC) inactive state or RRC idle state. 　　(Supplementary Note 16) 　　A method performed by an access network node, the method comprising: 　　transmitting information indicating whether a system information block 1 (SIB1) is transmitted periodically or on-demand. 　　(Supplementary Note 17) 　　A mobile device comprising: 　　means for receiving information indicating whether a system information block 1 (SIB1) is transmitted periodically or on-demand. 　　(Supplementary Note 18) 　　An access network node comprising: 　　means for transmitting information indicating whether a system information block 1 (SIB1) is transmitted periodically or on-demand.

[0313] Some or all of elements specified in any of Supplementary Notes may be applied to various types of hardware, software, and recording means for recording software, systems, and methods.

[0314] This application is based upon and claims the benefit of priority from Great Britain patent application No. 2402281.6, filed on February 16, 2024, the disclosure of which is incorporated herein in its entirety by reference.

[0315] 1 Communication System 3 UE 3-1 UE 3-2 UE 3-3 UE 5 RAN node, Base Station 7 Core Network 9 Corresponding Cell 9AnchorAnchor Cell 9Non-anchorNon-anchor Cell 10 Control Plane Function Group 10-1 AMF 10-2 SMF 10-n Other Function 11 UPF 20 External Data Network 31 Transceiver Circuit 33 Antenna 35 User Interface 37 Controller 39 Memory 41 Operating System 43 Communication Control Module 51 Transceiver Circuit 53 Antenna 55 Core Network Interface 57 Controller 59 Memory 61 Operating System 63 Communication Control Module

Claims

1. A method performed by a mobile device, the method comprising: 　　receiving information indicating whether a system information block 1 (SIB1) is transmitted periodically or on-demand.

2. The method according to claim 1, wherein 　　the information is included in a master information block (MIB) or a downlink control information (DCI) format 1_0.

3. The method according to claim 2, wherein 　　the information includes a parameter k_ssb which has a specific value, included in the MIB.

4. The method according to any one of claims 1 to 3, further comprising: 　　determining whether to transmit a request for the SIB1 transmitted on-demand.

5. The method according to claim 4, wherein 　　the request includes an uplink (UL) wake-up-signal (WUS).

6. The method according to claim 4 or 5, wherein 　　the request is transmitted during an inactive duration of a cell discontinuous transmission (DTX) / discontinuous reception (DRX).

7. The method according to any one of claims 1 to 6, further comprising: 　　receiving configuration information for an uplink (UL) wake-up-signal (WUS) via at least one of: 　　　　a system information block (SIB) other than a SIB1; 　　　　a radio resource control (RRC) release message; 　　　　a RRC reconfiguration message; 　　　　a dedicated signaling; 　　　　a paging message; 　　　　a downlink control information (DCI) format 1_0; 　　　　a physical downlink shared channel (PDSCH); or 　　　　a master system information (MIB).

8. The method according to claim 7, wherein 　　the configuration information includes at least one of: 　　　　an offset to latest downlink (DL) signal reception, 　　　　an offset to a start of frequency domain position of synchronization signal / physical broadcast (PBCH) block (SSB) or a control resource set (CORESET) type 0 common search space set, 　　　　a time window to receive a response to the UL WUS, 　　　　an offset to a start resource block of an initial uplink bandwidth part, 　　　　an absolute radio frequency channel number (FRFCN) for a "Point A", 　　　　a frequency band list, 　　　　a cell identity, 　　　　configuration information for an initial uplink bandwidth part, or 　　　　UplinkConfigCommonSIB information element.

9. The method according to claim 7 or 8, further comprising: 　　transmitting a request for the configuration information for the UL WUS, and wherein 　　the receiving the configuration information is performed in response to the transmitting the request for the configuration information.

10. The method according to claim 9, wherein 　　the transmitting the request is performed by transmitting the request to an anchor cell, and 　　the UL WUS is for requesting a network energy saving (NES) cell other than the anchor cell to transmit the SIB1 transmitted on-demand.

11. The method according to claim 9 or 10, wherein 　　the request for the configuration information for the UL WUS is transmitted in a message 1 (Msg1), and 　　the configuration information for the UL WUS is transmitted in a message 2 (Msg2) or message 4 (msg4).

12. The method according to any one of claims 1 to 11, further comprising: 　　receiving the SIB1 transmitted on-demand in a position indicated by at least one of: 　　　　time domain resource allocation in a message 2 (Msg2), message 4 (Msg4) or message B (MsgB), 　　　　a downlink control information (DCI) format 1_0, 　　　　configuration information for an uplink (UL) wake-up-signal (WUS) for requesting the SIB1 transmitted on-demand, 　　　　a response message to the UL WUS, or 　　　　a master information block (MIB).

13. The method according to claim 12, wherein 　　the position is indicated by the MIB in a case where a parameter k_ssb has a specific value.

14. The method according to any one of claims 1 to 13, wherein 　　transmission of the SIB1 transmitted on-demand is during an inactive duration of cell discontinuous transmission (DTX) discontinuous reception (DRX).

15. The method according to any one of claims 1 to 14, wherein 　　the mobile terminal is in a radio resource control (RRC) inactive state or RRC idle state.

16. A method performed by an access network node, the method comprising: 　　transmitting information indicating whether a system information block 1 (SIB1) is transmitted periodically or on-demand.

17. A mobile device comprising: 　　means for receiving information indicating whether a system information block 1 (SIB1) is transmitted periodically or on-demand.

18. An access network node comprising: 　　means for transmitting information indicating whether a system information block 1 (SIB1) is transmitted periodically or on-demand.

Images