Method, and mobile device

Abstract

A method performed by a mobile device includes: in a case where difference between a timing of on-demand synchronizing signal / physical broadcast channel (PBCH) block (SSB) / system information block 1 (SIB1) transmission and a timing of another SSB / SIB1 transmission is equal to or less than a threshold value, dropping or delaying either the on-demand SSB / SIB1 transmission or the another SSB / SIB1 transmission.

Description

METHOD, AND MOBILE DEVICE

[0001] The present disclosure relates to a communication system and to parts thereof. The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (including Long Term Evolution (LTE)-Advanced, Next Generation or 5G networks, future generations, and beyond). The present disclosure in particular, but not exclusively, relates to periodic and on-demand secondary cell (SCell) signal synchronisation / physical broadcast channel (PBCH) blocks (SSBs), periodic and on-demand system information block 1 (SIB1) messages, and their use in communication systems to achieve network energy savings (NESs).

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

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

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

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

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

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

[0008] Further, as the usage of 5G mobile communications for a wide range of different use cases increases, their complexity and energy demands are also expected to increase. With this in mind, efforts are being made to enhance network energy saving (NES) approaches that afford significant power savings in an industry standardized manner. To that end, techniques / procedures have been evaluated that have shown to bring substantial NES gains. By way of example only, such techniques / procedures may include: * The adaption of transmission patterns; * The use of wake-up signals (WUS) to allow devices such as UEs to enter reduced transmission / reception modes, (for example discontinuous transmission / reception modes); * The use of on-demand SSBs (and possibly other DL signals) for camping onto secondary cells (SCells) by UEs.

[0009] NPL 1: '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.

[0010] There is, nevertheless, still further development required to optimise the use of such NES techniques / procedures to ensure UEs can receive the required minimum system information whilst also minimising the unnecessary transmissions of minimum system information in order to maximise the available energy saving benefits.

[0011] The disclosure aims to provide one or more apparatus and / or one or more associated methods that at least partly contributes meeting the above need.

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

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

[0014] A method performed by a mobile device according to a first aspect of the present disclosure, the method comprises: 　　in a case where difference between a timing of on-demand synchronizing signal / physical broadcast channel (PBCH) block (SSB) / system information block 1 (SIB1) transmission and a timing of another SSB / SIB1 transmission is equal to or less than a threshold value, dropping or delaying either the on-demand SSB / SIB1 transmission or the another SSB / SIB1 transmission.

[0015] A mobile device according to a second aspect of the present disclosure comprises: 　　means for dropping or delaying either on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB) / system information block 1 (SIB1) transmission or another SSB / SIB1 transmission, in a case where difference between a timing of the on-demand SSB / SIB1 transmission and a timing of the another SSB / SIB1 transmission is equal to or less than a threshold value.

[0016] Example embodiments of the disclosure will now be described, by way of example, with reference to the accompanying drawings in which:Fig. 1 illustrates schematically a mobile (cellular or wireless) communication system;Fig. 2 illustrates a typical frame structure that may be used in the communication system of Fig. 1;Fig. 3 illustrates an example of a resource grid of a subframe shown in Fig. 2;Fig. 4A depicts a simplified sequence diagram illustrating an example procedure for indicating whether on-demand SSB transmissions for a given SCell are enabled that may be used in the communication system of Fig. 1;Fig. 4B depicts a simplified sequence diagram illustrating an example procedure for UE-requested on-demand SSB transmissions that may be used in the communication system of Fig. 1;Fig. 5 illustrates a simplified sequence diagram illustrating another procedure for requesting on-demand SSB transmissions that may be used in the communication system of Fig. 1;Fig. 6A illustrates a simplified sequence diagram illustrating a continuation (option A) of the procedure for requesting on-demand SSB transmissions of Fig. 5;Fig. 6B illustrates a simplified sequence diagram illustrating a different continuation (option B) of the procedure for requesting on-demand SSB transmissions of Fig. 5;Fig. 6C illustrates a simplified sequence diagram illustrating another different continuation (option C) of the procedure for requesting on-demand SSB transmissions of Fig. 5;Fig. 7A illustrates a simplified sequence diagram illustrating a further different continuation (option B) of the procedure for requesting on-demand SSB transmissions of Fig. 5;Fig. 7B illustrates a simplified sequence diagram illustrating a further different continuation (option C) of the procedure for requesting on-demand SSB transmissions of Fig. 5;Fig. 8 is a simplified block schematic illustrating the main components of a UE for implementation in the system of Fig. 1; andFig. 9 is a simplified block schematic illustrating the main components of a RAN node for implementation in the system of Fig. 1.

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

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

[0019] In the communication system 1, user equipments (UEs) 3-1, 3-2, 3-3 (e.g., mobile telephones and / or other mobile or stationary devices) can communicate with each other via a radio access network (RAN) node 5 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, the RAN node 5 comprises a base station 5 or 'gNB' 5 operating one or more associated cells 9. Communication via the RAN node 5 is typically routed through a core network 7 (e.g., a 5G / 6G or later generations core network or evolved packet core network (EPC)).

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

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

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

[0023] The core network 7 includes a number of logical nodes (or 'functions') for supporting communication in the communication system 1. In this example, the core network 7 comprises control plane functions (CPFs) 10 and one or more network node entities for the communication of user data (e.g. user plane functions (UPFs) 11). The CPFs 10 include one or more network node entities for the communication of control signalling (e.g. Access and Mobility Management Functions (AMFs) 10-1), one or more network node entities for session management (e.g. Session Management Functions (SMFs) 10-2) and a number of other functions 10-n (such as, for example an Authentication Server Function (AUSF) which facilitates security processes).

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

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

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

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

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

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

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

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

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

[0033] The RAN node 5 is also configured to transmit synchronisation signal / physical broadcast channel (PBCH) blocks (SSBs) periodically in the cell or cells 9 that it operates. The SSB includes both synchronisation signals (e.g., a primary synchronisation signal (PSS) and a secondary synchronisation signal (SSS)) and the PBCH carrying a MIB that provides at least part of the minimum system information for accessing the corresponding cell 9 (e.g., parameters required for acquiring system information block 1 (SIB1) which carries other minimum system information).

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

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

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

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

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

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

[0040] In the communication system 1, increases in bandwidth, and thereby bitrate can be achieved through carrier aggregation (CA), whereby multiple frequency blocks, i.e., component carriers (CCs), are assigned to the same UE 3 for use. Each CC in turn serves a cell which provides a particular bandwidth and set of services to the UE 3. For example, in CA each UE 3 has a first CC that provides a primary cell (PCell) that carries traffic and RRC signalling messages and 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 as required by the UE 3 and the network.

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

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

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

[0044] 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., periodically scheduled SSBs for SCells and / or 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.

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

[0046] The RAN node 5 may be configured to transmit SSBs associated with SCells periodically in their respective SCells so that the UE 3 may search for those SCell SSBs when scanning for SCells to camp on.

[0047] Alternatively, given that some SCells may not be 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 the UE 3 should utilise one or more SCells. In that scenario, the RAN node 5 may be configured to transmit SSBs associated with SCells on an on-demand basis. For example, each UE 3 may be configured to: -　　expect periodically transmitted on-demand SSB bursts / transmissions from a time instance 'A'; -　　expect periodically transmitted on-demand SSB bursts / transmissions from a time instance 'A' until the RAN node 5 switches off on-demand SSB transmissions; -　　expect on-demand SSB bursts / transmissions transmitted from a time instance 'A' to time instance 'B', wherein the on-demand SSB bursts are not transmitted after time instance 'B'. -　　expect on-demand SSB bursts / transmissions transmitted N times after time instance 'A', wherein the on-demand SSB bursts are not transmitted after N on-demand SSB bursts are transmitted; and / or -　　expect on-demand SSB bursts / transmissions transmitted with a specified first periodicity from time instance 'A' to time instance 'B 'and with a second periodicity after time instance 'B'.

[0048] Beneficially, for such on-demand SSB searching for SSBs associated with SCells (especially, but not exclusively for those SCells that operate in a different frequency band from the PCell), the communication system may implement one or more mechanisms / procedures to allow a UE to request, or a network device to trigger, on-demand SSBs for SCells.

