new forord - iik ntnupeople.item.ntnu.no/~lillk/stud-proj/tunheim-foerster... · 2003. 11. 26. ·...

Nye tjenester på tvers av ulike nettverksteknologier

i

FORORD

Denne rapporten er et resultat av prosjektarbeidet i 9. semester ved sivilingeniørutdanningen ved Norges teknisk-naturvitenskapelige universitet, NTNU. Arbeidet ble utført ved Telenor FoU og ved NTNU i Trondheim høsten 2003. Oppgaven ble foreslått av Josip Zoric ved Telenor FoU. Veiledere har vært Josip Zoric og Steinar Brede ved Telenor FoU, og faglærer har vært professor Lill Kristiansen ved institutt for Telematikk, NTNU. Vi ønsker å rette en stor takk til Josip Zoric for støtte og nyttige innspill under den praktiske gjennomføringen av arbeidet. Vi vil også gjerne takke Ingebrigt Fuglem og Arild Herstad ved Telenor Fou for hjelp under implementering av systemet som ble laget. Til slutt vil vi takke Gisle Grimen for gode råd og hjelp underveis i arbeidet.


ii


iii

SAMMENDRAG

Denne oppgaven tar for seg nye tjenester som baseres på interaksjonen mellom globale nettverk og ad-hoc nettverk. Tjenestene i oppgaven bygger videre på ideer fra Hewlett-Packard sitt Cooltown-konsept. Cooltown tar i bruk ad-hoc nettverk for å gi nye tjenester, der sensorer basert på infrarød teknologi og ressurser i det globale nettet anvendes. Siden oppgaven tar for seg interaksjonen mellom globale nettverk og ad-hoc nettverk, gis det definisjoner på hva vi mener med dette. Interaksjonen mellom ad-hoc nettverk og det globale nettet studeres ved hjelp av brukerscenarioer. Scenarioene blir presentert for å vise eksempler på tjenester. Hensikten med eksemplene er å gi et innblikk i hvilke muligheter som ligger i interaksjonen, og å vise ulike arenaer der slike tjenester kan tas i bruk. Ulike teknologier kan anvendes i nettverkene. I det globale nettet ser vi på GSM, GPRS og UMTS. I ad-hoc nettverket ser vi blant annet på WLAN, Bluetooth og infrarød-teknologi. For hver teknologi blir det gitt en beskrivelse av virkemåte og arkitektur, og styrker og svakheter vurderes. I oppgaven realiserer vi en tjeneste for å demonstrere hvordan interaksjon mellom nettverkene kan fungere i praksis. Vi har valgt å bruke universitetet som arena for en slik tjeneste. Kort beskrevet vil en student få tilsendt nyttig informasjon på sin mobiltelefon når han/hun kommer inn på universitetsområdet. Eksempel på informasjon er at en forelesning er avlyst eller flyttet. Studenten blir lokalisert ved at han har en PDA som kjører et klientprogram for posisjonering. For å realisere tjenesten anvendes GSM-teknologi for å sende SMS. Wireless LAN utgjør ad-hoc nettverket, og for lokalisering av PDA blir det tatt i bruk en lokasjonsserver utviklet ved Telenor FoU. Systemet som implementeres er et ”proof of the concept”, og har ikke til hensikt å fungere som en fullverdig løsning. En utvidelse av funksjonaliteten i demotjenesten kan eventuelt bli realisert i en hovedoppgave.


iv


v

INNHOLDSFORTEGNELSE

FORORD ....................................................................................................................................i

SAMMENDRAG......................................................................................................................iii

INNHOLDSFORTEGNELSE .................................................................................................v

FIGURLISTE..........................................................................................................................vii

TABELLISTE ........................................................................................................................viii

FORKORTELSER ..................................................................................................................ix

1 INNLEDNING........................................................................................................................1

1.1 Bakgrunn ...........................................................................................................................1

1.2 Problemstilling ..................................................................................................................1

1.3 Avgrensninger ...................................................................................................................1

1.4 Oppbygning.......................................................................................................................2

2 DEFINISJONER....................................................................................................................3

2.1 Globalt nettverk .................................................................................................................3

2.2 Ad-hoc nettverk .................................................................................................................4

2.3 Cooltown ...........................................................................................................................4

3 NYE TJENESTER I INTERAKSJONEN MELLOM AD-HOC- OG GLOBALE

NETTVERK ..............................................................................................................................6

3.1 Gammel dame med dårlig helse........................................................................................6

3.2 Meldingssending ...............................................................................................................7

3.3 Musikk...............................................................................................................................7

4 OVERSIKT OVER MULIGE TEKNOLOGIER...............................................................9

4.1 Teknologier i globale nettverk ..........................................................................................9

4.1.1 GSM...........................................................................................................................9

4.1.2 GPRS .......................................................................................................................10

4.1.3 UMTS.......................................................................................................................12

4.1.4 Ny generasjons UMTS: IP Multimedia Subsystem ...............................................13

4.2 Teknologier i ad-hoc nettverk .........................................................................................14

4.2.1 WLAN – Wireless Local Area Network..................................................................15

4.2.2 Bluetooth .................................................................................................................17

4.2.3 SPIKE......................................................................................................................18

4.2.4 HomeRF ..................................................................................................................18

4.2.5 HIPERLAN2...........................................................................................................19


vi

4.2.6 Infrarød teknologi ...................................................................................................20

5 BRUKERSCENARIO FOR DEMOTJENESTEN ...........................................................21

5.1 Beskrivelse av brukerscenarioet ......................................................................................21

5.1.1. Scenario..................................................................................................................21

5.1.2. Beskrivelse av rammeverk .....................................................................................21

5.1.3. Begrensninger i rammeverket ...............................................................................22

5.2 Krav til det globale nettet................................................................................................22

5.3 Krav til ad-hoc nettverket................................................................................................23

6 TEKNOLOGIER ANVENDT I BRUKERSCENARIOET .............................................24

6.1 Parlay OSA......................................................................................................................24

6.2 Parlay X...........................................................................................................................27

6.3 Ekahaus Positioning Engine 2.0......................................................................................28

6.4 Lokasjonsserver...............................................................................................................29

6.5 GSM ................................................................................................................................30

7 ARKITEKTUR I BRUKERSCENARIOET .....................................................................31

7.1 Overordnet arkitektur ......................................................................................................31

7.1.1 Definisjon av globalt nett i brukerscenarioet.........................................................33

7.1.2 Definisjon av ad-hoc nett i brukerscenarioet.........................................................33

7.1.3 Struktur av demotjenesten ......................................................................................33

7.1.4 Klassediagram .........................................................................................................38

7.2 Drøfting rundt designvalg ...............................................................................................39

8 IMPLEMENTASJON .........................................................................................................41

8.1 Teknologier anvendt........................................................................................................41

8.2 Testing.............................................................................................................................41

9 KONKLUSJON....................................................................................................................43

REFERANSER .......................................................................................................................44

APPENDIKS: KILDEKODE ................................................................................................46


vii

FIGURLISTE

Figur 1 Enhet sender signaler til sensorer ...................................................................................6

Figur 2 Sending av MMS............................................................................................................8

Figur 3 Arkitektur i GSM-nettverket. [10] ...............................................................................10

Figur 4 GPRS-arkitektur [9] .....................................................................................................11

Figur 5 UMTS fra Rel-5; IP Multimedia Subsystem. [21] .......................................................14

Figur 6 WLAN infrasturktur topologi [14]...............................................................................16

Figur 7 WLAN ad-hoc topologi [20] ........................................................................................16

Figur 8 Arkitekturen til Parlay/OSA [32] .................................................................................25

Figur 9 Parlay Gateway består av flere Service Capability Servers [35] .................................26

Figur 10 Meldinger som går mellom Framework, applikasjon og SCS. [35]..........................26

Figur 11 Forholdet mellom Parlay X og Parlay API [48].........................................................28

Figur 12 Ekahau trådløs posisjonering [28] ..............................................................................29

Figur 13 Arkitektur over Lokasjonsserver................................................................................30

Figur 14 Overordnet arkitektur .................................................................................................32

Figur 15 Lagdelt arkitektur .......................................................................................................32

Figur 16 Lokaliseringsprosedyren ............................................................................................34

Figur 17 Meldingsflyt mellom klassene i meldingsapplikasjonen ...........................................35

Figur 18 Valg av tjeneste på Parlay/OSA .................................................................................36

Figur 19 Sending av melding ....................................................................................................37

Figur 20 SMS i GSM-nettet......................................................................................................38

Figur 21 Klassediagram ............................................................................................................39

Figur 22 Alternativt design for lokasjonsserver, med Parlay/OSA ..........................................40


viii

TABELLISTE

Tabell 1 Anvendte teknologier i implementasjonen....................................................41


ix

FORKORTELSER

Forkortelse Forklaring

ADSL AP API BSC BSS CORBA GPRS GSM HIPERLAN2 HP HSCSD IMS IP IR IrDA ISDN ISM LAN MMS MSC PAN PATS PDA SCS SMS SMSC UMTS URL UTRAN WAP W-CDMA WLAN

Asymmetric Digital Subscriber Line Aksesspunkt Application Programming Interface Base Station Controller Base Station Subsystem Common Object Request Broker Architecture General Packet Radio Service Global System for Mobile communication High Performance Radio LAN 2 Hewlett-Packard High Speed Circuit Switched Data IP Multimedia-Subsystem Internet Protocol Infrared Infrared Data Association Integrated Services Digital Network Industrial Scientific Medical Local Area Network Multimedia Message Service Mobile Switching Centre Personal Area Network Program for Advanced Telecom Services Personal Digital Assistant Service Capability Server Short Message Service SMS Centre Universal Mobile Telecommunication System Uniform Resource Locator Universal Terrestrial Radio Access Network Wireless Application Protocol Wideband Code-Division Multiple Access Wireless Local Area Network


x


1

1 INNLEDNING

1.1 Bakgrunn

I dag finnes det mange globale telekommunikasjonstjenester som SMS, MMS og WAP. Cooltown er et konsept utviklet av Hewlett-Packard som kombinerer web-teknologi, mobile enheter og trådløs kommunikasjon for å utforske nye mobile tjenester og systemer. Ressurser i nettet er koblet til fysiske steder og enheter, der brukere har interaksjon med ressursene ved hjelp av enhetene de bærer med seg. Ved å bygge videre på ideene bak Cooltown vil det i framtiden kunne lages nye tjenester som baseres på tjenesteinteraksjon mellom globale nettverk og ad-hoc nettverk. Eksempel på slike tjenester kan være et eldre menneske som er ustø til bens, og derfor bærer på et apparat som kommuniserer med sensorer i hjemmet. Dersom personen skulle falle om og bli liggende, vil systemet sørge for at nærmeste sykehus bli alarmert og en ambulanse bli sendt. Et annet eksempel kan være at man mottar en liste over de 10 mest kjøpte cd-singlene på PDAen når man ankommer en musikk-butikk, og kan laste ned en prøve for å høre på den. Slike tjenester skaper et behov for en effektiv og pålitelig interaksjon mellom globale nettverk og ad-hoc nettverk.

1.2 Problemstilling

Grunnlaget for denne oppgaven er følgende problemstillinger: • Hvordan kan tjenesteinteraksjon mellom tjenester i et ad-hoc-nettverk og et globalt

nettverk realiseres? • Hvilke typer tjenester gir denne interaksjonen muligheter for? • Hva er ideen bak Cooltown-teknologien? • Hvordan skal man definere ad-hoc-nettverk og globale nettverk? • Et brukerscenario skal utarbeides som rammeverk for nye tjenester i interaksjon

mellom ad-hoc-nettverk og globale nettverk. • Hvilke krav stilles til kandidatteknologier i brukerscenarioet? • En ”proof of the concept”-demo skal utarbeides.

1.3 Avgrensninger

For at prosjektoppgaven skal bli oversiktelig og helhetlig er det viktig å gjøre visse begrensninger. Uten disse avgrensningene ville prosjektoppgaven blitt for omfattende og lite sammenhengende. Følgende avgrensninger er derfor blitt gjort:

• Rammeverket som har blitt laget skal fungere som et ”proof of the concept”, og ikke være en fullstendig løsning på brukerscenarioet.

• Applikasjonen tar ikke hensyn til skalerbarhet, da dette ville tatt for lang tid å gjennomføre.

• Det er benyttet tilgjengelig teknologi i PATS-laben ved Telenor, og derfor ikke nødvendigvis den mest optimale teknologien.

• Ved vurdering av kandidat-teknologier er disse ikke blitt beskrevet til minste detalj. Det har blitt sett på de aspektene som er relevante i forhold til brukerscenarioet.

• Internett ses verken på som et globalt eller ad-hoc nett, og vil derfor ikke bli vurdert sammen med andre kandidatteknologier i rapporten.


2

• De alternative brukerscenarioene skal fungere som illustrasjoner på tjenester som bruker interaksjon mellom globale- og ad-hoc nettverk. Det er ikke ment å gi enn fullstendig teknisk løsning.

• Sikkerhetsaspektet ved interaksjonen mellom globale- og ad-hoc nettverk har ikke blitt vurdert.

1.4 Oppbygning

Prosjektoppgaven er inndelt i følgende kapitler: • Kapittel 2 tar for seg definisjoner på globale nettverk og ad-hoc nettverk. • Kapittel 3 beskriver nye typer tjenester i tjenesteinteraksjonen mellom ad-hoc nettverk

og globale nettverk, og gir en beskrivelse av Cooltown-teknologien. • Kapittel 4 tar for seg de ulike tilgjengelige teknologier for applikasjonen. • Kapittel 5 beskriver brukerscenarioet som er benyttet for implementasjonen i

oppgaven. • Kapittel 6 tar for seg de teknologier som er benyttet i applikasjonen. • Kapittel 7 beskriver arkitektur, sekvensdiagram og klassediagram for

