Een beslissingsmodel van een Context-Aware mobiele telefoon volgens scenario-fit

Een beslissingsmodel van een Context-Aware mobiele telefoon volgens scenario-fit Justin Roodenburg [email protected] ABSTRACT

In deze paper staat beschreven hoe een ontwikkelingsmodel van een context-aware telefoon tot stand komt, die rekening houdt met de kans dat één context-sensor verkeerde informatie over de omgeving doorgeeft. Dit model besluit in welke toestand de telefoon moet komen aan de hand van een scenario-fit. Het model is opgebouwd uit drie lagen. De eerste laag is de interpretatie van de wereld door de sensoren. In de tweede laag wordt deze input gekoppeld aan een voorgedefinieerd scenario (activiteiten). En in de laatste laag worden deze activiteiten gekoppeld aan een telefoontoestand. Hierdoor is het model makkelijk aan te passen.

Keywords

Context-awareness, Mobile phone, scenario-fit.

1. INTRODUCTIE

Tegenwoordig gebruikt bijna iedereen wel een mobiele telefoon. Deze telefoons gaan op de meest ongepaste momenten af, tot grote ergernis van de omgeving. De mobiele telefoon gebruiker moet de hele dag nadenken of het geluid van de telefoon wel hard of zacht genoeg staat. Met de huidige technische ontwikkelingen hoeft dat niet meer nodig te zijn. Er zijn al onderzoeken gedaan naar een context-aware mobiele telefoon [SSF+03], [GSB02]. Waneer een apparaat contextaware is, houdt het rekening met informatie uit de omgeving en kan het zo een uitgebreidere service aan de gebruiker leveren [DA99]. Siewiorek et al. [SSF+03] beschrijven in hun artikel het gebruik van contextinformatie. De mobiele telefoon bepaalt zelf welke toestand (bijv. geruisloos, extra luid, trillen) het moet aannemen. Ook in het Technology Enabling Awareness (TEA) project heeft men onderzocht in hoeverre het bezitten van contextinformatie het gedrag van de telefoon kan beïnvloeden [GSB02]. In het TEA onderzoek [GSB02] gebruikt men de contextinformatie zonder naar de kwaliteit van de informatie te kijken. Siewiorek et al. [SSF+03] modelleren in hun artikel het gedrag van een context-aware mobiele telefoon. Ook zij houden er in hun stroomschema geen rekening mee dat de informatie die uit de context verzameld wordt incorrect kan zijn. Bij het bepalen van de telefoontoestand is volgens Siewiorek et al. [SSF+03] het belangrijkste gegeven de vraag: ‘Afspraak in agenda? J/N’. Maar zij vragen zich niet af wat er gebeurt als de afspraak van de gebruiker geannuleerd is en dit vergeten is in te voeren, of wat er gebeurt als de vergadering uitloopt. Het is niet vanzelfsprekend dat een mobiele telefoon die context-aware is, Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission. 6th Twente Student Conference on IT, Enschede, 2nd February, 2007 Copyright 2007, University of Twente, Faculty of Electrical Engineering, Mathematics and Computer Science

maar geen rekening houdt met de Quality of Context (QoC), een betere service levert dan een mobiele telefoon die niet contextaware is. QoC geeft aan in hoeverre bepaalde informatie over de context betrouwbaar is [BKS03]. Een lage QoC betekent dat de contextinformatie niet betrouwbaar is. Siewiorek et al. [SSF+03] beschrijven in hun artikel twee bronnen voor contextinformatie. Ten eerste noemen ze de informatie die door de gebruiker is ingevoerd. Dit kan een agendafunctie betreffen, zoals hierboven beschreven. Deze informatie kan achterhaald zijn en het toestel kan verkeerde conclusies trekken. Daarnaast richten zij in het artikel op contextinformatie die van sensoren komt, zoals licht, beweging en geluid. Met de lichtsensor bepaalt de telefoon waar het zich bevindt; op tafel, in de hand of in de broekzak. Maar kan een lichtsensor het verschil tussen een broekzak en een tas onderscheiden? Locaties met dezelfde lichtsterkte kunnen verschillende toestanden eisen. Omdat bestaande literatuur over context-aware mobiele telefonen geen rekening houden met de mogelijkheid dat de binnenkomende contextinformatie fout kan zijn, richt ik mijn onderzoek op de invloed van het omgaan met al dan niet foutieve contextinformatie bij het beslissingmodel van contextaware mobiele telefonen. In dit onderzoek staan de volgende twee vragen centraal: “Wat is de invloed van het binnen krijgen van al dan niet foutieve contextinformatie bij een context-aware mobiele telefoon?” En “Hoe kan een beslissingmodel van een context-aware mobiele telefoon er uit zien, die rekening houdt met het feit dat contextinformatie niet per definitie correct is?” In Hoofdstuk 2 wordt eerst het model van Siewiorek et al. [SSF+03] beschreven en vervolgens wordt er geanalyseerd hoe dit model omgaat met één sensorfout. Daarna zal er in Hoofdstuk 3 beschreven worden welke informatie nodig is voor het ontwerpen van een nieuw beslissingmodel voor een contextaware mobiele telefoon. Dit is onder andere gedaan aan de hand van een kwalitatief gebruikersonderzoek, waarbij onder andere informatie over de dagelijkse activiteiten en bijbehorende telefoontoestand centraal stonden. In Hoofdstuk 3.3 wordt beschreven welke karakteristieken bij de te onderscheiden activiteiten horen aan de hand van vier sensoren. In Hoofdstuk 4 wordt het ontworpen model gepresenteerd en toegelicht, waarna deze in Hoofdstuk 5 geanalyseerd wordt. In Hoofdstuk 6 wordt het voordeel van het model volgens scenario-fit uitgelegd. Tenslotte wordt in de conclusie de kern van deze paper weergeven en wordt de hoofdvraag kort teruggekoppeld. Tevens wordt er in dit hoofdstuk een paar suggesties gedaan voor toekomstig onderzoek.

