LIGHTWEIGHT CLIENT-PULL PROTOCOL FOR MOBILE

COMMUNICA

TION

Stefano Sanna, Emanuela De Vita, Andrea Piras

CRS4 - Center for Advanced Studies, Research and Development in Sardinia

Parco Scientiﬁco Polaris - 09010 Pula(CA) - Italy

Christian Melchiorre

Softeco

Sismat S.p.A.

Via De Marini 1 - WTC Tower - 16149 Genova - Italy

Keywords:

Priority management, communication protocol, mobile device.

Abstract:

Consumer mobile devices, such as cellular phones and PDAs, rely on TCP/IP as main communication pro-

tocol. However, cellular networks are not reliable as wired and wireless LAN, due to both users mobility

and geographical obstacles. Moreover, limited bandwidth outside urban areas requires an application level

data priority management, in order to improve user experience and avoid communication stack deadlocks.

This paper presents early speciﬁcation and ﬁrst prototype of the LCPP (Lightweight Client-Pull Protocol),

a UDP-based communication protocol specially designed to provide better performance, fast responsiveness

and save processing power on mobile devices. Using some concepts adopted in the ﬁeld of P2P ﬁle sharing,

LCPP provides data priority management approach, which enables application to negotiate concurrent access

to communication channel and to be notiﬁed about delaying, network congestion or remote device inability to

process data.

1 INTRODUCTION

Mobile devices communication use wireless chan-

nel that, to date, cannot be considered as reliable as

their wired counterpart. TCP/IP, which is the basis

for well-established application-level protocols such

as HTTP, has not been designed for such unreliable

channels. Using TCP/IP on wireless connection can

be extremely boring for users, which continuously

get ”connection lost” error messages. On the other

hand, cellular network data access is still expensive

and users tend to avoid using Internet services on mo-

bile devices, especially if they have experienced poor

performances and high connection rates.

Peer-to-peer paradigm (P2P) has emerged in the

last years as innovative way to create scalable sys-

tems over wired networks. P2P communities have

proposed two important concepts: data should be ex-

changed according to some classiﬁcation provided by

the user and hosts have to ﬁnd themselves preferably

without any central registration facility. Priority man-

agement refers to the ability of communication layer

to suspend data transfer if any other important data

needs to be transferred using the all available band-

width.

In this paper we describe beneﬁts of priority man-

agement in mobile communication and propose a

protocol suitable for mobile devices, such as PDA

and programmable cellular phones. We refer to mo-

bile communication as network access by means of

a GPRS or UMTS terminal (either mobile phone or

PCMCIA data card). WLAN access raises other inter-

esting issues, although large bandwidth and restricted

operation area give, for most applications, more re-

liability than cellular network in a mobile intensive

scenario.

2 PRIORITY MANAGEMENT IN

MOBILE COMMUNICATION

Desktop users are used to perform multiple access to

network resources: they read and write emails, while

sharing large ﬁles and downloading some interesting

software. At the same time, background processes up-

date system libraries, check for new virus signatures

and gather information about weather, stock quotes

and so on. This class of users rely on a wideband

connection, either with ofﬁce LAN or home DSL sub-

scription. With such connections, overall responsive-

ness of applications is pretty comfortable, although

very point-to-point connections may cause network

227

Sanna S., De Vita E., Piras A. and Melchiorre C. (2005).

LIGHTWEIGHT CLIENT-PULL PROTOCOL FOR MOBILE COMMUNICATION.

In Proceedings of the Seventh Inter national Conference on Enterprise Information Systems, pages 227-231

DOI: 10.5220/0002544402270231

 SciTePress

access locked for a while: it is common, for in-

stance, to lose connection to Instant Messaging (IM)

server or to have some delays in sending emails if

data transfer has been previously opened to a very

fast peer. While this scenario mainly applies to desk-

top users, mobile device users become to experience

similar problems related to concurrent network ac-

cess. Flat rate per-month subscriptions offered by

cellular network operators encourage customers to

use PDAs and high-end cellular phones to access

