Handling GNSS location information being not verified by a core network

Abstract

A method performed by an access network node is disclosed. The method includes receiving, from a user equipment (UE), information regarding a Global Navigation Satellite System (GNSS) location of the UE, the information being not verified by a core network; and forwarding, to another network node, the information regarding the GNSS location of the UE for determining a current location of the UE in a case where the UE moves to a target access network node.

Description

HANDLING GNSS LOCATION INFORMATION BEING NOT VERIFIED BY A CORE NETWORK

[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 the indication and verification of UE location in the network, in particular in the context of (but not limited to) 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, the 'NGMN 5G White Paper' V1.0 (NPL 2) by the Next Generation Mobile Networks (NGMN) Alliance, which document is available from https: / / www.ngmn.org / 5g-white-paper.html. 3GPP intends to support 5G by way of the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and the 3GPP NextGen core network.

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

[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 end-point 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] 3GPP Technical Report (TR) 38.811 (NPL 1) 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.

[0011] 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 act 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 synchronization signal 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 synchronization signal (PSS), secondary synchronization signal (SSS), and physical broadcast channel (PBCH).

[0016] The UE searches for and performs measurements on the SSB beams (e.g. of the synchronization signal reference signal received power, 'SS-RSRP', synchronization signal reference signal received quality, 'SS-RSRQ', and / or the synchronization 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] As a non-terrestrial platform serving a UE moves, discontinuous coverage for that UE can occur, even if the UE remains stationary, as a result of the service link dropping, e.g., due to the satellite movement. In addition to discontinuous coverage of this type, there could also be intermittent feeder link connectivity (for example with a gateway at an associated ground station) - e.g., in areas where it is not feasible to deploy a gateway or where deployment of the gateway is not cost effective.

[0018] Moreover, at different times different NTN platforms (and hence on-board base stations where present) may provide the feeder link and service link respectively. Specifically, for a UE at a given location, it is possible that one or multiple satellites may be circulating around and providing communication services for that UE at different times. Thus the UE will, effectively, see different base stations during different time windows. Similarly, one or multiple satellites may be circulating around the ground location of a gateway via which one or more feeder link connections are being provided meaning that the gateway feeder connectivity may be via different satellites (and, potentially, base stations in the case of a regenerative mode architecture).

[0019] When a UE attaches to a mobile network via a RAN, the base station of the RAN selects an appropriate core network for the UE taking into account, amongst other things, UE identifiers, the UE's selected public land mobile network (PLMN), and UE location information (including the serving cell as known to the serving RAN node).

[0020] As with terrestrial based communication systems, communication systems with satellite access need to be able to determine a UE's location in order to provide services (e.g., route traffic, support emergency calls, and / or the like) in accordance with the governing national or regional regulatory requirements applicable to that UE. This is made more complicated because whilst, with NTN it is possible to deploy very large cells over large portions of a continent (possibly even covering different countries), when providing services over entire continents with NTN, there is no "globally harmonised" set of requirements that overrules local ones. For the provision UE location information, the constraints are similar between NTN and terrestrial networks. Because of this, for NTN based systems, the same required granularity for UE location information (e.g., estimated via Global Navigation Satellite System (GNSS) measurements) are applicable as for terrestrial networks (TNs) - e.g., a precision of one TN macro cell (typically ~ 5 to 10km).

[0021] Network operators of NTN also need to know reliably the location information for a UE attached to the network in order to select an appropriate core network. Once an appropriate core network has been selected for a UE, it is possible to support some services subject to national regulations or other operational constraints. These services include, for example, public warning systems (PWSs), lawful interception (LI), emergency services (EMS), charging and tariff notifications, and or the like.

[0022] While a UE with GNSS capability may, hypothetically, send GNSS measurements to the RAN over RRC, relying only on the GNSS based location information reported by the UE is not considered reliable. UE reported location information (for example determined with a GNSS receiver), could be erroneous due to intentional (e.g., maliciously tampering by a user or by a 3rd party) or unintentional (e.g., interference) causes - hence it cannot be considered trusted by network operators. Accordingly, relying only on signalling GNSS measurements over RRC is, currently, not considered a viable solution to this issue.

[0023] Historically, to address this for TNs where the network may not be aware of a UE's location in advance, a network based cell identity based methodology, involving the AMF and LMF, was developed. This method involved verifying a reported UE location based on an identifier of the serving cell in combination with UE and / or RAN radio resource related measurements for improving the UE location estimate. Thus, for such TN cells, there has been no requirement for GNSS location related information. However, as NTN cells may be significantly larger than the ones of TNs (and may cover borders between two or more countries) such a cell identity based approach may not be sufficient to meet the required granularity (or to discriminate the country in which the UE is located). Moreover, this method is heavy in signalling and so verification may not be immediate.

[0024] There is, therefore, a need for reliable and efficient enhancements to network based methodologies for verifying reported UE location information. Currently it is envisaged that verification should be performed independently from any location information reported by the UE. Moreover, under current thinking, UE location information may be considered verified if a reported UE location is consistent with a network based assessment to within, say 5-10 km (similar to terrestrial network macro cell size) - i.e., sufficient to enable country discrimination and selection of an appropriate core network in order to support corresponding regulatory services (e.g., EMS, LI, PWS, charging / billing, and or the like).

[0025] Delays in network based verification have the potential to negatively impact (increase) latency for some services (i.e., because those services cannot be started until location is verified). Ideally, any enhancements to network based verification procedure should have no - or minimal - negative impact on the latency of the targeted services nor infringe privacy requirements that apply in respect of the UE location.

[0026] Moreover, enhancements to network based verification need to be considered in the context of a single satellite being used - i.e., where there can be no triangulation based on multiple satellites covering the UE at the same time. Single-satellite measurement methods can be particularly inaccurate resulting in additional delays to verification involving the AMF / LMF.

[0027] Enhancements are also being developed to support improved mobility / service continuity in various scenarios including, for example: mobility from an NTN cell to a TN cell; mobility between two NTN cells (with reduced signalling overhead); and improved support for handling discontinuous NTN coverage.

[0028] In addition to further enhancements to network verified UE location, it is also likely that future enhancements will need to be considered for: mobility from a TN cell to an NTN cell (previously considered enhancements having focussed on NTN to TN mobility - with TN priority); dual / multi-connectivity scenarios involving both a TN and an NTN cell (e.g., TN-NTN dual / multi-connectivity), or involving only NTN cells (e.g., NTN-NTN dual / multi-connectivity).

[0029] NPL 1: 3GPP Technical Report (TR) 38.811 NPL 2: NGMN 5G White Paper' V1.0

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

[0031] 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 airborne platforms used for implementing NTNs.

[0032] In one aspect there is provided a method performed by an access network node, the method comprising: 　　receiving, from a user equipment (UE), information regarding a Global Navigation Satellite System (GNSS) location of the UE, the information being not verified by a core network; and 　　forwarding, to another network node, the information regarding the GNSS location of the UE for determining a current location of the UE in a case where the UE moves to a target access network node.

[0033] In one aspect there is provided a method performed by a user equipment (UE), the method comprising: 　　transmitting, to an access network node, information regarding a Global Navigation Satellite System (GNSS) location of the UE, the information being not verified by a core network, wherein 　　the information regarding the GNSS location of the UE is forwarded from the access network node to another network node, for determining a current location of the UE in a case where the UE moves to a target access network node.

[0034] In one aspect there is provided an access network node, comprising: 　　means for receiving, from a user equipment (UE), information regarding a Global Navigation Satellite System (GNSS) location of the UE, the information being not verified by a core network; and 　　means for forwarding, to another network node, the information regarding the GNSS location of the UE for determining a current location of the UE in a case where the UE moves to a target access network node.

[0035] In one aspect there is provided a user equipment (UE) comprising: 　　means for transmitting, to an access network node, information regarding a Global Navigation Satellite System (GNSS) location of the UE, the information being not verified by a core network, wherein 　　the information regarding the GNSS location of the UE is forwarded from the access network node to another network node, for determining a current location of the UE in a case where the UE moves to a target access network node.

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

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

[0038] According to the present disclosure, it is possible to provide a method performed by an access network node, a method performed by a user equipment, a method performed by a core network node, an access network node, a user equipment, and a core network node.

[0039] Examples of the disclosure will now be described, by way of example, with reference to the accompanying drawings in which:

[0040] 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 illustrates a possible architecture of an NTN RAN;Fig. 3B illustrates a possible architecture of an NTN RAN;Fig. 3C illustrates a possible architecture of an NTN RAN;Fig. 4 is a simplified sequence diagram illustrating the RAN triggered handover procedure that may be implemented in the communication system of Fig. 1;Fig. 5 is a simplified sequence diagram illustrating the conditional handover procedure that may be implemented in the communication system of Fig. 1;Fig. 6 is a simplified sequence diagram illustrating a location services procedure that may be used in the communication system of Fig. 1;Fig. 7 is a simplified sequence diagram illustrating a procedure for provision of a UE location to a base station, and between base stations, that may be used in the communication system of Fig. 1;Fig. 8 is a simplified sequence diagram illustrating a procedure for provision of a UE location to a base station, to a core network, and to another base station, that may be used in the communication system of Fig. 1;Fig. 9 is a simplified sequence diagram illustrating a procedure for acquisition of a verified UE location at a base station, and the transfer of the verified location between base stations, that may be used in the communication system of Fig. 1;Fig. 10 is a simplified sequence diagram illustrating another procedure for acquisition of a verified UE location at a base station, and the transfer of the verified location between base stations, that may be used in the communication system of Fig. 1;Fig. 11 is a simplified sequence diagram illustrating a procedure for acquisition of a verified UE location at a base station, and the transfer of the verified location to a core network and to another base station, that may be used in the communication system of Fig. 1;Fig. 12 is a simplified sequence diagram illustrating a procedure for acquisition of a verified UE location at a base station, and the transfer of the verified location to the UE and to another base station, that may be used in the communication system of Fig. 1;Fig. 13 is a simplified sequence diagram illustrating a procedure for configuring base station side verification of location information that may be used in the communication system of Fig. 1;Fig. 14 is a simplified block schematic illustrating the main components of a user equipment that may be used in the communications system of Fig. 1;Fig. 15 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; andFig. 16 is a simplified block schematic illustrating the main components of a core network node that may be used in the communications system of Fig. 1.

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

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

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

[0044] 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 terrestrial network (TN) based RANs 5 rather than NTN RANs 5) and one or more other UEs 3.

