New accounts get up to $100 credit + a free number

HLR lookup explained: what it tells you about a number

An HLR lookup is a signalling query sent to the home register of a mobile network to ask what the network knows about a phone number right now. In practical terms it answers three questions: is this number known to a mobile network, which network currently holds the subscription, and is the subscription reachable at this moment. It is a routing enquiry borrowed from the machinery that delivers text messages, so it returns network identifiers rather than anything about the person holding the phone.

The name comes from the Home Location Register, the database in a mobile network that holds the master record for each subscription. In the 3GPP architecture the HLR is defined as the location register to which a mobile subscriber is assigned for record purposes, and in the Evolved Packet System that same functionality is provided through the Home Subscriber Server, described in 3GPP TS 23.002 as the master database for a given user. Most queries sold today as HLR lookups are answered by an HSS. The label stuck anyway.

Quick facts

Question Short answer
What is queried? The home register (HLR or HSS) of the network that holds the subscription
What is sent? A phone number in E.164 format, as a routing information request
What comes back? An IMSI, a serving node address, or an error value explaining the refusal
Which protocol? MAP over SS7, or the Diameter S6c interface in newer core networks
Does it ring the phone? No. Nothing is delivered to the handset
Does it work on landlines? No. Fixed and VoIP numbers have no HLR record
How long is a result valid? It is a point in time snapshot. Reachability can change within seconds
What it never returns Names, addresses, locations, consent records or do not call status

Why a routing query became a data product

Mobile networks need a way to find a subscriber before they can deliver anything. When a message centre has a message for a number, it does not know where that subscription is registered, so it first asks the home network for routing information. The operation is called SendRoutingInfoForSM in the Mobile Application Part, specified in 3GPP TS 29.002, and it has a direct Diameter equivalent, the Send Routing Info for SM procedure on the S6c interface between the HSS and the message gateway, specified in 3GPP TS 29.338.

The answer to that question happens to be commercially interesting. To tell a message gateway where to send a message, the home register has to reveal the subscription identity and the node currently serving it. Anyone able to send the query can therefore learn which network a number belongs to and whether it is currently registered, without sending anything to the phone.

The standards acknowledge this openly. TS 29.338 defines an information element that indicates delivery of a short message is not intended, with two values: only the IMSI is requested, or only the mobile country code and mobile network code are requested. In other words, 3GPP anticipated that some senders want the lookup and not the message, and gave the network a way to answer the narrower question. When only the country and network codes are requested, the register may return those codes followed by a dummy subscription number, and the serving node may be left out entirely.

How an HLR lookup actually works

A lookup runs in four steps.

  1. The request. A system submits a number in E.164 format to a lookup service. Nothing about the request touches the handset.
  2. The query. The lookup service takes the role a message gateway would take and issues a routing information request, either as MAP over SS7 or over a Diameter interface, depending on the interconnect it holds.
  3. The path. The query crosses the signalling interconnect. Where mobile number portability applies, it is steered towards the network that now holds the subscription rather than the network that originally held the number range. 3GPP describes two realisations for this, one based on a number portability database and one based on a signalling relay function, both listed in TS 23.002 and detailed in 3GPP TS 23.066. TS 29.338 notes the same idea on the Diameter side, where an intermediate agent may consult a portability database before routing the request onwards.
  4. The answer. The home register replies with routing information, or with an error explaining why it will not give any.

Two things on the path change what comes back. The first is home routing, where an operator places a message router in front of its register so that external systems never see the real subscription details. TS 29.338 states that where routing via the home network is enforced, the answer carries a correlation value instead of the IMSI, and the router substitutes its own address for the serving node. The second is signalling firewalls, which classify and block interconnect messages. Both are widely deployed: a 2020 ITU technical report on SS7 vulnerabilities, drawing on an ENISA survey of European providers, found home routing to be the most commonly implemented mitigation, reported by around 87 per cent of surveyed operators, with filtering on signalling nodes next at around 72 per cent.

Reading the answer: what each value proves

A successful answer carries an IMSI and the address of the node serving the subscription, and may carry a local identifier used by the visited register. Each value has a narrow meaning.

