A Design and Implementation for a Wireless Internet RemoteAccess Platform

�

Yao-Ting HuangandPhoneLin�

Abstract

Recently, mobile networks and Internettechnologieshave beenwidely developedfor the voice

communicationandinformationretrieval servicesall overtheworld. Comparedwith thewire-line

Internetenvironment,mobile networks have lower bandwidth,longer transmissionlatency and

unreliableconnection,andthecapabilitiesof mobileterminalsarerestrictedby thelimited memory

size,lowerCPUcomputationcapability, andinconvenientI/O interface.Theselimitationsrestrict

the developmentof the wirelessInternetapplications.For this issue,we designand implement

a “WirelessInternetRemoteAccessPlatform” (WIRAP) that interconnectsthewirelessnetwork

andInternetto providemobileusersaremotecentralizedstorageandcomputationenvironment.A

mobileusercanstorelargevolumeof dataandexecutecomplex computationson WIRAP instead

of on the mobile terminals. WIRAP supportsthe SMS,WML, andHTML interfaces,andusers

canuseterminals(with differentnetwork capabilities)to accessWIRAP.

Keywords: HTML, RemoteAccess,SMS,WirelessInternet,WML

1 Introduction

Mobile networks andInternettechnologieshave beenwidely developedfor the voice communi-

cationand informationretrieval servicesall over the world in recentyears. Integratingthe two

technologies,wirelessInternetservicesbecomea major trendin business.Peopleexpectto send

andreceiveinformationanytimeandanywhere.Comparedwith thewire-lineInternetenvironment,

thewirelessnetworkshave lower bandwidth,longertransmissionlatency andunreliableconnec-

tion, andthe capabilitiesof mobile terminalsareconstrainedby the limited memorysize, lower�Thiswork haswon thethird prizeof thesoftwarecontestheldby NationalCenterfor High-performanceComput-

ing (NCHC),Taiwan,R.O.C.,andwasawardedUSD 3,000.�ContactAuthor: PhoneLin, Dept.of ComputerScience& InformationEngineering,NationalTaiwanUniversity,

Taipei106,R.O.C.;FAX: +886-2-23628167; Email: plin@csie.ntu.edu.tw

1

�������

����������������������! #"%$& #"('

���)�����*�

+-,/.0213,/.

� ,/1346525 134

798�:;�

4 ��< 5

�&=&�>"?�, @'�'A��BC + 4ED �)�� )FG�IH

, �>J&���� 1 �"LK��M�����

0 )�� �"N�CBC ��& ��>O!'+ �M"P ��� @'Q' 5 )��FG�>"%R!'

8S�C�� �"%�� )�

T

UVWX U�U

U�T