[0045] 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 both 4G and 5G and / or later generations, and / or any other 3GPP or non-3GPP communication protocols.

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

[0047] 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 (e.g. Location Management Functions (LMFs) 10-3), and a number of other functions 10-n.

[0048] 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 reference point (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.

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

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

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

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

[0053] The LMF 10-3 is connected to the AMF 10-1 via 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.

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

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

[0056] The DL physical signals may include, for example, reference signals (RSs) and synchronization signals (SSs). A reference signal (sometimes known as a pilot signal) is a signal with a predefined special waveform known to both the UE 3 and the base station 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).

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

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

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

[0060] As seen in Fig. 2, the NTN RAN 5 comprises a base station 5A or 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).

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

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

[0063] Specifically, the base station 5A is able to provide satellite assistance information for the satellite as part of a dedicated system information block (SIB) that is broadcast to UEs 3 in a corresponding cell 9 of the NTN RAN 5 (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)).

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

[0065] 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 9 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 the N2, N3 interface / reference point etc.) is provided solely terrestrially.

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

[0067] The non-terrestrial (space or air borne) platform 5C transmits communications destined for and originating from the UEs 3 in each cell 9 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.

[0068] 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 the N2, N3 interface / reference point etc.) is provided solely terrestrially.

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

[0070] 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 the 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.

[0071] 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 both 4G and 5G, and / or later generations, and / or any other 3GPP or non-3GPP communication protocols.

[0072] For the purposes of description, when implemented in the communication system 1, the NTN RAN 5 will be described in terms of the regenerative architecture illustrated in Fig. 3C. 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.

[0073] < Mobility Procedures > 　　The UEs 3 and base station 5A of the communication system 1 are mutually configured for performing appropriate mobility procedures for transferring communication for the UE 3 from / to the base station 5A acting as a source / target base station 5A to / from another base station 5A (acting as a target / source base station 5A).

[0074] These mobility procedures include RAN centric handovers, based on direct communication over a base station to base station interface (e.g., X2, Xn or the like ), in which the network (source base station) determines the timing at which a handover should take place (e.g., based on measurements received from the UE 3). A typical RAN centric handover procedure involves a handover preparation phase during which, on making a decision that a UE 3 is to be handed over to a target base station 5A, the source base station 5A communicates over the base station to base station interface for preparation of resources in a target cell of the target base station 5A. This is followed (substantially immediately) by a handover execution phase during which the UE 3 receives the necessary parameters from, and is commanded by, the source base station 5A to perform the handover. The UE 3 then detaches from the cell 9 of the source base station 5A, and then synchronises to and accesses the target cell. When this has been successfully achieved the handover execution phase is essentially complete. The last phase is a handover completion phase during which the target base station 5A communicates with the core network 7 to switch communication to the target base station 5A. Once communication has been switched the target base station 5A initiates a UE context release at the source base station 5A to release the associated resources of the source base station 5A.

[0075] Considering the potential for very frequent handovers (especially in the context of earth moving cell scenarios) and the increasing number of UEs 3 to handover at the same time (in quasi-earth fixed cell scenario), a more UE centric handover procedure may also be used in the communication system 1. This type of handover is referred to as conditional handover (CHO). CHO is similar to RAN triggered X2 based handover but, in CHO, handover execution is de-coupled from handover preparation and may take place later when the UE 3 (rather than the source base station 5A) determines that it is time to do so. Specifically a CHO is a handover that is not executed until the UE 3 being handed over (rather than the network) determines that one or more handover execution conditions have been met. Once one or more handover execution conditions have been met the UE 3 then executes handover. The UE 3 starts evaluating the handover execution conditions upon receiving a CHO configuration from the network, and then stops evaluating the execution conditions once a handover has been executed.

[0076] < RAN Triggered Handover > 　　As mentioned above, the UEs 3 and RAN 5 of the communication system 1 are mutually configured for performing a RAN centric handover, based on direct communication over a base station to base station interface (e.g., X2, Xn or the like ), in which the source RAN 5 triggers handover.

[0077] An exemplary RAN triggered handover procedure that may be used in the communication system 1, will now be described, by way of example only, with reference to Fig. 4.

[0078] Fig. 4 is a simplified sequence diagram illustrating the RAN triggered handover procedure that may be implemented in the communication system 1.

[0079] Referring to Fig. 4, the RAN triggered handover procedure in this case concerns a handover of a UE 3 between a source cell 9 of a source base station 5A-1 and a target cell 9 of a target base station 5A-2.

[0080] Before the handover procedure starts, the source base station 5A-1 serving and communicating with the UE 3 at S402 (i.e., the source base station 5A-1 of the handover), will typically have a UE context for the UE 3 stored. This may include, for example, information regarding roaming and access restrictions which were provided either at establishment of the connection between the UE 3 and the source base station 5A-1 or at the last tracking area update.

[0081] The source base station 5A-1 configures measurement procedures to be performed by the UE 3, and the UE 3 reports according to the measurement configuration (at S412).

[0082] In the handover procedure a handover preparation phase S410 commences when the serving base station 5A-1 (operating as a source base station 5A-1) decides to initiate handover at S414. Specifically, the source base station 5A-1 makes a decision to handover the UE 3 to the target cell 9 of the target base station 5A-2 (at S414), for example based on measurement results received in a measurement report and / or radio resource management (RRM) information.

[0083] The source base station 5A-1 issues, at S416, a handover request, to the target base station 5A-2. This message will typically pass the necessary information, to the target base station 5A-2 in a transparent RRC container, for preparing the handover at the target side. The information may include, for example, the target cell ID, security information, a cell radio network temporary identifier (C-RNTI) of the UE 3 at the source base station 5A-1, RRM configuration information (e.g., including UE inactive time), basic access stratum (AS) configuration information including antenna information and downlink carrier frequency, current quality of service (QoS) flow to data radio bearer (DRB) mapping rules applied to the UE 3, the SIB1 from the source base station 5A-1, the UE capabilities for different RATs, protocol data unit (PDU) session related information, and / or UE reported measurement information including beam-related information if available.

[0084] While not shown, it will be appreciated that, admission control may be performed by the target base station 5A-2. Slice-aware admission control may, for example, be performed if corresponding slice information is sent to the target base station 5A-2 and if protocol data unit (PDU) sessions are associated with non-supported slices the target base station 5A-2 may reject such a PDU session.

[0085] The target base station 5A-2 prepares handover with its lower layers (L1 and L2) and sends, to the source base station 5A-1, an appropriate response (e.g., a handover request acknowledge message or the like) at S418. The response includes a transparent container to be sent to the UE 3 as an RRC message to be used as a handover command to instruct performance of the handover (e.g., an RRC reconfiguration message or the like).

[0086] The source base station 5A-1 triggers the handover by sending the RRC message (e.g., the RRC reconfiguration message or the like) to the UE 3 at S422. This RRC message contains the information required to access the target cell (e.g., the target cell ID, the new C-RNTI, the target base station security algorithm identifiers for the selected security algorithms and / or the like).

[0087] As soon as the source base station 5A-1 receives the response (e.g., the handover request acknowledge message or the like), or as soon as the transmission of the handover command (e.g., the RRC reconfiguration message or the like) is initiated in the downlink, data forwarding may be initiated.

[0088] A handover execution phase S420 is then initiated, and the UE 3 detaches from the source base station 5A-1 and synchronises to the target cell (at S426).

[0089] The UE 3 synchronises to the target cell and completes the handover procedure by sending an appropriate RRC message (e.g., an RRC Reconfiguration Complete message) to the target base station 5A-2 (S438).

[0090] The last phase is the handover completion phase during which the target base station 5A-2 coordinates with the core network 7 to switch communication to the target base station 5A-2 (at S450). Once communication has been switched the target base station 5A-2 initiates a UE context release at the source base station 5A-1 to release the associated resources of the source base station 5A-1 (e.g., by sending a UE context release message at S440).

[0091] < Conditional Handover > 　　As mentioned above, the UEs 3 and RAN 5 of the communication system 1 are mutually configured for performing conditional handover (CHO) when necessary.

[0092] An exemplary conditional handover (CHO) procedure that may be used in the communication system 1, will now be described, by way of example only, with reference to Fig. 5.

[0093] Fig. 5 is a simplified sequence diagram illustrating the conditional handover procedure that may be implemented in the communication system 1.

[0094] Referring to Fig. 5, the CHO procedure in this case concerns a handover of a UE 3 between a source cell 9 of a source base station 5A-1 and a target cell 9 (of potentially plural candidate cells 9) of a target base station 5A-2. The target base station 5A-2 may be one of a number of candidate base stations 5A-x, 5A-2 (i.e., candidates with the potential to become the target base station 5A-2 for the handover) each of which may operate one or more candidate cells 9 (i.e., candidates with the potential to be the target cell 9).

