Method performed by user equipment, method performed by access network node, and user equipment

Abstract

A wireless communication system is described that consists of at least one RAN node, and at least one UE. In particular, herein are described means and methods of enabling and performing on-demand secondary cell (SCell) signal synchronisation blocks (SSBs), and their use in communication systems to achieve network energy savings (NESs).

Description

METHOD PERFORMED BY USER EQUIPMENT, METHOD PERFORMED BY ACCESS NETWORK NODE, AND USER EQUIPMENT

[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 on-demand secondary cell (SCell) signal synchronisation / physical broadcast channel (PBCH) blocks (SSBs) and their use in communication systems to achieve network energy savings (NESs).

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

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

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

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

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

[0007] Further, as the usage of 5G mobile communications for a wide range of different use cases increases, their complexity and energy demands are also expected to increase. With this in mind, efforts are being made to enhance network energy saving (NES) approaches that afford significant power savings in an industry standardized manner. To that end, techniques / procedures have been evaluated that have shown to bring substantial NES gains. By way of example only, such techniques / procedures may include: ●　　The adaption of transmission patterns; ●　　The use of wake-up signals (WUS) to allow devices such as UEs to enter reduced transmission / reception modes, (for example discontinuous transmission / reception modes); and ●　　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, In the case of on-demand SSB for camping onto SCells, mechanisms and procedures are yet to be devised as to how the UE and / or network devices (e.g., a base station) are to trigger on-demand SSB for camping onto SCells, as well as how a UE is to receive, process, and respond to triggers for on-demand SSB for camping onto SCells from network devices. There is therefore a need to devise appropriate mechanisms and procedures to allow for the implementation of on-demand SSB for UEs to camp onto SCells. The present specification aims to disclose apparatus and methods that at least contribute to addressing one or more of the above needs and / or issues.

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

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

[0010] In a first aspect, the present disclosure provides a method performed by a user equipment (UE), the method including: 　　receiving, from an access network node, configuration information for on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB) / channel state information (CSI) reference signal (CSI-RS) for secondary cells (SCells); and 　　configuring on-demand SSB / CSI-RS based on the configuration information. 　　In a second aspect, the present disclosure provides a method performed by an access network node, the method including: 　　transmitting, to a user equipment (UE), configuration information for on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB) / channel state information (CSI) reference signal (CSI-RS) for secondary cells (SCells), wherein 　　the configuration information is used by the UE for configuring on-demand SSB / CSI-RS. 　　In a third aspect, the present disclosure provides a user equipment (UE) including: 　　means for receiving, from an access network node, configuration information for on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB) / channel state information (CSI) reference signal (CSI-RS) for secondary cells (SCells); and 　　means for configuring on-demand SSB / CSI-RS based on the configuration information.

[0011] Examples of apparatus and methods will now be described, by way of example, with reference to the accompanying drawings.Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system.Fig. 2 illustrates a typical frame structure that may be used in the communication system of Fig. 1.Fig. 3 illustrates a typical resource grid that may be used in the communication system of Fig. 1.Fig. 4 is a simplified sequence diagram illustrating a procedure for enabling on-demand SCell SSB transmissions that may be used in the communication system 1 of Fig. 1.Fig. 5 is a simplified sequence diagram illustrating a procedure for on-demand SCell SSB transmissions to a UE that may be used in the communication system 1 of Fig. 1.Fig. 6 is a simplified sequence diagram illustrating another procedure for on-demand SCell SSB transmissions to a UE that may be used in the communication system 1 of Fig. 1.Fig. 7A is a simplified timing diagram illustrating a procedure used by the UE for determining when to trigger on-demand SCell SSB transmissions.Fig. 7B is a simplified timing diagram illustrating another procedure used by the UE for determining when to trigger on-demand SCell SSB transmissions.Fig. 7C is a simplified timing diagram illustrating yet another procedure used by the UE for determining when to trigger on-demand SCell SSB transmissions.Fig. 8 is a simplified sequence diagram illustrating yet another procedure for on-demand SCell SSB transmissions to a UE that may be used in the communication system 1 of Fig. 1.Fig. 9 is a simplified sequence diagram illustrating yet another procedure for on-demand SCell SSB transmissions to a UE that may be used in the communication system 1 of Fig. 1.Fig. 10 is a simplified timing diagram illustrating a procedure for transmitting repetitions of on-demand SCell SSB transmission requests that may be used in the communication system 1 of Fig. 1.Fig. 11 is a simplified sequence diagram illustrating yet another procedure for on-demand SCell SSB transmissions to a UE that may be used in the communication system 1 of Fig. 1.Fig. 12 is a simplified sequence diagram illustrating yet another procedure for on-demand SCell SSB transmissions to a UE that may be used in the communication system 1 of Fig. 1.Fig. 13 is a simplified block schematic illustrating the main components of a user equipment that may be used in the communication system of Fig. 1.Fig. 14 is a simplified block schematic illustrating the main components of a base station / access network node that may be used in the communication system of Fig. 1.Description of Example Embodiment

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

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

[0014] In the communication system 1, user equipments (UEs) 3-1, 3-2, and 3-3 (e.g., mobile telephones and / or other mobile or stationary devices) can communicate with each other via a radio access network (RAN) 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)).

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

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

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

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

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

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

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

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

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

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

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

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

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

[0028] 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 (e.g., a unique identifier assigned to each cell within the network that helps UEs 3 differentiate between neighbouring cells and synchronize with the correct cell.

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

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

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

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

[0033]

[0034] Fig. 3 illustrates the resource grid of a subframe shown in Fig. 2 (which may be equivalent to one or more slots). As shown in Fig. 3, the subcarrier spacing, and the number of OFDM symbols within a subframe varies depending on the numerology. A single block shown in Fig. 3 corresponds to a single RE and this is the smallest unit of the resource grid and is made up of one subcarrier in the frequency domain and one symbol in the time domain. A resource block 25 is defined only for the frequency domain and is defined as twelve consecutive subcarriers in the frequency domain in one symbol.

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

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

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

[0038] The UEs 3 may be configured to camp onto SCells using a so-called 'SSB-less' procedure, where an SSB from the PCell is used for time / frequency synchronization, layer-1 (L1) / layer-3 (L3) measurements, SCell activation procedures, and the like. However, such an SSB-less procedure is most appropriately suited to scenarios where the CA is intra-band, e.g., the PCell and the SCells operate on different frequencies within a specific frequency band such as the FR1 band (e.g., DL: 150 MHz to 7650 MHz, UL: 2300 MHz to 29250 MHz).

[0039] It will be appreciated that where the CA is inter-band, e.g., the PCell and the SCells operate on different frequencies within different frequency bands such as the FR1 band (e.g., DL: 150 MHz to 7650 MHz, UL: 2300 MHz to 29250 MHz) and FR2 band respectively (e.g., DL / UL: 28 GHz and 29 GHz) SSB-less procedures for camping onto SCells may prove difficult as the time / frequency synchronization information (and the like) associated with the PCell on FR1 may not be appropriate for the SCells on FR2. In such cases the use of dedicated SSBs for SCells (e.g., on-demand SSBs for SCells) may be beneficial to ensure appropriate SCell activation procedures and RRM measurement procedures are performed for the SCell, and that correct SCell timing synchronization is achieved.

[0040] In such scenarios each UE 3 may 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 as described above, rather than rely on SSBs associated with the PCell. Given that SCells are not typically used by 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.

[0041] 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 implements one or more mechanisms / procedures to allow a 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 a UE 3 to request, or a network device to trigger, on-demand SSBs for SCells.

[0042] On demand SSBs may, for example, be triggered due to a number of reasons including, for example: to help achieve / maintain SCell timing synchronisation; due to SCell activation; due to a need for SSB based radio resource management (RRM) measurements (e.g., in respect of a particular SCell); due to a need for lower layer triggered mobility (LTM) measurement before SCell activation (e.g., aligned with activation / deactivation of LTM candidate cells).

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

[0044] For example, on-demand SSB transmissions for a SCell may be triggerable by a RAN node 5. In such a scenario, the RAN node 5 may trigger on-demand SSB transmissions for a 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 transmissions for a SCell based on the RAN node 5 deciding to perform specific radio resource management (RRM) measurements, or the like. Having decided to trigger on-demand SSB transmissions for a 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 transmissions to the UE 3.

[0045] Beneficially, by the RAN node 5 triggering on-demand SSB transmissions for a 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 transmissions. 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.

[0046] Alternatively, or additionally, on-demand SSB transmissions for a SCell may be triggerable based on the UE 3 request. In such a scenario, the UE 3 may trigger on-demand SSB transmissions for a SCell based on the UE 3 deciding that certain internal conditions of the UE 3 have been met. For example, the UE 3 may request on-demand SSB transmissions for a SCell based on the UE 3 determining that it has lost time / frequency synchronisation with a SCell. Alternatively, or additionally, the UE 3 may request on-demand SSB transmissions for a SCell based on receiving an indication of a SCell activation from the RAN node 5, and / or based on receiving an indication / request from the RAN node 5 that certain measurements of a SCell should be performed. Having decided to request on-demand SSB transmissions for a SCell, the UE 3 may indicate that decision to the RAN node 5 via appropriate messaging, and the RAN node 5 may subsequently send one or more SSB transmissions to the UE 3.

[0047] Beneficially, by the RAN node 5 sending on-demand SSB transmissions for a SCell based on certain conditions being met or certain indication being received at the UE 3, NES can be achieved, as the RAN node 5 does not need to continuously perform SCell SSB transmissions. Instead, the UE 3 may monitor for on-demand SSBs only after it has decided that on-demand SSBs are required, and that requirement has been appropriately signalled to the RAN node 5. Further beneficially, the overall signalling overhead of the system is reduced, as SSBs associated with SCells are only transmitted when deemed necessary by the UE 3, rather than them being sent on a periodic basis.

[0048] Moreover, on-demand SSB transmissions for a SCell may be triggerable by a RAN node 5 following the expiration of a timing alignment timer (TAT). For example, on-demand SSB transmissions for a SCell may be triggered by a RAN node 5 based on the RAN node 5 determining that the UE's TAT has expired. Having determined that the UE's TAT has expired, and that UL synchronization is lost), the RAN node 5 may begin sending one or more SSB transmissions to the UE 3.

[0049] Beneficially, by allowing the RAN node 5 to send SSB transmissions for a SCell as soon as the RAN node 5 has determined that the UE's TAT has expired, the UE 3 does not need to be configured to provide signalling to the RAN node 5, once it's TAT has expired to indicate that SSB transmissions are required; rather the RAN node 5 may assume that SSB transmissions are needed and begin transmitting them. That in turn reduces the overall signalling of the system and helps to reduce the time between the expiration of the TAT and the time at which re-synchronization occurs, thereby minimizing data transmission losses and maximizing QoS.

