Интеграција dect ule протокола у систем паметних кућа

УНИВЕРЗИТЕТ У НОВОМ САДУ

ФАКУЛТЕТ ТЕХНИЧКИХ НАУКА У НОВОМ САДУ

Нина Фат

Интеграција DECT ULE протокола у систем паметних кућа

МАСТЕР РАД

Нови Сад, 2016

УНИВЕРЗИТЕТ У НОВОМ САДУ ФАКУЛТЕТ ТЕХНИЧКИХ НАУКА

21000 НОВИ САД, Трг Доситеја Обрадовића 6

КЉУЧНА ДОКУМЕНТАЦИЈСКА ИНФОРМАЦИЈА

Редни број, РБР:

Идентификациони број, ИБР:

Тип документације, ТД: Монографска документација

Тип записа, ТЗ: Текстуални штампани материјал

Врста рада, ВР: Дипломски – мастер рад

Аутор, АУ: Нина Фат

Ментор, МН: Доц. др Иштван Пап

Наслов рада, НР: Интеграција DECT ULE протокола у систем паметних кућа

Језик публикације, ЈП: Српски / латиница

Језик извода, ЈИ: Српски

Земља публиковања, ЗП: Република Србија

Уже географско подручје, УГП: Војводина

Година, ГО: 2016

Издавач, ИЗ: Ауторски репринт

Место и адреса, МА: Нови Сад; трг Доситеја Обрадовића 6

Физички опис рада, ФО: (поглавља/страна/ цитата/табела/слика/графика/прилога)

7/59/23/9/19/2/0

Научна област, НО: Електротехника и рачунарство

Научна дисциплина, НД: Рачунарска техника

Предметна одредница/Кqучне речи, ПО: DECT, ниска потрошња,бежична комуникација,ULE

УДК

Чува се, ЧУ: У библиотеци Факултета техничких наука, Нови Сад

Важна напомена, ВН:

Извод, ИЗ: DECT протокол првенствено је био намењен за телефонске фиксне бежичне уређаје. Овај рад се бави проблемом интегрисања овог већ постојећег систем у системе намењене контроли паметних кућа. У теоријским основама осврће се на проблематику, адресирања, топологије као и самог преноса порука помоћу DECT протокола. Идејно решење своди се на коришћење библиотека које се већ користе спрегнуте са другим протоколима за контролу уређаја у домовима, преко сокета. У резултатима тестирана је јачина сигнала у функцији од раздаљине.

Датум прихватања теме, ДП:

Датум одбране, ДО: 14.7.2016.

Чланови комисије, КО: Председник: Доц. др Иван Мезеи

Члан: Доц. др Миодраг Ђукић Потпис ментора

Члан, ментор: Доц. др Иштван Пап

UNIVERSITY OF NOVI SAD FACULTY OF TECHNICAL SCIENCES

21000 NOVI SAD, Trg Dositeja Obradovića 6

KEY WORDS DOCUMENTATION

Accession number, ANO:

Identification number, INO:

Document type, DT: Monographic publication

Type of record, TR: Textual printed material

Contents code, CC: Master Thesis

Author, AU: Nina Fath

Mentor, MN: PhD Istvan Papp

Title, TI: Integration of DECT ULE protocool in smart homes

Language of text, LT: Serbian

Language of abstract, LA: Serbian

Country of publication, CP: Republic of Serbia

Locality of publication, LP: Vojvodina

Publication year, PY: 2016

Publisher, PB: Author’s reprint

Publication place, PP: Novi Sad, Dositeja Obradovica sq. 6

Physical description, PD: (chapters/pages/ref./tables/pictures/graphs/appendixes)

7/59/23/9/19/2/0

Scientific field, SF: Electrical Engineering

Scientific discipline, SD: Computer Engineering, Engineering of Computer Based Systems

Subject/Key words, S/KW: DECT,low power, wireless network, ULE

UC

Holding data, HD: The Library of Faculty of Technical Sciences, Novi Sad, Serbia

Note, N:

Abstract, AB: DECT ULE protocol was primarily intended for fixed wireless telephone devices. This paper deals with the problem of integrating the already existing system in systems designed to control the smart houses . The theoretical basis refers to the issue , addressing , topology , as well as the transmission of messages using the DECT protocol. Conceptual design is reduced to using libraries that are already being used coupled with other protocols to control devices in homes , through a UDP socket . The results of the tested signal strength as a function of distance, are given in last chapter.

Accepted by the Scientific Board on, ASB:

Defended on, DE: 14.7.2016.

Defended Board, DB: President: PhD Ivan Mezei

Member: PhD Miodrag Djukic Menthor's sign

Member, Mentor: PhD Istvan Papp

Zahvalnost

I

Zahvalnost

Srdačna zahvalnost Institutu RT-RK i profesorima koji su mi ove godine pružili široka

znanja. Osobito prof. Ištvanu Papu, na stručnim savetima i entuzijazmu koje nesebično deli

nama studentima. Dodala bih ovde zahvalnost Aleksandru Živkoviću, na pomoći oko ideje, i

Milanu Saviću, koji je svesrdno prihvatio funkcije lektora ovog rada.

Osim ovoga zahvaljujem se i kolegama u kancelariji na optimizmu, šalama, širokom spisku

običaja i razloga za slavlje. Doći će i taj dan, da ih dočeka „Ladiša“ na stolu.

I na kraju zahvaljujem se svojim najbližima, majci i bratu, na podršci koja traje od dana

mog rođenja do danas. Bez njih ne bih bila ovde gde sam.

Sadržaj

II

SADRŽAJ

1. Uvod ................................................................................................................................ 3

2. Teorijske osnove ............................................................................................................. 5

2.1 Dect ULE protokol ................................................................................................... 5

2.2 Karakteristike mreže ................................................................................................ 6

2.3 Adresiranje i topologija ............................................................................................ 8

2.3.1 Functional (HAN-FUN) Protocol ........................................................................ 8

2.3.2 Uređaji i jedinice ................................................................................................ 12

2.3.3 Interfejsi ............................................................................................................. 15

2.3.4 Servisi ................................................................................................................ 15

2.3.4.1 Obavezni servisi .......................................................................................... 16

2.3.4.2 Opcionalni servisi ........................................................................................ 17

2.3.5 Registracija uređaja i mehanizmi zaštite ........................................................... 19

2.3.6 Hardver .............................................................................................................. 21

3. Idejno rešenje ................................................................................................................ 23

3.1.1 Moguća rešenja .................................................................................................. 23

3.1.2 HAN server ........................................................................................................ 25

3.1.3 Poco biblioteke .................................................................................................. 26

3.1.3.1 Udp socketi .................................................................................................. 27

3.1.4 Programsko rešenje ............................................................................................ 28

3.1.4.1 Opis modula UDP ....................................................................................... 30

3.1.4.2 Opis modula parser ...................................................................................... 31

3.1.4.2.1 Strukture i klase..................................................................................... 31

3.1.4.2.2 Klase ...................................................................................................... 33

Sadržaj

III

3.1.4.3 Opis modula message generator .................................................................. 39

4. Rezultati testiranja ........................................................................................................ 41

4.1 Merenje u zatvorenom prostoru ............................................................................. 42

4.1.1 Snaga signala ..................................................................................................... 42

4.1.2 Kvalitet veze ...................................................................................................... 44

4.2 Merenje na otvorenom prostoru ............................................................................. 44

4.2.1 Snaga signala ..................................................................................................... 44

4.2.2 Kvalitet veze ...................................................................................................... 46

5. Zaključak ...................................................................................................................... 47

6. Literatura ....................................................................................................................... 49

Spisak slika

IV

SPISAK SLIKA

Slika 1. Izgled DECT TDD prozora za prenos podataka ....................................................... 6

Slika 2. Uporedni prikaz sprezanja DECTa sa drugim protokolima ...................................... 7

Slika 3. Zvezdasta topologija uređaja .................................................................................... 9

Slika 4. Izgled slojeva DECT protokola .............................................................................. 10

Slika 5. Struktura prozora i vrste ......................................................................................... 11

Slika 6. Stanja u kojima uređaj može da se nađe prilikom uspostavljanja veze .................. 12

Slika 7. Prikaz komunikacije baze i jedinica ....................................................................... 13

Slika 8. Izgled komunikacije između interfejsa ................................................................... 15

Slika 9 Servisi dostupni na host aplikaciji i bazi ................................................................. 18

Slika 10. Proces registracije uređaja u 3 faze ....................................................................... 20

Slika 11.Blok šema baze ...................................................................................................... 21

Slika 12. Blok šema modula- Izvor [18] .............................................................................. 22

Slika 13. Rešenje zasnovano na aplikaciji pisanoj u pomoću CMBS C biblioteke ............. 23

Slika 14. Rešenje zasnovano na komunikaciji preko HAN servera ..................................... 24

Slika 15. Izgled komandi po pokretanju host aplikacije ...................................................... 26

Slika 16. Komunikacija preko socketa ................................................................................. 28

Slika 17. Osnovni blok dijagram aplikacije ......................................................................... 29

Slika 18. Tok rada parsera .................................................................................................... 32

Slika 19. Izgled površine na kojoj je meren signal .............................................................. 45

Spisak tabela

V

SPISAK TABELA

Tabela 1. Opis karakteristika DECT protokola ...................................................................... 7

Tabela 2. Uporedni prikaz tehnologija ................................................................................... 8

Tabela 3. Spisak interfejsa koji su podržani......................................................................... 14

Tabela 4. Spisak funkcionalnih i rezervisanih interfejsa ..................................................... 16

Tabela 5. Spisak materijala i stepena atenuacije .................................................................. 41

Tabela 6. Prikaz vrednosti signala i standardne devijacije merenja ..................................... 43

Tabela 7. Prikaz procenta primljenih paketa unutar zgrade ................................................. 44

Tabela 8. Srednja vrednost i standardna devijacija merenja na otvorenom prostoru ........... 45

Tabela 9. Prikaz primljenih paketa u odnosu na ukupan broj paketa ................................... 46

Uvod

1

SKRAĆENICE

PSTN/ISDN - Public Switched Telephone Network / Integrated Services for Digital

Network

GSM - Global System for Mobile Communications

IP -Internet Protocol

UMTS -Universal Mobile Telecommunications System

DCS - Dinamic Channel Selection

DECT - Digital European Cordless Telecommunications

ULE - Ultra Low Energy

TDMA - Time Division Multiple Access

CCM - Counter with CBC-MAC je

VoIP - Voice over IP

HTTP - Hypertext Transfer Protocol

SMTP - Simple Mail Transfer Protocol

POP3 - Post Office Protocol 3 osnovni

CMBS - Cordless Module Base Station

URI - Uniform Resource Identifier

OSI - Open Systems Interconnection Model

DLC - Digital Loop Carrier

HAN-FUN (HF)- Home Area Network Functional.

FUN - Functional

EEPROM - Electrically Erasable Programmable Read-Only Memory

DECT ULE - Digital European Cordless Telecommunications Ultralow Energy

RSSI - Received Signal Strength Indicator

Uvod

2

UART - Universal Asynchronous Receiver/Transmitter

ETSI - European Telecommunications Standards Institute

Uvod

3

1. Uvod

Većini korisnika DECT je poznat prvenstveno kao protokol koji je korišćen u telefonskim

mrežama za komunikaciju između slušalice i baze koja je povezana sa PSTN mrežom. Danas

ovaj protokol postaje jedan od primarnih alata u IoT industiji. Od 2011. uvodi se novi standard

DECT ULE (eng. Digital European Cordless Telecommunications Ultralow Energy), koji ima za

zadatak smanjenje utroška energije. Ovaj standard dobio na značaju je na polju automatizacije

kuća, zaštite kuća, kontrole klime i temperature kuća. ULE omogućuje upotrebu baterijskih

uređaja po navodima nekih proizvođača čak i do 10 godina.

DECT standard u potpunosti definiše značenje pokretne jedinice, kao što su na primer

bežični telefoni. Za razliku od GSM mreže ne definiše se strogo topologija mreže. Konekcija ka

fiksnom delu mreže ostvaruje se kroz baznu stanicu koja koristi radio vezu i mrežni prolaz (eng.

gateway) koji povezuje pozive sa mrežom.

DECT ULE je protokol koji je uveden 2011. od strane organizacije ULE Alliance kao

protokol sa manjom potrošnjom. Kao i klasičan DECT koristi 1.9 Ghz propusni opseg i ima

manje smetnji za razliku od Zigbee, Bluetooth, Wi-Fi i ostalih uređaja koji rade na talasnoj

dužini od 2.4 Ghz . Koristeći veliki broj postojećih modema može da se integriše u mreže i zato

poslednjih godina dobija na značaju pametnih kuća [1].

Problem sa kojim se današnja industrija suočava je način integracije već postojećih rešenja.

DSPGroup je ponudio svoje rešenje za bežičnu bazu koja se može integrisati na svaki sistem koji

poseduje serijsku komunikaciju preko USB porta i operativnog sistema koji zahteva minimalne

hardverske resurse i koji je baziran na Linuxu.

Uvod

4

Poglavlja se mogu podeliti na nekoliko celina, koje predstavljaju deo rada.

Prvo poglavlje govori o načinu funkcionisanja DECT protokola, poređenju sa drugim

bežičnim protokolima , karakteristikama i propusnom opsegu.

Drugo poglavlje osvrće se na ponuđeni hardver u vidu baze i uređaja kao i načina

registrovanja uređaja i topologije sistema.

Treće poglavlje obrađuje idejno rešenje koje je implementirano kako bi se sistem

integrisao u web servere pisane u programskom jeziku C++. Predloženo rešenje zasnovano je na

UDP protokolu i implementiranu uz pomoc Poco biblioteke.

Četvrto poglavlje je obuhvata merenja poruka koje prima uređaj sa čvorova u zavisnosti

od razdaljine na kojoj se uređaji nalaze.

Peto poglavlje obuhvata zaključak i dalja istraživanja koja se mogu sprovesti vezana za

ovaj protokol kao i implemenataciju novih rešenja.

Teorijske osnove

5

2. Teorijske osnove

2.1 Dect ULE protokol

DECT je bežična mreža koja omogućava pristup slično kao i GSM svim javnim i lokalnim

mrežama. Poseduje set protokola koji omogućavaju fleksibilnost međukomunikacije između

velikog broja različitih mreža i aplikacija, uključujuči PSTN/ISDN, GSM, UMTS i IP. Koristi se

takođe i mnogim sistemima gde je potrebno da mreža koja prenosi informacije bude pouzdana,

ima širok domet, i male smetnje kao što su na ili uređaji za nadzor beba, zatim protivpožarni

sistemi. Razdaljina varira između nekoliko metara do nekoliko kilometara. DCS (eng. Dinamic

Channel Selection) omogućava korišćenje istovremeno nekoordinisanih privatnih i javnih mreža

na istoj DECT frekvenciji, tako da nije potrebno planiranje raspodele DECT frekvencije. Ovo

proširuje primenu ovog protokola od kućnih bežičnih telefona do složenih sistema kućne

automatizacije. Oblast koja doživljava procvat sa uvođenjem ULE protokola zaduženog za nisku

potrošnju sui pametne kuće [2]. ULE je standard koji je uveden 2013. od strane ETSI da bi se

kreirale bežične mreže senzora i aktuatora. Primarna funkcija je kontrola kuća, klima,

sigurnosnih i alarmnih uređaja. Ono što ULE omogućuje jeste i prenos podataka i prenos glasa,

što znači da senzori nisu limitirani samo na prenos događaja, nego se još dodaje i mogućnost

glasovnih komandi. Evolucija DECT protokola je tekla prvo kroz razvoj niske potrošnje, i male

snage potrebne za prenos signala, do 128 bitne AES enkripcije podataka, koja je smanjila napade

na ovu vrstu bežične komunikacije.

Obavezna implementacija iDCS (eng. Instant Dynamic Channel Selection) poruka i

procedura omogućuje postojanje privatnih i javnih mrežnih sistema koji ne moraju da budu

koordinisane. Svaki uređaj u mreži ima pristup svim kanalima (vreme/frekvencija ravni). Deset

RF nosioca su definisani na frekvencijama 1880 -1900Mhz. i omogućuju 120 dupleks pristupnih

Teorijske osnove

6

kanala. Kada je kontrolni kanal ili veza potrebna, novi kanal za vezu se odabira tako da ima

najmanje inteferencije sa svim kanalima koji imaju istu pristupnu tačku. Broj nosilaca se kreće

do 10. Na Slici 1 je prikazan izgled DECT prozora za prenos podataka i to MC/TDMA/TDD. Po

jednom vremenskom prozoru moguće je preneti istovremeno 12 nosioca. Između dva prozora

razmak je 5 ms, u slučaju da se nalaze na istom nosiocu.

Slika 1. Izgled DECT TDD prozora za prenos podataka

2.2 Karakteristike mreže

DECT protokol je razvijen za velike razdaljine i veliki broj uređaja koje želimo da

priključimo u mrežu. Neke od osnovih karakteristika prikazani su u Tabeli 1.

Prednosti mreže ogledaju se u frekvenciji koja je rezervisana samo za DECT, što

omogućuje malu interferenciju sa ostalim uređajima koji koriste vazduh kao medijum za

komunikaciju. Iako proizvođači garantuju dobar kvalitet komunikacije, korišćenje DECT

protokola nije još doživelo svoj rast na polju automatizacije kuća. Širenje ovog protokola

trenutno ogleda se u prodaji monitora za bebe čija prodaja je porasla sa uvođenjem DECT 6

protokola i niske potrošnje značajno porasla. Sa ovim protokolom povećan je spektar proizvoda

za pametne kuće, koji sada mogu da budu u sprezi sa fiksnim telefonima koji se koriste. Sa

uvođenjem DECT protokola počinju da se podržavaju u Skype i Voip pozivi, koji se preko IP

veze sprežu sa mrežnim servisima (Slika 2.). Skype i Voip pozivi se obavljaju preko socketa i

omogućavaju da se korisnik može udaljiti od baze i do 50m, dok na otvorenom ova razdaljina

Teorijske osnove

7

dostiže i 300m. Kvalitet zvuka je mnogo bolji od analognih bežičnih telefona koji daju statičke

šumove kada se korisnik pomera i priča [3].

Audio kodek G.726

Brzina 32 kbit/s

Frekvencija 1880 MHz–1900 MHz u Evropi

1920 MHz–1930MHz u SAD

Nosioci 10ms (1,728 kHz razmaka) in Evropi

5ms (1,728 kHz razmaka) u SAD

Vremenski slotovi 2 x 12 (ka i od baze)

Prosečna snaga prenosa 10 mW (250 mW najviše)u Evropi,

4 mW (100 mW najviše) u SAD

Alokacija kanala Dinamička

Tabela 1. Opis karakteristika DECT protokola

Slika 2. Uporedni prikaz sprezanja DECTa sa drugim protokolima

Teorijske osnove

8

Osim ovoga važno je uporediti karakteristike uređaja između bežičnih tehnologija. Iako je

Zigbee i Z-wave do sada imali prednost u bežičnim mrežama pametnih kuća, ne treba da se

smetne sa uma i da DECT protokol sa novijim uređajima poseduje podjednako dobru efikasnost

kao i brzinu. Tabela 2 predstavlja uporedni prikaz bežičnih tehnologija [4].

Tehnologija Brzina Frekvencija Osetljivost Snaga

odašiljača

Link

Wavegenis 19kb/s 900 Mhz -107 dBm 14 dBm 121 dB

ZigBee 250kn/s 2400 Mhz -98 dBm 8 dBm 106 dB

Bluetooth 1Mb/s 2400 Mhz -85 dBm 7 dBm 92 dB

Z-Wave 40kb/s 900 Mhz -101 dBm Do 0 dBm 101 dB

DECT 1Mb/s 1900 Mhz -98 dBm 25 dBm 123 dB

Tabela 2. Uporedni prikaz tehnologija

2.3 Adresiranje i topologija

Adresiranje i topologija uređaja su bitan aspekt svih bežičnih mreža. Postoje različiti

pristupi ovom problemu, od prepoznavanja uređaja po njihovom serijskom broju, do dodeljivanja

jedinstvenih identifikatora uređajima u mreži. Pitanje koje se ovde postavlja je i pitanje

interkomunikacije i između samih uređaja i između baze i uređaja. DSPGroup je odgovorio na

ovaj problem uvođenjem već prihvaćenog protokola, definisanog od strane ULE Alliance, kao i

koncepta jedinica i interfejsa kao osnovnog načina za komunikaciju. Čitav koncept protokola,

jedinica i interfejsa biće detaljnije objašnjen u narednim poglavljima.

2.3.1 Functional (HAN-FUN) Protocol

Prva verzija DECT protokola definisana je od strane ETSI koji uspostavlja standarde za

komunikaciju za područje Evrope. Osim standardnih protokola definišu se i protokoli kao što je

vezane za bankomate, elektromagnetsku kompatibilnost, VoIP i drugi. Objavljuje se se prva

verzija DECT ULE standarda 2013. kao novina na polju komunikacija između mašina (eng.

M2M ili Machine-To-Machine). Prvi deo standarda odnosi se na mreže zadužene za kontrolu

kuće, nazvane još HAN (skraćenica od Home Automation Network), dok se takođe planiraju i

proširenja na ovom sistemu, koja još nisu ubačena u standard.

Kao dodatak već postojećoj DECT ULE specifikaciji, ubacuje se i HAN-FUN protokol za

DECT uređaje uveden je od stane ULE Alliance kao jedan od standarda za uređaje koji

podržavaju protokol. Ovaj standard definiše način pravljenja topologije i adresiranja uređaja. sve

u korist ideje da različiti proizvođači lako mogu da integrišu svoje DECT uređaje u jedinstvenu

Teorijske osnove

9

mrežu. Osim toga definiše desetine jedinica, interfejsa i profila koji mogu da se registruju u

mreži. Ovu ideju već su podržali neki proizvođači kao što su: Panasonic, Vtech, DSPGoup,

Gigaset i mnogi drugi.

Ova vrsta protokola podržava različite transportne slojeve kao što su TCP/IP. Cela mreža

zasniva se na topologiji koja je zvezdasta (Slika 3.), gde je centar uređaj koji se naziva baza ili

koncentrator i moguće je na njega da se poveže hiljade uređaja. Neke mreže mogu da imaju

uređaje koji se nazivaju proširivači(eng. Repeater) i koji proširuju opseg glavnog uređaja [8]. U

ovom slučaju postavljanja proširivača, važno je jedino razmotriti prostor koji baza pokriva.

Slika 3. Zvezdasta topologija uređaja

Baza je uređaj postavljen na vrh transportnog sloja i omogućava komunikaciju sa ostalim

uređajima u mreži. Da bi se razumela mreža uređaja potrebno je razmotriti slojeve komunikacije

koji se dele na pet segmenta: fizički, mrežni, kontola poziva, veza za podatke i mac sloj. Prikaz

rasporeda slojeva je dat na Slici 4.

Fizički sloj deli radio spektar na fizičke kanale. Podela se vrši prema dve fiksne dimenzije i

koristi se TDMA (Time Division Multiple Access) operacije na višestukim RF nosicima. Tipično

se uzima oko 10 nosilaca u opsegu frekvencija (1880 do 1900MHz). Svaka TDMA struktura

definiše 24 slota u frejmu od 10ms. Svako polje sadrži sihnronizaciono polje zajedno sa

kontrolnim informacijama, formatiranjem servisa i kontrolom grešaka. Vrši dinamičko

odabiranje kanala (eng. Dynamic Channel Selection) koje upravlja DECT prenosom podataka.

Mrežni sloj (eng. Network Layer) je glavni sloj aplikacije. Ima sličan format kao većina

