Ady Wicaksono Daily Activities

Archive for the ‘Mobile’ Category

Lock/Unlock Javacard Applet

leave a comment »

Sometime we need to disable a javacard applet inside the SIMCard without remove it.
Once disabled, later we may want to activate it again. Global Platform spec define
a way to do this.

Let say we have javacard application with AID A00000001840840000, to lock it simply
this command through GSM 03.48 envelope command to SIMcard:


Meanwhile, once locked/disabled, simply send this GP command to enable it:


0x80: CLA
0xF0: INS for SET STATUS command
0x40: To indicate that this is a javacard applet application
0x83: Set to locked meanwhile 0x03: set to unlocked (state: SELECTABLE)
0x09: Length of AID to disabled/enabled is 9 bytes
A00000001840840000: this is the AID of applet

Written by adywicaksono

October 30, 2008 at 10:13 am

Remote File Management (RFM) on SIMCard

with 14 comments

What is the thing sold by GSM Operator to subscriber?

The answer is: SIMCard, a smartcard that personalized for telecommunication purpose. Yes, as we know physically GSM operator sell a SIMCard,  the rest are services upon it including SMS, call service, MMS, Voice Mailbox  and many things.

The next question, since SIMcard will be hold by customer inside their mobile phone, how could GSM operator manage the SIMcard remotely?  Things like managing javacard applet & filesystem inside the SIMCard. The answer is by OTA (over the air) using SMS and or CAT-TP bearer (GPRS based), but we will focus on the one using SMS (short message protocol).

GSM 03.48 define RFM and also RAM as standard mechanism for doing remote file management (RFM) and remote applet management. We are now focus on RFM, please note the implementation for this feature is vendor specific.

OK, let me give an example as our case study, one day we as operator need to do OTA campaign for updating file EF_SMSP (7F10/6F42) since the address of SMSC is now changed. As we know, based on 3GPP TS 31.102 document, EF_SMSP contains SMSC information that will be used by mobile phone for sending mobile originated  (MO) SMS. For example the content of file EF_SMSP (7F10/6F42) is now


You can refer to TS 31.102 document for the structure of EF_SMSP, but simply said the SMSC address defined here is: 85292040031. Now, operator want to change it to 85292040034 over the air.

So, technically we need to:
1. Prepare APDU for updating the file
2. Construct appropriate 03.48 + 03.40 APDU command
3. Send it over the air to customer

The result is, the file on customer SIMcard is updated silenty without user intervention.

Let us, go deeply with APDU for updating the file. Sequence for updating EF 7F10/6F42 record 1 from




is by executing these 4 APDU(s):


Details of each APDU is:

1) APDU for select 3F00 ==> A0 A4 00 00 02 3F 00
2) APDU for select DF 7F10 under MF 3F00 ==> A0 A4 00 00 02 7F 10
3) APDU to select EF 6F42 under DF 7F10 ==> A0 A4 00 00 02 6F 42
4) APDU to update record 1 of EF 6F42 to 534D532043454E545245FFFFE1FFFFFFFFFFFFFFFFFFFFFFFF07915892020430F4FFFFFFFF0000A9:

A0 DC 01 04 28 534D532043454E545245FFFFE1FFFFFFFFFFFFFFFFFFFFFFFF07915892020430F4FFFFFFFF0000A9

Now, we need to construct 03.48 SMS, means we need to ask our card vendor about these parameters:
1. TAR (toolkit application reference) of RFM applet
2. MSL (minimum security level setting)
3. Depend on MSL, maybe we need to know KiC & KiD of the card for RFM
4. Depend on how RFM implemented by card vendor, need to know how to pass APDU for updating the
filesystem. I assume we simply need to pass the APDU to RFM applet.

Let say,
1. the TAR is B0 00 10, please note this value is very specific to card vendor.
2. MSL is 0x25 means content must be encrypted and use CHryptographic CHecksum
3. Keyset to use is keyset 2 with algo Triple DES using outer CBC-Mode with 2 different keys and