[0050] Alternatively, or additionally, on-demand SSB transmissions for a SCell may be triggerable based on a UE request when a TAT is close to expiring. For example, on-demand SSB transmissions for a SCell may be requested by the UE 3 based on the UE 3 determining that the UE's TAT is close to expiring. Having received the request for on-demand SSB transmissions, the RAN node 5 may begin sending one or more SSB transmissions to the UE 3 prior to the expiration of the UE's TAT.

[0051] Beneficially, by triggering on-demand SSB transmissions prior to the UE's TAT expiring, the UE 3 does not have to be configured to allow the UE 3 to transmit messages post TAT expiry, i.e., once synchronization is deemed to have been lost; rather on-demand SSB transmissions are triggered prior to the TAT expiry. Further beneficially, by the on-demand SSB transmissions are triggered prior to the TAT expiry, a loss of synchronization at the expiration of the TAT is prevented. That in turn removes the need for RACH procedures to be performed to re-synchronize, thereby reducing overall signalling within the system, and ensuring continuous synchronization. That in turn beneficially minimizes data transmission losses and maximizes QoS.

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

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

[0054] On-demand SCell SSB procedures 　　Network Configuration for On Demand SSB 　　Fig. 4 is a simplified sequence diagram illustrating a procedure that may be used in the communication system 1 of Fig. 1 for indicating whether on-demand SSB transmissions for a given SCell is enabled.

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

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

[0057] 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 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 information element (IE) provided in a SIB1 message, or the like. As way of example only, the ServingCellConfigCommon IE may include the following parameters for SSB synchronisation: ssb-PositionsInBurst, ssb-periodicityServingCell, ssbSubcarrierSpacing, ss-PBCH-BlockPower which are described above.

[0058] The SSB configuration may also indicate additional appropriate information needed to facilitate on-demand SSB transmission occasions. For example, along with the 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 serving cell configuration or measurement object configuration may also include information on the periodicity of such on-demand SSB transmissions, and / or how long on-demand SSB transmissions 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 transmissions, or alternatively it may indicate a count of SSB periods (e.g., 5 periods of SSB transmissions) for the duration of on-demand SSB transmissions. Where the RAN node 5 indicates to the UE 3 that transmission of on-demand SSBs for one or more SCells is enabled within a serving cell configuration, an updated SSB configuration for the on-demand SSBs associated with the current serving cell being used to communicate between the RAN node 5 and the UE 3 may be provided. For example, where the RAN node 5 and the UE 3 are configured to communicate using a PCell and several SCells, the SSB configuration for an SCell for which on-demand SSBs are enabled may be updated and / or reconfigured. Nevertheless, the SSB configuration for an SCell for which on-demand SSBs are enabled (or at least part of that SSB configuration) may be the same as for an existing special cell (SpCell) that is effectively a combination of a PCell and a primary secondary cell (PSCell) - or may be the same as for another existing serving cell.

[0059] In the scenario where the SSB configuration is the same as that of an SpCell (or another serving cell) that is already configured for the UE 3, this can be indicated by the RAN node 5 to the UE 3 via a 1-bit field (or, possibly, via a ServCellIndex or SCellIndex IE in an activation / deactivation MAC control element (CE)). This beneficially reduces signaling overhead as the RAN node 5 need not send a whole new serving cell configuration to the UE 3 but may instead identify a pre-existing configuration of which the UE 3 is aware and able to communicate over.

[0060] It will be appreciated that whilst the serving cell may be configurable to provide the indication and associated SSB configuration as described above, a measurement object sent by the RAN node 5 to the UE 3 may alternatively or additionally be configurable to provide the indication and SSB configuration. A measurement object configuration (e.g., a radio resource management (RRM) measurement configuration) is typically used for setting up parameters and procedures for the measurement of various radio-related quantities, such as signal strength, quality, and interference. Such a configuration typically includes a measObject IE which identifies what parameter is to be measured, a ReportConfig IE which defines how and when the measurement results should be reported, and a measObjectID IE which provides a unique identifier used to link measurement configurations with specific measurement instances and reports. The ReportConfig IE may contain a resource type indicator (e.g., rsType) which may be set to 'SSB' to indicate that the UE 3 should perform measurements based on an SSB. Additionally, the configuration may contain a servingCellMO IE that provides similar information to that provided in the ServingCellConfigCommon IE described above but may also include additional information such as an SSB measurement timing configuration (SMTC) which can be used by the UE 3 for fast SSB discovery.

[0061] RAN node triggered on-demand SCell SSB 　　One way in which RAN node triggered on-demand SCell SSB transmissions may be implemented will now be described in more detail, by way of example only, with reference to Fig. 5.

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

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

[0064] Prior to the procedure illustrated in Fig. 5, the network may indicate whether on-demand SSB transmissions for a given SCell is enabled as described above with reference to Fig. 4.

[0065] At step S504, on-demand SSB transmissions for one or more SCells is triggered at the RAN node 5.

[0066] 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 a 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 SCell for use with the UE 3 when specific services are required that are only supported by a SCell. In these scenarios, the UE 3 does not need to send a request message to the RAN node 5 to trigger on-demand SSB transmissions for a SCell, rather the RAN node 5 may initiate 'on-demand' SSB transmission for an SCell of its own volition.

[0067] On-demand SSB transmissions for an SCell may (alternatively or additionally) be triggered at the RAN node 5 when (periodic) SSB based radio resource management (RRM) measurements and / or SSB based lower layer triggered mobility (LTM) measurements are required for the SCell. By way of example only, RRM / LTM 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)). In this scenario, the UE 3 also does not need to send a request message to the RAN node 5 to trigger on-demand SSB transmissions for an SCell, rather the RAN node 5 may initiate 'on-demand' SSB transmission for an SCell. When on-demand SSB transmissions for one or more SCells have been triggered, the RAN node 5 transmits, at step S506, an indication for on-demand SSB for the one or more SCells to the UE 3. The indication for on-demand SSB for a 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 transmissions for the SCell.

[0068] The indication for on-demand SSB for the SCell may be included in any appropriate command message to be sent by the RAN node 5 to the UE 3. For example, the indication may be provided within an SCell activation message sent by the RAN node 5 to the UE 3 to activate a SCell. The SCell activation message (also known as an SCell activation command) may be sent from the RAN node 5 to the UE 3 via a dedicated MAC information element (IE) on the PDSCH. Alternatively, for on-demand SSB for the SCell, the indication may be provided within an RRM / LTM measurement configuration / command for configuring the UE 3 to perform RRM / LTM measurements, e.g., any appropriate measurement configuration / command message sent by the RAN node 5 to the UE 3 that triggers the UE 3 to perform RRM or LTM measurements such as those previously described.