2. MODEL VAN SIEWIOREK ET AL.

Siewiorek et al. [SSF+03] beschrijven in hun artikel hoe een context-aware mobiele telefoon besluiten neemt over de toestand waarin de telefoon moet komen te staan. In dit hoofdstuk wordt dit beslissingsmodel onderzocht. Eerst wordt er in paragraaf 2.1 beschreven hoe dit model werkt. Vervolgens zal er in paragraaf 2.2 een analyse worden uitgevoerd over hoe

dit model omgaat met sensorfouten. Tot slot wordt er in paragraaf 2.3 een conclusie getrokken.

2.1 Beschrijving beslissingsmodel van Siewiorek et al.

In het model van Siewiorek et al. [SSF+03] worden de beslissingen over in welke toestand de context-aware mobiele telefoon komt genomen aan de hand van een stroomschema. Dit stroomschema is te zien in Figuur 1 en bestaat uit zes vragen, die elk met Ja of Nee beantwoord kunnen worden. De vragen die gebruikt worden zijn: •

Agenda laat afspraak zien?

•

Gebruiker spreekt?

•

Hoge fysieke inspanning?

•

Hoog omgevingsgeluid?

•

Lage fysieke inspanning?

•

Laag omgevingsgeluid?

Om antwoord te krijgen op deze zes vragen wordt er gebruik gemaakt van een agendafunctie en drie sensoren. De telefoon verzamelt eerst informatie van deze sensoren en de agenda, om daar vervolgens (via het stroomschema) conclusies aan te verbinden. De volgende informatieproducten zijn voor de telefoon beschikbaar: 1.

Er wordt gecontroleerd of er wel of niet een afspraak in de agenda van de gebruiker staat.

2.

Een spraakmicrofoon die aangeeft of de gebruiker wel of niet aan het spreken is.

3.

Een beweging-sensor die drie waarden kan doorgeven: Lage activiteit, Gemiddelde activiteit en Hoge activiteit.

4.

Een omgevingsgeluid microfoon die drie statussen heeft: Laag, Gemiddeld en Hoog.

Om deze paper leesbaarder te maken zal er gesproken worden over een ‘agenda-sensor’ die kan doorgeven of de gebruiker wel of niet een afspraak heeft.

De telefoon die Siewiorek et al gebruiken, onderscheidt vier telefoontoestanden. Busy, Active, Idle en Normal. De Busy-state is bedoeld voor wanneer de gebruiker druk is. In deze state wordt een oproep in principe geblokkeerd. Als een dergelijk oproep geblokkeerd wordt, krijgt de beller een SMS met de mededeling dat als het een belangrijk gesprek is de beller binnen 3 minuten terug kan bellen. Als dat gebeurt wordt deze oproep niet geblokkeerd. De Active-state is bedoeld voor wanneer de gebruiker actief is en moeite zal hebben om een binnenkomend gesprek op te merken. De telefoon heeft in deze state het belvolume op maximaal en de trilfunctie aan. In de Idle-state gaat de telefoon er vanuit dat de gebruiker niet druk is en doet de telefoon suggesties voor het maken van telefoongesprekken. (Bijvoorbeeld dat iemand een paar keer heeft geprobeerd te bellen, dus dat het misschien verstandig is die persoon terug te bellen.) De Normal-state is de standaard state, waarin de telefoon op normaal geluid staat, en geen suggesties plaatst.

2.2 Analyse van het beslissingsmodel van Siewiorek et al.

Zoals in de vorige paragraaf beschreven is, zijn er 4 sensoren die informatie geven over de context. Deze sensoren kunnen 2 of 3 standen aan nemen. Omdat elk van deze 4 sensoren afzonderlijk van elkaar kunnen variëren zijn er 2*2*3*3=36 mogelijke inputs voor de mobiele telefoon. Van deze 36 mogelijke inputs leidt er één naar de Idle-state, vijf naar de Active-state, drie naar de Normal-state en 27 naar de Busy-state. Deze aantallen zijn te zien in de bovenste regel van Tabel 2. Als de telefoon suggesties maakt, zoals in de Idle-state, kan dat in bepaalde situaties vervelend zijn. Er is één mogelijkheid om in deze state te komen, maar als één van de sensoren verkeerde informatie doorgeeft, wordt die kans op de Idle-state vergroot. Stel: De gebruiker zit wel in een vergadering, hij is niet aan het spreken, hij heeft geen hoge fysieke inspanning, het omgeving geluid is niet hoog, hij heeft wel een lage fysieke inspanning, en wel een laag omgevingsgeluid. De telefoon hoort dan in de Busy-state te gaan; de gebruiker zit immers in een vergadering. Maar wat nu als de gebruiker dat niet goed in zijn telefoon heeft gezet? (de telefoon denkt dat hij niet in vergadering zit, hij is niet aan het spreken, hij heeft geen hoge fysieke inspanning, het omgeving geluid is niet hoog, hij heeft wel een lage fysieke inspanning, en wel een laag omgevingsgeluid.). Als alleen de informatie van de agenda anders doorgegeven wordt, komt de telefoon in de Idle-state, waarin de telefoon suggesties doet wat storend is in een vergadering. Dit geldt ook als de gebruiker aan het spreken is, terwijl de telefoon dat niet herkent als spreken. Elk van de vier sensoren kan een verkeerde waarde doorgeven. De beweging-sensor heeft 2 alternatieven; de spraakmicrofoon heeft 1 alternatief; de omgevings-geluid microfoon heeft 2 alternatieven en de agenda kan op 1 manier andere informatie doorgeven dan de werkelijkheid. Dat betekent dat er per voorgedefinieerde input (2+1+2+1=) 6 alternatieven zijn waarin de telefoon met één sensorfout denkt in dit voorgedefinieerde scenario te zitten.

