Vergelijkende studie van ZigBee en Bluetooth voor context ......ZIGBEE 4 Hoofdstuk 2 ZigBee Dit...

Faculteit Toegepaste Wetenschappen

Vakgroep Informatietechnologie

Voorzitter: Prof. Dr. Ir. P. LAGASSE

Vergelijkende studie van ZigBee en Bluetooth voor

context-aware ziekenzorgtoepassingen

door

Pieter DE MIL

Promotoren: Prof. Dr. Ir. I. Moerman, Prof. Dr. Ir. R. Van de Walle, Dr. Ir. P. Verhoeve

Thesisbegeleider: Ir. B. Latre

In samenwerking met Televic

Scriptie ingediend tot het behalen van de academische graad van

licentiaat in de informatica, optie: toepassingsgerichte informatica

Academiejaar 2004–2005

Woord vooraf

Graag zou ik iedereen willen bedanken die heeft bijgedragen tot de verwezenlijking van dit

eindwerk, in het bijzonder dank ik:

• IBCN, MultimediaLab, Televic en mijn thesisbegeleider ir. Benoıt Latre voor het scheppen

van de mogelijkheid dit onderzoek te verrichten;

• mijn familie en vrienden;

• en uiteraard mijn vriendin Inge.

Pieter De Mil, mei 2005

Toelating tot bruikleen

“De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van

de scriptie te kopieren voor persoonlijk gebruik.

Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrek-

king tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit

deze scriptie.”

Pieter De Mil, mei 2005

Vergelijkende studie van ZigBee en Bluetooth voor

context-aware ziekenzorgtoepassingen

door

Pieter DE MIL

Scriptie ingediend tot het behalen van de academische graad van

licentiaat in de informatica, optie: toepassingsgerichte informatica

Academiejaar 2004–2005

Promotoren: Prof. Dr. Ir. I. Moerman, Prof. Dr. Ir. R. Van de Walle, Dr. Ir. P. Verhoeve

Thesisbegeleider: Ir. B. Latre

In samenwerking met Televic

Faculteit Toegepaste Wetenschappen

Universiteit Gent

Vakgroep Informatietechnologie

Voorzitter: Prof. Dr. Ir. P. LAGASSE

Samenvatting

Het uitgangspunt is een ziekenzorgtoepassing waarbij PDA’s ingeschakeld worden om het admi-nistratieve werk van de verpleegkundige te verlichten. We wensen deze applicatie transparanterte maken. Dit wordt gerealiseerd door de verpleegkundige automatisch te laten weten wie dedichtste patient in zijn buurt is. Dankzij deze contextgevoelige informatie zal de gebruiker vande applicatie niet langer de naam van de patient in een lijst moeten opzoeken. Het onderzoeknaar “context-aware computing” richt zich tot twee draadloze technologieen: 802.15.4/ZigBeeen Bluetooth. De aandachtspunten omvatten de nauwkeurigheid van de bepaling, de invloed vanhet zendvermogen en de mogelijke interferentie tussen beide technologieen. Het bleek dat ZigBeemeer geschikt was omdat hierbij op een eenvoudige wijze de linkkwaliteit bepaald kan wordenen dit sneller dan bij Bluetooth. Echter, ZigBee heeft meer last van interferentie dan Bluetooth,maar het pakketverlies valt binnen de vereisten van de applicatie. Uiteindelijk resulteerde ditwerk in een praktische demonstratie.

Trefwoorden

802.15.4, Bluetooth, context-aware, SMAC, ZigBee.

INHOUDSOPGAVE i

Inhoudsopgave

1 Inleiding 1

1.1 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Oplossingsmethode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 ZigBee 4

2.1 Achtergrondinformatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Introductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.2 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.3 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.4 Gebruikte kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Werk verricht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Programma: de hardware modules . . . . . . . . . . . . . . . . . . . . . . 12

2.2.2 Programma: de .Net Compact Framework toolkit . . . . . . . . . . . . . . 20

2.3 Analyse van de proeven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3.1 Foutenpercentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3.2 Verband tussen de linkkwaliteit en de afstand . . . . . . . . . . . . . . . . 26

2.3.3 Batterij test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3 Bluetooth 31

3.1 Achtergrondinformatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1.1 Introductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1.2 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.1.3 Gebruikte adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

INHOUDSOPGAVE ii

3.2 Werk verricht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.1 Programma: Windows PC - BTAccess . . . . . . . . . . . . . . . . . . . . 35

3.2.2 Programma: GNU/Linux PC - BlueZ . . . . . . . . . . . . . . . . . . . . 37

3.2.3 Programma: de .Net Compact Framework toolkit . . . . . . . . . . . . . . 40

3.3 Analyse van de proeven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.3.1 Foutenpercentage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.3.2 Verband tussen de linkkwaliteit en de afstand . . . . . . . . . . . . . . . . 42

3.4 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4 Vergelijking tussen ZigBee en Bluetooth 44

4.1 Algemene vergelijking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2 Interferentie tussen beide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.3 Interferentie door microgolfoven . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.4 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5 Integratie in CaReport 51

5.1 Vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.2 ContextEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.3 XtagEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.4 ElpasEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.5 BluetoothEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.6 ZigBeeEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6 Besluit 62

6.1 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.2 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6.3 Toekomstig werk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

LIJST VAN FIGUREN iii

Lijst van figuren

2.1 Het lagenmodel van IEEE 802.15.4 en ZigBee. . . . . . . . . . . . . . . . . . . . . 5

2.2 De verschillende topologieen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Het SMAC blok diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Een voorbeeld van een netwerkconfiguratie . . . . . . . . . . . . . . . . . . . . . . 9

2.5 De 802.15.4 hardware module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.6 Het sequentiediagram voor het zoeken van de dichtste patient . . . . . . . . . . . 13

2.7 Het sequentiediagram voor de bestandsoverdracht . . . . . . . . . . . . . . . . . . 15

2.8 Programmastructuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.9 Scenario 4: De linkkwaliteit i.f.v. het zendvermogen en de afstand . . . . . . . . 27

2.10 Scenario 5: De linkkwaliteit i.f.v. de positie . . . . . . . . . . . . . . . . . . . . . 29

3.1 De Bluetooth protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2 Het sequentiediagram voor het zoeken van de dichtste patient (Windows) . . . . 36

3.3 Het sequentiediagram voor het zoeken van de dichtste patient (GNU/Linux) . . . 38

4.1 De invloed van een externe Bluetooth-verbinding op de ZigBee-oplossing . . . . . 46

4.2 De invloed van een externe ZigBee-“verbinding” op de Bluetooth-oplossing . . . 47

4.3 De invloed van een microgolfoven op de ZigBee-oplossing . . . . . . . . . . . . . 49

5.1 De ContextEngine klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.2 Instellingen XtagEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.3 Instellingen ElpasEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.4 Instellingen BluetoothEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.5 Instellingen ZigBeeEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

LIJST VAN TABELLEN iv

Lijst van tabellen

2.1 Scenario 1: Timer variabel, Interval 2000 ms, Serieel . . . . . . . . . . . . . . . . 23

2.2 Scenario 2: Timer 500 ms, Interval variabel, Serieel . . . . . . . . . . . . . . . . . 24

2.3 Scenario 3: Timer 500 ms, Interval 1000 ms, Serieel, Twee bed-modules . . . . . 26

3.1 Foutenpercentage: Interval variabel . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2 Verband tussen de linkkwaliteit en de afstand bij Bluetooth . . . . . . . . . . . . 42

4.1 Algemene eigenschappen van Bluetooth en ZigBee . . . . . . . . . . . . . . . . . 44

INLEIDING 1

Hoofdstuk 1

Inleiding

In de komende tien jaar zullen we meer en meer draadloze netwerken zien verschijnen. In

dit eindwerk werd onderzocht of we deze draadloze technologieen kunnen aanwenden om een

context-aware applicatie te bouwen. Het uitgangspunt is een ziekenzorgtoepassing van de firma

Televic, namelijk CaReport. Dankzij deze applicatie kunnen de verpleegkundigen een aantal

activiteiten registeren op hun draagbare “Personal Digital Assistant” (PDA). Voorheen diende

deze informatie eerst ingevuld te worden op papieren formulieren om dit nadien allemaal in te

geven in de applicatie op de computer. Door de PDA in te schakelen is dit administratieve

overtikwerk overbodig geworden. Men wenst nu deze applicatie transparanter te maken voor de

verpleegkundige, door deze uit te breiden met context-gevoelige capaciteiten.

1.1 Probleemstelling

In de huidige CaReport-applicatie moet de verpleegkundige steeds de naam van de patient

opzoeken, wat een vervelend en tijdrovend karwei is. Wanneer de verpleegkundige bij een patient

komt, is het wenselijk dat de naam van deze patient op het scherm van de PDA verschijnt. Op die

manier wordt de applicatie transparanter en stijgt het gebruiksgemak voor de verpleegkundige.

Om dit probleemloos te laten verlopen, zijn er enkele aandachtspunten die we in acht nemen.

Het moet mogelijk zijn om het onderscheid te maken tussen minstens twee patienten die zich in

dezelfde kamer bevinden. De nauwkeurigheid is dus van groot belang. Hierbij merken we op dat

de patienten zich op minder dan 1 m van elkaar kunnen bevinden. Hiermee verband houdend

kunnen we ons afvragen of het mogelijk is om kleine proximity-cellen in te stellen. De werking

van het geheel mag verder uiteraard niet verstoord worden door andere draadloze technologieen

1.2 Oplossingsmethode 2

of door iemand die een microgolfoven aan het gebruiken is. Een derde aandachtspunt omvat

de meetsnelheid. Indien we 2 s moeten wachten om een resultaat te zien, dan zal dit het

gebruiksgemak niet verhogen. De meetsnelheid is afhankelijk van de tijd nodig om een verbinding

op te zetten en de vertraging geıntroduceerd door het versturen van de berichten. Een laatste

aandachtspunt is de batterij-problematiek. Indien de zenders en ontvangers gevoed worden door

een batterij, moeten we ervoor zorgen dat deze een bepaalde tijd onafhankelijk kunnen werken.

Stel dat we de batterijen elke dag moeten heropladen, dan betekent dit een aanzienlijke werklast.

1.2 Oplossingsmethode

Het gestelde probleem kan op twee manieren worden aangepakt. Enerzijds door middel van

exacte lokatie bepaling, anderzijds door middel van context-aware informatie. In dit eindwerk

wordt de piste van “context-aware computing” gevolgd. Hierbij zal elke patient een zender bij

zich hebben, die een identificatie-antwoord zal versturen naar de verpleegkundige in de buurt.

Aan de hand van de opgemeten linkkwaliteit, vervat in dat indentificatie-antwoord, kan er op

de PDA bepaald worden welke patient zich het dichtst bij de verpleegkundige bevindt. Het

opmeten van de linkkwaliteit, al dan niet in combinatie met het instellen van proximity-cellen,

moet ervoor zorgen dat deze info betrouwbaar en nauwkeurig is. Verder wordt er onderzocht

hoe elke technologie mogelijke storingen, van bijvoorbeeld een microgolfoven, kan opvangen.

Wat betreft de meetsnelheid wordt onderzocht welke factor de grootste vertraging met zich

meebrengt. Is dit het opzetten van de verbinding of het versturen van de berichten?

1.3 Overzicht

Om dit te verwezenlijken zijn verschillende technologieen bruikbaar. In hoofdstuk 2 worden

de mogelijkheden van ZigBee (IEEE 802.15.4) bestudeerd en toegepast. Bluetooth komt aan

bod in hoofdstuk 3. In elk hoofdstuk zal na de achtergrondinformatie een bespreking van het

programma volgen. Een niet onbelangrijk deel zal gaan naar de analyse van de proeven. Een

vergelijking van beide technologieen is te vinden in hoofdstuk 4. Hierbij worden zowel de typische

eigenschappen als de mogelijke interferentie tussen Bluetooth en ZigBee nader bekeken. Actieve

RFID werd onderzocht door Wim Vandenberghe [Van05] en GPS door Stijn De Wilde [DW05].

Uiteindelijk werden de oplossingen voor al deze technologieen geıntegreerd in de CaReport-

applicatie (hoofdstuk 5). Hoofdstuk 6 geeft tenslotte nog een besluit en een overzicht van

1.3 Overzicht 3

mogelijk verder onderzoek.

ZIGBEE 4

Hoofdstuk 2

ZigBee

Dit hoofdstuk handelt over de nieuwe draadloze technologie 802.15.4/ZigBee en de implemen-

tatie van een contextgevoelige applicatie. Na een korte kennismaking met deze standaarden

(Sectie 2.1.2 en 2.1.3) en de gebruikte kit (Sectie 2.1.4) wordt het eigenlijke werk besproken.

In eerste instantie werd de firmware (Sectie 2.2.1) voor de hardware-modules geschreven, in C.

Deze werd eerst getest met behulp van een terminal, pas nadien met een PDA testapplicatie

(Sectie 2.2.2), geschreven in C#.Net. Hierna volgt een analyse van de proeven (Sectie 2.3), met

als afsluiter de belangrijkste besluiten (Sectie 2.4).

Het is niet de bedoeling om de volledige 802.15.4/ZigBee-standaard te beschrijven. De

ZigBee-standaard is immers nog niet vrijgegeven voor het grote publiek. Voor meer info wordt

er verwezen naar de referenties.

2.1 Achtergrondinformatie

2.1.1 Introductie

Er zijn veel standaarden die zich toespitsen op middelgrote tot hoge datasnelheden voor netwerk-

toepassingen of multimedia, maar er was nog geen draadloze netwerkstandaard voor de unieke

behoeften van sensoren en andere controle toestellen. Sensoren hebben geen behoefte aan een

hoge bandbreedte zoals dat bij Wi-Fi en Wi-Max wel een doel is. Ze vereisen daarentegen een

netwerkomgeving die weinig energie vereist en weinig vertraging introduceert bij het versturen

van berichten op korte afstand.

Met de komst van ZigBee, het nieuwe draadloze communicatie protocol, werd die leemte

opgevuld. Het is een standaard die gebaseerd is op de IEEE 802.15.4 [Soc03] norm. De inhoud

2.1 Achtergrondinformatie 5

van de IEEE 802.15.4 norm kan afgeleid worden uit de volgende beschrijving:

“Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for

Low-Rate Wireless Personal Area Networks (LR-WPANs)”

Figuur 2.1: IEEE 802.15.4 en ZigBee protocolstack.

Figuur 2.1 geeft een schematisch overzicht van de protocolstack. De eerste twee lagen, de

fysieke laag en de media-access laag worden gedefinieerd in de 802.15.4 standaard. De daarboven

liggende lagen zijn door de ZigBee Alliance gedefinieerd. Hierna volgt een beknopte beschrijving

van zowel de 802.15.4 standaard en de ZigBee-specificatie.

2.1.2 802.15.4

Een LR-WPAN is een eenvoudig, lage-kost communicatienetwerk dat toelaat om applicaties

(toestellen) draadloos te verbinden. Deze toestellen hebben typisch een beperkt zendvermogen

en verbruiken zelf weinig energie. De hoofdbedoelingen van een LR-WPAN omvatten betrouw-

bare gegevensoverdracht, kort bereik, lage kostprijs, lange levensduur van de batterij en toch

nog een eenvoudig protocol stack [CGH+02].

Dit zijn enkele eigenschappen van een LR-WPAN:

• Data snelheden van 250 kbps, 40 kbps en 20 kbps

• Ster of punt tot punt netwerk

• 16 bit korte of 64 bit uitgebreide adressen

• Gegarandeerde tijd slots (GTSs)

• Channel access mechanisme (niet-beacon mode): Carrier sense multiple access with colli-

sion avoidance (CSMA-CA)


• Protocol met bevestigingen (ACKs) voor betrouwbare overdracht

• Laag energieverbruik

• Energie detectie

• Linkkwaliteit indicatie

• 16 kanalen in de 2450 MHz band, 10 kanalen in de 915 MHz band en 1 kanaal in de 868

MHz band

• Grote netwerken mogelijk (theoretisch tot 65535 nodes per netwerk coordinator)

Figuur 2.2: Ster en punt tot punt topologieen.

In een LR-WPAN netwerk kunnen twee verschillende types deelnemen, het “full-function

device” (FFD) en het “reduced function device” (RFD). Het FFD beschikt over drie modes, nl.

