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

Abstract

A method performed by a mobile terminal is disclosed. The method includes monitoring a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell transmitted on-demand, during a specific monitoring window; and activating the secondary cell at the mobile terminal based on the SSB for the secondary cell, regardless of receiving information for activating the secondary cell, in a case where the mobile terminal detects the SSB for the secondary cell transmitted on-demand by the monitoring.

Description

METHOD PERFORMED BY MOBILE TERMINAL, METHOD PERFORMED BY ACCESS NETWORK NODE, MOBILE TERMINAL, 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 networks, future generations, and beyond). The present disclosure in particular, but not exclusively, relates to the triggering of on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB) transmission for secondary cells (SCells) and non-serving cells.

[0002] Earlier developments of the 3GPP standards were referred to as the Long-Term Evolution (LTE) of Evolved Packet Core (EPC) network and Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), also commonly referred as '4G'. More recently, the term '5G' and 'new radio' (NR) has started to be used to refer to an evolving communication technology that is expected to support a variety of applications and services. Various details of 5G networks are described in, for example, the 'NGMN 5G White Paper' V1.0 (NPL 1) 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] Under the 3GPP standards, a NodeB (or an eNB in LTE, and gNB in 5G) is the radio access network (RAN) node (or simply 'access node', 'access network node' or 'base station') via which communication devices (user equipments or 'UEs') connect to a core network and communicate with other communication devices or remote servers. For simplicity, the present application will use the term access network node, RAN node or base station to refer to any such access nodes.

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

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

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

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

[0008] 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. 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 (WUS) to allow devices such as UEs to enter reduced transmission / reception modes, (for example discontinuous transmission / reception modes); -　　The use of on-demand SSBs (and possibly other DL signals) for camping onto secondary cells (SCells) by UEs configured to connect to, and use, such SCells; and -　　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.

[0009] In the case of on-demand SSB for camping onto SCells, mechanisms and procedures are in their infancy. There is therefore a need to devise further appropriate mechanisms and procedures to allow for the implementation of on-demand SSBs for UEs to camp onto SCells. The present specification aims to provide apparatus and methods that at least contribute to addressing one or more of the above needs and / or issues.

[0010] In addition, in the case of on-demand for camping onto non-serving cells, mechanisms and procedures on how to measure such cells for inter-cell UE mobility need to be developed. There is therefore a need to devise appropriate mechanisms and procedures to allow for the implementation of on-demand SSBs for UEs to camp onto non-serving 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] NPL 1: NGMN 5G White Paper' V1.0

[0012] In the present disclosure, one or more apparatus and / or one or more associated methods are disclosed that aim to at least partially contribute to implementing one or more of the above mentioned possible enhancements.

[0013] In one aspect there is provided a method performed by a mobile terminal, the method comprising: 　　monitoring a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell transmitted on-demand, during a specific monitoring window; and 　　activating the secondary cell at the mobile terminal based on the SSB for the secondary cell, regardless of receiving information for activating the secondary cell, in a case where the mobile terminal detects the SSB for the secondary cell transmitted on-demand by the monitoring.

[0014] In one aspect there is provided a method performed by an access network node, the method comprising: 　　performing measurements for a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell; 　　receiving information for activating the secondary cell; and 　　activating the secondary cell in a case where the mobile terminal maintains information for the measurements for the SSB for the secondary cell and the mobile terminal synchronizes with the secondary cell, without monitoring the SSB for the secondary cell transmitted on-demand.

[0015] In one aspect there is provided a method performed by an access network node, the method comprising: 　　receiving information for activating a secondary cell; and 　　determining whether to monitor a synchronization signal / physical broadcast channel (PBCH) block (SSB) for another cell which is contiguous to the secondary cell or shares SSB beams with the secondary cell, based on whether the mobile terminal synchronizes with the another cell.

[0016] In one aspect there is provided a method performed by an access network node, the method comprising: 　　transmitting a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell on-demand, during a specific monitoring window of a mobile terminal, wherein 　　the secondary cell is activated by the mobile terminal based on the SSB for the secondary cell, regardless of transmitting information for activating the secondary cell, in a case where the mobile terminal detects the SSB for the secondary cell transmitted on-demand.

[0017] In one aspect there is provided a method performed by an access network node, the method comprising: 　　transmitting a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell, for measurements by a mobile terminal; and 　　transmitting information for activating the secondary cell, wherein 　　the secondary cell is activated by the mobile terminal in a case where the mobile terminal maintains information for the measurements for the SSB for the secondary cell and the mobile terminal synchronizes with the secondary cell, without monitoring, by the mobile terminal, the SSB for the secondary cell transmitted on-demand.

[0018] In one aspect there is provided a mobile terminal comprising: 　　means for monitoring a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell transmitted on-demand, during a specific monitoring window; and 　　means for activating the secondary cell at the mobile terminal based on the SSB for the secondary cell, regardless of receiving information for activating the secondary cell, in a case where the mobile terminal detects the SSB for the secondary cell transmitted on-demand by the monitoring.

[0019] In one aspect there is provided a mobile terminal comprising: 　　means for performing measurements for a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell; and 　　means for receiving information for activating the secondary cell; and 　　means for activating the secondary cell in a case where the mobile terminal maintains information for the measurements for the SSB for the secondary cell and the mobile terminal synchronizes with the secondary cell, without monitoring the SSB for the secondary cell transmitted on-demand.

[0020] In one aspect there is provided a mobile terminal comprising: 　　means for receiving information for activating a secondary cell; and 　　means for determining whether to monitor a synchronization signal / physical broadcast channel (PBCH) block (SSB) for another cell which is contiguous to the secondary cell or shares SSB beams with the secondary cell, based on whether the mobile terminal synchronizes with the another cell.

[0021] In one aspect there is provided an access network node comprising: 　　means for transmitting a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell on-demand, during a specific monitoring window of a mobile terminal, wherein 　　the secondary cell is activated by the mobile terminal based on the SSB for the secondary cell, regardless of transmitting information for activating the secondary cell, in a case where the mobile terminal detects the SSB for the secondary cell transmitted on-demand.

[0022] In one aspect there is provided an access network node comprising: 　　means for transmitting a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell, for measurements by a mobile terminal; and 　　means for transmitting information for activating the secondary cell, wherein 　　the secondary cell is activated by the mobile terminal in a case where the mobile terminal maintains information for the measurements for the SSB for the secondary cell and the mobile terminal synchronizes with the secondary cell, without monitoring, by the mobile terminal, the SSB for the secondary cell transmitted on-demand.

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

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

[0025] According to the present disclosure, it is possible to provide a method performed by a mobile terminal, a method performed by an access network node, a mobile terminal, and an access network node.

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

[0027] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system;Fig. 2 depicts a simplified sequence diagram illustrating a procedure for on-demand SCell SSB transmission that may be used in the communication system of Fig. 1;Fig. 3 depicts a simplified timing diagram illustrating the procedure illustrated in Fig. 2;Fig. 4 depicts a simplified sequence diagram illustrating another procedure for on-demand SCell SSB transmission that may be used in the communication system of Fig. 1;Fig. 5 depicts a simplified timing diagram illustrating the procedure illustrated in Fig. 4;Fig. 6 depicts a simplified sequence diagram illustrating another procedure for on-demand SCell SSB transmission that may be used in the communication system of Fig. 1;Fig. 7 depicts a simplified timing diagram illustrating the procedure illustrated in Fig. 6;Fig. 8 depicts a simplified sequence diagram illustrating another procedure for on-demand SCell SSB transmission that may be used in the communication system of Fig. 1;Fig. 9 depicts a simplified timing diagram illustrating the procedure illustrated in Fig. 8;Fig. 10 depicts a simplified sequence diagram illustrating a procedure for on-demand SSB transmission for RRM measurements that may be used in the communication system of Fig. 1;Fig. 11 depicts a simplified sequence diagram illustrating another procedure for on-demand SSB transmission for RRM measurements that may be used in the communication system of Fig. 1;Fig. 12 depicts a simplified sequence diagram illustrating another procedure for on-demand SSB transmission for RRM measurements that may be used in the communication system of Fig. 1;Fig. 13 depicts a simplified sequence diagram illustrating another procedure for on-demand SSB transmission for RRM measurements that may be used in the communication system of Fig. 1;Fig. 14 is a simplified block schematic illustrating the main components of a UE for implementation in the system of Fig. 1; andFig. 15 is a simplified block schematic illustrating the main components of a RAN node for implementation in the system of Fig. 1.

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

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

[0030] In the communication system 1, user equipments (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 evolved packet core network (EPC)).

[0031] 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 one or more other RAN nodes 5 and UEs 3.

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

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

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

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

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

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

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

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

[0040] 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 downlink (DL) physical channels and for transmission of a number of physical signals. The DL physical channels correspond to resource elements (REs) carrying information originated from a higher layer, and the DL physical signals are used in the physical layer and correspond to REs which do not carry information originated from a higher layer.

[0041] The DL physical channels may include, for example, a physical downlink shared channel (PDSCH), a physical broadcast channel (PBCH), and a physical downlink control channel (PDCCH). The PDSCH carries data sharing the PDSCH's capacity on a time and frequency basis. The PDSCH can carry a variety of items of data including, for example, user data, UE-specific higher layer control messages mapped down from higher channels, system information blocks (SIBs), and paging. The PDCCH carries downlink control information (DCI) for supporting a number of functions including, for example, scheduling the downlink transmission on the PDSCH and also the uplink data transmission on a physical uplink shared channel (PUSCH). The PBCH provides the UEs 3 with the Master Information Block (MIB). It also, in conjunction with the PDCCH, supports the synchronisation of time and frequency, which aids cell acquisition, selection and re-selection.

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

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

[0044] The RAN node 5 is also configured to transmit synchronisation signal / physical broadcast channel (PBCH) blocks (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 system information block 1 (SIB1) which carries other minimum system information).

[0045] 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 and form the SSB (also referred to as a SS / PBCH block). The PSS is a part of the SSB that aids in initial cell detection and synchronization. It provides coarse timing and frequency synchronization for UEs 3. The PSS consists of a predefined sequence of complex-valued symbols transmitted over a specific frequency range. The SSS is another component of the SSB that provides additional information for fine-grained synchronization and cell identification. It carries the cell identity group and provides the necessary information to determine the exact physical cell ID (PCI) of the serving cell 9 (e.g., a unique identifier assigned to each cell 9) within the network that helps UEs 3 differentiate between neighbouring cells and synchronize with the correct cell.

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

[0047] Each UE 3 is configured to search for SSBs when scanning for a primary cell (PCell) 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 the RAN node 5.

[0048] Each UE 3 may also be configured to search for SSBs associated with SCells when scanning for SCells to camp on and to decode the associated PBCH before proceeding to decode other system information transmitted on the PDSCH, rather than rely on SSBs associated with the PCell. Given that SCells are not typically used by the UEs 3 all the time, each UE 3 may be configured to perform on-demand SSB searching to search for SSBs associated with SCells only when the UE 3 (or network) decides that it wishes to utilise one or more SCells.

[0049] Beneficially, for such on-demand SSB searching for SSBs associated with SCells (especially, but not exclusively for those SCells that operate in a different frequency band from the PCell), the communication system 1 implements one or more mechanisms / procedures to allow the UE 3 to request, or a network device to trigger, on-demand SSBs for SCells. It will be appreciated that there are several possible mechanisms that may be implemented to allow the UE 3 to request, or a network device to trigger, on-demand SSBs for SCells. On-demand SSBs may, for example, be triggered due to a number of reasons including, for example, SCell activation, or due to a need for SSB-based RRM measurements (e.g., in respect of a particular SCell).

[0050] Whether on-demand SSB is initiated by the network (e.g., the RAN node 5) or triggered based on the UE request depends on the specific use case.

[0051] For example, on-demand SSB transmission for an SCell may be triggerable by the RAN node 5. In such a scenario, the RAN node 5 may trigger on-demand SSB transmission for an SCell based on the RAN node 5 deciding to activate the SCell in question. Alternatively, or additionally, the RAN node 5 may trigger on-demand SSB transmission for an SCell based on the RAN node 5 deciding specific radio resources management (RRM) measurements, or the like need to be performed (for example, RRM measurements for an SCell provided by the RAN node 5, or alternatively, RRM measurements for an SCell provided by a neighbouring RAN node 5). Having decided to trigger on-demand SSB transmission for an SCell the RAN node 5 may indicate that decision to the UE 3 via appropriate messaging, and the RAN node 5 may subsequently send one or more SSB transmission to the UE 3.

[0052] Beneficially, by the RAN node 5 triggering on-demand SSB transmission for an SCell based on certain conditions being met at the RAN node 5 (e.g., an SCell is being activated or RRM measurements are to be performed), network energy savings (NES) can be achieved, as the RAN node 5 does not need to continuously perform SCell SSB transmission. Instead, the UE 3 may be triggered to monitor for on-demand SSBs only after the RAN node 5 has decided that on-demand SSBs are required, and that requirement has been appropriately signalled to the UE 3. Further beneficially, the overall signalling overhead of the system is reduced, as SSBs associated with SCells are only transmitted when deemed necessary by the RAN node 5, rather than them being sent on a periodic basis.

[0053] Each of the on-demand SSB transmission scenarios outlined above will now be discussed in more detail with reference to Figs. 2 to 13.

[0054] It will be appreciated that the various different mechanisms / procedures described are not mutually exclusive and all, or a subset of one or more, of the mechanisms / procedures may be implemented in the same communication system. For example, the various devices involved may be configured to use different mechanisms / procedures in different scenarios as appropriate.

[0055] < On-demand SCell SSB procedures for Serving Cells > 　　Fig. 2 depicts a simplified sequence diagram illustrating a procedure for on-demand SCell SSB transmission to the UE 3 triggered by the RAN node 5 that may be used in the communication system 1 of Fig. 1.

[0056] As shown in Fig. 2 there is provided the RAN node 5 and the UE 3 deployed in the communication system 1 of Fig. 1.

[0057] At step S202, the RAN node 5 sends an indication to the UE 3 indicating whether on-demand SSB transmission for one or more SCells is enabled. Specifically, for each SCell, the RAN node 5 may indicate whether SSBs are to be transmitted: i) on-demand based on a network trigger (i.e., a trigger at the RAN node 5), and / or ii) on-demand based on the RAN node 5 receiving requests for on-demand SSBs from the UE 3.

[0058] The RAN node 5 may indicate to the UE 3 that transmission of on-demand SSBs for one or more SCells is enabled, and the basis on which SSBs will be transmitted (e.g., based on a network trigger or a request from the UE 3) within an appropriate serving cell configuration message, e.g., a configuration message sent to configure the UE 3 to camp onto a serving cell of the RAN node 5, where a serving cell in carrier aggregation (CA) may consist of one primary cell (PCell) and several secondary cells (SCells). The indication may be sent within an SSB configuration of the serving cell e.g., in an SSB configuration in a ServingCellConfigCommon information element (IE) provided in a SIB1 message, or the like.

