Towards Proactive Context-Aware Service Selection in the Geographically Distributed

Remote Patient Monitoring SystemP. Pawar, B. J. F. van Beijnum, H. Mei, H. Hermens

Outline Introduction

– Remote patient monitoring system (RPMS)– Proactive and reactive context-aware service selection

Problem description– Need for distributed RPMS solution in the large scale geographic

environment– Clever solution is required for proactive service selection

Solution– Hierarchical architecture for distributed RPMS– Services, data and context flow– Proactive service selection approach

Simulation methodology Conclusion and future work

Introduction

AWARENESS Project: Remote Patient Monitoring System

Architecture of the Centralized Remote Patient Monitoring System

Based on the SOA concept Fixed and mobile services Services have associated

context sources Emergency response services:

doctor, ambulance/paramedic, hospital

SSIM uses context information of the patient and ERSs to select appropriate ERSs

SurrogateHost

ServiceDirectory

ContextServer

DataServer

Service Selection &Invocation

Module

1…n

1…n

1…n

Mobile Services Fixed Services Context Sources

Service Reg. Context Publishing Communication

Useful context information– Location of patient, ambulance, hospital– Availability of ERSs– Patient emergency status

Reactive and Proactive ERSs Selection Approaches

Reactive approach– Select ERSs on occurrence

of emergency Proactive approach

– Select ERSs before emergency occurs

Persistent context-aware service discovery is enabler for proactive approach

Context changes need updating ERSs selection

Proactive approach may need higher amount of resources

Problem Description

Proactive ERSs Selection in Large Scale Distributed Remote Patient Monitoring System

For targeting larger geographic region, we need to move from centralized solution to the distributed solution

The distributed solution could have components such as context server, service directory distributed according to the geographic zones

Reactive approach in the distributed RPMS could be a bottleneck due to distributed nature of services and other components

Hence a clever solution for proactive ERSSs selection is required

Solution

Logical Hierarchical Architecture for Distributed RMPS

Mobile Services

Fixed Services

Service Directory

Context Server Context Source

SSI ModuleSurrogate Host

OID Server POS Server

Basic Components and Interactions in Distributed RPMS

Object Index (OID) server: keep track of servers storing object data for queries like which context server stores the context information of caregiver object with OID CG12?

Position (POS) server: Stores X-Y coordinates of the location of fixed and mobile objects

ReferenceCommunicationFixed OID

Context ServerLocation Other ctx.

Service DirectoryProvider Other attr.

POS Server

x

yService Selection &Invocation Module

OID Index SpaceOIDPOS Server

x

yPOS Server

x

y

Service Selection &Invocation ModuleService Selection &

Invocation Module

Service DirectoryProvider Other attr.

Service DirectoryProvider Other attr.

Context ServerLocation Other ctx.

Context ServerLocation Other ctx. Mobile OID

OID Server record

Services, Data and Context Flow

Each level 1 OID-index server subscribes to the service directory (1) and context server (2).

POS server subscribes to the context server (3) to receive object location changes events.

When a service is activated, it first contacts the central data server (4) to obtain service dir., context server and SH info.

Service (5-7-8) and context source registration (6-9). Service directory (context server) sends notification to the OID-

index server (10 (11)). Context server sends notification to the POS-server (12). OID index server updates its records and this update is

propagated to the root level OID index server (13-14). For proactive ERSs selection approach, the surrogate host

sends ERSs selection request to the level 1 SSIM (15). SSIM contacts the POS server (16) to obtain the zone adjacency

list, determines the least common SSIM to the current zone and adjacent zones.

ERSs selection request is forwarded to the least common SSIM (17) which could eventually reach root level SSIM (18) in case required ERSs are not found in these zones.

Level 1

Level 0

FixedService CS

MobileService

CS

CentralData Server

ServiceDirectory

ContextServer

POSServerOID

Server

SSIM

SSIMOIDServer

SurrogateHost

Intermediate Levels

Root Level

14

15

16

17

18

12

4

7

5 6

1011

12

13

9

8

OIDServer

SSIMSSIMSSIMOIDServer

OIDServer

3

Handling Mobile Object’s Geographic Mobility

Results in the handover from old SH to new SH Old SH monitors object location and determines

need for handover and new SH - Use dwell timer to prevent ping-pong effect

Old SH sends the new SH info of the mobile object (1)

Mobile object sends further service and context data to the new SH (3-4).

New SH confirms data reception to old SH (5) Old SH sends the service (context source) removal

due to handover message to the old service directory (old context server) (6 (7)).

New SH registers service (context source) in the new service directory (new context server) (9 (10))

Removal of state of mobile object from old service directory, context server and POS Server (11-12-13)

Registration of state of mobile object to the new POS Server, OID server and further propagations (15-16-17-18)

Level 1

Level 0

MobileService

CS

OldService

Directory

OldContextServer

OldPOS

ServerOldOID

Server

OldSurrogate

Host

Higher Level OID Index Servers

13 15 16 17

1

9 10

3

5

12

8

4

NewService

Directory

NewContextServer

NewSurrogate

Host

2

6 7

NewPOS

ServerNewOID

Server

11

14 18

Proactive Context-Aware ERSs Selection & Invocation Mechanism

Determine initial SSIM Perform context-aware ERSs selection, if

not found, propagate selection request upwards

After ERSs found, send ERSs selection to the maintaining SSIM

Wait for context changes for updating ERSs selection– Caregiver status changes to busy.– Doctor’s status changes to busy. – Hospital is full and can not accommodate

further number of patients. – The relative distance between of the

patient and caregiver (or between the patient and ambulance) exceeds certain value.

– Any of the ERSs (caregiver, ambulance and hospital) goes offline.

– The caregiver (or ambulance) moves out of the current geographic zone.

Zones adjacent to Zone G

E F G H I J

M N O

Q

R

L1

L2

L3

L4

Initial SSIM

1st ER

SsSe

lecti

on

ERSs selected From Zone G & H

ERSs Maintenance

No appropriateERSs found

Simulation Methodology and Approach

Event based simulation– Order and process the

events according to their timestamp (temporal ordering)

– Process events one by one and queue the possible resulting events in the temporal order for further processing

We are working with the medical professionals in Singapore

The simulation will specifically analyze – Resource utilization (e.g. computational and communication requirements, time spent for

the service selection and invocation operations);– Emergency response time savings of the proactive vs. reactive ERSs selection approaches.

Conclusion and Future Work

Conclusion and Future Work

Proactive context-aware ERSs selection approach could be beneficial in the distributed RPMS

A logical architecture for the distributed RPMS where the RPMS components are distributed geographically

Details on the ERSs data and context flow, mobility handling mechanisms and proactive ERSs selection approach in such architecture

Simulation methodology for the performance evaluation for analyzing tradeoff for the resource utilization and emergency response time

Working on the event based simulation of the distributed RPMS modeled according to the geographical zones and patient population distribution in the Singapore region

Acknowledgements

• Freeband Awareness project (Funded by Dutch BSIK program BSIK5902390)

• IST-Amigo project (Partially funded by EC)• Institute for Infocomm Research, Singapore

Questions?

March 19, 2009 Towards Proactive Context-Aware Service Selection 19