Wireless access to a content routing system

Wireless access to a content routing system

Junbiao Zhang
C&C Research Laboratories, NEC USA Inc.
4 Independence Way
Princeton,NJ 08540
+1 609 951 2910
junzhang@nec-lab.com
Remo Strotkamp
C&C Research Laboratories, NEC USA Inc.
4 Independence Way
Princeton,NJ 08540
+1 609 951 2922
remo@nec-lab.com

ABSTRACT

We present in this paper our experience in providing a wireless access interface to a distributed content search and delivery system. Important Wireless Application Protocol (WAP) gateway functions, in particular the Push function, are integrated into the access points of the system. Wireless devices can use this interface to search for distributed information and get notified of relevant new content. A prototype implementation of the integration has been completed which works successfully with WAP 1.2 compliant clients.

Keywords

WAP gateway, Push, Kannel, ANSWER system, content routing

1. INTRODUCTION

The Wireless Application Protocol (WAP) is a suite of protocol solutions for providing web content to wireless devices. It enables wireless devices with small screen sizes and slow, lossy communication channels to access web content in a more efficient and natural way. In this paper, we describe our experience in integrating the WAP framework into the ANSWER information system[1]. ANSWER is a distributed content search and distribution system which provides an infrastructure directly connecting information providers and consumers. A symmetrical interaction model allows users to directly search for results or get notified by the system through content distribution based on prior interest indication. The core of the system serves as a distributed information base and search engine which can be built upon either an active network or an overlay application layer network. On the edge (access points) of the system, a consistent interface is provided for both content provision and search result delivery through the use of XML[2]. For search users, both web access and WAP access are provided for submission of queries as well as display of search results and new content alerts. In order to allow for wireless access, WAP gateway functions are introduced into the ANSWER system. In particular, the push feature of WAP is used as a natural means to distribute new content to interested clients. We discuss in the rest of the paper how we build the most essential gateway functions into the ANSWER system and show through examples how wireless devices interact with the system through the WAP interface.

2. ANSWER: core and edge

Due to space constraint, we shall only give a very brief overview of the ANSWER architecture. Interested readers can refer to [3] for a detailed description of the system.


Figure 1: The ANSWER system

ANSWER is built upon a concept referred to as ``information routing'' and a symmetrical interaction model between information providers and consumers. In short, ``information routing'' is an extension to the traditional network routing functions with information discovery mechanisms. An ``information routing'' capable network thus can route not only packets with specific destination addresses but those that only contain the specifications of their interests. Two types of information routing can be distinguished. In the first type, packets searching for particular areas of information are routed to the relevant information providers. This is referred to as query routing. In the second type, packets containing certain information are distributed to their targeted audience, or interested information consumers. This is referred to as distribution routing. The ANSWER system supports both query routing and distribution routing which are realized in a cooperative and symmetrical way. These are reflected in the way that the content providers and the information consumers interact with each other. Both parties may choose to inject active packets containing content descriptions or information requests into the active network. Information routing then serves as the bridge to matching entities. For convenience, we shall refer to the entity providing content information as the ``feeder'' and the one injecting requests as the ``seeker''. Thus query routing in ANSWER is responsible for routing ``seeker'' packets based on the ``feeder'' information in the system. Similarly, ``feeder'' packets are directed through distribution routing using the interest traces left by the ``seeker'' packets.

For efficient information storage and distribution in the network, only indexing information, instead of whole application data sets is stored in the network and such information is properly distilled (merge) when necessary. This makes the ANSWER system architecture highly scalable. A wide spectrum of applications ranging from e-commerce transactions to software distributions can be supported by the ANSWER system and new applications can be easily added into the system. Such a flexibility is made possible by several factors: On the edge of the system, XML is used as a uniform interface for content specification. Through the use of DTDs and XSL[5] files, content data with application specific syntax and semantics are converted into directory indices for distribution. These indices are eventually propagated into the ANSWER core through periodic routing information exchange among the ANSWER nodes. For the end users, ANSWER edge nodes provide interfaces for both web browsers and WAP enabled wireless devices. These interface modules are implemented as Java Servlets. User queries are transformed into ANSWER format through JavaScript or WMLScript. They are then injected into the ANSWER system and aggregated into query indices for distribution into the ANSWER core. These indices serve as indication of user interests which are used to direct content packets. Search results, when routed to the edge nodes, are converted into HTML or WML format using application specific XSL files.

