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

Abstract

A method performed by a User Equipment, UE, is described. The method comprising: receiving, from a network node, Master Information Block, MIB, comprising first information indicating whether System Information Block 1, SIB1, is to be transmitted periodically, temporarily, or on an on-demand basis; and receiving the SIB1 from the network node.

Description

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

[0001] The present disclosure relates to a communication system and to parts thereof. The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (including Long Term Evolution (LTE)-Advanced, Next Generation or 5G / 6G networks, future generations, and beyond). The present disclosure in particular, but not exclusively, relates to the acquisition of uplink (UL) wake-up signal (WUS) configurations and / or system information block 1 (SIB1) transmissions (periodically and / or on-demand) for network energy saving (NES) cells over those NES cells, or alternatively over an anchor cell / Cell 'A', especially in the context of non-terrestrial networks (NTNs) comprising space (or air) borne platforms.

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

[0003] Under the 3GPP standards, a NodeB (or e.g., 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] In more recently proposed RAN distributed architectures, in addition to the CU and DU, the concept of a Radio Unit (RU) - sometimes referred to as a 'remote unit' - has been introduced. In this architecture the RU is responsible for handling the digital front end (DFE), digital beamforming functionality and, typically, the functionality of the lower parts of the PHY layer, whilst the DU typically handles the higher parts of the PHY layer and the RLC and MAC layers. The CU in this architecture continues to be responsible for controlling one or more DUs (each DU corresponding to a different respective gNB) and to handle higher layer signalling (typically RRC and PDCP layers).

[0007] The actual functional split between the CU and DUs (and potentially RUs where applicable) of these distributed architectures is flexible allowing the functionality to be optimised for different use cases. Effectively, the split architecture enables a 5G network to use a different distribution of protocol stacks between CU and DUs (and potentially RUs) depending on, for example, mid-haul availability and network design.

[0008] The choice of how to split functions in the architecture depends on, among other things, factors related to radio network deployment scenarios, constraints and intended supported use cases. Key considerations include: the need to support a specific quality of service for each service offered and for real / non-real time applications; support of specific user density and load demand in a given geographical area; and available transport networks with different performance levels.

[0009] In 5G, core network entities comprise logical nodes (or 'functions') including control plane functions (CPFs) and one or more user plane functions (UPFs). The CPFs include, amongst other things, one or more Access and Mobility Management Functions (AMFs), a session management function (SMF), and one or more location management functions (LMFs). The AMF generally corresponds to the MME in 4G and performs many of the functions performed by the MME. Each UPF combines functionality of both the Serving Gateway (S-GW) and Packet Data Network Gateway (P-GW) - specifically user plane functionality of the S-GW (SGW-U) and user plane functionality of the P-GW (PGW-U). The SMF provides session management functionality (that formed part of MME functionality in 4G). The SMF also combines the some of the functionality provided by the S-GW and P-GW - specifically control plane functionality of the S-GW (SGW-C) and control plane functionality of the P-GW (PGW-C). The SMF also allocates IP addresses to each UE.

[0010] Further, as the usage of 5G mobile communication for a wide range of different use cases increases, their complexity and energy demands are also expected to increase. With this in mind, efforts are being made to enhance network energy saving (NES) approaches that afford significant power savings in an industry standardized manner. To that end, techniques / procedures have been evaluated that have shown to bring substantial NES gains. By way of example only, such techniques / procedures may include: -　　The adaption of transmission patterns; -　　The use of downlink (DL) (or uplink (UL)) wake-up signals (WUS) to allow devices such as UEs (or RAN nodes) to enter reduced transmission / reception modes, (for example discontinuous transmission / reception modes); -　　The use of on-demand SSBs (and possibly other DL signals) for camping onto secondary cells (SCells) by UEs configured to connect to, and use, such SCells; -　　The use of on-demand system synchronisation blocks (SSBs), and possibly other DL signals, for camping onto non-serving cells by UEs configured to connect to, and use, such non-serving cells; and -　　The use of on-demand system information block 1 (SIB1) for non-anchor cells supporting UEs in RRC INACTIVE / IDLE mode.

[0011] It will be appreciated that in the techniques / procedures listed above, SCells, non-serving cells, and / or non-anchor cells that implement some form of energy saving enhancement may also be referred to as NES cells - for example, cells that do not automatically (and / or periodically) transmit SSBs and / or system information (e.g., SIB1) to afford energy saving in the network.

[0012] In the case of on-demand SIB1 transmissions for non-anchor cells (e.g., NES cells) supporting UEs in RRC INACTIVE / IDLE mode, mechanisms, and procedures on how and when to transmit on-demand SIB1 transmissions are being considered.

[0013] In the case of on-demand SIB1 transmissions for NES cells, one example procedure being considered involves a UE obtaining an UL WUS configuration from a serving cell (e.g., 'Cell A') that indicates to the UE appropriate resources, and the like, for the transmission of a WUS signal to an NES cell to wake-up that NES cell. Once the NES cell has been woken up by the WUS signal sent by the UE, the NES cell transmits an on-demand SIB1 transmission associated with the NES cell to the UE.

[0014] Another example procedure being considered involves the serving cell (Cell A) rather than the NES cell providing the on-demand SIB1. This procedure still involves a UE obtaining an UL WUS configuration from the serving cell (Cell A) that indicates, to the UE, appropriate resources, and the like, for the transmission of a WUS signal to an NES cell to wake-up that NES cell. Once the NES cell has been woken up by the WUS signal sent by the UE, however, the serving cell (Cell A) (rather than the NES cell) transmits an on-demand SIB1 transmission associated with the NES cell to the UE. It will be appreciated that in this example, the NES cell may provide Cell A with an appropriate UL WUS configuration in advance that indicates appropriate resources that may be used by the UE for transmission of the WUS signal to the NES cell. The UL WUS configuration thus may be provided to Cell A by the NES cell over an appropriate interface (e.g., an Xn interface) before the NES cell enters an on-demand SIB1 mode and / or when the UL WUS configuration is updated / changed.

[0015] In the case of demand SSBs (and possibly other DL signals) for camping onto SCells by UEs configured to connect to, and use, such SCells mechanisms and procedures on how and when to transmit on-demand SSB transmissions are also being considered.

[0016] 3GPP is also working with the satellite communication industry to specify an integrated satellite and terrestrial network infrastructure in the context of 5G (and beyond). This is referred to as non-terrestrial networks (NTN) which term refers to networks, or segments of networks, using an airborne or spaceborne vehicle for transmission of data and control signalling. Satellites refer to spaceborne vehicles in Low Earth Orbits (LEO), Medium Earth Orbits (MEO), Geostationary Earth Orbit (GEO) or in Highly Elliptical Orbits (HEO). Airborne vehicles refer to High Altitude Platforms (HAPs) encompassing Unmanned Aircraft Systems (UAS) - including tethered UAS, Lighter than Air UAS and Heavier than Air UAS - all operating quasi-stationary at an altitude typically between 8 and 50 km. Typically, spaceborne vehicles in LEO may stay quasi-stationary for a few minutes at a time, while spaceborne vehicles in MEO may stay quasi-stationary for more than 1 hour at a time.

[0017] 3GPP Technical Report (TR) 38.811 is a study on New Radio to support such non-terrestrial networks. The study includes, amongst other things, NTN deployment scenarios and related system parameters (such as architecture, altitude, orbit etc.) and a description of adaptation of the 3GPP channel models for non-terrestrial networks (propagation conditions, mobility, etc.). Non-terrestrial networks are expected to: -　　help foster the 5G (and beyond) service roll out in un-served or underserved areas to upgrade the performance of terrestrial networks; -　　reinforce service reliability by providing service continuity for user equipment or for moving platforms (e.g. passenger vehicles - aircraft, ships, high speed trains, buses); -　　increase service availability everywhere; especially for critical communications, future railway / maritime / aeronautical communications; and -　　enable 5G (and beyond) network scalability through the provision of efficient multicast / broadcast resources for data delivery towards the network edges or even directly to the user equipment.

[0018] NTN access typically features the following elements (amongst others): -　　NTN Terminal: this may refer to the 3GPP UE or to a UE specific to the satellite system in the case that the satellite does not serve 3GPP UEs directly; -　　A service link which refers to the radio link between the UE and the space / airborne platform (which may be in addition to a radio link with a terrestrial based RAN); -　　A space or an airborne platform (e.g., a satellite or the like); -　　Gateways that connect the satellite or aerial access network to the core network. It will be appreciated that gateways will mostly likely be collocated with a base station (e.g. a gNB); and -　　Feeder links which refer to the radio links between the Gateways and the space / airborne platform.