[0069] The indication for on-demand SSB for the SCell sent to the UE 3 at step S504 may, nevertheless, be sent in any other appropriate type of (dedicated) message sent to the UE 3 by the RAN node 5. That other appropriate type of message may be sent to the UE 3, for example, either before or after the transmission of an SCell activation message (or RRM / LTM measurement configuration / command) to the UE 3. By way of example only, an indication for on-demand SSB for the SCell may be sent to the UE 3 in a new medium access control (MAC) control element (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 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 hybrid automatic repeat request (HARQ) acknowledgement / negative acknowledgement (ACK / NACK) procedure associated with the MAC CE transmission.

[0070] 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 a SCell is activated. Alternatively, the UE 3 may always monitor for the new DCI message regardless of whether a SCell is activated or deactivated (i.e., at all times).

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

[0072] In another example, the indication for on-demand SSB for the SCell may be sent to the UE 3 in any appropriate RRC message during an RRC procedure.

[0073] Whether the indication is sent in a MAC CE, a DCI or an RRC 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.

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

[0075] 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, a DCI or an RRC 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.

[0076] Whether the indication is sent in a MAC CE, a DCI or an RRC 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 the SSBs are to be transmitted over by the RAN node 5 based on the serving cell 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.

[0077] It will be appreciated that, whilst an explicit indication for on-demand SSB for the SCell is sent to the UE 3 at step S506 in a specific message, it is possible that an explicit indication is not used but rather that initiation of on-demand SSB transmission for the SCell may be indicated to the UE 3 implicitly. For example, after receiving an appropriate trigger to perform SSB measurements (e.g., SCell activation command, RRM / LTM measurement configuration / command, and / or a link recovery request) the UE 3 may assume that SSB transmissions shall be performed for at least some predetermined duration by the RAN node 5.

[0078] At step S508, the RAN node 5 transmits SCell SSB transmissions to the UE 3. Those SSB transmissions may be aperiodic transmissions or semi-persistent transmissions.

[0079] UE requested on-demand SCell SSB 　　One way in which UE requested on-demand SCell SSB transmissions may be implemented will now be described in more detail, by way of example only, with reference to Fig. 6.

[0080] Prior to the procedure illustrated in Fig. 6, the network may indicate whether on-demand SSB transmissions for a given SCell is enabled as described above with reference to Fig. 4.

[0081] Fig. 6 is a simplified sequence diagram illustrating a procedure for UE-requested on-demand SCell SSB transmissions that may be used in the communication system 1 of Fig. 1.

[0082] 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. At step S602 a requirement for on-demand SCell SSB transmissions is triggered at the UE 3 based on one or more internal conditions of the UE 3 (S602a). For example, a requirement for on-demand SSB for an SCell may be triggered at the UE 3 if the SCell is active when a requirement for on-demand SSB is detected (e.g., due to one or more UE internal conditions not being met / one or more criteria for triggering on-demand SSBs being met). It will be appreciated, for example, that UE internal conditions that may not be met may include any appropriate internal condition of the UE 3. By way of example only, such conditions may include time / frequency synchronization requirements, best downlink (DL) beam selection / update requirements, and / or specific automatic gain control (AGC) setting requirements.

[0083] By way of example only, a requirement for on-demand SCell SSB transmissions may be triggered at the UE 3 based on the UE 3 determining that time synchronisation is required (or that the UE 3 has lost time / frequency synchronisation with an SCell, i.e., time / frequency synchronization requirements are not met). In such scenarios, the trigger for on-demand SCell SSB transmissions may be defined in one of several ways which will be described now in more detail with reference to Figs. 7A-7C.

[0084] Fig. 7A is a simplified timing diagram illustrating a procedure used by the UE 3 for determining when to trigger on-demand SCell SSB transmissions.

[0085] As shown in Fig. 7A, after receiving an SSB in an on-demand SSB enabled SCell the UE 3 may communicate (transmit / receive) in the SCell as normal during some arbitrary period. During that period, the UE 3 may perform internal monitoring procedures to monitor whether the UE 3 remains in synchronisation with the SCell with which it is in communication. Upon detecting that it is no longer synchronised with the SCell, the UE 3 may decide that synchronisation is required and thus subsequently sends an on-demand SCell SSB transmission request message to the RAN node 5. At some later time, the UE 3 may receive one or more SSB transmission (i.e., sent by the RAN Node 5 in response to the request message) to assist with SCell re-synchronisation. Upon receipt of the SSB transmission from the RAN node 5, the UE 3 once again begins to perform internal monitoring procedures to monitor whether the UE 3 remains in synchronisation with the SCell with which it is in communication.

[0086] In another example, an SSB re-synchronisation timer may be used to determine when the UE 3 is to trigger on-demand SCell SSB transmissions.

[0087] Fig. 7B is a simplified timing diagram illustrating another procedure used by the UE 3 for determining when to trigger on-demand SCell SSB transmissions.

[0088] As shown in Fig. 7B, an SSB re-synchronisation timer may be (re)started whenever the UE 3 measures and / or detects an SCell SSB transmission from the RAN node 5. That re-synchronisation timer may run for a pre-configured period of time. For example, the UE 3 may be hardcoded to run the timer for a specified pre-configured period of time. Alternatively, the duration of the timer's runtime may be configured by the RAN node 5 during an appropriate configuration procedure with the UE 3, e.g., during a RRC re(configuration) procedure. While the SSB re-synchronisation timer is running, the UE 3 may also receive or transmit other signals. Upon expiration of the SSB re-synchronisation timer, the UE 3 may trigger on-demand SCell SSB transmissions whether time / frequency synchronisation with the SCell has been lost or not if no subsequent SSB transmission has been received.

[0089] At some later time, the UE 3, in response to sending the request message to the RAN node 5, may receive one or more SSB transmissions as requested to assist with SCell re-synchronisation. Upon receipt of the SSB transmission from the RAN node 5, the UE 3 sets the SSB re-synchronisation timer running again.

[0090] It will be appreciated that where the duration of the timer's runtime is configured by the RAN node 5 during an appropriate configuration procedure with the UE 3, e.g., during a RRC re(configuration) procedure, the UE 3 may provide the RAN node 5 with UE assistance (capability) information (UAI) during the RRC procedure that indicates a recommended value of the timer duration. In turn the RAN node 5 may use that recommended value of the timer duration to appropriately configure the timer value duration. It will be appreciated that the exchange of such UAI may occur on a static basis, e.g., when the UE 3 first becomes connected to the cell.

[0091] Fig. 7C is a simplified timing diagram illustrating yet another procedure used by the UE 3 for determining when to trigger on-demand SCell SSB transmissions.

[0092] As shown in Fig. 7C, an SSB non-synchronisation timer may be (re)started whenever the UE 3 measures and / or detects a SCell SSB transmission from the RAN node 5. That non-synchronisation timer may run for a pre-configured period of time. For example, the UE 3 may be hardcoded to run the timer for a specified pre-configured period of time. Alternatively, the duration of the timer's runtime may be configured by the RAN node 5 during an appropriate configuration procedure with the UE 3, e.g., during a RRC re(configuration) procedure. While the SSB non-synchronisation timer is running, the UE 3 may also receive or transmit other signals. Prior to the end of the pre-configured period of time, the UE 3 may trigger on-demand SCell SSB transmission by sending an on-demand SCell SSB transmission request message to the RAN node 5 if no subsequent SSB transmission has been received. It will be appreciated that the exact point within the pre-configured period of time that the UE 3 decides to trigger on-demand SCell SSB transmissions may be decided by the UE 3 based on one or more internal conditions of the UE 3. For example, when deciding the point within the pre-configured period of time, the UE 3 may take into consideration how long it takes for the UE 3 to detect SSB transmissions, how long it takes for the UE 3 to synchronise with SSB transmissions, and the like.

[0093] Later, if an SSB transmission has still not been received when the SSB non-synchronisation timer has expired, the UE 3 may initiate an SCell failure recovery procedure which may involve the UE 3 sending an appropriate RRC message to the RAN node 5 indicating to the RAN node 5 that the UE 3 has failed to detect an SCell SSB.

[0094] It will be appreciated that where the duration of the timer's runtime is configured by the RAN node 5 during an appropriate configuration procedure with the UE 3, e.g., during a RRC re(configuration) procedure, the UE 3 may provide the RAN node 5 with UE assistance (capability) information (UAI) during the RRC procedure that indicates a recommended value of the timer duration. In turn the RAN node 5 may use that recommended value of the timer duration to appropriately configure the timer value duration. It will be appreciated that the exchange of such UAI may occur on a static basis, e.g., when the UE 3 first becomes connected to the cell.

[0095] It will be appreciated that the request message sent at S604 to request on-demand SSB SCell transmissions may take any appropriate form that enables the request to be made to the RAN node 5. By way of example only, the request message may take the form of a new MAC CE that can carry the on-demand SCell SSB request from the UE 3 to the RAN node 5. 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). In such a scenario, the MAC CE would be assigned the highest, or second highest, relative logical channel priority amongst all other MAC CEs, i.e., the MAC CE will be below cell-radio network temporary identifier (C-RNTI) MAC CE or data from uplink-common control channel (UL-CCCH).

[0096] In another example, the request message may take the form of one or more new bits within uplink control information (UCI) sent to the RAN node 5 by the UE 3 on the physical uplink control channel (PUCCH). Those new bits may be defined in the PUCCH resources and may be used to request on-demand SCell SSB transmissions. For example, those new bits may take the form of an appropriate sequence of 1s and 0s to indicate to the RAN node 5 that on-demand SSB transmissions for a SCell is requested. It will be appreciated that where such sequences of bits in the UCI are used to indicate that on-demand SSB SCell transmissions are requested, the sequences may be hardcoded in the RAN node 5, for example there may be a mapping table provided at the RAN node 5 that maps specific sequences of those bits to specific on-demand SSB SCell requests. Alternatively, those sequences and the request they are associated with may be indicated to the RAN node 5 during an RRC procedure.

[0097] In another example, the request message may take the form of an appropriate RRC based message sent to the RAN node 5 by the UE 3. For example, the request message may take the form of a special RRC message sent during an RRC procedure between the UE 3 and the RAN node 5. A special RRC message may include, for example, a UE assistance information (UAI) message that is sent to the RAN node 5 after RRC (re)configuration.

[0098] It will be appreciated that the request message sent at S604 will be sent to the RAN node 5 over any appropriate cell that supports communication between the UE 3 and the RAN node 5. The request message may, for example, always use a PCell or a PSCell. Nevertheless, the cell to be used for sending the request message may be indicated to the UE 3 via an appropriate configuration message sent to the UE 3 by the RAN node 5 - i.e., the RAN node 5 may indicate to the UE 3 which cell it wishes to receive on-demand SSB SCell request messages. By way of example only, if the UE 3 is to send the request message using a specific configured PUCCH resource or some other appropriate scheduling request (SR) resource then the network (e.g., the RAN node 5) may indicate to the UE 3 which PUCCH resources or SR resources may be used for the transmission of the on-demand SSB SCell transmission request message. That indication of resources may be made in advance to the UE 3, for example, during an RRC (re)configuration procedure.

[0099] It will also be appreciated that where it is possible for the request message to be sent over one of multiple cells, the UE 3 may choose the specific cell to use to send the request message. For example, if the RAN node 5 indicates, to the UE 3, that multiple cells and corresponding resources are available for the transmission of the on-demand SSB SCell transmission request message, then the UE 3 may choose to use the resources, and thus corresponding cell, that are available earliest for the transmission of the request message.

[0100] The contents of the on-demand SSB SCell transmission request message (also referred herein as 'the request message') may include an indication of the number of SSBs required for the UE 3 to make desired measurements of the SCell. It will be appreciated that different scenarios may require different sets of SSB transmissions to be made to enable correct synchronization. For example, to enable radio resource management-based measurements (e.g., RSRP measurements, RSRQ measurements, cell identify measurements, CSI measurements, and the like) the UE 3 may require reception of a full set of SSBs. Meanwhile, for SCell activation procedures and / or time synchronisation, reception of a subset of SSBs may be sufficient to enable SCell activation and synchronisation.

[0101] The indication of the number of SSBs required for the UE 3 to make the desired measurements of the SCell may be encoded in the request message as a specific number of required SSBs, or alternatively it may be encoded in a dedicated 2- or 3-bit field indicating the number of required SSBs. Where the number of required SSBs is encoded in a dedicated 2- or 3-bit field, the 2- or 3-bit sequences of '1s' and '0s' may be used to indicate whether the UE 3 requires: a full set of SSB transmissions; a partial set (e.g., a subset) of SSB transmissions; or a single SSB transmission.

[0102] Alternatively, or additionally, the request message may include a field that indicates a type of request being made, and / or a reason for the request. For example, the request message may include a field that indicates that the on-demand SCell SSB transmissions are being requested so that the UE 3 can perform RRM / LTM measurements, SCell activation procedures, and / or SCell synchronization procedures. It will be appreciated that in this scenario, any appropriate field may be used in the request message to indicate the type and / or reason for the request.

[0103] The request message may also indicate to the RAN node 5 a number of repetitions of the on-demand SCell SSB transmissions that the UE 3 wishes the RAN node 5 to perform. For example, where the SSBs are transmitted using beam sweeping and / or beam forming procedures, the UE 3 may need the SSBs to be repeated at least as many times as there are Rx beams at the UE 3.

[0104] The request message may also include an SCell identifier that is used by the RAN node 5 to identify the SCell for which the on-demand SSB transmissions are being requested. The SCell identifier may be encoded explicitly in the request message (e.g., within an appropriate MAC CE) or alternatively it may be implicitly indicated to the RAN node 5. For example, the UE 3 may be configured by the RAN node 5 to transmit the request message over a specific set of resources for different serving cells, and each resource of the specific set of resources may be associated with a corresponding SCell by the RAN node 5. Hence, the RAN node 5 may imply which SCell a request message from the UE 3 is associated with, based on the specific resource used to transmit it to the RAN node 5.

[0105] At step S606, RAN node 5 may send an appropriate response message to the UE 3 to confirm that the RAN node 5 received the on-demand SSB request message sent at step S604, and to indicate to the UE 3 that the RAN node 5 will perform the requested on-demand SSB SCell transmissions. For example, the response message 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 response message, 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 (ACK) / negative acknowledgment (NACK) procedure associated with the MAC CE transmission.

[0106] In another example, the response message 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 only monitor for the new DCI message when the on-demand SCell SSB transmission request message has been initiated and triggered by the UE 3. Alternatively, the UE 3 may always monitor for the new DCI message when a SCell is activated. Alternatively, the UE 3 may always monitor for the new DCI message regardless of whether a SCell is activated or deactivated (i.e., at all times).

[0107] In the scenario where the response message 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). Alternatively, the DCI message may be transmitted over the same cell that the UE 3 sent the on-demand SSB SCell transmission request message to the RAN node 5. 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.

[0108] In another example, the response message may be sent to the UE 3 in any appropriate RRC message during an RRC procedure.

[0109] Whether the response message is sent in a MAC CE, a DCI or an RRC based message, it may, as well as indicating that the RAN node 5 received the-demand SSB SCell transmission request message, 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 (i.e., a number of SSBs that the UE 3 should expect to receive), 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.