YSZ�[\ZZ^]�_Q`^]�_

��� , � D �)�� )FG�)HDa4cb � , �Cd� �Ke

f g

U#h

i

U)WU�X

Figure1: Thenetwork architectureof theWIRAP

CPUcomputationcapability, andinconvenientI/O interface.To provide highertransmissionrate

in thewirelessenvironment,advancedradioandnetwork technologiesarestandardized.For exam-

ple,General PacketRadioServices(GPRS)[5] andUniversalMobileTelecommunicationServices

(UMTS) [1] networkscansupporttransmissionratesup to 150Kbpsand2 Mbps,respectively. To

extendthecapabilitiesof mobileterminals,theWirelessApplicationProtocol(WAP) [18] waspro-

posedfor the presentationanddelivery of the wirelessinformation. With WAP, userscaneasily

retrievetheinformationthroughthemobileterminals.Thewirelessnetwork bandwidthandtheI/O

interfaceof mobile terminalsareimproved. However, dueto the limited memorysizeandCPU

computationcapabilityof themobile terminal,thedevelopmentof wirelessInternetapplications

is restricted.

In this paper, we designandimplementa remoteaccessplatform “WirelessInternetRemote

AccessPlatform” (WIRAP) for wirelessInternetto enhancethe computationcapabilityandthe

storagespaceof themobile terminal. TheWIRAP platformprovidesmobileusersa remotecen-

tralizedstorageandcomputationenvironment.TheWIRAP supportstheSMS,WML, andHTML

interfaces,andcanbe accessedthroughheterogeneousmobile networks. A mobile useris able

to storelargevolumeof dataandexecutecomplex computationson theWIRAP insteadof on the

mobileterminal.

2

Figure1 illustratesthe network architectureof the WIRAP. The WIRAP platform (Figure1

(1)) is accessedby the mobile terminalsembeddedwith the WAP protocolor shortmessageca-

pability (Figure1 (2)) throughtheWAP gateway [18] (Figure1 (4)) or the integratedShortMes-

sage Service(iSMS) gatewayj [4, 3, 15] (Figure1 (5)). The interfacebetweenthe WIRAP and

the WAP gateway is the WirelessMarkup Language [19] (WML; Figure 1 (7)). The WIRAP

platform can also exchangeinformation with the laptop notebookbuilt in a wirelessmodem

(e.g., a GPRShandsetor a 802.11wirelessLAN card [7]; Figure 1 (3)) throughHyper Text

MarkupLanguage (HTML). In theHTML andWML interfaces,theWIRAP is identifiedby the

“URL” address[9], for example,http://PCS.csie.ntu.edu.tw/rap/login.jsp for Web browsing,

andhttp://PCS.csie.ntu.edu.tw/rap/wml/login.jsp for WAP browsing. In theSMSinterface,the

WIRAP is addressedby theMSISDNnumber(i.e.,GSMtelephonenumber)of theiSMSgateway.

On the WIRAP, we maintain a centralizedstoragespacenamed“Remote StorageSpace”

(RSS),which provideseachmobile usera personaldisk quota. The personaldisk quotacanbe

extendedto the computersin Public SwitchedData Network(PSDN;Figure1 (10)) throughthe

CommonInternetFile System(CIFS) protocol[16, 12, 13] (Figure1 (11)). Applicationsfor the

mobile userscanbe provided locally by WIRAP or remotelyby otherapplicationservers(e.g.,

e-mailor news server; Figure1 (12)). TheinterfacesbetweenWIRAP andtheapplicationservers

areTCP/IPapplicationprotocols,e.g.,SimpleMail TransferProtocol (SMTP) [14] andNetwork

NewsTransportProtocol(NNTP) [8] (Figures1 (13)and(14)).

In this paper, wedescribethedesignandimplementationfor theWIRAP platform.Thispaper

is organizedas follows. Section2 presentsthe software architecture. Section3 illustratesthe

collaborationsamongsoftwarecomponentsfor differentdevelopedapplicationsontheWIRAP. In

Section4, weevaluatetheperformanceof theWIRAP. Section5 givesaconcludingremark.

2 The Software Architecture of the WIRAP

In this section,we illustratethe softwarearchitectureof the WIRAP. As shown in Figure2, the

WIRAP can be set up on variousoperatingsystems(Figure 2 (2)) with Java Virtual MachinekTheiSMSgatewayis anoperator-independentplatformthatintegratestheIP network with theSMSin themobile

telephonesystems.ThroughiSMS, an IP host in the externaldatanetwork canoffer Internetservicesto an SMSmobile terminal. The iSMS gateway consistsof a server (Figure1 (7)) connectingto a GPRSmodem(Figure1 (6))thatdelivers(receives)shortmessages[3] (Figure1 (8)) to (from) themobileuser.

3

lnmpo>q�r�s2t�u2v wxmpo*y�z {}|>~���C�Q�L�A� mpoC��|*�Ct �S�Q�

���p� � oCmpz

�(���

� �Q�>� | �I���C�Q��!� � � t3����v��Ew��

� �Q�>� | �I���C�Q��!� � � t;��l/�Ewc�

|>�>r �S�� � t(t � � �l/�Ew

��r �?�G����� q �Q�@� mMr@o�!�Q�S�

���*��� mM� �A� mMr@o| �Q���C�Q�

� �Q�>���a���

� o>��r ��� �A� mMr@o� �)� � t(t�¡�Q���

�¢vx�Ew

£¤

¥

{ �)�I�%�Q�� q ���*� mMr@o�!�I���

vx¦ �

mS|>�§|¨¢���S� s � �

l �I©| �Q���C�Q�ª

«|>�§|�� �Q�C�¦ �M� t(t � t

¬v;¦ �

­*®°¯x±²�³^´cµ3¶!·;¸±!¹3±;º²�³^´cµ3¶!·;¸» ¯�±²�³^´cµ3¶!·;¸¼¾½�» ­²�³^´cµ3¶!·;¸

® ³;¿c¶^¼;¶c¿!·�´¾À�¢���C� mM� �A� mÁrÂo �!�Q�S�

» ¯�± ¼x¶�¿�·x´3À

Ã}¶c¿^³3Ä�ÅxÆ�ÆcÇ

Èxµ3¿xÀ�Æ;¸

É&à ±x­&Ê ·¾¶c¶

­&Ê ³x¸�¿¡´cË® ³^´x³^Ëc·;¸

Ì |!|�� � o � � �Q� � o ��!�Q�S�

l �I©| �Q���C�Q�

�)| �¦�r@o �S� mpo �I�Í^Î Æ3À¡³® ³^´x³^Ëc·;¸

Ã9ÏcÏ^Æ Î ´3À® ³^´x³^Ëc·;¸

Ð

Ñ

£IÒ

£*£

£ ¥ÓÃ�µ�Ô}¿!´

£)¤

Figure2: Thesoftwarearchitectureof WIRAP

(JVM) [11] (Figure2 (1)). In our implementation,we adoptLinux astheoperatingsystem.The

softwareof theWIRAP consistsof five major parts: thebeareradaption,formatadaption,infor-

mationaccess,RSSmanagement,andapplicationparts,which detailsaregiven in the following

sections.

2.1 Bearer Adaption Part

ThebeareradaptionpartmaintainsthebearerbetweentheWIRAP andmobileterminalsresiding

in heterogeneousnetworks.This partconsistsof threecomponents:iSMS gateway(Figure2 (4)),

Webserver (Figure2 (5)), andJavaServerPagesÕ (JSP)container(Figure2 (6)). For anincoming

SMS request,the iSMS gateway passesthe requestto the SMS Java classes(Figure2 (10)) and

returnstheshortmessagegeneratedby theseJavaclassesto themobileterminal.For anincoming

HTTP or WAP request,theWebserver first forwardstherequestto theJSPcontainer[17, 2] viaÖJSPis usedto dynamicallygeneratethewebcontent(e.g.,HTML), which is compiledandprocessedby theJSP

container. TheJSPcontainercompilestheJSPinto Javaclassesby a two-phaseapproach.In thefirst phase,theJSPiscompiledto Java Servlet.In thesecondphase,theJavaServletis compiledto Javaclass.As a result,theJSPactslikea typicalJava classrunningon JVM.

4

×IØxÙ�ÚcÛ Ü�Ý�ØcÛNÞ@ÝCß à�ÚcÛPÙ�Ú�Û

á�â&â!ã�ä�å@æ�ç�ä�èCéê æ#ë%ç ì\í�î á ê

ê æ�çSïñð

ê æ�çSïóò

ô è>ëPõöæ�ç¡áø÷&æ�â&ç�ä�è>é ê æ#ë%çê æ�çSïóù

ê æ�çSïûú

æê æ�ç�ï�ü

÷

åý

Figure3: RelationshipamongCategoriesInput,Control,andOuput

the TCP protocol. Accordingto the nameof the JSPspecifiedin the request,the JSPcontainer

passesthe requestto the correspondingJSP(Figures2 (8) and(9)) in the format adaptionpart.

After servingthis request,theJSPsgeneratetheHTML or WML pagesthataredelivered,by the

JSPcontainer, to the mobile terminalthroughthe Web server. The JSPcontaineralsomaintains

variableswhicharesharedamongdifferentJSPssothatdifferentJSPscancommunicatewith each

otherby accessingthesevariables.

2.2 Format Adaption Part

Theformatadaptionpart (Figure2 (7)) generatesdifferentformatsof contentsfor differenttypes

of mobileterminals,wheretheHTML andWML formatsaregeneratedby theJSPs,andtheshort

messageformatis generatedby theSMSJavaclasses.

The JSPs(for HTML or WML format) aredivided into threecategories: the Input, Control,

andOutputcategories,which relationshipis shown in Figure3.

Input (Figure3 (a)) generatestheHTML or WML input page(to beshown on themobiletermi-

nal) for theuserto specifytheinputarguments(e.g.,userID andpassword;seePath1). The

URL of the Control JSPis carriedin the input pagefor the userto sendthe requestto the

ControlJSPafterinputingarguments.

Control (Figure3 (b)) dispatchesthe requestfrom theuserto thecorrespondingJava classesin

theapplicationpart (Figure3 (d); seePaths2 and3). After servingtherequest,theControl

5

þ�ÿ��nÿ����Mþ���� þÁÿ��nÿ�� ���þ���

���������������������� ����

� ���� "!

#�$

�&% $ ���' ��()������� $ �*+ ,������- $ (.(/��% $' �)�10 $ �

2435��6*+-7*8* $ �90 $ ��

: ���9;<����� # �=�,������� � ����

>@?6A � �

� ���� CB � ���� ED

� ���� GF

� ���� CH

I

J

� K,��LM��þ�N��O ��P@þ�QR)S.�T&U U�VWU Q.�

Figure4: RelationshipamongtheiSMSClient, iSMSEntity, andexecutionregistrydatabase

JSPforwardsthe executionresultsto the Ouput JSP(seePath 4), and returnsan HTTP

responseheader(which carriesthe URL of the OutputJSP)for the userto automatically

makea requestto theOutputJSPX.

Output (Figure3 (c)) returnstheexecutionresultsto theuserby generatingHTML or WML page

to themobileterminal(seePath5).

Becauseshortmessageserviceis aconnectionlessbearer, theexecutionof theSMSJavaclasses

terminatesafter servingoneshortmessage.However an applicationmay requiremorethanone

shortmessageexchangedbetweentheWIRAP andmobile terminal. To completeanapplication,

ourdesignimplementsan“SMS SessionManagement”(SSM)mechanismin theSMSJavaclasses

to maintainthestatusfor thesessionof anapplication,whichdetailsaredescribedin AppendixA.

Threecomponentsin theformatadaptionpart,“executionregistry database”,iSMSClinet, and

iSMSEntity, areresponsibleto handlea shortmessagerequest,which relationshipis shown in

Figure4.

Execution registry database (Figure4 (e))maintainstheexecutionregistrywhichstoresthesta-

tusof thesessionfor eachmobileuser. Theexecutionregistryis createdwhentheuserlogins

anddeletedwhenhelogouts.YIn theHTTP responseheader, the“Location” field storestheURL addresswherethenext HTTP requestshould

besent[6].

6

Z\[�]�^ _a`cbedfeg9hWikj ^kl dkb�` _

j,monpj ]�[)q�r mosutwv qcx�x�xgomoy�z ] g|{�} q\x�x�x

~�� ���W���.������� ���u�u�9�9���e�.�9�W�5�

Figure5: Theformatof theentryin userprofile

iSMSClient (Figure4 (c)) is responsibleto receive (response)the request(result) from (to) the

mobile userthroughthe iSMS server� (seePaths1 and5, Figure4). TheiSMSClient

communicateswith theJavaclassesin theapplicationpart(Figure4 (f)) to processtheshort

messagerequest(seePath4, Figure4).

iSMSEntity (Figure 4 (d)) is invoked by iSMSClient to storeand to retrieve the execution

registry into andfrom thedatabase(seePaths2 and3, Figure4).

2.3 Information Access Part

Theinformationaccesspart(Figure2 (13))providesservicesto theJavaclassesin theapplication

part, which enablesthe communicationbetweenthe WIRAP andthe remoteapplicationservers

(e.g.,mail server). This part containstheSMTPHandler, POP3Handler, FTPHander, and

CIFSHandler classes.The SMTPHander andPOP3Handler servesasclients to commu-

nicatewith the remoteSMTP andPOP3servers to sendand receive emailsfor the users. The

FTPHandler is anFTPclient,which negotiateswith theremoteFTPserver for largevolumeof

dataaccess.TheCIFSHandler accommodatestheCIFSprotocol.By invoking thefunctionsof

theCIFSHandler, the userextendshis personaldisk quotato the storagespacein the remote

CIFSserver (e.g.,Sambaserver).

2.4 RSS Management Part

The RSSmanagementpart (Figure2 (12)) containsJava classesimplementingthe management

functionsfor the useraccountsandpersonaldisk quotas,which areAccountManager, Quo-�The iSMS server consistsof Agent Dispatcher(Figure4 (a)) andShortMessageDriver (Figure4 (b)). Upon

receiptof an incomingshortmessagerequest,theShortMessageDriver forwardsit to theAgentDispatchervia theTCPprotocol.Accordingto thecommandspecifiedin theshortmessage,theAgentDispatcherinvokesiSMSClinetclasses.For moredetailsof theShortMessageDriverandAgentDispatcher, readersarereferredto [15].

7

���W���4���������a�|�e�| 

���������a�)�e�o ¢¡ ���������a�|���o �£���������a�)�e�o ¥¤ ¦ ��§6�¨¡

©ª

«­¬��®��¡E�¯�������a�|���o °

���������a�|�e�| ¢¡ ¦ ��§��¥¡

«­¬��®� £������.���a�|�e�| 

¦ ��§���£ �����.���a�|�e�o "£

±

Figure6: An examplefor thestructureof thepersonaldiskquota

taManager, andSharingManager. Thefunctionalitiesof theseclassesaregivenbelow.

AccountManager. On WIRAP, eachsubscribeduserhasa userprofile that keepsthe userID,

password,andthenamesof thesubscribedapplicationsasshown in Figure5, andis stored

in the userprofile database.TheAccountManager classprovides functionsto access,

modify, create,anddeleteanentryin this database.

QuotaManager usesthe standardJava IO packageto provide functionsto create,delete,and

managethepersonaldisk quotafor users.Thefunctionsin theJava IO package(including

mkdir(), delete(), createNewFile(), renameTo(), getFileSize(), and

listFiles()) areinvokedto createdirectoriesandfiles,deleteafile, changeafile name,

get thefile size,andlist all file pointersin a directory, respectively. TheQuotaManager

utilizes thesefunctionsto provide file operations(e.g., “copy”, “cd”, and “move”). The

personaldisk quotafollows the treedirectorystructureasshown in Figure6. The root is

a pointerpointing to thedirectoryof thepersonaldisk quota(Figure6 (a)). For eachuser,

thereis auserdirectory(Figure6 (b)). Thefilesanddirectoriesof eachuseraredescendants

of theuserdirectory(Figures6 (c) and(d)).

SharingManager. Wemaintaintheaccessprivilegesto keepwhatoperationsusersareallowedto

performon thefile or directorybelongingto anotheruser. For quickly searchinganentryin

theaccessprivileges,our designstorestheprivilegesin a two-level hashtableasshown in

Figure7. Theentriesin the1st level hashtablecontainpointersto the2nd level hashtable

(seeFigure7 (a)), wherethe pathnameof a file or a directoryis usedasa searchingkey.

The entriesin the 2nd level tablecontainpointersto theUserPriv classthat storesthe

accessprivilege(seeFigures7 (b) and(c)), wheretheuserID is usedasthesearchingkey.

8

²w³.´ µ�¶®·¹¸aº�³�»µ�¼�º1½8¾µ�¼�º1½À¿µ�¼�º1½&Áµ�¼�º1½Àµ�¼�º1½CÃ

²w³.´ µ�¶®·Ä¸®º�³�»ÅÇÆ|³�»5¾ÅÇÆ|³�»�¿ÅÇÆ|³�»�ÁÅÇÆ|³�»�ÂÅÇÆ|³�»kÃ

¾�Æ9º,ÈW³�É�³�Ê�Ë̼�Æ9½ÇÍ�¼�Î�Ê1³

¿a¸�ÏÌÈW³�É�³�Ê�Ë̼Æ)½ÇÍ�¼�Î�Êг ÅÀÆo³.»9µ+»)·ÄÉCÑ4Ê1¼�Æ/Æ

¿Ò¸�ÏÌÈ�³.É�³�Ê�Ë̼�Æ9½ÇÍk¼.Î�Ê1³

²w³.´ µ�¶®·¹¸aº�³�»ÅÇÆ|³�»5¾ÅÇÆ|³�»�¿ÅÇÆ|³�»�ÁÅÇÆ|³�»�ÂÅÇÆ|³�»kÃ

µ�»9·¹É Óu¶®¶aÊ1³�¼�¸Ô5³�¼�Ï Í�»6Õ�³Ö¨»)·Äº�³ ×�¼�Ê�Æ|³Ø�Ù,³�Ú Í�»6Õ�³ÈW·�Æ9º ×�¼�Ê�Æ|³

µ+»)·¹É Óu¶a¶®Ê1³=¼�¸Ô5³�¼�Ï Í�»�Õ�³Ö¨»)·Äº�³ ×�¼�Ê�Æ|³Ø�Ù,³=Ú Í�»�Õ�³ÈW·�Æ9º ×�¼�Ê�Æ|³

ÅÇÆ|³�»�µ�»9·¹É&ÑÛÊ1¼ÆRÆÜ

ÝÞ

Figure7: Thetwo-level hashtablefor theaccessprivileges

Beforea useraccessesa file or a directory, theUserPriv class(of the file or directory)

correspondingto theuseris referencedto determinewhethertheusercan“Read”, “Write”,

“Execute”,or “List” thefile or directory. TheSharingManager classprovidesfunctions

to searchandmodify theUserPriv class,andaddor deleteanentry in the1st level and

2ndlevel hashtables.

2.5 Application Part

OnWIRAP, weprovidethea-Mail, w-FTP, e-Address,t-Editor, s-Admin,andFile Explorerappli-

cations.Thefeaturesof theseapplicationsarebriefly describedasfollows:

a-Mail: Thea-Mail applicationallows theuserto sendor receive anemailwith attachedfiles in

thepersonaldiskquota.

w-FTP: Thew-FTPapplicationenablesusersto retrievethefilesstoredin theremoteFTPservers.

e-Address: The e-Addressapplicationmaintainsthe addressbook (containing,e.g., email ad-

dressesandphonenumbersof user’s friends).

t-Editor: Thet-Editor applicationenablestheuserto modify thetext file on theWIRAP.

s-Admin: Thes-Adminapplicationhavethesystemadministratorto addor deleteauseraccount,

andto managethepersonaldiskquotason theWIRAP.

9

File Explorer: TheFile Explorerapplicationprovides(maintains)file operations(theaccesspriv-

ileges)for the userto manageshis personaldisk quota. It also enablesusersto createa

pointer(linked to thefile or directoryon the remoteCIFSserver) asa virtual directoryß in

theWIRAP.

TheApplicationpart (Figure2 (11)) containsJava classesimplementingtheapplicationspro-

videdby theWIRAP, which areMailClient, FTPClinet, AliasBook, Editor, Admin,

andRAPShell. TheMailClinet cooperateswith AliasBook andRAPshell in theappli-

cationpart,andSMTPHandler andPOP3Handler in theinformationaccesspartto implement

the a-Mail application. The FTPClient exerciseswith FTPHandler in the informationac-

cesspart andQuotaManager in the RSSmanagementpart to provide the w-FTP application.

TheAliasBook workstogetherwith QuotaManager in theRSSmanagementpart to accom-

plish thee-Addressapplication.TheEditor providesmemberfunctionsfor editinga text file on

WIRAP. TheAdmin integrateswith AccountManager andQuotaManager in theRSSman-

agementpartfor thes-Adminapplication.TheRAPShell cooperateswith AccountManager,

QuotaManager andSharingManager in theRSSmanagementpart,andCIFSHandler in

theinformationaccesspartto implementtheFile Explorerapplication.In Section3, we illustrate

how theclasseson WIRAP collaboratewith eachotherto implementtheapplications.

3 The Collaborations among Five Parts to Develop Applica-tions

This sectiondescribeshow thebeareradaption,formatadaption,application,informationaccess,

andRSSmanagementpartscollaborateto developapplications.Wefirst describethecollaboration

to handlethe login throughdifferentinterfaces.Thenwe show thecollaborationfor a-Mail asan

exampleto describehow to developanapplicationonWIRAP. Finally, wedescribethecollabora-

tion for theFile Explorerapplication.In this example,theSSMmechanismis appliedto let users

completeanapplicationthroughSMS.For otherapplications,thecollaborationsaresimilar, which

detailsarenotpresentedin this paper.àThis virtual directorycanbeaccessedby theuserlike a realdirectoryon WIRAP

10

á âuã+ä+å�æ�ç èé|ê

á ëEì+í6î�ï�æ,í9å�ðañí�å�ã,æ�ç èé|ê

á ëCê�êWò�å�ðañí9å�ã,æ�âuå6éoí/ç è�é|ê

á ë<ðÒðÒã,ì�æ+í6ó¢ñ�æeñÒä+ï�ô

á ó¢ã�õeå�ò�ï�ö÷é.ï�ôø çaî,í�í�êÛá ù�ùoç1ç ù9ò�ã�ä,å�ækç èéoêú çÒâuã�ä+å1æ�êWñÒä+ï

û çaî+í�í�ê4á ù�ù/çÐç ù�ë�ì,í6îeï�æ+í�å�ðÒñí9å�ã,ækç èéoê

û ç ø ç�ð�îeïÒð�ü�ý9þEÿ��������û ç ú ç�ä,ï�í�ëGÿ�âuå�éoí����

� çaî+í�í�ê8ô/ï®é|êWã�æWé.ï�îeïÒñ��ï�ô

çÒëCê+êWò�å�ðÒñ�í�å�ã�æ8ò�å6é/í�êWñÒä+ï

û ç û ç��kã,ô �<ñ�ô��<ñ�ê�êWò�å�ðÒñí9å�ã,æ<æeñ��"ïÇò�å�éoí� çaî+í�í�ê4á ù�ù/çÐç ù�ëCê+êWò�å�ðÒñ�í�å�ã�æ�âuå�éoíoç èé|ê

Figure8: Thecollaborationfor login on WIRAP throughHTML or WML

3.1 Login on WIRAP

BeforethemobileuserusestheapplicationsonWIRAP throughHTML or WML, hefirst loginson

WIRAP by connectingto theURL of Login.jsp in theformatadaptionpart.Figure8 illustrates

thecollaborationsfor userlogin, whichdetailsaregivenbelow.

Login through HTML or WML:

Steps 1. Themobileusersendsa login requestto theURL of theLogin.jsp of theInput cate-

gory.

Step 2. Uponthereceiptof therequest,theLogin.jsp generatesthelogin pagefor theuserto

input userID andpassword. Note that theURL of theJSPservingtheauthentication(i.e.,

theAuthentication.jsp) is containedin thelogin page.Figure9 (a) shows theWAP

login pagefor aWAP terminal.

Step 3. The mobile usersendsthe ID andpassword to the URL specifiedin the login pagefor

authentication.

Step 3.1. TheAuthentication.jsp of the Control category invokesthecheckIDPwd()

memberfunction in AccountManager in the RSSmanagementpart, which checksif

the received password is the sameasthat in the userprofile for the user. If authentication

is successful,thenStep3.2 is performed. Otherwise(i.e., an illegal login), Step2 is re-

exercised.

11

���������������� !#"�"�"%$&�&'(��)*���+����� ,-).���(��

� /

Figure9: Examplesfor theWAP login pageandapplicationslist page

Table1: Thecommandsandargumentsof theshortmessageto accessWIRAP (PartialList)Command Arguments Description

login ID, Password login on WIRAP with ID andPassworddir - list the directoriesand files in the personal

diskquotadel FileName deletea file or directorynamedFileNamecp FileName copy afile namedFileNamesm ID, Subject,

Content,FileName

sendanemailto theuserID with theSubject,Content,andattachedfile

Steps 3.2 and 3.3. TheAuthentication.jsp invokesthegetAPList() memberfunction

in the AccountManager to retrieve the namelist of the subscribedapplications. The

Authentication.jsp forwardsthenamelist to theApplicationList.jsp of the

Outputcategory to generatetheapplicationlist page.

Step 4. TheAuthentication.jsp returnstheuseranHTTPresponseheaderwhichspecifies

theURL of theApplicationList.jsp.

Steps 5 and 6. ThemobileuserusestheURL receivedat Step4 to get theapplicationlist page.

Figure9 (b)) showsanexamplefor theapplicationpage.

Notethatin theabovesteps,for thesecurityissue,all messagesexchangedbetweenthemobileuser

andWIRAP areencryptedvia theTransportLayerSecurity(TLS) [13] protocolfor webbrowsing,

andWirelessTransportLayerSecurity(WTLS) [18] protocolfor WAP browsing.

12

021�3�4537698�1;:�<>=021�3�453�?@<>=A1B=;C

0 D#EFEHG>I+<�= 4KJ�<�JFL+:M024KG�N�1;8;:9OQPR:MS�TVU 8;G+L+1W<X=A:(P�= SZY�[>\�]Y^T(U J�_ 4KJH1;8�`�aQ_ bdc�ef` TBTWT ]

S(T&S(T Eg�:FE�h�i jke^a#l�m nS(T2[�T L�:Z=;Doedp�1�P�=*mAn

S�T Y^T EM-:FJZ=A:V3�:(PqPR1;G><7m n

Figure10: Thecollaborationfor login throughSMS

In theSMSinterface,therequestfor theapplicationis carriedin a shortmessage,which is of

theform

Command r Argument 1 str Argument 2 s ... r Argument n sThefirst field, Command, indicatesthecommandsfor therequestedapplication.Theotherfields,

r Argument 1 s , ..., r Argument n s , carry parametersrelatedto the request. For the SMS

interface,we implement18commands.Table1 listsapartiallist of commandsandcorresponding

argumentsfor theSMSinterfacein WIRAP. For example,to login on WIRAP with ID “plin” and

password “1234”, themobileuserneedsto sendashortmessage:

login plin 1234 (1)

Considerthea-Mail applicationasanotherexample.Supposethat themobileuserwantsto send

an email to anotheruser“plin” with subject“Hello”, content“test”, andattachedfile “F1”. The

shortmessageis

sm Hello plin test F1 (2)

Figure10 illustratesthe collaborationfor login on WIRAP throughSMS, which detailsarede-

scribedasfollows.

Login through SMS:

Step 1. The mobile usersendsa shortmessagewith the streamin (1) to the iSMS server in the

beareradaptionpart. The iSMS server passesthe shortmessageto iSMSClient in the

formatadaptionpart. Then,theuserexpectsto receive a response(seeStep2) for thelogin

result.If theuserdoesnot receivetheresponse,theuserrecognizesthattheshortmessageis

lost. Hemaychooseto resendtherequest.

13

Steps 1.1 and 1.3 arethesameasSteps3.1and3.2in thelogin throughHTML or WML.

Step 1.2. The iSMSClient invokes the creatSession() memberfunction in iSMSEn-

tity in theformatadaptionpartto createa registry in theexecutionregistrydatabase.

Step 2. The iSMSClient sendsthe mobile usera short messagecontainingthe namelist of

subscribedapplicationsthroughtheiSMS server.

Note that shortmessagesexchangedbetweenthe mobile userandWIRAP areencryptedby the

existingGSM encryptionmechanismfor thesecurityissue[10].

3.2 The a-Mail Application

This sectiondescribesthecollaborationfor thea-Mail application.Thea-Mail applicationsends

andreceivesemailswith attachedfiles throughtheremoteSMTPandPOP3servers,respectively.

Figures11 and12 illustratethecollaborationsfor thea-Mail applicationthroughSMSandWML,

respectively. In Figure11, we assumethat themobileuserusesthea-Mail applicationto senda

mail (with thetopic“Hello”, content“test”, andattachedfile “F1”) to theuser“plin”, whichdetails

aregivenbelow.

a-Mail through SMS:

Step 1. Themobileusersendstheshortmessagewith thestreamin (2) to iSMSClient.

Step 1.1. TheiSMSClient usesthe MSISDN number(in the shortmessage)asthe searching

key to retrieve the executionregistry for the userby invoking therestoreSession()

memberfunctionin iSMSEntity.

Step 1.2. Accordingto thecommandcarriedin theshortmessage(i.e., “sm”), theiSMSClient

forwardstheparameters(i.e., “Hello”, “plin”, “test”, and“F1”) to theMailClient in the

applicationpartto preparesendingmail.

Step 1.2.1. TheMailClient invokesthegetUserMail() memberfunctionin AliasBook

in theapplicationpart to retrieve thefull emailaddressfor themail recipient(i.e., “plin” in

this example).

14

u v&w>xyw�z�{Wv}|q~��

u v&w>xyw>�%~(�;v��B�

u x��ZvW{}z�{}vW|q~(�u x��H�>v}{W|�����|q������ �*����{}v�~���|Z{W{}�9�;|��A��� �q� ��� ����� �H�����q�*�9���q�A�q�o|��&|q���

u2���>�H�;��x��q~>�Z��|q�

��� ��� �A�&�H�*|Fw�|�� �¡vW��~�¢;£

����� �o�ZvW{��¡|q~��^�*�>¤Z¤Z|�� � � �>{}{2� � ��� ��� ��� ��|�����v}{}|�¥�����¦�¢;£

���}��� �A|��A�&�H�*|Fw�|�� �¡vW�H~�¢&£u�w>x¨§d¥��9�q~>�V{W|q�

u ©�{}vW����ª��(�H«��� ���}��� �(|��}���¡|q� x��Zv}{�¢;£��� ��� ��� ��|q~���x��ZvW{�¢&£

Figure11: Thecollaborationfor thea-Mail applicationthroughSMS

Step 1.2.2. TheMailClient invokesthegetFilePath() memberfunctionin QuotaMan-

ager in theRSSmanagementpartto getthepathof thefile “F1”. At thisstep,thefile “F1”

is attachedin themail.

Step 1.2.3. TheMailClient invokesthesendMail() memberfunction in SMTPHandler

in theinformationaccesspartto sendthis email.

Step 1.3. The iSMSClient invokes the storeSession() memberfunction in iSMSEn-

tity to storetheexecutionregistry into theexecutionregistry database.

Step 2. TheiSMSClient sendsa shortmessageto inform theuserthat themail hasbeensent

successfully.

Figure12illustratesthecollaborationfor a-Mail throughWML, whichdetailsaregivenbelow. For

a-Mail throughHTML, thecollaborationis similar.

a-Mail through WML:

Steps 1 and 2 aresimilar to Steps1 and2 in login throughHTML or WML. The mobile user

sendsa requestto theaMail.jsp of theInput category in theformatadaptionpart to get

themail page.

Step 3. The mobile usersendsthe recipientID, subject,content,andthe nameof the file to be

attachedto theURL (carriedin themail page)of theMailProcessor.jsp of theControl

category in theformatadaptionpart.

Steps 3.1, 3.1.1-3.1.3 arethesameasSteps1.2,1.2.1-1.2.3in thecollaborationfor a-Mail through

SMS.

15

¬ ­�®¯}°B±�²*³V´Zµ�¶R¶¡³H² · ¸q¶ ¹¬ ®�­º®Z¯}°�· ¸q¶ ¹

¬ ­º®Z¯}°�»�°}¯Wµ�¼H½¬ ­º³�¾>¯}°}µ�¿�¶¡µ�² À ·ÁH½}½}¹d¬ Â}Â*·�· Â;­�®¯W°W±�²*³V´Zµ�¶ ¶-³H² · ¸q¶ ¹ À ·�Ã�·�Ä�³H²�ÅÆ®�²*Çȹ�®q²*®qÉ#µR½�µq²¡¶Ã�·Á�½W½}¹d¬ ÂWÂ*·�· Â&®�­º®Z¯}°�· ¸q¶A¹

À ·�Ã�· Ê�·FË(µR½&Ä�¯}°}µ�±7®R½;Á+Ì&ͬÏÎ�­ºÐ%±�Ñ�®�¼>ÇV°}µq²

¬ ÒÆ°}¯}®�¶¡Ó�³(³�ÔÀ ·�ÃF·}ÃF·FË�µR½;¿�¶-µq²A­º®Z¯}°�Ì&Í

¬ Õ×Ö>³F½�®�­º®q¼�®ZË�µ�²

À ·�Ã�· À ·�¶¡µq¼�Ç(­�®¯W°�Ì&Í

¬ ­�®¯W°WØ�µF¶*Ö>°Ï½�· ¸q¶ ¹

Ê�·­º®Z¯}°(¹+®ZË(µ

Ù ·ÁH½}½}¹Ú²*µF¶ ¹+³�¼+¶-µ�Á>µ®ZÇVµq²Û ·­º®Z¯}°>²*µ�¶*Ö�°2½+¹�®ZË�µÜ ·ÁH½}½}¹d¬ Â}Â*·�· Â�­º®¯W°WØ�µF¶*Ö>°Ï½�· ¸q¶ ¹ À · Ê�·�Ä�³H²�ÅÆ®�²*ÇÚ¶¡µ�¼>ÇV¯B¼>Ë9²*µF¶*Ö>°Ï½

Figure12: Thecollaborationfor thea-Mail applicationthroughHTML or WML

Steps 3.2, 4, 5, and 6 aresimilar to Steps3.3, 4, 5, and6 in the login throughHTML or WML,

respectively. TheMailResult.jsp of the Outputcategory in the format adaptionpart

generatesthemail resultpage.

3.3 The File Explorer Application

This sectiondescribesthecollaborationfor theFile Explorerapplication.In Figure13, we show

the following usagescenarioasan exampleto illustratehow the SSM mechanismis appliedto

completeanapplication.

Ý First, theusersendstheshortmessagewith “ln Dir1 140.112.1.1Tool” to WIRAP to create

thevirtual directory“Dir1” (thatis linkedto the“Tool” directoryon theCIFSserverwith IP

140.112.1.1)on WIRAP.

Ý Then,theusersendstheshortmessagewith “cd Dir1” ro changethedirectoryto “Dir1”.

Ý Finally, theusersendstheshortmessage“dir” to WIRAP to list thenamesof thefiles and

directoriesin Dir1.

Step 1. Theusersendstheshortmessagewith “ln Dir1 140.112.1.1Tool” to theiSMSClient

throughtheiSMS server.

Step 1.1 is similar to Step1.1in thea-mailthroughSMS.TheiSMSClient retrievestheexecu-

tion registry of theuserfrom thedatabase.

16

Þ2ß�à�áâà�ãåä�ß}æZçVè Þ é�ê�ëíì¡î+æ�ä�äÞ áðïVñ+ß�ä�æåòXì æZóô�õ�ö�÷�øÚù ßWóZúûü õ�öù ßWó¡æ ÷ è ïVó�ý ù ßWóZú ÷ ó¡æ�þ�è æ ø û

ÞÏÿ��+ï�è þZáðþZç�þ��VæZó� õHö�ø ßWó�û

� õ�ö ã�î+þZç��Væ ø è ï ù ßBóúZû ú õ ü õ ú õH÷ ó�æ�þqè æë%ï>ßWç(è æZó��Þ2ã�� dà���þZç ø ä}æZó

Þ ê ÷�÷ ï��>çVè&áðþZç�þ��VæZóô�õ ü õ ü õ �Væqè&òXì-æZó*ë�� ø ��ô�õ ü õ2ô�õ�� ï���ç(è��ú õ ü�� ô�õ ü�� þZç ø � õ ü õ�� ï(ó��ÚþZó ø�� þZó�þ � æqè æZó-ì� õ ü õ ú õ�ø ßWó��

ú õ�ö äBç ù ßWóZúkú ��� õ ú>ú ü õ ú õ ú��fï>ï>ä�û

�õ�ö 7ß�ä�æ+ú � 7ß�ä�æ ü��"!$# Þ2ß�à+áKà�%.ç(è ß�è�ýú õ ú � ô�õ ú � þZç ø � õ ú õó�æHì*è ï(ó�æ�à�æHìRì ß�ï(ç��� ú õ ô � ô�õ2ô � þZç ø � õ2ô�õìAè ïVó�æ�à�æFì�ì ß�ï(ç�� ô�õ ü õ ú õ ß&ì ù ßWó¡æ ÷ è ïVó�ý��

Figure13: Thecollaborationfor theFile ExplorerapplicationthroughSMS

Step 1.2. Accordingto thecommand“ln”, theiSMSClient forwardstheparametersin theshort

messageto theRAPshell in theapplicationpartto starttheFile Explorerapplication.

Step 1.2.1. By checkingthe command“ln”, the RAPshell invokes the creatPointer()

memberfunction in QuotaManager in the RSSmanagementpart to createa virtual di-

rectory“Dir1”. In our implementation,thevirtual directoryis a file with theextensionfile

name“.cifs”, which containstheIP addressof theCIFSserver (i.e., 140.112.1.1in this ex-

ample),andthenameof thedirectory(to be linked)on theCFISserver (i.e., “Tool” in this

example).

Step 1.3. The iSMSClient invokes the storeSession() memberfunction in iSMSEn-

tity to storebackthestatusof thesession.

Steps 2. TheiSMSClient sendstheshortmessagewith “Directory Dir1 created”to theuser.

Step 3. Theusersendsthesecondshortmessagewith “cd Dir1” to theiSMSClient.

Steps 3.1 and 3.2 arethesameasSteps1.1and1.2.

Step 3.2.1. According to the command“cd”, the RAPshell invokes the isDirectory()

memberfunction in theQuotaManager to checkthe typeof “Dir1” (i.e., local directory

or virtual directory).If the“Dir1” directoryis a local directoryon WIRAP, thecd() mem-

berfunctionin theQuotaManager is invokedto changethedirectorydirectly. Otherwise

(e.g.,thedirectoryis avirtual directory),Steps3.2.2and3.2.3areexecuted.

Step 3.2.2. TheRAPshell readsthe“Dir1.cifs” file, andgetstheIP addressof theCIFSserver

andthe nameof the directoryon the CIFS server. Then, it invokesthegetUserPwd()

17

memberfunction in AccountManager in theRSSmanagementpart to get thepassword

of theuser(to beusedfor authenticationin Step3.2.3).

Step 3.2.3. The RAPshell object invokes the mount() memberfunction in the CIFSHan-

dler in the informationaccesspart to connectto the CIFS server, wherethe userID and

password(gotatStep3.2.2)arepassedto theCIFSserver. TheCIFSserverusesthereceived

userID andpassword to checkif theuseris allowed to accessthe “Tool” directory. If the

authenticationis not successful,this connectionfails. Otherwise(i.e., theauthenticationis

successful),Steps3.3and4 areperformed.

Steps 3.3 and 4 are similar to Steps1.3 and 2. The iSMSClient sendsthe short message

“Changedto Dir1” to inform the userthat the directory path hasbeenchanged. At this

moment,theusercanaccessthe“Tool” directory.

Step 5. Theusersendsthethird shortmessagewith “Dir” to theiSMSClient.

Steps 5.1 and 5.2 arethesameasSteps1.1and1.2.

Step 5.2.1. TheRAPshell invokesthedir() memberfunction in theCIFSHandler to re-

trieve the namelist of directoriesandfiles from the directory “Dir1” on the remoteCIFS

server.

Steps 5.3 and 6 aresimilar to Steps1.3and2. TheiSMSClient sendstheshortmessagecon-

tainingthenamelist of directoriesandfiles to theuser.

For theHTML or WML interfaces,thecollaborationsaresimilar, which arenot presentedin this

paper.

4 Performance Evaluation

In thissection,weevaluatetheperformanceof theWIRAP platformby executingnumerousoper-

ationson it. We simulate& mobileusersconcurrentlyconnectingto WIRAP throughtheHTML

interface,andapply thefollowing testingscenariofor eachuser. Theuserfirst loginson WIRAP

andthenusestheFile Explorerapplicationto list thenamesof files in hispersonaldiskquota.Let')(be the total responsetime for the & testingconnections.The responsetime is definedasthe

18

*+,-.�/.�0.�1/�./�2/�3+�*

4657 .�*�8�9;:=<�>@?

.�*�A .�*�B .�* 9 .�*�C .�*�DE

F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F FF FFF F F F FF F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F

F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F FF F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F FF F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F FF F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F FF F F F F F F F FF F F F F F F FF F F F F F FF F F F FF F F F FF F F FFF F FF F FF F FF F F FF F FF F FF FF F FF FF F FF FF F FF FF FF FF F FFFF F

G G G G

G

Figure14: Theperformanceevaluationfor theWIRAP

periodbetweenthe time whentheuserloginson WIRAP andthe time whenhis mobile terminal

displaysthefile namelist. Let'IH

betheaverageresponsetime for the & connections,thatis,

'JHLK 'L(& (3)

In our simulation,theWIRAP runson theOS“Microsoft Windows 2000”, andthehardwareis a

PCwith Pentium1.4 GHz CPUand256MB memory. Themobileusersconnectto theWIRAP

throughthe Ethernet.We measure')(

, andthencalculate'JH

by using(3). Figure14 plots the

averageresponsetime'JH

asa functionof & . When &NM �PO j , 'JH increasesslowly andis lessthan

0.052seconds.When &RQ �SO j , 'IH increasesrapidly. Specially,'JH

is 0.052secondswhen & =�SO j and'JH

is 0.247secondswhen & =�SO Õ . This phenomenonindicatesthatunderthesimulation

environment,themaximumnumberof theconcurrentconnections(whenuserscanhave satisfied

quality of services)is about�PO j .

5 Conclusion

In thispaper, wedesignedandimplementedaremoteaccessplatformWIRAPfor provisionof large

storagespaceandpowerful computationenvironmenttoenhancethecapabilityof themobiletermi-

nals.WeimplementedtheSMS,WML, andHTML interfacesontheWIRAP, anduserscanaccess

19

T�UWVYX

T UWV[Z

T UWV[\

T U]V_^`badc�c egfihkj

