Method performed by user equipment and user equipment

Abstract

A method performed by a user equipment (UE) includes performing Global Navigation Satellite System (GNSS) acquisition; resetting configuration regarding time alignment based on the performing GNSS acquisition; and performing uplink transmission using the configuration regarding time alignment.

Description

METHOD PERFORMED BY USER EQUIPMENT 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 LTE-Advanced, Next Generation or 5G networks, future generations, and beyond). The disclosure has particular but not exclusive relevance to improvements relating to Global Navigation Satellite System (GNSS) operation in particular in the context of (but not limited to) estimation of timing adjustment values in Non-Terrestrial Networks (NTN).

[0002] Earlier developments of the 3GPP standards were referred to as the Long-Term Evolution (LTE) of Evolved Packet Core (EPC) network and Evolved UMTS Terrestrial Radio Access Network (E-UTRAN), also commonly referred as '4G'. More recently, the term '5G' and 'new radio' (NR) has started to be used to refer to an evolving communication technology that is expected to support a variety of applications and services. Various details of 5G networks are described in, for example, NPL (Non Patent Literature) 1. 3GPP intends to support 5G by way of the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and the 3GPP NextGen core network.

[0003] Under the 3GPP standards, a NodeB (or an eNB in LTE, and gNB in 5G) is the radio access network (RAN) node (or simply 'access node', 'access network node' or 'base station') via which communication devices (user equipment or "UE" 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 simply RAN) 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 base stations. 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 communications network for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory. A UE may, for example be anything from a conventional cellular based telephone (e.g., a smartphone or the like) to an Internet of Things (IoT) device 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, for example, be in the form of automated equipment that may operate without requiring human supervision or interaction.

[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] The core network includes a number of communication entities for providing different functions for supporting communication.

[0007] For example, in 4G the core network entities include, amongst other things, a mobility management entity (MME), a serving gateway (SGW or S-GW), a packet data network (PDN) gateway (PGW or P-GW), etc. The MME manages general mobility aspects of the UE and ensures that connectivity is maintained with the UE as it is moving within the geographical area covered by the communication system. The MME also handles control-plane signalling for the UE and manages the various bearers associated with the UE (e.g. such as an Evolved Packet System (EPS) bearer and / or a radio bearer), for example by controlling the S-GW and the P-GW (and / or possibly other network nodes) via which such bearers are provided. The S-GW provides a connection between the UE and the core network (via the base station) for sending and receiving user plane data over an associated communication bearer (e.g. an EPS bearer). The communication bearer normally terminates at the P-GW, although it is often complemented by an external bearer as well (for example, another EPS bearer and / or the like) between the P-GW and a communication endpoint outside the core network (e.g. in an external network). It will be appreciated that the functionalities of the S-GW and the P-GW could be implemented in a single gateway element.

[0008] In 5G, the 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 S-GW and 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. The LMF manages the support of different location services for UEs whose location is unknown and needs to be located.

[0009] 3GPP is also working with the satellite communication industry to specify an integrated satellite and terrestrial network infrastructure in the context of 5G. 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.

[0010] Currently NTN has two main aspects NTN-IoT and NTN-NR with each being targeted at a different set of use cases. NTN-IoT is aimed at expanding the reach of IoT use cases with the intention of enabling more global coverage over land, sea, and air. It operates at both GEO and LEO altitudes, but current services mostly operate at GEO. NTN-NR, on the other hand, is aimed at directly linking UEs such as smartphones, and other devices such as reduced capability (RedCap) devices, to non-terrestrial services. It is envisaged that NR-NTN will operate at the LEO altitude and enable low data services, voice, and messaging for various use cases.

[0011] NPL 2 is a study on New Radio to support such on-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 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 network scalability through the provision of efficient multicast / broadcast resources for data delivery towards the network edges or even directly to the user equipment. Non-Terrestrial Network 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 directly 3GPP UEs; 　　- A service link which refers to the radio link between the user equipment 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.

[0012] There are a number of different architectures that may be used for providing NTN access. One such architecture is a 'regenerative' access network architecture (sometimes referred to as 'regenerative satellite', 'regenerative payload', or 'regenerative mode') in which the non-terrestrial platform (e.g., satellite) performs some on board processing of the payload being communicated between the UE and the core network. Specifically, in a regenerative architecture, at least some of the base station functionality (e.g., at least the functionality of the DU of a distributed base station, or possibly all the base station functionality) is provided on the non-terrestrial platform. Other regenerative mode architectures are also possible, for example architectures in which at least some of the core network functionality is implemented on the non-terrestrial platform.

[0013] Another possible architecture is a 'transparent' access network architecture (sometimes referred to as 'transparent satellite', 'transparent mode', or 'transparent payload') in which the base station is terrestrially located and sends and receives communications respectively destined for, and originating from, UEs via a terrestrially located gateway and via a non-terrestrial platform that has no base station functionality. The non-terrestrial platform relays these communications to and from the UEs transparently without on-board processing them in effect acting as a so-called 'bent-pipe'. In this architecture, both the service link and the feeder link effectively function as part of the air interface between the base station and the UEs.

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

[0015] The coverage in 5G is primarily beam-based rather than cell based. There is no cell-level reference channel from where the coverage of the cell could be measured. Instead, each cell has one or more so-called synchronisation signal / physical broadcast channel (PBCH) block (SSB) beams (which are different to satellite or NTN beams). SSB beams form a matrix of beams covering an entire cell area. Each SSB beam carries an SSB comprising a primary synchronisation signal (PSS), secondary synchronisation signal (SSS), and physical broadcast channel (PBCH).

[0016] The UE searches for and performs measurements on the SSB beams (e.g. of the synchronisation signal reference signal received power, 'SS-RSRP', synchronisation signal reference signal received quality, 'SS-RSRQ', and / or the synchronisation signal to noise or interference ratio, 'SS-SINR'). The UE maintains a set of candidate beams which may contain beams from multiple cells. A PCI and beam ID (or SSB index) thus distinguish the SSB beams from each other. Effectively, therefore, the SSB beams are like mini cells which may be within a larger cell. Once a UE has detected and selected a cell (and / or an SSB beam in the case of 5G) it may attempt to access that cell and / or SSB beam using an initial RRC connection setup procedure comprising a random access procedure.

[0017] Many aspects of modern cellular communication systems require sophisticated timing synchronisation mechanisms between the network and the UE. Such timing relationships have a significant impact on both the network and the UE. Historically, mechanisms for managing timing relationships were focussed on communications within terrestrial based cells, in which distance from the UE to the base station, and hence the propagation delays, are relatively small compared to NTN based cells. Propagation delays in terrestrial based networks are, for example, typically less than a millisecond whereas the propagation delays in NTN cells can be significantly longer, ranging from several milliseconds to hundreds of milliseconds.

[0018] To achieve timing synchronisation, any timing misalignment between signals from different UEs received at the base station should fall within the length of a cyclic prefix to avoid inter-carrier interference (ICI) and inter-symbol interference (ISI). To ensure such alignment, mechanisms are employed by which the network is able to enforce implementation of an appropriate, UE specific, transmit timing advance (TA) at each UE. Each TA is, in effect, a negative offset between the start of a given downlink slot as received at the corresponding UE following any propagation delay, and the start of the same slot in the uplink.

[0019] In NTN based cells, therefore, each UE typically needs to apply a very large timing advance (TA) value to compensate for the round-trip time (RTT) between the UE 3 and the base station.

[0020] NPL 1: NGMN 5G WHITE PAPER Version 1.0, Next Generation Mobile Networks (NGMN) Alliance NPL 2: 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Study on New Radio (NR) to support non-terrestrial networks (Release 15), 3GPP TR 38.811 V15.4.0 (2020-09)

[0021] Currently timing alignment for NTN relies on the UE performing a level of pre-compensation to take account of the time delay (and frequency shift) arising from the UE's distance to the NTN platform and the relative movement between the UE and the NTN platform. The UE calculates the needed compensation based on ephemeris data for the serving NTN platform and its own location, which the UE may determine based on Global Navigation Satellite system (i.e., GNSS data). Successful operation in NTN cells therefore depends on the availability of satellite based GNSS / navigation signals. However, such signals can be maliciously jammed, or spoofed, relatively easily (or may be unavailable for other reasons) and so there is a need to increase the robustness of uplink time and frequency synchronisation in NTN to mitigate against issues arising from the unavailability (or inaccuracy) of such satellite based geographic positioning (GNSS) signals.

[0022] More specifically, there is a need for enhancements to existing UE pre-compensation techniques for achieving uplink time and frequency synchronisation during long connection times in the case that a geographic positioning mechanism (e.g., GNSS) availability and / or accuracy is reduced. Moreover, there is a need for enhancements to existing UE pre-compensation techniques for achieving uplink time and frequency synchronisation during initial access in the case that the geographic positioning mechanism (e.g., GNSS) availability and / or accuracy is reduced. Ideally, any enhancements aimed at addressing this need would be applicable whether a UE is static or in-motion and whether a UE is in an idle or a connected mode. It is currently envisaged that any enhancement can work on the assumption that geographic positioning (e.g., GNSS) accuracy can be reduced down to a certain minimum (e.g., 1 km), and that temporary unavailability refers to unavailability for a certain maximum (e.g., 30 minutes) duration.

[0023] Currently, it is generally assumed that all NR-NTN capable UEs are also GNSS capable, and that the UEs are capable of simultaneous GNSS and NR-NTN operation (i.e., GNSS position is always available and valid). It is currently envisaged, therefore, that enhancements to existing UE pre-compensation techniques can work on the assumption that simultaneous GNSS operation and NTN operation is supported.

[0024] However for IoT-NTN, whilst is can generally be assumed that a UE has a GNSS capability, simultaneous GNSS and NTN narrowband IoT (NB-IoT) or enhanced machine-type communication (eMTC) operation (another form of IoT technology) currently cannot be assumed. Accordingly, a GNSS 'validity' duration is used which represents a time period during which an acquired GNSS position is considered valid. Any RRC connection and scheduling therefore needs to be performed during this GNSS validity duration (albeit possibly extended by a limited extension duration). In earlier technology releases GNSS re-acquisition during the RRC connection was not supported and so only a relatively short RRC connection time was possible. In later technology releases, however, GNSS re-acquisition during RRC connection became supported and so a longer RRC connection time became possible. It would be beneficial, therefore, if any enhancement to existing UE pre-compensation techniques was applicable to this broader scenario of a long connection time.

[0025] One or more apparatus and / or one or more associated methods are disclosed that aim to at least partially contribute to meeting one or more of above needs.

[0026] In the following disclosure 'satellite' based NTN will generally be referred to but it will be appreciated that the principles and methods described are more widely applicable to other space (or air) borne platforms used for implementing NTNs.

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

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

[0029] A method performed by a user equipment (UE) according to the present disclosure includes performing Global Navigation Satellite System (GNSS) acquisition, resetting configuration regarding time alignment based on the performing GNSS acquisition, and performing uplink transmission using the configuration regarding time alignment.