3. The Wireless Application Protocol

The Wireless Application Protocol (WAP) is a suite of protocol solutions for providing web content to wireless devices.


Figure 2: The WAP operation model

Figure 2 shows the WAP operation model. As we can see from the figure, the gateway serves as an important intermediary between the wireless devices and the web servers. As we explained earlier, the Internet oriented protocols are not optimized for wireless accesses primarily due to the low bandwidth and high loss rate nature of the wireless channels. Further, the limited screen sizes of the most mobile wireless devices prohibit the proper display of full featured HTML pages. Other limitations of the wireless devices such as small memories and slow CPUs also dictate that wireless devices do not have enough power for sophisticated processing. It is thus necessary for the WAP gateway to provide support for protocol bridging and content conversion(such as compiling WML pages into byte code). To understand the discrepancy of the WAP and the web protocol stacks and the gateway functionalities, we compare the WAP hierarchy and the web protocol layers in Figure 3. The current web is built upon the Internet infrastructure with IP as the unified network layer protocol. On top of IP, transport layer protocols such as TCP (Transport Control Protocol) and UDP (User Datagram Protocol) provide end to end connectivities between transport entities. Using the reliability guaranteed by TCP/IP, the HTTP (HyperText Transport Protocol) protocol defines the interactions between web browsers and web servers in exchanging information. Finally, the application layer content format is predominantly HTML with Java/JavaScript.


Figure 3: The WAP protocol stack

Due to the reasons we explained earlier, WAP adopted a different protocol stack. On the top of the stack, the application layer consists of the Wireless Application Environment (WAE). This includes the Wireless Markup Language (WML), the JavaScript like WAP scripting language WMLScript and the Wireless Telephony Architecture (WTA) support. The session layer replaces HTTP with the Wireless Session Protocol (WSP) which uses binary headers and has enhanced capability negotiation mechanisms. The reliability provided by TCP in the Internet is now guaranteed through the Wireless Transaction Protocol (WTP) while the datagram support is provided by the Wireless Datagram Protocol (WDP). WDP provides a unified layer in the WAP stack for various physical layer bearer services such as GSM, CDMA and CDPD.

4. Wireless access to ANSWER

In order to support wireless access to the ANSWER system, we extended the ANSWER edge nodes with functions which enable a smooth and efficient WAP interface. These include: While the first function involves nothing more than checking the related HTTP headers about the WAP agents, the other functions are worth some extra explanations.

4.1 WAP gateway integration

Since the ANSWER edge nodes have a web interface, it is possible to use an arbitrary WAP gateway to access the ANSWER system. However, given the simple functions that wireless devices perform to interact with the ANSWER system, it is unnecessary to have a full featured WAP gateway. Further, directly integrating some of the WAP gateway functions into the ANSWER edge nodes makes the wireless accesses more efficient, as search requests and content deliveries do not have to go through some centralized gateways which could become system bottlenecks. As an example to these arguments, consider the WAP Push feature and its use in the ANSWER system which we will elaborate in a later section. It is the most important feature for our system since it serves as a means to deliver new content to interested users. However, if we rely on a Push gateway to notify users each time there is new result available at an edge node, the gateway will be flooded with PAP (Push Access Protocol) requests. If instead we build the Push gateway function in the edge nodes, not only can the bottleneck problem be alleviated, but the PAP protocol can be eliminated all together. This is because each edge node is the only source of Push requests for its gateway and thus there is no longer the need for external protocol interactions. For our purpose, we used the open source Kannel WAP gateway package as the reference. Since Kannel was implemented in C and did not support the Push function, our integration effort involved both re-implementing features in Java and building the gateway functions.

4.2 Search result conversion

As we mentioned earlier, the query results from the ANSWER system are coded in XML format for easy conversion into different display languages using XSL. For WAP devices, results are converted into WML cards where each result item corresponds naturally to a single card. Given the distributed nature of the ANSWER system, the results of a search are delivered to the user progressively as content summaries from different parts of the system become available. With the help of the edge nodes, the whole result sets can be displayed properly by the wireless devices. The edge node groups the results as they become available. Based on certain threshold(e.g. time passed or number of results available), it delivers the initial set of results as a deck of cards to the wireless device. The last card in the deck would ask the user whether he/she wants to see more results. More new decks from the edge node will then be fetched if the user decides to continue. Otherwise, the temporary storage of the result set is erased from the edge node.

