Kontekst i heterogene nett, med fokus på brukerkontekst

Kontekst i heterogene nett, med fokus på brukerkontekst Masteroppgave av Ellen Foerster Trondheim, juni 2004 NTNU - Fakultetet for informasjonsteknologi, matematikk og elektronikk

NORGES TEKNISK-NATURVITENSKAPELIGE UNIVERSITET FAKULTET FOR INFORMASJONSTEKNOLOGI, MATEMATIKK OG ELEKTROTEKNIKK MASTEROPPGAVE Kandidatens navn: Ellen Foerster Fag: Telematikk, teletjenester og nett. Oppgavens tittel (norsk): Kontekst i heterogene nettverk, med fokus på brukerkontekst. Oppgavens tittel (engelsk): Context in Heterogeneous Networks, with Focus on User Context. Oppgavens tekst: Det skal utføres en state-of-the-art-studie på kontekst, kontekstsensitivitet og brukerkontekst. Det skal gjøres klart hvilke definisjoner som brukes av begrepene i oppgaven. Det skal utarbeides arkitektur, strukturere kontekstdata og definere grensesnitt for bruk av kontekst i heterogene tjenester. Såkalte call-flows for prosessering av kontekstinformasjon skal studeres. Det skal utvikles scenarioer der brukerkontekst anvendes i heterogene nettverk. Et proof of the concept skal utarbeides og deler av et slikt scenario skal implementeres. Oppgaven gitt: 20. januar 2004 Besvarelsen leveres innen: 15. juni 2004 Besvarelsen levert: 15. juni 2004 Utført ved: Institutt for telematikk Veileder: Josip Zoric, ved Telenor, og Lill Kristiansen, ved NTNU. Trondheim, 15. juni 2004 Lill Kristiansen Faglærer

Forord Denne rapporten er et resultat av arbeidet med masteroppgaven i 10. semester ved sivilingeniørutdanningen ved Norges teknisk-naturvitenskapelige universitet, NTNU. Arbeidet ble utført ved Telenor FoU og ved NTNU i Trondheim våren 2004. Veiledere har vært Josip Zoric ved Telenor og Lill Kristiansen ved NTNU. Lill Kristiansen har også vært min faglærer ved institutt for Telematikk, NTNU. Jeg ønsker å rette en takk til Josip Zoric for nyttige innspill under arbeidet med masteroppgaven. Jeg ønsker også å rette en takk til Lill Kristiansen, for god veiledning og oppmuntring. Til slutt vil jeg takke Ingebrigt Fuglem og Jan Vedvig ved Telenor Fou for nyttige tips. Trondheim, juni 2004 Ellen Foerster v

Sammendrag Denne rapporten ser på betydningen av kontekst og kontekstsensitivitet, med fokus på brukerkontekst. Definisjoner av kontekst og kontekstsensitivitet introduseres. Det identifiseres hvorfor slik informasjon er vanskelig å bruke, og hva som skal til for at kontekstsensitive applikasjoner skal bli enklere å utvikle. Kontekstparametrene lokasjon, presence og tid er spesielt vektlagt, fordi de regnes som de grunnleggende kontekstparametrene. Brukerscenarioer presenteres for å gi leseren en idé om hvordan slik informasjon kan benyttes i tjenester. Rapporten beskriver hvordan informasjon kan samles inn fra ulike nettverk og teknologier, og hvordan dataene prosesseres og eventuelt lagres for senere bruk. Det er fokusert på fordeler ved å gjøre applikasjoner uavhengig av sensorteknologi, og hvordan innsamling og prosessering av sensordata kan gjøres i et frittstående miljø, transparent for applikasjonen som skal bruke informasjonen. Forslag til arkitektur er utarbeidet og enheter nødvendig for å behandle kontekstdata er foreslått. I tillegg er det sett på kostnad og personvern ved bruk av kontekstinformasjon. I det praktiske arbeidet implementeres en demonstrasjonstjeneste, som demonstrerer hvordan presence, tid og lokasjon kan anvendes. Tjenesten er en proof of the concept, og har derfor begrenset funksjonalitet. Tjenesten er utviklet for å vise hvordan kontekstinformasjon kan samles inn fra ulike nettverk, lagres, sammenstilles og brukes i en tjeneste. vii

Sammendrag viii

Innhold Forord Sammendrag Ordforklaring v vii xv 1 Innledning 1 1.1 Bakgrunn.................................... 1 1.2 Problemstilling................................. 2 1.3 Begrensninger.................................. 2 1.4 Oppbygning................................... 3 1.5 Definisjoner på noen begreper brukt i oppgaven............... 3 2 Kontekst generelt 7 2.1 Hva er kontekst?................................ 7 2.2 Ulike typer kontekst.............................. 8 2.3 Kontekstsensitivitet............................... 9 2.4 Hvorfor er kontekst vanskelig å bruke?.................... 10 2.5 Brukerscenarioer................................ 11 3 Nettverk 13 3.1 GSM og GPRS................................. 13 3.2 UMTS...................................... 15 3.3 Bluetooth.................................... 18 3.4 WLAN...................................... 19 3.5 Oppsummering................................. 20 4 Lokasjon som kontekstparameter 21 4.1 Hva er lokasjon?................................. 21 4.2 Standarder for beskrivelse av lokasjon..................... 22 4.3 Lokasjonssystemer............................... 22 4.4 Innsamling av lokasjonsinformasjon fra ulike nettverk............ 24 4.5 Andre lokasjonssystemer............................ 27 ix

INNHOLD 4.6 Oppsummering og oversikt........................... 27 5 Presence og tid som kontekstparametre 29 5.1 Tid........................................ 29 5.2 Presence som konteksttype........................... 30 5.3 Oppsummering................................. 34 6 Arkitektur og lagring av kontekstinformasjon 35 6.1 Viktig ved utforming av arkitektur...................... 35 6.2 Sensorer..................................... 40 6.3 Arkitektur ved bruk av lokasjon, tid og presence............... 41 6.4 Lagring av kontekstdata............................ 48 6.5 Brukerprofil................................... 50 6.6 Personvern.................................... 51 6.7 Kostnad..................................... 52 6.8 Oppsummering................................. 53 7 Praktisk gjennomføring av kontekst 55 7.1 Fullstendig scenario............................... 55 7.2 Scenario for demotjenesten........................... 56 7.3 Teknisk beskrivelse av demotjenesten..................... 56 7.4 Framgangsmåte................................. 56 7.5 Krav....................................... 57 7.6 Anvendt teknologi............................... 58 7.7 Begrensninger.................................. 61 7.8 Arkitektur.................................... 62 7.9 Lagring av kontekstdata i tjenesten...................... 64 7.10 Meldingsflyt................................... 65 7.11 Implementering................................. 71 7.12 Oppsummering og evaluering av det praktiske arbeidet........... 74 8 Konklusjon og framtidig arbeid 75 8.1 Konklusjon................................... 75 8.2 Framtidig arbeid................................ 76 Referanser 84 A SIP-meldinger 85 B Jain SIMPLE 91 C Sending av SMS i GSM-nettet 93 x

Figurer 1.1 Telenettets oppbygning. [1]........................... 5 2.1 Flere kilder gir samme informasjon til applikasjonen............. 10 3.1 GSM-arkitektur [2]............................... 14 3.2 GPRS-arkitektur, hentet fra Cisco.[3]..................... 14 3.3 Grunnleggende domener i UMTS. [4]..................... 16 3.4 Funksjonelle enheter i User Equipment. [4].................. 17 3.5 Nettmodell i 3GPP. [5]............................. 17 3.6 Signallering i UMTS.[5]............................. 18 3.7 Bluetooth-nettverk. [6]............................. 19 3.8 WLAN-arkitektur[7].............................. 20 4.1 Et typisk GPS-system.[8]............................ 23 4.2 Konfigurasjon av RadioEye.[9]......................... 26 5.1 Konseptmodell i SIP.[10]............................ 32 5.2 Register-, subscribe-og notify-meldinger i SIP.[11].............. 32 5.3 Meldingsflyt for presence-informasjon i UMTS.[12].............. 33 6.1 De ulike lagene som kan inngå i forvaltning av kontekst[13].......... 37 6.2 Arkitektur for håndtering av kontekstinformasjon i mobile nettverk[14]... 37 6.3 Parlay/OSA-arkitektur.[15]........................... 39 6.4 Lokasjonsinnhenting ved hjelp av OSA.................... 39 6.5 Regulatør i nettverket, ved bruk av OSA.[16]................. 40 6.6 Overordnet arkitektur for kontekst...................... 42 6.7 Foreslått arkitektur for bruk av kontekst................... 43 6.8 Informasjon fra sensorer til enhet som samler inn informasjon........ 45 6.9 Enheter håndterer kontekstinformasjon..................... 45 6.10 Informasjon samles inn og bearbeides...................... 46 6.11 Logikk i server avgjør data som skal sendes applikasjonene.......... 46 6.12 En applikasjon eller server kan spørre etter data................ 47 6.13 En applikasjon eller server kan abonnere på data............... 47 6.14 Utveksling av kontekst mellom ulike nettverk................. 48 xi