[0059] As way of example only, the ServingCellConfigCommon IE may include the periodicity of the SSB transmission (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 ServingCellConfigCommon IE may also provide the UE 3 with an indication of which SSBs within a 5 ms duration are transmitted (e.g., using ssb-PositionsInBurst). The UE 3 may also be provided with an indication of an absolute transmit power value of the SSS (e.g., using ss-PBCH-BlockPower) which may range from -60 to 50 dBm. Furthermore, the UE 3 may also be provided with an indication of the subcarrier spacing (SCS) used for the SSB (e.g., using ssbSubcarrierSpacing). It will be appreciated that all indications to the UE 3 about the SSB may be indicated to the UE 3 via any appropriate IE (e.g., ServingCellConfigCommon provided in a SIB1 message, or any other appropriate dedicated message).

[0060] The SSB configuration in the ServingCellConfigCommon IE may also indicate additional appropriate information needed to facilitate on-demand SSB transmission occasions for SCells. For example, it may include an indication to the UE 3 that transmission of on-demand SSBs for one or more SCells is enabled, and the basis on which they will be transmitted (e.g., based on a network trigger or a request from the UE 3). The configuration may also include information on the periodicity of such on-demand SSB transmission, and / or how long on-demand SSB transmission should be performed once they have begun. By way of example only, the SSB configuration for on-demand SSBs may indicate an absolute time limit (e.g., 100 ms) for the duration of on-demand SSB transmission, or alternatively it may indicate a count of SSB periods (e.g., 5 periods of SSB transmission) for the duration of on-demand SSB transmission.

[0061] Sometime later at step S203, on-demand SSB transmission for one or more SCells is triggered at the RAN node 5. The trigger may occur, for example, when the RAN node 5 decides to activate one or more SCells for use with the UE 3. For example, the RAN node 5 may decide to activate an SCell for use with the UE 3 when the communication link between the RAN node 5 and the UE 3 is experiencing high levels of data transmission congestion, or where additional bandwidth capacity would be beneficial. Additionally, or alternatively, the RAN node 5 may decide to activate a specific SCell for use with the UE 3 when specific services are required that are only supported by a specific SCell.

[0062] When on-demand SSB transmission for one or more SCells has been triggered, the RAN node 5 transmits, at step S204, an SCell activation command for the one or more SCells to the UE 3. The SCell activation command may be included in any appropriate command message to be sent by the RAN node 5 to the UE 3, which may be sent from the RAN node 5 to the UE 3 via a dedicated medium access control (MAC) control element (CE) on the PDSCH.

[0063] By way of example only, the SCell activation command may be sent to the UE 3 in a new MAC CE transmitted from the RAN node 5 to the UE 3 via communication paths at the MAC layer. Such MAC CEs are typically implemented as special bit strings within the logical channel identifier (LCID) field of the MAC header of the MAC protocol data unit (PDU). Having received the MAC CE comprising the SCell activation command, the UE 3 may (not shown) acknowledge receipt of the MAC CE to the RAN node 5 via a hybrid automatic repeat request (HARQ) acknowledgement / negative acknowledgement (ACK / NACK) procedure associated with the MAC CE transmission.

[0064] The SCell activation command may also include other appropriate information. For example, the SCell activation command may include an indication of a number of SSBs that are to be transmitted by the RAN node 5. For example, where N SSBs are to be sent by the RAN node 5, the message may include an indication in the form of a bit mask, wherein each bit is associated with an index of a corresponding one of the N SSBs. Nevertheless, it will be appreciated that the indication that N SSBs will be sent by the RAN node 5 may be sent in other ways, for example, in the form of an index that can be mapped to a mapping table configured to the UE 3 previously during an RRC configuration procedure. In this scenario, each entry in the mapping table may indicate a set of SSBs that the UE 3 should expect to receive from the RAN node 5.

[0065] The SCell activation command may also include timing information pertaining to the SSB transmission where appropriate. For example, the message may include an indication of a starting time occasion where SSB transmission will start. Additionally, or alternatively, it may also include an indication of a periodicity of SSB transmission. Additionally, or alternatively, it may also include an indication of how long SSB transmission will continue. Additionally, or alternatively, it may also include an indication as to whether SSB transmission is to be aperiodic or semi-persistent.

[0066] The SCell activation command may also include an indication of the identity or identities of the SCell or SCells for which on-demand SSB is enabled. For example, the identity of the SCells may be explicitly indicated or alternatively, the indication may be implicit. In the case of implicit indication, the UE 3 may imply which serving cell the SSBs are to be transmitted over by the RAN node 5 based on the serving cells for which the UE 3 has received the on-demand SSB configuration. For example, if the UE 3 receives the on-demand SSB configuration for a serving cell 'X', then the UE 3 may assume that the SSBs will be sent to the UE 3 for serving cell 'X' when SCell activation command is received for serving cell 'X'.

[0067] It will be appreciated that, like the indication of the number of SSBs that will be sent, all the indications discussed here may be indicated in the MAC CE message explicitly or implicitly. For example, dedicated indication fields may be provided in the message, or alternatively, an index value may be provided in the message that maps to a mapping table that contains entries that specify SSB start time, SSB periodicity, SSB transmission duration, and the like. In this scenario the mapping table is configured to the UE 3 previously during an RRC configuration procedure.

[0068] At step S206, having received the SCell activation command at step S204, the UE 3 is triggered to monitor for SCell SSB transmission for the SCell (or SCells) indicated in the SCell activation command. For example, the UE 3 may be triggered to monitor for SCell SSB transmission for a specific duration (e.g., in a specific monitoring window).

[0069] In one example, the size of that specific duration / monitoring window may be indicated to the UE 3 in the SCell activation command. For example, the SCell activation command may indicate a time for the SCell activation, and the UE 3 may try to receive one or more SSBs for that SCell before the indicated time for the SCell activation. Alternatively, the SCell activation command may explicitly indicate a time duration for which the UE 3 should monitor for SSBs. In another example, the size of that specific duration / monitoring window may be indicated to the UE 3 within an RRC configuration message.

[0070] At step S208, the RAN node 5 transmits SCell SSB transmission to the UE 3. Those SSB transmission may be aperiodic transmission or semi-persistent transmission. In response to receiving those SCell SSB transmission, the UE 3 may optionally send, at step S209, an appropriate feedback message (e.g., HARQ ACK / NACK message) to the RAN node 5 to confirm successful reception of the SCell SSB transmission.

[0071] Having successfully received the SCell SSB transmission (and optionally having successfully transmitted appropriate feedback message to the RAN node 5), the UE 3 may consider the SCell as activated (S210) and start normal SCell operation (e.g. PDCCH monitoring, SRS transmission, and the like).

[0072] It will be appreciated that the UE 3 may consider the SCell as activated only after it has received a specific number of SCell SSB transmission. For example, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on whether the UE 3 has performed any prior measurements of the SCell. Alternatively, or additionally, the number of SCell SSB transmission required may be based on a number of receive (Rx) beams present at the UE 3.

[0073] Alternatively, the number of SCell SSB transmission required may be configured by the network. For example, the network may determine, and indicate the number of SCell SSB transmission required for the UE 3 to consider the SCell activated in any appropriate message to the UE 3. By way of example only, the network may indicate the number in an on-demand SSB configuration sent by the RAN node 5 to the UE 3 (e.g., at step S202). Alternatively (or additionally) the network may indicate the number in an RRC connection procedure.

[0074] If the UE 3 does not successfully receive the SCell SSB transmission within the monitoring window, or the UE 3 fails to detect SCell SSB transmission within the monitoring window, the UE 3 may indicate to the RAN node 5 that it has failed to successfully receive / detect SCell SSB transmission despite having received an SCell activation command from the RAN node 5.

[0075] In one example, the UE 3 may send an appropriate feedback message (e.g., HARQ NACK message) to the RAN node 5 to indicate that it has failed to successfully receive / detect SCell SSB transmission despite having received an SCell activation command from the RAN node 5. In another example, the UE 3 may indicate that failure to successfully receive / detect SCell SSB transmission using a special 'On-demand SSB Failure' indication sent to the RAN node 5 by the UE 3 via appropriate RRC signalling. The appropriate signalling may be sent to the RAN node 5 over the PCell that the RAN node 5 and the UE 3 are currently communicating over.

[0076] In yet another example, the UE 3 may indicate its failure to acquire the on-demand SSBs via uplink control information (UCI) or a MAC CE transmitted to the RAN node 5 over the PCell that the RAN node 5 and the UE 3 are currently communicating over. In yet another example, the UE 3 may indicate its failure to successfully receive / detect SCell SSB transmission by transmitting an appropriate (re-)request message for on-demand SCell SSB transmission to the RAN node 5 to request that the RAN node 5 re-send the SCell SSB transmission. Alternatively, rather than transmitting an appropriate (re-)request message, the UE 3 may (re-)request on-demand SCell SSB transmission using appropriate wake-up signals (e.g., via PRACH signalling or sounding reference resources).

[0077] After the UE 3 has indicated its failure to successfully receive / detect SCell SSB transmission, the RAN node 5 may repeat the on-demand SCell SSB transmission. After repeating the on-demand SSBs transmission, if the UE 3 still is not able to detect the SSBs sent by the RAN node 5, the UE 3 may repeat the request procedure described above a (pre)configured number (e.g., 'N') times before triggering a failure event. The value of N may be configured by the network and signalled to the UE 3 over any appropriate signalling (e.g., an RRC message). Alternatively, it may be pre-defined (e.g., hard coded in the UE 3). It will also be appreciated that the value of N may also be set to zero to indicate that the UE 3 only transmits one on-demand-SSB request before triggering a failure event. If the UE 3 triggers the failure event, then the UE 3 may indicate that failure using the 'On-demand SSB Failure' indication described above. In another example, the UE 3 may indicate its failure to acquire the on-demand SSBs via UCI or a MAC CE transmitted to the RAN node 5 over the PCell that the RAN node 5 and the UE 3 are currently communicating over.

[0078] In the procedure for on-demand SCell SSB transmission described above, having received the SCell activation command at step S204, the UE 3 begins to monitor for SCell SSB transmission from the RAN node 5 for activation of the SCell indicated in the SCell activation command. However, it will nevertheless be appreciated that in certain scenarios the UE 3 may not need to monitor for the SCell SSB transmission prior to activation of the SCell. For example, the UE 3 may not need to detect / receive SSBs upon SCell activation when the UE 3 has recently performed SSB measurements for the given SCell. For example, the UE 3 may have recently performed SSB measurements for RRM purposes and / or time / frequency synchronisation purposes. In such cases, if the UE 3 has maintained synchronisation with the SCell since it performed those SSB measurements, the UE 3 may use those SSB measurements for SCell activation and may not need to monitor for more SSB transmission. If the UE 3 is able to use those SSB measurements then the UE 3 may, upon receipt of the SCell activation command at step S204, directly activate the SCell without performing on-demand SSB measurements. Whether the UE 3 has maintained synchronisation with the SCell since it performed SSB measurements may be determined by the UE 3 periodically, or upon receipt of the SCell activation command at step S204.

[0079] Alternatively, the UE 3 may be pre-configured (e.g., hardcoded) to not perform SSB measurements if the UE 3 performed the SSB measurements for RRM purposes and / or the time / frequency synchronisation purposes a threshold time / duration ago.

[0080] Fig. 3 depicts a simplified timing diagram illustrating the procedure illustrated in Fig. 2 used by the UE 3 for determining when to trigger monitoring for on-demand SCell SSB transmission.

[0081] As shown in Fig. 3, after receiving a SSB configuration for on-demand SCell SSBs as described above with reference to step S202, the UE 3 may communicate (transmit / receive) in its PCell as normal during some arbitrary period. During that arbitrary period the UE 3 does not monitor for SCell SSB transmission. At some later time, the UE 3 may receive an SCell activation command. The SCell activation command may be included in any appropriate command message to be sent by the RAN node 5 to the UE 3 as described above with reference to step S204.

[0082] Having received the SCell activation command, the UE 3 may be triggered to monitor for SCell SSB transmission for a period of time (e.g., in a specific monitoring window) as described above with reference to step S206. During that monitoring window, the RAN node 5 transmits SCell SSBs to the UE 3. Having successfully received the SCell SSB transmission, the UE 3 may consider the SCell activated and start normal SCell operations (e.g. PDCCH monitoring, SRS transmission, and the like).

[0083] As previously described, it will be appreciated that the UE 3 may consider the SCell activated only after it has received a specific number of SCell SSB transmission. For example, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on whether the UE 3 has performed a prior measurement of the SCell. Alternatively, or additionally, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on a number of receive (Rx) beams present at the UE 3.

[0084] Alternatively, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be configured by the network. For example, the network may determine, and indicate the number of SCell SSB transmission required for the UE 3 to consider the SCell activated in any appropriate message to the UE 3. By way of example only, the network may indicate the number in an on-demand SSB configuration sent by the RAN node 5 to the UE 3. Alternatively (or additionally) the network may indicate the number in an SSB configuration sent by the RAN node 5 to the UE 3.

[0085] It will be appreciated where the UE 3 considers the SCell activated based on having received a specific number of SCell SSB transmission, the UE 3 may consider the SCell activated at some point during the monitoring window providing the specific number of SCell SSB transmission have been received i.e., before the monitoring window expires.

[0086] Following expiration of the monitoring window, the UE 3 may stop monitoring for SCell SSB transmission. Accordingly, the UE 3 may be configured such that it assumes that SCell SSBs are only transmitted in the monitoring window (i.e., not periodically transmitted) and hence the UE 3 does not need to monitor for SCell SSBs all the time.

[0087] It will be appreciated that where the UE 3 is configured such that it assumes that SCell SSBs are only transmitted in the monitoring window, the UE 3 may nevertheless also be configured to explicitly request SCell SSB transmission for procedures that require SSB measurement / detection (e.g., TA expiry or when the UE 3 loses time / frequency synchronization).

[0088] Fig. 4 depicts a simplified sequence diagram illustrating another procedure for on-demand SCell SSB transmission to the UE 3 triggered by the RAN node 5 that may be used in the communication system 1 of Fig. 1.

[0089] As shown in Fig. 4 there is provided the RAN node 5 and the UE 3 deployed in the communication system 1 of Fig. 1.

[0090] At step S402, the RAN node 5 sends an indication to the UE 3 indicating whether on-demand SSB transmission for one or more SCells is enabled. Specifically, for each SCell, the RAN node 5 may indicate whether SSBs are to be transmitted: i) on-demand based on a network trigger (i.e., a trigger at the RAN node 5), and / or ii) on-demand based on the RAN node 5 receiving requests for on-demand SSBs from the UE 3.

[0091] The RAN node 5 may indicate to the UE 3 that transmission of on-demand SSBs for one or more SCells is enabled, and the basis on which SSBs will be transmitted (e.g., based on a network trigger or a request from the UE 3) within an appropriate serving cell configuration message e.g., a configuration message sent to configure the UE 3 to camp onto a serving cell 9 of the RAN node 5, where a serving cell 9 in CA may consist of one PCell and several SCells. The indication may be sent within an SSB configuration of the serving cell 9 e.g., in an SSB configuration in a ServingCellConfigCommon IE provided in a SIB1 message, or the like.

