Our design is implemented by four pieces of software that work together to fulfill the project objectives. These components are:
Table 4: Software Components and their Roles
Component Purpose
Transmitter Simulate unauthorized users; provide MAC address and transmit time Sensor (3 needed) Receive transmissions; capture data for storage and network transmission RTLS Real-time data processing; display unauthorized user‘s location
PPLD Data quality analysis; enable user-friendly transmitter and sensor configuration
The localization techniques we selected govern the configuration of our transmitter and sensors. First, a distance measurement from each sensor to the transmitter is calculated using TDoA and log-linear path loss. Then, a geometric position calculation uses the distance measurements to find the transmitter‘s location. This process is discussed in greater detail in Section 3.8. Since three or more sensors are required to perform two-dimensional localization, three or more sensors must be placed at known locations. One additional sensor is used as a mobile transmitter and positioned in several different test locations. Once set up, the transmitter broadcasts packets into the wireless channel at a known frequency. These packets are compliant with the message exchange protocol detailed in Section 3.6.2. Each sensor then receives a copy of this packet and measures its time of arrival and received signal strength indication. Upon collecting this data, each sensor then simultaneously writes a copy of the information to disk and delivers it to the RTLS over a network connection as described in Section 3.7. The configuration of the transmitter is controlled by data files produced by the PPLD. This approach allows for environment-specific settings to be loaded in a user-friendly manner, and is described in greater
44 detail in Section 3.10. Figure 7 shows this system in a flow graph format, demonstrating how data moves between each node and software package.
Figure 7: Full system architectural flow graph Transmitter
Sensor Sensor Sensor
Stored Data RTLS PPLD Error Graphs Calibration Settings Real-Time Map Wireless Channel
45 The configuration of our data processing and visualization software was governed by the needs of end users at the NRL. Three approaches to presenting localization and data quality information became apparent: post-processing in a data analysis program such as Microsoft Excel or Matlab, real-time output from a custom-implemented program to a text-only terminal, and real-time visualization through a custom-designed program with a graphical user interface. A comparison of each of these approaches is shown in Figure 8.
Figure 8: Comparison of localization software realizations
Our final system utilizes all three of these approaches, each for different purposes. Post processing is utilized for our data quality analysis so that system developers can quickly and easily visualize sources of error. This approach manifests itself in the PPLD and is well suited to the needs of system development. System development requires rapid, straightforward
implementation of new error correction and visualization tools that present considerable
46 system developers can afford to stop the localization infrastructure and gather stored data files. In contrast, end users view any interruption in system availability as a window of opportunity for security threats to go undetected. For this reason it became clear that end users need a real-time system. We chose to use a GUI as it is a very visual format, allowing security personnel to know where unauthorized users are intuitively, without having to translate numbers into positions within a building. However, a real-time terminal output is provided for debugging the RTLS. This approach is used because text is more conducive to system error logging and a terminal output is immune to problems with the GUI display.
We have developed a higher level system design, made up of five components and several requirements. First we developed the data component which is responsible for storing information via multiple CSV files. Information collected includes raw project data, localization test results, sensor locations, frequency offsets, and calibration data. The remaining four
components interact with each other in order to provide the data component with information. Second we developed our data gathering component. This component consists of the actual communication via the 802.11BBN code, and an error correcting module. Calibration data and frequency offset CSV‘s provide our modified 802.11BBN code with enhancements to provide initial average error correction to our system. The error correction module uses
theoretical lookups and range based analysis of incoming data to categorize the inputs and then add the most likely error to the data.
Third is the localization component that contains a variety of modules. Received in real- time is the project data with a mode identifier, which decides between using RSSI or ToA based distance calculations. After the distance is calculated, we use an aggregator that groups the distances by incoming MAC address. Each MAC address uses the sensor location CSV to reveal
47 its actual XY coordinates. Another mode is then triggered that distinguishes between using our Python localization or our C localization. The final results are logged and sent to our GUI.
The GUI component is rather small, however helps tremendously. This component contains the actual real time localization mapping and tracking. It also contains a test bench that can manipulate the data within the PPLD to test the effect of different variable parameters such as time difference, or the path loss gradient.
The final component consists of our processing and reporting which contain the PPLD as well as the Excel Localization Test Bench (ELTB). These are quality analysis tools that use our raw project data to ultimately determine the best calibration parameters for our system. In addition, both tools provide detail analysis of the environment in well-organized test
environment reports. In the following sections, we go into the procedural details of our system. Figure 9 shows our design components and the relationships between them.
48 Figure 9: System functionality diagram