Method of mobile device, method of access network node, mobile device and access network node

Abstract

A method performed by a mobile device is described, the method comprising receiving configuration information including a plurality of parameters used for receiving an on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB) and in a case where one or more of the plurality of the parameters is absent in the configuration information, determining configuration on the one or more of the plurality of the parameters for the receiving the on demand SSB based on configuration for receiving an always on SSB.

Description

METHOD OF MOBILE DEVICE, METHOD OF ACCESS NETWORK NODE, MOBILE DEVICE AND ACCESS NETWORK NODE

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

[0002] The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (including Long Term Evolution (LTE)-Advanced, Next Generation or 5G / 6G networks, future generations, and beyond). The present disclosure in particular, but not exclusively, relates to the configurational aspects of on-demand synchronization signel / physical broadcast channel (PBCH) block (SSB) transmissions for secondary cells (SCells).

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

[0004] Under the 3GPP standards, a NodeB (or an eNB in LTE, and gNB in 5G) is the radio access network (RAN) node (or simply 'access node', 'access network node' or 'base station') via which communication devices (user equipments or 'UEs') connect to a core network and communicate with other communication devices or remote servers. For simplicity, the present application will use the term access network node, RAN node or base station to refer to any such access nodes.

[0005] For simplicity, the present application will use the term mobile device, user device, or UE to refer to any communication device that is able to connect to the core network via one or more RAN nodes. Although the present application may refer to mobile devices in the description, it will be appreciated that the technology described can be implemented on any communication devices (mobile and / or generally stationary) that can connect to a communication network for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0006] In the current 5G architecture, the gNB structure may be split into two or more parts. In some RAN implementations there are two parts, known as the Central Unit (CU or gNB-CU) - sometimes referred to as a 'control unit' - and the Distributed Unit (DU or gNB-DU), connected by an F1 interface. This enables the use of a 'split' architecture in which the typically 'higher' CU layers (for example, but not necessarily or exclusively, Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) layers) and the 'lower' DU layers (for example, but not necessarily or exclusively, Radio Link Control (RLC), Media (sometimes referred to as 'Medium') Access Control (MAC), and Physical (PHY) layers) are separated between a particular CU, and one or more DUs that are connected to and controlled by that CU via the F1 interface. Thus, for example, the higher layer CU functionality for a number of gNBs may be implemented centrally (for example, by a single processing unit, or in a cloud-based or virtualised system), whilst retaining the lower layer DU functionality locally separately for each gNB.

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

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

[0009] Further, as the usage of 5G mobile communication for a wide range of different use cases increases, their complexity and energy demands are also expected to increase. With this in mind, efforts are being made to enhance network energy saving (NES) approaches that afford significant power savings in an industry standardized manner. To that end, techniques / procedures have been evaluated that have shown to bring substantial NES gains. By way of example only, such techniques / procedures may include: -　　The application of 'SSB-less' or 'System Information Block 1 (SIB1)-less' operation in certain 'non-anchor' cells (e.g., secondary cells (SCells) and / or non-serving cells), which involves not transmitting SSBs or SIB1s in those cells. Instead, a UE may rely on an SSB or SIB1 transmission in a different 'anchor' cell for acquiring synchronisation and / or minimum system information. -　　The use of on-demand transmission, rather than automatic (periodic) transmission, of SSBs for camping onto certain cells (e.g., secondary cells (SCells) and / or non-serving cells) by UEs configured to connect to, and use, such cells; and -　　The use of on-demand transmission, rather than automatic (periodic) transmission, of system information block 1 (SIB1) for certain cells in which a UE is able to retrieve the system information carried by SIB1 by sending an uplink wake-up signal (WUS) to a corresponding RAN node and can perform synchronisation based on another cell in which SIB1 is transmitted.

[0010] For SSB transmission on a cell supporting on-demand SSB SCell operation, the SCell may be configured such that the only SSBs available in that cell are transmitted on-demand (i.e., there is no 'always-on' SSB transmission in that cell (referred to as case #1)). Nevertheless, the SCell may be configured such that 'always-on' SSBs are periodically transmitted in the cell (referred to as case #2).

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

[0012] More recently, 5G Reduced Capability (RedCap) - also known as 5G NR-Light - has been proposed that is a variant of 5G designed for applications that do not require high-performance attributes of conventional 5G technologies; in particular RedCap aims to meet the requirements of RedCap devices (e.g., IoT devices such as smartwatches, wearables, industrial sensors, and the like) that do not need to support high-performance attributes of conventional 5G technologies.

[0013] As part of the development of RedCap, Cell-Defining (CD) and Non-Cell-Defining (NCD) SSBs have been defined.

[0014] CD-SSBs are SSBs associated with remaining minimum system information (RMSI) and are located on the synchronisation raster. Such CD-SSBs are similar to conventional SSBs in that they are associated with a SIB1 and may be used by UEs (e.g., RedCap UEs) for cell detection and initial attach. The configuration of CD-SSBs transmitted in an SCell is typically provided to a UE by a RAN node as part of a serving cell configuration for that cell (e.g., as part of a ServingCellConfigCommon IE, or the like) via an appropriate RRC message, or the like.

[0015] The serving cell configuration associated with the CD-SSBs may, for example, include: an indication of time domain position of the transmitted CD-SSBs (e.g., in an ssb-PositionsInBurst IE); an indication of a periodicity of the transmitted CD-SSBs (e.g., in an ssb-periodicityServingCell IE); an indication of a subcarrier spacing (SCS) of the transmitted CD-SSBs (e.g., in an ssbSubcarrierSpacing IE); and a transmission power that may be used by the network for transmission of the CD-SSBs (e.g., in an ss-PBCH-BlockPower IE).

[0016] Moreover, as part of the CD-SSB configuration, the RAN node also typically provides an SSB frequency of the CD-SSBs for the SCell (e.g., in an absoluteFrequencySSB IE within an FrequencyInfoDL IE, or the like).

[0017] Furthermore, where a serving cell for which the CD-SSB configuration is provided also includes SCells (or where a RAN node decides to indicate / add a SCell to the serving cell that may be used by a UE via the CD-SSB configuration), the CD-SSB configuration may also typically provide appropriate information for detection of SSBs associated with a SCell. For example, the CD-SSB configuration may include an a SCell configuration (e.g., in a SCellConfig IE) that includes an SSB measurement timing configuration IE (SMTC IE) or the like to indicate a periodicity / offset / duration of a target cell for NR SCell addition (e.g., a target SCell to be added, or which is provided by the RAN node).

[0018] NCD-SSBs carry most of the same information as a CD-SSB except that they are not associated with SIB1 (or any other SIB) of a cell. Such NCD-SSBs are single-frequency signals that do not contain any information about the cell identity or location. They are therefore less complex and more power-efficient than the CD-SSBs. NCD-SSBs are typically used by UEs (e.g., RedCap UEs) for basic cell detection purposes like time synchronisation; radio link monitoring / measurement (RLM); beam failure detection (BFD); radio resource management (RRM); and the like. It will be appreciated that as such NCD-SSBs are not associated with SIB1 (or any other SIB) of a cell they cannot be used by UEs (e.g., RedCap UEs) for initial attach.

[0019] In the case of NCD-SSBs, rather than providing a full configuration for those NCD-SSBs, only a subset of the configuration information required may be provided via an RRC message, and remaining information needed for configuring the NCD-SSBs may be obtained by the UEs from the configuration associated with the CD-SSBs provided by the network.

[0020] For example, the configuration for NCD-SSBs typically includes an appropriate indication of an SSB frequency of the NCD-SSBs for the SCell (e.g., in absoluteFrequencySSB-r17 IE within a NonCellDefiningSSB-r17 IE contained with a BWP-DownlinkDedicated IE, or the like). Additionally, the configuration for NCD-SSBs typically includes an appropriate indication of a periodicity of the NCD-SSB transmissions for the SCells (e.g., in an ssb-periodicity-r17 IE), and an appropriate indication of a timing offset for the NCD-SSB transmissions for the SCells (e.g., in an ssb-TimeOffset-r17 IE).

[0021] All other configuration information necessary for the NCD-SSBs may then be obtained by the UEs from the configuration information associated with the CD-SSBs provided by the network. For example, for the NCD-SSBs, the UEs may use the indication of time domain position of the transmitted CD-SSBs (e.g., in an ssb-PositionsInBurst IE of the serving cell configuration associated with the CD-SSBs); the indication of a periodicity of the transmitted CD-SSBs (e.g., in an ssb-periodicityServingCell IE of the serving cell configuration associated with the CD-SSBs); the indication of a subcarrier spacing (SCS) of the transmitted CD-SSBs (e.g., in an ssbSubcarrierSpacing of the serving cell configuration associated with the CD-SSBs IE); and the transmission power that may be used by the network for transmission of the CD-SSBs (e.g., in an ss-PBCH-BlockPower IE of the serving cell configuration associated with the CD-SSBs).

[0022] In the context of a SCell that supports on-demand SSB operation, a RAN node may or may not configure an 'always-on' SSB (if transmitted) as a CD-SSB. Moreover, a RAN node may configure an on-demand SSB as a CD-SSB or may limit on-demand SSBs to being NCD-SSBs. However, as some of the configuration information required for the configuration of NCD-SSBs is derived from configuration information provided for CD-SSBs, if a CD-SSB is not configured in an SCell then a UE may not be able to use any NCD-SSBs transmitted in that SCell for certain procedures (e.g., synchronisation purposes) meaning that the UE will have to rely on the SSBs transmitted in another cell.

[0023] This is not ideal, especially in the context of carrier aggregation in which the primary cell (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), where relying on SSBs transmitted in a different cell for synchronisation as the time / frequency synchronization information (and the like) associated with the PCell on FR1 may not be appropriate for the SCells on FR2.

[0024] Appropriate configurational enhancements are therefore required in the context of a SCell that supports on-demand SSB operation to enable the SCell to carry out certain procedures (e.g., synchronisation purposes) using on-demand CD-SSBs, and NCD-SSBs without having to rely on SSBs transmitted in another cell.

[0025] <On-demand SSB detection for SCell> 　　In the context of a SCell that supports on-demand SSB operation, once the RAN node has provided an appropriate SSB configuration to a UE to allow the UE to receive on-demand SSBs for a SCell, those on-demand SSBs may be transmitted to the UE by the RAN node in response to either i) the UE requesting activation of a SCell by the RAN node, or ii) the RAN node deciding that a UE should use a SCell for communication with it. Typically, the activation of the SCell occurs when a UE receive an SCell activation command (e.g., a MAC control element (CE)) from the RAN node, although in certain circumstances a SCell for the UE may be activated at the time of its configuration by the RAN node (e.g., via an appropriate RRC message or the like).

[0026] In either case, upon activation, the UE needs to know when to expect to receive the on-demand SSBs for the SCell (or at least the starting position of the SSB burst containing the on-demand SSBs for the SCell).

[0027] Typically, for on-demand SSB SCell operation activated via a MAC CE as described above, the UE may expect an SSB burst for the SCell (e.g., on-demand SSBs for the SCell) to be transmitted by the RAN node at some specified time instance (e.g., time instance 'A'), which may be determined as the slot boundary of the first SSB time domain position (or simply the first SSB time domain position) of an 'actually' transmitted on-demand SSB burst which is T slots or symbols after the slot or symbol where the UE receives a SCell activation command (e.g., a MAC CE for SCell activation).

[0028] In this case, the first SSB time domain position is configured by the RAN node, and the value T may be configured / selected / determined such that it is not less than a time period required for the UE to process the SCell activation command (e.g., a MAC CE for SCell activation).

[0029] The value T itself may be provided to the UE by the RAN node (e.g., as an indication of a number of slots or symbols with respect to the numerology of the PCell of the serving cell), or otherwise the value T may be determined by the UE (e.g., based on the on-demand configuration for the SCell provided to the UE by the RAN node).

