Overview
Loclib is a connector between applications and sensor hardware. Its task is to collect
data from the sensor hardware and pre-process it for further usage. On the application
side it offers two types of front-ends: The well-known Location API to
access position estimates, and so-called handlers that provide access to sensor-specific
data (e.g., signal strength values of neighboring access points). On the sensor hardware
side, it communicates directly with hardware drivers to access sensor information that
would otherwise be hidden. Loclib focuses not only on 802.11, it also contains a GPS part
that is able to talk to NMEA-0183-enabled GPS devices as well as a digital
compass for obtaining direction and inclination information.
Architecture
As already mentioned in the previous section, Loclib interconnects sensor hardware and
applications by gathering sensor-specific data and converting it into location information
if required. Loclib is organized in three layers:
- Sensor-specific data collection layer
- Data conversion layer
- Location application programming interface layer
The sensor-specific data collection layer gathers data from different sensor hardware. At the moment, Loclib
is able to retrieve data from 802.11 wireless LAN network cards, NMEA-enabled GPS receivers, and digital
compasses. To collect data, drivers can be accessed, or if it is feasible Loclib communicates directly with
the sensor in question. For instance, digital compasses are directly queried, as well as NMEA-0183 devices.
In case of 802.11 network cards, the signal strength of access points in communication range is retrieved
from the driver. The data collected from the sensor-specific data collection layer is usually forwarded
to the data conversion layer for further processing. However, the data can also be directly accessed by
using so-called handlers. Handlers are pre-defined interfaces to allow applications such as Loctrace to
access sensor-specific data.
The following figure shows the software architecture of Loclib and the aforementioned layers:
The data conversion layer is responsible for converting data provided by the sensor-specific data collection
layer into a position estimate that can be utilized by the Location API. To accomplish this, so far, GPS or
802.11-based positioning algorithms can be used. The data conversion layer is able to switch between 802.11-based
positioning and GPS-based positioning if one of the sources fades out and the other is still operational. If both
positioning services are available, GPS is preferred. Should both sources of position information be unable to
deliver the required data an error code is returned instead of a valid position. The location application program
interface layer implements the well-known and widely used Location API to deliver location estimates to applications.
This is a standardized way to hand over location information. Especially on mobile devices, this is a wide-spread
approach to support location-based services.
Documentation & Tests
For software documentation purposes we mostly rely on Javadoc.
Additionally, we use JUnit tests and UML diagrams during our development process as
documentation tools.
The documentation and the test suite is available through the Downloads website.
Location API
We have implemented the Location API as defined in JSR-179 to
provide application developers a unified interface to
location information. So far, our implementation is not
completely compliant with the standard because we focused on
the features we need. In the future, we will add missing parts.
NMEA-0183
A library compliant to the NMEA-0183 (Version 2.2) standard is
part of Loclib. The NMEA library is specifically optimized for
GPS receivers based on the SiRF II chipset. However, the library may
work with other NMEA-0183 compliant devices as well.
Usage
Invoke Loclib with the following command to
display the information provided by the GPS receiver:
Wireless LAN
Our Wireless LAN implementation supports Active and Passive
Scanning as well as Monitor-Sniffing. Monitor-Sniffing has been
proposed by us and is discussed in the research paper
"Wiretapping the Wireless Interface for 802.11-based Positioning
Systems". To get Monitor-Sniffing to work, a Wireless LAN network
card is required that supports monitor mode.
Usage
You can start a test program that actively scans for neighboring
access points by invoking the following command:
Please adjust the java.library.path accordingly.
The test
program works only under Linux or *BSD operation systems. It
actively scans for access points using interface eth0 and
prints detail information about the presence and signal strength
quality of access points in communication range.
Bluetooth
A so-called proximity-based Bluetooth location system is part of
Loclib. This kind of location systems have been proposed by many
researchers and they work as follows: the position of a mobile
device is derived from the access points in communication range by
averaging their positions.
Our implementation requires the BlueZ Bluetooth stack and a Linux or *BSD
operating system.
Usage
Replace the MAC addresses and coordinates stored in the
bluetoothlocationdata.txt file with the values of the Bluetooth
access points in your vicinity. Modify the loclib.properties, so
that "provider=Bluetooth" is set. After that, invoke Loclib with
the following command:
Digital Compass
We have implemented the communication protocol for the
F350-Compass-RD digital compass manufactured by Silicon
Laboratories. The compass provides information about azimuth, current temperature and inclination of the compass on X- and Y-axis.
Usage
The declination angle must be set correctly.
You can start a test program by invoking the following command:
The test program continously requests and receives data from
the compass and prints it to the screen.
As the compass package is not covered by the Location API, we
encourage you to use the InputOutputHandler class as a
front-ending if you want to use the compass package along with
your own source code. The class that uses the
InputOutputHandler is then supposed to implement the
CompassListener interface in order to handle incoming
messages. A detailed description is also available that
discusses how to use the classes and interfaces.
Application: FDDD
Usage
To invoke FDDD execute the following command:
The words in upper case are placeholders:
- PATH_LOCLIB_JNI defines the path to the Loclib jni directory
- PATH_FDDD defines the path where the FDDD code is stored
Application: SPBM
SPBM
(Scalable Position-Based Multicast) is a multicast routing protocol
for mobile ad-hoc networks. It uses the positions of the nodes in
the network to forward data packets. Loclib can be used to provide
the SPBM kernel module with coordinates derived from the current GPS
position.
Usage
loclib-spbm requires four command line arguments:
- Latitude of the origin of the SPBM coordinate system (in degrees)
- Longitude of the origin of the SPBM coordinate system (in degrees)
- Step width along the x axis of the SPBM coordinate system (in degrees)
- Step width along the y axis of the SPBM coordinate system (in degrees)
For example, if you want to use SPBM in the city of Mannheim (Germany),
you have to run loclib-spbm as follows: