Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 22.101  Word version:  18.6.0

Top   Top   Up   Prev   Next
1…   4…   5…   10…   11…   13…   21…   24…   26a…   28…   30…   A…   A.19…   B…

 

A.19  Abbreviated diallingp. 85

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.
Up

A.20  Barring of Dialled Numbersp. 85

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).
Up

A.21  DTMF control digits separatorp. 86

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.
Up

A.22  Selection of directory number in messagesp. 86

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. 86

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 Numbersp. 86

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.
Up

A.25  Fixed number dialling |R4|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 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.
Up

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

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.
Up

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

A.27.1  General Requirements |R14|p. 88

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.
Up

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

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.
Up

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

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.
Up

A.27.4  Interworking requirements |R14|p. 89

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.
Up

A.27.5  Domain selection |R14|p. 89

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. 89

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.
ICE information type format ICE information type value ICE information value 1 ICE information value 2 ICE information value n
Descrip­tion Two formats shall be defined in this release:
  1. Phone number format. For the phone number format it shall be possible to store a name and a phone number.
  2. 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:
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, FranceN/A
Free Format "Language" FrenchN/A
Free Format "Travel Information" London, from 3rd July. to 29th July, 2008N/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.
Up

Up   Top   ToC