[0092] As way of example only, the ServingCellConfigCommon IE may include the periodicity of the SSB transmission (e.g., per serving cell 9 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 ServingCellConfigCommon IE may also provide the UE 3 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 IE (e.g., ServingCellConfigCommon provided in a SIB1 message, or any other appropriate dedicated message).

[0093] The SSB configuration in the ServingCellConfigCommon IE may also indicate additional appropriate information needed to facilitate on-demand SSB transmission occasions for SCells. For example, it may include an indication to the UE 3 that transmission of on-demand SSBs for one or more SCells is enabled, and the basis on which they will be transmitted (e.g., based on a network trigger or a request from the UE 3). The configuration may also include information on the periodicity of such on-demand SSB transmission, and / or how long on-demand SSB transmission should be performed for once they have begun. By way of example only, the SSB configuration for on-demand SSBs may indicate an absolute time limit (e.g., 100 ms) for the duration of on-demand SSB transmission, or alternatively it may indicate a count of SSB periods (e.g., 5 periods of SSB transmission) for the duration of on-demand SSB transmission.

[0094] Sometime later at step S403, on-demand SSB transmission for one or more SCells is triggered at the RAN node 5. The trigger may occur, for example, when the RAN node 5 decides to activate one or more SCells for use with the UE 3. For example, RAN node 5 may decide to activate an SCell for use with the UE 3 when the communication link between the RAN node 5 and the UE 3 is experiencing high levels of data transmission congestion, or where additional bandwidth capacity would be beneficial. Additionally, or alternatively, the RAN node 5 may decide to activate a specific SCell for use with the UE 3 when specific services are required that are only supported by a specific SCell.

[0095] When on-demand SSB transmission for one or more SCells have been triggered, the RAN node 5 transmits, at step S404a, an SCell activation command for the one or more SCells to the UE 3. The SCell activation command may be included in any appropriate command message to be sent by the RAN node 5 to the UE 3, which may be sent from the RAN node 5 to the UE 3 via a dedicated MAC CE on the PDSCH.

[0096] By way of example only, the SCell activation command may be sent to the UE 3 in a new MAC CE transmitted from the RAN node 5 to the UE 3 via communication paths at the MAC layer. Such MAC CEs are typically implemented as special bit strings within the LCID field of the MAC header of the MAC PDU. Having received the MAC CE comprising the SCell activation command, the UE 3 may (not shown) acknowledge receipt of the MAC CE to the RAN node 5 via a HARQ ACK / NACK procedure associated with the MAC CE transmission.

[0097] The SCell activation command may also include other appropriate information. For example, the SCell activation command may include an indication of a number of SSBs that are to be transmitted by the RAN node 5. For example, where N SSBs are to be sent by the RAN node 5, the message may include an indication that N SSBs will be sent by the RAN node 5. The indication that N SSBs will be sent by the RAN node 5 may, by way of example, be in the form of a bit mask wherein each bit is associated with an index of a corresponding one of the N SSBs. Nevertheless, it will be appreciated that the indication that N SSBs will be sent by the RAN node 5 may be sent in other ways, for example, in the form of an index that can be mapped to a mapping table configured to the UE 3 previously during an RRC configuration procedure. In this scenario, each entry in the mapping table may indicate a set of SSBs that the UE 3 should expect to receive from the RAN node 5.

[0098] The SCell activation command may also include timing information pertaining to the SSB transmission where appropriate. For example, the message may include an indication of a starting time occasion where SSB transmission will start. Additionally, or alternatively, it may also include an indication of a periodicity of SSB transmission. Additionally, or alternatively, it may also include an indication of how long SSB transmission will continue. Additionally, or alternatively, it may also include an indication as to whether SSB transmission is to be aperiodic or semi-persistent.

[0099] The SCell activation command may also include an indication of the identity or identities of the SCell or SCells for which on-demand SSB is enabled. For example, the identity of the SCells may be explicitly indicated or alternatively, the indication may be implicit. In the case of implicit indication, the UE 3 may imply which serving cell the SSBs are to be transmitted over by the RAN node 5 based on the serving cells for which the UE 3 has received the on-demand SSB configuration. For example, if the UE 3 receives the on-demand SSB configuration for serving cell 'X', then the UE 3 may assume that the SSBs will be sent to the UE 3 for serving cell 'X' when UE 3 receives the activation command for serving cell 'X'.

[0100] It will be appreciated that, like the indication of the number of SSBs that will be sent, all the indications discussed here may be indicated in the MAC CE message explicitly or implicitly. For example, dedicated indication fields may be provided in the message, or alternatively, an index value may be provided in the message that maps to a mapping table that contains entries that specify SSB start time, SSB periodicity, SSB transmission duration, and the like. In this scenario the mapping table is configured to the UE 3 previously during an RRC configuration procedure.

[0101] When the SCell activation command is transmitted to the UE 3 (or shortly thereafter), the RAN node 5 may also transmit, to the UE 3, an indication for on-demand SSBs for the SCells (e.g., the SCells indicated in the SCell activation command) at step S404b. The indication for on-demand SSBs for the SCell may consist of any appropriate type of indication or message that is able to convey to the UE 3 that the RAN node 5 will initiate on-demand SSB transmission for the SCell. It will nevertheless be appreciated that such an indication may only be included where on-demand SSBs for the SCell or SCells being activated is supported.

[0102] The RAN node 5 may transmit the indication for on-demand SSB for the SCell to the UE 3 (S404b) in a MAC CE or a DCI. In one example, the RAN node 5 may transmit the indication for on-demand SSB for the SCell to the UE 3 in a separate new MAC CE, or alternatively in the MAC CE used for the SCell activation command. Where a new MAC CE is used it may typically be implemented as special bit strings within the LCID field of the MAC header of the MAC PDU. Alternatively, where the indication is included in the MAC CE used for the SCell activation command the indication may be included in the MAC CE by adding one or more octets to the MAC CE corresponding to the SCell or SCells being activated by the SCell activation command.

[0103] In either scenario, it will be appreciated that when the SCell activation command is sent to activate multiple SCells, if those multiple SCells are able to share a single set of SSB transmission then the indication may include appropriate information to indicate to the UE 3 that the multiple SCells to be activated can share a single set of SSB transmission. For example, the indication may include an explicit indication that the multiple SCells to be activated can share a single set of SSB transmission. Alternatively, where the SCell activation command is sent to activate multiple SCells and the indication for on-demand SSB for the SCells only includes information pertaining to a single SCell, the UE 3 may infer that the multiple SCells to be activated can share a single set of SSB transmission.

[0104] In either scenario, having received the MAC CE comprising the indication for on-demand SSB for the SCell, the UE 3 may (not shown) acknowledge receipt of the MAC CE to the RAN node 5 via a HARQ ACK / NACK procedure associated with the MAC CE transmission.

[0105] In another example, the indication for on-demand SSB for the SCell may be sent to the UE 3 in a new downlink control information (DCI) message sent on the PDCCH. For example, an appropriate new DCI message may be provided that has a different format to previous DCI formats. The DCI may be a common group DCI that is configured to be received by multiple UEs 3, or alternatively it may be a dedicated DCI message that is configured for reception by a specific UE 3. The UE 3 may monitor for such a new DCI message in several possible ways. For example, the UE 3 may always monitor for the new DCI message when the UE 3 receives an activation command for an SCell for which an on-demand SSB configuration is provided. Alternatively, the UE 3 may monitor for the new DCI message if a configuration to receive the given DCI is available to the UE 3 and an on-demand SSB configuration is provided for at least one of the SCells configured to the UE 3. Alternatively, the UE 3 may always monitor for the new DCI message regardless of whether an SCell is activated or deactivated (i.e., at all times).

[0106] In the scenario where the indication for on-demand SSB for the SCell is sent to the UE 3 in the new DCI message sent on the PDCCH, the new DCI message may be transmitted between the RAN node 5 and the UE 3 via a primary cell currently being used for communication between the RAN node 5 and the UE 3 (e.g., over a PCell or PSCell only). Nevertheless, it will be appreciated that the DCI message may be transmitted over any appropriate cell capable of supporting communication between the RAN node 5 and the UE 3.

[0107] Whether the indication is sent in a MAC CE, or a DCI based message, it may also include other appropriate information. For example, when not included in the SSB configuration, the indication sent in a MAC CE, or a DCI based message may include an indication of a number of SSBs that are to be transmitted by the RAN node 5, for example where N SSBs are to be sent by the RAN node 5, the message may include an indication that N SSBs will be sent by the RAN node 5. The indication that N SSBs will be sent by the RAN node 5 may, by way of example, be in the form of a bit mask wherein each bit is associated with an index of a corresponding one of the N SSBs. Nevertheless, it will be appreciated that the indication that N SSBs will be sent by the RAN node 5 may be sent in other ways, for example, in the form of an index that can be mapped to a mapping table configured to the UE 3 previously during an RRC configuration procedure. In this scenario, each entry in the mapping table may indicate a set of SSBs that the UE 3 should expect to receive from the RAN node 5.

[0108] Whether the indication is sent in a MAC CE, or a DCI based message, when not included in the SSB configuration, the indication sent in a MAC CE, or a DCI based message may also include timing information pertaining to the SSB transmission where appropriate. For example, the message may include an indication of a starting time occasion where SSB transmission will start. Additionally, or alternatively, it may also include an indication of a periodicity of SSB transmission. Additionally, or alternatively, it may also include an indication of how long SSB transmission will continue. Additionally, or alternatively, it may also include an indication as to whether SSB transmission is to be aperiodic or semi-persistent.

[0109] Whether the indication is sent in a MAC CE, or a DCI based message, when not included in the SSB configuration, the indication sent in a MAC CE, or a DCI based message may also include an indication of the identity or identities of the SCell or SCells for which on-demand SSB is enabled. For example, the identity of the SCells may be explicitly indicated or alternatively, the indication may be implicit. In the case of implicit indication, the UE 3 may imply which serving cell the SSBs are to be transmitted over by the RAN node 5 based on the serving cell 9 or radio resources over which the UE 3 receives the indication. For example, where the UE 3 receives the indication over serving cell 'X', then the UE 3 may assume that the SSBs will be sent to the UE 3 over serving cell 'X' also.

[0110] It will be appreciated that, like the indication of the number of SSBs that will be sent, all the indications discussed here may be indicated in the MAC CE, or a DCI based message explicitly or implicitly. For example, dedicated indication fields may be provided in the message, or alternatively, an index value may be provided in the message that maps to a mapping table that contains entries that specify SSB start time, SSB periodicity, SSB transmission duration, and the like. In this scenario the mapping table is configured to the UE 3 previously during an RRC configuration procedure.

[0111] At step S406, having received the SCell activation command at step S404a and the indication for on-demand SSB for the SCell at step S404b, the UE 3 is triggered to monitor for SCell SSB transmission for the SCell or SCells indicated in the SCell activation command. For example, the UE 3 may be triggered to monitor for SCell SSB transmission in a specific duration (e.g., in a specific monitoring window).

[0112] In one example, the size of that specific duration / monitoring window may be indicated to the UE 3 in the SCell activation command or the indication for on-demand SSB for the SCell. For example, the SCell activation command or the indication for on-demand SSB for the SCell may indicate a time for the SCell activation and the UE 3 tries to receive SSBs for that SCell before the indicated time for the SCell activation. Alternatively, the SCell activation command or the indication for on-demand SSB for the SCell may explicitly indicate a time duration for which UE 3 should monitor for SSBs. In another example, the size of that specific duration / monitoring window may be indicated to the UE 3 within an RRC configuration of SCell.

[0113] At step S408, the RAN node 5 transmits SCell SSB transmission to the UE 3. Those SSB transmission may be aperiodic transmission or semi-persistent transmission. In response to receiving those SCell SSB transmission, the UE 3 may optionally send, at step S409, an appropriate feedback message (e.g., HARQ ACK / NACK message) to the RAN node 5 to confirm successful reception of the SCell SSB transmission.

[0114] Having successfully received the SCell SSB transmission (and optionally transmission appropriate feedback message to the RAN node 5), the UE 3 may consider the SCell (or SCells) as activated (S410) and start normal SCell operations (e.g. PDCCH monitoring, SRS transmission, and the like). It will be appreciated that the UE 3 may consider the SCell as activated only after it has received a specific number of SCell SSB transmission. For example, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on the implementation of the UE 3. For example, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on whether the UE 3 has performed a prior measurement of the SCell. Alternatively, or additionally, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on a number of receive (Rx) beams present at the UE 3.

[0115] Alternatively, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be configured by the network. For example, the network may determine, and indicate the number of SCell SSB transmission required for the UE 3 to consider the SCell activated in any appropriate message to the UE 3. By way of example only, the network may indicate the number in an on-demand SSB configuration sent by the RAN node 5 to the UE 3. Alternatively (or additionally) the network may indicate the number in an SSB configuration sent by the RAN node 5 to the UE 3.

[0116] If the UE 3 does not successfully receive the SCell SSB transmission within the monitoring window, or the UE 3 fails to detect SCell SSB transmission within the monitoring window, the UE 3 may indicate to the RAN node 5 that it has failed to successfully receive / detect SCell SSB transmission despite having received an SCell activation command from the RAN node 5.

[0117] In one example, the UE 3 may send an appropriate feedback message (e.g., HARQ NACK message) to the RAN node 5. In another example, the UE 3 may indicate that failure to successfully receive / detect SCell SSB transmission using an 'On-demand SSB Failure' indication sent to the RAN node 5 by the UE 3 via appropriate RRC signalling. The appropriate signalling may be sent to the RAN node 5 over the PCell that the RAN node 5 and the UE 3 are currently communicating over. In another example, the UE 3 may indicate its failure to acquire the on-demand SSBs via UCI or a MAC-CE transmitted to the RAN node 5 over the PCell that the RAN node 5 and the UE 3 are currently communicating over. In yet another example, the UE 3 may indicate that failure to successfully receive / detect SCell SSB transmission by transmitting an appropriate (re-)request message for on-demand SCell SSB transmission to the RAN node 5.

[0118] In yet another example, rather than transmitting an appropriate (re-)request message, the UE 3 may (re-)request on-demand SCell SSB transmission by appropriate wake-up signals (e.g., via PRACH signalling or sounding reference resources). Having received that (re-)request the RAN node 5 may imply that the UE 3 failed to successfully receive / detect SCell SSB transmission that the RAN node 5 previously transmitted to the UE 3.

[0119] After initiating the request for on-demand SSBs, if the UE 3 still is not able to detect the SSBs sent by the RAN node 5, the UE 3 may repeat the procedure described N times before triggering a failure event. The value of N may be configured by the network and signalled to the UE 3 over any appropriate signalling (e.g., an RRC message) or alternatively, it may be pre-defined (e.g., hard coded in the UE 3). It will also be appreciated that the value of N may also be set to zero to indicate that the UE 3 only transmits one on-demand-SSB request before triggering a failure event.

[0120] If the UE 3 triggers a failure event, then the UE 3 may indicate that failure using an 'On-demand SSB Failure' indication sent to the RAN node 5 by the UE 3 via appropriate RRC signalling. The appropriate signalling may be sent to the RAN node 5 over the PCell that the RAN node 5 and the UE 3 are currently communicating over. In another example, the UE 3 may indicate its failure to acquire the on-demand SSBs via uplink control information (UCI) or a MAC-CE transmitted to the RAN node 5 over the PCell that the RAN node 5 and the UE 3 are currently communicating over.

[0121] In the procedure for on-demand SCell SSB transmission described above, having received the SCell activation command at step S404a, the UE 3 begins to monitor for SCell SSB transmission from the RAN node 5 for activation of the SCell indicated in the SCell activation command. However, it will nevertheless be appreciated that in certain scenarios the UE 3 may not need to monitor for the SCell SSB transmission prior to activation of the SCell. For example, the UE 3 may not need to detect / receive SSBs upon SCell activation when the UE 3 has recently performed SSB measurements for the given SCell. For example, the UE 3 may have recently performed SSB measurements for RRM purposes and / or time / frequency synchronisation purposes. In such cases, if the UE 3 has maintained synchronisation with the SCell since it performed those SSB measurements, the UE 3 may use those SSB measurements for SCell activation and may not need to monitor for more SSB transmission. If the UE 3 is able to use those SSB measurements then the UE 3 may, upon receipt of the SCell activation command at step S404a, directly activate the SCell without performing on-demand SSB measurements. Whether the UE 3 has maintained synchronisation with the SCell since it performed SSB measurements may be determined by the UE 3 periodically, or upon receipt of the SCell activation command at step S404a.

[0122] Alternatively, the UE 3 may be pre-configured (e.g., hardcoded) to not perform SSB measurements if the UE 3 performed the SSB measurements for RRM purposes and / or the time / frequency synchronisation purposes a threshold time / duration ago.

[0123] Fig. 5 depicts a simplified timing diagram illustrating the procedure illustrated in Fig. 4 used by the UE 3 for determining when to trigger monitoring for on-demand SCell SSB transmission.

[0124] As shown in Fig. 5, after receiving a SSB configuration for on-demand SCell SSBs as described above with reference to step S402, the UE 3 may communicate (transmit / receive) in its PCell as normal during some arbitrary period. During that arbitrary period the UE 3 does not monitor for SCell SSB transmission. At some later time, the UE 3 may receive an SCell activation command. The SCell activation command may be included in any appropriate command message to be sent by the RAN node 5 to the UE 3 as described above with reference to step S404a.

[0125] At the same time that the SCell activation command is transmitted to the UE 3 (or shortly thereafter), the RAN node 5 may also transmit, to the UE 3, an indication for on-demand SSB for the SCell for the SCell indicated in the SCell activation command as described above with reference to step S404b.

[0126] Having received the SCell activation command and the indication for on-demand SSB for the SCell, the UE 3 may be triggered to monitor for SCell SSB transmission for a period of time (e.g., in a specific monitoring window) as described above with reference to step S406. During that monitoring window the RAN node 5 transmits SCell SSBs to the UE 3. Having successfully received the SCell SSB transmission, the UE 3 may consider the SCell activated and start normal SCell operations (e.g. PDCCH monitoring, SRS transmission, and the like). It will be appreciated that UE 3 may consider the SCell activated only after it has received a specific number of SCell SSB transmission. For example, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on the implementation of the UE 3. For example, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on whether the UE 3 has performed a prior measurement of the SCell. Alternatively, or additionally, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on a number of receive (Rx) beams present at the UE 3.

[0127] Alternatively, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be configured by the network. For example, the network may determine, and indicate the number of SCell SSB transmission required for the UE 3 to consider the SCell activated in any appropriate message to the UE 3. By way of example only, the network may indicate the number in an on-demand SSB configuration sent by the RAN node 5 to the UE 3. Alternatively (or additionally) the network may indicate the number in an SCell configuration sent by the RAN node 5 to the UE 3.

[0128] It will be appreciated where the UE 3 considers the SCell activated based on having received a specific number of SCell SSB transmission, the UE 3 may consider the SCell activated at some point during the monitoring window i.e., before the monitoring window expires.

[0129] Following expiration of the monitoring window, the UE 3 may stop monitoring for SCell SSB transmission. Accordingly, the UE 3 may be configured such that it assumes that SCell SSBs are only transmitted in the monitoring window (i.e., not periodically transmitted) and hence the UE 3 does not need to monitor for SCell SSBs all the time. It will be appreciated that where the UE 3 is configured such that it assumes that SCell SSBs are only transmitted in the monitoring window, the UE 3 may also be configured to explicitly request SCell SSB transmission for procedures that require SSB measurement / detection (e.g., TA expiry or when the UE 3 loses time / frequency synchronization).

[0130] Fig. 6 depicts a simplified sequence diagram illustrating another procedure for on-demand SCell SSB transmission to the UE 3 triggered by the RAN node 5 that may be used in the communication system 1 of Fig. 1.

[0131] As shown in Fig. 6 there is provided the RAN node 5 and the UE 3 deployed in the communication system 1 of Fig. 1.

[0132] At step S602, the RAN node 5 sends an indication to the UE 3 indicating whether on-demand SSB transmission for one or more SCells is enabled. Specifically, for each SCell, the RAN node 5 may indicate whether SSBs are to be transmitted: i) on-demand based on a network trigger (i.e., a trigger at the RAN node 5), and / or ii) on-demand based on the RAN node 5 receiving requests for on-demand SSBs from the UE 3.

