Method performed by user equipment and method performed by network device

Abstract

A wireless communication system comprising at least one RAN node, and at least one UE that supports the measuring of both on-demand (OD) synchronisation signal (SS) / Physical Broadcast Channel (PBCH) blocks (SSBs) and always-on (AO) SSBs in a communication system that transmits both types of SSBs to UEs, more particularly when those UEs are communicating over a secondary cell (SCell), which may also be referred to as a network energy saving (NES) cell.

Description

METHOD PERFORMED BY USER EQUIPMENT AND METHOD PERFORMED BY NETWORK DEVICE

[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 SSB adaptation mechanisms and procedures for measuring both on-demand (OD) synchronisation signal (SS) / Physical Broadcast Channel (PBCH) blocks (SSBs) and always-on (AO) SSBs in a communication system that transmits both types of SSBs to UEs, more particularly when those UEs are communicating over a secondary cell (SCell), which may also be referred to as a network energy saving (NES) cell.

[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 '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] <SSBs in the context of Carrier Aggregation (CA)> 　　In a communication system, there have been increases in bandwidth, thereby bitrate can be achieved through carrier aggregation (CA), whereby multiple frequency blocks, i.e., component carriers (CCs), are assigned to the same UE for use. Each CC in turn serves a cell which provides a particular bandwidth and set of services to the UE . For example, in CA each UE 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 and the network.

[0012] In CA, when initially scanning for a cell to camp on each UE scans for a PCell. The PCell serves as the main point of communication between the UE and the RAN node 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 searches for SSB as described previously to enable efficient cell searching for, and initial access to the PCell.

[0013] As and when required, the UE 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 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 may camp onto a SCell that caters for Internet-of-Things (IoT) devices, high-definition data streaming, or the like.

[0014] The UEs 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).

[0015] 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, RRM measurement procedures, and layer-1 (L1) / layer-3 (L3) measurements are performed for the SCell, and that correct SCell timing synchronization is achieved. Having used those on-demand SSBs for the SCell to perform L1 / L3 measurements, the UE may send appropriate measurement reports to the RAN node periodically, semi-persistently, or aperiodically based on an appropriate CSI configuration.

[0016] In such scenarios each UE 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 all the time, each UE 3 may be configured to acquire SSBs on-demand as described above, and to search for SSBs associated with SCells only when the UE (or network) decides that it wishes to utilise one or more SCells.

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

[0018] 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 if the UE has a PCell 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.

[0019] In addition to SCells that support on-demand SSB transmissions, some SCells may also be configured to support 'always-on' SSB transmissions (Case #2) whereby SSBs are also transmitted over the SCell periodically in addition to on-demand SSB transmissions. For example, it may be beneficial for both on-demand (OD) SSBs and always-on (AO) SSBs to be supported by a SCell in a case where both UEs that support the reception of OD SSBs and UEs that only support AO SSBs are provided in the communication system.

[0020] It will be appreciated that in the case where a SCell supports both AO SSB transmissions and OD SSB transmissions, if a UE that access that SCell is configured to use OD SSB transmissions to perform L1 measurements, or the like, that UE may be configured with an appropriate CSI report configuration that is associated with both OD SSBs and AO SSBs (Option #1), or alternatively, the UE may be configured with an appropriate CSI report configuration that is associated with either OD SSBs or AO SSBs (Option #2).

[0021] It will also be appreciated that in the case where a SCell supports both AO SSB transmissions and OD SSB transmissions, the AO SSBs and OD SSBs may be configured such that that the AO SSBs and OD SSBs do not overlap in the time-domain to prevent a UE accidently receiving both types of SSBs simultaneously which may cause interference issues. Alternatively, the AO SSBs and OD SSBs may be configured such that that the AO SSBs and OD SSBs overlap in either the time domain or the frequency domain only to prevent similar interference issues.

[0022] In the case where a SCell supports both AO SSB transmissions and OD SSB transmissions, the frequency relationship between OD SSBs and AO SSBs when both those types of SSBs are supported by the cell (e.g., the SCell) may be defined such that the frequency location of the OD SSB is the same as the frequency location of the AO SSB at least for the case where AO SSB is not a cell defining (CD) SSB (CD-SSB) as described below. It is however still currently being discussed what the most appropriate the frequency location of an OD SSB may be for the case where the AO SSB is CD-SSB.

[0023] In the case where a SCell supports both AO SSB transmissions and OD SSB transmissions, the spatial relationship between OD SSBs and AO SSBs when both those types of SSBs are supported by the cell (e.g., the SCell) may be defined as follows: SS / PBCH blocks with the same SSB indices for AO SSB and OD SSB may be quasi co-located with respect to a Doppler spread, a Doppler shift, an average gain, an average delay, and / or a delay spread, and when applicable, spatial receiver (RX) parameters. Such quasi co-location may more especially apply at least for the case when the centre frequency locations of the AO SSB and OD-SSB is same.

[0024] Furthermore, when a signal / channel is configured to be quasi co-located with a SSB index, the signal / channel may be quasi co-located with the same SSB index of the AO SSB and OD SSB (if transmitted), and with the same quasi co-located parameters according to existing specifications. Such quasi co-location may also more especially apply at least for the case when the centre frequency locations of the AO SSB and OD-SSB are same. Additionally, at least for the case where SSB indices within an OD SSB burst are identical to SSB indices within an AO SSB burst is supported, it is currently being discussed whether or not to support the case where those SSB indices within the OD SSB burst can be subset of the SSB indices within the AO SSB burst.

[0025] <5G Reduced Capability (RedCap)> 　　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.

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

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

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

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

[0030] 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 be provided within an 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).

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

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

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

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

[0035] In the context of a SCell that supports OD SSB operation, a RAN node may or may not configure an AO SSB (if transmitted) as a CD-SSB. Moreover, a RAN node may configure an on-demand SSB as a CD-SSB or may limit OD SSBs to being NCD-SSBs.

[0036] <Non-Frequency Overlapping AO SSBs and OD SSBs> 　　As described above, in the case where a SCell is configured to support both OD and AO SSB transmissions, those OD and AO SSB transmission may be configured such that the AO SSBs and OD SSBs do not overlap in the time-domain to prevent a UE accidently receiving both types of SSBs simultaneously which may cause interference issues. Alternatively, the AO SSB and OD SSB transmissions may be configured such that that the AO SSBs and OD SSBs overlap in either the time domain or the frequency domain only to prevent similar interference issues.

[0037] However, in the case where the OD SSBs and AO SSBs never overlap in the frequency domain, it will be appreciated that issues can arise during the SCell activation of the SCell. For example, typically, a UE is allowed to cause an interruption during a SCell activation procedure once (e.g., due to activation of a particular radio frequency), however, where the OD SSBs and AO SSBs never overlap in the frequency domain, multiple interruptions may occur during the SCell activation procedure.

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

[0039] Fig. 1 illustrates an example timing diagram showing interruptions that can occur during a SCell activation procedure when OD SSBs and AO SSBs are supported by the SCell and do not overlap in frequency.

[0040] As shown in Fig. 1, the SCell may support one or more bandwidth parts (BWPs) such as a first BWP (e.g., BWP1) and a second BWP (e.g., BWP2). The SCell may also support the transmission of both OD and AO SSBs which are configured to be transmitted over different frequencies supported by the SCell. For example, the OD-SSB may be configured to be transmitted over BWP1 of the SCell, and the AO SSB may be configured to be transmitted over BWP2. Additionally, the OD SSBs and AO SSBs may be configured to be used for different purposes. For example, the OD SSBs may be used for SCell activation, automatic gain control (AGC), and the like, while the AO SSBs may be used for fine tracking, and the like. As a consequence of the OD SSBs and AO SSBs being transmitted on different BWPs, as shown in Fig. 1, upon SCell activation and / or OD SSB transmission activation, a first interruption may occur during which a first radio frequency (RF) associated with BWP2 is activated, to enable transmission of the OD SSBs using the first RF associated with BWP2, to enable UEs communicating with a RAN node over that SCell to receive those OD SSBs (e.g., for AGC, or the like). Sometime later, a second interruption may occur during which the first radio frequency (RF) associated with BWP2 is deactivated and a second radio frequency (RF) associated with BWP1 is activated, to enable transmission of the AO SSBs using the second RF associated with BWP1, to enable UEs communicating with a RAN node over that SCell to receive those AO SSBs (e.g., for fine tracking, or the like). Sometime later again the above switching between BWP2 and BWP1 may occur again, causing further interruptions.

[0041] Such interruptions that occur when the OD SSBs and AO SSBs being transmitted on different BWPs not only cause delays in the transmission and reception of the OD SSBs and AO SSBs for the SCell, but also may cause delays in the serving cell (or cells) of the communication system that trigger the SCell activation and / or OD SSB transmission activation.

[0042] Furthermore, it will be appreciated that in the case where the OD SSBs and AO SSBs are both supported by a SCell and are transmitted on different BWPs over the SCell, any UEs communicating with a RAN node over that SCell needs to track the OD SSBs and AO SSBs in two separate frequencies for time / frequency tracking or other L1 procedures such as radio link management (RLM), beam management procedures, path-loss procedures, and the like; this adds complexity at those UEs, as typically UEs are configured to use AO SSBs in a single frequency location (i.e., on the synchronisation raster) to perform L1 measurement procedures, and the like.

[0043] However, irrespective of the increased complexities associated with the implementation of OD SSBs and AO SSBs supported by a SCell that are transmitted on different BWPs, the ability to support the transmission of OD SSBs and AO SSBs over a SCell on different frequencies is important where the SCell is an NES Cell. For example, when the SCell is an NES SCell, that NES SCell may be deployed in a manner that supports both NES users (e.g., a UE which supports on-demand SSB operation) and legacy users (e.g., a UE which does not support on-demand SSB operation). In this scenario, the legacy users may only be able to use the AO SSBs for SCell operation, whilst the NES users may be able to use both the AO SSBs and the OD SSBs for SCell operation. For example, where the SCell is an NES SCell, the AO SSBs may be configured to be transmitted with a high periodicity (e.g., 160 ms) to enable power savings over the NES SCell, and thus the NES users may from time to time need to utilise both the AO SSBs and the OD SSBs where the periodicity of the AO SSBs is not sufficient for the needs of the NES user.

[0044] As will be appreciated, as such NES SCells may support both NES users (e.g., a UE which supports on-demand SSB operation) and legacy users (e.g., a UE which does not support on-demand SSB operation), the AO SSBs and OD SSBs may need to be transmitted on different frequencies (e.g., different BWPs) to ensure that the legacy users do not accidently detect OD SSBs which they are not configured to support. Thus, in the case where both OD SSBs and AO SSBs are supported by a SCell it may be preferable for the AO SSBs to be configured as CD-SSBs and thus located on the synchronisation raster, whilst the OD SSBs may be configured as NCD-SSBs and thus not be located on the synchronisation raster, thereby ensuring that the AO SSBs and OD SSBs are transmitted on different frequencies (e.g., different BWPs). In this case, only one of the SSB types (e.g., AO / CD SSB, or OD / NCD SSB) that is associated with the frequency location configured for the CSI reference signals may be used for CSI measurements, and whether a CSI report configuration is associated with one or both the OD SSBs and the AO SSBs may depend on whether the OD SSBs and AO SSBs are located in the same frequency or not.

[0045] However, whilst much progress has been made to facilitate NES SCells that can support both NES users (e.g., a UE which does supports on-demand SSB operation) and legacy users (e.g., a UE which does not support on-demand SSB operation) by, for example, configuring those NES SCells to support the transmission of both OD SSBs and AO SSBs on different frequencies, the mere fact that the OD SSBs and AO SSBs are transmitted over different frequencies introduces complexities at the UE-side of the communication system, especially for NES UEs (e.g., UEs which support on-demand SSB operation), as described above with reference to Fig. 1.

[0046] There is therefore a need to develop mechanisms to simplify the complexity associated with NES SCells that are configured to transmit OD SSBs and AO SSBs at different frequencies to support communication with both legacy and NES UEs.

[0047] The disclosure aims to describe one or more apparatus and / or one or more associated mechanisms / procedures that at least partially addresses or contributes to meeting one or more of the above needs and / or addressing one or more of the above issues.

[0048] The disclosure has a method performed by a User Equipment, UE, the method comprising transmitting, to a network device, a first UE capability message including a first indication on whether or not the UE supports measurement on both of an on-demand, OD, Synchronization Signal Physical Broadcast Channel, PBCH, block, SSB transmitted at a first frequency location and an always-on, AO, SSB transmitted at a second frequency location, wherein the first frequency location and the second frequency location are different; and measuring at least either the OD SSB or the AO SSB.

[0049] The disclosure has a method performed by a network device, the method comprising receiving, from a User Equipment, UE, a first UE capability message including a first indication on whether or not the UE supports measurement on both of an on-demand, OD, Synchronization Signal Physical Broadcast Channel, PBCH, block, SSB transmitted at a first frequency location and an always-on, AO, SSB transmitted at a second frequency location, wherein the first frequency location and the second frequency location are different; and receiving one or more measurement reports on at least either the OD SSB or the AO SSB.

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

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

[0052] Examples of apparatus and methods will now be described, by way of example, with reference to the accompanying drawings in which:Fig. 1 illustrates an example timing diagram showing interruptions that can occur during a SCell activation procedure when OD SSBs and AO SSBs that do not overlap in frequency are supported by a SCell;Fig. 2 schematically illustrates a ('cellular' or 'wireless') communication system;Fig. 3 schematically illustrates a RAN node of the communication system of Fig. 2 and PCell / SCell cell coverage provided by the RAN node to a UE;Fig. 4A illustrates a number of example ways in which an SCell may be configured to receive SSBs for that SCell;Fig. 4B illustrates a number of example ways in which an SCell may be configured to receive SSBs for that SCell;Fig. 4C illustrates a number of example ways in which an SCell may be configured to receive SSBs for that SCell;Fig. 5 illustrates a simplified sequence diagram illustrating a procedure for indicating to the network whether a UE is capable of performing simultaneous measurements of both OD SSBs and AO SSBs transmitted on different frequencies over an NES SCell;Fig. 6 illustrates an example way in which an SCell may be configured to receive AO SSBs and OD SSBs for that SCell.Fig. 7 illustrates a table listing examples of types of measurements that may be made by a UE using OD SSBs and / or AO SSBs transmitted over a SCell;Fig. 8 illustrates an example of another way in which an SCell may be configured to receive AO SSBs and OD SSBs for that SCell;Fig. 9 illustrates an example of yet another way in which an SCell may be configured to receive AO SSBs and OD SSBs for that SCell;Fig. 10A illustrates an example of a non-uniform distribution of the transmission of OD SSBs and AO SSBs over a SCell;Fig. 10B illustrates another example of a non-uniform distribution of the transmission of OD SSBs and AO SSBs over a SCell;Fig. 11 illustrates example UE counting of OD SSBs and AO SSBs transmitted over a SCell;Fig. 12 illustrates another example UE counting of OD SSBs and AO SSBs transmitted over a SCell;Fig. 13 is a simplified block schematic illustrating the main components of a user equipment that may be used in the communication system of Fig. 2; andFig. 14 is a simplified block schematic illustrating the main components of a RAN node that may be used in the communication system of Fig. 2.

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

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

[0055] 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. Communication via the RAN node 5 is typically routed through a core network 7 (e.g., a 5G / 6G core network evolved packet core network (EPC)) or any other generations core network.

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

[0057] Each RAN node 5 controls one or more associated cells 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.

[0058] 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 RAN node to RAN node interface (such as the so-called 'X2' interface, 'Xn' interface, and / or the like).

[0059] 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 5G security processes).

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

[0061] 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., N6 reference point) for communication of the user data. The AMF 10-1 performs mobility management related functions, maintains the NAS connection with each UE 3 and manages UE registration. The AMF 10-1 is also responsible for managing paging. The AMF 10-1 receives user information sent through the network and forwards the information to the SMF 10-2.

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

