• OMA IMPS (Previously Wireless Village)

Sponsored Links

  • FileName: OMA_IMPS.pdf [preview-online]
    • Abstract: IMPS specifically on mobile devices. There are currently close to two billion mobile ... level architecture of OMA IMPS. Immediately apparent from the high ...

Download the ebook

OMA IMPS – a paper for Instant Messaging and Presence-seminar, University of Helsinki, 2005 1
(Previously Wireless Village)
Sami I Mäkeläinen, Martin Peter Michael
Presence is the availability and other status information of
Abstract— Instant messaging and presence-systems have long any person, application, or device to exchange information
been popular in the “fixed” Internet world with tens of millions with any other person, application, or device. The power of
of PC users. The success has come despite the heterogeneous presence is that it promises to make communication more
environment of multiple incompatible IM systems. In the mobile natural and flexible; ideally, people would know beforehand
domain, however, instant messaging and presence is a relatively
what is the most appropriate way to get in touch with their
young thing. Hoping to avoid fragmentation in mobile IM and
presence, Wireless Village was formed by key industry players to
contacts and when they are available for a chat.
define a standard system for mobile IM and presence. The Instant messaging is the act of sending messages to
purpose of this paper is to introduce the Wireless Village recipients and delivering them more or less instantly, without
initiative currently residing in the Open Mobile Alliance (OMA), the need for the recipient to specifically fetch the messages.
it’s overall architecture, protocols and real life usage. Combining presence, instant messaging and mobility that can
be used anytime and anywhere enables powerful
Index Terms— instant messaging, presence, OMA, IMPS, communications possibilities. It opens up new business
Wireless Village, WV, chat, mobile IM, mobile presence opportunities as well as creates multiple new services in the
mobile communication domain. Not only can mobile users
I. INTRODUCTION communicate with other mobile users but also with users
using PCs, PDAs and other devices.
I nstant Messaging services have been provided in the
Internet by various vendors for a number of years. These
services have proven to be extremely popular among PC
The Wireless Village initiative was formed by a set of
major independent companies in the communication
users during the last decade. As Internet access became more technology area: Ericcson, Motorola and Nokia [4]. The
widely available from mobile devices and capable phones Wireless Village defines a set of specifications for instant
increased in numbers, there arose a need to define a common messaging and presence. The standard enables interoperability
set of standards for how Instant Messaging and Presence of mobile instant messaging and presence services by defining
Services (IMPS) would be available from mobile devices. The open standards for the different vendors to abide by. It is
ideal common standard would be agnostic of the device aimed to be a powerful catalyst for promoting a universal
manufacturer, device type, geographic location, the standard for mobile instant messaging and presence services.
underlying mobile communication technology and the type of It also specifically aims to overcome the limitation of using
software needed. A commonly accepted standard would specific proprietary chat technologies like Yahoo!, MSN
prevent marketplace fragmentation, which would lead to Messenger, ICN, Skype etc by opening a well-defined way for
multiple incompatible systems. Due to the difficulty of
cross-system interoperability.
software updates on mobile devices, this problem is especially
In this paper, the terms OMA IMPS and Wireless Village
severe in the mobile device domain. Wireless Village attempts
to solve this problem by defining a set of specifications for are used interchangeably. This is due to the fact that while the
IMPS specifically on mobile devices. name of the standardization effort has relocated to OMA
There are currently close to two billion mobile users in the IMPS, some elements in the architecture and specifications
world and it’s estimated that within a few years, more people still bear the Wireless Village name.
will be connected to the Internet using their mobile phone than
a PC. Lately it has become apparent that the way of II. HISTORY & CURRENT STATUS OF THE INITIATIVE
communication itself is changing on mobile devices. Instead The Instant Messaging and Presence services have become
of just plain voice communication or text messages, there is widely available in the Internet during the last decade. PC
growing interest in the importance of presence information users with Internet connections have been enjoying the
and the possibilities of instant messaging on mobile devices different services providing ever-increasing number of
[6]. features for a number of years. In the Internet, there was also a
bitter fact that none of the service providers agreed to work
This is a seminar paper for the Instant Messaging and Presence-seminar held together to provide an interoperable solution. Despite this,
at the department of Computer Science at the University of Helsinki in the fall several of the services were successful. However, mobile
of 2005. The authors are MSc students at the department of Computer Science devices were completely shut out of the Internet IM systems
at the University of Helsinki.
OMA IMPS – a paper for Instant Messaging and Presence-seminar, University of Helsinki, 2005 2
for a long time. The closest thing to IM in the mobile world III. ARCHITECTURE
was the widespread use of SMS (Short Message Service) This chapter provides an overview of the OMA IMPS
messages. The perceptions of the mobile devices have since architecture and the protocols used. The reader is assumed to
changed from simple mobile phones that could only be used to be familiar with the basics of 2.5G and 3G mobile packet data
make phone calls to powerful minicomputers. Applications networks as well as the most common protocols and standards
unimaginable only five years ago are now standard on many used in the Internet.
However, the problem that existed on the fixed side came A. Overview
true for the mobile side as well. There were various The conceptual high-level diagram of the solution can be
manufacturers of devices, proprietary software technologies, seen from the following diagram. In the diagram, all radio and
access technologies etc. that brought even more headache for core network components of the mobile network such as
the instant messaging and presence services to resolve. The SGSNs, GGSNs and others have been omitted for simplicity.
lack of interoperability between the various systems was not The OMA IMPS server is usually hosted by the mobile
limited to IMPS area but also existed in other areas of mobile operator.
The Open Mobile Alliance (OMA) was formed in 2002 for
solving these kinds of technical issues related to mobile
services. OMA defines open specifications for the mobile
Mobile operator
industry , helping to create interoperable service enablers.
H H H packet core network
There are now approximately 400 companies participating in OMA IMPS
the OMA work. These include major players in the mobile
industries like Nokia, Cingular, Ericsson, Qualcomm,
Vodafone and many others. The main principle of OMA is to
Figure 1: High-level architecture of OMA IMPS.
make products and services not dependent on proprietary
technologies but instead create open global standards, Immediately apparent from the high-level architecture is
protocols and interfaces. that unlike some popular Instant Messaging systems (like
To solve the standardization problem in the instant Skype or Google Talk) that utilize peer-to-peer connections,
messaging and presence area, Nokia, Ericsson and Motorola the Wireless Village solution is purely a client-server-based
formed the Wireless Village initiative in the year 2001. The solution. Direct client-to-client communications do not exist
first Wireless Village (WV) 1.0 specifications were published under any circumstances nor are any protocols defined in the
on February 2002. The initiative was then consolidated into OMA IMPS specification for client-to-client communication.
OMA in October 2002, after which Wireless Village no While the architecture is designed mostly for the wireless
longer existed as an independent organization. OMA IMPS environments, OMA IMPS does not limit the client devices to
specification v1.1 was published in November 2002. Based on mobile phones; the clients can also include PC-based clients.
Wireless Village v1.1 specifications, OMA IMPS v1.2 was These clients connect to the OMA IMPS system using the
published in January 2005. So far over 40 clients and servers same protocols as clients on mobile device.
have passed the Interoperability Testing. When designing the OMA IMPS architecture, principles
Nowadays major mobile phone manufactures often include laid out by the IETF IMPP (Internet Engineering Task Force
OMA IMPS compliant applications. in their mobile software Instant Messaging and Presence Protocol) working group
by default. For example Nokia currently has 25 phone models were kept in mind. While OMA IMPS cannot be called fully
supporting the standard [12]. There are also service providers “IMPP-compliant”, the architecture bears some resemblance
providing OMA IMPS services; some for free and others via a to IMPP specifications. For example, references to the
subscription plan. Mobile operators, the primary target for the Common Profile for Instant Messaging (CPIM) can be seen in
initiative, have so far been somewhat slow in adopting and the architecture and the Watcher-structure for receiving
promoting the standard. In Finland, Saunalahti was the first presence changes is similar to that defined in IMPP.
operator to launch OMA IMPS-compliant instant messaging A more detailed look at the OMA IMPS architecture and
services in March 2005. Work on the OMA IMPS standard is the protocols specified can be seen in Figure
ongoing and contributors include mobile operators, wireless 2.
equipment vendors, information technology companies,
content providers and others.
OMA IMPS – a paper for Instant Messaging and Presence-seminar, University of Helsinki, 2005 3
The logical component architecture of a Wireless Village
server is split into two subsystems: the Service Access Point
implements the protocols used to connect to OMA IMPS
clients and other network elements and the Service Elements
provide the actual functional implementations of the features.
In addition to basic connectivity, the Service Access Point
implements connection-related functions such as
authentication, authorization and service discovery.
The OMA IMPS system is session-oriented in the sense that
a client must have an active session with the OMA IMPS
system to be able to use the service. To establish a session,
clients must log in to a Service Access Point. For service
discovery, the clients can either be preloaded with the address
of a mobile operator’s Service Access Point or they can be
Figure 2: OMA IMPS system architecture: Entities and protocols defined in manually configured.
OMA IMPS specification [1]. Whether or not actual additional authentication is
performed when logging in is up to the operator; the Wireless
The main elements of the architecture are: Village Server can also simply rely on the authentication
performed by the mobile network. If a separate login is
• Wireless Village Servers required, either two-way access control through the use of
• Wireless Village Clients: embedded and CLI clients userid/password combination or a four-way access control
• Mobile Core Network employing challenge strings can be used.
• Proprietary Gateway and proprietary server(s) B. Protocols & standards
OMA IMPS defines separate communication protocols for
The Wireless Village (WV) Servers are the core of the
each of the links between the entities, including two separate
solution. WV Servers connect to OMA IMPS-compliant
protocols for two types of client entities. The defined
clients using the CSP and CLP protocols, to other OMA IMPS
protocols are:
servers using the SSP protocol and to elements of the mobile
core network utilizing the SMCNP protocol. A logical element
1) CSP (Client Server Protocol)
within the WV Servers, Service Access Point, serves as the
connection point to the other elements. CSP is the main protocol used for communication between
One notable feature in the architecture is the presence of an the client devices and the Wireless Village server(s). An
optional element called Proprietary Gateway. This gateway, if example of a CSP client is a mobile phone with software
present, enables the IMPS system to be connected to other support for OMA IMPS specification, such as the Nokia 6680
external IM systems that do not comply with the OMA IMPS [12]. The CSP protocol is an XML-based protocol and using
specifications. We will examine interoperability issues more it, access to the full set of available OMA IMPS services is
closely in section D of this chapter. provided.
The majority of the system functionality resides in the The vast majority of the embedded or installable OMA
Wireless Village servers. The following diagram depicts the IMPS-compliant clients utilize CSP as their communications
functional elements of a WV server [1]: protocol towards the Wireless Village Server. More details
and examples of the CSP protocol will be presented later.
2) CLP (Command Line Protocol)
Legacy terminals use CLP to connect to the OMA IMPS
system. The CLP protocol is a text-based protocol that can be
used either from an embedded program or by manually
entering commands in an SMS. Using CLP allows practically
any existing GSM phone to be used for basic interaction (such
as sending and receiving instant messages) with an OMA
IMPS system.
As an example, the following is a valid CLP message of
sending a message to “John” who is already assumed to be in
Figure 3: Logical architecture of the Wireless Village Server.
the sender’s contact list. This SMS can be sent to the WV
server, which will then deliver it to John as a normal instant
OMA IMPS – a paper for Instant Messaging and Presence-seminar, University of Helsinki, 2005 4
message, regardless of what protocol he uses to connect to the servers utilize the SMCNP protocol.
system. The core protocols (CSP and SSP) defined by the OMA
IMPS standard are based on XML. The protocol stack below
“WV-John Hi John, how are you?” the IMPS protocols is based on various open standards and is
depicted in Figure 4:
CLP provides only a subset of the OMA IMPS services, but
by using CLP, it’s possible to perform the most basic
functionalities such as adding and removing contacts, fetching
presence information, joining a group etc. All in all there are
17 “commands” that can be accessed using the text-based
interface to OMA IMPS [15]. While such a command-line
interface could be in theory used from any text-based
terminal, OMA IMPS has only defined the CLP protocol to be
used over an SMS bearer.
3) SSP (Server-Server Protocol)
Figure 4: Protocol stack for OMA IMPS protocols.
The Wireless Village servers are connected with the SSP
protocol. This protocol is used both intra-domain and inter- The protocol stack is a varied collection of mostly standard
domain communication across different service providers Internet protocols. On the top level are the OMA IMPS-
(such as different mobile operators). It is also used for the specified protocols (CSP, CLP and SSP) as well as the IMPP-
communication between the Proprietary Gateway and the WV specified Common Profile for Instant Messaging. The allowed
Servers. Similarly to the CSP protocol, the SSP protocol is transport protocols vary for the different OMA IMPS
XML-based. protocols.
The SSP connections run over HTTP or HTTPS and For example, for the CSP protocol, four transport bindings
between two WV servers, at least two TCP connections are are specified: WAP Wireless Session Protocol (WSP),
established: one for outgoing requests and the other for Hypertext Transfer Protocol (HTTP), Hypertext Transfer
incoming requests [16]. The exchange of messages between Protocol Secure (HTTPS) and Short Message Service (SMS),
two WV servers typically takes place in one hop over a direct of which at least one is required to be supported by the client
connection to the other WV server. However, the servers also [10].
support routing of the messages according to business and Going down the protocol stack, OMA IMPS is bearer-
service agreements. There is no automatic discovery of the agnostic: the connection itself can be run over TCP, UDP or
WV servers; the configuration (connections and possible WDP (WAP Wireless Datagram Protocol) can be utilized.
routing agreements) must take place manually. Also, any IP-based mobile or fixed network infrastructure
connection can be used to access the system. For mobile
4) SMCNP (Server Mobile Core Network Protocol) networks that do not support packet data connections, an SMS
delivery binding is specified for the CSP protocol.
SMCNP provides the Wireless Village servers access to the When communicating with the server, most communication
mobile core network (e.g. WCDMA CN or 2G/2.5G CN). between the client and the server is synchronous, i.e. request-
SMCNP is used to connect to the mobile operator’s core reply in its nature. For example, a simple and possibly the
network for the purpose of getting presence and service most common message is that of a client sending an instant
capability information from the operator’s network. It can also message. The flow of this is depicted in Figure 5:
be used to aid the authentication and authorization of the
users, clients and OMA IMPS servers.
However, the SMCNP cannot really be considered a
protocol but rather a logical connection to the operator’s core
network. This is because the OMA IMPS specification does
not actually specify anything at all about the protocol. The
exact protocol(s) used therefore depends on the deployment.
C. Protocol stack and examples
As seen, the name of the protocol is descriptive of its
position in the architecture. Clients always communicate with Figure 5: Flow diagram of SendMessageRequest [11].
the servers using either the CSP or the CLP protocol while the
servers communicate with each other using the SSP protocol. As was mentioned, the CSP protocol is based on XML. The
For interaction with the mobile core network (MCN), the specified XML protocol structure is quite heavy: with a
typical 200-character message, the overhead from the plain-
OMA IMPS – a paper for Instant Messaging and Presence-seminar, University of Helsinki, 2005 5
text XML can be as much as 80% or more of the message
length. To alleviate this significant overhead, OMA IMPS has
defined binary XML mappings for the Client-Server-Protocol