web site, mailboxes and adapted content (audio and

video). Business oriented applications (remote ofﬁce

and ﬁle sharing, email with attachments, simpliﬁed

editor for text documents, spreadsheets and presenta-

tions) and hardware tailored for mobile workers (ex-

tended keyboards, large displays, enhanced connec-

tivity) are bundled and offered to selected customers.

Network-oriented mobile applications refer to three

main classes: user interactive applications, user

browsing applications, system applications. User in-

teractive class identiﬁes applications which response

time is critical for user experience. It comprises email

clients, IM systems, navigation systems. These ap-

plications are expected to have very short delays and

give best responsiveness. For instance, IM clients en-

able people to talk nearly in real-time and most of

time is spent reading and typing, while data transfer

involves a few data; moreover, since it consist of syn-

chronous communication between humans, user ex-

pects continuous dialog with remote peer (response

time half a second or less). User browsing class iden-

tiﬁes applications which response time is not critical,

so that some delay is being tolerated. Video and audio

downloading, web browsing and software installation

may require some time to be completed and experi-

enced users are aware about it. Finally, system class

identiﬁes applications executed in background by the

operating system. It includes system updates (bug

ﬁxes, security updates), network synchronization and

similar.

In an ideal scenario, any system application should

suspend any data transfer if a user interactive appli-

cation requires to send or receive data. This way,

the user perceives that communication channel is de-

voted to his conversation or important web brows-

ing. To simplify, it is better to give the user best

performance of device and network connection, while

a delay of a few seconds will not affect system op-

erations (such as those previously described). Such

an approach can be found in modern operating sys-

tem design, where process scheduler tries to provide

good responsiveness to graphical interface and delay-

ing system processes (such as writing on ﬁlesystem).

Figure 1: Priority management in mobile communication:

user interactive and user browsing applications require dif-

ferent responsiveness.

3 LCPP

Lightweight Client-Pull Protocol (LCPP) has been

designed to provide mobile application developers

with a priority- and receiver- driven protocol. It has

been designed as a lightweight protocol, easy to im-

plement even on resource constrained devices. As

said before, priority management is key element for

mobile communication; in order to manage data com-

ing from multiple source, client is responsible for

managing data packets transmission. We identify peer

that sends data as Transmitter (TX), while the one that

receives is called Receiver (RX). Main LCPP con-

cepts can be summarized as follows:

• RX drives communication progress: data sender

(TX) cannot arbitrarly send any data if it has not

be requested by the RX

• all data packets moving from point to point contain

a priority information: RX should make requests

for higher priority data fragments ﬁrst

• communication stacks of peers share information

about priority management and network conges-

tion.

LCPP relies on UDP, because it is lighter than TCP

and requires less resources to be implemented on low-

end devices. While TCP/IP offers good infrastruc-

ture for continuous connections, it is time and re-

source consuming for intermittent connections. LCPP

does not introduce any custom addressing or rout-

ing schema; therefore LCPP headers do not con-

tain any information about source nor destination of

data: it is implicitly assumed that such an informa-

tion will be accessible through the underlying proto-

col. LCPP uses raw UDP packets and it is responsi-

ble for data synchronization, transport and connection

control. LCPP deﬁnes two type of data packets: Com-

mand and Data. Command packets are exchanged

ICEIS 2005 - SOFTWARE AGENTS AND INTERNET COMPUTING

228

Table 1: LCPP command list.

Command ID Description

REQUEST TO SEND DATA Sent by a TX that requires to send data to a RX

ACCEPT TO RECEIVE DATA Sent by a RX that accept to receive data from a TX

REFUSE TO RECEIVE DATA Sent by a RX that does not accept to receive data

SEND FRAGMENT Sent by a RX that is ready to receive a new data fragment

GET FRAGMENT Sent by a TX after a SEND FRAGMENT has been received

ABORT Sent by a peer to interrupt data transfer (sessions will be reset)

CONFIRM DATA RECEIVED Sent by the RX to notify that all data have been received

WAIT FOR HIGHEST PRIORITY Current session is being suspended to process higher priority data

WAIT FOR SYSTEM BUSY Communication delays caused by local time-consuming processes

WAIT FOR MEMORY BUSY Communication delays caused by memory-consuming processes

RESUME RECEIVE DATA A previously suspended data transfer can be recovered

between peers to manage data transfer setup and re-

