User equipment location verification based on low latency non-terrestrial networks

Abstract

Devices, methods, and systems are disclosed for low latency NTN-based UE location verification. An apparatus (1400) includes a transceiver (1425) and a processor (1405) coupled to the transceiver. In one embodiment, the processor (1405) is configured to cause the device to transmit, to a second network entity having location server functionality, a low latency UE location request comprising a location configuration comprising at least a request to provide location information for the UE within a configured time window, receiving a location information response from the second network entity based on the transmitted location request, and performing a low latency verification procedure of the location information for the UE based on the received location response.

Description

Technical Field

[0001] The subject matter disclosed herein relates generally to wireless communications, and more particularly, to low-latency non-terrestrial network ("NTN") based user equipment ("UE") location verification. Background Art

[0002] In wireless networks, UE positioning may refer to techniques used in wireless networks to determine the geographic location, position and / or velocity of a UE. Due to the large coverage area exhibited by NTN cells, conventional terrestrial network positioning verification mechanisms may not be applicable to NTN systems. Summary of the invention

[0003] A solution for UE location verification based on low-latency NTN is disclosed. The solution can be implemented by a device, a system, a method or a computer program product.

[0004] In one embodiment, a first device includes a transceiver and a processor coupled to the transceiver. In one embodiment, the processor is configured to cause the device to transmit a low-latency UE location request including a positioning configuration to a second network entity having location server functionality, the positioning configuration including at least a request to provide location information of the UE within a configured time window, receive a location information response from the second network entity based on the transmitted location request, and perform a low-latency verification procedure of the location information of the UE based on the received location response.

[0005] In one embodiment, a first method transmits a low-latency UE location request including a positioning configuration to a second network entity having location server functionality, wherein the positioning configuration includes at least a request to provide location information of the UE within a configured time window, receives a location information response from the second network entity based on the transmitted location request, and performs a low-latency verification process for the location information of the UE based on the received location response.

[0006] In one embodiment, a second device includes a transceiver and a processor coupled to the transceiver. In one embodiment, the processor is configured to cause the device to receive a low-latency UE location verification request including a positioning configuration from a second network entity, the positioning configuration including at least a request to provide location information of the UE within a configured time window, perform a low-latency verification process for the location information of the UE, and transmit a location information response to the second network entity based on the transmitted verification request.

[0007] In one embodiment, a second method receives a low-latency UE location verification request including a positioning configuration from a second network entity, wherein the positioning configuration includes at least a request to provide the location information of the UE within a configured time window, performs a low-latency verification process for the location information of the UE, and transmits a location information response to the second network entity based on the transmitted verification request. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] A more particular description of the embodiments briefly described above will be presented by reference to specific embodiments illustrated in the accompanying drawings. With the understanding that these drawings depict only some embodiments and are therefore not to be considered limiting in scope, a more particular and detailed description and explanation of the embodiments will be provided through the use of the accompanying drawings, in which:

[0009] Figure 1 is a schematic block diagram illustrating an embodiment of a wireless communication system for low-latency NTN-based UE location verification;

[0010] Figure 2 is a block diagram illustrating one embodiment of a 5G NR protocol stack;

[0011] Figure 3 Describing one embodiment of NR beam-based positioning;

[0012] Figure 4A Describing one embodiment of downlink time difference of arrival ("DL-TDOA") assistance data;

[0013] Figure 4B Describing one embodiment of a DL-TDOA measurement report;

[0014] Figure 5 Describes one embodiment of an overall architecture for UE positioning applicable to a Next Generation Radio Access Network ("NG-RAN");

[0015] Figure 6 Describes an embodiment of location services support in NG-RAN;

[0016] Figure 7 Describes one embodiment of the NG-RAN location reporting procedure;

[0017] FIG8 a depicts one embodiment of a networked RAN architecture with transparent satellite;

[0018] FIG8 b depicts one embodiment of a regenerated satellite without an inter-satellite link (“ISL”) and payload processed by a gNB;

[0019] FIG8c depicts one embodiment of a regenerated satellite with ISL and gNB-processed payload;

[0020] Fig.9A Describes one embodiment of a process for a low latency verification process using NG-RAN and Location Management Component ("LMC") combined functionality;

[0021] Fig. 9B Describing one embodiment of another process for low latency verification process using NG-RAN and LMC combined functionality;

[0022] FIG. 10 a depicts one embodiment of a process for a network-induced location request having a particular method type;

[0023] FIG. 10 b depicts one embodiment of a process for network-induced multiple location requests with multiple method types;

[0024] FIG. 11 a depicts one embodiment of a verification process based on multiple position estimates;

[0025] FIG. 11 b depicts one embodiment of a simplified verification process based on multiple position estimates;

[0026] FIG. 11c depicts one embodiment of a location estimation and verification process using a RAT-dependent approach;

[0027] Fig.12 Describes an embodiment of a LMF-based position estimation and verification process;

[0028] Fig.13 is a block diagram illustrating one embodiment of a user equipment device that may be used for low-latency NTN-based UE location verification;

[0029] Fig.14 is a block diagram illustrating one embodiment of a network device that may be used for low-latency NTN-based UE location verification;

[0030] Fig.15 is a flow chart illustrating one embodiment of a method for UE location verification based on low-latency NTN; and

[0031] Fig.16 is a flow chart illustrating one embodiment of another method for UE location verification based on low-latency NTN. DETAILED DESCRIPTION

[0032] As will be appreciated by those skilled in the art, aspects of the embodiments may be embodied as systems, devices, methods, or program products. Thus, the embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects.

[0033] For example, the disclosed embodiments may be implemented as hardware circuits including custom very large scale integration ("VLSI") circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed embodiments may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code, which may be organized, for example, as an object, procedure, or function.

[0034] In addition, embodiments may take the form of a program product embodied in one or more computer-readable storage devices storing machine-readable code, computer-readable code, and / or program code (hereinafter referred to as code). The storage device may be tangible, non-transitory, and / or non-transmitting. The storage device may not embody a signal. In a certain embodiment, the storage device employs only a signal for accessing the code.

[0035] Any combination of one or more computer readable media may be utilized. The computer readable medium may be a computer readable storage medium. The computer readable storage medium may be a storage device storing the code. The storage device may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical or semiconductor system, apparatus or device, or any suitable combination of the foregoing.

[0036] More specific examples of storage devices (a non-exhaustive list) would include the following: an electrical connection having one or more conductors, a portable computer diskette, a hard disk, a random access memory ("RAM"), a read-only memory ("ROM"), an erasable programmable read-only memory ("EPROM" or flash memory), a portable compact disk read-only memory ("CD-ROM"), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0037] The code for carrying out the operation of the embodiments may be any number of lines and may be written in any combination of one or more programming languages, including object-oriented programming languages ​​(e.g., Python, Ruby, Java, Smalltalk, C++, etc.), and conventional procedural programming languages ​​(e.g., "C" programming language, etc.) and / or machine languages ​​(e.g., assembly language). The code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network ("LAN"), a wireless local area network ("WLAN"), or a wide area network ("WAN"), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider ("ISP")).

[0038] In addition, the described features, structures, or characteristics of the embodiments may be combined in any suitable manner. In the following description, many specific details (such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc.) are provided to provide a thorough understanding of the embodiments. However, those skilled in the art will recognize that the embodiments may be practiced without one or more of the specific details or using other methods, components, materials, etc. In other examples, well-known structures, materials, or operations are not shown or described in detail to avoid making aspects of the embodiments unclear.

[0039] References throughout this specification to "one embodiment," "an embodiment," or similar language mean that a particular feature, structure, or characteristic described in conjunction with an embodiment is included in at least one embodiment. Therefore, the phrases "in one embodiment," "in an embodiment," and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment, but rather to "one or more but not all embodiments," unless otherwise expressly specified. The terms "comprise," "include," "have," and variations thereof mean "including but not limited to," unless otherwise expressly specified. An enumerated list of items does not imply that any or all items are mutually exclusive, unless otherwise expressly specified. The terms "one," "an," and "said" also refer to "one or more," unless otherwise expressly specified.

[0040] As used herein, a list with the conjunction "and / or" includes any single item in the list or a combination of items in the list. For example, a list of A, B, and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term "one or more of..." includes any single item in the list or a combination of items in the list. For example, one or more of A, B, and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term "one of..." includes one and only one of any single item in the list. For example, "one of A, B, and C" includes only A, only B, or only C, and excludes a combination of A, B, and C. As used herein, "a member selected from a group consisting of A, B, and C" includes one and only one of A, B, or C, and excludes a combination of A, B, and C. As used herein, "a member selected from the group consisting of A, B, and C, and combinations thereof" includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C.

[0041] Aspects of the embodiments are described below with reference to schematic flow charts and / or schematic block diagrams of methods, devices, systems, and program products according to the embodiments. It should be understood that each frame of the schematic flow charts and / or schematic block diagrams and the combination of frames in the schematic flow charts and / or schematic block diagrams can be implemented by code. This code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to generate a machine, so that instructions executed by the processor of the computer or other programmable data processing device create components for implementing the functions / actions specified in the flow charts and / or block diagrams.

[0042] Code may also be stored in a storage device, which may direct a computer, other programmable data processing apparatus or other device to function in a specific manner so that the instructions stored in the storage device produce an article of manufacture containing instructions for implementing the functions / actions specified in the flowchart and / or block diagram.

[0043] The code may also be loaded onto a computer, other programmable data processing device or other apparatus to cause a series of operating steps to be executed on the computer, other programmable device or other apparatus to produce a computer-implemented process, so that the code executed on the computer or other programmable device provides a process for implementing the functions / actions specified in the flowchart and / or block diagram.

[0044] The flowcharts and / or block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of devices, systems, methods, and program products according to various embodiments. In this regard, each box in the flowcharts and / or block diagrams may represent a module, segment, or portion of code that includes one or more executable instructions for implementing the code for (several) specified logical functions.

[0045] It should also be noted that in some alternative implementations, the functions mentioned in the blocks may not appear in the order mentioned in the figures. For example, two blocks shown in succession may, in fact, be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. Other steps and methods may be considered to be equivalent in function, logic or effect to one or more blocks or portions thereof of the illustrated figures.

[0046] Although various arrow types and line types may be used in flow charts and / or block diagrams, they are understood not to limit the scope of the corresponding embodiments. In fact, some arrows or other connecting symbols may be used to indicate only the logical flow of the depicted embodiments. For example, arrows may indicate waiting or monitoring periods of unspecified duration between the enumerated steps of the depicted embodiments. It should also be noted that each box of the block diagram and / or flow chart and the combination of boxes in the block diagram and / or flow chart may be implemented by a dedicated hardware-based system or a combination of dedicated hardware and code that performs a specified function or action.

[0047] The description of elements in each figure may refer to elements of previous figures. In all figures, the same numbers refer to the same elements, including alternative embodiments of the same elements.

[0048] In general, the present disclosure describes systems, methods, and devices for low-latency NTN-based UE location verification. In some embodiments, the method may be performed using computer code embedded on a computer-readable medium. In some embodiments, a device or system may include a computer-readable medium containing computer-readable code, which, when executed by a processor, causes the device or system to perform at least a portion of the solution described below.

[0049] There is no conventional method that enables verification of the reported location of a UE in an NTN network deployment. Due to the larger coverage area exhibited by NTN cells, current terrestrial network mechanisms require certain enhancements. In addition, the conclusions of TR 38.882 have identified the need to define a network-based solution intended to verify reported UE location information. Depending on the configured positioning method, the network verification process will need to be enhanced to provide accurate, reliable, and low-latency verified UE locations taking into account satellite movement, wider range, higher Doppler shift, and / or the like. The present disclosure provides a set of process enhancements to enable support of RAT-dependent (e.g., network-based) network verification processes on NTN networks.

[0050] In addition, there is no known mechanism to verify the accuracy and reliability of the UE's location based on NTN RAT-dependent positioning methods because all methods are designed with terrestrial networks in mind. According to solution #18 of TR 23.700-030, a network data analysis function ("NWDAF") network entity is used to perform location verification, which enables the access and mobility management function ("AMF") to receive statistics and predictions about the UE's location, thereby making it easier to determine whether the potentially inaccurate location information provided by the UE is reliable and trustworthy. This solution primarily does not consider the location management function ("LMF") in the network verification process of the UE and has a high signaling overhead. According to solution #24 of TR 23.700-030, NG-RAN assistance information is used to verify the UE's location, however, this solution does not consider the details of this NG-RAN assistance information and how the AMF can trigger the LMF to initiate the NTN RAT-dependent location verification process.