[0030] However, in the scenario where the value T is provided to the UE by the RAN node, as it is provided as an indication of a number of slots or symbols with respect to the numerology of the PCell of the serving cell, the units (size) of the slots or symbols indicated by the RAN node may not match up with slots or symbols of the SCell given that the PCell and the SCell may operate on different numerologies (e.g., they may operate on difference subcarrier spacings).

[0031] This may in turn mean that in cases where the value T is provided to the UE by the RAN node, there is a risk that the slot or symbol in which the on-demand SSB transmissions for the SCell may be determined incorrectly by the UE. This issue is further complicated in cases where the PCell and the SCell are not fully synchronised, in which case the PCell may only know the approximate time when on-demand SSBs for the are to be transmitted.

[0032] There is therefore also a need to develop enhanced procedures for indicating start positions of on-demand SSBs for an SCell, especially in the case where the determination of such start positions by a UE are determined based on timing information provided by a RAN node over a PCell that operates in a different numerology to the SCell.

[0033] <On-demand SSB Commencement for SCells - Additional UEs> 　　In the context of a SCell that supports on-demand SSB operation, once the RAN node has provided an appropriate SSB configuration to a UE to allow the UE to receive on-demand SSBs for a SCell, and appropriate timing information has been indicated to the UE to allow it to identify when to expect on-demand SSBs for the SCell, the UE can receive those SSBs, and use those SSBs as appropriate.

[0034] However, as will be appreciated, in real world scenarios the SCell being provided for the UE may in fact be provided for multiple UEs. In this scenario, UEs within the communication system, via appropriate SCell configuration messages (e.g., RRC message, or the like), may be configured (and reconfigured) to add (or remove) SCell available for the UEs. Accordingly, situations may occur wherein a first UE configured to use a SCell may be currently receiving on-demand SSBs for that SCell at a time when the network configures a second (or more) UEs to use the same SCell.

[0035] In this scenario activation of the SCell is not necessary, however the second (or more) UEs newly configured to use the SCell may not be aware of the status (e.g., activation) of the SCell, nor where they should assume on-demand SSB commencement to occur from their perspective.

[0036] There is therefore also a need to develop appropriate procedures to enable a UE to be informed when an SCell for which they are newly configured is already activated and transmitting SSBs, and to allow the UE to determine when it should start searching for those SSBs.

[0037] The disclosure aims to provide one or more apparatus and / or one or more associated methods that at least partially addresses or contributes to addressing one or more of the above need.

[0038] The disclosure has a method performed by a mobile device, the method comprising receiving configuration information including a plurality of parameters used for receiving an on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB); and in a case where one or more of the plurality of the parameters is absent in the configuration information, determining configuration on the one or more of the plurality of the parameters for the receiving the on demand SSB based on configuration for receiving an always on SSB.

[0039] The disclosure has a method performed by an access network node, the method comprising transmitting, to a mobile device, configuration information including a plurality of parameters used by the mobile device for receiving an on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB), and wherein in a case where one or more of the plurality of the parameters is absent in the configuration information, configuration on the one or more of the plurality of the parameters for the receiving the on demand SSB is determined by the mobile device based on configuration for receiving an always on SSB.

[0040] The disclosure has a mobile device comprising means for receiving configuration information including a plurality of parameters used for receiving an on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB); and means for determining configuration on one or more of the plurality of the parameters for the receiving the on demand SSB based on configuration for receiving an always on SSB, in a case where the one or more of the plurality of the parameters is absent in the configuration information.

[0041] The disclosure has an access network node comprising means for transmitting, to a mobile device, configuration information including a plurality of parameters used by the mobile device for receiving an on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB), and wherein in a case where one or more of the plurality of the parameters is absent in the configuration information, configuration on the one or more of the plurality of the parameters for the receiving the on demand SSB is determined by the mobile device based on configuration for receiving an always on SSB.

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

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

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

[0045] Fig. 1 schematically illustrates a ('cellular' or 'wireless') communication system;Fig. 2 schematically illustrates a RAN node of the communication system 1 and anchor / non-anchor cell coverage provided by the RAN node to a UE;Fig. 3A illustrates an example way in which an SCell may be configured to receive SSBs for that SCell;Fig. 3B illustrates an example way in which an SCell may be configured to receive SSBs for that SCell;Fig. 3C illustrates an example way in which an SCell may be configured to receive SSBs for that SCell;Fig. 4 illustrates a simplified sequence diagram illustrating a procedure for on-demand SCell SSB transmissions to a UE triggered by a RAN node that may be used in the communication system of Fig. 1;Fig. 5 illustrates an example SSB configuration for SCell on-demand (CD)-SSBs that may be provided to a UE to configure on-demand SSBs for a SCell when no 'always-on' SSBs are provided for the SCell;Fig. 6 illustrates an example SSB configuration for SCell on-demand (NCD)-SSBs that may be provided to a UE to configure on-demand SSBs for a SCell when no 'always-on' SSBs are provided for the SCell;Fig. 7 illustrates an example SSB configuration for SCell on-demand (NCD)-SSBs that may be provided to a UE to configure on-demand SSBs for a SCell when no 'always-on' SSBs are provided for the SCell;Fig. 8 illustrates an example of an SSB configuration for SCell on-demand SSBs that may be provided to a UE to configure on-demand SSBs for a SCell when 'always-on' SSBs are provided for the SCell in the same frequency;Fig. 9 illustrates an example of an SSB configuration for SCell on-demand SSBs that may be provided to a UE to configure on-demand SSBs for a SCell when 'always-on' SSBs are provided for the SCell in a different frequency;Fig. 10 illustrates another example of an SSB configuration for SCell on-demand SSBs that may be provided to a UE to configure on-demand SSBs for a SCell when 'always-on' SSBs are provided for the SCell in a different frequency;Fig. 11 illustrates an example timeline of slots for transmissions over the PCell (also referred to a 'reference' cell) and a timeline of slots for transmissions of an SSB burst over an SCell;Fig. 12 illustrates another example timeline of slots for transmissions over the PCell (also referred to a 'reference' cell) and a timeline of slots for transmissions of an SSB burst over an SCell;Fig. 13 illustrates yet another example timeline of slots for transmissions over the PCell (also referred to a 'reference' cell) and a timeline of slots for transmissions of an SSB burst over an SCell;Fig. 14 illustrates yet another example timeline of slots for transmissions over the PCell (also referred to a 'reference' cell) and a timeline of slots for transmissions of an SSB burst over an SCell;Fig. 15 illustrates yet another example timeline of slots for transmissions over the PCell (also referred to a 'reference' cell) and a timeline of slots for transmissions of an SSB burst over an SCell;Fig. 16 illustrates a timeline for the reception of SCell configurations, SCell activation commands, and on-demand SSB transmissions for a first UE and a second UE ;Fig. 17 is a simplified block schematic illustrating the main components of a UE for implementation in the system of Fig. 1; andFig. 18 is a simplified block schematic illustrating the main components of a RAN node for implementation in the system of Fig.1.

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

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

[0048] In the communication system 1, user equipments (UEs) 3 (3-1, 3-2, 3-3) (e.g., mobile telephones and / or other mobile or stationary devices) can communicate with each other via a (radio) access network ((R)AN) node 5 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, the RAN node 5 comprises a base station 5 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)) or any other core network.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0063] A number of different DCI formats can be used by the RAN node 5, depending on requirements, for transmission on a PDCCH corresponding to one of the PDCCH candidates in one of the search spaces configured for a given UE 3. For example, the RAN node 5 may be able to transmit DCI using one or more of the currently standardised DCI formats as set out in Table 1.

[0064] Different DCI formats may or may not have the same DCI size. Moreover, DCI may be addressed (scrambled) using different radio network temporary identifiers (RNTIs) that a UE 3 may monitor for. Typically, a UE 3 is capable of monitoring up to three different DCI sizes for DCI formats using a cell RNTI (C-RNTI) - typically used as an identifier for scheduling purposes. Additionally, a UE 3 is typically capable of monitoring one additional DCI size using other RNTIs for specific purposes (e.g., a slot format indication RNTI (SFI-RNTI), interruption RNTI (INT-RNTI), or the like). This constraint is sometimes referred to as the "3+1" size budget and is imposed because a DCI scrambled with a C-RNTI is, generally, more time critical than a DCI scrambled with a RNTI used for another specific purpose, and so requires the UE 3 to decode it promptly in order to be able to process the scheduled data transmission.

[0065] To take account of the constraint imposed by the DCI size budget, the sizes of some DCI formats may be aligned by padding, truncation, and / or determining a frequency domain resource assignment field differently.

[0066] A UE 3 may monitor a set of PDCCH candidates in one or more control resource sets (CORESETs) on an active DL bandwidth part, where monitoring implies decoding each PDCCH candidate according to the monitored DCI formats. The number of blind decodes (BDs) may be restricted on a per carrier basis of a serving cell. The number of BDs may refer to the number of monitored PDCCH candidates or the number of PDCCH candidates a UE is capable of decoding within a certain time frame, such as a slot or span of consecutive symbols in a slot. As an example, at a 15 kHz subcarrier spacing (SCS), the maximum number of BDs per slot per serving cell supported by a UE 3 may be 44 BDs.

[0067] <Synchronisation Signal / Physical Broadcast Channel (PBCH) Blocks (SSBs)> 　　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).

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

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

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

[0071] Each UE 3 may also be configured to search for SSBs associated with SCells when scanning for SCells to camp on and to decode the associated PBCH before proceeding to decode other system information transmitted on the PDSCH, rather than rely on SSBs associated with the PCell. Given that SCells are not typically used by 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.

[0072] <Cell-Defining (CD) and Non-Cell-Defining (NCD) SSBs> 　　The RAN node 5 and UEs 3 of the communication system 1 are also configured to support Cell-Defining (CD) and Non-Cell-Defining (NCD).

[0073] Specifically, the RAN node 5 is configured to provide configuration information for CD-SSBs transmitted in an SCell to a UE 3 as part of a serving cell configuration for that cell (e.g., as part of a ServingCellConfigCommon IE, or the like) via an appropriate RRC message, or the like. The serving cell configuration associated with the CD-SSBs may, for example, include: an indication of time domain position of the transmitted CD-SSBs (e.g., in an ssb-PositionsInBurst IE); an indication of a periodicity of the transmitted CD-SSBs (e.g., in an ssb-periodicityServingCell IE); an indication of a subcarrier spacing (SCS) of the transmitted CD-SSBs (e.g., in an ssbSubcarrierSpacing IE); and a transmission power that may be used by the network for transmission of the CD-SSBs (e.g., in an ss-PBCH-BlockPower IE). Moreover the RAN node 5 is configured to provide, as part of the CD-SSB configuration, an SSB frequency of the CD-SSBs for the SCell (e.g., in an absoluteFrequencySSB IE within an FrequencyInfoDL IE, or the like).

[0074] The RAN node 5 is also configured to provide configuration information for NCD-SSBs. For example, the configuration for NCD-SSBs typically includes an appropriate indication of an SSB frequency of the NCD-SSBs for the SCell (e.g., in absoluteFrequencySSB-r17 IE within a NonCellDefiningSSB-r17 IE contained with a BWP-DownlinkDedicated IE, or the like). Additionally, the configuration for NCD-SSBs typically includes an appropriate indication of a periodicity of the NCD-SSB transmissions for the SCells (e.g., in an ssb-periodicity-r17 IE), and an appropriate indication of a timing offset for the NCD-SSB transmissions for the SCells (e.g., in an ssb-TimeOffset-r17 IE).

[0075] <On-Demand SSB in the context of 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.

[0076] In CA, when initially scanning for a cell to camp on each UE 3 scans for a PCell. The PCell 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.

[0077] As and when required, the UE 3 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 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.

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