[0133] For example, the RAN node 5 may indicate to the UE 3 that transmission of on-demand SSBs for one or more SCells is enabled, and the basis on which SSBs will be transmitted (e.g., based on a network trigger or a request from the UE 3) within an appropriate serving cell configuration message e.g., a configuration message sent to configure the UE 3 to camp onto a serving cell of the RAN node 5, where a serving cell 9 in CA may consist of one PCell and several SCells. The indication may be sent within an SSB configuration of the serving cell 9 e.g., in an SSB configuration in a ServingCellConfigCommon information element (IE) provided in a SIB1 message, or the like.

[0134] As way of example only, the ServingCellConfigCommon IE may include the periodicity of the SSB transmission (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 ServingCellConfigCommon IE may also provide the UE 3 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 IE (e.g., ServingCellConfigCommon provided in a SIB1 message, or any other appropriate dedicated message).

[0135] The SSB configuration in the ServingCellConfigCommon IE may also indicate additional appropriate information needed to facilitate on-demand SSB transmission occasions for SCells. For example, it may include an indication to the UE 3 that transmission of on-demand SSBs for one or more SCells is enabled, and the basis on which they will be transmitted (e.g., based on a network trigger or a request from the UE 3). The configuration may also include information on the periodicity of such on-demand SSB transmission, and / or how long on-demand SSB transmission should be performed for once they have begun. By way of example only, the SSB configuration for on-demand SSBs may indicate an absolute time limit (e.g., 100 ms) for the duration of on-demand SSB transmission, or alternatively it may indicate a count of SSB periods (e.g., 5 periods of SSB transmission) for the duration of on-demand SSB transmission.

[0136] Sometime later at step S603 on-demand SSB transmission for one or more SCells is triggered at the RAN Node 5. The trigger may occur, for example, when the RAN node 5 decides to activate one or more SCells for use with the UE 3. For example, the RAN node 5 may decide to activate an SCell for use with the UE 3 when the communication link between the RAN node 5 and the UE 3 is experiencing high levels of data transmission congestion, or where additional bandwidth capacity would be beneficial. Additionally, or alternatively, the RAN node 5 may decide to activate a specific SCell for use with the UE 3 when specific services are required that are only supported by a specific SCell.

[0137] At step S604 the RAN node 5 may transmit, to the UE 3, an indication for on-demand SSB for an SCell. The indication for on-demand SSB for an SCell may consist of any appropriate type of indication or message that is able to convey to the UE 3 that the RAN node 5 will initiate on-demand SSB transmission for an SCell.

[0138] The RAN node 5 may transmit the indication for on-demand SSB for an SCell to the UE 3 at step S604 in a MAC CE or a DCI. In one example, the RAN node 5 may transmit the indication for on-demand SSB for an SCell to the UE 3 in a new MAC CE. Where a new MAC CE is used it may typically be implemented as special bit strings within the LCID field of the MAC header of the MAC PDU.

[0139] If multiple SCells are to be activate that are able to share a single set of SSB transmission, then the indication may include appropriate information to indicate to the UE 3 that multiple SCells to be activated can share a single set of SSB transmission. For example, the indication may include an explicit indication that multiple SCells to be activated can share a single set of SSB transmission. Alternatively, when the UE 3 receives an SCell activation command at some future time to activate multiple SCells and the indication for on-demand SSB for SCells only includes information pertaining to a single SCell, the UE 3 may infer that the multiple SCells to be activated can share a single set of SSB transmission.

[0140] In either scenario, having received the MAC CE comprising the indication for on-demand SSB for the SCell, the UE 3 may (not shown) acknowledge receipt of the MAC CE to the RAN node 5 via a HARQ ACK / NACK procedure associated with the MAC CE transmission.

[0141] In another example, the indication for on-demand SSB for an SCell may be sent to the UE 3 in a new DCI message sent on the PDCCH. For example, an appropriate new DCI message may be provided that has a different format to previous DCI formats. The DCI may be a common group DCI that is configured to be received by multiple UEs 3, or alternatively it may be a dedicated DCI message that is configured for reception by a specific UE 3. The UE 3 may monitor for such a new DCI message in several possible ways. For example, the UE 3 may always monitor for the new DCI message when the UE 3 receives an activation command for an SCell for which an on-demand SSB configuration is provided. Alternatively, the UE 3 may monitor for the new DCI message if a configuration to receive the given DCI is available to the UE 3 and an on-demand SSB configuration is provided for at least one of the SCells configured to the UE 3. Alternatively, the UE 3 may always monitor for the new DCI message regardless of whether an SCell is activated or deactivated (i.e., at all times).

[0142] In the scenario where the indication for on-demand SSB for the SCell is sent to the UE 3 in the new DCI message sent on the PDCCH, the new DCI message may be transmitted between the RAN node 5 and the UE 3 via a primary cell currently being used for communication between the RAN node 5 and the UE 3 (e.g., over a PCell or PSCell only). Nevertheless, it will be appreciated that the DCI message may be transmitted over any appropriate cell capable of supporting communication between the RAN node 5 and the UE 3.

[0143] Whether the indication is sent in a MAC CE, or a DCI based message, it may also include other appropriate information. For example, the message may also include an indication of a number of SSBs that are to be transmitted by the RAN node 5, for example where N SSBs are to be sent by the RAN node 5, the message may include an indication that N SSBs will be sent by the RAN node 5. The indication that N SSBs will be sent by the RAN node 5 may, by way of example, be in the form of a bit mask wherein each bit is associated with an index of a corresponding one of the N SSBs. Nevertheless, it will be appreciated that the indication that N SSBs will be sent by the RAN node 5 may be sent in other ways, for example, in the form of an index that can be mapped to a mapping table configured to the UE 3 previously during an RRC configuration procedure. In this scenario, each entry in the mapping table may indicate a set of SSBs that the UE 3 should expect to receive from the RAN node 5.

[0144] Whether the indication is sent in a MAC CE, or a DCI based message, the message may also include timing information pertaining to the SSB transmission where appropriate. For example, the message may include an indication of a starting time occasion where SSB transmission will start. Additionally, or alternatively, it may also include an indication of a periodicity of SSB transmission. Additionally, or alternatively, it may also include an indication of how long SSB transmission will continue. Additionally, or alternatively, it may also include an indication as to whether SSB transmission is to be aperiodic or semi-persistent.

[0145] Such timing information, may for example, include an indication that the UE 3 should monitor for SCell SSB transmission in a specific duration (e.g., in a specific monitoring window). In one example, the size of that specific duration / monitoring window may be indicated to the UE 3 indication at step S604. For example, the indication may indicate a time for the SCell activation, and the UE 3 tries to receive SSBs for that SCell before the indicated time for the SCell activation. Alternatively, the indication may explicitly indicate a time duration for which UE 3 should monitor for SSBs. In another example, the size of that specific duration / monitoring window may be indicated to the UE 3 within an RRC configuration of SCell.

[0146] It will be appreciated that, like the indication of the number of SSBs that will be sent, all the indications discussed here may be indicated in the MAC CE, or a DCI based message explicitly or implicitly. For example, dedicated indication fields may be provided in the message, or alternatively, an index value may be provided in the message that maps to a mapping table that contains entries that specify SSB start time, SSB periodicity, SSB transmission duration, and the like. In this scenario the mapping table is configured to the UE 3 previously during an RRC configuration procedure.

[0147] Whether the indication is sent in a MAC CE, or a DCI based message, the message may also include an indication of the identity or identities of the SCell or SCells for which on-demand SSB is enabled. For example, the identity of the SCells may be explicitly indicated or alternatively, the indication may be implicit. In the case of implicit indication, the UE 3 may imply which serving cell 9 the SSBs are to be transmitted over by the RAN node 5 based on the serving cell 9 or radio resources over which the UE 3 receives the indication. For example, where the UE 3 receives the indication over serving cell 'X', then the UE 3 may assume that the SSBs will be sent to the UE 3 over serving cell 'X' also.

[0148] At step S606, having received the indication for on-demand SSB for an SCell at step S604, the UE 3 is triggered to monitor for SCell SSB transmission for an SCell. For example, the UE 3 may be triggered to monitor for SCell SSB transmission in the specific duration (e.g., in the specific monitoring window) indicated in the indication for on-demand SSB for an SCell, or as pre-configured by RRC signalling.

[0149] At step S608, the RAN node 5 transmits SCell SSB transmission to the UE 3. Those SSB transmission may be aperiodic transmission or semi-persistent transmission. In response to receiving the SCell SSB transmission, the UE 3 may optionally send, at step S609, an appropriate feedback message (e.g., HARQ ACK / NACK message) to the RAN node 5 to confirm successful reception of the SCell SSB transmission.

[0150] After expiry of the monitoring window (or alternatively during the monitoring window), at step S610, the RAN node 5 transmits an SCell activation command for one or more SCells to the UE 3. The SCell activation command may be included in any appropriate command message to be sent by the RAN node 5 to the UE 3, which may be sent from the RAN node 5 to the UE 3 via a dedicated MAC CE on the PDSCH.

[0151] By way of example only, the SCell activation command may be sent to the UE 3 in a MAC CE transmitted from the RAN node 5 to the UE 3 via communication paths at the MAC layer. Such MAC CEs are typically implemented as special bit strings within the LCID field of the MAC header of the MAC PDU. Having received the MAC CE comprising the SCell activation command, the UE 3 may (not shown) acknowledge receipt of the MAC CE to the RAN node 5 via a HARQ ACK / NACK procedure associated with the MAC CE transmission.

[0152] Having received the SCell activation command for one or more SCells at step S610, the UE 3 uses its measurement of the transmitted on-demand SSBs to activate the SCells at step S612 and begin communication over them with the RAN node 5.

[0153] Nevertheless, it will be appreciated that the UE 3 may consider the SCell as activated only if it has received a specific number of SCell SSB transmission at the time that the SCell activation command is received. For example, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on the implementation of the UE 3. For example, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on whether the UE 3 has performed a prior measurement of the SCell. Alternatively, or additionally, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on a number of receive (Rx) beams present at the UE 3.

[0154] Alternatively, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be configured by the network. For example, the network may determine, and indicate the number of SCell SSB transmission required for the UE 3 to consider the SCell activated in any appropriate message to the UE 3. By way of example only, the network may indicate the number in an on-demand SSB configuration sent by the RAN node 5 to the UE 3. Alternatively (or additionally) the network may indicate the number in an SCell configuration sent by the RAN node 5 to the UE 3.

[0155] If the UE 3 has received the SCell activation command but has not successfully received the SCell SSB transmission within the monitoring window, or the UE 3 fails to detect SCell SSB transmission within the monitoring window, the UE 3 may indicate to the RAN node 5 that it has failed to successfully receive / detect SCell SSB transmission despite having received an SCell activation command from the RAN node 5. For example, the UE 3 may send an appropriate feedback message (e.g., HARQ NACK message) to the RAN node 5.

[0156] Alternatively, the UE 3 may indicate that failure to successfully receive / detect SCell SSB transmission using an 'On-demand SSB Failure' indication sent to the RAN node 5 by the UE 3 via appropriate RRC signalling. The appropriate signalling may be sent to the RAN node 5 over the PCell that the RAN node 5 and the UE 3 are currently communicating over. In another example, the UE 3 may indicate its failure to acquire the on-demand SSBs via uplink control information (UCI) or a MAC-CE transmitted to the RAN node 5 over the PCell that the RAN node 5 and the UE 3 are currently communicating over.

[0157] Alternatively, the UE 3 may indicate that failure to successfully receive / detect SCell SSB transmission by transmitting an appropriate (re-)request message for on-demand SCell SSB transmission to the RAN node 5. In another example, rather than transmitting an appropriate (re-)request message, the UE 3 may (re-)request on-demand SCell SSB transmission by appropriate wake-up signals (e.g., via PRACH signalling or sounding reference resources).

[0158] Having received that (re-)request the RAN node 5 may imply that the UE 3 failed to successfully receive / detect SCell SSB transmission that the RAN node 5 previously transmitted to the UE 3. After initiating the request for on-demand SSBs, if the UE 3 still is not able to detect the SSBs sent by the RAN node 5, the UE 3 may repeat the procedure N times before triggering a failure event. The value of N may be configured by the network and signalled to the UE 3 over any appropriate signalling (e.g., an RRC message) or alternatively, it may be pre-defined (e.g., hard coded in the UE 3). It will also be appreciated that the value of N may also be set to zero to indicate that the UE 3 only transmits one on-demand-SSB request before triggering a failure event. If the UE 3 triggers a failure event, then the UE 3 may indicate that failure using an 'On-demand SSB Failure' indication sent to the RAN node 5 by the UE 3 via appropriate RRC signalling. The appropriate signalling may be sent to the RAN node 5 over the PCell that the RAN node 5 and the UE 3 are currently communicating over.

[0159] In another example, the UE 3 may indicate its failure to acquire the on-demand SSBs via UCI or a MAC-CE transmitted to the RAN node 5 over the PCell that the RAN node 5 and the UE 3 are currently communicating over.

[0160] While in the above example, the UE 3 monitors for SCell on-demand SSB transmission once it has received the indication at S604, it will nevertheless be appreciated that in certain scenarios the UE 3 may not need to monitor for SCell SSB transmission prior to activation of the SCell. For example, the UE 3 may not need to detect / receive SSBs when the UE 3 has recently performed SSB measurements for the given SCell. For example, the UE 3 may have recently performed SSB measurements for RRM purposes and / or time / frequency synchronisation purposes. In such cases, if the UE 3 has maintained synchronisation with the SCell since it performed those SSB measurements for RRM purposes and / or time / frequency synchronisation purposes, the UE 3 may use those SSB measurements for SCell activation and may not need to monitor for more SSB transmission.

[0161] Whether the UE 3 has maintained synchronisation with the SCell since it performed SSB measurements for RRM purposes and / or time / frequency synchronisation purposes may be determined by the UE 3 periodically or upon receipt of the indication at S604.

[0162] Alternatively, the UE 3 may be pre-configured (e.g., hardcoded) to not perform SSB measurements if the UE 3 performed the SSB measurements for RRM purposes and / or the time / frequency synchronisation purposes a threshold time / duration ago.

[0163] Fig. 7 depicts a simplified timing diagram illustrating the procedure illustrated in Fig. 6 used by the UE 3 for determining when to trigger monitoring for on-demand SCell SSB transmission.

[0164] As shown in Fig. 7, after receiving an SCell configuration for on-demand SCell SSBs as described above with reference to step S602, the UE 3 may communicate (transmit / receive) in its PCell as normal during some arbitrary period. During that arbitrary period the UE 3 does not monitor for SCell SSB transmission. At some later time, the UE 3 may receive an indication for on-demand SSB for an SCell. The indication for on-demand SSB for the SCell may consist of any appropriate type of indication or message that is able to convey to the UE 3 that the RAN node 5 will initiate on-demand SSB transmission for the SCell as described above with reference to step S604. It will nevertheless be appreciated that such an indication may only be included where on-demand SSBs for the SCell or SCells being activated is supported.

[0165] Having received the indication for on-demand SSB transmission for an SCell, the UE 3 may be triggered to monitor for SCell SSB transmission for a period of time (e.g., in a specific monitoring window) as described above with reference to step S606. During that monitoring window, the RAN node 5 transmits SCell SSBs to the UE 3.

[0166] At some later time, the UE 3 may receive an SCell activation command as described above with reference to step S610. For example, the UE 3 may receive an SCell activation command during the monitoring window in which the RAN node 5 transmits SCell SSBs to the UE 3. Alternatively, the UE 3 may receive an SCell activation command after the expiry of the monitoring window.

[0167] Following expiration of the monitoring window, the UE 3 may stop monitoring for SCell SSB transmission. Accordingly, the UE 3 may be configured such that it assumes that SCell SSBs are only transmitted in the monitoring window (i.e., not periodically transmitted) and hence the UE 3 does not need to monitor for SCell SSBs all the time. It will be appreciated that where the UE 3 is configured such that it assumes that SCell SSBs are only transmitted in the monitoring window, the UE 3 may also be configured to explicitly request SCell SSB transmission for procedures that require SSB measurement / detection (e.g., TA expiry or when the UE 3 loses time / frequency synchronization).

[0168] Having received the SCell activation command, the indication for on-demand SSB for the SCell, and the SSB transmission, the UE 3 may consider the SCell activated and start normal SCell operations (e.g. PDCCH monitoring, SRS transmission, and the like).

[0169] As previously described, it will be appreciated that the UE 3 may consider the SCell activated only after it has received a specific number of SCell SSB transmission. For example, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on the implementation of the UE 3. For example, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on whether the UE 3 has performed a prior measurement of the SCell. Alternatively, or additionally, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on a number of receive (Rx) beams present at the UE 3.

[0170] Alternatively, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be configured by the network. For example, the network may determine, and indicate the number of SCell SSB transmission required for the UE 3 to consider the SCell activated in any appropriate message to the UE 3. By way of example only, the network may indicate the number in an on-demand SSB configuration sent by the RAN node 5 to the UE 3. Alternatively (or additionally) the network may indicate the number in an SCell configuration sent by the RAN node 5 to the UE 3.

[0171] It will be appreciated where the UE 3 considers the SCell activated based on having received a specific number of SCell SSB transmission, the UE 3 may consider the SCell activated at some point during the monitoring window if the specific number of SCell SSB transmission and SCell activation command have been received before the monitoring window expires.

[0172] Fig. 8 depicts a simplified sequence diagram illustrating another procedure for on-demand SCell SSB transmission to the UE 3 triggered by the RAN node 5 that may be used in the communication system 1 of Fig. 1.

[0173] As shown in Fig. 8 there is provided the RAN node 5 and the UE 3 deployed in the communication system 1 of Fig. 1.

[0174] At step S802, the RAN node 5 sends an indication to the UE 3 indicating whether on-demand SSB transmission for one or more SCells is enabled. Specifically, for each SCell, the RAN node 5 may indicate whether SSBs are to be transmitted: i) on-demand based on a network trigger (i.e., a trigger at the RAN node 5), and / or ii) on-demand based on the RAN node 5 receiving requests for on-demand SSBs from the UE 3.

