UPORABA STANDARDA TR-069 NA VoIP PRODUKTU · ABSTRACT The aim of the thesis is to show the software...

Diplomsko delo visokošolskega strokovnega študija Informatika v organizaciji in managementu

UPORABA STANDARDA TR-069 NA VoIP PRODUKTU

Mentor: doc. dr. Borut Werber Kandidat: Branko Zebec

Kranj, marec 2016

ZAHVALA Zahvaljujem se mentorju doc. dr. Borutu Werberju za pomoč in nasvete pri izbiri vsebin in sestavi moje diplomske naloge. Zahvaljujem se tudi lektorici Marjetki Vidovič, ki je lektorirala mojo diplomsko nalogo. Posebna zahvala velja moji ženi Lidiji, hčerki Juliji in sinu Maticu, ki so me vzpodbujali v času študija.

POVZETEK Namen diplomskega dela je prikazati programsko rešitev za podporo protokola TR-069 na VoIP (govor prek IP) produktu. TR-069 protokol je namenjen upravljanju omrežne naprave z avtokonfiguracijskega strežnika. Problem, zaradi katerega smo morali narediti programsko rešitev protokola TR-069 na VoIP produktu, je v kupčevi zahtevi po tej funkcionalnosti. S tem je bilo pogojeno obstoječe in nadaljnje sodelovanje z njim. V diplomski nalogi smo prikazali razvojne postopke, s katerimi smo dosegli delujočo funkcionalnost TR-069 na VoIP napravi. Razvojni postopki so bili zahtevni in so zahtevali veliko znanja in časa. Programska rešitev omogoča posodobitev VoIP produkta, s katero zadovoljimo kupca in omogočimo prodajo VoIP naprav. Ugotovili smo, da je zaradi TR-069 funkcionalnosti VoIP produkt postal bolj zanimiv tudi za druge kupce. S podporo protokola TR-069 na VoIP produktu smo dosegli njegovo večjo konkurenčnost. KLJUČNE BESEDE:

• programska rešitev • omrežne naprave • protokol • strežnik • VoIP • SOAP

ABSTRACT The aim of the thesis is to show the software solution for the support of the TR-069 Protocol on a VoIP (voice-over-IP) product. The TR-069 Protocol is intended to manage network devices from the Auto-Configuration Server. The reason for the software solution establishment of the TR-069 Protocol for the VoIP product was a customer's demand for this functionality. Our current and future cooperation depended on it. In the thesis, we presented the development processes which helped us to achieve the funtionality of TR-069 on the VoIP device. The development processes were complex and required a lot of knowledge and time. The software solution enables an update of the VoIP product which satisfies the customer and makes the VoIP devices possible to be sold. We have found out that due to the TR-069 functionality, the VoIP product became more interesting for other customers, too. With the TR-069 Protocol support on the VoIP product we have increased its competitiveness. KEYWORDS:

• software solution • network devices • protocol • server • VoIP • SOAP

KAZALO 1. UVOD ................................................................................................................. 1

1.1. PREDSTAVITEV PROBLEMA .......................................................................... 1

1.2. CILJI IN NALOGE ......................................................................................... 2

1.3. PREDPOSTAVKE IN OMEJITVE ...................................................................... 2

1.4. METODE DELA ............................................................................................. 3

1.4.1. Razvojni mejnik B100 .......................................................................... 3



2. OSNOVE ............................................................................................................. 7

2.1. TR-069 ........................................................................................................ 7

2.1.1. Osnovni opis ........................................................................................ 7

2.1.2. Transakcija ......................................................................................... 7

2.1.3. Vzpostavitev transakcijske seje .......................................................... 8

2.1.4. Dogodki ............................................................................................... 9

2.1.5. Začetna vzpostavitev CPE na ACS ..................................................... 10

2.1.6. Periodična vzpostavitev CPE seje ..................................................... 10

2.1.7. TR-069 sporočilo GetRPCMethods ..................................................... 11

2.1.8. TR-069 sporočilo Reboot ................................................................... 12

2.1.9. TR-069 sporočilo FactoryReset .......................................................... 13

2.1.10. TR-069 sporočilo Download ........................................................... 14

2.1.11. TR-069 sporočilo Upload ................................................................ 15

2.1.12. TR-069 sporočilo SetParameterValues ........................................... 16

2.1.13. TR-069 sporočilo GetParameterValues .......................................... 17

2.1.14. TR-069 sporočilo GetParameterNames .......................................... 18

2.1.15. TR-069 sporočilo AddObject .......................................................... 19

2.1.16. TR-069 sporočilo DeleteObject ...................................................... 20

2.1.17. Sporočilo Cookie ............................................................................ 21

2.1.18. Sporočilo za neuspešno izvedeno RPC funkcijo ............................. 21

2.2. SOAP ........................................................................................................ 22

2.3. WSDL ........................................................................................................ 23

2.4. gSOAP knjižnica ....................................................................................... 24

2.5. ACS strežnik ............................................................................................. 25

2.5.1. OpenACS ........................................................................................... 25

2.5.2. OpenACS konfiguracija ...................................................................... 25

3. OBSTOJEČE STANJE ......................................................................................... 26

3.1. PROGRAMSKA OPREMA ............................................................................. 27

3.1.1. Osnovno delovanje programske opreme ........................................... 28

4. PODATKOVNI MODEL ........................................................................................ 29

4.1. VOIP PODATKOVNI MODEL ........................................................................ 30

4.2. TR-069 PODATKOVNI MODEL .................................................................... 31

5. PRENOVA ......................................................................................................... 33

5.1. PRENOVA PROGRAMSKE OPREME .............................................................. 34

5.1.1. Samostojni modul za delovanje TR-069 programske opreme ............ 35

5.1.2. Univerzalni vmesnik za podatkovni model ........................................ 37

5.1.3. Delovanje TR-069 na različnih operacijskih sistemih ........................ 39

5.1.4. TR-069 programska oprema .............................................................. 40

6. VERIFIKACIJA IN TESTIRANJE ........................................................................... 44

6.1. RAZVOJNO TESTIRANJE ............................................................................ 44

6.1.1. Testiranje vzpostavitve transakcijske seje ....................................... 45

6.1.2. Testiranje konfiguracijske skripte .................................................... 50

6.1.3. Testiranje TR-069 sporočil ................................................................ 51

6.2. VERIFIKACIJA ............................................................................................ 57

7. ZAKLJUČEK ...................................................................................................... 58

8. LITERATURA .................................................................................................... 60

KAZALO SLIK ....................................................................................................... 61

KAZALO TABEL .................................................................................................... 62

KRATICE IN AKRONIMI ......................................................................................... 62

Univerza v Mariboru – Fakulteta za organizacijske vede Diplomsko delo visokošolskega strokovnega študija

Branko Zebec: Uporaba standarda TR-069 na VoIP produktu stran 1

1. UVOD

1.1. PREDSTAVITEV PROBLEMA

Zaposlen sem v razvojnem oddelku podjetja Iskratel d.o.o. Zadolžen sem za razvoj programske opreme za komunikacijske naprave. Od našega velikega kupca v Rusiji smo dobili zahtevo za podporo TR-069 funkcionalnosti na naši VoIP napravi. VoIP naprava je namenjena izvajanju govornih zvez med uporabniki. Pretvarja govorni analogni signal v digitalnega in obratno. Namen kupca je modernizacija telekomunikacijskega omrežja. Njegovo telekomunikacijsko omrežje je zelo veliko, zato je za modernizacijo potrebno veliko število VoIP naprav. Kupec ima enoten upravljalski sistem, s katerim upravlja vse komunikacijske naprave. Njegov upravljalski sistem deluje le prek TR-069 protokola. VoIP naprava ima vgrajen lasten upravljalski sistem, ki ni kompatibilen z nobeno standardno rešitvijo. To za kupca ni sprejemljivo, ker vpeljava dodatnega upravljalnega sistema pomeni zanj strošek. Potrebni so dodatno usposobljeni zaposleni. Problem je v velikem številu VoIP naprav. Vsem napravam je treba ročno nastaviti določene nastavitve, kar zahteva veliko časa in dela. Če bi kupec potreboval manjše število VoIP naprav, verjetno ne bi zahteval dodatnega upravljalskega sistema TR-069 in bi bil trenutni upravljalski sistem na VoIP napravi dovolj dober. Glavni problem je, da je kupec to zahteval kot pogoj za nakup VoIP naprav. S tem je pod vprašajem trenutni nekaj milijonski posel in nadaljnje sodelovanje z njim. TR-069 je tehnična specifikacija, ki določa protokol za oddaljeno upravljanje končnih naprav pri uporabniku doma. Naprava pri uporabniku doma se imenuje modem. VoIP naprava ni namenjena za postavitev pri uporabniku doma, temveč pri operaterju, ki je kupec te naprave. To pomeni, da se mora pri TR-069 upravljanju obnašati enako kot naprave pri uporabnikih doma. Zaradi drugačne zasnove strojne opreme na VoIP napravi bo velik izziv definicija TR-069 podatkovnega modela.



1.2. CILJI IN NALOGE

Glavni cilj diplomske naloge je izvedba programske opreme za TR-069 na obstoječi VoIP napravi. Cilj je doseči minimalno podporo standardnim podatkom, ki se upravljajo preko TR-069 protokola. Glede na to, da je VoIP naprava drugačne zasnove kot modem naprava, je dogovor s kupcem, da se podpre le del podatkovnega modela, ki ga določa TR-069. Vsi ostali podatki, ki nimajo standardne zamenjave, pa se lahko definirajo kot privatni. Zahteva je tudi doseči čim večjo modularnost TR-069 programskega modula za morebiten kasnejši prenos na druge obstoječe oz. nove produkte. S tem se strošek razvoja zmanjša, saj se ta ne ponavlja. Končen cilj je delovanje TR-069 z omejitvami na VoIP napravi za izpolnitev kupčeve zahteve.

1.3. PREDPOSTAVKE IN OMEJITVE

VoIP naprava je namenjena namestitvi pri kupcu. Zato nima zunanjega vmesnika WAN (prostrano omrežje), kot ga imajo naprave CPE (uporabniška oprema), ki so pri uporabnikih doma. In prav TR-069 določa protokol CWMP (CPE WAN upravljalni protokol) za upravljanje preko WAN vmesnika. VoIP naprava uporablja za dostop LAN (lokalno omrežje) vmesnik, enako kot računalnik doma. To je omejitev na VoIP strojni opremi. Kupec se tega zaveda in kljub temu želi imeti TR-069 na VoIP napravi. Zanj je ključna podpora TR-104, ki je razširitev TR-069. TR-104 je tehnična specifikacija za VoIP SIP (protokol za vzpostavitev seje) podatke na VoIP napravi. VoIP naprava ima podprte podatke, ki se konfigurirajo, vendar niso v celoti enaki podatkom, ki jih določa TR-104. Na VoIP napravi bo treba določene podatke spremeniti. Podatke, ki so na njej in ne obstajajo v TR-069 oz. TR-104 specifikaciji, je treba spremeniti v privatne. Problem je, da VoIP naprava ne deluje, če niso nastavljeni podatki, ki jih ni v TR-069 in TR-104. Zato je tudi te privatne podatke treba podprti, da se lahko nastavljajo.



1.4. METODE DELA

V razvojnem oddelku uporabljamo za razvoj programske oz. strojne opreme razvojne mejnike. Vsak razvojni mejnik ima določene pogoje, da je dosežen. Podpora TR-069 na VoIP napravi je v celoti programska rešitev.

1.4.1. Razvojni mejnik B100

Na začetku je produktni vodja predstavil zahtevo za projekt TR-069 na VoIP napravi. V razvojnem oddelku smo preverili, kakšne so možnosti za izvedbo, tako da smo analizirali to zahtevo. Analiza je vsebovala:

• Pregled standardne dokumentacije za TR-069. • Pregled obstoječe programske opreme. • Pregled podatkovnega modela.

Na podlagi analize smo potrdili, da je zahteva formalno sprejemljiva. Predstavili smo aktivnosti, oceno vložka in plan izvedbe do razvojnega mejnika B400. Določili smo naslednje aktivnosti:

• Pisanje funkcijske dokumentacije. • Pisanje zasnovne dokumentacije. • Implementacija TR-069. • Testiranje TR-069.

Definirali smo seznam možnih tveganj:

• Problem s stabilnostjo: Zaradi spremembe obstoječe programske opreme se v sistemu lahko pojavi problem z nesproščanjem spomina, kar privede do porabe celotnega spomina. Nepravilna izvedba programske kode lahko privede do trajnega zaklepa celotnega sistema.

• Problem z odprtokodno knjižnico gSOAP: Odprtokodne programske rešitve so ponavadi tvegana izbira, saj razvoja nismo naredili sami. Zaradi nepoznavanja programske kode ne moremo oceniti zanesljivosti delovanja. Podpora ni zagotovljena in zato smo pri morebitnem problemu prepuščeni samemu sebi.

Vložek smo ocenili na 3 ČM, kar pomeni tri mesece dela za enega človeka. Vložek vsebuje razvojno aktivnost do mejnika B400. Določili smo tudi datumski rok za zaključitev mejnika B400 na 22. 9. 2015. Rok za zaključitev mejnika B400 je podan na podlagi večletnih izkušenj z razvojem programske opreme in na podlagi analize. V praksi se velikokrat zgodi, da je rok napačno ocenjen. Zato pa je ključno, da se definirajo možna tveganja in s tem določena rezerva pri vložku.




Izvajali smo podane aktivnosti v mejniku B100: • Pisanje funkcijske dokumentacije:

Za TR-069 smo podrobneje analizirali tehnično dokumentacijo. Na podlagi analize in dogovora s kupcem o minimalni zahtevi za podporo TR0-69 smo v funkcijski dokumentaciji opisali funkcije in delovanje zahtevanih sporočil in podatkov. V dokumentaciji smo tudi opisali delovanje in zagon TR-069 v okviru VoIP naprave. Funkcijska dokumentacija ni namenjena razvijalcu, temveč ljudem, ki uporabljajo VoIP napravo in TR-069. To so serviserji, verifikatorji in integratorji. Na podlagi funkcijske dokumentacije se izdela uporabniški priročnik, ki je ključen za kupca. Zaradi tega smo porabili ogromno časa za analizo in dokumentacijo skrbno napisali. To je ena izmed težjih nalog, saj je potrebnega veliko znanja. Največji problem nam je predstavljala analiza TR-069 tehnične dokumentacije, ker je napisana preveč strokovno in brez praktičnih primerov. Funkcijska dokumentacija je ključna tudi za nadaljnji razvoj, saj se v njej obdela vse možne scenarije. • Pisanje zasnovne dokumentacije: Na podlagi funkcijske dokumentacije smo analizirali, kako lahko vsebino tega dokumenta pretvorimo v programsko rešitev. Analizirali smo tudi obstoječo programsko stanje na VoIP napravi. Glede na izkušnje in dobro poznavanje obstoječe programske opreme na VoIP napravi smo definirali naslednje postopke za vpeljavo TR-069 vanjo:

o Samostojni modul za delovanje TR-069 programske opreme. o Univerzalni vmesnik za podatkovni model. o Delovanje TR-069 na različnih operacijskih sistemih. o TR-069 programska oprema.

Postopke smo prikazali v dokumentaciji z UML diagrami in diagrami poteka. Zasnovna dokumentacija je pomembna le za razvijalce programske opreme in je namenjena razumevanju in kasnejši prenovi. Zadnje čase se opušča predvsem zaradi časa, namenjenega njeni izvedbi. Dobro napisana programska oprema je razumljiva in ni potrebe po zasnovni dokumentaciji. Za izvedbo zasnovne dokumentacije smo porabili precej časa.



• Implementacija TR-069. Za implementacijo programske opreme TR-069 smo uporabili programski jezik C++. Implementacijo smo izvajali po navodilih iz zasnovne dokumentacije. Orodja, s pomočjo katerih smo implementirali programsko opremo, so:

o Microsoft Visual Studio 2013 Express. Razvojno orodje se uporablja za razvoj programske opreme za delovanje na operacijskem sistemu Microsoft Windows.

o Wind River Tornado. Razvojno orodje se uporablja za razvoj programske opreme za delovanje na operacijskem sistemu Wind River VxWorks.

Programska oprema na VoIP napravi privzeto deluje na operacijskem sistemu Wind River VxWorks. Razvojno orodje Wind River Tornado je namenjeno prevajanju C++ programske kode v paket, ki deluje na VoIP napravi. Programsko kodo smo, zaradi lažjega iskanja napak in lažjega testiranja, razvijali v orodju Microsoft Visual Studio 2013 Express. To orodje omogoča, da se programska koda izvaja na operacijskem sistemu Microsoft Windows. Po programski kodi se lahko premikamo po korakih in spremljamo njeno izvajanje. Razvoj programske kode z orodjem Wind River Tornado je težji, saj potrebujemo VoIP napravo, na katero je treba vedno naložiti paket narejen, s tem orodjem, če želimo preveriti delovanje programske kode. Ta postopek je časovno neoptimalen, saj je pri razvoju programske kode veliko preverjanja njenega delovanja in s tem nalaganja paketa na VoIP napravo. Nalaganje je počasno, zato razvoja programske opreme nismo izvajali s tem orodjem. Orodje Wind River Tornado smo uporabili le za izdelavo paketa za VoIP napravo. Na koncu smo programsko kodo prenesli v razvojno orodje Wind River Tornado in naredili paket za VoIP napravo. Ugotovili smo, da je razvoj programske kode z orodjem Microsoft Visual Studio nekajkrat hitrejši kot z orodjem Wind River Tornado. Uporabili smo odprtokodno knjižnico gSOAP in s tem prihranili veliko časa, ki bi ga izgubili zaradi nepotrebne implementacije kodiranja in dekodiranja sporočil, ki jih definira TR-069. gSOAP knjižnica na podlagi TR-069 sporočil naredi programsko kodo, ki se prek funkcij kliče v aplikaciji, ki smo jo implementirali. Programska oprema za TR-069 vsebuje odprtokodno knjižnico gSOAP in aplikacijo.



• Testiranje TR-069. Razvojno testiranje programske kode smo izvajali z orodjem Microsoft Visual Studio in odprtokodnim avtokonfiguracijskim strežnikom OpenACS. Z orodjem Microsoft Visual Studio smo testirali izvajanje programske kode. Strežnik OpenACS smo uporabili za testiranje TR-069 sporočil. Testiranje se je izvajalo sočasno med razvojem programske kode. Po uspešnem testiranju TR-069 programske kode na operacijskem sistemu Microsoft Windows smo ga ponovili tudi med OpenACS strežnikom in VoIP napravo. Z orodjem Wireshark, ki je namenjeno analiziranju mrežnih protokolov, smo preverjali ustreznost TR-069 sporočil. Ta so se pošiljala pri testiranju med OpenACS strežnikom in TR-069 programsko kodo, ki se je izvajala z orodjem Microsoft Visual Studio oz. na VoIP napravi. Vse aktivnosti je preverjal projektni vodja, ki je prevzel ta projekt. Obveščali smo ga o statusu izvedenih aktivnosti, nezaključenih aktivnostih in o stanju programskega paketa. Razvojna aktivnost B400 se je zaključila po končani implementaciji in testiranju.


Po doseženem razvojnem mejniku B400 je verifikacijska skupina prevzela VoIP napravo z vključeno TR-069 programsko opremo. Verifikacijska skupina je preverjala ustreznost TR-069 na VoIP napravi. TR-069 je preverjal tester, ki ga pozna in ga je že testiral na drugih napravah. Za testiranje je uporabljal odprtokodni strežnik OpenACS in licenčni ACS strežnik, ki ga uporablja kupec. Drugi tester je preverjal osnovno delovanje VoIP naprave. Naredil je teste, ki so že bili uspešni pri prejšnjih testiranjih na VoIP napravi. S tem je preveril, ali se obstoječe stanje zaradi dodanega TR-069 ni pokvarilo. Za testiranje je uporabljal napravo Ameritec, ki je namenjena avtomatskemu izvajanju govornih zvez. Verifikacija je preverjala delovanje TR-069 po funkcijski dokumentaciji. Razvojni mejnik B600 je končan po uspešnih verifikacijskih testih.



2. OSNOVE

2.1. TR-069

2.1.1. Osnovni opis

TR-069 določa protokol CWMP (CPE WAN upravljalni protokol), ki se uporablja za daljinsko upravljanje CPE (uporabniška oprema) naprav. To omogoča konfiguriranje in nadzorovanje preko upravljalske aplikacije, ki se izvaja na oddaljenem ACS (avtokonfiguracijski strežnik) strežniku. Na sliki 1 je prikazan sistem upravljanja CPE naprav.

Slika 1: CWMP arhitektura