FIGURER 7.1 Steg i utviklingsprosessen........................... 57 7.2 Arkitektur til lokasjonsserveren. [17]...................... 59 7.3 Arkitektur i ParlayX.[18]............................ 61 7.4 Arkitektur i demotjenesten........................... 62 7.5 Alternativ arkitektur i demotjenesten..................... 64 7.6 Lagring av kontekstdata............................. 65 7.7 Meldingesflyt i tjenesten............................. 66 7.8 Meldinger som utveksles for å finne lokasjonen til en bruker......... 67 7.9 Varsling om når en bruker kommer inn i et WLAN-område.......... 68 7.10 REGISTER-melding fra kontekstserveren til SIP-serveren.......... 69 7.11 SUBSCRIBE-melding fra kontekstserveren til SIP-serveren.......... 69 7.12 Sending av SMS ved hjelp av ParlayX og ParlayOSA............. 70 7.13 Klassediagram i demotjenesten......................... 71 7.14 Meldinger mellom kontekstserver, SIP-server og SIP-klienten......... 73 A.1 Meldingsflyt mellom kontekstserver, SIP-server og SIP-klient......... 85 A.2 REGISTER-melding fra kontekstserver til SIP-server............. 86 A.3 OK-melding fra SIP-server til kontekstserver.................. 87 A.4 SUBSCRIBE-melding fra kontekstserver til SIP-server............ 87 A.5 OK-melding fra SIP-server til kontekstserver.................. 88 A.6 SUBSCRIBE-melding fra SIP-server til SIP-klienten............. 88 A.7 BAD-EVENT-melding fra SIP-klienten til SIP-serveren............ 89 C.1 Ruting av SMS i GSM-nettet [6]........................ 93 xii

Tabeller 4.1 Oversikt over nøyaktighet av lokasjon..................... 28 6.1 Statisk og dynamisk kontekstinformasjon.................... 49 xiii

TABELLER xiv

Ordforklaring API AS BS BSC BSS CC CSA CSAC CSCF EOTD FAMOUS GEOREF GGSN GPRS GPS GSM HLR HSS IETF IMPS ISO ITU JDBC JMS J2SDK LAN ME MMS MS MSC MT Application Program Interface Application Servers Base Station Base Station Controller Base Station Subsystem Context Client Context Service Adapter Context Service Adapter Client Call Session Control Functions Enhanced observed time difference Framework for Adaptive Mobile and Ubiquitous Services World Geographic Reference System Gateway GPRS Support Node General Packet Radio Service Global Positioning System Global System for Mobile Communication Home Location Register Home Subscriber Service The Internet Engineering Task Force Instant Messaging and Presence Systems International Organization for Standardization International Telecommunication Union Java Database Connectivity Java Message Service Java 2 Standard Development Kit Local Area Network Mobile Equipment Multimedia Messaging Service Mobile Station Mobile Switching Centre Mobile Equipment xv

Ordforklaring NIST OTDOA OMA OSA PC PDA PIDF RFC RFid SIMPLE SCS SGSN SIM SIP SMS SMSC SOAP SQL TA TE TINA UMTS UE USIM VLR WLAN WGS 3G National Institute of Standards and Technology Observed Time Difference Of Arrival Open Mobile Alliance Open Services Architecture Personal Computer Personal Digital Assistant Presence Information Data Format Request for Comments Radio Frequency Identification SIP for Instant Messaging and Presence Leveraging Extentions Service Capability Server Serving GPRS Support Node Subscriber Identity Module Session Initiation Protocol Short Message Service SMS Centre Simple Object Access Protocol Structured Query Language Timing Advance Terminal Equipment Telecommunication Information Networking Architecture Universal Mobile Telecommunication System User Equipment User Service Identity Module Visiting Location Register Wireless Lan World Geidetic System Tredje-generasjons mobile nettverk xvi

Kapittel 1 Innledning I dette kapitlet presenteres bakgrunnen for oppgaven, problemstilling, begrensninger og strukturering av rapporten. 1.1 Bakgrunn Mennesker tolker lett situasjoner og miljøet rundt seg ved å bruke informasjon om den nåværende situasjonen. Vi er i stand til å gjøre dette på grunn av et rikt språk og en felles forståelse av verden og dagligdagse situasjoner. Når mennesker kommuniserer utnytter vi implisitt informasjon knyttet til situasjonen. Denne type informasjon kalles kontekstinformasjon. Inntil nylig har mobile brukere kun hatt tilgang til tradisjonelle telefontjenester i det svitsjede nettverket. Tjenestene har vært statiske applikasjoner, og mobilitet har blitt sett på som et problem i stedet for en egenskap med nye muligheter. I dag er denne situasjonen i forandring, og mulighetene som ligger i mobilitet utforskes. Trådløs teknologi og sensorteknologi gjør at enheter kan brukes på flere steder. Nye tjenester kommer stadig på markedet og brukeren forventer hele tiden mer. Tradisjonelle interaktive applikasjoner er begrenset til å bruke innformasjon som brukeren gir eksplisitt. Når brukere beveger seg i mobile miljøer er det et økende behov for at applikasjoner kan påvirkes av implisitt informasjon eller kontekst. Mobilitet gir grunnlag for mye kontekstinformasjon, fordi brukere og enheter kan bevege seg fra sted til sted, og fra nettverk til nettverk. Slik informasjon er vanligvis ikke tilgjengelig for applikasjonene, men kan være nyttige for å tilpasse tjenesten til brukeren. Applikasjoner kan ikke tilpasse seg omgivelsene på samme måte som vi kan, men ved å gi applikasjonene tilgang på kontekstinformasjon kan tjenesten tilpasses omgivelsene. Applikasjoner som bruker kontekst kalles kontekstsensitive applikasjoner. 1

Innledning Konvergens mellom telefonitjenester og Internett har gjort det mulig å kombinere pakkebaserte og linjebaserte nettverk. Dette har lagt grunnlag for ny kommunikasjon og verdiøkende nettverkstjenester. Disse tjenestene er ikke begrenset til tale og enkle meldinger, men kan tilby kompliserte multimediatjenester og peer-to-peer interaksjon. 1.2 Problemstilling Ved å gi applikasjoner tilgang på kontekstinformasjon kan tjenester til en viss grad tilpasses omgivelsene, og dermed tilpasses brukeren i størst mulig grad. Ved å anvende og kombinere kontekstparametere kan det bli laget nye tjenester som møter de stadig voksende kravene til brukerne. Rapporten studerer blant annet begrepet kontekst, og hvordan dette kan brukes for å gjøre applikasjoner kontekstsensitive. I denne oppgaven fokuseres det på kontekstparametrene presence, lokasjon og tid. Nødvendig erfaring med utvikling av kontekstsensitive applikasjoner er lav. Rapporten ser på hva som gjør slike applikasjoner vanskelig å utvikle, og hvorfor kontekstinformasjon er vanskelig å bruke. Kontekstinformasjon kan samles inn fra forskjellige kilder. Ulike nettverk og teknologier, som kan gi kontekstinformasjon, studeres og evalueres. Arkitektur og prosesser for å samle inn og prosessere kontekstinformasjon utarbeides. Rapporten ser på muligheten for å lagre kontekstinformasjon, og hvordan applikasjoner skal kunne etterspørre kontekstinformasjon. En demonstrasjonstjeneste designes for å vise hvordan kontekstparametrene presence, lokasjon og tid kan samles inn fra ulike nettverk og anvendes i en tjeneste. Arkitektur utarbeides og applikasjonen implementeres. Tjenesten er kun ment å være en proof of the concept, og har derfor begrenset funksjonalitet. 1.3 Begrensninger Temaet som studeres i oppgaven er stort, og det har vært nødvendig å gjøre visse begrensninger. Det er valgt å fokusere på brukerkontekst, mer spesifikt på lokasjon, tid og presence, som i litteraturen har blitt betegnet som de grunnleggende kontekstparametrene. Personvern, sikkerhet og kostnad er viktige aspekter innenfor kontekst. Dette omtales i rapporten, men er ikke vektlagt. Det praktiske arbeidet har bestått i å utvikle en demonstrasjonstjeneste der lokasjon, presence og tid anvendes. Tjenesten er et proof of the concept, og er ikke ment å fungere som en fullstendig tjeneste. Den skal vise hvordan kontekstinformasjon kan brukes og mulighetene som ligger i slike tjenester. Rammeverket som er utviklet har ikke tatt hensyn til skalerbarhet. 2

1.4 Oppbygning I det praktiske arbeidet har tilgjengelig teknologi på PATS-laben på Telenor og på NTNU benyttet, noe som har gitt visse begrensninger i valg av teknologi. Det er vanlig å presentere arkitektur før teknologi, men fordi tilgjengelig teknologi har vært avgjørende for deler av arkitekturen, er det valgt å presentere anvendt teknologi før arkitektur presenteres. Presence er et utstrakt begrep i telekommunikasjons-litteraturen, og det velges derfor å ikke oversette ordet til norsk. 1.4 Oppbygning Kapittel 2 forklarer hva som menes med kontekst, kontekstsensitivitet og hvorfor kontekstinformasjon er vanskelig å bruke. Noen begrep brukt i oppgaven defineres. Kapittel 3 beskriver ulike nettverk som kan være kilde til kontekstinformasjon. Kapittel 4 tar for seg lokasjon som kontekstparameter og hvordan slik informasjon samles inn fra ulike nettverk. Kapittel 5 ser på presence og tid som kontekstparameter. Kapittel 6 beskriver hva som er viktig ved utforming av arkitektur, lagring av kontekstdata og personvern ved bruk av slik kontekstinformasjon. Kapittel 7 gir eksempler på brukerscenarioer der presence, lokasjon og tid benyttes. Kapittel 8 beskriver den praktiske gjennomføringen av oppgaven. 1.5 Definisjoner på noen begreper brukt i oppgaven Dette avsnittet definerer begreper brukt i oppgaven som ikke naturlig passer inn under andre kapitler. 1.5.1 Tjeneste De fleste har en oppfattelse av hva en tjeneste er. Det er et begrep, som ofte benyttes og som har mange definisjoner. En vanlig forståelse av en tjeneste, er at det er et sett varer eller verdifulle funksjoner som tilbys av en tjenesteleverandør, og som gir en verdiøkning for brukeren. Nedenfor nevnes noen definisjoner. Gozdecki et. al.[19] omtaler en tjeneste i telekommunikasjonssammenheng til å være:...the capability to exchange information through a telecommunications medium, provided to a customer by a service provider. 3