[0079] A group of serving cells associated with a master RAN node 5 may be referred to as a master cell group (MCG). The MCG typically comprises a so called special cell (SpCell) which is the PCell (Primary Cell), and one or more SCells. A group of serving cells associated with a secondary RAN node 5 may be referred to as a secondary cell group (SCG). The SCG typically comprises an SpCell, which is known as a primary SCell (PSCell) in this case, and one or more SCells.

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

[0081] 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 acquire SSBs on-demand SSB and to search for SSBs associated with SCells only when the UE 3 (or network) decides that it wishes to utilise one or more SCells.

[0082] There are a number of scenarios to which such on demand SSB transmission for an SCell may be appropriate. For example, a scenario involving a downlink only SCell that is otherwise without SSB transmission but with tracking reference signals (TRS) / aperiodic TRS (A-TRS) DL transmissions, a scenario involving an SCell that is otherwise without SSB transmission and without any other downlink transmissions, but with uplink reception at the NW side), and / or the like.

[0083] On-demand SSB transmission may be enabled semi-statically or dynamically. For example, common channel adaptation and / or on-demand SSB may be enabled via dedicated RRC signalling on a PCell and / or PSCell if the UE has a PCell and / or PSCell connection. On-demand SSB may be enabled via system information (e.g., where the content of system information includes a carrier indication field to indicate the applicable carrier / cell for the enabling of on-demand SSB transmission). On-demand SSB may be enabled via a DCI with an appropriate DCI format (e.g., DCI format 1_0 with a cyclic redundancy check (CRC) scrambled with a system information RNTI (SI-RNTI), for example that includes a carrier indication field to indicate the applicable carrier / cell for the system information to be transmitted.

[0084] By way of example, Fig. 2 schematically illustrates a RAN node 5 of the communication system 1 and PCell and SCell coverage provided by the RAN node 5 to a UE 3.

[0085] As shown in Fig. 2, in the illustrated example, the RAN node 5 provides a first serving (primary) cell (e.g., PCell 9-1). Additionally, the RAN node 5 also provides one or more other cells (other than the PCell) for the UE 3 to communicate via using CA. In this example, the RAN node 5 provides a secondary cell (e.g., SCell 9-2) that the UE 3 may access at some later time after initially camping onto the serving cell.

[0086] As shown in Fig. 2, the SCell 9-2 may be a cell that is a smaller cell overlapping with, or wholly incorporated within, the PCell 9-1. The SCell 9-2, unlike the PCell 9-1, may be a cell over which UEs 3 cannot (or at least cannot routinely) receive SSBs and / or system information (e.g., SIB messages). For example, the SCell 9-2 may be configured as an SSB-less cell or a cell in which SSBs are not sent periodically, but rather are sent on an on-demand basis.

[0087] A number of ways in which the SCell 9-2 may be configured will now be described, by way of example only, with respect to Fig. 3.

[0088] Fig. 3A illustrates one example SSB transmission procedure that may be implemented to allow time / frequency synchronization, L1 / L3 measurements, SCell activation, and the like for SCells 9-2.

[0089] As shown in Fig. 3A, the SCell 9-2 may be configured to transmit SSBs periodically ('always-on' SSBs; also referred to as 'Case#2'). That is to say, the SCell 9-2 may not be able to function using an SSB-less operation, but instead the SCell 9-2 may be configured to provide SSBs always in a periodical manner.

[0090] Fig. 3B illustrates another example SSB transmission procedure that may be implemented to allow time / frequency synchronization, L1 / L3 measurements, SCell activation, and the like for SCells 9-2.

[0091] As shown in Fig. 3B, the SCell 9-2 may be configured to provide SSBs on an on-demand basis ('no-always-on' SSBs; also referred to as 'Case#1'). For example, rather than always transmitting SSBs over the SCell 9-2 in a periodic manner as in Fig. 3A, the SSBs may only be transmitted to the UE 3 in the event that the UE 3, and / or RAN node 5 providing the SCell 9-2, specifically requests the SSBs (e.g., if / when the UE 3, and / or RAN node 5 providing the SCell 9-2, triggers activation of the SCell 9-2, or the like).

[0092] Fig. 3C illustrates yet another example SSB transmission procedure that may be implemented to allow time / frequency synchronization, L1 / L3 measurements, SCell activation.

[0093] As shown in Fig. 3C, the SCell 9-2 may be configured to provide a combination of 'always-on' SSBs (also referred to as 'Case#2') and on-demand SSBs. For example, the SCell 9-2 may be configured to provide always-on SSBs in a periodically manner; however in the event that the periodicity of the SSB transmissions are such that they are deemed inefficient for the purposes of enabling time / frequency synchronization, L1 / L3 measurements, SCell activation, and the like, a UE 3, and / or a RAN node 5 providing the SCell 9-2, may trigger on-demand SSB transmissions in addition to the periodic always-on SSB transmissions to supplement the periodic always-on transmissions. For example, the triggered on-demand SSB transmissions may occur more regularly than the periodic always-on SSB transmissions.

[0094] For completeness, an example of a typical procedure for on-demand SCell SSB transmissions to a UE 3 that may be used in the communication system 1 will now be described in detail with reference to Fig. 4.

[0095] Fig. 4 depicts 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.

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

[0097] 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 9-2 is enabled. Specifically, for each SCell 9-2, the RAN node 5 may indicate whether SSBs are to be transmitted: i) on-demand based on a network trigger (i.e., a trigger at the RAN node 5), and / or ii) on-demand based on the RAN node 5 receiving requests for on-demand SSBs from the UE 3.

[0098] The RAN node 5 may indicate to the UE 3 that transmission of on-demand SSBs for one or more SCells 9-2 is enabled, and the basis on which SSBs will be transmitted (e.g., based on a network trigger or a request from the UE 3) within an appropriate serving cell configuration message e.g., a configuration message sent to configure the UE 3 to camp onto a serving cell of the RAN node 5, where a serving cell in carrier aggregation (CA) may consist of one primary cell (PCell 9-1) and several secondary cells (e.g., SCell 9-2). 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.

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

[0100] The SSB configuration in the ServingCellConfigCommon IE may also indicate additional appropriate information needed to facilitate on-demand SSB transmission occasions for SCells 9-2. For example, it may include an indication to the UE 3 that transmissions of on-demand SSBs for one or more SCells 9-2 is enabled, and the basis on which they will be transmitted (e.g., based on a network trigger or a request from a UE 3). The 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 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.

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

[0102] When on-demand SSB transmissions for one or more SCells 9-2 has been triggered, the RAN node 5 transmits, at step S304, an SCell activation command for the one or more SCells 9-2 to the UE 3. The SCell activation command may be included in any appropriate command message to be sent by the RAN node 5 to the UE 3 on the PDSCH (e.g., over the PCell 9-1).

[0103] At step S406, having received the SCell activation command at step S404, the UE 3 is triggered to monitor for SCell SSB transmissions for the SCell 9-2 indicated in the SCell activation command (e.g., SCell 9-2). For example, the UE 3 may be triggered to monitor for SCell SSB transmissions for a specific duration (e.g., in a specific monitoring window).

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

[0105] Having successfully received the SCell SSB transmissions (and optionally having successfully transmitted appropriate feedback messages to the RAN node 5), the UE 3 may consider the SCell 9-2 as activated (S410) and start normal SCell operations (e.g. PDCCH monitoring, SRS transmission, and the like).

[0106] <Configurational Enhancements for On-Demand SSB> 　　Beneficially, the communication system 1 is configured to support one or more enhancements to how on-demand SSBs are configured to a UE 3.

[0107] For example, as described in more detail later, the communication system 1 may be configured to support one or more enhancements to the way in which NCD-SSBs and / or CD-SSBs are configured that allow the use of on-demand NCD-SSBs for synchronisation even if a corresponding CD-SSB has not been configured.

[0108] Moreover, as described in more detail later, the communication system 1 may be configured to support one or more enhancements to the way in which the timing of when on-demand SSB will be transmitted by the RAN node 5 is configured to / determined by the UE 3.

[0109] Moreover, as described in more detail later, the communication system 1 may be configured to support one or more enhancements to the way in which commencement / immediate availability of on-demand SSB transmissions may be indicated to / determined by the UE 3 where appropriate.

[0110] Several enhancements to the configurational framework for on-demand SSBs that may be implemented in the communication system 1 of Fig. 1 will now be described in detail with reference to Figs. 5 to 10.

[0111] <Enhanced Configuration Framework for On-demand SSBs> <Case#1: No 'always-on' SSBs for SCell (on-demand SSBs for SCell only)> 　　As alluded earlier, with the development of RedCap and the introduction of CD-SSBs and NCD-SSBs, when configuring on-demand SSBs for a SCell 9-2, a RAN node 5 now has the possibility of configuring CD-SSBs and / or NCD-SSBs for use in on-demand SSB transmissions for the SCell 9-2.

[0112] In the scenario where the RAN node 5 wishes to configure CD-SSBs for use in on-demand SSB transmissions for the SCell 9-2, an appropriate SSB configuration may need to be provided by the RAN node 5 to the UE 3 to ensure that the UE 3 has sufficient information to allow it to perform procedures such as time synchronisation. This is especially the case in the context of scenarios where no 'always-on' SSBs are provided for the SCell 9-2.

[0113] By way of example only, Fig. 5 illustrates an example SSB configuration for SCell on-demand (CD)-SSBs that may be provided to the UE 3 by the RAN node 5 to configure on-demand SSBs for the SCell 9-2 when no 'always-on' SSBs are provided for the SCell 9-2.

[0114] As shown in Fig. 5, an appropriate on-demand SSB configuration for the SCell 9-2, in the context of when no 'always-on' SSBs are provided for the SCell 9-2 and where the RAN node 5 wishes to provide on-demand CD-SSBs, may include (reuse) all of the configuration information / parameters that are typically included for a serving cell configuration associated with CD-SSBs as previously described.

[0115] For example, the appropriate SSB configuration may include (e.g., within a ServingCellConfigCommon IE, or the like): an indication of time domain position of the transmitted CD-SSBs (e.g., in an ssb-PositionsInBurst IE); an indication of a periodicity of the transmitted CD-SSBs (e.g., in an ssb-periodicityServingCell IE); an indication of a subcarrier spacing (SCS) of the transmitted CD-SSBs (e.g., in an ssbSubcarrierSpacing IE); and a transmission power that may be used by the network for transmission of the CD-SSBs (e.g., in an ss-PBCH-BlockPower IE).

[0116] Additionally, the SSB configuration may include (e.g., within a ServingCellConfigCommon IE, or the like), other new IEs that may indicate other appropriate information needed for performing time synchronisation using the on-demand SSBs for the SCell 9-2. For example, an appropriate IE may be provided to indicate to the UE 3 whether the SSBs for the SCell 9-2 are transmitted periodically or on an on-demand basis (e.g., in an Is-on-demand IE).

[0117] Additionally, the SSB configuration may include (e.g., within a ServingCellConfigCommon IE, or the like), any other new appropriate IEs to indicate other appropriate information needed for performing time synchronisation using the on-demand SSBs for the SCell 9-2 (e.g., On-demand SSB param1, On-demand SSB param2, On-demand SSB param3, etc.).

[0118] It will be appreciated that the above example SSB configuration may also be used in the scenario where the on-demand SSBs for the SCell 9-2 provided by the RAN node 5 are a combination of CD-SBBs and NCD-SSBs. For example, it will be appreciated that in the case where the RAN node 5 is able to provide some on-demand SSBs that are CD-SSBs and some on-demand SSBs that are NCD-SSBs, then by virtue of some of the on-demand SSBs being CD-SSBs, the SSB configuration may include (reuse) all of the configuration information / parameters that are typically included for a serving cell configuration associated with CD-SSBs.

[0119] Alternatively, in the scenario where the RAN node 5 wishes to configure NCD-SSBs for use in on-demand SSB transmissions for a SCell 9-2, a different appropriate SSB configuration may need to be provided by the RAN node 5 to the UE 3 to ensure that the UE 3 has sufficient information to allow it to perform procedures such as time synchronisation. This is especially the case in the context of scenarios where no 'always-on' SSBs are provided for the SCell 9-2.