[14]. Binary coding of the XML means “abbreviating” the
XML tags with shorter codes (tokens) in order to make the
The above message is over 1200 bytes long. With binary
messages shorter. For example, the token “74” is used for the
XML encoding, the total message length goes significantly
start tag of “TransactionDescriptor”. Listing 1 contains an
down, but even after binary encoding the message remains
example message that uses the CSP protocol primitive
over 300 bytes in size. As the “real” absolutely required
SendMessageRequest. This primitive is used to send an instant
information consists of significantly less than 100 bytes, there
message to other users.
is marked overhead in the CSP protocol even with the binary
XML coding.
The simple response from the server to the client to the


[email protected]

58 200
wv:[email protected]

Wicked Vicky
wv:john/[email protected]

wv:john/[email protected]
m The example plain-text response in Listing 2 consists of
over 700 bytes of information; the binary XML equivalent is
over 100 bytes in length. Even when using binary encoding,
the simple act of sending a very short message and receiving
an ACK-like acknowledgement from the server consumes
wv:[email protected] approximately half a kilobyte of traffic. While delay-wise this

should not be a cause for concern, it might turn out to be a
600 charging problem if the mobile operator charges their
subscribers for the Instant Messaging traffic with normal
packet data rates. This charging may come on top of possible
This is a test message, hurry up people! charging for the IM service itself. In addition, excessive
packet data traffic unnecessarily drains the mobile devices

