O GWARANTOWANEJ JAKOŚCI USŁUGI INTERNETU RZECZY ZINTEGROWANEJ Z SYSTEMEM WIDEOKONFERENCYJNYM 1

Transkrypt

1 STUDIA INFORMATICA 2017 Volume 38 Number 3 (132) Agnieszka CHODOREK Politechnika Świętokrzyska, Katedra Systemów Informatycznych Robert R. CHODOREK AGH Akademia Górniczo-Hutnicza, Katedra Telekomunikacji O GWARANTOWANEJ JAKOŚCI USŁUGI INTERNETU RZECZY ZINTEGROWANEJ Z SYSTEMEM WIDEOKONFERENCYJNYM 1 Streszczenie. Artykuł przedstawia analizę systemu Internetu Rzeczy zintegrowanego z systemem wideokonferencyjnym zbudowanym zgodnie z architekturą WebRTC. Dane aplikacji Internetu Rzeczy przesyłane są pomiędzy terminalami kanałem danych WebRTC, równocześnie z danymi wideokonferencji. Analiza uwzględnia poziomy QoS protokołu MQTT, liczbę aktywnych urządzeń Internetu Rzeczy oraz lokalizację terminali (pobliską i odległą). Słowa kluczowe: IoT, MQTT, QoS, WebRTC, wideokonferencja ON GUARANTEED QUALITY OF SERVICE OF AN INTERNET OF THINGS INTEGRATED WITH A VIDEOCONFERENCE Summary. In this paper, an analysis of Internet of Things (IoT) system, integrated with a videoconferencing system built according to the WebRTC architecture, is presented. Analysis covers Quality of Service (QoS) levels of the MQTT protocol, number of active IoT devices and location of a corresponding WebRTC terminal. Keywords: IoT, MQTT, QoS, videoconference, WebRTC 1. Wprowadzenie WebRTC (ang. Web Real-Time Communications) [1-3] to rozwijana od kilku lat, nowa architektura systemów telekonferencyjnych. Bazuje ona na języku opisu stron WWW 1 Prace prezentowane w niniejszym artykule były finansowane z funduszu prac statutowych KT AGH (nr umowy ).

2 168 A. Chodorek, R.R. Chodorek HTML5 i języku skryptowym JavaScript. Terminale WebRTC realizują w czasie rzeczywistym komunikację typu peer-to-peer. Pomiędzy terminalami można przesyłać strumień mediów (audio i wideo pochodzące z lokalnych źródeł mikrofonu, kamery internetowej) oraz dane. W tym celu wykorzystywane są dwa, osobne kanały transmisyjne. Pierwszy z nich, kanał mediów, do transmisji informacji multimedialnej w czasie rzeczywistym wykorzystuje protokół transportowy RTP. Drugi, kanał danych, przesyła dane niewymagające rygorów czasu rzeczywistego i korzysta z protokołu transportowego SCTP. WebRTC nie tworzy własnego, pełnego interfejsu użytkownika, lecz korzysta w tym celu z przeglądarki WWW. Internet Rzeczy (ang. Internet of Things, IoT) jest trzecim z kolei, obok przeglądarek WWW i platform ch, zastosowaniem WebRTC wymienionym na stronie głównej webrtc.org [4]. Możliwość integracji architektury WebRTC z systemami Internetu Rzeczy pozwala na stworzenie jednej, wspólnej platformy dla pracy grupowej, gdzie system konferencyjny będzie wspomagany przez podawane na bieżąco dane pomiarowe. Potencjalne zastosowania takiej platformy to telemedycyna czy diagnostyka techniczna. Integracja WebRTC i IoT może bazować na zastosowaniu w WebRTC protokołu sygnalizacyjnego MQTT (ang. MQ Telemetry Transport) [5] stosowanego w systemach IoT. Przykłady takich rozwiązań można spotkać, między innymi, w pracach [6] i [7]. Integracja może polegać również na przesyłaniu ruchu telemetrycznego, generowanego przez urządzenia Internetu Rzeczy, kanałem danych WebRTC. W pracy [8] podane zostały przykłady platform wykorzystujących WebRTC do współpracy człowieka z inteligentnym urządzeniem, jak również przykład telekonsultacji lekarskich, gdzie wywiad lekarski dokonywany jest za pomocą systemu konferencyjnego, przy jednoczesnym odbiorze informacji z sieci sensorów. Artykuł jest poświęcony gwarancjom jakościowym QoS (ang. Quality of Service) dla systemu Internetu Rzeczy współpracującego z systemem wideokonferencyjnym zgodnym z architekturą WebRTC. W rozdziale drugim omówione zostały poziomy QoS w protokole MQTT. W rozdziale trzecim zostało zaprezentowane środowisko badawcze, a w rozdziale czwartym wyniki badań. Rozdział piąty podsumowuje artykuł. 2. Poziomy QoS w protokole MQTT Protokół MQTT [5] przenosi dane aplikacji Internetu Rzeczy w swoich pakietach PUBLISH. Pakietom tym są udzielane gwarancje jakościowe na poziomach QoS 0, QoS 1 i QoS 2. Poziom QoS 0 nie daje żadnych gwarancji jakości usługi MQTT wysłany pakiet PUBLISH może dotrzeć do odbiorcy lub nie. Poziom QoS 1 daje gwarancję dotarcia do

3 O gwarantowanej jakości usługi Internetu Rzeczy 169 odbiorcy danych aplikacji przesyłanych w pakiecie PUBLISH, nie daje jednak gwarancji, że nie zostaną one zduplikowane. Poziom QoS 2 pozwala uniknąć zarówno strat pakietów PUBLISH, jak i ich duplikacji. Poziomy QoS 1 i 2 wykorzystują mechanizm pozytywnego potwierdzenia. W przypadku poziomu QoS 1 poprawny odbiór pakietu PUBLISH jest potwierdzany przez odbiornik pakietem PUBACK. Brak potwierdzenia PUBACK może spowodować retransmisję pakietu PUBLISH, co z kolei może doprowadzić do powielenia informacji przenoszonej w pakiecie PUBLISH, jeżeli brak potwierdzenia nie wynikał z utraty pakietu PUBLISH, lecz z utraty pakietu PUBACK. Aby uniknąć takich sytuacji, poziom QoS 2 wykorzystuje algorytm trójetapowego porozumienia. Poprawny odbiór pakietu PUBLISH potwierdzany jest przez odbiornik pakietem PUBREC. Poprawny odbiór pakietu PUBREC potwierdzany jest przez nadajnik pakietem PUBREL, a ten z kolei potwierdzany jest pakietem PUBCOMP. Nadajnik MQTT, poinformowany pakietem PUBREC, że pakiet PUBLISH dotarł do miejsca docelowego, wstrzymuje wysłanie duplikatów. Odbiornik zaś odrzuca jako duplikaty wszystkie pakiety PUBLISH, które odebrał przed odebraniem pakietu PUBREL. Nagłówek pakietu MQTT składa się z nagłówka stałego i nagłówka zmiennego (opcjonalnego). Pakiet PUBLISH przenosi informację o poziomie QoS w polu QoS level nagłówka stałego. W nagłówku zmiennym pakietu PUBLISH przenoszona jest informacja o numerze identyfikacyjnym pakietu (pole Packet Identifier). Numery identyfikacyjne nadawane są pakietom PUBLISH z ustawionym znacznikiem poziomu QoS 1 lub 2 oraz wszystkim pakietom potwierdzeń (PUBACK, PUBREC, PUBREL i PUBCOMP). Pakiety potwierdzeń muszą mieć tę samą wartość pola Packet Identifier co potwierdzany pakiet PUBLISH. Ponowne użycie tego samego identyfikatora Packet Identifier do identyfikacji innego pakietu jest możliwe dopiero po ukończeniu procesu potwierdzania. Czyli w przypadku poziomu QoS 1 po odebraniu pakietu PUBACK, a w przypadku poziomu QoS 2 po odebraniu pakietu PUBCOMP. 3. Środowisko do testów gwarancji jakościowych usługi IoT Badania gwarancji jakościowych usługi IoT zostały przeprowadzone w sieci o topologii pokazanej na rysunku 1. System konferencyjny (serwer WWW, mostek konferencyjny Kurento Media Server) oraz terminal posadowione zostały w sieci KT AGH, zbudowanej w technice Gigabit Ethernet. Drugi terminal,, jest podłączony do sieci telefonii komórkowej (standard LTE transmisji danych) i łączy się z mostkiem konferencyjnym za pośrednictwem Internetu.

4 170 A. Chodorek, R.R. Chodorek Broker IoT Mobilny terminal WebRTC Internet Urządzenia IoT Serwer WWW Kurento Media Server Sieć lokalna KT Broker IoT Stacjonarny terminal WebRTC Urządzenia IoT Rys. 1. Środowisko testowe (topologia fizyczna) Fig. 1. Test environment (physical topology) Transmisja w sieci KT AGH oraz pomiędzy terminalami odbywała się w obecności ruchu podkładowego (normalnego ruchu w sieci KT i w Internecie). Podczas testów uwzględniono dwie lokalizacje terminalu mobilnego: bliską (na terenie miasteczka akademickiego AGH) oraz odległą (w odległości około 150 km od terminalu stacjonarnego). Oprócz ruchu generowanego przez telekonferencję, w systemie generowany był również ruch pochodzący od urządzeń Internetu Rzeczy. Integracja z Internetem Rzeczy wymagała dodania do terminalu WebRTC brokera IoT. Broker został zaimplementowany w terminalu WebRTC z użyciem biblioteki mosca [9], uzupełnionej o nasze własne rozwiązania zawierające, między innymi, wsparcie dla wszystkich trzech poziomów QoS. Opracowany broker IoT ma dwa zadania. Pierwszym jest komunikacja bezpośrednia z urządzeniami IoT. Drugie zadanie to przetworzenie komunikatów MQTT i przekazanie ich do modułu obsługi danych techniki WebRTC. Komunikaty te przez zestawiony kanał danych WebRTC, obsługiwany przez protokół SCTP, trafiają do serwera Kurento. Z niego docierają do poszczególnych terminali, skąd następnie trafiają do tamtejszych brokerów, zintegrowanych z terminalem. Brokery w różnych terminalach WebRTC współpracują ze sobą, wykorzystując proste zdefiniowane przez nas komendy sterujące. Komendy te są zapisane w formacie JSON (JavaScript Object Notation) [10]. Opracowany przez nas sposób komunikacji urządzeń IoT jest przezroczysty i urządzenia IoT mogą komunikować się z odległymi urządzeniami bezpośrednio w ramach sesji wideokonferencyjnej. Sesja ta

5 O gwarantowanej jakości usługi Internetu Rzeczy 171 posiada standardowe dla WebRTC zabezpieczenia kryptograficzne, dzięki czemu dane wrażliwe z urządzeń IoT są chronione i zapewniana jest ich autoryzacja. Opracowany system został przebadany zarówno pod względem wydajnościowym, jak i funkcjonalnym. W trakcie badań wykorzystano generator ruchu MQTTBox [11] emulujący ruch pochodzący od urządzeń IoT. W trakcie testów funkcjonalnych rozwiązanie przetestowane zostało również z zastosowaniem fizycznych urządzeń IoT współpracujących z platformą Raspberry Pi i Intel Galileo. Były to m.in. czujniki temperatury, pulsu czy EKG. 4. Wyniki badań Wyniki badań gwarancji jakościowych usługi Internetu Rzeczy zostały zawarte w tabelach 1, 2 i 3 oraz na rysunkach 2 i 3. Badania zostały przeprowadzone dla trzech poziomów QoS protokołu MQTT (QoS 0, 1 i 2) oraz dla N aktywnych urządzeń Internetu Rzeczy, N = 1,..., 10. Ze względu na zastosowanie protokołu TCP straty pakietów MQTT były zerowe, niezależnie od ustawionego poziomu QoS i liczby aktywnych urządzeń IoT (tabela 1). Zaobserwowano natomiast relatywnie duże, bo sięgające 20% (tabela 2), straty pakietów TCP. Poziom QoS 0 charakteryzował się największymi retransmisjami pakietów TCP (tabela 1), również procentowymi (tabela 2). Dla N = 1,..., 8 udział retransmisji przekraczał 10%, dla większej liczby urządzeń spadając do około 8-9% (N = 9) i około 6-7% (N = 10). Spadek ten można tłumaczyć większą agresywnością dużego strumienia TCP. Poziom QoS 0 wyróżniał się również największą liczbą wysyłanych pakietów TCP (tabela 2), co znalazło swe odzwierciedlenie w przepływności TCP, obserwowanej dla QoS 0 (rys. 1 i 2). Może wydać się zaskakujące, że tej dużej liczbie pakietów TCP nie towarzyszy równie duża liczba pakietów PUBLISH (tabela 3) protokołu MQTT, przenoszonych wewnątrz pakietów TCP. Co więcej, liczba pakietów PUBLISH przesłanych podczas transmisji wielu strumieni nie jest prostą wielokrotnością liczby pakietów wysyłanych podczas transmisji jednego strumienia, a charakter narastania wskazuje, że nie wszystkie pakiety PUBLISH mogły zostać wysłane. Analiza przesyłanych pakietów TCP wykazała, że dla poziomu QoS 0 system transmisji wymuszał na TCP transmisję quasi-bezpołączeniową. Połączenia TCP nawiązywano na potrzeby przesyłania pojedynczego pakietu PUBLISH i natychmiast je rozwiązywano. Pomimo iż ilość przesłanych pakietów MQTT była najmniejsza (nie tylko ze względu na małą liczbę przesłanych pakietów PUBLISH, ale również ze względu na brak potwierdzeń), narzut pakietów przy nawiązywaniu i rozwiązywaniu połączenia sprawił, że poziom QoS 0 wygenerował największy ruch (w gruncie rzeczy niepotrzebnie).

6 Przepływność [kb/s] 172 A. Chodorek, R.R. Chodorek Tabela 1 Straty pakietów Systemy końcowe Poziom Liczba urządzeń IoT Nadajnik Odbiornik QoS Liczba utraconych wiadomości MQTT Liczba retransmisji TCP MQTT QoS=0 MQTT QoS=1 MQTT QoS= Czas [s] Rys. 2. Przepływność protokołu TCP przenoszącego pakiety MQTT (5 urządzeń IoT) Fig. 2. Throughput of the TCP protocol conveyed MQTT packets (5 IoT devices)

7 Przepływność [kb/s] O gwarantowanej jakości usługi Internetu Rzeczy 173 Tabela 2 Statystyki pakietów TCP Systemy końcowe Poziom Liczba urządzeń IoT Nadajnik Odbiornik QoS retransmisje % Liczba pakietów TCP MQTT QoS=0 MQTT QoS=1 MQTT QoS= Czas [s] Rys. 3. Przepływność protokołu TCP przenoszącego pakiety MQTT (10 urządzeń IoT) Fig. 3. Throughput of the TCP protocol conveyed MQTT packets (10 IoT devices)

8 174 A. Chodorek, R.R. Chodorek Tabela 3 Liczba wysłanych pakietów PUBLISH Systemy końcowe Poziom Liczba urządzeń IoT Nadajnik Odbiornik QoS W przypadku QoS 1 i 2 system już nie wymuszał rozwiązywania połączenia po każdym przesłanym pakiecie PUBLISH, co wyraźnie obniżyło liczbę wysyłanych pakietów TCP (tabela 2), a co za tym idzie, obniżyło i przepływność (rys. 2 i 3). Liczba pakietów PUBLISH (tabela 3), obserwowana podczas transmisji od wielu urządzeń, była wielokrotnością liczby pakietów wysyłanych podczas transmisji z jednego urządzenia (z dokładnością do dwóch pakietów). Liczba wysłanych pakietów potwierdzeń (PUBACK, PUBREC, PUBREL i PUBCOMP) dokładnie odpowiadała liczbie wysłanych pakietów PUBLISH. Dla QoS 1 liczba wysyłanych pakietów TCP jest 2-2,5 razy większa od liczby pakietów PUBLISH. Należy jednak pamiętać, że na każdy wysłany pakiet PUBLISH przypadał jeden wysłany pakiet PUBACK. Dla QoS 2, gdzie na każdy wysłany PUBLISH przypadają trzy potwierdzenia, liczba pakietów TCP jest o 20 do 40 procent niższa niż w przypadku QoS 1. Najprawdopodobniej jest to efekt użycia przez TCP opóźnionych potwierdzeń i lepszego wykorzystania tego mechanizmu przy QoS 2. Podobne efekty dla QoS 0, 1 i 2 uzyskano z zastosowaniem fizycznych urządzeń IoT. Całkowita przepływność protokołu TCP, zobrazowana na rysunku 2 (N = 5), wynosiła: 12,8 kb/s dla QoS 0, 4,2 kb/s dla QoS 1 i 2,6 kb/s dla QoS 2. Natomiast całkowita przepływność protokołu TCP, zobrazowana na rysunku 3 (N = 10), wynosiła: 27,7 kb/s dla QoS 0, 11,6 kb/s dla QoS 1 oraz 7,3 kb/s dla QoS 2. Jak można się było spodziewać, lokalizacja terminalu mobilnego, odległa) zupełnie nie wpłynęła na liczbę generowanych pakietów PUBLISH (tab. 3), widać natomiast różnice w liczbie pakietów TCP (tabela 2). Różnice te są niewielkie (pojedyncze pakiety) i wynikają raczej z lokalnych warunków pracy sieci. Jedynie w przypadku retransmisji TCP (tabela 1) da

9 O gwarantowanej jakości usługi Internetu Rzeczy 175 się zauważyć tendencję do wzrostu liczby retransmitowanych pakietów po zmianie lokalizacji z bliskiej na odległą, ale tylko dla dużej liczby aktywnych urządzeń Internetu Rzeczy. 5. Zakończenie W artykule zaprezentowane zostały badania QoS usługi Internetu Rzeczy zintegrowanej z systemem wideokonferencyjnym. Badania pokazały, że w przypadku współczesnych systemów IoT, korzystających w warstwie transportowej z protokołu TCP (bezpośrednio lub przez interfejs WebSockets), większe znaczenie ma ustawienie parametrów protokołu TCP przenoszącego wiadomości MQTT niż same mechanizmy zapewnienia jakości MQTT. BIBLIOGRAFIA 1. Loreto S., Romano S.P.: Real-Time Communication with WebRTC: Peer-to-Peer in the Browser. Wyd. O'Reilly Media, Inc., Grigorik I.: High Performance Browser Networking. Wyd. O'Reilly Media, Chodorek A., Chodorek R.R.: Model warstwowy ustanawiania sesji WebRTC. Studia Informatica, Wydawnictwo Politechniki Śląskiej, vol. 37, no. 2, Gliwice WebRTC Home WebRTC. dostęp: marzec MQTT Version os.html, dostęp: marzec Bharath R., Vaish P., Rajalakshmi P.: Implementation of Diagnostically Driven Compression Algorithms via WebRTC for IoT Enabled Tele-sonography. IEEE EMBS Conference on Biomedical Engineering and Sciences (IECBES), Kuala Lumpur 2016, s Sandholm T., Magnusson B., Johnsson B.A.: An On-Demand WebRTC and IoT Device Tunneling Service for Hospitals. International Conference on Future Internet of Things and Cloud, Barcelona 2014, s Krawiec P., Sosnowski M., Batalla J.M., Mavromoustakis C. X., Mastorakis G., Pallis E.: Survey on Technologies for Enabling Real-Time Communication in the Web of Things. Praca zbiorowa pod red. Batalla J.M., Mastorakis G., Mavromoustakis C.X., i Pallis E.: Beyond the Internet of Things, Springer, dostęp: marzec 2017.

10 176 A. Chodorek, R.R. Chodorek 10. Bray T. (red.): The JavaScript Object Notation (JSON) Data Interchange Format. RFC 7159, dostęp: marzec Abstract WebRTC (Web Real-Time Communications) [1-3] is a new teleconference architecture, based on the HTML5 and JavaScript. Integration of the WebRTC architecture with the Internet of Things (IoT) systems allows to build one, common platform for collaborative work, where a conferencing system is supported by up-to-date measurement data. The potential usage of such platform is telemedicine or technical diagnostics. Basic signaling protocol for the IoT is the MQTT (MQ Telemetry Transport) protocol. The protocol conveys application data in its PUBLISH packages. Each PUBLISH packet has its individual QoS (Quality of Service) guarantees set to one of three levels: QoS 0, QoS 1 and QoS 2. The QoS 0 provide no quality guarantees (similarly to the best effort service of the IP protocol). As a result, the PUBLISH package can reach the recipient or not. The QoS 1 provides guarantees of reaching the recipient, but does not guarantee that application data will not be duplicated. The QoS 2 avoids both the loss of PUBLISH packages and their duplication. This paper is focused on the QoS of an IoT system integrated with a videoconferencing system. Experiments were carried out using topology shown in Fig. 1. Results showed that in modern computer networks that use the TCP protocol for transmission of MQTT packets, MQTT's QoS levels and MQTT's error control are less important and have less impact on the reliable delivery of MQTT packets than the TCP. In analyzed system, based on brokers implemented with the use of the mosca library [9] and the MQTTBox [10] emulator, behavior of different QoS levels of the MQTT was, de facto, emulated using different mechanisms of the TCP protocol. Adresy Agnieszka CHODOREK: Politechnika Świętokrzyska, Katedra Systemów Informatycznych, Al. Tysiąclecia Państwa Polskiego 7, Kielce, a.chodorek@tu.kielce.pl Robert Ryszard CHODOREK: AGH Akademia Górniczo-Hutnicza, Katedra Telekomunikacji, Al. A. Mickiewicza 30, Kraków, chodorek@agh.edu.pl