5 Reference model for interconnection between IM CN subsystems

29.1653GPPInter-IMS Network to Network Interface (NNI)Release 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 General

Figure 5.1.1 illustrates the architecture diagram given in 3GPP TS 23.228 [4] showing the Inter-IMS Network to Network Interface (II-NNI) between two IM CN subsystem networks.

NOTE: The TRF can reside in a stand-alone entity or can be combined with another functional entity.

Figure 5.1.1: Inter-IMS Network to Network Interface between two IM CN subsystem networks

The protocols over the two reference points Ici and Izi make up the Inter-IMS Network to Network Interface.

The Ici reference point allows IBCFs to communicate with each other in order to provide the communication and forwarding of SIP signalling messaging between IM CN subsystem networks. The Izi reference point allows TrGWs to forward media streams between IM CN subsystem networks.

IMS roaming performed by using II-NNI is considered, when the IBCFs are inserted at the network borders. The applicability of roaming scenario by using II-NNI is based on agreement between the operators.

Whenever the Inter-IMS Network to Network Interface is used to interconnect two IM CN subsystem networks belonging to different security domains, security procedures apply as described in 3GPP TS 33.210 [10].

When an IMS transit network is providing application services and interconnecting two IM CN subsystem networks, as described in 3GPP TS 23.228 [4], interfaces on both sides of the IMS transit network are within the scope of this document.

When two IM CN subsystem networks are interconnected for IMS emergency session establishment as described in 3GPP TS 23.167 [215], the interface between these IM CN subsystem networks is within the scope of this document.

NOTE: Implementations of functional entities at the IMS network edge might include functions that are not described in this Release of the specification, for example fault management that sends SIP OPTIONS requests between the two IBCFs over the Ici. IBCF originated SIP OPTIONS standalone transactions and any other features not described in the main body of this specification are out of scope.

5.2 Functionalities performed by entities at the edge of the network

5.2.1 Interconnection Border Control Function (IBCF)

An IBCF provides application specific functions at the SIP/SDP protocol layer in order to perform interconnection between IM CN subsystem networks by using Ici reference point. According to 3GPP TS 23.228 [4], IBCF can act both as an entry point and as an exit point for the IM CN subsystem network.

The functionalities of IBCF are indicated in the 3GPP TS 23.228 [4] and specified in 3GPP TS 24.229 [5]. They include:

– network topology hiding;

– application level gateway (for instance enabling communication between IPv6 and IPv4 SIP applications, or between a SIP application in a private IP address space and a SIP application outside this address space);

– controlling transport plane functions;

– controlling media plane adaptations;

– screening of SIP signalling information;

– selecting the appropriate signalling interconnect;

– generation of charging data records;

– privacy protection;

– additional routeing functionality; and

– inclusion of a transit IOI in requests when acting as an entry point for a transit network and in responses when acting as an exit point for a transit network.

Based on local configuration, the IBCF performs transit routing functions as specified in 3GPP TS 24.229 [5] clause I.2.

The IBCF acts as a B2BUA when it performs IMS-ALG functionality.

5.2.2 Transition Gateway (TrGW)

According to 3GPP TS 23.002 [3], the TrGW is located at the network borders within the media path and is controlled by an IBCF. Forwarding of media streams between IM CN subsystem networks is applied over Izi reference point.

The TrGW provides functions like network address/port translation and IPv4/IPv6 protocol translation. NAT-PT binds addresses in IPv6 network with addresses in IPv4 network and vice versa to provide transparent routing between the two IP domains without requiring any changes to end points. NA(P)T-PT provides additional translation of transport identifier (TCP and UDP port numbers). The approach is similar to that one described also in 3GPP TS 29.162 [8].

Further details are described in 3GPP TS 23.228 [4].

5.3 Identifying II-NNI traversal scenario

5.3.1 General

The procedures for identifying the II-NNI traversal scenario using the "iotl" SIP URI parameter defined in IETF RFC 7549 [188] is specified in 3GPP TS 24.229 [5].

This specification uses the following II-NNI traversal scenarios when describing requirements at II-NNI:

– the non-roaming II-NNI traversal scenario;

– the roaming II-NNI traversal scenario; and

– the loopback II-NNI traversal scenario.

When a requirement at II-NNI is dependent on direction the roaming II-NNI traversal scenario is further divided into:

– the home-to-visited II-NNI traversal scenario; and

– the visited-to-home II-NNI traversal scenario.

See figure 4.2 and figure 4.3 for information on how the II-NNI traversal scenarios above are applied between networks.

5.3.2 Mapping of the "iotl" SIP URI parameter to II-NNI traversal scenario

Table 5.3.2.1 describes how the "iotl" SIP URI parameter shall be used to identify the II-NNI traversal scenario. The table 5.3.2.1 contains the following items:

– the first column, named "II-NNI traversal scenario", shows the II-NNI traversal scenarios within the scope of this specification; and

– the second column, named "Value of the "iotl" parameter", shows the value of the "iotl" SIP URI parameter as specified in IETF RFC 7549 [188].

Table 5.3.2.1: Mapping of the "iotl" SIP URI parameter to II-NNI traversal scenario

II-NNI traversal scenario	Value of the "iotl" parameter
Non-roaming II-NNI traversal scenario (NOTE 1)	"homeA-homeB" or "visitedA-homeB"
Loopback traversal scenario	"homeA-visitedA"
Roaming II-NNI traversal scenario	"visitedA-homeA" or "homeB-visitedB" (NOTE 2)
Home-to-visited traversal scenario	"homeB-visitedB"
Visited-to-home traversal scenario	"visitedA-homeA"
NOTE 1: This is the default II-NNI traversal scenario, if the "iotl" SIP URI parameter is not present in the Request-URI or in any of the Route header fields in the SIP request and if an implementation dependent method of identifying the II-NNI traversal scenario is not used. NOTE 2: When the requirement at II-NNI is independent on direction any of the "visitedA-homeA" or "homeB-visitedB" can be used to identify the roaming II-NNI traversal scenario.