IMPLEMENTATION OCH UTVÄRDERING AV KOMMUNIKATION MELLAN SMARTPHONE OCH IN FLIGHT ENTERTAINMENT SYSTEMS

Examensarbete, 15 hp

Högskoleingenjörsprogrammet i Elektronik och datorteknik, 180 hp

Bachelor thesis, 15 hp

Förord

Abstract

Sammanfattning

Innehåll

Användning av androidgränssnittet i de befintliga systemen ... 4

1

Introduktion

Projektet grundar sig i att undersöka, testa och utvärdera möjliga sätt att kommunicera mellan en PED (Personal Electronic Device) och en stolsskärmsenhet i ett IFE (In Flight Entertainment) system. I nuläget så finns möjligheten att använda PED i form av tillexempel en telefon där telefonen kan agera som en handkontroll för skärmen. Men hur står sig detta vid implementationer av protokoll på applikationsnivå som ställer högre krav på låglatent och dataintensiv kommunikation?

Det är således av intresse att undersöka vilka alternativ som finns för att kommunicera mellan de två enheterna, samt utvärdera hur dessa olika alternativ lämpar sig för mer datatunga och/eller låglatenta tillämpningar. Både ur ett rent informationstekniskt perspektiv samt baserat på hur redan befintliga mjukvarusystem kan integrera och hantera kommunikation via dessa. Är det möjligt, finns det några begränsningar, och hur skulle en implementation av detta kunna utformas?

Frågeställning

• Vilka former av kommunikation finns tillgänglig i de befintliga systemen som kan användas för att koppla samman en smartphoneapplikation med en applikation på underhållningssystemet?

• Hur skiljer sig de olika kommunikationsalternativen åt när det kommer till att integrera dem med de befintliga mjukvarusystem som används idag, d.v.s hur skulle applikationer kunna utformas för att kommunicera med varandra i dessa system?

• Hur skiljer sig de olika kommunikationsalternativen åt när det kommer till throughput och svarstider?

• Vilka begränsningar finns när det kommer till att utveckla applikationer/funktioner som ställer krav på låglatent, datatung kommunikation mellan enheter i dessa system?

Syfte

2

Mål

Det övergripande målet för projektet blir att sammanställa ett underlag som ger en överblick av vilka alternativ som finns för kommunikation mellan en smartphone applikation och en IFE applikation, samt hur de lämpar sig för implementationer som ställer krav på snabb och datatung kommunikation.

• Inledningsvis görs informationsinhämtning i form av litteratursökning och dialog med personer med relevant kunskap om området och/eller de befintliga systemen. • Två applikationer ska skapas som ska kunna kommunicera med varandra via de

tillgängliga kommunikationsalternativen. Den ena applikationen ska kunna köras på en smartphone och den andra på en stolsskärm. (Eventuellt så får båda köras på smartphones beroende på om stolsskärm finns tillgänglig att testa på.)

3

Krav nr Kravbeskrivning prioritet

1 Undersöka överföringsprotokoll (Vilka alternativ finns för det fysiska lagret). Ta fram ett underlag för vilka kommunikationsmetoder som går att använda för att kommunicera mellan en PED och en stolsskärm utifrån de befintliga systemen.

Avgränsningar:

Studien kommer att fokusera på de överföringsprotokoll som finns lättillgängliga i den hårdvara som finns, samt som har stöd i befintliga mjukvarugränssnitt. Det kan även inte garanteras att tillgång kommer att finnas till att testa implementationen på en faktisk stolsskärmsmodul och studien kan därför behöva baseras på en del antaganden när det kommer till prestanda och liknande.

1

2 Utforma och implementera ett protokoll på sessionsnivå som hanterar datatrafiken mellan enheterna.

Avgränsningar:

Implementationen kommer att i största möjliga utsträckning att använda befintliga gränssnitt, designer och ramverk för att implementera de delmoduler som utgör protokollstacken.

1

3 Undersök vilka svarstider testapplikationen kan uppnå

Avgränsningar:

Testerna kommer i största utsträckning att använda befintliga medel för att mäta och/eller estimera svarstiderna. Dessa metoder kommer att vara mjukvarubaserade och/eller teoretiska. Inga fysiska mätningar av överföringen i det fysiska lagret kommer att utföras.

1

4 Undersök vilken ’throughput’ som implementationen har per klient.

Avgränsningar:

Testerna kommer i största utsträckning att använda befintliga medel för att mäta och/eller estimera throughput. Dessa metoder kommer att vara mjukvarubaserade och/eller teoretiska. Inga fysiska mätningar av överföringen i det fysiska lagret kommer att utföras.

1

5 Undersök om exekveringsprestandan i ändutrustningen sätter större begränsningar på tillämpningen än själva överföringen. (Hantering av trafiken i ändutrustningen, t.ex: skärmarna och/eller telefon)

Avgränsningar:

Detta kan bli reducerat till teoretiskanalys och estimering beroende på om implementationen kan testas på de fysiska skärmarna eller inte.

2

6 Undersök hur svarstider och throughput påverkas när flera klienter används (T.ex om flera telefoner kopplas mot samma skärm).

Avgränsningar:

Detta kan bli reducerat till teoretiskanalys och estimering beroende på om implementationen kan testas på de fysiska skärmarna eller inte.

4

Teori

Att integrera PED med IFE, eller det som i bilindustrin kallas infotainment, har blivit allt mer vanligt. Det är en växande trend inom såväl flygindustrin som bilindustrin för att nämna några. Trots att dessa system ofta har många gemensamma nämnare så som t.ex att många system är androidbaserade eller har liknande funktioner, så är de ofta specialbyggda inbyggda system för olika bilmodeller eller IFE system [1]. Detta innebär att olika implementationer ställer olika krav på kommunikationen mellan PED’s och de stationära systemen. För utveckling mot infotainment i bilindustrin så finns ramverk som Android Auto och Apple CarPlay som har färdiga hjälpmedel för utveckling av funktioner mot just infotainment i bilar [2] [3].

