Content for TS 22.101 Word version: 18.4.0

1… 4… 5… 10… 11… 13… 21… 26a… A…

A (Normative) Description of optional user equipment features p. 82

A.1 Display of called number p. 82

This feature enables the caller to check before call setup whether the selected number is correct.

A.2 Indication of call progress signals p. 82

Indications shall be given such as tones, recorded messages or visual display based on signalling information returned from the PLMN. On data calls, this information may be signalled to the DTE.

Call progress indicators are described in TS 22.001.

A.3 Country/PLMN indication p. 82

The country/PLMN indicator shows in which PLMN the UE is currently registered. This indicator is necessary so that the user knows when "roaming" is taking place and that the choice of PLMN is correct. Both the country and PLMN will be indicated. When more than one visited PLMN is available in a given area such information will be indicated.

The PLMN name is either:

Stored in the ME and associated with the MCC+MNC combination received on the broadcast channel;
NITZ (see TS 22.042) (in which case it overrides the name stored in the ME);
stored in the USIM in text and /or graphic format and associated with the MCC+MNC combination, and optionally the LAI, received on the broadcast channel (in which case it overrides the name stored in the UE and - if present - the NITZ name).

It shall be possible to store on the USIM at least 10 PLMN Identifications (MCC+MNC combination and optionally the LAI) for which the same PLMN name shall be displayed.

The PLMN name stored in the USIM has the highest priority, followed by the PLMN name provided by NITZ. The PLMN name stored in the ME has the lowest priority.

If the PLMN name stored in the USIM is not available in text format and the UE is unable to display the graphic format, the PLMN name provided by NITZ has the highest priority, the PLMN name stored in the ME has the next priority.

For a PLMN name provided by NITZ, operators using non-Latin characters of the local language (such as Chinese, Japanese, Korean, Vietnamese, Arabic, Hindi, etc.) may include the network name in Latin characters in addition to characters of the local language.

For a PLMN name provided by NITZ, the roaming UE should skip displaying non-Latin character(s) if the language of those character(s) does not match the language of the MMI for the UE. If this would lead to no remaining Latin character in the PLMN name, the UE should skip displaying the PLMN name provided by NITZ; the PLMN name stored in the ME has the next priority instead.

A.4 Service Provider Name indication p. 83

The service provider name is stored in the USIM in text and/or optionally graphic format. It shall be possible to associate at least 10 PLMN Identifications (MCC+MNC combination) with the same SP Name.

When registered on the HPLMN, or one of the PLMN Identifications used for Service Provider Name display:

When registered on neither the HPLMN, nor one of the PLMN Identifications used for Service Provider Name display:

If the UE is unable to display the full name of the Service Provider the name is cut from the tail end. The storage of Service Provider name and options, and choice of options, shall be under control of the network operator.

A.4a Core Network Operator Name indication |R6| p. 83

It shall be possible for the UE to display the name of the core network operator the user has selected.

A.5 Keypad p. 83

A physical means of entering numbers, generally, though not necessarily, in accordance with the layout shown in Figure A.1.

See also TS 22.030 (Man-Machine Interface).

Additional keys may provide the means to control the UE (e.g. to initiate and terminate calls).

Reproduction of 3GPP TS 22.101, Fig. A.1:

Figure A.1

A.6 Short message indication and acknowledgement p. 84

This feature allows the delivery of short messages to a UE from a service centre. Such messages are submitted to the service centre by a telecommunications network user who can also request information of the status of the message by further interrogation of the service centre. The service centre then transmits the message to an active UE user.

The UE must therefore provide an indication to the user that a message has been received from the service centre and must also send an acknowledgement signal to the PLMN to show that this indication has been activated. The PLMN then returns this acknowledgement to the service centre.

The short message service teleservice is described in specification TS 22.003.

A.7 Short message overflow indication p. 84

An indication shall be given to the user of the short message service when an incoming message cannot be received due to insufficient available memory.

A.8 International access function p. 84

