This clause defines the functional characteristics and requirements of the User Service Identity Module (USIM) and ISIM (IM Services Identity Module). The USIM/ISIM are applications residing on a UICC.
Every USIM shall have a unique identity and shall be associated with one and only one home environment.
It shall be possible for a home environment to uniquely identify a user by the USIM.
The USIM shall be used to provide security features.
For access to services, provided by PS or CS CN domains, a valid USIM shall be required. Optionally, SIM according to GSM phase 2, GSM phase 2+, 3GPP release 99, 3GPP release 4 specifications may be supported.
The USIM shall be able to support SIM Application Toolkit as specified in TS 22.038.
The USIM shall reside on a UICC. USIM specific information shall be protected against unauthorised access or alteration.
It shall be possible to update USIM specific information via the radio interface, in a secure manner.
Access to the IMS services shall be possible using the USIM application in the event of no ISIM being present on the UICC. If an ISIM is present on the UICC it shall be used to access the IMS.
It shall be possible to store provisioning parameters on the USIM according to DM specifications .
It should be possible to store provisioning parameters on the USIM according to CP specifications .
It shall be possible for the network operator to configure the USIM to indicate (through personalisation and OTA) whether provisioning parameters according to DM specifications or provisioning parameters according to CP specifications shall be used.
Annex A describes a number of features that may optionally be supported by the UE and thus USIM.
It shall be possible for a user to be associated with one or a number of user profiles, which the user can select and activate on a per call basis. The user profile contains information which may be used to personalise services for the user.
It shall be possible for one or more user profiles associated with the same user to be active simultaneously so that the user may make or receive calls associated with different profiles simultaneously. Activation of profiles shall be done in a secure manner, for example with the use of a PIN.
For terminating calls the correct profile shall be indicated by the user address used (e.g. MSISDN, SIP URI), each profile will have at least one unique user address associated with it. For originating calls the user shall be able to choose from the available profiles, the appropriate one for the call. A profile identity will need to be associated with the call for accounting and billing purposes. User profile identities need not be standardised but a standardised means is required for indicating that a particular profile is being used.
Simultaneous use of the same user profile on multiple terminals for the same type of service shall not be allowed.
User profiles associated with different home environments shall not share the same user address.
The standard shall support more than one USIM per UICC even when those USIMs are associated with different home environments. Only one of the USIMs or the SIM shall be active at a given time. While the UE is in idle mode, it shall be possible for the user to select/reselect one USIM application amongst those available on the UICC. At switch on, the Last Active USIM shall be automatically selected. The Last Active USIM shall be stored on the UICC. By default if there is no Last Active USIM defined in the UICC, the user shall be able to select the active USIM amongst those available on the UICC.
The standard must not prevent the coexistence of USIM applications, each associated with different home environments on the same UICC, so long as the security problems which arise from such a coexistence are solved.
Access to the IMS services shall be possible using an ISIM application.
The ISIM shall be sufficient for providing the necessary security features for the IMS and IMS only.
The ISIM shall reside on a UICC. ISIM specific information shall be protected against unauthorised access or alteration.
It shall be possible to update ISIM specific information via the radio interface, in a secure manner.
It shall be possible for the UICC to host other applications in addition to the USIM or ISIM, see Figure 3. Service providers, subscribers or users may need to establish additional data or processes on the UICC. Each application on an UICC shall reside in its own domain (physical or logical). It shall be possible to manage each application on the card separately. The security and operation of an application in any domain shall not be compromised by an application running in a different domain. Applications may need to use their own security mechanisms which are separate to those specified by 3GPP e.g. electronic commerce applications.
Examples of UICC applications are: USIM, ISIM, off-line user applications like UPT, electronic banking, credit service, etc.
Applications should be able to share some information such as a common address book.
It shall be possible to address applications, which reside on the UICC, via the radio interface.
An optional "high speed" interface may be provided between the UICC and the ME.
If provided, this interface shall allow fast access and retrieval of data to support functionalities requiring large amounts of data to be transferred to and from the UICC. Examples include:
on-card web servers
rapid access to data stored on the UICC, e.g. phone book, PLMN lists or user data
A UICC/ME interface supporting this "high speed" interface shall be backward compatible with the TS 102 221 interface specified in TS 31.101.
A single terminal may support the use of multiple UICC (e.g. with applications like USIM and/or banking, credit card,...). Only one UICC shall be active at a time to access a PLMN. In case the active UICC contains more than one USIM, the requirements of clause 13.1.4 shall apply.
If the UICC with the active USIM is removed from the mobile terminal during a call (except for emergency calls), the call shall be terminated immediately. If the UICC with an active ISIM is removed during an IMS session the IMS session shall be terminated.
With the growing demand in the consumer market, some commercially deployed UEs support more than one USIM (typically two). With support of MUSIM UEs in the 3GPP system, the system performance and user experiences are expected to be improved.
The 3GPP system shall support ME with multiple USIMs (on the same UICC or on different UICCs) that are registered at the same time.
The 3GPP system shall treat each registration from the USIMs of a MUSIM UE independently. Each registered USIM in a MUSIM UE shall be associated with a dedicated IMEI/PEI.
3GPP specifications should support a wide variety of user equipment, i.e. setting any limitations on terminals should be avoided as much as possible. For example user equipment like hand-portable phones, personal digital assistants and laptop computers can clearly be seen as likely terminals.
In order not to limit the possible types of user equipment they are not standardised. The UE types could be categorised by their service capabilities rather than by their physical characteristics. Typical examples are speech only UE, narrowband data UE, wideband data UE, data and speech UE, etc.
In order to enhance functionality split and modularity inside the user equipment the interfaces of UE should be identified. Interfaces like UICC-interface, PCMCIA-interface and other PC-interfaces, including software interfaces, should be covered by references to the applicable interface standards.
UEs have to be capable of supporting a wide variety of teleservices, multimedia services and applications provided in PLMN environment. Limitations may exist on UEs capability to support all possible teleservices, multimedia services and information types (speech, narrowband data, wideband data, video, etc.) and therefore functionality to indicate capabilities of a UE shall be specified.
The basic mandatory UE requirements are:
Support for USIM. Optional support of GSM phase 2, 2+, 3GPP Release 99 and Release 4 SIM cards . Phase 1, 5V SIM cards shall not be supported. Support for the SIM/ISIM is optional for the UE, however, if it is supported, the mandatory requirements for SIM/ISIM shall be supported in the UE;
Home environment and serving network registration and deregistration;
Originating or receiving a connection oriented or a connectionless service;
An unalterable equipment identification; IMEI, see TS 22.016;
Basic identification of the terminal capabilities related to services such as; the support for software downloading, application execution environment/interface, MExE terminal class, supported bearer services.
Terminals capable for emergency calls shall support emergency call without a SIM/USIM/ISIM.
Support for the execution of algorithms required for encryption, for CS and PS services. Support for non encrypted mode is required;
Support for the method of handling automatic calling repeat attempt restrictions as specified in TS 22.001;
At least one capability type shall be standardised for mobile terminals supporting the GERAN,UTRAN and E-UTRAN radio interfaces.
Under emergency situations, it may be desirable for the operator to prevent UE users from making access attempts (including emergency call attempts) or responding to pages in specified areas of a network, see TS 22.011;
Ciphering Indicator for terminals with a suitable display;
The ciphering indicator feature allows the UE to detect that the 3GPP radio interface ciphering (user plane) is not switched on and to indicate this to the user. The ciphering indicator feature may be disabled by the home network operator setting data in the SIM/USIM. The default terminal behaviour shall be to take into account the operator setting data in the SIM/USIM. However, terminals with a user interface that can allow it, shall offer the possibility for the user to configure the terminal to ignore the operator setting data in the SIM/USIM. If this feature is not disabled by the SIM/USIM or if the terminal has been configured to ignore the operator setting data in the SIM/USIM, then whenever a user plane connection is in place, which is, or becomes un-enciphered, an indication shall be given to the user. In addition, if this feature is not disabled by the SIM/USIM or if the terminal has been configured to ignore the operator setting data in the SIM/USIM, then additional information may also be provided about the status of the ciphering. Ciphering itself is unaffected by this feature, and the user can choose how to proceed;
Support for PLMN selection.
Support for handling of interactions between toolkits concerning the access to UE MMI input/output capabilities;
Whenever an application (e.g. a SAT/MExE/WAP application) requires the access to the UE MMI input/output capabilities (e.g. display, keyboard,… ), the UE shall grant this access subject to the capabilities of the UE. This shall not cause the termination of any other applications (e.g. WAP browser or MExE/SAT application) which were previously using these UE resources. The UE shall give the user the ability to accept or reject the new application. In the case that the application request is rejected, the access to the UE MMI input/output capabilities is returned to the applications which were previously using these UE resources. If the user decides to continue with the new application, then when this new application is terminated, the access to the UE MMI input/output capabilities shall be returned to the UE to be re-allocated to applications (e.g. the preceding application which was interrupted). Subject to the capabilities of the UE, the user shall have the ability to switch the MMI input/output capabilities between applications.
Annex A describes a number of features which may optionally be supported by the UE.
A subscription to a network operator may provide the user with access to one or more domains. A Subscription shall identify the set of services, within particular domains, to which the user has access (see Figure 4); each subscription may specify a different set of services. These services may be provided by the CS CN Domain and/or a PS CN Domain and/or an IM CN subsystem. Subscriptions relate to services such as Basic Services (e.g. Teleservices, Bearer services), PS services and IM-Services (IP-based multimedia services), which are typically provided by network operators, and to value added services which typically are provided by network operators and/or other entities that provide services to a subscriber
The subscription identifies:
the services and related services information that are made available to the subscriber by the service provider ;
In addition, a subscription to a network operator may identify:
the domains to which the user has been granted access by the network operator. In particular, the PS service profile and information on the allowed QoS parameter ranges shall be contained in the subscription.
the identity of the subscriber within these domains.
the radio access systems over which the subscriber may access their services e.g. UTRAN, GERAN, EUTRAN, I-WLAN.
In general, it is a requirement to allow the use of independent services simultaneously (i.e. Basic, PS, IP multimedia and operator specific).
The network usage shall be based on the services identified within the subscription, the terminal capabilities and, where applicable, roaming agreements between operators.
The Home environment shall be able to decide on the service delivery in a roaming scenario. I.e. it shall control how services are delivered in line with the subscription.
If an offered or required service (e.g. voice) could be provided with different technologies within the serving network, the decision on service delivery shall be based on preferences identified in the user profile and serving network capabilities and conditions (e.g. load).
If the user profile does not allow an alternative service delivery method and the requested delivery method is not available in the serving network the service shall not be provided to the subscriber. This applies also to data bearer services with defined QoS parameters (or parameter ranges).
A terminating voice call for a subscriber with a dual/multi mode terminal (e.g. UTRAN/GERAN) could be delivered in a hybrid network as IM service or CS voice call (TS11). The delivery decision is based on the preferences of service delivery within the user profile and the network conditions. If there is no preference information of the Home environment available the decision is made only on the network conditions from the serving network.
A terminating data service (e.g. PS with QoS for real time audio) where the network cannot provide the QoS at call setup. Both the originating and terminating application shall be informed about the possible QoS configuration for that call. The further handling (setup continuation, termination) depends on the decisions of the applications.
When a ME capable of offering voice service both on CS and IMS is CS attached and IMS registered MO CS Voice calls (TS11) and MO IMS voice services shall be originated on the domain specified by the Home operator policy or users preferences. The Home Operator policy shall have precedence to user preferences.
When a ME capable of offering voice service both on CS and IMS, MT CS Voice calls (TS11) and MT IMS voice services shall be delivered over the domain specified by the Home operator policy or users preferences. The Home Operator policy shall have precedence to user preferences. If the call delivery attempt fails in one domain, if specified by operator policy, it should be possible to attempt the delivery in the other domain or the call/communication forwarding supplementary services ,  may be invoked if provisioned.
The cost of the call may cover the cost of sending, transporting, delivery and storage. The cost of call related signalling may also be included. Provision shall be made for charging based on time, destination, location, volume, bandwidth, access technology and quality. Charges may also be levied as a result of the use of value-added services.
It shall be possible for information relating to chargeable events to be made available to the home environment at short notice. The requirements shall include:
Immediately after a chargeable event is completed;
At regular intervals of time, volume or charge during a chargeable event.
Delivery of the location of the terminal to the home environment, e.g. cell identification;
Standardised mechanisms of transferring charging information are required to make these requirements possible.
It should be possible for multiple leg calls (e.g. forwarded, conference or roamed) to be charged to each party as if each leg was separately initiated. However, in certain types of call, the originating party may wish/be obliged to pay for other legs (e.g. SMS MO may also pay for the MT leg.).
It shall be possible to charge according to the location (e.g. cell, or zone) and access technology that are being used to access network services.
Provision shall be made for the chargeable party to be changed during the life of the call. There shall be a flexible billing mechanism which may include the use of stored value cards, credit cards or similar devices.
The chargeable party (normally the calling party) shall be provided with an indication of the charges to be levied (e.g. via the called number automatically or the Advice of Charge supplementary service) for the duration of the call (even though the user may change service environment)The user shall be able to make decisions about the acceptable level of accumulated charge dynamically or through their service profile.
If a user is to be charged for accepting a call then their consent should be obtained. This may be done dynamically or through their service profile.
Charging and accounting solutions shall support the shared network architecture so that end users can be appropriately charged for their usage of the shared network, and network sharing partners can be allocated their share of the costs of the shared network resources.
The personalised services & capabilities available in a visited network are dependent upon the subscription options in the home environment. This does not preclude the visited network offering additional services, or access to content providers.
Roaming from this release's home environment to CS (this release or earlier) visited network is required
Roaming from this release's home environment to IM CN subsystem visited network is required
Roaming from this release's home environment to PS (this release or earlier) visited network is required
Roaming from previous releases' home environment (or earlier) to this release CS visited network is required
Roaming from previous releases' home environment (or earlier) to this release PS visited network is required
Any handover required to maintain an active service while a user is mobile within the coverage area of a given network, shall be seamless from the user's perspective. However handovers that occur between different radio environments may result in a change of the quality of service experienced by the user.
It shall be possible for users to be handed over between different networks subject to appropriate roaming/commercial agreements.
For further information see TS 22.129.