HLR Configuration Guide

← Back to Main Documentation

This guide provides configuration for using OmniSS7 as a Home Location Register (HLR/HSS) with OmniHSS as the backend subscriber database.

OmniHSS Integration

OmniSS7 HLR mode functions as an SS7 signaling frontend that interfaces with OmniHSS, a full-featured Home Subscriber Server (HSS) backend. This architecture separates concerns:

OmniSS7 (HLR Frontend): Handles all SS7/MAP protocol signaling, SCCP routing, and network communication
OmniHSS (HSS Backend): Manages subscriber data, authentication, provisioning, and advanced features

Why OmniHSS?

OmniHSS provides carrier-grade subscriber management with features including:

Multi-IMSI Support: Each subscriber can have multiple IMSIs associated with a single MSISDN for international roaming, network switching, and eSIM provisioning
Flexible Authentication: Support for both Milenage (3G/4G/5G) and COMP128 (2G) authentication algorithms
Circuit & Packet Session Tracking: Independent tracking of CS (circuit-switched) and PS (packet-switched) network registrations
Advanced Provisioning: Customizable service profiles, supplementary services, and CAMEL subscription data
API-First Design: RESTful HTTP API for integration with billing, CRM, and provisioning systems
Real-time Updates: Location tracking, session management, and authentication vector generation

All subscriber data, authentication credentials, and service configurations are stored and managed in OmniHSS. OmniSS7 queries OmniHSS via HTTPS API calls to respond to MAP operations like UpdateLocation, SendAuthenticationInfo, and SendRoutingInfo.

Important: OmniSS7 HLR mode is a signaling frontend only. All subscriber management logic, authentication algorithms, provisioning rules, and database operations are handled by OmniHSS. This guide covers the SS7/MAP protocol configuration in OmniSS7. For information about subscriber provisioning, authentication configuration, service profiles, and administrative operations, refer to the OmniHSS documentation.

Multi-IMSI Support

OmniHSS natively supports Multi-IMSI configurations, allowing a single subscriber (identified by MSISDN) to have multiple IMSIs. This enables:

International Roaming Profiles: Different IMSIs for different regions to reduce roaming costs
eSIM Multi-Profile: Multiple network profiles on a single eSIM-capable device
Network Switching: Seamless switching between networks without changing MSISDN
Dual SIM Coordination: Coordination across multiple physical or virtual SIMs
Testing & Development: Multiple test IMSIs pointing to the same subscriber

How it works:

Each IMSI has its own authentication credentials (Ki, OPc, algorithm)
Each IMSI can have independent circuit and packet session registrations
Subscriber services and profiles can be shared or customized per-IMSI
OmniSS7 queries OmniHSS by IMSI, and OmniHSS returns the appropriate subscriber data
Billing systems can track usage per-IMSI while associating all IMSIs to a single account

Example Multi-IMSI scenario:

Subscriber MSISDN: +1-555-123-4567
├─ IMSI 1: 310260123456789 (US Home Network - Milenage auth)
├─ IMSI 2: 208011234567890 (France Roaming Profile - Milenage auth)
└─ IMSI 3: 440201234567891 (UK Roaming Profile - COMP128 auth)

All three IMSIs can be used independently for network registration, but they all belong to the same subscriber account. OmniHSS manages the IMSI-to-subscriber mapping and ensures proper authentication and provisioning for each IMSI.

Active Subs

OmniHSS Integration
Multi-IMSI Support
What is HLR Mode?
Enabling HLR Mode
Subscriber Database
Authentication Vectors
Location Updates
CAMEL Integration
Roaming Subscriber Handling
HLR Operations

Response Field Mapping
Field Source Summary

What is HLR Mode?

HLR Mode enables OmniSS7 to function as a Home Location Register for:

Subscriber Management: Store and manage subscriber data
Authentication: Generate authentication vectors for network access
Location Tracking: Process location updates from VLRs
Routing Information: Provide routing info for calls and SMS

HLR Architecture

Enabling HLR Mode

OmniSS7 can operate in different modes (STP, HLR, SMSc). The mode is selected through a set of mode flags and the associated configuration in config/config.exs, the application's default configuration file.

Switching to HLR Mode

To run OmniSS7 as an HLR, set the mode flags so that HLR features are enabled and SMSc features are disabled, then add the HLR-specific configuration:

Open config/config.exs
Set the mode flags under config :omniss7:
- map_client_enabled: true — required to send/receive MAP operations
- hlr_mode_enabled: true — enables HLR-specific handling
- smsc_mode_enabled: false — disables SMSc features
Add the HLR configuration parameters (API endpoint, GT addresses, ISD/CAMEL settings, M3UA connection) shown below
Customize the parameters for your deployment
Restart the application for the changes to take effect

Note: config/runtime.exs is a minimal stub used for automated testing only — it does not contain operational mode definitions. All mode and HLR configuration lives in config/config.exs (with environment-specific overrides in files such as config/test.exs). Production deployments supply their own config/config.exs.

HLR Mode Configuration

The complete HLR configuration (in config/config.exs) looks like this:

config :omniss7,
  # Mode flags - Enable HLR features only
  map_client_enabled: true,
  hlr_mode_enabled: true,
  smsc_mode_enabled: false,

  # OmniHSS Backend API Configuration
  hlr_api_base_url: "https://10.180.2.140:8443",

  # HLR Service Center GT Address for SMS operations
  hlr_service_center_gt_address: "1234567890",

  # MSISDN ↔ IMSI Mapping Configuration
  # See: MSISDN ↔ IMSI Mapping section for details
  hlr_imsi_plmn_prefix: "50557",
  hlr_msisdn_country_code: "61",
  hlr_msisdn_nsn_offset: 0,
  hlr_msisdn_nsn_length: 9,

  # InsertSubscriberData Configuration
  # Network Access Mode: :packetAndCircuit, :packetOnly, or :circuitOnly
  isd_network_access_mode: :packetAndCircuit,

  # Send ISD #2 (Supplementary Services data)
  isd_send_ss_data: true,

  # Send ISD #3 (Call Barring data)
  isd_send_call_barring: true,

  # CAMEL Configuration (for SendRoutingInfo responses)
  # Service Key for CAMEL service initiation
  camel_service_key: 11_110,

  # CAMEL Trigger Detection Point
  # Options: :termAttemptAuthorized, :tBusy, :tNoAnswer, :tAnswer
  camel_trigger_detection_point: :termAttemptAuthorized,

  # Home VLR Prefixes
  # List of VLR address prefixes that are considered "home" network
  # If subscriber's VLR starts with one of these prefixes, use standard SRI response
  # Otherwise, subscriber is roaming and we need to send PRN to get MSRN
  # Defaults to [] (no prefixes = all VLRs treated as roaming) if omitted
  home_vlr_prefixes: ["555123"],

  # M3UA Connection Configuration
  # Connect as ASP for receiving MAP operations (UpdateLocation, SendAuthInfo, etc.)
  map_client_m3ua: %{
    mode: "ASP",
    callback: {MapClient, :handle_payload, []},
    process_name: :hlr_client_asp,
    # Local endpoint (HLR system)
    local_ip: {10, 179, 4, 11},
    local_port: 2905,
    # Remote STP endpoint
    remote_ip: {10, 179, 4, 10},
    remote_port: 2905,
    routing_context: 1
  }

