Content for TS 22.101 Word version: 18.6.0
24 Service Alignment & Migration
24.1 Introduction
24.2 Alignment of supplementary services settings
25 System optimisation for communication with specific characteristics
25.2 Numbering Resource Efficiency
25.3 Network provided destination for uplink data
25.4 PS only subscriptions
26 Single Sign-On (SSO) Service
26.1 Requirements
26.1.1 Requirements for the UE
26.1.2 Requirements for a 3GPP SSO Service
...
...
24 Service Alignment & Migration |R9| p. 60
24.1 Introduction p. 60
Services can be offered to the users via different service domains, e.g. certain teleservices and supplementary services via CS or Multimedia Telephony and supplementary services via IMS. Especially for the supplementary services given below a strong relationship exists from the user's point of view. Therefore means shall be provided to enable a consistent user experience when changing from one service domain to the other.
The requirements in this clause are applicable during the migration to an ICS. The ability to synchronise the service settings will facilitate the migration from a CS to an IMS based network and will allow network operators maximum flexibility in their migration strategies.
24.2 Alignment of supplementary services settings p. 60
Based on user preferences and if provisioned by the home operator the network shall automatically synchronise the parameter settings of the supplementary services listed in the following table:
| CS Voice (TS11) Supplementary Services | Equivalent Multimedia Telephony Services in IMS domain | Service Behaviour Required |
|---|---|---|
| CLIP/CLIR | OIP/OIR | Consistency of presentation |
| CoLP/CoLR | TIP/TIR | Consistency of presentation |
| CNAP | OIP/OIR | Consistency of presentation |
| Call Forwarding | CDIV | Call forwarding/CDIV shall work consistently no matter which domain the user is in. The settings (e.g. forwarding numbers) shall remain the same across domains for all the parts of the service for which there is an equivalent. |
| Call Waiting | Communication Waiting | The busy state of the user shall be available to both domains so that this can be applied no matter from which domain an incoming call/communication originates. The activation status of Call Waiting and Communication Waiting shall be synchronised. |
| Call Hold | Communication HOLD | Any calls held in one domain shall remain held on moving to a different domain. It shall be possible to re-establish a call that was put on hold in another domain. |
| Multiparty | CONF | Any conference (multiparty) calls set up in one domain shall remain in force if any user moves to another domain. |
| Closed User Group | Closed User Group | Consistency required across domains |
| CCBS | CCBS | Consistency required across domains |
| Call Deflection | Defined in CDIV | Consistency required across domains |
| Explicit Call Transfer | ECommT | Consistency required across domains. The UE state (i.e. if busy or not) shall be available in both domains to ensure that this can be applied consistently. |
| Call Barring | Communication Barring | Call/ Communication Barring shall work consistently no matter which domain the user is in. The settings (i.e. barred numbers) shall remain the same across domains. |
| AoC | AoC | Consistent support across domains. If the user moves from one domain to the other during the communication, the AoC shall indicate the correct charge for the total duration of the communication. |
The operator shall be able to provision the user with the possibility to define which of the above settings shall be synchronised automatically and which settings can exist independently of each other. E.g. a user might decide that the activation status of CLIP/OIP, CLIR/OIR, Call Waiting/Communication Waiting etc. is synchronised but that the call forwarding status and forwarded-to-number is different from the communication diversion settings and the diverted-to-party address.
If the synchronisation of supplementary services, which use the UE's busy state for invocation, is activated the busy state of the UE shall be available in both domains.
Synchronisation of settings means that the most recent changes which have been applied in one domain are propagated to the other domain.
There are certain circumstances under which the synchronisation will fail e.g. when a user inserts a SIP URI as diverted-to-party address in the IMS domain which has no Tel URI associated with it. In such a case there is no valid setting for the CS domain for this particular parameter and therefore the CS domain service setting shall remain unchanged. The user may receive a notification about the failure of the synchronisation procedure and its cause.
25 System optimisation for communication with specific characteristics |R11| p. 62
25.1 Void
25.2 Numbering Resource Efficiency p. 62
The following optional requirement is intended to provide better numbering resource efficiency for UEs that only require packet switched services.
- A network operator shall be able to provide PS only subscriptions with or without assigning an MSISDN.
- Remote triggering shall be supported with or without assigning an MSISDN.
- Remote UE configuration shall be supported without the use of an MSISDN.
25.3 Network provided destination for uplink data p. 62
The Network Provided Destination for Uplink Data feature is intended for use when all data from a UE is to be directed to a network provided destination address.
- For uplink data communication, the network shall be able to direct all uplink PS data traffic to a network provided destination address.
25.4 PS only subscriptions p. 62
The system shall support subscriptions that only allow packet-based services and SMS.
26 Single Sign-On (SSO) Service |R12| p. 63
26.1 Requirements p. 63
26.1.1 Requirements for the UE p. 63
An SSO-capable UE shall support 3GPP SSO Authentication, without user intervention, based on Operator-controlled credentials.
An SSO-capable UE shall be able to initiate the SSO Service regardless of the access network technologies supported by the UE.
An SSO-capable UE that supports 3GPP access and non-3GPP access shall support transparency of the SSO Service from a user perspective during transitions between 3GPP access and non-3GPP access, whether or not the transition occurs during a data application session.
An SSO-capable UE may support a request for SSO Local User Authentication from a Data Application Provider or an Identity Provider to confirm the presence of the registered user of the data application.
26.1.2 Requirements for a 3GPP SSO Service p. 63
The 3GPP SSO Service shall provide secure, seamless and transparent access to data applications for users of the SSO Service independent of the access network technology.
The 3GPP SSO Service shall be able to interwork with Identity Management (IdM) specifications (e.g., OpenID [51]).
The 3GPP SSO Service shall support 3GPP SSO Authentication based on Operator-controlled credentials and policies.
The 3GPP SSO Service may support negotiation and use of an agreed authentication method between the UE and the 3GPP SSO Identity Provider. The negotiation of an authentication method may be repeated each time the user accesses a DAP's service.
The 3GPP SSO Service may support mechanisms to ensure the presence of the registered user of the data application to satisfy policies of the Data Application Provider.
The 3GPP SSO Service shall be transparent from a user perspective when transitions occur between 3GPP access and non-3GPP access, whether or not the transition occurs during a data application session.
The 3GPP SSO Service shall be transparent from a user perspective when the user accesses a data application using an identity created through a 3rd Party SSO Identity Provider. The user shall be able to configure which 3rd party SSO identities are used with the 3GPP SSO Service.
