Amarisoft

NR LPP (NR Positioning Protocol)

This tutorial is to show how to configure and test LPP. LPP stands for NR 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

NR LPP Overview 01

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

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

Table of Contents

Introduction

The NR Positioning Protocol (LPP) is a key component in 5G and LTE networks, designed to enable precise location-based services by facilitating the efficient exchange of positioning information between mobile devices (User Equipment, UE) and the network. Unlike its predecessor, SUPL (Secure User Plane Location), which primarily leverages the user plane and is closely tied to GPS, LPP offers a multi-constellation approach—supporting not only GPS but also other global navigation satellite systems (GNSS) such as GLONASS, Galileo, and QZSS. Architecturally, LPP operates in both the control plane (C-Plane) and user plane (U-Plane), allowing it to flexibly adapt to diverse deployment scenarios and use cases within LTE and 5G NR ecosystems. This dual-plane capability enhances the reliability and accuracy of positioning, making LPP an essential protocol for enabling advanced applications like emergency services, asset tracking, and network-based location analytics. LPP's integration into the radio access and core network layers leverages standardized signaling procedures to ensure interoperability, security, and scalability across devices and network vendors. As 5G networks continue to evolve, LPP's role in providing accurate, low-latency positioning data becomes increasingly significant, underpinning innovations in autonomous systems, smart cities, and mission-critical communications. In this tutorial, we explore the configuration and testing of LPP, with a particular focus on Amarisoft's implementation, highlighting current limitations and supported features to provide a practical, hands-on understanding of modern cellular positioning protocols.

Summary of the Tutorial

This tutorial details the test procedures for verifying NR LPP (LTE Positioning Protocol) functionalities using Amarisoft Callbox and UEsim. The following summarizes the test setup, configuration, and procedural steps required to perform the test and analyze the results.

Note: The tutorial provides comprehensive step-by-step procedures, including configuration, remote API command usage, log analysis, and expected transaction flows for validating NR LPP ECID and GNSS location procedures. All command-line and configuration steps must be followed exactly as described to ensure successful test outcomes.

Test Setup

Test setup for this tutorial is as shown below.  

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.

Test 1 : ECID

Configuration

I have used  gnb-sa-lpp-ecid.cfg on Callbox (gNB) as it is without any modification.

NR LPP Test1 Configuration 01

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

NR LPP Test1 Configuration 02

I have used  ue-nr-sa-lpp-ecid.cfg on UEsim which is copied and modified from ue-nr-sa.cfg.

NR LPP Test1 Configuration 03

For eNB configuration, there is no specific parameters you need to set.  Just use gnb-sa-lpp-ecid.cfg without any modification.

This test targets NR eCID measurement. The implementation requires at least two NR cells, so N_CELLS is set to 2 to provide a serving cell plus a neighbor cell for measurement. The setup selects an NR TDD configuration and a defined NR channel bandwidth so the test runs with a known numerology and resource grid size. The RF chain is also constrained by an IF attenuation setting, so the received level stays within the expected range for stable measurements.

This test does not use PRS. For NR eCID, the position-related result is derived from timing and cell identity based measurements rather than PRS correlation, so ENABLE_PRS is set to 0 to keep the procedure simple and avoid PRS scheduling and PRS resource configuration. The antenna settings define the DL and UL port usage for the call box and UE, and SRS is disabled unless you explicitly need uplink sounding for another part of the test. Overall, the configuration keeps only the minimum items needed for NR eCID in an LPP session and turns off PRS-related features to reduce variables during verification.

NR LPP Test1 Configuration 04

This configures the RF driver block so the call box knows which SDR devices to open and how many to allocate for the test. The driver name is set to sdr, so the software uses the SDR backend and expects device nodes like /dev/sdr0, /dev/sdr1, and so on.

If the downlink antenna count is 4 or more, it allocates four SDR devices and maps them to dev0 through dev3. Otherwise it checks the number of NR cells. If you run a single cell configuration, it uses only dev0. If you run a multi cell configuration, it allocates dev0 and dev1 so each cell can be served by its own SDR path. This is why N_CELLS impacts how many SDR cards are assigned.

NR LPP Test1 Configuration 05

This part defines the RF port mapping for the test so the software can build the correct set of transmit and receive paths for each NR cell.

The first RF port entry is always present. The second RF port entry is included only when N_CELLS is greater than 1. This is the mechanism that makes the same configuration file work for both one cell and two cell setups. If you run only one cell, the second port block is used, so there is no unused port and no extra SDR resource allocation. If you run two cells, the second port block becomes active.

This configuration defines the NR cell used in the LPP eCID session. The key parameters are n_id_cell, dl_nr_arfcn, subcarrier_spacing, and ssb_pos_bitmap. n_id_cell determines the PCI and therefore which cell the UE camps on and measures. dl_nr_arfcn and band set the RF frequency for the test. subcarrier_spacing sets the numerology that impacts timing and measurement behavior. ssb_pos_bitmap controls which SSB locations are transmitted, so it affects initial access and measurement stability.

For two cell eCID, ncell_list is the important parameter. It enables the neighbor cell definition only when N_CELLS > 1. Without ncell_list, the setup becomes a single cell configuration and eCID neighbor based measurement is not possible.

For LPP validation, access_point_position is the important block. latitude, longitude, and altitude provide the reference cell site position used for positioning messages and result checking.

This block adds the second NR cell only when N_CELLS > 1, which is required for NR eCID. The key parameters are rf_port, n_id_cell, dl_nr_arfcn, subcarrier_spacing, ssb_pos_bitmap, and ncell_list. rf_port maps this cell to the second RF chain. n_id_cell sets the PCI for this second cell. band and dl_nr_arfcn place it on a different frequency from the first cell. subcarrier_spacing and ssb_pos_bitmap make the SSB detectable for camping and measurements. ncell_list links the cells so the neighbor relationship exists for eCID reporting. access_point_position with latitude, longitude, and altitude defines the reference location of this second cell for LPP validation.

This block defines default NR cell behavior and the measurement settings needed before running the LPP procedure.

The inactivity_timer is extended to prevent the UE from going idle and triggering RRC release before you send the Remote API command that starts the LPP measurement.

The important part is meas_config_desc. This is where the RRC measurement framework is enabled, with A1 and A2 thresholds and time_to_trigger values that control when measurements are considered stable. For a single cell setup only, nr_periodical enables periodic measurement reports(this is experimental purpose). The key parameters there are report_quantity_rsrp, report_quantity_rsrq, report_quantity_sinr, report_interval, report_amount, and max_report_cells. These ensure the UE keeps producing measurement results that the LPP eCID procedure can use.

This block is the NR PRS configuration and it is used only when ENABLE_PRS is enabled. In this LPP eCID test, PRS is not used, so this section is kept as a template but remains inactive.

If you enable it, prs_resource_set defines when PRS is transmitted and how it is shaped. period, offset, time_gap, and repetition_factor control the PRS periodicity and repetition pattern. prs_muting_option1, muting_bit_repetition_factor, and prs_muting_option2 control muting so PRS can be selectively turned on and off across occasions. l_crb, rb_start, comb_size, and n_symb define the PRS frequency and time resource footprint. azimuth and elevation describe the beam direction metadata used for positioning related interpretation.

prs_resource then defines the actual PRS resources inside the set. re_offset, slot_offset, and start_symb place each PRS resource within the PRS occasion. sequence_id selects the PRS sequence identity so multiple resources can use different sequences.

This is another PRS resource set definition. It is meant to describe a second PRS transmission pattern, but it is still under the same ENABLE_PRS condition, so it stays inactive in this eCID based LPP test.

The key parameters are period, offset, time_gap, and repetition_factor. They define how often PRS occasions appear and how many consecutive occasions are repeated. prs_muting_option1, muting_bit_repetition_factor, and prs_muting_option2 define which occasions are muted, so you can create on off patterns across the repeated PRS occasions. l_crb and rb_start define where PRS is placed in frequency, and comb_size with n_symb define the PRS density and time length.

Inside prs_resource, re_offset selects the PRS comb offset, and slot_offset and start_symb place each PRS resource inside the slot. Multiple entries let you transmit PRS in different OFDM symbols within the same PRS occasion, which is useful when you want more PRS energy or different measurement opportunities. Azimuth and elevation are metadata for the beam direction associated with this PRS set.

In mme-ims-nr-lpp-auto.cfg , In case where you want to use Amarisoft mme for the testing purpose without using external LMF, you can configure a test LMF with the parameter lmf_cfg.

lmf_cfg configures the internal test LMF that is embedded in the AMF. It is not a real production location server. It exists to drive and debug positioning procedures through simple APIs.

autonomous_mode controls whether the LMF runs the whole procedure by itself. If autonomous_mode is true, the LMF automatically starts the needed NRPPa and LPP exchanges when it receives a location request, so you do not need to manually call step by step APIs. If autonomous_mode is false, the LMF only sends the first trigger message and then waits for you to invoke the follow up APIs to continue.

ran_node_id_list is required when autonomous_mode is enabled. It tells the LMF which gNB to address in the HTTP request, using plmn, gnb_id_bits, and gnb_id. If this list is missing or incorrect, the autonomous procedure cannot target the right RAN node.

NR LPP Test1 Configuration 06

In ue-nr-sa-lpp-ecid.cfg , TDD is used and bandwidth is set to 40 Mhz (CELL_BANDWIDTH 40).

This section sets the high level UE simulator parameters that must match the network side configuration for an NR LPP eCID test. N_CELLS is set to 2. This is the key requirement for NR eCID in this setup because the procedure needs at least a serving cell and one neighbor cell to produce meaningful eCID measurements. NR_TDD selects the NR TDD profile used by the UE simulator. It must be consistent with the gNB configuration so the UE can synchronize, camp, and keep UL and DL timing aligned during the measurement session. N_ANTENNA_DL and N_ANTENNA_UL define the UE antenna configuration for downlink and uplink. These settings control whether the UE runs as SISO or with diversity reception on the downlink, and they affect measurement quality and stability.

