Skip to main content

OmniHSS Protocol Flows

← Back to Operations Guide

Overview​

This document details the Diameter protocol message flows supported by OmniHSS. Understanding these flows is essential for troubleshooting and operations.

S6a Interface (LTE/EPC)​

Authentication Information Request (AIR/AIA)​

MME requests authentication vectors for subscriber.

Key AVPs:

  • Request: User-Name (IMSI), Visited-PLMN-Id, Number of Requested Vectors
  • Response: Authentication-Info (RAND, AUTN, XRES, KASME)

Update Location Request (ULR/ULA)​

MME notifies HSS of subscriber location and retrieves subscription data.

Key AVPs:

  • Request: User-Name (IMSI), RAT-Type, ULR-Flags, Visited-PLMN-Id, UE-SRVCC-Capability
  • Response: Subscription-Data (AMBR, APN-Configuration, Network-Access-Mode)

Purge UE Request (PUR/PUA)​

MME notifies HSS when subscriber context is deleted.

Notify Request (NOR/NOA)​

MME informs HSS of various events.

Cancel Location Request (CLR/CLA)​

HSS initiates location cancellation to inform MME that subscriber should be detached. OmniHSS supports both automatic and programmatic CLR sending.

Automatic CLR (MME Handover)​

When a subscriber performs an Update Location Request from a new MME, OmniHSS automatically sends a CLR to the previous MME to clean up stale registrations.

Key AVPs (Automatic CLR):

  • User-Name: IMSI of subscriber
  • Destination-Host: Previous MME hostname
  • Destination-Realm: Previous MME realm
  • Cancellation-Type: 0 (MME Update Procedure)
  • CLR-Flags: 0
  • Subscription-Data: Full subscription profile

Programmatic CLR (API-Triggered)​

Administrators can trigger CLR via the programmatic API to forcibly detach subscribers (e.g., for subscription withdrawal, fraud prevention, or administrative actions).

Key AVPs (Programmatic CLR):

  • User-Name: IMSI of subscriber
  • Destination-Host: Last seen MME hostname
  • Destination-Realm: Last seen MME realm
  • Cancellation-Type: :subscription_withdrawal (encoded as integer per 3GPP TS 29.272)
  • CLR-Flags:
    • s6a_indicator: 1 (indicates S6a interface)
    • reattach_required: 1 (UE must re-authenticate to reattach)

Cancellation Types​

OmniHSS supports multiple cancellation types per 3GPP TS 29.272:

TypeValueDescriptionUse Case
MME Update Procedure0Normal MME changeAutomatic during ULR from new MME
SGSN Update Procedure1SGSN handover3G/2G handover scenarios
Subscription Withdrawal2Admin terminationManual detach via API
Update Procedure IWF3Interworking function updateLegacy network interop
Initial Attach Procedure4Fresh registrationForce re-authentication

CLR-Flags​

The CLR-Flags AVP is a bitmask with the following fields:

FlagBitDescription
S6a/S6d Indicator01 = S6a interface used
Reattach Required11 = UE must perform new attach

Example CLR-Flags Configuration:

clr_flags: %{
  s6a_indicator: 1,        # Using S6a interface
  reattach_required: 1     # Force re-authentication
}

Multi-IMSI Scenarios​

OmniHSS tracks MME registration per subscriber (IMSI), not per MSISDN. This is critical for understanding CLR behavior in multi-IMSI scenarios:

Scenario 1: Multiple MSISDNs, Single IMSI

Subscriber A:
  - IMSI: 999000123456789
  - MSISDNs: ["+1234567890", "+9876543210"]
  - last_seen_mme: "mme01.operator.com"

When this subscriber moves to a new MME:

  • One CLR sent to "mme01.operator.com" with IMSI 999000123456789
  • Both MSISDNs are affected (same subscriber, same SIM)
  • User-Name AVP contains the IMSI, not MSISDNs

Scenario 2: Multiple Subscribers (Different IMSIs), Same MSISDN

OmniHSS enforces unique MSISDN constraint (one MSISDN cannot belong to multiple subscribers simultaneously). However, during porting/migration:

Subscriber A:
  - IMSI: 999000111111111
  - MSISDN: "+1234567890"
  - last_seen_mme: "mme01.operator.com"

Subscriber B (after porting):
  - IMSI: 999000222222222
  - MSISDN: "+1234567890"  # Same MSISDN, different SIM/IMSI
  - last_seen_mme: "mme02.operator.com"

When Subscriber B registers:

  • No CLR sent (different IMSI = different subscriber)
  • Subscriber A remains registered at mme01
  • Subscriber B registers at mme02
  • Both can be active simultaneously (different physical devices)

Scenario 3: Programmatic CLR for Multi-MSISDN Subscriber

Result:

  • One CLR sent to the subscriber's last_seen_mme
  • All MSISDNs associated with that IMSI are effectively detached
  • The IMSI is the primary key for tracking MME registration

