The problem set out above considers a MT-LR (Mobile Terminated Location Request), coming from a network function (AF or NF) or from an external LCS client as part of a commercial service. The default call flow for such MT-LR are depicted in Figure 6.1.2-1 of TS23.273 (not reproduced here, but incorporated by reference). In this, the call flow is depicted for a roaming service, with a Home GMLC (HGMLC) and a Visited GMLC (VGMLC) but can be easily interpreted for a non-roaming service, without this separation of the GMLC. If this specified call flow is applied to the above scenario of different zones, the LCS client could request a location service only for a single QoS value, assuming the current zone(s) of the device or the group of devices. Then the GMLC would carry out a privacy check with the UDM and also obtain the context information (including serving AMF) for the device(s). The GMLC will then orchestrate the AMF and onwards LMF to obtain the location information for the provided QoS level and check if the stated QoS levels are met in the provided positioning response. If so, the GMLC will then provide the LCS service response to the LCS client (or AF/NF). The LCS client (or AF/NF) will check the current location of the device(s) and when the required QoS level for this zone (if the zones are defined per area) is higher, will issue another location request with the higher QoS level. Generally, as the device(s) move from one zone to another, the LCS client (or AF/NF) will have to issue new location requests and the GMLC will have to execute the above call flow steps for each of the location requests. For obtaining continual location updates for a device(s) with low latency, this repetition of steps poses a significant barrier.

According to an embodiment of the present disclosure, depicted in call flow format in FIG. 2, the GMLC 50 is arranged to first accept a combined location service request (S1) from the LCS client 70 (or AF/NF) with multiple QoS. The combined request will contain the denomination of different zones and the relevant QoS levels needed for each zone. The GMLC 50 will contact (S2, S3) the UDM 60 and carry out a privacy verification for all the zones and QoS levels involved in the request.

The GMLC 50 will then select the correct AMF 30 to execute the request as per the current QoS level. The AMF 30 will drive the positioning steps through selecting a correct LMF 40 and the LMF 40 will configure the NG-RAN parameters to obtain the localisation with the required QoS (or even select another non-3GPP RAN if necessary). The results will be notified from LMF 40 to AMF 30 (S9) and then onwards (S10) to GMLC 50. At this stage the GMLC 50 will check the current location against the required QoS level and if this is met, the results will be notified to the LCS 70 client (S11).

If the QoS levels are not met, the GMLC 50 will perform another request (S12) to the AMF 30 to meet the QoS levels for the device's current zone. The GMLC 50 will continually check the QoS level against the reported (or indicated) zone for the device and will decide if to notify the LCS client 70 or make a new request to the AMF 30. In this way, the GMLC 50 is controlling the execution of the composite location request. As the number of call flow steps and the privacy checks are limited in this GMLC driven MT-LR solution, when compared to prior art solutions, the overall latencies for localization are reduced.

FIGS. 2 to 5 show call flows associated with different embodiments of the disclosure. The basic network topology is the same in each case, but the nature of the call flows differs. The numbering of the network elements is consistent and descriptions of the various entities (e.g. AMF 30, 130, 230, 330) is not necessarily repeated, for brevity.

A call flow associated with a first embodiment is presented in FIG. 2. It illustrates two positioning requests labelled “UE Positioning”, based on two zones for the device, but this can be easily extended to N number of requests and zones.

For very large IIoT networks with potentially thousands of devices, it may be feasible to employ two or more AMFs 30 which can cover different geographic areas of the network. In this scenario, especially if the above stated zones are defined as geographic areas (as opposed to time or density-based zones), the GMLC 50 can re-select the correct AMF 30 if a change in the zones occurs. Again, in this case, the GMLC 50 will only pass on the location notifications to the LCS 70 client if the correct QoS levels are met in the location result. If not, the GMLC 50 will re-issue a location request, with the possible change of the AMF 30. It is worth noting that, depending on the QoS levels and UE state, the AMF 30 can have the option to select non-3GPP access as well. For example, it is known that with Ultra Wideband (UWB) technology, localization accuracies in the range of 10 cm can be achieved, which is an enhancement from 3GPP based technologies. Also, if the UE is in (3GPP) idle state, the AMF 30 can select WiFi, for example, to do the positioning, which removes the need to bring the UE into the RRC-connected state.

In a second embodiment, the composite LCS request is orchestrated via the AMF. This embodiment is illustrated in FIG. 3.

The AMF 130 (and also the LMF 140) has the option to specify the radio access type used to derive the location information, as long as this access type is configured as a trusted, untrusted or wireline access type for the PLMN core and the UE 110 has indicated its capability to use this access type. A specific call flow is shown in FIG. 3, illustrating the steps in a 3GPP Access positioning operation (S22-S24) and a Non-3GPP Access positioning operation (S25-S26).

This embodiment is particularly useful when the non-3GPP technologies can provide better QoS in positioning than the 3GPP methods. For example, UWB technology is known to provide very high location accuracies (in the order of 10 cm) for short range communications.

In the Industry IoT scenario, for example, the positioning of articles on a conveyor belt would require such accuracies, while away from this arena, the accuracies provided by 3GPP techniques would suffice. The AMF 130 could execute the localisation by selecting different access technologies to meet the different QoS levels in this instance and instructing the LMF 140 to use the new access type and obtain the new QoS level. Alternatively, the AMF 130 could simply update the new QoS level requirement to the LMF 140 and the LMF 140 can select the appropriate access technology. The access type selection capability is already is known in the prior art.

A call flow diagram for the execution of this embodiment, with the option to select a non-3GPP access technology is shown in FIG. 4. Many of the calls/messages in this embodiment are the same as those shown in FIG. 2 and so commentary on these is omitted for brevity.

