Chapter 4 Measurement Methodology 13
4.4 Beacon Message Synchronization
The beacon sequence number in the beacon messages was used to synchronize the beacon traces. Upon receiving the beacon messages, the other beacon nodes and the receiving tag time stamped the messages using their local clocks. Assuming that the time required for the beacon messages to travel one hop to the receiving tag was the same as that required to travel to the neighboring beacon, the traces were synchronized by simplified Jigsaw approach [7].
More specifically, the local clock of the receiving tag was used as the global clock.
Let tm represent the timestamp of the reference packet received at the mobile tag and let tk denote the timestamp of the reference packet received at the kth beacon nodes.
The local clock of the kth beacon node would then adjusted by adding the time offset tm− tk. Since the testbed was a multi-hop network, no reference packet could be re-ceived by any beacons in the network. A queue of reference packets was implemented
CHAPTER 4. MEASUREMENT METHODOLOGY 18
to transitively synchronize other beacon nodes not receiving the previous reference packets. The first packet received by the mobile tag was chosen as the first reference packet. Once a beacon was synchronized, the next packet it received/sent was added to the queue. Elements in the queue were popped out sequentially until all beacons were synchronized.
Chapter 5
Trace Analysis
We analyze the five sets of traces collected from the localization testbed with different levels of WiFi traffic in the background.
5.1 Localization Errors
Figure 5.1 depicts the cumulative distribution function (CDF) of the localization errors.
The localization accuracy was pretty good with 50th percentile error 53cm. We believe such good accuracy comes from the following reasons. First, DESYNC was applied on beacons. Collisions were thus reduced, and the receiving tag could receive sufficient RSSI readings to give accurate location estimation. Second, the survey and the test conditions, e.g. antenna orientation and the way the receiving tag was wore, were held the same throughout the experiments. The beacon density of the system was also high, with a beacon placed every five meters.
19
CHAPTER 5. TRACE ANALYSIS 20
Figure 5.1: Distribution of Localization Errors
The test results showed that the localization errors were influenced by the back-ground WiFi traffic. In the 50th percentile, the errors increased from 53cm to 81cm (53% increase) as the background WiFi traffic increased. The increase in the 80th percentile error from 160cm to 385cm (141% increase) was particularly large. This indicated that, as background traffic increases, the localization error and variance also increase. In cases of heavy background traffic, all beacon messages may be corrupted in some cycles. The localization error was set to a pre-defined maximum for analysis of these cases. In practice, the system can predict or simply report the location obtained in the previous cycle.
CHAPTER 5. TRACE ANALYSIS 21
0 500 1000 1500 2000 2500 3000 5
7 9
Average Number of Recv Beacon Pkts 0 500 1000 1500 2000 2500 30000
2 4
Background Data Rate (kbits)
80−percentile Localization Error (m)
(a) Correlation of Background Traffic Rates and Localization Errors
(b) Effect of Beacon Message Loss
0 5 10 15
(c) Distribution of the Number of Beacon Messages
Figure 5.2: Impact of Beacon Packet Loss
CHAPTER 5. TRACE ANALYSIS 22
5.2 Beacon Message Losses
To understand how the background traffic impacts localization accuracy, we first look into the loss of beacon messages. In Figure 5.2(a), the left x-axis shows the average number of beacon message received during each 220-ms interval, and the right x-axis plots the 80-percentile localization error. It can be seen that the average number of beacon message received goes down in high background traffic rate and shows a strong correlation with the increasing localization error.
To further clarify the impact of beacon message loss, receiving cycles were clas-sified by the number of beacon messages received for each trace in Fig. 5.2(b). The corresponding average localization error and the variance shown in the figure indi-cate that fewer received beacon messages increase localization error and variation. A location estimation based on only one or two beacon RSSI readings would be very im-precise. Average errors would be as high as 9 meters since several sample signatures share similar RSSI readings for a single beacon. The insufficient information received due to the fewer beacon messages would cause larger localization errors.
Figure 5.2(c) shows the probability of the tag receiving a specific number of beacon messages for different background traffic rates. The distribution of the number of received beacon messages indicates that high background traffic increase the number of cycles in which the receiving tag observes only a small number of beacon messages.
In fact, the background traffic interferes with the delivery of beacon messages and corrupts them. Thus, the overall number as well as variance in localization errors worsens when background traffic is high.
CHAPTER 5. TRACE ANALYSIS 23
68 264 1308 1705 2835
−90
−80
−70
−60
−50
Background Traffic Rate (kbps)
RSSI (dBm)
Figure 5.3: Effect of Background Traffic to RSSI Readings
5.3 RSSI Values
Note that in Fig. 5.2(b), if the receiving tag manages to receive sufficient beacon mes-sages, the localization errors are all similar for different background traffic rates. This suggests that produces less distortion of RSSI readings. Figure 5.3 shows the average RSSI readings and the standard deviation for each trace. The RSSI values from dif-ferent beacons are slid slightly for clarity and ease of comparison. The deviation of RSSI readings again reveals no a clear trend as background traffic increases. Gener-ally, RSSI variance causes some localization error. However, background WiFi traffic apparently has no significant effect on RSSI variation.As Fig. 5.1 shows, the overall increase in the magnitude of errors is mainly due to the beacon message losses caused by background traffic.
CHAPTER 5. TRACE ANALYSIS 24
0 600 1200 1800 2400 3000
0
0 600 1200 1800 2400 3000
0
Figure 5.4: PRR vs Localization Errors
5.4 Packet Reception Rate
Figure 5.4 shows the beacon packet reception rate of a specific link located near the source AP and the corresponding localization errors. The figure is plotted by concate-nating the five 10-minute traces at different background traffic rates. When the level of background traffic increases, the localization error increases and the packet reception rate decreases. The effect of beacon message loss at the receiving tag is apparently observable from the neighboring beacons. The implication is that each beacon node may track the packet reception rates from neighboring beacons. The packet reception rate is likely high when the channel is quiet. The packet reception rate is likely low when there is background noise.
CHAPTER 5. TRACE ANALYSIS 25
Figure 5.5 shows WiFi data rate during a busy working hour at this department build-ing. The data rate exceeds 1 Mbps for substantial time periods. Such bursty traffic has also been reported in similar works elsewhere [29] [15]. The 80th-percentile error during these periods may be as high as 2 or even 4 meters. The localization system may temporarily blackout when WiFi traffic is high. For a stable RSSI-based localiza-tion system in an everyday working environment, a frequency hopping mechanism is proposed and will be detailed in the next section.
Chapter 6
Frequency Hopping Mechanism
For a RSSI-based localization system robust to background noise, this study proposes a frequency hopping mechanism consisting of (1) a diagnostic test to detect whether the sensor network is substantially influenced by background noise and (2) a protocol for signaling all nodes semi-synchronously hop to the next channel. The following subsections describe in detail the rationale for running the diagnostic test at the beacon nodes rather than at the receiving tag. The use of hidden Markov model for diagnostic testing, and the simple signaling protocol are also described.
6.1 Beacon Node
As observed in Section 5, the accuracy of an RSSI-based localization system is sen-sitive to wireless signals traveling on the same frequency band. The resulting beacon message losses cause localization errors. To hop away from busy channels, the system
26
CHAPTER 6. FREQUENCY HOPPING MECHANISM 27
must be able to accurately detect such channels.
One obvious solution is to track the reception rate of the beacon messages at the receiving tag. However, the receiving tag may appear anywhere in the surveyed re-gion. Regardless of the beacon network density, some regions, particularly those at the corners, should receive a small number of beacon messages even when the channel is quiet. A diagnostic test based on the number of beacon messages received at the receiving tag would not be robust. On the other hand, the effect of beacon message loss at the receiving tag is observable from the neighboring beacons (see section 5.4).
The diagnostic test can thus be performed on individual beacon nodes by monitoring reception of the beacon packets from well-connected neighboring beacons.
At the beacon network setup phase, the beacon nodes send messages to each other, possibly during non-working hours for example, to determine the list of well-connected neighboring beacons [38] [40]. Based on the beacon packet reception rate from these well-connected neighbors, a beacon can measure the influence of heavy background traffic.
6.2 Diagnostic Test
The accuracy of the diagnostic test to determine whether or not the beacon network should hop is critical to a noise-resilient RSSI-based localization system. Given the trend that packet reception rate decreases as the amount of background traffic increases, observed in Figure 5.4. A naive solution is to set a threshold on the smoothed packet reception rate. However, if the hopping threshold is set high, the diagnostic test may
CHAPTER 6. FREQUENCY HOPPING MECHANISM 28
suffer from occasional beacon message loss due to instantaneous noise, as opposed to sustained background WiFi traffic. The beacon network might therefore hop unneces-sarily. In this case, beacon nodes as well as the receiving tag in the network require time to switch to the new frequency channel. During the transition, the receiving tag may be unable to receive beacon messages effectively and thus produce increased lo-calization error. Conversely, if the threshold is set too low, the beacon may not be sufficiently sensitive to detect the presence of background traffic. Furthermore, the best threshold might differ between different pairs of well-connected beacon nodes.
Manually tracking the best threshold for each good link would also be tedious, i.e., not scalable.
Instead of trying to find a hard threshold, this study proposed a learning approach to solve the above dilemma by using hidden Markov model (HMM) [28]. Hidden Markov model is well-known for recognizing temporal patterns, which is also seen in daily WiFi traffic (see Figure 5.5). That is, if the data rate of the background WiFi traffic is currently high, it is likely to remain high; if the data rate is currently low, it is likely to remain low. The revealed time dependency in WiFi background traffic also suggests temporal patterns in packet reception rate, knowing the correlation between the WiFi traffic rate and the packet reception rate. This relationship enables application of HMM to the beacon observed packet reception rate.
Hidden Markov model extends the concept of Markov models to include the case where the observation is a probabilistic function of the state. Thus, hidden Markov model is a doubly embedded stochastic process with a hidden underlying stochastic process which can only be observed through another set of stochastic processes
produc-CHAPTER 6. FREQUENCY HOPPING MECHANISM 29
ing the sequence of observations [28]. Using HMM enables modeling of the hopping decision, the underlying stochastic process, according to the sequence of measured packet reception rate, the observable stochastic process.
To obtain a model, we feed packet reception rate as the observation sequence into the trainer. The HMM consists of several hidden states and their corresponding Gaus-sian distributions which characterize the observation of each hidden state. Applying the Expectation-Maximization (EM) algorithm enables adjustment of model param-eters to maximize the probability of the training observation sequences. The hidden states can be defined as ‘Hop’ or ‘No-Hop’ based on environments and strategies. With the model, a diagnostic test can be performed on beacons by calculating the state prob-ability of each observed PRR. Forward algorithm [6] is chosen for the state estimation computation because of its simplicity, more suitable for resource constrained sensor nodes.
6.2.1 State Modeling
Given the packet reception rate of a link near the wireless AP as the observation val-ues, the following parameters are estimated by the Expectation-Maximization (EM) algorithm. A general HMM represents by N states, denoted as S1, . . . , Si, . . . , SN. Assuming the observation Ot can be characterized by a Gaussian distribution Ot ∈ {N(µi, σ2i)} with mean µi and variance σi2, the state modeling problem can be formu-lated as, given observation sequence O = O1, O2, . . . , OT, find a model λ = (N, A, B, π ) that maximizes P (O|λ). The notation is as follows:
CHAPTER 6. FREQUENCY HOPPING MECHANISM 30
• π : Initial state distribution
πi = P (q1 = Si), q1 ∈ {S1, S2, . . . , SN}, qt represents the estimated state at time t.
• A = {aij} : state transition probability distribution given the previous state i;
probability of the next state j.
aij = P (qt= Sj|qt−1= Si)
• B = {bi(Ot)} : observation probability distribution, given the state i at time t;
the probability that an observation Otis observed at state i bi(Ot) = P (Ot∈ {N(µi, σi2)}|qt= Si)
After training, certain hidden states can be designated as ‘Hop’, while others are
‘No-Hop’. For example, in the most conservative way, the state with the lowest obser-vation mean is considered as ‘Hop’ and the others as ‘No-Hop’. Hopping would then only occur when PRR is low enough. In this study, two-state and three-state HMM are both used and only the state with the lowest observation mean is denoted as ‘Hop’.
Figure 6.1 gives an illustration of a two-state HMM with continuous observation.
Note that the observation, PRR, is calculated over a window of fifty. Thus, only fifty-one PRR observations, i.e., 0, 1, . . . , 50, are possible; the state machine can there-fore be modeled by discrete observations. However, the window size is in fact an adjustable parameter, and may affect the accuracy of the diagnostic tests. Because the optimal window size for individual environment is unknown, characterizing the PRR observations as a continuous Gaussian distribution is more appropriate.
CHAPTER 6. FREQUENCY HOPPING MECHANISM 31
6.2.2 State Estimation
With the derived HMM model λ and the observation sequence O = O1, O2, . . . , Ot, the probability P (qt = Si, O = O1, O2, . . . , Ot|λ) can be found with the Forward al-gorithm. The detailed derivation of the Forward algorithm can be found in [28]. The estimated state at time t would be the state with the highest probability. Here, the observation sequence can be the instantaneous PRR of a good link or a look-ahead window of size Ts that records the past Ts PRR. Since the PRR observation is char-acterized by Gaussian distributions, in Forward algorithm, exponential computation will be needed to compute bi(Ot) = √2πσ1
ie−(Ot−µi)/(2σ2i), where Ot are the values of PRR observation and µi, σi are the parameters of the Gaussian distribution in state i.
Computing the exponential function on the sensor nodes would not be feasible. How-ever, such function can be approximated by a look-up table, where there is a limited number of PRR values. The look-up table can be computed in advance to capture the above bi(Ot) function. Given the state machine and an implementation of the Forward algorithm, the beacon node can perform the hopping decision inference on board. The Forward algorithm, whose pseudo code is shown in Algorithm 1, is compact and rea-sonably tractable on Telos-like sensor node platforms. More precisely, for a HMM with N states, only N(N+1) multiplications and N(N-1) additions are needed for each observation. There will be 6 multiplications and 2 additions for the two-state HMM case; and 12 multiplications and 6 additions for the three-state HMM case.
CHAPTER 6. FREQUENCY HOPPING MECHANISM 32
Algorithm 1: Forward Algorithm N: the number of states in the HMM
π : the set of prior prob. {πi}, i ∈ {1, . . ., N}
A: the set of transition prob. {aij}, i, j ∈ {1, . . ., N}
B: the set of observation prob. function {bi}, i ∈ {1, . . ., N}
CHAPTER 6. FREQUENCY HOPPING MECHANISM 33
Figure 6.1: Illustration of Two-State HMM
6.3 Signaling Protocol
The beacon nodes as well as the receiving tag should hop to the next channel when the hopping signal is detected. If all nodes hop synchronously, the receiving tag can contin-uously receive beacon packets with minimum interruption. In other words, the shorter the transition time, the better the system stability. However, coordinating all nodes to hop in perfect synchronization is difficult. Instead, a mechanism, originally designed to avoid self-interference in a dense wireless ad hoc network [39], was adopted. This mechanism allows semi-synchronous hopping in beacon networks.
The signaling protocol functions as follows. Each beacon node independently runs the diagnostic test on packet reception rate. Any beacon link making a decision to hop takes the lead and generates a hopping message to its neighbors. Shortly after the message is sent, the beacon node hops to the next channel and waits for other nodes to join. Other nodes(beacon nodes and mobile nodes), upon receiving the hopping
CHAPTER 6. FREQUENCY HOPPING MECHANISM 34
message, propagate the message further before hopping to the next channel themselves.
The process continues until there are no further hopping messages in the network. For the best case that the hopping message can reach all the nodes in the network hop by hop, the transition time T will be
T = network hop counts ×
(transmission + processing) delay of the hopping message per hop
The worst case is that the hopping message cannot reach any nodes in the network.
When the first beacon node hops to a new channel, the packet reception rate(PRR) of its neighboring nodes will eventually drop to zero after a period of time. In this case, those neighboring nodes will hop due to the diagnostic test on the zero PRR. The maximum transition time Tmaxwill be
Tmax = network hop counts × window size of P RR
For the mobile nodes, if they can receive the hopping message, they will hop very fast. Otherwise, since no diagnostic test is run on the mobile nodes, we let them hop if they cannot receive any beacon messages for a period of time (window size for calculating the PRR).
At last, to ensure that all the nodes will remain in the same channel after the hop-ping process, each node needs to wait for the maximum transition time before it starts the diagnostic test again in the new channel. Although the theoretical maximum tran-sition time can be as large as dozens of seconds for middle-scale network, practically the hopping messages, propagated in such a flooding fashion, often result in multiple
CHAPTER 6. FREQUENCY HOPPING MECHANISM 35
copies of the messages being passed around the network. Even when the network is affected by background traffic and has a high packet loss rate, all nodes are likely to receive the hopping message and hop to the next channel within a small amount of time.
Chapter 7 Evaluation
In this section, trace-driven simulations, are used to evaluate the key components in the proposed frequency hopping mechanism: (1) transition delay of the hopping signaling protocol and the (2) accuracy of the diagnostic tests when using more realistic and long-term traces.
7.1 Trace Synthesis
Results of the evaluation depend on the interaction between a Zigbee-based indoor lo-calization system and WiFi noise in an actual environment. To obtain long-term RSSI, PRR and WiFi co-traces, we could follow the measurement methodology detailed in Section 4 and simply let the receiving tag, beacon nodes, and the WiFi traffic logger run simultaneously for several days. However, because the system was installed in a public area, continuously monitoring the receiving tag throughout the experiment
36
CHAPTER 7. EVALUATION 37
Figure 7.1: One-Hour WiFi Data Rate
Figure 7.1: One-Hour WiFi Data Rate