SNR

Spending Status Notification Request

Services →
Introduced in Rel-4 Also in: User Equipment, Services, Testing

SNR is a CAMEL protocol element used to trigger notifications about a subscriber's prepaid credit usage, enabling real-time charging control and alerts in mobile networks.

Category
Services
Introduced
Rel-4
Where
Radio Access Network › NG-RAN (5G)
Also touches
3 segments
Specifications
59 specs
SNR Description Purpose Related Classification Detected Changes Specifications

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.

Classification

Part ofCAMEL
Specific typesSINR

Detected Changes Across Releases

from 3GPP Change Requests

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

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

Rel-15 1 change

In Release 15, no new technical introduction for the SNR (Spending Status Notification Request) function is described within the provided grounding context or the listed Change Request titles. The cited CR titles from this release focus on clarifications and corrections to existing parameters, such as the "Max-Requested-Bandwidth," and do not mention SNR procedures, interfaces, or capabilities. Therefore, based solely on the provided materials, Release 15 did not introduce new SNR functionality.

  • Clarification of Max-Requested-Bandwidth TS 29.213CR0721
Rel-16 3 changes

In Release 16, the Spending Status Notification Request (SNR) function was updated with revised range calculations and associated spreadsheets for RRM (Radio Resource Management) and Demodulation testing. These changes were implemented to refine the SNR procedure's test baseline setup and its range length definitions. The updates integrated these new calculation methodologies directly into the relevant test procedures and documentation.

  • List of MCPTT group members who did not acknowledge the group call request TS 24.484CR0134
  • CR to TR 38.810: Implementation of endorsed draft CRs from RAN4#92 - R4-1909983 Update SNR range calculations and spreadsheets for RRM and Demodulation - R4-1910395 Draft CR for TR 38.810: Integrating re-positioning concept into test procedures - R4-1910556 Draft CR for TR 38.810: Update of RRM Baseline Setup R4-1910608 Draft CR to TR 38.810 on DFF range length definition TS 38.810CR0008
  • Missing XLS attachments of SNR range calculators added TS 38.810
Rel-17 3 changes

In Release 17, the enhancements for the SNR function included a correction to enable the retrieval of Network Provided Location information directly within a MESSAGE request. This builds upon the established framework for service requests and their corresponding response messages. The update ensures location data can be integrated as part of the service request indication primitive delivered to the service receiver.

  • The hostname of the MCData notification server(s) configured in the MCData service configuration TS 24.484CR0208
  • Allow-request-affiliated-groups authorization semantics fix TS 24.484CR0203
  • Correction to enable retrieval of Network Provided Location information in a MESSAGE request TS 29.213CR0747
Rel-18 1 change

In Release 18, the new work on SNR (Spending Status Notification Request) was not detailed in the provided grounding context or CR titles. The only related CR title mentions a technical update for FR2-2 maximum downlink testable SNR, which pertains to radio frequency testing parameters rather than the service notification function itself. Therefore, based solely on the provided materials, no specific new features or procedures for the SNR function compared to the previous release can be described.

  • CR on TR 38.884 for FR2-2 maximum DL testable SNR TS 38.884CR0002
Rel-19 1 change

In Release 19, the new functionality for the Spending Status Notification Request (SNR) function introduced an emergency remote floor request authorization configuration. This addition provides a mechanism for authorized entities to request control over a communication session during critical situations. The configuration defines the procedures for this authorized emergency request within the service framework.

  • Emergency remote floor request authorization configuration TS 24.484CR0287

Explore further

Broader topics and technologies where SNR plays a role.

Defining Specifications

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