PAN-coordinator, coordinator of gewoon als toestel zonder coordinerende functie. Het FFD kan

communiceren met alle RFDs en de andere FFDs, terwijl een RFD enkel kan communiceren met

een FFD (zie Figuur 2.2).

Aangezien er bij de start van het eindwerk nog geen mogelijkheid was om met deze 802.15.4

standaard te werken, is er gekozen om te werken op de “Simple Media Access Controller”-

implementatie (SMAC) van Freescale. Deze is bruikbaar in combinatie met de “MC13192 De-

veloper’s Starter Kit”(zie Sectie 2.1.4). In Figuur 2.3 zien we het blok diagram.

De SMAC is een deel van de code stack, geschreven in ANSI C. Die kan gebruikt worden om

een applicatie te bouwen, gebruik makend van de radio frequentie capaciteiten. Het doelplatform

is de 8-bit HCS08 microcontroller familie van Freescale Semiconductor.

Enkele eigenschappen van SMAC zijn ondermeer:


Figuur 2.3: Het SMAC Blok diagram

• Compacte code stack, 2K Flash

• Compatibel met de gebruikte MC13192 Developer’s Starter Kit (zie Sectie 2.1.4)

• Bi-directionele RF communicatie link

• Tot 123 bytes data in een pakket (de pakketgrootte is 127 bytes, de header is 4 bytes

groot)

• Geen retransmissies

2.1.3 ZigBee

De ZigBee Alliance is een groepering van bedrijven en instituten die de drijvende kracht vormen

achter de ZigBee specificatie. Momenteel telt dit consortium reeds meer dan 150 leden. De

keuze voor de naam “ZigBee” is afkomstig uit de bijenwereld. In een bijenkolonie is er een

koningin, enkele darren en vele duizenden ijverige werksters. Om te overleven is het nodig dat

er voortdurend belangrijk informatie naar elkaar wordt gecommuniceerd. Hiervoor gebruiken ze

een speciale techniek, de danstaal. De bijen dansen in een zig-zag patroon om op die manier

informatie door te geven, zoals de lokatie, afstand en richting van nieuw gevonden voedsel.

Dankzij deze snelle communicatievorm weten vele bijen in korte tijd waar de nectar op hun

wacht.

Die snelle communicatie is een typisch kenmerk van de ZigBee specificatie, die sinds 14 de-

cember 2004 geratificeerd werd (versie 1.0). Hoewel deze specificatie niet openbaar is, kunnen we

toch enkele karakteristieken meegeven [Zig04]. De logische types van toestellen zijn hier ZigBee


Coordinator (ZC), ZigBee Router (ZR) of ZigBee Eindtoestel (ZED) (zie Figuur 2.4).

ZigBee Coordinator:

• Maximum een per netwerk;

• Zorgt voor de initialisatie van het netwerk;

• Fungeert als een 802.15.4 PAN coordinator (FFD);

• Eens het netwerk gevormd is kan deze functioneren als een ZigBee Router.

ZigBee Router:

• Optionele netwerk component;

• Kan zich associeren met een ZC of een reeds geassocieerde ZR;

• Fungeert als een 802.15.4 coordinator (FFD);

• Het doel is om berichten te routeren.

ZigBee Eindtoestel:

• Optionele netwerk component;

• Types kunnen zich niet associeren met een ZED;

• Typisch een RFD;

• FFD kan ook als eindtoestel fungeren;

• Zal geen berichten routeren.

Dankzij deze indeling in logische types is het mogelijk om ad-hoc netwerken te creeren, waar-

bij zowel mesh-, cluster tree- als ster-topologieen tot de mogelijkheden behoren. Deze netwerken

kunnen betrouwbaar gegevens uitzenden, maar er is geen “Quality of Service”. De stertopologie

is de meest eenvoudige vorm. Hierbij vormt een van de nodes het centrale knooppunt. Daar waar

behoefte is aan een groot netwerk worden veelal diverse sternetwerken aan elkaar gekoppeld, wat

resulteert in een cluster-treenetwerk. Beide topologieen hebben als nadeel een of meerdere “sin-

gle point of failures” te herbergen, namelijk de centrale node(s). In omgevingen waar een hoge

betrouwbaarheid wordt geeist kan dan ook het best een meshnetwerk worden ingericht. Een


Figuur 2.4: Een voorbeeld van een netwerkconfiguratie

dergelijk netwerk biedt namelijk de mogelijkheid van alternatieve routes. In dat geval kan een

netwerk, op het moment dat een link uitvalt, toch grotendeels blijven functioneren. Daarnaast

is een dergelijk netwerk in staat, in het geval dat een knooppunt is verwijderd of uitvalt, zichzelf

te herconstrueren.

Beveiliging en data-integriteit vormen uiteraard belangrijke aspecten in een netwerkarchi-

tectuur. De 802.15.4 media access-laag voorziet in een aantal beveiligingsdiensten. Dit model

specificeert ondere andere dat het AES encryptie algoritme moet gebruikt worden, met een sleu-

tel van 128 bit. Daarnaast wordt er ook gebruik gemaakt van een frame teller, waardoor het

mogelijk is om de authenticiteit van een bericht te garanderen.

Een uitgebreide bespreking van de ZigBee standaard (bijvoorbeeld de routeringsprotocollen

AODV [RP00] en cluster tree [Cal01]) zou ons te ver leiden, daarom laat ik u liever kennismaken

met enkele domeinen waar ZigBee-oplossingen actief kunnen zijn:

• domotica;

• een draadloos netwerk van rook- of CO-detectoren;

• meterstanden in een appartementsgebouw verzamelen;

• medische informatie verzamelen, zodat de patient zich vrij kan bewegen;

• proces controle;

• . . .


In deze lijst ontbreekt minstens een toepassingsdomein, en dat zijn de contextgevoelige appli-

caties. Dankzij de hardware modules uit de gebruikte kit kunnen we zo een applicatie bouwen.

In Sectie 2.2 komt dit aan bod.

2.1.4 Gebruikte kit

Er wordt gewerkt met de MC13192 Developer’s Kit van Freescale Semiconductor. Elke kit bevat

twee 2,4 GHz modules (zie Figuur 2.5) die compatibel zijn met de IEEE 802.15.4 standaard. De

modules zelf beschikken over:

• een MC13192 2,4 Ghz RF data modem;

• een MC9S08GT60 8-bit microcontroller;

• geıntegreerde sensoren ( X-,Y- en Z-as);

• geprinte zenden ontvangstantennes;

• Background Debug Module (BDM) poort om de microcontroller te herprogrammeren

(Flash);

• RS-232 poort, geschikt voor zowel monitoring als Flash herprogrammeren;

• 4 leds en 4 drukknoppen;

• een aansluiting voor een 9V-batterij of externe voeding via de adapter.

De MC13192 2,4 Ghz RF data modem is instelbaar op 16 kanalen, tussen 2405 MHz en 2480

MHz. Het zendvermogen is typisch 0 dBm, maar is ook instelbaar. Uit de datasheet halen we

dat de packet error rate 1,0% bedraagt. Dit komt later nog aan bod.

De aanwezige microcontroller behoort tot de HCS08 familie. Dit type heeft 60K herpro-

grammeerbaar Flash geheugen en 4K RAM. Naast de twee seriele communicatie interface (SCI)

modules zijn er ook twee 2-kanaals 16-bit timers ter beschikking. Wie de uitgebreide specificatie

wil lezen, kan daarvoor [Sem04] raadplegen.

Samen met de meegeleverde “MetroWerks CodeWarrior Development Studio for HCS08 spe-

cial edition v3.1” kunnen we aan de slag om de nodige firmware te schrijven. Deze speciale editie

beperkt een project tot maximaal 32 bestanden en 16K broncode. De documentatie van de kit

beloofde dat het mogelijk was om de modules te flashen door middel van een seriele kabel. Dit

werd dan ook vol enthousiasme geprobeerd. Echter, hiervoor dient er reeds een zogenaamde


Figuur 2.5: De 802.15.4 hardware module

“Embedded Bootloader” aanwezig te zijn op de modules. Na contact met Freescale bleek dat

men kan testen of deze al dan niet aanwezig is door de module te resetten. Indien dan alle leds

branden, is er een embedded bootloader aanwezig. Dit was niet het geval bij de meegeleverde

modules.

We moeten dus gebruik maken van de BDM-poort. Hiervoor werd de “P&E Background

Debug Module Multilink cable” (USB HCS08/HCS12 Multilink - USB port) aangekocht. Dit

is een programmer die op de host aangesloten wordt via USB en op de module via een 6-pins

connector. Op de bijgevoegde CD-ROM bevindt zich een overzichtelijke stap voor stap gids.

Tijdens het testen van de geschreven firmware werd snel duidelijk dat het na een bepaalde

tijd onmogelijk was om nog een bericht te versturen naar de seriele poort. Die tijd bedroeg altijd

30 s nadat het eerste bericht werd verstuurd. Uiteindelijk werd de oorzaak gevonden. De chip

die de seriele communcicatie van de modules verzorgt, is de MAX3318E. Deze beschikt over een

zogenaamde “AutoShutdown Plus” mode. Deze functie zorgt ervoor dat de chip slechts 1 µA

2.2 Werk verricht 12

verbruikt in het geval er geen RS-232 kabel is aangesloten of indien de verzender gedurende

30 s niets verstuurd naar de modules. Om deze slapende chip wakker te maken, moeten we een

gepast signaal sturen. Dit signaal bestaat uit een byte met als meest beduidende bit 1 (Little

Endian). We sturen nu altijd eerst deze wake-up-byte, om er zeker van te zijn dat het bericht

goed wordt ontvangen.

2.2 Werk verricht

Hier bespreken we enerzijds de firmware die werd geschreven voor de modules. De meeste tijd

werd hier aan gespendeerd. Om deze firmware te testen werd anderzijds de toolkit applicatie

uitgebreid met extra forms.

2.2.1 Programma: de hardware modules

We beginnen de bespreking van het verrichte werk met de firmware voor de hardware modules.

Als leidraad doorheen het overzicht beschouwen we twee use cases. De hoofdbedoeling van

dit eindwerk is het transparanter maken van de CaReport-applicatie, door de naam van de

dichtstgelegen patient aan de verpleegkundige te tonen. De tweede use case omvat het versturen

van bestanden en een tekstgesprek tussen PDA’s. Deze laatste use case is als extra toegevoegd.

Eerste use case

We wensen een systeem dat het mogelijk maakt om te bepalen welke patient zich het dichtst

bij een verpleegkundige bevindt. We onderscheiden twee types, namelijk de verpleegkundigen

en de patienten. De hardware module van de verpleegkundige (VER-module) moet interageren

met zowel de PDA als met de hardware modules bij de patienten (BED-modules). De volgorde

van deze berichtenstroom wordt duidelijk in Figuur 2.6.

De verpleegkundige wil weten wie er in de buurt is, deze verzendt daarom een POLL REQ.

Vanop de PDA wordt dit verstuurd naar de VER-module. De VER-module zal dit POLL REQ

herkennen en als reactie een broadcast LQ REQ-bericht verzenden naar de BED-modules. El-

ke BED-module die een LQ REQ ontvangt zal de linkkwaliteit van het zonet binnengekomen

bericht bepalen. Deze wordt dan teruggestuurd naar de VER-module. Indien echter alle BED-

modules dit tegelijkertijd willen doen, zal er hoogstens 1 antwoord binnenkomen. De reden

hiervoor is dat de SMAC-implementatie geen retransmissies zal uitvoeren indien er een botsing


Figuur 2.6: Het sequentiediagram voor het zoeken van de dichtste patient

is opgetreden. De ontvanger, de VER-module, kan het eerste binnenkomende pakket nog ver-

werken maar de resterende pakketten botsen en gaan verloren. In de praktijk blijkt uiteraard

dat de BED-module die zich het dichtste bij de VER-module bevindt, ook meestal eerst zijn

antwoord kan doorsturen. Op basis van deze reactiesnelheid hebben we dus al een systeem dat

de dichtste patient kan opleveren. We wensen echter een betrouwbaar systeem te bouwen dat een

keuze kan maken tussen alle gemeten linkkwaliteit indicaties. Aangezien de 802.15.4-standaard

wel retransmissies specificeert, is er besloten om niet zelf retransmissies te implementeren. In

de plaats daarvan laten we elke BED-module een vastgelegde tijd wachten. Dit werd hard geco-

deerd en respectievelijk na 3, 9, 15 en 21 ms antwoorden de vier BED-modules. Een mogelijke

uitbreiding bestaat er in dat deze antwoordtijd dynamisch wordt in plaats van hard gecodeerd.

Deze methode kan immers geoptimaliseerd worden door eerst te controleren of er activiteit is op

het kanaal. Er kunnen dan nog altijd botsingen optreden, waarbij we terug komen bij de echte

oplossing: retransmissie van het pakket indien het niet op de bestemming is aangekomen.


Tijdens het zoeken naar de dichtste patient moeten we er dus voor zorgen dat er meer-

dere antwoorden (LQ RESP) doorgestuurd kunnen worden naar de PDA. De ontvanger heeft

hiervoor bij het versturen van het LQ REQ-bericht een timer gestart. Deze zal gedurende 500

ms de antwoorden van de BED-modules kunnen ontvangen en direct doorsturen naar de PDA.

Oorspronkelijk stond de timer ingesteld op 900 ms. Deze is probleemloos verlaagd naar 500 ms

en kan nog verder beperkt worden. Theoretisch is het mogelijk om elke 50 ms een LQ REQ te

versturen. Het is echter onnodig om elke 50 ms een update te krijgen van de linkkwaliteit.

Wanneer nu de timer in de VER-module afloopt wordt nog een “carriage return” (<CR>)

verstuurd, op voorwaarde dat er minstens 1 LQ RESP-bericht is toegekomen. Dit is het signaal

dat ervoor zorgt dat de PDA de binnengekomen antwoorden mag vergelijken. Deze vergelijking

gebeurt op basis van de gemeten linkkwaliteit. Die wordt uitgedrukt in dBm en kan varieren

tussen -20 dBm en -90 dBm. Een linkkwaliteit van -20 dBm wordt opgemeten als de VER-module

en de BED-module zich vlak bij elkaar bevinden. Dankzij deze linkkwaliteit hebben we een

uitstekend instrument in handen om een bepaalde drempel in te stellen. Het verband tussen de

afstand en de linkkwaliteit, en daarmee samenhangend de keuze van een goede drempelwaarde,

wordt onderzocht in Sectie 2.3.

Tweede use case

De tweede use case omvat het versturen van bestanden. Deze functionaliteit kan handig zijn

wanneer een verpleegkundige de taken van een andere verpleegkundige wilt overnemen. In dat

geval moet de informatie van die taak overgedragen worden. Het versturen van bestanden wordt

enkel voorzien tussen twee VER-modules. Figuur 2.7 verduidelijkt het opzet.

De verzender van het bestand verstuurt het eerste bericht. Dit bericht bevat informatie zoals

de bestandsgrootte en de bestandsnaam. De ontvanger heeft nu de keuze om dit te accepteren

of te weigeren. Deze keuze zit in het FileTransfer RESP-bericht dat teruggestuurd wordt naar

de verzender. In het geval van een positief antwoord, wordt het bestand in blokken van 117

bytes verstuurd. Het maximum aantal bytes per totaal pakket bedraagt 127 bytes. Dit omvat

de headers (4 bytes) en het data-payload (123 bytes) veld. In het data-payload veld gebruiken

we twee keer 2 bytes voor de verzender en ontvanger aan te duiden. Een byte wordt gebruikt

voor de bericht-identificatie en een laatste byte voor de <CR>. Zo houden we 117 bytes over

voor de data die we wensen te versturen. Elk aangekomen blok moet bevestigd worden met een

ACK, gevolgd door het nummer van het blok. De verantwoordelijkheid voor het interpreteren

van het FileTransfer RESP-bericht en de ACK-berichten ligt bij de bovenliggende applicatie. De


Figuur 2.7: Het sequentiediagram voor de bestandsoverdracht

modules zullen enkel doorsturen wat er binnnenkomt op de RS-232 poort en de radio interface,

aan de hand van de identificatie in het bericht. Elk bericht dat via de RS-232 poort binnenkomt

moet afgesloten worden met een <CR>. Dit is immers het teken voor de module om de bin-

