WiCom, a wireless communication API for the provisioning
of mobile computing over a GSM network
Davide Carboni, Gavino Paddeu, Stefano Sanna
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Center for Advanced Studies, Research and Development in Sardinia
VI Strada OVEST Z.I. Macchiareddu 09010 UTA (CA) - Italy
tel +39 0702796303, fax +39 0702796216
This paper describes WiCom, a package of Java APIs and services within the PASSION
Project. The principal aim of PASSION is to develop a complete system allowing the remote
consultation of multimedia documentation by maintenance operators. In this context, WiCom
provides a framework for managing wireless connections over GSM network, accessing the
telephony capabilities of the underlying operating system and hardware, by introducing a
robust and intelligent layer in the RMI stack.
While the development of sophisticated distributed applications is still a challenge, several
industrial standards (CORBA, DCOM, RMI …) are offering programmers a level of abstraction
similar to the Object Oriented Programming paradigm. Initially conceived to enable the
development of intranet and internet applications, these frameworks are built with the assumption
of robust and fast network connections between the components, which actually lack in the context
of a mobile environment. Since the aim of the PASSION project is to enable mobile operators to
access information in a distributed wireless environment, we have faced the problem of offering an
identical level of abstraction to the PASSION developers, in order to hide the fact that they actually
work in a wireless context. As a solution to this problem, we have developed WiCom, a package of
Java APIs for managing wireless connections, accessing the telephony capabilities of the
underlying system and introducing a robust and intelligent layer in the RMI stack.
After a brief description of PASSION, we will present the two main parts of WiCom: an abstract
layer which allows the applications to use RMI (Sun, 1998) over a wireless network in a
transparent manner, and the native layer which implements the abstract part for the Epoc32 OS and
a GSM bearer. The automatic connection management performed by WiCom aims to economise
the duration of the connection and to handle I/O exceptions caused by channel faults. Wireless
communications within the PASSION framework
PASSION is the acronym for Portable ASSistant for Interacting Operators Network and it is one
of the ESPRIT 4 (ESPRIT 1998) programme projects in the “IT for Mobility Work Area”. The
partners involved are the following: Alcatel Alsthom recherche (F) (prime contractor), CRS4 (I),
Matla Terminals (E), Robotiker (E), Softeco Sismat (I), HFRG - University College Cork (IRL),
RINA (I),SISTEPLANT (E), SiESA (E).
The overall goal of the PASSION project is to enhance the mobility and the access of
maintenance operators to an ubiquitous and transparent information system, in order to help in
managing operations like detecting and fixing the disruption which may occur in a widely
geographically distributed system. Examples of such systems include large transportation
networks like energy, telecommunication, railway or highway; sets of equipment located in
various distant places like ships, cars, bus fleets or even photocopiers. PASSION is based on
leading technologies like the Microsoft Windows NT, Linux and Epoc32 operating systems,
the Oracle and Versant DBMSs, the Java programming language, the JINI and CORBA
(OMG, 1998) distributed environments.
1.2 PASSION architecture
The aim of PASSION is to develop a complete system allowing the remote consultation of
multimedia documents by maintenance operators. The global system architecture is made of two
different parts: the ‘nomadic’ part, to be provided to the On-The-Field Operators (OTFOs), that is a
Personal Digital Assistant (PDA) with its associated software; and the Centralised Operation Base
(COB), to be used by a maintenance supervisor, which mainly manages the base of multimedia
documents, the maintenance support services, and the requests/updates coming from the operators.
These two parts are interconnected through a wireless communication network [Fig. 1].
Serv4 Serv N
PAS S ION
RMI RMI OODB
service service Renderer
us e r
us e r
Fig.: PASSION architecture.
The kiosk of services is available through the Jini look-up while the peer-to-peer interaction
between the objects is obtained using the Java Remote Method Invocation protocol.
1.3 Communications issues inside PASSION
The architecture of PASSION is based upon Java's standard Remote Method Invocation, which
relies on "wired" connections between hosts. Neither Java network API nor RMI extensions have
the control of the wireless physical channel. The PASSION communication channel is a standard
GSM circuit. This choice introduces some problems like connection costs and dial-out
management. Since it is better for developers to disregard wireless specific topics during the design
of their applications, the WiCom module tries to provide an abstraction for each topic described
2 The WIreless COMmunication package
2.1 Introduction to WiCom
WiCom (Wireless Communication package) consists of two layers. The first one is the abstract
layer where a connection model is given together with its connection factory. This layer provides
the API which sets the WiComRMISocketFactory as RMI socket factory. Java applications
can invoke remote methods from a PDA assuming that a connection has been set up or will be set
up when needed. The design of this layer has been made taking into account the possibility to reuse
it with bearers different than GSM. Thus a factory design pattern (Gamma et al.,1994) is the best
choice, the WiComConnection is provided by a ConnectionFactory, they are both
abstract classes and during the run time their native implementation is loaded by the JVM.
The second part of WiCom consists of platform-dependent layer. This part consists in a Java
package and a native library. In the actual implementation the connections are obtained as PPP
interfaces over a GSM circuit and the operating system is Epoc32. If a connection is dropped, the
WiCom module automatically tries to establish a new physical connection between client and
server. Moreover, WiCom can optimise the use of the GSM channel hanging-up the call during
silent phases of the logical connection and setting a new call when needed. The Epoc32 operating
system is provided with a JVM and a telephony server. A dynamic view of the WiCom behaviour
is shown below [Fig. 2]. When the RMISocketFactory is set it loads the proper
implementation of the ConnectionFactory for the underlying operating system. Now the
application can use RMI in a transparent manner disregarding all the matters related to dial-up and
GSM hardware. In the diagram below is assumed that the connection has still to be created and
RMI : WiComRMISocketFactory : Conn ect io n : WiCom : WiCom
Factory Connection Socket
3: creat e()
8: ref to WiComConnection
9 : new WiComS ocket()
10: ref to WiComSocket
11: ref to WiComSocket
Fig. 2: Sequence diagram of WiCom classes
2.2 The WiCom classes
The WiCom socket layer is an extension of the transport layer of the Java RMI stack [Fig. 3]. In
this way WiCom is able to provide the above RMI layer with ad-hoc input and output streams
specialized in handling connection failures to ensure a continuous data transmission and also
capable to separate the physical connection from the logical one.
Remote reference Remote reference
WiCom Layer WiCom Layer
Socket Layer Socket Layer
Datalink (PPP) Datalink (PPP)
Physical (GSM circuit) Physical (GSM circuit)
Fig. 3: RMI stack with the WiCom layer
A set of Java classes is provided to extend the socket layer inside the RMI stack. These classes are:
A replacement of standard RMISocketFactory. WiComRMISocketFactory provides
customized Socket and ServerSocket specialized for WiCom goals.
• WiComSocket, WiComServerSocket
Extensions of Socket and ServerSocket.
• WiComInputStream, WiComOutputStream
Extensions of InputStream and OutputStream. These classes implement mechanisms to
handle wireless connection exceptions like buffering and data transmission recovery from the last
2.3 WiCom under the hood
WiCom is designed as an extension of the RMI socket factory. Nevertheless, its structure is
generic and portable to operating systems other than Epoc by simply changing the native parts of
the package. The Epoc32 operating system release 5 supports Java 1.1.4 and also provides a
software development kit useful to write and test native C++ code. The client-server and object-
oriented structure of Epoc DLL (Symbian, 1999) allows through the use of the JNI to write Java
classes able to set-up a new call, to be notified about GSM events and to take over existing calls
Implementation of the
Internal WiCom class
which provides native
tit rs S)
aa( os t
rl) g( o
tO r) p
Interface to Dial service
provided by Epoc to
NetDial users' applications.
Fig. 4: Interaction between Java objects and native parts
3 Open issues
Since WiCom is still under development, the continuous data transmission feature in case of
channel failure is still to be tested in all possible conditions. We know that today’s market leader
technology is GSM but emerging technologies like GPRS (Cai et al.,1997) and UMTS are quickly
growing. Therefore we must take into account this evolution to design WiCom as “upgradable” as
possible to the new standards. Last but not least, some GSM services are currently available only
by native serial communications, but since one of the WiCom objectives is the portability we plan
to base serial I/O on Sun’s standard JavaComm API which is not yet available under Epoc.
The authors would like to thank Enrico Stara for his precious support during RMI specific issues
development and Paola Mastromarino for providing general guidelines related to wireless topics.
(Arnold et al., 1999)
Arnold, K., Wollrath, A., O'Sullivan, B., Scheifler, R., and Waldo, J. (1999).
The Jini Specification,
Addison-Wesley. ISBN 0201616343.
(Beck et al., 1999)
Beck, J., Gefflaut, A., and Islam, N. (1999).
Moca: a service framework for mobile computing devices.
In ACM international workshop on Data engineering for wireless and mobile access.
(Cai et al.,1997)
Cai, J., Goodman, J. D. (1997), General Packet Radio Service in GSM.
In IEEE Communications Magazine , October 1997, pages 122-131.
The EU information technologies programme.
GSM 07.07: Digital cellular telecommunications system (Phase 2+); AT command set for
GSM Mobile Equipment (ME); version 5.4.0; Nov 1997, http://www.cordis.lu/esprit/
(Haahr et al., 1999)
Haahr, M., Cunningham, R., and Cahill, V. (1999).
Supporting corba applications in a mobile environment.
In International Conference on Mobile Computing and Networking, pages 36-47.
Object Management Group (1998)
The Common Object Request Broker: Architecture and Specification
Object Management Group, February 1998, http://www.omg.org/library/
Stearns, B. (1997).
Integrating native code and java programs.
Technical report, SUN,
Java Remote Method Invocation Specification, 1.2 edition.
Epoc technical papers,
(Gamma et al., 1999)
Gamma, E., Helm, R., Johnson, R., Vlissides, J., (1994)
Design Patterns, Elements of Reusable Object-Oriented Software.
Addison-Wesley. ISBN 0-201-63361-2