quest, error reporting, communication closing; they

are 18 bytes long and contain: Command ID, priority

level, service ID, message, session and reference. The

ﬁrst two bytes contain the Command ID, which iden-

tiﬁes what action is being notiﬁed to the target (e.g.,

start transfer, abort transfer, get/send some data frag-

ments...) and the priority level. Remaining header

ﬁelds contain parameters of current command (such

as data size), service ID (that refers to a speciﬁc data

processor on the RX side), session and session refer-

rer information (used to keep track of correlation be-

tween sequence of request/response). Table 1 shows

the LCPP command list. Commands are always trans-

mitted and received regardless their priority. In fact,

since Commands are very small data fragments and

the information they contain may inﬂuence overall

data transfer policy, they are expected to be processed

as soon as possible by peers.

Figure 2: Structure of Command and Data packets.

Data packets are extended Command packets with

a 512 bytes payload. The Client-Pull approach refers

to the RX side control against data fragments being

sent; while TCP allows the server to send several

packets within a data window, potentially fulﬁlling

available bandwidth, LCPP server waits for client re-

quest (pull) before sending any data packet. More-

over, since every data stream has its own priority,

client will ask for higher priority packets ﬁrst, delay-

ing lower priority ones, assuring that data over chan-

nel is always that with highest priority.

Once TX needs to transmit data to RX, it sends a

REQUEST_TO_SEND_DATA command; by reading

the priority ﬁeld and data size, RX can decide if it is

able to process data (that is, since it knows how much

data will be transferred it can decide if there

s enough

memory - or credit on the SIM card - to get data)

and it responds with ACCEPT_TO_RECEIVE_DATA

command which informs TX that RX has accepted

the transfer. However, no data transfer actually starts,

until the RX sends a sequence of SEND_FRAGMENT

commands. How packets are requested depends on

RX implementation: TX has only be ready to split

and send data as required. The central idea con-

sists on moving intelligence from the protocol itself

to the hosts implementing it. Protocol metadata does

not provide enough data to understand communica-

tion status (while TCP/IP, where such an information

can be showed by windows and acknowledgments).

4 IMPLEMENTATION AND TEST

First prototype of LCPP stack has been implemented

as a communication library PersonalJava-compliant

and has been deployed on iPAQ PDA running Insignia

Design Jeode and IBM J9 embedded VMs. Tests have

been performed using GPRS cellular network. Al-

though LCPP packet size can be varied arbitrarily, it

has been choosen to ﬁt at least a GSM (ETSI, 1993)

time slot (current implementation uses 512B packets,

while early alpha releases were using 1KB packets).

LIGHTWEIGHT CLIENT-PULL PROTOCOL FOR MOBILE COMMUNICATION

229

Figure 3: Sequence diagrams of two concurrent data trasfers

with different priority.

Figure 4: Network conﬁguration used during extensive

tests.

Preliminary tests have shown very good performance

for small, spot data transfer (25KB-50KB); perfor-

mances decrease due to JVM limits on Windows CE

device. We plan to rewrite LCPP in C in order to min-

imize latency caused by VM and Garbage Collector.

GSM network compatibility tests have been per-

formed using PCMCIA and Bluetooth-enabled termi-

nals. These tests have shown that LCPP runs with net-

works without Network Address Translation (NAT)

between operator’s network and the public network.

Since complete tests on GPRS network is very expen-

sive, analysis LCPP has been tested using a wireless

LAN connection. Moreover, in order to avoid to slow

down iPAQ performances, we inserted a router node

between PDA and servers, equipped with the network

analyzer (Ethereal).

We have written a clone of well-known FTP ﬁle

transfer utility using LCPP protocol stack and com-

pared with standard TCP-based client. Results show

that two simultaneous 1MB data transfers over TCP

connection share communication channel and band-

width and the user cannot specify which connection

has to take control of communication channel (Fig-

ure 5). The same application written using LCPP sus-

pends a running data transfer when the user requires

to transfer data with higher priority (Figure 6). Over-

all performances can be improved with customized

RX implementations of more intelligent algorithms

for priority management.

Figure 5: Two concurrent data transfer without priority

management (TCP over GPRS).