nengekomen gegevens te interpreteren. Indien er zich echter een <CR>-byte in het te verturen

bestand bevindt, zal de module foutief denken dat er een volledig bericht is binnengekomen.

De PDA-applicatie moet hier rekening mee houden en de oplossing hiervoor is “bytestuffing”.

Aangezien de <CR>-byte een verboden teken is (behalve op het einde van het bericht) moeten

we dit vervangen door twee andere bytes. De eerste byte is het zogenaamde escape-teken. De

ontvanger weet nu dat de volgende byte moet omgezet worden, volgens een vastgelegd schema.

Als gevolg van deze oplossing moeten we ook het escape-teken zelf vervangen. De keuze van

het escape-teken moet dus weloverwogen zijn. De letter “e” is bijvoorbeeld een slechte keuze,

aangezien deze veel in tekstbestanden voorkomt. Een minder voorkomend teken is de tilde “∼”.

De verboden tekens, hier Carriage Return en de tilde, worden bij de verzender omgezet volgens


het volgende schema. Bij elke verboden byte tellen we een vast getal op. Deze nieuwe byte wordt

na het escape-teken verstuurd. De ontvanger hoeft nu enkel de byte volgend op het escape-teken

te verminderen met dit vast getal. We zorgen ervoor dat dit optellen van een vast getal bij een

bepaald verboden teken geen ander verboden teken oplevert. Hetzelfde mechanisme wordt even-

eens toegepast bij een tekstgesprek. Er is een type-veld voorzien in het FileTransferInit-bericht.

Hierdoor kunnen we aan de ontvanger duidelijk maken of het gaat om een bestandsoverdracht

of een tekstgesprek. De ontvanger zal in het geval van een tekstgesprek de tekst tonen aan de

gebruiker. In het geval van bestandsoverdracht moeten de ontvangen blokken data samengesteld

worden in een nieuw bestand.

Bespreking programmastructuur

Nu we weten wat er allemaal mogelijk is volgt een toelichting bij de geschreven firmware. Na

de nodige initialisaties bestaat het hoofdprogramma uit een oneindige for-lus. In deze for-lus

is er een switch-statement (zie Figuur 2.8). Dit zal ervoor zorgen dat telkens de juiste stukken

code worden uitgevoerd, afhankelijk van de huidige applicatie status. Na de afhandeling van

een applicatie status wordt er telkens gecontroleerd of er een volledig bericht is binnengekomen

via de seriele poort. Een volledig bericht wordt steeds afgesloten door een <CR>. Wanneer

deze wordt gededecteerd plaatsen we een vlag hoog en veranderen we de applicatie status naar

RX STATE PDA2VER.

Hoe kunnen we nu bepalen welke applicatie status er moet uitgevoerd worden? In elk bericht

is er een veld voorzien waarin men een bericht-identificatie kan plaatsen. De module voor wie het

bericht bestemd is zal op basis van deze bericht-identificatie de juiste applicatie status uitvoeren.

Deze berichten kunnen zowel via de RS-232-poort als via de radio interface binnenkomen.

• Zoals reeds eerder gezegd werken we met een vlag die wordt gezet als er een volledig be-

richt via de seriele poort is binnengekomen. Een bericht wordt door de module byte per

byte verwerkt door middel van een interruptroutine. Omdat we pas een bericht verwerken

nadat het volledig binnen is, slaan we alle binnengekomen bytes op in een ringbuffer. Een

ringbuffer is een structuur die de maximale grootte bevat, een pointer naar een buffer en

twee wijzers. De leeswijzer houdt bij welke byte mag gelezen worden en de schrijfwijzer

zal de plaats aanduiden waar geschreven mag worden. Indien de maximum grootte be-

reikt is wordt terug de eerste byte gelezen of overschreven. Men kan deze ringbuffer nog


for ( ; ; ) {

switch ( a p p l i c a t i e s t a t u s ){

case INITIAL STATE VER :

// e e r s t e s t a t u s na r e s e t

case RX STATE PDA2VER:

// verwerk t binnengekomen b e r i c h t

case . . . :

//nog andere s ta tu s sen , z i e verder

}

i f ( datav lag ){

a pp l i c a t i e s t a t u s = RX STATE PDA2VER;

}

}

Figuur 2.8: Programmastructuur

optimaliseren door per byte een vlag bij te houden. Deze vlag zetten we dan op 1 indien

er geschreven wordt, en op 0 indien deze uitgelezen worden. Er mag in de ringbuffer ge-

schreven worden als de vlag waar de schrijfwijzer naar wijst op 0 staat. De ringbuffer is

vol zolang alle vlaggen op 1 staan.

• Om berichten via de radio interface te ontvangen moeten we de module laten luiste-

ren. Elke module zal standaard luisteren naar berichten die via de antenna kunnen

binnenkomen. Dit kan enkel tijdelijk onderbroken worden door de interruptroutine van

de seriele poort. Nadat deze afgehandeld is wordt er terug geluisterd op de radio in-

terface. Een binnenkomend pakket wordt afgehandeld door de callback-functie “MC-

PS data indication(rx packet t *rx packet)”. Deze zal het pakket analyseren indien de

status “succes” is. In het geval van “overflow” of “time-out” wordt het pakket genegeerd

en luisteren we opnieuw. De callback-functie heeft als voornaamste functie het doorsturen

van de inkomende berichten naar de PDA.

De verschillende applicatie statussen worden telkens kort toegelicht. We beginnen met deze

van de VER-module:


• INITIAL STATE VER

Preconditie: Tijdens het aanzetten van de module houden we drukknop 1 of 4 ingedrukt.

Postconditie: De applicatie status is RECEIVER ALWAYS ON.

Doel: Deze staat zorgt ervoor dat we ons ervan kunnen vergewissen dat dit een VER-

module is. Indien de initialisatie correct verlopen is zien we alle leds een na een branden.

• RX STATE PDA2VER

Preconditie: Er is een volledig bericht binnengekomen op de seriele poort. De datavlag is

gezet.

Postconditie: Indien het bericht voor deze module was wordt het verwerkt. Nadien keren

we terug naar RECEIVER ALWAYS ON.

Doel: Deze staat verwerkt de berichten die binnenkomen via de seriele poort. Deze seriele

poort kan door middel van een Bluetooth-convertor draadloos gekoppeld worden aan de

PDA. Typisch bestaat een bericht uit: Wake-up, ZB, Eigen Adres, bericht-identificatie,

berichtspecifieke info. Wanneer het een bericht voor deze module was, dan wordt aan de

hand van de bericht-identificatie de berichtspecifieke informatie verder verwerkt.

• TX STATE VER

Preconditie: Er is een bericht-identificatie uit een serieel bericht gehaald.

Postconditie: De applicatie status is RECEIVER ALWAYS ON, behalve in het geval van

een LQ REQ. Dan is de nieuwe applicatie status WAITING FOR RSSI RESP FROM BED.

Doel: Op basis van de bericht-identificatie worden de gepaste pakketten verstuurd. Dit

kan bijvoorbeeld een POLL REQ zijn. In dit geval wordt ook de timer gestart.

• WAITING FOR RSSI RESP FROM BED

Preconditie: Er werd een LQ REQ verstuurd vanuit TX STATE VER.

Postconditie: Indien de timer verlopen is wordt de nieuwe applicatie status CR VER-

STUREN.

Doel: Zolang de timer loopt zal deze staat luisteren naar berichten die binnenkomen op

de radio interface.


• CR VERSTUREN

Preconditie: De timer is verlopen in WAITING FOR RSSI RESP FROM BED

Postconditie: De applicatie status is RECEIVER ALWAYS ON.

Doel: Deze staat zal de afsluitende Carriage Return versturen naar de PDA.

• RECEIVER ALWAYS ON

Preconditie: Verschillende staten hebben als postconditie RECEIVER ALWAYS ON.

Postconditie: Afhankelijk van het binnengekomen pakket.

Doel: Deze staat zal op de radio interface luisteren naar binnenkomende pakketten.

Dit zijn de belangrijkste applicatie statussen bij de BED-module:

• INITIAL STATE BED

Preconditie: Tijdens het aanzetten van de module houden we drukknop 2 of 3 ingedrukt.

Postconditie: De applicatie status is RX STATE BED.

Doel: Deze staat zorgt ervoor dat we ons ervan kunnen vergewissen dat dit een BED-

module is. Indien de initialisatie correct verlopen is zien we alle leds tegelijkertijd branden.

• RX STATE BED

Preconditie: Er is een bericht-identificatie uit een pakket gehaald.

Postconditie: Afhankelijk van het binnengekomen pakket.

Doel: Deze staat zal op de radio interface luisteren naar binnenkomende pakketten.

• BROADCAST ONTVANGEN

Preconditie: Er is een bericht-identificatie uit een pakket gehaald.

Postconditie: De linkkwaliteit wordt teruggestuurd naar de verzender van het pakket en

de nieuwe applicatie status is RX STATE BED

Doel: Deze staat zal de linkkwaliteit meten en na een vastgelegde tijd terugsturen.

De verschillende applicatie statussen van de VER- en BED-module bevonden zich in het

begin in een gezamelijk project. Op die manier zat de volledige code voor alle type modules


steeds in elke geprogrammeerde module. Door middel van de juiste drukknop konden we dan

overschakelen van VER naar BED-module. Na enkele weken testen bleek de VER-module in

een toestand van de BED-module te komen. Normaal gezien is dit onmogelijk, dus werd dit

onderzocht. Nadat de code opgesplitst werd in twee aparte project, bleef de module onverklaar-

baar gedrag vertonen. Uiteindelijk bleek dat de microcontroller zichtzelf altijd resette, omdat

het niveau van de batterij te laag was. Als gevolg van dit verschijnsel werd het project onnodig

opgesplitst. Dit is zo gebleven tijdens de rest van het werk, maar is niet noodzakelijk. Men kan

trouwens deze eigenschap van de microcontroller gebruiken om de modules een signaal te laten

uitzenden wanneer het batterij-niveau onder een bepaalde drempel daalt.

2.2.2 Programma: de .Net Compact Framework toolkit

Nu de firmware voor de hardware modules beschreven is kunnen we overgaan naar de bovenlig-

gende applicatie. Deze applicatie werd geschreven in Visual C#, gebruikmakend van het .Net

Compact Framework (.Net CF) Het .Net CF is een afgeslankte versie van het volledige .Net

Framework.

De applicatie heeft tot doel de geschreven firmware te testen. Een basisvereiste is de commu-

nicatie met deze hardware modules. Hiervoor werd een seriele bibliotheek gebruikt (NETSerial),

die aan onze noden werd aangepast door Wim Vandenberghe [Van05]. Dankzij deze bibliotheek

kunnen we de poortinstellingen wijzigen naar wens. De hardware modules versturen immers

gegevens aan een maximale baudrate van 38400 zonder pariteit en met 1 stopbit.

De abstracte DeviceCom klasse maakt gebruik van deze NETSerial bibliotheek om een poort

te openen met de gewenste instellingen. Dit gebeurt echter in het afgeleide ZigBeeCom-object.

Tijdens het testen via de Pocket PC 2003-emulator gebruiken we poort 1 of 2.

Eens de communicatie is opgezet kunnen we gegevens versturen en ontvangen. De toolkit

werd hiervoor uitgebreid met een aantal extra forms, die technologie specifiek zijn. De basisforms

zijn nr. 1 t.e.m. 4.

1. Poll Reader: Een manuele poll of een periodieke poll volgens een interval tussen 1000 ms en

3000 ms is mogelijk. Enkel de gevonden modules worden weergegeven, zonder aanduiding

van de linkkwaliteit.

2. Test Non-Response: Dit is een testform om te bepalen hoe vaak er geen antwoord binnen-

komt op een periodiek uitgestuurde poll.

2.3 Analyse van de proeven 21

3. Test Battery Life: Dankzij dit form kunnen we een tijdmeting verrichten om te bepalen

hoe lang de hardware module op batterijen kan blijven werken.

4. Visual Demo: Dit is een visuele demo waarbij een prentje getoond wordt in plaats van de

nummers van de hardware modules.

5. Link Quality: Dit bevat dezelfde functionaliteit als Poll Reader, echter nu met aanduiding

van de gemeten linkkwaliteit.

6. Test LQ-Distance: Dit is een uitbreiding van het Link Quality-form. Hier is het mogelijk

om de horizontale en vertikale afstand tussen twee modules in te geven. Na een test kunnen

we dan alle gegevens bewaren in een tekstbestand.

7. Change Power Settings: Hiermee wordt het vermogen van de VER-modules aangepast.

8. ZigBee File Transfer: Nadat een bestand gekozen is kan dit via de radio interface verstuurd

worden. Dit form is niet volledig afgewerkt.

Met behulp van deze toolkit kunnen we enkele proeven doen, waarvan de resultaten in de

volgende sectie worden geanalyseerd. Voor de uitbreiding van de CaReport-applicatie wordt

verwezen naar hoofdstuk 5.

2.3 Analyse van de proeven

De firmware en de toolkit laten ons nu toe om het geheel te testen. Bij elk testscenario zal een

beschrijving van de testopstelling gegeven worden. In eerste instantie zal het foutenpercentage

getest worden. Een mogelijke fout wordt gedefinieerd als het niet toekomen van een antwoord op

de PDA. De mogelijke oorzaken van deze fouten worden tevens onderzocht. Bij het testen van

het foutenpercentage zullen we eerst een aantal proeven doen door de applicatie in de Pocket PC

2003-emulator te draaien. De VER-module wordt dan via een seriele kabel verbonden met de PC.

In tweede instantie wordt de mobiele oplossing getest. Hiervoor beschikken we over een PDA met

een Bluetooth interface. We koppelen nu een Bluetooth-convertor aan de VER-module. Van op

de PDA worden de berichten nu via Bluetooth verstuurd, die door de Bluetooth-convertor serieel

worden doorgestuurd naar de VER-module. Aangezien zowel Bluetooth als ZigBee in de 2,4 GHz

band actief zijn, is het te verwachten dat deze elkaar kunnen storen. Nadien concentreren we

ons op het verband tussen de gemeten linkkwaliteit en de afstand. Afhankelijk van de omgeving


en de positie van de modules zal dit een verschillend resultaat opleveren. Bij deze proeven zal

ook de invloed van het zendvermogen van de VER-modules onderzocht worden. Vervolgens

wordt er getest hoe lang een BED-module kan antwoorden, indien deze gevoed wordt door een

9V-batterij. De invloed van een microgolfoven wordt onderzocht in Sectie 4.3.

2.3.1 Foutenpercentage

Met deze proeven willen we weten hoe betrouwbaar het geheel is. Er wordt bijzondere aandacht

geschonken aan het moment waarop een fout optreedt. Indien er op een bepaald ogenblik in

de tijd een fout aanwezig is, zal deze dan een reeks van fouten als gevolg hebben? We vragen

ons ook af of de frequentie van het aantal LQ REQ-berichten een invloed heeft op de prestaties.

Tijdens de proeven wordt er afwisselend getest met een interval van respectievelijk 1, 2 en 3 s.

Ook het effect van de timerinstelling van de VER-module wordt onderzocht.

Scenario 1: Invloed timer

Als eerste proef testen we het geheel zonder gebruik te maken van de Bluetooth-convertor. We

sluiten een VER-module aan op de computer via een seriele kabel. Er wordt 1 BED-module

aangezet. Via de emulator tellen we het aantal onbeantwoorde poll-berichten. De timer in

de VER-module staat eerst ingesteld op 900 ms, nadien op 500 ms. Na deze termijn wordt

de <CR> doorgestuurd. Elke 2000 ms wordt een nieuw poll-bericht verstuurd. Afhankelijk

van de timer instelling heeft de PDA-applicatie dus respectievelijk 1100 ms en 1500 ms de tijd

om de binnengekomen antwoorden te verwerken. Dit scenario werd uitgevoerd op een vlakke

ondergrond.

We bespreken de resultaten voor beide timerintervals bij 1900 verstuurde poll-berichten. De

gemiddelde fout in Tabel 2.1 bij een timerinterval van 900 ms bedraagt 0,74%. Per duizend

verstuurde berichten kunnen we dus 7,4 fouten verwachten. Indien we echter fout 16 bekijken,

dan zien we dat deze pas optreedt nadat er 910 poll-berichten probleemloos werden beantwoord.

De eerste 8 fouten daarentegen vinden plaats in een interval van nog geen 700 opeenvolgende

