You are on page 1of 70

Department of Microelectronics and Information Technology

How to use GPRS as bearer for applications residing on the SIM

Claes Rosenberg

Examiner: Mats Brorsson Department advisor: Sven Karlsson

Industry advisor: Jrgen Hult

Abstract
This Master Thesis report investigates the usage of General Packet Radio Service, GPRS, as bearer for applications residing on the Subscriber Identity Module, SIM. The SIM is a so-called SmartCard with embedded processor and memory, which are used for identifying the subscriber and store dynamic and static information among other things. The work has been conducted at Sonera SmartTrust AB, who provides operators with software products that offers security and service management solutions as well as applications directed to the operators subscribers. The bearer for these services has so far been the Short Message Service, SMS. The problems involved when using GPRS are mainly how to get traffic terminating at the phone to be forwarded to the SIM and how to push data to the phone from an application outside the GPRS network. One of three solutions investigated are considered preferable within this context. It exploits the capacity of GPRS and overcomes the two stated problems in the best possible way. Furthermore it is a perfect choice for SmartTrust since it moves the transmission control towards their products, it utilises the full capacity of their products, it inherits the security mechanisms from the SMS and it makes it possible to transmit larger data amounts. Suggestions on how this solution can be incorporated into SmartTrusts existing products are given.

ii

Index
ABSTRACT.............................................................................................................II INDEX ................................................................................................................... III 1 2 3 INTRODUCTION ............................................................................................1 BACKGROUND...............................................................................................4 ARCHITECTURE OF THE GSM NETWORK.............................................6
3.1 3.2 3.3 3.4 MOBILE STATION ..................................................................................................6 BASE STATION SYSTEM ........................................................................................7 NETWORK AND SWITCHING SUBSYSTEM ...............................................................7 GSM RADIO INTERFACE, FREQUENCIES AND CAPACITIES .......................................8

ARCHITECTURE OF THE GPRS NETWORK .........................................10


4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 MOBILE STATION ................................................................................................10 BASE STATION SYSTEM ......................................................................................13 SERVING GRPS SUPPORT NODE ..........................................................................13 GATEWAY GPRS SUPPORT NODE .......................................................................14 HOME AND VISITING LOCATION REGISTERS ........................................................15 FUNCTIONS REQUIRED FOR GPRS .......................................................................15 GPRS INTERFACES..............................................................................................17 TRANSMISSION PLANE.........................................................................................19 GPRS PROCEDURES ............................................................................................21 GPRS RADIO INTERFACE, FREQUENCIES AND CAPACITIES ...................................22 QUALITY OF SERVICE..........................................................................................22 CHARGING ..........................................................................................................24

SHORT MESSAGES AND SIM APPLICATIONS ......................................27


5.1 5.2 5.3 SHORT MESSAGING SERVICE, SMS .....................................................................27 SIM APPLICATION TOOLKIT................................................................................28 SECURITY MECHANISMS FOR THE SIM APPLICATION TOOLKIT .............................28

SMARTTRUST DELIVERY PLATFORM 5 ...............................................31


6.1 6.2 6.3 DP5 MODULES ....................................................................................................31 THE INVERTED TRANSPORT SERVER ...................................................................37 FUTURE WORK ON SMARTTRUST DP5.................................................................37

SOLUTIONS ..................................................................................................38
7.1 7.2 7.3 SMS OVER GPRS................................................................................................39 NEXT GENERATIONS OF MESSAGING SERVICES ...................................................40 THE GPRS DATA CHANNEL ................................................................................43

8 9 10 11

RESULTS .......................................................................................................54 FUTURE WORK ...........................................................................................55 CONCLUSION ...........................................................................................56 REFERENCES ...........................................................................................58 ABBREVIATIONS..................................................................61 EXAMPLE OF TERMINAL PROFILE ................................64 SAT COMMANDS..................................................................65

APPENDIX A APPENDIX B APPENDIX C

iii

How to use GRPS as bearer for applications residing on the SIM

1 Introduction
The Global System for Mobile communication, GSM, market is still growing worldwide and will most probably continue doing so for years to come, according to predictions made by many organisations, such as, GSM World [28]. New networks are being launched practically on a weekly basis and new countries launch networks on a monthly basis, according to GSM World [27]. One of the services offered by most of the GSM operators is the Short Message Service, SMS. At first the expectations were fairly low on the revenue potential of SMS, but the reality has proven it to be one of the most revenue generating parts of the network. In August 2000, six billion SMS messages were sent in Europe. The usage of the service is predicted to continue growing until 2004 at least [21]. In the light of SMS success and as part of the operators wish to increase both the revenue from and the value of their networks, many operators, as well as, third party companies have offered all kinds of services and applications that uses SMS as the bearer. The services can be everything from simple person-to-person text messaging, to more advanced business applications with high demands on security. The reason that SMS is so well suited for security applications is the straightforward incorporation of the Subscriber Identity Module, SIM, cards inherent security functions and parameters. The key issues for the operators are that these services create market advantages towards competitors and increases the revenue through increased usage of the SMS. Albeit the success, SMS is a very ineffective way of transferring data, which has been compared to a horse and a carriage. As the telecommunications networks develop and new techniques are introduced, new bearers surface, which should gradually replace SMS as bearer for the services mentioned above. This thesis gives some suggestions on this area. Like most of the technology in our society, the telecommunication industry is constantly developing. Within this industry the term Generation are used for categorising the type and the category of the network. One of the latest generations of mobile networks that are being rolled out on the global telecommunication market is General Packet Radio Service, GPRS. This technology is often referred to as generation 2.5, 2.5G, since it is a technology between the second and the third generation of mobile networks, that is, it is a packet switched network built on top of existing Global System for Mobile communication, GSM, technologies. The main idea behind the packet switched networks is to facilitate and streamline the networks for mobile Internet usage. If the companies and operators that are providing the value and revenue increasing services could offer transparent usage of either SMS or, for example, GPRS, there would be a number of advantages, such as: Keeping the ability to use the inherent security functionality of the SIM. A greater capacity. The potential to have services that are more traffic consuming. Increased availability compared to just using one of the technologies.

Claes Rosenberg

Master Thesis in Computer Science An opportunity to use the technology that has been invested in, as well as, introducing subscribers to new and future technology and services.

The main goal of this master thesis is to investigate the feasibility of using GPRS as carrier instead of or in parallel with SMS, for applications residing on the SIM. This is an interesting, natural and necessary next step for companies and operators involved. Special emphasise will be put on products from the company Sonera SmartTrust AB, which are using SMS as carrier for their services. Furthermore, as a sub goal, suggestions on how to implement a solution, based on existing products from SmartTrust, are made. The master thesis project has been conducted as a part of SmartTrusts development and planning work for future systems and adaptation of new techniques.

Background
In the light of recent development of the telecommunication market, where operators have spent fortunes on third generation licenses and the launching of the new networks are getting postponed over and over again, it is essential that the operators can generate an increased revenue with small investments, immediately. Furthermore, it is very interesting for the operators to introduce non-voice services to their subscribers and through this, getting them acquainted with the future type of services. SmartTrust is a wholly owned subsidiary of Sonera Corporation. They are providing a Wireless Application Delivery Platform, DP5, which allows mobile operators, as well as third party entities to create applications for their customers/clients to use and hence increasing the value of their net. The platform allows operators to manage both devices and services, charge for used services, deploy security, and more. Besides that, it allows the mobile operators customers, using either a Wireless Application Protocol, WAP, or a non-WAP phone, to access Internet based content applications, using an application located on the on the Subscriber Identity Module, SIM. The SIM is a so-called SmartCard with embedded processor and memory, which are used for identifying the subscriber and store dynamic and static information among other things. The communication between the SIM and the DP5 uses SMS as carrier today. It is highly interesting for SmartTrust to investigate the possibilities that GPRS can offer the communication to and from their platform. Since SMS has its limitations concerning transfer rates, packet size, and so forth, a new bearer that has the possibility to overcome some of these deficiencies is very attractive. Furthermore, their customers mainly consist of mobile operators and it is vital to be able to adapt to the investments that the operators have made. The work that has been done on the subject, within the company, has so far been limited to rudimentary investigative work, with very little of value for this thesis, however with two exceptions. It was in one of the internal reports that I first read about SIM Application Toolkit commands of letter class e, described under Section 7.3, and during the course of this work SmartTrust employees have made tests with SMS over GPRS, see Section 7.1. Both of these have had value for the results that have been reached.

Goals and problems


The goal of the thesis is to investigate if and in that case how, GPRS could be used as bearer for applications residing on the SIM. The bearer used today is the SMS. The 2

How to use GRPS as bearer for applications residing on the SIM ideal solution would be to have a transparent solution where the GPRS data channel were used, if it was available for the concerned phone, and SMS in other cases. This ideal scenario is not possible with the networks, phones and SIMs available today due to several obstacles. When using SMS it is fairly easy to address the message to the SIM. This is not as easy with data transported on the GPRS data channel. The shortage of IPv4 addresses has a vast effect in this case. This shortage forces the operators to dynamically allocate private addresses to the subscribers, that is, the addresses are not globally routable. When using private addresses a Network Address Translation gateway must be put between the GPRS network and the Packet Data Network, for example the Internet. The two facts just stated make it impossible to push data to a phone, that is, the subscriber must initiate all traffic. These are the major problems. They are there and this thesis gives some solutions on how to overcome them.

Outline of the report


Section 2 is a shorter technical background description. The next sections, Section 3 through 5, handle the underlying technique in detail. First a shorter description of GSM, followed by a more extensive one on GPRS. After that the SMS, the SIM Application Toolkit and its security mechanisms are presented. The sections are fairly extensive in some parts and it is up to reader to decide if she or he needs or wants to read them in full. Section 6 introduces the parts in the SmartTrust Delivery Platform, DP5. The next section, Section 7, is called Solutions and presents and analyses the three potential solutions to the problem at hand in this work. The solutions are valued from SmartTrusts point of view, that is, how well the solutions fit in and how they affect the products. Besides this, this section gives a presentation of the additions that should be made to the existing products to get a simulated test environment, based on the one existing at SmartTrust. Section 8 summarises the results that have been reached in this work. In Section 9 there are some suggestions on what future work should focus on. The last section, Section 10, is the concluding section of this thesis, where comments to the three solutions are provided, suggestions on how the solutions fit into SmartTrusts future plans and some personal reflections on the thesis.

Claes Rosenberg

Master Thesis in Computer Science

2 Background
This section contains a shorter description on some of the underlying technique. The following three sections give a more detailed description of, firstly the GSM network, secondly the GPRS network and finally Short Messaging Service, SMS, the SIM Application Toolkit, SAT, and the security protocol. Since these sections contain fairly detailed descriptions of the technologies and specifications involved in this thesis work, they should be viewed as reference parts, where far from all details are necessary for the work, especially if one has previous experience of, for example GPRS and/or SMS. Therefore, it is up to the reader to choose which parts of these sections, if any, she or he wants to read. Global System for Mobile communication, GSM, is a circuit switched network, which is not well suited for data transfer from neither the operators nor the users point of view. The establishment of a connection is rather complicated and time consuming, besides that the traffic is fairly expensive and at low speed. The nature of circuit switching also implies bad utilisation of an operators radio resources. Since much of the data traffic needs high transfer rates and is bursty, this leads to inefficiencies and a halt in the development of mobile data services. One of the solutions to this is General Package Radio Service, GPRS. Further information about GSM is found under Section 3. GPRS is offering end-to-end package switched services based on the GSM infrastructure. This bearer simplifies easy access to packet data networks, offers higher data rates, makes billing based on volume possible and makes the usage of the radio interface more effective. GPRS is based on the GSM network with the introduction of two new nodes to handle the traffic and the interfaces to other packet based networks. Due to shortage of IPv4 addresses the GPRS networks use dynamically allocate private addresses for the subscribers upon request. This fact prevents traffic from being pushed to a phone, since the address is not globally routable. A more extensive presentation on GPRS is found under Section 4. Short Messaging Service, SMS, is a service available in most GSM networks, which makes it possible to transfer smaller data packages between nodes in, as well as, outside the GSM network. A Short Message, SM, can consist of up to 140 bytes of data. SMs are sent between Short Message Entities, SMEs, which can be located in a phone, an external network or elsewhere. The SIM Application Toolkit, SAT, enhances the interaction through the SIM-ME interface. It provides mechanisms that allow applications that reside on the SIM, to interact and operate with any ME that supports the specific mechanism(s). A special type of SAT commands, called Proactive commands, makes the SIM able to instruct the ME to perform certain actions, for example, send an SM or sound a tone. Furthermore, the SAT gives the operators the ability to update files on their subscribers SIMs remotely, which is called Over The Air, OTA. These updates have so far used SMS as bearer. To secure the transfer of data to and from the SIM/MS, a protocol, called 03.48 after the specification number, is usually used. This makes, among other things, authentication, signing and confidentiality possible, using keys stored on the SIM. Further information on SMS, SAT and security is available under section 5 below.

How to use GRPS as bearer for applications residing on the SIM After this condensed introduction the reader is able to jump to Section 6. Should the need for more extensive knowledge arise on for example GPRS, the reader can easily return to the concerned section and obtain a deeper understanding.

Claes Rosenberg

Master Thesis in Computer Science

3 Architecture of the GSM network


The architecture consists of several more or less separated parts, referred to as functional entities by the European Telecommunications Standards Institute, ETSI, which are described below. Here the nodes have been grouped, according to [2], into Mobile Station, MS, Base Station System, BSS, and Network and Switching Subsystem, NSS, as showed in the Figure 1 that follows.
BSS
BTS MSC A BSC C BTS F D C E GMSC

VLR

PSTN

NSS BSS
BTS
Um

AuC A

EIR

HLR

A-bis

BSC
A-bis

BTS

ME

SIM

MS

Figure 1 GSM network

ETSI has described the general objectives that should be met by a GSM Public Mobile Land Network, PLMN and defined telecommunication services as a group of communication capabilities that the operator of the network places at the disposal of its users [6]. These services are divided into two main groups: Bearer services, give the user ability to transmit appropriate signals between certain access points. Tele services provide the user with functions necessary for communication with other users.

To make these services possible, a series of functions are needed and associated with these, the functional entities.

3.1 Mobile Station


The physical equipment or Mobile Equipment, ME, as it is called, together with the Subscriber Identity Module, SIM, makes the Mobile Station, MS. If a PC or PDA is connected to the ME, that equipment is called Terminal Equipment, TE and the SIM and ME are called Mobile Terminal, MT. For an MS to work there are some things that have to be present. First, the ME needs a valid International Mobile station Equipment Identifier, IMEI, which is a unique identifier of the ME. Second there has to be a SIM connected to the ME with a valid International Mobile Subscriber Identity, IMSI, a unique identifier of the subscriber.

How to use GRPS as bearer for applications residing on the SIM The Mobile Station ISDN number, MSISDN, is used for reaching a subscriber, that is, it is the telephone number. It points to a subscribers record in a Home Location Register, HLR, which gives the necessary information for locating the serving Mobile Switching Centre, MSC.

3.2 Base Station System


The BSS constitute the physical equipment needed to cover a certain geographical area called cell and make communication with the MS possible. It consists of two separate parts, the Base Transceiver Station, BTS, and the Base Station Controller, BSC. The BTS contains equipment for the radio interface to be able to communicate with the MS. The BSC takes care of the switching functions in the BSS, allocates and releases radio channels and manages handoffs. The BSC is in turn connected to an MSC, see 3.3 below. Several BTSs can be connected to a single BSC.

3.3 Network and Switching Subsystem


