Description
The Spending Status Notification Request, abbreviated as SN-Request, is a specific operation within the CAMEL (Customised Applications for Mobile network Enhanced Logic) protocol suite, which is a 3GPP standard for intelligent network (IN) services in GSM, UMTS, and later networks. CAMEL allows network operators to deploy custom services like prepaid charging, number translation, and call screening. The SN-Request is a message sent from the network's Service Control Point (SCP) – which hosts the prepaid service logic – to the Service Switching Point (SSP), typically the Mobile Switching Center (MSC) or Gateway MSC. Its purpose is to instruct the SSP to monitor a subscriber's call or session and send a notification back to the SCP when the subscriber's account balance reaches certain predefined thresholds during the communication.
How it works is integral to real-time prepaid charging. When a prepaid subscriber initiates a call, the MSC/SSP detects the CAMEL-triggered call and suspends call processing. It sends an InitialDP message to the SCP. The SCP, after checking the subscriber's balance and rating the call, authorizes the call for an initial duration. Crucially, the SCP can include an SN-Request in its response (e.g., in a RequestReportBCSMEvent or ApplyCharging operation). This request contains parameters like the spending limit thresholds (e.g., notify when 50% of the allocated credit is used, and again at 80%). As the call progresses, the MSC/SSP monitors the call duration or data volume. When a specified threshold is crossed, the SSP sends a notification (an EventReportBCSM or ApplyChargingReport) back to the SCP.
Upon receiving the notification, the SCP can then take further action. This typically involves re-checking the subscriber's balance, calculating a new credit allocation for the next segment of the call, and sending a new authorization to the SSP to continue the call. This process of periodic notification and re-authorization continues until the call ends or the credit is exhausted. The SN-Request mechanism is key to implementing features like low-balance warnings, where the network can play an announcement to the subscriber, or graceful call termination when funds run out. It ensures that prepaid charging is accurate, real-time, and allows for interactive subscriber notifications.
Purpose & Motivation
The SN-Request was developed to address the fundamental challenge of real-time control and notification in prepaid telephony services. Before CAMEL and mechanisms like SN-Request, prepaid services were often implemented through less efficient means, such as call gapping or simple duration limits without granular control. These methods could lead to subscriber dissatisfaction due to abrupt call termination without warning or inaccurate charging. The SN-Request provides a standardized, in-call signaling mechanism for the charging system (SCP) to stay informed of resource consumption.
It solves the problem of proactive account management during an active session. Without it, the SCP would only know the total cost at the end of the call, risking overspending. With SN-Request, the SCP can monitor spending incrementally, allowing for: 1) **Precise credit control**: Allocating credit in chunks prevents subscribers from exceeding their balance. 2) **Enhanced user experience**: Enabling low-balance announcements gives subscribers a chance to top up or end the call gracefully. 3) **Flexible service logic**: Operators can define multiple thresholds for different notification types or actions. Its creation was motivated by the massive growth of prepaid mobile subscriptions, which demanded robust, scalable, and feature-rich charging systems that could operate across different network elements and vendors, which CAMEL and its detailed operations like SN-Request provided.
Key Features
- A CAMEL operation used for real-time prepaid charging control
- Instructs the MSC/SSP to report when a subscriber's resource usage hits predefined thresholds
- Enables periodic re-authorization of calls or sessions based on remaining credit
- Supports subscriber notifications like low-balance warnings via in-call announcements
- Works in conjunction with CAMEL phases and other operations like ApplyCharging
- Applicable to voice calls, SMS, and data sessions in GSM, UMTS, and evolved packet core contexts
Evolution Across Releases
The Spending Status Notification Request (SN-Request) was introduced in CAMEL Phase 3 (Release 4). This initial inclusion defined the operation within the CAMEL Application Part (CAP) protocol, enabling basic notification mechanisms for spending limits during calls, forming the core of enhanced prepaid service control.
Defining Specifications
| Specification | Title |
|---|---|
| TS 21.905 | 3GPP TS 21.905 |
| TS 24.229 | 3GPP TS 24.229 |
| TS 24.484 | 3GPP TS 24.484 |
| TS 25.212 | 3GPP TS 25.212 |
| TS 25.222 | 3GPP TS 25.222 |
| TS 26.094 | 3GPP TS 26.094 |
| TS 26.881 | 3GPP TS 26.881 |
| TS 26.918 | 3GPP TS 26.918 |
| TS 26.933 | 3GPP TS 26.933 |
| TS 26.943 | 3GPP TS 26.943 |
| TS 26.952 | 3GPP TS 26.952 |
| TS 26.975 | 3GPP TS 26.975 |
| TS 26.976 | 3GPP TS 26.976 |
| TS 26.978 | 3GPP TS 26.978 |
| TS 26.997 | 3GPP TS 26.997 |
| TS 29.213 | 3GPP TS 29.213 |
| TS 29.219 | 3GPP TS 29.219 |
| TS 36.101 | 3GPP TR 36.101 |
| TS 36.104 | 3GPP TR 36.104 |
| TS 36.116 | 3GPP TR 36.116 |
| TS 36.117 | 3GPP TR 36.117 |
| TS 36.141 | 3GPP TR 36.141 |
| TS 36.747 | 3GPP TR 36.747 |
| TS 36.763 | 3GPP TR 36.763 |
| TS 36.867 | 3GPP TR 36.867 |
| TS 37.104 | 3GPP TR 37.104 |
| TS 37.141 | 3GPP TR 37.141 |
| TS 37.145 | 3GPP TR 37.145 |
| TS 37.320 | 3GPP TR 37.320 |
| TS 37.802 | 3GPP TR 37.802 |
| TS 37.812 | 3GPP TR 37.812 |
| TS 37.900 | 3GPP TR 37.900 |
| TS 37.901 | 3GPP TR 37.901 |
| TS 37.976 | 3GPP TR 37.976 |
| TS 37.977 | 3GPP TR 37.977 |
| TS 38.101 | 3GPP TR 38.101 |
| TS 38.521 | 3GPP TR 38.521 |
| TS 38.551 | 3GPP TR 38.551 |
| TS 38.741 | 3GPP TR 38.741 |
| TS 38.774 | 3GPP TR 38.774 |
| TS 38.785 | 3GPP TR 38.785 |
| TS 38.786 | 3GPP TR 38.786 |
| TS 38.787 | 3GPP TR 38.787 |
| TS 38.810 | 3GPP TR 38.810 |
| TS 38.811 | 3GPP TR 38.811 |
| TS 38.812 | 3GPP TR 38.812 |
| TS 38.817 | 3GPP TR 38.817 |
| TS 38.821 | 3GPP TR 38.821 |
| TS 38.831 | 3GPP TR 38.831 |
| TS 38.863 | 3GPP TR 38.863 |
| TS 38.868 | 3GPP TR 38.868 |
| TS 38.869 | 3GPP TR 38.869 |
| TS 38.871 | 3GPP TR 38.871 |
| TS 38.878 | 3GPP TR 38.878 |
| TS 38.884 | 3GPP TR 38.884 |
| TS 38.886 | 3GPP TR 38.886 |
| TS 38.903 | 3GPP TR 38.903 |
| TS 45.914 | 3GPP TR 45.914 |
| TS 46.008 | 3GPP TR 46.008 |