implementasjonen. • Kapittel 8 beskriver verktøy benyttet under implementeringen. • Kapittel 9 er en konklusjon og diskusjon på prosjektoppgaven.

Vi har i oppgaven valgt å beskrive teknologier benyttet i applikasjonen før vi beskriver arkitekturen. Grunnen til dette er at vi måtte benytte teknologi som var tilgjengelig ved PATS-laben på Telenor, noe som igjen ble avgjørende for deler av arkitekturen. I oppgaven brukes ordene nettverk og nett synonymt.


3

2 DEFINISJONER

Interaksjonen mellom globalt nett og ad-hoc nettverk skaper et grunnlag for nye tjenester. Før disse tjenestene beskrives nærmere, er det nødvendig med definisjoner på globalt nett og ad-hoc nettverk. I dette kapittelet presenteres derfor definisjonene som brukes i denne oppgaven. I tillegg er det nødvendig med en innledning til Cooltown-teknologien [1] og hva visjonene til dette konseptet går ut på.

2.1 Globalt nettverk

Et globalt nett er et nettverk som spenner seg over store områder. Ordet globalt betyr verdensomspennende [2], men i dag finnes ikke noe nettverk som dekker hele verden. I denne oppgaven brukers derfor ordet globalt om et nettverk som dekker store deler av verden. Det har blitt valgt å se på følgende kriterier for definisjon av et globalt nettverk:

• Dekker store deler av verden • Fast infrastruktur (inkludert faste basestasjoner i et mobilnett) • Dedikerte ressurser • Kostnadsorientert bruk

Internett og telekommunikasjonsnettverk er nettverk som dekker store områder. Internett dekker store deler av verden og har noen dedikerte ressurser, men er selvkonfigurerende i den forstand at noder kan komme og gå. Egenskaper til Internett har blitt rangert av Øivind Kure i Telektronikk[3], og der ble ikke kostandsbasert bruk prioritert. Kostnatdsbasert bruk er noe vi ser på som en egenskap til et globalt nettverk. Når Internett også i en viss grad er selvkonfigurerende, velger vi i denne oppgaven å ikke se på Internett som et globalt nettverk. I rapporten brukes først og fremst det globale nettet i betydningen av telekommunikasjonsnett. I følge Network’s Telecom Dictionary [4] defineres telekommunikasjon som ”kommunikasjon over en avstand ved å bruke telefon, telegraf eller radio”. Telekommunikasjonsnett inkluderer trådløse mobilnett og det kablede telefonnettet. I denne oppgaven er det mobile nettet mest relevant, og det blir derfor lagt vekk på dette nettet i definisjonen av globale nettverk. Telekommunikasjonsnettverket eies av en teleoperatør og bruken av det belastes i form av tellerskritt eller mengde data sendt. GSM, GPRS og framtidens UMTS er globale telekommunikasjonsnett der mobiltelefonene er i bevegelse, mens dedikerte servere betjener enhetene og tilbyr tjenester. UMTS er enda ikke ferdig utbygd, men planlegges å få like stor utbredelse som GSM. GSM, GPRS og det kablede telefonnettet er i bruk i store områder i dag. I et globalt nett har man mulighet for et utvalg av ulike tjenester. Eksempler på dette er SMS, MMS, internettaksess og samtale. Med UMTS vil nye tjenester som for eksempel videotelefoni komme på markedet. Senere i oppgaven presenteres ulike brukerscenario som tar i bruk noen av tjenestene i det globale nettet.


4

2.2 Ad-hoc nettverk

Bruken av trådløs overføring av data mellom mobile enheter som mobiltelefoner, bærbare PCer og PDAer har blitt stadig mer populært de siste årene. Behovet for et enkelt trådløst nettverk, som kan settes opp raskt og uten noen form for infrastruktur, melder seg. Et ad-hoc nettverk kan være en samling av trådløse mobile enheter som dynamisk former et midlertidig nettverk uten noen underliggende infrastruktur eller sentralisert administrasjon. I denne oppgaven defineres også et ad-hoc nettverk som et nettverk mellom to enheter, der den ene er trådløs og den andre er et fast punkt i nettverket, for eksempel et aksesspunkt i WLAN. Et ad-hoc nettverk kan være et personal area network, PAN, eller andre mindre nettverk, der noen av enhetene kun er del av nettverket så lenge en sesjon pågår, eller så lenge de mobile trådløse enhetene befinner seg i umiddelbar nærhet til resten av nettverket. Den begrensede rekkevidden for trådløs kommunikasjon gjør at ikke alle nodene kan stå i direkte forbindelse til hverandre, og nodene må derfor kunne opptre som rutere. Bruksområder for ad-hoc nettverk kan være militær- eller redningsoperasjoner der det er behov for raskt å sette opp midlertidige forbindelser i ulendt terreng, eller et universitet med studenter som vil jobbe i nettverk med sine bærbare PCer eller PDAer. Mulige teknologier som kan brukes for å forme ad hoc nettverk er blant annet Bluetooth og Wireless Local Area Network (WLAN). [5],[6]

2.3 Cooltown

Cooltown er et prosjekt som Hewlett-Packard Labs arbeidet med for noen år siden. Deres visjon på fremtiden er at mennesker, steder og ting er koblet sammen trådløst. Konseptet ga et nytt syn på hvordan nettverkstjenester kan tas i bruk sammen med ad-hoc nettverksaksess. [1] Forskningsprogrammet til Cooltown er basert på HP sine underliggende overbevisninger om fremtiden. Disse deles i fem punkter:

1. Økende mangfold av mobil- og informasjonsprodukter, trådløse og kablede kommunikasjonsnettverk og multimediainnhold vil være det vanlige. Dette vil gi opphav til nye og sofistikerte tjenester som øker etterspørselen fra brukere. For å oppnå dette trengs åpne, bredt tilgjengelige standarder.

2. Internett er fremtiden. I motsetning til hemmeligholdte plattformer, består Internett av en nettverksinfrastruktur som er åpen, heterogen og standardbasert. Denne åpenheten og den store utbredelsen av Internett vil fortsette å gi grunnlag for å utvide et globalt sted for ideer, produkter og tjenester.

3. Alt har en tilstedeværelse på nettet. Mennesker, steder og ting i den fysiske verden vil ha en økende og kompleks presentasjon på nettet.

4. Bygge bro mellom den fysiske verden og den nett-tilkoblede verden. Fordelene med web services vil overføres til den fysiske verden, og ”online”-miljøet får tilgang til fysiske steder og enheter.

5. Koble sammen tjenestetilbydere. Tjenestetilbyderne vil lenkes sammen på en kreativ og produktiv måte.


5

Cooltown beskriver en teknologi som gir tjenester for mennesker i bevegelse, der vi ser en konvergens mellom web-teknologi, trådløse nettverk og bærbare enheter. Ressurser i nettet kobles til fysiske steder og enheter. Dette gir mulighet for lokasjonsspesifikke tjenester der man befinner seg, og gir mulighet for interaksjon med omgivelsene. Brukerne samhandler med ressursene ved å bruke apparater som de har med seg. Disse apparatene kan være bærbare PCer, mobiltelefoner, smartwatches1 og lignende. Mye av arbeidet i Cooltown fokuserer på å utvide nettverkteknologi, trådløse nett og bærbare enheter for å koble mobile brukere virtuelt til fysiske enheter og elektroniske tjenester. Nettverksteknologi har blitt integrert i digitale apparater og enheter som printere, radioer og lignende. Brukere kan automatisk oppdage nettressurser som er assosiert med ”nett-steder”. En mobilenhet blir en fjernkontroll av nett-tjenester. På kommando kan den aksessere og få tak i informasjon. Denne informasjonen overføres trådløst av enheter som kalles beacons. Slike beacons kringkaster en URL som representerer et objekt eller et sted. URLen peker på et nettsted som gir informasjon, underholdning, reklame eller gateway til nettjenester. I Cooltown kan URL-merker samles ved hjelp av direkte interaksjoner, meldingstjenester, synkrone applikasjoner og lignende. Ting får en presentasjon på nettet ved at de får bygget inn web-servere, eller ved at en web-server er vert for tingens tilstedeværelse på nettet. Steder får en presentasjon på nettet ved at de organiseres på nettet i en samling som håndteres av en web-service. Det er vanskelig å finne noe svar på hvorfor HP har avsluttet Cooltown-prosjektet, men andre har akseptert ideen bak konseptet og videreutviklet den. Dette gjelder for eksempel Bluetooth [7] og WLAN [8]. Trolig vil ideene bak Cooltown også gi grunnlag for nye teknologier og tjenester i framtiden. [1]

1 Armbåndsur med innebygd operativsystem.


6

3 NYE TJENESTER I INTERAKSJONEN MELLOM AD-HOC-

OG GLOBALE NETTVERK

Som nevnt tidligere, vil en interaksjon mellom ad-hoc nettverk og det globale nettet gi rom for nye typer tjenester. For å gi en nærmere forståelse, vil det i dette kapittelet bli vist eksempler på slike tjenester. Brukerscenario presenteres, og mulig teknologi som kan anvendes beskrives uten å gå i detalj. Meningen er å presentere ulike brukerscenario for å vise mulighetene som ligger i interaksjonen. Hensikten er ikke å gi en fullstendig teknisk løsning.

3.1 Gammel dame med dårlig helse

Hendelse

Navn: Jorunn Alder: 83 Jorunn sliter med dårlig helse, og er redd for å bli liggende hvis hun faller og er alene hjemme. Hun har derfor fått et system i hjemmet som skal gjøre at helsepersonell kontaktes automatisk hvis noe skjer. En dag skjer det hun fryktet; hun faller om på gulvet og klarer ikke å komme seg opp. I løpet av kort tid sendes automatisk én melding til datteren og én melding til hjemmehjelpen. Hjemmehjelpen drar til boligen for å se hva som har skjedd. Hvis nødvendig kontakter hun sykehuset.

Teknologi

Langs listene i huset finnes sensorer som registrerer når Jorunn faller. Hun bærer på et apparat (for eksempel en PDA eller en smartwatch) som kommuniserer med disse. Mellom apparatet og sensorene brukes Bluetooth-teknologi. Apparatet og de aktuelle sensorene danner et ad-hoc nettverk. For å sende en melding tas det globale nettverket i bruk, der en SMS sendes ved hjelp av GSM-nettverket. I dette tilfellet sendes én melding til datteren og én til hjemmehjelpen.

Figur 1 Enhet sender signaler til sensorer


7

Kommentarer

Andre teknologier er mulig. For eksempel kan WLAN brukes mellom apparatet som bæres på kroppen og sensorene langs veggen. I det globale nettet er GPRS eller UMTS alternative løsninger. I tillegg kan SMS sendes ved hjelp av ISDN eller ADSL.

3.2 Meldingssending

Hendelse

Navn: Marit Alder: 22 Marit er på skolen. Hun sender en melding til Lise for å høre om hun vil chatte. Lise mottar meldingen og ser at Marit er på skolen. Hun begynner å chatte med Marit over det lokale nettverket på skolen.

Teknologi

Den første SMS-meldingen går over GSM-nettverket. De etterfølgende meldingene under chattingen foregår over WLAN, der terminalene danner et ad-hoc nettverk seg imellom.

Kommentar

Fordelen ved å bruke det lokale nettet til en slik type tjeneste, er at kostnadene blir lavere enn om det globale nettet skulle brukes. Hvis man chatter over det globale nettet, vil brukeren bli belastet for hver melding som sendes fram og tilbake.

3.3 Musikk

Hendelse

Navn: Thea Alder: 18 Thea kommer inn i en CD-butikk og mottar ”topp10”- listen på sin PDA. Hun har lyst til å høre sangen som ligger på første plass og laster den derfor ned på terminalen sin. Sangen høres bra ut, og Thea sender den til venninnen sin Tone, for å høre hva hun synes.

Teknologi

I dette scenarioet dannes et ad-hoc nettverk mellom en sensor i butikken og Thea sin PDA. Globalnettet blir brukt for å laste ned musikk og for å sende en melding til venninnen Tone. Infrarød teknologi brukes mellom en sensor i butikken og Thea sin PDA. Hvis dette brukes, må brukeren gå nær en sensor for å få lastet ned listen, da infrarød teknologi har relativt kort rekkevidde og må ha klar sikt. UMTS brukes for å laste ned melodien fra Internett og for å sende sangen til Tone.


8

Figur 2 Sending av MMS

Kommentar

Listen over sangene kan eventuelt lastes ned ved å bruke et lokalt nettverk i butikken, men dette betyr at hver butikk må ha utstyr som gjør dette mulig.


9

4 OVERSIKT OVER MULIGE TEKNOLOGIER

I dette kapittelet vil vi ta for oss forskjellige kandidatteknologier innen globale nettverk og innen ad-hoc nettverk. Det vil bli gitt en generell beskrivelse av hver teknologi, og fordeler og ulemper nevnes.

4.1 Teknologier i globale nettverk

Det finnes mange ulike teknologier som kan benyttes i et globalt nettverk. Vi vil i dette delkapittelet ta for oss tre aktuelle teknologier, beskrive virkemåte og arkitektur, og gi en beskrivelse av hvilke styrker og svakheter teknologiene har i forhold til hverandre.

4.1.1 GSM

I 1982 ble det etablert en arbeidsgruppe for å utvikle det nye offentlige ”land mobile system” som skulle dekke Europa. Gruppen ble kalt Groupe Special Mobile (GSM) [9]. De foreslo blant annet følgende kriterier for det nye trådløse mobilsystemet:

• God talekvalitet • Lave kostnader for terminaler og tjenester • Internasjonal roaming • Håndholdte terminaler • Støtte for introduksjon av nye tjenester

