Response Application Protocol Data Unit

Description

The R-APDU (Response Application Protocol Data Unit) is a structured data packet defined by 3GPP and ETSI standards, specifically within the framework of the UICC (Universal Integrated Circuit Card) and SIM (Subscriber Identity Module) application protocols. It forms the response part of a command-response transaction initiated by a C-APDU (Command APDU). The R-APDU is transmitted from the UICC to the terminal (e.g., mobile device) or, in OTA scenarios, through the terminal to a remote server. Its structure is rigorously defined, typically comprising a mandatory response data field (which may be empty) and a mandatory two-byte trailer containing a status word (SW1, SW2). This status word indicates the outcome of the corresponding command, such as success (e.g., '90 00'), various warning conditions, or specific error codes (e.g., memory failure, security status not satisfied).

In operation, when a terminal or OTA platform sends a C-APDU to the UICC to request an action—such as updating a file, running an applet, or performing a cryptographic calculation—the UICC processes the command. The processing result, which could include requested data (like a cryptographic signature or a file read) or simply an acknowledgment, is packaged into the R-APDU. The terminal then interprets this response based on the status word and any accompanying data. This mechanism is central to the SIM Application Toolkit (SAT), USAT (UMTS SAT), and CAT (CDMA Application Toolkit), allowing network operators to provision services, manage secure elements, and interact with applications on the card without physical access.

The role of the R-APDU in the network ecosystem is critical for secure management and service enablement. It is used in OTA platforms for remote SIM provisioning (e.g., eSIM management), updating authentication keys, and deploying value-added services. The protocol ensures integrity and a defined state machine for interactions, as every command must be conclusively answered. Its design allows for extensibility; the data field can carry complex payloads, and the status word space is large enough to cover numerous specific conditions defined by various application specifications, making it a versatile and enduring component of mobile telecommunications security and management architectures.

Purpose & Motivation

The R-APDU exists to provide a standardized, secure, and reliable method for a UICC/SIM card to respond to commands issued by an external entity. Before such standardization, interactions with smart cards were vendor-specific and lacked interoperability, hindering large-scale deployment of OTA services and secure application management. The APDU pair (C-APDU and R-APDU) protocol, adopted from ISO/IEC 7816-4, was integrated into telecom standards to create a uniform language for card-terminal communication.

This solved the problem of how to remotely and securely manage subscriber identity modules in the field. It enabled the SIM Application Toolkit, which allowed operators to push menus, services, and updates to phones, creating new revenue streams and improving customer experience. Furthermore, as mobile networks evolved to support more complex services like mobile banking (through SIM-based security) and later eSIM for IoT and consumer devices, the robust command-response mechanism of APDUs became indispensable. It addresses the need for atomic transactions where each command has a definitive success or failure outcome, which is crucial for maintaining the security state and data integrity of the SIM, a trusted anchor in the network.

Key Features

• Standardized response format with mandatory status word trailer (SW1, SW2)
• Carries response data payload from the UICC application processing
• Defines precise outcome codes for success, warnings, and execution errors
• Fundamental to SIM Application Toolkit (SAT/USAT) and OTA protocols
• Enables secure remote management and provisioning of UICC/SIM applications
• Ensures interoperable communication between terminals and smart cards from different vendors

Evolution Across Releases

Defining Specifications