ACR

Anonymous Communications Rejection

Services →
Introduced in Rel-7 Also in: Core Network

ACR is a supplementary service that automatically rejects incoming calls or sessions from parties who have hidden their calling line identity to protect user privacy and prevent unwanted contact.

Category
Services
Introduced
Rel-7
Where
Services › Codecs
Also touches
1 segments
Specifications
56 specs
ACR Description Purpose Related Classification Detected Changes Specifications

Description

Anonymous Communications Rejection (ACR) is a standardized supplementary service defined within the 3GPP framework, primarily for Circuit-Switched (CS) and IP Multimedia Subsystem (IMS) based networks. It operates as a network-based feature, typically provisioned and managed by the service provider on behalf of the subscriber. The core function of ACR is to intercept incoming communication attempts—such as voice calls or, in IMS, potentially other session types—and analyze the calling party's identification information. The key parameter is the presentation status of the Calling Line Identity (CLI), also known as Calling Party Number. If the incoming request is flagged with a presentation indicator signifying 'anonymous', 'withheld', or 'restricted', the ACR service logic is triggered. The network then prevents the call from completing to the called user's terminal, typically returning a specific tone, announcement, or SIP response code (e.g., 403 Forbidden) to the caller, indicating the call has been rejected due to anonymity.

Architecturally, for CS networks, ACR service logic resides within the Mobile Switching Center (MSC) or the Visitor Location Register (VLR) serving the subscriber. The MSC/VLR checks the subscriber's service profile, which includes the ACR subscription status, against the presentation indicator in the incoming call setup message (e.g., an ISUP Initial Address Message). For IMS networks, the service logic is implemented within the Serving-Call Session Control Function (S-CSCF) by applying initial Filter Criteria (iFC) that route the incoming SIP INVITE request to an Application Server (AS) hosting the ACR service. The AS evaluates the SIP P-Asserted-Identity header or the 'From' header with privacy settings to determine if the identity is presented. The service decision (allow or reject) is then enforced by the S-CSCF.

The service is highly configurable. Subscribers can typically activate or deactivate ACR via network-based management, such as Unstructured Supplementary Service Data (USSD) codes or through a customer portal. Some implementations may allow for more granular control, such as creating an exception list (a 'white list') of specific anonymous numbers that are permitted to connect. The service interacts closely with other supplementary services like Calling Line Identification Presentation (CLIP) and Calling Line Identification Restriction (CLIR). ACR essentially provides the inverse logic of CLIP; while CLIP allows the called party to see the number, ACR allows them to block calls when that number is not presented. Its role is fundamental to user-centric privacy and control in telecommunications, acting as a gatekeeper that enforces the called party's preference to only engage with identifiable callers.

Purpose & Motivation

The primary purpose of ACR is to empower network subscribers with control over their communications and enhance their privacy. Before such services were standardized, users receiving calls from anonymous parties had no network-assisted means to filter them out; they had to answer the call or let it go to voicemaill to determine the caller, potentially leading to harassment, spam, or unwanted telemarketing. ACR solves this by providing an automated, network-enforced barrier. It addresses the social and privacy concerns arising from the very capability of calling line identification restriction (CLIR), which allows callers to withhold their number. While CLIR is a legitimate privacy tool for callers, ACR balances the ecosystem by giving the called party an equivalent right to reject such anonymous interactions.

Historically, the development of ACR in 3GPP Release 7 was part of a broader maturation of supplementary services for GSM and UMTS, extending them into the emerging IMS architecture. It formalized a service that had existed in various proprietary forms in fixed-line networks and early mobile networks. Standardization ensured interoperability across different network operators and equipment vendors, allowing subscribers to reliably use the service even when roaming. It addressed the limitation of purely terminal-based solutions (like phone-side blocklists), which could be bypassed or were not universally available. By being a network-centric service, ACR provides consistent behavior regardless of the user's handset type or capabilities, and the rejection happens before the call rings the terminal, conserving battery and avoiding disturbance.

Classification