The NSS supports the switching functions, subscriber profiles and mobility management. Mobile Switching Centre This entity takes care of all the switching associated with a specific geographical area, including procedures for handling and updating the location registers and carrying out the handovers. The MSC is assigned a so-called administrative region, which is part of, or the whole GSM network. Each administrative region consists of one or more location areas, LAs, and each of these is built up by cell groups, where each group is controlled by a BSC. The Gateway Mobile Switching Centre, GMSC, interworks with other networks, such as Public Switched Telephone Networks, PSTNs, and Packet Data Networks, PDNs, which needs special functions not present in the usual MSC, so called interworking functions, IWF. The type of IWF used for the interconnection is dependent on the type of network and the type of service. Location Registers The Home Location Register, HLR, is a database that contains both permanent data, such as profiles, and dynamic data, such as current location, for all the operators registered users. The number of HLRs needed is dependent on the structure of the PLMN. If the operator is to make any administrative work on the subscriber data, this takes place in the HLR. There are three types of data stored in the register: MS information. For example the IMSI and the MSISDN for an MS. Location information. Information, such as, the addresses of the Visiting Location Register, VLR, where the MS is registered and of the serving MSC. Service information. For example subscribed and prohibited services.

The VLR is responsible for user information about subscribers located in the area of the VLRs responsibility. When an MS enters a new MSC region, the VLR in question is notified and during a registration phase, the MS is given a Mobile Subscriber Roaming Number, MSRN, which is used to route incoming traffic. The information Claes Rosenberg 7

Master Thesis in Computer Science stored in the VLR consists of permanent information transferred from the HLR for making access more efficient, as well as local information as temporary identification. The information gathered from the HLR is: MS information. Including IMSI, MSISDN and Temporary Mobile Subscriber Identity, TMSI. TMSI is a temporary identifier used by the VLR to identify the MS to prevent sending the IMSI over the radio interface. Location information. For example the address of the serving MSC and the Location Area Identity, LAI. Service information, which is chosen parts of the corresponding register in the HLR.

Authentication Centre and Equipment Identity Register The Authentication Centre, AuC, is used for security management and stores, among other things, keys for encryption and authentication. This node can be collocated with the HLR. The Equipment Identity Register, EIR, is optional and maintains a list of legitimate and counterfeit equipment and can together with the HLR block illegal calls. In other words, this register is rather for equipment than for subscribers. The EIR can be combined with an AuC or be a stand-alone entity. SS7 Signalling System number 7, SS7, is a communication protocol that, among other things, provides signalling and control capabilities to various entities in the network. For example the communication between MSCs, VLRs and HLRs, as well as, the communication between mobile networks and PSTNs, use this protocol. Furthermore, SS7 is the carrier for SMS.

3.4 GSM radio interface, frequencies and capacities


The GSM radio link uses the two multiplexing technologies FDMA and TDMA. The frequency bands normally used in GSM are 900, 1800 and 1900 MHz. The bands are divided for up- and downlink signals as follows: The 900 band is divided into (890-915 and 935-960) o 880-915 MHz for uplink o 925-960 MHz for downlink. The 1800 band is divided into o 1710-1785 MHz for uplink. o 1805-1880 MHz for downlink. The 1900 band is divided into o 1850-1910 MHz for uplink. o 1930-1990 MHz for downlink. The reason that the uplink signals uses the lower part of the frequency band is that it is more power consuming to transmit signals at a higher frequencies. Hence, for saving MS power uplink signals in mobile systems uses the lower part of a frequency band. 8

How to use GRPS as bearer for applications residing on the SIM To save MS power further both discontinuous transmission and reception are usually used. This means that transmission and reception only takes place when there is voice present. The bands are divided into channels that have 200 KHz spacing and use the TDMA structure. A TDMA frame in a channel has a length of 4.615 milliseconds and is divided into eight, so called bursts or Time Slots, TS, with the length 0.577 milliseconds. Up- and downlink are separated by three time slots, this for prevention of simultaneous transmitting and receiving. This separation can be disturbed especially when there is a great distance between MS and BTS. This problem is solved by the timing advance, which is calculated by the BSS and transmitted to the MS twice per second. Using the timing advance, transmitting and receiving gets separated by three time slots minus the timing advance, from the MS point of view. As shown below a normal burst consists of 148 bits, where 114 of these are actual data. This should mean a traffic capacity per timeslot of:
114 24.7 kbits per second. 8 0.577 10 3

This is however not the case. Due to the fact that GSM uses error correction and different types of coding schemes, the maximum data transfer capacity is 9.6 or 14.4 kbps, depending on which coding scheme that is used, see [2].

Claes Rosenberg

Master Thesis in Computer Science

4 Architecture of the GPRS network


The GPRS design is built on the GSM infrastructure with some changes and additions. Two new types of network nodes, so called support nodes, are added, the Serving GPRS Support Node, SGSN and the Gateway GPRS Support Node, GGSN. Figure 2 shows a GPRS network, with additions made to the GSM network. Compare with Figure 1.
BSS
BTS MSC A BSC C BTS F D C E GMSC

VLR

PSTN

NSS BSS
BTS
Um

AuC A

EIR

HLR

A-bis

BSC
A-bis

BTS Gb ME

Gs

Gf

Gr

Gc

SGSN
SIM

Gn

GGSN

Gi

PDN

MS

Figure 2 GPRS network

Together with the two new nodes there are naturally some new interfaces added and optional additions could be made in existing nodes. Furthermore a new area concept is introduced, Routeing Area, RA, which is a subset of one, and only one, Location Area and consists of some or all of the LAs cells. The RA is the paging area for packet services. However, all changes should be conservative in the sense that they should not affect existing GSM services. According to ETSI specification 3GPP TS 03.60, [11]: Non-GPRS MSs in GSM PLMNs that support GPRS shall, without changes, be able to continue operation. GSM PLMNs that do not support GPRS shall, without changes, be able to continue interworking with GSM PLMNs that do support GPRS. Below follows a description of the two new nodes and of changes and additions made to current GSM nodes in order to make GPRS services possible.

4.1 Mobile Station


A GPRS MS consists of a Mobile Terminal, MT, and a Terminal Equipment, TE, and it is pretty similar to the earlier GSM MS, [15]. However there are some differences. In the GPRS MS there is software, necessary for supporting GPRS services, for example Automatic Request for retransmission, ARQ, at the data link layer, for retransmission of error frames. The SIM used in a GPRS MS can be a regular GSM SIM or a new SIM that is GRPS aware, [5]. The GPRS aware SIM is able to store two 10

How to use GRPS as bearer for applications residing on the SIM elementary files, used for security and authentication among other things. When an ordinary SIM is used, these files are stored in the ME. There are three different modes of operation defined for the GPRS MS: Class A mode of operation, means that the MS is capable of simultaneous GPRS and GSM services. Class B mode of operation. The MS can only operate in either GSM or GPRS at one time, but monitors control channels from both simultaneously. Class C mode of operation. The MS is a GPRS exclusive MS.

For mobility management purposes, the MS maintains Mobility Management, MM, and Packet Data Protocol, PDP, contexts. MM and PDP contexts These contexts are stored on the SIM or directly in the ME, depending on the nature of the information and if the SIM is GPRS aware or not. The MM context fields below are some of the stored: IMSI and P-TMSI, which is the packet switched correspondent to TMSI. Routeing area and cell identity. Ciphering parameters, such as current key and used algorithm. MM state (one of IDLE, STANDBY or READY). PDP type (IP, X.25 or PPP), address and state (one of ACTIVE or INACTIVE). Dynamic address allowed, which specifies if the MS is allowed to use dynamic address. Access Point Name requested. Quality of Service, QoS, parameters.

Among the PDP context fields stored are:

An important issue for manufacturers of mobile equipment is the power consumption. The somewhat contradictive challenge for the manufacturers is to develop smaller phones with longer battery life. To reach this, power savings must be made in all possible ways. This is an even bigger challenge with GPRS MEs, since they are more power consuming than the GSM variant, due to among other things, the constant connection capability. MM and PDP states To be able to save power three mobility management, MM, states are being used, READY, IDLE and STANDBY. Each of theses states describes the degree of functionality an MS is in and the information allocated. This information, stored in the MS and SGSN, is referred to as the MM context. In the IDLE state the MS is not GPRS Attached, which means that neither the MS nor the SGSN keeps information about location and routeing for the subscriber. This makes it impossible for the MS to send or receive data, as well as, it makes it impossible to page the subscriber, that is, the MS is seen as not reachable. Claes Rosenberg 11

Master Thesis in Computer Science In the STANDBY state the MS is GPRS attached, that is, the MS and the SGSN have stored a MM context associated to the subscribers IMSI. The SGSN is aware of in which RA the subscriber is located and updates are sent to it when the subscriber moves into a new RA, but not when changing cells within a RA. In this state, the MS can initiate a PDP context, which is necessary for allowing data transmission. If an SGSN wants to send data to an MS in STANDBY state, it should start by paging it, the MS changes its MM state to READY upon receiving the page and sends a response. Upon reception of the response, the MM state for the MS is changed in the SGSN. An MS in READY state is not just GPRS attached it also has one or more PDP contexts activated, which allows data transmission to and from the MS. The MM context for the MS in the SGSN is similar to the one in the STANDBY state, with the addition of cell identity, that is, the SGSN knows exactly in which cell the subscriber is located not just in which RA. The READY state is governed by a timer, when the timer expires the MM context is moved from READY to STANDBY state. Below follows Figure 3 and 4, which illustrates the different MM states and their functions and transitions, both for the MS and the SGSN.
IDLE

GPRS Attach

GPRS Detach

READY

Timer expiration or forced STANDBY

PDU transmission

Figure 3 MM states and transitions in the MS

IDLE GPRS Detach or Cancel location

GPRS Attach Implicit Detach or Cancel location

Timer expiration or Forced or Abnormal RLC condition

READY

PDU transmission

STANDBY

Figure 4 MM states and transitions in the SGSN

As there are MM states, there are PDP states. Every PDP context associated with a subscriber is in either ACTIVE or INACTIVE state. A PDP context in ACTIVE state is active in all nodes that keep the PDP context, that is, the MS, the SGSN and GGSN. 12

How to use GRPS as bearer for applications residing on the SIM For this to be allowed, the MS has to be in one of the MM states STANDBY or READY. In INACTIVE state, there is no routeing information in the PDP context associated with a subscribers PDP address. Data transmission cannot be conducted. Transition to ACTIVE state is done by the MS by initiating the PDP Context Activation or where possible by the GGSN via the Network Requested PDP Context Activation. However, for the network to be able to do the activation, static addresses must be used, which is not the case in the initial networks. Below follows Figure 5, which shows the two PDP states and the functions that switch state.
INACTIVE Deactivate PDP Context or MM state change to IDLE

Activate PDP Context

ACTIVE

Figure 5 PDP states

4.2 Base Station System


For the BSS to support GPRS the BTS and BSC needs some modifications, mainly on the software side. The exception is a new node has to be added, the Packet Control Unit, PCU. The BSC uses the PCU to forward packet-switched data to the SGSN, and circuit-switched calls as usual to the MSC. The PCU is either collocated with the BTS or a stand-alone node. The interface between the BTS and the MS is the Um, reused from GSM with a transmission rate upgrade and some modifications, and the interface to SGSN is called Gb. Further information about interfaces is found in Section 4.7.

4.3 Serving GRPS Support Node


The SGSN is the GPRS equivalent to the MSC and is located on the same hierarchical level as shown in Figure 2. The SGSN connects to the BSS using an interface called Gb. It keeps track of MSs location, handles security and access control, as well as, collecting statistics for charging. To be able to provide these services the SGSN creates a mobility management, MM, context at GPRS attach, described under Section 4.9, which contains useful information about the MS concerning security and mobility. To route data between the MS and the GGSN, a PDP context needs to be activated, which is established by the SGSN. The SGSN retains the two contexts as long as the MS is in either one of MM states STANDBY or READY. The context fields for one MS in an SGSN contains, among other things: IMSI, P-TMSI, IMEI and MSISDN. MM state (one of IDLE, STANDBY or READY). Routeing Area Identity, RAI. Cell identity, which is the current cell in ready state or last known cell in IDLE or STANDBY state. VLR number of the MSC/VLR currently serving the MS.

Claes Rosenberg

13

Master Thesis in Computer Science New SGSN number, which is the IP address of the new SGSN, to which buffered packets should be forwarded. Parameters for authentication and ciphering. MS radio and network capabilities. Mobile Not Reachable for GPRS flag, MNRG, which indicates whether activity from the MS should be reported to the HLR. Non-GPRS Alert flag, NGAF, which indicates whether activity from the MS should be reported to the VLR. Paging Proceed Flag, PPF, which indicates whether paging for GPRS and nonGPRS services can be initiated. PDP context identifier, type, address and state. Access Point Name, APN, to external network, received from the HLR. IP address of GGSN currently in use. QoS parameters. Charging ID, which identifies the records generated by the SGSN and the GGSN.

An MM context is associated with zero or more of these PDP contexts:

4.4 Gateway GPRS Support Node


The GGSN takes care of the interworking between the PLMN and different PDNs. It contains routeing information of all attached GPRS users, within PDP contexts, which are used for tunnelling PDUs to the MSs current point of attachment, that is, SGSN. A GGSN may provide DNS services, as well as, DHCP functions. The interface between a SGSN and a GGSN is called Gn and is an IP-based GPRS backbone network and the interface towards a PDN is called Gi. Besides these two interfaces there is an optional interface to the HLR, called Gc, which makes it possible for the GGSN to query the HLR directly. The PDP context maintained for all attached users contains, among other things, the following information: IMSI and MSISDN. PDP type and address. Dynamic address, indicates if its a static or dynamic address. QoS profile negotiated. IP address of the SGSN serving this MS. Access point name of the external data network. Charging ID, which identifies charging records generated by SGSN and GGSN. MNRG flag, which indicates whether the MS is marked as not reachable for GPRS at the HLR.

14

How to use GRPS as bearer for applications residing on the SIM

4.5 Home and Visiting Location Registers


To be able to support GPRS services new fields are added to the existing ones in the HLR. This information is accessed by the SGSN and the GGSN via, respectively, the Gr and the Gc interfaces. The IMSI is the prime key for the stored data. Among the GSN related information that is stored are: IMSI and MSISDN. SGSN number, which is the SS7 number for SGSN currently serving the MS. SGSN address, the IP address to the SGSN. MS purged for GPRS flag, which indicates that the MM and PDP contexts are deleted from the SGSN. GGSN list, that is the GSN number and optional IP address pair related to the GGSN that shall be contacted when activity from the MS is detected. PDP context identifier, type and address. APN. QoS parameters.

For each IMSI zero or more of the following PDP context data:

In the MSC/VLR a new field is added, in which it is possible to store the SGSN number of an MS that is also IMSI attached. This makes it possible for the MSC/VLR to request location information from the SGSN via the Gs interface, as well as, coordinating circuit and packet switched traffic in those cases that there is need for that, for example, when using class B MSs.

4.6 Functions required for GPRS


The logical functions performed in GPRS are grouped into the following metafunctions. Network access Control functions GPRS network access support standard data transfer and may in addition support anonymous access without authentication and without ciphering since either IMSI or IMEI are used. The network access should work from both the fixed and the mobile side of the GPRS network. In GSM 03.60, [11], the access protocol is defined as a defined set of procedures that enables the user to employ the services of the network. The functions are: Registration. Associates the MS identity with the users PDP(s), address(es) within the PLMN and the users AP(s) to the external PDP network. This association is either dynamic or static. Authentication and authorisation. Identifies and authenticates the service requester and validates that the user is authorised to use the requested service. Admission control. Determines the radio and network resources required to provide requested QoS, check if these are available and in that case reserve them. Message screening. Filters out unsolicited messages and should, according to ETSI, be supported through packet filtering. In the first phase there is only 15

Claes Rosenberg