Forkortelsen GSM står i dag for Global System for Mobile Communication. Dette systemet ble utviklet med tale som hovedapplikasjon og har derfor strenge sanntidskrav. Nye tjenester har etter hvert blitt lagt til og i dag tilbyr GSM SMS, WAP og linjesvitsjet data-overføring. Men alle disse tjenestene er basert på radio-aksess-grensesnittet til GSM, som kun tillater én bruker per kanal. Dette begrenser brukerbåndbredden og antall parallelle brukere som kan aksessere nettverket.

Arkitektur

De tre hoveddelene i GSM-systemet er (se figur 3): • Mobile Station: benyttes av brukeren. • Base Station Subsystem (BSS): kontrollerer radiolinken til mobilstasjonen. Hver BSS

er kontrollert av en Base Station Controller (BSC). • Kjernenettverket: håndterer alle linje-svitsjede tjenester til og fra mobilstasjonen.

Kjernenettet består av Mobile Switching Centre (MSC) og forskjellige registre som ivaretar det meste av funksjonaliteten. MSC fungerer som en sentral node i kjernenettet og ivaretar funksjonaliteten knyttet til svitsjing, registrering, autentisering, handover etc.


10

Figur 3 Arkitektur i GSM-nettverket. [10]

High Speed Circuit Switched Data

Maksimal overføringshastighet på data i GSM er i dag 9,6 kbps [11]. High Speed Circuit Switched Data (HSCSD) [12] tilbyr økt båndbredde for linje-svitsjet trådløs dataoverføring i GSM-nettet, med en hastighet fra 28,8 kbps og opp mot 57,6 kbps. Som navnet tilsier, tilbyr HSCSD økt båndbredde for linjesvitsjet data, og ikke for pakkesvitsjet data. Pakkesvitsjet data tilbys gjennom GPRS og blir beskrevet i neste delkapittel. HSCSD tilbyr aksess til Internett ved å sette opp en permanent forbindelse via GSM-kjernenettverket til en ISP. Under en forbindelse blir en kanal dedikert til brukeren, og brukes ikke av noen annen så lenge forbindelsen varer. Brukeren blir taksert per minutt under forbindelsen, som i en samtale.

Fordeler

• Stor utbredelse; applikasjoner basert på GSM gjør at de derfor kan brukes av mange. • God dekning.

Ulemper

• Ved nedlasting av data belastes man for tellerskritt som i en vanlig samtale. • Ved nedlasting av data må man først ha dial-up-modem for å koble seg til nettet. • Maksimal overføringshastighet på data i GSM er i dag 9,6 kbps

4.1.2 GPRS

General Packet Radio Service (GPRS) [13] tilbyr pakke-svitsjet trådløs dataoverføring og er et viktig skritt i retningen av 3.generasjons nettverk. Forbindelse gis med én gang slik at informasjon kan sendes eller mottas så fort det er nødvendig. Det trengs ikke dial-up modem,


11

og det er derfor GPRS refereres til som ”always on”. Denne umiddelbarheten er en av fordelene med GPRS i forhold til GSM. Teoretisk maksimumshastighet er ca. 179 kbps per kanal, men brukeren vil ikke oppleve dette, da dataraten forutsetter at der ikke skjer feilkorrigering og at alle 8 tidsluker blir brukt. Normal dataoverføring benytter feilkorrigering, noe som begrenser dataraten per tidsluke til ca 13 kbps. Ved å bruke GPRS for å koble seg til Internett takseres brukeren kun for mengde data lastet ned, og ikke for varigheten av samtalen slik som med GSM. Dette er fordi dataoverføringen i GPRS ikke har en slik betydning som en samtale i GSM. Ved forbindelse til Internett via GPRS deles en eller flere av de 14,4 tidslukene av flere brukere, og blir ikke dedikert til kun en bruker. Eksempler på tjenester som tilbys over GPRS er e-post, mobil- fax, informasjonstjenester, spill, lokasjonsbaserte tjenester, pakkesporing og reklame [9].

Arkitektur

GPRS bruker mange av de eksisterende GSM-komponentene og er derfor integrert i GSM-systemet. Noe funksjonalitet er lagt til. GPRS skal gi overføring av data i et eksternt pakkedata-nettverk. Mobilterminalen må blant annet ha støtte for GPRS for å ta dette nettverket i bruk, men GSM brukes fortsatt for samtaler der en har samme funksjonalitet som før [9]. Nedenfor vises arkitekturen til GPRS-nettverket.

Figur 4 GPRS-arkitektur [9]

Fordeler

• Betaling kun for mengde data overført. • ”Always on”. • Designet for å støtte applikasjoner der data kommer i skur. • Høyere datarate enn GSM.


12

Begrensninger

• Begrenset cellekapasitet. GPRS påvirker den eksisterende cellekapasiteten i et nettverk. Tale og GPRS-kall bruker for eksempel noen av de samme nettverksressursene.

• Hastigheten er lavere i virkeligheten. Som nevnt ville det krevd at brukeren benytter alle de 8 tidslukene og ingen feilkorrigering for å oppnå maksimumshastigheten på 179 kbps. Dataraten per tidskanal er cirka 13 kbps.

• Forsinkelse. På grunn av pakkesvitsjing sendes pakker alternative veier i nettet, og samles hos destinasjonen. Dessuten kan en eller flere pakker kan mistes. GPRS har innarbeidet dataintegritet og retransmisjon av pakker dersom ønskelig, men dette gjør at forsinkelser kan oppstå. [10]

4.1.3 UMTS

Utviklingen av GSM og GPRS danner bakgrunnen for innføringen av Universal Mobile Telecommunication System (UMTS) [14] i Europa. UMTS er en av mange teknologier definert av International Telecommunication Union (ITU) for å muliggjøre tredje-generasjons mobile nettverk (3G). Standardiseringen skjer med støtte fra Europa, Asia og Amerika, og forventes derfor å få større utbredelse enn hva GSM har i dag [15]. Hensikten med UMTS er å tilby trådløse tjenester som krever høyere datarater enn det som kan tilbys av GSM/GPRS-nettverkene. Sammenlignet med andre-generasjons mobilsystemer, har UMTS forbedrede egenskaper, deriblant støtte for multimediatjenester, som lyd, video og datatjenester. [14], [16] UMTS støtter følgende tjenestekategorier og applikasjoner[9]:

• Internettaksess – for eksempel meldinger, nedlasting av video og musikk, tale/video over IP.

• Intranett-tilgang – for eksempel tilgang til felles database. • Personifisert informasjon – for eksempel nedlasting av video/musikk/bilder og spill. • Multimediameldinger (MMS) – SMS-utvidelse, for eksempel overføring av

dokumenter. • Lokasjonsbaserte tjenester – tjenester som knyttes mot brukerens lokasjon, f.eks.

navigering. • Multimediatelefoni

Det finnes ulike kvalitetsparametre på dataoverføring. Tjenester i UMTS-nettverket deles inn i følgende klasser, avhengig av kvalitetsparametre [17]:

1. Conventional - tale, videotelefoni, videospill 2. Streaming - multimedia, video on demand, webcast 3. Interactive - Nettverks-spill, database-aksess 4. Background - e-post, SMS, nedlastning av filer

UMTS støtter både tale og datatjenester. Dataraten er avhengig av hvor man er og om man er i bevegelse. UMTS gir følgende bitrater [9], [16]:

• 144 kbps – 384 kbps for utendørs mobile omgivelser og et redusert multimediatilbud i store celler.


13

• 348 kbps for å dekke behovet for multimedia i middels store celler. • 2 Mbps; innendørs, i små lokale celler og ganghastighe t.

Dataraten på 2 Mbps oppnås ved å bruke W-CDMA2 teknologi. Med denne teknologien deler alle tjenestene en felles radio-ressurs som bruker spredt-spektrum teknologi og ”bruk etter etterspørsel” (”usage on demand”). Dette utnytter spektrumet, men fordi det er en felles ressurs, varierer båndbredden for hver bruker. Dataraten er avhengig av antall samtidige brukere, brukerens avstand fra basemottakeren, hastigheten brukeren beveger seg i og forstyrrelser i luften, slik som værforhold og lignende. UMTS tillater en bruker/applikasjon å forhandle om overføringsparametrene som er best egnet for å overføre informasjonen.

Ifølge Telenor vil det i første omgang være en maksimal overføringshastighet for pakkesvitsjet trafikk på 348 kbps, og 64 kbps for linjesvitsjet [18].

Arkitektur

Den første utgivelsen kom i 1999, og inneholdt de grunnleggende egenskapene for å aksessere et IP-nettverk og de linjesvitsjede nettverkene. Kjernenettverket består av GSM i den linjesvitsjede delen og GPRS i den pakkesvitsjede. Radionettverket (UTRAN) er basert på W-CDMA teknologi og er uavhengig av kjernenettverket. I denne versjonen benyttes den linjesvitsjede delen for tale (klasse 1), noe som ble endret i Release 5, der den pakkesvitsjede delen også brukes for tale. Fordeler:

• Høy datarate • Støtter multimediatjenester

Ulemper:

• UMTS er under utbygging i Norge i dag og er dermed ikke tilgjengelig enda. • Apparatene vil være relativt dyre når UTMS introduseres. (Det forventes at prisen vil

falle når salget av terminaler øker.) [22] • Det finnes ikke støtte for skifte av bæretjeneste under en sesjon.

4.1.4 Ny generasjons UMTS: IP Multimedia Subsystem

UMTS-arkitekturen har utviklet seg gjennom utgivelsene og har blitt mer IP-fokusert når det gjelder transport og signalering. Infrastrukturen har gradvis blitt erstattet med en optimal IP-basert transport- infrastruktur. Den store påvirkningen av IP-baserte applikasjoner og betydningen av støtte for sanntid er dermed blitt tatt i betraktning. Transportdelen i versjon 5 (Release-5) består av en ”All IP”-arkitektur [21]. Denne versjonen introduserer IP multimedia subsystemet (IMS) for å effektivt gi IP-basert multimediabaserte tjenester over pakkedomenet [19], som vist i figur 5. Dette subsystemet er et kontrollsystem for å utføre sesjonskontroll av IP multimediatjenester basert på SIP. Målet med IP multimedia-subsystem er uavhengig nettverksaksesss og å gi sømløse

2 Wideband code-division multiple access.


14

multimediatjenester basert på internett-applikasjonestjenester og protokoller. Utviklingen av tjenester gjøres av operatører og andre leverandører [14].

Figur 5 UMTS fra Rel-5; IP Multimedia Subsystem. [21]

Fordeler

• Høy datarate. • Støtter multimediatjenester. • Støtter skifte av bæretjeneste under sesjon. • ”All IP”- arkitektur, det vil si IP-transport også i linjedomenet.

Ulemper

Dette er de samme ulempene som nevnes for UMTS i forrige del-kapittel, med unntak av det siste punktet.

• UMTS er under utbygging i Norge i dag og er dermed ikke tilgjengelig enda. • Apparatene vil være relativt dyre når UTMS introduseres. (Det forventes at prisen vil

falle når salget av terminaler øker.) [22] • IMS er en teknologi som ligger langt fram i tid.

4.2 Teknologier i ad-hoc nettverk

I dette del-kapittelet vil vi ta for oss potensielle trådløse teknologier for ad-hoc nettverk. Noen av teknologiene blir ikke beskrevet i detalj, da disse ikke er åpne spesifikasjoner eller er lite utbredt. De teknologiene som beskrives er

• WLAN • Bluetooth • SPIKE • HomeRF • HIPERLAN2 • IrDA


15

Felles for de fire første teknologiene (WLAN, Bluetooth, SPIKE og HomeRF) er at de alle oprererer eller har mulighet for å operere i frekvensområdet 2,4 GHZ til 2,4835 GHz. Dette området kalles Industrial Scientific Medical (ISM) band, og er ulisensiert i de fleste land. Det vil si at frekvensområdet kan brukes fritt, noe som medfører en del interferens fra andre trådløse kortdistanse-teknologier.

4.2.1 WLAN – Wireless Local Area Network

Wireless LAN [8] tilbyr fleksibel datakommunikasjon. Nettverket er trådløst og et alternativ til kablet lokalnett, derav navnet Wireless Local Area Network. Forbindelsen i et slikt nettverk er tilgjengelig i et begrenset område, for eksempel en bygning eller et universitetsområde. Data mottas og sendes i luften ved hjelp av elektromagnetiske bølger (radiofrekvens eller infrarødt). WLAN kombinerer derfor dataforbindelse og mobilitet. En viktig fordel med WLAN er at det kan brukes uavhengig av kablede nettverk. Det kan brukes hvor som helst som et frittstående nettverk for å koble flere PC-er sammen uten å måtte bygge eller utvide et kablet nettverk. Når nettverket er på plass, koster det per i dag ingenting å bruke det for sluttbrukerne. Kommunikasjonen skjer i frekvensområdet fra 2,4 GHz til 2,48735 GHz (ISM-båndet). Ulike WLAN standarder er tilgjengelige i dag. Applikasjonsstandarden for de fleste WLAN er IEEE 802.11. Den eneste kommersielle versjonen som er tilgjengelig i dag er 802.11b standarden fra IEEE, som leverer 11 Mbps [8]. Rekkevidden til WLAN er avhengig av bruken og miljøet. Det kan variere fra ca 30 meter inne i en bygning til flere hundre meter utendørs ved direkte siktelinje [15], [14].

Arkitektur