[0095] Before the CHO procedure starts, the base station 5A-1 serving and communicating with the UE 3 at S502 (i.e., the source base station 5A-1 of the CHO), will typically have a UE context for the UE 3 stored. This may include, for example, information regarding roaming and access restrictions which were provided either at establishment of the connection between the UE 3 and the base station 5A-1 or at the last tracking area update.

[0096] The source base station 5A-1 configures measurement procedures to be performed by the UE 3, and the UE 3 reports according to the measurement configuration (at S512).

[0097] In the conditional handover procedure a handover preparation phase S510 commences when the serving base station 5A-1 (operating as a source base station 5A-1) decides to prepare for conditional handover at S514. Specifically, the source base station 5A-1 makes a decision to configure the UE 3 for CHO (at S514), for example based on measurement results received in a measurement report and / or radio resource management (RRM) information.

[0098] Initially, the source base station 5A-1 initiates preparation of one or more candidate target base stations 5A-2 for handover by sending, at S516-x and / or S516-2, a respective handover request, to request CHO, for each of one or more candidate cells belonging to one or more of the candidate base stations 5A-x, 5A-2 including the target base station 5A-2. A CHO request message is sent for each candidate cell.

[0099] While not shown, it will be appreciated that, admission control may be performed by each candidate base station 5A-x, 5A-2. Slice-aware admission control may, for example, be performed if corresponding slice information is sent to that candidate base station 5A-x, 5A-2 and if protocol data unit (PDU) sessions are associated with non-supported slices that candidate base station 5A-x, 5A-2 may reject such a PDU session.

[0100] Each candidate base station 5A-x, 5A-2 sends, to the source base station 5A-1, a respective CHO response (e.g., a handover request acknowledge message or the like) for each CHO candidate cell (at S518-x, S518-2). Each CHO response includes a configuration for the corresponding CHO candidate cell (e.g., in an RRC reconfiguration message or the like).

[0101] The source base station 5A-1 sends an RRC reconfiguration message (e.g., an RRCReconfiguration message in 5G systems) to the UE 3 at S522. The RRC reconfiguration message includes information indicating the configuration for each CHO candidate cell and information indicating one or more CHO execution conditions determined by the source base station 5A-1. It will be appreciated that, although not illustrated, the CHO configuration of one or more candidate cells may be followed by other reconfiguration information from the source base station 5A-1.

[0102] The UE 3 sends an appropriate RRC reconfiguration complete message (e.g., an RRCReconfigurationCompletion message in 5G systems) to the source base station 5A-1 at S530 (effectively confirming the RRC reconfiguration).

[0103] The UE 3 maintains the connection with the source base station 5A-1 after receiving CHO configuration and starts evaluating the CHO execution conditions for one or more candidate cells (e.g., based on measurements performed by the UE 3) at S524. A handover execution phase S520 is not then initiated until one or more measurement results for at least one CHO candidate cell satisfies a corresponding CHO execution condition. When one or more CHO execution conditions have been met, the UE 3 detaches from the source base station 5A-1, applies the stored corresponding configuration for that selected candidate cell (which is the target cell of handover), and synchronises to that candidate (target) cell (at S526).

[0104] The UE 3 the performs an initial access procedure with the candidate (i.e., target) base station 5A-2 that operates the target cell, at S538. Specifically, the UE 3 sends a selected preamble (e.g., in 'Msg1') to the target base station 5A-2 over a random access channel (RACH) for initiating the process to obtain synchronisation in the uplink (UL). In response, the target base station 5A-2 responds with a RAR (or 'Msg2'). The RAR indicates reception of the preamble and includes a timing-alignment (TA) command for adjusting the transmission timing of the UE 3 based on the timing of the received preamble, and an uplink grant field indicating the resources to be used in the PUSCH (along with other information as appropriate). The UE 3 then sends an RRC reconfiguration complete message (e.g., an RRCReconfigurationCompletion message in 5G systems) as Msg3 to the network over a PUSCH based on the information in the RAR. This completes the RRC handover procedure. The UE 3 releases stored CHO configurations after successful completion of RRC handover procedure.

[0105] The target base station 5A-2 will then send, S540 a message indicating handover has been successful (e.g. a Handover Success message) to the source base station 5A-1 to inform the source base station 5A-1 that the UE 3 has successfully accessed the target cell. The source base station 5A-1 can then, if necessary, send (at S542-x) a message to cancel handover (e.g. a Handover Cancel message) for any other candidate cells of the target base station 5A-2, and / or of any other candidate base station 5A-x, to cancel the CHO for the UE 3 at that candidate base station 5A-x.

[0106] < Location Service Support > 　　The UEs 3, RAN 5, AMF 10-1, and LMF 10-3 of the communication system 1, are mutually configured for supporting positioning of a target UE 3 and delivery of location assistance data to a UE 3 with RAN access.

[0107] Specifically, the LMF 10-3 supports location determination for a UE 3. To facilitate UE location determination the LMF 10-3 can: obtain downlink location related measurements, or a location estimate from the UE 3; obtain uplink location measurements from the base station 5A of the RAN 5; and / or obtain non-UE associated assistance data from the base station 5A of the RAN 5.

[0108] For example, for positioning of a target UE 3, the LMF 10-3 may decide on the position methods to be used, based on factors that may include a location services (LCS) client type, a required QoS, UE positioning capabilities, and / or base station positioning capabilities. The LMF 10-3 may 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.

[0109] A typical location services procedure will now be described with reference to Fig. 6, which is a simplified sequence diagram illustrating a location services procedure that may be used in the communication system 1.

[0110] As seen at S601a, S601b and S601c, the procedures starts when a request is made to (or a need is determined at), for some location service (e.g. positioning) for a target UE 3, the serving AMF 10-1. A request may, for example, be made by some entity 15 in the core network 7 (e.g. a Gateway Mobile Location Centre (GMLC)) as indicated at S601a. Alternatively, or additionally, the serving AMF 10-1 for a target UE 3 may determines the need (effectively forming its own location service request) for some location service (e.g. to locate the UE 3 for an emergency call) as indicated at S601b. Alternatively, or additionally, the UE 3 may request some location service (e.g. positioning or delivery of assistance data) to the serving AMF 10-1 at the NAS level as indicated at S601c. In response to the request / determined need, the AMF 10-1 transfers (at S602) a corresponding location service request to an LMF 10-3.

[0111] The LMF 10-3 then instigates one or more location procedures at S603a and / or S603b. The LMF 10-3 may, for example, instigate one or more location procedures with the base station of the serving RAN 5 (and possibly one or more base stations of one or more neighbouring RANs 5), for example to obtain positioning measurements and / or assistance data (as indicated at S603a). Alternatively, or additionally, the LMF 10-3 may instigate one or more location procedures with the UE 3, for example to obtain a location estimate and / or positioning measurements, and / or to transfer location assistance data to the UE 3.

[0112] The LMF 10-3 provides, at S604, an appropriate location service response to the AMF 10-1 and includes, in the response, any needed results (e.g., a success or failure indication and, if requested and obtained, a location estimate for the UE 3).

[0113] The AMF 10-1 then responds depending on the origin of the original location service request. For example, if a location service request was received from some entity 15 in the core network 7 (e.g. a GMLC) as indicated at S601a, the AMF 10-1 returns (at S605a) a location service response to the some entity 15 and includes any needed results, for example a location estimate for the UE 3. If a location service request originated from a need determined by the AMF 10-1 as indicated at S601b, the AMF 10-1 uses the location service response received at S604 to assist the service that triggered this at S601b (e.g., the AMF 10-1 may provide a location estimate associated with an emergency call to a GMLC). If a location service request was received from the UE 3 at S601c, the AMF 10-1 may return a location service response to the UE 3 and includes any needed results (e.g., a location estimate for the UE. 3).

[0114] It will be appreciated that location procedures applicable to the base station 5A / RAN 5 occur at both S603a and S603b.

[0115] It will be appreciated that when the AMF 10-1 receives a location service request in respect of a UE 3 in an idle state, the AMF 10-1 may perform a network triggered service request in order to establish a signalling connection with the UE 3 and assign a specific serving base station 5A-1. The UE 3 is assumed to be in a connected mode before the beginning of the flow shown in Fig. 6 and so any signalling that might be required to bring the UE 3 into a connected state prior to S601a is not shown. The signalling connection may be released later (e.g., by the RAN 5 / base station 5A as a result of signalling and data inactivity) while positioning is still ongoing.

[0116] < Provision of UE Location Indication and Verification in the Network > 　　Historically, the network may not know the UE location in advance and the procedure to assess it, involving the AMF 10-1 and LMF 10-3, is relatively heavy in signalling overhead and takes some time. Accordingly, verification may not be immediate, especially with inaccurate single-satellite measurement methods. This is not ideal for some services, e.g., those that need UE location to be obtained to meet local legal requirements and so verification of a UE location, as soon as reasonably possible, is desirable.