Link to OmniHSS

Configuration Parameters to Customize

For a complete reference of all configuration parameters, see the Configuration Reference.

Parameter	Type	Default	Description	Example
`hlr_api_base_url`	String	Required	OmniHSS backend API endpoint	`"https://10.179.3.219:8443"`
`hlr_service_center_gt_address`	String	Required	HLR GT address used in UpdateLocation responses	`"5551234568"`
`smsc_service_center_gt_address`	String	Required	SMSC GT address returned in SRI-for-SM responses	`"5551234567"`
`hlr_smsc_alert_gts`	List	`[]`	List of SMSc GTs to send alertServiceCenter after UpdateLocation	`["15559876543", "15559876544"]`
`hlr_alert_location_expiry_seconds`	Integer	`172800`	Location expiry time (seconds) when SMSc receives alertServiceCenter	`86400`
`hlr_imsi_plmn_prefix`	String	`"50557"`	PLMN prefix (MCC+MNC) for MSISDN→IMSI mapping (see MSISDN ↔ IMSI Mapping)	`"001001"`
`hlr_msisdn_country_code`	String	`"61"`	Country code prefix for reverse IMSI→MSISDN mapping (see MSISDN ↔ IMSI Mapping)	`"1"`
`hlr_msisdn_nsn_offset`	Integer	`0`	Offset into MSISDN for NSN extraction (see MSISDN ↔ IMSI Mapping)	`0`
`hlr_msisdn_nsn_length`	Integer	`9`	Length of National Subscriber Number to extract (see MSISDN ↔ IMSI Mapping)	`10`
`isd_network_access_mode`	Atom	`:packetAndCircuit`	Network access mode for InsertSubscriberData	`:packetOnly`
`isd_send_ss_data`	Boolean	`true`	Send ISD #2 with Supplementary Services data	`false`
`isd_send_call_barring`	Boolean	`true`	Send ISD #3 with Call Barring data	`false`
`camel_service_key`	Integer	`11_110`	CAMEL service key for SendRoutingInfo responses	`100`
`camel_trigger_detection_point`	Atom	`:termAttemptAuthorized`	CAMEL trigger detection point	`:tBusy`
`home_vlr_prefixes`	List	`[]`	List of VLR address prefixes considered "home" network (empty = all VLRs treated as roaming)	`["555123"]`
`local_ip`	Tuple	Required	Your HLR system's IP address	`{10, 179, 4, 12}`
`local_port`	Integer	`2905`	Local SCTP port	`2905`
`remote_ip`	Tuple	Required	STP IP address for SS7 connectivity	`{10, 179, 4, 10}`
`remote_port`	Integer	`2905`	Remote SCTP port	`2905`
`routing_context`	Integer	`1`	M3UA routing context ID	`1`

What Happens When HLR Mode is Enabled

When hlr_mode_enabled: true, the web UI will show:

✅ SS7 Events - Event logging
✅ SS7 Client - MAP operation testing
✅ Peers - Connection status (M3UA/SCTP peers)
✅ HLR Links - HLR API status + subscriber management ← HLR-specific
✅ Resources - System monitoring
✅ Configuration - Config viewer

The Routing, Routing Test, and SMSc Links tabs will be hidden.

Important Notes

Required Configuration: The hlr_service_center_gt_address parameter is mandatory. The application will fail to start if it is not configured.
OmniHSS Backend: The OmniHSS API backend must be accessible at the configured hlr_api_base_url
API Request Timeout: All OmniHSS API requests have a hardcoded 5-second timeout
MAP Request Timeout: All MAP requests (SRI, UpdateLocation, SendAuthInfo, etc.) have a hardcoded 10-second timeout
ISD Timeout: Each InsertSubscriberData (ISD) message in an UpdateLocation sequence has a hardcoded 10-second timeout
M3UA connection to STP is required for receiving MAP operations
After changing modes, you must restart the application for changes to take effect
Web UI: See the Web UI Guide for information on using the web interface
API Access: See the API Guide for REST API documentation and Swagger UI access

Subscriber Database

OmniHSS manages all subscriber data including identities, authentication credentials, service profiles, and location information. OmniSS7 retrieves this data via RESTful API calls.

OmniHSS Subscriber Model

OmniHSS stores comprehensive subscriber information:

Multiple IMSIs per subscriber: Support for Multi-IMSI configurations (eSIM, roaming profiles, network switching)
Authentication credentials: Ki, OPc, and algorithm selection (Milenage or COMP128)
Service profiles: Subscriber category, allowed services, QoS parameters
Location tracking: Current VLR/MSC (circuit session) and SGSN/GGSN (packet session) independent tracking
CAMEL subscription data: Service keys, trigger points, and gsmSCF addresses
Supplementary services: Call forwarding, barring, waiting, CLIP/CLIR configurations
Administrative state: Enabled/disabled, service restrictions, expiration dates

Authentication Vectors

Generate Auth Vectors

OmniHSS generates authentication vectors using the Milenage or COMP128 algorithms based on each subscriber's configured authentication method. When OmniSS7 receives sendAuthenticationInfo MAP requests:

OmniSS7 extracts the IMSI from the MAP request
OmniSS7 calls the OmniHSS API to generate authentication vectors
OmniHSS retrieves the subscriber's Ki and OPc credentials
OmniHSS generates the requested number of vectors (RAND, XRES, CK, IK, AUTN)
OmniSS7 encodes the vectors into MAP format and returns them to the requesting VLR/SGSN

OmniHSS API Integration

OmniSS7 communicates with OmniHSS via HTTPS REST API to retrieve subscriber information, update location data, and generate authentication vectors:

config :omniss7,
  hlr_api_base_url: "https://omnihss-server:8443"