Value What it is What it reliably tells you What it does not tell you
IMSI The subscription identity, structured as mobile country code, mobile network code and subscription number under ITU-T Recommendation E.212 Which country and which network hold the subscription now, including after a port Anything about the person, the device or the location. E.212 states the IMSI is not intended for dialling
Serving node address An E.164 number identifying the MSC, MME or SGSN registered to serve the subscription Whether the subscription is currently registered, and whether the serving network sits in another country A position, a city or a cell. It is a network address, not a location fix
Error value The reason the register refused to give routing data Whether the number is in service right now A permanent verdict. Errors are frequently temporary

The error values are where most of the interpretation goes wrong. TS 29.338 lists the ones that apply to this procedure, and each means something specific.

Error Standard meaning Sensible reading
Unknown user The register does not know a subscription for this number Strong signal that the number is not assigned on that network. The most useful negative result
Absent user No serving node is registered for message delivery The subscription exists but is not reachable at this moment. Phone off, out of coverage, or detached
Teleservice not provisioned The subscription does not have the terminating message service Says nothing about voice reachability. A common false negative for machine to machine subscriptions
Service barred The subscription is barred from receiving the service Usually a subscription state, not a dead number
Facility not supported The requested facility is not supported Tells you about the network or the path, not the subscriber

Read that table twice before designing anything around it. Only one of those five values is close to meaning “this number does not exist”, and even that one applies to the network that answered.

What an HLR lookup cannot tell you

The single most common misunderstanding is that a network query returns something about a person. It does not.

  • No identity. There is no name field. The register holds subscription data, not directory data.
  • No location. A serving node address is an address. It can indicate that the serving network is foreign, which is why lookups are sold as roaming detection, but it does not narrow a subscriber down to a place.
  • No behaviour. Nothing in the answer predicts whether a call will be answered, whether a message will be read, or how engaged the subscriber is.
  • No permission. Lookups say nothing about consent, marketing preferences or do not call registration. Those live in national registers and in your own records.
  • No fixed lines. Fixed and VoIP numbers have no HLR record at all. A “not found” response for a landline is an artefact of the question, not evidence about the number.
  • No guarantee of message delivery. Routing information means the network knows where to send something. Delivery can still fail at the handset.

HLR lookup, portability lookup and number type lookup

Three different products get sold under overlapping names. They answer different questions, at different freshness, and at different cost.

Approach Source of truth Answers Freshness
Number type lookup Published national numbering plans Country, number type such as mobile, fixed or toll free, and the operator the range was allocated to Changes only when numbering plans change. Ported numbers are wrong by design
Portability lookup National or regional portability data Which network holds a ported number and the routing number used to reach it As current as the underlying data publication
Network query, marketed as HLR lookup The home register itself, over signalling The network holding the subscription and whether it is registered now Point in time, valid for as long as nothing changes

The important distinction is between a number’s origin and its present state. A numbering plan tells you where a number was born. A portability record tells you where it moved. Only a live query tells you whether anything is registered behind it at this moment.

Many commercial services blend all three and present one answer. That is reasonable engineering and it is also why identical numbers return different results from different suppliers.

Why two providers disagree about the same number

If you test a batch across suppliers, expect divergence. The usual causes, in rough order of frequency:

  • Home routing. Networks that route terminating messages through their own router return substituted values by design, so real subscription details never leave the network.
  • Firewall policy. Interconnect filtering, described in the GSMA guidance summarised in the ITU report cited above, blocks or drops queries that a network considers unnecessary from a given partner.
  • Cached results. Some services return a stored answer rather than running a query. That is cheaper and often sensible, and it is not a live status.
  • Blended sources. A supplier may answer from portability data when a live query fails, without saying which one produced the result.
  • Interconnect quality. The route to a given network affects both success rate and the level of detail that survives the trip.

The ITU report also notes an uncomfortable market reality: access to signalling networks has spread well beyond licensed operators, and unauthorised access is bought and sold. That matters when you choose a supplier. Ask where the interconnect comes from, not just what the response format looks like.

Where the data genuinely earns its place

Used narrowly, network data is valuable.

List hygiene before outbound campaigns. Removing numbers that return unknown user reduces wasted dialling capacity and pointless attempts. Do not treat absent user the same way, because that state changes when a phone is switched on.

Routing and rating accuracy. Knowing the network behind a number, rather than the range holder, matters when mobile and fixed termination are priced differently and when routes are selected per operator. This is a wholesale voice concern more than a marketing one.