(Vir: https://www.broadband-forum.org/technical/download/TR-069.pdf (15. 1. 2016))

2.1.2. Transakcija

TR-069 definira sejo transakcije kot zaporedje RPC (klic za oddaljeni postopek) klicev, zahtev in odgovorov. Seja transakcije je končana, ko CPE in ACS nimata več nobenih sporočil za poslati. Vloga CPE:

• Vzpostavljanje transakcijskih sej. • Ohranjanje TCP (protokol za krmiljenje transporta) povezav za čas trajanja

seje. • Zapiranje transakcijskih sej.



2.1.3. Vzpostavitev transakcijske seje

Vse transakcijske seje se vzpostavljajo na CPE s poslanim RPC sporočilom Inform. Ločimo dve vrsti transakcijskih sej, ki so začete s strani CPE ali ACS strežnika:

• CPE seje. • Asinhrone ACS seje. CPE vzpostavi transakcijsko sejo na ACS strežnik po

sprejetem sporočilu za vzpostavitev povezave s strani ACS strežnika (Connection Request from the ACS).

Na sliki 2 je prikazana vzpostavitev seje s CPE naprave.

Slika 2: CPE seja (Vir: https://www.broadband-forum.org/technical/download/TR-069.pdf

(15. 1. 2016))

Na sliki 3 je prikazana vzpostavitev seje z ACS strežnika.

Slika 3: Asinhrona ACS seja


CPE ACS

InformResponse

Inform

Send Cookie

204 No Content

RPC call

CPE ACSHTTP GET toConnectionRequestURL

InformResponse

200 OK

Inform(Event Connection request)

Send Cookie

204 No Content

RPC call



2.1.4. Dogodki

Sporočilo Inform vsebuje podatek, ki prikazuje vzrok za vzpostavitev transakcijske seje. Tabela 1 prikazuje vse možne dogodke, ki se lahko pošljejo v sporočilu.

Dogodek Opis 0 BOOTSTRAP Prvi kontakt CPE na ACS. 1 BOOT Po ponovnem zagonu CPE. 2 PERIODIC Seja se vzpostavi glede na periodični

interval sporočila Inform. 4 VALUE CHANGE Sprememba vrednosti parametra v listi

(Inform ParameterList). 6 CONNECTION REQUEST Seja se vzpostavi po asinhroni zahtevi

za vzpostavitev povezave z ACS strežnika.

7 TRANSFER COMPLETE Prikazuje popolno izvedbo RPC funkcije (DOWNLOAD, UPLOAD).

M <ime metode> (Reboot, Download)

Tabela 1: Dogodki Inform (Vir: https://www.broadband-forum.org/technical/download/TR-069.pdf

(15. 1. 2016))



2.1.5. Začetna vzpostavitev CPE na ACS

Ta se izvede po inicializaciji TR-069 klienta na CPE. Delovanje:

• CPE pošlje RPC sporočilo Inform z dogodkom 0 BOOTSTRAP. • ACS z uporabo RPC funkcije GetRPCMethods zahteva listo RPC funkcij, ki so

podprte na CPE. • ACS izvede konfiguracijo na CPE.

Slika 4 prikazuje začetno vzpostavitev seje s CPE naprave po startu naprave.

CPE ACS

InformResponse

Inform (Event BOOTSTRAP)

Send Cookie

204 No Content

GetRPCMethods

GetRPCMethodResponse

SetParameterValues

SeParameterValuesResponse

Slika 4: Začetna vzpostavitev CPE na ACS (Vir: https://www.broadband-forum.org/technical/download/TR-069.pdf

(15. 1. 2016))

2.1.6. Periodična vzpostavitev CPE seje

Privzeta nastavitev za periodično vzpostavitev seje: • InternetGatewayDevice.ManagementServer.PeriodicInformEnable = 1 • InternetGatewayDevice.ManagementServer.PeriodicInformInterval = 60

ACS strežnik nastavlja ta parametra. Če je parameter PeriodicInformEnable=1, CPE periodično izvaja Inform mehanizem. Slika 5 prikazuje periodično vzpostavitev seje s CPE naprave.

CPE ACS

InformResponse

Inform (Event PERIODIC)

Send Cookie

204 No Content

Slika 5: Periodična vzpostavitev CPE seje (Vir: https://www.broadband-forum.org/technical/download/TR-069.pdf

(15. 1. 2016))



2.1.7. TR-069 sporočilo GetRPCMethods

Na to sporočilo CPE vrne v sporočilu GetRPCMethodsResponse listo vseh RPC funkcij, ki so podprte. Podprte RPC funkcije:

• GetRPCMethods • GetParameterValues • SetParameterValues • GetParameterNames • AddObject • DeleteObject • Reboot • Download • Upload • FactoryReset

Slika 6 prikazuje izvedbo sporočila GetRPCMethods z ACS strežnika.


InformResponse

200 OK


Send Cookie

204 No Content

GetRPCMethods

GetRPCMethodsResponse

Slika 6: TR-069 sporočilo GetRPCMethods (Vir: https://www.broadband-forum.org/technical/download/TR-069.pdf

(15. 1. 2016))



2.1.8. TR-069 sporočilo Reboot

RPC funkcija povzroči ponovni zagon CPE. Delovanje:

• Podatek CommandKey, ki je v RPC sporočilu Reboot, se shrani v RAM disk. • Ta podatek se po ponovnem zagonu CPE upošteva v Inform sporočilu. • Po uspešnem sporočilu se ta podatek izbriše iz RAM diska.

Slika 7 prikazuje izvedbo sporočila Reboot z ACS strežnika.


InformResponse

200 OK


Send Cookie

204 No Content

Reboot

RebootResponse

Slika 7: TR-069 sporočilo Reboot (Vir: https://www.broadband-forum.org/technical/download/TR-069.pdf

(15. 1. 2016))



2.1.9. TR-069 sporočilo FactoryReset

RPC funkcija povzroči, da se uveljavijo privzete nastavitve v konfiguraciji. Delovanje:

• Na CPE se privzeta datoteka default_config.xml prekopira v obstoječo datoteko config.xml in se prepiše.

• CPE se ponovno zažene in na voljo je privzeta konfiguracija. Slika 8 prikazuje izvedbo sporočila FactoryReset z ACS strežnika.


InformResponse

200 OK


Send Cookie

204 No Content

FactoryReset

FactoryResetResponse

Slika 8: TR-069 sporočilo FactoryReset (Vir: https://www.broadband-forum.org/technical/download/TR-069.pdf

(15. 1. 2016))



2.1.10. TR-069 sporočilo Download

RPC funkcija povzroči, da CPE shrani paket ali konfiguracijo iz določene lokacije. Delovanje:

• CPE sprejme RPC funkcijo Download z ACS strežnika. • CPE pošlje sporočilo DownloadResponse s statusom 1 - prenos še ni končan. • Transakcijska seja se zapre. • CPE izvede funkcijo za prenos podatkov in pošlje sporočilo HTTP (protokol

za prenos hiperteksta) GET (HTTP zahteva za pridobitev podatkov) na podatkovni strežnik oz. na naslov, ki ga je dobil v predhodni RPC funkciji Download.

• Prenos podatkov je lahko uspešen oz. neuspešen. • Nova transakcijska seja se vzpostavi po prenosu podatkov in če je uspešen,

se pošlje sporočilo TransferComplete s kodo napake 0 - OK. Če prenos ni uspešen, se pošlje koda napake 9010 - download failure.

• Če med izvajanjem prenosa podatkov pride do ponovnega zagona CPE, se pred začetno vzpostavitvijo izvede transakcijska seja in pošlje sporočilo Inform z dogodkom 7 TRANSFER COMPLETE z napako 9017 - download failure: unable to complete download.

Slika 9 prikazuje izvedbo sporočila Download z ACS strežnika.


InformResponse

200 OK


Send Cookie

204 No Content

Download

DownloadResponse

CPE Download Process

Inform (Event Transfer Complete)

InformResponse

TransferComplete

Send Cookie

TransferCompleteResponse

204 No Content

Slika 9: TR-069 sporočilo Download (Vir: https://www.broadband-forum.org/technical/download/TR-069.pdf

(15. 1. 2016))



2.1.11. TR-069 sporočilo Upload

RPC funkcija povzroči, da CPE pošlje konfiguracijo ali log datoteko na določeno lokacijo. Delovanje:

• CPE sprejme RPC funkcijo Upload z ACS strežnika. • CPE pošlje sporočilo UploadResponse s statusom 1 - prenos še ni končan. • Transakcijska seja se zapre. • CPE izvede funkcijo za prenos podatkov in pošlje sporočilo HTTP (protokol

za prenos hiperteksta) POST (HTTP zahteva za shranjevanje podatkov) na podatkovni strežnik oz. na naslov, ki ga je dobil v predhodni RPC funkciji Upload.

• Prenos podatkov je lahko uspešen oz. neuspešen. • Nova transakcijska seja se vzpostavi po prenosu podatkov in če je uspešen,

se pošlje sporočilo TransferComplete s kodo napake 0 - OK. Če prenos ni uspešen, se pošlje koda napake 9010 - upload failure.

• Če med izvajanjem prenosa podatkov pride do ponovnega zagona CPE, se pred začetno vzpostavitvijo izvede transakcijska seja in pošlje sporočilo Inform z dogodkom 7 TRANSFER COMPLETE z napako 9017 - download failure: unable to complete download.

Slika 10 prikazuje izvedbo sporočila Upload z ACS strežnika.


InformResponse

200 OK


Send Cookie

204 No Content

Upload

UploadResponse

CPE Upload Process

Inform (Event Transfer Complete)

InformResponse

TransferComplete

Send Cookie

TransferCompleteResponse

204 No Content

Slika 10: TR-069 sporočilo Upload (Vir: https://www.broadband-forum.org/technical/download/TR-069.pdf

(15. 1. 2016))



2.1.12. TR-069 sporočilo SetParameterValues

RPC funkcija povzroči nastavitev enega ali več parametrov na CPE. Delovanje:

• CPE sprejme RPC funkcijo SetParameterValues z ACS strežnika. • Sporočilo vsebuje listo parametrov s pripadajočimi vrednostmi. • Pri uspešni nastavitvi celotne liste se pošlje odgovor

setParameterValuesResponse s statusom 0. Pri neuspešni nastavitvi vsaj enega parametra v listi se pošlje napaka: - 9005 Invalid parameter name - parameter ne obstaja. - 9007 Invalid parameter value - vrednost parametra je neustrezna. - 9002 Internal error – notranja napaka.

• Nove vrednosti parametrov na CPE se nastavijo po izteku časovnika 30 s po zadnji nastavitvi. Po izteku časovnika se vse spremembe vpišejo tudi v konfiguracijsko datoteko config.xml na flash disk. Časovnik ni nastavljiv.

Slika 11 prikazuje izvedbo sporočila SetParameterValues z ACS strežnika.


InformResponse

200 OK


Send Cookie

204 No Content

SetParameterValues

SetParameterValuesResponse

Slika 11: TR-069 sporočilo SetParameterValues (Vir: https://www.broadband-forum.org/technical/download/TR-069.pdf

(15. 1. 2016))



2.1.13. TR-069 sporočilo GetParameterValues

Na to RPC funkcijo CPE vrne vrednost enega ali več parametrov. Delovanje:

• CPE sprejme RPC funkcijo GetParameterValues z ACS strežnika. • Sporočilo vsebuje listo parametrov. • Pri uspešnem branju vrednosti parametrov celotne liste se pošlje odgovor

GetParameterValuesResponse, ki vsebuje listo parametrov s prebranimi vrednostmi. Napaka se pošlje le v primeru, če parameter ne obstaja: - 9005 Invalid parameter name - parameter ne obstaja. - 9002 Internal error – notranja napaka.

Slika 12 prikazuje izvedbo sporočila GetParameterValues z ACS strežnika.


InformResponse

200 OK


Send Cookie

204 No Content

GetParameterValues

GetParameterValuesResponse

Slika 12: TR-069 sporočilo GetParameterValues




2.1.14. TR-069 sporočilo GetParameterNames

Na to RPC funkcijo CPE vrne imena parametrov oz. imena tabel. Delovanje:

• CPE sprejme RPC funkcijo GetParameterNames z ACS strežnika. • Komanda mora vsebovati ime tabele s piko (.) (npr.

InternetGatewayDevice.). V tem primeru je tabela InternetGatewayDevice, ki vsebuje parametre in druge tabele.

• Če ime tabele obstaja, se v sporočilu GetParameterNamesResponse pošlje lista z imeni parametrov oz. tabel. Napaka se pošlje v primeru: - 9005 Invalid parameter name - parameter ne obstaja. Če ime tabele ne

obstaja. - 9002 Internal error – notranja napaka.

Slika 13 prikazuje izvedbo sporočila GetParameterNames z ACS strežnika.


InformResponse

200 OK


Send Cookie

204 No Content

GetParameterNames

GetParameterNamesResponse

Slika 13: TR-069 sporočilo GetParameterNames (Vir: https://www.broadband-forum.org/technical/download/TR-069.pdf

(15. 1. 2016))



2.1.15. TR-069 sporočilo AddObject

Na to RPC funkcijo CPE kreira novo tabelo oz. novo vrstico v tabeli. Delovanje:

• CPE sprejme RPC funkcijo AddObject z ACS strežnika. • Komanda vsebuje ime tabele, ki se bo kreirala (npr.

InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Line.). • Če ime tabele obstaja, se v sporočilu AddObjectResponse pošlje indeks

tabele in status kreacije 0. Napaka se pošlje v primeru: - 9005 Invalid parameter name - parameter ne obstaja. Če ime tabele ne


Slika 14 prikazuje izvedbo sporočila AddObject z ACS strežnika.


InformResponse

200 OK


Send Cookie

204 No Content

AddObject

AddObjectResponse

SetParameterValues

SetParameterValuesResponse

Slika 14: TR-069 sporočilo AddObject (Vir: https://www.broadband-forum.org/technical/download/TR-069.pdf

(15. 1. 2016))



2.1.16. TR-069 sporočilo DeleteObject

Na to RPC funkcijo CPE izbriše obstoječo tabelo oz. vrstico v tabeli. Delovanje:

• CPE sprejme RPC funkcijo DeleteObject z ACS strežnika. • Komanda vsebuje ime tabele, ki se bo brisala z vključenim indeksom tabele

(npr. InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.Line.1.).

• Če ime tabele z indeksom obstaja, se v sporočilu DeleteObjectResponse pošlje status brisanja 0. Napaka se pošlje v primeru: - 9005 Invalid parameter name - parameter ne obstaja. Če ime tabele ne


Slika 15 prikazuje izvedbo sporočila DeleteObject z ACS strežnika.


InformResponse

200 OK


Send Cookie

204 No Content

DeleteObject

DeleteObjectResponse

Slika 15: TR-069 sporočilo DeleteObject (Vir: https://www.broadband-forum.org/technical/download/TR-069.pdf

(15. 1. 2016))



2.1.17. Sporočilo Cookie

Po vsaki zaključitvi seje CPE pošlje HTTP sporočilo s statusom 204 No Content na ACS strežnik, kar pomeni, da CPE nima za poslati več nobenega sporočila. Sporočilo je prikazano na sliki 16.

Slika 16: Sporočilo Cookie


2.1.18. Sporočilo za neuspešno izvedeno RPC funkcijo

CPE v primeru neuspešno izvedene RPC funkcije pošlje sporočilo prikazano na sliki 17 na ACS strežnik. Sporočilo je v primeru napake za vse RPC funkcije enako, spreminja se le koda napake.

s

Slika 17: Sporočilo za neuspešno izvedeno RPC funkcijo


Vir: https://www.broadband-forum.org/technical/download/TR-069.pdf (15. 1. 2016)

HTTP/1.1 204 No Content\r\n Server: Apache-Coyote/1.1\r\n X-Powered-By: Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)/JBossWeb-2.0\r\n Date: Thu, 24 Dec 2015 11:44:38 GMT\r\n

<SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode> SOAP-ENV:Client </faultcode> <faultstring> CWMP Fault </faultstring> <detail> <FaultCode> 9002 </FaultCode> <FaultString> Internal error </FaultString> </detail> </SOAP-ENV:Fault> </SOAP-ENV:Body>