[0019] Satellite or aerial vehicles typically generate several satellite beams over a given area. The beams have a typically elliptic footprint on the surface of the earth. The beam footprint may be moving over the earth with the satellite or the aerial vehicle motion on its orbit. Alternatively, the beam footprint may be earth fixed (albeit temporarily), in such case some beam pointing mechanisms (mechanical or electronic steering feature) may be used to compensate for the satellite or the aerial vehicle motion. There are different options for beam identification purposes. In one option multiple (nearby / neighbouring) satellite beams may have the same associated physical cell ID (PCI) and hence the PCI can remain unchanged as a UE moves from beam-to-beam of the set of beams sharing a PCI. Alternatively, there may be a one-to-one relationship between the PCIs and the satellite beams (at least within a particular satellite's coverage area comprising multiple beams).

[0020] In such integrated satellite and terrestrial network infrastructures, power constraints on the satellites typically necessitate the selective activation and deactivation of beams provided by the satellites. For example, not all beams that can be provided by the satellites may be activated at the same time, and some may be inactive for long periods of time (e.g., 20 ms) to allow for other beams to be used (i.e., to allow power sharing). Selective activation and deactivation of the satellites' beams thus means that not all UEs in the communication system may be provided with the same level of service (or any service at all) all of the time. Given this, NES techniques typically used in terrestrial networks in scenarios where a cell is not always available (or certain features / services provided by a cell are not always available, or not always available at the same periodicity) may also be well suited for use with NTN cells.

[0021] However, while progress has been made in the development of integrated satellite and terrestrial network infrastructures in the context of 5G (and beyond), such developments do not yet take full advantage any of the network energy saving (NES) approaches that 3GPP are developing as outlined above, despite such NES approaches being particularly well suited for use with NTN cells.

[0022] It is therefore desirous to provide further enhancements to integrated satellite and terrestrial network infrastructures in the context of 5G (and beyond). In particular, there is a need to develop techniques and procedures that allow for the implementation of NES approaches into NTNs to ensure the provision of the best possible service by NTN cells given strict NTN power constraints; in particular to ensure the provision of the best possible service by NTN cells given NTN cells are not able to provide full capacity all of the time due to those strict power constrains.

[0023] PTL 1: 3GPP Technical Report (TR) 38.811

[0024] NPL 1: NGMN 5G White Paper' V1.0

[0025] The present specification aims to disclose apparatus and methods that at least contribute to addressing one or more of the above needs.

[0026] In one aspect there is provided a method performed by a User Equipment, UE, the method comprising: 　　receiving, from a network node, Master Information Block, MIB, comprising first information indicating whether System Information Block 1, SIB1, is to be transmitted periodically, temporarily, or on an on-demand basis; and 　　receiving the SIB1 from the network node.

[0027] In one aspect there is provided a method performed by a user equipment, UE, the method comprising: 　　acquiring, from a first cell or a second cell, at least either an Uplink, UL, wake-up signal, WUS, configuration or a System Information Block 1, SIB1, wherein, 　　the first cell is a non-terrestrial networks, NTN, network-energy-saving, NES, cell, and the second cell is a non-NES cell, 　　the WUS and the SIB1 are for the first cell; and 　　connecting to the first cell after acquiring at least either the UL WUS configuration or the SIB1.

[0028] In one aspect there is provided a method performed by a network node, the method comprising: 　　transmitting, to a User Equipment, UE, Master Information Block, MIB, comprising first information indicating whether System Information Block 1, SIB1, is to be transmitted periodically, temporarily, or on an on-demand basis; and 　　transmitting the SIB1 to the UE.

[0029] In one aspect there is provided a User Equipment, UE, comprising: 　　means for receiving, from a network node, Master Information Block, MIB, comprising first information indicating whether System Information Block 1, SIB1, is to be transmitted periodically, temporarily, or on an on-demand basis; and 　　means for receiving the SIB1 from the network node.

[0030] In one aspect there is provided a user equipment, UE, comprising: 　　means for acquiring, from a first cell or a second cell, at least either an Uplink, UL, wake-up signal, WUS, configuration or a System Information Block 1, SIB1, wherein, 　　the first cell is a non-terrestrial networks, NTN, network-energy-saving, NES, cell, and the second cell is a non-NES cell, 　　the WUS and the SIB1 are for the first cell; and 　　means for connecting to the first cell after acquiring at least either the UL WUS configuration or the SIB1.

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

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

[0033] According to the present disclosure, it is possible to provide a method performed by a UE, a method performed by a network node, and a UE.

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

[0035] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system;Fig. 2A illustrates a possible architecture of an NTN RAN;Fig. 2B illustrates a possible architecture of an NTN RAN;Fig. 2C illustrates a possible architecture of an NTN RAN;Fig. 3 illustrates schematically a non-terrestrial network (NTN) radio access network that may be used in the communication system of Fig. 1;Fig. 4 is a simplified sequence diagram illustrating an example SIB1 acquisition procedure for an NES cell that may be implemented in the communication system of Fig. 1;Fig. 5 is a simplified sequence diagram illustrating another example SIB1 acquisition procedure for an NES cell that may be implemented in the communication system of Fig. 1;Fig. 6 is a simplified sequence diagram illustrating yet another example SIB1 acquisition procedure for an NES cell that may be implemented in the communication system of Fig. 1;Fig. 7 is a simplified sequence diagram illustrating yet another example SIB1 acquisition procedure for an NES cell that may be implemented in the communication system of Fig. 1;Fig. 8 is a simplified diagram illustrating an arrangement of different levels of space (or air) borne platforms and the cell coverage provided to a UE by base stations of those space (or air) borne platforms as implemented in the communication system of Fig. 1;Fig. 9 is a simplified sequence diagram illustrating an example UL WUS configuration and / or SIB1 acquisition procedure for an NES cell over an anchor cell / Cell 'A' that may be implemented in the communication system of Fig. 1;Fig. 10 is a simplified sequence diagram illustrating another example UL WUS configuration and / or SIB1 acquisition procedure for an NES cell over an anchor cell / Cell 'A' that may be implemented in the communication system of Fig. 1;Fig. 11 is a simplified sequence diagram illustrating yet another example UL WUS configuration and / or SIB1 acquisition procedure for an NES cell over an anchor cell / Cell 'A' that may be implemented in the communication system of Fig. 1;Fig. 12 is a simplified block schematic illustrating the main components of a UE for implementation in the communication system of Fig. 1;Fig. 13 is a schematic block diagram illustrating the main components of a non-distributed base station for the communication system of Fig. 1; andFig. 14 is a schematic block diagram illustrating the main components of a distributed base station for the communication system of Fig. 1.

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

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

[0038] In the communication system 1, user equipments (UEs) 3 (3-1, 3-2, 3-3) (e.g., mobile telephones and / or other mobile or stationary devices) can communicate with each other via a corresponding (radio) access network ((R)AN) 5 (5-1, 5-2) that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, each RAN 5 comprises a corresponding base station (5A) 5A-1, 5A-2 (which may be integrated or distributed type base stations) operating one or more associated cells 9 (9-1, 9-2).Communication via each RAN 5 is typically routed through a core network 7 (e.g., a 5G / 6G / later generation core network or evolved packet core (EPC) network) or any other core network.

[0039] As those skilled in the art will appreciate, whilst three UEs 3 and two RANs 5 are shown in Fig. 1 for illustration purposes, the system, when implemented, will typically include one or more other RANs 5 and UEs 3.

[0040] Each RAN 5 respectively controls the associated one or more 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 each RAN 5 may be configured to support 4G, 5G, 6G and / or later generations, and / or any other 3GPP or non-3GPP communication protocols.

[0041] In the illustrated example, one RAN 5-1 is non-terrestrial network (NTN) RAN, while the other RAN 5-2 is a terrestrial network (TN). It will be appreciated that both RANs 5 in the communication system 1 may be TN RANs, or alternatively, both RANs 5 in the communication system 1 may be NTN RANs.

[0042] The UEs 3 and their serving RAN 5 are connected via an appropriate air interface (for example the so-called 'Uu' interface and / or the like). Base stations 5A of neighbouring RANs 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 - not shown in Fig. 1).

[0043] 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. Additional functions may include, for example: an Authentication Server Function (AUSF) which facilitates security processes; a Unified Data Management (UDM) entity for managing user specific data (e.g., for access authorization, user registration, and data network profiles); a Policy Control Function (PCF); an Application Function (AF); a Security Anchor Function (SEAF) which is in a serving network and acts as a "middleman" during an authentication process between a UE and its home network; an Authentication credential Repository and Processing Function (ARPF) which maintains the authentication credentials; and / or the like. It will be appreciated that the nodes or functions may have different names in different systems.

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

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

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

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

[0048] Each base station 5A 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.

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

[0050] The DL physical signals may include, for example, 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 base station 5A of the corresponding RAN 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).

[0051] Similarly, the UEs 3 are configured for transmission of, and the base station 5A of the corresponding RAN 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.

[0052] The UEs 3 and each base station 5A of a corresponding RAN 5 are mutually configured for performing a random-access channel (RACH) procedure for the UEs 3 to access the network. Specifically, on detection and selection of a cell 9 (and / or a beam) a UE 3 is able to attempt access to that cell 9 and / or beam using an initial radio resource control (RRC) connection setup procedure comprising a random-access procedure with the corresponding RAN 5.

[0053] Prior to attempting initial access, the UE 3 chooses random-access resources (including, for example, a preamble) to use to initiate the RACH procedure. The UE 3 sends the selected preamble (e.g., in 'Msg1') to the base station 5A of the RAN 5 over a physical random-access channel (PRACH) for initiating the process to obtain synchronization in the uplink (UL). In response, the base station 5A responds with a random-access response (RAR) (or 'Msg2'). The RAR indicates reception of the preamble and includes: a timing advance (TA) command for adjusting the transmission timing of the UE 3 based on the timing of the received preamble; an uplink grant field indicating the resources to be used in the uplink for a physical uplink shared channel (PUSCH); a frequency hopping flag to indicate whether the UE 3 is to transmit on the PUSCH with or without frequency; a modulation and coding scheme (MCS) field from which the UE 3 can determine the MCS for the PUSCH transmission; and a transmit power control (TPC) command value for setting the power of the PUSCH transmission. The UE 3 then sends a third message ('Msg3') to the base station 5A over a physical uplink shared channel (PUSCH) based on the information in the RAR. The specific message sent by the UE 3 in this step, and the content of the message, depends on the context in which the random-access procedure is being used. In the example of initial RRC connection setup, however, Msg3 typically comprises an RRC Setup request or similar message carrying a temporary randomly generated UE identifier. The base station 5A responds with a fourth message ('Msg4') which carries the randomly generated UE identifier received in Msg3 for contention purposes to resolve any collisions between different UEs 3 using the same preamble sequence. When successful, Msg4 also transfers the UE 3 to a connected state.

[0054] While a four-step contention-based RACH procedure is described it will be appreciated that a UE 3 and each base station 5A of a corresponding RAN 5 may also perform a non-contention based (or 'contention free') procedure in which a dedicated preamble is assigned by each base station 5A to the UE 3. Moreover, a UE 3 and each base station 5A of a corresponding RAN 5 may perform a two-step RACH procedure.

[0055] It will be appreciated that while the UE 3 can trigger initiation of the RACH procedure itself (e.g., when the UE 3 needs to connect to the network), initiation of the RACH procedure may be by the network. For example, a RACH procedure may be initiated via a message sent via downlink control information (DCI) with an appropriate DCI format (e.g., 1_0) in a physical downlink control channel (PDCCH) - such a message is commonly known as a PDCCH order. A RACH procedure may be also initiated by each base station 5A of a corresponding RAN 5 when handover is required (e.g., using a handover command message, or the like).

[0056] < NTN RAN Architecture > 　　Figs. 2A to 2C each respectively illustrate a possible architecture of an NTN RAN 5-1 that may be used.

[0057] The architecture of Fig. 2A may be referred to as a 'transparent satellite' based RAN architecture. In this architecture, the base station 5A-1 is a terrestrially located base station that sends and receives communications respectively destined for and originating from the UEs 3 via a terrestrially located gateway 5B-1 and via a non-terrestrial space (or air) borne platform 5C-1 that has no base station functionality. The non-terrestrial space (or air) borne platform 5C-1 relays these communications to and from the UEs 3 in one or more cells 9 operated by the base station 5A-1, and from and to the gateway 5B-1 as required. The non-terrestrial space (or air) borne platform 5C-1 relays these communications transparently without on-board processing them in effect acting as a so-called 'bent-pipe'. In this implementation, the feeder link between the gateway 5B-1 and the non-terrestrial space (or air) borne platform 5C-1 effectively acts as part of the Uu interface (or reference point) between the base station 5A-1 and one or more UEs 3. Similarly, the service link between the non-terrestrial space (or air) borne platform 5C-1 and one or more UEs 3 effectively acts as another part of the Uu interface (or reference point) between the base station 5A-1 and one or more UEs 3. The base station's communication link with the core network 7 (e.g., for signalling over the N2, N3 interface / reference point etc.) is provided solely terrestrially.

[0058] The architecture of Fig. 2B may be referred to as a 'regenerative satellite' based RAN architecture (i.e., in which the satellite performs on board processing of the payload being communicated between the UE 3 and the core network 7). In this architecture, the base station 5A-1 is a base station 5A-1 of a distributed type having a terrestrially located central unit (CU) 5ACU-1 and a distributed unit (DU) 5ADU-1 provided on-board the non-terrestrial space (or air) borne platform 5C-1. The terrestrially located CU 5ACU-1 performs some of the (typically higher layer) functionality of the base station 5A-1 whereas the non-terrestrially located DU 5ADU-1 performs other (typically lower layer) functionality of the base station 5A-1. The terrestrially located CU 5ACU-1 communicates with the non-terrestrially located DU 5ADU-1 via the gateway 5B-1 and an F1 interface implemented via a satellite radio interface between the gateway 5B-1 and the non-terrestrial space (or air) borne platform 5C-1 in which the DU 5ADU-1 is provided.

[0059] The non-terrestrial space (or air) borne platform 5C-1 transmits communications destined for and originating from the UEs 3 in one or more cells 9 operated by the base station 5A-1, and from and to the gateway 5B-1 as required. However, in this implementation lower layer processing of communication respectively destined for and originating from the UEs 3 is performed on-board the non-terrestrial space (or air) borne platform 5C-1 by the DU 5ADU-1 and higher layer processing of that communication respectively destined for and originating from the UEs 3 is performed by the terrestrially located CU 5ACU-1.

[0060] Accordingly, in this implementation, the feeder link between the gateway 5B-1 and the non-terrestrial space (or air) borne platform 5C-1 effectively acts as the F1 interface (or reference point) between the CU 5ACU-1 and DU 5ADU-1 of the base station 5A-1. The service link between the non-terrestrial space (or air) borne platform 5C-1 and one or more UEs 3, on the other hand, effectively acts as the Uu interface (or reference point) between the base station 5A-1 and one or more UEs 3. The base station's communication link with the core network 7 (e.g., for signalling over the N2, N3 interface / reference point etc.) is provided solely terrestrially.

[0061] The architecture of Fig. 2C may also be referred to as a 'regenerative satellite' based RAN architecture (i.e., in which the satellite performs on board processing of the payload being communicated between the UE 3 and the core network 7). In this architecture, the base station 5A-1 is provided on-board the non-terrestrial space (or air) borne platform 5C-1. The base station 5A-1 on board the non-terrestrial space (or air) borne platform 5C-1 transmits communications destined for and originating from the UEs 3 in one or more cells 9 operated by the base station 5A-1, and from and to the core network 7 via the gateway 5B-1 as required. However, in this implementation, processing of communication respectively destined for and originating from the UEs 3 is performed on-board the non-terrestrial space (or air) borne platform 5C-1 by the base station 5A-1.