Figuur 1: Beslissingsmodel van Siewiorek et al.

Een input kan gecodeerd worden als een 4 cijferig getal. Het eerste cijfer uit dit getal geeft informatie over de agenda-sensor. Het tweede cijfer geeft informatie over de spraak-sensor. Het derde cijfer over de beweging-sensor en het laatste cijfer geeft

informatie over de geluid-sensor. De agenda-sensor en de spraak-sensor kunnen twee waarden doorgeven; 1 komt overeen met wel en 0 komt overeen met niet. De beweging-sensor en geluid-sensor kunnen de waarden 1=laag, 2=gemiddeld en 3=hoog doorgeven. Een code van [0011] betekend dus dat er geen afspraak in de agenda staat, de gebruiker niet spreekt, er een lage beweging wordt waargenomen, en er een laag omgevingsgeluid is. Als iets laag is, is het niet hoog; als iets hoog is, is het niet laag; en als iets gemiddeld is, is het zowel niet hoog, als niet laag. Daarom is het mogelijk om met vier gegevens het stroomschema van Siewiorek et al. [SSF+03] door te lopen. De code [0011] zal leiden tot de Idle-state. In de vorige sectie is bedoeld dat als in de werkelijkheid de code [1011] is (wel agenda, niet spreken, lage beweging, lage omgevingsgeluid), maar de informatie van de agenda-sensor verkeerd is; de telefoon in de Idle-state kan komen: de werkelijkheid is [1011] maar door een fout denkt de telefoon [0011]. Tabel 1 laat alle situaties zien waarin er met één sensorfout de Idle-state ten onrechte bereikt wordt. Tabel 1: Situaties die door één sensorfout de Idle-state tot gevolg heeft

willekeurige sensorfout vanuit (2+10+6=) 18 situaties ten onterechte in de Busy-state kan komen. Dat betekent dat gesprekken geblokkeerd worden, terwijl dat niet nodig is.

2.3 Conclusie

In dit hoofdstuk is het model van Siewiorek et al. [SSF+03] onderzocht. Het is duidelijk geworden dat dit model niet om kan gaan met sensorfouten. Dit komt omdat Siewiorek et al. [SSF+03] beslissingen hard gecodeerd hebben, en de telefoon niet door kan hebben dat een sensor verkeerde informatie doorgeeft. Een systeem ontwerpen waarbij nooit sensorfouten optreden is niet realistisch, zeker niet als er van de gebruiker een bepaalde discipline verwacht wordt. Daarom zal in volgende hoofdstukken een model ontworpen worden wat wel omgaat met de mogelijkheid dat een sensor verkeerde informatie doorgeeft.

3. BENODIGDE INFORMATIE

Om een model te kunnen ontwerpen wat aansluit op de wensen van de gebruikers, is het nodig om eerst inzicht te krijgen in deze wensen. Daarnaast is het nodig om gebruikerseigenschappen te onderzoeken, omdat zonder geen conclusies getrokken kunnen worden over inkomende sensorinformatie. Dit hoofdstuk is opgedeeld in drie paragrafen. De eerste twee gaan over de gebruikersvoorkeuren en in de derde paragraaf wordt aan activiteiten sensor-informatie gekoppeld.

3.1 Gebruikersonderzoek Zoals genoemd zijn er vijf scenario’s waarin de telefoon in de Active-state hoort. Voor elk van deze vijf scenario’s zijn er zes alternatieven, uitgaande van één sensorfout. Van deze (5*6=) 30 inputs komt de telefoon met 12 scenario’s alsnog in de Activestate, 10 in de Busy-state en 4 in de Normal-state. In Tabel 2 is te zien welke fouten er kunnen optreden, als één sensor de verkeerde informatie doorgeeft. De getallen in de tabel geven aan in welke state de telefoon in theorie zou moeten staan (kolom) en in welke state de telefoon komt te staan omdat één van de sensoren verkeerde contextinformatie doorgeeft (de state waarin de telefoon in de praktijk komt, staat op de regel). Het gaat dus om een situatie uit de werkelijkheid, waarin één sensorfout gemaakt wordt. Tabel 2: Theorie en praktijk toestanden wanneer één sensor foutieve informatie doorgeeft

In de gearceerde velden staan het aantal gevallen waarin de telefoon een verkeerd beeld heeft van de werkelijkheid, maar alsnog in de goede status terecht komt. De percentages geven aan hoeveel procent van de gevallen dat de telefoon in een verkeerde toestand komt als één sensor verkeerde informatie doorgeeft. Opvallend is dat als de telefoon in de Busy-state hoort te staan er bij precies één sensorfout, de telefoon daar in (100%-11%=) 89% van de gevallen ook in deze state terecht komt. Daarnaast valt op te merken dat de telefoon met één

In dit onderzoek is vanwege beperkte middelen de gebruikersgroep ingeperkt tot Nederlandse studenten. Er is geen concrete informatie in de bestaande literatuur gevonden over dagelijkse activiteiten en bijbehorende gewenste telefoontoestand, daarom is besloten om een kwalitatief gebruikersonderzoek te houden. Dit betreft een interview waarbij doorgevraagd wordt. De volgende vragen stonden centraal in dit onderzoek: •

Wat zijn je dagelijkse bezigheden?

•

Waar bewaar je je telefoon tijdens deze bezigheden?

•

Wil je je trilfunctie aan hebben tijdens deze activiteit? (ja/nee)

•

Hoe hard wil je het geluid van je telefoon hebben tijdens deze activiteit? (Geen geluid, Zacht geluid, Normaal geluid, Hard geluid, Voicemail)