[0030] A user equipment (UE) according to the present disclosure includes means for performing Global Navigation Satellite System (GNSS) acquisition, means for resetting configuration regarding time alignment, and means for initiating a random access procedure to report a remaining validity duration of a GNSS position based on the GNSS acquisition.

[0031] Examples of apparatus and methods will now be described, by way of example, with reference to the accompanying drawings in which:Fig. 1 illustrates schematically an exemplary mobile (cellular or wireless) communication system;Fig. 2 illustrates schematically a non-terrestrial network (NTN) radio access network that may be used in the communication system of Fig. 1;Fig. 3A illustrate a possible architecture of an NTN RAN that may be used in the communication system of Fig. 1;Fig. 3B illustrate a possible architecture of an NTN RAN that may be used in the communication system of Fig. 1;Fig. 3C illustrate a possible architecture of an NTN RAN that may be used in the communication system of Fig. 1;Fig. 4, which is a simplified illustration of NTN based timing alignment in the communication system of Fig. 1;Fig. 5 is a simplified sequence diagram illustrating a timing adjustment mechanism that may be implemented in the communication system of Fig. 1 when GNSS positioning is unavailable;Fig. 6 is a simplified sequence diagram illustrating a timing (re)adjustment mechanism that may be implemented in the communication system of Fig. 1 when GNSS positioning becomes available after a period of unavailability.Fig. 7 is a simplified sequence diagram illustrating a simplified sequence diagram illustrating a GNSS positioning unavailability reporting / timing advance management adaptation mechanism that may be implemented in the communication system of Fig. 1 when GNSS positioning becomes unavailable;Fig. 8 is a simplified sequence diagram illustrating another timing adjustment mechanism that may be implemented in the communication system of Fig. 1 when GNSS positioning is unavailable;Fig. 9 is a simplified sequence diagram illustrating timing adjustment mechanisms that may be implemented in the communication system of Fig. 1 for triggering a random access procedure when GNSS positioning is invalid, or a UE has no GNSS positioning capability;Fig. 10 is a simplified sequence diagram illustrating a timing adjustment mechanism that may be implemented in the communication system of Fig. 1 when the UE is in an RRC connected state and GNSS positioning is invalid / unavailable;Fig. 11 is a simplified sequence diagram illustrating another timing adjustment mechanism that may be implemented in the communication system of Fig. 1 when the UE is in an RRC connected state and GNSS positioning is invalid / unavailable;Fig. 12 is a simplified block schematic illustrating the main components of a user equipment that may be used in the communications system of Fig. 1; andFig. 13 is a simplified block schematic illustrating the main components of a base station / access network node that may be used in the communications system of Fig. 1.

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

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

[0034] In the communication system 1 user equipment (UEs) 3 (3-1, 3-2, 3-3) (e.g. mobile telephones and / or other mobile devices) can communicate with each other via a corresponding radio access network (RAN) 5 that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, the RAN 5 is an NTN based RAN that includes a base station 5A (e.g., an LTE / 4G base station such as an eNB) that respectively operates one or more associated cells 9.

[0035] As those skilled in the art will appreciate, whilst three UEs 3, and one NTN RAN 5 are shown in Fig. 1 for illustration purposes, the system, when implemented, will typically include one or more other RANs 5 (which may be a terrestrial network (TN) based RAN rather than an NTN RAN) and one or more other UEs 3.

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

[0037] 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 for 4G, 'Xn' interface for 5G, and / or the like).

[0038] 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), a one or more network node entities for location management (3.g. Location Management Function (LMFs) 10-3), and a number of other functions 10-n.

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

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

[0041] 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 SMF 10-2 is connected to the AMF 10-1 via an appropriate interface (e.g. an N11 reference point). The SMF 10-2 provides session management functionality (that formed part of MME functionality in LTE) and additionally combines some control plane functions (provided by the serving gateway and packet data network gateway in LTE). The SMF 10-2 also allocates IP addresses to each UE 3.

[0042] The UEs 3 of the communication system 1 are capable of operation to acquire geographic positioning data (in this example at least Global Navigation Satellite System (GNSS) operation) for use in determining a position of the UE 3 (e.g., for assisting timing advance pre-compensation, and / or other positioning reliant operations). Nevertheless, whilst the exemplary communication system is described with reference to GNSS operation in particular, it will be appreciated that other similar forms of geographic positioning are possible in addition, or as an alternative, to GNSS. It is possible that one or more of these other geographic positioning mechanisms could potentially be used for supporting position reliant mechanisms such as, for example, timing advance pre-compensation.

[0043] The LMF 10-3 manages the support of different location services for UEs 3 whose location is unknown and needs to be located ('target UEs'), including positioning of the UEs 3 and delivery of assistance data to the UEs 3. The LMF 10-3 may interact with a serving base station 5A for a target UE 3 in order to obtain position measurements for that UE 3, including uplink measurements made by the base station (e.g., of sounding reference signals (SRS)) and downlink measurements made by the UE 3 (e.g., of positioning reference signals (PRS)) and provided to the base station 5A. The LMF 10-3 may interact with a target UE 3 in order to deliver assistance data if requested for a particular location service, or to obtain a location estimate if requested.

[0044] For positioning of a target UE 3, the LMF 10-3 decides on the position methods to be used, based on factors that may include, for example, a location services (LCS) client type, a required quality of service (QoS), UE positioning capabilities, and / or base station positioning capabilities. The LMF 10-3 can invoke these positioning methods in the UE 3 and / or serving base station. The positioning methods may yield a location estimate for UE-based position methods and / or positioning measurements for UE-assisted and network-based position methods. The LMF 10-3 may combine the received results and determine a single location estimate for the target UE 3. Additional information like accuracy of the location estimate and velocity may also be determined.

[0045] The LMF 10-3 is connected to the AMF 10-1 via an appropriate interface (e,g, an NLs reference point). The LMF 10-3 is configured to receive measurement results (e.g., for PRS) and assistance information from the base station 5A and / or UEs 3, via the AMF 10-1 over the NLs interface, and to compute the position of the UEs 3 based on the measurement results. The communication of positioning information between the base station 5A and the LMF 10-3 makes use of an appropriate protocol (such as the NR Positioning Protocol A (NRPPa)). The LMF 10-3 is also configured for configuring the UEs 3 using an appropriate protocol (e.g., the LTE positioning protocol (LPP)) via AMF 10-1.

[0046] The RAN 5 is also configured for transmission of, and the UEs 3 are configured for the reception of, control information and user data via a number of downlink (DL) physical channels and for transmission of a number of physical signals. The DL physical channels correspond to resource elements (REs) carrying information originated from a higher layer, and the DL physical signals are used in the physical layer and correspond to REs which do not carry information originated from a higher layer.

[0047] The 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 a 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.

[0048] Specifically, the PBCH is sent by the base station 5A via a Synchronisation Signal Block, which is also sometimes referred to as an SS / PBCH block (SSB), together with a primary synchronisation signal (PSS) and a secondary synchronisation signal (SSS). On reception of the SSB, the UE 3 may assume that the PBCH, PSS and SSS are in consecutive symbols forming the SSB. The base station 5A may transmit a number of such SSBs corresponding to different DL beams (referred to as 'SSB' beams).

[0049] The DL physical signals may include, for example, reference signals (RSs) and synchronisation 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 of the 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).

[0050] Similarly, the UEs 3 are configured for transmission of, and the base station of the 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 a UL control / data signal, and / or sounding reference signals (SRS) used for UL channel measurement.

[0051] Synchronisation and Initial Access In order to initially synchronise, in the downlink, with the network, the UE 3 is configured to search for, and perform measurements of the SSB beams (e.g. of the synchronisation signal reference signal received power, 'SS-RSRP', synchronisation signal reference signal received quality, 'SS-RSRQ', and / or the synchronisation signal to noise or interference ratio, 'SS-SINR'). The UE 3 may maintain a set of candidate beams which may contain beams from multiple cells (with a PCI and beam ID (or SSB index) distinguishing the SSB beams from one another). The UE 3 is configured to select an SSB beam (e.g., the best beam) based on the measurements, and to synchronise its reception to the selected SSB beam based on the synchronisation signals in that SSB (e.g., by estimating and correcting frequency and time offsets appropriately). The UE 3 decodes the corresponding PSS and SSS, detects the associated cell identity, and then decodes the PBCH and the MIB carried by the PBCH. The UE 3 also detects DMRSs transmitted via the selected beam. Hence, the UE 3 can detect and decode other system information carried in other SIBs (e.g., including cell access related information caried by SIB1).

[0052] Once downlink synchronisation has been completed, the UE 3 may then attempt to access the cell 9 via the SSB beam using an initial RRC connection setup procedure comprising an appropriate random access procedure.

[0053] Specifically, when attempting to access a cell 9, the UE 3 is configured to attempt to access the cell / beam using a random access procedure that typically involves four distinct steps. Prior to attempting initial access the UE 3 transmits a (typically randomly selected) preamble to the RAN 5 over a physical random access channel (PRACH / RACH) for initiating the random access procedure (also referred to as a RACH procedure or simply RACH) for obtaining synchronisation in the uplink. This step may be referred to as PRACH transmission or simply transmission of message 1 (Msg1). In response, the network responds with a random access response (RAR). The RAR indicates reception of the preamble and includes: a timing-alignment (TA) command (TAC) comprising information 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 the 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 RAR transmission step is often referred to as message 2 (Msg2) transmission. The UE 3 then sends a third message (message 3 or 'Msg3') to the network over the PUSCH based on the information in the RAR. The specific message sent by the UE 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 radio RRC connection setup, however, Msg3 typically comprises an RRC Setup request or similar message carrying a temporary randomly generated UE identifier. The network responds with a fourth message (message 4 or '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] A similar random access procedure may also be used in other contexts including, for example, handover, connection reestablishment, requesting UL scheduling where no dedicated resource for a scheduling-request has been configured for the UE 3, etc.

[0055] The UE 3 may, nevertheless, also be configured for performing a so-called two-step random access procedure (in addition, or as an alternative, to being able to perform the above described four-step random access procedure). The two-step random access may be particularly useful for supporting (Ultra) Low Latency Communications, 10 ms control plane latency, fast handover, efficient channel access in unlicensed spectrum, and transmission of small data packets, amongst others. However, the two-step procedure may also be applicable to large cells such as NTN cells. The main difference between the four-step and two-step procedure is that whilst the four-step random access procedure requires two round-trip cycles between the UE 3 and the base station 5A, the two-step random access procedure aims to reduce latency and control-signalling overhead by using a single round trip cycle between the UE 3 and the base station 5A. Effectively, this is achieved by combining the UE's PRACH preamble (Msg1) transmission and the scheduled PUSCH transmission (Msg3) into a single message (referred to as 'MsgA'). Similarly, the random access response (RAR / Msg2) from the base station to UE 3 and the contention resolution message (Msg4) are combined in the two-step random access procedure (and referred to as 'MsgB').

[0056] Moreover, as those skilled in the art will appreciate, while a contention based PRACH procedure is described, a non-contention based (or 'contention free') procedure may also be used in which a dedicated preamble is assigned by the base station 5A to the UE 3.

[0057] NTN RAN As mentioned above, in the exemplary communication system 1, the RAN 5 is implemented as a non-terrestrial network (NTN) RAN 5 (although it will be appreciated that this need not be the case and that may of the techniques described herein may be applied in the context of a terrestrial network based RAN).

[0058] Fig. 2 illustrates schematically one such NTN RAN 5, that may be used in the communication system, of Fig. 1 in more detail.

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

[0060] The NTN RAN 5 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 non-terrestrial space (or air) borne platform 5C is travelling along its orbit (e.g. as illustrated by the arrows A in Fig. 2). 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. 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).

