E-SMLC Location Services Guide

OmniLCS implements an Evolved Serving Mobile Location Centre (E-SMLC) that provides UE positioning for LTE networks. The E-SMLC determines UE location using multiple positioning methods and communicates with the MME via the SLs interface using native LCS-AP over SCTP per 3GPP TS 29.171.

Architecture

Positioning Methods

Cell ID

The simplest positioning method. Returns the geographic position of the serving cell from the cell database.

• Accuracy: Cell radius (typically 100m - 5km depending on cell type)
• Latency: Milliseconds (local database lookup)
• UE Support Required: No
• eNB Support Required: No

The engine first attempts to look up the serving cell in the local cell database. If not found, it sends an LPPA E-CID Measurement Initiation Request (with cell_id quantity only) to the eNB via the MME using LCS-AP Connection Oriented Information to obtain the cell identity.

Enhanced Cell ID (E-CID)

Uses LPPA to obtain radio measurements from the eNB, including timing advance and signal strength.

• Accuracy: 50m - 500m
• Latency: 1-5 seconds
• UE Support Required: No
• eNB Support Required: Yes (LPPA)

Measurement quantities requested:

Quantity	Description
Cell ID	Serving cell identity
Timing Advance Type 2	UE-to-eNB propagation delay (distance estimate)
RSRP	Reference Signal Received Power
RSRQ	Reference Signal Received Quality

GNSS / A-GPS

Requests the UE to report its GPS coordinates via the LPP protocol.

• Accuracy: 5m - 50m
• Latency: 5-30 seconds
• UE Support Required: Yes (GNSS capability)
• eNB Support Required: No

The E-SMLC sends an LPP Request Location Information message for GNSS to the UE through the MME via LCS-AP. The UE performs a GNSS fix and reports its coordinates back via LPP, relayed through the MME in a Connection Oriented Information message.

OTDOA

Observed Time Difference of Arrival. Uses multilateration from Positioning Reference Signal (PRS) measurements across multiple cells.

• Accuracy: 10m - 100m
• Latency: 5-15 seconds
• UE Support Required: Yes (OTDOA capability)
• eNB Support Required: Yes (PRS configured, LPPA)

OTDOA steps:

1. Request OTDOA cell information from eNB via LPPA (relayed through LCS-AP Connection Oriented Information)
2. Receive PRS configuration, cell IDs, EARFCNs for reference and neighbour cells
3. Send PRS assistance data to UE via LPP (relayed through LCS-AP Connection Oriented Information)
4. Request RSTD measurements from UE via LPP
5. Receive RSTD measurements
6. Run multilateration to compute position

SLs Interface -- LCS-AP over SCTP

The E-SMLC communicates with the MME using the LCS Application Protocol (LCS-AP) over SCTP per 3GPP TS 29.171. OmniLCS initiates SCTP associations to each configured MME peer.

Transport Details

Parameter	Value
Protocol	LCS-AP over SCTP
SCTP PPID	29
Default port	9082 (IANA registered)
Connection direction	E-SMLC initiates to MME
Encoding	ASN.1 PER aligned

LCS-AP Procedures

Procedure	Code	Description
Location Request / Location Response	0	E-SMLC requests MME to locate a UE
Connection Oriented Information	1	Relay LPPA/LPP PDUs (UE-associated, uses correlation_id)
Connectionless Information	2	Relay non-UE-associated LPPA PDUs
Location Abort	3	Abort an in-progress location procedure
Reset	4	Reset all location procedures

Correlation ID

Every UE-associated LCS-AP transaction uses a correlation ID -- a 4-byte binary value that ties together the Location Request, all Connection Oriented Information exchanges, and the Location Response for a single positioning session. The E-SMLC generates a random correlation ID at the start of each session using :crypto.strong_rand_bytes(4).

The correlation ID is included as an IE (ID 2) in:

• Location Request (E-SMLC -> MME)
• Location Response (MME -> E-SMLC)
• Connection Oriented Information (both directions)
• Location Abort (E-SMLC -> MME)

APDU Tunneling

LPP and LPPA PDUs are carried inside LCS-AP Connection Oriented Information messages. The payload type IE (ID 15) identifies the content:

Payload Type	Value	Description
:lPP	0	LPP PDU (UE positioning protocol, TS 36.355)
:lPPa	1	LPPa PDU (eNB positioning protocol, TS 36.455)

The APDU IE (ID 1) carries the binary LPP or LPPa PDU. The MME transparently relays these between the E-SMLC and the target eNB or UE.

Inbound Messages (MME -> E-SMLC)

Location Response (procedure code 0, successfulOutcome / unsuccessfulOutcome)

The MME sends a Location Response as the outcome of a Location Request.