ISDN (eng. Integrated Services Digital Network) slojeva i nudi slične funkcionalnosti [6].

Upravlja tako što koristi razmenu poruka između uparenih uređaja. Ove poruke podržavaju

uspostavljanje, održavanje i prekid poziva kao i mnoge druge mogućnosti.

Kontrola poziva omogućava da servis preko virtuelnog kola (VC ili virtual circuit) odabere

željenu opcija sa veze za podatke. Osim ovog implementirani su i servisi za upostavljanje veze,

slanje poruka i upravljanjem porukama.

Teorijske osnove

10

Slika 4. Izgled slojeva DECT protokola

Veza za podatke (eng. Data Link) obezbeđuje siguran sloj za podatke koji stižu sa mreže i

na taj način omogućava veći integritet za podatke..DECT slojevi razdvajaju se na ovom nivou na

dva DLC (eng. Digital loop carrier) sloja, C (eng. Control) i U (eng. User) ravan. C ravan je

zajednička svim aplikacijama, i nudi mogućnost pouzdanih linkova potrebnih za internu

kontrolu. U ravan obezbeđuje grupu alternativnih servisa, koji su optimizovani za određenu

svrhu.

MAC nivo obavlja dve osnovne funkcije, prvo odabira fizičke kanale i i oslobađa vezu na

njima [5]. Kao drugi korak vrši se od odabiranje kontrolne informacije zajedno sa

informacijama sa višeg nivoa i informacijama o greškama, i smešta ih u paket veličine prenosnog

prozora. Ovaj nivo treba da emituje poruke svim uređajima i te poruke se smeštaju u A polje

koje je rezervisano i javlja se u svim prenesenim paketima preko mreže. Ove poruke se emituju

svim uređajima i omogućavaju lakše prepoznavanje baze u okolini (eng. Fixed Point) od strane

uređaja-čvorova [7]. Na nivou MAC sloja definišu se stuktura okvira sa 24 puna prozora na

osnovu stukture na fizičkom nivou. MAC nivo kontroliše transmisiju i primanje svakog

duplog(eng. double), polu(eng. half slot) i punog (eng. full slot) prozora (Slika 5).

Teorijske osnove

11

Slika 5. Struktura prozora i vrste

Na ovom nivou postoji nekoliko stanja u kojima može da se nađe uređaj, prilikom na primer

registracije, ili dobavljanja podataka sa baze. Da bi bilo kakvu operaciju obavio uređaj je dužan

da pronađe slobodan prozor, tj da se sihronizuje da bi obavio transmisiju [8]. Zbog toga važno je

voditi računa o zauzetosti slotova, kroz nekoliko stanja, u kojima uređaj može da bude (datih na

Slika 6):

Active_Locked: Čvor je sinhronizovan sa poslednjim nosiocem i ima jednu ili više

transmisija u progresu

Idle_Locked: Čvor je sinhronizovan na bar jednu transmisiju. Može da prihvati vezu , ali

trenutno nijedna veza nije aktivna.

Active_Unlocked: Čvor nije sinhronizovan na transmisiju i nemoguće je uspostaviti vezu.

Povremeno se trazi da li bilo koji uređaj pokušava da uspostavi vezu.

Idle_Unlocked: Čvor nije sihronizovan ni na jednu transmisiju niti pokušava da pronađe

bilo kakvu slobodnu vezu.

Teorijske osnove

12

Slika 6. Stanja u kojima uređaj može da se nađe prilikom uspostavljanja veze

2.3.2 Uređaji i jedinice

Ovo poglavlje odnosi se na osnovno pitanje organizovanja uređaja koji su u mreži. Dok su

slojevi opisani u prošlom poglavlju obavezni, logičko udruživanje uređaja prema

funkcionalnosti, uvedeno je tek kasnije od strane ULE Alliance, i nije obavezno za proizvođače.

Ali svakako poštovanjem dogovora više različitih proizvođača mogu da integrišu uređaje u

jedinstven sistem [9].

Uređaji koji se registruju na bazu se mogu da sadrže konceptualne jedinice (eng. units)

koje instanciraju funkcionalnost u vidu profila. Svaki uređaj može da ima do 256 jedinica koje

mogu da pripadaju istom profilu ili ne. Svaka jedinica ima svoj jedistveni ID koji omogućuje da

se poruke sa ostalih jedinica upućuju ka njoj. Ovo je 8 bitni identifikator kojim se registruje

uređaj. Zajedno identifikator uređaja i identifikator adrese čine jedinstvenu adresu na koju se

šalju poruke [10].

Osim ove jedinice postoji i jedinica u svakom uređaju koja je zadužena za upravljanje

uređajima (eng. Device Management). Sadrži osnovne servise koje se koriste kod svih jedinica

koji se moraju implementirati.

Teorijske osnove

13

Slika 7. Prikaz komunikacije baze i jedinica

Svaka jedinica može da nosi broj profila koji može da označava čemu sama jedinica služi,

kao što je na primer detektor za otvaranje i zatvaranje vrata, protivpožarni detektor, pametna

utičnica i drugi (Slika 7). Na ovaj način moguće je podeliti grupe na skupove uređaja iste ili

slične funkcionalnosti. U slučaju da neki uređaji poseduju istu funkcionalnu jedinicu, uparenu sa

adekvatnim interfejsom, oni mogu međusobno da komuniciraju između sebe što olakšava da se

emituju poruke na više istovetnih uređaja kao i da se primaju poruke sa grupe uređaja [10].

Profil je kolekcija interfejsa koji definišu specifičnu funkcionalnost po kojoj aplikacija

može da prepozna koji je uređaj u pitanju. Profili ovo čine na taj način što opisuju ponašanje

koje obavezni servisi moraju da implementiraju. Kao dodatak na sve ovo profil treba da definiše

kako se podaci čuvaju i interpretiraju na relevantnim interfejsima. Svaki profil se instancira u

posebnim jedinicama unutar uređaja. Profili imaju jedinstveni identifikator koji se koristi da se

zna minimalna funkcionalnost za bilo koju jedinicu.

Registracijom jedinice ovi interfejsi se dodaju sami i njih dodaje baza koja inače čuva

tabelu dostupnih interfejsa u EEPROMu.

Uređaj deklariše tabelu dostupnih jedinica i opcionalnih interfejsa za date jedinice. One

jedinice/interfejsi koji ne postoje neće moći da koriste neke od osnovnih servisa sa baze

(koncentratora). Rečeno je da jedinice poseduju jedinstveni identifikator koji dozvoljava da se

poruke adresiraju na njih. Zajedno sa jedinstvenom adresom uređaja dobija se sistem

jedinstvenih adresa koja dozvoljavaju primanje i slanje poruka. Ova jedinica ukombinovana sa

jedinstvenim HF uređajem proizvodi jedinstvenu adresu, dozvoljavajući jedinicama da

komuniciraju jedna sa drugom.

Svaki uređaj ima definisan osnovni interfejs sa identifikatorom 00 rezervisan za osnovne

interfejse. Kao dodatak svaka druga jedinica može da implementirati neke servise iz Tabele 3.

Teorijske osnove

14

0x0001 Device

Management

Obavezan Servis zadužen za

otkrivanje uređaja

0x0002 Bind Management

Service

Obavezan Servis za kreiranje grupe

uređaja i uspostavljanje

veze između njih

0x0003 Group

Management Service

Opcioni Servis za emitovanje

poruka svim jedinicama

neke grupe.

0x0004 Identify Opcioni Jednostavan metod za

otkrivanje uređaja bez

potrage na osnovu

serijskog broja

0x0005 Device Information Obavezan Servis koji definiše

obavezne informacije

svagog uređaja u mreži

0x0006 Attribute Reporting Obavezan Servis koji omogućajva

da uređaji ili jedinice

povremeno šalju

obaveštenja ka bazi

0x0007 Batch Program

Management

Opcioni Servis za kreiranje

programa tj grupe akcija

koje se izvršavaju kada

neki događaj se desi

0x0008 Event Scheduling Service Opcioni Servis koji ima zadatak

da odrađuje vreme

izvršavanja događaja

0x0009 Weekly

Scheduling Service

Opcioni Zakazivanje na nivou

nedelje

0x0101 Tamper Alert Service Opcioni Servis za obeveštavanje

da je uređaj u kvaru

0x0102 Time Service Opcioni Obaveštava jedinice o

trenutnom vremenu po

UTC

0x0110 Power Service Opcioni Obaveštava o napajanju

0x0111 RSSI Opcioni Servis za određivanje

jačine signala

0x0115 Keep Alive Opcioni Servis koji salje

povremena obaveštenja

uređaja o tome da su

aktivni

0x0400 SUOTA Opcioni Softvare Update Over

The Air ili nova verzija

softvera se instalira bez

žične veze

Tabela 3. Spisak interfejsa koji su podržani

Teorijske osnove

15

2.3.3 Interfejsi

HAN FUN Interface biblioteka obezbeđuje funkcionalne gradivne blokove za definisane

jedinice koje su vezi sa profilima. Interfejsi su kolekcija komandi i atributa koje se koriste u

jedinicama kao obavezne ili opcionalne. Svaki interfejs ima takođe jednu ili dve moguće uloge

koje su povezane sa serverom ili klijentom. Kao primer, dato je na Slici 8. prikaz dva različita

uređaja koji imaju jednu ili dve uloge povezane sa istim interfejsom.

Slika 8. Izgled komunikacije između interfejsa

Jedinica 1 ima funkciju servera dok je jedinica 2 je klijent. Na ovaj način interakcija

uređaja je definisana gde se jednostavno identifikuje uređaj koji je kontroler (klient) i

senzor/aktuator uređaj (server) koji šalje poruke.

Svaki interfejs nosi svoj identifikacioni broj po kome može da se prepozna skup funkcija koje

implementira, koje atribute podržava, kao i komande. Sve ove operacije su značajne kada se

primenjuju kod uređaja koji koristi FUN poruke da bi primao informacije o uređajima. Svaki od

uređaja implementira neki od navedenih funkcionalnih interfejsa, koji opisuju spisak atributa

koje podržava.Prikaz svih ponuđenih interfejsa nalazi se u Tabela 4.

2.3.4 Servisi

U sledećem poglavlju biće opisano koje sve servise neki uređaj može da podržava. Osim

obaveznih servisa koji moraju da budu implementirani, radi registracije, biće opisani i opcioni

servisi koji se naknadno mogu dodati ali ipak su bitni jer bliže opisuju uređaje i dodaju operacije

kao što je slanje više komandi istovremeno, obaveštavanje o kvaru, grupisanje uređaja itd.

Teorijske osnove

16

Funkcionalni interfejsi

Identifikacioni broj

(hex)


(dec)

Ime Opis

0x0100 256 Alert Kada uređaj definiše

promenu, ili uzbunui

0x0200 512 On-Off Paljenje i gašenje

uređaja

0x0201 513 Level Control Podešava parametar

uređaja na određeni

nivo

0x0300 768 Simple Metering Uređaj obezbeđuje

merenja električnih

karakteristika

0x0301 769 Simple Temperature Interfejs za temperaturu

0x0302 770 Simple Humidity Interfejs za vlažnost

vazduha

0x0303 771 Simple Termostat Interfejs za

temparaturni uređaj

0x0304 772 Simple Button Interfejs za primanje

nekoliko obaveštenja o

pritisku dugmeta

0x0305 773 Simple Visual Control Interfejs za kontrolu

nekog visuelnog

identifikatora

0x0306 774 Air Pressure Interfejs za vazdušni

pritisak

Rezervisani interfejsi


(hex)


(dec)

Ime Opis

0x7f00-0x7ffe 32512 - 32766 Reserved Za vlasničke interfejse

0x7fff Reserved Specijalni identifikator

Tabela 4. Spisak funkcionalnih i rezervisanih interfejsa

2.3.4.1 Obavezni servisi

Unutar uređaja postoji velioki broj servisa pomoću koji jedinice međusobno mogu između

