iMobile: A Proxy-Based Platform for Mobile Services Chung-Hwa Herman Rao* Network Services Research Center AT&T Labs - Research *Currently with AT&T Wireless +886-2-29505401
Yih-Farn Robin Chen Network Services Research Center AT&T Labs - Research Florham Park, New Jersey, USA +1 973 360-8653
[email protected]
[email protected] Di-Fa Chang Computer Science Department University of Southern California Los Angles, California, USA +1 (213) 740-7287
Ming-Feng Chen Department of Computer Science and Information Engineering National Chiao-Tung University Hsin-Chu, Taiwan
[email protected]
[email protected] ABSTRACT iMobile is a proxy -based platform that addresses the research issues in building mobile services. iMobile acts as a message gateway that allows mobile devices using various protocols on different access networks to relay messages to each other. It also allows these clients to access internet services, corporate databases, and to control various networked devices. iMobile implements three key abstractions: devlet, infolet, and applet. A devlet is a driver attached to the proxy that receives and sends messages through a particular protocol for mobile devices. An infolet hosted on iMobile uses an access method to provide an abstract view of an information space. An applet implements service or application logic by processing information from various infolets. The core of iMobile, the let engine, implements the basic framework for maintaining applets, devlets and infolets, supports user and device profiles for personalization and transcoding, and invokes proper applets and infolets to answer requests from a devlet. The iMobile architecture allows new access devices and protocols to be added to its framework without changes in the service logic. iMobile effectively provides a personal agent on the network that enables a user to have mobile access to the vast information and services available on the various wireless and wireline networks, without being limited by where the user is or what device or communication or protocol is available.
Categories and Subject Descriptors D.4.4 [Computer-Communication Networks]: Protocols – applications, protocol architecture.
Network
General Terms Design, Experimentation, Languages, Security, Standardization.
Keywords Proxy, Mobile Computing, Wireless, POP3, IMAP, SMS, WAP, X10, Home Network, Telnet, Instant Messaging, GSM, TDMA, CDPD, TCP/IP.
1. INTRODUCTION The rapid advances recently in mobile devices, wireless networking, and messaging technologies have given mobile users a plethora of choices to access internet contents and services. Unfortunately, all these devices and protocols, such as Palm PDA with Web Clipping [12], cell phones with Wireless Application Protocol (WAP) [20] or Short Message Service (SMS) [8], email devices (Blackberry, AT&T PocketNet phone, etc.) that support POP3 [9] or IMAP [5], Pocket PC’s that support instant messaging through AOL Instant Messenger (AIM) [1], etc., do not communicate with each other easily. A mobile user faces the dilemma of wanting the convenience of mobile access to critical services and, in the mean time, suffering from managing the complexity of these incompatible devices and user interfaces [21]. The nature of wireless Internet is very different from simply accessing the Internet wirelessly. Wireless users, being mostly mobile, have different needs, motivations and capabilities from wireline users. A mobile user is usually in a multi-tasking mode
(accessing the internet while attending a meeting or shopping in the mall). The accesses are usually bursty in nature (checking stock quotes, weather, or finding a nearby restaurant) and very task-oriented; browser-centric applications and elaborate user interfaces simply do not fit their needs. Compared with office phone numbers or static IP addresses, cell phone numbers or instant messaging screen names are frequently more effective global personal ID’s to get in touch with mobile users. Finally, a mobile user may not always access the Internet wirelessly, and a wireless user may not be mobile at all [17]. Our goal is to allow mobile users to access all services critical to them wherever they are and whatever devices or communication channels are available.
engine and the user and device profiles that are used in personalization and transcoding services. Sections 4 discusses related work and issues on security. Section 5 summarizes and concludes with future directions.
2. ARCHITECTURE OF IMOBILE The iMobile architecture aims to hide the complexity of multiple devices and content sources from mobile users. It is built by leveraging established technology components in iProxy [14], a programmable proxy server that provides an environment for hosting agents and personalized services, which are implemented as reusable building blocks in Java. An iProxy agent can be invoked like a regular CGI (Common Gateway Interface) program as iProxy provides a built-in web server. iProxy also allows scripts embedded inside web pages to invoke agents to perform specialized processing. iProxy was originally designed to be middleware between HTTP clients and web servers. It maintains user profiles and adds intelligence to the traditional HTTP proxy server to provide personalized [13] and value-added services such as filtering, tracking, and archiving services[14]. As shown in Figure 2, iMobile added three main abstractions to iProxy: devlets, infolets, and applets. These components communicate with each other through the let engine. All these components are implemented as iProxy agents. The following subsections describe the detailed interactions among these agents in the iProxy environment.
Figure 1. Accessing iMobile Services Through Various Devices and Networks iMobile is a platform to provide personalized mobile services with the aforementioned needs of mobile users in mind. In a typical configuration as shown in Figure 1, iMobile runs on a computer with connections to the Internet and a cell phone with two-way short messaging service (SMS). Many devices can communicate with iMobile through various protocols and access networks. GSM/TDMA phones with two-way SMS can communicate with iMobile through an SMS driver hosted on iMobile. CDPD devices (such as AT&T PocketNet phone and Palm V with the Omnisky modem) can use WAP to access iMobile through the internet. Email devices such as Blackberry can use the standard email protocols (SMTP) on the CDPD network or a two-way paging network to communicate with iMobile. Users on PC devices and some PDA's can use AOL instant messenger or web browsers to connect with iMobile. iMobile also supports a TCP interface.. iMobile receives messages and commands from these devices, accesses internet services and information on behalf of the mobile user, and then relays messages or internet content back to the sending devices or other devices. The rest of the paper is organized as follows. Section 2 gives some background on a programmable proxy that iMobile uses, and discusses the architecture of iMobile and its three main abstractions: devlet, infolet, and applet. Section 3 discusses the let
Figure 2. iMobile Architecture
2.1 Devlet A devlet is an iProxy agent that provides a protocol interface to a device on a particular access network. Each devlet interacts with the let engine with a well-defined interface: it receives each request as a character stream, and returns results in a MIME (Multipurpose Internet Mail Extensions) type acceptable by the receiving device. When iMobile is started, a devlet for each communication protocol supported by iMobile is started to listen to incoming requests sent through that particular channel. For example, the AIM devlet on iMobile starts an AIM client and
listens to service requests from other AIM clients sent as instant messages. The required device driver that speaks a particular protocol may co-locate with the devlet or it may communicate with the devlet through a TCP protocol. This approach allows a device driver to run on a remote machine, other than on the iMobile server. For example, Figure 3 shows that an SMS devlet running on the iMobile server communicates with the GSM cell phone attached to a remote PC through an SMS driver [16]. Mobile users can send messages to this cell phone (through the GSM network), which then forwards each message to iMobile for processing. The result is then returned to the user through the same channel. Currently, iMobile supports devlets that understand the SMS protocol, the IMAP email protocol (to retrieve emails), the AIM protocol, the ICQ protocol, and the Telent protocol. iMobile also supports the WAP and HTTP protocols through the iProxy HTTP interface. To allow access to iMobile through email, the iMobile email devlet constantly monitors messages arriving at a particular email account for new service requests. For TCP users, a TCP session is created if someone tries to connect to a particular port of the iMobile machine using the telnet protocol. A telnet user can enter iMobile commands as if using a typical Unix or Windows terminal. While all these protocols and the devices that support them have different user interfaces, each devlet always interacts with the let engine in the standard way described above: a devlet sends a character stream, interpreted as an iMobile command and associated parameters, to the let engine. A devlet then receives results from the let engine formulated in a MIME type appropriate for that device, which is determined by the corresponding device profile stored at the let engine (See Section 3). Each iMobile command invokes an applet that corresponds to a service with a set of service parameters.
The naming of each device or destination follows the URL naming scheme: protocol name followed by an account name or address. For example, typical destination addresses include sms:+19737086242 (GSM cell phone), aim:sunshine4 (AIM buddy name), mail:
[email protected] (email id), etc. As an example of an iMobile request, to access the stock price of AT&T (T), an iMobile user would invoke the quote applet and issue quote T If the request is sent using SMS on the GSM network, then the result will be returned as plain text to the receiving GSM cell phone. On the other hand, if the mobile user wants to forward the result to
[email protected], he will issue forward mail:
[email protected] quote T Since that email account understands the MIME type text/HTML (according to the device profile), the result will be sent by the let engine as an HTML file, complete with graphics, to
[email protected]. The devlet abstraction allows users on different networks to easily communicate with each other. For example, if a GSM phone user wants to send a message to (a) an AT&T PocketNet mail account
[email protected], which is on the CDPD network, and also (b) an AT&T TDMA phone 908-500-6531 (chen’s cell phone) using SMS, then he can use the echo applet, a message relay service: forward mail:
[email protected],attmsg:9085006521 echo call your boss In this case, the sender really wants to reach a person, not a device. Since iMobile has the user to device map (see Section 3.3) and it keeps track of the user’s last access from a particular communication channel, it would be desirable to use an alias such as $chen, instead of listing the device ID’s, to reach either all of the user chen’s devices or the last device that chen uses.
2.2 Infolet The infolet abstraction extends beyond the HTTP protocol and URL name space to provide abstract views of various information spaces. Each infolet retrieves or writes to an information space using an access protocol appropriate for the information source available. Retrieved information may be passed to an applet for further processing. Examples of information spaces include
•
Figure 3: Communication Path Between SMS Devices and iMobile
Stock quote, weather, flight schedule, etc.: Information in this category is commonly available on many websites, but it would be the best to retrieve such information from XML files or databases directly. For example, Figure 4a shows an AIM client, YihFarn, that talks to an iMobile AIM agent, imobiledev. It issued the "flight 008" command to get flight
information on the NorthWest airline and received the concise output that includes time and gate information of each leg of the flight. The mapping from the flight command to the NorthWest airline can be controlled by the applet by consulting the user profile (see Section 3). Also, the let engine invokes necessary transcoding services to map the elaborate content on the website to a format appropriate for the receiving device using AIM. As another example, Figure 4b shows a Palm V (with a wireless modem) that just sent an email to the iMobile email devlet (
[email protected]) with the command "sitenews att". This command instructs iMobile to access the service provided by AT&T's Website News [4], which reports today's new hyperlinks on AT&T's website (http://www.att.com). The result is sent back as an email formatted for the Palm V device.
Figure 5: Accessing Corporate Database Through iMobile's JDBC Infolet
•
Corporate Database: This is typically accessed through the JDBC and ODBC interfaces. iMobile hosts a JDBC infolet that allows mobile users to access or update enterprise database information (employee data, marketing/sales data, system interface data, etc.) through SQL-like queries. For example, Figure 5 shows how a user connects to an enterprise database through a Telnet client to find the full name of a particular service. One can also access the same information from a PDA that supports AIM. In any case, it is critical that only end-to-end solutions are used for mobile access to corporate databases.
•
Network/Infrastructure Resources: This is typically accessed through the CORBA (Common Object Request Broker Architecture) interface. CORBA is an architecture and specification for managing distributed program objects in a network. It allows programs at different locations to communicate through an "interface broker." iMobile hosts a CORBA infolet that allows mobile users to request services from CORBA objects. Figure 6 shows how an AIM user gets phone diversion information for the user Herman by using the CORBA infolet to access a Phone server..
•
Mobile Control of X10 Home Network Devices: The X10 home network technology allows lamps and appliances connected on the same power line to be controlled by a computer. iMobile hosts an X10 infolet that controls home network devices connected to its server machine. Figure 7 shows how an iMobile user controls X10 devices remotely. First, the user instructs iMobile to locate firecraker, the device that is capable of sending a radio signal to a transceiver device on the X10 network, through the serial port COM2 on the iMobile server. After the connection is established, he sends the command "x10 on a1" to turn on the fan (which is named device a1 on that particular X10 network) and "x10 on a2" to turn on the coffee pot. The integration of iMobile and the X10 interface allows a mobile user to control the lighting and appliances at home with a cell phone, an instant messaging client, or any mobile device supported by iMobile anywhere in the world. The X10 infolet also demonstrates
Figures 4a: Accessing Flight Info Through iMobile on AOL Instant Messenger
Figures 4b: Accessing Website News Through iMobile using an Email Client on Palm V
that an infolet can be used to both retrieve and change the state of an information space. An applet can use an algorithm to determine when and how to activate certain X10 devices to control a home environment. Note that we call the interface that controls X10 devices an infolet, not a devlet, because (a) each devlet must be able to send at least a plain text command to iMobile, and (b) the state of all the X10 devices is considered an information space that can be retrieved or altered.
Figure 7: Mobile Control of the X10 Home Network
Figure 6: Using iMobile to Access CORBA Objects
•
Emails on Mail Servers: iMobile supports an IMAP infolet called inbox that can query and view a user's email account; however, this requires that the user trusts iMobile with his or her encrypted email password. Figure 8 shows that a mobile user first checks the status of his inbox to find the number of unread messages. He then looks at the size (message 37 has 728 bytes), subject, and sender of that message before actually viewing it. Such interaction style is typical for a mobile user with limited bandwidth and screen space on his or her communication device.
Figure 8: Mobile Access of a Person's Inbox
2.3 Applet An applet implements business or application logic by processing contents from different sources and relaying results to various destination devices. A simple applet is the echo applet described in Section 2.1, which simply sends a message from one device to another without using any information sources. An applet can also have complex interactions with other infolets. For example, The following code shows a FindMeAMovie applet implemented as an iProxy script (instead of a typical Java class). The applet finds theaters near a cell phone user that are currently showing the top ten movies by executing the following steps: (a) get the location (zip code) of the cell phone user, (b) find the top 10 movies from a movie database or website, (c) for each of these movies, find out if any local theater shows that movie, (d) list the move title and the theater.
#!/iproxy/script # get the localtion information (zip) :javabin infoLet zip getlocation # get top10 movies (mlist) :javabin infoLet mlist top10 movie :foreach mtitle ${mlist} # Find theaters -- Movie: ${mtitle} -:javabin infoLet thlist findTheater ${mtitle} ${zip}
3. THE LET ENGINE AND USER/DEVICE PROFILES The let engine in iMobile receives commands from devices, translates the commands according to user aliases and profiles, and then forwards the service request to to the right applet or infolet. The let engine also invokes the appropriate transcoding service to convert results returned from infolets or applets to a format appropriate for the target device. All devlets, infolets, and applets must be registered at the let engine first before communications with other agents can occur. The following subsections describe device and user profiles in detail.
3.1 Device Profile Every abstract device that communicates with iMobile must register its profile information with the let engine first. A device name is protocol:acct_id. For example, an AIM user webciao is named aim:webciao. iMobile maintains a default profile for each device type, but each instance of a device can overwrite that profile with device-specific information. A device profile is simply a list of attribute-value pairs. The most important attribute is dev.format.accept, which determines what MIME type the device is allowed to accept. This information is used by iMobile to transcode original content to a format appropriate for this device. For example, the default profile for an email device is the following and is simply named mail.ini in the directory where device profiles are kept: dev.format.accept=text/html,*/* dev.page.size=-1 It indicates that the default MIME type is text/html, but all MIME types(*/*) are acceptable. Also, the page size "-1" indicates that there's no limit on the size of each message transmission. These values are inherited by all mail devices unless they are overwritten. For example, while the two default values might be valid for primary email devices (desktop or laptop PC's), they are not appropriate for emails used on cell phones, such as AT&T's PocketNet phone. The following device profile for that phone indicates that only the MIME type text/plain is
:foreach theater ${thlist} # List the title & theater ${theater} :endfor :endfor
appropriate for this device (mail:
[email protected]) and it does not accept messages longer than 230 characters: dev.format.accept=text/plain dev.page.size=230 A devlet is modeled as a special device hosted on iMobile. It requires more information in the device profile to tell iMobile how and when to access this device. For example, the following profile for
[email protected], used by the email devlet of iMobile, specifies the frequency (every 10 seconds) of checking the email account(store.checktime), the account password(store.url), the transport protocol for sending emai(transport.url), last time the user accessed the account(cmd.lasttime), etc. mail.store.checktime=10000 mail.store.url=imap://imobile:password@bigmai l mail.transport.url=smtp://bigmail ...
3.2 Device to User Mapping Each device that attempts to access iMobile services has to be mapped to a registered iMobile user. There are two reasons for this requirement: (a) limiting access to legitimate iMobile users only and (b) to personalize a service based on the user profile. A typical device-to-user map stored under iMobile (rarp.ini) looks like this: sms:+886936731826=herman sms:+19087376842=chen mail:
[email protected]=difa aim:webciao=chen ...
3.3 Device Profile The way iMobile authenticates a mobile user depends on the device or protocol used. iMobile trusts wireless networks such as Voicestream GSM or AT&T TDMA networks in North America to provide the correct cell phone id when a short message is received. This is generally acceptable unless a cell phone is stolen and the user did not lock the phone with a security password. Currently, iMobile also trusts the AOL network's authentication for non-critical services. User authentication through iMobile itself
is required if the user accesses iMobile through Telnet, WAP, or HTTP. Following is a typical and simplified iMobile user profile: name=Robin Chen password=xf2gbH3 default=$mail.1 # my addresses sms.1=sms:+19087376842 mail.1=mail:
[email protected] mail.2=mail:
[email protected] mail.all=$mail.1,$mail.2 aim.1=aim:webciao # command aliases sms.cmd.q=quote sms.cmd.sn=sitenews # address aliases sms.addr.cc=aim:chrischen The above user profile stores the user name, password, and a list of the devices that the user registers with iMobile. It also stores command and address aliases. When a user accesses iMobile through AIM using the id webciao, iMobile determines from the user-device map that the user is chen and will use the user profile chen.ini for all later service requests from this device. For example, the following short message sent from a GSM phone: forward $mail.1 q T will be interpreted as forward mail:
[email protected] quote T according to the user profile. The special character "$" requests that iMobile maps the named device (mail.1) to its corresponding entry in the profile.
4. RELATED WORK Many researchers have recognized the flexibility that a proxy can provide to the implementation of new services. The WBI project [3] from IBM uses intermediaries to produce and manipulate web content, perform content distillation, and implement protocol extensions. Recently, a transcoding proxy was introduced as a web intermediary between Web servers and client devices to adapt to the varying bandwidths of different client communication links. Similarly, TranSend [7], a scalable transformational Web proxy from UC-Berkeley, focuses on how datatype-specific content distillation can be efficiently implemented by deploying infrastructural proxy services. iMobile differs from both approaches by focusing on how a proxy -based platform can use a uniform interface (character stream/MIME type) built in the devlet abstraction to deal with a variety of devices and their protocols, beyond what a web proxy typically handles. The recent ICEBERG project [18], also from UC-Berkeley, shares the iMobile goals of any-to-any communication services and personal mobility services, but has so far concentrated mostly on voice, rather than data services.
A proxy may not always be the best place to perform transcoding; it might waste the bandwidth if a lot of contents downloaded to the proxy are later discarded due to the limited screen size or bandwidth of the receiving device. Furthermore, the content provider may prefer to perform its own transcoding service to fully control the outcome. The Apache Cocoon [2] project allows the automatic generation of HTML, PDF, and WML (for WAP devices) files through the processing of statically or dynamically generated XML files using XSL and XSLT. We have also started to experiment with XML and XSLT technologies in our transcoding service inside the let engine. Before transcoding can occur, whether on the proxy or on the server, some kind of device profile must be provided to describe the characteristics (size, format, etc.) of the receiving device. To address this problem, several companies have started a W3C working group called CC/PP (Composite Capabilities/Preferences Profiles)[10] to create a structured and universal format that allows a client device to tell an origin server or proxy about its profile. We are currently monitoring the progress of this protocol and may migrate to its format when it receives wide support from the industry. Since iMobile interacts with multiple networks and protocols, it has to rely on different authentication mechanisms. Currently, we use the cell phone id on wireless phone networks, AOL buddy names on the AIM network, and generic user id and password for WAP, HTPP, and telnet clients. However, iMobile itself does not have control over how secure these networks are. Solutions such as Charon [6] and the SSH Secure Shell should be introduced to provide end-to-end authentication services. Charon is interesting as it focuses on how to secure the connection between the client and an application-level proxy. The Charon approach allows the client module to be extremely lightweight and amenable to implementation on most PDA and mobile devices. Most of the computations needed to conduct the Kerberos [16] protocol and establish a secure channel are located at the proxy. We are looking into the adoption of a Charon-like implementation for iMobile clients. Remote control of X10 home network devices is not new. The Aladdin project[18] from Microsoft Research also allows a user to use email to remotely control his or her X10 devices (such as the garage door opener). However, the focus of the Aladdin project is home automation (and it's reliability concerns), while the focus of iMobile is mobility; home automation is just a simple application built on top of the flexible iMobile architecture.
5. SUMMARY AND FUTURE WORK iMobile introduces three abstractions on top of an agent-based proxy: devlets to interact with various access devices and protocols, infolets to access multiple information spaces, and applets to implement application and service logic. The let engine
arbitrates the communications among devlets, applets, and infolets. It maintains user and device profiles, which are used to provide personalized services and to perform transcoding before returning contents to receiving devices. We have started to integrate iMobile with location services to further reduce the parameters (zip code, longitude, latitude, etc.) that a mobile user is required to enter to access useful information (nearby restaurants and hospitals, etc.). We are also experimenting with Voice XML technologies to provide a voice-based devlet for information retrievals. Finally, while iMobile currently satisfies most service requests instantly, except when it is constrained by the wireless networks (occassional slow SMS delivery), we need to conduct performance measurements to see how scalable the service is and to consider various deployment strategies. Our vision for iMobile is to allow a user to have true mobile access to the vast amounts of information available on various wireline and wireless networks regardless of where the user is and what device or communication protocol is available. The modular architecture also allows developers to write device drivers, information access methods, and application logic independently from each other. Additional information about the iMobile software can be found at http://www.research.att.com/sw/tools/imobile.
6. ACKNOWLEDGMENTS Rittwik Jana and Huale Huang helped with the integration of iMobile with location-tracking technology from AT&T Labs. Chris Rath, Matt Green and Jim Rowland helped with the service provisioning of iMobile and added several new infolets. Fred Douglis, Hau Le, and several other reviewers provided helpful comments.
ACM Conf. on Mobile Computing (MobiCom 96), White Plains, New York, Nov. 1996.
[7] Fox, Armando. Gribble, Steven. Chawathe, Yatin. and Brewer, Eric A. Adapting to Network and Client Variation Using Active Proxies: Lessons and Perspectives, IEEE Personal Communications, Vol. 5, No. 4, August 1998.
[8] GSM Association, An Overview of SMS, http://www.gsmworld.com/technology/sms.html .
[9] Myers, J. and Rose, M. Post Office Protocol - Version 3, http://www.isi.edu/in-notes/rfc1939.txt , RFC1939, Network Working Group, Internet Engineering Task Force, 1996.
[10] Nilsson, Mikael. Hjelm, Johan. Ohto, Hidetaka. Composite Capabilities/Preference Profiles: Requirements and Architecture, W3C working group, http://www.w3.org/Mobile/CCPP/, 2000.
[11] Infospace, Inc. http://www.infospace.com, 1999. [12] Palm, Inc., Web clipping, http://www.palmos.com/dev/tech/webclipping/ .
[13] Rao, H. Chen, Y. Chen, M. Chang, J. A Proxy -Based Personal Portal, in Proceedings of the WebNet99 Conference, Hawaii, October 1999.
[14] Rao, H. Chen, Y. Chen, M. A Proxy -Based Web Archiving Service, in Proceedings of the Middleware Symposium, Portland, Oregon, July 2000.
[15] Rao, H., Chang, D.and Lin, Y. iSMS: An Integration Platform for Short Message Service and IP Network, 15(2): 2001, 48-55.
[16] Steiner, J. Neuman, B. and Schiller, J. Kerberos: An Authentication Service for Open Network Systems, In Proceedings of the Winter 1988 Usenix Conference, pages February 1988, 191-201.
[17] Varshney, U. Recent Advances in Wireless Networking, 100-
7. REFERENCES [1] America Online, Inc. AOL Instant Messenger, http://www.aol.com/aim . [2] The Apache Group, The Apache Cocoon Project, http://xml.apache.org/cocoon/index.html, 2000. [3] Barrett, Rob. and Maglio, Paul P. Intermediaries: New Places for Producing and Manipulating Web Content , in Proceedings of the Seventh International World Wide Web Conference, Brisbane, Australia, 1998.
[4] Chen, Y. and Koutsofios, E. WebCiao: A Website Visualization and Tracking System, in Proceedings of WebNet97, Toronto, Canada, October, 1997.
[5] Crispin, M. Internet Message Access Protocol, http://www.isi.edu/in-notes/rfc2060.txt , RFC2060, Network Working Group, Internet Engineering Task Force, 1996.
[6] Fox, Armando. and Gribble, Steven. Security on the Move: Indirect Authentication using Kerberos, in Proc. Second
103, IEEE Computer, June 2000, 100-103.
[18] Wang, H. Raman, B. Chuah, C. Biswas, R. Gummadi, R. Hohlt, B. Hong, X. Kiciman, E. Mao, Z. Shih, J. Subramanian, L. Zhao, B. Joseph, A. and Katz, R. ICEBERG: An Internet-core Network Architecture for Integrated Communications, IEEE Personal Communications (2000): Special Issue on IP-based Mobile Telecommunication Networks.
[19] Wang, Y. Russell, W. and Arora, A. A Toolkit for Building Dependable and Extensible Home Networking Applications, in Proc. 4th USENIX Windows Systems Symposium, August 2000.
[20] The WAP Forum, Wireless Application Protocol, http://www.wapforum.org/ .
[21] Wildstrom, Stephen H. Should Coffeepots Talk? Business Week, November 8, 1999, page 22.
