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.

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

Table of Contents

• LTE LPP (LTE Positioning Protocol)
• Introduction
• Summary of the Tutorial
• Test Setup
• Setup A
• Setup B
• Key Configuration Parameters
• 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 critical component within the LTE and NR (New Radio/5G) ecosystem, designed to facilitate the precise exchange of positioning information between user equipment (UE) and the network. LPP serves as a control plane (C-plane) and user plane (U-plane) protocol, enabling the support of multiple global navigation satellite systems (GNSS) such as GPS, GLONASS, Galileo, and QZSS, thereby providing enhanced flexibility and accuracy over legacy protocols like SUPL (Secure User Plane Location), which is predominantly GPS-centric and limited to the U-plane. LPP operates by orchestrating the signaling and data exchange required for the network to request, assist, and retrieve location measurements from the UE, playing a pivotal role in enabling location-based services (LBS), emergency services, and regulatory compliance in modern cellular networks. Architecturally, LPP is integrated within both LTE and NR stacks, interacting with network elements such as the Evolved Serving Mobile Location Center (E-SMLC) or Secure Location Platform (SLP), and is designed to seamlessly interwork with various positioning methods including A-GNSS, OTDOA, and ECID. Its introduction marked a significant advancement in the standardization and extensibility of location services, directly supporting the evolution of mobile broadband and IoT applications requiring robust and standardized positioning capabilities. As LPP continues to evolve, its support in commercial and test platforms like Amarisoft further underscores its importance in network validation, interoperability testing, and the development of next-generation location-aware solutions.

• Context of LPP in Mobile Networks
  • LPP is a standardized protocol specified by 3GPP for the exchange of positioning assistance and measurement data between the mobile device (UE) and the core network.
  • Unlike its predecessor SUPL, LPP supports multiple satellite systems and operates over both control and user planes, boosting its applicability in diverse network deployments.
  • It is integral to LTE and 5G NR architectures, ensuring future-proof positioning support for both legacy and cutting-edge devices.
• Significance and Relevance of LPP
  • LPP enables advanced location-based services, regulatory compliance (such as E911), and emergency call positioning by providing a reliable and standardized mechanism for network-assisted and autonomous location determination.
  • Its multi-GNSS support enhances location accuracy and resilience in urban, rural, and indoor environments, making it essential for IoT, vehicular, and safety-critical applications.
  • Adoption of LPP in commercial network and test equipment, such as Amarisoft, streamlines development, testing, and certification of location-enabled devices and services.
• Tutorial Focus and Importance
  • This tutorial provides step-by-step guidance on configuring and testing LPP functionality, focusing on its implementation within Amarisoft.
  • It addresses practical aspects, including protocol configuration, message exchange, and simulation of location-based scenarios.
  • Understanding LPP configuration and testing is crucial for professionals involved in network deployment, device validation, and application development for LTE and 5G networks.
• Learning Outcomes
  • Gain a comprehensive understanding of LPP architecture, capabilities, and operational principles in LTE and NR networks.
  • Develop hands-on skills in configuring and validating LPP protocol operations using Amarisoft test solutions.
  • Learn to interpret LPP signaling flows and troubleshoot positioning scenarios in test environments.
  • Understand the limitations and extensibility of current LPP implementations in commercial test platforms.
• Prerequisite Knowledge and Skills
  • Familiarity with LTE/5G NR network architecture and protocol stack.
  • Basic understanding of positioning technologies, GNSS systems, and location-based service concepts.
  • Experience with Amarisoft or similar test platforms is beneficial but not mandatory.
  • Ability to interpret protocol logs and basic troubleshooting skills are recommended for optimal learning.

Summary of the Tutorial

This tutorial describes test procedures for performing LTE LPP (LTE Positioning Protocol) location requests and responses using Amarisoft solutions. The focus is on configuring the test environment, setting up the necessary parameters, and executing the test steps to verify end-to-end LPP procedures between network elements and UE (User Equipment) or UEsim.

• Test Setup
  •   Two setups are outlined:
    • Setup A: Uses a commercial UE as the Device Under Test (DUT).
    • Setup B: Uses Amarisoft UEsim as the DUT.
  •   The SIM card provided with the system is used as-is. For configuration changes, a separate configuration guide is referenced.