In Tabel 3 is te zien welke antwoorden gegeven zijn en in welke frequentie. De gearceerde velden zijn de opties die het meeste voorkomen en worden in de rest van dit onderzoek als waarden aangehouden. Uit de interviews kwam naar voren dat de bewaarplaats voor de geïnterviewden persoonsafhankelijk is, en daarnaast niet altijd consequent is; bovendien zit er geen verband tussen de bewaarplaats van de telefoon en het geluidsniveau dat gewenst is in de situatie. Bij deze resultaten moet wel vermeld worden dat 71% van de geïnterviewde man is, dus dat de genoemde bewaarplaats een vertekend beeld kan geven. Omdat bijvoorbeeld de beweging van een mobieltje afhankelijk is van de bewaarplaats is er voor dit onderzoek gewerkt met de bewaarplaatsen die weergegeven zijn in de tweede kolom van Tabel 3.

Tabel 3: Gewenste toestand per dagelijkse activiteit

Opvallend is dat er over het algemeen vrij weinig behoefte is aan een zacht geluid. Als de telefoon op trillen staat geeft dat al geluid, en als het te rumoerig is voegt het geluid ook niets toe. Uitzondering is echter tijdens het slapen, wanneer men wel bereid is de telefoon op te nemen, maar geen behoefte heeft aan een (relatief) hard geluid. Ook is opvallend dat de trilfunctie eigenlijk altijd aanstaat bij de Nederlandse student, behalve als de telefoon toch al overgaat op voicemail. Daarnaast wordt er door de geïnterviewden aangegeven dat het overbodig aanhebben van de trilfunctie niet als vervelend wordt beschouwd: als de trilfunctie niet nodig is, omdat dat het niet opgemerkt wordt, is het geen probleem als hij toch afgaat, omdat het namelijk toch niet opgemerkt wordt. Omdat er een verband zit tussen de trilfunctie en het wel of niet overgaan op voicemail zijn er vijf telefoontoestanden in te delen, waarbij in de eerste 4 toestanden de trilfunctie aan staat: 1)

Geen geluid

2)

Zacht geluid

3)

Normaal geluid

4)

Hard geluid

5)

Voicemail (waarbij de trilfunctie uit staat)

verwacht. Waar het model van Siewiorek et al. [SSF+03] gebruik maakt van ingevoerde- én sensor-informatie (zie Hoofdstuk 1), wordt in dit onderzoek alleen gericht op informatie die van sensoren komt. Bij dit onderzoek is er vanuit gegaan dat er vier sensoren op een telefoon zitten: •

Geluid-sensor, die acht verschillende meetwaarden kan doorgeven (stil, rumoerig, luid, hard, één spreker, meerdere sprekers, vallend water, snurken).

•

Beweging-sensor, die vijf verschillende soorten van beweging kan onderscheiden (geen beweging, heel weinig beweging, vrij weinig beweging, normale beweging, veel beweging).

•

Verplaatsing-sensor, die de absolute verplaatsing van de telefoon registreert, en daarmee de snelheid waarin de verplaatsing plaatsvindt. Deze sensor zal vier snelheidsgroepen onderscheiden (0 tot 2 km/u, 2 tot 12 km/u, 12 tot 30 km/u, harder dan 30 km/u). Dit kan bijvoorbeeld gebeuren met behulp van een GPSsysteem, of met behulp van telefoonmasten.

•

Thuis?-sensor, dit is een sensor die bepaalt of de gebruiker in de buurt van zijn huis is (ja/nee). Dit kan bijvoorbeeld door een externe zender bij de gebruiker thuis te installeren met een beperkt bereik.

Aan de hand van deze vier sensoren is er onderscheid gemaakt tussen de 17 activiteiten die door studenten onderscheiden worden volgens Tabel 3. Deze karakteristieken zijn te vinden in vier verschillende tabellen die elk in een eigen subparagraaf beschreven worden.

3.3.1 Geluid-sensor

In Tabel 4 staan de karakteristieken met betrekking tot de geluid-sensor. Tabel 4: Verwachte informatie van geluid-sensor per activiteit

3.2 Schalen vervelendheid van fouttoestanden

In dit onderzoek wordt er vanuit gegaan dat de contextinformatie die de telefoon krijgt via zijn sensoren niet altijd correct hoeft te zijn. Hierdoor zal de telefoon aannames moeten maken bij twijfel. Tijdens het gebruikersonderzoek is ook gekeken naar welke fouten vervelender worden beschouwd en welke minder. In essentie komt het er op neer dat het onnodig missen van een telefoongesprek als vervelend wordt ervaren.

3.3 Karakteristieken

Vervolgens is er gekeken naar welke karakteristieken horen bij de activiteiten uit Tabel 3. In de literatuur is informatie te vinden over verschillende typen sensoren die kunnen bepalen in wat voor context de gebruiker zich bevindt. Er valt onderscheid te maken tussen sensoren die op de telefoon zelf kunnen zitten [SL04] en sensoren die niet aan de telefoon vast zitten [FMT+99], [LAL01]. Het speciaal aantrekken van een jas met daarop allerlei sensoren om te bepalen in wat voor een positie de gebruiker zit [FMT+99] en het om je been hebben van een band [LAL01], vraagt extra inzet van de gebruiker. Tijdens dit onderzoek wordt uitgegaan van een mobiele telefoon die niet veel van de gebruiker

De sensor kan acht verschillende waarden doorgeven; vier daarvan zijn speciaal soort geluiden die de sensor van de mobiele telefoon kan onderscheiden. Als er slechts één spreker aan het woord is, kan de telefoon dat herkennen door bijvoorbeeld toonhoogte, volume, etc. Als er water valt (bij het douchen), als er gesnurkt wordt of als er meerdere sprekers zijn; zal de telefoon dit herkennen door het vaste patroon dat die geluiden met zich meebrengen. Hoe dit technisch gerealiseerd kan worden is voor deze paper niet van belang en zal dan ook buiten beschouwing gelaten worden