[0049] It will be appreciated that there are several possible mechanisms that may be implemented to allow a UE 3 to request, or a network device to trigger, on-demand SSBs for SCells. On-demand SSBs may, for example, be triggered due to a number of reasons including, for example, SCell activation, SCell synchronisation procedures, including the determination of Rx beams on the SCell, and / or due to a need for SSB-based RRM measurements (e.g., in respect of a particular SCell), and the like. It will also be appreciated that whether on-demand SSBs is initiated by the network (e.g., RAN node 5) or triggered based on a UE request may depend on the specific use case.

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

[0051] In yet another alternative, the RAN node 5 may be configured to perform both periodic SSB transmissions associated with SCells, as well as on-demand SSB transmissions associated with the same SCells. For example, in some scenarios the UE 3 may consider the periodic SSB transmissions associated with the SCells provided by the RAN node 5 sufficient on their own for the UE 3 to accurately determine the timing information associated with the receive (Rx) beams of the SCell. In such a scenario, SCell activation may not be able to be performed, or may fail. Accordingly, the RAN node 5, in addition to providing periodic SSB transmissions associated with its SCells, may also provide multiple further SSB bursts / transmissions to the UE 3 via on-demand SSB transmissions so that the UE 3 is able to accurately determine the timing information associated with the receive (Rx) beams of the SCell.

[0052] It will be appreciated however that in the case where the RAN node 5 supports both periodic SSB transmissions and on-demand SSB transmissions for SCell searching and activation, care needs to be taken to ensure that collisions are avoided between the periodic and on-demand SSB transmissions. For example, collision issues may arise where both the periodic and on-demand SSB transmissions are performed in the same frequency band and / or both the periodic and on-demand SSB transmissions are transmitted close to each other in the time domain.

[0053] There is therefore a need to develop new mechanisms for handling situations where both periodic and on-demand SSB transmissions may be transmitted in the same frequency band and / or close together in time by a RAN node 5.

[0054] On-demand SSBs for SCells 　　Typically, on-demand SSBs are transmitted whenever they are needed by a UE 3 to perform a specific action or measurement e.g., for at least SCell time / frequency synchronization, Layer-1 / Layer-3 measurements and SCell activation. The need for on-demand SSB transmissions can be determined and triggered by either an entity at the network side (e.g., the RAN node 5) or the UE 3-1.

[0055] An example on-demand SSB transmission procedure for SCells will now be described with reference to Figs. 4A and 4B.

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

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

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

[0059] For example, the RAN node 5 may indicate to the UE 3 that transmission of on-demand SSBs for one or more SCells is enabled, and the basis on which SSBs will be transmitted (e.g., based on a network trigger or a request from the UE 3) within an appropriate serving cell configuration message e.g., a configuration message sent to configure the UE 3 to camp onto a serving cell of the RAN node 5, where a serving cell in CA may consist of one PCell and several SCells. The indication may be sent within an SSB configuration of the serving cell e.g., in an SSB configuration in a ServingCellConfigCommon information element (IE) provided in a SIB1 message, or the like. As way of example only, the ServingCellConfigCommon IE may include the following parameters for SSB synchronisation: ssb-PositionsInBurst, ssb-periodicityServingCell, ssbSubcarrierSpacing, ss-PBCH-BlockPower which are described above.

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

[0061] Where the RAN node 5 indicates to the UE 3 that transmission of on-demand SSBs for one or more SCells is enabled within a serving cell configuration, an updated SSB configuration for the on-demand SSBs associated with the current serving cell being used to communicate between the RAN node 5 and the UE 3 may be provided. For example, where the RAN node 5 and UE 3 are configured to communicate using a PCell and several SCells, the SSB configuration for an SCell for which on-demand SSBs are enabled may be updated and / or reconfigured. Nevertheless, the SSB configuration for an SCell for which on-demand SSBs are enabled (or at least part of that SSB configuration) may be the same as for an existing special cell (SpCell) that is effectively a combination of a PCell and a primary secondary cell (PSCell) - or may be the same as for another existing serving cell.

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

[0063] Fig. 4B depicts a simplified sequence diagram illustrating an example procedure for UE-side on-demand SSB transmissions that may be used in the communication system 1 of Fig. 1.

[0064] As shown in Fig. 4B there is provided a RAN node 5 and a UE 3 deployed in the communication system 1 of Fig. 1. Prior to the procedure illustrated in Fig. 4B, the RAN node 5 and UE 3 may first perform the procedure as described above with reference to Fig. 4A.

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

[0066] By way of example only, a requirement for on-demand SSB transmissions may be triggered at the UE 3 based on the UE 3 determining that time synchronisation is required (or that the UE 3 has lost time / frequency synchronisation with an SCell i.e., time / frequency synchronization requirements are not met).

[0067] Having determined time synchronisation is required (or that the UE 3 has lost time / frequency synchronisation with an SCell i.e., time / frequency synchronization requirements are not met), UE 3 may trigger on-demand SSB transmission by sending an on-demand SSB transmission request message (S406) to the RAN node 5.

[0068] At step S408, the RAN node 5 may send an appropriate response message to the UE 3 to confirm that the RAN node 5 received the on-demand SSB request message sent at step S406, and to indicate to the UE 3 that the RAN node 5 will perform the requested on-demand SSB SCell transmissions.

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

[0070] However, it will be appreciated that the example procedure described above for triggering on-demand SSB transmissions for a SCell does not consider the scenario where the RAN node 5 is configured to perform both periodic SSB transmissions associated with SCells, as well as on-demand SSB transmissions associated with the same SCells. Thus without adaptation, the example procedure described above, if implemented within a communication system in which both periodic and on-demand SSB transmissions for the same SCells, may result in SSB transmission collisions, SSB transmission failures, and / or SSB transmission inefficiencies.

[0071] In particular, it will be appreciated that SSB transmission collisions, SSB transmission failures, and / or SSB transmission inefficiencies may occur when the on-demand SSB transmissions for the SCell are transmitted by the RAN node 5 in the same frequency band as the periodic SSB transmission for the SCell and / or both the on-demand SSB transmission and the periodic SSB transmissions occur close together in time (as defined later).

[0072] Additionally, SSB transmission inefficiencies may also occur even when the on-demand SSB transmissions for the SCell are transmitted by the RAN node 5 on a different frequency band as the periodic SSB transmission for the SCell i.e., as the number of SSB transmissions (both periodic and on-demand) may be excessive and inefficient resulting in unnecessary energy losses.

[0073] Summary 　　The communication system 1 is therefore configured to support one or more enhanced SSB transmission procedures / techniques that support the co-existence of periodic and on-demand SSB transmissions for SCell search and activation that reduces SSB transmission collisions and minimises the number of repeated SSB transmissions so that network energy saving (NES) gains are maximised.

[0074] It will be appreciated that in such enhanced SSB transmission procedures / techniques that support the co-existence of periodic and on-demand SSB transmissions, on-demand SSB transmission can be transmitted whenever they are needed e.g., for SCell time / frequency synchronization, L1 / L3 measurements, SCell activation, and the like. In such procedures / techniques the need for on-demand SSB transmissions can be determined and triggered by the UE 3 (or alternatively by the RAN node 5).

[0075] For example, in the case where on-demand SSB transmissions may be transmitted in the same frequency as 'always-on' SSB transmission e.g., periodic SSB transmission associated with a cell and / or even non-cell defining (NCD), it may be beneficial to implement appropriate SSB transmission methods and procedures for handling possible collisions between the on-demand and 'always-on' SSB transmission.

[0076] Moreover, even in the case where on-demand SSB transmissions are transmitted in a different frequency as 'always-on' SSB transmission e.g., periodic SSB transmission associated with a cell and / or even non-cell defining (NCD), it may still be beneficial to implement appropriate SSB transmission methods and procedures to handle possible collisions between the on-demand and 'always-on' SSB transmission, for example, if those transmissions occur close to one another in time.

