HLR queries explained, and what to use instead

The Home Location Register (HLR) is a database in a mobile operator's core network. Mobile networks talk to it with the Mobile Application Part (MAP), which the 3GPP specification says uses the transaction services of Signalling System No. 7 ¹. A MAP message is not a web request. It travels between network elements such as exchanges and registers, addressed by SCCP global titles.

The best known exchange is routing a call. When a call is set up, the specification says the HLR of the called subscriber is interrogated to discover the whereabouts of the mobile station, with the SCCP address derived from the dialled MSISDN ¹. The service that does this, MAP_SEND_ROUTING_INFORMATION, is used between the gateway exchange and the HLR to interrogate the HLR in order to route a call towards the called mobile ¹.

What comes back is a set of conditional parameters. Per the same service definition they include the IMSI, a roaming number (MSRN), the serving exchange address, location information, the subscriber state and a number portability status ¹. Each is conditional, so which ones arrive depends on the network and on what was asked.

The number a person dials is an E.164 number. The 1997 edition of ITU-T E.164 limits an international number to 15 digits excluding the international prefix, built from a country code of one to three digits and a national significant number ². The edition in force is E.164 (02/26) ³.

The subscription itself is identified by the IMSI. In the 3GPP numbering specification the IMSI has three parts: a three-digit mobile country code, a two or three digit mobile network code that identifies the home network, and the subscriber identification number within that network ⁴. ITU-T E.212 is the recommendation that defines the international identification plan for public networks and subscriptions ⁵. A register such as the HLR is where the dialled E.164 number and the IMSI are linked, which is why the answer cannot be derived from the number alone.

The last three rows are the point. They are facts held by the operator and exchanged on its signalling network, so no public table can supply them.

Our phone product validates a number against the numbering plan, using Google libphonenumber metadata and the NANPA area code report. It returns the E.164 form, national and international formats, the country, a number type and, for North American numbers, the area code and its region. The carrier field is always null, and the response says the check cannot tell whether the number is active or has been moved to another carrier.

Our carrier lookup reads the public NANPA central office code and thousands-block reports and returns the carrier a block was first assigned to. It covers US numbers, and its ported field is always unknown. Neither product sends anything over a signalling network, and neither can see whether a handset is on.

1curl -X POST https://YOUR_API_HOST/v1/phone \
2  -H "Authorization: Bearer $LOOKVALID_API_KEY" \
3  -H "Content-Type: application/json" \
4  -d '{"phone":"+12025550143"}'

In our captured example for that number the answer is number_type: fixed_line_or_mobile, area_code: 202, region District of Columbia, carrier: null, and line_type_source: numbering-plan. The type comes from the plan, and the plan cannot say more.

• Cleaning a list before use: run the numbering-plan check first. Invalid and impossible lengths are free, because a lookup that finds nothing is not charged.
• Routing or labelling US numbers by network history: add the carrier lookup, and treat its carrier as the original assignee.
• Needing live status or roaming: that is operator data, outside what these checks cover.

Start with the phone validator to see the fields on a number of your own, or follow the quickstart to call the API.