Overview

Any Time Interrogation (ATI) is a CAMEL/IN procedure used by operators to retrieve a subscriber’s current status and coarse location information (e.g., serving MSC/VLR and Cell Global ID/LAI) without disturbing ongoing service.

In practice, ATI answers “Where is this IMSI right now and is it reachable?” and does so over SS7/MAP with minimal network impact compared to active location services.

This article maps ATI to the exact 3GPP standards, decodes its parameters and responses, compares it to LCS, Diameter Sh/SLh, and 5G NEF/UDM, and provides operator-grade security, KPIs, runbooks, and pricing insights. If you’re deciding whether, where, and how to enable ATI across 2G/3G/4G/5G, you’ll find the standards references, guardrails, and checklists you need to move from consideration to safe deployment.

Any Time Interrogation (ATI) in CAMEL/IN: definition and purpose

ATI is a CAMEL/IN function that lets a gsmSCF or authorized service node query the HLR/HSS for a live snapshot of a subscriber’s state and location context. It typically returns subscriberState (e.g., idle/busy/notReachable), locationInformation (Cell Global ID/LAI, MSC/VLR address), and optional classmark elements.

As defined in the Mobile Application Part (MAP), ATI is read-only and does not modify subscriber data or trigger call/session changes. It should not disrupt service flows or cause more paging than requested (see the AnyTimeInterrogation operation in 3GPP TS 29.002 (MAP)).

Accuracy is limited to radio cell or routing area level—think Cell ID/TA, not GPS-grade positioning. Use ATI for context and routing decisions, not for precise emergency location.

Because paging can be induced depending on requestedInfo flags, operators need policies that balance freshness against radio load and privacy.

Standards and normative references for ATI and related procedures

ATI behavior and payloads are precisely described in 3GPP MAP and CAMEL specifications. Adjacent functions live in LCS (for regulated positioning) and in Diameter/5G SBA for modern data access.

Authoritative definitions of MAP operations and the SubscriberInfo container are in 3GPP TS 29.002 (MAP). CAMEL usage patterns are in 3GPP TS 23.078 (CAMEL).

For comparisons, the LCS framework is in 3GPP TS 23.271 (Location Services). 4G profile/status reads align to 3GPP TS 29.328 (Sh). 5G exposure is specified in 3GPP TS 29.503 (NEF Northbound APIs).

Use these specs to ground your design decisions, justify exposure control, and ensure interop in multi-vendor cores.

3GPP TS 29.002 (MAP) and clause-to-field mapping

The MAP specification defines ATI and the composition of SubscriberInfo returned by the HLR/HSS. This includes locationInformation (CGI/LAI, VLR/MSC address), subscriberState (e.g., notReachable, reachable), and optional elements such as msClassmark2/3, IMEI, and mnpInfo depending on network configuration (per 3GPP TS 29.002 (MAP)).

It also defines MAP_PSI (Provide Subscriber Information), which a VLR/MSC uses to supply or update information like current location or subscriber state. This often occurs as part of fulfilling an ATI request.

Read TS 29.002 to see how requestedInfo flags switch on specific data items. Confirm encoding rules so your decoders and filters are precise. In practice, the clause-to-field mapping is what you’ll rely on for policy enforcement at your STP and for correct parsing in your analytics.

CAMEL anchor points for ATI in TS 23.078

TS 23.078 describes CAMEL’s service control framework, where the gsmSCF is the logical consumer of ATI when service logic needs near-real-time context about a subscriber.

CAMEL stages define where ATI can be invoked safely without affecting call control. The spec clarifies that ATI is not a signaling path to modify subscription data or inject charging—those belong elsewhere (e.g., AnyTimeModification) (see 3GPP TS 23.078 (CAMEL)).

Treat ATI as a read-only, event-independent query that the gsmSCF can issue within the bounds of defined service triggers and operator policy. This keeps service logic decoupled from low-level signaling side effects like paging storms.

LCS and Diameter/5G analogs

LCS under TS 23.271 provides regulated positioning (e.g., Cell-ID, OTDOA, A-GNSS) with user consent and emergency service regimes. This is distinct from ATI’s coarse status/location context (per 3GPP TS 23.271).

In 4G, Sh/SLh interfaces (TS 29.328/29.329) cover profile and status reads/writes to HSS/UDR. SLh enables MME/HSS lookups; these are stronger fits for subscription attributes than for live radio context (see 3GPP TS 29.328 (Sh)).