Innledning Tjeneste i IP-nettverk er definert av ITU [20] som: A service provided by the service plane to an end user (e.g., a host [end system] or a network element) and which utilizes the IP transfer capabilities and associated control and management functions, for delivery of the user information specified by the service level agreements. TINA[21] beskriver i [22] en tjeneste som:...a meaningful set of capabilities provided by an existing or intended system to all business roles that utilize it; each business role sees a different perspective of the service. TINA sin definisjon er bred og inkluderer ulike type tjenester. I denne oppgaven legges det vekt på denne definisjonen. 1.5.2 Nettverk Nettverk muliggjør utveksling av informasjon. I dette avsnittet presenteres begrepet fra data- og telekom-siden. Tidligere var det et tydelig skille mellom disse nettverkene; datanettverk var pakkesvitsjet, mens telekom-nettverk var linjesvitsjet. Konvergens mellom telefonitjenester og Internett i senere tid, har gjort det mulig å kombinere pakkebaserte og linjebaserte nettverk. Telekom-nett består i dag av både pakkesvitsjede og linjesvitsjede domener. Skillet mellom disse nettene er derfor ikke lenger like klare. Begrepet heterogene nettverk forklares i avsnitt 1.5.2.3. 1.5.2.1 Tradisjonelle telenett Tradisjonelle telenett er linjesvitsjede. Ifølge Dictionary of communications technology[23] er det linjesvitsjet telenettverk et nettverk av telefonlinjer som vanligvis brukes for telefonsamtaler. Samferdselsdepartementet omtaler i [1] de grunnleggende elementer i telenettet. Disse er listet opp under og vises i figur 1.1 : Aksessnett Transportnett Tjenestenett Drifts- og støttesystemer Brukerutstyr 4

1.5 Definisjoner på noen begreper brukt i oppgaven Figur 1.1: Telenettets oppbygning. [1] 1.5.2.2 IP-nett Hoem [24] definerer datanettverk som: Et datanettverk kan defineres som et antall datamaskiner og spesialiserte bokser som kommuniserer gjennom et kommunikasjonsmedium. IP-nett er nettverk hvor informasjon utveksles ved hjelp av IP-pakker. En pakke er et stykke data, som i tillegg til informasjonen, blant annet inneholder adressen til destinasjonen. Disse pakkene kan ta ulike veier i nettverket, før det kommer fram til destinasjonen. MacKie- Mason[25] forklarer begrepet pakke på følgende måte: The term packets refers to the fact that the data stream for your computer is broken up into packets of about 200 bytes (on average), which are then sent out onto the network. Each packet contains a header with information necessary for routing the packet from origination to destination. Thus each packet in a data stream is independent. 1.5.2.3 Heterogene nett I Dictionary of Networking[23] betegnes heterogene nett som A network constructed using hardware and software from different vendors, usually operating multiple protocols. Som beskrevet over, kan heterogene nett defineres som nettverk bestående av hardware og software fra ulike leverandører. I denne oppgaven fokuseres det derimot på bruk av mulitple protokoller i slike nettverk. I rapporten defineres heterogene nettverk som nettverk med ulike protokoller, systemer og egenskaper. To nettverk betyr ikke nødvendigvis at nettverket 5

Innledning er heterogent. For at et nettverk skal være heterogent må det bestå av to eller flere nettverk som samhandler eller kobles sammen. I det praktiske arbeidet i denne oppgaven brukes for eksempel både GSM og WLAN i demotjenesten som utvikles. 6

Kapittel 2 Kontekst generelt De fleste har en idé om hva kontekst er, men for å bruke kontekst er det nødvendig med en bedre og nøyaktig forståelse og definisjon. I dette kapitlet beskrives kontekst og betydningen av kontekst i denne oppgaven presenteres. 2.1 Hva er kontekst? For å bruke kontekst trengs en nøyaktig forståelse og definisjon av begrepet. På den måten kan utviklere lettere velge hva slags kontekst de skal bruke i applikasjonene, noe som vil gi innsikt i hva slags data som trengs, abstraksjoner og mekanismer som kreves for å utvikle kontekstsensitive applikasjoner. Teknologi er nødvendig for å samle informasjon fra ulike sensorer, og tilpasse tjenesten basert på disse dataene. Det har blitt gjort flere forsøk på å definere kontekst. Ulike definisjoner av kontekst har skapt behovet for én formell definisjon som er bred nok til å gjelde alle typer kontekst. Schilit og Theimer [26] er noen av de første som har skrevet om bruken av kontekst, og definerer kontekst slik; Context refers to location, identities of objects nearby and the changes to those objects. Myrhaug [27] har også skrevet om kontekst, og mener kontekst beskriver aspekter av en situasjon som noe har vært i, er i eller vil være i, der noe primært betyr brukere, softwarekomponenter, noder og linker. Dey og Abowd[28] har definert kontekst. Definisjonen blir ofte referert til i litteraturen, og har fått bred aksept i det faglige miljøet: Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant 7

Kontekst generelt to the interaction between a user and an application, including the user and applications themselves. Siden det er umulig å beregne hvilke aspekter av alle situasjoner som er viktig, fordi det vil forandre seg fra situasjon til situasjon, er definisjonen til Dey og Abowd brukt i denne rapporten. 2.2 Ulike typer kontekst Flere har delt kontekstinformasjon opp i ulike kategorier. Schilit [26] definerer kontekst til å være det kjørende miljøet som forandrer seg konstant, og inkluderer dette i miljøet: Tjenestemiljø; tilgjengelige prosesser, nettverkskapasitet osv Brukermiljø; lokasjon, mennesker i nærheten osv Fysisk miljø; lys, støy osv Myrhaug har jobbet med SINTEF sitt LAMA-prosjekt, der de har kategorisert kontekst i følgende klasser[29]: Brukerkontekst Softwarekomponent-kontekst Nodekontekst Linkkontekst Kategoriseringen begrunnes med at forskning på teknologi for utviklingen av kontekstsensitive tjenester krever involvering av eksperter innen flere teknologiske domener, som data- og telekom-ingeniører. Telekommunikasjonstjenester støtter kommunikasjonen mellom brukere. Dette inkluderer transport av informasjon og etablering av forbindelser mellom brukerne. Forfatterne av rapporten ser det derfor som hensiktsmessig å dele kontekst opp i kategorier som nevnt over. Famous-prosjektet[30] har delt kontekst opp i bruker- og nettverkskontekst. I denne oppgaven er det valgt å dele kontekst opp på samme måte, for å få med kontekstdefinisjon fra både data og telesiden. Det vil ikke bli gitt en detaljert definisjon av nettverkskontekst, fordi begrepet ikke fokuseres på i oppgaven. Det fokuseres på brukerkontekst som beskrives nærmere avsnitt 2.2.2. 2.2.1 Nettverkskontekst Nettverkskontekst er nettverksinformasjon, og inkluderer informasjon om node og link. Nettverkskontekst kan samles inn ved å analysere nettverket og informasjon som allerede er tilgjengelig i nettet. Aspekter ved denne type kontekst er båndbredde, forsinkelse, pakketap etc.[30] 8

2.3 Kontekstsensitivitet 2.2.2 Brukerkontekst Brukerkontekst er relatert til brukeren og brukerens omgivelser. Brukerkontekst er ofte samlet inn ved hjelp av sensorer eller brukeren selv. Eksempler på denne type kontekst er lokasjon, tilstedeværelse og egenskaper, men det kan også være brukerens tilstand, rolle, humør og nåværende oppgaver. Sintef [29] har delt brukerkontekst inn i fem grupper: Miljøkontekst; omfatter enheter rundt brukeren, for eksempel ting, tjenester, temperatur, lys, personer, nettverk etc. Personlig kontekst: Dette beskriver brukerens tilstand. Det kan være blodtrykk, vekt, humør, stress etc. Oppgavekontekst; beskriver hva brukeren gjør. Dette kan være mål, oppgaver, aktivitet etc. Sosialkontekst; inkluderer de sosiale aspektene ved brukerkontekst. Eksempler er rollen til brukeren, informasjon om venner, familie etc. Temporærkontekst: beskriver aspekter som er relatert til tid og rom. Det vil si atributter som tid, lokasjon, hastighet etc. I denne oppgaven fokuseres det på brukerkontekst, og det legges vekt på tre av parametrene, nemlig presence, lokasjon og tid. Dey[28] har definert disse som de primære kontekstparametrene. Parametrene beskrives nærmere i kapittel 4 og 5. 2.3 Kontekstsensitivitet Sammen med begrepet kontekst hører kontekstsensitivitet. Kontekstsensitive applikasjoner er applikasjoner som tilpasser seg miljøet. Slike applikasjoner har blitt beskrevet av flere, og nedenfor nevnes et par av definisjonene som er brukt om begrepet. Schilit [31] beskriver kontekstsensitive applikasjoner som:..application adaptation triggered by such things as the location of use, the collection of nearby people, the presence of accessible devices and other kinds of objects, as well as changes to all these things over time. Dey og Abowd[28] definerer kontekstsensitive systemer som følger : A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user s task. Dey og Abowd sin generelle definisjon er den mest fullstendige, og legges derfor vekt på i oppgaven. 9