[0117] Whilst, historically, for TN cells 9, there was no perceived need for a UE 3 to have a GNSS capability or for a UE 3 derived location to be provided, a TN cell 9 may be the last link before a UE 3 moves to an NTN cell 9. The base station 5A operating the TN cell 9 may provide NTN information to UE 3 (that is relevant to determining the UE's location) and / or may provide UE location related information to another base station 5A and / or the core network 7.

[0118] Beneficially, the communication system 1 includes a number of enhancements for supporting provision of UE location information to the network and verification of the UE location in the network. These enhancements include: 　　　　Enhancements for supporting relatively fast acquisition of a UE's location; 　　　　Enhancements for supporting location verification at the base station 5A (e.g., at lower layers) without requiring direct involvement from the AMF 10-1 and / or LMF 10-3; and 　　　　Enhancements for supporting the sharing of location information (e.g., verified at the base station 5A) with the core network 7.

[0119] These enhancements will now be summarised, by way of example only, before specific exemplary implementations are described in more detail.

[0120] It will be appreciated that the enhancements described are not mutually exclusive and all, or a subset of the enhancements, may be incorporated into a communication system to provide a commensurate benefit. Nevertheless, the examples are also not reliant on one another and so may be implemented in the communication system individually.

[0121] < Supporting Provision of Location Information > 　　Beneficially, as will be described in more detail later, the communication system 1 includes enhancements for supporting relatively fast acquisition of a UE's location. Specifically, the communication system 1 is configured to take advantage of the fact that UEs 3 often have a GNSS capability (especially those that are capable of communicating in existing NTN based systems) and so a GNSS capable UE 3 such as this is able to provide a GNSS based location to a base station 5A of a terrestrial network (TN) before being switched to a non-terrestrial network (NTN).

[0122] In more detail the UE 3 and base station 5A are mutually configured for the provision, by the UE 3, of (unverified) GNSS location information to the network (e.g., to the base station 5A and / or to the core network 7 via the base station 5A) before a switch to an NTN cell 9 (from a TN cell 9 or an NTN cell 9). This information does not, necessarily, have to be passed on to the AMF 10-1 / LMF 10-3 for network based verification (although it can be). From the network's perspective, the location can be treated as a type that is verified at a later point in time, or a type that remains unverified.

[0123] This contrasts with previous systems in which even a trusted UE 3 is not expected to know its own location and, instead, location is determined / verified by the core network 7 (e.g., based on RRC measurements and cell ID) provided to the AMF 10-1 / LMF 10-3.

[0124] Nevertheless, it has been realised that the relatively fast acquisition of even an unverified UE location (e.g., GNSS location) can be beneficial (even from a currently untrusted UE 3). For example, provision of such a location can be helpful for use in a simple "verification" procedure in which a UE 3 is generally treated as being "trusted" and the network (base station 5A or core network entity such as the AMF 10-1 / LMF 10-3) compares the UE provided location with a location provided using a positioning method known to be potentially inaccurate (e.g., because of the very large cell size known to be associated with NTN). If the UE provided location and the location provided using a less accurate positioning method are consistent with one another then the UE provided location can be treated as verified (or verified to a certain level of confidence). Similarly, in case where the UE 3 moves significantly, using a UE provided location may be useful. For example, a UE 3 could be considered to be a trusted UE 3 (for which no, or simpler, verification is required) at some point in time after which more complex (and hence time consuming) network-based positioning methods are deemed to be unnecessary.

[0125] It will be appreciated that while this provision of UE derived location information (and associated verification), is particularly beneficial in the context of NTN systems where the information for a UE 3 belonging to a certain NTN cell 9 can be particularly inaccurate, the provision of UE location in this way can be beneficial in the context of purely TN systems, e.g., for providing a more precise UE location (without verification).

[0126] In one example described in more detail later, the UE 3 is configured to provide the UE location information as part of a handover procedure (e.g., from a TN cell 9 to an NTN cell 9, or between NTN cells 9). Specifically, the (unverified) GNSS location may be provided during a (conditional) handover preparation phase of a handover procedure similar to that described with reference to Fig. 4 or Fig. 5, for example in response to a request, from the source base station, for the UE GNSS location. In response to the request, the UE 3 can provide its latest known GNSS location. The information identifying the GNSS location may be provided together with information identifying a positioning integrity and / or an associated time stamp. The positioning integrity is effectively a measure of the trust in the accuracy of the position-related data and the ability to provide associated alerts (which is different from a verified location). During the handover procedure (conditional or RAN triggered), the source base station 5A-1 provides the received GNSS location (and potentially any positioning integrity and / or time stamp) to the target base station 5A-2 (e.g., via the base station to base station (Xn / X2) interface).

[0127] In one example described in more detail later, the UE 3 and base station 5A are configured for provision of the UE location (e.g., GNSS location) as part of a UE context (e.g., part of a UE context that is established during initial access). Specifically, in this example, the UE 3 is configured to provide the UE location information to the base station 5A as part of the UE context. The UE provided location information may then be forwarded to the core network 7 for storage. When the UE 3 subsequently joins a new cell 9 (e.g., an NTN cell 9), the base station 5A that operates the new cell may send a request to the core network 7 for the stored UE location information for that UE 3. It will be appreciated that this can be used for TN-TN mobility, although the precise location may have changed significantly as a relative proportion of the TN cell size in this context.

[0128] It will be appreciated that the provision of the UE location information during handover, and the provision of the UE location as part of a UE context, are not mutually exclusive examples. Nevertheless, the examples are not reliant on each other and either example may be implemented in the communication system 1 individually to derive a commensurate benefit.

[0129] < Location Verification at Base Station (e.g., by lower layers) > 　　Beneficially, as will be described in more detail later, the communication system 1 includes enhancements for supporting location verification at the base station 5A (e.g., at lower layers). Specifically, the UE 3 and base station 5A are configured to support verification at the base station 5A, without coordination with, or assistance from, the LMF 10-3.

[0130] These enhancements take advantage of the fact that, for lower mobility UEs switching to an NTN cell 9 / beam, and switching between NTN cells 9 / beams (e.g., between different cells / beams of the same satellite, or of different satellites), the switching (e.g., of at least a service link) may not impact the positioning process significantly. Accordingly, accuracy can be increased by acquiring measurements over time with one or multiple satellites.

[0131] Accordingly, in one example, the base station 5A may determine (and verify) a UE location based on measurements taken, over time, in respect of one or more satellites. It can be seen, therefore, that multiple base stations and / or satellites may thus be involved even when, at a particular time, only a single satellite can be used for verification.

[0132] Every new measurement may be treated as additional location related (e.g., measurement) information that is accumulated over time as the coverage area of one or more satellites moves relative to the UE 3 (even though the UE 3 may not move significantly). In this context, "(verified) location information" may thus comprises a plurality of sets of measurements, e.g., with associated time stamps and / or positioning precision / integrity information. The accumulated (verified) UE location information may be transferred from one (source) base station 5A-1 to the next (target base station 5A-2) either directly via a base station to base station interface (e.g., Xn interface or the like), or indirectly via the UE 3 and / or core network 7. The target base station 5A-2 may request the accumulated (verified) UE location information from the communication entity (e.g., source base station 5A-1, UE 3, or core network entity) from which it obtains the accumulated (verified) UE location information. Nevertheless, the accumulated (verified) UE location information may be provided automatically (e.g., as an automatic part of a handover procedure or other procedure during which a UE 3 joins / accesses a cell 9 of the target base station 5A-2).

[0133] It can be seen, therefore, that use of accumulated (verified) UE location information has the potential to achieve significantly improved precision, e.g., effectively based on triangulation based on information for successive satellites (or for different cells / beams of the same satellite).

[0134] It will be appreciated that in the event of discontinuous NTN coverage for the UE 3, there may be a gap during which location related measurement data and / or other location related information cannot be acquired. This has the potential to affect the validity of the location information and to alleviate this possible issue, in the event of discontinuous coverage causing a lack of up-to-date location information, a reply to a base station's request for (verified) UE location information request may indicate the lack of available information (e.g., in the form of an information element indicating "No valid or up-to-date information available" or the like).

[0135] It will also be appreciated that a satellite switch could occur relatively frequently, and the forwarded (verified) location information may or may not be in a verified state at the time it is transferred. For example, the source base station 5A-1 may provide previously acquired unverified location information to be kept up to date by the next base station 5A (e.g., effectively sharing a "work in progress" towards verification of a not yet fully verified UE location). In this context it will be understood, that "verified" UE location information refers to a UE location known to the network, which has been verified and / or is trusted (e.g., to a predefined level of precision / positioning integrity) form the network's perspective. Accordingly, initially, the verification state for the UE's location may be unverified or "no verified information". Similarly, after a relatively long period (e.g., without updated UE location information) the verification state for the UE's location may become unverified or "no verified information". It will also be appreciated that, the accumulated (verified) UE location information may also include a positioning integrity (e.g., precision) target (e.g., preconfigured by the core network 7) against which the unverified / verified state of the UE location can be assessed.

[0136] < Base Station Side Verification of Location Information and Sharing with Core Network > 　　Beneficially, as will be described in more detail later, the communication system 1 includes enhancements for supporting the sharing of that UE location information by the base station 5A with the core network 7. The shared UE location information may be UE location information partially or fully verified at the base station 5A as described above.

[0137] Specifically, in this example, following some form of UE location information acquisition and / or verification at the base station 5A, the base station 5A is triggered to provide the location information back to the core network 7 (e.g., the AMF 10-1 and / or LMF 10-3). For example, the base station 5A may be configured to share the UE location information with the core network 7 (e.g., the LMF 10-3) when requested, or configured, to do so by the core network 7, or once verified by the base station 5A.

[0138] In this case, while verification of the UE location may take place at the base station 5A, the process to be used for acquisition / verification of the UE location at the base station 5A is determined in the core network 7 (e.g., initiated by the LMF 10-3 and implemented by the AMF 10-1).

[0139] From the base station's perspective, the verification process could result from an explicit (optional) request from the core network 7 for a specific UE 3 with conditions for reporting location information back to the core network 7 being set up by the request. The information defining the conditions could, for example, set a positioning integrity target (or alternatively a default one could be used). Similarly, the procedure could be configured by the core network 7 as an optional procedure (with a default or configurable positioning integrity target) that may be carried out for all UEs 3.

[0140] The actual positioning verification could potentially be a lengthy procedure and somewhat unpredictable due to the nature of the operation, especially with inaccurate single-satellite measurements. The procedure could also vary depending on satellite altitude (e.g., between HAPs, LEO and / or MEO NTN platforms).

[0141] Hence, once verification requirements have been configured by the core network 7, the verification process can be achieved independently of the location service requests typically used in historic legacy systems. For example, while the procedure may be initialised by the LMF 10-3, the core network 7 does not expect a timely reply and it is not clear when a desired verification will be achieved.

[0142] In more detail rather than the UE location information being provided as a result of a specific location service request, the base station 5A is configured with one or more reporting triggers for reporting the UE location information back to the core network 7. For example, the base station 5A may be configured with one or more of the following triggers in any appropriate combination: 　　A trigger for reporting the UE location information on "verification" of the UE location at the base station 5A (e.g., when the positioning integrity falls below a target threshold); 　　A trigger for only reporting the UE location information in accordance with a configured period, and / or on explicit request (e.g., the base station 5A may constantly monitor one or more UEs' location and report the associated UE location information periodically or upon explicit request); 　　A trigger for reporting UE location information automatically only after the associated UE's location has been verified; 　　A trigger for providing an alert (e.g., to the core network 7) if a verification status for the UE location changes from verified to unverified (e.g., as a result of the most recent measurements that indicate a location that is inconsistent with a location indicated by previous measurements because the UE 3 has moved over time); 　　A trigger to report a verified UE location should that verified UE location change by a certain preconfigured amount (e.g., every 5-10km for consistency with a network definition of "verified location") - this is particularly useful to ensure the core network 7 has up to date UE location information because otherwise the base station lower layers may maintain an accurate but moving UE location while the UE location at the core network 7 becomes outdated; and / or 　　A trigger to report a (verified) UE location based on the UE's location reaching or transiting certain positions (e.g., a geographical border between states and / or countries).

[0143] < Supporting Provision of Location Information (exemplary procedures) > 　　As mentioned above, the communication system 1 includes enhancements for supporting relatively fast acquisition of a UE's location and, in particular, a UE's GNSS based location.

[0144] Possible implementations of such enhancements will now be described in more detail, by way of example only, with reference to Figs. 7 and 8.

[0145] Fig. 7 is a simplified sequence diagram illustrating a procedure for provision of a UE location to a base station 5A, and between base stations 5A, that may be used in the communication system 1.

[0146] In the example of Fig. 7, the UE 3 provides an (unverified) UE location (in this example a GNSS UE location) to the network as part of a handover procedure (e.g., a RAN based handover as described with reference to Fig. 4, or a conditional handover as described with reference to Fig. 5). It will be appreciated that both the source cell 9-1 and target cell 9-2 in this example may be either a cell of a TN RAN 5, or a cell of an NTN RAN 5, albeit that the method is particularly advantageous in the context of a handover to an NTN RAN 5.

[0147] Specifically, as seen at S700-1 during or just before the handover preparation phase (e.g., in a manner analogous to the measurement control and reporting that takes place during conventional handover but with location information being provided instead), the source base station 5A-1 requests the UE location from the UE 3. The source base station 5A-1 also coordinates with the target base station 5A-2 to prepare handover as seen at S700-2 (e.g., as described with reference to Fig. 4 or Fig. 5). It will be appreciated that the request for the UE location may be made in any suitable way. For example, the request may use an 'on-demand' mechanism that is similar to the mechanism for provision of 'on-demand' measurement reports from the UE 3. However, in this case the content would be the UE (GNSS) location (and potentially any positioning integrity and / or time stamp). Nevertheless, it will be appreciated, that rather than making an explicit request every time UE location is required, an automated regular or triggered UE location reporting mechanism may be (pre)configured. For example, the UE 3 could be configured (preconfigured or configured by the network) to send a UE location at a regular interval (e.g. "every minute" or the like) or to trigger the sending of a UE location when a particular condition is fulfilled (e.g., "if location changed too much" or the like). The reported information could then be stored as part of the UE context.

[0148] In response to the request for the UE location, the UE 3 (assuming it is capable of doing so) provides the UE location (and possibly an associated positioning integrity / precision and / or time stamp) to the source base station 5A-1 at S702-1 (e.g., in an appropriate RRC message with an information element including the UE location information, or the like). The source base station 5A-1 can then forward the UE location (including any associated positioning integrity / precision and / or time stamp) to the target base station 5A-2 over a base station to base station interface (e.g., the Xn interface or similar) as part of the remaining handover procedure at S702-2. The UE location information may, for example, be forwarded using a base station to base station interface (e.g., Xn) handover request from the source base station 5A-1 to the target base station 5A-2 (e.g., similar to that shown at S416 in Fig. 4 or S516 in Fig. 5).

[0149] Fig. 8 is a simplified sequence diagram illustrating a procedure for provision of a UE location to a base station 5A-1, to a core network 7, and to another base station 5A-2, that may be used in the communication system 1. It will be appreciated while the initial cell 9-1 new cell 9-2 in this example are, respectively, a cell 9 of a TN RAN 5 and a cell 9 of an NTN RAN 5, the method may also be used for a TN-to-TN mobility procedure.

[0150] In the example of Fig. 8, the UE 3 provides an (unverified) UE location (in this example a GNSS UE location), and possibly an associated positioning integrity / precision and / or time stamp, to a TN base station 5A-1 as part of the UEs context at S800-1 (e.g., in an appropriate RRC message with an information element including the UE location information, or the like). The TN base station 5A-1 then forwards this information to the core network 7 at S800-2 and the forwarded information is stored in the core network 7 (e.g., in an appropriate message over the interface with the AMF 10-1 (e.g., an NGAP message) during a UE context modification procedure).

[0151] Later, when the UE 3 joins a new cell 9-2 (in this example an NTN cell) at S804, the new base station 5A-2 that operates that cell 9-2 may request the UE location from the core network 7 at S806-1. In response to the request the core network 7 provides the stored UE location to the new base station 5A-2 at S806-2. The UE location information may, for example, be provided as part of an initial UE Context setup procedure over the interface with the AMF 10-1 (e.g., NGAP interface). It will, nevertheless, be appreciated that the new base station 5A-2 may not solicit the UE location from the AMF 10-1 using an explicit request. The AMF 10-1 may, for example, automatically provide the UE location information (e.g., as part of a UE context setup request), if the UE location information is available.

[0152] < Location Verification at Base Station (exemplary procedures) > 　　As mentioned above, the communication system 1 includes enhancements for supporting location verification at the base station 5A (e.g., at lower layers).

[0153] Possible implementations of such enhancements will now be described in more detail, by way of example only, with reference to Figs. 9 to 12.

[0154] Fig. 9 is a simplified sequence diagram illustrating a procedure for acquisition of a verified UE location at a base station 5A, and the transfer of the verified location between base stations 5A, that may be used in the communication system 1. In this example, the source cell 9-1 is a cell 9 of a RAN 5-1 that is a TN RAN 5 and the target cell 9-2 is a cell 9 of a RAN 5-2 that may be either a TN based RAN 5, or an NTN based RAN 5.

[0155] In this example, as the source cell 9-1 is a TN cell 9, the UE location can be determined fairly precisely from information such the timing advance (TA) for that UE 3 (as this is indicative of distance from the corresponding TN base station 5A-1) and / or information indicating a beam and / or sector of the cell 9-1 in which the UE 3 is located. It can be seen, therefore, that a UE location derived from such information can meet (and exceed) any precision criteria for early location verification relatively quickly and efficiently.

[0156] Accordingly, in the example of Fig. 9, a relatively precise verified UE location is acquired by the source base station 5A-1 for the UE 3 at S900. This verified location is based on UE location information determined for the UE 3 which may include information such as the TA (or a distance derived from it) and / or information indicating the beam and / or sector of the cell 9 (although it will be appreciated that other information may additionally or alternatively be used, e.g., measurement results received from the UE 3 in respect of reference signals from the source cell 9-1 and / or other cells). This verified UE location can be maintained at the source base station 5A-1 before switching cell 9 (e.g., as part of a RAN based or conditional handover procedure).

[0157] When the UE 3 moves to a target cell 9-2 (e.g., an NTN cell) operated by a target (e.g., NTN) base station 5A-2 (as indicated at S904), the target base station 5A-2 can obtain (e.g., as part of a handover procedure), the verified UE location information from the source base station 5A-1. It will be appreciated that the move to the target cell 9-2 may not arise (entirely) from movement of the UE 3 itself but may arise from movement of an NTN cell relative to the UE 3. The verified UE location information may be explicitly requested (as indicated at S906-1) and provided by the source base station 5A-1 (as indicated at S906-2) in response to the explicit request. Nevertheless, the source base station 5A-1 may provide the verified UE location information automatically at S906-2 (e.g., as part of a handover procedure) without requiring an explicit request.

[0158] Fig. 10 is a simplified sequence diagram illustrating another procedure for acquisition of a verified UE location at a base station 5A, and the transfer of the verified location between base stations, that may be used in the communication system 1. In this example, the source cell 9-1 is a cell 9 of a RAN 5-1 that is an NTN RAN 5 and the target cell 9-2 is a cell 9 of a RAN 5-2 that is also an NTN RAN 5.

[0159] As seen in Fig. 10, a verified UE location is acquired by the source base station 5A-1 for the UE 3 at S1000. The verified UE location in this case may be based on multiple measurements (e.g., performed over time as the cell 9-1 moves relative to the UE 3 as described above in the subsection titled "Location Verification at Base Station (e.g., by lower layers)"). This verified UE location can be maintained at the source base station 5A-1 before switching cell 9 (e.g., as part of a RAN based or conditional handover procedure).

[0160] When the UE 3 moves to a target cell 9-2 operated by a target base station 5A-2 (as indicated at S1004), the target base station 5A-2 can obtain (e.g., as part of a handover procedure), the verified UE location information from the source base station 5A-1. It will be appreciated that the move to the target cell 9-2 may not arise (entirely) from movement of the UE 3 itself but may arise from movement of an NTN cell relative to the UE 3. The verified UE location information may be explicitly requested (as indicated at S1006-1) and provided by the source base station 5A-1 (as indicated at S1006-2) in response to the explicit request. Nevertheless, the source base station 5A-1 may provide the verified UE location information automatically at S1006-2 (e.g., as part of a handover procedure) without requiring an explicit request.

[0161] Fig. 11 is a simplified sequence diagram illustrating a procedure for acquisition of a verified UE location at a base station 5A-1, and the transfer of the verified location to a core network 7 and to another base station 5A-2, that may be used in the communication system 1. In this example, the source cell 9-1 is a cell 9 of a RAN 5-1 that is an NTN RAN 5 and the target cell 9-2 is a cell 9 of a RAN 5-2 that is also an NTN RAN 5.

[0162] As seen in Fig. 11, a verified UE location is acquired by the source base station 5A-1 for the UE 3 at S1100. The verified UE location in this case may be based on multiple measurements (e.g., performed over time as the cell 9-1 moves relative to the UE 3 as described above in the subsection titled "Location Verification at Base Station (e.g., by lower layers)"). This verified UE location can be maintained at the source base station 5A-1 until the UE 3 leaves the source cell 9-1 as indicated at S1101 (e.g., as a result of discontinuous coverage, suspension of an RRC connection, and / or the like).

[0163] In this example, when the UE 3 leaves the source cell 9-1 at S1101, the source base station 5A-1 provides the verified UE location information to the core network 7 at S1006-2 where the verified UE location information is stored. For example, the verified UE location information may be provided to the AMF 10-1 (and onto the LMF 10-3). The UE location information may, nevertheless, be stored at the AMF 10-1 (e.g., once the LMF 10-3 has determined allocation) as the AMF 10-1 will be the entity at the interface with the target base station 5A-2 (and also upper layers).

[0164] When the UE 3 moves to a target cell 9-2 operated by a target base station 5A-2 (as indicated at S1104), the target base station 5A-2 can obtain (e.g., as part of a procedure to (re)establish / resume a UE's connection in the target cell 9-2), the verified UE location information from the core network 7. It will be appreciated that the move to the target cell 9-2 may not arise (entirely) from movement of the UE 3 itself but may arise from movement of an NTN cell 9 relative to the UE 3. The verified UE location information may be explicitly requested from the core network 7 (as indicated at S1106-1) and provided by the core network 7 (as indicated at S1106-2) in response to the explicit request. Nevertheless, the core network 7 may provide the verified UE location information automatically at S1106-2 (e.g., as part of a procedure to (re)establish / resume a UE's connection in the target cell 9-2) without requiring an explicit request.

[0165] It will be appreciated that in the case of discontinuous NTN coverage, when there may be a potentially significant time gap before coverage resumption that could affect the validity of the verified UE location information, this could be indicated to the target base station 5A-2 at S1006-2 (e.g., using an indication of "No valid or up-to-date information available" or the like as mentioned above). It will also be appreciated that this indication may be provided instead of providing the (requested) verified UE location information at S1006-2, or together with the (requested) verified UE location information at S1006-2.

[0166] Fig. 12 is a simplified sequence diagram illustrating a procedure for acquisition of a verified UE location at a base station 5A-1, and the transfer of the verified location to the UE 3 and to another base station 5A-2, that may be used in the communication system 1. In this example, the source cell 9-1 is a cell 9 of a RAN 5-1 that is an NTN RAN 5 and the target cell 9-2 is a cell 9 of a RAN 5-2 that may be an NTN RAN 5 or a TN RAN 5.

[0167] As seen in Fig. 12, a verified UE location is acquired by the source base station 5A-1 for the UE 3 at S1200. The verified UE location in this case may be based on multiple measurements (e.g., performed over time as the cell 9-1 moves relative to the UE 3 as described above in the subsection titled "Location Verification at Base Station (e.g., by lower layers)"). This verified UE location can be maintained at the source base station 5A-1 until the UE 3 is about to leave coverage of the source cell 9-1 (e.g., as a result of discontinuous coverage, suspension of an RRC connection, and / or the like).

[0168] In this example, before the UE 3 leaves the source cell 9-1, the source base station 5A-1 provides the verified UE location information to the UE 3 at S1006-2 where the verified UE location information is stored. In the context of ensuring that the UE location can remain verified, the UE location information provided to the UE 3 may be encrypted (e.g., to prevent malicious actors from tampering with the UE location information).

[0169] When the UE 3 moves to a target cell 9-2 operated by a target base station 5A-2 (as indicated at S1204), the target base station 5A-2 can obtain (e.g., as part of a procedure to (re)establish / resume a UE's connection in the target cell 9-2), the verified UE location information from the UE 3. It will be appreciated that the move to the target cell 9-2 may not arise (entirely) from movement of the UE 3 itself but may arise from movement of an NTN cell relative to the UE 3. The verified UE location information may be explicitly requested from the UE 3 (as indicated at S1206-1) and provided by the UE 3 (as indicated at S1206-2) in response to the explicit request. Nevertheless, the UE 3 may provide the verified UE location information automatically at S1206-2 (e.g., as part of a procedure to (re)establish / resume a UE's connection in the target cell 9-2) without requiring an explicit request.

[0170] It will be appreciated that this example may be particularly useful in the case of NTN cells where the corresponding base stations may be very far apart (e.g., particularly for moving UEs 3 in / on a vehicle such as a boat, plane, or the like). Specifically, by providing the UE 3 with the verified UE location information, the target base station 5A-2 does not need to acquire the information from another base station 5A over a direct base station to base station interface (which may not be practicable when the source and target base stations are at a large distance from one another).

[0171] In summary, therefore, in these examples, for continuous TN to TN coverage (or mobility from a TN to NTN), the TN base station 5A can provide beam and / or timing advance (TA) information (which is indicative of the distance of the UE 3 from a base station 5A) to another base station 5A via a base station to base station interface (e.g., Xn) and / or to the core network 7 using messages of an appropriate application protocol over a corresponding interface with the core network 7 (e.g., an N2 / NGAP interface).

[0172] For continuous NTN coverage, network verified location information may be forwarded to the next base station 5A (if it changes). Nevertheless, this may not be necessary (i.e., in a scenario where only the service link changes but the base station 5A does not).

[0173] For discontinuous NTN coverage, the (verified) location information may be stored in the core network 7, or in the UE 3. This stored information may then be forwarded to a new base station 5A-2 later (e.g., when a service link for the UE 3 is (re)established with the NTN RAN 5 that the new base station forms part of).

[0174] It can be seen that, in the examples described with reference to Figs. 9 to 12, the base station 5A may provide the (verified) UE location information in any suitable way. The (verified) UE location information may, for example, be provided to a target base station 5A in response to a direct (e.g., Xn) request over the base station interface, or using an appropriate message forming part of a RAN based / conditional handover procedure (e.g., as described with reference to Fig. 9, with extra TN-related information such as the latest TA and / or beam / sector information, or as described with reference to Fig. 10). The (verified) UE location information may alternatively, or additionally be provided (e.g., using appropriate NGAP messages) to, and stored in, the core network 7 from where it can be retrieved by a later (new) base station 5A. Alternatively, or additionally, the (verified) UE location information may be provided (e.g., using appropriate RRC messages) to, and stored by, the UE 3 (potentially in encrypted form to mitigate against the risk of malicious tampering) from where it can be accessed by a later (new) base station 5A.

[0175] It will be appreciated that in the examples described with reference to Figs. 9 to 12, the procedure is optional and any communication node (UE 3, source base station 5A-1, target base station 5A-2, core network node / function) from which the verified UE location information might otherwise be obtained may, at a given time, not possess any verified location information for a particular UE 3. In this scenario, the communication node may simply provide an indication that "no verified information" is available (e.g., in response to a request for such information) or when the information would otherwise be provided (e.g., automatically).

[0176] Moreover, in the examples described with reference to Figs. 9 to 12, the source base station 5A-1 currently serving a UE 3 will still be able to coordinate with the core network 7 (AMF 10-1 / LMF 10-3) to obtain location services support (e.g., as described with reference to Fig. 6 above). Alternatively, or additionally the source base station 5A-1 may be configured by the core network 7 to obtain a (verified) UE location (e.g., as described above in the subsection titled "Base Station Side Verification of Location Information and Sharing with Core Network") based on measurements from one or multiple UEs 3 for positioning purposes.

[0177] It also will be appreciated that, in the examples described with reference to Figs. 9 to 12, the source base station 5A-1 may store / maintain a result of one or more such measurements (and possibly a history of such results) or other information in conjunction with the (verified) UE location (and provide any stored measurement result to another node, as described above, together with or as part of the (verified) UE location information). This beneficially provides for a more 'holistic' approach to maintaining a verified UE location.

[0178] < Base Station Side Verification of Location Information and Sharing with Core Network (exemplary procedure) > 　　As mentioned above, the communication system 1 includes enhancements for supporting the sharing of that UE location information, with the core network 7, that may be partially or fully verified at the base station 5A.

[0179] A possible implementation of such enhancements will now be described in more detail, by way of example only, with reference to Fig. 13.

[0180] Fig. 13 is a simplified sequence diagram illustrating a procedure for configuring base station side verification of location information that may be used in the communication system 1.

[0181] As seen in Fig. 13, the AMF 10-1 sends (at S1302) a location service request to an LMF 10-3. This location service request may, for example, originate from some entity in the core network 7 (e.g. a GMLC), the AMF 10-1 itself, or the UE 3 (e.g., as described with reference to Fig. 6).

[0182] In accordance with the request from the AMF 10-1, the LMF 10-3 then configures the base station 5A of the RAN 5 for acquisition of (verified) UE location information and reporting of that information to the LMF 10-3 in accordance with one or more reporting conditions. The LMF 10-3 may, for example, send an explicit (optional) request for (verified) UE location information for a specific UE 3 as indicated at S1310a. This request may include information defining one or more conditions for the procedure and / or may set a positioning integrity target for the acquisition of (verified) UE location information (although a default one could, alternatively, be used). The request may, for example, include information defining / setting one or more of the trigger conditions described above in the subsection titled "Base Station Side Verification of Location Information and Sharing with Core Network".

[0183] The LMF 10-3 may, nevertheless, configure an optional procedure that may be performed by the base station 5A of the RAN 5 in respect of any UE 3 as indicated at S1310b. The configuration may include information defining one or more conditions for the procedure and / or may set a positioning integrity target for the acquisition of (verified) UE location information (although a default one could, alternatively, be used). The configuration may, for example, include information defining / setting one or more of the trigger conditions described above in the subsection titled "Base Station Side Verification of Location Information and Sharing with Core Network".

[0184] The base station 5A of the RAN 5 may then acquire and maintain (verified) UE location information in accordance with the information provided by the LMF 10-3 at S1310a or S1310b as indicated at S1320. Any acquired (verified) UE location information may be provided to the LMF 10-3 when triggered to do so (e.g., based on one or more trigger conditions configured by the LMF 10-3).

[0185] Any (verified) UE location information reported by the base station 5A of the RAN 5 may be reported back to the AMF 10-1, as indicated at S1304, and potentially from the AMF 10-1 to other communication nodes (e.g., as described with reference to Fig. 6).

[0186] < User Equipment > 　　Fig. 14 is a simplified block schematic illustrating the main components of a UE 3 for implementation in the system of Fig. 1.

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

[0188] 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, and location functions 45.

[0189] The communications control module 43 is operable to control the communication between the UE 3 and its serving base station 5A-1 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 3 side; for determining how slots / symbols are configured (e.g., for UL, DL or full duplex communication, or the like); for determining which bandwidth parts are configured for the UE 3; for determining how uplink transmissions should be encoded and the like.

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

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

[0192] The location functions 45 are configured to perform, under the overall control of the communications control module 43, the location related functionality of the UE 3 described herein (e.g., the provision of UE location (GNSS) information (and related information) to a base station 5A, the acquisition of (potentially encrypted) verified UE location information from the base station 5A and the forwarding of such information to the core network 7, etc.).

[0193] < Base Station > 　　Fig. 15 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).

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

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

[0196] 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 5A 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.

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

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

[0199] The location functions 65 are configured to perform, under the overall control of the communications control module 63, the location related functionality of the base station 5A described herein, for example: requesting / reception of UE location (GNSS) information (and related information) from the UE 3 or another base station 5A, and / or forwarding such information to another base station 5A or the core network 7; the acquisition / maintenance of verified UE location information at the base station 5A and the forwarding of such information to the UE 3, another base station 5A, and / or the core network 7, etc; and / or the reception of configuration information from the core network 7 for configuring the acquisition / maintenance of verified UE location information at the base station 5A, and for configuring triggering of reporting of such information to the core network 7.

[0200] < Core Network Node / Function > 　　Fig. 16 is a block diagram illustrating the main components of a core network node or function, such as an AMF 10-1, CPF 10, UPF 11, SMF 10-2, LMF 10-3 etc.). As shown, the core network function includes a transceiver circuit 71 which is operable to transmit signals to and to receive signals from other nodes (including the UE 3, the base station 5A, and other core network nodes) via a network interface 72. A controller 73 controls the operation of the core network function in accordance with software stored in a memory 74. The software may be pre-installed in the memory 74 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The software includes, among other things, an operating system 75, a communications control module 76, and location functions 77.

