LTE LPP (LTE Positioning Protocol)

This tutorial is to show how to configure and test LPP. LPP stands for LTE Positioning Protocol and it is a mechanism to facilitate the exchange of positioning information between the mobile device and the network. Conceptually in terms of the purpose LPP is similar to SUPL(Secure User Plane Location). Main differences from SUPL would be

LPP can be associated not only with GPS but also with other system like GLONASS, Galileo, and QZSS etc whereas SUPL is mainly associated with GPS
LPP support the information exchange not only via U-plane but also via C-Plane whereas SUPL supports U-Plane only.
LPP is supported in LTE and NR, whereas SUPL is supported in 3G/4G.

LTE LPP Overview 01

NOTE :Currently there are a couple of limitation in Amarisoft LPP

Only C-Plane LPP is supported (U-Plane LPP is not supported)
LCS Server (SLP, E-SMLC) is not supported by Amarisoft. Instead we provide a feature to generate location request and process the response by internal test function. (NOTE : If you have your own LCS server, it can be connected to Amarisoft LPP functionality)

NOTE : LPP is supported since the release 2024-02-20

LTE LPP (LTE Positioning Protocol)

Introduction
Summary of the Tutorial
Test Setup

Setup A
Setup B

Key Configuration Parameters
Test 1 : Auto Configuration - ECID

Configuration
Perform the test
Log Analysis

Test 2 : Manual Configuration

Configuration
Perform the test
Log Analysis

RRC / NAS Signaling

Downlink generic NAS transport /(LTE Positioning Protocol (LPP) message)
Uplink generic NAS transport /(LTE Positioning Protocol (LPP) message)

Introduction

The LTE Positioning Protocol (LPP) is a standardized mechanism designed to enable accurate location determination in advanced mobile networks, including LTE and 5G NR. Functioning as a control-plane protocol, LPP facilitates the exchange of positioning information between User Equipment (UE) and the network's location services infrastructure, such as the Evolved Serving Mobile Location Center (E-SMLC) or Secure Location Platform (SLP). Unlike legacy protocols like SUPL (Secure User Plane Location), which primarily rely on user-plane signaling and are focused on GPS, LPP is architected to support a diverse array of Global Navigation Satellite Systems (GNSS) including GPS, GLONASS, Galileo, and QZSS. LPP's architecture enables both control-plane and user-plane operation modes, though implementation support may vary between platforms. Its modular message structure allows the protocol to carry assistance data, measurement reporting, and location information efficiently and securely. LPP plays a pivotal role in enabling location-based services (LBS) and regulatory features such as emergency call positioning, and it is integral to modern mobile ecosystems where accurate and reliable location data is mission-critical. As mobile networks evolve to support higher positioning accuracy and expanded GNSS capabilities, LPPā€™s flexible framework ensures extensibility and interoperability across different radio access technologies and network deployments.

Context and Scope
- LPP is a 3GPP-defined protocol supporting advanced location-based services in LTE and 5G NR networks.
- It operates primarily in the control plane, enabling robust and secure information exchange between mobile devices and network-side location services servers.
- This tutorial focuses on the configuration and testing of LPP, specifically within the Amarisoft software environment, highlighting protocol features, limitations, and real-world application scenarios.
Relevance and Importance
- LPP enhances the accuracy, reliability, and flexibility of positioning in mobile networks, supporting regulatory requirements and commercial LBS applications.
- The protocolā€™s support for multiple GNSS systems and dual-plane operation (control and user plane) makes it essential for operators and developers targeting next-generation mobile services.
- Understanding LPP is critical for engineers working on network deployment, device integration, and service development where location is a key differentiator.
Learning Outcomes
- Gain a solid understanding of LPPā€™s role and operation within LTE and 5G environments.
- Learn how to configure and test LPP features using Amarisoftā€™s platform, including generating and processing location requests.
- Identify current limitations in LPP implementations and understand integration points for external LCS servers.
- Develop the ability to troubleshoot and extend positioning solutions for advanced mobile networks.
Prerequisite Knowledge
- Familiarity with LTE/5G network architecture and components (e.g., eNodeB, gNodeB, EPC, 5GC)
- Basic understanding of mobile positioning concepts and GNSS technologies
- Experience with network protocol configuration and test procedures
- Exposure to Amarisoft or similar mobile network testing environments is beneficial but not mandatory

Summary of the Tutorial