[0063] The RAN node 5 of the communication system 1 is configured to operate at least one cell on an associated time-division duplex (TDD) carrier that operates in unpaired spectrum and / or at least one cell on an associated frequency-division duplex (FDD) carrier that operates in paired spectrum.

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

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

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

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

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

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

[0070] 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 the UE 3 may monitor for. Typically, the 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, the 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.

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

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

[0073] <Synchronisation Signal (SS) / Physical Broadcast Channel (PBCH) Blocks (SSBs)> 　　The RAN node 5 is also configured to transmit synchronisation signal (SS) / Physical Broadcast Channel (PBCH) blocks (SSBs) periodically in the cell or cells 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 (e.g., parameters required for acquiring system information block 1 (SIB1) which carries other minimum system information).

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

[0075] The RAN node 5 may transmit several SSBs corresponding to different DL beams. The total number of SSBs may be confined, for example, within a 5 ms duration as an SS burst. The periodicity of the SSB transmissions may be indicated to the UE using any suitable signalling (e.g., per serving cell using ssb-periodicityServingCell). The periodicity value for the SSB may be, for example, greater than or equal to 20 ms. For initial cell selection, the UE 3 may be configured to assume that an SS burst occurs with a periodicity of 2 frames. The UE 3 may also be provided with an indication of which SSBs within a 5 ms duration are transmitted (e.g., using ssb-PositionsInBurst). The UE 3 may also be provided with an indication of an absolute transmit power value of the SSS (e.g., using ss-PBCH-BlockPower) which may range from -60 to 50 dBm. Furthermore, the UE 3 may also be provided with an indication of the 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).