sebe da šalju poruke i obaveštenja. Svaki uređaj mora da poseduje osnovnu jedinicu pod

oznakom D:0 U:0 što je skraćenica za device 0: unit 0. Ova jednica je obavezna i omogućava

Teorijske osnove

17

komunikaciju svih uređaja sa bazom. Osim ovoga, unutar ove jedinice uključena su 3 servisa

koja su obavezna[11]:

1. Upravljanje uređajima - Device Management Service

2. Informacija o uređajima - Device Information Service

3. Obaveštenja o stanju atributa - Attribute Reporting Service

Device Management obezbeđuje da svaki uređaj koji treba da se registruje u mrežu dect

uređaja mora da se registruje sa D0:U0, tj sa bazom. Na ovaj način se obezbeđuje jedinstvena

adresa za taj uređaj. Kao deo registracionog procesa uređaj mora da informiše o tome koje

jedinice i opcionalne interfejse implementira i podržava. Osim registracije i deregistracije

uređaja D0:U0 dozvoljava i otkrivanje drugih uređaja u mreži, tako što zahteva informacije o

svim uređima. Obavezni interfejsi ovih jedinica se ne moraju da se registruju. Potrebno je

registrovati samo opcione interfejse.

Device information definiše set podataka koje svaki HF uređej mora da obezbedi.

Informacije su vezane za verzije protokola i slojeva kao i komunikacionih uslova, dok su drugi

podaci opcionalni.

Attribute Reporting Service je servis koji omogućava da se jedinica obaveštava kada dođe

do promene vrednosti nekog parametra u nekoj drugoj jedinici, koja implementira isti interfejs.

Takođe uređaju se može slati periodično obaveštenje o stanju nekog atributa. Osnovna jedinica,

oznake D:0 U:0, je dužna da implementira ovaj servis i njegov interfejs kao server tj da može da

prima poruke sa ostalih uređaja, registuje pravila o primanju poruka i prima prosta obaveštenja.

2.3.4.2 Opcionalni servisi

Osim obaveznih servisa postoje i oni koji se implementiraju opciono u zavisnosti da li su

potrebni. Dele se na nekoliko grupa izdvojenih u sledećim pasusima i prikazanih na slici( Slika

9).

Upravljanje vezama (eng. Bind Management) predstavlja servis koji pravi logičke veze

izmedju unita i uređaja (jednog ili više njih).Svaki interfejs se povezuje u device-unit-interface

kao triplet uređaja . On takođe čuva internu bazu svih veza među jedinicama. Osim ovoga

moguće je da se uklanjaju veze između jedinica. Takođe se implementira i Bind Lookup Service

koji ima zadatak da koji se koristi od strane rutera za pravljenje putanji poruka.

Servis za upravljanje grupama (eng. Group Management Service) omogućava da kroz

jednu adresu se povezuje više uređaja. Ovo je posledica toga što se unutar svakog uređaja nalaze

jedinice koje se lako grupišu prema adresama. Poruke je moguće da se šalju kao unicast i kao

Teorijske osnove

18

broadcast.Unicast slanje predstavlja slanje svakoj jedinici unutar grupe posebno na adresu.

Emitovanje ( eng. broadcast) predstavlja slanje svim jedinicama preko zajedničke adrese.

Servis za identifikaciju uređaja (eng. Identify Service) omogućava identifikaciju uređaja

bez traženja serijskog broja. Ovo se postiže slanjem jednostavne komande uređaju koja ga pali ili

gasi, radi neku komandu, i zatim očekuje odgovor, na tu komandu.

Servis za grupisanje programa (eng. Batch Program Management Service) koristi se za

grupisanje skupa komandi koje želimo istovremeno da izvršimo.

Servis za zakazivanje događaja (eng. Event Scheduling Service) koristi se za postavljanje

vremenskog intervala na grupu programa koji je ranije objašnjena unutar servisa za grupisanje

komandi.

Servis za zakazivanje (eng. Weekly Scheduling Service) izvršavanja nekog programa na

nedeljnom nivou.

Servis za obaveštenje o kvaru (eng. Tamper Alert Service) izveštava u slučaju da dođe do

havarije nekog uređaja.

Slika 9 Servisi dostupni na host aplikaciji i bazi

Osim navedenih servisa koji su obavezni od strane DECT ULE specifikacije, dodat je još i

servis od strane DSPGroup koji je jedan od proizvođača, za slanje poruka (eng. Message

Service). Message Service implementira ruter, putanju za slanje, i putanju za primanje poruka.

Ruter je zadužen za slanje poruka koje idu ka bazi i adresiranje svih poruka. Putanja za slanje

zadužena je za usmeravanje poruka koje idu ka bazi. Potrebno je da se te pristigle poruke usmere

Teorijske osnove

19

na odgovarajuću jedinicu i interfejs. Putanja za primanje šalje poruke od baze ka ostalim

uređajima, tj njihovim jedinicama i interfejsima [14].

Han uređaj ne mora da održava stalnu vezu sa bazom. Kada jedinica hoće da pošalje poruku,

treba da pošalje zahtev servisu za poruke (eng. Message Service) koji u zamenu ima vezu sa

servisom za rutiranje. Servis za rutiranje obaveštava da određeni uređaj želi da uspostavi vezu sa

bazom. Nakon što se primi obaveštenje da je uređaj dobio vezu sa bazom, jedinice tog uređaja

mogu da šalju poruke. Nakon završetka servis za poruke je dužan da zatvori vezu.

2.3.5 Registracija uređaja i mehanizmi zaštite

Svaki složen sistem koji je zadužen da vodi računa o osetljivim pitanjima kao što je

kontrola kućnih aparata, obaveštavanje o narušavanju privatne svojine, narušavanje sigurnosti

ukućana, prirodnim nepogodama mora da poseduje siguran sistem zaštite podataka koji se

prenose preko mreže bilo da je ona bežična ili žična. Ideja da je sam protokol plasiran preko

vazduha čini ga manje otpornim na napad i slanje lažnih informacija ka uređajima. Jedan od

načina na koji su se proizvođači uređaja koji koriste DECT protokol zaštitili od napada, je ideja o

registraciji uređaja kroz tri koraka.

Prilikom priključivanja uređaja u mrežu postoje izazovi zbog kratkog vremena prenosa

paketa gde ne postoji mogućnost testiranja i provere na višim nivoima protokola. Zbog toga

prilikom uključivanja uređaja u mrežu i registracije postoje 3 faze provere.

Prva faza registacije obuhvata jednostavno uparivanje uređaja (eng. Easy Pairing) gde se

šalje niz od 1000 i uređaj je dužan da vrati niz (eng. capability bit) koji predstavlja potvrdu da je

ovo zaista DECT ULE uređaj. Korisnik zahteva prava pristupa na taj način što baza fiksna baza

emituje “Access Rights requests supported” bit za pristup . Kada se uređaj prijavi, čvor će da

emituje PIN kod (najčešće 0000), i započeće procedura za dobijanje prava (eng. access rights),

dok se vrednost dobijenog PINa koristi kao autentifikacioni kod. Prilikom obavljanja ove faze

registracije, pretpostavlja da je jedininica koja se registruje u blizini baze. U slučaju da postoji

više baza, čvor uređaj (eng. node) će odabrati najbližu bazu da se registruje. Za ovo koriste se

očitavanja jačine signala (RSSI) na svim kanalima. Pronalazi se onaj sa najvećom jačinom

signala. Gleda se da li je capability bit setovan. U slučaju da jeste nastavlja se dalje sa drugom

fazom, ako nije traži se druga bazna stanica [14]. Kao dodatak se može dodati i procedura da se

baza odabira prema imenu, i na taj način se kontroliše da se uređaj na pravu bazu registrovao. U

slučaju da ne postoji baza tada se može pokrenuti procedura koja je dužna da sama probudi

process registracije od strane baze ako se u blizini nalazi uređaj.

Teorijske osnove

20

Druga faza obuhvata slanje paketa preko mreže kao što je razmena verzija softvera, zatim

informacija o stranicama, razmena CCM ključeva koji su karakteristični za AES enkripciju.

Potrebno je da se pošalje ključ dužine 64 ili 128 bita na koji se dobija odgovarajući odgovor.

Odabrani ključ ne bi smeo da se koristi više od jednog puta[14].

Treća faza podrazumeva slanje registacione poruke i odgovora na nju gde se konačno

dobija broj uređaja, informacija o interfejsima i jedinicama koje su podržane u okviru već

formiranog sistema kao i njegove jedinice i interfejsi[15].

Većina ovih funkcija automatski je implementirana unutar CMBS C biblioteke koju

proizvođač obezbeđuje.

Slika 10. Proces registracije uređaja u 3 faze

Na Slika 10 prikazan je način komunikacije CMBS C API sa uređajem. Baza šaljući

događaje, koji se pomoću softverskog steka na bazi, komunicira sa uređajima. Svaka fukcija koja

se koristi očekuje odgovor od strane baze da li je uspešno izvršena. Funkcija

cmbs_dsr_cord_RegistrationOpen otvara port za registraciju uređaja i čeka događaj

CMBS_EV_DSR_CORD_REGOPEN_RES da bi započela sledeću fazu. U slučaju da ne dobije

odgovor od nijednog uređaja registracija se zatvara nakon 120s. U slučaju da uređaj se registruje

na sistem pokreće se sledeća faza gde se očekuju događaji kao što su

CMBS_EV_DSR_HAN_DEVICE_REG_STAGE_1_NOTIFICATION, kao i obaveštenja

vezana za sledeće faze registracije. Nakon uspešne prve faze registracije zatvara se registracioni

prozor da ne bi neki drugi uređaj pokušao istovremeno da se registruje na isti kanal.

Teorijske osnove

21

2.3.6 Hardver

Ovaj uređaj koristi processor 32-bit ARM926 @208MHz with MMU, zatim 32kb I-keša i

8kB D-keša. Memorija obuhvata 250KB ROM memorije sa 128KB programske RAM

memorije. Baza poseduje memorijski mapiran Quad SPI fleš interfejs sa vezom frekvencije

10MHz. Dva eksterna SPI interfejsa poseduju DMA podršku za ekran . Osim ovog poseduje još

UART, GPIO i PWM za 3 led diode.

Slika 11.Blok šema baze

Što se tiče uređaja da bi se neki uređaj integrisao u sistem, i mogao registrovati potrebno

je da poseduje modul sa antenom za DECT protokol. DSPGroup je implementirao modul koja se

jednostavno integriše u već postojeći uređaj, i koji se još naziva DHAN module [17]. Blok šema

data je na Slici 12.

Dhan modul je fabrički obezbeđen sa standardnim HAN-FUN izvornim kodom već učitanim u

uređaj, i napravljenim tako da se sa ulazima može jednostavno kontrolisati sa eksternim

mikrokontrolerom. Implemetira standatdne protokole komunikacije I2C, UART, GPIO, Takođe

on je konfigurisan da radi na frekvenciji definisanoj za Evropu (1880-1900Mhz), sa generičkim

identifikatorom, i sebe identfikuje kao detektor dima na baznoj stanici kada se prvi put učita. Ovi

parametri se naknadno mogu promeniti od strane korisnika slanjem komandi.

Teorijske osnove

22

Slika 12. Blok šema modula- Izvor [18]

Snaga koju emituje ovaj modul prilikom slanja je 23,6dBm dok prilikom prijema

osetljivost ide do -96dBm. Potrošnja modula koja u stanju hibernacije iznosi oko 2µA.

Važno je napomenuti način na koji se antena kontroliše preko eksternog mikrokontolera. U

slučajevima kada mikrokontroler detektuje događaj koji se mora poslati DHAN-u, moraće prvo

da probudi DHAN iz hibernacije i da sačeka oko 10ms, i tek onda preko UART porta može

poslati informacije koje će se dalje emitovati preko antene. Postoji više načina na koji se postiže

buđenje mikrokontrolera:

1) Poslati signal sa rastućom ivicom na neki od ULE I/O ulaza, i zatim započeti