[0201] The communications control module 76 is responsible for handling (generating / sending / receiving) signalling between the core network function and other nodes, such as the UE 3, the base station 5A, and other core network nodes.

[0202] It will be appreciated that the communications control module 76 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, where the core network node is implemented as an MME (or AMF 10-1 for 5G), the communications control module 76 may include, for communicating with the base station 5A, an S1-AP sub-module, an SCTP sub-module, an IP sub-module, an L1 sub-module, an L2 sub-module, etc (or corresponding sub-modules for an AMF 10-1).

[0203] The communications control module 76 is configured in particular, to control the core network node's communications, in accordance with any of the methods described herein.

[0204] The location functions 77 are configured to perform, under the overall control of the communications control module 76, the location related functionality of the core network node / function described herein, for example: reception of UE location (GNSS) information (and related information) from one base station 5A and the provision of such information to another base station 5A (e.g., on request); requesting and reception of verified UE location information from a base station 5A and the forwarding of such information to another base station 5A (e.g., on request); and / or the provision of configuration information to the base station 5A for configuring the acquisition / maintenance of verified UE location information at the base station 5A, and for configuring triggering of reporting of such information to the core network 7.

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

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

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

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

[0209] In the above description the UE 3 and the base station 5A 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.

[0210] 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 3 or base station 5A 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 3 or the base station 5A in order to update their functionalities.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0226] Table 1

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

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

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