KiC: 00112233445566778899AABBCCDDEEFF
KiD: 00112233445566778899AABBCCDDEEFF

Then we can generate APDU SMS-PP Download like this:

A0 C2 00 00 7B D1 79 02 02 83 81 06 04 00 21 43
F5 0B 6D 63 05 00 99 40 F1 7F F6 01 01 01 01 01
01 00 5D 02 70 00 00 58 15 06 01 25 25 B0 00 10
25 4E 56 31 DF D0 4D 77 DC 9C 64 90 30 E6 E8 97
DF 57 49 4B FC 45 11 71 56 2B 5E D3 FF C0 11 AA
62 CA 46 B6 4A 51 B0 A8 52 B3 CC 9F D0 6B 0D 95
C0 E8 DB E7 BF 44 25 39 67 90 B6 E2 22 BE C3 3F
EF 5B 35 2D 9D F7 97 22 15 08 67 F4 AA 29 A5 73

Next step is send this APDU over the air using SMS and the file inside SIMCard will be updated without user intervention.

Good luck 🙂

Written by adywicaksono

June 21, 2008 at 5:31 pm

Understanding GSM 03.48

with 10 comments

The structure of SMS-PP APDU including GSM 03.40 & GSM 03.48 header is defined in this structure:

The 3GPP TS 23.048 standard specifies the structure of Secure Packets in a general format and implementation using in particular Short Message Service Point to Point (SMS-PP).

The 3GPP TS 23.048 format is contained in the TP-UD (TP-User-Data) field in the 3GPP TS 03.40 format.

In the 3GPP TS 03.40 header, the TP-UDHI (User Data Header Indicator) bit value must be set to 1 to indicate that the initial bytes in the TP-User-Data field contain a header, and in particular, a 3GPP TS 23.048 header.

Please note that TS-SCA (Service Center Address) is optional

The TP-UD of SMS contains GSM 03.48 header and secure data, there’s 2 type of secure data:

  • Command Packet

Is a secured packet transmitted by sending entity to the receiving entity, containing secured application message.

  • Response Packet

Is a secured packet transmitted by receiving entity to the sending entity, containing secured response and possibly application data.

For Command Packet, the structure is like picture below:

As seen GSM 03.48 data include:

  • CPL (Command Packet Length): 2 octet

Indicate the number of bytes from and including the command header identifier to the end of the secured data, including any padding bytes

  • CHL (Command Header Length): 1 octet

Indicate the length of command header of packet data, means the number of bytes from and including the SPI to the end of RC/CC/DS.

  • SPI (Security Parameter Indicator): 2 octet

These 2 bytes define the security level applied to the input and output message, this include if counter verification and PoR (proof of receipt) are required along with the associated security level. If the SPI indicates that a specific field is unused, the sending entity sets the contens of this field to zero and the receiving entity ignores the contents. For example, if there is no counter check, the counter value is set to 0x00.

If the SPI indicates that no RC, CC, or DS is present in the command header then the RC/CC/DS field is not present (length of zero)

First byte of SPI is described in picture below:

Second byte of SPI is:

  • Ciphering Key Identifer (KiC): 1 octet

Keyset Identifier and algorithm for encryption for data.

  • Key Identifer (KiD): 1 octet

Keyset Identifier and algorithm for encryption for RS/CC/DS.

The coding for KiC and KiD is shown below:

  • Toolkit Application Reference (TAR): 3 octets

The TAR is part of the 23.048 header that identifies and triggers the Over The Air (OTA) feature, which is an application on the Java Card™. Each application

has its own TAR, which cannot be duplicated on the same card.

The TAR of a SIM toolkit applet is coded on three bytes and is defined in ETSI

TS 101 220 as the 13th, 14th and 15th byte of the applet’s AID.

If these bytes are not present in the AID, the TAR is not defined for the SIM toolkit applet and cannot be triggered on a formatted SMS PP Envelope.