komunikaciju preko UARTa,

2) Početi komuikaciju sa UARTa u nadi da će eksernom mikrokontroleru biti potrebno

10ms da primi podatke.

U ostalim slučajevima, kada je mikrokontroler, na primer, u stanju hibernacije, on će se

najčešće probuditi u slučaju da se javi neka tranzicija na RxD liniji, tj magistrali za čitanje.

Idejno rešenje

23

3. Idejno rešenje

3.1.1 Moguća rešenja

Proizvođač koji je implementirao bazu kao rešenje integracije u već ponuđen sistem

ponudio je dva rešenja od kojih će jedno biti objašnjeno kasnije u tekstu. Jedno od dostupnih

rešenja podrazumeva da se na osnovu već postojeće biblioteke implementira sistem [17].

Softverski stek (CMBS SDK) se nalazi na DCX81 CMBS modulu, još poznatom kao baza,

i predstavlja vezu ka uređajima koji podržavaju HAN DECT protocol. Aplikacioni softver

pokrenut je na nekom mrežnom procesoru. Aplikacioni softver se najčešće isporučuje kao izvršni

fajl potrošaču. Ovaj izvorni kod je pisan u C jeziku i može da se pokrene na računaru koji ima

minimalan ARM9 procesor sa 8MB rama, i Linux operativnim sistemom. Izvršni kod. još

nazvan DSPG-CMBS Reference, ostvaruje RS232-UART komunikaciju sa bazom i njenim

softverskim stekom.

Slika 13. Rešenje zasnovano na aplikaciji pisanoj u pomoću CMBS C biblioteke

Idejno rešenje

24

Prvi način ostvarivanja komunikacije je direktnim korišćenjem CMBS biblioteke unutar

aplikacije. Mana ovog pristupa što korisnik mora sam da implementira aplikaciju. Vreme razvoja

je duže, zbog vremena potrebnog sa upoznavanjem sa bibliotekama. Takođe ograničenje

predstavlja i sam izbor programskog jezika koji je sada sužen na C. Prednost je u tome što

korisnik odabira funkcionalnosti iz biblioteke koje su mu potrebne, bez potrebe za

implementiranjem modula koje neće koristiti.

Drugo rešenje je korišćenje već gotove aplikacije za server za komunikaciju sa bazom, i

njegova instalacija u postojeći uređaj. Komunikacija sa korisničkim programom i informacija o

uređajima se dobija preko socket-a. Ovaj način implementacije podrazumeva viši nivo

apstrakcije, kojima korisnik može da pristupa prema funkcionalnostima. Ujedno je vreme

razvoja kraće jer korisnik ne mora da proučava biblioteke koje daje proizvođač, nego samo

protokol i poruke koje mu stižu sa već gotovog servera instaliranog na mrežnom procesoru.

Programer koji razvija aplikaciju za DECT protokol, osim HAN protokola je dužan da sam

napiše aplikaciju koja komunicira preko socketa, koristeći po izboru biblioteke za

implementaciju socketa.

Komunikacija sa uređajima se ostvaruje preko FUN OTA(eng. Fun Over The Air) poruka,

koje su ustvari DECT bežične poruke, čija struktura je definisana u zvaničnoj specifikaciji

DECT protokola.

Slika 14. Rešenje zasnovano na komunikaciji preko HAN servera

Idejno rešenje

25

3.1.2 HAN server

Da bi se mogao koristiti protokol potrebno je ukratko upoznati se sa osnovnim

funkcionalnostima aplikacije koja će biti instalirana na uređaju sa kojim želimo da povežemo

bazu (preko USB-RS232 veze). Prilikom uspešne uspostavljanja serijske veze sa bazom, uređaj

se inicijalizuje i obezbeđuje beleženje u logove. Nudi nekoliko opcija kao što su (Slika 15):

Otvaranje registracionog prozora (eng. Open Registration Window)

Otvaranje registracionog prozora za uređaje koji podržavaju ULE standard (eng.

Open Registration Window ULE Device only)

Otvaranje registracije za dect uređaje (eng. Open Registration Window DECT HS

only)

Service, system (eng. Service, system) -podešavanje servisa za kontrolu baze. Ovde

spadaju kontola EEPROMa, čitanje sa adresa, i čuvanje podataka, zatim uređaji

koji se priključuju kao što su slušalice, baze koje proširuju mrežu, podaci o

pozivima, liniji, imenima uređaja.

Upravljanje pozivima (eng. Call management) – uspostavljanje telefonske veze,

deljenje medija, tonovi za zauzeće, kodek uređaja.

Firmver za unapređenje (eng. Firmware update menu) – svi servisi neophodni za

osvežavanje softvera vezanog za bazu.

Zahtevi zgrade (eng. Facility requests) - Nalaze se uređaji koji emituju signale koji

su zaduženi za uspostavljanje veze, poziva između dect uređaja. Baza koristi

CATiq 2.1. protocol za komunikaciju između uređaja.

Upostavljanje sesije sa uređajima i bazama telefona (eng. Light Data Service), koji

se nalaze u okolini.

Testiranje mogućnosti linija (eng. D&A Tester Menu) – gleda koje veze su

slobodne a koje su zauzete pozivom, i u zavisnosti od zauzetosti mere odabira

odgovarajuće linije.

Osvežavanje softvera bežično (eng. Suota test Menu) – funkcije za osvežavanje

softvera bežično, instaliranja novih verzija softvera na uređajima.

Kalibracija uređaja (eng. Calibration Menu)

Radio transfer protokol (RTP Test Menu) je namenjen za isporuku audio i video

signala preko IP mreže. Koristi se često u prenosu podataka, i sistemima za zabavu.

Provera ispravnosti pristiglih podataka (eng. Checksum Error Test Menu)

Pokretanje servera za kućnu automatizaciju (eng. HAN Test Menu)

Provera audio profila (eng. Audio Test Menu).

Idejno rešenje

26

Slika 15. Izgled komandi po pokretanju host aplikacije

Od svih ponuđenih opcija najbitnija opcija je pokretanje servera za kućnu automatizaciju.

Ovo se može učiniti odmah po pokretanju aplikacija plasiranjem parametra –han. Tada ostale

opcije neće biti pokrenute i direktno će se pokrenuti server koji sluša na adresi 3490. Preko ovog

socketa ostvaruje se komunikacija sa ostalim uređajima, preko aplikacije koja sluša na ovoj

adresi. Aplikacija može da bude na primer serverska aplikacija koja sluša na adresi.

3.1.3 Poco biblioteke

Kao jedno od rešenja za pisanje HAN klijenta koji bi mogao da se koristi na proizvoljnoj

platformi odabrane su Poco biblioteke koje nude širok spektar mogućnosti za pisanje cloud

aplikacija. Neke od mogućnosti koje Poco pruža su sposobnost prilagođavanja različitim

platformama od desktopa do servera : Windows, Linux, Mac OS X, Solaris, HP-UX. Poco ne

isključuje mogućnost pokretanja na nekoj manjoj platformi. Najmanje potrebne sistemske

specifikacije sastoje se od ARM9 procesora sa 8MB rama. Cela biblioteka je licencirana pod

Boost Software License 1.0 što znači da je svaka komercijalna i nekomercijalna upotreba

Idejno rešenje

27

dozvoljena bez naknadnog plaćanja. Jedne od osnovnih osobina koje ove biblioteke imaju je Any

klase koje su zadužene za kastovanje podataka jednostavno iz jednog tipa u drugi. Keširanje

okruženja kao i podrška za događaje je jedna od prednosti ove biblioteke. U kratkim crtama neke

od osnovnih osobina sistema su:

Kompresija – podržava kompresiju i dekompresiju klasa koje se koriste

Kriptografija - kriptografski ključevi, X509 upravljanje sertifikatima, RSA čiperi,

stimovi za enkripciju i dekripciju, bazirano na OpenSSL standardu

Baze podataka – jedinstveni pristup bazama podataka (mySQL, ODBC, SQLite)

Sistemi datoteka - FTP protokoli

Posmatranje grešaka(eng. logging) – okruženje za posmatranje grešaka (podržava

console logging, log files, syslog, remote syslog, Windows event log service)

Multithreading – mogućnost pisanja aplikacija sa više niti

Mreža - stream, datagram, multicast, server and raw sockets su podržani. TCP

okruženje. Podrška za pisanje HTTP klijenta i servera. SMTP i POP3 klijent za

slanje mailova. URI i UUID upravljanje putanjama

Procesi i interprocesorska komunikacija, kao i deljena memorija i resursi

Enkodovanje teksta - UTF-8

XML and JSON - parser za XML (SAX2), DOM parser, JSON parser i formatter.

Za implementaciju ovog rešenja najveći značaj imaju moduli koji podržavaju UDP ili datagram

sockete, kao i moduli koji podržavaju više niti. Zbog ovoga se u sledećem poglavlju pravi kratak

osvrt na funkcionisanje UDP socketa.

3.1.3.1 Udp socketi

Bolji uvid u implementaciju aplikacije može da se postigne ako se ima uvid u

funkcionisanje socket. UDP socket je jedan od načina komunikacije, koji se sastoji od IP adrese i

broja porta slično kao što se telefonska linija sastoji od broja i određenog pozivnog broja.

Socketi ne moraju da imaju adresu, osim u slučaju slanja podataka. Socketi ostvaruju vezu sa

nekim serverom tako sto povezuju (eng. bind) na datu adresu, i onda mogu da primaju podatke

sa date adrese. Primljeni podaci se zatim prosleđuju željenom procesu ili niti. Ovo znači da je

socket karakterisan sa dve stavke [19]:

1. lokalnom adresom socketa

2. protokolom koji može da bude UDP, TCP, ili raw IP. Ovo znači da ako UDP i TCP

socket imaju istu adresu ne znači da su to isti socket

Slika 16 prikazuje vezu sa serverom. Klijent ne uspostavlja odmah vezu sa serverom.

Klijent samo šalje datagram paket preko funkcije sendto [19]. Ova funkcija uzima samo adresu

Idejno rešenje

28

destinacije gde se upućuje datagram. Slično tako i server ne prihvata odmah pakete nego poziva

blokirajuću funkciju recvfrom(), koja čeka da podaci stignu sa klijenta. Ove nativne linux

funkcije su upakovne unutar Poco biblioteke.

Slika 16. Komunikacija preko socketa

3.1.4 Programsko rešenje

U prethodnom poglavlju opisane su Poco biblioteke koji su jedan od ključnih delova aplikacije

jer omogućuju komunikaciju između klijenta i servera unutar aplikacije. U sledećim poglavljima

biće opisan izgled i rešenje same klijentske aplikacije koja ima zadatak da prima podatke sa

HAN servera i obrađuje ih. Aplikacija se sastoji od nekoliko modula različitih uloga prikazanih

na Slici 17:

UDP modul

Parser

Generator poruka (eng. MessageGenerator)

Modul za kontrolu prozora (eng. DoorWindowModule)

Modul za pametnu uičnicu (eng. SmartPlugModule)

Idejno rešenje

29

Svaki od ovih modula zadužen je za jednu funkciju prilikom razmene poruka i biće opisan u

sledećem poglavlju.

Slika 17. Osnovni blok dijagram aplikacije

Udp modul zadužen je za pokretanje UDP klijenta koji sluša na adresi 3490, i dočekuje

podatke poslate u vidu HAN poruka sa baze preko i pomoću HAN servera. Prilikom pokretanja

modula pokreću se dve niti od kojih je jedna zadužena za primanje poruka, a druga za slanje

poruka. Kako je funkcija za primanje poruka blokirajuća, potrebno je postaviti određeni

vremenski interval za primanje odgovora. Ako se odgovor ne primi u određenom intervalu

prelazi se na sledeći korak (slanje poruke na primer).

Parser je zadužen za obradu primljenih podataka sa UDP-a , i smeštanje u posebnu klasu

koja će da sadrži podatke o svim uređajima i njihovim osobinama. Ovako formirana struktura