3.3.2 Beweging-sensor

In Tabel 5 zijn de beweging-karakteristieken van de 17 activiteiten weergegeven. Bij de beweging ‘geen’ kan er vanuit gegaan worden dat de gebruiker de telefoon niet bij zich draagt; bijvoorbeeld in een stilstaande tas of als de telefoon op een bureau ligt. Als de telefoon in de broekzak zit en de gebruiker probeert stil te zitten (in een hoorcollege, tijdens het tv kijken of in de bioscoop) zal de sensor ‘heel weinig’ beweging registreren. Verwacht de activiteit echter inspanning van de gebruiker (Werkcollege, Achter buro zitten of Eten), dan moet de sensor ‘vrij weinig’ beweging registreren. Daarnaast is er de optie tot het registreren van ‘gewone beweging’ dit is bij activiteiten waarbij de gebruiker niet zit. Veel beweging wordt geregistreerd als de gebruiker actief bezig is (Fietsen, Lopen, Uitgaan). Tabel 5: Verwachte informatie van beweging-sensor per activiteit

bewust bezig met zich te verplaatsen. Bij verplaatsingen tussen de 2 en de 12 km/u zal het gaan om verplaatsingen die bewust gemaakt worden doormiddel van te lopen. Boven de 12 km/u en onder de 30 km/u zal er vanuit gegaan worden dat de gebruiker aan het fietsen is. Als laatste categorie worden snelheden onderscheiden van boven de 30 km/u; dan kan de gebruiker in een auto zitten, in een bus of in een trein. In Tabel 6 is weergegeven welke karakteristieken met betrekking tot de snelheid van de absolute verplaatsing horen bij de 17 activiteiten.

3.3.4 Thuis?-sensor

De vierde sensor die informatie geeft over de context is de Thuis?-sensor Deze sensor bepaalt of de gebruiker thuis is. Dit kan gedaan worden aan de hand van een zender die bij de gebruiker thuis geïnstalleerd wordt. Deze zender zendt een signaal uit, met een beperkt bereik, waardoor de telefoon door heeft dat hij in de buurt van de zender is. Tabel 7 laat zien wat verwacht wordt dat de “Thuis?-sensor” doorgeeft als het gaat om de 17 activiteiten. Tabel 7: Verwachte informatie van Thuis?-sensor per activiteit

3.3.3 Verplaatsing-sensor

De verplaatsing-sensor meet absolute verplaatsing. Dat wil zeggen dat hij op een bepaald tijdstip de locatie bepaalt met behulp van externe apparatuur (bijvoorbeeld GPS, of via telefoonmasten). Op een tweede tijdstip bepaalt hij weer de locatie. Op deze manier is de snelheid waarmee de telefoon, en dus de gebruiker, zich verplaatst te berekenen. Tabel 6: Verwachte informatie van verplaatsing-sensor per activiteit

Deze sensor maakt onderscheid tussen vier verschillende snelheden. De eerste snelheid die de sensor onderscheid zijn de snelheden tussen de 0 en de 2 km/u; dan is de gebruiker niet

3.3.5 Activiteit codering

In Tabel 8 is er aan elk van de activiteiten een code gekoppeld, die weergeeft welke karakteristieken de activiteit heeft. Tabel 8: Code per activiteit

Dit is een 4 cijferig getal, waarbij het eerste cijfer een waarde van 1 tot 8 kan aannemen en het geluid aangeeft. Het tweede cijfer geeft de beweging aan en is een waarde tussen de 1 en 5.

Het derde cijfer geeft aan hoe snel de telefoon zich beweegt, geschaald tussen 1 en 4. Het laatste cijfer geeft de sensorinformatie van de ‘Thuis?-sensor’ weer en kan dus 1 en 2 zijn. Deze cijfers zijn boven de tabellen 4 tot en met 7 aangegeven als de optienummers.

4. MODEL

In de vorige paragraaf zijn twee opvallende feiten: •

Boodschappen en Winkelen/stad hebben dezelfde karakteristieken (3422) én dezelfde ideale telefoontoestand (normaal).

•

Eten, douchen en slapen hebben meerdere scenario’s, die kunnen wijzen op een van deze activiteiten.

Door het eerste feit wordt er besloten om Boodschappen en Winkelen/stad samen te nemen als één activiteit.

Er wordt in dit onderzoek dus gericht op de inputs die voor 75% overeenkomen met de voorgedefinieerde scenario’s. Inputs die niet aan deze eis voldoen, zijn óf inputs die niet mogelijk zijn in de praktijk, óf inputs die horen bij scenario’s die buiten de scope van deze paper vallen. Van de (320-19=) 301 overgebleven inputs er 152 voor 75% overeen met in ieder geval één voorgedefinieerd scenario. Dat betekend dat er 149 inputs buiten de scope van dit beslissingmodel vallen, en dus verder niet in deze paper behandeld worden. #

#

%

#

&

#

'