poll-berichten. Een eerste bemerking die we kunnen maken is dat het optreden van een fout

onvoorspelbaar is. De gemiddelde fout is slechts een indicatie en geen bewijs dat er per duizend

verstuurde berichten ook effectief 7,4 fouten zullen zijn.

Bij de tweede proef van scenario 1 werd de timer in de VER-module verlaagd van 900 ms

naar 500 ms. Het geconstateerde foutenpercentage, na 1900 poll-berichten, bedraagt 0,53%. We

merken opnieuw op dat het tijdstip waarop een fout plaatsvindt onvoorspelbaar is. Na 1900


Tabel 2.1: Scenario 1: Timer variabel, Interval 2000 ms, Serieel

Fouten Aantal verstuurde poll-berichten

Timer: 900 ms Timer: 500 ms

0 209 70

1 210 71

2 340 165

3 360 219

4 462 657

5 502 1487

6 553 1722

7 592 1765

8 682 1780

9 723 1863

10 807 1900

14 1900 -

15 2150 -

16 3060 -

opeenvolgende poll-berichten is er bij een timerinterval van 900 ms een foutenpercentage van

0,74%. Aangezien er geen vast terugkerend patroon is bij herhaaldelijke testen sluiten we uit

dat er bug in de geschreven code zit. Immers, tussen elke proef worden de modules gereset.

Indien er een bug in de firmware zou zitten, dan moet deze telkens terugkeren na hetzelfde

aantal poll-berichten. Uit deze twee proeven blijkt dat dit niet het geval is. Aangezien dit

onregelmatig optreden van een fout blijft voorkomen, laten we een gedetailleerd overzicht in de

volgende scenario’s weg. Enkel het gemiddeld foutenpercentage zal vermeld worden.

Scenario 2: Invloed interval

In het tweede scenario wordt de Bluetooth-convertor nog altijd niet gebruikt. We sluiten opnieuw

een VER-module aan op de computer via een seriele kabel en er wordt slechts 1 BED-module

aangezet. Via de emulator tellen we het aantal onbeantwoorde poll-berichten. We varieren nu

het interval, dit staat achtereenvolgens ingesteld op 3000, 2000, 1600 en 1000 ms. De timer in

de VER-module staat nu vast ingesteld op 500 ms. Dit scenario werd uitgevoerd op een vlakke


ondergrond en per interval werd de meting twee keer uitgevoerd. Er werd telkens tussen de 50

en 100 minuten getest, vandaar het wisselend aantal poll-berichten per test.

Tabel 2.2: Scenario 2: Timer 500 ms, Interval variabel, Serieel

Interval (ms) Fouten Aantal Gem. percentage

3000 12 1006 1,19%

3000 22 2413 0,91%

Totaal 34 3419 0,99%

2000 10 2019 0,50%

2000 67 3340 2,01%

Totaal 77 5359 1,43%

1600 17 4004 0,42%

1600 16 3678 0,44%

Totaal 33 7682 0,43%

1000 59 2826 2,09%

1000 14 5000 0,28%

Totaal 73 7826 0,93%

Indien we alle resultaten optellen, onafhankelijk van de ingestelde intervalwaarde komen we

aan een foutenpercentage van 0,83%(243 fouten op 29263 poll-berichten). Het valt op dat er bij

een interval van 2000 ms de ene keer 0,50% en de andere keer 2,01% fout loopt. In de tweede

proef (Tabel 2.1) van scenario 1 haalden we een foutenpercentage van 0,53%. Indien we bij elke

intervalwaarde enkel het beste resultaat in rekening brengen, dan merken we een merkwaardige

dalende trend op. Het aantal fouten vermindert wanneer de poll-frequentie verhoogt. Dit mag

echter geen besluit zijn. Bij een intervalwaarde van 1000 ms noteren we immers twee extreme

waarden, namelijk 2,09% en 0,28%.

Er zijn enkele mogelijke oorzaken voor het optreden van de fouten:

1. De VER-module verstuurt niet altijd een LQ REQ naar de BED-modules.

2. De VER-module verstuurt altijd een LQ REQ naar de BED-modules, maar deze worden

niet correct ontvangen door de BED-modules.

3. De BED-modules versturen niet altijd een LQ RESP naar de VER-module.


4. De BED-modules versturen altijd een LQ RESP naar de VER-module, maar deze worden

niet correct ontvangen door de VER-module.

In het geval van 1 en 3 zou er een vast patroon in het optreden van de fouten moeten zitten.

Dit is echter niet het geval, dus als mogelijke oorzaken blijven punt 2 en 4 over. We hebben dus

te maken met een radio interface die niet alle pakketten probleemloos aflevert. In de datasheet

van deze radio interface lezen we dat er een “packet error rate” van 1,0% is. Hierbij komt het

feit dat het gebruikte channel access mechanisme enkel zal proberen botsingen te vermijden,

deze worden niet gededecteerd. Het gemiddeld foutenpercentage van alle proeven in scenario

1 en 2 bedroeg 0,83%. Men zou dit percentage kunnen doen dalen door zelf retransmissies te

implementeren. Indien een bepaald bericht dan niet bevestigd wordt door een ACK, verstuurt

men dit bericht opnieuw. De huidige implementatie is te vergelijken met UDP. Immers, een

verloren bericht wordt niet opnieuw verzonden.

Scenario 3: Invloed twee BED-modules

In de twee voorgaande scenario’s werd telkens slechts 1 BED-module aangezet. In dit scenario

zullen we twee BED-modules aanzetten. Het interval bedraagt 1000 ms en de timer staat nog

steeds ingesteld op 500 ms. Deze proef werd gedurende een periode van meer dan 11 uur

uitgevoerd. Dit is ondere andere om te testen of het geheel blijft werken, zonder te resetten.

Na bijna 42000 opeenvolgende poll-berichten is het foutenpercentage 0,40%. Indien we de

uitschieter van 0,28% in het vorige scenario buiten beschouwing laten is dit het laagste resultaat

tot nu toe. Zoals reeds in het begin gesteld, beschouwen we een fout als het niet toekomen

van een antwoord op de PDA. Aangezien er nu twee BED-modules een antwoord kunnen stu-

ren, is de kans kleiner dat beide BED-modules tegelijkertijd geen antwoord doorsturen naar de

VER-module. Verder valt het op dat er vanaf poll-bericht 5900 tot bericht 10400 geen enkele

bijkomende fout is opgetreden. Er werden dus 4500 opeenvolgende poll-berichten beantwoordt

door minstens 1 BED-module.

Om het geheel mobiel te maken vervangen we de seriele kabel door een Bluetooth-convertor.

We koppelen de Bluetooth-convertor via een seriele kabel aan de module van de verpleegkundige.

De poll-berichten worden nu via Bluetooth verstuurd vanop de PDA. Dankzij deze convertor

kunnen we een Bluetooth-verbinding omzetten naar een signaal geschikt voor de seriele kabel,

die verbonden is met de VER-module. Dit is een tussenoplossing, omdat er nog geen ZigBee

uitbreidingskaarten voor de PDA beschikbaar zijn. Er zijn wel al prototypes, maar deze zijn nog


Tabel 2.3: Scenario 3: Timer 500 ms, Interval 1000 ms, Serieel, Twee bed-modules

Fouten Aantal Gem. percentage

0 1500 0%

1 1650 0,06%

2 1785 0,11%

3 1860 0,16%

4 1950 0,21%

5 1980 0,25%

6 2680 0,22%

7 2690 0,26%

8 5900 0,14%

9 10401 0,09%

167 41707 0,40%

168 41750 0,40%

niet op de markt verschenen. Er werd opgemerkt dat het foutenpercentage niet veel verhoogt

(0,45%). De invloed van een externe, continue Bluetooth-verbinding op dit foutenpercentage

wordt besproken in 4.2.

2.3.2 Verband tussen de linkkwaliteit en de afstand

Met deze proeven zoeken we een verband tussen de linkkwaliteit en de afstand. We vragen ons

af wat de invloed van het zendvermogen van de VER-module hierop is (scenario 4). Tevens

verwachten we dat de omgeving een belangrijke rol speelt bij het meten van de linkkwaliteit

(scenario 5). De linkkwaliteit wordt immers opgemeten bij de BED-modules, op basis van

het laatst binnengekomen pakket. Men kan verwachten dat de positie en de omgeving van de

modules een invloed hebben op de linkkwaliteit.

Scenario 4: Invloed van het zendvermogen van de VER-module

Beide use cases vereisen een verschillend bereik van de modules. Bij het zoeken naar een

patient is het voldoende dat de VER-module een bereik heeft van ongeveer 4 m. Op die manier

ontvangen de BED-modules die buiten dit bereik liggen geen POLL REQ (afhankelijk van het

bereik van de BED-modules). Voor het versturen van een bestand naar bijvoorbeeld de centrale


server, wensen we een groter bereik in te stellen. Hiervoor moet het mogelijk zijn om minstens

10 m te overbruggen. De hardware modules laten toe om dit zendvermogen in te stellen. Het

zendvermogen van de VER-module kan ingesteld worden tussen -16 dBm en ± +4 dBm.

In een eerste proef zullen we 1 VER-module en 1 BED-module op 50 cm boven de grond

plaatsen. Deze worden telkens met de antenne naar elkaar gepositioneerd, op een rechte lijn.

We beperken de metingen tot een afstand van 2 m, waarbij elke 10 cm de linkkwaliteit vier keer

wordt opgemeten. We letten er op dat er zich tijdens de metingen niemand tussen, of in de

buurt van, de twee modules bevindt. We testen het verband voor respectievelijk -16 dBm, -10

dBm, 0 dBm en +4 dBm (Figuur 2.9).

Figuur 2.9: Scenario 4: De linkkwaliteit i.f.v. het zendvermogen en de afstand, op 50 cm boven de grond

We zien duidelijk een invloed van het ingestelde zendvermogen op de gemeten linkkwaliteit.

Zoals verwacht is de gemeten linkkwaliteit lager indien het zendvermogen verlaagd is. Het is

gebleken dat de linkkwaliteit informatie zeer stabiel is. Immers, de gemiddelde standaarddevi-

atie bedraagt slechts 0,11 dBm. Dit maakt het mogelijk om proximity-cellen in te stellen rond

een module. Met deze proximity-cellen willen we het bereik beperken, zodat BED-modules op

10 m afstand van een verpleegkundige geen antwoord versturen. Het is echter wel noodzake-

lijk dat alle BED-modules dezelfde instellingen hebben. Op de PDA worden de linkkwaliteiten

immers vergeleken met een bepaalde drempelwaarde. Stel dat twee naburige BED-modules een


verschillende instelling hebben quai zendvermogen. Deze zullen dan een verschillende linkkwali-

teit rapporteren aan de VER-module, die zich op gelijke afstand van de BED-modules bevindt.

Verschillende instellingen bij de BED-modules leveren dus onbruikbare resultaten op.

Het valt wel op dat het verschil tussen 0 en +4 dBm miniem is. Omdat we echter het

bereik willen beperken in plaats van vergroten is dit niet belangrijk. Tevens zien we dat, over

alle verschillende zendvermogens heen, het verband tussen de afstand en de linkkwaliteit een

gelijkaardig patroon vertoont. Dit maakt het mogelijk om een bepaalde drempel waarde in te

stellen. Indien de gemeten linkkwaliteit zich boven deze drempel bevindt, dan kunnen we stellen

dat de verpleegkundige in de buurt van de patient is. In het volgende scenario wordt de invloed

van de positie van de modules onderzocht.

Scenario 5: Invloed van de positie van de modules

In deze proef zullen we 1 VER-module en 1 BED-module op een houten ondergrond leggen. Deze

worden opnieuw met de antenne naar elkaar gepositioneerd, op een rechte lijn. We beperken de

metingen tot een afstand van 2 m, waarbij elke 10 cm de linkkwaliteit vier keer wordt opgemeten.

We letten er op dat er zich tijdens de metingen niemand tussen, of in de buurt van, de twee

modules bevindt. We testen het verband met een vast zendvermogen van 0 dBm. De resultaten

van deze proef worden vergeleken met de resultaten uit scenario 4, waarbij de modules zich op

een afstand van 50 cm boven de grond bevonden.

De resultaten in Figuur 2.10 worden nu besproken. We merken op dat de positie van de

modules wel degelijk een invloed heeft op linkkwaliteit. We kunnen dit verklaren doordat ener-

zijds het zendpatroon van de antenne wordt verstoord en anderzijds er bij de ontvanger minder

reflecties toekomen. Deze twee fenomenen zorgen ervoor dat de linkkwaliteit lager is. Vanaf

welke afstand boven de grond kunnen we nu een normaal zendpatroon verwachten? De golfleng-

te bij een frequentie van 2,4 GHz bedraagt 12,5 cm (golflengte = lichtsnelheid/frequentie). In

de voorgaande proef werden de modules op een hoogte van 4 keer deze golflengte geplaatst. Op

deze hoogte hebben we het normale zendpatroon. We verwachten dat de grafiek weinig wijzigt

indien we testen vanaf een hoogte van 1 keer de golflengte, dit werd echter niet onderzocht. We

merken tenslotte op dat ook hier de linkkwaliteit informatie zeer stabiel is.

2.3.3 Batterij test

In deze test voeden we de VER-module met een 9V blokbatterij. We laten elke 1000 ms een

poll-bericht versturen. Uit deze test bleek dat de batterij 2 u meegaat. Aangezien er in dit

2.4 Besluit 29

Figuur 2.10: Scenario 5: De linkkwaliteit i.f.v. de positie van de modules

eindwerk geen speciale aandacht werd geschonken aan deze batterij-problematiek hoeft dit re-

sultaat ons niet te verwonderen. Via zogenaamde beacons kan met den modules op bepaalde

tijdstippen laten luisteren en bijvoorbeeld 99% van de tijd laten “slapen”. Op die manier kan het

stroomverbruik aanzienlijk beperkt worden. De gebruikte SMAC-implementatie liet dit echter

niet toe. Dit is dan ook een interessant onderwerp voor verder onderzoek.

2.4 Besluit

Uit de verschillende proeven kunnen we besluiten dat we met behulp van deze modules een

contextgevoelige applicatie kunnen bouwen. Er werd gewerkt met de SMAC laag in plaats

van de 802.15.4 MAC laag omdat deze laatste in het begin van het academiejaar nog niet

beschikbaar was. Het verschil zit hem in het feit dat er geen retransmissies worden verzonden,

indien een bepaald pakket niet bevestigd wordt. Indien men zou overschakelen op de 802.15.4

MAC laag, kan met het foutenpercentage nog verder doen dalen. Verder werd er vastgesteld

dat er een bruikbaar verband is tussen de linkkwaliteit en de afstand. Hierbij is wel de positie

van de modules van belang. Voor een goede werking worden deze niet op de grond gelegd.

2.4 Besluit 30

Aangezien we tussen de modules pakketten versturen, moet er niet eerst een verbindingssessie

worden opgezet. Dit komt de algemene snelheid ten goede, waarbij we een ordegrootte van

enkele ms vaststelden. Tenslotte werd het geheel mobiel gemaakt, waarbij er geen extra fouten

werden geıntroduceerd door de gebruikte Bluetooth-convertor. De mogelijke interferentie van

een externe Bluetooth-verbinding en een microgolfoven worden besproken in hoofdstuk 4.

BLUETOOTH 31

Hoofdstuk 3

Bluetooth

Dit hoofdstuk handelt over de implementatie van een contextgevoelige applicatie met behulp van

Bluetooth, een open en draadloze standaard. Na een korte kennismaking met deze standaard

(Sectie 3.1.2) wordt het eigenlijke werk besproken. De linkkwaliteit informatie onder Windows

(Sectie 3.2.1) en GNU/Linux (Sectie 3.2.2) is verschillend, dit werd dan ook onderzocht. Er

werd een perl-script geschreven, gebaseerd op BlueZ, en een PDA testapplicatie, geschreven in

C#.Net (Sectie 3.2.3). Hierna volgt een analyse van de proeven (Sectie 3.3), met nadien de

belangrijkste besluiten kort samengevat (Sectie 3.4).

Het is niet de bedoeling om de volledige Bluetooth standaard te beschrijven. Voor meer info

wordt er verwezen naar de referenties.

3.1 Achtergrondinformatie

3.1.1 Introductie

