EP4018690A1 - Providing location information - Google Patents

Abstract

There is provided a method performed by a radio access network device, the method comprising: deciding that a location of a target device is to be determined; determining location of the target device; after having determined the location of the target device, receiving a location request; responding to the location request with location information of the target device.

Description

PROVIDING LOCATION INFORMATION

TECHNICAL FIELD

Various example embodiments relate generally to positioning or locat ing of a device.

BACKGROUND

The number of services which require location information is heavily increasing. In addition to the use cases related to regulatory requirements (e.g. emergency call), other services may now require the use of location information: machine-to-machine (M2M) and Internet of Things (IoT) devices, commercial ser vices and also network optimization. The related use cases may comprise e.g. reg ulatory requirements for emergency call positioning, public safety & security and lawful interception, positioning of IoT devices, indoor positioning for mobile ad vertising, and leveraging subscriber location to optimize network coverage and re duce costs.

BRIEF DESCRIPTION

According some aspects, there is provided the subject matter of the in dependent claims. Some further aspects are defined in the dependent claims.

The embodiments and/or examples that do not fall under the scope of the claims are to be interpreted as examples useful for understanding the disclo sure.

LIST OF THE DRAWINGS

In the following, the invention will be described in greater detail with reference to the embodiments and the accompanying drawings, in which

Figure 1 presents a wireless communication system, according to an embodiment;

Figure 2 shows a radio access network and a core network, according to an embodiment;

Figures 3 depicts a method, according to an embodiment;

Figures 4 and 5 illustrate signaling flow diagrams, according to some embodiments;

Figures 6 and 7 depict methods, according to some embodiments; and

Figures 8, 9 and 10 illustrate apparatuses, according to some embodi ments. DESCRIPTION OF EMBODIMENTS

The following embodiments are exemplary. Although the specification may refer to "an", "one", or "some" embodiment(s) in several locations of the text, this does not necessarily mean that each reference is made to the same embodi ments), or that a particular feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embod iments. In this application terms "positioning" and "locating" are used interchange ably. For the purposes of the present disclosure, the phrases "A or B" and "A and/or B" means (A), (B), or (A and B). For the purposes of the present disclosure, the phrase "A, B, and/or C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C). For the purposes of the present disclosure, the phrase "at least one of the following: A, B, C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C).

Embodiments described may be implemented in a radio system, such as one comprising at least one of the following radio access technologies (RATs): Worldwide Interoperability for Micro-wave Access (WiMAX), Global System for Mobile communications (GSM, 2G), GSM EDGE radio access Network (GERAN), General Packet Radio Service (GRPS), Universal Mobile Telecommunication System (UMTS, 3G) based on basic wideband-code division multiple access (W-CDMA), high-speed packet access (HSPA), Long Term Evolution (LTE), LTE-Advanced, and enhanced LTE (eLTE). Term 'eLTE' here denotes the LTE evolution that connects to a 5G core. LTE is also known as evolved UMTS terrestrial radio access (EUTRA) or as evolved UMTS terrestrial radio access network (EUTRAN). A term "resource" may refer to radio resources, such as a physical resource block (PRB), a radio frame, a subframe, a time slot, a subband, a frequency region, a sub-carrier, a beam, etc. The term "transmission" and/or "reception" may refer to wirelessly transmit ting and/or receiving via a wireless propagation channel on radio resources

The embodiments are not, however, restricted to the systems/RATs given as an example but a person skilled in the art may apply the solution to other communication systems provided with necessary properties. One example of a suitable communications system is the 5G system. The 3GPP solution to 5G is re ferred to as New Radio (NR). 5G has been envisaged to use multiple-input-multiple- output (MIMO) multi-antenna transmission techniques, more base stations or nodes than the current network deployments of LTE (a so-called small cell con cept), including macro sites operating in co-operation with smaller local area ac cess nodes and perhaps also employing a variety of radio technologies for better coverage and enhanced data rates. 5G will likely be comprised of more than one radio access technology / radio access network (RAT/RAN), each optimized for certain use cases and/or spectrum. 5G mobile communications may have a wider range of use cases and related applications including video streaming, augmented reality, different ways of data sharing and various forms of machine type applica tions, including vehicular safety, different sensors and real-time control. 5G is ex pected to have multiple radio interfaces, namely below 6GHz, cmWave and mmWave, and being integrable with existing legacy radio access technologies, such as the LTE.

The current architecture in LTE networks is distributed in the radio and centralized in the core network. The low latency applications and services in 5G require to bring the content close to the radio which leads to local break out and multi-access edge computing (MEC). 5G enables analytics and knowledge genera tion to occur at the source of the data. This approach requires leveraging resources that may not be continuously connected to a network such as laptops, smartphones, tablets and sensors. MEC provides a distributed computing environ ment for application and service hosting. It also has the ability to store and process content in close proximity to cellular subscribers for faster response time. Edge computing covers a wide range of technologies such as wireless sensor networks, mobile data acquisition, mobile signature analysis, cooperative distributed peer- to-peer ad hoc networking and processing also classifiable as local cloud/fog com puting and grid/mesh computing, dew computing, mobile edge computing, cloud let, distributed data storage and retrieval, autonomic self-healing networks, remote cloud services, augmented and virtual reality, data caching, Internet of Things (massive connectivity and/or latency critical), critical communications (autono mous vehicles, traffic safety, real-time analytics, time-critical control, healthcare applications). Edge cloud may be brought into RAN by utilizing network function virtualization (NVF) and software defined networking (SDN). Using edge cloud may mean access node operations to be carried out, at least partly, in a server, host or node operationally coupled to a remote radio head or base station comprising radio parts. Network slicing allows multiple virtual networks to be created on top of a common shared physical infrastructure. The virtual networks are then custom ised to meet the specific needs of applications, services, devices, customers or op erators.

For 5G networks, it is envisaged that the architecture may be based on a so-called CU-DU (central unit - distributed unit) split, where one gNB-CU controls several gNB-DUs. The term 'gNB' may correspond in 5G to the eNB in LTE. The gNBs (one or more) may communicate with one or more UEs. The gNB-CU (central node) may control a plurality of spatially separated gNB-DUs, acting at least as trans mit/receive (Tx/Rx) nodes. In some embodiments, however, the gNB-DUs (also called DU) may comprise e.g. a radio link control (RLC), medium access control (MAC) layer and a physical (PHY) layer, whereas the gNB-CU (also called a CU) may comprise the layers above RLC layer, such as a packet data convergence protocol (PDCP) layer, a radio resource control (RRC) and an internet protocol (IP) layers. Other functional splits are possible too. It is considered that skilled person is famil iar with the OS1 model and the functionalities within each layer.

Some other technology advancements probably to be used are Soft ware-Defined Networking (SDN), Big Data, and all-IP, to mention only a few non limiting examples. For example, network slicing may be a form of virtual network architecture using the same principles behind software defined networking (SDN) and network functions virtualisation (NFV) in fixed networks. SDN and NFV may deliver greater network flexibility by allowing traditional network architectures to be partitioned into virtual elements that can be linked (also through software) . N et- work slicing allows multiple virtual networks to be created on top of a common shared physical infrastructure. The virtual networks are then customised to meet the specific needs of applications, services, devices, customers or operators.