[0077] Therefore, in one example described in more detail below, the communication system 1 is configured to handle collisions between 'always-on' and on-demand SSB transmissions for SCells in the case where the 'always-on' and on-demand SSB transmissions for SCells are transmitted in the same frequency e.g., where they fall in the same half frame and have different configurations, for example where they have as different position in an SSB burst (e.g., configured by an ssb-PositionsInBurst IE or the like).

[0078] Furthermore, even if the on-demand SSB transmissions can be transmitted on frequency locations which are not used by the 'always-on' SSB, an appropriate dropping rule may be beneficial, e.g., in a case where the transmissions of 'always-on' SSB transmissions and on-demand SSB transmissions are close in time, in order to minimize the number of repeated SSB transmissions, thereby maximising the network energy saving gains.

[0079] Therefore, in one example described in more detail below, the communication system 1 is configured with appropriate dropping rules to allow the RAN node 5 to decide to drop either 'always-on' SSB transmission or on-demand SSB transmissions based on a priority and timing schedule of those respective SSB transmissions.

[0080] In one example described in more detail below, 'always-on' SSB transmissions are dropped by the RAN node 5 when it is determined that the on-demand SSB transmissions are of a higher priority and / or are scheduled to occur within a preconfigured time prior to the scheduled 'always-on' transmissions.

[0081] In another example described in more detail below, on-demand SSB transmissions are dropped by the RAN node 5 when it is determined that the 'always-on' SSB transmissions are of a higher priority and / or are scheduled to occur within a preconfigured time prior to the scheduled on-demand transmissions.

[0082] In yet another example described in more detail below, either 'always-on' or on-demand SSB transmissions are dropped by the RAN node 5 based on which of those two types of SSB transmissions occurs first.

[0083] Despite the above, there may also be a case where the transmission of on-demand SSBs for a SCell is beneficial even if 'always-on' SSB transmission are also scheduled to be close to one another (in time and / or frequency). For example, for SCell activation, the UE 3 may require transmission of multiple SSB bursts to determine the best Rx beam of the SCell. In this case, on-demand SSB bursts may still need to be transmitted for the UE 3 to correctly determine the best Rx beam of the SCell even if the on-demand SSB transmission are very close to the 'always-on' SSB transmissions.

[0084] Therefore, in another example described in more detail below the communication system 1 is configured with appropriate dropping rules to allow the RAN node 5 to decide whether to maintain the transmission of both 'always-on' SSB transmissions and on-demand transmissions despite them being transmitted very close together (in frequency and / or time), or whether to drop either the 'always-on' SSB transmission or the on-demand SSB transmissions based on a priority and timing schedule of those respective SSB transmissions.

[0085] In yet another example described in more detail below the communication system 1 is additionally (or alternatively) configured with appropriate dropping rules to allow the UE 3 to decide whether or not to trigger an on-demand SSB transmission procedure by sending an appropriate request message to the RAN node 5. In one example, when 'always-on' SSB transmissions are already present, the UE 3 may only trigger an on-demand SSB transmission request procedure for special cases such as determining the best Rx beam during SCell activation; otherwise the on-demand SSB transmission request procedure (i.e., the transmission of an on-demand SSB transmission request by the UE 3) may be dropped if the trigger is for the usual 'synchronization', which can be performed using the 'always-on' SSB transmissions.

[0086] In the examples described above, the enabling / disabling of the dropping rules for on-demand SSB transmission may be indicated explicitly in conjunction with an indication to enable on-demand SSB transmission, or alternatively the dropping rules may be supported implicitly by default. For example, the RAN node 5 may provide the frequency location of on-demand SSB transmissions independently of the 'always-on' SSB transmissions.

[0087] In yet another example if the UE 3 is requesting on-demand SSB transmissions, the UE 3 may indicate to the RAN node 5 that on-demand SSB transmissions are required for Rx beam determination. If the RAN node 5 decides that the 'always-on' SSB transmission are sufficient for the UE request (e.g., for Rx beam determination), the RAN node 5 may, nevertheless, drop the requested on-demand SSB transmissions.

[0088] In yet another example, the 'always-on' SSB transmissions may have a higher priority than on-demand SSB transmissions. For example, if there are 'always-on' SSB transmission within a time period 'T' after the time when on-demand SSB transmissions are due, the UE 3 may not be expected to receive a response to a request for on-demand SSB transmissions. Instead, the UE 3 may be expected to monitor the 'always-on' SSB transmissions.

[0089] In yet another example, if the UE 3 knows there is an 'always-on' SSB following a fixed cycle, e.g. within a time period T based on the time when the UE 3 intends to send the on-demand SSB transmissions request, the UE's on-demand SSB transmissions request may be suppressed. In this case, the UE 3 may not send the on-demand SSB transmissions request but may instead wait for the reception of 'always-on' SSB transmissions following the fixed cycle for the 'always-on' transmissions.

[0090] It will be appreciated that in the enhanced SSB transmission procedures / techniques that support the co-existence of periodic and on-demand SSB transmissions summarised above, where there are multiple UEs 3 present, each transmitting their own on-demand SSB transmissions request to the RAN node 5, methods and procedures may also be appropriate to handle possible collisions between those requests and the timing / transmission of the on-demand and 'always-on' SSB transmission that follow.

[0091] Therefore, in another example the following handling rules for multiple UEs' on-demand SSB requests may, beneficially, be implemented: 　　Allow only one SSB transmission every time 'T', where 'T' may be equal to a legacy SSB transmission periodicity. Where there are more than one on-demand SSB transmissions due within time 'T', the UE 3 is expected to receive only one SSB transmission by the end of 'T'.

[0092] If there is already an on-demand SSB transmission due within a time 'T' prior to a newly requested on-demand SSB transmission, the RAN node 5 may delay the newly requested on-demand SSB transmission to a time 'T' after the already due on-demand SSB transmission. The UE 3 may be expected to monitor for the on-demand SSB transmission for at least a duration 'T'. If there is an 'always-on' SSB transmission or another newly requested on-demand SSB to be transmitted close by, the delayed on-demand SSB transmission may be dropped.

[0093] Each of the enhanced SSB transmission procedures / techniques outlined above will now be discussed in more detail with reference to Figs. 5 to 9.

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

[0095] Enhanced SCell SSB Transmission Procedures / Techniques 　　There now follows a detailed description of new enhanced SCell SSB transmission procedures and / or techniques that may be implemented to achieve NES enhancements and SSB transmission efficiencies. The following description is divided into two sections; a first section which describes the procedures used by athe UE 3 to request on-demand SSB transmissions, and a second section which describes the subsequent procedure used by the UE 3 and / or the RAN node 5 for deciding how to handle the scenario where the on-demand SSBs and periodic SSBs over the SCell are transmitted close together in time.

[0096] It will be appreciated that, while the transmission procedures described below are described with specific reference to the transmission of SSBs for SCells specifically, the procedures may, where appropriate, be adapted for avoiding collisions between on-demand transmissions of SIB1 and 'always-on' transmissions of SIB1.

[0097] Single on-demand SSB request 　　Fig. 5 illustrates a simplified sequence diagram illustrating a procedure for requesting on-demand SSB transmissions that may be used in the communication system 1 of Fig. 1. As shown in Fig. 5 there is provided a RAN node 5 and a UE 3 (or a plurality of UEs 3) deployed in the communication system 1 of Fig. 1.

[0098] For the purposes of simplicity, the following description will refer to the procedure between the RAN node 5 and the single UE 3. Nevertheless, it will be appreciated that a plurality of UEs 3 may each request on-demand SSBs for a SCell or SCells respectively, and that the procedure described below may be adapted accordingly.

[0099] At step S502, the RAN node 5 may send an appropriate message to the UE 3 to configure a PCell and one or more SCells for the UE 3 to allow it to communicate with the RAN node 5 over those cells. For example, the RAN node 5 may send an RRC (re)configuration message, an SCell configuration message, or the like, to the UE 3 to (re)configure the SCells provided for the UE 3 e.g., add and / or release one or more SCells for the UE 3.