[0061] The base station 5A of the NTN RAN 5 is configured to provide ephemeris data for the non-terrestrial space (or air) borne platform 5C, 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 subscriber identity module, 'SIM') 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.

[0062] Specifically, the base station 5A is able to provide satellite assistance information for the non-terrestrial space (or air) borne platform 5C 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 (for 5G 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., k_offset), validity duration for uplink synchronisation information, and an epoch time (a reference time for which assistance information is valid)).

[0063] NTN RAN Architecture Figs. 3A to 3C each respectively illustrate a possible architecture of an NTN RAN 5 that may be used.

[0064] The architecture of Fig. 3A may be referred to as a 'transparent satellite' based RAN architecture. In this architecture, the base station 5A 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 and via a non-terrestrial space (or air) borne platform 5C that has no base station functionality. The non-terrestrial space (or air) borne platform 5C relays these communications to and from the UEs 3 in each cell operated by the base station 5A, and from and to the gateway 5B as required. The non-terrestrial space (or air) borne platform 5C 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 and the non-terrestrial space (or air) borne platform 5C effectively acts as part of the respective Uu interface (or reference point) between the base station 5A and each UE 3. Similarly, the respective service link between the non-terrestrial space (or air) borne platform 5C and each UE 3 effectively acts as another part of the respective Uu interface (or reference point) between the base station 5A and each UE 3. The base station's communication link with the core network 7 (e.g. for signalling over appropriate interfaces (e.g. N2, N3 interface / reference point etc.)) is provided solely terrestrially.

[0065] The architecture of Fig. 3B 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 is a base station 5A of a distributed type having a terrestrially located central unit (CU) 5ACUand a distributed unit (DU) 5ADUprovided on-board the non-terrestrial space (or air) borne platform 5C. The terrestrially located CU 5ACUperforms some of the (typically higher layer) functionality of the base station 5A whereas the non-terrestrially located DU 5ADUperforms other (typically lower layer) functionality of the base station 5A. The terrestrially located CU 5ACUcommunicates with the non-terrestrially located DU 5ADUvia the gateway 5B and an F1 interface implemented via a satellite radio interface between the gateway 5B and the non-terrestrial space (or air) borne platform 5C in which the DU 5ADUis provided.

[0066] The non-terrestrial space (or air) borne platform 5C transmits communications destined for and originating from the UEs 3 in each cell operated by the base station 5A, and from and to the gateway 5B 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 by the DU 5ADUand higher layer processing of that communication respectively destined for and originating from the UEs 3 is performed by the terrestrially located CU 5ACU.

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

[0068] The architecture of Fig. 3C 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 is provided on-board the non-terrestrial space (or air) borne platform 5C. The base station 5A on board the non-terrestrial space (or air) borne platform 5C transmits communications destined for and originating from the UEs 3 in each cell operated by the base station 5A, and from and to the core network 7 via the gateway 5B 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 by the base station 5A.

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

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

[0071] For the purposes of description, when implemented in the communication system 1, the NTN RAN 5 will be described in terms of the transparent satellite based RAN architecture illustrated in Fig. 3A. It will be appreciated, however, that the NTN RAN 5 could potentially use a different one of the architectures and the entities of the communication system 1 could be adapted accordingly.

[0072] In the exemplary communication system 1, the base station 5A and UE 3 are mutually configured for perform appropriate timing synchronisation to ensure that any timing misalignment between received signals from different UEs 3 at the base station 5A falls within the cyclic prefix to avoid ISI and ICI.

[0073] Transmission Timing Adjustment (Non-NTN / Terrestrial) In the context of normal non-NTN (i.e., terrestrial) based cells, the UE 3 is configured for performing normal terrestrial cell based uplink timing alignment involving the determination, and application, of an appropriate transmission timing advance (TA) value based on timing components provided by the network. Specifically, for this terrestrial based timing alignment, the UE 3 can determine the TA value to be used based on the sum of a serving cell specific timing advance component (offset value), NTA,offset(broadcast by the serving terrestrial base station in system information), and a UE specific timing advance component (offset value), NTA, received from the base station (e.g., via the initial TAC in the RAR) and / or in a subsequent update, after initial attach, via a TAC MAC control element (CE).

[0074] In more detail, during a connection, the base station 5A can estimate an uplink timing error, within a range, by detecting a reference signal (e.g., a sounding reference signal (SRS)) in an uplink transmission. The base station 5A can hence send an indication of a timing adjustment to the UE 3 via an initial TAC in an RAR and / or a TAC MAC CE. This timing adjustment corresponds to the NTAcomponent of the TA value. This is sometimes referred to as closed loop timing adjustment.

[0075] Transmission Timing Adjustment (GNSS Available) Referring to Fig. 4, which is a simplified illustration of NTN based timing alignment in the communication system 1, to help achieve timing alignment in the context of NTN when geographic positioning (in this example GNSS assisted) measurements are available, the UE 3 and base station 5A are mutually configured to support a more sophisticated timing alignment procedure than is used for terrestrial based timing alignment.

[0076] As seen in Fig. 4, in the NTN based timing alignment procedure the TA value to be used is determined based, not only on the UE specific and serving cell specific timing components (NTA,offsetand NTA) obtained from the base station 5A, but also on two UE estimated 'pre-compensation' timing components. One of these pre-compensation timing components, , is derived from the geographic position (i.e., GNSS position) and serving satellite ephemeris related parameters shared by the base station 5A (e.g., from a satellite orbit (position and / or velocity) estimated from the satellite-ephemeris-related parameters). This pre-compensation timing component effectively compensates for the UE specific 'service link' round trip propagation delay arising from the UE's distance to the non-terrestrial space (or air) borne platform 5C and the relative movement between the UE 3 and the non-terrestrial space (or air) borne platform 5C. The other of these pre-compensation timing components, , is derived from network-controlled higher-layer parameters. This pre-compensation timing component effectively compensates for the 'feeder link' round trip propagation delay (that is common to UEs 3 in the cell) arising from the distance between the uplink time synchronisation reference point (the gateway 5B in the illustrated example but may be elsewhere for different NTN architectures) and the serving non-terrestrial space (or air) borne platform 5C.

[0077] In more detail, the UE 3 is able to determine a TA value based on the following equation:

[0078] where: TTAisthe transmit timing advance (TA) value.

[0079] NTAis the offset specific to each UE 3 and is provided under the control of the network (e.g., from the RAN 5) via a TAC in an RAR and / or a TAC MAC CE. In TN scenario, NTAis usually used to correct a timing error that arises due to oscillator drifting, UE movement and / or channel condition variation assuming a fixed base station location.

[0080] NTA,offsetis the serving cell / RAN specific timing advance offset value that is broadcast in system information. It is specified to ensure that an UL radio frame finishes before the start of the subsequent DL radio frame. The uplink time synchronization reference point is the point where DL and UL are frame aligned with an offset given by NTA,offset.

[0081] is the UE self-estimated 'common' pre-compensation value that may be derived from a number of higher-layer 'TA common related' parameters (e.g., TACommon, TACommonDrift, and TACommonDriftVariation) if configured (otherwise ). This is to compensate for the two-way transmission delay between the uplink time synchronisation reference point and the serving satellite (all or part of feeder link delay). The value is referred to as being 'common' because it is used for compensating for a propagation delay common to all the transmissions between all UEs 3 and the base station 5A that serves them. In the illustrated example the reference point is set at the antenna of the NTN gateway 5B, and the common delay thus corresponds to the round trip delay experienced on the feeder link between the serving non-terrestrial space (or air) borne platform 5C and the NTN gateway 5B.

[0082] is the UE self-estimated UE specific pre-compensation value based on UE position (e.g., GNSS derived) and serving satellite ephemeris related higher layers parameters (if configured) - otherwise . This corresponds to the UE specific two-way transmission delay on the service link between the UE 3 and the serving non-terrestrial space (or air) borne platform 5C. However, in some scenarios the value of may not reflect an accurate GNSS based position measurement, for example when GNSS signalling is unavailable (e.g., due to jamming) or is spoofed.

[0083] TS(sometimes referred to as TC) is a basic time unit for TA values in the communication system 1

[0084] The TA common related parameters and / or satellite ephemeris related parameters may be calculated based on orbit prediction information shared by an NTN control centre (NCC) and provided by the RAN 5 to the UE 3 together as part of 'NTN UL synchronisation assistance information'. All, or some of, the NTN UL synchronisation assistance information may be provided through a system information broadcast (SIB19) and / or through dedicated RRC reconfiguration messages.

[0085] Referring to the TA common related parameters in more detail, the TACommon parameter is a network-controlled common TA value and may include any timing offset considered necessary by the network. It may have a typical value range of, for example, 0 to 270.73 ms and a granularity of 4.072 × 10-3μs. The TACommonDrift parameter indicates a drift rate of the common TA value. It may have a typical value range of, for example, -52.387 μs / s to +52.387 μs / s and a granularity of 0.2 × 10-3μs / s. The TACommonDriftVariation parameter indicates a drift rate variation of the common TA value. It may have a typical value range of, for example, 0 to 0.5894 μs / s2and a granularity of 0.2 × 10-4μs / s2.

[0086] Transmission Timing Adjustment (GNSS Unavailable) As discussed in the introduction, inaccurate GNSS measurement may arise due to GNSS signalling being jammed or spoofed. Accordingly, the estimated uplink TA value may be affected by an error in the compensation component arising, for example, from an error in the GNSS information (as the base station 5A is unable to distinguish the specific source of any timing error).

[0087] Beneficially, to help achieve timing alignment in the context of NTN when GNSS based positioning is not available, the UE 3 and base station 5A of the communication system 1 are mutually configured to support one or more enhanced timing alignment mechanism.

[0088] In one enhanced timing alignment mechanism described in more detail later, when GNSS based positioning of the UE 3 becomes unavailable, the UE 3 continues to calculate the TA value based on Equation 1. Nevertheless, rather than attempt to calculate the 'ideal' UE specific compensation component (e.g., by adjusting for changes in the UE position estimated derived from another, non-GNSS, source), the UE 3 simply continues to use last available GNSS position (and satellite ephemeris related parameters) to calculate, temporarily, the UE specific compensation component (i.e., ignoring UE position changes) - which may be referred to as . The correction of the TA value thus relies on the closed loop TA adjustment mechanism in which the base station 5A detects the total timing error, including any part arising from a UE position error (i.e., any difference between the 'true' / 'correct' / 'ideal' based on the real current position of the UE 3 and the value of based on the last known position of the UE 3). The base station 5A can then simply send a TAC in an RAR and / or a TAC MAC CE to the UE 3 as usual with a value of NTAthat, in effect, automatically compensates for the error (albeit within a specific maximum correction range (e.g. [-31, 32]×16TS)).