[0120] By way of example only, Fig. 6 illustrates an example SSB configuration for SCell on-demand (NCD)-SSBs that may be provided to the UE 3 by the RAN node 5 to configure on-demand SSBs for the SCell 9-2 when no 'always-on' SSBs are provided for the SCell 9-2.

[0121] As shown in Fig. 6, an appropriate on-demand SSB configuration for the SCell 9-2, in the context of when no 'always-on' SSBs are provided for the SCell 9-2 and where the RAN node 5 wishes to provide on-demand NCD-SSBs, may include all configuration information / parameters that are typically required NCD-SSBs as previously described; that is to say the on-demand SSB configuration may include both information / parameters that are provided specifically for NCD-SSBs, along with a subset of information / parameters that are typically provided in a serving cell configuration associated with CD-SSBs, and which are common parameters for both CD-SSBs and NCD-SSBs.

[0122] For example, the appropriate SSB configuration may include (e.g., within a NonCellDefiningSSB-r17 IE, or the like): an appropriate indication of an SSB frequency of the NCD-SSBs for the SCell 9-2 (e.g., in absoluteFrequencySSB-r17 IE), an SSB periodicity for the NCD-SSBs (e.g., in a ssb-Periodicity-r17 IE). Optionally, the SSB configuration may also include a timing offset indication (e.g., in an ssb-TimeOffset-r17 IE). These parameters, it will be appreciated, as specific to NCD-SSBs and are typically found in the NonCellDefiningSSB-r17 IE provided when configuring NCD-SSBs.

[0123] Additionally, the appropriate SSB configuration may also include (e.g., within a NonCellDefiningSSB-r17 IE, or the like) common IEs that are needed for configuring NCD-SSBs, but which are typically extracted by the UE 3 from the serving cell configuration associated with CD-SSB provided by the cell. These common parameters may include, for example: an indication of a subcarrier spacing of the SSBs (e.g., in an ssbSubcarrierSpacing IE), an indication of time domain position of the transmitted SSBs (e.g., in an ssb-PositionsInBurst IE); an indication of a periodicity of the transmitted SSBs (e.g., in an ssb-periodicityServingCell IE); an indication of a subcarrier spacing (SCS) of the transmitted SSBs (e.g., in an ssbSubcarrierSpacing IE); and a transmission power that may be used by the network for transmission of the SSBs (e.g., in an ss-PBCH-BlockPower IE).

[0124] It will be appreciated that beneficially, by including, within the NonCellDefiningSSB-r17 IE of the new proposed SSB configuration described above with reference to Fig. 6 to configure on-demand NCD-SSBs, appropriate common IEs that are typically needed for configuring NCD-SSBs, but which are usually obtained by the UE 3 from a serving cell configuration associated with CD-SSBs provided by the cell (e.g., ssbSubcarrierSpacing, ssb-PositionsInBurst ss-PBCH-BlockPower), the UE 3 can use those on-demand NCD-SSBs to performing time synchronisation for the SCell 9-2.

[0125] More specifically, while the absence of 'always-on' SSBs would usually mean that UE 3 will not be configured with the IE absoluteFrequencySSB and thus the IEs ssbSubcarrierSpacing ssb-PositionsInBurst, ss-PBCH-BlockPower located within a CD-SSB serving cell configuration will also not be provided, by providing those IEs within the new proposed SSB configuration for on-demand NCD-SSBs for the SCell 9-2, the UE 3 can use those on-demand NCD-SSBs to perform time synchronisation for the SCell 9-2.

[0126] Additionally, the appropriate SSB configuration may also include (e.g., within a NonCellDefiningSSB-r17 IE, or the like) other new IEs that may indicate other appropriate information needed for performing time synchronisation using the on-demand NCD-SSBs for the SCell 9-2. For example, an appropriate IE may be provided to indicate to the UE 3 whether the SSBs for the SCell 9-2 are transmitted periodically or on an on-demand basis (e.g., in an Is-on-demand IE).

[0127] Additionally, the SSB configuration may include (e.g., within a NonCellDefiningSSB-r17 IE, or the like), any other new appropriate IEs to indicate other appropriate information needed for performing time synchronisation using the on-demand NCD-SSBs for the SCell 9-2 (e.g., On-demand SSB param1, On-demand SSB param2, On-demand SSB param3, etc.).

[0128] In the case of the optional parameters described above (e.g.) the ssb-TimeOffset-r17 IE), these parameters may not be included in the SSB configuration if ServingCellConfigCommon parameters (e.g., the common IEs that are needed for configuring NCD-SSBs but which are typically extracted by the UE 3 from the serving cell configuration associated with CD-SSB provided by the cell) are vacant.

[0129] Alternatively, rather than using either of the SSBs configurations depicted in Figs. 5 and 6, which rely on the reuse of IEs associated with typical SSB configurations for CD-SSBs and NCD-SSBs, a SSB configuration with a whole new IE may be provided within a ServingCellConfigCommon IE always, an ServingCellConfigCommon IE when the on-demand SSBs to be provided by the RAN node 5 are CD-SSBs, or otherwise in another location (e.g., in NonCellDefiningSSB-r17 IE).

[0130] Alternatively, it will be appreciated that current IEs of ServingCellConfigCommon IE (e.g., ssbSubcarrierSpacing, ssb-PositionsInBurst, ss-PBCH-BlockPower) may be reused to provide the values for on-demand SSB (even though absoluteFrequencySSB within FrequencyInfoDL may be absent). Hence, the current IEs of ServingCellConfigCommon IE can be configured if either absoluteFrequencySSB within FrequencyInfoDL is included or if on-demand SSB configuration is provided using NonCellDefiningSSB IE.

[0131] By way of example only, Fig. 7 illustrates an example of an SSB configuration for SCell on-demand SSBs that may be provided to the UE 3 by the RAN node 5 to configure on-demand SSBs for the SCell 9-2 when no 'always-on' SSBs are provided for the SCell 9-2.

[0132] As shown in Fig. 7, in the context of when no 'always-on' SSBs are provided for the SCell 9-2, rather providing a new appropriate SSB configuration, a whole new IE (e.g., On-demandSSB IE) may be provided within a ServingCellConfigCommon IE always, an ServingCellConfigCommon IE when the on-demand SSBs to be provided by the RAN node 5 are CD-SSBs, or otherwise in another location (e.g., in NonCellDefiningSSB-r17 IE).

[0133] Within that On-demandSSB IE there may be provided: an appropriate indication of an SSB frequency of the CD-SSBs for the SCell 9-2 (e.g., in an absoluteFrequencySSB IE), an indication of a subcarrier spacing of the SSBs (e.g., in an ssbSubcarrierSpacing IE), an indication of time domain position of the transmitted SSBs (e.g., in an ssb-PositionsInBurst IE); an indication of a periodicity of the transmitted SSBs (e.g., in an ssb-Periodicity IE); and a transmission power that may be used by the network for transmission of the SSBs (e.g., in an ss-PBCH-BlockPower IE); and optionally an indication of a timing offset for the SSBs (e.g., in a sbb-TimeOffset IE).

[0134] It will be appreciated that beneficially, by including, within the On-demandSSB IE of the new proposed SSB configuration described above with reference to Fig. 6 to configure on-demand SSBs for the SCell 9-2, appropriate common IEs that are typically needed for configuring SSBs, (e.g., ssbSubcarrierSpacing, ssb-PositionsInBurst ss-PBCH-BlockPower), the UE 3 can use those on-demand SSBs to performing time synchronisation for the SCell 9-2.

[0135] More specifically, while the absence of 'always-on' SSBs would usually mean that UE 3 will not be configured with the IE absoluteFrequencySSB and thus the IEs ssbSubcarrierSpacing ssb-PositionsInBurst, ss-PBCH-BlockPower located within a CD-SSB serving cell configuration will also not be provided, by providing those IEs within the new proposed SSB configuration for on-demand SSBs for the SCell 9-2, the UE 3 can use those on-demand SSBs to perform time synchronisation for the SCell 9-2.

[0136] Additionally, within that On-demandSSB IE there may be provided other new IEs that may indicate other appropriate information needed for performing time synchronisation using the on-demand SSBs for the SCell 9-2. For example, an appropriate IE may be provided to indicate to the UE 3 whether the SSBs for the SCell 9-2 are transmitted periodically or on an on-demand basis (e.g., in an Is-on-demand IE).

[0137] Additionally, within that On-demandSSB IE there may be provided any other new appropriate IEs to indicate other appropriate information needed for performing time synchronisation using the on-demand SSBs for the SCell 9-2 (e.g., On-demand SSB param1, On-demand SSB param2, On-demand SSB param3, etc.).

[0138] In the case of the optional parameters described above (e.g. the ssb-TimeOffset IE), these parameters may not be included in the SSB configuration if ServingCellConfigCommon parameters (e.g., absoluteFrequencySSB, ssb-Periodicity, ssbSubcarrierSpacing ssb-PositionsInBurst, and ss-PBCH-BlockPower) are vacant.

[0139] It will nevertheless be appreciated that that some of current IEs can be reused to provide the configuration instead of using the new parameters such as those outlined above. For example, the current IEs of ServingCellConfigCommon (e.g., ssbSubcarrierSpacing, ssb-PositionsInBurst, ss-PBCH-BlockPower) may be reused to provide the information for on-demand SSB. Hence, the current IEs of ServingCellConfigCommon can be configured if either absoluteFrequencySSB within FrequencyInfoDL is included or if on-demand SSB configuration is provided using the new On-demandSSB IE.

[0140] <Case#2: 'Always-on' SSBs for SCell + on-demand SSBs for SCell> 　　In the scenario where 'always-on' SSB are provided for the SCell 9-2 and the RAN node 5 wishes to configure CD-SSBs or NCD-SSBs for use in on-demand SSB transmissions as well for the SCell 9-2 and (e.g., in scenarios where latency critical procedure like SCell activation or L1-based measurement triggers require on-demand SSBs), an appropriate SSB configuration for the on-demand (CD / NCD)-SSBs may still need to be provided by the RAN node 5 to the UE 3 to ensure that the UE 3 has sufficient information to allow it to perform procedures such as time synchronisation.

[0141] Beneficially however, as 'always-on' SSB are provided for the SCell 9-2, those 'always-on' SSBs may be used as CD-SSBs and may be configured by the RAN node 5 in an appropriate configuration that reuses the IEs typically found in an SSB configuration for CD-SSBs.

[0142] It will be appreciated that where the 'always-on' SSBs for the SCell 9-2 are used as CD-SSBs, then, where the on-demand SSBs for the SCell 9-2 are to be transmitted in the same frequency as the 'always-on' SSBs, the configuration information / parameters necessary for configuring the on-demand SSBs for the SCell 9-2 may be provided alongside the configuration information / parameters for the CD-SSBs (e.g., the 'always-on' SSBs).

[0143] By way of example only, Fig. 8 illustrates an example of an SSB configuration for SCell on-demand SSBs that may be provided to the UE 3 by the RAN node 5 to configure on-demand SSBs for the SCell 9-2 when 'always-on' SSBs are provided for the SCell 9-2 in the same frequency.

[0144] As shown in Fig. 8, in the context of when 'always-on' SSBs are provided for the SCell 9-2 in addition to on-demand SSBs (either CD-SSBs or NCD-SSBs) and the 'always-on' SSBs are used as CD-SSBs, then an adapted version of a typical CD-SSB serving cell configuration may be used to configure the on-demand SSBs.

[0145] For example, an adapted version of a cell configuration associated with the CD-SSBs may be provided which, for example, includes: an indication of time domain position of the transmitted CD-SSBs (e.g., in an ssb-PositionsInBurst IE); an indication of a periodicity of the transmitted CD-SSBs (e.g., in an ssb-periodicityServingCell IE); an indication of a subcarrier spacing (SCS) of the transmitted CD-SSBs (e.g., in an ssbSubcarrierSpacing IE); and a transmission power that may be used by the network for transmission of the CD-SSBs (e.g., in an ss-PBCH-BlockPower IE).