NR LPP Test1 Configuration 07

This block configures which SDR devices the UE simulator will open and how they are mapped to logical device instances.

The driver selection depends on N_ANTENNA_DL and N_CELLS. When N_ANTENNA_DL is 2 or less, the number of SDR devices is mainly driven by how many cells you run. If N_CELLS is 1, only dev0 is allocated. If N_CELLS is greater than 1, dev0 and dev1 are allocated so the UE simulator can support the two cell test topology. When N_ANTENNA_DL is larger, more SDR devices are allocated, up to dev0 through dev3, to support additional RF chains.

This block defines the NR cell group and the first NR cell that the UE simulator will use during the LPP eCID session.

group_type set to nr tells the UE simulator that this group is NR. multi_ue set to true allows multiple UE contexts to run under the same cell group. The cells array then lists the actual cell configurations.

For the first cell, rf_port selects which RF port instance is used for this cell. The key radio parameters are band, dl_nr_arfcn, ssb_nr_arfcn, and subcarrier_spacing. band and dl_nr_arfcn define the carrier frequency where the UE will operate. ssb_nr_arfcn defines where the SSB is placed, which is critical for initial access and stable synchronization. subcarrier_spacing sets the numerology and must match the network configuration for reliable camping and measurement.

At the end, bandwidth, n_antenna_dl, and n_antenna_ul tie this cell to the global bandwidth and antenna settings so the UE simulator uses the correct channel width and RF chain configuration.

NR LPP Test1 Configuration 07 01

This block adds the second NR cell in the UE simulator only when N_CELLS is greater than 1. This is needed for the NR eCID test because the UE must see at least two cells.

rf_port is set to 1 so this cell is mapped to the second RF path. The key frequency and sync parameters are band, dl_nr_arfcn, ssb_nr_arfcn, and subcarrier_spacing. dl_nr_arfcn places the second carrier at a different frequency from the first cell. ssb_nr_arfcn defines where the second cell transmits its SSB so the UE can detect and measure it. subcarrier_spacing must match the network numerology so measurements are stable. rx_to_tx_latency keeps the TDD timing consistent for uplink behavior. bandwidth, n_antenna_dl, and n_antenna_ul reuse the global bandwidth and antenna settings so the second cell operates with the same channel width and RF chain assumptions as the first cell.

Perform the test

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

In cell phy, confirm that you see Cell 0x001 and Cell 0x002. Check BAND is n78 for both. Check BW is 40 MHz for both. Check DL ARFCN is 627300 for Cell 0x001 and 633300 for Cell 0x002. Check SCS is 30 kHz for both. Check the SSB section shows SSB ARFCN 626592 for Cell 0x001 and 632640 for Cell 0x002, with SCS 30 kHz.

In cell, confirm that dl_arfcn matches the DL ARFCN for each cell. Confirm pci is 500 for Cell 0x001 and 501 for Cell 0x002. Confirm plmn is 00101 and gNB_ID is 0x12345 as expected.

NR LPP Test1 Run 01

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

NR LPP Test1 Run 02

Power on a UE in UEsim

NR LPP Test1 Run 02 01

Make it sure that the initial attach is completed properly.

NR LPP Test1 Run 02 02

Now let's send the command "nr_location_req" to Initiate the location procedure for a target UE in the AMF.

./ws.js mme '{"message": "nr_location_req","supi": "imsi-001010123456789","pei": "imei-01234567000001"}''

[root@CBC-2023010100 mme]# ./ws.js mme '{"message": "nr_location_req","supi": "imsi-001010123456789","pei": "imei-01234567000001"}'

WebSocket remote API tool version 2024-02-16, Copyright (C) 2012-2024 Amarisoft

[0.004] ### Connected to 127.0.0.1:9000

[0.004] ### Ready: name=MME, type=MME, version=2024-02-16

[0.024] <== Send message nr_location_req id#1

[0.035] ==> Message received

{

    "message": "nr_location_req",

    "message_id": "id#1",

    "time": 229.742,

    "utc": 1708232748.754

}

Log Analysis

Sample Log

This log sequence shows the full end to end flow of a network initiated 5G NR LPP positioning session for NR eCID.

The procedure starts when the AMF triggers the internal test LMF through the determine-location service. After receiving that request, the LMF prepares the control plane paths it needs. It creates the non UE N2 subscription so that NRPPa messages coming back from the gNB can be forwarded by the AMF. It also creates a UE specific N1/N2 subscription so that UE specific LPP messages and N2 notifications can be correlated to the same positioning session.

Once the callback paths are ready, the LMF starts the actual positioning procedure in two directions at the same time. Toward the gNB, it sends an NRPPa e-CID Measurement Initiation Request asking for network side eCID measurements such as serving cell information, signal strength and quality, and timing related data. Toward the UE, it sends an LPP RequestCapabilities so the UE can declare which positioning methods and formats it supports.

The UE receives the LPP capability request through NAS carried inside RRC DL Information Transfer. The UE then responds with LPP ProvideCapabilities in UL NAS Transport. In that response, the UE confirms support for A-GNSS, NR eCID, and NR DL-TDOA related capability, including detailed PRS processing capability and reporting support. The network then sends an LPP Ack to confirm it received the capability report correctly.

After capability discovery is complete, the LMF sends the real location request to the UE by using LPP RequestLocationInformation. In that request, the LMF asks for a location estimate and includes A-GNSS, NR eCID, and NR DL-TDOA related request elements. The request is targeted to the same UE context through the AMF and is delivered down to the UE again through NAS over RRC.

While that UE side LPP procedure is ongoing, the gNB side also progresses. The gNB sends back the NRPPa e-CID Measurement Initiation Response. That response contains the network side serving cell information, serving cell TAC, access point position of the base station, serving cell RSRP and RSRQ, timing advance related information, and neighbor cell measurement data. The AMF forwards that NRPPa result to the LMF through the previously established N2 notification callback.

On the UE side, the UE answers the RequestLocationInformation with LPP ProvideLocationInformation. In that response, the A-GNSS part reports a location error, meaning the GNSS based estimate did not succeed in this run. However, the NR eCID part succeeds and reports serving cell and neighbor cell measurements. The serving cell is PCI 501 and the neighbor cell is PCI 500, with their corresponding NR RSRP and NR RSRQ values. The network then sends another LPP Ack to acknowledge receipt of this final UE report.

In parallel to the LPP messaging, the normal RRC measurement framework is also active. The UE sends an RRC Measurement Report showing serving and neighbor cell RSRP and RSRQ values. This confirms that the UE measurement configuration installed by RRC Reconfiguration is working and that the radio side measurement path is healthy.

So at a high level, the flow proves that the complete positioning signaling chain is functioning. The AMF, LMF, UE, and gNB all exchange the expected messages. The LPP path between the UE and the LMF works correctly. The NRPPa path between the gNB and the LMF also works and returns network side eCID measurements. The UE fails only on the A-GNSS location estimate, but it successfully provides NR eCID related measurements. The gNB also successfully provides NRPPa eCID measurements. Overall, this is a successful NR eCID signaling session with valid UE side and network side radio measurement exchange, even though the GNSS based part of the requested location information does not succeed in this particular test.

This part shows the UE confirming NAS security and, at the same time, advertising that it supports LPP during registration. The important field to check is 5GMM capability in the Security mode complete. In that capability bitmap, the LPP flag is set to 1. This tells the core network that the UE supports the LTE Positioning Protocol over NAS, so the MME is allowed to start the LPP capability exchange and the later eCID measurement procedure.

This shows the core network starting the positioning procedure by calling the LMF over the Nlmf_Location service.

The AMF sends an HTTP POST to /nlmf-loc/v1/determine-location. This means the request is network initiated, not UE initiated. The goal is to trigger the LMF to run the location workflow that will later generate NRPPa and LPP messages.

The important tracking field is correlationID in the request data. This value is used to connect all related messages across the AMF, LMF, NRPPa, and LPP logs, so you can follow one positioning session end to end.

The request body also carries the UE identity and serving cell context. supi and pei identify the UE. The ncgi field contains the PLMN and NR cell ID so the LMF knows which RAN node and cell the UE is currently attached to. The ueLocCap section indicates LPP support, so the LMF is allowed to select an LPP based procedure when it proceeds with capability exchange and measurement initiation.

This shows the LMF preparing the control plane path for NRPPa related positioning messages by creating a subscription in the AMF.

The LMF sends an HTTP POST to /namf-comm/v1/non-ue-n2-messages/subscriptions. This tells the AMF that the LMF wants to receive non UE N2 messages that belong to positioning procedures. The key IE is n2InformationClass set to NRPPa. This selects the NRPPa message category so the AMF will route NRPPa transport messages between the LMF side and the RAN side. The other key IE is n2NotifyCallbackUri. This is the callback endpoint where the AMF will deliver future NRPPa related notifications for this positioning session. In this trace it points to the LMF callback path ending with /non_ue_n2_notif_cbk. The request also includes anueList with 3GPP_ACCESS. This scopes the subscription to 3GPP access, which is the normal access type for NR positioning. Finally, nlmfId identifies the LMF instance that owns this subscription, so later notifications can be associated with the correct LMF session.

This shows the network starting the NR eCID measurement phase by sending an NRPPa e-CID Measurement Initiation Request from the LMF side toward the RAN.

The key control fields are procedureCode set to e-CIDMeasurementInitiation and nrppaTransactionID set to 2. nrppaTransactionID is the main handle you use to correlate the following NRPPa responses and any failure indications to this specific measurement attempt.