[0089] This mechanism has the advantage of simplicity and is particularly suitable for scenarios in which the GNSS based UE position has been unavailable only a relatively short time, the UE 3 is static or has a relatively low mobility, and / or the GNSS accuracy is reduced but the reduction in accuracy is relatively limited (i.e., within a limited range).

[0090] This enhanced timing alignment mechanism beneficially takes advantage of the realisation that, in an NTN scenario, even when there is an error in the compensation component arising from an error in / unavailability of the GNSS information, if the closed loop signalling (e.g., TAC) indicating the NTAcomponent to the UE 3 is sent frequently enough (e.g., often enough to ensure any timing advance error due to oscillator drifting and GNSS inaccuracy are within a specific correction range (e.g. [-31, 32]×16TS)), then uplink transmission may still be possible even if the GNSS position is not accurate.

[0091] When the GNSS become available again, and the UE 3 reacquires its GNSS based position, the UE 3 may be beneficially configured either to adjust the NTAappropriately itself (there are a number of ways in which this might be done as described in more detail later), or to initiate a new random access channel (RACH) procedure to reacquire an updated NTAdirectly from the base station 5A (e.g., in a TAC). Accordingly, the UE 3 can continue to calculate its TA value using Equation 1 based on the 'ideal' UE specific compensation component determined based on the newly acquired GNSS based position and the adjusted / updated NTA.

[0092] Moreover, as described in more detail later, the UE 3 may, beneficially, be configured to report the GNSS position unavailability to base station 5A, and the base station 5A may be configured to adapt the configurations for faster closed loop TA management appropriately.

[0093] In another enhanced timing alignment mechanism described in more detail later, when GNSS based positioning of the UE 3 becomes unavailable, the UE 3 is configured to calculate a reference / common TA value based on a variation of Equation 1 in which the UE specific compensation component is replaced with a reference position based compensation component that is calculated based on a reference position (e.g., a cell coverage centre, or other appropriate reference position, configured by the network) and the serving satellite ephemeris related higher layers parameters (if configured). The correction of the TA value in this case also relies on the closed loop TA adjustment mechanism in which the base station 5A detects the total timing error, including any part arising from a UE position error (i.e., any difference between the 'true' / 'correct' / 'ideal' based on the real current position of the UE 3 and the value of based on the reference position). The base station 5A can then simply send a TAC in an RAR and / or a TAC MAC CE, to the UE 3 as usual with a value of NTAthat, in effect, automatically compensates for the error.

[0094] This mechanism is particularly suitable for scenarios in which the GNSS based UE position is invalid (e.g., when a GNSS validity duration has expired since the last GNSS based location was acquired or the GNSS based UE position is known to be invalid for some other reason), the GNSS position accuracy is very low, GNSS based positioning is not available at the time a RACH procedure is triggered, and / or the UE 3 has no GNSS capability.

[0095] Moreover, as described in more detail later, a UE 3 without a valid GNSS (or no GNSS capability) may, beneficially, be configured to use the reference / common TA value when a RA procedure needs to be initiated (e.g., when a UE 3 in idle mode needs to initiate initial access, or a UE needs to execute a RACH-based handover).

[0096] Similarly, as described in more detail later, during a period when GNSS has become unavailable or invalid, a UE 3 that is in RRC connected may report this to the base station 5A with appropriate assistance information and the base station 5A may trigger application of the reference / common TA (and may indicate the reference location) and / or an absolute NTAto be applied upon the reference / common TA being adopted.

[0097] In another enhanced timing alignment mechanism described in more detail later, when a UE 3 is in RRC connected and a GNSS signal becomes out of date, a GNSS position becomes invalid (e.g., based on a validity timer), GNSS accuracy is very low, and / or an accumulated NTAexceeds a threshold, the UE 3 may trigger an RA procedure, in which the UE 3 performs a PRACH transmission (using a legacy PRACH format or an enhanced PRACH format) with an appropriate timing advance (e.g., a timing advance value calculated in a similar manner to one of the other enhanced timing alignment mechanisms mentioned above).

[0098] It will be appreciated that the various enhanced timing alignment mechanisms and related enhancements summarised above and described in more detail below are neither mutually exclusive nor reliant on one another. More specifically, all or a subset of the procedures may be incorporated into a communication system together (or individually) to provide a commensurate benefit. For example, whilst a timing alignment mechanism using the last known GNSS position (or reference position) may be incorporated into a communication system without the timing alignment mechanism using a reference position (or last known GNSS position), they may be incorporated for use at different times depending on circumstances (e.g., based on the length of time GNSS positioning is unavailable).

[0099] Transmission Timing Adjustment (Based on last known GNSS position) As mentioned above, in one enhanced timing alignment mechanism, when GNSS based positioning of the UE 3 becomes unavailable, the UE 3 may calculate the TA value using a UE specific compensation component determined from a last available GNSS position (and satellite ephemeris related parameters) in place of the 'ideal' determined from a current GNSS position.

[0100] A possible implementation of this mechanism will now be described in more detail with reference to Figs. 5 to 6, by way of example only.

[0101] Fig. 5 is a simplified sequence diagram illustrating a timing adjustment mechanism that may be implemented in the communication system 1 when GNSS positioning is unavailable.

[0102] As seen in Fig. 5, the illustrated procedure assumes that, initially, the UE 3 has performed appropriate downlink synchronisation in the cell 9 of the NTN RAN 5 and GNSS positioning is initially available (as indicated at S500-1).

[0103] The UE 3, in this example, receives system information at S502 that includes, amongst other information, information that may be used in the calculation of the TA value. For example, and as illustrated in Fig. 5, the system information may include information indicating the serving cell / RAN specific timing advance offset value, NTA,offset, described above. Moreover, as illustrated in Fig. 5, the system information may include NTN UL synchronisation assistance information such as ephemeris related parameters and / or the TA common related parameters (e.g., TACommon, TACommonDrift, and TACommonDriftVariation) although it will be appreciated that this information may not always be configured by the network. It will be appreciated that whilst Fig. 5 shows this information being provided at the same time, for simplicity, the various information used in the calculation of the TA value need not be provided at the same time or in the same SIB. Typically, for example, the serving cell / RAN specific timing advance offset value, NTA,offset, may be provided in SIB1 whilst the NTN UL synchronisation assistance information may be provided in SIB19 (although the specific SIBs used may be different).

[0104] Whilst GNSS positioning continues to be available (as indicated at S500-1), transmission adjustment timing may occur as usual using the GNSS position based mechanism described with reference to Fig. 4 based on Equation 1, as illustrated at S504-1, when needed.

[0105] For example, during a RACH procedure, the base station 5A may calculate a closed loop UE specific timing offset, NTA, as seen at S506-1, and may provide this to the UE 3 in a TAC included in the RAR as seen at S508-1. Similarly, after initial attach, the base station 5A may (re)calculate a closed loop UE specific timing offset, NTA, as seen at S506-1, and may provide this to the UE 3 in a TAC MAC CE as seen at S508-1.

[0106] The UE 3 may thus perform transmission time adjustment, at S510-1 using a TA value that is calculated based on Equation 1 using the NTAprovided in the TAC, the NTA,offsetbroadcast in system information, an estimated based on the TA common related parameters (if configured), and an estimated based on the GNSS derived UE position and any satellite ephemeris parameters (if configured). It will be appreciated that, whilst not specifically illustrated, prior to any network calculation and provision of NTAtransmission timing adjustment may, nevertheless, still occur based on Equation 1 with the value NTAset to zero (e.g., for the purposes of initially triggering a RACH procedure by sending a preamble).

[0107] However, when GNSS positioning ceases to be available (e.g., becomes temporarily unavailable) as indicated at S500-2, a variation of the transmission adjustment timing mechanism based on Equation 1 may be used, as illustrated at S504-2, when needed.

[0108] For example, during a RACH procedure, the base station 5A may still calculate a closed loop UE specific timing offset, NTA, as seen at S506-2, and may provide this to the UE 3 in a TAC included in the RAR as seen at S508-2. Similarly, after initial attach, the base station 5A may still (re)calculate a closed loop UE specific timing offset, NTA, as seen at S506-2, and may provide this to the UE 3 in a TAC MAC CE as seen at S508-2.

[0109] However, while the GNSS is unavailable, the UE 3 performs transmission time adjustment, at S510-2 using a TA value that is calculated based on Equation 1 using the NTAprovided in the TAC, the NTA,offsetbroadcast in system information, an estimated based on the TA common related parameters (if configured), and a value of ( ) estimated based on the last known GNSS derived UE position and any satellite ephemeris parameters (if configured). It will be appreciated that, whilst a further calculation and provision of NTAis shown at S506-2, transmission timing adjustment may, nevertheless, occur prior to any (further) network calculation and provision of NTA, using the last known value of NTA(or with NTAset to zero if there is no previous value).

[0110] Any subsequent calculation and provision of the closed loop UE specific timing offset, NTA, by the base station 5A, while the GNSS is unavailable will, in effect, autocorrect for any errors in the calculation of arising, for example, from UE movement.

[0111] It can be seen that the transmission timing adjustment in this case will, initially, be the calculated TA value based on the last GNSS positioning when it was available. Here it will be appreciated that the is calculated based on not only UE position but also NTN satellite position, which constantly changes for NGSO system, consequently, even if the GNSS position of UE 3 has not been updated since it was last known, the calculated at any time is likely to be different to the last calculated value when GNSS position was last available. 　　In summary, therefore, the UE 3 effectively uses the same formula . However, while GNSS is not available, the UE 3 uses the last available GNSS position to calculate (i.e., ignoring the UE position changes), referred to for clarity as . Beneficially, therefore, this mechanism takes advantage of closed loop TA adjustment in which the base station 5A detects a total timing error - including any part which arises from UE position error (i.e., the difference between the ideal (that would have been calculated based on a real GNSS position) and (calculated based on the last known GNSS position)). The base station 5A can then sends a TAC to the UE 3 in which the position error related timing error is reflected in the NTAcomponent.

[0112] Fig. 6 is a simplified sequence diagram illustrating a timing (re)adjustment mechanism that may be implemented in the communication system 1 when GNSS positioning becomes available after a period of unavailability.

[0113] Specifically, as seen in Fig. 6, when GNSS positioning becomes available again (as indicated at S600), the UE 3 reacquires the GNSS position and recalculates the UE specific compensation value, , based on this newly reacquired GNSS position accordingly (as indicated at S602).