Bluetooth is een technologie die het mogelijk maakt draadloos te communiceren tussen verschil-

lende mobiele apparaten. Deze standaard richt zich tot situaties waar slechts een kort bereik

noodzakelijk is. Typisch zal het bereik ongeveer 10m (klasse 2 met 4 dBm zendvermogen) be-

dragen, maar door een groter zendvermogen zijn afstanden tot 100m mogelijk (klasse 1 met

20 dBm zendvermogen). Telefoons kunnen bijvoorbeeld snel informatie synchroniseren met

desktop computers, faxen en printers binnen een straal van 10 meter worden herkend en zijn

beschikbaar en headsets van telefoons zullen zonder kabels communiceren. De geschiedenis van

Bluetooth start in 1994, wanneer de firma Ericsson zocht naar een goedkope manier om draad-

loos gegevens te verzenden tussen mobiele telefoons. Vanaf het begin was het doel de kabels


tussen de apparaten te vervangen. In 1998 werd door Ericsson, IBM, Intel, Nokia en Toshiba

de “Bluetooth Special Interest Group” [SIG] opgericht, met als uitgangspunt dat de standaard

open moest zijn. De naam Bluetooth is geınspireerd op Harald Blauwtand die de koninkrijken

van Noorwegen en Denemarken heeft verenigd, en Bluetooth streeft ernaar om de verschillende

apparaten draadloos te verenigen. Nadat de 1.0a versie van de specificatie beschikbaar was,

bleek dat verscheidene fabrikanten van Bluetooth-adapters deze soms verkeerd interpreteerden.

Het bleek zelfs dat twee verschillende adapters van dezelfde fabrikant niet met elkaar konden

communiceren. Aangezien interoperabiliteit een belangrijke troef moest zijn, werden vele verbe-

teringen aangebracht. Na uitgebreide testen, waarbij fabrikanten hun adapters onderling testten

op zogenaamde UnPlugFests, werd de 1.1 specificatie geratificeerd. De transport lagen (L2CAP,

LMP, Baseband en Bluetooth radio) van de Bluetooth technologie werden ook gestandardiseerd

in de IEEE 802.15.1-2002 standaard. Deze specificatie is gebaseerd op de PHY en MAC lagen

van de Bluetooth 1.1 specificatie. In de volgende secties worden enkele verschillende lagen van

de Bluetooth protocol stack kort besproken.

3.1.2 Bluetooth

Figuur 3.1: De Bluetooth protocol stack

De (niet volledige) protocol stack van Bluetooth in Figuur 3.1 wordt kort besproken. We

lichten de verantwoordelijkheden van elke laag toe:

• Radio: De Bluetooth Radiolaag specifieert de eisen waaraan een Bluetooth-transceiver

moet voldoen om te kunnen opereren in de 2,4 GHz ISM-band. De data doorvoersnelheid


bedraagt 1 Mbps. Bluetooth maakt gebruik van frequency hopping waarbij de ISM-band

wordt opgedeeld in 79 hopkanalen die elk 1 MHz uit elkaar liggen, van 2,402 GHz tot 2,480

GHz. Elk kanaal wordt voor minstens 625 microsec (= een tijdsslot) gebruikt waarna er

gehopt wordt in een pseudo-random volgorde naar een ander kanaal. Dit wordt voortdu-

rend herhaald met een maximale snelheid van 1600 hops per seconde. Op deze manier

wordt het dataverkeer gespreid over de hele ISM band en wordt een systeem bekomen met

een goede interferentieprotectie. Indien een van de transmissies botst met bijvoorbeeld

het signaal van een microgolfoven, zal de kans op interferentie bij een volgende hop zeer

klein zijn. Dit is eigenlijk een agressieve methode die andere technologieen die in dezelfde

band opereren kan storen.

• BaseBand / Link Controller: De BaseBand en de Link Control zorgen voor de fysieke

verbinding tussen Bluetooth-apparaten. Foutcorrectie, dataflow, synchronisatie en bevei-

liging zijn diensten die door deze laag worden geleverd. We onderscheiden twee soorten

verbindingen: synchrone connectie-georienteerde (SCO) voor “voice” en asynchrone con-

nectieloze (ACL) voor data. Bij een ACL verbinding zullen gebotste pakketten opnieuw

verstuurd worden.

• Link manager: Het Link Manager Protocol is verantwoordelijk voor het opzetten van

een verbinding tussen Bluetooth-apparaten. Dit omvat ook de beveiligingsaspecten zoals

authentificatie en encryptie. Ook het beheer van piconetten behoort tot de verantwoorde-

lijkheid. Deze laag maakt gebruik van de diensten van de Link Controller-laag.

• Host Controller Interface (HCI): De HCI voorziet een interface voor de softwarelagen

naar de in hardware geımplementeerde Baseband / Link controller en Link manager.

• Bluetooth Logical Link Control en het Adaption Protocol (L2CAP): Via de-

ze laag kunnen hogere lagen gebruik maken van de Baseband. L2CAP biedt connectie-

georienteerde en connectieloze data diensten voor de hogere lagen protocollen, met mo-

gelijkheid voor protocol multiplexing en segmentatie. De maximale grootte van L2CAP

datapakketten is 64 kilobytes. De data van de bovenliggende lagen wordt in het Bluetooth-

pakket formaat verpakt.

• Service Discovery Protocol (SDP): Het ontdekken van diensten (Eng. services) is een

zeer belangrijk onderdeel van Bluetooth. Een overzicht van diensten die een Bluetooth-

apparaat biedt, is de basis voor het gebruiken van Bluetooth. Via SDP kan apparaatinfor-


matie en de diensten/profielen (inclusief de eigenschappen) van een ander apparaat worden

gevraagd. De lokale applicaties zijn verantwoordelijk om de diensten die ze aanbieden te

registreren. Daarna kan een verbinding worden gemaakt tussen 2 of meer Bluetooth-

apparaten.

• RFCOMM: Deze protocol laag emuleert een seriele verbinding en is gebaseerd op de

ETSI 07.10 specificatie. Het emuleert de zeer bekende RS-232 controle en data signalen.

RFCOMM kan weer gebruikt worden door hogere lagen protcollen, zoals OBEX. Dankzij

de seriele emulatie is het eenvoudig om software die gebruik maakt van RS-232 compatibel

te maken met Bluetooth. Het is via deze laag dat we in dit eindwerk een verbinding zullen

maken tussen de PDA en de Bluetooth-adapter.

• Object Exchange Protocol (OBEX): OBEX is ontwikkeld door de Infrared Data

Association (IrDA) voor het uitwisselen van objecten op een eenvoudige manier. Dit is

een betrouwbaar protocol dat gebruik maakt van de diensten van de RFCOMM-laag.

Nu we een beperkt overzicht hebben van de protocol stack, worden de verschillende types

van netwerken kort toegelicht. Bluetooth voorziet een point-to-point connectie (waarbij slechts

2 toestellen betrokken zijn) of een point-to-multipoint connectie. Om het verkeer te regelen

tussen de apparaten die via Bluetooth met elkaar communiceren, gebruikt men een master/slave

configuratie. Elke unit kan zowel de rol van master als van slave aannemen. Hierover wordt

onderhandeld tijdens een zogenaamde “Role switch”. Twee of meer units die hetzelfde kanaal

delen, vormen een piconet. Er is een kanaal tussen twee nodes wanneer deze hetzelfde schema

hebben voor de frequency hopping. Elk piconet heeft een master en maximaal zeven actieve

slaves. Er kunnen echter meer slaves aan eenzelfde master gebonden blijven door in de bepaalde

connectie modes (“hold”, “sniff”, “park”) over te gaan. Meerdere piconetten vormen samen

een scatternet, waar een onderdeel uit het ene piconet ook slave is in het andere netwerk. Een

onderdeel kan ook in het ene piconet een master zijn en in het andere piconet een slave. De

piconetten hebben hun eigen startfrequentie en hopsequentie en deze zijn verschillend voor ieder

piconet, daar deze bepaald worden door respectievelijk de klok en het deviceID van de master.

Alle units die in eenzelfde piconet zitten, zijn gesynchroniseerd met deze hopsequentie. Daar

er 79 kanalen beschikbaar zijn van 1MHz is het in principe mogelijk om een scatternet van 79

piconetten aan elkaar te hangen. Rekening houdend met het aantal mogelijke frequenties is in

de praktijk acht het maximale aantal waarbij het aantal botsingen nog niet lijdt tot significant


snelheidsverlies. Meer dan acht piconetten is uiteraard mogelijk maar de kans dat twee kanalen

toevallig tegelijkertijd op dezelfde frequentie proberen te zenden neemt uiteraard toe.

Een uitgebreide beschrijving van de mogelijkheden van Bluetooth valt buiten het bestek

van dit eindwerk. Een goede introductie is [JKKG01]. We wensen enkel gebruik te maken

van Bluetooth om de linkkwaliteit van een bepaalde verbinding te meten. Op deze manier

zullen we proberen te bepalen of een bepaald Bluetooth-toestel zich dicht in de buurt van de

verpleegkundige bevindt.

3.1.3 Gebruikte adapter

De laatste Bluetooth specificatie is 2.0. Er zijn echter nog niet veel producten op de markt die

compatibel zijn met deze laatste specificatie. De Bluetooth-adapters die in dit eindwerk werden

gebruikt zijn compatibel met de 1.1 specificatie. Het gaat hier om een Bluetooth USB Adapter

van Acer en een DBT-120 van D-Link. Dit brengt een belangrijke beperking met zich mee.

Indien we de linkkwaliteit wensen te meten, moeten we eerst een verbinding opzetten tussen de

PDA en de Bluetooth-adapter. Adapters die compatibel zijn met de 1.2 specificatie zouden deze

beperking niet hebben. Dit kon echter niet getest worden in dit eindwerk.

3.2 Werk verricht

Er werd eerst onderzocht in welke mate we de linkkwaliteit kunnen opmeten. Er bleek een

verschil te bestaan indien we de Bluetooth-adapter aansluiten op een computer met een Windows

besturingssysteem en een Linux besturingssysteem. Dit verschil spruit voort uit de verschillende

drivers die er voor elk platform zijn. Onder Windows zijn de belangrijkste leveranciers van

Bluetooth drivers de firma’s Broadcom en Microsoft. Dankzij de firma High Point Software

is er een gratis evalutie SDK ter beschikking, genaamd BTAccess. Deze wordt besproken in

Sectie 3.2.1. Voor het Linux platform is er een vrije software gemeenschap die Bluetooth drivers

heeft ontwikkeld, genaamd BlueZ. Naast de drivers zijn er ook vrij beschikbare tools aanwezig.

Het werk op basis van de BlueZ protocol stack wordt besproken in Sectie 3.2.2. Daarnaast werd

de toolkit uitgebreid om het geheel te testen (secie 3.2.3).

3.2.1 Programma: Windows PC - BTAccess

High Point Software (HPS) levert een software development kit voor apparaten die Broadcom

(= Widcomm) drivers gebruiken voor de Bluetooth functionaliteit. Sinds 1 november 2004 biedt


HPS ook Bluetooth ondersteuning voor .Net applicaties. Dit is de enige commerciele firma die

een evaluatie versie gratis ter beschikking stelt. De SDK van Broadcom (BTW-CE Software

Development Kit for Pocket PC Development Platform) kost al snel 1395$ en werd hier niet

gebruikt.

Figuur 3.2: Het sequentiediagram voor het zoeken van de dichtste patient (windows)

Met behulp van BTAccess [BTA] werd een PocketPC-applicatie geschreven, volgens het

sequentiediagram in Figuur 3.2. Deze zal eerst een scan uitvoeren, om te weten te komen

welke Bluetooth-apparaten er in de buurt zijn. Deze scan duurt 12 s en levert ons een lijst van

Bluetooth MAC-adressen op. We kunnen pas de linkkwaliteit meten nadat er een verbinding

is opgezet. Deze verbindingssessie wordt geınitialiseerd door de PDA. Het is gebleken dat de

linkkwaliteit, die in de onderste lagen wordt opgemeten, gegroepeerd wordt in drie categorieen:

laag, goed en hoog. Aangezien “laag” betekent dat er geen verbinding is kunnen we deze

categorie reeds buiten beschouwing laten. Er blijven nu nog maar twee categorieen over. Meestal

zullen we “goed” als linkkwaliteit terug krijgen. Indien men zich binnen een straal van 30 cm rond

de Bluetooth-adapter begeeft, zien we de linkkwaliteit “hoog”. De linkkwaliteit wordt gemeten

op de PDA zelf. Op de windows host PC wordt enkel een Bluetooth-adapter aangesloten. Er is

daar geen programma nodig die de linkkwaliteit opmeet en terugstuurt. Men kan dus wel bepalen

dat men bij een patient staat, indien we de PDA dicht bij de Bluetooth-adapter brengen. Dit is

echter onaanvaardbaar, aangezien we wensen dat het zoeken van de dichtste patient transparant

moet verlopen. Men kan niet verwachten dat de verpleegkundige actief zijn PDA dicht bij de


Bluetooth-adapter brengt.

Deze oplossing voldoet niet aan onze gestelde eisen, zodat we overschakelen naar BlueZ onder

GNU/Linux.

3.2.2 Programma: GNU/Linux PC - BlueZ

Sinds 11 april 2005 is de BlueZ protocol stack officieel gekwalificeerd als Bluetooth subsys-

teem [Blu]. Dit maakt het voor producenten mogelijk om de goede werking van hun Bluetooth-

apparaten te controleren. Na de installatie van Debian 2.6.9 GNU/Linux werd BlueZ geınstalleerd.

Dankzij BlueZ kunnen we onder Linux werken met Bluetooth hardware. BlueZ bestaat uit ver-

schillende modules:

• Bluetooth kernel subsysteem core;

• L2CAP en SCO audio kernel lagen;

• RFCOMM, BNEP, CMTP en HIDP kernel implementaties;

• HCI UART, USB en PCMCIA drivers;

• Algemene Bluetooth en SDP bibliotheken en servers,

• Configuratie en test programma’s.

Deze BlueZ stack ondersteunt verschillende profielen: General Access Profile, Service Disco-

very Profile, DialUp Networking Profile, LAN Access Profile, OBEX Object Push Profile, OBEX

File Transfer Profile, PAN Profile en het Serial Port Profile. Het is het “Serial Port Profile” dat

verder zal gebruikt worden. Naast deze ondersteuning voor de verschillende profielen zijn er ook

enkele tools beschikbaar. We bespreken hier enkel de belangrijkste voor dit eindwerk. Voor een

correct gebruik ervan wordt verwezen naar de man-pagina’s.

• hciconfig: Met hciconfig kunnen we de USB Bluetooth-adapter configureren. Deze moet

immers eerst “UP” zijn alvorens we verder kunnen. Wanneer er een Bluetooth-adapter is

gededecteerd zal dit de naam hciX krijgen (X is een nummer). Van elke herkende adapter

kunnen we onder andere het Bluetooth MAC adres opvragen. Tevens kunnen we instellen

of er authenticatie en encryptie moet gebruikt worden tijdens de verbindingen.


• hcitool: Hiermee kunnen we scannen naar Bluetooth-adapters in de buurt. Van de ge-

vonden adapters kunnen we informatie (aangeboden diensten, de naam en de versie) ver-

krijgen. “hcitool” maakt het ook mogelijk om een baseband verbinding op te zetten. De

belangrijkste informatie die deze tool ons zal verschaffen is de linkkwaliteit (lq) en de

“Returned Signal Strength Indication” (rssi) van een verbinding.

• rfcomm: Dankzij deze tool kunnen we een Bluetooth-verbinding opzetten die een seriele

kabel emuleert.

De versie’s waarmee gewerkt wordt zijn:

– Bluetooth Core ver 2.6;

– hciconfig ver 2.15;

– hcitool ver 2.15;

– Bluetooth RFCOMM ver 2.15.

Figuur 3.3: Het sequentiediagram voor het zoeken van de dichtste patient (GNU/Linux)

We wensen het sequentiediagram van Figuur 3.3 te verwezenlijken. Allereerst wordt er een

verbinding opgezet tussen de PDA en de host PC. Op deze host PC is de Bluetooth-adapter

aangesloten. Het maken van een verbinding is de verantwoordelijkheid van deze host PC en

verloopt via de RFCOMM tool. Dit wordt nu stap voor stap uitgelegd.


1. Controleren of de Bluetooth-adapter wordt herkend op de host PC

