Toolkit Application (ME-side or test-side application using 3GPP toolkit commands)

Description

The term 'Toolkit application' designates an application that uses the commands specified in TS 31.111 (USIM Application Toolkit, USAT) and TS 11.14 (SIM Application Toolkit for the legacy SIM). It is defined in the test and conformance specifications TS 31.131 and TS 34.131, where it denotes the application entity exercising or implementing the toolkit command set. The definition is intentionally functional: a toolkit application is any application whose behavior is expressed through the 3GPP toolkit commands — proactive commands, terminal responses, envelope commands, and associated data objects.

In the protocol architecture, the toolkit application sits at the boundary between the UICC and the Mobile Equipment. When the application runs on the UICC, it is the entity that emits proactive commands to the ME, which is why the term is closely related to, but distinct from, 'Toolkit applet'. In the test context, a toolkit application may be a test harness or a reference implementation on the ME side that validates whether a UICC correctly constructs and interprets toolkit commands. TS 31.131 specifies the conformance test suite for the USIM Application Toolkit, while TS 34.131 specifies terminal conformance tests for terminals supporting USAT/SAT functionality.

The commands used by a toolkit application include the proactive command set (DISPLAY TEXT, GET INKEY, GET INPUT, SEND SMS, SEND SS, SEND USSD, SET UP CALL, SET UP EVENT LIST, LAUNCH BROWSER, PROVIDE LOCAL INFORMATION, and many others), the terminal response set, and envelope commands such as SMS-PP data download, menu selection, call control, and event download. Each command is encoded as a TLV-structured data object carried over the card-terminal interface using the T=0 or T=1 transport. The application must respect the envelope and command handling rules, including the handling of Multiple Cards, Call Control, and MO/MT short message control by SIM.

The term appears mainly in test specifications because it describes the implementation under test from a functional viewpoint. When writing or executing conformance tests for USAT, engineers need a name for the abstract application that consumes TS 31.111 and TS 11.14 commands, independent of whether it is realized on the card, in the terminal, or in a test instrument. That abstraction is the toolkit application. This is also why the definition references both TS 31.111 and the older TS 11.14: interoperability must span the USIM/UICC generation and the legacy SIM generation.

For students and engineers, the practical distinction is straightforward. A toolkit applet is defined by its position and role — an application on the UICC that generates proactive commands. A toolkit application is defined by the command set it uses — the commands of TS 31.111 and TS 11.14. In many real products a toolkit applet is also a toolkit application, but the terms answer different questions and appear in different specifications. Recognizing this prevents confusion when navigating the 3GPP card and terminal test suites.

Purpose & Motivation

The term 'Toolkit application' exists to provide a specification-neutral name for any application that implements or exercises the 3GPP toolkit command set. In conformance testing, it is essential to refer to the implementation under test without assuming where it physically resides. TS 31.131 and TS 34.131 need such an abstraction because the same command-level behavior must be verified in different test configurations: USIM versus SIM, terminal versus card, and different toolkit classes.

Historically, the SIM Application Toolkit (TS 11.14) introduced proactive commands so that the SIM could drive the terminal. When USIM and USAT (TS 31.111) arrived with 3G, a new generation of toolkit behavior was defined while the legacy behavior remained in use. Test specifications therefore needed a single term spanning both generations, and 'toolkit application' was chosen because it is defined by the commands used rather than by the hosting platform.

The term also serves a practical interoperability purpose. Operators, card vendors, and terminal vendors all implement or consume the same command set, so a common functional label simplifies requirements traceability between core specifications (31.111, 11.14) and test specifications (31.131, 34.131). It reduces ambiguity in test cases, certification checklists, and interoperability statements.