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.

Two LCS roles, one location request

OmniLCS is co-located as both an E-SMLC and a GMLC — the two location network functions defined by the 3GPP LTE LCS architecture (TS 23.271). A location client never chooses between them: it asks for a UE's location over the REST API, the Location web page, or the Le interface, and OmniLCS picks the role and interface from the requested method/accuracy. Both options are always available behind the one "get location" call.

• Active / high-accuracy methods (E-CID, GNSS, OTDOA, hybrid) use the E-SMLC role documented in this guide. OmniLCS drives LPP (to the UE, TS 36.355) and LPPa (to the eNB, TS 36.455) over the SLs / LCS-AP interface (TS 29.171), relayed by the serving MME, for a precise fix.
• Cell ID / last-known requests use the GMLC role (see the GMLC & Le Interface guide). OmniLCS resolves the serving MME over SLh (TS 29.173) and sends a Provide-Location-Request over SLg (TS 29.172); the MME returns the serving cell from the UE's context.

In both roles the serving MME is the anchor: it is the only node with a signalling path to the UE (NAS) and the eNB (S1AP), so it is either the SLg responder or the SLs relay for LPP/LPPa. The GMLC, with only SLh/SLg Diameter links, cannot reach the radio itself — which is exactly why active positioning is the E-SMLC's job.

See the REST API reference for the harmonised request/response schema and the full decision table. The REST API selects the path per request; the Le Diameter interface and deferred (periodic/triggered) sessions currently always use the GMLC/SLg path.

2G/3G location over MAP/Lg

For subscribers on GERAN (2G) or UTRAN (3G) there is no Diameter SLg/SLs — the GMLC reaches the legacy core over the Lg interface using MAP (TS 29.002) on an SS7/SIGTRAN stack (SCTP → M3UA → SCCP → TCAP). OmniLCS provides this through the OmniLcs.Control.MapClient module, backed by the omniss7 SS7 stack, as a third option behind the same /api/location call (selected with rat: "2g" / "3g").

The flow is a two-step MAP transaction:

1. SendRoutingInfoForLCS (opcode 85) to the HLR → returns the subscriber's serving MSC/SGSN global title. (Skipped if a node_gt is supplied.)
2. ProvideSubscriberLocation (opcode 83) to that MSC/SGSN → returns the location estimate.

The locationEstimate is the same TS 23.032 GAD shape as 4G, so it is decoded with the shared decode_gad/1 and returned in the standard location map with source: "map".

Accuracy on 2G/3G is Cell-ID / Timing-Advance class — the network returns the serving cell, not a precise fix. This path is disabled by default (config :omnilcs, :map, enabled: false); enabling it requires the GMLC number, HLR global title, and a configured SS7 peer (STP/MSC/SGSN) over omniss7's :map_client_m3ua transport. See the GMLC guide and Configuration.

Operation. omniss7 runs headless (library mode — just the MAP codec and transaction registry), so when :omnilcs, :map is enabled OmniLCS starts the M3UA association to the STP itself (supervised by OmniLcs.Control.MapStack); when disabled it starts nothing. Each MAP transaction increments the omnilcs_map_request_total Prometheus counter (tags type = MAP-PSL, result = sent/success). A request with rat: "2g"/"3g" while the path is disabled returns HTTP 501; an unresolved serving node returns 422.

Architecture

Positioning Methods

OmniLCS supports the full range of LTE positioning techniques. A request names a method (or a target accuracy, which auto-selects one); OmniLCS runs that technique on the appropriate interface and returns the estimate. Every method maps to a standard 3GPP positioning procedure:

Method	Technique	Positioning protocol	Role / interface	Typical accuracy	Needs
Cell ID (CID)	Serving-cell position	cell DB lookup, or SLg PLR	E-SMLC (local) or GMLC (SLg)	cell radius, 100 m – 5 km	nothing
Enhanced Cell ID (E-CID)	Single-cell ranging: timing advance + RSRP/RSRQ	LPPa (eNB) → LPP (UE) fallback	E-SMLC / SLs	50 m – 500 m	eNB or UE
OTDOA	Downlink multilateration ("triangulation") from PRS time-differences across cells	LPPa (PRS config) + LPP (RSTD)	E-SMLC / SLs	10 m – 100 m	UE + eNB PRS
A-GNSS	Assisted satellite (GPS/Galileo/…) fix in the UE	LPP (UE)	E-SMLC / SLs	5 m – 50 m	UE GNSS
Hybrid	Combine A-GNSS + E-CID in one request, best-of	LPP (UE)	E-SMLC / SLs	best available	UE

What "triangulation" means here. True triangulation/multilateration of an LTE UE is OTDOA: the UE measures the time difference of downlink Positioning Reference Signals (PRS) from several cells and OmniLCS solves the resulting hyperbolae for a position (see OTDOA Calculation). E-CID is the coarser single-cell cousin — range from one cell's timing advance rather than multi-cell geometry. Uplink multilateration (U-TDOA, network-measured) is not implemented: it requires Location Measurement Units (LMUs) not present in an EPC-only deployment.

Choosing a method by accuracy

If a request supplies accuracy (in metres) instead of an explicit method, OmniLCS picks the lightest method that can plausibly meet the target:

Requested accuracy	Method selected
≤ 50 m	A-GNSS
≤ 200 m	OTDOA
≤ 500 m	E-CID
> 500 m	Cell ID

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.

The same serving cell can also be obtained without touching the radio via the GMLC role — an SLg Provide-Location-Request to the serving MME, which returns the ECGI from the UE's context. This is the path used for cell/last-known REST requests and all Le-interface requests (see Two LCS roles, one location request).

Enhanced Cell ID (E-CID)

Uses LPPa to obtain radio measurements from the eNB, including timing advance and signal strength. If the eNB rejects the LPPa E-CID procedure (e.g. requested-item-not-supported), OmniLCS falls back to requesting E-CID measurements directly from the UE over LPP.

• Accuracy: 50m - 500m
• Latency: 1-5 seconds
• UE Support Required: No for the LPPa path; Yes for the LPP fallback
• eNB Support Required: Yes for the LPPa path; the LPP fallback needs neither

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

Hybrid

Requests A-GNSS and E-CID in a single LPP transaction and returns the best available fix, falling back to the coarser E-CID measurement when the UE cannot complete a GNSS fix.

• Accuracy: Best of A-GNSS (5-50m) and E-CID (50-500m)
• Latency: 5-30 seconds (bounded by the GNSS fix)
• UE Support Required: Yes (GNSS + measurement reporting)
• eNB Support Required: No

OmniLCS sends one combined LPP Request Location Information for GNSS + E-CID and merges whatever the UE returns, preferring the GNSS position. This minimises signalling versus running the two methods separately.

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)