Lokasjons- og kontekstbaserte tjenester - Department of Computer ...

More documents

Recommendations

Info

4 PROTOTYPING 61 scope, slik det er implementert i denne oppgaven, inneholder kun en unik ID og et navn, men det er ogs˚a mulig ˚a legge inn alternative attributter som en beskrivelse, dato for opprettelse, eier osv. Dette støtter opp under forslaget i AROUND ved at systemet skal slippe ˚a søke igjennom hele det tilgjengelige informasjonsrommet, se avsnitt 3.5. Oppgaven har tidligere sagt at et scope kan inneholde en eller flere tjenester. Dette skaper en en-til-mange relasjon. Men for at en tjeneste ikke kun kan eksistere i et scope, var det nødvendig ˚a dele opp relasjonen mellom scope og tjeneste. Slik modellen er implementert ble det opprettet en ekstra entitet, S S (Scope til Service), som løser opp denne mange-til-mange relasjonen i to en-til-mange relasjoner. Se Figur 16. Tjeneste er her beskrevet som “Service”. Et scope kan n˚a inneholde flere tjenester, og vice versa, men samme problem oppst˚ar n˚ar et scope skal knyttes til en lokasjon: En lokasjon kan være knyttet til flere enn et scope, og et scope kan være knyttet til flere lokasjoner. Igjen har modellen en mange-til-mange relasjon. Denne ble delt opp i to en-til-mange relasjoner ved ˚a innføre en entitet L S (Lokasjon til Scope), p˚a samme m˚ate som for scope til tjenester. Forskjellen er her at lokasjon, slik definert i modellen, kan være: campus, bygning, etasje eller rom. Entiteten L S inneholder derfor en attributt “Coverage” som sier hvilken av disse omr˚adene som dekkes og hvilken lokasjon (for omr˚adet “Room” hvilket rom, for omr˚adet “Floor” hvilken etasje osv.) det er snakk om. Figur 16: Relasjonen mellom lokasjon og informasjon i FUMBLE Denne modellen skaper en relasjon mellom lokasjonsdata og informasjonsdata som utnytter strukturen i lokasjonshierarkiet og som samtidig støtter b˚ade informasjon og tjenester. For ˚a utdype dette litt s˚a er informasjonsdata knyttet til lokasjonsdata p˚a en slik m˚ate at systemet slipper ˚a traversere lokasjonshierarkiet for ˚a finne fram til korrekt lokasjon. M˚aten modellen støtter b˚ade informasjon og tjenester er vha. attributten URL i entiteten Service, ved ˚a legge ut informasjonen p˚a en webside, eller ved at informasjonen skrives inn i “Alt description”. Her bør det ta en avgjørelse som systemet skal kunne lagre informasjon internt (i Alt description) og via eksterne websider, eller at informasjon kun kan knyttes til systemet via eksterne websider.
62 4 PROTOTYPING Se ogs˚a avsnitt 6.3. 4.6 Datastruktur Lokasjonsdataene er organisert i en klassisk tre-struktur. I et ferdig system ville rotnoden vært “Verden” 27 , men siden dette er en prototype er rotnoden “Gløshaugen”. Et niv˚a lengre ned finner vi foreløpig bygningene IT-Vest, IT-Øst og IT-Sør. Tredje niv˚a best˚ar av etasjer og fjerde niv˚a inneholder rom. Femte niv˚a inneholder fingeravtrykkene som er det minste omr˚adet (alts˚a et punkt) dette systemet kan behandle. Grunnen til at oppgaven har valgt denne strukturen er fordi dette er et innendørs lokasjonssystem, da utendørs posisjonering allerede er realisert gjennom GPS 28 og snart Galileo 29 . 4.6.1 Datainnsamling For ˚a gjøre Fumble operativ m˚a det samles inn data beskrevet som fingeravtrykk tidligere. Dette skjer i en offlinefase, eg. ingen lokalisering kan skje før denne fasen er over. (Det er derimot ingenting i veien for ˚a legge til flere fingeravtrykk selv n˚ar offlinefasen kan sies ˚a være avsluttet.) I offlinefasen lages og analyseres fingeravtrykkene med tanke p˚a ˚a øke presisjonen og lette gjenfinningsarbeidet i onlinefasen. I onlinefasen trekker prototypen slutninger ut i fra hva slags signaler den f˚ar inn p˚a gjeldene lokasjon mot fingeravtrykkene som er lagret i offline fasen. Sammenlignet med [24] er offlinefasen den samme, men onlinefasen er noe endret. I RADAR[24] sender hver klient ut et signal som fanges opp av basestasjonene og signalstyrken lagres i disse. I v˚ar løsning er det klienten som foretar en periodisk scan og lagrer signalstyrken lokalt. Uansett, dette har ingen betydning for presisjonen som konkludert med i RADAR. Et tr˚adløst nettverkskort samler inn masse informasjon om de tr˚adløse nettverkene som er tilgjengelige, men bare et lite sett av dette er brukbart for lokalisering. Det er fire attributter som er aktuelle for lokalisering: MAC (Media Access Control), RSS (Recieved Signal Strenght), Noise og SNR (Signal-to-noise ratio). MAC brukes til ˚a skille de forskjellige aksesspunktene fra hverandre. RSS, Noise og SNR kan alle benyttes for ˚a lokalisere en tr˚adløs klient, men som vi skal se er det bare RSS som er praktisk. RSS sammen med Noise danner grunnlag for SNR, men som konkludert med i [24, 18] er RSS en sterkere funksjon enn SNR fordi SNR blir p˚avirket av tilfeldig støy (Noise). Dette er bekreftet gjennom arbeidet med Fumble, da presisjonen økte merkbart ved ˚a basere lokaliseringen p˚a RSS, i stedet for SNR. I tillegg viste seg at NetStumbler i noen tilfeller rapporterte -100dBm for noise for enkelte kort, 27 Omtalt som “Campus” i kildekoden. 28 http://en.wikipedia.org/wiki/Gps 29 http://en.wikipedia.org/wiki/Galileo positioning system
Page 1 and 2:
Lokasjons- og kontekstbaserte tjene
Page 3 and 4:
ii Sammendrag Denne oppgaven presen
Page 6 and 7:
INNHOLD v Innhold Forord i Sammendr
Page 8 and 9:
INNHOLD vii 5.3.1 Innhold i testdat
Page 10:
TABELLER ix 15 Tabell Type . . . .
Page 13 and 14:
2 1 INNLEDNING mye tid du har tilgj
Page 15 and 16:
4 1 INNLEDNING baren. Etter en lite
Page 17 and 18:
6 2 STATE OF THE ART 2.1.1 Lokasjon
Page 19 and 20:
8 2 STATE OF THE ART fastsl˚a at e
Page 21 and 22: 10 2 STATE OF THE ART Se ogs˚a avs
Page 23 and 24: 12 2 STATE OF THE ART 2.2.3 Metadat
Page 25 and 26: 14 2 STATE OF THE ART graphs with p
Page 27 and 28: 16 2 STATE OF THE ART 2.3.2 RADAR R
Page 29 and 30: 18 2 STATE OF THE ART sisjonsavheng
Page 31 and 32: 20 2 STATE OF THE ART det ikke fore
Page 33 and 34: 22 2 STATE OF THE ART som befinner
Page 35 and 36: 24 3 MITT SYSTEM 3.2 Brukere av sys
Page 37 and 38: 26 3 MITT SYSTEM Appendix B. Bruker
Page 39 and 40: 28 3 MITT SYSTEM Figur 4: Systemstr
Page 41 and 42: 30 3 MITT SYSTEM stavhengig system.
Page 43 and 44: 32 3 MITT SYSTEM Figur 6: Mulige ka
Page 45 and 46: 34 3 MITT SYSTEM AROUND-arkitekture
Page 47 and 48: 36 3 MITT SYSTEM I de neste punkten
Page 49 and 50: 38 3 MITT SYSTEM logge seg inn i de
Page 52 and 53: 4 PROTOTYPING 41 4 Prototyping P˚a
Page 54 and 55: 4 PROTOTYPING 43 vil være unik for
Page 56 and 57: 4 PROTOTYPING 45 Figur 12: Signalst
Page 58 and 59: 4 PROTOTYPING 47 oppgaven og det er
Page 60 and 61: 4 PROTOTYPING 49 en del av samme sy
Page 62 and 63: 4 PROTOTYPING 51 4.3.1 Valgt teknol
Page 64 and 65: 4 PROTOTYPING 53 - Navnetyper inneh
Page 66 and 67: 4 PROTOTYPING 55 - Finn lokasjon: D
Page 68 and 69: 4 PROTOTYPING 57 Figur 14: Fumble :
Page 70 and 71: 4 PROTOTYPING 59 Figur 15: Fumble :
Page 74 and 75: 4 PROTOTYPING 63 muligens fordi enk
Page 76 and 77: 4 PROTOTYPING 65 AP ID MAC Signal N
Page 78 and 79: 4 PROTOTYPING 67 Utover dette har i
Page 80 and 81: 4 PROTOTYPING 69 Figur 19: Informas
Page 82: 4 PROTOTYPING 71 4.8 Oppsummering p
Page 85 and 86: 74 5 TESTING OG EVALUERING AV FUMBL
Page 105 and 106: 94 6 KONKLUSJON OG VIDERE ARBEID in
Page 107 and 108: 96 6 KONKLUSJON OG VIDERE ARBEID M
Page 110 and 111: REFERANSER 99 Referanser [1] A9. A9
Page 112 and 113: REFERANSER 101 [22] Ole Hestnes og
Page 114 and 115: A TERMINOLOGI 1 Appendix A Terminol
Page 116 and 117: B KRAVSPESIFIKASJON 3 Alternative c
Page 118 and 119: B KRAVSPESIFIKASJON 5 3. Case condi
Page 120 and 121: B KRAVSPESIFIKASJON 7 - Attributten
Page 122 and 123:
C INSTALLASJONSMANUAL FUMBLE 9 C In
Page 124 and 125:
D BRUKERMANUAL FUMBLE 11 D Brukerma
Page 126 and 127:
E TR˚ADLØSE SIGNALER 13 E Tr˚adl
Page 128 and 129:
F FUNKSJONER 15 dette. I tillegg er
show all

Lokasjons- og kontekstbaserte tjenester - Department of Computer ...

Create successful ePaper yourself

Delete template?

Save as template?