ZAVRŠNI RAD br. 4419 MOBILNOST STVARI U ...SVEUČILIŠTE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA Zagreb, lipanj 2016. ZAVRŠNI RAD br. 4419 MOBILNOST STVARI U ARHITEKTURI

SVEUČILIŠTE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

Zagreb, lipanj 2016.

ZAVRŠNI RAD br. 4419

MOBILNOST STVARI U ARHITEKTURI

INTERNETA STVARI

Jurica Hanžek

i

SADRŽAJ

1. Uvod ............................................................................................................................. 1

2. Internet stvari ............................................................................................................. 2

2.1. Svrha i koncept Interneta stvari .............................................................................. 2

2.2. IEEE 802.15.4 standard i prilagodba standarda ...................................................... 3

3. Ispitivanje komunikacijskih mogućnosti simulatora .............................................. 5

3.1. Simuliranje, poruke i mobilnost .............................................................................. 5

3.2. Ispitni slučajevi ....................................................................................................... 6

3.2.1. Ispitni slučaj 1 ............................................................................................................ 7

3.2.2. Ispitni slučaj 2 ............................................................................................................ 9

3.2.3. Ispitni slučaj 3 .......................................................................................................... 10

3.3. Verifikacija rezultata ............................................................................................. 12

4. Zaključak .................................................................................................................. 14

Literatura ........................................................................................................................... 15

Sažetak ................................................................................................................................ 16

Summary ............................................................................................................................ 16

1

1. UVOD

Internet stvari (engl. Internet of Things, IoT) je pojam koji označava internetsko povezivanje

različitih uređaja čija primarna svrha nije korištenje Interneta [1]. Te „stvari“ mogu biti npr.

kućanski aparati ili vozila što pruža mogućnosti ostvarivanja njihove međusobne

komunikacije kao i komunikacije uređaja s ljudima.

S obzirom na to da je ideja Interneta stvari povezivanje vrlo različitih uređaja, ključni zahtjev

za njihovo povezivanje je prilagodljivost na razne tipove veza među njima. Budući da svi

uređaji koje želimo povezati često nemaju mogućnost povezivanja na nama željeni način,

iznimno bitno je prilagoditi „glavne“ uređaje na više tipova veza.

Ovaj rad fokusira se na ispitivanje programa na različite tipove poveznica između uređaja u

jednoj razvojnoj arhitekturi Interneta stvari [5].

U ovom radu, u drugom poglavlju, najprije se ukratko opisuju ideje, mogućnosti i uporaba

Interneta stvari kao brzorastućeg koncepta komunikacije. Pruža se i kratak uvid u IEEE

802.15.4. standard kao podloga za izradu simulatora mobilnosti stvari u ovoj arhitekturi. U

trećem poglavlju naglasak je stavljen na samu srž ovog dokumenta, a to je ispitivanje

mobilnosti stvari. Opisuje se simulator koji prihvaća razne vrste čvorova (uređaja, stvari) te

prikazuje komunikaciju među njima kroz razne tipove veza i formata poruka koje se

razmjenjuju među dionicima komunikacije. Konačno, u nastavku se opisuju razne

mogućnosti simulatora kroz izradu ispitnih slučajeva. Objašnjava se svrha izrade i očekivani

rezultat pojedinog ispitnog slučaja, detalji izvedbe te dobiveni rezultat. Na kraju slijedi

verifikacija tih rezultata, a dokument završava zaključkom o ostvarenom u ovom Radu i

pregledom mogućnosti za napredak u nekom budućem radu.

2

2. INTERNET STVARI

2.1. Svrha i koncept Interneta stvari

Internet stvari (IoT) je sintagma koja obuhvaća razne vrste heterogenih objekata povezanih

u mrežu kojom ti objekti (stvari) mogu komunicirati. Sam pojam Internet stvari možda je

previše doslovan prijevod engleske kovanice Internet of Things, čime se ne dobiva uvid u to

kakve vrste objekata mogu sudjelovati u komunikaciji. Ti objekti mogu biti razni uređaji

koje koristimo u kućanstvu, ugradbeni uređaji ili vozila [1]. Unatoč raznim mogućnostima,

postoje i određene vrste objekata koji nisu prigodni (korisni) za spajanje u takve mreže.

Osnovni preduvjet za povezivanje nekog objekta u Internet stvari je sposobnost tog uređaja

da pomoću nekakvog senzora prikupi određene podatke koji se mogu u obliku informacije

poslati nekom drugom uređaju ili korisniku (čovjeku).

Jedna od glavnih pretpostavki Interneta stvari je i niska potrošnja energije [2]. Taj zahtjev

posebno se odnosi na uređaje koji prikupljaju i šalju podatke. Unatoč tome što uređaji

primaju i odašilju poruke te tako proširuju svoju funkcionalnost, njihovi zahtjevi za

energijom ne bi smjeli značajno odstupati od istovrsnih uređaja koji nisu dio arhitekture

Interneta stvari. Takvi uređaji čine smisao postojanja Interneta stvari i njihova drastična

preobrazba negativno bi utjecala na njihovu kompliciranost izvedbe, a kod nekih uređaja bi

vjerojatno zahtijevala i potpuno rekonstruiranje čitavog uređaja, što bi u konačnici dovelo

do povećanja njihove cijene. Taj zahtjev, osim cijene, sa sobom povlači i neke dodatne

probleme. Naime ti uređaji upravo zbog tog zahtjeva ne mogu imati veliku moć obrade. Oni

prikupljaju podatke i posjeduju dovoljno logike samo za razašiljanje tih podataka u nekom

dogovorenom obliku (poruka, paket) te za primanje odgovora ili zahtjeva od nekog drugog

uređaja.

Zato bi uređaji koji zahtijevaju podatke trebali biti nešto kompleksniji. Oni obično posjeduju

dovoljnu količinu logike za komuniciranje s više različitih uređaja te za određivanje kojem

