The seminal SIM standards are GSM 11.11 and GSM 11.14. You will hear these standards referred to frequently in discussions of the SIM. The SCP evolutions of these two oldies but goodies are ETSI TS 102.221 and ETSI TS 101.223, respectively.

GSM 11.11 is the original SIM standard and covers the SIM data files and application protocol data units (APDUs) that are sent by the handset to the SIM in establishing network access and subscriber account authentication. GSM 11.11 is based on ISO 7816-4 and certainly credits this standard to be its genesis, at least in public. As you read GSM 11.11, you will find all of your old APDU friends from ISO 7816-4. Where ISO 7816-4 is vague or provides wiggle room for proprietary implementations or hollow claims of standards compliance, GSM 11.11 is specific and says exactly how it shall be.

GSM 11.14 describes a quiet smart card revolution that took place in the mid-1990s. You will recall that from the dawn of smart card time, the smart card was the slave and the terminal was the master. The card spoke only when spoken to and did only what it was bid to do. GSM 11.14 turns history on its head and describes commands that the SIM can send to the handset. It was this document, GSM 11.14, that transformed the smart card in the GSM mobile telephone from a simple data store and session key computer to a full-fledged network-aware application platform. Two business necessities and two elegant insights into their solution provided the explosive power for this revolution.

First, when the network operator wanted to perform some administrative functions on the SIM, he couldn't very well just tell the subscriber to drop by network headquarters at an appointed time. The SIM was connected to a network device—the handset—so why couldn't the administration be done over the air? The instructions to be followed by the SIM had to go through the network and the handset right to the SIM, untouched and uninterpreted by these intermediate nodes. This brought the SIM itself onto the network. It was no longer just a peripheral on the handset, but a network node engaging in direct, end-to-end communication with network central.

Second, if the SIM was going to be a viable network node, it had to be able to initiate activity and not just be a slave to duty. Up to this time, a basic tenet of smart cards was that code running inside the smart card only needed to respond to commands from outside. GSM 11.14 introduced the radical notion that on-card code could initiate calls on services outside the card. In one flourish of the standard writer's pen, the GSM handset was transformed from a demanding master to a mere docking station.

The two technical innovations that converted these standards requirements to street realities were called event download and proactive commands. Event download requires the handset to tell the SIM about events that are taking place on the handset itself and on the network. Proactive commands let the SIM tell the handset what to do. Event download was invented by Swisscom and proactive commands were invented by BT Cellnet. For a detailed description of their discoveries, see Mobile Application Development with SMS and the SIM Toolkit (Guthery and Cronin, 2001).

These two new smart card usage conventions—event download and proactive commands—form the foundation of the SIM Application Toolkit, which we discuss in detail a bit later. The first convention governs the flow of information and control from the mobile equipment to the card and the second governs the flow of information and control from the card to the mobile handset. Both were simple straightforward elaborations of existing practice, but when used together, caused a revolution in the use of the GSM mobile phone.

How can five simple APDUs create an application platform where none existed before? There are hundreds of calls on the Windows or Linux application programming interface (API), for example. Are these guys just making heavy water?

We will discover that these five simple ETSI TS 102.221 APDUs aren't really so simple after all and that they pack a lot of information and functionality into their little frames. What is simple, however, is the model of computation for the use of these APDUs.

First, early in the initial interaction between a handset and a SIM, the handset sends the SIM the first of the five platform APDUs, the TERMINAL PROFILE APDU. The data field of this APDU tells the SIM exactly what the terminal can do. The implicit semantics of the APDU are “Here's what I, the handset, am capable of. If you ask me to do anything else, you'll get an error return.” Table 8.5 is a list of the capabilities the handset can tell the SIM about in the TERMINAL PROFILE APDU. The handset sends up to 160 bits (20 bytes) to the SIM in the data field of the TERMINAL PROFILE APDU and sets a bit to 1 if it (the handset) has the associated capability and to 0 if it doesn't. This makes for a lot of information packed into a little package.

Figure 8.5. Data Field of the TERMINAL PROFILE APDU