2.2. SOAP

V središču spletnih storitev je SOAP glavni komunikacijski protokol. Je protokol, ki temelji na XML (razširljivi označevalni jezik) tekstovnem formatu. Namenjen je sporočilom za zahteve in odgovore preko HTTP (protokol za prenos hiperteksta) protokola. SOAP določa natančno kodiranje HTTP glave in XML datoteke, tako da lahko program v enem računalniku pokliče program v drugem računalniku in izmenja informacije. HTTP in XML omogočata komunikacijo med programi v omrežju na različnih operacijskih sistemih. SOAP tudi določa, kako klicani program vrne odgovor. Ima podobno delovanje kot RPC in omogoča aplikacijam klicanje funkcij v drugih aplikacijah. Klici večinoma nimajo težav s požarnim zidom zaradi HTTP porta 80. Ostali klici na drugih portih se lahko blokirajo zaradi varnostnih razlogov. HTTP zahteve so običajno dovoljene skozi požarne zidove, zato programi, ki uporabljajo SOAP za komunikacijo lahko komunicirajo s programi kjerkoli. Prednosti SOAP protokola:

• Neodvisnost glede na platformo in programski jezik. • Komunikacija skozi požarne zidove in proksi strežnik.

Slabosti SOAP protokola:

• Je običajno precej počasen zaradi XML formata. • Pred gradnjo aplikacij je treba v celoti razumeti omejitve zmogljivosti. • Mnogi požarni zidovi ne razumejo razlike med uporabo HTTP v spletnem

brskalniku in v SOAP. Ker se na požarnem zidu analizira HTTP promet, nastane latenca.

Slika 18 prikazuje zgradbo SOAP sporočila.