• Key Configuration Parameters
  •   Essential parameters for the test are listed and include nl1, lcs, and local_e_smlc, each with multiple sub-parameters such as api_root, transaction_timeout, server_addr, lpp_test, e_smlc_id, otdoa_assistance_data, etc. These parameters are referenced for detailed configuration in Amarisoft documentation.
• Configuration Steps
  • eNB/gNB: Use the default configuration file enb.default.cfg without modification. FDD mode is used with a 5 MHz bandwidth (N_RB_DL 25).
  • MME: Use and modify mme-ims-lte-lpp.cfg as needed, especially for e-SMLC settings under local_e_smlc. For internal e-SMLC testing, enable lpp_test and set related parameters such as e_smlc_id, periodic_meas, meas_period, and otdoa_assistance_data.
  • UE/UEsim: Use ue.default.cfg as-is. For GNSS response, configure ground_position_at_origin in cell_groups. Ensure that dl_earfcn matches the eNB configuration (Band 7).
• Test Execution Procedure
  1. Verify cell configuration using cell phy and cell commands.
  2. Switch to the MME screen and run the lcs command, verifying that the LCS connection state is state=connected.
  3. Power on the UE in UEsim and ensure the initial attach is successfully completed.
  4.   On the Callbox, send a location request to the UE using the Remote API:

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

  5.   After receiving the response, send a command to request a report from E-SMLC using the ECID method:

     ./ws.js mme '{"message": "lpp_request_location","supi": "imsi-001010123456789","imei": "01234567000001","correlation_id": 1,"lpp_methods": ["ecid"],"report_type":"once"}'
     

     Note: This must be done within 5 minutes of the location request, as the session expires after 5 minutes.
  6.   Send a similar command for the GNSS method:

     ./ws.js mme '{"message": "lpp_request_location","supi": "imsi-001010123456789","imei": "01234567000001","correlation_id": 1,"lpp_methods": ["gnss"],"report_type":"once"}'
     

  7.   For both ECID and GNSS, verify that the system processes the requests and responses correctly, as observed in associated logs.
• Log Analysis
  •   Perform high-level correlation between remote API/user actions and LCSAP log entries.
  •   Ensure that LCSAP is connected before UE power-up and that after initial attach, the eNB triggers location requests correctly.
  •   The sequence for each remote API command should show the expected message flow (location request, capability request/provide, reporting, and acknowledgements).
  •   Use LCSA layer logs and provided snapshots to verify each test step.

Summary: The test procedure involves configuring the network elements and UE/UEsim, verifying connections, issuing remote API commands to trigger location requests (ECID and GNSS), and analyzing logs to confirm correct LPP message exchanges and positioning information flow. The test ensures proper end-to-end signaling and system behavior for LTE LPP location-based services.

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.

Setup B

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

Key Configuration Parameters

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

• nl1
• api_root
• transaction_timeout
• server_bind_addr
• lcs
• server_addr
• bind_addr
• local_e_smlc
• lpp_test
• e_smlc_id
• transaction_id
• periodic_meas
• meas_period
• meas_id
• otdoa_assistance_data
• ref_pci
• ref_earfcn
• neighbour
• earfcn
• pci
• nr_tdoa_assistance_data
• pointA_arfcn
• cells
• arfcn
• pci

Configuration

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

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

I have used  ue.default.cfg on UEsim as it is without any modification.

For eNB configuration, there is no specific parameters you need to set.  Just use enb.default.cfg without any modification.

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

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

In mme-ims-lte-lpp.cfg , the e-SMLC configuration is specified. It is configured by the parameter local_e_smlc. In case where you want to use Anarisoft mme for the testing purpose without using external e-SMLC server, just set lpp_test : true and set e_smlc_id, perodic_meas, meas_period, meas_id and otdoa_assistance_data as you want.

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).

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.

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

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

Perform the test

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

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

Power on a UE in UEsim

Make it sure that the initial attach is completed properly.

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"}' WebSocket remote API tool version 2024-02-01, Copyright (C) 2012-2024 Amarisoft [0.003] ### Connected to 127.0.0.1:9000 [0.003] ### Ready: name=MME, type=MME, version=2024-02-01 [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 }

Once you receive the response to location_req message, send another command to request report to E-SMLC. The command that I sent at this point is 'lpp_request_location' command for "ecid".

NOTE : This command should be sent within 5min after "location_req" command since the session for "location_req" will expire in 5min.

