H.2 Architecture model and reference points
23.2923GPPIP Multimedia Subsystem (IMS) centralized servicesRelease 17Stage 2TS
H.2.1 Reference architecture
The basic principles described in previous clause require the introduction of a CS access to IMS gateway function, i.e. the MSC Server enhanced for SeDoC and an interworking function (ICS IWF) to the reference architecture. The MSC Server enhanced for SeDoC maps GSM access procedures to IMS procedures but does not store user profile data, i.e. the VLR functionality is extracted and is placed for own users into the HSS and for inbound roamer into an ICS-IWF. By doing this the internal IMS architecture does not need to introduce new interfaces.
Figure H.2-1: Reference architecture
NOTE: Does only show the principle architecture, i.e. it does not show all interfaces.
H.2.2 Functional Entities
H.2.2.1 MSC Server enhanced for SeDoC
The MSC Server enhanced for SeDoC terminates CS Access and maps it to respective IMS procedures.
NOTE: When only a single profile in the IMS is used for service definition then a MSC Server enhanced for ICS (as defined in clause 7.6.2.9.3) is not used, instead a MSC Server enhanced for SeDoC is used in its place.
At high level the MSC Server enhanced for SeDoC performs the following functionality on the control plane:
– towards the UE:
– terminates the A (GERAN) and Iu-cs interfaces (UTRAN) when the UE accesses via a CS RAT.
– towards the IP Multimedia Subsystem:
– Terminates the I2′ interface to the x-CSCF.
– Terminates I3 to the Telephony Application Server.
– towards legacy networks:
– terminates the G and E interface towards MSC Servers.
– terminates ISUP signalling towards PSTN.
On the media plane the MSC Server enhanced for SeDoC controls Mc to the Media gateway.
H.2.2.1.1 Main differences to MSC Server enhanced for ICS
The MSC Server enhanced for SeDoC is based on the MSC Server enhanced for ICS, associated MGW as defined in clause 5.3.3 of this specification, TS 23.216 [36] and TS 23.237 [12] with the following amendments.
H.2.2.1.2 Call control solely done in IMS
Call Control (CC) functionality is essentially required only for the A/Iu-cs side of the MSC Server enhanced for SeDoC. Some local call control i.e.to treat "non UE detected emergency call" (Germany: 110) as emergency call and. route to E-CSCF is required. Remaining Call Control functionality is done by IMS in the same way as for PS calls. Therefore the MSC Server enhanced for SeDoC behaves as P-CSCF/ATCF from viewpoint of I/S/E-CSCF, SCC-AS and MSC.
Radio Resource Management (RR) and Mobility Management (MM) remain unchanged.
H.2.2.1.3 No VLR functionality
MSC Server enhanced for SeDoC does not include VLR functionality, i.e. there is also no D-Interface to the HLR. User Service Profile data and user service profile (i.e. identity, supplementary services) are handled in the IMS domain only. MSC Server enhanced for SeDoC just need to store user data related to radio access and RR/MM/CC procedures (e.g. IMSI, IMEI, TMSI, etc.).
H.2.2.1.4 Mapping of CS procedures to IMS procedures
The MSC Server enhanced for SeDoC terminates CS Access and maps it to respective IMS procedures.
H.2.2.1.5 Call Control procedures
Call Control procedures from the mobile CS user interface (A, Iu) are mapped towards IMS interface, i.e. I2 (SIP) towards IMS core in order to support the mapping of:
– MOC & MTC based on A/Iu to respective IMS procedures
– SMS-MO & SMS-MT based on A/Iu to respective IMS/IP-SM procedures
H.2.2.1.6 Supplementary Services Management procedures
Supplementary Services Management procedures from the mobile CS user interface (A, Iu) are mapped towards IMS interfaces, i.e. I3-IF (Ut, XCAP) towards IMS MMTEL AS.
H.2.2.1.7 Mapping of IMS procedures to CS procedures
IMS specific procedures that need to be mapped to appropriate GSM procedures are:
– early media (uni/bi-directional through-connect of media path).
– multiple early dialogues (due to forking on remote side (e.g. MSIM scenario):
– i.e. MSC Server enhanced for SeDoC serving the originating user needs to map multiple early SIP dialogues to one GSM dialogue towards the GSM device.
SRVCC is supported as specified for GSM MSC (TS 23.216 [36]), i.e. via Sv Interface to MME and via I2 Interface to ATCF. Reverse SRVCC is supported as specified for GSM MSC (TS 23.216 [36]).
CSFB support for Voice and SMS over SGs interface to MME, in case of combined attach to EPC and CS (via SGs), the MSC Server enhanced for SeDoC needs to interact with the IMS core similar as for CS attached voice terminals (e.g. map Location Update to IMS Registration, etc.)
H.2.2.1.8 Procedures which can be handled without IMS interaction
Various MSC-Server procedures which can be handled without IMS interaction remain within the MSC Server enhanced for SeDoC. This includes e.g. handover to/from other MSC Server enhanced for SeDoC or VMSC (original MSC Server enhanced for SeDoC remains anchor after handover).
H.2.2.1.9 SMS support considerations
In order to properly support SMS a SIP based replacement for MAP based SMS alerting procedures (reachability check) is needed, i.e. to set "not reachable" flag in case of unsuccessful SMS-MT and re-register if user is reachable again.
Upon unsuccessful SMS-MT delivery (no response from terminal) the MSC Server enhanced for SeDoC needs to activate a "Not Reachable" (NR) flag (similar to GSM MSC). In case of "NR flag = TRUE" and receipt of any message from the terminal, the MSC Server enhanced for SeDoC needs to re-register towards IMS-Core.
In case of unsuccessful SMS-MT to an attached user, the IP-SM-GW shall not initiate supervision in packet core network (Sh request to HSS).
After unsuccessful SMS-MT delivery, the IP-SM-GW sets a "Not Reachable" flag. Due to this flag a re-registration (and other messages received from the terminal) will trigger the standard retry mechanisms.
H.2.2.1.10 Location
MSC Server enhanced for SeDoC provides with PANI header the network provided location information according to cell-id received from radio access network (RAN). This information may be used by applications to differentiate between 2/3G Access via MSC Server enhanced for SeDoC and 4G Access via P-CSCF.
H.2.2.1.11 CS Data support
CS Data is used analogously to a voice call: A data terminal equipment (modem) establishes a connection to another terminal (modem). The connection setup is controlled by the IMS Core, the data stream can be transported transparently with already available codecs (e.g., "clear mode"/G7.11).
H.2.2.2 ICS Interworking Function
The ICS interworking function is introduced in order to support inbound and outbound roamers in networks that do not support IMS or ICS. Detailed in clause H.5.2.2.
H.2.3 Reference points
H.2.3.1 Reference Point MSC Server enhanced for SeDoC – CSCF (I2′ Reference Point)
The I2′ reference point is based on I2 functionality as defined in TS 23.216 [36], TS 23.237 [12] and in clause 5.4.2.
Additionally it supports the "Registration and Authentication procedure utilizing IMS Authorization" as specified in annex G.
H.2.3.2 Reference Point MSC Server enhanced for SeDoC – TAS (I3 Reference Point)
The I3 is used between the MSC Server enhanced for SeDoC and the TAS to interwork CS signalling and communication service setting procedures, as defined in clause 4.5 of this specification.
H.2.3.3 Reference Point ICS-IWF – CSCF (Cx’ Reference Point)
The Cx’ reference point is based on Cx functionality similar to the procedures of S-CSCF – HSS communication. It supports information transfer between CSCF and ICS-IWF.
The main procedures that require information transfer between CSCF and ICS-IWF are:
1) Procedures related to Serving CSCF assignment
2) Procedures related to routing information retrieval from ICS-IWF to CSCF
3) Procedures related to authorisation (e.g. checking of roaming agreement)
4) Procedures related to authentication: transfer of security parameters of the subscriber between ICS-IWF and CSCF
5) Procedures related to filter control: transfer of filter parameters of the subscriber from ICS-IWF to CSCF
Further information on the Cx reference point is provided in TS 23.228 [2].
H.2.3.4 Reference Point ICS-IWF – AS (Sh’ Reference Point)
The Sh’ reference point is based on Sh functionality similar to the procedures of AS – HSS communication. It supports information transfer between AS and HSS.