Mobile Instant Messaging Systems - A Comparative Study and ... · Detta arbete unders¨oker hur v...

HELSINKI UNIVERSITY OF TECHNOLOGYDepartment of Computer Science and EngineeringTelecommunications Software and Multimedia Laboratory

Peter Salin

Mobile Instant Messaging Systems -

A Comparative Study and Implementation

Master’s Thesis submitted in partial fulfillment of the requirements for the degree ofMaster of Science in Technology.

Espoo, September 21, 2004

Supervisor: Professor Antti Yla-Jaaski

Instructor: Juhani Malka, M.Sc.

HELSINKI UNIVERSITY ABSTRACT OF THEOF TECHNOLOGY MASTER’S THESIS

Author: Peter SalinName of the thesis: Mobile Instant Messaging Systems -

A Comparative Study and ImplementationDate: September 21, 2004 Number of pages: 75 + 5Department: Department of Computer Professorship: T-110

Science and EngineeringSupervisor: Prof. Antti Yla-JaaskiInstructor: Juhani Malka, M.Sc.

Ever since their introduction less than a decade ago, modern instant messaging systemshave experienced a massive growth in users. Meanwhile, text messaging has revolu-tionized the use of the mobile phone, bringing mobile messaging forward as a newsource of revenue for service providers. Now service providers look to enrich mobilemessaging by bringing the combination of presence awareness and real-time messaging,that is instant messaging, to the mobile environment. However, several restrictions areinflicted on mobile services due to the differences of mobile and wireline environments.The instant messaging standards destined for mobile networks must be able to adaptto these restrictions.

IMPS (Instant Messaging and Presence Service) is an instant messaging system de-signed especially for mobile environments. Another instant messaging system, the SIP(Session Initiation Protocol) based SIMPLE (SIP for Instant Messaging and PresenceLeveraging Extensions) service, will be introduced in forthcoming third generation (3G)networks as part of the 3G multimedia services.

This thesis evaluates the applicability of IMPS and SIMPLE in mobile networks andpresents the strengths and weaknesses of the standards in comparison to each other.

The architecture of IMPS was found to be quite simple while SIMPLE is based on amore complex structure utilizing several different protocols and data formats. Despitetheir differences, both architectures are very scalable. The comparison also found thesecurity services of SIMPLE to be better than those of IMPS. However, SIMPLE hasproblems with proxy traversal while IMPS is able to traverse proxies without problems.The performance of SIMPLE was considered slightly better than IMPS’s when it comesto bandwidth usage and delays, although the performance of IMPS is more than ade-quate for mobile environments as well. The level of extensibility and interoperabilityis equally high for both IMPS and SIMPLE.

In conclusion, IMPS is easy to deploy due to its simple architecture, while considerableeffort and resources are required to deploy the more complex SIMPLE service. On theother hand, SIMPLE enables a range of other multimedia services to be launched basedon the same framework. As SIMPLE offers stronger security services, it is a betteralternative for transporting business-critical information. In contrast, IMPS enablesthe creation of a global instant messaging service spanning both mobile networks andthe wireline Internet, while SIMPLE is unable to accomplish the same due to proxytraversal problems. All in all, both services conform well to the requirements of mobilenetworks.Keywords: mobile instant messaging, instant messaging, presence awareness, IMPS,SIMPLE

ii

TEKNISKA HOGSKOLAN SAMMANDRAG AV DIPLOMARBETE

Forfattare: Peter SalinTitel: System for mobila direktmeddelanden -

En jamforande studie och implementationDatum: 21.09.2004 Antal sidor: 75 + 5Avdelning: Avdelningen for datateknik Professur: T-110Overvakare: Prof. Antti Yla-JaaskiHandledare: DI Juhani Malka

Moderna system for direktmeddelande har anda sedan introduktionen for mindre antio ar sedan erfarit en massiv okning i antalet anvandare. Under tiden har textmed-delanden (SMS) revolutionerat sattet pa vilket mobiltelefoner anvands, vilket har fortfram mobila meddelanden som en ny inkomstkalla for tjanstleverantorer. Nu stravarleverantorer av mobila tjanster till att berika utbudet av tjanster genom att lanseradirektmeddelande i en mobil omgivning. Mobila och stationara omgivningar skiljer sigemellertid avsevart ifran varandra. Detta medfor en hel del begransningar, till vilka enstandard for mobila direktmeddelanden maste klara av att anpassa sig.

IMPS (Instant Messaging and Presence System) ar ett system for direktmeddelandekonstruerat speciellt for att anvandas i en mobil omgivning. Ett annat system fordirektmeddelande, det SIP (Session Initiation Protocol) baserade SIMPLE (SIP forInstant Messaging and Presence Leveraging Extensions), kommer att lanseras som enmultimediatjanst i kommande tredje generationens (3G) natverk.

Detta arbete undersoker hur val IMPS och SIMPLE tillampar sig for anvandning imobila natverk samt beskriver standardernas styrkor och svagheter i jamforelse medvarandra.

Arkitekturen hos IMPS visade sig vara relativt simpel, medan SIMPLE har en merakomplex struktur och anvander sig flera olika protokoll och data format. Trots skill-naderna, ar skalbarheten hos bada arkitekturerna utmarkt. Jamforelsen visade ocksaatt SIMPLE erbjuder battre sakerhetstjanster an IMPS. Daremot har SIMPLE prob-lem med proxyservrar medan IMPS-trafik kan genomkorsa proxyservrar utan problem.Prestationsformagan hos SIMPLE betraktades vara nagot battre an IMPS’ nar detgaller forbrukning av bandbredd och fordrojningar, aven om prestationen hos IMPSocksa visade sig vara mer an tillracklig for mobila omgivningar. Nar det galler flexi-bilitet och interoperabilitet ligger bagge standarder pa lika hog niva.

Som slutsats: IMPS ar enklare att ta i bruk tack vare dess simplare arkitektur medan enlansering av SIMPLE kraver storre anstrangingar och resurser. A andra sidan mojliggorramverket pa vilket SIMPLE ar baserat lanseringen av en lang rad andra multimedi-atjanster. Eftersom SIMPLE erbjuder starkare sakerhetstjanster, ar den battre lampadfor transportering av business-kritisk information. I motsats mojliggor IMPS skapandetav en global tjanst for direktmeddelande innehallande bade mobila natverk och Inter-net, medan SIMPLE inte formar detsamma p.g.a. problem med proxyservrar. Allt somallt anpassar sig bagge tjanster val till mobila omgivningar.

Nyckelord: mobilt direktmeddelande, direktmeddelande, narvaro, IMPS, SIMPLE

iii

Acknowledgements

This Master’s thesis has been done for Celtius Ltd.

I want to thank the management of Celtius Ltd. for giving me the opportunity to writethis thesis for their company.

I wish to thank my instructor Juhani Malka for his valuable input and guidance duringthe entire work process.

I would also like to thank my supervisor, Professor Antti Yla-Jaaski, for his helpful com-ments and advice regarding the thesis.

My gratitude also goes to all those who read and commented the final draft version of thisthesis.

Finally, I would like to thank my family for their support throughout my entire studies.

Espoo, September 21, 2004

Peter Salin

iv

Contents

Abbreviations viii

1 Introduction 1

1.1 Objectives and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Internet Instant Messaging 3

2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.1 Concepts and Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.2 Differences from Other Communication Systems . . . . . . . . . . . 8

2.4 Proprietary Instant Messaging Systems . . . . . . . . . . . . . . . . . . . . . 10

2.4.1 ICQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4.2 AOL Instant Messenger . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.3 Yahoo Messenger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.4 MSN Messenger/Windows Messenger . . . . . . . . . . . . . . . . . 11

2.5 Standards and Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5.1 IMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5.2 SIMPLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5.3 XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.6.1 Server Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.6.2 Message Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.7 Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.8 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.8.1 Types of Security Threats . . . . . . . . . . . . . . . . . . . . . . . . 17

v

3 Mobile Instant Messaging 20

3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Differences in Comparison to Instant Messaging in Fixed Networks . . . . . 22

3.3.1 Device Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3.2 Network Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3.3 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.4 Other . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4 Standards and Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4.1 xMS (SMS, EMS, MMS) . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4.2 IMPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4 Comparison of IMPS and SIMPLE 32

4.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2 Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.2 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3.1 Bandwidth Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3.2 Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.3.3 Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3.4 Coverage Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3.5 Proxy Traversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3.6 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.4.1 Security Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.4.2 Attack Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.5 Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.6 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.7 Current Status and Future Trends . . . . . . . . . . . . . . . . . . . . . . . 52

4.7.1 Industry Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.7.2 Service Maturity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.7.3 Future Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

vi

5 Implementation of IMPS CSP Protocol 55

5.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.1.1 Overall Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.1.2 CSP Protocol Requirements . . . . . . . . . . . . . . . . . . . . . . . 57

5.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2.1 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.2 CSP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.3 CSP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.3.1 Programming Language . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3.2 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3.3 Software Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.3.4 Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.3.5 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6 Discussion and Conclusions 65

6.1 Comparison of IMPS and SIMPLE . . . . . . . . . . . . . . . . . . . . . . . 65

6.2 Implementation of IMPS CSP protocol . . . . . . . . . . . . . . . . . . . . . 66

6.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.4 Significance of the Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.5 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Bibliography 70

A Message Flow Examples 76

vii

Abbreviations

3GPP Third Generation Partnership Project

APEX Application Exchange

CIR Connection Initiation Request

CLP Command Line Protocol

CPIM Common Profile for Instant Messaging

CPP Common Profile for Presence

CSP Client-Server Protocol

DOM Document Object Model

DTD Document Type Definition

EMS Enhanced Messaging Service

GIF Graphics Interchange Format

GLMS Group and List Management Server

GPRS General Packet Radio Service

GSM Global System for Mobile communications

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol (Secure)

IEC International Engineering Consortium

IETF Internet Engineering Task Force

IM Instant Messaging

IMAP Internet Message Access Protocol

IMPP Instant Messaging and Presence Protocol

viii

IMPS Instant Messaging and Presence Service

IMS IP Multimedia Subsystem

IP Internet Protocol

IRC Internet Relay Chat

JPEG Joint Photographic Experts Group

MD5 Message Digest Algorithm #5

MIDI Musical Instrument Digital Interface

MIME Multipurpose Internet Mail Extensions

MMS Multimedia Messaging Service

MPEG Moving Pictures Experts Group

MSRP Message Session Relay Protocol

OMA Open Mobile Alliance

PIDF Presence Information Data Format

POP Post Office Protocol

PRIM Presence and Instant Messaging Protocol

RFC Request For Comments

RTT Round-Trip Time

SAP Service Access Point

SAX Simple API for XML

SHA Secure Hash Algorithm

SIMPLE SIP for Instant Messaging and Presence Leveraging Extensions

SIP Session Initiation Protocol

SIPPING Session Initiation Protocol Project Investigation

SMCNP Server Mobile Core Network Protocol

SMIL Synchronized Multimedia Integration Language

S/MIME Secure MIME

SMS Short Message Service

ix

SSP Server-Server Protocol

TCP Transmission Control Protocol

TLS Transport Layer Security

UDP User Datagram Protocol

UML Unified Modeling Language

UMTS Universal Mobile Telecommunications System

URI Uniform Resource Identifier

VoIP Voice over IP

WAP Wireless Application Protocol

WBXML Wireless Binary XML

WLAN Wireless Local Area Network

WSP Wireless Session Protocol

XCAP XML Configuration Access Protocol

XML Extensible Markup Language

XMPP Extensible Messaging and Presence Protocol

x

Chapter 1

Introduction

Picture yourself in a situation where you realize that you have an hour of free time tospend. You decide to gather a group of friends to meet for a cup of coffee. Using yourmobile phone you are able to see which of your friends currently are available and possiblyeven where they are located and what mood they are in. Quickly you have gathered alist of people, potentially willing to keep you company. Next you send an instant messageto the whole group, inviting them to join you. As all responses are sent to the group,negotiating the time and place to meet is efficient and easy. Before you know it, you areall at the cafeteria having your cup of coffee.

The above example illustrates one application of mobile instant messaging. As neitherpresence information nor group instant messaging are available in current mobile networks,the above situation would require numerous phone calls or text messages, consuming mostof the time available.

The combination of presence awareness and real-time messaging offered by instant mes-saging systems has proved to be the source of a killer application in the Internet, gatheringhundreds of millions of users. Although originally considered a teenager toy, the benefitsof instant messaging have been realized by both academic and corporate organizations inthe last few years.

Concurrently with the instant messaging revolution of the Internet, the introduction oftext messaging has launched a similar phenomenon in mobile networks. Over time, mobilemessaging has proved one of the most important sources of revenue for providers of mobileservices and new messaging services, such as multimedia messaging and mobile email, havebeen introduced in recent years.

Now, instant messaging is about to make the transition from the wireline Internet to mobilenetworks. This thesis studies the requirements placed upon instant messaging systems bymobile environments and evaluates the applicability of two instant messaging systems setfor introduction in mobile networks in the future.

1

CHAPTER 1. INTRODUCTION 2

1.1 Objectives and Scope

The objectives of this thesis are:

� To identify requirements and limitations related to mobile instant messaging

� To compare IMPS and SIMPLE emphasizing the requirements of mobility

� To design and implement the client and the server end of the IMPS CSP protocol

In order to be able to evaluate the applicability of instant messaging systems to mobileenvironments, the restrictions of mobile networks that affect such a system must be iden-tified. Earlier work in this area has been performed by Parvianen et al. [48], Vogiazou[68] and Leggio et al. [37].

IMPS (Instant Messaging and Presence Service) and SIMPLE (SIP for Instant Messagingand Presence Leveraging Extensions) are two instant messaging systems, both more thanlikely to be deployed in mobile networks in forthcoming years. The main objective of thisthesis is to uncover the strengths and weaknesses of these services and to evaluate howwell they conform to the requirements of mobile environments. This kind of study has notbeen performed earlier, but Leggio et al. [37] have evaluated the performance of XMPP(Extensible Messaging and Presence Protocol) in mobile networks while Greene et al. [27],Mituoka et al. [40] and Parvianen et al. [48] have proposed their own instant messagingsolutions for mobile environments.

Finally, the design and implementation of the Client-Server Protocol (CSP) of IMPS isone goal of this thesis. The CSP protocol provides clients of the IMPS instant messagingservice with access to the IMPS server and the functionality provided by the IMPS service.In essence, CSP enables a user to interact with all other users connected to the same IMPSservice.

The scope of this thesis is limited to exploring instant messaging standards in general;evaluating single products or implementations of the standards is not inside the scope ofthe thesis.

1.2 Structure

Chapter 2 introduces the concept of instant messaging and presents the solutions currentlyused in Internet instant messaging. Chapter 3 describes the services used to enable mobilemessaging and studies the restrictions that mobile environments inflict on mobile instantmessaging services. Two mobile instant messaging candidates, IMPS and SIMPLE, arecompared in Chapter 4. Chapter 5 presents the design and implementation of the CSPprotocol of IMPS. Finally, Chapter 6 discusses the findings of the thesis and presents theconclusions that can be drawn from them.

Chapter 2

Internet Instant Messaging

Instant messaging services have enjoyed a constant growth ever since their introduction.Real-time messages and presence information are the pieces of technology that makesinstant messaging different from previous communication services. However, the successof instant messaging is not based on technical differences only; also the methods andconcepts used in instant messaging clients, such as popup windows and buddy lists, havecontributed to the birth of a completely new type of communication. Although firstconsidered a toy for teenagers, the value of instant messaging to enterprises, e.g. in formof cost savings and increase in efficiency, has been recognized in recent years.

This chapter introduces the concept of instant messaging as well as the solutions availablefor enabling Internet instant messaging. Section 2.1 defines the term ’instant messaging’.Section 2.2 presents the history of instant messaging in the Internet. In Section 2.3, anoverview of the concepts and model of instant messaging is given. Section 2.4 describesthe proprietary solutions for instant messaging while Section 2.5 presents standardizedsolutions. The architectural choices used in instant messaging systems are explained inSection 2.6. Section 2.7 describes the interoperability problem of Internet instant messag-ing. Finally, in Section 2.8 the security features of Internet instant messaging systems arediscussed.

2.1 Definition

Several different interpretations of the term ’instant messaging’ exist. This section clarifiesthe meaning of the term within this thesis.

IEC (International Engineering Consortium) provides the following definition: ”Instantmessaging (IM) is an Internet protocol (IP)–based application that provides convenientcommunication between people using a variety of different device types” [18].

Campbell et al. [14] defines instant messaging as ”the exchange of content between a set

3

CHAPTER 2. INTERNET INSTANT MESSAGING 4

of participants in near real time”.

Webopedia.com [69] states that instant messaging is ”a type of communications servicethat enables you to create a kind of private chat room with another individual in orderto communicate in real time over the Internet, analogous to a telephone conversationbut using text-based, not voice-based, communication. Typically, the instant messagingsystem alerts you whenever somebody on your private list is online”.

According to another online IT-specific encyclopedia, Whatis.com [70], instant messagingis ”the ability to easily see whether a chosen friend or co-worker is connected to the Internetand, if they are, to exchange messages with them”.

Finally, Kohda et al. [35] refers to instant messaging as ”buddy list applications, whichconsist of two orthogonal services, presence and short messaging”.

The IEC definition is rather vague and applies to almost all types of messaging. Campbellet al. recognizes the fact that instant messages are delivered to the recipient in real time.The remaining definitions all include presence as a part of instant messaging, thus exposingthe dual nature of the term. Instant messaging is often perceived as a service consistingof both presence and sending of instant messages. However, the term instant messaging isfrequently used also when referring to the sending of instant messages. In this thesis theformer definition will mainly be used. If the term ”instant messaging” is referring to thesending of instant messages it will be made clear by context.

Definition 1 Instant messaging is a type of communication service providing users withtwo elements; presence information and real-time messaging.

As it is an essential part of instant messaging it is necessary to provide a definition forpresence as well.

Webopedia.com [69] defines presence as ”the ability to detect whether other users areonline and whether they are available”.

Day et al. [19] provides the following definition: ”Presence is a means for finding, retriev-ing, and subscribing to changes in the presence information (e.g. ”online” or ”offline”) ofother users”.

For the purposes of this thesis, the latter definition is suitable. It should be stressed thatpresence information is not restricted to online status only, other attributes such as mood,location and language might just as well be included. Also note that instant messaging ismerely one application of presence; other technologies, e.g. VoIP (Voice over IP), providepresence services as well.

Definition 2 Presence is a means for finding, retrieving, and subscribing to changes inthe presence information of other users.