The TERMINAL PROFILE APDU is half of the getting-to-know-you protocol. The other half is the terminal finding out what the SIM can do. The terminal accomplishes this by using a plain old READ BINARY APDU to read the contents of a file called the SIM service table. This is file “6F38” in the SIM ADF. Table 8.6 lists the format of this file. Just like the TERMINAL PROFILE data field, the SIM sets a bit to 1 in this file if it can perform a particular function and to 0 if it can't. Table 8.7 gives the services.

Figure 8.6. Format of the SIM Service Table Transparent File (from 3GPP TS 31.102)

At the end of this mutual introduction phase of the SIM Toolkit model of computation, the handset and the SIM each know what the other can do and will avoid asking the other to do something that it knows it can't do. Now they can get down to work.

Recall that the two technical capabilities that we are creating are event download and proactive commands. Event download is where the terminal tells the SIM about something that happened—an event of some sort. Proactive commands are where the SIM tells the handset to do something. The ENVELOPE APDU implements event download and the FETCH, TERMINAL RESPONSE, and STATUS APDUs implement proactive commands. Let's look at event download first because that's the easy one.

The ISO 7816-3 T=0 and T=1 communication protocols between the handset and the SIM let the handset talk to the SIM just about anytime it wants to. It just sends the SIM an APDU. In order to tell the SIM about an event, it uses the escape APDU from ISO 7816-4, the ENVELOPE APDU. The ENVELOPE APDU was first defined as a way to overcome deficiencies in the secure messaging mechanisms of ISO 7816-4; however, it is a way to send a random undifferentiated blob of data to a smart card. Unlike UPDATE RECORD or VERIFY PIN, which carry data intended for a specific use, namely the use defined by the APDU, the semantics of ENVELOPE are more like “Here's a blob of data. I assume you know what to do.” What GSM 11.14 and ETSI 102.223 do is organize and give meaning to the data field of the ENVELOPE APDU when it is sent to a SIM smart card.

As you recall, ISO 7816-4 establishes, roughly speaking, a one-to-one relationship between what you want the card to do and a command to ask it to do it. READ BINARY reads from a file, VERIFY PIN checks a PIN value, and so forth. But the folks that wrote ISO 7816-4 understood well that they couldn't imagine all possible uses of a smart card, so they built themselves and all the rest of us an escape hatch to the future: the ENVELOPE command. The design intent of ENVELOPE was to be able to put proprietary and special-purpose information and commands inside a standard ISO 7816 command “envelope” in order to transmit them to the card.

In keeping with the over-arching policy of being as compatible as possible with existing smart card standards, the authors of GSM 11.14 chose the ENVELOPE command to get all sorts of non-APDU–based information to the SIM.Thus, whether it is message traffic coming from the user, the handset, or somewhere out on the network, it is moved to the SIM tucked inside an ENVELOPE command. There are a number of different variants of the SIM ENVELOPE command, but the three primary ones correspond to these three sources of message traffic for the SIM. We discuss these immediately after we look at the ENVELOPE command itself.

The syntax of the ISO 7816-4 ENVELOPE APDU is simplicity itself:

There is no P1 or P2—just a CLA and an INS, a length, and a data field. The entire message to be loaded into the smart card—in the case at hand, the SIM—is put into the data field. The thinking was that if you wanted to dream up a new smart card command, you could still use all the smart card readers in the field by encapsulating or tunneling your command in the ENVELOPE command.

The first type of SIM event download ENVELOPE APDU is for messages from the user and is called ENVELOPE (MENU SELECTION). The data field contains an index of the menu item that was selected and assumes that the SIM kept track of the list of choices that were offered to the user.

The second type of event comes from the handset itself and consists of the handset informing the card of events that are taking place upstairs. Examples of such events are pressing a key or initiating a call. An ENVELOPE APDU that contains such event notifications is called ENVELOPE (EVENT DOWNLOAD).

The final type of the ENVELOPE APDU for events originating in the network (e.g., the host-side or off-card component of your application sitting on a server somewhere) is called ENVELOPE (SMS-PP DOWNLOAD).

Of the three event types, SMS-PP DOWNLOAD is the most useful and the most powerful from the point of view of application construction. Using this event download, the off-card application communicates with the on-card application by sending it a short message using the network's short message system (SMS). Coding in the SMS message tells the handset to pack the entire SMS message into an ENVELOPE command and pass it onto the SIM. SMS-PP DOWNLOAD can also be used to load new applications onto the SIM.

