Common Operations

Every network element in OmniWeb is different on the inside, but the way you work with them is deliberately the same. This page documents the patterns shared by all elements — viewing data, editing and changing NF setups, reading configuration, running actions, watching logs, and understanding polling and permissions. Learn these once and they apply to the HSS, the UPF, the SMSC, the MSC, and every other NF.

The screenshots below come from specific elements, but they illustrate the generic pattern — the same controls appear, with different fields, on every element.

← Back to Operations Guide

Table of Contents

• Page Anatomy
• Viewing Data
• Detail Views
• Editing & Changing NF Setups
• Running Actions (clear, release, test, ping)
• Viewing Configuration
• Logs on Every Element
• Dashboards on Every Element
• Real-Time Polling
• Permissions & What You Can Change
• Multi-Instance & Fleet Views

Page Anatomy

Selecting an element instance in the sidebar opens its workspace. Every element workspace shares the same layout:

• Overview — the landing tab: health, key counts, and component status for that instance.
• Data tabs — the element-specific views (sessions, subscribers, peers, routing, etc.).
• Configuration — a structured view of the element's runtime configuration (where exposed).
• Logs — a live Loki log viewer scoped to that element.
• Dashboards — embedded Grafana dashboards for that element (when Grafana tags match).

Sidebar entries are ordinary links, so you can Ctrl/Cmd-click (or middle-click, or right-click → Open in new tab) any of them to open that workspace in a new browser tab — handy for watching two elements at once.

Viewing Data

Operational data is presented in a consistent, sortable table throughout OmniWeb. Tables provide:

• Sorting by column.
• Pagination for large result sets.
• Search / filtering where the element API supports it (e.g. search by IMSI/MSISDN or UE IP).
• Skeleton loading while data is fetched, and a clear empty state when there is nothing to show.
• Row click-through to a detail view where one exists.

Values are formatted for readability — timestamps as local time, durations as h m s, byte counts as KB/MB/GB, and large numbers with thousands separators.

The generic list pattern (here, a subscriber list): searchable, sortable, paginated, with click-through and inline editing. The same table drives sessions, peers, routes, and every other listing.

Tables can render richer cells — here, utilisation bars per row. The pattern is the same; only the columns differ.

Detail Views

Where a row has more to show, clicking it opens a detail view. These reuse the same chrome (header, polling, actions) but present the single record in depth — for example an interactive relationship map for a complex object:

A detail view opened from a table row — here, an interactive map of one session's internal rules. Detail views are reached the same way everywhere: click the row.

Editing & Changing NF Setups

Wherever an element's API supports modification, OmniWeb exposes it through a consistent action form. The same form component drives "add a subscriber", "add a route", "edit a QoS rule", and "change a profile" — only the fields differ.

Action forms support these field types: text, number, select (dropdown), boolean (toggle), password (masked, with a show/hide toggle), and multi-line text. Each field can be marked required, carry a placeholder, and show helper text. The form shows a loading state while submitting and reports success or failure via an on-screen notification.

The HTTP method behind each action maps to a permission level — see Permissions.

The same pattern, three elements

These illustrate the same mechanic applied to different NFs:

Task	Where	What happens
Add/edit a subscriber	HSS → Subscribers → Add	Fill the form (IMSI, MSISDN, profile, keys) → proxied POST/PUT → list refreshes
Add/change a route	SMSC → Routing → Add (or MSC → Routing)	Fill the rule (pattern, destination, priority) → proxied write → table refreshes
Clear/release a session	UPF → Sessions (or MSC → Calls)	Select the record → confirm → proxied DELETE → list refreshes

The mechanics — form or confirmation dialog, proxied write, table refresh — are identical. Only the element and fields change.

Changing routing is the same edit pattern: the routing table is a list you add to and edit; some elements additionally parse destinations into readable chips and offer a simulator to test a change before it goes live.

Running Actions

Beyond CRUD, many elements expose operational actions that don't fit a simple form. These are surfaced as buttons that trigger a proxied call and show the result inline. Examples of the same button-action pattern:

Example action	Element	Effect
Force release a call	MSC → Calls	Tears down an active call
OPTIONS ping a SIP peer	MSC → SIP Peers	Tests reachability of a SIP trunk
MAR test a Diameter peer	TWAG → Diameter	Sends a test Multimedia-Auth-Request
Activate/deactivate a redirect	UPF → Walled Garden	Redirects or restores a subscriber
Ping from the node	UPF → Diagnostics	Runs a ping from the element itself
Disconnect a session	TWAG → Sessions	Drops an authenticated WiFi session
Manual paging	MSC → Paging	Triggers a paging request

