Event Detection Point - Notification

Description

Event Detection Point - Notification (EDP-N) is a specific subtype of Event Detection Point introduced to refine the service control model, particularly within CAMEL and IMS. Unlike an EDP-R (Request), an EDP-N represents a detection point configured for notification only. When the call or session state reaches an EDP-N, the Service Switching Function (SSF) – embodied in an MSC for circuit-switched calls or an S-CSCF for IMS sessions – sends a report to the designated Service Control Function (SCF) or Application Server (AS). The key distinction is that this reporting is a one-way communication; the SSF does not suspend call processing to wait for instructions. After sending the notification, it immediately continues with the normal call/session progression as per the basic call state model.

The primary architectural role of EDP-N is to enable observation and information reporting without direct intervention. The notification message contains relevant event data (e.g., the fact that a call was answered, a specific DTMF digit was received, or a session timer expired). The SCF/AS receives this information and can use it for purposes such as incremental charging, event logging, statistical analysis, or triggering other non-call-affecting processes. This mechanism is crucial for services that require awareness of call events but do not need to alter the call path in real-time. For example, in a postpaid or flat-rate service, the network may still need to log call answer events for billing records without needing to interrupt the call.

In the protocol interaction between the SSF and SCF (e.g., using CAP – CAMEL Application Part), the EDP-N is invoked, and a specific report message is sent. The SCF acknowledges receipt, but no further command related to call control is expected or acted upon by the SSF. This makes EDP-Ns less intrusive and lower latency from a call-processing perspective compared to EDP-Rs. They are defined for various points in the call model, often for events that are informational milestones rather than decision points. The configuration of whether a detection point is armed as an EDP-N or EDP-R is part of the service logic profile provided to the SSF at the start of service control.

Purpose & Motivation

EDP-N was introduced to address a specific need within the Intelligent Network and IMS service control paradigm: the requirement for passive monitoring and event reporting without the overhead and potential latency of a full request-response interaction. In early CAMEL phases, the model primarily focused on EDP-Rs, where the switch would suspend processing and wait for instructions. While powerful, this model introduced processing delay and complexity for scenarios where the service logic only needed to be informed of an event, not to control it.

The creation of EDP-N solved this by providing a lightweight notification mechanism. It allowed for more efficient implementation of services like detailed call logging, event-based charging updates (where billing is recorded but not rate-limited in real-time), lawful interception triggers, and service usage analytics. By not suspending call processing, EDP-Ns reduce the load on the SCF/AS for non-critical interactions and improve overall call setup times for services that only require monitoring. It represented an evolution towards a more granular and efficient service control interface, recognizing that not all service interactions require bi-directional control. This refinement was particularly important as networks scaled and service logic became more complex, requiring a clear separation between control-influencing and observation-only interactions.

Key Features

• Provides one-way notification from SSF (MSC, CSCF) to SCF/AS without suspending call processing
• Used for monitoring, logging, non-real-time charging, and statistical data collection
• Reduces call setup latency compared to EDP-R interactions
• Carries event-specific data (e.g., answer time, detected DTMF digit) to the service logic
• Defined for informational milestones in the call/session state model
• Part of the CAMEL and IMS service control architecture, specified in CAP and Diameter/SIP protocols

Evolution Across Releases

Defining Specifications