4.3 New content delivery

One of the distinctive features of the ANSWER system is the symmetrical interaction model between content providers and consumers. That is, not only can query packets be routed to the proper content destinations, but content packets can be delivered to users who expressed their interests before. New content notification is thus an integral part of the wireless access. From WAP 1.2 and higher, a Push function is specified. It allows a user to send information asynchronously to a WAP enabled device. To do so, the user sends a request containing the id of the intended device to a Push gateway. The gateway then locate the device and deliver the message. With this push feature, we can very smoothly deliver new content notifications to WAP users. As a very important part of our WAP integration, we have implemented the Push gateway functions in the ANSWER edge nodes. When a WAP device submits an ANSWER query to an edge node, its device id together with the query id are stored at the node. When new results are available at a later stage(after certain time threshold), if the query has not been canceled by the user, the results are converted into a WML deck, a Push message containing a link to the deck is then sent to the device. Such a message will be either delivered as an alert or put in the user's mail box.

5. Examples

One of the applications we developed on the ANSWER framework is the conference announcement and search application. Conference organizers can announce the conferences using a special XML format. A user can search for specific conferences through a web browser or a WAP device based on different criteria. See Figure 4 for the WAP query interface. The corresponding WML file and WMLScript are downloaded from a web server, in our case Apache, through the kannel WAP gateway. The query data entered by the user is analyzed and reformatted by the WMLScript and sent back to a servlet. This servlet packs the data into an ANSWER query packet and injects it into the ANSWER network. It also returns a WML page containing a timer to the WAP device. The results returned from the ANSWER network are aggregated by the servlet into a deck of cards, with each card representing one conference. The WAP device, upon the expiration of the timer, retrieves the results currently available at the servlet and displays them as shown in Figure 5. Again this transaction goes through the WAP gateway.

Figure 4: Entering a queryFigure 5: Results obtained

Users may also be notified of relevant new announcements through alert messages on the WAP devices. The last card of the returned results from a query allows the user to subscribe to the announcement feature. Figure 6 shows the announcement subscription card. If the user subscribes to this service, a special flag will be set at the servlet for the user. Once the servlet receives additional replies to the original query, it will compile a Push Message and send it to the WAP device. The message contains a link to where the new result can be retrieved. It is compiled into byte code and sent directly to the WAP device through the Push gateway which is part of the servlet. Figure 7 shows the screen shot of a WAP phone when a new result becomes available and the user chooses to view the result. Since we are not aware of any Push capable WAP phones, the WAP phone in this example is a simulator in the Nokia WAP Toolkit.

Figure 6: Receive updates?Figure 7: New results arrived

6. Status and future work

We have finished integrating the basic WAP gateway functions into the ANSWER system. A prototype system which uses the ANSWER framework has been tested with both WAP phones and WAP simulation softwares. We are investigating various aspects of mobility management for wireless access in the ANSWER system. In particular, we plan to integrate support in the ANSWER system so that 1) mobile devices can locate the ``nearest'' edge nodes, and 2) user sessions can remain uninterrupted, e.g. search results can still be properly delivered even when the user moves or temporarily disconnects from the ANSWER system.

7. REFERENCES

  1. WAP Forum. Wireless Application Protocol Architecture Specification. http://www1.wapforum.org/tech/terms.asp?doc=WAP-100-WAPArch-19980430-a.pdf.
  2. J. Zhang and M. Ott. ANSWER: Information Routing Based on Active Networks. The 5th Asia Pacific Conference on Communications. Beijing, China. October 1999.
  3. W3C. Extensible Markup Language(XML) 1.0. http://www.w3.org/TR/1998/REC-xml-19980210.html.
  4. WAP Forum. Push Architectural Overview. http://www1.wapforum.org/tech/terms.asp?doc=WAP-165-PushArchOverview-19991108-a.pdf.
  5. W3C. Extensible Stylesheet Language(XSL) 1.0. http://www.w3.org/TR/xsl/.
  6. T.R. Gruber. Toward principles for the design of ontologies used for knowledge sharing. Padova workshop on Formal Ontology, March 1993.