OCI

Overload Control Information

Core Network
Introduced in Rel-6
Overload Control Information (OCI) is a signaling mechanism used in IMS and 5G core networks to prevent server overload. It allows a network function (NF) to signal its load level to other NFs, enabling them to throttle or redirect requests. This is critical for maintaining network stability and service availability during traffic surges or failure scenarios.

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.

Key Features

  • In-band signaling of load conditions within standard protocol messages (SIP, HTTP/2)
  • Supports both hard throttling (retry-after timer) and probabilistic traffic reduction
  • Allows overloaded nodes to control the rate of incoming requests from peers
  • Includes validity periods to ensure control information is time-bound
  • Enables priority handling, allowing critical requests to bypass throttling
  • Integral part of 3GPP-defined overload control procedures for IMS and 5GC

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.

Defining Specifications

SpecificationTitle
TS 21.905 3GPP TS 21.905
TS 29.122 3GPP TS 29.122
TS 29.500 3GPP TS 29.500
TS 29.843 3GPP TS 29.843
TS 31.102 3GPP TR 31.102