When OmniSS7 receives MAP operations from the SS7 network, it queries OmniHSS to:

Retrieve subscriber data by IMSI or MSISDN
Generate authentication vectors using stored Ki/OPc credentials
Update circuit session location when subscribers perform UpdateLocation
Check subscriber status and service entitlements

Location Updates

Update Location Processing

When receiving updateLocation MAP requests, OmniSS7 coordinates with OmniHSS to register the subscriber at a new VLR:

Extract location info from UpdateLocation request (IMSI, new VLR GT, new MSC GT)
Query OmniHSS to verify subscriber exists and is enabled
Update circuit session in OmniHSS with new VLR/MSC location
Send InsertSubscriberData (ISD) messages to provision the subscriber at the new VLR
Return UpdateLocation response to VLR (includes HLR GT from hlr_service_center_gt_address)
Send alertServiceCenter to configured SMSc GTs (if hlr_smsc_alert_gts is populated)

Note: The hlr_service_center_gt_address configuration parameter specifies the HLR's Global Title that is returned in UpdateLocation responses. This allows the VLR/MSC to identify and route messages back to this HLR.

Alert Service Center Integration

After a successful UpdateLocation, the HLR can automatically notify SMSc systems that a subscriber is now reachable by sending alertServiceCenter (MAP opcode 64) messages. For information on how the SMSc handles these alerts, see Alert Service Center Handling in SMSc Guide.

Configuration

Configure the list of SMSc Global Titles to notify:

config :omniss7,
  # List of SMSc GTs to send alertServiceCenter after UpdateLocation
  hlr_smsc_alert_gts: [
    "15559876543",
    "15559876544"
  ],

  # Location expiry time when SMSc receives alertServiceCenter (default: 48 hours)
  hlr_alert_location_expiry_seconds: 172800

Flow Diagram

Behavior

When a subscriber performs UpdateLocation:

HLR sends alertServiceCenter to each SMSc GT in the hlr_smsc_alert_gts list
Message includes the subscriber's MSISDN
HLR uses hlr_service_center_gt_address as the calling party GT
SCCP addressing: calling SSN=6 (HLR), called SSN=8 (SMSc)

The SMSc receives the alert and:

Strips TON/NPI prefix from MSISDN (e.g., "19123123213" → "123123213")
Marks the subscriber as reachable in its location database (via POST to /api/locations)
Sets user_agent field to the HLR GT when calling the API (for tracking which HLR sent the alert)
Sets location expiry time based on hlr_alert_location_expiry_seconds
Tracks the subscriber in the SMSc Subscriber Tracker for monitoring

Testing

Use the Active Subscribers page in the Web UI to manually send alertServiceCenter messages for testing:

Navigate to the "Active Subscribers" tab
Find the "Test Alert Service Center" section
Enter MSISDN, SMSc GT, and HLR GT (defaults are pre-populated from config)
- SMSc GT defaults to first entry in hlr_smsc_alert_gts
- HLR GT defaults to hlr_service_center_gt_address
Click "Send alertServiceCenter"

This is useful for testing SMSc alert handling without requiring a full UpdateLocation flow. The form uses phx-blur validation to avoid showing errors while typing.

InsertSubscriberData (ISD) Configuration

After a successful UpdateLocation, the HLR sends subscriber provisioning data to the VLR using InsertSubscriberData (ISD) messages. The ISD configuration allows you to customize what data is sent and how.

For configuration parameter reference, see ISD Configuration in Configuration Reference.

ISD Sequence

The HLR can send up to 3 sequential ISD messages:

ISD #1 (Always sent) - Basic subscriber data:
- IMSI
- MSISDN
- Subscriber category
- Subscriber status (serviceGranted)
- Bearer service list
- Teleservice list
- Network access mode
ISD #2 (Optional) - Supplementary Services (SS) data:
- Call forwarding settings (unconditional, busy, no reply, not reachable)
- Call waiting
- Call hold
- Multi-party service
- Supplementary service status and features
ISD #3 (Optional) - Call Barring data:
- Barring of all outgoing calls (BAOC)
- Barring of outgoing international calls (BOIC)
- Access restriction data

Configuration Options

# InsertSubscriberData Configuration
# Network Access Mode: :packetAndCircuit, :packetOnly, or :circuitOnly
isd_network_access_mode: :packetAndCircuit,

# Send ISD #2 (Supplementary Services data)
isd_send_ss_data: true,

# Send ISD #3 (Call Barring data)
isd_send_call_barring: true,

Network Access Mode

The isd_network_access_mode parameter controls what type of network access the subscriber is allowed:

Value	Description	Use Case
`:packetAndCircuit`	Both packet-switched (GPRS/LTE) and circuit-switched (voice)	Default - Full service subscribers
`:packetOnly`	Packet-switched only (data/LTE)	Data-only SIM cards, IoT devices
`:circuitOnly`	Circuit-switched only (voice/SMS)	Legacy devices, voice-only plans

Controlling ISD Messages

You can control which ISD messages are sent based on your network requirements:

Send all ISDs (Default - Full feature set):

isd_send_ss_data: true,
isd_send_call_barring: true,

Send only basic subscriber data (Minimal provisioning):

isd_send_ss_data: false,
isd_send_call_barring: false,

Send basic + supplementary services (No call barring):

isd_send_ss_data: true,
isd_send_call_barring: false,

ISD Flow Example

When UpdateLocation is received:

VLR → HLR: UpdateLocation (BEGIN)
HLR → VLR: InsertSubscriberData #1 (CONTINUE) - Basic data
VLR → HLR: ISD #1 ACK (CONTINUE)
HLR → VLR: InsertSubscriberData #2 (CONTINUE) - SS data [if enabled]
VLR → HLR: ISD #2 ACK (CONTINUE)
HLR → VLR: InsertSubscriberData #3 (CONTINUE) - Call barring [if enabled]
VLR → HLR: ISD #3 ACK (CONTINUE)
HLR → VLR: UpdateLocation Response (END)

If isd_send_ss_data or isd_send_call_barring are set to false, those ISD messages are skipped, and the UpdateLocation END is sent sooner.

Best Practices

Default Configuration: Use :packetAndCircuit and enable all ISDs for maximum compatibility
IoT/M2M: Use :packetOnly and disable SS data/call barring for data-only devices
Interoperability: Some older VLRs may not support all supplementary services - disable isd_send_ss_data if encountering issues
Performance: Disabling unused ISDs reduces message overhead and speeds up location updates

CAMEL Integration

CAMEL Configuration for SendRoutingInfo