./ws.js mme '{"message": "lpp_request_location","supi": "imsi-001010123456789","imei": "01234567000001","correlation_id": 1,"lpp_methods": ["ecid"],"report_type":"once"}'

NOTE : "pei" is an optional parameter, but you should specify this when multi-UE is enabled.

[root@CBC-2023010100 mme]# ./ws.js mme '{"message": "lpp_request_location","supi": "imsi-001010123456789","imei": "01234567000001","correlation_id": 1,"lpp_methods": ["ecid"],"report_type":"once"}' WebSocket remote API tool version 2024-02-01, Copyright (C) 2012-2024 Amarisoft [0.003] ### Connected to 127.0.0.1:9000 [0.004] ### Ready: name=MME, type=MME, version=2024-02-01 [0.023] <== Send message lpp_request_location id#1 [0.044] ==> Message received {     "message": "lpp_request_location",     "message_id": "id#1",     "time": 54.306,     "utc": 1707145587.394 }

Now let's send another command to request report to E-SMLC. The command that I sent at this point is 'lpp_request_location' command for "gnss".

NOTE : This command should be sent within 5min after "location_req" command since the session for "location_req" will expire in 5min.

./ws.js mme '{"message": "lpp_request_location","supi": "imsi-001010123456789","imei": "01234567000001","correlation_id": 1,"lpp_methods": ["gnss"],"report_type":"once"}'

NOTE : "pei" is an optional parameter, but you should specify this when multi-UE is enabled.

[root@CBC-2023010100 mme]# ./ws.js mme '{"message": "lpp_request_location","supi": "imsi-001010123456789","imei": "01234567000001","correlation_id": 1,"lpp_methods": ["gnss"],"report_type":"once"}' WebSocket remote API tool version 2024-02-01, Copyright (C) 2012-2024 Amarisoft [0.003] ### Connected to 127.0.0.1:9000 [0.004] ### Ready: name=MME, type=MME, version=2024-02-01 [0.023] <== Send message lpp_request_location id#1 [0.034] ==> Message received {     "message": "lpp_request_location",     "message_id": "id#1",     "time": 60.794,     "utc": 1707145593.884 }

Log Analysis

Sample Log

Just for high level correlation between user action (e.g, lte service execution and remote API command execution) and LCSAP log, refer to this snapshot. Of course, you need to look into the contents of each of these log lines for the detailed analysis, but with this high level log lines you would get a quick check point on how each of your actions are going on.

After lte service is launched, select LCSA on Layer dropbox and execute remoteAPI commands one by one as explained in 'Perform the test' section and check if these blocks of log lines go through.

When you turn on eNB with mme configured with LPP, LCSAP is activated. Make it sure that LCSAP is connected before powering up UE. (NOTE : Refer to this tutorial to collect full log for eNB/gNB and MME)

After the initial attach is completed, you trigger eNB to send location request with remote API 'location_req'. Once the command is received by the core network (mme), it send the request to LCS via LCSAP.

First the core network send 'Location Request' message with id-UE-Positioning-Capability information.

Then the e-SMLC send LPP request capabilities to the LCS client in the MME in the message LCS-AP  Connection Oriented Information

Then the details of the request is sent from LCS to core network and the core network finally conveys the message to UE via NAS message (Downlink generic NAS transport).

Once the LPP request capabilities is received by the UE, the UE is supposed to send the response LPP provide capabilities via NAS message Uplink Generic NAS transport

Once the Positioning Information from UE is received by the core network (mme), the core network relays it to LCS server.

Once the LCS get the positioning information, it replies with ack (acknowledgement).

When you run ./ws.js mme '{"message": "lpp_request_location","supi": "imsi-001010123456789","imei": "01234567000001","correlation_id": 1,"lpp_methods": ["ecid"],"report_type":"once"}', a sequence of steps are performed as follows :

When you run ./ws.js mme '{"message": "lpp_request_location","supi": "imsi-001010123456789","imei": "01234567000001","correlation_id": 1,"lpp_methods": ["gnss"],"report_type":"once"}', a sequence of steps are performed as follows

RRC / NAS Signaling

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

Message: Downlink generic NAS transport

 

Data:

0000:  27 39 64 3e b7 03 07 68  01 00 0c 90 02 00 fa 02  '9d>...h........

0010:  05 02 c0 e0 14 06 40 65  04 00 00 00 01           ......@e.....