Table 8.8 is a list of the all the event download ENVELOPEs defined in 3GPP TS 31.111. There are 13 for event notification, 2 for short message reception, 2 for call control, and 1 each for menu selection and timer expiration.

The innovation in event download wasn't in the invention of new technique or the promulgation of a new standard. It was using a piece of existing smart card technology, the ENVELOPE APDU, for a revolutionary purpose: to carry information from outside the SIM to inside the SIM to enable the SIM to respond to this information based on the policies it contained. The original use for which Swisscom invented event download was to silently let the SIM redirect calls being placed on the handset in order to use the network more efficiently. When combined with proactive commands that we describe next, event download turns the SIM from a passive data store into an integral and interactive part of the mobile application framework.

Even with event download, the SIM is still reactive rather than proactive. It can react to the events that it is told about but it can't create an event. You can easily imagine tinkering with the communication protocol between the handset and the SIM to let the SIM initiate communication, but any changes had to be a graceful evolution of the existing SIM because new SIMs had to work in all the old handsets. In particular, a proactive SIM had to live within the ISO 7816-4 framework on which the existing SIMs were built. This meant that at the lower levels of the communication protocol, the handset had to be the master and the card was still the slave.

In order to turn the tables at the higher levels, Colin Hamling of BT Cellnet, then vice-chairman of SMG9, the ETSI committee charged with solving the over-the-air unlatching problem, proposed something very modest and innocent but with far-reaching consequences: a new status word.

Here are the words taken directly from GSM 11.14 version 5.9.0 Release 1996 that gave the SIM a voice:

In other words, upon receiving a “0x91xx” status code, the handset is now obliged to respond with a FETCH APDU to find out what the card wants it, the handset, to do... and, what's more, it was obliged to do it. Gasp! The slave presumes to issue commands to the master.

Thus, at the lower levels of the T=0 protocol, the handset was still the master, but at the upper levels, the smart card was now in charge. This modest and yet elegant addition to the set of ISO 7816-4 status words transformed the SIM from a floppy disk with an attitude to a secure mobile computer with a perfectly useable human interface and some truly awesome communication capabilities. But one more conceptual leap had to be taken before this would be an application platform. Kristian Woodsend, who worked for Colin Hamling at the time, took this leap.

What had to happen was that the commands the SIM could give to the handset had to be standardized. This standardization, together with the standardization of event downloads, would mean that any SIM with applications could work with any handset. This was where we started when the SIM was just a data store and this had to be where we ended when the SIM became an application platform.

The recognition of the need for a general way to build mobile applications using the SIM was in the air in the middle of 1994. Up to that time, each new SIM application required application-specific and often operator-specific modifications to the handset; this was obviously a very large impediment to rolling out new applications. A general-purpose way to control the phone from the SIM had been discussed briefly at SMG9 #2 of that year and a work item titled “Proactive SIM” approved at the SMG9 #12 plenary meeting.

At the same time, discussions were being held within SMG9 on a general-purpose and standardized way to extend Swisscom's “SicapNATEL” technique for the data on the SIM. This work item was called “SIM Data Download.” The synergy between these two work items was quickly realized—applications needed to be able to catch data and downloaded data needed someone to catch it. These two tasks were combined in early 1995 into the SIM Application Toolkit work item, which was approved at the SMG9 #14 plenary meeting.

The description of the SIM Application Toolkit work item was:

Colin Hamling was the rapporteur of the original SIM Application Toolkit work item but this duty was passed to Kristian Woodsend, also of BT Cellnet, at SMG9 #6 in September 1995. Kristian set to work to create the first draft of GSM 11.14, which was to combine the ideas of Swiss Telecom PTT for data download, the need for standardized unlatching, and above all else, a standard way for the SIM to give commands to the handset. The first draft of GSM 11.14 was presented to SMG9 #7 at the end of November 1995, a mere two months later.

A GSM handset was already obliged to send a STATUS APDU to the SIM every 30 seconds. The primary purpose of the STATUS command was to make sure the SIM was still there. If it wasn't, the call that was in progress was immediately terminated and the handset dropped off the network. With this new status word, if the card had a command waiting for the handset, it would respond to the STATUS command with a “91xx” as previously. Otherwise, it would just respond with “9000” as before.