The remote applet management TAR is standardised in 3GPP TS 23.048 and

ETSI TS 101 220 as 00h 00h 00h. All card manufacturers must support this value. Since the TAR value for RFM is not yet standardised, operators should

Inform the card manufacturers as to which TAR value is required for RFM.

To offer interoperability, all card manufacturers must obviously provide the

same value for referencing applets. The SIM Alliance suggests that operators

define their own TAR values.

  • CNTR (Counter): 5 octets

This counter is used for replay detection and sequence integrity. The presence and verification of this information are defined in the SPI bytes. Even if the SPI bytes require no counter available, the five counter bytes must be present in the TS 23.048 header

The following rules apply to counter management, with the aim of preventing replay and synchronization attack:

The SE sets the counter value; it is only to be incremented

When the counter value reaches its maximum value, the counter is blocked

If the security checks on an incoming command packet are successful and the counter mode used is mode 3 or 4 (b5b4 = 10 or b5b4 = 11), the card counter is updated using the counter of the incoming command packet.

If the security checks on an incoming command packet are successful and the counter mode used is mode 0 (No counter available mode: b5b4 = 00h), the five-byte counter must be present in the message, but is not checked and the card

• For mode 1 (Counter available: no replay or sequence checking: b5b4 = 01h), behavior depends on the application.

Example SMS-PP APDU:


Please note that this secure data & RS/CC/DS is encrypted with KiC & KiD:

KiC: 30 42 30 42 30 44 30 44 30 45 30 45 30 46 30 46
KiD: 01 23 45 67 89 AB CD EF 10 02 76 FE DC BA 01 23


A0C20000: This is the APDU command for SMS-PP (Point to Point) Download
^^ ->  0xA0: CLA of APDU
  ^^ -> 0xC2: INS of APDU
    ^^ -> 0x00: P1 of APDU
      ^^ -> 0x00: P2 of APDU

^^ -> 0x4E is length of data followed
  ^^ -> 0xD1 is a TAG of APDU data
    ^^ -> 0x4C is length of data followed
      ^^ -> 0x82 is a TAG that indicate Device Identities
        ^^ -> 0x02 is a TAG that indicate length of data
          ^^ -> 0x83 is a source device (Network)
            ^^ -> 0x81 is a destination device (UICC/SIMCard)

This now is is GSM 03.40 header

^^ -> 0x8B is TAG that indicate starting of SMS-TPDU data
  ^^ -> 0x46 is length of data followed
    ^^ -> 0x40 or in binary 01000000
          The bit structure numbering is like this
          TP-MTI  is bit no. 1 & bit no. 0 = 00 = type MS-Delivery
          TP-MMS  is bit no. 2 = 0 = no more message to send
          TP-UDHI is bit no. 6 = 1 = there’s header in TP-UD
          TP-RP   is bit no. 7 = 0 = no reply path 

      ^^ -> 0x08: Length of TP-OA is 8 digit
        ^^ -> 0x81: TON/NPI
          ^^^^^^^^ -> 55667788: TP-OA in BCD swapped format (8 digit)
                  ^^ -> 0x7F: TP-PID SIM data download

^^ -> 0xF6: TP-DCS
  ^^^^^^^^^^^^^^ -> TP-SCTS:
                ^^ -> 0x35: TP-UDL: User Data Length 53 octet

Now the TP-UD of SMS


^^ -> 0x02: UDHL
  ^^ -> 0x70: IEI (Information Element Identifier)
    ^^ -> 0x00: IEDL (Information Element Identifier Data Length)