Provision is made for a direct, standard method of gaining international access. For this purpose the UE may have a key whose primary or secondary function is marked "+". This is signalled over the radio interface and would have the effect of generating the international access code in the network. It may be used directly when setting up a call, or entered into the memory for abbreviated dialling.

This feature is of benefit since the international access code varies between CEPT countries, which might cause confusion to a user, and prevent the effective use of abbreviated dialling when roaming internationally. Users may still place international calls conventionally, using the appropriate international access code.

A.9 Service Indicator (SI) p. 84

An indication is given to the user that there is adequate signal strength (as far as can be judged from the received signal) to allow a call to be made. Additionally the network should be capable of providing, and the UE may display, an indication of the serving cells' capabilities e.g. GPRS, HSDPA, HSUPA.

If indicated by the registered network, the UE in idle mode may display an indication of one of the radio access technologies provided to the UE in the network on which the UE is registered with the following priority order: E-UTRAN, UTRAN, GERAN.

Displaying the serving cell's capabilities and the access technology are mutually exclusive.

A.10 Dual Tone Multi Frequency (DTMF) p. 84

The UE shall be capable of initiating DTMF in accordance with specifications TS 22.003. Optionally, the UE may provide a suppress function which allows the user to switch off the DTMF function.

A.11 On/Off switch p. 84

The UE may be provided with a means of switching its power supply on and off. Switch-off shall be "soft", so that on activation, the UE completes the following housekeeping functions: termination of a current call, detach (where applicable) and storing required data in the SIM/USIM before actually switching off. As far as possible, this procedure should also apply on power failure (e.g. remote switch-off or low battery).

A.12 Sub-Address p. 84

This feature allows the mobile to append and/or receive a sub-address to a Directory Number, for use in call set-up, and in those supplementary services that use a Directory Number.

A.13 Short Message Service Cell Broadcast p. 85

The Short Message Service Cell Broadcast enables the mobile equipment to receive short messages from a message handling system.

The short message service cell broadcast teleservice is described in specification TS 22.003

A.14 Short Message Service Cell Broadcast DRX p. 85

This feature enables a mobile equipment to save on battery utilization, by allowing the mobile equipment to not listen during the broadcast of messages the subscriber is not interested in.

A.15 Support of the extended Short message cell broadcast channel p. 85

This feature allows a mobile equipment by supporting of the extended Short message cell broadcast channel to enhance the capacity of the service. The support of the extended channel has low priority, i.e. the UE can interrupt the reading of this channel if idle mode procedures have to be executed.

A.16 Network Identity and Timezone p. 85

The feature provides the means for serving PLMNs to transfer current identity, universal time and the local timezone to mobile equipment, and for the mobile equipment to store and use this information. This enhances roaming by permitting accurate indication of PLMN identities that are either newer than the ME or have changed their name since the ME was sold. Additionally time and timezone information can be utilized by MEs as desired.

The network name time and timezone information will normally be transferred from the network to the ME:

Upon registering on the network.
When the UE geographically relocates to a different Local Time Zone.
When the network changes its Local Time Zone, e.g. between summer and winter time.
When the network changes its identity.
At any time during a signalling connection with mobile equipment.

Further details of this feature are described in TS 22.042.

A.17 Network's indication of alerting in the UE p. 85

This feature provides the means for serving PLMNs to transfer to a UE an indication that may be used by the UE to alert the user in a specific manner in the following cases:

mobile terminating call
network-initiated USSD
network-initiated Mobile Originated (MO) connection, if the ME supports the "network-initiated MO connection" feature.

Eight different indications are defined, whether the mobile terminating traffic is a call or USSD or related to the network-initiated MO connection procedure. These indications are sent by the network and received by the UE:

Three of these indications are used as levels, reflecting some kind of urgency: level 0 indicates that the UE shall not alert the user for USSD and remain silent in the case of call, level 2 shall be considered by the UE as more important than level 1 for the purpose of alerting the user.
The five other indications are used as categories, identifying different types of terminating traffic. The UE shall inform the user in a specific manner for each of these five categories. Nevertheless, the possible forms of the alert (different ringing tones, displayed text, graphical symbols...) is still up to the mobile manufacturer (some forms of alerts can be simultaneously used, e.g. ringing tones and text on the display).