This tutorial covers procedures for testing LTE LPP (LTE Positioning Protocol) ECID (Enhanced Cell-ID) positioning using both auto and manual configuration methods. The tests are designed for setups using either a commercial UE or Amarisoft UEsim as the Device Under Test (DUT). Two main test scenarios are described: Auto Configuration - ECID and Manual Configuration. The overall methodology includes configuration steps, test execution, and log analysis to validate LPP-based positioning functionality.

Test Setup
- Two test setups are provided:
  - Setup A: Using a commercial UE as DUT.
  - Setup B: Using Amarisoft UEsim as DUT.
- SIM card provided with the system is used for all tests.
- Configuration changes can be referenced from the Configuration Guide if needed.

Key Configuration Parameters
- Critical parameters include nl1, lcs, and local_e_smlc blocks in the configuration files.
- Parameters such as api_root, transaction_timeout, server_bind_addr, and others under each block are highlighted as important for LPP/LCS functionality.
- Assistance data for OTDOA and NR-TDOA are referenced, though not detailed exhaustively in the steps.

Test 1: Auto Configuration - ECID
- Objective: Demonstrate LPP in LTE with minimal manual configurationā€most parameters are auto-configured by the LTE stack.
- Configuration Steps:
  - Use default configuration files (enb.default-lpp.cfg for eNB/gNB, mme-ims-lte-lpp-auto.cfg for MME, ue-lpp.cfg for UEsim) with minimal or no modification.
  - Ensure FDD mode and 5MHz bandwidth are set; dl_earfcn matches the desired LTE band (e.g., Band 7).
  - In MME configuration, enable autonomous_mode: true in local_e_smlc block; set basic identity parameters (e.g., plmn, enb_id).
  - On UEsim, ground position origin must be configured for GNSS responses; otherwise, GNSS report requests will result in errors.
- Test Execution:
  - Verify cell configurations using cell phy and cell commands.
  - On the MME, check LCS connection status with the lcs command (should be state=connected).
  - Power on the UE (UEsim).
  - Ensure initial attach completes successfully.
  - Trigger a location request via Remote API:
- Log Analysis:
  - Confirm successful LCSAP connection before triggering LPP measurement.
  - Trace the end-to-end procedure: Location request, LPP capability exchange, measurement configuration, reporting, and final location estimate.
  - Key aspects include validation of capability negotiation, measurement initiation, and location result reporting.

Test 2: Manual Configuration
- Objective: Execute LTE LPP positioning with explicit, manual configuration of e-SMLC and measurement parameters for greater control and repeatability.
- Configuration Steps:
  - Use enb.default.cfg for eNB/gNB, mme-ims-lte-lpp.cfg for MME, and ue.default.cfg for UEsim as the starting point.
  - In mme-ims-lte-lpp.cfg, configure local_e_smlc block: set lpp_test: true, e_smlc_id, periodic_meas, meas_period, meas_id, and otdoa_assistance_data as required (format varies depending on software release).
  - On UEsim, set ground_position_at_origin for GNSS, and ensure dl_earfcn matches eNB configuration.
- Test Execution:
  - Check cell configuration using cell phy and cell commands.
  - Ensure LCSAP is connected on the MME before powering on the UE.
  - Power on the UE (UEsim) and confirm attach completion.
  - Send a location request using:
  - After receiving the response, send location report requests for specific positioning methods (e.g., ECID, GNSS)
- Log Analysis:
  - Correlate user actions (e.g., service launch, API command execution) with LCSAP log entries.
  - Observe the signaling flow: Location Request, LPP request/provide capabilities, measurement reporting, and acknowledgements.
  - Separate analysis for ECID and GNSS procedures, ensuring that the signaling trace reflects your manual settings and the expected workflow.

General Methodology Notes:

Both tests emphasize the need for matching cell parameters (e.g., dl_earfcn, bandwidth) across eNB/gNB and UEsim for successful signaling and measurement exchange.
Manual configuration allows for explicit control of positioning method selection, reporting intervals, and assistance data, beneficial for debugging or deterministic testing.
Remote API commands are used for triggering location procedures and requesting measurement reports; responses should be monitored for completeness and correctness within the allowed session timeframes.
Log analysis is essential for verifying the step-by-step signaling, ensuring that each phase of LPP/ECID positioning (from attach to final location reporting) is executed as expected.

Test Setup

Test setup for this tutorial is as shown below.

SIM Card used in this tutorial is the one delivered with the system as it is.
If you want to change the configuration, The tutorial Configuration Guide would help

Setup A

This is the setup where you use a commercial UE as DUT.

TestSetup Callbox UE 1sdr 01

Setup B