[0076] 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 a RAN node 5.

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

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

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

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

[0081] <On-Demand SSB in the context of Carrier Aggregation (CA)> 　　In the communication system 1, 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.

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

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

[0084] A group of serving cells associated with a master RAN Node 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 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.

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

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

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

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

[0089] By way of example, Fig. 3 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.

[0090] As shown in Fig. 3, in the illustrated example, the RAN node 5 provides a first serving (primary) cell (e.g., PCell). 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) that a UE 3 may access at some later time after initially camping onto the serving cell. As shown in Fig. 3, the SCell may be a cell that is a smaller cell overlapping with, or wholly incorporated within, the PCell. The SCell, unlike the PCell, may be a cell over which UEs cannot (or at least cannot routinely) receive SSBs and / or system information (e.g., SIB messages). For example, a SCell 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.

[0091] A number of ways in which an SCell may be configured will now be described, by way of example only, with respect to Figs. 4A -.4C.

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

[0093] Fig. 4B 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.

[0094] As shown in Fig. 4B, the SCell 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 in a periodic manner as in Fig. 4A, 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, specifically requests the SSBs (e.g., if / when the UE 3, and / or RAN node 5 providing the SCell, triggers activation of the SCell, or the like).

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

[0096] As shown in Fig. 4C, the SCell may be configured to provide a combination of 'always-on' SSBs and on-demand SSBs (also referred to as Case#2). For example, the SCell may be configured to provide always-on SSBs in a periodical 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, 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.

[0097] However, as described above (and depicted in Fig. 4C), whilst it is important that the AO SSBs and the OD SSBs are transmitted on different frequencies, especially in the context where the SCell is an NES SCell to ensure that legacy users do not accidently detect OD SSBs scheduled for NES users, the provision of both types of SSBs over an NES SCell that can support communication with both legacy UEs 3 (e.g., UEs 3 which do not support on-demand SSB operation) and NES UEs 3 (e.g., UEs 3 which support on-demand SSB operation) increases complexity in the communication system at the UE-side, especially for UEs 3 which support on-demand SSB operation, as they may need to monitor both OD-SSBs and AO-SSBs simultaneously on different frequencies. Furthermore, complexity may also arise and the network-side of the communication system 1 on account of the NES SCell supporting communication with both legacy and NES UEs 3.

[0098] The communication system 1 is beneficially configured to support one or more mechanisms and procedures for simplifying the complexity associated with NES SCells that are configured to transmit OD SSBs and AO SSBs at different frequencies, and which support communication with both legacy and NES UEs 3.

[0099] The communication system 1 may be beneficially configured to support UE capability signalling over NES SCells that allow the transmission of both OD SSBs and AO SSBs at different frequencies to support communication with both legacy and NES UEs 3 and to indicate a UE's capability to perform OD SSB-based measurements and / or AO SSB-based measurements (e.g., simultaneously).

[0100] The communication system 1 may also be beneficially configured to implement one or more restrictions for the measurement of both OD SSBs and AO SSBs that are transmitted over NES SCells to simplify the complexity associated with NES SCells that are configured to transmit OD SSBs and AO SSBs at different frequencies, and which support communication with both legacy and NES UEs 3.

[0101] < UE Capability Signalling> 　　It will be appreciated that whether or not a UE 3 can monitor for OD SSBs and / or AO SSBs that are transmitted on different frequencies over an NES SCell to perform OD SSB-based measurements and / or AO SSB-based measurements respectively, may depend on hardware restrictions of the UE 3. For example, some UEs 3 (e.g., a UE 3 supporting on-demand SSB operation, or the like) may be capable of performing simultaneous measurements of both the OD SSBs and the AO SSBs transmitted on different frequencies over the NES SCell (i.e., the UE 3 is capable of measuring the OD SSBs and AO SSBs that are on different frequencies, periodically within a time window (e.g. 20ms / 40ms)), whilst other UEs 3 (e.g., legacy UEs 3) may not have such capability.

[0102] Fig. 5 illustrates a simplified sequence diagram illustrating a procedure for indicating to the network whether a UE is capable of performing simultaneous measurements of both OD SSBs and AO SSBs transmitted on different frequencies over an NES SCell.

[0103] As shown in Fig. 5, the RAN node 5 and a UE 3 deployed in the communication system 1 of Fig. 2 are in communication with one another, and the UE 3 is camped on a serving cell (e.g., PCell) provided by that RAN node 5.

[0104] At step S502, the RAN node 5 may send to the UE 3 a request message for UE capability information (e.g., a UE capability information request message, a UE capability enquiry, or the like) to request that the UE 3 provide the RAN node 5 with appropriate capability information.

[0105] At step S504, the UE 3 sends to the RAN node 5, (either independently or in response to the message received at step S502), a UE capability message, or the like, to indicate to the RAN node 5 the UE's capabilities. For example, the UE capability message may include an appropriate indication of whether or not that UE 3 is capable of performing simultaneous measurements of both OD SSBs and AO SSBs transmitted on different frequencies. In this scenario simultaneous measurements means that within a time window (e.g. 20 ms / 40 ms) the UE 3 is capable of measuring both OD-SSB and AO-SSB transmitted in different frequencies periodically.

[0106] Additionally (or alternatively), that UE capability message may include an appropriate indication of whether or not that UE 3 is capable of performing simultaneous measurements of both OD SSBs and AO SSBs transmitted on different frequencies but within a same BWP.

[0107] Additionally (or alternatively), that UE capability message may include an appropriate indication of whether or not that UE 3 is capable of performing simultaneous measurements of both OD SSBs and AO SSBs transmitted on different frequencies and which are within different BWPs (e.g., the OD SSBs may be transmitted over BWP1 (which may be the active BWP) and the AO SSBs may be transmitted on BWP2, or vice versa).

[0108] Additionally, that UE capability message may include an appropriate indication of how many frequency carriers (or cells) for which the UE 3 is capable of performing simultaneous measurements of both OD SSBs and AO SSBs transmitted on different frequencies.

[0109] Additionally (or alternatively), that UE capability message may include an appropriate indication of on which frequency carriers (or cells) the UE 3 is capable of performing simultaneous measurements of both OD SSBs and AO SSBs transmitted on different frequencies.

[0110] Additionally (or alternatively), that UE capability message may include an appropriate indication that the UE 3 is capable of performing simultaneous measurements of both OD SSBs and AO SSBs transmitted on different frequencies if the time difference between the transmission of the OD SSBs and the transmission of the AO SSBs is at least equal to, or greater than, a threshold.

[0111] It will be appreciated however that in the case where the UE capability information indicates that a UE 3 does not support simultaneous measurements on both AO SSBs and OD SSBs (e.g., where the UE 3 supports on-demand SSB operation and is communicating over the NES SCell), appropriate restrictions may need to be applied to i) the manner in which the AO SSBs and OD SSBs are transmitted over the SCell and / or ii) how the UE 3 should measure those AO SSBs and OD SSBs.