[0062] Accordingly, in this implementation, the feeder link between the gateway 5B-1 and the non-terrestrial space (or air) borne platform 5C-1 effectively acts as part of the N2 / N3 interfaces (or reference points) between the base station 5A-1 and the core network 7. The base station's communication link with the core network 7 (e.g., for signalling over the N2, N3 interface / reference point etc.) is thus provided partly via the feeder link and partly terrestrially. The service link between the non-terrestrial space (or air) borne platform 5C-1 and one or more UEs 3, on the other hand, effectively acts as the Uu interface (or reference point) between the base station 5A-1 and one or more UEs 3.

[0063] The base station 5A-1 thus controls one or more associated cells 9 via the non-terrestrial space (or air) borne platform 5C-1. It will be appreciated that the base station 5A-1 may be configured to support 4G, 5G, and / or later generations and / or any other 3GPP or non-3GPP communication protocols.

[0064] < NTN RAN > 　　Fig. 3 illustrates schematically one NTN RAN 5-1 architecture that may be used in the communication system of Fig. 1.

[0065] Fig. 3 depicts an NTN RAN 5-1 whose satellite is in regenerative mode as shown in Fig. 2C. It will nevertheless be appreciated that the NTN RAN 5-1 depicted is by way of example only, and that the NTN RAN 5-1 may comprise a satellite in regenerative mode as shown in Fig. 2B, or alternative transparent (bent pipe) mode as shown in Fig. 2A.

[0066] As seen in Fig. 3, the NTN RAN 5-1 comprises a base station 5A-1 operating one or more associated cells 9, a gateway 5B-1, and a non-terrestrial space (or air) borne platform 5C-1 (e.g. comprising one or more satellites and / or airborne vehicles), which may be referred to generally as a 'satellite' 5C-1 for simplicity. Communication via the NTN RAN 5-1 is routed through the core network 7 and external data network 20 (e.g. via the N6 interface / reference point).

[0067] The NTN RAN 5-1 controls a number of directional satellite beams via which associated NTN cells 9 may be provided. Specifically, each satellite beam has an associated footprint on the surface of the Earth which forms an NTN cell 9, or part of an NTN cell 9. Each NTN cell 9 has an associated Physical Cell Identity (PCI). The satellite beam footprints may be moving as the space (or air) borne platform 5C-1 is travelling along its orbit (e.g., as illustrated by the arrows 'A' in Fig. 3). Alternatively, the satellite beam footprint may be earth fixed, in which case an appropriate satellite beam pointing mechanism (mechanical or electronic steering) may be used to compensate for the movement of the non-terrestrial space (or air) borne platform 5C-1. Satellite beams and satellites are not considered visible from a UE perspective in NTN. This does not, however, preclude differentiating at the public land mobile network (PLMN) level the type of network (e.g., NTN vs. terrestrial).

[0068] The base station 5A-1 of the NTN RAN 5-1 is configured to provide ephemeris data for the non-terrestrial space (or air) borne platform 5C-1, to the UEs 3, to help UEs 3 perform measurement and cell selection / reselection and for supporting initial access. This ephemeris data may comprise information on orbital information such as information on orbital plane level or on satellite level and / or information (e.g., a pointer or index) from which more detailed ephemeris data stored in the UE 3 (e.g. in a universal subscriber identity module, 'USIM') may be obtained. At least some of this ephemeris information may, for example, be provided in system information and / or may be provided using UE specific (dedicated) signalling such as RRC signalling.

[0069] Specifically, the base station 5A-1 is able to provide satellite assistance information for the satellite as part of a dedicated system information block (SIB) that is broadcast to UEs 3 in a corresponding cell 9 of the NTN RAN 5-1 (for NTN this may, for example, be SIB19 but for future generations it may be provided in another SIB or in a different way). The satellite assistance information may include, for example, information identifying at least one associated NTN configuration (e.g., as part of an NTN-Config IE or the like). The NTN configuration includes parameters for assisting the UE 3 to access the network using NTN access (e.g., ephemeris data, common timing alignment parameters, a scheduling (e.g., koffset), validity duration for uplink synchronisation information, and an epoch time (a reference time for which assistance information is valid)).

[0070] The satellite assistance information may include, for example, an indication of a time information on when a cell 9 provided via an NTN system is going to stop serving the area it is currently covering (e.g., in a t-Service IE). This may be indicated, for example, as a time in multiples of 10ms after 00:00:00 on a Gregorian calendar date of 1 January 1900 (midnight between Sunday, December 31, 1899, and Monday, January 1, 1900). The exact stop time may be between the time indicated by the value of this field minus 1 and the time indicated by the value of this field.

[0071] With the help of this ephemeris data, a UE 3 may search for the first NTN cell 9 it can connect to. After detecting a synchronization signal block (SSB) of a cell 9 broadcasted via a non-terrestrial space (or air) borne platform 5C-1, the UE 3 may be able to read initial system information of that cell 9 which may contain further ephemeris information relating to the exact location of the cell 9 (and / or to the satellite broadcasting the cell 9). This ephemeris information may be given relative to information relating, for example, to the orbital plane that the UE 3 may already have obtained.

[0072] The accuracy of the prediction of a satellite orbit or the satellite position can decrease with time and so, to help ensure accuracy, the ephemeris data provided to the UE 3 is updated periodically or aperiodically.

[0073] The same PCI may be used for several satellite beams, or there may be one PCI per satellite beam. A satellite beam can consist of one or more SSB beams with one cell 9 (PCI) having a maximum of L SSB beams, where L can typically be 4, 8 or 64 depending on the band. During initial access, the UEs 3 perform cell search based on SSBs where each SSB is transmitted in a different respective beam. Each SSB comprises a primary synchronization signal (PSS), secondary synchronization signal (SSS), and physical broadcast channel (PBCH). As the SSB carries synchronization signals (SSs) / PBCH (SS / PBCH) transmissions it is sometimes referred to as an SS / PBCH block.

[0074] As those skilled in the art will understand, while the disclosure is described in the context of an NTN based RAN 5 / base station 5A, many of the technical features described are generally applicable to, and can be implemented in, any RAN 5 / base station 5A of a more conventional (non-NTN) based communication system 1.

[0075] However, as alluded to above, while there has been much progress in the development of NTNs, further work it still required to improve their efficiencies. In particular, there is a need to adapt NTNs to incorporate NES approaches and techniques to beneficially provide similar network energy savings to NTNs to those enjoyed by TNs. A number of these possible approaches / techniques that may be implemented in the communication system 1 will now be briefly introduced, by way of example only, before a more detailed description of the various mechanisms / techniques is provided.

[0076] For example, as described in more detail later, the communication system 1 may be configured to support one or more procedures for handling acquisition of a SIB1 by a UE 3 in an NES cell 9 in a scenario in which SIB1 is already being periodically broadcast by a RAN 5 in that NES cell 9.

[0077] Beneficially, as described in more detail later, the communication system 1 may be configured to additionally (or alternatively) support one or more procedures for handling the acquisition of a SIB1 by a UE 3 in an NES cell 9 in a scenario in which SIB1 is only temporarily broadcast by a RAN 5 in that NES cell 9. For example, when the SIB1 is broadcast by the RAN 5 in an NES cell 9 in an aperiodic manner and / or when the SIB1 will be broadcast by the RAN 5 in an NES cell 9 a specific number of times before the broadcast is stopped (rather than continuously).

[0078] Beneficially, as described in more detail later, the communication system 1 may be configured to additionally (or alternatively) support one or more procedures to acquire uplink (UL) wake-up signal (WUS) configurations and / or SIB1 for an NES cell 9 in the context of an NTN system.

[0079] < SIB1 Acquisition by a UE Over an NES Cell > 　　< Acquisition of SIB1 During Periodic SIB1 Broadcast > 　　Fig. 4 is a simplified sequence diagram illustrating an example SIB1 acquisition procedure that may be implemented in the communication system 1 of Fig. 1.

[0080] As shown in Fig. 4, there is provided a UE 3, and a RAN 5 which provides at least one cell 9 over which the UE 3 and the RAN 5 can communicate. It will be appreciated that, in the following procedure, whilst a RAN 5 is referred to in general terms, communication performed by the RAN 5 with the UE 3 will typically be performed by the base station 5A of the RAN 5.

[0081] At step S402, the UE 3 may receive a MIB from the RAN 5 (e.g., over an NES cell 9). That MIB may, for example, include typical MIB-type content such as the subcarrier spacing (SCS) to be used for the reception of a SIB1 transmission, other broadcast System Information (SI), paging message, and the like. For example, the MIB may contain an appropriate indication as to whether or not the SIB1 is to be transmitted periodically, temporarily, or on an on-demand basis. Furthermore in the case where the MIB indicates that the SIB1 is to be transmitted periodically, the MIB may also contain an indication of the periodicity at which the SIB1 will be transmitted. For example, the MIB may indicate that SIB1 is to be broadcast by the RAN 5 periodically at a periodicity of e.g., 160 ms, 320 ms, 640 ms, etc. Where the SIB1 is to be broadcast periodically at 160 ms (e.g., a legacy periodicity) it may be said to be regularly broadcast, while when the SIB1 is to be broadcast at a periodicity greater than 160 ms it may be said to be sparsely broadcast.

[0082] The MIB may also contain appropriate information pertaining to the application of a subcarrier offset, which can be used to indicate whether or not the MIB has an associated CORESET which can be used when allocating PDSCH resources for the SIB1, as well as other parameters which will be known to the skilled person.

[0083] At step S404, the UE 3 processes the MIB it received at S402. In the scenario shown in Fig. 4, the UE 3 is aware, from the content of the MIB, that SIB1 (e.g., for the NES cell 9) will be broadcast by the RAN 5 on a periodic basis (and the periodicity at which it will be broadcast). Being aware that the SIB1 will be broadcast by the RAN 5 periodically and the periodicity at which it will be broadcast, the UE 3 may decide to listen for those SIB1 transmission (Option 'A') at step S408 and ignore any UL WUS configuration that the UE 3 may have for configuring the UE 3 for transmitting an UL WUS to request an on-demand SIB1 transmission in the NES cell 9.

[0084] For example, the UE 3 may have received such an UL WUS configuration previously (e.g., following a request for such an UL WUS configuration, automatically via the MIB it received at step S402, or in some other way) either in the NES cell 9 or another cell 9 (such as an anchor cell 9 / non-NES cell 9 / cell 'A' 9)

[0085] It will be appreciated that, where the UE 3 does not have any UL WUS configuration (or does not have an up-to-date UL WUS configuration) and the UE 3 might otherwise request an UL WUS configuration, the UE 3, being aware that SIB1 will be broadcast by the RAN 5 periodically, may choose not to request an UL WUS configuration from the RAN 5.

[0086] At step S408, the RAN 5 broadcasts SIB1 transmissions periodically with a periodicity as indicated in the MIB sent to the UE 3 at step S402 and the UE 3 can therefore acquire the information contained in SIB1, to access the NES cell 9, when required.

[0087] Fig. 5 is a simplified sequence diagram illustrating another example SIB1 acquisition procedure that may be implemented in the communication system 1 of Fig. 1.

[0088] As shown in Fig. 5, there is provided a UE 3, and a RAN 5 which provides at least one cell 9 over which the UE 3 and the RAN 5 can communicate. It will be appreciated that, in the following procedure, whilst a RAN 5 is referred to in general terms, communication performed by the RAN 5 with the UE 3 will typically be performed by the base station 5A of the RAN 5.

[0089] At step S502, the UE 3 may receive a MIB from the RAN 5 (e.g., over an NES cell 9). That MIB may, for example, include typical MIB-type content such as the subcarrier spacing (SCS) to be used for the reception of a SIB1 transmission, other broadcast System Information (SI), paging message, and the like. For example, the MIB may contain an appropriate indication as to whether or not the SIB1 is to be transmitted periodically, temporarily, or on an on-demand basis. Furthermore in the case where the MIB indicates that the SIB1 is to be transmitted periodically, the MIB may also contain an indication of the periodicity at which the SIB1 will be transmitted. For example, the MIB may indicate that SIB1 is to be broadcast by the RAN 5 periodically at a periodicity of e.g., 160 ms, 320 ms, 640 ms, etc. Where the SIB1 is to be broadcast periodically at 160 ms (e.g., a legacy periodicity) it may be said to be regularly broadcast, while when the SIB1 is to be broadcast at a periodicity greater than 160 ms it may be said to be sparsely broadcast.