debian :\# hc i c o n f i g

hc i0 : Type : USB

BD Address : 0 0 : 6 0 : 5 7 : 1 8 :FE:56 ACL MTU: 192 :8 SCO MTU: 64 :8

UP RUNNING PSCAN ISCAN

RX bytes :548743 a c l :9500 sco : 0 events :2754 e r r o r s : 0

TX bytes :33981 a c l : 820 sco : 0 commands :1769 e r r o r s : 0

2. Is de PDA in de buurt aanwezig? Dit kan tot 12 s duren.

debian :/# h c i t o o l − i hc i0 scan

Scanning . . .

0 0 : 0 4 : 3E: 6 8 : 3C: 6B Pocket PC

3. We kunnen nu als test deze gevonden PDA pingen.

debian :/# l2p ing − i hc i0 00 : 0 4 : 3E: 6 8 : 3C: 6B

Ping : 0 0 : 0 4 : 3E: 6 8 : 3C: 6B from 00 : 6 0 : 5 7 : 1 8 :FE:56 ( data s i z e 20) . . .

20 bytes from 00 : 0 4 : 3E: 6 8 : 3C: 6B id 0 time 16 .05ms




4 sent , 4 rece ived , 0\% l o s s

4. rfcomm.conf moet eerst worden ingesteld.

#

# RFCOMM con f i gu r a t i on f i l e .

#

rfcomm0 {

bind yes ;

# Bluetooth address o f the dev i c e

dev i c e 00 : 0 4 : 3E: 6 8 : 3C: 6B;

# RFCOMM channel for the connect ion

channel 0 ;


# Desc r ip t i on o f the connect ion

comment ”PDA” ;

}

5. We zetten de verbinding op tussen de host PC (rfcomm0) en da PDA (00:04:3E:68:3C:6B).

debian :/# rfcomm connect rfcomm0 00 : 0 4 : 3E: 6 8 : 3C: 6B

Connected /dev/rfcomm0 to 00 : 0 4 : 3E: 6 8 : 3C: 6B on channel 1

Press CTRL−C for hangup

Deze stappen werden geautomatiseerd door deze in een perl-script te schrijven. Wanneer dit

uitgevoerd wordt zal er een inkomende verbinding verschijnen op de PDA. Deze kan nu gebruikt

worden door de toolkit om berichten te versturen en te ontvangen (zie Sectie 3.2.3). De PDA

verstuurt een poll-bericht waarop de host PC de linkkwaliteit moet opmeten en deze terugsturen.

Het opmeten van de linkkwaliteit gebeurt als volgt:

1. De binnenkomende tekst wordt gededecteerd via /dev/rfcomm0

2. In het geval dit een geldig poll-bericht is wordt de linkkwaliteit opgemeten.

h c i t o o l l q 00 : 0 4 : 3E: 6 8 : 3C: 6B

Dit zal een waarde tussen 0 en 255 opleveren, waarbij 255 betekent dat de linkkwaliteit

optimaal is.

3. De linkkwaliteit wordt teruggestuurd naar de PDA, opnieuw via /dev/rfcomm0

Ook deze functionaliteit werd vervat in een perl-script. De toolkit wordt nu uitgebreid om

deze Bluetooth-oplossing te testen.

3.2.3 Programma: de .Net Compact Framework toolkit

In tegenstelling tot de ZigBee-oplossing, waar de PDA zelf de verbinding opzet, wordt hier de

verbinding opgezet door de host PC. Hierdoor zien we op de PDA een binnenkomende verbinding

verschijnen, op COM-poort 5. Dit stellen we in in het afgeleide BluetoothCom-object. Eens de

communicatie is opgezet kunnen we gegevens versturen en ontvangen. De toolkit werd hiervoor

uitgebreid met een extra form.


• Link Quality: De gemeten linkkwaliteit wordt zichtbaar op de PDA.

Met behulp van deze toolkit kunnen we enkele proeven doen, waarvan de resultaten in de

volgende sectie worden geanalyseerd. Voor de uitbreiding van de CaReport-applicatie wordt

opnieuw verwezen naar hoofdstuk 5.

3.3 Analyse van de proeven

De perl-scripts en de toolkit laten ons toe om de GNU/Linux oplossing te testen. Bij elk

testscenario zal een beschrijving van de testopstelling gegeven worden. In eerste instantie zal

het foutenpercentage getest worden (Sectie 3.3.1). Hiervoor beschikken we over een PDA met

een Bluetooth interface. Van op de PDA worden de berichten via Bluetooth verstuurd naar

de Bluetooth-adapter op de host PC. Nadien concentreren we ons op het verband tussen de

gemeten linkkwaliteit en de afstand (Sectie 3.3.2). We bekijken of deze informatie betrouwbaar

is. De invloed van een microgolfoven wordt onderzocht in Sectie 4.3.

3.3.1 Foutenpercentage

Met deze proef willen we weten hoe betrouwbaar het geheel is. De PDA zal, na een bepaalde

intervalwaarde, telkens een poll-bericht versturen naar de host PC. Het interval staat ingesteld

op respectievelijk 1000 ms, 1600 ms en 2000 ms. Een fout is het niet toekomen van een antwoord

op de PDA. We tellen het aantal onbeantwoorde poll-berichten, ervoor zorgende dat de PDA

zich niet buiten het bereik van de Bluetooth-adapter begeeft.

Tabel 3.1: Foutenpercentage: Interval variabel

Interval (ms) Fouten Aantal Gem. percentage

2000 0 4000 0%

1600 0 4000 0%

1000 0 4000 0%

De totale fout, bij elk interval, in Tabel 3.1 bedraagt 0%. Dit is te verklaren doordat

Bluetooth een betrouwbaar protocol is. Dankzij de retransmissies worden niet aangekomen

pakketten opnieuw verstuurd. Er is dus geen informatieverlies.


3.3.2 Verband tussen de linkkwaliteit en de afstand

Met deze proeven zoeken we een verband tussen de linkkwaliteit en de afstand. De Bluetooth-

adapter wordt op de grond geplaatst en de PDA wordt rechtstaand vastgehouden. Hierbij

merken we op dat er zich geen obstakels tussen beide bevinden. Elke 50 cm staan we stil en

noteren we de waarde van de linkkwaliteit. De proef werd uitgevoerd tot een afstand van 2 m.

Tabel 3.2: Verband tussen de linkkwaliteit en de afstand bij Bluetooth

Afstand (cm) Linkkwaliteit

0 255

50 255

100 255

150 255

200 255

Bij de resultaten in Tabel 3.2 hoort een belangrijke opmerking. We zien dat de linkkwali-

teit binnen een straal van 2 m rond de Bluetooth-adapter “255” is. Tijdens het meten werd

echter vastgesteld dat de linkkwaliteit wel daalt wanneer we ons bewegen, maar dat deze na-

dien in trappen stijgt tot de maximale linkkwaliteit van 255. Zo daalde de linkkwaliteit op een

afstand van 50 cm tot 214, waarna deze terug steeg tot 255. Dit fenomeen wordt verklaard

doordat de Bluetooth-adapter deze daling van de linkkwaliteit opmerkt. Wanneer deze daalt

zal de Bluetooth-adapter zijn zendvermogen verhogen. Op die manier zal de linkkwaliteit, van

bijvoorbeeld 214, in trappen stijgen tot het maximum van 255.

Deze eigenschap van Bluetooth maakt het onmogelijk om, op basis van de linkkwaliteit,

een betrouwbare afstandsbepaling te doen. Zoals in de probleemstelling vermeld moeten we

immers het verschil kunnen maken tussen twee patienten A en B die zich op minder dan 1 m

van elkaar bevinden. Wanneer de verpleegkundige bij een patient A komt zal de linkkwaliteit tot

de Bluetooth-adapter bij patient B ook 255 zijn. Men kan dus niet bepalen wie zich het dichtst

bij de verpleegkundige bevindt. Aangezien we het zendvermogen van de Bluetooth-adapter

niet manueel kunnen instellen, kan ook het opzetten van proximity-cellen rond een patient niet

verwezenlijkt worden. Men kan enkel de lijst beperken door alle patienten te tonen die een

linkkwaliteit van 255 rapporteren.

3.4 Besluit 43

3.4 Besluit

Uit de verschillende proeven kunnen we besluiten dat we de vooropgestelde contextgevoelige

applicatie niet kunnen realiseren. Op korte afstand is de linkkwaliteit informatie onbruikbaar

om te bepalen welke patient het dichtst bij de verpleegkundige is. Aangezien de Linux Host

PC de verbinding opzet met de PDA van de verpleegkundige, moet deze eerst weten of de

verpleegkundige al dan niet in de buurt is. De Linux Host PC zal dus een scan moeten uitvoeren

en dit kan tot 12 s duren. Dit is een bijkomend nadeel aangezien we in de probleemopstelling

vereisten dat het bepalen van de dichtste patient niet langer dan 2 s mag duren. Volgens de

Bluetooth 1.2 specificatie zou men de linkkwaliteit kunnen meten zonder eerst een verbinding op

te zetten. Men kan veronderstellen dat het zendvermogen niet verhoogd zal worden, aangezien

er nog geen verbinding is. Deze stelling kan onderzocht worden in een toekomstig werk. Verder

is gebleken dat het informatieverlies bij Bluetooth 0% is. Of dit ook het geval is wanneer er een

microgolfoven in de buurt is wordt besproken in hoofdstuk 4.

VERGELIJKING TUSSEN ZIGBEE EN BLUETOOTH 44

Hoofdstuk 4

Vergelijking tussen ZigBee en

Bluetooth

In dit hoofdstuk zullen we eerst enkele algemene eigenschappen van Bluetooth en ZigBee met

elkaar vergelijken (Sectie 4.1). Aangezien beide technologieen actief zijn in de 2,4 GHz band

onderzoeken we de mogelijke interferentie tussen beide (Sectie 4.2). Er wordt vaak gezegd dat

een microgolfoven storend zal werken, in dit eindwerk worden dan ook enkele basisproeven

uitgevoerd om dit al dan niet aan te tonen (Sectie 4.3).

4.1 Algemene vergelijking

We plaatsen enkele eigenschappen op een rij in Tabel 4.1.

Tabel 4.1: Algemene eigenschappen van Bluetooth en ZigBee

Parameter Bluetooth ZigBee

Datasnelheid 1 Mbps 250 kbps

Netwerk (aantal nodes) 7 65535

Vertraging (ordegrootte) enkele seconden milliseconden

Kanaal frequency hopping keuze uit 16, vast

Bereik 10 m (klasse 2) 0 tot 30 m

Doel kabelvervanger “low duty cycle”

• Datasnelheid: We merken op dat de datasnelheid bij ZigBee lager ligt. Voor de context-

4.2 Interferentie tussen beide 45

gevoelige applicatie in dit eindwerk is dit echter geen obstakel. De pakketten die worden

verstuurd zijn typisch 10 bytes groot. Bij een bestandsoverdracht zal Bluetooth wel beter

presteren, aangezien de hogere datasnelheid die kan gehaald worden.

• Netwerk: Bij Bluetooth kan een master-toestel tot 7 actieve verbindingssessies opzetten

met andere Bluetooth-apparaten. Bij ZigBee wordt er geen verbindingssessie opgezet, maar

verstuurt men direct pakketten. Men kan gebruik maken van een 16-bit kort adres zodat

we tot 65535 ZigBee-apparaten per PAN-coordinator kunnen opnemen in het netwerk.

• Vertraging: De relatief grote vertraging bij Bluetooth wordt veroorzaakt door het zoe-

ken naar naburige toestellen en het opzetten van een verbinding. Het versturen van de

berichten zelf gebeurt bij beide snel.

• Kanaal: Bluetooth maakt gebruik van frequency hopping tussen de 79 kanalen. Per

tijdsslot wordt er een ander kanaal gebruikt, zodat de volledige band tussen 2,402 GHz en

2,480 GHz wordt benut. Elk Bluetooth kanaal gebruikt 1 MHz. Bij ZigBee werken we op

een vast kanaal, waarbij we de keuze hebben uit 16 kanalen in de band van 2,405 GHz tot

2,480 GHz. Elk kanaal gebruikt 3 MHz, gecentreerd rond 5 MHz per kanaal. Zo blijft er

een vrije ruimte van 2 MHz tussen elk kanaal. Dit zal van belang zijn bij de bespreking

van de interferentie in sectie 4.2.

• Bereik: Het zendvermogen bij ZigBee is instelbaar, waardoor een bereik van 0 tot 30

m mogelijk is. Bij Bluetooth is het bereik niet manueel instelbaar (voor een klasse 2

apparaat). Het typisch bereik bedraagt ongeveer 10 m.

• Doel: Bluetooth is ontworpen als ideale kabelvervanger en heeft zijn nut al bewezen in

vele toepassingen. ZigBee daarentegen wil de standaard worden voor zogenaamde “low

duty cycle” toepassingen. Hierbij denken we aan netwerken van sensoren die slechts om

de zoveel tijd een waarde moeten doorsturen.

4.2 Interferentie tussen beide

Interferentie is de gezamelijke werking van meerdere gelijksoortige golven op dezelfde tijd en

plaats. Daarbij kunnen zich verschillende verschijnselen voordoen, afhankelijk van de frequen-

tie, amplitude en fase van de golven en de eigenschappen van het medium. Er ontstaat in

alle gevallen een interferentiepatroon, waarbij er plaatsen ontstaan met een hogere intensiteit,


wanneer de golven in fase zijn. De golven versterken elkaar en er ontstaat een buikpunt. Er

ontstaan ook plaatsen met een lagere intensiteit, of zelfs volledige uitdoving, waar de golven

elkaar vernietigen. De golven zijn dan in tegenfase en er ontstaat een knooppunt. Dit wordt

destructieve interferentie genoemd.

De invloed van een externe Bluetooth-verbinding op de ZigBee-oplossing

In Figuur 4.1 zien we de opstelling. We versturen poll-berichten, waarop de BED-module

zal antwoorden. Ondertussen versturen we een bestand tussen twee PC’s via Bluetooth.

Figuur 4.1: De invloed van een externe Bluetooth-verbinding op de ZigBee-oplossing

Na verschillende testen werd een lichte verhoging van het foutenpercentage vastgesteld, na-

melijk 1,27%. De interferentie veroorzaakt door Bluetooth is dus minimaal, dankzij de frequency

hopping techniek. De Bluetooth apparaten springen 1600 keer per seconde naar een van de 79

kanalen. Doordat de ZigBee-oplossing op een vast kanaal berichten verstuurt en ontvangt, zal

die frequentie op een bepaald moment door beide gebruikt worden. Het is op dat moment dat

er botsingen kunnen plaatsvinden. Aangezien Bluetooth zeer snel van kanaal verandert, waarbij

de kans op een niet-overlappend kanaal groot is, krijgen de ZigBee-modules meestal de kans om

het bericht toch door te sturen.

Bluetooth beschikt over drie verschillende pakketlengtes. Bij grotere pakketlengtes blijft

men langer bij 1 frequentie. Wanneer er op die frequentie een botsing is, zal die dan ook langer


duren. Het kan dan efficienter zijn om kleinere pakketten te versturen. Wanneer deze botsten is

het voordeliger deze opnieuw te versturen dan in het geval dat grote pakketten opnieuw moeten

verzonden worden. Bij kleinere pakketlengtes zal er ook sneller naar andere frequenties gehopt

worden.

De Bluetooth 1.2 specificatie gebruikt een “adaptive frequency hopping” (AFH) algorit-

me. Dit laat de Bluetooth-adapters toe om kanalen als goed, slecht of onbekend te markeren.

De slechte kanalen worden tijdens het hoppen vermeden. De Bluetooth-adapter zal periodiek

controleren of er nog activiteit is op het slechte kanaal. Als de mogelijke interferentie op dat

kanaal verdwenen is, wordt het slechte kanaal als goed gemarkeerd. We beschikten niet over 1.2

compatibele Bluetooth-adapters. Dit is een piste die in toekomstig werk kan onderzocht worden.

De invloed van een externe ZigBee-“verbinding” op de Bluetooth-oplossing

In Figuur 4.2 zien we de opstelling. We versturen poll-berichten, waarop de Bluetooth-

adapter zal antwoorden. Ondertussen versturen we een pakketten tussen twee modules via

ZigBee. Tussen de twee ZigBee-modules is er geen actief opgezette verbindingssessie, maar we