[0100] Additionally, the RRC (re)configuration message, SCell configuration message, or the like, may also include appropriate information pertaining to SCells that may be added for use by the UE 3 to assist in the use of the SCells by the UE 3. For example, the RRC (re)configuration message, an SCell configuration message, or the like, may include an indication of whether or not periodic SSB transmissions will be sent by the RAN node 5 for the SCell i.e., whether periodic SSB transmissions for the SCell are 'always on'. In this scenario, the RRC (re)configuration message, SCell configuration message, or the like, may include an indication of a periodicity for those periodic 'always on' SSB transmissions.

[0101] Alternatively, an indication of whether or not periodic SSB transmissions will be sent by the RAN node 5 for the SCell, and the periodicity those periodic SSB transmissions may be signalled to the UE 3 via another appropriate message (e.g., an SSB configuration message, or the like) sent by the RAN node 5 over the PCell as described in more detail below.

[0102] At step S504, the RAN node 5 sends an indication to the UE 3 indicating whether on-demand SSB transmissions for one or more SCells is enabled in an appropriate message over the configured PCell (e.g., an SSB configuration message for the one or more SCells). Specifically, for each SCell, the RAN node 5 may indicate whether SSBs are to be transmitted: i) on-demand based on a network trigger (i.e., a trigger at the RAN node 5), and / or ii) on-demand based on the RAN node 5 receiving requests for on-demand SSBs from the UE 3.

[0103] Additionally, for each SCell, the RAN node 5 may indicate whether SSBs are also to be transmitted periodically; that is to say, whether periodic SSBs for the SCell are 'always on'. In this case the appropriate message (e.g., an SSB configuration message for the one or more SCells) may also include an indication of a periodicity for those periodic 'always on' SSB transmissions in conjunction with the indication as to whether on-demand SSBs are to be transmitted i) on-demand based on a network trigger (i.e., a trigger at the RAN node 5), and / or ii) on-demand based on the RAN node 5 receiving requests for on-demand SSBs from the UE 3.

[0104] For the purposes of simplicity only, in the subsequent description of Fig 5 it will be assumed that for each SCell, the RAN node 5 indicates whether SSBs are to be transmitted on-demand based on the RAN node 5 receiving requests for on-demand SSBs from the UE 3. Nevertheless, it will be appreciated that the procedure described below may be easily adapted for the scenario where, for each SCell, the RAN node 5 indicates whether SSBs are to be transmitted on-demand based on a network trigger (i.e., a trigger at the RAN node 5).

[0105] At step S504, additionally, for each SCell, the RAN node 5 may indicate that, where both periodic SSB transmissions for the SCell are 'always on' and on-demand SSB transmissions are enabled (i.e., the RAN node 5 may transmit both types of SSBs for the SCell), the periodic or on-demand SSBs may (or may not) be transmitted to the UE 3 unless a (pre)configured priority and / or timing criteria associated with on-demand and / or periodic SSB transmissions for the SCell are met.

[0106] Alternatively, rather than explicitly indicating that the periodic or on-demand SSBs may (or may not) be transmitted to the UE 3 unless a (pre)configured (or hardcoded) priority and / or timing criteria associated with on-demand and / or periodic SSB transmissions for the SCell are met, the UE 3 may be configured (or hardcoded) to know implicitly that when on-demand SSBs are enabled and periodic SSBs are 'always on', the periodic or on-demand SSBs may (or may not) be transmitted to the UE 3 unless a (pre)configured priority and / or timing criteria associated with on-demand and / or periodic SSB transmissions for the SCell are met.

[0107] Three examples of such (pre)configured (or hardcoded) priority and / or timing criteria, and the corresponding decisions / indications as to whether the periodic and / or on-demand SSBs are (or are not) be transmitted to the UE 3 will now be described.

[0108] Option A: 　　In one example, the RAN node 5 may indicate that, for a respective SCell, on-demand SSBs will not be transmitted to the UE 3 following the RAN node 5 receiving a request for on-demand SSBs from the UE 3 if the periodic SSB transmissions for the respective SCell are of a higher priority than the on-demand SSB transmissions. By way of example only, periodic SSB transmissions required for 'RRM measurement' or for fulfilling the usual 'synchronization' requirements may be assigned a higher priority than on-demand SSB transmissions for such RRM measurement' or for fulfilling the usual 'synchronization' requirements. In this scenario, the RAN node 5 may ignore / skip an on-demand SSB transmission request sent by the UE 3, and the UE 3 may only receive periodic SSB transmissions for the SCell.

[0109] In another example, periodic SSB transmissions for the SCell may be considered to have a higher priority than on-demand SSB transmissions for the SCell if the periodic SSB transmissions are scheduled to occur within a minimum time period T after the time instance when on-demand SSB transmissions are scheduled. In this instance, the UE 3 knows that there is a periodic SSB transmission due in accordance with a fixed cycle e.g. within a time period T based on the time when the UE 3 intends to send the on-demand SSB request. In this scenario the UE 3 is instead expected to monitor for periodic SSB transmissions only. By way of example only, the minimum time period T may be set to 0ms, 2ms, 5ms, 10ms or 20ms. Alternatively, the value of the minimum time period T may be defined in unit of slots.

[0110] Option B: 　　In another example, the RAN node 5 may indicate that, for a respective SCell, on-demand SSBs transmissions and periodic SSBs transmissions have the same priority, and that either periodic or on-demand SSB transmissions may be sent by the RAN node 5, and that based on which of the periodic or on-demand is sent first, the other type of SSB transmissions will be dropped. In this scenario, on-demand SSBs transmissions will not be transmitted to the UE 3 following the RAN node 5 receiving a request for on-demand SSBs from the UE 3, if the RAN node 5 transmits the periodic SSB transmissions within a minimum time period T prior to when the RAN node 5 was due to transmit the on-demand SSB transmissions. By way of example only, the minimum time period T may be set to 0ms, 2ms, 5ms, 10ms or 20ms. Alternatively, the value of the minimum time period T may be defined in unit of slots.

[0111] Similarly, the RAN node 5 may indicate that, for a respective SCell, periodic SSBs transmissions will not be transmitted to the UE 3 following the RAN node 5 receiving a request for on-demand SSBs from the UE 3 if the RAN node 5 transmits the on-demand SSB transmissions within a minimum time period T prior to when the RAN node 5 was due to transmit the periodic SSB transmissions. In this scenario, the UE 3 may be expected to start monitoring for the on-demand SSB transmissions within a time period T prior to the time when periodic SSB transmission are due. By way of example only, the minimum time period T may be set to 0ms, 2ms, 5ms, 10ms or 20ms. Alternatively, the value of the minimum time period T may be defined in unit of slots.

[0112] Option C: 　　In another example, the RAN node 5 may indicate that, for a respective SCell, on-demand SSBs will be transmitted to the UE 3, and periodic SSB transmission will be dropped following the RAN node 5 receiving a request for on-demand SSBs from the UE 3, if the periodic SSB transmissions for the respective SCell are of lower priority than the on-demand SSBs. In this scenario, periodic SSB transmissions are considered to be of lower priority when the periodic SSB transmissions are due within a minimum time period T prior to the time when on-demand SSB transmissions are due. In this scenario, the UE 3 is not expected to receive periodic SSB transmissions. However, if the periodic SSB transmissions are not received (i.e., dropped), the UE 3 is expected to continue / resume monitoring for periodic SSB transmissions at a time TReset after the time when periodic SSB transmissions were due to be transmitted. By way of example only, the minimum time period T may be set to 0ms, 2ms, 5ms, 10ms or 20ms. Alternatively, the value of the minimum time period T may be defined in unit of slots.

[0113] It will be appreciated that the indications described above with reference to step S504 may be made by the RAN node 5 within an appropriate serving cell configuration message e.g., a configuration message sent to configure the UE 3 to camp onto a serving cell of the RAN node 5, where a serving cell in CA may consist of one PCell and several SCells. The indication may be sent within an SSB configuration of the serving cell e.g., in an SSB configuration in a ServingCellConfigCommon IE provided in a SIB1 message, or the like.

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

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

