Description
Overload Control Information (OCI) is a protocol-level mechanism designed to manage and mitigate overload conditions within the IP Multimedia Subsystem (IMS) and the 5G Service-Based Architecture (SBA). It operates by allowing a network function that is experiencing high load (the overloaded entity) to inform its peer functions (the clients) about its current capacity status. This information is typically embedded within protocol responses, such as SIP responses in IMS (e.g., 503 Service Unavailable) or within HTTP/2 messages in the 5G core (e.g., Nudm_UEContextManagement response). The OCI contains parameters that instruct the client on how to adjust its request traffic. Key parameters include a 'retry-after' value, which specifies a duration during which the client should refrain from sending new requests, and potentially more granular controls like a probability factor, where the client is instructed to discard a certain percentage of new requests before sending them. In 5G SBA, OCI is formalized as part of the overload control procedures in TS 29.500. A consumer NF (client) sending a service request to a producer NF (server) includes its own overload control preferences in the request. If the producer is overloaded, it can respond with OCI that includes a 'load control information' element, dictating a reduction factor and a validity period. The consumer NF must then apply this reduction to its request rate towards that producer. The mechanism is dynamic and stateful, allowing load to be managed in real-time. It works in conjunction with other resilience features like load balancing and stateless design to ensure that a single point of overload does not cascade into a wider network failure.
Purpose & Motivation
OCI was created to address the critical problem of signaling overload in all-IP core networks, which became prominent with the deployment of IMS for multimedia services. Traditional telephony switches had hardware-based overload controls, but software-based, IP-connected NFs are susceptible to being overwhelmed by signaling storms—sudden surges in traffic that can be caused by mass call events, network failures, or malicious attacks. Without a standardized overload control mechanism, an overloaded server might crash, drop connections indiscriminately, or become unresponsive, leading to a cascading failure that affects service across the network. OCI provides a graceful and cooperative way to handle such conditions. It allows an overloaded NF to proactively protect itself by instructing its peers to reduce their request load, rather than simply rejecting requests, which can cause clients to retry aggressively and exacerbate the problem. Its introduction in Release 6 for IMS and later refinement for the 5G SBA was motivated by the need for robust, scalable, and self-regulating networks that can maintain service continuity for priority users (e.g., emergency calls) even under extreme load, fulfilling regulatory and reliability requirements.
Classification
Evolution Across Releases
Introduced Overload Control for the IMS core, primarily defined for the SIP protocol. Specified the use of parameters like 'retry-after' in SIP 5xx responses to inform upstream proxies (I-CSCF, S-CSCF) and User Agents to reduce traffic. Focused on protecting core IMS nodes like CSCFs from signaling overload.
Explore further
Broader topics and technologies where OCI plays a role.
Defining Specifications
3GPP specifications that define or reference OCI, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TR 21.905 vj00 | 3GPP Technical Terms and Definitions | Rel-19 |
| TS 29.122 vj40 | T8 Reference Point for Northbound APIs | Rel-19 |
| TS 29.500 vj50 | 5GC Service Based Architecture Specification | Rel-19 |
| TR 29.843 vg00 | 5GC Load and Overload Control Study | Rel-16 |
| TS 31.102 vj40 | USIM Application Specification | Rel-19 |