Main Page | Modules | Data Structures | File List | Data Fields | Globals | Related Pages | Examples

SIM Toolkit


This chapter is meant as a light introduction to SIM Toolkit (STK). All the details can be found in Ref. 11.14.

Citing the Ref. 11.14: SIM Application Toolkit provides mechanisms which allow applications, existing in the SIM, to interact and operate with any ME which supports the specific mechanism(s) required by the application.

STK was developed as a way for running applications in the SIM card. It is the oldest (first draft of Ref. 11.14 was published on 1996) and the most spread application platform for mobile phones/equipment. Due the security of SIM it is very popular for banking and privacy applications, and it has bright future in USIM - enhanced version for 3G networks.

Since 1998 allmost all of the mobile phones produced have been STK enabled, today every phone on the market STK supports. The question is not if but how good the support/compliance is. (Surprisingly smaller mobile equipmennt vendors have often better STK than the bigger brands.)


The most popular language option used for STK development is Java, or better its stripped down JavaCard variant
While using Java in embedded devices is a heavily marketed option, in practice it is not that convenient to use technology without direct memory access/manipulation as neccessary in devices with very little memory.

Development of JavaCard/STK application means to have good relations with smartcard producers, an area where almost everything is covered by NDA's. Deployment of such applications means connection to mobile operators. As a result it is closed community with very little if none room for independent applications.

STK Commands

During the years STK standard has evolved from basic user interface and SMS send operations to the advanced set of commands containing e.g. networking or pictures.

By functionality the STK commands could be divided into following groups:

User interface:

ME/SIM control commands:

Network commands:

Local information:



The SIM is informed about detail STK ME support during the initialization phase with the help of TERMINAL PROFILE APDU, ref. Notes on ME and SIM.

STK Protocol

You can leave the following text for later, it is more detailed and not necessary for beginners.
The communication between ME and SIM is command/response based, and it is always the ME which initiates communication. The general protocol is described in ISO 7816, the GSM specific stuff is in Ref. 11.11 and details on SIM Toolkit is in Ref. 11.14.


ME-SIM command/response protocol

SIM/Turbo operates only between command and answer - marked black in the above picture. Between the command/answer pairs ME can stop clock (or lower frequency) and Turbo goes to sleep to lower power consumption.

SIM Toolkit Low-level Commands

The SIM Toolkit extends the GSM APDUs with 4 commands:

Because it is the SIM which wants ME to perform some STK command and the ISO 7816 protocol is ME initiated, there must be some way for the SIM to inform ME that it should use the FETCH. This is done with the special answer on previous command(s) - we call the period when SIM first requests FETCH and FETCH command itself Pending FETCH request. It is upto the ME when it satisfies SIM request and it does not have to be immediately - ME can be busy performing something else.

After ME obtains the STK command with FETCH it tries to perform it, it can be e.g. display text or sending sms, etc. It may take some time and involve user activity - insert input, confirm, etc. Once the command is finished ME sends SIM the answer with the TERMINAL RESPONSE APDU. In the case taht SIM wants to continue with the next command it answers with FETCH request and the cycle repeates.


SIM Toolkit ME-SIM communication, singlethread FETCH

Multithreaded FETCH

While on the above right picture the STK commands follow one by one it could not be the only scenario.

The next picture shows situations when STK commands either intersect or are nested. Unfortunately the Ref. 11.14 leaves this unspecified and some devices behave differently - usually badly.

To avoid such situation Turbo queues FETCH requests, i.e. next command is offered to ME only after previous command is done (TERMINAL RESPONSE received). In practice that means that one Turbo application has to wait until command of another application is performed, e.g. sending of SMS response in localization requests waits for e.g. user entering text in another application.


Multithread FETCH situations

It is possible to allow multithreaded FETCH with the:
set_proc_8(PROC_8_MT_FETCH, 1);

Comparation to other mobile application technologies

STK could be compared to other on-device application platforms, esp. J2ME and full operation systems - Symbian, MS Smartphone, Linux.

STK pros:

STK cons:

J2ME pros:

J2ME cons:

OS level approach pros:

OS level approach cons:

Copyright © 2004-2006 BLADOX
Turbo version 1.2