od njih trebaju poslati/proslijediti poruku. Ta vrsta uređaja u arhitekturi Interneta stvari mogu

biti korisnici (računala, ostali uređaji povezani na Internet ili neki Cloud servis) ili samo

posrednici, koji služe kao poveznica između objekata koji generiraju neke korisne podatke i

korisnika (čovjeka) koji ih zahtijeva. Posrednici u arhitekturi Interneta stvari mogu, ali i ne

moraju postojati. Potreba za posrednicima proizlazi iz fizičkih opstrukcija komunikacije

između korisnika i objekata koji prikupljaju podatke (npr. njihova udaljenost, postojanje

prepreka koje ometaju komunikaciju i sl.). Često se događa i slučaj kad neki uređaj

objedinjuje uloge posrednika i npr. stvari koja prikuplja podatke.

U arhitekturi Interneta stvari uređaji mogu biti povezani žično ili bežično. Preferirani način

komunikacije je bežični, što ponajviše proizlazi iz jednostavnosti izvedbe. U žičnoj izvedbi

komunikacije dva objekta koja komuniciraju moraju biti fizički spojena što je izrazito

nepraktično za određene vrste uređaja kao što su npr. vozila ili kućanski aparati. Takva

izvedba stvara probleme u infrastrukturnom ostvarenju što također dovodi do povećanja

cijene povezivanja pojedinog uređaja. U bežičnoj izvedbi se javlja drugačiji problem. Stvari

povezane u bežičnu mrežu ne smiju (ne mogu) biti previše fizički udaljene. Taj problem

rješava se uvođenjem međučvorova (posrednika) koji mogu poslužiti kao lanac u

komunikaciji, ali takva bi se rješenja u praksi trebala izbjegavati jer prevelik broj posrednika

dovodi do povećanja cijene i kompleksnosti izvedbe arhitekture što odstupa od osnovne ideje

Interneta stvari. Iz tog razloga arhitektura Interneta stvari (trenutno) se veže uz osobne mreže

(PAN).

3

S obzirom na spomenuto, sigurnost u arhitekturi Interneta stvari nema istu težinu kao kod

konstruiranja širokih, globalnih mreža, protokola i načina komunikacije (npr. www, TCP,

Skype…). Ipak, čak i u takvoj izvedbi postoje određeni načini zaštite komunikacije. Poruke

se mogu kriptirati, mogu se uključiti mehanizmi poput generiranja sažetka poruke i slično.

Valja istaknuti kako korisnik sam treba procijeniti kolika je razina sigurnosti zaista potrebna

njegovoj komunikaciji jer korištenje naprednih mehanizama i algoritama kriptiranja također

mogu negativno utjecati na zahtjev jednostavnosti poruka u komunikaciji. Razina sigurnosti

koja se koristi trebala bi proizlaziti iz značenja podataka koji se prikupljaju u komunikaciji.

Jasno je da korisnik koji dobiva podatak o količini neke namirnice u hladnjaku ne želi toliko

razmišljati o privatnosti (niti sigurnosti) podataka kao korisnik koji prikuplja podatke za,

primjerice, znanstveno istraživanje.

Arhitektura IoT je brzorastuća arhitektura iz nekoliko jednostavnih činjenica. Prije svega, ta

arhitektura relativno je nepoznata prosječnom korisniku Interneta i novih tehnologija

(„pametni“ telefoni, tableti i sl.). Činjenica je da ljudi danas sve više koriste aplikacije na

svojim mobitelima koje omogućavaju lako, brzo i jeftino (ili besplatno) komuniciranje pa se

koncept komuniciranja s neživim stvarima čini kao logičan nastavak tog trenda. Drugi

(možda još i bitniji) razlog je taj da se Internet stvari može primijeniti u vrlo mnogo različitih

djelatnosti, ali i kao olakšavanje svakodnevnih obaveza ili čista zabava [1,2]. Lako je

zamisliti primjenu arhitekture Interneta stvari u prirodnim znanostima koje na taj način

dobivaju vrijedan alat u istraživanjima. To se pogotovo odnosi na medicinu koja ionako

provodi trend sve većeg uključivanja tehnologije u liječenje, rehabilitaciju i dijagnostiku [3].

Brojne mogućnosti za primjenu postoje i u inženjerstvu (promet, građevinarstvo,

strojarstvo). Konačno, proizvođači svake stvari koja može biti izvor podataka mogu se

uključiti u proizvodnju proizvoda prilagođenih arhitekturi Interneta stvari. Proširivanjem

funkcionalnosti bilo koje stvari povećava se njezina objektivna vrijednost (neovisno o

cijeni), što je i temelj ekonomije, ali i cilj ljudskog društva u želji za napretkom.

2.2. IEEE 802.15.4 standard i prilagodba standarda

Organizacija IEEE (Institute of Electrical and Electronics Engineers) prepoznala je važnost

arhitekture Interneta stvari i donijela je standard kodnog imena IEEE 802.15.4. S tim

standardom krenuo je aktivniji rad na arhitekturi Interneta stvari jer, iako ideja za tu

arhitekturu postoji još iz devedesetih godina prošlog stoljeća, širenje korištenja i

unaprjeđivanja arhitekture ima veliki uzlazni trend zadnjih nekoliko godina. Kroz to vrijeme

organizacija IEEE izdala je desetak dokumenata koji unaprjeđuju i proširuju standard.

Standard je najbolji odgovor na zahtjeve opisane u ovom poglavlju jer se fokusira na

oblikovanje jeftine i jednostavne bežične komunikacije među uređajima [4]. Iako postoji

čitav niz standarda iz grupe IEEE 802.15. koji opisuju izvedbe osobnih bežičnih mreža

(WPANs) te mogu biti upotrijebljeni kod izgradnje arhitekture Interneta stvari, standard