lnmpo[q l�m�osrlnmpo[tl m�osu

lvm]oWtl m�oYq

w)xyxdz�{|P}@~={����;�

���S�����"�

���S�����

���y�

��

��

�� }��_{|}

�

Figure15: Thestatemachineappliedin iSMSClient

the WIRAP by terminalswith differentnetwork capabilities.On the WIRAP, we developedthe

applications,a-Mail, e-Address,w-FTP, t-Editor, s-Asmin,andFile Explorerfor mobileusers.We

alsotestedthecapacityof WIRAP by runningit onPCwith Windows2000OS,Pentium1.4GHz

CPU,and256MB memmory. Thestudyindicatedthecapacityof theWIRAP is about�SO j users.

Theimplementationsof theWIRAPcanbefoundin http://pcs.csie.ntu.edu.tw/WIRAP/index.html.

Appendix

A The SSM mechanism

TheiSMSClient processestheshortmessagerequestfrom theuserandinvokestherequested

applicationfor the user. During the executionfor the application,theiSMSClient maintains

thestatusof thesessionfor theuserby following thestatemachineasshown in Figure15. The

statemachineconsistsof two sub-statemachines:thebasicstatemachine(Figure15 (a)) andthe

applicationstatemachine(Figure15 (b)). In thebasicstatemachine,two states,���i��� and ��&���� ,aredefined:

������� meansthattheuserdoesnot login on WIRAP.

��&i�p� meansthat the user has beenauthenticatedand preparesto executeapplicationson the

WIRAP.

For eachapplicationontheWIRAP, thereis acorrespondingapplicationstatemachine.Thestates

in an applicationstatemachinearedefinedaccordingto the commands(e.g., “dir” for the File

20

���� ���¡£¢  _¡ ��¤]¥�¤p¦§�¨ª©�«"¬�­y®�¯�°"± ²y³k´¶µ§�¨ª©�«�±�°�¯�®S­"¬ ·P¸ ¹º¹»¹

¹º¹»¹

¼¾½�¿ ¡À ´k³kÁÃÂ�Ä�²y³�Å�Æ]Á�ÆÇ ²�²y³k´kÈ@Éʸ=´kÅ�µ)«Ë�Ì�ÍpÌ

Ë�ÎWÏ Ð ¼ÒÑdÑÔÓkÕÖ ¥�¤ Õ×�ØÔÙ�Ú ¦ Ó ¥�¤]¦@ÛÝÜ Õ ¦ Ó ÛÔÞ

Figure16: Theexecutionregistry for themobileuser

Explorerapplication)usedin the correspondingapplication.Note that, if theWIRAP receivesa

shortmessagefor whichthereis nocorrespondingtransition,thismessageis dropped,andthestate