[0090] The MIB may also contain appropriate information pertaining to the application of a subcarrier offset, which can be used to indicate whether or not the MIB has an associated CORESET which can be used when allocating PDSCH resources for the SIB1, as well as other parameters which will be known to the skilled person.

[0091] At step S504, the UE 3 processes the MIB it received at S502. In the scenario shown in Fig. 5, the UE 3 is aware, from the content of the MIB, that SIB1 (e.g., for the NES cell 9) will be broadcast by the RAN 5 on a periodic basis (and the periodicity at which it will be broadcast).

[0092] Being aware that the SIB1 will be broadcast by the RAN 5 periodically and the periodicity at which it will be broadcast, the UE 3 may decide, at step S506 to request on-demand SIB1 transmissions from the RAN 5 (Option 'B'). For example, the UE 3 may determine that, due to for example latency requirements, or the like, the periodically broadcast SIB1 transmissions from the RAN 5 will not be sufficient (e.g., may not be received in time) and that on-demand SIB1 transmissions should be requested.

[0093] At step S508, if the UE 3 determines that the periodically broadcast SIB1 transmissions from the RAN 5 will not be sufficient (e.g., may not be received in time) and that on-demand SIB1 transmissions should be requested, the UE 3 may send a WUS to the RAN 5 at step S508. That WUS may include appropriate indications to wake-up the RAN 5 and / or request on-demand SIB1 transmissions from the RAN 5 in respect of the NES cell 9.

[0094] For example, at step S508, the UE 3 may send a WUS to the RAN 5 in accordance with an UL WUS configuration that the UE 3 may have received previously (e.g., following a request for such an UL WUS configuration, automatically via the MIB it received at step S502, or in some other way) either in the NES cell 9 or another cell 9 (such as an anchor cell 9 / non-NES cell 9 / cell 'A' 9).

[0095] It will be appreciated that if a UE 3 does not have any UL WUS configuration (or does not have an up-to-date UL WUS configuration), when the UE 3 determines that the periodically broadcast SIB1 transmissions from the RAN 5 will not be sufficient (e.g., may not be received in time), then the UE 3 may obtain such a UL WUS configuration on-demand by requesting such an UL WUS configuration. Then, at step S508, the UE 3 may send a WUS to the RAN 5 in accordance with an UL WUS configuration that the UE 3 requested when the UE 3 determined to request on-demand SIB1s at step S506. For example, having determined that the periodically broadcast SIB1 transmissions from the RAN 5 will not be sufficient (e.g., may not be received in time) and that on-demand SIB1 transmissions should be requested at step S506, the UE 3 may (not shown) send an UL WUS configuration request, or the like, to the RAN 5 to request the RAN 5 to provide an UL WUS configuration to the UE 3. The RAN node 5A may then send an UL WUS configuration to the UE 3, which the UE 3 may use to send a WUS to the RAN 5 to request on-demand SIB1 transmissions.

[0096] At step S510, the RAN 5 may transmit on-demand SIB1 transmissions to the UE 3. More specifically, having received the WUS message requesting on-demand SIB1 transmissions, the RAN 5 may (optionally, not shown) transmit a DCI message (e.g., a DCI format 1_0 message scrambled with SI-RNTI) to indicate to the UE 3 appropriate resources on which to expect to receive the SIB1 transmissions. For example, the DCI message may indicate that the on-demand SIB1s are to be transmitted to the UE 3 periodically within a specific SIB1 transmission period (e.g., a period of 160 ms) from a specific start time. The specific start time may, by way of example, correspond to the time immediately following transmission of the DCI format 1_0 message. Alternatively, the specific start time may, by way of example, correspond to the end of a specified time delay window. For example, the transmission start time for the SIB1s may be delayed until the start of a next SIB1 periodicity (i.e., the start of the next 160 ms period), following the transmission of the DCI format 1_0 that indicates the SIB1 resources.

[0097] Alternatively (or additionally), the DCI message may indicate that the on-demand SIB1s are to be transmitted to the UE 3 a specific number of times. For example, the DCI format 1_0 may indicate the SIB1 transmission period is 160 ms, and that the on-demand SIB1s are to be transmitted to the UE 3 once every 40 ms i.e., the RAN 5 will transmit on-demand SIB1s to the UE 3 four times in the 160 ms SIB1 transmission period.

[0098] Alternatively, having received the WUS message requesting an on-demand SIB1 transmissions, the RAN 5 may not need to transmit a DCI message if the appropriate resources on which to expect to receive the on-demand SIB1 transmissions have already been indicated to the UE 3 by an earlier message. In one example, the appropriate resources may be indicated to the UE 3 in the UL WUS configuration that the UE 3 received from the RAN 5. In another example, the appropriate resources may be indicated to the UE 3 in an appropriate response message (not shown) sent by the RAN 5 to the UE 3 having received the WUS message to request on-demand SIB1 transmissions at step S508.

[0099] Alternatively, having received the WUS message requesting on-demand SIB1 transmissions, the RAN 5 may not need to transmit a DCI message even if the appropriate resources on which to expect to receive on-demand SIB1 transmissions has not been previously signalled to the UE 3 if a specific time window for receiving on-demand SIB1 transmissions is pre-configured (hard coded) at the UE 3. For example, the UE 3 may start to monitor for on-demand SIB1 transmissions from the RAN 5 immediately after transmitting the WUS message, and it may expect the on-demand SIB1 transmissions to be transmitted using a legacy periodicity (e.g., 160 ms) or some other new periodicity (e.g. 320 ms, 640 ms).

[0100] < Possible Indication of UL WUS Allowability During Periodic SIB1 Transmissions > 　　It will be appreciated that the UL WUS configuration received by the UE 3 (e.g., following a request for such an UL WUS configuration, automatically via the MIB, or in some other way) may include an indication of whether or not the UE 3 is allowed to send a WUS to request on-demand SIB1 transmissions in the event that the RAN 5 has already indicated that SIB1 is being broadcast periodically. In this scenario, even when the UE 3 determines that the periodically broadcast SIB1 transmissions from the RAN 5 will not be sufficient (e.g., may not be received in time) and that on-demand SIB1 transmissions should be requested, the UE 3 may nevertheless decide not to send a WUS in accordance with the UL WUS configuration if the UL WUS configuration indicates that such a request for on-demand SIB1 transmissions is not allowed.

[0101] < Acquisition of SIB1 During Temporary SIB1 Broadcast > 　　Fig. 6 is a simplified sequence diagram illustrating another example SIB1 acquisition procedure that may be implemented in the communication system 1 of Fig. 1.

[0102] As shown in Fig. 6, there is provided a UE 3, and a RAN 5 which provides at least one cell 9 over which the UE 3 and the RAN 5 can communicate. It will be appreciated that, in the following procedure, whilst a RAN 5 is referred to in general terms, communication performed by the RAN 5 with the UE 3 will typically be performed by the base station 5A of the RAN 5.

[0103] At step S602, the UE 3 may receive a MIB from the RAN 5 (e.g., over an NES cell 9). That MIB may, for example, include typical MIB-type content such as the subcarrier spacing (SCS) to be used for the reception of a SIB1 transmission, other broadcast System Information (SI), paging message, and the like. In this example, the MIB may also contain an appropriate indication that the SIB1 is being transmitted temporarily (e.g., via a cell defining SSB (CD-SSB)). The indication may, for example, be included temporarily while such SIB1 transmission is ongoing.

[0104] For example, SIB1 transmissions by the RAN node 5A over e.g., the NES cell 9, may be triggered temporarily by an on-demand SIB1 transmission request sent to the NES cell 9 from another UE or UEs. In this scenario, the UE 3 may not be aware of the conditions (e.g., the periodicity, timing, resources, etc.) used for the on-demand SIB1 transmissions as they were requested by another UE or UEs. Alternatively (or additionally), SIB1 transmissions by the RAN node 5A over e.g., the NES cell 9, may be triggered temporarily by a regular SIB1 update within the NES cell 9. Similarly, in this scenario, the UE 3 may not be aware of the conditions (e.g., the periodicity, timing, resources, etc.) used for the SIB1 transmissions as they are triggered by SIB1 updates in the NES cell 9 of which the UE 3 may not be aware.

[0105] At step S604, the UE 3, having received the MIB1 indicating that a SIB1 is to be transmitted temporarily by the RAN 5, may begin to monitor for scheduling for the SIB1 transmission on Core Resource Set #0 (CORESET#0) - i.e., the CORESET that is to carry the PDCCH / DCI for SIB1 - and ignores any UL WUS configuration that the UE 3 may have for transmitting an UL WUS to request on-demand SIB1 transmissions (i.e., the UE 3 monitors the CORESET#0 and does not send a WUS to the RAN 5 to request on-demand SIB1 transmissions).

[0106] For example, the UE 3 may have received such an UL WUS configuration previously (e.g., following a request for such an UL WUS configuration, automatically via the MIB it received at step S602, or in some other way) either in the NES cell 9 or another cell 9 (such as an anchor cell / non-NES cell / cell 'A').

[0107] It will be appreciated that, where a UE 3 does not have any UL WUS configuration (or does not have an up-to-date UL WUS configuration) and the UE 3 might otherwise request an UL WUS configuration, the UE 3, being aware that the SIB1 will be broadcast by the RAN 5 temporarily, may choose not to request an UL WUS configuration from the RAN 5.

[0108] At step S606, the RAN 5 broadcasts temporary SIB1 transmissions to the UE 3, and the UE 3 may receive those SIB1 transmission through its monitoring of the CORESET#0.

[0109] Fig. 7 is a simplified sequence diagram illustrating yet another example SIB1 acquisition procedure that may be implemented in the communication system 1 of Fig. 1.

[0110] As shown in Fig. 7, there is provided a UE 3, and a RAN 5 which provides at least one cell 9 over which the UE 3 and the RAN 5 can communicate. It will be appreciated that, in the following procedure, whilst a RAN 5 is referred to in general terms, communication performed by the RAN 5 with the UE 3 will typically be performed by the base station 5A of the RAN 5.

[0111] At step S702, the UE 3 may receive a MIB from the RAN 5 (e.g., over an NES cell 9). That MIB may, for example, include typical MIB-type content such as the subcarrier spacing (SCS) to be used for the reception of a SIB1 transmission, other broadcast System Information (SI), paging message, and the like. In this example, the MIB may also contain an appropriate indication that the SIB1 is being transmitted temporarily (e.g., via a cell defining SSB (CD-SSB)). The indication may, for example, be included temporarily while such SIB1 transmission is ongoing.

[0112] For example, SIB1 transmissions by the RAN node 5A over e.g., the NES cell 9, may be triggered temporarily by an on-demand SIB1 transmission request sent to the NES cell 9 from another UE or UEs. In this scenario, the UE 3 may not be aware of the conditions (e.g., the periodicity, timing, resources, etc.) used for the on-demand SIB1 transmissions as they were requested by another UE or UEs. Alternatively (or additionally), SIB1 transmissions by the RAN node 5A over e.g., the NES cell 9, may be triggered temporarily by a regular SIB1 update within the NES cell 9. Similarly, in this scenario, the UE 3 may not be aware of the conditions (e.g., the periodicity, timing, resources, etc.) used for the SIB1 transmissions as they are triggered by SIB1 updates in the NES cell 9 of which the UE 3 may not be aware.

[0113] At step S704, the UE 3, having received the MIB1 indicating that a SIB1 is to be transmitted temporarily by the RAN 5, may begin to monitor for scheduling for the SIB1 transmission on Core Resource Set #0 (CORESET#0) for a duration of time before deciding to trigger / request on-demand SIB1 transmissions from the RAN 5 in the absence of SIB1 transmissions from the RAN 5 (or in the absence of detecting scheduling for SIB1 transmissions from the RAN 5 in the monitored CORESET#0).

[0114] At step S706, the RAN 5 may broadcast temporary SIB1 transmissions to the UE 3, and the UE 3 may receive those SIB1 transmission through its monitoring of the CORESET#0.

[0115] Nevertheless, at step S708, if the UE 3 has not received temporary SIB1 transmissions from the RAN 5 (or has not managed to detect the broadcasted temporary SIB1 transmissions sent at step S706), the UE 3 determines to request on-demand SIB1 transmissions from the RAN 5. For example, the UE 3 may determine that having not received (or detected) SIB1 transmissions from the RAN 5 after a specific period of time (i.e., after a specific time duration), that the UE 3 should request the RAN 5 to perform on-demand SIB1 transmissions to the UE 3.