lako se može smestiti u bazu podataka i čuvati u njoj. Detaljniji opis sledi u narednih nekoliko

poglavlja.

Generator poruka je modul koji ima zadatak da na osnovu parametra koje mu prosleđuje ili

korisnik ili neki od drugih modula generiše poruku u željenom formatu za komunikaciju sa

Idejno rešenje

30

uređajem. Osim određenih zahteva o stanju sistema, generišu se i komande koje mogu da

aktiviraju/deaktiviraju uređaje u sistemu.

Modul za kontrolu prozora prima obaveštenja od parsera da je stanje uređaja za kontrolu

prozora promenjeno, na osnovu događaja koji pristiže u parser u vidu FUN poruke stringa koja

se koristi za obaveštavanje.

Modul za pametnu utičnicu je zadužen da generiše strukture za kontrolu utičnice i da zatim

ove podatke šalje u generator poruka, koji prosleđuje dalje željenu komandu. Takođe može da

šalje komande za proveru trenutnog stanja utičnice, da li je upaljena ili ugašena.

3.1.4.1 Opis modula UDP

Udp modul je direktna veza sa Poco bibliotekama. Unutar njega se deklarišu pozivaju klase

koje su zadužene za pokretanje dodatne niti za slušanje podataka koji se primaju sa UDP

socketa.

Pomoću headera udp.hpp se lako integriše unutar aplikacije.

Opis osnovnih klasa potreban je za razumevanje načina upravljanja Poco bibliotekama.

Klasa Udp sadrži osnovna polja koja se koriste prilikom inicijalizacije uređaja i

započinjanjanja komunikacije.

Poco::Net::DatagramSocket dataSocket – polje

bool isThreadRunning – promenjiva koja proverava da li je već

pokrenut process za slušanje sa porta 3490

UDPclbck_t myUDPrxClbck – funkcija kojoj se prosleđuje metoda iz

aplikacije u kojoj želimo da obrađujemo pristigle podatke

void* myCallbackUserData – pokazivač na funkciju koja se prosleđuje

za slanje podatke

struct MyThreadArg_t – argumenti za nit koja pokreće slušanje sa

porta

class Listener – klasa za pokretanje slušanja porta i

primanja podataka sa njega. Ova klasa nasleđuje klasu Poco::Runnable koja je zadužena

za prosleđivanje parametara klasi Thread koju Poco sadrži specijalno za pokretanje

dodatnih niti.

Metode klase koje se koriste:

start – Klasa za startovanje UDP porta i započinjane parsiranja i obrade podataka

Idejno rešenje

31

o parametri:

const string& _addr – adresa servera

unsigned short _port – port

o povratna vrednost: Err_Code_t

stop – Klasa za zatvaranje veze sa serverom i udruživanje niti zaduženih za slanje i

slušanje, prima adresu i port soketa koji želimo da zatvorimo

o parametri:

const string& _addr – adresa servera

unsigned short _port – port


registerRxCallback – Klasa za startovanje UDP porta i otvaranje

o parametri

UDPclbck_t _myCallback – funkcija koja se poziva kada informacija

pristigne na UDP port

void * userData – u slučaju da se funkciji treba još neka vrsta podataka

proslediti, kao na primer proizvoljni string


sendToUDP – Klasa za slanje sting na adresu i port koji su prethodno podešeni

o parametri:

string _data - proizvoljni string


3.1.4.2 Opis modula parser

Parser je kreiran kao modul koji obrađuje stringove koje dobija sa UDP-a. Osnovni izazov

prilikom kreiranja ovog mogula svodi se na smeštanje podataka u strukture koje će da sadrže sve

informacije o uređajima. Takođe problem se svodio na menjanje atributa i interfejsa prilikom

pristizanja novih događaja koji izveštavaju o promenama na uređajima. Zbog toga moralo se

pribeći dodavanju interfejsa koji su obevezni jer se informacija o njima se ne može dobiti iz

tabele uređaja ili preko komande koja izveštava o osnovnim informacijama o jednom određenom

uređaju . Slika 18. prikazuje osnovni tok funkcionisanja parsera.

3.1.4.2.1 Strukture i klase

Idejno rešenje

32

Dev_Info_t - struktura koja omogućava slanje osnovnih informacija o uređajima kroz

povratnu funkciju

int dev_id - identifikator uređaja

int unit_id - identifikator jedinice

int interf_id - identifikator interfejsa

int attr_id - identifikator atributa

int value - vrednost atributa

Slika 18. Tok rada parsera

Command_Type_t - enumeracija zadužena za beleženje tipa povratnog događaja. Poseduje

nekoliko tipova:

EVENT - događaj koji pristiže sa uređaja, najčešće kao deo odgovora na

AttributeReporting interfejs

RESP - odgovor na neku komandu kao što je na primer INIT,

DEV_DELETED.

ATTR_CHANGE - promena koja se dešava u nekom interfejsu, kada dobijamo

komandu direktno od interfejsa

Idejno rešenje

33

Command_Value_t - Predstavlja deo komande gde se javlja uspešnost inicijalizacije, brisanja ili

registrovanja uređaja

NOT_DEFINED - komanda nije definisana

FAIL - greška u komandi koja je primljena

SUCCESS - uspešno primljena i parsirana poruka

Command_Name_t - definiše ime poslednje komande koja je poslata. Za sada poseduje sledeće

vrednosti

INIT - inicijalizacija uređaja

REG_OPEN - otvaranje registracionog prozora

REG_CLOSE - zatvaranje registracionog prozora

DEV_DELETED - brisanje uređaja

DEV_TABLE - pristigla tabela uređaja

DEV_REGISTERED - registovan novi uređaj

DEV_INFO - informacija o uređaju

FUN_MSG - informacije o uređajima se plasiraju kroz ovu strukturu

Access_Type_t - definiše operacije nad atributima nekog interfejsa

READ - dozvoljeno samo čitanje u atributa ili interfejsa

WRITE - dozvoljen upis u atribut ili interfejs

READWRITE - dozvoljen upis i čitanje u atributa ili interfejsa

3.1.4.2.2 Klase

Attribute - sadrži osnovna polja za opis nekog atributa interfejsa

int attr_id - identifikator atributa

string attr_name - ime atributa

U_type_t attr_type - tip attributa tj dužinu u bajtovima

Access_Type_t attr_access - operacije nad atributom

int attr_value - vrednost atributa

Interface - osnovna klasa za opis interfejsa

int interf_type - tip interfejsa , klijent ili server

int interf_id - identifikacioni broj

vector<Attribute> inter_attrib - lista atributa koje interfejs poseduje

Unit - klasa koja opisuje jedinicu. Polja klase su:

Idejno rešenje

34

int unit_id - identifikator

int unit_type - tip jednince( Alert, DoorWindow...)

int no_of_interf - broj interfejsa

vector<Interface> interfs - lista interfejsa smeštena u vektor

Device - klasa koja opisuje jednu instancu uređaja.

int id - identifikator

string ipui - serijski broj

string emc - mašinski kod uređaja

int no_of_units - broj jedinica uređaja

vector<Unit> units - lista jedinica

ReceivedCommand- klasa koja sadrzi poslednju primljenu komandu

Command_Type_t type- poslednja komanda može da bude Event, Attribute Change, or

Responce

Command_Value_t value - vrednost te komande ili da li je uspešno izvršena

Command_Name_t name - ime komande

vector<Device> table - tabela uređaja koja se popunjava u slučaju da se pozove

komanda za dobavljanje spiska uređaja ili promene atributa

FunMessage - klasa u slučaju da korisnik želi da ima informaciju o poslednjoj FUN poruci sa

UDP-a. Putem ovog servisa se obaveštava o svim događajima u sistemu (pritiscima, menjanjima

stanja itd).

int srcDevId - Indentifikator pošiljaoca poruke

int srcUnitId - Identifikator jedinice pošiljaoca

int dstDevId - Indentifikator primaoca poruke

int dstUnitId - Identifikator jedinice primaoca

int dstAdressType - Adresa prijemnika

int msgTransport - Način prenosa poruka

int msgSeq - Redni broj poruke

int msgType - Tip poruke, 0/1 klijent/server

int intrfType - Tip interfejsa

int intrfId - Identifikator interfejsa

int intrfMember - Član interfejsa

Idejno rešenje

35

int dataLen - Dužina podataka koji slede u polju data

string data - Podaci(informacija o uređaju, promena atributa)

Parser - klasa koja ima zadatak da parsira sve podatke. Pomoću njenih metoda pristigli string se

smešta u polja u tabeli gore navedene strukture (Slika 18).

Javna polja klase Parser su:

ReceivedData getData(ReceivedData receivedData) - dobavlja sve podatke

koji su pristigli u parser

vector<Device> getTableOfDevices - dobavlja za listu uređaja privatnog

polja

ReceivedData receivedData - primljeni podaci

void start(string) - uzima string i započinje čitanje

podataka i smeštanje u odgovarajuća polja strukture

ErrCode_t registerDoorWindowCallback(DoorWindowclbck_t

_myCallback) - registacija callbacka koji se

prosleđuje dalje modulime

Privatne metode i polja klase su:

DoorWindowclbck_t doorWindowCallback - polje za događaj koji pristiže sa senzora za prozor

ReceivedData receivedData - polje za primljenje podatke, bilo da su po to poruke o

inicijalizaciji, registraciji, promeni interfejsa uređaja

FunMessage fun - polje za parsiranu Fun poruku, koja nosi osnovni opis o promeni atributa

uređaja interfejsa

resInit - pokreće se kada se prepozna odgovor na init komadu. Prima podatke u stringu i

smešta ih pomoću pokazivača menjamo polje data tipa ReceivedData koje sadrži informaciju o

poslednjoj komandi. Preko ErrCode_t vraća da li je uspešno ili neušpešno pročitana i smeštena

komanda.

parametri: string, ReceivedData *data

povratna vrednost: ErrCode_t

Idejno rešenje

36

resOpen - Poziva se kada se prepozna komada za otvaranje registracionog prozora. Javlja

uspeh ili neuspeh kroz polje Command_Value_t value

parametri: string str, ReceivedData data


resClose - Poziva se kada se prepozna komada za zatvaranje registracionog prozora. Javlja

uspeh ili neuspeh kroz polje Command_Value_t value.

parametri: string str

povratna vrednost:

resDevTable - čuva listu uređaja u internoj tabeli, kada dobije ovu vrstu odgovora na portu.

Svi podaci se smeštaju pomoću pokazivača u promenjivu klase ReceivedData. U slučaju greške

javlja se neuspeh, kroz povratnu vrednost ErrCode_t.



resDevInfo - poziva se kada se traži informacija o nekom uređaju. Prosleđeni parametri

predstavljaju pokazivač na podatke o kojima se čuvaju informacije o uređajima, i string komande

koja se parsira.

parametri: string, ReceivedData *


resDevDeleted - briše uređaj iz tabele koja je ranije pozvana. U slučaju da komanda koja

dobavlja spisak uređaja nije pozvana ili uređaj ne postoji u tabeli greška se vraća preko povratne

vrednosti.



resDevRegistered - javlja kada se uređaj uspešno registruje. Tabela uređaja koja se čuva se

dopunjava uređajem, u slučaju da on već ne postoji u tabeli. Ako postoji javlja se greška kroz

povratnu vrednost.



readsFunData - vraća parsiran objekat poruke unutar polja FunMessage

Idejno rešenje

37

parametri: vector char


line_parsing.cpp - sadrži pomoćne funkcije za čitanje i lakše parsiranje

readLine - čita liniju iz prosleđenog stringa

parametri: string

povratna vrednost: string

deleteLine - briše liniju iz stringa koji se prosleđuje da se pročita.

parametri:string str

povratna vrednost:

readCommand - čita komandu iz linije koja se prosleđuje


povratna vrednost:

readValue – iz linije koja se prosleđuje čita vrednost i javlja grešku ako vrednost nije u

pravom formatu.

parametri:string


convertToInt - konvertuje string u integer tj decimalnu vrednost


