5.5 Configuration of IM CN Subsystem entities

23.0023GPPNetwork architectureRelease 17TS

5.5.1 IM CN Subsystem functional entities

The configuration of IM CN Subsystem entities is presented in figure 6. In the figure, all the functions are considered implemented in different logical nodes. If two logical nodes are implemented in the same physical equipment, the relevant interfaces may become internal to that equipment.

Only the interfaces specifically linked to the IM CN subsystem are shown, i.e. all the SGSN, GGSN, S-GW, PDN-GW and HSS interfaces depicted in figure 1 and figure 1b are still supported by these entities even if not shown.

Legend:

Bold lines: interfaces supporting user traffic;

Dashed lines: Interfaces supporting only signalling.

NOTE 1: The reference point CS (Circuit Switched) is not specified in this specification.

NOTE 2: The reference point I5 is not shown in this figure.

Figure 6: Configuration of IM Subsystem entities

5.5.2 IM CN Subsystem Service layer

The figure below depicts an overall view of the functional architecture for services.

Figure 6a: Functional architecture for the provision of service in the IMS

The purpose of the IM SSF is to host the CAMEL network features (i.e. trigger detection points, CAMEL Service Switching Finite State Machine, etc.) and to interwork with CAP. The IMS-SSF may receive CAMEL subscription data from HSS via Sh reference point in addition to the Si reference point.

The IM SSF and the CAP interface support legacy services only.

The application server may contain "service capability interaction manager" (SCIM) functionality and other application servers. The SCIM functionality is an application which performs the role of interaction management. The internal components are represented by the "dotted boxes" inside the SIP application server. The internal structure of the application server is outside the standards. The Sh interface shall have sufficient functionality to enable this scenario.

The figure below depicts an overall view of the functional architecture for enabling the management of the user’s service related information via the Ut interface.

Figure 6b: Functional architecture for the management of the user’s service related information

The figure below depicts an overall view of the functional architecture for routing SIP requests between I‑CSCF and Application Server.

Figure 6c: Functional architecture for the routing of SIP requests between I‑CSCF and AS

5.5.3 Service Centralization and Continuity

Figure 6d depicts an overall view of the functional architecture for IMS services centralization and continuity.

Figure 6d: Functional architecture for IMS Service Centralization and Continuity

IMS Service Centralization, defined in TS 23.292 [110] provides communication services such that all services, and service control, are based on IMS mechanisms and enablers. It enables IMS services when using CS access as bearer for the media.

IMS Service Continuity, defined in TS 23.237 [111] provides Session Transfer mechanisms to maintain service continuity in the event of access transfer for the case when such events are not hidden from the IMS session layer and thus service continuity could not otherwise be maintained.

Figure 6e provides the reference architecture for SRVCC using the ATCF enhancements as defined in TS 23.237 [111]. The ATCF enhancements provide Session Transfer mechanisms in the serving network to maintain service continuity in the event of access transfer for SRVCC.

Figure 6e: IMS Service Centralization and Continuity Reference Architecture when using ATCF enhancements

If neither the MSC Server is not enhanced for ICS, the interface between MSC Server and ATCF is Mw.

NOTE 2: If the MSC Server is enhanced for ICS, the interface between MSC Server and ATCF is I2.

5.5.4 WebRTC access to IMS

Figure 5.5.4-1 depicts an overall view of the functional architecture for WebRTC access to IMS.

NOTE: 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 is meant for non-cellular access to IMS.

Figure 5.5.4-1: Functional architecture for WebRTC access to IMS

The architecture and the procedures to provide communication services to WebRTC IMS clients (WIC) are defined in Annex U of TS 23.228 [34].