Kontekst generelt 2.4 Hvorfor er kontekst vanskelig å bruke? Det har blitt utviklet ulike kontekstsensitive applikasjoner, men kompleksiteten i designet av disse applikasjonene gjør at de ofte er laget kun med dette formål, det vil si på en ad-hoc måte. Dette gjør at videreutvikling og gjenbruk av eksisterende komponenter er vanskelig. Kompleksiteten i designet av disse applikasjonene er grunnet manglende abstraksjon av utvikleren. Dey[28] har pekt på noen egenskaper ved kontekst som gjør at det er vanskelig å bruke: 1. Kontekst er samlet fra enheter som utvikleren har begrenset kunnskap om når en tjeneste designes. Disse komponentene er mer komplekse enn tradisjonelle enheter som mus og tastatur. 2. En applikasjon kan kreve abstraksjon av kontekst for at det skal gi mening. 3. Kontekst kan registreres fra flere heterogene kilder. 4. Kontekst er dynamisk. Det forandres hurtig og kan kreve sanntidsprosessering og oppdateringer. Som vist i figur 2.1, kan kontekstinformasjon abstraheres før det presenteres for applikasjonen. Det er ønskelig at teknologien som brukes til å samle og prosessere kontekstinformasjonen er helt usynlig for enhetene som bruker informasjonen. Det er nyttig for utvikleren å slippe å tenke på hvordan kontekstinformasjon samles og prosesseres, så lenge det leveres til applikasjonen i et forståelig format. Figur 2.1: Flere kilder gir samme informasjon til applikasjonen. De fleste applikasjoner er nært koblet med sensorer som brukes for å skaffe informasjon. Dette er en trend som har ført til tre generelle problemer[28]: 10

2.5 Brukerscenarioer mangel på variasjon av sensorer for en gitt konteksttype mangel på variasjon av konteksttyper vanskelig å utvikle applikasjoner Det er ikke ønskelig at applikasjonene er nært knyttet til underliggende teknologi, fordi forandring i teknologi da vil gjøre det nødvendig å designe applikasjonen på nytt. Ved å separere hvordan kontekstinformasjon samles og hvordan det brukes kan det bli enklere å designe kontekstsensitive tjenester og utvikleren slipper å tenke på hvordan tilegne seg nødvendig informasjon i et passende format eller abstraksjonsnivå. 2.5 Brukerscenarioer I dette avsnittet presenteres ulike brukerscenarioer for å illustrere hvordan kontekstparametrene lokasjon, presence og tid kan brukes for å gi tjenester til brukere. 2.5.1 Meldinger på PC eller mobilterminal Gunnar er på jobb og arbeider ved PCen. På PCen har han et program som gjør at han kan sende meldinger til sine venner og kolleger. Når han har vært borte fra PCen en viss tid, sendes disse meldingene til mobiltelefonen i stedet for til PCen. Når han så kommer tilbake til PCen sendes meldingene igjen til PCen. I slike tilfeller må det avgjøres om borte fra PCen betyr at brukeren er fysisk borte fra PCen eller at han ikke har rørt tastaturet en viss tid. Det er naturlig at betydningen borte er at han ikke har rørt PCen på en stund, fordi brukeren kan være opptatt med andre ting og derfor borte i psykisk forstand. 2.5.2 Melding avhengig av lokasjon Jorunn, 80 år, er dårlig til bens, og er derfor med i en hjemmehjelptjeneste. Hun bærer alltid på en enhet som registrerer om hun faller. Hvis hun faller sendes en SMS til nærmeste pleier som er på jobb i det aktuelle tidsrommet, og som er registrert til å være ledig. Her kan ulike nettverk brukes for å gi Jorunns lokasjon. Nøyaktighet er her viktig, og er et krav til posisjoneringssystemet. 2.5.3 Lokasjon avgjørende for terminal Per, 32 år, er mye på farten og har flere enheter som han benytter. Lokasjonen til Per avgjør hvilken terminal som brukes for innkommende samtaler. Hvis han er hjemme brukes 11

Kontekst generelt hjemmetelefonen, hvis han er på kontoret brukes jobbtelefonen, og hvis han er ute og reiser brukes mobiltelefonen. I brukerscenarioer som dette, hvor det er aktuelt at brukeren bytter brukerterminal, bør det sees på brukerens villighet til å bytte brukergrensesnitt. 2.5.4 Venner i nærheten Ola, 15 år, er i byen en lørdag. Han har lyst til å finne på noe, og vil vite hvilke venner som er i nærheten og som ikke er opptatt. På mobiltelefonen får han listet opp venner som er i nærheten, og som har status tilgjengelig. Personvern er her av vesentlig betydning. Det er viktig at brukere selv kan definere hvem som kan se lokasjon- og statusinformasjon. 12

Kapittel 3 Nettverk Dette kapitlet beskriver ulike typer nettverk, og er derfor bakgrunnstoff for deler av rapporten. Nettverkene omtales og arkitektur i hvert av nettene beskrives kort. 3.1 GSM og GPRS Global System for Mobile Communication (GSM) -systemet[3] ble utviklet med tale som hovedapplikasjon og har derfor strenge sanntidskrav. Nye tjenester har etter hvert blitt lagt til og i dag tilbyr systemet SMS, WAP, linjesvitsjet dataoverføring og posisjoneringstjenester. Disse tjenestene er basert på radioaksessgrensesnittet til GSM, som kun tillater en bruker per kanal. Dette begrenser brukerbåndbredden og antall parallelle brukere som akseserer nettverket. Standard datarate til en GSM-kanal er 22,8 kbps [32]. Forbindelsen blir taksert per minutt som en vanlig samtale. General Packet Radio Service (GPRS) [33] tilbyr pakkesvitsjet trådløs dataoverføring og er et viktig skritt i retningen av 3.generasjons nettverk. GPRS er integrert i GSM, og bruker mange av de eksisterende GSM-komponentene. Noen elementer er lagt til for å muliggjøre overføringen av datapakker. For å ta i bruk dette nettverket må mobilterminalen ha støtte for GPRS. 3.1.1 Arkitektur Figur 3.1 viser en oversikt over arkitekturen i GSM. De tre hoveddelene i GSM er: Mobile Station (MS): benyttes av brukeren. Består av Mobile Equipment (ME) og SIM-kort. Base Station Subsystem (BSS): kontrollerer radiolinken til mobilstasjonen. Hver BSS er kontrollert av en basestasjon-kontroller (BSC). 13

Nettverk Kjernenettverket: håndterer alle linjesvitsjede tjenester til og fra mobilstasjonen. Figur 3.1: GSM-arkitektur [2] Mobilstasjonen (MS) er det fysiske utstyret brukt av en bruker. Den består av Mobile Equipment (ME) og Subscriber Identity Module (SIM). ME består av Mobile Termination (MT) som, avhengig av applikasjonen og tjenestene, kan støtte ulike kombinasjoner av Terminal Adapter (TA) og Terminal Equipment (TE). SIM-kortet er ikke bundet til terminalen og kan derfor flyttes til andre terminaler. Basestasjon subsystem består av Base Station Transceiver og Base Station Controller og kontrollerer radiolinken til mobilstasjonen. Kjernenettet består av Mobile Switching Centre (MSC) og forskjellige registre som ivaretar det meste av funksjonaliteten i nettverket.[34] Figur 3.2 viser oversikt over arkitekturen i GPRS-nettverket, der Serving GPRS support node (SGSN) og Gateway GPRS support node (GGSN) er nye komponenter som håndterer den nye funksjonaliteten knyttet til datapakker. Resten av komponentene er fra GSMnettverket. Figur 3.2: GPRS-arkitektur, hentet fra Cisco.[3] 14

3.2 UMTS 3.2 UMTS Utviklingen av GSM og GPRS danner bakgrunnen for innføringen av Universal Mobile Telecommunication System (UMTS)[35] i Europa. UMTS er en av mange teknologier definert av International Telecommunication Union (ITU) for å muliggjøre tredjegenerasjons 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[36]. 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 andregenerasjons mobilsystemer, har UMTS forbedrede egenskaper ved at det støtter multimediatjenester, som lyd, video og datatjenester[3]. 3.2.1 Session Initiation Protocol I UMTS skal det blant annet brukes Session Initiation Protocol (SIP)[37] for call-setup og presence. SIP er en signaleringsprotokoll, og en oversikt over SIP-protokollen gis i dette avsnittet. SIP er et sett av standarder som definerer hvordan enheter (PCer, mobiltelefoner etc.) kan utveksle informasjon med hverandre. Det er et verktøy for å opprette, modifisere og avslutte sesjoner. SIP arbeider uavhengig av underliggende transportprotokoller og er uavhengig av type sesjon som etableres. Protokollen ble basert på elementer fra http. I likhet med http ble SIP designet for å frakte pakker over IP-nettverk, og kontrollen av applikasjonen ble flyttet til endepunktene. Den grunnleggende funksjonen er sesjonsinitiering, men den har også andre viktige funksjoner som kunngjøring av presenceinformasjon og korte meldinger (Instant Messaging[38]).[37][39] I SIP brukes en klient-server transaksjonsmodell. En klient generer en SIP-forespørsel, og serveren svarer med en respons. Partene blir enige om karakteristikker av sesjonen de skal sette opp mellom seg, der en sesjon er utveksling av data mellom deltagerne. En SIP-server og en klient har full kontroll over sesjon seg imellom. Dette er i kontrastt til modellen for tjenestekontroll i den tradisjonelle, linjesvitsjede telekom-verdenen, hvor endepunkter ikke har call-kontroll-egenskaper. Hovedelementene i et SIP-nettverk er brukeragenter, servere og lokasjonservere [40]: Brukeragentene er endepunktene i SIP-nettverket. De er opphavet til SIPforespørsler, blant annet for å etablere mediasesjoner. Servere er formidlere som er lokalisert i nettverket og skal assistere brukeragenter i etableringen av sesjonen og andre funksjoner. En lokasjonsserver er en database. Den inneholder informasjon om brukere, som URL, IP-adresser, script etc. Brukeragenter har vanligvis kontakt med lokasjonsserverne via proxyer. 15