[0230] This application is based upon and claims the benefit of priority from UK patent application No. 2312288.0, filed on August 10, 2023, the disclosure of which is incorporated herein in its entirety by reference.

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

[0232] For example, the whole or part of the example embodiments disclosed above can be described as, but not limited to, the following supplementary notes. (Supplementary note 1) 　　A method performed by an access network node, the method comprising: 　　receiving, from a user equipment (UE), information regarding a Global Navigation Satellite System (GNSS) location of the UE, the information being not verified by a core network; and 　　forwarding, to another network node, the information regarding the GNSS location of the UE for determining a current location of the UE in a case where the UE moves to a target access network node. (Supplementary note 2) 　　The method according to Supplementary note 1, wherein 　　the another network node is at least one of the target access network node or a core network node in the core network. (Supplementary note 3) 　　The method according to Supplementary note 1 or 2, wherein 　　the another network node is the target access network node, 　　the forwarding is performed in a handover procedure from the access network node to the target access network node. (Supplementary note 4) 　　The method according to Supplementary note 1 or 2, wherein 　　the another network node is the core network node, 　　the information regarding the GNSS location of the UE is included in a UE context, and 　　the forwarding is performed in a case where the another network node receives a request from the target access network node. (Supplementary note 5) 　　The method according to any one of Supplementary notes 1 to 4, wherein 　　the UE moves from the access network node to the target access network node includes the UE moves: 　　　　from a non-terrestrial network to a non-terrestrial network, 　　　　from a non-terrestrial network to a terrestrial network, 　　　　from a terrestrial network to a non-terrestrial network, or 　　　　from a terrestrial network to a terrestrial network. (Supplementary note 6) 　　The method according to any one of Supplementary notes 1 to 5, wherein 　　the information regarding the GNSS location of the UE includes at least one of: 　　　　information indicating integrity or precision of the GNSS location of the UE, or 　　　　information indicating a timestamp corresponding to the GNSS location of the UE. (Supplementary note 7) 　　The method according to any one of Supplementary notes 1 to 6, further comprising: 　　transmitting, to the UE, a request for the information regarding the GNSS location of the UE, and wherein 　　the receiving is performed upon transmitting the request. (Supplementary note 8) 　　The method according to any one of Supplementary notes 1 to 7, further comprising: 　　receiving, from the UE, a measurement result by the UE; and 　　verifying a current location of the UE using the measurement result. (Supplementary note 9) 　　The method according to Supplementary note 8, further comprising: 　　transmitting to another node, information indicating a verified current location of the UE. (Supplementary note 10) 　　The method according to Supplementary note 9, wherein 　　the transmitting is performed upon receiving a request from the another node. (Supplementary note 11) 　　The method according to Supplementary note 9, wherein 　　the information indicating the verified current location of the UE is forwarded to the target access network node in a case where the UE moves to the target access network node and the target access network node transmit a request to the another node. (Supplementary note 12) 　　The method according to Supplementary note 9, wherein 　　information indicating that the information indicating the verified current location of the UE is not available is transmitted to the target access network node in a case where the UE moves to the target access network node, the target access network node transmit a request to the another node, and the access network node corresponds to the dis continuous non-terrestrial network coverage. (Supplementary note 13) 　　The method according to any one of Supplementary notes 9 to 12, wherein 　　the information indicating the verified current location of the UE includes at least one of: 　　　　beam information, or 　　　　information indicating a distance from a cell operated by the access network node, 　　in a case where the access network node corresponds to a continuous terrestrial network coverage. (Supplementary note 14) 　　The method according to any one of Supplementary notes 9 to 12, wherein 　　the information indicating the verified current location of the UE includes information indicating a current location of the UE verified by the core network, in a case where the access network node corresponds to a continuous non-terrestrial network coverage. (Supplementary note 15) 　　The method according to any one of Supplementary notes 9 to 12, wherein 　　the information indicating the verified current location of the UE is stored in the another network node in a case where the access network node corresponds to a discontinuous non-terrestrial network coverage. (Supplementary note 16) 　　The method according to any one of Supplementary notes 8 to 15, wherein 　　the information indicating the verified current location of the UE is used by the another node to perform a triangulation for verifying the current location of the UE. (Supplementary note 17) 　　The method according to any one of Supplementary notes 8 to 16, wherein 　　the another node includes at least one of: 　　　　the UE, 　　　　the target access network node, or 　　　　the core network node. (Supplementary note 18) 　　The method according to any one of Supplementary notes 8 to 17, further comprising: 　　receiving, from the core network, information indicating a target of integrity or precision of the current location of the UE, and wherein 　　the verifying is performed based on the information indicating the target of integrity or precision. (Supplementary note 19) 　　The method according to any one of Supplementary notes 1 to 18, further comprising: 　　receiving, from a core network node, a request for transmitting the information regarding the GNSS location of the UE or the information indicating the verified current location of the UE, and wherein 　　the transmitting the information regarding the GNSS location of the UE or the information indicating the verified current location of the UE is performed upon receiving the request from the core network node. (Supplementary note 20) 　　The method according to any one of Supplementary notes 1 to 19, further comprising: 　　receiving, from a core network node, information indicating at least one condition for transmitting the information regarding the GNSS location of the UE or the information indicating the verified current location of the UE, and wherein 　　the transmitting the information regarding the GNSS location of the UE or the information indicating the verified current location of the UE is performed in a case where one of the at least one condition is met. (Supplementary note 21) 　　The method according to Supplementary note 20, wherein 　　the at least one condition includes at least one of: 　　　　integrity or precision of the GNSS location of the UE or the verified current location of the UE is below a threshold, 　　　　a period has elapsed, 　　　　a location of the UE has been verified, 　　　　a location of the UE has been changed to an unverified area, 　　　　a location of the UE has been changed by a predetermined amount, or 　　　　the UE has reached a predetermined location. (Supplementary note 22) 　　A method performed by a user equipment (UE), the method comprising: 　　transmitting, to an access network node, information regarding a Global Navigation Satellite System (GNSS) location of the UE, the information being not verified by a core network, wherein 　　the information regarding the GNSS location of the UE is forwarded from the access network node to another network node, for determining a current location of the UE in a case where the UE moves to a target access network node. (Supplementary note 23) 　　An access network node, comprising: 　　means for receiving, from a user equipment (UE), information regarding a Global Navigation Satellite System (GNSS) location of the UE, the information being not verified by a core network; and 　　means for forwarding, to another network node, the information regarding the GNSS location of the UE for determining a current location of the UE in a case where the UE moves to a target access network node. (Supplementary note 24) 　　A user equipment (UE) comprising: 　　means for transmitting, to an access network node, information regarding a Global Navigation Satellite System (GNSS) location of the UE, the information being not verified by a core network, wherein 　　the information regarding the GNSS location of the UE is forwarded from the access network node to another network node, for determining a current location of the UE in a case where the UE moves to a target access network node.