Inside protocolIEs, lMF-UE-Measurement-ID identifies the measurement instance for this UE. reportCharacteristics indicates how the RAN should report the results. In this capture it is onDemand, which means the gNB should provide the requested measurements immediately rather than waiting for periodic reporting.

The most important content for what is being measured is measurementQuantities. The request explicitly asks for measurementQuantitiesValue items such as cell-ID, angleOfArrival, timingAdvanceType1, and timingAdvanceType2. These are the core inputs used by the LMF to derive an eCID based location estimate.

There are also signal strength and quality items : rSRP and rSRQ. These give the serving cell reference signal power and quality. They are used as basic link metrics that help the LMF interpret coverage and confidence.

The request also includes ss-RSRP and ss-RSRQ. These are SSB based measurements, so they reflect the SSB reference signals rather than CSI-RS. This is useful when SSB is the most stable reference in the current configuration.

The request further includes csi-RSRP and csi-RSRQ. These are CSI-RS based measurements, so they provide another reference type that can improve accuracy when CSI-RS is configured and measurable.

For direction and timing in NR, the decoded list includes angleOfArrivalNR and timingAdvanceNR. angleOfArrivalNR is the angular measurement component, and timingAdvanceNR is the NR timing advance value used as a distance related input in eCID.

The decoded panel also shows optional cross-technology placeholders. otherRATMeasurementQuantities includes EUTRA, meaning the structure can carry LTE related measurement quantities if the UE supports it. wlanMeasurementQuantities includes wlan, meaning the structure can also carry WLAN related measurement quantities when applicable.

After this message, you should see the gNB provide the requested measurements via the corresponding NRPPa measurement response, using the same nrppaTransactionID and the same lMF-UE-Measurement-ID.

This shows an LPP RequestCapabilities message sent from the network side locationServer to the UE. The key identifier is transactionID with transactionNumber set to 0, which is used to match the UE response to this capability query. endTransaction is FALSE, meaning this is not the final message of the transaction.

The core content is lpp-MessageBody set to requestCapabilities. Under criticalExtensions, requestCapabilities-r9 carries the actual capability request structures. a-gnss-RequestCapabilities is present and it includes assistanceDataSupportListReq set to TRUE. This means the network is asking whether the UE supports A-GNSS and whether it can accept a list of supported GNSS assistance data types. otdoa-RequestCapabilities is included as an empty object. This means the network is querying OTDOA capability without requesting any specific sub-features here. ecid-RequestCapabilities is included as an empty object. This means the network is querying E-CID capability. nr-ECID-RequestCapabilities-r16 is included as an empty object. This explicitly asks for Release 16 NR E-CID capability. nr-DL-TDOA-RequestCapabilities-r16 is included as an empty object. This asks for Release 16 NR DL-TDOA capability.

This shows the LMF sending a combined N1 and N2 message package to the AMF so the AMF can forward the positioning signaling to both the UE and the gNB in one coordinated step.

The HTTP POST goes to /namf-comm/v1/ue-contexts/imsi-001010123456789/n1-n2-messages. This endpoint is used when the network needs to deliver an N1 message to the UE and an N2 message to the RAN as part of the same procedure for the same UE context.

The body is multipart/related. The JSON control part defines two containers. n1MessageContainer has n1MessageClass set to LPP and references an LPP PDU by contentId. This is the UE facing positioning message that will be carried over NAS. n2InfoContainer has n2InformationClass set to NRPPa and references an NRPPa PDU by contentId. This is the gNB facing positioning instruction that the AMF will transport on the N2 interface. The two binary parts are then attached by content type. The NRPPa PDU part is carried as application/vnd.3gpp.ngap, which is what the AMF uses to wrap and send the NRPPa payload toward the gNB. The LPP PDU part is carried as application/vnd.3gpp.5gnas, which is what the AMF uses to forward the LPP RequestCapabilities to the UE over NAS.

The key tracking field here is n1n2CorrelationId. This value is used by the AMF to correlate later delivery reports and responses that belong to this combined N1/N2 transmission.

This is the same NRPPa subscription creation step, shown from the AMF side. The AMF log is capturing an incoming HTTP/2 POST from the LMF to the AMF SBI interface at /namf-comm/v1/non-ue-n2-messages/subscriptions.

The key decoded fields are n2InformationClass set to NRPPa and n2NotifyCallbackUri set to the LMF callback endpoint ending with /non_ue_n2_notif_cbk. This tells the AMF to route future non UE N2 NRPPa notifications to that callback.

The payload also includes anTypeList with 3GPP_ACCESS, which scopes the subscription to 3GPP access. nlmfId identifies the LMF instance that owns the subscription so the AMF can associate later notifications with the correct LMF session.

This shows the AMF accepting the NRPPa non UE N2 subscription request and creating a new subscription resource.

The AMF returns HTTP status 201, which means the subscription was successfully created. The Location header contains the newly created resource path under /namf-comm/v1/non-ue-n2-messages/subscriptions/ followed by the subscription identifier.

The response body includes n2NotifySubscriptionId. This is the key value that represents the active subscription. From this point, the AMF can use this subscription to send NRPPa related non UE N2 notifications to the LMF callback URI that was provided in the request.

This shows the LMF asking the AMF to transfer a non UE N2 message toward the gNB, specifically an NRPPa PDU carried inside an NGAP container.

The HTTP POST is sent to /namf-comm/v1/non-ue-n2-messages/transfer. This endpoint is used when the LMF wants the AMF to deliver an N2 message to the RAN without involving the UE NAS path.

globalRanNodeList identifies the target RAN node. The important fields are plmnId with mcc 001 and mnc 01, and gnbId with bitLength 28 and gNBValue 0012345. This tells the AMF exactly which gNB should receive the NRPPa message. n2Information shows n2InformationClass set to NRPPa. This selects NRPPa as the protocol carried over N2 for this transfer. nrppaInfo contains nfid, which is the LMF instance identifier used to associate this transfer with the LMF session context. nrppaPdu then defines the payload reference. It states ngapIeType NRPPa_PDU and it points to ngapData with contentId nrppa-pdu. The actual binary part is attached as Content-Type application/vnd.3gpp.ngap with Content-Id nrppa-pdu. This is the NGAP wrapped NRPPa message that the AMF will forward to the gNB.

This is the AMF response to the LMF after the non UE N2 transfer request was accepted.

The AMF returns HTTP status 200, meaning the request format and target information were valid and the AMF has taken ownership of delivering the N2 message toward the gNB. The key field is result with the value N2_INFO_TRANSFER_INITIATED. This means the AMF has started the N2 information transfer procedure on the N2 interface. It does not mean the gNB has already responded with measurements yet. It only confirms that the delivery process to the RAN side has been initiated successfully.

This shows another non UE N2 transfer request from the LMF to the AMF, again using the path /namf-comm/v1/non-ue-n2-messages/transfer. It is the same delivery mechanism used to push an NRPPa message to the gNB over N2.

globalRanNodeList again identifies the target gNB. The key fields are plmnId with mcc 001 and mnc 01, and gnbId with bitLength 28 and gNBValue 0012345. This is the destination RAN node for the positioning message. n2Information sets n2InformationClass to NRPPa, so the AMF treats the attached payload as an NRPPa procedure. nrppaInfo includes nfid, which ties this transfer to the LMF instance and its positioning session context. nrppaPdu declares ngapIeType NRPPa_PDU and points to ngapData using contentId nrppa-pdu. The attached multipart body includes Content-Type application/vnd.3gpp.ngap with Content-Id nrppa-pdu, which is the actual NGAP wrapped NRPPa payload that will be delivered to the gNB.

This shows an NRPPa e-CID Measurement Initiation Request being delivered to the gNB. The message is identified by procedureCode set to e-CIDMeasurementInitiation and it uses nrppaTransactionID set to 2, which is the main correlation key for the rest of this measurement exchange.

In the protocolIEs list, lMF-UE-Measurement-ID is present and provides the measurement instance identifier that the gNB should echo back in the response. reportCharacteristics is set to onDemand, which means the gNB should provide an immediate one shot report rather than waiting for a periodic reporting cycle.The measurementQuantities IE lists what the network wants to receive from the gNB for eCID. In this view, the requested items include cell-ID, angleOfArrival, and timingAdvanceType1. These are the core eCID inputs used to identify the serving/neighbor cell context, estimate direction, and estimate range via timing advance.

The request includes timingAdvanceType2. This asks the gNB to provide the second timing advance representation used for positioning. It then requests serving signal metrics rSRP and rSRQ. These are the basic NR reference signal power and quality measurements. It also requests SSB based metrics ss-RSRP and ss-RSRQ. These are useful when SSB is the primary reference signal available for stable measurement. It also requests CSI-RS based metrics csi-RSRP and csi-RSRQ. These provide measurements tied to CSI reference signals when CSI-RS is configured. The request adds NR specific directional and timing items angleOfArrivalNR and timingAdvanceNR, which are the NR oriented versions of the angle and timing advance quantities used in eCID processing. Finally, the message includes optional groups for other technologies. otherRATMeasurementQuantities contains an EUTRA placeholder and wlanMeasurementQuantities contains a wlan placeholder. Both are marked with criticality ignore, meaning the gNB can ignore these parts if they are not supported or not applicable.

This shows an RRC reconfiguration that installs the measurement configuration the UE will use to provide radio measurements needed by the positioning procedure.

measConfig contains reportConfigToAddModList. Two report configurations are added. reportConfigId 2 and reportConfigId 3 are both periodic reports. reportInterval is ms120 and reportAmount is r1, so the UE is instructed to produce one periodic report at a 120 ms cadence. reportQuantityCell requests rsrp and rsrq, and sinr is set to FALSE. maxReportCells is 1, includeBeamMeasurements is FALSE, and useAllowedCellList is FALSE. measIdToAddModList links measurement IDs to these report configurations. measId 2 points to measObjectId 2 and reportConfigId 2. measId 3 points to measObjectId 2 and reportConfigId 3. This mapping tells the UE which measurement object should be measured and which report rule should be used for each report stream. measGapConfig enables measurement gaps. gapUE is set to setup, with gapOffset 18. mgl is ms6, mgrp is ms40, and mgta is ms0dot5. This configures periodic measurement gaps so the UE can pause normal activity and perform measurements that may require additional RF time, which helps when positioning needs extra measurement opportunities.