Protocol discriminator = 0x7 (EPS Mobility Management)

Security header = 0x2 (Integrity protected and ciphered)

Auth code = 0x39643eb7

Sequence number = 0x03

Protocol discriminator = 0x7 (EPS Mobility Management)

Security header = 0x0 (Plain NAS message, not security protected)

Message type = 0x68 (Downlink generic NAS transport)

Generic message container type = 1 (LTE Positioning Protocol (LPP) message)

Generic message container:

{

  transactionID {

    initiator locationServer,

    transactionNumber 1

  },

  endTransaction FALSE,

  lpp-MessageBody c1: requestCapabilities: {

    criticalExtensions c1: requestCapabilities-r9: {

      commonIEsRequestCapabilities {

        lpp-message-segmentation-req-r14 '11'B

      },

      a-gnss-RequestCapabilities {

        gnss-SupportListReq TRUE,

        assistanceDataSupportListReq TRUE,

        locationVelocityTypesReq TRUE

      },

      otdoa-RequestCapabilities {

      },

      ecid-RequestCapabilities {

      },

      nr-ECID-RequestCapabilities-r16 {

      },

      nr-DL-TDOA-RequestCapabilities-r16 {

      }

    }

  }

}

Additional information:

  Length = 4

  Data = 00 00 00 01

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

Message: Uplink generic NAS transport

 

Data:

0000:  27 37 b2 a9 1c 03 07 69  01 00 29 f0 03 00 42 1e  '7.....i..)...B.

0010:  80 81 60 28 28 00 0a 3f  c4 4a 85 2b 08 84 04 00  ..`((..?.J.+....

0020:  c0 02 00 02 00 02 00 02  a0 02 00 02 01 87 05 80  ................

0030:  60 00 70 00 65 04 00 00  00 01                    `.p.e.....

Protocol discriminator = 0x7 (EPS Mobility Management)

Security header = 0x2 (Integrity protected and ciphered)

Auth code = 0x37b2a91c

Sequence number = 0x03

Protocol discriminator = 0x7 (EPS Mobility Management)

Security header = 0x0 (Plain NAS message, not security protected)

Message type = 0x69 (Uplink generic NAS transport)

Generic message container type = 1 (LTE Positioning Protocol (LPP) message)

Generic message container:

{

  transactionID {

    initiator locationServer,

    transactionNumber 1

  },

  endTransaction TRUE,

  sequenceNumber 0,

  acknowledgement {

    ackRequested TRUE

  },

  lpp-MessageBody c1: provideCapabilities: {

    criticalExtensions c1: provideCapabilities-r9: {

      commonIEsProvideCapabilities {

        segmentationInfo-r14 noMoreMessages,

        lpp-message-segmentation-r14 '10'B

      },

      a-gnss-ProvideCapabilities {

        gnss-SupportList {

          {

            gnss-ID {

              gnss-id gps

            },

            agnss-Modes {

              posModes '100'B

            },

            gnss-Signals {

              gnss-SignalIDs 'FF'H

            },

            adr-Support FALSE,

            velocityMeasurementSupport FALSE

          }

        },

        locationCoordinateTypes {

          ellipsoidPoint TRUE,

          ellipsoidPointWithUncertaintyCircle FALSE,

          ellipsoidPointWithUncertaintyEllipse FALSE,

          polygon FALSE,

          ellipsoidPointWithAltitude TRUE,

          ellipsoidPointWithAltitudeAndUncertaintyEllipsoid FALSE,

          ellipsoidArc FALSE

        }

      },

      otdoa-ProvideCapabilities {

        otdoa-Mode '100'B,

        supportedBandListEUTRA {

          {

            bandEUTRA 7

          }

        },

        interFreqRSTDmeasurement-r10 supported,

        prs-id-r14 supported,

        tp-separation-via-muting-r14 supported,

        maxSupportedPrsBandwidth-r14 n100,

        periodicalReporting-r14 supported,

        interRAT-RSTDmeasurement-r15 supported

      },

      ecid-ProvideCapabilities {

        ecid-MeasSupported '00111'B,

        ueRxTxSupTDD-r13 true,

        periodicalReporting-r14 supported,

        triggeredReporting-r14 supported

      }

    }

  }

}

Additional information:

  Length = 4

  Data = 00 00 00 01