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

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

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

Table of Contents

• NR LPP (NR 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 /(requestCapability
• Uplink generic NAS transport /(provideCapability)
• Downlink generic NAS transport /(requesting LocationInformation-ecid)
• Uplink generic NAS transport /(providing LocationInformation-ecid)

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.

• Context and Background
  • LPP is the standardized protocol for positioning in LTE and 5G NR, supporting advanced location services beyond traditional GPS.
  • Facilitates multi-constellation GNSS support, enhancing accuracy and service robustness in urban and challenging environments.
  • Operates over both control plane (C-Plane) and user plane (U-Plane), improving flexibility and enabling a wider range of network deployment options.
  • Supersedes SUPL in modern networks, addressing the growing demand for secure and reliable positioning in next-generation mobile applications.
• Relevance and Importance
  • Essential for regulatory compliance such as E911, providing accurate location for emergency services.
  • Enables critical use cases in IoT, logistics, autonomous vehicles, and augmented reality where precise positioning is a core requirement.
  • Supports advanced features in 5G NR, including low-latency services and network-assisted positioning enhancements.
  • Amarisoft's LPP implementation allows for practical evaluation and development of positioning-enabled solutions in a controlled test environment.
• Learning Outcomes
  • Understand the architectural principles and functional workflow of LPP in LTE and 5G NR networks.
  • Learn how to configure and test LPP using Amarisoft software, with emphasis on current capabilities and limitations.
  • Gain insights into GNSS system integration, dual-plane signaling, and the practical aspects of protocol interoperability.
  • Develop skills to troubleshoot and validate positioning procedures in modern cellular networks.
• Prerequisite Knowledge
  • Basic understanding of LTE and 5G NR network architecture and signaling procedures.
  • Familiarity with GNSS technologies and location-based service concepts.
  • Experience with Amarisoft or similar cellular network test platforms is beneficial but not mandatory.
  • General knowledge of protocol testing and network configuration is recommended for hands-on sections.

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.

• Test Setup:
  • Two alternative setups are described: using a commercial UE as the Device Under Test (DUT), or using Amarisoft UEsim as DUT.
  • The SIM card provided with the system is used by default; configuration changes are possible as referenced in the Configuration Guide.
• Key Configuration Parameters:
  • Critical parameters for NL1 and LMF configuration are listed, such as nl1.api_root, nl1.transaction_timeout, lmf_cfg.lpp_test, lmf_cfg.periodic_meas, lmf_cfg.meas_period, lmf_cfg.otdoa_assistance_data, lmf_cfg.nr_tdoa_assistance_data, and lmf_cfg.autonomous_mode.
• Configuration Procedures:
  • Callbox (gNB) Configuration:
    • Use the gnb-sa.cfg configuration file as-is; TDD mode and 20MHz bandwidth are set for NR Band 78.
    • Set dl_nr_earfcn as required for the chosen frequency band.
  • MME Configuration:
    • Copy and modify mme-ims.cfg to create mme-ims-nr-lpp.cfg.
    • Configure a test LMF using the lmf_cfg parameter for cases where external LMF is not used.
  • UEsim Configuration:
    • Copy and modify ue-nr-sa.cfg to create ue-nr-sa-lpp.cfg, ensuring TDD and 20MHz bandwidth are configured.
    • Set ground_position_at_origin within cell_groups to enable UEsim to respond to nr_location_req.
    • Use default ue_list configuration as required.
• Test Execution Steps:
  • Verify cell configuration using 'cell phy' and 'cell' commands to ensure settings are as intended.
  • Switch to the (mme) interface and execute the 'nl1' command; confirm LCS connection state is 'state=connected'.
  • Power on the UE in the UEsim and confirm successful initial attach procedure.
  • LMF Client and Subscription:
    • On Callbox, navigate to /root/mme and execute the remote API command:
      ./ws.js mme '{"message": "lmf_client_connect"}'
    • Upon receiving a response, send a command to subscribe the LMF server to N1/N2 messages for a specific UE:
      ./ws.js mme '{"message": "lmf_ue_n1_n2_subscribe","supi": "imsi-...","imei": "...","n1_notify_cbk_uri":"lmf_n1_notif_cbk", "n2_notify_cbk_uri": "lmf_n2_notif_cbk"}'
  • Initiate Location Procedure:
    • Send the nr_location_req command to initiate the location procedure for the target UE:
      ./ws.js mme '{"message": "nr_location_req","supi": "imsi-...","pei": "imei-..."}'
    • Request ECID and GNSS reports individually using:
      ./ws.js mme '{"message": "lpp_request_location", "is_5gs": true, "supi": "imsi-...","imei": "...", "correlation_id": 0,"lpp_methods": ["ecid"],"report_type":"once"}'
./ws.js mme '{"message": "lpp_request_location", "is_5gs": true, "supi": "imsi-...","imei": "...", "correlation_id": 0,"lpp_methods": ["gnss"],"report_type":"once"}'
• Log Analysis:
  • Monitor log files for NL1, MME, LMF, and UE event sequences. Key checkpoints include:
  • NL1 interface listening upon gNB startup.
  • Initial UE registration completion.
  • HTTP transactions for establishing LMF-AMF connections and N1/N2 message subscriptions.
  • HTTP and NAS transactions corresponding to LPP request/response sequences for capability and location information exchanges.
  • Verification of successful message exchanges via status codes and message reception indications.

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.  

• 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
• lmf_cfg
• lpp_test
• transaction_id
• periodic_meas
• meas_period
• meas_id
• otdoa_assistance_data
• nr_tdoa_assistance_data
• autonomous_mode

Configuration

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

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

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

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

Here TDD is used and Bandwidth is set to 20Mhz (NR_BANDWIDTH 20)

Specify dl_nr_earfcn as you want. A band 78 freuency is used in this test.

In mme-ims-nr-lpp.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.

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

Configure ground_position_at_origin in cell_groups. This is required for the UEsim to respond to nr_location_req.

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 'nl1' 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 the command "lmf_client_connect" to connect an LMF client to the AMF server on the NL1 interface. Go to /root/mme directory on Callbox and run following Remote API command.

./ws.js mme '{"message": "lmf_client_connect"}'

[root@CBC-2023010100 mme]# ./ws.js mme '{"message": "lmf_client_connect"}' WebSocket remote API tool version 2024-02-16, Copyright (C) 2012-2024 Amarisoft [0.003] ### Connected to 127.0.0.1:9000 [0.004] ### Ready: name=MME, type=MME, version=2024-02-16 [0.024] <== Send message lmf_client_connect id#1 [0.035] ==> Message received {     "message": "lmf_client_connect",     "message_id": "id#1",     "time": 153.67,     "utc": 1708232672.683 }

Once you receive the response to ""lmf_client_connect", send another command to setup LMF server subscription to the reception of LPP messages.

./ws.js mme '{"message": "lmf_ue_n1_n2_subscribe","supi": "imsi-001010123456789","imei": "01234567000001","n1_notify_cbk_uri":"lmf_n1_notif_cbk", "n2_notify_cbk_uri": "lmf_n2_notif_cbk"}'

[root@CBC-2023010100 mme]# ./ws.js mme '{"message": "lmf_ue_n1_n2_subscribe","supi": "imsi-001010123456789","imei": "01234567000001","n1_notify_cbk_uri":"lmf_n1_notif_cbk", "n2_notify_cbk_uri": "lmf_n2_notif_cbk"}' 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 lmf_ue_n1_n2_subscribe id#1 [0.045] ==> Message received {     "message": "lmf_ue_n1_n2_subscribe",     "message_id": "id#1",     "time": 192.208,     "utc": 1708232711.225 }

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 }

Then send the command "lpp_request_location" to request the ecid report.

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

[root@CBC-2023010100 mme]# ./ws.js mme '{"message": "lpp_request_location", "is_5gs": true, "supi": "imsi-001010123456789","imei": "01234567000001", "correlation_id": 0,"lpp_methods": ["ecid"],"report_type":"once"}' WebSocket remote API tool version 2024-02-20, Copyright (C) 2012-2024 Amarisoft [0.005] ### Connected to 127.0.0.1:9000 [0.006] ### Ready: name=MME, type=MME, version=2024-02-20 [0.026] <== Send message lpp_request_location id#1 [0.037] ==> Message received {     "message": "lpp_request_location",     "message_id": "id#1",     "time": 99.918,     "utc": 1708526391.108 }

Then send the command "lpp_request_location" to request the gnss report.

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

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

Log Analysis

Sample Log

When you turn on gNB with mme configured with LMF, NL1 interface start listening.

Power on UE and wait until the initial registration gets completed.

When you send the RemoteAPI command lmf_client_connect, a sequence of HTTP transaction happens between AMF and LMF to establish the connection.

If you send "lmf_ue_n1_n2_subscribe" command, you will se a sequence of HTTP transaction as shown below.

This is the message sent by the LMF to the AMF to subscribe to UE N1/N2 messages notifications service (see 29.518 paragraph 5.2.2.3.3 N1N2MessageSubscribe)

If you send "nr_location_req" command, you will se a sequence of HTTP transactions as shown below.

This is the message sent by the AMF to the LMF to start a location procedure (see 29.571 5.2.2.2 DetermineLocation)

This is the message sent by the LMF client to AMF(127.0.1.100:5560)  containing a LPP message 'LPP requestCapabilities'

This is the same message received by the AMF server(5560).  LMF client(127.0.1.100:44511) is the sender

If the sent message is properly processed by the reciever, you would see Status 200.

Then Core Network (AMF) send NAS message to UE to forward the LPP message received from the LMF.

Then UE send the response LPP provideCapabilities  to Core Network in UL NAS transport message.

This is the meassage sent by the AMF to the LMF to convey an uplink LPP message

This is the message sent by the LMF to the AMF to convey a LPP message

If the sent message is properly processed by the reciever, you would see the proper Status code.

 This is the same message received by the AMF server and  AMF Client(127.0.1.100:44511) is the sender

If the sent message is properly processed by the reciever, you would see the proper Status code.

If you send "lpp_request_location" command for "ecid", you will se a sequence of NL1 transactions as shown below.

AMF sends LPP message.

Core Network send NAS message to UE that request Location Information.

UE send NAS message to Core Network that provides Location Information.

The core network transfer the message to LMF.

If you send "lpp_request_location" command for "gnss", you will se a sequence of NL1 transactions as shown below.

Core Network send a NAS message to UE that request Location Information.

UE send a NAS message to Core Network that provides Location Information.

Core Network transfer the message to LMF.

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