II-NNI

Inter-IMS Network to Network Interface

Interface →
Introduced in Rel-8

II-NNI is the standardized interface between two different operators' IMS networks that enables secure interconnection for services like VoLTE and RCS.

Category
Interface
Introduced
Rel-8
Where
Core Network › 5G Core
Specifications
4 specs
II-NNI Description Purpose Related Classification Detected Changes Specifications

Description

The Inter-IMS Network to Network Interface (II-NNI) is a critical standardized reference point within the 3GPP IMS architecture. It defines the interface between the IMS core networks of two different service providers or administrative domains. The primary purpose of the II-NNI is to facilitate the interconnection of IMS networks to support end-to-end IMS services between subscribers belonging to different operators. Technically, the II-NNI is not a single physical link but a logical interface encompassing a set of protocols and procedures. The core protocol used across the II-NNI is the Session Initiation Protocol (SIP), extended with 3GPP-specific headers and parameters (as defined in TS 24.229) for session control. Alongside SIP, the interface utilizes the Session Description Protocol (SDP) for media negotiation and the Real-time Transport Protocol (RTP) for media bearer transport. A key architectural component is the Interconnection Border Control Function (IBCF), which acts as the gateway node at the edge of each IMS network. The IBCF performs vital functions such as topology hiding, network address/port translation (NAPT), SIP message screening and adaptation, and interworking between IPv4 and IPv6. The Transition Gateway (TrGW), often co-located with the IBCF, handles the media plane functions like media relay and transcoding if necessary. The II-NNI enables the establishment of peer-to-peer sessions (voice, video, messaging), registration path optimization, and the exchange of service-related information between networks while maintaining security, policy control, and charging separation.

Purpose & Motivation

The II-NNI was created to solve the fundamental problem of inter-operator connectivity for advanced IP-based multimedia services delivered by the IMS. Prior to its standardization, operators could deploy IMS as an island within their own network, but offering services like VoLTE or video calling to subscribers on other networks required proprietary gateways or fallback to legacy circuit-switched networks. The motivation was to enable a seamless, all-IP service experience across operator boundaries, which is essential for widespread user adoption. It addresses the limitations of non-standardized interconnection, which leads to interoperability issues, limited service richness, and complex network management. By defining a standardized interface, 3GPP allowed operators to interconnect their IMS cores directly, preserving the full feature set of IMS services (e.g., HD voice codecs, video, supplementary services) end-to-end. This was a crucial step in the evolution from circuit-switched telephony to all-IP communication, supporting the industry's move towards Rich Communication Services (RCS) and ensuring IMS could fulfill its role as a global service platform.

Classification

Part ofIMS
Related approachesIBCFSIP

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-15 3 changes

In Release 15, the II-NNI (Inter-IMS Network to Network Interface) saw the introduction of Functional Alias Management over this interface. The release also included corrections to II-NNI conditions specifically related to the handling of the P-Early-Media header field, including for the SIP UPDATE request method.

  • Functional Alias Management over II-NNI TS 29.165CR0961
  • Correction of II-NNI condition related to P-Early-Media header field TS 29.165CR0938
  • Correction of II-NNI condition related to P-Early-Media header field for the UPDATE request TS 29.165CR0940
Rel-16 3 changes

In Release 16, the II-NNI specifications were enhanced with clarifications and corrections for specific SIP header fields, namely the usage restriction of the P-Asserted-Identity header and the handling of the P-Charging-Vector header. Furthermore, new requirements for the RLOS (Redirected Line Identification Service) were added to operate over this interface, which interconnects two IMS core networks via the Ici reference point between IBCFs.

  • Clarification of the usage restriction of P-Asserted-Identity header field over the II-NNI. TS 29.165CR0990
  • Corrections on the II-NNI specifications on the P-Charging-Vector header field TS 29.165CR1006
  • Adding the RLOS requirements over the II-NNI TS 29.165CR1008
Rel-17 1 change

In Release 17, the II-NNI (Inter-IMS Network to Network Interface) was enhanced with the introduction of an IMS data channel capability. This addition provides a new protocol option for the interface, which is used to interconnect two IMS core network subsystem networks. The II-NNI remains a multi-protocol interface encompassing both the Ici reference point for SIP signaling and the Izi reference point for media forwarding.

  • IMS data channel at the II-NNI TS 29.165CR1024

Explore further

Broader topics and technologies where II-NNI plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 23.228 vj50 IMS Stage-2 Service Description Rel-19
TS 24.802 vc10 IMS II-NNI Traversal Scenario Determination Study Rel-12
TS 29.165 vj10 Inter-IMS Network to Network Interface (NNI) Rel-19
TS 29.865 v1800 Inter-IMS Network to Network Interface Rel-8
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.