Figure 6: Two concurrent data transfer with priority man-

agement enabled: low priority connection (thin line) is sus-

pended until high priority data has been transferred. Priority

management affects data transfers only: Command packets

are expected to be processed though their priority is lower

(LCPP over GPRS).

Performances have been evaluated for two, four

and eight concurrent connections (1Mb data transfer

each), with different assigned priority. Figure 7 and

8 show results for 4 concurrent connections, with and

without priority management support: with priority

management enabled . Table 2 shows numeric results:

priority management connections require more time

to be completed, but highest priority connection data

transfer is expected to be completed before any other.

5 RELATED WORKS

Priority management approach has been implemented

in the ﬁelds of mobile communication, sensor net-

works (Buonadonna, 2001) and embedded systems.

ICEIS 2005 - SOFTWARE AGENTS AND INTERNET COMPUTING

230

Figure 7: Four concurrent 1MB data transfers without pri-

ority management enabled (wireless LAN).

Figure 8: Four concurrent 1MB data transfers with priority

management enabled: bold line refers to highest priority

connection. This starts late, but it is the ﬁrst to be completed

(wireless LAN).

Prefetching mechanism (Kirchner, 2004) may im-

prove user experience with mobile device; at the same

time they can take advantage of priority management

enabled communication stacks. LCPP can be easily

integrated in existing network-oriented applications

and used to test algorithms for prefetching. Prior-

ity management for mixed voice and data services

is addressed by other interesting works (Makrakis,

1998), although proposed approaches are not so easy

to be implemented in a web-oriented prototype. Other

works focused on application-level approach, which

is out of the scope of our work.

6 CONCLUSION

Priority managed communication approach could im-

prove user experience on mobile devices, giving

fastest access to user interactive applications. Cur-

rent LCPP prototype has been implemented in a Java

environment; therefore, to take advantages of prior-

ity management, applications have to share the same

runtime environment, that is responsible for incoming

Table 2: Results for four concurrent data transfers. Priority

management delays overall data transfer, but Time of High-

est Priority (THP, the time needed to complete data trans-

fer with highest priority) does not depend on the number of

actual concurrent connections. LCPP assures that highest

priority data will be transferred in the shortest time.

Connections Priority No priority THP

2 24s 20s 6s

4 44s 36s 7s

8 92s 70s 7s

data fragments. Therefore, to date applications have

to use the custom LCPP protocol library and related

interfaces. Such an approach is suitable for fully in-

tegrated applications, where several modules access

concurrently to the same network stack (the runtime

environment stack). On the other hand, native ap-

plications still use the operating system layer, which

cannot be controlled by the LCPP library. We plan to

implement LCPP concepts in the kernel IP stack, so

that applications will be able to use standard libraries

and, if needed, to assign and negotiate data fragments

priorities to incoming data with remote peers. We also

plan to improve protocol by adding more commands

for detailed automatic error reporting. LCPP is be-

ing used as communication protocol for the EU IST

EurEauWeb project.

REFERENCES

C. Hunt (2002). TCP/IP Network Administration. O’Reilly

N. Minar et al. (2001). Peer-toPeer. O’Reilly

E. Rusty Harold (2000). Java Network Programming.

O’Reilly

P. Buonadonna, J. Hill, and D. Culler (2001). Active mes-

sage communication for tiny networked sensors. In

Proceedings of the 20th Annual Joint Conference of

the IEEE Computer and Communications Societies

(INFOCOM’01).

D. Makrakis, R. S. Mander, L. Orozco-Barbosa, P.

Papantoni-Kazakos (1998). A spread-slotted random-

access protocol with multi-priority for personal and

mobile communication networks carrying integrated

trafﬁc In Mob. Netw. Appl..

H .Kirchner, R. Krummenacher, T. Risse, D. Edwards-May

(2004). A Location-aware Prefetching Mechanism.

Fourth International Network Conference (INC 2004)

Sun Microsystems. PersonalJava Speciﬁcation.

http://java.sun.com/products/personaljava

European Telecommunications Standards Institute. GSM

Speciﬁcation. http://www.etsi.org

LIGHTWEIGHT CLIENT-PULL PROTOCOL FOR MOBILE COMMUNICATION

231