Fraud and account security. The ITU report describes a specific, legitimate pattern: monitor whether the IMSI associated with a number has changed, because a change is an indicator of a SIM swap, and watch for a new IMSI appearing on a dormant number, which indicates the number has been recycled to a new subscriber. Both checks use the same query discussed here, and both are about protecting the account holder.

Roaming awareness. A serving node in another country is a hint that costs, delivery behaviour and appropriate contact times differ. Treat it as a hint, not a fact about where somebody is.

Questions worth asking a lookup provider

  1. Is each result a live query, a cached result, or a database answer? How is that indicated in the response?
  2. Do you return the mobile country code and mobile network code, or only a network name you have mapped yourself?
  3. How do you represent networks that use home routing, where the real subscription details are not disclosed?
  4. What exactly does your “active” or “valid” field mean, and which underlying error values map to it?
  5. How are fixed line and VoIP numbers reported, given that no register exists for them?
  6. What happens when a destination network blocks or rate limits your queries?
  7. Where does your signalling interconnect come from?

Answers to questions two, three and four separate a service that reports what the network said from one that reports its own interpretation.

Compliance, and knowing when to stop

Phone numbers are personal data in most modern data protection regimes, and network identifiers linked to them usually inherit that status. That has practical consequences: run lookups for a defined purpose, keep only what that purpose needs, and set a retention period rather than accumulating a permanent shadow database of subscription states.

Two limits are worth setting explicitly. Network data is not a substitute for consent, and reachability is not permission. A number that returns a clean result can still be one you have no lawful basis to contact. Second, monitoring a number over time in order to observe a person’s movements or availability is a different activity from validating a list, and it should be treated as such regardless of how easy the query is to run.

Common mistakes

  • Treating absent user as invalid. It is the most common false positive in list cleaning and it silently deletes reachable customers.
  • Assuming a lookup predicts answer rates. Reachability is a network state. Whether somebody picks up is driven by timing, caller ID reputation and relevance, not by register contents.
  • Interpreting the serving node as a location. It is a network address, nothing more.
  • Running the same query repeatedly. Bulk repetition looks like probing to the network on the other end, and firewalls exist precisely to stop it.
  • Assuming HLR data explains a voice problem. A number that looks fine in the register can still fail on a specific route. Call outcomes are diagnosed from signalling and call detail records on the voice path.

Where didlogic fits

didlogic operates the voice infrastructure layer: phone numbers, SIP trunking and the routes that carry calls to the public phone network. Number intelligence services such as HLR and portability lookups sit in a separate data layer, and the two are often confused because both deal with the same digits.

The distinction is worth keeping clear when planning outbound work. A lookup service can tell you whether a number is currently known to a mobile network. What happens after you dial is a routing and interconnect question: which carrier the call passes through, how the destination network treats it, and what caller ID is presented. didlogic provides international voice termination and routing built for dialler traffic, along with local and virtual numbers delivered over SIP for the inbound side of the same campaigns.

If your operational question is “will this call complete and sound right”, the answer lives in the call path and its records, not in a register query.

FAQs

Does an HLR lookup send a message or ring the phone?
No. It is a signalling query for routing information. The standards even define a flag stating that delivery of a message is not intended, and an option to return only the country and network codes.

Does an HLR lookup work on landline numbers?
No. The Home Location Register exists in mobile networks. Fixed line and VoIP numbers have no record there, so a query either fails or is answered from other data sources rather than from a register.

Can an HLR lookup tell me where someone is?
No. It can return the address of the node currently serving the subscription, which indicates whether the serving network is domestic or foreign. That is a network address, not a position.

Why did a number come back as valid last week and unreachable today?
Because the answer describes the present state. Absent user means no serving node is registered at that moment, which changes when the handset reconnects.

Is an HLR lookup the same as phone number validation?
No. Validation usually means checking format and numbering plan structure, which requires no signalling. A network query goes further and asks the operator, but it also fails on number types that have no register.

Can a lookup detect a SIM swap?
It can support the check. Because the query can return the subscription identity, a change in that identity for the same number is a recognised indicator of a SIM swap, and a new identity appearing on a long dormant number indicates the number has been recycled. Treat both as signals feeding a review, not as proof.

Why do some networks return so little?
Operators deploy home routing and signalling firewalls to prevent external systems from learning subscription details. Those networks return substituted or minimal values on purpose.

Continue learning

Create account