[0110] Whether the response message is sent in a MAC CE, a DCI or an RRC based message, the message may also include timing information pertaining to the SSB transmissions where appropriate. For example, the message may include an indication of a starting time occasion where SSB transmissions will start. Additionally, or alternatively, it may also include an indication of a periodicity of SSB transmissions. Additionally, or alternatively, it may also include an indication of how long SSB transmissions will continue. Additionally, or alternatively, it may also include an indication as to whether SSB transmissions are to be aperiodic or semi-persistent. 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, a DCI or an RRC 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] Whether the response message is sent in a MAC CE, a DCI or an RRC 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 response message 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 over which the UE 3 receives the response message. For example, where the UE 3 receives the response message 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.

[0112] At step S608, the RAN node 5 transmits SCell SSB transmissions to the UE 3. Those SSB transmissions may be aperiodic transmissions or semi-persistent transmissions.

[0113] Another way in which UE requested on-demand SCell SSB transmissions may be implemented will now be described in more detail, by way of example only, with reference to Fig. 8.

[0114] Fig. 8 is a simplified sequence diagram illustrating a procedure for UE-requested on-demand SCell SSB transmissions that may be used in the communication system 1 of Fig. 1.

[0115] Prior to the procedure illustrated in Fig. 8, the network may indicate whether on-demand SSB transmissions for a given SCell is enabled as described above with reference to Fig. 4.

[0116] 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. At step S802, the RAN node 5 sends a SCell activation trigger message or indication to the UE 3. For example, the SCell activation trigger message or indication may be a SCell activation command sent by the RAN node 5 to the UE 3 to order the UE 3 to activate a specific SCell.

[0117] Upon reception of the SCell activation command at step S802, the UE 3, at step S804, a requirement for on-demand SCell SSB transmissions is triggered at the UE 3 for the specific SCell indicated in the SCell activation command. For example, if the UE 3 does not have time and / or frequency synchronisation with the specific SCell, and no SSB for the specific SCell is available to the UE 3 or no SSB for the specific SCell is being transmitted to the UE 3 then the UE 3 shall immediately request for SCell SSBs after receiving the SCell activation trigger at S802, as the UE 3 will be unable to initiate the SCell activation procedure (e.g., receiving PDCCH, CSI reporting, starting sCellDeactivation timer, and the like) until the UE 3 has successfully received an SSB for the SCell and acquired time and frequency synchronisation.

[0118] In the scenario where the UE 3 immediately requests SCell SSBs after receiving the SCell activation trigger as described above, the UE 3 may also need to transmit an appropriate response message to the RAN node 5 indicating the success of the SCell activation procedure once the requested SSB is successfully received and timing / frequency synchronisation has been performed.

[0119] As already described above, a requirement for on-demand SCell SSB transmissions is triggered at the UE 3 may be met following receipt of an SCell activation trigger from the RAN node 5 if the UE 3 determines that it has lost time / frequency synchronisation with the SCell indicated in the activation trigger, i.e., time / frequency synchronization requirements are not met. In such scenarios, the trigger for on-demand SCell SSB transmissions may be defined in one of several ways which have already been described in detail with reference to Figs. 7A-7C. The procedures described with reference to Figs. 7A-7C apply here equally. At step S806, the UE 3 sends an appropriate request message to the RAN node 5 to request the RAN node 5 to perform on-demand SCell SSB transmissions. That request message may contain any appropriate indication that informs the RAN node 5 that on-demand SCell SSB transmission for one or more SCells is requested. It will be appreciated that the request message sent at S806 to request on-demand SSB SCell transmissions may take any appropriate form that enables the request to be made to the RAN node 5. By way of example only, the request message may take the form of a new MAC CE that can carry the on-demand SCell SSB request from the UE 3 to the RAN node 5. Such MAC CEs are typically implemented as special bit strings within the LCID field of the MAC header of the MAC PDU. In such a scenario, the MAC CE may be assigned the highest, or second highest, relative logical channel priority amongst all other MAC CEs, i.e., the MAC CE will be below C-RNTI MAC CE or data from UL-CCCH.

[0120] In another example, the request message may take the form of one or more new bits within uplink control information (UCI) sent to the RAN node 5 by the UE 3 on the physical uplink control channel (PUCCH). Those new bits may be defined in the PUCCH resources and may be used to request on-demand SCell SSB transmissions. For example, those new bits may take the form of an appropriate sequence of 1s and 0s to indicate to the RAN node 5 that on-demand SSB transmissions for a SCell is requested. It will be appreciated that where such sequences of bits in the UCI are used to indicate that on-demand SSB SCell transmissions are requested, the sequences may be hardcoded in the RAN node 5, for example there may be a mapping table provided at the RAN node 5 that maps specific sequences of those bits to specific on-demand SSB SCell requests. Alternatively, those sequences, and the request they are associated with, may be indicated to the RAN node 5 during an RRC procedure.

[0121] In another example, the request message may take the form of an appropriate RRC based message sent to the RAN node 5 by the UE 3. For example, the request message may take the form of a special RRC message sent during an RRC procedure between the UE 3 and the RAN node 5. A special RRC message may include, for example, a UE assistance information (UAI) message that is sent to the RAN node 5 after RRC (re)configuration.

[0122] It will be appreciated that the request message sent at S806 will be sent to the RAN node 5 over any appropriate cell that supports communication between the UE 3 and the RAN node 5. The request message may, for example, always use a PCell or a PSCell. Nevertheless, the cell to be used for sending the request message may be indicated to the UE 3 via an appropriate configuration message sent to the UE 3 by the RAN node 5 - i.e., the RAN node 5 may indicate to the UE 3 which cell it wishes to receive on-demand SSB SCell request messages. By way of example only, if the UE 3 is to send the request message using a specific configured PUCCH resource or some other appropriate scheduling request (SR) resource then the network (e.g., the RAN node 5) may indicate to the UE 3 which PUCCH resources or SR resources may be used for the transmission of the on-demand SSB SCell transmission request message. That indication of resources may be made in advance to the UE 3, for example, during an RRC (re)configuration procedure.

[0123] It will also be appreciated that where it is possible for the request message to be sent over one of multiple cells, the UE 3 may choose the specific cell to use to send the request message. For example, if the RAN node 5 indicates, to the UE 3, that multiple cells and corresponding resources are available for the transmission of the on-demand SSB SCell transmission request message, then the UE 3 may choose to use the resources, and thus corresponding cell, that are available earliest for the transmission of the request message.

[0124] The contents of the on-demand SSB SCell transmission request message (also referred herein as 'the request message') may include an indication of the number of SSBs required for the UE 3 to make the desired measurements of the SCell. It will be appreciated that different scenarios may require different sets of SSB transmissions to be made to enable correct synchronization. For example, to enable radio resource management-based measurements (e.g., RSRP measurements, RSRQ measurements, cell identify measurements, CSI measurements, and the like) the UE 3 may require reception of a full set of SSBs. Meanwhile, for SCell activation procedures and / or time synchronisation, reception of a subset of SSBs may be sufficient to enable SCell activation and synchronisation.

[0125] The indication of the number of SSBs required for the UE 3 to make the desired measurements of the SCell may be encoded in the request message as a specific number of required SSBs, or alternatively it may be encoded in a dedicated 2- or 3-bit field indicating the number of required SSBs. Where the number of required SSBs is encoded in a dedicated 2- or 3-bit field, the 2- or 3-bit sequences of '1s' and '0s' may be used to indicate whether the UE 3 requires: a full set of SSB transmissions; a partial set (e.g., a subset) of SSB transmissions; or a single SSB transmission.

[0126] Alternatively or additionally, the request message may include a field that indicates a type of request being made, and / or a reason for the request. For example, the request message may include a field that indicates that the on-demand SCell SSB transmissions are being requested so that the UE 3 can perform RRM / LTM measurements, SCell activation procedures, and / or SCell synchronization procedures. It will be appreciated that in this scenario, any appropriate field may be used in the request message to indicate the type and / or reason for the request.

[0127] The request message may also indicate to the RAN node 5 a number of repetitions of the on-demand SCell SSB transmissions that the UE 3 wishes the RAN node 5 to perform. For example, where the SSBs are transmitted using beam sweeping and / or beam forming procedures, the UE 3 may need the SSBs to be repeated at least as many times as there are Rx beams at the UE 3.

[0128] The request message may also include an SCell identifier that is used by the RAN node 5 to identify the SCell for which the on-demand SSB transmissions are being requested. The SCell identifier may be encoded explicitly in the request message (e.g., within an appropriate MAC CE) or alternatively it may be implicitly indicated to the RAN node 5. For example, the UE 3 may be configured by the RAN node 5 to transmit the request message over a specific set of resources for different serving cells, and each resource of the specific set of resources may be associated with a corresponding SCell by the RAN node 5 such that the RAN node 5 may imply which SCell a request message from the UE 3 is associated with, based on the specific resource used to transmit it to the RAN node 5.

[0129] At step S808, RAN node 5 may send an appropriate response message to the UE 3 to confirm that the RAN node 5 received the on-demand SSB request message sent at step S806, and to indicate to the UE 3 that the RAN node 5 will perform the requested on-demand SSB SCell transmissions. For example, the response message 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 response message, 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.

[0130] In another example, the response message 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 only monitor for the new DCI message when the on-demand SCell SSB transmission request message has been initiated and triggered by the UE 3. Alternatively, the UE 3 may always monitor for the new DCI message when a SCell is activated. Alternatively, the UE 3 may always monitor for the new DCI message regardless of whether a SCell is activated or deactivated (i.e., at all times).

[0131] In the scenario where the response message 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). Alternatively, the DCI message may be transmitted over the same cell that the UE 3 sent the on-demand SSB SCell transmission request message to the RAN node 5. 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.

[0132] In another example, the response message may be sent to the UE 3 in any appropriate RRC message during an RRC procedure.

[0133] Whether the response message is sent in a MAC CE, a DCI or an RRC based message, it may, as well as indicating that the RAN node 5 received the-demand SSB SCell transmission request message, 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 (i.e., a number of SSBs that the UE 3 should expect to receive), 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.

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

[0135] 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, a DCI or an RRC 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.

[0136] Whether the response message is sent in a MAC CE, a DCI or an RRC 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 response message 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 over which the UE 3 receives the response message. For example, where the UE 3 receives the response message 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.

[0137] At step S810, the RAN node 5 transmits SCell SSB transmissions to the UE 3. Those SSB transmissions may be aperiodic transmissions or semi-persistent transmissions.

[0138] Another way in which UE requested on-demand SCell SSB transmissions may be implemented will now be described in more detail, by way of example only, with reference to Fig. 9.

[0139] Fig. 9 is a simplified sequence diagram illustrating a procedure for UE-requested on-demand SCell SSB transmissions that may be used in the communication system 1 of Fig. 1.