povratna vrednost:

convertToString - konvertuje integer u string

parametri:int number


convertHexToDec - konvertuje sting koji je dat heksadecimalno u integer


povratna vrednost: int

check - proverava poklapanje komande i prosleđenog stringa (compare_string). Javlja

poklapanje ili ne kroz povratnu vrednost

Idejno rešenje

38

parametri: string command, string compare_string

povratna vrednost: bool

device.cpp sadrži sve metode koje su potrebne za parsiranje uređaja interfejsa i komandi

readInterfaces - čita interfejse iz prosleđenog stringa str


povratna vrednost: Interface

readUnit - čita jedinice iz prosleđenog stringa i vraca ih.

parametri:string

povratna vrednost: Unit

removeDevice uklanja uređaj iz sačuvano vektora uređaja u slučaju da pristigne podatak da je

uređaj obrisan iz memorije baznog uređaja

parametri: vector<Device> &device


interfaces.cpp - sadrži listu dodatih podrazumevanih interfejsa za jedinice koji su obavezni.

Informacije o njima se nalaze u dokumentaciji, a proizvođač ne nudi tu mogućnost da se vide ili

vrate u tabeli preko UDP porta.

addMandatoryInterfaces u slučaju da su obavezni interfejsi sakriveni (po podrazumevanom

podešavanju proizvođača) vraća se spisak uređaja koji sadrži obavezne interfejse, koji se dodaju

pomoću ove metode.

parametri:vector<Device> &device


findMandatoryInterface iz identifikacionog broja jedinice pronalazi se koji se interfejs mora

dodati. U slučaju greške vraća grešku kroz enumeraciju ErrCode_t.

parametri:int unit_id


resFunMsg - parsira podatke dobijene u data polju fun poruke. U slučaju greške vraća grešku

kroz povratnu vrednost ErrCode_t.

parametri:string, FunMessage fun, ReceivedData &data

Idejno rešenje

39


changeAttrData - u podacima koji se parsiraju prepoznaje se promena na uređaju i zatim se

na osnovu parametara kao što su identifikator uređaja, jedinice, interfejsa, atributa, i vrednosti

koja je isparsirana menja polje data, i čuva trenutno stanje uređaja

parametri:int dev_id, int unit_id, int interf_id, int attr_id, int value,

ReceivedData &data

povratna vrednost

parseAlert - kada se primi poruka u formi upozorenja (eng. alert)

parametri:string mesg, ReceivedData data, FunMessage fun

povratna vrednost:

parseAttributeChange - u slučaju da je prepoznata promena atributa ova klasa se poziva

parametri: string &s, ReceivedData &data, FunMessage message


parsePowerReporting - smeštanje promene atributa koji opisuje snagu uređaja opisana kroz

Power Reporing servis

parametri:string &s, ReceivedData &data, FunMessage message


3.1.4.3 Opis modula message generator

Ova struktura predstavlja jednostavan generator koji se koristi da se poruke šalju na UDP

port dalje ka bazi tj uređajima preko dect veze.

reqInit – na izlazu daje string kojim se uređaj inicijalizuje

parametri: int version


reqOpenReg – vraća string kojim se otvara registracioni prozor

parametri: int time


Idejno rešenje

40

reqCloseReg – vraća string kojim se zatvara registracioni prozor

parametri: int time


reqRegister – vraća sting kojim se proverava da li je uređaj sa željenim identifikatorom

registrovan

parametri int dev_id


reqGetDevTable – prosleđivanjem identifikatora tabele i broja elemenata

parametri: int dev_id, int how_many


reqGetDevInfo – kreira string kojim se zahteva informacija o uređaju sa željenim

identifikatorom koji se prosleđuje kao parametar

parametri: int dev_id


reqDeleteDev - prosleđuje komandu za brisanje uređaja, datog identifikatora

parametri: int dev_id


reqFunMsq – prosleđuje FUN poruku kroz strukturu, koja sadrži polja koja će se kasnije

proslediti kroz string koji se salje na UDP port. Ovim se može kontrolisati rad uređaja tj paliti ili

gasiti uređaji, slati različite komande za dobavljanje stanja itd.

parametri: FunMessage_t msg


Rezultati merenja

41

4. Rezultati testiranja

Prilikom testiranje efikasnosti protokola potrebno je da se razmotri efikasnost slanja

poruka preko njega. Kao jedan od parametara razmatra se i jačina signala koji je glavni indikator

kvaliteta transmisije. Osim ovog važno je razmotriti i proj uspešno pristiglih poruka u funkciji od

razdaljine od uređaja. U ovom poglavlju razmatraju se bitni podaci vezani za kvalitet DECT

protokola.

Veliki uticaj na kvalitet veze predstavlja i sredina kroz koju se prostire signal. Tabela 5

daje uporedni prikaz materijala i njihovog stepena atenuacije. Osim ovoga šumovi i okolni

uređaji su glavni razlog neuspelog slanja i uspostavljanja veze. Što se tiče frekvencijskog opsega

u Srbiji prema poslednjem izveštaju najbliži nosilac GSM DST 1800 ima poslednji nosilac na

frekvenciji 1879.8 Mhz., što ne bi trebalo da predstavlja problem, jer prvi nosilac DECT-a nalazi

se na frekvenciji 1880Mhz [20].

Materijal Stepen atenuacije

Vazduh Mala

Drvo Mala

Plastika Mala

Staklo Mala

Živa stvorenja Srednji

Cigle Srednji

Gips Srednji

Keramika Srednji

Zid Visok

Metal Visok

Tabela 5. Spisak materijala i stepena atenuacije

Rezultati merenja

42

4.1 Merenje u zatvorenom prostoru

Ova vrsta merenja sprovodi se unutar zgrada i pokazatelj je kako se kreće i menja signal

kada se susreće sa preprekama kao što su zidovi, gips, cigle, staklo. Bitan je kao pokazatelj kako

se kreće jačina signala i do koje razdaljine je signal dovoljno dobar da bi mogao da prenosi

signal.

4.1.1 Snaga signala

Snaga signala je mera kvaliteta transmisije. U radio i telefonskoj industriji ova vrednost se

najčešće izražava u dBm koji ustvari predstavlja snagu u odnosu na impedansu antene koja je

najčešće 50Ω. Veoma dobra snaga prijema definiše se do -50dBm. Kvalitet signala opada sa

razdaljinom ali je i dalje dobar do vrednosti od -60dBm. Za uređaje koji prenose podatke, ali ne i

zvuk prihvatljiva je vrednost do -70dBm. Sve vrednosti ispod ove smatraju se za loše vrednosti,

neodgovoravajuće za transmisiju [21].

Grafik 1. Prikaz RSSI u zavisnosti od rastojanja u zatvorenom prostoru

Prilikom merenja razmatrana je jačina sa dva uređaja, koja sadrže antene za dect protokol.

Jedan od čvorova je bio AN171-2 SmartPlug koji sadrži, osim prijemnika za bežično

uključivanje i isključivanje, i trenutnu potrošnju u vatima. U slučaju preopterećenja mreže

automatski se isključuje da zaštiti potrošač od havarije.

Drugi čvor je bežična utičnica pod oznakom AN170-2 ili jednostavno AcPlug. Podržava

potrošače snage 3500 W, i ne poseduje posebne funkcije osim bežičnog paljenja i gašenja

uređaja.

-80

-70

-60

-50

-40

-30

-20

-10

0

5 10 20 30

RSS

I (d

Bm

)

rastojanje od baze (m)

AcPlug

SmartPlug

Rezultati merenja

43

Sa Grafik 1. se vidi da AcPlug ima slabiji signal od SmartPlug iako su u oba slučaja bili

identični uslovi merenja i udaljenost od baze. Merenje je odrađeno u realnim uslovima. Signal

opada sa rastojanjem, skoro linearno. Uzroci koji mogu da ometaju kvalitet prijema su odbijanje

i refleksija o površine koje su neprovodne.

Svi uređaji koji rade na stalno napajanje u vidu naizmenične struje, mogu da vraćaju

informaciju o jačini signala(eng. RSSI). Ova veličina opisuje ukupnu snagu u milivatima, a

rezultat se najčešće izražava preko logaritamske skale u dBm sa negativnim znakom. Ovaj signal

je pokazatelj da li je dovoljno jaka veza da se sigurno prenesu informacije. Što je signal bliži 0 to

je veza bolja. Ovaj indikator varira od proizvođača do proizvođača što se može videti u

merenjima [22].

Da bi se standardna devijacija merenja koristila se metoda najmanjih kvadrata po formuli (1):

(1)

gde je s standardna devijaci dok je n broj merenja, je merni uzorak dok je srednja

aritmetička sredina svih merenja [22] . Ona određuje kvalitet merene veličine

5m 10m 20m 30m

AcPlug(dBm) -39.94± 4.20 -46.7± 2.19 -57.52± 3.22 -72.12± 3.39

SmartPlug (dBm) -24.38± 1.34 -35.28 ±0.89 -37.48± 2.27 -40.32 ±1.81

Tabela 6. Prikaz vrednosti signala i standardne devijacije merenja

U Tabeli 6 nalazi se prikaz srednjih vrednosti jačine signala kao i standardne devijacije

merenja. Znajući da se srednja snaga radijacije u dBm izračunava po formuli

Što ako se prevede u W za primer od 5m, vidimo da je prosečna snaga emitovanja

ili .

Rezultati merenja

44

4.1.2 Kvalitet veze

Osim ovoga bitno je razmotriti i broj pristiglih paketa sa uređaja. Ovaj parametar je dobro

posmatati u odnosu na prijemnu moć uređaja. Kvalitet veze se može razmotriti posmatranjem

paketa koji su vraćeni.

5m 10m 20m 30m

ACPlug 100% 100% 100% 100%

SmartPlug 100% 100% 100% 100%

Tabela 7. Prikaz procenta primljenih paketa unutar zgrade

Kvalitet veze koji pokazuju uređaji je veoma dobar bez obzira na jačinu signala koja u

slučaju 30m razdaljine dostiže u slučaju ACPluga i do -75dBm, jer su svi primljeni paketi i

vraćeni.

4.2 Merenje na otvorenom prostoru

Merenja na otvorenom obavljena su iscrpnije nego u zatvorenom prostoru sa više uzoraka

jer je cilj bio da se utvrdi kada zaista jačina signala opada, toliko da je nemoguće da se uspostavi

veza. Prema specifikacijama proizvođača stoji da doseže do 300m. Međutim uslovi merenja koja

proizvođač navodi, zahtevaju sredinu, bez bilo kakvih smetnji i predmeta koji apsorbuju signale.

Ovu uslovi nisu bili potpuno realni, posebno za gradsku sredinu gde signali svakako i na

otvorenom moraju da imaju prepreke poput zidova zgrada. U sledećim poglavljima biće opisan

način merenja na otvorenom koji je sproveden

4.2.1 Snaga signala

Merenja su sprovedena na gorenavedenim uređajima, a to su pametna utičnica za merenje

potrošnje i bežičnu kontrolu SmartPlug i ACPlug pametna utičnica za bežičnu kontorolu.

U ovom slučaju merenja su vršena do momenta kada baza više ne može da se poveže i

pošalje paket koji uređaj vraća zajedno sa informacijom o RSSI. Na sledećem grafikonu (Grafik

2.) se vidi izgled signala koji opada sa udaljavanjem uređaja od baze. Tabela 8 je spisak srednje

vrednosti i standardne devijacije merenja RSSI vrednosti snage signala.

Rezultati merenja

45

Grafik 2. Zavisnost RSSI od rastojanja – merenje na otvorenom

Na slici se vidi da signal ne opada ravnomerno, nego povremeno ima veći pad. Jedan od većih

padova signala vidi se između 35 i 40 m razaljine kada se nalazi na prvu preprepreku u vidu

zida. Ovde koeficijent pada iznosi -2.57dBm/m. Na Slici 19. se može videti površina gde su

izvršena merenja, gde su plave tačke položaji uređaja u toku merenja a crvena tačka položaj