[0116] The UE 3, at step S510 may decide to trigger an on-demand SSB transmission request procedure (although it will be appreciated that the on-demand SSB transmission request procedure may be triggered at the UE 3 by the RAN node 5). For example, the UE 3 may decide to request on-demand SSB transmissions for one or more SCells indicated an SCell activation command for which an on-demand SSB configuration is provided. Part of that SSB transmission request procedure may include, at step S512, transmitting an appropriate request message to the RAN node 5 to request on-demand SSB transmissions for the SCell (e.g., an on-demand SSB transmissions request message).

[0117] For example, the SCell on-demand SSB transmissions request message may comprise an indication indicating the UE's 3 need for SCell on-demand SSB transmissions for Rx beam determination purposes. That indication, by way of example only, may be sent in UCI sent to the RAN node 5.

[0118] At step S514, the RAN node 5, having received the on-demand SSB transmission request, may (optionally) transmit an appropriate response message to the UE 3 to confirm that the RAN node 5 has received the UE's 3 on-demand SSB transmissions request message.

[0119] In one example, that appropriate response message may include an appropriate indication that the RAN node 5 has received the UE's 3 on-demand SSB transmissions request message, and that in response to that request message, the RAN node 5 will trigger the transmission of on-demand SSBs for the SCell. Furthermore, where the appropriate response message includes an appropriate indication that the RAN node 5 has received the UE's 3 on-demand SSB transmissions request message, and that in response to that request message, the RAN node 5 will trigger the transmission of on-demand SSBs for the SCell, the appropriate response message may also include other appropriate information pertaining to the on-demand SSB transmissions e.g., the frequency location to be used for the on-demand SSB transmissions which may be independent of periodic SSB transmissions that may occur over the SCell.

[0120] Alternatively, having sent the on-demand SSB transmission request message to the RAN node 5 at step S512, if the RAN node 5 decides that the periodic SSB transmissions for the SCell that are due to occur are sufficient to meet the needs of the UE 3 for on-demand SSB transmissions indicated in the on-demand SSB transmissions request message (e.g., on-demand SSB transmissions for Rx beam determination, RRM measurements, and the like), the RAN node 5 may reject the request for on-demand SSB transmissions and indicate to the UE 3, in the response message, to use periodic SSB transmissions for the SCell. It will be appreciated that rather than the RAN node 5 rejecting the request for on-demand SSB transmissions and explicitly indicating that rejection to the UE 3 within the response message, the UE 3 may alternatively be configured to implicitly conclude that its request for on-demand SSB transmissions has been rejected if it does not receive a response message from the RAN node 5.

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

[0122] At step S516, the UE 3 determines whether to monitor for the on-demand SSB transmissions that the UE 3 expects the RAN node 5 to transmit. For example, at step S516, the UE 3 may determine that it is to monitor for on-demand SSB transmissions only, periodic SSB transmissions only, or both on-demand and periodic SSB transmissions. The determination of the UE 3 as to whether to monitor for the on-demand SSB transmissions that the UE 3 expects the RAN node 5 to transmit and the subsequent procedure will now be described in more detail with reference to Figs. 6A to 6C.

[0123] Fig. 6A illustrates a simplified sequence diagram illustrating a continuation (option A) of the procedure for requesting on-demand SSB transmissions of Fig. 5.

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

[0125] At step S516a, having transmitted the on-demand SSB transmission request message to the RAN node 5 at step S512 (and optionally having received an appropriate response message at step S514), the UE 3 determines not to monitor for on-demand SSB transmissions.

[0126] For example, having transmitted the on-demand SSB transmission request message to the RAN node 5 at step S512, the UE 3 may determine not to monitor for on-demand SSB transmissions based on the absence of an appropriate response message at step S514. Alternatively, having transmitted the on-demand SSB transmission request message to the RAN node 5 at step S512, the UE 3 may determine not to monitor for on-demand SSB transmissions based on an appropriate response message received at step S514 to indicate that the requested on-demand SSBs will not be transmitted to the UE 3 because the periodic SSB transmissions for the respective SCell or SCells are of higher priority than the on-demand SSB transmissions as described above with reference to Option A.

[0127] In another example, having transmitted the on-demand SSB transmission request message to the RAN node 5 at step S512, the UE 3 may determine not to monitor for on-demand SSB transmissions because periodic SSB transmissions for the SCell may be considered to have a higher priority than on-demand SSB transmissions for the SCell if the periodic SSB transmissions are scheduled to occur within a minimum time period T after the time instance when on-demand SSB transmissions are scheduled. In this instance, the UE 3 knows that there is a periodic SSB transmission due in accordance with a fixed cycle e.g. within a time period T based on the time when the UE 3 intends to send the on-demand SSB request. In this scenario the UE 3 is instead expected to monitor for periodic SSB transmissions only. By way of example only, the minimum time period T may be set to 0ms, 2ms, 5ms, 10ms or 20ms. Alternatively, the value of the minimum time period T may be defined in unit of slots.

[0128] At step S518a, the RAN node 5, having received the on-demand SSB transmission request message from the UE 3, decides to ignore the received the on-demand SSB transmission request message because the periodic SSB transmissions for the respective SCell are of higher priority than the requested on-demand SSB transmissions as described above. In this scenario, the on-demand SSB transmissions are not scheduled.

[0129] At step S520a, the RAN node 5 transmits only periodic SSB transmissions for the SCell to the UE 3, the RAN node 5 having decided to drop / not transmit the requested on-demand SSB transmissions. In response to receiving those periodic SSB transmissions, the UE 3 may optionally send (not shown) appropriate feedback messages (e.g., HARQ ACK / NACK messages) to the RAN node 5 to confirm successful reception of the periodic SSB transmissions.

[0130] Fig. 6B illustrates a simplified sequence diagram illustrating a continuation (option B) of the procedure for requesting on-demand SSB transmissions of Fig. 5.

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

[0132] At step S516b, having transmitted the on-demand SSB transmission request message to the RAN node 5 at step S512 (and optionally having received an appropriate response message at step S514), the UE 3 determines to monitor for on-demand SSB transmissions.

[0133] For example, having transmitted the on-demand SSB transmission request message to the RAN node 5 at step S512, the UE 3 may determine to monitor for on-demand SSB transmissions based on periodic SSB transmissions and on-demand SSB transmissions for the SCell having the same priority as described above with reference to Option B.

[0134] At step S518b, the RAN node 5, having received the on-demand SSB transmission request message from the UE 3, may decide to trigger on-demand SSB transmissions for the SCell as requested in the on-demand SSB transmission request message sent to the RAN node 5 at step S512. For example, having received the on-demand SSB transmission request message from the UE 3, the RAN node 5 may decide to trigger on-demand SSB transmissions for the SCell based on both periodic SSB transmission and on-demand SSB transmissions for the SCell having the same priority as described above with reference to Option B.

[0135] For example, at step S518b, the RAN node 5 may decide to send either periodic or on-demand SSB transmissions to the UE 3. Then, based on which of the periodic or on-demand is sent first, the other type of SSB transmissions are dropped.

[0136] Accordingly, in this scenario, on-demand SSBs transmissions will not be transmitted to the UE 3 following the RAN node 5 receiving a request for on-demand SSBs from the UE 3, if the RAN node 5 transmits the periodic SSB transmissions within a minimum time period T prior to when the RAN node 5 was due to transmit the on-demand SSB transmissions. By way of example only, the minimum time period T may be set to 0ms, 2ms, 5ms, 10ms or 20ms. Alternatively, the value of the minimum time period T may be defined in unit of slots.

[0137] In a same vein, periodic SSBs transmissions will not be transmitted to the UE 3 following the RAN node 5 receiving a request for on-demand SSBs from the UE 3 if the RAN node 5 transmits the on-demand SSB transmissions within a minimum time period T prior to when the RAN node 5 was due to transmit the periodic SSB transmissions. In this scenario, the UE 3 may be expected to start monitoring for the on-demand SSB transmissions within a time period T prior to the time when periodic SSB transmission are due. By way of example only, the minimum time period T may be set to 0ms, 2ms, 5ms, 10ms or 20ms. Alternatively, the value of the minimum time period T may be defined in unit of slots.