[0233] 1　　communication system 3　　UEs 5　　radio access network (RAN), NTN RAN, TN RAN 5-1　　source RAN 5-2　　target RAN 5A　　base station 5A-1　　source base station 5A-2　　target base station 5A-x　　candidate base station 5B　　gateway 5C　　non-terrestrial (space or air borne) platform 7　　core network 9　　cells 9-1　　source cell, initial cell 9-2　　target cell, new cell 10　　control plane functions (CPFs) 10-1　　Access and Mobility Management Functions (AMFs) 10-2　　session management function (SMF) 10-3　　location management functions (LMFs) 11　　user plane functions (UPFs) 15　　some entity 20　　external data network 31, 51, 71　　transceiver circuit 33, 53　　antenna 35　　user interface 37, 57, 73　　controller 39, 59, 74　　memory 41, 61, 75　　operating system 43, 63, 76　　communications control module 45, 65, 77　　location functions 55　　core network interface 72　　network interface

Claims

1. A method performed by an access network node, the method comprising: 　　receiving, from a user equipment (UE), information regarding a Global Navigation Satellite System (GNSS) location of the UE, the information being not verified by a core network; and 　　forwarding, to another network node, the information regarding the GNSS location of the UE for determining a current location of the UE in a case where the UE moves to a target access network node.