The composite localisation request comes from the LCS client 270 to the GMLC 250. The GMLC 250 selects the appropriate AMF capable of deriving the different QoS levels and sends the composite request (S34) as ‘Namf_Location_provide positioningInfo request’ to the AMF 230. The AMF makes a decision on the current zone for the UE 210 and selects an LMF 240 and the access type to derive the localisation to match the necessary QoS level for this zone.

In FIG. 4, the first “determine location” (S38) request to the LMF 240 is driven by 3GPP access. When the location response comes back (S39) from the LMF 240, the AMF 230 checks the QoS level and if this meets the requirements, the response is sent onwards (S40) to the GMLC 250 and to the LCS client 270 (S41). When the UE 210 moves on to the second zone, the AMF 230 detects this and can select an LMF 240 (can also be the LMF in the first instance) to derive the new QoS levels by localising through a new non-3GPP access mode. The LMF 240 drives this localisation process either through the N3IWF, TNGF or W-AGF functions 280. This could also include a UWB interworking function that could be adopted by 3GPP in the future. The AMF 230 again checks if the localisation response meets the new QoS level and if it does, the AMF 230 sends the response onwards to the GMLC 250 (S44) and then onwards to the LCS client 270 (S45).

As the decisions on the respective QoS levels and the LMF 240 and access mode are all made by the AMF 230, the number of messages needed to enact this solution is fewer than for the GMLC based solution shown in FIG. 2 and, hence, this can be executed even faster.

The AMF functionalities (as per the localisation service requests) are contained in TS 23.273, section 4.3.7, which includes:

“Functions which may be performed by an AMF to support location services include the following:

Receive and manage location requests from a GMLC for a 5GC-MT-LR and deferred 5GC-MT-LR for periodic, triggered and UE available location events.”

Therefore, if the GMLC additionally supports localization requests with multiple QoS levels as set out previously, this would imply that the AMF in turn will have to support this if the GMLC decides to forward this composite location request to the AMF. Therefore, provided that the additional functionality for the GMLC is enacted, the AMF does not need further specification updates to implement this functionality.

FIG. 5 shows a still further embodiment where, in an extension of the process shown in FIG. 4, the LMF 340 can also drive the composite LCS 370 request. The AMF 330 will forward (S57) the multiple QoS level localisation request to the LMF 340. The LMF 340 will decide on the access type and other RAN configuration parameters (if the access type is NG-RAN 320) and orchestrate the UE 310 positioning. When it receives the localization results, LMF 340 will check the QoS levels and if it matches to the given zone (for example a physical area) then it will forward (S58) the results to the AMF 330 and the AMF 330 will forward (S59) the results to GMLC 350 (and onwards to LCS client 370) (S60). If QoS levels are not met, the LMF 340 can reconfigure the RAN parameters or change the access type. When the LMF 340 detects that the QoS level needs changing, it can select another access type, such as WLAN or UWB access for very accurate positioning. If NG-RAN 320 is selected for access type, it will configure RAN parameters related to localization (like the PRS/SRS signal repetition rate, for example) to help meet the new QoS level. When the localization results are derived, it will again check the QoS levels and follow the same steps as above (S61-S63).

FIG. 6 is a flowchart which illustrates certain steps associated with the GMLC-driven embodiment shown in FIG. 2.

Flow starts at S70. At S71, the LCS client 70 sends a composite location service request to the GMLC 50. At S72. The GMLC 50 conducts a combined privacy check with the UDM 60 for all QoS zones (physical or otherwise) involved with the request.

At S73, a determination is made whether the devices in question have Location Privacy Information (LPI). If not, then at S74, the GMLC 50 notifies the client 70 and terminates the process, since it cannot continue with this determination.

Alternatively, flow continues to S75 where GMLC 50 obtains device context information from the UDM 60, which includes details of the serving AMF(s) 30.

At S76, the GMLC 50 selects the AMF 30 to execute the localisation service request with the relevant QoS.

At S77, the AMF 30 selects the LMF 40 to communicate through NG-RAN 20 and executes the positioning operation.

At S78, the LMF 40 executes the positioning operation and returns the location response to the AMF 30.

At S79, the AMF 30 reports the localisation response back to the GMLC 50 and the GML 50 analyses the response.

At 580, the GML determines if the relevant QoS level has been met. If not, flow passes to S81 where the GMLS re-sends the location request with the QoS level. This may be sent to a different AMF 30 to the previous one. Flow then passes to S77 again.

If at 580, the GMLC 50 determines that the relevant QoS level has been met, then, at S82, the GMLC 50 sends the LCS service response for the particular zone (N) to the LCS client 70.

At S83, the GMLS 50 continues to monitor the location response from the AMF 30 against the QoS levels.

By studying FIGS. 2 and 6 together, a complete impression of the operation of this embodiment of the disclosure can be obtained.

FIG. 7 is a flowchart which illustrates certain steps associated with the AMF-driven embodiment shown in FIG. 4.

Flow starts at 590. At 591, the LCS client 270 sends a composite location service request to the GMLC 250. At S92. The GMLC 250 conducts a combined privacy check with the UDM 260 for all QoS classes and associated zones (physical or otherwise) involved with the request.

At S93, a determination is made whether the devices in question have Location Privacy Information (LPI). If not, then at S94, the GMLC 250 notifies the client 270 and terminates the process, since it cannot continue with this determination.

Alternatively, flow continues to S95 where GMLC 250 obtains device context information from the UDM 260, which includes details of the serving AMF(s) 230.

At S96, the GMLC 250 selects the AMF 230 to execute the localisation service request with the relevant QoS.

At S97, the AMF 230 selects the LMF 240 to communicate through NG-RAN