De dubbele scenario’s eten, douchen en slapen worden als aparte activiteiten gezien. Hierdoor wordt er vanuit gegaan dat er 19 activiteiten zijn, met elk een eigen input: er zijn 19 voorgeprogrammeerde scenario’s. Met een scenario wordt bedoeld een code die een representatie geeft van de werkelijke situatie waarin de gebruiker zich bevindt. In deze paper wordt er vanuit gegaan dat deze 19 scenario’s alle situaties omvatten, waarin iemand zich kan verkeren. Er wordt voor het onderzoek in deze paper uitgegaan van een mobiele telefoon met vier sensoren, die ieder acht, vijf, vier of twee mogelijke waarden kunnen doorgeven. Hierdoor zijn er (8*5*4*2=) 320 mogelijke codes. Voor elk van deze codes moet er gezocht worden naar een bijpassend scenario, maar zoals in Hoofdstuk 1 aangegeven moet er ook rekening gehouden worden met het feit dat een sensor niet volledig betrouwbaar is. Met andere woorden: het beslissingsmodel die in de volgende paragrafen besproken wordt moet er rekening mee houden dat de input die ze krijgen niet per se hoeft te kloppen. Er wordt echter wel uitgegaan dat van de vier sensoren altijd drie de juiste informatie geven. De telefoon weet alleen niet welke van de vier sensoren de onjuiste informatie kan geven. Er is besloten om niet te werken met een stroomschema, waarin aan de hand van een enkele sensor beslissingen genomen worden: er wordt gekeken in hoeverre de gehele input overeenkomt met verwachte input. Het ontworpen model, dat werkt volgens een scenario-fit, is te vinden in Figuur 2. Dit model wordt stap voor stap toegelicht in de volgende paragrafen. Het model is geanalyseerd met de 320 mogelijke inputs. Onderaan iedere paragraaf staat cursief gedrukt welke aantallen er onder bepaalde condities vallen.

4.1 Stap 1

Als een input binnenkomt voor 100% overeenkomt met een voorgedefinieerd scenario, gaat de telefoon er vanuit dat geen van de sensoren verkeerde informatie heeft doorgegeven en gaat het dus over in de toestand die volgens dat scenario zou moeten. Van de 320 mogelijke inputs zijn er 19 voorgeprogrameerd in de telefoon. Als deze input gegeven wordt, wordt de toestand die bij deze input hoort ingesteld.

4.2 Stap 2

Als een scenario niet voor 100% klopt kan er vanuit gegaan worden dat een van de sensoren verkeerde informatie doorgeeft. De aanname in het begin van dit hoofdstuk is immers dat de scenario’s alle activiteiten omvatten. Daarnaast wordt er vanuit gegaan dat maximaal één sensor verkeerde informatie doorgeeft.

!

#

"

!

"

"

!

#

!

#

"

! $

#

$

Figuur 2: Beslissingsmodel van een Context-Aware telefoon, die rekening houdt met eventuele sensorfouten

4.3 Stap 3

Als een input met precies één scenario voor 75% overeenkomt, kan de telefoon bepalen welke sensor de verkeerde informatie heeft gegeven. De telefoon moet dan handelen alsof de input van dit scenario is binnen gekomen. Als van alle scenario’s waarvan de input 75% overeenkomt leiden tot dezelfde stand, hoeft de telefoon zich niet druk te maken over in welke situatie hij zit, maar gewoon die state aannemen. Ook kan er gekeken worden welk van de gewenste toestanden het meeste voorkomt. Dit heeft voor de eerste twee ‘testen’ hetzelfde resultaat (als er precies één scenario is, komt die ene toestand automatisch ‘het vaakst’ voor, als er alleen ‘getwijfeld’ wordt tussen dezelfde toestanden, komt die toestand ook als meeste voor), maar daarnaast test het ook andere situaties waarin de telefoon tussen meer dan twee activiteiten twijfelt. Deze stap verbindt aan 113 inputs een toestand. Er zijn dus aan (113+19=) 132 inputs toestanden verbonden. Na het uitvoeren van deze stap zijn er nog (152-113=) 39 scenario’s waarbij de telefoon nog geen beslissing heeft gemaakt.

4.4 Stap 4

Als de input dan nog niet tot een telefoontoestand geleid heeft, kan er een aanname gedaan worden over welke sensor het meest waarschijnlijkst kapot is. Omdat we er vanuit gaan dat er maar

één sensor verkeerde informatie doorgeeft, en dat alle scenario’s beschreven zijn, kunnen we een aanname doen over welke waarden waarschijnlijk wel goed zijn. Bijvoorbeeld: als de input ABCD is, en mogelijk passende scenario’s zijn ABCZ en ABYD. Als er dan vanuit gegaan zou worden dat de eerste twee sensoren verkeerde inputs hebben, leidt dat tot het effect dat de input minder met een voor-gedefinieerd scenario overeenkomt. Daarom gaat de context-aware telefoon er vanuit dat de sensoren die het meest met alle mogelijke scenario’s overeenkomen, de goede informatie geven. In dit voorbeeld zijn dat de eerste twee sensoren. De derde of vierde sensor kan in dit voorbeeld een fout bevatten. Om te bepalen welk van de overgebleven sensoren fout is, wordt uitgegaan van de kwaliteit van de sensor, waarbij de Thuis?-sensor als betrouwbaarst wordt geacht, daarna de Beweging-sensor, vervolgende de Geluid-sensor (de telefoon kan immers in een dempende broekzak/tas zitten) en daarna de verplaatsing-sensor (deze zal waarschijnlijk de verplaatsing bepalen aan de hand van externe apparatuur (zie Paragraaf 3.3)). Met behulp van deze rangorde kan bepaald worden welke drie contextinformatie producten als betrouwbaar worden geacht. Dan wordt er gekeken welk scenario het meest overeenkomt met de drie inputs. Van de 39 inputs waarvoor de telefoon nog geen beslissing heeft genomen zijn, op bovenstaande manier, 24 inputs gekoppeld aan een voorgedefinieerd scenario. Dat betekent dat de telefoon bij 15 inputs nog moet zoeken naar een passende toestand.

4.5 Stap 5