[0146] Additionally, the adapted version of a cell configuration associated with the CD-SSBs may, for example, include: an indication of an on-demand SSB timing offset which indicate the time occasions where on-demand SSB burst can be received with respect to an always-on SSB burst (e.g., in a On-demand SSB-timeoffset IE), an indication of an on-demand SSB periodicity to provide additional periodicity information for the on-demand SSBs other than periodicity of 'always-on' SSB (e.g., in a On-demand-SSB-Periodicity IE), along with other appropriate IEs that may be used to provide additional information necessary for using the on-demand SSBs of the SCell 9-2. For example, an Additional on-demand-SSB IE to indicate the presence of additional on-demand SSB (on top of always-on SSB) to differentiate between Case#1 (only on-demand SSB) and Case#2 (on-demand SSB and always-on SSB, an On-demand SSB param1 IE, an On-demand SSB param2 IE, etc.

[0147] With respect to the Additional on-demand-SSB IE, it will be appreciated that this information may alternatively be provided implicitly using another parameter of on-demand SSB. For example, presence of On-demand SSB time offset, or On-demand SSB-Periodicity can implicitly indicate the presence of additional on-demand SSB on top of always-on SSB.

[0148] Alternatively, where the 'always-on' SSBs for the SCell 9-2 are used as CD-SSBs, but the on-demand SSBs for the SCell 9-2 are to be transmitted in a different frequency as the 'always-on' SSBs, some of the configuration information / parameters necessary for configuring the on-demand SSBs for the SCell 9-2 may be provided alongside the configuration information / parameters for the CD-SSBs (e.g., the 'always-on' SSBs).

[0149] By way of example only, Fig. 9 illustrates an example of an SSB configuration for SCell on-demand SSBs that may be provided to the UE 3 by the RAN node 5 to configure on-demand SSBs for the SCell 9-2 when 'always-on' SSBs are provided for the SCell 9-2 in a different frequency.

[0150] As shown in Fig. 9, in the context of when 'always-on' SSBs are provided for the SCell 9-2 in addition to on-demand SSBs (either CD-SSBs or NCD-SSBs) and the 'always-on' SSBs are used as CD-SSBs, then an adapted version of a typical CD-SSB serving cell configuration may be used to configure the on-demand SSBs.

[0151] For example, an adapted version of a cell configuration associated with the CD-SSBs may be provided which, for example, includes: an indication of time domain position of the transmitted CD-SSBs (e.g., in an ssb-PositionsInBurst IE); an indication of a periodicity of the transmitted CD-SSBs (e.g., in an ssb-periodicityServingCell IE); an indication of a subcarrier spacing (SCS) of the transmitted CD-SSBs (e.g., in an ssbSubcarrierSpacing IE); and a transmission power that may be used by the network for transmission of the CD-SSBs (e.g., in an ss-PBCH-BlockPower IE).

[0152] Additionally, the adapted version of a cell configuration associated with the CD-SSBs may, for example, include: an indication of an on-demand SSB timing offset which indicate the time occasions where on-demand SSB burst can be received with respect to an always-on SSB burst (e.g., in a On-demand SSB-timeoffset IE), an indication of an on-demand SSB periodicity to provide additional periodicity information for the on-demand SSBs other than periodicity of 'always-on' SSB (e.g., in an On-demand-SSB-Periodicity IE), an indication of a frequency of the on-demand SSBs (e.g., in an On-demand SSB frequency IE) along with other appropriate IEs that may be used to provide additional information necessary for using the on-demand SSBs of the SCell 9-2. For example, an appropriate IE may be provided to indicate to the UE 3 whether the SSBs for the SCell 9-2 are transmitted periodically or on an on-demand basis (e.g., in an Is-on-demand IE), along with other appropriate IEs e.g., On-demand SSB param1 IE, an On-demand SSB param2 IE, etc.

[0153] It will be appreciated that the IEs relevant for on-demand SSB can be grouped together and sent in a different IE (similar to the SSB configuration described above with reference to Fig. 7) which may not be included within the ServingCellConfigCommon IE.

[0154] It will also be appreciated that in the case described above the CD-SSB parameters (e.g., ssb-PositionsInBurst, ssbSubcarrierSpacing and ss-PBCH-BlockPower) are common for 'always-on' SSBs and on-demand SSBs while other parameters (e.g., On-demand SSB frequency IE) are provided specifically for the on-demand SSBs.

[0155] Alternatively, where the 'always-on' SSBs for the SCell 9-2 are used as CD-SSBs, but the on-demand SSBs for the SCell 9-2 are to be transmitted in a different frequency as the 'always-on' SSBs, the configuration information / parameters necessary for configuring the on-demand SSBs for the SCell 9-2 may be provided within an IE used in SSB configurations for NCD-SSBs (e.g., within a NonDefiningCellSSB-r17 IE).

[0156] By way of example only, Fig. 10 illustrates another example of an SSB configuration for SCell on-demand SSBs that may be provided to the UE 3 by the RAN node 5 to configure on-demand SSBs for the SCell 9-2 when 'always-on' SSBs are provided for the SCell 9-2 in a different frequency.

[0157] As shown in Fig. 10, in the context of when 'always-on' SSBs are provided for the SCell 9-2 in addition to on-demand SSBs (either CD-SSBs or NCD-SSBs) and the 'always-on' SSBs are used as CD-SSBs, then an adapted version of a typical NCD-SSB serving cell configuration may be used to configure the on-demand SSBs.

[0158] For example, the appropriate SSB configuration may include (e.g., within a NonCellDefiningSSB-r17 IE, or the like): an appropriate indication of an SSB frequency of the NCD-SSBs for the SCell 9-2 (e.g., in absoluteFrequencySSB-r17 IE), an SSB periodicity for the NCD-SSBs (e.g., in a ssb-Periodicity-r17 IE). Optionally, the SSB configuration may also include a timing offset indication (e.g., in an ssb-TimeOffset-r17 IE). These parameters, it will be appreciated, as specific to NCD-SSBs and are typically found in the NonCellDefiningSSB-r17 IE provided when configuring NCD-SSBs.

[0159] Additionally, the appropriate SSB configuration may include (e.g., within a NonCellDefiningSSB-r17 IE, or the like): an indication of an on-demand SSB periodicity to provide additional periodicity information for the on-demand SSBs other than periodicity of 'always-on' SSB (e.g., in a On-demand-SSB-Periodicity IE), an indication of whether the SSBs for the SCell 9-2 are transmitted periodically or on an on-demand basis (e.g., in an Is-on-demand IE), along with other appropriate IEs e.g., On-demand SSB param1 IE, an On-demand SSB param2 IE, etc.

[0160] <Determining On-demand SSB start times for SCells> 　　It will be appreciated that once on-demand SCell SSBs such as those described above (e.g., SCell CD-SSBs and / or SCell NCD-SSBs) have been configured by the network (e.g., RAN node 5), the network (e.g., the RAN node 5) may, at any appropriate time, trigger the transmission of on-demand SSBs for the SCell 9-2 to the UE 3 (e.g., via an appropriate MAC control element (CE)). For example, as shown in the procedure of Fig. 4, the RAN node 5 may (based on some condition e.g., based on a change in cell capacity etc.) trigger the UE 3 to use the configured SCell 9-2 by sending an appropriate SCell activation command (or the like) to the UE 3 (see e.g., step S404 of Fig. 4).

[0161] Alternatively, once on-demand SCell SSBs such as those described above (e.g., SCell CD-SSBs and / or SCell NCD-SSBs) have been configured by the network (e.g., RAN node 5), the UE 3 may decide (based on some condition e.g., based on a change in cell capacity etc.) that it wishes to use the SCell 9-2 of the RAN node 5, and may send an appropriate message to request that the RAN node 5 trigger / activate an appropriate SCell 9-2. The RAN node 5 may then trigger the UE 3 to use a configured SCell 9-2 by sending an appropriate SCell activation command (or the like) to the UE 3 in, for example, an appropriate MAC CE (see e.g., step S404 of Fig. 4).

[0162] In those cases, the UE 3 expects that the one or more SSB bursts for the on-demand SCell SSBs may begin to be transmitted by the RAN node 5 from a time instance 'A'. That time instance A may, for example, be determined by the UE 3 as follows: The time instance 'A' at which the UE 3 expects the one or more SSB bursts for the on-demand SCell SSBs to begin may correspond to the slot boundary of the first SSB time domain position of the transmitted on-demand SSB burst, which is a predefined or configured number ('T') of slots or symbols after the slot or symbol where UE 3 received signalling from RAN node 5 to indicate on-demand SSB transmissions e.g., after the slot or symbol where the UE 3 received the SCell activation command in the MAC CE. In this scenario, the first SSB time domain position of the transmitted on-demand SSB burst are configured by the RAN node 5.

[0163] It will be appreciated that when determining the time instance A, the UE 3 may assume that the T slots or symbols after the slot or symbol where UE 3 received signalling from RAN node 5 to indicate on-demand SSB transmissions will not be less than the timeline requirements necessary for the UE 3 to process the MAC CE it received from the RAN node 5 for SCell activation (e.g., the number of slots or symbols required for the UE 3 to process the MAC CE it received from the RAN node 5 for SCell activation).

[0164] It will also be appreciated that the SSB time domain positions of an on-demand SSB burst may be configured by the RAN node 5, whilst the value of T may be predefined or indicated / configured by the RAN node 5.

[0165] Fig. 11 illustrates an example timeline of slots for transmissions over the PCell 9-1 (also referred to a 'reference' cell) and a timeline of slots for transmissions of an SSB burst over an SCell 9-2.

[0166] As shown in Fig. 11, in a slot #0, the RAN node 5 may send an appropriate indication (e.g., in a MAC CE or the like) to a UE 3 to activate a SCell 9-2 for use by the UE 3 and / or indicate that on-demand SSBs for the activated SCell 9-2 have been triggered. Based on that indication, the UE 3 is aware that on-demand SSBs for the activated SCell 9-2 are due and will shortly be transmitted to it by the RAN node 5.

