Page 1
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
Page 2
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
Page 3
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
Page 4
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
Page 5
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.
Page 6
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
Page 7
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
Page 8
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
Page 9
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
Page 10
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
Page 11
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
Page 12
1.3 Overzicht 3
mogelijk verder onderzoek.
Page 13
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
Page 14
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)
Page 15
2.1 Achtergrondinformatie 6
• 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:
Page 16
2.1 Achtergrondinformatie 7
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
Page 17
2.1 Achtergrondinformatie 8
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
Page 18
2.1 Achtergrondinformatie 9
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;
• . . .
Page 19
2.1 Achtergrondinformatie 10
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 zend- en 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
Page 20
2.1 Achtergrondinformatie 11
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
Page 21
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
Page 22
2.2 Werk verricht 13
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.
Page 23
2.2 Werk verricht 14
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
Page 24
2.2 Werk verricht 15
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
Page 25
2.2 Werk verricht 16
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
Page 26
2.2 Werk verricht 17
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:
Page 27
2.2 Werk verricht 18
• 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.
Page 28
2.2 Werk verricht 19
• 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
Page 29
2.2 Werk verricht 20
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.
Page 30
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
Page 31
2.3 Analyse van de proeven 22
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
Page 32
2.3 Analyse van de proeven 23
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
Page 33
2.3 Analyse van de proeven 24
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.
Page 34
2.3 Analyse van de proeven 25
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
Page 35
2.3 Analyse van de proeven 26
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
Page 36
2.3 Analyse van de proeven 27
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
Page 37
2.3 Analyse van de proeven 28
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
Page 38
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.
Page 39
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.
Page 40
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
Page 41
3.1 Achtergrondinformatie 32
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
Page 42
3.1 Achtergrondinformatie 33
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-
Page 43
3.1 Achtergrondinformatie 34
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
Page 44
3.2 Werk verricht 35
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
Page 45
3.2 Werk verricht 36
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
Page 46
3.2 Werk verricht 37
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.
Page 47
3.2 Werk verricht 38
• 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.
Page 48
3.2 Werk verricht 39
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
20 bytes from 00 : 0 4 : 3E: 6 8 : 3C: 6B id 1 time 37 .29ms
20 bytes from 00 : 0 4 : 3E: 6 8 : 3C: 6B id 2 time 35 .28ms
20 bytes from 00 : 0 4 : 3E: 6 8 : 3C: 6B id 3 time 26 .26ms
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 ;
Page 49
3.2 Werk verricht 40
# 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.
Page 50
3.3 Analyse van de proeven 41
• 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.
Page 51
3.3 Analyse van de proeven 42
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.
Page 52
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.
Page 53
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-
Page 54
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,
Page 55
4.2 Interferentie tussen beide 46
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
Page 56
4.2 Interferentie tussen beide 47
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.
Page 57
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%.
Page 58
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
Page 59
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.
Page 60
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.
Page 61
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
Page 62
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.
Page 63
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
Page 64
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.
Page 65
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
Page 66
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
Page 67
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
Page 68
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.
Page 69
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.
Page 70
5.6 ZigBeeEngine 61
Figuur 5.5: Instellingen ZigBeeEngine
Page 71
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
Page 72
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.
Page 73
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.
Page 74
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.
Page 75
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-
Page 76
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.