IE	ID	Criticality	Description
Correlation-ID	2	Reject	Correlation ID from the original Location Request
Location-Estimate	12	Reject	GAD-encoded position (on success)
Positioning-Data	16	Reject	Positioning method information (on success)
Velocity-Estimate	21	Reject	Velocity of the UE (optional, on success)
Accuracy-Fulfilment-Indicator	0	Reject	Whether requested accuracy was met (on success)
LCS-Cause	11	Ignore	Failure cause (on failure)

Connection Oriented Information (procedure code 1, initiatingMessage)

The MME relays LPPA/LPP PDUs from the eNB or UE back to the E-SMLC.

IE	ID	Criticality	Description
Correlation-ID	2	Reject	Session correlation
Payload-Type	15	Reject	:lPP or :lPPa
APDU	1	Reject	Binary LPP or LPPa PDU

Reset Request (procedure code 4, initiatingMessage)

The MME requests the E-SMLC to reset all active procedures. The E-SMLC responds with a Reset Acknowledge.

IE	ID	Criticality	Description
LCS-Cause	11	Ignore	Reason for reset

Outbound Messages (E-SMLC -> MME)

Location Request (procedure code 0, initiatingMessage)

The E-SMLC requests the MME to locate a UE.

IE	ID	Criticality	Description
Correlation-ID	2	Reject	4-byte session correlation ID
Location-Type	13	Reject	geographic-Information, assistance-Information, or last-known-location
E-UTRAN-Cell-Id	4	Ignore	E-CGI of the UE serving cell
LCS-Client-Type	8	Reject	Type of LCS client (optional)
LCS-Priority	9	Reject	Location request priority (optional)
LCS-QoS	10	Reject	Quality of service requirements (optional)
IMSI	7	Ignore	UE IMSI (optional)
IMEI	6	Ignore	UE IMEI (optional)
Include-Velocity	5	Reject	Request velocity estimate (optional)

Connection Oriented Information (procedure code 1, initiatingMessage)

The E-SMLC sends LPPA/LPP PDUs to the eNB or UE via the MME.

IE	ID	Criticality	Description
Correlation-ID	2	Reject	Session correlation
Payload-Type	15	Reject	:lPP or :lPPa
APDU	1	Reject	Binary LPP or LPPa PDU

Connectionless Information (procedure code 2, initiatingMessage)

The E-SMLC sends non-UE-associated LPPA PDUs (e.g., eNB position requests) through the MME.

IE	ID	Criticality	Description
Source-Identity	19	Reject	E-SMLC network element identity
Destination-Id	3	Reject	Target eNB network element identity
APDU	1	Reject	Binary LPPa PDU

Location Session Lifecycle

Each session tracks:

Field	Description
session_id	Unique identifier (e.g., esmlc-1234567890-1)
imsi	UE identifier
mme_host	MME that originated the request
method	Positioning method used
state	Current session state
created_at	Session creation timestamp
updated_at	Last state change timestamp
completed_at	Completion timestamp
lppa_transactions	List of LPPA PDUs exchanged
lpp_transactions	List of LPP PDUs exchanged
measurements	Accumulated measurement data
result	Final location result

Sessions older than 1 hour can be cleaned up via LocationSession.cleanup_old_sessions/1.

Pending Transaction Correlation

The E-SMLC uses an ETS table (:pending_transactions) to correlate outgoing LCS-AP messages with their responses. When a positioning session sends a Connection Oriented Information message:

1. The engine generates a 4-byte correlation ID
2. Registers {correlation_id, {caller_pid, ref}} in the :pending_transactions table
3. Sends the LCS-AP message via the SCTP transport
4. Waits in a receive block for the response
5. When the SLs handler receives a matching response, it looks up the pending transaction by correlation ID and sends the result to the waiting process

Cell Database Management

The cell database stores geographic positions and radio parameters for each cell site. It is used for Cell ID positioning and OTDOA calculations.

Cell Record Fields

Field	Type	Required	Description
cell_id	any	Yes	Unique cell identifier
latitude	float	Yes	Cell latitude in decimal degrees
longitude	float	Yes	Cell longitude in decimal degrees
pci	integer	No	Physical Cell Identity (0-503)
earfcn	integer	No	E-UTRA Absolute Radio Frequency Channel Number
radius	integer	No	Cell coverage radius in meters (default: 1000)
azimuth	float	No	Antenna azimuth in degrees
height	float	No	Antenna height in meters
prs_config	map	No	PRS configuration for OTDOA

PRS Configuration Fields