Nettverk 3.2.2 Arkitektur Den første UMTS-utgivelsen kom i 1999 og inneholdt de grunnleggende egenskapene for å aksessere IP-nettverk og de linjesvitsjede nettverkene. UMTS-arkitekturen har utviklet seg gjennom utgivelsene, og blitt mer IP-fokusert når det gjelder transport og signallering. Den store påvirkningen av IP-baserte applikasjoner og betydningen av støtte for sanntid er dermed tatt i betraktning. De grunnleggende domenene i UMTS er som vist i figur 3.3. Et skille i arkitekturen er mellom user equipment (terminalene) og infrastrukturen. Dette gir to domener; User Equipment domain og Infrastructure domain. Figur 3.3: Grunnleggende domener i UMTS. [4] User equipment (UE) er utstyret som brukeren bruker for å få tilgang til UMTS-tjenester, og har et radiogrensesnitt til infrastrukturen. UE er videre delt opp i Mobile Equipment (ME) og User Service Identity Module (USIM). ME-domenet kan videre deles inn i flere komponenter som viser forbindelsen mellom ulike funksjonelle grupper. Disse gruppene kan implementeres i en eller flere hardware-enheter. Et eksempel på slike grupper er Mobile Termination (MT), som utfører radiooverføringen og relaterte funksjoner, og Terminal Equipment (TE), som inneholder ende-til-ende-applikasjonen. Figur 3.4 viser den funksjonelle modellen for UE.[4] UMTS-nettverket skiller mellom tjenester basert på linjesvitsjet og pakkesvitsjet bæreteknologi. Den pakkesvitsjede delen vil tilsvare GPRS, mens den linjesvitsjede delen vil være svært lik GSM. Nettverksmodellen i UMTS Release 5 er vist i figur 3.5. 16

3.2 UMTS Figur 3.4: Funksjonelle enheter i User Equipment. [4] Figur 3.5: Nettmodell i 3GPP. [5] 3GPP har bestemt at SIP skal brukes i IP-multimediadomenet. Call Session Control Functions (CSCF) er primært SIP-noden i nettverket. Det vil være forskjellige typer slike noder. P-CSCF er lokalisert i aksessnettet og har blant annet som oppgave å trigge lokale tjenester. S-CSCF er første punkt for kontakt for innkommende signalering i hjemmedomenet, og koordinerer tjenestene. I-CSCF er ofte plassert mellom domener og spør hjemmeregisteret for å finne den riktige S-CSCF. HSS er Home Subscriber Services, og erstatter HLR i GSM. Aapplication servers (AS) skal brukes for tilleggstjenester.[41][42] SIP-signaleringen mellom disse vises i figur 3.6. 17

Nettverk Figur 3.6: Signallering i UMTS.[5] 3.3 Bluetooth 3.3.1 Generelt Bluetooth [43] 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. 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, noe som er relativt kort. Men med en kraftigere sender kan rekkevidden utvides opp til 100 meter.[43] 3.3.2 Arkitektur Hovedfunksjonen til Bluetooth er å tilby et ad-hoc nettverk mellom enheter. Disse nettverkene er vanligvis midlertidige nettverk som forandrer seg når enheter kommer og går i det aktuelle området. Når Bluetooth-enheter er i en forbindelse er de enten master eller slave, der master er enheten som starter utvekslingen av data. Denne enheter har styringen og bestemmer hva som skal sendes og når det skal overføres. En master kan 18

3.4 WLAN støtte opp til syv enheter i sitt nettverk. Figuren 3.7 viser hvordan enheter kan være koblet sammen. Figur 3.7: Bluetooth-nettverk. [6] Enhetene i et nettverk bruker samme frekvens, men kan være i flere nettverk. Dette betyr at en slave i et nettverk kan være master i et annet.[6][43] 3.4 WLAN Trådløst LAN[44] er et trådløst nettverk og et alternativ til kablet lokalnett, derav navnet Wireless Local Area Network (WLAN). Forbindelsen i et WLAN er tilgjengelig i et begrenset område. Rekkevidden er avhengig av bruken og miljøet, og kan variere fra ca. 30 meter inne i en bygning til flere hundre meter utendørs ved direkte siktelinje. WLAN fungerer på samme måte som GSM og UMTS, der terminalen kommuniserer med et aksesspunkt for å få kontakt med et kablet nettverk. Aksesspunkt kan også kommunisere med hverandre, noe som gir mulighet for at ulike LAN kan knyttes sammen.[7][3] 3.4.1 Arkitektur I et WLAN får enheter vanligvis tilgang til andre nett ved hjelp av et aksesspunkt. Aksesspunktet koordinerer all kommunikasjon og er en bro til andre nett; trådløse eller faste. Figur 3.8 illustrerer arkitekturen i WLAN. 19

Nettverk Figur 3.8: WLAN-arkitektur[7] 3.5 Oppsummering Nettverksteknologiene som er presentert i kapitlet varierer med hensyn på blant annet dekningsområde og utbredelse. GSM og GPRS er nettverk med stor utbredelse i Norge. Standardisering av UMTS skjer med støtte fra Europa, Asia og Amerika, og regnes derfor med å få større utbredelse enn GSM har i dag. Bluetooth og WLAN er nettverk med kortere utstrekning. 20

Kapittel 4 Lokasjon som kontekstparameter I dag baserer mange tjenester seg på GPS- og GSM-lokasjon, men det fins andre måter å innhente posisjonsinformasjon på. Dette kapitlet beskriver noen av disse mulighetene. 4.1 Hva er lokasjon? Når en terminal er fastkoblet, er lokalisering forholdsvis enkelt, siden den er koblet til en fast plugg og lokalisering av pluggen er kjent. Lokalisering av trådløse terminaler er vanskeligere, fordi disse er i bevegelse og det er nødvendig å oppdage posisjonen til terminalen. Lokasjon kan ifølge Srivastava[45] være: Absolutt posisjon, for eksempel GPS-posisjon. Lokasjon relativ til faste sensorer. Lokasjon relativ til et startpunkt. Et område, der lokasjon kan være relativt til en definert kontekst, for eksempel kan Oslo være i betydningen kommunen eller bysentrum. Lokasjon i forhold til andre mennesker eller objekter. Lokasjon innen en bygning. Lokasjon kan gis av brukeren selv eller av nettverket. Posisjonering kan angis av brukerens enhet, for eksempel ved å observere signaler mottatt fra sendere. Det kan brukes fjernposisjonering, der posisjonen til den mobile noden beregnes på en fjerntliggende lokasjon, for eksempel ved å bruke signaler mottatt fra mobilen. Lokasjon kontrolleres av kilden til informasjonen. Lokasjonssystemer varierer med hensyn på dekningsgrad og nøyaktighet. Applikasjoner stiller ulike krav til graden av nøyaktighet på brukerens posisjonen, noe som gjør at det ofte er nødvendig at slik tilleggsinformasjon oppgis. 21

Lokasjon som kontekstparameter Som regel oppgis posisjon i form av koordinater. Dette gir liten informasjon til brukeren, og det kan derfor være ønskelig for applikasjonen å motta en abstraksjon av koordinatene. I noen tilfeller er lokasjon ønskelig i form av en posisjonen. Hvis for eksempel en bruker vil ha opplysninger om raskeste vei fra A til Å, er ikke korteste vei nødvendigvis best. Type vei og fartsgrense spiller en vesentlig rolle i slike tilfeller. Et annet eksempel er når en pakke skal leveres til et postkontor. I slike tilfeller er ikke posisjonen til brukerens hjem ønskelig, men derimot i hvilket område brukeren bor og dermed hvilket postkontor han hører til. Dette viser at posisjon i seg selv ikke alltid er nok, men abstraksjon og tilleggsinformasjon kan være nødvendig. 4.2 Standarder for beskrivelse av lokasjon Det er utviklet ulike systemer for å beskrive lokasjon; både verdensomspennende og nasjonale systemer, med to eller tre dimensjoner. I dette kapitlet gis en kort beskrivelse av to verdensomspennende systemer for beskrivelse av lokasjon. Presentasjonen er basert på [46]. 4.2.1 International Organization for Standardization (ISO) ISO[47] har utviklet en standard for representasjon av lokasjon basert på lengdegrad, breddegrad og høyde. Standarden beskriver hvordan disse parametrene kan representeres. Breddegrader representeres ved hjelp av grader, minutter og sekunder. Breddegrader nord for ekvator merkes med +, og breddegrader sør for ekvator med -. Lengdegrader representeres ved hjelp av grader, minutter og sekunder. Lengdegrader øst for Greenwich betegnes med -, og lengdegrader vest for Greenwich med +. Høyde over havnivå merkes med +, og under havnivå merkes -. 4.2.2 World Geographic Reference System (GEOREF) GEOREF[8] blir brukt for flynavigering og er basert på lengde-og breddegrad. Jorden deles inn i 24 lengdegradssoner og 12 breddegradssoner. Dette gir 288 firkanter som alle er 15x15 grader og spesifiseres med to bokstaver; lengdegradsrute og breddegradsrute. 4.3 Lokasjonssystemer Det eksisterer noen forskjellige terminalbaserte lokaliseringsmetoder. Den mest kjente og mest brukte er Global Positioning System (GPS)[8], som er utviklet av US Departement 22