I IEEE 802.11 standarden kan det benyttes to forskjellige topologier: en hvor en gruppe av stasjoner kommuniserer direkte med hverandre i et ad-hoc nettverk, og en topologi med infrastruktur. Når infrastruktur benyttes angir et aksesspunkt et dekningsområde. Aksesspunktet (AP) koordinerer all kommunikasjon og er bro til andre nett; trådløse eller faste. Den fungerer som viderebringer. Det vil si at to terminaler som kommuniserer må begge kunne nå aksesspunktet, men trenger ikke nødvendigvis se hverandre for å sende informasjon seg i mellom. WLAN er derfor skalerbart, og kan konfigureres i forskjellige topologier. Infrastrukturen med aksesspunkt og trådløse enheter kalles Basic Servcie Set (BSS). Flere BSS er koblet sammen via et distribuert system, og refereres til som Extended Service Set (ESS) som vist i figur 6. Dette systemet kobler sammen flere BSS og LAN ved å bruke et distribuert system-medium (DS) for at aksesspunktene skal kunne kommunisere sammen. MDS kan være hvilket som helst nettverk, men er ofte et vanlig lokalnett.


16

Figur 6 WLAN infrasturktur topologi [14]

Ved bruk av ad-hoc topologi kommuniserer enhetene direkte med hverandre uten å bruke et aksesseringspunkt (se figur 7). To eller flere enheter kan danne et trådløst nettverk, og dette kan fungere bra for enkle løsninger, for eksempel en eller to bærbare PCer i et konferanserom. Dette kan være nyttig for overføring av datafiler mellom maskinene, men mer avanserte egenskaper som man ellers har kan mangle. I tillegg kan ikke ad-hoc nettverk løse ”hidden-station”-problemer. ”Hidden-station” oppstår når flere enheter prøver å sende samtidig og derfor gir uønsket interferens for en tredje stasjon. Et aksesspunkt kan minimere dette problemet.

Figur 7 WLAN ad-hoc topologi [20]

Ad-hoc nettverk

Det kan diskuteres om WLAN er en teknologi som kan kalles et ad-hoc nettverk. Som nevnt er det mulig for enhetene å kommunisere direkte med hverandre. På en annen side går kommunikasjonen vanligvis via et aksesspunkt. I denne oppgaven sees likevel WLAN på som et ad-hoc nettverk, selv om infrastruktur benyttes.

Fordeler

• Lisensfritt • Ingen kabler


17

• Billig å bruke • Kan fungere som ad-hoc nettverk

Ulemper

• GSM, GPRS eller UMTS mobilstasjon trenger Wireless Network Interface Card • Direkte kommunikasjon uten aksesspunkt gir begrensede egenskaper

4.2.2 Bluetooth

Brukere i dag må håndtere en rekke ulike oppkoblinger mellom enheter som PC, mus, tastatur, skjerm, printer, scanner, digitalt kamera osv. Dette gjør systemet komplekst og vanskelig å flytte med seg rundt. Trådløs kommunikasjon mellom disse enhetene gir derfor brukeren mange fordeler og muliggjør en videre bruk av mobile enheter. Bluetooth [23] er en teknologi som spesifiserer hvordan data kan overføres trådløst mellom maskinvareenheter. Bluetooth-teknologien ble utarbeidet av Ericsson Mobile Communications i 1994. Navnet Bluetooth kommer fra den danske vikingekongen Harald Blåtand, som førte Norge og Danmark sammen på 900-tallet, og symboliserer at teknologien forventes å føre sammen telekommunikasjons- og dataindustrien. Formålet med teknologien var å fungere som et grensesnitt mellom mobiltelefoner og dens tilbehør, men har utviklet seg til å bli en generell trådløs teknologi. Den første versjonen av Bluetooth-spesifikasjonen ble sluppet i 1999. Bluetooth-teknologien har i utgangspunktet en rekkevidde på 10 meter, men med en kraftigere sender kan rekkevidden utvides opp mot 100 meter. Bluetooth er en radiofrekvens-teknologi og opererer i frekvensområdet 2.4 til 2.4835 GHz, som er det samme som WLAN benytter. Siden bruken av ISM-båndet er ulisensiert3 i de fleste land i dag, finnes det mye annet utstyr som bruker de samme frekvenser. Dette oppleves som støy eller interferens og kan gi til dels betydelig reduksjon i kapasiteten. Den kanskje største støykilden er mikrobølgeovner som opererer nettopp på disse frekvensene. Selv om de som oftest er godt skjermet, kan en uheldig plassert mikrobølgeovn fullstendig lamme kommunikasjonen. Annet ustyr som bruker disse frekvensene er f.eks. enkelte alarmer og trådløse telefoner, enheter for trådløs overføring av videosignal og HomeRF.

Fordeler

Hovedstyrken til Bluetooth er muligheten for håndtering av både data- og tale-strømmer samtidig. Denne evnen sammen med ad-hoc tilkobling av enheter og automatisk oppdaging av tjenester gjør Bluetooth til en bra løsning for mobile enheter og internett-applikasjoner. [24] Andre fordeler er:

• Billig • Trådløst • Bruker lite strøm.

3 Åpent for alle som vil bruke det.


18

• Kan brukes hvor som helst, forutsatt at enhetene støtter teknologien og at rekkevidden mellom enheten ikke er over 10 meter (eventuelt 100 meter).

• Det er ikke nødvendig at enhetene peker mot hverandre. • Enkelt å bruke. Bluetooth-enheter kommuniserer automatisk med hverandre, når

forbindelsen er satt opp èn gang.

Ulemper

• Kort rekkevidde (spesielt "10 meters-utstyr"). • Førstegangs-konfigurasjon kan være litt komplisert. • Begrenset båndbredde (dataoverføringshastighet); 1 Mbps er ikke nok til for eksempel

video-overføring (2 Mbps i neste versjon). • Krever enheter som støtter teknologien. • Interferens med andre teknologier i samme frekvensområde. • Lite standardisert.

4.2.3 SPIKE

SPIKE [25] er en relativt ny teknologi som ligner mye på Bluetooth-teknologien. SPIKE opererer i frekvensområdet 900 MHz, men er spesifisert for også å operere i 2,4 GHz-frekvensområdet, det samme som Bluetooth. SPIKE ble i utgangspunktet utviklet for bruk i videospill, som en erstatning for kabler mellom spillkonsollet og kontroll-boksen. Teknologien kan imidlertid også brukes utover dette, enten som en LAN-gateway, en MP3-server eller i peer-to-peer4 kommunikasjon. SPIKE er utviklet av ett selskap, Eleven Engineering. Teknologien er derfor ikke åpen, og man trenger lisens på systemet for å studere spesifikasjonen. Fordeler

• Kan benyttes i peer-to-peer kommunikasjon.

Ulemper

• Teknologien er kun utviklet av ett selskap, og spesifikasjonen er dermed ikke åpen.

4.2.4 HomeRF

HomeRF [26] står for home radio frequency og ble utviklet som et alternativ til trådløst hjemme-nettverk. HomeRF benytter frekvens-hopping og kan levere opp til 1,6 Mbps. Dette er en for lav datarate for bruk i forretningsapplikasjoner, men passer bra til hjemmebruk. HomeRF Working Group ble dannet i 1998. De har offentliggjort protokollen Shared Wireless Access Protocol (SWAP) som støtter data- og taletrafikk. Protokollen kombinerer IEEE 802.11b og Digital Enhanced Cordless Telecommunications til et system. SWAP opererer i frekvensområdet 2,4 GHz, det ulisensierte ISM-båndet. Dette er det samme båndet som Bluetooth, IEEE 802.11, 802.11b og mikrobølgeovner bruker, og vil derfor kunne føre til

4 Peer-to-peer er en kommunikasjonsmodell der hver enhet har de samme egenskaper og de samme mulighetene for å starte en sesjon.


19

interferens mellom alle disse teknologiene. Enheter som bruker HomeRF kan operere både mot et aksesspunkt og som peer-to-peer. Det er tilsynelatende ikke helt den samme åpenhet om HomeRF protokollen som det er om f.eks Bluetooth, hvor standarden kan lastes ned direkte. Det er derfor vanskelig å sammenligne teknologien direkte med andre kort-distanse trådløse teknologier. Fordeler

• Støtter både data- og taletrafikk.

Ulemper

• For lav datarate for bruk i forretningsapplikasjoner (1,6 Mbps). • Opererer i det ulisensierte ISM-båndet, noe som kan føre til interferens fra andre

teknologier i samme frekvensområde.

4.2.5 HIPERLAN2

HIPERLAN2 [27] står for High Performance Radio LAN 2 og er utviklet av ETSI og BRAN og publisert i mai 2000. HIPERLAN2 er en standard for trådløst LAN og opererer i frekvensområdet 5 GHz. [23] HIPERLAN2 støtter hastigheter opp mot 54 Mbps og har en innendørs rekkevidde på 30 meter og utendørs rekkevidde på 150 meter. Bruksområder er ad-hoc nettverk og mobile nettverk. HIPERLAN2 har en del fordeler i forhold til IEEE 802.11 slik at denne teknologien kan benyttes nær Bluetooth. En fordel er at HIPERLAN2 opererer i 5 GHz-båndet, som er forskjellig fra Bluetooth, og kan derfor fungere sømløst sammen med den. En annen fordel er høyere overføringshastighet i HIPERLAN/2 i forhold til IEEE 802.11. HIPERLAN/2 er videre standardisert med tanke på tilkobling mot ulike nettinfrastrukturer som TCP/IP-nett, ATM/Bluetooth-ISDN og UMTS. Det finnes ingen form for garantert tjenestekvalitet, kun en ”best effort” tjeneste. Dersom mange noder sender såkalte høyprioritetspakker, vil man få de samme problemene som i et hvilket som helst annet delt medium. [20] Fordeler

• Opererer i 5 GHz-båndet, og kan derfor fungere sømløst sammen med Bluetooth og WLAN.

• Høy overføringshastighet (opp mot 54 Mbps). • Standardisert.

Ulemper

• Ingen tjenestekvalitet er garantert.


20

4.2.6 Infrarød teknologi

Infrarød teknologi (IR) [23] tilbyr trådløs dataoverføring. IR er en short-range-teknolgoi, der det er nødvendig med en klar siktelinje mellom overfører og mottaker. I tillegg kan lysforhold påvirke signaleringskvaliteten. Tap av kommunikasjon kan skje hvis det er mye sollys eller bakgrunnslys. Fluoroescerende lys kan også inneholde mye infrarødt lys. Dette er et problem som kan løses ved at man bruker sterk signalering og et optimalt båndbreddefilter, som reduserer infrarødsignalene som kommer fra utenforstående kilder. Utendørs kan snø, is og tåke virke inn på effektiviteten til systemet. Infrared Data Association (IrDA) [29] er en gruppe av produsenter som har utviklet et sett standarder for infrarød dataoverføring. Standardene inkluderer utvidelser for høy-hastighets overføringer for 1.152 Mbps, 4.0 Mbps og 16 Mbps [28]. Dette gjør at overføringshastigheten til IrDA er raskere enn for Bluetooth. Men den maksimale rekkevidden er kortere (1,2 m).

Sikkerhet

I motsetning til andre trådløse teknologier går ikke infrarøde stråler gjennom vegger og andre materialer. Dette gjør IR til en sikrere teknologi i forhold til Bluetooth og HomeRF, som trenger sterkere kryptering for å hindre at personer utenfor bygningen kan overvåke overføringen. For å tyvlytte på overføringer som foregår ved hjelp av infrarød teknologi, må man oppholde seg i samme rom som overføringen skjer i.

Fordeler:

• Ingen statlig regulering kontrollerer bruken (lisensfritt). • Ingen interferens med elektromagnetisk (EM) stråling og RF.

Ulemper:

• Fri sikt mellom enheter er nødvendig. • Signalet påvirkes av lys, snø, is og tåke. • Kort rekkevidde.


21

5 BRUKERSCENARIO FOR DEMOTJENESTEN

Prosjektoppgaven tar for seg et komplekst område, som gir muligheter for et stort spekter av nye tjenester. Disse tjenestene har kompleks arkitektur og interaksjon. Vi har valgt å kun lage et rammeverk for å demonstrere en enkel tjeneste. En fullverdig løsning ville blitt for omfattende og ta for lang tid å realisere i denne prosjektoppgaven.

5.1 Beskrivelse av brukerscenarioet

På et universitet er det mye informasjon som skal ut til studentene. En forelesning kan bli flyttet til et annet auditorium eller avlyses, et møte kan bli utsatt, temadager skal annonseres osv. Denne informasjonen skal noen ganger ut til alle studentene, andre ganger til mindre grupper. Ved å bruke interaksjon mellom et ad-hoc nettverk og et globalt nettverk kan denne informasjonen distribueres på en rask og enkel måte, og spare studentene for mye tid i en stresset hverdag. Noen tjenester som er aktuelle i et universitetsmiljø:

• Studenten mottar den nyeste informasjonen på sin mobiltelefon/PDA ved ankomst til skolen.

• Studenter kan jobbe i nettverk ved hjelp av sine bærbare PCer. • En Buddy- liste på mobiltelefonen kan fortelle hvor klassekameratene befinner seg. • Studenten kan koble seg opp mot nærmeste printer fra PDAen sin for å skrive ut

dagens forelesningsnotater. Det første av disse punktene realiseres i denne oppgaven.

5.1.1. Scenario

Brukerscenarioet beskriver en student ved navn Thomas. Han er 20 år og studerer i 1. klasse ved linjen for elektroteknikk. Interessene hans er fotball, data og mobiltelefoner. Historien som følger gir en illustrasjon på et scenario som er mulig ved hjelp av interaksjon mellom nettverk. Første delen av dette scenariet realiseres i oppgaven. ”Thomas har kretsteknikk mandag morgen kl 08.15, men forsov seg og ankommer skolen i siste liten. Han slår på PDAen sin rett før han går inn hoveddøren til Elektrobygget. Innenfor hører han et meldingsvarsel fra mobiltelefonen sin. Han tar fram telefonen og leser meldingen. Der står det at forelesningen i kretsteknikk er flyttet til auditorium S3 i Sentralbygget. Thomas bestemmer seg for å la være å gå i forelesningen og i stedet gjøre denne ukens øving. Via mobiltelefonen kobler han seg opp mot Internett og går inn på fagets hjemmeside, ved hjelp av URLen som ble sendt med i meldingen. Der finner han øvingen og printer den ut på nærmeste printer. ”