IEEE 802.15.4. najbolje opisuje nabrojane zahtjeve pa je pojednostavljena i prilagođena

verzija tog standarda postala osnova za implementaciju simulatora promatrane arhitekture.

Standard predviđa povezivanje uređaja u konceptualno jednostavnu mrežu u kojoj se uređaji

nalaze na udaljenosti do otprilike 10 metara i šalju podatke brzinom manjom od 250kbit/s

[4]. Ti uređaji moraju biti jednostavni, ali i dovoljno općeniti i prilagodljivi kako bi mogli

komunicirati s raznorodnim uređajima.

Također, u standardu se spominju dva različita tipa uređaja s obzirom na mogućnost obrade

podataka - FFD (Full-function device) i RFD (Reduced-function device). Takva

konfiguracija postala je osnova za razdvajanje uređaja (čvorova naše mreže) na glavne i

4

sporedne. Glavni čvor u našem slučaju čini uređaj koji zahtijeva podatke i može komunicirati

s više stvari u svojem djelokrugu te prikupljati podatke na zahtjev ili ih primiti u bilo kojem

trenutku. Sporedni čvor je „stvar“ koja šalje podatke i prima poruke u obliku odgovora ili

zahtjeva. Sporedni čvor može inicirati komunikaciju i ostvariti komunikaciju s više glavnih

ili sporednih čvorova, a može imati i ulogu posrednika [5]. Samo FFD u navedenom

standardu može postati PAN Coordinator što znači da služi kao posrednik i upravljač nad

RFD uređajima, ali i FFD uređajima koji nisu PAN Coordinatori. U našoj mreži funkcija

koordinatora se kao takva zanemaruje – svaki čvor koji ima adresu ima valjanu adresu nekog

drugog čvora može slati poruke tom čvoru bez nekih ograničenja. Razlika između glavnog i

sporednog čvora u našoj mreži očituje se isključivo u mogućnosti uređaja za komuniciranjem

pomoću različitih tipova veza i preko različitih posrednika.

IEEE 802.15.4. predviđa dvije topologije takvih uređaja: zvjezdastu (Star Topology) i

ravnopravnu (Peer-to-Peer Topology). Zvjezdasta topologija predviđa hijerarhiju uređaja

koji želi sudjelovati u komunikaciji i pokazuje pravu funkciju PAN Coordinator uređaja. S

druge strane, peer-to-peer topologija dopušta svakom od uređaja komunikaciju s bilo kojim

uređajem u njegovom dosegu što je i precizan opis mreže korištene u ovom radu.

Standard se, između ostalog, bavi i problemom uspješnosti dostavljanja poslanih poruka.

Tako postoje kontrola zagušenja mreže usred prevelikog broja poruka te potvrda uspješne

komunikacije među čvorovima. Što se kontrole zagušenja tiče, predviđa se korištenje

CSMA-CA i ALOHA mehanizama. S druge strane, naša mreža je dovoljno jednostavna pa

ne postoji velika vjerojatnost zagušenja. Zagušenje bi se moglo dogoditi usred razašiljanja

poruka kroz mrežu od jednog čvora do drugog bez dolaska do čvora kome je poruka

namijenjena (petlja) pa je potrebno izbaciti poruke iz mreže ukoliko one u određenom

vremenu ne stignu do čvora označenog kao primatelj. S tim u vezi, IEEE 802.15.4. govori o

postojanju tzv. Frame acknowledgement mehanizma čija je ideja prihvaćena i u našoj mreži.

Čvor koji prima poruku odašilje odgovor koji je označen kao „reply“ i on putuje natrag do

pošiljatelja izvorne poruke. Mehanizam odgovora koristi se u komunikaciji svaka dva čvora,

neovisno o tome radi li se o komunikaciji glavnog čvora i neke stvari ili o komunikaciji dvije

stvari.

Standard IEEE 802.15.4 govori i o mnogim drugim detaljima, problemima i predviđenim

rješenjima, ali njihova implementacija nadilazila bi doseg ovog projekta.

5

3. ISPITIVANJE KOMUNIKACIJSKIH MOGUĆNOSTI SIMULATORA

3.1. Simuliranje, poruke i mobilnost

Na temelju zahtjeva i ideja arhitekture Interneta stvari opisanih u poglavlju 2.1. i prilagodbe

standarda opisanog u poglavlju 2.2. izgrađen je simulator komunikacije između čvorova

(stvari, uređaja) u nekoj ispitnoj mreži [5].

Motivacija za izradu arhitekture je korisnik koji svojim računalom želi ostvariti

komunikaciju sa „stvarima“, odnosno uređajima koji će dati neku informaciju. Potencijalni

problem javlja se u činjenici da se korisnik možda nalazi izvan dometa uređaja s kojim želi

komunicirati pa je potrebno u komunikaciju uvesti posrednike. To pak dovodi do pitanja

koliko bi posrednika potencijalno moglo zatrebati da udaljeni korisnik ostane u vezi s

promatranim uređajem. Zbog toga se jedan od posrednika zamjenjuje servisom. Servis

zadržava posredničku ulogu, ali također je spojen na Internet pa može održavati stalnu vezu

s korisnikom. On obavlja i ulogu dohvaćanja podataka od stvari pa mora sadržavati njihovu

adresu, a predstavlja i točku proširenja nad kojom se mogu implementirati složenije

operacije nad skupom stvari (npr. nadzor i upravljanje). Na taj način korisnik željene podatke

od servisa preuzima onda kad to njemu odgovara, a ne kada stvari postaju dostupne i šalju

podatke. Jednako tako korisnik može zadati neki upit servisu koji taj upit prosljeđuje

stvarima.

S obzirom na to da u sustavu postoji više tipova čvorova (stvari, posrednici, servis,

korisnici), postavlja se pitanje načina komunikacije među njima. Poruke koje oni

razmjenjuju trebaju prenositi podatke o nekim izmjerenim veličinama ili informaciju o

