ICS (3) - Function (Charging, Roaming, SS Data Mgt/Syn and User Prederence)

ICS (3) - Functions (Charging, Roaming, SS Data Mgt/Syn and User Prederence)

8). Charging on SCC AS:

§ The access related charge for an ICS call, i.e. the CS access network related charge or IP-CAN related charge, shall be included in charging record generated by SCC AS.

8.1). Offline charging

§ Charging record generated by the SCC AS may be correlated with charging records generated in the MSC Server or with charging records in the IP-CAN, where applicable - the combination of charging records is used for determining access charge for the call or multimedia session.

§ The combination of these charging records may further be correlated with other IMS-based charging records generated by S‑CSCF or other functional entities in the IMS network, for the purpose of generating an overall charge for a call or multimedia session, including access related charge.

8.2). On-line charging

§ When on-line charging is applied for an ICS subscriber, this on-line charging should be performed strictly in IMS. CS network based on-line charging service (e.g., CAMEL prepaid), for example, shall not be invoked for ICS subscribers.

§ If for an ICS subscriber a call that is established in CS is not anchored in IMS network, i.e. no ICS is applied for that call, then on-line charging in CS access can be applied for that call

9). Roaming support

§ UE could move on to an MSC that is either not enhanced for ICS or does not have an associated L‑CAAF‑n while roaming.

9.1). ICS Roaming OV

An ICS user shall receive full ICS support from the HPLMN while roaming in the VPLMN, subject to the constraints of the VPLMN (e.g. roaming agreements, operator policies).

a) The subscriber does not receive IMS Centralized services. The roaming subscriber shall at least be able to originate and terminate basic services e.g. bi-directional speech calls.

b) The subscriber receives a subset of IMS Centralized services.

c) The subscriber is rejected from roaming in those networks.

9.2). ICS Roaming Numbers

§ CSRN (as MSRN): CS Roaming Number -> Mobile Terminated IMS -> CS -> VLR returns CSRN (as MSRN) as a response to SRI

§ IMRN (IMS Roaming Number): -> Mobile Originated CS -> IMS -> CAMEL triggered forwarding to IMRN

§ Dynamic ICS PSI: Public Service ID -> Mobile Originated CS -> IMS -> PSI received via USSD

9.3). Fallback Mechanism – Roaming in VPLMN:

When there is no ICS functionality available at an attached MSC, the following fallback solutions options are discussed especially roaming in VPLMN.

§ In VPLMNs with CAMEL, It should be better operator options (e.g. by CAMEL provisioning) when option 1 or option 2.1 should be used

§ In VPLMNs with no CAMEL, option 2.1 should always be used.

Option 1. Fallback to redirection to IMS. That is, to redirect all originated calls to the IMS by using CAMEL.

§ Option 1 provides the most functionality of all options, but of course relies on CAMEL support in the VPLMN.

§ Options 1 should be defined in the network based ICS solution.

Option 2. Fallback to CS:

Option 2.1. MO calls handled in CS (i.e. MSC in VPLMN), MT calls handled in IMS. Hence originating or mid‑call services will be in CS domain and terminating services in IMS.

§ Option 2.1 will have a fairly simple technical realization and is probably the best option to use when there is no CAMEL in the VPLMN

§ In VPLMNs with no CAMEL, option 2.1 should always be used.

§ Options 2.1 should be defined in the network based ICS solution.

Option 2.2. MO calls and MT calls handled in CS. For incoming IMS calls, the T-SDS will need to be enhanced to be made dynamic as currently it is only statically configured.

§ Option 2.2 will require fairly substantial work in order to provide a technical realization: possibly too much work for the actual benefit it brings.

§ Option 2.2 is too complex in relation to their actual use and benefits they will bring.

Option 3. Fall back to UE based ICS solution.

§ Option 3 falling back to UE based ICS solution is impossible in any case.

§ Option 3 is not applicable.

10). ICS - Supplementary Services Data Management / Synchronization on HSS and TAS

10.1). Alternative 1: ICS Supplementary Service data synchronization via Ut and Sh

§ from UE to HSS via Ut (UE à HSS)

§ between HSS and TAS via Sh (TAS ß à HSS)

The following extensions for the Sh interface are necessary: Add a new Data Ref. value to identify CS service data for use in

§ Sh-Pull; to allow the TAS to read CS service data from the HSS/HLR