This is the setup where you use a commercial Amarisoft UEsim as DUT.

TestSetup Callbox UEsim 1sdr 01

Key Configuration Parameters

Followings are important configuration parameters for this tutorial. You may click on the items for the descriptions from Amarisoft documents.

local_e_smlc

earfcn
pci

nr_tdoa_assistance_data

pointA_arfcn
cells

arfcn
pci

Test 1 : Auto Configuration - ECID

This is to show how to configure and verify LPP in LTE with auto configuration, where you set very minimal configuration and all the other details are automatically configured by lte software. The goal is to keep the setup as small as possible. You only set the few mandatory parameters to enable positioning. Then the LTE stack automatically fills in the remaining details. This feature is supported only by recent release (Feb 2026 or later is recommended).

Configuration

I have used enb.default-lpp.cfg on Callbox (gNB) as it is without any modification.

LTE LPP Test1 Configuration 01

I am using the mme-ims-lte-lpp-auto.cfg which is copied and modified from mme-ims.cfg

LTE LPP Test1 Configuration 02

I have used enb.default-lpp.cfg on UEsim as it is without any modification.

LTE LPP Test1 Configuration 03

For eNB configuration, enb.default-lpp.cfg is configured as follows.

Here FDD is used and Bandwidth is set to 5Mhz (N_RB_DL 25)

LTE LPP Test1 Configuration 04

Specify dl_earfcn as you want. A band 7 freuency is used in this test.

LTE LPP Test1 Configuration 05

For the measurement like ECID, measurement configuration should be specified

In mme-ims-lte-lpp-auto.cfg , the e-SMLC configuration is specified. It is configured by the parameter local_e_smlc. In this test, the auto configuration is used that requires the minimum set of configuration. You define how the built-in e-SMLC behaves through the local_e_smlc block. The key point of this test is that you enable auto configuration, so you only provide the minimum identity information that the LTE stack needs, and then the software derives the rest of the LPP/LCS behavior automatically. autonomous_mode: true is the switch that tells the Amarisoft stack to run the e-SMLC logic with auto-generated defaults. The enb sub-block gives the identity that must be consistent with your LTE network, such as plmn: "00101", enb_type: "macro", and enb_id: 0x1A2D0

LTE LPP Test1 Configuration 06

NOTE : The otdoa_assistance_data parameter format is based on the early release. In later release, you can just comment this parameter out for auto configuration. Or you can configure it with an asn file (Refer to this example for the asn template)

In ue-lpp.cfg , I didn't configure any specific parameter. I just used the default LTE configuration on UEsim as it is.

FDD is used and bandwidth is set to 5 Mhz (CELL_BANDWIDTH 5).

LTE LPP Test1 Configuration 07

Configure ground_position_at_origin in cell_groups. This is required for the UEsim to respond to lpp_location_request for gnss. If you don't configure this, UEsim will send Error message in NAS when it is requested with GNSS report.

LTE LPP Test1 Configuration 07 01

Cell frequency is set to be same as eNB configuration (Band 7) by dl_earfcn.

LTE LPP Test1 Configuration 08

UE configuration in ue_list is also used as in the default configuration.

LTE LPP Test1 Configuration 09

Perform the test

Check out the cell configuration with the command 'cell phy and cell' command, and confirm that they are configured as intended.

LTE LPP Test1 Run 01

Switch to (mme) screen and run 'lcs' command. Make it sure that the LCS connection state is 'state=connected'.

LTE LPP Test1 Run 02

Power on a UE in UEsim

Make it sure that the initial attach is completed properly.

LTE LPP Test1 Run 02 02

On Callbox, send the remote API command to send location requation message to UE. Go to /root/mme directory on Callbox and run following Remote API command.

./ws.js mme '{"message": "location_req","imsi": "001010123456789","imei": "01234567000001","session_id": 1,"plmn": "00101","cell_id": 0x1A2D001,"type": "geographic"}'

[root@CBC-2023010100 mme]# ./ws.js mme '{"message": "location_req","imsi": "001010123456789","imei": "01234567000001","session_id": 1,"plmn": "00101","cell_id": 0x1A2D001,"type": "geographic"}'

[0.003] ### Connected to 127.0.0.1:9000

[0.003] ### Ready: name=MME, type=MME, version=2026-02-06

[0.023] <== Send message location_req id#1

[0.044] ==> Message received

{

"message": "location_req",

"message_id": "id#1",

"time": 48.569,

"utc": 1707145581.655

}

Log Analysis

Sample Log