Master Thesis in Computer Science network controlled screening, but subscription- and user-controlled screening should follow this. Packet terminal adaptation. Adapts data packets to be suitable for GPRS transferring. Charging data collection. Collects data for charging of subscription and traffic.

Packet routeing and transfer functions In the GSM network there are switches such as MSCs and within GPRS, GSNs have been added, which acts as routers. Routeing is the process of determining and using, in accordance with a set of rules, the route for transmission of a message within and between the PLMN(s), GSM 03.60, [11]. The functions are as follows: Relay. Functions in the BSS used for forwarding traffic between the MS and the SGSN. Used in the SGSN for forwarding between a BSS and a GSN of some sort. Routeing. Determines to which GSN a packet should be forwarded and which service(s) that should be used to reach that node, based on the terminating address. Address translation and mapping. Used to translate from one type of address to another, for example from a PDN address to an address that is routable inside a PLMN. Encapsulating. Addition of address and control information to data units for transport within and between PLMN(s), usually trough tunnels. Tunnelling. A tunnel is a two-way point-to-point way of transferring encapsulated data units between the point of encapsulation and the point of decapsulation. Compression. Used for optimisation of the usage of the radio capacity. Ciphering. Gives confidentiality to traffic traversing the PLMN. Domain name server, DNS. Resolves logical GSN names to their IP addresses.

Mobility management functions Used for knowing an MS current location within a PLMN. Since an MS can be GPRS attached, IMSI attached or both, a location update can be concerned with the routeing area, location area or both. Independent of the type of area update, the procedure is initiated by the MS and may involve one or more SGSNs and/or MSCs/VLRs, GGSN and HLR, that is, all involved entities that needs an update when the MS has changed location. Logical link management functions Manages the communication channel between an MS and the PLMN across the radio interface. The functions are: 16 Logical link establishment. Performed when an MS attaches to the GPRS service. Logical link maintenance. Used for supervision of the state of the logical link and changes in the control link state.

How to use GRPS as bearer for applications residing on the SIM Logical link release. De-allocates resources from the logical link connection.

Radio resource management functions Allocates and maintains radio communication paths, which are shared between GSM voice and data services and GPRS services. Um management. Manages the set of physical channels in a cell and determines the amount allocated for GPRS, which may vary from cell to cell. Cell selection. Enables the MS to select the optimal cell for radio communication with the PLMN, which includes measurement of signal quality and avoidance of congestion in possible cells. Um-tranx. Provides the capability of packet transferring between MS and BSS using the radio interface, which includes procedures for medium access control, packet multiplexing, packet discrimination, error detection and flow control Path management. Maintains the packet data communication paths between BSS and SGSN, establishment and release could be dynamic or static.

4.7 GPRS interfaces


Below follows a shorter description of the most important interfaces between the nodes involved in a GPRS network, starting with the Um interface between the MS and the BTS and going through the network until the ending interface Gi interconnecting the GGSN with a PDN, as shown in Figure 2. Um interface The Um interface describes the radio interface between the MS and the BTS, [12]. The GSM TDMA structure is unchanged with 200 kHz carriers, time division with eight timeslots, TS, per TDMA frame. A new logical channel is introduced for control of signalling and traffic flow over the Um interface. The up- and downlink are allocated separately and several GPRS users can be multiplexed on the same physical resource. Packet Data Channel, PDCH, is the physical channel dedicated to packet data traffic, onto which the logical channels are mapped. PDCH is a timeslot on a radio frequency carrier and at any given time in a GPRS supporting cell, none, one or more physical channels may be allocated for GPRS traffic. The logical channels involved in packet traffic in GPRS can be divided into three separate groups as follows below. Common for them are that they all use the PDCH for transmission. The first group, Packet Traffic Channels, has only one member Packet Data Traffic Channel, PDTCH. This channel is momentarily dedicated to one MS and is allocated for data transfer. An MS may use several PDTCHs simultaneously for a single transfer. PDTCHs are unidirectional, that is, an allocated channel is either carrying MS terminating or originating traffic. The second group consists of the following Packet Common Control Channels, PCCCHs:

Claes Rosenberg

17

Master Thesis in Computer Science Packet Random Access Channel, PRACH, used for initiation of uplink transfer for data or signalling. This is the only PCCCH that is uplink, all of the below are downlink. Packet Paging Channel, PPCH, which pages MS for both circuit- and packet switched services. Packet Access Grant Channel, PAGCH, is used in the packet establishment phase for resource assignment. Packet Broadcast Control Channel, PBCCH, which broadcasts system information specific for packet data.

The third group, Packet Dedicated Control Channels, PDCCH, consists of the following channels: Packet Associated Control Channel, PACCH, transmits signalling information, such as power control, resource assignment and reassignment information. This channel shares resources with PDTCHs. An MS currently involved in packet transfer can be paged for circuit switched services on PACCH. The direction is both up- and down link, independent of how the PDTCH is allocated. Packet Timing Advance Control Channel in the Uplink direction, PTCCH/U, which is used by an MS to transmit a random access burst. With this information the BSS estimates timing advance. Packet Timing Advance Control Channel in the Downlink direction, PTCCH/D, is used by the BSS to transmit timing advance information updates to several MSs.

For more information about the involved protocols, see Section 4.8. Gb interface The BSS and the SGSN are connected via the Gb interface. Unlike the corresponding A interface in GSM, where a user takes a physical channel in possession during the complete duration of the call, the Gb interface allows many users to be multiplexed over the same physical resource. Resources are allocated to a user upon activity, that is, when data is sent or received, and reallocated after completed transmission. Both data and signalling are sent over the same physical resource. For more information about the involved protocols, see Section 4.8. Gn interface The Gn interface connects GSNs within the same GPRS network. The Gn utilises GPRS Tunnelling Protocol, GTP, which is transparent for all other entities in the network except the GSNs. GTP allows many to many communication between GSNs, that is, a single SGSN can communicate with several GGSNs and vice versa. For more information about the involved protocols, see Section 4.8. Gp interface The Gp interface is the connection between GSNs situated in different GPRS networks. This interface is very similar to the previous Gn interface with the

18

How to use GRPS as bearer for applications residing on the SIM difference of additional necessary security mechanisms involved in inter PLMN communication. Gs interface The Gs interface connects the SGSN and the databases in the MSC/VLR, and is optional. It does not involve user data transmission. The interface is used to coordinate location information of MSs that are both IMSI- and GPRS attached, and can be used for transmission of certain circuit switched services via the SGSN, such as paging. This interface is necessary to make a combined location and area update. Gi interface The Gi interface is the interconnection between a GGSN and a PDN or PSDN. Here the GGSN serves as an access point towards an external data network for the GPRS network. If the interconnected network is a X.25 or X.75, the MS is given a X.121 address. If it is an intranet or the Internet, the MS is given an IPv4 or an IPv6 address, and the GGSN can be viewed as a router and the GPRS network as just another IP network. It is expected that the operator use some kind of firewall on this interface to prevent unsolicited intrusion into the network. Other interfaces Besides the already mentioned interfaces there are the following interfaces: The Ga interface is a Charging Data Record, CDR, interface that connects a SGSN and/or GGSN with a Charging Gateway Functionality, CGF. The Gc interface that is optional and connects the GGSN and HLR, making it possible for the GGSN to make location information queries. The Gf interface connects SGSN and EIR and makes identity checking possible. The Gr interface is between SGSN and HLR. The Gd interface, not showed in Figure 2, makes it possible for the MSs to SMs via the SGSN, instead of the MSC. More on this in Section 7.1.

4.8 Transmission plane


The transmission plane consists of a layered protocol structure, as showed in Figure 6 below, which provides user information, as well as, associated information transfer control procedures, such as flow control, error detection, correction and recovery.

Claes Rosenberg

19

Master Thesis in Computer Science

Application IP/X.25 Relay SNDCP LLC Relay RLC MAC PLL GSM RF MS Um RLC MAC PLL Physical GSM RF BSS Gb SGSN Gn GGSN Gi Physical Physical Physical BSSGP NS BSSGP NS IP DLL IP DLL SNDCP LLC GTP TCP/UDP GTP IP/X.25

TCP/UDP

Figure 6 Transmission plane

Below follows a description of the more important of the protocols. SNDCP, SubNetwork Dependent Convergence Protocol, maps network level characteristics onto the characteristics of the underlying network. LLC, Logical Link Control, layer provides a reliable ciphered logical link. This layer should, according to ETSI standard, be independent of underlying radio interface protocols, which allows introduction of alternative GPRS radio solutions without major changes to the Network and Switching Subsystem. RLC and MAC, Radio Link Control and Medium Access Control, layers. RLC provides a reliable link that is radio solution dependent. MAC takes care of mapping of the LLC frames onto the underlying physical channels, and of controlling of the access signalling procedures for the radio channel. BSSGP, Base Station System GPRS Protocol, carries routeing and QoS related information between the two nodes BSS and SGSN. This protocol does not provide error correction. NS, Network Service, is used for transportation of BSSGP PDUs between BSS and SGSN via the Frame Relay connection between them. GTP, GPRS Tunnelling Protocol, tunnels both user data and signalling between GSNs in the GPRS backbone network. According to GSM 09.60, [16], all PDP PDUs should be encapsulated by this protocol. Relay functions take place in two places in the network topology. In the BSS, LLC PDUs get relayed between the Um and Gb interfaces and in the SGSN the relay is between the Gb and Gn interfaces. IP, Internet Protocol, is used as the GPRS backbone network protocol and should go through a replacement of the initial IPv4 by IPv6. It is used for routeing user data and control signalling. TCP and UDP. The Transmission Control Protocol is used for transport through the backbone when reliability is essential, since the protocol provides flow control and protection against lost and corruption of packets. The User Datagram Protocol carries GTP PDUs for protocols were the reliability is less important, since UDP only protects against corruption.

20

How to use GRPS as bearer for applications residing on the SIM

4.9 GPRS procedures


The procedures, shortly described below, involve some or all of the nodes present in a GPRS network, and are the most fundamental for providing GPRS services and mobility management. GPRS attach Before an MS is able to use the GPRS service it has to perform the GPRS attach procedure, which establishes a logical link between the MS and the SGSN. This is necessary for the SGSN; because it is during this the MM context is created. The GPRS attach is usually performed at MS start-up and an IMSI attach is usually performed at the same time, that is, the attachment for circuit switched services. The MS sends an attach request to the SGSN, which tries to receive the IMSI from the last SGSN serving the MS using the P-TMSI. If this fails the MS is asked to send the IMSI over the radio interface to the current SGSN. After necessary security measures have been taken, routeing and/or location updates are performed. Finally the SGSN returns an acceptance message to the MS, which may include a new P-TMSI. Figure 7 below shows the procedures involved in GPRS attach, as described above.
MS BSS New SGSN Old SGSN GGSN HLR VLR

Attach Request Identification request Identification Response

RA/LA Update Attach Accept

Figure 7 Procedures involved in GPRS attach

GPRS detach The detach procedure removes the MM contexts associated with an MS and can be initiated by the MS, SGSN or HLR. The detachment differs somewhat dependant on which node that initiates it. For example, if the MS is the initiating party, it can choose to request a GPRS detach, an ISMI detach or a combination of both. If there are any PDP contexts associated with the MS, these are deactivated and in case it is a GPRS detach, not concerning IMSI, the VLR is told to stop using the SGSN for paging and location update services. PDP context procedures The PDP context activation procedure makes data transmission to and from the MS and an external network possible. The PDP context activation is started when the MS sends a context request to the SGSN, including specification of the external data network and desired QoS. The SGSN performs some security measurements and creates a request to the GGSN. This request creates a logical link between the PDP contexts in the SGSN and the GGSN. The GGSN dynamically allocates an IP address for the context. A reply is sent to the SGSN, which activates the PDP context and informs the MS. Theoretically a PDP context can be initiated by the GGSN, but this Claes Rosenberg 21

Master Thesis in Computer Science craves the usage of static addresses, which is not the case in initial releases of GPRS networks. The MS, the SGSN or the GGSN can initiate PDP context deactivation. The communication differs depending on which node that is the initiator, but in all cases the PDP contexts are deleted in the three entities.

4.10 GPRS radio interface, frequencies and capacities


In accordance with the reusage of infrastructure, GPRS reuses the GSM radio interface. The main differences are that a GPRS user is able to use several timeslots, up to eight, which are all available time slots in a TDMA frame. Furthermore several users may share the same timeslots over a time period. However the time slots are shared between GPRS and GSM, and it is up to the operator to decide how many timeslots that are available for GPRS. The most likely scenario is that the operator uses some kind of dynamic solution where GPRS is allowed to use several timeslots as long as all GSM traffic get the resources asked for. Furthermore, the MEs have a limitation on how many slots that it is capable of using. This is typically two or four slots for the downlink and one or two for the uplink. For the purpose of achieving different degree of robustness, GPRS uses four different coding schemes. The coding of a bit stream makes it possible to correctly receive packets even if a few bits are lost or corrupted on the way. The four available coding schemes for GPRS are CS1, CS2, CS3 and CS4. The data rates shown in the Table 1 below are the physical transfer rates.
Table 1 GPRS coding schemes (from [2]) Coding Scheme User data rate Correction capability Worst-Link Budget Maximum cell range CS1 9.05 kbps Highest 135 dB 450 m CS2 13.4 kbps 133dB 390 m CS3 15.6 kbps 131 dB 350 m CS4 21.4 kbps None 128.5 dB 290 m

As shown in Table 1, the chosen coding scheme has great influence on the transfer rates. The thought is to use CS1 in areas with less signal quality and CS4 in areas with better quality. In theory, as well as, in a lot of opportunistic papers and commercials, the capacity of GPRS is stated as well over 100 kbps. In theory the maximum data transmission speed is 171.2 kbps using regular GPRS. This demands however that no error correction, that is, CS4 is used over all eight timeslots. This is not realistic since an operator hardly allocates all resources for GPRS and since that, not many phones with that kind of time slot capacity will ever surface on the market, see Mobile GPRS [25]. Since the operators just allocate timeslots for GPRS when GSM traffic allows it, there are no guarantees on the transfer rates; they can vary from second to second. A realistic estimation on transfer rates for a 4+1 ME, which means, an ME capable of four downstream and one upstream timeslots, are something between 5 and 40 kbps, [1].

4.11 Quality of Service


The Quality of Service, QoS, is an important part of the idea behind the GPRS network, as well as, future mobile networks. This makes it possible for the subscribers 22

How to use GRPS as bearer for applications residing on the SIM to choose transfer speeds, qualities and how much they are willing to pay for every individual transfer, [8], [11] and [3]. With each PDP context there is a Quality of Service, QoS, profile associated. The profile consists of the following data transfer parameters: Precedence class. There are three different precedence classes: High, normal and Low priority. Under abnormal conditions these classes are used for labelling the relative importance of the different QoS profiles, for example which packets that should be dropped first, in cases where that is necessary. Under normal conditions the network should try to keep up to all QoS profiles. Delay class. Since GPRS does not have store and forward, all delays occurring during transmission of data is due to transfer characteristics or in some cases limitations, in the network. These delays should be kept to a minimum within the classes. Each delay class has defined a mean transfer delay and 95-percentile delay for Service Data Units, SDUs, of the two sizes 128 and 1024 bytes. The delay is end-to-end trough the GPRS network, meaning it is calculated from the MS to the Gi interface, see Figure 2 GPRS network. Below follows Table 2 showing the delay classes and associated delays. According to GSM 03.60, [11], GPRS networks do not need to support all delay class, but the minimum is class 4, best effort.
Delay (maximum values) SDU size: 128 bytes SDU size: 1024 bytes Mean Mean 95 percentile 95 percentile Transfer Transfer Delay (sec) Delay (sec) Delay (sec) Delay (sec) < 0,5 < 1,5 <2 <7 <5 < 25 < 15 < 75 < 50 < 250 < 75 < 375 Unspecified