uspješno obavljenoj komunikaciji. Iako se ovdje oblik podataka kojima se prenose

informacije nazivaju „poruke“, preciznije bi bilo spomenuti da su to zapravo paketi koje

čvorovi razmjenjuju u mrežnom sloju računalnih mreža. Poruke koje se prenose neovisne su

o tipu čvora koji ih šalje/prima.

Poruke su oblikovane tako da se sastoje od vanjskog omotača i unutarnje poruke. Postojanje

vanjskog omotača je neobavezno – svrha tog dijela poruke je povećanje sigurnosti i

privatnosti te jednostavnost prosljeđivanja.

Vanjski omotač sadrži vanjske zastavice, veličinu poruke, unutarnju poruku te potpis

(opcionalno). Vanjske zastavice zauzimaju 16 bitova (nekoliko neiskorištenih) i određuju

veličinu identifikatora u unutarnjoj poruci (16 ili 64 bita): identifikator poruke, identifikator

pošiljatelja, identifikator odredišta i identifikator prijašnje poruke. Također, određuju i

veličinu sigurnog sažetka u unutarnjoj poruci te postavke kriptiranja. Potpis, koji je

opcionalan, koristi se za identifikaciju pošiljatelja, skrivanje identiteta pošiljatelja te

posredno skrivanje unutarnje poruke od ostalih čvorova.

Unutarnja poruka sadrži unutarnje zastavice, veličinu poruke, podatke („korisni“ dio),

sigurni sažetak te identifikatore (poruke, pošiljatelja, primatelja i prijašnje poruke).

Unutarnje zastavice, koje također zauzimaju 16 bitova, sadrže podatke o postojanju

podataka, enkripcije, sigurnog sažetka te informacije o tome traži li se odgovor na tu poruku,

postoje li neki opcionalni identifikatori (pošiljatelja, primatelja i prijašnje poruke), a

nekoliko bitove je neiskorišteno.

Simulator izrađen za komunikaciju čvorova s takvim porukama u opisanom sustavu, daje

prikaz komunikacije u obliku prikazanom na slici 3.1.

6

Slika 3.1. Primjer jednog ispisa

Svaki prikaz akcije pojedinog čvora počinje s točnim vremenom kada je neki čvor

poslao/primio poruku. Nakon toga navodi se ime čvora koji prima (ili šalje) tu poruku te

informacija je li taj čvor tu poruku primio (IN) ili ju u tom trenutku šalje (OUT). Nakon toga

slijede detaljnije informacije o sadržaju poruke: identifikator poruke (mid = message id),

identifikator pošiljatelja (src = source), identifikator primatelja (dest = destination),

unutarnje zastavice (iflags) u heksadekadskom zapisu te podaci (data) predstavljeni

heksadekadskim znamenkama koje u ovom simulatoru komunikacije nemaju neko stvarno

značenje. Ukoliko je poruka odgovor na neku prethodnu poruku, umjesto polja data

pojavljuje se polje resp (response, odgovor) u kojem se nalazi identifikator poruke na koju

se odgovara, a zatim i sadržaj odgovora (data). Na kraju se nalaze informacije o vanjskim

zastavicama (oflags) te osrc- „prenositelj“, odnosno čvor koji je zadnji proslijedio poruku

(može biti stvarni pošiljatelj – src ili posrednik).

Ispitivanje simulatora fokusira se na mobilnost. To znači da ispitujemo mogućnost i

nemogućnost komunikacije nekog „pokretnog“ čvora (označenog s „M“) u mreži koja se

sastoji od nekoliko čvorova stvari („Tn“), posrednika („G“) te kolektora podataka („C“).

Mobilnost čvora predstavljena je valjanošću pojedinih adresa koje čvor M ima zapisane u

svojoj bazi, kao i valjanošću adresa čvora M koje su zapisane u bazi ostalih čvorova.

3.2. Ispitni slučajevi

U svakom od navedenih ispitnih slučajeva zanima nas komunikacija mobilnog čvora M s

ostalim čvorovima u promatranoj mreži – C, G, T1 i T2.

Pri tom postoji nekoliko važnih pretpostavki. Prva pretpostavka je da M ima sve adrese svih

ostalih čvorova – valjanost tih adresa određuje doseg komunikacije pojedina dva čvora.

Iduća pretpostavka je ta da čvor M želi ostvariti komunikaciju sa svim čvorovima u toj mreži

– M inicira komunikaciju šaljući neki zahtjev (podatke) u nadi da će ta poruka stići do

željenog cilja i da će odredišni čvor poslati odgovor (reply) na primljenu poruku. U svim

ispitnim slučajevima koristi se potpuna enkripcija.

U zapisu čvora M postoje podaci o svim čvorovima ove mreže (M, C, G, T1 i T2) – njihovi

identifikatori, imena i njihovi javni ključevi. Osim toga, u „address“ dijelu zapisa nalaze se

podaci o svakom tipu adresa za svaki od čvorova zajedno s prioritetom koji govori

simulatoru kojim redoslijedom će isprobati adrese kada čvor M želi komunicirati s nekim

drugim čvorom (prvo se isprobava komunikacija onim tipom adrese koji ima naznačen viši

prioritet). Zatim postoji zapis pod nazivom „relay“. Relay služi za posredničku razmjenu

poruka – ako izravna razmjena poruka između dva čvora ne uspije, tada čvor inicijator

pokušava stići do željenog čvora tako da promatra tablicu posrednika. Svaki zapis u toj

tablici sastoji se od identifikatora željenog čvora („dest“) i identifikatora posredničkog čvora

(„relay“) te prioriteta takvog načina komuniciranja. Prikladno je zapise u relayju označiti s

manjim prioritetom od onih u „address“ dijelu. U „config“ dijelu zapisa postoje postavke

poruka – enkripcija, unutarnje i vanjske zastavice te opcije spremanja i preusmjeravanja

