GPRS-convergentielaag voor location aware computing in de ziekenzorg

Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Een transparante Bluetooth/GPRS-convergentielaag voor location aware computing in de ziekenzorg door Evy TROUBLEYN

Promotoren: Prof. Dr. Ir. I. MOERMAN, Dr. Ir. P. VERHOEVE Scriptiebegeleiders: B. JOORIS, Ir. J. HOEBEKE In samenwerking met Televic N.V.

Scriptie ingediend tot het behalen van de academische graad van burgerlijk elektrotechnisch ingenieur

Academiejaar 2006–2007

Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Een transparante Bluetooth/GPRS-convergentielaag voor location aware computing in de ziekenzorg door Evy TROUBLEYN

Promotoren: Prof. Dr. Ir. I. MOERMAN, Dr. Ir. P. VERHOEVE Scriptiebegeleiders: B. JOORIS, Ir. J. HOEBEKE In samenwerking met Televic N.V.

Scriptie ingediend tot het behalen van de academische graad van burgerlijk elektrotechnisch ingenieur

Academiejaar 2006–2007

Voorwoord Deze thesis zou niet zijn wat hij is zonder de steun en de hulp van vele mensen. Graag zou ik dan ook iedereen willen bedanken die een bijdrage, hoe klein ook, geleverd heeft om deze thesis te helpen maken tot wat hij is. Enkele mensen verdienen hierbij een speciale vermelding. In de eerste plaats wil ik mijn promotoren Ingrid Moerman en Piet Verhoeve bedanken. Zij hebben mij de mogelijkheid en het vertrouwen gegeven om deze thesis uit te voeren. Zonder hen zou er van deze boeiende zoektocht in de wereld van Bluetooth en GPRS geen sprake geweest zijn. Ook wil ik Televic bedanken om dit project mede mogelijk te maken. Graag wil ik ook mijn begeleiders Bart Jooris en Jeroen Hoebeke bedanken. In het bijzonder bedank ik Bart voor de permanente opvolging van mijn thesis, voor de nodige tips en tricks en voor de fijne samenwerking. Ik wil ook Tom Deweerdt bedanken voor de vlotte samenwerking tijdens de stage en gedurende het academiejaar. Verdere bedankingen gaan uit naar Nicolas Staelens voor de programmeerhulp tijdens de eerste weken. Dankzij hem begon ik langzaam door de bomen het bos weer te zien wat betreft het maken en compileren van dll’s. Een speciaal woordje van dank gaat uit naar mijn ventje Maarten. Ik wil hem bedanken voor de steun, niet enkel dit jaar maar ook de voorbije jaren. Het doet goed om te weten dat er iemand is die altijd achter je staat, ook op de moeilijke momenten. Verder wil ik hem ook bedanken om mij steeds met raad en daad bij te staan, en voor het op zich nemen van de kleine en grote zorgen die bij de renovatie van ons huisje kwamen kijken. In het bijzonder wil ik mijn ouders, Jeannette en Willy, bedanken omdat ze mij de mogelijkheid gegeven hebben om deze studies aan te vatten en voor hun nooit aflatende steun. Ik wens ook mijn broer Davy bedanken voor de hulp de voorbije jaren. Tot slot wil ik alle andere mensen bedanken die, elk op hun manier, hebben bijgedragen tot deze thesis, gaande van het zorgvuldig nalezen op fouten tot het geven van waardevol advies en mij een beetje opmonteren op moeilijke momenten. Pieter-Paul, Jan, Guus, Sophie, Marie-Claire. Bedankt!

Toelating tot bruikleen “De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”

Evy Troubleyn, juni 2007

Een transparante Bluetooth/GPRS-convergentielaag voor location aware computing in de ziekenzorg door Evy TROUBLEYN Scriptie ingediend tot het behalen van de academische graad van burgerlijk elektrotechnisch ingenieur Academiejaar 2006–2007 Promotoren: Prof. Dr. Ir. I. MOERMAN, Dr. Ir. P. VERHOEVE Scriptiebegeleider: B. JOORIS, Ir. J. HOEBEKE In samenwerking met Televic N.V. Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Samenvatting Televic is een West-Vlaamse onderneming die hoogtechnologische producten ontwikkelt en oplossingen levert voor audio-, multimedia- en communicatiemarkten. Eén van hun onderzoeksdomeinen concentreert zich op de ontwikkeling van systemen voor de gezondheidszorg. Omdat Televic voortdurend onderzoek verricht naar nieuwe technologieën en systemen om nog beter tegemoet te komen aan de noden en de wensen van de gezondheidszorg, werd deze thesis uitgeschreven. De doelstelling van deze thesis is het ontwikkelen van een netwerkoplossing die toelaat dat een verpleegkundige een foto kan nemen van een wonde van een patiënt en dat deze foto op een transparante manier een centrale server bereikt. We bekijken eerst de ontwikkeling van een transparante foto-overdracht tussen een fototoestel en een PDA. Vervolgens bekijken we hoe we de foto transparant over het netwerk kunnen versturen. We ontwikkelen hiervoor een Bluetooth/GPRS-convergentielaag die op basis van een aantal parameters de foto via de juiste weg naar de server zal routeren. Ook het belang van privacy en security zal hierbij aan bod komen.

Trefwoorden Bluetooth, GPRS, SMS, netwerkoplossing, ziekenzorg

A transparent Bluetooth/GPRS convergence layer for location aware computing in healthcare Evy Troubleyn Supervisor(s): Ingrid Moerman, Piet Verhoeve, Bart Jooris, Jeroen Hoebeke Abstract— This article describes a network solution for healthcare computing. We focus on the situation where a nurse wants to take a picture of a patient and send it in a safe and transparent way to a server. We introduce a transparent Bluetooth/GPRS convergence layer as underlying transport mechanism. Keywords—Bluetooth, GPRS, SMS, network solution, healthcare

I. I NTRODUCTION Televic [1] is a Belgian company which develops and manufactures a wide range of products and solutions for audio, multimedia and communication markets. One of their business units concentrates on healthcare.

Fig. 1. Healthcare network

Figure 1 shows the global healthcare network situation. In the circle we see the nurse’s environment. Each nurse has her own mobile phone, digital camera and PDA. In the following, we call the PDA an Interactive Nurse Terminal (INT) which is a Pocket PC with Windows Mobile 5.0. All these devices communicate using Bluetooth. In the center of Figure 1 we see the patient’s environment. The Interactive Patient Terminal (IPT) is a Windows XP computer which contains a large touchscreen. This makes it easier for the nurse to fill in the relevant patient information. Both the INT and the IPT contain the CaReport software. With this software suite, the nurse can consult the schedule, the tasks she has to perform and the medical files which can be updated with the current temperature, blood pressure and extra remarks. Now, we want a nurse to be able to take a picture of an injury and send this picture to the central CaReport server. The whole process must be as transparent as possible to the nurse. We make use of Bluetooth and GPRS as underlying transport mechanisms. In the whole healthcare network, security and privacy are very important. Only an allowed nurse can have access to the CaReport server. In case of emergency, we want a nurse to be able

to request a SMS message which contains the necessary keys to get access to the server. II. O BJECT P USH P HOTO S ERVICE We first studied the possibilities to push the picture of an injury to the INT. For this purpose, we used a Kodak EasyShare V610 digital camera with Bluetooth 2.0 + EDR technology which contains the Object Push Protocol to transfer pictures to another device. We want to receive the picture on the INT, a HP iPAQ hx2790. This PDA contains a default Object Push Service to receive a pushed file. Normally, the Object Push Service is used to receive business cards (vcards). When using the default Object Push Service, we concluded that it isn’t transparent enough for our purposes. Every time we receive a picture, a new window appears asking how and where we want to save the picture. This is of course very annoying. We decided to implement our own Object Push Service for PDA. For the implementation, we used an software library, Franson BlueTools SDK v1.2b [2]. This SDK simplifies the implementation of several Bluetooth functionalities. The implemented Object Push Service can receive the picture in a completely transparent way. III. R ECEIVING AN SMS MESSAGE Receiving an SMS message is a very important part in the healthcare network solution, especially in case of emergency. We added a button in the CaReport software suite that can be used to read an SMS message from a mobile phone. For this purpose, we used the Bluetooth Serial Port Service on the mobile phone. Over this Bluetooth link, we send AT-commands to the mobile phone, which answers with the requested SMS message. IV. C ONVERGENCE LAYER

Fig. 2. Convergence Layer

The most important part of this article is the development of a Bluetooth/GPRS convergence layer. This layer will be used for the communication between the INT and the CaReport server. The convergence layer consists of two parts: a Bluetooth communication path and a GPRS communication path, which can both be seen in Figure 2. The Bluetooth communication path was developed last year by Tom Pluym [3]. He created a transparent network with the IPT as central router. Each INT can connect to this router and send messages to the IPT or another INT. Originally it was not intended to send messages to an external server. The first thing we had to do was extend the currently available Bluetooth communication path in such way that it becomes possible to send pictures directly to the CaReport server. This extended network is shown in Figure 3.

gence layer, it just indicates how long it takes to send the picture with TCP over GPRS. We only consider the case of GPRS here because GPRS is much more sensitive than Bluetooth.

Fig. 4. Transmission Time Convergence Layer

We can see it is a huge improvement when we consider the UDP full-duplex implementation. For Bluetooth the transmission time reduces from 3,4 to 2,1 seconds and for GPRS from 35,6 to 23,2 seconds. If we compare the GPRS UDP full-duplex transmission time with the TCP transmission time, we see that the UDP full-duplex implementation is a little faster. A problem arose when we merged the Bluetooth communication path en the GPRS communication path together. First of all, we noticed that it is necessary to start the GPRS communication path before the Bluetooth communication path. Secondly, we noticed that if the Bluetooth communication path fails, no traffic gets over the Bluetooth link while the Bluetooth communication path tries to reconnect. The cause of these problems lies in the fact that most Bluetooth hardware can’t handle device discovery and active Bluetooth connections simultaneously. V. I NTEGRATION

Fig. 3. Extended Transparent Network

We also have a GPRS communication path. This communication path was set up by using an intermediate mobile phone with GPRS modem. For the communication between the INT and the mobile phone we chose Bluetooth. In contrary to IrDA, we don’t need a line-of-sight. To activate the GPRS connection on the INT, we use the Connection Manager and the Connection Manager API. The convergence layer is an intelligent layer which switches between the Bluetooth communication path and the GPRS communication path. Bluetooth will always be preferred. Only when this link isn’t available, we switch to GPRS. Figure 4 shows the transmission time for a picture of 46304 bytes. We compare for both Bluetooth and GPRS two different implementations: an optimal UDP half-duplex implementation and a UDP full-duplex implementation. In the case of GPRS we compare the convergence layer to a normal TCP transport. This implementation has further more nothing to do with the conver-

Now that we have all the necessary building blocks, we can make an integration. Just like we must first start the GPRS communication path before the Bluetooth communication path, we must also start the Object Push Photo Service before the Bluetooth communication path. Otherwise we have problems caused by the device discovery. Once the device discovery is done, we don’t have further problems with simultaneously active Bluetooth connections. VI. C ONCLUSION Most problems were caused by the device discovery for the Bluetooth communication path and other simultaneaously active Bluetooth connection. For this reason, it may be interesting to use a PDA with a built-in GPRS modem as INT. This way, we avoid already one disturbing Bluetooth connection. R EFERENCES [1] Televic, http://www.televic.com/ [2] Franson BlueTools SDK, http://franson.com/bluetools/ [3] Tom Pluym, Transparante Bluetooth netwerkoplossing voor context-aware ziekenzorgtoepassingen, 2006, UGent

INHOUDSOPGAVE

i

Inhoudsopgave Tabel van afkortingen

iv

1 Inleiding

1

1.1

Situering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.3

Doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.4

Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2 Foto-overdracht tussen digitale camera en IVT

6

2.1

Keuze digitale camera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.2

Implementatie van de foto-overdracht

. . . . . . . . . . . . . . . . . . . . . . . .

7

2.2.1

Implementatie via de standaard Object Push Service . . . . . . . . . . . .

8

2.2.2

Implementatie en gebruik van een eigen Object Push Service . . . . . . .

9

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.3

3 Een GSM als GPRS modem

12

3.1

Situering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.2

Wat is GPRS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.3

Communicatie tussen PDA en GSM: Infrarood of Bluetooth? . . . . . . . . . . .

17

3.3.1

IrDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.3.2

Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

Het instellen van de GPRS-verbinding op de PDA . . . . . . . . . . . . . . . . .

19

3.4.1

Algemene werkwijze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.4.2

Specifieke instellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

Aanspreken van de GPRS-verbinding vanuit de applicatie . . . . . . . . . . . . .

25

3.5.1

Connection Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

3.5.2

Connection Manager API . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.4

3.5

INHOUDSOPGAVE

3.6

ii

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4 SMS

28

4.1

Situering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

4.2

Wat is SMS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.3

Bluetooth als communicatieprotocol tussen PDA en GSM . . . . . . . . . . . . .

30

4.4

Implementatie via de Franson BlueTools SMS SDK . . . . . . . . . . . . . . . . .

30

4.4.1

Bluetooth-pairing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.4.2

Connecteren van de GSM met de PDA over Bluetooth vanuit de SMSapplicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4.4.3

Selecteren van de gewenste service . . . . . . . . . . . . . . . . . . . . . .

32

4.4.4

Uitlezen SMS-berichten . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

Implementatie via AT commando’s . . . . . . . . . . . . . . . . . . . . . . . . . .

33

4.5.1

Wat zijn AT commando’s?

. . . . . . . . . . . . . . . . . . . . . . . . . .

33

4.5.2

Uitlezen van SMS via AT commando’s . . . . . . . . . . . . . . . . . . . .

35

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

4.5

4.6

5 Bluetooth/GPRS-convergentielaag

38

5.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

5.2

Bluetooth-communicatielaag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

5.2.1

Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

5.2.2

Transmissiesnelheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

GPRS-communicatielaag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

5.3.1

Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

5.3.2

Transmissiesnelheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

Convergentielaag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

5.4.1

Algemene architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

5.4.2

Communicatieprotocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

Implementatie van de convergentielaag . . . . . . . . . . . . . . . . . . . . . . . .

49

5.5.1

“Connections” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

5.5.2

“Stream” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

5.5.3

Verband tussen “Connections” en “Stream” . . . . . . . . . . . . . . . . .

53

Resultaten en Performantie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

5.6.1

55

5.3

5.4

5.5

5.6

Half-duplex implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . .

INHOUDSOPGAVE

5.7

iii

5.6.2

Full-duplex implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

5.6.3

GPRS: Convergentielaag versus TCP . . . . . . . . . . . . . . . . . . . . .

60

5.6.4

Wisselwerking tussen het Bluetooth-communicatiepad en het GPRS-communicatiepad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

6 Integratie in de CaReport-software

64

6.1

Integratie van de eigen bouwblokken . . . . . . . . . . . . . . . . . . . . . . . . .

64

6.2

Integratie in de CaReport-applicatie . . . . . . . . . . . . . . . . . . . . . . . . .

65

6.3

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

7 Besluit

67

A Ontwikkelen van Windows Mobile 5.0 PPC Applicaties

69

A.1 Aanmaken van een nieuwe Windows Mobile 5.0 applicatie . . . . . . . . . . . . .

69

A.1.1 Benodigde hardware en software . . . . . . . . . . . . . . . . . . . . . . .

69

A.1.2 Aanmaken van een nieuw project . . . . . . . . . . . . . . . . . . . . . . .

70

A.1.3 Programmeren van de applicatie . . . . . . . . . . . . . . . . . . . . . . .

71

A.1.4 Compileren en deployen van de applicatie . . . . . . . . . . . . . . . . . .

72

A.2 Omzetten van een Windows Mobile 2003 applicatie naar een Windows Mobile 5.0 applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

B Franson BlueTools

74

B.1 Installatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

B.2 Extra installatie bij .NET Compact Framework . . . . . . . . . . . . . . . . . . .

74

B.3 Opmerkingen bij de licentiecode . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

C GPRS-architectuur

76

D PDP, MT en TE

78

E Specifieke GPRS-modemcommando’s

79

F De structuur van ConnectionInfo

81

Bibliografie

86

Lijst van figuren

88

Lijst van tabellen

91

TABEL VAN AFKORTINGEN

Tabel van afkortingen API

Application Programming Interface

AuC

Authentication Center

BSC

Base Station Controller

BTS

Base Transceiver Station

DCE

Data Communication Equipment

DTE

Data Terminal Equipment

FIR

Fast Infrared

GGSN

Gateway GPRS Support Node

GPRS

General Packet Radio Service

GR

GPRS Register

GSM

Global System for Mobile communication

GSN

GPRS Support Nodes

GUID

Globally Unique Identifier

HLR

Home Location Register

IPT

Interactieve Patiënten Terminal

IrDA

Infrared Data Associaton

IVT

Interactieve Verpleegster Terminal

LED

Light Emitting Diode

ME

Mobile Equipment

MIR

Medium Infrared

MMS

Multimedia Messaging Service

MS

Mobile Station

MSC

Mobile Switching Center

MT

Mobile Termination

iv

TABEL VAN AFKORTINGEN

MTU

Maximum Transfer Unit

PDA

Personal Digital Assistant

PDP

Packet Data Protocol

PDU

Protocol Description Unit

PIE

Pocket Internet Explorer

PSTN

Public Switched Telephone Network

RTT

Round Trip Time

SGSN

Serving GPRS Support Node

SIG

Bluetooth Special Interest Group

SIM

Subscriber Identity Module

SIR

Serial Infrared

SM

SIM card

SMS

Short Message Service

TCP

Transmission Control Protocol

TE

Terminal Equipment

UDH

User Data Header

UDP

User Datagram Protocol

UFIR

Ultra Fast Infrared

UTMS

Universal Mobile Telecommunications System

VFIR

Very Fast Infrared

VLR

Visitor Location Register

WAP

Wireless Application Protocol

v

INLEIDING

1

Hoofdstuk 1

Inleiding In dit inleidende hoofdstuk geven we een schets van het algemene kader waarbinnen deze thesis zich situeert. We bespreken de probleemstelling en de daaruit voortvloeiende concrete doelstellingen. Dit hoofdstuk wordt afgerond met een overzicht van wat er in de komende hoofdstukken aan bod zal komen.

1.1

Situering

We leven in een maatschappij waarin iedereen steeds mobieler wordt en onderworpen is aan een voortdurende interactie met zijn omgeving. Deze trend zet zich ook voort in de thuisverpleging. Door de steeds groter wordende vraag naar thuisverpleging wordt van de verpleegkundigen verwacht dat ze snel en efficiënt kunnen optreden. Een aantal hoogtechnologische snufjes kunnen hierbij het leven van de verpleegkundige aangenamer maken. Patiëntengegevens eerst op papier invullen en dan later nog eens in een computer ingeven is tijdrovend en nutteloos. Televic [1] is een West-Vlaamse onderneming die hoogtechnologische producten ontwikkelt en oplossingen levert voor audio-, multimedia- en communicatiemarkten. Een van hun onderzoeksdomeinen concentreert zich op de ontwikkeling van systemen voor de gezondheidszorg. We denken hierbij aan intercomsystemen, systemen voor zorgregistratie en systemen om de verpleegkundige op te roepen. Televic verricht voortdurend onderzoek naar nieuwe technologieën en systemen om nog beter tegemoet te komen aan de noden en de wensen van de gezondheidszorg.

