”How to use GPRS as bearer for Claes Rosenberg

Transcription

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: Jörgen 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 operator’s 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 SmartTrust’s existing products are given.
ii
Index
ABSTRACT.............................................................................................................II
INDEX ................................................................................................................... III
1
INTRODUCTION ............................................................................................1
2
BACKGROUND...............................................................................................4
3
ARCHITECTURE OF THE GSM NETWORK.............................................6
3.1
3.2
3.3
3.4
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
5
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
6
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
7
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
RESULTS .......................................................................................................54
9
FUTURE WORK ...........................................................................................55
10
CONCLUSION ...........................................................................................56
11
REFERENCES ...........................................................................................58
APPENDIX A
ABBREVIATIONS..................................................................61
APPENDIX B
EXAMPLE OF TERMINAL PROFILE ................................64
APPENDIX C
SAT COMMANDS..................................................................65
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, card’s 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
1
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 SmartTrust’s 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 operator’s 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
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
SmartTrust’s 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
SmartTrust’s future plans and some personal reflections on the thesis.
Claes Rosenberg
3
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 operator’s 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.
4
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
5
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
B
VLR
BTS
MSC
A
PSTN
GMSC
E
BSC
C
C
BTS
F
D
NSS
BSS
AuC
EIR
HLR
A
A-bis
BTS
BSC
Um
A-bis
BTS
SIM
ME
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.
6
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 operator’s
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
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.
•
The 1900 band is divided into
o 1850-1910 MHz for uplink.
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
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
9
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
B
VLR
BTS
MSC
PSTN
GMSC
E
A
BSC
C
C
BTS
D
F
NSS
BSS
AuC
EIR
HLR
A
A-bis
BTS
BSC
Um
A-bis
BTS
Gb
Gs
Gf
Gr
Gc
ME
Gn
GGSN
Gi
PDN
SIM
SGSN
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 LA’s 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
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).
Among the PDP context fields stored are:
•
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.
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
In the STANDBY state the MS is GPRS attached, that is, the MS and the SGSN have
stored a MM context associated to the subscriber’s 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 it’s 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
PDU
transmission
STANDBY
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
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
•
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.
An MM context is associated with zero or more of these PDP contexts:
•
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.
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:
14
•
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.
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.
For each IMSI zero or more of the following PDP context data:
•
PDP context identifier, type and address.
•
APN.
•
QoS parameters.
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 user’s PDP(s), address(es)
within the PLMN and the user’s 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
Claes Rosenberg
15
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.
•
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
•
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.
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.
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
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
Application
IP/X.25
IP/X.25
Relay
SNDCP
LLC
GTP
SNDCP
GTP
LLC
TCP/UDP
TCP/UDP
BSSGP
IP
IP
Relay
RLC
RLC
BSSGP
MAC
MAC
NS
NS
DLL
DLL
PLL
PLL
Physical
Physical
Physical
Physical
GSM RF
GSM RF
MS
Um
BSS
Gb
SGSN
Gn
GGSN
Gi
Figure 6 Transmission plane
Below follows a description of the more important of the protocols.
20
•
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.
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
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
CS3
15.6 kbps
133dB
390 m
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
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.
Table 2 GPRS Delay classes
Delay class
1. (Predictive)
2. (Predictive)
3. (Predictive)
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
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
Table 3 GPRS Reliability classes
Reliability
Class
Lost SDU
Probability
-9
Duplicate
SDU
Probability
-9
Out of
Sequence
SDU
Probability
10
-9
Corrupt
SDU
Probability
10
-9
1.
10
10
2.
10-4
10-5
10-5
10-6
3.
10-2
10-5
10-5
10-2
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
•
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:
•
24
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.
•
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 MS’s 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
Monthly charge (SEK/month)
GPRS Surf
Data GPRS
368,75
25
Claes Rosenberg
Traffic fee
(SEK/MB)
25
175
25
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
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)
HLR
VLR
MS
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
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
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.
Sending
Entity
Security
Security
Sending
Application
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 Entity’s 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
Sending Entity and is sent by the Receiving Entity as an acknowledgement
upon successful reception of a Security Packet.
•
30
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.
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
Wireless
Internet
Gateway
Alarm
Manager
Service
And
Device
Management
SIM &
Services
DB
Administrator
Configuration
Manager
Order
Manager
Service
Assistant
Messaging
SFM WSM
A
P
I
Flow
Control
WIG
Web Ass.
STM
O&M
Transport Server
Charging
Alarms
SMS
GPRS
Customer
Application
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
SmartTrust DP5
Service and Device Management
SFM
Server
Service
Assistant
WSM
Server
Order
Manager
Web
Assistant
O&M
SmartTrust DP5 Core
WIG
WIG
Server
Messaging
Administrator
Charging
Server
Alarm
Manager
A&C
Server
Transport
Server
Database
Configuration
Manager
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
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 subscriber’s 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
End User
Content Provider
HTTP, HTML
Standard
Web Browser
Web
Server
Buisness
Logic
HTTP, HTTPS,
HTML or WML
Mobile
Station
Operator
Request
WIB
Push
GSM 03.48
WIG Server
DP5
Figure 12 DP5 WIB and WIG
34
•
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 handset’s 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
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
PLMN
(SMS-C)
Transport Server
API
Messaging
WIG Server
Internet
Non-Wap
Phone with
WIB
Wap
Capable
Phone
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
Transport Server
API
PLMN
(SMS-C)
API
DP5 Core
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
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.
IP/X.25
TS
INV.
TS
API
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
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
IP/X.25
SMSC
GSM
GSM
ME
SIM
API
API
API
Application
Application
Figure 16 DP5 Transport environment using SMS
TS
IP/X.25
GPRS
GPRS
ME
SIM
API
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
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-C’s 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
Islandssimi’s 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
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
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
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
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
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].
IP/X.25
TS
GPRS
GPRS
ME
SIM
API
Laptop
AT
API
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
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
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
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
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
MSC
SMS-C
Internet
Internet
ME
SIM
IP
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
Config.param.
Config.param.
•AckDelay
•ProofofReceiptDelay
•ResultInAck
•ResponseCodeProofofReceipt
HLR
SIM
SMS-C
TransportServer
Simulator
IP
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
Config.param.
Config.param.
•SendAcknowledgement
•OpenDelay
•ReceptionAcknowledgement
•RecAckDelay
SIM
MS
TransportServer
Simulator
IP
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
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 Sonera’s 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
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 don’t 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
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 SmartTrust’s
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 Server’s 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
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 SmartTrust’s products, since it is up to the SMS-C to
make the decision on whether to use GPRS or not. However, when SmartTrust’s
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 SmartTrust’s 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
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
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
SmartTrust’s 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
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
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 Thümmler, 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.
Security Mechanisms for the SIM application toolkit; Stage 2, version 8.5.0,
ETSI 2001.
General Packet Radio Service (GPRS); Service Description; Stage 2, version
7.6.0, ETSI 2001.
General Packet Radio Service (GPRS); Overall description of the GPRS radio
interface; Stage 2, version 8.8.0, ETSI 2001.
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
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.
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.
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,
26. Comviq, Comviq, http://www.comviq.se
27. GSM – Association Network Statistics, GSM World
http://www.gsmworld.com/membership/ass_net_stats.html,
28. GSM - Association Subscriber Forecast, GSM World
http://www.gsmworld.com/membership/ass_sub_fore.html,
29. Islandssimi, www.islandssimi.com
Claes Rosenberg
59
30. Nokia on the web, Nokia, http://www.nokia.com/main.html
31. Telia.se: Telia.se, Telia, http://www.telia.se,
32. www.europolitan.se, Europolitan, http://www.europolitan.se/001.euro,
Personal communications
33. Comviq customer service, Josefin Lindh, Personal communication.
Mail received 2001-11-09.
34. Europolitan Vodafone Internet support, Personal communication.
35. MAGNET Center Developer Support, Motorola Applications Global Network,
Personal communication.
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.
60
Appendix A
Abbreviations
nd
2G
2.5G
3G
3GPP
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
API
APN
ARQ
AuC
Access Point Identifier alt. Application Programming Interface
Access Point Name
Automatic ReQuest for retransmission
Authentication Centre
BCCH
bps
BS
BSC
BSS
BSSGP
BTS
Broadcast Control Channel
bit per second
Billing System
Base Station Controller
Base Station System
BSS GPRS Protocol
Base Transceiver Station
CCCH
CCU
CGF
CM
GSM Common Control Channels
Channel Coding Unit
Charging Gateway Functionality
Configuration Manager
DHCP
DLL
DNS
DP5
Dynamic Host Configuration Protocol
Dynamic Link Layer (In transmission plane)
Domain Name System
SmartTrust Delivery Platform generation 5
EDGE
EIR
EMS
eSMS
ETSI
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
FDMA
Frequency Division Multiple Access
GGSN
GMSC
GSM
GPRS
GTP
Gateway GPRS Support Node
Gateway Mobile Switching Centre
Global System for Mobile communications
General Packet Radio Service
GPRS Tunnelling Protocol
HDLC
HLR
HTTP
High-level Data Link Control
Home Location Register
Hyper Text Transfer Protocol
IMEI
IMSI
IPv4
IPv6
ISDN
IWF
International Mobile station Equipment Identifier
International Mobile Subscriber Identity
Internet Protocol version 4
Internet Protocol version 6
Integrated Services Digital Network
InterWorking Functions
Claes Rosenberg
61
Kbps
kilobits per second
LA
LAI
LLC
Location Area
Location Area Identity
Logical Link Control (layer)
MAC
MB
MCC
MM
MMI
MMS
MNC
MO
MS
MSC
MSISDN
MSRN
MT
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)
NAT
NS
NSAPI
Network Address Translation (RFC 1631)
Network Service
Network layer Service Access Point Identifier
O&M
OTA
Operations & Maintenance
Over The Air
PACCH
PAD
PAGCH
PBCCH
PCCCH
PCU
PDA
PDCCH
PDCH
PDN
PDP
PDU
PLL
PLMN
PPCH
PPP
PRACH
PSDN
PSTN
PSPDN
PTCCH
P-TMSI
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
QoS
Quality of Service
RA
RAC
Routeing Area
Routeing Area Code
62
RFC
RFU
RLC
Request For Comments
Reserved for Future Use
Radio Link Control (layer)
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
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
TCP
TDMA
TE
TID
TLLI
TLV
TMSI
TP
TS
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
UDP
UMTS
URL
User Datagram Protocol
Universal Mobile Telecommunications System
Uniform Resource Locator
VLR
Visiting Location Register
WADP
WAP
WIB
WIG
WML
Wireless Application Delivery Platform
Wireless Application Protocol
Wireless Internet Browser
Wireless Internet Gateway
Wireless Markup Language
Claes Rosenberg
63
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
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
Field
description
Proactive SIM
Command Tag
Length
Command
details
Device Identities
Mandatory
Length
(byte)
Yes
1
’D0’
Yes
Yes
1
5
Yes
4
’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)
5
6
7
Alpha Identifier
Icon Identifier
Bearer
description
No
No
Yes
--B (11)
8
9
Buffer size
Access Point
Name
Other Address
Yes
No
4
2
No
3
No
5
No
7
10
11
12
SIM/ME
interface
transport level
Data Destination
Address
Value
’3E0021’ (dynamically allocate an
IPv4 address)
’3C03021E61’ (TCP protocol and
port number 7777)
’3E0521 CA01CF02’
(Ipv4 address 172.16.252.32)
Put together the total command looks like this in hexadecimal code:
D029 0103014010 02028182 3509020104030431020000 39020400 3100 3E0021
3C03021E61 3E0521CA01CF02
Claes Rosenberg
65
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
4
Field
description
Proactive SIM
Command Tag
Length
Command
details
Device Identities
5
Event list
2
3
Mandatory
Length
(byte)
Value
Yes
1
’D0’
Yes
Yes
1
5
’0C’ (12 in decimal)
’0103 010500’
Yes
4
Yes
3
’0202 8182’ (SIM is source and ME
is destination)
’1901 09’ (Data availble event)
Put together the total command looks like this in hexadecimal code:
D00C 0103010500 02028182 190109
66

”How to use GPRS as bearer for Claes Rosenberg

Transcription

Similar documents

Dejavoo Systems 1129 Northern Blvd Suite 303

Configuring the Device

GR64 GSM/GPRS Radio Device

Stencil and Howto for Micro SIM Cutting

GTX Prime One

GR64 GSM/GPRS Radio Device

in withSIM - Senior Insurance Marketing

How to register and set up the Orange GPS-Trace account

Technical specifications Omnicomm Profi Omnicomm Optim

George Middle School / Homepage