[0114] However, the newly calculated UE position may be significantly different from last known GNSS position used in the calculation of the TA value in accordance with the transmission timing adjustment mechanism described with reference to Fig. 5. Consequently, the calculated using the newly acquired position may be very different to the calculated based on last know position. As explained with reference to Fig. 5, however, the difference between the formerly calculated and the newly calculated may have been compensated for via the closed loop mechanism while GNSS positioning was unavailable (i.e., by adjustments to the calculated value of the NTAcomponent provided by the base station 5A). Hence, if the UE 3 simply uses the updated (corrected) value of the component to calculate a new TA value and adjust its transmission timing accordingly, the whole TA value may exhibit a significant step change, with the former closed loop timing compensation associated with the position related timing error being incorporated into the calculation of the TA value.

[0115] To cater for this potential error, the UE 3 may be configured to perform a transmission timing readjustment, when it has reacquired its GNSS position (as seen at S604), be effectively 'resetting' the closed loop timing component, NTA, to a more appropriate value. The UE 3 may be configured to perform the transmission timing readjustment, S604, only if a particular condition has been met, for example: if the UE 3 reacquires its GNSS position after a particularly long time (e.g., by reference to a threshold period predefined, or configured by the network, at the UE 3); if there is a big enough difference between the newly acquired position and the last known position (e.g., by reference to a threshold position delta / difference predefined, or configured by the network, at the UE 3); and / or if there is a big enough difference between the calculated using the newly acquired position and the calculated using the last known position (e.g., by reference to a threshold delta / difference predefined, or configured by the network, at the UE 3).

[0116] The UE 3 may reset the closed loop timing component, NTA, to a more appropriate value in any of a number of ways as illustrated at S606-1 and S606-2.

[0117] The UE 3 may, for example, simply reset the closed loop timing component, NTA, locally to a more appropriate value NTA'as seen at S606-1.

[0118] For example, the UE 3 may effectively reset the closed loop timing component, NTA, by subtracting the difference between the calculated using the newly acquired position and the calculated using the last known position from the closed loop timing component, NTA, to arrive at an adjusted closed loop timing component, NTA' as seen at S606-1a. Effectively, therefore, when determining the TA value (at S610) the UE 3 applies a modified version of Equation 1 as follows:

[0119] Alternatively, the UE 3 may simply reset the closed loop timing component, NTA, to zero as seen at S606-1b.

[0120] Alternatively, the UE 3 may simply reset the closed loop timing component, NTA, to its the last known value before GNSS positioning became unavailable as seen at S606-1c.

[0121] The UE 3 may, alternatively, trigger a RACH procedure. For sending preamble over PRACH channel, the UE 3 may reset NTAto 0 (as in conventional procedures), and this will also cause the base station 5A to recalculate a new value for the closed loop timing component, NTA, and provide it to the UE 3 as seen at S606-2 (e.g., in the RAR).

[0122] It will be appreciated that whilst the four different NTAadjustment mechanisms described with reference to S606-1a to S606-1c and S606-2 are described as alternatives, the UE 3 may nevertheless be configured to be able to perform all, or a subset of, the described NTAadjustments and to select the most appropriate one to use (e.g., based on the time that GNSS position was unavailable, difference between the newly acquired position and the last known position, and / or the difference between the calculated using the newly acquired position and the calculated using the last known position).