^^^^ -> 0x00 0x30: CPL (Command Packet Length) -> 48 octet
    ^^ -> 0x15: CHL (Command Header Length) -> 21 octet
      ^^^^ -> 0x0E 0x19: SPI (Security Parameter Indicator)
              0x0E = 01110 (in binary form) means:
		-	Cryptographic Checksum
		-	Encryption applied
		-	Counter Available, replay or sequence not checked

              0x19 = 11001 (in binary form) means:
		-	PoR required to be sent to sending entity
		-	PoR response with CC Applied
		-	PoR to be encrypted

          ^^ -> 0x25: KiC Identifier
                0x25 = 100101 (in binary form) means:
		-	DES
		-	Triple DES in outer CBC-Mode using 2 different keys
		-	Keyset to be used is 0x02

            ^^ -> 0x25: KiD Identifier
                  0x25 = 100101 (in binary form) means:
		-	DES
		-	Triple DES in outer CBC-Mode using 2 different keys
		-	Keyset to be used is 0x02

              ^^^^^^ -> 0x000000: TAR (Toolkit Application Reference)
                        This is the default TAR for Remote Applet

^^^^^^^^^^ -> 5 octets of CNTR
          ^^ -> 0x1B: 1 octet of PCNTR
            ^^^^^^^^^^^^^^^^ -> D80CABB2C3F3903D: 8 octets of RS/CC/DS

And this is the secure data:

Written by adywicaksono

May 21, 2008 at 2:00 pm

Sending WAP Push – Service Indication

with 3 comments

I believe many of you ever receive this kind of SMS, normally content provider send java games, midi ringtone, or any multimedia content usin this type of SMS.

Actually how they send it is normally like picture below:

At first stage Push Initiator will send Service Indication in XML format (process 1) into Push Proxy Gateway (PPG) and then PPG will build a WAP Push SMS and send it to user (2).

When User receive it (3), it will be simply like normal SMS but contains a URL that could be simply opened. If user try to open it, then the rest is normally WAP session or TCP/IP session (4) and it’s actually like normal mobile browsing (5)

The algorithm use by mobile phone when receiving WAP Push Service Indication is like this:

Now I don’t want to discuss about how SI XML is sent by push initiator, but how PPG build WAP Push Service Indication. Actually the SI XML sent by push initiator is like this:

<?xml version="1.0"?>
<indication href=""
You have 4 new emails

PPG will then build WBXML or Wireless Binary format for that XML data, and it’s like this


That code above is hexadecimal code where 2 digit represented 1 byte hexadecimal digit range from 0x00 to 0xFF.

The detail of this encoding is:

^^ -> 0x02: Version of WBXML is 1.2
  ^^ -> 0x05: SI 1.0 Public Identifier, this indicated that document is a SI version 1.0 document
    ^^ -> 0x6A: Character Set is UTF-8
      ^^ -> 0x00: Table string length is 0x00
        ^^ -> 0x45: This is a WBXML coding for tag <SI> with content only (No attribute)
	  ^^ -> 0xC6: This is a WBXML coding for tag <indication> with content & attribute
	    ^^ -> 0x0D: This is a WBXML coding for attribute href="http://www."
	      ^^ -> 0x03: This is an indicator that a string is following ended with 0x00 (NULL)
	        ^^^^^^^^ -> 0x78 0x79 0x7A 0x00: This is a hex value of string "xyz" ended with 0x00 (NULL)

^^ -> 0x85: This is a WBXML coding for string ".com/"
  ^^ -> 0x03: This is an indicator that a string is following ended with 0x00 (NULL)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -> 0x656D61696C2F3132332F6162632E776D6C000
                                             Hex representation of string "email/123/abc.wml"
					     ended with 0x00 (NULL)

^^ -> 0x0A: This is a WBXML coding for attribute "created="
  ^^ -> 0xC3: This is an indicator that an OPAQUE data (data with Length Value format)
    ^^ -> 0x07: Length of OPAQUE data
      ^^^^^^^^^^^^^^ -> 0x19990625152315 (7 octet) this is represent date "1999-06-25 15:23:15"

^^ -> 0x10: This is a WBXML coding for attribute "expires="
  ^^ -> 0xC3: This is an indicator that an OPAQUE data (data with Length Value format)
    ^^ -> 0x04: Length of OPAQUE data
      ^^^^^^^^ -> 0x20990603 (4 octet) this is to represent date "2099-06-30 00:00:00"
              ^^ -> 0x01: This is to indicate end of attribute for current TAG
	                  so no more attribute inside tag <indication>