4.3 Lokasjonssystemer of Defence. Dette systemet beskrives nærmere under. 4.3.1 Global Positioning System (GPS) GPS-systemet er stort og komplekst, og det gis kun et innblikk i hvordan teknologien fungerer. GPS består av 24 valgfrie satellitter og fire monitorstasjoner på ulike steder i verden. Master Control bruker disse stasjonene for å sende riktige beregninger for hver satellitt sin posisjon og klokke. Disse satellittene sender en del av dataene til GPS-mottakerne. Det er mulig å bestemme posisjonen i to dimensjoner ved hjelp av tre satellitter. Satellittene benytter en svært nøyaktig intern klokke. GPS mottagerne derimot har ikke en tilsvarende nøyaktig klokke, så den tredje satellitten benyttes for å korrigere klokkefeilen. For å beregne lokasjonen i fire dimensjoner (lengdegrad, breddegrad, høyde og tid) trenger GPS-mottakerne data fra fire satellitter.[8] Dette vises i figur 4.1. GPS kan ha gi en nøyaktighet på noen få meter, som er mer nøyaktig en noen annen lokasjonsmetode i stor skala. Figur 4.1: Et typisk GPS-system.[8] Vurdering av GPS GPS er spesielt designet med posisjonering som funksjon. Posisjonen kan representeres ved hjelp av lengdegrad, breddegrad og høyde, og er meget nøyaktig. En ulempe er at systemet krever fri sikt til satellittene for å fungere, noe som kan gi problemer innendørs og i tunneler. 23

Lokasjon som kontekstparameter 4.4 Innsamling av lokasjonsinformasjon fra ulike nettverk Som beskrevet kan kontekst, for eksempel lokasjonsinformasjon, komme fra ulike nettverk. I de neste avsnittene beskrives ulike nettverk og hvordan disse kan være kilde til lokasjonsinformasjon. 4.4.1 Lokasjon i GSM/GPRS GSM tilbyr nettverksbasert kontinuerlig lokasjon av terminaler som er på. Det eksisterer mange forskjellige muligheter for å posisjonere en mobilterminal i et system som GSM. Kravene til hvor mange basestasjoner som må dekke et spesielt område varierer, og det samme gjelder nøyaktigheten til de forskjellige metodene. Typiske nøyaktigheter for slike systemer er 60-1000 meter, men det har vist seg å være vanskelig å oppnå nøyaktigheter ned mot 60 meter i praksis. Mobiltelefonen i et GSM-nettverk kommuniserer med en basestasjon (BS). BS dekker et område kalt en celle. Basestasjonene er knyttet til basestasjon-kontrollere. Disse er igjen knyttet til Visiting Location Register (VLR) som har ansvar for et visst antall celler, og derfor et visst geografisk område. VLR har til en hver tid oversikt over hvilke terminaler som er i dette område. Home Location Register (HLR) inneholder informasjon om hvert enkelt abonnement. I dette registrert er det blant annet en peker til hvilken VLR terminalen befinner seg i, og derfor også hvor den er. Den mest grunnleggende lokaliseringsmetoden kalles Cell-ID, og går ut på at posisjonen til terminalen kan finnes ved at HLR vet hvilket VLR terminalen befinner seg i, og VLR vet hvilken celle den er i. Graden av nøyaktighet varierer med størrelsen på cellen. Posisjonen til terminalen er nemlig posisjonen til basestasjonen i den aktuelle cellen. Cell-ID-metoden kan forbedres ved å bruke Timing Advance (TA), der basestasjonen bruker tidsforskjell på mottak av pakker til å finne en mer nøyaktig avstand til mobilenheten. Feildistansen i Cell-ID + TA er rundt 550 meter. Ulempen med denne metoden er at nøyaktigheten er dårlig og varierer. Fordelen med metoden er at investeringene er lave, siden kostnad for tilleggsutstyr er lav. En vanlig lokaliseringsmetode i GSM er Enhanced Observed Time difference (E-OTD). I denne metoden beregner mobilenheten lokasjonen ut fra tidsdifferansen ved mottak av minst tre GSM-rammer sendt fra basestasjoner. Nøyaktigheten til denne metoden avhenger av oppløsningen av tidssynkroniseringen. Fordi tid er kritisk i denne metoden er ekstra hardware nødvendig, noe som gjør metoden mer kostbar. Nøyaktigheten er ikke nødvendigvis bedre sammenlignet med Cell ID + TA. En annen metode med bedre nøyaktighet er assisted-gps (A-GPS). Ideen med metoden er å etablere et referansenettverk koblet til GSM. Ved etterspørsel overføres data til mobilen- 24

4.4 Innsamling av lokasjonsinformasjon fra ulike nettverk heten for å øke nøyaktigheten og minske tiden det tar å finne lokasjonen til GPS-sensoren i enheten. Det er mulig å beregne lokasjonen både i mobilenheten og i nettverket. GSMlokalisering kombinert med GPS gir høyere nøyaktighet enn andre metoder. GPRS er, som beskrevet tidligere, et pakkebasert nettverk bygd på toppen av GSM, og bruker derfor de samme løsningene for lokalisering som GSM.[48], [49], [50] Vurdering av GSM/GPRS GSM-nettverket har stor utbredelse, og gir varierende posisjonsnøyaktighet. Ved bruk av Cell-ID er nøyaktigheten 60-1000 meter, men det har vist seg å være vanskelig å oppnå nøyaktigheter ned mot 60 meter i praksis. Lokasjonsinformasjonen i GSM oppgis i form av lengdegrad og breddegrad, og representerer koordinatene til basestasjonens posisjon. Ved bruk av andre metoder kan nøyaktigheten på lokasjonen forbedres. Nøyaktigheten til Cell-ID kan forbedres ved hjelp av Time Advance. E-OTD er en dyrere metode, og gir ikke nødvendigvis bedre nøyaktighet. A-GPS kombinerer GSM og GPS, og er metoden i GSM som gir best nøyaktighet. 4.4.2 Lokasjon i UMTS Lokaliseringsmetodene i UMTS likner på metodene som eksisterer i GSM. Koordinatene til basestasjonen vil representere brukerens lokasjon. Basestasjonene i UMTS har kortere rekkevidde enn basestasjonene i GSM, noe som gjør at cellene vil være mindre. UMTS støtter både Cell-ID og A-GPS. E-OTD kommer i en annen form i UMTS og kalles Observed Time Difference Of Arrival (OTDOA)[50]. Nettet vil gi et system for lokalisering av brukerne, som kan aksessere ved hjelp av Parlay APIer i OSA-arkitekturen.[51] Applikasjoner kan dermed benytte seg av lokasjonsinnhenting i UMTS, uten å ha kjennskap til det underliggende nettet. Dette vil gjøre det enklere å utvikle lokasjonsbaserte applikasjoner. Vurdering av UMTS Som nevnt ligner lokasjonsmetodene i UMTS på metodene brukt i GSM. UMTS er velegnet for posisjonsbestemmelse, og på mange måter bedre enn GSM siden cellene er mindre og det er lagt inn støtte for posisjonsbestemmelse i arkitekturen. Støtte for henting av lokasjonsinformasjon ved hjelp av Parlay/OSA vil gjøre det lettere å utvikle applikasjoner som benytter lokasjon. 4.4.3 Lokasjon i Bluetooth Det fins ikke noe standard for Bluetooth-lokalisering, men ulike implementasjoner eksisterer. Radionor arbeider med et system for lokalisering ved hjelp av Bluetooth, kalt 25

Lokasjon som kontekstparameter RadioEye[9]. Konseptet baserer seg på at man finner retningen på radiobølgene som sendes fra kilden. Dermed er det mulig å finne lengdegrad og breddegrad ved å bruke én sensor, som er montert på et kjent sted i nærheten av kilden. Dersom det brukes to sensorer, er det mulig å få høyde i tillegg. Nøyaktigheten varierer med plasseringen av utstyret, men Radionor kan oppnå nøyaktighet på bedre enn én meter.[52] Arkitektur er som vist i figur 4.2. Figur 4.2: Konfigurasjon av RadioEye.[9] Vurdering av Bluetooth Mangelen på standard for Bluetooth-lokalisering er en ulempe, samtidig som det er en fordel at hver enhet kan lokaliseres uten at spesiell hardware er nødvendig. Posisjonering med en nøyaktighet på under 1 meter er en fordel. 4.4.4 Lokasjon i WLAN Siden rekkevidden til WLAN er begrenset, kan tilnærmet lokasjon brukes, på liknende måte som i Cell-ID-metoden i GSM. Lokasjonen er da lokasjonen til aksesspunktet som terminalen er forbundet med. En annen måte er å bruke radiosignalene sendt fra terminalen for å beregne en mer presis posisjon. Den første metoden er enkel, men gir lav nøyaktighet. Den andre metoden gir bedre nøyaktighet.[49] Lokasjonsserveren[48] på Telenor Tyholt benytter Ekahau Positioning Engine[53] for å lokalisere en terminal i WLAN. Dette systemet baserer seg på signalstyrke og kan gi 26