[0175] The RAN node 5 may indicate to the UE 3 that transmission of on-demand SSBs for one or more SCells is enabled, and the basis on which SSBs will be transmitted (e.g., based on a network trigger or a request from the UE 3) within an appropriate serving cell configuration message e.g., a configuration message sent to configure the UE 3 to camp onto a serving cell of the RAN node 5, where a serving cell in CA may consist of one PCell and several SCells. The indication may be sent within an SSB configuration of the serving cell e.g., in an SSB configuration in a ServingCellConfigCommon IE provided in a SIB1 message, or the like.

[0176] As way of example only, the ServingCellConfigCommon IE may include the periodicity of the SSB transmission (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 ServingCellConfigCommon IE may also provide the UE 3 with an indication of which SSBs within a 5 ms duration are transmitted (e.g., using ssb-PositionsInBurst). The UE 3 may also be provided with an indication of an absolute transmit power value of the SSS (e.g., using ss-PBCH-BlockPower) which may range from -60 to 50 dBm. Furthermore, the UE 3 may also be provided with an indication of the subcarrier spacing (SCS) used for the SSB (e.g., using ssbSubcarrierSpacing). It will be appreciated that all indications to the UE 3 about the SSB may be indicated to the UE 3 via any appropriate IE (e.g., ServingCellConfigCommon provided in a SIB1 message, or any other appropriate dedicated message).

[0177] The SSB configuration in the ServingCellConfigCommon IE may also indicate additional appropriate information needed to facilitate on-demand SSB transmission occasions for SCells. For example, it may include an indication to the UE 3 that transmission of on-demand SSBs for one or more SCells is enabled, and the basis on which they will be transmitted (e.g., based on a network trigger or a request from the UE 3). The configuration may also include information on the periodicity of such on-demand SSB transmission, and / or how long on-demand SSB transmission should be performed for once they have begun. By way of example only, the SSB configuration for on-demand SSBs may indicate an absolute time limit (e.g., 100 ms) for the duration of on-demand SSB transmission, or alternatively it may indicate a count of SSB periods (e.g., 5 periods of SSB transmission) for the duration of on-demand SSB transmission.

[0178] Sometime later at step S803, the RAN node 5 may decide to activate one or more SCells for use with the UE 3. For example, the RAN node 5 may decide to activate an SCell for use with the UE 3 when the communication link between the RAN node 5 and the UE 3 is experiencing high levels of data transmission congestion, or where additional bandwidth capacity would be beneficial. Additionally, or alternatively, the RAN node 5 may decide to activate an SCell for use with the UE 3 when specific services are required that are only supported by an SCell.

[0179] When a decision has been made to activate one or more SCells, the RAN node 5 transmits, at step S804, an SCell activation command for the one or more SCells to the UE 3. The SCell activation command may be included in any appropriate command message to be sent by the RAN node 5 to the UE 3, which may be sent from the RAN node 5 to the UE 3 via a dedicated MAC CE on the PDSCH.

[0180] By way of example only, the SCell activation command may be sent to the UE 3 in a new MAC CE transmitted from the RAN node 5 to the UE 3 via communication paths at the MAC layer. Such MAC CEs are typically implemented as special bit strings within the logical channel identifier (LCID) field of the MAC header of the MAC PDU. Having received the MAC CE comprising the SCell activation command, the UE 3 may (not shown) acknowledge receipt of the MAC CE to the RAN node 5 via a HARQ ACK / NACK procedure associated with the MAC CE transmission.

[0181] The SCell activation command may also include other appropriate information. For example, the SCell activation command may also include an indication of a number of SSBs that may be transmitted by the RAN node 5 on-demand (e.g., when requested by the UE 3). For example, where N SSBs may be sent by the RAN node 5, the message may include an indication that N SSBs may be sent by the RAN node 5. The indication that N SSBs may be sent by the RAN node 5 may, by way of example, be in the form of a bit mask wherein each bit is associated with an index of a corresponding one of the N SSBs. Nevertheless, it will be appreciated that the indication that N SSBs may be sent by the RAN node 5 may be sent in other ways, for example, in the form of an index that can be mapped to a mapping table configured to the UE 3 previously during an RRC configuration procedure. In this scenario, each entry in the mapping table may indicate a set of SSBs that the UE 3 expect to receive from the RAN node 5 following a request from the UE 3.

[0182] The SCell activation command may also include timing information pertaining to the on-demand SSB transmission where appropriate. For example, the message may include an indication of a starting time occasion where SSB transmission will start if requested by the UE 3. Additionally, or alternatively, it may also include an indication of a periodicity of on-demand SSB transmission if requested. Additionally, or alternatively, it may also include an indication of how long SSB transmission will continue if requested. Additionally, or alternatively, it may also include an indication as to whether such on-demand SSB transmission is to be aperiodic or semi-persistent.

[0183] The SCell activation command may also include an indication of the identity or identities of the SCell or SCells for which on-demand SSB is enabled. For example, the identity of the SCells may be explicitly indicated or alternatively, the indication may be implicit. In the case of implicit indication, the UE 3 may imply which serving cell the SSBs are to be transmitted over by the RAN node 5 based on the serving cells for which the UE 3 receives the on-demand SSB configuration. For example, if the UE 3 receives the on-demand SSB configuration for serving cell 'X', then the UE 3 may assume that the SSBs may be sent, on request, to the UE 3 for serving cell 'X' when UE 3 receives the activation command for serving cell 'X'.

[0184] It will be appreciated that, like the indication of the number of SSBs that will be sent, all the indications discussed here may be indicated in the MAC CE message explicitly or implicitly. For example, dedicated indication fields may be provided in the message, or alternatively, an index value may be provided in the message that maps to a mapping table that contains entries that specify SSB start time, SSB periodicity, SSB transmission duration, and the like. In this scenario the mapping table is configured to the UE 3 previously during an RRC configuration procedure.

[0185] Having received the SCell activation command, the UE 3, at step S805 may trigger an SCell SSB transmission request procedure. For example, having received the SCell activation command the UE 3 may decide to request SCell SSB transmission for one or more SCells indicated in the SCell activation command for which on on-demand SSB configuration is provided. Part of that SCell SSB transmission request procedure may include, at step S806, transmitting an appropriate request message to the RAN node 5 to request SCell SSB transmission for the SCell (or SCells) indicated in the SCell activation command (e.g., an SCell SSB transmission request message).

[0186] The SCell SSB transmission request message may, for example, comprise an indication indicating the UE's need for SCell SSB transmission in UCI sent to the RAN node 5. For example, in response to the UE 3 receiving the SCell activation command at step S805, the UE 3 may send appropriate feedback information to the RAN node 5 to indicate whether the SCell activation command was successfully received (and processed) by the UE 3. That feedback information may be sent in a HARQ-type message (e.g., HARQ ACK / NACK message) as part of UCI, and may also include an indication of the UE's need for SCell SSB transmission to activate the SCell (or SCells) indicated in the SCell activation command.

[0187] At step S808, the RAN node 5 may (optionally) transmit an appropriate response message to the UE 3 to confirm that the RAN node 5 has received the UE's SCell SSB transmission request message. It will be appreciated that where a response message is sent this (rather than the activation command sent at S804) may include some or all of the information pertaining to the configuration of the on-demand SSB transmission described above in relation to the possible content of the activation command (e.g. the number of SSBs and / or associated timing information).

[0188] It will be appreciated that where the communication system 1 is configured such that the UE 3 triggers an on-demand SCell SSB transmission request procedure such as that described above, the timing of the transmission in the procedure will need to be configured so that there is sufficient time between the UE request transmission and network's corresponding response and / or on-demand SCell SSB transmission.

[0189] At step S809, having transmitted the on-demand SCell SSB transmission request message to the RAN node 5 at step S806 (or optionally having received an appropriate response message to the UE 3 to confirm that the RAN node 5 has received the UE's SCell SSB transmission request message), the UE 3 triggers to monitor for SCell SSB transmission for the SCell or SCells indicated in the SCell activation command. For example, the UE 3 may trigger to monitor for SCell SSB transmission in a specific duration (e.g., in a specific monitoring window).

[0190] It will be appreciated that the SCell SSB transmission request message may include appropriate information to indicate to the RAN node 5 a monitoring window for receiving the SCell SSBs. For example, the SCell SSB transmission request message sent at S806 may include an indication of the size of a specific duration / monitoring window within which to expect the on-demand SCell SSB transmission.

[0191] It will nevertheless be appreciated that the size of that specific duration / monitoring window may be indicated to the UE 3 in the SCell activation command (or response message at S808). For example, the SCell activation command (or response message at S808) may indicate a time for the SCell activation (e.g., relative to the timing that the request is sent by the UE 3, or the associated response is sent / received) and the UE 3 tries to receive SSBs for that SCell before the indicated time for the SCell activation. Alternatively, the SCell activation command (or response message at S808) may explicitly indicate a time duration for which UE 3 should monitor for SSBs (e.g., following the sending of the request by the UE 3 or following the reception / sending of the associated response). In another example, the size of that specific duration / monitoring window may be indicated to the UE 3 within an RRC configuration of SCell.

[0192] At step S812, the RAN node 5 transmits SCell SSB transmission to the UE 3. Those SSB transmission may be aperiodic transmission or semi-persistent transmission. In response to receiving the SCell SSB transmission, the UE 3 may optionally send (not shown) an appropriate feedback message (e.g., HARQ ACK / NACK message) to the RAN node 5 to confirm successful reception of the SCell SSB transmission.

[0193] Having successfully received the SCell SSB transmission (and optionally transmission appropriate feedback message to the RAN node 5), the UE 3 may consider the SCell as activated (S814) and start normal SCell operations (e.g. PDCCH monitoring, SRS transmission, and the like). It will be appreciated that the UE 3 may consider the SCell as activated only after it has received a specific number of SCell SSB transmission. For example, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on the implementation of the UE 3. For example, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on whether the UE 3 has performed a prior measurement of the SCell. Alternatively, or additionally, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on a number of receive (Rx) beams present at the UE 3.

[0194] Alternatively, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be configured by the network. For example, the network may determine, and indicate the number of SCell SSB transmission required for the UE 3 to consider the SCell activated in any appropriate message to the UE 3. By way of example only, the network may indicate the number in an on-demand SSB configuration sent by the RAN node 5 to the UE 3. Alternatively (or additionally) the network may indicate the number in an SCell configuration sent by the RAN node 5 to the UE 3.

[0195] If the UE 3 does not successfully receive the SCell SSB transmission within the monitoring window, or the UE 3 fails to detect SCell SSB transmission within the monitoring window, the UE 3 may indicate to the RAN node 5 that it has failed to successfully receive / detect SCell SSB transmission despite having received an SCell activation command from the RAN node 5 (not shown). For example, the UE 3 may send an appropriate feedback message (e.g., HARQ NACK message) to the RAN node 5.

[0196] Alternatively, the UE 3 may indicate that failure to successfully receive / detect SCell SSB transmission using an 'On-demand SSB Failure' indication sent to the RAN node 5 by the UE 3 via appropriate RRC signalling. The appropriate signalling may be sent to the RAN node 5 over the PCell that the RAN node 5 and the UE 3 are currently communicating over.

[0197] In another example, the UE 3 may indicate its failure to acquire the on-demand SSBs via UCI or a MAC-CE transmitted to the RAN node 5 over the PCell that the RAN node 5 and the UE 3 are currently communicating over.

[0198] It will be appreciated that if the UE 3 indicates failure to successfully receive / detect SCell SSB transmission to the RAN node 5, the UE 3 may re-trigger the SCell SSB transmission request procedure at step S805 to re-attempt receiving SCell SSB transmission.

[0199] Alternatively, the UE 3 may not indicate a failure to successfully receive / detect SCell to the RAN node 5 via an explicit message such as an 'On-demand SSB Failure' indication sent to the RAN node 5 by the UE 3 via appropriate RRC signalling, but instead may simply re-trigger the SCell SSB transmission request procedure at step S805 to re-attempt receiving SCell SSB transmission when it fails to successfully receive / detect SCell to the RAN node 5.

[0200] In either scenario, where the UE 3 is configured to re-trigger the SCell SSB transmission request procedure at step S805 to re-attempt receiving SCell SSB transmission, it will be appreciated that the SCell SSB transmission request message may include appropriate information to indicate to the RAN node 5 a monitoring window for receiving the SCell SSBs. For example, the SCell SSB transmission request message sent at S806 may include an indication of the size of a specific duration / monitoring window within which to expect the on-demand SCell SSB transmission.

[0201] In the procedure described above, the SCell SSB transmission request message is always sent in response to the UE 3 receiving the SCell activation command from the RAN node 5. However, it will nevertheless be appreciated that the UE 3 may be configured to only transmit the SCell SSB transmission request message if, having received the SCell activation command at step S804, the UE 3 has not received any SCell SSB transmission for the SCell or SCells indicated in the SCell activation command within a threshold period of time. That threshold period may be hardcoded in the UE 3, or alternatively it may be configured by an RRC configuration message or the like.

[0202] Fig. 9 depicts a simplified timing diagram illustrating the procedure illustrated in Fig. 8 used by the UE 3 for determining when to trigger monitoring for on-demand SCell SSB transmission.

[0203] As shown in Fig. 9, after receiving a SSB configuration for on-demand SCell SSBs as described above with reference to step S802, the UE 3 may communicate (transmit / receive) in its PCell as normal during some arbitrary period. During that arbitrary period the UE 3 does not monitor for SCell SSB transmission. At some later time, the UE 3 may receive an SCell activation command. The SCell activation command may be included in any appropriate command message to be sent by the RAN node 5 to the UE 3, as described above with reference to step S804.

[0204] Having received the SCell activation command, the UE 3 may trigger an SCell SSB transmission request procedure to request SCell SSBs from the RAN node 5. For example, the UE 3 may transmit an appropriate request message to the RAN node 5 to request SCell SSB transmission for the SCell indicated in the SCell activation command. For example, having received the SCell activation command the UE 3 may decide to request SCell SSB transmission for the SCell (or SCells) indicated in the SCell activation command. Part of that SCell SSB transmission request procedure may include transmitting an appropriate request message to the RAN node 5 to request SCell SSB transmission for the SCell (or SCells) indicated in the SCell activation command (e.g., an SCell SSB transmission request message).

[0205] The SCell SSB transmission request message may, for example, comprise an indication indicating the UE's need for SCell SSB transmission in uplink control information (UCI) sent to the RAN node 5.

[0206] The SCell SSB transmission request message may include appropriate information to indicate to the RAN node 5 a monitoring window for receiving the SCell SSBs. For example, the SCell SSB transmission request message may include an indication of the size of a specific duration / monitoring window within which to expect the on-demand SCell SSB transmission.

[0207] In response to the SCell SSB transmission request message, the RAN node 5 may (optionally) transmit an appropriate response message to the UE 3 to confirm that the RAN node 5 has received the UE's SCell SSB transmission request message.

[0208] Having transmitted the on-demand SCell SSB transmission request message to the RAN node 5 (or optionally having received an appropriate response message to the UE 3 to confirm that the RAN node 5 has received the UE's SCell SSB transmission request message), the UE 3 triggers to monitor for SCell SSB transmission for the SCell or SCells indicated in the SCell activation command. For example, the UE 3 may trigger to monitor for SCell SSB transmission in a specific duration (e.g., in a specific monitoring window) as described above with reference to step S809. During that monitoring window, the RAN node 5 transmits SCell SSBs to the UE 3. Having successfully received the SCell SSB transmission, the UE 3 may consider the SCell activated and start normal SCell operations (e.g. PDCCH monitoring, SRS transmission, and the like).

[0209] As previously described, it will be appreciated that the UE 3 may consider the SCell activated only after it has received a specific number of SCell SSB transmission. For example, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on whether the UE 3 has performed a prior measurement of the SCell. Alternatively, or additionally, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be based on a number of receive (Rx) beams present at the UE 3.

[0210] Alternatively, the number of SCell SSB transmission required for the UE 3 to consider the SCell activated may be configured by the network. For example, the network may determine, and indicate the number of SCell SSB transmission required for the UE 3 to consider the SCell activated in any appropriate message to the UE 3. By way of example only, the network may indicate the number in an on-demand SSB configuration sent by the RAN node 5 to the UE 3. Alternatively (or additionally) the network may indicate the number in an SSB configuration sent by the RAN node 5 to the UE 3.

[0211] It will be appreciated where the UE 3 considers the SCell activated based on having received a specific number of SCell SSB transmission, the UE 3 may consider the SCell activated at some point during the monitoring window providing the specific number of SCell SSB transmission have been received i.e., before the monitoring window expires.

[0212] Following expiration of the monitoring window, the UE 3 may stop monitoring for SCell SSB transmission. Accordingly, the UE 3 may be configured such that it assumes that SCell SSBs are only transmitted in the monitoring window (i.e., not periodically transmitted) and hence the UE 3 does not need to monitor for SCell SSBs all the time.

[0213] < On-demand SCell SSB procedures for contiguous cells > 　　It will be appreciated that in all the examples described above the SCell to be activated may be contiguous to another serving cell 9 of the RAN node 5 in the same frequency band (or the two serving cells 9 may share the same SSB beams), and on-demand SSB transmission may only be supported by the serving cell 9 of the RAN node 5 that is contiguous to the SCell to be activated.

[0214] In such a scenario, the UE 3, when being triggered to monitor for SCell SSB transmission (e.g., at step S206; S406; S606; S809) may determine whether to receive / measure on-demand SSB for the given SCell indicated in the SCell activation and / or the indication for SCell on-demand SSB transmission based on whether UE 3 is synchronised with the contiguous serving cell 9.

[0215] < On-demand SSB procedures for non-Serving Cells > 　　In all the procedures described above with reference to Figs. 2 to 9, the RAN node 5 and UE 3 communicate over a serving cell 9 that may comprise a PCell and several SCells. The procedures described above outline methods of obtaining on-demand SCell SSB transmission for the SCells of the serving cell 9 over which the RAN node 5 and UE 3 communicate.

[0216] However, it will nevertheless be appreciated that in certain cases, the UE 3 may need to perform Radio Resource Management (RRM) measurements of a cell 9 which is not yet configured as a serving cell 9 to the UE 3. For example, before configuring a cell as serving cell 9 to UE 3, RAN node 5 may need to determine its suitability in terms of signal strength. Hence, RAN node 5 may decide to configure RRM measurements of the cell 9. Additionally, or alternatively, the RAN node 5 may decide that the UE 3 needs to be provided with a specific SCell provided by a target RAN node 5Twhen the UE 3 is moving out of service of the serving cell 9 provided by the source RAN node 5S.

[0217] In that scenario, the UE 3 may need to perform Radio Resource Management (RRM) measurements to determine signal strength of a cell which is yet to be configured as a SCell by the RAN node 5. By way of example only, RRM measurements may include, but are not limited to, reference signal received power (RSRP) measurements, reference signal received quality (RSRQ) measurements, cell identify measurements, and / or channel state information (CSI) measurements (including channel quality indicator (CQI)).

[0218] Procedures for using on-demand SSBs to perform RRM measurements will now be described with reference to Figs. 10-13.

[0219] Fig. 10 depicts a simplified sequence diagram illustrating a procedure for on-demand SSB transmission to the UE 3 for RRM measurements that may be used in the communication system 1 of Fig. 1.

[0220] As shown in Fig. 10 there is provided the RAN node 5 and the UE 3 deployed in the communication system 1 of Fig. 1.

[0221] At step S1002, the RAN node 5 sends a measurement configuration message (e.g., an RRC configuration message) to the UE 3 to indicate measurements that are to be performed by the UE 3. For example, the measurement configuration message may indicate that the UE 3 is to perform intra- / inter-frequency measurements of reference signals, or the like. The measurement configuration message may include several measurement objects that indicate frequency / time locations, as well as the subcarrier spacings of the reference signals to be measured. Additionally, an SSB configuration for on-demand SSBs may also be included in the measurement objects of the measurement configuration message.

[0222] Where an SSB configuration for on-demand SSBs is provided in the measurement objects of the measurement configuration message, the SSB configuration may be provided on a per cell basis. For example, the network may provide an on-demand SSB configuration for a list of cells 9 (which may include white cells) for which SSBs are not transmitted periodically. Alternatively, the SSB configuration may be provided on a per frequency basis. For example, the SSB configuration for on-demand SSBs may be included in a SS / PBCH Block Measurement Timing Configuration (SMTC) present in the measurement objects of the measurement configuration message.

[0223] The SSB configuration for on-demand SSBs included in the measurement configuration message sent at step S1002 may include an indication to the UE 3 as to whether on-demand SSB transmission for one or more cells 9 is enabled. Specifically, for each cell 9, the RAN node 5 may indicate whether SSBs are to be transmitted: i) on-demand based on a network trigger (i.e., a trigger at the RAN node 5), and / or ii) on-demand based on the RAN node 5 receiving requests for on-demand SSBs from the UE 3.

[0224] Where the SSB configuration indicates that SSBs are to be transmitted on-demand based on a network trigger, the configuration may contain information about the time occasions where on-demand SSB is transmitted. For example, the configuration may indicate that on-demand SSB shall be transmitted only for a certain duration of time with a configured periodicity value.

[0225] Alternatively, where the SSB configuration indicates that SSBs are to be transmitted on-demand based on the RAN node 5 receiving requests for on-demand SSBs from the UE 3, the configuration may contain information on how to request on-demand SSB. For example, the configuration may include uplink resources (e.g., radio bearer / physical channel, and the like) which shall be used for transmission of request. The configuration may also contain information pertaining to the occasions where SSB monitoring shall be performed by the UE 3 after transmission of UE request.

[0226] At step S1004, the RAN node 5 may decide to trigger the UE 3 to perform RRM measurements for a non-serving cell that can be provided by the RAN node 5 based on a determined RRM event (e.g., signal quality deterioration, the need to provide specific services, and the like) e.g., if the RAN node 5 decides that it should / needs to communicate with the UE 3 over a different serving cell 9 than is currently being used. In response to determining that the RAN node 5 and the UE 3 should communicate over a new cell 9, the RAN node 5 may trigger the UE 3 to perform RRM measurements for a non-serving cell 9.

[0227] At step S1006, the RAN node 5 may transmit an appropriate command message (e.g., a measurement command) to trigger the UE 3 to begin RRM measurements for the non-serving cell 9 that can be provided by the RAN node 5.

[0228] At step S1008, the UE 3, having received the appropriate command message, may begin performing RRM measurements. For example, the UE 3 may monitor for SSB transmission from the RAN node 5 based on the on-demand SSB configuration provided to the UE 3 at step S1002. It will be appreciated that the start time at which the SSB transmission is transmitted to the UE 3 (i.e., the time at which the UE 3 should begin monitoring for on-demand SSBs) can be indicated to the UE 3 by RAN node 5 in the SSB configuration sent to the UE 3 at step S1002. Alternatively, the UE 3 may determine the time at which it should begin monitoring for on-demand SSBs based on different RRM events (e.g., the RAN node 5 may start on-demand SSB transmission when it transmits a measurement command at step S1006, or before a measurement report transmission occasion signalled by the RAN node 5 in the measurement command).

[0229] At step S1010, which may occur simultaneously with step S1008, the RAN node 5 transmits on-demand SSBs to the UE 3. If the SSB configuration sent to the UE 3 is an SSB configuration provided on a per cell basis, then the UE 3 may perform measurements using on-demand SSBs for the cells 9 indicated in the SSB configuration only. In this scenario, if the UE 3 also needs to make measurements pertaining to other cells not indicated in the SSB configuration, then the UE 3 uses legacy procedures. If on the other hand the SSB configuration sent to the UE 3 is an SSB configuration provided on a per frequency basis, then the UE 3 may perform measurements of all cells 9 in the frequency indicated using on-demand SSBs.

[0230] Once the on-demand SSBs have been transmitted by the RAN node 5 and measured by the UE 3, the UE 3 and RAN node 5 may subsequently perform any appropriate mobility procedure at S1012. For example, the UE 3 and RAN node 5 may perform a mobility procedure to switch the cell 9 on which the UE 3 and RAN node 5 communicate to the non-serving cell 9 measured by the UE 3 using the on-demand SSBs.

[0231] Fig. 11 depicts a simplified sequence diagram illustrating another procedure for on-demand SCell SSB transmission to the UE 3 for RRM measurements that may be used in the communication system 1 of Fig. 1.

[0232] As shown in Fig. 11 there is provided the RAN node 5 and the UE 3 deployed in the communication system 1 of Fig. 1.

[0233] At step S1102, the RAN node 5 sends a measurement configuration message (e.g., an RRC configuration message) to the UE 3 to indicate measurements that are to be performed by the UE 3. For example, the measurement configuration message may indicate that the UE 3 is to perform intra- / inter-frequency measurements of reference signals, or the like. The measurement configuration message may include several measurement objects that indicate frequency / time locations, as well as the subcarrier spacings of the reference signals to be measured. Additionally, an SSB configuration for on-demand SSBs may also be included in the measurement objects of the measurement configuration message.

[0234] Where an SSB configuration for on-demand SSBs is provided in the measurement objects of the measurement configuration message, the SSB configuration may be provided on a per cell basis. For example, the network may provide an on-demand SSB configuration for a list of cells 9 (which may include white cells 9) for which SSBs are not transmitted periodically. Alternatively, the SSB configuration may be provided on a per frequency basis. For example, the SSB configuration for on-demand SSBs may be included in a SMTC present in the measurement objects of the measurement configuration message.

[0235] The SSB configuration for on-demand SSBs included in the measurement configuration message sent at step S1002 include an indication to the UE 3 indicating whether on-demand SSB transmission for one or more cells 9 is enabled. Specifically, for each cell 9, the RAN node 5 may indicate whether SSBs are to be transmitted: i) on-demand based on a network trigger (i.e., a trigger at the RAN node 5), and / or ii) on-demand based on the RAN node 5 receiving requests for on-demand SSBs from the UE 3.