[0051] The subject matter of this document provides support for a low latency network verification UE positioning process, which takes into account the additional propagation delay due to NTN gNB and UE signaling after registration. In the present disclosure, a method / configuration with a low latency UE verification process is disclosed. Depending on the applicable scenario, the verification process may be performed by the AMF, LMF or LMC. In one embodiment, the LMF may be co-located with the NG-RAN node, where this implementation may be more common in NTN networks to avoid longer propagation delays, thereby enhancing positioning accuracy. This means that the gateway and NTN-gNB may be equipped with LMC functionality or co-located with the LMF, so that the verification process at the LMC has very low latency. In addition, the verification process only needs to be performed by a reliable position estimation process, such as a RAT-dependent method. Therefore, a process for verification using a RAT-dependent method is disclosed. In addition, a process is disclosed that demonstrates that a RAT-independent method can be used for emergency and regulatory services, if these can be considered reliable.

[0052] Figure 1A wireless communication system 100 for low-latency NTN-based UE location verification according to an embodiment of the present disclosure is depicted. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, a radio access network ("RAN") 120, and a mobile core network 140. The RAN 120 and the mobile core network 140 form a mobile communication network. The RAN 120 may be composed of a base unit 121 with which the remote unit 105 communicates using wireless communication links (e.g., service link(s) 125 and feeder link(s) 127) via a satellite 129. As depicted, the mobile communication network includes an "on-ground" base unit 121 and a non-terrestrial network ("NTN") gateway 123 that accesses the remote unit 105 via a satellite.

[0053] Despite Figure 1 Although a specific number of remote units 105, base units 121, wireless communication links, RAN 120, satellites 129, NTN gateways 123 (e.g., satellite ground / terrestrial devices), and mobile core networks 140 are depicted in the wireless communication system 100, a person skilled in the art will recognize that any number of remote units 105, base units 121, wireless communication links, RAN 120, satellites 129, NTN gateways 123, and mobile core networks 140 may be included in the wireless communication system 100.

[0054] In one embodiment, the RAN 120 is compatible with the 5G system specified in the 3rd Generation Partnership Project ("3GPP") specifications. For example, the RAN 120 may be a next generation radio access network ("NG-RAN") that implements the NR RAT and / or the 3GPP Long Term Evolution ("LTE") RAT. In another example, the RAN 120 may include non-3GPP RATs (e.g., compatible with 5G). In another embodiment, the RAN 120 is compatible with the LTE system specified in the 3GPP specification. However, more generally, the wireless communication system 100 may implement some other open or proprietary communication network, such as the Worldwide Interoperability for Microwave Access ("WiMAX") or the IEEE 802.16 family of standards, among others. The present disclosure is not intended to be limited to implementations of any particular wireless communication system architecture or protocol.

[0055] In one embodiment, the remote unit 105 may include a computing device, such as a desktop computer, a laptop computer, a personal digital assistant (PDA), a tablet computer, a smart phone, a smart TV (e.g., a TV connected to the Internet), a smart appliance (e.g., an appliance connected to the Internet), a set-top box, a game console, a security system (including a security camera), a car computer, a network device (e.g., a router, a switch, a modem), etc. In some embodiments, the remote unit 105 includes a wearable device, such as a smart watch, a fitness band, an optical head-mounted display, or the like. In addition, the remote unit 105 may be referred to as a UE, a subscriber unit, a mobile device, a mobile station, a user, a terminal, a mobile terminal, a fixed terminal, a subscriber station, a user terminal, a wireless transmit / receive unit ("WTRU"), a device, or by other terms used in the art. In various embodiments, the remote unit 105 includes a subscriber identity and / or identification module ("SIM") and a mobile equipment ("ME") that provides mobile terminal functions (e.g., radio transmission, switching, speech encoding and decoding, error detection and correction, signaling, and access to the SIM). In certain embodiments, remote unit 105 may include terminal equipment ("TE") and / or be embedded in an appliance or device (eg, a computing device as described above).

[0056] The remote unit 105 may communicate directly with one or more of the base units 121 in the RAN 120 via uplink ("UL") and downlink ("DL") communication signals. In some embodiments, the remote unit 105 communicates in a non-terrestrial network via UL and DL communication signals between the remote unit 105 and a satellite 129. In certain embodiments, the satellite 129 may communicate with the RAN 120 via the NTN gateway 123 using UL and DL communication signals between the satellite 129 and the NTN gateway 123. The NTN gateway 123 may communicate directly with the base units 121 in the RAN 120 to relay the UL and DL communication signals.

[0057] Furthermore, UL and DL communication signals may be carried via wireless communication links during at least a portion of their paths between the RAN 120 and the remote unit 105. In the depicted embodiment, the wireless communication link between the remote unit 105 and the satellite 129 comprises a service link 125, while the wireless communication link between the satellite 129 and the base unit 121 comprises a feeder link 127. However, in other embodiments, satellite(s) and NTN gateways may be deployed between the base unit 121 or the RAN 120 and the mobile core network 140, e.g., similar to a wireless backhaul link.

[0058] The RAN 120 is an intermediate network that provides the remote units 105 with access to the mobile core network 140. In various embodiments, the UL communication signals may include one or more uplink channels, such as a physical uplink control channel ("PUCCH") and / or a physical uplink shared channel ("PUSCH"), and the DL communication signals may include one or more downlink channels, such as a physical downlink control channel ("PDCCH") and / or a physical downlink shared channel ("PDSCH").

[0059] Additionally, satellite 129 provides a non-terrestrial network that allows remote unit 105 to access mobile core network 140 via satellite access. Figure 1 A transparent NTN system is depicted in which satellite 129 repeats the waveform signal for base unit 121, but in other embodiments, satellite 129 (for a regenerative NTN system) or NTN gateway 123 (for an alternative implementation of a transparent NTN system) may also act as a base station, depending on the deployed configuration.

[0060] In some embodiments, the remote unit 105 communicates with an application server via a network connection with the mobile core network 130. For example, an application 107 in the remote unit 105 (e.g., a web browser, a media client, a phone and / or a Voice over Internet Protocol (“VoIP”) application) may trigger the remote unit 105 to establish a protocol data unit (“PDU”) session (or other data connection) with the mobile core network 130 via the RAN 120. The mobile core network 130 then relays traffic between the remote unit 105 and the application server (e.g., a content server 151 in the packet data network 150) using the PDU session. The PDU session represents a logical connection between the remote unit 105 and a user plane function (“UPF”) 131.

[0061] To establish a PDU session (or PDN connection), remote unit 105 must register with mobile core network 130 (also referred to as "attached to the mobile core network" in the context of fourth generation ("4G") systems). Note that remote unit 105 may establish one or more PDU sessions (or other data connections) with mobile core network 130. Thus, remote unit 105 may have at least one PDU session for communicating with packet data network 150 (e.g., representing the Internet). Remote unit 105 may establish additional PDU sessions for communicating with other data networks and / or other communication peer entities.

[0062] In the context of a 5G system ("5GS"), the term "PDU session" provides a data connection for end-to-end ("E2E") user plane ("UP") connectivity between a remote unit 105 and a specific data network ("DN") through UPF 131. A PDU session supports one or more quality of service ("QoS") flows. In certain embodiments, there may be a one-to-one mapping between QoS flows and QoS profiles such that all packets belonging to a specific QoS flow have the same 5G QoS identifier ("5QI").

[0063] In the context of 4G / LTE systems such as the Evolved Packet System (“EPS”), a Packet Data Network (“PDN”) connection (also referred to as an EPS session) provides E2E UP connectivity between a remote unit and the PDN. The PDN connectivity process establishes an EPS bearer, i.e., a tunnel between the remote unit 105 and a packet gateway (“PGW”, not shown) in the mobile core network 130. In certain embodiments, there is a one-to-one mapping between EPS bearers and QoS profiles, such that all packets belonging to a particular EPS bearer have the same QoS class identifier (“QCI”).

[0064] The base units 121 may be distributed throughout a geographic area. In some embodiments, the base units 121 may also be referred to as access terminals, access points, bases, base stations, node Bs ("NBs"), evolved node Bs (abbreviated as eNodeBs or "eNBs", also known as evolved universal terrestrial radio access network ("E-UTRAN") node Bs), 5G / NR node Bs ("gNBs"), home node Bs, relay nodes, RAN nodes, or by any other terminology used in the art. The base units 121 are typically part of a RAN (e.g., RAN 120) that may include one or more controllers communicatively coupled to one or more corresponding base units 121. These and other elements of a radio access network are not illustrated, but are generally familiar to those of ordinary skill in the art. The base units 121 are connected to the mobile core network 130 via the RAN 120. Note that in an NTN scenario, certain RAN entities or functions may be incorporated into the satellite 129. For example, the satellite 129 may be an embodiment of a non-terrestrial base station / base unit.

[0065] The base unit 121 may serve several remote units 105 within a service area, such as within a cell or cell sector, via a wireless communication link 123. The base unit 121 may communicate directly with one or more of the remote units 105 via communication signals. Typically, the base unit 121 transmits DL communication signals in the time domain, frequency domain, and / or spatial domain to serve the remote units 105. In addition, the DL communication signals may be carried via the wireless communication link 123. The wireless communication link 123 may be any suitable carrier in a licensed or unlicensed radio spectrum. The wireless communication link 123 facilitates communication between one or more of the remote units 105 and / or one or more of the base units 121. Note that during NR-U operation, the base unit 121 and the remote units 105 communicate via an unlicensed radio spectrum.

[0066] In one embodiment, mobile core network 130 is a 5GC or evolved packet core ("EPC"), which can be coupled to packet data network 150, such as the Internet and private data networks, as well as other data networks. Remote unit 105 may have a subscription or other account with mobile core network 130. Each mobile core network 130 belongs to a single public land mobile network ("PLMN"). The present disclosure is not intended to be limited to implementation of any particular wireless communication system architecture or protocol.

[0067] The mobile core network 130 includes several network functions ("NFs"). As depicted, the mobile core network 130 includes at least one UPF 131. The mobile core network 130 also includes a plurality of control plane ("CP") functions, including but not limited to an access and mobility management function ("AMF") 133 serving the RAN 120, a session management function ("SMF") 135, a network exposure function ("NEF"), a policy control function ("PCF") 137, a location management function ("LMF") 141, a unified data management function ("UDM"), and a user data repository ("UDR") 139.

[0068] In the 5G architecture, (several) UPFs 131 are responsible for packet routing and forwarding, packet inspection, QoS handling, and external PDU sessions for interconnected data networks ("DNs"). AMF 133 is responsible for NAS signaling termination, NAS encryption and integrity protection, registration management, connection management, mobility management, access authentication and authorization, and security context management. SMF 135 is responsible for session management (i.e., session establishment, modification, release), remote unit (i.e., UE) IP address allocation and management, DL data notification, and service steering configuration for UPF to perform appropriate service routing.

[0069] NEF is responsible for making it easy for customers and network partners to access network data and resources. Service providers can activate new functions and expose them through APIs. These APIs allow third-party authorized applications to monitor and configure network behavior for multiple different subscribers (i.e., connected devices with different applications). PCF 137 is responsible for the unified policy framework, providing policy rules for CP functions, and providing access subscription information for policy decisions in UDR.

[0070] In one embodiment, LMF 141 receives positioning measurements and estimates from RAN 120 and remote unit 105 (e.g., via AMF 133), and calculates the location of remote unit 105. UDM 139 is responsible for generating authentication and key agreement ("AKA") credentials, user identification handling, access authorization, subscription management. UDR is a repository of subscriber information and can be used to serve several network functions. For example, UDR can store subscription data, policy-related data, subscriber-related data that allows exposure to third-party applications, etc. In some embodiments, UDM is co-located with UDR, depicted as a combined entity "UDM / UDR" 139.

[0071] In various embodiments, the mobile core network 130 may also include an authentication server function ("AUSF"), which acts as an authentication server, a network repository function ("NRF"), which provides NF service registration and discovery, enabling NFs to identify appropriate services in each other and communicate with each other via application programming interfaces ("APIs"), or other NFs defined for the 5GC. In certain embodiments, the mobile core network 130 may include an authentication, authorization, and accounting ("AAA") server.

