Mapping application and location service profile

Abstract

To provide mapping applications and location service profiles.SOLUTION: A method includes configuring location service profiles. Each location service profile includes a positioning method, a service quality parameter, mapping to a location service producer, an application service type, and / or a service area type. The method includes receiving a location request from a location service consumer, and determining a first mapping of an application to a first location service profile of the location service profiles based on the location request. The method includes transmitting the first mapping and the first location service profile to the location service producer, and determining a fused location estimation for the first location service profile.SELECTED DRAWING: Figure 9

Description

[Technical Field]

[0001] The subject matter disclosed herein relates generally to wireless communications, and more particularly to mapping application and location service profiles. [Background technology]

[0002] In certain wireless communication networks, location service profiles may be used to support location services, which may not function properly if not properly configured. Summary of the Invention [Means for solving the problem]

[0003] A method for mapping applications and location service profiles is disclosed. Apparatuses and systems also perform the functions of the method. One embodiment of the method in a location services enabler includes configuring a plurality of location service profiles. Each location service profile of the plurality of location service profiles includes at least one positioning method, at least one quality of service parameter, at least one mapping to at least one location service producer, at least one application service type, at least one service area type, or a combination thereof. In some embodiments, the method includes receiving a location request from a location service consumer. In particular embodiments, the method includes determining a first mapping of at least one application of at least one user equipment to a first location service profile of the plurality of location service profiles based on the location request. In various embodiments, the method includes transmitting the first mapping and the first location service profile to at least one location service producer. In some embodiments, the method includes determining a fused location estimate for the first location service profile.

[0004] An apparatus for mapping applications and location service profiles includes a location services enabler. In some embodiments, the apparatus includes a processor that configures a plurality of location service profiles. Each location service profile of the plurality of location service profiles includes at least one positioning method, at least one quality of service parameter, at least one mapping to at least one location service producer, at least one application service type, at least one service area type, or a combination thereof. In various embodiments, the apparatus includes a receiver that receives a location request from a location service consumer. The processor determines a first mapping of at least one application of at least one user equipment to a first location service profile of the plurality of location service profiles based on the location request. In some embodiments, the apparatus includes a transmitter that transmits the first mapping and the first location service profile to the at least one location service producer. In a particular embodiment, the processor determines a fused location estimate for the first location service profile.

[0005] A more particular description of the embodiments briefly described above will be given by reference to specific embodiments that are illustrated in the accompanying drawings. The embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings, with the understanding that these drawings illustrate only some embodiments and therefore should not be considered limiting in scope. [Brief explanation of the drawings]

[0006] [Figure 1] 1 is a schematic block diagram illustrating one embodiment of a wireless communication system for mapping application and location service profiles. [Figure 2]FIG. 1 is a schematic block diagram illustrating one embodiment of an apparatus that may be used to map application and location service profiles. [Figure 3] FIG. 1 is a schematic block diagram illustrating one embodiment of an apparatus that may be used to map application and location service profiles. [Figure 4] FIG. 1 is a block diagram illustrating one embodiment of a system for mapping applications to LCS profiles. [Figure 5] FIG. 1 is a block diagram illustrating another embodiment of a system for mapping applications to LCS profiles. [Figure 6] FIG. 1 is a flowchart diagram illustrating one embodiment of a method for requirements validation. [Figure 7] FIG. 10 is a block diagram illustrating a further embodiment of a system for mapping applications to LCS profiles. [Figure 8] FIG. 1 is a block diagram illustrating another embodiment of a system for mapping applications to LCS profiles. [Figure 9] FIG. 1 is a flow chart diagram illustrating one embodiment of a method for mapping application and location service profiles. DETAILED DESCRIPTION OF THE INVENTION

[0007] As will be appreciated by those skilled in the art, aspects of the embodiments may be embodied as a system, apparatus, method, or program product. Accordingly, 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, all of which may be referred to generally herein as a "circuit," "module," or "system." Furthermore, the embodiments may take the form of a program product embodied in one or more computer-readable storage devices that store machine-readable code, computer-readable code, and / or program code, hereinafter referred to as code. The storage devices may be tangible, non-transitory, and / or non-transmittable. The storage devices may not embody signals. In certain embodiments, the storage devices merely use signals to access the code.

[0008] Some of the functional units described herein may be labeled as modules to more fully emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very large scale integrated ("VLSI") circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, etc.

[0009] Modules may also be implemented in code and / or software for execution by various types of processors. For example, an identified module of code may include one or more physical or logical blocks of executable code that may be organized, for example, as an object, procedure, or function. Nevertheless, the executable files of identified modules need not be physically located together, but may include different instructions stored in different locations that, when logically combined, comprise that module and achieve the purpose stated for that module.

[0010] In practice, a module of code may be a single instruction or many instructions, and may even be distributed across several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and depicted herein in modules and may be embodied in any suitable form and organized within any suitable type of data structure. Operational data may be collected as a single data set or may be distributed across different locations, including across different computer-readable storage devices. When a module or portions of a module are implemented in software, the software portions are stored on one or more computer-readable storage devices.

[0011] Any combination of one or more computer-readable mediums may be utilized. The computer-readable medium may be a computer-readable storage medium. The computer-readable storage medium may be a storage device that stores code. The storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micro-mechanical, or semiconductor system, apparatus, or device, or any suitable combination of the above.

[0012] More specific examples (non-exhaustive list) of storage devices include the following: an electrical connection having one or more wires, 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 disc read-only memory ("CD-ROM"), an optical storage device, a magnetic storage device, or any suitable combination of the above. 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 connection with an instruction execution system, apparatus, or device.

[0013] The code for performing operations for 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 ​​such as Python, Ruby, Java, Smalltalk, C++, and traditional procedural programming languages ​​such as the "C" programming language, and / or machine languages ​​such as assembly language. The code may run entirely on the user's computer, partially on the user's computer, as a standalone 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 through any type of network, including a local area network ("LAN") or a wide area network ("WAN"), or the connection to the external computer may be made (e.g., through the Internet using an Internet Service Provider).

[0014] References throughout this specification to "one embodiment," "an embodiment," or similar phrases mean that a particular feature, structure, or characteristic described with respect to an embodiment is included in at least one embodiment. Thus, all appearances of the phrases "in one embodiment," "in an embodiment," and similar phrases throughout this specification may, but do not necessarily, refer to the same embodiment, but mean "one or more, but not all, embodiments" unless otherwise specified. The words "including," "comprising," and "having," and variations thereof, mean "including, but not limited to," unless otherwise specified. An enumerated list of items does not imply that any or all of the items are mutually exclusive unless otherwise specified. The terms "a," "an," and "the" also refer to "one or more," unless otherwise specified.

[0015] Furthermore, the described features, structures, or characteristics of the embodiments may be combined in any suitable manner. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, and hardware chips, to provide a thorough understanding of the embodiments. However, those skilled in the art will recognize that the embodiments can be practiced without one or more of the specific details or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of an embodiment.

[0016] Aspects of the embodiments are described below with reference to schematic flowchart illustrations and / or schematic block diagrams of methods, apparatus, systems, and program products according to the embodiments. It will be understood that each block of the schematic flowchart illustrations and / or schematic block diagrams, and combinations of blocks in the schematic flowchart illustrations and / or schematic block diagrams, may be implemented by code. The code may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the schematic flowchart illustrations and / or schematic block diagrams.

[0017] The code may also be stored in a storage device that can instruct a computer, other programmable data processing apparatus, or other device to function in a particular manner, such that the instructions stored on the storage device produce an article of manufacture that includes instructions that implement the functions / acts specified in one or more blocks of the schematic flowchart diagrams and / or schematic block diagrams.

[0018] The code may also be loaded into a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to generate a computer-implemented process, such that the code running on the computer or other programmable apparatus provides a process for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0019] The schematic flowchart diagrams and / or schematic block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods, and program products according to various embodiments. In this regard, each block in the schematic flowchart diagrams and / or schematic block diagrams may represent a module, segment, or portion of code that includes one or more executable instructions of code for implementing the specified logical function(s).

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

[0021] Various arrow and line types may be used in the flowchart and / or block diagrams, but these are understood not to limit the scope of the corresponding embodiments. Indeed, some arrows or other connectors may be used only to indicate the logical flow of the illustrated embodiments. For example, arrows may indicate wait or monitoring periods of unspecified duration between enumerated steps of the illustrated embodiments. It should also be noted that each block of the block and / or flowchart diagrams, and combinations of blocks in the block and / or flowchart diagrams, may be implemented by dedicated hardware-based systems that perform the specified functions or acts, or a combination of dedicated hardware and code.

[0022] The description of an element in each figure may refer to the element in the preceding figure. Like numbers refer to like elements in all figures, including alternative embodiments of like elements.