2.2 History

The Unix ’talk’ tool, released in the mid 1980’s, was one of the first applications to providereal-time messaging. ’Talk’ did not provide presence information, but combined with e.g.the Unix ’finger’ command, the elements of instant messaging were in place. ’Zephyr’, anotification service released for Unix in 1987, combined real-time messaging and onlinestatus information, but it was originally intended for sending short notifications to usersand not for session-like communication.

In 1988, Internet Relay Chat (IRC) was introduced. IRC provides both real-time mes-saging and online status information; therefore it can be classified as instant messaging.Private messaging between two users is the most frequently used type of communicationfor instant messaging applications. IRC differs from this as it is designed and mainly usedfor group chat, i.e. users join together at a channel (or chat room) where the ongoingdiscussion is seen by all joined users.

Instant messaging as we know it today was born in 1996, when Mirabilis, a small Israelistart-up company, launched ICQ (I Seek You). ICQ included features such as buddy lists,presence subscriptions/notifications and, of course, sending of instant messages. Whereasall the previously mentioned solutions were text-based, the ICQ client came with graphicaluser interface making it very easy to use. The freely distributed ICQ rapidly gainedpopularity, reaching 850 000 registered users in within six months of its release. As theamount of users connected to the Internet kept soaring, so did the popularity of ICQ.

Although ICQ was free, the major players in the Internet business recognized the value ofsuch a vast user base. In May 1997 AOL (America Online) released their instant messagingsoftware, the AOL Instant Messenger. One year later, in June 1998, AOL acquired themajority of instant messaging users when it bought Mirabilis and ICQ. Microsoft andYahoo were not going to let AOL go unchallenged as they released their own solutions,MSN Messenger and Yahoo Messenger.

All of these new applications became very popular, having a considerable amount of regis-tered users. Unfortunately there was a slight problem; all solutions were based on propri-etary protocols, meaning that a user of one IM system could not exchange messages witha user of another IM system. The problem was addressed by the Internet EngineeringTask Force (IETF), which in 1999 formed the Instant Messaging and Presence Protocol(IMPP) working group. The group was to specify requirements and framework for instantmessaging, and eventually produce a standard instant messaging protocol.

The IMPP working group had severe difficulties in deciding on an instant messagingprotocol. Therefore it was decided to let the market decide and three new work groupswere formed, each creating their own protocol: Application Exchange (APEX, formerlyIMXP), Presence and Instant Messaging Protocol (PRIM) and SIP for Instant Messagingand Presence Leveraging Extensions (SIMPLE). The IMPP working group would define a


model and common formats for instant messaging, thus ensuring interoperability betweenthe protocols.

SIMPLE proved to be the strongest of the three candidates; PRIM was discontinuedquite early and APEX, although a finalized standard, has generated only limited interest.In 2002, a new challenger joined the race as IETF approved a working group for theExtensible Messaging and Presence Protocol (XMPP). Since then SIMPLE and XMPPhave been battling it out, along with IMPS (Instant Messaging and Presence Services),a solution mainly targeted at mobile environments but perfectly applicable elsewhere aswell (see Section 3.4.2).

Figure 2.1 displays the growth of users of instant messaging along with the timeline ofinstant messaging.

Figure 2.1: The history and user growth of instant messaging. Source: IDC

2.3 Overview

2.3.1 Concepts and Model

RFC (Request For Comment) 2778 [20], produced by the IETF IMPP working group,defines a common vocabulary and presents an abstract model for instant messaging. Thismodel is used as such by all current solutions, both proprietary and open standards.


Presence Service

Figure 2.2 displays an overview of a presence service. A presence service has two distincttypes of clients: ’presentities’ and ’watchers’. Presentities provide presence information tothe presence service, while watchers request presence information about presentities fromthe presence service. Naturally, the same application can act both as a presentity and asa watcher.

Figure 2.2: Overview of a presence service

The watchers are classified as well; there are ’subscribers’, ’fetchers’ and ’pollers’ (seeFigure 2.3). A subscriber is a watcher that has subscribed to the presence information ofa presentity. The presence service keeps track of the subscriptions and sends a notificationto the subscriber whenever the presence information of the subscribed presentity changes.A fetcher requests the presence service for presence information about a presentity. Thepresence service does not send notifications to fetchers, presence information is only sentupon the request of the fetcher. A poller is a special kind of a fetcher that polls thepresence service for presence information about a presentity on a regular basis.

Figure 2.3: Different kinds of watchers

Instant Message Service

Equally to the presence service, the instant message service also has two kinds of clients:’senders’ and ’instant inboxes’ (see Figure 2.4). Senders are the source of instant messages


to be delivered by the instant message service. An instant inbox is a container for instantmessages that are to be read by the owner of the inbox. The instant message serviceaccepts instant messages from senders and attempts to deliver them to the instant inboxes,to which they are addressed. Typically, the instant inbox resides in the client application,although it is not required by the IMPP definition.

Figure 2.4: Overview of an instant message service

2.3.2 Differences from Other Communication Systems

Model

Presence, as such, is clearly not part of any major established communication systems oftoday, but also the method for delivering messages differs considerably from the methodscurrently used.

Most of the currently used messaging systems are based on a paradigm called ’store-and-forward’. When sending a message over a network using this paradigm, each messagetransfer agent stores and forwards the message to the next agent. In case the next agentcannot be reached, delivery can be reattempted later on. The store of the message transferagent closest to the user agent of the recipient usually serves as an inbox to the user agent.The user agent fetches the messages from the inbox when it is online. Even though it ispossible for messages to arrive real-time, ’store-and-forward’ is viewed as non-real-timedelivery system since all delivered messages do not arrive in real-time. Examples of mes-saging systems using ’store-and-forward’ include traditional email, SMS (Short MessageService) and MMS (Multimedia Messaging Service).

For instant messaging systems, intermediate elements along the path from the sender tothe recipient merely relay the instant message to the next element without storing it. Ifthe recipient cannot be reached, e.g. when the user is not online, then the instant messageis normally discarded. Some instant messaging systems provide storage for messages sentto offline users, but this is a distinct service and not part of instant messaging as such.

Sending instant messages from peer to peer is also possible using a few instant messaging


systems (e.g. ICQ and SIMPLE). These systems provide the sender with the address of therecipient, using which the instant messages can be sent directly to the recipient withoutany server intervention.

Usage

Voice calls and email are by far the two most popular communication systems of today [8].Table 2.1 shows some usage related properties of instant messaging compared with the cor-responding properties of voice calls and email. Instant messaging can be seen as some kindof combination of features from voice calls and email. Like voice calls instant messagingprovides real-time communication but at a price comparable to email. Of course, instantmessaging is not free; deploying an instant messaging solution in an enterprise requires no-ticeable investments. However, after deployment the cost of usage is significantly lower forinstant messaging than for voice calls, especially for international communication. Whenit comes to archiving, email systems provide the most sophisticated solutions. Presenceinformation is one of the greatest benefits for users of instant messaging. Surveys showthat 40-60% of business related phone calls fail due to the callee being busy or absent[67]. Presence information practically eliminates this phenomena for instant messaging,assuming that users keep their presence information up-to-date.

Table 2.1: Comparison of popular messaging systemsMessagingSystem

Real-time Cost Presence Archiving

Voice call Yes High Partly, the call is eitherestablished or not

No

Email No Low No, the sender does notknow whether the recip-ient is available or not.

Yes

InstantMessaging

Yes Low Yes, the status of the re-cipient is known by thesystem at all times.

Depends on the IM client.Must often be done explic-itly by the user.

Table 2.2 shows how initiating a business related line of communication using differentmessaging systems affects the productivity of parties involved. Voice calls often interruptthe work of the callee, and on the contrary, emailing is more prone to suspend caller’swork for a while. Instant messaging is more like voice calls in this aspect, but presenceinformation provides a means to prevent unnecessary interruptions. Instant messaging canalso reduce productivity if not deployed carefully within an organization. Gossiping andconstant interruptions are some aspects that can decrease productivity. The productivityaspect of instant messaging is discussed in more detail in [44] and [64].

The comparisons of Tables 2.1 and 2.2 reveal that instant messaging have both strongand weak points in comparison with current communication systems. There clearly exists


Table 2.2: The influence of messaging systems on productivityMessagingSystem

Caller Callee

Voice call Generally no decrease in productivity. Ifthe callee is reached, a direct answer canbe received.

Often decreases productivity as the inter-rupted callee must drop its current work inorder to answer the call.

Email Decrease in productivity while waiting fora reply.

Affects productivity only slightly since thecallee can choose when to answer theemail.

InstantMessaging

Typically no productivity reduction. Thepresence service allows the caller to selectcurrently available callee.

Reduces productivity upon message recep-tion, but the callee can use the presenceservice to control the arrival of messages.

a niche for instant messaging as it is more suitable for particular tasks than the currentsystems. However, instant messaging will not eliminate any of the current systems. Userswill choose which system to use based on the type of communication. Instant messag-ing is suitable for quick real-time conversations, email is convenient for errands that donot require an immediate response and voice calls are often preferred for e.g. businessnegotiations as the risk of misunderstandings is reduced.

2.4 Proprietary Instant Messaging Systems

The instant messaging market is currently dominated by three big companies, AOL, Yahooand Microsoft. These companies all offer their own proprietary solutions based on privateprotocols that are not interoperable. From the viewpoint of instant messaging, there areno fundamental differences between the solutions. Instead, the solutions try to attractusers by incorporating non-instant messaging features such as weather reports or onlinegames. The rest of this section describes these instant messaging systems in brief.

2.4.1 ICQ

ICQ (short for I Seek You), created in 1996 by a small Israeli start-up company calledMirabilis, is considered the ancestor of instant messaging systems. ICQ introduced con-cepts like buddy lists, presence subscriptions and block lists, which form the basis for everyinstant messaging system of today. Internet growth was exponential at the time and ICQquickly gathered a large user base. When Mirabilis was bought for $287 by AOL in 1998,ICQ had already gathered 12 million users. Currently ICQ has 180 million registeredusers, of which approximately 68 millions are active users. The majority of the user baseis located in Asia and Europe, while the amount of users in the U.S. is relatively small.

Table 2.3 presents the amount of active users per instant messaging system. The numbersare based on a research performed by the Radicati Group in October 2003.


Table 2.3: Active users per proprietary instant messaging systemMessaging System Active Users

AIM 100 million

ICQ 68 million

MSN 66 million

Yahoo 36 million

2.4.2 AOL Instant Messenger

In the early 1990’s America Online (AOL) had a significant amount of users subscribingto their online services, which included communication through electronic bulletin boards.In May 1997 AOL released the AOL Instant Messenger (AIM) to provide these users withthe means to communicate with the outside world and vice versa. AIM quickly gainedpopularity especially in the U.S., home of AOL, and was starting to catch up with ICQ.The competition between ICQ and AIM came to an end in 1998, when AOL bought thecompany behind ICQ, cornering about 90% of the market. The amount of users has notdecreased since then, but the introduction of several competing systems has reduced themarket share. Presently, AIM is used by roughly 100 million people.

2.4.3 Yahoo Messenger

Yahoo joined the instant messaging race in June 1999 with the release of the YahooMessenger. Starting with no user base, but with a brand well-known to many users of theInternet, Yahoo currently has a user base of around 36 million for their instant messagingservices.

2.4.4 MSN Messenger/Windows Messenger

Microsoft published their instant messaging solution, the MSN Messenger, in July 1999.Similarly to Yahoo, Microsoft started out with a non-existent user base but coupling theMessenger with e.g. Hotmail and Windows has enabled Microsoft to build a large userbase rapidly.

As of now Microsoft has two different instant messaging clients. In addition to the previ-ously mentioned MSN Messenger, the Windows Messenger was released for Windows XPin 2001. In comparison to the MSN Messenger, the Windows Messenger is more businessfocused and includes support for e.g. SIMPLE and the Exchange IM Server. The twoclients are interoperable as both use the same instant messaging network.

All in all, Microsoft’s instant messaging system currently serves about 66 million users.


2.5 Standards and Protocols

Ever since it became evident that users of the proprietary solutions would not be able tocommunicate with each other, IETF has been striving to produce a standardized solutionfor instant messaging. This section presents the results of the standardization efforts.

2.5.1 IMPP

IETF originally chartered IMPP (Instant Messaging and Presence Protocol) in order todefine protocols and data formats necessary to build an internet-scaled instant messagingsystem. The working group managed to produce a model for presence and instant mes-saging in RFC 2778 [20] and requirements for an instant messaging protocol in RFC 2779[19]. However, as stated in Section 2.2, the working group failed to achieve a commonconsensus for an instant messaging protocol. This resulted in the launch of several newworking groups specifying protocols based on IMPP.

It was decided that although the IMPP working group was not to specify any instantmessaging protocol, it would carry on with its work. It would focus on producing standardsfor enabling interoperability between instant messaging systems. The working group hassince created RFCs containing:

� a common extensible instant message format (message/cpim)

� a common extensible presence information format (application/pidf+xml)

� a common profile for instant messaging (CPIM)

� a common profile for presence (CPP)

CPIM [50] and CPP [51] specify semantics and data formats for common instant messagingand presence services. The goal of the profiles is to facilitate the creation of gatewaysbetween instant messaging systems for interoperability. CPIM uses the message/cpimMIME (Multipurpose Internet Mail Extension) type [7] as data format for instant messageswhile PIDF (Presence Information Data Format) [65] is used for formatting presenceinformation in CPP.

In order for an instant messaging system to be IMPP compliant, it must conform to theCPIM and CPP profiles and their data formats as well as meet the requirements of RFC2778 and RFC 2779.

2.5.2 SIMPLE

The IETF SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions)working group was one of the three working groups formed in 2000 when the IMPP


working group failed to agree on a common protocol for instant messaging. Of the three,the SIMPLE solution is the only one still going strong; the other two have more or lessfailed.

As the name indicates, SIMPLE is based on SIP (Session Initiation Protocol) [60]. Theprimary work of the SIMPLE working group is to generate an IMPP-compliant proposedstandard SIP extension for instant messaging. SIMPLE defines the presence protocol asan instantiation of the general event notification framework for SIP [56]. For sendinginstant messaging SIMPLE provides two modes: a pager mode [14] and a session mode[13]. When using the pager mode instant messages are sent as SIP messages. In sessionmode SIP is used to initiate a session, in which the instant messages then are sent. Detailedinformation concerning the technical details of the SIMPLE specifications can be found inChapter 4.

The progress of the SIMPLE working group has been quite slow, mostly due to the com-plexity of the SIP protocol. Overall, the SIMPLE specifications currently consist of close to20 Internet Drafts. Only a few Requests for Comments has been produced so far, includingpager mode messaging specified in RFC 3428. Despite the slow-moving standardizationprocess, the SIMPLE standard has gained support from several major companies includingMicrosoft, IBM and Yahoo.

2.5.3 XMPP

The Extensible Messaging and Presence Protocol (XMPP) is beyond doubt the strongestchallenger to the SIMPLE standard in the Internet. Like SIMPLE, XMPP is also adminis-tered by an IETF working group, i.e. the XMPP working group. XMPP has been formedfrom the basis of the Jabber protocol.

The Jabber protocol is the result of a project started by Jeremie Miller in 1998 [16]. Thegoal of the project was to produce an interoperable and open instant messaging protocol,an alternative to the proprietary solutions. The first public release of the protocol tookplace in May 2000. In June 2000 project members sent an Internet Draft of the Jabberprotocol to the IMPP working group (see Section 2.5.1) as an instant messaging protocolproposal. However, the organization of the Jabber project was not mature enough at thetime and the Internet Draft was left to expire. In 2001 the Jabber Software Foundation wasformed to organize the projects and commercial bodies involved in the Jabber community.Following the reorganization, a new Internet Draft was submitted to the IETF in February2002, eventually leading to the birth of the XMPP working group in October 2002.

XMPP is in essence the core of the XML (Extensible Markup Language) based Jabberprotocol. XMPP has been made IMPP compliant by the working group. The JabberSoftware Foundation will continue to work on the parts of the Jabber protocol that arenot part of XMPP or IMPP, exploring features such as: multi-user chat, calendaring and


whiteboarding.

Compared to SIMPLE, the XMPP solution is more mature. Recently, three of four InternetDrafts have been approved as Proposed Standards and the protocol has already beenwidely deployed with tens of thousands of active servers and millions of users. Althoughit has not acquired the support of as many major companies as SIMPLE, XMPP is alsoembraced by big enterprises, including Hewlett-Packard and Intel. An in-depth comparisonof SIMPLE and XMPP from the viewpoint of XMPP can be found in [17].

2.6 Architecture

Although virtually all currently available instant messaging systems are based on differ-ent protocols, architecturally the solutions are quite similar. Nevertheless, two greaterarchitectural aspects can be distinguished, namely the distribution of servers and themechanism for message exchange.

2.6.1 Server Distribution

Essentially two models can be found for how servers are organized in current instantmessaging systems: the centralized model and the distributed model.

In the centralized model, all information is gathered at one place handled by either oneserver or a cluster of servers. All traffic resulting from registration and lookup tasks,such as logging in, subscribing to presence, fetching presence and receiving notifications,is routed through the centralized server.

In the distributed model the information is stored by a network of servers, all managingthe information related to their own domain. When users request their home server forinformation available in other domains, the server forwards the request to the server ofthat domain.

Table 2.4: Advantages and disadvantages of the server distribution modelsCharacteristic Centralized model Distributed model

Administration/Maintenance Easy Moderate

Scalability Limited Good

Attack vulnerability High Moderate

Performance Limited Good

Table 2.4 provides a light comparison of the two models. For a single authority, thecentralized model is easier to administer and maintain than the distributed model. Hence,all the proprietary instant messaging systems are based on the centralized model (seeTable 2.5).


On the other hand, the centralized model has several obvious disadvantages. When thegroup of users accessing the system expands, more and more traffic is directed at theserver (or cluster of servers) causing severe congestion. All proprietary IM systems havequite recently experienced outages relating to this as the amount of users logging on hasbeen soaring. The single point of access is also a security issue as it makes the systemvulnerable to denial-of-service attacks.

The distributed model is more scalable with less traffic directed at a single server. Inaddition, an attack on a server does not usually affect the whole system, but as Lundgrenet al. points out in [39], many of the current distributed systems can suffer from singlepoints of failure if not built carefully. Also, since most communication takes place betweenusers in the same region, a home server in a distributed system is able to deliver informationfaster than a centralized server.

2.6.2 Message Exchange

