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.