Fakulteten för teknik och samhälle Datavetenskap
Examensarbete
15 högskolepoäng, grundnivå
Simuleringar av Bluetooth mesh-nätverk i ett dynamiskt
och storskaligt tätbefolkat område
Simulations of a Bluetooth mesh network in a dynamic and large densely populated area
Oliver Ahlberg
Isadora Persson
Examen: Kandidatexamen 180 hp Huvudområde: Datavetenskap Program: Systemutvecklare Datum för slutseminarium: 2016-05-27Handledare: Mia Persson
Sammanfattning
Mobil datakonsumtion har drastiskt ökat de senaste åren vilket belastar de existerande kommunikationsnätverken. I och med den ökade belastningen av existerande infrastruktu-rer krävs det nya kommunikationslösningar. Detta har i sin tur skapat ett behov för dataav-lastning på fasta nätverk, exempelvis Wi-Fi-nätverk. I denna studie undersöker vi genom simuleringar hur vi kan underhålla ett storskaligt och dynamiskt Bluetooth meshnätverk i en miljö likt Stortorget under Malmöfestivalen. Vi implementerar en nätverkstopologi för Bluetooth, scatternettopologin, i nätverkssimulatorn NS-3 och utför simuleringar där vi provocerar förändringar i topologin. Resultaten av våra simuleringar visar på att nätverket lyckas återhämta sig vid förändring i topologin, att scatternettopologin minst klarar av 240 dynamiska mobila noder samt att max 3 noder påverkas vid förändringar i topologin för simuleringar av upp till 240 noder.
Abstract
Mobile data consumption has drastically increased in the recent years which stress the existing communication networks. As an effect of the increased load a demand for new communication solutions has arisen, creating a need for data offloading onto fixed networks such as Wi-Fi. In this thesis, we aim to study how to maintain and reconstruct a large and dynamic Bluetooth mesh network in an environment such as Stortorget during Malmöfes-tivalen. We implement a network topology specific for Bluetooth, the scatternet topology, in the network simulator NS-3 and run simulations in which we provoke changes in the network topology. The result of our simulations shows that the network is able to heal itself when the topology changes, that the scatternet topology can manage up to 240 dynamic mobile nodes and that at most 3 nodes are affected when the topology changes during simulations of up to 240 nodes.
Innehåll
1 Introduktion 1
1.1 Syfte med studie . . . 2
1.2 Frågeställning . . . 2 1.3 Avgränsningar . . . 3 2 Teoretisk bakgrund 4 2.1 Nätverk . . . 4 2.1.1 Peer-to-peer-nätverk . . . 4 2.1.2 Subnätmask . . . 4 2.1.3 MAC-adress . . . 4 2.1.4 Protokoll . . . 4 2.2 Bluetooth . . . 5 2.3 Trådlösa meshnätverk . . . 5 2.3.1 MANET . . . 6 2.3.2 Routing . . . 6 2.3.3 Piconet . . . 7 2.3.4 Scatternet . . . 8 2.3.5 BMN . . . 9 2.4 Bluetooth-topologier . . . 9 2.4.1 Ring . . . 9 2.4.2 Star . . . 10 2.4.3 Peer-to-peer . . . 10 2.4.4 Scatternet . . . 10 2.5 BLE Mesh . . . 11
2.6 Efficient Bluetooth topology construction protocol . . . 12
2.7 NS-3 . . . 13 3 Metod 14 3.1 Mixed methodology . . . 14 3.2 Källor . . . 15 3.2.1 Databaser . . . 15 3.2.2 Sökord . . . 15 3.3 Vår kvalitativa metod . . . 16 3.3.1 Val av metod . . . 16
3.3.2 Utförande av vår kvalitativa studie . . . 16
3.4 Vår kvantitativa studie . . . 17
3.4.1 Val av metod . . . 17
3.4.2 Utförande av vår kvantitativa studie . . . 17
4 Relaterad forskning 19 4.1 Efficient Bluetooth topology construction protocol . . . 19
4.2 BLE Mesh . . . 20
4.3 Simulation of Algorithms for Mobile Ad-Hoc Networks . . . 20
4.3.2 Star . . . 20
4.3.3 Peer-to-peer . . . 21
4.4 Val av topologi . . . 21
5 Vår fallstudie 22 5.1 Scenario - Malmöfestivalen . . . 22
5.2 Vår simuleringsmiljö och implementation . . . 23
5.2.1 Val av simulator . . . 23
5.2.2 Initiering av nätverket . . . 24
5.2.3 Vår implementation av scatternettopologins algoritmer . . . 25
5.3 Genomförande och mätning av våra simuleringar . . . 30
5.3.1 Presentation av data . . . 32
5.4 Felkällor . . . 32
6 Resultat 34 6.1 Scatternet healing time . . . 34
6.2 Antal rekonstruktionspaket skickade per nod tills nätverket återhämtat sig . 34 6.3 Antal bortkopplade slave-noder när den mest centrala master-noden går ner 35 6.4 Visuell simulering av rekonstruktion vid bortkopplad nod . . . 35
6.5 Visualisering av nätverkstopologi . . . 36
7 Analys och diskussion 38 7.1 Våra simuleringsresultat . . . 38
7.1.1 Scatternet healing time . . . 38
7.1.2 Rekonstruktionspaket . . . 39
7.1.3 Antal påverkade noder vid rekonstruktion . . . 40
7.1.4 Topologin efter rekonstruktion . . . 41
7.2 Analys av vår implementation . . . 42
7.3 Analys av NS-3 som nätverkssimulator . . . 43 8 Sammanfattning och vidare forskning 44
9 Appendix 1 - Intervju 46
1
Introduktion
Datakonsumtionen på mobila enheter har ökat drastiskt de senaste åren vilket belastar existerande kommunikationsnätverk. I och med den ökade belastningen av existerande in-frastrukturer krävs det nya kommunikationslösningar. Mobila nätverk blir tungt belastade på grund av spridningen av mobila enheter och trafikhungriga applikationer.
Det finns ett behov för avlastning, därför har avlastningsstrukturer utvecklats mycket under de senaste åren. Under 2015 avlastades totalt 51 procent av total datatrafik från enheter uppkopplade på mobilnät på fasta nätverk så som Wi-Fi [1].
Att använda lokala nätverksreläer istället för att skicka data via 3G- eller 4G-nätverk belastar telenätverket mindre och är ett mer ekonomiskt och miljövänligt alternativ [2]. I en studie från 2013 bevisar Lee m.fl [3] att nätverksavlastning via Wi-Fi är ekonomiskt fördelaktigt både för nätverksleverantörer och för användare. De visar även att det kan vara från 73 % till 319 % billigare för användaren och från 21 % till 152 % billigare för leverantören.
Enligt Cisco finns det från och med 2014, fler mobila enheter i världen än människor [1]. Många människor är beroende av sina mobiltelefoner och att vara uppkopplade hela tiden berättar Lin [4].
Tidigare lösningar på nätverksproblem i tätbefolkade områden är Cloud Computing. Fer-nando m.fl. [5] beskriver tre olika lösningar av mobila cloudnätverk; avlastning till en nätverksserver, ett lokalt cloudlet och ett mobilt peer-to-peer-nätverk. När cellulära- eller Wi-Fi-länkar inte är tillgängliga eller tillräckligt starka, kan ad hoc-nätverk införas som ett alternativ enligt Liu [6].
Mobil cloud computing är uppbyggt av flera mobila enheter som tillhandahåller sina resur-ser i ett peer-to-peer-nätverk. De ihopkopplade enheterna utnyttjar varandras resurresur-ser för att avlasta varandra och samarbeta för ökad effektivitet. Fernando m.fl. [5] menar att vissa aktiviteter är mer lämpade att utföra i ett mobilt peer-to-peer-nätverk, så som delning av internetåtkomst, crowd computing och sensordatabaserade applikationer.
Inom ett mobilt cloud computing peer-to-peer-nätverk kan man använda olika nätverks-protokoll för nätverkskommunikation. Dessa kan vara Wi-Fi, Wi-Fi Direct, NFC och Blu-etooth [6].
Bluetooth är mer energisnålt än Wi-Fi vilket gör Bluetooth lämpligt att använda i mobila enheter med begränsat batteri. Bluetooth har en räckvidd på cirka 10 meter till skillnad från NFC som endast når cirka 10 cm. År 2018 förutsägs det att 10 miljarder enheter är utrustade med Bluetooth [7]. Lee m.fl. [8] hävdar att dessa faktorer gör Bluetoothproto-kollet till ett alternativ när Wi-Fi- eller 3G-uppkopplingar inte är tillgängliga.
innovation. Därför har de bildat en specifik Bluetooth Smart Mesh Working Group för att ta fram en arkitektur för att standardisera meshnätverk för Bluetooth Smart-tekniken. Cambridge Silicon Radio (CSR) och Samsung har tagit fram protokoll för Bluetooth mesh-nätverk för Internet of Things-enheter så som smarta lampor och eluttag [10].
På en festival med flera tusen människor på en plats som är anslutna till samma 3g/4g-mast eller Wi-Fi-nätverk kan det bli problem med belastningen av nätverket när folk ska skicka sms, ringa och surfa samtidigt. I en sådan situation som på en festival är möjligheten att kontakta varandra viktigt eftersom det är lätt att tappa bort varandra i folkmängden, ljudvolymen gör det också svårt att ropa och kommunicera.
1.1 Syfte med studie
Det huvudsakliga syftet med studien är att simulera en lösning på problemet med högt belastad kommunikation mellan mobila enheter under extremt tätbefolkade och dynamis-ka förhållanden. Notera att vi i vår studie tillämpar den välkända radiomodellen [11] och därför är oberoende av existerande infrastruktur. Exempel på existerande nätverk i denna modell är cellulära- och Wi-Fi-nätverk.
Bluetooth är en relativt ny intressant teknik som erbjuder lovande decentraliserade lös-ningar på existerande nätverksproblem. Så vitt vi vet har inga tidigare studier fokuserat på en dynamisk och storskalig miljö i samband med rekonstruktion av Bluetooth meshnät-verk. Dock har flera studier studerat konstruktion i en statisk miljö [12, 13, 14, 15, 16, 17, 18, 19, 20]. I vår studie observerar vi hur väl dynamiska nätverk lyckas återhämta sig vid förändring i topologin så som att noder tillkommer, förflyttas och försvinner.
Detta är en praktisk studie där vi simulerar hur ett Bluetooth meshnätverk (BMN) be-ter sig i ett dynamiskt och tätbefolkat område med hjälp av nätverkssimulatorn NS-3. Vi använder Stortorget i Malmö under Malmöfestivalen som referensmiljö.
1.2 Frågeställning
F1 Kan vi underhålla ett storskaligt1 och dynamiskt Bluetooth meshnätverk där noder frekvent tillkommer, förflyttas och försvinner? Med underhålla avser vi här att nätverket återhämtar2 sig vid förändring i topologin.
F2 Hur implementerar vi en topologi för ett Bluetooth meshnätverk i den nya situ-ationen av en dynamisk miljö i NS-3?
F3 Hur stora nätverk kan vår implementerade topologi hantera?
F4 Hur många noder blir påverkade vid realistiska förändringar i topologin i relation till antal noder?
1
I kontexten av Bluetooth meshnätverk anser vi mer än 20 noder vara ett storskaligt nätverk.
2Med återhämtning av nätverket menar vi att alla noder som blir bortkopplade vid förändring i topologin
1.3 Avgränsningar
I syfte att besvara studiens frågeställning tittar vi enbart på en Bluetoothtopologi för att skapa och underhålla ett meshnätverk. Studien avgränsas till att undersöka hur ett nätverk med den valda topologin beter sig i en tätbefolkad och dynamisk miljö så som Malmöfes-tivalen.
Vi använder Malmöfestivalen som en lämplig referensmiljö i vår studie. Detta eftersom vi är stationerade i området och har personliga erfarenheter av brister i den mobila upp-kopplingen under Malmöfestivalen.
För att de praktiska delarna av undersökningen ska vara genomförbara inom tidsramen utförs experimenten i nätverkssimulatorn NS-3 [21]. Simulering är en effektiv metod som gör det möjligt för oss att återskapa ett scenario så att vi kan undersöka specifika nycke-laspekter av de tillämpade algoritmerna utan godtyckliga störningar.
Vi avgränsar oss till att undersöka tid, antal skickade rekonstruktionspaket och antal noder som påverkas av rekonstruktion i ett dynamiskt BMN då vi antar3 att dessa är några av de kritiska egenskaperna för att avgöra om ett BMN går att underhålla.
3
Notera att vi tvingas göra ett antagande på grund av att det så vitt vi vet inte finns några tidiga-re studier som formulerar kritiska egenskaper med avseende på tidiga-rekonstruktion av dynamiska Bluetooth meshnätverk.
2
Teoretisk bakgrund
2.1 Nätverk
2.1.1 Peer-to-peer-nätverk
Ett peer-to-peer-nätverk (P2P-nätverk) är ett decentraliserat nätverk där de anslut-na enheteranslut-na agerar som både server och klient. Enheteranslut-na kan på så sätt kommunicera med varandra direkt utan en central server och bandbredd och bearbetning distribueras bland de anslutna enheterna [22].
Ett ad hoc-nätverk består av enheter som är inom varandras räckvidd. Det är endast de enheter som är inom räckhåll för varandra som kan kommunicera och utbyta meddelan-den [23].
I ett meshnätverk kommunicerar anslutna enheter med sina närmaste grannar, som i sin tur kommunicerar med sina grannar, och så vidare. Varje ansluten enhet fungerar som en router vars mål är att hitta bästa vägen för ett meddelande att skickas från avsändare till mottagare [24].
2.1.2 Subnätmask
En subnätmask är det filter som sorterar internetmeddelanden till nätverk som är uppde-lade i subnät [56].
2.1.3 MAC-adress
MAC-address är ett unikt nummer som identifierar en dators anslutningspunkt i ett da-tornätverk [54].
2.1.4 Protokoll
Ett protokoll definierar en uppsättning regler för hur enheter ska interagera, hur data ska behandlas och formateras i ett nätverk [25].
2.1.4.1 UDP
UDP (User Datagram Protocol) är ett meddelandeöverföringsprotokoll som används till-sammans med internetprotokollet IP (UDP/IP). Det används oftast för broadcasting eller massutskick av meddelanden [55].
2.1.4.2 TCP
TCP (Transmission Control Protocol) är den del av internetprotokollet TCP/IP som tar hand om överföring av meddelanden från avsändarnod till mottagarnod [39].
2.2 Bluetooth
År 1994 satte Ericsson Mobile Communications igång en studie med syfte att undersö-ka möjligheterna av att använda kostnadseffektiva och energisnåla kortdistansradiolänundersö-kar (short-range radio links) för att koppla ihop digitala enheter trådlöst. Radiochippet, även känt som ”the Blutooth chip”, överträffade kraven på alla övriga mobila lösningar med hän-syn på kostnad, energikonsumtion, storlek och förmåga. I maj 1998 gick Ericsson, Nokia, IBM, Toshiba och Intel ihop och skapade Bluetooth Special Interest Group-konsortiet med syfte att standardisera användandet av mjukvara och gränssnitt för Bluetoothteknologin. Den första specifikationen av Bluetoothprotokollet släpptes på www.bluetooth.com i juli 1999 [26].
”Bluetooth can be described as a robust, simple, and economical technology that offers wireless access to LANs, Public Switched Telephony Network (PSTN), the mobile phone network and the Internet [26].”
Bluetooth har använts flitigt för trådlös ljudströmmning till headsets och högtalare både från datorer och mobila enheter. Med tillkomsten av Bluetooth Smart (eller BLE) kan utvecklare nu skapa små Bluetoothsensorer som drivs av knappcellsbatterier som har en batteritid på flera månader. Med hjälp av solenergi och rörelseenergi kan dessa sensorer ha en potentiellt oändlig livstid sett ur ett energiperspektiv. Detta resulterar i att Bluetooth nästan finns i all teknologi idag och Bluetooths låga energikonsumtion gör protokollet per-fekt för Internet of Things [27].
2016 kommer Bluetooth SIG lansera en ny Bluetoothversion som ökar räckvidden med fyra gånger och dubblerar hastigheten, utan att öka energikonsumtionen. De implemente-rar även mesh networking vilket möjliggör att Bluetoothenheter kan kopplas ihop i nätverk som kan täcka en hel byggnad eller ett hem. Mesh networking öppnar upp för automatise-ring av hemmet och industrier för applikationer och utvecklare [28].
2.3 Trådlösa meshnätverk
Ett trådlöst meshnätverk, WMN, är en nätverkstopologi där noderna inom nätverket utgörs av mobila, smarta enheter så som smartphones, wearables, datorer och tablets. Noderna inom nätverket samarbetar tillsammans vid överföring av data mellan enheterna [29]. I ett meshnätverk kan alla noder kommunicera med varandra, direkt eller indirekt [10]. Se figur 1.
Figur 1: Partiellt anslutet meshnätverk med 11 noder.
2.3.1 MANET
Ett mobilt ad hoc-nätverk, MANET, är ett mobilt meshnätverk där noder kommer och går enligt ad hoc-principen. Noder inom ett MANET förflyttar sig genom nätverket vilket leder till att topologin ständigt är i förändring [17, 30].
MANET nätverk är både självbildande och självläkande och tillåter mobila enheter att skapa temporära nätverk för att kommunicera med varandra utan att vara beroende av centraliserade resurser eller existerande infrastruktur. En nod kan alltså skicka data direkt till en annan nod, eller gå via mellanliggande noder utan att behöva förlita sig på bassta-tioner [31]. När två noder är inom varandras kommunikationräckvidd kan de utbyta data med varandra [32].
Ett MANET är decentraliserat och all nätverksaktivitet så som upptäckt av topologi och leverans av meddelande exekveras därför av de anslutna enheterna själva. Routingfunktio-nalitet är alltså integrerad i de mobila enheterna [31].
2.3.2 Routing
Routing är benämningen på den process som krävs för att sända paket genom ett nät-verk [33]. Ett nätnät-verk kan definieras av en uppsättning noder som är sammankopplade via länkar. Vägen från en nod, source, till en annan, destination, kallas ”route”. Routingproblem i ett nätverk består av att hitta den mest effektiva vägen mellan två noder i förhållande till tid, avstånd eller kostnad [34].
En routingtabell lagrar information om adressen till alla noder i nätverket och om hur de kommer till dem. Vid dynamisk routing skapas och uppdateras routingtabellerna auto-matiskt av programvara. Programvaran använder sig av ett routingprotokoll som beskriver hur nätverket ska se ut för att kunna bygga upp routingtabellerna. Om en nod försvinner eller läggs till i nätverket kommer noderna meddela detta till varandra och routingtabel-lerna uppdateras med den nya informationen. Nyqvist [33] menar att fördelen med detta är ett nätverk som i princip sköter sig självt och att protokollen kan hantera stora och komplexa nätverk som ständigt förändras.
och routingtekniker används för att vidarebefordra data genom nätverket. Flooding-baserade tekniker använder sig av broadcastmodellen för att skicka data till alla noder inom räckvidd, medans routingbaserade tekniker låter varje enhet att vidarebefordra data till den närmaste enheten i nätverket [29].
De flesta existerande routingtekniker för trådlösa meshnätverk förutsätter att alla noder i nätverket är statiska. Enligt Barak m.fl. [29] är detta inte ett realistiskt antagande eftersom det inte tillåter fördelarna med rörliga noder inom ett meshnätverk.
Mobila ad hoc-nätverk, MANET, beskriver två typer av routingalgoritmer, proactive och reactive. Proactivealgoritmer lagrar routingtabeller i varje nod med vägar till varje annan nod i nätverket. Detta gör det snabbt att hitta den bästa vägen mellan två noder men på bekostnad av nätverkstrafik. Reactivealgoritmer reducerar nätverkstrafik genom att en-dast lagra information om de noder som är direktkopplade till varje nod. För att hitta den bästa vägen mellan två noder måste vägen dock upptäckas varje gång den efterfrågas vilket resulterar i det tar längre tid att hitta vägen i jämförelse med proactivealgoritmer [35].
2.3.3 Piconet
Ett piconet, se figur 2, är ett ad hoc-nätverk av enheter som är ihopkopplade via Bluetooth-teknologi. Ett piconet kan bestå av två till åtta anslutna enheter. Varje enhet har en roll i nätverket, en är master och resten är slave-noder. All kommunikation mellan enheterna i ett piconet sker via masterenheter.
Piconets skapas automatiskt då två enheter är inom räckvidden för varandra och vill an-sluta. Ett piconet är dynamiskt och uppdateras automatiskt då nya enheter kommer inom räckvidden eller anslutna enheter lämnar nätverket [36].
Figur 2: Piconet av maxkapacitet, 8 enheter. Röd = master, Blå = slave.
2.3.4 Scatternet
Ett scatternet möjliggör kommunikation mellan flera piconetnätverk för att kunna hantera nätverk med fler än åtta noder. När två eller flera piconet överlappar varandra bildar de tillsammans ett scatternet (se figur 3). Rollerna i nätverken kan förändras vid initiering av scatternetformationen. En enhet som är slave i ett piconet kan även vara master i ett annat piconet och då bildas kopplingen mellan piconetnätverken. Kopplingen kan också bildas genom att en enhet är slave i två piconet [37]. En enhet som tillhör två piconets kallas ”interpiconet node” [35].
Bluetoothspecifikationen gör det möjligt att bilda scatternets men den specificerar inte någon standard för att göra det. Det finns flera tillvägagångssätt för att bilda Bluetooth scatternets vilket resulterar i flera olika topologier för samma uppsättning noder. Kotak m.fl. [17] förklarar att Scatternetproblemet kan representeras av scatternet formation, route discovery och mobility management.
Figur 3: Scatternet av tre piconet. Röd = master, Blå = slave, Blå/röd = slave/master.
2.3.5 BMN
Ett Bluetooth mesh network, BMN, är ett meshnätverk där enheterna är anslutna via Bluetooth. Bluetooth-teknologin gör det möjligt för mobilenheter att trådlöst kommunicera med varandra i ad hoc-nätverk kallat scatternet. Eftersom Bluetooth scatternets är en speciell typ av ad hoc-nätverk anser Kotak m.fl. [17] att det inte är lämpligt att applicera ett vanligt ad hoc-protokoll. Det behövs därför speciella algoritmer för att konstruera och rekonstruera ett Bluetooth scatternet.
2.4 Bluetooth-topologier
En topologi beskriver hur enheter inom ett nätverk är sammankopplade [38]. Topologier är konfigurationer som används för att förvalta ett nätverk [25].
2.4.1 Ring
I ringtopologin är varje nod i nätverket kopplad till två grannoder och kan endast kom-municera med dessa två. För att nå en annan nod i nätverket behöver noden fråga sina grannar som i sin tur frågar sin andra grannod och så vidare tills att den hittar destina-tionen.
När en ny nod vill bli en del av nätverket infogas den mellan två grannoder och dessa två blir då den nya nodens grannar. Grannarna uppdaterar också sin respektive grannlista med den nya noden.
När en nod lämnar nätverket meddelar den detta till sina grannoder, de två noder som är kopplade till den borttagna noden uppdaterar då sin respektive grannlista.
vänstra granne med information om destinationen. Om den vänstra grannen är destina-tionen skickas detta tillbaka till A, annars vidarebefordrar den ett token till sin vänstra granne och så vidare. Om det token som skickades av nod A går hela varvet runt och kommer tillbaka till nod A hittades inte destinationen [20].
2.4.2 Star
I startopologin agerar en nod master och resten är slave-noder. Slave-noder kan bara kom-municera direkt med master-noden som sedan kan vidarebefordra meddelanden till en annan slave-nod. I en startopologi kan obegränsat antal slave-noder vara kopplade till master-noden. Nätverket är även självständigt och kan inte kopplas ihop med en annan starformation. I detta nätverk finns problemet med en svag punkt som är master-noden och all trafik går igenom den noden [20].
2.4.3 Peer-to-peer
Peer-to-peertopologin är en ostrukturerad arkitektur som tillåter varje nod att ansluta till varje annan nod.
I en peer-to-peertopologi har noderna antingen rollen som master eller slave. En master-nod kan endast kommunicera med sina slave-noder och en slave-nod kan endast kommunicera med sin master-nod. Enligt Magalhães [20] påverkas inte nätverksformationen av rollerna utan de används i första hand för att testa olika kommunikationsscenarion.
När en ny nod vill bli en del av nätverket frågar den en nod inom räckvidd. Om den mottagande noden har mindre än fem anslutningar accepteras den nya noden och läggs till i adresslistan för mottagande nod. Om mottagande nod redan har fem anslutningar avslås begäran om att ansluta och den nya noden börjar om att leta anslutningsmöjligheter. Om den nya noden får slut på alternativ bildar den ett eget närverk med sig själv som master.
För att nätverket ska kunna hantera när en nod lämnar nätverket håller varje nod en lista med alla sina grannoder. Magalhães [20] menar att denna redundans av kopplingar utgör ett feltolerant nätverk där alla noder kan rekonstruera nätverket vid behov.
2.4.4 Scatternet
Scatternettopologin är baserad på Bluetooth scatternets som är ett nätverk av ihopkoppla-de piconets (se avsnitt 2.3.4). Nedan följer pseudokod av konstruktion och rekonstruktion av Scatternettopologin som beskrivet av Magalhães [20].
2.4.4.1 Konstruktion
Del 1 - Piconet
Den första noden som blir en del av nätverket får rollen som master.
När en nod, A, vill bli en del av nätverket sänder den ut en broadcast till alla noder inom räckvidd. Av de som svarade på broadcasten väljer A en godtycklig nod, B, att skicka JOIN-meddelande till med begäran att få bli en del av nätverket.
Om nod B är av rollen slave vidarebefordrar den begäran till sin master. Om nod B är av rollen master och har plats för fler noder, skickar den ett ACCEPT-meddelande tillbaka till nod A om att den fick bli en del av Bs piconet. Nod A får då rollen som slave och nod B lägger till A i sin lista med anslutningar.
Del 2 - Scatternet
Om nod B är av rollen master och inte har plats för fler noder, det vill säga B har redan sju slave-noder i sitt piconet, kontrollerar den sin lista med piconetgrannar och ser om det finns plats i någon av dem.
Om nod B har en granne med plats för en till nod, skickar B ett GO_JOIN-meddelande till nod A med adressen till master-noden, C, i det piconet som har plats. När A tar emot meddelandet skickar den ett JOIN-meddelande till nod C.
Om nod B inte har några grannar med plats för fler noder väljer den ut en godtycklig slave-nod, D, och begär att D skickar ett MAKE_GROUP_WITH-meddelande till nod A. När A tar emot meddelandet tilldelas den rollen master och skickar ett MAKE_GROUP-meddelande till nod D om att skapa en brygga. Nod D blir då slave till både A och B och skapar på så sätt kopplingen mellan två piconet. Nod A och B lägger till varandra i respektive lista med grannar.
2.4.4.2 Rekonstruktion
Varje master har kännedom om sina grannars slave-noder. Om en bridge-nod försvinner kommer master-noden upprätta en anslutning med en annan av grannens slave-noder.
När en master-nod lämnar nätverket får dess slave-noder leta efter nya piconets att ansluta sig till. Bridge-noder har redan en annan master och behöver därför inte söka efter nya piconets.
2.5 BLE Mesh
BLE Mesh består av tre lager: applikationslagret, mesh service-lagret och BLE framework-lagret.
När en enhet vill ansluta sig till nätverket annonserar enheten sin närvaro till en BMN-enhet inom räckvidd. Framework-lagret ger tillgång till möjligheten att skicka och ta emot
dessa annonseringar. En ansluten kanal kan etableras när enheten ansluter sig till nätverket och enheten kan därefter utbyta data.
Mesh service-lagret tar emot rådata från framework-lagret och tolkar informationen till olika kontroll- eller datameddelanden som sedan skickas till en mesh-nod. Mesh-noden agerar sedan enligt de mottagna meddelanden.
Datameddelanden som skickas till mesh-noden som slutdestination, skickas vidare till ap-plikationslagret som då kan utföra beskrivna operationer.
För konstruktion och underhåll av nätverket används en Directed Acyclic Graph (DAG).
Vid konstruktion utses en enhet till rot-nod. När en enhet vill ansluta skickas annonse-ringen i form av ett DAG information solicitation-message (DIS). När en Bluetoothenhet mottar ett DIS svarar den med ett DAG information object (DIO) innehållande sin rank. Den nya enheten väntar och samlar på sig flera DIO-meddelanden. Enheten med lägst rank blir den nya enhetens parent-nod.
Om avståndet är långt mellan roten och dess child-noder försämras energieffektiviteten. Författarnas förslag till att lösa problemet är en viktbalanseringsteknik. När en enhet vill skicka ett meddelande försöker den skicka till nästa enhet i routingtabellen. Om desti-nationen inte är tillgänglig vidarebefordras meddelandet via en alternativ väg. Om även den alternativa vägen är otillgänglig vidarebefordras meddelandet till enhetens parent-nod.
Nätverket är beroende av sin rotenhet. Det är därför viktigt att det utses en alterna-tiv rot-nod. Ifall rot-noden lämnar nätverket går den alternaalterna-tiva rot-noden in och blir den nya rot-enheten [18, 19].
2.6 Efficient Bluetooth topology construction protocol
EBTC-protokollet består av tre faser: konstruktion, routing och rekonstruktionshantering.
I konstruktionsfasen tilldelas noderna i nätverket olika roller. En supermaster-nod, ett antal master/slave-noder knutna till super master-noden, relänoder som tillhör två master-noder och knyter ihop dem, samt vanliga slave-noder tillhörande en master-nod.
Supermaster-noden håller information om vägarna till alla master-noder och deras re-spektive slave-noder i en routingtabell. Varje master-nod har också en routingtabell som innehåller information om varje relänod den är kopplad till samt vilken annan master-nod den relänoden har koppling till.
Routing-proceduren går till så att källan frågar sin master-nod om vägen till destinationen. Master-noden i sin tur frågar supermaster-noden om vilka master-noder som ligger på den kortaste vägen till destinationsnoden. Källan mottar informationen om vägen och skickar datan till den första master-noden i rutt-listan. Master-noden som mottar paketet hittar
nästa master-nod att skicka till och använder sin routingtabell för att hitta relänoden att skicka paketet igenom. Paketet skickas vidare tills det når slutdestinationen. Den funna vägen cachas i käll-noden.
Rekonstruktionsfasen sker då en nod ansluts eller försvinner från nätverket. Nodernas rol-ler kan då ändras beroende på situationen och routingtabelrol-ler uppdateras. Cachade vägar som innehåller rörda noder tas bort [17].
2.7 NS-3
NS-3 är en diskret nätverkssimulator som används inom nätverksforskning [21]. NS-3 ger forskare ett betydande stöd vid simulering av TCP-, routing- och multicastprotokoll över både trådbundna och trådlösa nätverk. NS-3 är inte en färdig produkt, utan snarare ett resultat av den pågående forskningen och utvecklingen inom näverkssimulering. Detta gör att användarna av NS-3 ansvarar för att verifiera sina simuleringar själva då det kan fö-rekomma programfel. Användarna ansvarar också för att nätverksmodellen implementeras på rätt sätt så att resultaten blir korrekta4 [40]. NS-3 är erkänt och väl använt inom forsk-ningsvärlden, det är open source och gratis att använda. NS-3 anses även vara effektivt, kraftfullt, snabbt och enkelt att använda.
4
3
Metod
Det finns två generellt accepterade metoder för datainsamling, kvantitativa och kvalitati-va [41]. Vi använder oss av båda dessa metoder i vår studie.
Kvalitativa metoder (se t.ex. [41, 42]) strävar efter att hitta, förstå och förklara ett fe-nomen, i motsats till den kvantitativa metoden som ämnar bekräfta eller falsifiera något som redan är uppmärksammat. Ett kvalitativt tillvägagångssätt kan förklara ett fenomen för ett specifikt fall och kan därmed inte i första hand generaliseras. Genom att man med kvalitativa metoder strävar att åstadkomma en helhetsbeskrivning av det undersökta tenderar denna typ av studier att omfatta mindre populationer än vid kvantitativa under-sökningar.
Kvantitativa metoder (se t.ex. [41, 43]) har som syfte att systematiskt samla in kvanti-fierbar data. Den data som samlas in kan sedan analyseras och användas för att bekräfta tidigare ställd hypotes. Kvantitativa metoder och därtill kopplade tekniker, såsom simu-leringar, är något av ett villkor vid studiet av stora populationer. Att använda sig av kvantitativa metoder förutsätter inte att forskaren själv deltar i det denne studerar, vilket uppfattats som en fördel av objektivitetsskäl.
3.1 Mixed methodology
Forskningsdesignen ”mixed method” använder sig av både kvantitativa och kvalitativa till-vägagångssätt i ett och samma forskningsprojekt för att samla in data [44].
En mixed methodology kan enligt Creswell [45] med fördel användas i följande fall: - ”The insufficient argument” Enbart en kvalitativ eller kvantitativ undersökning är
inte tillräcklig för att svara på frågan.
- ”The more-evidence-the-better” Att kombinera en kvalitativ och en kvantitativ un-dersökning ger mer bevis.
- ”Community of practice” En blandad metod kan vara att föredra i en vetenskaplig miljö.
Notera att vi behöver kvalitativ data för att modellera den praktiska miljö vi simulerar, och vi behöver kvantitativ data för att erhålla svar på vår studies frågeställningar.
Cameron [44] beskriver flera olika sätt att kombinera de båda metoderna inom mixed methodology. I vår studie använder vi oss av en sekventiell form där vi låter data från en metod ligga som grund för insamling av data från en annan metod [44].
Mer specifikt använder vi en sekventiell utforskande design (sequential exploratory de-sign) [45] där vi samlar in och analyserar kvalitativ data före vi samlar in och analyserar kvantitativ data, se figur 4. Den kvalitativa datainsamlingen ligger alltså till grund för den
kvantitativa. Inom sekventiell utforskande design prioriteras oftast den kvalitativa delen av metoden men även den kvantitativa delen kan prioriteras liksom i vårt fall [45].
Figur 4: Illustration av vår valda sekventiell utforskande desigmetod.
3.2 Källor
3.2.1 Databaser
Alla de databaser vi använder kommer ifrån listan med databaser som Malmö Högskola prenumererar på. Det är erkända databaser med vetenskapligt innehåll vilket hjälper oss att säkerställa kvaliteten på källorna.
IEEE - Tidskriftsartiklar, konferensbidrag och standards inom datavetenskap. ACM - Tidskriftsartiklar inom datavetenskap.
Springer - Tidskriftsartiklar och e-böcker
Google Scholar - Artiklar, avhandlingar, böcker, referat och domstolsyttranden från akademiska förlag, yrkessamfund, onlinearkiv, universitet och andra webbplatser. Nationalencyklopedin - Uppslagsverk och ordbok
Encyclopaedia Britannica - Uppslagsverk och ordbok
3.2.2 Sökord
Alla sökord vi använder är på engelska eftersom vi upplever att det lättast att hitta rele-vanta källor då de flesta forskningsartiklar publiceras på engelska.
Bluetooth
Bluetooth Mesh Network Ad hoc
Mobile Ad hoc NETwork MANET
Wireless Mesh Network Mesh
Simulation NS-3
Även kombinationer av sökorden ovan, så som Bluetooth + NS-3, hjälper till att filtrera sökresultat ytterligare och på så sätt få fram mer relevanta källor.
3.3 Vår kvalitativa metod
3.3.1 Val av metod
För att vi ska kunna genomföra våra simuleringar med realistiska värden och på så sätt få en verklighetsanknytning krävs det att vi tar reda på de parametrar vi behöver definiera. Vi måste också ta reda på vilken topologi vi ska använda samt hur vi ska kunna implementera den valda topologin i nätverkssimulatorn. För detta utför vi en fallstudie som innefattar en intervju samt en analys av tidigare relaterad forskning och implementationsspecifika detaljer.
3.3.2 Utförande av vår kvalitativa studie
3.3.2.1 Intervju
Vi gör vår studie på en referensmiljö, Stortorget i Malmö under en dag på Malmöfestivalen. Därför måste vi ta reda på hur stor area det är på Stortorget, vilket vi mäter med Google kartor som har ett verktyg för att mäta distans mellan punkter på en karta. Vi vill också ha svar på en del frågor som inte finns tillgängliga på Malmöfestivalens hemsida. Därför skickar vi ett mail till Pontus Friberg, ansvarig av uppbyggnad och site (el, logistik, bodar, tält m.m.) på Malmöfestivalen, och ber honom svara på följande frågor:
1. Vilken dag och tid vistas det flest människor på Stortorget under Malmöfestivalen? Den dag och tid då det är mest belastat på Stortorget:
2. Hur många människor vistas där då?
3. Hur många använder sig av mobila enheter för att kommunicera under den tiden? 4. Hur många upplever problem med att ringa, smsa, använda sociala medier/surfa? 5. Hur många procent av tiden ligger tillgängliga nätverk nere?
Allmänna frågor:
6. Hur många anslutningspunkter, Wi-Fi och 3G/4G finns det i närheten av Stortorget? 7. Hur många använder sig av Wi-Fi som tillhandahålls av Malmö stad?
8. Hur har ni tidigare löst problem med nätverksuppkoppling? 9. Hur har de tidigare lösningarna fungerat?
Svar på dessa frågor hjälper oss att definiera värde på vilket tidsspann det vistas som flest människor på Stortorget samt hur många som vistas där då. De hjälper också oss att få en förståelse för vår referensmiljö och bakgrunden till vårt scenario.
3.3.2.2 Studie av tidigare implementationer
För att ta reda på hur vi ska genomföra vår kvantitativa studie tittar vi på hur Bluetoothto-pologier tidigare implementerats i en nätverkssimulator och analyserar de konfigurationer som krävs för att simulera Bluetoothteknologin. Vi väljer också ut en topologi vi vill im-plementera och analyserar algoritmerna som är dokumenterade i syfte att efterlikna dem i vår implementation.
3.4 Vår kvantitativa studie
3.4.1 Val av metod
Eftersom vi inte har möjlighet att samla ihop 15 000 personer på Stortorget, förse dem med vars en mobil och testa nätverket i den faktiska miljön väljer vi att göra en simulering av scenariot. Vi samlar in stora mängder data på ett systematiskt sätt och analyserar en sammanställning av datan. Därför är en kvantitativ metod ett självklart val för oss.
3.4.2 Utförande av vår kvantitativa studie
Vi använder oss av simulering för att få fram kvantitativa resultat från våra experiment. Vi väljer att implementera metoden ”diskret simulering” vilket är en tekniskt lagd veten-skaplig metod i vilken möjliga händelser simuleras i ett datorprogram [46]. Vi utför ett antal simuleringar med systematiskt varierande parametrar för att få fram resultat. För att göra simuleringarna likt verkligheten används slumpmässiga element i modellen, i vårt fall låter vi noderna kopplas upp och ned till nodnätverket enligt ett slumptal.
Simulering definieras som en forskningsteknik som reproducerar faktiska händelser i en testmiljö. Detta tillåter forskare att utföra ”dry lab”-expreriment utan att behöva använda dyra resurser eller speciell utrustning. Simulering är även tidseffektivt då händelseförlopp som tar flera dagar eller år kan simulerats på minuter. Det kan även ge en god överblick över komplexa processer då simuleringar endast tar hänsyn till de faktorer som påverkar resultatet [47].
Simulering har visat sig vara mer effektivt i jämförelse med ett experiment i den rikti-ga världen då det skulle krävas storskalirikti-ga, tidskrävande och kostsamma experiment för att få fram realistiska resultat. Simulering tillåter oss att återskapa scenariot utan att be-höva ta hänsyn till en mängd människor, plats och tid. Simuleringen eliminerar även en stor del störningar vilket underlättar vår process att få fram vetenskaplig data [48]. De olika faktorerna vi kan mäta i vår testmiljö är:
- Antal noder som går ner när en central nod blir bortkopplad
- Antal rekonstruktionspaket som skickas när en central nod blir bortkopplad - Tiden det tar att skicka/ta emot meddelanden inom nätverket
- Hur många paket som inte kommer fram - Antal mellannoder för att ta emot ett paket - Tid det tar att rekonstruera nätverket
- Overhead på meddelanden vid rekonstruktion av nätverket
Eftersom vi fokuserar på att underhålla ett storskaligt och dynamiskt Bluetooth meshnät-verk väljer vi att endast mäta de faktorer som vi antar vara kritiska vid rekonstruktion av nätverket5.
Vi mäter tiden det tar att rekonstruera nätverket eftersom vi fokuserar på ett dynamiskt nätverk där noder frekvent tillkommer, förflyttas och försvinner, vilket innebär att nätver-ket frekvent behöver rekonstrueras och därför anser vi att detta är viktigt att mäta. Vi mäter antal noder som blir påverkade vid rekonstruktion eftersom det påverkar återhämt-ningsförmågan. Vi mäter även antal skickade rekonstruktionspaket vid rekonstruktion av nätverket, detta eftersom att det krävs ett stort antal meddelanden vid rekonstruktion av nätverket och Bluetooth tillåter endast en hastighet på 25 Mbps vilket sätter en gräns på hur lång tid ett meddelande tar att leverera mellan två noder.
5
Notera att vi tvingas göra ett antagande på grund av att det så vitt vi vet inte finns några tidiga-re studier som formulerar kritiska egenskaper med avseende på tidiga-rekonstruktion av dynamiska Bluetooth meshnätverk.
4
Relaterad forskning
I en studie från 2012 presenterade Yu m.fl [12] en mesh topologi för Bluetooth scatter-net formation. Resultatet av deras simuleringar visar att deras Enhanced Bluetree effek-tivt förbättrade prestandan i avseende på piconeteffekeffek-tivtet, sökvägslängd och end-to-end-fördröjning. Detta resulterade i att den uppbyggda topologin gjorde nätverket mer pålitligt och genererade ett effektivt nätverk med lägre paketfördröjningstid än ett konventionellt Bluetree-nätverk.
I en uppsats från 2009 föreslår Al-Kassem m.fl. [13] en Bluetooth formation topologi som överväger en ojämn distribution av Bluetoothenheter, BlueHRT. De använder en ringto-pologi för område med hög noddensitet och förlänger nätverket med en trädtoringto-pologi till andra områden. Genom att kombinera dessa två topologier kunde Al-Kassem m.fl. utnyttja fördelarna och begränsa påverkan av nackdelarna hos respektive topologi.
”Self Organizing Wireless Mesh Network” av Raj m.fl [14] behandlar problemet med dyna-miska länkfel och hur autonoma rekonfigurationssystem kan lösa detta problemet i trådlösa meshnätverk.
I ”A Self-Routing Topology for Bluetooth Scatternets” föreslår Chung-Kuo m.fl. [15] två olika konstruktionsprotokoll för Bluetooth scatternet i olika scenarion. Dessa protokoll är självdirigerande med en strävan att hålla routing overhead till ett minimum.
Abdulaziz m.fl. [16] menar på att så länge det finns tillräckligt hög noddensitet så finns det en stor möjlighet att en nod är omgiven av ett stort antal andra noder att kunna skapa en koppling med och på så vis skapa ett nodnätverk som fungerar som en ad hoc superdator. De presenterar även en work-stealing-algoritm vars syfte är att distribuera arbetsuppgifter på ett effektivt sätt genom Bluetoothnätverk.
4.1 Efficient Bluetooth topology construction protocol
Ett förslag på en lösning av scatternetproblemet är Efficient Bluetooth Topology Construc-tion Protocol av Kotak m.fl. [17] som bygger på en hierarkisk topologi där olika noder i nätverket har olika roller.
Se avsnitt 2.6 för en mer detaljerad beskrivning av EBTCP.
På grund av att routing-tabellerna endast ligger i supermaster- och master-noder sker all routing genom förfrågan- och svarmetoden. Detta medför enligt Kotak m.fl. [20] en reducerad fördröjning av ruttsökning samt minskat antal kontrollpaket som måste skickat i jämförelse med tidigare lösningar.
Vi anser att detta är en intressant lösning men inte aktuell för oss eftersom vi har en väldigt dynamiskt nätverk och därför är det inte bra för nätverket att bero på en supermaster-nod.
4.2 BLE Mesh
I en demonstration presenterar Bonggon m.fl. [18, 19] ett mesh-nätverk som använder Blu-etooth Low Energy(BLE) för att koppla ihop mobila enheter. De föreslår tekniker för att optimera kommunikationen i mesh-nätverket genom viktbalansering. Syftet är att demon-strera en routing-arkitektur och en viktbalanseringsalgoritm genom en prototyp.
Se avsnitt 2.5 för en mer detaljerad beskrivning av BLE Mesh.
Bonggon m.fl. [18, 19] redovisar en lösning på problemet med en rotenhet genom att in-troducera en alternativ rot. De visar att systemet är skalbart för ett stort antal statiska och mobila enheter. Vi anser inte att detta är tillräckligt relevant för vår dynamiska miljö eftersom det finns risk att rot-noden ofta behöver bytas och det gör att en stor del av nätverket behöver rekonstrueras kontinuerligt.
4.3 Simulation of Algorithms for Mobile Ad-Hoc Networks
Magalhães [20] undersöker i sin uppsats begränsningar och fördelar hos de nutida trådlö-sa kommunikationsteknologierna; Wi-Fi, Wi-Fi Direct, TDLS och Bluetooth. Han lägger extra vikt på hur nätverken beter sig med större mängder noder. Han utför simuleringar av ringtopologin, startopologin, peer-to-peertopologin och scatternettopologin. Se avsnitt 2.4 för mer detaljerade beskrivningar av dessa topologier. Den referensmiljön som används är ett stadium för sportevenemang. Anledningen till valet av denna miljö är att den an-tas vara relativt statisk eftersom besökare ofan-tast sitter på sin plats under hela evenemanget.
Vi väljer att lägga störst vikt vid denna sistnämnda forskning då den publicerades 2015. Uppsatsen är djupgående och objektiv samt förklarar olika topologier på ett för oss imple-menterbart sätt, d v s med hög detaljnivå och figurer som översiktligt förklarar nyckela-spekterna i topologierna.
4.3.1 Ring
Enligt Magalhães [20] är ringtopologin inte skalbar för nätverk med fler än 64 noder och är därför inte relevant för vår forskning. Ringtopologin utnyttjar inte heller Bluetooth-teknologins potential genom att endast tillåta två kopplade noder.
4.3.2 Star
Magalhães [20] nämner att det är svårt att lösa problemet med master-noden på ett effektivt sätt och väljer därför att inte implementera en lösning utan antar att master-noden förblir statisk och uppkopplad. Detta är för oss ingen realistiskt antagande och därför känns inte star relevant för vår forskning. Star-topologion följer inte heller de regler som finns för Bluetooth-teknologin eftersom den tillåter ett obegränsat antal anslutna enheter.
4.3.3 Peer-to-peer
Magalhães [20] anser att peer-to-peer är ett väldigt grundläggande och snabbt lättvikts-protokoll på grund av det godtyckliga beteendet och avsaknad av struktur. Magalhães [20] kunde dock verifiera att densiteten i nätverket kunde bli låg i vissa delar av topologin. På grund av den låga densiteten anser vi inte detta vara relevant för vår forskning då vi vill utnyttja Bluetoothteknologin fullt ut och fylla piconet så gått det går för att få ett så komplett nätverk som möjligt med hög densitet.
4.4 Val av topologi
Vi väljer att implementera scatternettopologin som beskrivs av Magalhães [20] då han kommer fram till att det är den mest passande av de lösningarna han undersöker. Scat-ternettopologin är baserad på Bluetooth scatternets och är därför realistiskt möjligt att implementera med Bluetooth på tillgängliga smartphones och surfplattor. Även om Magal-hães [20] väljer en relativt statisk miljö för sina simuleringar beskrivs en rekonstruktions-algoritm som gör att vi anser den vara tillräckligt relevant att implementera i vårt mycket dynamiska scenario. Alla algoritmer som beskrivs är även bra dokumenterade och ger oss möjlighet att implementera dem i NS-3.
5
Vår fallstudie
5.1 Scenario - Malmöfestivalen
Malmöfestivalen är Skandinaviens största festival i stadsmiljö. Den besöks årligen av 1,5 miljoner personer av olika nationaliteter under de åtta dagarna festivalen pågår. Festival-området är koncentrerat till Malmö centrum med en stor scen på Stortorget där många människor är i rörelse [49].
På första fredagen och fredag samt lördag veckan efter då de största banden spelar på scenen på Stortorget mellan klockan 19.00 - 00.00 vistas det upp emot 15 000 människor på Stortorget, enligt Pontus Friberg som är ansvarig för Uppbyggnad och site (el, logistik, bodar, tält m.m.) på Malmöfestivalen (se appendix 1). Stortorget i Malmö är ungefär 140 x 130 meter till ytan [50], se figur 5.
Figur 5: Arean av Stortorget i Malmö, mätt med Google Maps avståndsmätningsverktyg.
Med tanke på att det är många människor ständigt i rörelse på en mindre plats blir fun-gerade kommunikationskanaler viktiga då det kan vara svårt att hålla reda på och hitta varandra i den tätbefolkade miljön. Det blir större påfrestningar för de trådlösa nätverken än en vanlig vecka med tanke på den stora mängden människor som besöker Malmöfes-tivalen. Dessa påfrestningar kan leda till att nätverken blir instabila och det finns även en risk att de blir otillgängliga. Friberg, se appendix 1, har ingen statistik på hur många som upplever problem med uppkopplingen på Malmöfestivalen men påstår att det fungerar bättre nu än för några år sedan.
BMN då miljön är mycket dynamisk vilket kräver att nätverket rekonstrueras och uppda-teras mer frekvent än i en mer statisk miljö.
5.2 Vår simuleringsmiljö och implementation
5.2.1 Val av simulator
Det finns flera olika nätverkssimulatorer, exempelvis NS-2, NS-3 OPNET och NetSim. Vi noterar att ingen av dessa för oss tillgängliga nätverkssimulatorerna har implementerat Bluetooth (IEEE 802.15) specifikationen.
Det finns dock tillägg till NS-2 för att simulera Bluetooth. Modulen UCBT är en open-source Bluetoothsimulator utvecklad vid University of Cincinnati [51]. UCBT implemente-rar dock bara Bluetooth 1.1 och eftersom den nuvarande Bluetooth versionen är 4.2 anser vi att UCBT är utdaterat och inte relevant för vår forskning.
På grund av de begränsningar som finns tittar vi på alternativa metoder. En framgångsrik studie av Magalhães [20] visar att det går att emulera Bluetooth genom att använda existe-rande protokoll i NS-3. Vi använder därför ett Wi-Fi interface i ad-hoc mode enligt 802.11g specifikationen och modifierar det med Bluetooth begränsningar för antal anslutningar, rol-ler och radiodistans. Vi initierar kommunikationshastigeten till 24 Mbps, signalstyrkan till -45 dBm och räckvidden till 10 meter. Vi väljer kommunikationshastigheten 24 Mbps ef-tersom Bluetooth 4.2 tillåter hastigheter upp till 24 Mbps [57], signalstyrkan sätter vi till -45 dBm eftersom vi följer tidigare NS-3-implementationer som har använt den signalstyr-kan. Vi väljer räckvidden 10 meter eftersom Bluetooth har en räckvidd på cirka 10 meter. Vi adderar även extra variabler för att kunna tilldela noder olika roller samt listor för olika anslutningar för varje nod. Dessa anslutningar begränsar vi till max sju per nod enligt reglerna för ett Bluetooth piconet.
Vi utför därför våra simuleringar i Network Simulator 3 (NS-3) installerat i Linuxmiljö (Ubuntu 14.04). Vi skriver algoritmerna i C++ och använder de bibliotek som finns för NS-3. Vi använder terminalen i Linux för att exekvera simuleringarna i NS-3. Netanimmo-dulen6 används för att visualisera nätverket efter simulering.
Vi följer Magalhães [20] dokumentationen av algoritmerna för scatternettopologin och im-plementerar dem. Notera dock att i de fall då dokumentationen har varit bristfällig på detaljnivå tvingas vi göra vissa egna antaganden.
Vi följer NS-3s detaljerade installationsguide för att installera NS-3 [52].
6
5.2.2 Initiering av nätverket
5.2.2.1 Skapa noder
För att simulera ett nätverk måste vi generera noder som i vårt fall representerar mobila enheter så som mobiltelefoner. Vi skapar noder med hjälp av NS3::NodeContainer och initierar den med antal noder nätverket ska bestå av.
5.2.2.2 Installera noder
När vi har en NodeContainer med noder måste vi specificera vilken kommunikationstek-nologi7 vi vill använda för kommunikation mellan enheterna. I vårt fall använder vi Wi-Fi
eftersom det inte finns någon Bluetoothmodul i NS-3. Vi sätter även attribut så som sig-nalstyrka, räckvidd och hastighet för att emulera Bluetoothteknologin genom Wi-Fi. Vi lägger till MAC-adresser på enheterna och sätter dem till ad hoc mode. Vi installerar sedan teknologin på våra enheter.
5.2.2.3 Implementera random walk
Vi anser att sättet människor går på är random och för att få en så verklighetstrogen rörelse som möjligt installerar vi NS3::2D random walk mobility model på varje nod för att modellera hur festivalbesökare rör sig på Stortorget. Vi definierar inom vilka gränser noderna ska kunna röra sig inom genom att sätta en MobilityModel med Bounds 140 x 130 meter.
5.2.2.4 Installera Internetprotokoll och tilldela IP-adresser
Sedan behöver vi sätta regler och tala om för noderna vilka protokoll de ska följa. Genom att installera Internetstacken på noderna kan de nu kommunicera via UDP. Vi antar att UDP är tillräckligt för vår simulering. Vi använder Ipv4AddessHelper för att tilldela IP-adresser till noderna. För att kunna hantera IP-IP-adresser för 15 000 anslutna enheter ändrar vi subnetmask till 255.255.192.0. Vi loopar därefter igenom alla 240 noder och genererar unika IP-adresser som de tilldelas. Vi initierar också noderna till att inte ha någon roll, varken master eller slave. Noderna börjar därefter skicka ut inquery-meddelanden för att konstruera nätverket.
7
Med kommunikationsteknologi menar vi tillgängliga teknologier inom NS-3 så som Wi-Fi och Ether-net [40].
5.2.3 Vår implementation av scatternettopologins algoritmer
5.2.3.1 Ny nod
När en ny nod vill bli en del av nätverket skickar den ut ett INQUERY-meddelande till al-la noder inom räckvidd. Den första noden som tar emot ett svar påbörjar en JOIN-process.
Om noden som svarar är en slave-nod skickar den tillbaka adressen till sin master. Den nya noden gör då en JOIN-förfrågan till master-noden och om den är inom räckvidd svarar den med ett ACCEPT-meddelande. Den nya noden får då rollen som slave och master-noden lägger till den i sin lista över anslutna slave-noder. Se figur 6.
Figur 6: En ny nod, A, skickar en JOIN-förfrågan till en slave, B, som ber den nya noden skicka en JOIN-förfrågan till dess master, C, istället. Grön = ny nod, Röd = master, Blå = slave.
Om noden som svarar är en master och inte är full, alltså inte redan har sju anslutna slave-noder, får den nya noden rollen som slave och master-noden lägger till den i sin lista över anslutna slave-noder. Se figur 7.
Figur 7: En ny nod, A, skickar en JOIN-förfrågan till en master, B, som har plats. Grön = ny nod, Röd = master, Blå = slave.
om den har någon granne i sin lista över grannar. Om den har en grannod skickar den tillbaka grannodens adress till den nya noden som vill göra en JOIN. Se figur 8.
Figur 8: En ny nod, A, skickar en JOIN-förfrågan till en full master, B, som ber den nya noden skicka en JOIN-förfrågan till Bs grannod med ledig plats, C, istället. Grön = ny nod, Röd = master, Blå = slave.
Om noden som svarar är en master och den inte har någon grannod väljer den ut en godtycklig nod i sin lista över slave-noder och ber den göra ett nytt piconet med den nya noden. Om slave-noden är inom räckvidd för den nya noden kommer den nya noden få rollen som master och lägger till den andra master-nodens slave-nod i sin lista över slave-noder. Den slave-noden blir en bridge-nod och gör den nya noden och den svarande master-noden till grannar. De lägger till varandra i sin respektive grannlista. Se figur 9.
Figur 9: En ny nod, A, skickar en JOIN-förfrågan till en full master, B, som ber en av sina slave-noder, C, att göra ett nytt piconet med A. Grön = ny nod, Röd = master, Blå = slave.
5.2.3.2 Slå ihop piconet
Två separata piconet kan inte kommunicera med varandra, det krävs ett scatternet. I vår implementation letar alla master-noder ständigt efter nya grannar för att försöka få ihop ett komplett nätverk med alla noder för att göra det möjligt för alla att kommunicera med varandra. För att slå ihop två piconets krävs det att de två master-noderna i respektive piconet delar på en slave-nod, en bridge-nod. När en master hittar en annan master och de redan inte är grannar påbörjar de processen att slås ihop med varandra.
En master som tar emot ett CHECK AREA-meddelande från en annan master kontrollerar om den har någon slave-nod att dela med sig av, den kollar även om det finns plats för en ny slave-nod i den andra masters piconet. När de kommer överens om vilken som ska dela sin nod och vilken som ska ta emot en ny nod skickar den master som ska dela sin slave-nod ett MAKE GROUP WITH-meddelande till den slave-noden och skickar med adressen till den andra master-noden. Slave-noden skickar därefter ett MAKE GROUP-meddelande till den andra masten och om de är inom räckvidd för varandra lägger master-noden till slave-noden i sin lista med slave-noder och slave-slave-noden bildar kopplingen mellan två piconet. De två master-noderna blir då grannar och lägger till varandra i respektive grannlista. Se figur 11.
Figur 10: Koppla ihop två masters, A och B, genom att låta dem dela på Bs slave, C. De två masters blir då grannar till varandra. Röd = master, Blå = slave.
5.2.3.3 Nod försvinner
För att kontrollera att noder fortfarandra är kvar i nätverket pingar alla noder sina kopp-lingar var tionde sekund. När en nod inte svarar inom 10 sekunder antas den vara borta. När en nod försvinner från nätverket måste nätverket rekonstrueras. Eftersom en bortta-gen nod inte länge är med i nätverket är det viktigt att se till att inga anslutna noder har länkar kvar till den borttagna noden.
Om den borttagna noden är en slave-nod och inte är en bridge-nod mellan två piconet, tar master-noden bort slaven från sin slavelist.
pi-conet tas den bort ur alla kopplade master-noderna slavelist. De master-noder som har grannar genom den borttagna slave-noden tar bort varandra ur sina respektive grannlistor eftersom de inte längre är ihopkopplade.
Om den borttagna noden är en master blir alla slave-noder som endast var kopplade till den master-noden utan roll och tar bort master-noden ur sin masterlista. De ansvarar se-dan själva för att skicka ut nya INQUERY-meddelande för att försöka hitta andra piconet att ansluta sig till. De slave-noder som var kopplade till den borttagna master-noden men som också är kopplade till en annan master-nod behåller sin roll som slave eftersom de tillhör minst en master till. De master-noder som hade den borttagna noden som granne tar bort den ur sina grannlistor.
5.2.3.4 Övergripande simuleringsflöde
5.2.3.5 Designproblem
Eftersom vi använder Wi-Fi för att emulera Bluetooth finns det inga inbyggda begräns-ningar för antal anslutna noder per master i NS-3. Det finns inte heller några inbyggda roller i noderna. Därför måste vi lägga till några variabler i klassen NS3::Node för att kun-na behandla noderkun-na som Bluetooth-noder. För att begränsa dem till max 7 anslutningar per master måste vi veta hur många och vilka slave-noder som är anslutna till en master. En master-nod har en lista med anslutna slave-noder och även grannoder, dessa sparas i vars en std::vector. Även slave-noder har en std::vector som fylls med master-noderna de är anslutna till. Varje nod har också två variabler för att definiera vilken roll den har, master eller slave. Vi använder två variabler för att en ny nod har ingen roll och är därför varken master eller slave.
För att få ut IP-adressen till en nod i NS-3 måste vi gå via en socket, den som tar emot ett meddelande kan alltså få ut IP-adressen till den noden som skickade meddelandet. För att underlätta i våra simuleringar sparar vi IP-adressen i en variabel i varje nod. Det gör det lättare för oss att felsöka och få en bild av nätverkets struktur efter körning. I mät-ningssyfte lägger vi även till en variabel som räknar antal skickade paket per nod.
Ett problem med algoritmen som vår studie bygger på är att de inte nämner något om timeout-problemet [29]. Vi implementerar därför en egen lösning på problemet genom att lägga till en timeout-lista i varje nod som sparas i en std::vector.
Ett annat problem vi ser är att Magalhães [20] inte nämner hur han hanterar eventuella cykler i nätverket eller hur de förhindras. För att förhindra cykler från att inträffa använder vi godtyckliga värden vid urvalsprocesser eftersom vi anser att det är en enkel lösning på problemet.
5.3 Genomförande och mätning av våra simuleringar
Nätverket konstrueras innan vi påbörjar våra mätningar för att utgå från ett så komplett nätverk som möjligt. För att få fram data som är relaterat till storleken på nätverket så utför vi simuleringarna i nodintervaller där vi börjar med 0 noder och fortsätter addera 20 noder per intervall upp till 240 noder i nätverket. Anledningen till att vi inte kan simulera fler noder än 240 är att datorn vi utför simuleringarna på inte är tillräckligt stark för att hantera mer än 240 noder som utför Scatternet-algoritmerna.
Vi utför varje simulering i 100 sekunder. För att tillåta nätverket att konstrueras och hinna bli så verklighetstroget som möjligt låter vi simuleringen köra i 50 sekunder innan vi mäter rekonstruktionstiden, antal påverkade slave-noder och antal skickade rekonstruktionsrelate-rade paket vid rekonstruktionen. Efter 50 sekunder provocerar vi en rekonstruktion genom att ta bort den mest centrala noden med rollen master. Vi låter master-noden vi tagit bort ha en downtime på 10 sekunder innan den återansluter som en ny nod. Anledningen till att vi tar bort en master är för att de är mest kritiska i nätverket då de binder ihop kopplingar med flera slave-noder. Anledningen till att vi tar den mest uppkopplade noden är för att få fram värstafallsscenariot.
Alla noderna i simuleringarna rör sig slumpmässigt inom en area på 130 x 140 meter. Alla noderna har en räckvidd på 10 meter. Notera att med hänsyn till godtyckligheten i algoritmerna så utför vi varje simulering fem gånger och tar fram ett medelvärde av dessa resultat för att verifiera att mätdatan är pålitlig.
För att verifiera att vi implementerat scatternettopologin korrekt använder vi oss av NetA-nim för att visualisera nätverket vid en given tidspunkt i simuleringen. NetANetA-nim låter oss även se hur paket skickas mellan noderna vilket vi sedan analyserar för att säkerställa att våra algoritmer är korrekta. Vi använder även loggar där alla noder och deras kopplingar skrivs ut. I dessa loggarna kan vi se om relationerna är korrekta vid olika tidspunkter i simuleringen.
Funktionen KillMostConnectedNode, se algoritm 1, körs 50 sekunder in i simuleringen. Först hämtar funktionen den mest uppkopplade master-noden, vid fall om fler än en väljs en godtyckligt ut. Vi tar sedan bort varje slave-nod i master-nodens slavelista och vi tar även bort master-noden i respektive slave-nods master-lista.
Om en slave-nod blir helt utan master blir den bortkopplad från nätverket eftersom kopp-lingen förloras på grund av att master-noden gick ner. Vi dokumenterar tiden för bort-kopplingen i terminalen samt hur många paket just den noden hade skickat när den gick ner. Vi kör även funktionen sendInq efter 0.5 sekunder som låter den bortkopplade noden försöka koppla upp sig mot nätverket igen. Vi kör även den rekursiva funktionen checkIf-BackInScatternet, se algoritm 2, tills dess att noden blir återkopplad till nätverket. När noden blir återkopplad dokumenterar vi tiden i nanosekunder samt antal paket som noden hunnit skicka innan den blev återkopplad. På så sätt kan vi få fram totala mängden paket och den totala tiden som krävdes för samtliga noder att bli återkopplade in i nätverket igen. Efter 10 sekunder återställer vi den bortplockade master-noden och låter den skicka ett INQUERY-meddelande då vi simulerar att master-noden gick ner i 10 sekunder.
forall the nodes do
if current node has more slaves than previous then set current node to most connected node; end
end
forall the slave nodes in the most connected node’s slavelist do
forall the current slave’s masters and current slave’s master’s neighbors do delete the current slave’s master from its master’s neighborlist;
delete the current slave’s master’s neighbor from its master’s neighborlist; end
delete the current slave’s master from its masterlist; if the current slave has no more masters then
set slave to lost node;
schedule INQUERY-message to be sent in 0.5 seconds;
schedule CHECK-IF-BACK-IN-SCATTERNET-function immediately; end
end
Algorithm 1: KillMostConnectedNode
Funktionen CheckIfBackInScatternet, se algoritm 2, som tillåter oss att få ut tiden det tog för just denna nod att återansluta sig samt hur många paket den skickade innan den blev återansluten.
if the lost node has one or more masters then print current time;
print number of packets sent; else
schedule CHECK-IF-BACK-IN-SCATTERNET-function after 0.2 seconds end
Algorithm 2: CheckIfBackInScatternet
5.3.1 Presentation av data
Efter att varje simulering har körts så hämtar vi loggen från terminalen i Linux. Sedan räknar vi den totala mängden paket som behövs för att nätverket ska återhämta sig och den tid det tog för noderna att återanslutas till nätverket. Vi använder oss av Google Kalkylark för att rendera graferna.
5.4 Felkällor
Vi kan endast implementera algoritmerna till den detaljnivå som beskrivs i artikeln. Hur väl vi kan implementera algoritmerna beror på hur väl de är definierade.
Vi kan inte lita på att alla mätvärden är korrekta. Vi kan dock säkerställa att vi installerar och konfigurerar simuleringsmiljön på rätt sätt.
På grund av begränsningar i NS-3 och den hårdvara vi simulerar på kan vi endast kö-ra en simulering med 240 noder. Detta gör att vi inte kan gakö-rantekö-ra att få ut samma resultat som om vi hade kunnat simulera 15 000 noder.
6
Resultat
6.1 Scatternet healing time
Här visar vi tiden det tar för samtliga slave-noder att återanslutas till nätverket då deras master går ner i relation till antal noder som ingår i nätverket, se figur 12.
Figur 12: Medelvärde av scatternet healing time.
6.2 Antal rekonstruktionspaket skickade per nod tills nätverket åter-hämtat sig
Här visar vi antal skickade paket vid rekonstruktion i relation till antal noder som ingår i nätverket, se figur 13.
6.3 Antal bortkopplade slave-noder när den mest centrala master-noden går ner
Här visar vi antal bortkopplade slave-noder när deras master-nod går ner i relation till antal noder som ingår i nätverket, se figur 14.
Figur 14: Medelvärde av antal bortkopplade slave-noder när den mest centrala master-noden går ner.
6.4 Visuell simulering av rekonstruktion vid bortkopplad nod
Här visar vi den visuella representationen av simuleringen med hjälp av NetAnim som är en animator för NS-3. Se figur 15 - 17.
Vid 49 sekunder in i simuleringen är slave-noderna 12 och 19 kopplade med master-noden 4. Master-noder representeras av färgen grön och slave-noder har färgen blå, se figur 15.
Figur 15: Animation av simulering efter 49 sekunder. Grön = master, Blå = slave.
Slave-noderna 12 och 19 förlorar då kopplingen till nod 4 och därför också sin koppling till nätverket. De har inte heller någon roll längre vilket vi visar genom att ge dem färgen röd. De börjar därefter söka efter andra noder att ansluta sig till, se figur 16.
Figur 16: Animation av simulering efter 50 sekunder. Rosa = bortkopplad master, Röd = bortkopplad slave.
En tiondels sekund efter att nod 4 blir bortkopplad hittar nod 12 och 19 varandra genom att nod 19 skickade ett INQUERY-meddelande till nod 12. Nod 12 blir därför master och får nod 19 som slave. Se figur 17.
Figur 17: Animation av simulering efter 50.1 sekunder. Grön = master, Blå = slave, Rosa = bortkopplad master.
6.5 Visualisering av nätverkstopologi
Här redovisar vi en visuell representation av nätverkstopologin då vi kör en simulering med 20 noder. Se figur 18.
7
Analys och diskussion
7.1 Våra simuleringsresultat
7.1.1 Scatternet healing time
Vi kan se i figur 20 att tiden det tar för samtliga noder att återansluta efter att en central master-nod gått ner oftast är under 7500 millisekunder. Vi ser dock tre spikar i datan (markerat med röd cirkel) där tiden är högre eller mycket högre.
Vi antar att anledningen till ovannämnda dataspikar är att vi simulerar en mycket god-tycklig miljö, en tänkbar förklaring till detta är följande scenario: Den mest uppkopplade master-noden råkar befinna sig i utkanten av nätverket, och master-noden har en slave-nod som är längst ut i kanten av nätverket. När master-noden går ner blir slave-noden en lost node och går slumpmässigt runt i utkanten av nätverket under en längre tid innan noden hittar en nod inom räckvidd att koppla ihop med och därför bli återkopplad till nätverket.
Att dessa spikar uppkommer i fall med färre noder verkar bero på att noddensiteten i nätverket är lägre ju färre noder som rör sig inom arean och risken är då större att en lost node som försöker återansluta sig till nätverket inte hittar någon nod inom sin räckvidd. Eftersom noderna hela tiden rör på sig lyckas noden till slut möta någon inom räckvidd och återansluts då till nätverket.
Enligt figur 20 lyckats nätverket alltid återhämta sig trots längre tidsåtgång i vissa fall. Detta visar på att svaret på forskningsfråga F1 är: ja, vi kan underhålla ett storskaligt och dynamiskt Bluetooth meshnätverk vid förändring i topologin så som att en kritisk nod blir bortkopplad. Det är även intressant hur nätverket verkar återhämta sig mellan ett mer konsekvent tidsspann desto fler antal noder det finns i nätverket, detta kan bero på den högre noddensiteten.
Figur 19: Medelvärde av scatternet healing time i relation till antal noder. Dataspikarna markeras med röda cirklar.
7.1.2 Rekonstruktionspaket
Vi kan se ett samband mellan antal påverkade slave-noder då deras master-nod går ner och antal noder som ingår i nätverket, se figur 13. I våra simuleringar simulerar vi olika mängd noder på samma area. När vi simulerar många noder blir nätverkets noddensitet högre än när vi simulerar färre noder. Den ökade densiteten bidrar till att noder ligger närma-re varandra och chansen är då störnärma-re att en nod är inom räckvidd för ett flertal andra noder.
Vid rekonstruktion skickar en bortkopplad slave-nod ut INQUERY-meddelanden om att återanslutas till nätverket. Dessa meddelanden skickas som en broadcast och träffar då alla noder inom räckvidd. Detta medför en ökning av antal skickade rekonstruktionsmeddelan-den i ett nätverk med många noder i förhållande till ett nätverk med färre noder.