Destructive actions (release, delete, deactivate) always require explicit confirmation before they run.

Operational actions appear as buttons alongside the data they affect — here, activating/deactivating subscriber redirects and managing whitelisted IPs. Destructive actions prompt for confirmation first.

Viewing Configuration

Elements that expose their runtime configuration have a Configuration tab. OmniWeb renders it in a structured, readable layout with a Raw JSON toggle for the full underlying document.

Two behaviours are worth knowing:

• Mixed config formats are normalised. Some elements return configuration as Python-style dictionaries ('key': True, None) rather than strict JSON. OmniWeb parses these into a clean view automatically and falls back gracefully if a value can't be parsed.
• Secrets are masked. Any field whose name looks sensitive (matching password, secret, token, or credential) is displayed as *** rather than its real value, both in configuration views and in form fields.

The generic configuration view: settings in a structured layout, with a Raw JSON toggle and sensitive values masked. Elements that expose config (UPF, TAS, ePDG, SMSC frontends, OCS, RAN Monitor) all use this pattern.

Logs on Every Element

Every element has a Logs tab backed by Loki. It queries that element's service logs by host/label, supports structured filtering, and streams new lines as they arrive. Because the log model is identical across elements, it is documented in full on its own page:

➡️ Logs & Subscriber Tracing

Every element's Logs tab uses the same viewer — structured, colour-coded, live-streamed Loki logs with service and severity filtering.

Dashboards on Every Element

Elements tagged for Grafana show a Dashboards tab. OmniWeb discovers matching dashboards by tag and renders them inline, so you can see the statistics for an element without leaving its workspace. See:

➡️ Grafana Dashboards & Statistics

Real-Time Polling

Operational pages auto-refresh. The Polling Indicator in each page header shows:

• Active (green dot) or paused.
• The interval (default 5 seconds, set per element via pollIntervalMs).
• A spinner while a fetch is in flight.
• The timestamp of the last successful update.

Polling can be toggled per page. Pages built around interactive or one-shot actions — consoles, diagnostics, JSON executors — do not poll by default and are refreshed manually. Pausing polling is useful when you want a stable view while reading a large table or while a trace is in progress.

Permissions & What You Can Change

What you can do on an element depends on your role. Access is granted per element type, per HTTP method:

Permission	Methods allowed	Typical use
Read-only	GET	View data, no changes
Read-write	GET, POST, PUT, PATCH	View and modify (add subscriber, edit route)
Full	GET, POST, PUT, PATCH, DELETE	Everything, including deletion / clearing

Permissions are assigned independently per element — you might have full access to the UPF but read-only on the HSS. If an action is not permitted for your role, its control is unavailable. Administrators have full access to all elements. See Authentication & Access Control for managing roles, and note that every proxied request is audit-logged regardless of role.

Multi-Instance & Fleet Views

Many element types run as multiple instances — several UPFs behind a PGW-C, a pair of SMSCs, redundant STPs. OmniWeb handles this at the element type level: a type with more than one configured instance gets two navigation modes.

Sidebar & Instance Selection

When a type has multiple instances, the sidebar entry expands to list each one by name. Clicking a named instance opens that instance's workspace directly. An instance dropdown also appears in the workspace header, letting you switch between instances without going back to the sidebar — useful when comparing behaviour across nodes without losing your position on a particular tab.

The instance selector in the top-right of the workspace header. Opening it shows every configured instance plus "All Instances" to jump back to the fleet view — without leaving your current tab.

Fleet View

Clicking the element type name in the sidebar (rather than a specific instance) — or selecting All Instances from the dropdown — opens the fleet view for that type. The fleet view shows a summary card per instance with health status and key metrics, so you can assess the whole fleet at a glance before drilling into a specific node.

UPF fleet view: one card per instance, all polled in parallel. Click any instance card or use the dropdown to drill in.

When to Use Each View

Situation	Use
Checking overall fleet health	Fleet view — all instances at a glance
Investigating a specific node	Instance dropdown or sidebar sub-item
Comparing two UPFs session counts	Open each in the instance dropdown in turn
Clearing a session on a specific UPF	Navigate to that instance, then Sessions