2. The method according to claim 1, wherein 　　the another network node is at least one of the target access network node or a core network node in the core network.

3. The method according to claim 1 or 2, wherein 　　the another network node is the target access network node, 　　the forwarding is performed in a handover procedure from the access network node to the target access network node.

4. The method according to claim 1 or 2, wherein 　　the another network node is the core network node, 　　the information regarding the GNSS location of the UE is included in a UE context, and 　　the forwarding is performed in a case where the another network node receives a request from the target access network node.

5. The method according to any one of claims 1 to 4, wherein 　　the UE moves from the access network node to the target access network node includes the UE moves: 　　　　from a non-terrestrial network to a non-terrestrial network, 　　　　from a non-terrestrial network to a terrestrial network, 　　　　from a terrestrial network to a non-terrestrial network, or 　　　　from a terrestrial network to a terrestrial network.

6. The method according to any one of claims 1 to 5, wherein 　　the information regarding the GNSS location of the UE includes at least one of: 　　　　information indicating integrity or precision of the GNSS location of the UE, or 　　　　information indicating a timestamp corresponding to the GNSS location of the UE.

7. The method according to any one of claims 1 to 6, further comprising: 　　transmitting, to the UE, a request for the information regarding the GNSS location of the UE, and wherein 　　the receiving is performed upon transmitting the request.

8. The method according to any one of claims 1 to 7, further comprising: 　　receiving, from the UE, a measurement result by the UE; and 　　verifying a current location of the UE using the measurement result.

9. The method according to claim 8, further comprising: 　　transmitting to another node, information indicating a verified current location of the UE.

10. The method according to claim 9, wherein 　　the transmitting is performed upon receiving a request from the another node.

11. The method according to claim 9, wherein 　　the information indicating the verified current location of the UE is forwarded to the target access network node in a case where the UE moves to the target access network node and the target access network node transmit a request to the another node.

12. The method according to claim 9, wherein 　　information indicating that the information indicating the verified current location of the UE is not available is transmitted to the target access network node in a case where the UE moves to the target access network node, the target access network node transmit a request to the another node, and the access network node corresponds to the dis continuous non-terrestrial network coverage.

13. The method according to any one of claims 9 to 12, wherein 　　the information indicating the verified current location of the UE includes at least one of: 　　　　beam information, or 　　　　information indicating a distance from a cell operated by the access network node, 　　in a case where the access network node corresponds to a continuous terrestrial network coverage.

14. The method according to any one of claims 9 to 12, wherein 　　the information indicating the verified current location of the UE includes information indicating a current location of the UE verified by the core network, in a case where the access network node corresponds to a continuous non-terrestrial network coverage.

15. The method according to any one of claims 9 to 12, wherein 　　the information indicating the verified current location of the UE is stored in the another network node in a case where the access network node corresponds to a discontinuous non-terrestrial network coverage.

16. The method according to any one of claims 8 to 15, wherein 　　the information indicating the verified current location of the UE is used by the another node to perform a triangulation for verifying the current location of the UE.

17. The method according to any one of claims 8 to 16, wherein 　　the another node includes at least one of: 　　　　the UE, 　　　　the target access network node, or 　　　　the core network node.

18. The method according to any one of claims 8 to 17, further comprising: 　　receiving, from the core network, information indicating a target of integrity or precision of the current location of the UE, and wherein 　　the verifying is performed based on the information indicating the target of integrity or precision.

19. The method according to any one of claims 1 to 18, further comprising: 　　receiving, from a core network node, a request for transmitting the information regarding the GNSS location of the UE or the information indicating the verified current location of the UE, and wherein 　　the transmitting the information regarding the GNSS location of the UE or the information indicating the verified current location of the UE is performed upon receiving the request from the core network node.

20. The method according to any one of claims 1 to 19, further comprising: 　　receiving, from a core network node, information indicating at least one condition for transmitting the information regarding the GNSS location of the UE or the information indicating the verified current location of the UE, and wherein 　　the transmitting the information regarding the GNSS location of the UE or the information indicating the verified current location of the UE is performed in a case where one of the at least one condition is met.

21. The method according to claim 20, wherein 　　the at least one condition includes at least one of: 　　　　integrity or precision of the GNSS location of the UE or the verified current location of the UE is below a threshold, 　　　　a period has elapsed, 　　　　a location of the UE has been verified, 　　　　a location of the UE has been changed to an unverified area, 　　　　a location of the UE has been changed by a predetermined amount, or 　　　　the UE has reached a predetermined location.

22. A method performed by a user equipment (UE), the method comprising: 　　transmitting, to an access network node, information regarding a Global Navigation Satellite System (GNSS) location of the UE, the information being not verified by a core network, wherein 　　the information regarding the GNSS location of the UE is forwarded from the access network node to another network node, for determining a current location of the UE in a case where the UE moves to a target access network node.

23. An access network node, comprising: 　　means for receiving, from a user equipment (UE), information regarding a Global Navigation Satellite System (GNSS) location of the UE, the information being not verified by a core network; and 　　means for forwarding, to another network node, the information regarding the GNSS location of the UE for determining a current location of the UE in a case where the UE moves to a target access network node.

24. A user equipment (UE) comprising: 　　means for transmitting, to an access network node, information regarding a Global Navigation Satellite System (GNSS) location of the UE, the information being not verified by a core network, wherein 　　the information regarding the GNSS location of the UE is forwarded from the access network node to another network node, for determining a current location of the UE in a case where the UE moves to a target access network node.

Images