[0167] Having received that indication from the RAN node 5, the UE 3 determines when it should expect to receive the on-demand SSBs for the SCell 9-2 by determining a start time (e.g., a timing instance A) of a corresponding SSB burst for those SSBs. For example, as shown in Fig. 11, the UE 3 may determine that the SSB burst for the on-demand SSBs for the SCell 9-2 will begin to be transmitted by the RAN node 5 T slots or symbols after the slot or symbol in which the UE 3 received signalling from RAN node 5 to indicate on-demand SSB transmissions (e.g., T slots after slot #0 as shown in Fig. 11). Once the UE 3 reaches T slots after slot#0 in time, it may begin searching for the SSB burst.

[0168] That value T corresponding to the number of slots or symbols after the slot or symbol where the UE 3 received signalling from the RAN node 5 to indicate on-demand SSB transmissions may, in one example, be provided to the UE 3 by the RAN node 5 (e.g., indicated in an appropriate configuration associated the 'reference' cell).

[0169] In this example however, the value of T may be provided to the UE 3 in a format more appropriate for the reference cell. For example, when the RAN node 5 provides the UE 3 with the T value, it may give that T value to the UE 3 such that the number of slots or symbols it indicates is with units of (size of) the slots or symbols used for transmissions over the reference cell. Accordingly, if the reference cell and the SCell 9-2 operate on different numerologies, and the size of the slots / symbols differs between the reference cell and the SCell 9-2, the T value indicated by the RAN node 5 may not be correct. This in turn may cause the UE 3 to miss the start position of an SSB burst or bursts for an activated SCell 9-2.

[0170] In another example, the value T may be determined directly by the UE 3 based on information provided to the UE 3 in the on-demand SCell SSB configuration provided to it by the RAN node 5. It will be appreciated that in this case as the T value is determined by the UE 3 itself the T value may be determined such that is in units of (the same size as) the slots or symbols used for transmissions over the activated SCell 9-2, and thus the risk of the UE 3 missing the start position of an SSB burst or bursts for the activated SCell 9-2 is mitigated.

[0171] There now follows several mechanisms / procedures, described with reference to Figs. 12 to 15, for determining a start time of an SSB burst for on-demand SSBs for a SCell 9-2 that may be implemented in the communication system 1 in the case where the value T is provided by the RAN node 5.

[0172] <Enhanced Procedures for Indicating Start Positions of On-demand SSBs for UE SSB Detection> 　　Fig. 12 illustrates another example timeline of slots for transmissions over the reference cell and a timeline of slots for transmissions of an SSB burst over an SCell 9-2.

[0173] As shown in Fig. 12, in a slot #0, the RAN node 5 may send an appropriate indication (e.g., in a MAC CE or the like) to a UE 3 to activate the SCell 9-2 for use by the UE 3 and / or indicate that on-demand SSBs for the activated SCell 9-2 have been triggered. Based on that indication, the UE 3 is aware that on-demand SSBs for the activated SCell 9-2 are due and will shortly be transmitted to it by the RAN node 5.

[0174] Having received that indication from the RAN node 5, the UE 3 determines when it should expect to receive the on-demand SSBs for the SCell 9-2 by determining a start time (e.g., a timing instance A) of a corresponding SSB burst for those SSBs. However, in the case where the unit (size) of the slots used for transmissions by the reference cell and the unit (size) of the slots used for transmissions by the SCell 9-2 differ, there is a risk that the UE 3 may miss the start position of an SSB burst or bursts for an activated SCell 9-2 if it uses the value T to calculate / determine the timing instance A (e.g., the start time of the SSB burst for the on-demand SSBs for the SCell 9-2).

[0175] Therefore, to mitigate the risk of the UE 3 missing the start position of an SSB burst or bursts for an activated SCell 9-2, the communication system 1 may be adapted such that when the RAN node 5 provides the T value to the UE 3, it provides that T value in units of symbols, rather than slots. It will be appreciated that by providing the T value in units of symbols rather than slots, the RAN node 5 may be able to indicate a T value that extends within, and ends part way through, slots, as shown in Fig. 12. In this way, although the T value provided by the RAN node 5 may not enable the UE 3 to determine the exact start position of an SSB burst of SSBs for the SCell 9-2, it may nevertheless be able to determine a close approximation of start position and may only begin searching for on-demand SSBs at that close approximation point.

[0176] It will be appreciated however, that as the approach described above does not enable the UE 3 to determine an exact start position of the SSB burst, the UE 3 may still need to perform blind decoding of the SSBs.

[0177] Fig. 13 illustrates another example timeline of slots for transmissions over the reference cell and a timeline of slots for transmissions of an SSB burst over an SCell 9-2.

[0178] As shown in Fig. 13, in a slot #0, the RAN node 5 may send an appropriate indication (e.g., in a MAC CE or the like) to a UE 3 to activate the SCell 9-2 for use by the UE 3 and / or indicate that on-demand SSBs for the activated SCell 9-2 have been triggered. Based on that indication, the UE 3 is aware that on-demand SSBs for the activated SCell 9-2 are due and will shortly be transmitted to it by the RAN node 5.

[0179] Having received that indication from the RAN node 5, the UE 3 determines when it should expect to receive the on-demand SSBs for the SCell 9-2 by determining a start time (e.g., a timing instance A) of a corresponding SSB burst for those SSBs. However, in the case where the unit (size) of the slots used for transmissions by the reference cell and the unit (size) of the slots used for transmissions by the SCell 9-2 differ, there is a risk that the UE 3 may miss the start position of an SSB burst or bursts for an activated SCell 9-2 if it uses the value T to calculate / determine the timing instance A (e.g., the start time of the SSB burst for the on-demand SSBs for the SCell 9-2).

[0180] Therefore, to reduce the risk of the UE 3 missing the start position of an SSB burst or bursts for an activated SCell 9-2, the communication system 1 may be adapted such that when the RAN node 5 provides the T value to the UE 3, it provides that T value in the numerology (e.g., the symbol / slot length) of the activated SCell 9-2 for which on-demand SSB transmissions have been triggered.

[0181] For example, if the T value is indicated by the RAN node 5 to the UE 3 over the reference cell, then the RAN node 5 may indicate that T value in a unit (size) of slots or symbols associated with the numerology of the SCell 9-2 provided by the RAN node 5 for which the UE 3 expects to receive on-demand SSB transmissions. In this way the T value provided to the UE 3 will have greater accuracy than if the T value was provided in units associated with the numerology of the reference cell such as in the case described above with reference to Fig 12).

[0182] It will be appreciated that even where the RAN node 5 provides the T value in a unit (size) of slots or symbols associated with the numerology of the SCell 9-2 provided by the RAN node 5 for which the UE 3 expects to receive on-demand SSB transmissions, there may still be a risk (albeit small) that the timing instance A (e.g., the start time of the SSB burst for the on-demand SSBs for the SCell) calculated / determined by the UE 3 using that T value may not be exact, but may nevertheless be a close approximation of start position and may only begin searching for on-demand SSBs at that close approximation point.

[0183] Accordingly, it will be appreciated that as the approach described above may not enable the UE 3 to determine an exact start position of the SSB burst, the UE 3 may still need to perform blind decoding of the SSBs.

[0184] It will also be appreciated that the approach described above with reference to Fig. 12 and the approach described above with reference to Fig. 13 may optionally be implemented jointly in the communication system 1. For example, the RAN node 5 may provide the T value to the UE 3 in a unit (size) of slots or symbols associated with either: -　　The numerology of the reference cell provided by the RAN node 5 (e.g., the cell provided by the RAN node 5 over which the indication to activate a SCell for use by the UE 3 is sent; or -　　The numerology of the SCell 9-2 provided by the RAN node 5 for which the UE 3 expects to receive on-demand SSB transmissions.

[0185] In this scenario, the RAN node 5 may decide to provide the T value to the UE 3 in a unit (size) of slots or symbols associated whichever of the reference cell or the SCell 9-2 has the smallest numerology (e.g., the smallest SCS). For example, if the SCS of the SCell 9-2 is smaller than the SCS of the reference cell, then the RAN node 5 may decide to provide the T value to the UE 3 in a unit (size) of the slot or symbols associated with the SCell 9-2. In another example, if the SCS of the reference cell is smaller than the SCS of the SCell 9-2, then the RAN node 5 may decide to provide the T value to the UE 3 in a unit (size) of the slot or symbols associated with the reference cell.

[0186] Fig. 14 illustrates another example timeline of slots for transmissions over the reference cell and a timeline of slots for transmissions of an SSB burst over an SCell 9-2.

[0187] As shown in Fig. 14, in a slot #0, the RAN node 5 may send an appropriate indication (e.g., in a MAC CE or the like) to a UE 3 to activate a SCell 9-2 for use by the UE 3 and / or indicate that on-demand SSBs for the activated SCell 9-2 have been triggered. Based on that indication, the UE 3 is aware that on-demand SSBs for the activated SCell 9-2 are due and will shortly be transmitted to it by the RAN node 5.

[0188] Having received that indication from the RAN node 5, the UE 3 determines when it should expect to receive the on-demand SSBs for the SCell by determining a start time (e.g., a timing instance A) of a corresponding SSB burst for those SSBs. However, in the case where the unit (size) of the slots used for transmissions by the reference cell and the unit (size) of the slots used for transmissions by the SCell 9-2 differ, there is a risk that the UE 3 may miss the start position of an SSB burst or bursts for an activated SCell 9-2 if it uses the value T to calculate / determine the timing instance A (e.g., the start time of the SSB burst for the on-demand SSBs for the SCell 9-2).

[0189] Therefore, to reduce the risk of the UE 3 missing the start position of an SSB burst or bursts for an activated SCell 9-2, the communication system 1 may be adapted such that the RAN node 5 may provide the UE 3 with: -　　A configuration of potential slots or symbols of the SCell 9-2 where on-demand SSBs are transmitted for the SCell 9-2 (or where an SSB burst is transmitted for the SCell 9-2) - e.g., a configuration of a repeating pattern of those slots / symbols; and -　　A T1 value after which the UE 3 may expect to receive the on-demand SSBs for the SCell 9-2. When provided by the RAN node 5, that T1 value may be in a unit (size) of slots or symbols associated with either a) the reference cell, or b) the SCell 9-2 over which on-demand SSBs will be transmitted.

[0190] Alternatively, the RAN node 5 may provide the UE 3 with the configuration of potential slots or symbols of the SCell 9-2 where on-demand SSBs are transmitted for the SCell 9-2 (or where an SSB burst is transmitted for the SCell 9-2), and the T1 value may be determined / calculated by the UE 3. It will be appreciated however that in this case, the T1 value may only be in a unit (size) of slots or symbols associated with the SCell 9-2 over which on-demand SSBs will be transmitted.

[0191] In either case, the T1 value may correspond to a variety of different times. In one example, the T1 value may correspond to an end of a MAC CE processing time, or a HARQ transmission time corresponding to the MAC CE transmitted by the RAN node 5 to indicate that on-demand SSBs for the SCell 9-2 are triggered and will soon be transmitted (e.g., an end of a MAC CE processing time, or a HARQ transmission time corresponding to an SCell activation command, or the like).

[0192] In another example, the T1 value may correspond to an end of an RRC processing time or RRC reconfiguration complete message that includes an appropriate indication to indicate that on-demand SSBs for the SCell 9-2 are triggered and will soon be transmitted.

[0193] In yet another example, the T1 value may correspond to a DCI processing time for receiving a DCI from the RAN node 5. In this case the DCI may include an appropriate indication to indicate that on-demand SSBs for the SCell 9-2 are triggered and will soon be transmitted.

[0194] Having received the configuration of the potential slots or symbols of the SCell 9-2 where on-demand SSBs are transmitted for the SCell 9-2, and having received or determined the T1 value, the UE 3 may determine an SSB occasion within which an on-demand SSB for the SCell 9-2 may be expected to be transmitted. For example, the UE 3 may determine a first slot or symbol of the reference cell within which it would expect the on-demand SSBs for the SCell 9-2 to be transmitted (if such SSBs were actually transmitted over the reference cell). That first slot or symbol of the reference cell within which the UE 3 would expect the on-demand SSBs for the SCell 9-2 to be transmitted (if such SSBs were actually transmitted over the reference cell) may occur, for example, after a time corresponding to T1 value after the UE 3 received an indication that -demand SSBs for the SCell 9-2 are triggered and will soon be transmitted.

[0195] After time T1 elapses, if the UE 3 has already acquired time synchronisation with the SCell 9-2, then the UE 3 starts searching for on-demand SSB transmissions in the slots and / or symbols determined based on the configuration of potential slots or symbols of the SCell 9-2 where on-demand SSBs are transmitted for the SCell 9-2.