Table 2 GPRS Delay classes

Delay class

1. (Predictive) 2. (Predictive) 3. (Predictive) 4. Best Effort

Reliability class. The reliability class states the demands and characteristics of the applications sending traffic over the GPRS network. There are four different parameters that have a probability of occurring for each class: o Loss of SDU. o Duplication of SDU, which can occur when a package gets discarded after network holding time has timed out, that is, the maximum time a data package exists in the network. o Sequence reordering of SDU. o Delivery of corrupted SDU, which means a corrupted SDU is delivered to the user without detection of the corruption. Below follows Table 3 with the reliability classes and the associated probabilities for the different cases.

Claes Rosenberg

23

Master Thesis in Computer Science


Table 3 GPRS Reliability classes Reliability Class Lost SDU Probability Duplicate SDU Probability
-9

Out of Sequence SDU Probability 10


-9

Corrupt SDU Probability


-9

Example of Application Characteristics Error sensitive, no error correction capability, limited error tolerance capability. Error sensitive, limited error correction capability, good error tolerance. Not error sensitive, error correction capability and/or very good error tolerance capability

1.

10

-9

10

10

2.

10-4

10-5

10-5

10-6

3.

10-2

10-5

10-5

10-2

Peak throughput class. This class describes the maximum transfer rate, in bytes per second, which can be expected for a certain PDP context. There are nine classes spanning from 8 kbits per second for class one to 2 Mbits per second for class nine. There are no guarantees that the peak transfer rate of the chosen class is the actual transfer rate. This is governed by the capacity of the MS and available resources in the network. Mean throughput class. The mean throughput is a measure of the expected mean transfer rate, in bytes per hour, for the remaining duration of the PDP context. There are 18 transfer classes ranging from 100 bytes per hour to 50 million bytes per hour, plus an additional class, 31, which is a best effort class.

The QoS is negotiated during the PDP context activation procedure. The MS should be able to specify individual values for all the classes above or use default values for the subscription that are stored in the HLR. Due to the complexity of implementing QoS on an individual user level, this feature is most likely not available in the first releases of GPRS networks. The reasons for this are mainly due to limitations in the Packet Control Unit, PCU, which will need some considerable changes, [1].

4.12 Charging
In a GPRS network charging information is collected at the SGSN and the GGSN. Information is collected for each MS by all serving nodes that are serving it. It is up to the operator to decide how this information is used to generate the actual bill to the subscriber. The SGSN charging information is related to the usage of the radio network. The amount of data is counted at SNDCP level. Collection should, according to GSM 03.60, [11], at least include: Usage of radio interface. This includes the amount of mobile originating, MO, as well as mobile terminating, MT, traffic. This collection also keeps track of QoS and user protocols for transferred data.

24

How to use GRPS as bearer for applications residing on the SIM Usage of packet data protocol, PDP, addresses. The information tells how long an MS has used a certain PDP address. Usage of general GPRS resources. Describes how other GPRS services have been used and the MSs activity in the network, for example, mobility management. The MS location. Information about usage of home and visiting PLMNs.

The GGSN charging information is related to the usage of the external data network associated with that GGSN. The amount of data is collected at GTP level. Collection should, according to GSM 03.60, [11], at least include: Destination and source. Information about the destination and the source addresses. The level of accuracy is up to the operator. Usage of external data network. Information about the amount of data sent to and from the external data network. Usage of addresses. The information tells how long an MS has used a certain PDP address. The MS location. Information about usage of home and visiting PLMNs.

Both of the serving nodes collect information on the usage of the GPRS network resources. The common way of charging in Sweden today is solely based on amount of data sent. Telia is offering three different choices: Online high, low and mobile. The difference lies in the fixed monthly fee, the amount of data that is included in this fee and the fee for transmission of data exceeding the fixed amount, as showed in Table 4 below.
Table 4 Telia GPRS prices. Source Telia [31] Subscription type Online High Online Low Online Mobile Monthly charge (SEK/month) 300 100 0 Fixed transmission (MB/month) 25 5 0 Charge for exceeding transfer (SEK/kB) 0.018 0.023 0.125

Europolitan have chosen a different charging scheme, where there is no traffic included in the monthly charge. There are two different subscriptions to choose between, GPRS Surf and Data GPRS. The figures for these are showed in Table 5. Besides this difference from Telia, Europolitan charges their subscribers 2.50 SEK per hour for every hour more than the first 24 that the subscriber has been consecutively connected. In my opinion this put the phrase always-on-line, which is often associated with GPRS, in a somewhat strange perspective.
Table 5 Europolitan GPRS prices. Source Europolitan [32] Subscription type GPRS Surf Data GPRS Monthly charge (SEK/month) 368,75 25 Traffic fee (SEK/MB) 25 175

Claes Rosenberg

25

Master Thesis in Computer Science Comviq has only one GPRS subscription for the time being. Until the last of May 2002, the subscribers pay a monthly charge of 49 SEK and no extra per traffic fee. After the last of May, the monthly charge is kept and that include transfer of three MB. Traffic exceeding the initial three MB, costs 21 SEK per MB. Source: Comviq [26]. These prices and choices of subscriptions are the available ones in Sweden in the fall of 2001. I think that since the technique has just been launched and the fact that the current amount of subscribers are fairly low, there is a limitation in the competition seen so far between the concerned operators.

26

How to use GRPS as bearer for applications residing on the SIM

5 Short messages and SIM Applications


5.1 Short Messaging Service, SMS
The Short Messaging Service, SMS, makes it possible for a Mobile Station, MS, to send or receive a short message, SM, to or from a Short Message Entity, SME. An SME is an entity that can send or receive Short Messages, and is located in an MS, in a Service Centre, SC or in a fixed network. A single SM can consist of up to 140 bytes. However several SMs can be concatenated to a longer message, [9]. Below follows a figure of the involved nodes in the transmission of SMs.
Proprietary

SME

SC

SMS-GMSC SMS-IWMSC

MSC (SGSN)

MS

HLR

VLR

Figure 8 The nodes involved in SMS

An SM is sent via an SMS Service Centre, SMS-SC or SMS-C, which is responsible for storing and forwarding of the message. Furthermore, the SC has the responsibility for the message until a receipt of reception has arrived from the receiving MS or SME. When an SM is MS terminated the SC sends the message to an SMS Gateway Mobile Switching Centre, SMS-GMSC. The GMSC interrogates the HLR for necessary routeing information. Using this information the message is then sent to the appropriate MSC. The MSC then queries the VLR for the location area address of the MS and then forwards the SM to the MS. In many cases the SMS-C and the SMSGMSC are one and the same entity. After successful reception of the message at the SM a delivery confirmation report is transferred back to the sending SME, alternatively an error report if some trouble has risen along the transport line. In the case of an MS originating message, the transfer is just reversed. The message is sent from the MS to the MSC, which then retrieves relevant info from the VLR for forwarding the message to the SMS Interworking MSC, SMS-IMSC. As in the MS originating case the SMS-C and the SMS-IMSC, are usually identical. The IMSC initiates contact with the addressed SC, in case that is necessary, and then forwards the message to the addressed SC. At successful reception a report is sent in the corresponding direction. The communication and transfer of data is standardised from the SC trough to the MS. But beyond the SC the transfer protocols are proprietary of the manufacturer of the SC. The transfer of a message uses the GSM control channels, SDCCH or alternatively SACCH. These channels have transfer speeds of 660 and 150 bps, respectively, and as mentioned before a maximum message length of 140 bytes. In case more than one SM that is destined for an MS are waiting in the SMS-C, there is a bit in the SM header that can be set, called More Messages to Send, MMS. When this bit is set, the MSC does not release its contact with the MS until all messages has been sent. This is used to speed up transmission of several SMs, since the MS does Claes Rosenberg 27

Master Thesis in Computer Science not have to be paged, authenticated and so forth for every SM, which would be the normal procedure not using MMS. There is a special type of SM, known as SIM Toolkit Message, STM, [22]. When this message is received, the ME detects that it is addressed to the SIM, at the SIM the content is recognized as a SIM Application Toolkit command, see Section 5.2 below, which is then executed. SMs can be transferred over the GPRS network using its radio channels, [23]. The only major difference from the GSM scenario is that the MSC node and its functionality are replaced by a SGSN. A prerequisite for this to work is that the MS is GPRS attached. Further information on this follows under Section 7.1.

5.2 SIM Application Toolkit


The SIM Application Toolkit, SAT, enhances the interaction through the SIM-ME interface. It provides mechanisms that allow applications, existing in the SIM, to interact and operate with any ME that supports the specific mechanism(s) required by the application, [17] and [18]. This allows, among other things, an operator to upgrade its subscribers MSs Over The Air, OTA, remotely by sending codes to update the SIMs. These codes have so far used SM as bearer, but in 3GPP TS 11.14, [18], a bearer independence feature, was introduced, which allows usage of several different types of bearers, including GPRS. Another major service type made possible is different security applications, such as mobile banking. To secure the transfer of data to and from the SIM/MS, services described in 3GPP TS 03.48, [10], is usually used. Besides OTA updates and security, SAT makes the SIM able to initiate actions to be taken by the ME through so called Proactive commands, which among others include: Setting up a data call to a number and with bearer capabilities held by the SIM. Providing local information from the ME to the SIM. Running an AT command received from the SIM, and returning the result to the SIM. Requesting the ME to launch the browser corresponding to a URL. Establishing and managing a bearer independent protocol.

Not all SIM cards support these Proactive commands, but if they do there is a restriction that the commands or related procedures must not jeopardise service provisioning to the user.

5.3 Security mechanisms for the SIM application toolkit


The 3GPP TS 02.48 [7] and 03.48 [10] specifications provide standardised security mechanisms for the SIM application toolkit, SAT. The SAT provides commands and procedures, which make it possible to have specific applications residing on the SIM. The communication involved in the usage of these applications needs to be secure over the GSM network, to a level decided by the operator or alternatively the application provider.

28

How to use GRPS as bearer for applications residing on the SIM The Sending Application sends an Application Message, a SIM Application Toolkit Message, STM, to the Receiving Application via a Sending Entity and a Receiving Entity. These entities are for example an SMS-C and a SIM. The message is sent in one or more secure packets, where the Sending Entity, under instructions from the Sending Application, applies the security. The applied mechanisms should be indicated in the secure packet. At the receiving end the Receiving Entity is responsible for reconstruction of the Application Message from the Secure Packet(s). Furthermore the Receiving Entity should inform the Receiving Application on which security mechanisms that where used. The transferring of messages in both directions is schematically shown in Figure 9.

Security

Security

Sending Application

Sending Entity

Transport Mechanism

Receiving Entity

Receiving Application

Information flow E.g. a bank or a SIM resident application E.g. an SMS-C or a SIM E.g. SMS E.g. a SIM or an SMS-C E.g. a SIM resident application or a bank

Figure 9 Secure message transferring

The following security mechanisms are covered by the specifications: Unilateral authentication from network to SIM and vice versa. Authentication has the purpose of protecting the entities from malicious use of applications. This is done by verification of the Sending or Receiving Entitys identity by the corresponding Entity. Unilateral authentication means that the authentication is one-way, that is, one party is authenticated. Mutual or bilateral authentication authenticates all or both parties. Message integrity prevents undetected corruption of the Application Message or the whole Secured Packet. This is done in either of three ways: by adding a redundancy check to the Security Header, by adding a cryptographic checksum in the Security Header or by calculating a digital signature on the Application Message. Replay detection protects the Receiving Entity from replay attacks and loss of secure packets. It is done by including a counter in the Security Header, which is protected by including it in the calculation of the checksum or the digital signature. Proof of receipt. This security mechanism provides proof to the Sending Entity that the Receiving Entity has received and forwarded to the Receiving Application, a Security Packet. Proof of receipt has to be requested by the

Claes Rosenberg

29

Master Thesis in Computer Science Sending Entity and is sent by the Receiving Entity as an acknowledgement upon successful reception of a Security Packet. Message confidentiality prevents unsolicited parties from reading or extracting information from the Security Packet. This is done by ciphering, using for example DES or 3DES.

30

How to use GRPS as bearer for applications residing on the SIM

6 SmartTrust Delivery Platform 5


This part is concerned in giving an overview of the functionality and some of the features of the SmartTrust Delivery Platform 5, DP5, [22]. SmartTrust DP5 is a solution that combines Short Message, Over-The-Air, SIM Application Toolkit and WAP technologies and make transparent use of them to application programmers and maintenance staff.
Configuration Manager Alarm Manager Administrator Configuration Manager Order Manager Service Assistant SIM & Services DB Wireless Internet Gateway Service And Device Management Messaging

SFM WSM

A P I

Flow Control O&M

WIG

Web Ass.

STM

Charging

Transport Server

Alarms Customer Application

SMS

GPRS

DP5 Clients

DP5 Core

Figure 10 DP5 overview

DP5 is an extensive solution for wireless application delivery and management. The Wireless Internet Gateway, WIG, provides the channel between the wireless device and the Internet Service. The Device Management gives the operator tools for control of the wireless services and devices. Messaging provides a unified short message flow to and from the wireless devices. The Security framework makes use of the SIMs inherent security features to provide a base for wireless security schemes based on both symmetrical and asymmetrical algorithms, where the latter is one of the foundations in a Wireless Public Key Infrastructure.

6.1 DP5 modules


The DP5 consists of four primary modules, which each consist of one or more modules. Below follows a schematic figure, Figure 11, and short descriptions of the modules, their functions and some of the included components.

Claes Rosenberg

31

Master Thesis in Computer Science


SmartTrust DP5 Service and Device Management

SFM Server Service Assistant Order Manager WSM Server Web Assistant

SmartTrust DP5 Core

WIG WIG Server

O&M

Messaging
Transport Server

Administrator

Charging Server A&C Server

Alarm Manager Configuration Manager

Database

Figure 11 DP5 components and modules

DP5 Service and Device Management DP5 Service and Device Management is a tool providing the operator with a single point of control for the over-the-air, OTA, management of subscribers, their devices and access to wireless services, that is, remote management of SIM files and SIM applications. It has support for most of the major SIM platforms and protocols, which is a big advantage, since these are proprietary and differs from manufacturer to manufacturer. The Service and Device Management module consists of two separate components, which are described below. The SIM File Management server. The SFM provides OTA management of SIM card files, supporting the 3GPP TS 03.48 Remote File Management standard, [10], as well as, all of the major vendor-specific OTA protocols. When the SFM server receives an OTA request from a DP5 client, it verifies the correctness of the request and then builds a corresponding request with SM(s). After that the SM(s) are sent to the Transport Server, which is responsible for forwarding the data to the MS via an appropriate SMS-C. Examples of files that can be changed or updated are: MSISDN, PLMN Selection and Forbidden PLMN. The Wireless Service Management server. The WSM provides a tool for management of the users access to WIG-based services, that is, updating of the menu associated with the WIB and the corresponding scripts. This means that when the WSM tool is used for management of the WIG services, two files are updated on the SIM, the menu file and the Script file. More information on the WIG and the WIB follows below.

Both of these modules services are accessible through a number of different interfaces, for example, C++ APIs and Java APIs.

32