When it comes to exchanging messages between counterparts, the instant messaging sys-tems can be divided into two camps. One sends all messages, including instant messages,via a dedicated server to the recipient, while the other transmits instant messages peer-to-peer. For peer-to-peer messaging, only instant messages are sent from peer to peer, alllogin and presence information must still be sent to the server (see Figure 2.5).

Figure 2.5: Peer-to-peer instant messaging

Again, both mechanisms come with both gains and losses. Sending instant messages viaa server places an extra burden on the server, adding further delay to the delivery undercongestion. On the other hand, sending messages via a server protects the identity of theusers, as the IP (Internet Protocol) address of a user is not disclosed to other users. Groupchat is also easier to implement when messages pass through a server.

With peer-to-peer messaging the IP addresses of the involved parties are disclosed, but amore efficient data transfer is achieved. Some instant messaging systems send text basedinstant messages via a server, but sends content requiring more bandwidth (e.g. video and


files) peer-to-peer in order to reduce server load.

Table 2.5 lists the server distribution model and message exchange mechanism for theexisting instant messaging systems. A more detailed evaluation of peer-to-peer networkingand server distribution has been performed by Quintana et al. in [55]

Table 2.5: Architectural differences between instant messaging systemsMessaging System Registration/Lookup Message exchange

AIM Centralized Via server

ICQ Centralized Peer to peer

IRC Distributed Via server/Peer to peer

IMPS Distributed Via server

MSN Centralized Via server

SIMPLE Distributed Peer to peer

XMPP Distributed Via server

Yahoo Centralized Via server

2.7 Interoperability

Interoperability is a serious problem in today’s world of instant messaging. As mentionedin earlier chapters, the proprietary solutions are not able to cooperate, creating ’islands’of users unable to communicate with each other. The problem can be seen by comparingTable 2.3 on page 11 with Figure 2.1 on page 6; the sum of users of four different instantmessaging systems is already greater than the sum of all users. This is, of course, due tousers being forced to run several different clients concurrently in order to reach all theircontacts.

The fear of losing their large user bases makes the companies behind the proprietarysolutions reluctant to open up their systems. The interoperability problem has initiatedattempts to create clients able to communicate with all major proprietary protocols. Asthe proprietary protocols are not publicly documented, these solutions are purely basedon reverse-engineering. The messengers from Trillian and Odigo are probably the mostadvanced in this area. The multi-network clients do only hide the interoperability problemthey do not solve it, e.g. users are still required to have accounts in all IM systemsthey want to access. In addition, the corporations owning the proprietary solutions keepchanging their protocols in order to cut off multi-network clients.

Most of the up-and-coming open standard instant messaging protocols are IMPP compli-ant. This makes it relatively straight-forward to create gateways enabling users of oneinstant messaging system to interact directly with users of another system.


2.8 Security

The competition for users caused the companies behind the proprietary instant messagingsolutions to give security a low priority, putting most emphasis on the feature richness fortheir products. Because of this, notable security flaws can still be found in all proprietarysolutions.

The forthcoming standardized solutions have incorporated stronger security mechanisminto their design. This makes the standardized instant messaging systems strong con-tenders in the enterprise instant messaging market.

2.8.1 Types of Security Threats

Several types of security threats for instant messaging can be identified. The main threatsare briefly discussed below, more comprehensive studies of instant messaging securitythreats can be found in [29], [38], [42] and [64].

Worms

A worm is a program that tries to propagate itself across a network, using the resourcesavailable on one machine to attack others. Furthermore, a worm might try to causedamage on the attacked machine before propagation. Most worms are programs spreadthrough email. The content of the email tries trick users into running the worm, in whichcase the worm searches the contacts of the user and forwards itself to these.

Anti-virus products monitoring email traffic are quite effective against worms and canreduce the rate of propagation considerably. Although, worms can propagate just as wellthrough instant messages than through email, support for monitoring instant messaginghas not been available until just recently.

Trojan Horses

A Trojan horse is a program masquerading as a benign application, tricking the user intoexecuting it. Upon execution the Trojan horse usually opens a backdoor, through whichan attacker can access the system. The Trojan horse might also collect user information,such as logins and passwords, and send them over the Internet to the attacker.

Traditionally, firewalls provide protection against Trojan horses, since the firewall canbe configured to block all traffic but traffic from well-known services. When it comes toinstant messaging the Trojan horses can operate via the instant messaging client, making ithard to detect using traditional firewalls. Most Trojan horses exploiting instant messagingutilize the file sharing capabilities in order to infiltrate the system.


Buffer Overflow Attacks

Buffer overflow attacks exploit design flaws that allow an attacker to send overly long inputstreams to an application, causing the application to overflow its memory and execute codeprovided by the attacker instead.

Buffer overflow vulnerabilities have been found in all four of the major proprietary instantmessaging solutions. Nguyen provides a list of attacks exploiting known buffer overflowvulnerabilities of the instant messaging systems in [42].

Man-in-the-Middle Attacks

A man-in-the-middle attack, allows an adversary to listen to and insert messages intoan ongoing session, impersonating one of the users. Alternatively, the adversary canattempt to hijack the connection, disconnecting one of the parties and continuing thesession impersonating the disconnected user. The intention of a man-in-the-middle attackis usually to obtain user passwords and other secret information, either by eavesdroppingthe connections or by asking the user directly, disguised as a trusted friend.

A man-in-the-middle attack against a proprietary instant messaging system is fairly easyto carry out as most systems offer virtually no protection against it. Data is usually sentboth unencrypted and unauthenticated, making reading and producing messages easy foran adversary. The standard solutions provide better protection against man-in-the-middleattacks.

Replay Attacks

A replay attack is an attack in which the adversary records a session between two partiesand later replays the recorded data impersonating one party of the earlier communication.Systems with a weak login mechanism are vulnerable to this attack since the adversarycan login as another user merely by replaying a previously recorded session.

Denial-of-Service Attacks

A denial-of-service (DoS) attack aims to overload the system or service which it is directedat, effectively making it impossible to use the service. Flooding the target with messagesis the most usual type of denial-of-service attack, but known vulnerabilities of the targetsystem that allow the adversary to cause the system to consume a large amount of CPUor to halt the system can also be used in a DoS attack. For attacking large systems, adistributed DoS attack involving numerous computers is often used.

Especially instant messaging systems based on architectures with centralized servers (seeSection 2.6.1) are vulnerable to this kind of attack. Although the usual reason for a DoS


attack is to cause annoyance, it can also be used for example when hijacking a session inorder to block one party of the session.

Chapter 3

Mobile Instant Messaging

Similar to instant messaging in the Internet, mobile messaging also took off in the lastdecade of the 20th century. Mobile services might seem no different from Internet servicesfrom a user’s point of view, but the mobile environment imposes several requirements thata mobile service must fulfill before it can be successfully launched. This chapter presentsthe concept of mobile messaging and identifies the restrictions of mobile environments thata mobile instant messaging service must be able to handle.

The chapter consists of the following parts: Section 3.1 defines the term ’mobile instantmessaging’. Section 3.2 briefly presents the history of mobile messaging. The differencesbetween mobile and fixed environments from a mobile instant messaging point of view aredescribed in Section 3.3. Finally, Section 3.4 describes the standards related to mobileinstant messaging.

3.1 Definition

As the word ’mobile’ has several distinct interpretations depending on the context, at-tempting to provide an unambiguous definition of ’mobile instant messaging’ is in place.

MobileIN.com [41] provides a proper definition stating that ”Mobile Instant Messaging(MIM) is the ability to engage in IM from a mobile handset via various bearer technologies,which may include SMS, WAP or GPRS”.

Although implied by the examples of bearers in the previous definition, it should bestressed that only devices connected through wireless bearers can participate in mobileinstant messaging. In the scope of this thesis, a device must be able to be both mobile andconnected to a network simultaneously in order to engage in mobile instant messaging. Adevice connected to a wireline network that first is disconnected, then moved and finallyreconnected does not fit this requirement.

Furthermore, a handset is required to participate in mobile instant messaging. Therefore,

20

CHAPTER 3. MOBILE INSTANT MESSAGING 21

using instant messaging from a laptop connected through a wireless connection is notconsidered mobile instant messaging in the scope of this thesis, as the laptop does nothave the limitations of a typical handset.

Definition 3 Mobile instant messaging is the ability to engage in instant messaging froma mobile handset via various wireless bearer technologies.

Finally, it should be noted that it is possible for an instant messaging system providingmobile instant messaging to users with mobile handsets to provide instant messaging tousers with fixed connections as well. In fact, this is usually the preferred behavior.

3.2 History

As wireless networks only have existed for a few decades, the history of mobile messagingis short and the history of mobile instant messaging even shorter.

Mobile messaging took off in the late 1990’s when SMS messaging was made availableto GSM (Global System for Mobile communications) subscribers. In the following years,SMS usage kept rising rapidly as can be seen from Figure 3.1.

Figure 3.1: Worldwide monthly SMS traffic. Source: EMC Research

The success of SMS got the operators of mobile networks to realize the value of mobilemessaging; considerable revenues can be gained using only a fraction of the availablebandwidth. Therefore, new messaging services similar to SMS but with richer features,such as EMS (Enhanced Messaging Service) and MMS, have been designed and deployedlately.

The most successful messaging system of the Internet, email, has also been brought tomobile clients in a number of different ways. In the beginning, email in mobile clients was


handled through SMS messages. Later, mobile email was made available through WAP(Wireless Application Protocol) and recently mobile devices with email clients managingemail using well-known mail protocols such as IMAP (Internet Message Access Protocol)or POP (Post Office Protocol) on top of GPRS (General Packet Radio Service) have beenmade available.

Instant messaging solutions for mobile devices have been available since 2002, when AOLand Yahoo started providing access to their instant messaging network using an SMS in-terface. However, these services are not available worldwide, only users of wireless carriersthat have made an agreement with AOL or Yahoo can use them. The SMS-based instantmessaging services are not very convenient to use as they require the user to rememberseveral commands and phone numbers. The recent introduction of mobile devices that al-low both installation of third party software and packet switched data transfer has enabledcompanies to develop their own mobile client software for their proprietary protocols. Forexample, AOL has released an instant messaging client for mobile devices running theSymbian operating system.

Work for a non-proprietary mobile instant messaging solution commenced in 2001 whenEricsson, Nokia and Motorola teamed up to form the Wireless Village initiative (nowknown as IMPS), a joint project established to create universal specifications for mobileinstant messaging. The first release of the specifications was made available in 2002 butit was not until in the fourth quarter of 2003 that the first mobile device with support forthe technology was published.

The IP Multimedia Subsystem (IMS) defined for enabling multimedia communicationservices for 3G networks uses SIP for establishing multimedia sessions. The upcoming3GPP (Third Generation Partnership Project) Release 6 specifications include instantmessaging using SIMPLE, bringing SIMPLE forth as a contender to IMPS in the mobileinstant messaging world as soon as IMS is widely deployed.

3.3 Differences in Comparison to Instant Messaging in Fixed

Networks

Transitioning from developing Internet services targeted at fixed networks to developingmobile services is not a trivial task. The mobile environment introduces several constraintson a mobile service that do not exist in traditional, fixed environments. Not only does thetechnology used for establishing wireless networks place limitations on a mobile service,but also mobile terminals and the behavior of users differ significantly between fixed andmobile environments. This section presents the characteristics of mobile environments thatdeviate from the corresponding ones of wireline environments. Even though only aspectsaffecting mobile instant messaging services are considered here, most of them apply tomobile services in general.


3.3.1 Device Limitations

Due to the requirement of portability, mobile devices have several differences in comparisonto stationary computers, which should be considered when designing a mobile service.These differences are presented briefly below; in-depth studies are available in [15], [23]and [52].

Display Size

As mobile devices are pocket-sized for portability, it follows that displays must be relativelysmall to fit the devices. Due to the small display size, special emphasis must be put onuser interface design for mobile applications. In addition, there are no standard displayresolutions for mobile devices. There exist high-level languages allowing the target deviceto render the user interface using its native style, thus trading look-and-feel design forportability. However, in practice distinct versions of the user interface must often becreated for different display types.

Input Device

Size constraints of portable devices make many traditional input devices such as keyboardsand mice impossible to use with mobile devices. Instead, mobile devices come equippedwith limited keyboards, navigator buttons, touch screens or pointing devices.

When it comes to instant messaging, the greatest problem arising from these alternativeinput devices is the difficulty of typing. Typing using any of the aforementioned methodsis notably slower than typing using a regular keyboard. In recent years some progress hasbeen made in this area; for example the T9 text input system has been introduced.

Memory

Memory is another aspect differing in size from wireline environments to mobile envi-ronments. Both physical memory and permanent storage memory are limited on mobiledevices.

These memory limitations cannot be ignored when designing a mobile service. Due tomemory constraints some handsets might e.g. be unable to receive large bulks of data,forcing designers to utilize alternative methods such as sending data in smaller chunks.

Luckily, rapid progress has been made in this area. In the last few years the magnitude ofmemory sizes has shifted from KB to MB. Several solutions for storing data permanentlyfitting into a very small space, such as CompactFlash, MultiMediaCard, Secure DigitalCard and SmartMedia Card, have been put into market and are used in numerous newmobile devices.


Processing Power

In addition to memory limitations, mobile devices are limited also when it comes to pro-cessing power. When designing a mobile instant messaging service the restrictions ofmobile device processors need to be considered especially when deciding what data for-mats to use. Data formats are of importance because of the processing power that isrequired to en/decode them for network transmission. Codecs for some formats are veryefficient while others require heavy computing. In addition, some formats require moreprocessing power to encode than to decode and vice versa. In general, codecs demandingmore processing power often result in a better data compression rate and since data sizeis another important aspect of mobile computing, this trade-off between processing powerand data size must also be taken into account when choosing data formats.

Battery

Practically all mobile devices are powered by batteries. As most batteries are rechargeable,saving batteries is often quite nonessential. Furthermore, software engineers implementinga mobile service have more influence on battery usage than the designers of the service.

A designer of a mobile service can slightly affect the usage of power by optimizing theuse of the processor and data communications. Data communication hardware consumespower especially when sending or receiving data, optimizing the amount of sent data canhelp reducing power consumption. For techniques reducing the need for processing power,see the previous subsection.

Media Formats

The operating systems of mobile handsets come equipped with a limited range of nativelysupported media formats. When specifying a mobile service, support for a particular mediatype cannot be assumed. Preferably a mobile instant messaging service should providethe means for parties of a communication to find out the mutually supported formats orat least notify the sender of a message when the recipient does not support a particularmedia format.

3.3.2 Network Limitations

The characteristics of wireless network links differ considerably from those of links inconventional wireline networks. These differences affect the behavior of network datatraffic in various ways that need to be considered when designing a mobile service. As thetransport protocols currently in use were originally designed for wireline networks some ofthem do not adapt well to wireless environments. The aspects most relevant to protocolperformance are presented below. When deciding which transport protocols to use for a


mobile service, each protocol needs to be evaluated against these characteristics in orderto find the most suitable for the particular case.

Bandwidth

Although new generation wireless networks will provide users with bandwidth that is closerto the one provided to subscribers of fixed networks, bandwidth is still a factor that cannotbe ignored when planning mobile services. E.g. the data rate of 2.5G systems, which ispresently the most widespread wireless technology, is 10-20 kbps uplink and 10-40 kbpsdownlink while the corresponding rates of the up-and-coming 3G systems are 64 kbps resp.384 kbps [30]. In addition to the reduced bandwidth, bandwidth variations are also morefrequent in wireless networks. Handovers and the fact that voice usually has precedenceover data in wireless networks are two causes for bandwidth fluctuation.

Even though most instant messages contain only text and are small in size, bandwidthlimitations cannot be completely neglected as many instant message services allow anykind of content to be sent. Another reason for optimizing the bandwidth usage is operatorcharging schemes (see Section 3.3.4).

Delay

The delays in wireless networks can be several magnitudes greater than in conventionalwireline ones; delays exceeding one second are not unusual in wireless environments,whereas delays in fixed networks often are measured in milliseconds. Most of the la-tency in wireless networks is caused by transmission delays in the radio access networkand by the extensive processing done at the physical layer [30].

Another characteristic of wireless networks is high delay jitter, i.e. variations to the roundtrip time. Typical causes for increased delay jitter are [28]:

� Temporal loss of coverage, e.g. in tunnels or elevators

� Handovers

� Blocking by higher-priority traffic such as voice calls

Delays and delay jitter especially affect the performance of protocols providing reliabledelivery, such as TCP (Transmission Control Protocol). Several mechanisms for improvingTCP performance in wireless environments have been developed. The Timestamps Option[33] aims to make TCP adapt better to delays and delay jitter.

As instant messaging is a real-time service, minimizing the time it takes for a message thereach the recipient is essential. For example, initiating a connection with a connection-oriented protocol is very time-consuming when long delays are experienced. Therefore,keeping the connection active between messages improves performance considerably.


Packet Losses

Another characteristic specific to wireless networks is a high packet loss rate. As opposedto the wireline networks where packet losses usually are caused by congestion, packetlosses in wireless networks are mainly caused by bit errors, i.e. packets are corruptedwhile traversing the network. Common reasons for these bit errors are [49]:

� Weak signal power

� Co-channel interference (several sources with equal signal power)

� External noise sources between transmitter and receiver

Due to the high probability of packet corruption, many wireless technologies apply link-layer error correction techniques in order to reduce end-to-end packet losses.

In particular the TCP protocol, which is built around the assumption that packet lossesare caused by congestion, suffers a decrease in performance in wireless environments. Anumber of papers studying and proposing improvements to TCP, including [21], [30], [33]and [36], are available. Unreliable transport protocols, such as UDP (User DatagramProtocol), obviously suffer from more packets being lost but deliver packets without adecrease in performance. Designers of mobile services must consider this trade-off betweenperformance and reliability.

Proxies

NAT (Network Address Translation) gateways and firewalls are common in fixed networks,but in wireless networks the majority of the clients are connected to the Internet through aproxy. Especially peer-to-peer applications like instant messaging do not interact well withNAT gateways [47]. Problems arising from the use of NAT gateways in mobile networksinclude:

� Incoming connections to clients are not possible, the client must initiate the connec-tion

� The IP address to which the recipient should reply changes when packets traverse thegateway, therefore applications that store addresses in the data portion of messagesare unlikely to work with proxies

� Applications cannot send reply data to dedicated ports, the ports dynamically allo-cated by the proxy must be used

� Proxies might drop idle connections that are still active in order to free up resources

In order to be usable in mobile networks an instant messaging service must provide mech-anisms for allowing messaging through various types of proxies.


3.3.3 Mobility

