ICE

Interactivity Connectivity Establishment

Services →
Introduced in Rel-8 Also in: Services

ICE is a 3GPP framework for establishing interactive media sessions like voice and video calls across diverse networks, extending IETF methodology to ensure robust NAT and firewall traversal.

Category
Services
Introduced
Rel-8
Where
Core Network › Evolved Packet Core
Also touches
1 segments
Specifications
23 specs
ICE Description Purpose Related Classification Detected Changes Specifications

Description

Interactivity Connectivity Establishment (ICE) in the 3GPP context is a service enabler framework that provides a standardized mechanism for establishing interactive media sessions (e.g., Voice over LTE (VoLTE), Video over LTE (ViLTE), and other IMS-based services) in the presence of Network Address Translators (NATs) and firewalls. It is an adaptation and profiling of the IETF's ICE protocol (RFC 8445) for use within the 3GPP IP Multimedia Subsystem (IMS) architecture. The core function of ICE is to discover the most optimal network path between two communication endpoints by gathering candidate transport addresses (combinations of IP address and port), prioritizing them, and performing connectivity checks to verify which pairs can successfully communicate.

How it works involves several key components and steps, primarily executed by the User Equipment (UE) and assisted by network elements. First, each UE gathers candidate addresses. These include a Host Candidate (its own local IP address), Server Reflexive Candidates (its public IP address as seen from a STUN server, obtained via a STUN binding request), and Relayed Candidates (an address on a TURN relay server, used as a last resort). In a 3GPP IMS deployment, the P-CSCF often incorporates or co-locates with the ICE-related functions, acting as the STUN/TURN server. The candidates are then sent to the remote party via the Session Initiation Protocol (SIP) offer/answer exchange embedded in the SDP (Session Description Protocol).

Once both sides have exchanged candidate lists, they begin connectivity checks. Each endpoint systematically sends STUN binding requests to the candidate pairs provided by the other endpoint, prioritizing pairs that are likely to work fastest (e.g., host-to-host on the same subnet). The first pair that results in a successful bidirectional STUN request/response exchange is selected for media flow. This process ensures that media takes the most direct path possible while guaranteeing a fallback to a relayed path if direct connectivity is blocked. Within 3GPP, specifications like TS 24.229 and TS 29.333 detail how ICE procedures are integrated into IMS signaling and how the P-CSCF controls and assists the process, ensuring it aligns with network policies and quality of service (QoS) mechanisms.

Purpose & Motivation

ICE was created to solve the fundamental problem of establishing peer-to-peer media sessions on the modern internet, which is dominated by IPv4 address scarcity and the consequent ubiquitous deployment of NATs and stateful firewalls. These devices break the end-to-end connectivity principle by hiding private IP addresses and dynamically allocating ports, making it impossible for an endpoint behind a NAT to simply announce its private address and receive incoming media streams. Prior to ICE, solutions like simple STUN worked only for certain types of NATs, and often required fallback to a media relay (TURN) for all sessions, which is inefficient and costly.

The motivation for 3GPP to adopt and profile ICE was driven by the transition to all-IP networks with LTE and the reliance on IMS for telephony services (VoLTE). For carrier-grade voice and video to be successful, they needed reliability and quality matching circuit-switched networks, but over an IP infrastructure shared with best-effort data. ICE provides a robust, standardized method for NAT traversal that maximizes the chance of establishing a direct, low-latency media path (optimal for quality) while guaranteeing a relayed connection will work if necessary (ensuring reliability). This was a critical enabler for the commercial success of VoLTE.

Furthermore, ICE allows sessions to work across diverse network attachments, including when a UE moves between cellular and Wi-Fi (IFOM, MAPCON, or later ATSSS). It provides a unified methodology for connectivity establishment regardless of the underlying access technology. By standardizing this within 3GPP, it ensures all UEs and network elements implement a compatible, interoperable, and efficient mechanism, preventing proprietary solutions and fostering a consistent user experience for interactive services.

Classification

Part ofIMS
Specific typesTURN
Related approachesNATTURNP-CSCF

Detected Changes Across Releases

from 3GPP Change Requests

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

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

Rel-15 1 change