How to use GRPS as bearer for applications residing on the SIM DP5 Operation & Maintenance The Operation and Maintenance, O&M, module provides the different parts of the system with common services. Some of these services and functions are: Configuration Management. A DP5 configuration has certain data associated to it, which is stored in a registry database. Charging Services. This service receives charging data from all the DP5 components. The data is stored in files and can be accessed by file transfer. The charging events stored, contain data that makes it possible to identify which entity or user that requested a service, a time stamp, a unique charging event identification and the subscribers MSISDN. Alarm Management. Information about the alarms and counters available in the DP5 can be accessed over Simple Network Management Protocol, SNMP. Furthermore, alarms can be monitored with the module called Alarm Manager. Performance Management. This management is realised by performance counters that are used for providing data for, among other things, statistics and diagnostics. The values of the different counters can be retrieved using SNMP. Fault Management. Examples of tools available to be used for fault management are alarm counters and event logging. The former can be used to identify abnormal behaviour in the system, such as supervision of queue lengths. The latter tracks requests trough the system and logs any failures. This makes trouble shooting on subscriber level possible. Overload protection. Overload within the system are prevented using flow control. This is achieved by the usage of flow control. The flow control can be adjusted to possible limitations within the system, whether it is the DP5, connected SMS-Cs, external applications or anything else.

DP5 Wireless Internet Gateway DP5 enables publishing of Internet information on the GSM phones of today. By using the Wireless Internet Gateway, WIG, and the SIM Application Toolkit, SAT, terminals get access to WML-based content and applications. To make this possible the terminals need a SIM based WML browser, Wireless Internet Browser, WIB, which allows delivering of Wireless Markup Language, WML, based services to both WAP capable and incapable phones. Moreover, plug-in modules to generate signatures and to retrieve location-based information are available for the SIM browser, both from SmartTrust and as third party plug-ins. This is done by the usage of two entities, the Wireless Internet Gateway. WIG, and the SIM based WML browser, Wireless Internet Browser, WIB. The WIB is a menu driven micro browser residing on the SIM. The menu can be seen as bookmarks in a normal web browser. The entries in the menu typically point to a locally stored WML-application or a URL where the service is located. Browsing involves the WIB and the WIG, plus an operator and a content provider. Figure 12 below shows the entities above together with the traffic flow. Further down a description of the entities roles and behaviours when browsing takes place.

Claes Rosenberg

33

Master Thesis in Computer Science


End User Content Provider HTTP, HTML Web Server Buisness Logic

Standard Web Browser

HTTP, HTTPS, HTML or WML

Mobile Station

Operator

Request WIB GSM 03.48

Push

WIG Server DP5

Figure 12 DP5 WIB and WIG

The WIG server. The DP5 and consequently the WIG server, is usually located within the operators network in some way and needs a connection to one or more SMS-Cs. The server is divided into two logical parts, the request and the push module. Both modules have similar behaviours and the main purpose for them is to receive a web page from a content provider, convert it to byte code and forward it to the WIB, using TS 03.48, [10]. The difference between the two modules lies in how they fetch a web page from the content provider. The request module waits for a request for a web page from the WIB. When a request has been received, the WIG server converts it to an ordinary HTTP request, which is then sent to the content provider. When the content provider returns the web page, the WIG converts it to byte code and forwards it to the WIB. The push module, on the other hand, waits for the content provider to send a web page to some WIB, hence, neither the WIG nor the WIB need taking any initiative, instead the content provider takes this. So when a web page is sent to the WIG, it converts it to byte code and then sends it to the concerned WIB. The WIG server acts as a web browser on the request interface and as a web client on the push interface as a web server, towards the content provider. The Mobile Station, MS. To make this type of browsing possible the SIM in the MS has to be equipped with a WIB. Furthermore, the MS has to support SAT class 2 commands, see earlier versions than 8.0.1 of 3GPP TS 11.14, [18]. The main purpose for the WIB is to run byte code strings and convert them to SAT commands. This byte code could be fetched either from some storage place on the SIM or from the WIG. When the WIB receives a compressed web page for example, it converts the data to corresponding SAT commands. Interaction with the user takes place via the handsets user interface. An important feature in the SAT, used here, is the possibility to add menu entries in the existing menu structure of the mobile phone. The menu is actually the starting point for the user to access the web. Each menu item in the part of the menu belonging to the WIB, points to a byte code string that is executed when chosen by the user. The byte code could be very simple, for

34

How to use GRPS as bearer for applications residing on the SIM example a request for a web page, or more advanced demanding further input from the user before the request is actually sent. The interfaces. The interface between the WIG and the content provider consists of standard HTTP over TCP/IP. Above the HTTP, WML is transported. Secure Socket Layer, SSL, is supported to protect information on the interface to the content provider. Moreover, two-way authentication is supported in both the request and the push interface. The DP5 transport services carry all communication between the WIG and the WIB as showed in Figure 13 below.
DP5 Core
Messaging

PLMN (SMS-C)
Non-Wap Phone with WIB Wap Capable Phone

Transport Server

API

WIG Server

Internet

Database

Content Provider

Figure 13 DP5 Internet Gateway

The WIG uses the standard interface provided by DP5 for TS 03.48 communication to the WIB. The interface between the WIB and DP5 consists of standard, 8-bit, SMS and on top of this 3GPP TS 03.48, [10]. Each 03.48 packet consists of byte code, which when sent to the WIB is a web page and when from the WIB is a request for a new page or user parameters. DP5 Messaging When operators deploy SM services there is a risk that they run into management and access control problems, this since SMS-Cs are often weak in this area. DP5 Messaging provides a unified interface, with concurrent access to an array of SMSCs, based on its support for most of the major SMS-C access protocols. DP5 forms a platform for value-added services based on Over-The-Air, OTA, SIM services. By using SM as the information carrier, the technique is also widely compatible. DP5 provides transport services used by all DP5 functional modules. It is also available to external applications via the Software Development Kit, SDK. The platform provides full support for short message transport according to ETSI GSM 03.40, [9], including e.g.: 7-bit text messages. 8- and 16-bit (Unicode) binary short messages. Concatenation of short messages. 3GPP TS 03.48, Security mechanisms for the SIM Application Toolkit, [10].

The transport services can act in either of two ways, as a gateway to an SMS-C, or provide similar store-and-forward features as the SMS-C, including full transaction recovery and delivery confirmation. Figure 14 below depictures the Transport Server and the Transport Server API, which are the involved entities in DP5 Messaging. Claes Rosenberg 35

Master Thesis in Computer Science


DP5 Core

PLMN (SMS-C)

API

Transport Server

API

Customer Client

Database

Figure 14 DP5 Messaging components and related objects

Applications using the DP5 SDK are authenticated towards the DP5 for access to the addressed SIM card, as well as, the potentially addressed SIM Toolkit Application. The DP5 keeps a status report on all sent SMs and if needed informs the concerned application. The recovery service provided is based on an optional storage of SMs and their status in a database. In case a SIM Toolkit Message is too large to be sent in a single SM, the Transport Server can divide the message into several parts, which are sent sequentially and then concatenated in the SIM. The Transport Server includes the following functionality: Receiving short messages requests from any of the servers in DP5 or from external entities and sending them to an SMS-C. Handling status information concerning sent SM. Each SM goes through three statuses, sent, on-route and delivered. Besides these, there is also a set of different error statuses. Receiving short messages from the SMS-C and forwarding them to the corresponding waiting entity in DP5 or to an external entity. Handling the interfaces towards different SMS-C suppliers' proprietary protocol. Providing the transport service for application messages exchanged between a SIM Toolkit application residing on a SIM card and an application connected to SmartTrust DP5.

Since the protocol to each specific SMS-C is proprietary the functionality may be limited depending on the brand of SMS-C the current operator has chosen. The SMS-Cs used either TCP/IP or X.25 and therefore the Transport Server supports both of them. Flow control is an important part of a transactional platform like the DP5. The Transport Server implements flow control to handle varying traffic load. With flow control the Transport Server can reject incoming requests if its load is too high. The Flow control is implemented both in sending and receiving direction in the Transport Server. Transport Server API The Transport Server SDK consists of a C++ API and developer documentation. It has methods for sending SMs and SIM Toolkit Messages, STMs, and for listening for incoming messages from the handset via the SMS-C. 36

How to use GRPS as bearer for applications residing on the SIM

6.2 The Inverted Transport Server


For evaluation purposes SmartTrust has created a simulator, the Inverted Transport Server. With the aid of this, both internal and external parties can evaluate performance of the system, test new releases of entities in the DP5 as well as external applications. The name of the simulator comes from that it is based on the Transport Server, with the addition of some new software. Below follows a simple figure showing the simulated environment.

TS
API

IP/X.25

INV. TS
API

API

API

Application

Application

Figure 15 SIM applications in a simulated environment

The Inverted TS simulates the route an SM must traverse between the TS and the SIM. The major part in this is the simulation of the SMS-C and its proprietary protocol and behaviour. Via APIs, some applications, for example testclients specialised on some type of tests, can communicate over the test environment. As seen in the picture, the Transport Server and the Simulator are connected via IP or alternatively X.25. This approach makes it possible to run the whole test environment on a single machine.

6.3 Future work on SmartTrust DP5


Two developments, which have correlation with this thesis, are planned for future version of the SmartTrust Delivery Platform: an internal SS7 interface and support for GPRS. The Transport Server possesses the same main characteristics and behaviour as an SMS-C. That is, it has its own store and forward service, delivery confirmation, recovery ability and so forth. These capabilities make the transmission via an SMS-C redundant and inefficient. The planned solution is to give the transport server its own SS7 interface to the network, and through that bypassing the SMS-C. A lot of things are needed for this to be possible, where the most fundamental thing is licensing of the DP5 as a node in the concerned networks. The support for GPRS is highly interesting for SmartTrust to offer to their customers, since many of them have invested a lot of money in the technique and gladly see it being used. The support is under evaluation, where this master thesis is one of the parts.

Claes Rosenberg

37

Master Thesis in Computer Science

7 Solutions
The goal of this thesis work is, as mentioned before, an investigation of how GPRS could be used as the bearer for SIM residing applications, instead of SMS, which is being used today. This replacement should be transparent for the applications on both sides of the communication, according to Figure 16 and 17 below. That is, the applications should be unaware if the data has been transferred using SMS or GPRS. Moreover, the security level existing in the environment today should not be decreased with the introduction of the new bearer. Due to the gradual penetration of GPRS, the bearers should coexist as long as necessary. This coexistence also serves as availability security during the operators limitation of GPRS channel allocation. In Figure 16 and 17 only the Transport Server of the SmartTrust DP5 is showed. The reason for this is that the software work that is proposed in this thesis work should be done in the Transport Server and Simulator, exclusively.

TS
API

IP/X.25

SMSC

GSM GSM

ME
SIM

API

API

Application

Application

Figure 16 DP5 Transport environment using SMS

TS
API

IP/X.25

GPRS GPRS

ME
SIM

API

API

Application

Application

Figure 17 DP5 Transport environment using GPRS

I believe in three different, potential solutions for replacing SMS with GPRS as bearer for SIM residing applications. The descriptions of the solutions, which follow, are accompanied by the additions that have to be made to the network for the solution to work. Furthermore, pros and cons, as well as, speculations on transfer efficiency and potential advantages for the SmartTrust DP5 are presented. 38

How to use GRPS as bearer for applications residing on the SIM

7.1 SMS over GPRS


The GPRS standard, [11], states the following: It shall be possible for a GPRS-attached MS to send and receive short messages over GPRS radio channels. This solution only demands a specialised SMS-C, with the interface Gd towards the SGSN and naturally an MS supporting GPRS. According to the standards, [9] and [11], the transmission should, in short terms, be done as follows. When an SMS-C receives a Mobile Terminated, MT, SM, it should start by asking the HLR for routeing information for the MS. The response can either include an SGSN number, an MSC number or both. If the response includes an SGSN, the SM is sent to the MS via the SGSN, using the Gd interface between the SGSN and the SMS-C. If this works, that is, a positive delivery report is returned to the SMS-C, the transmission is considered done. However, in case no SGSN number is initially returned from the HLR or if the transmission fails when using the SGSN, the SM is sent to the MSC, that is, the way it worked prior to the introduction of GPRS. The actual choice between SGSN and MSC is up to the operator, but apparently it is more radio resource efficient to use the SGSN for SMS delivery, [11]. However important this saving of radio resources, when using the SGSN, might be for the operator, a more interesting question is if using the SGSN increases the transfer speed. To answer this question there are some facts that has to be clarified. When sending an SM over GPRS the carrier is the PDTCH. In GSM the transmission uses either the SACCH or the SDCCH, the former if a TCH is allocated and the latter if not. Both of these channels are control channels, with certain inherent characteristics, where the major issue would be that they share resources with the control signalling that is sent. The GSM control channels have fairly low transfer capacities, 660 and 150 bps respectively, which is usually lower than what can be expected on the PDTCH. However, it is more complicated than that, for example, the PDTCH shares resources with other logical channels and the SMS-Cs sending capabilities is independent of channel type. In conclusion, it is hard to estimate potential transfer gains using the PDTCH without vast system information or actual trials. SmartTrust has conducted trials, [36], using SMS over GPRS in the Icelandic operator Islandssimis network, [29]. Traffic were pushed from their DP5 to an Ericsson T39, using both the SGSN and the MSC. The trials were not exact time wise, that is, a wristwatch was started when a message was pushed and the time was registered when it arrived to the phone. Hence, the result should be used with this in perspective. Three different sizes of messages were pushed three times each. The first consisted of one SM, the second of two and third of four. Table 6 below shows the resulting times.
Table 6 Results from trials with SMS over GPRS Message size in SM 1 2 4 Time when MSC used (s) 5-6 14 22 Time when SGSN used (s) 2-4 5 7-9

The big time differences when sending more than one SM are most likely due to the fact that for every new SM that the SMS-C sends via the MSC, the MS has, among other things, to be paged and authenticated. This procedure can be made more Claes Rosenberg 39

Master Thesis in Computer Science effective using More Messages to Send, MMS, where the MS is only paged before transmitting the first SM, see Section 5.1. Furthermore, the trial was made on a live network, where little can be said about, for example, the traffic density during the time of the trials. Even though this trial far from proves anything on if or if not using GPRS for SMS is faster, it indicates that there should be further and more scientific trials made to get more accurate transfer times. The advantages of this solution are that only the SMS-Cs needs updating and the positive characteristics of the SMS, such as, store and forward and data download to SIM, are transparently inherited. One disadvantage with this solution is that the limitation of 140 bytes per SM remains, that is, if say a 350-byte message is to be sent from the SmartTrust DP5, it has to be divided into three SMs. In Sweden today, there are three different GPRS networks; none have SMS-Cs that support SMS over GPRS. Furthermore, none of them have plans, at the moment, to implement it, [33], [34] and [37]. This solution is actually not a real replacement of SMS; it is rather an amalgamation of the two techniques, since SMS is still used with all its characteristics, but the channel is new. In conclusion, there are radio resource savings to be made by the operator and probably increased transfer speeds could be expected using this solution, which would benefit the user. The implementation of this solution mainly concerns the operators in such way that it is the SMS-Cs that need updating. Hence, this solution is transparent for SmartTrust until their future plans of bypassing the SMS-C are realised, see Section 6.3.

7.2 Next generations of Messaging Services


As the success for SMS is becoming more and more evident all over the world, the work on its successors has been going on for some time now. Together with proprietary solutions, such as, Smart Messaging from Nokia [30], ETSI and 3GPP have come up with a standard initiated by Ericsson, called Enhanced Message Service, EMS or eSMS [9]. Furthermore, the next step has been standardised as well, Multimedia Messaging Service, MMS.

Enhanced Messaging Service


As the name implies this is an enhancement of SMS. However, it is very similar to its predecessor in that it uses the same SMS-Cs. The enhancement consists of the ability to send formatted text, small pictures, sounds and simpler animations. The concept is built on using, the already supported, User Data Header, UDH, which makes it possible to include binary data in an SM prior to possible text, [9]. Moreover, an Enhanced Message, EM, may consist of more than one SM. Since existing SMS-Cs already support UDH no additions need to be made to the network, with a small reservation. In case operators want to charge differently for EMS, compared to SMS, for example a flat fee independent of how many SMs the EMS uses, then new charging technology has to be implemented in the SMS-C. Even though the networks do not need upgrading, the terminals, that is, the MSs need to support this new message format. This implies that for the service to be used, this 40