[0236] Where the SSB configuration indicates that SSBs are to be transmitted on-demand based on a network trigger, the configuration may contain information about the time occasions where on-demand SSB is transmitted. For example, the configuration may indicate that on-demand SSB shall be transmitted only for a certain duration of time with a configured periodicity value.

[0237] Alternatively, where the SSB configuration indicates that SSBs are to be transmitted on-demand based on the RAN node 5 receiving requests for on-demand SSBs from the UE 3, the configuration may contain information on how to request on-demand SSB. For example, the configuration may include uplink resources (e.g., radio bearer / physical channel, and the like) which shall be used for transmission of request. The configuration may also contain information pertaining to the occasions where SSB monitoring shall be performed by the UE 3 after transmission of UE request.

[0238] At step S1104 the RAN node 5 may decide to trigger the UE 3 to perform RRM measurements for a non-serving cell 9 that can be provided by the RAN node 5 based on a determined RRM event (e.g., signal quality deterioration, the need to provide specific services, and the like) e.g., if the RAN node 5 decides that it should / needs to communicate with the UE 3 over a different serving cell 9 than is currently being used. In response to determining that the RAN node 5 and UE 3 should communicate over a new cell 9, the RAN node 5 may trigger the UE 3 to perform RRM measurements for a non-serving cell 9.

[0239] At step S1106, the RAN node 5 may transmit an appropriate command message (e.g., a measurement command) to trigger the UE 3 to begin RRM measurements for the non-serving cell 9 that can be provided by the RAN node 5.

[0240] Having received the measurement command, the UE 3, at step S1107 may trigger an SSB transmission request procedure. For example, having received the measurement command the UE 3 may decide to request SSB transmission for a non-serving cell 9 indicated in the measurement command. Part of that SSB transmission request procedure may include, at step S1108, transmitting an appropriate request message to the RAN node 5 to request SSB transmission for non-serving cell 9 indicated in the measurement command (e.g., an SSB transmission request message). It will be appreciated that the initiation of transmission of an on-demand SSB request can be determined by the UE 3 based on different RRM events. The UE 3 may, for example, be triggered to send the request to the RAN node 5 immediately upon receiving the measurement command from the RAN node 5 or at some (pre)configured time before a measurement reporting transmission occasion occurs (allowing sufficient time for the SSB transmission and measurement before the measurement reporting occasion).

[0241] At step S1109, the RAN node 5, having received the request message, may begin transmitting on-demand SSBs to the UE 3. If the SSB configuration sent to the UE 3 is an SSB configuration provided on a per cell basis, then the UE 3 may perform measurements using on-demand SSBs for the cells 9 indicated in the SSB configuration only. In this scenario, if the UE 3 also needs to make measurements pertaining to other cells 9 not indicated in the SSB configuration, then the UE 3 uses legacy procedures. If on the other hand the SSB configuration sent to the UE 3 is an SSB configuration provided on a per frequency basis, then the UE 3 may perform measurements of all cells 9 in the frequency indicated using on-demand SSBs.

[0242] At step S1110, which may occur simultaneously to step S1109, the UE 3 may begin performing RRM measurements. For example, the UE 3 may monitor for SSB transmission from the RAN node 5 based on the on-demand SSB configuration provided to the UE 3 at step S1102. It will be appreciated that the start time at which the SSB transmission is transmitted to the UE 3 (i.e., the time at which the UE 3 should begin monitoring for on-demand SSBs) can be indicated to the UE 3 by RAN node 5 in the SSB configuration sent to the UE 3 at step S1102. Alternatively, the UE 3 may determine the time at which it should begin monitoring for on-demand SSBs based on different RRM events (e.g., the RAN node 5 may start on-demand SSB transmission when it transmits a measurement command at step S1106, or before a measurement report transmission occasion).