poruke te zahtjeva za odgovorom. Konačno, u „rules“ dijelu strukture nalaze se zapisi kojim

se opisuje kako čvor reagira na dolaznu poruku od nekog drugog čvora ili prema kojim

čvorovima taj čvor generira zahtjeve (poruke).

7

U svakom od ispitnih slučaja čvorovi sadrže sljedeće adrese:

čvor M sadrži IPv4, IPv6 i WLsim adresu (doseg w1)

čvor C sadrži IPv6 adresu

čvor G sadrži IPv4, IPv6 i WLsim adresu (doseg w1 i w2)

čvor T1 sadrži WLsim adresu (doseg w1)

čvor T2 sadrži WLsim adresu (doseg w2)

Mogućnosti koje takav oblik komunikacije pruža su brojne. Jasno je da je bi ispitivanje

svakog mogućeg ispitnog slučaja daleko prelazio opseg ovog rada pa je ispitivanje

usmjereno na nekoliko jednostavnih, ali reprezentativnih slučajeva. Svi ispitni slučajevi

izrađeni su u json obliku zapisa podataka jer simulator prima tekstualne podatke na temelju

kojih generira željene izlaze.

3.2.1. Ispitni slučaj 1

U ispitnom slučaju 1 ispituje se komunikacija čvora M s ostalim čvorovima kad se M nalazi

samo u dometu čvora C kako je prikazano na slici 3.2. Ispitni slučaj 1 ostvaren je tako da su

u zapisu čvora M adrese čvorova G, T1 i T2 neispravne. Također, čvorovi G i T1 imaju

neispravne adrese čvora M, dok T2 ni ne sadrži zapis o adresi čvora M.

Slika 3.2. Čvorovi u ispitnom slučaju 1

Očekivani ishod ovog ispitnog slučaja je ostvarenje komunikacije čvora M sa svim

promatranim čvorovima. Čvor M i čvor C trebali bi komunicirati izravno jer oba čvora u

komunikaciji sadrže ispravne adrese. Komunikacija čvora M s ostalim čvorovima trebala bi

se odvijati posredništvom čvora C. U tablici posrednika čvora M (relay zapisi čvora M)

nalazi se čvor C koji može proslijediti poruke do čvorova G, T1 i T2. Čvor M najprije bi

trebao pokušati ostvariti izravnu komunikaciju sa čvorovima koji nisu u njegovom dometu,

ali nakon neuspjeha ta komunikacija trebala bi se ostvariti preko posrednika jer je

komunikacija preko posrednika označena s nižim prioritetom od izravne komunikacije.

8

Na slici 3.3. prikazana je komunikacija čvora M i čvora C. Mobilni čvor M inicira

komunikaciju sa čvorom C tako da šalje poruku na adresu koju pronalazi u svom zapisu

čvorova mreže. Uočava se da poruka koju M šalje (mid:e8454233a83c367f) odmah dolazi

do čvora C, što je u skladu s očekivanjem jer čvor M je odaslao poruku na valjanu adresu

čvora C. Nakon primitka, čvor C oblikuje odgovor (Reply) i šalje poruku natrag prema čvoru

M. Taj odgovor ima vlastito polje podataka koje sadrži neke „korisne“ podatke koje je čvor

M zatražio te polje resp u kojem je zapisan identifikator poruke na koju C odgovara.

Slika 3.3. Komunikacija čvorova M i C u ispitnom slučaju 1

Nešto kompliciranija komunikacija odvija se između čvorova M i G. Čvor M u svojim

zapisima ima adrese čvorova G (IPv6, IPv4 i WLsim adresa), ali sve one su neispravne.

Sukladno zadanim prioritetima, čvor M šalje poruku na adresu s najvišim prioritetom, a

nakon neuspjeha takvog slanja šalje poruku na adresu koja je sljedeća po prioritetu. Kako su

sve tri adrese čvora G koje ima čvor M neispravne, četvrti pokušaj nalaženja čvora G odvija

se preko posrednika C. Čvor C je i dalje u dometu čvora M i prima tu poruku te je prosljeđuje

prema čvoru G. S obzirom na to da C ima valjanu adresu čvora G, čvor G odmah prima tu

poruku. Nakon toga G oblikuje odgovor i komunikacija teče u suprotnom smjeru.

Slika 3.4. Komunikacija čvorova M i G u ispitnom slučaju 1

Razmjena poruka između čvorova M i T1 te čvorova M i T2 u ovom ispitnom slučaju odvija

se na jednak način kao između čvorova M i G. I u tim slučajevima čvor C odigrava ulogu

posrednika u komunikaciji između ta dva para čvorova. Razlika je samo u tome što u

komunikaciji tih čvorova sudjeluju dva posrednika – čvor C i čvor G.

9


U ovom ispitnom slučaju čvor M nastoji komunicirati s ostalim čvorovima kad se nalazi u

dometu čvorova G i T1, sukladno prikazu na slici 3.5. U zapisu čvora M adrese čvorova C i

T2 su neispravne. Isto vrijedi za adrese čvora M u zapisima čvorova C i T2.


Očekivani ishod ovog ispitnog slučaja je, kao i u prethodnom slučaju, komunikacija čvora

M sa svim čvorovima u mreži. Čvorovi G i T1 nalaze se u dometu čvora M i njihova

komunikacija treba se odvijati izravno, bez posrednika. Što se tiče ostalih čvorova,

komunikacija se treba odvijati uz pomoć čvora G. S obzirom na to da se u tablici posrednika

čvora M nalazi čvor G koji može proslijediti poruke do čvorova C, T1 i T2, čvor M bi nakon

neuspjele izravne komunikacije sa čvorovima C i T2 trebao uspostaviti komunikaciju s njima

posredništvom čvora G.

U skladu s očekivanjem, komunikacija između čvorova M i G odvija se izravnom