[0116] At step S710, if the UE 3 determines that on-demand SIB1 transmissions should be requested, the UE 3 may send a WUS to the RAN 5 at step S710. That WUS may include appropriate indications to wake-up the RAN 5 and / or request on-demand SIB1 transmissions from the RAN 5.

[0117] For example, at step S710, the UE 3 may send a WUS to the RAN 5 in accordance with an UL WUS configuration that the UE 3 may have received previously (e.g., following a request for such an UL WUS configuration, automatically via the MIB it received at step S702, or in some other way) either in the NES cell 9 or another cell 9 (such as an anchor cell / non-NES cell / cell 'A').

[0118] It will be appreciated that if a UE 3 does not have any UL WUS configuration (or does not have an up-to-date UL WUS configuration), when the UE 3 determines that the periodically broadcast SIB1 transmissions from the RAN 5 will not be sufficient (e.g., may not be received in time), then the UE 3 may obtain such a UL WUS configuration on-demand by requesting such an UL WUS configuration. Then, at step S710, the UE 3 may send a WUS to the RAN 5 in accordance with an UL WUS configuration that the UE 3 requested from the RAN 5 when the UE 3 determined to request on-demand SIB1s at step S708. For example, having determined that on-demand SIB1 transmissions should be requested at step S708, the UE 3 may (not shown) send an UL WUS configuration request, or the like, to the RAN 5 to request the RAN 5 to provide an UL WUS configuration to the UE 3. The RAN 5 may then send an UL WUS configuration to the UE 3, which the UE 3 may use to send a WUS to the RAN 5 to request on-demand SIB1 transmissions.

[0119] At step S712, the RAN 5 may transmit on-demand SIB1 transmissions to the UE 3. More specifically, having received the WUS message requesting on-demand SIB1 transmissions, the RAN 5 may (optionally, not shown) transmit a DCI message (e.g., a DCI format 1_0 message scrambled with SI-RNTI) to indicate to the UE 3 appropriate resources on which to expect to receive the SIB1 transmissions. For example, the DCI message may indicate that the on-demand SIB1s are to be transmitted to the UE 3 periodically within a specific SIB1 transmission period (e.g., a period of 160 ms) from a specific start time. The specific start time may, by way of example, correspond to the time immediately following transmission of the DCI format 1_0 message. Alternatively, the specific start time may, by way of example, correspond to the end of a specified time delay window. For example, the transmission start time for the SIB1s may be delayed until the start of a next SIB1 periodicity (i.e., the start of the next 160 ms period), following the transmission of the DCI format 1_0 that indicates the SIB1 resources.

[0120] Alternatively (or additionally), the DCI message may indicate that the on-demand SIB1s are to be transmitted to the UE 3 a specific number of times. For example, the DCI format 1_0 may indicate the SIB1 transmission period is 160 ms, and that the on-demand SIB1s are to be transmitted to the UE 3 once every 40 ms i.e., the RAN 5 will transmit on-demand SIB1s to the UE 3 four times in the 160 ms SIB1 transmission period.

[0121] Alternatively, having received the WUS message requesting an on-demand SIB1 transmissions, the RAN 5 may not need to transmit a DCI message if the appropriate resources on which to expect to receive the on-demand SIB1 transmissions have already been indicated to the UE 3 by an earlier message. In one example, the appropriate resources may be indicated to the UE 3 in the WUS configuration it received from the RAN 5. In another example, the appropriate resources may be indicated to the UE 3 in an appropriate response message (not shown) sent by the RAN 5 to the UE 3 having received the WUS message to request on-demand SIB1 transmissions at step S710.

[0122] Alternatively, having received the WUS message requesting on-demand SIB1 transmissions, the RAN 5 may not need to transmit a DCI message even if the appropriate resources on which to expect to receive on-demand SIB1 transmissions has not been previously signalled to the UE 3 if a specific time window for receiving on-demand SIB1 transmissions is pre-configured (hard coded) at the UE 3. For example, the UE 3 may start to monitor for on-demand SIB1 transmissions from the RAN 5 immediately after transmitting the WUS message, and it may expect the on-demand SIB1 transmissions to be transmitted using a legacy periodicity (e.g., 160 ms) or some other new periodicity (e.g. 320 ms, 640 ms).

[0123] The specific time duration that the UE 3 monitors CORESET#0 before deciding to request on-demand SIB1 transmissions (step S708) may, by way of example only, be preconfigured at the UE 3.

[0124] Alternatively (or additionally), the specific duration that the UE 3 monitors CORESET#0 before deciding to request on-demand SIB1 transmissions (step S708) may be indicated to the UE 3 in an UL WUS configuration sent to the UE 3 by the RAN 5 prior to, within, or after the transmission of the MIB at step S702, or in response to an UL WUS configuration request.

[0125] It will be appreciated that if the specific time duration that the UE 3 monitors CORESET#0 before deciding to request on-demand SIB1 transmissions is too short, then the UE 3 may unnecessarily request on-demand SIB1 transmissions / trigger an UL WUS transmission / request an UL WUS configuration. Conversely, if the specific time duration is too long, then a problem may arise whereby the UE 3 waits for another UE in communication with the RAN 5 to request on-demand SIB1 transmissions / trigger an UL WUS transmission / request an UL WUS configuration.

[0126] The specific time duration that the UE 3 monitors CORESET#0 before deciding to request on-demand SIB1 transmissions (step S708) may therefore be configured in order to avoid these 'too short' and 'too long' scenarios. For example, optionally a minimum SIB1 monitoring duration (e.g., one or two frames) and a maximum time window for monitoring SIB1 transmissions may be defined and indicated to UEs 3 by RAN 5 over a non-NES cell 9 (e.g., Cell 'A' 9). Each UE 3 may then select a random monitoring duration from the maximum time window for monitoring CORESET#0 before deciding to request on-demand SIB1 transmissions (step S708). Beneficially, this approach means that most UEs 3 would not need to request on-demand SIB1 transmissions / trigger an UL WUS transmission / request an UL WUS configuration, and most of the UEs 3 would still see a reduction in the latency associated with receiving SIB1 transmissions from the RAN 5.

[0127] < Additional Considerations > 　　It will be appreciated that whilst the SIB1 acquisition procedures of Figs. 5 to 7 described above are particularly beneficial in the context of scenarios involving NTN RANs 5-1, they would also be beneficial if implemented in the context of scenarios involving non-NTN (or simply TN) RANs 5-2.

[0128] Additional considerations associated with the SIB1 acquisition procedures of Figs. 5 to 7 described above, and other possible adaptations that can be made to those procedures to further enhance them, will now be described.

[0129] < Determining whether there is sufficient NES cell service time for on-demand SIB1s > 　　In the context of NTNs (although not limited to NTNs), it will be appreciated that the UE 3 may be aware of when a given cell 9 is due to stop providing service to the UE 3. For example, as shown in Fig. 8, the UE 3 (which may be moving or stationary) may experience changes in the service level provided by one or more non-terrestrial space (or air) borne platforms 5C over time.

[0130] In the example shown in Fig. 8, a non-terrestrial space (or air) borne platform 5C-1 in the form of a geostationary Earth orbit (GEO) satellite is always present and available to the UE 3 (by definition) and provides a corresponding cell 9-1. Given the stability of the cell 9-1 provided by the GEO non-terrestrial space (or air) borne platform 5C-1, that cell 9-1 may be configured as an anchor cell 9 / Cell 'A' 9 / non-NES cell 9, etc.

[0131] On the other hand, one or more further non-terrestrial space (or air) borne platforms 5C-11, 5C-12 in the form of middle Earth orbit (MEO) non-terrestrial space (or air) borne platforms 5C may form part of the NTN system and may move (see arrow 'B'), which in turn causes a respective cell 9-11, 9-12 provided by each of those MEO space (or air) borne platforms 5C-11, 5C-12 to also move, thereby changing the level of coverage provided by those cells 9-11, 9-12 to the UE 3. Nevertheless, such cells 9-11, 9-12 may move relatively slowly (e.g., compared to those provided by a low Earth orbit (LEO) non-terrestrial space (or air) borne platform 5C) and may also be configured as an anchor cell 9 / Cell 'A' 9 / non-NES cell 9, etc.

[0132] Similarly, one or more further non-terrestrial space (or air) borne platforms 5C-111, 5C-112, 5C-121 in the form of LEO non-terrestrial space (or air) borne platforms 5C may also move (see arrow 'C'), which in turn causes the cells 9-111, 9-112, 9-121 provided by those space (or air) borne platforms 5C-111, 5C-112, 5C-121 respectively to also move, thereby changing the level of coverage provided by those cells 9-111, 9-112, 9-121 to the UE 3. Such cells 9-111, 9-112, 9-121 may, for example, be considered as NES cells 9.

[0133] As the service provided to the UE 3 by cells 9-11, 9-12, 9-111, 9-112, 9-121 provided by the MEO and LEO non-terrestrial space (or air) borne platforms 5C varies as described above, it may be necessary to provide appropriate adaptations to the SIB1 acquisition procedures of Figs. 5 to 7 to account for such cell coverage variations.

[0134] In one example adaptation, the UE 3 may be provided, by a RAN 5, with satellite assistance information, or the like (e.g., in a SIB19 transmission, or the like) of a non-terrestrial space (or air) borne platform (or platforms) 5C associated with the RAN 5, which may, by way of example only, include IEs such as those listed below in Table 1.

[0135] Table 1 - A table of example IEs that may be included in a SIB19 for providing NTN-specific parameters for serving cell and / or neighbour cells.

[0136] Having been provided satellite assistance information such as that described above, the UE 3 may use that information to determine / check whether the UE 3 has sufficient time to both, send a WUS to a RAN 5 to request on-demand SIB1 transmissions, and receive those on-demand SIB1 transmissions over NES cells 9 (e.g., cells 9-111, 9-112, 9-121 provided via a LEO non-terrestrial space (or air) borne platform 5C-111, 5C-121).

[0137] For example, if a UE 3 has received a SIB19, the UE 3 may use timing information provided in SIB19 indicating when a cell 9 provided via the NTN system (e.g., via a non-terrestrial space (or air) borne platform 5C) is going to stop providing service in the area it is currently serving (e.g., t-Service IE) to determine / check whether the UE 3 has sufficient time to both, send a WUS to a RAN 5 to request on-demand SIB1 transmissions (e.g., steps S508; S710), and receive those on-demand SIB1 transmissions (e.g., steps S510; S712) prior to the cell 9 stopping providing service in the area it is currently serving.

[0138] It will also be appreciated that in this scenario, to check whether the UE 3 has sufficient time to both, send a WUS to a RAN 5 to request on-demand SIB1 transmissions, and receive those on-demand SIB1 transmissions prior to the cell 9 stopping providing service in the area it is currently serving, the UE 3 may compare the timing information provided in the t-Service IE with a minimum required time parameter, or the like, indicating a minimum time required for the UE 3 to both, send a WUS to a RAN 5 to request on-demand SIB1 transmissions, and receive those on-demand SIB1 transmissions. That minimum required time parameter may, for example, be indicated to the UE 3 in an UL WUS configuration, or preconfigured at the UE 3.

[0139] It will be appreciated that the time that constitutes a 'sufficient time' to both, send a WUS to a RAN 5 to request on-demand SIB1 transmissions, and receive those on-demand SIB1 transmissions, may be indicated to the UE 3 in an UL WUS configuration that the UE 3 receives from the RAN 5, may be preconfigured at the UE 3, or may be determined by the UE 3 based on its own configuration.

[0140] < Determining whether there is sufficient anchor cell service time for UL WUS Configuration Requests > 　　Additionally, as well as determining / checking whether the UE 3 has sufficient time to both, request on-demand SIB1 transmissions (e.g., steps S508; S710), and receive those on-demand SIB1 transmissions (e.g., steps S510; S712) prior to the cell 9 stopping providing service in the area it is currently serving, the UE 3 may also be configured to check whether there is sufficient time to complete a procedure to request an UL WUS configuration (if needed), to perform an UL WUS request, and acquire SIB1.