[0023] 1 illustrates one embodiment of a wireless communication system 100 for mapping application and location service profiles. In one embodiment, the wireless communication system 100 includes a remote unit 102 and a network unit 104. Those skilled in the art will recognize that although a particular number of remote units 102 and network units 104 are illustrated in FIG. 1, any number of remote units 102 and network units 104 may be included in the wireless communication system 100.

[0024] In one embodiment, the remote units 102 may include computing devices such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smartphones, smart televisions (e.g., Internet-connected televisions), set-top boxes, game consoles, security systems (including security cameras), vehicle-mounted computers, network devices (e.g., routers, switches, modems), aircraft, drones, etc. In some embodiments, the remote units 102 include wearable devices such as smart watches, fitness bands, optical head-mounted displays, etc. Furthermore, the remote units 102 may be referred to as subscriber units, mobiles, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, UEs, user terminals, devices, or other terms used in the art. The remote units 102 may communicate directly with one or more of the network units 104 via UL communication signals. In particular embodiments, the remote units 102 may communicate directly with other remote units 102 via sidelink communication.

[0025] The network units 104 may be distributed across a geographic region. In particular embodiments, the network units 104 may include access points, access terminals, base stations, location servers, core networks ("CN"), radio network entities, Node Bs, evolved Node Bs ("eNB"), 5G Node Bs ("gNB"), home Node Bs, relay nodes, devices, core networks, air servers, radio access nodes, access points ("AP"), new radios ("NR"), network entities, access and mobility management functions ("AMF"), unified data management ("UDM"), unified data repository ("UDR"), UDM / UDR, policy control functions ("PCF"), radio access networks ("RAN"), network slice selection functions ("NSSF"), operations, administration, and management functions. The network unit 104 may also be referred to as and / or include one or more of: Operation and Administration Management Function ("OAM"), Session Management Function ("SMF"), User Plane Function ("UPF"), Application Function, Authentication Server Function ("AUSF"), Security Anchor Function ("SEAF"), Trusted Non-3GPP Gateway Function ("TNGF"), Application Function, Service Enabler Architecture Layer (SEAL) Function, Vertical Application Enabler Server, Edge Enabler Server, Edge Configuration Server, Mobile Edge Computing Platform Function, Mobile Edge Computing Application, Middleware Entity, Location Enabler Server, Location Server, or by any other terminology used in the art. The network unit 104 is typically part of a radio access network that includes one or more controllers communicatively coupled to one or more corresponding network units 104. The radio access network is typically communicatively coupled to one or more core networks, which may be coupled to other networks such as the Internet and the Public Switched Telephone Network, among other networks.These and other elements of the radio access network and core network are not shown but are generally well known by those skilled in the art.

[0026] In one implementation, the wireless communication system 100 conforms to the NR protocol standardized in the 3rd Generation Partnership Project (“3GPP®”), in which the network unit 104 transmits using an OFDM modulation scheme on the downlink (“DL”) and the remote unit 102 transmits using a Single Carrier Frequency Division Multiple Access (“SC-FDMA”) scheme or an Orthogonal Frequency Division Multiplexing (“OFDM”) scheme on the uplink (“UL”). More generally, however, the wireless communication system 100 may implement any other open or proprietary communication protocol, such as WiMAX, Institute of Electrical and Electronics Engineers ("IEEE") 802.11 variants, Global System for Mobile Communications ("GSM"), General Packet Radio Service ("GPRS"), Universal Mobile Telecommunications System ("UMTS"), Long Term Evolution ("LTE") variants, Code Division Multiple Access 2000 ("CDMA2000"), Bluetooth, ZigBee, Sigfox, among others. This disclosure is not intended to be limited to any particular wireless communication system architecture or protocol implementation.

[0027] The network unit 104 may serve several remote units 102 within a serving area, e.g., a cell or a cell sector, via a wireless communication link. The network unit 104 transmits DL communication signals to serve the remote units 102 in the time domain, the frequency domain, and / or the spatial domain.

[0028] In particular embodiments, the network unit 104 may configure multiple location service profiles. Each location service profile of the multiple location service profiles includes at least one positioning method, at least one quality of service parameter, at least one mapping to at least one location service producer, at least one application service type, at least one service area type, or a combination thereof. In some embodiments, the network unit 104 may receive a location request from a location service consumer. In particular embodiments, the network unit 104 may determine a first mapping of at least one application of at least one user equipment to a first location service profile of the multiple location service profiles based on the location request. In various embodiments, the network unit 104 may transmit the first mapping and the first location service profile to the at least one location service producer. In some embodiments, the network unit 104 may determine a fused location estimate for the first location service profile. Thus, the network unit 104 may be used to map applications and location service profiles.

[0029] 2 illustrates one embodiment of an apparatus 200 that may be used to map application and location service profiles. The apparatus 200 includes one embodiment of the remote unit 102. Additionally, the remote unit 102 may include a processor 202, a memory 204, an input device 206, a display 208, a transmitter 210, and a receiver 212. In some embodiments, the input device 206 and the display 208 are combined in a single device, such as a touchscreen. In particular embodiments, the remote unit 102 may not include any input device 206 and / or display 208. In various embodiments, the remote unit 102 may include one or more of the processor 202, the memory 204, the transmitter 210, and the receiver 212, and may not include the input device 206 and / or the display 208.

[0030] The processor 202, in one embodiment, may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, the processor 202 may be a microcontroller, microprocessor, central processing unit (“CPU”), graphics processing unit (“GPU”), auxiliary processing unit, field programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, the processor 202 executes instructions stored in the memory 204 to implement the methods and routines described herein. The processor 202 is communicatively coupled to the memory 204, the input device 206, the display 208, the transmitter 210, and the receiver 212.

[0031] Memory 204, in one embodiment, is a computer-readable storage medium. In some embodiments, memory 204 includes a volatile computer storage medium. For example, memory 204 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, memory 204 includes a non-volatile computer storage medium. For example, memory 204 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 204 includes both volatile and non-volatile computer storage media. In some embodiments, memory 204 also stores program code and associated data, such as an operating system or other controller algorithms running on remote unit 102.

[0032] The input device 206, in one embodiment, may include any known computer input device, including a touch panel, buttons, a keyboard, a stylus, a microphone, etc. In some embodiments, the input device 206 may be integrated with the display 208, for example, as a touch screen or similar touch-sensitive display. In some embodiments, the input device 206 includes a touch screen such that text may be entered using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, the input device 206 includes two or more different devices, such as a keyboard and a touch panel.

[0033] Display 208, in one embodiment, may include any known electronically controllable display or display device. Display 208 may be designed to output visual, audible, and / or tactile signals. In some embodiments, display 208 includes an electronic display capable of outputting visual data to a user. For example, display 208 may include, but is not limited to, a liquid crystal display ("LCD"), a light-emitting diode ("LED") display, an organic light-emitting diode ("OLED") display, a projector, or similar display device capable of outputting images, text, and the like to a user. As another non-limiting example, display 208 may include a wearable display such as a smartwatch, smart glasses, a head-up display, and the like. Furthermore, display 208 may be a component of a smartphone, a personal digital assistant, a television, a tablet computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, and the like.

[0034] In certain embodiments, the display 208 includes one or more speakers for generating sound. For example, the display 208 may generate audible alerts or notifications (e.g., beeps or chimes). In some embodiments, the display 208 includes one or more haptic devices for generating vibrations, movements, or other haptic feedback. In some embodiments, all or a portion of the display 208 may be integrated with the input device 206. For example, the input device 206 and the display 208 may form a touchscreen or similar touch-sensitive display. In other embodiments, the display 208 may be located near the input device 206.

[0035] Although only one transmitter 210 and one receiver 212 are shown, the remote unit 102 may have any suitable number of transmitters 210 and receivers 212. The transmitter 210 and receiver 212 may be any suitable type of transmitter and receiver. In one embodiment, the transmitter 210 and receiver 212 may be part of a transceiver.

[0036] 3 illustrates one embodiment of an apparatus 300 that may be used to map application and location service profiles. The apparatus 300 includes one embodiment of the network unit 104. Furthermore, the network unit 104 may include a processor 302, a memory 304, an input device 306, a display 308, a transmitter 310, a receiver 312, a network interface 314 (e.g., for communicating with network devices), and an application interface 316 (e.g., for communicating with applications). As can be appreciated, the processor 302, the memory 304, the input device 306, the display 308, the transmitter 310, and the receiver 312 may be substantially similar to the processor 202, the memory 204, the input device 206, the display 208, the transmitter 210, and the receiver 212 of the remote unit 102, respectively.

