TrackMe

1. TrackMe Presenting: Nir Maoz & George Pleener Directed by: Edward Bortnikov

2. TrackMe Mesh Network Algorithms Nomadic Service Points

3. The Idea • Using real wireless data to run in simulations, for different algorithms. • Comparing the effectiveness of different algorithms on real data.

4. The CRAWDAD Project CRAWDAD–Community Resource for Archiving Wireless Data At Dartmouth

5. CRAWDAD: Data Collected • Data collected at Dartmouth college by keeping track of the access points a student switches through during his stay at the campus. • A textual database, ~200MB in size. • There are larger versions. We used the smallest one available.

6. AP Database CRAWDAD: WiFi Network • About ~6,000 students had participated. • 623 access points. • 19% of which had an unknown location. • AP DB format: {AP_Name, x, y, z}

7. MV Database (per one user) Movement Database • ~6,000 files - one per student/user. • Every reassignment is written as a row. • MV DB format: {Time, AP} • Time in timestamp format.

8. CRAWDAD: AP Interpolation • 623 access points. • 19% of which had an unknown location – problematic APs. • Filling in the gaps: An iterative algorithm that runs through the movement DB and finds references to problematic APs, attempting to fix their location.

9. CRAWDAD: AP Interpolation AP_1 X=10 0 AP_2 X=?? AP_2 X=15 1 Index AP_3 X=20 2

10. Index CRAWDAD: AP Interpolation • Inspecting user paths, looking for problematic APs surrounded by known APs. • Using a recursive formula for finding the AP’s location, using it’s history and the surrounding known APs.

11. CRAWDAD: AP Connection • The mesh network is made out of ~600 APs. • Maximal transmission distance was taken to be 133.8 meters. • This is the minimum for insuring complete network connectivity.

12. CRAWDAD: AP Connection

13. CRAWDAD: AP Connection

14. Simulation Model Simulator & Cost

15. Simulation • Every time slot (100 sec) a server reassignment might occur, depending on the algorithm. • If the server assignment changes, we pay a setup cost for setting up the new link and hold cost for the rest of the time slot. • In case of no change, only hold cost is paid.

16. Cost Model • All algorithms use a shortest path algorithm, to find the path to the closest server. • Each hop from AP to AP, along the path, results in a 1% packet loss, due to wave transmission. • Setup Cost • Setup takes 1sec. Hence – cost = 640 packets. • Hold Cost • By the formula:

17. Movements (Greedy Example) SRV 2 SRV 1 Current AP: 1 1 1 2 2 1 3 2 2 4 1 1 Current Server: Hops (Length): 4 3 2 1

18. Algorithms Greedy, CTrack, DTrack & Optimal

19. Greedy Algorithm Idea – always choose the shortest path in that moment. • Each second the algorithm checks to see if there is a better (less hops) server assignment for the user. • If so – switch, • Otherwise – stay.

20. CTrack Algorithm Idea – force the user to stay at a server for some minimal amount of time. If user is irritable – stalling the decision might be a good idea. • Requires the user to stay for a minimal amount of time at each server, before switching. • Even when there is a closer server, as opposed to the greedy algorithm.

21. DTrack Algorithm Idea – at any time, check what the gain would have been if the user was attached to another server. • Each second the algorithm checks how much the user would have benefited if he were attached to a different server. This value is called the deficit. • When the deficit grows above some predefined value - switch to the closest server.

22. Optimal Algorithm Idea – find the best possible assignment to servers along the user’s path. In essence, find the optimal solution to our problem. • This is the best offline algorithm. • Using this algorithm is possible only if we know the entire path the user takes in advance (e.g. offline). • Uses dynamic programming to find the optimal assignment to servers, filling it in, going backwards - from the last time slot to the first.

23. Simulation Results Greedy, CTrack, DTrack & Optimal Algorithm Runs

24. Simulation Parameters • Time slots are 100 seconds each. • For CTrack & DTrack, use the following parameters:

25. Average Total Cost

26. Average Ratio

27. User Count

28. Future Development Problems Encountered & Future Recommendations

29. The Time Slot Problem • The MV database has in each row, not a time slot, but rather a variable-time slotted AP assignment. • The algorithms require a fixed-time slotted DB format (constant time). • Optimal solution: Convert DB (on disk or on the fly) to fixed-time slotted format. • Problem: Original DB is ~200MB, after conversion, algorithms would require many days to run on a PC. In fact, the conversion process itself would be extremely long.

30. The Time Slot Problem • There is a large variance in the values of delta in our database (from seconds to hours to days). • Using a fine resolution would result in a database too big to run over using a PC. • Using a rough resolution would result in inaccuracy. • The solution we used was to run over the users’ paths only partially, slicing the variable-time slots into fixed-time slots. Stopping after SIM_LENGTH (= 100) time slots have passed.

31. Future Development • Check if the parameters of CTrack & DTrack can obtain better results. • We don’t think they can gain results of a different magnitude, but it’s worth checking out.

32. Software Used • The Eclipse SDK. Java 5.0, and some Perl. • Microsoft Excel – For all data analysis, graphical representation and filtering. • Matlab 6.5 - For statistical analysis of the average total cost results. • Microsoft PowerPoint – For the presentation. • Google Earth, for finding the geographical units used (feet) in the GPS based AP database. • Adobe Photoshop 7.0 – For graphical maps.

33. Acknowledgements • CTrack, DTrack & Optimal algorithms by Edward Bortnikov. • CRAWDAD Project done at Dartmouth college, for all the data used in simulations in this project.