This decoded panel shows how the LPP RequestCapabilities is delivered to the UE over NAS.

The key field is payload container type set to 3, which indicates an LPP payload. This tells the UE that the payload container contains an LTE Positioning Protocol message. Inside the payload, the LPP message is RequestCapabilities. transactionID is present with transactionNumber set to 0 and endTransaction set to FALSE, so the UE must respond using the same transactionNumber. In requestCapabilities-r9, a-gnss-RequestCapabilities requests GNSS support and sets assistanceDataSupportListReq to TRUE, meaning the network wants the UE to report which GNSS assistance data types it supports. otdoa-RequestCapabilities and ecid-RequestCapabilities are included to query OTDOA and E-CID capability. The NR extensions nr-ECID-RequestCapabilities-r16 and nr-DL-TDOA-RequestCapabilities-r16 are also present, which asks the UE to declare support for NR eCID and NR DL-TDOA capability in Release 16 terms.

This shows the downlink delivery step on the RRC side after the core network prepared the LPP message. Basically this is the encapsulation of the NAS message shown in previous log.

This shows the UE specific subscription setup for combined N1 and N2 positioning related notifications. The LMF sends an HTTP POST to /namf-comm/v1/ue-contexts/imsi-001010123456789/n1-n2-messages/subscriptions. This creates a subscription tied to one UE context, identified by the IMSI in the path.

The key fields are n2InformationClass set to NRPPa and n2NotifyCallbackUri set to an LMF callback URL. This tells the AMF to notify the LMF when NRPPa related N2 events for this UE occur, such as positioning measurement delivery or gNB responses. The request also includes n1MessageClass set to LPP and n1NotifyCallbackUri set to another LMF callback URL. This tells the AMF to notify the LMF when LPP related N1 events for this UE occur, such as UE responses to RequestCapabilities or later LPP messages. The identifiers nfid and imei are included so the subscription can be associated with the correct LMF instance and the correct device identity when notifications arrive. This is important when multiple UEs or multiple parallel positioning sessions are running.

This shows the AMF acknowledging creation of the UE specific N1/N2 subscription. The AMF returns HTTP status 201, which means the subscription resource was successfully created for the UE context identified by the IMSI in the request path.

The Location header provides the resource URI of the new subscription under /namf-comm/v1/ue-contexts/imsi-001010123456789/n1-n2-messages/subscriptions/ followed by the assigned subscription identifier. The response body contains n1n2NotifySubscriptionId. This is the key identifier for the UE specific subscription. The AMF will use this subscription to send both N1 LPP and N2 NRPPa notifications for this UE to the callback URIs that were provided in the subscription request.

This shows a UE specific combined N1 and N2 message transfer request from the LMF to the AMF. The HTTP POST goes to /namf-comm/v1/ue-contexts/imsi-001010123456789/n1-n2-messages, so the delivery is tied to a single UE context identified by the IMSI in the path.

The JSON part contains n1MessageContainer and n2InfoContainer. n1MessageContainer has n1MessageClass set to LPP and points to an LPP PDU using contentId lpp-pdu. n2InfoContainer has n2InformationClass set to NRPPa and points to an NRPPa PDU using contentId nrppa-pdu. This means the AMF will deliver an LPP message to the UE over NAS and an NRPPa message to the gNB over N2 as part of the same UE specific transaction. nfid is included to associate the transfer with the LMF instance. lcsCorrelationId is included to correlate this combined transfer with the overall positioning procedure. n1n2FailureTxfNotifURI provides the failure notification callback for this transfer. pei carries the device identity so the AMF can match the message to the correct UE equipment record. The multipart parts show the payload types. The NRPPa part is attached as application/vnd.3gpp.ngap with Content-Id nrppa-pdu. The LPP NAS part is attached as application/vnd.3gpp.5gnas with Content-Id lpp-pdu.

This is the AMF response to the UE specific N1/N2 message transfer request. The AMF returns HTTP status 200, meaning the combined N1/N2 transfer request was accepted and is being processed. The key field is cause with the value N1_N2_TRANSFER_INITIATED. This indicates the AMF has started delivering the N1 message toward the UE and the N2 message toward the gNB for this UE context. It confirms initiation of delivery, not the final delivery result or any UE or gNB response yet.

This shows the UE facing N1 delivery part of the UE specific N1/N2 transfer. The AMF has wrapped the LPP message into a downlink NAS transport so it can be delivered to the UE.

The outer NAS message is DL NAS transport with protocol discriminator 5GMM and a security header indicating the message is integrity protected and ciphered. This confirms the LPP signaling is being sent under the active NAS security context.

The key field is payload container type set to 3, which indicates the payload is an LPP message. The payload itself is an LPP RequestCapabilities. It carries transactionID with transactionNumber 0 and endTransaction FALSE, so the UE must answer with ProvideCapabilities using the same transactionNumber. Inside requestCapabilities-r9, the network is querying a-gnss-RequestCapabilities with assistanceDataSupportListReq TRUE and also includes otdoa-RequestCapabilities and ecid-RequestCapabilities. The NR extensions nr-ECID-RequestCapabilities-r16 and nr-DL-TDOA-RequestCapabilities-r16 are also present, so the UE is asked to declare NR eCID and NR DL-TDOA capability support as well.

This shows an AMF notification delivered to the LMF callback for the non UE N2 subscription.

The HTTP POST goes to /namf-comm/v1/non_ue_n2_notif_cbk, which is the callback URI the LMF previously registered in the global non UE N2 subscription. The key field that ties it back to that subscription is n2NotifySubscriptionId, which matches the global subscription ID created earlier.

The notification body carries n2InfoContainer with n2InformationClass set to NRPPa. This tells the LMF that the attached payload is an NRPPa related N2 notification coming from the RAN side. Inside nrppaInfo, nfid identifies the LMF instance context, and nrppaPdu points to an attached NGAP part using contentId notifyN2. The multipart attachment is Content-Type application/vnd.3gpp.ngap with Content-Id notifyN2. This NGAP wrapped NRPPa payload is the actual radio side response or indication that the AMF is forwarding to the LMF as part of the positioning procedure.

This is the AMF response confirming creation of the global non UE N2 subscription that the LMF requested earlier.

The AMF returns HTTP status 201, meaning the subscription resource was successfully created. The Location header gives the URI of the created resource under /namf-comm/v1/non-ue-n2-messages/subscriptions/ followed by the subscription identifier. The response body contains n2NotifySubscriptionId set to 0000000000000001. This ID is the handle for the global subscription. The AMF will use this subscription to send future NRPPa non UE N2 notifications to the LMF callback URI that was registered in the subscription request.

This is the AMF response to the non UE N2 transfer request.

The AMF returns HTTP status 200, meaning the request was accepted and processed at the SBI layer. The response body contains result set to N2_INFO_TRANSFER_INITIATED. This indicates the AMF has started the N2 information transfer procedure toward the gNB for the attached NRPPa payload. It confirms initiation of delivery on N2, not the completion of delivery and not the measurement result itself.

This shows the UE response to the earlier LPP RequestCapabilities, carried in an uplink UL NAS transport.

The outer NAS message is UL NAS transport in 5GMM with security header showing integrity protection and ciphering. payload container type is 3, so the payload is an LPP message. The LPP payload is provideCapabilities. transactionID matches the earlier request with transactionNumber 0, and endTransaction is TRUE, meaning the capability exchange is complete for this transaction. The acknowledgement section includes ackRequested TRUE, which confirms the UE recognized the request and is asking for an acknowledgement behavior as defined by LPP.

In provideCapabilities-r9, the decoded content lists what the UE can support. It includes a-gnss-ProvideCapabilities with gnss-SupportList and gnss-IDs, plus gnss-Modes. It also lists locationCoordinateTypes, indicating which coordinate formats the UE can report, such as ellipsoidPoint and ellipsoidPointWithAltitude. The decoded panel also contains Release 16 NR capability blocks. nr-ECID-ProvideCapabilities-r16 indicates the UE supports NR eCID measurement reporting, including periodic and triggered reporting capability. nr-DL-TDOA-ProvideCapabilities-r16 indicates NR DL-TDOA related capability, and it includes detailed PRS related capability groups. Within the NR DL-TDOA PRS capability details, the decoded panel shows limits like maxNrofDL-PRS-ResourceSetPerTRPPerFrequencyLayer and maxNrofTRP-AcrossFreqs, and it lists supported bands in dl-PRS-ResourcesBandCombinationList-r16 with bandList-r16 including band 78. It also shows measurement and processing capability items such as dl-RSTD-MeasurementPerPairOfTRP-FR1-r16, supportOfDL-PRS-RSRP-MeasFR1-r16, and processing related items in nr-DL-PRS-QCL-ProcessingCapability-r16 and nr-DL-PRS-ProcessingCapability-r16, including buffer type and processing duration parameters.

This decoded panel shows a UE specific N1 notification being pushed from the AMF to the LMF callback.

The HTTP POST goes to /namf-comm/v1/N1/imsi-001010123456789/notify/imei=012345670000001. This path indicates it is an N1 side notification tied to a specific UE context (IMSI) and device identity (IMEI), using the callback URI that was registered in the UE specific N1/N2 subscription. The key correlation field is n1NotifySubscriptionId. It is set to 0000000000000002, which matches the UE specific subscription that the AMF created earlier. This tells the LMF that this notification belongs to that UE specific N1 subscription, not the global non UE subscription.

