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.)
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.
By functionality the STK commands could be divided into following groups:
User interface:
ME/SIM control commands:
Network commands:
Local information:
Timer:
Internetworking:
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.
ME-SIM command/response protocol
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
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
set_proc_8(PROC_8_MT_FETCH, 1);
STK pros:
STK cons:
J2ME pros:
J2ME cons:
OS level approach pros:
OS level approach cons:
Copyright © 2004-2006 BLADOX | Turbo version 1.2
|