The plurality of gNBs (access points/nodes), each comprising the CU and one or more DUs, may be connected to each other via the Xn interface over which the gNBs may negotiate. The gNBs may also be connected over next genera tion (NG) interfaces to a 5G core network (5GC), which may be a 5G equivalent for the core network of LTE. Such 5G CU-DU split architecture may be implemented using cloud/server so that the CU having higher layers locates in the cloud and the DU is closer to or comprises actual radio and antenna unit. There are similar plans ongoing for LTE/LTE-A/eLTE as well. When both eLTE and 5G will use similar ar chitecture in a same cloud hardware (HW), the next step may be to combine soft ware (SW) so that one common SW controls both radio access networks /technol ogies (RAN/RAT). This may allow then new ways to control radio resources of both RANs. Furthermore, it may be possible to have configurations where the full pro tocol stack is controlled by the same HW and handled by the same radio unit as the CU.

It should also be understood that the distribution of labour between core network operations and base station operations may differ from that of the LTE or even be non-existent. Some other technology advancements probably to be used are Big Data and all-IP, which may change the way networks are being con structed and managed. 5G (or new radio, NR) networks are being designed to sup port multiple hierarchies, where MEC servers can be placed between the core and the base station or nodeB (gNB). It should be appreciated that MEC can be applied in 4G networks as well.

NR may also utilize satellite communication to enhance or complement the coverage of 5G service, for example by providing backhauling. Possible use cases are providing service continuity for machine-to-machine (M2M) or Internet of Things (loT) devices or for passengers on board of vehicles, or ensuring service availability for critical communications, and future railway/maritime /aeronautical communications. Satellite communication may utilize geostationary earth orbit (GEO) satellite systems, but also low earth orbit (LEO) satellite systems, in partic ular mega-constellations (systems in which hundreds of (nano) satellites are de ployed). Each satellite in the mega-constellation may cover several satellite-ena bled network entities that create on-ground cells. The on-ground cells may be cre ated through an on-ground relay node or by a gNB located on-ground or in a satel lite.

The embodiments may be also applicable to narrow-band (NB) Inter- net-of-things (loT) systems which may enable a wide range of devices and services to be connected using cellular telecommunications bands. NB-loT is a narrowband radio technology designed for the Internet of Things (loT) and is one of technolo gies standardized by the 3rd Generation Partnership Project (3GPP). Other 3GPP loT technologies also suitable to implement the embodiments include machine type communication (MTC) and eMTC (enhanced Machine-Type Communication). NB-loT focuses specifically on low cost, long battery life, and enabling a large num ber of connected devices. The NB-loT technology is deployed "in-band" in spectrum allocated to Long Term Evolution (LTE) - using resource blocks within a normal LTE carrier, or in the unused resource blocks within a LTE carrier’s guard-band - or "standalone" for deployments in dedicated spectrum.

Figure 1 illustrates an example of a communication system to which em bodiments of the invention may be applied. The system may comprise a control node 110 providing a cell 100. Each cell may be, e.g., a macro cell, a micro cell, femto, or a pico cell, for example. In another point of view, the cell may define a coverage area or a service area of the access node 110. The control node 110 may be an evolved Node B (eNB) as in the LTE and LTE-A, ng-eNB as in eLTE, gNB of 5G, or any other apparatus capable of controlling radio communication and managing radio resources within a cell. The control node 110 may be called a base station, network node, or an access node.

The system may be a cellular communication system composed of a ra dio access network of access nodes, each controlling a respective cell or cells. The access node 110 may provide user equipment (UE) 120 (one or more UEs) with wireless access to other networks such as the Internet. The wireless access may comprise downlink (DL) communication from the control node 110 to the UE 120 and uplink (UL) communication from the UE 120 to the control node 110.

Additionally, one or more local area access nodes may be arranged such that a cell provided by the local area access node at least partially overlaps the cell 100 of the macro cell access node 110. The local area access node may provide wireless access within a sub-cell that may be comprised within a macro cell 100. Examples of the sub-cell may include a micro, pico and/or femto cell. Typically, the sub-cell provides a hot spot within a macro cell. The operation of the local area access node may be controlled by an access node under whose control area the sub cell is provided. In general, the control node may be likewise called a base station, network node, or an access node.

The term "terminal device" or "UE" refers to any end device that may be capable of wireless communication. By way of example rather than limitation, a terminal device may also be referred to as a communication device, user equipment (UE), a Subscriber Station (SS), a Portable Subscriber Station, a Mobile Station (MS), or an Access Terminal (AT). The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wire less local loop phones, a tablet, a wearable terminal device, a personal digital assis tant (PDA), portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback ap pliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), USB dongles, smart devices, wireless customer-premises equipment (CPE), an In ternet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a con sumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. In the following description, the terms "terminal device", "communication device", "terminal", "user equipment" and "UE" may be used interchangeably. In this application, the term "target device" may refer to any of the examples for the terminal device.

In the case of multiple access nodes in the communication network, the access nodes may be connected to each other with an interface. LTE specifications call such an interface as X2 interface. For IEEE 802.11 network (i.e. wireless local area network, WLAN, WiFi), a similar interface Xw may be provided between ac cess points. An interface between an eLTE access point and a 5G access point may be called Xn. Other communication methods between the access nodes may also be possible.

The access node 110 of the RAN may be further connected via another interface to a core network of the cellular communication system.

The LTE specifications specify the core network as an evolved packet core (EPC), and the core network may comprise a mobility management entity (MME) and a gateway node. The MME may handle mobility of terminal devices in a tracking area encompassing a plurality of cells and handle signalling connections between the terminal devices and the core network. The gateway node may handle data routing in the core network and to/from the terminal devices.

The 5G specifications specify the core network as a 5G core (5GC). This is shown in Figure 2. The core network may comprise an access and mobility man agement function (AMF), a session management function (SMF) and a user plane function (UPF), among others. The AMF may handle mobility of terminal devices in a tracking area encompassing a plurality of cells and handle signalling connections between the terminal devices and the core network. The SMF may handle selection and control of user plane connections for PDU sessions between the terminal de vices and the core network. The UPF may handle data routing in the core network and to/from the terminal devices.

Due to the increase of services which need the positioning information, the number of location requests is increasing and also its frequency. This will in crease significantly the amount of signaling, and in many cases, part of the signaling would be unnecessary due to the very consecutive location requests and the small variation of the assistance data. This is especially the case for massive or industrial loT (M2M/loT) scenarios where many devices use positioning services in a contin uous manner. As an example, in warehouse or factory scenarios, special low-cost single-purpose devices could be used for tracking of vehicles (like trolleys) for au tomated driving and logistics without human interaction. This can imply hundreds or thousands of devices in a spatially restricted area (indoor or outdoor) with sin gle or multiple base stations for coverage. In such a scenario, it may be inefficient to perform location request procedures for each device on a per-need basis, since there may be a continuous and permanent need for positioning data.

Also, in some use cases there can be strict requirements on latency for the first positioning estimate (i.e. Time to First Fix, TTFF). Such requirements are challenging to meet due to the configuration-related and/or measurement related signaling that is needed for determining a positioning estimate.

