7 vSTP HLRR with SDS Support

vSTP HLRR router with SDS support is a G-Flex enhancement running on vSTP platform and provides functionality equivalent to that of the current G-Flex feature. HLRR has increased the capacity to support a billion IMSIs and MSISDNs combined. Both ITU and ANSI protocols are supported.

In many modern GSM networks, subscribers are mapped to specific Home Location Registers (HLRs) through predefined ranges or blocks of subscriber identifiers, such as contiguous MSISDN or IMSI ranges. In this approach, all signaling related to a subscriber is implicitly tied to the HLR that owns that number range. While simple to operate, it introduces several practical limitations:

  • Uneven load distribution: Subscriber growth and usage patterns often deviate from the original numbering plan, resulting in signaling traffic and database load becoming concentrated on specific HLRs, while other HLRs remain underutilized.
  • Inefficient capacity utilization: Subscriber assignments made in large blocks make efficient utilization of available HLR capacity difficult. As a result, operators may need to expand capacity on heavily loaded HLRs even when sufficient spare capacity is available on other HLRs.
  • Reduced flexibility for rebalancing: Reassigning subscribers to different HLRs is constrained by number-range ownership. Any change typically requires the movement of entire ranges or the execution of complex renumbering and migration activities, increasing operational effort and risk.

The vSTP HLR Router with Subscriber Data Server (SDS) addresses these constraints by decoupling subscriber-to-HLR association from fixed number ranges. This enables operators to:

  • Assign subscribers individually to specific HLRs: (rather than only by predefined blocks), enabling precise distribution of subscribers across multiple HLRs.
  • Route signalling messages based on the subscriber identity: Route signaling messages based on subscriber identity, specifically using MSISDN or IMSI, ensuring that each query is directed to the appropriate HLR according to the per-subscriber assignment maintained in SDS.
  • Improve load balancing and capacity optimization by dynamically: Controlling subscriber distribution across available HLR resources, helping avoid hotspots and enabling more efficient utilization of total installed HLR capacity..

Key Concepts

Network Entities:

In the network, a Network Entity (NE) represents an endpoint; in the case of HLRR, the NE corresponds to an HLR. The SDS database returns an NE as the result of a successful query. Within SDS, an NE is defined by a name and a unique identifier. This unique identifier is used to locate the corresponding NE in the vSTP NE managed object. In the vSTP NE managed object, the NE contains the point code and SSN of the network element to which HLRR attempts to route the message, along with other associated data.

Normal and Exception Routing:

Assuming that it can normalize the address digits of the CdPA from the incoming message, for more information, see number conditioning, HLRR attempts to perform normal routing. Normal routing consists of querying the DN database (for E.164 numbers) or IMSI database (for E.212 numbers) and routing the message to the resulting network entity. If normal routing fails and the exception routing override option is not set or the parameter “GflexExceptionOverrideE164vSTPaddr” is not set, exception routing is performed. Exception routing consists of querying the exception routing table and routing the message to the resulting preferred or mate network entity. If exception routing fails, then HLRR is unable to route the message. In vSTPs case, exception routing is the same as GTT Routing.

Exception Routing Override:

The intent of Exception Routing Override (ERO) is to enable the MP to directly return an "unknown subscriber" indication to the initiating node when normal HLR routing fails (which is, the IMSI or DN is not present in the routing and database). When ERO is active and the conditions below are met, the MP composes a TCAP Return Error (Unknown Subscriber) within a SCCP UDT response and sends it back to the originator.

Applicability and trigger:

  • Scope: ITU‑TCAP requests only.
  • Trigger conditions:
    • The received message is ITU‑TCAP Begin.
    • Normal HLR routing fails with "translation data not found" (IMSI/DN lookup failure).
    • The Exception Routing Override flag is ON.
  • If any of the above conditions are not met, the message processor performs normal exception routing or standard G‑Flex processing.

    Note:

    • ERO applies to ITU‑TCAP Begin messages only. ANSI‑TCAP requests do not enter the ERO path in the current implementation.
    • The override parameters NP, NAI, and E.164 must be appropriately provisioned; provisioning enforces format and range validation.
    • For ANSI MSUs sent to vSTP, calling party must contain a valid SSN, as the generated TCAP Err MSU called party requires an SSN.