[0140] Prior to the procedure illustrated in Fig. 9, the network may indicate whether on-demand SSB transmissions for a given SCell is enabled as described above with reference to Fig. 4.

[0141] As shown in Fig. 9, there is provided a RAN node 5 and a UE 3 deployed in the communication system 1 of Fig. 1. At step S902, the RAN node 5 sends a SCell measurement command message to the UE 3. For example, the RAN node 5 may send a command message to initiate / request the performance of SCell RRM measurements, LTM measurements, link-recovery measurements, and the like.

[0142] Upon reception of the SCell measurement command message at step S902, a requirement for on-demand SCell SSB transmissions may be triggered at the UE 3, at step S904, and the UE 3 may initiate the transmission of a request message to the RAN node 5 to request on-demand SCell SSB transmissions for the specific SCell indicated in the SCell measurement command message. For example, a requirement for on-demand SCell SSB transmissions may be triggered at the UE 3 if no SSB for the specific SCell is available to the UE 3 or no SSB for the specific SCell is being transmitted to the UE 3.

[0143] It will be appreciated however that whether the UE 3 initiates transmission of a request message to the RAN node 5 to request on-demand SCell SSB transmissions for the specific SCell at step S904 may also be dependent on the type of SCell measurement command message sent at S902. For example, where the SCell measurement command message sent to the UE 3 requests CSI-RS measurements, or other such measurements that do not pertain to synchronisation block measurements, then the UE 3 may not initiate transmission of a request message to the RAN node 5 to request on-demand SCell SSB transmissions for the specific SCell at step S904 as such transmissions will not be useful and will increase signalling overhead. In such a scenario, the UE 3 may instead request, for example, on-demand CSI-RS transmissions, or the like, if such on-demand transmissions are supported in the communication system 1.

[0144] If on the other hand the SCell measurement command message sent to the UE 3 requests SCell synchronisation type measurements (e.g., SSB measurements, and the like), then the UE 3 will, at step S904, initiate the transmission of a request message to the RAN node 5 to request on-demand SCell SSB transmissions for the specific SCell indicated in the SCell measurement command message if, for example, the UE 3 does not have time and / or frequency synchronisation with the specific SCell, and no SSB for the specific SCell is available to the UE 3 or no SSB for the specific SCell is being transmitted to the UE 3.

[0145] In such a scenario, the UE 3 may trigger / initiate the transmission of a request message to the RAN node 5 to request on-demand SCell SSB transmissions for the specific SCell in one of several possible ways described in more detail below.

[0146] For example, the UE 3 may initiate the transmission of a request message to the RAN node 5 to request on-demand SCell SSB transmissions for the specific SCell immediately after receiving the SCell measurement command message at step S902 from the RAN node 5 (e.g., immediately after receiving the SCell measurement configuration or SCell measurement report request from the RAN node 5).

[0147] In another example, the UE 3 may initiate the transmission of a request message to the RAN node 5 to request on-demand SCell SSB transmissions for the specific SCell within a specified period of Y ms after receiving the SCell measurement command message at step S902 from the RAN node 5. The specified period of Y ms may be pre-configured at the UE 3 (e.g., by hardcoding, or pre-configured by the RAN node 5 during an RRC configuration procedure). Alternatively, the specified period of Y ms may be determined by the UE 3 based on a time gap (Tgap) between the time of reception of the measurement command message from the RAN node 5 and a time occasion of the requested measurement report. For example, if Tgaprepresents the time gap between the time of reception of the measurement command message from the RAN node 5 and a time occasion of the requested measurement report, then value of Y ms can be determined as W*Tgapwhere W is between 0 and 1.

[0148] In another example, the UE 3 may initiate the transmission of a request message to the RAN node 5 to request on-demand SCell SSB transmissions for the specific SCell at the latest time Y ms before the time occasion of the requested measurement report. At step S906, UE 3 sends an appropriate request message to the RAN node 5 to request the RAN node 5 to perform on-demand SCell SSB transmissions. That request message may contain any appropriate indication that informs the RAN node 5 that on-demand SCell SSB transmission for one or more SCells is requested.

[0149] It will be appreciated that the request message sent at S906 to request on-demand SSB SCell transmissions may take any appropriate form that enables the request to be made to the RAN node 5. By way of example only, the request message may take the form of a new MAC CE that can carry the on-demand SCell SSB request from the UE 3 to the RAN node 5. Such MAC CEs are typically implemented as special bit strings within the LCID field of the MAC header of the MAC PDU. In such a scenario, the MAC CE would be assigned the highest, or second highest, relative logical channel priority amongst all other MAC CEs, i.e., the MAC CE will be below C-RNTI MAC CE or data from UL-CCCH.

[0150] In another example, the request message may take the form of one or more new bits within uplink control information (UCI) sent to the RAN node 5 by the UE 3 on the physical uplink control channel (PUCCH). Those new bits may be defined in the PUCCH resources and may be used to request on-demand SCell SSB transmissions. For example, those new bits may take the form of an appropriate sequence of 1s and 0s to indicate to the RAN node 5 that on-demand SSB transmissions for a SCell is requested. It will be appreciated that where such sequences of bits in the UCI are used to indicate that on-demand SSB SCell transmissions are requested, the sequences may be hardcoded in the RAN node 5, for example there may be a mapping table provided at the RAN node 5 that maps specific sequences of those bits to specific on-demand SSB SCell requests. Alternatively, those sequences and the request they are associated with may be indicated to the RAN node 5 during an RRC procedure.

[0151] In another example, the request message may take the form of an appropriate RRC based message sent to the RAN node 5 by the UE 3. For example, the request message may take the form of a special RRC message sent during an RRC procedure between the UE 3 and the RAN node 5. A special RRC message may include, for example, a UE assistance information (UAI) message that is sent to the RAN node 5 after RRC (re)configuration.

[0152] It will be appreciated that the request message sent at S906 will be sent to the RAN node 5 over an appropriate cell that supports communication between the UE 3 and the RAN node 5. The request message may, for example, always use a PCell or a PSCell. Nevertheless, the appropriate cell to be used for sending the request message is sent may be indicated to the UE 3 via an appropriate configuration message sent to the UE 3 by the RAN node 5 - i.e., the RAN node 5 may indicate to the UE 3 which cell it wishes to receive on-demand SSB SCell request messages. By way of example only, if UE 3 is to send the request message using a specific configured PUCCH resource or some other appropriate SR resources then the network (e.g., the RAN node 5) may indicate to the UE 3 which PUCCH resources or SR resources may be used for the transmission of the on-demand SSB SCell transmission request message. That indication of resources may be made in advance to the UE 3, for example, during an RRC (re)configuration procedur.

[0153] It will also be appreciated that where it is possible for the request message to be sent over one of multiple cells, the UE 3 may choose the specific cell to use to send the request message. For example, if the RAN node 5 indicates, to the UE 3, that multiple cells and corresponding resources are available for the transmission of the on-demand SSB SCell transmission request message, then the UE 3 may choose to use the resources, and thus corresponding cell, that are available earliest for the transmission of the request message.

[0154] The contents of the on-demand SSB SCell transmission request message (also referred herein as 'the request message') may include an indication of the number of SSBs required for the UE 3 to make the desired measurements of the SCell. It will be appreciated that different scenarios may require different sets of SSB transmissions to be made to enable correct synchronization. For example, to enable radio resource management-based measurements (e.g., RSRP measurements, RSRQ measurements, cell identify measurements, CSI measurements, and the like) the UE 3 may require reception of a full set of SSBs. Meanwhile, for SCell activation procedures and / or time synchronisation, reception of a subset of SSBs may be sufficient to enable SCell activation and synchronisation.

[0155] The indication of the number of SSBs required for the UE 3 to make the desired measurements of the SCell may be encoded in the request message as a specific number of required SSBs, or alternatively it may be encoded in a dedicated 2- or 3-bit field indicating the number of required SSBs. Where the number of required SSBs is encoded in a dedicated 2- or 3-bit field, the 2- or 3-bit sequences of '1s' and '0s' may be used to indicate whether the UE 3 requires a full set of SSB transmissions, a partial set (e.g., a subset) of SSB transmissions, or a single SSB transmission.

[0156] Alternatively, or additionally, the request message may include a field that indicates a type of request being made, and / or a reason for the request. For example, the request message may include a field that indicates that the on-demand SCell SSB transmissions are being requested so that the UE 3 can perform RRM measurements, SCell activation procedures, and / or SCell synchronization procedures. It will be appreciated that in this scenario, any appropriate field may be used in the request message to indicate the type and / or reason for the request.

[0157] The request message may also indicate to the RAN node 5 a number of repetitions of the on-demand SCell SSB transmissions that the UE 3 wishes the RAN node 5 to perform. For example, where the SSBs are transmitted using beam sweeping and / or beam forming procedures, the UE 3 may need the SSBs to be repeated as least as many times at there are Rx beams at the UE 3.

[0158] The request message may also include an SCell identifier that is used by the RAN node 5 to identify the SCell for which the on-demand SSB transmissions are being requested. The SCell identifier may be encoded explicitly in the request message (e.g., within an appropriate MAC CE) or alternatively it may be implicitly indicated to the RAN node 5. For example, the UE 3 may be configured by the RAN node 5 to transmit the request message over a specific set resources for different serving cells, and each resource of the specific set of resources may be associated with a corresponding SCell by the RAN node 5 such that the RAN node 5 may imply which SCell a request message from the UE 3 is associated with based on the specific resource used to transmit it to the RAN node 5.

[0159] At step S908, RAN node 5 may send an appropriate response message to the UE 3 to confirm that the RAN node 5 received the on-demand SSB request message sent at step S906, and to indicate to the UE 3 that the RAN node 5 will perform the requested on-demand SSB SCell transmissions. For example, the response message 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 response message, 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.

[0160] In another example, the response message 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 only monitor for the new DCI message when the on-demand SCell SSB transmission request message has been initiated and triggered by the UE 3. Alternatively, the UE 3 may always monitor for the new DCI message when a SCell is activated. Alternatively, the UE 3 may always monitor for the new DCI message regardless of whether a SCell is activated or deactivate (i.e., at all times).

[0161] In the scenario where the response message 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). Alternatively, the DCI message may be transmitted over the same cell that the UE 3 sent the on-demand SSB SCell transmission request message to the RAN node 5. 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.

[0162] In another example, the response message may be sent to the UE 3 in any appropriate RRC message during an RRC procedure.

[0163] Whether the response message is sent in a MAC CE, a DCI or an RRC based message, it may, as well as indicating that the RAN node 5 received the-demand SSB SCell transmission request message, 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 (i.e., a number of SSBs that the UE 3 should expect to receive), 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.

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

[0165] 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, a DCI or an RRC 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.

[0166] Whether the response message is sent in a MAC CE, a DCI or an RRC 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 response message 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 over which the UE 3 receives the response message. For example, where the UE 3 receives the response message 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.