[0138] Additionally (or alternatively), at step S518b, having received the on-demand SSB transmission request message from the UE 3, if on-demand SSB transmissions are due to be transmitted within a time period T prior to a time when periodic SSB transmissions for the SCell are due to be transmitted, the RAN node 5 may decide to drop the instance of periodic SSB transmissions immediately after the on-demand SSB transmissions. In this case, the UE 3 may be expected to start monitoring for the on-demand SSB transmission within a minimum time period T prior to the time when periodic SSB transmissions are due. By way of example only, the minimum time period T may be set to 0ms, 2ms, 5ms, 10ms or 20ms. Alternatively, the value of the minimum time period T may be defined in unit of slots.

[0139] At step S520b, the RAN node 5 transmits either periodic SSB transmissions or on-demand SSB transmissions, whichever is scheduled to come first. Alternatively, if at step S518b the RAN node decided to drop the periodic SSB transmission, then at step S520b, the RAN node 5 transmits an on-demand SSB transmission for the SCell.

[0140] Fig. 6C illustrates a simplified sequence diagram illustrating a continuation (option C) of the procedure for requesting on-demand SSB transmissions of Fig. 5.

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

[0142] At step S516c, having transmitted the on-demand SSB transmission request message to the RAN node 5 at step S512 (and optionally having received an appropriate response message at step S514), the UE 3 determines to monitor for on-demand SSB transmissions only.

[0143] For example, having transmitted the on-demand SSB transmission request message to the RAN node 5 at step S512, the UE 3 may determine to monitor for on-demand SSB transmissions based on periodic SSB transmissions having a lower priority than on-demand SSB transmissions for the SCell as described above with reference to Option C.

[0144] At step S518c, the RAN node 5, having received the on-demand SSB transmission request message from the UE 3, may decide to trigger on-demand SSB transmissions for the SCell or SCells as requested in the on-demand SSB transmission request message sent to the RAN node 5 at step S512. For example, having received the on-demand SSB transmission request message from the UE 3, the RAN node 5 may decide to trigger on-demand SSB transmissions for the SCell or SCells based on periodic SSB transmissions having a lower priority than on-demand SSB transmissions for the SCell or SCells as described above with reference to Option C.

[0145] For example, at step S518c, the RAN node 5 may decide to trigger on-demand SSB transmission only when the periodic SSB transmissions are due within a minimum time period T prior to the time when on-demand SSB transmissions are due. By way of example only, the minimum time period T may be set to 0ms, 2ms, 5ms, 10ms or 20ms. Alternatively, the value of the minimum time period T may be defined in unit of slots.

[0146] In this scenario, the UE 3 is not expected to receive periodic SSB transmissions. However, if the periodic SSB transmissions are not received (i.e., because they are dropped), the UE 3 is expected to continue / resume monitoring for periodic SSB transmissions at a time TReset after the time when periodic SSB transmissions were due to be transmitted.

[0147] At step S520c, the RAN node 5 transmits on-demand SSB transmissions for the SCell to the UE 3 only and drops the periodic SSB transmissions that were due to occur. Multiple on-demand SSB requests

[0148] The above-described procedure with reference to Figs. 5 and 6 relates to the scenario where a single UE 3 sends an appropriate on-demand SSB request message to the RAN node 5 to request that it receives on-demand SSBs for a SCell.

[0149] Nevertheless, it will be appreciated that in certain scenarios multiple UEs 3 may wish to access the SCell or SCells provided by the RAN node 5, and thus multiple UEs 3 may each send an appropriate on-demand SSB request messages to the RAN node 5 respectively to request that the UE 3 receives on-demand SSBs for a SCell. In such a scenario however, it will be appreciated that the multiple on-demand SSB request messages sent by the corresponding multiple UEs 3 may be transmitted to the RAN node 5 close to each other in time. For example, the multiple on-demand SSB request messages may be considered to be transmitted close together in time if two or more on-demand SSB request messages are sent to the RAN node 5 within a minimum time period TOn-Demand. By way of example only, TON-DEMAND may be configured by the network, and may be equal to one or more or a fraction of a legacy SSB transmission periodicity.

[0150] In the scenario where the multiple on-demand SSB request messages sent by the corresponding multiple UEs 3 are transmitted to the RAN node 5 close to each other in time, the RAN node 5 may be configured to implement one or more mechanisms or procedures for determining which on-demand SSB transmissions to send. For example, where multiple sets of different on-demand SSB transmissions have been requested, one set for each UE 3 that has requested on-demand SSB transmissions, the RAN node 5 may be configured to decide whether to send some or all of the requested on-demand SSB transmissions, and also which order the requested on-demand SSB transmissions should be transmitted.

[0151] The procedure of Figs. 5 and 6 therefore may be appropriately adapted to take account of the reception of multiple on-demand SSB transmissions by the RAN node 5 from multiple different UE 3.

[0152] An example of an adapted procedure that takes take account of the reception of multiple on-demand SSB transmissions by the RAN node 5 from multiple different UE 3 will now be described with reference to Figs 7A & 7B.

[0153] In this example, a minimum time interval TON-DEMAND is configured between multiple on-demand SSB bursts transmissions, e.g. 0ms, 2ms, 5ms, 10ms or 20ms (although TON-DEMAND may also be configured in units of slots) and an associated appropriate on-demand demand (or periodic) SSB dropping rule is defined. For example, only SSB burst, or a defined number of SSB bursts, may be allowed within the TON-DEMAND period. TON-DEMAND may be configured by the RAN node 5, and may be equal to one, or more, or a fraction of a legacy SSB transmission periodicity.

[0154] Fig. 7A illustrates a simplified sequence diagram illustrating a continuation (option B) of the procedure for requesting on-demand SSB transmissions of Fig. 5. Prior to the procedure illustrated in Fig. 7A, the RAN node 5 and UE 3 first perform the procedures as described above with reference to Fig. 5 and adapted for a plurality of UEs 3.

[0155] As shown in Fig. 7A, there is provided a RAN node 5 and a plurality of UEs 3 deployed in the communication system 1 of Fig. 1.

[0156] At step S716b, having transmitted their respective on-demand SSB transmission request message to the RAN node 5 at step S512 (and optionally having received an appropriate response message at step S514), each UE 3 determines to monitor for on-demand SSB transmissions.

[0157] For example, having transmitted the on-demand SCell transmission request message to the RAN node 5 at step S512, each UE 3 may determine to monitor for on-demand SSB transmissions based on periodic SSB transmissions and on-demand SSB transmissions for the SCell or SCells having the same priority as described above with reference to Option B.

[0158] At step S718b, the RAN node 5, having received a first on-demand SSB transmission request message from a first UE 3, may decide to trigger one or more on-demand SSB transmissions for an SCell as requested in the first on-demand SSB transmission request message sent to the RAN node 5 at step S512.

[0159] For example, having received the first on-demand SSB transmission request message from the first UE 3 of the plurality of UEs 3, the RAN node 5 may decide to trigger on-demand SSB transmission for an SCell for the first UE 3, providing that there are no on-demand SSB transmissions for an SCell already scheduled for another one of the plurality of UEs 3 within the TON-DEMAND time period after receipt of the first on-demand SSB transmission request message from the first UE 3 (for example as a result of one or more earlier or simultaneous on-demand SSB requests from one or more other UEs 3).

[0160] However, if there is one or more on-demand SSB bursts already scheduled (e.g., for another one or more UEs 3) within the TON-DEMAND time period, the UE 3 is expected to receive only one SSB bursts by the end of the TON-DEMAND period. The UE 3 is, nevertheless, configured to monitor for the on-demand SSB for at least the TON-DEMAND period.

[0161] Moreover, in the case where there is one or more on-demand SSB bursts already scheduled, the RAN node 5 may decide not to trigger an on-demand SSB transmission for the first UE 3 immediately. Instead, the RAN node 5 may delay the transmission of the requested on-demand SSB for the first UE 3 until expiry of the TON-DEMAND time period after the already scheduled on-demand SSB is transmitted. In this scenario, the first UE 3 may be configured to continue to monitor for the requested on-demand SSB transmissions for at least the TON-DEMAND duration after an expected response time.