The JSON body includes n1MessageContainer with n1MessageClass set to LPP. This means the attached payload is an LPP message coming from the UE. n1MessageContent points to a multipart attachment using contentId notifyN1. The attached part has Content-Type application/vnd.3gpp.5gnas and Content-Id notifyN1. This attachment is the actual NAS container carrying the UE generated LPP ProvideCapabilities message. The notification also carries context fields like nfid to associate it with the LMF instance, lcsCorrelationId to correlate with the overall positioning procedure, and radio context such as ncgi and nrCellId so the LMF knows which serving cell the UE was attached to when the capability information was reported.

This shows the LPP ProvideCapabilities message after it has been fully decoded by the network location side.

transactionID shows transactionNumber 0 and endTransaction TRUE, confirming it is the UE response that closes the earlier RequestCapabilities transaction. acknowledgement shows ackRequested TRUE, indicating the UE is requesting the acknowledgement behavior defined in LPP. The main content is provideCapabilities-r9. commonIEsProvideCapabilities includes lpp-message-segmentation-r14, indicating the UE supports LPP message segmentation. a-gnss-ProvideCapabilities shows gnss-SupportList with gnss-Id set to gps and gnss-Signals indicating the supported GPS signals. agnss-Modes is present with posModes. adr-Support and velocityMeasurementSupport are FALSE. locationCoordinateTypes lists which coordinate formats the UE can report. ellipsoidPoint is TRUE and ellipsoidPointWithAltitude is TRUE, while other formats like uncertainty circle and ellipse types are FALSE. nr-ECID-ProvideCapabilities-r16 indicates NR eCID support. It shows nr-ECID-MeasSupported-r16 and reporting support flags including periodicalReporting-r16 supported and triggeredReporting-r16 supported. nr-DL-TDOA-ProvideCapabilities-r16 indicates NR DL-TDOA related capability. nr-DL-TDOA-Mode-r16 is present with posModes, showing the UE supports the NR DL-TDOA positioning mode category that the network queried.

nr-DL-TDOA-PRS-Capability-r16 reports the UE limits for PRS resource handling. maxNrofDL-PRS-ResourceSetPerTRPPerFrequencyLayer-r16 is 1, meaning the UE can handle one PRS resource set per TRP per frequency layer. maxNrofTRP-AcrossFreqs-r16 is 4, meaning it can handle up to four TRPs across frequency layers. maxNrofPosLayers-r16 is 1, meaning one positioning frequency layer is supported. dl-PRS-ResourcesCapabilityBandList-r16 and dl-PRS-ResourcesBandCombinationList-r16 show band support. freqBandIndicatorNR-r16 and bandList-r16 indicate band 78 is supported for PRS based positioning. nr-DL-TDOA-MeasurementCapability-r16 shows measurement support for RSTD and PRS RSRP. dl-RSTD-MeasurementPerPairOfTRP-FR1-r16 is 1 and dl-RSTD-MeasurementPerPairOfTRP-FR2-r16 is 1, indicating the UE can measure RSTD per TRP pair in both FR1 and FR2. supportOfDL-PRS-RSRP-MeasFR1-r16 is supported and supportOfDL-PRS-RSRP-MeasFR2-r16 is supported, indicating PRS RSRP measurement support for both ranges.

nr-DL-PRS-QCL-ProcessingCapability-r16 provides the QCL processing capability band list and again indicates freqBandIndicatorNR-r16 is 78. nr-DL-PRS-ProcessingCapability-r16 reports PRS processing constraints. supportBandIndicatorNR-r16 is 78. dl-PRS-BufferType-r16 is type1, which describes the buffering model the UE uses for PRS processing. durationOfPRS-Processing-r16 is n1 and durationOfPRS-ProcessingSymbols-r16 is n1, indicating minimal stated processing duration. durationOfPRS-ProcessingSymbolsInEveryTms-r16 is n8, indicating the UE can process up to that number of PRS symbols per millisecond window. maxNumOfDL-PRS-ProcessedPerSlot-r16 is 6, indicating the UE can process up to six PRS resources per slot. maxSupportedFreqLayers-r16 is 1, confirming single frequency layer support. periodicalReporting-r16 is present with posModes, indicating the UE can do periodic reporting for these NR positioning measurements.

This shows an LPP Ack message handled on the network side after the capability exchange.

The message type is Ack and it contains an acknowledgement container. ackRequested is FALSE, meaning this Ack does not request a further acknowledgement in return. ackIndicator is 0, which is the value used to relate this Ack to the previously received LPP message in the same flow. endTransaction is FALSE, which means the overall LPP transaction context remains open for the next positioning messages, such as RequestLocationInformation and later measurement reporting.

This shows another UE specific N1/N2 message transfer request from the LMF to the AMF, but in this case it carries only an N1 LPP payload.

The HTTP POST goes to /namf-comm/v1/ue-contexts/imsi-001010123456789/n1-n2-messages, so it is explicitly tied to the UE context identified by that IMSI. The JSON body contains n1MessageContainer with n1MessageClass set to LPP. n1MessageContent points to contentId lpp-pdu, and the multipart attachment includes Content-Type application/vnd.3gpp.5gnas with Content-Id lpp-pdu. This means the AMF will deliver an LPP message to the UE over NAS, without an accompanying NRPPa N2 payload in this transfer. nfid ties the request to the LMF instance. lcsCorrelationId is present as the session correlation tag used across the positioning flow. n1n2FailureTxfNotifURI provides the failure notification callback for this transfer. pei carries the device identity so the AMF can bind the message to the correct UE equipment record during delivery.

The  shows an LPP RequestLocationInformation message sent by the locationServer to start the actual positioning measurement and reporting phase.

transactionID is present with transactionNumber 1. endTransaction is FALSE, so this request opens a new transaction that will be completed by the UE response. In requestLocationInformation-r9, locationInformationType is set to locationEstimatePreferred. This means the network is asking for a position estimate result rather than only raw measurement data. qos is present with responseTime set to 3, so the UE is expected to deliver the result within about 3 seconds. verticalCoordinateRequest is FALSE, so altitude is not requested. responseTimeEarlyFix-r12 is 1, which indicates the network also allows an early fix behavior. velocityRequest is FALSE, so the UE is not asked to report velocity. locationCoordinateTypes indicates which coordinate formats are acceptable. ellipsoidPoint is TRUE and ellipsoidPointWithAltitude is TRUE, while the other uncertainty ellipse and polygon formats are FALSE. This tells the UE what output formats the server can accept for the location estimate. segmentationInfo-r14 is set to noMoreMessages, meaning message segmentation is not being used for this request. a-gnss-RequestLocationInformation contains the positioningInstructions and gnss-Method with gnss-id. fineTimeAssistanceMeasReq is FALSE, adrMeasReq is FALSE, multipleFreqMeasReq is FALSE, and assistanceAvailability is FALSE. This means the request is using a minimal A-GNSS method request without additional fine time or multi frequency measurement assistance. nr-ECID-RequestLocationInformation-r16 is included, indicating the procedure should also use NR eCID related information for the location estimate. nr-DL-TDOA-RequestLocationInformation-r16 is included. It shows nr-RequestedMeasurements with nr-RequestedMeasurements-r16 and nr-AssistanceAvailability-r16 FALSE, meaning the network is requesting NR DL-TDOA related measurements but is not indicating that assistance data is available in this step.

This shows the SBI request that actually delivers the LPP RequestLocationInformation to the UE, using a UE specific N1/N2 message transfer.

The HTTP POST goes to /namf-comm/v1/ue-contexts/imsi-001010123456789/n1-n2-messages. Because the IMSI is in the path, the request is bound to that single UE context. The payload is multipart/related. The JSON part contains n1MessageContainer with n1MessageClass set to LPP and n1MessageContent pointing to contentId lpp-pdu. This tells the AMF the message is an N1 LPP payload to be sent to the UE. The attached part has Content-Type application/vnd.3gpp.5gnas with Content-Id lpp-pdu. This is the NAS container that carries the LPP RequestLocationInformation message. The request also includes nfid to identify the LMF instance, lcsCorrelationId to correlate this delivery with the ongoing positioning session, n1n2FailureTxfNotifURI to specify where the AMF should report delivery failures, and pei with the UE IMEI so the AMF can associate the transfer with the correct device identity.

This is the AMF response to the UE specific N1/N2 message transfer that carried the LPP RequestLocationInformation.

The AMF returns HTTP status 204, which means the request was accepted but there is no response body to return. This is used when the AMF has nothing additional to report at the SBI layer beyond successful reception. The practical meaning is that the AMF has taken the LPP payload and will proceed with delivery toward the UE over the radio path, and any later outcomes will be reported via the configured notification callbacks rather than in this immediate HTTP response.

This shows the LMF sending the UE specific N1 message transfer to the AMF that carries the LPP request toward the test UE.

The HTTP POST target is /namf-comm/v1/ue-contexts/imsi-001010123456789/n1-n2-messages, so the message is bound to the UE context for that IMSI. The JSON container includes n1MessageContainer with n1MessageClass set to LPP and n1MessageContent pointing to contentId lpp-pdu. This tells the AMF the payload is an LPP N1 message to be delivered to the UE. The attached multipart part has Content-Type application/vnd.3gpp.5gnas with Content-Id lpp-pdu. This is the NAS encoded LPP payload that the AMF will forward over the radio path. The request carries nfid to identify the LMF instance, lcsCorrelationId to link it to the ongoing location procedure, n1n2FailureTxfNotifURI to define where failure notifications should be sent, and pei with the UE IMEI to bind delivery to the specific device.

This is the AMF response to the UE specific N1 transfer request that carried the LPP RequestLocationInformation.

