MME — Mobility Management Entity

The MME is the control‑plane anchor of the EPC. It terminates S1AP to the eNodeBs, runs the attach, authentication and mobility procedures for every UE, and holds a UE context for each attached subscriber. It fetches subscription and authentication data from the HSS over S6a (Diameter), sets up bearers on the Serving Gateway over S11, and coordinates inter‑MME and inter‑system handovers over S10/N26. In short, it is the node that decides where and how each subscriber attaches, is paged and moves through the network. OmniWeb surfaces the MME's live eNodeBs, UE contexts, SGW and Diameter peers, interface states and handover status; longer‑run trends are on the Grafana dashboards reached from the same page.

← Operations Guide

The MME is a per‑instance element page reached from the sidebar when one runs in the site's inventory, and — where several are deployed — a fleet view for aggregate status. All traffic goes through the OmniWeb backend proxy to the MME's API, 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 API status of the MME and a summary of its live load — connected eNodeBs, attached UEs, SGW peers and the state of its Diameter (S6a) peers. It is the quickest way to confirm the MME is up and see how much of the access network it is serving.

eNodeBs

Every eNodeB the MME has an S1AP association with, each row showing the global eNB ID, name and connection state. Opening an eNodeB shows its context — the served cells and TACs and the UEs on it. An operator can update the MME capacity advertised to an eNodeB, which adjusts how the eNodeB load‑balances UEs across the MME pool (used to drain or weight an MME for maintenance or rebalancing).

UEs

Every attached subscriber's UE context, each row keyed by IMSI and GUTI with its connection and mobility state and serving eNodeB. Opening a UE shows its full context. A range of per‑UE actions is available:

• Page the UE.
• Send to idle — release the radio connection while keeping the context.
• Offload the UE to another MME.
• Request re‑attach — force the UE to re‑attach.
• Send SMS to the UE.
• Delete the UE context — clear a stale or stuck subscriber.

You can also look up the operator / PLMN for an IMSI to identify home versus roaming subscribers.

S‑GW Peers

The Serving Gateways the MME talks to over S11 (GTP‑C), each row showing the peer's IP, its liveness / reachability, the GTP restart (recovery) counter — which increments when the S‑GW restarts, telling the MME to re‑establish the sessions it was holding — and the session count anchored on that gateway. Whether a peer was learned by DNS or is a static entry is shown alongside the S‑GW selection method the MME applies for home and roaming subscribers. Opening a peer lists the sessions it carries, each identified by IMSI with its S11 TEIDs (the MME‑ and S‑GW‑side tunnel endpoints). It is where an operator confirms which S‑GWs are up and sees how the UE sessions are distributed across them — useful when balancing load or diagnosing why bearers for a group of subscribers went down with a single gateway.

GUTI reallocation and S10 offload

Two mobility actions are driven by IMSI rather than per row:

• GUTI reallocation — reallocate a connected subscriber's GUTI, refreshing the temporary identity the UE presents (used when rotating identifiers or clearing an identity mismatch).
• S10 offload — force‑offload a subscriber to another MME. This moves a specific subscriber's context off this MME over S10, complementing the eNodeB‑capacity control when draining an MME.

S10

The S10/N26 inter‑MME interface — the path over which a UE's context is relocated when it moves between MMEs in a pool during a TAU or handover (and, over N26, between the MME and an AMF for EPC‑to‑5GC interworking). The tab has two parts. Active handovers lists the relocations in flight, each showing the source and target MME and the IMSI being moved, so an operator can watch a mobility event proceed or spot one that is stuck. Peer MME discovery shows how the MME finds its pool peers — the DNS / NAPTR lookups it runs and any static peers configured — with each peer's FQDN and address. It is where you confirm inter‑MME mobility is healthy and that the MME can actually reach the neighbours it needs to hand contexts to, complementing the per‑subscriber S10 offload action driven from the UEs tab.

Diameter

The MME's Diameter peers — principally the HSS over S6a — each row showing the peer host, realm and connection state. Opening a peer shows its detail. This is where you confirm the authentication and subscription path to the HSS is up when attaches are failing.

Interfaces

The Interfaces view reports the state of every MME interface in one place: S1AP to the eNodeBs, GTP‑C (S11) to the SGW, Diameter for S6a (HSS) and SLg (location services), SGsAP (to the MSC for CS fallback and SMS), LCS‑AP / SLs (location services), and S10/N26 (inter‑MME and EPC‑to‑5GC handover). It is the single screen for confirming which of the MME's signalling paths are up and which are down.

Logs

The Logs tab tails the MME's live log output for troubleshooting a single MME without leaving OmniWeb.

Monitoring dashboards

Attach rates, UE counts, handover rates and other time‑series for the MME are presented as Grafana dashboards, reached from the element page — OmniWeb does not duplicate those charts natively.

Related

• The HSS holds the subscription and authentication data the MME fetches over S6a.
• The SGW‑C is the control peer over S11 — the MME drives session and bearer setup on it.
• The MSC is reached over SGsAP for CS fallback and SMS.
• Other MMEs are reached over S10 for inter‑MME mobility, and the AMF over N26 for EPC‑to‑5GC handover.