[0037] In a particular embodiment, the processor 302 configures a plurality of location service profiles. Each location service profile of the plurality of location service profiles includes at least one positioning method, at least one quality of service parameter, at least one mapping to at least one location service producer, at least one application service type, at least one service area type, or a combination thereof. In various embodiments, the receiver 312 receives a location request from a location service consumer. The processor 302 determines a first mapping of at least one application of at least one user equipment to a first location service profile of the plurality of location service profiles based on the location request. In some embodiments, the transmitter 310 transmits the first mapping and the first location service profile to the at least one location service producer. In a particular embodiment, the processor 302 determines a fused location estimate for the first location service profile.

[0038] In particular embodiments, location services ("LCS") is part of the 3rd Generation Partnership Program ("3GPP") architecture and radio access network ("RAN") framework that enables identification and standardized reporting of location information for user equipment ("UE's") and / or groups of UE's. Location information may be exposed to users, mobile equipment ("ME"), network operators, service providers, value-added service providers, and for internal operations of public land mobile networks ("PLMN"). In some embodiments, the LCS framework may be used for all different types of location information.

[0039] In various embodiments, location application programming interfaces ("APIs") may be provided for vertical devices that may have completely different network ("NW") handling capabilities and requirements for different scenarios. Different API exposures for different configurations may use additional signaling and / or complexity on the network or application side to provide the required quality of service ("QoS").

[0040] In particular embodiments, location publishing may be implemented based on different vertical needs (which may change dynamically over time and area, for example) without imposing additional complexity on the vertical applications.

[0041] In some embodiments, mobile network operators (“MNOs”) and / or third-party service providers (“SPs”) may dynamically offer customized value-added location services (e.g., location enhancements, location predictions) as APIs to improve vertical user experience and / or vertical server awareness.

[0042] In various embodiments, when there is a mix of non-3GPP and 3GPP positioning methods, the positioning methods may be integrated and negotiated.

[0043] In particular embodiments, location services may be dynamically provided in edge and / or mobile edge computing ("MEC") environments with minimal complexity and / or signaling, and a mix of positioning methods.

[0044] In some embodiments, off-network location support for verticals may be handled efficiently (e.g., UE-to-UE (“PC5”) communications may be used for some out-of-coverage scenarios, but location reporting may be performed by the NW and / or middleware when licensed resources and multi-operator vertical services are envisioned).

[0045] In various embodiments, there may be various use cases, verticals, scenarios, and application services (e.g., Vehicle-to-Everything ("V2X"), Industrial Internet of Things ("IIoT"), Unmanned Aircraft Systems ("UAS")) that use LCS in addition to data communications, which may increase the complexity of the LCS framework and the corresponding interactions between 3GPP® and non-3GPP entities. Location-related key performance indicators ("KPIs") for various use cases may require different levels of accuracy (e.g., horizontal, vertical, two-dimensional ("2D"), three-dimensional ("3D")), different location fix latency requirements, availability requirements, speed, and / or direction.

[0046] In certain embodiments, there may be an integration framework that uses LCS Profiles that consider sets of attributes to meet the specific requirements of use cases and / or application services across MNOs, verticals, and third-party operators. An LCS Profile solution may involve 1) configuration and signaling of LCS Profiles, and / or 2) the use of middleware to translate location requests from vertical applications into LCS Profiles and provide value-added services to the verticals.

[0047] In some embodiments, handling API calls from vertical customers and matching them with northbound APIs per LCS profile can enable easy vertical integration into fifth generation systems (“5GS”) and can enable faster location reporting (e.g., one location API may be proposed to a vertical, but multiple LCS profiles (e.g., which may be “hidden” to the customer) may be negotiated and consumed by the middleware).

[0048] In various embodiments, location services are one type of service that may be provided by a mobile communication system. Location-based services may serve a particular vertical industry or may be provided for a targeted application.

[0049] In particular embodiments, location-based services may include emergency services, emergency alert services, people tracking, fleet management, asset management, traffic congestion reporting, roadside assistance, route guidance to the nearest commercial business, traffic and public transportation information, city tours, localized advertising, mobile yellow pages, weather, and / or asset and service discovery.

[0050] In some embodiments, LCS sessions associated with LCS profiles may be defined and configured with minimal exposure to third parties and / or customers. Without such embodiments, an application server may need to integrate all measurements and interact with different systems to obtain the required location. LCS profiles can help optimize location determination based on the environment, UE context, and can facilitate profile checking and / or monitoring.

[0051] In various embodiments, the step of defining and / or configuring an LCS profile may include translating vertical requests into an LCS profile and deriving requested location reports. In particular embodiments, a location services enabler ("LSE") server and / or device may fetch location reports iteratively and / or based on priority to facilitate vertical requirements being satisfied with minimal signaling and / or complexity.

[0052] 4 is a block diagram illustrating one embodiment of a system 400 for mapping applications to LCS profiles. System 400 includes a non-3GPP (“N3GPP”) location service producer (“LSP”) 402, a 3GPP® LSP 404 (e.g., a 3GPP®-based LSP, a location management function (“LMF”), a radio access network (“RAN”), a service enabler application layer (“SEAL”)), a location service enabler (“LSE”) 406 (and / or middleware), and a location service consumer (“LSC”) 408 (e.g., a vertical application, an application function (“AF”)). As can be appreciated, any of the communications described herein may include one or more messages. Note that a location service consumer may be a UE or a group of UEs within a service area.

[0053] Steps 410-434 describe the initial mapping and transformation, and steps 436-442 perform remapping due to application changes and / or monitoring.

[0054] In a first communication 410, the LSE 406 receives a new location request from the LSC 408 (e.g., a vertical application). The location request may include requirements for location granularity, reporting, response time, end-to-end positioning latency (e.g., time to first fix), etc.

[0055] The LSE 406 maps an application identifier (“ID”) (e.g., a vertical application layer (“VAL”) server ID, an external UE ID, a group ID, etc.) or a service ID and / or type to an LCS profile from an available list of LCS profiles (which may be pre-configured by, for example, the location service provider and / or the MNO) 412. The mapping may take into account 1) the application service type (e.g., corresponding to different applications based on the vertical use case), 2) the environment or service area type (e.g., indoor, outdoor, urban, suburban, etc.), 3) the QoS requirements (e.g., accuracy), 4) the capabilities of the involved UEs, 5) the energy constraints of the device, 6) the time validity of the request, 7) the service and / or slice profile of the application, 8) a preference for a particular positioning method (e.g., a RAT-dependent method (e.g., a 3GPP-based positioning method) or a RAT-independent method), 9) the LCS service level (e.g., for an IIoT vertical), 10) the priority of the location method, and / or 11) the load of the location functions involved in the process.

[0056] Table 1 shows an example of the mapping information.

[0057] [Table 1]

[0058] In an optional second communication 414, there may be configuration of the LCS producer with the required positioning methods and mappings to applications per LCS profile (e.g., to know capabilities and / or permissions). This may include configuration of the LMF, RAN-LMC, UE-LCS, and / or SEAL Location Management Component ("LMC") with information on which methods to use and with what priority.

[0059] In the third communication 416, the LSE 406 (e.g., based on the application LCS profile) sends a location request and / or subscription to one or more of the following 3GPP-defined functions (e.g., based on the required location method): 1) the UE's (or, based on the profile, a group of UEs') application - which may be an activated LSE client on the UE side - such request may include additional data such as UE mobility, route, etc.; 2) the LMF via the Network Publication Function ("NEF") or via the GMLC and / or Location Search Function ("LRF"); 3) the RAN and / or RAN LCS - the LSE may request this indirectly via the UE modem (e.g., from the LSE to the LCS UE, from the LCS UE to the RAN); and / or 4) the SEAL Location Management Server ("LMS") (e.g., the LSE acting as a VAL server) via a SEAL API.

[0060] In the fourth communication 418, the LSE 406 receives a location response and / or report based on the request, i.e., 1) the UE's (or group of UEs based on the profile's) application, 2) the LMF, 3) the RAN and / or the RAN LCS - the RAN may provide this indirectly via the UE modem (e.g., from the RAN to the LCS UE, from the LCS UE to the LSE client, from the LSE client to the LSE server), and / or 4) the SEAL LMS.

[0061] The LSE 406 may request from all functions simultaneously or sequentially and conditional on whether requirements are met. The LSE 406 may check 420 after each receipt of a report to decide whether to perform further requests. The LSE 406 may start with the function with the highest priority and continue in descending order. The LSE 406 may perform positioning estimation processing and may determine additional inputs and / or processing based on the LCS profile.