§ Sh-Update; to allow the TAS to modify CS service data in the HSS/HLR

§ Sh-Subs-Notif; to allow the TAS to subscribe to notifications about modified CS service data in the HSS/HLR

§ Sh-Notif; to allow the HSS to notify the subscribed TAS about modified CS service data in the HSS/HLR.

10.2). Alternative 2: Interworking ICS supplementary service data requests between MAP and XCAP via IWF

§ ICS UE à (DTAP) à MSC à (MAP) à HSS à (MAP) à IWF à (XCAP) à TAS

§ TAS à (XCAP) à IWF à (MAP) à MSC à (DTAP) à ICS-UE

§ HSS is pre-configured with the address of an interworking function (IWF) that interworks MAP Call Independent Supplementary Services (CISS) requests into XCAP.

§ For an ICS user, all CISS requests are forwarded to the IWF for further processing.

§ MAP to XCAP interworking function for SS Data Management

11). Management of TAS user configuration

11.1). Alternative 1: Using I1 (UE --- SCC AS)

Managing Communication Services related Information

§ ICS UE initiates management of communication services related information.

§ The ICS UE encodes in one or more CS protocol (e.g. USSD) messages sufficient information for the SCC AS to use capabilities for Managing Communication services related information and sends it to the SCC AS.

11.2). Alternative 2: Ut reference point Using IP-CAN

§ The supplementary service setting management is possible through the user getting IP-CAN access.

11.3). Alternative 3: Ut reference point Using CS Data call (UE --- TAS)

§ Authentication Proxy (AP) may be used to authenticate the UE in the IMS when the UE accesses to the TAS over IP-CAN.

§ This AP may also be able to authenticate the UE when the UE uses CS data calls as bearer.

§ The TAS receives the XCAP/HTTP request to manage the user settings over Ut

§ The TAS does not see any difference whether the UE uses IP-CAN or CS data call as bearer.

11.4). Alternative 4: Using a WAP interface via CS Data call

§ This CS data calls can be used to manage supplementary services via a WAP interface

§ The WAP GW interacts with the TAS to modify the supplementary service settings of the user.

12). Mechanism for Conveyance of User Preference:

§ User preferences include: Preferred access for terminating sessions

§ User Preference thru T-ADS (Terminating Access Domain Selection) enhanced in R9

§ Whether the user preference is conveyed from UE to the SCC AS

§ The deployment options will choose and depend on capabilities of UE and Network

12.1). Alternative 1 – User Preferences by UE assisted T-ADS

§ This alternative depends on having T-ADS capability on both ICS UE and SCC AS.

§ In case UE assisted T-ADS (UE T-ADS) is supported then the enforcement of user preferences can be done locally in the UE.

§ When T-ADS-IMS (in SCC AS) selects the IMS access (e.g. I1-ps or IP-CAN) to deliver the termination session, the T-ADS in the UE (UE T-ADS) can indicate to the T-ADS-IMS whether voice session should be delivered via CS access and whether I1-ps or I1-cs should be used for continuing the session setup.

§ In this case there is no need for the UE to provide any user preferences to the SCC AS in order to determine the preferred access for terminating sessions

12.2). Alternative 2 – User Preferences conveyed within IMS registration

§ The benefit of this alternative is to avoid introducing new interfaces or mechanisms, the existing IMS registration procedures can be reused. But not every UE can have IP-CAN connectivity.

§ Whenever an UE acquires IP connectivity via an IP-CAN, the UE will register in the IMS and a 3rd party registration will be made towards the SCC AS. The user preference is conveyed to the SCC AS as a part of the 3rd party register.

§ User preferences can be stored in the UE and sent to the SCC AS at registration time.

§ If the User preferences are changed, the UE would initiate a re-registration in order to convey the new data to the SCC AS.

§ If the UE is not registered to IMS through PS domain, the UE cannot provide user preferences to the SCC AS.

12.3). Alternative 3 – User Preferences over Ut

§ This alternative may be more suitable if the user preferences are set on a per user basis.

§ If more complex user preferences shall be communicated to the SCC AS, an Ut interface may be used

§ In this case, the XML model for such user preferences must be specified.

12.4). Alternative 4 – User Preferences over OMA DM

§ The benefit of this alternative is simple and no new protocol needs to be introduced for user preferences, but through OMA DM management mechanism for UE.