[0112] <Measurement Restrictions for AO SSBs and OD SSBs> 　　It will be appreciated that while for the purposes of making a single type of measurement (e.g., a L1 measurement, or the like), a UE 3 may be configured to measure either AO SSBs or OD SSBs being transmitted over the NES SCell, in the case where the UE 3 is configured to perform multiple different types of measurements using the AO SSBs and OD SSBs being transmitted over the NES SCell, some restrictions may need to be implemented.

[0113] For example, in the case where the UE 3 is configured to monitor AO SSBs for link recovery procedures (after NES SCell is activated) and OD SSBs for L1 beam measurements, appropriate restrictions may need to be implemented if, nevertheless, the UE 3 in question is unable to perform simultaneous measurements of both AO SSBs and OD SSBs. Similarly, in another example, in the case where the UE 3 is configured to perform different L1 measurements associated with OD SSBs and AO SSBs respectively, appropriate restrictions may need to be implemented if, nevertheless, the UE 3 in question is unable to perform simultaneous measurements of both AO SSBs and OD SSBs.

[0114] <Measurement Restrictions Based on Measurement Type> 　　Fig. 6 illustrates an example way in which an SCell may be configured to receive AO SSBs and OD SSBs for that SCell.

[0115] As shown in Fig. 6, in a case where a UE 3 communicating over an SCell does not support simultaneous measurement of both AO SSBs and OD SSBs that are transmitted on different frequencies over that SCell, the network may configure / ensure that the UE 3 is only required to periodically measure one of the SSBs (e.g., AO SSBs or OD SSBs) for different measurement purposes. For example, after NES SCell is activated for the UE 3, the network may configure the UE 3 to perform link recovery measurements, which require periodic measurements of SSBs, using the AO SSBs. Similarly, the network may configure the UE 3 to perform RRM measurements, which require periodic measurements of SSBs, using the AO SSBs.