This log is shown before you trigger any LPP measurement, and it only confirms that the e-SMLC side is connected to the Core Network over LCSAP. In the LCSAP layer you see the connection setup toward the Core Network address, and then the Connected status, so it tells you the transport path for location services signaling is ready. At this stage there is no LPP transaction yet, no requestCapabilities, and no RequestLocationInformation, so you should treat this as a prerequisite connectivity check between the e-SMLC function and the MME/Core Network.

If you trigger LPP measurement by the remote API ./ws.js mme '{"message": "location_req","imsi": "001010123456789","imei": "01234567000001","session_id": 1,"plmn": "00101","cell_id": 0x1A2D001,"type": "geographic"}'. You will get a long sequence of transactions as shown below.

First, the Core Network allocates the location context and creates the LCSAP session toward the e-SMLC. Then the e-SMLC starts LPP capability exchange to learn whether the UE supports A-GNSS, OTDOA, and E-CID. The LPP payloads are tunneled through the MME and delivered to the UE via NAS generic NAS transport with the generic message container type=1. Based on the capability results and available assistance data, the network may attempt OTDOA, and if it fails or is not usable it proceeds with E-CID measurement initiation. The UE then reports measurements such as RSRP/RSRQ and Rx-Tx time difference, and the positioning side computes the estimate. Finally, you see the Location Response on LCSAP, which carries the completed coordinate estimate back to the requester, and the related transactions are acknowledged and closed.

In this Attach request, the UE is advertising its positioning support through the UE network capability IE. In the hex-decoded capability line you can see LPP=1, which means the UE declares it supports LTE Positioning Protocol (LPP). This is an early I am LPP-capable indication to the MME, so the core network knows it is allowed to deliver LPP payloads later using Generic NAS transport with Generic message container type=1. This is not the detailed capability handshake yet. The detailed method-level profile (A-GNSS/OTDOA/E-CID modes, bands, coordinate types) is still learned later through the actual LPP requestCapabilities / provideCapabilities exchange.

This RRCConnectionReconfiguration is where the eNB pushes the measurement configuration (measConfig) down to the UE, so the UE knows what to measure and how to report it. In the highlighted part you can see a measObject being created for E-UTRA with an ARFCN (earfcn 3350) and a neighbor-cell configuration, which tells the UE what carrier/cell context the measurements belong to. You also see a quantityConfig / quantityConfigEUTRA, which defines what measurement quantities are relevant for that object, so the UE can later produce results like RSRP/RSRQ (and, when enabled, timing-related items such as Rx-Tx time difference) in its MeasurementReport. The key point is that this message is the setup step that enables all the measurement reporting used later by the positioning flow, including the E-CID snapshot that gets copied into LPP provideLocationInformation.

The message underlined in red is the LCS-AP Location Request. This is the "Command" message sent from the MME to the E-SMLC (Location Server) to initiate the positioning process for a specific UE. This message tells the E-SMLC why the location is needed and what kind of accuracy is required. It acts as the master trigger for all the LPPa and LPP sub-messages you see following it in the trace.

The message is the LPPa: e-CID Measurement Initiation Request. The e-CID (Enhanced Cell-ID) method is the network's secondary positioning strategy. While OTDOA (which failed earlier in your trace) relies on the UE measuring multiple base stations, e-CID asks the serving base station to report specific radio parameters it already knows about the UE. It is faster and more reliable in poor signal conditions, though generally less accurate than GPS or OTDOA.

timingAdvanceType1/timingAdvanceType2 gives the UE-to-eNodeB range estimate because it reflects the propagation delay. angleOfArrival (AoA) gives the bearing when the antenna supports it, so combining AoA with Timing Advance turns a distance circle into a more specific position. rSRP and rSRQ provide received power and quality, so E-SMLC uses them to refine the distance estimate using path-loss consistency. id-ReportCharacteristics=onDemand means the eNodeB should return a single immediate location snapshot, not periodic updates.

Now the procedure moved from the core network request to the actual RRC (Radio Resource Control) layer configuration. The message underlined in red is the RRC connection reconfiguration. The eNodeB's command to the UE to start the physical measurements required for positioning. While the previous LPPa messages were internal network "talk," this is the specific instruction sent over the air to the phone. In an LPP test context, this reconfiguration is often used to set up Measurement Gaps or specific reporting criteria so the UE can measure neighbor cells without dropping its current data connection.