[0167] At step S910, the RAN node 5 transmits SCell SSB transmissions to the UE 3. Those SSB transmissions may be aperiodic transmissions or semi-persistent transmissions.

[0168] SCell SSB Repetitions 　　In all the scenarios described above with reference to Figs. 6, 8, and 9, it is also envisaged that the UE 3 may also send repeated requests for on-demand SCell SSB transmissions when appropriate to do so.

[0169] However, it will be appreciated that sending repetitions of the request message (e.g., the message sent at step S604 in Fig. 6, step S806 in Fig. 8, and step S906 in Fig. 9) immediately after the transmission of a first request message for SCell SSB transmissions may lead to signalling inefficiencies. For example, once the UE 3 has transmitted the first request message to the RAN node 5, the RAN node 5 requires time to process the message and then where appropriate send a response message to the UE 3 to confirm correct reception of the request message. Immediate re-transmitting the request message however means the RAN node 5 does not have time to process the first request message and respond before the next request message is sent. Consequently, the subsequent request message may be sent despite the RAN node 5 not needing them, e.g., when the RAN node 5 correctly receives and processes the first request message. Beneficially, to avoid such signalling inefficiencies, a mechanism is provided that limits UE (re)requests for on-demand SSB transmissions. That mechanism is now described in detail with reference to Fig. 10.

[0170] Fig. 10 is a simplified timing diagram illustrating a procedure for transmitting repetitions of on-demand SCell SSB transmission requests that may be used in the communication system 1 of Fig. 1.

[0171] As shown in Fig. 10, once a trigger has been determined by the UE 3 to request on-demand SCell SSB transmissions, the UE 3 may send an appropriate request message to the RAN node 5 (e.g., the message sent at step S604 in Fig. 6, step S806 in Fig. 8, and step S906 in Fig. 9) multiple times. For example, if the UE 3 does not receive an appropriate response message from the RAN node 5 following the transmission of the request message, the UE 3 may decide to repeatably send the request message to the RAN node 5 until a response message is received. By way of another example, if the UE 3 fails to receive or detect an SSB transmission from the RAN node 5 following the transmission of the request message, the UE 3 may decide to repeatably send the request message to the RAN node 5 until a SSB transmission is received, or until a threshold number of repetitions have been performed by the UE 3.

[0172] As shown in Fig. 10, upon determining a trigger to request on-demand SCell SSB transmissions, the UE 3 sends a first request message to the RAN node 5. At the same time as transmitting the request message the UE 3 initiates a timer. While the timer runs, the UE 3 may resend the request message to the RAN node 5 a defined number (e.g., 'NOndemandSSB' or the like) times within a timer period (e.g., 'TOndemandSSB' or the like). It will be appreciated that while in Fig. 9 the NOndemandSSBnumber of request messages for on-demand SCell SSB transmissions are arranged such that they occur in consecutive time slots, the timing of the request messages may be distributed over the timer period TOndemandSSBin non-consecutive slots.

[0173] The value of NOndemandSSBmay be a pre-configured value of the UE 3 (e.g., NOndemandSSBmay be hardcoded in the UE 3). Alternatively, the value of NOndemandSSBmay be configured by the RAN node 5 during an RRC procedure with the UE 3. The value of NOndemandSSBmay any number greater than or equal to 1.

[0174] The timer period TOndemandSSBmay be configured by the RAN node 5 during an RRC procedure with the UE 3. For example, the RAN node 5 may configure different timer period TOndemandSSBvalues for different scenarios. By way of example only, the RAN node 5 may configure one value for the timer period TOndemandSSBfor the case where the request message is being retransmitted to the RAN node 5 due to the UE 3 not receiving an appropriate response message from the UE 3 confirming reception of the request message. Additionally, or alternatively, the RAN node 5 may configure a different value for the timer period TOndemandSSBfor the case where the request message is being retransmitted to the RAN node 5 due to the UE 3 failing to receive or detect a SCell SSB transmission from the RAN node 5.

[0175] Alternatively, the value of the timer period TOndemandSSBmay be determined by the UE 3. For example, the value of the timer period TOndemandSSBmay be determined by the UE 3 based on an expected time occasion when an SSB transmission from the RAN node 5 terminates. By way of example only, if the RAN node 5 indicates to the UE 3 that an SSB transmission will begin at a time T0and will continue for a duration TSSB, then the UE 3 may initiate transmission of the request message and its repetitions if the UE 3 has not received any SSB transmissions within the period of T0+ TSSB.

[0176] At the end of the timer period TOndemandSSB, if the UE 3 has not received any response messages from the RAN node 5 in response to the transmission of the request messages and / or has not detected or received a SCell SSB transmission from the RAN node 5, then the UE 3 re-initiates the timer and the UE 3 then begins transmitting the request message again, including performing repetitions of the transmission of the request message.

[0177] UL Timing Alignment Timer (TAT) 　　The implementation of on-demand SCell SSB transmissions may also be particularly beneficial when dealing with UL TAT expiry as will be described now in more detail.

[0178] During RACH procedures to establish a connection between the UE 3 and RAN node 5, the RAN node 5 may send an appropriate timing advance (TA) command to the UE 3 to control UL transmission timing of the UE 3. Beneficially, by sending the TA command to the UE 3 it can be ensured that UL transmissions from the UE 3, and any other UE to which the RAN node 5 is connected, are synchronised. The maintenance of such synchronisation is particularly important for the minimisation of interference between different UEs in communication with the RAN node 5 and to minimise data loss and maintain quality-of-service (QoS).

[0179] The TA command typically it transmitted to the UE 3 by the RAN node 5 using a MAC CE communicated to the UE 3 over a communication path at the MAC layer. The MAC CE may be implemented as a special bit string in the LCID field of the MAC header. The structure of the MAC CE for the TA command typically comprises a 6-bit portion for the TA command (TA) and a 2-bit portion for a timing advance group (TAG) identifier (ID). A TAG is a group of cells (e.g., a PCell and one or more SCells) that share the same UL transmission timing, i.e., they share the same DL timing reference and the same TA commands.

[0180] It will be appreciated that there are multiple ways of maintaining the synchronisation of UL transmissions from the UE 3, and any other UE to which the RAN node 5 is connected, such as the use of an UL TAT. An UL TAT is a timer that is (re-)started by the UE 3 each time it receives a TA command from the RAN node 5. That UL TAT runs for a maximum time specified in an appropriate IE (e.g., a timingAlignmentTimer IE or the like within a ServingCellConfigCommonSIB IE) signalled to the UE 3 by the RAN node 5 in an appropriate signalling message, e.g., a system information block 1 (SIB1) message. The maximum time specified in the appropriate IE specifies to the UE 3 a maximum time that the UE 3 remains synchronised in the UL direction after receiving a TA command. Once the UL TAT expires, the UE 3 may assume that it has lost UL synchronisation and must then in that instance use a RACH procedure to re-synchronise before it can continue to transmit on the UL to the RAN node 5.

[0181] However, to perform the RACH procedure, the UE 3 needs to make appropriate signal measurements to allow the RACH procedure to go ahead. For example, the UE 3 will need to perform SSB measurements, and thus on-demand SCell SSB transmissions may be required when RACH resources are configured for a SCell, and none of the serving cells that belong to the same TAG ID as that associated with the SCell have periodic SSB transmission available. In such a scenario, the unavailability of periodic SSB transmissions will result in the UE 3 being unable to carry out the RACH procedure configured for the SCell and communication over that cell will be lost.

[0182] To ensure that in such a scenario as that described above the UE 3 is able to carry out the necessary RACH procedures configured for the SCell to re-synchronise UL transmissions sent over that cell, and thus re-establish communication over that cell, the RAN node 5 may schedule on-demand SCell SSB transmissions of its own volition when the TAT expires at the UE 3.

[0183] Fig. 11 a simplified sequence diagram illustrating another procedure for RAN node triggered on-demand SCell SSB transmissions that may be used in the communication system 1 of Fig. 1.

[0184] Prior to the procedure illustrated in Fig. 11, the network may indicate whether on-demand SSB transmissions for a given SCell is enabled as described above with reference to Fig. 4.

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

[0186] At step S1104, the RAN node 5 triggers on-demand SSB transmissions for one or more SCells. The trigger may be initiated by the RAN node 5 when the TAT for the UE 3 expires. For example, as the RAN node 5 indicates to the UE 3 a maximum time for the TAT specified in an appropriate IE, and given that the RAN node 5 knows when it last sent a TA command to the UE 3, the RAN node 5 is able to determine when the TAT expires at the UE 3 presuming that the TAT is (re-)started in response to receiving the last TA command from the RAN node 5.

[0187] In this scenario, the UE 3 may expect the RAN node 5 to transmit SCell SSBs to the UE 3 once the UE's TAT has expired and thus the UE 3 may merely monitor for SCell SSB transmissions from the RAN node 5 upon expiration of its TAT. At step S1108, the RAN node 5 transmits the SCell SSBs to the UE 3. Optionally, rather than the UE 3 assuming that the RAN node 5 will transmit SCell SSBs once its TAT expires, the UE 3 may await an indication from the RAN node 5 indicating that SCell SSB transmissions have been triggered. For example, the RAN node 5 may, at step S1106, transmit an indication that SCell SSB transmissions have been triggered, and that the UE 3 should thus expect to receive SCell SSB transmissions.

[0188] Fig. 12 is a simplified sequence diagram illustrating another procedure for UE-requested on-demand SCell SSB transmissions that may be used in the communication system 1 of Fig. 1.

[0189] Prior to the procedure illustrated in Fig. 12, the network may indicate whether on-demand SSB transmissions for a given SCell is enabled as described above with reference to Fig. 4.

[0190] As shown in Fig. 12, there is provided the RAN node 5 and the UE 3 deployed in the communication system 1 of Fig. 1. At step S1202 a requirement for on-demand SCell SSB transmissions is triggered at the UE 3 based on one or more conditions associated with the UE's TAT. For example, a requirement for on-demand SCell SSB transmissions is triggered at the UE 3 based on the UE's TAT being about to expire (i.e., in advance of the TAT expiring the UE 3 is triggered for on-demand SCell SSB transmissions).

[0191] Alternatively, a requirement for on-demand SCell SSB transmissions may be triggered at the UE 3 based on the UE's TAT expiring. In this specific scenario, the UE 3 may be configured to allow it to perform a small number of UL transmissions to the RAN node 5 despite the TAT having expired. For example, despite the TAT having expired the UE 3 may still be able to send an UL transmission to the RAN node 5 to request on-demand SSB. The UE 3 may only be able to continue sending UL transmission to the RAN node 5 after the TAT has expired for a threshold duration following expiry of the TAT. That threshold duration may be hardcoded at the UE 3 or may be configured at the UE 3 during RRC procedures or the like. Additionally, the UE 3 may also be configured such that all UL transmissions following expiry of the TAT are restricted to transmissions requesting on-demand SSB.

[0192] Additionally, the decision as to whether the UE 3 triggers on-demand SCell SSB transmissions may also be based on other appropriate additional criteria. For example, the UE 3 may request on-demand SSB if the UE 3 has not received a message from the RAN node 5 indicating that an (on-demand) SSB transmission is being transmitted or is shortly about to be transmitted.

[0193] Alternatively, or additionally, the UE 3 may request on-demand SSB transmissions if the last SSB measurement / detection was performed earlier than a threshold duration of time before TAT expiry or RACH transmission.

[0194] In either scenario described above with reference to step S1202, following the UE 3 deciding to request SCell SSB transmissions, the UE 3, at step S1204, sends an appropriate request message to the RAN node 5 to request the RAN node 5 to perform on-demand SCell SSB transmissions. That request message may contain any appropriate indication that informs the RAN node 5 that on-demand SCell SSB transmission for one or more SCells is requested.

[0195] It will be appreciated that the request message sent at S1204 to request on-demand SSB SCell transmissions may take any appropriate form that enables the request to be made to the RAN node 5. By way of example only, the request message may take the form of a new MAC CE that can carry the on-demand SCell SSB request from the UE 3 to the RAN node 5. Such MAC CEs are typically implemented as special bit strings within the LCID field of the MAC header of the MAC PDU. In such a scenario, the MAC CE would be assigned the highest, or second highest, relative logical channel priority amongst all other MAC CEs, i.e., the MAC CE will be below C-RNTI MAC CE or data from UL-CCCH.

[0196] In another example, the request message may take the form of one or more new bits within uplink control information (UCI) sent to the RAN node 5 by the UE 3 on the physical uplink control channel (PUCCH). Those new bits may be defined in the PUCCH resources and may be used to request on-demand SCell SSB transmissions. For example, those new bits may take the form of an appropriate sequence of 1s and 0s to indicate to the RAN node 5 that on-demand SSB transmissions for a SCell is requested. It will be appreciated that where such sequences of bits in the UCI are used to indicate that on-demand SSB SCell transmissions are requested, the sequences may be hardcoded in the RAN node 5, for example there may be a mapping table provided at the RAN node 5 that maps specific sequences of those bits to specific on-demand SSB SCell requests. Alternatively, those sequences and the request they are associated with may be indicated to the RAN node 5 during an RRC procedure.

[0197] In another example, the request message may take the form of an appropriate RRC based message sent to the RAN node 5 by the UE 3. For example, the request message may take the form of a special RRC message sent during an RRC procedure between the UE 3 and the RAN node 5. A special RRC message may include, for example, a UE assistance information (UAI) message that is sent to the RAN node 5 after RRC (re)configuration.

[0198] It will be appreciated that the request message sent at S1104 will be sent to the RAN node 5 over an appropriate cell that supports communication between the UE 3 and the RAN node 5. The request message may, for example, always use a PCell or a PSCell. Nevertheless, the appropriate cell to be used for sending the request message may be indicated to the UE 3 via an appropriate configuration message sent to the UE 3 by the RAN node 5, i.e., the RAN node 5 may indicate to the UE 3 which cell it wishes to receive on-demand SSB SCell request messages. By way of example only, if the UE 3 is to send the request message using a specific configured PUCCH resource or some other appropriate SR resources then the network (e.g., the RAN node 5) may indicate to the UE 3 which PUCCH resources or SR resources may be used for the transmission of the on-demand SSB SCell transmission request message. That indication of resources may be made in advance to the UE 3, for example, during an RRC (re)configuration procedure.

[0199] It will also be appreciated that where it is possible for the request message to be sent over one of multiple cells, the UE 3 may choose the specific cell to use to send the request message. For example, if the RAN node 5 indicates, to the UE 3, that multiple cells and corresponding resources are available for the transmission of the on-demand SSB SCell transmission request message, then the UE 3 may choose to use the resources, and thus corresponding cell, that are available earliest for the transmission of the request message.

[0200] The contents of the on-demand SSB SCell transmission request message (also referred herein as 'the request message') may include an indication of the number of SSBs required for the UE 3 to make desired measurements of the SCell. It will be appreciated that different scenarios may require different sets of SSB transmissions to be made to enable correct synchronization. For example, to enable radio resource management-based measurements (e.g., RSRP measurements, RSRQ measurements, cell identify measurements, CSI measurements, and the like) the UE 3 may require reception of a full set of SSBs. Meanwhile, for SCell activation procedures and / or time synchronisation, reception of a subset of SSBs may be sufficient to enable SCell activation and synchronisation.

[0201] The indication of the number of SSBs required for the UE 3 to make the desired measurements of the SCell may be encoded in the request message as a specific number of required SSBs, or alternatively it may be encoded in a dedicated 2- or 3-bit field indicating the number of required SSBs. Where the number of required SSBs is encoded in a dedicated 2- or 3-bit field, the 2- or 3-bit sequences of '1s' and '0s' may be used to indicate whether the UE 3 requires a full set of SSB transmissions, a partial set (e.g., a subset) of SSB transmissions, or a single SSB transmission.

[0202] Alternatively, or additionally, the request message may instead include a field that indicates a type of request being made, and / or a reason for the request. For example, the request message may include a field that indicates that the on-demand SCell SSB transmissions are being requested so that the UE 3 can perform RRM / LTM measurements, SCell activation procedures, and / or SCell synchronization procedures. It will be appreciated that in this scenario, any appropriate field may be used in the request message to indicate the type and / or reason for the request.

[0203] The request message may also indicate to the RAN node 5 a number of repetitions of the on-demand SCell SSB transmissions that the UE 3 wishes the RAN node 5 to perform. For example, where the SSBs are transmitted using beam sweeping and / or beam forming procedures, the UE 3 may need the SSBs to be repeated at least at many times at there are Rx beams at the UE 3.

[0204] The request message may also include an SCell identifier that is used by the RAN node 5 to identify the SCell for which the on-demand SSB transmissions are being requested. The SCell identifier may be encoded explicitly in the request message (e.g., within an appropriate MAC CE) or alternatively it may be implicitly indicated to the RAN node 5. For example, the UE 3 may be configured by the RAN node 5 to transmit the request message over a specific set of resources for different serving cells, and each resource of the specific set of resources may be associated with a corresponding SCell by the RAN node 5. Hence the RAN node 5 may imply which SCell a request message from the UE 3 is associated with based on the specific resource used to transmit it to the RAN node 5.

[0205] At step S1206, the RAN node 5 may send an appropriate response message to the UE 3 to confirm that the RAN node 5 received the on-demand SSB request message sent at step S1204, and to indicate to the UE 3 that the RAN node 5 will perform the requested on-demand SSB SCell transmissions. For example, the response message 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 response message, 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.

[0206] In another example, the response message 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 only monitor for the new DCI message when the on-demand SCell SSB transmission request message has been initiated and triggered by the UE 3. Alternatively, the UE 3 may always monitor for the new DCI message when a SCell is activated. Alternatively, the UE 3 may always monitor for the new DCI message regardless of whether a SCell is activated or deactivate (i.e., at all times).

[0207] In the scenario where the response message 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 the same cell that the UE 3 sent the on-demand SSB SCell transmission request message to the RAN node 5. Alternatively, the DCI message may be transmitted over any appropriate cell capable of supporting communication between the RAN node 5 and the UE 3.

[0208] In another example, the response message may be sent to the UE 3 in any appropriate RRC message during an RRC procedure.

[0209] Whether the response message is sent in a MAC CE, a DCI or an RRC based message, it may, as well as indicating that the RAN node 5 received the-demand SSB SCell transmission request message, 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 (i.e., a number of SSBs that the UE 3 should expect to receive), 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.

[0210] Whether the response message is sent in a MAC CE, a DCI or an RRC based message, the message may also include timing information pertaining to the SSB transmissions where appropriate. For example, the message may include an indication of a starting time occasion where SSB transmissions will start. Additionally, or alternatively, it may also include an indication of a periodicity of SSB transmissions. Additionally, or alternatively it may also include an indication of how long SSB transmissions will continue. Additionally, or alternatively, it may also include an indication as to whether SSB transmissions are to be aperiodic or semi-persistent. 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, a DCI or an RRC 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.

[0211] Whether the response message is sent in a MAC CE, a DCI or an RRC 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 response message 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 over which the UE 3 receives the response message. For example, where the UE 3 receives the response message 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.

[0212] At step S1208, the RAN node 5 transmits SCell SSB transmissions to the UE 3. Those SSB transmissions may be aperiodic transmissions or semi-persistent transmissions.

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

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

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

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

[0217] 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. The communication control module 43 is configured, in particular, to control the UE's communications, in accordance with any of the methods described herein.

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

[0219] As shown in Fig. 14, 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 antennas 53 (e.g., a single or multi-panel antenna array / massive antenna), and a core network interface 55 for transmitting signals to and for receiving signals from network nodes in the core network 7. Although not shown, the RAN node 5 may also be coupled to other RAN nodes via an appropriate interface (e.g., the so-called 'X2' interface in LTE or the 'Xn' interface in NR). The RAN node 5 has a controller 57 to control the operation of the RAN node 5. The controller 57 is associated with a memory 59. Software may be pre-installed in the memory 59 and / or may be downloaded via the communication system 1 or from a 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 the memory 59.

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

[0221] The communication control module 63 is operable to control the communication between the RAN node 5 and UEs 3 and other network entities (e.g., core network nodes) that communicate with the RAN node 5. The communication control module 63 is configured for the overall control of the reception and decoding of uplink communications, via associated uplink channels (e.g., via a 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.

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

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

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

[0225] For example, it will be appreciated that whilst the procedures described above with reference to Figs. 4-12 relate to on-demand SSB transmissions 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 transmissions on a PCell when a 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.

[0226] By way of example only, a 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, 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 transmissions) that allow the UE 3 perform measurements of cells in the vicinity of the UE 3, and where appropriate undertake a cell (re-)selection procedure to camp onto and access a cell to support communication with the network.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0247]

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

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

[0250] This application is based upon and claims the benefit of priority from United Kingdom Patent Application No. 2319334.5, filed on December 15, 2023, the disclosure of which is incorporated herein in its entirety by reference.