So that's the story of five little APDUs and how they turned the SIM smart card from a data store into an application platform: TERMINAL PROFILE, to tell the SIM about the capabilities of the docking station it has been plugged into; the event download ENVELOPE, to tell it what is going on; a new status word with two new APDUs, FETCH and TERMINAL RESPONSE, to let it initiate action; and finally, an update of the STATUS APDU to let it get a word in edgewise. This is a motley set of technical bits and pieces to be sure, but when working together, they create what could turn out to be the salvation of many a network operator's business: a mobile application platform. The remainder of this chapter is about putting this motley crew to work for your applications.

Things have moved on since GSM 11.14. The proactive command set is now called the Card Application Toolkit and the commands themselves are codified in ETSI TS 102.223, which is under the care of ETSI's Smart Card Platform project.

Table 8.9 contains a list of the 32 proactive commands defined in the latest version of ETSI TS 102.223.

Even without knowing the details of these commands, you can see that there is a lot that your mobile application can do. The Card Application Toolkit is a very rich application development environment, far richer, for example, than the WAP application environment. You can find all the grisly details in ETSI TS 102.223, but a couple of these commands deserve a brief description here so you can get a sense of what is possible.

The POLLING INTERVAL command lets you set how frequently the handset polls the SIM with the STATUS command. You can't set it to a value less than the 30 seconds called for in other GSM standards, but if you have a lot of work for the handset to do, you can set the interval to less than 30 seconds. An issue that hasn't yet been fully resolved is: Who is ultimately in charge here? The handset? The 11.11 part of the SIM? The SIM application? The WAP browser? The network? The user? The PC to which the handset is connected? The server sending commands to the SIM? There are a lot of entities demanding space on the screen and the user's attention and virtually no machinery in place for them to coordinate or cooperate their activities.

The POWER ON CARD, PERFORM CARD APDU, and POWER OFF CARD commands are all meant to let the application on the SIM control and communicate with another smart card plugged into the handset. POWER ON and POWER OFF obviously tell the handset to provide power to the second card and to remove power from the second card, respectively. The PERFORM CARD APDU lets the SIM send an APDU to the second card by way of the handset.

The TERMINAL RESPONSE to this command is the reply of the second card. The vision was that the second card could be a credit card or an e-cash card of some sort that could be used in conjunction with SIM applications to conduct e-commerce. Unfortunately, dual-slot handsets haven't become widely available, so this vision is still more of a dream than a reality.

The PROVIDE LOCAL INFORMATION command lets the SIM application acquire data about the current environment from the handset. Included in the data available is information about the current location of the handset so that the SIM application can be sensitive to the geography in which it finds itself. These are called location-based applications, and there is a lot of work going on in this area. The resolution of the mobile's location available to the SIM is not as good as, say, GPS or even what is available to the network operator, but it is a beginning and certainly sufficient to get the creative juices flowing.

DISPLAY TEXT, GET INKEY, GET INPUT, PLAY TONE, SELECT ITEM, SETUP IDLE MODE TEXT, and SETUP MENU are all human interface commands that access the screen and the keypad on the handset. While there are certainly standards for handsets as well as for the SIM card, they aren't so tight that you can write fully handset-independent applications. There is still enough variation in screen size, display capability, and keypad layout that you will want to test your SIM application with a number of different handsets before you send it out into the world.

OPEN CHANNEL, RECEIVE DATA, SEND DATA, GET CHANNEL STATUS, and CLOSE CHANNEL enable your SIM application to communicate with servers out on the Internet. There is not yet a full TCP/IP stack on the SIM but this is coming.

Finally, SEND DTMF, SEND SHORT MESSAGE, SEND SS, SEND USSD, and SETUP CALL provide the means for your application to communicate with the outside world using the telephone network as opposed to the Internet. Of particular note is SEND SHORT MESSAGE, which enables your application to send a text message of up to 140 characters to any other GSM phone. SETUP CALL opens a voice channel to any other telephone number and SEND DTMF sends the touch pad tones down the wire. You can doubtless imagine some creative uses of this capability.

The Card Application Toolkit is a very capable application platform that provides some unique and very useful services to your mobile application. It is understandable why network operators don't let just anybody download applications to their SIMs. In fact, getting your applications into use—and thus turning them into money—will loom as just as big a challenge as creating the applications in the first place.