In the measConfig structure, reportConfigId ties this measurement setup to a specific reporting rule set, and the triggerType=periodical means the UE will keep sending reports using the interval defined by that rule. reportInterval=ms120 is an aggressive rate, so the E-SMLC can receive very fresh snapshots of radio conditions during positioning. triggerQuantity=rsrp tells the UE to rank/select cells to report mainly based on received signal strength. ue-RxTxTimeDiffPeriodical-r9 is the key e-CID enabler because it turns on the UE's Rx-Tx time-difference measurement, where the UE compares its downlink reception timing to its uplink transmission timing, providing the UE-side timing input that supports the network's distance (Timing Advance-related) calculation.

This message represents the transition from network-side preparation to active communication with the device. The E-SMLC (Location Server) uses this message to "tunnel" LPP instructions through the MME and eNodeB to reach the UE. The network is now asking the phone: "What positioning methods are you actually capable of performing?"

This LPP message is a requestCapabilities handshake, so the location server is asking what positioning methods the UE can support (A-GNSS, OTDOA, E-CID, etc.). a-gnss-RequestCapabilities=TRUE means the network is explicitly checking whether the UE can do satellite-based positioning with assistance. otdoa-RequestCapabilities=TRUE means the network still wants the UE's OTDOA capability status for possible later use, even if an OTDOA attempt failed earlier on the network side. ecid-RequestCapabilities=TRUE matches the e-CID workflow you saw before, so the server is confirming the UE can provide the related measurements. transactionID shows the initiator is locationServer, and the UE must reply with ProvideCapabilities using the same transactionID to keep the session aligned. id-Correlation-ID=00000001H is the glue that ties this LPP session back to the original location request, so you can use it to trace the full end-to-end procedure across logs.

The Downlink generic NAS transport is a NAS-layer message that tunnels the actual positioning instructions. In this specific trace, it is being used to send the LPP RequestCapabilities. This is the handshake phase where the network (specifically the E-SMLC) asks the mobile device, "What hardware sensors and positioning methods do you support?"

The generic message container carries the actual LPP payload, and type=1 tells you this container is an LTE Positioning Protocol (LPP) message. lpp-MessageBody confirms the specific operation is requestCapabilities, meaning the locationServer is starting the capability handshake. a-gnss-RequestCapabilities=TRUE shows the network is checking Assisted-GNSS support, while otdoa-RequestCapabilities={} and ecid-RequestCapabilities={} indicate the server is also probing whether the UE can support OTDOA and Enhanced Cell-ID reporting. transactionID is the session key here: initiator=locationServer and transactionNumber=0, so the UE's next ProvideCapabilities should echo this exact transactionID to keep the LPP exchange correctly matched in your trace.

The UL (Uplink) information transfer is an RRC (Radio Resource Control) layer message used by the UE to send non-access stratum (NAS) information to the network. In the context of an LTE LPP test, this specific message acts as a transport container for the UE's response to the network's previous positioning requests. It confirms that the UE has successfully processed the network's instructions and is now sending the required data (such as its positioning capabilities) back to the MME.

The message is the Uplink generic NAS transport. This is the response to the network's earlier request for capabilities. At this stage, the UE is essentially "auditioning" its sensors, telling the E-SMLC (Location Server) exactly which positioning methods it can perform (GPS, OTDOA, etc.) so the server can decide which one to use for the final location fix.

Confirm that lpp-MessageBody: provideCapabilities is present, and first confirm transactionID.transactionNumber=0 to prove this is the UE's direct response to the server's earlier request. In a-gnss-ProvideCapabilities, check gnss-id=gps to confirm a GPS receiver is supported, and then read posModes='10'B to see which GNSS positioning modes the UE claims (standalone vs assisted/UE-based capabilities). In otdoa-ProvideCapabilities, otdoa-Mode='10'B confirms the UE can perform OTDOA measurements, and supportedBandListEUTRA tells you which LTE bands it can use for those timing measurements (for example bandEUTRA 7). ecid-ProvideCapabilities at the bottom is the key confirmation for the fallback path, because it indicates the UE can report the radio timing/related measurements needed for E-CID. Finally, under locationCoordinateTypes, make sure ellipsoidPoint=TRUE, which confirms the UE can report position using standard latitude/longitude coordinates.

This message is sent by the E-SMLC (Location Server) to the UE to officially acknowledge receipt of the ProvideCapabilities message seen in the previous step. In the LPP state machine, this "closes the loop" on the capability exchange. It tells the UE that the network now has all the hardware information it needs (GPS support, band info, etc.) and is ready to proceed to the next phase, such as providing assistance data or requesting the actual location fix.