§ TS 24.216 defines an OMA DM management object for operator policy in Session Continuity.

§ The Policy is carried from the management server to the UE.

§ This solution carries user preferences from the UE to the management server (DM Server)

§ In the OMA DM management object, each attribute can define whether the attribute can be read, written or both by the management server.

§ Alternatively, a separate set of user modifiable attributes can be defined in the management object - readable by the server, but modified by the UE (end user)

§ UE then either initiates the management session and notifies the management server that the attribute has been modified, or the server is also able to inquire the changed management object from the UE e.g. periodically.

ICS (2) - Architecture, I/F, FE, Path Establishment

ICS (2) - Architecture, I/F, FE, Path Establishment

5). Architecture and Interface:

5.1). ICS Architecture and Interface:

Figure - ICS Architecture: http://docs.google.com/View?id=ddh56dhg_317ccr5n8vv

5.2). (I1) UE – SCC AS

§ The I1 reference point is used between the UE and the SCC AS for service control signalling over CS access.

§ I1 reference point is optional and implemented using USSD transport via CS network elements.

The I1 performs the following functions:

§ session set up via CS access for mobile originating & terminating sessions;

§ signalling for additional IMS parameter exchange during session setup;

§ IMS services control via CS access.

§ The ICS User Agent (IUA) function provides SIP UA behavior on behalf of the UE for setup and control of for IMS sessions using CS bearers that are established with or without the use of Gm (via SIP) or I1 (via USSD) between the ICS UE and the SCC AS.

5.3). (I2) MSC Server (IMSC) – CSCF

§ The I2 reference point shall be used to route service control signalling between the MSC Server enhanced for ICS and the home IMS.

§ I2 is used, when the MSC is enhanced for IMS centralized services, to convert CS signaling to IMS signaling (SIP protocol)

§ The Mw in TS 23.228 together with ICS specific extensions shall be used over the I2 reference point.

5.4). (I3) MSC Server (IMSC) – TAS

§ For a UE not supporting multimedia telephony, the MSC Server enhanced for ICS may implement a communication service setting conversion function between CS signalling via I3.

§ The I3 reference point shall be used between the MSC Server enhanced for ICS and the TAS to interwork CS signalling and communication service setting procedures

§ Configuration of supplementary services by the user should:

o take place over the Ut interface using XCAP as enabling protocol

o use SIP based user configuration

5.5). ICCF – IMSC: for ICS asscoication between ICCF and IMSC

Option 1: New Diameter exchange upon CS Attach

Option 2: New USSD exchange upon CS Attach

Option 3: Use of SIP REGISTER upon CS Attach

§ The following options are possible for implementation of the ICS Association between the ICCF and the IMSC.

Option 1: Diameter exchange upon CS Attach

§ Figure illustrates use of Diameter to establish the ICS Association between the ICCF and the IMSC upon CS Attach.

§ Figure: http://docs.google.com/View?id=ddh56dhg_311fjcdnrth

§ The HSS maintains the ICS subscription information, as well as subscriber location to aid in determining the IMSC contact address as part of the subscriber data.

§ Upon Location Update from an IMSC, this information is pushed down to the ICCF over the Sh or MAP interface. With the use of this information, the ICCF initiates a dialogue with the IMSC to establish the ICS Association.

§ A new Diameter interface between the ICCF and the IMSC is used for establishment of the ICS Association (Step 4 in the figure).

§ After the ICS Association has been established for a ICS UE, the IMSC initiates a SIP REGISTER for the UE if it's a non ICS UE or a ICS UE using I1-cs.

Option 2: USSD exchange upon CS Attach

§ The IMSC uses UE initiated USSD procedure toward the ICCF upon CS Attach to establish the ICS Association.

§ Figure below illustrates use of USSD to establish the ICS Association between the ICCF and the IMSC upon CS Attach.

§ After the ICS Association has been established for a ICS UE, the IMSC initiates a SIP REGISTER for the UE if it's a non ICS UE or a ICS UE using I1-cs.

§ This option eliminates the need for MAP/Sh enhancements and/or a new Diameter interface between the ICCF and the IMSC.

§ Figure: http://docs.google.com/View?id=ddh56dhg_3138dk65qgq

Option 3: Use of SIP REGISTER upon CS Attach