[0072] In various embodiments, the mobile core network 130 supports different types of mobile data connections and different types of network slices, where each mobile data connection utilizes a specific network slice. Here, "network slice" refers to a portion of the mobile core network 130 that is optimized for a specific traffic type or communication service. A network instance can be identified by a single network slice selection assistance information ("S-NSSAI"), and a set of network slices that the remote unit 105 is authorized to use is identified by the network slice selection assistance information ("NSSAI").

[0073] Here, "NSSAI" refers to a vector value that includes one or more S-NSSAI values. In some embodiments, various network slices may include separate instances of network functions, such as SMF 135 and UPF 131. In some embodiments, different network slices may share some common network functions, such as AMF 133. For ease of illustration, Figure 1Different network slices are not shown in the figure, but support for them is assumed. In the case where different network slices are deployed, the mobile core network 130 may include a network slice selection function ("NSSF") that is responsible for selecting a network slice instance to serve the remote unit 105, determining the allowed NSSAI, and determining the AMF group to be used to serve the remote unit 105.

[0074] although Figure 1 Although a specific number and type of network functions are depicted in the mobile core network 130, those skilled in the art will recognize that any number and type of network functions may be included in the mobile core network 130. Furthermore, in LTE variants in which the mobile core network 130 includes an EPC, the depicted network functions may be replaced with appropriate EPC entities, such as a mobility management entity ("MME"), a serving gateway ("SGW"), a PGW, a home subscriber server ("HSS"), and the like. For example, the AMF 133 may be mapped to the MME, the SMF 135 may be mapped to the control plane portion of the PGW and / or the MME, the UPF 131 may be mapped to the SGW and the user plane portion of the PGW, the UDM / UDR 139 may be mapped to the HSS, and the like.

[0075] Although Figure 1 Components of a 5G RAN and 5G core network are depicted, but the described embodiments are applicable to other types of communication networks and RATs, including IEEE 802.11 variants, Global System for Mobile Communications (“GSM”, the 2G digital cellular network), General Packet Radio Service (“GPRS”), UMTS, LTE variants, CDMA 2000, Bluetooth, ZigBee, Sigfox, and the like.

[0076] In the following description, the term "gNB" is used for a base station, but it may be replaced by any other radio access node, such as a RAN node, an eNB, a base station ("BS"), an access point ("AP"), a NR, etc. In addition, the operations are mainly described in the context of 5G NR. However, the proposed solution / method is also equally applicable to other mobile communication systems that support CSI enhancement for higher frequencies.

[0077] Figure 2 Depicts an NR protocol stack 200 according to an embodiment of the present disclosure. Figure 2UE 205, RAN node 210, and AMF 215 are shown in a 5G core network ("5GC"), but these represent a set of remote units 105 interacting with base unit 121 and mobile core network 140. As depicted, protocol stack 200 includes user plane protocol stack 201 and control plane protocol stack 203. User plane protocol stack 201 includes physical ("PHY") layer 220, medium access control ("MAC") sublayer 225, radio link control ("RLC") sublayer 230, packet data convergence protocol ("PDCP") sublayer 235, and service data adaptation protocol ("SDAP") sublayer 240. Control plane protocol stack 203 includes physical layer 220, MAC sublayer 225, RLC sublayer 230, and PDCP sublayer 235. Control plane protocol stack 203 also includes radio resource control ("RRC") sublayer 245 and non-access stratum ("NAS") sublayer 250.

[0078] The AS layer (also referred to as the "AS protocol stack") of the user plane protocol stack 201 is composed of at least SDAP, PDCP, RLC and MAC sublayers and a physical layer. The AS layer of the control plane protocol stack 203 is composed of at least RRC, PDCP, RLC and MAC sublayers and a physical layer. Layer 2 ("L2") is divided into SDAP, PDCP, RLC and MAC sublayers. Layer 3 ("L3") includes an RRC sublayer 245 and a NAS layer 250 for the control plane, and includes, for example, an Internet Protocol ("IP") layer and / or a PDU layer (not depicted) for the user plane. L1 and L2 are referred to as "lower layers", while L3 and above (e.g., transport layer, application layer) are referred to as "higher layers" or "upper layers".

[0079] The physical layer 220 supplies transport channels to the MAC sublayer 225. The physical layer 220 may perform clear channel assessment and / or listen before talk ("CCA / LBT") procedures using energy detection thresholds, as described herein. In certain embodiments, the physical layer 220 may send a notification of a UL listen before talk ("LBT") failure to the MAC entity at the MAC sublayer 225. The MAC sublayer 225 supplies logical channels to the RLC sublayer 230. The RLC sublayer 230 supplies RLC channels to the PDCP sublayer 235. The PDCP sublayer 235 supplies radio bearers to the SDAP sublayer 240 and / or the RRC layer 245. The SDAP sublayer 240 supplies QoS flows to the core network (e.g., 5GC). The RRC layer 245 provides for the addition, modification, and release of carrier aggregation and / or dual connectivity. The RRC layer 245 also manages the establishment, configuration, maintenance, and release of signaling radio bearers ("SRBs") and data radio bearers ("DRBs").

[0080] The NAS layer 250 is between the UE 205 and the 5GC 215. NAS messages are passed transparently through the RAN. The NAS layer 250 is used to manage the establishment of communication sessions and to maintain continuous communication with the UE 205 when the UE 205 moves between different cells of the RAN. In contrast, the AS layer is between the UE 205 and the RAN (e.g., the RAN node 210) and carries information via the wireless portion of the network.

[0081] As background, NR positioning based on NR Uu signals and a standalone ("SA") architecture (e.g., beam-based transmission) was first specified in Rel-16. Target use cases also include commercial and regulatory (e.g., emergency services) scenarios as in Rel-15. The performance requirements are as follows, for example, as described in TR 38.855:

[0082] Positioning Error indoor outdoor Horizontal positioning For 80% of UEs, <3m For 80% of UEs, <10m Vertical positioning For 80% of UEs, <3m For 80% of UEs, <3m

[0083] 3GPP Rel-17 Positioning recently defined positioning performance requirements for commercial and IIoT use cases as follows, for example, as described in TR38.857:

[0084]

[0085] Some UE positioning techniques supported in Rel-16 are listed in Table 1. Individual positioning techniques as indicated in Table 2 may be configured and performed based on the requirements of the LMF and / or UE capabilities. Note that Table 1 includes Terrestrial Beacon System ("TBS") positioning based on PRS signals, but only Observed Time Difference of Arrival ("OTDOA") based on LTE signals is supported. E-CID includes the cell ID for the NR method. The TBS method refers to TBS positioning based on metropolitan beacon system ("MBS") signals.

[0086]

[0087]

[0088] Table 1: Supported Rel-16 UE positioning methods

[0089] The transmission of the PRS enables the UE to perform measurements related to UE positioning to enable calculation of a position estimate of the UE, and is configured as a transmit receive point ("TRP"), where a TRP may transmit one or more beams.

[0090] In one embodiment, system 100 may support the following RAT-dependent positioning techniques:

[0091] DL-TDoA: The downlink time difference of arrival ("DL-TDOA") positioning method utilizes the DL RS time difference ("RSTD") (and optionally the DL PRS RS received power ("RSRP") of downlink signals received from multiple TPs at a UE (e.g., remote unit 105). The UE measures the DL RSTD (and optionally the DL PRS RSRP) of the received signals using assistance data received from a positioning server, and uses the resulting measurements along with other configuration information to position the UE relative to neighboring transmission points ("TPs").

[0092] DL-AoD: The DL Angle of Departure ("AoD") positioning method utilizes the measured DL PRS RSRP of downlink signals received at the UE from multiple TPs. The UE uses assistance data received from a positioning server to measure the DL PRS RSRP of the received signals and uses the resulting measurements along with other configuration information to position the UE relative to neighboring TPs.

[0093] Multi-RTT: The multiple round trip time ("multi-RTT") positioning method utilizes UE receive-transmit ("Rx-Tx") measurements and DL PRS RSRP measured by the UE of downlink signals received from multiple TRPs and gNB Rx-Tx measurements (e.g., measured by a RAN node) and UL Sounding Reference Signal ("SRS")-RSRP at multiple TRPs of uplink signals transmitted from the UE.

[0094] The UE measures UE Rx-Tx measurements (and optionally DL PRS RSRP of received signals) using assistance data received from the positioning server, and TRP measures gNB Rx-Tx measurements (and optionally UL SRS-RSRP of received signals) using assistance data received from the positioning server. The measurements are used to determine the round trip time ("RTT") at the positioning server, which is used to estimate the position of the UE. In one embodiment, multi-RTT is only supported for UE-assisted / NG-RAN-assisted positioning techniques, as mentioned in Table 1.

[0095] E-CID / NR E-CID: Enhanced Cell ID ("CID") positioning method, which uses the UE's knowledge of the serving ng-eNB, gNB and cell to estimate the UE's position, and the position is based on LTE signals. Information about the serving ng-eNB, gNB and cell can be obtained through paging, registration or other methods. NR Enhanced Cell ID ("NR E-CID") positioning refers to the use of additional UE measurements and / or NR radio resources and other measurements to improve the UE position estimate using NR signals.

[0096] Although NR E-CID positioning may utilize some of the same measurements as the measurement control system in the RRC protocol, it is generally not expected that the UE will perform additional measurements solely for positioning purposes; for example, the positioning procedure does not supply measurement configuration or measurement control messages, and the UE reports its available measurements rather than being required to take additional measurement actions.

[0097] UL-TDoA: The UL TDOA positioning method utilizes UL TDOA (and optionally UL SRS-RSRP) at multiple reception points ("RPs") of uplink signals transmitted from the UE. The RPs measure the UL TDOA (and optionally UL SRS-RSRP) of the received signals using assistance data received from a positioning server, and use the resulting measurements together with other configuration information to estimate the position of the UE.

[0098] UL-AoA: The UL Angle of Arrival ("AoA") positioning method utilizes the measured azimuth and zenith angle of arrival at multiple RPs of uplink signals transmitted from the UE. The RP uses assistance data received from a positioning server to measure the A-AoA and Z-AoA of the received signal, and uses the resulting measurements along with other configuration information to estimate the UE's position.

[0099] In one embodiment, system 100 may support various RAT independent technologies, for example, as described in TS 38.305. In one embodiment, a network-assisted global navigation satellite system ("GNSS") method utilizes a UE equipped with a radio receiver capable of receiving GNSS signals. In the 3GPP specifications, the term GNSS covers both global and regional / augmented navigation satellite systems.

[0100] Examples of global navigation satellite systems include GPS, modernized GPS, Galileo, GLONASS, and the BeiDou Navigation Satellite System ("BDS"). Regional navigation satellite systems include the Quasi-Zenith Satellite System ("QZSS"), while many augmentation systems are classified under the general term Space-Based Augmentation System ("SBAS") and provide regional augmentation services. In this concept, different GNSS (e.g., GPS, Galileo, etc.) may be used alone or in combination to determine the position of a UE.

[0101] In one embodiment, the air pressure sensor method utilizes an air pressure sensor to determine the vertical component of the UE's position. The UE measures the air pressure, optionally assisted by assistance data, to calculate the vertical component of its position or sends the measurement to a positioning server for position calculation. This method can be combined with other positioning methods to determine the 3D position of the UE.

[0102] In one embodiment, the WLAN positioning method uses WLAN measurements (e.g., AP identifiers and optionally other measurements) and a database to determine the location of the UE. The UE measures the signals received from the WLAN access points, optionally assisted by assistance data, to send the measurements to a positioning server for position calculation. Using the measurement results and a reference database, the location of the UE is calculated. Alternatively, the UE determines its location using WLAN measurements and optionally WLAN AP assistance data provided by a positioning server.

[0103] In one embodiment, the Bluetooth positioning method uses Bluetooth measurements (beacon identifiers and optionally other measurements) to determine the location of the UE. The UE measures the signals received from the Bluetooth beacons. Using the measurement results and a reference database, the location of the UE is calculated. The Bluetooth method can be combined with other positioning methods (e.g., WLAN) to improve the positioning accuracy of the UE.

[0104] In one embodiment, the TBS consists of a network of ground-based transmitters that broadcast signals for positioning purposes only. Current types of TBS positioning signals are MBS signals and PRS. The UE measures the received TBS signals, optionally assisted by assistance data, to calculate its position or transmits the measurements to a positioning server for position calculation.

[0105] In one embodiment, the motion sensor method uses different sensors such as accelerometers, gyroscopes, magnetometers, etc. to calculate the displacement of the UE. The UE estimates the relative displacement based on a reference position and / or a reference time. The UE sends a report including the determined relative displacement that can be used to determine the absolute position. This method should be used in conjunction with other positioning methods for hybrid positioning.

[0106] Figure 3 Depicted is a system 300 for NR beam-based positioning. According to Rel-16, PRS may be transmitted by different base stations (serving base station and neighboring base stations) using narrow beams between frequency range #1 ("FR1", e.g., frequencies from 410 MHz to 7125 MHz) and frequency range #2 ("FR2", e.g., frequencies from 24.25 GHz to 52.6 GHz), which is relatively different when compared to LTE where PRS is transmitted across the entire cell.

[0107] like Figure 3, a UE 305 may receive PRS from a first gNB ("gNB 3") 310 as a serving gNB, as well as a neighboring second gNB ("gNB 1") 315, and a neighboring third gNB ("gNB 2") 320. Here, the PRS may be locally associated with a set of PRS resources grouped under a resource set ID of a base station (e.g., a TRP). In the depicted embodiment, each gNB 310, 315, 320 is configured with a first resource set ID 325 and a second resource set ID 330. As depicted, UE 305 receives PRS on the transmit beam; here, PRS is received from gNB 3 310 on a set of PRS resources 335 from the second resource set ID 330, PRS is received from gNB 1 315 on a set of PRS resources 335 from the second resource set ID 330, and PRS is received from gNB 2 320 on a set of PRS resources 335 from the first resource set ID 325.

[0108] Similarly, UE positioning measurements, such as Reference Signal Time Difference ("RSTD") and PRS RSRP measurements, are made between beams rather than between different cells as in LTE. In addition, there are additional UL positioning methods that the network utilizes in order to calculate the position of the target UE. Tables 2 and 3 show the mapping of reference signals to measurements required for each of the supported RAT-dependent positioning techniques at the UE and gNB, respectively. RAT-dependent positioning techniques involve 3GPP RAT and core network entities to perform position estimation for the UE, which is different from RAT-independent positioning techniques that rely on GNSS, IMU sensors, WLAN, and Bluetooth technologies to perform positioning of the target device (e.g., UE).

[0109]

[0110] Table 2: UE measurements for implementing RAT-dependent positioning techniques

[0111]

[0112] Table 3: gNB measurements for RAT-dependent positioning techniques

[0113] Regarding measurement and reporting configuration, according to TS 38.215, UE measurements have been defined, which are applicable to DL-based positioning techniques, see subclause 2.4. For a conceptual overview of the current implementation in Rel-16, assistance data configuration is provided for each of the supported positioning techniques (see Figure 4A ) and measurement information (see Figure 4B ):

[0114] Figure 4AThe information element ("IE") NR-DL-TDOA-ProvideAssistanceData 402 shown in FIG. 4 is used by the location server to provide assistance data to enable UE-assisted and UE-based NR downlink TDOA. It can also be used to provide NRDL TDOA positioning specific error causes.

[0115] Figure 4B The IE NR-DL-TDOA-SignalMeasurementlnformation 404 shown in is used by the target device to provide NR-DL TDOA measurements to the location server. The measurements are provided as a list of TRPs, where the first TRP in the list is used as the reference TRP in case of reporting RSTD measurements. The first TRP in the list may or may not be the reference TRP indicated in the NR-DL-PRS-AssistanceData. In addition, the target device selects a reference resource per TRP and compiles the measurements per TRP based on the selected reference resource.

[0116] Regarding RAT-dependent positioning measurements, different DL measurements including DL PRS-RSRP, DL RSTD and UE Rx-Tx time difference required for supported RAT-dependent positioning techniques are shown in Table 4. The following measurement configurations may be specified:

[0117] • 4 pairs of DL RSTD measurements may be performed per pair of cells. Each measurement is performed between a pair of different DL PRS resources / resource sets with a single reference timing.

[0118] • 8 DL PRS RSRP measurements may be performed on different DL PRS resources from the same cell.

[0119]

[0120]

[0121] Table 4: DL measurements required for DL-based positioning methods

[0122] Figure 5An architecture in a 5GS suitable for positioning a UE with NR or E-UTRA access is shown. In one embodiment, AMF 133 receives a request for a certain location service associated with a specific target UE from another entity (e.g., a Gateway Mobile Location Center ("GMLC") or a UE), or AMF 133 itself decides to initiate a certain location service on behalf of a specific target UE (e.g., for an IP Multimedia System ("IMS") emergency call from the UE), for example, as described in TS23.502 and TS23.273. AMF 133 then sends a location service request to LMF 141. LMF 141 processes the location service request, which may include transmitting assistance data to the target UE to assist in UE-based and / or UE-assisted positioning and / or may include positioning of the target UE. LMF 141 then returns the result of the location service to AMF 133 (e.g., a positioning estimate for the UE). In case of location service requested by an entity other than AMF 133 (e.g. GMLC or UE), AMF 133 returns the location service result to this entity.

[0123] In one embodiment, the NG-RAN node may control several TRPs / TPs, such as remote radio heads or DL-PRS-only TPs to support PRS-based TBS. In one embodiment, LMF 141 may have a dedicated signaling connection to the E-Serving Mobile Location Center ("SMLC"), which may enable LMF 141 to access information from E-UTRAN (e.g., to support OTDOA for E-UTRA positioning methods using downlink measurements of signals from eNBs and / or PRS-only TPs in E-UTRAN obtained by the target UE). LMF 141 may have a dedicated signaling connection to the SLP. The SLP is the SUPL entity responsible for positioning on the user plane. More details of user plane positioning are provided in TS38.305 Annex A.

[0124] In case of split gNB architecture, the gNB-DU may include TRP functionality, where TRP functionality may support functions for TP, RP, or both TP and RP. The gNB-DU including TRP functionality is not required to provide cell service.

[0125] Regarding RAN-UE positioning operations, in order to support the positioning of the target UE and the delivery of location assistance data to the UE with NG-RAN access in 5GS, location-related functions such as Figure 5 The architecture is shown in TS23.501 and TS23.273 and is distributed as explained in more detail. Figure 6 The overall sequence of events for UE, NG-RAN and LMF applicable to any location service is shown in FIG.

[0126] Note that when the AMF receives a location service request while the UE is in CM-IDLE state, the AMF performs a network-triggered service request, e.g. as defined in TS 23.502 and TS 23.273, to establish a signaling connection with the UE and assign a specific serving gNB or NG-eNB. Assuming the UE is in Figure 6 1a, the UE is in connected mode before the start of the process shown in FIG; that is, any signaling that may be required to put the UE into connected mode before step 1a is not shown. However, the signaling connection may be released later (e.g., by the NG-RAN node due to signaling and data inactivity) while positioning is still in progress.

[0127] In one embodiment, Figure 6 The process flow depicted in FIG. 6 includes UE 601, NG-RAN node 603, AMF 133, LMF 141 and 5GC location service (“LCS”) entity 605.

[0128] In step 1a, an entity in the 5GC (e.g., GMLC) requests (see messaging 602) a location service (e.g., positioning) for the target UE 601 from the serving AMF 133. In step 1b, the serving AMF 133 for the target UE 601 determines (see box 604) the need for a certain positioning service (e.g., to locate the UE 601 for an emergency call). In step 1c, the UE 601 requests (see messaging 606) a certain location service (e.g., positioning or delivery assistance data) from the serving AMF 133 at the NAS level.

[0129] In one embodiment, in step 2, the AMF 133 transmits (see messaging 608) a location service request to the LMF 141. In step 3a, the LMF 141 initiates (see box 610) a positioning procedure with the serving ng-eNB or gNB in ​​the NG-RAN 603 and possibly neighboring ng-eNBs or gNBs—e.g., to obtain positioning measurements or assistance data. In one embodiment, in addition to or as an alternative to step 3a, in step 3b, the LMF 141 initiates (see box 612) a positioning procedure with the UE 601—e.g., to obtain a position estimate or positioning measurements or to transmit position assistance data to the UE 601.

[0130] In one embodiment, at step 4, LMF 141 provides (see messaging 614) a location services response to AMF 133, and includes any desired results—e.g., a success or failure indication, and if requested and obtained, a location estimate for UE 601. In one embodiment, at step 5a, if step 1a is performed, then AMF 133 returns (see messaging 616) a location services response to 5GC entity 605 at step 1a, and includes any desired results—e.g., a location estimate for UE 601. In one embodiment, at step 5b, if step 1b occurs, then AMF 133 uses (see box 618) the location services response received in step 4 to assist the services that triggered this in step 1b (e.g., a location estimate associated with an emergency call may be provided to GMLC). In step 5c, in one embodiment, if step 1c is performed, then AMF 133 returns a location services response to UE 601, and includes any desired results—e.g., a location estimate for UE 601.

[0131] In one embodiment, the positioning process applicable to NG-RAN occurs at Figure 6 In steps 3a and 3b of . Figure 6 The other steps in are applicable to 5GC and are described in more detail in TS23.502 and TS23.273. In one embodiment, steps 3a and 3b involve obtaining position-related measurements of the target UE using different positioning methods, and calculating a position estimate and possibly additional information such as velocity based on these position-related measurements.

[0132] Figure 7 Depicts a process flow for a NG-RAN location reporting procedure, e.g., as described in TS 23.502. In one embodiment, the AMF 133 uses the depicted procedure to request the NG-RAN 701 to report where the target UE is currently located when the UE is in the CM-CONNECTED state. The need for the NG-RAN 701 to continue reporting ceases when the UE transitions to CM-IDLE or the AMF 133 sends a cancel indication to the NG-RAN 701. This procedure may be used for services that require accurate cell identification (e.g., emergency services, lawful interception, charging), or for services subscribed to by other NFs. When dual connectivity is activated, PSCell information is reported only upon request by the AMF 133.

[0133] In step 1, in one embodiment, the AMF 133 sends (see messaging 702) a Location Reporting Control message to the NG-RAN 701. The Location Reporting Control message shall identify the UE for which a report is requested and shall contain the reporting type and the location reporting level. The Location Reporting Control message may also contain the area of ​​interest and the request reference ID. The location reporting level may be TAI + cell identity. The reporting type indicates whether the message wishes to trigger a single independent report on the current cell identity serving the UE, or to initiate the NG-RAN 701 to report whenever the UE changes cells, or to request the NG-RAN 701 to report whenever the UE moves out of or into an area of ​​interest. If the reporting type indicates reporting whenever the UE changes cells, and if PSCell reporting is requested and dual connectivity is being used, the primary RAN node shall also report to the AMF 133 whenever the PSCell changes. If the reporting type indicates initiating the NG-RAN 701 to report when the UE moves out of or into an area of ​​interest, the AMF 133 also provides the requested area of ​​interest information in the Location Reporting Control message. AMF 133 may include a request reference ID in the location report control message to identify the report request for the concerned area. If multiple concerned areas are included in the message, the request reference ID identifies each concerned area.

[0134] Note that requesting a report every time the UE changes cell may increase the signaling load on multiple interfaces. Requesting reporting of all changes to PSCell IDs may further increase the signaling load. Therefore, it is recommended that any such reporting is only applicable to a limited number of subscribers.

[0135] In step 2, in one embodiment, the NG-RAN 701 sends (see messaging 704) a location report message informing the AMF 133 of the location of the UE, which will be indicated as the requested location reporting level. If PSCell reporting is requested and dual connectivity is activated, the primary NG-RAN node should also include the PSCell ID. In the case of NR satellite access, the cell and TAI reporting of the NG-RAN refers to the fixed cell and fixed TA in which the UE is geographically located. As part of the user location information, the NG-RAN also reports one or more Tracking Area Codes ("TACs") for the selected PLMN, for example as described in TS 38.413, but there is no guarantee that the UE is always located in one of these TACs.

[0136] When the UE is in CM-CONNECTED with RRC Inactive state, if the NG-RAN 701 has received a Location Reporting Control message with a Report Type indicating a single independent report from the AMF 133, then the NG-RAN 701 shall perform NG-RAN paging before reporting the location to the AMF 133. The NG-RAN 701 shall send the location report promptly and shall not wait to attempt to create a dual connectivity configuration. However, if a PSCell report is requested and the PSCell ID is known to the primary RAN node, then it shall be included in the location report. In case of RAN paging failure, the RAN reports the last known location of the UE with a timestamp.

[0137] When the UE is in CM-CONNECTED with RRC Inactive state, if the NG-RAN 701 has received a Location Reporting Control message with a reporting type indicating continuous reporting whenever the UE changes cells from the AMF 133, the NG-RAN 701 shall send a Location Reporting message containing the last known location of the UE with a timestamp to the AMF 133. If the UE was using dual connectivity and requested PSCell reporting immediately before entering CM-CONNECTED with RRC Inactive state, the location report shall also contain the PSCell ID.

[0138] While the UE is in CM-CONNECTED, if the NG-RAN 701 has received a Location Reporting Control message with a reporting type of reporting based on an area of ​​concern from the AMF 133, then the NG-RAN 701 shall track the UE presence in the area of ​​concern and send a Location Report message to the AMF 133 containing the UE presence in the area of ​​concern (e.g. inside, outside or unknown), as described in clause D.2, and the current location of the UE (including the PSCell ID if PSCell reporting is requested and dual connectivity is activated) when the UE is in RRC Connected state, or the last known location of the UE with a timestamp (including the PSCell ID if PSCell reporting is requested and the UE was using dual connectivity immediately before entering CM-CONNECTED with RRC Inactive state) if the NG-RAN 701 perceives that the UE presence in the area of ​​concern is different from the last reported location when the UE is in RRC Inactive state. When the NG-RAN 701 detects that the UE has moved out of or into multiple areas of interest, it sends multiple pairs of the UE presence in the areas of interest and the requested reference ID in one location report message to the AMF 133. If the UE transitions from RRC Inactive state to RRC Connected state, the NG-RAN 701 will check the latest location of the UE (including PSCell ID if PSCell reporting is requested and dual connectivity is activated) and follow the rules when the UE is in RRC Connected.

[0139] AMF 133 may receive location reports even if there is no change in the UE presence in the area of ​​interest. AMF 133 stores the most recently received PSCell ID with its associated timestamp. When available, AMF 133 stores the most recently received PSCell ID with its associated timestamp.

[0140] In one embodiment, in step 3, AMF 133 may send a cancel location reporting message to inform NG-RAN 701 that it should terminate location reporting for a given UE corresponding to the reporting type or for the area of ​​interest indicated by the request reference ID. This message is required when the reporting type is requested for continuous reporting or for the area of ​​interest. AMF 133 may include a request reference ID indicating the requested location reporting control of the area of ​​interest so that NG-RAN 701 should terminate location reporting for the area of ​​interest. Note that during Xn handover, location reporting related information of the source NG-RAN node is transmitted to the target NG-RAN node.

[0141] Fig. 8AOne embodiment of a transparent satellite-based NG-RAN architecture is depicted. In the depicted embodiment, the satellite payload implements frequency conversion and radio frequency amplifiers in both the uplink and downlink directions. It corresponds to an analog RF repeater. Therefore, the satellite 802 repeats the NR-Uu 804 radio interface from the feeder link (between the NTN gateway 806 and the satellite 802) to the service link (between the satellite 802 and the UE 810), and vice versa. The satellite radio interface ("SRI") on the feeder link is NR-Uu 804. In other words, the satellite does not terminate NR-Uu 804. NTN GW 806 supports all necessary functions for forwarding signals of the NR-Uu 804 interface. Different transparent satellites can be connected to the same gNB 808 on the ground. It should be noted that although several gNBs 808 can access a single satellite payload, without loss of generality, the description has been simplified to a single gNB 808 accessing the satellite payload.

[0142] Figure 8B Depicts one embodiment of a regenerative satellite-based NG-RAN architecture without ISLs. In one embodiment, the NG-RAN logical architecture as described in TS 38.401 is used as a baseline for the NTN scenario. The satellite payload implements the regeneration of the signal received from the earth. The NR-Uu 804 radio interface is the service link between the UE 810 and the satellite 802 and the SRI 812 on the feeder link between the NTN gateway 806 and the satellite 802. The SRI 812 is the transmission link between the NTN GW 806 and the satellite 802. It should be noted that the satellite 802 may assume additional traffic routing functions outside the scope of the RAN. The satellite payload also provides ISLs between satellites. ISLs are transmission links between satellites. ISLs may be radio interfaces or optical interfaces, which may be 3GPP or non-3GPP defined, but this is outside the scope of the study project. The NTN GW 806 is a transport network layer node and supports all necessary transport protocols.

[0143] Figure 8C Depicting one embodiment of a regenerative satellite-based NG-RAN architecture with ISLs. Figure 8C It is illustrated that a UE 810 served by a gNB 808 carried by a satellite 802 can access a 5GCN 814 via an ISL. gNBs 808 carried by different satellites 802 can connect to the same 5GCN 814 on the ground. If a satellite 802 hosts more than one gNB 808, the same SRI 812 will transport all corresponding NG interface instances.

[0144] In general, the solutions disclosed herein provide various solution enhancements for achieving network verified positioning of target UEs. In one embodiment, a solution is disclosed for enabling the AMF to transmit a UE location verification request to a NG-RAN node equipped with an LMC so as to have a low latency verification process, while the verification can be performed by the LMC or the AMF.

[0145] In one embodiment, a solution is disclosed for enabling an AMF to trigger a network induced positioning procedure, wherein a location estimate based on a specific positioning method (e.g., RAT dependent or RAT independent) is configured. In one embodiment, a solution is disclosed for first verifying the UE location by the AMF by employing a RAT dependent technique and then verifying the assisted location estimate by comparing the assisted location estimate using the RAT independent method with the first location estimate using the RAT dependent method.

[0146] In one embodiment, a solution is disclosed for triggering the LMF to initiate a network verified positioning process using NTN RAT-dependent positioning technology. Note that the various embodiments disclosed below may be implemented in combination with each other to support NR positioning using supported NTN interfaces and network entities / nodes. In one embodiment, for the purposes of this disclosure, positioning-related reference signals may refer to reference signals used for positioning processes / purposes to estimate the position of a target UE (e.g., PRS), or based on existing reference signals such as SRS, and the target UE may be referred to as a device / entity to be localized / positioned. In one embodiment, the target UE is referred to as a UE of interest where the position will be calculated by the network or the target UE itself. In addition, the subject matter disclosed in Lenovo patent application SMM020220103-GR-NP (IDF-153114) is incorporated herein by reference and may be implemented in combination with the embodiments in this disclosure.

[0147] In the first embodiment for low latency verification based on LMC in NG-RAN, as Fig.9A , after completing UE registration in step 0 (see messaging 902), the AMF 133 transmits a UE location verification request to the NG-RAN node 903 equipped with LMC in step 1 (see messaging 904). This is applicable to scenarios where the LMF can be co-located with the NG-RAN node 903, where this implementation may be more common in NTN networks to avoid longer propagation delays and thus enhance positioning accuracy. This implementation means that the gateway and NTN-gNB can be equipped with LMC functionality or can be co-located with the LMF.

[0148] In one embodiment, at steps 2.1 and 2.2, NG-RAN node procedures (see box 906) and UE procedures (see box 908) are performed. In one embodiment, at step 3, the LMC at the NG-RAN node 903 performs (see box 910) a LMC verification decision. In this embodiment, the LMC includes all or part of the functional set of the LMF, including positioning capability exchange, PRS / SRS resource configuration, selection of positioning methods, positioning measurement configuration and reporting procedures. This implementation provides a low latency method for the verification process, whereby the NG-RAN and LMC (location management component) coordinate the determination of the location of the UE 901 using RAT dependent and / or RAT independent methods, while also performing verification. In one embodiment, at step 4, a verification response message is sent (see messaging 912) to the AMF 133, and if not verified, the UE 901 is deregistered (see process 914).

[0149] Fig. 9B Describes another process flow for low latency validation using NG-RAN and LMC combined functionality. Fig. 9B The process described in can be roughly similar to Fig.9A , except that the AMF 133 sends a location request to the NG-RAN / LMC 903 at step 1 (see messaging 920) to request a location estimate for the UE 901, receives a location response from the NG-RAN / LMC 903 at step 3 (see messaging 922), and performs a validation decision based on the location estimate at step 4 (see box 924).

[0150] In one embodiment, the location request or verification message from the AMF 133 to the NG-RAN / LMC 903 is sent using the Nlmf_Location_DetermineLocation service operation, where this message may explicitly contain an indication of a location request based on a RAT-dependent method or a field indicating a verification request. In the presence of a field indicating a verification procedure, the NG-RAN / LMC 903 may only adopt the RAT-dependent method. Based on the indicated request (verification procedure or location estimate), the NG-RAN / LMC 903 performs the corresponding operation. Once the indicated service operation has been completed, the NG-RAN / LMC 903 may send a Nlmf_Location_DetermineLocation response message, indicating the verification or positioning request.

[0151] In one embodiment, a new signaling procedure for verifying the location of the target UE 901 is adopted, wherein the procedure is based on request / response messages, such as Namf_location_verification request and response messages containing information related to the verification procedure of the target UE 901 location.

[0152] In a second embodiment for a network induced (e.g. AMF to LMF and LMF to AMF) positioning procedure with method type, the AMF invokes a positioning service operation to the LMF, which explicitly contains information about the type of method to be used for position estimation, e.g. RAT independent or RAT dependent, in addition to services such as quality of service and serving cell identity. This information may be necessary for UE reported position verification purposes, since some methods may be considered unreliable (e.g. due to spoofed GNSS) or some methods may be invalid or inaccurate for a given scenario (e.g. triangulation based methods, cell ID based methods or even RTT based methods in NTNs). Additionally, the AMF may need a position based on a specific type of positioning method to compare the result with some previous positions achieved with other methods, to verify it with a reliable method, or to avoid long processing delays in the position estimate.

[0153] exist Fig. 10A In an example embodiment shown in FIG. 1002 , in step 1 , AMF 133 initiates a UE location request to LMF 141 using the Nlmf_Location_DetermineLocation service operation (see messaging 1002 ), wherein this service operation includes an explicit field (e.g., “RAT_method_type”) to indicate the type of method used for location determination. In one implementation, the field may indicate the use of a RAT independent method or a RAT dependent method for location estimation purposes, leaving the selection of the method to be used to LMF 141. In another implementation, the field indicates one or a set of methods to be used for UE location determination. For example, AMF 133 may be aware of the UE positioning capabilities and, based on this information, indicate which type of method will be utilized, or AMF 133 may know that UE 1001 is connected via a single satellite, so in this case, a single satellite based positioning method will be used. Therefore, AMF 133 may indicate to LMF 141 to select one of the methods from a set of applicable methods.

[0154] In one embodiment, information about the type of method to be used by the LMF 141 may be embedded in the LCS QoS information. For example, a new QoS class may be specified for location verification purposes for NTN, where this class includes methods that meet the verification accuracy requirements of the NTN system (e.g., 5 to 10 km) and excludes those methods that still meet the accuracy but are unreliable (e.g., GNSS). In this case, the LMF decision about the positioning method is determined based on the QoS criteria. In one example, the response time field in the LCS QoS information may also determine the method to be adopted and may be read together with the QoS class. For example, a large response and NTN verification QoS may mean a RAT-dependent method, and a short response time may mean a RAT-independent method such as GNSS.

[0155] In one embodiment, a new field is included in the request message indicating that the location estimate is for verification purposes. In this scenario, LMF 141 follows the RAT-dependent method for location estimation, and the selection of the corresponding RAT-dependent positioning method (RTT, AoA or similar) will be performed by LMF 141.

[0156] Based on the request received from AMF 133, LMF 141 performs one or more positioning procedures indicated in the LMF request message, such as Fig. 10A 1004). If AMF 133 indicates a specific positioning method, then LMF 141 initiates the positioning process according to the method. Otherwise, LMF 141 may select any RAT method process. In this embodiment, LMF 141 selects the method based on the defined parameter set and initiates the process. The LMF 141 positioning process may be a UE-assisted and / or UE-based positioning process triggered by employing the LTE Positioning Protocol ("LPP"), or may be a network-assisted and / or network-based positioning based on the NR Positioning Protocol A ("NRPPa") protocol.