[0062] The LSE 406 checks 422 whether the LCS requirements (eg, QoS requirements) are achieved and evaluates whether further action is required. In particular, such further action may be one of the following: 1) requesting a location report (e.g., based on an LCS profile) from a non-3GPP system or application server and / or client (e.g., from a wireless local area network (“WLAN”), a global navigation satellite system (“GNSS”), etc., via GPS, Bluetooth, motion sensors, etc.); 2) location verification via multiple sources (e.g., this may be useful in UAS scenarios where the location reported by an unmanned aerial vehicle (“UAV”) is unreliable); 3) location augmentation (e.g., using a 3D live map, etc.); 4) checking the location of all and / or additional UEs in the area and / or vicinity (e.g., as the UE's expected location may be correlated with other UEs in the area) (e.g., UEs located in a rectangular grid such as a zone); 5) using analytical and / or historical data to improve precision; 6) taking input about the target UE's location from other UEs in the area; and / or 7) group-based positioning.

[0063] In optional fifth communication 424, optional sixth communication 426, optional seventh communication 428, and optional ninth communication 430, if the action requires information from a location report, LSE 406 requests and / or receives location reports and / or supplemental information from one or more of the UE's app, the RAN, the LMF, the SEAL, and / or the non-3GPP system.

[0064] The LSE 406 calculates 432 a location estimate (e.g., actual location, predicted location, estimated location) for the application's UE and sends the location information to the vertical application server in a tenth communication 434. This may be a one-time event or may occur periodically and / or based on a trigger event.

[0065] Steps 436-442 describe the procedure for trigger events and adaptation.

[0066] In an eleventh communication 436, the LSE 406 may monitor the location of app #1 (e.g., along the route) and may trigger an update of app #a's mapping to the LCS profile if the location QoS cannot be met, if the service profile mapping changes, if the UE's location and / or mobility changes, or if the application is expected to be relocated to a different data network ("DN") name ("DNN") or slice.

[0067] If the trigger comes from an application, the LSE 406 receives a remapping of the application to a service profile or an expected change in application requirements (e.g., location accuracy and / or QoS). If the trigger comes from monitoring, monitoring capabilities in the LSE are required to trigger an action 438 that is an adaptation of an attribute (e.g., the UE moves from outdoors to a tunnel).

[0068] In a twelfth communication 440, the LSE 406 repeats steps 412-434 to update the LCS profile and incoming reports to ensure that location requirements are met (e.g., update remapping).

[0069] An example of an updated mapping is shown in Table 2, where the crossed out elements have been removed from the profile and other elements have been added.

[0070] [Table 2]

[0071] In a thirteenth communication 442, if the change was triggered by an application, the LSE 406 provides a report and / or response to the application indicating the change in the report and / or profile.

[0072] Certain embodiments include techniques for performing mapping and transformation between LSE servers and LSE clients located within a VALUE.

[0073] In a first embodiment, there may be LCS profile mapping and translation by the LSE server. In a first embodiment, the LCS profile is configured by and / or for the telecommunications carrier and / or provider (e.g., MNO or cloud provider). The LSE-S may be an enhancement of the SEAL LMS or a new entity.

[0074] 5 is a block diagram illustrating another embodiment of a system 500 for mapping applications to LCS profiles. The system 500 includes an application 502 (e.g., connected by GPS, Bluetooth, etc.), an LSE client 504, a UE-LCS client 506, a RAN 508, an LMF 510 (e.g., a 5th Generation Core (“5GC”) LMF, a Global Location Management System (“GLMS”)), a SEAL LMS 512, an LSE server 514 (“LSE-S”), a VAL server 516, and a non-3GPP access network 518 (e.g., trusted, untrusted). The application 502, the LSE client 504, and the UE-LCS client 506 may all be part of a VAL UE. As can be appreciated, any of the communications described herein may include one or more messages.

[0075] In a first communication 520, a location request message may be sent from the VAL server 516 to the LSE server 514. The location request message may include a VAL server ID, an application ID, an application type, location QoS requirements (e.g., accuracy, response time, etc.), location granularity (e.g., coordinates, cell level, civic address, topological location), vertical-specific supporting information (e.g., planned route, roadmap, etc.), time validity of requirements, area of ​​validity, predictive location services, service profile, device capabilities (e.g., GPS receiver, supported radio access technologies (“RATs”), supported positioning methods), power constraints, time deadlines for the request, minimum time between successive reports, and / or event triggering criteria (e.g., under what criteria a location report needs to be sent).

[0076] The LSE-S 514 performs 522 a mapping of the application to the LCS profile (eg, based on the ID received in step 520).

[0077] The LCS profile (or profiles) include one or more of the following attributes: vertical, use case, environment, positioning service level (e.g., for IIoT), LCS QoS parameters and / or accuracy, supported positioning methods, positioning method priority and / or preference, involved 3GPP capabilities and priorities, involved non-3GPP access networks (e.g., trusted, untrusted), required APIs and / or API information, location validation flag, location extension flag, and / or group-based positioning flag.

[0078] The mapping may take into account 1) application service type, 2) environment (e.g., indoor, outdoor, urban, suburban, etc.), 3) QoS requirements (e.g., accuracy), 4) capabilities of the UEs involved, 5) energy constraints of the device, 6) time validity of the request, 7) service and / or slice profile of the application, 8) preference for a particular positioning method (e.g., RAT-dependent or RAT-independent method), 9) LCS service level (e.g., for IIoT verticals), 10) location method priority, and / or 11) load of the location functions involved in the process.

[0079] One exemplary method for mapping an application to an LCS profile is to match the context information received in step 520 with the attributes of the LCS profile and further check the load of the LCS profile (e.g., the load that the LCS profile impacts on the load of each location service it provides). Mapping policies (e.g., based on application type) can be pre-configured based on vertical and / or OAM.

[0080] In a second communication 524 (e.g., a set of communications from the LSE-S 514), the LSE-S 514 configures the involved 3GPP functions and the application enabler client in the UE for mapping of applications to LCS profiles and configuration of reporting corresponding to the applications' LCS profiles. The configuration may include at least one of the following parameters: 1) UE ID, list of UE IDs, group ID, service ID, VAL server ID, and / or application type, 2) mapping of app#1 to LCS profile#x (e.g., this can also be a sequence of mappings for app#1, such as along the UE route), 3) reporting configuration (e.g., event triggering threshold, reporting periodicity, reporting format, minimum time between consecutive reports), 4) positioning method priority, 5) location reporting granularity (e.g., coordinates, cell level, civic address, topological location), 6) LCS profile attributes (e.g., if not already known by the involved entities), and / or 7) time validity and / or validity area of ​​the configuration. In some embodiments, step 524 may occur before step 520 (eg, when the application registers with LSE-S 514).

[0081] In the third communications 526, 530, 534, and 538, the LSE-S 514 performs a location request to one or more of the following:1) to the SEAL LMS acting as a VAL Server to request location information for one or more UEs (e.g., a VAL triggered location reporting trigger) - such a reporting trigger may also be enriched to indicate the LCS profile ID and to indicate the locations of all UEs with this LCS profile in this area; 2) to the LMF and / or Gateway Mobile Location Centre ("GMLC"), either directly or via the NEF acting as an AF - the LCS service request is sent to the GMLC and / or LMF or AMF via the NEF using a service-based interface or Common API Framework ("CAPIF") API, or directly to the GMLC if allowed (e.g., to the LSE-S in the MNO trust domain); 3) to the RAN and / or RAN-LMC - this request may be sent to the RAN function that calculates the location for one or more UEs - Such a request may include the app ID, location QoS requirements (e.g., absolute and relative horizontal and vertical accuracy, response time), positioning method and priority related to the positioning method and associated positioning measurements, a request for location information for all UEs with the same profile, the number of positioning fixes for a particular UE, confidence interval, alert limit, time to alert, target and positioning estimate integrity such as integrity risk; 4) to an application in the UE (e.g., LSE-S, Server Enabler Application Layer ("SEAL") Client ("C") ("SEAL-C")) - this request may be similar to the location information request or may be enhanced to include an LCS profile ID (e.g., if no app-to-profile mapping was sent in step 524) and a request for location reports for other nearby UEs in the same service and / or profile; and / or 5) to the MEC platform via a call to a location API - this request may be enhanced to include an LCS profile ID and configuration information (e.g., if the MEC capability is profile unaware).

[0082] In a fourth communication 528, 532, 536, and 540, the LSE-S 514 receives a location response (e.g., including a location report) from the entity requested in step 526, the location response providing location information and / or an estimate based on the requested granularity (e.g., coordinates, cell level, civic address, etc.), a timestamp, a triggering event (e.g., if the request is to send a location report only in case of an event), whether it is the actual location of the UE or the predicted location of the UE, and / or an associated confidence interval or related metric indicating the reliability of the provided location estimate.

[0083] The LSE-S 514 performs location reporting processing 542 and checks whether the received location information meets the LCS profile requirements (e.g., based on QoS parameters such as accuracy and / or response time). If the information meets the requirements, the method moves to step 554.