razmjenom poruka između ta dva čvora. Slika 3.6. prikazuje tu komunikaciju kroz izmjenu

jednog zahtjeva i odgovora. Čvor M odašilje poruku na adresu čvora G koju pronalazi u

svom zapisu adresa. Iako se ta komunikacija izravno može odvijati na više načina (oba čvora

imaju valjane IPv6, IPv4 i WLsim adrese), ona se odvija putem IPv6 veze jer ta veza ima

najviši prioritet. Tako čvor G odmah prima poruku poslanu od čvora M te oblikuje odgovor

(Reply) koji, također, odmah stiže do čvora M. Format poruke jednak je onom opisanom u

ispitnom slučaju 1.

Slika 3.6. Komunikacija čvorova M i G u ispitnom slučaju 2

10

Na vrlo sličan način odvija se i komunikacija čvorova M i T1. Jedina razlika je u tipu veze

kojim se odvija komunikacija – u ovom slučaju to je bežična veza u mreži koja je označena

s dosegom w1. Unatoč toj razlici, format poruka je jednak, što je i u skladu sa zahtjevima

općenitosti i prilagodljivosti čvorova u arhitekturi Interneta stvari.

Čvorovi C i T2 također mogu sudjelovati u komunikaciji sa čvorom M iako se ne nalaze u

njegovom dometu. Slika 3.7. prikazuje izvedbu komunikacije čvora M sa čvorom C. Kao

što je i očekivano, M najprije pokušava izravno odaslati poruku čvoru C, ali ne uspijeva jer

nema valjanu adresu tog čvora. Zatim M šalje poruku preko posrednika G koji u svojim

zapisima pronalazi adresu čvora C te mu prosljeđuje poruku. Čvor C šalje odgovor koji se

vraća na posredni čvor G te konačno dolazi do čvora M koji je inicirao komunikaciju.

Slika 3.7. Komunikacija čvorova M i C u ispitnom slučaju 2

Čvor T2 komunicira sa mobilnim čvorom M na potpuno analogan način. Posrednik u toj

komunikaciji je također čvor G. Ovaj slučaj je posebno reprezentativan s obzirom na

prilagodljivost čvorova. Naime čvor M šalje poruku prema posredniku G pomoću žične

(IPv6) veze, a G prosljeđuje poruku bežičnom vezom (doseg: w2) jer čvor T2 posjeduje samo

tu vrstu veze. Čvor T2 zatim istom tom vezom vraća odgovor te se on ponovno žičnom

vezom vrati do početnog čvora M. Tako su čvorovi M i T2 ostvarili komunikaciju unatoč

tome što ne posjeduju međusobno valjane adrese, a ne nalaze se čak ni u istom dosegu za

bežičnu komunikaciju.


Ispitni slučaj 3 pokriva situaciju kada se mobilni čvor M nalazi isključivo u dometu čvora

T1, što prikazuje slika 3.8. Analogno prethodnim slučajevima, u zapisu čvora M nalaze se

ispravne adrese čvora T1, a neispravne adrese ostalih čvorova (C, G i T2). Također, adrese

čvora M neispravne su u zapisima čvorova C, G i T2.

11


Očekivanje od ovog ispitnog slučaja je razmjena poruka između čvorova M i T1. Ta

komunikacija treba se odvijati izravno. S obzirom na to da čvor M u tablici posrednika sadrži

čvorove G i C kao potencijalne posrednike, ali nema valjane adrese tih čvorova, on ne može

pristupiti ni posrednicima ni ostalim čvorovima osim čvora T1. Čvor M treba isprobati sve

adrese čvorova G, C i T2, ali nakon toga odustaje od daljnjeg slanja poruke prema tim

čvorovima. Daljnja razmjena poruka događa se samo između čvorova M i T1.

Slika 3.9. prikazuje razmjenu poruka između čvorova M i T1. Ti čvorovi spojeni su bežičnom

vezom u mreži dosega w1 s valjanim adresama pa zato mogu neposredno komunicirati. Kao

i u prethodnim ispitnim slučajevima, vidimo da čvor M šalje poruku prema čvoru T1, a čvor

T1 prihvaća tu poruku. Nakon toga T1 šalje odgovor s odgovarajućim podacima i ta poruka

u jednom koraku stiže do mobilnog čvora M.

Slika 3.9. Komunikacija čvorova M i T1 u ispitnom slučaju 3

Što se tiče komunikacije čvora M s ostalim čvorovima u ovoj mreži, pokazuje se da zadane

postavke adresa ne omogućavaju ostvarivanje komunikacije, čak ni preko posrednika. Slika

3.10. pokazuje pokušaj čvora M da ostvari komunikaciju sa čvorom C. Analogni ispis dobio

bi se za pokušaj uspostavljanje komunikacije čvora M sa čvorovima T2 i G.

12

Slika 3.10. Čvor M šalje neuspješno šalje poruke

Čvor M pokušava uspostaviti komunikaciju sa čvorom C tako da najprije izravno šalje

poruke na adrese spremljene u tablici adresa. S obzirom na to da jedina adresa koju čvor M

ima za čvor C nije ispravna, komunikacija se pokušava ostvariti preko tablice posrednika

(relay). U toj tablici nalaze se čvorovi C i G kao potencijalni posrednici. Čvor M sada „zna“

da adresa čvora C nije valjana pa pokušava doći do posrednika G i dalje do čvora C. Najprije

pokušava poslati poruku preko IPv6 veze, zatim preko IPv4 i nakon toga preko bežične

WLsim veze. Pokazuje se da ni jedna adresa za posrednik G nije valjana. Čvor M više nema

nikakav mehanizam za slanje te poruke pa se ispisuje pogreška i izbacuje ta poruka iz

komunikacije. Ispis govori da čvor M ne može poslati poruku te se ispisuju identifikatori