How to use GRPS as bearer for applications residing on the SIM type of MSs needs to have a certain penetration, which means that a certain amount of telephones with this support have to be out on the market. The operators hope that this service will increase the traffic amount, since EMs are larger than regular SMs. This solution does not provide anything relevant for the DP5 that are not already supported, with the exception of the ability to send fancier messages. The ability to send larger data packets using segmentation and concatenation is already supported and since the old infrastructure is reused, increased transfer speeds cannot be expected.

Multimedia Messaging Service


MMS is the most advanced Messaging Service standardised by ETSI/3GPP so far. Like its predecessors it is a non-realtime service with the store and forward capability and delivery confirmation. As the name suggests the service has the ability to send and receive rich media, such as, text, sounds, images and video. Despite the similarities to SMS, MMS is described by 3GPP in TS 23.140, [20], as a new service which has no direct equivalent in the previous ETSI/GSM world or in the fixed network world. This technique uses the available packet switched network, be it GPRS, UMTS or anything else. It needs a complete update of the networks messaging infrastructures, where entities have to be installed. Furthermore, the terminals need special support to be able to send and receive MMs. Four new important entities are involved in the actual messaging. MMS User Agent, UA. This entity resides on the phone and is an application layer function, which makes composing, sending, receiving, viewing and so forth, of MMs possible. MMS Relay and MMS Server. These entities are responsible for incoming and outgoing messages, transferring of messages between different messaging systems and generating of charging data. Together these can be viewed as the equivalent to the SMS-C in SMS, that is, they provide the store and forward functionality, as well as, the delivery confirmation. They are usually collocated, and are as that referred to as Multimedia Message Service Centre, MMS-C, but can be separated. MMS User Databases. Usually several entities that store different types of user information, that is, the HLR is included but there is more information, for example, user profiles.

In short, an MM is sent and received by phones as follows. A user composes the message using its User Agent and then sends it to the originator MMS-C. The MMSC checks for the recipient MMS-C, if it is not itself it forwards the message to the corresponding one. The recipient MMS-C stores the MM and then informs the recipient User Agent that there is a message available, by pushing an MM notification to it. The User Agent can then choose to retrieve the message immediately, later on or the retrieval is done automatic. The originating or receiving User Agents do not have to be residing on phones; it might as well be a mail client, an external server or any other type of node with some kind of connection to the network.

Claes Rosenberg

41

Master Thesis in Computer Science The following table, Table 7, summarises some interesting similarities and differences between SMS and MMS.
Table 7 Differences and similarities between SMS and MMS. Source [21] Feature Store and forward Delivery confirmation Supported media Delivery mechanism Protocol SMS Yes Yes Text and binary Signalling channels SMS specific, proprietary MMS Yes Yes Text, sound, video, etc. Data traffic channel Internet protocols, such as, MIME, SMTP

This technique surely changes the way users send messages between each other, but can it be used as a bearer for applications residing on the SIM? Alas, I have no concrete answer to this. The major issue is, if messages can be directed to the SIM or not. The present specifications [19] and [20] do not specify anything on this matter and I have not found any literature that does either. However, one can imagine that the User Agent could be able to redirect messages to the SIM using a special message type or something else to identify that the message is meant for the SIM. Since this is not specified by 3GPP, manufacturers of involved equipment will most likely make proprietary solutions if needed. Alternatively, 3GPP specifies this in later releases of involved specifications. The initial implementations of MMS use WAP as transport protocol and SMS as MM notification bearer, according to the illustration below. These solutions imply, among other things, that, in theory, MMS is able to use both circuit and packet switched bearers. Figure 18 below shows how Sonera plans to implement MMS in their network, using WAP over GPRS and SMS.
MMS-C IP Network

WAP Gateway

SMS-C MM Notification

GGSN MM Submission GPRS Backbone SGSN SGSN MSC/VLR BSS BSS MM Retrieval

ME

ME

Figure 18 Sonera implementation of MMS

The sending ME creates the MM and sends it to the MMS-C via a WAP gateway. The WAP gateway sends an MM notification to the receiving ME using SMS. The receiver can then retrieve the MM over GPRS via the WAP gateway.

42

How to use GRPS as bearer for applications residing on the SIM In conclusion, MMS have a great potential of being a success as the successor to the great income bringer SMS. My guess is that the operators are just waiting for the phones with the necessary support get out on the market. MMS might be interesting in the future for SIM residing applications, since it makes it possible to simplify, as well as, speeding up transfer of larger data packets. However, this demands that messages can be directed to the SIM card, which is not possible today.

7.3 The GPRS Data Channel


Since the SmartTrust DP5 has an IP channel, see Section 6.1, it would be ideal if it was possible to send messages directly to the phone via, for example, the Internet, using this channel. There are however some things that stand in the way of using this in a straightforward manner. Among the problems present, the following should be noticed. When traffic arrives to an MS using GPRS as bearer, there is no way for the ME to realise that this special packet should be routed to the SIM. When SMS is used as bearer, this routeing is done through the usage of a special Process Identifier, PID, in the message header. Both the MEs and the SIM cards available on the market today supports a limited amount of the functions and services specified by ETSI and 3GPP. Another problem is that the scarcity of IPv4 addresses forces the operators to use private and usually dynamic addresses in their GPRS networks. Another reason for using private addresses is that it is easier for the operators to prevent unsolicited traffic into their networks. These facts implicate the usage of some type of Network Address Translation, NAT, entity, which implies that it is complicated to push messages to an MS, especially from an entity outside the network. Even though these obstacles are present I feel that this is the most interesting solution for me to investigate in detail, in this thesis. The reasons for this are that this solution is the most logical one since it overcomes some of the limitations present when using SMS, such as, limited message length. It can be used without adding unnecessary overhead, which would be the case with MMS. Furthermore, it is the most convenient solution for SmartTrust, it is the solution where upgrades to the existing SmartTrust DP5 are necessary and it is likely that necessary support within involved equipment are closest in the future. Hence, I have investigated the possible ways of using the GPRS data channel, keeping a potential implementation in mind. The following text describes different angles of this solutions and then how it is best implemented.

Ideas for the implementation


Quite early in the work the conclusion was reached that the transparent implementation, as in Figure 17, could turn out to be impossible to implement today, if ever. This could be due to lack of sufficient support or capabilities within the GPRS network, the mobile equipment and/or the SIM card. So the task was to find a way to overcome the existing obstacles. Two different ideas came up during the prestudy phase of the thesis work, which are described below. Because of the possibility of trouble with communication directly to the SIM, an alternative solution could be to connect a terminal equipment, TE, for example a laptop, to the ME, according to figure below. The idea is that data is transported via the ME to the TE, using regular TCP/IP, that is, the ME operates as a modem. On the TE there would be some software listening for this data and route it between the SIM Claes Rosenberg 43

Master Thesis in Computer Science and the corresponding node. The communication with the SIM would be through attention, AT, commands, such as +CSIM or +CRSM, according to GSM 07.07, [14].

TS
API

IP/X.25

GPRS GPRS

ME
SIM

Laptop API

AT
API

Application

Application

Figure 19 Simulated environment using AT commands

Another idea is based on the usage of a group of SAT commands, defined as letter class e commands in TS 11.14, [18]. These, so called Proactive commands describe a bearer independent service that allows the SIM to communicate via the ME over several different bearers, for example GPRS. The following commands are of interest OPEN_CHANNEL. Requests the ME to open a data channel. The channel can be opened immediately or when the first data arrives, which is called on demand. The SIM provides the ME with necessary information for setting up a PDP context. CLOSE_CHANNEL. Requests the ME to close the data channel with the specified Channel identifier. RECEIVE_DATA. Requests the ME to return data to the SIM from the data channel with the specified Channel identifier. SEND_DATA. Requests the ME to send data from the SIM using the specified channel. SET_UP_EVENT_LIST. The SIM supplies the ME with a list of events that the ME should inform the SIM if any of them occurs. The interesting event here is the Data Available event, which informs the SIM that there is up to 255 bytes of data available on the data channel with a certain identity. If more than 255 bytes are available the hex code FF is used.

This type of SAT commands are more suitable than the solution with a laptop communicating with the SIM via AT commands for SIM residing applications, which is the case here. Besides this, these SAT commands can make it possible to initiate communication from a node in the current PDN, for example a Transport Server, which is not allowed in the initial implementation of GPRS networks. Hence, I started checking the possibilities of using this class e commands. Besides the obvious support within the SIM, the ME must support the letter class e. To find out what the ME supports one can check the Terminal Profile, TP, which is data sent from the ME to the SIM at initialisation, which tells the SIM what the ME is capable of. The profile consists of an amount of bytes, where each bit tells if a certain facility is supported. The bytes follow the TS 11.14, [18], and according to this it is mainly the 44

How to use GRPS as bearer for applications residing on the SIM twelfth byte that is concerned with the bearer independent services, that is, class e SAT commands. Retrieving the Terminal Profile At SmartTrust there is test equipment that can log all traffic sent between SIM and ME and at initialisation the Terminal Profile is sent from ME to SIM. I got access to two GPRS capable MEs, a Motorola Timeport T260 with a SIM from Europolitan and an Ericsson T39m with a Telia SIM. The software, SmartMonitor and the equipment comes from a company called Aspects Software Limited, [24], and consists of something called a paddle, which is like SIM card with a serial output that can be connected to a computer. The real SIM card is put in a reader that is connected to the computer. When the ME is turned on, a SIM initialisation is conducted and SmartMonitor logs all data sent between the SIM and the ME. When I tried this at first, it would not work with either of the phones. I did two other tests with non-GPRS capable phones, which worked out fine. I draw the conclusion that something could be different with the new phones compared to the old ones. Contact was taken with the manufacturer, who after a couple of days replied with the answer that the problem was the paddles I used. Apparently the paddles took some current from the phone at start-up, which, with the new phones using as little voltage as possible to increase battery life, led to problems. A new paddle, that had a pull-up resistor added to it, solved this problem. After this the tests worked fine. Five different tests were made: 1. Ericsson T39m with Telia SIM. 2. Ericsson T39m with Europolitan SIM. 3. Motorola Timeport T260 with Europolitan SIM. 4. Motorola Timeport T260 with Europolitan SIM with another paddle. 5. Motorola Timeport T260 with Telia SIM. An example of a terminal profile from the T39 can be found in Appendix B. The first thing that was noticed was that the Europolitan SIM was a phase 2 SIM and the Telia SIM was a phase 2+. The former makes it impossible to retrieve the TP from an ME, since this is not supported. However test one and five showed as suspected that there is no support for letter class e in either of the MEs. In fact the TP consists of just four bytes in both MEs, which limits the amount of proactive SIM commands to the basic ones, such as DISPLAY_TEXT, PLAY_TONE and SEND_SHORT_MESSAGE. Test 3 and 4 confirmed that there was no difference between the paddles. The results shows, as suspected, that the two phones that were available at the time of the tests, were not supporting the necessary SAT commands. However, support for them will surely come within the next year or so. According to Motorola their new phones that will be released during 2002, might have support for SAT commands of letter class e, [35].

Claes Rosenberg

45

Master Thesis in Computer Science

The Implementation
This section describes how the communication to and from applications residing on the SIM, using SAT commands and the functionality of the Transport Server, work. Firstly, a shorter overall description on how the communication takes place is provided, followed by a description of the functionality of the TS today. After that, the necessary additions to the TS are presented and a schematic description of procedures involved in the communication is given. Finally, the existing Simulator and the necessary additions that have to be made for trials of the new functionality are presented. Overall description An application sends data to the Transport Server, destined for a SIM with a certain MSISDN. The TS starts by authorising the involved parties and then checks if the MS is GPRS capable and if so, if there is an open connection to it. If the MS is GPRS capable but not connected, the TS creates an STM including the SAT commands OPEN_CHANNEL and SET_UP_EVENT_LIST, see Appendix C, and sends this to the MS. After the message has been sent the TS starts listening to the port number that was included in the STM. After this, security is added to the data according to 3GPP TS 03.48, [10]. The keys necessary for this are extracted from a database available to the TS, using the MSISDN or alternatively the IMSI as key. After the security has been added the data is cloned so that there are two identical copies, where one is divided to fit into SMs and the other is kept for transmission using the GPRS channel. When it is time for the data to be sent, the TS checks if the MS has connected to the port and if so sends the data over the open channel, if not the data is sent using SMS. The Transport Server The transmission of data to and from the Transport Server uses SMS today. Data that arrives to the Transport Server from an application passes through some stages in the TS before it is sent to the corresponding SMS-C. Firstly the TS checks so that the application is entitled to perform the intended action. After that potential security is added to the data using the 03.48 standard, [10]. If the data is larger than 140 bytes it has to be divided to fit into SMs, which is done after the security has been added. The SM(s) are then put in a queue and optional charging information is recorded. SMs are taken from the queue and an appropriate SMS-C protocol is added to the message, before it is sent to the corresponding SMS-C over either IP or X.25. After the message has been delivered, an optional delivery confirmation can be returned to the sending application. The TS has functionality for taking care of the data as SM(s) and similar functionality has to be added for the data going out on the GPRS channel. The additions that have to be made to the TS are based on the overall description above. Firstly, a new entry has to be added to the existing ones in the available database. This is a flag indicating if the MS and SIM is GPRS capable or not. If not the data transmission uses SMS and no new functionality is involved. Secondly, the Transport Server is concurrent, that is, it can handle several clients simultaneously. This is done by the usage of so-called sockets, where each socket describes a connection to a SMS-C. For information about sockets, see for example [4]. This technique shall be reused for the GPRS channel and the addition that has to be made is a mapping in the memory between the MSISDN, the IMSI and a potential socket. This mapping is used by the TS to determine if there

46

How to use GRPS as bearer for applications residing on the SIM is an open connection to a MS or not. If that is the case, no STM has to be sent, the data is just sent using the socket corresponding to the IMSI or MSISDN. Before the TS can send the STM to the concerned MS, the message has to be constructed. As mentioned, the message includes the two SAT commands OPEN_CHANNEL and SET_UP_EVENT_LIST, see Appendix C. The first command shall among other things include the transport layer protocol type, which should be TCP and the IP address and the port number that the TS listens to. The latter command should provide the information so that the event the MS supervising and informs the SIM about is the data available event. A schematic figure and description of how the transfer of messages and data take place are described below. The case here is an MS that is GPRS capable but is not connected to the TS.
App TS SMSC HLR MSC/VLR GGSN SGSN ME SIM

Data STM STM STM STM SAT

PDP Context Activation


OK Data Acknowledgement

Figure 20 Procedures for sending data from TS to SIM using GPRS

1. Data is sent from the application to the Transport Server. 2. The TS creates and sends a SIM Toolkit Message, STM, to the concerned SMS-C. After that the TS starts the message handling described earlier. 3. The SMS-C finds the serving MSC and sends the message to it. 4. The MSC in turn forwards the message to the ME. 5. The ME detects that the STM is destined for the SIM and forwards it there. 6. The SIM receives the message and executes the SAT commands, which is OPEN CHANNEL to the IP address and port number of the Transport Server, plus the instruction to set up the Data available event. 7. A PDP context is activated informing and updating all involved entities. 8. The TS receives a connection request and sets up a socket. The SIM is informed that there is a PDP context activated. 9. The TS sends data available to the IMSI using the corresponding socket. 10. When all data has been received by the SIM, it may optionally send an acknowledgement to the Transport Server, confirming the reception.

Claes Rosenberg

47