OMA IMPS – a paper for Instant Messaging and Presence-seminar, University of Helsinki, 2005 6
batteries and degrades the network performance. the Wireless Village servers using the SSP (Server-to-Server
Protocol). However, the proprietary gateway is not a required
D. Interoperability
element in the OMA IMPS architecture and nothing forces the
Interoperability can be divided in two cases: service providers to provide interoperability with other IM
interoperability across different domains both running an systems – or, indeed, even other operators running an OMA
OMA IMPS-based system and interoperability with other, IMPS-compliant system.
possibly proprietary, IM solutions. Interoperability with other The Proprietary Gateway performs the protocol conversions
OMA IMPS systems is achieved using the standard SSP necessary between OMA IMPS and the proprietary system(s).
protocol with the Wireless Village servers running in different It connects to the proprietary server(s) using whatever
domains. The interoperability between WV systems can also protocol they utilize and to the OMA IMPS servers using the
include sharing of complementary services – one domain can SSP protocol. The actual implementation of the protocol
include the shared content feature that the other does not conversion(s) and whether or not both (or all) IM services
support. With full interoperability, users of both domains can share the same feature set naturally depends on the
use services in each other’s domain. deployment and which IM service is being connected to.
Figure 6 depicts the interoperability scenario between two Some features in the other IM service may not be accessible
WV systems [3]. In this scenario, the WV Server on Domain by the OMA IMPS users and vice versa; for example, an
A only implements the IM and Group/Chat services while the attempt by an MSN Messenger user to initiate a video
server on Domain B implements the full service set. With full connection with an OMA IMPS user will fail.
interoperability between the domains, Client 1 can also utilize Figure 7 presents a simplified message flow-example of
the Presence service even when his/her “local” server does not sending an instant message to a user residing in another IM
have the service implemented. system. Client A, an OMA IMPS user, sends an instant
message to one of his/her contacts with an ID of
[email protected]” who uses some proprietary IM solution.
The message is sent to the WV server as usual, which routes it
to the proprietary gateway. The proprietary gateway in turn
performs any required protocol conversions and sends the
message to the other IM network, where it is routed to the
final recipient.
OMA IMPS does not define which other Instant Messaging
systems the proprietary gateway should be able to support. Its
capabilities are therefore dependant on the vendor’s gateway
implementation. There are, for example, implementations
connecting to the Yahoo! Messenger service, XMPP
Figure 6: Simple interoperability setup with two Wireless Village server (Extensible Messaging and Presence Protocol) and SIMPLE
domains. (SIP for Instant Messaging and Presence Leveraging
Extensions)-based systems. The existence of a dedicated
As was previously mentioned, a noteworthy feature of the network element to aid interoperability is in contrast with
OMA IMPS architecture is its explicit support for many other IM solutions, which are often purposefully built as
interoperability with other instant messaging-systems. The “closed” systems with no (allowable) means for
interoperability with other IM systems is supported through an interoperability with other IM systems.
element called Proprietary Gateway that communicates with
Proprieta ry Other IM system
Client A WV Server Gateway server Client B
CSP: SendMessa geRe quest
To: john@hotm ail.com
“Hi J ohn! How are you?”
CSP: SendMessa geRes ponse
200 OK SSP: SendMessa geRe quest
SSP: SendMessa geRes ponse (Proprietary protoc ol for
sending the message)
(Proprietary protoc ol for
delivering the message)
Figure 7: Simple interoperability setup to a proprietary IM system.
OMA IMPS – a paper for Instant Messaging and Presence-seminar, University of Helsinki, 2005 7
OMA IMPS system. Even if transport encryption is deployed,
due to the nature of the CSP-protocol specification it’s
E. Implications of chosen architecture
inevitable that the encryption breaks at the OMA IMPS
The chosen architecture and protocols for OMA IMPS has a servers: as there are no separate headers in the CSP protocol
number of important functional and other implications. The messages, OMA IMPS servers will need to be able to open the
choice of a pure client-server architecture would initially XML message to determine who the message should be
imply less than optimal bandwidth utilization as each message delivered to. It’s clear that significant trust will therefore need
will need to traverse through a server. However, in the case of to be placed on the service operator – something that
the most co

Use: 0.0705