The existing location procedure for a location request transaction is de scribed in TS 38.305 Stage 2 functional specification of User Equipment (UE) posi tioning in NG-RAN, sections 5.1-5.2. There it is shown that the 5GC may comprise a location management function (LMF), as shown in Figure 2 with dotted lines. As one example, the AMF may receive a request for a location service associated with a particular target UE (e.g. UE 120) from another entity (e.g., such as an external client of Figure 2 or a Gateway Mobile Location Center, GMLC) or the AMF itself decides to initiate some location service on behalf of a particular target UE (e.g., for an IMS emergency call from the UE). The AMF may then send a location services request to the LMF. The LMF processes the location services request which may include transferring assistance data to the target UE to assist with UE-based and/or UE-assisted positioning and/or may include positioning of the target UE. The LMF then returns the result of the location service back to the AMF (e.g., a position esti mate for the UE. In the case of a location service requested by an entity other than the AMF (e.g., the GMLC), the AMF returns the location service result to this entity. The LMF may have access to information from RAN (e.g. to support Observed Time Difference Of Arrival, OTDOA, positioning method using e.g. downlink measure ments obtained by a target UE of signals from eNBs/gNBs and/or positioning ref erence signals (PRS).

The LMF manages the support of different location services for target UEs, including positioning of UEs and delivery of assistance data to UEs. The LMF may interact with the serving gNB or serving ng-eNB for a target UE in order to obtain position measurements for the UE, including uplink measurements made by an ng-eNB and downlink measurements made by the UE that were provided to an ng-eNB as part of other functions such as for support of handover.

The LMF may interact with a target UE in order to deliver assistance data if requested for a particular location service, or to obtain a location estimate if that was requested. For positioning of a target UE, the LMF may decide on the position methods to be used, based on factors that may include the location ser vices (LCS) client type, the required quality of services (QoS), UE positioning capa bilities, gNB positioning capabilities and/or positioning capabilities of other access nodes (e.g. ng-eNB). The LMF may then invoke these positioning methods in the UE, serving gNB and/or other access nodes. The positioning methods may yield a location estimate for UE-based position methods and/or positioning measure ments for UE-assisted and network-based position methods. The LMF may com bine all the received results and determine a single location estimate for the target UE (hybrid positioning). Additional information like accuracy of the location esti mate and velocity may also be determined.

The LCS request may provide a type of periodic or triggered location reporting being requested and associated parameters (attributes). For some cases, such as periodic location, the LCS Service Request may include the time interval between successive location reports, the total number of reports and may include location QoS. For area event reporting, the LCS Service Request may include details of the target area, whether the event to be reported is the UE being inside, entering into or leaving the target area, the duration of event reporting, the minimum and maximum time intervals between successive event reports, the maximum event sampling interval, whether location estimates shall be included in event reports, and whether only one location report is required or more than one. For motion event reporting, the LCS Service Request may include a threshold linear distance, the duration of event reporting, the minimum and maximum time intervals be tween successive event reports, the maximum event sampling interval, whether lo cation estimates shall be included in event reports (and associated location QoS), and whether only one location report is required or more than one.

One example of location request is deferred 5GC-MT-LR Procedure for Periodic, Triggered and UE Available Location Events. With a deferred location re quest, a location request is sent for a target UE (or group of target UEs) and expects to receive a response containing the indication of event occurrence and location information if requested for the target UE (or group of target UEs) at some future time (or times), which may be associated with specific events associated with the target UE (or group of target UEs). These location request may cause the location of the UE to be determined periodically, per a predetermined trigger (e.g. certain movement and/or motion of the UE), and/or when the UE is available. Especially periodic location determinations may cause significant signaling overhead.

However, there are drawbacks with the current manner. E.g. the exchange of assistance data required for the location estimation is just performed after there is a location request, which would increase the Time to First Fix (TTFF), and the assistance data related to one particular UE is stored in the central location management function (LMF) in the core network which increases the latency.

Therefore, there is need for efficient positioning/locating of devices. To at least partially tackle these drawbacks, there is proposed a positioning method and a device useable for e.g. RAN continuous positioning (RCP), where proactive positioning may be used.

The method may be performed by a radio access network (RAN) device, not part of the core network. It is considered that the RAN device (also called RAN node) is enhanced with location functionalities. These location functionalities may be comprised in a Location Management Component (RAN LMC or simply LMC) shown in Figure 2, wherein the LMC functions as part of the RAN, in order to pro vide at least some functionalities similar to a Location Management Function (LMF) of the core network depicted in TS 38.305 and discussed above, such as how the positioning of the target device is made. In some embodiments, the LMC replaces the need for LMF of core, as the RAN LMC handles these functionalities (hence LMF is shows with doted lines in Figure 2). However, in some embodiments, the LMF of the core is maintained as a central control unit for positioning purposes while the RAN LMC supports local positioning functions. The division of labour between the two may be configurable. In other words, the functionalities explained above in connection of LMF may be performed by the LMC as well.

The proposed positioning method may reduce the time to obtain the lo cation estimation (i.e., to reduce the latency) and optimize the amount of signaling as well as of location assistance information that needs to be exchanged. According to some embodiment, the triggering of the location session may be performed by the RAN node itself, prior to receiving any LCS request e.g. from an external client in form of mobile terminating location request (MT-LR), from a target device (such as the terminal device to be located) in form of e.g. mobile originated location re quest (MO-LR), or from the core (e.g. from the AMF) in form of network induced location request (Nl-LR), e.g. emergency call. The LMC may support any of the lo cation request types that are defined for an LMF, i.e. Nl-LR, MT-LR, immediate lo cation requests, and deferred location requests. In addition to the location request types defined for an LMF, the LMC may be able to support location service requests from functions internal to the RAN node, for purposes such as Radio Resource Man agement (RRM), Minimization of Drive Tests (MDT), etc. This type of location request can be called RAN Induced Location Request (Rl-LR). The LMC may effi ciently handle Rl-LR since the necessary operations are internal to the RAN and can therefore be handled locally, avoiding the additional latency and network interface signaling that would be incurred if Rl-LR was handled by the LMF. One possible use case is location determination of e.g. sensors.

In some embodiments, the RAN device, such as the LMC, may have ca pabilities for: receiving location service requests for a target UE from the serving AMF or from an internal function of the serving RAN node (e.g. RRM, MDT, etc.); decide on the position method (s) to be used; interact with other internal functions of the serving RAN node in order to e.g. obtain position measurements for the UE; interact with a target UE in order to e.g. deliver assistance data or to obtain a loca tion estimate; interact with neighboring RAN nodes in order to e.g. obtain position measurements for the UE or coordinate dynamic PRS configuration; calculate or verify the final location of the UE and provide it to the requesting entity or request ing internal function of the serving RAN node.

Figure 3 depicts an example method that is useable for such RCP. In an embodiment, the RAN device performing the method of Figure 3 is a gNB, a ng-eNB or the location management component (LMC), which can be but need not be co located with the access node 110 - LMC may be a separate RAN entity having wired or wireless connection to the gNB as shown in Figure 2, for example. In one exam ple, in case of split gNB, the LMC may be a function of the gNB-CU, possibly as part of gNB-CU-CP (gNB-central unit-control plane). Although applicable to many net works, we will in the following examples focus on NR, for the sake of simplicity.

As shown in Figure 3, the RAN device may in step 300 decide that a lo cation of the target device (such as a terminal device, e.g. sensor) is to be deter mined. In step 302, the RAN device may determine location of the target device. In step 304, after having determined the location of the target device, the RAN device may receive a location request. In step 306, the RAN device may respond to the location request by indicating the location of the target device. This may comprise indicating the location of the target device to the requester. As described, the loca tion request may come many different sources (such as the target device or AMF, to mention only a few) and correspondingly the responding of step 306 may be to different directions, depending on the requester.

According to the proposal, positioning measurements and other related procedures in RAN may be conducted continuously and proactively by the LMC of the RAN. This may mean that positioning measurements and corresponding location information are already available when a location request from a client (external, UE, network) is received. The time-to-first-fix (TTFF) is significantly re duced compared to serial invocation of measurement procedures triggered by lo cation request.

In an embodiment, the deciding of step 300 is performed before receiv ing any location requests (also called location service, LCS, requests). This may pro vide for proactive and efficient location feedback, upon an LCS request has been received.

In an embodiment, the deciding of step 300 is based on information as sociated with at least one of the following: target device registration, target device context setup, target device context modification. For example, the RAN device may receive this registration and/or context setup associated information, such as RCP assistance information (RCPAI), from the core network. In an embodiment, the in formation is received when initial UE context is established or modified for the tar get device, e.g. by use of NGAP messages such as INITIAL CONTEXT SETUP RE QUEST message or UE CONTEXT MODIFICATION REQUEST message. The "associ ated" may denote that the information is received in connection of target device registration, target device context setup and/or target device context modification.

In an embodiment, the deciding is based on information associated with at least one of the following: bearer context setup for the target device, bearer con text modification for the target device. For example, the network device may re ceive this bearer associated information, such as RCP assistance information (RCPAI), from the core network. In an embodiment, the information is received at the time a protocol data unit (PDU) session is established or modified, e.g. by use of NGAP messages such as PDU SESSION RESOURCE SETUP REQUEST message or PDU SESSION RESOURCE MODIFY REQUEST message. The "associated" may de note that the information is received in connection of bearer context setup for the target device and/or bearer context modification for the target device.

In an embodiment, the information is received from the core network, such as from AMF therein. In some other embodiments, the information is at least partially received from the target device (e.g. the UE 120).

In an embodiment, the information (such as RCPAI), regardless of how or when it is received, may indicate at least one of the following: target device type, target device subscription information, application type applied by the target de vice, device capability information regarding positioning, location profile indicator. The location profile indicator (LPI), also called positioning profile indicator) may be e.g. an index to one of potentially multiple location profiles configured to the RAN node, wherein each location profile defines specific attributes for the location determination. The location profile indicator may be specific to a particular target device, or it may be specific to a particular area, or it may be specific to the RAN node such that the RAN node applies the same LP1 for each target device under its coverage. The deciding of step 300 may then be based on at least one of these in formation elements. For example, the target device type may indicate that the de vice is a sensor, and there may be a rule to trigger the proactive location determi nation for each sensor in a predetermined area. As another example, the subscriber information of the target device may indicate that the device and/or the subscriber belongs to a group for which the proactive location determination is to be per formed. As yet one example, the application type used at the target device may be such that the device may benefit from proactive location determination. An exam ple application may be any application that may require continuous location deter mination such as automatic guided vehicles (AGVs), remote controlled UAVs, or ve hicle platoons. The location profile indicator may indicate that the proactive loca tion determination should be applied for a particular target device or area, for ex ample.

In an embodiment, the deciding is based on a flag in the information. Thus, it may be preconfigured that for a certain class of devices, such as movement and location sensors, activation of proactive positioning, such as the RCP, is needed. This may be indicated by a flag e.g. in subscription information for each device be longing to the group of certain type of devices. In some other embodiments, config uration of the proactive positioning via an Application Function is performed, for example by means of an inter-working function such as a Network Exposure Func tion (NEF) in the 5G core which configures activation of proactive positioning in the network based on input. One specific example could be maintenance of AGVs and other equipment in a factory where continuous positioning is temporarily dis abled.

In an embodiment, the deciding in step 300 is based on a preconfigured rule stored in the RAN device. For example, a local configuration may be stored in the RAN device defining that the location determination, such as RCP, may be per formed for all target devices in the area, e.g. in a private network. Another example of such rule is that the proactive location determination is performed for all certain type of target devices.

In an embodiment, determining the location of the target device in step 302 may be based on predefined attributes. These may be preconfigured and stored at the RAN device or may be configured locally in the RAN device.

In an alternative or additional embodiment, determining the location of the target device in step 302 is based on attributes indicated from core network as part of at least one of the following: target device registration, target device context setup, target device context modification, bearer context setup for the target de vice, bearer context modification for the target device. In an embodiment, the at tributes may be received from the core as a location profile indicator included in the RCPA1.

In an embodiment, the attributes define at least one of the following: time interval between target device positioning fixes for periodic reporting, an event trigger for event based reporting (such as certain type of traffic detected or movement detected), quality of service for the location determination (such as QoS class, e.g. best effort class or assured class, accuracy, response time), trigger event for measurement report such as A3 "Neighbor becomes offset better than serving", or any of the parameters/attributes mentioned in connection of LMF for periodic reporting, area event reporting, and motion event reporting.

In an embodiment, the RAN device may adapt attributes e.g. based on the target device type or the application being used at the target device. For exam ple, the rate at which position is being determined, measurements are being made, etc. may be modified dynamically.

In an embodiment, determining the location in step 302 is at least par tially based on target device positioning capabilities. Alternatively or in addition, RAN device positioning capabilities and/or positioning capabilities of other access nodes (e.g. gNBs or ng-eNBs) may affect how the determination is performed. These target device positioning capabilities may include e.g. information on does the target device support at least one of the following: PRS monitoring, Global Nav igation Satellite System (GNSS), Assisted GNSS (e.g. GNSSs supported (such as GPS, GLONASS, Galileo, Beidou, etc.) and assistance data supported, such as ionospheric model support], OTDOA (e.g. OTDOA mode, supported bands, max supported PRS bandwidth, PRS frequency hopping, etc.), enhanced cell ID (EC1D), such as E-C1D measurements supported by the target device and capabilities for angular methods such as Angle of Departure (AoD), Angle of Arrival (AoA) of the transmitted and/or received signal.

In order to perform the proactive positioning, such as RCP, and base the positioning at least partially on the target device capabilities, the RAN device may need to proactively acquire the target device positioning capabilities. In an embod iment, the target device positioning capabilities are received from the core network and/or from the target device.

In an example where target device positioning capabilities are received from the core network, these may be in an embodiment be indicated by core net work to the RAN device, e.g. as part of RCPA1, possibly before the RAN device places any positioning related requests, such as requests for the positioning capabilities, to the core network. In another embodiment, the RAN device asks for this infor mation. The target device positioning capabilities may be known to the core assum ing that information on target device capabilities is stored as part of subscription information in the core (possibly in a unified data management (UDM) entity) and is obtained and sent to the RAN device e.g. during target device registration or con text setup/modification. The target device may send positioning capabilities in a non-access stratum (NAS) message to the AMF e.g. during target device registra tion, and the core network (e.g. AMF, UDM, UDR (unified data repository)) may store it as part of the target device context, and then provide the same to the RAN device. To be noted that similar provision of any RCPA1 (described in the applica tion) from the core to the RAN may take place.

Alternatively or additionally, the target device positioning capabilities are received from the target device. For example, the target device may send posi tioning capabilities as part of Access Network (AN) parameters in a registration request to the RAN, which stores it as part of UE context. In yet one example, the target device may provide its positioning capabilities in a radio resource control (RRC) message to RAN, possibly based on RRC request from the RAN (e.g. from the gNB).

In an embodiment, the RAN device may provide an indication of the ex istence of location information of the target device to the target device. For exam ple, the target device may be notified by the RAN node via RRC that the RCP session is activated. Also deactivation of the proactive location determination may be indi cated to the target device by the RAN device, upon the RAN device triggering deac tivation of the RCP. While the RCP session is activated, the target device may re quest its own position (e.g. via RRC) directly from the RAN device (e.g. from LMC), instead of the core. This may reduce signaling and latency since core’s AMF is not involved, as would be the case for MO-LR. As a response to the request, the RAN device may provide location information of the target device to the target device.

As evident from various embodiments described, some benefits of the proposal may include reduced time-to-first-fix, possibly to a few milliseconds, and reduced latency for subsequent location requests due to elimination of core net work (AMF) in communication path. One benefit may also comprise that the RAN node is continuously aware of the location of the target device, which also helps in reducing latencies. Compared to existing positioning methods, the proactive deter mination of the target device’s location provides for reduced latencies and signal ing whenever a location request (also known as location service request) is re ceived by the RAN node or a need for providing target devices location is deter mined by the RAN node, as the location may be provided to the requesting entity substantially immediately, without negotiation with the core network. The benefits may realize even in case of a single location request, as well as for continuous po sitioning indication. E.g. some software applications run at the target device may benefit or even require constant or frequent and/or periodical location indication. Being able to provide such frequent location indication to the target device directly from the RAN instead of the core may reduce latencies and signaling overhead.

Figure 4 show a signaling flow example for proactive location determi nation (e.g. RCP) activation based on e.g. RCPAI during initial access. The entities performing the signaling flow diagram may be the target device (such as the UE 120), the RAN (such as the gNB 110 or LMC of RAN) and the core network (such as AMF of the core network).

In step 400 of Figure 4, an RRC connection setup is established. This may be done e.g. by means of random access (RA) procedure. Step 402 carries an UE message which may comprise a first uplink NAS message (e.g. Service Request) to trigger context setup to the AMF. Step 404 depicts an initial context setup re quest, enhanced with one or more of the following carried in the RCPAI embedded in the context setup request:

• UE authorization for RCP. AMF may obtain the "UE authorized for RCP" from UDM and store it in UE location context.

• Location service QoS requirements for RCP. In one option the lo cation service QoS requirement are stored in UDM, after receiv ing from the target device. In another option, the UE sends the location service QoS requirement in a NAS message to AMF.

• UE positioning capabilities, incl. supported positioning methods. In one option the location service QoS requirement are stored in UDM, after receiving from the target device. In another option, the UE sends the location service QoS requirement in a NAS message to AMF.

• Device type, subscription data, application type, etc. These may also be fetched from the UDM. In another option, the UE sends the location service QoS requirement in a NAS message to AMF.

In step 406, based on RCPA1 and a trigger (such as a local trigger, e.g. RI- RL) to start RCP, the RAN node decides whether to use RCP or not. According to the UE capabilities and the load, the RAN node may evaluate if any of the positioning methods (e.g. UE assistance and/or neighboring RAN node assistance) available is capable to provide the location estimation meeting the requirements received in the RCPA1, according to the current resource availability.

In step 408, if RCP is used as decided in Step 406, the RAN node may initiate positioning procedures for the target UE. The RAN node may additionally send a measurement configuration and/or an RCP usage indication, possibly to gether with location service QoS to the UE in an RRC Connection Reconfiguration message. For example, the RAN node may, for downlink positioning, trigger loca tion procedures with the UE.

Steps 410 depicts an RRC Reconfiguration Complete message from the UE to the RAN node. Step 412 shows that the RAN node indicates to the AMF in the Context Setup Response if RCP is used by RAN node.

After this, whenever a location request is received and regardless does the location request come from the UE, the core network (e.g. AMF), external client, or internally from the RAN, the location request may be responded substantially immediately reducing latencies.

Figure 5 shows a similar method to that shown in Figure 4. However, for Figure 5 the RCP is triggered only after a certain trigger for the positioning (such as Rl-LR) is met. The steps with the same reference numeral as in step 4 are iden tical. Step 500 of Figure 5 depicts RRC reconfiguration message without the RCP indication. This is because RCP has not yet been triggered by the RAN node. Also, the RAN node may in step 502 send a context setup response to the core network without RCP indication. Only after these, the RAN node may trigger RCP based on a local trigger (e.g. event based), for example, in step 406 of Figure 5. This is fol lowed by steps 408 and 410, as was the case for Figure 4. In step 504 of Figure 5, the RAN device sends location management information to the core network, wherein the information includes the RCP indication indicating that RCP has been triggered for this particular UE.

In an embodiment, the proactive location determination may also be applied in connection of handovers, or in connection of Conditional Handover. This may include the RAN device acting as a source node of the handover and detecting that a handover is needed. The source node may send information to at least one candidate target node, the information indicating that location determination may be applied for the target device that is to be handed over to the target node. This information may comprise the RCPAI, or parts of it. The information may be sent in a handover request message, for example. The target node where the UE is handed over can then determine whether to start the proactive location determi nation for the UE. This may be based on local triggers, preconfigured rules, etc.

In another embodiment in connection of handovers, the RAN device is comprised in the target node providing the target cell of the handover, and receive in connection of handover preparation information from a source node, the infor mation indicating that location determination may be applied for the target device that is to be handed over to the target node. The RAN device in the target node of the handover may then decide whether to start the proactive location determina tion for the UE. This may be based on local triggers, preconfigured rules, etc.

Figure 6 shows a method from the point of view of the target device, such as the UE 120 or any other terminal device (sensor devices, etc.). In step 600 the UE 120 may receive an indication from the RAN device (such as the gNB 110 or LMC) device that location information of the UE is available in the RAN device. This may take place before the UE 120 has any need for or has sent any location service requests. In step 602, the UE may decide to request location information from the RAN device. Such decision may be due to an application in the UE requesting loca tion data, for example. This may be possible because the UE has knowledge that the RAN device has determined the location of the UE. The UE need not ask the location from the core network, as the UE has knowledge that the RAN device has this in formation. This may reduce latencies and signaling. In step 604, the UE may receive the location information from the RAN device. In step 606, the UE may determine location of the UE at least partially based on the received location information. This may be useful in e.g. indoor scenarios where the use of GPS may be impossible.

Figure 7 shows a method from the point of view of the core network device, such as the AMF or LMF. The method may comprise, in step 700, receiving, from the target device (such as UE 120), information related to positioning of the target device. This information may be e.g. positioning capabilities of the target de vice, target device subscription information, application type applied by the target device, location profile indicator for the target device, for example. In step 702 the method may comprise providing, before receiving a positioning related request (e.g. from the RAN device), at least part of the information to a radio access network device responsible of triggering a location determination of the target device. Such proactive provisioning of the RCPA1 may reduce latencies and enable the RAN de vice to decide on activation of RCP and to locate the target device more efficiently.

An embodiment, as shown in Figure 8, provides an apparatus 10 com prising a control circuitry (CTRL) 12, such as at least one processor, and at least one memory 14 including a computer program code (PROG), wherein the at least one memory and the computer program code (PROG), are configured, with the at least one processor, to cause the apparatus to carry out any one of the above-de scribed processes. The memory may be implemented using any suitable data stor age technology, such as semiconductor based memory devices, flash memory, mag netic memory devices and systems, optical memory devices and systems, fixed memory and removable memory.

In an embodiment, the apparatus 10 may be or be comprised in a net work node, such as in gNB/gNB-CU/gNB-DU of 5G. In an embodiment, the appa ratus 10 is or is comprised in the network node 110. In an embodiment, the appa ratus 10 is or is comprised in LMC. In an embodiment, the apparatus 10 is or is comprised in ng-eNB. In an embodiment, the apparatus 10 may be or be comprised in a WLAN access point. The apparatus may be caused to execute the functionalities of some of the above described processes, such as the steps of Figures 3, 4 and 5.

It should be appreciated that future networks may utilize network func tions virtualization (NFV) which is a network architecture concept that proposes virtualizing network node functions into "building blocks" or entities that may be operationally connected or linked together to provide services. A virtualized net work function (VNF) may comprise one or more virtual machines running com puter program codes using standard or general type servers instead of customized hardware. Cloud computing or data storage may also be utilized. In radio commu nications, this may mean node operations to be carried out, at least partly, in a cen tral/centralized unit, CU, (e.g. server, host or node) operationally coupled to dis tributed unit, DU, (e.g. a radio head/node). It is also possible that node operations will be distributed among a plurality of servers, nodes or hosts. It should also be understood that the distribution of labour between core network operations and base station operations may vary depending on implementation.

In an embodiment, the proactive location determination may also be ap plied in connection of RRC state transition between high activity states (e.g. RECONNECTED) and low activity states (RRCJNACTIVE, RRCJDLE). For exam ple, this may include the RAN device detecting low user plane activity and config uring the UE with the RRC state transition to RRCJNACTIVE. The proactive location determination can be done before the UE is configured with RRC_ INACTIVE state and connection is suspended, or before transitioning the connection CM-CON- NECTED to CM-IDLE (Connection Management) and releasing the RRC connection to RRCJDLE.

In an embodiment, the server may generate a virtual network through which the server communicates with the radio node. In general, virtual networking may involve a process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network. Such virtual network may provide flexible distribution of operations be tween the server and the radio head/node. In practice, any digital signal processing task may be performed in either the CU or the DU and the boundary where the re sponsibility is shifted between the CU and the DU may be selected according to im plementation.

Therefore, in an embodiment, a CU-DU architecture is implemented. In such case the apparatus 10 may be comprised in a central unit (e.g. a control unit, an edge cloud server, a server) operatively coupled (e.g. via a wireless or wired network) to a distributed unit (e.g. a remote radio head/node). That is, the central unit (e.g. an edge cloud server) and the radio node may be stand-alone apparatuses communicating with each other via a radio path or via a wired connection. Alter natively, they may be in a same entity communicating via a wired connection, etc. The edge cloud or edge cloud server may serve a plurality of radio nodes or a radio access networks. In an embodiment, at least some of the described processes may be performed by the central unit. In another embodiment, the apparatus 50 may be instead comprised in the distributed unit, and at least some of the described pro cesses may be performed by the distributed unit.

In an embodiment, the execution of at least some of the functionalities of the apparatus 10 may be shared between two physically separate devices (DU and CU) forming one operational entity. Therefore, the apparatus may be seen to depict the operational entity comprising one or more physically separate devices for executing at least some of the described processes. In an embodiment, such CU- DU architecture may provide flexible distribution of operations between the CU and the DU. In practice, any digital signal processing task may be performed in ei ther the CU or the DU and the boundary where the responsibility is shifted between the CU and the DU may be selected according to implementation. In an embodi ment, the apparatus 10 controls the execution of the processes, regardless of the location of the apparatus and regardless of where the processes/functions are car ried out.

The apparatus may further comprise communication interface (TRX) 16 comprising hardware and/or software for realizing communication connectivity according to one or more communication protocols. The TRX may provide the ap paratus with communication capabilities to access the core network, the UEs or some other devices of the radio access network, for example. The apparatus may also comprise a user interface 18 comprising, for example, at least one keypad, a microphone, a touch display, a display, a speaker, etc. The user interface may be used to control the apparatus by the user.

The control circuitry 12 may comprise a positioning triggering circuitry 20 for deciding whether to trigger the proactive location determination, according to any of the embodiments. The control circuitry 12 may further comprise a loca tion determination circuitry 22 for determining the location of the target device, according to any of the embodiments.

An embodiment, as shown in Figure 9, provides an apparatus 50 com prising a control circuitry (CTRL) 52, such as at least one processor, and at least one memory 54 including a computer program code (PROG), wherein the at least one memory and the computer program code (PROG), are configured, with the at least one processor, to cause the apparatus to carry out any one of the above-de scribed processes. The memory may be implemented using any suitable data stor age technology, such as semiconductor-based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory.

In an embodiment, the apparatus 50 may comprise the terminal device of a communication system, e.g. a user terminal (UT), a computer (PC), a laptop, a tabloid computer, a cellular phone, a mobile phone, a communicator, a smart phone, a palm computer, sensors, moving robots, a mobile transportation appa ratus (such as a car), a household appliance, or any other communication appa ratus, commonly called as UE or target device in the description. Alternatively, the apparatus is comprised in such a terminal device. Further, the apparatus may be or comprise a module (to be attached to the UE) providing connectivity, such as a plug-in unit, an "USB dongle", or any other kind of unit. The unit may be installed either inside the UE or attached to the UE with a connector or even wirelessly. In an embodiment, the apparatus 50 is or is comprised in the UE 120. The apparatus may be caused to execute the functionalities of some of the above described processes, such as the steps of Figure 4, 5 and 6.

The apparatus may further comprise communication interface (TRX) 56 comprising hardware and/or software for realizing communication connectivity according to one or more communication protocols. The TRX may provide the ap paratus with communication capabilities to access the radio access network, for example. The apparatus may also comprise a user interface 58 comprising, for ex ample, at least one keypad, a microphone, a touch display, a display, a speaker, etc. The user interface may be used to control the apparatus by the user.

The control circuitry 52 may comprise a connection establishment cir cuitry 60 for establishing connection to the RAN, according to any of the embodi ments. The control circuitry 52 may further comprise a location determination cir cuitry 62 for determining the location of the target device (e.g. by asking from the RAN node), according to any of the embodiments.

An embodiment, as shown in Figure 10, provides an apparatus 80 com prising a control circuitry (CTRL) 82, such as at least one processor, and at least one memory 84 including a computer program code (PROG), wherein the at least one memory and the computer program code (PROG), are configured, with the at least one processor, to cause the apparatus to carry out any one of the above-de scribed processes. The memory may be implemented using any suitable data stor age technology, such as semiconductor-based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory.

In an embodiment, the apparatus 80 may comprise a core network de vice of a communication system, e.g. the AMF or LMF of the core. In an embodiment, the apparatus 80 is or is comprised in the AMF. The apparatus may be caused to execute the functionalities of some of the above described processes, such as the steps of Figure 4, 5 and 7.

The apparatus may further comprise communication interface (TRX) 86 comprising hardware and/or software for realizing communication connectivity according to one or more communication protocols. The TRX may provide the ap paratus with communication capabilities to access the radio access network or other devices of the core network, for example. The apparatus may also comprise a user interface 88 comprising, for example, at least one keypad, a microphone, a touch display, a display, a speaker, etc. The user interface may be used to control the apparatus by the user.

The control circuitry 82 may comprise a connection establishment cir cuitry 90 for establishing connection to the RAN and/or to the terminal device, ac cording to any of the embodiments. The control circuitry 82 may further comprise a positioning assistance circuitry 92 for assisting in a target device positioning, such as provisioning of the RCPAI to the RAN device, according to any of the em bodiments. The RCPAI may be stored in the memory 84, for example, or in some other core network entity with which the apparatus 80 has connection to.

In an embodiment, an apparatus carrying out at least some of the em bodiments described comprises at least one processor and at least one memory including a computer program code, wherein the at least one memory and the com puter program code are configured, with the at least one processor, to cause the apparatus to carry out the functionalities according to any one of the embodiments described. According to an aspect, when the at least one processor executes the computer program code, the computer program code causes the apparatus to carry out the functionalities according to any one of the embodiments described. Accord ing to another embodiment, the apparatus carrying out at least some of the embod iments comprises the at least one processor and at least one memory including a computer program code, wherein the at least one processor and the computer pro gram code perform at least some of the functionalities according to any one of the embodiments described. Accordingly, the at least one processor, the memory, and the computer program code form processing means for carrying out at least some of the embodiments described. According to yet another embodiment, the appa ratus carrying out at least some of the embodiments comprises a circuitry includ ing at least one processor and at least one memory including computer program code. When activated, the circuitry causes the apparatus to perform the at least some of the functionalities according to any one of the embodiments described.

As used in this application, the term 'circuitry' refers to all of the follow ing: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of circuits and software (and/or firmware), such as (as applicable): (i) a combination of processor(s) or (ii) portions of processor(s)/software including digital signal processor(s), software, and memory(ies) that work together to cause an apparatus to perform various functions, and (c) circuits, such as a microprocessor(s) or a portion of a micropro- cessor(s), that require software or firmware for operation, even if the software or firmware is not physically present. This definition of 'circuitry' applies to all uses of this term in this application. As a further example, as used in this application, the term 'circuitry' would also cover an implementation of merely a processor (or mul tiple processors) or a portion of a processor and its (or their) accompanying soft ware and/or firmware. The term 'circuitry' would also cover, for example and if applicable to the particular element, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in a server, a cellular network device, or another network device.

In an embodiment, at least some of the processes described may be car ried out by an apparatus comprising corresponding means for carrying out at least some of the described processes. Some example means for carrying out the pro cesses may include at least one of the following: detector, processor (including dual-core and multiple-core processors), digital signal processor, controller, re ceiver, transmitter, encoder, decoder, memory, RAM, ROM, software, firmware, dis play, user interface, display circuitry, user interface circuitry, user interface soft ware, display software, circuit, antenna, antenna circuitry, and circuitry.

The techniques and methods described herein may be implemented by various means. For example, these techniques may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or combinations thereof. For a hardware implementation, the appa ratus (es) of embodiments may be implemented within one or more application- specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programma ble gate arrays (FPGAs), processors, controllers, micro-controllers, microproces sors, other electronic units designed to perform the functions described herein, or a combination thereof. For firmware or software, the implementation can be car ried out through modules of at least one chip set (e.g. procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory unit and executed by processors. The memory unit may be imple mented within the processor or externally to the processor. In the latter case, it can be communicatively coupled to the processor via various means, as is known in the art. Additionally, the components of the systems described herein may be rear ranged and/or complemented by additional components in order to facilitate the achievements of the various aspects, etc., described with regard thereto, and they are not limited to the precise configurations set forth in the given figures, as will be appreciated by one skilled in the art.

Embodiments as described may also be carried out in the form of a computer process defined by a computer program or portions thereof. Embodi ments of the methods described may be carried out by executing at least one por tion of a computer program comprising corresponding instructions. The computer program may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, which may be any entity or device capable of carrying the program. For example, the computer program may be stored on a computer program distribution medium readable by a computer or a processor. The computer program medium may be, for example but not limited to, a record medium, computer memory, read-only memory, electrical carrier signal, telecommunications signal, and software distribution package, for example. The computer program medium may be a non-transitory medium. Coding of software for carrying out the embodiments as shown and described is well within the scope of a person of ordinary skill in the art.

Following is a list of some examples.

According to a first example, there is provided an apparatus, compris ing: at least one processor and at least one memory including a computer program code, wherein the at least one memory and the computer program code are config ured, with the at least one processor, to cause a radio access network device to perform operations comprising: decide that a location of a target device is to be determined; determine location of the target device; after having determined the location of the target device, receive a location request; respond to the location re quest with location information of the target device.

Various embodiments of the first example may comprise at least one feature from the following bulleted list:

• wherein the deciding is performed before receiving any location request.

• wherein the deciding is based on information associated with at least one of the following: target device registration, target de vice context setup, target device context modification.

• wherein the deciding is based on information associated with at least one of the following: bearer context setup for the target de vice, bearer context modification for the target device.

• wherein the information indicates at least one of the following: target device type, target device subscription information, appli cation type applied by the target device, location profile indica tor. • wherein the information indicates at least one of the following: target device type, target device subscription information, appli cation type applied by the target device, location profile indica tor.

• wherein the information indicates at least one of the following: target device type, target device subscription information, appli cation type applied by the target device, location profile indica tor.

• wherein the information is received from a core network.

• wherein the deciding is based on a flag in the information.

• wherein the deciding is based on a preconfigured rule stored in the radio access network device.

• wherein determining the location is based on predefined attrib utes or based on attributes indicated from core network as part of at least one of the following: target device registration, target device context setup, target device context modification, bearer context setup for the target device, bearer context modification for the target device.

• wherein determining the location is at least partially based on target device positioning capabilities, wherein the target device positioning capabilities are received from a core network or from the target device.

• provide an indication of existence of location information of the target device to the target device; receive the request from the target device, the request being for the location of the target de vice; provide, as a response to the request, location information to the target device.

• detect that a handover of the target device is to performed; send information to a target node, the information indicating that lo cation determination is to be applied for the target device that is to be handed over to the target node.

• wherein the radio access network device is a gNB, a ng-eNB or a location management component, LMC, within the radio access network.

According to a second example, there is provided an apparatus compris ing means for performing: deciding that a location of a target device is to be determined; determining location of the target device; after having determined the location of the target device, receiving a location request; responding to the loca tion request with location information of the target device. Various embodiments of the second example may comprise at least one feature from the bulleted list un der the first example.

According to a third example, there is provided a method, comprising: deciding that a location of a target device is to be determined; determining location of the target device; after having determined the location of the target device, re ceiving a location request; responding to the location request with location infor mation of the target device. Various embodiments of the third example may com prise at least one feature from the bulleted list under the first example.

According to a fourth example, there is provided a computer program product embodied on a distribution medium readable by a computer and compris ing program instructions which, when loaded into an apparatus, execute a method according the third example. Various embodiments of the third example may com prise at least one feature from the bulleted list under the first example.

According to a fifth example, there is provided an apparatus, compris ing: at least one processor and at least one memory including a computer program code, wherein the at least one memory and the computer program code are config ured, with the at least one processor, to cause a terminal device to perform opera tions comprising: receive an indication from a radio access network device that lo cation information of the terminal device is available in the radio access network device; request the location information from the radio access network device; re ceive the location information from the radio access network device; determine lo cation of the terminal device at least partially based on the received location infor mation.

According to a sixth example, there is provided an apparatus for a ter minal device, the apparatus comprising means for performing: receiving an indica tion from a radio access network device that location information of the terminal device is available in the radio access network device; requesting the location in formation from the radio access network device; receiving the location information from the radio access network device; determining location of the terminal device at least partially based on the received location information.

According to a seventh example, there is provided a method performed by a terminal device, the method comprising: receiving an indication from a radio access network device that location information of the terminal device is available in the radio access network device; requesting the location information from the radio access network device; receiving the location information from the radio ac cess network device; determining location of the terminal device at least partially based on the received location information.

According to an eight example, there is provided a computer program product embodied on a distribution medium readable by a computer and compris ing program instructions which, when loaded into an apparatus, execute a method according to the seventh example.

According to a ninth example, there is provided an apparatus, compris ing: at least one processor and at least one memory including a computer program code, wherein the at least one memory and the computer program code are config ured, with the at least one processor, to cause a core network device to perform operations comprising: receive, from a target device, information related to posi tioning of the target device; provide, before receiving a positioning related request, at least part of the information to a radio access network device responsible of trig gering a location determination of the target device.

According to a tenth example, there is provided an apparatus for a core network device, the apparatus comprising means for performing: receiving, from a target device, information related to positioning of the target device; providing, be fore receiving a positioning related request, at least part of the information to a radio access network device responsible of triggering a location determination of the target device.

According to an eleventh example, there is provided a method per formed by a core network device, the method comprising: receiving, from a target device, information related to positioning of the target device; providing, before receiving a positioning related request, at least part of the information to a radio access network device responsible of triggering a location determination of the tar get device.

According to a twelfth example, there is provided a computer program product embodied on a distribution medium readable by a computer and compris ing program instructions which, when loaded into an apparatus, execute a method according the eleventh example.

According to a thirteenth example, there is provided a computer system, comprising: one or more processors; at least one data storage, and one or more computer program instructions to be executed by the one or more processors in association with the at least one data storage for carrying out a method according to any of third, seventh or eleventh example.

Even though the invention has been described above with reference to an example according to the accompanying drawings, it is clear that the invention is not restricted thereto but can be modified in several ways within the scope of the appended claims. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment. It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be implemented in various ways. Further, it is clear to a person skilled in the art that the described embodiments may, but are not required to, be com- bined with other embodiments in various ways.

Claims

1. An apparatus, comprising: at least one processor and at least one memory including a computer program code, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause a radio access network device to perform operations comprising: decide that a location of a target device is to be determined; determine location of the target device; after having determined the location of the target device, receive a loca- tion request; respond to the location request with location information of the target device.

2. The apparatus of claim 1, wherein the deciding is performed before receiving any location request.

3. The apparatus of any of claims 1 to 2, wherein the deciding is based on information associated with at least one of the following: target device registra tion, target device context setup, target device context modification.

4. The apparatus of any of claims 1 to 3, wherein the deciding is based on information associated with at least one of the following: bearer context setup for the target device, bearer context modification for the target device.

5. The apparatus of any of claims 3 to 4, wherein the information indi cates at least one of the following: target device type, target device subscription information, application type applied by the target device, location profile indica tor.

6. The apparatus of any of claims 3 to 5, wherein the information is re ceived from a core network.

7. The apparatus of any of claims 3 to 6, wherein the deciding is based on a flag in the information.

8. The apparatus of any of claims 1 to 7, wherein the deciding is based on a preconfigured rule stored in the radio access network device.

9. The apparatus of any of claims 1 to 8, wherein determining the loca tion is based on predefined attributes or based on attributes indicated from core network as part of at least one of the following: target device registration, target device context setup, target device context modification, bearer context setup for the target device, bearer context modification for the target device.

10. The apparatus of any of claims 1 to 9, wherein determining the loca- tion is at least partially based on target device positioning capabilities, wherein the target device positioning capabilities are received from a core network or from the target device.

11. The apparatus of any of claims 1 to 10, wherein the at least one memory and the computer program code are configured, with the at least one pro cessor, to cause a radio access network device to perform operations comprising: provide an indication of existence of location information of the target device to the target device; receive the request from the target device, the request being for the lo- cation of the target device; provide, as a response to the request, location information to the target device.

12. The apparatus of any of claims 1 to 11, wherein the at least one memory and the computer program code are configured, with the at least one pro cessor, to cause a radio access network device to perform operations comprising: detect that a handover of the target device is to performed; send information to a target node, the information indicating that loca tion determination is to be applied for the target device that is to be handed over to the target node.

13. The apparatus of any of claims 1 to 12, wherein the radio access net work device is a gNB, a ng-eNB or a location management component, LMC, within the radio access network.

14. An apparatus for a radio access network device, the apparatus comprising means for performing: deciding that a location of a target device is to be determined; determining location of the target device; after having determined the location of the target device, receiving a lo- cation request; responding to the location request with location information of the tar get device.

15. A method performed by a radio access network device, the method comprising: deciding that a location of a target device is to be determined; determining location of the target device; after having determined the location of the target device, receiving a lo cation request; responding to the location request with location information of the tar get device.

16. A computer program product embodied on a distribution medium readable by a computer and comprising program instructions which, when loaded into an apparatus, execute a method according claim 15.

17. An apparatus, comprising: at least one processor and at least one memory including a computer program code, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause a terminal device to per form operations comprising: receive an indication from a radio access network device that location information of the terminal device is available in the radio access network device; request the location information from the radio access network device; receive the location information from the radio access network device; determine location of the terminal device at least partially based on the received location information.

18. An apparatus for a terminal device, the apparatus comprising means for performing: receiving an indication from a radio access network device that location information of the terminal device is available in the radio access network device; requesting the location information from the radio access network de vice; receiving the location information from the radio access network de vice; determining location of the terminal device at least partially based on the received location information.

19. A method performed by a terminal device, the method comprising: receiving an indication from a radio access network device that location information of the terminal device is available in the radio access network device; requesting the location information from the radio access network de vice; receiving the location information from the radio access network de vice; determining location of the terminal device at least partially based on the received location information.

20. A computer program product embodied on a distribution medium readable by a computer and comprising program instructions which, when loaded into an apparatus, execute a method according claim 19.

21. An apparatus, comprising: at least one processor and at least one memory including a computer program code, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause a core network device to perform operations comprising: receive, from a target device, information related to positioning of the target device; provide, before receiving a positioning related request, at least part of the information to a radio access network device responsible of triggering a loca tion determination of the target device.

22. An apparatus for a core network device, the apparatus comprising means for performing: receiving, from a target device, information related to positioning of the target device; providing, before receiving a positioning related request, at least part of the information to a radio access network device responsible of triggering a loca tion determination of the target device.

23. A method performed by a core network device, the method compris ing: receiving, from a target device, information related to positioning of the target device; providing, before receiving a positioning related request, at least part of the information to a radio access network device responsible of triggering a loca tion determination of the target device.

24. A computer program product embodied on a distribution medium readable by a computer and comprising program instructions which, when loaded into an apparatus, execute a method according claim 23.

25. A computer system, comprising: one or more processors; at least one data storage, and one or more computer program instructions to be executed by the one or more processors in association with the at least one data storage for carrying out a method according to any of claims 15, 19 or 23.