Master Thesis in Computer Science The data transferred from the TS is placed in a buffer in the ME. The ME informs the SIM that there is a certain amount of data available and the SIM uses the SAT command RECEIVE_DATA to retrieve it from the buffer. Since there are not any MEs or SIMs available that support the SAT commands that are used here, a simulator has to be used to simulate the non existing parts in the scenario. The Simulator The implementation of the simulated environment, as illustrated in Figure 15, should consist of the Transport Server, the Simulator and applications to send and receive data. The simulated part of the test environment consists of the route from the SIM to the Transport Server, according to the Figure 21 below.
Real case connection Test environment connection

Simulator

BSS

SGSN

GGSN

Internet Internet

ME

IP
SIM

MSC

SMS-C TS

GPRS Additions

03.48 Appl. Appl.

Figure 21 Simulated test environment

The idea that has governed the work with the suggestion for the implementation can be summarised as in the following two sentences. The Transport Server should include everything that is necessary to make the intended scenario work under assumed conditions. The simulator should replace functions and behaviour, which correspond to expected ditto in a future realised network. These intentions would make it possible to use the system in the intended way in the future, since the SmartTrust products have the necessary functionality to communicate with the involved entities to come. No emphasise is spent on the actual applications since they are only the generators and receivers of arbitrary traffic. The simulation functions as an analysis of the proposed solutions. The simulator is based on the existing Simulator, earlier referred to as Inverted Transport Server, described in Section 6.2. Figure 22 below gives an overview of the existing parts and parameters in the Simulator.

48

How to use GRPS as bearer for applications residing on the SIM


Config.param. AckDelay ResultInAck Config.param. ProofofReceiptDelay ResponseCodeProofofReceipt

HLR SIM SMS-C

TransportServer

IP

Simulator

MSC

BSC

BST

MS

ResultInStatusReport StatusReportDelay Config.param.

Figure 22 The parameters concerned with SMS in the Simulator

The configuration parameters in the figure, as well as other relevant data, such as, IP addresses and port numbers, can be configured using an application called Configuration Manager, CM. The CM is a graphic user interface that shows available parameters, their type and effect. The parameters in the figure have the following meaning. AckDelay. Simulates the time it takes for the SMS-C to send an acknowledgement to the TS. This time includes check of data in message, contacts with the HLR and storage of the message. ResultInAck. A message containing either an OK or an error message concerned with any of the three procedures above. ProofofReceiptDelay. This simulates the time it takes before the SIM returns a message confirming the reception of a message. ResponseCodeProofofReceipt. Either an OK or an error message declaring any of the predefined error types. ResultInStatusReport. A message from the SMS-C to the TS, declaring the status of message, for example, delivered or expired. StatusReportDelay. Simulates how much time the generation of the message described above needs.

As these parameters simulate the behaviours related to SMS, additions have to be made for the GPRS parts. This includes the behaviours of the SIM, the ME and the network nodes, that is, interpreting the involved SAT commands, the communication between the SIM and ME and the transfer across the network. The Figure 23 below corresponds to the previous one, but shows parameters associated with GPRS. Claes Rosenberg 49

Master Thesis in Computer Science


Config.param. SendAcknowledgement OpenDelay Config.param. ReceptionAcknowledgement RecAckDelay

SIM MS

TransportServer

IP

Simulator

GGSN

SGSN

BCC

TransferDelay Config.param.

Figure 23 GPRS parameters in the Simulator

The configuration parameters in the figure have the following meaning. SendAcknowledgement, which states if there should be an acknowledgement sent to the TS when the channel is opened OpenDelay, states the time, in seconds, the simulator waits before it connects the IP channel. Simulates the time it takes to perform the PDP context activation. ReceptionAcknowledgement decides if received data should be acknowledged by the MS/SIM. RecAckDelay, which gives the time it takes from reception of data to transmission of acknowledgement. Simulates the actual reception behaviour, where the data is placed in a buffer from where the SIM can retrieve it after being informed. TransferDelay, a special factor that should be used with care. It is meant to simulate the transfer speed in the network.

The additions that have to be made to the Simulator are concerned with handling the GPRS channel. This includes setting up the channel when the correct STM arrives from the TS, sending an appropriate acknowledgement to the TS, setting up an event, that is, listen for data from the TS, handle incoming data and acknowledge reception of data. The transfer of data from the Transport Server to the ME is considered to be transparent in this simulation.

Conclusion
This solution conquers the two major problems stated in Section 1, among other places. The first problem of getting data directed to the SIM is solved using the SAT 50

How to use GRPS as bearer for applications residing on the SIM commands of letter class e, such as OPEN_CHANNEL, SET_UP_EVENT_LIST, as described above. The second source for problems was the shortage of IPv4 addresses, which led to the usage of dynamically allocated private addresses. The usage of the Transport Server, as the responsible node for delivery of data to the SIM, makes it possible to activate a PDP context by sending an STM. This STM includes instructions for the SIM to open a channel. Since the first data is actually sent from the SIM, there is no problem for the traffic from the TS to traverse the possible NAT gateway. Two other disadvantages that GPRS has compared to SMS are that there are no store and forward and no confirmation of delivery. However, by the usage of the SmartTrust DP5 these problems can be nullified. Since the Transport Server offers store and forward, as well as, delivery confirmation, its services could be compared with those of an SMS-C. Furthermore, the security offered before, using the functions described in TS 03.48, is kept, since the security addition in the Transport Server is done before the data package is segmented into SMs The solution might at first seem a bit complicated, with the initial transfer of an SM and then the channel opening and not until then the actual data is sent. But as a validation of this idea, one can do a comparison with Soneras solution to the Multimedia Message Service, which uses very similar ideas for the message delivery, compare Figure 24 below with Figure 18.
Application Transport Server

IP Network

SMS-C STM GGSN

GPRS Backbone
SGSN

MSC/VLR BSS

Data transmission

ME

Figure 24 Data transmission to the SIM using SmartTrust's Transport Server

Since no real trials were possible, some assumptions have been made, which should be motivated. The idea is to do this by referring to standards, existing similar solutions and/or by exclusion of alternatives. The first thing that has to be mentioned here is that the usage of SAT commands of letter class e, is completely based on the standard [18], that is, no other sources of information were found on this subject. Hence, the assumption is that the standard has been correctly interpreted and that future implementations of the standard will behave

Claes Rosenberg

51

Master Thesis in Computer Science as expected here. The motivation for this assumption is that since I could not find any information that contradicted my interpretation, this was the only one I could work on. According to the specification, [18], the ME should be able to take responsibility for the transport layer, and the SIM can instruct usage of TCP or UDP. Hence, the SIM only receives and sends so-called Service Data Units, SDUs, to and from the ME. Since the security mechanisms from the 03.48 specification, [10], are reused it is assumed that there are no problem for the ME, which is the receiving or the sending entity in this case, to utilise the same mechanisms in this case. It is assumed that the type of traffic that is going to be sent have no problem traversing the expected firewalls that the operators have between the GPRS and the Packet Data Networks. Since it is normal IP traffic that is transferred, this is a quite safe assumption to make. When the connection is set up between the Transport Server and a SIM, that is, the TS has a socket to the client, it needs to know to which SIM that socket goes. How this can be solved is dependent on how the SIM card manufacturer has implemented the OPEN_CHANNEL command. The best solution is that the IMSI is included in the connection request, which makes it possible for the Transport Server to make the mapping between the IMSI and the socket directly, as mentioned above, and then send available data destined for that IMSI. A more inconvenient and time consuming solution would be to have the TS query the GGSN which IMSI that corresponds to the IP address and port number which requests the connection. The assumption here is that the SIM vendors choose the most convenient solution and includes the IMSI in the request and if that should not be the case the necessary additions can be added to the TS so that it can query the GGSN. Another assumption that is dependent on the SIM manufacturer is the handling of the data transmitted to the SIM over the GPRS channel. The specification [18] does not specify how the data should be handled once the SIM has retrieved it. I assume that the manufacturers that support the concerned SAT commands have support for handling the received data as well. All alternatives seem very unlike. There are some disadvantages with this way of transferring data, compared to the existing variant with SMS, which deserve to be mentioned. Since there are some procedures that has to be done before the data is sent, the STM from the Transport Server, the activation of the PDP context, among other things. This overhead time implies that unless the data to be sent has a certain size, it is faster to use SMS. This size is something that I dont want to speculate in here, I leave that for future studies when necessary equipment has become available. However, one can imagine that the owner or administrator of the Delivery Platform want to set a desired minimum size of the data to sent, before considering using GPRS. It might even be desired to have some sort of dynamic solution, governed by certain characteristics in the networks. Another liability is the necessity of user interaction when setting up the GPRS channel. When using SMS, the operators can update files on the SIM invisibly, that is, without the user noticing it or interacting in the update. This is for example done when roaming tables are updated. This transparent update or download is not possible in this solution, since the ME prompts the subscriber if she or he accepts the PDP context activation performed in step 7 in Figure 20 above. The operators have a lot to gain in this solution. They can charge for the initial SM as usual, the transmission of the data can be charged as regular GPRS traffic or charged using the charging records collected in the Transport Server. Their subscribers can be 52

How to use GRPS as bearer for applications residing on the SIM offered a wider variety of services, since the transmission of data is not hindered by the limitations of SMS. For SmartTrust this is a perfect solution. The interaction with nodes like the SMS-C or MMS-C is avoided, that is, the transmission control is moved towards SmartTrusts products. The full capacity of the DP5 is used, that is, the store and forward capability, the delivery confirmation and so on. The Transport Server is the fundament, which this solution is built on and the Servers functionalities are a prerequisite. The security mechanisms, using the SIM card, that are one of the strengths when using SMS are reused in this solution. No unnecessary overhead is present, which might be the case when using, for example, MMS, see TS 23.140, [20]. The ability to provide transmissions of larger data amounts leads to an increased usage of the DP5.

Claes Rosenberg

53

Master Thesis in Computer Science

8 Results
SMS over GPRS is the least technically advanced solution of the three described in this thesis, but at the same time the solution with the least impact on the transfer of data. The only updates that have to be made are done at the SMS-C. Alas, only results from rudimentary tests on this technique were presented in this thesis, Section 7.1. These tests indicates however that there might be some transfer time savings to be made, but further studies of these must be made before anything concrete can be said. This solution is transparent to SmartTrusts products, since it is up to the SMS-C to make the decision on whether to use GPRS or not. However, when SmartTrusts future plans of bypassing the SMS-C are realised, this feature should be incorporated in the products. The next messaging services are, firstly, Enhanced Messaging Service, EMS, and secondly, Multimedia Messaging, MMS. EMS does not change the conditions in this context, since it essentially enhances the font of the text in the message, provides the ability to send simpler pictures, animations and sounds, through adding binary data to the message header. However, it still uses SMS as the underlying technique. This service demands support for interpreting the information in the header and presenting the data to the receiver. However, the network can be kept as it is, unless special charging for EMs is desired. No trials whatsoever have been conducted in this area during this work. SmartTrust is already capable of sending larger data amounts in several SMs that are concatenated at the receiving end. The only benefit that SmartTrust can get from incorporating this into their products is the capability to provide the ability to send enhanced messages. MMS could prove to be interesting, provided that traffic could be redirected to the SIM, something that is yet to be specified or given a proprietary solution. If the demand comes up, I am sure that solutions will be found on how to direct traffic to the SIM. When a solution on how to redirect the transmissions arrives, SmartTrust should investigate how they can utilise it together with their products. Using the GPRS data channel is the best-suited solution for applications residing on the SIM in general and for SmartTrusts Delivery Platform in particular. The Transport Server provides the store and forward and delivery confirmation services instead of the SMS-C. The GPRS channel provides a bearer with a greater capacity than the control channels used for SMS and the former constraint of 140 bytes per message is no longer. The updates that have to be made to the Delivery Platform are exclusively in the Transport Server and are mainly concerned with opening and maintaining of a channel towards the GGSN and the GPRS network. The only prerequisite is that the phones and the SIM cards support the letter class e of the SAT commands, something that can be expected from future releases of GPRS capable phones.

54

How to use GRPS as bearer for applications residing on the SIM

9 Future work
The obvious future work would be to try to implement the simulation as suggested here. This could lead to new issues that have been overseen in this work. When the previous work has been done it would be natural to replace parts in the simulation implemented with their genuine counterparts, as they become available. For example, Motorola [35] claims that there may be support for SAT commands of letter class e during next year, depending on demand from the market though. If this proves to be the case, new quantitative tests could be made using real MS and commercial networks. Further investigation should also been done on the solution using Multimedia Messaging Service, as it is becoming available in the market. Will there be support for SIM terminating traffic? Can one implement proprietary solutions in the User Agent? There are many questions, but as the operators and hardware manufacturers are pushing so hard for this technique, it is a good idea to keep an eye on the development. Quantitative trials on SMS over GPRS should be made and the results should be compared with the ordinary SMS, especially using More Messages to Send for more fair results. The eventual introduction of IPv6 will lead to the possibility to provide static, publicly routable addresses to all MSs in GPRS networks, which will change the conditions. How far into the future is this introduction? When it arrives, are the operators interested in providing publicly routable addresses to the subscribers, with the inherent problems of spamming and so forth?

Claes Rosenberg

55

Master Thesis in Computer Science

10 Conclusion
This thesis investigates the possibilities to use GPRS as bearer for applications residing on the SIM. Today SMS is used to transfer data, as the case is with SmartTrusts Delivery Platform. The two major problems that hinder a straightforward usage of GPRS are the complication of directing traffic to the SIM and the shortage of IPv4 addresses leading to the usage of dynamically allocated private addresses. Three different techniques for data transfer to and from applications residing on the SIM, using the GPRS network, are described. Firstly, sending SMS over GPRS, which is the solution that is the most straightforward of the three described here, where only the SMS-C needs to be updated. This is not a replacement of SMS, since the service is still used, but over new channels. Examples of inherited limitations with this solution are the limitation of 140 bytes per short message is still there and since the traffic must pass the SMS-C, the store and forward functionality is present. Furthermore, because all data are transferred via the SMS-C the two stated problems will have no effect: There is no problem addressing SMs to the SIM and the IP or X.25 address of the SMS-C is available to the Delivery Platform. Since operators are able to save radio resources using this upgrade, I believe that the support for SMS over GRPS will become more and more common as the GPRS capable phones become more frequent. The operators have resource savings to do and hopefully the subscribers can experience some increased transfer speeds. Secondly, next messaging services, which are Enhanced Messaging Service and Multimedia Messaging Service. EMS is based on SMS, that is, an EM is one or more SMs with additional binary data in the message header. This data makes it possible to format the text in the message, send simpler pictures, animations and sounds. This technique does not affect the transfer capabilities or speeds in any way; it only provides the ability to present the messages that are transferred, in a fancier way. Since SMS has become such as massive success, all involved parties are very interested in the launch of MMS. This opens the doors for new services from service providers, new phones to be sold from the hardware vendors and escalating revenue from messaging for the operators. In this case the problem with the private addresses is avoided since MMs are sent to MMS-C, from which the receiver then retrieves the message. However, the problem is that there are no specifications on how the messages should be directed to the SIM. In case demand for this will arise, proprietary or standardised solutions are guaranteed to come. Thirdly, using a GPRS channel set up by the SIM Application Toolkit, SAT. This alternative is a clever usage of the new type SAT commands of letter class e, which establishes a channel between, in this case, the Transport Server and a SIM. When the Transport Server sends an SM to a SIM containing necessary data for executing the appropriate SAT command both of the mentioned problems are conquered. The channel is between the SIM and the Transport Server; hence, traffic will reach the SIM. The Transport Server initialises the connection through sending an SM, but it is actually realised by the phone, which means that the problem with the private addresses is overcome. 56