[0141] Specifically, the UE 3 may be configured to check whether there is sufficient time to perform these operations before the end of a service time associated with an anchor cell / Cell 'A' (e.g., cell 9-11, 9-12 provided via an MEO non-terrestrial space (or air) borne platform 5C-11, 5C-12). An end of service time associated with an anchor cell 9 / Cell 'A' 9 (e.g., cell 9-11, 9-12) provided by an MEO non-terrestrial space (or air) borne platform 5C-11, 5C-12 may be indicated by the network to the UE 3, or may be left up to the UE 3 to determine.

[0142] It will be appreciated that the time that constitutes a 'sufficient time' to request an UL WUS configuration (if needed), to perform an UL WUS request, and acquire SIB1, may be indicated to the UE 3 by the RAN 5, may be preconfigured at the UE 3, or may be determined by the UE 3 based on its own configuration.

[0143] < Re-acquisition of an UL WUS Configuration for an NES Cell upon (re-)camping on an NES Cell > 　　As described above, in the case of NES cells 9 (e.g. cells 9-111, 9-112, 9-121 provided via LEO non-terrestrial space (or air) borne platforms 5C-111, 5C-112, 5C-121 respectively), service provided by those cells 9-111, 9-112, 9-121 may change, be interrupted, or terminated, as the LEO non-terrestrial space (or air) borne platforms 5C-111, 5C-112, 5C-121 move, relatively frequently. It will therefore be appreciated that the UE 3 may regularly (re-)camp onto cells 9-111, 9-112, 9-121 provided via the LEO non-terrestrial space (or air) borne platforms 5C as those non-terrestrial space (or air) borne platforms 5C-111, 5C-112, 5C-121 move.

[0144] During the (re-)camping onto one of those cells 9-111, 9-112, 9-121, the UE 3 may need to re-acquire an UL WUS configuration (even if the UE 3 has already previously been camped on a cell 9-111, 9-112, 9-121 and received an UL WUS configuration for that cell 9-111, 9-112, 9-121).

[0145] For example, despite having previously obtained an UL WUS configuration, the UL WUS configuration for a cell 9 (e.g., cell 9-112) on which the UE 3 (re-)camps may be different to the previously obtained UL WUS configuration. As such, upon (re-)camping onto the NES cell 9 (e.g., cell 9-112) the UL WUS configuration that the UE 3 has may be out-of-date / incorrect, and a new (updated / correct) UL WUS configuration may thus need to be acquired.

[0146] In one example, an UL WUS configuration provided to a UE 3 may be provided with a version indication or the like (e.g., a valueTag IE, or the like) to indicate a version of the UL WUS configuration. In this scenario, upon (re-)camping onto an NES cell 9 (e.g., cell 9-112), the UE 3 may determine whether an UL WUS configuration provided by a RAN 5 for that NES cell 9 (e.g., cell 9-112) is an updated / different version of the UL WUS configuration compared to a previously obtained UL WUS configuration stored in the memory of the UE 3. This may be determined by the UE 3, for example, by comparing the valueTag of an UL WUS configuration received from a RAN 5 with the valueTag of the UL WUS configuration stored in the memory of the UE 3. In the event that the valueTags are different, the UE 3 may replace the UL WUS configuration stored in its memory with the UL WUS configuration sent to the UE 3 by the RAN 5 after having (re-)camped onto the NES cell 9 (e.g., cell 9-112).

[0147] In another example, the UE 3 may be configured to always discard any UL WUS configuration stored in its memory (e.g., when it loses service with an NES cell 9 (e.g., cell 9-121)), and to re-acquire an UL WUS configuration after having (re-)camped onto an NES cell 9 (e.g., cell 9-112).

[0148] In another example, the UE 3 may be configured to discard any UL WUS configuration stored in its memory (e.g., when it loses service with an NES cell 9 (e.g., cell 9-121)) if that cell 9 (e.g., cell 9-121) was indicating that it was going to broadcast SIB1 to the UE 3 periodically, and then (re-)acquire an UL WUS configuration after having (re-)camped onto an NES cell 9 (e.g., cell 9-112).

