Skip to main content

5G Core

The 5G Core section gives each 5GC network function (NF) its own live dashboard — health, registration, and the operational data that NF owns (UE contexts, PDU sessions, IP pools, NRF registrations, policies, charging sessions) — plus per-NF and per-item actions to clear state. It is the 5GC equivalent of the per-element pages for EPC/IMS functions, reading each NF's OAM API through the OmniWeb backend proxy.

← Operations Guide

When it appears

The 5G Core group only shows in the sidebar when the selected site actually runs a 5GC control plane — OmniWeb keys this off the presence of an AMF and/or SMF in the site's inventory. A lone UPF or CHF shared with the EPC is not a 5GC and does not surface this section.

Which NFs appear, and the address of each NF's OAM API, are derived directly from the site's Ansible inventory — the 5GC NF groups defined in the host file — so adding or moving an NF is an inventory change with nothing to hand-template. Each NF resolves to a label, description, IP, and port. OmniWeb serves the resolved registry via /api/5gc/nf-registry; the dashboards then query each NF's OAM API through the proxy (/api/5gc/nf/<id>/…), so all traffic stays behind the single authenticated gateway — see the configuration model. Deployments that run no inventory (e.g. the hosted service) fall back to a static fivegc block in the OmniWeb configuration.

The NFs

Each NF has its own dashboard:

NFFunctionKey data surfaced
NRFNetwork Repository FunctionRegistered NF instances (grouped by type), registered services, subscriptions — see below
AMFAccess & Mobility ManagementUE list, connected gNodeBs (with decoded gNB-ID / TAC / PLMN / SST), statistics, maintenance mode
SMFSession ManagementPDU sessions, IP Pools, UPF association, statistics
UDMUnified Data ManagementUE list, statistics
UDRUnified Data RepositoryHSS health, subscribers
AUSFAuthentication ServerAUSF (auth) sessions, statistics
PCFPolicy ControlAM policies, SM policies, statistics
CHFCharging FunctionCharging sessions, CGrateS health, CDR records
NSSFNetwork Slice SelectionSlices, NSSAI availability, statistics
BSFBinding SupportPCF bindings, statistics
SCPService Communication ProxyNF health, discovery cache, statistics

Not every deployment runs every NF — only the NFs defined in the site's inventory appear. Each NF has its own reference page — follow the links above.

The SMF's IP Pools tab

As an example of the NF-owned data these dashboards surface: the SMF dashboard has an IP Pools tab showing the address pools the SMF allocates UE IPs from, alongside its live PDU Sessions and its UPF Association (the N4/PFCP link state to the user plane). Together these answer "is the SMF connected to its UPF, what sessions are up, and is it running out of addresses?" without leaving OmniWeb.

A dashboard at a glance

Every NF dashboard follows the same layout:

  1. Health cards across the top — API Health, NRF Registration (is this NF registered with the NRF?), NF Status, and License. Each polls on an interval; use the Polling Indicator in the header to pause or see the last-update time (polling is a shared pattern — see Common Operations).
  2. Actions — NF-level operations (see below).
  3. Data sections — the API status detail, NRF registration detail, and the NF-specific tables from the table above, each auto-refreshing. Tables auto-decode what they can: PLMN/TAC/SST from Erlang-encoded S1AP terms, timestamps to relative time, statuses to coloured chips, and cross-links (an NF-type value links to that NF's dashboard).

Actions

Dashboards expose actions to clear NF state — each asks for confirmation first, since they are destructive:

NFNF-level actionsPer-row actions
AMFClear all UE contexts · Clear cacheDeregister a UE
SMFRelease all PDU sessions · Clear cache · PFCP reassociate (re-establish the UPF association)Release one PDU session
NRFDeregister all NFsDeregister one NF · Remove a subscription
AUSFClear all auth sessionsClear one session
UDMClear subscriber cache
PCFRemove an AM or SM policy

These let an operator recover from stuck state — e.g. force an SMF that lost its UPF to reassociate, drop a UE context that will not clear, or deregister a stale NF from the NRF.

The NRF dashboard

The NRF gets a richer view because it is the registry the whole 5GC discovers through:

  • Metric cards — NF types, total instances, registered (with a percent-of-total bar), and services/subscriptions.
  • Registered NF instances — grouped by NF type, each instance card colour-coded and showing registration status, heartbeat timer, service count, and PLMN. Click an instance for its full profile (with an Open Dashboard link to that NF and a Deregister button).
  • Registered services — a flat table of every service each instance advertises, its versions, and status.
  • Deregister All NFs — clears every registration (each NF must then re-register).

This makes the NRF the place to answer "which NFs are up, are they all registered, and what services are they offering?"

  • Network Topology — the topology views that link into these dashboards.
  • Common Operations — the polling, configuration, and RBAC patterns shared with every element page.
  • PGW-C / SMF and UPF — the EPC-side session/user-plane pages for a converged EPC+5GC.