The fact that users can be on the move while using a mobile service also introduces a fewaspects different from fixed environments. These differences are presented below.

Roaming

Roaming is the ability to move freely while maintaining an active connection to a wirelessnetwork. There are two types of roaming: contractual roaming and handover roaming.

Contractual roaming is the ability to use services outside of the network of the homeservice provider and still only pay the home service provider. When it comes to designingmobile services contractual roaming is not a factor.

Handover roaming is a factor that mobile services should consider. Handover roaming itselfcomes in two flavors, horizontal handovers and vertical handovers. Horizontal handoversare the ability to move from one access point to another within the same technology.As stated in Section 3.3.2 horizontal handovers have an impact for instance on networkdelay and on delay jitter. Vertical roaming enables moving between to different types oftechnologies, e.g. from UMTS (Universal Mobile Telecommunications Network) to GPRSor from UMTS to WLAN (Wireless Local Area Network). Vertical roaming might alterthe behavior of a network connection completely as the characteristics of the underlyingtechnology are changed.

Coverage

Another aspect of wireless networks that is not available in wireline networks is networkcoverage. Naturally, coverage is lost when the mobile device is moved outside of the areacovered by the network, but temporary coverage loss is also possible when moving in thenetwork. Temporal coverage loss usually occurs in closed locations like e.g. tunnels orelevators. In addition to decreases in performance discussed in Section 3.3.2 coverage lossoften cause disconnections.

A mobile service should be able to cope with users being disconnected unexpectedly,minimizing the damage inflicted by sudden disconnections. Services preserving user stateand letting users continue a previous session upon login is one example of reducing theimpact of unexpected disconnections.


3.3.4 Other

Switching Equipment

Due to the quite extensive range of limitations of mobile devices and mobile networks listedin the previous sections, users will prefer to use conventional devices and fixed networkswhenever possible. Most users will most likely use a service from their mobile device whileon the move, but then switch to the computer when at home or in the office.

A mobile instant messaging service should be able to manage the frequently changingdevice capabilities of users constantly changing equipment and perhaps even support si-multaneous sessions from a single user with multiple devices.

Charging

Finally, the success of a mobile service often depends on its cost; if the service is tooexpensive it will not be able to compete against other similar services, e.g. mobile instantmessaging cannot compete against short messaging services if it costs much more eventhough it comes with more advanced features.

As many operators are likely to charge by the amount of data transferred, optimizing theamount of data sent by the service not only increases the performance of the service, butalso makes it cheaper to use.

3.4 Standards and Protocols

This section provides an overview of the standards related to mobile instant messaging.Although the xMS services cannot be classified as instant messaging, their usage is verysimilar to instant messaging as described in Section 3.4.1. Section 3.4.2 introduces IMPS,currently the only instant messaging system designed specifically for mobile environments.

3.4.1 xMS (SMS, EMS, MMS)

Technically none of the xMS messaging services can be seen as instant messaging due tothe lack of presence information. Nevertheless, the usage of these services resembles theuse of instant messaging services very much. Since users carry their mobile devices withthem, their presence rate is much higher than at a fixed computer. As the probability forreceiving a quick reply to a message is considerably higher, the content of xMS messages isoften similar to the content in instant messages, i.e. xMS is often used for short questionsto which an immediate answer is expected. The following subsections give a brief overviewof the xMS messaging services.


Short Message Service (SMS)

SMS (Short Message Service) was originally designed and used for service messages, mak-ing it possible for operators to send service notifications to subscribers. This explains thelow capacity (140 data octets) and limited functionality (text only) of SMS. The first SMSmessage was sent already in 1992, but it took until the end of the 1990’s until the massuse of the SMS service begun.

At first all messages were mobile terminated, operators using SMS messages to notifyusers of waiting voicemail. The launch of support for mobile originated SMS messages,allowed end users to take an active role and send SMS messages to each other. Thisnew functionality allowed the creation of interactive services using the SMS technology.Subscribers adopted this new form of mobile interaction quickly and as shown in Figure3.1, the popularity of the SMS service has been growing swiftly ever since.

Locationwise SMS is far more popular in Europe and Asia than in North America, wherecompeting transmission technologies [43] and the Receiving Party Pays (RPP) system [66],[71] have been slowing down the rollout of SMS.

Enhanced Messaging Service (EMS)

EMS (Enhanced Messaging Service) was the first standardized messaging solution to offerricher messaging content than SMS. The EMS standard was born in the beginning of year2000 when 3GPP, the same standardization body that defined SMS, started working onit. Of the terminal manufacturers, Alcatel, Ericsson, Siemens and Motorola have beenfostering the standard and included EMS support in their terminals. The first EMScompliant mobile devices became available to customers in mid 2001.

EMS is completely based on SMS technology allowing up to 255 SMS messages to bechained together as one EMS message increasing the amount of data that can be trans-ported in one message from 140 bytes to about 38KB. EMS supports various contentsincluding formatted text, animation, polyphonic sounds and color pictures. EMS alsoallows combinations of different media types in one message as long as the maximummessage size is not exceeded.

A major advantage of EMS being based on existing SMS technology is that operators donot need to invest in new infrastructure in order to offer EMS messaging. EMS messagingis completely transparent to SMS service centers. Practically the only requirement forEMS messaging is that both the sender and the recipient of an EMS message carry mobiledevices that are EMS compliant.

EMS is often seen as an intermediary step between SMS and MMS. For example, Baskervillepredicts a market share of only 3% for EMS in 2006 while MMS is projected a share ofover 30 %. The supporting forces behind EMS recognize the fact the MMS is a more ideal


messaging service for 3G networks than EMS, however they see EMS as a cost-effectivetechnology that eases the transition to MMS.

Figure 3.2: Global message revenue market share projection for 2006. Source: Baskerville

Multimedia Messaging Service (MMS)

Following EMS, MMS (Multimedia Messaging Service) is the next evolutionary step ofmobile messaging. MMS supports messages with theoretically unlimited size and a by farricher range of multimedia content than EMS. MMS supports many standard multimediaformats like JPEG, GIF, MPEG and MIDI, which can be combined in one message usinga presentation language (e.g. SMIL).

The MMS specifications are defined by both 3GPP and OMA (Open Mobile Alliance) in aneffort to achieve worldwide interoperability. As opposed to EMS, which is based on SMStechnology, MMS is a completely new technology. MMS makes use of existing protocols(e.g. WAP, SMTP, HTTP (Hypertext Transfer Protocol)) and message formats (SMIL,MIME) as far as possible, but requires operators to invest in new network elements. Table3.1 summarizes the main differences between SMS, EMS and MMS.

Although many network operators already offer MMS services to subscribers and mostnew mobile devices contain support for MMS, the volume of sent messages has so far beenrelatively small. Subscribers are still reluctant to use the service as they cannot be surethat the counterpart has an MMS compliant handset. Assuming the cost of sending MMSmessages is kept reasonable, it is probable that MMS will acquire a significant amount ofthe messaging market (see Figure 3.2) as soon as the penetration level of MMS complianthandsets is high enough for mass use.


Table 3.1: Comparison of mobile messaging services [11]Feature SMS EMS MMS

Media supported Text only Formatted text, simplemedia formats, e.g.pictures, animations,sounds

Multiple rich media for-mats, e.g. video, audio,text

Delivery mechanism Signaling channel Signaling channel Data channel

Store-and-Forward Yes Yes Yes

Confirmation of mes-sage delivery

Yes Yes Yes

Protocols SMS specific, e.g.SMPP

SMS specific WAP and general In-ternet e.g. MIME,HTTP, SMTP

Platform SMS Center SMS Center MMS Server, MMSRelay, MMS MessageStore, MMS UserAgent, MMS UserDatabases

3.4.2 IMPS

IMPS (Instant Messaging and Presence Service) is a set of specifications striving to ensureinteroperability in mobile instant messaging. The initiative was started in 2001 by threeleading telecommunication companies, namely Ericsson, Motorola and Nokia. The initia-tive was originally known as the Wireless Village but has since then been consolidatedinto the Open Mobile Alliance (OMA), which is an industry forum for developing marketdriven, interoperable mobile service enablers.

In order to minimize interoperability issues, the initiative is open to participation fromindustry supporters interested in providing input regarding ongoing specification work.The aim of IMPS is not only to provide exchange of messages and presence information inmobile networks, but also to facilitate the creation of gateways to other instant messagingservices. For a detailed evaluation of IMPS as a whole compared to SIMPLE, see Chapter4.

The first approved version of the IMPS specification was released in February 2002 andit was followed up by version 1.1 in November 2002. Version 1.2 has been available as acandidate enabler since February 2003 and will be approved by the end of 2004. Currentlythe initiative is working on version 1.3 and a candidate enabler is planned towards the endof 2004. Although the specification work has been quite rapid, IMPS has been quite slowto market. It was not until the final quarter of 2003 that the first IMPS compliant mobiledevices were released and only a few operators are currently offering instant messagingbased on IMPS to subscribers. Like MMS, the IMPS service is expected to take off assoon as the penetration of IMPS capable handsets is high enough.

Chapter 4

Comparison of IMPS and SIMPLE

This chapter contains a comparison of two open instant messaging standards applicable inmobile environments, namely IMPS and SIMPLE. IMPS is specifically defined for use inmobile environments and SIMPLE will soon be incorporated into 3G networks as part ofthe SIP-based IMS (IP Multimedia Subsystem). Therefore, these two services are withoutdoubt the top contenders in the mobile instant messaging race.

As IMPS services have not yet been deployed by operators and IMS is not yet available incommercial wireless networks, measuring the performance of the services using tests wasnot possible. Hence, the comparison between the two services had to be performed ona theoretical basis. Specifications, articles and technical reports related to the area wereutilized. In addition, test results from sub-areas, e.g. studies evaluating the performanceof transport protocols in wireless networks, were considered in the comparison.

The aim of the comparison was to investigate which of the two standards suits the demandsof mobile instant messaging the best. Therefore, the features differing between mobile andfixed environments listed in Section 3.3 were emphasized in the comparison. However,some features crucial to both environments, such as security, were also studied.

The comparison was performed between version 1.2 of IMPS and the current (August2004) specifications of SIMPLE. IMPS version 1.2 is currently a stable candidate enablerto which no further changes are expected. The final release is planned towards the endof 2004. Most SIMPLE specifications are still ongoing work available as Internet Drafts.Nevertheless, the specifications containing the main functionality are in a stable state.Thus, although neither service is complete it is possible to carry out a fairly thoroughcomparison between them.

This chapter is organized as follows: Section 4.1 compares the functionality provided bythe services. Section 4.2 presents and evaluates the architectures and protocols of theservices. The performance and security is investigated in Sections 4.3 and 4.4. The nexttwo sections, Section 4.5 and Section 4.6, study the interoperability and extensibility ofthe services. Finally, Section 4.7 presents the current status and anticipates the future

32

CHAPTER 4. COMPARISON OF IMPS AND SIMPLE 33

trends of the two services.

4.1 Functionality

This section provides an overview of IMPS and SIMPLE functionality. The functionalityis considered from the user’s point of view. Succeeding sections study the technologybehind the functionality in detail.

Table 4.1 displays the support for main instant messaging functionality in IMPS andSIMPLE. As can be seen there are few differences between the two services. All majorfeatures are available in both services.

Table 4.1: IMPS and SIMPLE functionalityFunction IMPS SIMPLE

General functions

Login and logout Yes Yes

Service and capabilitynegotiation

Yes No, services and capabilities are not negotiated with aserver. It is up to client to reject unsupported requestsand content types.

User search Yes No

Invitations Yes Yes

Contact lists Yes Yes

Presence

Presence subscriptions Yes Yes

Presence notifications Yes Yes

Update presence Yes Yes

Presence authorization Yes Yes

Watcher list Yes Yes

Watcher notifications No Yes

Instant Messaging

Sending and receivinginstant messages

Yes Yes

Delivery reports Yes Yes

Message blocking Yes No, must be implemented in the client

Message compositionindication

No Yes

Group Messaging Yes Yes, but specified by the SIPPING WG

In IMPS all traffic is directed via an IMPS server before reaching its destination (seeSection 2.6.2). The IMPS service enables clients to inform the IMPS server about sup-ported services, client capabilities etc. This makes it possible for IMPS servers to rejecttraffic not supported by the client. Since SIMPLE sends instant messages peer-to-peer,


a similar mechanism cannot be implemented. This explains the differences in service ne-gotiation, capability negotiation and message blocking functionality of the two services.SIMPLE provides the means for clients to reject single messages but mechanisms for de-ciding which messages to reject, are not part of the specifications. SIMPLE clients canhowever implement e.g. message blocking in non-standard ways.

IMPS offers functionality for finding out the IMPS address of a user through a search.For example, if the real name of the user is known, the IMPS address can be discoveredusing the search functionality. SIMPLE does not provide this kind of functionality; theaddress of the user must be resolved using other means before a line of communicationcan be initiated.

The presence service features provided by the services are similar, except for the lack ofwatcher notifications in IMPS. Using watcher notifications a user can find out wheneveranother user subscribes to or unsubscribe from the presence information of the user. IMPSoffers the functionality for retrieving a list of current watchers, but real-time notificationsabout changes made to the list are only sent in SIMPLE.

Message compositions indications can be used to notify a user as soon as the other partystarts composing a reply to a message. This feature is available in several proprietaryinstant messaging systems. SIMPLE offers support for message composition indications,while IMPS does not.

Group messaging is a feature analogous to chatting, allowing users to join groups andparticipate in discussions within the group. IMPS includes support for group messaging.The SIMPLE working group does not directly offer group messaging. Instead, the SIP-PING (Session Initiation Protocol Project Investigation) working group defines a moregeneral service called conferencing, providing group functionality for any type of mediasession. Therefore group messaging can be accomplished by combining conferencing withSIMPLE messaging sessions. As conferencing is included in the IMS, group messaging willbe available in networks supporting the IMS architecture.

4.2 Technology

This section describes and compares the architectures and protocols utilized by the twocompared services, IMPS and SIMPLE.

4.2.1 Architecture

IMPS

The architecture of the IMPS service is depicted in Figure 4.1. IMPS is based on a client-server architecture, all traffic sent from a client passes through the server (see Section


2.6.2); peer-to-peer messaging is not supported.

Figure 4.1: IMPS architecture [6]

IMPS Server

The IMPS server holds five important elements; the Service Access Point (SAP) and fourservice elements. The SAP serves as the interface through which the outside environmentcan communicate with the IMPS server. The interface provides IMPS clients, the mobilecore network, proprietary gateways and other IMPS servers with access to the functionalityof the SAP and the service elements. The functionality of the SAP includes:

� Authentication and authorization

� Service discovery and service agreement

� User profile management

� Service relay

The functionality specific to instant messaging can be divided into four logical groups.Each service element comprises the functionality of one such group. Table 4.2 lists theservice elements and their main functionality.

All IMPS servers are required to provide SAP functionality but service elements can bescattered among several servers; a server is not required to implement all of them. This


Table 4.2: IMPS service elementsService element Main functionality

Presence Presence managementPresence subscriptionsPresence authorizationContact list management

Instant Messaging Instant message deliveryAccess control

Group Group usageGroup managementGroup access control

Content Content sharing

facilitates the creation of distributed IMPS services, where servers relay requests to theserver containing a particular service element using the Server-Server Protocol (SSP).

IMPS Clients

The IMPS system defines two types of clients, Embedded Clients and CLI (CommandLine Interface) Clients. The Embedded Client can be embedded into several differentenvironments, e.g. mobile terminals, fixed PC-clients and automated applications. TheClient-Server Protocol (CSP) allows these clients to be fully interoperable despite theirdifferences. CLI Clients use the text message based Command Line Protocol (CLP) tocommunicate with IMPS servers. CLP consists of commands typed by the user and sentas SMS messages to the IMPS server, which sends an SMS message in reply for the userto read and interpret. Consequently, CLI Clients need no software except for the abilityto send and receive SMS messages. CLI Clients provide only a subset of the functionalityprovided by Embedded Clients.

SIMPLE

Figure 4.2 shows the architecture of SIMPLE. As mentioned previously, theSIMPLE specifications are not yet finalized and therefore changes to the architecture,such as addition or removal of reference points, are possible.

The reference points and their associated communication protocols are summarized inTable 4.3 and further elaborated on in the following subsections. As can be seen fromthe table, protocols providing direct interaction between the server elements are still tobe defined. Some of these undefined reference points are not necessarily needed as serverelements can communicate with each other utilizing reference points used by clients. Inthis case a server element acts as a client in order to use the services provided by anotherserver. For example, a GLMS (Group and List Management Server) can subscribe topresence information provided by a presence server. Furthermore, several server elementscan be co-located into one physical element, in which case an element has direct access to


Figure 4.2: SIMPLE architecture

the information of the other co-located elements.

Table 4.3: SIMPLE reference pointsReference Point Functions Protocol

IM-1, IM-2, IM-3 Session signaling between IM elements using the SIP/IP Core SIP

IM-4 Peer-to-peer messaging MSRP

IM-5, IM-6 Messaging through IM Servers MSRP

IM-7 Communication between a Presence Server and an IM Server Undefined

PRS-1, PRS-2 Communication between a Presence Client and a Presence Server SIP

PRS-3 Presence information and authorization management XCAP

GM-1, GM-2 Communication between a Group Management Client and GLMS SIP

GM-3 Management of groups and lists at the GLMS XCAP

GM-4 Communication between a GLMS and a Presence Server Undefined

GM-5 Communication between a GLMS and an IM Server Undefined

It should be noted that Figure 4.2 is somewhat simplified as the server elements themselvescan consist of several smaller elements that are not required to exist at the same locationeither (for an example, see Figure 4.3). However no means for communication betweenthe sub-elements of the server elements have been defined. In practice, it follows that thesub-elements usually will be co-located in the same physical entity, similar to the serversof Figure 4.2.

IM Server

SIMPLE provides two modes for sending instant messages: pager mode and session mode.


In pager mode instant messages are sent over SIP using the MESSAGE method extension[14]. When using session mode messaging, a session is established using SIP, after whichthe Message Session Relay Protocol (MSRP) [13] is used for exchanging instant messageswithin the session.

Both modes are able to function without any actual server functionality. In this case theIM Server element of Figure 4.2 simply consists of a regular SIP proxy. When using pagermode, IM Server elements only route the message to the recipient over IM-1, IM-2 andIM-3. For session mode messaging, the session is initiated using IM-1, IM-2 and IM-3,while the actual message session is established over IM-4 using MSRP.