Important Notes​

  1. IMSI is the Key: CLR operations are always per IMSI, never per MSISDN. The subscriber_state table tracks last_seen_mme by subscriber (IMSI).

  2. Atomic Operation: Each subscriber can only be registered at one MME at a time. The automatic CLR ensures this by cleaning up the old registration.

  3. No CLR if No Previous MME: If last_seen_mme is nil (subscriber never registered), no CLR is sent during ULR.

  4. Subscription Data Included: The automatic CLR (during ULR) includes the full Subscription-Data AVP to help the old MME properly clean up context.

  5. Asynchronous: The CLR is sent asynchronously (fire-and-forget). The ULA response to the new MME does not wait for CLA from the old MME.

  6. CLA Handling: OmniHSS receives CLA responses but currently discards them (:discard at line 398). This prevents message loops and is standard HSS behavior.

SWx Interface (Non-3GPP Access / WiFi Calling)​

The SWx interface enables WiFi calling by connecting the ePDG (Evolved Packet Data Gateway) to the HSS for subscriber authentication and authorization over non-3GPP access networks.

Multimedia Auth Request (MAR/MAA)​

ePDG requests EAP-AKA authentication vectors for WiFi calling registration.

Key AVPs:

  • Request: User-Name (IMSI or IMSI@realm), SIP-Auth-Data-Item (authentication scheme), SIP-Number-Auth-Items
  • Response: SIP-Auth-Data-Item (SIP-Authenticate, SIP-Authorization, Confidentiality-Key, Integrity-Key)

SQN Resynchronization: When the UE detects an authentication failure due to SQN mismatch, the ePDG includes resync data in the SIP-Authorization AVP. OmniHSS extracts AUTS from this field and recalculates SQN using IND-length-aware computation per 3GPP TS 33.102.

Server Assignment Request (SAR/SAA)​

ePDG registers or deregisters the subscriber for WiFi calling services.

Server Assignment Types:

TypeValueDescription
NO_ASSIGNMENT0Query only, no state change
REGISTRATION1Initial WiFi calling registration
RE_REGISTRATION2Registration refresh
UNREGISTERED_USER3Services for unregistered user
TIMEOUT_DEREGISTRATION4Registration timeout
USER_DEREGISTRATION5User-initiated deregistration
AUTHENTICATION_FAILURE7Auth failed, clear state
ADMINISTRATIVE_DEREGISTRATION8Admin-initiated deregistration

Key AVPs:

  • Request: User-Name (IMSI), Server-Assignment-Type, Server-Name (ePDG identity), Service-Selection (APN)
  • Response: User-Data (IFC profile XML), Non-3GPP-User-Data

WiFi Calling Registration Flow​

Complete end-to-end WiFi calling registration.

Cx Interface (IMS)​

User Authorization Request (UAR/UAA)​

I-CSCF queries if user is authorized to register.

Server Assignment Request (SAR/SAA)​

S-CSCF registers/deregisters user and retrieves IMS profile.

IFC Template Rendering:

  • {{imsi}} → Actual IMSI
  • {{msisdns}} → List of phone numbers
  • {{mcc}}, {{mnc}} → Home PLMN codes

Multimedia Auth Request (MAR/MAA)​

S-CSCF requests authentication vectors for IMS registration.

Location Info Request (LIR/LIA)​

I-CSCF queries which S-CSCF is serving the user.

Sh Interface (IMS Profile Data)​

See Sh RepositoryData (Transparent Data) for the data model, SequenceNumber/concurrency rules, and the REST provisioning API for MMTEL-Services / IMS-ODB-Information documents.

User Data Request (UDR/UDA)​

Application Server requests subscriber profile data.

Profile Update Request (PUR/PUA)​

Application Server updates subscriber profile data.

Subscribe Notifications Request (SNR/SNA)​

Application Server subscribes to profile changes.

Gx Interface (Policy Control)​

OmniHSS functions as the PCRF (Policy and Charging Rules Function) via the Gx interface.

See PCRF Documentation for detailed architecture, policy configuration, and QoS management.

Credit Control Request - Initial (CCR-I/CCA-I)​

P-GW requests policy rules when PDN session is established.

Key AVPs:

  • Request: Subscription-Id (IMSI), Called-Station-Id (APN), RAT-Type, IP-CAN-Type
  • Response: QoS-Information (QCI, ARP, AMBR), Charging-Rule-Install

Credit Control Request - Update (CCR-U/CCA-U)​

P-GW notifies of session changes.

Credit Control Request - Terminate (CCR-T/CCA-T)​

P-GW notifies when PDN session ends.

Re-Auth Request (RAR/RAA)​

OmniHSS (PCRF) initiates policy update to P-GW.

Rx Interface (IMS Media Policy)​

OmniHSS functions as the PCRF via the Rx interface for IMS media authorization.

See PCRF Documentation for detailed VoLTE call flows and media authorization.

AA Request (AAR/AAA)​

P-CSCF requests media authorization for IMS session.

Key Information:

  • Parse SDP to determine codec and bandwidth
  • Calculate required bandwidth (UL/DL)
  • Create SDF filters for media flows
  • Trigger dedicated bearer via Gx RAR

