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.

See TS 23.228 Annex G.1 and Annex 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.

See clause 5.2 of TS 23.237 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 RFC 8489 and RFC 8656 respectively.

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 TS 23.228 for a comprehensive description of the reference model.

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.

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 TS 22.153).

See TS 23.237 and TS 24.237 for a comprehensive description of the ATCF and ATGW functions.

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 TS 33.328) 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 TS 23.228 Annex U for a comprehensive description of the eP-CSCF and eIMS-AGW functions.