[0123] The UE 3 may thus perform transmission time adjustment, at S610 using a TA value that is calculated based on Equation 1 using the updated NTA(NTA') determined at S606-1 or S606-2, the NTA,offsetbroadcast in system information, an estimated based on the TA common related parameters (if configured), and an estimated based on the newly reacquired GNSS based UE position and any satellite ephemeris parameters (if configured).

[0124] It will be appreciated that the UE 3 may be configured to report, to the base station 5A, the UE's capability to support the transmission timing readjustment after GNSS reacquisition behaviour described with reference to Fig. 6. This may, for example, be sent using a conventional capability report in which the base station sends a UE capability enquiry to the UE 3 (if not available in network side) and the UE 3 responds and reports its capability. The reported capability may then be stored in the core network so that every time the UE 3 reconnects to a base station 5A, the core network 7 can provide the UE capability to the base station 5A.

[0125] It will be appreciated that GNSS reacquisition may be network triggered or UE triggered. Network triggered GNSS reacquisition involves the transmission of a DL MAC CE for triggering a connected UE 3 to perform a GNSS measurement. UE autonomous GNSS reacquisition, if enabled by the base station 5A, allows a UE 3 to autonomously start GNSS measurement during an inactive state of a connected mode discontinuous reception (C-DRX) energy saving mechanism.

[0126] For both network-triggered and UE-autonomous based GNSS reacquisition, a measurement gap length configuration may be based on using a MAC CE (with a 1 bit indication to differentiate the two cases). It is also possible that an RRC configuration may be used for a network triggered case. The access stratum (AS) operations (e.g., radio link management (RLM) related timers, data inactivity timer, conditional handover execution, neighbour cell measurement, RACH, scheduling requests, and buffer status reporting) may be suspended when a UE 3 is performing GNSS measurement and resumed when the GNSS measurement is finished.

[0127] It will also be appreciated that an uplink synchronization extension duration may be implemented after GNSS become initially invalid. During this extension duration uplink transmission may still be allowed even after an original GNSS validity duration expires without requiring GNSS reacquisition. When a TAT is not set to infinity, the duration may be set to the remaining value of the TAT. When the TAT is set to infinity, the duration may be set to a configured value. An RRC parameter may be provided in dedicated RRC signalling to enable / disable the extension duration. A new RRC parameter may be provided in dedicated RRC signalling to configure the when the TAT is set to infinity.

[0128] As described above, in the communication system 1, the various mechanisms described with reference to Fig. 6 may be implemented together with a timing adjustment mechanism as described with reference to Fig. 5 for when GNSS positioning is unavailable. Nevertheless, it will be appreciated that the timing adjustment mechanism described with reference to Fig. 5 is not dependent on use of any of the specific mechanisms described with reference to Fig. 6 and may be implemented independently of any such mechanisms. Similarly, any of the mechanisms described with reference to Fig. 6, or a variation on them, may be implemented with a different timing adjustment mechanism than that described with reference to Fig. 5 when GNSS positioning is unavailable.

[0129] GNSS Positioning Unavailability Reporting / Closed Loop TA Management Adaptation As mentioned above, the UE 3 may, beneficially, be configured to report the GNSS position unavailability to base station 5A, and the base station 5A may be configured to adapt the configurations for faster closed loop TA management appropriately.

[0130] A possible implementation of this mechanism will now be described in more detail with reference to Fig. 7, by way of example only.

[0131] Fig. 7 is a simplified sequence diagram illustrating a GNSS positioning unavailability reporting / timing advance management adaptation mechanism that may be implemented in the communication system 1 when GNSS positioning becomes unavailable.

[0132] As seen in Fig. 7, when the GNSS is malfunctioning / GNSS availability is lost, as seen at S700-1, the UE 3 may report this at S703 either immediately, or after a predefined or network configured reporting period threshold time (tGNSS,unavailablein Fig. 7) as seen at S701. The GNSS malfunction / availability loss may, for example, be due to an unavailable GNSS signal or inaccurate GNSS measurement, meaning that the GNSS position cannot be accurately acquired.

[0133] The reporting of the GNSS malfunction / GNSS unavailability may, for example, be provided as a simple indication of a 'GNSS malfunction' or 'GNSS unavailability' as seen at S703-1. Alternatively, or additionally, the UE 3 may determine and report a 'GNSS validity duration' which is an indication of a time for which the GNSS may be treated as valid (i.e., a duration for which the uplink transmission is allowed without GNSS position reacquisition) as seen at S703-2.

[0134] Optionally, the UE 3 may report other assistance information for assisting the base station 5A to adapt the way in which it performs TA management appropriately (e.g., information indicating whether the UE 3 is static or in motion, an estimated mean speed and / or moving direction of the UE 3, and / or other information indicating the nature of faster close loop TA management that is required / desired at the UE 3 including, for example, desired / required adjustments to the configuration of sounding reference signals (SRSs) and / or the time alignment timer (TAT) at the UE 3). It will be appreciated that this assistance may be sent together with the GNSS malfunction / GNSS unavailability indication and / or GNSS validity duration (as illustrated) or may be sent separately in a different message.

[0135] Thus, the NTN RAN 5 (base station 5A) can determine an adapted UE configuration, for performing faster closed loop TA management, to at least partially compensate for the unavailable GNSS (as indicated at S705-1) and reconfigure the UE 3 accordingly (as indicated at S705-2). The adapted configuration may, for example, include adjustments to the configuration of the SRS (e.g., to be more frequent) and / or the TAT (e.g., to be shorter) at the UE 3.

[0136] It will be appreciated that, to provide for the enhanced (faster) closed loop TA adjustment to compensate for inaccurate / no GNSS measurement temporarily, the UE 3 may send the assistance information using any appropriate signalling (e.g., via an RRC message or via a periodic PUCCH / PUSCH layer 1 / layer 2 signalling update (e.g., either immediately when the GNSS is unavailable or when the GNSS has been unavailable for a threshold 'T' period)). As mentioned above the assistance information may include any appropriate information such as, for example, an indication of the UE speed and moving direction and / or other information such as a desired TAT value.

[0137] The base station 5A can thus beneficially configure and activate an alternative configuration at the UE 3 (for example to transmit more uplink reference signals (SRSs), and / or to use a shorter TAT) to support faster close loop TA adjustment when base station 5A detects that correction of a timing error, arising due to an error in the location used by the UE 3 for its TA calculations, relies on close loop TA management (e.g., because GNSS is not available).

[0138] It will be appreciated that, the base station 5A may reconfigure and activate the alternative configuration at the UE 3 by any suitable mechanism. For example, the base station 5A may use a one-step configuration (as illustrated in Fig. 7) via, for example, an RRC message. Nevertheless, the base station 5A may provide one or more alternative configurations first (e.g., via an RRC message) and then activate an appropriate alternative configuration, at an appropriate timing, via a lower layer message.

[0139] When the GNSS recovers, the GNSS availability returns, and / or a GNSS position is successfully (re)acquired, as seen at S700-2, the UE 3 may report this GNSS revery at S707.

[0140] The GNSS recovery / availability return may, for example, be provided as a simple indication of a 'GNSS recovery' or 'GNSS position (re)acquired' as seen at S707-1. Alternatively, or additionally, the UE 3 may report an infinite value for the 'GNSS validity duration as seen at S703-2.

[0141] The NTN RAN 5 (base station 5A) can thus determine to revert the UE configuration for performing closed loop TA management (as indicated at S709-1) and reconfigure the UE 3 accordingly (as indicated at S709-2), for example, to revert the configuration of the SRS and / or the TAT at the UE 3 to their original configurations.

[0142] It will be appreciated that this reporting mechanism, if implemented in the communication system 1, may be used in the context of any of the transmission timing adjustment mechanisms described herein. Moreover, even in a communication system that does not use a different transmission timing adjustment mechanism when GNSS is unavailable, this reporting / timing advance management adaptation mechanism may, nevertheless, be used to report a GNSS malfunction / unavailability.

[0143] Transmission Timing Adjustment (Based on reference GNSS position) As mentioned above, in one enhanced timing alignment mechanism, when GNSS based positioning of the UE 3 becomes unavailable, the UE 3 may calculate a reference / common TA value based on a variation of Equation 1 in which the UE specific compensation component is replaced with a reference position based compensation component that is calculated based on a reference position.

[0144] A possible implementation of this mechanism will now be described in more detail with reference to Fig. 8, by way of example only.

[0145] Fig. 8 is a simplified sequence diagram illustrating another timing adjustment mechanism that may be implemented in the communication system 1 when GNSS positioning is unavailable.

[0146] As seen in Fig. 8, the illustrated procedure assumes that, initially, the UE 3 has performed appropriate downlink synchronisation in the cell 9 of the NTN RAN 5 and GNSS positioning is initially unavailable (as indicated at S800).

[0147] The UE 3, in this example, receives system information at S802 that includes, amongst other information, information that may be used in the calculation of the reference / common TA value. For example, and as illustrated in Fig. 8, the system information may include information indicating the serving cell / RAN specific timing advance offset value, NTA,offset, described above. Moreover, as illustrated in Fig. 8, the system information may include NTN UL synchronisation assistance information such as ephemeris related parameters and / or the TA common related parameters (e.g., TACommon, TACommonDrift, and TACommonDriftVariation) although it will be appreciated that this information may not always be configured by the network. In this example, the system information also includes information indicating the reference position (e.g., the cell coverage centre) that may be used for TA calculations in the event that GNSS is unavailable (although it will be appreciated that, alternatively or additionally, this information may be provided in another way).

[0148] It will be appreciated that whilst Fig. 8 shows this information being provided at the same time, for simplicity, the various information used in the calculation of the reference / common TA value need not be provided at the same time or in the same SIB. Typically, for example, the serving cell / RAN specific timing advance offset value, NTA,offset, may be provided in SIB1 whilst the NTN UL synchronisation assistance information may be provided in SIB19 (although the specific SIBs used may be different).

[0149] While the GNSS positioning remains unavailable as indicated at S800, a variation of the transmission adjustment timing mechanism based on Equation 1 may be used, as illustrated at S804, when needed.

[0150] For example, during a RACH procedure, the base station 5A may calculate a closed loop UE specific timing offset, NTA, as seen at S806, and may provide this to the UE 3 in a TAC included in the RAR as seen at S808. Similarly, after initial attach, the base station 5A may (re)calculate a closed loop UE specific timing offset, NTA, as seen at S806, and may provide this to the UE 3 in a TAC MAC CE as seen at S508.

[0151] However, while the GNSS is unavailable, the UE 3 performs transmission time adjustment, at S810 using a reference / common TA value that is calculated based on a variation of Equation 1 using the NTAprovided in the TAC, the NTA,offsetbroadcast in system information, an estimated based on the TA common related parameters (if configured), and a value of calculated based on the reference position and any satellite ephemeris parameters (if configured). Specifically, the UE 3 performs transmission time adjustment based on the following equation:

[0152] It will be appreciated that, whilst a calculation and provision of NTAis shown at S806, transmission timing adjustment may, nevertheless, occur prior to any (further) network calculation and provision of NTA, based on Equation 3 with the value of NTAset to zero (e.g., for the purposes of initially triggering a RACH procedure by sending a preamble).

[0153] Any subsequent calculation and provision of the closed loop UE specific timing offset, NTA, by the base station 5A, while the GNSS is unavailable will, in effect, autocorrect for any errors in the calculation of arising, for example, from a difference between the actual UE position and the reference position. In summary, therefore, while GNSS is not available the UE 3 effectively uses a redefined formula in which is calculated by the UE 3 based on a reference position (e.g., cell coverage centre, configured by network) and serving satellite ephemeris related higher layer parameters if configured. This effectively corresponds to the round trip transmission delay between satellite and the reference position. Beneficially, this mechanism takes advantage of closed loop TA adjustment in which the base station 5A detects and compensates for the total timing error - including any part which arises from a difference between the actual UE position and the reference position error (i.e., the difference between the calculated based on the reference position and calculated based on the GNSS position). The base station 5A can then send a TAC in an RAR, or a TAC MAC CE, to the UE 3 in which the position error related timing error is reflected in the NTAcomponent.

[0154] Random Access (RA) Procedure Initiation As mentioned above, when an RA procedure needs to be initiated, a UE 3 without a valid GNSS (or no GNSS capability) may, beneficially, be configured to use a reference / common TA value (e.g., calculated using a reference position based timing component as described with reference to Fig. 8). This might occur in a number of different scenarios, for example, when a UE is in idle mode and needs to initiate initial access, or when a UE 3 needs to execute a RA procedure as part of a RACH-based handover.

[0155] Possible mechanisms for this will now be described in more detail with reference to Fig. 9, by way of example only.

[0156] Fig. 9 is a simplified sequence diagram illustrating timing adjustment mechanisms that may be implemented in the communication system 1 for triggering a random access procedure when GNSS positioning invalid, or a UE 3 has no GNSS positioning capability.

[0157] As seen in Fig. 9, the illustrated procedure assumes that, initially, the UE 3 has performed any appropriate downlink synchronisation in the cell 9 of the NTN RAN 5 and any available GNSS positioning information is either invalid / inaccurate or the UE 3 has no GNSS positioning capability and GNSS positioning is, therefore, unavailable (as indicated at S900).

[0158] The UE 3, in this example, receives system information at S902 that includes, amongst other information, information that may be used in the calculation of the reference / common TA value. For example, and as illustrated in Fig. 9, the system information may include information indicating the serving cell / RAN specific timing advance offset value, NTA,offsetdescribed above. Moreover, as illustrated in Fig. 9, the system information may include NTN UL synchronisation assistance information such as ephemeris related parameters and / or the TA common related parameters (e.g., TACommon, TACommonDrift, and TACommonDriftVariation) although it will be appreciated that this information may not always be configured by the network. In this example, the system information may also include information indicating the reference position (e.g., the cell coverage centre) that may be used for TA calculations in the event that GNSS is unavailable (although it will be appreciated that, alternatively or additionally, this information may be provided in another way).

[0159] It will be appreciated that whilst Fig. 9 shows this information being provided at the same time, for simplicity, the various information used in the calculation of the reference / common TA value need not be provided at the same time or in the same SIB. Typically, for example, the serving cell / RAN specific timing advance offset value, NTA,offset, may be provided in SIB1 whilst the NTN UL synchronisation assistance information may be provided in SIB19 (although the specific SIBs used may be different).

[0160] Fig. 9 illustrates two different scenarios that may occur when an RA procedure needs to be initiated.

[0161] In one example, illustrated in box S904-1, the UE 3 is (pre)configured, by the base station 5A, with one or more dedicated PRACH formats / separate PRACH resources specifically for use when no valid GNSS is available, or the UE 3 has no GNSS capability. For example, the preconfigured dedicated PRACH formats / separate PRACH resources may include one or more dedicated RACH occasions and / or one or more dedicate PRACH preambles.

[0162] In another example, illustrated in box S904-2, the UE 3 is not (pre)configured with one any dedicated PRACH formats / separate PRACH resources specifically for use when no valid GNSS is available, or the UE 3 has no GNSS capability - instead the UE 3 is only (pre)configured with one or more non-dedicated (legacy) PRACH formats / shared PRACH resources.

[0163] It will be appreciated that the different examples may be applicable in respect of different UEs 3 in the same communication system or may be applicable in respect of different RANs 5 with different PRACH configuration capabilities.

[0164] For a UE 3 that is (pre)configured with one or more dedicated PRACH formats / separate PRACH resources, as illustrated in box S904-1, when the UE 3 needs to initiate initial access but has and GNSS position has become invalid / inaccurate (e.g., by reference to a GNSS validity duration / timer) or the UE 3 simply has no GNSS capability, the UE 3 selects a dedicated PRACH format / separate PRACH resource (e.g., a dedicated RACH occasion and / or preamble) at S906-1. The UE 3 then initiates an RA procedure using the selected PRACH format / resource at S908-1. The transmission timing of the initial PRACH message (i.e., carrying a selected dedicated PRACH preamble) is configured based on a reference / common TA value calculated based on a network configured reference position (e.g., as described in more detail with reference to Fig. 8).

[0165] It will be appreciated that, as described in more detail later, initiation of an RA procedure using a dedicated PRACH format / separate PRACH resource may, nevertheless, be subject to some form of load balancing / load control which may prevent the RA procedure from being initiated (e.g., due to limited capacity).

[0166] For a UE 3 that is not (pre)configured with one or more dedicated PRACH formats / separate PRACH resources, as illustrated in box S904-2, when the UE 3 needs to initiate initial access but has and GNSS position has become invalid / inaccurate (e.g., by reference to a GNSS validity duration / timer) or the UE 3 simply has no GNSS capability, the UE 3 may still be able to initiate an RA procedure using a non-dedicated (legacy) PRACH format / shared PRACH resource using a transmission timing based on the reference / common TA value (e.g., as described in more detail with reference to Fig. 8). However, the initiation of the RA procedure based on the reference / common TA value may be restricted to a scenario in which the ability to do so has been implicitly, or explicitly, enabled by the base station 5A.

[0167] Specifically, if the use of the reference / common TA value has been has been implicitly, or explicitly, enabled by the base station 5A (at S906-2), then the UE 3 may initiate an RA procedure using the non-dedicated PRACH format / resource at S908-2b and a transmission timing based on the reference / common TA value calculated based on the network configured reference position (e.g., as described in more detail with reference to Fig. 8). If, on the other hand, the use of the reference / common TA value has not been implicitly, or explicitly, enabled by the base station 5A (at S906-2), then the RA procedure may not be initiated as indicated at S908-2a.

[0168] It will be appreciated that the use of the reference / common TA value may, for example, be enabled by an explicit indication provided by means of setting an 'enable' bit or flag in the system information (or via other signalling). Nevertheless, the use of the of the reference / common TA value may, for example, be enabled implicitly by including the reference location for calculation of the reference / common TA in the system information (or other signalling).

[0169] Load control of PRACH resource As mentioned above, if one or more dedicated PRACH formats / separate PRACH resources are introduced for the inaccurate / invalid GNSS and / or no GNSS capability scenario, there is the potential capacity that might be limited thereby necessitating some form of load control. It will be appreciated that to support this one or more criteria may be defined based on which a decision may be made as to whether a UE is allowed to use these PRACH formats / PRACH resource to trigger a RACH procedure (e.g., when GNSS failure occurs).

[0170] For example, for initial access, a unified access control (UAC) based mechanism may be used in which a UE 3 may first check if initial access is allowed based on, for example, an access category and / or an access identity configured for the UE 3 (e.g., stored at the UE 3, e.g., in a universal subscriber identity module), and / or on the access reason / cause. Alternatively, or additionally, a barring factor-based access control mechanism may be used in which the UE 3 selects ('draws') a random number and if that random number is lower (or conceivably higher) than a configured barring factor the UE 3 is allowed to initiate initial access.

[0171] For connected UE 3, on the other hand, the ability to use the dedicated PRACH formats / separate PRACH resources for RA procedure initiation may be enabled on a UE by UE basis by information provided, by the base station 5A, in an RRC configuration for the corresponding UE 3. Alternatively, or additionally, the ability to use the dedicated PRACH formats / separate PRACH resources for RA procedure initiation may be enabled and / or triggered by means of a PDCCH order. It will be appreciated that any such PDCCH order may potentially include information indicating the dedicated PRACH format / resource to be used.

[0172] Otherwise, the UE 3 may be prevented from initiating an RA procedure using a dedicated PRACH format / PRACH resource for the inaccurate / invalid GNSS and / or no GNSS capability scenario.

[0173] RRC Connected Switch to Use of a Reference / Common TA Value As mentioned above, during a period when GNSS has become unavailable or invalid, a UE 3 that is in RRC connected may report this to the base station 5A with appropriate assistance information and the base station 5A may trigger application of the reference / common TA (and may indicate the reference location) and / or an absolute NTA, to be applied upon the reference / common TA being adopted.

[0174] A possible mechanism for this will now be described in more detail with reference to Fig. 10, by way of example only.

[0175] Fig. 10 is a simplified sequence diagram illustrating a timing adjustment mechanism that may be implemented in the communication system 1 when the UE 3 is in an RRC connected state and GNSS positioning is invalid / unavailable.

[0176] As seen in Fig. 10, the illustrated procedure assumes that, initially, the UE 3 has performed any appropriate downlink synchronisation in the cell 9 of the NTN RAN 5.

[0177] The UE 3, in this example, receives system information at S1002 that includes, amongst other information, information that may be used in the calculation of the reference / common TA value. For example, and as illustrated in Fig. 9, the system information may include information indicating the serving cell / RAN specific timing advance offset value, NTA,offset, described above. Moreover, as illustrated in Fig. 9, the system information may include NTN UL synchronisation assistance information such as ephemeris related parameters and / or the TA common related parameters (e.g., TACommon, TACommonDrift, and TACommonDriftVariation) although it will be appreciated that this information may not always be configured by the network. In this example, the system information may also include information indicating the reference position (e.g., the cell coverage centre) that may be used for TA calculations in the event that GNSS is unavailable (although it will be appreciated that, alternatively or additionally, this information may be provided in another way).

[0178] It will be appreciated that whilst Fig. 10 shows this information being provided at the same time, for simplicity, the various information used in the calculation of the reference / common TA value need not be provided at the same time or in the same SIB. Typically, for example, the serving cell / RAN specific timing advance offset value, NTA,offset, may be provided in SIB1 whilst the NTN UL synchronisation assistance information may be provided in SIB19 (although the specific SIBs used may be different).

[0179] At S1004, the UE 3 enters an RRC connected state. It is assumed here that GNSS positioning is available during the RRC connection procedure. However, at some point, while still in RRC connected the GNSS positioning may become unavailable and / or available GNSS positioning information may become invalid / inaccurate (as indicated at S1000).

[0180] In this case the UE 3 sends (e.g., using an appropriate RRC message or the like) a message for providing appropriate assistance information to the base station 5A (e.g., the latest total TA adjustment (Tta)), latest position, moving speed, and / or the like), at S1006, for assisting the base station 5A to manage how transmission timing adjustment should continue at the UE 3. The assistance information may, for example, be provided in an appropriate reporting message sauch as, for example, a 'GNSS invalidity report', a 'used TA report', or the like.