[0116] At the same time, by way of example only, the network may configure the UE 3 to perform other measurements that do not necessarily require recurrent SSBs (e.g., some RRM measurement, random access procedures, or the like) using the OD SSBs. For example, the network may configure the UE 3 to perform aperiodic and / or semi-persistent measurements using the OD SSBs.

[0117] For example, the table shown in Fig. 7 illustrates example measurements / procedures that may be supported by the UE 3: using AO SSBs only; or using either AO SSBs or OD SSBs. As shown in Fig. 7, radio link monitoring, link recovery procedures, random access procedures, periodic RRM measurements, semi-persistent RRM measurements, and aperiodic RRM measurements may all be performed using AO SSBs. Conversely, as shown in Fig. 7, only random access procedures, semi-persistent RRM measurements, and aperiodic RRM measurements may be performed using OD SSBs.

[0118] It will be appreciated that the measurements and procedures that may be performed using AO SSBs and OD SSBs as shown in Fig. 7 are by way of example only and that other measurements and procedures may also be performed using AO SSBs and / or OD SSBs.

[0119] Additionally, the network may configure a minimum time gap between the transmission of the AO SSBs and the OD SSBs if the UE 3 needs to perform measurements of the AO SSBs and the OD SSBs. Alternatively, the network may configure the UE 3 to drop OD SSB-based measurements if the UE 3 needs to perform measurements of both the AO SSBs and the OD SSBs (e.g., at the same, or nearly the same, time).

[0120] For example, as shown in Fig. 6, the OD SSBs transmitted over the SCell and used by the UE 3 to perform link recovery measurements, RRM measurements, or any other appropriate measurement that requires SSBs to be transmitted periodically, are transmitted at a fixed periodicity in a first frequency / BWP. The AO SSBs, which are used by the UE 3 to perform some RRM measurement, random access procedures, or any other measurement / procedure that does not require SSBs to be transmitted periodically, are transmitted not just on a different frequency / BWP, but also at a time such that a minimum time gap is formed between the transmission of OD SSBs and the AO SSBs transmissions either side of the OD SSBs.

[0121] Additionally, the network may configure measurement gaps to support OD SSBs in the case where the UE 3 needs to measure both the OD SSBs and the AO SSBs. For example, the network may configure measurement gaps for measuring the OD SSBs whereby the measurement gaps have the same periodicity and time occurrence as the OD SSBs. Additionally, the tiggering / activation of OD SSBs by the network (e.g., by the RAN node 5) may be configured to simultaneously trigger / activate the configured measurement gaps for measuring the OD SSBs. For example, within a measurement gap configuration, the network may indicate that upon the tiggering / activation of OD SSBs by the network, the configured measurement gaps for measuring the OD SSBs should also be triggered / activated.

[0122] Additionally, the measurement gaps configured by the network may be configured to the UE 3 (e.g., via an appropriate configuration message) even if the UE 3 supports simultaneous monitoring of both AO SSBs and OD SSBs, but OD SSBs are being transmitted (or are about to be transmitted) on a non-active BWP of the UE 3.

[0123] Additionally, when an NES SCell is not activated for the UE 3, the network may configure the UE 3 to perform RRM measurements, which requires periodic measurements of SSBs, using only one of either AO SSBs and OD SSBs (but not both AO SSBs and OD SSBs). For example, before an NES SCell is activated for the UE 3, the network may configure the UE 3 to perform periodic RRM measurements using OD SSBs and perform aperiodic and / or semi-persistent measurements using the AO SSBs. Alternatively in another example, before an NES SCell is activated for the UE 3, the network may configure the UE 3 to perform periodic RRM measurements using AO SSBs and perform aperiodic and / or semi-persistent measurements using the OD SSBs.

[0124] <Measurement Restrictions Based on SSB Frequency Location> 　　Fig. 8 illustrates an example of another way in which a UE 3 may be configured to receive AO SSBs and OD SSBs for that SCell.

[0125] As shown in Fig. 8, in a case where the UE 3 communicating over an SCell does not support simultaneous measurement of both AO SSBs and OD SSBs that are transmitted on different frequencies over that SCell, as well as restriction #1, measurements of both the AO SSBs and the OD SSBs may be restricted based on a frequency location of those AO SSBs and OD SSBs.

