Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 21.111  Word version:  18.0.0

Top   Top   Up   Prev   None
1…   9… 
9 Electrical characteristics and transmission protocols  10 Contents of the Elementary Files  10.1 USIM information storage requirements  10.2 Phone Book  10.3 Storage of call details  11 3G/GSM interworking  12 Contact Manager  12.1 General  12.2 Security requirements  $ Change history 

 

9  Electrical characteristics and transmission protocols  p. 10

Electronic signals and transmission protocols shall be in accordance with the specifications in TS 31.101.
The electrical specifications shall at least cover the 1.8V and 3V voltage ranges as specified in TS 31.101. Lower voltages may be added in the future. 3G terminals and beyond shall not support 5V on the ME-UICC interface. Both ME and UICC shall support operational class indication as defined in ISO/IEC 7816-3 [11].
UICC shall support at least two consecutive voltage classes unless it has a non removable form factor. ME shall support at least two consecutive voltage classes, unless it contains a non-removable UICC or unless it supports any of the following, or a combination of: NB-IoT, GERAN EC-GSM-IoT, Category M1 of E-UTRAN enhanced-MTC and Category 1bis as specified in TS 36.306.
An ME supporting NG-RAN and containing a removable UICC shall support at least the 1.8V voltage class, and may support a second, consecutive voltage class.
Both UICC and ME shall support PPS as defined in ISO/IEC 7816-3 [11] with at least the values defined in TS 31.101.
The ME shall have the capabilities of initiating a warm reset as defined in ISO/IEC 7816-3 [11]. The UICC shall support warm reset as defined in ISO/IEC 7816-3 [11].
The UICC may indicate in the ATR to the warm reset that the specific mode is entered automatically, using the parameters that were used prior to the warm reset. In case of a cold reset, the UICC shall enter the negotiable mode.
In addition to the T=0 protocol which is mandatory for the UICC and the ME, the T=1 protocol shall be mandatory for the ME. It is optional for the UICC.
The speed enhancement as specified in TS 31.101 shall be supported by both the ME and the UICC.
Up

9.1  Void

10  Contents of the Elementary Files  p. 11

10.1  USIM information storage requirements  p. 11

The USIM shall contain information elements for 3G network operations. The USIM may contain information elements related to the subscriber, 3G services and home environment or service provider related information.
The UICC shall provide storage capability for the following:
  • UICC related information:
    • IC card identification: a number uniquely identifying the UICC and the card issuer;
    • Preferred language(s);
    • Directory of applications.
  • USIM related information:
    • Administrative information: indicates mode of operation of the USIM, e.g. normal, type approval;
    • USIM service table: indicates which optional services are provided by the USIM;
    • IMSI;
    • Language indication;
    • Location information;
    • Cipher key (Kc) and cipher key sequence number;
    • Access control class(es);
    • Forbidden PLMNs;
    • Ciphering Key for GPRS;
    • GPRS location information;
    • Cell Broadcast related information;
    • Emergency call codes;
    • Phone numbers (ADN, FDN, SDN);
    • Short messages and related parameters;
    • Capability and Configuration parameters;
    • Higher Priority PLMN search period;
    • list of carrier frequencies to be used for cell selection.
  • Information accessible to the USIM and other applications:
    • ADN.
In addition, the USIM shall manage and provide storage for the following information in accordance with the security requirements of clause 5:
  • PIN;
  • PIN enabled/disabled indicator;
  • PIN error counter;
  • Unblock PIN;
  • Unblock PIN error counter;
  • Data integrity keys;
  • Subscriber authentication keys.
Up

10.2  Phone Book  p. 12

A Phone Book entry consists of a record in an ADN file and, optionally, additional records which are placed in different EFs. In the latter case, a mechanism shall be defined to link all records in the same Phone Book entry. These features shall be supported by the ME while their support by the UICC is optional.

10.2.1  Support of two name fields per entry  p. 12

The support of two name fields per entry shall be specified to allow, for example, for two different representations of the same name (for example, in Japanese characters and in Latin characters).

10.2.2  Support of multiple phone numbers per entry  p. 12

The support of multiple phone numbers per entry shall be specified, for example, office, home, fax, mobile or pager. In addition to that, information for identifying those attributes are needed.

10.2.3  Support of email address  p. 12

The support of email addresses linked to Phone Book entries shall be specified. In addition to that, information for identifying these addresses is needed.

10.2.4  Support of user definable groupings  p. 12

The specification shall support the grouping of Phone Book entries into groups defined by the user, for example, business and private.

10.2.5  Support of hidden entries  p. 12

The specification shall support means of marking Phone Book entries as "hidden".

10.2.6  Number of entries  p. 12

The specification shall support storage of at least 500 entries.

10.2.7  Void

10.3  Storage of call details  p. 12

The specification shall support provision of storage for call detail information. The call detail information consists of the following attributes:
  • mobile terminated calls:
    calling party number, date and time, calling party's name and status of call (i.e. answered or missed), duration;
  • mobile originated calls:
    called party number, date and time, called party's name and duration;
  • accumulated duration of preceding calls, separately for mobile originated and mobile terminated calls.
    Call detail attributes are optional. A value to mark them as "undefined" shall be available.
