The following general requirements are applicable to CSI:
The solution is applicable to GERAN and UTRAN;
A CSI capable UE requires DTM capability (in case of GERAN access) and MultiRAB capability (in case of UTRAN access);
IMS networks and IMS UEs without CSI support should not be impacted;
CS core, PS core, xRAN are not to be impacted. Conclusively, changes should be restricted to the IMS elements and the UEs that support CSI for IMS;
Procedures connecting the IMS to the CS domain, to the PSTN and to other SIP networks, including other IMS networks should remain unchanged;
CS only UEs and PS only UEs are not to be impacted;
CSI capable UE provides capabilities to associate the corresponding peer-to-peer CS and IMS communication to present it within one context for the user. The IMS communication may be peer-to-peer session or session unrelated communication, e.g. IMS immediate messaging;
The quality of the CS call (e.g. voice quality, setup delay, handover, etc.) shall not be impacted from a user perception point of view regardless of whether the CS call is combined with an IMS session or not;
The use of CSI requires that the UE is CS attached, PS attached and IMS registered;
The solution shall be transparent for the end-user;
Existing security mechanisms for CS and IMS shall be re-used;
For network efficiency, the UE capability exchange functionality requires the terminal to store information about the other terminals' capabilities;
Functionality is required to handle remote parties who use more than one device (e.g. with the same MSISDN or the same public user ID).
The same MSISDN should be used for the users IMS subscription and their CS subscription. The system behaviour is not specified for the case where the MSISDN for the IMS subscription and the CS subscription are different.
If the UE is not IMS registered and gets engaged in a CS call, then the UE should make an IMS registration using a Public User Identity causing the MSISDN used in the CS call to be implicitly registered.
The following general requirements are applicable to multimedia sessions between UEs that use IMS origination and UEs that use CSI termination:
It shall be possible to interwork between IMS origination and CSI termination for sessions that include a real-time (e.g. voice) components.
There shall be no requirement to maintain time synchronization between media transferred over different domains.
The terminating CS domain and the originating IMS domain shall not to be impacted.
The impact on UE behaviour relating to the origination and termination of IMS sessions shall be minimized.
The impact on UE behaviour relating to the origination and termination of CS calls shall be minimized.
A CSI-capable UE shall have logic to trigger the capability and identity exchange required for simultaneous communication on the CS and IMS domains. Further, the logic shall be able to co-ordinate current activities in the UE , the user preferences, whether support for simultaneous CS and PS access is available and available IMS enablers in such a way, that only those services/enablers are offered to a user, which can be used simultaneously. This logic shall function in such a way that it makes the simultaneous usage of the CS and IMS domains for the media flows as transparent as possible for the user.
For the scenario of a CS call and an IMS session being established at the same time from an end user perspective, an IMS session can be setup first followed by adding a CS call to the IMS session using the call-flow of clause 8.4, or a CS call can be setup first followed by adding the IMS session to the CS call using the call-flow of clause 8.3.