When responding to SendRoutingInfo (SRI) requests from a GMSC (Gateway MSC), the HLR can instruct the GMSC to invoke CAMEL services for intelligent call routing and service control.

For configuration parameter reference, see CAMEL Configuration in Configuration Reference.

What is CAMEL?

CAMEL (Customized Applications for Mobile network Enhanced Logic) is a protocol that enables intelligent network services in GSM/UMTS networks. It allows network operators to implement value-added services like:

Prepaid billing
Call screening and barring
Virtual Private Networks (VPN)
Premium rate services
Call forwarding with custom logic
Location-based services

Configuration Options

# CAMEL Configuration (for SendRoutingInfo responses)
# Service Key for CAMEL service initiation
camel_service_key: 11_110,

# CAMEL Trigger Detection Point
# Options: :termAttemptAuthorized, :tBusy, :tNoAnswer, :tAnswer
camel_trigger_detection_point: :termAttemptAuthorized,

Service Key

The camel_service_key identifies which CAMEL service should be invoked at the gsmSCF (Service Control Function). This is a numeric identifier configured in your network:

Service Key	Typical Use Case
`11_110`	Prepaid terminating call control (default)
`100`	Originating prepaid service
`200`	Call forwarding with custom logic
`300`	Virtual Private Network (VPN)
Custom	Operator-specific services

Configuration Example:

# For prepaid terminating call control
camel_service_key: 11_110,

# For VPN service
camel_service_key: 300,

Trigger Detection Point

The camel_trigger_detection_point specifies when the CAMEL service should be triggered during call setup:

Detection Point	Description	When Triggered
`:termAttemptAuthorized`	Call attempt authorized (default)	Before call is routed to subscriber
`:tBusy`	Terminating busy	When subscriber is busy
`:tNoAnswer`	Terminating no answer	When subscriber doesn't answer
`:tAnswer`	Terminating answer	When subscriber answers the call

Configuration Examples:

Standard prepaid control (trigger before routing):

camel_trigger_detection_point: :termAttemptAuthorized,

Custom busy handling (trigger when busy):

camel_trigger_detection_point: :tBusy,

Answer-based billing (trigger on answer):

camel_trigger_detection_point: :tAnswer,

SRI Response with CAMEL

When configured, SendRoutingInfo responses include CAMEL subscription information:

GMSC → HLR: SendRoutingInfo (BEGIN)
HLR → GMSC: SRI Response (END) with:
  - IMSI
  - VLR number
  - Subscriber state
  - CAMEL routing info:
    * Service Key: 11_110
    * gsmSCF Address: <configured address>
    * Trigger Detection Point: termAttemptAuthorized
    * Default Call Handling: continueCall

GMSC contacts gsmSCF at trigger point to execute CAMEL service

Best Practices

Production Networks: Use standardized service keys agreed upon with your gsmSCF provider
Testing: Use :termAttemptAuthorized for most comprehensive testing
Prepaid Services: Service key 11_110 is a common industry standard for prepaid terminating calls
Fallback Handling: defaultCallHandling: :continueCall ensures calls proceed if gsmSCF is unreachable

Roaming Subscriber Handling

Home VLR vs Roaming VLR Detection

When the HLR receives a SendRoutingInfo (SRI) request, it needs to determine whether the subscriber is on a "home" VLR (within your network) or on a roaming VLR (visiting another network). The behavior differs based on this determination:

For configuration parameter reference, see Home VLR Prefixes in Configuration Reference.

Home VLR: Return standard SRI response with CAMEL routing information
Roaming VLR: Send a Provide Roaming Number (PRN) request to obtain an MSRN, then return it in the SRI response

Configuration

# Home VLR Prefixes
# List of VLR address prefixes that are considered "home" network
# If subscriber's VLR address starts with one of these prefixes, use standard SRI response
# Otherwise, subscriber is roaming and we need to send PRN to get MSRN
home_vlr_prefixes: ["555123"],

Configuration Example:

# Single home network
home_vlr_prefixes: ["555123"],

# Multiple home networks (e.g., different regions or subsidiaries)
home_vlr_prefixes: ["555123", "555124", "555125"],

How It Works

1. Home Subscriber Flow (Standard)

When the subscriber's VLR address starts with a configured home prefix:

GMSC → HLR: SendRoutingInfo (MSISDN: "1234567890")
HLR queries backend API for subscriber data
HLR checks VLR address: "5551234567"
HLR determines: VLR starts with "555123" → Home network
HLR → GMSC: SRI Response with CAMEL routing info:
  - IMSI
  - VLR number: "5551234567"
  - gsmSCF address (MSC): "5551234501"
  - CAMEL service key: 11_110
  - Trigger detection point: termAttemptAuthorized

2. Roaming Subscriber Flow (PRN Required)

When the subscriber's VLR address does NOT match any home prefix:

GMSC → HLR: SendRoutingInfo (MSISDN: "1234567890")
HLR queries backend API for subscriber data
HLR checks VLR address: "49170123456"
HLR determines: VLR doesn't start with "555123" → Roaming
HLR → MSC: ProvideRoamingNumber (PRN):
  - MSISDN: "1234567890"
  - IMSI: "999999876543210"
  - MSC number: "49170123456"
  - GMSC address: "5551234501"
MSC → HLR: PRN Response with MSRN: "49170999888777"
HLR → GMSC: SRI Response with routing info:
  - IMSI
  - VLR number: "49170123456"
  - Roaming Number (MSRN): "49170999888777"

Response Structure Differences

Home Subscriber SRI Response

%{
  imsi: "999999876543210",
  extendedRoutingInfo: {
    :camelRoutingInfo, %{
      gmscCamelSubscriptionInfo: %{
        "t-CSI": %{
          serviceKey: 11_110,
          "gsmSCF-Address": "5551234501",
          defaultCallHandling: :continueCall,
          "t-BcsmTriggerDetectionPoint": :termAttemptAuthorized
        }
      }
    }
  },
  subscriberInfo: %{
    locationInformation: %{"vlr-number": "5551234567"},
    subscriberState: {:notProvidedFromVLR, :NULL}
  }
}

Roaming Subscriber SRI Response

%{
  imsi: "999999876543210",
  extendedRoutingInfo: {
    :routingInfo, %{
      roamingNumber: "49170999888777"  # MSRN from PRN
    }
  },
  subscriberInfo: %{
    locationInformation: %{"vlr-number": "49170123456"},
    subscriberState: {:notProvidedFromVLR, :NULL}
  }
}

Provide Roaming Number (PRN) Operation

