Flower – Framework for Local Wireless Services

by Tero Hakkarainen, Ali Lattunen and Vespe Savikko

Local wireless services enable the distribution of location-dependent information using wireless short-range communication methods. At VTT Information Technology, a novel framework solution for local wireless services has been developed.

Local wireless services provide content that is accessible only at the immediate vicinity of the service access point. Local services are accessed normally either with mobile phone or palmtop computer equipped with appropriate content, eg, WAP (Wireless Application Protocol), browser and suitable short-range communication method like Bluetooth or WLAN (Wireless Local Area Network). The limited service area distinguishes local services from cellular network, eg, GSM, based services that are accessible in fairly broad geographical area. Proximity of the user enables local services to provide content that is both location-dependent and meaningful for the user only at that precise location. This fact and charge-free local communication bearer services make local service concept ideal for providing services like local information kiosks, guidance, m-payment and ticketing services, games, entertainment, advertising and remote control solutions, as illustrated in Figure 1. Effort to build local wireless services is substantially decreased by the novel framework called Flower (Framework for Local Wireless Services) which provides an easy-to-use programming interface for the developers of local service applications.

Framework Architecture
The Flower framework hosts local wireless service applications capable of responding to requests and events in the service environment. As depicted in Figure 2, the content generated by an application is conveyed through a local area network to the access point that hosts the terminal that requested the service. Access points transfer content to terminals’ browsers using short-range wireless communication methods.

The Flower server executes the local applications and offers them a view to the physical service environment. Applications generate content typically in either HTML (HyperText Markup Language) or WML (Wireless Markup Language) format. HTTP (Hypertext Transfer Protocol) protocol is used for transferring content data, eg, HTML, from Apache Tomcat Web Server to HTTP enabled terminals. For WAP terminals, WAP protocol must be used instead. The essential part of the latter communication route is the WAP Gateway, which transforms content data, eg, WML, to WAP protocol messages.

The Flower system may contain an arbitrary number of independent access points. Access points may autonomously choose the wireless short-range communication method they use. It would therefore be fully possible to have eg, Bluetooth and WLAN access points simultaneously in a Flower system. The primary function of access points is to relay protocol data in either WAP or HTTP format to the terminals. Each terminal belongs to only one access point at a time. Additionally, access points monitor the terminals in their service area. A new or a lost terminal is signaled to a special server in the framework, the Manager, which is a database containing the current state of the whole system. A change detected by some access point causes an event that can be caught and handled by the local applications.

Figure 1: Local wireless services in urban environment.

Figure 2: Flower framework architecture.

Creating local Wireless Services
The use of the WAP Gateway makes it possible to use established web technologies in local wireless service development. Flower development framework is implemented with Java servlets. This solution offers the following benefits:

• servlet developers can easily migrate to local wireless applications domain
• availability of free servlet engines (eg, Tomcat)
• Java Native Interface (JNI) is used to map the Flower API (Application Programming Interface) to C++.

The Flower API is actually a layer encapsulating the Servlet API, providing Flower specific alternatives to HTTP specific classes (eg, Request ‘HttpRequest, Session’ HttpSession) and hiding those parts of the Servlet API that do not have a Flower counterpart (eg, cookies). As the Flower API reflects the concepts of the Servlet API it feels familiar to servlet developers, thus making them productive after short orientation. Additional, Flower specific, features are seamlessly integrated into the Flower API, encouraging a developer to create genuine local wireless applications with them:

• Interface to the Manager provides the current state of the system (access points and terminals connected to them).
• Due to the dynamic nature of the system, where a terminal can leave the service area of its access point at any time, a simple acknowledgement mechanism is devised. Access point signals through the Manager to the originating Flower application whether the message could be sent to the target terminal.
• WAP push support enables a Flower application to approach terminals instead of passively waiting for requests. The actual push mechanism (Push Access Protocol) is implemented by the WAP Gateway.

Conclusions
The Flower framework supports currently WAP services over Bluetooth communication. Since actual WAP-over-Bluetooth terminals are not yet available, laptops with Bluetooth adapters have been used as substitutes for smart phones. In the future, the system development will be targeted to completing the HTTP protocol support and adding support for new types of terminals and protocols. With the experience and knowledge gained from the pilot applications already running over Flower it is likely that the forthcoming technical improvements will make the framework even more attractive for research purposes as well as for real-life applications.

Please contact:
Tero Hakkarainen, VTT
Tel: +358 3 316 3355
E-mail: Tero.J.Hakkarainen@vtt.fi