poruke, pošiljatelja i primatelja i podaci koji nisu uspjeli pronaći odredište. Nakon toga M

generira novu poruku i ponovno pokušava poslati poruku prema čvoru C.

Sličan ispis dobiva se i za pokušaj komunikacije čvora M sa čvorovima G i T2. Eventualne

razlike u broju ispisa proizlaze iz različitog broja adresa u tablicama čvora M za pojedine

čvorove.

3.3. Verifikacija rezultata

Svi ispitni slučajevi potvrdili su očekivanja. Ovi ispitni slučajevi pokazali su valjanost

simulatora arhitekture za različite zahtjeve. Sažetak rezultata prikazan je u tablici 3.1.

Tablica 3.1. Komunikacija sa čvorom M prema ispitnim slučajevima

ispitni slučaj 1 ispitni slučaj 2 ispitni slučaj 3

čvor C G T1 T2 C G T1 T2 C G T1 T2

izravno + - - - - + + - - - + -

posredno - + + + + - - + - - - -

Tablica pokazuje da je mobilni čvor M uspio uspostaviti komunikaciju sa gotovo svakim od

čvorova u ova tri ispitna slučaja. Ispitni slučajevi 1 i 2 pokazuju široku mogućnost

komunikacije čvora koji može koristiti posrednike u komunikaciji. U ispitnom slučaju 3

pokazuje se osjetljivost arhitekture na slučaj kada rubni čvor mreže, koji ne može koristiti

posrednike u komunikaciji, nastoji slati poruku čvorovima koji mu nisu u neposrednoj

13

blizini. S obzirom na to da je čvor M spojen samo na čvor koji nema ulogu posrednika u

komunikaciji, rezultati trećeg ispitnog slučaja nisu iznenađenje.

Ispitni slučajevi su pokazali i da simulator dobro odgovara na zahtjeve arhitekture Interneta

stvari. Različiti tipovi veza u ovoj simulaciji jednostavne mreže pokazali su da komunikacija

kroz jednostavne poruke ne mora ovisiti o vrsti veze kojom se komunikacija odvija što

pokazuje dobru prilagodljivost sustava. Osim prilagodljivosti, ispunjen je i uvjet

jednostavnosti. Poruke koje se razmjenjuju u mreži prenose određene „korisne“ podatke, ali

u isto su vrijeme dovoljno jednostavne da ne zahtijevaju veliku procesnu moć čvorova. Na

taj način čvorovi koji su „stvari“ mogu ostati fokusirani na svoju primarnu zadaću, a ostali

čvorovi koji se dodaju u mrežu ne moraju biti skupi niti komplicirani.

Kao važan mehanizam pokazalo se i izbacivanje poruka prilikom neuspjele komunikacije.

Čak i u jednostavnim mrežama važno je osigurati dobru otpornost na zagušenja. U mreži

gdje više čvorova može igrati ulogu posrednika lako se može stvoriti slučaj kruženja iste

poruke kroz petlju od nekoliko čvorova, bez mogućnosti napredovanja te poruke prema

ciljanom čvoru. Ta kontrola ostvaruje se zahtjevom za odgovor na odaslanu poruku. Svaki

čvor koji primi određenu poruku ima određeno vrijeme da na nju odgovori. Odgovor bi, u

nekoj stvarnoj mreži, mogao biti skup traženih podataka na poruku koja stvara određene

zahtjeve. Ako pak poruka stiže do nekog čvora koji ne generira podatke, odgovor je

isključivo kontrolnog tipa. Ukoliko čvor ne uspije u zadanom vremenu odgovoriti na poruku,

smatra se da je ona izgubljena, usprkos činjenici da je odgovor možda na putu. Tu se

pokazuje bitnim procijeniti duljinu čekanja na odgovor. U slučaju kada je čekanje na

odgovor prekratko, javlja se potencijalni problem komunikacije nekih udaljenih čvorova, što

je izraženije s većim brojem posrednika u komunikaciji (ispitni slučaj 1 – komunikacija

čvorova M i T1 te čvorova M i T2), ali i većim brojem adresa nekog čvora koje mogu poslužiti

u komunikaciji. To se može vidjeti u slučaju kada su adrese označene s višim prioritetom

neispravne, a simulator najprije pokušava poslati poruku preko njih. S druge strane, kada je

čekanje na odgovor predugačko, iskorištenost mreže je mala i povećava se opterećenje čvora

koji čeka odgovor umjesto da radi nešto korisno. U ovom simulatoru duljina čekanja na

odgovor postavlja se u „rules“ dijelu zapisa prilikom stvaranja poruke. Ovaj mehanizam

pokazao se dovoljno dobrim jer, kao što je već spomenuto u poglavlju 2.2., u našoj

jednostavnoj mreži zagušenja nisu česta pojava pa nema potreba za uvođenjem nekih

naprednih mehanizama.

Ispitnim slučajevima u ovom radu nije pokriven potencijalni problem kvarova pojedinih

čvorova tijekom komunikacije. Ovdje su ispitivani samo dostupnost/nedostupnost čvorova

za komunikaciju, ali stvarni slučajevi mogu biti prilično složeniji. To posebno vrijedi za

bežični tip veze gdje lako može doći do ispada pojedinog čvora usred vanjskih smetnji. U

nekom potencijalnom slučaju moglo bi se dogoditi da čvor do kojeg se pokušava poslati

neka poruka bude privremeno nedostupan pa bi odredišni čvor zaključio da je zapis adrese

za taj čvor pogrešan. Poruka koja putuje kroz veći broj čvorova ima u takvim slučajevima

ima veće šanse biti izgubljena. Potencijalno rješenje tog problema bilo bi pohranjivanje

poruka u nekim čvorovima komunikacije (uvođenja čvorova sa spremnikom), ali to se

djelomično kosi sa zahtjevom jednostavnosti izvedbe arhitekture te dovodi do povećanja