[0181] In response, the base station 5A responds with a message (e.g., an appropriate RRC message or the like) for managing how transmission timing adjustment should continue at the UE 3 as indicated at S1008. This message may, for example, include information for triggering the UE 3 to apply the reference / common TA, may indicate the reference location to be used (e.g., instead of, or to replace, a reference location provided in the system information), and / or may include a TAC indicating an absolute NTAto be applied upon adoption of the reference / common TA.

[0182] The UE 3 then performs transmission time adjustment, at S1010 using a reference / common TA value that is calculated based on Equation 3 using the absolute NTAprovided in the TAC at S1008 (if included), the NTA,offsetbroadcast in system information, an estimated based on the TA common related parameters (if configured), and a value of calculated based on the reference position and any satellite ephemeris parameters (if configured) as described in more detail with reference to Fig. 8.

[0183] RRC Connected PRACH Transmission As mentioned above, when a UE 3 is in RRC connected and a GNSS signal becomes out of date, a GNSS position becomes invalid (e.g., based on a validity timer), GNSS accuracy is very low, and / or an accumulated NTAexceeds a threshold, the UE 3 may trigger an RA procedure, in which the UE 3 performs a PRACH transmission with a transmission timing based on an appropriate TA value (which may be derived using any of the techniques described earlier).

[0184] A possible mechanism for this will now be described in more detail with reference to Fig. 11, by way of example only.

[0185] Fig. 11 is a simplified sequence diagram illustrating another timing adjustment mechanism that may be implemented in the communication system 1 when the UE 3 is in an RRC connected state and GNSS positioning is invalid / unavailable.

[0186] As seen in Fig. 11, the illustrated procedure assumes that, initially, the UE 3 has performed any appropriate downlink synchronisation in the cell 9 of the NTN RAN 5.

[0187] The UE 3, in this example, receives system information at S1102 that includes, amongst other information, information that may be used in the calculation of the reference / common TA value. For example, and as illustrated in Fig. 9, the system information may include information indicating the serving cell / RAN specific timing advance offset value, NTA,offset, described above. Moreover, as illustrated in Fig. 9, the system information may include NTN UL synchronisation assistance information such as ephemeris related parameters and / or the TA common related parameters (e.g., TACommon, TACommonDrift, and TACommonDriftVariation) although it will be appreciated that this information may not always be configured by the network. In this example, the system information may also include information indicating the reference position (e.g., the cell coverage centre) that may be used for TA calculations in the event that GNSS is unavailable (although it will be appreciated that, alternatively or additionally, this information may not be provided, or may be provided in another way).

[0188] It will be appreciated that whilst Fig. 11 shows this information being provided at the same time, for simplicity, the various information used in the calculation of the reference / common TA value need not be provided at the same time or in the same SIB. Typically, for example, the serving cell / RAN specific timing advance offset value, NTA,offset, may be provided in SIB1 whilst the NTN UL synchronisation assistance information may be provided in SIB19 (although the specific SIBs used may be different).

[0189] At S1104, the UE 3 enters an RRC connected state. It is assumed here that GNSS positioning is available during the RRC connection procedure.

[0190] However, at some point, while still in RRC connected the GNSS signal may become out-of-date, the GNSS position may become invalid, the GNSS accuracy may become too low, and / or the accumulated NTA(arising from closed loop adjustment as described previously) may exceed a threshold. When one or more of these situations is detected at the UE 3 (as indicated at S1106) the UE 3 initiates a random access procedure by performing a PRACH transmission, with a timing based on an appropriate TA value (and effectively cause the base station 5A to ultimately provide an updated NTAin a TAC in an RAR).

[0191] As indicated in Fig. 11, there a number of ways in which the TA value used for the initial PRACH transmission may be determined. For example, the UE 3 may determine a reference / common TA value (e.g., as described with reference to Fig. 8), perform associated timing adjustment (at S1110-1), and thus perform the PRACH transmission based on the calculated reference / common TA value (at S1112-1).

[0192] Alternatively, the base station 5A may configure the TA value to be used e.g., by providing at least one component of the TA value and / or reference information (e.g., a reference position) via a PDCCH order (at S1111-2). This may occur, for example, when the base station 5A detects a RACH based TAC is necessary (e.g., because the NTAis becoming too large or because the UE 3 has provided an explicit report / indication of GNSS unavailability). The UE 3 may then determine the configured TA value based on the TA configuration provided by the base station 5A and perform associated timing adjustment (at S1110-2), and thus perform the PRACH transmission based on the configured TA value (at S1112-2).

[0193] The UE 3 may, alternatively, use the most recent TA value (i.e., determine the TA value based on the most recently acquired GNSS position as described with reference to Fig. 5), perform associated timing adjustment (at S1110-3), and thus perform the PRACH transmission based on the calculated most recent GNSS position based TA value (at S1112-3). 　　User Equipment

[0194] Fig. 12 is a simplified block schematic illustrating the main components of a UE 3 for implementation in the system of Fig. 1.

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

[0196] 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, a communications control module 43, a timing alignment module 45, and a GNSS acquisition module 47.