There is a main menu on the SIM that displays a pick list of all of the available applications. When the Rapid Reorder selection is made from this menu, an ENVELOPE (MENU SELECTION) APDU is sent from the handset to the SIM containing the index of the menu item selected. The SIM card operating system knows that the index selected is Rapid Reorder and activates our application.

Rapid Reorder uses the list of product categories to build a SELECT ITEM proactive command and passes this command back to the operating system. The operating system returns a “91xx” to the handset in response to its ENVELOPE command and the handset turns around and issues a FETCH command to retrieve our SELECT ITEM command.

After presenting the category list to the user and getting a pick, the handset issues a TERMINAL RESPONSE command to the SIM containing the list index of the item picked. The operating system remembers that it was the Rapid Reorder application that sent the proactive command and calls Rapid Reorder with the reply from the handset.

Rapid Reorder goes around this loop once more using the list of products in the chosen category to get a selection of the exact product that is being reordered. The Rapid Reorder application uses the GET INKEY proactive command to get a “Y” or “N” response to the question about whether the usual quantity of items should be ordered.

After acquiring the quantity either from an internal table (“Y”) or asking for a numeric input using GET INPUT (“N”), the Rapid Reorder application uses the GET INKEY proactive command again to display the entire transaction and get back another “Y” or “N” response. Assuming all the information is correct and that “Y” is chosen, Rapid Reorder formats the transaction, retrieves the phone number of the distributor associated with the category, and uses the SEND SHORT MESSAGE proactive command to send the transaction to the distributor.

When the transaction gets to the off-card application and is entered into the distributor's order entry system, the off-card Rapid Reorder application sends an SMS back to the mobile that sent it the transaction containing whatever information had been given to it by the order entry system. This short message is received by the handset and passed to the SIM in an ENVELOPE (SMS-PP DOWNLOAD) APDU. The operating system hands the SMS to each of the applications on the card that indicated they might be receiving SMS messages. In due time, it is handed to Rapid Reorder, which recognizes it as a message from its off-card application and uses a DISPLAY TEXT proactive command to pop up a window that contains whatever information that had been passed along from the order entry system. It also informs the operating system that it handled the message.

Very abbreviated, here's what the on-card Rapid Reorder application looks like:

To say the least, this is not top-down, fastback, fully recursive compiler programming. The challenge in SIM Toolkit programming isn't writing wads of code, but rather working efficiently and elegantly within a rich but very complex and highly constrained environment. In other words, the challenge is to get the environment to do the work, not your code.

To build our example Rapid Reorder SIM Toolkit application, we used the Microsoft Smart Card for Windows Visual Studio development environment coupled with Rowley's SmartWorks C® compiler. This lets us program in C and run on the Microsoft Smart Card for Windows SIM card.

Whatever SIM Application Toolkit development environment you use, start by configuring a main menu on the SIM card. In the case at hand, we add a “Rapid Reorder” entry to the main menu and connect it to the compiled code we download onto the card. When this menu entry is selected on the handset, an ENVELOPE (MENU SELECTION) APDU is sent to the card. The SIM operating system notes which menu item has been selected, starts the corresponding application, and passes the entire ENVELOPE APDU to it.

Here's the entire ENVELOPE APDU that the Rapid Reorder application gets from the operating system (see Table 8.11):

The data field of the ENVELOPE APDU is a compound TLV. The tag of this TLV, D3, is the Toolkit tag for the Menu Selection. The value field of the Menu Selection TLV consists of two simple TLVs: Device Identifier (tag 82) and Item Identifier (tag 90). The Device Identifier TLV says that the command is going from the ME (83) to the SIM (81). The Item Identifier TLV says that Item #1 was selected.

Because there are two events that can cause our Rapid Reorder application to be placed into execution, the first thing that the application does is check to see which of the two events has occurred this time. If it is the Menu Selection event, then it sends a SELECT ITEM proactive command menu back to the handset to get the category of the product to be reordered.

Under the covers, the SIM operating system returns the status code 0x9134 to the handset in response to the ENVELOPE APDU. This says, “The ENVELOPE command was executed successfully and I have 0x34 bytes of proactive command for you.” The handset sends a FETCH APDU to the card to retrieve the 0x34 bytes of the proactive command. The SIM operating system responds with

