AP Component Handling for MAP and CAP in SS7 Networks

In the layered world of Australian telecommunications, TCAP rides on top of SCCP and supplies the transaction framework that MAP and CAP rely on across the PSTN and mobile cores operated by Telstra, Optus, and TPG Telecom. Whether a roaming subscriber lands in Brisbane or a CAMEL prepaid call hits a service switching point in Perth, the dialogue that follows is shaped by three building blocks: Invoke, Return Result, and Return Error components. Each carries an operation code, parameters, and linkage identifiers that determine whether a transaction completes, rolls back, or surfaces a fault.

Engineers tracing a glitch in an HLR lookup or a missed prepaid announcement need to read these components fluently. Misreading a Return Result Not Last as a final response, or treating a return error problem code as a generic reject, can send a fault hunt down the wrong rabbit hole. The sections that follow walk through the mechanics, the protocol-specific quirks of MAP and CAP, and how to keep observability tight when SCTP associations flap on long-haul links between capital-city data centres.

How TCAP packages a component

A TCAP component is essentially a tagged record. The transaction portion supplies the dialogue handle and an optional application context name, while the component portion carries the Invoke, Return Result, or Return Error that does the actual work. The component sublayer is independent of whether you are running structured or unstructured dialogues, which is why the same component format shows up whether a CAMEL service control point in Adelaide answers a gsmSCF query or a gsmSSF forwards an event to it.

Every component carries an Invoke ID so that correlates can be matched. For Return Result and Return Error the same Invoke ID is echoed back, tying the response to the original request. The operation code, encoded locally per the application context, identifies which MAP or CAP operation is in play, and the parameter sequence follows ASN.1 BER rules.

The Invoke component in detail

An Invoke begins a logical operation. MAP operations such as UpdateLocation or SendRoutingInfoForSM are classic examples, as is the CAP InitialDP operation that arms a service switching point when a call hits a detection point. The Invoke component includes a linked ID when it depends on a previous operation, which is common in CAP chains where ApplyChargingReport must reference the matching ApplyCharging.

For the Australian market, where prepaid CAMEL services still play a meaningful role for inbound roamers from New Zealand and the Pacific Islands, getting the linked ID right is essential. A missing or duplicated linked ID is one of the more common causes of CAP dialogue aborts, and operators watching call completion rates between Sydney and Melbourne exchanges will see these as silent gaps in CDR records rather than explicit rejects.

Return Result Last and Not Last

Return Result comes in two flavours. Return Result Last signals the end of a multi-step operation; Return Result Not Last signals an intermediate segment. MAP dialogues often use Not Last when an operation has a segmented parameter set, such as long SendRoutingInfo responses carrying subscriber data that exceeds a single TCAP message size.

The choice between Last and Not Last affects how the receiving node manages its state machine. Treating a Not Last as final can orphan the next segment still in flight across the signalling link. When analysing traces, watch for parameter sequencing errors that force the peer to send a return error instead of the expected second segment.

Handling Return Error cleanly

Return Error carries an error code drawn from the application context and an optional parameter list. MAP and CAP define their own error catalogues, and the codes map differently to the TCAP problem codes that sit underneath them. A return error problem code such as MistypedParameter indicates a structural fault, while an application-level error code like UnidentifiedSubscriber is a semantic reply from the responding node.

ACMA fault management reviews occasionally surface mislabelled return errors, so engineering teams should distinguish between local problem codes raised by the stack and application error codes raised by the network element. Logging both, with the invoke ID attached, gives you a recoverable trail when a subscriber complaint about dropped calls lands on the service desk.

MAP-specific component patterns

In MAP, the most frequently exchanged components cluster around mobility management and short message service. UpdateLocation, CancelLocation, InsertSubscriberData, and DeleteSubscriberData are the workhorses of the HLR-VLR dialogue that underpins national roaming across Telstra's Band 28 footprint and Optus's regional partners. Each of these is a single Invoke-Return Result Last exchange, with the Return Error branch carrying codes like UnknownSubscriber or RoamingNotAllowed.

SMS-related operations such as ForwardShortMessage use components in much the same way, but with tighter timer expectations because of TCAP's role in supporting inter-carrier delivery. When messages queue up between gateways in different capital cities, component-level timeouts can pile up faster than application-level alarms, so monitoring Invoke latency rather than just TCAP abort counts gives a truer picture of health.

CAP-specific component patterns

CAP introduces longer dialogues and a richer component vocabulary. InitialDP, ApplyCharging, Connect, Continue, and EventReportBCSM form the CAMEL phase 2 and 3 toolkit that prepaid and virtual private network services rely on. A typical prepaid call flow in Australia will see an InitialDP from the SSF to the SCF, followed by an ApplyChargingReport after the call ends, often with EventReportBCSM messages interleaved if the call encounters busy or no-answer conditions.

Because CAP dialogues can be long-lived, operators must guard against SCTP path failures breaking an open dialogue mid-charge. The walkthrough on SCTP heartbeat in M3UA covers heartbeat interval tuning and association failover behaviour, and pairing that with component-level tracing lets an engineer pinpoint whether a charge record vanished because the dialogue was torn down abruptly or because the SCF never sent the expected ApplyChargingReport.

Practical recommendations for component handling

• Always log the Invoke ID alongside the operation code so return results and errors can be correlated without guessing.
• Decode the application context name early in trace analysis; it tells you whether to expect MAP or CAP component vocabulary.
• Distinguish Return Result Last from Not Last by checking the optional parameter tag before assuming a transaction has completed.
• Map TCAP problem codes to application error codes in your fault dashboards so on-call engineers see one consistent taxonomy.
• Watch SCTP heartbeats on inter-state SIGTRAN links between Sydney, Melbourne, and Brisbane, since path flapping can corrupt open CAP dialogues.
• Capture full TCAP transactions, not just component summaries, when chasing roaming issues with inbound subscribers from the Pacific.
• Rehearse component-level failure scenarios in lab tests, including missing linked IDs and mistyped parameters, so production staff recognise the patterns quickly.

Pull the last week of MAP UpdateLocation traces from a production signalling gateway, decode every Invoke ID, and confirm that Return Result Last components match the count of Invoke components issued. Running that reconciliation against your gsmSSF-CAP dialogue logs will surface any broken pairings before they show up as revenue leakage or audit findings.