versturen wel constant pakketten.

Figuur 4.2: De invloed van een externe ZigBee-“verbinding” op de Bluetooth-oplossing

Er werd geen informatieverlies vastgesteld, zodat we opnieuw een bevestiging krijgen dat

Bluetooth een betrouwbaar protocol is dat alles in het werk stelt om de pakketten foutloos af

te leveren. Indien er dan toch een pakket botst wordt dit opnieuw verzonden of kan de inhoud

nog hersteld worden.

4.3 Interferentie door microgolfoven 48

4.3 Interferentie door microgolfoven

Microgolven zijn elektromagnetische golven. Andere elektromagnetische golven zijn rontgen-

stralen, UV-stralen, zichtbaar licht, korte en lange radiogolven. Alle stralingsgolven worden

gekenmerkt door een welbepaalde golflengte (uitgedrukt in meter) of een frequentie (uitgedrukt

in Hertz). Het product van beide parameters wordt gegeven door de snelheid van het licht.

Een elektromagnetische straling bezit meer energie naarmate zijn golflengte kleiner is of zijn fre-

quentie hoger. De frequentie van microgolven bedraagt 300 tot 30.000 MHz, wat overeenstemt

met een golflengte van 1 m tot 0,1 mm. Huishoudtoestellen in Europa werken standaard met

microgolven van 2450 MHz. De microgolfoven die in deze test werd gebruikt werkt eveneens op

deze frequentie.

De invloed van een microgolfoven op de ZigBee-oplossing

We nemen opnieuw de opstelling van Figuur 4.1, waarbij we nu de externe Bluetooth-

verbinding weglaten en een microgolfoven als mogelijke stoorbron in de plaats zetten. De

modules bevinden zich in een straal van 20 cm rond deze microgolfoven. Elke 1000 ms ver-

sturen we een poll-bericht en we tellen het aantal fouten. De frequentie van het kanaal waarover

we deze berichten versturen is eveneens 2450 MHz. We zullen in deze proef de microgolfoven

drie keer aanzetten.

In Figuur 4.3 zien we duidelijk wanneer de microgolfoven werd aangezet. Het gaat om de

rode gebieden in de grafiek. Het valt op dat het aantal fouten sterk stijgt. De richtingscoefficient

van de verschillende gebieden kan ons dit bevestigen. We delen de toename van het aantal fouten

door het aantal minuten van het deelgebied. We berekenen afwisselend deze richtingscoefficient

voor de blauwe en rode gebieden. De resultaten zijn: 0,47; 5,75; 0,26; 3,25, 0; 3,5 en 0,29.

Wanneer de microgolfoven draait, stellen we vast dat de richtingscoefficient groter dan 3 is. In-

dien we enkel het aantal fouten tellen gedurende de tijd dat de microgolfoven aan staat, komen

we uit op een foutenpercentage van 40%! We stellen vast dat er duidelijk hinder is. Aangezien

we het kanaal kunnen instellen trachten we het foutenpercentage te doen dalen door een ander

kanaal te kiezen. De proef werd herhaald met als frequentie van de modules 2405 MHz. Het

foutenpercentage bedroeg 10%, wat nog altijd relatief veel is, vergeleken met het aanvaardbare

foutenpercentage van 1%.

4.4 Besluit 49

Figuur 4.3: De invloed van een microgolfoven op de ZigBee-oplossing

De invloed van een microgolfoven op de Bluetooth-oplossing

We nemen opnieuw de opstelling van Figuur 4.2, waarbij we nu de externe ZigBee-“verbinding”

weglaten en een microgolfoven als mogelijke stoorbron in de plaats zetten. De Bluetooth-adapter

en de PDA bevinden zich in een straal van 20 cm rond deze microgolfoven. Elke 1000 ms ver-

sturen we een poll-bericht en we tellen het aantal fouten.

Uit de proef is gebleken dat er geen informatieverlies is. Opnieuw blijkt dat we via Bluetooth

betrouwbaar gegevens kunnen versturen. Er werd wel opgemerkt dat de linkkwaliteit van de

verbinding daalt tijdens het gebruik van de microgolfoven. De Bluetooth-adapter is dus niet

in staat om de maximale linkkwaliteit te bereiken. Dit wil zeggen dat er toch een invloed is,

zelfs bij het maximale zendvermogen van de Bluetooth-adapters, maar dat deze invloed van de

microgolfoven niet hinderlijk is.

4.4 Besluit

Uit alle proeven blijkt dat ZigBee hinder ondervindt van interferentie. De gevolgen van deze

hinder kunnen echter beperkt worden door de 802.15.4 MAC implementatie te gebruiken in

plaats van de SMAC implementatie. Hierdoor kunnen we het informatieverlies reduceren door

4.4 Besluit 50

de pakketten opnieuw te versturen indien er geen ontvangstbevestiging terugkomt. Bluetooth

daarentegen heeft geen last van interferentie. Dankzij de retransmissies en de frequency hopping

techniek is het informatieverlies nihil.

INTEGRATIE IN CAREPORT 51

Hoofdstuk 5

Integratie in CaReport

5.1 Vereisten

Deze sectie werd geschreven door Pieter De Mil, Stijn De Wilde en Wim Vandenberghe

Er werden een aantal thesissen uitgewerkt die allemaal draaien rond location-aware toepas-

singen in de ziekenzorg. In elk van hen werd weliswaar een andere technologie onderzocht, maar

het uiteindelijke doel was steeds hetzelfde: ervoor zorgen dat een Pocket PC applicatie op de een

of andere manier weet welke patienten er zich in zijn nabije omgeving bevinden. Deze informatie

zou dan kunnen geıntegreerd worden in de CaReport applicatie.

CaReport is een PDA applicatie die ingezet wordt om de administratie in de ziekenzorg te

vereenvoudigen. Het is namelijk mogelijk om allerhande gegevens die met de verzorging te maken

hebben rechtstreeks op de PDA in te geven, waarna deze gegevens kunnen worden ingeladen in

een centraal systeem. Dit is een stuk efficienter dan de gegevens eerst op een groot blad papier

te schrijven en ze achteraf over te typen.

Origineel werd CaReport ontwikkeld voor Palm PDA’s. Stijn De Wilde heeft in zijn thesis

echter een Pocket PC port van deze applicatie gemaakt. Het zou dan ook heel mooi zijn indien

we de resultaten van de verschillende thesissen allemaal zouden kunnen verwerken in deze ene

applicatie. In het ideale geval zou het dan mogelijk worden om in CaReport live te veranderen

van technologie.

Dit zou het best gebeuren in een formulier dat bekend staat als het Form1. Dit is het scherm

waarin een patient kan worden gekozen. Wanneer we net in dit scherm gebruik maken van de

informatie die de verschillende technologieen kunnen leveren, dan kan de lijst met mogelijke

patienten worden ingekort tot die patienten die zich in de nabije omgeving bevinden.

5.2 ContextEngine 52

Om dit te verwezenlijken zijn er twee grote vereisten. De eerste is dat de verschillende

technologieen elkaar niet mogen storen. Het is dan ook zeer belangrijk dat bij het omschakelen

van de ene technologie naar de andere steeds alle resources volledig worden vrijgegeven. De

tweede vereiste is dat er goede afspraken moeten worden gemaakt over hoe elke technologie zijn

informatie kan doorspelen naar de bovenliggende applicatie.

5.2 ContextEngine

Deze sectie werd geschreven door Pieter De Mil, Stijn De Wilde en Wim Vandenberghe

Nu we de vereisten kennen moeten we een methode ontwikkelen om iedere technologie toe

te voegen aan de CaReport applicatie. We zullen dit doen door middel van overerving: een

basisklasse zal door iedere technologie gebruikt worden om zich toe te voegen aan CaReport.

Deze basisklasse is de ContextEngine.

ContextEngine is een klasse geschreven in C#, en bestaat voor een deel uit geımplementeerde

methodes, en een deel uit abstracte methodes die door elke technologie moeten worden ingevuld.

Het is de bedoeling dat ContextEngine zich zal gedragen als een object dat events opgooit waar

CaReport op zal reageren. Het object zelf zal niet in een aparte draad worden geplaatst. Elke

klasse die overerft van ContextEngine zal zelf verantwoordelijk zijn voor het beheer van eventuele

interne draden. Het object zal tevens blijven leven gedurende de hele levensduur van CaReport.

Wanneer een Form1 niet meer getoond wordt zal dit dus niet betekenen dat het object niet meer

bestaat. Het beheer van de resources zal dan ook niet in de constructor en destructor kunnen

gebeuren.

Een UML schema van de ContextEngine is te zien in figuur 5.1. Er zijn een aantal methoden

geımplementeerd die voor elke technologie hetzelfde zijn. Denk maar aan de methodes voor het

opgooien van een contextevent of een statusevent. Een aantal getters en setters zijn ook reeds

ingevuld. Wanneer men nu een nieuwe technologie wil toevoegen aan CaReport moet men een

klasse maken die overerft van ContextEngine en de abstracte methoden implementeert. Deze

methoden zullen we dan ook iets meer in detail bespreken:

• Open

Dit is de methode waarin alle resources worden ingenomen. De initialisatie moet dus hier

en niet in de constructor gebeuren.

• Close

5.2 ContextEngine 53

Figuur 5.1: De ContextEngine klasse

De tegenhanger van Open. In deze methode worden alle resources weer mooi afgesloten

zodat ze kunnen gebruikt worden door een andere technologie.

• Start

Wanneer men patientgegevens aan het invullen is, dan is het niet nodig dat er ondertussen

wordt gezocht naar patienten in de nabije omgeving. Het is echter ook niet nodig om

alle resources af te sluiten, want er wordt niet omgeschakeld naar een andere technologie.

Wel zal na het ingeven van de gegevens weer moeten verder gegaan worden met zoeken.

Daarom moeten de methoden Start en Stop worden voorzien: deze kunnen het zoeken

pauseren zonder dat de resources worden vrijgegeven.

5.3 XtagEngine 54

• Stop

Dit is de tegenhanger van de Start methode.

• GetName

Het Form1 zal een aantal ContextEngine objecten binnenkrijgen. De gebruiker zal hieruit

kunnen kiezen via een combobox. Deze methode geeft de naam terug die voor dit object

in die combobox zal verschijnen.

• getConfigForm

Bij een aantal technologieen moet het mogelijk zijn om verschillende zaken in te stellen.

Daarvoor zal in het Form1 een knop worden voorzien die dan een settings formulier zal

tonen. Deze zal de instellingen inlezen uit een configuratie-bestand, en daar ook weer terug

naar schrijven. Wanneer de Open methode dan wordt uitgevoerd zal uit hetzelfde bestand

de nodige instellingen ingelezen worden. De reeds geımplementeerde methode config zal

eerst de Stop methode uitvoeren, dan het settings formulier laten zien, en na het sluiten

van dat formulier de Start methode uitvoeren. Deze methode getConfigForm wordt daarbij

gebruikt, en geeft de klasse terug die het gepaste settings formulier voorstelt.

Tenslotte kunnen we nog opmerken dat iedere technologie met een interne voorstelling van

identiteiten zal werken. Deze kunnen totaal verschillend zijn. De bovenliggende CaReport-

applicatie verwacht echter steeds ID’s van dezelfde vorm. We zullen de koppeling tussen deze

twee voorstellingen vastleggen in een XML-bestand, contextInfo.xml. Het is dan de bedoeling

dat dit bestand automatisch uit de CaReport databanken (op een PC) wordt gegenereerd.

5.3 XtagEngine

Deze sectie werd geschreven door Wim Vandenberghe

XtagEngine is de implementatie van de ContextEngine voor het RFID scenario met mobiele

readers. Deze zal gebruik maken van het XtagCom object dat reeds eerder werd besproken.

Dit object maakt het mogelijk om een reader op te vragen zonder aandacht te moeten besteden

aan technische details zoals seriele communicatie, protocol, . . . . Het volstaat om de methode

ondervraag() aan te roepen die een array met gevonden tags terug geeft. Een aparte thread in de

XtagEngine zal dan periodiek het XtagCom object ondervragen. De mapping van de gevonden

5.3 XtagEngine 55

ID’s naar de voorstelling in CaReport zal worden gemaakt, en daarna worden deze in een array

geplaatst en via een ContextEvent doorgegeven aan CaReport.

Het is mogelijk om een aantal zaken in te stellen, zoals te zien in figuur 5.2. We bespreken

de betekenis van de verschillende settings kort.

Figuur 5.2: Instellingen XtagEngine

• Com poort

Hier kan ingesteld worden via welke seriele poort de reader aan de Pocket PC verbonden

is. Dit zal typisch poort 1 zijn op de emulator, en poort 8 (de outbound Bluetooth-poort)

op de Pocket PC.

5.4 ElpasEngine 56

• Readernummer

Hier wordt het nummer van de reader ingegeven. Dit moet overeenkomen met de jumper-

instellingen op de reader.

• Interval

Hiermee kan ingesteld worden hoeveel tijd er tussen twee poll-berichten voorbijgaat. Het

is het best om deze niet onder de 2000 ms in te stellen.

• Krediet

Er werd reeds besproken dat het sorteren van de tags gebeurt door middel van een kre-

dietsysteem. Zolang een tag zijn krediet hoger is dan nul zal hij nog worden teruggegeven.

Hier kan het begin-krediet worden opgegeven. Een goede waarde hiervoor is twee of drie.

5.4 ElpasEngine

Deze sectie werd geschreven door Wim Vandenberghe

Dit is de implementatie van de ContextEngine voor het RFID scenario gebaseerd op het

Elpas systeem. Deze is opgebouwd uit twee bouwstenen: een aparte thread en een timer.

De thread zal de verbinding maken met de Elpaslistener service, en daarna blijven luisteren

naar binnenkomende boodschappen. Telkens een boodschap binnenkomt zal het tijdskrediet van

het daarbij horende ID terug op zijn beginwaarde worden gezet. Tevens zal een contextevent

worden opgegooid met de recenste lijst van ID’s. Uiteraard zal ook in de ElpasEngine de mapping

uit het contextInfo.xml bestand worden gevolgd.

De timer zal om de seconde alle tijdskredieten met een verminderen. Alle ID’s waarvan dit

nul is geworden zullen worden verwijderd. De andere worden in een array gestopt en gesorteerd

volgens tijdskrediet. Indien er ID’s werden verwijderd zal de array worden doorgegeven aan

CaReport. De timer staat tevens in voor de periodieke controle van de verbinding met de

server. Een interne teller wordt bijgehouden en om de seconde vermeerderd. Wanneer deze

gelijk is aan een drempelwaarde zal de connectie worden gecontroleerd en eventueel hersteld.

De drempelwaarde zal daarna weer op nul worden gezet.

Ook in de ElpasEngine kunnen een aantal parameters worden ingesteld, zoals te zien in

figuur 5.3. We bespreken ze kort.

• Naam reader/tag

5.4 ElpasEngine 57

Figuur 5.3: Instellingen ElpasEngine

De client moet zich onder een bepaalde naam registreren. Deze hangt af van de modus

waarin de server gebruikt wordt. Wanneer we werken met vaste LF readers moet men

inloggen onder de naam van de tag die de verpleegkundige bij zich draagt. In het andere

geval moet dit de naam van de LF reader zijn. De namen moeten overeenkomen met een

naam die ingesteld werd in de Eiris server.

• Server

Hier kan de DNS naam van de server worden ingegeven. Het gebruik van de DNS naam

heeft het voordeel dat de server steeds zal gevonden worden, ook al wijzigt het IP van de

5.5 BluetoothEngine 58

server. Dit is niet ondenkbaar in een netwerk dat automatisch wordt geconfigureerd aan

de hand van een DHCP server.

• Timeout connectie

Dit is de drempelwaarde die door de timer wordt gebruikt voor de periodieke controle

van de verbinding met de server. Met andere woorden bepaalt deze instelling het interval

waarna steeds de verbinding zal worden gecontroleerd en eventueel hersteld.

• Poort server

Dit is het poortnummer waarop de Elpaslistener service luistert naar binnenkomende con-

necties.

• Tijdskrediet

Er werd reeds vermeld dat na het binnenkomen van een ID deze voor een bepaalde tijd

zal getoond worden vooraleer deze weer uit de lijst van nabije personen wordt verwijderd.

Deze tijd wordt bepaald door middel van een tijdskrediet. Dit kan hier ingesteld worden.

