OCI

Overload Control Information

Core Network →
Introduced in Rel-6

OCI is a signaling mechanism used in IMS and 5G core networks that allows a network function to signal its load level to others, enabling request throttling or redirection to prevent server overload.

Category
Core Network
Introduced
Rel-6
Where
Core Network › 5G Core
Specifications
5 specs
OCI Description Purpose Related Classification Specifications

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

Part ofIMS
Related approachesSIP

Evolution Across Releases

Rel-6 Initial

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.

SpecificationTitleRelease
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
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.