Sigfox localization using limited Wi-Fi fingerprints Thomas Janssen Promotor: Maarten Weyn Co-promotor: Rafael Berkvens Outdoor Sigfox localization using limited Wi-Fi fingerprints U hebt het waarschijnlijk al eens meegemaakt: Je kan je smartphone maar niet vinden, en je vraagt hopeloos aan iemand om er even naar te bellen om hem te lokaliseren. Als hij dan nog eens op stil staat, dan ben je nog verder van huis. Zijn er geen andere manieren om apparaten met Wi-Fi te lokaliseren? De focus van dit onderzoek ligt op de nauwkeurigheid van outdoor lokalisatie van Wi-Fi devices.

Research methods & equipment Contents Wi-Fi localization Research methods & equipment Results WiGLE LocationAPI Conclusion Eerst gaan we eens kijken wat Wi-Fi lokalisatie is en hoe het werkt. Vervolgens zal ik vertellen hoe we te werk zijn gegaan. Daarna bespreek ik de resultaten van de experimenten, om zo tot een conclusie te komen.

Goal “How accurate can we locate Wi-Fi devices using only 2 BSSIDs with reduced power consumption?” Het doel van dit onderzoek is om te bepalen hoe nauwkeurig we een device met Wi-Fi kunnen lokaliseren op basis van 2 Wi-Fi access points, en dat met zo weinig mogelijk P-verbruik.

Goal LPWAN Sigfox network: 868 MHz band “How accurate can we locate Wi-Fi devices using only 2 BSSIDs with reduced power consumption?” LPWAN Sigfox network: 868 MHz band 12 bytes / message (= 2 MAC addresses) 140 msg / day 1 % duty cycle Max. power of 25 mW Sigfox is een LPWAN network op de 868 MHz ISM-band. Max 12 bytes per bericht en max 140 berichten per dag. 12 bytes is net genoeg om 2 MAC adressen van 48 bits, dus 6 bytes, door te sturen. Er mag ook maar 1 % van de tijd gestuurd worden met een max P van 25 mW.

Wi-Fi localization WPS  Wireless Access Points GNSS (e.g. GPS) Outdoor + indoor Various databases GNSS (e.g. GPS) Outdoor Satellite GPSsatelliet, WPS access points. WPS gebruikt minder E en kan ook indoor lokaliseren. Dit gebeurt via een fingerprinting techniek, waarbij een database wordt geraadpleegd om op te vragen welke access points zich waar bevinden. Die database is gevuld door wardrivers, dit zijn mensen die met geschikte HW en SW de wereld rondrijden en data in de database uploaden. Dit kan ook crowdsourced gebeuren met een smartphone app. 50 miljard devices aan IoT tegen 2020  WPS toepassingen: smartphones, M2M, asset tracking … Source: Uwinloc

Wi-Fi localization: Fingerprinting How to get your current location? Discover nearby networks (no need to connect) Perform request of BSSIDs to the database The database responds with a coordinate Hoe kan je nu je huidige locatie bepalen met Wi-Fi lokalisatie? Dit gebeurt in 3 stappen. De 1e stap bestaat uit het zoeken naar Wi-Fi netwerken in je omgeving, je hoeft er niet mee te verbinden. In de 2e stap vragen we de gevonden BSSIDs (= Basic Service Set Identifier, MAC-adres van AP) op in een database. In de 3e stap zal de database een respons sturen met daarin de coördinaat van elk access point.

Equipment WiGLE LocationAPI Op deze slide vindt u al het materiaal, SW en HW die we gebruikt hebben. Ik ben met fiets, GPS en laptop naar enkele locaties in en rond Antwerpen geweest. De verwerking van de data en requests naar de database gebeuren via Python scripts. De gebruikte databases zijn WiGLE (Wireless Geographic Logging Engine) en LocationAPI, omdat deze respectivelijk de meeste access points wereldwijd en in België bevatten. Om de data visueel weer te geven, gebruikten we Excel en MATLAB. WiGLE LocationAPI

Measurements – Step 1: Collect data De eerste stap van het lokalisatie proces was het verzamelen van data. Ik heb in totaal 36 metingen gedaan op locaties verspreid over heel Antwerpen.