[0126] For example, as shown in Fig. 8, the UE 3 may be configured such that if the OD SSBs are transmitted in a different BWP to the active BWP of the UE 3, then the UE 3 does not have to measure the OD SSBs. However, in the case where OD-SSBs are the only SSB type which is present within the active BWP of the UE 3 (and AO-SSB is on a different BWP) then the UE 3 may measure the OD SSBs for all periodic type measurements including link recovery measurements if OD-SSBs are transmitted periodically to the UE 3. In this case, the UE 3 may not be required to perform periodic measurements of AO-SSB. For instance, the UE 3 may perform only aperiodic or semi-persistent measurement of AO-SSB in this case.

[0127] However, in the case where OD-SSBs are the only SSB type which is present within the active BWP of the UE 3 (and AO-SSB is on a different BWP) and those OD SSBs are not transmitted periodically to the UE 3, the UE 3 may still need to perform AO SSB-based measurements for link recovery. In this scenario the restrictions related to measurement type described above are applicable for the OD SSBs. Furthermore, in this case, an additional time gap (which is based on a BWP switching time) may be required between the end of transmission of AO-SSBs (or OD-SSBs) and the start of transmission of the OD-SSBs (or AO-SSBs) to enable the UE 3 to monitor both the OD-SSBs and the AO-SSBs. Otherwise, the UE 3 may be configured to drop OD-SSB transmissions for measurement purpose e.g., if the UE 3 needs to perform AO-SSB measurements for RLM.

[0128] <SSB Prioritisation> 　　Alternatively, rather than applying restrictions related to measurement type and / or restrictions based on SSB frequency location , in the case where a UE 3 communicating over an SCell does not support simultaneous measurement of both AO SSBs and OD SSBs that are transmitted on different frequencies over that SCell, the UE 3 may be configured to prioritise one type of SSB transmission (e.g., AO SSBs or OD SSBs) over another.

[0129] In one example, the network may configure the UE 3 to prioritise one type of SSB transmission over another via an appropriate network indication sent to by the network (e.g., RAN node 5) to the UE 3. For example, the network may indicate to the UE 3 to periodically monitor OD SSBs for different measurement types (e.g. link recovery) when OD-SSBs are being transmitted; otherwise, the UE 3 may use AO-SSBs. Alternatively, the network may indicate to the UE 3 to perform CSI reporting based on only OD SSBs, in which can the UE 3 may prioritise OD SSB measurements using OD SSBs.

[0130] In another example, the network may configure the UE 3 to prioritise one SSB type over another based on the criticality of the SSB measurements to be reported. For instance, the UE 3 may prioritise the SSB type which is to be used for link recovery measurements (e.g., AO SSBs as shown in the table of Fig. 7).

[0131] In yet another example, the network may configure the UE 3 to prioritise one SSB type over another based on the location of SSB transmissions. For instance, if OD SSBs are being transmitted in the active BWP of the UE 3 (and AO SSBs are not) then the UE 3 may prioritise the OD SSB measurements made using OD SSBs for all measurement types and vice versa.

[0132] In a further example, the network may configure the UE 3 to prioritise one SSB over another based on the availability of SSB transmissions. For instance, the UE 3 may prioritise OD SSB measurements made using OD SSBs if OD SSB measurements are periodically transmitted and are available more frequently than the AO SSBs.

[0133] <Common Frequency for OD-SSBs and AO-SSBs> 　　It will be appreciated that in the case where the OD SSBs and the AO SSBs are transmitted at the same frequency as shown in Fig. 9, there may be no restrictions on performing simultaneous measurements of OD-SSB and AO-SSB by the UE 3, and thus periodic measurements may be performed using both the OD SSBs and the AO SSBs. In this case, the network may configure the UE 3 to perform periodic measurements using the OD SSBs on top of periodic measurements using the AO SSBs.

[0134] <Handling Non-Uniform SSB Bursts> 　　It will be appreciated that in the case where the OD SSBs and the AO SSBs are transmitted at the same frequency as shown in Fig. 9, it is still possible that the combined time periodicity of the OD SSBs and the AO SSBs may be non-uniform.

[0135] For example, as shown in Fig. 10A whilst the OD SSBs may be transmitted periodically (e.g., at a periodicity of 10 ms) and the AO SSBs are transmitted periodically (e.g., at a periodicity of 20 ms), when combined the time periodicity of the OD SBBs and the AO SSBs may not be uniform. In this case, the UE 3 may not be able to support simultaneous measurements of both the OD SSBs and the AO SSBs.

[0136] Similarly, as shown in Fig. 10B, whilst the OD SSBs and the AO SSBs may be transmitted at the same periodicity (e.g., at a periodicity of 10 ms) the combined SSB pattern may still be non-uniform due to offsets selected for the OD SSBs and the AO SSBs, then the UE 3 may also not be able to support simultaneous measurements of both the OD SSBs and the AO SSBs.

[0137] In these scenarios, the UE 3 may not be expected to monitor SSB bursts with non-uniform periodicity. Instead, the UE 3 may be expected (or indicated to / configured by the network) to monitor only one of OD SSBs or AO SSBs. For example, the RAN node 5 may indicate to the UE 3 that the UE 3 should only monitor OD SSBs (or AO SSBs).

[0138] < UE Counting of SSBs> 　　In addition to the restrictions described above and the handling of non-uniform SSB bursts, there may also be a need for appropriate mechanisms to enable a UE 3 to count SSB resources and SSBs that are to be measured by the UE 3 in different scenarios, more especially in the case where both AO SSBs and OD SSBs are being measured. For example, in the case where the UE 3 measures SSBs for L1 measurements, the UE 3 may be required to measure a specific (e.g., preconfigured / predefined) number of SSBs to make those L1 measurements, and thus the UE 3 in this case should be able to count the number of SSBs it has measured to ensure it has measured the required number.

[0139] In a first example, the UE 3 may be configured to count the number of OD SSBs / OD SSB resources measured, in addition to the number of AO SSBs / AO SSB resources measured when OD SSBs is either periodically or semi-persistently transmitted (and thus measured by the UE 3).

