IOPS

Isolated E-UTRAN Operations for Public Safety

Services →
Introduced in Rel-13 Also in: Security, Core Network

IOPS is a 3GPP feature enabling LTE base stations to operate independently from the core network during emergencies, providing critical local communication for public safety personnel when the wider network is unavailable.

Category
Services
Introduced
Rel-13
Where
Services
Also touches
2 segments
Specifications
15 specs
IOPS Description Purpose Related Classification Detected Changes Specifications

Description

Isolated E-UTRAN Operations for Public Safety (IOPS) is a specialized operational mode defined in 3GPP specifications that allows a cluster of LTE radio access network (E-UTRAN) nodes, specifically evolved NodeBs (eNBs), to provide local communication services without a connection to the Evolved Packet Core (EPC) or 5G Core (5GC). In this mode, the eNBs form a self-contained network, managing radio resources, mobility, and basic session management autonomously. The architecture for IOPS involves one eNB acting as an Anchor eNB, which assumes control plane functions typically handled by the core network, such as mobility management and bearer context storage. Other eNBs in the cluster operate as Assisting eNBs, connecting to the Anchor eNB via the X2 interface.

How IOPS works begins with a trigger, such as a loss of backhaul connection to the EPC or a manual command. Eligible eNBs (pre-configured for IOPS) enter the isolated state. The Anchor eNB establishes itself, often through a pre-defined priority mechanism, and begins broadcasting system information indicating IOPS operation. Public Safety User Equipment (PS UE), which is specially configured to support IOPS, can then attach to this isolated network. The Anchor eNB performs a localized version of attachment and authentication, potentially using pre-stored credentials or a local authentication server if available. It manages the radio bearers for voice, video, and data services within the limited geographical coverage of the eNB cluster.

Key components include the IOPS-capable eNB (with enhanced software), IOPS-capable PS UE, and potentially a local application server (e.g., for Group Communication System Enablers). The X2 interface between eNBs is crucial for supporting mobility (handovers) within the isolated cluster. The system supports essential public safety services like mission-critical push-to-talk (MCPTT), location services, and emergency alerting. All communication is confined to the local radio coverage area; there is no connectivity to the public internet or other external networks unless a gateway function is locally implemented.

IOPS's role is to provide a lifeline communication network when the infrastructure is compromised due to natural disasters, terrorist attacks, or technical failures. It ensures that first responders can continue to coordinate using high-speed LTE-based services even in the absence of network infrastructure. Specifications such as TS 23.401 (GPRS enhancements for E-UTRAN access) and TS 33.401 (3GPP system architecture security) define the procedures and security mechanisms for IOPS, including how to securely transition UEs into and out of the isolated mode and how to protect the local communications.

Purpose & Motivation

IOPS was created to address a critical vulnerability in early LTE networks for public safety: complete dependence on the core network and transport backhaul. Traditional cellular networks are centralized; if the core network sites or the links to them fail, the entire radio access network becomes inoperative. This is unacceptable for mission-critical public safety communications, where reliability is paramount during crises that often damage infrastructure. Prior to IOPS, public safety agencies relied on dedicated land mobile radio (LMR) systems for local resilience, but these lacked the high-speed data capabilities of LTE.

The motivation for standardizing IOPS within 3GPP was to enable LTE to become a true broadband replacement for legacy LMR systems, but without sacrificing resilience. It solves the problem of "single point of failure" inherent in the centralized EPC architecture. By allowing eNBs to operate autonomously, IOPS ensures that communication can be maintained among first responders at a disaster site even if the nearest core network node is destroyed or isolated. This capability was a key requirement from public safety organizations worldwide as they planned their transition to 3GPP-based broadband networks.

Historically, the feature was driven by requirements from entities like the First Responder Network Authority (FirstNet) in the USA and other national public safety bodies. Its development in Release 13 was part of a broader 3GPP effort on Mission Critical services. IOPS addresses the limitations of previous commercial cellular technology, which was designed for efficiency and scalability in stable conditions, not for survivability in extreme scenarios. It enables a hybrid model where public safety networks can benefit from wide-area commercial-grade LTE services normally, but seamlessly fall back to resilient, localized operation when needed, all on the same network infrastructure and devices.

Classification

Part ofMCPTT

Detected Changes Across Releases

from 3GPP Change Requests

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

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

Rel-15 1 change

In Release 15, the IOPS function was enhanced to ensure robust public safety communications by formally integrating support for ProSe UE-to-UE Relay functionality, enabling direct device connections between remote Public Safety UEs via one or more relay hops. This allows for continued operation in coverage, out-of-coverage, or partial coverage scenarios. The release also reinforced the framework for non-public networks and private slices, which underpin isolated operations like IOPS, by defining requirements for their flexible deployment and management.

  • Correction of non-3GPP to E-UTRAN handovers TS 23.401CR3418
Rel-16 6 changes