The management of the feature by the UE requires for the handling of categories that:

the SIM/USIM stores for each category an informative text (maximum 25 characters per category) describing the type of terminating traffic associated with the category. This information could be used by the UE when alerting the user (display on the screen). It is necessary for the network operator to be able to change the meaning of each category.
The user has the ability to set up his/her own association between the type of terminating traffic (identified by each category) and the different types of alert provided by the UE. To help the user in this choice, the UE uses the informative text associated with each category (as stored in the SIM/USIM). The UE should keep this association when switched off.
Default settings should also be defined in the ME for the following cases:
- when the UE receives a call, USSD or a request for a network-initiated MO connection with no alerting indication,
- when the UE receives a call, USSD or a request for a network-initiated MO connection with a category of alerting not defined in the SIM/USIM.
These default settings should be separated per type of mobile terminated traffic received (call, USSD or request for a network-initiated MO connection).

A UE supporting the feature shall act according to the following points in case of mobile terminating traffic:

when a mobile terminating traffic is received without any indication (level or category), the ME shall act as if it was not supporting the feature, i.e. use a default alert (e.g. associated with this type of mobile terminating traffic).
if a level is indicated, the UE shall use an alert enabling the user to differentiate between the three levels.
if a category is indicated, then:
- if the SIM/USIM used in the UE does not store any information on that feature, the UE shall ignore the category received with any mobile terminating traffic and act as if it was not supporting the feature, i.e. use a default alert (e.g. associated with this type of mobile terminating traffic).
- if the category is not defined in the SIM/USIM, the UE shall act as if it was not supporting the feature, i.e. use a default alert (e.g. associated with this type of mobile terminating traffic).
- if the category is defined in the SIM/USIM, the UE shall use the alert associated with this category. In addition, it would be very useful for the user to be notified of the informative text associated with this category (e.g. on the display).

Some interactions between this feature and other services related to alerting are described below:

the call waiting service has priority on this feature, i.e. the call waiting tone will be played and not the alert derived by this feature. If possible, two different indications should be given to the user (e.g. the call waiting tone and a text on the display indicating call waiting, and in addition a text relative to the type of the new call received).
the presentation of the calling line identity takes priority on this feature, if it is not possible to display this information and another information related to this feature.
In case of interaction between this feature and UE specific features to alert the user (e.g. whole silent mode), the user should still be able to differentiate between the different levels or different types of terminating traffic, even if the alert itself may be changed.

A.18 Network-initiated Mobile Originated (MO) connection p. 87

The "Network-initiated Mobile Originated connection" feature allows the network to ask the mobile equipment to establish a mobile originated connection. The serving PLMN provides the mobile equipment with the necessary information which is used by the mobile equipment to establish the connection.

Currently only the network-initiated mobile originated call feature is specified. It is mandatory for a UE supporting CCBS and is used in the case of a CCBS recall.

A.19 Abbreviated dialling p. 87

The directory number or part of it is stored in the mobile equipment together with the abbreviated address. After retrieval the directory number may appear on the display.

Abbreviated dialling numbers stored in the UE or USIM may contain wild characters.

If wild characters are used to indicate missing digits, each wild character shall be replaced for network access or supplementary service operation, by a single digit entered at the keypad. The completed directory number is transmitted on the radio path.

A.20 Barring of Dialled Numbers p. 87

This feature provides a mechanism so that by the use of an electronic lock it is possible to place a bar on calling any numbers belonging to a pre-programmed list of numbers in the SIM/USIM.

Barred Dialling Numbers stored in the /USIM may contain wild characters.

Under control of PIN2, "Barred Dialling Mode" may be enabled or disabled. The selected mode is stored in the SIM/USIM.

Under PIN2 control, it shall be possible to add, modify or delete a particular "Barred Dialling Number" (BDN) and to allocate or modify its associated comparison method(s). This BDN may have the function of an abbreviated dialling number / supplementary service control (ADN/SSC), overflow and/or sub-address.