1.2 Probleemstelling

2

Een van de vele ontwikkelingen van Televic is het softwarepakket CaReport. Dit softwarepakket werd speciaal ontwikkeld om het administratieve werk van de verpleegkundige te verlichten. Het laat de verpleegkundigen toe om voor de start van hun patiëntenronde de planning te downloaden die zal aangeven welke patiënten moeten bezocht worden en welke taken moeten uitgevoerd worden. De verpleegkundige kan aanduiden welke patiënten al bezocht zijn en welke taken uitgevoerd werden. Verder kunnen gegevens ingevuld worden zoals de bloeddruk en de temperatuur van de patiënt. Deze gegevens worden dan automatisch overgebracht naar een centrale server, zonder dat de verpleegkundige nog gegevens moet overtypen. De voorbije jaren werd dit softwarepakket verder uitgebreid. Eén van de uitbreidingen was location-awareness, zodat de verpleegkundige de juiste patiënt niet meer hoeft te selecteren uit een lijst, maar dat het juiste patiëntendossier automatisch geopend wordt van zodra de verpleegkundige in de buurt van de patiënt komt.

1.2

Probleemstelling

In het huidige CaReport systeem kan de verpleegkundige enkel gegevens invullen zoals temperatuur, bloeddruk en eventuele opmerkingen. Met de komst van de digitale camera’s willen we het echter mogelijk maken dat de verpleegkundige een foto kan nemen van een wonde van de patiënt en dat deze foto kan toegevoegd worden aan het patiëntendossier. Deze informatie komt dan op de centrale server terecht waar ook de behandelende artsen toegang tot hebben. De artsen kunnen dan op een snelle en eenvoudige manier de juiste diagnose stellen. Het versturen van een foto zal echter bijkomende eisen stellen aan de huidige software en het bestaande netwerk. Het algemene scenario is weergegeven in Figuur 1.1.

1.2 Probleemstelling

3

Figuur 1.1: Algemeen Scenario

Zoals reeds aangehaald is het de bedoeling dat een verpleegkundige een foto kan nemen met een digitaal fototoestel en dat deze foto vervolgens op een transparante manier een server bereikt. De verpleegkundige beschikt hiervoor over een aantal persoonlijke toestellen: een PDA (Pocket PC), een GSM en een digitaal fototoestel. De PDA zullen we in wat volgt de Interactieve Verpleegster Terminal (IVT) noemen. Elke verpleegster beschikt over een eigen PDA zodat de nodige privacy naar de patiënten toe gegarandeerd kan worden. Op elke PDA wordt de CaReport-software ge¨ınstalleerd. Naast de IVT is in het scenario ook een Interactieve Patiënten Terminal (IPT) aanwezig. Deze terminal is een vaste computer die beschikt over een groot aanraakscherm en die bij de patiënt thuis staat. Op deze computer wordt eveneens de CaReport-software ge¨ınstalleerd. In plaats van op het kleine IVT-scherm kan de verpleegkundige de uitgevoerde taken op het grote IPTscherm aanduiden en is het ook eenvoudiger om zaken zoals de temperatuur en de bloeddruk in te geven. De IPT beschikt over een vaste internetverbinding. Tussen de IPT en de IVT bestaat er reeds een transparante Bluetooth-communicatielaag die ontwikkeld werd door Tom Pluym [2]. We kunnen van deze communicatielaag gebruik maken om de foto van de IVT naar de IPT te sturen. Vanop de IPT moet de foto dan nog naar de centrale server gestuurd worden. Het kan nu gebeuren dat de verpleegkundige de patiënt verlaat, omdat alle taken uitgevoerd zijn, maar dat nog niet alle foto’s op de server toegekomen zijn. Op dat moment beschikken we niet meer over de Bluetooth-communicatielaag tussen de IVT en de IPT en zullen we alternatieve communicatiepaden moeten zoeken. Eén van de mogelijkheden is overschakelen naar GPRS. In dit geval wordt via de GSM een internetverbinding opgezet die

1.3 Doelstelling

4

toelaat om de foto vanop de IVT naar de server te sturen. Het spreekt voor zich dat security en privacy hierbij een belangrijke rol spelen. Daarom moeten er tussen de IVT, de IPT en de server toegangssleutels uitgewisseld worden. In een normale situatie worden deze toegangssleutels via synchronisatie op de IVT geplaatst. Deze synchronisatie gebeurt vóór het begin van de werkdag en bevat de sleutels voor alle patiënten die op die dag moeten bezocht worden. Indien er echter in een noodsituatie een niet-geplande verpleegkundige bij een patiënt langskomt, zal deze niet over de juiste sleutels beschikken. Daarom is het wenselijk dat we in deze noodsituaties vlug sleutels kunnen uitwisselen. Dit zal gebeuren via een self-destructing SMS. Deze SMS wordt verstuurd aan de server-zijde, hetzij via een traditionele gsm, hetzij via een internet-service. Parallel aan deze thesis loopt de thesis van Tom Deweerdt [3]. Deze thesis concentreert zich op de studie en de implementatie van een authenticatiesysteem voor de ziekenzorg. In deze thesis is het de bedoeling om een betrouwbare gegevensoverdracht te realiseren tussen de IVT en de CaReport-server. Het verzenden van de SMS-berichten van de CaReport-centrale naar de IVT maakt eveneens deel uit van deze thesis.

1.3

Doelstelling

Uitgaande van voorgaande probleemstelling kunnen we deze thesis onderverdelen in een aantal afzonderlijk te realiseren bouwblokken, die samen het grotere geheel vormen.

• Implementatie van een transparante foto-overdracht tussen het digitale fototoestel en de IVT. • Implementatie van SMS-functionaliteit die het mogelijk maakt dat de verpleegkundige een SMS in de CaReport-software op de IVT kan inlezen. • Implementatie van een transparante GPRS-verbinding. De verbinding via GPRS vormt het alternatieve pad indien de Bluetooth-communicatielaag tussen de IPT en de IVT niet beschikbaar is. Bij deze verbinding verloopt de communicatie niet over de IPT maar wordt er rechtstreeks met de centrale server gecommuniceerd.

1.4 Overzicht

5

• Ontwikkelen en implementeren van een convergentielaag. De convergentielaag moet over de nodige intelligentie beschikken om een keuze te maken uit de Bluetooth-communicatielaag en de GPRS-verbinding. Hierbij zal de Bluetooth-communicatielaag steeds de voorkeur krijgen, maar indien deze plots onbruikbaar wordt moet een omschakeling naar GPRS gemaakt worden. Van zodra de Bluetooth-communicatielaag opnieuw beschikbaar wordt, schakelen we hierop opnieuw over. Dit alles moet transparant én zonder pakketverlies gebeuren.

1.4

Overzicht

In hoofdstuk 2 onderzoeken we de mogelijkheden om de foto-overdracht te realiseren tussen het digitale fototoestel en de IVT. We bekijken hierbij de voor- en nadelen van de standaard beschikbare oplossingen. In hoofdstuk 3 gaan we dieper in op het aanmaken en het instellen van de GPRS-verbinding. We bekijken hierbij eerst de architectuur van GPRS en vervolgens onderzoeken we hoe de verbinding tot stand kan gebracht worden. De geleverde oplossing moet voor de verpleegkundige zo transparant mogelijk zijn, zodat de manuele tussenkomst tot een minimum herleid wordt. In hoofdstuk 4 onderzoeken we het begrip self-destructing SMS en bekijken we de mogelijkheden om dit te realiseren. We beginnen het hoofdstuk met een korte situering van SMS om vervolgens over te gaan tot de concrete implementatie. In hoofdstuk 5 komt het belangrijkste deel van deze thesis aan bod, namelijk de ontwikkeling van een transparante Bluetooth/GPRS-convergentielaag voor location aware computing in de ziekenzorg. Met behulp van de Bluetooth-communicatielink van Tom Pluym [2] en met behulp van de in hoofdstuk 3 ge¨ımplementeerde GPRS-communicatielink, implementeren we een convergentielaag die in staat is om vlot over te schakelen tussen deze twee paden. We bespreken de mogelijkheden en onderzoeken de tekortkomingen en problemen. In hoofdstuk 6 bekijken we de integratie van de afzonderlijke bouwblokken en onderzoeken we hoe alles kan ge¨ıntegreerd worden in de CaReport-software. In hoofdstuk 7 vormen we tot slot een besluit over het geleverde werk en bespreken we de toekomstperspectieven.

FOTO-OVERDRACHT TUSSEN DIGITALE CAMERA EN IVT

6

Hoofdstuk 2

Foto-overdracht tussen digitale camera en IVT In dit hoofdstuk bekijken we de foto-overdracht tussen de digitale camera en de IVT. We onderzoeken de verschillende implementatiemogelijkheden en bespreken de problemen die we tijdens de implementatie ondervonden.

2.1

Keuze digitale camera

We hebben gekozen voor de Kodak EasyShare V610 [4] [5] (Figuur 2.1). Dit toestel is een 6,1 MegaPixel camera en beschikt over de Bluetooth 2.0 EDR draadloze technologie. Het is dan ook van deze Bluetooth-technologie dat we gebruik maken voor de foto-overdracht tussen de Kodak EasyShare V610 en de IVT. Bluetooth 2.0 EDR laat toe om datatransmissiesnelheden te halen tot 3 Mbps en deze camera maakt voor de overdracht gebruik van het Object Push Protocol. Meer informatie over de keuze van dit toestel en over de Bluetooth Protocol Stack is te vinden in [5].

2.2 Implementatie van de foto-overdracht

7

Figuur 2.1: Kodak EasyShare V610

2.2

Implementatie van de foto-overdracht

Voor de implementatie van de foto-overdracht beschikken we over volgende apparaten:

• HP iPAQ hx2790 (Windows Mobile 5.0) • Kodak EasyShare V610

De HP iPAQ hx2790 beschikt standaard over het Object Push Profile. In het Object Push Profile zijn twee rollen gedefinieerd [6]:

• Push Server: voorziet in een Object Exchange Server. • Push Client: zorgt voor de push en pull van objecten naar en van de Push Server.

De PDA kan dus via Bluetooth zowel gegevens naar andere apparaten versturen als gegevens van andere apparaten ontvangen. Wanneer de digitale camera een foto naar de PDA verstuurt, zal de PDA dit kunnen ontvangen. We onderzoeken eerst de mogelijkheden van deze standaard op de PDA aanwezige Object Push Service. Het heeft immers geen zin om iets te ontwikkelen dat reeds voorhanden is.


2.2.1

8

Implementatie via de standaard Object Push Service

Pairing van de digitale camera en de PDA Vooraleer de digitale camera en de PDA foto’s via Bluetooth kunnen uitwisselen, moeten we een eenmalige Bluetooth-pairing uitvoeren. De eenvoudigste manier om dit te realiseren is vertrekken van de digitale camera. We gaan naar Share → Bluetooth → Mijn apparaten → “Selecteren van een lege apparaatplaats”. In de digitale camera is er plaats om vier apparaten toe te voegen. Na het selecteren van de apparaatplaats start de digitale camera met het zoeken naar Bluetoothapparaten die zich in de buurt bevinden. Het is dus belangrijk dat we de Bluetooth van de PDA aanleggen vooraleer de digitale camera op zoek gaat naar apparaten. Indien de digitale camera onze PDA gevonden heeft, kunnen we deze toevoegen. Het volstaat om eerst op de digitale camera en vervolgens op de PDA dezelfde PIN-code in te geven. Wanneer dit succesvol afgerond is, zijn de apparaten gepaired. Het voordeel van deze werkwijze is dat we nooit nog een PIN-code hoeven in te geven bij het uitwisselen van foto’s tussen beide apparaten. Een alternatieve werkwijze is om de PDA niet toe te voegen aan de lijst met “Mijn apparaten” op de digitale camera. In dit geval zal de digitale camera steeds de PDA moeten zoeken en zullen we telkens de apparaten moeten pairen. Deze methode is sneller indien het om een eenmalige foto-uitwisseling gaat, maar is niet aan te raden wanneer er vaak foto’s moeten uitgewisseld worden, zoals bij ons het geval is.

Foto-overdracht van de digitale camera naar de PDA Nu de Bluetooth-pairing voltooid is, zijn de apparaten gepaired en kan de foto-overdracht beginnen. Wanneer we echter een foto naar de PDA pushen, ontvangen we de melding: “An object has been received that is not supported by Pocket Outlook ” (Figuur 2.2). Deze melding vloeit voort uit het feit dat de Object Push Service eigenlijk door de PDA gebruikt wordt om business cards (vCards) uit te wisselen. De PDA is wel in staat om foto’s te ontvangen, maar kan dit zelf niet automatisch afhandelen. We moeten manueel kiezen of we de foto wensen op de slaan en onder welke naam dit moet gebeuren. Dit is onaanvaardbaar omwille van de transparantievereisten. Het is de bedoeling dat de verpleegkundige zo weinig mogelijk merkt van het hele


9

fototransmissiegebeuren.

Figuur 2.2: Melding bij Object Push

2.2.2

Implementatie en gebruik van een eigen Object Push Service

Wegens de tekortkomingen van de standaard aanwezige Object Push Service ontwikkelen we een eigen Object Push Service voor de PDA. Voor de ontwikkeling van onze service hebben we gekozen voor de Microsoft Visual Studio 2005 ontwikkelomgeving. Omdat onze PDA, de HP iPAQ hx2790, beschikt over de Windows Mobile 5.0 software, zullen we nog de Windows Mobile 5.0 SDK for Pocket PC moeten installeren. Deze SDK kan door geregistreerde windows-gebruikers gratis gedownload worden op de site van Microsoft. De SDK vormt een uitbreiding voor Microsoft Visual Studio 2005 en laat toe om via managed of native code software-applicaties te ontwikkelen voor Windows Mobile 5.0 devices. In navolging van vorige thesissen en met het oog op een eenvoudige integratie, zullen we kiezen om te ontwikkelen in de taal C#. Voor meer informatie over het ontwikkelen van een Windows Mobile 5.0 applicatie verwijzen we naar Bijlage A. Naast de Windows Mobile 5.0 SDK, maken we bij de implementatie van de Object Push Service ook gebruik van de Franson BlueTools SDK v1.2b [7]. Deze SDK werd reeds door Tom Pluym [2] gebruikt bij de implementatie van zijn Bluetooth-communicatielaag. De SDK beschikt over een aantal belangrijke troeven. Zo biedt deze SDK ondersteuning voor de twee belangrijkste Bluetooth Protocol Stacks die op hedendaagse PDA’s gebruikt worden, namelijk de Widcomm


10

Bluetooth Stack en de Microsoft Bluetooth Stack1 en dit zowel voor het .NET Desktop Framework als het .NET Compact Framework. Dit laatste wordt gebruikt voor het ontwikkelen van applicaties op Pocket PC. Verder laat deze SDK toe om in C# te programmeren. Een alternatief voor deze wrapper is om rechtstreeks gebruik te maken van de API’s van Widcomm en Microsoft. Deze API’s zijn echter vrij complex en zijn enkel beschikbaar voor applicaties die geschreven worden in C\C++. Uitgebreide informatie is te vinden in [2]. Voor meer informatie over het gebruik van de Franson BlueTools SDK verwijzen we naar Bijlage B. De Franson BlueTools SDK is echter niet gratis beschikbaar. Per applicatie die aangemaakt wordt, moet een licentiecode aangekocht worden. Bovendien vereisen het .NET Desktop Framework en het .NET Compact Framework een verschillende licentiecode. Elke licentiecode kost US$1492 . Omdat Tom Pluym al gebruik maakt van deze SDK en wij een uitbreiding maken van dezelfde applicatie, vereist dit geen bijkomende licentie-aankoop. Het enige nadeel aan de Franson BlueTools SDK voor onze applicatie is momenteel nog de beperkte ondersteuning van de Object Push Service. Afhankelijk van de gebruikte Bluetooth Stack kunnen er al eens problemen optreden [7]. De PDA die wij gebruiken, de HP iPAQ hx2790, beschikt over de Widcomm 1.7.1 Stack. In combinatie met de digitale camera, de Kodak EasyShare V610, levert dit geen problemen. Een belangrijk feit waar we tijdens de implementatie wel rekening mee moeten houden is dat de Franson BlueTools SDK vereist dat eerst alle OBEX services die reeds op de PDA aanwezig zijn, uitgeschakeld worden. Anders zullen deze de push afkomstig van de digitale camera onderscheppen, en dit is niet de bedoeling. We kunnen deze service als volgt uitschakelen: Start → Settings → Connections → Bluetooth → Services → Information Exchange → Enable service uitvinken (zie Figuur 2.3). 1 2

Daarnaast bestaan ook nog vele andere Bluetooth Stacks zoals Toshiba, BlueSoleil,... Bij aankoop in oktober 2006. Bij aankoop van beide licentiecodes wordt een een korting van 25% op één van

de licentiecodes gegeven

2.3 Besluit

11

Figuur 2.3: Uitschakelen OBEX service

2.3

Besluit

Omdat de standaard Object Push Service die op de PDA aanwezig is niet voldoet aan de transparantievereisten, hebben we een eigen Object Push Service ge¨ımplementeerd. Dit deden we met behulp van de Windows Mobile 5.0 SDK en de Franson BlueTools SDK v1.2b. Onze applicatie is nu in staat om te luisteren naar alle binnenkomende foto’s. Door vooraf alle standaard OBEX services op de PDA uit te schakelen, voorkomen we conflicten.

EEN GSM ALS GPRS MODEM

12

Hoofdstuk 3

Een GSM als GPRS modem We beginnen dit hoofdstuk met een korte beschrijving en situering van GPRS. Vervolgens onderzoeken we een aantal mogelijkheden waarop we de GPRS-verbinding kunnen realiseren. In een volgende fase kijken we hoe we de GPRS-verbinding kunnen instellen op de PDA en tot slot onderzoeken we hoe we deze verbinding kunnen aanspreken vanuit onze applicatie.

3.1

Situering

In dit hoofdstuk gaan we dieper in op het gebruik van een GPRS-verbinding om de foto, genomen met het fototoestel, via de PDA op de server te plaatsen. Dit scenario is weergegeven in Figuur 3.1. Het is de bedoeling dat we gebruik maken van een GPRS-compatibele GSM die ons toelaat om van op de PDA een internetconnectie op te zetten. We beschikken hiertoe over volgende apparaten:

• HP iPAQ hx2790 (Windows Mobile 5.0) • Nokia 6021

3.2 Wat is GPRS?

13

Figuur 3.1: GPRS-verbinding

3.2

Wat is GPRS?

General Packet Radio Service (GPRS) biedt een pakketgeschakelde datatransportdienst aan als uitbreiding op het bestaande circuitgeschakelde GSM-netwerk. Door de toenemende groei aan datacommunicatie ontstond de nood om op een snelle en goedkope manier grote hoeveelheden data over het netwerk te kunnen sturen. Het traditionele GSM-netwerk bleek hiervoor algauw ontoereikend, omdat het slechts beschikt over een datatransmissiesnelheid van 9,6 Kbps (14,4 Kbps in meer geavanceerde netwerken) en omdat we slechts 1 kanaal tegelijk kunnen gebruiken. Een eerste uitbreiding op het traditionele GSM-netwerk is High Speed Circuit Switched Data (HSCSD). Deze technologie laat toe om verschillende kanalen te bundelen en op die manier een hogere datatransmissiesnelheid te bekomen. HSCSD is circuitgeschakeld, wat inhoudt dat indien men een datastroom wenst op te zetten, we eerst een aantal kanalen tussen de twee eindpunten moeten reserveren vooraleer we effectief data kunnen versturen. Dit vereist signalering, het opzetten van de verbinding en het opnieuw afbreken van de verbinding. Eenmaal de kanalen gereserveerd zijn, kunnen deze niet meer door andere gebruikers benut worden. Het grote nadeel aan deze technologie is dus de verspilling van bandbreedte. Een internetverbinding wordt immers gekenmerkt door een grillig, gepiekt verloop en is vaak geen vlakke continue datastroom. De gereserveerde kanalen kunnen dus niet altijd even optimaal benut worden. In tegenstelling tot HSCSD is GPRS pakketgeschakeld en voorafgaand aan het datatransport hoeft men geen verbinding op te zetten. Vaak zegt men dan ook dat GPRS een always-on-

3.2 Wat is GPRS?

14

karakter heeft. Wanneer een gebruiker even geen pakketjes te versturen heeft, kan het netwerk gebruikt worden voor het verzenden van pakketjes van andere gebruikers. Dit zorgt voor een optimale benutting van de beschikbare bandbreedte. De meeste operatoren zullen dan ook afrekenen op het verbruikte datavolume in plaats van op de effectieve verbindingstijd zoals bij GSM en HSCSD het geval is. GPRS behoort tot de 2, 5de generatie mobiele telefoonnetwerken. We kunnen GPRS zien als een overgangspunt tussen de 2de generatie mobiele telefoonnetwerken, waar we GSM kunnen onderbrengen, en de 3de generatie mobiele telefoonnetwerken, waar UTMS een prominente speelt. Omdat GPRS gebruik maakt van het bestaande GSM-netwerk zullen een aantal bijkomende netwerkelementen in de vorm van zowel hardware als software toegevoegd moeten worden. Onder software verstaan we de aanpassingen die nodig zijn om verschillende kanalen te kunnen bundelen, zodat we hogere datasnelheden kunnen bekomen. De extra hardwarecomponenten zijn de GPRS support nodes, die in feite routers zijn. We kunnen hierbij onderscheid maken tussen de gateway GPRS support node (GGSN) en de serving GPRS support node (SGSN). De gateway GPRS support node bevindt zich tussen het GPRS netwerk en externe pakketdatanetwerken (PDN) en zorgt voor routeringsinformatie voor de GPRS-gebruikers. De serving GPRS support node houdt de locatie bij van de individuele gebruikers, verzamelt gegevens in verband met kostenberekeningen (bijvoorbeeld door het tellen van de bytes), voorziet in security en zorgt voor toegangscontrole. Aangezien de infrastructuur, die het 3de generatie mobiele telefoonnetwerk UTMS vereist, precies deze is van het GPRS-netwerk, betekent GPRS een enorme stap vooruit naar UTMS. Meer informatie betreffende het GSM- en het GPRS-netwerk kan men terugvinden in Bijlage C. GPRS zal meestal enkel pakketjes versturen op niet-benutte tijdsloten naast het gewone circuitgeschakelde telefoonverkeer. Op die manier zal een gebruiker geen hinder ondervinden wanneer hij een gewoon telefoongesprek voert. Er is een asymmetrische allocatie van tijdsloten mogelijk, wat wil zeggen dat een verschillend aantal tijdsloten kan gebruikt worden voor uplink- en downlinkverkeer. Afhankelijk van het gebruikte coderingsschema en het aantal tijdsloten kunnen transmissiesnelheden tot 171,2 Kbps gehaald worden. Een volledig overzicht van de transmissiesnelheden is te vinden in Tabel 3.1 [8]. CS-1 en CS-2 bieden een goede foutdetectie en -correctie met een lage throughput terwijl CS-3 en CS-4 een hogere throughput leveren maar met weinig tot geen foutcorrectiemogelijkheden. In de huidige GPRS-netwerken wordt CS-1/CS-2 gebruikt

3.2 Wat is GPRS?

15

terwijl de meeste GSM-toestellen de vier coderingsschema’s ondersteunen. De transmissiesnelheid van 171,2 Kbps is een theoretische maximumsnelheid die in vele gevallen niet gehaald zal worden. Een eerste reden hiervoor is dat de huidige providers slechts CS1/CS-2 aanbieden en bovendien worden enkel de niet-benutte tijdsloten gebruikt. Een tweede belangrijke reden is dat de transmissiesnelheid beperkt wordt door het mobiele toestel zelf. Niet alle apparaten zijn immers in staat om tegelijk te zenden en te ontvangen. Tabel 3.2 geeft een overzicht van de GPRS-multislotklassen [9]. Deze zijn apparaatspecifiek en geven de mate weer waarin het mobiele toestel in staat is om tijdsloten te gebruiken voor zenden en ontvangen. Het maximum totaal aantal sloten geeft weer hoeveel sloten simultaan kunnen gebruikt worden voor uplink- en downlinkcommunicatie. Tabel 3.3 geeft tot slot een overzicht van de drie klassen waarin we mobiele apparaten kunnen indelen op basis van hun capaciteiten. Een typisch mobiel apparaat beschikt momenteel over GPRS-multislotklasse 10 en is van klasse B [9]. Wat betreft het netwerk zelf, geeft de Belgische provider Proximus melding van een maximale uploadsnelheid van 27 Kbps en een maximale downloadsnelheid van 54 Kbps. GPRS-gebruikers kunnen ook een QOS-profiel opgeven. Dit profiel geeft de prioriteit van een dienst weer, de betrouwbaarheidsklasse, de vertragingsklasse en tot slot de doorvoercapaciteit. Een belangrijk gegeven van GPRS is de vertraging (delay). De vertraging ligt ongeacht de klasse veel hoger dan in vaste netwerken. In de uplink blijft de vertraging meestal beperkt tot 1 seconde, maar in de downlink kan de vertraging al vlug oplopen tot 3 seconden. Ter vergelijking: in vaste netwerken is de round trip time (RTT) in de orde van 10 tot 100 ms. Bij onze implementatie zullen we met dit gegeven extra rekening moeten houden. Het spreekt voor zich dat deze aanzienlijke vertragingen in real-time toepassingen voor problemen kunnen zorgen. Coderings-

Aantal tijdsloten (waarden in Kbps)

schema

1

2

3

4

5

6

7

8

CS-1

9,05

18,1

27,15

36,2

45,25

54,3

63,35

72,4

CS-2

13,4

26,8

40,2

53,6

67

80,4

93,8

107,2

CS-3

15,6

31,2

46,8

62,4

78

93,6

109,2

124,8

CS-4

21,4

42,8

64,2

85,6

107

128,4

149,8

171,2

Tabel 3.1: GPRS-transmissiesnelheden (in Kbps) in functie van het aantal tijdsloten en het gebruikte coderingsschema.

3.2 Wat is GPRS?

Klasse

16

Maximum aantal

Maximum aantal

Maximum totaal

ontvangstsloten

zendsloten

aantal sloten

1

1

1

2

2

2

1

3

3

2

2

3

4

3

1

4

5

2

2

4

6

3

2

4

7

3

3

4

8

4

1

5

9

3

2

5

10

4

2

5

11

4

3

5

12

4

4

5

Tabel 3.2: multislotklassen

Klasse

Capaciteiten

Klasse A

Deze terminals kunnen simultaan met GPRS- en GSM-diensten connecteren. Men kan dus simultaan met het circuitgeschakelde deel en met het pakketgeschakelde deel van het netwerk connecteren. Telefoneren terwijl men data aan het versturen is, vormt geen enkel probleem.

Klasse B

Deze terminals kunnen met zowel GPRS- als GSM-diensten connecteren, maar slechts 1 dienst kan tegelijk actief zijn. Wanneer er een telefoongesprek of SMS binnenkomt, wordt de GPRS-dienst onderbroken. Na het beëindigen van het gesprek of het binnenkomen van de SMS wordt de GPRS-dienst opnieuw hervat.

Klasse C

Deze terminals kunnen connecteren met GPRS-diensten of met GSM-diensten. Men moet manueel tussen deze diensten omschakelen. Een voorbeeld hiervan zijn de GPRS PCMCIA kaarten in laptops. Tabel 3.3: GPRS klassen

3.3 Communicatie tussen PDA en GSM: Infrarood of Bluetooth?

3.3

17

Communicatie tussen PDA en GSM: Infrarood of Bluetooth?

Vooraleer de PDA het GSM-toestel kan gebruiken als GPRS-modem, moeten we eerst een connectie opzetten tussen deze twee apparaten. Hiervoor hebben we de keuze uit drie mogelijkheden, waarvan 1 bekabelde en 2 draadloze: usb, infrarood en Bluetooth. Omdat de omgeving voor de verpleegkundige zo transparant mogelijk moet zijn, zonder veel extra kabels, zullen we een keuze moeten maken uit de twee draadloze technologieën: infrarood en Bluetooth.

3.3.1

IrDA

De Infrared Data Association (IrDA) [10] werd in 1994 opgericht als organisatie met als doel het ontwikkelen van een standaard voor het versturen van data via infrarood licht. IrDA-devices maken gebruik van infrarood LED’s die het infrarood licht uitzenden in een smalle bundel van 15 tot 30 graden. De ontvanger maakt op zijn beurt gebruik van een fotodiode die het infrarood licht opnieuw omzet in een elektrische stroom. Omdat het infrarood licht slechts in een beperkte gerichte bundel wordt uitgestuurd, vereist deze technologie dat de zender en ontvanger elkaar kunnen “zien” met andere woorden dat ze over een zichtlijn beschikken. Het bereik van infrarood hangt af van het vermogen van de apparaten. Het gangbare bereik is 1 meter, maar wanneer we apparaten gebruiken met een lager vermogen, valt het bereik terug tot 0,3 of zelfs 0,2 meter. De transmissiesnelheid kunnen we onderverdelen in drie categorieën: Serial Infrared (SIR), Medium Infrared (MIR) en Fast Infrared (FIR). SIR vindt zijn oorsprong in de koppeling aan een normale RS-232 poort en haalt bijgevolg een transmissiesnelheid van 115,2 Kbps. MIR is eigenlijk geen officiële term, maar wordt vaak gebruikt om transmissiesnelheden van 0,576 Mbps tot 1,152 Mbps aan te duiden. FIR wijst op transmissiesnelheden van 4 Mbps. In de toekomst zullen ook Very Fast Infrared (VFIR) en Ultra Fast Infrared (UFIR) gebruikt worden die beschikken over een transmissiesnelheid van respectievelijk 16 Mbps en 100 Mbps, waarvan deze laatste nog in ontwikkeling is. Hoewel de meeste laptops beschikken over FIR dat transmissiesnelheden kan halen tot 4 Mbps, is de IrDA datasnelheid bij de meeste Pocket PC’s gelimiteerd tot 115 Kbps, vanwege hun kop-

3.3 Communicatie tussen PDA en GSM: Infrarood of Bluetooth?

18

peling aan een seriële poort. Wat betreft de HP iPAQ hx2790 kan er wat verwarring optreden. Sommige bronnen maken melding van SIR terwijl andere FIR vermelden. Een eenvoudige bestandsoverdracht brengt aan het licht dat het toch om SIR gaat. Verder vinden we ook nog in de datasheet van de iPAQ dat het infraroodbereik 0,3 meter bedraagt. De lage datarate in combinatie met het feit dat de twee devices vrij goed naar mekaar gericht moeten worden (binnen een afstand van 30 centimeter), maakt deze technologie minder geschikt voor onze toepassing. Het is onaanvaardbaar dat de verpleegkundige er steeds zou moeten voor zorgen dat er een zichtlijn aanwezig is.

3.3.2

Bluetooth

De geschiedenis van Bluetooth gaat eveneens terug tot 1994, toen de Zweedse ICT-gigant Ericsson met onderzoek begon naar wat voorlopig werd aangeduid als een “multi-communicator link”. Een 4-tal jaar later, in het voorjaar van 1998, werd het Bluetooth Consortium opgericht door vijf bedrijven: Ericsson, Intel, IBM, Nokia en Toshiba. Ze hadden één doel: een op één chip ge¨ıntegreerde, laaggeprijsde, radiogebaseerde draadloze netwerktechnologie ontwikkelen. In september 1998 ging men over tot het oprichten van een Bluetooth Special Interest Group (SIG) dat tot doel had om eind 1999 te kunnen komen met concrete, op Bluetooth gebaseerde producten zoals gsm’s, laptops, headsets,... Al gauw sloten vrijwel alle grote elektronicabedrijven, software-ontwikkelaars en telecombedrijven zich hierbij aan [8] [11]. Bluetooth wordt vaak omschreven als een draadloze kabelvervanger, die verschillende apparaten die zich in elkaars buurt bevinden kan verbinden zonder dat hierbij dure bekabeling nodig is. Bluetoothdevices zijn verkrijgbaar in 3 vermogensklassen:

• Vermogensklasse 1: Maximum uitgangsvermogen van 20 dBm (100mW) en met een bereik van 100 tot 150 meter. • Vermogensklasse 2 : Maximum uitgangsvermogen van 4 dBm (2.5mW) en met een bereik van 10 meter. • Vermogensklasse 3 : Maximum uitgangsvermogen van 0 dBm (1mW) en met een bereik van 10 cm.

3.4 Het instellen van de GPRS-verbinding op de PDA

19

Aangezien Bluetooth gebruik maakt van radiogolven (2,4 GHz-bereik) hoeft men niet te beschikken over een zichtlijn. Hoewel sommige PDA’s reeds Bluetooth 2.0 + EDR ondersteunen, dat snelheden kan halen tot 3 Mbps, beschikt de HP iPAQ hx2790 nog over Bluetooth v1.2 dat het voorlopig moet stellen met een snelheid tot maximaal 723,1 Kbps. Aangezien de iPAQ over vermogensklasse 2 beschikt, halen we een bereik van 10 meter. Gezien het feit dat we voor Bluetooth geen zichtlijn nodig hebben en dat een bereik van 10 meter haalbaar is, is Bluetooth de meest optimale keuze om de communicatie tussen de PDA en het GSM-toestel op te zetten.

3.4

Het instellen van de GPRS-verbinding op de PDA

Omdat we gebruik maken van een Bluetooth-communicatielink tussen de PDA en de GSM, kunnen we voor het instellen van de GPRS-verbinding gebruik maken van een wizard die aanwezig is in de Bluetooth Manager op de PDA. Deze instelling is slechts eenmalig en vormt bijgevolg geen beperking op de transparantievereisten. We bespreken eerst de algemene werkwijze om de GPRS-verbinding in te stellen op de PDA en vervolgens gaan we iets dieper in op enkele specifieke instellingen.

3.4.1

Algemene werkwijze

De instelling kan als volgt gebeuren:

1. Opstarten van de Bluetooth-wizard. Start → Settings → Connections → Bluetooth → Bluetooth Manager → New → Connect to Internet via phone (Figuren 3.2 en 3.3)


Figuur 3.2: Bluetooth settings

20

Figuur 3.3: Connect to Internet via phone

2. Pairing van de PDA en de GSM. In een eerste fase activeren we Bluetooth op het GSM-toestel. Op die manier is het GSMtoestel discoverable en is de PDA in staat om het GSM-toestel te detecteren. (Figuur 3.4). Van zodra de PDA het GSM-toestel gevonden heeft, kunnen we overgaan tot pairing. Hiertoe geven we een PIN-code in in de wizard (Figuur 3.5). Vervolgens zal het GSMtoestel deze PIN-code vragen, waar we ze opnieuw ingeven. Hierna zijn de apparaten succesvol gepaired.


Figuur 3.4: Prepairing Bluetooth

21

Figuur 3.5: Bluetooth Pairing

3. Instellen van de inbelgegevens. We creëren een nieuwe inbelverbinding (new connection), zie Figuur 3.6. De wizard laat enkel toe om de naam van de connectie en het inbelnummer in te stellen. In het geval van Proximus is dit inbelnummer: ∗99∗∗∗1# (Figuur 3.7). In §3.4.2 gaan we dieper in op de structuur van dit inbelnummer.

Figuur 3.6: Inbelverbinding

Figuur 3.7: Inbelgegevens


22

4. Extra instellingen: extra dial-string en baudrate. Voor het instellen van de GPRS-verbinding zijn nog een aantal bijkomende inbelinstellingen nodig. We gaan naar Start → Settings → Connections → Bluetooth internet settings → Manage existing connection. Hier kunnen we de net ingestelde inbelverbinding selecteren (Figuur 3.8) en de inbelinstellingen verder verfijnen. We stellen de baudrate in op 115200 en in het tabbladje advanced geven we een extra dial-string mee. In het geval van Proximus is deze dial-string: +cgdcont=1,“ip”,“internet.proximus.be” (Figuur 3.9). In §3.4.2 gaan we dieper in op de structuur van deze dial-string en geven we meer uitleg over de gekozen baudrate.

Figuur 3.8: Aanpassen van de reeds ingestelde inbelverbinding

Figuur 3.9: Extra dial-string en instellen van de baudrate

Alle instellingen voor de GPRS-verbinding zijn hiermee voltooid. Indien we nu bijvoorbeeld Pocket Internet Explorer (PIE) opstarten, zien we het venster “Logon to Server” verschijnen (Figuur 3.10). Het Proximus-netwerk vereist dat al deze velden blanco blijven, dus eigenlijk is dit venster overbodig. We kunnen het enkel beschouwen als een extra vraag naar de gebruiker toe of hij zeker is dat hij met het Proximus GPRS-netwerk wenst te connecteren. Dit is echter niet zo transparant voor de verpleegkundige. Telkens de applicatie opstart, zal de vraag verschijnen of men een Proximus GPRS-verbinding wenst op te zetten. We kunnen dit probleem eenvoudig verhelpen door in het register het veld RequirePw op 0 te plaatsen in plaats van op 1 (zie Figuur 3.11). We kunnen dit als volgt wijzigen:


23

1. Installeren van een Pocket PC Register Editor. 2. Ga naar HKEY LOCAL MACHINE → Comm → ConnMgr → Providers → {7C4B7A38 − 5F F 7 − 4BC1 − 80F 6 − 5DA7870BB1AA} → Connections → proximus → RequirePw. (Hierbij is “proximus” de naam die we ingesteld hebben voor de inbelverbinding). 3. Wijzig RequirePw van 1 naar 0.

Figuur 3.10: Logon to Server

3.4.2

Figuur 3.11: RequirePw

Specifieke instellingen

Instelling inbelnummer en dial-string Het eerste wat opvalt bij het instellen bij de inbelverbinding is het vrij ongewone inbelnummer, namelijk ∗99∗∗∗1#. Om dit nummer te verklaren moeten we eerst de extra dial string +cgdcont=1,“ip”,“internet.proximus.be” (Figuur 3.9) van naderbij bekijken. In Bijlage E wordt de volledige structuur van het GPRS-modemcommando “+cgdcont” weergegeven. Proximus vereist dat we enkel de eerste drie velden doorsturen, namelijk +cgdcont= , en <APN>.


24

• = 1. Deze numerieke parameter specificeert de Packet Data Protocol (PDP) context. Dit getal geeft weer welke dataverbinding op de GSM moet aangesproken worden. Naast GPRS zijn er bijvoorbeeld ook nog MMS- en WAP-dataverbindingen. Dit cidnummer wordt door de provider bepaald. • = “ip”. Deze parameter specifieert het PDP-type. Momenteel wordt enkel “ip” ondersteund. • <APN> = “internet.proximus.be”. Deze parameter is de logische naam die gebruikt wordt om de GGSN van het externe PDN te selecteren. In dit geval dus “internet.proximus.be”.

Met deze gegevens kunnen we de structuur van het inbelnummer verklaren. Dit nummer wordt als volgt opgebouwd: ∗99∗∗∗#. Dit cid voor een GPRS-verbinding bij Proximus is 1, zodat we dit als ∗99∗∗∗1# moeten doorgeven zodat we inbellen op de juiste dataverbinding.

Instelling baudrate

Figuur 3.12: Lijnsnelheden

Bij het instellen van de baudrate op de PDA moeten we een onderscheid maken tussen de Data Terminal Equipment/Data Communication Equipment (DTE/DCE) snelheid en de snelheid op de telefoonlijn zelf. Dit is grafisch weergegeven in Figuur 3.12. De DTE, hier de PDA, vormt het eindpunt van een communicatieverbinding terwijl de DCE, hier de GSM-modem, zorgt voor de communicatieverbinding. Het is zo dat de telefoonlijnsnelheid niet noodzakelijk moet gelijk zijn aan de snelheid op de DTE/DCE lijn. Het is vooral belangrijk dat de DTE/DCE lijnsnelheid groter of gelijk is aan de te verwachten telefoonlijnsnelheid. De baudrate langs de DTE zijde kunnen we instellen op de PDA (zie Figuur 3.9). De DCE (GSM-modem) maakt voor het instellen van de baudrate gebruik van autodetectering op de communicatie-interface. Dit wil zeggen dat de modem de snelheid detecteert waarmee de DTE hem data toezendt en aan dezelfde snelheid data zal terugzenden.

3.5 Aanspreken van de GPRS-verbinding vanuit de applicatie

25

We moeten een correcte keuze maken wat betreft de baudrate tussen de DTE en de DCE. Voor Bluetooth verbindingen tussen de GSM en de PDA wordt de maximale baudrate van 115200 baud aangeraden. De meeste GPRS-modems kunnen deze baudrate aan. Het blijkt echter moeilijk om hierover duidelijke informatie te vinden. Op het AT-commando (AT+IPR?) dat hierover meer informatie kan geven, kan de Nokia 6021 GPRS-modem niet antwoorden. We krijgen enkel een “ERROR”-bericht terug. We proberen dus de maximale baudrate van 115200 in te stellen en we kijken of de communicatie lukt. Wanneer we een GPRS-verbinding opzetten, werkt alles naar behoren. We kunnen dus aannemen dat de Nokia 6021 met een baudrate van 115200 overweg kan.

3.5

Aanspreken van de GPRS-verbinding vanuit de applicatie

Nu alle instellingen van onze GPRS-verbinding in de PDA zijn opgeslagen, kunnen we overgaan tot het aanspreken van deze verbinding vanuit onze applicatie. Om dit te realiseren zullen we vanuit onze applicatie de Connection Manager van de PDA aanspreken.

3.5.1

Connection Manager

Met de komst van Pocket PC 2002 werd de Connection Manager ge¨ıntroduceerd. De Connection Manager centraliseert en automatiseert de totstandkoming van verschillende soorten netwerkverbindingen waarvan de applicaties gebruik kunnen maken indien ze wensen te connecteren met het internet of met het locale netwerk. Wanneer een bepaalde applicatie een connectie nodig heeft, voorziet de Connection Manager in een vlugge en transparante manier om de meest ideale netwerkconnectie te kiezen, op te zetten en te beheren. Zo houdt de Connection Manager bij welke connecties er in gebruik zijn, brengt hij alle applicaties op de hoogte van de actieve connecties, sluit onnodige connecties of connecties die reeds lange tijd niet gebruikt zijn en sluit lage-prioriteit verbindingen af ten voordele van hoge-prioriteitverbindingen. Typisch zullen spraakconnecties een hogere prioriteit hebben dan dataconnecties. Het spreekt voor zich dat de Connection Manager slechts gebruik kan maken van connecties die eerder op de PDA zijn ingesteld. In §3.4.1 hebben wij de Bluetooth GPRS-verbinding ingesteld en vanaf dan kan de Connection Manager hiervan gebruik maken. De Connection Manager kan onderstaande verbindingen beheren:

3.5 Aanspreken van de GPRS-verbinding vanuit de applicatie

26

• Remote Access Service (RAS) connections • Virtual Private Network (VPN) connections • General Packet Radio Services (GPRS) connections • Proxy Server connections • Wi-Fi (802.11) connections • Wired Ethernet (802.3) connections • Desktop Passthrough (DTPT) connections

3.5.2

Connection Manager API

We kunnen de Connection Manager in onze applicatie aanspreken door gebruik te maken van de Connection Manager API. Deze API is echter enkel beschikbaar in native code. Omdat we onze applicatie in .NET managed code wensen te schrijven, zullen we gebruik maken van het P/Invoke mechanisme voor het aanspreken van functies uit de native unmanaged dll.

Instellen van de eigenschappen van de connectie In een eerste fase zullen we een ConnectionInfo-structuurelement moeten aanmaken, waarin we enkele eigenschappen van onze connectie-aanvraag kunnen instellen. We kunnen bijvoorbeeld de prioriteit, de maximale kost en bandbreedte van de connectie instellen. Tevens kunnen we de Globally Unique Identifier (GUID) van het netwerk waarmee we wensen te connecteren instellen. Als GUID maken we gebruik van de GUID van internet. De PDA zal dan zelf beslissen of hij de verbinding met het internet maakt via de cradle, of via de Bluetooth GPRS-verbinding. Een gedetailleerde beschrijving van de verschillende elementen is te vinden in Bijlage F.

Opzetten en afbreken van de connectie Eens de eigenschappen van onze connectie ingesteld zijn, kunnen we een verbinding proberen maken in overeenstemming met onze instellingen. We maken hiervoor gebruik van de Connection Manager API-functie ConnMgrEstablishConnectionSync die zal proberen de verbinding op te

3.6 Besluit

27

zetten. Eenmaal dit gelukt is kunnen we gegevens over GPRS versturen. Op het einde van de sessie, wanneer we geen GPRS-data meer wensen te versturen, kunnen we de verbinding verbreken via de functie ConnMgrReleaseConnection.

3.6

Besluit

Met behulp van de Connection Manager en de Connection Manager API zijn we in staat om vanuit een applicatie de op de PDA aanwezige connecties aan te spreken. Het volstaat om een connectie-aanvraag op te bouwen voorzien van de juiste parameters. Een ander punt dat wel vatbaar voor discussie is, is het gebruik van een GSM als GPRS-modem. Omdat we tussen de GSM en de PDA een verbinding moeten opbouwen zijn we verplicht om een aantal instellingen manueel in te stellen. Omdat we gebruik maken van Bluetooth als communicatieprotocol, kunnen we bijvoorbeeld niet onder de pairing van de apparaten uit. Ook de GSM-modeminstellingen en commando’s moeten via de PDA gebeuren. Opnieuw kunnen we niet zonder deze manuele instellingen. We kunnen ons hierbij afvragen of het niet interessant zou zijn om een PDA te gebruiken die reeds over een GPRS-modem beschikt, zonder de tussenkomst van een GSM. In dit geval zou de configuratie met behulp van een configuratiefile kunnen gebeuren, die eenvoudig op de PDA kan geplaatst worden. Dit zou de manuele tussenkomst van iemand die alle PDA’s eenmalig moet configureren drastisch verminderen.

SMS

28

Hoofdstuk 4

SMS In dit hoofdstuk gaan we dieper in op het gebruik van een self-destructing SMS binnen het CaReport-softwarepakket. We beginnen dit hoofdstuk met een korte situering van de selfdestructing SMS in het algemene scenario. Daarna bespreken we kort wat SMS precies inhoudt. Vooraleer we kunnen overgaan tot de implementatie moeten we nog een aantal technologiekeuzes maken. Tot slot gaan we dieper in op de verschillende implementatiemogelijkheden en bespreken we de concrete implementatie.

4.1

Situering

Figuur 4.1 geeft weer waar de self-destructing SMS zich bevindt binnen het algemene scenario. Om de privacy van de patiënten te garanderen, verloopt de datatransmissie tussen de IPT en de IVT geëncrypteerd. In normale omstandigheden beschikt de verpleegkundige over alle sleutels die per patiënt nodig zijn. Deze sleutels worden immers via een synchronisatieprocedure van de IVT met de centrale server op de IVT geplaatst nog voor de patiëntenronde begint. In noodsituaties kan het gebeuren dat een verpleegkundige langskomt die niet over de gepaste sleutels beschikt. Bijgevolg heeft men ook geen toegang tot de IPT van die patiënt en tot het patiëntendossier. In dit geval moet de verpleegkundige via een SMS de nodige sleutels van de CaReport-centrale kunnen ontvangen. Omdat het niet de bedoeling is dat deze sleutels op de GSM van de verpleegkundige achterblijven, moet dit SMS-bericht verwijderd worden van zodra het door de CaReport-applicatie is ingelezen.

4.2 Wat is SMS?

29

Figuur 4.1: Self-destructing SMS binnen het algemene scenario

De SMS wordt van de centrale naar de verpleegkundige verstuurd. Dit kan gebeuren via een speciale webinterface of rechtstreeks via een GSM-toestel. De precieze wijze waarop de SMS verstuurd wordt, speelt in deze thesis geen rol. Het is enkel de bedoeling dat we de SMS correct uit de GSM in de CaReport-applicatie kunnen inlezen.

4.2

Wat is SMS?

Short Message Service (SMS) wordt gebruikt voor eenvoudig berichtenverkeer. SMS-berichten kunnen maximaal 140 bytes groot zijn. Omdat SMS-tekstberichten gebruik maken van een 7-bit encodering passen hierin 160 karakters. Voor de datatransmissie maakt men gebruik van de onbenutte capaciteit op de signaleringskanalen en niet van de standaard datakanalen van de GSM. Het verzenden en ontvangen van SMS-berichten kan zowel tijdens data- of spraaktransmissie plaatsvinden. De hedendaagse GSM-toestellen zijn in staat om berichten te verzenden die langer zijn dan 140 bytes. Dit zijn zogenaamde multi-part berichten. In dit geval wordt een User Data Header (UDH) aan het SMS-bericht toegevoegd. Wanneer men hiervan gebruik maakt blijft er minder plaats over voor gebruikersdata, namelijk “140 min de lengte van de UDH-header” bytes. De UDH voor multi-part berichten omvat 6 bytes. Er blijven dus slechts 134 bytes over voor gebruikersdata. Dit komt overeen met 153 7-bit karakters. Wanneer we nu bijvoorbeeld een bericht

4.3 Bluetooth als communicatieprotocol tussen PDA en GSM

30

verzenden dat bestaat uit 3 SMS-berichten kunnen we slechts 459 7-bit karakters versturen in plaats van 480. In deze thesis maken we geen gebruik van multi-part berichten. Indien later echter de uitbreiding gemaakt zou worden naar multi-part berichten zal men met deze extra header rekening moeten houden. Tot slot merken we op dat een UDH-header niet enkel gebruikt wordt bij multi-part berichten, maar ook bij andere geavanceerde SMS-berichten zoals beltonen en afbeeldingen.

4.3

Bluetooth als communicatieprotocol tussen PDA en GSM

Voor de implementatie van de self-destructing SMS beschikken we over volgende apparaten: • HP iPAQ hx2790 (Windows Mobile 5.0) • Nokia 6021 Net als bij GPRS moeten we tussen de PDA en de GSM een communicatielink opzetten alvorens we SMS-berichten kunnen uitwisselen. Opnieuw hebben we de keuze tussen 1 bekabelde (USB) en 2 draadloze technologieën (IrDA, zie §3.3.1 en Bluetooth, zie §3.3.2). Omwille van dezelfde redenen als bij GPRS kiezen we opnieuw voor Bluetooth. Deze technologie vereist geen zichtlijn en het bereik is ruim voldoende voor onze toepassing. Voor de Bluetooth-communicatie maken we opnieuw gebruik van de Franson BlueTools SDK v1.2b. Naast de gewone BlueTools SDK is er ook een speciale SMS SDK aanwezig. Deze SDK laat toe om SMS-berichten te verzenden en te ontvangen. We zullen in de eerste plaats dan ook de mogelijkheden van deze SDK onderzoeken.

4.4 4.4.1

Implementatie via de Franson BlueTools SMS SDK Bluetooth-pairing

Alvorens we de Franson BlueTools SMS SDK gebruiken, moeten we eerst overgaan tot een Bluetooth-pairing van de PDA en de GSM. Dit is een eenmalige pairing die geen afbreuk doet

4.4 Implementatie via de Franson BlueTools SMS SDK

31

aan de transparantievereisten. Door de Bluetooth-pairing vormen de apparaten een zogenaamd trusted pair en we verhinderen op die manier dat telkens wanneer we onze applicatie starten, we een PIN-code moeten ingeven. De Bluetooth-pairing gebeurt als volgt: op de PDA activeren we Bluetooth, zodat dit apparaat discoverable wordt. Vervolgens activeren we Bluetooth op de GSM en laten we de GSM op zoek gaan naar discoverable-apparaten in de nabije omgeving. Indien het GSM-toestel de PDA gevonden heeft, kunnen we dit selecteren en vraagt het GSM-toestel ons om een PIN-code in te geven. Nadat we een PIN-code hebben ingegeven, vraagt de PDA ons om dezelfde PIN-code in te geven. Als dit succesvol afgerond is, vormen de apparaten een trusted pair.

4.4.2

Connecteren van de GSM met de PDA over Bluetooth vanuit de SMSapplicatie

Telkens de SMS-applicatie opstart, is het de bedoeling dat de PDA op zoek gaat naar het juiste GSM-toestel. Het is dus niet de bedoeling dat om het even welk willekeurig Bluetooth-apparaat of een foutief GSM-toestel geselecteerd wordt. Een manuele tussenkomst van de verpleegkundige voor het selecteren van het juiste GSM-toestel is niet gewenst. Alle beslissingen moeten intern in de applicatie genomen worden. De Franson BlueTools SDK beschikt over een functie die toelaat om alle Bluetooth-apparaten in nabije omgeving op te sporen. Na deze device discovery beschikken we over een lijst van alle aanwezige Bluetooth-apparaten. Van de gevonden apparaten kunnen we het apparaatadres, de friendly name, de apparaatklasse en de op het apparaat aanwezige services opvragen. Onder services verstaan we bijvoorbeeld een Seriële Poort Service, de Object Push Service,... De friendly name is een naam die we zelf kunnen instellen in het Bluetooth-apparaat. De apparaatklasse geeft tot slot weer of het gaat om een laptop, een GSM, een desktopcomputer,... Voor meer informatie verwijzen we naar [2]. Een eerste mogelijkheid voor het selecteren van het juiste GSM-toestel is op basis van de apparaatklasse. Op die manier kunnen we bijvoorbeeld alle niet-GSM-toestellen uitsluiten. Het gebruik van dit veld is helaas nog steeds niet ge¨ımplementeerd in de laatste versie van Franson BlueTools [2]. Een tweede mogelijkheid om het juiste GSM-toestel te selecteren is op basis van de friendly

4.4 Implementatie via de Franson BlueTools SMS SDK

32

name. In dit geval kunnen we een uniforme naamgeving voor alle GSM-toestellen van de verpleegkundigen vooropstellen. Een voorbeeld is “PHONE nummer verpleegkundige”. Echt veilig is dit natuurlijk niet, want iedereen kan zijn GSM-toestel die naam geven. De derde en tevens laatste mogelijkheid is een lijst bijhouden waarin alle apparaatadressen van de GSM-toestellen van alle verpleegkundigen opgenomen zijn. In dit geval hoeven we geen device discovery uit te voeren en kunnen we in principe direct connecteren met het gewenste GSM-toestel. Tom Pluym [2] heeft echter aangetoond dat per apparaat dat zich niet in de buurt bevindt, we 5 seconden tijd verliezen. Een volledige lijst met apparaatadressen overlopen, waarbij het gewenste toestel misschien helemaal achteraan staat, is dus geen goed idee. Wat we wel kunnen doen is op de PDA een bestandje bijhouden met enkel het apparaatadres van het GSM-toestel van de verpleegkundige. Zowel de PDA als het GSM-toestel behoren immers tot de persoonlijke toestellen van de verpleegkundige. Beide gevallen zijn ge¨ımplementeerd in de applicatie. Op de Nokia 6021 kunnen we de Bluetooth-informatie met o.a. het Bluetoothapparaatadres opvragen via *#2820#.

4.4.3

Selecteren van de gewenste service

Eenmaal we geconnecteerd zijn met het juiste GSM-toestel moeten we nog connecteren met de gewenste service. Indien we SMS-berichten wensen uit te lezen volstaat een Seriële Poort Service. Indien geen Seriële Poort Service aanwezig is, kunnen we eventueel gebruik maken van de Dial-up Service. De Franson BlueTools SDK laat toe om de aanwezige services op te sporen en met de gewenste service te connecteren.

4.4.4

Uitlezen SMS-berichten