§ Upon CS Attach, the IMSC establishes the ICS Association as part of the SIP REGISTER; SIP extensions may be required to exchange ICS information as part of IMS Registration via CS access.

§ This option eliminates the need for new interface or USSD

§ But this option requires local VPLMN configuration of ICS subscription for ICS users as the IMSC shall only redirect ICS users to IMS.

5.6). (I5) ICCF – TAS: (TBC later)

5.7). (Mc) MSC server – CS-MGW

§ The Mc is established between the MSC Server enhanced for ICS and the CS-MGW.

§ MSC Server controls the MGW functions to enable the interworking between CS access and RTP bearers.

6). ICS Functional Entity

In 3GPP ICS Spec:

§ ICCF defines in R8 and SCC AS for ICS in R9

§ ICCF in R8 includes CAAF, RUA and RPC

§ SCC AS in R9 includes CAA, IUA and T-ADS

§ ICS AS in R9 includes IUA and T-ADS

6.1). FE: UE enhanced for ICS

The ICS UE is an IMS UE enhanced with ICS capability. The ICS UE provides the following functions:

§ Communicates with the SCC AS for service control signalling.

§ Establishes the Bearer Control Signalling Path to setup the media through the CS domain.

§ Executes ADS (Access Domain Selection) for originating sessions

§ Assists the SCC AS in the execution of T-ADS (Terminating-ADS) if Gm is used.

The ICS UE uses the Gm reference point when using the PS network for service control signalling.

6.2). FE: ICS Enhanced MSC Server (IMSC)

§ The MSC Server (e.g. as described in TS 23.002) may be enhanced for the support of ICS.

§ In addition to the standard MSC Server behavior, an MSC Server which has been enhanced for ICS provides the following for an identified ICS user:

§ It processes the user-network signalling received over the CS access (e.g. A/Iu and E interface) for interworking with IMS SIP and vice versa.

§ It controls the MGW functions described in TS 23.002 to enable the interworking between CS access and RTP bearers.

§ It performs the interworking to support multimedia call in ICS.

§ It may implement a communication service setting conversion function between CS signalling (e.g. as described in TS 24.010 for systems based on TS 24.008) and communication service setting procedures (as defined in TS 24.173).

§ For subscribers not identified as ICS users, the MSC Server functionality is unchanged.

§ MSC Server enhancements for ICS are not required for the support of an ICS UE.

6.3). FE: Application Server (ICS AS)

The ICCF provides the following roles:

§ CS Access Adaptation Function (CAAF) in R8

§ Remote User Agent (RUA) in R8

§ Remote Provisioning Client (RPC) in R8

The ICS AS provides the following roles:

§ ICS User Agent (IUA) in R9

§ Terminating Access Domain Selection (T-ADS) in R9 Spec Enhancement

The SCC AS provides the following roles:

§ CS Access Adaptation (CAA) in R9

§ ICS User Agent (IUA) in R9

§ Terminating Access Domain Selection (T-ADS) in R9 Spec Enhancement

6.3A). CS Access Adaptation (CAA):

§ CS Access Adaptation Function (CAAF) in R8 and CAA in R9

§ The CAAF is not employed in the ICCF and the UE when the I1-ps is used.

§ Note: CAAF is not used when using SIP for the ICCC.

§ The CS Access Adaptation (CAA) is an (ICCF internal) adaptation function for the service control signalling communicated transparently via the CS domain CS access transport between the UE and the IMS (SCC AS).

§ The CAA is only used when using the CS network for communication of service control signalling.

§ The CAAF can also be used as an adaptation function for requests for communication services setting modifications.

§ The CAAF conveys the information received from the ICS UE over CS access signalling to ICCF functions such as the RUA and RPC, and vice versa.

§ The CAA processes the service control signalling received via the CS access for interworking with other IMS functional elements.

§ The Remote CS Access Adaptation Function (R-CAAF) resides in the ICCF with a Local CS Access Adaptation Function (L-CAAF) provided in the ICS UE.

6.3B). ICS User Agent (IUA):

§ Remote User Agent (RUA) in R8 and IUA in R9

§ Performs SIP User Agent functions on behalf of the ICS UE for IMS voice sessions established using CS voice bearers.

§ The RUA uses the information received from the CAAF for initiation and control of SIP sessions.