Field	Type	Description
bandwidth	integer	PRS bandwidth in resource blocks (6, 15, 25, 50, 75, 100)
config_index	integer	PRS configuration index (0-4095)
num_dl_frames	integer	Number of consecutive DL subframes
cp_length	atom	Cyclic prefix length (:normal or :extended)
num_antenna_ports	integer	Number of antenna ports (1, 2, or 4)

InfluxDB Cell Sync

Cell positions are periodically synchronized from InfluxDB:

Parameter	Value	Description
Sync interval	5 minutes	Automatic sync period
Initial delay	10 seconds	Delay before first sync after startup
Sync timeout	60 seconds	Maximum time for a sync operation

Sync can also be triggered manually via:

• REST API: POST /api/cells/sync
• LiveView UI: "Sync from InfluxDB" button on the Cells page

JSON Import

Cells can be imported from a JSON file:

[
  {
    "cell_id": "001-01-0001-01",
    "latitude": 40.7128,
    "longitude": -74.0060,
    "pci": 100,
    "earfcn": 1300,
    "radius": 500,
    "prs_config": {
      "bandwidth": 50,
      "config_index": 0,
      "num_dl_frames": 1
    }
  }
]

Nearby Cell Search

The cell database supports geographic proximity queries using the Haversine formula for great-circle distance calculation. Query via REST API: GET /api/cells/nearby?lat=X&lon=Y&radius=R where radius is in kilometers.

OTDOA Calculation

The OTDOA calculator converts RSTD (Reference Signal Time Difference) measurements into a UE position using multilateration.

Algorithm

1. RSTD to distance difference: dd = RSTD * Ts * c where Ts = 1/(15000 * 2048) seconds and c = speed of light
2. Coordinate projection: Cell lat/lon coordinates are projected to a local meter-based coordinate system
3. Iterative least squares: Solves the hyperbolic positioning equations using weighted least squares with Jacobian-based optimization
4. Convergence: Iterates until position change is less than 1 meter or maximum 50 iterations
5. Uncertainty estimation: Computed from measurement geometry and distance differences

Requirements

• Minimum 2 neighbour cells (plus reference cell = 3 total) for a position estimate
• 3 or more neighbours recommended for unambiguous 2D fix
• All cells must have known positions in the cell database
• Cell positions are resolved by PCI, ECGI, or cell_id

REST API Reference for Location

See REST API Reference for the full endpoint documentation. Key location endpoints:

Endpoint	Method	Description
/api/location	POST	Request a new UE location
/api/location	GET	List recent location fixes
/api/location/:imsi	GET	Last known location for an IMSI
/api/location/:imsi/history	GET	Location history for an IMSI
/api/location/:imsi/history/csv	GET	CSV export of location history

Troubleshooting

No SLs Peers Connected

1. Verify the :sls configuration: local_ip must be reachable from the MME network
2. Check that each mme_peers entry has the correct IP address and port (default 9082)
3. Look for SCTP connection errors in the log: SLs: Failed to connect to MME
4. Verify SCTP is not blocked by firewalls (IP protocol 132)
5. Confirm the MME is listening for LCS-AP on port 9082

Location Request Returns "no_mme_host"

The E-SMLC cannot determine which MME to send LPPA/LPP messages to. Ensure:

1. At least one SLs SCTP association is established
2. For REST API requests, provide the mme_host parameter
3. Check the SLs connection status on the Dashboard page

No LCS-AP Response from MME

1. Verify the SCTP association is in :established state via SctpTransport.get_connections/0
2. Check for SCTP heartbeat failures in the log
3. Confirm the MME supports LCS-AP (TS 29.171)
4. Check that the correlation ID is being correctly matched between request and response

Cell ID Positioning Returns No Coordinates

The cell database does not contain a matching cell. Actions:

1. Trigger an InfluxDB sync: POST /api/cells/sync
2. Add cells manually via the REST API or LiveView UI
3. Import cells from a JSON file

OTDOA Timeout

The eNB did not respond with OTDOA information within the timeout period. Possible causes:

1. eNB does not support LPPA OTDOA Information procedure
2. PRS is not configured on the eNB
3. Network path issue between MME and eNB

GNSS Timeout

The UE did not report GNSS coordinates within the timeout. Possible causes:

1. UE does not support GNSS positioning
2. UE is indoors (no satellite visibility)
3. No GNSS assistance data provided (cold start takes longer)

3GPP References

Specification	Title
TS 29.171	LCS Application Protocol (LCS-AP) between MME and E-SMLC (SLs interface)
TS 29.172	EPC LCS Protocol between GMLC and MME (SLg Diameter interface)
TS 36.455	LTE Positioning Protocol A (LPPa) between eNB and E-SMLC
TS 36.355	LTE Positioning Protocol (LPP) between UE and E-SMLC
TS 23.032	Universal Geographical Area Description (GAD encoding)