D0 32                             // Proactive Command of 0x32 bytes
     81 03 02 24 01               // Command Details
     82 02 81 82                  // Device Identifier
     05 07 43 61 74 65 67 6F 72   // Alpha Identifier "Category"
     8F 06 01 44 61 69 72 79      // Item #1 "Dairy"
     8F 06 02 44 72 69 6E 6B      // Item #2 "Drink"
     8F 06 03 4D 65 61 74 73      // Item #3 "Meats"
     8F 06 04 43 68 69 70 73      // Item #4 "Chips"

The handset collects a choice from the user and sends a TERMINAL RESPONSE APDU back to the SIM:

This particular TERMINAL RESPONSE says that Item #1 was selected. The SIM operating system feeds the final 01 back to the Rapid Reorder application in the variable passed to the GsmEndSelectItem call that sent the menu to the handset.

This fundamental Card Application Toolkit protocol continues through the selection of a product from the category, an answer to the “Usual Amount?” question and terminates in the sending of an SMS message to the distributor that contains the order.

In actual fact, the display of the status message back from the distributor could have been left to the handset because it is nothing but a normal SMS message, but we've included its handling in the application to demonstrate how you might catch and process normal incoming SMS messages in a SAT application as follows.

/*
** Rapid Reorder SIM Toolkit Application
*/
#include <scw.h>
#include <string.h>
#include <gsm.h>

typedef const unsigned char *STR;

#define CLA_GSM       0xA0
#define INS_ENVELOPE  0xC2

#define SW_BADCLA  0x6402
#define SW_BADINS  0x6404
#define SW_BADTAG  0x6406

#define TAG_SMS_PP_DOWNLOAD  0xD1
#define TAG_MENU_SELECTION   0xD3

#define CATEGORY_DAIRY   0x01
#define CATEGORY_DRINK  0x02
#define CATEGORY_MEATS  0x03
#define CATEGORY_CHIPS  0x04

char *sms_title = "Rapid Reorder";
char *distributor_number="16179256888";

char *product[4][4] = {
{{"020 Skim Milk/Pt"},
{"020 Whole Milk/Pt"},
{"010 Skim Milk/Qt"},
{"010 Whole Milk/Qt"}},
{{"050 Coke/6Pack"},
{"030 Coke/2Lt"},
{"050 Pepsi/6Pack"},
{"030 Pepsi/2Lt"}},
{{"035 Hot Dogs"},
{"020 Bologna"},
{"040 Salami"},
{"010 Liverwurst"}},
{{"100 Potato Chips"},
{"050 Fritos"},
{"025 Pringles"},
{"040 Pretzels"}}
};