MSRP sessions can also be directed through MSRP relay elements [34] using referencepoints IM-5 and IM-6. Currently this is the only case where the IM Server could in-clude extra functionality. For example, a store-and-forward mechanism enabling offlinemessaging could be implemented.

Presence Server

By definition a SIMPLE presence server is a physical entity either acting as a presenceagent or forwarding incoming subscriptions to entities that may act as presence agents[58]. A presence agent is a SIP user agent which manages presence subscriptions and sendsnotifications to watchers whenever the presence information of the subscribed presentity isupdated. In order to manage presence subscriptions and notifications the presence agentneeds access to both presence information and presence authorization rules, both definedas separate entities. As the methods to be used for communicating between these entitiesare undefined, most implementations will co-locate all in one physical element, generallycalled the Presence Server, as shown in Figure 4.3.

Figure 4.3: SIMPLE Presence Server

Figure 4.3 also illustrates another aspect typical to SIMPLE; on several occasions multiple


methods for performing the same function exist. For example, presence information canbe updated either using the SIP PUBLISH method over PRS-1 and PRS-2 or using theXML Configuration Access Protocol (XCAP) [59] over PRS-3.

GLMS

The Group and List Management Server (GLMS) is responsible for the management ofcontact lists, group lists and group access lists. The GLMS allows users to create groupsand to define the users which are allowed access to the created groups. The XCAP protocol(over GM-3) is generally used to manage the content on the GLMS.

The GLMS might act as a server for ongoing group messaging sessions as well, but groupmessaging sessions can also be hosted by other entities, such as dedicated applicationservers or the hosts that created the groups.

4.2.2 Protocols

This section presents protocols specific to the IMPS and SIMPLE services. Well-knownprotocols such as TCP, UDP or HTTP are not presented although used by the services.Only protocols enabling the actual functionality of the services are presented.

IMPS

The IMPS architecture and the protocols used for transporting data between the elementsof the architecture are presented in Figure 4.2. This section presents CSP and SSP,the protocols most essential to the IMPS service. Of the other protocols, CLP is quiteinconvenient to operate and contains only a subset of the functionality of CSP. The ServerMobile Core Network Protocol (SMCNP) for enabling features such as charging has notbeen defined by OMA at all.

Client-Server Protocol (CSP)

The Client-Server Protocol (CSP) provides IMPS clients with access to the IMPS serverand its functionality. The functions provided by the server are used through CSP trans-actions. A CSP transaction consists of the messages needed to carry out a function,ordinarily one request and its response. Most CSP transactions are only available withina CSP session. A CSP session is established when the user logs in to the system andterminated upon user logout or if the server decides to disconnect the user. CSP sessionsare transport independent, i.e. they remain valid even when the transport connection isbroken, a phenomenon typical to mobile networks as described in Section 3.3.3.

In order to achieve the flexibility needed for CSP to be used in clients varying frommobile terminals to fixed PC-clients, several different transport bindings have been defined.Logically a CSP transport binding is divided into two channels: a mandatory data channelin which all CSP messages are exchanged and a conditional CIR (Connection Initiation


Request) channel used to activate the data channel whenever it is not active (Figure 4.4).This communication model enables a server to communicate with clients behind proxies,which is a usual situation in mobile networks (see Section 3.3.2)

Figure 4.4: IMPS communication model

The protocol bindings defined for the data channel are WSP (Wireless Session Protocol),HTTP, HTTPS and SMS, while the bindings for the CIR channel are WAP push overSMS, WAP push over UDP, SMS, UDP, TCP and HTTP.

CSP data is carried over the network using the XML message format according to theDTDs (Document Type Definition) specified in [2] and [4]. See Appendix A for examplesof CSP messages. In order to optimize messages for size, CSP also supports the WBXML(Wireless Binary XML) format [1].

Server-Server Protocol (SSP)

The Server-Server Protocol (SSP) [3] connects IMPS servers with each other. SSP enablesIMPS clients to use IMPS functionality distributed across the network, possibly providedby different service providers. In addition, SSP enables other instant messaging networksto communicate with the IMPS network through proprietary gateways.

SSP is transferred using either HTTP or HTTPS over the TCP transport protocol. AsHTTP is an asymmetrical protocol two physical TCP connections are required in orderto provide two-way communication. SSP uses persistent TCP connections for improvedperformance.

Equally to the CSP protocol, SSP is also conveyed between network elements in the XMLformat. WBXML is not supported by SSP since servers ordinarily communicate with eachother via wireline connections with high bandwidth.

SIMPLE

Session Initiation Protocol (SIP)

The Session Initiating Protocol (SIP) is a signaling protocol used for creating, modifyingand terminating sessions with one or more participants [60]. SIP allows for any kind ofsession to be initiated, including IP telephony calls, multimedia conferences and instantmessaging sessions. Sessions created using SIP are peer-to-peer, i.e. the SIP frameworkis only used for managing sessions, not for session traffic. This typically results in a SIPtrapezoid shown in Figure 4.5.

User agents are SIP entities able send SIP requests acting as clients (UAC) and respond


Figure 4.5: The SIP trapezoid

to incoming requests as servers (UAS). All servers and clients of the SIMPLE architecture(Figure 4.2) act as user agents.

SIP proxies accept SIP requests from user agents or other SIP proxies and route themcloser to the recipient.

In addition to proxies and user agents, registrars are also important elements in SIPnetworks. Registrars accept registrations of address information from other SIP entities.The registrars store the information in location services which are then used by SIPproxies when routing messages.

Finally, redirect servers can be utilized to redirect incoming requests to other destina-tions, e.g. a user could set the SIP phone at work to redirect all calls to the SIP phone athome.

SIP is very similar to the HTTP protocol [22], utilizing the same request/response trans-action model where each transaction consists of a request invoking a particular methodand the responses to the request. The majority of the message and header field syntax isalso derived directly from HTTP.

SIP allows extensions to the protocol to be made in the form of new methods and headerfields. Three extensions of the SIP protocol have a central role in SIMPLE, namely theevent notification extension [56], the pager mode instant messaging extension [14] and theUPDATE method extension [57]. The event notification extension enables SIP nodes tobe notified when a particular event occurs. The instant messaging extension adds supportfor sending instant messages in SIP messages without creating a session. Finally, theUPDATE method extension provides the means for updating presence information. Inaddition, group messaging software may use the REFER method extension [62].

Table 4.4 lists the main SIP methods and their use in SIMPLE.

Message Session Relay Protocol (MSRP)

The Message Session Relay Protocol (MSRP) [13] is an instant message transport pro-tocol defined by the SIMPLE working group. As opposed to pager mode instant mes-sage exchange which uses the SIP MESSAGE method, MSRP is a session-based protocol.MSRP sessions can be setup using any signaling protocol capable of initiating sessions. InSIMPLE the SIP protocol is naturally used.


Table 4.4: SIMPLE usage of SIP methodsSIP method SIMPLE function

REGISTER Login/logout, enables the user to be reached by other users

INVITE Initiating instant messaging and group messaging sessions

REFER Alternative method for inviting users into ongoing group messaging sessions

BYE Terminating sessions

SUBSCRIBE Subscribing to the presence information of other users, watcher information, groupchange information etc.

NOTIFY Notifies subscribers of particular events, e.g. changes to presence information

UPDATE Updating presence information

MESSAGE Sending of pager mode instant messages

Like SIP, MSRP is also a text based protocol similar to the HTTP protocol. MSRP is afairly simple protocol, only two request methods are needed: the SEND method and theREPORT method. The SEND method is obviously used for sending instant messages.MSRP does not limit instant messages to contain only text; any content type can be used.The REPORT method can be used for receiving delivery reports for sent instant messages.

As MSRP is based on HTTP, it allows for extending the protocol by adding new methodsand header fields. The ’Relay Extensions for MSRP’ specification [34] does exactly that,adding support for using relay intermediaries to MSRP, which originally is a peer-to-peerprotocol.

XML Configuration Access Protocol (XCAP)

The XML Configuration Access Protocol (XCAP) [59] allows clients to retrieve, modifyand delete XML data stored on a server. Although defined by the SIMPLE working group,XCAP is a general-purpose protocol which area of usage is not restricted to SIMPLE.However, XCAP is particularly suitable for the needs of SIMPLE as all data permanentlystored in SIMPLE server elements, such as presence information, watcher information andpresence authority rules, is defined in the XML format.

XCAP provides the means for mapping XML documents and document elements directlyto HTTP URIs (Uniform Resource Identifier). This enables XCAP to manipulate XMLdocuments stored on a server using normal HTTP primitives. The HTTP GET method isused for retrieving XML documents or parts of them, the PUT method is used for creatingor modifying documents and the DELETE method can be utilized for deletion of XMLdocuments.

The XCAP specification in [59] defines a framework for manipulation of XML data. Inaddition, each application storing data on XCAP servers comes with application-specificconventions, e.g. XML schemas and bootstrap URIs, which need to be defined. Thereforeeach application using XCAP is required to specify application-specific requirements in an


’XCAP Application Usage’ document. For example, an application usage for manipulatingpresence information using XCAP is defined in [32].

4.2.3 Summary

As a whole, the architecture of IMPS is more mature than the SIMPLE architecture.The IMPS architecture is relatively simple; complete instant messaging functionality canbe delivered using only two protocols, CSP and SSP, defining the client-client and theserver-server interfaces clearly and unambiguously.

The SIMPLE architecture is without doubt more complex; numerous reference points aredefined for accessing the service. The functionality has been divided into several smallelements of which each has been defined independently from the others in order to providea flexible system. However, although the client-server interfaces of the elements are quiteclearly defined, communication between server elements is mostly undefined. Also, onseveral occasions the SIMPLE service provides several alternatives for performing thesame function. While this on one hand improves flexibility, it might on the other handincrease complexity as server solutions are forced to provide all alternatives in order tobe functional against all kinds of clients. Again, it should be stressed that the SIMPLEspecifications are ongoing work; changes to the current solution are possible.

The protocols on which the network communication of IMPS and SIMPLE relies are verysimilar; both services rely on HTTP-like protocols based on the request/response model.In addition, all data except for the content of instant messages is transferred in the XMLformat for both IMPS and SIMPLE. The characteristics of the protocol and data formatswhen it comes to performance, security etc. are evaluated in subsequent sections.

4.3 Performance

This section evaluates the performance of IMPS and SIMPLE compared to each other.Several aspects such as bandwidth usage, delays, processing, coverage loss, proxy traversaland scalability were studied. As mentioned earlier, the performance comparison is basedpurely on theoretical facts, no real tests could be performed due to the lack of deployedimplementations of the services.

4.3.1 Bandwidth Usage

As instant messages usually only contain short strings of text, it might seem unimportantto optimize them for size. However, in addition to the actual data, instant messagescarry addressing information, session identifiers etc. increasing the size of the messagesubstantially. Moreover, although 3G networks offer a broad bandwidth, only a fraction


of it will be allocated for SIP signaling. Also, it will take long until complete 3G coverageis reached and until then low-bandwidth technology, such as GPRS, will be widely used.

Message Size

Protocol messages consist of two parts: protocol data and payload data. In order tooptimize the total size of a message, both parts need to be optimized. IMPS messageshave a relatively small protocol part; most information is generally carried as payloaddata. SIMPLE messages carry more information in the protocol part of the message andonly the actual instant message or presence information is carried in the payload part.

For optimizing the size of the protocol part IMPS includes a WSP (Wireless SessionProtocol) transport binding. In essence, WSP is a tokenized version of HTTP resultingin smaller sized messages. For compressing the payload data, IMPS provides support forthe WBXML format. WBXML tokenizes the XML elements of the CSP protocol. As theXML elements of the CSP protocol have lengthy names, the WBXML format reduces thesize of the payload data significantly. On average the size of a compressed CSP messageis about 25% of the uncompressed message.

SIMPLE SIP messages can be compressed using the SigComp solution [54] as describedin [12]. SigComp compresses both the protocol and the payload part of SIP messages. Aperformance evaluation performed by Nordberg et al. in [46] indicates that the messagesize can be reduced to approximately 25-50% of the uncompressed size for SIP messagessent in 3G networks.

By comparing the message sizes of instant messages for both services (see Appendix Afor message examples) it can be noted that sending uncompressed IMPS instant messagesconsumes over three times more data than pager mode SIP instant messages. Setting up aSIMPLE session mode and sending one message requires a little more data than one IMPSmessage. Nevertheless, after session mode has been set up, all subsequent SIMPLE instantmessages are over five times smaller than corresponding IMPS messages. Conclusively,despite IMPS providing a somewhat higher compression rate, SIMPLE messages are stillconsiderably smaller than IMPS messages.

Finally, the message size can also be affected by reducing the size of presence notificationsreceived from the presence server. The size of notifications can be decreased using partialnotifications, i.e. the server sends only the changed part of the presence information inthe notification. Both IMPS and SIMPLE includes support partial notifications.

Filtering Rules

The bandwidth usage can also be limited using filtering rules. Clients can use filtering rulesto narrow the amount of events resulting in notifications. Filtering rules can also be used to


block instant messages from certain users, thus limiting the amount of data received. IMPSsupports filtering rules for both presence information and instant messaging. SIMPLE onlysupports filtering rules for presence information; instant messages cannot be blocked beforearriving at the client due to the peer-to-peer property of SIMPLE.

Signaling

IMPS needs no signaling in order to send an instant message to another user. SIMPLEneeds to setup a session using SIP when using session mode instant messaging, thus in-troducing data overhead in comparison to IMPS.

Furthermore, SIMPLE presence subscriptions are not permanent, clients must refreshsubscriptions periodically. The length of the period depends on the policy of the presenceserver. In comparison, IMPS presence subscriptions are guaranteed to last for the lengthof an IMPS session. However, IMPS clients might need to renew subscriptions wheneverthey login to the system, creating overhead comparable to SIMPLE presence refreshments.

4.3.2 Delays

Delays and delay jitter are not as important factors in instant messaging as in other real-time services. E.g. when sending voice or video, keeping delays and delay jitter to aminimum is critical to the quality of the communication. Nevertheless, instant messagingis a real-time service and if delays grow too high, the user experience deteriorates. Delayjitter is not a factor in instant messaging since messages are not sent in an uninterruptedstream.

There are two types of delays affecting user experience: the session setup delay and themessage exchange delay. These are studied in more detail below.

Session Setup

The session setup delay is the amount of time needed for initiating the sending of aninstant message. The delay caused from establishing a data channel to the radio accessnetwork can be neglected here as both services perform the same procedure.

In IMPS, clients create a session with the IMPS server upon logging in to the system, butsessions are not initiated with recipients of instant messages. Hence there is no sessionsetup delay associated with the IMPS service.

SIMPLE pager mode messaging generates no session setup delay either. SIMPLE sessionmode messaging requires a session to be set up using SIP before the first instant messagecan be sent. A minimum of three SIP messages or 2 round-trip times (RTTs) are neededto complete the setup of a SIMPLE instant messaging session.


Message Exchange

The message exchange delay is simply the amount of time elapsed between sending aninstant message and its arrival at the recipient. The following aspects of the servicesaffect the message exchange delay:

� System architecture

� Transport protocol

� Persistent connections

� Message size

In IMPS all data communication with the IMPS server is client-initiated, i.e. the servercan only send data to the client in a reply to a request initiated by a client. The IMPSserver utilizes the CIR channel (Figure 4.4) to trigger requests from clients when needed.This inflicts an additional RTT to occur between the receiver and the IMPS server foreach message. This is illustrated in Figure 4.6.

Figure 4.6: IMPS message exchange

IMPS recommends but does not require persistent connections to be used between clientsand servers. Since IMPS is based on HTTP, using persistent connections offer significantperformance gains due to the reduced number of connection initiations.

SIMPLE message exchange using session mode is efficient since messages are sent peer-to-peer. The protocol for session mode messaging, MSRP, uses the TCP protocol for trans-port and recommends reusing open connections, thus improving performance in wirelessenvironments. The efficiency of pager mode messaging also depends on the use of persis-tent connections; if connections between SIMPLE clients and SIP proxies can be reused,then messages can be delivered efficiently. In addition to TCP, SIP also supports usingUDP for transportation in which case the bit error rate of the network dictates the per-formance of pager mode messaging. However, since pager mode messages are sent in thelow-bandwidth signaling channel, session mode messages will usually have a lower messageexchange delay.

4.3.3 Processing

As described in Section 3.3.1, the processing and memory constraints of mobile devicesshould be taken into account by mobile services. Both IMPS and SIMPLE offer basic


functionality for restricting the size of a single message in order to prevent clients fromrunning out of memory.

IMPS clients can specify the maximum message size it is able to process in one chunkduring the login procedure. In SIMPLE the MSRP protocol allows sending large messagesin smaller chunks when using session based messaging. For pager mode, instant messagesare restricted to 1300 bytes by the specification.

4.3.4 Coverage Loss

Both the IMPS and the SIMPLE service are able to cope with sudden disconnectionscaused by the loss of radio network coverage. Clients of neither service need to re-loginto the system upon a disconnection, only the transport layer connections need to bereestablished. For session based messaging, SIMPLE clients need to store some informationin order to be able to re-initiate the transport connection upon sudden disconnections,otherwise a new session must be negotiated.

4.3.5 Proxy Traversal

Mobile networks are usually connected to the Internet via NAT proxies. Therefore, theability to communicate through proxies is an important feature of mobile instant messagingservices as it enables a global service, available from both mobile and wireline clients.

IMPS makes use of the CIR channel presented in 4.2.2 in order to traverse proxies. Asall client-server communication is client-initiated and the server can trigger client requestsusing the CIR channel, IMPS clients can use the IMPS service through proxies withoutproblems. The cost of this arrangement is some additional delay to message exchange asdescribed in Section 4.3.2.

Implementations of SIP as specified in [60] have severe problems with NAT traversal.The problem stems from SIP proxies sending replies to ports defined in the SIP requests.RFC 3581 [61] defines a header extension to the SIP protocol solving the problem forTCP. However, the problem persists for UDP connections and all server-initiated requests.Several solutions to the problem have been proposed, including [9] and [63], but it will takelong until a standard solution is available in every SIP proxy. SIMPLE services functionperfectly inside mobile networks, e.g. using IMS in 3G networks, but due to the NATproblems it is currently not possible to create fully functional SIMPLE services spanningboth mobile and wireline networks.

4.3.6 Scalability

By scalability, the system performance when used by a substantial amount of simultaneoususers is meant. Scalability is important as these services are expected to acquire millions


of users over time. The architectures of the two compared services provide excellentscalability. Neither service requires any centralized network elements, enabling data tobe distributed among several servers. By building a network of distributed servers, bothservices can serve a vast amount of simultaneous clients.