In Release 16, the IOPS function was updated by replacing the term "private network" with the standardized concept of a "non-public network" intended for exclusive use, aligning with broader 5G terminology. Furthermore, enhancements were made to support dedicated bearers for Ethernet traffic within the EPC architecture, specifically addressing aspects for IOPS, LIPA, and SIPTO@LN to improve service delivery for isolated operations.

  • Dedicated Bearers for Ethernet in EPC - IOPS / LIPA / SIPTO@LN aspects TS 23.401CR3508
  • Replacing private network with non-public network TS 22.261CR0315
  • UTRAN and manufacturer assigned UE Radio Capability ID TS 23.401CR3623
  • MCC Editorial update for publication after TSG SA approval (SA#84) TS 23.778
  • Definition of the coding of the Home Network Public Key in EFSUCI_CALC_INFO TS 31.102CR0860
  • Definition of the coding of the Home Network Public Key in EFSUCI_CALC_INFO TS 31.102CR0871
Rel-17 2 changes

In Release 17, the IOPS function was enhanced to include operation with a "Satellite E-UTRAN in PLMN selector," allowing for the selection of satellite-based access within a public land mobile network. This update supports flexible network operations for public safety by integrating satellite access into the isolated E-UTRAN framework. Additionally, an editorial update was made to the Mobile Country Code (MCC) specifications for publication clarity.

  • Satellite E-UTRAN in PLMN selector TS 31.102CR0956
  • MCC Editorial update for publication after TSG SA approval (SA#89) TS 23.180
Rel-18 9 changes

In Release 18, the enhancements for Isolated E-UTRAN Operations for Public Safety (IOPS) focused on expanding and validating Mission Critical Push to Talk (MCPTT) services. Specifically, new conformance test cases were added to the Mission Critical Services (MCX) Abstract Test Suite (ATS) to verify MCPTT functionality in both isolated E-UTRAN (MCX-EUTRA) and 5G New Radio with 5G Core (MCX-NR5GC) operational models. This ensured robust testing of direct device connections and relaying via ProSe UE-to-UE Relays for public safety users in various coverage conditions.

  • Support multiple non-public networks access and corresponding simultaneous services for a UE TS 22.261CR0564
  • Addition of MCPTT test case 5.1 to the MCX ATS with MCX-EUTRA model TS 37.579CR0004
  • Addition of MCPTT test case 6.1.1.16 to the MCX ATS with MCX-EUTRA model TS 37.579CR0008
  • Addition of MCPTT test case 5.1 to the MCX ATS with MCX-NR5GC model TS 37.579CR0016
  • Addition of MCPTT test case 6.1.1.16 to the MCX ATS with MCX-NR5GC model TS 37.579CR0019
  • Addition of MCPTT test case 5.8 to the MCX ATS with MCX-EUTRA model TS 37.579CR0025

+ 3 more changes

Rel-19 8 changes

In Release 19, the IOPS function was enhanced to become "access generic" or "access agnostic," moving beyond its E-UTRAN-specific origins to support more flexible network operations. This update involved revising core procedural clauses, such as IOPS discovery, and the scope to align with broader 5G system principles like support for non-public networks and diverse deployment scenarios. The changes also included cleaning up the specification text by removing Editor's Notes and incorporating procedures for Store and Forward Satellite Operations.

  • Updates to sections 10.6.1.4 and 10.7 to support generic IOPS TS 23.180CR0001
  • Updates to sections 10.5.1.3, 10.5.1.4, 10.5.3.1, and 10.5.3.3 to support generic IOPS TS 23.180CR0002
  • Updates to clauses 2 and 3 (References, Definitions, Abbreviations) to support access agnostic IOPS TS 23.180CR0010
  • Updates to clause 1 (Scope) to support access generic IOPS TS 23.180CR0011
  • Update the IOPS network deployment TS 23.180CR0012
  • Updates to clause 10.2.2.3 (IOPS discovery request) to support access generic IOPS TS 23.180CR0014

+ 2 more changes

Rel-20 1 change

In Release 20, the enhancements for Isolated E-UTRAN Operations for Public Safety (IOPS) specifically clarified security aspects for Mission Critical services, such as Mission Critical Push to Talk (MCPTT), operating over IOPS. This focused on ensuring secure direct device connections and relaying between Public Safety UEs, including via ProSe UE-to-UE Relays, within isolated network conditions. The update aimed to strengthen the security framework for priority communications in coverage, out-of-coverage, or partial coverage scenarios.

  • Clarification about security for MC over IOPS TS 33.180CR0236

Explore further

Broader topics and technologies where IOPS plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 22.261 vk30 5G System Service Requirements Rel-20
TS 22.281 vj00 Mission Critical Video (MCVideo) Service Requirements Rel-19
TS 22.282 vj00 Mission Critical Data Service Requirements Rel-19
TR 22.879 ve00 Mission Critical Video over LTE Feasibility Study Rel-14
TS 22.880 ve00 Mission Critical Data Communications Study Rel-14
TS 23.180 vj10 MC services support in IOPS mode Rel-19
TS 23.401 vj50 Evolved Packet System (EPS) Stage 2 Description Rel-19
TS 23.778 vg00 Mission Critical Services in Isolated E-UTRAN (IOPS) Rel-16
TS 23.797 vd00 Isolated E-UTRAN Operation for Public Safety (IOPS) Rel-13
TS 31.102 vj40 USIM Application Specification Rel-19
TS 33.180 vk00 Security of Mission Critical (MC) Service Rel-20
TS 33.401 vj10 EPS Security Architecture Rel-19
TS 33.700 3GPP TR 33.700 Rel-13
TS 33.897 vd10 Security for Isolated E-UTRAN Operation (IOPS) Rel-13
TS 37.579 vi40 Mission Critical services conformance testing Rel-18