When BDN is inactive, no special controls are specified, and the barred dialling numbers may be read (though not modified or deleted, except under PIN2 control) as if they were normal abbreviated dialling numbers. Access to keyboard and normal abbreviated dialling numbers (including sub-address) is also permitted.

When Barring of Dialled Numbers is active:

Considering a number dialled by the user, if it exists a BDN for which there is a successful comparison (see below) between that BDN and the dialled number, then the ME shall prevent the call attempt to that number. If there is no BDN to fulfil those conditions, the call attempt is allowed by the ME.

With each BDN is associated one (or a combination of) comparison method(s) used between that BDN and the number dialled by the user. At least three different comparison methods are possible:

The comparison is made from the first digit of that BDN, from the first digit of the dialled number and for a number of digits corresponding to the length of the BDN.
The comparison is made from the first digit of that BDN, from any digit of the dialled number and for a number of digits corresponding to the length of the BDN.
The comparison is made backwards from the last digit of that BDN, from the last digit of the dialled number and for a number of digits corresponding to the length of the BDN.
If a BDN stored in the SIM/USIM contains one or more wild characters in any position, each wild character shall be replaced by any single digit when the comparison between that BDN and the dialled number is performed.
If a BDN contains a sub-address, and the same number without any sub-address or with that sub-address is dialled, the ME shall prevent the call attempt to that number.
Numbers specified as "barred" may only be modified under PIN2 control.
If the ME does not support barring of dialled numbers, the UE with a BDN enabled USIM shall not allow the making of calls and the UE with BDN enabled SIM shall not allow the making or receiving of calls. However, this feature does not affect the ability to make emergency calls.

If "Fixed Number Dialling" and "Barring of Dialled Numbers" are simultaneously active, the dialled number shall be checked against the two features before the ME allows the call attempt. In that case, a dialled number will only be allowed by the ME if it is in the FDN list and if the comparison between that number and any number from the BDN list is not successful.

The UE may support other selective barrings, e.g. applying to individual services (e.g. telephony, data transmission) or individual call types (e.g. long distance, international calls).

A.21 DTMF control digits separator p. 88

Provision has been made to enter DTMF digits with a telephone number, and upon the called party answering the UE shall send the DTMF digits automatically to the network after a delay of 3 seconds (± 20 %). The digits shall be sent according to the procedures and timing specified in TS 24.008.

The first occurrence of the "DTMF Control Digits Separator" shall be used by the ME to distinguish between the addressing digits (i.e. the phone number) and the DTMF digits. Upon subsequent occurrences of the separator, the UE shall pause again for 3 seconds (± 20 %) before sending any further DTMF digits.

To enable the separator to be stored in the address field of an Abbreviated Dialling Number record in the SIM/USIM, the separator shall be coded as defined in TS 31.102. The telephone number shall always precede the DTMF digits when stored in the SIM/USIM.

The way in which the separator is entered and display in the UE, is left to the individual manufacturer's MMI.

MEs which do not support this feature and encounter this separator in an ADN record of the SIM/USIM will treat the character as "corrupt data" and act accordingly.

A.22 Selection of directory number in messages p. 88

The Short Message Service (SMS), Cell Broadcast Service (CBS), Multimedia Message Service (MMS), Network-initiated USSD or Network Response to Mobile Originated USSD message strings may be used to convey a Directory Number, which the user may wish to call.

A.23 Last Numbers Dialled (LND) p. 88

The Last "N" Numbers dialled may be stored in the SIM/USIM and/or the ME. "N" may take the value up to 10 in the SIM/USIM. It may be any value in the ME. The method of presentation of these to the user for setting up a call is the responsibility of the UE but if these numbers are stored in both the SIM/USIM and the UE, those from the SIM/USIM shall take precedence.

A.24 Service Dialling Numbers p. 88

The Service Dialling Numbers feature allows for the storage of numbers related to services offered by the network operator/service provider in the SIM/USIM (e.g. customer care). The user can use these telephone numbers to make outgoing calls, but the access for updating of the numbers shall be under the control of the operator.