We zijn geconnecteerd met het juiste GSM-toestel en we hebben de juiste service geselecteerd. We zijn dus helemaal klaar om de SMS-berichten uit te lezen via de Franson BlueTools SMS SDK. Helaas loopt het hier mis. Met de Nokia 6021 vindt deze SDK enkel de SMS-berichten uit het SIM-geheugen terug. Alle andere berichten die niet zijn opgeslagen op de SIM-kaart worden niet teruggevonden. Om de oorzaak van dit probleem te vinden, bekijken we eerst over welke soorten geheugen een GSM-toestel beschikt. We kunnen ze onderverdelen in drie “soorten”:

4.5 Implementatie via AT commando’s

33

• SM (SIM card) - het SIM-geheugen • ME (Mobile Equipment) - het telefoongeheugen • MT - het totale geheugen = SIM-geheugen + telefoongeheugen

De implementatie die Franson gebruikt, probeert de SMS-berichten uit te lezen door het MTgeheugen aan te spreken. Normaalgezien worden hiermee de SMS-berichten uit zowel het SIMgeheugen als het telefoongeheugen uitgelezen. Bij de Nokia 6021 worden echter enkel de berichten uit het SIM-geheugen uitgelezen. Indien we hetzelfde proberen met de Nokia 6310i stellen we hetzelfde probleem vast. Omdat we SMS-berichten uit het volledige geheugen willen uitlezen, zullen we overgaan tot een eigen implementatie die eerst het SIM-geheugen en vervolgens het telefoongeheugen aanspreekt.

4.5

Implementatie via AT commando’s

Het selecteren van het juiste GSM-toestel en het selecteren van de juiste service verloopt identiek als in §4.4.2 en §4.4.3. Voor het opvragen van de SMS-berichten uit het GSM-toestel zullen we gebruik maken van AT-commando’s. We bespreken kort wat AT-commando’s zijn en overlopen vervolgens welke commando’s we precies nodig hebben.

4.5.1

Wat zijn AT commando’s?

Hayes AT commando set De oudste modems waren enkel in staat om datagegevens te zenden en te ontvangen. Voor het opzetten van de verbinding was dan een extern apparaat nodig. Toen het gebruik van modems echter toenam, ontstond de nood om de modem zelf het telefoonnummer te laten kiezen. Hoewel de RS-232 standaard een secundair communicatiekanaal voorziet voor controlecommando’s, werd dit niet ge¨ımplementeerd in de low-cost RS-232 implementaties die aanwezig waren op de home computers van de jaren zeventig. Het was Dennis Hayes die in 1977 een smart modem


34

ontwikkelde die het enkele RS-232 communicatiekanaal gebruikte om zowel controlecommando’s als data te versturen [12]. AT-commando’s beginnen steeds met AT gevolgd door het effectieve commando. AT staat voor ATtention en dient eigenlijk om de modem wakker te schudden: “Aandacht, er volgen commando’s”. Op de meeste AT commando’s volgt een antwoord dat beëindigd wordt met een “OK” indien alles succesvol verlopen is en met een “ERROR” indien er een fout is opgetreden. We kunnen onderscheid maken tussen drie soorten commando sets:

• de basis commando set • de uitgebreide commando set • de merkspecifieke commando set

De basis commando set kan men herkennen aan de letter die onmiddellijk na AT volgt. Een voorbeeld hiervan is ATZ (Reset Modem) dat gebruikt wordt om de modem te herstellen in zijn oorspronkelijke staat. De uitgebreide commando set bevat commando’s voor functionaliteiten die nog niet aanwezig waren bij de eerste implementaties van de smart modem. Een voorbeeld hiervan zijn de SMS-commando’s die we zullen gebruiken bij onze implementatie. Tot slot zijn er ook nog merkspecifieke commando sets die verschillen per modemfabrikant en zelfs per model.

SMS AT commando’s De AT commando’s die we gebruiken voor het uitlezen van de SMS-berichten zijn weergegeven in Tabel 4.1.


AT commando

Betekenis

AT+CMGF

Stelt het berichtenformaat in:

35

0 = PDU mode (default) 1 = text mode. AT+CMGL

Duidt aan welk type berichten we wensen uit te lezen 0 / REC UNREAD = Nieuwe ongelezen berichten 1 / REC READ = Opgeslagen reeds gelezen berichten 2 / STO UNSENT = Opgeslagen niet-verzonden berichten 3 / STO SENT = Opgeslagen verzonden berichten 4 / ALL = Alle berichten

AT+CMGR

Wordt gebruikt om een bericht op een specifieke plaats uit te lezen

AT+CMGD

Wordt gebruikt om een bericht op een specifieke plaats te verwijderen

AT+CPMS

Hiermee kan men het geheugen selecteren van waaruit men berichten wil lezen of naar waar men berichten wil schrijven Tabel 4.1: SMS AT commando’s

4.5.2

Uitlezen van SMS via AT commando’s

SMS-berichten kunnen op twee manieren uit de GSM ingelezen worden: in Protocol Description Unit (PDU) mode of in text mode. Text mode is eigenlijk gewoon een decodering van de PDU-mode. Het nadeel aan text mode is dat niet alle GSM-toestellen deze mode ondersteunen en dat we gelimiteerd zijn tot de aanwezige coderingsschema’s. Aangezien de Nokia 6021 wel ondersteuning biedt voor text mode en het enkel de bedoeling is om eenvoudige tekstberichten uit te wisselen volstaat de text mode. Bij PDU-mode moeten we zelf voor de volledige decodering zorgen. Het eerste wat moet gebeuren, is het instellen van de text mode. Hiertoe sturen we het volgende AT-commando naar de GSM: AT+CMGF=1. Vervolgens kunnen we beginnen met het eigenlijke uitlezen van de SMS-berichten. We lezen eerst alle SMS-berichten uit het SM-geheugen (SIM-geheugen) uit en vervolgens lezen we alle SMS-berichten uit het ME-geheugen (telefoongeheugen) uit. Het ME-geheugen bevat alle SMS-


36

berichten die niet op de SIM-kaart zijn opgeslagen. Omdat we enkel nieuwe, nog ongelezen SMSberichten wensen uit te lezen, kunnen we dit realiseren met behulp van de volgende commando’s: • SIM-geheugen: AT+CPMS=“SM” gevolgd door AT+CMGL=“rec unread” om alle ongelezen SMS-berichten uit te lezen • Telefoongeheugen: AT+CPMS=“ME” gevolgd door AT+CMGL=“rec unread” om alle ongelezen SMS-berichten uit te lezen

We beschikken nu over alle ongelezen SMS-berichten, die we terugkrijgen als 1 lange tekststring. We merken op dat na het uitvoeren van AT+CMGL=“rec unread” de normale melding op het GSM-toestel “1 bericht ontvangen” verdwijnt. Zolang het gaat om een bericht van de CaReportcentrale is dit geen probleem. Het kan natuurlijk gebeuren dat de verpleegkundige een privé SMS-bericht kreeg en dan zal de CaReport-applicatie dit SMS-bericht eveneens uitlezen. We kunnen onze SMS-berichten immers pas na het uitlezen filteren op afzender. Dit vereist dat de CaReport-applicatie een melding geeft aan de verpleegkundige dat een privé SMS-bericht ontvangen werd. Aangezien de melding van het GSM-scherm verdwijnt kan men immers niet meer weten dat men een SMS-bericht heeft ontvangen. Een bijkomend probleem is dat de verpleegkundige uit gewoonte bij het binnenkomen van een SMS-bericht het bericht zal lezen. Op zich is dit niet zo erg, ware het niet dat AT+CMGL=“rec unread” geen nieuwe berichten meer zal vinden. Bij het lezen van een nieuw bericht uit het GSM-toestel wijzigt de status van het SMS-bericht immers van “rec unread” naar “rec read”. Om hieraan tegemoet te komen zullen we naast de nieuw ontvangen SMS-berichten ook alle andere op de GSM aanwezige SMS-berichten uitlezen. Dit kunnen we realiseren door eerst een AT+CMGL=“rec unread” uit te voeren, gevolgd door een AT+CMGL=“rec read”. Op die manier zijn we zeker dat we het SMS-bericht afkomstig van de CaReport-centrale terug zullen vinden. Het nadeel aan deze manier van werken is dat AT+CMGL=“rec read” alle SMSberichten uitleest en dat dit eventjes kan duren. Bovendien krijgen we één lange tekststring terug. Dit probleem stelt zich ook bij AT+CMGL=“rec unread”. Voor de eenvoud schrijven we een nieuwe klasse die in staat is om de lange tekststring te parsen naar individuele berichten waar we gemakkelijk het telefoonnummer, de plaats in het geheugen, de status, het bericht en de datum en tijd kunnen uithalen. Omdat de verpleegkundige enkel in een noodsituatie een SMS-bericht zal ontvangen, kiezen we

4.6 Besluit

37

niet voor een constante polling. We laten het aan de verpleegkundige over om in de CaReportapplicatie het uitlezen van het SMS-bericht te beginnen. Hiervoor zullen we een extra knopje in de applicatie voorzien. Op die manier vermijden we ook dat de applicatie de melding moet maken dat het om een privé SMS-bericht gaat. Wanneer de verpleegkundige beslist dat het ontvangen SMS-bericht in de CaReport-applicatie moet ingelezen worden, moeten we uit de vele SMS-berichten die op het GSM-toestel aanwezig zijn het SMS-bericht zoeken dat van de juiste afzender, de CaReport-centrale, komt. Hiervoor houden we op de IVT een lijst met toegelaten afzenders bij. Van zodra het SMS-bericht uitgelezen is, verwijderen we het via het commando: AT+CMGD=“<positie van te verwijderen bericht>”. Deze positie kunnen we gemakkelijk opvragen uit de eigenschappen van het SMSbericht.

4.6

Besluit

In voorgaande paragrafen hebben we aangetoond dat we een SMS-bericht uit het GSM-toestel kunnen inlezen op de PDA en verwijderen van zodra we het ingelezen hebben. Een opmerking hierbij is dat niet alle GSM-toestellen de text mode ondersteunen. Het instellen en gebruiken van AT-commando’s is bovendien zeer toestelspecifiek. De methode hierboven beschreven zou moeten werken voor de meeste Nokia GSM-toestellen, maar biedt totaal geen garantie voor andere toestellen. De methode werd getest met de Nokia 6021 en de Nokia 6310i.

BLUETOOTH/GPRS-CONVERGENTIELAAG

38

Hoofdstuk 5

Bluetooth/GPRS-convergentielaag In dit vijfde hoofdstuk gaan we dieper in op de ontwikkeling van de Bluetooth/GPRS-convergentielaag. We beginnen dit hoofdstuk met een korte inleiding. Vervolgens bekijken we de Bluetooth-communicatielaag van Tom Pluym [2] van naderbij. We onderzoeken hierbij de mogelijkheden en de eventuele tekortkomingen. Daarna bekijken we de GPRS-communicatielaag binnen de convergentielaag. Vervolgens behandelen we de eigenlijke convergentielaag en bespreken we de mogelijke performantiemogelijkheden. We ronden dit hoofdstuk af met een kort besluit.

5.1

Inleiding

In Figuur 5.1 geven we een overzicht van het te implementeren scenario. We beschikken over twee paden tussen de IVT en de CaReport-server. Enerzijds hebben we het Bluetooth-communicatiepad. Dit pad bestaat enerzijds uit de Bluetooth IVT/IPT-verbinding die ontwikkeld werd door Tom Pluym [2] en anderzijds uit een vaste internetverbinding tussen de IPT en de server. Daarnaast hebben we het GPRS-communicatiepad dat besproken werd in hoofdstuk 3. Het GPRS-communicatiepad loopt rechtstreeks van de IVT naar de server.

5.1 Inleiding

39

Figuur 5.1: Scenario

Het is nu de bedoeling om een convergentielaag te ontwikkelen die transparant kan overschakelen tussen deze twee paden. Het Bluetooth-communicatiepad zal steeds de voorkeur krijgen, omdat deze verbinding over het algemeen goedkoper en sneller is. Het gedeelte tussen de IVT en de IPT is kosteloos en de IPT is via een vaste internetverbinding verbonden met internet. De meeste internetverbindingen zijn tegenwoordig breedbandverbindingen waarvoor een maandelijks vast tarief moet betaald worden. Wat betreft GPRS kunnen we een abonnement nemen op basis van volume of op basis van connectietijd. Indien het Bluetooth-communicatiepad onbeschikbaar is, zullen we overschakelen op het GPRScommunicatiepad. Van zodra het Bluetooth-communicatiepad echter opnieuw beschikbaar wordt, schakelen we terug over van het GPRS-communicatiepad naar het Bluetooth-communicatiepad. De omschakeling tussen het Bluetooth-communicatiepad en het GPRS-communicatiepad moet vlot gebeuren en alle pakketjes moeten correct op de server toekomen. We zullen de nodige maatregelen moeten nemen om het pakketverlies, dat onvermijdelijk zal veroorzaakt worden door de omschakeling tussen het Bluetooth-communicatiepad en het GPRS-communicatiepad, op te vangen. We maken gebruik van volgende apparaten:

5.2 Bluetooth-communicatielaag

40

• HP iPAQ hx2790 • Fujitsu Siemens Lifebook C 1410 • Belkin Bluetooth USB-adapter F8T013 • Nokia 6021

De HP iPAQ hx2790 fungeert als IVT terwijl de Lifebook C de rol van IPT vervult. Hoewel de Lifebook C over Bluetooth beschikt, moeten we toch een aparte Bluetooth USB-adapter gebruiken. De Lifebook C beschikt immers over de Toshiba Bluetooth Stack terwijl Franson BlueTools enkel ondersteuning biedt voor de Widcomm of de Microsoft Bluetooth Stack. De gebruikte Belkin Bluetooth USB-adapter beschikt over de Widcomm Bluetooth Stack.

5.2 5.2.1

Bluetooth-communicatielaag Architectuur

Zoals reeds vermeld, werd de Bluetooth-communicatielaag vorig jaar ontwikkeld door Tom Pluym [2]. Hij introduceerde een transparant netwerk waarin meerdere IVT’s met elkaar onderling en met de IPT kunnen communiceren. De IPT speelt hierbij de rol van centrale router. Deze situatie is weergegeven in Figuur 5.2. Met behulp van deze communicatielaag kunnen we nagaan met welke andere Bluetooth-apparaten (IPT en IVT’s) we verbonden zijn en kunnen we gegevens uitwisselen met de gewenste IVT of met de IPT. Deze Bluetooth-communicatielaag is er echter niet op voorzien om gegevens uit te wisselen met een externe server. Indien we dus de foto naar de centrale server wensen te sturen, kunnen we deze enkel naar de IPT of een andere IVT sturen. Op de IPT weten we echter niet of de ontvangen gegevens voor de IPT zelf bestemd zijn, of verder naar de centrale server moeten gerouteerd worden. Er zijn een aantal mogelijkheden om dit probleem op te lossen. We kunnen bij elk pakketje dat we naar de IPT sturen een extra byte toevoegen met een vlag die aangeeft of de data naar de centrale server moet gestuurd worden of niet. Dit vereist dat we op de IPT het IP-adres van de centrale server bijhouden. Indien het echter niet gaat om één centrale server, maar om meerdere


41

Figuur 5.2: Transparant Netwerk

servers (een gegevensserver, een aparte fotoserver,...) moeten we bovendien telkens meegeven naar welke server het nu precies moet verstuurd worden. Dit vereist duidelijke afspraken tussen de IPT en de IVT. Een andere manier is om de Bluetooth-communicatielaag uit te breiden met een veld waarin het IP-adres kan meegegeven worden. Naast gewone data (die voor de IPT zelf bestemd is) kan de IPT dan ook internetdata ontvangen waarvan hij weet dat hij het moet routeren naar het meegegeven IP-adres. Wij kiezen voor deze laatste aanpak. Schematisch is dit weergegeven in Figuur 5.3.


42

Figuur 5.3: Uitgebreid Transparant Netwerk

5.2.2

Transmissiesnelheid

De Bluetooth-communicatielaag bevindt zich tussen de IPT en de IVT. De IPT beschikt over Bluetooth 2.0 + EDR (Belkin Bluetooth USB-adapter) dat transmissiesnelheden kan halen tot 3 Mbps. De IVT (HP iPAQ hx2790) beschikt over Bluetooth v1.2 dat transmissiesnelheden kan halen tot 723.1 Kbps. De beperkende factor is hier dus de IVT.

5.3 GPRS-communicatielaag

5.3 5.3.1

43

GPRS-communicatielaag Architectuur

De GPRS-architectuur waarvan wij gebruik maken is weergegeven in Figuur 5.4. We gebruiken een GPRS-compatibele GSM die ons toelaat om vanop de IVT een verbinding op te zetten met de CaReport-server.

Figuur 5.4: GPRS-architectuur

5.3.2

Transmissiesnelheid

We maken gebruik van een Nokia 6021 die beschikt over GPRS-multislotklasse 10. Uit Tabel 3.2 kunnen we aflezen dat hierbij maximaal 4 tijdsloten kunnen gebruikt worden voor downlinkverkeer en maximaal 2 tijdsloten voor uplinkverkeer. Tegelijkertijd mogen slechts 5 tijdsloten actief zijn (3 downlink - 2 uplink of 4 downlink - 1 uplink). Het Proximus GPRS-netwerk maakt gebruik van coderingsschema CS-2 [14]. Uit Tabel 3.1 kunnen we dan een maximale downloadsnelheid van 53,6 Kbps en een maximale uploadsnelheid van 26,8 Kbps aflezen. Dit is in overeenstemming met de waarden die Proximus zelf meegeeft, namelijk een maximale downloadsnelheid van 54 Kbps en een maximale uploadsnelheid van 27 Kbps. We bemerken het grote verschil in transmissiesnelheid tussen de Bluetooth-communicatielaag en de GPRS-communicatielaag. Bij de ontwikkeling van de convergentielaag zullen we hiermee rekening moeten houden.

5.4

Convergentielaag

In deze paragraaf bekijken we hoe we de transparante convergentielaag met de centrale server kunnen opzetten. Deze communicatielaag zit volledig afgeschermd van de gebruiker en is zelf in

5.4 Convergentielaag

44

staat om de pakketjes via één van de aanwezige verbindingen naar de server te routeren. We beginnen met een beschrijving van de architectuur van de convergentielaag om daarna over te gaan tot de concrete implementatie.

5.4.1

Algemene architectuur

De algemene architectuur van de convergentielaag is weergegeven in Figuur 5.5.

Figuur 5.5: Architectuur convergentielaag

We beschikken over twee communicatiepijpen waarover we gegevens kunnen versturen: de Bluetooth-communicatiepijp en de GPRS-communicatiepijp. Alle gegevens die verzonden moeten worden, gaan door één van beide pijpen. Bovenop deze communicatiepijpen zullen we streamobjecten aanmaken. Een stream kunnen we zien als een punt-tot-punt verbinding met de server waarover we gegevens kunnen verzenden. Een voorbeeld is een fotostream. Deze stream is dan verantwoordelijk voor correcte aflevering van de foto’s aan de CaReport-server. Naast deze fotostream kunnen nog andere streamob-