The AMF returns HTTP status 200, meaning the request was accepted and the transfer procedure has started. The key field is cause with the value N1_N2_TRANSFER_INITIATED. In this context, it indicates the AMF has initiated delivery of the N1 payload toward the UE. It confirms initiation of delivery, but it does not yet confirm that the UE has received the message or that the UE has produced the location result.

This shows a downlink DL NAS transport carrying an LPP Ack from the network to the UE.

The outer NAS container is DL NAS transport in 5GMM with a security header indicating integrity protection and ciphering, so the acknowledgement is delivered under the active NAS security context. payload container type is 3, which indicates the payload is an LPP message. The embedded LPP message is Ack. Inside the acknowledgement field, ackRequested is FALSE and ackIndicator is 0. This tells the UE that the network has acknowledged the earlier UE message without requesting another acknowledgement back. endTransaction is FALSE, which means the positioning session remains open and the UE should stay ready for the next LPP procedure step, such as RequestLocationInformation and the follow up measurement and location reporting.

This shows the LMF initiating a UE specific N1/N2 message transfer toward the AMF to deliver an LPP payload.

The HTTP request is a POST to /namf-comm/v1/ue-contexts/imsi-001010123456789/n1-n2-messages. This path binds the transfer to the UE context identified by that IMSI. user-agent is LMF, so this is coming from the location server side. The body is multipart/related. The JSON control section includes n1MessageContainer with n1MessageClass set to LPP and it references n1MessageContent by contentId lpp-pdu. This means the transfer is N1 only and the AMF will forward the LPP message to the UE over NAS. The second part is the actual binary NAS payload. It is attached as Content-Type application/vnd.3gpp.5gnas with Content-Id lpp-pdu. This binary content is the encoded LPP message being delivered in this step. The request also includes nfid to identify the LMF instance, lcsCorrelationId to link this transfer to the ongoing location procedure, n1n2FailureTxfNotifURI to define where failures should be reported, and pei carrying the UE IMEI so the AMF can associate the transfer with the correct device identity.

This is the AMF response to the UE specific N1/N2 transfer request that carried the LPP message.

The AMF returns HTTP status 200, which means the request was accepted and the delivery procedure has been started. The key field is cause with the value N1_N2_TRANSFER_INITIATED. In this case it confirms the AMF has initiated delivery of the N1 payload toward the UE for this IMSI context. It is an internal handoff confirmation, not the UE receipt and not the final positioning result.

This shows the LPP RequestLocationInformation being delivered to the UE inside a DL NAS transport, so these are the positioning instructions that the UE positioning engine will execute.

The key identifier is transactionID with transactionNumber 1. endTransaction is FALSE, so the UE is expected to respond later with ProvideLocationInformation for the same transaction. The requestLocationInformation payload sets locationInformationType to locationEstimatePreferred. This tells the UE to compute a position estimate result, not only to return raw measurement data. qos is included with responseTime set to 3, so the UE should attempt to produce the result within that time budget. verticalCoordinateRequest is FALSE and velocityRequest is FALSE, so altitude and velocity are not requested. locationCoordinateTypes indicates the allowed output formats. ellipsoidPoint and ellipsoidPointWithAltitude are TRUE, so the UE can return latitude and longitude and may include altitude if available. In the method specific parts, a-gnss-RequestLocationInformation is present with gnss-Method and basic positioningInstructions, while fineTimeAssistanceMeasReq, adrMeasReq, and multipleFreqMeasReq are all FALSE and assistanceAvailability is FALSE, meaning no extra GNSS assistance or special measurement requests are being used here. nr-ECID-RequestLocationInformation-r16 is present, so NR eCID is requested as part of the location estimate process. nr-DL-TDOA-RequestLocationInformation-r16 is also present. It includes nr-RequestedMeasurements-r16 and sets nr-AssistanceAvailability-r16 to FALSE, meaning the network is not providing NR DL-TDOA assistance data in this step, even though the UE has indicated support for NR DL-TDOA capability.

This shows an RRC UL information transfer message, which is how the UE sends a dedicated NAS payload back to the core network over the RRC signaling channel. This is just RRC Encapsulation of  NAS message

This shows the UE sending LPP ProvideCapabilities inside an uplink UL NAS transport, which is the direct response to the earlier LPP RequestCapabilities.

The outer NAS message is UL NAS transport with payload container type 3, meaning the payload is an LPP message. The LPP transactionID uses transactionNumber 0, and endTransaction is TRUE, so the UE is closing the capability exchange transaction. acknowledgement shows ackRequested TRUE, which means the UE expects the network to send an LPP Ack back. In provideCapabilities-r9, commonIEsProvideCapabilities includes lpp-message-segmentation-r14, indicating the UE supports segmented LPP messages. a-gnss-ProvideCapabilities indicates GNSS support with gnss-SupportList showing gnss-Id gps, plus gnss-Signals and agnss-Modes. locationCoordinateTypes shows what coordinate outputs the UE can provide, with ellipsoidPoint TRUE and ellipsoidPointWithAltitude TRUE. nr-ECID-ProvideCapabilities-r16 is present and indicates NR eCID measurement support. It includes nr-ECID-MeasSupported-r16 and shows both periodicalReporting-r16 supported and triggeredReporting-r16 supported. nr-DL-TDOA-ProvideCapabilities-r16 is present and provides NR DL-TDOA related support and detailed DL-PRS capability. nr-DL-TDOA-PRS-Capability-r16 reports limits such as maxNrofDL-PRS-ResourceSetPerTRPPerFrequencyLayer-r16 equal to 1, maxNrofTRP-AcrossFreqs-r16 equal to 4, and maxNrofPosLayers-r16 equal to 1. dl-PRS-ResourcesBandCombinationList-r16 indicates support for band 78. nr-DL-TDOA-MeasurementCapability-r16 indicates RSTD measurement per TRP pair in FR1 and FR2 and shows PRS RSRP measurement support for FR1 and FR2. nr-DL-PRS-QCL-ProcessingCapability-r16 and nr-DL-PRS-ProcessingCapability-r16 report processing capability for band 78, including dl-PRS-BufferType-r16 type1, processing duration fields, maxNumOfDL-PRS-ProcessedPerSlot-r16 equal to 6, and maxSupportedFreqLayers-r16 equal to 1. periodicalReporting-r16 with posModes indicates periodic reporting capability for these NR positioning measurements.

This is a DL NAS transport that carries an LPP Ack from the network to the UE.

payload container type is 3, so the embedded payload is an LPP message. The LPP payload shown on the right is acknowledgement, not a new request. endTransaction is FALSE, which means the LPP session remains open and the network may send more positioning messages after this. In the acknowledgement field, ackRequested is FALSE. This means the network is not asking the UE to acknowledge this Ack. ackIndicator is 0. This value links the Ack to the previous UE LPP message that requested acknowledgement, so the UE can match this receipt to the correct prior transaction.

This shows the downlink RRC carrier that transports a NAS message from the network to the UE. This is just RRC Encapsulation of a NAS message (DL NAS Transport in this case)

This is the DL NAS transport that carries the LPP RequestLocationInformation to the UE. It is the point where the locationServer gives the UE the concrete positioning task.

transactionID shows transactionNumber 1 and endTransaction is FALSE, so this is an active location transaction that will be completed by the UE response. lpp-MessageBody is requestLocationInformation. locationInformationType is locationEstimatePreferred, so the UE is asked to compute and return a position estimate. qos includes responseTime 3, verticalCoordinateRequest FALSE, and velocityRequest FALSE. This means the UE should respond within about 3 seconds, and the network is not requesting altitude or velocity as mandatory inputs. locationCoordinateTypes shows ellipsoidPoint TRUE and ellipsoidPointWithAltitude TRUE. This means the network can accept either a 2D latitude/longitude point or a latitude/longitude point with altitude if available. a-gnss-RequestLocationInformation is present with gnss-Method and basic positioningInstructions. fineTimeAssistanceMeasReq FALSE, adrMeasReq FALSE, multipleFreqMeasReq FALSE, and assistanceAvailability FALSE indicate no extra GNSS assistance or special measurements are requested here. nr-ECID-RequestLocationInformation-r16 is included, so NR eCID based information is requested for the estimate. nr-DL-TDOA-RequestLocationInformation-r16 is included with nr-RequestedMeasurements-r16 and nr-AssistanceAvailability-r16 FALSE, meaning the network requests NR DL-TDOA related measurements but is not providing DL-TDOA assistance data in this step.

This shows the downlink RRC carrier that transports a NAS message from the network to the UE. This is just RRC Encapsulation of a NAS message (DL NAS Transport in this case)

This shows the UE sending an RRC UL information transfer. It is the radio layer wrapper used when the UE sends a dedicated NAS message back toward the core network.

This shows the UE's LPP ProvideLocationInformation response for transactionNumber 1. endTransaction is TRUE, which means the UE is closing this location request transaction and returning everything it could gather for this request.

Under a-gnss-ProvideLocationInformation, the UE reports a locationError with cause set to undefined. This means the GNSS part of the request did not produce a valid location estimate in this attempt, so the A-GNSS method did not succeed here. At the same time, the NR eCID part does return usable radio measurements. Under nr-ECID-ProvideLocationInformation-r16, the UE reports nr-PrimaryCellMeasuredResults-r16 for nr-PhysCellId 501 on NR ARFCN 633300. The reported serving cell values are nr-RSRP 89 and nr-RSRQ 65. It also includes SSB based results in resultSSB-Cell-r16, again showing SSB index 0 with nr-RSRP 89 and nr-RSRQ 65. The UE also reports neighbor cell measurements in nr-MeasuredResultsList-r16. For nr-PhysCellId 500 on NR ARFCN 627300, it provides measured results with nr-RSRP 83 and nr-RSRQ 65. The SSB specific result for that neighbor cell is also included in resultSSB-Indexes-r16 with SSB index 0, nr-RSRP 83, and nr-RSRQ 65. So the important point is that the GNSS based estimate failed, but the UE still successfully returned NR eCID measurement data for the serving cell and neighbor cell, which can be used by the network for positioning.