5.1.2. Beskrivelse av rammeverk

Det som skal implementeres er et enkelt rammeverk for hvordan en interaksjon mellom tjenester i et ad-hoc nettverk og et golbalt nettverk kan realiseres. Rammeverket er et ”proof of the concept” og har ikke til hensikt å beskrive en fullstendig tjeneste.


22

Det skal implementeres en meldingsapplikasjon som har ansvar for å sende melding med relevant informasjon til studentene som ankommer et visst område. En student har en PDA utstyrt med WLAN kort som gjør at den kan benyttes i WLAN. PDAen må kjøre et klient-program for posisjonering før den kan bli oppdaget. En lokasjonsserver har funksjonalitet som gjør at den kan varsle meldingsserveren om at en student har ankommet området. Funksjonaliteten til lokasjonsserveren er beskrevet under i delkapittel 6.4. Identifisering av student gjøres på grunnlag av mac-adressen til PDAen. Alle nettverkskort har en unik fysisk adresse som kalles mac-adresse (Media Access Control address). Dette er en 6-bytes adresse, vanligvis skrevet i hexadesimal form, for eksempel 08:00:20:0A:8C:6D. De tre første byte er leverandørspesifikke og de tre siste er unike for kortet [30]. I WLAN-nettverket er datalinklaget fra OSI-modellen delt opp i to lag; Logical Link Control layer og Media Access Control (MAC) layer. Mac- laget er grensesnitt mot nettverksmediet [31]. Mac-adressen er lagret i en database sammen med andre relevante opplysninger om studenten, som navn, adresse, studentnummer, telefonnummer og hvilke fag studenten tar. Når studenten ankommer WLAN-området, blir riktig melding hentet ut fra databasen og sendt som SMS til mobilen. Hvis studenten nok en gang kommer inn i WLAN-området, blir ikke meldingen sendt på ny. Dette er viktig, både fordi studenten ikke er interessert i gamle meldinger og fordi de som betaler for sending av meldingene ikke er interessert i å betale for unødvendige meldinger.

5.1.3. Begrensninger i rammeverket

En student er assosiert med sin PDA, og som nevnt har en PDA en fast mac-adresse. Dette kan brukes for å personalisere tjenesten ved at informasjon om når studenten er i området og hva personen gjør blir lagret. Da systemet i denne oppgaven kun skal demonstrere interaksjonen mellom et globalt nett og et ad-hoc nettverk, er personalisering av tjenesten ikke tatt i betraktning. Når meldingsserveren har fått beskjed om at en student med en gitt mac-adresse har ankommet området, vil opplysninger angående fagene til studenten hentes ut av databasen og sendes i en SMS til studentens mobiltelefon. I realiseringen av tjenesten i dette brukerscenarioet skrives meldingen direkte inn i databasen. Alternativt kunne meldingene for eksempel blitt generert ved hjelp av et web-grensesnitt. Meldinger i demotjenesten sendes til alle studentene som ankommer området. I en fullstendig tjeneste hadde det vært mer interessant å ha muligheten for å sende meldinger til en begrenset gruppe, for eksempel en klasse. Det er mulig å ha funksjonaliteten til en PDA og en mobiltelefon i samme enhet. I tjenesten som er realisert i denne oppgaven benyttes to enheter, siden PDA med GSM-funksjonalitet ikke har vært tilgjengelig.

5.2 Krav til det globale nettet

Tjenesten som realiseres i denne oppgaven inkluderer sending av SMS i det globale nettet. Meldingene skal være korte og kun bestå av tekst. Det er nødvendig at nettet er pålitelig, og at


23

meldingen leveres til mottaker i løpet av kort tid. Det er en fordel at nettet er godt utbygd og at de fleste studenter har apparater som støtter teknologien. Kandidatteknologier til det globale nettet er GSM, GPRS eller UMTS. GSM og GPRS er godt utbygd. UMTS har støtte for å sende multimediameldinger, men er i liten grad bygd ut i dag. Hvilken av disse teknologiene som benyttes i brukerscenarioet presenteres i kapittel 6.

5.3 Krav til ad-hoc nettverket

Det må stilles en del krav til den teknologien som skal benyttes i ad-hoc nettverket i brukerscenarioet. Det viktigste kravet er at teknologien er trådløs og at kommunikasjon mellom enheter kan skje umiddelbart. Se delkapittel 2.2 for en generell definisjon på ad-hoc nettverk. Et annet viktig krav er at teknologien som benyttes må ha en lang nok rekkevidde til at PDAen kan nås fra 1 meter opp til omtrent 10 meter. Dersom rekkevidden er kortere enn 1 meter, vil det skape problemer med lokaliseringen. Et tredje krav er at det ikke kan benyttes en teknologi som krever at enhetene peker mot hverandre (fri sikt). Dette er fordi hindringer kan komme i veien for sensorene. Apparatet kan for eksempel ligge i en sekk og flere studenter kan komme og gå samtidig.


24

6 TEKNOLOGIER ANVENDT I BRUKERSCENARIOET

Dette kapittelet omhandler teknologier som er benyttet i brukerscenarioet. Arkitektur skal være uavhengig av teknologi, og bør derfor presenteres først. I denne oppgaven beskrives derimot teknologiene før arkitekturen, siden tilgjengelig teknologi på Telenor FoU var avgjørende for deler av arkitekturen. Først blir Parlay/OSA og Parlay X beskrevet. Disse teknologiene finnes på PATS-laben på Telenor FoU, og brukes for å få tilgang til Telenor sitt globale nettverk. Videre tar kapittelet for seg Ekahau Positioning Engine, som gir mulighet for å lage posisjonsbaserte applikasjoner. Ekahau Positioning Engine brukes av en lokasjonsserver utviklet ved Telenor FoU. Lokasjonsserveren blir anvendt av meldingsapplikasjonen. Til slutt følger en beskrivelse av hvilke teknologier som er anvendt i det globale nettet og ad-hoc nettverket.

6.1 Parlay OSA

Parlay/OSA [32] er et åpent API som brukes for å lage telekommunikasjonstjenester. APIene gjør det lettere for utviklere av IT-applikasjoner å lage denne type tjenester, da de ikke trenger detaljkunnskap om det underliggende kommunikasjonsnettverket. Programvareutviklere fra IT-bransjen, som utvikler applikasjonene utenom det tradisjonelle telekom-nettverket, er avgjørende for å opprettholde fortsatt vekst i neste generasjons applikasjoner, tjenester og nettverk. Settet av APIer er omfattende og inkluderer Mobility, Location, Presence and Availability Management, Call Control, User Interaction, Messaging, Content Based Charging og Policy Management. Parlay/OSA APIene er uavhengig av teknologi. De ble designet for å bli brukt i mobile og kablede nettverk og for neste generasjons IP-baserte nettverk. Parlay/OSA er basert på åpne standarder som CORBA, IDL, Java, UML og Web Services (SOAP, XML og WSDL) [32]. Figur 7 viser en oversikt over arkitekturen i Parlay/OSA.


25

Figur 8 Arkitekturen til Parlay/OSA [32]

Rollen til Parlay/OSA Gateway

Parlay/OSA-modellen legger et nytt element til i nettverket, nemlig Parlay/OSA Gateway. Denne brukes for å koble applikasjonene som bruker APIene med de eksisterende nettverkselementene. Dette betyr at applikasjonene er isolert fra de spesifikke protokollene som brukes i nettverket. En gateway består av Framework og flere SCS, som vist i figur 8.

Parlay/OSA Framework

En av de viktigste kravene fra nettverks- og tjenesteoperatørene har vært å forsikre at åpningen av nettverket, som gjøres ved å definere en API, ikke avslører kommunikasjonsinfrastrukturen til uautoriserte brukere. Dette er noe Parlay/OSA Framework sikrer ved autentisering. Framework er implementert i Parlay/OSA Gateway. Alle applikasjoner og tjenester som vil bruke Parlay/OSA APIene må først registrere seg hos Framework. Objektreferanser returneres til applikasjonen for de Parlay/OSA-funksjonene den har fått lov til å bruke av operatøren. Framework gir på denne måten kontrollert aksess til APIene.

Service Capability Servers

Parlay/OSA Gatewayen består av flere Service Capability Servers (SCS). Dette er funksjonelle enheter som gir Parlay/OSA-grensesnitt mot applikasjoner. Applikasjonene ser på hver SCS som en eller flere Service Capability Features (SCF). Disse er abstraksjoner av funksjonaliteten som tilbys av nettverket og som er tilgjengelig via Parlay/OSA APIene (se


26

figur 8) . Parlay/OSA SCSene er spesifisert ved hjelp av grensesnitt-klassene og deres metoder [34].

Figur 9 Parlay Gateway består av flere Service Capability Servers [35]

Applikasjoner bruker tjenestene definert i Parlay/OSA og som tilbys gjennom Parlay/OSA APIene. Applikasjoner kan anvendes i applikasjonsservere og tjenestene tilbys av SCSene. SCS implementerer serversiden og applikasjonen implementerer klientsiden av APIen. Kommunikasjonen mellom applikasjonen og SCSen gjøres gjennom standard IT mellomvare-infrastruktur (f.eks. CORBA). SCSer er derfor logiske entiteter som implementerer APIen og kan samhandle med elementene i kjernenettverket. Disse elementene kan for eksempel være HLR i GSM-nettet. Derfor kan en SCS sees på som en proxy eller gateway til kjernenettverket [35]. En SCS kan implementere flere APIer, men vanligvis snakkes det om en spesifikk SCS per API. I vårt tilfelle hvor det er snakk om å sende SMS, har vi derfor å gjøre med en SCS som har funksjoner for å gjøre dette [35]. Parlay/OSA Framework er en slik SCS, og det finnes alltid et Framework per nettverk. Framework kontrollerer tilgangen til nettverket, håndtering av integritet og oppdaging av nettverksfunksjonaliteter, som beskrevet over. Se figuren under for hvordan Framework fungerer sammen med en applikasjon og en SCS.

Figur 10 Meldinger som går mellom Framework, applikasjon og SCS. [35]


27

Applikasjonen registrerer seg hos Framework. Dette er en viktig oppgave, men noe vi ikke skal se nærmere på. Deretter starter Framework en passende Manager, og gir en referanse til applikasjonen. Brukeren tar deretter i bruk tjenesten, og SCS sjekker abonnementet. Informasjonen presenteres for brukeren via UI SCS. Applikasjonen belaster deretter abonnenten [34].

Fordeler med Parlay/OSA hevdes å være, i henhold til [34] og [35]:

• Rask utvikling av tjenester • Nettverksuavhengighet; APIene er designet for å være uavhengige av det

underliggende nettverket. • Leverandøruavhengighet; dette er en konsekvens av teknologi- og

nettverksuavhengigheten til APIEne. • Stor bredde av applikasjonsutviklere; bruken av standard programvareteknologi gjør at

programvareutviklere som f.eks har erfaring fra Java og EJB lett kan utvikle applikasjoner ved å bruke Parlay/OSA.

• Tredjeparts uavhenige softwareutviklere; disse utvikler og selger applikasjoner og tjenester basert på Parlay/OSA. Denne gruppen vokser som resultat av bruken av standard programvareutviklingsteknologi.

6.2 Parlay X

Parlay X-spesifikasjonen [36] ble sluppet i april 2003 og spesifiserer et sett av enkle web services som kan brukes som byggeklosser i utviklingen av telekommunikasjonsapplikasjoner. Byggeklossene er definerte for å fremme en bred anvendbarhet i stedet for å gå i dybden på funksjonalitet. Dette reflekteres i 80/20-regelen (80 % av applikasjonene kan implementeres ved bruk av 20 % av den tilgjengelige funksjonaliteten). Parlay X Web Services har til hensikt å stimulere utviklingen av neste generasjons nettverksapplikasjoner, av IT-programvareutviklere som ikke nødvendigvis innehar ekspertise innen telekommunikasjon. Interaksjonen mellom en applikasjon som innlemmer en Parlay X Web Service og serveren som implementerer den aktuelle Parlay X Web Service gjøres med en XML-basert (SOAP) meldingsutveksling. Dette gjør det enklere for uprofesjonelle programmerere å benytte seg av Parlay X. Parlay X Web Services er et applikasjonsgrensesnitt og implementerer ikke noen form for AAA (Authorization, Authentication og Accounting), SLA (service level agreement) eller andre kjørespesifikke egenskaper. Tjenestene skal i stedet være avhengig av ferdige løsninger fra Web Services infrastrukturen.

Forhold mellom Parlay X Web Services og Parlay aktiviteter

Figur 10 viser forholdet mellom Parlay X Web Services og Parlay APIer. En Parlay Gateway slik det vises i figuren implementerer Parlay APIene. Applikasjoner kan samhandle med Parlay Gateway over et nettverk ved hjelp av CORBA eller Web Services-transport.


28

En applikasjon kan skrives i hvilket som helst programmeringsspråk, så lenge den kan gjøre de korrekte metodekall og kan behandle de tilsvarende responsene som API-versjonen i Parlay Gateway’en tilbyr. Applikasjonen kan derfor være et Java-program, et Visual Basic-program eller et XML-script. Interaksjonen mellom applikasjonen og Parlay Gateway’en kan generelt sett være svært kompleks og utnytte alle egenskapene til APIene. Parlay X Web Services representerer en abstraksjon og forenkling av Parlay APIene og vises derfor over dette grensesnittet i figur 10. Det er forventet at de fleste Parlay X Web Services vil bli implementert ved å kalle på funksjonalitet på en Parlay Gateway, men det finnes tilfeller der Parlay X serveren kan implementere en Web Service via direkte oppkobling mot nettverksressursene. En Parlay X-applikasjon kan også skrives i hvilket som helst språk, så lenge den kan gjøre det riktige kallet mot en Web Service. Det finnes forskjellig utviklingsverktøy for å lage, ta i bruk og ha interaksjon med Web Services.