§ The ICS User Agent (IUA) function provides SIP UA behavior on behalf of the UE for setup and control of for IMS sessions using CS bearers that are established with or without the use of Gm (via SIP) or I1 (via USSD) between the ICS UE and the SCC AS.

§ For IMS sessions established using Gm or I1 between the ICS UE and the SCC AS, the IUA combines the service control signalling with the description of the bearer, e.g. SDP, established via the CS access to present a standard IMS session on behalf of the UE.

Combines the CS call established between the UE and the RUA to set up a voice bearer

§ UE Leg: Enables the completion of the call leg towards the UE - as the "UE Leg"

§ RUA Leg: Presents the session through the S-CSCF toward the other party, on a call leg - as the " RUA Leg "

§ The TAS (MMTel) and other Application Servers are executed on the RUA Leg as part of standard service execution logic at the S-CSCF. (Same IMS procedure as MMTel in 3GPP)

§ The UE Leg and the RUA Leg form a B2BUA at the RUA

6.3C). Terminating Access Domain Selection (T-ADS):

§ T-ADS: New Enhancement in R9

Terminating Access Domain Selection (T-ADS) provides:

§ Directs an incoming session to an ICS User;

§ For one or more UEs of an ICS User (multiple UEs allowed)

§ Influences the selection of one or more contacts amongst the registered contacts and;

§ Influences the selection of an access network for delivery of the incoming session to the selected contact,

§ Performs breakout to the CS Domain by fetching the CSRN.

§ The T-ADS has two functions, the selection function and the execution function.

§ The selection and execution function of the T-ADS are provided by the same AS.

§ The execution function of the T-ADS is in the last IMS application server in the terminating iFC.

§ For a network requiring T-ADS but which does not implement the ICCF, the last AS is not specified (one candidate is MMSC AS).

UE T-ADS:

The UE may assist the T-ADS. The UE assisted T-ADS (UE T-ADS), based on configuration that takes into account operator policy and local access network capabilities, performs the following:

§ Detect media that is candidate for delivery over the CS domain associated with an incoming INVITE,

§ Identify the domain in which the session is to be established (CS or PS).

§ Determines the mechanism to complete the establishment (origination or termination) - applicable to sessions to be established in the CS domain only.

§ Notifies the SCC AS of the mechanism the establishment will be completed on - if possible.

§ When T-ADS-IMS selects the IMS access (e.g. selected I1-ps or just using IP-CAN) to deliver the termination session, the T-ADS in the UE (UE T-ADS) can indicate to the T-ADS-IMS whether voice session should be delivered via CS access and whether I1-ps or I1-cs should be used for continuing the session setup.

UE T-ADS may use the following information to determine the response to T-ADS-IMS.

§ ICS capable IMS network.

§ Access network currently on.

§ User preference and Operator policy.

§ Any other information that the UE can be used to determine the media capabilities of the IP-CAN.

6.3D). Remote Provisioning Client (RPC) in R8

§ The Remote Provisioning Client (RPC) is an ICCF internal adaptation function for the communication setting modifications signalling between CS domain and IMS.

§ The RPC conveys communication setting modifications information received from the ICS UE over CS access signalling to the TAS (MMTel) via I5 interface.

§ The settings to be modified are defined by as part of the definition of current IMS procedures (e.g. MMTel for standardized supplementary services).

6.4). FE: TAS for ICS

§ The TAS shall allow an ICS User to manipulate the communication service settings using only one of the following mechanisms:

- communication service settings via the MSC Server enhanced for ICS (via I3)

- communication service settings directly from the UE (via Ut)

7). ICS Reference Architectures (ICCC, I1-cs, I1-ps and ICCF)

7.1). The IMS CS Control Channel (ICCC) (I1-cs and I1-ps):

Two different methods of call control have been documented for initiation of ICS UE sessions established using CS bearers:

§ Method 1: Using ICCC (either ICCC-ps: SIP with I1-ps or ICCC-cs: ICCP/USSD with I1-cs)

§ Method 2: Using CAMEL based redirection to IMS

§ Such mid-call services are e.g. conferencing, call transfer, call hold and resume, that in GSM (global system for mobile communication) are executed in the CS domain in a VMSC (visited mobile switching center), but in the ICS system, these should be executed in the IMS as instead.