Slika 18: Zgradba SOAP sporočila (Vir: https://www.w3.org/TR/soap/ (15. 1. 2016))

Vir: https://www.w3.org/TR/soap/ (15. 1. 2016)



2.3. WSDL

Je jezik za opis storitev in temelji na XML tekstovnem formatu. Zgradba:

• Tipi spremenljivk (Types) Določa vrsto podatkov za sporočila (RPC funkcije) splošno opredeljena z XML shemo XSD (definicija XML sheme).

• Sporočilo (Message) Določa sklop dejanskih sporočil oz. RPC funkcij. Sporočilo je lahko sestavljeno iz enega ali več delov.

• Tip porta (PortType) Definira abstraktne operacije. Operacija se nanaša na sporočila vključena v transakcijo.

• Vezi (Bindings) Določa obliko sporočila in informacije o protokolu za operacije, ki jih določi tip porta.

• Storitev (Service) Definira končno točko, na kateri bo delovala spletna storitev.

Na podlagi tega se WSDL razdeli na dva dela (slika 19):

• Abstraktni del Ni podatkov, ki se nanašajo na komunikacijski protokol in kako oz. kje se storitev izvaja.

• Fiksni del Podatki o protokolu in končni točki.

Slika 19: WSDL zgradba

(Vir: https://www.w3.org/TR/wsdl (15. 1. 2016)) XML shema definira elemente v XML dokumentu. Uporablja se za preverjanje ustreznosti elementov v XML dokumentu. Vir: https://www.w3.org/TR/wsdl (15. 1. 2016)



2.4. GSOAP KNJIŽNICA

gSOAP orodje je C/C++ programsko razvojno orodje za SOAP in XML spletne storitve. Je odprtokodna programska oprema (SourceForge projekt) za programske jezike C/C++, JAVA. Orodje na podlagi analize WSDL in XML sheme kreira C/C++ programsko kodo. Programska koda se kreira za server in odjemalca. Kreirajo se SOAP/XML funkcije za razčlenjevanje. DOM (objektni model dokumenta) ali SAX (enostaven API za XML) razčlenjevalnik ni potreben. gSOAP knjižnica je na voljo na: http://sourceforge.net/projects/gsoap2/ Slika 20 prikazuje uporabo gSOAP knjižnice.

Slika 20: Uporaba gSOAP knjižnice (Vir: http://www.cs.fsu.edu/~engelen/soap.html (15. 1. 2016))

Vir: http://www.cs.fsu.edu/~engelen/soap.html (15. 1. 2016)



2.5. ACS STREŽNIK

ACS strežnik se uporablja za konfiguriranje omrežnih elementov. Avtomatska konfiguracija je postopek, kjer operater za omrežni element vnaprej pripravi konfiguracijske podatke. Ko se omrežni element zažene, se prijavi v ACS strežnik. ACS strežnik mu pošlje konfiguracijske podatke. Za komunikacijo med ACS in omrežnim elementom se uporabljajo XML sporočila v obliki SOAP ovojnic. Uporablja se protokol CWMP (TR-069), ki ga definira DSL forum (https://www.broadband-forum.org/).

2.5.1. OpenACS

OpenACS je odprtokodni CWMP/TR-069 strežnik. Projekt se nahaja na http://sourceforge.net/projects/openacs/. Strežnik je na voljo kot VMware slika, ki je narejena z operacijskim sistemom Linux openSUSE. OpenACS strežnik je že nameščen in skonfiguriran. Privzeto je mrežni vmesnik nastavljen na DHCP protokol (protokol za dinamično konfiguriranje gostiteljskih računalnikov). Omogočen je port 8080 za dostop do strežnika preko spletnega brskalnika. OpenACS strežnik uporablja za konfiguracijo spletni vmesnik, preko katerega se dostopa z naslovom http://IP NASLOV STREŽNIKA:8080/.

2.5.2. OpenACS konfiguracija

Zahteva za izvedbo določene RPC funkcije pride z ACS strežnika. Spreminjanje konfiguracije oz. parametrov se izvaja preko RPC funkcij SetParameterValues, AddObject in DeleteObject. Poizvedba se izvaja preko RPC funkcije GetParameterValues. Nabor teh funkcij se na ACS strežniku izvaja iz skripte, ki je napisana v programskem jeziku JavaScript. Na ACS strežniku se lahko za določen CPE kreira svoja skripta oz. se uporabi privzeta (Default) skripta. ACS strežnik izvede skripto po prejeti zahtevi Inform od CPE. Vir: http://sourceforge.net/projects/openacs/ (15. 1. 2016)



3. OBSTOJEČE STANJE

VoIP naprava uporablja lastno programsko opremo za upravljanje in taka se prodaja že nekaj let. Naši kupci so večinoma ponudniki internetnih storitev. Do sedaj ni bilo pripombe na trenutno programsko opremo za upravljanje. Za našega velikega kupca takšen sistem upravljanja ni več dober in zahteva, da ima VoIP naprava TR-069 upravljanje. Kupec želi za vse naprave v svojem omrežju enako upravljanje. Kljub ugotovljenim omejitvam na VoIP napravi, se kupčeva zahteva ne spremeni. Kupec ima zgrajen sistem upravljanja z avtokonfiguracijskim strežnikom in ne želi dodatnega sistema upravljanja, ki ga ponuja VoIP naprava. To povzroči naslednje probleme:

• Določiti moramo okvirni vložek in datum zaključitve vseh razvojnih mejnikov za TR-069 na VoIP napravi.

• Datum zaključitve vseh razvojnih aktivnosti mora ustrezati tudi kupcu in se mora z njim strinjati.

• Pripravljeni moramo biti za skrajšanje časa zaključitve, kar pomeni, da moramo razvojne aktivnosti ustrezno prilagoditi glede na zahtevani čas.

• S kupcem se moramo uskladiti glede omejitev in dobiti pisno potrdilo, kaj zahteva, da je podprto in kaj ni potrebno podprti.

• Prodaja VoIP naprave se nam prestavi. • Zaradi razvojnih aktivnosti nastanejo dodatni stroški za podjetje. • Ostale razvojne aktivnosti na drugih projektih se prestavijo zaradi

odsotnosti razvijalcev. Obstoječe stanje programske opreme je opisano v poglavju 3.1.



3.1. PROGRAMSKA OPREMA

Slika 21 prikazuje obstoječo arhitekturo programske opreme na VoIP napravi. Zaradi vpeljave TR-069 na VoIP napravo imamo v obstoječi arhitekturi programske opreme naslednje probleme:

• K obstoječi programski opremi za upravljanje moramo vzporedno dodati novi programski modul TR-069, ki mora vsebovati TR-069 in TR-104 z omejitvami na podatkovnem modelu.

• Na programskem modulu XML (razširljivi označevalni jezik) je treba razširiti vmesnik za nastavljanje konfiguracijskih podatkov. Novi vmesnik bo namenjen dostopu konfiguracijskih podatkov iz TR-069 programskega modula. Vmesnik je zunanji in se registrira v programski modul TR-069. Za zagotavljanje modularnosti TR-069 programskega modula se vmesnik definira standardno in se ne omeji na trenutno implementacijo na VoIP napravi. To omogoča uporabo TR-069 programskega modula na drugih napravah.

• Narediti moramo samostojno sistemsko knjižnico, ki bo namenjena dostopu do funkcij operacijskega sistema. Glavne funkcije, ki jih potrebujemo so task, semafor, časovnik in čakalna vrsta. VoIP naprava deluje na operacijskem sistemu Wind River VxWorks. Operacijski sistem Microsoft Windows pa uporabljamo za lažji in hitrejši razvoj in testiranje programske opreme. Potrebujemo podporo za oba operacijska sistema. To je potrebno zaradi uporabe TR-069 programskega modula na drugih napravah, ki lahko delujejo na drugih operacijskih sistemih. Podpora drugega operacijskega sistema (npr. Linux) se doda v sistemsko knjižnico in se s tem ne popravlja TR-069 programskega modula.

Slika 21: Obstoječa VoIP arhitektura (Vir: lasten)



3.1.1. Osnovno delovanje programske opreme

VoIP naprava uporablja za nastavitev podatkov podatkovni model XML, zanj pa skrbi programski modul XML. Glavna VoIP aplikacija je vedno obveščena o spremembi konfiguracije. Ob spremembi vsak modul znotraj aplikacije samostojno prebere konfiguracijske podatke, za katere je zadolžen, in spremeni delovanje glede na spremembe.



4. PODATKOVNI MODEL

Glavni podatkovni model za VoIP napravo je XML zapis. Aplikacija vedno dostopa do XML podatkov in se ne zaveda zunanjih konfiguracijskih modulov. Zunanji konfiguracijski modul je VoIP upravljalni modul. Dodali smo dodatni konfiguracijski modul TR-069, ki se ga VoIP aplikacija ne bo zavedala. Na VoIP napravi imamo tri različne podatkovne modele (XML, VoIP upravljanje, TR-069). Med podatkovnimi modeli se izvaja pretvorba, ki je prikazana na sliki 22.

Slika 22: Pretvorba podatkovnega modela

(Vir: lasten)



4.1. VOIP PODATKOVNI MODEL

Konfiguracijski podatki so v XML datoteki. Slika 23 prikazuje del podatkov v XML datoteki. Na VoIP napravi je teh podatkov veliko več.

Slika 23: XML konfiguracijski podatki

(Vir: lasten)

<?xml version="1.0" encoding="utf-8" ?> <settings version="1.0"> <param name="domainName" value="VoIP"/> <param name="voipIp" value="192.168.1.101"/> <param name="voipIpMask" value="255.255.255.0"/> <groupref name="PortList" ref="PortList#1" id="1"/> <groupref name="SipProfile" ref="SipProfile#1" id="1"/> <groupref name="SipServerProfile" ref="SipServerProfile#1" id="1"/> </group> <group name="SipProfile" id="1"> <param name="ringingTimer" value="120"/> <param name="registerMode" value="0"/> </group> <group name="SipServerProfile" id="1"> <param name="sipHostname" value="192.168.1.111"/> <param name="sipPort" value="5060"/> </group> <group name="PortList" id="1"> <groupref name="Port" ref="Port#1" id="1"/> </group> <group name="Port" id="1"> <param name="equip" value="1"/> <groupref name="PortProfile" ref="PortProfile#1" id="1"/> <groupref name="SipAccount" ref="SipAccount#1" id="1"/> </group> <group name="PortProfile" id="1"> <param name="onHook" value="350"/> <param name="offHook" value="150"/> </group> <group name="SipAccount" id="1"> <param name="sipAccountName" value="account1"/> <param name="displayName" value="account1"/> <param name="sipLineDn" value="01"/> <param name="username" value="auth0001"/> <param name="password" value="auth0001"/> <param name="reregisterTime" value="3600"/> </group> </settings>



4.2. TR-069 PODATKOVNI MODEL

TR-098 definira podatkovni model za naprave, ki podpirajo TR-069. Podatkovni model je sestavljen iz tabel (objektov) in parametrov v drevesni strukturi, ki se lahko upravljajo preko CWMP (CPE WAN upravljalni protokol). Vidno na sliki 24. Objekt vsebuje druge objekte in parametre. Zraven standardnih objektov in parametrov smo definirali tudi privatne. Definirani so kot: X_<proizvajalec>_ proizvajalčevoSpecifičnoIme:

• <proizvajalec> - ISKRATEL. • proizvajalčevoSpecifičnoIme – ime objekta oz. parametra.

Za identifikacijo parametra ali objekta v podatkovnem modelu se uporablja ime poti. Podprta sta celotna in delna pot imena:

• Celotno ime poti je ime parametra (npr. InternetGatewayDevice.DeviceInfo.SoftwareVersion).

• Delno ime poti: se konča z (.) in je ime objekta. Če obstaja več primerkov objekta, imenu sledi ({i}.). Pri enem objektu imenu sledi številka.

• (npr. InternetGatewayDevice.DeviceInfo. ali InternetGatewayDevice.WANDevice.{i}.).

Za identifikacijo celotnega podatkovnega modela podprtega na CPE se uporabi ime InternetGatewayDevice..

ParameterObjekt

Instanca objekta

InternetGatewayDevice.Services.VoiceService.1.VoiceProfile.1.SIP.AuthUserName

Instanca objekta

ObjektObjekt

Slika 24: Drevesna struktura podatkovnega modela TR-098 (Vir: https://www.broadband-forum.org/technical/download/TR-098.pdf

(10. 6. 2015))

Vir: https://www.broadband-forum.org/technical/download/TR-098.pdf (10. 6. 2015)



V TR-069 programski modul smo dodali standardne TR-069 konfiguracijske parametre. Spodaj je prikazani TR-069 konfiguracijski parameter:

• InternetGatewayDevice.Services.VoiceService.{i}.VoiceProfille.{i}.SIP.UserAgentDomain:

o Opis: CPE domensko ime. o Dostop: branje, pisanje o Tip parametra: string o Podprte funkcije RPC:

� GetParameterValues: vrne vrednost parametra. � SetParameterValues: nastavi vrednost parametra.

ᔤV TR-069 programski modul smo dodali privatne VoIP konfiguracijske parametre. V TR-069 programski modul smo dodali privatne VoIP konfiguracijske parametre. Spodaj je prikazani VoIP privatnih konfiguracijski parameter:

• InternetGatewayDevice.X_ISKRATEL_voipIp: o Opis: TCP/IP naslov. o Dostop: branje, pisanje o Tip parametra: IPAddress o Podprte funkcije RPC:

� GetParameterValues: vrne vrednost parametra. � SetParameterValues: nastavi vrednost parametra.

Slika 25 prikazuje pretvorbo podatkovnega modela TR-069.

Slika 25: Pretvorba podatkovnega modela TR-069 (Vir: lasten)



5. PRENOVA

S kupcem smo se uskladili glede omejitev na TR-069 protokolu. Zaradi prevelikega posega v obstoječo programsko kodo na VoIP napravi za podporo TR-069 sporočil GetParameterAttributes in SetParameterAttributes je kupec pristal na to, da teh sporočil nujno ne potrebuje in nam jih ni treba podprti. Zaradi zasnove strojne opreme na VoIp napravi smo se z njim dogovorili, da bomo mrežne nastavitve nastavljali s privatnim podatkovnim modelom in vse ostale konfiguracijske parametre, ki nimajo preslikave. Je pa kupec zahteval, da je standard TR-104 v celoti podprt. Standard TR-104 definira podatkovni model za SIP nastavitve. Na VoIP napravi uporablja te nastavitve VoIP aplikacija. S kupcem smo se dogovorili o časovnem roku za dobavo programskega paketa z vključeno podporo za TR-069.



5.1. PRENOVA PROGRAMSKE OPREME

V obstoječo VoIP programsko opremo smo dodali programski modul TR-069, kar prikazuje slika 26. Naredili smo tudi sistemsko knjižnico za dostop do sistemskih funkcij. To nam zagotavlja neodvisnost programskega modula TR-069 od operacijskega sistema. S tem smo dosegli cilj kasnejše uporabe programskega modula TR-069 na drugih napravah oz. produktih, ki lahko delujejo na različnih operacijskih sistemih, npr. Linux, Android itd. Programski modul TR-069 je z obstoječo VoIP programsko opremo povezan le s programskim modulom XML, ki zagotavlja celotno podatkovno infrastrukturo za VoIP aplikacijo. Zaradi dobre zasnove obstoječe programske opreme na VoIP napravi je sprememba obstoječe programske opreme le na programskem modulu XML. S tem se izognemo nedelovanju obstoječe programske opreme. Na programskem modulu XML smo spremenili vmesnik za dostop do konfiguracijskih podatkov. To je potrebno zaradi zagotavljanja neodvisnosti programskega modula TR-069 od drugih programskih modulov.

Slika 26: VoIP arhitektura programske opreme z dodanim programskim modulom TR-069

(Vir: lasten)



5.1.1. Samostojni modul za delovanje TR-069 programske opreme

Ker želimo imeti TR-069 programsko opremo neodvisno od ostale, smo naredili proces, v katerem deluje TR-069 programska oprema. Proces smo implementirali po načrtovalskem vzorcu enojni vzorec (singleton), kar pomeni, da je v sistemu na voljo vedno le en statičen programski objekt in je dostopen globalno. Programski objekt je vedno živ in se nikoli ne pobriše. Programski objekt v programskem jeziku C++ pomeni, da se iz razreda naredi objekt, ki vsebuje druge objekte oz. reference na druge objekte in programsko kodo s funkcijami. Implementacija procesa je sistemska funkcija. To pomeni, da moramo uporabiti sistemske funkcije. Ker je programska koda za proces del programske kode TR-069, smo morali sistemske funkcije za proces, zaradi neodvisnega delovanja na različnih operacijskih sistemih, narediti v sistemski knjižnici. V procesu smo naredili programsko kodo, ki ustvari objekt po imenu Protocol, v katerem deluje programska koda za TR-069. Proces je zadolžen za kreacijo tega objekta in zagon TR-069. Proces tudi vzdržuje TR-069 pri življenju v zanki in kakršnakoli napaka na njem privede do brisanja objekta in njegove ponovne kreacije. Na sliki 27 je prikazan proces, ki skrbi za delovanje TR-069 programskega modula. Preklop med procesi izvaja operacijski sistem glede na prioriteto procesa. Procesu TR-069 smo dodali nižjo prioriteto, saj čas izvedbe konfiguracije ni kritičen. Konfiguracija se vedno lahko izvede zakasnjeno.

Slika 27: TR-069 proces (Vir: lasten)



Na sliki 28 je prikazana programska koda, ki skrbi za delovanje TR-069 programskega modula. Izvaja se v procesu TR-069. Ko se pokliče sistemska funkcija za kreacijo TR-069 procesa, operacijski sistem poskrbi, da se programska koda na sliki 28 začne izvajati. To se naredi vedno samo enkrat po zagonu VoIP naprave. Funkcijo za zagon TR-069 procesa smo dodali na vhodni vmesnik TR-069 programskega modula in s tem omogočili dostop iz drugih programskih modulov. Klic funkcije smo dodali v programski modul operacijskega sistema v glavno funkcijo, ki se zažene po startu operacijskega sistema.

Slika 28: Izvajanje TR-069 procesa (Vir: lasten)

int Task::runTask() { itTraceLog(LNONE,IT_MODULE,IT_FUNCNAME,"- Starting tr069client !!"); do { mProtocol = new Protocol; if(mProtocol != NULL) { break; } else { delete mProtocol; delayCurrentTaskForMillis(15000); } } while (true); do { itTraceLog(LDET,IT_MODULE,IT_FUNCNAME,"Trying to start the protocol"); if(false == mProtocol->start()) { mProtocol->stop(); delayCurrentTaskForMillis(5000); } } while (mProtocol != NULL); itTraceLog(LNONE,IT_MODULE,IT_FUNCNAME,"- tr069client end !!"); return 0; }



5.1.2. Univerzalni vmesnik za podatkovni model

TR-069 programski modul se mora na svojem izhodu vedno povezati z drugim programskim modulom, ki je zadolžen za konfiguracijske podatke. Na VoIP napravi je za konfiguracijske podatke zadolžen programski modul XML. Zaradi samostojnega in neodvisnega delovanja programskega modula TR-069 smo morali narediti tudi izhodni vmesnik za dostop do konfiguracijskih podatkov. Na vmesniku smo definirali funkcije in vhodno-izhodne parametre. Naredili smo privzeto implementacijo vmesnika, ki imitira vmesnik. Ta implementacija ima prazne funkcije s privzetimi izhodnimi parametri. Slika 29 prikazuje prazno implementacijo vmesnika. S tem smo zagotovili, da programski modul TR-069 vedno deluje samostojno. Če drugi zunanji programski modul ne implementira TR-069 izhodnega konfiguracijskega vmesnika, TR-069 programski modul deluje s privzetim vmesnikom.

Slika 29: UML diagram TR-069 izhodni vmesnik za dostop do konfiguracijskih podatkov s prazno implementacijo vmesnika

(Vir: lasten)

Na VoIP programski opremi smo spremenili le en programski modul XML in na njem implementirali TR-069 izhodni konfiguracijski vmesnik. Funkcije v vmesniku smo prilagodili na implementacijo programskega modula XML. To prikazuje slika 30.

Slika 30: UML diagram TR-069 izhodni vmesnik za dostop do konfiguracijskih podatkov z implementacijo vmesnika na XML programskem modulu

(Vir: lasten)



Objekt, ki vsebuje implementacijo vmesnika za TR-069 konfiguracijo, smo registrirali v programski modul TR-069 iz programskega modula XML. Objekt se naredi v programskem modulu XML in je njegov del. V programski modul TR-069 se registrira le referenca na objekt. Na sliki 31 je prikazana relacija med programskim modulom TR-069 in XML.

Slika 31: UML diagram relacije med programskim modulom TR-069 in XML (Vir: lasten)

Funkcijo za registracijo reference objekta za TR-069 konfiguracijo smo naredili v programskem modulu TR-069 in je del vhodnega vmesnika. Vhodni vmesnik vsebuje zraven te funkcije še funkcijo za zagon TR-069 procesa.



5.1.3. Delovanje TR-069 na različnih operacijskih sistemih

Programski modul TR-069 za delovanje potrebuje funkcije operacijskega sistema (proces, časovnik, semafor …). Delovati mora na operacijskem sistemu Microsoft Windows in Wind River VxWorks. V programski kodi TR-069 modula bi lahko naredili implementacijo za oba operacijska sistema in jo ločili z definicijo glede na operacijski sistem. S tem modul ne bi bil samostojen, ker bi bil vezan le na dva operacijska sistema. Operacijskih sistemov pa je v praksi več, npr. Linux, Android … Kasnejša uporaba programskega modula TR-069 na drugi napravi z drugim operacijskim sistemom bi zahtevala implementacijo za ta operacijski sistem in popravljanje programske kode v programskem modulu TR-069. Zato smo naredili sistemsko knjižnico in v njej podprli sistemske funkcije za operacijska sistema Microsoft Windows in Wind River VxWorks. Slika 32 prikazuje implementacijo sistemske knjižnice, ki smo jo naredili po načrtovalskem vzorcu tovarna. Tovarna je v našem primeru sistemska knjižnica, ki vsebuje oddelke Proces, Časovnik in Semafor. Sistemska knjižnica kot tovarna ponuja vsem oddelkom dostop do sistemskih funkcij. Oddelki se ne zavedajo operacijskega sistema, ker implementacijo zagotavlja tovarna, ki izbere ustrezno glede na operacijski sistem. Če želimo, da sistemska knjižnica deluje na drugem operacijskem sistemu, moramo narediti novo implementacijo zanj, in sicer za vse oddelke. Tudi oddelke lahko dodajamo, npr. mrežni dostop, dostop do diska itd … Za novi oddelek moramo narediti implementacijo za vse operacijske sisteme. Z uporabo sistemske knjižnice na TR-069 programskem modulu smo dosegli, da se modul ne zaveda operacijskega sistema, je prenosljiv in se ne spreminja. Sistemsko knjižnico lahko uporabimo na drugih produktih in s tem zagotovimo večjo modularnost, preglednost in boljšo programsko opremo.

Slika 32: UML diagram, sistemska knjižnica (Vir: lasten)



5.1.4. TR-069 programska oprema

Zaradi prevelike zahtevnosti in časovne omejitve za implementacijo TR-069 sporočil smo uporabili odprtokodno knjižnico gSOAP. Knjižnica gSOAP je zelo kompleksna z veliko programske kode, ki poskrbi za kodiranje in dekodiranje TR-069 sporočil in za mrežno povezljivost na TCP (protokol za krmiljenje prenosa) vtičnici. gSOAP knjižnica deluje na operacijskih sistemih Microsoft Windows in Wind River VxWorks. Na gSOAP knjižnici smo naredili:

• WSDL specifikacija: Definirali smo funkcije za TR-069 sporočila. WSDL specifikacijo smo zapisali v datoteko cwmp.wsdl. XML shemo smo uporabili od Broadband foruma https://www.broadband-forum.org/cwmp/cwmp-1-0.xsd. Slika 33 prikazuje WSDL specifikacijo za RPC funkcijo GetParameterValues. Vse ostale RPC funkcije so narejene enako.

Slika 33: TR-069 WSDL specifikacija

(Vir: lasten)

<?xml version='1.0' encoding='UTF-8'?> <definitions name="cwmp" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:cwmp="urn:dslforum-org:cwmp-1-0" <types> <xs:schema> <xs:import namespace="urn:dslforum-org:cwmp-1-0" schemaLocation="cwmp-1-0.xsd"/> </xs:schema> </types> <message name="GetParameterValues"> <part name="args" element="cwmp:GetParameterValues"/> </message> <message name="GetParameterValuesResponse"> <part name="args" element="cwmp:GetParameterValuesResponse"/> </message> <portType name="cwmpPortType"> <operation name="GetParameterValues"> <output message="tns:GetParameterValues"/> <input message="tns:GetParameterValuesResponse"/> </operation> </portType> </definitions>



• gSOAP WSDL uvoznik: Na podlagi WSDL specifikacije smo naredili datoteko cwmp.h, v kateri so definicije in deklaracije za TR-069 RPC funkcije. Slika 34 prikazuje izvedbo gSOAP WSDL uvoznika.

Slika 34: gSOAP TR-069 WSDL uvoznik (Vir: lasten)



• gSOAP RPC prevajalnik: Prevajalnik na podlagi datoteke cwmp.h ustvari programsko kodo z implementiranimi TR-069 RPC funkcijami. Slika 35 prikazuje izvedbo gSOAP RPC prevajalnika.

Slika 35: gSOAP TR-069 RPC prevajalnik (Vir: lasten)



Slika 36 prikazuje celotno implementacijo TR-069 programskega modula. Razred (TR-069 proces) je zadolžen za kreacijo sistemskega procesa, ki implementira objekt Protocol, ta pa je glavni objekt celotne implementacije. Njegove naloge so:

• Kreacija in dostop do objekta CwmpDatamodel. Namenjen je dostopu do podatkovnega modela za branje in nastavitev parametrov.

• Kreacija (soap) strukture. • Kreacija TCP vtičnice. • Kreacija časovnika za periodično pošiljanje Inform sporočila. • Kreacija časovnika za spremembo IP naslova omrežnega elementa. • Kreacija objekta Receiver za sprejem RPC sporočil. • Kreacija objekta TransferComplete. • Kreacija objekta Inform.

Slika 36: UML diagram programske opreme TR-069 (Vir: lasten)



6. VERIFIKACIJA IN TESTIRANJE

6.1. RAZVOJNO TESTIRANJE

Testiranje implementacije TR-069 programskega modula smo izvajali z odprtokodnim avtokonfiguracijskim strežnikom OpenACS. OpenACS strežnik smo morali pripraviti za delovanje. Namestitev je že izvedena v okviru virtualne slike na operacijskem sistemu Linux. Virtualno sliko OpenACS strežnika smo naložili na drugem računalniku. Do OpenACS strežnika smo dostopali preko spletnega vmesnika, na katerem smo izvajali nastavitve potrebne za testiranje. Zaradi lažje implementacije in testiranja smo uporabljali orodje Microsoft Visual Studio 2013 Express. V začetni fazi implementacije smo testirali predvsem ustrezno delovanje programske kode. Testiranje TR-069 programskega modula smo med implementacijo izvajali po korakih:

• Testirali smo ustrezno izvajanje in trajanje TR-069 procesa. • Testirali smo inicializacijo gSOAP knjižnice. • Testirali smo delovanje TCP vtičnice na gSOAP knjižnici. • Testirali smo delovanje gSOAP knjižnice pri dohodnem sporočilu HTTP GET. • Testirali smo delovanje vzpostavitve transakcijske seje. • Testirali smo periodično delovanje vzpostavitve transakcijske seje. • Testirali smo delovanje gSOAP knjižnice in TR-069 programske kode pri

dohodnih sporočilih TR-069. • Testirali smo pretvorbo med podatkovnima modeloma TR-069 in XML. • Testirali smo spremembo konfiguracijskih podatkov na VoIP aplikaciji in

spremljali spremembe v XML datoteki. • Testirali smo porabo in sproščanje glavnega spomina na operacijskem

sistemu. • Testirali smo sistemsko knjižnico.

Pri testiranjih smo ugotovili napake in jih sproti popravljali. Vsa testiranja smo ponavljali tako dolgo, dokler niso bile odpravljene vse napake. Testiranje smo naredili na obeh operacijskih sistemih Microsoft Windows in Wind River VxWorks. TR-069 sporočila smo preverjali v programskem orodju Wireshark, v katerem smo imeli nastavljen filter na HTTP protokol.



6.1.1. Testiranje vzpostavitve transakcijske seje

Vzpostavitev transakcijske seje je eden izmed ključnih testov. Če se seja ne vzpostavi, tudi vse nadaljnje akcije ne delujejo. Testiranje vzpostavitve seje smo naredili pri:

• Registraciji VoIP naprave na OpenACS strežnik. • Periodični registraciji VoIP naprave na OpenACS strežnik. • Zahtevi za vzpostavitev transakcijske seje z OpenACS strežnika.

Pri vseh testih TR-069 programski modul pošilja sporočilo Inform na OpenACS strežnik. Slika 37 prikazuje TR-069 sporočilo Inform, ki ga je pri testiranju pošiljala VoIP naprava na OpenACS strežnik.

Slika 37: TR-069 sporočilo Inform zahteva (Vir: lasten)



Pri ustrezno sprejetem sporočilu TR-069 Inform je OpenACS strežnik poslal odgovor (slika 38).

Slika 38: TR-069 sporočilo Inform potrditev (Vir: lasten)

<SOAP-ENV:Envelope xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:cwmp="urn:dslforum-org:cwmp-1-0" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SOAP-ENV:Header> <cwmp:ID SOAP-ENV:mustUnderstand="1"> 1 </cwmp:ID> <cwmp:NoMoreRequests> 0 </cwmp:NoMoreRequests> </SOAP-ENV:Header> <SOAP-ENV:Body> <cwmp:InformResponse xmlns:cwmp="urn:dslforum-org:cwmp-1-0"> <MaxEnvelopes> 1 </MaxEnvelopes> </cwmp:InformResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>



Registracija VoIP naprave na OpenACS strežnik: Slika 39 prikazuje nastavitveno okno OpenACS strežnika, v katerem poiščemo VoIP napravo. Če se je VoIP naprava uspešno registrirala na OpenACS strežnik, potem jo najdemo v tem oknu. Išče se po serijski številki, ki je vidna v TR-069 sporočilu Inform. Pri testiranju se nam je dogajalo, da VoIP naprava ni bila najdena. To je pomenilo, da smo pošiljali neustrezno TR-069 sporočilo Inform. Sporočilo smo tako dolgo spreminjali, dokler ni bila najdena. Spremembe sporočila so vplivale na spremembe v programski kodi za TR-069 programski modul.

Slika 39: Iskanje VoIP naprave na OpenACS strežniku (Vir: lasten)



Periodična registracija VoIP naprave na OpenACS strežnik: Test je odvisen od uspešnega testa registracije VoIP naprave na OpenACS strežnik. Če se VoIP naprava ni registrirala, potem tudi periodična registracija ne bo delovala. Slika 40 prikazuje nastavitveno okno za periodično registracijo na OpenACS strežniku.

Slika 40: Periodočna nastavitev transkacijske seje na OpenACS strežniku (Vir: lasten)

Nastavitev za periodično registracijo smo preverili tako, da je VoIP naprava morala dobiti TR-069 sporočilo SetparameterValues s parametri za nastavitev periodične registracije. OpenACS strežnik je poslal to sporočilo v primeru, da so se vrednosti teh parametrov razlikovale med VoIP napravo in nastavitvami na OpenACS strežniku. OpenACS je nastavitve na VoIP napravi preveril s poslanim TR-069 sporočilom GetParameterValues. Pri enakih vrednostih parametrov OpenACS strežnik ni nastavljal teh parametrov. OpenACS strežnik je v testih preverjal nastavitve za periodično registracijo vedno po uspešno vzpostavljeni transakcijski seji oz. po uspešno potrjenem TR-069 sporočilu Inform. Na programskem modulu TR-069 smo preverili, če se periodično pošilja registracija na OpenACS strežnik glede na nastavitve parametrov za periodično registracijo. Pri vključeni periodični registraciji je VoIP naprava morala pošiljati TR-069 sporočila Inform z nastavljeno časovno periodo. Časovna perioda je morala ustrezati minimalni toleranci zakasnitve.



Zahteva za vzpostavitev transakcijske seje z OpenACS strežnika: Test je odvisen od uspešnega testa registracije VoIP naprave na OpenACS strežnik. Test smo naredili tako, da smo kliknili na povezavo Connection request URL: (slika 41). OpenACS je poslal na VoIP napravo sporočilo HTTP GET. VoIP naprava je poslala na OpenACS strežnik TR-069 sporočilo Inform in s tem vzpostavila transakcijsko sejo z dogodkom 6 CONNECTION REQUEST.

Slika 41: Zahteva za vzpostavitev transakcijske seje na OpenACS strežniku (Vir: lasten)



6.1.2. Testiranje konfiguracijske skripte

Za testiranje smo uporabili privzeto skripto na OpenACS strežniku, v katero smo dodali konfiguracijsko skripto za VoIP. Slika 42 prikazuje nastavitveno okno za dodajanje konfiguracijske skripte na OpenACS strežniku. OpenACS strežnik izvede privzeto skripto po sprejetem TR-069 sporočilu Inform z dogodkom 6 CONNECTION REQUEST, ki ga pošlje VoIP naprava.

Slika 42: OpenACS dodajanje konfiguracijske skripte (Vir: lasten)

Pri testu smo uporabili vse konfiguracijske parametre, ki jih je možno nastavljati na VoIP napravi. Konfiguracijske parametre smo dodali v OpenACS konfiguracijsko skripto z OpenACS funkcijama SetParameterValues in AddObject. OpenACS strežnik je na podlagi teh funkcij pošiljal TR-069 sporočili SetParameterValues in AddObject na VoIP napravo. V orodju Wireshark smo preverili, ali so bila vsa sporočila uspešno potrjena brez napak. Preverili smo tudi, ali so se vse spremembe vpisale v XML konfiguracijsko datoteko na VoIP napravi. Pri tem testiranju smo zaradi nepravilne pretvorbe naleteli na veliko napak na podatkovnem modelu. Programsko kodo na TR-069 programskem modulu smo popravljali, dokler ni bilo nobene napake. S konfiguracijsko skripto smo preverili delovanje celotnega podatkovnega modela.



6.1.3. Testiranje TR-069 sporočil

Testiranje smo izvajali podobno kot pri testiranju konfiguracijske skripte. Za testiranje posameznega TR-069 sporočila smo v privzeto skripto na OpenACS strežniku dodali v polje 6 CONNECTION REQUEST parametre in funkcijo. Po zahtevi za vzpostavitev transakcijske seje z OpenACS strežnika in prispelem TR-069 sporočilu Inform z dogodkom 6 CONNECTION REQUEST se je izvedla funkcija, ki smo jo dodali v privzeto skripto. OpenACS je na podlagi funkcije poslal TR-069 sporočilo na VoIP napravo. Vsa TR-069 sporočila, ki jih pošilja OpenACS strežnik, imajo podobno strukturo. Vidimo jo lahko na sliki 43. Razlika med sporočili je v vsebini, telesu in glavi (ID).

Slika 43: TR-069 sporočilo z OpenACS strežnika (Vir: lasten)

<SOAP-ENV:Envelope xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:cwmp="urn:dslforum-org:cwmp-1-0" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SOAP-ENV:Header> <cwmp:ID SOAP-ENV:mustUnderstand="1"> ID:intrnl.unset.id.SetParameterValues1450865188137.30587065 </cwmp:ID> <cwmp:NoMoreRequests> 0 </cwmp:NoMoreRequests> </SOAP-ENV:Header> <SOAP-ENV:Body> <cwmp:SetParameterValues xmlns:cwmp="urn:dslforum-org:cwmp-1-0"> <ParameterList SOAP-ENC:arrayType="cwmp:ParameterValueStruct[1]"> <ParameterValueStruct> <Name> InternetGatewayDevice.ManagementServer.PeriodicInformInterval </Name> <Value xsi:type="unsignedInt"> 120 </Value> </ParameterValueStruct> </ParameterList> <ParameterKey> unsetCommandKey </ParameterKey> </cwmp:SetParameterValues> </SOAP-ENV:Body> </SOAP-ENV:Envelope>



VoIP naprava je za vsako prispelo TR-069 sporočilo od OpenACS strežnika poslala potrditveno sporočilo oz. sporočilo za napako. Testirali smo TR-069 sporočila z ustreznimi in neustreznimi parametri. Pri ustreznih je VoIP naprava morala poslati potrditveno sporočilo, pri neustreznih pa sporočilo za napako. Pri drugačnih sporočilih od pričakovanih smo morali popravljati programsko kodo v TR-069 programskem modulu, dokler ta niso bila ustrezna.

Slika 44 prikazuje potrditveno sporočilo iz VoIP naprave.

Slika 44: TR-069 sporočilo iz VoIP naprave (Vir: lasten)

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns1="http://www.iskratel.si/cwmp.wsdl" xmlns:cwmp="urn:dslforum-org:cwmp-1-0" xmlns:itLocal="urn:LCIskratel"> <SOAP-ENV:Header> <cwmp:ID SOAP-ENV:mustUnderstand="1"> ID:intrnl.unset.id.SetParameterValues1450951688491.26107155 </cwmp:ID> </SOAP-ENV:Header> <SOAP-ENV:Body> <cwmp:SetParameterValuesResponse> <Status> 0 </Status> </cwmp:SetParameterValuesResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>



Slika 45 prikazuje sporočilo za napako, ki jo pošlje VoIP naprava pri ugotovljeni napaki. Sporočilo se razlikuje glede na tip napake in vsebuje ustrezno kodo napake.

Slika 45: TR-069 sporočilo za napako iz VoIP naprave (Vir: lasten)

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns1="http://www.iskratel.si/cwmp.wsdl" xmlns:cwmp="urn:dslforum-org:cwmp-1-0" xmlns:itLocal="urn:LCIskratel"> <SOAP-ENV:Header> <cwmp:ID SOAP-ENV:mustUnderstand="1"> ID:intrnl.unset.id. SetParameterValues1450951688491.26107155 </cwmp:ID> </SOAP-ENV:Header> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode> SOAP-ENV:Client </faultcode> <faultstring> CWMP Fault </faultstring> <detail> <FaultCode> 9002 </FaultCode> <FaultString> Internal error </FaultString> </detail> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope>



Testiranje TR-069 sporočila GetRPCMethods: V privzeto skripto smo na OpenACS strežniku dodali funkcijo cpe.GetRPCMethods. OpenACS strežnik je pri izvedbi skripte poslal TR-069 sporočilo GetRPCMethods na VoIP napravo. Pri testiranju smo preverjali:

• Ali je VoIP naprava sprejela sporočilo. • Ali je VoIP naprava poslala potrditveno sporočilo s podatki o vseh TR-069

sporočilih, ki jih podpira. Testiranje smo ponovili večkrat. Pri vsakem testu je morala VoIP naprava poslati potrditveno sporočilo brez napake. V primeru poslanega sporočila z napako smo morali odpraviti vzrok zanjo. Testiranje TR-069 sporočila GetParameterValues: V privzeto skripto smo na OpenACS strežniku dodali funkcijo cpe. GetParameterValues. OpenACS strežnik je pri izvedbi skripte poslal TR-069 sporočilo GetParameterValues na VoIP napravo. Pri testiranju smo preverjali:

• Ali je VoIP naprava sprejela sporočilo. • Ali je VoIP naprava poslala potrditveno sporočilo z vrednostmi zahtevanih

konfiguracijskih parametrov, ki so podprti na njej. • Ali je VoIP naprava poslala sporočilo z napako, da konfiguracijski

parameter ne obstaja, če ta na njej ni podprt. Testiranje TR-069 sporočila SetParameterValues: V privzeto skripto smo na OpenACS strežniku dodali funkcijo cpe. SetParameterValues. OpenACS strežnik je pri izvedbi skripte poslal TR-069 sporočilo SetParameterValues na VoIP napravo. Pri testiranju smo preverjali:

• Ali je VoIP naprava sprejela sporočilo. • Ali je VoIP naprava poslala potrditveno sporočilo s statusom uspešne

nastavitve. • Ali je VoIP naprava poslala sporočilo z napako, da konfiguracijski

parameter ne obstaja, če ta na njej ni podprt. • Ali je VoIP naprava poslala sporočilo z napako, da konfiguracijski

parameter nima ustrezne vrednosti. • Ali je VoIP naprava poslala sporočilo z napako, da konfiguracijski

parameter ni zapisljiv.



Testiranje TR-069 sporočila GetParameterNames: V privzeto skripto smo na OpenACS strežniku dodali funkcijo cpe. GetParameterNames. OpenACS strežnik je pri izvedbi skripte poslal TR-069 sporočilo GetParameterNames na VoIP napravo. Pri testiranju smo preverjali:

• Ali je VoIP naprava sprejela sporočilo. • Ali je VoIP naprava poslala potrditveno sporočilo s podatki o imenih

konfiguracijskih parametrov oz. tabel. • Ali je VoIP naprava poslala sporočilo z napako, da konfiguracijska tabela ne

obstaja, če ta na njej ni podprta. Testiranje TR-069 sporočila AddObject: V privzeto skripto smo na OpenACS strežniku dodali funkcijo cpe.AddObject. OpenACS strežnik je pri izvedbi skripte poslal TR-069 sporočilo AddObject na VoIP napravo. Pri testiranju smo preverjali:

• Ali je VoIP naprava sprejela sporočilo. • Ali je VoIP naprava poslala potrditveno sporočilo s podatkom o indeksu

nove vrstice v podani tabeli. • Ali je VoIP naprava poslala sporočilo z napako, da konfiguracijska tabela ne

obstaja, če ta na njej ni podprta. Testiranje TR-069 sporočila DeleteObject: V privzeto skripto smo na OpenACS strežniku dodali funkcijo cpe.DeleteObject. OpenACS strežnik je pri izvedbi skripte poslal TR-069 sporočilo DeleteObject na VoIP napravo. Pri testiranju smo preverjali:

• Ali je VoIP naprava sprejela sporočilo. • Ali je VoIP naprava poslala potrditveno sporočilo s podatkom o uspešnem

brisanju vrstice iz podane tabele. • Ali je VoIP naprava poslala sporočilo z napako, da konfiguracijska tabela ne

obstaja, če ta na njej ni podprta. • Ali je VoIP naprava poslala sporočilo z napako, da indeks v konfiguracijski

tabeli ne obstaja. Testiranje TR-069 sporočila Reboot: V privzeto skripto smo na OpenACS strežniku dodali funkcijo cpe.Reboot. OpenACS strežnik je pri izvedbi skripte poslal TR-069 sporočilo Reboot na VoIP napravo. Pri testiranju smo preverjali:

• Ali je VoIP naprava sprejela sporočilo. • Ali je VoIP naprava poslala potrditveno sporočilo s podatkom o njenem

uspešnem ponovnem zagonu.



Testiranje TR-069 sporočila FactoryReset: V privzeto skripto smo na OpenACS strežniku dodali funkcijo cpe.FactoryReset. OpenACS strežnik je pri izvedbi skripte poslal TR-069 sporočilo FactoryReset na VoIP napravo. Pri testiranju smo preverjali:

• Ali je VoIP naprava sprejela sporočilo. • Ali je VoIP naprava poslala potrditveno sporočilo s podatkom o uspešni

spremembi celotne konfiguracije na privzeto konfiguracijo na njej. • Ali je VoIP naprava poslala sporočilo z napako, da se konfiguracija na njej

ni spremenila na privzetonjej. Testiranje TR-069 sporočila Download: V privzeto skripto smo na OpenACS strežniku dodali funkcijo cpe.Download. OpenACS strežnik je pri izvedbi skripte poslal TR-069 sporočilo Download na VoIP napravo. Pri testiranju smo preverjali:

• Ali je VoIP naprava sprejela sporočilo. • Ali je VoIP naprava poslala potrditveno sporočilo s podatkom o uspešno

izvedeni download proceduri na VoIP napravi. • Ali je VoIP naprava poslala sporočilo z napako, da se download procedura

na njej ni izvedla. Testiranje TR-069 sporočila Upload: V privzeto skripto smo na OpenACS strežniku dodali funkcijo cpe.Upload. OpenACS strežnik je pri izvedbi skripte poslal TR-069 sporočilo Upload na VoIP napravo. Pri testiranju smo preverjali:

• Ali je VoIP naprava sprejela sporočilo. • Ali je VoIP naprava poslala potrditveno sporočilo s podatkom o uspešno

izvedeni upload proceduri na njej. • Ali je VoIP naprava poslala sporočilo z napako, da se upload procedura na

njej ni izvedla.



6.2. VERIFIKACIJA

Verifikacijska skupina je preverjala celotno programsko opremo na VoIP napravi. Verifikacija vedno pretestira celoten produkt in ne samo del funkcionalnosti. Poudarek so imeli na testiranju TR-069 funkcionalnosti, ki so jo preverili glede na zahteve in omejitve podane v funkcijskem dokumentu. Celoten produkt so preverjali zaradi dodanih sprememb za TR-069 funkcionalnost. Napak pri delovanju govornih zvez na VoIP napravi niso ugotovili. Razvojno testiranje, ki smo ga opravili pri razvoju programske rešitve TR-069 na VoIP napravi, je ključno za verifikacijo, da ta ne izgublja časa z nedelovanjem TR-069 funkcionalnosti. Naredili smo ga na na odprtokodnem OpenACS strežniku, zato ker nismo imeli licenčnega ACS strežnika in zato ker je kupec izrazil željo, da bo uporabljal tudi OpenACS strežnik. Verifikacija pa je izvajala testiranje zraven OpenACS strežnika tudi na drugem priznanem licenčnem ACS strežniku, ker OpenACS ni bistven. Zaradi testiranja na licenčnem ACS strežniku smo imeli veliko napak, saj je ta deloval malo drugače. Verifikacija nam je prijavila vse odkrite napake na obeh ACS strežnikih. V razvojnem oddelku, katerega del je tudi verifikacija, imamo orodje za spremljanje zahtev, v katerih so lahko podane napake, nove funkcije in izboljšava obstoječih funkcij. Večino teh napak smo odpravili in poslali VoIP paket nazaj v testiranje. Verifikacija je nadaljevala testiranje in preverila prijavljene napake. Pri ponovnem testiranju so ugotovili dodatne napake in jih ponovno prijavili. Proces testiranja in popravljanja napak se je ponovil trikrat, dokler niso bili večinoma vsi testi uspešni. Po uspešni verifikaciji je bil programski paket za VoIP napravo na voljo kupcu. Verifikacija je zelo pomembna, saj si ne smemo dovoliti, da se napake rešujejo pri kupcu. To nam zagotavlja dobro ime podjetja in nadaljnje poslovanje z njim. Reševanje napak pri kupcu je veliko dražje za podjetje. V verifikacijski skupini niso vedno zaposleni razvijalci oz. programerji, kar pomeni, da imajo drugačen pogled na testiranje kot programer, ki je naredil programsko kodo in jo testiral. S tem se zagotovi obširno testiranje in odprava večine napak.



7. ZAKLJUČEK

Uporaba standarda TR-069 na obstoječem VoIP produktu je zahtevala veliko razvojnih aktivnosti. Vse razvojne aktivnosti smo zaključili v določenem času. Prvotna ocena vložka je bila pravilno ocenjena, kar je zelo pomembno za kupca, kdaj lahko pričakuje obljubljeno rešitev. Za dobro ocenitev je potrebno veliko znanja, izkušenj in predvsem dobro poznavanje VoIP produkta. Pri razvojnih aktivnostih B100 in B400 sem sodeloval kot glavni programer z več kot desetletnimi izkušnjami s programskim jezikom C/C++ in vgrajenimi sistemi. Zadane cilje smo uspešno realizirali. Končno analizo bomo podali v SWOT analizi, ki jo lahko vidimo v tabeli 2.

PREDNOSTI SLABOSTI

• Prodaja VoIP naprav pri kupcu, ki je zahteval TR-069 funkcionalnost.

• Prodaja drugih naprav oz. opreme pri istem kupcu zaradi uspešno realizirane VoIP naprave s TR-069 funkcionalnostjo.

• Zagotovljeno nadaljnje sodelovanje s kupcem.

• Modularni programski modul TR-069.

• Možnost napak pri delovanju

VoIP naprave pri kupcu, kljub celovitemu testiranju in verifikaciji.

• Dodatno vzdrževanje in razvojni stroški za podjetje.

• Poraba skupnega spomina na VoIP napravi in problem s kasnejšim dodajanjem programske kode, kar lahko privede do prenove strojne opreme.

PRILOŽNOSTI GROŽNJE • Možnost prodaje VoIP naprave

pri drugih kupcih, kjer konkurenca ponuja podobno rešitev.

• Možnost uporabe programskega modula TR-069 na drugih produktih z minimalnim vložkom razvojnih aktivnosti in povečanje konkurenčne prednosti pri kupcih.

• Konkurenca s podobnim

produktom. • Konkurenca s podprtim TR-069

standardom brez omejitev. TR-069 standard je podprt v celoti.

Tabela 2: SWOT analiza za uporabo standarda TR-069 na VoIP produktu

(Vir: lasten)



VoIP naprava se že prodaja na trgu nekaj let. Največja slabost uporabe standarda TR-069 na VoIP produktu je, da lahko spremembe programske opreme vplivajo negativno na osnovno delovanje VoIP naprave, za kar je namenjena – govor med naročniki. Kljub celovitemu testiranju v razvoju in verifikaciji se na terenu pokažejo problemi, ki jih je težko oz. nemogoče ponoviti v laboratoriju. Takšni problemi so najtežji in jih je težko odpraviti. Velikokrat je potrebna fizična prisotnost razvijalca na terenu. Da se temu izognemo, je treba definirati dober dizajn že od začetka in stremeti k temu, da je čim manj prepletanja med različnimi programskimi moduli. Pri uporabi standarda TR-069 na VoIP produktu je bil naš cilj od začetka do konca narediti neodvisen programski modul, ki smo ga pri implementaciji upoštevali in minimalno posegali v spremembo obstoječe programske opreme. Vendar se moramo zavedati, da lahko zaradi operacijskega sistema, ki je skupen vsem programskim modulom, posredno vplivamo na nedelovanje VoIP naprave. Problemi, ki se lahko pojavijo, so:

• Nesproščanje spomina in s tem poraba celotnega spomina. • Trajni zaklep procesa in s tem onemogočanje delovanja drugih procesov.

VoIP naprava je vgrajeni sistem, ki deluje v realnem času. To pomeni, da se programska koda ne izvaja samo koračno, ampak se celotna izvaja istočasno. To pa pomeni nešteto možnih kombinacij v njenem delovanju. Ena takšna kombinacija, ki je nismo odkrili v razvoju, lahko pri kupcu povzroči takšne probleme, da bi na koncu bilo boljše, da se nismo odločili za realizacijo. Pri enem oz. več kupcih se lahko nahaja ogromno število VoIP naprav. Nadgradnja programskega paketa, v katerem je dodan TR-069 programski modul na vse te naprave, bi v primeru napake lahko povzročila nezmožnost govornih zvez med ogromnim številom naročnikov, ki plačujejo te storitve našemu kupcu. Zaenkrat nimamo nobenih pritožb nad delovanjem pri kupcu. Rad bi se zahvalil vsem sodelujočim, ki so pripomogli, da je projekt uporaba standarda TR-069 na VoIP produktu uspel.



8. LITERATURA

Knjige: 1. Erich Gamma: Design Patterns – Elements of reusable object oriented

software, Addison Wesley, USA, 1995. 2. Linda Rising: Design Patterns in communications software, Cambridge

University press, UK, 2001. Članki:

3. https://tr069.wordpress.com/2012/10/30/a-tr-069-acs-deal-under-the-microscope/

4. https://tr069.wordpress.com/2012/09/10/open-source-tr-069-efforts/ Spletne strani:

5. https://www.broadband-forum.org/technical/download/TR-069.pdf (10. 6. 2015)



8. https://www.broadband-forum.org/cwmp.php (10. 6. 2015) 9. http://www.cs.fsu.edu/~engelen/soap.html (15. 1. 2016) 10. http://openacs.org/ (15. 1. 2016) 11. http://sourceforge.net/projects/openacs/ (15. 1. 2016) 12. https://www.w3.org/TR/soap/ (15. 1. 2016) 13. https://www.w3.org/TR/wsdl (15. 1. 2016) 14. https://www.w3.org/XML/Schema (15. 1. 2016)



KAZALO SLIK Slika 1: CWMP arhitektura ........................................................................................ 7

Slika 2: CPE seja ....................................................................................................... 8

Slika 3: Asinhrona ACS seja ...................................................................................... 8

Slika 4: Začetna vzpostavitev CPE na ACS .............................................................. 10

Slika 5: Periodična vzpostavitev CPE seje .............................................................. 10

Slika 6: TR-069 sporočilo GetRPCMethods .............................................................. 11

Slika 7: TR-069 sporočilo Reboot ............................................................................ 12

Slika 8: TR-069 sporočilo FactoryReset .................................................................. 13

Slika 9: TR-069 sporočilo Download ....................................................................... 14

Slika 10: TR-069 sporočilo Upload .......................................................................... 15

Slika 11: TR-069 sporočilo SetParameterValues ..................................................... 16

Slika 12: TR-069 sporočilo GetParameterValues .................................................... 17

Slika 13: TR-069 sporočilo GetParameterNames .................................................... 18

Slika 14: TR-069 sporočilo AddObject .................................................................... 19

Slika 15: TR-069 sporočilo DeleteObject ................................................................ 20

Slika 16: Sporočilo Cookie ...................................................................................... 21

Slika 17: Sporočilo za neuspešno izvedeno RPC funkcijo ....................................... 21

Slika 18: Zgradba SOAP sporočila ........................................................................... 22

Slika 19: WSDL zgradba .......................................................................................... 23

Slika 20: Uporaba gSOAP knjižnice ......................................................................... 24

Slika 21: Obstoječa VoIP arhitektura...................................................................... 27

Slika 22: Pretvorba podatkovnega modela ............................................................. 29

Slika 23: XML konfiguracijski podatki ..................................................................... 30

Slika 24: Drevesna struktura podatkovnega modela TR-098 ................................... 31

Slika 25: Pretvorba podatkovnega modela TR-069 ................................................. 32

Slika 26: VoIP arhitektura programske opreme z dodanim programskim modulom 34

Slika 27: TR-069 proces .......................................................................................... 35

Slika 28: Izvajanje TR-069 procesa ........................................................................ 36

Slika 29: UML diagram TR-069 izhodni vmesnik za dostop do konfiguracijskih podatkov s prazno implementacijo vmesnika......................................................... 37

Slika 30: UML diagram TR-069 izhodni vmesnik za dostop do konfiguracijskih podatkov z implementacijo vmesnika na XML programskem modulu ..................... 37

Slika 31: UML diagram relacije med programskim modulom TR-069 in XML .......... 38

Slika 32: UML diagram, sistemska knjižnica ........................................................... 39

Slika 33: TR-069 WSDL specifikacija ....................................................................... 40

Slika 34: gSOAP TR-069 WSDL uvoznik .................................................................... 41

Slika 35: gSOAP TR-069 RPC prevajalnik ................................................................ 42

Slika 36: UML diagram programske opreme TR-069 ............................................... 43

Slika 37: TR-069 sporočilo Inform zahteva ........................................................... 45

Slika 38: TR-069 sporočilo Inform potrditev ........................................................ 46

Slika 39: Iskanje VoIP naprave na OpenACS strežniku ............................................ 47

Slika 40: Periodočna nastavitev transkacijske seje na OpenACS strežniku ............ 48

Slika 41: Zahteva za vzpostavitev transakcijske seje na OpenACS strežniku ......... 49

Slika 42: OpenACS dodajanje konfiguracijske skripte ............................................ 50

Slika 43: TR-069 sporočilo z OpenACS strežnika ..................................................... 51

Slika 44: TR-069 sporočilo iz VoIP naprave ............................................................. 52

Slika 45: TR-069 sporočilo za napako iz VoIP naprave ............................................ 53



KAZALO TABEL Tabela 1: Dogodki Inform ......................................................................................... 9

Tabela 2: SWOT analiza za uporabo standarda TR-069 na VoIP produktu .............. 58

KRATICE IN AKRONIMI TR-069: Technical Report 069: Tehnična specifikacija, ki določa protokol za

daljinsko upravljanje končnih naprav. SOAP: Simple Object Access Protocol: Enostaven objektni dostopovni

protokol. WSDL: Web Services Description Languages: Opisni jezik za spletne storitve. XML: Extensible Markup Language: Razširljivi označevalni jezik. XSD: XML Schema Definition: Definicija XML sheme. HTTP: HyperText Transfer Protocol: Protokol za prenos hiperteksta. RPC: Remote Procedure Call: Klic za oddaljeni postopek. SIP: Session Initiation Protocol: Protokol za vzpostavitev seje. P2P: Peer-to-peer: Vsak z vsakim. IP: Internet Protocol: Internetni protokol. TCP: Transmission Control Protocol: Protokol za krmiljenje transporta. VoIP: Voice over Internet Protocol: Govor prek IP. CWMP: CPE WAN Management Protocol: CPE WAN upravljalni protokol. ACS: Auto Configuration Server: Avtokonfiguracijski strežnik. CPE: Customer Provided Equipment: Uporabniška oprema. IGD: Internet Gateway Device. UML The Unified Modeling Language: Poenoteni jezik za modeliranje. MIB: Management Information Base: Baza upravljalskih informacij. SNMP: Simple Network Management Protocol: Preprosti protokol za

upravljanje omrežja. WAN: Wide Area Network: Prostrano omrežje. LAN: Local Area Network: Lokalno omrežje. POST: HTTP Request method for store the information: HTTP zahteva za

shranjevanje podatkov. GET: HTTP Request method for retrieve information: HTTP zahteva za

pridobitev podatkov. JAVA: Computer Programming Language Object Oriented: Objektno

orientirani programski jezik. .NET: Microsoft Software Framework: Microsoft programski jezik.

gSOAP: C/C++ Toolkit for SOAP: C/C++ orodje za SOAP.

API: Application Programming Interface: Vmesnik uporabniškega programa.

DOM: XML Document Object Model: Objektni model dokumenta.

SAX: Simple API for XML: Enostaven API za XML.

RAM: Random Access Memory: Pomnilnik z naključnim dostopom.

DHCP: Dynamic Host Configuration Protocol: Protokol za dinamično konfiguriranje gostiteljskih računalnikov.

CLI: Command line interface: Vrstični ukazni vmesnik.

UPORABA STANDARDA TR-069 NA VoIP PRODUKTU · ABSTRACT The aim of the thesis is to show the software...

Documents

Transcript of UPORABA STANDARDA TR-069 NA VoIP PRODUKTU · ABSTRACT The aim of the thesis is to show the software...