In 5G, NEF northbound APIs (TS 29.503) expose network events and capabilities under policy control with audit, quotas, and CAPIF alignment. This enables modern, API-gateway-style governance (see 3GPP TS 29.503).

Your selection should align to the data sensitivity and governance model. Use ATI for coarse, operator-internal context; LCS for precise, consented location; Sh/NEF for profile and event exposures.

MAP_ATI and MAP_PSI parameters and example responses

You can only secure and operationalize ATI if you understand its arguments and outputs at the field level. MAP_ATI carries requestedInfo flags that tell the HLR what to fetch (e.g., locationInformation, subscriberState).

MAP_PSI lets a VLR/MSC provide subscriber data back to the HLR when needed. Reading TS 29.002 alongside decoder traces will let you define exact filtering rules and test cases.

With that foundation, you can set paging policies, decode MSC/VLR routing numbers, and map CGI/LAI to your RF planning datasets to make the responses actionable.

Request parameters that drive behavior

The ATI argument structure determines what the HLR will return and whether paging may be triggered if the network lacks fresh data. Key drivers include the msisdn/imsi identifier, the requestedInfo bitmask (e.g., locationInformation, subscriberState, currentLocation), and optional flags for subscriberInfo extensions like msClassmark.

Precise selection of requestedInfo reduces radio load, speeds responses, and tightens your exposure surface. Start minimal and scale only if operational need is proven.

Response fields and typical values

The ATI Result includes SubscriberInfo with the elements you requested and that the HLR could obtain. Expect to see locationInformation (LAI/CGI, possibly with routing area for PS contexts), subscriberState (e.g., idle, busy, notReachable), and optionally mscNumber/vlrNumber, msClassmark, and IMEI depending on your HLR configuration and interconnect restrictions.

Operators should codify how each field is used downstream (e.g., RA workflow enrichment vs routing decisions). Apply masking where minimal data suffices.

Example decode scenarios

A few realistic decodes help clarify what to infer and how to react operationally.

In each scenario, log decision rationale, mask unneeded fields, and adjust requestedInfo on future queries to achieve the least-data principle.

ATI vs LCS and 4G/5G subscriber data queries (Diameter Sh/SLh, NEF/UDM/CAPIF)

Choosing the right interface is the crux of safe, effective deployments. ATI is for low-latency, coarse context from HLR/HSS. LCS is for regulated positioning workflows. Sh/SLh or NEF/UDM are for subscription and event exposure with modern governance.

TS 23.271 explicitly frames LCS consent and emergency carve-outs. TS 29.328 shows Sh’s strengths in profile/state retrieval. TS 29.503 adds policy-managed 5G APIs that cleanly separate app developers from core signaling.

Decide by accuracy required, privacy regime, paging tolerance, and auditability needs. Then standardize your routing: operator-internal systems use ATI for context; external partners consume NEF APIs with quotas and consent checks.

When to use ATI vs LCS

Use ATI when you need current service state and approximate location sufficient for routing, fraud triage, or network assurance. It is also appropriate when you cannot wait for full LCS orchestration.

Choose LCS when:

If a workflow starts with ATI and flags risk or ambiguity, escalate to LCS with proper approvals rather than widening ATI scope.

When subscriber data via Sh/SLh or NEF is a better fit

When the question is “What does the subscription say?” rather than “Where is the device right now?”, Sh/SLh or 5G UDM/UDR via NEF is the correct path.

Prefer Sh/UDR/UDM when:

This shift reduces attack surface and aligns data exposure with modern API security models. It also preserves SS7/MAP for strictly internal control-plane needs.

ATI vs ATSI vs ATM: disambiguation and selection guide

ATI (Any Time Interrogation) retrieves dynamic subscriber context like state and location. ATSI (AnyTimeSubscriptionInterrogation) reads subscription data from HLR/HSS (e.g., ODB, CAMEL subscriptions). ATM (AnyTimeModification) updates certain subscription data under strict authorization.

In operational terms, ATI is read-only and event-agnostic. ATSI is for reading profiles and service settings. ATM is for controlled, auditable changes to subscriber data.

Select ATI when your service logic needs reachability or MSC/VLR context. Choose ATSI when a decision depends on stored HLR attributes. Use ATM only when your process and RBAC allow on-the-fly modifications with rollback and full audit.

Keep these interfaces segregated in policy so read paths can never escalate to write paths without explicit, multi-party approvals.