[0157] In one embodiment, the estimated current location of the target UE is returned by LMF 141 to AMF 133 using an Nlmf_Location_DetermineLocation response message. Fig. 10A3 in step 3 (see messaging 1006). The service operation may include an LCS related identifier, a location estimate with a timestamp, and the positioning method used. In one embodiment, UE 1001 may not have the capability of the positioning method that has been requested by AMF 133. In this embodiment, LMF 141 may initiate an Nlmf_Location_DetermineLocation response message with a field stating that the requested message is not supported. In addition, LMF 141 may also include alternative UE positioning capabilities / methods in the same message.

[0158] In one embodiment, the request message may contain a field indicating that the location estimation and verification process will be completed by a configured network entity (e.g., LMF, LMC). In this case, both the location estimation and verification process may be performed by the configured entity. The configured network entity may use a positioning process from a RAT-dependent method. Upon completion of the verification process, a response message will be sent and will contain both the location estimate of the target UE (and related information, such as the positioning method) and the verification result (e.g., whether the verification was successful), or will only contain information about the verification result (e.g., whether the verification was successful).

[0159] exist Fig. 10B In one embodiment shown in FIG. 1 , AMF 133 using the Nlmf_Location_DetermineLocation service operation may request LMF 141 to estimate and report multiple UE locations using multiple method types (RAT-dependent and RAT-independent), where each location estimate corresponds to a positioning method, such as Fig. 10B (see messaging 1010). For example, AMF 133 may request two position estimates based on RAT-dependent and RAT-independent positioning procedures.

[0160] In this embodiment, the field RAT_method_type may indicate multiple method types. Since multiple location estimates with different method types may be needed to verify the UE location, this process may be beneficial to reduce latency, especially in NTNs. Upon receiving an AMF 133 request to estimate and report multiple location estimates with different method types, the LMF 141 initiates the positioning process at step 2 (see box 1004). Once the LMF 141 has the current location of the UE corresponding to the different methods, the LMF 141 may invoke the Nlmf_Location_DetermineLocation response message at step 3 (see message 1012), in which the LMF 141 indicates multiple location estimates with timestamps and the corresponding positioning methods used to estimate the location, in addition to other information such as an LCS-related identifier.

[0161] In a third embodiment, for an AMF initiated location and verification procedure based on multiple location estimates with different RAT method types, after UE registration has been completed and there is no information about the UE location during the registration process, the AMF initiates two location request messages to the LMF for location estimation using a RAT dependent method and a RAT independent method, wherein the AMF verifies the first location estimate (RAT independent method) by adopting the second location estimate obtained using the RAT dependent method. In one embodiment, the idea is to have a first location estimate (e.g., GNSS location) that can be based on a RAT independent method, and if verified by a second location estimate produced by a reliable RAT dependent method, the network can consider the first RAT independent method (e.g., GNSS) to be a reliable method, and further use the method to improve the location estimate for the corresponding UE or later use the method for emergency services (if needed).

[0162] In one embodiment, the AMF that initiates the positioning procedure also performs the verification procedure. In one embodiment, the AMF that initiates the location reporting procedure may be different from the AMF that performs the verification procedure. In another embodiment, the AMF that initiates the location reporting and verification procedure may be only the serving AMF to the NTN NG-RAN node (based on a single PLMN). In an alternative embodiment, any AMF may initiate the location reporting and verification procedure. In yet another embodiment, different AMFs may initiate separate location reporting requests for different methods in parallel.

[0163] In one embodiment, the AMF initiates the location service procedures for two location estimates with different method types in sequential order, such as Fig.11A . In step 1, after UE registration 1102 is completed and there is no information of UE location during the registration process, AMF 133 initiates (see message delivery 1104) a first location request message (e.g., Nlmf_Location_DetermineLocation) to LMF 141 to request the current location of UE 1101 and estimate this location using a RAT independent method. Therefore, the service operation includes an LCS related identifier, a serving cell identifier of a primary cell in a primary RAN node and a primary cell in a secondary RAN node based on a dual connectivity scenario (when available), and an indication of a location request from a regulatory service client (e.g., emergency services), and may include an indication of whether UE 1101 supports LPP, the required QoS and supported GAD shapes, UE positioning capabilities (if available), and a type of positioning method required for position estimation (e.g., RAT independent method). The indication of the method type may be generic, where LMF 141 selects one of the positioning methods, or may be explicitly specified in the request message (e.g., GNSS).

[0164] In step 2, in one embodiment, based on the indicated method type field, LMF 141 triggers a RAT independent positioning procedure with NTN NG-RAN node 1103 and UE 1101 (see box 1106), where LMF 141 selects a suitable procedure from a list of RAT independent procedures without indicating a specific method, or otherwise adopts a specified method.

[0165] In step 3, in one embodiment, when the current location of the UE is estimated using a RAT independent method, LMF 141 notifies (see messaging 1108) the current location of the UE to AMF 133 via a Nlmf_Location_DetermineLocation response message. In addition to the location estimate, the message also includes the method type used for the location estimate (in the case where the positioning method is not specified in the request message and is not selected by LMF 141), the timestamp and accuracy of the location estimate. Additional information about the UE capabilities related to the adoption of RAT dependent methods (e.g., single satellite or multi-satellite coverage) may also be included in the message. This information may help the network select a suitable RAT dependent method for verification. In this embodiment, AMF 133 assigns a specific RAT independent method type, and if UE 1101 does not have the capability for the method, the response method will indicate to AMF 133 that UE 1101 does not have the capability for the requested positioning method type.

[0166] In step 4, in one embodiment, AMF 133 transmits (see messaging 1110) a second location service request to LMF 141 using an Nlmf_Location_DetermineLocation request message specifying that a RAT-dependent procedure for location estimation of the target UE 1101 is to be used. The request message may contain an indication of the method type and LMF 141 may decide which RAT-dependent positioning method needs to be implemented. LMF 141 may include the parameters discussed in step 1 or specify only the positioning method type. In the absence of additional parameters, LMF 141 may assume that the parameters described in the first step are also valid for the second location service request message.

[0167] In steps 5a and 5b, in one embodiment, LMF 141 initiates a RAT-dependent positioning procedure with the NTN NG-RAN 1103 node and UE 1101. In one embodiment, in step 5a, LMF 141 initiates a positioning procedure (see box 1114) with the serving NTN gNB and possibly neighboring NTN gNBs in NG-RAN 1103 (applicable to both transparent and regenerative payload architectures), e.g., to perform PRS / SRS resource requests to obtain positioning measurements, where the positioning procedure is RAT-dependent. This also applies to single and multiple satellite cases. Examples may include using a network-based positioning method that relies on the NRPPa protocol, e.g., to exchange NTN gNB measurements or the like.

[0168] In step 5b, in one embodiment, LMF 141 initiates a positioning procedure (see block 1116) with UE 1101, for example, via LPP, to exchange NTN capability information, provide NTN assistance data configuration, NTN location measurement configuration, NTN location information report (including location estimation or positioning measurement), and error / abort messages. The mode of location estimation may include a UE-assisted positioning procedure; however, in other implementations, a UE-based positioning procedure for determining the location of the UE is not excluded.

[0169] At step 6, in one embodiment, LMF 141 provides (see messaging 1118) a second location service response to AMF 133 to indicate the RAT-dependent location of target UE 1101 by utilizing an Nlmf_Location_DetermineLocation response message. The message may include the method type and timestamp of the LTE location estimation.

[0170] In step 7, in one embodiment, upon receiving the RAT-dependent position estimate, the AMF 133 compares (see block 1120) the timestamps of the two position estimates to check the reported position delay, since the RAT-dependent method may take longer and the difference between the two position estimates may be above a predefined threshold. In this case, the network may assume that the RAT-independent method is unreliable and not use it further.

[0171] In step 8, in one embodiment, if the delay between the first position estimate and the second position estimate is greater than a predefined threshold, the first position estimation process can be repeated by initiating a third network induction request to LMF 141 (see process 1122), and so on (repeating steps 1 to 3).

[0172] In step 9, in one embodiment, the AMF 133 verifies (see block 1124) the UE location based on predefined criteria and by using the RAT-dependent location estimate. The criteria may include the geographic coordinates of the requested service (e.g., the UE 1101 is in the expected location for the requested service). If successful, no further action may be required. In addition to verifying the UE location, the AMF 133 may also compare the two location estimates from the RAT-dependent method and the RAT-independent method. If the RAT-independent location is within a predefined tolerance of the RAT-dependent location, the AMF 133 may deem the RAT-independent method to be reliable and may further use the method as an independent positioning method for emergency services or for positioning accuracy enhancement.

[0173] In step 10, in one embodiment, if the UE location verification is successful, the UE continues to maintain its connection with the network. Otherwise, if the UE location verification fails, the UE 1101 is deregistered from the network (see process 1126).

[0174] In one embodiment, by using a network-induced location service request message to request both the RAT-independent location and the RAT-dependent location from LMF 141 in a single message (as discussed above in Embodiment 1), the latency in the location estimation and verification process discussed above can be further reduced. Fig.11A Steps 1 and 4 in can be combined, such as Fig. 11B Upon receiving this request message, LMF 141 initiates a RAT-dependent positioning procedure with NTN NG-RAN node 1103 at step 2a (see block 1132) and with UE 1101 at step 2b (see block 1134), and in parallel, may also initiate a RAT-independent positioning procedure, as described above in Fig.11A described in steps 2 and 5 of Fig. 11B Step 3 of box 1136).

[0175] Once position estimates have been calculated for both methods, in one embodiment, LMF 141 may initiate (see messaging 1138) a position response message at step 4 indicating both position estimates (combined Fig.11A 3 and 6 in step 1124). This process also reduces the delay between the two location estimates. In one embodiment, in step 5, the AMF 133 may check (see block 1124) the delay between the two location estimates and once it is within range, the UE location may be verified and the reliability of the RAT independent method may also be checked.

[0176] exist Fig. 11CIn one embodiment shown in FIG. 1 , UE 1101 may first verify the target UE location by first initiating a RAT-dependent location request message to LMF 141, and based on the received location estimate response made by LMF 141, AMF 133 verifies the target UE location based on set criteria (e.g., UE 1101 is in the desired geographic area). If the UE location verification is successful, UE 1101 continues to maintain its connection with the network. If the UE location verification fails, the UE is deregistered from the network. In one embodiment, the process stops here, as shown in FIG. 1 . Fig. 11C Basically, the Fig.11A Steps 4 (messaging 1110), 5 (boxes 1114 and 1116), 6 (messaging 1118), 9 (box 1124) and 10 (process 1126) of , while the signaling remains the same.

[0177] In one embodiment, instead of using a field to indicate the type of method to be adopted (RAT-dependent or RAT-independent), the AMF 133 may use a field to indicate to the LMF 141 that the location estimate is used for positioning verification purposes. In this embodiment, the LMF 141 initiates the positioning procedure based on the RAT-dependent method and specifies the positioning method used for the location estimate of the target UE 1101 in the response message.

[0178] In one example, the AMF 133 may initiate a second location request message for the RAT independent method after having performed location verification (using the RAT dependent method). If the location estimate of the RAT independent method is within a predefined threshold set, the AMF 133 may consider the RAT dependent method as a reliable method (e.g., not spoofed) and may further use the method to enhance positioning accuracy or use the method for emergency or regulatory services in the future.

[0179] According to a fourth embodiment of the LMF-initiated location reporting and verification process after UE registration, LMF 141 receives a request to perform network verification of the UE's location. In this implementation, LMF 141 is responsible for the verification of the UE's location by acting as a consumer of location and performing the verification process. LMF 141 may consider the following options to verify the UE's location:

[0180] RAT-dependent positioning method;

[0181] RAT independent positioning method; and / or

[0182] A hybrid positioning method includes a combination of both a RAT-dependent positioning method and a RAT-independent positioning method.

[0183] like Fig.121201, the AMF 133 transmits (see message 1202) and receives (see message 1206) a verification response, respectively, according to steps 1 and 4. The verification request may include a field for indicating whether the verification is based on the RAT type and number of NTN satellites connected to the UE 1201. The verification response may include a single field as to whether the verification of the UE 1201 is successful or unsuccessful.

[0184] In one embodiment, according to step 3, LMF 141 may combine (see block 1204) results from one or more of the different RAT type positioning methods to verify the accuracy of the UE. This verification may be associated with a validity time or area limit, which may be transmitted with the verification response in step 4.

