Herecast:An Open Infrastructure for Location- Based Services Using ...

12 downloads 6714 Views 301KB Size Report
click, access web sites relevant to their location, publish presence information to .... for software that asks for a subscription to a service. In testing this work, we ...
>Herecast
Herecast
Herecast < Maintaining Access Point Information Component. This component maintains information about the access points retrieved. Information about each access point found is stored in an AccessPoint object. Information stored includes the average RSSI. A list of AccessPoint objects is stored in AccessPointList. A method of this component includes finding the access point with highest RSSI. This can be used to determine which service information to retrieve. Communication with the Server. Transfer of information between a client device and the server is through a standard HTTP connection. To download information from the database, the client issues a GET request to http://db.herecast.com/text/?action=location.downloadText&bbsid=00123456789a where “00123456789a” is the BSSID (MAC address) of the access point that the client needs location information for. If there is no information associated with the access point it returns a message indicating this. If there is information, then the retrieved information is stored in the data cache. When the client wants to upload information, the HTTP POST request to http://db.herecast.com/text?action=location.uploadText is used. An example of an application using this command is the application that displays the data entry forms in Figure 2. Data Cache Component. Upon receiving a request for location information for an access point, the server returns the information as well as information for other access points in the building. These access points are the ones found in AccessPointList. This component provides a cache to store location and service information retrieved. The implementation uses simple text files to keep the storage format compact, making it suitable for a mobile device with limited memory. The cache is first examined before requesting information from the server. C. Possible Types of Services The initial screen includes a today item. When the user clicks on this button, the list of services available to the user at the user’s current location is retrieved as shown in Figure 3. It is possible to have a location-aware service that can receive as input the user’s location. For example, the “area map” service (described in section IV.a) was created to show a map of the University of Western Ontario campus. It is available to anyone in the UWO area. However, this service is also able to receive the user’s location as input, and is thus able to determine the building in which the user is located. The location is sent as parameters in the URL query string e.g., the url: http://herecast.com/service.php?building={building}. When the user requests the service, {building} is replaced by the actual building name. The following URL parameters are supported: {country}, {province}, {city}, {streetaddr}, {building}, {buildingid}, {area}, {location}, and {bssid}.

3

Figure 3 The most advanced type of location-aware service is one that continually receives updates as the user moves around. The URL itself uses the same parameters as described above. When a user subscribes to the service, the client will automatically access the URL specified every time the user enters a new location. To allow a user to subscribe to a service, a web site provides a web link of the form: herecast://url. For example, herecast://example.com/svc?building={building}. When the user clicks on this URL from the device, the Herecast software is activated, and the user is prompted to confirm their intention to subscribe to the service. The user can also specify further privacy settings at that time. Services can pop up alerts to the user. III. IMPLEMENTATION The client software is written in C++. The Pocket PC version uses embedded Visual C++, which is available as a free download from Microsoft. The WiFi Scanner open source software is used to interface to the network card to discover access points. It is possible to show all access points that are detected from the spot that the user is at (as seen in Figure 4). Services can register with the server using the HTTP POST request message as described in section II.B. To facilitate the development of locationaware services a library is provided.

Figure 4

>Herecast
Herecast
Herecast
Herecast < Ease of Development of Location-Aware Applications. One of the major design goals of Herecast is to facilitate the development of location-aware applications and location-based services. The reason for this goal is that we believe that a reason for the lack of location-aware applications and location-based services is that the infrastructure is sometimes complicated and the amount of time needed to understand the infrastructure to develop applications and services. Hence, an open-source library for the client software is available. So far, this has been found to be quite useful and does facilitate the development of applications. The Area Map service described in section V was developed in an hour. More application development is needed to best determine the features that should be included in the client software library. In addition, a library should be developed for location-based service providers to facilitate their development. Data Management Issues. Currently Herecast has a single database. Eventually multiple servers are needed. One possible approach is to use a proxy service that returns the IP address of a server in the user’s region. There can be multiple proxy servers. DNS is used to balance the load among the proxy servers. This will be explored in more detail. Access points, especially those owned by private individuals, might move. Currently, the only way to resolve this is to manually delete the access point from the database and re-create it somewhere else. In the meantime, it may cause the client to mistakenly download information for other cities. This issue has not been fully dealt with and is a topic of future work. There are some other database management features that need to be more fully implemented. For example, when a database is being created by large number of different users, it is inevitable that some people will spell the names of places differently from other people. There needs to be a facility to merge different spellings of the same item into a single object. The lifetime of the data cache should also be addressed. Currently, downloaded data is cached indefinitely, and can only be cleared manually. This means that if new services are added via the web site, they will not appear clients until the client next has to download information. VII. CONCLUSIONS AND FUTURE WORK This paper described a location positioning system called Herecast that makes use of WiFi networks for location positioning. Our experience with Herecast suggests that this is a promising approach. This section describes some of the future development that we would like to see occur with the Herecast system.

7 A. Future Applications Community-building applications would benefit from location-awareness. This would be a logical extension of the Heresay service discussed earlier. For example, imagine an instant messaging application that allow users to broadcast messages to other people in the geographic area. This not only could be used to discover people not previously known to be nearby (“does anyone want to go for lunch?”, “is anyone out there studying for the computer science exam?”), but also for facilitating communication between people who are already meeting (sending documents, sending questions to the professor in the middle of a large lecture.) The ActiveCampus project at the University of California San Diego is an example of a location-aware application that is designed to foster campus communities and encourage participation in large classes [3]. Another application area of interest is games. A course in video development might be able to look into developing games in which players run around campus picking up objects, leaving things for other players, and so on. In Tokyo, one such “massively multiplayer role-playing game” exists today [4]. Hong Kong is host to another location-based game, this one involving the search for terrorists [6]. B. GPS Integration Although not a core requirement of the system, it would be possible to add GPS information (latitude and longitude) to complement the existing symbolic representation. This would make it possible to gather a large amount of information quickly, using the “war-driving” method— driving around a city, letting the device automatically gather and record the coordinates of many access points. This would open up additional possibilities for services, as coordinates are well suited for generating maps and calculating the relative distance between two points. Gathering this information raises its own issues in topics such as how to average location information from multiple sightings, how to determine when an access point has moved, and so on. C. Finding Access Points WiFi signals can travel a long distance. We found that it is often the case that a signal can travel from one building to another building. It would be feasible to avoid situations where the user enters incorrect information as the result of not knowing they were sending a signal from a great distance. One approach is to add a warning message when the user attempts to enter information for an access point that the device is receiving a weak signal. Another

>Herecast

Suggest Documents