[0196] However, if the UE 3 has not acquired time synchronisation with the SCell 9-2, then after time T1 elapses, the UE 3 determines the slots and / or symbols of the reference cell when on-demand SSB transmissions are expected to be transmitted on the SCell 9-2, and the UE 3 shall search for on-demand SSBs during the determined slots and / or symbols of the reference cell. The slots or symbols of the reference cell where the on-demand SSBs transmissions for the SCell 9-2 would be expected to be transmitted (or the slots or symbols of the reference cell where the UE searches for on-demand SSBs transmissions for the SCell 9-2) may in turn be determined based on the configuration of potential slots or symbols of the SCell 9-2 where on-demand SSBs are transmitted for the SCell 9-2 using the following calculations: For a slot: For a symbol: Where: - SlotReferenceCelland SymbolReferenceCellare the slot and symbol of the reference cell corresponding to when the UE 3 assumes an on-demand SSB transmission for the SCell 9-2 will be transmitted by the RAN node 5 over the SCell 9-2; - SlotSCellis the slot of the SCell 9-2 where an on-demand SSB for the SCell 9-2 can be transmitted (e.g., as indicated per the configuration of potential slots or symbols of the SCell 9-2 where on-demand SSBs are transmitted for the SCell 9-2 provided to the UE 3 by the RAN node 5); - SCSReferenceCelland SCSSCellare the subcarrier spacings (in kHz) of the reference cell and the SCell 9-2 respectively; and - Timing Offset is the time difference (in symbols / ms) between the start of the system frame of the reference cell and the start of the system frame of the SCell 9-2.

[0197] The value of Timing Offset can be configured by the RAN node 5 to the UE 3. If the value of Timing Offset is not provided then the UE 3 may assume the value of the Timing Offset to be 0.

[0198] It will be appreciated that via the calculations above, the UE 3 can, having determine a slot or symbol within which it would expect to receive an on-demand SSB transmission for the SCell over the reference cell, transform that determined slot or symbol into a corresponding slot or symbol of the SCell 9-2. In this way the UE 3 may more accurately determine the starting slot or symbol where an SSB burst of on-demand SSBs for the SCell 9-2 may begin.

[0199] It will nevertheless be appreciated that there may still be a risk (albeit small) that the determined starting slot or symbol where an SSB burst of on-demand SSBs for the SCell 9-2 may begin may not be exact. Rather the determined starting slot or symbol where an SSB burst of on-demand SSBs for the SCell 9-2 may be a close approximation of the start position. Accordingly, it will be appreciated that as the approach described above may not enable the UE 3 to determine an exact start position of the SSB burst, the UE 3 may still need to perform blind decoding of the SSBs.

[0200] Fig. 15 illustrates another example timeline of slots for transmissions over the reference cell and a timeline of slots for transmissions of an SSB burst over an SCell 9-2.

[0201] As shown in Fig. 15, in a slot #0, the RAN node 5 may send an appropriate indication (e.g., in a MAC CE or the like) to a UE 3 to activate the SCell 9-2 for use by the UE 3 and / or indicate that on-demand SSBs for the activated SCell 9-2 have been triggered. Based on that indication, the UE 3 is aware that on-demand SSBs for the activated SCell 9-2 are due and will shortly be transmitted to it by the RAN node 5.

[0202] Having received that indication from the RAN node 5, the UE 3 determines when it should expect to receive the on-demand SSBs for the SCell 9-2 by determining a start time (e.g., a timing instance A) of a corresponding SSB burst for those SSBs. However, in the case where the unit (size) of the slots used for transmissions by the reference cell and the unit (size) of the slots used for transmissions by the SCell 9-2 differ, there is a risk that the UE 3 may miss the start position of an SSB burst or bursts for an activated SCell 9-2 if it uses the value T to calculate / determine the timing instance A (e.g., the start time of the SSB burst for the on-demand SSBs for the SCell 9-2).

[0203] Therefore, to reduce the risk of the UE 3 missing the start position of an SSB burst or bursts for the activated SCell 9-2, the communication system 1 may be adapted such that the RAN node 5 provides the UE 3 with an indication of a slot of the reference cell within which the UE 3 may expect to receive on-demand SSB transmissions for the SCell 9-2 over the SCell 9-2. In this way the RAN node 5 merely provides the UE 3 with a rough approximation of the location of where the on-demand SSB transmission will be transmitted over the SCell 9-2 as corrections for any difference between the size of the slots used by the reference cell and the size of the slots used by the SCell 9-2 are not provided.

[0204] It will therefore be appreciated that as there is a risk that the indicated slot of the reference cell within which the UE 3 may expect to receive on-demand SSB transmissions for the SCell 9-2 over the SCell 9-2 may not match up with the actual slot within which the demand SSBs for the SCell 9-2 is transmitted over the SCell 9-2, the UE 3 may still need to perform blind decoding of the SSBs during the indicate slot of the reference cell.

[0205] To reduce the risk that the indicated slot of the reference cell within which the UE 3 may expect to receive on-demand SSB transmissions for the SCell 9-2 over the SCell 9-2 do not match up with the actual slot within which the demand SSBs for the SCell 9-2 is transmitted over the SCell 9-2, the RAN node 5 may also provide the UE 3 with a SSB measurement timing configuration (SMTC) for the reference cell which may include SMTC occasions with respect to the reference cell numerology where UE 3 can potentially obtain on-demand SSBs for the SCell 9-2 as shown in Fig. 15.

[0206] In this scenario, each indicated SMTC occasion may comprise a start slot or symbol of the SMTC occasion, as well as a duration of that SMTC occasion with respect to the timing numerology of the reference cell. The UE 3 may then assume that only those SMTC occasions which are indicated to the UE 3 by the RAN node 5 via an appropriate indication (e.g., the on-demand SSB indication) shall be used for on-demand SSB transmissions for the SCell 9-2, while all other occasions of SMTC shall be assumed to not be used for on-demand SSB transmissions for the SCell 9-2.

[0207] <Other Considerations> 　　It will be appreciated that each of the mechanisms / procedures described above with reference to Figs. 12 to 15 are by way of example only and that modifications may be made to those mechanisms / procedures where such modifications are deemed appropriate.

[0208] For example, although in the mechanisms / procedures described above with reference to Figs. 12 to 15, the timings for the start of on-demand SSB transmissions for the SCell 9-2 are determined with respect to the end of a slot or symbol within which the UE 3 receives an appropriate indication from the RAN node 5 (e.g., in a MAC CE or the like) to activate the SCell 9-2 for use by the UE 3 and / or indicate that on-demand SSBs for the activated SCell 9-2 have been triggered, it will be appreciated that the timings for the start of on-demand SSB transmissions for the SCell 9-2 may alternatively be determined with respect to a start time of the slot or symbol within which the UE 3 receives an appropriate indication from the RAN node 5.

[0209] In another example, in the case where the appropriate indication received by the UE 3 from the RAN node 5 specifically indicates the activation of the SCell 9-2 for use by the UE 3, RAN node 5 configure the start time of on-demand SSB transmissions for the SCell 9-2 such that the UE 3 is able to receive the on-demand SSB transmissions for the SCell 9-2 either a) immediately after it has received the SCell activation indication / command; or b) immediately after the transmission of an appropriate HARQ or HARQ-like feedback message by the UE 3 to the RAN node 5 in response to the SCell activation indication / command. For example, the T value provided by the RAN node 5 may be configured such that delay between SCell activation and the start of on-demand SSB transmissions for the SCell 9-2 is not large. It will be appreciated that this may be achieved by restricting an ending time instance of T (or T1 as appropriate), the value of which may be indicated to the UE 3 by the RAN node 5. Such an ending time instance may, for example, occur before SCell activation command reception or HARQ feedback transmission for SCell activation command.

[0210] <Indicating On-demand SSB Commencement for SCells> The enhanced procedures described above with reference to Figs. 12 to 15 relate to means of indicating the start position of on-demand SSBs for the SCell 9-2 to a UE 3 following activation of the SCell 9-2 for which the UE 3 has previously received an appropriate on-demand SCell SSB transmission configuration, or the like.

[0211] However, it will be appreciated that such means of indicating the start position of on-demand SSBs for the SCell 9-2 to the UE 3 following activation of the SCell 9-2 may not be equally applicable to scenarios the SCell 9-2 is already activated for a first UE 3-1 and is then subsequently activated for another (second) UE 3-2 while on-demand SSB transmissions for the SCell 9-2 are being transmitted by the RAN node 5.

[0212] For example, Fig. 16 illustrates a timeline for the reception of SCell configurations, SCell activation commands, and on-demand SSB transmissions for the first UE 3-1 and the second UE 3-2.

[0213] As shown Fig. 16, at a time t1, the first UE 3-1 may receive an appropriate SCell configuration for the SCell 9-2 (which may, it will be appreciated, include an appropriate SSB configuration for the SCell 9-2). At some time later at t2, either in response to a request by the first UE 3-1, or initiated by the RAN node 5, a SCell activation command is sent to the first UE 3-1 to active the SCell 9-2 that was configured at t1; sometime later the transmission of periodic on-demand SSBs begins.

[0214] Following the initiation of the transmission of on-demand SSBs for the SCell 9-2, at time t3, the second UE 3-2 may receive appropriate SCell configuration for the SCell 9-2 (which may, it will be appreciated, include an appropriate SSB configuration for the SCell 9-2). At some time later at t4, either in response to a request by the second UE 3-2, or initiated by the RAN node 5, a SCell activation command is sent to the second UE 3-2 to active the SCell 9-2 that was configured at t4.

[0215] However, in this scenario as the same SCell 9-2 is activated (or configured and activated) for the second UE 3-2 and on-demand SSB transmission for that SCell 9-2 are on-going at the point of SCell configuration and activation for the second UE 3-2, appropriate procedures may be needed to inform the second UE 3-2: -　　That on-demand SSB transmissions for the SCell 9-2 have already begun; and -　　When to start monitoring for those on-demand SSB transmissions for the SCell 9-2 that are already being transmitted by the RAN node 5.

[0216] There now follows a description of several mechanisms / procedures, described with reference to Figs. 12 to 15, for determining a start time of an SSB burst for on-demand SSBs for a SCell 9-2 that may be implemented in the communication system 1 of Fig. 1

[0217] <Enhanced Procedures for Indicating On-demand SSB Commencement for SCells> 　　In the scenario where the RAN node 5 intends to transmit on-demand SSBs to the second UE 3-2 immediately after SCell addition (e.g., in the example shown in Fig 16, immediately after time t3, then RAN node 5 may need to indicate to the UE 3 that it wishes to commence -demand SSBs to the second UE 3-2 as soon as possible.

[0218] In one example, to enable the RAN node 5 to indicate to the second UE 3-2 that on-demand SSBs to the second UE 3-2 for the SCell 9-2 occur immediately after SCell addition, the SCell configuration (e.g., an RRC configuration, or the like) received by the second UE 3-2 at t3 may include appropriate parameters / information to indicate to the second UE 3-2 whether i) on-demand SSB transmissions for the SCell 9-2 are available for the second UE 3-2 immediately (i.e., on-demand SSBs are already being transmitted for the SCell 9-2 to another UE 3), or ii) the start of the on-demand SSBs for the SCell 9-2 will be indicate to the second UE 3-2 via another form of signalling.

[0219] For example, the SCell configuration may include within an ServingCellConfigCommon IE or a NonCellDefiningSSB-r17 IE the following information / IEs: On-demand SSB param1 IE, On-demand SSB param2 IE, On-demand SSB param3 IE, and Transmitted on RRC configuration IE.

[0220] The Transmitted on RRC configuration IE, may, for example, indicate to the second UE 3-2 as to whether on-demand SSB are available for reception immediately upon receiving the SCell configuration (e.g., RRC configuration, or the like), or whether the start of on-demand SSB shall be indicated using another form of signalling (e.g. DCI-based or MAC CE-based).

[0221] It will be appreciated that the Transmitted on RRC configuration IE, may, for example, be a one-bit indication / flag which indicates a True or False value. For example, the Transmitted on RRC configuration IE may be set to True when on-demand SSB are available for reception immediately upon receiving the SCell configuration, and False when the on-demand SSB are not available for reception immediately upon receiving the SCell configuration. In the case of False, the second UE 3-2 may assume that another form of signalling shall indicate the start of on-demand SSBs for the SCell 9-2.

[0222] Alternatively, the Transmitted on RRC configuration IE may only be included when on-demand SSB are available for reception immediately upon receiving the SCell configuration, and upon detection of that IE in the SCell configuration, the second UE 3-2 may assume that on-demand SSB are available for reception immediately upon receiving the SCell configuration. It will be appreciated that the corollary of this is that in the absence of such an IE in the SCell configuration, the second UE 3-2 may assume that another form of signalling shall indicate the start of on-demand SSBs for the SCell 9-2.