[0185] Fig.13 A user equipment device 1300 that can be used for UE location verification based on low-latency NTN according to an embodiment of the present disclosure is depicted. In various embodiments, the user equipment device 1300 is used to implement one or more of the above solutions. The user equipment device 1300 may be an embodiment of a UE, such as a remote unit 105 and / or a UE 205 as described above. In addition, the user equipment device 1300 may include a processor 1305, a memory 1310, an input device 1315, an output device 1320, and a transceiver 1325. In some embodiments, the input device 1315 and the output device 1320 are combined into a single device, such as a touch screen. In certain embodiments, the user equipment device 1300 may not include any input device 1315 and / or output device 1320. In various embodiments, the user equipment device 1300 may include one or more of the processor 1305, the memory 1310, and the transceiver 1325, and may not include the input device 1315 and / or the output device 1320.

[0186] As depicted, transceiver 1325 includes at least one transmitter 1330 and at least one receiver 1335. Here, transceiver 1325 communicates with one or more base units 121. Additionally, transceiver 1325 may support at least one network interface 1340 and / or application program interface 1345. Application program interface 1345 may support one or more APIs. Network interface 1340 may support 3GPP reference points such as Uu and PC5. Other network interfaces 1340 may be supported as will be appreciated by one of ordinary skill in the art.

[0187] In one embodiment, the processor 1305 may include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, the processor 1305 may be a microcontroller, a microprocessor, a central processing unit ("CPU"), a graphics processing unit ("GPU"), an auxiliary processing unit, a field programmable gate array ("FPGA"), a digital signal processor ("DSP"), a coprocessor, a special-purpose processor, or a similar programmable controller. In some embodiments, the processor 1305 executes instructions stored in the memory 1310 to perform the methods and routines described herein. The processor 1305 is communicatively coupled to the memory 1310, the input device 1315, the output device 1320, and the transceiver 1325. In certain embodiments, the processor 1305 may include an application processor (also referred to as a "main processor") that manages application domain and operating system ("OS") functions and a baseband processor (also referred to as a "baseband radio processor") that manages radio functions.

[0188] In one embodiment, memory 1310 is a computer-readable storage medium. In some embodiments, memory 1310 includes volatile computer storage media. For example, memory 1310 may include RAM, including dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and / or static RAM ("SRAM"). In some embodiments, memory 1310 includes non-volatile computer storage media. For example, memory 1310 may include a hard drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 1310 includes both volatile and non-volatile computer storage media.

[0189] In some embodiments, memory 1310 stores data related to CSI enhancement for higher frequencies. For example, memory 1310 may store parameters, configurations, resource assignments, policies, and the like as described above. In certain embodiments, memory 1310 also stores program code and related data, such as an operating system or other controller algorithms operating on user equipment device 1300, and one or more software applications.

[0190] In one embodiment, input device 1315 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, and the like. In some embodiments, input device 1315 may be integrated with output device 1320, such as a touch screen or similar touch-sensitive display. In some embodiments, input device 1315 includes a touch screen, so that text can be entered using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, input device 1315 includes two or more different devices, such as a keyboard and a touch panel.

[0191] In one embodiment, the output device 1320 is designed to output visual, auditory, and / or tactile signals. In some embodiments, the output device 1320 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, the output device 1320 may include, but is not limited to, an LCD display, an LED display, an OLED display, a projector, or a similar display device capable of outputting images, text, or the like to a user. As another non-limiting example, the output device 1320 may include a wearable display that is separate from the rest of the user equipment device 1300 but communicatively coupled to the rest of the device, such as a smart watch, smart glasses, a head-up display, or the like. In addition, the output device 1320 may be a component of a smart phone, a personal digital assistant, a television, a tablet computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0192] In some embodiments, output device 1320 includes one or more speakers for producing sounds. For example, output device 1320 can produce an audible alarm or notification (e.g., a beep or buzzer). In some embodiments, output device 1320 includes one or more tactile devices for producing vibration, motion, or other tactile feedback. In some embodiments, all or part of output device 1320 can be integrated with input device 1315. For example, input device 1315 and output device 1320 can form a touch screen or similar touch-sensitive display. In other embodiments, output device 1320 can be positioned near input device 1315.

[0193] The transceiver 1325 includes at least a transmitter 1330 and at least one receiver 1335. The transceiver 1325 may be used to provide UL communication signals to the base unit 121 and receive DL communication signals from the base unit 121, as described herein. Similarly, the transceiver 1325 may be used to transmit and receive SL signals (e.g., V2X communication), as described herein. Although only one transmitter 1330 and one receiver 1335 are illustrated, the user equipment device 1300 may have any suitable number of transmitters 1330 and receivers 1335. In addition, the transmitter 1330 and the receiver 1335 may be any suitable type of transmitter and receiver. In one embodiment, the transceiver 1325 includes a first transmitter / receiver pair for communicating with a mobile communication network via a licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network via an unlicensed radio spectrum.

[0194] In some embodiments, a first transmitter / receiver pair for communicating with a mobile communication network via a licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network via an unlicensed radio spectrum may be combined into a single transceiver unit, such as a single chip that performs functions for use with both licensed and unlicensed radio spectrum. In some embodiments, the first transmitter / receiver pair and the second transmitter / receiver pair may share one or more hardware components. For example, some transceivers 1325, transmitters 1330, and receivers 1335 may be implemented as physically separate components that access shared hardware resources and / or software resources, such as a network interface 1340.

[0195] In various embodiments, one or more transmitters 1330 and / or one or more receivers 1335 may be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, a system on a chip, an ASIC, or other type of hardware component. In certain embodiments, one or more transmitters 1330 and / or one or more receivers 1335 may be implemented and / or integrated into a multi-chip module. In some embodiments, other components such as a network interface 1340 or other hardware components / circuits may be integrated into a single chip along with any number of transmitters 1330 and / or receivers 1335. In this embodiment, the transmitters 1330 and receivers 1335 may be logically configured as transceivers 1325 using one or more common control signals, or may be modular transmitters 1330 and receivers 1335 implemented in the same hardware chip or in a multi-chip module.

[0196] Fig.14 An embodiment of a network device 1400 that can be used for low-latency NTN-based UE location verification according to an embodiment of the present disclosure is depicted. In one embodiment, the network device 1400 may be an embodiment of a RAN node and its supporting hardware, such as a base unit 121 and / or a gNB as described above. In addition, the network device 1400 may include a processor 1405, a memory 1410, an input device 1415, an output device 1420, and a transceiver 1425. In some embodiments, the network device 1400 does not include any input device 1415 and / or output device 1420.

[0197] As depicted, the transceiver 1425 includes at least one transmitter 1430 and at least one receiver 1435. Herein, the transceiver 1425 communicates with one or more remote units 105. In addition, the transceiver 1425 can support at least one network interface 1440 and / or an application program interface 1445. The application program interface 1445 can support one or more APIs. The network interface 1440 can support 3GPP reference points, such as Uu, N1, N2, N3, N5, N6, and / or N7 interfaces. As understood by one of ordinary skill in the art, other network interfaces 1440 can be supported.

[0198] In one embodiment, the processor 1405 may include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, the processor 1405 may be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), a digital signal processor (“DSP”), a coprocessor, a dedicated processor, or a similar programmable controller. In some embodiments, the processor 1405 executes instructions stored in the memory 1410 to perform the methods and routines described herein. The processor 1405 is communicatively coupled to the memory 1410, the input device 1415, the output device 1420, and the transceiver 1425. In certain embodiments, the processor 1405 may include an application processor (also referred to as a “main processor”) that manages application domain and operating system (“OS”) functions and a baseband processor (also referred to as a “baseband radio processor”) that manages radio functions. In various embodiments, the processor 1405 controls the network device 1400 to implement the network entity behaviors (e.g., of the gNB) described above for UE location verification based on low-latency NTN.

[0199] In one embodiment, memory 1410 is a computer-readable storage medium. In some embodiments, memory 1410 includes volatile computer storage media. For example, memory 1410 may include RAM, including dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and / or static RAM ("SRAM"). In some embodiments, memory 1410 includes non-volatile computer storage media. For example, memory 1410 may include a hard drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 1410 includes both volatile and non-volatile computer storage media.

[0200] In some embodiments, memory 1410 stores data related to CSI enhancement for higher frequencies. For example, memory 1410 may store parameters, configurations, resource assignments, policies, and the like as described above. In certain embodiments, memory 1410 also stores program code and related data, such as an operating system ("OS") or other controller algorithms operating on network device 1400, and one or more software applications.

[0201] In one embodiment, input device 1415 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, and the like. In some embodiments, input device 1415 may be integrated with output device 1420, such as a touch screen or similar touch-sensitive display. In some embodiments, input device 1415 includes a touch screen, so that text can be entered using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, input device 1415 includes two or more different devices, such as a keyboard and a touch panel.

[0202] In one embodiment, output device 1420 may include any known electronically controllable display or display device. Output device 1420 may be designed to output visual, auditory, and / or tactile signals. In some embodiments, output device 1420 includes an electronic display capable of outputting visual data to a user. In addition, output device 1420 may be a component of a smart phone, a personal digital assistant, a television, a tablet computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, etc.

[0203] In some embodiments, output device 1420 includes one or more speakers for producing sounds. For example, output device 1420 may produce an audible alarm or notification (e.g., a beep or buzzer). In some embodiments, output device 1420 includes one or more tactile devices for producing vibration, motion, or other tactile feedback. In some embodiments, all or part of output device 1420 may be integrated with input device 1415. For example, input device 1415 and output device 1420 may form a touch screen or similar touch-sensitive display. In other embodiments, all or part of output device 1420 may be positioned near input device 1415.

[0204] As discussed above, the transceiver 1425 may communicate with one or more remote units and / or with one or more interworking functions that provide access to one or more PLMNs. The transceiver 1425 may also communicate with one or more network functions (e.g., in the mobile core network 80). The transceiver 1425 operates under the control of the processor 1405 to transmit messages, data, and other signals, and also receive messages, data, and other signals. For example, the processor 1405 may selectively activate the transceiver (or portions thereof) at specific times in order to send and receive messages.

[0205] The transceiver 1425 may include one or more transmitters 1430 and one or more receivers 1435. In some embodiments, the one or more transmitters 1430 and / or the one or more receivers 1435 may share transceiver hardware and / or circuitry. For example, the one or more transmitters 1430 and / or the one or more receivers 1435 may share antennas, antenna tuners, amplifiers, filters, oscillators, mixers, modulators / demodulators, power supplies, and the like. In one embodiment, the transceiver 1425 implements multiple logical transceivers using different communication protocols or protocol stacks while using common physical hardware.

[0206] In one embodiment, the processor 1405 transmits a low-latency UE location request including a positioning configuration to a second network entity having location server functionality via the transceiver 1425, wherein the positioning configuration includes at least a request to provide the location information of the UE within a configured time window, receives a location information response from the second network entity via the transceiver 1425 based on the transmitted location request, and performs a low-latency verification process for the location information of the UE based on the received location response.

[0207] In one embodiment, the first network entity comprises an AMF and the second network entity comprises a NG-RAN node equipped with an LMC.

[0208] In one embodiment, processor 1405 transmits a UE location verification request to a NG-RAN node via transceiver 1425 .

[0209] In one embodiment, the processor 1405 transmits a location request configuration to the NG-RAN node via the transceiver 1425, the location request configuration comprising a request for the UE location based on the configured positioning method type.

[0210] In one embodiment, the processor 1405 invokes a location service operation through the LMF, the location service operation comprising a location request based on a single configured positioning method type.

[0211] In one embodiment, the configured positioning method type consists of a RAT-dependent method, a RAT-independent method, or a combination thereof.

[0212] In one embodiment, the processor 1405 invokes a location service operation through the LMF, the location service operation including a plurality of location requests corresponding to a plurality of configured positioning method types.

[0213] In one embodiment, processor 1405 generates a location report based on a low latency verification process, the location report including multiple location estimates corresponding to multiple method types.

[0214] In one embodiment, the processor 1405 transmits a first positioning configuration request to a location server via the transceiver 1425 based on the positioning configuration, wherein the first positioning configuration includes a first estimate of the position of the UE using a first positioning method type, transmits a second positioning configuration request to the location server, wherein the second positioning configuration includes a second estimate of the position of the UE using a second positioning method type, receives a location response to the first configuration and the second configuration from the location server, performs a verification process based on the location response of the first configuration, the second configuration or a combination thereof, and performs a verification process of the positioning method type.

[0215] In one embodiment, processor 1405 initiates two location request messages to the LMF for determining the location estimate of the UE using a RAT independent method and a RAT dependent method in a sequential manner.