Security, privacy, and compliance guardrails

Unchecked ATI exposure is a known vector for subscriber tracking and reconnaissance, particularly when combined with MAP_PSI or other MAP primitives to refresh or cross-validate data. The GSMA’s guidance explicitly warns against accepting ATI from external networks and emphasizes signaling firewall enforcement; see GSMA FS.11 SS7 Interconnect Security Guidelines.

ENISA has also documented EU incidents where signaling abuse enabled location tracking across borders; see ENISA Signalling Security in Telecommunications. Lock down ATI to internal trust zones, implement cross-layer validation (SCCP/MAP/GT), rate-limit requests, and ensure all invocations are attributable to a service ID with approval lineage.

For roaming, never trust inbound ATI. Terminate and log with partner notifications if needed.

Lawful basis, minimization, and retention

ATI-derived data is personal data when it can identify or locate a subscriber. Processing requires a lawful basis under GDPR Article 6 and must follow the minimization, purpose limitation, and storage limitation principles in Article 5; see the GDPR Regulation (EU) 2016/679.

Operational use cases typically rely on legitimate interests or legal obligation (e.g., network integrity). You must document a DPIA for high-risk cases, define retention (e.g., hours to days for operations, longer only for incident/legal holds), and map cross-border signaling flows to your Schrems-compliant transfer framework.

Always ask: what’s the minimal requestedInfo we need, do we mask or hash CGIs when only state is needed, and what is the shortest retention that preserves auditability? Build these choices into your service design and review them annually.

Auditability and role-based access

Every ATI invocation should be linked to an authenticated service identity, a named change ticket or case ID, and a purpose code. Logs should capture selector fields, requestedInfo, response metadata, and decision outcomes.

Implement RBAC with separation of duties: only specific roles can configure ATI policies, fewer can invoke at scale, and an independent team reviews usage patterns monthly. Alerts should fire on unusual selectors (e.g., high-frequency queries on a single IMSI), off-hours spikes, and cross-border attempts.

Prepare incident response playbooks to suspend access and escalate to security. This audit spine deters misuse and gives you defensible evidence for regulators and partners.

Operator KPIs, SLAs, and safe rate limiting

To keep ATI valuable and safe, monitor end-to-end performance and control-plane side effects. The core KPIs include latency (with and without paging), success rate, error cause distribution, paging attempts per ATI, and request rates per service and per IMSI.

Tie KPIs to SLAs with your internal customers so they understand the trade-offs. If they demand fresh location on every call, page budgets and radio KPIs will suffer.

Implement hierarchical rate limits (per-service, per-IMSI, per-source GT) and burst controls. Prefer sampling or caching for non-critical analytics use cases.

Benchmark targets and alert thresholds

Start with pragmatic, conservative targets and tune with real traffic.

These thresholds are starting points. Refine them based on your RAN capacity, HLR/HSS performance, and privacy risk appetite.

Roaming, interconnect controls, and 5G exposure patterns

Roaming heightens ATI risk because it invites cross-border queries and complex trust chains. Your default stance should be deny-by-default at borders with strict GT/OPC filtering.

Maintain contract-level clauses that prohibit inbound ATI/PSI from partners. Implement STP signaling firewalls to enforce it, logging and notifying when violations occur as required by GSMA guidance.

In 5G, SEPP protects inter-PLMN SBA traffic with security and policy controls. That does not make ATI-like data safe to expose. Use NEF with explicit policies, quotas, and partner onboarding instead of legacy signaling wherever possible.

Keep internal-only ATI in legacy domains. Keep external exposure only via NEF/CAPIF with regulator-ready governance.

Firewall and policy patterns at borders

Translate policy into concrete, testable controls.

Periodic negative testing at borders (spoofed GTs, malformed ACs) is essential to ensure these policies stick through upgrades.

Fraud and revenue assurance with ATI: where it helps and where it doesn’t

ATI is effective for quick context checks—verifying a roamer’s serving MSC before rating anomalies, correlating suspicious SIM swap events with reachability, or triaging inbound signaling anomalies. It complements NRTRDE and TAP by providing live state/location clues that billing feeds lack in near real time.

However, ATI is not a replacement for behavioral fraud analytics, handset fingerprinting, or usage-based alarms. Its coarse location and occasional staleness limit precision.