A specific example of Service Dialling Numbers is the storage of mailbox dialling numbers on the SIM/USIM for access to mailboxes associated with Voicemail, Fax, Electronic Mail and Other messages.

A.25 Fixed number dialling |R4| p. 89

This feature provides a mechanism so that by the use of an electronic lock it is possible to place a bar on calling any numbers other than those pre-programmed in the SIM/USIM.

Under control of PIN 2, "Fixed Dialling Mode" may be enabled or disabled. The mode selected is stored in the SIM/USIM.

Fixed Dialling Numbers (FDNs) are stored in the SIM/USIM in the Fixed Dialling Number field. FDN entries are composed of a destination address/Supplementary Service Control. Destination addresses may have the format relevant to the bearer services/teleservices defined in [21] and [14]. FDN entries may take the function of an Abbreviated Dialling Number/Supplementary Service Control (ADN/SSC), Overflow and/or sub-address. Fixed Dialling Numbers stored in the SIM/USIM may contain wild card characters.

The Fixed Dialling feature is optional, however when Fixed Dialling Mode is enabled, an ME supporting the feature shall;

Prevent the establishment of bearer services/teleservices to destination addresses which are not in FDN entries on a per bearer service/teleservice basis. The list of bearer services/teleservices excluded from the FDN check shall be stored in the SIM/USIM. Those bearer services/teleservices are characterised by their service code as described in [23]. For instance, if the SMS teleservices is indicated in this list, SMS can be sent to any destination. By default, the ME shall prevent the establishment of any bearer service/teleservice to destination addresses which are not in FDN entries.
Only allow modification, addition or deletion of Fixed Number Dialling entries under control of PIN2.
Allow the establishment of bearer services/teleservice to destination addresses stored in FDN entries. For SMS, the Service Center address and the end-destination address shall be checked.
Support the reading and substitution of wildcards in any position of an FDN entry, via the ME MMI.
Allow the user to replace each wildcard of an FDN entry by a single digit, on a per call basis without using PIN2. The digit replacing the wildcard may be used for network access or supplementary service operation.
Only allow Supplementary Service (SS) Control (in Dedicated or Idle mode) if the SS control string is stored as an FDN entry.
Allow the extension of an FDN entry by adding digits to the Fixed Dialling number on a per call basis.
Allow the emergency numbers (see Section 8.4) to be called, even if it is not an FDN entry.
Allow normal access to ADN fields (i.e. allow ADN entries to be modified, added or deleted) and the keyboard.
Allow use of ADNs subject to the FDN filter.

When FDN is disabled, an ME supporting FDN shall;

Allow FDN entries to be read as though they were normal ADN entries.
Only allow modification, addition or deletion of Fixed Number Dialling entries under control of PIN2.
Allow normal access to ADN fields and the keyboard.

If the ME does not support FDN, the UE shall not allow the making of calls when Fixed Dialling is enabled in the USIM, and the UE shall not allow the making or receiving of calls when Fixed Dialling is enabled in the SIM. However, emergency calls (112 and other user defined emergency numbers) shall still be possible.

A.26 Message Waiting Indication |R4| p. 89

A short message may be used to provide an indication to the user about the status and number of types of messages waiting on systems connected to the PLMN. The ME shall present this indication as an icon on the screen, or other MMI indication, and store the indication status on the SIM/USIM to allow the status to be retained through power off/on, SIM/USIM movement between UEs etc.

The ME shall be able to accept and acknowledge these message waiting status short messages irrespective of the memory available in the SIM/USIM.

A.27 Transfer of eCall Minimum Set of Data (MSD) |R8| p. 90

A.27.1 General Requirements |R14| p. 90

With the exception of the following specific requirements, considered necessary for the satisfactory operation of the eCall service, all existing emergency call requirements shall apply.

An eCall shall consist of an emergency call supplemented by a minimum set of emergency related data (MSD). The MSD e.g. vehicle identity, location information and other parameters, is defined by CEN [46].

