Content for TS 22.101 Word version: 18.4.0
21 Voice Call Continuity
22 IMS Centralized Services
23 CS IP interconnection requirements
24 Service Alignment & Migration
25 System optimisation for communication with specific characteristics
26 Single Sign-On (SSO) Service
...
...
21 Voice Call Continuity |R7| p. 54
21.1 General p. 54
The 3GPP system shall be able to provide continuity between CS voice services (Teleservice 11 [14]) and the full duplex speech component of IMS multimedia telephony service [40] with no negative impact upon the user's experience of the voice service. This functionality is known as voice call continuity. Voice call continuity shall be executed when continuation of a voice service is required based on operator policy across a change in the connection of the UE to the 3GPP system as the user moves from using the CS domain to using IMS and vice versa.
The user experience shall be unaffected by the transition from a CS voice service to a full duplex speech component of IMS multimedia telephony and vice versa, and the user shall experience no disruption in the voice service provided. The voice service is continued with the same ME.
It shall be possible to support Voice call continuity between IMS and the CS domain belonging to different operators; i.e., when the user's IMS services are under the control of the home IMS and the user is roaming in the coverage of the visited CS network.
It shall be possible for an operator to enable or disable Voice call continuity for a given subscriber e.g. based on roaming conditions, terminal capabilities.
21.2 Support of Supplementary Services p. 54
The voice call continuity user's experience shall be such that, to the greatest degree possible, a consistency of service is provided regardless of the underlying communication infrastructure and technology. With regard to supplementary services, the general principle is that CS-based supplementary services only apply whilst a VCC subscriber is in the CS domain and equivalent services over IMS only apply whilst a VCC subscriber is in the IMS domain, although there are exceptions listed below. It is not required to synchronise the supplementary service settings of the CS domain with the related service settings of the IMS (e.g. different forwarding numbers may apply over CS and over IMS).
The following supplementary services apply. The impact on the supplementary services in case the VCC is executed for the calling party, the called party, or both is described below.
21.2.1 Line Identification Services p. 54
A user who has subscribed to the CLIP Supplementary Service and receives a call shall also receive the line identity or appropriate IMS information of the calling party.
The identity presentation is not changed for the duration of the call regardless of whether the call undergoes VCC.
If the CLIR Supplementary Service or IMS identity restriction is applicable to the call, then at call setup time the called user shall receive an indication that the identity is not available because of restriction.
The indication is not changed for the duration of the call regardless of whether the call undergoes VCC.
If COLP or a corresponding IMS service is applicable to a call the calling subscriber shall receive the connected line identity or appropriate IMS information at call setup time.
The identity presentation is not changed for the duration of the call regardless of whether the call undergoes VCC.
If the COLR Supplementary Service or IMS identity restriction is applicable to the call, then the calling user shall receive an indication at call setup time that the identity of the connected party is not available because of restriction.
The indication is not changed for the duration of the call regardless of whether the call undergoes VCC.
21.2.2 All Call Forwardings p. 54
It shall be possible to perform VCC on a call which was forwarded due to call forwarding supplementary services in the CS or redirecting services in the IMS.
21.2.3 Call Waiting p. 55
The functionality of call waiting supplementary service in the CS domain shall not be affected by the user's ability to undergo VCC.
21.2.4 Call Hold |R8| p. 55
It shall be possible to re-establish a call which has been put on hold before undergoing VCC, after the VCC has been performed.
21.2.5 Multiparty p. 55
It shall be possible for any party in a multiparty call to undergo VCC and to stay in the call. It shall be possible to terminate the entire multiparty call when the served mobile subscriber releases even if she is connected via the IMS after undergoing VCC.
21.2.6 All Call Barrings p. 55
If a call were to undergo VCC and that would result in the call being barred in the target domain/system, it shall be up to the home operator policy whether the call continues in the target domain/system, the call terminates, or VCC is not executed for the call.
21.2.7 Void
21.2.8 Void
21.2.9 All other Supplementary Services p. 55
Other supplementary services are not discussed in this section as they do not apply to calls in progress (i.e. they apply to call set up only) or their support and/or the need for standardised implementation has not been identified as critical for VCC in this Release.
21.3 Quality of Service p. 55
Voice call continuity shall not adversely impact the quality of the voice service experienced by the user.
21.4 Security p. 55
Voice call continuity shall not adversely impact the security of the 3GPP system.
Security mechanisms of the 3GPP system shall be reused for voice call continuity.
21.5 Emergency calls p. 55
Voice call continuity for emergency calls shall be applicable to dual radio and single radio UEs.
Voice call continuity of emergency calls shall only be performed when all the following conditions are met:
- the source network is IMS;
- the target network supports emergency calls;
- the user is moving out of coverage;
- the source and target network belong to the same operator;
- the target network supports voice call continuity.
21.6 Charging p. 56
It shall be possible to indicate in the charging information that a VCC event has occurred (e.g., so that appropriate ratings can be applied for the CS and IMS parts of the continued voice call).
21.7 VCC Activation p. 56
It shall be possible to activate VCC based on operator policies, taking into account any of the following:
- Radio conditions e.g. radio quality thresholds and related hysteresis
- Coverage availability e.g.: Always prefer I-WLAN, if certain SSID are available
22 IMS Centralized Services |R8| p. 57
22.1 General p. 57
The ICS user shall receive both registered and unregistered services in a consistent manner when the user accesses IMS either via the CS or the PS domain (both of which can be supported by 3GPP access networks or non-3GPP access networks). Support of UEs enhanced with ICS capability as well as UEs without ICS capability shall be possible.
22.2 Service Consistency p. 57
Subscribers shall have a consistent user experience regardless of the domain used, subject to the constraints of the UE and access network.
22.3 Service Continuity p. 57
ICS shall support service continuity between CS and PS domains (both of which can be supported by 3GPP access networks or non-3GPP access networks), subject to the constraints of the UE and access networks.
The service continuity shall include:
- Basic services
- Non mid-call services
- Mid-call services
22.4 IMS Services p. 57
The set of IMS services supported by ICS shall include at least the following, subject to the constraints of the UE and access networks:
-
IMS Multimedia Telephony services, including:
- speech,
- video,
- fax,
- data (CS),
- Supplementary services defined within [40]; and
- Multimedia priority service.
- IMS emergency calls, including eCall.
22.5 Roaming Support p. 58
An ICS user shall be able to 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).
The Home operator shall be able to control if the UE enhanced with ICS capability shall act without ICS capability while roaming.
23 CS IP interconnection requirements |R8| p. 59
23.1 Introduction p. 59
CS IP interconnect represents the interconnection of MSC Server functionality between 2 CS networks over an underlying IP infrastructure.
23.2 IP interconnect p. 59
The IP connection used for CS IP interconnect shall be generic such that it can support all combinations of core network interconnection. E.g. the IP interconnection shall be shared between the IMS interconnection and the CS IP interconnection.
It shall be possible to handle the inter-connection of all services over this generic IP interface. The handling of security and charging shall also be generic for all IP interconnect scenarios.
23.3 MSC server interconnect p. 59
The following requirements apply at the interconnection point when two PLMNs are interconnected by means of IP transport technology for 2G and 3G CS services.
The system shall support the capability for CS service interoperability and interworking.
It shall be possible to apply operator defined policy at the interconnection point.
The system shall support the capability to control the session resources when two different network domains are connected that may have, for example, different IP addressing schemes.
The system shall support IP inter-connection between core networks either by direct connection or by using an intermediate carrier (e.g. GSMA IPX [43]).
The system shall support both bilateral interconnection between two carriers and multilateral interconnection (e.g. GSMA IPX [43]) by means of intermediate carrier.
The system shall support either
- transparent relay of the IP signalling and traffic;
- service aware interconnection
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.