[0140] In another example, the UE 3 may be configured to count the number of OD SSBs / OD SSB resources measured, in addition to the number of AO SSBs / AO SSB resources measured, when a single CSI reporting configuration received by the UE 3 includes both SSB types as reporting metrics.

[0141] In another example, the UE 3 may separately count OD SSBs / OD SSB resources which are measured (in addition to AO SSBs / AO SSB resources) if the resources used for transmitting those OD SSBs are not quasi co-located with any of the AO SSBs / AO SSB resources measured by the UE 3 as shown in Fig. 11.

[0142] For example, as shown in Fig. 11, the UE 3 may count the number of OD SSBs, and the number of AO SSBs received and measured when those OD SSBs and AO SSBs are transmitted on different frequency resources.

[0143] In other words, if the frequency of the AO SSBs and OD SSBs are the same, then UE 3 may not count the OD SSBs / OD SSB resources separately (e.g., if the corresponding quasi co-located AO SSBs / AO SSB resources are already being counted by the UE 3) as shown in Fig. 12.

[0144] In yet another example, the UE 3 may count the number of OD SSBs / OD SSB resources measured in addition to AO SSBs / AO SSB resources measured when transmission parameters related to the OD SSB beams transmitted (e.g., ssb-PositionsInBurst IE) are differently configured for OD SSBs compared to CD-SSBs.

[0145] It will also be appreciated that different capabilities / restrictions may be defined in terms of how many OD SSBs / OD SSB resources that the UE 3 is configured to measure simultaneously for a given measurement report.

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

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

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

[0149] The communication control module 43 is operable to control the communication between the UE 3 and its serving RAN node or RAN nodes 5 (and other communication devices connected to the RAN node 5, such as further UEs and / or core network nodes). The communication control module 43 is configured for the overall handling of uplink communication via associated uplink channels (e.g., via a 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.

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

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

[0152] <RAN node> 　　Fig. 14 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. 2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0180] 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 User Equipment, UE, the method comprising: 　　transmitting, to a network device, a first UE capability message including a first indication on whether or not the UE supports measurement on both of an on-demand, OD, Synchronization Signal Physical Broadcast Channel, PBCH, block, SSB transmitted at a first frequency location and an always-on, AO, SSB transmitted at a second frequency location, wherein the first frequency location and the second frequency location are different; and measuring at least either the OD SSB or the AO SSB. 　　(Supplementary note 2) 　　The method of supplementary note 1, wherein the first indication further indicates whether or not the UE supports a simultaneous measurements of the OD SSB and the AO SSB, when the first frequency location is different from the second frequency location. 　　(Supplementary note 3) 　　The method of supplementary note 1 or 2, wherein the first frequency location and the second frequency location are within a same Bandwidth Part, BWP. 　　(Supplementary note 4) 　　The method of supplementary note 1 or 2, wherein the first frequency location is within a first Bandwidth Part, and the second frequency location is within a second BWP, wherein the first BWP is different from the second BWP. 　　(Supplementary note 5) 　　The method of any one of supplementary notes 1-4, wherein the first UE capability message further includes a second indication on a number of frequency carriers for which the UE supports simultaneous measurements of the OD SSB and the AO SSB transmitted on different frequencies. 　　(Supplementary note 6) 　　The method of supplementary note 5, wherein the first UE capability message further includes a third indication indicating the frequency carriers for which the UE supports simultaneous measurements of the OD SSB and the AO SSB transmitted on different frequencies. 　　(Supplementary note 7) 　　The method of supplementary note 2, wherein the first UE capability message further includes a fourth indication indicating whether the UE supports the simultaneous measurements if time difference between transmission of the OD SSB and transmission of the AO SSB is at least equal to, or greater than, a threshold. 　　(Supplementary note 8) 　　The method of any one of supplementary notes 1-7,wherein the UE is configured to monitor the AO SSB for a link recovery procedure and to monitor the OD SSB for L1 beam measurements. 　　(Supplementary note 9) 　　The method of any one of supplementary notes 1-8, further comprising: receiving, from the network device, a first configuration of measurement associated with either one of the OD SSB or the OA SSB. 　　(Supplementary note 10) 　　The method of supplementary note 9, wherein the first configuration indicates link recovery measurements associated with the AO SSB. 　　(Supplementary note 11) 　　The method of supplementary note 9, wherein the first configuration indicates Radio Resource Management, RRM, measurements associated with e periodic measurements of the AO SSB. 　　(Supplementary note 12) 　　The method of any one of supplementary notes 1-11, further comprising: receiving, from the network device, a second configuration associated with the OD SSB, wherein the second configuration is for aperiodic or semi-persistent reporting. 　　(Supplementary note 13) 　　The method of any one of supplementary notes 1-12, wherein the AO SSB is configured for at least one of: radio link monitoring, link recovery procedures, random access procedures, periodic RRM measurements, semi-persistent RRM measurements, and aperiodic RRM measurements. 　　(Supplementary note 14) 　　The method of any one of supplementary notes 1-13, wherein the OD SSB is configured for at least one of: random access procedures, semi-persistent RRM measurements, and aperiodic RRM measurements. 　　(Supplementary note 15) 　　The method of any one of supplementary notes 1-14, further comprising: 　　receiving, from the network device, a third configuration indicating a minimum time gap between transmission of the AO SSB and transmission of the OD SSB. 　　(Supplementary note 16) 　　The method of any one of supplementary notes 1-15, further comprising: 　　receiving, from the network device, a fourth configuration for the UE to drop OD SSB-based measurements in a case where the UE performs measurements of both the AO SSB and the OD SSB. 　　(Supplementary note 17) 　　The method of any one of supplementary notes 1-16, further comprising: 　　receiving, from the network device, a fifth configuration indicating a measurement gap to support the OD SSB in the case where the UE measures both the OD SSB and the AO SSB. 　　(Supplementary note 18) 　　The method of any one of supplementary notes 1-17, wherein, in a case where the OD SSB is transmitted in a different BWP to an active BWP of the UE, the UE is not required to measure the OD SSB. 　　(Supplementary note 19) 　　The method of supplementary note 18, wherein in a case where the OD-SSB is the only SSB type which is present within the active BWP of the UE, the UE measures the OD SSB for all periodic type measurements. 　　(Supplementary note 20) 　　The method of any one of supplementary notes 1-19, further comprising: 　　receiving, from the network device, a sixth configuration indicating priority information for a type of SSB transmission. 　　(Supplementary note 21) 　　The method of supplementary note 9, wherein the first configuration is associated with only OD SSB. 　　(Supplementary note 22) 　　The method of supplementary note 20, wherein the priority information is based on at least one of: criticality of measurements to be reported based on the SSB transmission, location of the SSB transmission, and availability of the SSB transmission. 　　(Supplementary note 23) 　　The method of any one of supplementary notes 1-22, further comprising: 　　counting a number of OD SSBs or OD SSB resources that are measured, and a number of AO SSBs or AO SSB resources that are measured. 　　(Supplementary note 24) 　　A method performed by a network device, the method comprising: 　　receiving, from a User Equipment, UE, a first UE capability message including a first indication on whether or not the UE supports measurement on both of an on-demand, OD, Synchronization Signal Physical Broadcast Channel, PBCH, block, SSB transmitted at a first frequency location and an always-on, AO, SSB transmitted at a second frequency location, wherein the first frequency location and the second frequency location are different; and receiving one or more measurement reports on at least either the OD SSB or the AO SSB.