Android

Android är ett operativsystem som är baserat på linuxkärnan och som marknadsförs av Google sedan år 2005. Android plattformen är open-source och därför fritt för vem som helst att använda [4]. Operativsystemets applikationer skrivs främst i programspråket Java som körs i en JVM (Java Virtual Machine) som bl.a modifierats av Google för att

optimiseras mot hårdvara i mobila enheter [5].

Användning av androidgränssnittet i de befintliga systemen

Utvecklingen mot IFE system som bedrivs av Tactel, bedrivs framförallt mot Panasonics IFE system. Panasonics IFE system är huvudsakligen Android baserade och använder Androids standard API som gränssnitt vid utveckling. Mer exakt så används Android 4.4 (API level 19) som högst i den utveckling som bedrivs av Tactel idag. Eventuella specialimplementationer som används för att passa speciella system eller funktioner, implementeras genom att åsidosätta standard API’ets implementationer men fortsatt behålla samma gränssnitt i största möjliga utsträckning.

5

ReactiveX

ReactiveX är ett API för asynkron programmering med observerbara dataströmmar. API’et finns för flertalet programmeringsspråk, bl.a Java och Kotlin vilket är två språk som används vid androidutveckling, detta ingår i ramverket RxAndroid. Androids designprinciper utgår från att huvudtråden i applikationen ska hantera så lite som möjligt utöver användargränssnittet. Detta innebär att en applikations olika delprocesser behöver exekveras i olika trådar. Detta ställer krav på att om data ska förmedlas mellan trådar så behöver detta i många tillämpningar ske asynkront. Något som ReactiveX tillhandahåller är att abstrahera mycket av de implementationsdetaljer som behöver bejakas vid asynkron och flertrådad programmering. Exempelvis så finns implementationer av schedulers som har färdiga funktioner för att skapa och hantera exekvering av kod i separata trådar. Men även implementationer för att förmedla data mellan dessa trådar. I exempelvis Kotlin så kan ett attribut som deklareras som en instans av klassen observable, definiera från vilken tråd denna ska vara observerbar ifrån. Detta innebär att attributet kan förmedla data från den tråd som den exekveras i, till en annan tråd. I den andra tråden så kan då ett observer attribut prenumerera på detta dataflöde (d.v.s prenumerera på observalbe attributet) för att asynkront ta emot och behandla data som avges från den andra tråden [6].

Bluetooth

Bluetooth utvecklades 1994 av LM Ericsson is Sverige och utvecklas sedan 1998 av Bluetooth Special Interest Group (SIG). Bluetooth är en teknologi för trådlös kommunikation över korta distanser [7]. Kommunikationen består av kortvågsradioöverföring och utnyttjar ”Frequency hopping” för att fördela kommunikationen över flertalet kanaler i sitt frekvensspektrum [8].

UDP

6 Till skillnad från andra transportprotokoll som exempelvis TCP så använder UDP inga handshakes eller Ack mekanismer i sin kommunikation. Detta gör att UDP ofta anses bättre lämpad för mer tidskritisk kommunikation som exempelvis streaming och onlinespel [10].

Latens

Latens (engelska: Latancy), responstid och svarstid är olika benämningar som i samband med datakommunikation ofta refererar till hur lång tid det tar att exempelvis skicka ett datapaket genom ett nätverk. Tiden mäts i regel i millisekunder och kan mätas på många olika sätt beroende på hur kommunikationen i nätverket är utformat.

RTT (Round Trip Time) eller Round Trip Latancy är ett mått på hur lång tid det tar för ett datapaket att skickas från avsändaren till mottagaren och sedan återvända till avsändaren, eller att avsändaren får en kvittens av mottagaren. För att mäta RTT så kan avsändaren upprepat klocka tidsskillnaden mellan när ett paket skickas till dess att det kvitteras, för att på så vis producera en sekvens av uppmätta svarstider som sedan kan analyseras [11].

Throughput

Throughput fungerar som ett mått på den volym av data som totalt kan överföras per tids enhet (ofta mätt i sekunder) i exempelvis ett nätverk. Detta mäter alltså all data som exempelvis skickas mellan en enhet till en annan.

Ett annat mått som används är vad som kallas goodput. Goodput är relaterat till throughput men mäter istället bara den ”nyttiga” eller ”användbara” data (även kallat ”user data”) som kan överföras per tidsenhet. Detta mått ignorerar alltså all data som överförs, som är relaterat till överföringsprotokoll, som handshakes, start/stopp sekvenser, kvittenser osv. Detta medför att goodput alltid är mindre än eller lika med överföringens throughput [12] [13] [14].

Standardavvikelse

7 För att beräkna standardavvikelsen för en datamängd bestående av sampels, så beräknas först datamängdens medelvärde. Därefter så summeras varje sampels avstånd från medelvärdet i kvadrat. Vilket sedan divideras på antalet sampels minus ett och standardavvikelsen är då roten ur det resulterande värdet [15] [16].