45

jecten bestaan, zoals een filestream, een controlestream of zelfs een chatstream. Elke stream wordt gekenmerkt door een verschillende streamafhandeling. Een fotostream is bijvoorbeeld éénwegscommunicatie, terwijl een controlestream tweewegscommunicatie vereist. Wanneer de streamobjecten hun gegevens naar de CaReport-server wensen te sturen, moeten ze allemaal gebruik maken van dezelfde communicatiepijpen. We zullen de nodige controle en buffering moeten inbouwen om conflicten te vermijden.

5.4.2

Communicatieprotocol

UDP vs TCP Een eerste keuze die zich opdringt is het gebruik van TCP of UDP voor de uitwisseling van datapakketjes. TCP is een connectie-georiënteerd protocol. Dit houdt in dat alvorens er gegevens kunnen uitgewisseld worden tussen de client en de server, er een handshaking moet worden uitgevoerd. Het laat toe om gegevens in een stream te versturen en is een betrouwbaar transportmechanisme. Alle gegevens zullen foutloos en in de juiste volgorde afgeleverd worden. UDP is een connectieloos protocol. UDP zal proberen om het pakketje af te leveren aan de gewenste server, maar biedt hiervoor geen enkele garantie. Bovendien kunnen pakketjes in willekeurige volgorde afgeleverd worden. Ondanks het feit dat TCP betrouwbare gegevensoverdracht garandeert, kiezen we toch voor UDP. Net zoals bij TCP willen we een betrouwbare punt-tot-punt verbinding tussen de client en de server opzetten. Wij beschikken echter over verschillende soorten communicatieverbindingen waartussen we zelf moeten omschakelen. Het is hierbij niet mogelijk om één punt-tot-punt TCPstream op te zetten die alles afhandelt. Aan de hand van UDP-pakketjes zullen we zelf een soort TCP-systeem ontwikkelen dat in staat is om de gegevens correct aan de server af te leveren én dat terzelfdertijd de meest optimale communicatieverbinding kan kiezen. Nog een extra motivatie voor UDP is dat we anders dubbel werk moeten verrichten. De TCPstream langs het Bluetoothcommunicatiepad kan enkel worden opgezet tussen de IPT en de CaReport-server. Over de Bluetooth-communicatielink zelf hebben we echter geen controle. Op de IVT kunnen we niet weten of het pakketje over de Bluetooth-communicatielink verzonden is of


46

niet. We moeten op de IVT dus hoe dan ook een mechanisme ontwikkelen dat de pakketopvolging bijhoudt.

Protocol Omdat we gebruik maken van het best-effort UDP-protocol voor het uitwisselen van gegevens tussen de IVT en de CaReport-server moeten we een communicatieprotocol afspreken. We beginnen met een handshaking tussen de IVT en de CaReport-server. Tijdens deze handshaking brengt de IVT de CaReport-server op de hoogte dat er gegevens zullen uitgewisseld worden. Eenmaal de handshaking succesvol afgerond is, kan de IVT beginnen met het versturen van de eigenlijke pakketjes. De CaReport-server zal op geregelde tijdstippen acknowledgementberichten naar de IVT terugsturen indien hij de pakketjes correct ontvangen heeft. Voor de implementatie van het communicatieprotocol introduceren we 4 berichttypes waarover alle communicatie met de server zal verlopen:

• RequestMessage • ResponseMessage • InternetDataMessage • AckMessage

RequestMessage.

Dit bericht wordt door de IVT gebruikt om aan de CaReport-server te

laten weten welk type stream hij wenst op te zetten. Dit kan een fotostream zijn, een controlestream,... Verder geeft deze RequestMessage ook het aantal en de grootte van de pakketjes mee.

Figuur 5.6: RequestMessage


ResponseMessage.

47

Dit bericht wordt door de CaReport-server naar de IVT gestuurd om te

laten weten dat alles in orde is om gegevens over de stream te verzenden.

Figuur 5.7: ResponseMessage

InternetDataMessage.

Dit type bericht wordt gebruikt om de eigenlijke data tussen de IVT

en de CaReport-server uit te wisselen. Deze pakketjes kunnen zowel van de IVT naar de server als van de server naar de IVT lopen.

Figuur 5.8: InternetDataMessage

AckMessage.

Deze berichten worden door de CaReport-server naar de IVT gestuurd om de

IVT te laten weten dat een burst van pakketjes correct ontvangen werd.

Figuur 5.9: AckMessage

Ondanks deze 4 opgelegde pakkettypes blijven een aantal keuzemogelijkheden over. We kunnen kiezen of we per ontvangen pakketje een acknowledgement terugsturen of dat we dit pas doen na een aantal goed ontvangen pakketjes, zodat de overhead beperkt wordt. In §5.6 onderzoeken we deze performantiemogelijkheden.

Voorbeelden Fotostream.

Figuur 5.10 geeft een voorbeeld van een fotostream waarbij we na 4 correct

ontvangen pakketjes aan de serverzijde een AckMessage terugsturen.


48

Figuur 5.10: Fotostream

Controlestream.

Figuur 5.11 geeft een voorbeeld van een controlestream waarbij de server

data terugstuurt. Deze InternetDataMessage kan tevens fungeren als AckMessage.

5.5 Implementatie van de convergentielaag

49

Figuur 5.11: Controlestream

5.5

Implementatie van de convergentielaag

Nu we de algemene architectuur hebben besproken en een communicatieprotocol hebben vastgelegd, kunnen we overgaan tot de eigenlijke implementatie van de convergentielaag. Deze implementatie kunnen we opsplitsen in twee grote delen. Enerzijds moet de convergentielaag kunnen omschakelen tussen Bluetooth en GPRS. In dit gedeelte moeten we de toegang tot beide pijpen controleren en beheren. De implementatie hiervan gebeurt in de klasse “Connections”. Anderzijds hebben we ook de streamobjecten die zich bovenop de communicatiepijpen bevinden en die een belangrijk onderdeel vormen van de convergentielaag. Deze implementatie gebeurt in de klasse “Stream”.

5.5.1

“Connections”

Toegangscontrole via een Singleton We beschikken over twee communicatiepijpen waarover het verkeer kan lopen. Van elke pijp mag er slechts één instantie aangemaakt worden: één Bluetooth-communicatiepijp en één GPRScommunicatiepijp. Om dit te realiseren maken we gebruik van het ontwerppatroon “Singleton”, zie Figuur 5.12. Een Singleton wordt gebruikt om het aantal objecten van een klasse tot 1 te beperken. Telkens we gegevens wensen te versturen zal dezelfde instantie van de klasse opgeroepen worden en op die manier creëren we één globaal toegangspunt tot onze communicatiepijpen.


50

Figuur 5.12: Singleton: Connections

Polling van de streamobjecten Omdat we verschillende streamobjecten kunnen aanmaken, moeten we in onze klasse “Connections” een pollingmechanisme voorzien. Dit pollingmechanisme bevraagt alle aanwezige streams of ze te verzenden data hebben. Indien dit het geval is zorgt de klasse “Connections” ervoor dat de data naar de server gestuurd wordt via de juiste communicatiepijp. Het ge¨ımplementeerde mechanisme is Round Robin (Figuur 5.13). Alle streamobjecten worden sequentieel ondervraagd op data. Indien er geen data aanwezig is, gaan we over naar de volgende stream. Deze implementatie kan later eventueel uitgebreid worden met een wachtlijnsysteem dat rekening houdt met de prioriteiten van de streams. Bij een dergelijke implementatie zou men een fotostream een hogere prioriteit kunnen geven dan een chatstream.

Figuur 5.13: Round Robin polling

Aanmaken van de streamobjecten In de klasse “Connections” zullen we de mogelijkheid moeten voorzien om een streamobject aan te maken. Alle streamobjecten worden door de “Connections”-klasse bijgehouden in een centrale lijst die aan polling onderheven is. De volledige structuur van de klasse “Stream” bespreken we in §5.5.2. Het UML-schema van de klasse “Connections” is weergegeven in Figuur 5.14.


51

Figuur 5.14: klasse Connections

5.5.2

“Stream”

Algemeen Een streamobject beschikt over één of meerdere van onderstaande parameters:

• mode : int • streamtype : byte • ipAddress : IPAddress • packetSize : int

Mode. Bij het aanmaken van het streamobject kunnen we de mode instellen. Hiermee geven we aan over welke communicatiepijp we onze gegevens wensen te versturen. De mogelijke waarden voor de parameter “Mode” zijn weergegeven in Tabel 5.1.


Mode

Betekenis

1

GPRS of Bluetooth. Indien de Bluetooth-communicatiepijp aanwezig is, krijgt

52

deze de voorkeur. In het andere geval schakelen we over op GPRS. 2

Bluetooth. Alle verkeer moet verplicht over de Bluetooth-communicatiepijp lopen. De GPRS-communicatiepijp is verboden, ook al is ze aanwezig.

3

GPRS. Alle verkeer moet verplicht over de GPRS-communicatiepijp lopen. De Bluetooth-communicatiepijp is verboden, ook al is ze aanwezig. Tabel 5.1: Mode

StreamType.

Dit veld wordt niet in de convergentielaag vastgelegd. Het wordt boven de

convergentielaag gebruikt om aan te geven welk type stream we versturen zodat de stream aan de serverzijde correct kan afgehandeld worden. Een fotostream vereist immers een andere afhandeling dan een controlestream.

IpAddress.

Dit veld geeft aan naar welk IP-adres de gegevens moeten verstuurd worden.

Indien dit veld niet aanwezig is, zijn de gegevens voor de IPT bestemd.

PacketSize.

Met behulp van het veld “PacketSize” kunnen we de pakketgrootte van onze

InternetDataMessage-pakketjes instellen. Alvorens we de pakketgrootte kunnen instellen, moeten we onderzoeken wat de meest beperkende Maximum Transfer Unit (MTU) is die we op weg naar de server tegenkomen. De MTU van GPRS en van Ethernet is 1500 bytes. Dit werd experimenteel gecontroleerd met behulp van de netwerksniffer “Wireshark” [15]. Van zodra we pakketjes versturen die groter zijn, gebeurt er een fragmentatie. Bij deze fragmentatie wordt gewoon een stuk van het pakketje afgeknipt dat verdwijnt. We zijn dan niet meer in staat om het UDP-pakket terug te vinden. Tom Pluym [2] maakt geen melding van de MTU van de Bluetooth-communicatielaag. Enkele experimenten tonen aan dat de MTU een stuk hoger ligt dan 1500 bytes. We limiteren de maximale pakketgrootte daarom op 1500 bytes. Met deze gegevens kunnen we beperkingen opleggen wat betreft de instelbare pakketgrootte. Indien geen waarde opgegeven wordt, gebruiken we een pakketgrootte van 1454 bytes. Deze


53

grootte is gebaseerd op de maximale pakketgrootte (1500 bytes) - 20 bytes IP-header - 8 bytes UDP-header - 18 bytes eigen header die gebruikt wordt bij het verzenden van een InternetDataMessage (zie Figuur 5.15). Wanneer de gebruiker een pakketgrootte ingeeft die groter is dan 1454 bytes, worden automatisch pakketjes van 1454 bytes gebruikt.

Figuur 5.15: Ethernet-pakketten

Meerdere objecten per stream Een uitbreiding op de algemene streamklasse is de mogelijkheid om verschillende objecten per stream te versturen. We kunnen op die manier een fotostream opzetten waarover we verschillende foto’s kunnen versturen. De streamklasse zal al deze aanvragen in een wachtlijn plaatsen en vervolgens de objecten sequentieel versturen. Per nieuw object wordt een nieuwe RequestMessage en ResponseMessage uitgewisseld die de streamgegevens actualiseert. Zo worden het aantal pakketjes en de pakketgrootte aangepast aan de te verzenden data. Het principe van meerdere objecten per stream en de wisselwerking tussen verschillende streams is schematisch weergegeven in Figuur 5.16.

5.5.3

Verband tussen “Connections” en “Stream”

Figuur 5.17 geeft het verband weer tussen de klasse “Connections” en de klasse “Stream”. Een stream op de IVT communiceert met een stream op de CaReport-server en maakt hiervoor gebruik van de klasse “Connections” die de communicatiepijpen beheert en controleert.


Figuur 5.16: Verschillende streams met meerdere objecten per stream

Figuur 5.17: Verband tussen Connections en Stream

54

5.6 Resultaten en Performantie

5.6

55

Resultaten en Performantie

In deze paragraaf bespreken we de performantie van de Bluetooth/GPRS-convergentielaag. We bekijken hierbij een half-duplex en een full-duplex implementatie. In een eerste fase onderzoeken we de performantie van het Bluetooth-communicatiepad en het GPRS-communicatiepad afzonderlijk. Wat betreft het GPRS-communicatiepad toetsen we de convergentielaag aan een TCP-implementatie. Tot slot bespreken we de wisselwerking tussen het Bluetooth-communicatiepad en het GPRS-communicatiepad in de convergentielaag. Voor onderstaande performantiemetingen maken we gebruik van een foto met een grootte van 46304 bytes. De foto wordt verstuurd in pakketjes van 1454 bytes. In totaal worden 32 pakketjes van 1454 bytes verzonden over de communicatielink.

5.6.1

Half-duplex implementatie

Bluetooth Figuur 5.18 toont de gemiddelde transmissietijd via het Bluetooth-communicatiepad in de convergentielaag, indien we gebruik maken van een half-duplex implementatie. Bij deze implementatie versturen we één of meerdere pakketten en wachten we op een acknowledgement-bericht alvorens we één of meerdere nieuwe pakketten versturen. De figuur geeft eveneens de invloed op de transmissietijd weer van het aantal pakketten dat we versturen alvorens we een acknowledgement-bericht terugsturen. Wanneer één acknowledgement-bericht per pakket wordt verstuurd, bedraagt de gemiddelde transmissietijd 8,8 seconden. Indien er één acknowledgement-bericht per 2 pakketten wordt verstuurd, bedraagt de gemiddelde transmissietijd nog slechts 5,7 seconden, wat een tijdswinst van 3,1 seconden betekent. Vanaf één acknowledgement-bericht per 4 verstuurde pakketten, met een transmissietijd van 3,4 seconden, wordt de bijkomende tijdswinst steeds kleiner. Wanneer geen enkel acknowledgement-bericht verstuurd wordt, bedraagt de gemiddelde transmissietijd 1,5 seconden. We bemerken het grote verschil tussen de transmissietijd in het geval waarbij één acknowledgement-bericht per 4 pakketten wordt verstuurd en het geval waarbij geen enkel acknowledge-


56

Figuur 5.18: Bluetooth: half-duplex

ment-bericht wordt verstuurd. Wanneer we de datatrafiek van naderbij bekijken, vinden we de verklaring voor dit fenomeen. De datatrafiek die we beschouwen is weergegeven in Figuur 5.19. De RTT vanaf het verzenden van het eerste requestpakket tot het ontvangen van het responsepakket over het Bluetoothcommunicatiepad bedraagt gemiddeld 0,34 seconden (RTT 1 op Figuur 5.19). De RTT vanaf het verzenden van een datapakket tot het ontvangen van een acknowledgement-bericht bedraagt gemiddeld 0,27 seconden (RTT 2 op Figuur 5.19). De tussenaankomsttijd van 2 pakketjes die direct na elkaar verstuurd werden, bedraagt tussen de 33 en 42 ms (TAT op Figuur 5.19). Er gaat dus heel wat tijd verloren indien we moeten wachten op een acknowledgement-bericht. Deze metingen werden in het lokale thuisnetwerk uitgevoerd. Een ping van op de IPT naar de server leverde een verwaarloosbare tijd op. De hoge RTT wordt dus veroorzaakt door Bluetooth. Een extra vertraging kan ge¨ıntroduceerd worden door het internetpad tussen de IPT en de server. Indien het om een breedbandverbinding gaat, zal deze extra vertraging verwaarloosbaar zijn. Wanneer het echter zou gaan om een 56k-modemverbinding, zullen we wel rekening moeten houden met een niet-verwaarloosbare extra vertraging. We kunnen dus concluderen dat hoe trager de verbinding tussen de IPT en de server (en dus hoe


57

Figuur 5.19: Datatrafiek

hoger de RTT) wordt, hoe groter het positieve effect op de totale transmissietijd wordt wanneer we minder acknowledgement-berichten versturen.

GPRS Figuur 5.20 toont de transmissietijd via het GPRS-communicatiepad binnen de convergentielaag, indien we gebruik maken van een half-duplex implementatie. Wanneer één acknowledgement-bericht per pakket wordt verstuurd, bedraagt de gemiddelde transmissietijd 68,4 seconden. Indien een acknowledgement-bericht pas na een aantal pakketten wordt verstuurd, stellen we vast dat de transmissietijd vlug afneemt en vanaf 4 pakketten per acknowledgement-bericht begint de transmissietijd te schommelen rond de 35 seconden. Het gedrag vanaf dat moment is vrij onvoorspelbaar en hangt af van de conditie van het GPRS-netwerk. Indien alle pakketten correct ontvangen worden, neemt de transmissietijd verder af naarmate er meer pakketten verstuurd worden alvorens een acknowledgement-bericht wordt verstuurd. Van zodra we onderhevig zijn aan pakketverlies zal de transmissietijd echter stijgen naarmate we


58

langer wachten om een acknowledgement-bericht te versturen. De burst wordt immers groter en bij het verlies van één pakket is de volledige burst onderhevig aan retransmissie. Dit uit zich ook in de totale hoeveelheid verzonden en ontvangen bytes. Bij deze metingen werd een timeout ingesteld van 10 seconden, wat inhoudt dat indien geen acknowledgement voor een burst binnen de 10 seconden wordt ontvangen, er een retransmissie van de burst plaatsvindt. We merken op dat voor echt betrouwbare resultaten veel meer metingen moeten uitgevoerd worden en dit gedurende een langere periode. De huidige resultaten zijn beperkte momentopnames en zijn afhankelijk van de toestand van het GPRS-netwerk.

Figuur 5.20: GPRS: half-duplex

Conclusie Uit bovenstaande resultaten kunnen we besluiten dat het voor een half-duplex implementatie een goede keuze is om één acknowledgement-bericht te sturen per 4 verstuurde pakketten. Deze half-duplex oplossing is echter niet optimaal. De transmissietijd via het Bluetooth-communicatiepad bedraagt hierbij gemiddeld 3,4 seconden en de transmissietijd via het GPRS-communicatiepad bedraagt gemiddeld 35,6 seconden. Wanneer we de theoretische transmissiesnelheden van Bluetooth (723,1 Kbps) en GPRS (26,8 Kbps) bekijken, zou het mogelijk moeten


59

