4 Architecture

23.3343GPPIP Multimedia Subsystem (IMS) Application Level Gateway (IMS-ALG) - IMS Access Gateway (IMS-AGW) interface: Procedures descriptionsRelease 17TS

4.1 Reference architecture

The reference architecture for the IMS-ALG and the IMS-AGW when NAT is invoked between the UE and the IMS domain is shown in figure 4.1.1 below.

Figure 4.1.1: Reference Architecture with NAT invoked between the UE and the IMS domain

See 3GPP TS 23.228 [2] Annexes G.1 and G.2 for a comprehensive description of the reference models.

The reference architecture for the IMS-ALG and the IMS-AGW supporting the ATCF/ATGW function is shown in figure 4.1.2 below.

Figure 4.1.2: Reference Architecture for IMS-ALG/IMS-AGW with ATCF/ATGW function

See 3GPP TS 23.237 [18] clause 5.2 for a comprehensive description of the reference model.

The reference architecture for the IMS-ALG and IMS-AGW supporting Interactive Connectivity Establishment (ICE) is shown in figure 4.1.3, for the case when both the signalling and media traverses NAT devices. There might be an ICE process towards access network domain and/or an ICE process towards core network domain. Both ICE processes are independent of each other. The network entities that support Session Traversal Utilities for NAT (STUN) and Traversal Using Relays NAT (TURN) are described in IETF RFC 8489 [84] and IETF RFC 8656 [85] respectively.

NOTE 1: If the IMS-AGW only supports ICE lite, it will only contain a STUN server.

NOTE 2: The IMS-AGW and IMS-ALG may support ICE only towards the served UE, and will then only contain a STUN client/server and ICE support on related terminations.

NOTE 3: The TURN server is a deployment option but not required for all ICE deployments.

NOTE 4: The separate STUN server is used by the served UE while it gathers ICE candidates. The STUN server in the IMS-AGW is used to answer ICE connectivity checks.

Figure 4.1.3: Reference architecture for ICE

The reference architecture for the P-CSCF enhanced for WebRTC (eP-CSCF) and the IMS-AGW enhanced for WebRTC (eIMS-AGW) to support WebRTC client access to IMS is shown in figure 4.1.4 as below, see Annex U in 3GPP TS 23.228 [2] for a comprehensive description of the reference model.

Figure 4.1.4: Reference Architecture for eP-CSCF/eIMS-AGW supporting WebRTC access to IMS

NOTE 1: The presence of dashed elements in the figure depends on the configuration.

PCC functional elements are present only for EPC access with QoS.

The corresponding PCC elements for fixed access are also optionally supported but not shown.

The NAT in figure 4.1.4 is meant for non-cellular access to IMS.

4.2 NAT Function

An operator may need NAT function between UE and IMS domain. Such function can be provided by the IMS-AGW and can be called local (near-end) NAT or IM CN hosted NAT (see clause 5.2). There can also be an independent NAT device between UE and IMS domain (see clause 5.4), referred as remote (far end) NAT. Thus the IMS-AGW shall support remote NA(P)T traversal.

Figure 4.1.1 illustrates the particular IP media-path scenario with both a remote NAT and local NAT function. Each NAT function is partitioning an IP domain into two address domains, or partitioning the used IP address space (realm) into two realms.

The reference architecture of Figure 4.1.1 may be mapped on various network scenarios, like e.g. to three IPv4 realms, indicated by a) IP-CAN (connectivity access network), b) (Media) Access Domain and c) (Media) IM CN domain. If there would not be any remote NAT device between the UE and IMS-AGW, then there would be just two IP domains (a and c).

The two types of NATs are also typically different from control perspective: local (near-end) NAT can be controlled by the operators directly, and remote (far-end) NAT that cannot be controlled by the operators directly.

The support of local NAT is thus implicitly leading to the requirement for IP realm indication at Iq (see clause 5.3).

The edge node of the IP-CAN may be a remote (far-end) NAT device (see Figure 4.1.1). This NAT device provides NAT or NAPT or NA(P)T-PT for IP traffic in the media-path and signalling path (e.g. IP network addresses and possibly L4 transport port values may be translated of SIP Gm messages).

The remote NAT device cannot be directly controlled by the operators of the (Media) Access and IP CN domain. The IMS-ALG is consequently lacking the direct information with regards to the applied NAT bindings by the remote NAT device.

4.3 ATCF/ATGW Function

The ATCF/ATGW functions may be supported by the IMS-ALG/IMS-AGW when SRVCC enhanced with ATCF is used. In this case, the Iq reference point is used for IMS sessions that the IMS-ALG (ATCF) decides to anchor at the IMS-AGW (ATGW) to provide the following functions:

– reservation and configuration of IMS-AGW (ATGW) resources for media anchoring during PS session origination or termination;

– reconfiguration of IMS-AGW (ATGW) resources during access transfer to the CS domain;

– release of IMS-AGW (ATGW) resources upon completion of the access transfer or release of the session;

– media transcoding if the media that was used prior to the access transfer is not supported by the MSC server;

– IP version interworking if different IP versions are used between the access and the remote legs;

– Indication of IP realm during allocation of transport addresses/resources (the PS and CS accesses may be reachable via different IP realms);

– the ability to configure ECN properties towards the transferred to Access if ECN is supported/requested;

– the ability to reconfigure the ECN mode e.g. from ECN transparent to ECN endpoint towards the IMS CN if ECN transparent cannot be maintained after access transfer to the CS domain;

– provide priority treatment to calls identified as Multimedia Priority Service (see 3GPP TS 22.153 [22]).

See 3GPP TS 23.237 [18] and 3GPP TS 24.237 [19] for a comprehensive description of the ATCF and ATGW functions.

4.4 eP-CSCF/eIMS-AGW Function

The Iq reference point is used between the P-CSCF enhanced for WebRTC (eP-CSCF) and the IMS-AGW enhanced for WebRTC (eIMS-AGW), with the following additional functions:

– media plane interworking extensions as needed for WICs;

– media security of type "e2ae" (as specified in 3GPP TS 33.328 [12]) for data channels using DTLS-SCTP.

– NAT traversal support including ICE;

– the ability to perform any transcoding needed for audio and video codecs supported by the browser; and

– transport level interworking between data channels and other transport options supported by IMS.

See 3GPP TS 23.228 [2] Annex U for a comprehensive description of the eP-CSCF and eIMS-AGW functions.