An eCall may be initiated automatically, for example due to a vehicle collision, or manually by the vehicle occupants;
An IVS, or other UE designed to support eCall functionality, shall include in the emergency call set-up an indication that the present call is either a Manually Initiated eCall (MIeC) or an Automatically Initiated eCall (AIeC).
The Minimum Set of Data (MSD) sent by the In vehicle System (IVS) to the network shall not exceed 140 bytes;
Should the MSD component not be included in an eCall, or is corrupted or lost for any reason, then this shall not affect the associated emergency call speech functionality.
To reduce the time taken to establish an eCall an IVS whilst in eCall only mode, may receive network availability information whilst not registered on a PLMN.
PLMNs should make use of eCall indicators, received in the emergency call set-up, to differentiate eCalls from other emergency calls.
The MIeC and AIeC should be used by the serving network to filter and route eCalls to dedicated, eCall equipped, PSAPs.
The PSAP shall be given an indication that the incoming call is an eCall.
When an emergency call, other than an eCall, is routed to a PSAP that supports the eCall service, the eCall equipment shall not cause audible interference to the emergency voice call.

Throughout the duration of the emergency call and following receipt of the MSD by the PSAP

It shall be possible for the PSAP to send a confirmation to the IVS that the MSD has been acted upon.
It shall be possible for the PSAP to request the IVS to re-send its most recent MSD.
It shall be possible for the PSAP to instruct the IVS to terminate the eCall.

A.27.2 Requirements for the transfer of eCall MSD in a TS12 call |R14| p. 90

The MSD should typically be made available to the PSAP within 4 seconds measured from the time when end to end connection with the PSAP is established;

A call progress indication shall be provided to the user whilst the MSD transmission is in progress.

Where the eCall indicators are not supported by the serving network, the time needed for the PSAP eCall modem to differentiate between eCalls and other TS12 calls, before routing the call to an operator, shall not exceed 2 seconds from when the IVS receives notification that the PSAP has answered the call.

When an eCall is routed to a PSAP, that does not support the eCall service, the In Vehicle System (IVS) shall not emit any audible tones for longer than 2 seconds from the time that the call is first answered.

A.27.3 Requirements for the transfer of eCall data in an IMS emergency call |R14| p. 91

The MSD should typically be available to the PSAP when the end to end connection with the PSAP has been established.

Additional data (i.e. data not contained in the initial MSD) may be transferred at any time during the eCall (e.g. MSD acknowledgement, resending of the MSD if requested by a PSAP).

The call setup time of an eCall shall be the same as for an IMS emergency call.

The IVS shall not emit any audible tones in order to transfer the MSD or other eCall related data.

A.27.4 Interworking requirements |R14| p. 91

A PSAP, which is connected to the IMS, and supports either IMS emergency call based eCall or TS12 based eCall, shall be able to interwork with a TS12 based IVS using IMS Centralized Service, i.e. it shall be able to terminate the emergency call from the IVS, receive the MSD and request additional data from the IVS, using the eCall Modem end-to-end.

An IVS that supports IMS emergency call based eCalls shall also support TS12 based eCalls.

An IVS that supports IMS emergency call based eCalls and is attached via LTE access with no CS access available shall support the transfer of MSD via IMS emergency call to a TS12 based PSAP using the eCall Modem end-to-end.

In case of interworking between TS12 and IMS emergency call based eCall equipment the requirements given in clause A.27.2 shall apply, requirements given in clause A.27.3 do not apply.

A.27.5 Domain selection |R14| p. 91

A PLMN shall indicate to an IVS whether IMS emergency call based eCalls are supported.

An IVS that supports both IMS emergency call based eCalls and TS12 based eCalls shall support domain selection for an eCall in the same way as for any other emergency call except for determining PLMN support for an IMS emergency based eCall using the PLMN indication for this.

A.28 Requirements for "In Case of Emergency" (ICE) information |R8| p. 91

The In Case of Emergency (ICE) information are used to enable first responders, such as paramedics, fire-fighters, and police officers, to contact a victim's emergency contact(s) in order to identify the victim and obtain important medical information or other information required during an emergency.

