Towards Proactive Context-Aware Service Selection in the Geographically Distributed Remote Patient Monitoring System P. Pawar, B. J. F. van Beijnum, H. Mei, H. Hermens
Jan 19, 2016
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