Send Authentication Info and HLR behaviour across GSM and UMTS

Mobile networks across Sydney, Melbourne, Brisbane, Perth, Adelaide and regional Australia still depend on authentication exchanges that began long before smartphones became mainstream. The underlying request that verifies a subscriber's identity is rooted in a Mobile Application Part procedure known as MAP Send Authentication Info, executed whether a handset attaches to a Telstra 4G small cell or to an Optus macro site in the Pilbara. Understanding how the Home Location Register, working with its Authentication Centre, returns the correct response for each access generation is essential for engineers modernising legacy interconnects.

In Australian operator environments the procedure is rarely isolated. SAI requests are issued by MSC servers, SGSN nodes and IMS-attached entities chasing 2G fall-back sessions. Authentication traffic also runs alongside bearer-side procedures such as call diversion numbering flows, so operational teams correlate both streams when investigating dropped sessions. The HLR must respond in a way consistent with the serving network's declared security capabilities, otherwise calls can fail silently at the radio interface.

The response is shaped by the subscriber record, the MAP version, the algorithm provisioned in the AuC, and whether the subscriber is registered as a GSM identity or a UMTS-capable one. This article walks through the exchange, the returned vectors, and the differences between GSM triplets and UMTS authentication quintuplets.

Role of the HLR and authentication centre

The HLR stores each subscriber's permanent identity, including the IMSI, Ki secret key and cryptographic profile. In Australian deployments the AuC is co-located with the HLR so that Ki never leaves a secure boundary. When a Send Authentication Info request arrives, the HLR queries its internal AuC, hands over Ki and the configured algorithm set, and waits for one or more vectors.

Operators have historically supported COMP128 variants for GSM and the MILENAGE family for UMTS, with most networks now leaning on MILENAGE for 3G and beyond. The HLR must therefore select the right algorithm context per subscriber before returning the vectors.

Structure of the MAP_SEND_AUTHENTICATION_INFO message

The MAP procedure is defined under 3GPP TS 29.002 and uses the application context MAP_SEND_AUTHENTICATION_INFO_service. The request carries the IMSI, optionally including the number of vectors requested and the network type indicator. Australian nodes from an MSC-S in Adelaide to an SGSN near the Gold Coast populate these parameters based on local policy and the radio access technology in use.

The response, sendAuthenticationInfo_Response, contains an array of AuthenticationTriplet or AuthenticationQuintuplet structures depending on the network type requested. Traces captured at the SS7 border of major carriers show response times well under 200 milliseconds when the AuC is healthy.

Vector generation for GSM and UMTS subscribers

For a GSM-only subscriber the HLR returns triplets derived from COMP128 or the operator's chosen GSM algorithm. Each triplet bundles RAND, the expected SRES and the session key Kc. The MSC or VLR stores these and later issues RAND to the mobile, which computes SRES inside the SIM using the same Ki. A mismatch indicates a corrupted SIM, a cloning attempt or a roaming misconfiguration.

UMTS replaces the triplet with a quintuplet containing RAND, XRES, CK, IK and AUTN. The HLR generates the quintuplet using Ki through MILENAGE, signs AUTN with the operator variant configuration, and returns the full vector. The 3G node uses AUTN to prove network authenticity to the handset, a step absent in GSM. Australian carriers issued quintuplets throughout the 3G era on networks such as Telstra's Next G and Optus's parallel 3G overlay.

Behaviour differences across 2G and 3G serving nodes

The HLR discriminates between GSM and UMTS using the subscriber profile and the network type in the MAP request. A 2G VLR normally triggers triplet generation because GSM nodes cannot interpret AUTN, while a 3G SGSN with the UMTS network type set triggers quintuplet production.

Operators in Hobart, Darwin and Canberra often run hybrid cores where the same HLR serves both legacy and modern nodes. If the HLR receives a UMTS request from a node that is not declared as 3G-capable, it can fall back to triplet mode. Engineers reviewing traces during access transitions frequently see interleaved triplet and quintuplet flows, which complicates root-cause analysis when requester and HLR disagree on subscriber capabilities.

Operational watchpoints in live deployments

ACMA-regulated carriers must keep audit trails for any anomaly that could indicate signalling fraud. The AuC should be sized to handle peak vector demand during mass re-attach events triggered by outages in capital cities, because request storms can saturate it quickly during regional faults.

Engineers should also verify that the HLR returns the correct error cause when a subscriber cannot be authenticated. Returning a generic system failure instead of unknown subscriber or roaming restriction makes root-cause analysis harder for Australian Signals Directorate-aligned incident teams and extends customer-visible outage time.

Practical recommendations for engineers

Maintaining clean SAI exchanges on a hybrid GSM-UMTS core benefits from a few disciplined habits. The list below reflects how Australian operators structure day-to-day operations.

• Confirm that the HLR-AuC pairing supports both COMP128 and MILENAGE so legacy GSM and modern UMTS requests both succeed.
• Audit subscriber records so the authentication profile matches the declared network type in the MAP request.
• Configure sensible limits on the number of vectors returned per call to reduce AuC load during peaks.
• Retain sendAuthenticationInfo traces at the SS7 and SIGTRAN border for the ACMA-required retention window.
• Monitor for repeated AUTN failures, which can indicate SIM cloning or rogue femtocell activity.
• Test fallback paths between triplet and quintuplet generation in a controlled lab before deploying HLR upgrades.
• Coordinate with the ACCC and internal fraud teams when abnormal authentication rejection patterns appear across regions.

A MAP Send Authentication Info exchange may look routine, but it is the single procedure that decides whether a handset is allowed onto the network. Australian carriers rely on the HLR to issue the right vector, with the right cryptographic profile, at the right moment, and that quiet decision shapes every successful call, SMS and packet session that follows.