4.5 Andre lokasjonssystemer nøyaktighet på inntil 1 meter. Koordinatsystemet som benyttes i posisjoneringen kalles Geodetic Latitude, Longitude, Altitude (breddegrad, lengdegrad, høyde over havet). Det brukes et globalt datum, kalt Worl Geodetic System 1984 (WGS-84), som referansepunkt. Radionor Communications har utviklet et WLAN-posisjoneringssystem, kalt RadioEye, som består av antenner montert i taket. De lytter etter trafikk i WLAN-området og gir posisjonen til MAC-adresser som ligger i dekningsområdet til antennen. Nøyaktigheten på posisjonen vil variere fra 0,5-5 meter, og er avhengig av avstanden til antennen.[48] Vurdering av WLAN WLAN er fleksibelt siden hvem som helst kan kjøpe terminaler og aksesspunkt, og dermed konstruere sine egne trådløse nettverk. WLAN dekker relativt små områder, og gir av den grunn god nøyaktighet. Ekahau Positioning Engine og RadioEye er eksempler på teknologi som kan anvendes i et WLAN-området. Ekahau kan gi en posisjonsnøyaktighet på 1 meter, og RadioEye kan gi nøyaktighet på inntil 0,5 meter. For å få en fordelaktig posisjonering i stor skale, må områdene som dekkes av WLAN knyttes sammen, og teknologi for posisjonering må implementeres i hvert nett. Koordinering av slik teknologi kan bli vanskelig, fordi det krever samarbeid mellom de ulike aktørene som administrer slike nettverk. 4.5 Andre lokasjonssystemer Infrarød teknologi (IR) brukes ofte mellom enheter, og er vanlig i for eksempel butikker og fjernsynskontrollere. Slik teknologi kan brukes til lokalisering. Andre teknologier som blant annet Radio Frequency Identification (RFID) og optisk laser kan brukes til samme formål. 4.6 Oppsummering og oversikt Som beskrevet i dette kapitlet er det mulig å hente lokasjonen til en bruker fra forskjellige lokasjonssystemer og nettverk. De ulike teknologiene varierer med hensyn på blant annet dekningsområde og nøyaktigheten av posisjonen. En oversikt over presisjonen vises i tabell 4.1. Lokasjonen som oppgis er ikke nødvendigvis posisjonen til brukeren, men brukerens terminal 1, da disse kan befinne seg på forskjellige steder. Posisjonen som oppgis er derfor ikke bevis på at brukeren oppholder seg på oppgitt sted. 1 Mer nøyaktig er det posisjonen til basestasjonen som dekker området der terminalen befinner seg, som oppgis. 27

Lokasjon som kontekstparameter Tabell 4.1: Oversikt over nøyaktighet av lokasjon. Nettverk/system Format Nøyaktighet Rekkevidde GPS Lengdegrad, breddegrad, Nøyaktighet på noen meter God høyde GSM Lengdegrad, breddegrad Rimelig unøyaktig God (avhengig av cellestørrelse - typisk 60-1000 m) UMTS Lengdegrad, breddegrad Rimelig unøyaktig, men Forventes å bedre enn GSM (avhengig være god av cellestørrelse) WLAN (Ekahau) Lengdegrad, breddegrad, høyde Nøyaktig (inntil 1 m) Begrensede områder Bluetooth (Radionor) Lengdegrad, breddegrad, høyde Nøyaktig (under 1 meter er mulig) Liten 28

Kapittel 5 Presence og tid som kontekstparametre Dette kapitlet tar for seg tid og presence som kontekstparameter. 5.1 Tid Grimen et. al. [46] omtaler tid som et observert fenomen, i betydningen av at mennesker observerer og registrerer forandringen i miljøet. Tid er et viktig element i mange mobile tjenester. Ved bruk av tid som kontekstparameter kan en tjeneste tilpasses dato og tid. Det kan brukes sammen med andre kontekstparametere for å tilpasse tjenesten bedre til hver enkelt bruker. Tid kan settes på ulike måter, for eksempel ved hjelp av brukeren, terminalens klokke, nettverket eller tidssynkroniserte sensorer. Måten parameteren settes på er avhengig av applikasjonen, terminalen og andre aspekter i designet.[51] 5.1.1 Modeller for tid Det er viktig å ha en modell for tid for å kunne snakke om tid. Den Newtonske modellen er vanlig innen databehandling [54]. Ut fra denne modellen er det tre forkskjellig måter å se tid på: Lineær Forgrenet Syklisk 29

Presence og tid som kontekstparametre Vanligvis tenker vi på tiden som lineær, det vil si at tiden går framover med konstant hastighet. I den forgrenede tidsmodellen er tiden lineær fram til nåtiden, deretter forgrener den seg i mulige framtider. Den sykliske modellen er tid som gjentar seg, for eksempel månedene i et år eller dagene i en uke. Det er vanligvis snakk om kontinuerlig eller diskret tid. Diskret tid kan sammenlignes med tallene på en tallinje, mens kontinuerlige tall kan sammenlignes med de reelle tallene. For å bruke tid som kontekstvariabel er det nyttig å relatere det til annen informasjon, foreksempel lokasjon eller presence-informasjon. 5.2 Presence som konteksttype Presence betyr ofte å formidle og å ta imot kommunikasjon, og er nødvendig for å formidle hva vi gjør, kroppsspråk, følelser etc. Oxford Concise Dictionary definerer presence til å være the state or condition of being present. American Heritage Dictionary definerer presence til immediate proximate in time or space. IETF[55] har skrevet følgende om presence: Presence is defined as the willingness and ability of a user to communicate with other users on the network. Presence formidles på ulike måter og hjelper oss blant annet med følgende: Samarbeid: Informasjon om andre gjør at vi kan koordinere aktivitetene våre etter hva andre gjør. Improvisert kommunikasjon: Tilstedeværelse gjør det enkelt med lett og improvisert kommunikasjon. Etablere sosiale relasjoner og andre sosiale aktiviteter: Presence gir oss sosiale relasjoner. Presence er nært knyttet til det engelske ordet awareness, som på norsk kan oversettes til bevissthet og forståelse. Begrepene presence og awareness dekker mye av det samme, og i denne rapporten brukes presence som betegnelse for begge begrepene. Presence er et utstrakt begrep i telekommunikasjonslitteraturen, og det velges derfor å ikke oversette ordet til norsk. Presence-konseptet har blitt brukt i flere applikasjonsområder, men har vært mest vanlig i forbindelse med Instant Messaging. Da konseptet først ble tatt i bruk, ga det kun informasjon om en bruker var pålogget eller ikke. Senere har begrepet presence blitt utvidet til å inkludere informasjon angående statusen til brukeren, slik som tilgjengelighet (for eksempel ute til lunsj, borte fra pc ) og brukerens aktivitet ( i telefonen, etc). Lokasjonsinformasjon har stort sett blitt holdt separat fra det som er blitt kalt presence-informasjon, og behandles som en egen kontekstparameter, noe som også gjøres i denne oppgaven. 30

5.2 Presence som konteksttype Dette er kun et lite utvalg av det vi bruker presence til. Teknologisk støtte for presence har ofte vært fokusert rundt disse scenarioene. Ved bruk av presence-informasjon bør følgende tas i betraktning: Informasjon bør gjøres tilgjengelig i standardisert format. Informasjon bør være tilgjengelig gjennom veldefinerte grensesnitt. Brukerinformasjon skal karakterisere en spesiell type enhet. Attributter må defineres. Format og verdier til attributter bør standardiseres. Presence er et attributt som er relatert til, men forskjellig fra mobilitetsinformasjon. Det kan brukes for å skape nye tilleggstjenester, som for eksempel kommunikasjonstjenester, mer avanserte eksisterende tjenester eller informasjonstjenester. Nedenfor beskrives SIP og Jabber. Dette er teknologier som anvendes for å benytte presence i applikasjoner. Det er valgt å fokusere på SIP. 5.2.1 Teknologier for bruk av presence For å anvende presence i applikasjoner er det nødvendig med teknologier som støtter utveksling av presence-informasjon mellom applikasjoner. I dette avsnittet studeres slike teknologier som støtter dette. 5.2.1.1 SIP for Instant Messaging and Presence Leveraging Extentions (SIM- PLE) Den åpne designen til SIP har gjort at protokollen har blitt en ledene metode for standardisering av Instant Messaging og presence blant ulike tjenestetilbydere. I likhet med SIP, er SIP SIMPLE[56] en IETF-standard. RFC 2778[10] definerer en konseptmodell og terminologi for å beskrive systemer som tilbyr presence-informasjon, se figur 5.1. I modellen er en presence-tjeneste et system som tar imot, lagrer og distribuerer presence-informasjon. Presence-tjenesten har to forskjellige type klienter. Disse behandles separat i modellen, men kan være kombinert i en implementasjon. Det ene settet av klienter kalles presentities, og gir presence-informasjon som skal lagres og distribueres av serveren. Det andre settet av klienter kalles watchers. Disse mottar presence-informasjon om aktuelle presentities fra serveren. En watcher kan etterspørre eller abonnere på presence-informasjon. Meldingsutvekslingen mellom enhetene demonstreres i figur 5.2. Først må enhetene registrere seg hos serveren som har tjenesten. For å abonnere på informasjon sender en watcher en subscribe-melding til serveren. Denne rutes gjennom proxier som andre SIPetterspørsler. Tjenesten sender deretter presence-status i en notify-melding tilbake til 31

Presence og tid som kontekstparametre Figur 5.1: Konseptmodell i SIP.[10] watcher. [40] På denne måten kan brukere abonnere på presence-informasjonen til andre brukere. Figur 5.2: Register-, subscribe-og notify-meldinger i SIP.[11] 5.2.1.2 SIP for presence i 3GPP 3GPP har valgt SIP som standard for presence-baserte tjenester i 3G-nettverk. Presence-status til en bruker i 3GPP har attributtene; tilgjengelig, tilgjengelig med begrensninger, ikke tilgjengelig og ikke vises. Brukeren definerer et sett av aksessregler for å kontrollere andre brukeres tilgangen til sin presence-informasjon. På denne måten kan noen brukere ikke se eller kun se deler av brukerens status. Ulike kilder gir presence-informasjon. Disse kildene er eksterne agenter (informasjon gitt av elementer utenfor nettverket), informasjon gitt av brukeren og informasjon gitt av nettverket selv. 3GPP har definert krav som presence-tjenesten skal støtte. Noen av disse kravene er som følger[57]: 32

