CCNR

Completion of Communication sessions on No Reply

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

CCNR is a supplementary service that automatically completes a communication session for the caller when a called party who was busy or did not answer becomes available.

Category
Services
Introduced
Rel-8
Where
Services › IMS
Also touches
1 segments
Specifications
10 specs
CCNR Description Purpose Related Classification Detected Changes Specifications

Description

Completion of Communication sessions on No Reply (CCNR) is a standardized supplementary service within 3GPP networks that provides automatic call completion functionality when initial call attempts fail due to the called party being busy or not answering. The service operates through a network-based queuing mechanism where the calling party's request is stored and monitored until the called subscriber becomes available for communication. When activated, CCNR intercepts failed call attempts and places them in a waiting state rather than terminating the connection immediately.

Architecturally, CCNR is implemented within the core network elements, primarily involving the Home Subscriber Server (HSS) for subscriber data management and the Mobile Switching Center (MSC) or IP Multimedia Subsystem (IMS) nodes for call processing. The service relies on specific signaling procedures defined in 3GPP specifications to establish, maintain, and terminate the completion request. When a user activates CCNR for a failed call, the network creates a completion record containing the calling and called party identities, timestamp, and service parameters. This record is stored in the appropriate network element based on the called party's registration status and network configuration.

The service operates through a monitoring mechanism that tracks the called party's availability status. When the called subscriber transitions from busy or unavailable to idle and registered, the network detects this state change and initiates the completion procedure. The network then attempts to establish the communication session automatically, notifying both parties through specific tones or indications. The implementation includes timers and counters to prevent indefinite queuing, with configurable expiration periods and maximum retry attempts. CCNR integrates with other supplementary services like call forwarding and call barring, with defined precedence rules to avoid conflicts between different services.

Key technical components include the CCNR activation/deactivation procedures, completion request storage and management, availability monitoring mechanisms, and automatic call establishment protocols. The service supports both voice and multimedia sessions in IMS environments, with specific adaptations for different session types. Security measures ensure that only authorized users can activate the service and that completion attempts follow proper authentication procedures. CCNR's implementation varies between circuit-switched and packet-switched domains, with IMS-based implementations offering enhanced flexibility and integration with other multimedia services.

Purpose & Motivation

CCNR was developed to address the common problem of failed communication attempts in mobile networks, particularly when users encounter busy signals or no answer situations. Before CCNR, callers had to repeatedly attempt connections manually, which was inefficient and frustrating. The service automates this process, allowing users to request automatic completion once the called party becomes available, thereby improving communication success rates and user convenience.

Historically, similar services existed in fixed-line networks (often called 'call completion to busy subscriber' or CCBS), but 3GPP standardized CCNR specifically for mobile environments where subscriber mobility and registration states added complexity. The service addresses limitations of basic call handling where failed attempts simply terminated without recourse. By introducing network-managed completion queues, CCNR reduces missed connections and improves overall network utilization by ensuring communication attempts eventually succeed when conditions permit.

The creation of CCNR was motivated by the need to enhance basic telephony services in mobile networks to match or exceed fixed-line capabilities. It solves the problem of inefficient manual retry attempts and improves customer satisfaction by ensuring important communications aren't missed due to temporary unavailability. In business contexts, CCNR ensures critical calls are completed without requiring constant monitoring by the calling party, making it particularly valuable for time-sensitive communications.

Classification

Part ofIMS
Related approachesCCBS

Detected Changes Across Releases

from 3GPP Change Requests

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

Studied in Rel-8, normative work from Rel-15.

Rel-15 1 change

In Release 15, the CCNR (Completion of Communications by No Reply) function was newly introduced for the IMS core network, enabling automated call completion when a called party does not answer. Specifically, the IMS Application Server (AS) starts a no-reply timer upon receiving a 180 (Ringing) response and, upon timer expiry or reception of a 487 (Request Terminated) response, releases the session and associated data channel media resources. This release also defined the parallel procedures for CCBS and introduced the necessary protocol specifications for these supplementary services within the IP Multimedia Subsystem.

  • Completion of Communications to Busy Subscriber (CCBS) and Completion of Communications by No Reply (CCNR) using IP Multimedia (IM) Core Network (CN) subsystem TS 24.642CR0088
Rel-17 1 change

In Release 17, the CCNR function was enhanced to support IMS data channel sessions. Specifically, the IMS Application Server procedures were updated so that upon receiving a 180 (Ringing) response, it notifies the DCSF and updates the reserved data channel media resources, and upon CCNR activation with a 487 (Request Terminated) response, it releases those data channel resources along with the session.

  • Support for signed attestation for emergency and priority IMS sessions TS 29.165CR1029
Rel-18 1 change

In Release 18, the new feature for the CCNR function was the support for IMS data channel media sessions. Specifically, upon receiving a 180 (Ringing) response, the IMS AS now notifies the DCSF and updates the data channel media resources, and upon receiving a 487 (Request Terminated) response, it releases those data channel resources along with the session. This enhancement integrates CCNR with the IMS data channel capability defined for the MMTel service.

  • MPS for CCBS supplementary service TS 24.642CR0090
Rel-19 8 changes

In Release 19, the key enhancement for CCNR was its integration with Standalone IMS Data Channel sessions, requiring updates to both UE and IMS AS procedures. Specifically, upon receiving a 180 (Ringing) response, the IMS AS now notifies the DCSF and updates the data channel media resources for the waiting communication. Furthermore, upon CCNR activation triggered by a 487 (Request Terminated) response, the IMS AS releases these reserved data channel media resources as part of the session release.

  • Procedure of avatar communication TS 24.186CR0054
  • Update on the avatar communication TS 24.186CR0080
  • Remove a EN of avatar communication TS 24.186CR0064
  • IMS AS procedures for Standalone IMS DC sessions TS 24.186CR0101
  • Update in UE procedures for Standalone IMS DC sessions TS 24.186CR0102
  • Update on avatar communication TS 24.186CR0104

+ 2 more changes

Explore further

Broader topics and technologies where CCNR plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 24.186 vj60 IMS Data Channel applications Rel-19
TS 24.292 vj00 IMS Centralized Services (ICS) Protocol Rel-19
TS 24.642 vj00 CCBS/CCNR/CCNL SIP Protocol Specification Rel-19
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.864 v801 Application Server Service Data Definition for IMS Telephony Rel-8
TS 32.275 vj00 MMTel Charging Specification Rel-19
TS 32.850 ve00 IMS Charging Correlation Methods Study Rel-14