[0243] Once the on-demand SSBs have been transmitted by the RAN node 5 and measured by the UE 3, the UE 3 and RAN node 5 may subsequently perform any appropriate mobility procedure at S1112. For example, the UE 3 and RAN node 5 may perform a mobility procedure to switch the cell 9 on which the UE 3 and RAN node 5 communicate to the non-serving cell 9 measured by the UE 3 using the on-demand SSBs.

[0244] Fig. 12 depicts a simplified sequence diagram illustrating a procedure for on-demand SSB transmission to the UE 3 for RRM measurements that may be used in the communication system 1 of Fig. 1.

[0245] As shown in Fig. 12 there is provided the source RAN node 5S, the target RAN node 5T, and the UE 3 deployed in the communication system 1 of Fig. 1.

[0246] At step S1202, the source RAN node 5Ssends a measurement configuration message (e.g., an RRC configuration message) to the UE 3 to indicate to the UE 3 measurements that are to be performed by the UE 3. For example, the measurement configuration message may indicate that the UE 3 is to perform intra- / inter-frequency measurements of reference signals, or the like. The measurement configuration message may include several measurement objects that indicate frequency / time locations, as well as the subcarrier spacings of the reference signals to be measured. Additionally, an SSB configuration for on-demand SSBs may also be included in the measurement objects of the measurement configuration message.

[0247] Where an SSB configuration for on-demand SSBs is provided in the measurement objects of the measurement configuration message, the SSB configuration may be provided on a per cell basis. For example, the network may provide an on-demand SSB configuration for a list of cells 9 (which may include white cells 9) for which SSBs are not transmitted periodically. Alternatively, the SSB configuration may be provided on a per frequency basis. For example, the SSB configuration for on-demand SSBs may be included in a SMTC present in the measurement objects of the measurement configuration message.

[0248] The SSB configuration for on-demand SSBs included in the measurement configuration message sent at step S1202 include an indication to the UE 3 indicating whether on-demand SSB transmission for one or more cells 9 is enabled. Specifically, for each cell 9, the RAN node 5 may indicate whether SSBs are to be transmitted: i) on-demand based on a network trigger (i.e., a trigger at the RAN node 5), and / or ii) on-demand based on the RAN node 5 receiving requests for on-demand SSBs from the UE 3.

[0249] Where the SSB configuration indicates that SSBs are to be transmitted on-demand based on a network trigger, the configuration may contain information about the time occasions where on-demand SSB is transmitted. For example, the configuration may indicate that on-demand SSB shall be transmitted only for a certain duration of time with a configured periodicity value.

[0250] Alternatively, where the SSB configuration indicates that SSBs are to be transmitted on-demand based on the RAN node 5 receiving requests for on-demand SSBs from the UE 3, the configuration may contain information on how to request on-demand SSB. For example, the configuration may include uplink resources (e.g., radio bearer / physical channel, and the like) which shall be used for transmission of request. The configuration may also contain information pertaining to the occasions where SSB monitoring shall be performed by the UE 3 after transmission of UE request.

[0251] At step S1204, the source RAN node 5Smay decide to trigger the UE 3 to perform RRM measurements for a non-serving cell 9 that is provided by a different RAN node 5 (e.g., a target RAN node 5T) based on a determined RRM event (e.g., signal quality deterioration, the need to provide specific services, and the like) e.g., if the source RAN node 5Sdecides the UE 3 should / needs to communicate with over a different serving cell 9 that is provided by a different RAN node 5.

[0252] In response to determining that UE 3 should communicate over a new cell 9 provided by a new RAN node 5T, the source RAN node 5Smay, at step S1205, send an appropriate request message to a target RAN node 5Tthat can provide the non-serving cell 9 for the UE 3 to request on-demand SSB transmission from the target RAN node 5Tto the UE 3 to allow RRM measurements of a non-serving cells 9 of that target RAN node 5T. For example, the source RAN node 5Smay send the request message to the target RAN node 5Tvia an Xn interface between the source RAN node 5Sand target RAN node 5Tto allow inter-RAN node requests for on-demand SSB transmission for RRM measurements.

[0253] In response to the request message, the target RAN node 5Tmay optionally (not shown) send an appropriate feedback message to the source RAN node 5Sto confirm it has received the request message.

[0254] At the same time, or shortly thereafter, in response to determining that UE 3 should communicate over a new cell 9 provided by a new RAN node 5T, the source RAN node 5Smay, at step S1206, send an appropriate command message (e.g., a measurement command) to trigger the UE 3 to begin RRM measurements for the non-serving cell 9 that can be provided by the new RAN node 5T.

[0255] The source RAN node 5Smay also provide an indication of the availability of on-demand SSB transmission for RRM measurements for one or more cells 9 (which may include SCells) using cell-level signalling. For example, additional bits may be included in a paging early indication (PEI). Those additional bits may be configured such that they provide an indication of the availability of on-demand SSB transmission for RRM measurements for one or more cells 9 (which may include SCells). Alternatively, an indication of the availability of on-demand SSB transmission for RRM measurements for one or more cells 9 (which may include SCells) may be provided using group-common DCI signalling.

[0256] Beneficially, indicating the availability of on-demand SSB transmission for RRM measurements for one or more cells 9 (which may include SCells) using cell-level signalling allows the transmission of a single message from the source RAN node 5Sto all (or a group) of the UEs 3 in a cell 9.

[0257] Additionally, or alternatively, the indication of the availability of on-demand SSB transmission may also include a frequency identifier or cell identifier associated with the SSBs to be transmitted. For example, the indication may identify the frequency and / or cell on which the SSBs are to be transmitted from the target RAN node 5Tto the UE 3. Additionally, or alternatively, other appropriate information may be included to indicate the timing at which the SSB transmission will be transmitted (i.e., the time at which the UE 3 should begin monitoring for on-demand SSBs).

[0258] At step S1208, the UE 3 may begin monitoring for performing RRM measurements. For example, the UE 3 may monitor for SSB transmission from the target RAN node 5T(e.g., based on the timing provided in the PEI / DCI) and perform measurements based on the received SSBs.

[0259] At step S1210, which may occur simultaneously with step S1208, the target RAN node 5Ttransmits on-demand SSBs to the UE 3. If the SSB configuration sent to the UE 3 is an SSB configuration provided on a per cell basis, then the UE 3 may perform measurements using on-demand SSBs for the cells indicated in the SSB configuration only. In this scenario, if the UE 3 also needs to make measurements pertaining to one or more other cells 9 not indicated in the SSB configuration, then the UE 3 uses legacy procedures. If on the other hand the SSB configuration sent to the UE 3 is an SSB configuration provided on a per frequency basis, then the UE 3 may perform measurements of all cells 9 in the frequency indicated using on-demand SSBs.

[0260] Once the on-demand SSBs have been transmitted by the RAN node 5 and measured by the UE 3, the UE 3 and the RAN node 5 may subsequently perform any appropriate mobility procedure at S1212. For example, the UE 3 and the RAN node 5 may perform a mobility procedure to switch the cell 9 on which the UE 3 and the RAN node 5 communicate to the non-serving cell 9 measured by the UE 3 using the on-demand SSBs.

[0261] Fig. 13 depicts a simplified sequence diagram illustrating another procedure for on-demand SSB transmission to the UE 3 for RRM measurements that may be used in the communication system 1 of Fig. 1.

[0262] As shown in Fig. 13 there is provided the source RAN node 5S, the target RAN node 5T, and the UE 3 deployed in the communication system 1 of Fig. 1.

[0263] At step S1302, the source RAN node 5Ssends a measurement configuration message (e.g., an RRC configuration message) to the UE 3 to indicate to the UE 3 measurements that are to be performed by the UE 3. For example, the measurement configuration message may indicate that the UE 3 is to perform intra- / inter-frequency measurements of reference signals, or the like. The measurement configuration message may include several measurement objects that indicate frequency / time locations, as well as the subcarrier spacings of the reference signals to be measured. Additionally, an SSB configuration for on-demand SSBs may also be included in the measurement objects of the measurement configuration message.

[0264] Where an SSB configuration for on-demand SSBs is provided in the measurement objects of the measurement configuration message, the SSB configuration may be provided on a per cell basis. For example, the network may provide an on-demand SSB configuration for a list of cells (which may include white cells) for which SSBs are not transmitted periodically. Alternatively, the SSB configuration may be provided on a per frequency basis. For example, the SSB configuration for on-demand SSBs may be included in a SMTC present in the measurement objects of the measurement configuration message.

[0265] The SSB configuration for on-demand SSBs included in the measurement configuration message sent at step S1302 may include an indication to the UE 3 indicating whether on-demand SSB transmission for one or more cells 9 is enabled. Specifically, for each cell 9, the RAN node 5 may indicate whether SSBs are to be transmitted: i) on-demand based on a network trigger (i.e., a trigger at the RAN node 5), and / or ii) on-demand based on the RAN node 5 receiving requests for on-demand SSBs from the UE 3.

[0266] Where the SSB configuration indicates that SSBs are to be transmitted on-demand based on a network trigger, the configuration may contain information about the time occasions where on-demand SSB is transmitted. For example, the configuration may indicate that on-demand SSB shall be transmitted only for a certain duration of time with a configured periodicity value.

[0267] Alternatively, where the SSB configuration indicates that SSBs are to be transmitted on-demand based on the RAN node 5 receiving requests for on-demand SSBs from the UE 3, the configuration may contain information on how to request on-demand SSB. For example, the configuration may include uplink resources (e.g., radio bearer / physical channel, and the like) which shall be used for transmission of request. The configuration may also contain information pertaining to the occasions where SSB monitoring shall be performed by the UE 3 after transmission of UE request.

[0268] At step S1304 the UE 3 may trigger an SSB transmission request procedure. This may occur, for example, following receipt of a measurement command from the RAN node 5.

[0269] This may happen, for example, if the source RAN node 5Sdecides to trigger the UE 3 to perform RRM measurements for a non-serving cell 9 that can be provided by another 'target' RAN node 5Tbased on a determined RRM event (e.g., signal quality deterioration, the need to provide specific services, and the like) e.g., if the source RAN node 5Sdecides that the UE 3 may need to communicate via a different serving cell 9 than is currently being used. In response to determining that the UE 3 should communicate over a new cell 9, the source RAN node 5Smay trigger the UE 3 to perform RRM measurements for a non-serving cell 9. The source RAN node 5Smay therefore transmit a measurement command to the UE 3 to trigger associated RRM measurements for the non-serving cell 9 that can be provided by the target RAN node 5T.

[0270] The UE 3 may thus decide to request SSB transmission for the non-serving cell 9 indicated in the measurement command by sending, at step S1306, an appropriate request message to the source RAN node 5Sto indicate to the source RAN node 5Sthat it requires appropriate SSB transmission to be able to perform RRM measurements.

[0271] In response to the request message, the source RAN node 5Smay send, at S1307, an appropriate request message to the target RAN node 5T. That request message may similarly also indicate that the UE 3 wishes to switch to a non-serving cell 9 and that the UE 3 requires appropriate SSB transmission to be able to perform RRM measurements. For example, the source RAN node 5Smay send the request message to the target RAN node 5Tvia an Xn interface between the source RAN node 5Sand target RAN node 5Tto allow inter-RAN node requests for on-demand SSB transmission for RRM measurements.

[0272] In response to the request message, the target RAN node 5Tmay optionally (not shown) send an appropriate feedback message to the source RAN node 5Sto confirm it has received the request message.

[0273] The source RAN node 5Smay also provide an indication of the availability of on-demand SSB transmission for RRM measurements for one or more cells 9 (which may include SCells) using cell-level signalling. For example, additional bits may be included in a paging early indication (PEI). Those additional bits may be configured such that they provide an indication of the availability of on-demand SSB transmission for RRM measurements for one or more cells 9 (which may include SCells). Alternatively, an indication of the availability of on-demand SSB transmission for RRM measurements for one or more cells 9 (which may include SCells) may be provided using group-common DCI signalling.

[0274] At the same time, or shortly thereafter, the UE 3 may, at step S1308, begin monitoring for performing RRM measurements. For example, the UE 3 may monitor for SSB transmission from the target RAN node 5T(e.g., based on the timing provided in the PEI / DCI) and perform measurements based on the received SSBs.

[0275] At step S1310, which may occur simultaneously with step S1308, the target RAN node 5Ttransmits on-demand SSBs to the UE 3. If the SSB configuration sent to the UE 3 is an SSB configuration provided on a per cell basis, then the UE 3 may perform measurements using on-demand SSBs for the cells 9 indicated in the SSB configuration only. In this scenario, if the UE 3 also needs to make measurements pertaining to other cells 9 not indicated in the SSB configuration, then the UE 3 uses legacy procedures. If on the other hand the SSB configuration sent to the UE 3 is an SSB configuration provided on a per frequency basis, then the UE 3 may perform measurements of all cells 9 in the frequency indicated using on-demand SSBs.

[0276] Once the on-demand SSBs have been transmitted by the target RAN node 5Tand measured by the UE 3, the UE 3 and target RAN node 5Tmay subsequently perform any appropriate mobility procedure at S1312. For example, the UE 3 and target RAN node 5Tmay perform a mobility procedure to switch the cell 9 on which the UE 3 communicates on to a serving cell 9 of the target RAN node 5Tusing the on-demand SSBs.

[0277] < Devices of the Communication System > 　　< User Equipment > 　　Fig. 14 is a simplified block schematic illustrating the main components of the UE 3 for implementation in the communication system 1 of Fig. 1.

[0278] As shown, the UE 3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from the 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 (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.

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

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

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

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

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

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

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

[0286] The communication control module 63 is operable to control the communication between the RAN node 5 and the 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 physical uplink control channel (PUCCH), a random-access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 63 is also configured for the overall control of the transmission of downlink communications via associated downlink channels (e.g., via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-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.

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

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

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

[0290] For example, it will be appreciated that whilst the procedures described above with reference to Figs. 2-9 relate to on-demand SSB transmission for SCells when the UE 3 is in an RRC connected mode, the same or similar procedures may also be used for on-demand SSB transmission on a PCell when the UE 3 is trying to access the PCell cell from an idle mode when no non-access stratum (NAS) signalling connection exists between the UE 3 and the network.

[0291] By way of example only, the UE 3, when in an RRC idle mode, may be enabled to periodically become available for downlink broadcast paging without the need for a connection to a specific RAN node 5, thereby allowing the UE 3 to save battery power because the UE 3 only scans the downlink at discrete intervals. That downlink broadcast paging may take the form of an appropriate message or messages (e.g., on-demand SSB transmission) that allow the UE 3 perform measurements of cells 9 in the vicinity of the UE 3, and where appropriate undertake a cell (re-)selection procedure to camp onto and access a cell 9 to support communication with the network.

[0292] For example, it will be appreciated that whilst the procedures described above with reference to Figs. 2-9 relate to on-demand SSB transmission for SCells, the same or similar procedures may also be used for on-demand CSI-RS transmission for SCells which may be required by the UE 3 for measurement or synchronization purposes.

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

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

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

[0296] 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 3 or RAN node 5 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 3 or the RAN node 5 in order to update their functionalities.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0310] 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 1. This list is not exhaustive and is intended to be indicative of some examples of machine type communication applications.

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

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

[0313] Although the present disclosure has been described with reference to the example embodiments, the present disclosure is not limited to the above. Various changes that can be understood by those skilled in the art can be made to the configuration and details of the present disclosure within the scope of the disclosure.

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

[0315] The program can be stored and provided to the computer device using any type of non-transitory computer readable media. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), CD-ROM (Read Only Memory), CD-R, CD-R / W, and semiconductor memories (such as mask ROM, PROM (Programmable ROM), EPROM (Erasable PROM), flash ROM, RAM (Random Access Memory), etc.). The program may be provided to the computer device using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to the computer device via a wired communication line, such as electric wires and optical fibers, or a wireless communication line.

