The licensed-operator advantage: what direct SIGTRAN actually gives you

The licensed-operator advantage: what direct SIGTRAN actually gives you

"Licensed operator" is a regulatory label with technical consequences. It means a national telecommunications regulator has authorised an entity to connect directly to the global signalling network, to be allocated signalling point codes, to originate and terminate Mobile Application Part operations on its own behalf, and to take legal responsibility for what happens on that connection. On a product page, the label looks like marketing. At the signalling layer, it is the difference between asking a friend to make a call on your behalf and dialling the number yourself.

This post describes what that label actually buys in practice, walking through the protocol stack and the concrete operations a licensed operator runs differently from an aggregator. Aggregators are not the antagonist of the post. Many are capable operators in their own right. The post is here to be precise about which properties of Tensormobile's APIs follow from the licensed-operator architecture and which do not.

SIGTRAN and MAP, in two paragraphs

Signalling System No. 7 is the control-plane protocol family that carries call setup, SMS delivery, subscriber-data operations, and mobility management between mobile network elements. It was originally specified for TDM circuits in the 1980s and has been carried over IP by the SIGTRAN protocol family (M2PA, M3UA, SUA, running over SCTP) since the early 2000s. SIGTRAN preserves the semantics of SS7 while moving the transport to IP, which is why modern mobile core networks interwork between legacy and IP-signalling endpoints without loss of functionality. Every mobile operator in commercial service today uses SIGTRAN as the transport for its SS7 signalling traffic. Every SMS between two networks traverses this stack.

On top of SS7/SIGTRAN sits the application layer. The Transaction Capabilities Application Part provides transaction semantics. Above TCAP, the Mobile Application Part carries the actual mobile operations: subscriber authentication queries, routing information retrieval, location updates, SMS delivery, and supplementary service management. The canonical reference is Dryburgh and Hewett's Signaling System No. 7, which remains the single most authoritative technical primer on the protocol stack and is the text most operator-side engineers cut their teeth on.

What a licensed operator has that an aggregator does not

A licensed operator carries three entitlements that an aggregator cannot replicate, in increasing order of importance: a signalling point code, a global title, and the authority to originate and terminate MAP operations on its own behalf.

A signalling point code: a point code is the address used by MTP3 (in legacy SS7) or M3UA (in SIGTRAN) to route signalling messages to a specific network element. Licensed operators are allocated their own point codes by national and international authorities, with the ITU allocating international signalling point codes and national regulators allocating national ones. Point codes are not rentable in any meaningful sense. An aggregator without its own point code federates behind someone else's, which means its traffic appears on the signalling network as traffic originating from that other party, with that party's liability and routing decisions attached.

A global title: at the SCCP layer above MTP3, routing happens by global title, which is an E.164-like address used to identify a signalling endpoint for a specific service. A licensed operator typically has one or more global titles representing its HLR, its SMSC, and its MSC-like functions. These are the addresses that other networks route to when they send MAP operations intended for the operator's subscribers. Aggregators typically operate with delegated global titles, either their own but smaller in scope, or shared with a carrier partner.

The authority to originate and terminate MAP operations on its own behalf: this is the legal and technical consequence of the first two items. With its own point code and its own global title, a licensed operator can issue a SendRoutingInfoForSM, originate a MT-Forward-SM, perform an UpdateLocation, or invoke a SendAuthenticationInfo as a first-class signalling participant. An aggregator can cause these operations to be issued, but only through an intermediary that holds its own license and signalling footprint. The aggregator can get the operation done. The licensed operator does it directly and owns the resulting trace.

The four MAP operations that matter for our APIs

The APIs Tensormobile ships, including silent auth, SIM swap detection, HLR lookup, and A2P SMS with handset-level delivery confirmation, each resolve to one or more specific MAP operations.

SendRoutingInfoForSM (SRI-for-SM): the HLR query that returns the IMSI currently bound to an MSISDN, the global title of the serving MSC, and associated routing information. It is the primitive underneath any number-intelligence API, and it is the primitive underneath the first half of an SMS delivery (the "where do I send this?" lookup). A licensed operator issues SRI-for-SM directly, with its own signalling identity, and receives responses of whatever freshness the terminating HLR provides.

MT-Forward-SM: the operation that actually delivers an SMS to a handset, via the serving MSC. A successful MT-Forward-SM produces a delivery acknowledgement that travels back through the signalling network and ends up as the "class four" delivery receipt described in our DLR fabrication post. The operation is visible as a first-class event on a licensed operator's signalling logs. On an aggregator's logs it is visible only as a claimed outcome from an upstream party.

UpdateLocation and CancelLocation: these operations fire whenever a subscriber's serving MSC or VLR changes, including on SIM swap and on roaming handover. A licensed operator observing its own subscribers' provisioning history has an authoritative record of when the IMSI-to-MSISDN binding changed, which is the primitive underneath the SIM-swap signal. An aggregator without access to the operator's provisioning audit trail has only the external side: probing SRI-for-SM periodically and inferring changes from IMSI differences.

