LCS — Location Services (OmniLCS)
The LCS function provides location services for the core — it answers "where is this subscriber?" and drives cell‑broadcast warnings. It resolves a UE's position from the serving cell (and configured cell geometry), services location requests from the network (immediate and deferred), and pushes Commercial Mobile Alerts / cell‑broadcast warnings to an area. OmniWeb surfaces the LCS's cell inventory, live and recent location fixes, deferred‑location requests, CAP alerts and broadcasts; longer‑run trends are on the Grafana dashboards reached from the same page.
The LCS is a per‑instance element page reached from the sidebar when one runs in the site's inventory. All traffic goes through the OmniWeb backend proxy, so it stays behind the single authenticated gateway. The documentation link in the page header (the in‑context help button) opens this page. It is organised into tabs.
Overview
A single‑screen health read: the LCS status, its Diameter peers (to the MME/serving network), active and completed location sessions, the number of cells loaded, and the cell‑sync result — the quickest confirmation the LCS is up and has current cell geometry.
Cells
The cell inventory the LCS positions against: each cell's id, latitude/longitude, radius, height, TAC/LAC, PCI, EARFCN, azimuth and RAT. Cells can be added, edited and removed here — this geometry is what turns a serving‑cell id into a position.
Location
Recent location fixes: each fix's subscriber, resolving cell, computed position, accuracy and method. A location can be requested for a subscriber from here, and opening a fix shows its authoritative last‑known position. This is where an operator confirms a positioning result.
Deferred
The outstanding deferred‑location requests the LCS is holding. Where the Location tab answers "where is this subscriber now", a deferred MT‑LR (deferred mobile‑terminated location request) asks the network to report a subscriber's position later, when a trigger fires, rather than immediately — the GMLC arms the request and the report comes back when the condition is met. The common triggers are UE availability (report the next time the device becomes reachable, having been idle or unreachable when the request was made), periodic location (report at a fixed interval for a set number of reports), and area/motion events (report when the UE enters, leaves or moves within a designated area). This is how an operator schedules positioning for a subscriber who cannot be found at the moment or who needs to be tracked over time.
Each row lists the deferred session's subscriber by IMSI, its event/trigger type (periodic or triggered), the reporting interval in seconds and the count of reports to send, and its status — pending while it waits for the trigger, active once reporting has begun. An operator can create a new deferred request from here — naming the target IMSI, the trigger type and, for periodic reporting, the interval and count — and cancel an outstanding session at any time, which tears down the armed request so no further reports are produced. The list polls so a session's status updates as the network arms it and the trigger fires.
CAP Alerts
The Common Alerting Protocol (CAP) alerts the LCS knows about — each with its identifier, status, urgency, severity and target area. These are the emergency/warning messages eligible to be broadcast.
Broadcasts
The Broadcasts tab shows the active cell‑broadcast messages (warning type, message identifier, serial, target cells and status) — the alerts currently being pushed to an area.
Logs
The Logs tab tails the LCS's live log output for troubleshooting without leaving OmniWeb.
Monitoring dashboards
Location‑request rates and other time‑series are presented as Grafana dashboards, reached from the element page — OmniWeb does not duplicate those charts natively.
Related
- The MME requests positioning over the location interfaces and is the LCS's Diameter peer.
- CAP alerts and broadcasts feed the cell‑broadcast warning system.