In the Generic message container, acknowledgement shows the location server is explicitly acknowledging the UE's previous LPP transmission. ackRequested=FALSE means the server is not asking the UE to acknowledge this acknowledgement, so the exchange stops cleanly and does not create an ack-of-ack loop. ackIndicator=0 is the key linkage because it points to the transactionID.transactionNumber=0 of the UE message being acknowledged, so you can confirm it matches the capability transaction you are tracking. endTransaction=FALSE is critical for a successful test case because it means only the capability handshake step is complete, while the overall positioning session remains open and the network can send the next LPP instructions (OTDOA, E-CID, A-GNSS assistance, etc.). Finally, Generic message container type=1 confirms the NAS message is still carrying an LPP payload, so the layering and routing are correct.

This message serves as the radio-layer carrier for a response from the Location Server (E-SMLC). Because the actual positioning protocol (LPP) and core network signaling (NAS) cannot be read directly by the physical radio, they are wrapped in this RRC "envelope" to be delivered over the air to the phone.

This message represents the "Final Order" in the LPP sequence. The E-SMLC has analyzed the UE's capabilities (like the GPS support confirmed in previous logs) and is now telling the UE: "Perform these specific measurements using your GPS and cell tower sensors, and give me the result."

In this LPP request, locationInformationType=locationEstimatePreferred tells you the network wants a final computed position (latitude/longitude), not just raw measurements. The qos.responseTime=3 s is the key stress point of the test, because it gives the UE only a short window to get a GNSS fix before the session times out or falls back. Under locationCoordinateTypes, ellipsoidPoint=TRUE means the network is requesting the UE to report coordinates in the standard lat/long format the UE already advertised. For the actual measurement plan, a-gnss-RequestLocationInformation activates GNSS behavior, and gnss-Methods='1'B specifically triggers the GPS receiver. In parallel, ecid-RequestLocationInformation.requestedMeasurements='111'B is a combined request for RSRP, RSRQ, and UE Rx-Tx time difference (Timing Advance-related), so the network can still produce an E-CID position estimate if GNSS cannot complete within the 3-second QoS window.

This message is the UE's response to the network's previous request for capabilities. It is the moment the mobile device "introduces" its hardware to the location server. By using Generic NAS Transport, the device can tunnel specialized LPP information through the standard LTE signaling stack without the base station needing to understand the location data itself.

Generic message container type=1 confirms the NAS message is carrying an LPP payload, so the MME treats it as positioning-related signaling rather than general user traffic. Inside the Generic message container, the lpp-MessageBody=provideCapabilities shows this is the UE's capability response. Under a-gnss-ProvideCapabilities, gnss-id=gps confirms the UE has GPS available for this session. Under otdoa-ProvideCapabilities, otdoa-Mode='10'B together with supportedBandListEUTRA (bandEUTRA 7) confirms the UE can perform OTDOA measurements on that LTE band if the network provides valid neighbor/cell assistance data, even if OTDOA failed earlier on the network side. In locationCoordinateTypes, ellipsoidPoint=TRUE confirms the UE can report a calculated position in standard latitude/longitude coordinates. Finally, transactionID.transactionNumber=0 must match the server's original request, proving this provideCapabilities is correctly linked to the same LPP session.

This message is an LCS-AP (Location Services Application Program) protocol unit. It acts as a "container" that tunnels LPP payloads through the MME. In these specific traces, it is used to manage the LPP Capability Exchange—the phase where the network and the mobile device introduce their positioning hardware to one another.

The fields that matter most are id-Correlation-ID (e.g., 00000001H) to tie the whole exchange back to the original location request, id-Payload-Type=lpp to confirm the payload is LPP, and transactionID.transactionNumber (e.g., 0) to keep the request/response paired. endTransaction tells you whether this specific LPP transaction phase is being kept open for follow-on steps (FALSE) or closed/finished (TRUE), and in the requestCapabilities phase you should see a-gnss/otdoa/ecid RequestCapabilities flags set to indicate the network is probing which positioning methods the UE can support (with E-CID typically important as a fallback when OTDOA is problematic).

This message is an LCS-AP protocol container sent from the E-SMLC (Location Server) to the UE. Its primary purpose in this specific log is to acknowledge that the server has successfully received and parsed the UE's previously sent hardware capabilities (such as the GPS and OTDOA support confirmed in the prior uplink message).

This is the DL NAS message that encapsulate the LCSAP message shown above.

This is the RRC package that encapsulate the NAS message from UE.