PRN Request Structure

The PRN request sent to the MSC/VLR contains:

Field	Source	Description
MSISDN	SRI request	Subscriber's phone number
IMSI	HLR API	Subscriber's IMSI
MSC Number	HLR API	MSC serving the roaming subscriber (`serving_msc`)
GMSC Address	SRI request	GMSC making the original SRI request
Call Reference Number	Static	Call reference identifier
Supported CAMEL Phases	Static	CAMEL phases supported by GMSC

PRN Response Handling

The HLR expects a PRN response containing:

MSRN (Mobile Station Roaming Number): A temporary number allocated by the visited network for routing the call

Error Handling:

If PRN times out → Returns error 27 (Absent Subscriber) in SRI response
If PRN fails → Returns error 27 (Absent Subscriber) in SRI response
If MSRN cannot be extracted → Returns error 27 (Absent Subscriber) in SRI response

Configuration Examples

Single Home Network Operator

# All VLR addresses starting with "555123" are considered home
home_vlr_prefixes: ["555123"],

VLR 5551234567 → Home (CAMEL response)
VLR 5551235001 → Home (CAMEL response)
VLR 49170123456 → Roaming (PRN + MSRN response)

Multi-Region Operator

# Multiple home networks across different regions
home_vlr_prefixes: ["555123", "555124", "555125"],

VLR 5551234567 → Home (region 1)
VLR 5552341234 → Home (region 2)
VLR 5553411111 → Home (region 3)
VLR 44201234567 → Roaming (international)

Testing Configuration

For testing PRN functionality, set an empty list to treat all VLRs as roaming:

# All VLRs are treated as roaming (for testing PRN flow)
home_vlr_prefixes: [],

Best Practices

Prefix Selection: Use the shortest unique prefix that identifies your network's VLRs (e.g., country code + network code)
Multiple Prefixes: Include all VLR prefixes in your network, including different regions and subsidiaries
Roaming Agreements: Ensure PRN is properly supported by roaming partner networks
Testing: Test both home and roaming scenarios thoroughly before production deployment
Monitoring: Monitor PRN timeout rates to identify connectivity issues with roaming partners

Troubleshooting

Symptom: All subscribers treated as roaming

Cause: home_vlr_prefixes not configured or prefixes don't match VLR addresses
Solution: Check VLR addresses in your database and update prefixes accordingly

Symptom: PRN requests timing out

Cause: Network connectivity issues to roaming partner MSC/VLR
Solution: Verify M3UA/SCCP routing to remote MSC addresses

Symptom: Invalid MSRN in SRI response

Cause: PRN response format from roaming partner doesn't match expected structure
Solution: Review PRN response logs and adjust extract_msrn_from_prn/1 if needed

HLR Operations

Supported MAP Operations

OmniSS7 dispatches inbound MAP operations by opcode (independent of TCAP phase). The following inbound operations are handled:

Opcode	Operation	Purpose
2	`updateLocation`	Register VLR location (triggers ISD sequence + optional alertServiceCenter)
23	`updateGprsLocation`	Register SGSN (packet-switched) location
3	`cancelLocation`	Deregister from old VLR
7	`insertSubscriberData`	Receive subscriber profile (e.g. when acting as VLR-side)
22	`sendRoutingInfo` (SRI)	Provide MSRN/CAMEL routing for calls (home vs roaming)
45	`sendRoutingInfoForSM` (SRI-for-SM)	Provide IMSI + SMSC GT for SMS routing
44	`MT-Forward-SM`	Mobile-terminated SMS delivery
46	`MO-Forward-SM`	Mobile-originated SMS reception
47	`reportSM-DeliveryStatus`	SMS-GMSC delivery status report
64	`alertServiceCenter`	Subscriber-reachable alert to SMSc
66	`readyForSM`	MSC/SGSN signals subscriber is ready for SMS
56	`sendAuthenticationInfo`	Generate authentication vectors
57	`restoreData`	VLR subscriber-data restoration
67	`purgeMS`	Purge a subscriber record at the HLR
59	`processUnstructuredSS-Request`	USSD (handled via USSD gateway when enabled)
71	`anyTimeInterrogation` (ATI)	Subscriber location/state interrogation
10	`registerSS`	Supplementary-service registration (e.g. Call Forwarding Unconditional)

Unhandled opcodes are answered with a facilityNotSupported (21) error.

Response Field Mapping

This section details where each field in HLR responses comes from.

SendRoutingInfo (SRI) Response

Purpose: Provides routing information for incoming calls to a subscriber.

The HLR provides two different response types based on whether the subscriber is on a home VLR or roaming:

Home Subscriber Response (CAMEL Routing)

Used when the subscriber's VLR address starts with a configured home_vlr_prefixes value.

Response Structure:

Field	Source	Description	Example
IMSI	OmniHSS API	Subscriber's IMSI from OmniHSS database	`"999999876543210"`
VLR Number	OmniHSS API	Current VLR serving the subscriber (`circuit_session.assigned_vlr`)	`"5551234567"`
Subscriber State	Static	Always `notProvidedFromVLR`	`:notProvidedFromVLR`
extendedRoutingInfo	-	Type: `camelRoutingInfo`	-
gsmSCF Address	OmniHSS API	MSC serving the subscriber (`circuit_session.assigned_msc`)	`"5551234501"`
Service Key	config.exs	CAMEL service identifier (`camel_service_key`)	`11_110`
Trigger Detection Point	config.exs	When to trigger CAMEL (`camel_trigger_detection_point`)	`:termAttemptAuthorized`
CAMEL Capability Handling	Static	CAMEL phase support level	`3`
Default Call Handling	Static	Fallback if gsmSCF unreachable	`:continueCall`

Roaming Subscriber Response (MSRN Routing)

Used when the subscriber's VLR address does NOT match any configured home_vlr_prefixes value.

Response Structure:

Field	Source	Description	Example
IMSI	OmniHSS API	Subscriber's IMSI from OmniHSS database	`"999999876543210"`
VLR Number	OmniHSS API	Current VLR serving the subscriber (`circuit_session.assigned_vlr`)	`"49170123456"`
Subscriber State	Static	Always `notProvidedFromVLR`	`:notProvidedFromVLR`
extendedRoutingInfo	-	Type: `routingInfo`	-
Roaming Number (MSRN)	PRN Response	MSRN obtained from ProvideRoamingNumber request	`"49170999888777"`

Routing Decision Logic:

1. OmniSS7 receives SendRoutingInfo request
2. OmniSS7 queries subscriber data from OmniHSS API
3. OmniSS7 checks VLR address against home_vlr_prefixes:

   If VLR starts with home prefix:
     → Return CAMEL routing info (home subscriber flow)

   If VLR does NOT match any home prefix:
     → Send ProvideRoamingNumber (PRN) to MSC
     → Extract MSRN from PRN response
     → Return routing info with MSRN (roaming subscriber flow)

Data Flow:

OmniSS7 queries OmniHSS for subscriber information
OmniHSS returns IMSI, current VLR/MSC location, and subscriber state
OmniSS7 uses this data to construct the MAP response

Configuration Requirements:

# In config/config.exs
home_vlr_prefixes: ["555123"],  # List of home VLR prefixes

Error Responses:

If serving_vlr and serving_msc are null: Returns error 27 (Absent Subscriber)
If subscriber not found: Returns error 1 (Unknown Subscriber)
If PRN request times out (roaming case): Returns error 27 (Absent Subscriber)
If PRN response invalid (roaming case): Returns error 27 (Absent Subscriber)

UpdateLocation Response with InsertSubscriberData

Purpose: Registers subscriber at new VLR and provisions subscriber data.

UpdateLocation END Response

Field	Source	Description	Example
HLR Number	config.exs	This HLR's Global Title (`hlr_service_center_gt_address`)	`"5551234568"`
TCAP Message Type	Static	Final response after all ISDs	`END`

InsertSubscriberData #1 (Basic Subscriber Data)

Field	Source	Description	Example
IMSI	Request	From UpdateLocation request	`"999999876543210"`
MSISDN	OmniHSS API	Subscriber's phone number from OmniHSS	`"555123456"`
Category	Static	Subscriber category	`"\n"` (0x0A)
Subscriber Status	Static	Service status	`:serviceGranted`
Bearer Service List	Static	Supported bearer services	`[<<31>>]`
Teleservice List	Static	Supported teleservices	`[<<17>>, "!", "\""]`
Network Access Mode	config.exs	Packet/circuit access (`isd_network_access_mode`)	`:packetAndCircuit`

InsertSubscriberData #2 (Supplementary Services) - Optional

Field	Source	Description	Controlled By
Provisioned SS	Static	Supplementary services data	`isd_send_ss_data: true`
Call Forwarding	Static	Forwarding configurations (unconditional, busy, no reply, not reachable)	Config enabled
Call Waiting	Static	Call waiting service status	Config enabled
Multi-party Service	Static	Conference call support	Config enabled

ISD #2 includes:

Call forwarding unconditional (SS code 21)
Call forwarding on busy (SS code 41)
Call forwarding on no reply (SS code 42)
Call forwarding on not reachable (SS code 62)
Call waiting (SS code 43)
Multi-party service (SS code 51)
CLIP/CLIR services

InsertSubscriberData #3 (Call Barring) - Optional

Field	Source	Description	Controlled By
Call Barring Info	Static	Call barring configurations	`isd_send_call_barring: true`
BAOC	Static	Barring of All Outgoing Calls (SS code 146)	Config enabled
BOIC	Static	Barring of Outgoing International Calls (SS code 147)	Config enabled
Access Restriction Data	Static	Network access restrictions	Config enabled

ISD Sequence Control:

ISD #1: Always sent - Contains essential subscriber data
ISD #2: Sent only if isd_send_ss_data: true in config/config.exs
ISD #3: Sent only if isd_send_call_barring: true in config/config.exs

SendRoutingInfoForSM (SRI-for-SM) Response

Purpose: Provides MSC/SMSC routing information for SMS delivery. When an SMSc needs to deliver an SMS to a subscriber, it sends a SRI-for-SM request to the HLR to determine where to route the message.

Response Structure:

Field	Source	Description	How Generated	Example
IMSI	Calculated	Synthetic IMSI derived from MSISDN	`PLMN_PREFIX + zero_padded_MSISDN`	`"001001555123456"`
Network Node Number	config.exs	SMSC GT address for SMS routing	`smsc_service_center_gt_address`	`"5551234567"`

Configuration Parameters (from config/config.exs):

# Service Center GT Address (returned in SRI-for-SM responses)
# This tells the requesting SMSc where to send MT-ForwardSM messages
smsc_service_center_gt_address: "5551234567",  # Required

# MSISDN ↔ IMSI Mapping Configuration
# PLMN prefix: MCC (001 = Test Network) + MNC (01 = Test Operator)
hlr_imsi_plmn_prefix: "001001",                  # Only config parameter needed!

MSISDN ↔ IMSI Mapping

Configuration Parameters:

These parameters control how OmniSS7 generates synthetic IMSIs from MSISDNs for SRI-for-SM responses:

hlr_imsi_plmn_prefix: The MCC+MNC prefix to use when constructing synthetic IMSIs (e.g., "50557" for MCC=505, MNC=57)
hlr_msisdn_country_code: Country code to prepend when doing reverse IMSI→MSISDN mapping (e.g., "61" for Australia, "1" for USA/Canada)
hlr_msisdn_nsn_offset: Character position where the National Subscriber Number (NSN) starts within the MSISDN (typically 0 if MSISDN doesn't include country code, or length of country code if it does)
hlr_msisdn_nsn_length: Number of digits to extract from the MSISDN as the NSN

For additional configuration details, see MSISDN ↔ IMSI Mapping in Configuration Reference.

Why is MSISDN to IMSI Mapping Needed?

The MAP protocol for SendRoutingInfoForSM (SRI-for-SM) requires the HLR to return an IMSI (International Mobile Subscriber Identity) in its response. However, the requesting SMSc only knows the subscriber's MSISDN (phone number).

In a traditional network:

The SMSc sends SRI-for-SM with the destination MSISDN (e.g., "5551234567")
The HLR must look up the subscriber in its database to find their IMSI
The HLR returns the IMSI in the SRI-for-SM response
The SMSc then uses this IMSI when sending MT-ForwardSM to the MSC/VLR

OmniSS7's Approach - Synthetic IMSIs:

Instead of maintaining a full subscriber database with MSISDN-to-IMSI mappings, OmniSS7 uses a simple encoding scheme to calculate synthetic IMSIs directly from the MSISDN. This approach provides two key benefits:

Privacy: Real subscriber IMSIs stored in the HLR database are never exposed in SRI-for-SM responses sent over the SS7 network
Simplicity: No need to query the HLR database for IMSI lookups during SRI-for-SM operations - the IMSI is calculated on-the-fly from the MSISDN

How It Works:

MSISDNs are encoded directly into the subscriber portion of the IMSI (the digits after MCC+MNC):

IMSI = PLMN_PREFIX + zero_padded_MSISDN

Where:

PLMN_PREFIX: MCC + MNC (e.g., "001001" for Test Network)
MSISDN: All numeric digits from the phone number
Zero Padding: Left-padded with zeros to fill IMSI to exactly 15 digits

Step-by-Step Example:

# Configuration
plmn_prefix = "001001"  # MCC 001 + MNC 01

# Input: MSISDN from SRI-for-SM request (TBCD decoded)
msisdn = "555123456"    # 9 digits

# Step 1: Calculate available space for subscriber number
subscriber_digits = 15 - String.length("001001")  # = 9 digits

# Step 2: Left-pad MSISDN with zeros to fill subscriber portion
padded_msisdn = String.pad_leading("555123456", 9, "0")  # = "555123456" (no padding needed)

# Step 3: Concatenate PLMN prefix + padded MSISDN
imsi = "001001" <> "555123456"  # = "001001555123456" (exactly 15 digits)

Complete Examples:

Input MSISDN	PLMN Prefix	Subscriber Digits Available	Padded MSISDN	Final IMSI	Notes
`"555123456"`	`"001001"` (6)	9	`"555123456"`	`"001001555123456"`	Exact fit, no padding
`"99"`	`"001001"` (6)	9	`"000000099"`	`"001001000000099"`	Left-padded with zeros
`"999999999"`	`"001001"` (6)	9	`"999999999"`	`"001001999999999"`	Exact fit
`"91123456789"`	`"001001"` (6)	9	`"555123456"`	`"001001555123456"`	Too long, rightmost 9 digits kept

Edge Case Handling:

Short MSISDNs: Left-padded with zeros (e.g., "99" → "000000099")
Long MSISDNs: Rightmost digits are kept, leftmost digits are truncated (e.g., "91123456789" → "555123456")
IMSI Length: Always exactly 15 digits

Reverse Mapping (IMSI → MSISDN):

The SMSc can reverse this mapping to convert IMSIs back to MSISDNs:

# Input: IMSI from SRI-for-SM response
imsi = "001001555123456"

# Step 1: Strip PLMN prefix
plmn_prefix = "001001"
subscriber_portion = String.slice(imsi, 6, 9)  # = "555123456"

# Step 2: Remove leading zeros to get actual MSISDN
msisdn = String.replace_leading(subscriber_portion, "0", "")  # = "555123456"

Reverse Mapping Examples:

Input IMSI	PLMN Prefix	Subscriber Portion	Remove Leading Zeros	Final MSISDN
`"001001555123456"`	`"001001"`	`"555123456"`	`"555123456"`	`"555123456"`
`"001001000000099"`	`"001001"`	`"000000099"`	`"99"`	`"99"`
`"001001999999999"`	`"001001"`	`"999999999"`	`"999999999"`	`"999999999"`

Properties of This Mapping:

✅ Deterministic: Same MSISDN always produces same IMSI
✅ Reversible: Can convert back from IMSI to MSISDN
✅ Minimal Configuration: Only requires hlr_imsi_plmn_prefix
✅ Privacy-Preserving: Real IMSIs never exposed
✅ No Database Lookup: Fast calculation, no API calls needed
✅ Always 15 Digits: IMSI is always exactly 15 digits

MSISDN Input Handling:

When the HLR receives a SRI-for-SM request, the MSISDN undergoes TBCD decoding:

TBCD Decode: Convert binary TBCD to string (may include TON/NPI prefix like "91")
Extract Digits: Keep only numeric digits, strip any non-digit characters
Normalize: If longer than available space, take rightmost digits; if shorter, left-pad with zeros
Encode: Concatenate PLMN prefix + normalized MSISDN

Security Considerations:

The synthetic IMSIs returned in SRI-for-SM responses are purely for routing purposes. They are NOT the real IMSIs stored in the HLR subscriber database. This provides an additional layer of privacy protection, as real subscriber IMSIs are only exposed when absolutely necessary (e.g., during UpdateLocation or SendAuthenticationInfo operations that require real authentication vectors).

Response Flow:

1. SMSc → HLR: SRI-for-SM Request
   - MSISDN (TBCD): "91123456789" (includes TON/NPI)

2. HLR Processing:
   - TBCD decode: "91123456789"
   - Extract digits: "91123456789" (11 digits)
   - Fit to 9 digits: "555123456" (rightmost 9)
   - Add PLMN: "001001" + "555123456" = "001001555123456"
   - Get SMSC GT from config: "5551234567"

3. HLR → SMSc: SRI-for-SM Response
   - IMSI: "001001555123456" (synthetic, always 15 digits)
   - Network Node Number: "5551234567" (where to send MT-ForwardSM)

4. SMSc sends MT-ForwardSM to "5551234567" with IMSI "001001555123456"

Configuration:

The following parameters are used in config/config.exs:

# PLMN prefix: MCC (001 = Test Network) + MNC (01 = Test Operator)
hlr_imsi_plmn_prefix: "001001",

# NSN Extraction (if MSISDNs include country code)
hlr_msisdn_country_code: "1",      # Used for reverse mapping (IMSI→MSISDN)
hlr_msisdn_nsn_offset: 1,          # Skip 1-digit country code
hlr_msisdn_nsn_length: 10          # Extract 10-digit NSN

NSN Extraction Configuration:

If your MSISDNs include the country code (e.g., "68988000088" instead of just "88000088"), you must configure NSN extraction:

hlr_msisdn_nsn_offset: Position where NSN starts (typically the length of your country code)
hlr_msisdn_nsn_length: Number of digits in the NSN

Examples:

Example	Country Code	MSISDN Example	nsn_offset	nsn_length	NSN Extracted
1-digit CC	`"9"`	`"95551234567"`	`1`	`10`	`"5551234567"`
2-digit CC	`"99"`	`"99412345678"`	`2`	`9`	`"412345678"`
3-digit CC	`"999"`	`"99988000088"`	`3`	`8`	`"88000088"`

How It Works:

MSISDN → IMSI: Extract NSN from MSISDN, pad with leading zeros, concatenate with PLMN prefix

MSISDN: "99988000088"
NSN: String.slice("99988000088", 3, 8) = "88000088"
Padded NSN: "088000088" (9 digits)
IMSI: "547050" + "088000088" = "547050088000088"

IMSI → MSISDN: Strip PLMN prefix, remove leading zeros, prepend country code

IMSI: "547050088000088"
Subscriber portion: "088000088"
Remove zeros: "88000088"
MSISDN: "+999" + "88000088" = "+99988000088"

API Requirements: None - SRI-for-SM uses calculated values and config only. No backend API calls are required.

Field Source Summary

Source Type	Description	Examples
OmniHSS API	Dynamic data from OmniHSS subscriber database	IMSI, MSISDN, serving VLR/MSC from circuit_session
config.exs	OmniSS7 configuration parameters	`smsc_service_center_gt_address`, `camel_service_key`, `isd_network_access_mode`
Static	Hardcoded values in response generator	Subscriber status, bearer services, SS codes
Request	Fields extracted from incoming MAP request	IMSI from UpdateLocation, MSISDN from SRI
Calculated	Derived values using logic	Synthetic IMSI in SRI-for-SM (hlr_imsi_prefix + NSN)

Configuration Dependencies

Required in config/config.exs:

hlr_service_center_gt_address - Used in UpdateLocation responses
smsc_service_center_gt_address - Used in SRI-for-SM responses (where MT-ForwardSM should be routed)

Optional in config/config.exs (with defaults):

camel_service_key - Default: 11_110
camel_trigger_detection_point - Default: :termAttemptAuthorized
isd_network_access_mode - Default: :packetAndCircuit
isd_send_ss_data - Default: true
isd_send_call_barring - Default: true
hlr_imsi_plmn_prefix - Default: "001001" (PLMN prefix for MSISDN↔IMSI mapping)

Required from OmniHSS:

OmniHSS must provide REST API endpoints for:

Subscriber lookup by IMSI and MSISDN
Circuit session location updates (VLR/MSC assignment)
Authentication vector generation
Subscriber status and service profile queries

OmniSS7 Documentation:

OmniHSS Documentation: For subscriber management, provisioning, authentication configuration, and administrative operations, refer to the OmniHSS product documentation. OmniHSS contains all the subscriber database logic, authentication algorithms, service provisioning rules, and Multi-IMSI management capabilities.

OmniSS7 by Omnitouch Network Services

OmniHSS Integration​

Why OmniHSS?​

Multi-IMSI Support​

Table of Contents​

What is HLR Mode?​

HLR Architecture​

Enabling HLR Mode​

Switching to HLR Mode​

HLR Mode Configuration​

Configuration Parameters to Customize​

What Happens When HLR Mode is Enabled​

Important Notes​

Subscriber Database​

OmniHSS Subscriber Model​

Authentication Vectors​

Generate Auth Vectors​

OmniHSS API Integration​

Location Updates​

Update Location Processing​

Alert Service Center Integration​

Configuration​

Flow Diagram​

Behavior​

Testing​

InsertSubscriberData (ISD) Configuration​

ISD Sequence​

Configuration Options​

Network Access Mode​

Controlling ISD Messages​

ISD Flow Example​

Best Practices​

CAMEL Integration​

CAMEL Configuration for SendRoutingInfo​

What is CAMEL?​

Configuration Options​

Service Key​

Trigger Detection Point​

SRI Response with CAMEL​

Best Practices​

Roaming Subscriber Handling​

Home VLR vs Roaming VLR Detection​

Configuration​

How It Works​

1. Home Subscriber Flow (Standard)​

2. Roaming Subscriber Flow (PRN Required)​

Response Structure Differences​

Home Subscriber SRI Response​

Roaming Subscriber SRI Response​

Provide Roaming Number (PRN) Operation​

PRN Request Structure​

PRN Response Handling​

Configuration Examples​

Single Home Network Operator​

Multi-Region Operator​

Testing Configuration​

Best Practices​

Troubleshooting​

HLR Operations​

Supported MAP Operations​

Response Field Mapping​

SendRoutingInfo (SRI) Response​

Home Subscriber Response (CAMEL Routing)​

Roaming Subscriber Response (MSRN Routing)​

UpdateLocation Response with InsertSubscriberData​

UpdateLocation END Response​

InsertSubscriberData #1 (Basic Subscriber Data)​

InsertSubscriberData #2 (Supplementary Services) - Optional​

InsertSubscriberData #3 (Call Barring) - Optional​

SendRoutingInfoForSM (SRI-for-SM) Response​

MSISDN ↔ IMSI Mapping​

API Requirements: None - SRI-for-SM uses calculated values and config only. No backend API calls are required.​

Field Source Summary​

Configuration Dependencies​

Related Documentation​

OmniHSS Integration

Why OmniHSS?

Multi-IMSI Support

Table of Contents

What is HLR Mode?

HLR Architecture

Enabling HLR Mode

Switching to HLR Mode

HLR Mode Configuration

Configuration Parameters to Customize

What Happens When HLR Mode is Enabled

Important Notes

Subscriber Database

OmniHSS Subscriber Model

Authentication Vectors

Generate Auth Vectors

OmniHSS API Integration

Location Updates

Update Location Processing

Alert Service Center Integration

Configuration

Flow Diagram

Behavior

Testing

InsertSubscriberData (ISD) Configuration

ISD Sequence

Configuration Options

Network Access Mode

Controlling ISD Messages

ISD Flow Example

Best Practices

CAMEL Integration

CAMEL Configuration for SendRoutingInfo

What is CAMEL?

Configuration Options

Service Key

Trigger Detection Point

SRI Response with CAMEL

Best Practices

Roaming Subscriber Handling

Home VLR vs Roaming VLR Detection

Configuration

How It Works

1. Home Subscriber Flow (Standard)

2. Roaming Subscriber Flow (PRN Required)

Response Structure Differences

Home Subscriber SRI Response

Roaming Subscriber SRI Response

Provide Roaming Number (PRN) Operation

PRN Request Structure

PRN Response Handling

Configuration Examples

Single Home Network Operator

Multi-Region Operator

Testing Configuration

Best Practices

Troubleshooting

HLR Operations

Supported MAP Operations

Response Field Mapping

SendRoutingInfo (SRI) Response

Home Subscriber Response (CAMEL Routing)

Roaming Subscriber Response (MSRN Routing)

UpdateLocation Response with InsertSubscriberData

UpdateLocation END Response

InsertSubscriberData #1 (Basic Subscriber Data)

InsertSubscriberData #2 (Supplementary Services) - Optional

InsertSubscriberData #3 (Call Barring) - Optional

SendRoutingInfoForSM (SRI-for-SM) Response

MSISDN ↔ IMSI Mapping

API Requirements: None - SRI-for-SM uses calculated values and config only. No backend API calls are required.

Field Source Summary

Configuration Dependencies

Related Documentation