Session Termination Request (STR/STA)​

P-CSCF notifies when IMS session ends.

S13 Interface (EIR)​

OmniHSS functions as the EIR (Equipment Identity Register) via the S13 interface.

See EIR Documentation for detailed equipment identity checking, IMEI validation, and blacklist management.

ME Identity Check Request (ECR/ECA)​

External EIR client (or MME) requests equipment validation.

Equipment Status Values:

  • Equipment Unknown (0) - Device allowed (whitelist)
  • Equipment Blacklisted (1) - Device blocked
  • Equipment Greylisted (2) - Device allowed but tracked

SLh Interface (LCS / Location Services)​

OmniHSS answers SLh LCS-Routing-Info-Request (RIR) so a GMLC can discover which MME currently serves a subscriber before requesting their location over SLg. The serving MME is the one recorded at S6a registration (Update-Location). SLh uses Diameter application id 16777291 (3GPP TS 29.173).

LCS Routing Info Request (RIR/RIA)​

GMLC requests the serving node for a subscriber.

Notes:

  • The IMSI is taken from User-Name; an MSISDN lookup is used as a fallback.
  • The returned Serving-Node carries the MME-Name/MME-Realm last recorded by the S6a AIR/ULR handlers (subscriber_state.last_seen_mme / last_seen_realm) — no extra provisioning is required.
  • A GMLC typically follows a successful RIA with an SLg Provide-Location-Request to the returned MME.

Result Codes:

  • 2001 - Success; Serving-Node returned.
  • 5001 - DIAMETER_ERROR_USER_UNKNOWN; IMSI/MSISDN not provisioned.
  • 4201 - DIAMETER_ERROR_ABSENT_USER; subscriber known but no serving MME on record (never attached, or location cancelled).

Complete Call Flow: VoLTE Call​

End-to-end VoLTE call setup showing multiple interfaces.

Zh Interface (Generic Bootstrapping Architecture)​

The Zh interface enables Generic Bootstrapping Architecture (GBA) by connecting the Bootstrapping Server Function (BSF) to the HSS for subscriber authentication and key derivation.

Multimedia Auth Request (MAR/MAA)​

BSF requests GBA authentication vectors for bootstrapping.

Key AVPs:

  • Request: User-Name (IMPI), Public-Identity, SIP-Auth-Data-Item (authentication scheme), Destination-Realm
  • Response: SIP-Auth-Data-Item (SIP-Authenticate, SIP-Authorization, Confidentiality-Key, Integrity-Key), GBA-UserSecSettings

GBA Use Cases:

ApplicationDescription
MBMSMobile Broadcast Multicast Service key management
HTTPSGBA-based certificate provisioning
NAFGeneric Network Application Function authentication
PresenceSecure presence service authentication

SWm Interface (Untrusted Non-3GPP Access)​

The SWm interface enables EAP-AKA authentication for untrusted non-3GPP access networks (e.g., WiFi via ePDG) by connecting the 3GPP AAA Server to the HSS.

Diameter-EAP-Request (DER/DEA)​

EAP authentication exchange for WiFi access.

Key AVPs:

  • Request: Session-Id, Auth-Application-Id, EAP-Payload, Auth-Request-Type, User-Name (optional)
  • Response: EAP-Payload, EAP-Master-Session-Key (MSK), APN-Configuration, Session-Timeout

AA-Request (AAR/AAA)​

Authorization after successful EAP authentication.

Key AVPs:

  • Request: Session-Id, Auth-Application-Id, User-Name, Auth-Request-Type, AAR-Flags
  • Response: APN-Configuration, 3GPP-Charging-Characteristics, Session-Timeout

Session-Termination-Request (STR/STA)​

WiFi session termination notification.

Termination Causes:

CauseValueDescription
DIAMETER_LOGOUT1User logout
DIAMETER_SERVICE_NOT_PROVIDED2Service unavailable
DIAMETER_BAD_ANSWER3Protocol error
DIAMETER_ADMINISTRATIVE4Admin termination
DIAMETER_LINK_BROKEN5Connection lost
DIAMETER_AUTH_EXPIRED6Auth timeout
DIAMETER_USER_MOVED7User moved to other access
DIAMETER_SESSION_TIMEOUT8Session timeout

Troubleshooting Protocol Issues​

Authentication Failures (S6a AIR)​

Check:

  1. Key set configured correctly (Ki, OPC, AMF)
  2. SQN synchronization (if repeated failures)
  3. Roaming rules allow visited network

Location Update Failures (S6a ULR)​

Check:

  1. EPC profile exists and has APNs configured
  2. Roaming allowed for data services
  3. MME identity format correct

IMS Registration Failures (Cx SAR)​

Check:

  1. IMS profile assigned to subscriber
  2. IFC template valid XML
  3. S-CSCF selection configured
  4. MSISDNs assigned if used in template

PDN Connection Failures (Gx CCR-I)​

Check:

  1. APN exists in EPC profile's APN list
  2. APN QoS profile configured
  3. PDN session table not full (if limits exist)

← Back to Operations Guide

Last updated on