baze.

Slika 19. Izgled površine na kojoj je meren signal

-80

-70

-60

-50

-40

-30

-20

-10

0

5 10 15 20 25 30 35 40 45 50 55 60

RSS

I (d

Bm

)

rastojanje od baze(m)

AC Plug

Smart Plug

5 10 15 20 25 30 35 40 45 50 55 60

AC Plug -41.02 ± 1.41

-47.55 ±1.58

-46.27 ±1.48

-46.27 ±1.48

-51.55 ±4.27

-56.85 ±5.01

-58.75 ±2.42

-71.60 ±3.52

-71,00 ±0

-71,00 ±1.73

-75.85 ±0.99

Smart Plug

-28.85 ±2.73

-34.72 ±1.20

-36.60 ±1.44

-36.77 ±1.72

-37,00 ±1.37

-41.10 ±0.79

-41.77 ±1.49

-40.35 ±7.13

-44.07 ±1.52

-42,00 ±0

-42,00 ±0

-46.10 ±1.83

Tabela 8. Srednja vrednost i standardna devijacija merenja na otvorenom prostoru

Rezultati merenja

46

Sa Slike 19 se vidi se da na rastojanju od 60m SmartPlug gubi kontakt sa bazom, baza ga

registruje međutim nije u mogućnosti da pošalje paket zbog slabog signala. Za AC Plug jačina

signala opada mnogo strmije i već na 55m od baze gubi se kontakt sa bazom. Jedan od razloga

što SmartPlug može 5m dalje da dosegne, svakako leži u boljem predajniku, koji je ovde ugrađen

da bi se mogla slati informacija o potrošnji, kao i o stanju utičnice (upaljena ili ugašena).

4.2.2 Kvalitet veze

U ovom slučaju pošto su testovi odrađeni do trenutka kada se gubi veza sa bazom iz

rezultata vidi se da se posle 55m za SmartPlug i 50m za AcPlug gube paketi. U Tabeli 9. se vidi

procentualno prikaz primljenih paketa u odnosu na ukupan broj paketa koji je konstantan. Paketi

se ne gube do 40m rastojanja, kada može da dođe do gubljenja jednog paketa ili više paketa u

zavisnosti od smetnji. Broj poslatih paketa je 40, i da bi se znalo da je paket primljen na uređaju

šalje se nazad bazi potvrda da je primljen, zajedno sa RSSI informacijom.

Tabela 9. Prikaz primljenih paketa u odnosu na ukupan broj paketa

5 10 15 20 25 30 35 40 45 50 55 60

SmartPlug 100% 100% 100% 100% 100% 100% 100% 97,50% 100% 97,50% 95% 92,50%

AC Plug 100% 100% 100% 100% 100% 100% 100% 100% 100% 98% 95% 0%

Zaključak

47

5. Zaključak

Danas, kada su na raspolaganju veliki izbor protokola za bežičnu komunikaciju među

uređajima, važno je osvrnuti se na već postojeće protokole koji su korisnicima na raspolaganju u

kući, a pritom mogu da se iskoriste za kućnu automatizaciju. Cilj ovog rada bio je da se osvrne

na DECT protokol koji je dostupan naveliko u telefonskoj industriji, a mnogo manje u industriji

vezanoj za kućnu automatizaciju. Osim ovoga pokazalo se kao dobro i ne tako složeno rešenje i

prilagođenje ovih uređaja na bilo koji mrežni procesor, sa jedinim uslovom da poseduje USB

konektor, i minimalno 8MB rama. Programsko rešenje je implementirano uspešno sa funkcijama

koje su opisane u prethodnim poglavljima. Ono na šta bi se trebalo obratiti pažnja je veličina

aplikacije mada u ovom slučaju ona ne prelazi 4,4Mb.

Kao još jedno od prednosti DECT protokola pokazao se i njegov domet, koji je testiran

unutar poglavlja sa rezultatima. Protokol funkcioniše i do 30m bez interferencije i uticaja

ostalnih bežičnih uređaja, što je vrlo značajno. Testovi su rađeni u realnim uslovima unutar

zgrade gde postoje uređaji koji emituju WIFI, Bluetooth, i ostale bežične protokole. Svakako

mogu da se rezultati poboljšaju, i da se vidi rezultat koji ima šum ako se detaljnije i iscrpnije

testiranje samog protokola izvrši. Za ove vrste testiranja moraju da postoje i posebni uslovi koji

su definisani u standardu namenjenom testiranju protokola [21]. Međutim testiranje koje je

sprovedeno pomaže korisniku uređaja da stekne uvid o granicama samog protokola i koliko

daleko sme da postavi bazu od uređaja.

Kao pravaca daljeg istraživanja, potrebno je da se osvrne na proširivanje HAN protokola

na još neke funkcije koje baza pruža a nisu definisane, unutar protokola. Osim ovoga svakako

cilj je da se nastavi sa pisanjem aplikacije dodavanjem različitih funkcionalnosti (grafičke

sprege) ili pak integracija u već postojeću aplikaciju za kućnu automatizaciju, komunikacija sa

drugim uređajima koji ne podržavaju DECT. Jedan osvrt bi se mogao napraviti i ka smanjenju

Zaključak

48

aplikacije izbacivanjem nepotrebnih servisa koji se ne koriste (telefonskih, VoIP…), ili pak ka

proširenju integracijom ovih servisa u veći sistem senzora, i na kraju integracijom na cloud i

pristupanjem preko interneta, što je olakšano izborom biblioteka koje podržavaju mrežne servise,

unutar već postojećeg rešenja.

Literatura

49

6. Literatura

[1] ETSI Standard http://www.etsi.org/standards-search#Home & Office

[2] ETSI Standard 2013 Dect Protocol

http://www.etsi.org/deliver/etsi_tr/103000_103099/103089/01.01.01_60/tr_103089v010

101p.pdf

[3] Panasonic Wireless DECT protocol

http://www.telecomuserguides.com/manuals/filesupload/Panasonic/wireless-

phones/What_is_DECT.pdf, pristupano 20.6.2016

[4] ULE Technology Whitepaper

http://www.ulealliance.org/downloads.aspx?c=w, pristupano 20.6.2016

[5] Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI); Part

3: Medium Access Control (MAC) layer

http://www.etsi.org/deliver/etsi_en/300100_300199/30017503/02.02.00_40/en_300175

03v020200o.pdf pristupano 29.6.2016

[6] Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI); Part

3: Medium Access Control (MAC) layer


03v020200o.pdf pristupano 29.6.2016

[7] Integrated Services Digital Network (ISDN); Digital Subscriber Signalling System No.

one (DSS1) protocol; Signalling network layer for circuit-mode basic call control; Part

1: Protocol specification,


01v010201c.pdf , pristupano 29.6.2016

[8] W.H. Turttlebee, Cordless Telecomunication Worldwide:The Evolution of Unlicensed

PCS, Springer Science & Business Media, 2012

http://www.etsi.org/deliver/etsi_tr/103000_103099/103089/01.01.01_60/tr_103089v010101p.pdf

http://www.etsi.org/deliver/etsi_tr/103000_103099/103089/01.01.01_60/tr_103089v010101p.pdf

http://www.telecomuserguides.com/manuals/filesupload/Panasonic/wireless-phones/What_is_DECT.pdf

http://www.telecomuserguides.com/manuals/filesupload/Panasonic/wireless-phones/What_is_DECT.pdf

http://www.ulealliance.org/downloads.aspx?c=w

http://www.etsi.org/deliver/etsi_en/300100_300199/30017503/02.02.00_40/en_30017503v020200o.pdf

http://www.etsi.org/deliver/etsi_en/300100_300199/30017503/02.02.00_40/en_30017503v020200o.pdf

http://www.etsi.org/deliver/etsi_en/300100_300199/30017503/02.02.00_40/en_30017503v020200o.pdf%20pristupano%2029.6.2016

http://www.etsi.org/deliver/etsi_en/300100_300199/30017503/02.02.00_40/en_30017503v020200o.pdf%20pristupano%2029.6.2016

http://www.etsi.org/deliver/etsi_en/300400_300499/30040301/01.02.01_20/en_30040301v010201c.pdf

http://www.etsi.org/deliver/etsi_en/300400_300499/30040301/01.02.01_20/en_30040301v010201c.pdf

Literatura

50

[9] Home Area Network Functional (HAN-FUN) Protocol, ULE Alliance Standard, V1.3.0

2016

[10] Home Area Network Functional Profile Version, ULE Alliance Standard, V1.3.0 2016

[11] Home Area Network Functional (HAN-FUN) Core Services and Interfaces, ULE

Alliance Standard, V1.3.0 2016

[12] DSP HAN Overview 2013, DSP Group.

[13] Digital Enhanced Cordless Telecommunications (DECT); New Generation DECT; Part

3: Extended wideband speech services

http://www.etsi.org/deliver/etsi_ts/102500_102599/10252703/01.03.01_60/ts_1025270

3v010301p.pdf, pristupano 28.6.2016

[14] DECT ULE Security Overview, DSP Group

[15] Digital Enhanced Cordless Telecommunications (DECT); Ultra Low Energy (ULE);

Machine to Machine Communications; Part 1: Home Automation Network (phase 1),

TS 102 939-1



[16] Digital Enhanced Cordless Telecommunications (DECT); Ultra Low Energy (ULE);

Machine to Machine Communications; Part 2: Home Automation Network (phase 2),

TS 102 939-2,



[17] Connecting the DCX81 CMBS to the network, Rev2

[18] DHX91 DHAN Module DECT-ULE Platform http://www.dspg.com/wp-

content/uploads/DHX91-DHAN-Module.pdf pristupano 28.6

[19] W. Richard Stevens, Bill Fenner, Andrew M. RUNIX Network Programming Volume

1, Third Edition: The Sockets Networking API

[20] Pravilnik o utvrđivanju Plana raspodele frekvencija za rad u radiofrekventnim opsezima

1710-1788/1805-1880MHz

http://www.ratel.rs/upload/editor_files/File/Regulativa/Plan%20raspodele%20za%20GS

M.pdf , pristupano 11.7.2016

[21] Digital Enhanced Cordless Telecommunications (DECT); Test specification; Part 1:

Radio



http://www.etsi.org/deliver/etsi_ts/102500_102599/10252703/01.03.01_60/ts_10252703v010301p.pdf






http://www.dspg.com/wp-content/uploads/DHX91-DHAN-Module.pdf

http://www.dspg.com/wp-content/uploads/DHX91-DHAN-Module.pdf

http://www.ratel.rs/upload/editor_files/File/Regulativa/Plan%20raspodele%20za%20GSM.pdf

http://www.ratel.rs/upload/editor_files/File/Regulativa/Plan%20raspodele%20za%20GSM.pdf

http://www.etsi.org/deliver/etsi_en/300100_300199/30017601/02.01.01_60/en_30017601v020101p.pdf

http://www.etsi.org/deliver/etsi_en/300100_300199/30017601/02.01.01_60/en_30017601v020101p.pdf

Literatura

51

[22] M. Sauter, From GSM to LTE: An Introduction to Mobile Networks and Mobile

Broadband , John Wiley & Sons.ISBN 9780470978221, 2010.

[23] V. Bego, Mjerenja u elektrotehnici, Tehnička knjiga Zagreb, 1975, četvrto izdanje

http://books.google.com/books?id=uso-6LN2YjsC&lpg=PA160&dq=received%20signal%20strength&pg=PA160#v=onepage&q=received%20signal%20strength&f=false

http://books.google.com/books?id=uso-6LN2YjsC&lpg=PA160&dq=received%20signal%20strength&pg=PA160#v=onepage&q=received%20signal%20strength&f=false

https://en.wikipedia.org/wiki/John_Wiley_%26_Sons

https://en.wikipedia.org/wiki/International_Standard_Book_Number

https://en.wikipedia.org/wiki/Special:BookSources/9780470978221

Интеграција dect ule протокола у систем паметних кућа

Documents