Description
The Spending-Limit-Answer (SLA) is a critical component of the 3GPP Online Charging System (OCS) architecture, operating within the Diameter-based Ro/Rf reference points. It is a direct response to the Spending-Limit-Request (SLR) message initiated by a network function like a Gateway GPRS Support Node (GGSN), Packet Data Network Gateway (PGW), or Session Management Function (SMF). The SLA carries the decision from the OCS regarding the amount of service units (e.g., data volume, time duration, monetary credit) a subscriber is permitted to consume. The message contains key Attribute-Value Pairs (AVPs) such as the Granted-Service-Unit AVP, which specifies the precise quota (e.g., 10 MB of data). It may also include the Validity-Time AVP, defining how long the quota is valid, and the Final-Unit-Indication AVP, which signals that the granted quota is the final one before service termination or redirection.
Architecturally, the SLA is part of the Diameter Credit-Control Application (DCCA) as defined in IETF RFC 4006, which 3GPP has adopted and extended. The OCS, upon receiving an SLR, performs subscriber balance checks, applies tariff rates, and potentially consults policy rules before formulating the SLA. The process is stateful, with the OCS maintaining a session context for each active credit-control session. The SLA is transported reliably over the Diameter protocol, ensuring the charging client in the network receives the authorization decision.
Its role is fundamental to real-time, event-based charging for data, voice, SMS, and IMS services. By providing a dynamic and immediate spending limit, the SLA enables prepaid services, spending-limit controls for postpaid accounts, and seamless service continuation through quota renewal cycles. The integrity and timeliness of the SLA are paramount for accurate revenue assurance and for providing subscribers with transparent, up-to-date information on their credit consumption.
Purpose & Motivation
The Spending-Limit-Answer exists to facilitate real-time credit authorization in telecommunications networks, a necessity for prepaid services and spending control. Prior to online charging, operators relied heavily on offline charging (post-event billing), which carried the risk of bad debt from subscribers exceeding their credit. The SLA, as part of the OCS framework, solves this by providing an immediate 'yes/no' and 'how much' decision before network resources are committed.
Its creation was motivated by the commercial need to offer innovative prepaid plans for emerging packet-switched services like GPRS and, later, 3G/4G/5G data. The traditional call-detail-record (CDR) based approach had too much latency between usage and billing, making it unsuitable for controlling data sessions that could consume large value quickly. The SLA mechanism allows operators to offer flexible, real-time tariffs and protect their revenue by enforcing hard limits on consumption.
Historically, its introduction in R99 coincided with the standardization of the CAMEL-based and later Diameter-based OCS. It addressed the limitation of passive billing by creating an interactive dialogue between the network and the charging system, transforming charging from a mere recording function into an active policy enforcement point for monetization.
Key Features
- Carries the Granted-Service-Unit (data, time, money) from the OCS to the network element
- Supports quota validity timers to control the lifetime of an authorization
- Includes Final-Unit-Indication to trigger service termination or redirection upon quota exhaustion
- Transported via the reliable Diameter protocol over the Ro/Rf reference points
- Integral part of the stateful Diameter Credit-Control Application (DCCA) session
- Enables multiple quota types (e.g., volume, time, event) within a single answer
Evolution Across Releases
Introduced as part of the initial Online Charging System (OCS) framework. The initial architecture defined the Spending-Limit-Request/Answer dialogue over the CAP (CAMEL Application Part) interface for circuit-switched services and early GPRS support, establishing the fundamental concept of real-time quota authorization.
Defining Specifications
| Specification | Title |
|---|---|
| TS 21.905 | 3GPP TS 21.905 |
| TS 22.495 | 3GPP TS 22.495 |
| TS 22.519 | 3GPP TS 22.519 |
| TS 22.980 | 3GPP TS 22.980 |
| TS 23.107 | 3GPP TS 23.107 |
| TS 23.207 | 3GPP TS 23.207 |
| TS 23.435 | 3GPP TS 23.435 |
| TS 23.700 | 3GPP TS 23.700 |
| TS 23.758 | 3GPP TS 23.758 |
| TS 24.525 | 3GPP TS 24.525 |
| TS 26.501 | 3GPP TS 26.501 |
| TS 26.804 | 3GPP TS 26.804 |
| TS 26.891 | 3GPP TS 26.891 |
| TS 26.942 | 3GPP TS 26.942 |
| TS 28.530 | 3GPP TS 28.530 |
| TS 28.535 | 3GPP TS 28.535 |
| TS 28.536 | 3GPP TS 28.536 |
| TS 28.805 | 3GPP TS 28.805 |
| TS 29.116 | 3GPP TS 29.116 |
| TS 29.199 | 3GPP TS 29.199 |
| TS 29.213 | 3GPP TS 29.213 |
| TS 29.219 | 3GPP TS 29.219 |
| TS 29.949 | 3GPP TS 29.949 |
| TS 32.101 | 3GPP TR 32.101 |
| TS 32.102 | 3GPP TR 32.102 |
| TS 32.141 | 3GPP TR 32.141 |
| TS 32.410 | 3GPP TR 32.410 |
| TS 32.854 | 3GPP TR 32.854 |
| TS 38.300 | 3GPP TR 38.300 |
| TS 38.828 | 3GPP TR 38.828 |
| TS 38.900 | 3GPP TR 38.900 |
| TS 38.901 | 3GPP TR 38.901 |