𝑥 = 𝑠𝑎𝑚𝑝𝑒𝑙 µ = 𝑚𝑒𝑑𝑒𝑙𝑣ä𝑟𝑑𝑒𝑡 𝑛 = 𝑎𝑛𝑡𝑎𝑙 𝑠𝑎𝑚𝑝𝑒𝑙𝑠 𝑆𝑡𝑎𝑛𝑑𝑎𝑟𝑑𝑎𝑣𝑣𝑖𝑘𝑒𝑙𝑠𝑒𝑛 =√(Ʃ |𝐱 − µ| 𝟐₎ 𝒏 − 𝟏

Standardavvikelsen kan användas för att få en mer noggrann jämförelse mellan olika datamängder. Två datamängder kan t.ex ha samma medelvärde men väldigt olika spridningar kring värdet.

Tidigare forskning

När det kommer till forskning gällande kommunikationen i dessa typer av system så har M Mourad m.fl utfört tester för samexistens mellan bluetooth och WLAN för infotainment i bilar. De skriver att både bluetooth och WLAN används för att sammankoppla t.ex mobiltelefoner med bilens datorsystem. De menar dock att det finns en betydande skillnad i throughput mellan de båda alternativen. Där throughput för WLAN är mycket större än för bluetooth. De menar även att WLAN tillskillnad från bluetooth är mycket bättre lämpat för att samexistera med andra kommunikationssystem när det kommer till interferens. Artikeln visar på hur WLAN kommunikationen inte påverkas nämnvärt av interferens i närvaron av bluetooth kommunkation. Medan bluetooth kommunikationen kan påverkas betydligt mer i närvaron av WLAN, vilket de menar är relaterat till WLAN’s högre uteffekt och throughput framförallt, vilket ockuperar en stor del av bluetooth kommunikationens kanaler i frekvensbandet. De påpekar dock att dessa två kommunikationsalternativ inte behöver utesluta varandra, utan kan samexistera genom att adressera just dessa problempunkter. WLAN kan dock bli påverkade av interferens från annan WLAN kommunikation. I artikeln så visar de på hur throughput kan minska med så mycket som hälften när två WLAN befinner sig i närheten av varandra [17]. Detta kan vara värt att ha i åtanke vid analysen av resultaten denna studie producerar.

8 spänning, ström, resistans och temperatur. Det inbyggda systemet kan mäta och spara data, samt skicka det sparade datat via bluetooth. En androidbaserad smartphone applikation har även skapats som via bluetooth kan skicka förfrågningar till det inbyggda systemet för att bl.a kunna visa datat som mäts i realtid på telefonen [18]. De motiverar användningen av bluetooth genom att hänvisa till tidigare studier som t.ex en studie av L Hua m.fl som studerat användningen av bluetooth för ett trådlöst övervaknings, diagnos och kalibrerings gränssnitt för ett kontrollsystem till bränsleceller i fordon. De föreslår användning av WiMedia Alliance bluetooth (Ultra Wide Band) för att få överföringshastigheter på upptill 480 Mbps, men återkopplar dock aldrig till exakt vilken bluetooth version som används i experimentet. De understryker dock vikten av felupptäkt och felhantering i systemet och har därför valt att använda XMODEM protokollet via bluetooth universal data interface och menar på att bluetooth är fullt dugligt till ändamålet [19].

C Khan m.fl har dock gjort en studie kring Wi-Fi Direct, där de bland annat listar applikationsområden för denna typ av kommunikation. De listar bl.a livestreaming, content delivery och online spel, samt påpekar att Wi-Fi direct har bra stöd i android. De menar även att denna teknik har fördelar gentemot andra typer av kommunikation där de nämner bluetooth som ett exempel. De trycker på att Wi-Fi direct är lättare att arbeta med när det kommer till att t.ex överföra filer mellan enheter, samt att prestandan är bättre när det kommer till Device Discovery delay [20].

Ms.Sayali Gupte m.fl skriver om ett förslag på en implementation för infotainment i bilar som kontrolleras trådlöst via Wi-Fi och bluetooth med en Android applikation. De ansluter enheterna genom att smartphonen fungerar som ett hotspot som bilenheten ansluter sig mot [21]. Detta kan vara en metod som kan användas i testimplementationen i denna studie.

9 kommunicerar mot en CSR1010 modul som agerar server. Syftet med artikeln är att fungera som en referensplattform för implementationer av trådlös kommunikation på Android baserade system vilket kan vara till nytta i detta projekt [22].

X Dayan m.fl har skrivit en artikel om implementationen av nätverksfunktionalitet för androidbaserade spel utvecklade i Unity3D. En metod som används i artikelns implementation är att den ena android enheten upprättar ett WLAN genom att göra sig själv till en access punkt och agera server, medan den andra enheten söker efter access punkten och ansluter sig som klient vilket liknar metoder som använts av b.la Gupte som nämnts ovan [23].

T Permana m.fl har däremot skrivit om kommunikation mellan enheter i en implementation för att testa noggrannheten av handrörelser i AR (Augmented Reality). Implementationen använder en android smartphone som HMD (Head Mounted Display) som tar emot data från andra enheter via en server som körs på en PC. I systemet så ansluter sig alla enheter som klienter mot servern via Wi-Fi, som förmedlar data till klienterna via UDP [24]. Detta kan även vara ett alternativ för implementationen i detta projekt.

10

Metod

Material

Hårdvara:

• Samsung Galaxy s10+, Androidversion 10 API level 29 • Samsung Galaxy s20, Androidversion 10 API level 29 • USB-C kablage

• IFE testrack, 4K UHD Altus Smart Monitor, Elite V3. • Acer Aspire 7 A717-71G-53HR, Windows 10.

Mjukvara:

• Android Studio 4.1.2 • Android 4.4 API level 19.

• ReactiveX, AndroidRx, KotlinRx, JavaRx

Applikation

Med hjälp av Android Studio skapas ett nytt projekt. Projektet använder Kotlin som programspråk och Android API nivå 19 för att detta är den högsta API nivå som används av Tactel vid utveckling mot IFE systemen vid tiden för detta projekt.

11 Figur 1 : Skärmdump av användargränssnittet

När användaren interagerat med någon av knapparna Host eller Connect så påbörjas processen av att upprätta kommunikationen mellan enheterna. För att hålla användaren uppdaterad om processen så ges användaren statusmeddelanden i form av s.k Toasts. Se fig

2.

12 För att skapa kommunikationsprotokollet så skapas en Kotlin klass ConnectionService.kt. Klassen hanterar allt som rör att skapa och upprätthålla kommunikationen mellan enheterna. Samt funktioner för att skicka och ta emot paket. Klassen agerar som ett interface mellan

MainActivity.kt och klasserna BluetoothService.kt och WiFiService.kt se fig 3.

Figur 3 : UML diagram över applikationen.

Knapparna i användargränssnittet har Button klassens setOnClickListener aktiva. När Host eller Connect knappen interageras med så läses Switch elementets läge in, för att avgöra om användaren valt Bluetooth eller Wi-Fi som kommunikationsalternativ. Det valda alternativet förmedlas till ConnectionService objektet och därefter så anropas objektets

hostConnection eller connectToDevice funktion beroende på vilken av knapparna som

interagerats med.

ConnectionService initierar sedan uppkopplingen genom att hantera anrop mot det valda

13 funktionen i motsvarande service-klass. connectToDevice fungerar på samma sätt med undantaget att när det valda kommunikationsalternativet är Bluetooth, så startas en inskanning av tillgängliga Bluetooth enheter som hanteras i en receiver och när en enhet med ett förbestämt discovery name hittas så skickas denna med som parameter till

BluetoothService klassens connectToDevice funktion.

Både BluetoothService och WiFiService har observable attribut från ReactivX bibloteket som ConnectionService prenumererar på via observers. All eventuell data som avges från

BluetoothService eller WiFiService observables avges i sin tur från ConnectionService egna

observable attribut messageObservable vilket innebär att MainActivity enbart behöver prenumerera på denna för att få all data oberoende av vilken kommunikationstyp som valts.

Se fig 4.

Figur 4 : Illustration av informationsflödet mellan trådarna.

Implementationen av bluetooth består av en klass BluetoothService som har ett antal metoder.

hostConnection metoden skapar en ny tråd som exekverar metoden acceptConnection. som

14 hos den lyssnande enhetens SDP. Om den mottagna förfrågan kan accepteras utan problem så instancieras en Bluetoothsocket och serversocketen kan stängas. Denna Bluetoothsocket kan sedan användas i samma tråd för att i en loop pollat lyssna efter inkommande data via bluetoothsocketens inputstream. Eventuell data som inkommer sparas efter att ett start tecken mottagits och hålls i en buffer till dess att ett stopp tecken mottagits.

För att kommunicera datat från inputstream tillbaka till huvudtråden så parsas paketet och avges via observable attributet btMsgObserver som är observerbar från huvudtråden.

Dessa metoder exekverar som nämnt i en egen tråd i enlighet med Android dokumentationens uppmaningar till att i så stor utsträckning som möjligt avlasta huvudtråden (mainThread), som per default hanterar applikationens UI (user interface) element som annars skulle vara oresponsiva under exekveringen av dessa metoder.

Write funktionen tar emot data som en ByteArray och lägger till ett start och stopptecken till meddelandet innan det skickas iväg. Detta görs för att kunna skicka dynamiskt långa meddelanden som lätt går att parsa för mottagaren.

Implementationen av Wi-Fi består av en klass WiFiService.kt som likt BluetoothService.kt har en metod hostConnection. Metoden skapar en ny tråd som exekverar metoden

acceptConnection som öppnar en UDP socket och lyssnar pollat efter input. När det första

paketet inkommer via socketen så utläses paketets avsändare och en uppkoppling upprättas. Därefter så anropas metoden manageMyConnectedSocket som pollat lyssnar efter input. Om input inkommer så avges det inkomna datat via klassens observable attribut som kan observeras från huvudtråden.

Klassens connectToDevice funktion gör försök att ansluta mot en UDP socket på en hårdkodad IP-adress.

15

Tester

Testerna som utförs för UDP kommer att ansluta enheterna via Wi-Fi där Acer Aspire 7 laptoppen kommer att agera Access Point när telefonerna används som testenheter. När IFE-skärmarna används som testenheter så kommer anslutningen att ske via trådburen förbindelse. Detta är p.g.a att de IFE-skärmar som finns tillgängliga att köra testerna på, i detta fall inte har någon trådlös uppkoppling som telefonerna kan ansluta via. Detta medför att testerna som utförs på IFE-skärmarna kommer att utföras genom att låta

skärmarna ansluta till varandra. Under testet så kommer den ena skärmen att agera telefon (PED) och den andra att agera host (IFE-skärm).

Responstid (Latancy)

Testet av responstider är utformat för att testa round trip latancy. För att starta testet så väljs först anslutningstypen, d.v.s Bluetooth eller UDP, via användargränssnittet. Därefter så kan enheterna anslutas mot varandra. Detta görs genom att först klicka på Host knappen i användargränssnittet på den ena enheten och sedan klicka på Connect knappen i användargränssnittet på den andra enheten. När enheterna upprättat en uppkoppling så startas testet automatiskt.

För att mäta responstiderna så tar klient-enheten först ett timestamp (mätt i millisekunder).

Därefter så konstrueras ett meddelande bestående av en floatarray med tre element som agerar utfyllnadsdata, samt den tagna timestampen. Detta meddelande skickas sedan via den skapade ConnectionService klassens write funktion som hanterar att överföra meddelandet till host-enheten via den valda anslutningstypen.

När host-enheten mottar det skickade meddelandet så parsas innehållet i meddelandet och ett Ack meddelande skickas sedan tillbaka till klient-enheten. Ack meddelandet består av strängen ”Ack” och den timestamp som det mottagna meddelandet innehöll.

16 När 1000 värden har lagts till i listan så sparas listans element i en txt fil på klient-enhetens lokala lagringsenhet och kan sedan hämtas till en PC via Android Studios Device File

Explorer. Varje test utförs fem gånger för att få fem separata mätserier att jämföra.

Anledningen till att meddelandet parsas och att den timestamp som meddelandet innehåller skickas med i Ack meddelandet, är UDP protokollets opålitlighet. Att UDP protokollet inte garanterar att paketen levereras kan hanteras med en sliding window princip som skickar ett nytt paket om inget Ack paket mottages inom en viss utsatt tid. Men problemet som motiverar att timestampen skickas med i Ack paketet är att UDP inte garanterar att paketen anländer i ordning. Därför anses det opålitligt att mäta tiden från det senast skickade paketet till tiden då det senast mottagna Ack meddelandet mottas. Därför så inkluderas timestampen från när paketet skickas, i själva paketet för att på så vis kunna mäta tidsskillnaden oavsett om paketet kommer i oordning [10].

Detta bidrar dock troligen till en viss fördröjning som påverkar den resulterande svarstiden. Samma metod används även vid mätningen för bluetooth som dock inte har samma typer av begränsningar. Detta görs för att eventuella fördröjningar som introduceras av denna metod som relaterar till exekveringstid ska vara så lika som möjligt mellan mätningarna som utförs med bluetooth och det mätningar som utförs med UDP.

Throughput (Goodput)

Testet av throughput är utformat för att testa goodput. För att starta testet så väljs först anslutningstypen, d.v.s Bluetooth eller Wi-Fi, via användargränssnittet. Därefter så kan enheterna anslutas mot varandra. Detta görs genom att först klicka på Host knappen i användargränssnittet på den ena enheten och sedan klicka på Connect knappen i användargränssnittet på den andra enheten. När enheterna upprättat en uppkoppling så startar testet automatiskt.

17 När host-enheten mottar startmeddelandet, så sparas en timestamp (mätt i millisekunder). Sedan så lagras alla inkommande meddelanden (eventuella delpaket) fram till och med att meddelandet innehållande stoppsekvensen mottages. När stoppmeddelandet mottagits så tas en ny timestamp och överföringens goodput beräknas med följande formel:

𝐵𝑖𝑡𝑎𝑟

𝑠 =

𝑀𝑜𝑡𝑡𝑎𝑔𝑛𝑎𝐵𝑦𝑡𝑒𝑠 ∗ 8 (𝑠𝑡𝑜𝑝𝑝𝑡𝑖𝑑 − 𝑠𝑡𝑎𝑟𝑡𝑡𝑖𝑑₁₀₀₀ )

Det beräknade värdet sparas och processen upprepas. När tio goodput värden kunnat beräknas och sparats, så skrivs de sparade värdenen till en fil på host-enhetens lokala lagringsenhet. Denna fil kan sedan hämtas till en PC via Android Studios Device File Explorer. Varje test utförs fem gånger för att få fem separata mätserier att jämföra.

Att tidsmätningens start och stopp styrs av start och stopp sekvenser som skickas av klienten medför onekligen en viss fördröjning. Detta anses dock vara något som kan accepteras då goodput är ett mått på den ”nyttiga” data som i praktiken kan överföras under en viss tid. Goodput kommer alltid att vara mindre än eller lika med den totala throughput som kommunikationen har. Samt att då tidsmätningen startar först efter att startsekvensen mottagits innebär att den största fördröjningen som introduceras av detta är överföringen av de tre tecknen som utgör stoppsekvensen: ”£££”.

Demo

18

Resultat

Kommunikationsalternativ

IFE systemen från Panasonic har kommunikationsmöjligheter mot PED via Wi-Fi och vissa enhetsmodeller har integrerade Bluetooth sensorer som kan användas för kommunikation. Kommunikationen över Wi-Fi sker via en accesspunkt som trådlöst kan kommunicera med PED enheten och på ett godtyckligt sätt kommunicera med IFE enheten. Exempelvis via fiber eller tp-kabel.

Mjukvaruintegration för kommunikation via Bluetooth och Wi-Fi kan utgå ifrån att Androids standardgränssnitt kan användas. Eventuella specialimplementationer åtsidosätter standardgränssnittets implementation och ersätter den med den egna implementationen, utan att ändra gränssnittet i största möjliga utsträckning. Det är även möjligt att använda externa bibliotek som ReactiveX. ReactiveX abstraherar implementationsdetaljer relaterat till hanteringen av den flertrådade kodexekveringen, samt hanteringen av dataförmedling mellan trådarna.

Istället för två separata applikationer så har en applikation skapats. Applikationen kan köras både på IFE-skärmarna och på Androidtelefonerna. Beroende på hur användaren interagerar med applikationen så kan enheten som kör applikationen anta olika roller i sessionen (host eller klient).

Tester

Responstid

UDP (Wi-Fi/trådbunden)

Testet av responstid med UDP som kommunikationsalternativ gav följande resultat. Testen som använt IFE-skärmarna som testenheter gav upphov till graferna som kan ses i fig 5 &

19 Figur 5 : Altus Smart Monitor (Klient), Elite V3 (Host). Medelsvarstid (blå), Standardavvikelse (Orange).

Figur 6 : Elite V3 (Klient), Altus Smart Monitor (Host). Medelsvarstid (blå), Standardavvikelse (Orange).

20 Figur 7 : s10+ (Klient), s20 (Host). Medelsvarstid (blå), Standardavvikelse (Orange).

Figur 8 : s20 (Klient), s10+ (Host). Medelsvarstid (blå), Standardavvikelse (Orange).

Bluetooth

21 Figur 9 : Bluetooth, s10+ (Klient), s20 (Host). Medelsvarstid (blå), Standardavvikelse (Orange).

Figur 10 : Bluetooth, s20 (Klient), s10+ (Host). Medelsvarstid (blå), Standardavvikelse (Orange).

Throughput

Wi-Fi/Trådbunden

22 Figur 11 : Altus Smart Monitor (Klient), Elite V3 (Host). Medel-goodput (blå), Standardavvikelse (Orange).

Figur 12 : Elite V3 (Klient), Altus Smart Monitor (Host). Medel-goodput (blå), Standardavvikelse (Orange).

Testet av throughput (goodput) som använt UDP som kommunikationsalternativ och som använt smarttelefonerna som testenheter, gav upphov till graferna som kan ses i fig 13 &

23 Figur 13 : s20 (Klient), s10+ (Host). Medel-goodput (blå), Standardavvikelse (Orange).

Figur 14 : s10+ (Klient), s20 (Host). Medel-goodput (blå), Standardavvikelse (Orange).

Bluetooth

Testet av throughput (goodput) som använt Bluetooth som kommunikationsalternativ och som använt smarttelefonerna som testenheter gav upphov till graferna som kan ses i fig 15

24 Figur 15 :Bluetooth, s20 (Klient), s10+ (Host). Medel-goodput (blå), Standardavvikelse (Orange).

25

Diskussion

Responstid

Efter avslutad testning så kan vissa trender utläsas från det resulterande datat. Testresultaten från responstidstesten vid användning av UDP visar på hur standardavvikelsen är väldigt låg. Detta när testet körs med de två IFE-skärmarna som test-enheter jämfört med när de två mobiltelefonerna används som test-enheter. Detta även i de fall då Elite V3 skärmen och de båda telefonerna agerar host-enheter i separata tester och ger upphov till samma medelsvarstider inom ett spann på ca +-10 ms. Som visat i fig 5, 7 & 8 så är standardavvikelsen i testerna som inkluderar telefonerna (fig 7 & 8) i spannet ca 70-100 ms medan standardavvikelsen i testerna som utförs på IFE skärmarna som högst uppmätts till 7,36 ms.

Detta antas bero på att testerna som utförts med telefonerna kommunicerat via radiolänk medan testerna som utförts med IFE-skärmarna kommunicerat via trådad förbindelse. Vilket då antas vara den största orsaken till skillnaden i standardavvikelse mellan mätningarna. Detta motiveras med att det enda som skiljer testerna åt är att testerna körs på annan hårdvara och använder ett annat fysiskt överföringsmedium. Men då mätningarna som utförts med Elite V3 skärmen givit upphov till mätresultat som visar att medelssvarstiden ligger inom ca ±10 ms jämfört med mätningarna som utförts med telefonerna, så antas det fysiska mediet vara den starkast bidragande faktorn till skillnaden i standardavvikelsen.

En tydlig skillnad även kan observeras när det kommer till medelsvarstiderna som uppmätts med Altus Smart Monitor skärmen som host-enhet, jämfört med övriga tester. Som visat i

fig 5 så var den högsta uppmätta medelsvarstiden 16.57 ms. Då den enda kända skillnaden

i testet med Altus Smart Monitor skärmen som host och testet med Elite V3 skärmen som host, är hårdvaran i skärmenheten i sig, så antas exekveringsprestandan i detta fall utgöra en betydande skillnad för medelsvarstiderna.

Svarstidstesterna som använt bluetooth har som nämnt enbart utförts med telefonerna som testenheter. Mätningarna visar att medelsvarstiderna och standardavvikelserna, oavsett vilken av telefonerna som agerar host- och klient-enhet, ligger inom ett spann mellan ca 75-90 ms för medelsvarstiderna och mellan ca 33-41 ms för standardavvikelserna. Som visat i

26 Jämfört med svarstidstesterna som utfördes med telefonerna som testenheter där UDP över Wi-Fi användes för överföringen. Så går det att utläsa att medelsvarstiden var konsekvent lägre för UDP över Wi-Fi än för Bluetooth. Medelsvarstiden vid test med bluetooth för överföring var som sagt inom ett spann på ca 75-90 ms oberoende av vilken telefon som agerade host/klient. Medan medelsvarstiden för test med UDP över Wi-Fi låg vid mätningarna inom ett spann på ca 58-75 ms, även där oberoende av vilken telefon som agerade host/klient.

Vid jämförelse av standardavvikelserna för mätningarna som utförts med telefonerna som testenheter, så går det dock att utläsa hur standardavvikelsen konsekvent varit större för testerna som använt UDP över Wi-Fi jämfört med Bluetooth. Anledningen till detta är inte helt fastslaget, men vid närmare granskning av mätdatat se bilaga 1 så går det att utläsa hur någorlunda periodiska spikar uppstår i svarstiderna som uppmätts vid användning av UDP över Wi-Fi. Detta skulle kunna bero på att testerna utförts med telefoner som testenheter. I och med detta så skulle eventuella bakgrundsprocesser i telefonen kunna ge upphov till dessa spikar. Detta känns troligt p.g.a det periodiska upprepandet av spikarna.

27

Throughput

Mätningarna av throughput inriktade sig som nämnt på att mäta och beräkna kommunikationens goodput. Mätningarna som utförts med IFE-skärmarna som testenheter visar på stora skillnader i goodput beroende på vilken av skärmarna som agerar host-enhet. Mätningarna som utfördes med Elite V3 skärmen som host-enhet, resulterade i en medelgoodput inom ett spann på ca 398 – 409 kbit/s. Detta kan då ställas i relation till mätningarna som utfördes med Altus Smart Monitor skärmen som host-enhet som resulterade i en medelgoodput inom ett spann på ca 886 - 898 kbit/s se fig 11 & 12, vilket är mer än dubbelt så högt.

Precis som med testet av responstiderna så är den enda kända skillnaden mellan de båda testfallen, vilken av skärmarna som agerat host-enhet. Det antas därför utifrån resultaten, att exekveringsprestandan är den största bidragande faktorn till skillnaden i mätresultat mellan de båda testfallen. Detta kan vara påverkat av testets utformning eller implementationen av applikationens kommunikationsgränssnitt. Men då samma stora skillnad i mätresultat kunde observeras även vid mätning av responstiderna (som hanterar mycket mindre data) och responstiderna blev dubbelt så låga när Altus Smart Monitor skärmen agerade host som när den agerade klient. Så tyder det ändå på att hårdvaruprestandan spelar en stor roll för resultatet.

Mätningarna av goodput som utfördes med telefonerna som testenheter visar att vid användningen av UDP över Wi-Fi så uppmäts medelgoodput inom ett spann på ca 2.68 – 3.0 mbit/s oberoende av vilken av telefonerna som agerar host se fig 13 & 14. I kontrast till resultaten från testkörningen som använde bluetooth, som när s10+ agerade host-enhet hade en medelgoodput inom ett spann på ca 137 – 179 kbit/s och när s20 agerade host hade en medelgoodput inom spannet 153 – 229 kbit/s.

28 Visserligen så har inga tester kunnat utföras med IFE-skärmarna som testenheter där bluetooth används för överföringen. Däremot, utifrån de resultat som kunnat sammanställas från de utförda testerna så anses det rimligt att anta, att ett test som skulle använda bluetooth för överföringen och som körs med IFE-skärmarna som testenheter, skulle ge upphov till ett liknande resultat när det kommer till förhållandet mellan den goodput som kan uppnås när den aktuella enheten använder UDP kontra bluetooth för överföringen, som det förhållande som uppmätts mellan UDP och bluetooth i de tester som utförts i denna studie. Detta antagande baseras på de resultat som kan redovisas från testerna som utförts med telefonerna som testenheter. Detta är dock föremål för fortsatt forskning.

Applikationens utformning

När det kommer till att utforma applikationer för att kommunicera mellan en PED och en IFE-skärm så kan det som sagt utgås ifrån att Androids standard API kan användas i detta fall. Androids API har mycket god dokumentation och eftersom Android är ett populärt operativsystem så finns mycket annan öppen dokumentation från andra utvecklare, vilket underlättar utvecklingen.

ReactiveX kunde som sagt användas i implementationen vilket underlättade mycket när det kom till att hantera överföringen av data mellan bakgrundstrådarna och huvudtråden, samt hanteringen av att exekvera utvald kod i separata trådar. I början av projektet så användes exempel från Android för att hantera dessa implementationsdetaljer. Detta inkluderade att deklarera klasser som runnable objekt som tog handlers via konstruktorn, som användes för att göra callbacks till huvudtråden för att förmedla datat mellan trådarna. Det finns god dokumentation för detta. Men då ReactiveX abstraherade mycket av de implementationsdetaljer som detta ställer krav på så får ReactiveX anses vara att föredra ur ett enkelhetsperspektiv.

Att implementera ConnectionService klassen som ett gränssnitt mot underliggande service klasser gav en bra abstraktion som innebär att fler olika kommunikationsalternativ skulle kunna integreras, samt att de redan befintliga implementationerna skulle kunna ändras utan att behöva ändra något i huvudprogrammet.

29

BluetoothService), så får dessa anses fungera bra och kunde implementeras relativt enkelt

med hjälp av den dokumentation som funnits tillgänglig via Androids API. Vid en eventuell framtida implementation av detta för kommunikation mellan PED och IFE-system, så bör klasserna ses över för allmänna optimeringsmöjligheter. Detta eftersom testerna tycks visa på att hårdvaruprestandan hos testenheten tycks ha spelat en relativt stor roll för testresultatet.

Något som skulle kunna optimera koden för sändningen och mottagningen av data i de båda service klasserna är att refaktorisera de delar av koden som hanterar strängar. I den befintliga implementationen så används standardklassen String för detta och hanteringen av strängarna sker via klassens medföljande strängoperationer. Detta skulle kunna bytas ut mot att använda StringBuilder klassen vars operationer, bl.a att bifoga strängar, har lägre komplexitet än motsvarande operation för String klassen.

En faktisk implementation för utgivning skulle även behöva implementera extra steg i processen för att ansluta enheterna mot varandra. I testimplementationen så ansluter enheterna till varandra genom hårdkodade IP-adresser eller ansluter automatiskt till en bluetooth-enhet vars discovery name stämmer överens med ett förbestämt namn. Detta bör kunna implementeras genom att host-enheten genererar en typ av pinkod som visas på skärmen och som användaren (klienten) kan använda istället för de hårdkodade värdena för att ansluta mot host-enheten. För bluetooth så kan detta ersätta det discovery name som används för att hitta ”rätt” enhet att ansluta mot. För anslutning via Wi-Fi så bör klienten kunna göra en broadcast innehållande den angivna pinkoden och en server eller alla IFE-enheter som lyssnar efter anslutningsförfrågningar, kan ignorera alla anslutningsförfrågningar som inte innehåller den genererade pinkoden som är aktuell för den aktuella enheten.

Utvärdering av testerna

30 kommunikation sker via trådlösöverföring. Detta tillsammans med att eventuella tester av PED enheters kommunikation sker via samma accesspunkt skulle kunna ge en mer exakt jämförelse.

Slutsatser

Systemen kan kommunicera med PED över wifi via en accesspunkt. Kommunikationskedjan kan vara olika för olika implementationer. Vissa IFE-enheter har inbyggda bluetooth sensorer som skulle kunna användas för kommunikation. Detta är dock olika eftersom de flesta IFE-skärmarna är specialbyggda vilket kan innebära att funktionaliteten skiljer sig.

Att integrera kommunikation mellan PED och IFE i befintliga mjukvarusystem är relativt enkelt när det kommer till hanteringen av att skicka och ta emot data via en viss kommunikationstyp. Detta eftersom Android har ett bra, färdigt, väldokumenterat gränssnitt för detta som abstraherar mycket av jobbet. Problemet som kan uppstå är just att etablera uppkopplingen, då detta beror på hur kommunikationskedjan ser ut i det specifika flygplanet. Detta bör dock inte vara allt för svårt att anpassa, så länge som kännedom om kommunikationskedjan finns tillgänglig.

Wi-Fi implementationen har i testerna visat sig ha en konsekvent högre throughput än Bluetooth implementationen. Bluetooth är också enligt mätningarna konsekvent sämre när det kommer till svarstider, med skillnaden att marginalen inte är lika stor när det kommer till skillnaden i svarstider. Mätningarna visar även att bluetooth jämfört med Wi-Fi testerna, konsekvent har en lägre standardavvikelse när det kommer till svarstiderna.

Utifrån detta så får det anses vara bättre lämpat att använda Wi-Fi vid utveckling av applikationer som kräver högre throughput. Men i fall där svarstid är av större vikt än hög throughput så är bluetooth inte att utesluta som alternativ.

32

Referenser

[1] J. Choi, “Agent-Based In-Vehicle Infotainment Services in Internet-of-Things Environments,” Electronics (Basel), vol. 9, no. 8, p. 1288–, Aug. 2020, doi: 10.3390/electronics9081288.

[2] https://www.android.com/auto/ - Hämtad: 2021-03-15 [3] https://www.apple.com/ios/carplay/ - Hämtad: 2021-03-15

[4] Gargenta, M., 2011. Learning android. " O'Reilly Media, Inc.".

[5] Jianye Liu and Jiankun Yu, “Research on Development of Android Applications,” in 2011 4th International Conference on Intelligent Networks and Intelligent Systems, 2011, pp. 69–72, doi: 10.1109/ICINIS.2011.40.

[6] Z. Jovanovic, R. Bacevic, R. Markovic and S. Randjic, "Android application for observing data streams from built-in sensors using RxJava," 2015 23rd

Telecommunications Forum Telfor (TELFOR), Belgrade, Serbia, 2015, pp. 918-921, doi:

10.1109/TELFOR.2015.7377615.

[7] C. Bisdikian, "An overview of the Bluetooth wireless technology," in IEEE

Communications Magazine, vol. 39, no. 12, pp. 86-94, Dec. 2001, doi:

10.1109/35.968817.

[8] R. Challoo, A. Oladeinde, N. Yilmazer, S. Ozcelik, and L. Challoo, “An Overview and Assessment of Wireless Technologies and Co- existence of ZigBee, Bluetooth and Wi-Fi Devices,” Procedia computer science, vol. 12, pp. 386–391, 2012, doi:

10.1016/j.procs.2012.09.091.

[9] S. Thombre, "Modelling of UDP throughput," 2016 IEEE Region 10 Conference (TENCON), Singapore, 2016, pp. 482-487, doi: 10.1109/TENCON.2016.7848046.

[10] H. Lampesberger and H. Lampesberger, “Technologies for Web and cloud service interaction: a survey,” Service oriented computing and applications, vol. 10, no. 2, pp. 71– 110, 2016, doi: 10.1007/s11761-015-0174-1.

[11] P. Karn and C. Partridge, “Improving round-trip time estimates in reliable transport protocols,” ACM transactions on computer systems, vol. 9, no. 4, pp. 364–373, 1991, doi: 10.1145/118544.118549.

[12] S. Fortin-Parisi and B. Sericola, “A Markov model of TCP throughput, goodput and slow start,” Performance evaluation, vol. 58, no. 2, pp. 89–108, 2004, doi:

10.1016/j.peva.2004.07.016.

[13] W. Grote, A. Grote, and I. Delgado, “IEEE 802.11 goodput analysis for mixed real-time and data traffic for home networks,” Annales des télécommunications, vol. 63, no. 9, pp. 463–471, 2008, doi: 10.1007/s12243-008-0044-3.

[14] https://packetpushers.net/throughput-vs-goodput/ - Hämtad: 2021-02-18

[15] V. Grech, “WASP (Write a Scientific Paper) using Excel –5: Quartiles and standard deviation,” Early human development, vol. 118, pp. 56–60, 2018, doi:

33 [16] https://www.khanacademy.org/math/statistics-probability/summarizing-quantitative-data/variance-standard-deviation-population/a/calculating-standard-deviation-step-by-step

– Hämtad: 2021-02-19

[17] M. Mourad, “On the performance of WLAN and Bluetooth for in-car infotainment systems,” Vehicular Communications, vol. 10, pp. 1–12, Oct. 2017, doi:

10.1016/j.vehcom.2017.08.001.

[18] S. Darjat, “Utilization of bluetooth wireless for SOFC test rigs with android smartphone device,” in AIP conference proceedings, Apr. 2020, vol. 2217, no. 1, doi: 10.1063/5.0000916.

[19] L. Hua, “Bluetooth wireless monitoring, diagnosis and calibration interface for control system of fuel cell bus in Olympic demonstration,” Journal of power sources, vol. 186, no. 2, pp. 478–484, 2009, doi: 10.1016/j.jpowsour.2008.10.013.

[20] C. Khan, “Wi-Fi Direct Research ‐ Current Status and Future Perspectives,” Journal of network and computer applications, vol. 93, pp. 245–258, Sep. 2017, doi:

10.1016/j.jnca.2017.06.004.

[21] S. Gupte and A. R. Askhedkar, "An Innovative Wireless Design for a Car

Infotainment System," 2018 Second International Conference on Intelligent Computing

and Control Systems (ICICCS), Madurai, India, 2018, pp. 1751-1754, doi:

10.1109/ICCONS.2018.8663132.

[22] C. Hughes, “Bluetooth Low Energy for Use with MEMS Sensors,” ProQuest Dissertations Publishing, 2015.

[23] X. Dayan, “Development of Unity3D Network Functionality on Android,”

International Journal of Hybrid Information Technology, vol. 9, no. 2, pp. 359–370, Feb. 2016, doi: 10.14257/ijhit.2016.9.2.32.

[24] T. Permana, “The Connectivity Between Leap Motion And Android Smartphone For Augmented Reality (AR)-Based Gamelan,” Journal of Information Technology and Computer Science, vol. 3, no. 2, pp. 146–158, Nov. 2018, doi: 10.25126/jitecs.20183263.

34

Bilaga 1

Data från mätning av svarstid med Samsung s10+ som klient och Samsung s20 som host. Testet kördes med en Acer Aspire 7 A717-71G-53HR laptop som trådlös accesspunkt och kommunikationen använder UDP som transportprotokoll.