[0216] In one embodiment, the processor 1405 initiates a location request message LMF for determining a location estimate of the UE using a RAT independent method and a RAT dependent method.

[0217] In one embodiment, if the delay between two position estimates exceeds a predefined threshold, processor 1405 repeats the position estimation process.

[0218] In one embodiment, the processor 1405 receives a low-latency UE location verification request including a positioning configuration from a second network entity via the transceiver 1425, wherein the positioning configuration includes at least a request to provide the location information of the UE within a configured time window, performs a low-latency verification process for the location information of the UE, and transmits a location information response to the second network entity via the transceiver 1425 based on the transmitted verification request.

[0219] Fig.151 is a flow chart of a method 1500 for low-latency NTN-based UE location verification. The method 1500 may be performed by a network entity as described herein (e.g., a gNB, a base station 121, a network function (e.g., an AMF or LMF), and / or a network equipment device 1400). In some embodiments, the method 1500 may be performed by a processor (e.g., a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, or the like) that executes program code.

[0220] In one embodiment, method 1500 starts and transmits 1505 a low-latency UE location request including a positioning configuration to a second network entity having location server functionality. In one embodiment, method 1500 receives 1510 a location information response from the second network entity based on the transmitted location request. In one embodiment, method 1500 performs 1515 a low-latency verification procedure of the UE's location information based on the received location response, and method 1500 ends.

[0221] Fig.16 1 is a flow chart of a method 1600 for low-latency NTN-based UE location verification. The method 1600 may be performed by a network entity as described herein (e.g., a gNB, a base station 121, a network function (e.g., an AMF or LMF), and / or a network equipment device 1400). In some embodiments, the method 1600 may be performed by a processor (e.g., a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, or the like) that executes program code.

[0222] In one embodiment, method 1600 starts and receives 1605 a low-latency UE location verification request including a positioning configuration from a second network entity. In one embodiment, method 1600 performs a low-latency verification process of the UE's location information. In one embodiment, method 1600 transmits 1615 a location information response to the second network entity based on the transmitted verification request, and method 1600 ends.

[0223] A first device for UE location verification based on low-latency NTN is disclosed. The first device may include a network entity as described herein, such as a gNB, a base station 121, a network function (e.g., an AMF or LMF) and / or a network equipment device 1400. In some embodiments, the first device includes a processor that executes program code, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, or the like.

[0224] In one embodiment, a first device includes a transceiver and a processor coupled to the transceiver. In one embodiment, the processor is configured to cause the device to transmit a low-latency UE location request including a positioning configuration to a second network entity having location server functionality, the positioning configuration including at least a request to provide location information of the UE within a configured time window, receive a location information response from the second network entity based on the transmitted location request, and perform a low-latency verification procedure of the location information of the UE based on the received location response.

[0225] In one embodiment, the first network entity comprises an AMF and the second network entity comprises a NG-RAN node equipped with an LMC.

[0226] In one embodiment, the processor is configured to cause the apparatus to transmit a UE location verification request to a NG-RAN node.

[0227] In one embodiment, the processor is configured to cause the apparatus to transmit a location request configuration to a NG-RAN node, the location request configuration comprising a request for the UE location based on the configured positioning method type.

[0228] In one embodiment, the processor is configured to cause the device to invoke a location service operation through the LMF, the location service operation comprising a location request based on a single configured positioning method type.

[0229] In one embodiment, the configured positioning method type consists of a RAT-dependent method, a RAT-independent method, or a combination thereof.

[0230] In one embodiment, the processor is configured to cause the device to invoke a location service operation through the LMF, the location service operation comprising a plurality of location requests corresponding to a plurality of configured positioning method types.

[0231] In one embodiment, the processor is configured to cause the apparatus to generate a position report based on a low latency validation process, the position report comprising a plurality of position estimates corresponding to a plurality of method types.

[0232] In one embodiment, the processor is configured to cause the device to transmit a first positioning configuration request to a location server based on a positioning configuration, the first positioning configuration including a first estimate of the location of the UE using a first positioning method type, transmit a second positioning configuration request to the location server, the second positioning configuration including a second estimate of the location of the UE using a second positioning method type, receive a location response to the first configuration and the second configuration from the location server, perform a verification process based on the location response of the first configuration, the second configuration, or a combination thereof, and perform a verification process of the positioning method type.

[0233] In one embodiment, the processor is configured to cause the apparatus to initiate two location request messages to the LMF for determining a location estimate of the UE using a RAT independent method and a RAT dependent method in a sequential manner.

[0234] In one embodiment, the processor is configured to cause the apparatus to initiate a location request message LMF for determining a location estimate of the UE using a RAT independent method and a RAT dependent method.

[0235] In one embodiment, the processor is configured to cause the apparatus to repeat the position estimation process if a delay between two position estimates exceeds a predefined threshold.

[0236] A first method of a first network entity device for UE location verification based on low-latency NTN is disclosed. The first method may be performed by a network entity as described herein (e.g., gNB, base station 121, network function (e.g., AMF or LMF) and / or network equipment device 1400). In some embodiments, the first method may be performed by a processor (e.g., a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, or the like) that executes a program code.

[0237] In one embodiment, a first method transmits a low-latency UE location request including a positioning configuration to a second network entity having location server functionality, wherein the positioning configuration includes at least a request to provide location information of the UE within a configured time window, receives a location information response from the second network entity based on the transmitted location request, and performs a low-latency verification process for the location information of the UE based on the received location response.

[0238] In one embodiment, the first network entity comprises an AMF and the second network entity comprises a NG-RAN node equipped with an LMC.

[0239] In one embodiment, a first method transmits a UE location verification request to a NG-RAN node.

[0240] In one embodiment, a first method transmits a location request configuration to a NG-RAN node, the location request configuration comprising a request for the UE location based on a configured positioning method type.

[0241] In one embodiment, the first method invokes a location service operation through the LMF, the location service operation comprising a location request based on a single configured positioning method type.

[0242] In one embodiment, the configured positioning method type consists of a RAT-dependent method, a RAT-independent method, or a combination thereof.

[0243] In one embodiment, the first method invokes a location service operation through the LMF, the location service operation including a plurality of location requests corresponding to a plurality of configured positioning method types.

[0244] In one embodiment, a first method generates a location report based on a low-latency verification process, the location report including a plurality of location estimates corresponding to a plurality of method types.

[0245] In one embodiment, the first method transmits a first positioning configuration request to a location server based on a positioning configuration, the first positioning configuration including a first estimate of the location of the UE using a first positioning method type, transmits a second positioning configuration request to the location server, the second positioning configuration including a second estimate of the location of the UE using a second positioning method type, receives a location response to the first configuration and the second configuration from the location server, performs a verification process based on the location response of the first configuration, the second configuration or a combination thereof, and performs a verification process of the positioning method type.

[0246] In one embodiment, a first method initiates two location request messages to the LMF for determining a location estimate of the UE using a RAT independent method and a RAT dependent method in a sequential manner.

[0247] In one embodiment, a first method initiates a location request message LMF for determining a location estimate of the UE using a RAT independent method and a RAT dependent method.

[0248] In one embodiment, the first method repeats the position estimation process if the delay between two position estimates exceeds a predefined threshold.

[0249] A second device for UE location verification based on low-latency NTN is disclosed. The second device may include a network entity as described herein, such as a gNB, a base station 121, a network function (e.g., an AMF or LMF) and / or a network equipment device 1400. In some embodiments, the second device includes a processor that executes program code, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, or the like.

[0250] In one embodiment, the second device comprises a transceiver and a processor coupled to the transceiver. In one embodiment, the processor is configured to cause the device to receive a low-latency UE location verification request including a positioning configuration from a second network entity, the positioning configuration including at least a request to provide location information of the UE within a configured time window, perform a low-latency verification process for the location information of the UE, and transmit a location information response to the second network entity based on the transmitted verification request.

[0251] A second method for UE location verification based on low-latency NTN is disclosed. The second method may be performed by a network entity as described herein (e.g., a gNB, a base station 121, a network function (e.g., an AMF or LMF), and / or a network equipment device 1400). In some embodiments, the second method may be performed by a processor (e.g., a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, an FPGA, or the like) that executes a program code.

[0252] In one embodiment, the second method receives a low-latency UE location verification request including a positioning configuration from a second network entity, wherein the positioning configuration includes at least a request to provide the location information of the UE within a configured time window, performs a low-latency verification process for the location information of the UE, and transmits a location information response to the second network entity based on the transmitted verification request.

[0253] Embodiments may be practiced in other specific forms. The described embodiments should be considered in all respects as illustrative and non-restrictive only. Therefore, the scope of the present disclosure is indicated by the appended claims rather than the foregoing description. All changes within the meaning and equivalent range of the claims should be included within the scope of the claims.

Claims

1. A first network entity device, comprising: Transceiver; and a processor coupled to the transceiver, the processor configured to cause the apparatus to: transmitting a low-latency user equipment (UE) location request including a positioning configuration to a second network entity having a location server function, the positioning configuration including at least a request to provide location information of the UE within a configured time window; receiving a location information response from the second network entity based on the transmitted location request; and A low-latency verification procedure of the UE's location information is performed based on the received location response.

2. The apparatus according to claim 1, wherein the first network entity comprises an access and mobility management function (AMF), and the second network entity comprises a new generation radio access network (NG-RAN) node equipped with a location management component (LMC).

3. The apparatus of claim 2, wherein the processor is configured to cause the apparatus to transmit a UE location verification request to the NG-RAN node.

4. The apparatus of claim 2, wherein the processor is configured to cause the apparatus to transmit a location request configuration to the NG-RAN node, the location request configuration comprising a request for a UE location based on a configured positioning method type.

5. A device according to any preceding claim, wherein the processor is configured to cause the device to invoke a location service operation through a location management function (LMF), the location service operation comprising a location request based on a single configured positioning method type.

6. The apparatus of any preceding claim, wherein the configured positioning method type consists of a Radio Access Technology (RAT) dependent method, a RAT independent method, or a combination thereof.

7. An apparatus according to any preceding claim, wherein the processor is configured to cause the apparatus to invoke a location service operation through a location management function (LMF), the location service operation comprising a plurality of location requests corresponding to a plurality of configured positioning method types.

8. An apparatus according to any preceding claim, wherein the processor is configured to cause the apparatus to generate a position report based on a low latency validation process, the position report comprising a plurality of position estimates corresponding to a plurality of method types.

9. An apparatus according to any preceding claim, wherein the processor is configured to cause the apparatus to: transmitting a first positioning configuration request to the location server, the first positioning configuration comprising a first estimate of the position of the UE using a first positioning method type; transmitting a second positioning configuration request to the location server, the second positioning configuration comprising a second estimate of the position of the UE using a second positioning method type; receiving, from the location server, a location response to the first configuration and the second configuration; performing a verification process based on the position response of the first configuration, the second configuration, or a combination thereof; and Perform the verification process for the positioning method type.

10. The apparatus of claim 9, wherein the processor is configured to cause the apparatus to initiate two location request messages to a location management function (LMF) for determining a location estimate of the UE using a Radio Access Technology (RAT) independent method and a RAT dependent method in a sequential manner.

11. The apparatus according to claim 9 or 10, wherein the processor is configured to cause the apparatus to initiate a location request message location management function (LMF) for determining a location estimate of the UE using a radio access technology (RAT) independent method and a RAT dependent method.

12. An apparatus as claimed in any preceding claim, wherein the processor is configured to cause the apparatus to repeat a position estimation process if a delay between two position estimates exceeds a predefined threshold.

13. A method of a first network entity device, comprising: transmitting a low-latency user equipment (UE) location request including a positioning configuration to a second network entity having a location server function, the positioning configuration including at least a request to provide location information of the UE within a configured time window; receiving a location information response from the second network entity based on the transmitted request; and A low-latency verification process of the UE's location information is performed based on the location response.

14. The method of claim 13, wherein the first network entity comprises an Access and Mobility Management Function (AMF), and the second network entity comprises a Next Generation Radio Access Network (NG-RAN) node equipped with a Location Management Component (LMC).

15. A network entity device, comprising: Transceiver; and a processor coupled to the transceiver, the processor configured to cause the apparatus to: receiving, from a second network entity, a low-latency user equipment (UE) location verification request including a location configuration, the location configuration including at least a request to provide location information of the UE within a configured time window; Performing a low-latency verification process for the location information of the UE; and A location information response is transmitted to the second network entity based on the transmitted verification request.

Images