MAP PSI query behaviour across GPRS and EPC mobile networks
The Provide Subscriber Information procedure, defined inside the Mobile Application Part of SS7, has carried subscriber state lookups between core nodes for decades. In a GPRS deployment, an SGSN asks the HLR for PSI when it needs IMSI, MSISDN, subscriber status, or location data tied to a mobile that just attached. In an Evolved Packet Core deployment, the same logical need is served differently, with MME elements exchanging identity information over Diameter on the S6a reference point.
For Australian carriers rolling out LTE while still running 2G and 3G layers in regional pockets, the interaction between these generations is a daily reality. Engineers at Telstra, Optus and TPG often have to trace a single subscriber session across both MAP and Diameter planes, especially when subscribers roam between a Pilbara mining camp and the Sydney CBD.
Protocol foundations of the provide subscriber information procedure
The MAP PSI message family sits inside TCAP dialogue and uses the HLR as the authoritative store. Common variants include PSI for IMSI retrieval, PSI for MSISDN retrieval, PSI for subscriber state, and PSI for location information. Each variant carries an Invoke ID that pairs with the returned Return Result, which is why logs from an SGSN often show interleaved conversations when multiple pages are open at once.
In a classic GPRS attach, the SGSN uses MAP Send Authentication Info first, then a Provide Subscriber Information exchange to confirm the subscription record before allocating a PDP context. The procedure is short, but a missing Return Error or a malformed Invoke ID is enough to stall attach times for travellers on a train between Brisbane and the Gold Coast.
EPS migration and the shift from MAP to Diameter
When a subscriber attaches to LTE, the MME no longer speaks MAP to the HSS. Identity and subscription state flow through Diameter Application, where S6a carries Authentication Information Request and Update Location, and S13 carries ME Identity Check. PSI as defined in 3GPP TS 29.002 still exists, but it lives mostly at the inter-RAT boundary and on the SGSN-MME handover path rather than on a fresh LTE attach.
Operators that consolidated their HLR into a unified HSS typically front the old MAP interface with a protocol converter. A single subscriber record may then be reached two different ways, and a Diameter timeout on S6a sometimes triggers a fallback PSI over MAP to verify the same identity. Aussie integrators running lab benches in Melbourne often rely on this dual-stack behaviour to validate cutover scenarios.
Comparing the two delivery models
| Aspect | GPRS MAP PSI | EPC Diameter equivalent |
|---|---|---|
| Transport | SCCP over MTP3 or SIGTRAN M3UA | SCTP over Diameter |
| Source node | SGSN | MME |
| Subscriber store | HLR | HSS |
| Typical operation | Provide Subscriber Information | Authentication Information Request, S13 ME Identity Check |
| Identity fields | IMSI, MSISDN, location, state | IMSI, IMEI, subscription data, APN profile |
| Fallback behaviour | Return Error to SGSN | Diameter Result-Code, may trigger MAP PSI for cross-RAT verification |
The differences in transport alone explain why tooling built for one generation rarely transfers cleanly to the other. PCAP filters, parser plugins and even visualisation dashboards usually have to be rewritten when the conversation moves from MAP over M3UA to Diameter over SCTP.
Practical use cases inside Australian operators
Australian carriers deploy PSI in several practical scenarios beyond a routine attach. Fraud teams request PSI to confirm whether a stolen handset has reattached after a SIM swap, customer-care desks at retail stores in Perth query MSISDN-to-IMSI mapping when a customer walks in with a damaged SIM, and lawful interception platforms rely on PSI and Subscriber Location procedures to anchor target identities.
Emergency services coordination, routed through the Triple Zero gateway, depends on accurate PSI responses so that dispatchers reach the correct mobile rather than a ported fixed-line number. Field engineers working from a servo in regional Queensland will sometimes run a manual PSI from a probe to double-check what the core is reporting when a customer complaint lands on their desk.
Security considerations and source point code checks
Because MAP PSI travels over SS7 and SIGTRAN, it is exposed to the same spoofing and relay risks that the wider signalling plane suffers from. Unverified peer Point Codes can answer PSI requests with attacker-supplied subscriber data, which is why every reply should be tied back to an authorised source. The SS7 Training guide on source point code verification walks through a concrete validation workflow that lab teams can adapt for both 2G and 4G probes.
In EPC, the same threat class appears on Diameter with forged Origin-Realm and Origin-Host AVPs. ACMA guidance for Australian carriers stresses validating peer identities before any subscriber information is released, especially for inbound roamer traffic terminating on a Melbourne or Sydney STPo.
Engineering recommendations for carrier labs
Engineers building reproducible MAP PSI traces can lean on a small set of habits that pay off across 2G, 3G and 4G reproducer rigs.
- Capture full TCAP dialogues rather than individual MAP operations, so the Invoke ID pairing is preserved in pcap.
- Mirror the HLR and HSS behind a single subscriber identity so MAP and Diameter views can be correlated per IMSI.
- Tag every reply with the originating Point Code and the SCTP association ID before logging, not after.
- Run source point code validation as a post-processing step on each PSI response, never as a side path.
- Keep a known-good baseline pcap from a real Telstra or Optus inter-network handover for diff testing.
- Document which variants your probe issues, because PSI for state and PSI for location return different mandatory AVPs and break field parsers in different places.
A practical next step is to script a one-button validation pass that fires a synthetic PSI from a lab SGSN, forwards the response through the existing source point code checker, and writes the verdict into a shared lab notebook. That single pipeline turns sporadic manual checks into a repeatable guardrail before the next EPC feature ships.