^^ -> 0x03: This is an indicator that a string is following ended with 0x00 (NULL)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -> 0x596F7520686176652034206E657720652D6D61696C73000
                                       This is a hex representation of string:
				       "You have 4 emails" ended with 0x00 (NULL)
^^ -> 0x01: this is to indicate end of attribute for current TAG (should refer to </indication> )
  ^^ -> 0x01: this is to indicate end of attribute for current TAG (should refer to </si> )

Now, PPG will generate WSP (Wireless Session Protocol) header as defined in WAP spec ( like this:



This WSP header is actually encoded like this:

^^ -> 0x01: This is Push Identifier
  ^^ -> 0x06: WSP PDU Type = Push
    ^^ -> 0x04: Length of octet followed 4 bytes
      ^^^^^^^^ -> 03AE81EA

03AE81EA itself is encoded like this:
^^ -> Length of content-type + header (3 octets)
  ^^ -> This is the content type of WAP Push (application/vnd.wap.sic)
        generated by doing OR operation with 0x80 like this
	1. Value of application/vnd.wap.sic is 0x2E
	   0x2E = 00101110
	   0x80 = 10000000
	   ------------------ OR
	   0xAE = 10101110

    ^^ -> 0x81: This is a header "Accept-Charset" (0x01) -> become 0x81
                since 0x81 = 0x01 | 0x80
      ^^ -> 0xEA: This is a value of header "Accept-Charset" which is UTF-8 (hexa code 0x6A)
                become 0xEA since 0xEA = 0x6A|0x80

The job is not done yet, PPG will now build WDP (Wireless Datagram Protocol) like this


Where actually this WDP is refer to this encoding:

^^ -> 0x05: IEI (Application Port Schema Addressing, 16 bit), see GSM 03.40
  ^^ -> 0x04: Length of octet following (4 bytes)
    ^^^^ -> 0x0B84: Destination Port of datagram = 2948 in decimal
                    Mobile phone which support WAP Push will normally listen
		    on WDP port 2948 to receive WAP Push 

		    This is the standard port for WAP Push connectionless
		    session service
        ^^^^ -> 0x23F0: Source port of datagram: the value here
	                is refer to Connectionless WAP Browser Proxy Server

So now we have combination WSP+WDP+SI layer to send as WAP Push:

05040B8423F0 (WDP Layer)
01060403AE81EA (WSP Layer)
5231510C304209906030103596F7520686176652034206E657720652D6D61696C73000101 (SI layer)

If you try to calculate the number of octet there is 89 octets,means we can send it using 1 SMS only no need for sending long sms, since 1 SMS can contains 140 octets of data.

Now PPG will send it to end user by completing GSM 03.40 header for this data, like this



55010C9126582602680800F5A75A   --> GSM 03.40 Header
06                             --> UDHI Length
05040B8423F0                   --> WDP Layer
01060403AE81EA                 --> WSP Layer

6D6C000AC3071999062515231510C    ==> SI Layer

Now if send it using AT command like this:



Our mobile phone will receive the WAP Push like this:

Please note, the WAP Push application behaviour for each mobile phone may different each others.

Written by adywicaksono

May 11, 2008 at 7:58 am

Display Text using javacard on SIM card

with 13 comments

TS 31.111 define USIM Application Toolkit for SIMCard, one feature defined there
is proactive command. What’s is proactive command? Proactive command is
a mechanism whereby the UICC/SIM Card can initiate actions to be taken by the ME
(mobile equipment). These actions include:

– displaying text from the UICC to the ME;
– sending a short message;
– setting up a voice call to a number held by the UICC;
– setting up a data call to a number and bearer capabilities held by the UICC;
– sending a SS control or USSD string;
– playing tone in earpiece;
– initiating a dialogue with the user;
– USIM initialization request and notification of changes to EF(s);
– providing local information from the ME to the UICC;
– providing information about the additional card reader(s) (if class “a” is supported);
– managing timers running physically in the ME;
– running an AT command received from the UICC, and returning the result to the UICC
(if class “b” is supported);
– sending DTMF;
– requesting the ME to launch the browser corresponding to a URL. (if class “c” is supported);
– establishing and managing a bearer independent protocol (if class “e” is supported).

OK, I will start sharing some javacard application that do a display text proactive command
it will be our helloworld smartcard application :). Details of proactive command for
displaying text is defined like this:

This command instructs the ME to display a text message, and/or an icon. It allows the UICC to
define the priority of that message, and the text string format.

Two types of priority are defined:
– display normal priority text and/or icon on screen;
– display high priority text and/or icon on screen.

The text string can be in one of three formats:
– packed format in SMS default alphabet
– unpacked format in SMS default alphabet
– UCS2 alphabet format

NOTE: The text string may contain up to 240 bytes.

TLV (Type Length Value) format of Display Text is defined like this:


So how to implement it? Here it is:

package proactive_cmd;

 * Imported packages
import sim.toolkit.*;
import sim.access.*;
import javacard.framework.*;

public class display_text extends javacard.framework.Applet implements
		ToolkitInterface, ToolkitConstants {
	// Mandatory variables
	private SIMView gsmFile;
	private ToolkitRegistry reg;

	// Main Menu
	private byte idMenu1;
	private byte[] Menu1;

	 * Constructor of the applet
	public display_text() {
		// Get the GSM application reference
		gsmFile = SIMSystem.getTheSIMView();

		// Get the reference of the applet ToolkitRegistry object
		reg = ToolkitRegistry.getEntry();

		Menu1 = new byte[] {
				(byte) 'D', (byte) 'i', (byte) 's', (byte) 'p',
				(byte) 'l', (byte) 'a', (byte) 'y', (byte) ' ',
				(byte) 'T', (byte) 'e', (byte) 'x', (byte) 't' };
		// Define the applet Menu Entry
		idMenu1 = reg.initMenuEntry(Menu1, (short) 0, (short) Menu1.length,
				PRO_CMD_SELECT_ITEM, false, (byte) 0, (short) 0);

	 * Method called by the JCRE at the installation of the applet
	 * @param bArray the byte array containing the AID bytes
	 * @param bOffset the start of AID bytes in bArray
	 * @param bLength the length of the AID bytes in bArray
	public static void install(byte[] bArray, short bOffset, byte bLength) {
		// Create the Java SIM toolkit applet
		display_text StkCommandsExampleApplet = new display_text();
		// Register this applet
		StkCommandsExampleApplet.register(bArray, (short) (bOffset + 1),
				(byte) bArray[bOffset]);

	 * Method called by the SIM Toolkit Framework
	 * @param event the byte representation of the event triggered
	public void processToolkit(byte event) {
		EnvelopeHandler envHdlr = EnvelopeHandler.getTheHandler();

		// Manage the request following the MENU SELECTION event type
		if (event == EVENT_MENU_SELECTION) {
			// Get the selected item
			byte selectedItemId = envHdlr.getItemIdentifier();

			// Perform the required service following the Menu1 selected item
			if (selectedItemId == idMenu1) {

	 * Method called by the JCRE, once selected
	 * @param apdu the incoming APDU object
	public void process(APDU apdu) {
		// ignore the applet select command dispached to the process
		if (selectingApplet()) {

	 * Manage the Menu1 selection
	private void menu1Action() {
		// Get the received envelope
		ProactiveHandler proHdlr = ProactiveHandler.getTheHandler();

		// Display the "Menu1" message text
		// Initialize the display text command
		proHdlr.initDisplayText((byte) 0x00, DCS_8_BIT_DATA, Menu1, (short) 0,
					(short) (Menu1.length));

The bold font is the code to display text using proactive command. The result on my Nokia 3660 is like this:


If we try to trace the APDU, it will be like this

D0 18 81 03 01 21 00 82 02 81 02 8D 0D 04 44 69 73 70 6C 61 79 20 54 65 78 74


0xD0: this is proactive command tag
0x18 : length of these bytes “81 03 01 21 00 82 02 81 02 8D 0D 04 44 69 73 70 6C 61 79 20 54 65 78 74” which is 24 bytes
0x81: Command details tag, see picture below


0x03: length of value of command details tag “01 21 00”
0x01: command number
0x21 0x00: Display text (normal priority, clear message after a delay)
0x82: Device identities tag, see below


0x02: Length of device identities values which is “81 02”
0x81: means source is UICC or SIMCard
0x02: means destination is display which is on mobile phone
0x8D: Text string tag, see picture below


0x0D: length of text string tag value, which is “04 44 69 73 70 6C 61 79 20 54 65 78 74”
0x04: DCS or data coding scheme (defined in TS 23.038)
44 69 73 70 6C 61 79 20 54 65 78 74: hex representation of string “Display text”, use hex2string tools to convert from string to hex vice versa

Uh.. complicated.. yes telco stuff is complicated, that’s why it’s expensive hehehehe

Written by adywicaksono

February 9, 2008 at 3:20 pm

SIM Card Filesystem

with one comment

SIM card is one of smartcard type use widely on telecomunication sector. As a smartchip which has operating system, CPU, RAM, it also has a filesystem. You need to read 3GPP TS 51.011 about Specification of the Subscriber Identity Module – Mobile Equipment (SIM – ME) interface.

Now I am going to share a picture of a filesystem on a working SIMCard, sorry some secret information is not revealed :). Moreover this picture is taken from commercial product Gemalto Card Admin.

simcard content

For each details of those file, please read the above spec

Written by adywicaksono

February 2, 2008 at 2:53 am

Posted in Mobile, SmartCard

What happened when an SMS sent from mobile phone to you?

leave a comment »

From 3GPP TS 09.02

See this picture

+-----+  +-----------+   +------+   +-------------+   +----+
¦ MS  ¦  ¦ Servicing ¦   ¦ VLR  ¦   ¦Interworking ¦   ¦ SC ¦
¦     ¦  ¦MSC or SGSN¦   ¦      ¦   ¦    MSC      ¦   ¦    ¦
+-----+  +-----------+   +------+   +-------------+   +----+
   ¦         1.¦             ¦              ¦           ¦   
   + - - - - ->¦           2.¦              ¦           ¦   
   ¦           +------------>¦              ¦           ¦   
   ¦           ¦ 3.          ¦              ¦           ¦   
   ¦           +<------------¦              ¦           ¦   
   ¦           ¦             ¦            4.¦           ¦   
   ¦           ¦-------------+------------->¦         5.¦   
   ¦           ¦             ¦              + - - - - ->¦   
   ¦           ¦             ¦              ¦6.         ¦   
   ¦           ¦7.           ¦              +<- - - - - ¦   
   ¦8.         +<------------+--------------¦           ¦   
   +< - - - - -¦             ¦              ¦           ¦   
   ¦           ¦             ¦              ¦           ¦   

1)	Short Message (GSM 04.11).
        SMS sent from MS (mobile phone) to Servicing MSC/SGSN
	see spec GSM04.11 for details


        VLR response with MAP_SEND_INFO_FOR_MO_SMS_ACK to SMSC

        SMSC forward SMS to IMSC
5)	Short message (TS GSM 03.40).        
6)	Short message Acknowledgement (TS GSM 03.40).
        IMSC send ACK to SMSC

8)	Short Message Acknowledgment (GSM 04.11).
        SMSC send ACK to mobile phone if  
(*)	Messages 2) and 3) are not used by SGSN.

I will cover the detail soon :)

Written by adywicaksono

January 3, 2008 at 5:05 am

Posted in Mobile, Telco - GSM