5.2 Presence som konteksttype Presence-tjenesten skal tilby mulighet for hjemmemiljøet å håndtere presenceinformasjonen for brukernes enheter, tjenester og tjenester-medier, selv under roaming 1. Tjenesten skal gi abonnentene mulighet for å håndtere sin egen presence-informasjon eller presence-informasjonen til sine enheter, tjenester eller tjeneste-medier, selv under roaming. Presence-informasjon skal gjøres tilgjengelig i et standardisert format. Dette er for å gjøre det mulig å operere mellom 3GPP-nettverk. Presence-informasjon for abonnenter skal være mulig å utvide for å representere tilleggsinformasjon, uten å svekke det standardiserte formatet. Presence-informasjon skal inkludere hjelpemidler for å unikt identifisere brukeren. Abonnenten skal kunne definere aksessregler for tilgjengeligheten av sin presenceinformasjon. Det skal være mulig å etterspørre verdien av dataene som inneholder presenceinformasjon på ethvert tidspunkt eller periodisk (unntatt når dette ikke er mulig på grunn av aksessregler). Det skal være mulig å konfigurere tjenesten for å nekte en abonnent å abonnere, samtidig som det skal se ut som abonneringen er godtatt (kalles høflig blokkering). Figur 5.3: Meldingsflyt for presence-informasjon i UMTS.[12] Figur 5.3 viser meldingsflyten i et UMTS-nettverk. Bruker A etterspør presenceinformasjon til bruker B, der bruker B befinner seg i et annet nettverk. Meldingen rutes via proxyer i de to nettverkene. Presence-serveren (PS-B) til bruker B har oversikt over 1 Roaming inntreffer når samtalen til en abonnent rutes gjennom en annen operatør sitt nett. 33

Presence og tid som kontekstparametre hvem som har tillatelse til å se B sin presence-status. Den sender betalingsinformasjon til A sitt nettverk før den sender B sin status tilbake til applikasjonen nettverket til A. 5.2.1.3 Jabber og XMPP Jabber[58] er et sett av åpne XML-protokoller og teknologier som gjør det mulig for to enheter å utveksle meldinger, presence og annen strukturert informasjon i nærmest sanntid. Jabber har et stort utviklingsmiljø, mange brukere, diskusjonsforum for utviklere, gode utviklingsmanualer og det finnes en rekke klienter basert på Jabber som kan hentes fra Internett. Jabber er selskapet bak XMPP, og mener at en XML-basert protokoll er bedre egnet til å håndtere Instant Messaging (IM) og presence enn hva en signalteknologi som SIP er i stand til. Ifølge Jabber er en stor fordel med XMPP at den kan utvides over heterogene applikasjoner og plattformer, fordi den er basert på XML. En annen styrke det legges vekt på, er at alle beskjeder går via en tjener i protokollen. Dette gjør tjenere i stand til å logge og dermed kjøre revisjonslogger.[58] 5.2.1.4 Sammenligning og oppsummering av SIP og XMPP Både SIP SIMPLE og XMPP kan brukes for utveksling av presence-informasjon. For XMPP er presence en del av det å sende XML-meldinger mellom applikasjoner. For SIP SIMPLE blir IM og presence en ny form for kommunikasjon mellom klienter. Både SIP og Jabber skryter av utvidbarhet. Jabber poengterer at en styrke er nettbasert tjener, men dette er noe som også kommer med SIP i 3GPP. SIP SIMPLE vil i tillegg til leveranse av IM og presence, også kunne levere VoIP, konferanse, voicemail, call controll og så videre. Dette er trolig grunnen til at mange aktører støtter seg til denne protokollen. De får dermed alt i ett og samme produkt. Moore skriver i [59] at vinneren av de to protokollene mest sannsynlig ikke vil bli avgjort av tekniske meritter, men av påvirkningskraft i markedet. XMPP støttes av blant annet HP, France Telecom og Intel, mens SIP SIMPLE støttes av Microsoft, IBM og Novell. 3GPP har tatt i bruk SIP for signalering og presence.[60] 5.3 Oppsummering I dette kapitlet er kontekstparametrene tid og presence beskrevet. Tid er et viktig element i mange mobile tjenester, og kan blant annet brukes sammen med andre kontekstparametere for å tilpasse tjenesten bedre til hver enkelt bruker. Det er sett på hvordan presence hjelper oss å formidle kroppsspråk, følelser etc. Teknologier for å utveksle presence-informasjon er presentert. 34

Kapittel 6 Arkitektur og lagring av kontekstinformasjon Dette kapitlet beskriver forskning som er gjort rundt arkitektur og rammeverk med hensyn på innsamling, lagring og bearbeiding av kontekstinformasjon til bruk i applikasjoner. Informasjon kan samles inn fra sensorer eller ved hjelp av brukeren selv, konsumeres av applikasjoner umiddelbart eller lagres for senere bruk. Forslag til et rammeverk der lokasjon, presence og tid tas i betraktning presenteres. Deretter diskuteres avveininger og avgjørelser rundt et slikt rammeverk. 6.1 Viktig ved utforming av arkitektur Flere applikasjoner kan trenge å dele samme sensor, noe som gjør at sensorer blir en knapp ressurs. Rå sensordata kan underlegges komplisert signalprosessering for at det skal være i forståelig format for applikasjoner. Dette bidrar til at kontekstsensitive applikasjoner er vanskelig og kostbare å utvikle. [61] 6.1.1 Tett eller løs kobling mellom applikasjon og sensor Forvaltning av kontekst kan gjøres ut fra to prinsipper. Den ene er å skille forvaltning av kontekst fra applikasjonene som skal bruke konteksten. En tett kobling vil gjøre applikasjonen tett knyttet til underliggende teknologi. En slik løsningen vil gjøre at all kontekst som en applikasjon trenger er en integrert del av applikasjonen selv, og utvikleren må ta hensyn til detaljer ved sensoren. Dette gjøre det vanskelig for flere applikasjoner å kunne dele sensor og å videreutvikle applikasjonen for 35

Arkitektur og lagring av kontekstinformasjon å ta i bruk nye og flere sensorer. En tett kobling bidrar derfor til at kontekstsensitive applikasjoner er vanskelige og kostbare å utvikle. Mangelen på rammeverk gjør at en tett kobling er en vanlig løsning i dag. Å skille mellom applikasjon og sensorer er viktig for å forenkle utvikling av applikasjoner som bruker kontekst. Logikk for bearbeidelse av kontekstinformasjon mellom sensor og applikasjon er derfor nødvendig. Det er ofte ønskelig at teknologien som brukes for å samle inn og prosessere kontekstinformasjonen er helt usynlig for enheter som bruker informasjonen. Ved å separere hvordan kontekstinformasjon samles og hvordan det brukes, kan det bli enklere å designe kontekstsensitive tjenester. Det vil gjøre at konteksten ivaretas i et frittstående system. En slik separasjon gjør at utvikleren slipper å tenke på hvordan kontekstinformasjon samles og prosesserer, så lenge det leveres til applikasjonen i et egnet format. Oppgradering eller innføring av nye sensorer kan gjøres transparent for applikasjonen, og data fra flere sensorer kan settes sammen for å møte behovet til applikasjonen.[62][61] 6.1.2 Rammeverk for håndtering av kontekst Dey [62] har utarbeidet et rammeverk for utvikling av kontekstsensitive applikasjoner. Et sentralt mål med rammeverket er å skjule detaljer ved innsamling, tolkning, lagring og sammenstilling av kontekst for applikasjonene som bruker kontekst. Noen av de sentrale egenskapene ved rammeverket er: Spesifikasjon av kontekst; applikasjonsutvikleren skal kunne spesifisere den konteksten som applikasjonen trenger, som enkeltelementer eller sammenstilt kontekst. Skille forvaltning av kontekst; forvalte kontekst i et autonomt system og la applikasjoner spørre etter ønsket kontekst. Tolkning av kontekst; abstraksjon av sensoriske rådata, for eksempel gjøre en GPSposisjon om til en gateadresse. Transparent distribuert kommunikasjon; både de ulike komponentene som samlet sett forvalter kontekst og applikasjoner som bruker kontekst kan fysisk kjøre på ulike maskiner og kommunikasjonen mellom disse er skjult for applikasjonen. Lagring av kontekstdata; ta vare på kontekst som ikke skal brukes av applikasjoner umiddelbart. Mobicon-prosjektet til Telenor[13] har foreslått et rammeverk for håndtering av kontekst. Rammeverket skiller forvaltning av kontekst fra applikasjonen, og er illustrert i figur 6.1. Arkitekturen består av ulike lag for bearbeidelse av innsamlet informasjon. 36

6.1 Viktig ved utforming av arkitektur Figur 6.1: De ulike lagene som kan inngå i forvaltning av kontekst[13]. Figur 6.2: Arkitektur for håndtering av kontekstinformasjon i mobile nettverk[14]. Mendes et.al.[14] har foreslått en arkitektur, som vist i figur 6.2, for håndtering av informasjon i mobile nettverk. Arkitekturen består av enheter som behandler kontekstinformasjon: Context Collection Point (CCP) tar seg av generell konteksthåndtering, Context 37