This Uplink generic NAS transport message contains the LPP ProvideLocationInformation payload. This is the most critical message in the test, as it delivers the end results—the physical coordinates and supporting radio measurements—that were requested by the server.

commonIEsProvideLocationInformation.locationEstimate is the main outcome. It should contain ellipsoidPointWithAltitude, showing the final coordinates and height, i.e. latitude 45.53766, longitude 10.9621, and altitude 5 m. a-gnss-ProvideLocationInformation is where GNSS-specific details would appear if the fix was driven primarily by satellite measurements. In this trace, the key point is that the UE produced a valid locationEstimate, consistent with the earlier capability exchange and the request parameters. ecid-ProvideLocationInformation.measuredResultsList provides the radio supporting measurements at the time of the fix: rsrp-Result=76 and rsrq-Result=29 describe serving-cell signal strength and quality, and ue-RxTxTimeDiff=32 is the timing measurement that feeds the E-CID distance component (and acts as the fallback anchor if GNSS is constrained). transactionID.transactionNumber=1 must match the RequestLocationInformation transaction, confirming this result belongs to that exact request. endTransaction=TRUE indicates the network is closing the LPP session for this specific location request, which is what you want to see at the end of a clean, completed test.

eNB sends Downlink generic NAS transport to carry an LPP payload to the UE. Generic message container type=1 confirms the NAS message is tunneling LTE Positioning Protocol (LPP) data. Inside the generic message container, endTransaction=FALSE means this LPP session is still open, so more positioning steps can follow. ackIndicator=1 means this message is acknowledging the LPP transaction whose transactionID.transactionNumber is 1. In other words, the sender is confirming it received the earlier LPP message that belonged to transaction 1

This RRC DL information transfer is to carry a NAS PDU inside an RRC container on the air interface. you can see message c1: dlInformationTransfer-r8, and inside it the dedicatedInfoType: dedicatedInfoNAS field holds the raw NAS bytes

This message acts as a secure container used by the UE to deliver the final LPP Provide Location Information payload back to the network. It contains the physical coordinates (latitude, longitude, and altitude) that were the ultimate goal of the location request.

In the provideLocationInformation result, the key outcome is the location estimate itself: latitudeSign is north and degreesLatitude 4553766 , degreesLongitude 109621 and altitude 5 means the UE reports roughly 5 meters above the ellipsoid. The session linkage is confirmed by transactionID having transactionNumber 1, which must match the earlier RequestLocationInformation so you know this estimate is the response to that command, and endTransaction TRUE indicates the positioning procedure for this request is formally closed. For ECID metadata, rsrp-Result 76 and rsrq-Result 29 capture the serving-cell signal strength and quality at the time of the fix, and ue-RxTxTimeDiff 32 is the UE timing measurement that supports the Enhanced Cell-ID fallback distance component.

This message is LCSAP Connection-Oriented-Information-Transfer carrying an LPP provideLocationInformation-r9 payload from the locationServer. The id-Correlation-ID=00000001H ties it to the same overall positioning request chain, and id-Payload-Type=lpp confirms the embedded payload is LPP. The transactionID.transactionNumber=1 shows this result belongs to the requestLocationInformation transaction, and ackIndicator=1 with acknowledgement=TRUE means the network is explicitly acknowledging the UE-side message for transaction 1. endTransaction=TRUE is the key success flag here because it closes this LPP transaction after delivering the final result.

Inside commonIEsProvideLocationInformation.locationEstimate, the UE reports an ellipsoidPointWithAltitude fix with latitude north / degreesLatitude 4553766, degreesLongitude 109621, and altitude 5, so the session produced a concrete coordinate output. In ecid-ProvideLocationInformation.measuredResultsList, you also see the supporting radio snapshot for the same instant, including rsrp-Result=76, rsrq-Result=29, and ue-RxTxTimeDiff=32, which are the E-CID inputs kept as backup/metadata alongside the coordinate estimate.

This message is LCSAP Connection Oriented Information sent from the MME, and it is carrying an LPP-related control container identified by id-Payload-Type=lpp with id-Correlation-ID=00000001H, so it belongs to the same positioning session you have been tracing. ackIndicator=1, which means the MME/location side is confirming it has received the LPP transaction #1 exchange, while ackRequested=FALSE prevents an ack-of-ack loop. endTransaction=FALSE means this message is only an acknowledgement step and the overall positioning session is still considered open at the LCSAP transport level, so follow-on LCS/LPP messages can still occur under the same correlation ID.