[0149] In yet another example, the UE 3 may be configured to discard any UL WUS configuration stored in its memory (e.g., when it loses service with the NES cell 9 (e.g., cell 9-121) if that cell 9 (e.g., cell 9-121) was broadcasting SIB1 periodically, and then (re-)acquire the UL WUS configuration after having re-camped onto the NES cell 9 (e.g., cell 9-112).

[0150] < UL WUS Configuration and / or SIB1 Acquisition by a UE > 　　As mentioned above, the communication system 1 may be configured to additionally (or alternatively) support one or more procedures to acquire UL WUS configurations and / or SIB1 for an NES cell 9 (e.g. one of cells 9-111, 9-112, 9-121 provided via LEO non-terrestrial space (or air) borne platforms 5C-111, 5C-112, 5C-121 respectively) in the context of an NTN system.

[0151] A number of procedures to acquire UL WUS configurations and / or SIB1 will now be described, by way of example only, with reference to Figs. 9 to 11. It will be appreciated that these may be implemented in conjunction with the procedures of Figs. 4 to 7 for acquiring UL WUS configurations and / or SIB1 transmissions for an NES cell 9 over an Anchor cell 9 / non-NES cell 9 / Cell 'A' 9.

[0152] < Location-based Mechanism > 　　Fig. 9 is a simplified sequence diagram illustrating an example UL WUS configuration and / or SIB1 acquisition procedure for an NES cell 9 (e.g. one of cells 9-111, 9-112, 9-121 provided via LEO non-terrestrial space (or air) borne platforms 5C-111, 5C-112, 5C-121 respectively) over an anchor cell 9 / Cell 'A' 9.

[0153] As shown in Fig. 9, there is provided a UE 3, and a RAN 5 which provides at least one cell 9 over which the UE 3 and the RAN 5 can communicate. It will be appreciated that, in the following procedure, whilst a RAN 5 is referred to in general terms, communication performed by the RAN 5 with the UE 3 will typically be performed by the base station 5A of the RAN 5.

[0154] At step S902, the UE 3 (e.g., a GNSS-capable UE) may determine / estimate its relative distance to a non-terrestrial (or air) borne platform 5C (e.g., an LEO non-terrestrial space (or air) borne platform 5C-111, 5C-112, 5C-121) that provides an NES cell 9 (e.g. one of cells 9-111, 9-112, 9-121) and hence its relative distance to that NES cell 9. For example, the UE 3 may determine / estimate its relative distance to the non-terrestrial (or air) borne platform 5C using information pertaining to a current location of the UE 3 in conjunction with information pertaining to a trajectory of the non-terrestrial (or air) borne platform 5C that the UE 3 has received from the RAN 5 over Cell 'A' 9 (e.g., Ephemeris data related to the non-terrestrial (or air) borne platform 5C that provides an NES cell 9).

[0155] Based on the determined / estimated relative distance between the UE 3 and the non-terrestrial (or air) borne platform 5C that provides an NES cell 9 that is due to begin to provide coverage for the UE 3, the UE 3 may determine (not shown) that an NES cell 9 provided by that non-terrestrial (or air) borne platform 5C is due to serve the UE's location in the future, and the UE 3 may acquire an UL WUS configuration and / or SIB1 for that NES cell 9 over the anchor cell 9 / Cell 'A' 9 to allow the UE 3 to communicate over the NES cell 9.

[0156] In Fig. 9 three possible mechanisms are shown by which the UE 3 may acquire an UL WUS configuration and / or SIB1 for that NES cell 9 over the anchor cell 9 / Cell 'A' 9 to allow the UE 3 to communicate over the NES cell 9.

[0157] In a first approach (option #1), at step S904a, the UE 3 may monitor for a SIB (or the like) broadcast by the RAN 5 over the anchor cell 9 / Cell 'A' 9 that includes, for example, an UL WUS configuration for the NES cell 9 that may be used by the UE 3 to trigger on-demand SIB1 transmissions for the NES cell 9 over the NES cell 9. Additionally (or alternatively) the SIB (or the like) broadcast by the RAN 5 over the anchor cell 9 / Cell 'A' 9 at step S904a may include the SIB1 for the NES cell 9.

[0158] In a second approach (option #2), at step S904b, the UE 3 may send an UL WUS configuration request message, or the like (e.g., a SIB request message), to the RAN 5 over the anchor cell 9 / Cell 'A' 9 to request provision of an UL WUS configuration for the NES cell 9 (if provided in an on-demand manner). At step S906b, the RAN 5 may then send, in response to the request sent at step S904b, an UL WUS configuration for the NES cell 9 that may be used by the UE 3 to trigger on-demand SIB1 transmissions for the NES cell 9 over the NES cell 9.

[0159] In a third approach (option #3), at step S904c, the UE 3 may send an appropriate message to the RAN 5 (e.g., a SIB request message) over the anchor cell 9 / Cell 'A' 9 to request the RAN 5 to provide SIB1 for the NES cell 9 to the UE 3 over the anchor cell / Cell 'A' (if provided in an on-demand manner). At step S906c, the RAN 5 may then send, in response to the request sent at step S904c, SIB1 for the NES cell 9.

[0160] It will be appreciated that where the SIB1 for the NES cell 9 is provided to the UE 3 over the anchor cell 9 / Cell 'A' 9, the anchor cell 9 / Cell 'A' 9 may need to indicate, to the UE 3, a maximum duration between the moment when the UE 3 acquires SIB1 for the NES cell 9 from the anchor cell 9 / Cell 'A' 9, and the moment when the UE 3 uses that SIB1 e.g., to access the NES cell 9. In this way, the UE 3 is aware of a 'validity duration' of the SIB1 for the NES cell 9 that it acquires over the anchor cell 9 / Cell 'A' 9.

[0161] < Time-based Mechanism > 　　Fig. 10 is a simplified sequence diagram illustrating another example UL WUS configuration and / or SIB1 acquisition procedure for an NES cell 9 (e.g. one of cells 9-111, 9-112, 9-121 provided via LEO non-terrestrial space (or air) borne platforms 5C-111, 5C-112, 5C-121 respectively) over an anchor cell 9 / Cell 'A' 9.

[0162] As shown in Fig. 10, there is provided a UE 3, and a RAN 5 which provides at least one cell 9 over which the UE 3 and the RAN 5 can communicate. It will be appreciated that, in the following procedure, whilst a RAN 5 is referred to in general terms, communication performed by the RAN 5 with the UE 3 will typically be performed by the base station 5A of the RAN 5.

[0163] At step S1002, the UE 3 may determine / estimate (or the UE 3 may know) a time at which a non-terrestrial (or air) borne platform 5C (e.g., an LEO non-terrestrial space (or air) borne platform 5C-111, 5C-112, 5C-121) that provides an NES cell 9 (e.g. one of cells 9-111, 9-112, 9-121) will begin to provide coverage for the UE 3. For example, the UE 3 may receive appropriate timing information pertaining to neighbouring non-terrestrial (or air) borne platforms 5C and when NES cell 9 provided by RAN nodes 5A of those neighbouring non-terrestrial (or air) borne platform 5C will be able to provide service to the UE 3 (e.g., via a t-Start IE, or the like in an appropriate SIB transmission).

[0164] Based on the determined / estimated (or known) time at which a non-terrestrial (or air) borne platform 5C whose base station provides an NES cell 9 will begin to provide coverage for the UE 3, the UE 3 may acquire an UL WUS configuration and / or SIB1 for that NES cell 9 over the anchor cell 9 / Cell 'A' 9 to allow the UE 3 to communicate over the NES cell 9 within a given time window (e.g., in a given time window prior to when the non-terrestrial (or air) borne platform 5C whose base station provides an NES cell 9 will begin to provide coverage for the UE 3.

[0165] In Fig. 10, three possible mechanisms are shown by which the UE may acquire an UL WUS configuration and / or SIB1 for that NES cell 9 over the anchor cell 9 / Cell 'A' 9 to allow the UE 3 to communicate over the NES cell 9.

[0166] In a first approach (option #1), at step S1004a, the UE 3 may monitor for a SIB (or the like) broadcast by the RAN 5 over the anchor cell 9 / Cell 'A' 9 that includes, for example, an UL WUS configuration for the NES cell 9 that may be used by the UE 3 to trigger on-demand SIB1 transmissions for the NES cell 9 over the NES cell 9. Additionally, the SIB (or the like) broadcast by the RAN 5 over the anchor cell 9 / Cell 'A' 9 at step S1004a may also optionally include the SIB1 for the NES cell 9.

[0167] In a second approach (option #2), at step S1004b, the UE 3 may send an UL WUS configuration request message, or the like (e.g., a SIB request message), to the RAN 5 over the anchor cell 9 / Cell 'A' 9 to request provision of an UL WUS configuration for the NES cell 9 (if provided in an on-demand manner). At step S1006b, the RAN 5 may then send, in response to the request sent at step S1004b, an UL WUS configuration for the NES cell 9 that may be used by the UE 3 to trigger on-demand SIB1 transmissions for the NES cell 9 over the NES cell 9.

[0168] In a third approach (option #3), at step S1004c, the UE 3 may send an appropriate message to the RAN 5 (e.g., a SIB request message) over the anchor cell 9 / Cell 'A' 9 to request the RAN 5 to send a SIB1 for the NES cell 9 to the UE 3 over the anchor cell 9 / Cell 'A' 9 (if provided in an on-demand manner). At step S1006c, the RAN 5 may then send, in response to the request sent at step S1004c, SIB1 for the NES cell 9.

[0169] It will be appreciated that where the SIB1 for the NES cell 9 is provided to the UE 3 over the anchor cell 9 / Cell 'A' 9, the anchor cell 9 / Cell 'A' 9 may need to indicate, to the UE 3, a maximum duration between the moment when the UE 3 acquires SIB1 for the NES cell 9 from the anchor cell 9 / Cell 'A' 9, and the moment when the UE 3 uses that SIB1 e.g., to access the NES cell 9. In this way, the UE 3 is aware of a 'validity duration' of the SIB1 for the NES cell 9 that it acquires over the anchor cell 9 / Cell 'A' 9.

[0170] < RSRP-based Mechanism > 　　Whilst the location-based mechanism of Fig. 9 and the time-based mechanism of Fig. 10 may be particularly beneficial in the context of NTN systems for acquiring UL WUS configurations and SIB1s for NES cell, it will nevertheless be appreciated that other mechanism may alternatively be used instead of, or in combination with, the mechanisms of Figs. 9 and 10.

[0171] Fig. 11 is a simplified sequence diagram illustrating an alternatively UL WUS configuration and / or SIB1 acquisition procedure for an NES cell 9 (e.g. one of cells 9-111, 9-112, 9-121 provided via LEO non-terrestrial space (or air) borne platforms 5C-111, 5C-112, 5C-121 respectively) over an anchor cell 9 / Cell 'A' 9.

[0172] As shown in Fig. 11, there is provided a UE 3, and a RAN 5 which provides at least one cell 9 over which the UE 3 and the RAN 5 can communicate. It will be appreciated that, in the following procedure, whilst a RAN 5 is referred to in general terms, communication performed by the RAN 5 with the UE 3 will typically be performed by the base station 5A of the RAN 5.

[0173] At step S1102, the UE 3 may determine if an RSRP value associated with an NES cell 9 (e.g. one of cells 9-111, 9-112, 9-121 provided via LEO non-terrestrial space (or air) borne platforms 5C-111, 5C-112, 5C-121 respectively) indicates that the NES cell 9 in question is suitable (or the best cell) for use by the UE 3. For example, the UE 3 may measure an RSRP value associated with an NES cell 9 during an appropriate cell selection / reselection procedure to allow the UE 3 to select / reselect the NES cell 9 for use in communication with the RAN 5. The UE 3 may then compare that measured RSRP value with a (pre)configured RSRP threshold value. In the event that the measured RSRP value for the NES cell 9 meets or exceeds a (pre)configured RSRP threshold value the UE 3 may acquire an UL WUS configuration and / or SIB1 for that NES cell 9 over the anchor cell 9 / Cell 'A' 9 to allow the UE 3 to communicate over the NES cell 9.

[0174] In Fig. 11, three possible mechanisms are shown by which the UE 3 may acquire an UL WUS configuration and / or SIB1 for that NES cell 9 over the anchor cell 9 / Cell 'A' 9 to allow the UE 3 to communicate over the NES cell 9.

[0175] In a first approach (option #1), at step S1104a, the UE 3 may monitor for a SIB (or the like) broadcast by the RAN 5 over the anchor cell 9 / Cell 'A' 9 that includes, for example, an UL WUS configuration for the NES cell 9 that may be used by the UE 3 to trigger on-demand SIB1 transmissions for the NES cell 9 over the NES cell 9. Additionally, the SIB (or the like) broadcast by the RAN 5 over the anchor cell 9 / Cell 'A' 9 at step S1104a may also optionally include the SIB1 for the NES cell 9.

[0176] In a second approach (option #2), at step S1104b, the UE 3 may send an UL WUS configuration request message, or the like (e.g., a SIB request message), to the RAN 5 over the anchor cell 9 / Cell 'A' 9 to request provision of an UL WUS configuration for the NES cell 9 (if provided in an on-demand manner). At step S1106b, the RAN 5 may then send, in response to the request sent at step S1104b, an UL WUS configuration for the NES cell 9 that may be used by the UE 3 to trigger on-demand SIB1 transmissions for the NES cell 9 over the NES cell 9.

[0177] In a third approach (option #3), at step S1104c, the UE 3 may send an appropriate message to the RAN 5 (e.g., a SIB request message) over the anchor cell 9 / Cell 'A' 9 to request the RAN 5 to send a SIB1 for the NES cell 9 to the UE 3 over the anchor cell 9 / Cell 'A' 9 (if provided in an on-demand manner). At step S1106c, the RAN 5 may then send, in response to the request sent at step S1104c, SIB1 for the NES cell 9.

[0178] It will be appreciated that where the SIB1 for the NES cell 9 is provided to the UE 3 over the anchor cell 9 / Cell 'A' 9, the anchor cell 9 / Cell 'A' 9 may need to indicate, to the UE 3, a maximum duration between the moment when the UE 3 acquires SIB1 for the NES cell 9 from the anchor cell 9 / Cell 'A' 9, and the moment when the UE 3 uses that SIB1 e.g., to access the NES cell 9. In this way, the UE 3 is aware of a 'validity duration' of the SIB1 for the NES cell 9 that it acquires over the anchor cell 9 / Cell 'A' 9.

[0179] It will also be appreciated that the location-based, time-based, and / or RSRP-based mechanisms for acquiring UL WUS configurations and / or SIB1s for NES cells 9 over an anchor cell 9 / Cell 'A' 9 as described above with reference to Figs. 9 to 11, may be used by (implemented by) the UE 3 singularly or in combination with one another.

[0180] < Devices of the Communication System > 　　< User Equipment > 　　Fig. 12 is a schematic block diagram illustrating the main components of a UE 3 as shown in Fig. 1.

[0181] As shown, the UE 3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a RAN 5 via one or more antennas 33 (e.g., comprising one or more antenna elements). The UE 3 has a controller 37 to control the operation of the UE 3. The controller 37 is associated with a memory 39 and is coupled to the transceiver circuit 31. Although not necessarily required for its operation, the UE 3 might, of course, have all the usual functionality of a conventional UE (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.

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

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

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

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

[0186] < Base Station (non-distributed) > 　　Fig. 13 is a schematic block diagram illustrating the main components of a non-distributed base station 5A for the communication system 1 shown in Fig. 1. As shown, the base station 5A has a transceiver circuit 51 for transmitting signals to and for receiving signals from the communication devices (such as UEs 3) via one or more antennas 53 (e.g., a single or multi-panel antenna array / massive antenna), and a core network interface 55 (e.g., comprising the N2, N3 and other reference points / interfaces) for transmitting signals to and for receiving signals from network nodes in the core network 7. Although not shown, the base station 5A may also be coupled to other base stations 5A via an appropriate interface (e.g., the so-called 'Xn' interface in NR). The base station 5A has a controller 57 to control the operation of the base station 5A. 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 base station 5A by, in this example, program instructions or software instructions stored within memory 59.

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

[0188] The communication control module 63 is operable to control the communication between the base station 5A and UEs 3 and other network entities that are connected to the base station 5A. 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 handling 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-static signalling (e.g., CSI-RS, SSBs etc.). The communication control module 63 is also responsible, for example, for determining and scheduling the resources to be used by the UE 3 for receiving in DL / transmitting in UL, for configuring slots / symbols appropriately (e.g., for UL, DL, flexible, full duplex communication, or the like), for configuring one or more bandwidth parts for the UE 3, and for providing related configuration signalling to the UE 3.

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

[0190] The communication control module 63 is configured, in particular, to control the base station's communications, where applicable, in accordance with any of the methods described herein.

[0191] < Base Station (distributed) > 　　Fig. 14 is a simplified block schematic illustrating the main components of a distributed type of base station 5A for implementation in the communication system 1 of Fig. 1. As shown, the base station 5A includes a central unit (base station CU) 5ACUand a distributed unit (base station DU) 5ADU(although it may include other base station DUs 5ADUas described above). Each unit 5ACU, 5ADUincludes respective transceiver circuitry 51c, 51d.

[0192] The transceiver circuitry 51d of the distributed unit 5ADUis operable to transmit signals to and to receive signals from UEs 3 via an air interface 53d and one or more antennas and is also operable to transmit signals to and to receive signals from the central unit 5ACUvia an interface, for example the distributed unit 5ADUside of an F1 interface (which may be provided over a satellite radio interface).

[0193] The transceiver circuitry 51c of the central unit 5ACUis operable to transmit signals to and to receive signals from functions of the core network 7 and / or other base stations 5A via a network interface 55c. The network interface typically includes an N2 and / or N3 interfaces for communicating with the core network 7 and a base station to base station (e.g., Xn) interface for communicating with other base stations 5A. The transceiver circuitry 51c of the central unit 5ACUis also operable to transmit signals to and to receive signals from one or more distributed units 5ADU, for example the central unit 5ACUside of the F1 interface provided.

[0194] Each unit 5ACU, 5ADUincludes a respective controller 57c, 57d which controls the operation of the corresponding transceiver circuitry 51c, 51d in accordance with software stored in the respective memories 59c and 59d of the central unit 5ACUand the distributed unit 5ADU. The software of each unit may be pre-installed in the memory 59c, 59d and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The software of each unit includes, among other things, a respective operating system 61c, 61d, and a respective communication control module 63c, 63d.

[0195] Each communication control module 63c, 63d is operable to control the communication of its corresponding unit 5ACU, 5ADUincluding the communication from one unit to the other. The communication control module 63d of the distributed unit 5ADUcontrols communication between the distributed unit 5ADUand the UEs 3, and the communication control module 63c of the central unit 5ACUcontrols communication between the central unit 5ACUand other network entities that are connected to the distributed type of base station 5A.

[0196] The communication control modules 63c, 63d also respectively control the part played by the central unit 5ACUand distributed unit 5ADUin the flow of uplink and downlink user traffic and control data to be received from and transmitted to the communications devices served by the base station 5A including, for example, control data for managing operation of the UEs 3. Each communication control module 63c, 63d is responsible, for example, for controlling the respective part played by the central unit 5ACUand distributed unit 5ADUin 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). Each communication control module 63c, 63d is responsible, for example, for controlling the respective part played by the central unit 5ACUand distributed unit 5ADUin the overall handling 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-static signalling (e.g., CSI-RS, SSBs etc.). Each communication control module 63c, 63d is responsible, for example, for controlling the respective part played by the central unit 5ACUand distributed unit 5ADUin determining and scheduling the resources to be used by the UE 3 for receiving in DL / transmitting in UL, for configuring slots / symbols appropriately (e.g., for UL, DL, flexible, full duplex communication, or the like), for configuring one or more bandwidth parts for the UE 3, and for providing related configuration signalling to the UE 3.

[0197] It will be appreciated that each communication control module 63c, 63d may include a number of sub-modules (or 'layers') to support specific functionalities supported by the by the central unit 5ACUand distributed unit 5ADU. For example, a communications PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an SDAP sub-module, an IP sub-module, an RRC sub-module, etc may be distributed between the central unit 5ACUand distributed unit 5ADUappropriately depending on where the functional split is configured between the central unit 5ACUand distributed unit 5ADU.

[0198] Each communication control module 63c, 63d is configured, in particular, to control the respective communications of the central unit 5ACUand distributed unit 5ADU, where applicable, in accordance with any of the methods described herein.

[0199] < 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 concepts embodied therein.

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

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

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

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

[0204] The User Equipment (or "UE," "mobile station," "mobile device" or "wireless device") in the present disclosure is an entity connected to a network via a wireless interface. It should be noted that the present disclosure is not limited to a dedicated communication device and can be applied to any device having a communication function as explained in the following paragraphs.

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

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

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

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

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

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

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

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

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

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

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

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

[0217] Table 2

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

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

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

[0221] This application is based upon and claims the benefit of priority from UK patent application No. 2416421.2, filed on November 7, 2024, the disclosure of which is incorporated herein in its entirety by reference.

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

[0223] For example, the whole or part of the example embodiments disclosed above can be described as, but not limited to, the following supplementary notes. (Supplementary note 1) 　　A method performed by a User Equipment, UE, the method comprising: 　　receiving, from a network node, Master Information Block, MIB, comprising first information indicating whether System Information Block 1, SIB1, is to be transmitted periodically, temporarily, or on an on-demand basis; and 　　receiving the SIB1 from the network node. (Supplementary note 2) 　　The method of supplementary note 1, wherein the first information indicates the SIB1 is to be transmitted periodically, and the MIB further comprises second information indicating a periodicity of the SIB1. (Supplementary note 3) 　　The method of supplementary note 1 or 2, further comprising: 　　in response to determining that the first information indicates the SIB1 is to be transmitted periodically, 　　listening for transmission of the SIB1; and 　　ignoring any Uplink, UL, wake-up signal, WUS, configuration for configuring the terminal device for transmitting an UL WUS to request a transmission of an on-demand SIB1 in a Network Energy Saving, NES, cell. (Supplementary note 4) 　　The method of supplementary note 1, further comprising: 　　in response to determining that the first information indicates the SIB1 is to be transmitted temporarily, starting to monitor for scheduling for transmission of the SIB1 on Core Resource Set #0, CORESET#0; and 　　ignoring any UL WUS configuration for transmitting an UL WUS to request a transmission of an on-demand SIB1. (Supplementary note 5) 　　The method of supplementary note 4, further comprising: 　　in response to determining that the SIB1 has not been received for a first time period, requesting a transmission of an on-demand SIB1 to the network device. (Supplementary note 6) 　　The method of supplementary note 5, wherein the terminal device requests the transmission of the on-demand SIB1 using a WUS. (Supplementary note 7) 　　The method of supplementary note 5, further comprising: 　　receiving a Downlink Control Information, DCI, format indicating resources to expect reception of SIB1 transmission. (Supplementary note 8) 　　A method performed by a user equipment, UE, the method comprising: 　　acquiring, from a first cell or a second cell, at least either an Uplink, UL, wake-up signal, WUS, configuration or a System Information Block 1, SIB1, wherein, 　　the first cell is a non-terrestrial networks, NTN, network-energy-saving, NES, cell, and the second cell is a non-NES cell, 　　the WUS and the SIB1 are for the first cell; and 　　connecting to the first cell after acquiring at least either the UL WUS configuration or the SIB1. (Supplementary note 9) 　　The method of supplementary note 8, further comprising: 　　determining a distance between the UE and a platform that provides the first cell or the second cell, wherein the platform is a non-terrestrial borne platform or an air borne platform. (Supplementary note 10) 　　The method of supplementary note 9, wherein the UE determines the distance based on a current location of the UE in conjunction with information pertaining to a trajectory of the platform that the UE has received from a radio access network node over the second cell. (Supplementary note 11) 　　The method of supplementary note 10, wherein the information is ephemeris data related to the platform. (Supplementary note 12) 　　The method of supplementary note 9, further comprising: 　　determining, based on the distance, that the first cell is due to serve a location of the UE in future, wherein the acquiring the UL-WUS configuration or the SIB1 is based on the determining that the first cell is due to serve a location of the UE in future. (Supplementary note 13) 　　The method of supplementary note 8, wherein the acquiring at least either the UL-WUS configuration or the SIB1 comprises: 　　monitoring for a SIB being broadcast by a radio access network node over the first cell or the second cell. (Supplementary note 14) 　　The method of supplementary note 13, wherein 　　the SIB includes at least either: 　　an UL WUS configuration for the first cell that may be used by the UE to trigger an on-demand SIB transmission for the first cell over the first cell, or 　　the SIB1 for the first cell. (Supplementary note 15) 　　The method of supplementary note 8, wherein the acquiring at least either the UL-WUS configuration or the SIB1 comprises: 　　sending an UL WUS configuration request message to a radio access network node over the first cell or the second cell. (Supplementary note 16) 　　The method of supplementary note 15, wherein the acquiring at least either the UL-WUS configuration or the SIB1 further comprises: 　　receiving an UL WUS configuration for the first cell that may be used by the UE to trigger an on-demand SIB transmission for the first cell over the first cell. (Supplementary note 17) 　　The method of supplementary note 8, wherein the acquiring at least either the UL-WUS configuration or the SIB1 comprises: 　　sending a message to a radio access network node over the first cell or the second cell to request the radio access network node to provide SIB1 for the first cell to the UE over the first cell or the second cell. (Supplementary note 18) 　　The method of supplementary note 17, wherein the acquiring at least either the UL-WUS configuration or the SIB1 further comprises: 　　receiving, from the radio access network node, the SIB1 for the first cell. (Supplementary note 19) 　　A method performed by a network node, the method comprising: 　　transmitting, to a User Equipment, UE, Master Information Block, MIB, comprising first information indicating whether System Information Block 1, SIB1, is to be transmitted periodically, temporarily, or on an on-demand basis; and 　　transmitting the SIB1 to the UE. (Supplementary note 20) 　　A User Equipment, UE, comprising: 　　means for receiving, from a network node, Master Information Block, MIB, comprising first information indicating whether System Information Block 1, SIB1, is to be transmitted periodically, temporarily, or on an on-demand basis; and 　　means for receiving the SIB1 from the network node. (Supplementary note 21) 　　A user equipment, UE, comprising: 　　means for acquiring, from a first cell or a second cell, at least either an Uplink, UL, wake-up signal, WUS, configuration or a System Information Block 1, SIB1, wherein, 　　the first cell is a non-terrestrial networks, NTN, network-energy-saving, NES, cell, and the second cell is a non-NES cell, 　　the WUS and the SIB1 are for the first cell; and 　　means for connecting to the first cell after acquiring at least either the UL WUS configuration or the SIB1.

[0224] 1　　communication system 3, 3-1, 3-2, 3-3　　UEs 5, 5-1, 5-2　　radio access network (RAN), NTN RAN 5A, 5ACU, 5ADU　　base station 5B　　gateway 5C　　borne platform 7　　core network 9, 9-1, 9-2　　cells 10　　control plane functions (CPFs) 10-1　　Access and Mobility Management Functions (AMFs) 10-2　　session management function (SMF) 11　　user plane functions (UPFs) 20　　external data network 31, 51, 51c, 51d　　transceiver circuit 33, 53　　antenna 35　　user interface 37, 57, 57c, 57d　　controller 39, 59, 59c, 59d　　memory 41, 61, 51c, 61d　　operating system 43, 63, 63c, 63d　　communications control module 55　　core network interface 53d　　air interface 55c　　network interface

Claims

1. A method performed by a User Equipment, UE, the method comprising: 　　receiving, from a network node, Master Information Block, MIB, comprising first information indicating whether System Information Block 1, SIB1, is to be transmitted periodically, temporarily, or on an on-demand basis; and 　　receiving the SIB1 from the network node.

2. The method according to claim 1, wherein the first information indicates the SIB1 is to be transmitted periodically, and the MIB further comprises second information indicating a periodicity of the SIB1.

3. The method according to claim 1 or 2, further comprising: 　　in response to determining that the first information indicates the SIB1 is to be transmitted periodically, 　　listening for transmission of the SIB1; and 　　ignoring any Uplink, UL, wake-up signal, WUS, configuration for configuring the terminal device for transmitting an UL WUS to request a transmission of an on-demand SIB1 in a Network Energy Saving, NES, cell.

4. The method according to claim 1, further comprising: 　　in response to determining that the first information indicates the SIB1 is to be transmitted temporarily, starting to monitor for scheduling for transmission of the SIB1 on Core Resource Set #0, CORESET#0; and 　　ignoring any UL WUS configuration for transmitting an UL WUS to request a transmission of an on-demand SIB1.

5. The method according to claim 4, further comprising: 　　in response to determining that the SIB1 has not been received for a first time period, requesting a transmission of an on-demand SIB1 to the network device.

6. The method according to claim 5, wherein the terminal device requests the transmission of the on-demand SIB1 using a WUS.

7. The method according to claim 5, further comprising: 　　receiving a Downlink Control Information, DCI, format indicating resources to expect reception of SIB1 transmission.

8. A method performed by a user equipment, UE, the method comprising: 　　acquiring, from a first cell or a second cell, at least either an Uplink, UL, wake-up signal, WUS, configuration or a System Information Block 1, SIB1, wherein, 　　the first cell is a non-terrestrial networks, NTN, network-energy-saving, NES, cell, and the second cell is a non-NES cell, 　　the WUS and the SIB1 are for the first cell; and 　　connecting to the first cell after acquiring at least either the UL WUS configuration or the SIB1.

9. The method according to claim 8, further comprising: 　　determining a distance between the UE and a platform that provides the first cell or the second cell, wherein the platform is a non-terrestrial borne platform or an air borne platform.

10. The method according to claim 9, wherein the UE determines the distance based on a current location of the UE in conjunction with information pertaining to a trajectory of the platform that the UE has received from a radio access network node over the second cell.

11. The method according to claim 10, wherein the information is ephemeris data related to the platform.

12. The method according to claim 9, further comprising: 　　determining, based on the distance, that the first cell is due to serve a location of the UE in future, wherein the acquiring the UL-WUS configuration or the SIB1 is based on the determining that the first cell is due to serve a location of the UE in future.

13. The method according to claim 8, wherein the acquiring at least either the UL-WUS configuration or the SIB1 comprises: 　　monitoring for a SIB being broadcast by a radio access network node over the first cell or the second cell.

14. The method according to claim 13, wherein 　　the SIB includes at least either: 　　an UL WUS configuration for the first cell that may be used by the UE to trigger an on-demand SIB transmission for the first cell over the first cell, or 　　the SIB1 for the first cell.

15. The method according to claim 8, wherein the acquiring at least either the UL-WUS configuration or the SIB1 comprises: 　　sending an UL WUS configuration request message to a radio access network node over the first cell or the second cell.

16. The method according to claim 15, wherein the acquiring at least either the UL-WUS configuration or the SIB1 further comprises: 　　receiving an UL WUS configuration for the first cell that may be used by the UE to trigger an on-demand SIB transmission for the first cell over the first cell.

17. The method according to claim 8, wherein the acquiring at least either the UL-WUS configuration or the SIB1 comprises: 　　sending a message to a radio access network node over the first cell or the second cell to request the radio access network node to provide SIB1 for the first cell to the UE over the first cell or the second cell.

18. The method according to claim 17, wherein the acquiring at least either the UL-WUS configuration or the SIB1 further comprises: 　　receiving, from the radio access network node, the SIB1 for the first cell.

19. A method performed by a network node, the method comprising: 　　transmitting, to a User Equipment, UE, Master Information Block, MIB, comprising first information indicating whether System Information Block 1, SIB1, is to be transmitted periodically, temporarily, or on an on-demand basis; and 　　transmitting the SIB1 to the UE.

20. A User Equipment, UE, comprising: 　　means for receiving, from a network node, Master Information Block, MIB, comprising first information indicating whether System Information Block 1, SIB1, is to be transmitted periodically, temporarily, or on an on-demand basis; and 　　means for receiving the SIB1 from the network node.

21. A user equipment, UE, comprising: 　　means for acquiring, from a first cell or a second cell, at least either an Uplink, UL, wake-up signal, WUS, configuration or a System Information Block 1, SIB1, wherein, 　　the first cell is a non-terrestrial networks, NTN, network-energy-saving, NES, cell, and the second cell is a non-NES cell, 　　the WUS and the SIB1 are for the first cell; and 　　means for connecting to the first cell after acquiring at least either the UL WUS configuration or the SIB1.

Images