Measurements – Step 2: Perform requests Python scripts: HTTP-request to databases WiGLE: request single BSSID LocationAPI: request pair of BSSIDs (with and without RSSI) Save responses to Excel sheets (empty cell = no match in database) BSSID (= MAC of WAP) Coordinate 56:67:31:0f:0e:3f 51.292682, 4.506222 e2:b9:e5:72:ac:4e 51.297109, 4.504937 00:0a:95:9d:68:16 51.295830, 4.469273 2e stap: HTTP-request sturen naar de database voor elk gevonden BSSID. Bij WiGLE kon je 1 BSSID per request vragen, bij LocationAPI moeten dat er minstens 2 zijn. Ook hebben we request gedaan met, naast de BSSID als input, ook de RSSI, de signaalsterkte. Hier kom ik later nog op terug. De data wordt opgeslagen in Excel sheets. Als een cel leeg is, is de BSSID niet gevonden in de database en kan er dus geen coördinaat worden teruggegeven.

Measurements – Step 3: Process data Per location: Generate all possible combinations of 2 BSSIDs Calculate mean coordinate of each pair of BSSIDs Calculate distance error between measurement location and GPS location  Haversine function In de laatste stap wordt de verkregen data verwerkt. Eerst worden alle mogelijke combinaties van 2 BSSIDs gegenereerd. Van elk paar berekenen we dan de gemiddelde coördinaat. Vervolgens berekenen we de error, dit is het verschil tussen de locatie waar ik me werkelijk bevond en de locatie die berekend werd. Dit gebeurt met de Haversine functie, die rekening houdt met de kromming van de aarde.  gemiddelde en de mediaan van alle errors op de verschillende locaties en tot slot visualiseren we deze data met een histogram, een CDF en een heatmap. CDF = Cumulative Distribution Function en ziet er zo uit: (klik)

Measurements – Step 3: Process data Per location: Generate all possible combinations of 2 BSSIDs Calculate mean coordinate of each pair of BSSIDs Calculate distance error between measurement location and GPS location  Haversine function Calculate mean and median distance error Calculate chance of match in database Visualization: histogram + CDF + heatmaps In de laatste stap wordt de verkregen data verwerkt. Eerst worden alle mogelijke combinaties van 2 BSSIDs gegenereerd. Van elk paar berekenen we dan de gemiddelde coördinaat. Vervolgens berekenen we de error, dit is het verschil tussen de locatie waar ik me werkelijk bevond en de locatie die berekend werd. Dit gebeurt met de Haversine functie, die rekening houdt met de kromming van de aarde.  gemiddelde en de mediaan van alle errors op de verschillende locaties en tot slot visualiseren we deze data met een histogram, een CDF en een heatmap. CDF = Cumulative Distribution Function en ziet er zo uit: (klik)

4 measurement locations Results - WiGLE 4 measurement locations Op deze grafiek zijn de resultaten van 4 meetlocaties weergegeven. Deze twee locaties bevatten metingen die allemaal resulteren in een error die kleiner is dan 150 m. Bij de paarse curve ligt 95% van de metingen onder de 200 meter.

BAP8: CDF with mean = 101,283 km and median = 45 m Results - WiGLE BAP8: CDF with mean = 101,283 km and median = 45 m Er zijn echter ook locaties waar er enorm grote errors zijn. Hier zijn bvb outliers van 1600 km, wat leidt tot een coördinaat in Portugal… We hebben zelfs een access point gediscovered dat zich volgens de database in Brazilië bevindt! Wanneer we echter inzoomen (klik), zien we dat meer dan 90% van de metingen een error heeft van amper 150 m. De horizontale lijn geeft aan dat alle combinaties die een ‘corrupt BSSID’ bevatten een zeer grote afwijking geven. Outliers Detail

Results - LocationAPI Requests without RSSI Requests with RSSI Voor LocationAPI hebben we hetzelfde gedaan, maar we hebben ook gekeken naar het verschil tussen de requests met en zonder RSSI. Zo kunnen we zien dat er op sommige locaties een verschil is, bijvoorbeeld de lichtblauwe curve heeft een grotere max error, terwijl de max error bij de zwarte curve kleiner is als we de RSSI mee doorsturen. Opmerking: periode tussen requests met en zonder RSSI  wijzigingen in database!