[0223] Moreover, the Transmitted on RRC configuration IE in the SCell configuration may be mandatory set to True if the SCell 9-2 is activated using the (same) RRC signalling, otherwise this IE can have either True or False value or can be optional.

[0224] In another example, rather than the RAN node 5 indicating to the second UE 3-2 that on-demand SSBs to the second UE 3-2 for the SCell 9-2 will occur immediately after SCell addition, the second UE 3-2 may simply be configured to assume that on-demand SSBs are being transmitted upon reception of the SCell configuration (e.g., RRC configuration of the SCell) when that configuration also includes a SCell activation command or the like.

[0225] In this case, the second UE 3-2 does not need any explicit IEs to indicate that start of transmission of on-demand SSBs for the SCell 9-2. If the RRC message which includes SCell configuration includes SCell activation (e.g. if the message includes sCellState IE) then the second UE 3-2 assumes that SSBs shall be available for reception based on the provided configuration and the second UE 3-2 does not need to wait for further signalling or commands from the RAN node 5 to indicate on-demand SSB transmission start times, or the like.

[0226] It will be appreciated that both of the approaches outlined above may also be appropriately combined into one single approach for indicating whether on-demand SSB transmissions for the SCell 9-2 are available for the second UE 3-2 immediately. For example, the second UE 3-2 may be configured to assume that on-demand SSBs for the SCell 9-2 will be transmitted after the second UE 3-2 receives the SCell configuration (e.g., RRC configuration) if either i) the Transmitted on RRC configuration IE is included and set in the SCell configuration; or ii) the second UE 3-2 receives a SCell configuration which includes an appropriate SCell activation command, or the like.

[0227] In yet another example, even though on-demand SSBs for a SCell 9-2 may currently be being transmitted to another UE 3, the RAN node 5 may wish the second UE 3-2 to assume legacy behaviour for SSB transmission reception; for example, the RAN node 5 may wish the second UE 3-2 to assume that the SSBs for the SCell 9-2 will be transmitted to it periodically. In this case the RAN node 5 may indicate appropriate legacy parameters (e.g., parameters defined for 'always-on' SSBs) to the second UE 3-2.

[0228] It will nevertheless be appreciated that in this scenario, if at any point the RAN node 5 wishes to terminate / stop transmission of the on-demand SSBs for the SCell 9-2, then it may have to reconfigure the SCell 9-2 and configure on-demand SSB parameters so that the second UE 3-2 assumes that SSB transmission, following termination, will only start after receiving additional signalling from the RAN node 5.

[0229] In yet another example, where the RAN node 5 transmits appropriate signalling to the second UE 3-2 to indicate that on-demand SSBs for the SCell 9-2 are available for the second UE 3-2 immediately after receiving the SCell configuration, delay requirements for the second UE 3-2 for SCell activation in this case may be dependent on the time instance when the second UE 3-2 receives the indication of the start of the on-demand SSB transmissions for the SCell 9-2.

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

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

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

[0233] The communication control module 43 is operable to control the communication between the UE 3 and its serving RAN node or RAN nodes 5 (and other communication devices connected to the RAN node 5, such as further UEs 3 and / or core network nodes). The communication control module 43 is configured for the overall handling of uplink communication via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), random access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 43 is also configured for the overall handling of receipt of downlink communication 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 communication (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.

[0234] 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 UE 3 may include sub-modules corresponding to the layers of a conventional protocol stack (PHY, MAC, RRC, RLC, PDCP etc.).

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

[0236] <RAN node> 　　Fig. 17 is a simplified block schematic illustrating the main components of a RAN node 5 (e.g., a base station) for implementation in the communication system 1 of Fig. 1.

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

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

[0239] The communication control module 63 is operable to control the communication between the RAN node 5 and UEs 3 and other network entities (e.g., core network nodes) that communicate with the RAN node 5. The communication control module 63 is configured for the overall control of the reception and decoding of uplink communication, via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), a random-access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 63 is also configured for the overall control of the transmission of downlink communication including downlink communication via associated downlink channels (e.g., via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-persistent scheduling (e.g., SPS). The communication control module 63 is responsible, for example: for determining where to configure the UE 3 to monitor for downlink control information (e.g., the location of search spaces, CORESETs, and associated PDCCH candidates to monitor); for determining the resources to be scheduled for UE transmission / reception of UL / DL communication (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the RAN node side; for configuring slots / symbols appropriately (e.g., for UL, DL or full duplex communication, or the like); for configuring bandwidth parts for the UE 3; for providing related configuration signalling to a UE 3; and the like.

[0240] It will be appreciated that the communication control module 63 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. By way of example only the communication control module 63 may include sub-modules corresponding to the layers of a conventional protocol stack (PHY, MAC, RRC, RLC, PDCP etc.).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0260] It will be appreciated that IoT technology can be implemented on any communication devices that can connect to a communication system for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

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

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

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

[0264] For example, the whole or part of the exemplary embodiments disclosed above can be described as, but not limited to, the following supplementary notes. 　　(Supplementary note 1) 　　A method performed by a mobile device, the method comprising: 　　receiving configuration information including a plurality of parameters used for receiving an on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB); and 　　in a case where one or more of the plurality of the parameters is absent in the configuration information, determining configuration on the one or more of the plurality of the parameters for the receiving the on demand SSB based on configuration for receiving an always on SSB. 　　(Supplementary note 2) 　　The method according to supplementary note 1, wherein 　　the one or more of the plurality of the parameters are includes at least one of: 　　　　a parameter indicating at least one frequency of the on demand SSB, 　　　　a parameter indicating at least one position of the on demand SSB, 　　　　a parameter indicating at least one periodicity of the on demand SSB, 　　　　a parameter indicating at least one subcarrier spacing (SCS) of the on demand SSB, 　　　　a parameter indicating at least one time location of the on demand SSB, or 　　　　a parameter indicating at least one downlink transmission power of the on demand SSB. 　　(Supplementary note 3) 　　The method according to supplementary note 1 or 2, further comprising: 　　receiving information indicating the on demand SSB is transmitted; and 　　determining a timing when the on demand SSB is transmitted based on the receiving the information. 　　(Supplementary note 4) 　　The method according to supplementary note 3, wherein 　　the determining is performed based on at least one of: 　　　　information indicating a time resource, 　　　　information indicating a numerology, 　　　　information indicating a subcarrier spacing, 　　　　information indicating SSB measurement timing configuration (SMTC), or 　　　　a time of reception of the information indicating the on demand SSB is transmitted. 　　(Supplementary note 5) 　　The method according to any one of supplementary notes 1 to 4, further comprising: 　　receiving a radio resource control (RRC) message including: 　　　　information indicating the on demand SSB is transmitted, and 　　　　information indicating whether configuration for receiving the on demand SSB is activated or deactivated, and 　　wherein the determining the configuration for the receiving the on demand SSB is performed based on contents of the RRC message. 　　(Supplementary note 6) 　　The method according to supplementary note 5, wherein 　　the receiving the RRC message is performed after receiving information of activation of a secondary cell (SCell). 　　(Supplementary note 7) 　　A method performed by an access network node, the method comprising: 　　transmitting, to a mobile device, configuration information including a plurality of parameters used by the mobile device for receiving an on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB), and wherein 　　in a case where one or more of the plurality of the parameters is absent in the configuration information, configuration on the one or more of the plurality of the parameters for the receiving the on demand SSB is determined by the mobile device based on configuration for receiving an always on SSB. 　　(Supplementary note 8) 　　A mobile device comprising: 　　means for receiving configuration information including a plurality of parameters used for receiving an on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB); and 　　means for determining configuration on one or more of the plurality of the parameters for the receiving the on demand SSB based on configuration for receiving an always on SSB, in a case where the one or more of the plurality of the parameters is absent in the configuration information. 　　(Supplementary note 9) 　　An access network node comprising: 　　means for transmitting, to a mobile device, configuration information including a plurality of parameters used by the mobile device for receiving an on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB), and wherein 　　in a case where one or more of the plurality of the parameters is absent in the configuration information, configuration on the one or more of the plurality of the parameters for the receiving the on demand SSB is determined by the mobile device based on configuration for receiving an always on SSB.

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

[0266] 1 COMMUNICATION SYSTEM 3 USER EQUIPMENT 5 RAN NODE 7 CORE NETWORK 9 CELL 10 CONTROL PLANE FUNCTIONS 11 USER PLANE FUNCTIONS 20 EXTERNAL DATA NETWORK 31 TRANSCEIVER CIRCUIT 33 ANTENNA 35 USER INTERFACE 37 CONTROLLER 39 MEMORY 41 OPERATING SYSTEM 43 COMMUNICATIONS CONTROL MODULE 51 TRANSCEIVER CIRCUIT 53 ANTENNA 55 CORE NETWORK INTERFACE 57 CONTROLLER 59 MEMORY 61 OPERATING SYSTEM 63 COMMUNICATIONS CONTROL MODULE

Claims

A method performed by a mobile device, the method comprising:　　receiving configuration information including a plurality of parameters used for receiving an on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB); and　　in a case where one or more of the plurality of the parameters is absent in the configuration information, determining configuration on the one or more of the plurality of the parameters for the receiving the on demand SSB based on configuration for receiving an always on SSB.　　The method according to claim 1, wherein　　the one or more of the plurality of the parameters are includes at least one of:　　　　a parameter indicating at least one frequency of the on demand SSB,　　　　a parameter indicating at least one position of the on demand SSB,　　　　a parameter indicating at least one periodicity of the on demand SSB,　　　　a parameter indicating at least one subcarrier spacing (SCS) of the on demand SSB,　　　　a parameter indicating at least one time location of the on demand SSB, or　　　　a parameter indicating at least one downlink transmission power of the on demand SSB.　　The method according to claim 1 or 2, further comprising:　　receiving information indicating the on demand SSB is transmitted; and　　determining a timing when the on demand SSB is transmitted based on the receiving the information.　　The method according to claim 3, wherein　　the determining is performed based on at least one of:　　　　information indicating a time resource,　　　　information indicating a numerology,　　　　information indicating a subcarrier spacing,　　　　information indicating SSB measurement timing configuration (SMTC), or　　　　a time of reception of the information indicating the on demand SSB is transmitted.　　The method according to any one of claims 1 to 4, further comprising:　　receiving a radio resource control (RRC) message including:　　　　information indicating the on demand SSB is transmitted, and　　　　information indicating whether configuration for receiving the on demand SSB is activated or deactivated, and　　wherein the determining the configuration for the receiving the on demand SSB is performed based on contents of the RRC message.　　The method according to claim 5, wherein　　the receiving the RRC message is performed after receiving information of activation of a secondary cell (SCell).　　A method performed by an access network node, the method comprising:　　transmitting, to a mobile device, configuration information including a plurality of parameters used by the mobile device for receiving an on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB), and wherein　　in a case where one or more of the plurality of the parameters is absent in the configuration information, configuration on the one or more of the plurality of the parameters for the receiving the on demand SSB is determined by the mobile device based on configuration for receiving an always on SSB.　　A mobile device comprising:　　means for receiving configuration information including a plurality of parameters used for receiving an on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB); and　　means for determining configuration on one or more of the plurality of the parameters for the receiving the on demand SSB based on configuration for receiving an always on SSB, in a case where the one or more of the plurality of the parameters is absent in the configuration information.　　An access network node comprising:　　means for transmitting, to a mobile device, configuration information including a plurality of parameters used by the mobile device for receiving an on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB), and wherein　　in a case where one or more of the plurality of the parameters is absent in the configuration information, configuration on the one or more of the plurality of the parameters for the receiving the on demand SSB is determined by the mobile device based on configuration for receiving an always on SSB.

Images