How to use GRPS as bearer for applications residing on the SIM This solution is the best suited for SmartTrust because the product that the company has, that is, the Delivery Platform, makes this solution possible. The solution makes it possible to offer services that demand larger transfers and it is the next natural step to develop for SmartTrust. Furthermore, it is similar to the solution that Sonera has chosen for their implementation of MMS, which can serve as a validation of the ideas feasibility. It should not be used for smaller transfers, such as, messages, but could be suitable for larger ones, such as, larger application downloads, where it would be next to impossible to use SMS. A proposal on how this solution could be implemented is given. The implementation is dependent on the Delivery Platform from SmartTrust and adds necessary functionality to the existing. Furthermore, suggestions on how the available simulator could be updated for trials and verifications are presented. Certain assumptions have been made when describing the implementation, due to the fact that the available information, mainly specifications, is not that comprehensive. Many details are left for future releases of specifications or proprietary solutions. The main assumptions that have been made concerns the interpretation of the specification of the SAT commands is correct, the continued usage of the security mechanisms described in TS 03.48 [10] and the handling of retrieved data in the SIM. More details on the assumptions and their justification can be found under Section 7.3. I believe that a combination of using the GPRS data channel together with the class e SAT commands for larger data transfers and SMS over GPRS for smaller is the best way to utilise GPRS for applications residing on the SIM. This leads to increased transfer speeds for SMS and the ability to offer secure data consuming services and applications for SmartTrust and other companies utilising applications residing on the SIM. Finally, I have some personal reflections on the work with the thesis. A big challenge with this project has been the problems to find sources of information that are initiated in the technique, which in this case not just means GPRS in general, but more in the usage of the new SAT commands, traffic to the SIM and so forth. I must say that I have not been successful on this area, which initially led to some frustration, but has during the course of the work turned out to be quiet inspiring. The reason for this is mainly that I have had to come up with most of the ideas myself, with the help from my advisor, evidently. Another side of this coin is obviously that I might have missed some facts that might alter the choice of solution. I realise that the risk for this is not negligible. Still, that will not change the fact that this is one solution and it is mine.

Claes Rosenberg

57

Master Thesis in Computer Science

11 References
Books and publications
1. Andersson, Christoffer, GPRS and 3G Wireless Applications, John Wiley & Sons, ISBN: 0471414050, 1 edition, 2001. 2. Lin, Yi-Bing and Chlamtac, Imrich, Wireless and Mobile Network Architectures, John Wiley & Sons, ISBN: 0471394920, 1 edition, 2000. 3. Lindemann, Christoph and Thmmler, Axel, Evaluating the GPRS Radio Interface for Different Quality of Service Profiles, Department of Computer Science, University of Dortmund, 2000. 4. Tanenbaum, Andrew S, Modern Operating Systems, Prentice Hall, ISBN 0135881870, 1992. 5. GPRS overview, APIS Training and seminars, 2000.

Standards and specifications


6. GSM 01.02, Digital cellular telecommunications system (Phase 2+); General description of a GSM Public Land Mobile Network (PLMN), version 6.0.1, ETSI 2001. 7. 3GPP, 3GPP TS 02.48, Digital cellular telecommunications system (Phase 2+); Security Mechanisms for the SIM application toolkit; Stage 1, version 8.0.0, ETSI 2000. 8. 3GPP TS 02.60, Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Service Description; Stage 1, version 7.5.0, ETSI 2000. 9. GSM 03.40, Digital cellular telecommunications system (Phase 2+); Technical Realization of the Short Message Service (SMS, version 7.4.0, ETSI 1999. 10. 3GPP TS 03.48, Digital cellular telecommunications system (Phase 2+); Security Mechanisms for the SIM application toolkit; Stage 2, version 8.5.0, ETSI 2001. 11. 3GPP TS 03.60, Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Service Description; Stage 2, version 7.6.0, ETSI 2001. 12. 3GPP TS 03.64, Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Overall description of the GPRS radio interface; Stage 2, version 8.8.0, ETSI 2001. 13. GSM 04.60, Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Mobile Station (MS) Base Station System (BSS) interface; Radio Link Control/Medium Access Control (RLC/MAC) protocol, version 8.4.1, ETSI 1999. 14. GSM 07.07, Digital cellular telecommunications system (Phase 2+); AT command set for GSM Mobile Equipment (ME), version 7.5.0, ETSI 1999.

58

How to use GRPS as bearer for applications residing on the SIM 15. 3GPP 07.60, Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Mobile Station (MS) supporting GPRS, version 7.2.0, ETSI 2001. 16. GSM 09.60, Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP); across the Gn and Gp Interface, version 7.5.1, ETSI 2000. 17. GSM 11.11, Digital cellular telecommunications system (Phase 2+); Specification of the Subscriber Identity Module Mobile Equipment (SIM ME) interface, version 8.3.0, ETSI 2000. 18. 3GPP TS 11.14, Digital cellular telecommunications system (Phase 2+); Specification of the SIM application toolkit for the Subscriber Identity Module Mobile Equipment (SIM - ME) interface, version 8.8.0, ETSI 2001. 19. 3GPP TS 22.140, 3 rd Generation Partnership Project; Technical Specifications Group Services and System Aspects; Service Aspects; Stage 1; Multimedia Messaging Service, version 4.1.0, 3GPP 2001. 20. 3GPP TS 23.140, 3 rd Generation Partnership Project; Technical Specifications Group Terminals; Multimedia Messaging Service (MMS); Functional description; Stage 2, version 4.4.0, 3GPP 2001.

White papers
21. Next Messaging An introduction to SMS, EMS and MMS, Mobile Lifestreams. Available from http://www.mobilewhitepapers.com/papers.asp 22. Technical Description, DP5, Version 5.1, Document Number 17409077, Revision H, SmartTrust, 2001. 23. Why SMS if we have GPRS, Logica Mobile Networks, Aldiscon Limited, 1999.

World Wide Web


24. Aspects Software Limited, www.aspects-sw.com Accessed 2001-10-09. 25. All about General Packet Radio Service (GPRS) on mobile networks mobileGPRS.com, Mobile GPRS, http://www.mobilegprs.com/developers.asp, Accessed 2001-11-27. 26. Comviq, Comviq, http://www.comviq.se Accessed 2001-10-09. 27. GSM Association Network Statistics, GSM World http://www.gsmworld.com/membership/ass_net_stats.html, Accessed 2001-11-27. 28. GSM - Association Subscriber Forecast, GSM World http://www.gsmworld.com/membership/ass_sub_fore.html, Accessed 2001-11-27. 29. Islandssimi, www.islandssimi.com Accessed 2001-10-09. Claes Rosenberg 59

Master Thesis in Computer Science 30. Nokia on the web, Nokia, http://www.nokia.com/main.html Accessed 2001-11-12. 31. Telia.se: Telia.se, Telia, http://www.telia.se, Accessed 2001-10-09. 32. www.europolitan.se, Europolitan, http://www.europolitan.se/001.euro, Accessed 2001-10-09.

Personal communications
33. Comviq customer service, Josefin Lindh, Personal communication. Mail received 2001-11-09. 34. Europolitan Vodafone Internet support, Personal communication. Mail received 2001-11-09. 35. MAGNET Center Developer Support, Motorola Applications Global Network, Personal communication. Mail received 2001-09-10. 36. Sonera SmartTrust AB, Johan stman, Customer Project Manager, Personal communication. Test results received 2001-11-02. 37. Telia Mobile AB, se Lundberg, Personal communication. Mail received 2001-12-07.

60

How to use GRPS as bearer for applications residing on the SIM

Appendix A
2G 2.5G 3G 3GPP API APN ARQ AuC BCCH bps BS BSC BSS BSSGP BTS CCCH CCU CGF CM DHCP DLL DNS DP5 EDGE EIR EMS eSMS ETSI FDMA GGSN GMSC GSM GPRS GTP HDLC HLR HTTP IMEI IMSI IPv4 IPv6 ISDN IWF
nd

Abbreviations

2 Generation of mobile networks usu. GSM Generation 2.5 of mobile networks usu. GPRS 3 rd Generation of mobile networks usu. UMTS 3 rd Generation Partnership Project Access Point Identifier alt. Application Programming Interface Access Point Name Automatic ReQuest for retransmission Authentication Centre Broadcast Control Channel bit per second Billing System Base Station Controller Base Station System BSS GPRS Protocol Base Transceiver Station GSM Common Control Channels Channel Coding Unit Charging Gateway Functionality Configuration Manager Dynamic Host Configuration Protocol Dynamic Link Layer (In transmission plane) Domain Name System SmartTrust Delivery Platform generation 5 Enhanced Data Rates for Global Evolution originally Enhanced Data Rates for GSM Evolution Equipment Identity Register Enhanced Message Service Enhanced Message Service the European Telecommunications Standards Institute Frequency Division Multiple Access Gateway GPRS Support Node Gateway Mobile Switching Centre Global System for Mobile communications General Packet Radio Service GPRS Tunnelling Protocol High-level Data Link Control Home Location Register Hyper Text Transfer Protocol International Mobile station Equipment Identifier International Mobile Subscriber Identity Internet Protocol version 4 Internet Protocol version 6 Integrated Services Digital Network InterWorking Functions 61

Claes Rosenberg

Master Thesis in Computer Science Kbps LA LAI LLC MAC MB MCC MM MMI MMS MNC MO MS MSC MSISDN MSRN MT NAT NS NSAPI O&M OTA PACCH PAD PAGCH PBCCH PCCCH PCU PDA PDCCH PDCH PDN PDP PDU PLL PLMN PPCH PPP PRACH PSDN PSTN PSPDN PTCCH P-TMSI QoS RA RAC 62 kilobits per second Location Area Location Area Identity Logical Link Control (layer) Medium Access Control Mega Byte Mobile Country Code Mobility Management alt. Multimedia Message Man Machine Interface Multimedia Messaging Service alt. More Messages to Send Mobile Network Code Mobile Originating (about traffic) Mobile Station Mobile Switching Centre Mobile Station Integrated Services Digital Network Mobile Subscriber Roaming Number Mobile Terminal alt. Mobile Terminating (about traffic) Network Address Translation (RFC 1631) Network Service Network layer Service Access Point Identifier Operations & Maintenance Over The Air Packet Associated Control Channel Packet Assembly/Disassembly Packet Access Grant Channel Packet Broadcast Control Channel Packet Common Control Channel Packet Control Unit Personal Data Assistant Packet Dedicated Control Channel Packet Data Channel Public Data Network Packet Data Protocol Protocol Data Unit Physical Link Layer Public Land Mobile Network Packet Paging Channel Point-to-Point Protocol Packet Random Access Channel Packet Switched Data Network Public Switched Telephone Network Packet Switched Public Data Network Packet Timing advance control Channel Packet Temporary Mobile Subscriber Identity Quality of Service Routeing Area Routeing Area Code

How to use GRPS as bearer for applications residing on the SIM RFC RFU RLC SAT SC SDK SDU SGSN SIM SM SMS SMS-C SMS-GMSC SMS-IMSC SMS-SC SNDCP SNMP SN-PDU SSL SSP STM SW1 / SW2 TCP TDMA TE TID TLLI TLV TMSI TP TS UDP UMTS URL VLR WADP WAP WIB WIG WML Request For Comments Reserved for Future Use Radio Link Control (layer) SIM Application Toolkit Service Centre (for Short Messaging) Software Development Kit Service Data Unit Serving GPRS Support Node Subscriber Identity Module Short Message Short Message Service Short Message Service Centre SMS Gateway Mobile Switching Centre SMS Interworking Mobile Switching Centre Short Message Service Centre Subnetwork Dependent Convergence Protocol Simple Network Management Protocol SNDCP Protocol Data Unit Secure Sockets Layer Service Switching Point SIM Toolkit Message Status Word 1 / Status Word 2 Transmission Control Protocol Time Division Multiple Access Terminal Equipment Tunnel Identifier Temporary Logical Link Identity Tag, Length, Value Temporary Mobile Subscriber Identity Terminal Profile Transport Server alt. Technical Specification alt. Time Slot User Datagram Protocol Universal Mobile Telecommunications System Uniform Resource Locator Visiting Location Register Wireless Application Delivery Platform Wireless Application Protocol Wireless Internet Browser Wireless Internet Gateway Wireless Markup Language

Claes Rosenberg

63

Master Thesis in Computer Science

Appendix B

Example of terminal profile

The following text is the terminal profile of an Ericsson T39, which informs the SIM of the capabilities of the ME.
TerminalProfile Bytes = 4d Timer Expiration = No 9E XX response code for SIM data download error = No Menu selection = Yes Cell Broadcast data download = Yes SMS-PP data download = Yes Profile download = Yes Display of Extension Text = Yes UCS2 Display Supported = Yes UCS2 Entry Supported = Yes Handling of the Alpha Identifier = No MO short Message control by SIM = No Cell Identity included = No Call control by SIM = No Command Result = Yes Proactive command: REFRESH = Yes Proactive command: POLLING OFF = Yes Proactive command: POLLING INTERVAL = Yes Proactive command: PLAY TONE = Yes Proactive command: MORE TIME = Yes Proactive command: GET INPUT = Yes Proactive command: GET INKEY = Yes Proactive command: DISPLAY TEXT = Yes Proactive command: PROVIDE LOCAL INFORMATION (NMR) = No Proactive command: PROVIDE LOCAL INFORMATION (MCC MNC LAC CellID & IMEI) = Yes Proactive command: SET UP MENU = Yes Proactive command: SET UP CALL = Yes Proactive command: SEND USSD = Yes Proactive command: SEND SS = Yes Proactive command: SEND SHORT MESSAGE = Yes Proactive command: SELECT ITEM = Yes

64

How to use GRPS as bearer for applications residing on the SIM

Appendix C

SAT Commands

OPEN_CHANNEL The command consists of 12 different fields as shown in the table below. The value of field 3-12 starts with the corresponding tag value, for example, 02, then the length of the rest of the field, for example, 02, followed by the values of the specific field, for example 8182. All values are defined in hexadecimal form.
Table 8 Structure of the SAT command OPEN_CHANNEL Field number 1 2 3 4 5 6 7 Field description Proactive SIM Command Tag Length Command details Device Identities Alpha Identifier Icon Identifier Bearer description Mandatory Yes Yes Yes Yes No No Yes 1 1 5 4 --B (11) Length (byte) D0 29 (41 in decimal) 0103 014010 (immediate link establishment) 0202 8182 (SIM is source and ME is destination) --350902 010403043102 0000 (precedence[1], delay[best effort], reliability[3], peak[4], mean[best effort], PDP type[IP]) 3902 0400 (1024 bytes) 3100 (use default GGSN) 3E0021 (dynamically allocate an IPv4 address) 3C03021E61 (TCP protocol and port number 7777) 3E0521 CA01CF02 (Ipv4 address 172.16.252.32) Value

8 9 10 11

Buffer size Access Point Name Other Address SIM/ME interface transport level Data Destination Address

Yes No No No

4 2 3 5

12

No

Put together the total command looks like this in hexadecimal code: D029 0103014010 02028182 3509020104030431020000 39020400 3100 3E0021 3C03021E61 3E0521CA01CF02

Claes Rosenberg

65

Master Thesis in Computer Science SET_UP_EVENT_LIST This command consists of five different fields as shown in the table below. The value of field 3-5 starts with the corresponding tag value, for example, 02 for Device Identity, then the length of the rest of the field, for example, 02, followed by the values of the specific field, for example 8182. All values are defined in hexadecimal form.
Table 9 Structure of the SAT command SET_UP_EVENT_LIST Field number 1 2 3 4 5 Field description Proactive SIM Command Tag Length Command details Device Identities Event list Mandatory Yes Yes Yes Yes Yes 1 1 5 4 3 Length (byte) D0 0C (12 in decimal) 0103 010500 0202 8182 (SIM is source and ME is destination) 1901 09 (Data availble event) Value

Put together the total command looks like this in hexadecimal code: D00C 0103010500 02028182 190109

66

You might also like