This is the Downlink generic NAS transport which encapsulate the LPP message sent by the server. The Generic message container type=1 means it is carrying an LPP payload. Inside that container, ackIndicator=1 points to LPP transactionNumber 1, so the network side is confirming it received the transaction #1 message. ackRequested=FALSE means it does not ask the UE to acknowledge this acknowledgement, so you do not get an ack-of-ack loop. endTransaction=FALSE means this particular container does not close the overall positioning procedure by itself; it is just an acknowledgement delivery step while the higher-level session context can remain open under the same correlation ID.

This entry is the LCSAP Location Response coming from the MME toward the E-SMLC/location server side. It is no longer LPP tunneling; it is the final LCSAP response that delivers the computed position back to the requester. In the right pane you can see successfulOutcome with procedureCode = id-Location-Service-Request, which means the original location service request has completed successfully. The id-Correlation-ID = 00000001H confirms it belongs to the same end-to-end session you have been tracking. The actual answer is carried in id-Location-Estimate. It contains ellipsoidPoint-With-Altitude (shown as geographicalCoordinates + altitude), with latitudeSign = north, degreesLatitude = 4553766, degreesLongitude = 109621, and altitude = 5. This is the location estimate that corresponds to the LPP provideLocationInformation you saw earlier, now wrapped as the final LCSAP location response.

This RRC MeasurementReport is the UE's radio measurement snapshot that feeds the E-CID part of the positioning workflow. In the right pane you can see measurementReport-r8 with measResults, where rsrpResult=76 and rsrqResult=29 report the serving-cell signal strength and quality at that moment. The presence of ue-RxTxTimeDiffResult-r9=32 is the critical e-CID timing input, because it is the UE-reported Rx-Tx time difference that corresponds to the Timing-Advance-related distance component used by the network. The currentSFN value is just the UE's frame timing context for when the measurement was taken, and the key point is that this MeasurementReport is the RRC-level source of the same ECID measurements you later see echoed inside the LPP provideLocationInformation and the final LCS location response.

This is the e-CID Measurement Response coming from the positioning side, and it is where the E-SMLC consolidates the UE's radio measurements into a single e-CID result set. In the right pane you can see identifiers like eNB-UE-Measurement-ID and then e-CID-MeasurementResult, which carries both the serving-cell identity context and the outputs that were used to compute the fix.

The servingCell-ID / PLMN-Identity / EUTRANCellIdentifier fields anchor the measurement to the exact LTE cell that acted as the reference. The e-UTRANAccessPointPosition block is the final coordinate estimate in ellipsoid format, showing latitude north / degreesLatitude 4553766, degreesLongitude 109621, and altitude 5, along with uncertainty/confidence fields that describe the quality of that estimate. Under measuredResults, the key e-CID inputs are listed: timingAdvanceType1 and timingAdvanceType2 values (shown as 16/16 here) and the radio quality snapshots resultRSRP=76 and resultRSRQ=29, which match the RRC MeasurementReport you saw earlier and confirm the e-CID path was populated correctly.

This screen is the MME-side Connection Oriented Information that carries the e-CID measurement result back through LCSAP. The payload starts with lppatransactionID 0 and then lists LCS/e-CID objects such as id-E-SMLC-UE-Measurement-ID, id-eNB-UE-Measurement-ID, and id-E-CID-MeasurementResult.

The servingCell-ID block anchors the result to the serving LTE cell, and the e-UTRANAccessPointPosition block is the coordinate estimate that the positioning function is reporting, showing latitude north with values around 45.54°, longitude around 10.96°, and the altitude field. The measuredResults section carries the radio evidence used for the e-CID computation, including timingAdvanceType1 and timingAdvanceType2 values, and the per-cell resultRSRP=76 and resultRSRQ=29 entries tied to the same ECGI/ARFCN context. The presence of these fields together means the e-CID path is complete: the network has both a position estimate and the measurement snapshot that supports how it was derived.

Test 2 : Manual Configuration

This test is to shows how to run the same LTE LPP positioning procedure using manual configuration instead of auto configuration. In this mode, you explicitly set the key e-SMLC and measurement parameters, so you can control which positioning methods are attempted, how often the UE reports, and what assistance or neighbor information is used. The purpose is to understand each required knob, verify that each setting is reflected in the signaling trace, and have a deterministic baseline when you need repeatable results or detailed debugging beyond what autonomous mode provides.

NOTE : If you are using a recent software release (e.g, later than Feb 2026) and you don't need any specific configuration requirement, it is recommended to use auto mode introduced in previous test.