A UE shall have the capability to store one or more "ICE information" on the UICC. The "ICE information" shall list the type of information which is to be configured by the mobile operator as described in the Table below.

Table A.28.1: "ICE information" description

	ICE information type format	ICE information type value	ICE information value 1	ICE information value 2	ICE information value n
Description	Two formats shall be defined in this release: Phone number format. For the phone number format it shall be possible to store a name and a phone number. Free format. It shall be possible for the mobile operator to provision zero, one or several instances of a given format on the UICC.	It shall be possible to store this information in text or graphic format.	It shall be possible to have at least one ICE information value field. If more than one information value fields are required it shall be indicated by the ICE information type format. It shall be possible for the subscriber to add, modify, view, or delete any ICE information value. For the free format ICE information type format, it shall be possible to store information in text or graphic format. For pre-defined ICE information type formats the ME should adapt the input mode to the type of the ICE information value (e.g. numerical mode for phone number input).	Present only if explicitly indicated by the ICE information type format.	Present only if explicitly indicated by the ICE information type format.

The following table provides an example of ICE information stored on the UICC:

Table A.28.2: "ICE information" example

ICE information type	ICE information type value	ICE information value 1	ICE information value 2
Phone Number	"Contact in case of emergency"	My Wife	+3364566
Phone Number	"Contact in case of emergency"	Family Smith	+3364565
Phone Number	"Contact in case of emergency"	My Family doctor: Dr. Jones	+33643234
Free Format	"Medical Information"	My blood type is A+, I am allergic to etc.	N/A
Free Format	"Home Postal Address"	15 rue de la Paix, Paris, France	N/A
Free Format	"Language"	French	N/A
Free Format	"Travel Information"	London, from 3rd July. to 29th July, 2008	N/A

Provision is made for direct and unambiguous read access from the UE to ICE information stored on the UICC.

The subscriber may choose not to enter any ICE information.

The default configuration for this information shall be that they are accessible even when the security features on either the UE or UICC have been enabled (e.g. the keypad is locked). It shall be possible for the subscriber to change this default setting to prevent accessibility to the ICE information (i.e. a user configurable setting in the UICC indicates whether the ICE information on the UICC shall be displayed or not, if the ICE access procedure described in TS 22.030 is invoked).

The unlocking of ICE information shall not allow access to other secure information on the UICC or UE. The ICE information value should not be accessible to ME or UICC applications.

The ICE access procedure is described in TS 22.030.

B Additional number use case |R11| p. 94

Company X is customer of operator Z and has a subscription for voice and data with 10 SIM cards. The company also decides to subscribe to the private numbering plan feature of operator Z. A certain corporate phone number is assigned to company X, e.g. +43 676 88888 xx (with xx being the extensions of the users), and they can freely choose the extensions for up to 100 SIM cards.

Initially company X take the existing 10 SIM cards (with the existing MSISDNs) and integrate them into the private numbering plan by assigning the extensions 11 to 20 to these cards via a web portal. This is not a permanent assignment, the extensions can be changed easily any time, old SIMs can be deleted from the private numbering plan and new ones can be integrated whenever necessary. Special privileges or restrictions can be chosen on a per SIM basis via the portal and special tariffs apply.

The CEO of company X calls a customer. The customer's phone displays the corporate number + extension of the CEO as CLI. After a while the customer decides to call back the CEO and uses the corporate number + extension as MSISDN. Later they also exchange some short messages, again the corporate number + extension of the CEO is used as sender's MSISDN.

For all these calls and short messages operator Z is able to collect charging records containing the corporate number + extension.

The CEO also uses her smart phone to establish PS connections to browse the internet and to access the intranet via the operator's gateway. The corporate number + extension is used for authentication and authorisation in the company's intranet and its web applications. Charging for PS connections by operator Z is also based on this number.

In general the users in company X are not aware of their "real" underlying MSISDNs in the system, they only see the corporate number + their extension and there is no need for them to know the underlying MSISDN.