[0162] If there are one or more on-demand SSBs to be transmitted within the TON-DEMAND period, after a another 'earlier' on-demand SSB is to be transmitted, the RAN node 5 may delay transmission of the earlier on-demand SSB until the time at which the latest scheduled SSB transmission is due to take place (i.e., the UE 3 is not expected to receive the corresponding on-demand SSB transmission until the latest on-demand SSB transmission (no later than TON-DEMAND) is due). Instead, the UE 3 is expected to continue monitoring for the SSB transmission for the TON-DEMAND time period after the requested on-demand SSB transmission is due (or until receipt of the SSB transmission, in which case the TON-DEMAND timer is cancelled).

[0163] It will be appreciated that similar on-demand / periodic SSB dropping rules to those discussed with reference to Fig. 6B may also be applied where appropriate.

[0164] For example, at step S718b, having received the first on-demand SSB transmission request message from the first UE 3, if on-demand SSB transmissions are due to be transmitted within a time period T prior to a time when periodic SSB transmissions for the SCell or SCells are due to be transmitted, the RAN node 5 may decide to drop the instance of periodic SSB transmissions immediately after the on-demand SSB transmissions. In this case, the first UE 3 may be expected to start monitoring for the on-demand SSB transmissions within a minimum time period T prior to the time when periodic SSB transmissions are due. By way of example only, the minimum time period T may be set to 0ms, 2ms, 5ms, 10ms or 20ms. Alternatively, the value of the minimum time period T may be defined in unit of slots.

[0165] At step S720b, the RAN node 5 transmits either periodic SSB transmissions or on-demand SSB transmissions, whichever is scheduled to come first. Alternatively, if at step S718b the RAN node 5 decided to drop the periodic SSB transmissions, then at step S720b, the RAN node 5 transmits on-demand SSB transmissions for the SCell or SCells only.

[0166] It will be appreciated that, at step S720b, having transmitted on-demand SSB transmissions for the SCell or SCells first (e.g., if on-demand SSB transmissions have been transmitted within a time period T prior to a time when periodic SSB transmissions for the SCell or SCells are due to be transmitted), the RAN node 5 may decide to drop the instance of periodic SSB transmissions immediately after the on-demand SSB transmissions. In this case, the first UE 3 may be expected to start monitoring for the on-demand SSB transmissions within a minimum time period T prior to the time when periodic SSB transmissions are due. By way of example only, the minimum time period T may be set to 0ms, 2ms, 5ms, 10ms or 20ms. Alternatively, the value of the minimum time period T may be defined in unit of slots.

[0167] In response to receiving those periodic / on-demand SSB transmissions, the first UE 3 may optionally send (not shown) appropriate feedback messages (e.g., HARQ ACK / NACK messages) to the RAN node 5 to confirm successful reception of the periodic / on-demand SSB transmissions.

[0168] Fig. 7B illustrates a simplified sequence diagram illustrating a continuation (option C) of the procedure for requesting on-demand SSB transmissions of Fig. 5. Prior to the procedure illustrated in Fig. 7B, the RAN node 5 and UE 3 first perform the procedures as described above with reference to Fig. 5 and adapted for a plurality of UEs 3.

[0169] As shown in Fig. 7B there is provided a RAN node 5 and a plurality of UEs 3 deployed in the communication system 1 of Fig. 1.

[0170] At step S716c, having transmitted their respective on-demand SSB transmission request message to the RAN node 5 at step S512 (and optionally having received an appropriate response message at step S514), each UE 3 determines to monitor for on-demand SSB transmissions.

[0171] For example, having transmitted the on-demand SCell transmission request message to the RAN node 5 at step S512, each UE 3 may determine to monitor for on-demand SSB transmissions based on periodic SSB transmissions and on-demand SSB transmissions for the SCell or SCells having the same priority as described above with reference to Option C.

[0172] At step S718c, the RAN node 5, having received a first on-demand SSB transmission request message from a first UE 3, may decide to trigger one or more on-demand SSB transmissions for an SCell as requested in the first on-demand SSB transmission request message sent to the RAN node 5 at step S512.

[0173] For example, having received the first on-demand SSB transmission request message from the first UE 3 of the plurality of UEs 3, the RAN node 5 may decide to trigger on-demand SSB transmission for an SCell for the first UE 3, providing that there are no on-demand SSB transmissions for an SCell already scheduled for another one of the plurality of UEs 3 within the TON-DEMAND time period after receipt of the first on-demand SSB transmission request message from the first UE 3 (for example as a result of one or more earlier or simultaneous on-demand SSB requests from one or more other UEs 3).

[0174] However, if there is one or more on-demand SSB bursts already scheduled (e.g., for another one or more UEs 3) within the TON-DEMAND time period, the UE 3 is expected to receive only one SSB bursts by the end of the TON-DEMAND period. The UE 3 is, nevertheless, configured to monitor for the on-demand SSB for at least the TON-DEMAND period.

[0175] Moreover, in the case where there is one or more on-demand SSB bursts already scheduled, the RAN node 5 may decide not to trigger an on-demand SSB transmission for the first UE 3 immediately. Instead, the RAN node 5 may delay the transmission of the requested on-demand SSB for the first UE 3 until expiry of the TON-DEMAND time period after the already scheduled on-demand SSB is transmitted. In this scenario, the first UE 3 may be configured to continue to monitor for the requested on-demand SSB transmissions for at least the TON-DEMAND duration after an expected response time.

[0176] If there are one or more on-demand SSBs to be transmitted within the TON-DEMAND period, after a another 'earlier' on-demand SSB is to be transmitted, the RAN node 5 may delay transmission of the earlier on-demand SSB until the time at which the latest scheduled SSB transmission is due to take place (i.e., the UE 3 is not expected to receive the corresponding on-demand SSB transmission until the latest on-demand SSB transmission (no later than TON-DEMAND) is due). Instead, the UE 3 is expected to continue monitoring for the SSB transmission for the TON-DEMAND time period after the requested on-demand SSB transmission is due (or until receipt of the SSB transmission, in which case the TON-DEMAND timer is cancelled).

[0177] It will be appreciated that similar on-demand / periodic SSB dropping rules to those discussed with reference to Fig. 6C may also be applied where appropriate.

[0178] For example, at step S718c, having received the on-demand SSB transmission request message from the UE 3, if periodic SSB transmissions are due to be transmitted within a time period T prior to a time when on-demand SSB transmissions for the SCell or SCells are due to be transmitted, the RAN node 5 may decide to drop the transmission of the periodic SSB transmissions. In this case, UE 3 may be expected to start monitoring for the periodic SSB bursts / transmissions again within a minimum time period T after to the time when periodic SSB transmissions was due if said periodic SSB transmissions did not occur. By way of example only, the minimum time period T may be set to 0ms, 2ms, 5ms, 10ms or 20ms. Alternatively, the value of the minimum time period T may be defined in unit of slots.

[0179] At step S720c, the RAN node 5 transmits on-demand SSB transmissions for the SCell to the UE 3 (i.e., subject to any TON-DEMAND time period based restrictions arising from multiple on-demand SSB requests as described above) and drops the periodic SSB transmissions that were due to occur.

[0180] In response to receiving those on-demand SSB transmissions, the first UE 3 may optionally send (not shown) appropriate feedback messages (e.g., HARQ ACK / NACK messages) to the RAN node 5 to confirm successful reception of the on-demand SSB transmissions.

[0181] Enhanced SIB1 Transmission Procedures / Techniques 　　As mentioned above, while the transmission procedures described above with reference to Figs. 5 to 7 related to transmission of SSBs for SCells, those procedures may, where appropriate, be adapted for avoiding collisions between on-demand transmissions of SIB1 and 'always-on' transmissions of SIB1. Possible adaptations of the procedures will now be described in more detail by way of example only.

