Providing Location Services (LCS) to a UE or to other entities regarding one or more UEs is a cooperative effort amongst several Network Functions and service APIs in the 5GC as shown above. There are three types of requests used to initiate location reporting, and two modes in which they operate.
- Network Induced Location Requests (NI-LR) are initiated by an AMF to determine a UE’s location on behalf of a regulatory agency (e.g. to determine location during an IMS emergency call).
- Mobile Terminated Location Requests (MT-LR) are initiated by internal or external LCS clients and may be related to a service or application accessed by the UE, requests from regulatory agencies, or requests from the PLMN operator.
- Mobile Originated Location Requests (MO-LR) are initiated by the UE to determine its own location or to provide its location to an external client.
An LCS client initiating any of these requests may issue an Immediate Location Request if they require a response within a short period, and they may specify the required QoS. With an MT-LR, an LCS client can also subscribe to event-based or periodic location reporting by generating a Deferred Location Request.
Gateway Mobile Location Center (GMLC)
If the client is authorized to access location information, whether implicitly or explicitly, the GMLC uses the Nudm_UECM service to learn which AMF is serving the UE and then generates a location request towards that AMF using the Namf_Location service on the NL2 interface. In a roaming scenario, the LCS client interacts with the HGMLC which forwards authorized requests to the VGMLC using Ngmlc_Location on the NL3 interface (not shown), and the VGMLC interacts with the serving AMF, relaying the information back to the HGMLC.
The location service produced by the GMLC to interact with internal LCS clients includes the following operations:
- ProvideLocation — Enables an HGMLC or an NEF to initiate an MT-LR for immediate location reporting or for deferred location reporting, including the parameters that define the positioning and reporting criteria. In a successful response the GMLC will provide any location information available.
- LocationUpdate — AMFs use this operation to notify the GMLC of a UE’s location during an MO-LR process if the UE is providing its location to an external LCS client. This operation triggers the HGMLC to provide the location information to the LCS client, and it triggers the VGMLC to provide the location information to the HGMLC that is interacting with the LCS client.
- CancelLocation — The initiator of a ProvideLocation for MT-LR deferred location reporting uses this operation to cancel the reporting.
- EventNotify — GMLCs generate event notifications when indicated towards the callback URI provided in the ProvideLocation request for MT-LR deferred reporting.
- LocationUpdateNotify — Upon receipt of a LocationUpdate, a GMLC uses this operation to notify an NEF of new location information during an MO-LR process.
Location Management Function (LMF)
The LMF manages the resources and timing of positioning activities, and it exposes the Nlmf_Location service to the AMF for immediate or deferred location information requests on the NL1 interface. An LMF uses the Namf_Communication service on the NL1 interface to request UE positioning from the access network over N2, or to communicate with the UE over N1 for UE-based or UE-assisted positioning. It may also request estimated movement — velocity and direction — or estimate the accuracy of the location information when requested.
The LMF’s location service provides the following operations:
- DetermineLocation — An AMF uses this operation to request an immediate location report, or to request deferred periodic or event-triggered location reporting for a target UE. When the ultimate consumer of deferred reporting is a GMLC the AMF will provide the GMLC’s URI in the request, thereby enabling the LMF to send notifications directly to it.
- EventNotify — The LMF uses this operation to provide periodic or event-triggered location reports to the consumer.
- CancelLocation — AMFs use this operation to cancel deferred reporting.
- LocationContextTransfer — When an AMF selects a new LMF to complete or carry on location reporting the new LMF uses this operation to obtain the location context from the old LMF.
LMFs also produce the Nlmf_Broadcast service with a CipheringKeyData operation that provides AMFs with ciphering keys and parameters related to location assistance data that is broadcast to UEs in encrypted form.
Access and Mobility Management Function (AMF)
AMFs provide location information related to call processing or policy and charging to NFs in the 5GC, and to NEFs requesting deferred location reporting on behalf of AFs, through its EventExposure service. With its Namf_Location service an AMF provides location services to the NFs involved in location reporting destined for a consumer external to the 5GC — the UE or an external LCS client.
AMFs receive and manage location requests from several sources: MO-LRs from the UE over N1, requests for the Network Provided Location Information (NPLI) for a UE from a UDM over the N8 interface, and MT-LRs from GMLCs over the NL2 interface. The AMF selects the LMF that is best suited to perform the location determination for each request and uses its Nlmf_Location service to trigger that process. When necessary, due to UE mobility or network conditions, an AMF may determine that another LMF is better suited to complete a location determination or to continue deferred reporting. In that case it indicates to the new LMF that it should obtain the UE’s location context from the old LMF.
AMFs also receive location privacy requirements from UEs and update that information in the UDM/UDR using Nudm_SDM over the N8 interface.
The Namf_Location service provides the following operations:
- ProvidePositioningInfo — GMLCs use this operation to request the geodetic, and optionally civic, location of a UE, triggering the AMF to invoke Nlmf_Location. They may request immediate location reports or subscribe to periodic or event-triggered deferred location reporting.
- EventNotify — The AMF uses this operation to notify the subscribed GMLC of UE location events.
- ProvideLocationInfo — UDMs use this operation to obtain the NPLI of a UE.
- CancelLocation — A subscribed GMLC uses this operation to cancel its subscription and the associated reporting.
Network Exposure Function (NEF)
NEFs serve as location proxies to internal and external AFs in the same way GMLCs serve as proxies to external LCS clients. When an AF subscribes to UE mobility events via Nnef_EventExposure the NEF determines how the request can best be satisfied. If the specified QoS requirements indicate an Immediate Location Request the NEF initiates an MT-LR with a GMLC using Ngmlc_Location. If a Deferred Location Request is indicated the NEF, after first authorizing a request from an external AF using Nudm_SDM, subscribes to UE location events through Namf_EventExposure. In both cases the NEF relays the information received to the AF with Event Notifications.
Test the capacity and performance of your LMF with our AMF emulators. Generate different types of DetermineLocation requests towards the LMF DUT, increasing the volume to find maximum capacity, and/or test performance and stability with long-duration soak tests.
Use our LMF emulator to provide Nlmf_Location services in your lab. It will provide the location reporting requested based on the location profiles configured in the subscriber database.
Test your AMF’s location service by surrounding it with our GMLC, LMF, and gNodeB emulators.
- Initiate MT-LRs from the GMLCs
- Initiate MO-LRs from the gNodeBs
- LMF emulator provides Nlmf_Location reporting
See our Namf Service-Based Interface page for more comprehensive AMF testing.
As with all dsTest products, the node configurations and test scenarios are easily defined and configured with XML files that are validated against a published XML Schema to avoid invalid definitions. With our dsClient Desktop application you can create, run, and archive tests; capture, graph and archive operational measurements; capture real-time data flows and subscriber events; and manage your dsTest platforms and testing scenarios with a standalone application that runs on your PC.
Advanced Testing Features
SmartEvents — Alter application behavior or coordinate multiple interface applications with SmartEvents — our programmable, subscriber-level state machine. All dsTest applications are event-driven, enabling you to easily alter subscribers’ activities. Use our visual composer to draw your state machine and to trace a single subscriber’s path through the state machine while the test is running. Define event handlers that affect a subscriber’s behavior in an application, or that trigger an event in another application. You can also configure event handlers to modify subscriber information during run-time, introduce timers, or randomize subscriber behavior based on configurable probabilities to name just a few of the many options in one of dsTest’s most powerful features.
SmartMessageElement — Insert, delete, or replace elements in Diameter, RADIUS, MAP, LDAP, GTP, REST, or SOAP messages with our SmartMessageElement feature. Define proprietary signaling or corrupt elements to facilitate negative testing. You can specify when your elements are used with SmartEvents.
Traffic Profile — Draw the shape of your test actions across time with Traffic Profile. You can define the rate for any action as a static rate or reference a Traffic Profile configuration, which also means that multiple Traffic Profiles can be running concurrently. Use Traffic Profile in conjunction with the randomizing features in SmartEvents to design a test that more truly simulates real-world network activity.
REST Dictionary — Add conformance testing to your performance or functional test with our REST Dictionary. You can validate message types and JSON structures by simply including our base dictionary. You can also build custom dictionaries to explicitly define required parameter and property values and selectively include the dictionary to be used for a particular test.
dsTest provides rich sets of measurements for all interface applications:
- Transaction and transport layer attempts, successes, and failures
- Transaction duration, transactions-per-second, and round-trip delay
- Message and byte counters
- Errors encountered and error indications received in messages