Figur 11 Forholdet mellom Parlay X og Parlay API [48]

6.3 Ekahaus Positioning Engine 2.0

Ekahaus Positioning Engine er et programvare-basert system som gør det mulig å lage posisjonsbaserte applikasjoner for trådløse lokale nettverk (WLAN) [28]. Systemet består av Ekahau Positioning Engine, Ekahau Client og Ekahau Manager og brukes for å lokalisere brukerutstyr som PDAer og bærbare PCer. Hver enhet som skal lokaliseres må kjøre Ekahau Client-programvaren.


29

Ekahau Positioning Engine er server-programvare basert på Java og brukes til å kalkulere brukerutstyrets posisjon. Ekahau Manager er en platform som kan benyttes for å lage posisjoneringsmodeller, spore utstyr og analysere nøyaktigheten på posisjoneringsdata. Figur 11 viser komponentene i systemet.

Figur 12 Ekahau trådløs posisjonering [28]

1. Ekahau Manager brukes for å lage posisjoneringsmodeller på grunnlag av kart og planløsninger.

2. Kalibrering av posisjoneringsmodell. 3. Sporing av brukerutstyr starters fra Ekahau Manager. 4. Nøyaktigheten av posisjoneringen analyseres.

En av hovedfordelene ved Ekahau posisjoneringssystem er at det ikke krever installasjon av spesialiserte aksess-punkt, men kan benyttes over alle typer trådløse LAN, som HiperLAN og IEEE 802.11. Posisjoneringssystemet gir en posisjon med nøyaktighet på 1 meter, noe som er nok for de fleste innendørsapplikasjoner. Men en slik nøyaktighet krever at klienten som kjører Ekahau Client-programvaren befinner seg inne en rekkevidde av fire aksesspunkt. En test utført av Wi-Fi Planet [50] med fire aksesspunkt viste en gjennomsnittlig nøyaktighet på 1,9 meter. Siden det kreves at alle enheter som skal lokaliseres blir installert med Ekahau Client-programvaren, passer systemet best innen en privat bedrift eller selskap der alt brukerutstyr kan kontrolleres. Koordinatsystemet som benyttes i posisjoneringen kalles ”Geodetic Latitude, Longitude, Altitude” (breddegrad, lengdegrad, høyde over havet). Det brukes et globalt datum, kalt World Geodetic System 1984 (WGS-84), som referansepunkt. WGS-84 er det datumet som benyttes av Global Positioning System (GPS). [49]

6.4 Lokasjonsserver

En lokasjonsserver [38] utviklet av Ingebrit Fuglem ved Telenor FoU bruker Ekahau Positioning Engine for å lokalisere og hente ut posisjonen til en terminal. Lokasjonsserveren har adaptere som implementerer grensesnitt mot de forskjellige underliggende posisjoneringssystemene den kan benytte seg av. Muligheten for at et av systemene er nede


30

ved et gitt tidspunkt er tilstede. Lokasjonsserveren har derfor en database som holder på siste kjente posisjon for terminalene som skal lokaliseres. En testklient for lokasjonsserveren har fire metoder: FIND, TRACK, NOTIFY OG NOTIFY_WHEN_MOVED. Det benyttes et JMS-grensesnitt mellom klienten og lokasjonsserveren. I brukerscenarioet presentert i denne prosjektoppgaven er det metoden NOTIFY som brukes.

GSMRadioEye Ekahau Pos.

EngineBluetooth RFid

LokasjonsserverDB

Meldings-server

JMS

Figur 13 Arkitektur over Lokasjonsserver

6.5 GSM

Se kapittel 5 for nærmere beskrivelse av GSM. I brukerscenarioet er GSM valgt som teknologi i det globale nettverket. Dette er fordi det dekker kravene som er stilt for å gi tjenesten som tas i bruk i dette nettet, nemlig sending av SMS. GSM støtter SMS som inneholder opp til 160 tegn, og leverer meldingene til mottaker innen kort tid. I tillegg er det enkelt å anvende dette nettverket ved å bruke Parlay X på PATS-laben hos Telenor.

6.6 WLAN

Se kapittel 4.2.1 for nærmere beskrivelse av WLAN. Nettverket er trådløst og har god rekkevidde (det vil si fra ca 30 meter inne i en bygning). WLAN er tilgjengelig i lokalene til Telenor, og er tatt i bruk i ad-hoc nettverket i brukerscenarioet.. Tilgjengeligheten samt fordelene ved WLAN, gjorde at WLAN ble valgt som teknologi i ad-hoc nettverket i bruerscenarioet i denne oppgaven. Andre teknologier var gode kandidater. For eksempel hadde det vært mulig å anvende Bluetooth. Dette er en teknologi som har kommet mer og mer på markedet i det siste, og finnes for eksempel i mange mobiltelefoner i dag.


31

7 ARKITEKTUR I BRUKERSCENARIOET

Dette kapittelet gir en beskrivelse av arkitekturen i scenarioet, og definerer hva som er det globale nettverket og hva som er ad-hoc nettverket. Meldingssekvensdiagram og klassediagram blir også beskrevet.

7.1 Overordnet arkitektur

En overordnet arkitektur over rammeverket som implementeres vises i figur 13. Applikasjonen for å sende SMS ligger på en meldingsserver. Meldingsserveren har et Java Message Service grensesnitt mot en lokasjonsserver (beskrevet i kapittel 6). Lokasjonsserveren håndterer lokaliseringen av en terminal tilhørende en student. Når meldingsserveren blir varslet om at en student har ankommet området som dekkes, vil den gjøre et kall mot en Parlay X Web Service via et SOAP-grensesnitt. I dette tilfellet er det en SMS Web Service, for å sende melding, som kalles. SMS Web Servicen gjør så et kall mot en Parlay API-metode ved å bruke Parlay/OSA-grensesnittet SCS-SMS (User Interaction). SCSen tar seg av å sende meldingen videre til en SMSC [37]. Meldingen blir til slutt rutet gjennom GSM-nettet til riktig mottaker. Se figur 19, sekvensdiagram for sending av SMS i GSM-nettet. Parlay X brukes for å nå det globale nettet. I arkitekturen består det globale nettet av GSM-nettet med tilhørende komponenter. En TestSMSC brukes for å sende en melding. Denne sees også på som en del av det globale nettverket. Ad-hoc nettverket består av en PDA og Ekahau Position Engine. Disse kommuniserer ved hjelp av WLAN når en PDA kommer inn i området.


32

AP

AP

GSM-nett

TestSMSC

ParlayGW

Appl.Server

Meldings-server

Lokasjon-server

Ekahua Pos. EngineMeldings-DB

Lokasjons-DB

JMS

Parlay/SOAP

ss7/SSMP

CORBA

Parlay X

Figur 14 Overordnet arkitektur

Figur 14 viser en lagdelt inndeling av arkitekturen. Applikasjonen som er utviklet i denne oppgaven vises øverst i figuren.

Figur 15 Lagdelt arkitektur


33

7.1.1 Definisjon av globalt nett i brukerscenarioet

I brukerscenarioet skal det sendes en SMS i det globale GSM nettverket. Dette nettet tas i bruk ved at meldingen først sendes via Parlay X til en test-SMSC i GSM-nettet. Deretter sendes meldingen videre i GSM-nettet ved hjelp av komponenter som vist i sekvensdiagram i figur 19. Det globale nettet i brukerscenarioet består derfor av test-SMSC og komponentene i GSM-nettverket som vist i denne figuren. 7.1.2 Definisjon av ad-hoc nett i brukerscenarioet

I brukerscenarioet vil et ad-hoc nettverk settes opp mellom Ekahau Positioning Engine, via aksesspunkt for WLAN og en mobil terminal. Terminalen kan for eksempel være en PDA eller en mobiltelefon med nødvendig teknologi. I vårt brukerscenario benyttes en PDA for lokalisering og en mobiltelefon for å motta SMS. For at PDA-en skal kunne lokaliseres av posisjonerings-systemet, må den være utstyrt med trådløst WLAN-kort. 7.1.3 Struktur av demotjenesten

Figur 16 illustrerer kommunikasjonen mellom PDA, aksesspunkt for WLAN, meldingsserveren, lokasjonsserveren og posisjoneringssystemet. En PDA som kjører et klientprogram for posisjonering har på forhånd mottatt mac-adressene til aksesspunktene som skal benyttes i lokaliseringen. Signal-støy-forholdet til disse sendes til posisjoneringssystemet hvert 10. sekund. Dette er markert med rødt i sekvensdiagrammet. Meldingsserveren sender Notify via et JMS-grensesnitt til lokasjonsserveren. Notify inneholder koordinater for området som skal overvåkes, samt mac-adressen til terminalen som skal lokaliseres. Lokasjonsserveren sender en Start_location_track til posisjoneringssystemet, beskrevet i del-kapittel 7.1.4. Location_estimate sendes så tilbake hvert n’te sekund, inntil terminalen har ankommet området som overvåkes. En Position-melding med posisjonen til terminalen, mac-adressen og tidspunkt sendes deretter til meldingsserveren.


34

Ekahau Pos. Client Aksesspunkt Lokasjonsserver

mac_address()

Ekahau Pos.EngineMeldingsServer

notify(pos,pos,mac)()

start_location_track(mac, snr)

location_estimate(x,y,mac_adr)()



postition(x,y,mac_adr)()

stop_location_track(mac_adr)()

singal_noise_ratio()

signal_noise_ratio()

signal_noise_ratio()

Sendeshvert

10.sek

Sendeshvert n’tesekund

Figur 16 Lokaliseringsprosedyren

Figur 17 illustrerer dataflyten i meldingsapplikasjonen. Client-klassen inneholder main-metoden, og oppkobling mot databasen og lokasjonsserveren er det første som skjer. Client henter deretter ut alle mac-adresser som er lagret i databasen og disse blir registrert i LokasjonsConnector. Kommunikasjon mellom LokasjonsConnector og lokasjonsserveren ble forklart i sammenheng med figur 15. Etter at LokasjonsConnector har mottatt en Position-melding, kalles metoden Handle_position hos Client. Mac-adressen, som sendes med som parameter i Handle_position, brukes så for å hente ut tilhørende melding og telefonnummer. Metoden postMsg sender med meldingen og telefonnummeret til SMSconnector, og denne klassen tar seg så av videre kommunikasjon med Parlay X-grensesnittet. (Se beskrivelse av arkitektur under kapittel 7.1) Klassen UserInt har ansvar for å avslutte programmet, og kaller metoden shut_down i Client når den mottar signal fra omgivelsene rundt. Delete_mac kalles deretter i LokasjonsConnector. Dette gjøres for at lokasjonsserveren ikke skal fortsette å lokalisere terminaler som har blitt registrert. Client vil til slutt koble ned forbindelsen med lokasjonsserveren og databasen.


35

PosRequestClientUserInt SMSconnectorJDBCconection

mac_adresser()

LokasjonsConnector

handle_position()

dbConnect()

registrer_mac()

notify()

position()

hentMsg()

hentTlf()

postMsg()

shut_down()

delete_mac()

delete_mac()

delete()

hentMac()

connect_pos()

disconnect_pos()

close()

check_input()

Kalles når q skrivesi command-vinduet.

Figur 17 Meldingsflyt mellom klassene i meldingsapplikasjonen

Figur 18 viser prosessen der en ny tjeneste/SCS registreres hos Parlay Framework og hvordan en applikasjon oppdager og velger en tjeneste. SCS kontakter Framework og etterspør Registration interface, som brukes for å publisere hvilken type tjeneste som tilbys. I tillegg får Framework en referanse til tjenesten/SCS.


36

Applikasjonen kontakter Framework og benytter seg av Discovery interface for å få en oversikt over tjenestene som tilbys. En tjeneste velges fra listen og Framework anmoder SCS om å lage en unik instans for applikasjonen (create Service Manager). En referanse til denne instansen returneres til Framework, som igjen leverer den til applikasjonen. Applikasjonen er etter dette i stand til å bruke tjenesten. [39] Pilene som er merket med rødt i sekvensdiagrammet vil bli repetert for hver tjeneste som applikasjonen ønsker å bruke.

Parlay X Application Parlay FW Service/SCS TestSMSC

selectService

createServiceManager

returnServiceManager

returnServiceManager

useService

sendSMS()

Authentication

request Registration interface

register factory

authentication

request Discovery interface

discover Service

Figur 18 Valg av tjeneste på Parlay/OSA

Dataflyten under sending av SMS er illustrert i figur 18. PostMsg kalles i SMSconnector, som igjen benytter en metode i Parlay X Web Service API; sendSMS.


37

SMSconnector Parlay X Web Service Parlay/OSA TestSMSC

sendSMS()

sendSMS()

Client

postMsg()

sendSMS()

SMS Web Service brukergrensesnittet SCS-SMS(User Interaction)i Parlay/OSAfor å kalle riktig metodetil sending av SMS.

Figur 19 Sending av melding

Figur 20 illustrerer hvordan en melding rutes i det globale nettet før det leveres hos mottaker. SMS er en tjeneste for korte meldinger (opp til 140 bytes), der meldingen leveres i løpet av sekunder hvis mottaker er innen dekningen av et GSM-nett. Hvis mottaker ikke er tilgjengelig lagres meldingen i SMS-sentralen (SMSC), og sendes når mottakers mobiltelefon igjen er koblet til nettet. På denne måten er levering fortsatt garantert selv om umiddelbar levering ikke er mulig. [40], [41] Komponenter som brukes ved sending av SMS [42]:

• Short Messaging Entity (SME) er en instans som kan sende eller motta me ldinger. • Short Message Service Center (SMSC) er ansvarlig for å videresende og lagre en

melding mellom en SME og mottaker. • Home Location Register (HLR) er en database som lagrer og håndterer brukere og

tjenesteprofiler. • Mobile Switching Center (MSC) utfører svitsjefunksjoner. • Visitor Location Register (VLR) er en database som inneholder midlertidig

informasjon om abonnentene. Denne informasjonen trengs av MSC for å betjene besøkende abonnenter i et område.

Meldingen sendes til SMS-sentralen som sender en Routing Information Request til HLR. Dette gjøres for å få rutingsinformasjon slik at den kan levere meldingen til MSCen som betjener mobilstasjonen. Når SMSC har fått rutingsinformasjonen av HRL, sender den meldingen til MSC, som videresender den til MS. Hvis ikke mobilstasjonen er i sitt hjemme-område, blir SMSC henvnist til VLR i besøksområdet. Dette er imidlertid ikke tatt med i figur 19.[42]


38

Hvis SMSC feiler med å levere en melding, spør SMSC om HLR kan legge til SMSC-adressen i listen over SMSCer som skal informeres når mobilen er tilgjengelig. Dette er ikke tatt med i figur 19 for å holde den så enkel som mulig.

TestSMSC HLR MSC MS

Routing Information Request()

message()

Parlay Gateway

message()

Routing Information()

SMSC lagrer meldingen ogleverer den til mottakernår denne er tilgjengelig.

message()

Figur 20 SMS i GSM-nettet

7.1.4 Klassediagram

Klassediagrammet i figur 20 beskriver de ulike klassene i meldings-applikasjonen, med parametre og operasjoner, samt relasjonene mellom disse. Client-klassen inneholder main-metoden. Pilene til SMSconnector og JDBCconnection indikerer at Client har referanser til disse klassene, men ikke omvendt. Client har også referanser til UserInt og LokasjonsConnector, som igjen har referanse til Client-klassen. Meldingsflyten i applikasjonen ble beskrevet under delkapittel 7.1.3, og vil derfor ikke bli gått nærmere innpå her.


39

+dbConnect()+hentMsg()+hentTlf()+close()+JDBCconnection()+hentMac()

-conn-mac-melding-tlf-time

JDBCconnection

+main()+handle_position()+shut_down()+Client()+delete_mac()

-connection-lokconn-mac-macs-melding-smsC-time-tlf-ui

Client

+UserInt()+check_input()

-in-client

UserInt

+registrer_mac()+notify()+LokasjonsConnector()+connect_pos()+delete_mac()+disconnect_pos()

-ackMode-client-connection-context-devices-endUserId-factory-queue_name-replyQueue-sender-session

LokasjonsConnector

+postMsg()+login()+addSecurityHeader()+getSendSmsPort()+getLoginPort()

-telefon-tekst-tlf

SMSconnector

Figur 21 Klassediagram

7.2 Drøfting rundt designvalg

I demotjenesten benyttes en lokasjonsserver utviklet ved Telenor FoU. Det underliggende nettverket som benyttes i dette tilfellet er WLAN, og eies av Telenor. Dette gjør at det ikke er nødvendig å bruke Parlay/OSA for å skjule kommunikasjonsinfrastrukturen. I tillegg må meldingsapplikasjonen som er implementert sende med mac-adressen til enheten som skal


40

lokaliseres. Dette gjør at det allerede på applikasjonsnivå må vites at et WLAN benyttes som nettverk. Siden Parlay/OSA ikke benyttes av lokasjonsserveren, bryter denne delen av systemet med kravet om nettverksuavhengighet. Alternativt kunne Parlay/OSA blitt anvendt mellom lokasjonsserveren og WLAN, og på den måten oppnå nettverksuavhengighet ved å skjule det underliggende nettverket. Se figur 22 for en illustrasjon av dette.

Figur 22 Alternativt design for lokasjonsserver, med Parlay/OSA

I figuren blir User Location SCS (se figur 9, kapittel 6.1) brukt mot Ekahau Positioning Engine. Dersom lokasjonsserveren hadde vært uavhengig av underliggende nettverk, som vist i figur 22, kunne en mer generell brukeridentifikasjon ha blitt benyttet. Denne identifikasjonen kunne for eksempel ha vært personnummer5, telefonnummer eller brukernavn, alt etter hvilken instans som eier lokasjonsserveren.

5 Personnummer kunne nok ikke blitt brukt direkte. Alternativt kunne et statlig e-nummer blitt benyttet.


41

8 IMPLEMENTASJON

I dette kapittelet presenteres teknologier som er anvendt i implementasjonen. Deretter beskrives testingen som er gjort av tjenesten. All kildekode med dokumentasjon legges ved på CD-ROM.

8.1 Teknologier anvendt

For å implementere meldingsapplikasjonen er følgende teknologier og grensesnitt blitt brukt: • Java 2 Standard Development Kit (J2SDK) 1.4.2 [43] • Java Messaging Service (JMS) 1.0.2a [44] • Java Database Connectivity (JDBC) [45] • Apache Axis 1.1 (Simple Object Access Protocol) [46] • Oracle9i Enterprise Edition Release 9.2.0.4.0 [47] • Structured Query Language (SQL) [33] • Parlay X for Movade version 4.1 [48]

Systemkomponent Teknologi

Client Java 1.4.2

UserInt Java 1.4.2

LokasjonsConnector Java 1.4.2, JMS

JDBCconnection Java 1.4.2, SQL, JDBC

SMSconnection Java 1.4.2, SOAP

SMS web service Parlay X

Database Oracle 9

Tabell 1 Anvendte teknologier i implementasjonen

8.2 Testing

For å sjekke at demotjenesten fungerer har det blitt utført testing som beskrevet under.

Testing under implementasjonen

• Databasen: Etter at data hadde blitt lagret i databasen, testet vi ved å utføre spørringer. • Main-metoder i klassene gjorde det mulig å teste at disse fungerte før hele systemet

var ferdig. Ved å skrive ut beskjeder til skjerm, sjekket vi at operasjoner ble gjennomført.

• For å sjekke at meldinger ble sendt til mobiltelefonen via Parlay X, ble meldinger sendt ved å kjøre en main-metode i SMSconnector-klassen.

Testing av tjenesten

Testing som ble utført for å kontrollere at tjenesten fungerte var følgende:


42

• Vi gikk inn i WLAN-området på Telenor med en PDA som var registrert i databasen. • Deretter sjekket vi at riktig melding ble sendt til riktig mobiltelefon i løpet av kort tid. • Kort tid etter å ha gått ut av området gikk vi inn i området på ny. Dette ble gjort for å

sjekke at meldingen ikke ble sendt to ganger.


43

9 KONKLUSJON

I denne prosjektoppgaven har vi tatt for oss interaksjon mellom globale nettverk og ad-hoc nettverk og sett på hvilke nye tjenester dette kan tilby. Denne interaksjonen dekker et stadig økende behov for ”on demand”-tjenester. Med ”on demand” menes tjenester som er tilgjengelige umiddelbart og på stedet. Det har blitt laget eksempler på slike nye tjenester, og et brukerscenario for en demotjeneste har blitt utarbeidet. Demotjenesten har blitt implementert som et ”proof-of-the-concept”. Dette er et rammeverk for å vise funksjonaliteten, og er ikke ment å fungere som en optimal løsning. Det har blitt vurdert ulike kandidatteknologier for demotjenesten. Teknologiene som har blitt benyttet er valgt på bakgrunn av de krav som er utarbeidet for denne tjenesten, og med hensyn på tilgjengelig teknologi ved Telenor FoU i Trondheim. Demotjenesten kunne vært utvidet til å inkludere mer funksjonalitet for å gi en mer sammensatt tjeneste. Eksempel på funksjonalitet som kunne vært lagt til er personalisering av informasjon. Informasjon knyttet til den enkelte student kunne blitt sendt med i meldingen. Eventuelt kunne det blitt sendt en melding til en person som ikke var på skolen når en student ankommer. Det kunne i tillegg vært mulig å holde en oversikt over alle som var i området, og sende en SMS til disse hvis det var ønskelig. Dette kan for eksempel gjøres for å sende ut generell informasjon som angår alle i det aktuelle området. Rammeverket skal vise interaksjon mellom et globalt og et ad-hoc nettverk. Interaksjonen som demonstreres i rammeverket kan brukes i andre tjenester. Noen eksempler på andre tjenester som kan realiseres er beskrevet i kapittel 3. Dette er et lite utvalg, men kapittelet viser at mulighetene for nye tjenester er mange. I framtiden vil det med stor sannsynlighet komme flere og bedre teknologier som kan benyttes. UMTS vil bli bygd ut, noe som vil gi nye tjenester i det globale nettet. Bluetooth er en trådløs teknologi i vekst og kan bli et bra alternativ til bruk i ad-hoc nettverket. Telenor FoU i Trondheim planlegger de kommende årene å arbeide videre med temaet, som denne prosjektoppgaven har tatt for seg, i to EU-prosjekter. Muntlig meddelelse, Josip Zoric, Telenor FoU. Gjennom arbeidet med prosjektoppgaven har vi vist at det er mulig å lage nye tjenester basert på interaksjon mellom ad-hoc nettverk og globale nettverk ved å bruke ”state of the art” teknologi. Vi har tilegnet oss nyttig kunnskap om et stadig mer aktuelt tema. Denne kunnskapen vil vi kunne benytte oss av i framtidig arbeid.


44

REFERANSER

1. Cooltown: [online] http://www.cooltown.com 2. Newton, Harry, Network’s Telecom Dictionary, Quebec/Martinsburg, s. 325, 1998. 3. Kure, Ø., Basic Internet Protocol (IP), Telektronikk, s 3-11, 2.97. 4. Newton, Harry, Network’s Telecom Dictionary, Quebec/Martinsburg, s. 711, 1998. 5. Ad hoc network: [online]

http://searchmobilecomputing.techtarget.com/sDefinition/0,,sid40_gci213462,00.html 6. Tønnesen, Andreas, Ruting i Mobile Ad Hoc Nett. Essay, Universitetet i Oslo, mars

2003: [online] http://heim.ifi.uio.no/~andreto/hfag/hfessay.pdf 7. Bluetooth: [online] http://www.bluetooth.org 8. Trulove, J., Build your own Wireless Lan with projects, McGraw-Hill, 2002. 9. GSM, GPRS og UMTS: [online]

http://www.cisco.com/en/US/netsol/ns110/ns175/ns177/ns278/networking_solutions_design_guide_chapter09186a00801219ac.html#1003063

10. GSM: [online] http://ccnga.uwaterloo.ca/~jscouria/GSM/gsmreport.html#3 11. GPRS: [online] http://www.gsmworld.com/technology/gprs/intro.shtml#1 12. HSCSD: [online] http://telenormobil.no/bedrift/tjenester/gsmdata/beskrivelse/ 13. GPRS white paper: [online]

http://www.cisco.com/en/US/products/sw/wirelssw/ps873/products_white_paper09186a00800ad645.shtml

14. Lempiäinen, J., Manninen, M., Radio Interface System Planning for GSM/GPRS/UMTS, Kluwer Academic, 2001.

15. Terjesen, T., Applikasjonsutvikling – mobile tjenester, Master Thesis, NTNU, april, 2001.

16. Rækken, R., Walter, K. E., Fra GSM til UMTS – en oversikt: [online] http://www.item.ntnu.no/~thanhvan/doc/GSMtoUMTS.pdf

17. Cisco: [online] http://www.cisco.com/en/US/ne tsol/ns110/ns175/ns177/ns278/networking_solutions_design_guide_chapter09186a00801219ac.html#1057908

18. UMTS: [online] http://telenormobil.no/partner/tjenester/umts/beskrivelse/ 19. Eskedal, T. G., Paint, F., Quality of Service in UMTS, Telektronikk, 2/3 2001, 20. Alian, L., Mokhtary, P., Bruk av trådløs kommunikasjon i Material- og

Produksjonsstyring System (MPS), Hovedoppgave, Grimstad 2000 [online] http://siving.hia.no/ikt00/ikt6400/pmokhtar/rapport.htm#_Toc484243240

21. Kristiansen, L., Personlige multimediatjenester for mobile brukere, foiler fra Kursdagene ved NTNU: [online] http://www.item.ntnu.no/~lillk/presentations/UMTS-All-IP-mobile-services-2003-01-07.pdf

22. Øverby, Harald, Tele- og Tjenestemarkedet, Hovedprosjekt ved Telematikk ved NTNU, November 2001, Trondheim, s 42.

23. Borg, F., Monitoring Bluetooth network topology, Cand Scient Thesis, Universitetet i Oslo, Februar 2002.

24. Benediktsson, A., Guide: Bluetooth: [online] http://www.hardware.no/guider/bluetooth/index2.html

25. SPIKE: [online] http://elevenengineering.com/products/SPIKE.asp 26. HomeRF: [online]

http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci535092,00.html 27. HIPERLAN2: [online] http://www.hiperlan.uk.com/pages/whatishiperlan.htm


45

28. Ekahau Positioning Engine: [online] http://www.ekahau.com/products/positioningengine

29. Infrarød teknologi: [online] http://www.irda.org/standards/standards.asp 30. Mac-adresser: [online] http://kunnskapsnett.no/innhold/fbarp.htm 31. Mac-adresser: [online] http://odense.kollegienet.dk/service/mac.php 32. Lozinski, Z., Parlay/OSA – a New Way to Create Wireless Services: [online]