is not changed.

TheiSMSEntity maintainstheexecutionregistry in theexecutionregistry databaseto keep

the stateof the statemachinefor the user, which consistsof MSISDN, ID, State, APID, and

Application-relatedfields (seeFigure16). TheMSISDN field storestheMSISDN numberof the

mobileuser. This numberis carriedin theshortmessage,which is usedasa searchingkey in the

executionregistry database.TheID field specifiestheusername.Thestate field storesthethe

currentstateof thestatemachinefor theuser. TheAPID field storesthenameof theapplication

currentlyusedby theuser. TheApplication-relatedfieldsstorethevaluesof variablesusedby the

application.

References

[1] 3GPP.3rd GenerationPartnershipProject;TechnicalSpecificationGroupServicesandSys-

temsAspects;GeneralPacketRadioService(GPRS);ServiceDescripton;Stage2. Technical

ReportTechnicalSpecification3GTS 23.060version4.1.0(2001-06),2001.

[2] Eduardo,P.-L. Java Server Pages(Ôß

Specification. TechnicalReport Version 1.2, 27-

Auguest,SunMicro-SystemsInc., 2001.

[3] ETSISMG. Userof DataTerminalEquipment-DataCircuit Terminating;Equipment(DTE-

DCE) Interfacefor ShortMessageservice(SMS)andCell BroadcastService(CBS) (GSM

07.05version5.3.0). TechnicalReportRecommendationGSM 07.05,ETSI/TC,1997.

[4] ETSISMG. Digital cellulartelecommunicationssystem(Phase2+); Technicalrealizationof

theShortMessageService(SMS);Point-to-Point(PP)(GSM03.40version7.2.0).Technical

ReportRecommendationGSM03.40,ETSI/TC,1999.

21

[5] ETSI/TC.Digital cellulartelecommunicationssystem(Phase2+); GeneralPacketRadioSer-

vice (GPRS);Servicedescription;Stage2 (GSM03.60version7.0.0Release1999).Techni-

calReportRecommendationGSM03.60,ETSI,1999.

[6] Fielding,R.,Gettys,J.,Mogul, J.,Frystyk,H., Masinter, L., Leach,P., andLee,T.-B. Hyper-

text TransferProtocol– HTTP/1.1.TechnicalReportRFC2616,June1999.

[7] IEEE. TheInstituteof ElectricalandElectronicsEngineers;WirelessMediaAccessControl

(MAC) andPhysicalLayer(PHL) Specifications:Higher-SpeedPhysicalLayerExtensionin

the2.4GHzBand.TechnicalReport802.11b,September1999.

[8] Kantor, B. andLapsley, P. Network News TransferProtocol. TechnicalReportRFC977,

February1986.

[9] Lee,T.-B., Masinter, L., andMcCahill, M. Uniform ResourceLocators(URL). Technical

ReportRFC1738,March1987.

[10] Lin, Y.-B. andChlamtac,I. WirelessandMobile NetworkArchitectures. Addison-Wesley,

2001.

[11] Lindholm, T. and Yellin, F. The Java(Ôß

Virtual Machine SpecificationSecondEdition.

Addison-Wesley, 1999.

[12] Network Working Group. ProtocolStandardfor a NetBIOSServiceon a TCP/UDPTrans-

port: ConceptsandMethods.TechnicalReportRFC1001,March1987.

[13] Network Working Group. ProtocolStandardfor a NetBIOSServiceon a TCP/UDPTrans-

port: DetailedSpecifications.TechnicalReportRFC1002,March1987.

[14] Postel,J.-B. SimpleMail TransferProtocol.TechnicalReportRFC0821,August1982.

[15] Rao,H. C.-H.,Chang,D.-F., andLin, Y.-B. iSMS:An IntegrationPlatformfor ShortMessage

ServiceandIP Networks. IEEENetworks, March/April 2001.

[16] SNIA. StorageNetworking Industry Association;CommonInternetFile System(CIFS)

TechnicalReferrence.TechnicalReportRevision: 1.0,2002.

[17] TheApacheSoftwareFoundation.TheApacheJakartaProject.http://jarkata.apache.org.

22

[18] WAP Forum. WirelessApplicationProtocol: ArchitectureSpecification.TechnicalReport

Version30-April, 1998.

[19] WAP Forum. WirelessApplicationProtocol:WirelessMarkupLanguageSpecificationVer-

sion1.1. TechnicalReportVersion16-Jun,1998.

23