[0084] If the information does not meet the requirements, the LSE-S 514 performs 544 further processing based on the received location report and the context received in step 520 and checks the fused location estimate again. The further processing may include one or more of the following: 1) location enhancement (e.g., using a 3D live map), 2) using analytics and / or historical data to improve accuracy, and / or 3) mobility information of the UE and / or group of UEs.

[0085] In an optional fifth communication 546, if steps 542 and 544 do not provide the required LCS (or the LSE-S 514 does not have up-to-date information about the application context), the LSE-S 514 requests supplemental information related to UE positioning from the SEAL LMS and / or LMC, the LMF and / or AMF, the Network Data Analysis Function ("NWDAF"), one or more 3GPP® entities as LSE clients in the UE, or from the MEC platform via the MEC API.

[0086] In an optional sixth communication 548, the LSE-S 514 receives supplemental information based on the request. The information may include actual and / or predicted UE mobility, locations for all and / or additional UEs in the area and / or vicinity, UE location from other sources for location verification (e.g., may be used for UAS-related profiles), high-definition (“HD”) maps for a specific area, augmented location, relative locations between UEs within an application (e.g., between a drone and a pilot, between vehicles in a platoon), and location requests for one UE to be served on behalf of other UEs (e.g., a group leading the collection and transmission of other UE locations).

[0087] In an optional seventh communication 550A, an optional eighth communication 550B, an optional ninth communication 552A, and an optional tenth communication 552B, the LSE-S 514 checks that the LCS profile requirements are met for the application. If the requirements are not met, the LSE-S 514 and / or the LSE client 504 requests the non-3GPP domain to provide such information and receives the location information. This may be via one or more of the following three ways: 1) as shown in UE-assisted and UE-based positioning procedures via the N3IWF, TNGF, and / or Wireless Access Gateway Function ("W-AGF") or via the application layer (e.g., interfaces outside the scope of 3GPP®) - when interacting with the N3GPP access network, the reported location information depends on whether it is reliable or not - such information may include the UE's local Internet Protocol ("IP") address or local IP addresses of the UE and / or N5CW device, in case of WLAN access, the Basic Service Set Identifier ("BSSID") of the attached AP or the BSSID of the detected AP, and / or civic address and / or geospatial location information; 2) as a network-assisted positioning procedure via the N3IWF, TNGF, and / or W-AGF or via the application layer (e.g., interfaces outside the scope of 3GPP®) - This information may be the UE and / or N5CW device's local IP address and optionally User Datagram Protocol ("UDP") or Transmission Control Protocol ("TCP") source port, as well as a Trusted Non-3GPP Access Point ("TNAP") and / or Trusted WLAN Access Proxy ("TWAP") ID (e.g., in the case of a trusted device), and / or 3) may be via a SEAL LMC and / or LSE client to indirectly request UE location information (e.g., from a Global Positioning System ("GPS") receiver, Bluetooth receiver, etc.).

[0088] The LSE-S 514 calculates 554 a fused location estimate based on the previous steps and checks whether the requested location QoS (eg, based on the LCS profile) is met.

[0089] In an eleventh communication 556 , the LSE-S 514 reports the location information to the VAL server 516 .

[0090] One possible flow chart for the procedure described in FIG. 5 is shown in FIG. 6 and described herein.

[0091] In steps 558-564, an event, which may be provided by the application side, by the network, by OAM, and / or by the UE, may trigger a remapping of the application to a different LCS profile. This triggering event may be due to a change in environment (e.g., from indoor to outdoor), a change in the application's service profile (e.g., a change in service operation level), a change in location service profile availability in the target area, a change in location service profile area, or a mobility event that may require relocation of the application to a different DN and / or slice. In certain embodiments, if there is a mismatch between the application's LCS requirements and the LCS profile, the LSE server may be able to adapt the mapping to facilitate meeting the location QoS requirements.

[0092] If the trigger originates from OAM, the trigger may affect the remapping of all applications to a different LCS profile in the target geographical or topological area (e.g., cell area, tracking area) or slice instance.

[0093] In a twelfth communication 558, the LSE-S 514 may monitor the location of app #1 (e.g., along the route) and may trigger an update of the mapping of app #1 to the LCS profile if the location QoS cannot be met, if the service profile mapping changes, if the UE's location and / or mobility changes, or if the application is expected to be relocated to a different DNN or slice. If the trigger is application-derived, the LSE-S 514 receives a remapping of the application to a service profile or an expected change in application requirements (e.g., location accuracy and / or QoS).

[0094] If the trigger comes from monitoring, monitoring capabilities in the LSE-S 514 may be required and may trigger an action 560, which may be an adaptation of an attribute (e.g., the UE moves from outdoors to a tunnel).

[0095] In a thirteenth communication 562, the LSE-S 514 may repeat steps 522-556 to update the LCS profile and incoming reports to facilitate location requirements being met.

[0096] In a fourteenth communication 564, if the change was triggered by an application, the LSE-S 514 provides a report and / or response to the application indicating the change in the report and / or profile.

[0097] FIG. 6 is a flowchart illustrating one embodiment of a method 600 for requirements validation. Method 600 includes step 602 of mapping an application (e.g., app #1) to an LCS profile (e.g., LCS profile #x). Method 600 further includes step 604 of requesting and / or receiving a location report from a high-priority LCS producer (e.g., based on profile #x). Method 600 includes step 606 of determining whether the report meets the requirements (e.g., QoS requirements). If the report meets the requirements, method 600 includes step 608 of terminating and / or sending the location information to a VAL server. If the report does not meet the requirements, method 600 includes step 610 of placing the next LCS producer (e.g., based on profile #x) in a first-priority location. Method 600 then returns to step 604 until there are no more LCS producers and / or until a time threshold is reached.

[0098] If there are no more LCS producers and / or a time threshold has been reached, method 600 performs 612 additional processing for the profile and / or application (e.g., using location enhancements, analysis, and / or supplemental information). Method 600 determines 614 whether the process location estimate meets the requirements. If the process location estimate meets the requirements, method 600 performs step 608. If the process location estimate does not meet the requirements, method 600 requests and receives 616 reports from non-3GPP access points and returns to step 612.

[0099] In a second embodiment, the LCS profile mapping may be performed by an LSE client (eg, an LSE client residing in a device-side -VALUE based on an LSE server configuration).

[0100] 7 is a block diagram illustrating a further embodiment of a system 700 for mapping applications to LCS profiles. The system 700 includes a first VALUE (e.g., VALUE#1) that includes a first application 702 (e.g., App#1), a first LSE client 704 (e.g., and / or SEAL LMC), and a first UE-LCS client 706. The system 700 also includes a second VALUE (e.g., VALUE#2) that includes a second application 708 (e.g., App#2), a second LSE client 710, and a second UE-LCS client 712. The system 700 includes a non-3GPP access network 714, a RAN 716 (e.g., or CN, SEAL, MEC), and an LSE server (LSE-S) 718. As can be appreciated, any of the communications described herein may include one or more messages.

[0101] In the first communication 720 and the second communication 722, the LSE-S 718 configures the LSE client at the UE side for mapping of applications to LCS profiles and configuration of reporting corresponding to the LCS profiles of the applications. The configuration may be in the form of a request and may include at least one of the following parameters: 1) UE ID, list of UE IDs, group ID, service ID, VAL server ID, and / or application type, 2) pre-defined mapping of app #1 to LCS profile #x (e.g., this may be a sequence of mappings for app #1, such as along the UE route), 3) reporting configuration (e.g., event triggering threshold, reporting periodicity, reporting format, minimum time between consecutive reports), 4) positioning method priority, 5) location reporting granularity (e.g., coordinates, cell level, civic address, topological location), 6) LCS profile attributes (e.g., if not already known by the involved entities), and / or 7) time validity and / or validity area of ​​the configuration. The LSE client may then send back a response message to notify about the success of the configuration (e.g., an affirmative acknowledgement ("ACK") and / or a negative acknowledgement ("NACK")).

[0102] In an optional third communication 724, the first LSE client 704 configures LSE profiles of other UEs and / or LSE clients within nearby services and / or applications and / or within the same group.

[0103] In a fourth communication 726, a location request message is sent from the first application 702 in the UE to the first LSE client 704 and includes one or more of an application ID, an application type, location QoS requirements (e.g., accuracy, response time, etc.), location granularity (e.g., coordinates, cell level, civic address, topological location), vertical-specific support information (e.g., planned route, roadmap, etc.), time validity of the requirement, area of ​​validity, predictive location services, service profile, device capabilities (e.g., GPS receiver, supported RATs, supported positioning methods), power constraints, time deadline for the request, minimum time between successive reports, and / or event triggering criteria (e.g., under what criteria a location report needs to be sent).