4.3.7 Summary

Generally, SIMPLE performs better than IMPS when it comes to optimizing bandwidthusage and delays. IMPS causes no session setup delays, but session mode messagingenables shorter message exchange delays and smaller messages for SIMPLE.

On the other hand, the mechanisms causing delays in message exchange for IMPS alsoenable IMPS messages to traverse NAT proxies without problems. In contrast to IMPS,SIMPLE currently has severe problems with NAT traversal.

The architectures of both services enable good scalability supporting customer bases oflarge scale. The ability to recover from disconnections due to coverage loss is also goodfor both IMPS and SIMPLE.

4.4 Security

This section describes the security services provided by the compared instant messagingsystems and evaluates how well the systems are protected against the security threatslisted in Section 2.8.

4.4.1 Security Services

Authentication

IMPS requires user authentication before access to server functionality can be provided.For user authentication, either a two-way or a four-way access control mechanism canbe used. Using the two-way mechanism, the user sends both the user identifier and thepassword in plain text to the server, which either grants or denies access. The four-waymechanism is a digest authentication based on a challenge sent by the server. The four-waymechanism supports the following digest schemes: SHA (Secure Hash Algorithm), MD4(Message Digest Algorithm #4), MD5 and MD6. Server authentication is provided onlywhen the HTTPS transport binding is used. No mechanisms have been defined explicitlyfor end-to-end authentication of instant messages. However, as any MIME type is allowedfor content of instant messages, end-to-end authentication can be accomplished using e.g.S/MIME (Secure MIME) signatures.

SIMPLE does not enforce clients or servers to be authenticated. However, SIP proxies are


required to support authentication mechanisms and to use them whenever requested. SIPproxies can authenticate clients using a scheme based on the HTTP authentication scheme[26] while clients can utilize TLS (Transport Layer Security) for server authentication. Forend-to-end authentication, e.g. in session mode messaging, S/MIME signatures can beapplied.

Authorization

Both IMPS and SIMPLE allow clients to specify authorization rules for their own presenceinformation. In addition, IMPS lets clients specify access rules for instant messages as well,enabling the server to block messages from unauthorized users.

In IMPS the services to be used are negotiated during the login procedure. Although themain purpose of the service negotiation is to ensure that clients do not request servicesnot supported by the server, it can also be utilized to implement service authorization. InSIMPLE services are not negotiated, therefore service authorization can only be providedusing proprietary solutions.

Accountability

Neither IMPS nor SIMPLE require service elements to create audit trails or logs of transac-tions. Nevertheless, although not enforced by specifications, most server implementationstraditionally come equipped with some level of accountability features.

Confidentiality

For protecting the confidentiality of protocol messages IMPS clients can utilize the HTTPStransport binding, assuring that message content is only interpretable by the local IMPSserver. Strangely, IMPS does not enforce end-to-end confidentiality, i.e. even though aclient sends a message over HTTPS to the server, secure delivery from the server onwardsis not guaranteed.

In SIMPLE, TLS can be used to ensure that only trusted elements can read messages.Using the SIPS addressing scheme described in [60], a SIMPLE client can demand secureconnections to be used along the whole path between the client and the recipient of amessage. For providing end-to-end confidentiality for messaging sessions, encryption usingS/MIME can be utilized if supported by both parties.

Integrity

Message integrity can be ensured in IMPS only when using the HTTPS transport bind-ing and even then the integrity is only guaranteed between the client and the server. In


SIMPLE the SIPS addressing scheme can be used to cause TLS to be used between inter-mediaries, thus providing message integrity. SIMPLE also supports the use of S/MIMEsignatures for end-to-end integrity.

4.4.2 Attack Vulnerability

This subsection evaluates how well IMPS and SIMPLE are able to withstand some of thesecurity threats listed in Section 2.8.

Man-in-the-Middle Attacks

When using two-way authentication in IMPS, an adversary listening to network trafficcan easily learn the password of the user as it is sent in plain text. When using four-way authentication passwords are harder to grab, but as the session identifier assignedto the created session is sent in plain text in each message, hijacking an ongoing sessionis simple. In essence, the HTTPS transport binding is the only mechanism providingadequate protection against man-in-the-middle attacks. Even when HTTPS is used itonly guarantees secure delivery up to the server, an adversary can snatch and modifyinstant messages between the server and the final recipient instead.

SIMPLE specifications do not force server elements to perform authentication of incomingtraffic. Since neglecting authentication allows an adversary to impersonate any otheruser, providing authentication is in practice mandatory for SIMPLE systems. In order toprevent adversaries to read message content, the SIPS addressing format should be used.For end-to-end security the messages can be both encrypted and signed using S/MIME.When all these techniques are in use, SIMPLE provides relatively strong protection againstman-in-the-middle attacks.

Replay Attacks

As TSL includes mechanisms for preventing replay attacks, IMPS users are decently pro-tected against replay attacks while using the HTTPS transport. For other transports,messages can be replayed as long as the session from which the original message wascaptured is still active. Also, two-way authentication can be successfully replayed whilefour-way authentication cannot.

Like IMPS messages, SIMPLE messages are sufficiently protected against replay attackswhen transported over TSL connections. In order to prevent replay attacks SIMPLErequires all signed presence notifications to contain timestamps. Similarly, pager modeinstant messaging obligates the usage of the SIP Date-header to defend against replayattacks.


Denial-of-Service Attacks

Instant messaging systems are especially vulnerable to denial-of-service attacks due to theamplification properties of the presence service; an update of presence information canresult in numerous notifications being sent out.

Although it is never possible to mitigate denial-of-service attacks completely, authenticat-ing incoming requests is one of the most effective means for reducing the probability ofsuch an attack. As mentioned earlier, IMPS requires user authentication and SIMPLEprovides mechanisms for authenticating both client and server requests.

4.4.3 Summary

When using only the minimum required security services, the level of protection providedby both IMPS and SIMPLE is too weak to be used in business-oriented environments orpublic networks. Fortunately, both services include support for stronger security mecha-nisms as well.

Overall, SIMPLE comes equipped with stronger security mechanisms than IMPS but thecomplexity of the SIMPLE architecture can make it difficult to apply strong securitythroughout the whole network. However, the IMS specifications define a security model tobe deployed throughout 3G networks assuring strong security for SIMPLE within mobilenetworks. From the SIMPLE point of view, IMS security services are a combination ofSIMPLE security and 3GPP security. For further information about the IMS securitymodel and 3GPP security, see [53] and [45].

IMPS provides only two security mechanisms, authentication and the HTTPS transportbinding. A server provider can provide a secure service within a closed network by en-forcing the use of both these mechanisms. However, users of the service have no meansto request end-to-end security for messages. Consequently, the service is vulnerable tosecurity breaches in networks without common security policies, such as a global IMPSservice in the Internet.

4.5 Interoperability

The IETF IMPP working group produces standards aiming to provide interoperabilitybetween instant messaging systems. IMPP and the requirements it places on instantmessaging systems for interoperability were described in Section 2.5.1.

SIMPLE does conform to the IMPP specifications in full, facilitating the creation of in-teroperability gateways between SIMPLE and other IMPP compliant instant messagingsystems.

IMPS conforms to all other IMPP requirements except for the PIDF presence format [65].


The lack of PIDF support does not prevent gateways from being created, but the gatewaysneeds to translate the IMPS presence format to the PIDF format and vice versa. Thismeans that presence information cannot be preserved end-to-end, which has implicationsespecially on security since signed or encrypted presence information cannot pass throughgateways.

The OMA Presence & Availability Working Group is currently working on adding PIDFsupport to the presence architecture meaning that IMPS is likely to be fully IMPP-compliant in the future. Furthermore, the OMA Messaging Working Group is in theprocess of defining gateway functionality for connecting IMPS and SIMPLE networkstogether.

4.6 Extensibility

As instant messaging is still a young service, it is subject to changes as instant messagingmatures over the years. Consequently, extensibility is an important characteristic in thecomparison of IMPS and SIMPLE.

IMPS protocols are largely based on the XML format. New transactions and extensions toexisting transactions can easily be added to the protocols using XML Namespaces [10]. Inaddition, all IMPS protocols are version-numbered; a new protocol version can be releasedwhen major changes to existing functionality are needed. In IMPS, protocol versions areusually not backwards compatible, but XML extensions are.

SIMPLE also utilizes the XML format, enabling existing data formats to be extendedeasily. For example, SIMPLE defines several extensions to the XML based PIDF presenceformat. However, in contrast to IMPS which protocols are completely defined in XML,much of the SIMPLE functionality is provided by HTTP-like protocols such as SIP andMSRP. Both SIP and MSRP can be extended with new methods and header fields. In fact,as described in Section 4.2.2 SIMPLE is based upon SIP extensions. SIMPLE protocols,such as MSRP and XCAP, are not versioned which places limits on the amount of changesthat can be made to the protocols.

Finally, when it comes to layer independency IMPS does not depend on underlying proto-cols, making it possible to change the transport binding without affecting IMPS function-ality. SIMPLE on the other hand is tightly coupled with SIP, meaning that all changes tothe SIP protocol might have an impact on SIMPLE as well.

4.7 Current Status and Future Trends

This section presents the current status and future trends of the compared services.


4.7.1 Industry Support

The main founders of IMPS (known as Wireless Village at the time), Ericsson, Motorolaand Nokia are the main forces behind the service. Each of these companies has mobileterminals with IMPS support on the market today. In addition, around 20 companies arecurrently offering IMPS client and server software. No free IMPS solutions have emergedup to date.

As mentioned in Section 2.5.2, SIP and SIMPLE are supported by several major infor-mation technology players, such as Microsoft, IBM and Yahoo. There are numerous com-mercial and free SIP implementations available, a quite comprehensive list can be foundin [31]. Of all SIP implementations around 15 include SIMPLE functionality as well.However, since the SIMPLE specifications are ongoing work, only a few implementationsinclude newer features such as session mode messaging and XCAP.

4.7.2 Service Maturity

Of the two compared services, IMPS is without doubt the more mature. IMPS is readyto be taken into use immediately; several terminals already include IMPS client softwareand IMPS server software is available on the market as well. However, there is a notableshortage of deployed IMPS services. Few network operators provide IMPS services andalthough mobile IMPS clients are able to function with public IMPS servers as well,currently only one public server, Yamigo [72], is known.

As mentioned earlier, parts of the SIMPLE specifications are still ongoing work, e.g. majorchanges were made to the MSRP protocol enabling session mode instant messaging as lateas July 2004. The current deadline for the SIMPLE working group is set at September2004, but work is expected to continue during 2005 as well.

4.7.3 Future Trends

Although IMPS is ready for deployment, network operators have initially been slow tointroduce mobile instant messaging, evidently in the fear of losing SMS revenues. However,due to the superior functionality provided by mobile instant messaging, a few operatorsdeploying instant messaging services will probably force the rest to follow in order to retaintheir customer bases.

As more mobile handsets featuring support for IMPS becomes available, the IMPS servicewill start gaining momentum. Since the deployment of IMS, which enables SIMPLE tobe used in mobile networks, is still a few years away IMPS is expected to attain an earlylead in the mobile instant messaging race.

The introduction of IMS into mobile networks makes SIP and consequently SIMPLE hottopics in the wireless world. As instant messaging based on SIMPLE is part of IMS,


deploying IMS automatically makes the SIMPLE service available to mobile users.

As both standards are interoperable and OMA currently is defining a gateway for con-necting IMPS and SIMPLE together, it is probable that both services will co-exist in thefuture as opposed to one of the services fading away completely.

Chapter 5

Implementation of IMPS CSP

Protocol

As part of this thesis, one protocol of the IMPS service, namely the CSP protocol (ClientServer Protocol) was implemented. The CSP protocol enables communication between anIMPS client and an IMPS server (see Figure 4.1 in Section 4.2). For an overview of theCSP protocol, see Section 4.2.2. Both the client and the server part of the protocol wereimplemented. For the client, the implementation consists of an application programminginterface (API) on which e.g. a client equipped with a user interface can be built. Theserver is a fully functional implementation.

The reason for choosing to implement the CSP protocol of the IMPS service is quiteobvious. A CSP compatible IMPS server can provide a fully functional IMPS service toall CSP compatible clients subscribed to that particular server. Of course, the SSP (ServerServer Protocol) is needed to allow communication between users of separate servers, buta functional service cannot be based on SSP only. The CLP (Command Line Protocol)protocol is based on text messages and supports only a subset of the features supported byCSP. CLP will primarily be used in mobile devices not supporting packet-switched datatransfer; the majority of new mobile devices supporting IMPS will base their clients onthe CSP protocol.

In the time frame of this thesis only one protocol could be implemented and as the CSPprotocol forms the basis of the IMPS service it was chosen. The next logical step after pro-ducing a fully functional CSP implementation would be to implement the SSP protocol,which not only provides inter-domain communication but also enables distributing ser-vices across multiple servers and connecting other instant messaging networks with IMPSthrough gateways.

This section is organized as follows: Section 5.1 presents the requirements of the software.The design of the software is depicted in Section 5.2. The solutions used in the implemen-tation and the problems arising during the implementation phase are described in Section

55

CHAPTER 5. IMPLEMENTATION OF IMPS CSP PROTOCOL 56

5.3.

5.1 Requirements

Version 1.2 of the CSP protocol was chosen for the implementation. Although not yetfinalized, no further changes are expected to version 1.2 before its final release beforethe end of 2004. This section presents the requirements set upon the implementation ingeneral, as well as the requirements imposed by the protocol specifications.

5.1.1 Overall Requirements

To ensure that the implementation would be both easy to use for end-users and simpleto maintain and expand for software developers, a list of high-level requirements wasproduced:

� Extensibility

– Easy addition of unimplemented CSP functionality

– Easy addition of additional transport bindings

– Easy addition of new protocol versions

� Clear, maintainable structure

� Multi-platform support (Windows, Linux, Solaris, ...)

� High performance

As not all features of the CSP protocol were to be implemented (see Section 5.1.2), theability to add missing features to the solution later on was considered important. Since newprotocol versions are under constant development, the solution should also be extensibleenough to allow integration of these into the software.

The structure of the software should not only provide extensibility, a clear structure easyto comprehend for developers new to the solution was also required.

Another requirement was not to restrict the solution to any particular environment, butrather to make sure that the solution is applicable in a broad range of different environ-ments with no or only minor changes.

Finally, as the client library was to perform well in environments with limited resourcesand a scalable server solution was desired as well, the performance aspect of the systemcould not be overlooked. However, the clarity of the design was given a higher priority,thus no performance optimizations decreasing the comprehensiveness of the system wereto be made.


5.1.2 CSP Protocol Requirements

The CSP Static Conformance Requirement document [5] lists the features of the CSPprotocol version 1.2, specifying which features are mandatory to implement and whichare optional. As described in Section 4.2.1, the functionality of the CSP protocol can bedivided into five larger groups (see Table 5.1). Of these groups only the SAP is manda-tory to implement. However, creating a service consisting of only the SAP functionalitywould not be meaningful since this merely provides users with the ability to login andlogout of the service. Therefore more functionality was needed in order to build a usablesystem. However, the time frame of the project also placed constraints on the amount offunctionality that could be included.

Table 5.1: Implemented CSP requirementsFunctionality Requirement Implemented Implemented

sub-elements

Service Access Point Mandatory Yes Mandatory

Instant Messaging Service Ele-ment

Optional Yes Mandatory

Presence Service Element Optional Yes Mandatory + contact list man-agement and updating presenceinformation

Group Service Element Optional No

Content Service Element Optional Yes Mandatory

As the two primary elements of instant messaging are presence information and messageexchange, both the instant messaging service element and the presence service elementwere to be implemented. The shared content service does not require much effort toimplement; therefore it was chosen for implementation as well. As required, all mandatoryelements of the selected service elements were to be implemented. In addition, contact listmanagement and the ability to update presence information, which are optional features ofthe presence service element were also chosen for implementation as these were consideredto be essential parts of a presence service.

5.2 Design

The CSP protocol was described in Section 4.2.2. This section presents the design of theCSP protocol implementation. The tools utilized in the design are described in Section5.2.1. Sections 5.2.2 and 5.2.3 describe the design of the IMPS client and the IMPS server,respectively.


5.2.1 Tools

Unified Modeling Language (UML)

The Unified Modeling Language (UML) is a notational language for specifying, visualizingand documenting models of software. UML is especially suitable for designing object-oriented software. UML was utilized extensively during the design, the entire design ofthe system being documented using UML. Several of the standard diagram types specifiedwithin UML were used, in particular use-case diagrams, package diagrams, class diagramsand sequence diagrams [24].

Microsoft Visio

Microsoft Visio is a tool for creating business and technical diagrams. The tool includessupport for a wide variety of different diagram types, e.g. organizational charts, flowcharts, database models and software program planning. For software program planningVisio supports several UML diagram types, which made it a suitable tool for creating thedesign diagrams of the CSP implementation.

5.2.2 CSP Client

The design of the CSP client library is clarified by the UML class diagram of Figure 5.1.

Figure 5.1: Architecture of the CSP client library


The ImpsClient and CspReceiver classes form the application programming interface(API) that is visible to the end-user of the library. The ImpsClient class provides methodsfor configuring and initializing the client. Client-initiated messages are also sent using theImpsClient class. The CspReceiver class contains callback methods that are invoked whenthe client receives server-initiated CSP messages. CspReceiver contains stubs for the call-back methods; for non-default behavior these methods shall be overridden by applicationsusing the library. The subsections below provide more detailed descriptions of how CSPmessages are sent and received using the CSP client library.

When it comes to the internals of the library, the TransportHandler class is the main con-troller, directing messages to their correct destination class. By having classes implementthe CIRTransport or the Transport interface, support for additional transport bindings forCIR and data channels can easily be added to the client, thus fulfilling the requirementlisted in Section 5.1.1.

Sending CSP Requests

Messages are sent using the sendMessage method of ImpsClient :

CspMessage *sendMessage(const CspMessage &request)

The method takes the CSP request to be sent as an input parameter and returns theresulting CSP response message as a return value. The CspMessage class is the base classfor CSP messages, containing features shared by all CSP messages. All CSP messages aresubclasses of CspMessage as shown in Figure 5.2.

Figure 5.2: CSP message tree


Receiving CSP Requests

The library invokes the callback methods of CspReceiver upon reception of messages ini-tiated by the IMPS server. These callback methods will be handed the incoming messageas the first parameter, while the second parameter contains a response message to be filledby the method.

void handleMessageNotification (const MessageNotification &req, StatusMessage &res)

For example, the implementation of the handleMessageNotification -method above wouldexamine the received message notification and produce a status message to be sent backto the IMPS server.

5.2.3 CSP Server

The architecture of the server is depicted in Figure 5.3, the UML packages representingthe logical components of the system.

Figure 5.3: Server architecture

Table 5.2 below describes the primary tasks of each logical component in brief.


Table 5.2: System component tasksComponent Function

Transport Handles all data sent or received via the network interface over the supportedtransport bindings.

XML Parser Parses raw XML data filling the data into abstract data types derived fromthe CSPMessage class (see Figure 5.2).

CSP Server Controller Links the different components of the system together. Also performs regulartasks, such as cleaning up expired sessions etc.

Validator Validates aspects that are common to all messages, e.g. verifies that thesession identifier of the message is valid.

Transaction Handler Creates and executes Transaction objects performing the actions needed tofulfill each CSP request.

APIs Provides access to the data of the server. For example, all presence subscrip-tions of a particular user can be fetched using the Presence API.

Data Storage Contains the mechanisms needed for storing the permanent data of the system.

Transactions

All logic for fulfilling CSP requests is contained in Transaction objects. Transactionobjects are instances of classes implementing the Transaction interface shown in Figure5.4. The Transaction interface enables the Transaction Handler to create and executea certain CSP transaction based on the type of CSP request. A Transaction objectexamines the received CSP request, carries out the procedures needed to fulfill the requestand creates a CSP response message to be sent back in reply.

Figure 5.4: The Transaction interface

Some CSP transactions endure for several message exchanges between the client and theserver. In this case Transaction objects are stored on the server while waiting for furthermessages from the client. Then the Transaction Handler retrieves and resumes executionof the previously created Transaction object.

In order to clarify the operation of the server, the UML sequence diagram in Figure 5.5shows the flow of control during its primary task, responding to incoming requests.


Figure 5.5: Flow of control for incoming messages

Adding New Functionality

According to the requirements of Section 5.1.1, addition of new transactions to the serverwas made as simple as possible. The process is described below:

1. Creation of abstract data types (CSPMessage) for the messages of the new transac-tion

2. Addition of support for the new messages to the XML parser

3. Creation of a Transaction class for performing the logic related to the transaction

4. Registering the new Transaction with the Transaction Handler

In essence, creating a few classes derived from existing base classes and registering thesewith the server is all that is needed; no changes to the main flow of the server are neededat all.

Similarly, many aspects are hidden behind common interfaces allowing for easy additionand changing of system parts. For example, new transport bindings can be added and thedata storage component can be changed without affecting the rest of the system at all.

5.3 Implementation

This section describes the solutions used and the problems encountered during the imple-mentation of the CSP protocol. First, the tools and libraries utilized in the implementationare presented. Then problems arising in during the implementation phase are discussed.Finally, improvements that could be done in the future are identified.


5.3.1 Programming Language

Both the server and the client library were written in the C++ programming language. Analternative object-oriented language would have been the Java programming language. AsC++ code generally is more efficient and takes less space than Java code, it was consideredmore suitable than Java especially for mobile devices, which are one possible environmentof the CSP client. Furthermore, since there would be quite an amount of shared codebetween the client library and the server it was sensible to implement both using the sameprogramming language.

5.3.2 Tools

Microsoft Visual Studio 6.0

The program code and binaries of the CSP protocol implementations were produced usingthe Microsoft Visual Studio 6.0 application development suite. However, no Windows-specific features were utilized in order to make the code compilable for as many platformsas possible according to the requirements of Section 5.1.1.

5.3.3 Software Libraries

Xerces XML Parser

Version 2.5.0 of the Xerces C++ XML parser was used the produce the XML parsingmodule of the system. The Xerces library provides for both parsing and validation of XMLstructures. As Document Type Definitions (DTD) for the CSP protocol were provided inthe specifications ([2], [4]), Xerces was able to validate incoming XML messages based onthe DTDs, thus reducing the amount of code needed to be written.

The Xerces API provides access to XML data using both SAX (Simple API for XML)and DOM (Document Object Model). Since SAX surpasses DOM when it comes to speedand memory consumption [25], it was seen as the best choice considering that the clientlibrary might be executed in environments with limited resources.

Celtius HTTP API

Celtius HTTP API for C++ is a powerful HTTP library for use in both client and serverapplications. As the library conforms to Wireless Profiled HTTP specifications it is per-fectly applicable in both wireless and wireline environments.

In order to implement the HTTP transport binding of the CSP protocol, the CSP clientlibrary utilizes the HTTP client that is part of the Celtius HTTP API while the CSPserver relies on the HTTP server support included in the same library.


5.3.4 Problems

During the creation process of the CSP protocol no severe problems that would havesuspended the flow of work were encountered. As version 1.2 is the third release of theCSP protocol, most principal elements have been thoroughly reviewed and the protocol israther stable as a whole.

Still, there are some ambiguities in the specifications especially when handling specialcases. For example, management of presence subscriptions in cases where users subscribeor unsubscribe to contact lists is not clearly described in the specifications. Also, recon-necting to a previous session is not defined in an unambiguous fashion. The implementa-tion resolves these uncertainties by applying the solution that appears most reasonable.This does however not guarantee complete interoperability.

Another minor problem was the lack of other implementations against which the imple-mentation could have been tested. IMPS clients are currently available in a few mobiledevices, but these clients are still based on previous versions of the CSP protocol. Fur-thermore, network operators are still to deploy IMPS services and Internet IMPS serverssupporting version 1.2 of the CSP protocol are not available either. The main advantageof testing the software against other implementations of the same protocol would havebeen the ability to resolve the kind of ambiguities mentioned in the previous paragraph.

5.3.5 Future Work

Although the created CSP implementation fulfills most of the mandatory protocol require-ments, much of the optional functionality, such as access control, invitations and usersearch, is not available. Also, the group messaging service element was not implementeddue to the limited time frame of the project. In order to create a richer implementation,these features could be added in the future.

Other possible improvements for the future include the addition of support for new trans-port bindings as well as incorporating support for other versions of the CSP protocol intothe implementation.

Finally, an implementation of the IMPS Server-Server Protocol (SSP) would combinedwith the CSP implementation provide a complete IMPS service.

Chapter 6

Discussion and Conclusions

Section 3.3 presented a number of characteristics of mobile environments that deviatefrom the corresponding characteristics of wireline environments. Two instant messagingsystems, IMPS and SIMPLE, were compared in Chapter 4, the comparison emphasizingthe characteristics of mobile environments. Furthermore, the design and implementationof the IMPS CSP protocol was introduced in Chapter 5. Thus, all the objectives listed inSection 1.1 were fulfilled.

The remainder of this chapter summarizes the results of the comparison and the imple-mentation work in Sections 6.1 and 6.2. Conclusions from the results are drawn in Section6.3. Finally, the significance of the results and future work to be done are considered inSections 6.4 and 6.5.

6.1 Comparison of IMPS and SIMPLE

As IMPS is specifically defined for usage in mobile environments and the IP MultimediaSubsystem (IMS) brings SIMPLE to forthcoming 3G networks, these two services are thetop alternatives for mobile instant messaging.

IMPS is a more mature service than SIMPLE. IMPS version 1.2 is nearly finalized andversion 1.3 is already being defined. SIMPLE has not yet reached standard status andparts of the service are still ongoing work. However, the main elements of SIMPLE areready and the service should be adopted as an IETF standard in 2005.

The functionality of both services is very similar from a user’s point of view, but the tech-niques used to provide the functionality differ considerably between the services. IMPSis based on a rather simple architecture where all client communication passes throughservers. SIMPLE on the other hand is a fairly complex solution which relies on SIP formuch of its functionality but other protocols such as XCAP and MSRP are also utilized.The fact that SIMPLE provides two completely different messaging modes, pager mode

65

CHAPTER 6. DISCUSSION AND CONCLUSIONS 66

and session mode, only adds to the complexity. Despite their differences, both architec-tures allow for excellent scalability as functionality and users can be distributed among amultitude of servers.

Both services utilize techniques for optimizing the performance in mobile environments.Overall, SIMPLE is slightly more efficient than IMPS when it comes to bandwidth usageand delays. Performance-wise, the most notable flaw in SIMPLE is the inability to traverseproxies. This affects the applicability of the service since a global service cannot be created.IMPS is able to handle proxy traversal without problems.

SIMPLE includes mechanisms for providing the service with relatively strong security.Due to the complexity of the SIMPLE architecture, applying an even level of securitythroughout a network requires a great deal of cooperation between network administrators.IMPS provides sufficient security only between the client and its local server, end-to-endsecurity can not be requested by clients and is therefore not guaranteed in all networks.

Since the IMPS protocols are completely based on XML and function on top of several dif-ferent transport bindings, IMPS qualifies as an extensible and flexible solution. SIMPLEalso utilizes the XML format, but the tight coupling with the SIP protocol reduces flexi-bility to an extent.

Finally, both services are built based on the requirements formulated by the IMPP workinggroup, thus enabling good interoperability with other instant messaging systems. However,IMPS does not support the PIDF presence format, whereas SIMPLE is fully compliantwith IMPP.

6.2 Implementation of IMPS CSP protocol

The implementation of the CSP protocol of the IMPS service was successfully completedaccording to the plan and the requirements set upon the implementation were fulfilled.Minor problems were caused by ambiguities in the specifications. In addition, the lack ofother similar implementations complicated interoperability testing slightly.

6.3 Conclusions

Tables 6.1 and 6.2 list the main advantages and disadvantages of the compared services.The rest of this section presents the conclusions drawn from the results of the comparison.


Table 6.1: Advantages and disadvantages of IMPSAdvantages Disadvantages

Simple architecture Security

Scalability Lack of charging protocol

Extensibility

Proxy traversal

Table 6.2: Advantages and disadvantages of SIMPLEAdvantages Disadvantages

Scalability Complex architecture

Interoperability Tightly coupled with SIP

Security Proxy traversal

Efficiency

IMPS is a simple solution that is easy to deploy

The simple architecture of IMPS makes it possible for service providers to take the ser-vice into use without great efforts. In the simplest case, the service provider only needs todeploy one IMPS server. By updating the server with addresses of other servers, communi-cation between users of different service providers or distributed services can be enabled.As a range of different bearers can be used to access the IMPS service, most serviceproviders already have the infrastructure needed to deploy the service. IMPS lacks charg-ing functionality; if service providers intend to charge per sent message, then a proprietarysolution must be utilized.

SIMPLE is a complex solution that requires effort to deploy

As opposed to IMPS, the architecture of SIMPLE consists of several distinct elementscommunicating using numerous different protocols and data formats. This alone makesdeploying SIMPLE far from effortless. In addition, a functioning SIP network is neededas a prerequisite for building a SIMPLE service. The SIP-based IMS standard bringsmultimedia services, including SIMPLE, to 3G networks. IMS also includes chargingfunctionality which enables service providers to choose from different charging schemes forinstant messaging. Although deploying IMS and SIMPLE requires resources from serviceproviders, the amount of new services enabled by IMS should pay back the effort overtime.


SIMPLE provides the performance and security needed for business-oriented

services

The combination of SIP and peer-to-peer messaging provides SIMPLE with good per-formance considering the demands related to mobile instant messaging services. Bothbandwidth usage and messaging delay can be optimized for usage in mobile environments.Additionally, security issues have not been neglected in the design of SIMPLE. All proto-cols used in SIMPLE come equipped with security mechanisms strong enough to eliminatemost security threats. All in all, the level of performance and security is high enough forusing SIMPLE for business-oriented services.

IMPS lacks in security

Although the performance of IMPS in mobile environments is up to par with the require-ments for mobile environments, IMPS fails to meet some expectations when it comes tosecurity. A service provider can create a secure service in a closed network by havingall servers accept only secure connections. However, in larger networks with no commonsecurity policy, end-to-end security cannot be guaranteed. In such networks, a mechanismallowing clients to request that a message should be rejected in case it cannot be deliveredsecurely would be needed. Unfortunately, IMPS lacks this kind of mechanism.

IMPS can be used to implement a global service spanning both wireline and

wireless networks

IMPS includes mechanisms allowing servers to communicate with clients even if the two areseparated by a proxy. Although the solution for proxy traversal adds some extra delay toserver initiated messages, the advantage of the solution easily outweighs the disadvantages.While most mobile clients and many fixed PC clients are connected to the Internet throughproxies, the proxy traversal ability of IMPS makes communication between them possible.This enables creating a global service on the Internet, to which users can connect usingboth mobile and fixed clients.

SIMPLE has problems traversing proxies

SIMPLE has severe problems traversing proxies. The difficulties are caused both by theSIP protocol and by peer-to-peer sessions. Several independent solutions to the problemhave been proposed, all adding to the complexity of the service. So far no solutions forsolving the problem completely and efficiently have been standardized. SIMPLE functionswell inside mobile networks or intranets, but connecting mobile network users with Internetusers is currently not possible.


Both IMPS and SIMPLE are applicable in mobile environments

All in all, the comparison confirmed that IMPS and SIMPLE conform to the requirementsset forth by mobile environments. Both IMPS and SIMPLE feature numerous optimiza-tions for improving the suitability of the services in mobile environments. Of course, bothservices have their strengths and weaknesses, against which own requirements should becompared before selecting a mobile instant messaging solution.

6.4 Significance of the Results

This thesis strives to bring new information to the domain of mobile services by studyingthe limitations placed on mobile services and by evaluating the applicability of two mobileinstant messaging services with these limitations in mind. Although one service could notbe declared superior to the other, this thesis provides an overview of the advantages anddisadvantages of both services and an assessment of the applicability of the services inmobile networks.

6.5 Future Work

As the functionality of the next version of IMPS is already being defined and many partsof the SIMPLE specifications are not finalized, updates and improvements will be madeto both the compared services in the future. These changes can affect the validity of theresults of the comparison. Therefore, the comparison should be kept up to date as theservices evolve.

As the comparison was carried out on a theoretical basis, performing tests in real mobilenetworks would also be of interest in the future.

Furthermore, the implementation of the IMPS CSP protocol could be broadened to includemore functionality, such as access control and group messaging.

Bibliography

[1] Open Mobile Alliance. Client-Server Protocol Binary Definition and Example,Version 1.2, February 2003. Available at: http://member.openmobilealliance.

org/ftp/public documents/MWG/IM/Permanent documents/OMA-IMPS-WV-CSP

WBXML-V1 2-20030221-C.zip [referred to 30.8.2004].

[2] Open Mobile Alliance. Presence Attribute DTD and Examples, Version 1.2,February 2003. Available at: http://member.openmobilealliance.org/ftp/

public documents/mwg/IM/Permanent documents/OMA-IMPS-WV-CSP PA DTD-V1

2-20030221-C.zip [referred to 30.8.2004].

[3] Open Mobile Alliance. Server-Server Protocol Semantics Document, Candidate Ver-sion 1.2, February 2003. Available at: http://member.openmobilealliance.org/

ftp/public documents/MWG/IM/Permanent documents/OMA-IMPS-WV-SSP-V1

2-20030221-C.zip [referred to 30.8.2004].

[4] Open Mobile Alliance. Client-Server Protocol DTD and Examples, CandidateVersion 1.2, March 2004. Available at: http://member.openmobilealliance.org/

ftp/public documents/mwg/IM/Permanent documents/OMA-IMPS-WV-CSP DTD-V1

2-20040317-C.zip [referred to 30.8.2004].

[5] Open Mobile Alliance. Client-Server Protocol Static Conformance Re-quirement, Candidate Version 1.2, March 2004. Available at: http:

//member.openmobilealliance.org/ftp/public documents/mwg/IM/

Permanent documents/OMA-IMPS-WV-SSP SCR-V1 2-20040427-C.zip [referredto 30.8.2004].

[6] Open Mobile Alliance. System Architecture Model, Candidate Version 1.2, May 2004.

[7] D. Atkins and G. Klyne. Common Presence and Instant Messaging (CPIM): MessageFormat (RFC 3862). The Internet Society, August 2004.

[8] AT&T. Getting The Most From Your Favourite Gizmo ... The Telephone, May 2004.Available at: http://www.att.com/news/item/0,1847,13059,00.html [referred to30.8.2004].

70

http://member.openmobilealliance.org/ftp/public_documents/MWG/IM/Permanent_documents/OMA-IMPS-WV-CSP_WBXML-V1_2-20030221-C.zip



http://member.openmobilealliance.org/ftp/public_documents/mwg/IM/Permanent_documents/OMA-IMPS-WV-CSP_PA_DTD-V1_2-20030221-C.zip



http://member.openmobilealliance.org/ftp/public_documents/MWG/IM/Permanent_documents/OMA-IMPS-WV-SSP-V1_2-20030221-C.zip



http://member.openmobilealliance.org/ftp/public_documents/mwg/IM/Permanent_documents/OMA-IMPS-WV-CSP_DTD-V1_2-20040317-C.zip



http://member.openmobilealliance.org/ftp/public_documents/mwg/IM/Permanent_documents/OMA-IMPS-WV-SSP_SCR-V1_2-20040427-C.zip



http://www.att.com/news/item/0,1847,13059,00.html

BIBLIOGRAPHY 71

[9] G. Bajko, B. Bertenyi, and K. Kiss. Multimedia Sessions Between 3G Wireless andInternet Users. In IEEE International Conference on Communications, 2001, pages435–439, June 2001.

[10] T. Bray, D. Hollander, A. Layman, and R. Tobin. Namespaces in XML 1.1. WorldWide Web Consortium, February 2004. Available at: http://www.w3.org/TR/

xml-names11/.

[11] S. Buckingham. Data on MMS. Mobile Lifestreams, November 2001.

[12] G. Camarillo. Compressing the Session Initiation Protocol (SIP) (RFC 3486). TheInternet Society, February 2003.

[13] B. Campbell, R. Mahy, and C. Jennings. The Message Session RelayProtocol. Internet draft, Internet Engineering Task Force, August 2004.Work in progress, Available at: http://www.ietf.org/internet-drafts/

draft-ietf-simple-message-sessions-08.txt [referred to 30.8.2004].

[14] B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, and D. Gurle. SessionInitiation Protocol (SIP) Extension for Instant Messaging (RFC 3428). The InternetSociety, December 2002.

[15] I. Chlamtac and J. Redi. Mobile Computing: Challenges and Potential. InEncyclopedia of Computer Science, 4th Edition. International Thomson Publish-ing, 1998. Available at: http://www.jasonredi.com/papers/mobile computing

summary distrib.pdf [referred to 30.8.2004].

[16] The Jabber Community. Brief chronology of activity related to Jabber and XMPP inthe IETF standards process. Available at: http://www.jabber.org/ietf/history.php [referred to 30.8.2004].

[17] The Jabber Community. The Instant Messaging Standards Race: ComparingXMPP/Jabber and SIP/SIMPLE, May 2003.

[18] International Engineering Consortium. Instant Messaging. Available at: http://

www.iec.org/online/tutorials/instant msg/ [referred to 30.8.2004].

[19] M. Day, S. Aggarwal, G. Mohr, and J. Vincent. Instant Messaging / Presence ProtocolRequirements (RFC 2779). The Internet Society, February 2000.

[20] M. Day, J. Rosenberg, and H. Sugano. A Model for Presence and Instant Messaging(RFC 2778). The Internet Society, February 2000.

[21] H. Elaarag. Improving TCP Performance over Mobile Networks. ACM ComputingSurveys, 34(3):357–374, September 2002. ACM Press.

http://www.w3.org/TR/xml-names11/

http://www.w3.org/TR/xml-names11/

http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-08.txt

http://www.ietf.org/internet-drafts/draft-ietf-simple-message-sessions-08.txt

http://www.jasonredi.com/papers/mobile_computing_summary_distrib.pdf

http://www.jasonredi.com/papers/mobile_computing_summary_distrib.pdf

http://www.jabber.org/ietf/history.php

http://www.jabber.org/ietf/history.php

http://www.iec.org/online/tutorials/instant_msg/

http://www.iec.org/online/tutorials/instant_msg/

BIBLIOGRAPHY 72

[22] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, Masinter L., P. Leach, and T. Berners-Lee. Hypertext Transfer Protocol – HTTP/1.1 (RFC 2616). The Internet Society,June 1999.

[23] G.H. Forman and J. Zahorjan. The Challenges of Mobile Computing. Computer,27(4):38–47, 1994.

[24] M. Fowler. UML Distilled: A Brief Guide to the Standard Object Modeling Language.Addison-Wesley Longman Publishing Co., Inc., 2003.

[25] S. Franklin. XML Parsers: DOM and SAX Put to the Test, February 2001. Availableat: http://www.devx.com/xml/Article/16922/0/page/1 [referred to 30.8.2004].

[26] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, andL. Stewart. HTTP Authentication: Basic and Digest Access Authentication (RFC2617). The Internet Society, June 1999.

[27] D. Greene and D. O’Mahony. Instant Messaging & Presence Management in MobileAd-Hoc Networks. In Second IEEE Annual Conference on Pervasive Computing andCommunications Workshops, pages 55–59, March 2004.

[28] A. Gurtov. Making TCP Robust Against Delay Spikes. Technical Report Seriesof Publications C, No C-2001-53, University of Helsinki, Department of ComputerScience, November 2001.

[29] N. Hindocha. Threats to Instant Messaging. Technical report, Symantec Secu-rity Response, October 2002. Available at: http://www.symantec.com/avcenter/

reference/threats.to.instant.messaging.pdf [referred to 30.8.2004].

[30] H. Inamura (Editor), G. Montenegro (Editor), R. Ludwig, A. Gurtov, and S. Khafizov.TCP Over Second (2.5G) and Third (3G) Generation Wireless networks (RFC 3481).The Internet Society, February 2003.

[31] iptel.org. SIP Products. Available at: http://www.iptel.org/info/products/

[referred to 30.8.2004].

[32] M. Isomaki and E. Leppanen. An Extensible Markup Language (XML) Con-figuration Access Protocol (XCAP) Usage for Manipulating Presence Docu-ment Contents. Internet draft, Internet Engineering Task Force, June 2004.Work in progress, Available at: http://www.ietf.org/internet-drafts/

draft-ietf-simple-xcap-pidf-manipulation-usage-01.txt [referred to30.8.2004].

[33] V. Jacobson, R. Braden, and D. Borman. TCP Extension for High Performance(RFC 1323). The Internet Society, May 1992.

http://www.devx.com/xml/Article/16922/0/page/1

http://www.symantec.com/avcenter/reference/threats.to.instant.messaging.pdf

http://www.symantec.com/avcenter/reference/threats.to.instant.messaging.pdf

http://www.iptel.org/info/products/

http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-pidf-manipulation-usage-01.txt

http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-pidf-manipulation-usage-01.txt

BIBLIOGRAPHY 73

[34] C. Jennings and R. Mahy. Relay Extensions for Message Sessions Re-lay Protocol (MSRP). Internet draft, Internet Engineering Task Force, July2004. Work in progress, Available at: http://www.ietf.org/internet-drafts/

draft-ietf-simple-msrp-relays-01.txt [referred to 30.8.2004].

[35] Y. Kohda, H. Sugano, and S. Okuyama. IMPP: A New Instant Messaging Standardand Its Impact on Internet Business. Fujitsu Scientific & Technical Journal: Informa-tion Technologies in the Internet Era, 36(2):147–153, December 2000. Available at:http://magazine.fujitsu.com/us/vol36-2/paper06.pdf [referred to 30.8.2004].

[36] T.V. Lakshman and U. Madhow. The Performance of TCP/IP for Networks withHigh Bandwidth-Delay Products and Random Loss. IEEE/ACM Transactions onNetworking, 5(3):336–350, June 1997. ACM Press.

[37] S. Leggio, T. Kulve, O. Riva, and M. Kojo. An Analysis of Instant Messaging andE-mail Access Protocol Behaviour in Wireless Environments. Technical report, Uni-versity of Helsinki, Department of Computer Science, March 2004.

[38] T. Louis. AIM Still Not Secure. Planet IT, February 2001. Available at: http:

//www.tnl.net/who/bibliography/aimsecurity/ [referred to 30.8.2004].

[39] H. Lundgren, R. Gold, E. Nordstrom, and M. Wiggberg. A Distributed Instant Mes-saging Architecture based on the Pastry Peer-To-Peer Routing Substrate. Technicalreport, Uppsala University of Sweden, 2003. Available at: http://winternet.sics.se/workshops/sncnw2003/proceedings/18T-sncnw.pdf [referred to 30.8.2004].

[40] M. Mitsuoka, S. Watanabe, J. Kakuta, and S. Okuyama. Instant Messaging with Mo-bile Phones to Support Awareness. In Symposium on Applications and the Internet,pages 223–230, January 2001.

[41] MobileIN.com. Mobile Instant Messaging. Available at: http://www.mobilein.com/MIM.htm [referred to 30.8.2004].

[42] P. Nguyen. Instant Messaging technology for the business market: Do the advantagesoutweigh the risks? Technical report, SANS Institute, November 2003. Availableat: http://www.giac.org/practical/GSEC/Phuong Nguyen GSEC.pdf [referred to30.8.2004].

[43] P. Nicholls. Short Message Service Long on Possibilities. Available at: http://www.klixxx.com/archive/smssolution.shtml [referred to 30.8.2004].

[44] J. Nielsen. IM, Not IP (Information Pollution). ACM Queue, 1(8):75–76, November2003.

[45] V. Niemi and K. Nyberg. UMTS Security. John Wiley & Sons, December 2003.

http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-relays-01.txt

http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-relays-01.txt

http://magazine.fujitsu.com/us/vol36-2/paper06.pdf

http://www.tnl.net/who/bibliography/aimsecurity/

http://www.tnl.net/who/bibliography/aimsecurity/

http://winternet.sics.se/workshops/sncnw2003/proceedings/18T-sncnw.pdf

http://winternet.sics.se/workshops/sncnw2003/proceedings/18T-sncnw.pdf

http://www.mobilein.com/MIM.htm

http://www.mobilein.com/MIM.htm

http://www.giac.org/practical/GSEC/Phuong_Nguyen_GSEC.pdf

http://www.klixxx.com/archive/smssolution.shtml

http://www.klixxx.com/archive/smssolution.shtml

BIBLIOGRAPHY 74

[46] M. Nordberg, H. Hannu, J. Christoffersson, and L. Zaccomer. Improving SigCompperformance through Extended Operations. In Vehicular Technology Conference,2003, pages 3425–3428, October 2003.

[47] V. Pai and P. Rana. A Transparent Framework for Enabling Incoming TCP Connec-tions to Host Behind a NAT Gateway. In Computer Communications and Networks,2003, pages 572–575, October 2003.

[48] R. Parvianen and P. Parnes. Mobile Instant Messaging. In 10th International Con-ference on Telecommunications, pages 425–430, 2003.

[49] C.E. Perkins. Mobile networking in the Internet. Mobile Networks and Applications,3(4):319–334, 1999. ACM Press.

[50] J. Peterson. Common Profile for Instant Messaging (CPIM) (RFC 3860). The In-ternet Society, August 2004.

[51] J. Peterson. Common Profile for Presence (CPP) (RFC 3859). The Internet Society,August 2004.

[52] E. Pitoura and B. Bhargava. Dealing With Mobility: Issues and Research Challenges.Technical report, Department of Computer Science, Purdue University, US, November1993.

[53] M. Poikselka, G. Mayer, H. Kharatabil, and A. Niemi. The IMS: IP MultimediaConcepts and Services in the Mobile Domain. John Wiley & Sons, June 2004.

[54] R. Price, C. Bormann, J. Christoffersson, H. Hannu, Z. Liu, and J. Rosenberg. Sig-naling Compression (SigComp) (RFC 3320). The Internet Society, January 2003.

[55] A. Quintana, J. Ramsinghani, and T. Walls. Peer-to-Peer Computing: The Searchfor Viable Business Models. Technical report, Kellogg Tech Ventures, 2001. Avail-able at: http://www.ranjaygulati.com/new/research/PEER-TO.pdf [referred to30.8.2004].

[56] A. B. Roach. Session Initiation Protocol (SIP) - Specific Event Notification (RFC3265). The Internet Society, June 2002.

[57] J. Rosenberg. The Session Initiation Protocol (SIP) UPDATE Method (RFC 3311).The Internet Society, September 2002.

[58] J. Rosenberg. A Presence Event Package for the Session Initiation Protocol (SIP)(RFC 3856). The Internet Society, August 2004.

[59] J. Rosenberg. The Extensible Markup Language (XML) Configuration Ac-cess Protocol (XCAP). Internet draft, Internet Engineering Task Force, July2004. Work in progress, Available at: http://www.ietf.org/internet-drafts/

draft-ietf-simple-xcap-03.txt [referred to 30.8.2004].

http://www.ranjaygulati.com/new/research/PEER-TO.pdf

http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-03.txt

http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-03.txt

BIBLIOGRAPHY 75

[60] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks,M. Handley, and E. Schooler. SIP: Session Initiation Protocol (RFC 3261). TheInternet Society, June 2002.

[61] J. Rosenberg and M. Schulzrinne. An Extension to the Session Initiation Protocol(SIP) for Symmetric Response Routing (RFC 3581. The Internet Society, August2003.

[62] R. Sparks. The Session Initiation Protocol (SIP) Refer Method (RFC 3515). TheInternet Society, April 2003.

[63] B. Sterman and D. Schwartz. NAT Traversal in SIP, 2001. Available at:http://corp.deltathree.com/technology/nattraversalinsip.pdf [referred to30.8.2004].

[64] J. Stone and S. Merrion. Instant Messaging or Instant Headache? ACM Queue,2(2):72–80, April 2004.

[65] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, and J. Peterson. PresenceInformation Data Format (PIDF) (RFC 3863). The Internet Society, August 2004.

[66] E. Sutherland. Wireless telecommunications: value and mobility. Technical report,Indian Institute of Technology, 2002.

[67] techiwarehouse.com. Instant Messaging. Available at: http://www.

techiwarehouse.com/Articles/2003-05-12.html [referred to 30.8.2004], May2003.

[68] Y. Vogiazou. Wireless Presence and Instant Messaging. Technical report, KnowledgeMedia Institute, November 2002.

[69] Webopedia.com. Online Encyclopedia dedicated to computer technology. Availableat: http://www.webopedia.com.

[70] Whatis.com. Available at: http://www.whatis.com.

[71] R.L. Wickham (Editor-in Chief). SMS: Europe’s Smash Hit. Wireless Review, Avail-able at: http://wirelessreview.com/ar/wireless sms europes smash/ [referredto 30.8.2004], March 2001.

[72] Yamigo.com. It’s a Wireless Village. Available at: http://www.yamigo.com/.

http://corp.deltathree.com/technology/nattraversalinsip.pdf

http://www.techiwarehouse.com/Articles/2003-05-12.html

http://www.techiwarehouse.com/Articles/2003-05-12.html

http://www.webopedia.com

http://www.whatis.com

http://wirelessreview.com/ar/wireless_sms_europes_smash/

http://www.yamigo.com/

Appendix A

Message Flow Examples

SIMPLE

Session Mode Messaging

Alice → atlanta.com proxy

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

Max-Forwards: 70

To: Bob <sip:[email protected]>

From: Alice <sip:[email protected]>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Contact: <sip:[email protected]>

Content-Type: application/sdp

Content-Length: 179

v=0

o=alice 2890844557 2890844559 IN IP4 pc33.example.com

s=

c=IN IP4 pc33.atlanta.com

76

APPENDIX A. MESSAGE FLOW EXAMPLES 77

t=0 0

m=message 9 msrp *

a=accept-types:text/plain

a=path:msrp://pc33.atlanta.com:7777/iau39;tcp

atlanta.com proxy → Alice

SIP/2.0 100 Trying

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1

To: Bob <sip:[email protected]>



CSeq: 314159 INVITE

Content-Length: 0


SIP/2.0 200 OK

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1

To: Bob <sip:[email protected]>;tag=a6c85cf



CSeq: 314159 INVITE

Contact: <sip:[email protected]>

Content-Type: application/sdp

Content-Length: 182

v=0

o=bob 2890844612 2890844616 IN IP4 bobpc.biloxi.com

s=

c=IN IP4 bobpc.biloxi.com

t=0 0

m=message 9 msrp *

a=accept-types:text/plain

a=path:msrp://bobpc.biloxi.com:8888/9di4ea;tcp

Alice → Bob

ACK sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9

Max-Forwards: 70

To: Bob <sip:[email protected]>;tag=a6c85cf



CSeq: 314159 ACK

Content-Length: 0

Alice → Bob

MSRP d93kswow SEND

To-Path:msrp://bobpc.biloxi.com:8888/9di4ea;tcp

From-Path:msrp://pc33.atlanta.com:7777/iau39;tcp

Message-ID: 12339sdqwer

Content-Type:text/plain

Hi, I’m Alice!

-------d93kswow$


Bob → Alice

MSRP d93kswow 200 OK

To-Path:msrp://bobpc.biloxi.com:8888/9di4ea;tcp

From-Path:msrp://pc33.atalanta.com:7777/iau39;tcp

-------d93kswow$

Bob → Alice

BYE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10

Max-Forwards: 70

From: Bob <sip:[email protected]>;tag=a6c85cf

To: Alice <sip:[email protected]>;tag=1928301774


CSeq: 231 BYE

Content-Length: 0

Alice → Bob

SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10

From: Bob <sip:[email protected]>;tag=a6c85cf

To: Alice <sip:[email protected]>;tag=1928301774


CSeq: 231 BYE

Content-Length: 0

Pager Mode Messaging

Alice → atlanta.com proxy

MESSAGE sip:[email protected] SIP/2.0

Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776sgdkse

Max-Forwards: 70

From: sip:[email protected];tag=49583

To: sip:[email protected]

Call-ID: [email protected]

CSeq: 1 MESSAGE

Content-Type: text/plain

Content-Length: 14

Hi, I’m Alice!



SIP/2.0 200 OK

Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK776sgdkse; received=1.2.3.4

From: sip:[email protected];;tag=49394

To: sip:[email protected];tag=ab8asdasd9

Call-ID: [email protected]

CSeq: 1 MESSAGE

Content-Length: 0

IMPS

Messaging

Alice → IMPS server

POST /wv/ HTTP/1.1

Host: imps.atlanta.com

Content-Length: 949

Content-Type: application/vnd.wv.csp.xml

<WV-CSP-Message xmlns="http://www.openmobilealliance.org/DTD/WV-CSP1.2">

<Session>

<SessionDescriptor>

<SessionType>Inband</SessionType>

<SessionID>pc33.atlanta.com#48815atlanta.com</SessionID>

</SessionDescriptor>

<Transaction>

<TransactionDescriptor>

<TransactionMode>Request</TransactionMode>

<TransactionID>IMApp01#12345@NOK5110</TransactionID>

</TransactionDescriptor>

<TransactionContent xmlns="http://www.openmobilealliance.org/DTD/WV-TRC1.2">

<SendMessage-Request>

<DeliveryReport>F</DeliveryReport>

<MessageInfo>

<ContentType>text/plain</ContentType>

<ContentEncoding>None</ContentEncoding>

<ContentSize>58</ContentSize>

<Recipient>

<User>

<UserID>wv:[email protected]</UserID>

</User>

</Recipient>

<Sender>


<User>

<UserID>wv:[email protected]</UserID>

</User>

</Sender>

<Validity>600</Validity>

</MessageInfo>

<ContentData>Hi, I’m Alice!</ContentData>

</SendMessage-Request>

</TransactionContent>

</Transaction>

</Session>

</WV-CSP-Message>

IMPS server → Alice

HTTP/1.1 200 OK

Date: Sat, 21 Aug 2004 07:40:27 GMT

Content-Length: 702

Content-Type: application/vnd.wv.csp.xml

<WV-CSP-Message xmlns="http://www.openmobilealliance.org/DTD/WV-CSP1.2">

<Session>

<SessionDescriptor>

<SessionType>Inband</SessionType>

<SessionID>pc33.atlanta.com#[email protected]</SessionID>

</SessionDescriptor>

<Transaction>

<TransactionDescriptor>

<TransactionMode>Response</TransactionMode>

<TransactionID>IMApp01#12345@NOK5110</TransactionID>

</TransactionDescriptor>

<TransactionContent xmlns="http://www.openmobilealliance.org/DTD/WV-TRC1.2">

<SendMessage-Response>

<Result>

<Code>200</Code>

<Description>Successfully completed.</Description>

</Result>

<MessageID>0x0000f132</MessageID>

</SendMessage-Response>

</TransactionContent>

</Transaction>

<Poll>F</Poll>

</Session>

</WV-CSP-Message>

Mobile Instant Messaging Systems - A Comparative Study and ... · Detta arbete unders¨oker hur v...

Documents

Transcript of Mobile Instant Messaging Systems - A Comparative Study and ... · Detta arbete unders¨oker hur v...