§ For this purpose, the ICS has described two main solutions, I1-cs and I1-ps, that are protocol alternatives what a so-called ICS UE can use to control the IMS services while engaged to a CS call.

§ The ICCC between the UE and the ICCF can in principle be established

§ Established over CS domain network, or over GPRS

ICCC-cs (I1-cs):

o A new IMS CS Call Control Protocol (ICCP) on top of USSD when using GSM CS networks.

o Transport mechanism for I1-cs is USSD

o over the CS domain network is referred to as I1-cs

ICCC-ps (I1-ps):

o SIP transport when using GPRS EDGE capable of DTM, or UMTS networks.

o Transport mechanism for I1-ps is a PS bearer.

o over the PS domain is referred to as I1-ps.

§ This is a logical control channel, established between the UE and an IMS network element for establishment and/or service control of IMS sessions using CS voice bearers

§ ICCC only applies to MMTel services.

§ An implicit call control signalling channel (ICCC) used to transport call control signalling between the ICS UE or L-CAAF-n and the IMS when accessing IMS services via the CS domain

§ IP connectivity is needed between the L-CAAF-n and ICCF for the support of ICCC.

§ For I1-cs, the USSD transport mechanism does not offer as much bandwidth as the PS bearer so when using the USSD transport mechanism the limited bandwidth has to be taken into account and a suitable IMS CS Control Protocol (ICCP) is required.

7.2). Information Exchange between the ICS UE and the ICCF

§ This may be achieved by using a new SIP event package or USSD exchange between the ICS UE and the ICCF. The following information is exchange:

o UE's ICS capability.

o ICCC capability of the HPLMN and VPLMN - type of ICCC expected for use with the current network attachment.

§ ICS UE shall be able to learn whether both HPLMN and the VPLMN supports ICCC; i.e. whether I1-ps and/or I1-cs (type) or neither are supported.

§ UE needs this information e.g. to determine whether it should use the ICCC in call initiations

§ Non-ICS UE does not need to learn the home or visited network support for ICS.

§ ICS UE could establish a circuit switch data connection and run Ut over it.

7.3). IMS CS Control Function (ICCF)

IMS CS Control Function (ICCF) provides functions necessary

§ for provision of IMS services for calls originated or terminated over CS access networks,

§ for calls transferred between CS and PS access networks

§ for communication services setting modifications over I1-cs.

§ ICCF capability can merge / split two SIP sessions in the case of I1-ps on its own, namely the SIP session over the session control signalling path via PS access and the SIP session for the bearer control signalling path

§ Communicate parameters required to identify sessions for domain transfer / session transfer between the ICS UE and ICCF using either I1-ps or I1-cs

§ ICCF is invoked as the first SIP AS in the originating call and the last one in terminating calls

§ ICCF needs to be ensured that the AS implementing DTF of VCC Application is either second for originating calls or second last for terminating calls.

7.4). Service Control Signalling Path and Bearer Control Signalling Path on (SCC AS) ICS

§ A Service Control Signalling Path is used to transport service control signalling between the ICS UE and the SCC AS, for enabling IMS services when using CS or PS access.

§ For ICS UE sessions, the SCC AS combines the service control signalling received over the Service Control Signalling Path with the description of the bearer established via the CS network to present an IMS session on behalf of the UE.

§ The service control signalling elements from Gm / I1 such as A party address shall be used together with the bearer description signalling received via CS bearer control signalling path to construct the signalling for the remote leg.

7.5). Reference Architecture: IMS CS Control Function (ICCF) for ICS-UE

§ The CAAF is not employed in the ICCF and the ICS-UE when the I1-ps is used.

§ The CAAF and RUA in the ICCF are required for this scenario

§ ICCF provides functions necessary for provision of IMS services for calls established over CS access networks and for calls transferred between CS and PS access networks.

§ ICCF is realized with an ISC interface (I2) to S-CSCF for both I1-cs and I1-ps.

7.6). Reference Architecture: IMS CS Control Function (ICCF) for Non-ICS-UE

§ Solution for non-ICS enabled (‘Legacy’) UEs

§ RUA provides SIP UA behavior for the UE using 3GPP Rel-07 VCC techniques

o Standard CS call control procedures used for setup of CS sessions CAMEL used for redirection of the CS sessions to IMS.

o SIP used for call control with the RUA providing SIP UA behavior on behalf of the UE for control of user sessions.