Use ATI to accelerate investigations and to gate expensive LCS pulls. Anchor revenue assurance in call/data detail records, NRTRDE, and anomaly detection fed by multiple signaling domains.

Align RA playbooks so ATI queries are sparse, justified, and logged with case IDs.

Configuration, filtering, testing, and monitoring runbooks

A disciplined runbook ensures consistency across change windows and incident response. Establish golden configs for STP/MAP and Diameter edges, add canary tests and negative tests to your CI for signaling, and wire KPIs to dashboards with clear SLOs and paging thresholds.

Version-control policy artifacts (e.g., GT lists, requestedInfo masks) and require dual control for changes that widen exposure or relax rate limits.

SS7/MAP edge controls

Start at the STP and HLR edges where ATI/PSI traverse.

Diameter and 5G exposure controls

Map modern exposures to policy-centric gateways rather than SS7.

Troubleshooting and lab setup to simulate ATI end-to-end

A realistic lab saves time in production by revealing paging, timing, and error behaviors you’ll see on live nodes. Stand up an HLR/HSS simulator with configurable VLR/MSC peers. Seed a small RF map to translate CGI/LAI to regions.

Build a harness to generate ATI requests with varying requestedInfo and rates. Add a signaling firewall in front of the HLR to validate filtering and logging.

Inject negative conditions—VLR unreachable, timeouts, malformed AC—to confirm error handling and observability. Correlate HLR logs, STP traces, and your client-side timestamps to build a complete picture of end-to-end latency and cause codes.

Paging scenarios and timing effects

Paging can add seconds to ATI completion and may still return stale data if the UE is camped in weak coverage. Emulate these scenarios by configuring the VLR to require paging for currentLocation and by varying paging retries and timeouts.

Measure the tail latencies and success impacts. Compare ATI latency distributions with and without currentLocation to quantify the operational trade-off for product teams.

In RAN-limited conditions, demonstrate that paging multipliers rise with concurrent ATI. This makes the case for stricter rate limits or for switching to cached or batched queries.

Document these findings in SLOs so services accept realistic response windows.

Pricing and TCO drivers

ATI’s cost profile spans licensing, signaling load, and operational overhead. Expect per-node licenses for HLR/HSS features and signaling firewalls. Capacity-based pricing applies for STP/SIGTRAN links, and there may be per-message fees in managed cores.

On the infrastructure side, the marginal cost is driven by HLR CPU for ATI/PSI dialogues, STP firewall rule complexity, and observability pipelines. Virtualized cores shift costs toward horizontal scaling but also enable right-sizing.

Budget heuristics that help:

A simple ROI view often emerges: if ATI reduces LCS pulls by X% and accelerates fraud triage by Y minutes per case, it pays for itself. That holds provided you cap paging externalities and keep exposure internal.

Case studies of ATI misuse and mitigations

Real incidents show how small policy gaps enable outsized harm. ENISA’s reporting highlights cases where attackers leveraged SS7 signaling to locate subscribers, sometimes chaining multiple MAP operations to refresh data; see ENISA Signalling Security in Telecommunications.

In one anonymized scenario, an operator accepted ATI from a roaming link due to permissive GT filters. Attackers queried targeted IMSIs for weeks, mapping movement via CGI changes. Root cause: missing deny rule and no per-IMSI anomaly detection. Mitigation: block inbound ATI/PSI, add per-IMSI rate limits and off-hours alerts, and notify partners of attempted abuse with timestamps.

In another case, an internal analytics service began requesting currentLocation during a holiday traffic spike, unintentionally driving paging storms in a dense urban RAN. Root cause: a code change widened requestedInfo without review, and no circuit breaker existed. Mitigation: enforce least-privilege requestedInfo at the firewall, require change tickets for policy widening, and implement a paging-per-ATI SLO with automatic throttling.

Finally, a multi-tenant MVNE exposed an ATI-like function to an enterprise portal without strong RBAC. An overprivileged account scripted bulk queries across thousands of IMSIs, creating privacy and reputational fallout. Root cause: missing per-tenant quotas and purpose-bound access. Mitigation: move exposure to NEF with OAuth scopes, institute per-tenant quotas and jittered rate limits, and require explicit consent or contract addenda for location-derived data.

These cases converge on the same lessons: deny ATI at borders, constrain requestedInfo, instrument tightly, and treat every invocation as an auditable, purpose-bound action. With standards-based grounding and disciplined operations, Any Time Interrogation (ATI) can serve operators safely and effectively.