Results – Comparison of databases WiGLE: median = 82 m mean = 6,3 km LocationAPI: median = 52 m mean = 15,9 km Als we de distance errors van alle locaties vergelijken, komen we op een gemiddelde error van 6 km voor WiGLE en 16 km voor LocationAPI. Dat is een enorme error, die volledig te wijten is aan de outliers. Wanneer we echter kijken naar de mediaan, vinden we een veel kleinere error van 82 m voor WiGLE en 52 m voor LocationAPI.

Median distance errors: WiGLE LocationAPI Dan komen we aan misschien wel de belangrijkste slide van deze presentatie. Op de kaart staan cirkels bij de 36 meetlocaties. De straal van de cirkel is een maat voor de grootte van de median error op een locatie. Dus hoe groter de cirkel, hoe kleiner de accuracy. We zien dat in bijna alle gevallen de error van LocationAPI (oranje) groter is dan die van WiGLE.

Results – Statistics Chance of no match in databases = 13 % 𝐶ℎ𝑎𝑛𝑐𝑒 𝑜𝑓 ′𝑐𝑜𝑟𝑟𝑢𝑝 𝑡 ′ 𝑐𝑜𝑚𝑏𝑖𝑛𝑎𝑡𝑖𝑜𝑛= # 𝑒𝑟𝑟𝑜𝑟𝑠 𝑎𝑏𝑜𝑣𝑒 𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑 𝑣𝑎𝑙𝑢𝑒 # 𝑒𝑟𝑟𝑜𝑟𝑠  mean chance ≈ 7,5 % Vervolgens hebben de kans berekend dat de kans op geen match in de database 13% is. De kans dat we een combinatie sturen met een ‘corrupt’ BSSID werd ook berekend. Daarvoor hebben we een drempelwaarde gedefinieerd. De kans is voor beide databases ongeveer 7,5%.

Results – Urban vs. Rural areas We hebben ook onderzocht of er een verband is tussen het soort gebied en de error die er gemeten werd. Op deze grafiek zijn 6 minder bevolkte gebieden aangeduid (zoals bijvoorbeeld in parken). We zien dat daar 3 van de 5 grootste errors zijn gemeten, maar er zijn ook errors die zeer klein zijn, waardoor we niet kunnen zeggen dat er een verband is tussen het soort gebied en de gemeten error.

Results – Send combination with highest RSSI + Accuracy - Energy consumption WiGLE: median: 82  56 m mean: 6 km  93 m ! LocationAPI: median: 52  35 m mean: 16 km  46 m ! Om de accuracy van de meting op te drijven, hebben we geprobeerd om enkel de combinatie van BSSIDs met de hoogste RSSI te sturen. Dit vraagt meer rekenwerk en dus meer P-verbruik, maar kan de accuracy wel doen toenemen. We zien ook echt een veel betere gemiddelde error: Bij WiGLE daalt het gemiddelde van 6 km naar slechts 93 m en bij LocationAPI daalt het gemiddelde van 15 km naar amper 46 m!

87 % chance of match in database Conclusion The accuracy of outdoor Wi-Fi localization, using only 2 BSSIDs 87 % chance of match in database LocationAPI mean 46 m Outliers? Control mechanisms! WiGLE mean 93 m We kunnen dus concluderen dat we Wi-Fi devices kunnen lokaliseren met een gemiddelde accuracy van 93 m als we de WiGLE database gebruiken en 46 m als we de LocationAPI database gebruiken. We moeten wel rekening houden dat er een kans is van 13 % dat er geen match is in de database. Er zijn ook grote outliers in de metingen. Dit komt omdat de data grotendeels crowdsourced is, wat wil zeggen dat iedereen een gratis profiel kan aanmaken en foutieve data kan uploaden. Daarom moeten we ervoor zorgen dat de lokalisatie applicatie voorzien van controle mechanismen. Zo kunnen bvb ‘corrupte’ BSSIDs worden gefilterd of kan aan DAD gedaan worden om MAC spoofing tegen te gaan. Bedankt voor uw aandacht en als er nog vragen zijn, hoor ik ze graag!