[0104] The first LSE client 704 performs 728 a mapping of the application to the LCS profile (eg, based on the IDs received in steps 720 and 722).

[0105] The LCS profile includes one or more of the following attributes: vertical, use case, environment, positioning service level (e.g., for IIoT), LCS QoS parameters and / or accuracy, supported positioning methods, positioning method priority and / or preference, location estimation completeness and reliability, involved 3GPP capabilities and preferences, involved non-3GPP access networks (e.g., trusted, untrusted), required APIs and / or API information, location validation flag, location extension flag, and / or group-based positioning flag.

[0106] The mapping may take into account 1) application service type, 2) environment (e.g., indoor, outdoor, urban, suburban, etc.), 3) QoS requirements (e.g., accuracy), 4) capabilities of the UEs involved, 5) energy constraints of the device, 6) time validity of the request, 7) service and / or slice profile of the application, 8) preference for a particular positioning method (e.g., RAT-dependent or RAT-independent method), 9) LCS service level (e.g., for IIoT verticals), 10) location method priority, and / or 11) load of the location functions involved in the process.

[0107] One exemplary method for mapping an application to an LCS profile is to match the context information received in step 726 with most of the attributes of the LCS profile and also check the load of the LCS profile (e.g., the load of the LCS profile affects the load of each location service that provides functionality). Mapping policies (e.g., based on application type) can be pre-configured based on vertical and / or OAM.

[0108] In a fifth communication 730, the second LSE client (“LSE-C”) 704 may send a mapping of applications to LCS profiles (e.g., based on the IDs received in steps 720-724) to other UEs and / or LSE clients within nearby services and / or applications and / or within the same group (e.g., configured with the LSE profile in 724).

[0109] In the sixth communication 732, if the VAL UE#1 has an LCS client, the VAL UE#1 may also fetch location information locally from the first UE-LCS client 706 (e.g., how this is received at the first LSE-C704 may be up to the implementation).

[0110] In a seventh communication 734, the first LSE-C 704 performs a location request to one or more of the following: 1) to the LMF and / or GMLC via the AF and via the NEF - the LCS service request is sent to the NEF via the AF (e.g., SEAL LMS and / or LSE-S), from the AF via the NEF to the GMLC and / or LMF or AMF using a service-based interface or CAPIF API, or directly to the GMLC if allowed; 2) to the RAN - this request may be sent to the RAN function that calculates the location for one or more UEs - such a request may include application ID, location QoS requirements (e.g., absolute and relative horizontal and vertical accuracy, response time), positioning method and priority related to the positioning method and associated positioning measurements, a request for location information for all UEs with the same profile, number of positioning fixes for a particular UE, positioning estimate completeness, confidence interval, alert limit, time to alert, and / or target and integrity risk; 3) to the UE's application - This request may be similar to the location information request, or may be enhanced to include the LCS profile ID (e.g., if no application to profile mapping was sent in step 726) and a request for location reports for other nearby UEs within the same service and / or profile, and / or 4) to the MEC platform via a location API call (e.g., from the LSE client to the MEC location service) - this request may be enhanced to include the LCS profile ID and configuration information (e.g., if the MEC capability is profile unaware).

[0111] In an eighth communication 736, the first LSE-C704 receives a location response (e.g., including a location report) from the entity requested in step 736, the location response providing location information and / or an estimate based on the requested granularity (e.g., coordinates, cell level, civic address, etc.), a timestamp, a triggering event (e.g., if the request is to send a location report only in case of an event), whether it is the actual location of the UE or the predicted location of the UE, and an associated confidence interval or related metric indicating the reliability of the provided location estimate.

[0112] The first LSE-C 704 checks whether the received location information meets the LCS profile requirements (e.g., based on QoS parameters such as accuracy and / or response time) 738. If the requirements are met, it proceeds to step 752.

[0113] If the requirements are not met, the first LSE-C 704 performs 740 further processing based on the received location report and the context received in steps 720-724 to check the fused location estimate. This processing may include 1) using location augmentation, such as using a 3D live map, 2) using analytical and / or historical data to refine, and / or 3) mobility information for the UE and / or group of UEs.

[0114] In a ninth communication 742, if steps 738 and 740 do not provide the required LCS (or the LSE-C does not have up-to-date information about the application context), the first LSE-C 704 requests supplemental information related to UE positioning from all and / or additional UEs within the area and / or vicinity of the UE via groupcast and / or broadcast messages to all users within the LCS profile or in a given area.

[0115] In a tenth communication 744, the first LSE-C 704 receives the supplemental information based on the request.

[0116] In optional eleventh communication 746 and optional twelfth communication 748, the first LSE-C 704 again checks that the LCS profile requirements are met for the application. If the profile requirements are not met, the first LSE-C 704 requests the non-3GPP access network (e.g., WLAN) to provide such information and receives location information. When interacting with an N3GPP access network, the reported location information depends on whether it is trusted or not. Such information may be the UE's local IP address or the local IP address of the UE and / or non-5G compatible over WLAN ("N5CW") device, in the case of WLAN access, the BSSID of the attached AP or the BSSID of the detected AP, the civic address, and / or geospatial location information.

[0117] The first LSE-C 704 calculates 750 a fused location estimate based on the previous steps and checks whether the requested location QoS (eg, based on the profile) is met.

[0118] In a thirteenth communication 752, the first LSE-C 704 reports the location information to the first application 702.

[0119] In a third embodiment, the LSE function may enhance the functions (or new services) of the LMF and / or GMLC based on the deployment on the network side.

[0120] 8 is a block diagram illustrating another embodiment of a system 800 for mapping applications to LCS profiles. The system 800 includes a UE 802, a non-3GPP interworking function (“N3IWF”) 804 (e.g., and / or TNGF and / or W-AGF), a RAN 806, an AMF 808 (e.g., and / or GMLC and / or LMF and / or LSE functions), a UDM 810, and an external LCS client 812 (e.g., AF, application). As can be appreciated, any of the communications described herein may include one or more messages.

[0121] In the first communication 814, there may be an LCS profile configuration.

[0122] In a second communication 816, a location request (e.g., including a subscription to location events) originates from the external LCS client 812. The AMF 808 may receive context and / or measurements that are non-UE related and may support location extensions.

[0123] In a third communication 818, the AMF 808 retrieves a mapping of applications to LCS profiles from the UDM 810. Here, either the AMF 808 or the UDM 810 maintains the mapping between applications and / or UEs and LCS profiles. The LCS profiles provide positioning access types, methods, QoS, etc.

[0124] The AMF 808 configures 820 the required reports, including which entities to request reports from and what priorities to use. The AMF 808 also considers the priorities of different positioning methods based on the LCS profile. The AMF 808 may also consider the radio resource control ("RRC") state of the UE to configure an energy-efficient positioning method, which may or may not affect the achievable accuracy.

[0125] In a fourth communication 822, the AMF 808 sends a location request with the LCS profile ID and / or the UE ID to the RAN 806. The fourth communication 822 may be performed by the AMF 808 via a network positioning message sent to a serving next generation ("NG") RAN ("NG-RAN") node in an N2 transport message.

[0126] The RAN 806 calculates 824 and / or obtains any location information for the profile and / or UE. The RAN 806 returns any obtained location information to the AMF 808 in a fifth communication 826. This may be done via the AMF 808 in a network positioning message from the AMF 808 to the LSE over a service-based interface included in an N2 transport message (e.g., between the RAN 806 and the AMF 808).

[0127] In a sixth communication 828, the AMF 808 sends a location request to the N3IWF 804 along with the UE ID and optionally with the LCS profile ID and / or information. This may be done by the AMF 808 via a network positioning message to the serving N3IWF 804.

[0128] The N3IWF 804 calculates 829 and / or obtains any location information for the profile and / or UE. In a seventh communication 830, the N3IWF 804 returns any obtained location information to the AMF 808. The reported location information depends on whether it is reliable or not. Such information may be the local IP address of the UE or the local IP addresses of the UE and / or N5CW device, in case of WLAN access, the BSSID of the attached AP or the BSSID of the detected AP, the civic address, and / or geospatial location information.

[0129] In an eighth communication 832, the AMF 808 sends a location request to the UE 802 (e.g., in a DL Non-Access Stratum ("NAS") transport message via a downlink positioning message to the UE 802) with the LCS profile ID and / or information.

[0130] The UE 802 stores 834 any assistance data provided in the downlink positioning message and performs any positioning measurements and / or location calculations requested by the downlink positioning message. In a ninth communication 836, the UE 802 sends an uplink positioning message included in a NAS transport message to the AMF 808 (e.g., to acknowledge the downlink positioning message) and returns any location information or any capabilities based on the profile.

[0131] The AMF 808 checks 838 whether the received location information meets the LCS profile requirements (eg, based on QoS parameters such as accuracy and / or response time).