[0197] The communications control module 43 is operable to control the communication between the UE 3 and its serving base station or base stations 5A (and other communication devices connected to the base station 5A, such as further UEs 3 and / or core network nodes). The communications 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 communications 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 communications control module 43 is responsible, for example: for determining where to monitor for downlink control information; for determining the resources to be used by the UE 3 for transmission / reception of UL / DL communications (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the UE side; for determining how slots / symbols are configured (e.g., for UL, DL or full duplex communication, or the like); for determining which bandwidth parts are configured for the UE 3; for determining how uplink transmissions should be encoded and the like.

[0198] It will be appreciated that the communications control module 43 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communications 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.

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

[0200] The timing alignment module 45 is configured to perform, under the overall control of the communications control module 43, the UE side transmission timing adjustment, and timing alignment functions, described herein. These include, for example, the acquisition / calculation of the components of the TA value and related information, and the associated calculation of the TA value.

[0201] The GNSS acquisition module 47 is configured to perform, under the overall control of the communications control module 43, the acquisition of a GNSS position when GNSS positioning is available as described herein.

[0202] Base Station Fig. 13 is a simplified block schematic illustrating the main components of a base station 5A for implementation in the system of Fig. 1 (e.g. in an NTN access network or other such RAN 5).

[0203] 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 antenna 53 (e.g., a single or multi-panel antenna array / massive antenna), and a core network interface 55 for transmitting signals to and for receiving signals from network nodes in the core network 7. Although not shown, the base station 5A may also be coupled to other base stations via an appropriate interface (e.g., the so-called 'X2' interface in LTE or the 'Xn' interface in NR). The 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.

[0204] As shown, these software instructions include, among other things, an operating system 61, a communications control module 63, and a timing alignment module 65.

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

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

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

[0208] The timing alignment module 65 is configured to perform, under the overall control of the communications control module 63, the base station side uplink timing adjustment, and timing alignment functions, described herein. These include, for example, the calculation and provision of the components of the TA value provided by the base station (e.g., NTAand NTA,offset) and related information (e.g., NTN UL synchronisation assistance information).

[0209] Modifications and Alternatives Detailed examples been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above examples whilst still benefiting from the enhancements embodied therein.

[0210] It will be appreciated that description of features of and actions performed by a base station (or eNB or gNB), NTN nodes, and UEs may be applied equally to base stations and UEs that communicate in the terrestrial plane only (i.e. as part of a terrestrial RAN without features of an NTN RAN such as a gateway and space or airborne platform) as to base stations that communicate via a non-terrestrial plane.

[0211] Moreover, description of features of and actions performed by a base station (or eNB or gNB), apply equally to distributed type base stations as to non-distributed type base stations.

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

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

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

[0215] It will be appreciated that (re)establishment of an RRC Connection in NTN may be conditional on the UE having a valid GNSS position. For example, if a system information block that contains satellite assistance information for the serving cell (e.g., SIB31 or SIB31-NB for NB-IoT) is broadcast, a RRC connection may be initiated only if the UE has a valid GNSS position. Moreover, the UE may need to re-acquire the GNSS position before (re-)establishing the connection to avoid interruption during the connection.

[0216] When determining that the GNSS position has become out-of-date while RRC connected (e.g., on receiving an indication from the network or identifying that GNSS position has become out-of-date based on a timer), the UE may leave the RRC connected state (with an appropriate release cause e.g., set to 'other').

[0217] A GNSS validity duration information element may be used to indicate the remaining GNSS validity duration at the UE. The UE report may report this (i.e., the remaining time of the GNSS validity duration) in any of a number of different RRC messages to enable for network to know when the GNSS position is out-of-date and can, therefore, release the UE. The RRC messages may include, for example, RRC connection setup complete, RRC connection resume complete, RRC connection reconfiguration complete (HO case), and / or RRC connection reestablishment complete(this is also applicable to the narrowband (NB) equivalent messages).

[0218] It will be appreciated that for IOT NTN, in particular, there may be a need for improved GNSS operations in which a new GNSS position fix, for UE pre-compensation, may occur during long connection times for reduced power consumption. Nevertheless, the need is also applicable to the broader use case of long connection times in general. Therefore, it may be beneficial for the UE to be able to obtain a new GNSS-based position fix during an RRC connected mode.

[0219] To support this the UE may be able to send a GNSS fix time duration report to indicate the length of time duration it takes for the UE to re-acquire a GNSS position fix in connected mode. This may be reported in any of a number of different RRC messages from the UE to the network, used for GNSS measurement Gap / timer configuration. The RRC messages may include, for example, RRC connection setup complete, RRC connection resume complete, RRC connection reconfiguration complete (HO case), and / or RRC connection reestablishment complete (this is also applicable to the narrowband (NB) equivalent messages).

[0220] For both an aperiodic GNSS measurement gap triggered by a base station with a MAC CE and autonomous GNSS measurement, the base station may configure the length for GNSS measurement gap (by indicating a GNSS measurement gap / timer).

[0221] In addition to reporting the remaining GNSS validity duration in RRC messages during initial access / re-establishment / HO the UE may report the remaining GNSS validity duration by using a new MAC CE every time upon completing a GNSS fix operation in RRC connected.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0239] While the present disclosure has been particularly shown and described with reference to example embodiments thereof, the present disclosure is not limited to these example embodiments. It will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present disclosure as defined by the claims. And each embodiment can be appropriately combined with at least one of embodiments.

[0240] Each of the drawings or figures is merely an example to illustrate one or more example embodiments. Each figure may not be associated with only one particular example embodiment, but may be associated with one or more other example embodiments. As those of ordinary skill in the art will understand, various features or steps described with reference to any one of the figures can be combined with features or steps illustrated in one or more other figures, for example, to produce example embodiments that are not explicitly illustrated or described. Not all of the features or steps illustrated in any one of the figures to describe an example embodiment are necessarily essential, and some features or steps may be omitted. The order of the steps described in any of the figures may be changed as appropriate.

[0241] 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: 　　performing Global Navigation Satellite System (GNSS) acquisition; 　　resetting configuration regarding time alignment based on the performing GNSS acquisition; and 　　performing uplink transmission using the configuration regarding time alignment. 　　(Supplementary Note 2) 　　The method according to Supplementary Note 1, further comprising: 　　initiating a random access procedure to report a remaining validity duration of a GNSS position based on the GNSS acquisition. 　　(Supplementary Note 3) 　　The method according to Supplementary Note 1 or 2, wherein 　　the performing the GNSS acquisition is performed in a case where: 　　　　a GNSS position is unavailable at the UE, 　　　　a GNSS position becomes available after GNSS position has been unavailable, or 　　　　the GNSS acquisition is triggered by a network or the UE. 　　(Supplementary Note 4) 　　The method according to any one of Supplementary Notes 1 to 3, wherein 　　the reporting is performed in a case where a new GNSS position becomes valid. 　　(Supplementary Note 5) 　　The method according to any one of Supplementary Notes 1 to 4, wherein 　　the resetting is performed after the GNSS position is acquired. 　　(Supplementary Note 6) 　　The method according to Supplementary Notes 5, wherein 　　the resetting is performed after the GNSS position has been unavailable but before a new GNSS position is required. 　　(Supplementary Note 7) 　　The method according to any one of Supplementary Notes 1 to 6, wherein 　　the configuration regarding time alignment indicates a timing advance value which is based on a difference between: 　　　　a first quantity calculated by the UE based on an acquired GNSS position and a current UE location and, 　　　　a second quantity calculated by the UE based on a last GNSS position which is available by the UE and a corresponding UE location. 　　(Supplementary Note 8) 　　The method according to any one of Supplementary Notes 1 to 7, wherein 　　the resetting is performed by resetting a UE specific compensation component value to a reference position based compensation component value that is calculated based on a reference position of a satellite. 　　(Supplementary Note 9) 　　The method according to Supplementary Note 8, wherein 　　the reference position is configured by a network. 　　(Supplementary Note 10) 　　The method according to any one of Supplementary Notes 1 to 7, wherein 　　the resetting is performed by resetting at least one of: 　　　　a timing offset between uplink and downlink radio frames at the UE, NTA'to zero, 　　　　the NTA'to a last GNSS position which is available by the UE, or 　　　　the NTA'by subtracting from a current timing offset between uplink and downlink radio frames at the UE, a difference between: 　　　　　　a first quantity calculated by the UE based on an acquired GNSS position and a current UE location and, 　　　　　　a second quantity calculated by the UE based on a last GNSS position which is available by the UE and a corresponding UE location. 　　(Supplementary Note 11) 　　The method according to any one of Supplementary Notes 1 to 10, further comprising: 　　receiving ephemeris information relating to ephemeris of a satellite; and 　　estimating new configuration regarding timing advance based on an acquired GNSS position and the ephemeris information. 　　(Supplementary Note 12) 　　The method according to any one of Supplementary Notes 1 to 11, further comprising: 　　reporting, to a network, information of an event indicating that GNSS position is unavailable. 　　(Supplementary Note 13) 　　The method according to any one of Supplementary Notes 1 to 12, wherein 　　the UE includes at least one of: 　　　　a Bandwidth Limited (BL) UE, 　　　　a UE in enhanced coverage, and 　　　　a Narrowband(NB)-Internet of Things (IoT) UE. 　　(Supplementary Note 14) 　　A user equipment (UE), comprising: 　　means for performing Global Navigation Satellite System (GNSS) acquisition; 　　means for resetting configuration regarding time alignment; and 　　means for initiating a random access procedure to report a remaining validity duration of a GNSS position based on the GNSS acquisition.

[0242] This application is based upon and claims the benefit of priority from Great Britain patent application No. 2316833.9, filed on November 2, 2023, the disclosure of which is incorporated herein in its entirety by reference.

[0243] 1 communication system 3 UE 5 RAN 5A base station 5B gateway 5C non-terrestrial space (or air) borne platform 7 core network 9 cell 10 CPF 10-1 AMF 10-2 SMF 10-3 LMF 11 UPF 20 external data network 31 transceiver circuit 33 antenna 35 user interface 37 controller 39 memory 41 operating system 43 communications control module 45 timing alignment module 47 GNSS acquisition module 51 transceiver circuit 53 antenna 55 core network interface 57 controller 59 memory 61 operating system 63 communications control module 65 timing alignment module

Claims

1. A method performed by a user equipment (UE), the method comprising: 　　performing Global Navigation Satellite System (GNSS) acquisition; 　　resetting configuration regarding time alignment based on the performing GNSS acquisition; and 　　performing uplink transmission using the configuration regarding time alignment.

2. The method according to claim 1, further comprising: 　　initiating a random access procedure to report a remaining validity duration of a GNSS position based on the GNSS acquisition.

3. The method according to claim 1 or 2, wherein 　　the performing the GNSS acquisition is performed in a case where: 　　　　a GNSS position is unavailable at the UE, 　　　　a GNSS position becomes available after GNSS position has been unavailable, or 　　　　the GNSS acquisition is triggered by a network or the UE.

4. The method according to any one of claims 1 to 3, wherein 　　the reporting is performed in a case where a new GNSS position becomes valid.

5. The method according to any one of claims 1 to 4, wherein 　　the resetting is performed after the GNSS position is acquired.

6. The method according to claim 5, wherein 　　the resetting is performed after the GNSS position has been unavailable but before a new GNSS position is required.

7. The method according to any one of claims 1 to 6, wherein 　　the configuration regarding time alignment indicates a timing advance value which is based on a difference between: 　　　　a first quantity calculated by the UE based on an acquired GNSS position and a current UE location and, 　　　　a second quantity calculated by the UE based on a last GNSS position which is available by the UE and a corresponding UE location.

8. The method according to any one of claims 1 to 7, wherein 　　the resetting is performed by resetting a UE specific compensation component value to a reference position based compensation component value that is calculated based on a reference position of a satellite.

9. The method according to claim 8, wherein 　　the reference position is configured by a network.

10. The method according to any one of claims 1 to 7, wherein 　　the resetting is performed by resetting at least one of: 　　　　a timing offset between uplink and downlink radio frames at the UE, NTA'to zero, 　　　　the NTA'to a last GNSS position which is available by the UE, or 　　　　the NTA'by subtracting from a current timing offset between uplink and downlink radio frames at the UE, a difference between: 　　　　　　a first quantity calculated by the UE based on an acquired GNSS position and a current UE location and, 　　　　　　a second quantity calculated by the UE based on a last GNSS position which is available by the UE and a corresponding UE location.

11. The method according to any one of claims 1 to 10, further comprising: 　　receiving ephemeris information relating to ephemeris of a satellite; and 　　estimating new configuration regarding timing advance based on an acquired GNSS position and the ephemeris information.

12. The method according to any one of claims 1 to 11, further comprising: 　　reporting, to a network, information of an event indicating that GNSS position is unavailable.

13. The method according to any one of claims 1 to 12, wherein 　　the UE includes at least one of: 　　　　a Bandwidth Limited (BL) UE, 　　　　a UE in enhanced coverage, and 　　　　a Narrowband(NB)-Internet of Things (IoT) UE.

14. A user equipment (UE), comprising: 　　means for performing Global Navigation Satellite System (GNSS) acquisition; 　　means for resetting configuration regarding time alignment; and 　　means for initiating a random access procedure to report a remaining validity duration of a GNSS position based on the GNSS acquisition.

Images