[0251] Supplementary notes 　　The whole or part of the example Aspects disclosed above can be described as, but not limited to, the following supplementary notes. 　　　　(Supplementary note 1) 　　A method performed by a user equipment (UE), the method comprising: 　　receiving, from an access network node, configuration information for on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB) / channel state information (CSI) reference signal (CSI-RS) for secondary cells (SCells); and 　　configuring on-demand SSB / CSI-RS based on the configuration information. 　　　　(Supplementary note 2) 　　The method according to supplementary note 1, wherein 　　the configuration information includes information for occasions of transmission of the on-demand SSB / CSI-RS, and 　　the information indicates at least one of: 　　　　timing of the transmission of on-demand SSB / CSI-RS, 　　　　periodicity of the on-demand SSB / CSI-RS, or 　　　　how long the transmission of the on-demand SSB / CSI-RS continues. 　　　　(Supplementary note 3) 　　The method according to supplementary note 1 or 2, wherein 　　the configuration information indicates at least one of: 　　　　on which SSBs / CSI-RSs are transmitted; or 　　　　each of the SCells. 　　　　(Supplementary note 4) 　　The method according to supplementary note 1, wherein 　　the configuration information indicates that all or a part of configuration of on-demand SSB / CSI-RS of the SCells is same as a special cell (SpCell). 　　　　(Supplementary note 5) 　　The method according to any one of supplementary notes 1 to 4, wherein 　　the configuration information is included in at least one of: 　　　　serving cell configuration information, or 　　　　measurement object configuration information, and 　　the serving cell configuration information or the measurement object configuration information indicates whether each SSB / CSI-RS is periodic or on-demand. 　　　　(Supplementary note 6) 　　The method according to any one of supplementary notes 1 to 5, wherein 　　the configuration information is transmitted by at least one of: 　　　　a medium access control (MAC) control element (MAC CE); 　　　　downlink control information (DCI); 　　　　group common DCI; 　　　　a radio resource control (RRC) message; or 　　　　a hybrid automatic repeat request (HARQ) acknowledgement (ACK) / negative ACK (NACK) feedback. 　　　　(Supplementary note 7) 　　The method according to any one of supplementary notes 1 to 6, wherein 　　the transmission of the on-demand SSB / CSI-RS is triggered due to at least one of: 　　　　SCell timing synchronization; 　　　　SCell activation; 　　　　radio resource management (RRM) measurements; 　　　　lower layer triggered mobility (LTM) measurements before SCell activation; or 　　　　at least one condition which is configured by the access network node is met. 　　　　(Supplementary note 8) 　　The method according to supplementary note 7, further comprising: 　　receiving, from the access network node, first information indicating that the transmission of the on-demand SSB / CSI-RS is triggered, and wherein 　　the first information is transmitted in at least one of: 　　　　a trigger message for the SCell activation, the RRM measurements or link recovery measurements; 　　　　a message transmitted before or after transmitting the trigger message; or 　　　　a message for triggering SSB / CSI-RS measurements. 　　　　(Supplementary note 9) 　　The method according to supplementary note 7 or 8 further comprising: 　　transmitting, to the access network node, a request for triggering the transmission of the on-demand SSB / CSI-RS. 　　　　(Supplementary note 10) 　　The method according to supplementary note 9, wherein 　　the transmitting the request is performed based on at least one of: 　　　　SCell timing synchronization; 　　　　SCell activation; 　　　　radio resource management (RRM) measurements; 　　　　lower layer triggered mobility (LTM) measurements before SCell activation; 　　　　at least one condition which is configured by the access network node is met; 　　　　triggering SSB measurements; 　　　　losing time / frequency synchronization with at least one of the SCells; or 　　　　timer expiry. 　　　　(Supplementary note 11) 　　The method according to supplementary note 9 or 10, wherein 　　the request is transmitted by at least one of: 　　　　a medium access control (MAC) control element (MAC CE); 　　　　uplink control information (UCI); or 　　　　a radio resource control (RRC) message. 　　　　(Supplementary note 12) 　　The method according to any one of supplementary notes 9 to 11, wherein 　　the request is transmitted via at least one of: 　　　　a primary cell (PCell); 　　　　a primary secondary cell group cell (PSCell); 　　　　a specific cell which is indicated by the access network node; or 　　　　a cell where a resource for the transmitting the request is available the earliest. 　　　　(Supplementary note 13) 　　The method according to any one of supplementary notes 9 to 12, wherein 　　the request includes at least one of: 　　　　information indicating how many SSBs / CSI-RSs are required for measurements; 　　　　information indicating a number of SSBs / CSI-RSs to be transmitted; 　　　　information indicating a reason of the request; 　　　　information indicating how many repetitions of the transmission of the on-demand SSB / CSI-RS are required; or 　　　　information indicating at least one SCell. 　　　　(Supplementary note 14) 　　The method according to any one of supplementary notes 7 to 13, wherein 　　the transmitting the request is performed by transmitting the request multiple times based on a timer. 　　　　(Supplementary note 15) 　　The method according to supplementary note 7 or 10, wherein 　　the at least one condition is related to at least one of: 　　　　time / frequency synchronization; 　　　　automatic gain control (AGC) setting; or 　　　　best downlink (DL) beam selection / update. 　　　　(Supplementary note 16) 　　A method performed by an access network node, the method comprising: 　　transmitting, to a user equipment (UE), configuration information for on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB) / channel state information (CSI) reference signal (CSI-RS) for secondary cells (SCells), wherein 　　the configuration information is used by the UE for configuring on-demand SSB / CSI-RS. 　　　　(Supplementary note 17) 　　A user equipment (UE) comprising: 　　means for receiving, from an access network node, configuration information for on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB) / channel state information (CSI) reference signal (CSI-RS) for secondary cells (SCells); and 　　means for configuring on-demand SSB / CSI-RS based on the configuration information.

[0252] 1　　COMMUNICATION SYSTEM 3, 3-1, 3-2, 3-3　　USER EQUIPMENT (UE) 5　　RADIO ACCESS NETWORK (RAN) NODE 7　　CORE NETWORK 9　　ASSOCIATED CELL 10　　CONTROL PLANE FUNCTION (CPF) GROUP 10-1, 10-2, 10-n　　CONTROL PLANE FUNCTION (CPF) 11　　USER PLANE FUNCTION (UPF) 20　　EXTERNAL DATA NETWORK 31, 51　　TRANSCEIVER CIRCUIT 33, 53　　ANTENNA 35　　USER INTERFACE 55　　CORE NETWORK INTERFACE 37, 57　　CONTROLLER 39, 59　　MEMORY 41, 61　　OPERATING SYSTEM 43, 63　　COMMUNICATIONS CONTROL MODULE

Claims

1. A method performed by a user equipment (UE), the method comprising: 　　receiving, from an access network node, configuration information for on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB) / channel state information (CSI) reference signal (CSI-RS) for secondary cells (SCells); and 　　configuring on-demand SSB / CSI-RS based on the configuration information.

2. The method according to claim 1, wherein 　　the configuration information includes information for occasions of transmission of the on-demand SSB / CSI-RS, and 　　the information indicates at least one of: 　　　　timing of the transmission of on-demand SSB / CSI-RS, 　　　　periodicity of the on-demand SSB / CSI-RS, or 　　　　how long the transmission of the on-demand SSB / CSI-RS continues.

3. The method according to claim 1 or 2, wherein 　　the configuration information indicates at least one of: 　　　　on which SSBs / CSI-RSs are transmitted; or 　　　　each of the SCells.

4. The method according to claim 1, wherein 　　the configuration information indicates that all or a part of configuration of on-demand SSB / CSI-RS of the SCells is same as a special cell (SpCell).

5. The method according to any one of claims 1 to 4, wherein 　　the configuration information is included in at least one of: 　　　　serving cell configuration information, or 　　　　measurement object configuration information, and 　　the serving cell configuration information or the measurement object configuration information indicates whether each SSB / CSI-RS is periodic or on-demand.

6. The method according to any one of claims 1 to 5, wherein 　　the configuration information is transmitted by at least one of: 　　　　a medium access control (MAC) control element (MAC CE); 　　　　downlink control information (DCI); 　　　　group common DCI; 　　　　a radio resource control (RRC) message; or 　　　　a hybrid automatic repeat request (HARQ) acknowledgement (ACK) / negative ACK (NACK) feedback.

7. The method according to any one of claims 1 to 6, wherein 　　the transmission of the on-demand SSB / CSI-RS is triggered due to at least one of: 　　　　SCell timing synchronization; 　　　　SCell activation; 　　　　radio resource management (RRM) measurements; 　　　　lower layer triggered mobility (LTM) measurements before SCell activation; or 　　　　at least one condition which is configured by the access network node is met.

8. The method according to claim 7, further comprising: 　　receiving, from the access network node, first information indicating that the transmission of the on-demand SSB / CSI-RS is triggered, and wherein 　　the first information is transmitted in at least one of: 　　　　a trigger message for the SCell activation, the RRM measurements or link recovery measurements; 　　　　a message transmitted before or after transmitting the trigger message; or 　　　　a message for triggering SSB / CSI-RS measurements.

9. The method according to claim 7 or 8 further comprising: 　　transmitting, to the access network node, a request for triggering the transmission of the on-demand SSB / CSI-RS.

10. The method according to claim 9, wherein 　　the transmitting the request is performed based on at least one of: 　　　　SCell timing synchronization; 　　　　SCell activation; 　　　　radio resource management (RRM) measurements; 　　　　lower layer triggered mobility (LTM) measurements before SCell activation; 　　　　at least one condition which is configured by the access network node is met; 　　　　triggering SSB measurements; 　　　　losing time / frequency synchronization with at least one of the SCells; or 　　　　timer expiry.

11. The method according to claim 9 or 10, wherein 　　the request is transmitted by at least one of: 　　　　a medium access control (MAC) control element (MAC CE); 　　　　uplink control information (UCI); or 　　　　a radio resource control (RRC) message.

12. The method according to any one of claims 9 to 11, wherein 　　the request is transmitted via at least one of: 　　　　a primary cell (PCell); 　　　　a primary secondary cell group cell (PSCell); 　　　　a specific cell which is indicated by the access network node; or 　　　　a cell where a resource for the transmitting the request is available the earliest.

13. The method according to any one of claims 9 to 12, wherein 　　the request includes at least one of: 　　　　information indicating how many SSBs / CSI-RSs are required for measurements; 　　　　information indicating a number of SSBs / CSI-RSs to be transmitted; 　　　　information indicating a reason of the request; 　　　　information indicating how many repetitions of the transmission of the on-demand SSB / CSI-RS are required; or 　　　　information indicating at least one SCell.

14. The method according to any one of claims 7 to 13, wherein 　　the transmitting the request is performed by transmitting the request multiple times based on a timer.

15. The method according to claim 7 or 10, wherein 　　the at least one condition is related to at least one of: 　　　　time / frequency synchronization; 　　　　automatic gain control (AGC) setting; or 　　　　best downlink (DL) beam selection / update.

16. A method performed by an access network node, the method comprising: 　　transmitting, to a user equipment (UE), configuration information for on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB) / channel state information (CSI) reference signal (CSI-RS) for secondary cells (SCells), wherein 　　the configuration information is used by the UE for configuring on-demand SSB / CSI-RS.

17. A user equipment (UE) comprising: 　　means for receiving, from an access network node, configuration information for on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB) / channel state information (CSI) reference signal (CSI-RS) for secondary cells (SCells); and 　　means for configuring on-demand SSB / CSI-RS based on the configuration information.

Images