Every mobile phone call, every SMS message, and every data session begins with a query to the Home Location Register. The HLR is the authoritative database that knows which subscribers belong to a network, what services they are entitled to, and -- crucially -- where they are right now. For anyone working in telecommunications, whether building SMS platforms, implementing fraud detection, or optimizing message delivery, understanding the HLR is essential.
What Is the Home Location Register?
The HLR is a centralized database maintained by every mobile network operator. It stores the permanent subscriber record for every SIM card (subscriber) that belongs to that network. When you buy a SIM card from an operator, a record is created in that operator's HLR. That record remains in the HLR for as long as you are a subscriber, regardless of where you physically are in the world.
The HLR is "home" in the sense that it belongs to the subscriber's home network -- the operator they have a contract with. Even when a subscriber roams to another country and connects to a visited network, the home HLR remains the authoritative source of information about that subscriber.
What Data Does the HLR Store?
The HLR maintains several categories of subscriber information:
- IMSI (International Mobile Subscriber Identity) -- The globally unique identity burned into the SIM card. Format: MCC (Mobile Country Code, 3 digits) + MNC (Mobile Network Code, 2-3 digits) + MSIN (Mobile Subscriber Identification Number, up to 10 digits). Example:
310260012345678. - MSISDN (Mobile Station International Subscriber Directory Number) -- The subscriber's phone number in E.164 format. A subscriber can have multiple MSISDNs (e.g., a primary number and a data-only number), all mapped to a single IMSI.
- Service profile -- Which services the subscriber is authorized to use: voice calls, SMS, data, call forwarding, call waiting, call barring, supplementary services.
- Authentication data -- The subscriber's authentication key (Ki), used to generate authentication triplets (or quintets in 3G) for network access validation.
- Current location -- The address (Global Title) of the VLR/MSC where the subscriber is currently registered. This is updated every time the subscriber moves to a new location area or connects to a new network.
- GPRS data -- SGSN address for packet-switched services, PDP context profiles, QoS parameters.
- Supplementary service settings -- Call forwarding numbers, call barring configurations, CLIR (Calling Line Identification Restriction) settings.
- Operator-specific data -- Prepaid/postpaid status, roaming restrictions, VPN group membership, and other operator-defined attributes.
HLR vs. VLR vs. AuC vs. EIR
The HLR is part of a family of databases in the GSM architecture, each with a specific role:
- HLR (Home Location Register) -- Permanent subscriber record. One per home network. Stores the definitive subscriber profile and knows where the subscriber is currently located.
- VLR (Visitor Location Register) -- Temporary subscriber record. One per MSC/switch area. When a subscriber enters a new area, the VLR requests a copy of the subscriber's profile from the HLR. The VLR serves as a local cache, reducing the need to query the HLR for every call or message.
- AuC (Authentication Center) -- Stores the master authentication key (Ki) for each subscriber and generates authentication vectors (triplets in 2G, quintets in 3G). The AuC is logically separate from the HLR but is almost always co-located and accessed through the HLR interface.
- EIR (Equipment Identity Register) -- Stores the IMEI (International Mobile Equipment Identity) numbers of mobile devices and maintains three lists: white (allowed), grey (monitored), and black (blocked/stolen). The EIR is queried during network attachment to verify the device is not stolen or blocked.
In practice, modern implementations often combine HLR, AuC, and sometimes EIR into a single physical platform. Vendors like Ericsson, Nokia, and Huawei sell these as integrated subscriber data management systems.
MAP Operations: How Applications Talk to the HLR
The Mobile Application Part (MAP) protocol, running over SS7's TCAP and SCCP layers, defines the operations used to query and update the HLR. The most important MAP operations for SMS and telecom service providers:
SRI-SM (Send Routing Info for Short Message)
This is the operation that makes SMS delivery work. When an SMSC needs to deliver an SMS, it sends an SRI-SM to the recipient's HLR. The request contains the recipient's MSISDN. The HLR responds with:
- The IMSI of the subscriber
- The address of the MSC/VLR currently serving the subscriber
- An indication if the subscriber's phone is switched off (in which case the HLR sets the Message Waiting Data flag and the SMSC holds the message for later delivery)
This operation is the foundation of SS7-based SMS routing. Without SRI-SM, an SMSC would have no way to find the recipient's current location.
ATI (AnyTimeInterrogation)
ATI queries the HLR for the subscriber's current location (cell ID, geographic coordinates if available) and subscriber state (idle, busy, not reachable). This operation is used for location-based services and fleet management. It is also the operation most commonly exploited in SS7 surveillance attacks, which is why many operators now restrict ATI access to authorized sources only.
SAI (Send Authentication Info)
SAI requests authentication vectors from the HLR/AuC. The VLR uses these vectors to authenticate the subscriber during network attachment and at periodic intervals. In GSM (2G), the response contains authentication triplets (RAND, SRES, Kc). In UMTS (3G), it contains authentication quintets (RAND, XRES, CK, IK, AUTN).
Update Location / Cancel Location
When a subscriber moves to a new VLR area, the new VLR sends an UpdateLocation to the HLR, registering itself as the current serving VLR. The HLR then sends a CancelLocation to the old VLR, instructing it to delete its copy of the subscriber record. This handover process ensures that only one VLR holds the subscriber's data at any time.
Insert Subscriber Data / Delete Subscriber Data
When the HLR needs to update the subscriber's profile in the serving VLR (e.g., a service change, a roaming restriction update), it sends InsertSubscriberData to push the new data. DeleteSubscriberData removes specific profile elements.
HLR Lookup as a Service
HLR lookup has become a widely available commercial service, used by businesses for number validation, delivery optimization, and fraud prevention. A commercial HLR lookup queries the operator's HLR (via SS7 SRI-SM or proprietary interfaces) and returns information about the number:
- Number validity -- Is the MSISDN currently assigned to an active subscriber? Numbers that are disconnected, recycled, or never assigned are identified.
- Network identification -- Which operator currently serves the number (identified by MCC+MNC or network name). This is particularly useful for detecting ported numbers.
- Ported status -- Has the number been ported from its original operator? If so, which operator is the current serving network? This is essential for SMS routing -- sending an SMS through the wrong operator results in delivery failure or additional per-message fees.
- Roaming status -- Is the subscriber currently roaming on a foreign network? If so, which visited network? This can affect delivery latency and cost.
- Subscriber status -- Is the handset reachable (phone on and connected to the network) or absent (phone off, out of coverage, or SIM removed)?
- IMSI -- The subscriber's International Mobile Subscriber Identity. Some HLR lookup services return the IMSI, which can be used for SIM swap detection (a changed IMSI for the same MSISDN suggests the SIM has been swapped).
Use Cases for HLR Lookup
- SMS delivery optimization -- Before sending a message, check if the number is valid and active. Sending to invalid numbers wastes money and degrades your sender reputation. A bulk HLR lookup on your subscriber database can reduce costs by 10-30% by removing dead numbers.
- Number portability routing -- Route SMS through the correct operator to avoid inter-operator forwarding fees and reduce delivery time. MOBITELSMS provides integrated MNP/LNP lookups for this purpose.
- Fraud prevention -- Detect SIM swaps by monitoring IMSI changes. If a customer's IMSI changes unexpectedly, it may indicate a SIM swap attack. Block high-risk transactions and require additional verification.
- Number hygiene -- Clean your contact database regularly. Remove numbers that return "absent subscriber" or "unknown subscriber" errors. This improves campaign performance metrics and reduces wasted spend.
- User registration -- During account creation, verify that the phone number the user provides is a valid, active mobile number -- not a landline, VoIP number, or unassigned number.
- Roaming detection -- For services that need to know if a user is traveling (travel insurance, location-aware services), HLR lookup reveals the visited network without requiring GPS access.
HLR in 4G and 5G: The Evolution to HSS and UDM
As mobile networks evolved beyond GSM/3G, the HLR concept was extended and eventually replaced:
HSS (Home Subscriber Server) -- 4G LTE
In 4G LTE networks, the HSS replaces the HLR. The HSS combines the functions of the HLR and AuC into a single database, accessed via the Diameter protocol (specifically the Cx, Dx, Sh, and S6a interfaces) rather than MAP over SS7. The HSS stores the same categories of subscriber data as the HLR (IMSI, MSISDN, service profile, authentication keys, location) but adds LTE-specific data like APN configurations, QoS profiles, and EPS security contexts.
Most operators run the HSS alongside a legacy HLR, with synchronization between the two databases to support subscribers on both 4G and 2G/3G networks simultaneously. The HLR and HSS often run on the same physical platform.
UDM/UDR (Unified Data Management / Unified Data Repository) -- 5G
In 5G Standalone (SA) networks, the subscriber database function is split into two components:
- UDM (Unified Data Management) -- Handles the application logic: authentication, subscriber registration, SMS management. UDM exposes its services via HTTP/2-based Service-Based Interfaces (SBI) -- specifically the Nudm interface.
- UDR (Unified Data Repository) -- Stores the actual data (subscriber profiles, authentication credentials, policy data). The UDR is a pure data store, accessed by the UDM and other network functions.
This separation of logic (UDM) and storage (UDR) is a deliberate architectural choice that enables cloud-native deployment, independent scaling, and multi-vendor interoperability. The UDR can store not just subscriber data but also policy data (previously handled by PCRF/PCF) and application-specific data.
Commercial HLR Lookup APIs
For businesses that need HLR lookup capabilities without operating their own SS7 infrastructure, several options exist:
- Direct SS7 access -- The most authoritative option. An SS7 gateway sends MAP SRI-SM queries directly to the operator's HLR. This provides real-time, accurate results but requires SS7 interconnection agreements and signaling infrastructure.
- HLR lookup APIs -- Third-party providers offer REST APIs that abstract the SS7 complexity. You send an HTTP request with a phone number and receive a JSON response with the lookup results. Pricing is typically per-lookup, ranging from $0.003 to $0.01 per query depending on volume.
- Bulk lookup -- For database cleaning, many providers offer batch processing: upload a CSV of numbers and receive results in minutes to hours. Bulk pricing is significantly cheaper than real-time per-query pricing.
- Integrated lookup -- Some SMS platforms (including MOBITELSMS) integrate HLR lookup directly into the message routing pipeline. Before sending each message, the platform automatically checks the number's validity and routes through the correct operator, optimizing delivery without requiring separate API calls.
API Response Fields
A typical HLR lookup API response includes:
{
"msisdn": "+447700900123",
"mcc": "234",
"mnc": "15",
"network": "Vodafone UK",
"country": "GB",
"status": "DELIVERED",
"ported": true,
"original_network": "EE",
"roaming": false,
"imsi": "234150123456789",
"subscriber_status": "CONNECTED"
}The ported field is particularly valuable for SMS routing. If a number has been ported, routing through the original network will fail or incur forwarding charges. Knowing the current serving network enables direct routing.
HLR Lookup for Fraud Prevention
HLR lookups are increasingly used as a fraud signal in multi-factor authentication and financial services:
- SIM swap detection -- Compare the IMSI returned by HLR lookup against a previously stored IMSI for the same MSISDN. If the IMSI has changed within the last 24-72 hours, the SIM may have been swapped. Flag the account for additional verification before processing sensitive transactions.
- Account takeover prevention -- Before sending an OTP via SMS, check the HLR to confirm the number is active and has not been recently ported or SIM-swapped. This adds a few hundred milliseconds of latency but can prevent costly fraud.
- Synthetic identity detection -- Numbers that return "unknown subscriber" or that are assigned to non-mobile operators (VoIP, landline) may indicate synthetic or fraudulent identities during account registration.
- Revenue assurance -- For telecom operators, regular HLR audits detect subscriber records that are out of sync between the HLR and billing systems, preventing revenue leakage from untracked subscribers.
The HLR has been the backbone of mobile subscriber management since GSM launched in 1991. While its implementation has evolved from standalone physical hardware to virtualized cloud-native microservices, the fundamental concept remains the same: a central source of truth that knows who every subscriber is, what they are authorized to do, and where they are right now. For anyone building services that touch the mobile network -- SMS, voice, authentication, or fraud detection -- the HLR is where the answers are.