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
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (25 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-8, normative work from Rel-15.
In Release 15, the II-NNI (Inter-IMS Network to Network Interface) saw updates including the introduction of Functional Alias Management and clarifications for the P-Early-Media header field handling in specific SIP requests. The release also updated architectural references to define the II-NNI for 5GS cases without IMS-level roaming interfaces and removed an editor's note concerning the exchange of Service-Interact-Info.
- Functional Alias Management over II-NNI TS 29.165CR0961
- Clause W.2 on "Architecture without IMS-level roaming interfaces" to refer to clause Y.9.2 that defines it for the 5GS case. TS 23.228CR1196
- 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
- Removal of editor's note on Service-Interact-Info TS 29.165CR0977
In Release 16, the II-NNI was enhanced with clarifications and corrections for header field usage, specifically for the P-Asserted-Identity and P-Charging-Vector header fields. It also introduced new requirements for the support of the RLOS (Reference Location Object) over this interface. Furthermore, the release provided updates for HSS discovery and interface type selection procedures used across the network interface.
- HSS Discovery and Interface Type Selection TS 23.228CR1201
- Allowing IMS to use N5 interface to interact with PCF TS 23.228CR1203
- Additional corrections for allowing IMS to use N5 interface to interact with PCF TS 23.228CR1204
- Clarification for HSS Discovery and Interface Type Selection TS 23.228CR1212
- 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
+ 1 more changes
In Release 17, the II-NNI was enhanced to support the IMS data channel, which is established within an IMS session to transfer application data and graphical user interfaces. Additionally, new functionality was specified for the IBCF to perform Resource Priority Header signing to support the Multimedia Priority Service (MPS) across interconnected IMS networks. These additions expanded the II-NNI's capabilities for both media interaction and priority service signaling.
In Release 18, the primary update for the II-NNI (Inter-IMS Network to Network Interface) function was a clarification on the interfaces and reference points used for Data Channel (DC) establishment and handling. This work specifically addressed the Ici reference point between IBCFs in different networks, ensuring proper procedures for the bootstrap data channel and interactions with DC Application Servers. The clarification helped define the network entry point roles, such as the IBCF, within the II-NNI architecture for these data channel services.
- Clarification on Interfaces and Reference Points Used for DC TS 23.228CR1325
In Release 19, the II-NNI enhancements primarily focused on enabling and refining Data Channel (DC) interworking procedures between a Data Channel Media Telephony Service for IMS (DCMTSI) UE and a Multimedia Telephony Service for IMS (MTSI) UE. This included specifying procedures for DC interworking via a DC Application Server (DC AS) and making corrections to the associated signalling procedures. The updates also involved aligning the service-based interface definitions and correcting the signalling for application data channel interworking via the Media Function (MF).
- Support of IMS data channel interworking between DCMTSI UE and MTSI UE TS 23.228CR1418
- KI#3: DC interworking with MTSI UE TS 23.228CR1479
- Update on support of DC interworking TS 23.228CR1465
- KI#3: Update to DC interworking with MTSI UE TS 23.228CR1539
- Updates on procedure and service of DC interworking via DC AS TS 23.228CR1551
- Correction to 3GPP PS Data Off Exempted Services for DC interworking TS 23.228CR1651
+ 4 more changes
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.
| Specification | Title | Release |
|---|---|---|
| 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 |