Part ofIMS
Related approachesCLIPCLIR

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (119 CRs across 4 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-15 1 change

In Release 15, the Anonymous Communication Rejection (ACR) function was formally introduced alongside Communication Barring (CB) using the IP Multimedia Core Network subsystem. The specification details that ACR takes precedence over various communication diversion and forwarding services like CFU, CFB, and CFNL, causing the communication to be rejected. It also defines interoperability with PSTN/ISDN and clarifies that the service does not apply to UEs accessing from mobile 3GPP access networks.

  • Anonymous Communication Rejection (ACR) and Communication Barring (CB) using IP Multimedia (IM) Core Network (CN) subsystem TS 24.611CR0051
Rel-17 26 changes

In Release 17, the ACR function was enhanced with new capabilities including cancellation support, management event notifications, and explicit preconditions for the Edge Enabler Client (EEC). The release also introduced mechanisms for EEC context relocation during an ACR request and resolved numerous procedural inconsistencies in ACR launching, failure alleviation, and information subscription. Furthermore, corrections were made across various ACR scenarios and its interactions with services like Originating Identification Restriction (OIR) and communication diversion.

  • Corrections for AC and EEC initiated ACR scenario TS 23.558CR0003
  • Corrections to ACR request and response TS 23.558CR0010
  • Adding ACR management event notification TS 23.558CR0017
  • Remove EN on automated ACR service message TS 23.558CR0019
  • Resolving EN about Automated ACR terminology TS 23.558CR0024
  • ACR preconditions for EEC TS 23.558CR0036

+ 20 more changes

Rel-18 72 changes

In Release 18, the ACR function was significantly expanded to support new edge computing and cloud application architectures, including procedures for ACR between Edge Application Servers (EAS) and a Central Application Server (CAS) and enabling ACR with cloud applications. Key enhancements introduced an ACR modification procedure, support for simultaneous EAS connectivity, and the ability to trigger ACR requests on EDGE-5. Furthermore, the release added capabilities for EES-determined ACR scenarios for EAS bundles and defined the API for ACR parameter information.

  • ACR Scenario Combination TS 23.558CR0123
  • Addition of prediction expiration time IE and ACR information procedure TS 23.558CR0126
  • Support simu-EAS connectivity in ACR TS 23.558CR0129
  • ACR request trigger timing TS 23.558CR0130
  • Update ACR scenarios with ACR parameter procedure TS 23.558CR0145
  • ACR scenario selection enhancement TS 23.558CR0190

+ 66 more changes

Rel-19 20 changes

In Release 19, the ACR function was enhanced with new capabilities for edge computing scenarios, including instigating ACR at the Edge Enabler Server (EES) and managing interactions between the Application Client and Edge Enabler Client. The release also introduced refinements such as providing a list of UE IDs in management notifications, supporting prediction expiration time, and adding specific failure causes to improve error handling. Furthermore, corrections and updates were made to ACR parameters, scenario selection, and operations related to simultaneous connectivity and service provisioning.

  • EAS instantiation considering different ACR type TS 23.558CR0593
  • Instigating ACR at the edge enabler server (EES) TS 23.558CR0561
  • AC and EEC interaction for ACR TS 23.558CR0630
  • EAS instantiation in progress indication during ACR TS 23.558CR0647
  • Updates to support the prediction expiration time in ACR scenarios TS 29.558CR0193
  • Out of service area ACR management event TS 29.558CR0211

+ 14 more changes

Explore further

Broader topics and technologies where ACR plays a role.

Defining Specifications

3GPP specifications that define or reference ACR, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 22.173 vk00 IMS Multimedia Telephony Service Definition Rel-20
TS 22.273 v1700 IMS Multimedia Telephony with PSTN/ISDN Simulation Rel-7
TS 22.401 v1800 Videotelephony Service Requirements for NGN Rel-8
TS 22.495 v1700 NGN Requirements for IMS Services Rel-7
TS 23.558 vk00 Architecture for Edge Applications Rel-20
TS 23.700 vk00 XR Services Application Enablement Layer Rel-20
TR 23.758 vh00 Study on Edge Application Architecture Rel-17
TS 24.173 vj00 Multimedia Telephony Service and Supplementary Services in IMS Rel-19
TS 24.196 vj00 Enhanced Calling Name (eCNAM) Stage 3 Protocol Rel-19
TS 24.404 v1700 Communication Diversion Services (CDIV) Rel-7
TS 24.411 v1830 ACR and CB Service Protocol Specification Rel-8
TS 24.416 v1700 Malicious Call Identification Service Rel-7
TS 24.428 v1700 Common Basic Communication Procedures Rel-7
TS 24.429 v1700 Explicit Communication Transfer (ECT) Service Specification Rel-7
TS 24.454 v840 Closed User Group (CUG) Protocol Specification Rel-8
TS 24.504 v8m0 Communication Diversion Services Stage 3 Rel-8
TS 24.516 v830 MCID Protocol Specification for NGN Rel-8
TS 24.528 v830 Common Basic Communication Procedures for IMS Services Rel-8
TS 24.529 v820 Explicit Communication Transfer (ECT) Simulation Service Rel-8
TS 24.543 vj50 SEAL Data Delivery Management Protocol Rel-19
TS 24.558 vj50 Edge Enabler APIs Stage 3 Rel-19
TS 24.604 vj00 Communications Diversion (CDIV) Protocol Spec Rel-19
TS 24.611 vj00 Anonymous Communication Rejection & Barring Rel-19
TS 24.616 vj00 Malicious Call Identification (MCID) Protocol Rel-19
TS 24.628 vj00 Common Basic Communication Procedures in IMS Rel-19
TS 24.629 vj00 Explicit Communication Transfer (ECT) Protocol Rel-19
TS 24.654 vj00 Closed User Group (CUG) supplementary service Rel-19
TS 24.802 vc10 IMS II-NNI Traversal Scenario Determination Study Rel-12
TS 26.077 vj00 AMR Noise Suppression Minimum Performance Requirements Rel-19
TS 26.512 vj10 5G Media Streaming Protocols & APIs Rel-19
TR 26.803 vh00 5G Media Streaming Extensions for Edge Processing Rel-17
TR 26.936 vj00 Audio Codec Characterization Technical Report Rel-19
TR 26.952 vj00 EVS Codec Selection, Verification & Characterization Rel-19
TR 26.953 vj00 Study on Service Interactivity for Streaming & Download Rel-19
TR 26.975 vj00 AMR Speech Codec Performance Background Rel-19
TR 26.976 vj00 AMR-WB Codec Characterization & Verification Rel-19
TR 26.978 vj00 AMR Noise Suppression Selection Phase Technical Report Rel-19
TR 28.815 vh00 Charging Study for Edge Computing Rel-17
TS 29.163 vj00 Interworking between 3GPP IM CN and CS networks Rel-19
TS 29.165 vj10 Inter-IMS Network to Network Interface (NNI) Rel-19
TS 29.292 vj00 IMS Centralized Services (ICS) Interworking Rel-19
TS 29.364 vj10 IMS AS Service Data Descriptions Rel-19
TS 29.558 vj40 Enabling Edge Applications Rel-19
TS 29.864 v801 Application Server Service Data Definition for IMS Telephony Rel-8
TS 32.260 vj10 IMS Charging Management Rel-19
TS 32.272 vj00 Charging for Push-to-Talk over Cellular (PoC) Rel-19
TS 32.273 vj00 MBMS Charging Management Rel-19
TS 32.278 vj00 Monitoring Events Offline Charging Specification Rel-19
TS 32.299 vj00 Diameter Charging Applications for 3GPP Rel-19
TS 32.850 ve00 IMS Charging Correlation Methods Study Rel-14
TS 33.127 vj50 Lawful Interception Architecture and Functions Rel-19
TR 33.739 vi10 Study on security enhancement of support for Rel-18
TR 33.937 vj00 Protection against Unsolicited Communication in IMS Rel-19
TR 45.912 vj00 GERAN Evolution Feasibility Study Rel-19
TS 46.008 vj00 GSM Half Rate Speech Codec Performance Rel-19
TS 46.055 vj00 GSM Enhanced Full Rate Speech Codec Performance Rel-19
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.