![Using these time stamps we can calculate the offset between coordinator and end point time, and the round
trip delay due to the ZigBee communication.
● ffset θ ) (t )] / 2O = = [(t1 − t0 − 2 − t3
● elay δ t ) (t ) D = = ( 3 − t0 − 2 − t1
With these calculated statistics, we can come up with a plan on synchronizing an event between BeagleBone
Black boards over the ZigBee network.
Implementation details
To implement our authentication system we utilize two BeagleBone Blacks (BBB) and two Zigbee Xstick usb
modules to enable a wireless serial link between the two BBB. Our system is written using the GO language
platform and utilize the time, format, OS, syscall, unsafe, and a C library for getting cycle counts. For simplicity,
the two BBB are set to run at 1 Ghz, which results in a 1 nanosecond clock period. Using this simplification, we
can easily convert number of cycles to a time duration in nanoseconds.
The first thing our two node system does is synchronize their times with each other. This is described in the
previous section under “Analyzing time synchronization through delay and offset statistics.” Once the two BBB
have been synced with each other, one board sends the request for key authentication to be received
sometime in the future from now. Prior to sending the request, the coordinating board will begin a cycle timer
to enforce the lower bound requirement within the acceptance window. The cycle timer is implemented
through constantly calculating the difference in cycle counter values until the difference is equal or greater
than the necessary time. If the key is received before the timer expires then the authentication fails. On the
other end, the second BBB in our system receives the key request and will wait until the appropriate amount
of time based on the time synchronized information of the system before sending the key over to the
coordinating BBB. The waiting is implemented through the same methodology as the cycle timer in the
coordinating board. Calculating the difference between cycle counter reads proved to be significantly more
accurate than using any kind of sleep function provided by either the C language environment or the Go
language environment. The coordinating BBB then checks to make sure that the key is received within the
upper bound of the acceptance window. If the key is not received during the specified period (as enforced
through the lower bound timer and the upper bound timer), the authentication mechanism fails. More
information concerning window size and other system characteristics can be found in the characterization
sections.
In our implementation, we have determined that the offset that was calculated during time synchronization is
unnecessary for coordinating our synchronized event of key authentication. This simplification is due to the
timing characteristics of the two BBB. Because each BBB is set to run at the same frequency, the time
progression is identical in each of the boards. Therefore a fixed delay in one board represents the same fixed
delay in the other board. The only corrections that have to be applied in the receiving board is to account for
the delays of transmitting information wirelessly from one BBB to another BBB through the Zigbee stack.
The demo portion of our application involves triggering an event of some kind depending on the success of the
authentication. Our demonstration uses two LEDs through two GPIO ports on the coordinating BBB. When the
application is locked, one of the two LEDs will be on. When the application is unlocked through authentication,](https://image.slidesharecdn.com/d8069a44-8aed-4be7-9678-6bd7e9a48b36-160307211249/85/Synchronous-Security-Authentication-Report-2-320.jpg)
Synchronous Security Authentication Report
- 1. Sebastian Cheah A53081673 Roger Huang A09230317 Final Report Overview This report is both an analysis of time synchronization between two BeagleBone Blacks (BBBs) each with a Zigbee Xstick for wireless communication capabilities and an application description that utilizes a wireless system with high resolution for time synchronization between two nodes. The following report is organized as follows: an application description, an analysis of time synchronization, our implementation, our methodology of characterization, the characterization of our initial implementation, potential optimizations, the characterization of the optimized implementation, and finally a conclusion to our project. Application When nodes can be time synchronized with high resolution there are many applications that can utilize this capability. We decided to apply time synchronization as a security authentication method. One node in the system will expect to receive keys during a specific window of time. If the keys are not received in the window of time, the authentication fails. All keys must therefore transmit accurately in timing according to a master clock. This application can thus only be accomplished if the nodes in the system have a high degree of time synchronization between each other. As the time synchronization accuracy between the nodes improves, the window of key acceptances can shrink and the validity of authentication through this method improves. Analyzing time synchronization through delay and offset statistics We use an algorithm based off of the Network Time Protocol (NTP) clock synchronization algorithm. We perform a round trip communication between coordinator and end point. We store four specific time stamps: ● t0 is the coordinator’s timestamp of the request packet transmission ● t1 is the end point’s timestamp of the request packet reception ● t2 is the end point’s timestamp of the response packet transmission ● t3 is the coordinator’s timestamp of the response packet reception
- 2. Using these time stamps we can calculate the offset between coordinator and end point time, and the round trip delay due to the ZigBee communication. ● ffset θ ) (t )] / 2O = = [(t1 − t0 − 2 − t3 ● elay δ t ) (t ) D = = ( 3 − t0 − 2 − t1 With these calculated statistics, we can come up with a plan on synchronizing an event between BeagleBone Black boards over the ZigBee network. Implementation details To implement our authentication system we utilize two BeagleBone Blacks (BBB) and two Zigbee Xstick usb modules to enable a wireless serial link between the two BBB. Our system is written using the GO language platform and utilize the time, format, OS, syscall, unsafe, and a C library for getting cycle counts. For simplicity, the two BBB are set to run at 1 Ghz, which results in a 1 nanosecond clock period. Using this simplification, we can easily convert number of cycles to a time duration in nanoseconds. The first thing our two node system does is synchronize their times with each other. This is described in the previous section under “Analyzing time synchronization through delay and offset statistics.” Once the two BBB have been synced with each other, one board sends the request for key authentication to be received sometime in the future from now. Prior to sending the request, the coordinating board will begin a cycle timer to enforce the lower bound requirement within the acceptance window. The cycle timer is implemented through constantly calculating the difference in cycle counter values until the difference is equal or greater than the necessary time. If the key is received before the timer expires then the authentication fails. On the other end, the second BBB in our system receives the key request and will wait until the appropriate amount of time based on the time synchronized information of the system before sending the key over to the coordinating BBB. The waiting is implemented through the same methodology as the cycle timer in the coordinating board. Calculating the difference between cycle counter reads proved to be significantly more accurate than using any kind of sleep function provided by either the C language environment or the Go language environment. The coordinating BBB then checks to make sure that the key is received within the upper bound of the acceptance window. If the key is not received during the specified period (as enforced through the lower bound timer and the upper bound timer), the authentication mechanism fails. More information concerning window size and other system characteristics can be found in the characterization sections. In our implementation, we have determined that the offset that was calculated during time synchronization is unnecessary for coordinating our synchronized event of key authentication. This simplification is due to the timing characteristics of the two BBB. Because each BBB is set to run at the same frequency, the time progression is identical in each of the boards. Therefore a fixed delay in one board represents the same fixed delay in the other board. The only corrections that have to be applied in the receiving board is to account for the delays of transmitting information wirelessly from one BBB to another BBB through the Zigbee stack. The demo portion of our application involves triggering an event of some kind depending on the success of the authentication. Our demonstration uses two LEDs through two GPIO ports on the coordinating BBB. When the application is locked, one of the two LEDs will be on. When the application is unlocked through authentication,
- 4. As seen from the table and graphs provided, the performance of our initial implementation is not that great. The round trip delay measurements are quite large and the minimum and maximum values differ significantly. The jitter associated with the delay is also unstable in our initial implementation. Because of all of these variances in our delays and jitter values, the acceptance window in our initial implementation was quite large. The large acceptance window size ensures that our authentication application succeeds. One issue regarding the Zigbee protocol was left unsolved in our initial version of the application. For some reason when collecting data, our application tends to stall after just four iterations. This makes it extremely difficult to gather enough samples for behavior analysis. The samples are the round trip delays related to simply exchanging timestamps between each of the boards. After exchanging timestamps four times, our application stalls for awhile before resuming, at which point the progress through our testbench application is sporadic. Instead of a linear continuous execution stream of progress, the application manages to only finish between two to six iterations at a time before stalling. The benchmark application for delay analysis is meant to repeatedly exchange timestamps one hundred times from which the median and jitter can be calculated. Potential Optimizations We first begin analyzing the data path beginning from running a GO application until a message is sent from the BeagleBone board. Along the way, there could be optimizations applied to the GO application to optimize the run time performance. (compiler etc). We must also consider when we send a message through the USB to Serial driver. We identify this driver as: Bus 001 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB‐Serial (UART) IC There is a USB to Serial latency issues that can arise and be improved upon. In a USB to serial converter, the FTDI chip buffers data it receives until either the buffer is full, or until a timer triggers the buffer to flush because no data has come on the serial port for a fixed amount of time. As such, we need to consider the latency timer and the block request size. Default values for these parameters are 16ms and 4096 bytes respectively. The USB buffers packets of fixed size 64 bytes at a time. As such, latency can be calculated as the following: aximum Latency latencyTimer lockRequestSize/64M = * b With the default parameters, latency can be at most 1.024 seconds. This presents an opportunity for improvement. Instead of using the default parameters, we can instead use customized parameters tailored to our particular application. Our application communications with small packet sizes, so a latency timer of 1ms and block request size of 64 bytes would be the best available values to change to. This change would involve either modifying the current USB driver onboard the BBB or interfacing the BBB with another compatible USB driver that could be modified for the specific application. There are two specific methods to interface with the FT232 USB UART: through the Virtual COM Port (VCP, which runs by default onboard the BBB) or through D2XX drivers. D2XX drivers provide a useful interface for setting the latency timer and block request size. We set these values to 1ms and 64 bytes respectively.
- 6. each of the Zigbee modules was set to correspond to the address of the other module, a point to point link was established and performance should improve. Characterization of final optimized implementation One issue that is still unresolved is related to starting up the Zigbee stick on the endpoint board. After the board powers up, the Zigbee stick maintains a solid LED. However, once our application is executed for the first time the LED turns off for some undefined duration before powering back on. We currently do not have an explanation for this particular behavior between the USB module and the BBB. TTYUSB0 (VCP)‐broadcast TTYUSB0 (VCP)‐P2P D2XX Average Round Trip Delay 259222500 ns / 259.223 ms 42118500 ns / 42.119 ms 63595000 ns / 63.595 ms Average Jitter to Round Trip Delay 55505158 ns / 55.505 ms 6755530 ns / 6.756 ms 2326480 ns / 2.326 ms Window Size 500 ms 100 ms 100 ms