cijene pojedinog čvora zbog ulaganja u memorijski prostor. To dovodi do zaključka da

pouzdanost ove mreže nije velika.

14

4. ZAKLJUČAK

Ovaj rad pokazao je da je izrađeni simulator arhitekture Interneta stvari spreman za

korištenje u nekom jednostavnom okruženju sa sličnim brojem i funkcijom čvorova kao u

ispitnim slučajevima iz ovog rada u kontekstu jednostavnijih oblika komunikacije, izravno i

neizravno (preko posrednika). Izrađeni ispitni slučajevi potvrdili su pouzdanost simulatora

u komunikaciji prilikom uključivanja nekog mobilnog čvora u zadanu mrežu. Ispitni

slučajevi nisu bili komplicirani ni sveobuhvatni, ali su bili prilično reprezentativni s obzirom

na navedene zahtjeve.

Zahtjevi arhitekture Interneta stvari dobro su implementirani u izgradnji jednostavnog

okruženja. Posebno dobro su ispunjeni zahtjevi jednostavnosti i prilagodljivosti svih dionika

komunikacije te je pokazana mogućnost mobilnosti nekog potencijalnog korisnika koji se

želi spojiti u arhitekturu Interneta stvari i crpiti neke podatke.

U nekom budućem radu moguća su poboljšanja u smislu izbacivanja/ispravljanja nepravilnih

adresa iz sustava čime bi se dobilo na brzini komunikacije, ali i na prilagodljivosti zbog

promjenjivih uvjeta u mreži. Potencijalno poboljšanje moglo bi se izvesti i u označavanju

rednih brojeva poruke čime bi se sustavom mogli prenositi veći i kompliciraniji podaci.

Također bi se mogao prilagoditi ispis komunikacije kod ispitivanja simulatora kako bi se

dobio uvid kojom vrstom veze se komunikacija ostvaruje.

Potencijalna korisnost ovog sustava može postati velika. Već je više puta spomenuto da je

arhitektura Interneta stvari jedna od brzorastućih arhitektura u svijetu mreža, ali u vrijeme

izrade ovog rada još uvijek nije široko raširena u svakodnevnom životu. Pravilnom

uporabom sustav bi se mogao koristiti za rješavanje mnogih svakodnevnih rutinskih zadaća

pa se s pravom može reći da arhitektura Interneta stvari u mnogočemu može svakodnevni

život učiniti lakšim.

15

LITERATURA

1. Wikipedia, Internet of Things, https://en.wikipedia.org/wiki/Internet_of_things 2. European Research Cluster on the Internet of Things, Internet of Things – From

Research and Innovation to Market Deployment, River Publishers, http://www.internet-

of-things-research.eu/pdf/IoT-

From%20Research%20and%20Innovation%20to%20Market%20Deployment_IERC_

Cluster_eBook_978-87-93102-95-8_P.pdf., 2014.

3. Prof.dr.sc. Ratko Magjarević, Uvod u tehnologije u medicini, kolegij Tehnologija u medicini, Fakultet Elektrotehnike i Računarstva, Sveučilište u Zagrebu,

https://www.fer.unizg.hr/_download/repository/01_TUM_Uvod_u_tehnologije_u_med

icini_2016.pdf, 2015.

4. IEEE Standards Association, IEEE Standard for Local and metropolitan area networks- Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs),

http://standards.ieee.org/getieee802/download/802.15.4p-2014.pdf

5. Doc.dr.sc. Leonardo Jelenković, Simulator arhitekture Interneta stvari, https://github.com/l30nard0/dasiot

https://en.wikipedia.org/wiki/Internet_of_thingshttp://www.internet-of-things-research.eu/pdf/IoT-From%20Research%20and%20Innovation%20to%20Market%20Deployment_IERC_Cluster_eBook_978-87-93102-95-8_P.pdf.http://www.internet-of-things-research.eu/pdf/IoT-From%20Research%20and%20Innovation%20to%20Market%20Deployment_IERC_Cluster_eBook_978-87-93102-95-8_P.pdf.http://www.internet-of-things-research.eu/pdf/IoT-From%20Research%20and%20Innovation%20to%20Market%20Deployment_IERC_Cluster_eBook_978-87-93102-95-8_P.pdf.http://www.internet-of-things-research.eu/pdf/IoT-From%20Research%20and%20Innovation%20to%20Market%20Deployment_IERC_Cluster_eBook_978-87-93102-95-8_P.pdf.https://www.fer.unizg.hr/_download/repository/01_TUM_Uvod_u_tehnologije_u_medicini_2016.pdfhttps://www.fer.unizg.hr/_download/repository/01_TUM_Uvod_u_tehnologije_u_medicini_2016.pdfhttp://standards.ieee.org/getieee802/download/802.15.4p-2014.pdfhttps://github.com/l30nard0/dasiot

16

SAŽETAK

Mobilnost stvari u arhitekturi Interneta stvari

Ovaj rad bavi se ispitivanjem izrađenog simulatora za jednostavne mreže koncipirane prema

arhitekturi Interneta stvari. Izrađeni su ispitni slučajevi koji simuliraju komunikaciju

pokretnog čvora u arhitekturi i ispituju mogućnosti takvog čvora u zadanoj mreži.

Ključne riječi: Internet stvari, mobilnost, uređaji, poruke

SUMMARY

Title: Explore mobility of things in designed Internet of Things architecture

Summary

This bachelor thesis if focused on testing of simulator designed for simple networks that

were based on Internet of Things architecture. There have been built some tests in order to

simulate communication between mobile and static nodes and to explore possibilities for

mobile node in given network.

Keywords: Internet of Things, mobility, devices, messages

Documents

ZAVRŠNI RAD br. 4419 MOBILNOST STVARI U ...SVEUČILIŠTE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA Zagreb, lipanj 2016. ZAVRŠNI RAD br. 4419 MOBILNOST STVARI U ARHITEKTURI