GSM MAP Send Authentication Info Transaction Through TCAP
GSM authentication depends on a signaling exchange that lets a serving network obtain security vectors from the subscriber’s home network. The MAP Send Authentication Info operation, commonly abbreviated SAI, carries this request between a VLR or SGSN and the HLR/AuC.
SAI is an application-layer transaction, but it does not travel alone. MAP uses TCAP to manage the dialogue, while SCCP provides global title routing and MTP3 or SIGTRAN transports the signaling message through the SS7 network. Understanding these layers makes packet traces and fault reports much easier to interpret.
The procedure also illustrates the transition from classic circuit-switched signaling to IP-based SS7. In a modern deployment, M3UA and SCTP may replace traditional signaling links without changing the essential MAP operation.
The Purpose Of Send Authentication Info
When a mobile subscriber attempts to register, originate a call, or access a service, the VLR needs authentication material. Rather than storing permanent subscriber credentials locally, it asks the HLR for one or more authentication vectors using MAP SAI.
The request normally includes the subscriber’s IMSI and the number of vectors required. The HLR consults the authentication center, generates suitable parameters, and returns an authentication set. In GSM, this typically contains RAND, SRES, and Kc. RAND is the random challenge, SRES is the expected signed response, and Kc is the ciphering key.
The serving node sends RAND to the handset and compares the returned SRES with the expected value. Kc can then support radio-interface encryption. In UMTS, the returned material is richer and can include RAND, XRES, CK, IK, and AUTN.
Network Roles And Signaling Path
The VLR usually initiates SAI for circuit-switched mobility management, while an SGSN can perform a similar role for packet services. The HLR identifies the subscriber profile and obtains authentication data from the AuC, which may be integrated with the HLR or implemented as a closely associated function.
At the protocol level, the path commonly follows this sequence: MAP creates the operation, TCAP places it in a transaction, SCCP determines the destination using point codes and global titles, and MTP3 or SIGTRAN carries the message across the signaling network. A routing or translation failure at any lower layer can therefore appear to the application as an authentication timeout.
The SS7 training contact page can be useful when a trace review requires clarification about MAP procedures, TCAP behavior, or signaling infrastructure.
TCAP Dialogue And Operation Handling
A SendAuthenticationInfo transaction begins with a TCAP Begin message containing a MAP Invoke component. The invoke includes an operation code identifying SAI and parameters such as the IMSI and requested vector count. The originating node assigns a transaction identifier and an invoke ID so the response can be correlated correctly.
The HLR returns a TCAP Continue or End message, depending on the dialogue handling, with a Return Result Last component when the operation completes. The result includes the authentication vectors and may also carry information about the supported authentication method. TCAP dialogue portions can identify the MAP application context and help both sides apply the correct protocol version.
A failed operation can produce a MAP error component rather than a normal result. Typical causes include an unknown subscriber, absent subscriber data, unexpected data values, congestion, or an unsupported operation context. Timers at TCAP, SCCP, and MAP-related layers determine how quickly the serving node abandons the attempt and retries or reports failure.
Comparing Authentication Data Across Generations
The exact response content depends on the radio technology and MAP version. GSM authentication is based on a triplet, while UMTS authentication uses a quintet designed to provide stronger mutual authentication and separate integrity and ciphering keys.
| Aspect | GSM Authentication | UMTS Authentication |
|---|---|---|
| Main challenge | RAND | RAND |
| Network response check | SRES | XRES |
| Ciphering material | Kc | CK |
| Integrity material | Not separately provided | IK |
| Subscriber authentication token | Not used in the GSM triplet | AUTN |
| Typical serving node | VLR | VLR or SGSN |
| Home-network source | HLR/AuC | HLR/AuC |
LTE evolved the architecture further. Authentication information is generally requested through Diameter S6a between the MME and HSS, rather than through MAP over TCAP. This distinction matters when analyzing mixed networks, because a trace may contain MAP SAI for legacy access and Diameter authentication information requests for LTE access.
Reading A Packet Trace
A useful trace review starts with the TCAP transaction ID and SCCP calling and called party addresses. Confirm that the response uses the expected transaction relationship and that the global title translation points to the correct HLR or signaling gateway.
Next, inspect the MAP invoke parameters. An incorrect IMSI format, invalid numbering plan, unsupported application context, or unreasonable vector count can cause rejection before the HLR reaches the AuC. The return result should then be checked for the expected authentication-set structure and encoding.
Timing is equally important. A missing Continue or End message may indicate a congested route, failed SCCP translation, broken SIGTRAN association, or an overloaded HLR. Comparing the time between the Invoke and response with configured TCAP and MAP timers often separates remote application errors from transport failures.
Common Diagnostic Priorities
Use a consistent troubleshooting sequence when an SAI exchange does not complete:
- Verify IMSI encoding, MAP version, operation code, and requested vector count.
- Confirm SCCP global title translation, point codes, and subsystem numbers.
- Check TCAP transaction and invoke IDs in both directions.
- Compare MAP error codes with HLR, AuC, VLR, and SGSN application logs.
- Inspect M3UA, SCTP, MTP3, and signaling-link alarms for lower-layer loss.
Authentication failures should also be correlated with the subscriber’s mobility event. A successful SAI response followed by a rejected authentication challenge may indicate a radio-interface or key-handling issue rather than an SS7 problem.
Applying The Procedure In SS7 Training
The SAI transaction is a compact example of layered telecom signaling. It connects subscriber identity, authentication algorithms, MAP service logic, TCAP transaction control, SCCP addressing, and SS7 or SIGTRAN transport in one operational flow.
For study and operations, draw the message sequence from VLR or SGSN to HLR/AuC, label every protocol layer, and annotate the Invoke, Return Result, transaction identifiers, and likely failure points. Then compare a successful exchange with traces showing timeout, unknown subscriber, and malformed parameters.
Use this transaction model to strengthen practical SS7 analysis, and explore further learning resources or request focused assistance through the site’s support channel.