zijn om transmissietijden te halen van respectievelijk 0,5 en 13,8 seconden. Wat betreft het Bluetooth-communicatiepad moet hierbij wel opgemerkt worden dat indien we een foto van 1,13 MB rechtstreeks tussen de PDA en de laptop (met de Bluetooth dongle) uitwisselen, we een transmissiesnelheid vaststellen die varieert tussen 318 Kbps en 362 Kbps. Een transmissietijd van 1 seconde voor het Bluetooth-communicatiepad is dus een meer realistische streefwaarde.

5.6.2

Full-duplex implementatie

Bij de full-duplex implementatie versturen we de datapakketten van de IVT naar de server via een eerste UDP-socket, zonder te wachten op acknowledgement-berichten. Het acknowledgement-bericht dat per datapakket vanop de server naar de IVT teruggestuurd wordt, verloopt via een tweede UDP-socket, wat de full-duplex implementatie mogelijk maakt. Een uitzondering hierop vormt de handshaking-procedure. We wachten op het response-bericht voordat de eigenlijke datatrafiek mag beginnen. In de convergentielaag stellen we een timeout in van 5 seconden. Indien binnen deze 5 seconden geen acknowledgement-bericht werd ontvangen, wordt het verloren pakket opnieuw verstuurd. Pakketten die in de verkeerde volgorde aankomen worden automatische herordend.

Bluetooth De gemiddelde transmissietijd voor de foto van 46304 bytes via het Bluetooth-communicatiepad bedraagt 2,1 seconden. Dit is een verbetering van 1,3 seconden ten opzichte van de half-duplex implementatie. Toch ligt deze waarde nog steeds 1,1 seconde hoger dan de theoretische streefwaarde. We kunnen dit opnieuw verklaren door de RTT van de handshaking-procedure die aan de eigenlijke data-overdracht vooraf gaat. Op het einde van de datastroom zullen we eveneens even moeten wachten tot het overeenkomstige acknowledgement-bericht ontvangen is.

GPRS Wanneer we de datapakketten over GPRS versturen zonder te wachten op een acknowledgement-bericht, merken we op dat de trafiek stopt na 22 pakketten. 22 pakketten van 1500 bytes komen overeen met een totaal van 33 KByte. Na enig opzoekwerk vinden we dat de uplink-buffer in de meeste terminals varieert tussen de 3 en de 30 KByte [16].


60

Om dit probleem te omzeilen voeren we een beperking in op de verzendsnelheid. Hiertoe houden we een zendvenster bij waarin 15 pakketten zijn toegelaten. Van zodra er een acknowledgement-bericht binnenkomt, komt er een plaats vrij in het zendvenster en kunnen we een nieuw pakket versturen. Deze implementatie levert geen beperkingen op onze full-duplex verbinding. Het eerste acknowledgement-bericht komt immers veel vlugger toe dan de andere 14 pakketten verzonden zijn. Via bovenstaande implementatie bekomen we een gemiddelde transmissietijd via het GPRScommunicatiepad van 23,2 seconden. Dit betekent een tijdswinst van 12,4 seconden in vergelijking met de half-duplex implementatie waarbij we om de 4 pakketten een acknowledgementbericht sturen.

5.6.3

GPRS: Convergentielaag versus TCP

Figuur 5.21 toont de transmissietijd via het GPRS-communicatiepad in het geval van een halfduplex implementatie (met één acknowledgement-bericht per 4 pakketten), een full-duplex implementatie en een TCP-implementatie. In dit laatste geval maken we geen gebruik van de convergentielaag. We versturen de foto van 46304 bytes rechtstreeks vanop de PDA naar de server. We merken op dat de eigen implementatie via de full-duplex verbinding een gemiddelde transmissietijd heeft van 23,2 seconden, terwijl de TCP-verbinding een gemiddelde transmissietijd heeft van 25,9 seconden. Onze eigen implementatie is dus gemiddeld 2,7 seconden sneller dan een gewone TCP-verbinding. [17] bespreekt enkele performantieproblemen van TCP over GPRS. Tot slot merken we op dat het bij GPRS moeilijk is om over een gemiddelde transmissietijd te spreken. De transmissietijd kan sterk variëren naar gelang de belasting van de GSM-masten. Het is immers zo dat GPRS enkel de vrije tijdsloten zal gebruiken en het spraakverkeer altijd prioriteit zal krijgen op het dataverkeer.


61

Figuur 5.21: Transmissietijd GPRS

Figuur 5.22: Verzonden/Ontvangen bytes GPRS


5.6.4

62

Wisselwerking tussen het Bluetooth-communicatiepad en het GPRScommunicatiepad

Handover tussen Bluetooth en GPRS De gemiddelde tijd tussen het laatste correct ontvangen pakket op de server vóór de handover en het eerste correct ontvangen pakket op de server ná de handover bedraagt 33 seconden. Deze 33 seconden worden veroorzaakt door het Bluetooth-communicatiepad. Ongeveer 21 van deze 33 seconden worden veroorzaakt door het feit dat de IVT pas na 21 seconden beseft dat hij zijn connectie met de router (IPT) verloren heeft. Pas nadat de IVT dit beseft kan hij omschakelen naar het GPRS-communicatiepad. Een bijkomende vertraging wordt ge¨ıntroduceerd door het feit dat de IVT nu niet meer verbonden is met een router en een router zal proberen zoeken. Bij het opstarten van de Bluetoothterminal, de IVT, hebben we het Bluetooth interdiscovery-interval ingesteld op 15 seconden. Elke 15 seconden gaat de IVT op zoek naar routers in de nabije omgeving en indien een router gevonden wordt maakt hij een connectie. Indien geen enkele router gevonden wordt, wacht de IVT 15 seconden en herhaalt voorgaande procedure. Nu is het zo dat tijdens deze device discovery de Bluetooth-verbinding volledig wordt opgeëist. Op de site van Franson Bluetools vinden we terug dat het probleem zich situeert in de Bluetoothhardware zelf. De meeste Bluetooth-hardware laat immers geen simultane discovery en actieve connecties toe. Algemeen wordt aangeraden om geen discovery uit te voeren zolang er actieve connecties zijn. In ons geval vormt dit een grote belemmering. Wij willen de discovery elke 15 seconden blijven uitvoeren, omdat we zo vlug mogelijk opnieuw wensen te connecteren met de router om opnieuw het Bluetooth-communicatiepad te kunnen gebruiken. We moeten dus rekening houden met performantieproblemen van de convergentielaag. De Bluetooth-link zal gedurende 10 seconden onbruikbaar worden op het moment dat de discovery plaatsgrijpt. We hebben dus telkens slechts 15 seconden waarin we vlot data kunnen versturen. De enige manier om dit probleem te vermijden is door gebruik te maken van een PDA met ingebouwde GPRS-modem zodat we geen Bluetooth-link tussen de PDA en de GSM moeten opzetten. Omwille van het discovery-probleem is het ook aan te raden om de GPRS-module te starten v´ o´ or

5.7 Besluit

63

de Bluetooth-module. Indien we eerst de Bluetooth-module starten zal de discovery-procedure het voor de GPRS-module moeilijker en soms zelfs onmogelijk maken om op te starten. Bij de omgekeerde werkwijze stellen we geen problemen vast.

Handover tussen GPRS en Bluetooth De handover tussen GPRS en Bluetooth gebeurt vrijwel onmiddellijk. Indien natuurlijk het laatste acknowledgement-bericht niet meer ontvangen werd, kan een retransmissie van het laatste pakket nodig zijn.

5.7

Besluit

In dit hoofdstuk hebben we de samenhang bekeken tussen het Bluetooth-communicatiepad en het GPRS-communicatiepad. Omdat het Bluetooth-communicatiepad nog niet voorzien was op verkeer naar een externe server hebben we hiervoor een uitbreiding voorzien. We ontwikkelden een convergentielaag die over het best-effort UDP-protocol in staat is om transparant pakketten naar de server te sturen, hetzij via het Bluetooth-communicatiepad, hetzij via het GPRS-communicatiepad. De convergentielaag houdt bij welke pakketten correct op de server zijn ontvangen en voert indien nodig retransmissies uit. De full-duplex implementatie is te verkiezen boven de half-duplex implementatie en is iets sneller dan een overdracht via TCP. Tot slot merken we op dat de discovery-procedure tussen de IVT en de IPT voor problemen zorgt van zodra we niet meer geconnecteerd zijn met de IPT. Dit brengt de performantie van de convergentielaag in het gedrang. Een mogelijke oplossing hiervoor is om gebruik te maken van een PDA met ingebouwde GPRS-modem in plaats van een GPRS-verbinding op te zetten over een Bluetooth-link met een GSM-toestel.

INTEGRATIE IN DE CAREPORT-SOFTWARE

64

Hoofdstuk 6

Integratie in de CaReport-software In dit hoofdstuk bekijken we kort de samenhang tussen de gerealiseerde bouwblokken en bespreken we de problemen die we bij de integratie ondervonden. Vervolgens bespreken we de eigenlijke integratie in de CaReport-software.

6.1

Integratie van de eigen bouwblokken

In deze thesis was het de bedoeling dat de verpleegkundige een foto kan nemen van een patiënt en dat deze foto op een transparante manier de CaReport-server bereikt. Indien de verpleegkundige over onvoldoende rechten beschikt om de foto te versturen, moet het mogelijk zijn een SMSbericht te ontvangen dat de nodige toegangssleutels bevat. In hoofdstuk 5 hebben we reeds aangehaald dat er problemen ontstaan van zodra de IVT de connectie met de router (IPT) verliest. Vanaf dan zal de IVT telkens na het verstrijken van het interdiscovery-interval op zoek gaan naar een geschikte router. Tijdens deze discovery-procedure zal de Bluetooth-link tijdelijk onbruikbaar worden en dit gedurende 10 seconden. Om de problemen met de discovery-procedure van de IVT te vermijden, is het belangrijk om de eigen ge¨ımplementeerde Object Push foto-service te starten vóór de Bluetooth-terminal, en dus de discovery-procedure, wordt opgezet. Eenmaal de discovery-procedure van de IVT voorbij is, stellen we vast dat simultane connecties in de meeste gevallen geen probleem vormen. Zo is het mogelijk om simultaan een SMS-bericht

6.2 Integratie in de CaReport-applicatie

65

uit te lezen en gegevens over GPRS te versturen. Ook kunnen we simultaan een foto naar de IVT pushen en gegevens over het Bluetooth-communicatiepad verzenden. Enige voorzichtigheid blijft echter geboden en het is aan te raden om toch zo sequentieel mogelijk te werken.

6.2

Integratie in de CaReport-applicatie

In deze laatste fase gaan we over tot de integratie van de afzonderlijke bouwblokken in de CaReport-applicatie voor Pocket PC. We maken hierbij gebruik van de code van Stijn De Wilde [18]. Deze integratie verloopt in samenwerking met Tom Deweerdt [3] die in dezelfde CaReportapplicatie instaat voor een intelligent authenticatiesysteem dat ervoor zorgt dat de uitgewisselde gegevens over een betrouwbare link naar de CaReport-server worden gestuurd. De betrouwbare gegevensuitwisseling werd gerealiseerd in een laag boven de Bluetooth/GPRS-convergentielaag, maar maakt gebruik van de Bluetooth/GPRS-convergentielaag om de gegevens effectief uit te wisselen. Naast het samenvoegen van de verschillende onderdelen, moeten we ook nog een kleine aanpassing uitvoeren in de GUI van Stijn De Wilde [18]. Het betreft het invoegen van de knop getKey die de verpleegkundige toelaat om een SMS-bericht uit te lezen. Dit is weergegeven in Figuur 6.1.

Figuur 6.1: CaReport

6.3 Besluit

6.3

66

Besluit

De integratie in de CaReport-applicatie verliep in samenwerking met Tom Deweerdt [3]. Het integreren van beide delen liep echter niet van een leien dakje. Hoewel de verschillende onderdelen zoveel mogelijk als afzonderlijke stukken werden ontwikkeld, worden ze op de IPT en de CaReport-server onlosmakelijk met elkaar verbonden. Een aantal aanpassingen van beide kanten drongen zich dan ook op. Door het toevoegen van enkele functionaliteiten en wat creativiteit zijn we er echter in geslaagd om een werkende CaReport-applicatie af te leveren.

BESLUIT

67

Hoofdstuk 7

Besluit In deze thesis was het de bedoeling om een netwerkoplossing te ontwikkelen die een verpleegkundige toelaat om een foto te nemen van een patiënt en ervoor te zorgen dat deze foto op een transparante manier de CaReport-server bereikt. In een eerste fase ontwikkelden we de foto-overdracht tussen het fototoestel en de IVT. We toonden aan dat de standaard op de PDA aanwezige Object Push Service ontoereikend was en we ontwikkelden een eigen Object Push Service die in staat is de foto’s te ontvangen en te verwerken. Vervolgens onderzochten we hoe we de GPRS-verbinding konden realiseren. Deze verbinding wordt gebruikt als alternatief pad om de foto van de IVT naar de CaReport-server te versturen. We kozen voor Bluetooth als draadloze communicatielink tussen de GSM en de IVT. De GPRSinstelling gebeurde via een op de PDA aanwezige Bluetooth-wizard en voor het aanspreken van de verbinding maakten we gebruik van de Connection Manager en de Connection Manager API. We kwamen tot de conclusie dat een PDA met ingebouwde GPRS-modem enkele voordelen heeft ten opzichte van een aparte GSM met GPRS-modem. Om tegemoet te komen aan security en privacy, implementeerden we het idee van een selfdestructing SMS. Indien een verpleegkundige in een noodsituatie geen toegang heeft tot de IPT en het patiëntendossier, kan ze eenvoudig vanuit de CaReport-applicatie een sleutel opvragen die via een SMS-bericht werd ontvangen. Bij de implementatie maakten we gebruik van ATcommando’s. We kwamen tot de conclusie dat de implementatie toestelspecifiek is en geen garantie biedt om te werken met alle mogelijke GSM-toestellen.

BESLUIT

68

In het belangrijkste onderdeel van deze thesis behandelden we de transparante Bluetooth/GPRSconvergentielaag. We onderzochten de twee communicatiepaden en bespraken de belangrijkste problemen. Vanwege Bluetooth-hardware problemen is het moeilijk om de twee communicatiepaden vlot naast elkaar te laten bestaan. De device discovery die uitgevoerd wordt voor het Bluetooth-communicatiepad zorgt ervoor dat het GPRS-communicatiepad tijdelijk onbruikbaar wordt. Het gebruik van een PDA met ingebouwde GPRS-modem zou uitsluitsel kunnen bieden. Dan zijn we immers niet meer afhankelijk van Bluetooth wat betreft het opzetten van de GPRS-verbinding. Tot slot bekeken we de integratie van de afzonderlijke bouwblokken en de integratie in de CaReport-software. Om conflicten te vermijden, worden de Bluetooth-connecties best zo veel mogelijk sequentieel aangesproken. Uit het geleverde onderzoek kunnen we besluiten dat het de moeite zou lonen om deze oplossing te herbekijken met een PDA met ingebouwde GPRS-modem in plaats van gebruik te maken van een aparte GSM met GPRS-modem.

ONTWIKKELEN VAN WINDOWS MOBILE 5.0 PPC APPLICATIES

69

Bijlage A

Ontwikkelen van Windows Mobile 5.0 PPC Applicaties In deze appendix gaan we dieper in op de ontwikkeling van applicaties voor een Pocket PC die beschikt over het Windows Mobile 5.0 platform. De applicaties die de voorbije jaren ontwikkeld werden en waar wij op voortbouwen, waren bestemd voor het Windows Mobile 2003 platform. We bekijken hoe we een nieuwe Windows Mobile 5.0 applicatie kunnen aanmaken en hoe we kunnen omschakelen van een bestaande Windows Mobile 2003 applicatie naar een Windows Mobile 5.0 applicatie.

A.1 A.1.1

Aanmaken van een nieuwe Windows Mobile 5.0 applicatie Benodigde hardware en software

We ontwikkelen onze applicatie in de Microsoft Visual Studio 2005 ontwikkelomgeving. Deze ontwikkelomgeving beschikt niet standaard over de Windows Mobile 5.0 SDK die nodig is voor het ontwikkelen van applicaties voor Windows Mobile 5.0. We kunnen deze SDK echter gratis downloaden op de site van Microsoft. De SDK bevat de nodige Pocket PC Emulatoren, bibliotheken en documentatie. In principe hebben we voor de ontwikkeling voldoende aan de Windows Mobile 5.0 Pocket PC Emulator en moeten we niet over een echt toestel beschikken. Helaas beschikt de Emulator niet

A.1 Aanmaken van een nieuwe Windows Mobile 5.0 applicatie

70

over Bluetooth-hardware, zodat we voor onze Bluetooth-applicaties toch moeten gebruik maken van een echt toestel. Er bestaat wel een mogelijkheid om aan de com-poorten van de emulator een com-poort van de PC te koppelen, maar wij gebruiken de PC zelf ook al als Bluetooth-device. Voor het deployen van de applicatie naar de Pocket PC moeten we bovendien beschikken over Microsoft ActiveSync. Kort samengevat moeten we dus beschikken over:

• Pocket PC met Windows Mobile 5.0 • Windows Mobile 5.0 SDK • Microsoft ActiveSync 4.1.0 (of hoger)

A.1.2

Aanmaken van een nieuw project

We starten Microsoft Visual Studio en gaan in het menu naar File → New → Project. De ontwikkeltaal is Visual C# en we willen een applicatie ontwikkelen voor een smartdevice dat beschikt over Windows Mobile 5.0. Bovendien willen we dat onze applicatie over een GUI beschikt. Daarom selecteren we “Device Application”. Na het kiezen van een geschikte naam en een locatie waar we de applicatie willen opslaan, kiezen we voor “Ok” en wordt de applicatie aangemaakt (Figuur A.1).


71

Figuur A.1: Aanmaken van een nieuw project

A.1.3

Programmeren van de applicatie

Nu de applicatie aangemaakt werd, kunnen we beginnen met het eigenlijke programmeren. In de ontwikkelomgeving (zie Figuur A.2) kunnen we via het drag and drop-systeem eenvoudig elementen uit de toolbox toevoegen aan de GUI. Door te klikken op “view code” kunnen we de code verder manueel aanpassen.


72

Figuur A.2: Ontwikkelomgeving

A.1.4

Compileren en deployen van de applicatie

Eenmaal de code klaar is, kunnen we ze compileren. Eventuele problemen verschijnen in het “Output” venster. We kiezen hiervoor in de menubalk “Build” voor het item “Build solution”. Na een succesvolle build zijn we in staat om de applicatie op de Pocket PC te deployen. We kiezen in de menubalk “Build” voor het item “Deploy”. Het venster uit Figuur A.3 zal verschijnen. Omdat wij rechtstreeks op de Pocket PC werken, kiezen we voor “Windows Mobile 5.0 Pocket PC Device”.

A.2 Omzetten van een Windows Mobile 2003 applicatie naar een Windows Mobile 5.0 applicatie 73