[0182] For example, in the scenario where the transmission procedures described above with reference to Figs. 5 to 7 are adapted for SIB1 transmissions, the minimum time duration T is a minimum time period T between the time when on-demand SIB1 transmissions are due to be transmitted and the time when periodic SIB1 transmission are due to be transmitted may, by way of example only, similarly be set to 0ms, 2ms, 5ms, 10ms or 20ms. Alternatively, in some scenarios, the minimum time duration T is a minimum time period T between the time when on-demand SIB1 transmissions are due to be transmitted and the time when periodic SIB1 transmission are due to be transmitted may be set to different values to those used for SSB transmissions-based procedure. For example, there may be a dedicated TSIB1 value that is different from T described above, which in this scenario may be referred to as TSSB.

[0183] Furthermore, it will be appreciated in the scenario where the transmission procedures described above with reference to Figs. 5 to 7, are adapted for SIB1 transmissions, TON-DEMAND may not be of the same values for on-demand SSB transmissions and on-demand SIB1 transmissions. Furthermore TON-DEMAND may not be of the same values for on-demand SSB / SIB1 transmissions and periodic SSB / SIB1.

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

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

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

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

[0188] It will be appreciated that the communication control module 43 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 43 may include a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an RRC sub-module, etc.

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

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

[0191] 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. As shown, these software instructions include, among other things, an operating system 61, and a communication control module 63.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0216]

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

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

[0219] This application is based upon and claims the benefit of priority from British patent application No. 2404932.2, filed on April 5, 2024, the disclosure of which is incorporated herein in its entirety by reference.

[0220] The whole or part of the exemplary embodiments disclosed above can be described as, but not limited to, the following supplementary notes. (Supplementary note 1) 　　A method performed by a mobile device, the method comprising: 　　in a case where difference between a timing of on-demand synchronizing signal / physical broadcast channel (PBCH) block (SSB) / system information block 1 (SIB1) transmission and a timing of another SSB / SIB1 transmission is equal to or less than a threshold value, dropping or delaying either the on-demand SSB / SIB1 transmission or the another SSB / SIB1 transmission. (Supplementary note 2) 　　The method according to supplementary note 1, further comprising: 　　continuing to monitor SSB / SIB1 transmission of the one that did not drop or delay. (Supplementary note 3) 　　The method according to supplementary note 1 or 2, wherein 　　the dropping or delaying is performed on SSB / SIB1 transmission with the lower priority than the other. (Supplementary note 4) 　　The method according to supplementary note 1 or 2, wherein 　　the dropping or delaying is performed on later SSB / SIB1 transmission than the other. (Supplementary note 5) 　　The method according to any one of supplementary notes 1 to 4, wherein 　　a length of the delaying is a predetermined period of time. (Supplementary note 6) 　　The method according to any one of supplementary notes 1 to 5, wherein 　　the another SSB / SIB1 transmission includes at least one of: 　　　　another on-demand SSB / SIB1 transmission, or 　　　　periodic SSB / SIB1 transmission. (Supplementary note 7) 　　The method according to any one of supplementary notes 1 to 6, wherein 　　at least one of the on-demand SSB / SIB1 transmission or the other SSB / SIB1 transmission is related to a secondary cell (SCell), and 　　the method comprises: 　　　　receiving information indicating a periodicity of the at least one of the on-demand SSB / SIB1 transmission or the other SSB / SIB1 transmission, before performing activation of the SCell. (Supplementary note 8) 　　The method according to supplementary note 7, wherein 　　the information is included in information indicating configuration of the SCell. (Supplementary note 9) 　　The method according to any one of supplementary notes 1 to 8, wherein 　　the another SSB / SIB1 transmission includes another on-demand SSB / SIB1 transmission, and 　　the dropping or delaying is performed on SSB / SIB1 transmission whose request is earlier than the other. (Supplementary note 10) 　　The method according to any one of supplementary notes 1 to 9, wherein 　　the threshold value includes at least one values of: 　　　　0, 2, 5 ,10, 20, or 　　　　a fraction of a periodicity of periodic SSB / SIB1 transmission. (Supplementary note 11) 　　The method according to any one of supplementary notes 1 to 10, wherein 　　the threshold value is different for the another SSB transmission and for the another SIB1 transmission. (Supplementary note 12) 　　A mobile device comprising: 　　means for dropping or delaying either on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB) / system information block 1 (SIB1) transmission or another SSB / SIB1 transmission, in a case where difference between a timing of the on-demand SSB / SIB1 transmission and a timing of the another SSB / SIB1 transmission is equal to or less than a threshold value.

[0221] 1　　COMMUNICATION SYSTEM 3-1, 3-2, 3-3　　USER EQUIPMENTS (UEs) 5　　RAN NODE 7　　CORE NETWORK 9　　ASSOCIATED CELLS 10　　CONTROL PLANE FUNCTION (CPF) 10-1　　ACCESS AND MOBILITY MANAGEMENT FUNCTION (AMF) 10-2　　SESSION MANAGEMENT FUNCTION (SMF) 10-n 　　OTHER FUNCTIONs 11　　USER PLANE FUNCTION (UPF) 21　　EXTERNAL DATA NETWORK 25　　RESOURCE BLOCK 31　　TRANSCEIVER CIRCUIT 33　　ANTENNA 35　　USER INTERFACE 37　　CONTROLLER 39　　MEMORY 41　　TRANSCEIVER CIRCUIT 43　　COMMUNICATION CONTROL MODULE 51　　TRANSCEIVER CIRCUIT 53　　ANTENNA 55　　CORE NETWORK INTERFACE 57　　CONTROLLER 59　　MEMORY 61　　OPERATING SYSTEM 63　　COMMUNICATION CONTROL MODULE

Claims

1. A method performed by a mobile device, the method comprising: 　　in a case where difference between a timing of on-demand synchronizing signal / physical broadcast channel (PBCH) block (SSB) / system information block 1 (SIB1) transmission and a timing of another SSB / SIB1 transmission is equal to or less than a threshold value, dropping or delaying either the on-demand SSB / SIB1 transmission or the another SSB / SIB1 transmission.

2. The method according to claim 1, further comprising: 　　continuing to monitor SSB / SIB1 transmission of the one that did not drop or delay.

3. The method according to claim 1 or 2, wherein 　　the dropping or delaying is performed on SSB / SIB1 transmission with the lower priority than the other.

4. The method according to claim 1 or 2, wherein 　　the dropping or delaying is performed on later SSB / SIB1 transmission than the other.

5. The method according to any one of claims 1 to 4, wherein 　　a length of the delaying is a predetermined period of time.

6. The method according to any one of claims 1 to 5, wherein 　　the another SSB / SIB1 transmission includes at least one of: 　　　　another on-demand SSB / SIB1 transmission, or 　　　　periodic SSB / SIB1 transmission.

7. The method according to any one of claims 1 to 6, wherein 　　at least one of the on-demand SSB / SIB1 transmission or the other SSB / SIB1 transmission is related to a secondary cell (SCell), and 　　the method comprises: 　　　　receiving information indicating a periodicity of the at least one of the on-demand SSB / SIB1 transmission or the other SSB / SIB1 transmission, before performing activation of the SCell.

8. The method according to claim 7, wherein 　　the information is included in information indicating configuration of the SCell.

9. The method according to any one of claims 1 to 8, wherein 　　the another SSB / SIB1 transmission includes another on-demand SSB / SIB1 transmission, and 　　the dropping or delaying is performed on SSB / SIB1 transmission whose request is earlier than the other.

10. The method according to any one of claims 1 to 9, wherein 　　the threshold value includes at least one values of: 　　　　0, 2, 5 ,10, 20, or 　　　　a fraction of a periodicity of periodic SSB / SIB1 transmission.

11. The method according to any one of claims 1 to 10, wherein 　　the threshold value is different for the another SSB transmission and for the another SIB1 transmission.

12. A mobile device comprising: 　　means for dropping or delaying either on-demand synchronization signal / physical broadcast channel (PBCH) block (SSB) / system information block 1 (SIB1) transmission or another SSB / SIB1 transmission, in a case where difference between a SSBtiming of the on-demand SSB / SIB1 transmission and a timing of the another SSB / SIB1 transmission is equal to or less than a threshold value.

Images