Als er na stap 4 nog geen toestand is bepaald voor de telefoon, wordt er een stand bepaald aan de hand van alle toestanden die horen bij alle scenario’s waarmee de input voor 75% overeenkomt. Zit er tussen deze toestanden de voicemail, en (minstens één) andere toestand, dan zet hij de telefoon op stil. Dit met de gedachtegang dat een gebruiker niet onnodig een gesprek wil missen (zie Paragraaf 3.2). Als de keuze gaat tussen hard en (minstens een) andere (waarvan niet voicemail, die gevallen zijn immers al beschreven in de vorige alinea), dan gaat de telefoon op normaal. Ook hier is de gedachte dat de gebruiker niet onnodig een gesprek wil missen. Als er gekeken wordt naar Tabel 3 zijn de gevallen dat de telefoon in de toestand hard zou moeten gaan: TV kijken, Douchen, Fietsen, Uitgaan en Autorijden. In de meeste van deze gevallen zou de telefoon al volgens (een minderheid van) de gebruikers in de normaal-state moeten. Verwacht wordt dus dat dit geen ergernis zal opleveren. De scenario’s van de situaties waarin de telefoon kan kiezen tussen voicemail/stil en hard liggen in deze case dusdanig ver uit elkaar dat er bijna nooit gekozen hoeft te worden tussen voicemail-hard of stil-hard; behalve tijdens het sporten. Volgens Tabel 3 zijn er echter ook gebruikers die een andere stand dan de voicemail willen, dus verwacht wordt dat deze keuze geen ernstige gevolgen heeft. Als er dan nog geen beslissing is geweest, kijkt de telefoon of er getwijfeld wordt tussen stil; als dat niet zo is, wordt er getwijfeld tussen zacht en normaal. De telefoon gaat dan op normaal, omdat in de huidige scenario’s alleen zacht verwacht wordt als de gebruiker slaapt en subtiel gewekt wil worden. Het is geen ramp als de gebruiker bij wijze van uitzondering een keer wat harder wordt gewekt. Als er wel getwijfeld wordt tussen stil, wordt er gekeken of er getwijfeld wordt tussen stil en zacht. In dat geval gaat de telefoon in stil, er vanuit gaande dat de trilmotor ook geluid maakt en dus het lage belniveau niet al te veel toevoegt. Als de keuze gaat tussen stil en normaal komt de telefoon in zacht, als mooie middenweg.

Hiermee is er aan alle 171 scenario’s een telefoontoestand toegekend. In Figuur 3 is van deze case de verdeling per beslissingsmodel stap te zien.

Figuur 3: Verdeling van scenario's door het beslissingsmodel

5. ANALYSE VAN HET BESLISSINGSMODEL VOLGENS SCENARIO-FIT

Op gelijke manier als beschreven in Hoofdstuk 2 is er een analyse uitgevoerd op het model uit Hoofdstuk 4. Hierbij is er uitgegaan dat de telefoon zich in een voorgedefinieerd scenario bevindt. Vervolgens zijn er alternatieven inputs gedefinieerd die maar op één punt afwijken van het scenario waarin de telefoon zich werkelijk bevindt. In het geval dat de eerste sensor verkeerde informatie geeft zijn er 7 alternatieve inputs. Als de tweede sensor verkeerde informatie doorgeeft zijn er 4 alternatieve inputs. Bij fouten in de derde sensor kan dat leiden tot 3 alternatieve inputs. En als de ‘Thuis?-sensor’ verkeerde informatie geeft is er 1 alternatief. Er zijn dus per voorgedefinieerd scenario (7+4+3+1=) 15 alternatieven bekeken. De uitkomsten staan in onderstaande tabel. Een getal in deze tabel geeft het aantal mogelijkheden weer dat de telefoon zich in een bepaalde situatie bevindt (kolom), maar doordat de telefoon verkeerde input krijgt, plaatst hij zich in een bepaalde toestand (rij). Er zijn (19*15=) 285 van deze gevallen. Tabel 9: Theorie en praktijk toestanden wanneer één sensor foutieve informatie doorgeeft bij het model beschreven in Hoofdstuk 4

Er zijn 92 situaties te bedenken waarin de telefoon een verkeerde toestand bij een situatie kiest, als er één sensorfout plaatsvindt (niet gearceerde velden). Het totaal aantal goed gecorrigeerde sensorfouten is 193 (gearceerde velden). Bij Tabel 9 moet opgemerkt worden, dat als een gebruiker niet gestoord wil worden (voicemail), van de (12+4+1=) 17 fouten er 12 gecorrigeerd worden in de geen geluid-toestand. Hierbij wordt de omgeving van de gebruiker niet onnodig gestoord en kan de gebruiker alsnog beslissen de telefoon handmatig te negeren.

Als de telefoon op voicemail of geen geluid moet staan zijn er slechts (3+2+1+4=) 10 scenario’s waarin de telefoon een toestand aanneemt die wel geluid maakt en ergernis van de omgeving kan opwekken Opgemerkt moet worden dat de gegevens uit Tabel 9 niet één op één vergeleken kunnen worden met de gegevens uit Tabel 2, omdat het om twee verschillende beslissingsmodellen gaat, die ieder een verschillend aantal alternatieven hebben, een verschillend aantal telefoontoestanden; en er in het onderzoek verschillende typen sensoren gebruikt zijn.

6. VOORDEEL VAN MODEL MET SCENARIO-FIT