Up

10.4  Void

11  3G/GSM interworking  p. 13

11.1  Void

11.2  3G subscribers in a GSM network  p. 13

3GPP TS 22.101 requires that UMTS shall provide some mechanisms which permit UMTS subscribers to roam easily onto pre-UMTS systems and access the services.
Thus, the specification shall allow the UICC to be used with a dual mode (GSM/ 3G) ME and a GSM ME for the provision of GSM service.

12  Contact Manager  p. 13

12.1  General  p. 13

The Contact Manager provides an interface for the management of contact information including rich content without any structural limitations.
There shall be a mechanism for the ME to detect that the UICC containing the Contact Manager has changed. This mechanism may be used by the ME to ask the user whether synchronization of data between the ME and the UICC Contact Manager should occur.
This clause defines the functional requirements of the Contact Manager. An ME and a 3GPP application supporting the Contact Manager shall comply with all these requirements.
Up

12.2  Security requirements  p. 13

The Contact Manager may contain personal information. It shall be possible to restrict the access to this information to authorized users or entities (e.g. by binding the access to the verification of the USIM PIN).

12.4.3  Interworking with the 3G Phone Book  p. 13

In case both the ME and the 3GPP application support both the 3G Phone Book (i.e. as defined in clause 10.2 of the present document) and the Contact Manager the Contact Manager shall be used. There shall be a mechanism for the 3GPP application to indicate the support of the Contact Manager.

12.4.4  Content description  p. 13

12.4.4.1  Number of contacts  p. 13

The Contact Manager specification shall not unreasonably restrict the number of contacts.

12.4.4.2  Contact structure  p. 13

The Contact Manager shall consist of contacts, which are made up of various fields (e.g. phone number, name, photo). A filtering mechanism according to OMA DS Field Filtering shall be supported.
It shall be possible to have several instances of a field in a contact when appropriate (e.g. a contact may have two fax numbers).
An extensible coding scheme shall be defined which allows to describe a contact including all its fields. An existing scheme (e.g. "vcard") shall be used, if appropriate.
A minimum set of field types recognised by the 3GPP application and the ME shall be defined (e.g. name, phone number, URL, Email address, address, sound, pictures, notes).
It shall be possible to store and associate multimedia information (stored on the 3GPP application) with a contact (e.g. photo, logo, video, ring tone, voice tag).
It shall be possible to associate an icon or a label to each contact field type (e.g. associate an icon representing a phone to the number field. "Home address" could be configured as the label of the "mailing address" field type).
It shall be possible to configure the structure and the display order of the contact fields (e.g. first name then Instant Messaging address then number, etc) depending on ME capabilities.
Up

12.4.4.3  Group management  p. 14

It shall be possible to define new groups (e.g. My Tennis Club).
It shall be possible to pre-define groups (e.g. Friend, Work, Family and VIP).
It shall be possible to store and associate multimedia information (stored on the 3GPP application) with a group (e.g. photo, logo, video, ring tone, icon).
It shall be possible to bind contacts to one or several groups.

12.4.4.4  User Action Management  p. 14

It shall be possible to configure a list of possible actions that could be proposed to the user when the contact is selected (e.g. Launch Browser, Send SMS, Send MMS, Instant messaging, Make a voice over IP call, Make a video call, Make a conference call, Game player, Send Email).

12.4.5  Interface capabilities description  p. 14

An external and an internal interface to the Contact Manager shall be defined.
The external interface between the Contact Manager and a UICC external entity, i.e. the ME, shall rely on a transport protocol layer that is independent of the physical interface (i.e. the ISO interface and the new high-speed interface). This is to allow the definition of one solution that can use either the existing ISO interface or the new high-speed interface. The external interface definition shall also ease interfacing the PC applications with the Contact Manager.
Both the ME and the UICC shall be capable of initiating contact information synchronization based on a configurable policy.The internal interface allows other UICC resident applications to access the Contact Manager e.g. through a dedicated API. This enables the creation of additional services utilizing the Contact Manager data and properties. There shall be a mechanism for the user to allow or prevent remote access to the Contact Manager.
The external and internal interface shall provide means to:
  • identify Contact Manager capabilities
  • perform the following operations on a contact or a group: create, retrieve, modify, delete, search
In addition the internal interface shall provide mechanisms to:
  • register/deregister an UICC resident application to the Contact Manager.
  • allow a resident UICC application to access Contact Manager data and properties based on user permission.
  • allow the Contact Manager to notify events to registered UICC application and to pass event related information when applicable. Events notifying the applications shall include:
    • contact information is modified locally
    • contact information is modified remotely
    • change of contact manager configuration
Up

12.4.6  Efficient browsing and searching  p. 15

The Contact Manager interfaces should allow efficient searching and browsing of the contacts (i.e. the user experience browsing the Contact Manager should be acceptable).

12.4.7  Associated services  p. 15

12.4.7.1  Memory management  p. 15

It shall be possible to determine the number of stored contacts and the amount of the available and used Contact Manager memory.

$  Change history  p. 16

Up   Top