This shows a DL NAS transport carrying an LPP Ack from the network to the UE.

The embedded LPP message is an acknowledgement. ackIndicator is 1, which means this Ack is tied to the previous UE LPP message in transaction 1, namely the UE response that carried ProvideLocationInformation. ackRequested is FALSE, so the network is not asking the UE to send another LPP acknowledgement back for this packet. endTransaction is FALSE. This means the Ack itself does not close the broader LPP session context, even though it confirms receipt of the previous UE message.

This shows DL information transfer on the RRC layer. It is the radio layer wrapper used by the gNB to deliver a dedicated NAS message from the core network to the UE.

This shows the UE sending the final LPP ProvideLocationInformation for transactionNumber 1. The key point is endTransaction TRUE, which means the UE has finished this specific location request and is returning the last location related information it could collect.

The A-GNSS part reports a failure. Under a-gnss-ProvideLocationInformation, the UE sends locationError with cause set to undefined. This means the satellite based method did not produce a usable location estimate in this attempt. The NR eCID part succeeds and provides usable radio measurements. In nr-ECID-ProvideLocationInformation-r16, the serving cell is reported in nr-PrimaryCellMeasuredResults-r16 with nr-PhysCellId 501 and nr-ARFCN-r16 633300. The reported serving cell values are nr-RSRP 89 and nr-RSRQ 65. The SSB specific result is also included with sSB-Index 0, nr-RSRP 89, and nr-RSRQ 65. The UE also reports neighbor cell measurement results in nr-MeasuredResultsList-r16. For nr-PhysCellId 500 on nr-ARFCN-r16 627300, it reports nr-RSRP 83 and nr-RSRQ 65. The SSB result for that neighbor cell is also included with sSB-Index 0, nr-RSRP 83, and nr-RSRQ 65. Overall, this message means the UE could not provide the requested A-GNSS location estimate, but it successfully returned NR eCID measurement data for both the serving cell and the neighbor cell, which the network can still use for positioning.

This shows the AMF forwarding the UE's LPP response to the LMF through the UE specific N1 notification callback.

The HTTP POST goes to /namf-comm/v1/N1/imsi-001010123456789/notify/imei=012345670000001. This means the notification is tied to the specific UE identified by IMSI 001010123456789 and IMEI 012345670000001. n1NotifySubscriptionId is 0000000000000002. This matches the UE specific N1 subscription that was created earlier, so the LMF knows this message belongs to that LPP session. n1MessageContainer shows n1MessageClass set to LPP. This confirms that the attached payload is the UE's LPP message, not a generic NAS notification. The notification also includes lcsCorrelationId, which links this message to the same positioning session, and location context fields such as GUAMI and NCGI. In NCGI, the NR Cell ID is 001234502, so the LMF can identify the serving cell context from which the UE sent the response. The attached part with Content-Type application/vnd.3gpp.5gnas and Content-Id notifyN1 is the actual NAS container carrying the UE's LPP ProvideLocationInformation message. This is how the UE's final positioning response is delivered from the AMF back to the LMF.

This shows the LPP ProvideLocationInformation message after it has reached the location server side and been fully decoded.

The key transaction fields are transactionNumber 1 and endTransaction TRUE. This means the UE is closing this location request transaction and returning the final result it could produce. ackRequested is TRUE, so the UE is also asking the location server to acknowledge receipt of this message at the LPP layer. For the A-GNSS part, the UE does not provide a valid GNSS position. Under a-gnss-ProvideLocationInformation, it reports locationError with cause undefined. In other words, the GNSS based method did not succeed in this attempt. For the NR eCID part, the UE does provide useful radio measurement data. In nr-ECID-ProvideLocationInformation-r16, the primary cell result is for PCI 501 on ARFCN 633300, with nr-RSRP 89 and nr-RSRQ 65. The SSB specific result for that same serving cell is also included with SSB index 0, again showing nr-RSRP 89 and nr-RSRQ 65. The UE also reports neighbor cell data in nr-MeasuredResultsList-r16. The neighbor cell is PCI 500 on ARFCN 627300, with nr-RSRP 83 and nr-RSRQ 65. Its SSB specific result is also included with SSB index 0, showing nr-RSRP 83 and nr-RSRQ 65. So the overall meaning is clear. The GNSS estimate failed, but the UE successfully returned NR eCID measurement results for both the serving cell and the neighbor cell. Those measurements are the data the network can now use for the eCID based location estimate.

This shows the LPP Ack generated by the location server after it received the UE's ProvideLocationInformation.

The key field is ackIndicator set to 1. This tells you that this message is acknowledging the previous UE LPP message in transaction 1, which is the ProvideLocationInformation carrying the final positioning data. ackRequested is FALSE. This means the network is not asking the UE to send another acknowledgement back for this Ack. endTransaction is FALSE. So even though this message acknowledges receipt of the UE report, the LPP layer itself is not explicitly closing the overall session with this packet.

This shows the LMF sending another UE specific N1 message through the AMF so the message can be delivered down to the UE.

The HTTP POST goes to /namf-comm/v1/ue-contexts/imsi-001010123456789/n1-n2-messages. This means the transfer is tied to the UE context identified by IMSI 001010123456789. The sender is the LMF, as shown by user-agent LMF. The JSON control part contains n1MessageContainer with n1MessageClass set to LPP. This tells the AMF that the payload is an LPP message for the UE. The message is N1 only, so it is a UE directed NAS delivery rather than an NRPPa transfer to the gNB. The request also includes nfid, lcsCorrelationId, and pei. nfid identifies the LMF instance. lcsCorrelationId ties this message to the same ongoing positioning session. pei carries the UE IMEI, so the AMF can bind the delivery to the correct device. The multipart attachment has Content-Type application/vnd.3gpp.5gnas and Content-Id lpp-pdu. That binary payload is the actual NAS encoded LPP message. In this step, it is the LPP Ack that the network is sending back to the UE after receiving the UE's ProvideLocationInformation.

This indicates that the LPP side and the NRPPa side did not both complete successfully enough to produce a final NR eCID location estimate.

The first line, NR eCID: NRPPa meas results not received, means the location server did not receive the required network side NRPPa measurement results from the gNB. In other words, the UE to server path over LPP worked and the UE did send its measurement information, but the gNB to server path over NRPPa did not return the measurement response that the location server expected. The second line, NR ECID UE position estimation error, is the consequence of that missing NRPPa data. Even though the UE reported serving cell and neighbor cell measurements through LPP, the server could not complete the final position calculation because the full NR eCID procedure needs the corresponding network side measurement information as well. So the overall meaning is that the UE side reporting succeeded, but the network side NRPPa measurement reporting failed or was not delivered, and therefore the final NR eCID position estimate could not be generated.

This shows a normal successful SBI acknowledgement between network functions.

The HTTP status is 204 No Content. In 5G SBA, this means the receiving network function accepted and processed the request successfully, but it does not need to return any payload body. In this context, it indicates that the AMF to LMF notification or the related callback handling completed successfully at the HTTP interface level. The signaling message was received, understood, and consumed correctly, so there is nothing more to send back in the response. So this line is not an error and not a missing decode. It is simply the expected confirmation that the inter-network-function signaling exchange finished successfully.

This shows the LMF sending a UE specific N1 message transfer to the AMF after it received the UE's ProvideLocationInformation.

The HTTP POST goes to /namf-comm/v1/ue-contexts/imsi-001010123456789/n1-n2-messages, so the message is targeted to that specific UE context. The sender is the LMF, as shown by user-agent LMF. The key field is n1MessageClass set to LPP. This means the payload being pushed to the UE is an LPP message. In this case, the attached binary payload 2402 is the encoded LPP Ack that the LMF is sending back to acknowledge the UE's previous ProvideLocationInformation message. The request also includes lcsCorrelationId, which ties this delivery to the same positioning session, and pei, which identifies the UE device by IMEI. The multipart attachment with Content-Type application/vnd.3gpp.5gnas and Content-Id lpp-pdu is the actual NAS container that the AMF will forward to the UE.

This shows the AMF response to the LMF after the LMF asked it to deliver the LPP Ack to the UE. The HTTP status is 200, which means the AMF accepted the request successfully at the SBI level. The key field is cause set to N1_N2_TRANSFER_INITIATED. This means the AMF has started the UE delivery procedure for that N1 message. In this specific step, that N1 message is the LPP Ack sent by the LMF to acknowledge the UE's earlier ProvideLocationInformation. So this does not mean the UE has already consumed the Ack. It means the AMF has successfully received the LMF instruction and has initiated forwarding of the NAS message toward the UE over the radio path.

This DL NAS transport is the network's formal LPP acknowledgement to the UE after receiving the UE's ProvideLocationInformation message.

The key field is ackIndicator set to 1. This shows that the message is acknowledging the UE's previous LPP response for transaction 1, which was the final location information report. ackRequested is FALSE, so the network is not asking the UE to send another acknowledgement back for this packet. endTransaction is FALSE, which means this packet itself does not explicitly close the overall LPP session context. It only confirms that the location server successfully received the UE's measurement report.

This shows the AMF acknowledging the LMF request and confirming that delivery toward the UE has been initiated.

The HTTP status is 200, which means the AMF accepted the request successfully at the SBI level. The key field is cause set to N1_N2_TRANSFER_INITIATED. This means the AMF has started the UE delivery procedure for the N1 message. In this specific step, the N1 message is the LPP acknowledgement that the location server is sending back to the UE after receiving the UE's ProvideLocationInformation. So this line does not mean the UE already received the message. It means the AMF has taken the message from the LMF and has started forwarding it toward the UE over the radio path.