Het grootste voordeel van het beslissingsmodel volgens scenario-fit is dat er rekening gehouden kan worden met het feit dat niet alle binnenkomende contextinformatie correct hoeft te zijn. Doordat er gekeken wordt in hoeverre een input overeenkomt met een voorgedefinieerd scenario, is er een mogelijkheid tot het corrigeren van verkeerde sensorinformatie. Het model van Siewiorek et al. [SSF+03] is een stroomschema waarbij de voorkeuren hard gecodeerd zijn. Dat betekent dat als een gebruiker andere persoonlijke voorkeuren heeft, het model volledig aangepast moet worden. Daarnaast is in het model een rangorde van de sensoren. De agenda-sensor wordt als belangrijkst gezien. Dit model houdt niet rekening met het binnen krijgen van foutieve contextinformatie. Het model beschreven in Hoofdstuk 4, is opgebouwd uit meerdere lagen. De eerste laag is de interpretatie van de wereld door de sensoren. In de tweede laag wordt deze input gekoppeld aan een voorgedefinieerd scenario (activiteiten). En in de laatste laag worden deze activiteiten gekoppeld aan een telefoontoestand. Een voordeel van de verdeling in deze lagen is dat dit model flexibel is. Als een ontwerper graag een extra sensor op de telefoon wil plaatsen, is dat een aanpassing in de eerste laag. Als er verder onderzoek gedaan wordt, en er worden meer activiteiten onderscheiden, is dat een aanpassing in de tweede laag, en als blijkt dat de persoonlijke voorkeur van iemand anders is als beschreven in Tabel 3, dan hoeft alleen de derde laag aangepast te worden. Er kan zelfs in de toekomst gedacht worden aan een telefoon die zelf zijn scenario’s leert uit de praktijk. Als de telefoon een input krijgt waarvoor geen bijbehorende toestand bekend is, kan hij aan de gebruiker vragen welke toestand bij de verzamelde contextinformatie hoort.

7. CONCLUSIE

In deze paper wordt de totstandkoming van een model beschreven waarmee een context-aware telefoon kan beslissen in welke toestand de telefoon moet staan. Dit model is gebaseerd op het gebruik van vier sensoren die informatie geven over de context van het apparaat. In dit onderzoek stonden de volgende twee vragen centraal: “Wat is de invloed van binnen het krijgen van al dan niet foutieve contextinformatie bij een context-aware mobiele telefoon?” En “Hoe kan een beslissingmodel van een contextaware mobiele telefoon er uit zien, die rekening houdt met het feit dat contextinformatie niet per definitie correct is?” Als een mobiele telefoon verkeerde contextinformatie binnen krijgt, kan de telefoon daar verkeerde toestanden aan verbinden. Dit kan ergernis op wekken bij de gebruiker.

In Hoofdstuk 4 staat een beslissingmodel van een context-aware mobiele telefoon die rekening houdt met het feit dat contextinformatie niet per definitie correct is. Dit model werkt volgens een scenario-fit. Er wordt gekeken in hoeverre een input overeenkomt met een voorgedefinieerd scenario, om zo (eventueel na correctie) daar een conclusie aan te verbinden. Dit nieuwe model is opgebouwd uit drie lagen. De eerste laag is de interpretatie van de wereld door de sensoren. In de tweede laag wordt deze input gekoppeld aan een voorgedefinieerd scenario (activiteiten). En in de laatste laag worden deze activiteiten gekoppeld aan een telefoontoestand. Een voordeel van het werken met deze lagen is dat het model heel goed aanpasbaar is (zie Hoofdstuk 6).

8. VERDER ONDERZOEK

In verder onderzoek kan gekeken worden of dit model in de praktijk werkt zoals verwacht. Daarnaast kan er onderzocht worden of de 19 scenario’s die beschreven zijn in Hoofdstuk 4 compleet zijn, door een grotere gebruikersgroep te interviewen. Er zou onderzocht kunnen worden of het niet mogelijk is een lerend systeem te maken die bij iedere nieuw scenario input vraagt welke toestand de gebruiker bij de verzamelde contextinformatie zou willen. Op die manier worden uiteindelijk alle mogelijke scenario’s beschreven en bovendien kan iedere gebruiker zijn persoonlijke instellingen maken. Ook kan er gekeken worden wat het uitbreiden van de telefoon met meer dan vier sensoren kan toevoegen aan de service die het apparaat levert. Een andere uitbreiding zou kunnen zijn hoe de omgang moet verlopen bij meer dan één sensorfout.

ERKENNING

Gedurende het schrijven van deze paper ben ik ondersteund door een aantal personen. Door onder andere feedback te krijgen en te kunnen geven, maar ook door te kunnen discussiëren, heb ik nieuwe inzichten gekregen, wat de kwaliteit van deze paper ten goede is gekomen. Bij deze wil ik iedereen bedanken die heeft bijgedragen aan deze paper.

REFERENTIES

[BKS03] T. Buchholz, A. Kuepper, M. Schiffers, Quality of Context: What it is and Why we need it, Workshop of the HP OpenView University Association 2003, Geneva, 2003 [DA99] A.K. Dey and G.D. Abowd, Toward a better understanding of Context and Context-Awareness, HUC ’99: Proceedings of the 1st international symposium on Handheld and Ubiquitous Computing, pages 204-207, Londen, UK. 1999. Springer-Verlag. [FMT+99] J. Farringdon, A.J. Moore, N. Tilbury, J. Chruch and P.D. Biemond, Wearable sensor badge & sensor jacket for context awareness, Proceedings of the International Symposium on Wearable Computing (ISWC’99), San Francisco, CA (November 1999) pp. 107–113 [GSB02] Gellersen H.W., Schmidt A., Beigl M, Multi-Sensor Context-Awareness in Mobile Devicesand Smart Artifacts, Mobile Networks and Applications 7, p341– 351, 2002

[LAL01] K. Van Laerhoven, K. Aidoo and S. Lowette, Realtime analysis of data from many sensors with neural networks, Proceedings of the International Symposium on Wearable Computing (ISWC 2001), Zürich, Switzerland (October 2001) [SL04] A. Schmidt and K. Van Laerhoven, How to build smart appliances?, IEEE Personal Communications 8(4) (August 2001)

[SSF+03] Siewiorek D., Smailagic A., Furukawa J., Moraveji N., Reiger K., and Shaffer J. SenSay: A ContextAware Mobile Phone september 2003