In Release 15, the ICE function was newly introduced to support pre-established session establishment and modification for Mission Critical (MC) services, where the MC service client gathers ICE candidates to establish media sessions. This functionality is specifically detailed within procedures for modifying a pre-established session, where the client can send a request to update the ICE candidate pair and the server responds to accept this update. The integration of ICE provides the necessary NAT traversal for the media bearers used in these MC service communications.

  • Update to connectivity for interconnection TS 23.280CR0142
Rel-16 1 change

In Release 16, the key new feature for ICE (Interactive Connectivity Establishment) was the introduction of procedures for an MC service UE to obtain **migration connectivity information** for a partner MC system. This enabled the MC service client to gather ICE candidates and establish or modify a pre-established session using updated ICE candidate pairs specifically for migration scenarios. The enhancement focused on supporting service continuity and session establishment when a user migrates between interconnected Mission Critical systems.

  • Migration connectivity information TS 23.280CR0179
Rel-17 11 changes

In Release 17, the primary update to the Interactivity Connectivity Establishment (ICE) function was the systematic update of IETF references for the ICE, STUN, and TURN protocols to align with the latest external standards. Furthermore, a new capability was introduced allowing the MC service server to request network resources at session establishment, which integrates with the existing pre-established session procedures for gathering ICE candidates.

  • Request for network resources at session establishment from the MC service server TS 23.280CR0278
  • Update of IETF references for ICE TS 23.333CR0145
  • Update of IETF references for ICE, STUN and TURN TS 23.334CR0177
  • Update of IETF references for ICE TS 29.232CR0662
  • Update of IETF references for ICE TS 29.332CR0202
  • Update of IETF references for ICE TS 29.333CR0113

+ 5 more changes

Rel-18 1 change

In Release 18, the ICE function was extended to support PDN connection establishment specifically for Mission Critical (MC) service clients located behind an MC Gateway UE. This enables MC service clients hosted on non-3GPP devices behind the gateway to utilize the established PDN connection to the MC service APN for connectivity. The enhancement integrates ICE candidate gathering and session modification procedures within the pre-established session framework between the MC client and the MC server.

  • PDN connection establishment for MC service clients behind MC GW UE TS 23.280CR0414

Explore further

Broader topics and technologies where ICE plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 23.280 vk10 Common Architecture for Mission Critical Services Rel-20
TS 23.333 vj00 MRFC-MRFP Mp Interface Requirements Rel-19
TS 23.334 vj00 IMS-ALG to IMS-AGW Interface (Iq) Stage 2 Rel-19
TS 23.379 vk00 MCPTT Functional Architecture Rel-20
TS 23.701 vc00 WebRTC Access to IMS Architecture Study Rel-12
TS 24.229 vj50 IMS call control protocol based on SIP and SDP Rel-19
TS 26.223 vj00 IMS Telepresence Client Specification Rel-19
TS 26.506 vj20 Real-Time Media Communication Architecture for 5G Rel-19
TS 26.510 vj10 Media Delivery APIs for 5GMS and RTC Systems Rel-19
TR 26.923 vj00 Study on IMS-based Telepresence Media Handling Rel-19
TR 26.998 vj00 5G AR/MR Glasses Integration Study Rel-19
TS 29.079 vj00 Optimal Media Routeing (OMR) Procedures Rel-19
TS 29.162 vj00 IMS-IP Network Interworking Rel-19
TS 29.163 vj00 Interworking between 3GPP IM CN and CS networks Rel-19
TS 29.232 vj00 Mc Interface Protocol Profile Rel-19
TS 29.235 vj00 SIP-I CS Core Network Interworking Rel-19
TS 29.238 vj00 H.248 Profile for IBCF-TrGW Interface Rel-19
TS 29.292 vj00 IMS Centralized Services (ICS) Interworking Rel-19
TS 29.332 vj00 MGCF-IM-MGW Interface Protocol (Mn) Rel-19
TS 29.333 vj00 MRFC-MRFP Mp Interface Protocol Rel-19
TS 29.334 vj00 IMS-ALG to IMS-AGW Interface Protocol Rel-19
TS 31.102 vj40 USIM Application Specification Rel-19
TS 33.871 vc00 Security for WebRTC IMS Client Access Rel-12