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.

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 [34]. 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;
• Location update;
• 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.

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.

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.

Network selection procedures are defined in TS 22.011. Other procedures may be offered by the UE.

Security matters are considered in TS 21.133 and TS 33.120.