void main(void)
{
  BYTE dlTag, dlLen, category, pick, answer[4], anslen;
  BYTE data[36];
  GsmDCSValue dcsValue;

  /*
  ** Make sure it's an ENVELOPE command
  */
  if (ScwGetOSParam(CURRENT_CLA) != CLA_GSM)
    ScwExitSW(SW_BADCLA);

  if (ScwGetOSParam(CURRENT_INS) != INS_ENVELOPE)
    ScwExitSW(SW_BADINS);

  /*
  ** Get the download tag and total length of the download
  */
  dlTag = ScwGetCommByte();
  dlLen = ScwGetCommByte();

  /* Branch on the download tag */
  switch (dlTag)
    {
      /*
      ** MENU_SELECTION
**
** The Rapid Reorder Application has been selected to place an order
      **    - get a selection from the list of product categories
      **    - get a subselection from the products in that category
**    - if not usual amount, get the amount desired
      **    - send an SMS message to the distributor to place the order
      */
      case TAG_MENU_SELECTION:
          GsmSelectItem(7, (STR)"Category", PRESENT_AS_DATA_VALUES_NO_HELP);
          GsmAddItem(5, (STR)"Dairy", CATEGORY_DAIRY);
          GsmAddItem(5, (STR)"Drink", CATEGORY_DRINK);
          GsmAddItem(5, (STR)"Meats", CATEGORY_MEATS);
          GsmAddItem(5, (STR)"Chips", CATEGORY_CHIPS);
          GsmEndSelectItem(&category);

          switch(category) {
             case CATEGORY_DAIRY:
           GsmSelectItem(14, (STR)"Dairy Products",
                                  PRESENT_AS_DATA_VALUES_NO_HELP);
           GsmAddItem(5, (STR)"Skim Milk/Pt", 1);
           GsmAddItem(5, (STR)"Whole Milk/Pt", 2);
           GsmAddItem(5, (STR)"Skim Milk/Qt", 3);
           GsmAddItem(5, (STR)"Whole Milk/Qt", 4);
           GsmEndSelectItem(&pick);
                    break;

             case CATEGORY_DRINK:
           GsmSelectItem(12, (STR)"Cold Drinks",
                                   PRESENT_AS_DATA_VALUES_NO_HELP);
           GsmAddItem(5, (STR)"Coke/6Pack", 1);
           GsmAddItem(5, (STR)"Coke/2Lt", 2);
           GsmAddItem(5, (STR)"Pepsi/6Pack", 3);
           GsmAddItem(5, (STR)"Pepsi/2Lt", 4);
           GsmEndSelectItem(&pick);
                    break;

             case CATEGORY_MEATS:
           GsmSelectItem(7, (STR)"Cold Cuts",
                                  PRESENT_AS_DATA_VALUES_NO_HELP);
           GsmAddItem(8, (STR)"Hot Dogs", 1);
           GsmAddItem(7, (STR)"Bologna", 2);
           GsmAddItem(6, (STR)"Salami", 3);
           GsmAddItem(11, (STR)"Liverwurst", 4);
           GsmEndSelectItem(&pick);
                   break;

             case CATEGORY_CHIPS:
           GsmSelectItem(7, (STR)"Snack Food",
                                  PRESENT_AS_DATA_VALUES_NO_HELP);
           GsmAddItem(12, (STR)"Potato Chips", 1);
           GsmAddItem(6, (STR)"Fritos", 2);
           GsmAddItem(8, (STR)"Pringles", 3);
           GsmAddItem(8, (STR)"Pretzels", 4);
           GsmEndSelectItem(&pick);
                    break;
  }

  /* See if the usual amount is to be ordered */
          GsmGetInKey(DCS_SMS_UNPACKED, 14, (STR)"Usual Amount?",
                          YES_NO_OPTION_NO_HELP, &dcsValue, &answer[0]);
  /* If not, get the amount to be ordered */
      if(!answer) {
            GsmGetInput(DCS_SMS_UNPACKED, 9, (STR)"How Many?",
                  UNPACKED_DIGITS_ONLY_NO_HELP,
                  DCS_SMS_UNPACKED, 4, (STR)"10",
                  3, 3, &dcsValue, answer, &anslen);
     memcpy(product[category][pick], answer, 3);
  }
  /* Send the order off to the distributor */
      GsmSendSMS(13, (STR)sms_title, TON_INTERNATIONAL_AND_NPI_TELEPHONE,
                 sizeof(distributor_number), (STR)distributor_number,
                 14, (STR)(&product[category][pick][0]), PACKING_NOT_REQUIRED);
          break;

/*
** SMS_PP_DOWNLOAD
**
** If it's an order status message from the distributor, display it
**
*/
    case TAG_SMS_PP_DOWNLOAD:
  ScwGetCommBytes(data, 2);
  ScwGetCommBytes(data, data[1]); // Fan the device TLV
  ScwGetCommBytes(data, 2);
  ScwGetCommBytes(data, data[1]); // Fan the address of the SMSC
  ScwGetCommBytes(data, 2);
  ScwGetCommBytes(data, data[1]); // Get the Originating Address
  if(memcmp(data, distributor_number, data[1]) != 0)
  break;
  ScwGetCommBytes(data, 10);
  anslen = data[9];
  ScwGetCommBytes(data, anslen); // Get the message from the distributor
      GsmDisplayText(DCS_SMS_UNPACKED, anslen, (STR)data,

HIGH_PRIORITY_USER_CLEAR, 0);
      break;

    default:
      ScwExitSW(SW_BADTAG);
    }

  /* Add standard success SW. */
  ScwExitSW(GSM_S_COMMAND_SUCCESSFUL);
}