5.5 BluetoothEngine

Deze sectie werd geschreven door Pieter De Mil

Met behulp van deze BluetoothEngine werd de Bluetooth-oplossing uit hoofdstuk 3 getest.

Dankzij een BluetoothCom object, afgeleid van de abstracte DeviceCom klasse, kunnen we nu

gegegevens versturen en ontvangen naar de Linux host pc. Deze laatste zal een verbinding

opzetten, waardoor de PDA een binnenkomende verbinding zal ontvangen. Dit gebeurt op

COM poort 5. Via de methode ondervraag() kunnen we nu een poll-bericht versturen naar

de Bluetooth-adapter, aangesloten op de Linux host pc. Het interval tussen de verschillende

poll-berichten staat vast ingesteld op 1s. Het perl-script op de Linux host pc zal een identifi-

catie nummer terugsturen. Dit wordt aan de hand van de xml-mapping omgezet naar de juiste

patient naam. Aangezien we de signaalsterkte gebruiken, kunnen we een drempelwaarde instel-

len. Alle antwoorden met een signaalsterkte boven deze drempelwaarde worden getoond aan de

verpleegkundige.

In Figuur 5.4 zien we de instelbare parameters. Deze worden kort besproken.

• Com poort

5.5 BluetoothEngine 59

Figuur 5.4: Instellingen BluetoothEngine

Aangezien we werken met een binnenkomde verbinding, moet hier COM-poort 5 worden

ingesteld. Dit is meestal de standaard poort voor inkomende Bluetooth-verbindingen. Men

kan deze COM-poort wijzigen indien we willen testen via de emulator. We moeten dan de

Bluetooth-convertor aansluiten via een seriele kabel op COM-poort 1 of 2.

• Gevoeligheid

Wanneer de opgemeten linkkwaliteit zich boven deze ingestelde drempel bevindt, dan is

de patient dichtbij. 255 is de maximumwaarde. Een ingestelde waarde van 0 betekent dat

we alle patienten binnen het bereik van de PDA op het scherm zullen tonen.

5.6 ZigBeeEngine 60

5.6 ZigBeeEngine

Deze sectie werd geschreven door Pieter De Mil

Om de ZigBee-oplossing uit hoofdstuk 2 te testen werd de ZigBeeEngine afgeleid van de

abstracte DeviceCom klasse. We kunnen nu gegevens versturen naar de VER-module en om-

gekeerd. Het is de PDA die de verbinding zal opzetten, zodat we tijdens de mobiele opstelling

COM-poort 8 gebruiken. Het interval tussen de verschillende poll-berichten staat vast ingesteld

op 1s. De VER-module zal de verschillende antwoorden terugsturen naar da PDA. Deze wor-

den aan de hand van de xml-mapping omgezet naar de juiste patient namen. Aangezien we

de signaalsterkte gebruiken, kunnen we een drempelwaarde instellen. Alle antwoorden met een

signaalsterkte boven deze drempelwaarde worden getoond aan de verpleegkundige.

In Figuur 5.5 zien we de instelbare parameters. Deze worden kort besproken.

• Verpleegkundige

Er werden twee modules voorzien voor de verpleegkundige. Deze hebben intern een ver-

schillend identificatie-nummer. Dit kan ingesteld worden door ofwel “Inge” (= FE) of

“Pieter” (= FD) te kiezen.

• COM-poort

Hier werken we met een uitgaande Bluetooth-verbinding naar de Bluetooth-convertor. De

typische COM-poort hiervoor is 8. Dit is echter ook instelbaar om het testen via de

emulator mogelijk te maken. De VER-module wordt dan via een seriele kabel verbonden

met de PC.

• Gevoeligheid

De linkkwaliteit geeft een waarde tussen -20dBm en -90dBm. Hier betekent een waarde

van -20dBm dat men zich dicht bij een patient bevindt. Wanneer we nu de drempelwaarde

instellen op -53dBm, dan zullen alle antwoorden die groter zijn als nabije patienten worden

getoond. Bijvoorbeeld -20dBm, -48dBm.

5.6 ZigBeeEngine 61

Figuur 5.5: Instellingen ZigBeeEngine

BESLUIT 62

Hoofdstuk 6

Besluit

De scriptie omvat twee technologieen, ZigBee en Bluetooth. Elke technologie werd onderzocht op

zijn mogelijkheden om een contextgevoelige ziekenzorgtoepassing te realiseren. Het uitgangspunt

hierbij was het transparanter maken van de CaReport-applicatie. We wensten een systeem dat

het mogelijk maakt om te bepalen welke patient zich het dichtst bij een verpleegkundige bevindt.

Een extra vereiste was het feit dat er meerdere patienten per kamer kunnen zijn.

Bij elke technologie werd hetzelfde scenario geımplementeerd: de PDA-applicatie verstuurt

een poll-bericht met de vraag naar de huidige linkkwaliteit. Dit wordt opgemeten door de

ZigBee-modules of Bluetooth-adapters bij de patienten. Deze toestellen zullen de opgemeten

linkkwaliteit terugsturen naar de verzender van het poll-bericht (de verpleegkundige). In wat

volgt bespreken we de belangrijkste besluiten voor elke technologie. Als afsluiter van deze scriptie

beschrijven we enkele tips voor toekomstig werk.

6.1 ZigBee

Aangezien deze technologie zeer recent is, was er nog geen beschikbare literatuur omtrent con-

textgevoelige applicaties met behulp van 802.15.4 of ZigBee. Er was tot december 2004 zelfs

geen 802.15.4 MAC implementatie beschikbaar voor de gebruikte hardware modules. Er werd

daarom gewerkt met een SMAC implementatie voor de hardware modules. Dit is een afgeslankte

versie van de volledige 802.15.4 MAC laag. Een belangrijke beperking hierbij is dat verstuurde

berichten niet worden bevestigd. We versturen dan ook geen retransmissies in het geval er iets

fout loopt tijdens de transmissie van de pakketten. Het opgemeten foutenpercentage van de

ZigBee-oplossing bedroeg 0,83%. Dit is, gezien het gebruik van de SMAC implementatie, een

6.1 ZigBee 63

aanvaardbaar resultaat. De PDA-applicatie zal automatisch elke seconde een poll-bericht ver-

sturen. Tijdens de proeven werd opgemerkt dat een fout geen twee maal na elkaar voorkomt.

In het slechtste geval moet de verpleegkundige dus een seconde langer wachten op het resultaat.

Men kan dit foutenpercentage verder reduceren door gebruik te maken van de 802.15.4 MAC

implementatie. Hierbij zal men dan wel retransmissies kunnen verzenden. Dit is ook noodzake-

lijk aangezien er bij eender welke draadloze technologie telkens pakketten zullen botsen. Toen

de 802.15.4 MAC implementatie beschikbaar werd was het te laat om over te schakelen. Daarom

is er gekozen om niet zelf retransmissies te implementeren.

Verder werd er een bruikbaar verband tussen de linkkwaliteit en de afstand genoteerd. Dit

verband is noodzakelijk omdat we ons baseren op de linkkwaliteit om te bepalen welke patient

zich het dichtst bij de verpleegkundige bevindt. Dankzij deze betrouwbare en stabiele informatie

werkt de gerealiseerde oplossing ook in kamers met meerdere patienten. De hardware modules

bij de patienten mogen zich zelfs op 1 meter van elkaar bevinden, het blijft nog altijd mogelijk

om te bepalen wie zich het dichtst bij de verpleegkundige bevindt.

Wat betreft de mogelijk storende invloed van Bluetooth werd vastgesteld dat het foutenper-

centage verhoogt tot 1,27%, indien er in de onmiddellijke buurt een bestand wordt verstuurd

via Bluetooth. In deze scriptie werd telkens het slechtste geval getest, met de stoorbron tussen

de verschillende hardware modules. Een andere stoorbron was de microgolfoven. De invloed

hiervan is duidelijk groter. Er werd een foutenpercentage van 40% genoteerd. Hierbij waren de

hardware modules ingesteld op dezelfde frequentie als de microgolfoven. Een eerste oplossing

hiervoor was het instellen van een ander kanaal bij de hardware modules. Het foutenpercentage

daalde tot 10%. Om dit verder te reduceren hebben we opnieuw nood aan retransmissies van

pakketten.

De firmware van de modules werd, als extra, uitgebreid met de mogelijkheid om bestanden

te versturen of een tekstgesprek te voeren. Het bestand dat we wensen te versturen wordt

opgedeeld in blokken van 117 bytes. De bovenliggende applicatie die dit moet regelen is echter

niet afgewerkt.

We kunnen besluiten dat de ZigBee-oplossing bruikbaar is voor de contextgevoelige applicatie

die werd voorgesteld. Hoewel de resultaten zeker aanvaardbaar zijn, kan deze oplossing nog

verder geoptimaliseerd worden. Tips hiervoor volgen in Sectie 6.3.

6.2 Bluetooth 64

6.2 Bluetooth

De Bluetooth technologie is door de jaren heen een volwassen en wijd verspreide standaard ge-

worden. De gebruikte Bluetooth-adapters zijn compatibel met de Bluetooth 1.1 specificatie. De

belangrijkste beperking hiervan is dat we eerst een verbindingssessie moeten opzetten alvorens

we de linkkwaliteit kunnen opmeten. Bij elke patient staat een PC met een GNU/Linux be-

sturingssysteem. Hierop wordt een Bluetooth-adapter aangesloten. Het opzet werd hier licht

gewijzigd. Het is de verantwoordelijkheid van de PC om een verbindingssessie op te zetten

tussen de PC en de PDA van de verpleegkundige. Het perl-script op de PC zal dus eerst een

scan uitvoeren. Dit kan tot 12 seconden in beslag nemen. Wanneer er een verpleegkundige in de

buurt is, zal er een verbinding worden opgezet. Dankzij deze verbinding kan de verpleegkundige

nu poll-berichten versturen en de opgemeten linkkwaliteit opvragen.

Tijdens de proeven stelden we vast dat het verband tussen de linkkwaliteit en de afstand niet

bruikbaar is. Het is gebleken dat de linkkwaliteit wel daalt maar terug maximaal wordt. De ver-

klaring voor deze onstabiele informatie is dat de Bluetooth-adapter de linkkwaliteit gebruikt om

te bepalen of de verbinding optimaal is. Indien de linkkwaliteit daalt zal de Bluetooth-adapter

het zendvermogen verhogen tot als de maximale linkkwaliteit of het maximale zendvermogen

wordt bereikt. Op grote afstanden zal eerder de limiet van het maximale zendvermogen bereikt

worden, waardoor de linkkwaliteit niet maximaal is maar wel bruikbaar. In de vooropgestelde

ziekenzorgtoepassing vereisten we dat het verschil tussen verschillende patienten in dezelfde ka-

mer moet kunnen bepaald worden. Dit zijn typisch kortere afstanden waarbij de linkkwaliteit

maximaal zal zijn, en dus niet bruikbaar.

Interferentie van andere technologieen of Bluetooth zelf wordt vermeden door de frequency

hopping techniek. Er wordt tijdens het versturen van pakketten tot maximaal 1600 keer per

seconde naar een ander kanaal gesprongen. Wanneer nu een pakket op een bepaald kanaal botst,

zal het de volgende keer op een andere kanaal worden verzonden. Zelfs een microgolfoven kan

de goede werking van Bluetooth niet storen. Het informatieverlies blijft nihil. We merkten wel

op dat de linkkwaliteit daalt wanneer de microgolfoven is ingeschakeld.

Als conclusie kunnen we stellen dat de voorgestelde Bluetooth-oplossing niet bruikbaar is

voor dit contextgevoelig ziekenzorgscenario.

6.3 Toekomstig werk 65

6.3 Toekomstig werk

Om het foutenpercentage bij de ZigBee-oplossing te doen dalen moet men overschakelen naar

de 802.15.4 MAC implementatie. Met behulp van retransmissies kan men het aantal fouten

aanzienlijk doen dalen en ideaal op 0% brengen. De mogelijke interferentie van Bluetooth en

de microgolfoven kunnen dan opnieuw getest worden. Een andere technologie, die echter niet

aan bod kwam in deze scriptie, is Wi-Fi. Er is reeds onderzoek gedaan naar de mogelijkhe-

den om interferentie met Wi-Fi te vermijden. Een interessant artikel hierbij is [Zig05]. In de

huidige ZigBee-oplossing zullen de modules bij de patienten constant luisteren naar nieuwe poll-

berichten. Dit heeft natuurlijk een negatieve invloed op de levensduur van de batterijen. In

de 802.15.4 MAC implementatie is er echter een mechanisme dat dit kan aanpakken: de zoge-

naamde “beacon-mode”. Hierbij zullen de modules gesynchroniseerd worden en telkens op een

bepaald ogenblik in de tijd luisteren naar nieuwe poll-berichten. Dit maakt het mogelijk om de

modules gedurende 99% van de tijd te laten “slapen”.

Indien we dezelfde contextgevoelige applicatie met behulp van Bluetooth wensen te maken,

dan moet er overgeschakeld worden naar 1.2 compatibele Bluetooth-adapters. Volgens de speci-

ficatie is het bij deze mogelijk om de linkkwaliteit te meten zonder eerst een verbinding te maken.

De hypothese is dat het zendvermogen van de Bluetooth-adapter niet zal stijgen, aangezien er

geen verbinding wordt opgezet. Hierdoor kan de linkkwaliteit informatie betrouwbaar zijn. Nu

er meer en meer 1.2 compatibele adapters op de markt verschijnen is dit een te onderzoeken

piste.

BIBLIOGRAFIE 66

Bibliografie

[Blu] Bluez: Official linux bluetooth protocol stack. http://www.bluez.org/.

[BTA] Btaccess: High-point software. http://www.high-point.com/.

[Cal01] E. Callaway. Cluster tree network. april 2001.

http://grouper.ieee.org/groups/802/15/pub/2001/May01/01189r0P802-15 TG4-

Cluster-Tree-Network.pdf.

[CGH+02] E. Callaway, P. Gorday, L. Hester, J.A. Gutierrez, M. Naeve, B. Heile, and V. Bahl.

Home networking with ieee 802.15.4: a developing standard for low-rate wireless

personal area networks. IEEE Communications Magazine, 40(8):70–77, August 2002.

[DW05] S. De Wilde. Contextgevoelige pda-applicatie voor de thuiszorg, op basis van gpsin-

formatie. Master’s thesis, Universiteit Gent, mei 2005.

[JKKG01] P. Johansson, M. Kazantzidis, R. Kapoor, and M. Gerla. Bluetooth: an enabler for

personal area networking. IEEE Network, 15(5):28–37, Sep/Oct 2001.

[RP00] Elizabeth M. Royer and Charles E. Perkins. An implementation stu-

dy of the aodv routing protocol. In Proceedings of the IEEE Wire-

less Communications and Networking Conference, Chicago, september 2000.

http://www.cs.ucsb.edu/∼ebelding/txt/wcnc impl.ps.

[Sem04] Freescale Semiconductor. MC9S08GT60 datasheet, december 2004.

http://www.freescale.com/files/microcontrollers/doc/data sheet/MC9S08GB60.pdf.

[SIG] The bluetooth special interest group. https://www.bluetooth.org/.

[Soc03] IEEE Computer Society. Part 15.4: Wireless medium access control (mac)

and physical layer (phy) specifications for low-rate wireless personal area net-

BIBLIOGRAFIE 67

works (lr-wpans). Technical report, IEEE Computer Society, mei 2003.

http://standards.ieee.org/getieee802/download/802.15.4-2003.pdf.

[Van05] W. Vandenberghe. Gebruik van actieve rfid voor context-aware ziekenzorgtoepassin-

gen. Master’s thesis, Universiteit Gent, mei 2005.

[Zig04] Network layer technical overview. Technical report, ZigBee Alliance,

2004. http://www.zigbee.org/en/documents/ZigBee-Network-Layer-Technical-

Overview.pdf.

[Zig05] Avoiding rf interference between wifi and zigbee. Technical report, Crossbow, 2005.

Vergelijkende studie van ZigBee en Bluetooth voor context ......ZIGBEE 4 Hoofdstuk 2 ZigBee Dit...

Documents

Transcript of Vergelijkende studie van ZigBee en Bluetooth voor context ......ZIGBEE 4 Hoofdstuk 2 ZigBee Dit...