[0132] If the requirements are not met, the AMF 808 performs 840 further processing based on the received location report and the context received in step 816 and checks the fused location estimation again. Such processing may include 1) location enhancement using a 3D live map, 2) refinement using analytical and / or historical data, and / or 3) mobility information of the UE and / or group of UEs.

[0133] In a tenth communication 842, if steps 832-836 do not provide the required LCS (or the LSE does not have up-to-date information about the app context), the AMF 808 requests and receives supplemental information.

[0134] The AMF 808 calculates 844 a fused location estimate based on the previous steps and checks whether the requested location QoS (eg, based on the profile) is met.

[0135] In an eleventh communication 846, the AMF 808 reports the location information to the external LCS client 812.

[0136] 9 is a flow chart diagram illustrating one embodiment of a method 900 for mapping application and location service profiles. In some embodiments, the method 900 is performed by an apparatus such as the network unit 104. In particular embodiments, the method 900 may be performed by a processor executing program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0137] In various embodiments, method 900 includes configuring 902 a plurality of location service profiles. Each location service profile of the plurality of location service profiles includes at least one positioning method, at least one quality of service parameter, at least one mapping to at least one location service producer, at least one application service type, at least one service area type, or a combination thereof. In some embodiments, method 900 includes receiving 904 a location request from a location service consumer. In particular embodiments, method 900 includes determining 906 a first mapping of at least one application of at least one user equipment to a first location service profile of the plurality of location service profiles based on the location request. In various embodiments, method 900 includes transmitting 908 the first mapping and the first location service profile to at least one location service producer. In some embodiments, method 900 includes determining 910 a fused location estimate for the first location service profile.

[0138] In a particular embodiment, the method 900 further includes receiving at least one location report corresponding to the first location service profile, the at least one location report being derived via at least one radio access technology dependent positioning method, at least one radio access technology independent positioning method, or a combination thereof. In some embodiments, a fused location estimate for the first location service profile is determined based on the at least one location report. In various embodiments, the method 900 further includes transmitting the fused location estimate to a location service consumer.

[0139] In one embodiment, method 900 further includes determining whether a location quality of service requirement is met based on the fused location estimate. In a particular embodiment, method 900 further includes sending a request for supplemental information and receiving a response to the request for supplemental information. In some embodiments, the supplemental information includes actual user equipment mobility information, predicted user equipment mobility information, location information for user equipment in an area, user equipment location information obtained from a secondary source, a map for a particular area, enhanced location information, relative location information between user equipment in an application, location request information, or some combination thereof.

[0140] In various embodiments, method 900 further includes transmitting the fused location estimate to at least one user equipment, a group of user equipment, or a combination thereof within the service area. In one embodiment, each location service profile of the plurality of location service profiles includes application information, user equipment context information, priority information, application programming interface information, location enhancement requirements, location prediction requirements, sidelink positioning assistance requirements, proximity-based location estimation requirements, location validation requirements, or some combination thereof. In a particular embodiment, method 900 further includes transmitting a request for a location report to at least one location service producer based on the first location service profile.

[0141] In some embodiments, the at least one location service producer includes a service enabler application layer location management server, a gateway mobile location center, a non-3G partnership program interworking function, a trusted non-3G partnership program gateway function, a wireless access gateway function, a mobile edge computing service, a radio access network, a user equipment, or some combination thereof. In various embodiments, the location service consumer includes a vertical application server, an application function, a vertical enabler server, a user equipment application, an application enabler client, an external location service client, a network device, or a combination thereof. In one embodiment, the location service enabler is a user equipment application, a middleware application device, a network device, or a combination thereof.

[0142] In certain embodiments, method 900 further includes receiving a trigger event from at least one location service producer, an application entity, or a combination thereof, determining a second mapping of at least one application of at least one user equipment to a second location service profile of the plurality of location service profiles based on a first location service profile of the plurality of location service profiles and the trigger event, and transmitting the second mapping and the second location service profile to the at least one location service producer. In some embodiments, method 900 further includes receiving at least one additional location report for the second location service profile, wherein the at least one additional location report is derived via at least one radio access technology dependent positioning method, at least one radio access technology independent positioning method, or a combination thereof.

[0143] In various embodiments, the method 900 further includes determining a second fused location estimate for the second location service profile based at least in part on the at least one additional location report. In one embodiment, the method 900 further includes transmitting the second fused location estimate to the location service consumer.

[0144] In one embodiment, a method in a location services enabler includes configuring a plurality of location service profiles, each location service profile of the plurality of location service profiles including at least one positioning method, at least one quality of service parameter, at least one mapping to at least one location service producer, at least one application service type, at least one service area type, or a combination thereof; receiving a location request from a location service consumer; determining a first mapping of at least one application of at least one user equipment to a first location service profile of the plurality of location service profiles based on the location request; sending the first mapping and the first location service profile to the at least one location service producer; and determining a fused location estimate for the first location service profile.

[0145] In certain embodiments, the method further includes receiving at least one location report corresponding to the first location service profile, wherein the at least one location report is derived via at least one radio access technology dependent positioning method, at least one radio access technology independent positioning method, or a combination thereof.

[0146] In some embodiments, the fused location estimate for the first location service profile is determined based on at least one location report.

[0147] In various embodiments, the method further includes transmitting the fused location estimate to a location services consumer.

[0148] In one embodiment, the method further includes determining whether a location quality of service requirement is met based on the fused location estimate.

[0149] In certain embodiments, the method further includes sending a request for the supplemental information and receiving a response to the request for the supplemental information.

[0150] In some embodiments, the supplemental information includes actual user equipment mobility information, predicted user equipment mobility information, location information for user equipment within an area, user equipment location information obtained from a secondary source, a map for a particular area, extended location information, relative location information between user equipment within an application, location request information, or some combination thereof.

[0151] In various embodiments, the method further includes transmitting the fused location estimate to at least one user equipment, a group of user equipment, or a combination thereof within the service area.

[0152] In one embodiment, each location service profile of the plurality of location service profiles includes application information, user equipment context information, priority information, application programming interface information, location enhancement requirements, location prediction requirements, sidelink positioning assistance requirements, proximity-based location estimation requirements, location validation requirements, or some combination thereof.

[0153] In certain embodiments, the method further includes sending a request for a location report to at least one location service producer based on the first location service profile.

[0154] In some embodiments, the at least one location service producer includes a service enabler application layer location management server, a gateway mobile location center, a non-3G partnership program interworking function, a trusted non-3G partnership program gateway function, a wireless access gateway function, a mobile edge computing service, a radio access network, a user equipment, or some combination thereof.

[0155] In various embodiments, the location service consumer includes a vertical application server, an application function, a vertical enabler server, an application on a user equipment, an application enabler client, an external location service client, a network device, or a combination thereof.

[0156] In one embodiment, the location services enabler is a user equipment application, a middleware application device, a network device, or a combination thereof.

[0157] In certain embodiments, the method further includes receiving a trigger event from at least one location service producer, an application entity, or a combination thereof; determining a second mapping of at least one application of at least one user equipment to a second location service profile of the plurality of location service profiles based on a first location service profile of the plurality of location service profiles and the trigger event; and transmitting the second mapping and the second location service profile to the at least one location service producer.

[0158] In some embodiments, the method further includes receiving at least one additional location report for the second location service profile, wherein the at least one additional location report is derived via at least one radio access technology dependent positioning method, at least one radio access technology independent positioning method, or a combination thereof.

[0159] In various embodiments, the method further includes determining a second fused location estimate for a second location service profile based at least in part on the at least one additional location report.

[0160] In one embodiment, the method further includes transmitting the second fused location estimate to a location services consumer.

[0161] In one embodiment, an apparatus comprises a location services enabler, the apparatus further comprising: a processor for configuring a plurality of location service profiles, each location service profile of the plurality of location service profiles including at least one positioning method, at least one quality of service parameter, at least one mapping to at least one location service producer, at least one application service type, at least one service area type, or a combination thereof; a receiver for receiving a location request from a location service consumer, the processor for determining a first mapping of at least one application of at least one user equipment to a first location service profile of the plurality of location service profiles based on the location request; and a transmitter for transmitting the first mapping and the first location service profile to the at least one location service producer, the processor determining a fused location estimate for the first location service profile.

[0162] In a particular embodiment, the receiver receives at least one location report corresponding to the first location service profile, the at least one location report being derived via at least one radio access technology dependent positioning method, at least one radio access technology independent positioning method, or a combination thereof.

[0163] In some embodiments, the fused location estimate for the first location service profile is determined based on at least one location report.

[0164] In various embodiments, the transmitter transmits the fused location estimate to a location services consumer.