§ New HSS based mechanisms for call independent aspects such as interworking/alignment of supplementary services data across CS domain and IMS.

7.7). ICCC-ps: I1-ps solution for DTM capable GPRS EDGE and UMTS networks

§ Figure: http://docs.google.com/View?id=ddh56dhg_323fknw8vf3

§ ICCF is invoked as the first SIP AS in the originating call and the last one in terminating calls

§ ICCF needs to be ensured that the AS implementing DTF of VCC Application is either second for originating calls or second last for terminating calls.

§ 1a. UE establishes a SIP session for Session (Service) Control Signalling in IMS ICCF inserted in session path by iFC execution

§ 1b. UE sets up Bearer Control Signaling Session to establish the CS bearer

§ 2. ICCF Combines both service control signaling and bearer control sessions, invokes RUA (B2BUA) to present the combines session to S-CSCF; originating service execution at S-CSCF

§ The Gm reference point is used to realize the I1 reference point with use of 3GPP SIP signalling for registration and session control.

§ The ISC interface and the Ma reference point are used for PSI routing to the ICCF to establish voice bearer via the CS domain.

§ The ISC interface is used for realization of the I2 (SIP) reference point.

§ The Ut reference point is used for communication services setting modifications.

ICS UE session signalling and bearer path using Gm (SIP) over PS network for Service Control Signalling Path

§ The signalling and bearer paths established by the ICS UE are combined at the SCC AS when the Service Control Signalling Path is established via the PS network using the Gm reference point.

§ Upon session initiation, the ICS UE or the SCC AS establishes the Service Control Signalling Path for communication of service control signalling via the PS network using the Gm (via SIP) reference point.

§ The ICS UE also sets up the CS Bearer Control Signalling Path using standard CS network procedures to establish the circuit media.

§ The SCC AS combines the service control signalling received over the Service Control Signalling Path with the description of the bearer established using the CS Bearer Control Signalling Path by acting as a B2BUA as below:

o Access Leg: The Access Leg is formed with a combination of the Service Control Signalling Path and the CS Bearer Control Signalling Path.

o Remote Leg: The Remote Leg is presented by the SCC AS to the CSCF as an IMS session using IMS SIP signalling on behalf of the UE.

§ The TAS and other Application Servers are executed on the Remote Leg as part of standard service execution logic at the CSCF.

§ The SIP UA at the UE maintains the SIP/SDP state machine with the SCC AS also maintaining a copy of the state data.

7.8). ICCC-cs: I1-cs solution for non-PS GSM access networks:

§ Figure: http://docs.google.com/View?id=ddh56dhg_3195ww7t8c6

§ The A/Iu interface as well as the gsmSCF-HLR interface is used to realize the I1 reference point with use of USSD transport to carry information required to generate IMS signalling at the ICCF.

I1-cs approach: The ISC interface and the Ma reference point are used for PSI routing to the ICCF to establish voice bearer via the CS domain.

ICS UE session signalling and bearer path using I1 (via USSD) over CS network for Service Control Signalling Path

§ The signalling and bearer paths established by the UE are combined at the SCC AS when the Service Control Signalling Path is established via the CS network using the I1 (via USSD) reference point

§ Upon session initiation, the ICS UE or the SCC AS establishes the Service Control Signalling Path for communication of service control signalling via the CS network using the I1 (USSD) reference point.

§ In parallel, the ICS UE or the SCC AS sets up the CS Bearer Control Signalling Path using standard CS network procedures to establish the circuit media.

§ The SCC AS combines the Service Control Signalling Path with the bearer established using the CS Bearer Control Signalling Path by acting as a B2BUA as described above for the case of Service Control Signalling Path established via the PS network

7.9). Non-ICS UE Session signalling and bearer path using CS call control

§ The signalling and bearer paths for sessions are established using standard CS call control procedures and MSC Server.

§ Figure: http://docs.google.com/View?id=ddh56dhg_3214ptcbkd9

§ Upon session initiation, the UE or the remote end sets up a call and the call is directed to IMS using standard CS procedures; IN (e.g. CAMEL) triggers are used to redirect CS originated calls to IMS.

§ The SCC AS acts a B2BUA for presentation of the UA behavior on behalf of the UE to IMS.

§ The TAS and other Application Servers are executed on the Remote Leg as part of standard service execution logic at the CSCF