[0316] For example, 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 terminal, the method comprising: 　　monitoring a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell transmitted on-demand, during a specific monitoring window; and 　　activating the secondary cell at the mobile terminal based on the SSB for the secondary cell, regardless of receiving information for activating the secondary cell, in a case where the mobile terminal detects the SSB for the secondary cell transmitted on-demand by the monitoring. (Supplementary note 2) 　　The method according to Supplementary note 1, further comprising: 　　receiving, from an access network node, the information for activating the secondary cell, and wherein 　　the monitoring the SSB for the secondary cell is performed after receiving the information for activating the secondary cell. (Supplementary note 3) 　　The method according to Supplementary note 2, wherein 　　the receiving the information for activating the secondary cell is performed during the monitoring window or outside the monitoring window. (Supplementary note 4) 　　The method according to Supplementary note 2 or 3, further comprising: 　　receiving, from the access network node, information indicating that the SSB for the secondary cell shall be transmitted, on or after the receiving the information for activating the secondary cell. (Supplementary note 5) 　　The method according to Supplementary note 4, wherein 　　the information indicating that the SSB for the secondary cell shall be transmitted is transmitted by at least one of: 　　　　a Medium Access Control Control Element (MAC-CE), 　　　　downlink control information (DCI), or 　　　　group common DCI. (Supplementary note 6) 　　The method according to Supplementary note 2, further comprising: 　　receiving, from the access network node, information indicating that the SSB for the secondary cell shall be transmitted, before the receiving the information for activating the secondary cell. (Supplementary note 7) 　　The method according to Supplementary note 2, further comprising: 　　transmitting, to the access network node, information for requesting the SSB for the secondary cell, in a case where the mobile terminal has not received the SSB for the secondary cell, and wherein 　　the monitoring the SSB for the secondary cell is performed after the transmitting the information for requesting the SSB for the secondary cell. (Supplementary note 8) 　　The method according to Supplementary note 7, wherein 　　the transmitting the information for requesting the SSB for the secondary cell is performed upon at least one of: 　　　　a time alignment expiry, or 　　　　losing synchronization. (Supplementary note 9) 　　The method according to any one of Supplementary notes 2 to 8, wherein 　　the monitoring window is configured by at least one of: 　　　　the information for activating the secondary cell, 　　　　a Radio Resource Control (RRC) message, 　　　　configuration information for the SSB for the secondary cell. (Supplementary note 10) 　　The method according to any one of Supplementary notes 1 to 9, wherein 　　the activating the secondary cell is performed in a case where the receiving a specific number of SSBs for the secondary cell is performed. (Supplementary note 11) 　　The method according to Supplementary note 10, wherein 　　the specific number is configured by: 　　　　the mobile terminal, or 　　　　configuration information for the secondary cell or for the SSB for the secondary cell. (Supplementary note 12) 　　The method according to any one of Supplementary notes 1 to 11, further comprising: 　　determining to fail to detect the SSB for the secondary cell during the monitoring window; and 　　transmitting, on a primary cell, information indicating failure of the receiving the SSB for the secondary cell. (Supplementary note 13) 　　The method according to Supplementary note 12, wherein 　　the information indicating the failure is transmitted by at least one of: 　　　　a Radio Resource Control message, 　　　　a Medium Access Control Control Element (MAC-CE), or 　　　　uplink control information (UCI). (Supplementary note 14) 　　The method according to any one of Supplementary notes 1 to 13, further comprising: 　　determining to fail to detect the SSB for the secondary cell during the monitoring window; and 　　transmitting, on a primary cell, information for requesting the SSB for the secondary cell based on the determining. (Supplementary note 15) 　　The method according to Supplementary note 14, wherein 　　the information for requesting the SSB is transmitted by at least one of: 　　　　a wake up signal, 　　　　a physical random access channel (PRACH), or 　　　　a scheduling request. (Supplementary note 16) 　　The method according to any one of Supplementary notes 1 to 15, further comprising: 　　receiving configuration information for receiving SSB for cells for radio resource management (RRM) measurements, and wherein 　　the receiving the SSB for the secondary cell is performed based on the configuration information for the SSB for the cells for RRM measurements. (Supplementary note 17) 　　The method according to Supplementary note 16, wherein 　　the configuration information includes information per cell or per frequency. (Supplementary note 18) 　　The method according to Supplementary note 16 or 17, wherein 　　the configuration information includes at least one of: 　　　　information indicating time occasions where the SSB for the secondary cell is transmitted on-demand, 　　　　information indicating how to request for the SSB for the secondary cell which is transmitted on-demand. (Supplementary note 19) 　　The method according to any one of Supplementary notes 16 to 18, wherein 　　the monitoring is triggered by the configuration information for receiving the SSB for cells for RRM measurements. (Supplementary note 20) 　　The method according to Supplementary note 1, wherein 　　the monitoring is triggered by a radio resource monitoring (RRM) event. (Supplementary note 21) 　　The method according to Supplementary note 7 or 8, wherein 　　the requesting the SSB for the secondary cell is triggered by a radio resource monitoring (RRM) event. (Supplementary note 22) 　　The method according to any one of Supplementary notes 1 to 21, wherein 　　an access network node which serves the mobile terminal transmits a request to a further access network node to transmit the SSB for the secondary cell for radio resource management, and 　　the SSB for the secondary cell is transmitted from the further access network node. (Supplementary note 23) 　　A method performed by a mobile terminal, the method comprising: 　　performing measurements for a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell; 　　receiving information for activating the secondary cell; and 　　activating the secondary cell in a case where the mobile terminal maintains information for the measurements for the SSB for the secondary cell and the mobile terminal synchronizes with the secondary cell, without monitoring the SSB for the secondary cell transmitted on-demand. (Supplementary note 24) 　　A method performed by a mobile terminal, the method comprising: 　　receiving information for activating a secondary cell; and 　　determining whether to monitor a synchronization signal / physical broadcast channel (PBCH) block (SSB) for another cell which is contiguous to the secondary cell or shares SSB beams with the secondary cell, based on whether the mobile terminal synchronizes with the another cell. (Supplementary note 25) 　　A method performed by an access network node, the method comprising: 　　transmitting a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell on-demand, during a specific monitoring window of a mobile terminal, wherein 　　the secondary cell is activated by the mobile terminal based on the SSB for the secondary cell, regardless of transmitting information for activating the secondary cell, in a case where the mobile terminal detects the SSB for the secondary cell transmitted on-demand. (Supplementary note 26) 　　A method performed by an access network node, the method comprising: 　　transmitting a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell, for measurements by a mobile terminal; and 　　transmitting information for activating the secondary cell, wherein 　　the secondary cell is activated by the mobile terminal in a case where the mobile terminal maintains information for the measurements for the SSB for the secondary cell and the mobile terminal synchronizes with the secondary cell, without monitoring, by the mobile terminal, the SSB for the secondary cell transmitted on-demand. (Supplementary note 27) 　　A mobile terminal comprising: 　　means for monitoring a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell transmitted on-demand, during a specific monitoring window; and 　　means for activating the secondary cell at the mobile terminal based on the SSB for the secondary cell, regardless of receiving information for activating the secondary cell, in a case where the mobile terminal detects the SSB for the secondary cell transmitted on-demand by the monitoring. (Supplementary note 28) 　　A mobile terminal comprising: 　　means for performing measurements for a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell; and 　　means for receiving information for activating the secondary cell; and 　　means for activating the secondary cell in a case where the mobile terminal maintains information for the measurements for the SSB for the secondary cell and the mobile terminal synchronizes with the secondary cell, without monitoring the SSB for the secondary cell transmitted on-demand. (Supplementary note 29) 　　A mobile terminal comprising: 　　means for receiving information for activating a secondary cell; and 　　means for determining whether to monitor a synchronization signal / physical broadcast channel (PBCH) block (SSB) for another cell which is contiguous to the secondary cell or shares SSB beams with the secondary cell, based on whether the mobile terminal synchronizes with the another cell. (Supplementary note 30) 　　An access network node comprising: 　　means for transmitting a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell on-demand, during a specific monitoring window of a mobile terminal, wherein 　　the secondary cell is activated by the mobile terminal based on the SSB for the secondary cell, regardless of transmitting information for activating the secondary cell, in a case where the mobile terminal detects the SSB for the secondary cell transmitted on-demand. (Supplementary note 31) 　　An access network node comprising: 　　means for transmitting a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell, for measurements by a mobile terminal; and 　　means for transmitting information for activating the secondary cell, wherein 　　the secondary cell is activated by the mobile terminal in a case where the mobile terminal maintains information for the measurements for the SSB for the secondary cell and the mobile terminal synchronizes with the secondary cell, without monitoring, by the mobile terminal, the SSB for the secondary cell transmitted on-demand.

[0317] 1　　communication system 3　　UEs 5　　radio access network (RAN) node 5S　　source RAN node 5T　　target RAN node 7　　core network 9　　cells 10　　control plane functions (CPFs) 10-1　　Access and Mobility Management Functions (AMFs) 10-2　　session management function (SMF) 11　　user plane functions (UPFs) 20　　external data network 31, 51　　transceiver circuit 33, 53　　antenna 35　　user interface 37, 57　　controller 39, 59　　memory 41, 61　　operating system 43, 63　　communications control module 55　　core network interface

Claims

1. A method performed by a mobile terminal, the method comprising: 　　monitoring a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell transmitted on-demand, during a specific monitoring window; and 　　activating the secondary cell at the mobile terminal based on the SSB for the secondary cell, regardless of receiving information for activating the secondary cell, in a case where the mobile terminal detects the SSB for the secondary cell transmitted on-demand by the monitoring.

2. The method according to claim 1, further comprising: 　　receiving, from an access network node, the information for activating the secondary cell, and wherein 　　the monitoring the SSB for the secondary cell is performed after receiving the information for activating the secondary cell.

3. The method according to claim 2, wherein 　　the receiving the information for activating the secondary cell is performed during the monitoring window or outside the monitoring window.

4. The method according to claim 2 or 3, further comprising: 　　receiving, from the access network node, information indicating that the SSB for the secondary cell shall be transmitted, on or after the receiving the information for activating the secondary cell.

5. The method according to claim 4, wherein 　　the information indicating that the SSB for the secondary cell shall be transmitted is transmitted by at least one of: 　　　　a Medium Access Control Control Element (MAC-CE), 　　　　downlink control information (DCI), or 　　　　group common DCI.

6. The method according to claim 2, further comprising: 　　receiving, from the access network node, information indicating that the SSB for the secondary cell shall be transmitted, before the receiving the information for activating the secondary cell.

7. The method according to claim 2, further comprising: 　　transmitting, to the access network node, information for requesting the SSB for the secondary cell, in a case where the mobile terminal has not received the SSB for the secondary cell, and wherein 　　the monitoring the SSB for the secondary cell is performed after the transmitting the information for requesting the SSB for the secondary cell.

8. The method according to claim 7, wherein 　　the transmitting the information for requesting the SSB for the secondary cell is performed upon at least one of: 　　　　a time alignment expiry, or 　　　　losing synchronization.

9. The method according to any one of claims 2 to 8, wherein 　　the monitoring window is configured by at least one of: 　　　　the information for activating the secondary cell, 　　　　a Radio Resource Control (RRC) message, 　　　　configuration information for the SSB for the secondary cell.

10. The method according to any one of claims 1 to 9, wherein 　　the activating the secondary cell is performed in a case where the receiving a specific number of SSBs for the secondary cell is performed.

11. The method according to claim 10, wherein 　　the specific number is configured by: 　　　　the mobile terminal, or 　　　　configuration information for the secondary cell or for the SSB for the secondary cell.

12. The method according to any one of claims 1 to 11, further comprising: 　　determining to fail to detect the SSB for the secondary cell during the monitoring window; and 　　transmitting, on a primary cell, information indicating failure of the receiving the SSB for the secondary cell.

13. The method according to claim 12, wherein 　　the information indicating the failure is transmitted by at least one of: 　　　　a Radio Resource Control message, 　　　　a Medium Access Control Control Element (MAC-CE), or 　　　　uplink control information (UCI).

14. The method according to any one of claims 1 to 13, further comprising: 　　determining to fail to detect the SSB for the secondary cell during the monitoring window; and 　　transmitting, on a primary cell, information for requesting the SSB for the secondary cell based on the determining.

15. The method according to claim 14, wherein 　　the information for requesting the SSB is transmitted by at least one of: 　　　　a wake up signal, 　　　　a physical random access channel (PRACH), or 　　　　a scheduling request.

16. The method according to any one of claims 1 to 15, further comprising: 　　receiving configuration information for receiving SSB for cells for radio resource management (RRM) measurements, and wherein 　　the receiving the SSB for the secondary cell is performed based on the configuration information for the SSB for the cells for RRM measurements.

17. The method according to claim 16, wherein 　　the configuration information includes information per cell or per frequency.

18. The method according to claim 16 or 17, wherein 　　the configuration information includes at least one of: 　　　　information indicating time occasions where the SSB for the secondary cell is transmitted on-demand, 　　　　information indicating how to request for the SSB for the secondary cell which is transmitted on-demand.

19. The method according to any one of claims 16 to 18, wherein 　　the monitoring is triggered by the configuration information for receiving the SSB for cells for RRM measurements.

20. The method according to claim 1, wherein 　　the monitoring is triggered by a radio resource monitoring (RRM) event.

21. The method according to claim 7 or 8, wherein 　　the requesting the SSB for the secondary cell is triggered by a radio resource monitoring (RRM) event.

22. The method according to any one of claims 1 to 21, wherein 　　an access network node which serves the mobile terminal transmits a request to a further access network node to transmit the SSB for the secondary cell for radio resource management, and 　　the SSB for the secondary cell is transmitted from the further access network node.

23. A method performed by a mobile terminal, the method comprising: 　　performing measurements for a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell; 　　receiving information for activating the secondary cell; and 　　activating the secondary cell in a case where the mobile terminal maintains information for the measurements for the SSB for the secondary cell and the mobile terminal synchronizes with the secondary cell, without monitoring the SSB for the secondary cell transmitted on-demand.

24. A method performed by a mobile terminal, the method comprising: 　　receiving information for activating a secondary cell; and 　　determining whether to monitor a synchronization signal / physical broadcast channel (PBCH) block (SSB) for another cell which is contiguous to the secondary cell or shares SSB beams with the secondary cell, based on whether the mobile terminal synchronizes with the another cell.

25. A method performed by an access network node, the method comprising: 　　transmitting a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell on-demand, during a specific monitoring window of a mobile terminal, wherein 　　the secondary cell is activated by the mobile terminal based on the SSB for the secondary cell, regardless of transmitting information for activating the secondary cell, in a case where the mobile terminal detects the SSB for the secondary cell transmitted on-demand.

26. A method performed by an access network node, the method comprising: 　　transmitting a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell, for measurements by a mobile terminal; and 　　transmitting information for activating the secondary cell, wherein 　　the secondary cell is activated by the mobile terminal in a case where the mobile terminal maintains information for the measurements for the SSB for the secondary cell and the mobile terminal synchronizes with the secondary cell, without monitoring, by the mobile terminal, the SSB for the secondary cell transmitted on-demand.

27. A mobile terminal comprising: 　　means for monitoring a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell transmitted on-demand, during a specific monitoring window; and 　　means for activating the secondary cell at the mobile terminal based on the SSB for the secondary cell, regardless of receiving information for activating the secondary cell, in a case where the mobile terminal detects the SSB for the secondary cell transmitted on-demand by the monitoring.

28. A mobile terminal comprising: 　　means for performing measurements for a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell; and 　　means for receiving information for activating the secondary cell; and 　　means for activating the secondary cell in a case where the mobile terminal maintains information for the measurements for the SSB for the secondary cell and the mobile terminal synchronizes with the secondary cell, without monitoring the SSB for the secondary cell transmitted on-demand.

29. A mobile terminal comprising: 　　means for receiving information for activating a secondary cell; and 　　means for determining whether to monitor a synchronization signal / physical broadcast channel (PBCH) block (SSB) for another cell which is contiguous to the secondary cell or shares SSB beams with the secondary cell, based on whether the mobile terminal synchronizes with the another cell.

30. An access network node comprising: 　　means for transmitting a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell on-demand, during a specific monitoring window of a mobile terminal, wherein 　　the secondary cell is activated by the mobile terminal based on the SSB for the secondary cell, regardless of transmitting information for activating the secondary cell, in a case where the mobile terminal detects the SSB for the secondary cell transmitted on-demand.

31. An access network node comprising: 　　means for transmitting a synchronization signal / physical broadcast channel (PBCH) block (SSB) for a secondary cell, for measurements by a mobile terminal; and 　　means for transmitting information for activating the secondary cell, wherein 　　the secondary cell is activated by the mobile terminal in a case where the mobile terminal maintains information for the measurements for the SSB for the secondary cell and the mobile terminal synchronizes with the secondary cell, without monitoring, by the mobile terminal, the SSB for the secondary cell transmitted on-demand.

Images