Figuur A.3: Deployen van het project

A.2

Omzetten van een Windows Mobile 2003 applicatie naar een Windows Mobile 5.0 applicatie

We kunnen een applicatie heel eenvoudig omzetten van Windows Mobile 2003 naar Windows Mobile 5.0. We selecteren in de menubalk “Project” het item “Change Target Platform”. In het venster dat verschijnt (Figuur A.4) selecteren we “Windows Mobile 5.0 Pocket PC SDK”. De applicatie wordt nu automatisch geconverteerd.

Figuur A.4: Change Target Platform

FRANSON BLUETOOLS

74

Bijlage B

Franson BlueTools Alle bouwblokken van deze thesis maken gebruik van de Franson BlueTools SDK v1.20b1 . In deze appendix zullen we daarom wat dieper ingaan op de installatie en het gebruik van deze SDK.

B.1

Installatie

De Franson BlueTools SDK v1.20b kan gedownload worden van de site van Franson[7]. Na het downloaden moet de SDK ge¨ınstalleerd worden. Alvorens we de SDK echter kunnen gebruiken, moeten we beschikken over een geldige licentiecode. Er wordt een onderscheid gemaakt tussen het .NET Framework en het .NET Compact Framework (voor Pocket PC). Voor beiden is een verschillende licentiecode nodig. Om de SDK te testen, kan een gratis 14-dagen trial licentiecode aangevraagd worden.

B.2

Extra installatie bij .NET Compact Framework

Indien we gebruik willen maken van BlueTools in het .NET Compact Framework, moeten we nog een aantal native dll-files op onze Pocket PC plaatsen. Deze dll-files kunnen we terugvinden 1

11 september 2006

B.3 Opmerkingen bij de licentiecode

75

in: Start → Programs → Franson BlueTools SDK → .NET Compact Framework 1.0 → Samples & Assemblies → wince420. Het gaat om volgende dll-files:

• BlueTools.dll (Core DLL, moet ge¨ınstalleerd worden) • BlueToolsMS.dll (Microsoft stack ondersteuning). • BlueToolsWC.dll (WidComm stack ondersteuning). • BlueToolsWC150.dll (Uitgebreidde WidComm stack ondersteuning).

We kunnen deze dll-files op de Pocket PC in de \Windows-folder of in dezelfde directory als de applicatie plaatsen. Deze extra installatie is niet nodig voor het .NET Framework omdat deze dll-files automatisch in de \Windows-folder geplaatst werden tijdens de installatie van de Franson BlueTools SDK.

B.3

Opmerkingen bij de licentiecode

In de code bij deze thesis werden de geldige licentiecodes vervangen door oude 14-dagen trial codes. Om een werkende applicatie te krijgen, moeten de licentiecodes opnieuw vervangen worden door geldige licentiecode.

GPRS-ARCHITECTUUR

76

Bijlage C

GPRS-architectuur Het pakketgeörienteerde GPRS-netwerk is een uitbreiding van het bestaande circuitgeörienteerde GSM-netwerk. De architectuur van beide netwerken is weergegeven in Figuur C.

Figuur C.1: GSM- en GPRS-architectuur

De blauwe blokken zijn de elementen die aanwezig zijn in het klassieke GSM-netwerk en de uitbreidingen voor GPRS zijn weergegeven in de gele blokken. In de figuur zien we dat verschillende Mobile Stations (MS) verbonden zijn met een Base Transceiver Station (BTS). De MS’s zijn bijvoorbeeld de GSM’s en de BTS’s zijn de antennemasten. Verschillende BTS’s zijn verbonden met een Base Station Controller (BSC). Deze reserveert

GPRS-ARCHITECTUUR

77

de radiofrequentie, regelt de handovers tussen de BTS’s en verzorgt het oproepen van het MS. Verder zien we dat het GSM-netwerk nog bestaat uit Mobile Switching Centers (MSC), die we eigenlijk kunnen beschouwen als grote switches, en gateway MSC’s (GMSC) die zorgen voor de connecties met andere netwerken, zoals het klassieke PSTN-netwerk. Verder zien we ook nog het HLR en het VLR waarin gegevens over de gebruikers bijgehouden worden. Het AuC zorgt voor de gebruikersidentiteit en moet de datatransmissie beschermen. De extra netwerkelementen voor het GPRS-netwerk zijn twee soorten GPRS support nodes (GSN), namelijk de gateway GPRS support node (GGSN) en de serving GPRS support node (SGSN). De gateway GPRS support node bevindt zich tussen het GPRS-netwerk en de externe PDN en zorgt voor routeringsinformatie voor de GPRS-gebruikers. De serving GPRS support node houdt de locatie bij van de individuele gebruikers, verzamelt gegevens in verband met kostenberekeningen (bijvoorbeeld door het tellen van de bytes), voorziet in security, zorgt voor toegangscontrole en regelt de handover tussen verschillende BSC. De SGSN vraagt o.a. ook gebruikersgegevens op uit het GPRS-register (GR). Voor een gedetailleerde bespreking verwijzen we naar [8].

PDP, MT EN TE

78

Bijlage D

PDP, MT en TE Alvorens men pakketgeschakelde data kan uitwisselen tussen een MS en een netwerk, moet er een PDP-context geactiveerd worden voor het MS. Van zodra een PDP-context geactiveerd is, beschikt het MS over een PDP-adres (IP-adres) dat kan gebruikt worden voor de communicatie met externe netwerken. De GPRS standaard splitst een MS op in twee delen. Er is een Terminal Equipment (TE) gedeelte en een Mobile Termination (MT) gedeelte. De TE en het MT kunnen fysiek tot hetzelfde draadloze toestel behoren, of ze kunnen gescheiden worden. Dit laatste geval treedt op wanneer de TE tot een laptop behoort en de MT tot een toestel zoals een GSM. Indien de TE en de MT niet tot hetzelfde fysieke toestel horen, moet een verbinding tussen de twee toestellen opgezet worden, vooraleer er data kan uitgewisseld worden tussen de applicaties van de TE en het externe netwerk. Vanuit het standpunt van de TE gedraagt de MT zich als een modem. Dit is het scenario dat in deze thesis gebruikt wordt en is weergegeven in Figuur D.1.

Figuur D.1: TE en MT

SPECIFIEKE GPRS-MODEMCOMMANDO’S

79

Bijlage E

Specifieke GPRS-modemcommando’s Het modemcommando waarvan we bij onze GPRS-verbinding gebruik maken is: “+CGDCONT= , , <APN>, , ,”. Dit commando is enkel bruikbaar op GSM-toestellen die over GPRS-functionaliteit beschikken. In dit modemcommando kunnen we een aantal parameters onderscheiden:

• PDP (Packet Data Protocol) Context Identifier Deze numerieke parameter specifieert de PDP-context. Deze parameter is eigen aan de TE-MT interface en wordt gebruikt in relatie met andere PDP-context gerelateerde commando’s. Het bereik van de toegelaten waarden wordt weergegeven door de testuitvoering van het commando (+CGDCONT=?). De minimumwaarde is 1. Voor meer informatie omtrent PDP, TE en MT verwijzen we naar Bijlage D. • Packet Data Protocol type Deze parameter is van het type string en specifieert het PDP-type. Momenteel wordt enkel IP (Internet Protocol) ondersteund. • <APN> Access Point Name Deze parameter is van het type string en is de logische naam die gebruikt wordt om de GGSN van het PDN te selecteren.

SPECIFIEKE GPRS-MODEMCOMMANDO’S

80

• Deze parameter is van het type string en duidt de MT aan in de adresruimte van het PDP. Omdat momenteel enkel IP ondersteund wordt als PDP, zal dit een IP-adres zijn. Wanneer deze waarde null (“0.0.0.0” of 0) is, zal er een adres toegekend worden door de TE gedurende de PDP startup procedure. Indien dit faalt, zal er een dynamisch adres aangevraagd worden. Het toegekende adres zal men kunnen lezen via het +CGPADDR commando. • Deze numerieke parameter controleert de PDP-datacompressie. 0 betekent af. Deze 0waarde is de default waarde en tevens de enige ondersteunde waarde. • Deze numerieke parameter controleert de PDP-headercompressie. 0 betekent af. Deze 0-waarde is de default waarde en tevens de enige ondersteunde waarde.

Het antwoord op dit commando is ofwel het “OK” bericht, ofwel het “ERROR” bericht.

DE STRUCTUUR VAN CONNECTIONINFO

81

Bijlage F

De structuur van ConnectionInfo In deze bijlage bekijken we de structuur van ConnectionInfo wat meer in detail. Deze structuur bevat informatie over de connectie-aanvraag. We bespreken kort de verschillende elementen die opgenomen zijn in de structuur die weergegeven is in Figuur F.1.

public struct ConnectionInfo { public uint cbSize ; public uint dwParams ; public uint dwFlags ; public uint dwPriority ; public int bExclusive ; public int bDisabled ; public Guid guidDestNet ; public IntPtr hWnd ; public uint uMsg ; public uint lParam ; public uint ulMaxCost ; public uint ulMinRcvBw ; public uint ulMaxConnLatency ; }

Figuur F.1: Struct ConnectionInfo


82

• cbSize De cbSize geeft de grootte weer van deze structuur. Niet alle velden zijn immers verplichte velden, zo zijn guidDestNet, MaxCost, MinRcvBw en MaxConnLatency optionele parameters. • dwParams Het element dwParams bevat een lijst met welke optionele parameters er toegelaten zijn. Het gaat hier om volgende optionele velden: – guidDestNet – MaxConnLatency – MaxCost – MinRcvBw • dwFlags Het element dwFlags bevat een lijst van controle- en proxy-vlaggen. Deze vlaggen worden door de applicatie gezet om aan te geven dat hij hiervoor ondersteuning biedt. Zo zal een applicatie die niet overweg kan met een http-proxy enkel een verbinding toegewezen krijgen waarbij geen http-proxy is ingesteld. Wanneer geen enkele vlag ingesteld staat, is enkel een directe IP-verbinding mogelijk. De verschillende proxy-vlaggen zijn: – HTTP – WAP – SOCKS4 – SOCKS5 De verschillende controle-vlaggen zijn: – suspend-aware – registered-home – no error msgs • dwPriority Dit veld bevat de prioriteit van de verbinding. We kunnen kiezen uit de volgende mogelijkheden:


83

– userinteractive – userbackground – useridle – hipribkgnd – idlebkgnd – externalinteractive – lowbgnd We hebben hierbij gekozen voor userinteractive. Dit wil zeggen dat de gebruiker zelf om de verbinding vraagt en dat ze met de hoogste prioriteit moet gemaakt worden. • bExclusive Indien deze waarde true is, kan de connectie niet gedeeld worden met andere applicaties. We hebben hier voor de waarde false gekozen. Het is niet de bedoeling dat enkel deze applicatie de connectie mag gebruiken. • bDisabled Indien deze waarde op true staat, kijkt de connection manager of hij kan connecteren, zonder de verbinding effectief op te zetten. Deze waarde zetten we op false. • guidDestNet Dit veld geeft de globally unique identifier (GUID) van het netwerk naarwaar we de verbinding willen opzetten. Wat betreft het instellen van de Guid hebben we een aantal mogelijkheden. We kunnen de GUID nemen van internet of we kunnen de GUID nemen van de GPRS-verbinding zelf. Deze eerste mogelijkheid, de Guid van internet, heeft het voordeel dat de GPRS-verbinding pas zal gekozen worden op het moment dat geen enkele andere internetverbinding aanwezig is. Indien we bijvoorbeeld op het internet wensen te surfen en de PDA bevindt zich in de cradle, zal een internetconnectie via usb opgezet worden (indien de pc waarop de cradle is aangesloten natuurlijk over een internetverbinding beschikt). De GUID is samen met de aanmaak en het gebruik van de struct ConnectionInfo in Figuur F.2 weergegeven. De GUID voor internet is een vaste GUID.


84

Guid I I D_ D e st N e tI n t ernet = new System . Guid ( " 436 ef144 - b4fb -4863 - a041 -8 f905a62c572 " ); ConnectionInfo connInfo = new ConnectionInfo (); connInfo . guidDestNet = IID_DestNetInternet

Figuur F.2: Gebruik GUID Internet

De tweede mogelijkheid zal enkel toelaten dat de GPRS-verbinding gekozen wordt. Wanneer we de GUID willen kennen van de GPRS-verbinding hebben we twee mogelijkheden. Een eerste mogelijkheid is de GUID opzoeken in het register en een tweede mogelijkheid is het opvragen van de GUID aan de hand van de naam van de verbinding. Het gebruik van de GUID van internet zal de voorkeur verdienen. Het heeft immers geen zin een dure GPRS-verbinding te gebruiken, indien een vaste internetverbinding aanwezig is. Een tweede nadeel van de keuze van de rechtstreekse GUID van de GPRS-verbinding, is dat er geen GPRS-connectie opgezet wordt indien de PDA zich in de cradle bevindt. Dit zal enkel gebeuren als we de PDA uit te cradle halen. De aanmaak van de struct ConnectionInfo en de mapping van de juiste GUID op basis van het opzoeken van de connectienaam ,zoals we ze in de PDA hebben ingesteld (Figuur 3.7), zijn weergegeven in Figuur F.3.

ConnectionInfo connInfo = new ConnectionInfo (); ConnMgrMapConRef (0 , " proximus " , ref connInfo . guidDestNet );

Figuur F.3: Gebruik GUID GPRS-verbinding

• hWnd Dit veld verwijst naar een venster waarin de Connection Manager statuswijzigingen kan weergeven. Wanneer deze waarde 0 is, toont de Connection Manager geen statuswijzigingen. Ongeacht of we dit veld nu gebruiken of niet, kunnen we de status van de connectie steeds opvragen via een functie ConnMgrConnectionStatus. • uMsg Specifieert het bericht dat moet gebruikt worden om statuswijzigingen te posten.


85

• lParam Waarde die in het lParam veld van het bericht geplaatst wordt wanneer statuswijzigingen gepost worden. • ulMaxCost Indien dit veld ingegeven is, kunnen we hier de maximaal toelaatbare kost van de connectie instellen. We maken geen gebruik van dit veld. • ulMinRcvBw Indien dit veld ingegeven is, kunnen we hier de aanvaardbare bandbreedte van de connectie instellen. We maken geen gebruik van dit veld. • ulMaxConnLatency Indien dit veld ingegeven is, kunnen we hier de maximaal aanvaardbare vertraging van de connectie instellen. We maken geen gebruik van dit veld.

BIBLIOGRAFIE

86

Bibliografie [1] Televic. http://www.televic.com/. [2] Tom Pluym. Transparante Bluetooth netwerkoplossing voor context-aware ziekenzorgtoepassingen, 2006. [3] Tom Deweerdt. Studie en implementatie van een intelligent authenticatiesysteem in de ziekenzorg, 2007. [4] Kodak Easyshare V610. http://www.kodak.com/. [5] Evy Troubleyn. Stageverslag Televic. 2006. [6] Object Push Profile.

http://www.palowireless.com/infotooth/tutorial/k11_opp.

asp/. [7] Franson Bluetools SDK. http://franson.com/bluetools/. [8] Jochen Schiller. Mobiele Communicatie. Pearson Education, 2005. [9] Gsm World. http://www.gsmworld.com/. [10] Irda - Infrared Data Association. http://www.irda.org/. [11] Bluetooth. http://www.bluetooth.com/. [12] AT commando’s.

http://www.lammertbies.nl/comm/info/nl_hayes-at-commands.

html. [13] Connectivity Knowledge Platform. http://ckp.made-it.com/. [14] Provider gegevens. 201.65.pdf.

http://www.mcs-nl.com/files/manuals/Providers%20gegevens%

BIBLIOGRAFIE

87

[15] Wireshark. http://www.wireshark.org/. [16] Andrei Gurtov, Matti Passoja, Olli Aalto, and Mika Raitola. Multi-Layer Protocol Tracing in a GPRS Network. http://www.cs.helsinki.fi/u/gurtov/papers/vtc02.html, 2002. [17] Rajiv Chakravorty, Joel Cartwright, and Ian Pratt. Practical Experience with TCP over GPRS. http://www.cl.cam.ac.uk/~rc277/globe02.pdf, 2002. [18] Stijn De Wilde. Contextgevoelige PDA-applicatie voor de thuiszorg, op basis van GPSinformatie, 2005.

LIJST VAN FIGUREN

88

Lijst van figuren 1.1

Algemeen Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1

Kodak EasyShare V610 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.2

Melding bij Object Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.3

Uitschakelen OBEX service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.1

GPRS-verbinding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.2

Bluetooth settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

3.3

Connect to Internet via phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

3.4

Prepairing Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.5

Bluetooth Pairing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.6

Inbelverbinding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.7

Inbelgegevens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.8

Aanpassen van de reeds ingestelde inbelverbinding . . . . . . . . . . . . . . . . .

22

3.9

Extra dial-string en instellen van de baudrate . . . . . . . . . . . . . . . . . . . .

22

3.10 Logon to Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.11 RequirePw

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.12 Lijnsnelheden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

4.1

Self-destructing SMS binnen het algemene scenario . . . . . . . . . . . . . . . . .

29

5.1

Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

5.2

Transparant Netwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

5.3

Uitgebreid Transparant Netwerk . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

LIJST VAN FIGUREN

89

5.4

GPRS-architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

5.5

Architectuur convergentielaag . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

5.6

RequestMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

5.7

ResponseMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5.8

InternetDataMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5.9

AckMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5.10 Fotostream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

5.11 Controlestream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

5.12 Singleton: Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

5.13 Round Robin polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

5.14 klasse Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

5.15 Ethernet-pakketten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

5.16 Verschillende streams met meerdere objecten per stream . . . . . . . . . . . . . .

54

5.17 Verband tussen Connections en Stream . . . . . . . . . . . . . . . . . . . . . . . .

54

5.18 Bluetooth: half-duplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

5.19 Datatrafiek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

5.20 GPRS: half-duplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

5.21 Transmissietijd GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

5.22 Verzonden/Ontvangen bytes GPRS . . . . . . . . . . . . . . . . . . . . . . . . . .

61

6.1

CaReport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

A.1 Aanmaken van een nieuw project . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

A.2 Ontwikkelomgeving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

A.3 Deployen van het project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

A.4 Change Target Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

C.1 GSM- en GPRS-architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

D.1 TE en MT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

78

F.1 Struct ConnectionInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

81

LIJST VAN FIGUREN

90

F.2 Gebruik GUID Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

F.3 Gebruik GUID GPRS-verbinding . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

LIJST VAN TABELLEN

91

Lijst van tabellen 3.1

GPRS-transmissiesnelheden (in Kbps) in functie van het aantal tijdsloten en het gebruikte coderingsschema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

3.2

multislotklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

3.3

GPRS klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

4.1

SMS AT commando’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

5.1

Mode

52

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

GPRS-convergentielaag voor location aware computing in de ziekenzorg

Recommend Documents