SendAuthenticationInfo: this operation is part of the Authentication and Key Agreement exchange. It is how the Authentication Centre produces the authentication vectors (triplets in 2G, quintets in 3G/LTE) that the MSC/VLR uses to challenge the handset. Silent network authentication rests on the fact that this exchange has already happened at network attach and that the operator can issue an OAuth or OpenID Connect token bearing the MSISDN claim based on the completed AKA. A licensed operator runs its own Authentication Centre and can vouch for the AKA directly. An aggregator cannot, by definition.

What this actually produces on the API surface

The user-visible consequence of owning the signalling footprint is that several product claims become verifiable rather than aspirational.

"Our HLR lookup returns the live IMSI": when Tensormobile is the home operator, the IMSI in the response is pulled directly from the HSS. When Tensormobile is querying another operator via SRI-for-SM, the IMSI returned is whatever the target HLR returns, subject to that operator's caching policies. The distinction is observable to the integrator because the resolution path is documented per region: home, CAMARA federation, or SRI-for-SM probe.

"Our SIM swap signal returns the timestamp, not an inference": where Tensormobile is the home operator, the timestamp is exact, drawn from the HSS provisioning audit trail. Where Tensormobile is federated via CAMARA, the timestamp is whatever the home operator's federation response reports. Where Tensormobile is probing, the timestamp granularity is the probe interval. An aggregator federating through a peer inherits whichever of these applies, plus one additional hop of uncertainty.

"Our delivery receipts reflect MAP events, where the path supports it": when the delivery path is direct (Tensormobile's own subscribers, or a direct SMPP interconnect with the terminating SMSC), the class-four receipt reflects the RP-ACK from the MSC. When the path is aggregated, the receipt is labelled with the highest class observable, which may be class two or class three. The labelling describes what happened on the wire, not what the dashboard wants to display.

"Silent auth runs as operator-hosted": for subscribers on the Tensormobile home network, the authorisation server in the OIDC flow is Tensormobile's, the HSS query is internal, and the ID token is issued under Tensormobile's signing key. For subscribers on other networks, Tensormobile participates in CAMARA federation and the authorisation server is the home operator's. In either case, the silent-auth decision is not running behind a vendor abstraction layer. It is running on an operator's footprint.

What licensed-operator status doesn't do

The architecture is real, but it is not magic. Several failure modes do not go away.

Subscribers on other operators remain limited by those operators. Federation via CAMARA or roaming-based fallback gets the resolution part of the way there. It does not make Tensormobile the home operator for everyone's subscribers. Any claim that ignores this is untrue at the level of physics.

Signalling-layer attacks still exist. SS7, despite its operator-grade authentication design, has known vulnerabilities that have been extensively documented in surveys of the attack surface and in real-traffic analyses of operator networks. Signalling firewalls at the STP level reduce the attack surface, but they do not eliminate it. The argument for silent auth over SMS-based authentication is not that the signalling network is perfectly secure, but that removing SMS from the authentication loop removes a specific and well-documented class of attack.

Coverage varies by geography. Operator footprints, direct interconnects, and CAMARA federation are all geographically uneven. A product page that claims "global coverage" without qualifying by region is in the same category of claim as "100 percent delivery." For every region Tensormobile serves, the resolution path is documented and the per-API performance is reported in that region.

How Tensormobile uses this architecture

Aggregators have real advantages, including breadth of integration, commercial agility, and lower operational overhead for smaller customers. A licensed operator is not automatically a better choice for every application. For a global B2C messaging app with no authentication-critical paths, a good aggregator is probably fine. For a fintech running authentication and fraud signals on top of its messaging flow, the architectural difference matters in ways the aggregator's pricing page does not capture.

The question for the integrator is which claims their downstream logic depends on. Logic that depends on "the timestamp we got is the real timestamp" needs a verifiable resolution path. Logic that depends on "the delivery was confirmed at the handset" needs the MAP operation. Logic that depends on "the authentication was signed by the operator whose subscriber this is" needs the operator identity attached to the response.

The licensed-operator architecture is the substrate for TensorConnect (direct A2P termination on Tensormobile's own signalling footprint or via direct MNO interconnects) and TensorSignal (MAP-resolved number intelligence with published per-region resolution paths). Both products carry provenance fields on every response: which path resolved the query, which operator returned the result, and what the originating regulatory regime is. Integrators who care about the difference can audit the path. Integrators who do not care can ignore the field, and the API works the same way.

"Direct SIGTRAN" and "licensed operator" describe how a signalling network actually routes a specific operation to a specific endpoint with a specific signature. The architecture is what determines which claims about the API are verifiable.