SIM Toolkit Modifications for 3GPP

3GPP TSG-T3 (USIM) Meeting #10
Austin, USA, 2 - 5 November, 1999
Tdoc T3-99346
Source: Nokia

---

General
The SIM toolkit has been designed for a single application environent. As a result of this the SAT can be started at the initial power up of the card. In 3GPP the multiapplication environment has to be taken into account in such a way that the USAT is not activated until a specific application has been selected. Further more there are SAT commands that are more card related than application related. These commands should apply to the card setting and should be common to all SAT applications that may be active consecutively during a card session e.g the terminal profile is performed once during the UICC activation phase. The activated toolkit session is terminated when the USIM session has been deactivated according to the deactivation procedures. Any resources assigned to the deactivated toolkit application are released.

The toolkit features should go through a revision process where the outcome of the AEE work is taken inot account. This part of the toolkit work should take place in coperation with SA1.

Protocol Issues
There is a need to separate between protocol errors that takes place on the ME-UICC interface and errors that are related to the application itself. This can be achieved by reserving a couple of response codes SW1/SW2 for indication of application specific response/error codes. These response codes will always carry in an "envelope" the detailed error description. This error description do not have to be interpreted by the ME-UICC protocol communication SW.

In order to make the toolkit protocol independent a possibility for inidicating the source application in these responses should be considered. This would be useful in particular when introducing multitasking in the UICC. There would be two levels of source information. The first level is command related and would contain the logical channel information that was used in the command issued by the ME. The other information would be an application source address similar to what is used for T=1.

An abort command needs to be specified. This command would abort the execution of any command ongoing. The response to this command is acceptance only. The null procedure byte associated with T=0 is not a valid response to this command. The response to the command should take place within the normal work waiting time of the card. This command is need as well in GSM as in UMTS to ensure execution of essential commands related to the security and network management.

Refresh with UICC Reset
The refresh command that requires UICC reset is to be modified from an existing cold reset to a warm reset. Issues related to interface parameters and the specific mode needs to be resolved. The intention is that the security status of the USIM remains unchanged. This means that the PIN verification status remains and access conditions prior top the reset remains unchanged unless changed by the application.

A SW command for application restart is to be defined. This command can be used in some cases instead of the reset of the UICC. This command would take the application back to the start. The return point is after the ATR, no ATR is sent to the terminal. The response to the restart command is not sent until the application has succesfully restarted. In case of simultanous multiapplications running in the card only the application addressed in the command is affected.

Call Control
The existing indication of FDN and BDN activation in addition to the service table needs to be revised. The invalidation of the ADN remains only for compatibility with GSM. In this case only the mapped ADN file under DFTelecom is invalidated not the true ADN file under DFPhonebook. The BDN feature is either implemented as a pure toolkit implementation or dedicated commands are used for evaluating the dialled number by the USIM application.

Command related alpha identifiers
The use of alpha identifiers attached to toolkit commands should be stream lined. In the current 11.14 the amount of bytes used for alpha identifiers seems to be command dependent. Unless a TLV structure is used in these commands incompatibility is introduced at the command level if the aplha identifier is extended from one release to an other. A mechanism is to be defined for this. An alternative is to reserve several alpha identifiers for the commands using alpha identifiers to cope with future needs.