[0165] In one embodiment, the processor determines whether a location quality of service requirement is met based on the fused location estimate.

[0166] In certain embodiments, a transmitter transmits a request for supplemental information and receives a response to the request for supplemental information.

[0167] In some embodiments, the supplemental information includes actual user equipment mobility information, predicted user equipment mobility information, location information for user equipment within an area, user equipment location information obtained from a secondary source, a map for a particular area, extended location information, relative location information between user equipment within an application, location request information, or some combination thereof.

[0168] In various embodiments, the transmitter transmits the fused location estimate to at least one user equipment, a group of user equipment, or a combination thereof within the service area.

[0169] In one embodiment, each location service profile of the plurality of location service profiles includes application information, user equipment context information, priority information, application programming interface information, location enhancement requirements, location prediction requirements, sidelink positioning assistance requirements, proximity-based location estimation requirements, location validation requirements, or some combination thereof.

[0170] In a particular embodiment, the transmitter sends a request for a location report to at least one location service producer based on the first location service profile.

[0171] In some embodiments, the at least one location service producer includes a service enabler application layer location management server, a gateway mobile location center, a non-3G partnership program interworking function, a trusted non-3G partnership program gateway function, a wireless access gateway function, a mobile edge computing service, a radio access network, a user equipment, or some combination thereof.

[0172] In various embodiments, the location service consumer includes a vertical application server, an application function, a vertical enabler server, an application on a user equipment, an application enabler client, an external location service client, a network device, or a combination thereof.

[0173] In one embodiment, the location services enabler is a user equipment application, a middleware application device, a network device, or a combination thereof.

[0174] In a particular embodiment, the receiver receives a trigger event from at least one location service producer, an application entity, or a combination thereof, the processor determines a second mapping of at least one application of at least one user equipment to a second location service profile of the plurality of location service profiles based on a first location service profile of the plurality of location service profiles and the trigger event, and the transmitter transmits the second mapping and the second location service profile to the at least one location service producer.

[0175] In some embodiments, the receiver receives at least one additional location report for the second location service profile, the at least one additional location report being derived via at least one radio access technology dependent positioning method, at least one radio access technology independent positioning method, or a combination thereof.

[0176] In various embodiments, the processor determines a second fused location estimate for a second location service profile based at least in part on the at least one additional location report.

[0177] In one embodiment, the transmitter transmits the second fused location estimate to a location services consumer.

[0178] The embodiments may be embodied in other specific forms. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are intended to be embraced within their scope. [Explanation of symbols]

[0179] 100 Wireless Communication System 102 Remote Unit 104 Network Unit 200 equipment 202 processors 204 memory 206 Input Devices 208 Display 210 Transmitter 212 receiver 300 equipment 302 processor 304 memory 306 Input Devices 308 Display 310 Transmitter 312 Receiver 314 Network Interface 316 Application Interface 400 System 406 Location Services Enabler, LSE 408 Location Service Consumer, LSC 410 First Communication 414 Second Communication 416 Third Communication 418 Fourth Communication 424 Fifth Communication 426 Sixth Communication 428 Seventh Communication 430 Ninth Communication 434 Tenth Communication 436 11th Communication 440 12th Communication 442 13th Communication 500 Systems 502 Application 504 LSE Client 506 UE-LCS Client 508 RAN 510 LMF 512 SEAL LMS 514 LSE Server, LSE-S 516 VAL Server 520 First Communication 524 Second Communication 526 Third Communication 528 Fourth Communication 530 Third Communication 532 Fourth Communication 534 Third Communication 536 Fourth Communication 538 Third Communication 540 Fourth Communication 546 Fifth Communication 548 Sixth Communication 550A Seventh Communication 550B Eighth Communication 552A 9th Communication 552B 10th Communication 556 11th Communication 558 12th Communication 562 13th Communication 564 14th Communication 600 ways 700 System 702 First Application 704 First LSE Client, First LSE-C 706 First UE-LCS Client 708 Second Application 710 Second LSE Client 712 Second UE-LCS Client 716 RAN 718 LSE Server, LSE-S 720 First Communication 722 Second Communication 724 Third Communication 726 Fourth Communication 730 Fifth Communication 732 Sixth Communication 734 Seventh Communication 736 Eighth Communication 742 Ninth Communication 744 10th Communication 746 11th Communication 748 12th Communication 752 13th Communication 800 System 802 UE 806 RAN 808 AMF 810 UDM 812 External LCS Clients 814 First Communication 816 Second Communication 818 Third Communication 822 Fourth Communication 826 Fifth Communication 828 Sixth Communication 830 Seventh Communication 832 Eighth Communication 836 Ninth Communication 842 Tenth Communication 846 11th Communication 900 ways

Claims

1. 1. A method in a location services enabler, comprising: configuring a plurality of location service profiles, each location service profile of the plurality of location service profiles including at least one positioning method, at least one quality of service parameter, at least one mapping to at least one location service producer, at least one application service type, at least one service area type, or a combination thereof; receiving a location request from a location services consumer; determining a first mapping of at least one application of at least one user equipment to a first location service profile of the plurality of location service profiles based on the location request; sending the first mapping and the first location service profile to the at least one location service producer; determining a fused location estimate for the first location service profile; A method comprising:

2. 10. The method of claim 1, further comprising: receiving at least one location report corresponding to the first location service profile, the at least one location report being derived via at least one radio access technology dependent positioning method, at least one radio access technology independent positioning method, or a combination thereof; and determining the fused location estimate for the first location service profile based on the at least one location report.

3. The method of claim 2 , further comprising transmitting the fused location estimate to the location services consumer.

4. The method of claim 1 , further comprising sending a request for supplemental information and receiving a response to the request for supplemental information.

5. 5. The method of claim 4, wherein the supplemental information includes actual user equipment mobility information, predicted user equipment mobility information, location information about user equipment within an area, user equipment location information obtained from a secondary source, a map for a particular area, extended location information, relative location information between user equipment within an application, location request information, or any combination thereof.

6. 6. The method of claim 1, wherein each location service profile of the plurality of location service profiles comprises application information, user equipment context information, priority information, application programming interface information, a location enhancement requirement, a location prediction requirement, a sidelink positioning assistance requirement, a proximity-based location estimation requirement, a location validation requirement, or some combination thereof.

7. The method of claim 1 , further comprising the step of sending a request for a location report to the at least one location service producer based on the first location service profile.

8. 8. The method of claim 1, wherein the at least one location service producer comprises a service enabler application layer location management server, a gateway mobile location center, a non-3G partnership program interworking function, a trusted non-3G partnership program gateway function, a wireless access gateway function, a mobile edge computing service, a radio access network, a user equipment, or any combination thereof.

9. 9. The method of claim 1, wherein the location service consumer comprises a vertical application server, an application function, a vertical enabler server, an application of the user equipment, an application enabler client, an external location service client, a network device, a remote device, a group of user equipment, or a combination thereof.

10. The method of claim 1 , wherein the location services enabler is an application of the user equipment, a middleware application device, a network device, or a combination thereof.

11. receiving a trigger event from the at least one location service producer, an application entity, a network entity, or a combination thereof; determining a second mapping of at least one application of at least one user equipment to a second location service profile of the plurality of location service profiles based on the first location service profile of the plurality of location service profiles and the trigger event; sending the second mapping and the second location service profile to the at least one location service producer; 11. The method of any one of claims 1 to 10, further comprising:

12. 12. The method of claim 11, further comprising receiving at least one additional location report for the second location service profile, wherein the at least one additional location report is derived via at least one radio access technology dependent positioning method, at least one radio access technology independent positioning method, or a combination thereof.

13. 13. The method of claim 12, further comprising: determining a second fused location estimate for the second location service profile based at least in part on the at least one additional location report; and transmitting the second fused location estimate to the location service consumer.

14. 1. An apparatus comprising a location services enabler, the apparatus comprising: a processor for configuring a plurality of location service profiles, each location service profile of the plurality of location service profiles including at least one positioning method, at least one quality of service parameter, at least one mapping to at least one location service producer, at least one application service type, at least one service area type, or a combination thereof; a receiver for receiving a location request from a location services consumer, the processor determining a first mapping of at least one application of at least one user equipment to a first location service profile of the plurality of location service profiles based on the location request; a transmitter for transmitting the first mapping and the first location service profile to the at least one location service producer; Furthermore, the processor determining a fused location estimate for the first location service profile. Device.

15. the receiver receiving a trigger event from the at least one location service producer, an application entity, or a combination thereof; the processor determines a second mapping of at least one application of at least one user equipment to a second location service profile of the plurality of location service profiles based on the first location service profile of the plurality of location service profiles and the trigger event; the transmitter transmitting the second mapping and the second location service profile to the at least one location service producer; 15. The apparatus of claim 14.

Images