This is the RRC Measurement Report sent from the UE to the gNB as part of the network configured measurement procedure. The key field is measId 2, which tells you which measurement configuration triggered this report.

In the serving cell result, the UE reports physCellId 501 with rsrp 89 and rsrq 65. This confirms that the UE is currently camped on PCI 501 and that this cell is the stronger one in terms of received power. In the neighbor cell result, the UE reports physCellId 500 with rsrp 83 and rsrq 65. This means the neighbor cell is also detected and measured, but its received power is lower than the serving cell by about 6 dB, while the signal quality is the same. For this LPP eCID test, this message is important because it proves that the UE measurement framework is working correctly at the RRC level and that the UE can report both serving cell and neighbor cell radio measurements, which are the basic inputs needed for eCID related positioning.

This shows the NRPPa e-CID Measurement Initiation Response coming back from the gNB to the LMF. This is the network side measurement response that complements the UE side LPP measurements.

The message is identified as successfulOutcome for procedureCode e-CIDMeasurementInitiation with nrppaTransactionID 2. That confirms this response belongs to the same NRPPa measurement request that the LMF started earlier. The key identifiers are lMF-UE-Measurement-ID and RAN-UE-Measurement-ID, both set to 1. These values tie the returned measurement result to the specific UE measurement instance. The e-CID-MeasurementResult includes the serving cell identity. You can see the PLMN identity and the nG-RAN cell identifier, along with the serving cell TAC. This tells the LMF exactly which cell the gNB used as the reference cell for the result. An important part is servingCellTAC and the nGRANAccessPointPosition. The access point position gives the geographic reference of the serving cell, including latitude, longitude, altitude, and uncertainty related fields. This location anchor is essential because eCID positioning combines radio measurements with the known location of the serving base station. The measurement result also includes radio measurements for the serving cell. In the visible part, the gNB reports nr-RSRP for PCI 501 on NR ARFCN 633300, and the value is 89. This matches the serving cell measurement trend already seen from the UE side. The panel also starts to show nr-RSRQ information just below, indicating that quality measurements are also part of the returned network side result.  For the serving cell, the gNB reports nr-RSRQ for PCI 501 on ARFCN 633300 with a value of 65. This complements the earlier nr-RSRP value of 89, so now the LMF has both signal strength and signal quality for the serving cell from the network side. The response also includes NR-TADV with a value of 24. This is very important for eCID because it provides the timing advance related distance information between the UE and the serving gNB. The message then includes neighbor cell measurements as well. For PCI 500 on ARFCN 626592, the gNB reports nr-RSRP 83 and nr-RSRQ 65. This means the network side result is not limited to the serving cell. It also includes neighbor cell radio measurements that can be used together with the serving cell result for location estimation.  Overall, this message is very important because it proves that the gNB did return the NRPPa eCID measurement result to the LMF. In other words, this is the network side counterpart of the UE measurements, carrying serving cell identity, base station position, and radio measurement values needed by the LMF for final eCID location processing.

This shows the AMF forwarding the gNB’s NRPPa response to the LMF through the UE specific N2 notification callback.

The HTTP POST goes to /namf-comm/v1/N2/imsi-001010123456789/notify/imei=012345670000001. This means the notification is tied to the specific UE context identified by IMSI 001010123456789 and IMEI 012345670000001. The important field is n2NotifySubscriptionId. This links the message to the previously created UE specific N2 subscription, so the LMF knows this NRPPa notification belongs to the same positioning session. The JSON body contains n2InfoContainer with n2InformationClass set to NRPPa. This confirms that the payload is network side positioning information coming from the gNB, not UE side LPP information. Inside nrppaInfo, the NRPPa PDU is referenced through the attached binary part with Content-Id notifyN2 and Content-Type application/vnd.3gpp.ngap. That attached payload is the actual encoded NRPPa measurement response from the gNB. So this step is the SBI forwarding stage where the AMF delivers the gNB’s eCID measurement result up to the LMF for final location processing.

RRC / NAS Signaling

Downlink generic NAS transport /(requestCapability

Message: DL NAS transport

 

Protocol discriminator = 0x7e (5GS Mobility Management)

Security header = 0x2 (Integrity protected and ciphered)

Auth code = 0xb17aa1e2

Sequence number = 0x05

Protocol discriminator = 0x7e (5GS Mobility Management)

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

Message type = 0x68 (DL NAS transport)

Payload container type = 3 (NR Positioning Protocol (LPP) message container)

Payload 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 = 16

  Data = 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30

Uplink generic NAS transport /(provideCapability)

Message: UL NAS transport

 

Protocol discriminator = 0x7e (5GS Mobility Management)

Security header = 0x2 (Integrity protected and ciphered)

Auth code = 0x40293af6

Sequence number = 0x04

Protocol discriminator = 0x7e (5GS Mobility Management)

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

Message type = 0x67 (UL NAS transport)

Payload container type = 3 (NR Positioning Protocol (LPP) message container)

Payload 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

        }

      },

      nr-ECID-ProvideCapabilities-r16 {

        nr-ECID-MeasSupported-r16 '3'H,

        periodicalReporting-r16 supported,

        triggeredReporting-r16 supported

      },

      nr-DL-TDOA-ProvideCapabilities-r16 {

        nr-DL-TDOA-Mode-r16 {

          posModes '001'B

        },

        nr-DL-TDOA-PRS-Capability-r16 {

          maxNrOfDL-PRS-ResourceSetPerTrpPerFrequencyLayer-r16 1,

          maxNrOfTRP-AcrossFreqs-r16 n4,

          maxNrOfPosLayer-r16 1,

          dl-PRS-ResourcesCapabilityBandList-r16 {

            {

              freqBandIndicatorNR-r16 78,

              maxNrOfDL-PRS-ResourcesPerResourceSet-r16 n1,

              maxNrOfDL-PRS-ResourcesPerPositioningFrequencylayer-r16 n6

            }

          },

          dl-PRS-ResourcesBandCombinationList-r16 {

            {

              bandList-r16 {

                78

              },

              maxNrOfDL-PRS-ResourcesAcrossAllFL-TRP-ResourceSet-r16 fr1-Only-r16: n6

            }

          }

        },

        nr-DL-TDOA-MeasurementCapability-r16 {

          dl-RSTD-MeasurementPerPairOfTRP-FR1-r16 1,

          dl-RSTD-MeasurementPerPairOfTRP-FR2-r16 1,

          supportOfDL-PRS-RSRP-MeasFR1-r16 supported,

          supportOfDL-PRS-RSRP-MeasFR2-r16 supported

        },

        nr-DL-PRS-QCL-ProcessingCapability-r16 {

          dl-PRS-QCL-ProcessingCapabilityBandList-r16 {

            {

              freqBandIndicatorNR-r16 78

            }

          }

        },

        nr-DL-PRS-ProcessingCapability-r16 {

          prs-ProcessingCapabilityBandList-r16 {

            {

              freqBandIndicatorNR-r16 78,

              supportedBandwidthPRS-r16 fr1: mhz100,

              dl-PRS-BufferType-r16 type1,

              durationOfPRS-Processing-r16 {

                durationOfPRS-ProcessingSymbols-r16 n1,

                durationOfPRS-ProcessingSymbolsInEveryTms-r16 n8

              },

              maxNumOfDL-PRS-ResProcessedPerSlot-r16 {

              }

            }

          },

          maxSupportedFreqLayers-r16 1

        },

        periodicalReporting-r16 {

          posModes '001'B

        }

      }

    }

  }

}

Additional information:

  Length = 16

  Data = 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30

Downlink generic NAS transport /(requesting LocationInformation-ecid)

Message: DL NAS transport

 

Protocol discriminator = 0x7e (5GS Mobility Management)

Security header = 0x2 (Integrity protected and ciphered)

Auth code = 0xe4f31a0b

Sequence number = 0x08

Protocol discriminator = 0x7e (5GS Mobility Management)

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

Message type = 0x68 (DL NAS transport)

Payload container type = 3 (LTE Positioning Protocol (LPP) message container)

Payload container:

{

  transactionID {

    initiator locationServer,

    transactionNumber 1

  },

  endTransaction FALSE,

  lpp-MessageBody c1: requestLocationInformation: {

    criticalExtensions c1: requestLocationInformation-r9: {

      commonIEsRequestLocationInformation {

        locationInformationType locationMeasurementsRequired,

        qos {

          verticalCoordinateRequest FALSE,

          responseTime {

            time 3,

            responseTimeEarlyFix-r12 1

          },

          velocityRequest FALSE

        },

        segmentationInfo-r14 noMoreMessages

      },

      ecid-RequestLocationInformation {

        requestedMeasurements '111'B

      }

    }

  }

}

Additional information:

  Length = 16

  Data = 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30

Uplink generic NAS transport /(providing LocationInformation-ecid)

Message: UL NAS transport

Protocol discriminator = 0x7e (5GS Mobility Management)

Security header = 0x2 (Integrity protected and ciphered)

Auth code = 0x5aad91e9

Sequence number = 0x06

Protocol discriminator = 0x7e (5GS Mobility Management)

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

Message type = 0x67 (UL NAS transport)

Payload container type = 3 (LTE Positioning Protocol (LPP) message container)

Payload container:

{

  transactionID {

    initiator locationServer,

    transactionNumber 1

  },

  endTransaction TRUE,

  sequenceNumber 0,

  acknowledgement {

    ackRequested TRUE

  },

  lpp-MessageBody c1: provideLocationInformation: {

    criticalExtensions c1: provideLocationInformation-r9: {

      ecid-ProvideLocationInformation {

        ecid-SignalMeasurementInformation {

          measuredResultsList {

            {

              physCellId 0,

              arfcnEUTRA 0

            }

          }

        }

      }

    }

  }

}

Additional information:

  Length = 16

  Data = 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30

© 2025 All rights reserved | Legal notice |