http://www.parlay.org/specs/library/IEC_Wireless_A_New_Way_to_Create_Wireless_Services.pdf

33. SQL: [online] http://www.w3schools.com/sql/default.asp 34. Parlay/OSA-arkitektur: [online]

http://www.item.ntnu.no/fag/ttm4130/Slides2002/16_AllAboutParlayOSA.pdf 35. Parlay/OSA: [online] http://www.parlay.org/docs/OSA-Parlay-

Opening_the_network_with_parlay.pdf 36. Parlay X: Parlay APIs 4.0. Parlay X Web Services White Paper: [online]

http://www.parlay.org 37. Parlay X: Parlay X Web Services Specification – Version 1.0 [online]

http://www.parlay.org 38. Lokasjonsserver: [online] http://www.pats.no 39. Moerdijk, A., Klostermann, L., Opening the networks with Parlay/OSA: Standards

and aspects behind the APIs. 40. Scourias, J, Overview of the Global System for Mobile Communications: [online]

http://ccnga.uwaterloo.ca/~jscouria/GSM/gsmreport.html#2 41. GSM [online]: http://www.comms.eee.strath.ac.uk/~gozalvez/gsm/gsm.html#6.1 42. SMS [online]: www.hssworld.com/commapps/smsc/faq.htm 43. J2SDK: [online] http://java.sun.com/j2se/1.4.2/docs/api/ 44. JMS: [online] http://java.sun.com/products/jms 45. JDBC: [online] http://java.sun.com/ 46. SOAP: [online] http://ws.apache.org/axis/ 47. Oracle: [online] http://www.oracle.com/ip/deploy/database/oracle9i 48. Parlay X for Movade 4.1, API Description, Incomit [CD-ROM] 49. Geodetic Datum and Coordinate System Specification, Ericsson, 2002 [CD-ROM] 50. Ekahau's Positioning Engine 2.0, Wi-Fi Planet, [online] http://www.wi-

fiplanet.com/reviews/SW/article.php/1560261


46

APPENDIKS: KILDEKODE

Følgende klasser har blitt implementert: • Client.java • UserInt.java • JDBCconnetion.java • LokasjonsConnector.java • SMSconnetor.java

Client.java import java.util.*; import java.lang.*; import java.io.*; import java.sql.Time; public class Client{ public String melding; public String mac; public Time time; public int tlf; JDBCconnection connection; LokasjonsConnector lokconn; ArrayList macs; SMSconnector smsC; UserInt ui; public Client(){ ui = new UserInt(this); ui.check_input(); connection = new JDBCconnection(); connection.dbConnect(); macs = connection.hentMac(); smsC = new SMSconnector(); lokconn = new LokasjonsConnector(this); lokconn.connect_pos(); for(int i = 0; i < macs.size(); i++){ lokconn.registrer_mac((String)macs.get(i));//sender med macadressen som er skrevet inn. } } public static void main(String args[]){ Client c = new Client(); } public void handle_position(String mac, Time time){ this.mac=mac; this.time=time; melding = connection.hentMsg(mac,time); if(melding == null){


47

System.out.println("Melding er null"); } tlf = connection.hentTlf(mac); try{ smsC.postMsg(melding,tlf); }catch(Exception e){ e.printStackTrace(); } } public void delete_mac(String mac){ for(int i = 0; i < macs.size(); i++){ lokconn.delete_mac((String)macs.remove(0));//sletter mac adresser... } } public void shut_down(){ delete_mac(mac); lokconn.disconnect_pos(); connection.close(); System.out.println("shutting down"); //til slutt... System.exit(0); } } UserInt.java import java.util.*; import java.lang.*; import java.io.*; public class UserInt{ BufferedReader in = null; Client client = null; public UserInt(Client c){ client = c; } public void check_input(){ (new Thread(){ public void run(){ String input = new String("notnull"); System.out.println("Skriv q og press enter når du vil avslutte"); //her tar vi vare på det som skrives inn i vinduet, og sjekker om det er q. try{ BufferedReader in = new BufferedReader(new InputStreamReader(System.in)); while(!input.equals("q")){ input = in.readLine();


48

if(input.equals("q")){ client.shut_down(); } } }catch(IOException ex){ ex.printStackTrace(); } } }).start(); //legger metoden i en tråd. Starter tråden før klienten går videre. //Denne tråden henger til noen trykker q og deretter enter. } } JDBCconnetion.java import java.sql.*; import java.util.*; public class JDBCconnection{ Connection conn; public String mac; public Time time; public int tlf; public String melding = null; public JDBCconnection(){ } public void dbConnect(){ try {//laster inn Oracles JDBC-driver. Kan kaste ClassNotFoundException Class.forName("oracle.jdbc.driver.OracleDriver"); //Kobler opp mot databasen conn = DriverManager.getConnection("jdbc:oracle:thin:@elefant.idi.ntnu.no:1521:ELEFANT", "TUNHEIM", "TUNHEIM"); }catch(Exception e){ e.printStackTrace(); } } public ArrayList hentMac(){ ArrayList macliste = null; Statement stmt = null; ResultSet rs = null; try{ stmt = conn.createStatement(); macliste = new ArrayList(); rs = stmt.executeQuery("SELECT macadr FROM Terminal t"); while(rs.next()){ String macadr = new String(rs.getString("macadr")); System.out.println("macadr som skal spores" + macadr);


49

macliste.add(macadr); } rs.close(); stmt.close(); }catch(Exception e){ e.printStackTrace(); if(rs != null){ //hvis rs ikke er null, er ting gjort og vi lukker. Hvis det er null, trengs det ikke å lukkes. try{ rs.close(); }catch(Exception ex){ ex.printStackTrace(); } } if(stmt != null){ try{ stmt.close(); }catch(Exception ex){ ex.printStackTrace(); } } } return macliste; } public String hentMsg(String mac, Time time){ Statement stmt = null; ResultSet rs = null; try{ stmt = conn.createStatement(); rs = stmt.executeQuery( "SELECT Tekst FROM Terminal INNER JOIN Fagvalg ON Fagvalg.Studentnr = Terminal.Studentnr INNER JOIN Melding ON Melding.Fagkode = Fagvalg.Fagkode WHERE Macadr = '" + mac + "'"); while(rs.next()){ melding = rs.getString("tekst"); System.out.println("Meldingen som skrives ut... " + melding); } }catch(Exception e){ e.printStackTrace(); if(rs != null){ try{ rs.close(); }catch(Exception ex){ ex.printStackTrace(); } } if(stmt != null){ try{ stmt.close(); }catch(Exception ex){


50

ex.printStackTrace(); } } } return melding;//sjekk hvis null hos mottaker. } public int hentTlf(String mac){ Statement stmt = null; ResultSet rs = null; try{ stmt = conn.createStatement(); rs = stmt.executeQuery("SELECT mobilnr FROM Terminal t WHERE t.macadr = '" + mac + "'"); while(rs.next()){ tlf = rs.getInt("mobilnr"); } }catch(Exception e){ e.printStackTrace(); if(rs != null){ try{ rs.close(); }catch(Exception ex){ ex.printStackTrace(); } } if(stmt != null){ try{ stmt.close(); }catch(Exception ex){ ex.printStackTrace(); } } } return tlf; } public void close(){ try{ conn.close(); }catch(Exception e){ e.printStackTrace(); e.printStackTrace(); } } }


51

LokasjonsConnector.java import com.telenor.positionserver.Position; import com.telenor.positionserver.PosRequest; import com.telenor.positionserver.NotifyArea; import java.util.*; import javax.naming.InitialContext; import javax.naming.Context; import javax.jms.*; import java.sql.*; public class LokasjonsConnector{ QueueConnection connection = null; QueueSession session = null; TemporaryQueue replyQueue = null; static QueueConnectionFactory factory = null; static Context context = null; static String queue_name = "position"; static int ackMode = Session.AUTO_ACKNOWLEDGE; QueueSender sender = null; Client client = null; String[] devices = null; String endUserId; public LokasjonsConnector(Client k){ client = k; } public void connect_pos(){ try{ Hashtable props = new Hashtable(); props.put(Context.PROVIDER_URL, "tcp://129.241.219.152:3035/"); props.put(Context.INITIAL_CONTEXT_FACTORY, "org.exolab.jms.jndi.mipc.IpcJndiInitialContextFactory"); context = new InitialContext(props); factory = (QueueConnectionFactory) context.lookup("JmsQueueConnectionFactory"); if(factory == null) { throw new RuntimeException("Failed to locate connection factory"); } connection = factory.createQueueConnection(); connection.start(); session = connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE); if(session == null){ System.out.println("Session er null"); } Queue queue = (Queue) context.lookup("position"); if (queue == null){ throw new RuntimeException("Failed to create the queue " + queue);


52

} sender = session.createSender(queue); replyQueue = session.createTemporaryQueue(); }catch(Exception e){ e.printStackTrace(); } } public void registrer_mac(String mac){ try { endUserId = mac; devices = new String[]{"urn:wlan:" + mac}; PosRequest u = new PosRequest(endUserId, "smsvarsling", PosRequest.NOTIFY, devices); NotifyArea na = new NotifyArea( 63.42231f, 10.43761f, 10); u.setNotifyArea(na); ObjectMessage message = session.createObjectMessage(u); message.setJMSReplyTo(replyQueue); sender.send(message, DeliveryMode.PERSISTENT, 2, 0); System.out.println("Request message sent"); Reply reply = new Reply(replyQueue, client); reply.start(); }catch (Exception exception) { exception.printStackTrace(); } } public void delete_mac(String mac){ try{ endUserId = mac; PosRequest u = new PosRequest(endUserId, "smsvarsling", PosRequest.DELETE, null); ObjectMessage message = session.createObjectMessage(u); message.setJMSReplyTo(replyQueue); sender.send(message, DeliveryMode.PERSISTENT, 2, 0); System.out.println("Delete message sent"); }catch (Exception exception) { exception.printStackTrace(); } } public void disconnect_pos(){ try{ sender.close();


53

}catch (Exception exception){ exception.printStackTrace(); } } class Reply extends Thread implements ExceptionListener { TemporaryQueue replyQueue = null; Client client = null; public Reply(TemporaryQueue replyQueue, Client k){ this.replyQueue = replyQueue; client = k; } public void run() { System.out.println("Waiting for result"); try { while (true){ QueueReceiver receiver = session.createReceiver(replyQueue); //System.out.println("er i while -løkken"); ObjectMessage message = (ObjectMessage) receiver.receive(); Position position = (Position) message.getObject(); Time t = new Time(position.getDateTime().getTime()); client.handle_position(position.getEndUser(), t); System.out.println("Received position = " + position.toString()); } } catch (Exception ee) { System.out.println("Unexpected exception: " + ee.toString()); ee.printStackTrace(); } finally { try { if (session != null) session.close(); if (connection != null) connection.close(); } catch (JMSException e) { e.printStackTrace(); } } } public void onException(JMSException exception){ try{ connection.close();


54

} catch (Exception error) { error.printStackTrace(); } System.out.println("Exit signal from user"); System.exit(0); } } } SMSconnector.java import java.lang.*; import sms.*; import login.*; public class SMSconnector{ public String tekst; public int tlf; public String telefon; public SMSconnector(){ } public void postMsg(String tekst, int tlf)throws Exception{ this.tekst = tekst; this.tlf = tlf; String appDomain = "espa_app1"; String user = "foerster"; String password = user; String senderName = "19949"; //mailboks. String charging = "CP_FREE"; //Login - er ikke del av ParlayX. Sender id tilbake - legger denne i soap-headeren. System.out.println("Logging in ...."); UserLoginPort loginPort = getLoginPort(); int sessionId = loginPort.login(appDomain, user, password); System.out.println("SessionId: " + sessionId); //Send sms System.out.print("Sending SMS .... "); SendSmsPort smsPort = getSendSmsPort(sessionId); EndUserIdentifier[] eu = new EndUserIdentifier[1]; eu[0] = new sms.EndUserIdentifier(); telefon = new Integer(tlf).toString();


55

eu[0].setValue(new org.apache.axis.types.URI("tel", telefon)); //dette telefonummeret sendes fra Client. Her skal en string sendes med! System.out.println("EU\t"+eu); System.out.println("senderName\t"+senderName); System.out.println("Char\t"+charging); System.out.println("tekst\t"+tekst);

String smsId = smsPort.sendSms(eu, senderName, charging, tekst); //meld kommer fra Client System.out.println("ok. SMSId: " + smsId); //Logout System.out.print("Logging out..."); loginPort.logout(sessionId); System.out.println("OK"); } public UserLoginPort getLoginPort() throws Exception{ UserLoginService loginService = new UserLoginServiceLocator(); UserLoginPort loginPort = loginService.getUserLoginPort(); return loginPort; } public SendSmsPort getSendSmsPort(int sessionId) throws Exception { SendSmsService smsService = new SendSmsServiceLocator(); SendSmsPort smsPort = smsService.getSendSmsPort(); addSecurityHeader(sessionId, smsService.getSendSmsPortAddress(), (org.apache.axis.client.Stub)smsPort); return smsPort; } public void addSecurityHeader(int sessionId, String wsdlUrl, org.apache.axis.client.Stub stub) { org.apache.axis.message.SOAPHeaderElement header = new org.apache.axis.message.SOAPHeaderElement(wsdlUrl, "Security" , "" ); header.setActor( "wsse:PasswordToken" ); header.addAttribute(wsdlUrl, "Username" , String.valueOf(sessionId)); header.addAttribute(wsdlUrl, "Password" , String.valueOf(sessionId)); header.setMustUnderstand(true); stub.setHeader(header); } }

new forord - iik ntnupeople.item.ntnu.no/~lillk/stud-proj/tunheim-foerster... · 2003. 11. 26. ·...

Documents