SpecificationTitleRelease
TR 21.905 vj00 3GPP Technical Terms and Definitions Rel-19
TS 24.229 vj50 IMS call control protocol based on SIP and SDP Rel-19
TS 24.484 vj30 MCS Configuration Management Rel-19
TS 25.212 vj00 UTRA FDD Layer 1 Multiplexing & Channel Coding Rel-19
TS 25.222 vj00 UTRA TDD Multiplexing & Channel Coding Rel-19
TS 26.094 vj00 AMR Voice Activity Detector (VAD) Specification Rel-19
TS 26.881 vf00 MBMS FEC for Mission Critical Services Study Rel-15
TR 26.918 vj00 Virtual Reality Relevance Study for 3GPP Rel-19
TR 26.933 vj00 Study on Diverse Audio Capturing System Rel-19
TR 26.943 vj00 SES Codec Selection Report Rel-19
TR 26.952 vj00 EVS Codec Selection, Verification & Characterization 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 26.997 vj00 IVAS Codec Specification Rel-19
TS 29.213 vj20 PCC Signalling Flows and QoS Mapping Rel-19
TS 29.219 vj00 Sy Reference Point Stage 3 Specification Rel-19
TS 36.101 vj30 LTE UE Radio Transmission & Reception Requirements Rel-19
TS 36.104 vj10 Base Station (BS) radio transmission and reception Rel-19
TS 36.116 vj00 E-UTRA Relay RF Requirements Rel-19
TS 36.117 vj00 E-UTRA Relay RF Test Methods & Requirements Rel-19
TS 36.141 vj00 E-UTRA BS Conformance Testing Rel-19
TS 36.747 ve00 Enhanced CRS and SU-MIMO IM Performance Requirements Rel-14
TR 36.763 vh00 NB-IoT/eMTC Support for Non-Terrestrial Networks Rel-17
TS 36.867 vd00 LTE DL 4 Rx Antenna Port Study TR Rel-13
TS 37.104 vj10 MSR Base Station RF Characteristics Rel-19
TS 37.141 vj10 RF Test Methods for Multi-Standard Radio Base Stations Rel-19
TS 37.145 vj10 AAS Base Station Conducted Conformance Testing Rel-19
TS 37.320 vj00 Minimization of Drive Tests (MDT) Overview Rel-19
TS 37.802 va10 MSR BS RF Requirements for Non-Contiguous Spectrum Rel-10
TS 37.812 vb30 Multi-band Multi-standard Radio BS Requirements Rel-11
TR 37.900 vj00 Multi-Standard Radio (MSR) Base Station Requirements Rel-19
TR 37.901 vf10 UE Application Layer Data Throughput Performance Rel-15
TR 37.976 vj00 MIMO OTA Test Methodology Study Rel-19
TR 37.977 vj00 MIMO OTA Test Methodology Rel-19
TS 38.101 vj31 NR User Equipment Radio Transmissions Rel-19
TS 38.521 vj20 NR Physical Layer UE Conformance Testing Rel-19
TS 38.551 vi30 User Equipment (UE) Multiple Input Multiple Output (MIMO) Over-the-Air (OTA) performance Rel-18
TS 38.741 vj00 NTN L-/S-band for NR Technical Specification Rel-19
TS 38.774 vj00 Rel-19 LP-WUS/WUR RF Requirements TR Rel-19
TR 38.785 vh00 UE radio transmission for enhanced NR sidelink Rel-17
TR 38.786 vi20 Technical Report for NR Sidelink Evolution Rel-18
TS 38.787 vj00 UE Radio Transmission for Sidelink CA in ITS Band Rel-19
TR 38.810 vg70 NR OTA Test Methods Study Rel-16
TS 38.811 vf40 Study on NR Support for Non-Terrestrial Networks Rel-15
TR 38.812 vg00 Study on NOMA for NR Rel-16
TS 38.817 3GPP TR 38.817 Rel-4
TS 38.821 vg20 NR Support for Non-Terrestrial Networks Rel-16
TS 38.831 vg10 UE RF Requirements for FR2 Enhancements Rel-16
TS 38.863 vj10 NR NTN RF and Co-existence Spec Rel-19
TR 38.868 vh00 Optimizations of pi/2 BPSK uplink power in NR Rel-17
TR 38.869 vi00 Study on low-power wake up signal and receiver for NR Rel-18
TR 38.871 vi20 Technical Report Rel-18
TR 38.878 vi40 Technical Report on Advanced Receiver for MU-MIMO Rel-18
TR 38.884 vi20 Technical Report Rel-18
TR 38.886 vg30 NR V2X UE Radio Transmission & Reception Rel-16
TR 38.903 vj00 Test Tolerances & Measurement Uncertainties Rel-19
TR 45.914 vj00 MUROS Feasibility Study for Voice Capacity Rel-19
TS 46.008 vj00 GSM Half Rate Speech Codec Performance Rel-19