[0181] This application is based upon and claims the benefit of priority from Great Britain Patent Application No. 2501786.4, filed on February 6, 2025, the disclosure of which is incorporated herein in its entirety by reference.

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

1. A method performed by a User Equipment, UE, the method comprising: 　　transmitting, to a network device, a first UE capability message including a first indication on whether or not the UE supports measurement on both of an on-demand, OD, Synchronization Signal Physical Broadcast Channel, PBCH, block, SSB transmitted at a first frequency location and an always-on, AO, SSB transmitted at a second frequency location, wherein the first frequency location and the second frequency location are different; and measuring at least either the OD SSB or the AO SSB.

2. The method of claim 1, wherein the first indication further indicates whether or not the UE supports a simultaneous measurements of the OD SSB and the AO SSB, when the first frequency location is different from the second frequency location.

3. The method of claim 1 or 2, wherein the first frequency location and the second frequency location are within a same Bandwidth Part, BWP.

4. The method of claim 1 or 2, wherein the first frequency location is within a first Bandwidth Part, and the second frequency location is within a second BWP, wherein the first BWP is different from the second BWP.

5. The method of any one of claims 1-4, wherein the first UE capability message further includes a second indication on a number of frequency carriers for which the UE supports simultaneous measurements of the OD SSB and the AO SSB transmitted on different frequencies.

6. The method of claim 5, wherein the first UE capability message further includes a third indication indicating the frequency carriers for which the UE supports simultaneous measurements of the OD SSB and the AO SSB transmitted on different frequencies.

7. The method of claim 2, wherein the first UE capability message further includes a fourth indication indicating whether the UE supports the simultaneous measurements if time difference between transmission of the OD SSB and transmission of the AO SSB is at least equal to, or greater than, a threshold.

8. The method of any one of claims 1-7,wherein the UE is configured to monitor the AO SSB for a link recovery procedure and to monitor the OD SSB for L1 beam measurements.

9. The method of any one of claims 1-8, further comprising: receiving, from the network device, a first configuration of measurement associated with either one of the OD SSB or the OA SSB.

10. The method of claim 9, wherein the first configuration indicates link recovery measurements associated with the AO SSB.

11. The method of claim 9, wherein the first configuration indicates Radio Resource Management, RRM, measurements associated with e periodic measurements of the AO SSB.

12. The method of any one of claims 1-11, further comprising: receiving, from the network device, a second configuration associated with the OD SSB, wherein the second configuration is for aperiodic or semi-persistent reporting.

13. The method of any one of claims 1-12, wherein the AO SSB is configured for at least one of: radio link monitoring, link recovery procedures, random access procedures, periodic RRM measurements, semi-persistent RRM measurements, and aperiodic RRM measurements.

14. The method of any one of claims 1-13, wherein the OD SSB is configured for at least one of: random access procedures, semi-persistent RRM measurements, and aperiodic RRM measurements.

15. The method of any one of claims 1-14, further comprising: 　　receiving, from the network device, a third configuration indicating a minimum time gap between transmission of the AO SSB and transmission of the OD SSB.

16. The method of any one of claims 1-15, further comprising: 　　receiving, from the network device, a fourth configuration for the UE to drop OD SSB-based measurements in a case where the UE performs measurements of both the AO SSB and the OD SSB.

17. The method of any one of claims 1-16, further comprising: 　　receiving, from the network device, a fifth configuration indicating a measurement gap to support the OD SSB in the case where the UE measures both the OD SSB and the AO SSB.

18. The method of any one of claims 1-17, wherein, in a case where the OD SSB is transmitted in a different BWP to an active BWP of the UE, the UE is not required to measure the OD SSB.

19. The method of claim 18, wherein in a case where the OD-SSB is the only SSB type which is present within the active BWP of the UE, the UE measures the OD SSB for all periodic type measurements.

20. The method of any one of claims 1-19, further comprising: 　　receiving, from the network device, a sixth configuration indicating priority information for a type of SSB transmission.

21. The method of claim 9, wherein the first configuration is associated with only OD SSB.

22. The method of claim 20, wherein the priority information is based on at least one of: criticality of measurements to be reported based on the SSB transmission, location of the SSB transmission, and availability of the SSB transmission.

23. The method of any one of claims 1-22, further comprising: 　　counting a number of OD SSBs or OD SSB resources that are measured, and a number of AO SSBs or AO SSB resources that are measured.

24. A method performed by a network device, the method comprising: 　　receiving, from a User Equipment, UE, a first UE capability message including a first indication on whether or not the UE supports measurement on both of an on-demand, OD, Synchronization Signal Physical Broadcast Channel, PBCH, block, SSB transmitted at a first frequency location and an always-on, AO, SSB transmitted at a second frequency location, wherein the first frequency location and the second frequency location are different; and receiving one or more measurement reports on at least either the OD SSB or the AO SSB.

Images