smarthealth-ndnot: named data network of things for healthcare services
TRANSCRIPT
SmartHealth-NDNoT: Named Data Network of Things for Healthcare Services
Divya Saxena IIT Roorkee, India
Vaskar Raychoudhury IIT Roorkee, India
Nalluri SriMahathi IIT Roorkee, India
ABSTRACT In recent years, healthcare sector has emerged as a major application area of Internet-of-Things (IoT). IoT aims to automate healthcare services through remote monitoring of patients using several vital sign sensors. Remotely collected patient records are then conveyed to the hospital servers through the user’s smartphones. Healthcare IoT can thus reduce a lot of overhead while allowing people to access healthcare services all the time and everywhere. However, healthcare IoT exchanges data over the IP-centric Internet which has vulnerabilities related to security, privacy, and mobility. Those features are added to the Internet as external add-ons. In order to solve this problem, in this paper, we propose to use Named Data Networking (NDN), which is a future Internet paradigm based on Content-Centric Networking (CCN). NDN has in-built support for user mobility which is well-suited for mobile patients and caregivers. NDN also ensures data security instead of channel security earlier provided by the Internet. In this paper, we have developed NDNoT, which is an IoT solution for smart mobile healthcare using NDN. Our proof-of-concept prototype shows the usability of our proposed architecture.
Categories and Subject Descriptors C.2.1 [COMPUTER-COMMUNICATION NETWORKS]: Net- work Architecture and Design
Keywords Named Data Networking (NDN), Internet of Things (IoT), Open mHealth architecture, NDNoT, Healthcare.
1. INTRODUCTION Healthcare services are integral part of our physical and mental wellbeing across genders and ages. Though the healthcare industry has significantly flourished over the past few decades, existing methods of hospital-centric treatment has several drawbacks. Firstly, it assumes/demands that both patients and caregivers are assembled in a common facility and the healthcare services are limited within that facility instead of being available all the time and everywhere. Bringing critical patients to far away hospitals may increase the potential health risks [1]. Similarly, for people with restricted movements, like neo-natal, elderly or disabled, it is inconvenient, if not impossible to visit to a hospital
for treatment. Secondly, in a large country, like India, with a huge population, usually a single hospital serves a vast region. Infrastructure available in these hospitals is severely stretched in order to cope with the huge influx of patients. Also, the human resources, like doctors and nurses are overwhelmed by the large number of patients they are required to attend. This increases the queue length and demands long waiting times. So, the existing healthcare infrastructure is not sufficient to cater to the needs of the growing population. Finally, people require to take leave for visiting the hospital and while waiting there they are exposed to different types of health risks.
To address the afore-mentioned challenges, and to ensure maximum coverage, quality, and efficiency of healthcare services all the time and everywhere, Information and Communication Technologies (ICT) are infused in order to build smart healthcare infrastructure. Smart healthcare aims to build an Internet of Things (IoT) using wearable vital-sign sensors connected through low-power wireless technologies [2][3][4][5][6]. People can connect to the SmartHealthIoT through their smartphones most of which has in-built sensors like, accelerometer, gyroscope, proximity sensor, microphone, camera, GPS, etc. Patients can be monitored, all the times and everywhere, either in their comfortable home environment or even on the move, through vital-sign sensors connected to their smartphones. The data collected can be analyzed locally and the results are then shared in a secured manner with the caregivers whenever necessary. SmartHealthIoT is useful for people requiring continuous monitoring and care, such as, disabled individuals, elderly and weak persons living alone, children of different ages, and adults who are susceptible to near-fatal falls or sudden increases in blood pressure, heart rates, stress level, etc. In case of emergency, a patient location can be traced using his GPS coordinates.
Though the SmartHealthIoT guarantees improved care at reduced costs, they have certain loopholes due to their dependance on the Internet/IP-based communication. Firstly, due to the continuous and fast increase of smart devices connected to the IoT, soon there will be shortage in the available IP addresses. By 2020, there will be 50 billion devices connected to the Internet [7] and even IPv6 will fail to cope with this huge number. Secondly, mobility support is offered in IP-based system as a add-on feature and hence, it incurs high overhead for mobile users. Moreover, wireless communication channels between sensors and sink may be unstable due to high user mobility. This may disrupt data collection or corrupt the collected data. Thirdly, IP-based systems frequently suffer from security breaches. Patient's health records are sensitive information that require high security and privacy and they might be vulnerable in traditional IP-based systems. Ensuring reliability, performance, and efficiency are some of the other challenges associated with the IP-based systems [8].
In order to address the above challenges we can use a networking paradigm which has capability to interconnect any number of smart devices and have inherent support for mobility, security,
© 2015 Association for Computing Machinery. ACM acknowledges that this contribution was authored or co-authored by an employee, contractor or affiliate of a national government. As such, the Government retains a nonexclusive, royalty-free right to publish or reproduce this article, or to allow others to do so, for Government purposes only. MobileHealth’15, June 22, 2015, Hangzhou, China. Copyright © 2015 ACM 978-1-4503-3525-6/15/06…$15.00. DOI http://dx.doi.org/10.1145/2757290.2757300
45
and reliability. Among the available future Internet architecture, the Named Data Networking (NDN) addresses the above requirements [9][10]. It is a Content-Centric Networking (CCN) paradigm which allows users to fetch and distribute contents directly using their application-assigned names [11]. In this paper, we propose to build a NDN-based SmartHealthIoT which we name as NDNoT. NDNoT will use the NDN capabilities to build an intelligent system for real-time remote patient monitoring, diagnosis, and clinical care. NDNoT supports end-user (patient and/or caregiver) mobility. Sensor collected data is stored in and accessed from the remote server using NDN. For the sake of generalizing, NDNoT is developed over the Open mHealth architecture [12] which is a open architecture for building mobile healthcare applications.
The benefits of using NDNoT are manifold [13]. Firstly, NDN directly access contents using names in a peer-to-peer model instead of a client server model which uses IP-address. So, NDN do not require to translate data names to IP addresses which reduces system overhead and increases efficiency. Secondly, as the contents are well distrbuted across the hosts, proper load balancing can be achieved and the effect of a node failure is minimal. Thirdly, support for user mobility and data security are in-built in NDN. Each Data packet is signed by the content provider to ensure data security. NDN supports encryption-based access control, where content is encrypted in place of communication channels between the end-nodes.
In summary, the main contributions of this paper are as follows.
We have proposed a NDN-based smart health-care IoT, or NDNoT, for remote monitoring and diagnosis of patient's healthcare and wellness. Our system works for both static and mobile users.
We have proposed naming conventions to locate the healthcare services instead of using IP addresses.
Experiments with a proof-of-concept prototype with multiple health sensors show the usability of our proposed system.
The remainder of this paper is organized as follows. In Section 2, we introduce the Open mHealth architecture and the NDN architecture. In Section 3, we present our proposed NDN-based network architecture which uses CRoS routing algorithm [14] for locating the medical services on-demand. In Section 4, we present naming conventions to locate the medical services. Section 5 introduces our experiments and test results. Finally, we conclude the paper in Section 6.
2. RELATED WORK 2.1 Open mHealth Architecture and NDN Architecture An Open mHealth architecture is proposed by Deborah Estrin (Cornell) and Ida Sim (UC San Francisco) in 2010 as shown in Figure 1. The thin-waist of Open mHealth architecture is the interoperability layer which is responsible for data exchange. Open mHealth architecture may support improvements in healthcare through making application development straightforward. Shared standards and reuseable components facilitate fast data collection for self-care, clinical care and research evidence. The healthcare professionals and experts may put the data collection and analysis constituents together for customizing the apps. These apps usability may be increased for people having different age groups, diseases, and treatments
where many underlying functionalities could be re-used for developing innovative applications.
Figure 1. The Open mHealth architecture [12]
2.2 NDN Overview NDN hourglass architecture's thin-waist also supports data exchange instead of service interoperability. Therefore, NDN can be well suited for Open mHealth architecture. NDN supports pull-based communication, initiated by the content requester. It uses two types of packets for communication: Interest packet and Data packet. Content names are embedded in both the Interest and Data packets. When an Interest packet reaches a valid content provider, a Data packet is issued for that content and it carries the corresponding content name. The Data packet retraces the path of the Interest packet in reverse to reach the content requester. The basic objective of NDN is to provide content to requested user irrespective of the location of the hosting entity. In NDN, packets refer the data using the content name whereas these names are not transparent to the network and the only names that are used to get global data must be globally unique. An application can adopt a naming scheme according to its requirement as long as it is independent from the network [11][15].
2.3 Forwarding in NDN Interest forwarding in NDN is facilitated by NDN routers in a hop-by-hop manner. Each NDN router maintains following three data structures [15] shown in Figure 2.
Figure 2. Forwarding process at NDN node [11]
46
Content Store (CS): The CS plays the role of a temporary cache for Data packets (or, contents), to satisfy future requests for already fetched contents. CS uses exact matching for name lookup.
Pending Interest Table (PIT): PIT stores content requests (or, Interests) until they are satisfied. This is why NDN forwarding is called stateful.
Forwarding Information Base (FIB): FIB maintains information about the next-hops and forwards Interest packets using Longest Prefix Match (LPM).
In the next section, we shall discuss the proposed NDN-based system architecture.
3. THE PROPOSED NDN-BASED NETWORK ARCHITECTURE In this section, we presented NDN-based system architecture for remotely monitoring the patient health status, providing them clinical care and emergency services with alert messages all the time and everywhere. This architecture also supports patient's self-care by allowing them to monitor their body reactions toward new medication and new medical plans. The main function of the proposed NDN-based architecture is to collect, transfer, process and analyze the patient's personal health data as a healthcare service using NDN naming communication. The proposed architecture is composed of four layers: embedded systems and sensors, NDNoT gateway, networking services and database, and central controller shown in Figure 3.
Figure 3. System architecture
In the first embedded systems and sensors layer, we have used e-Health sensor shield V2.0 with Arduino which allows users to monitor their health through different sensors. Some of the sensors are Patient Position Sensor (Accelerometer), Glucometer Sensor, Body Temperature Sensor, Blood Pressure Sensor (Sphygmomanometer) V2.0, Pulse and Oxygen in Blood Sensor (SPO2), Airflow Sensor (Breathing), Galvanic Skin Response Sensor (GSR - Sweating), Electrocardiogram Sensor (ECG), Electromyography Sensor (EMG) etc. All the sensors remain connected to the Arduino. Whenever a patient wants either self-care or clinical care from the experts or professionals, he can use his smartphone to collect his personal health information with the help of these sensors in real-time. The gathered raw information will be wirelessly sent for further processing and diagnosis. A camera can also be attached with the sensors to get the actual state of a patient for his health diagnosis. This sensor devices sub-system remains connected to the home network to collect the patient's data.
The second layer NDNoT gateway transfers collected data to the specified healthcare service centers using NDN. Also, the Google Maps Geolocation API [16] is used along with the patient's data for tracking current location of a patient. The third layer of the architecture is networking services and database which records, analyzes and visualizes the patient's health data as shown in Figure 3 and 4. At the back end, Patient DB maintains health
records and Log DB maintains patient's queries. At the middle end, patient database management module is used to aggregate
Figure 4. Service architecture
the incoming new information with the existing patient record. At the front end, patient monitoring module supports intelligent analysis of the data collected to identify deterioration in health condition before any mishappening. Then, it generates report for user/doctor and an automated alarm if needed. The data flow of the proposed architecture is shown in Figure 5 where patient,
47
hospital, doctors, nurses, ambulance and patient's family will remain connected together in case of emergency.
Figure 5. Data flow among different components of healthcare
The fourth central controller layer plays an important role in the proposed architecture. In NDN, a routing protocol is required to install and update FIB entries for forwarding requests over wide-area networks. Our proposed approach uses the already existing NDN CRoS routing algorithm for locating the registered healthcare services. CRoS is based upon NDN Interest and Data packet where it uses CS, PIT and FIB for packet forwarding. The two main network elements of CRoS are router and controller. Routers forward the incoming Interest packet and register named data in their FIB for satisfying future requests. The main task of the controller is to acquire the network topology, register named data locations and to locate the named data services on-demand. The main name prefixes used for this purpose are /controller, /register, and /route. /controller name prefix is used to search any controller while /controller/controllerID is used to search specific controller having same controllerID. /register name prefix is used only by hospitals or healthcare service providers for registering their name prefixes to the controller. /route is a path from consumer to service provider provided by the controller.
The CRoS first phase registers all network routers and their neighbors to the controller. Then, controller forms the network topology and calculates network routes. In the next phase, healthcare service providers can also register their name prefixes to the controller using their HospitalIDs by sending an Interest packet as Interest ("/register/Hospital/HospitalID", nonce) where nonce is used to remove the duplicacy of a request and HospitalID is used to uniquely (e.g., country, state, city, and street) identify the hospitals. For minimizing the overhead because of total number of messages required to locate the health service, all intermediate routers of this Interest will update its FIB entry /Hospital/HospitalID with incoming interface(s). If any intermediate router knows the controller then, it can directly sends request. Any patient who wants to get service from a specific healthcare centre, will send an Interest packet Interest(/Hospital/HospitalID, nonce) to the controller. In response, controller will send a Data packet having /route from requester to that specific service provider.
In IP-based networking, there are many issues related to consumer's and provider's mobility whereas NDN communication model supports the consumer (user-side) mobility without any extra efforts through in-network caching. It supports the smooth hand-off because if consumer moved to another location then, requested content will be cached in-between routers. There will be no need to pull data again from data provider. NDN caching provides high benefits to dynamic content in case of multicast or retransmission due to packet loss. In NDN, in-network storage minimizes the network load and data dissemination latency up to
a high level [17][18]. The another issue may be provider mobility. But, in healthcare, service provider's location remains same over a long period of time.
We have used NDN CRoS routing algorithm for implementing our proposed architecture as it provides network scalability problem solution through multiple controllers, network partition problem solution through election of new controller and large FIB size problem solution through router memory re-use. According to NLSR [19], a CRoS routing algorithm may introduce high overhead because it floods special formatted Interest messages to search the controller. But, in our proposed scenario, once route for healthcare service provider is updated in intermediate router's FIB, there will be less requirement to find controller's location.
4. NDN NAMING CONVENTION We propose to use following structure of data names for NDN-based mobile health data transfer and report generation /Hospital/HospitalID/PatientName/PatientID/Timestamp/Geolocation/DataName where first component of the name Hospital serves as application-id for the healthcare application. The second component HospitalID serves as unique identification of the hospital for routing purpose. The third and fourth components are used to uniquely identify the patients, i.e., PatientName and PatientID where patientID will be provided by the hospitals earlier. The fifth component is Timestamp which uses the format of /date/time where date and time are in DDMMYY and HHMM 24-hour format respectively. The next component is Geolocation which uses the format of /longitute/latitude of the patient’s current location. The DataName component will have the name of sensor, producing that data.
NDN uses receiver-driven communication, i.e., an Interest is needed to pull the required data. Therefore, a patient requests to the hospital for uploading personal health data by sending an Interest packet as Interest(/Hospital/HospitalID/PatientName/PatientID/Timestamp/Geolocation/DataName, nonce). If server is available for providing the services, it will generate same Interest packet for that patient. Now, patient can upload data with the content name as Data(/Hospital/HospitalID/PatientName/PatientID/Timestamp/Geolocation/DataName, nonce).
In the next section, we shall discuss the experiments to test the working of our proposed architecture.
5. PROTOTYPE MOBILE HEALTHCARE APPLICATION We have carried out extensive experiments to test the efficient working of our proposed NDN-based healthcare mobile architecture. A complete sensors sub-system is shown in Figure 6. We have used following types of sensors to collect health-related data of patients.
Patient Position Sensor (Accelerometer), Glucometer (measures blood glucose level) Body Temperature Sensor Blood Pressure Sensor (Sphygmomanometer) Pulse-oximeter (measures pulse rate and blood Oxygen
level) Respiration Sensor (measures respiration rate) Galvanic Skin Response Sensor (measures skin resistance
and conductance) Electrocardiogram (ECG) Sensor
48
Electromyography (EMG) Sensor (measures electrical activity in skeletal muscles)
Figure 6. Sensors sub-system
The readings collected by sensors are in analog format. They are voltage values normally varying from 0V to 5V. Sensors periodically update their values and send to microcontroller. We have used the Arduino MEGA ADK microcontroller board based on ATmega2560. Microcontroller, on receiving voltage values from sensors, it converts the analog voltage values to numbers on the scale of 0 to 100 and then transfer them to smartphone. The topology used for the proposed architecture is shown in Figure 7. There is a central controller, C which is connected to Hospital Server A (HSA) and B (HSB) through an indirect (multi-hop) and a direct path, respectively. A mobile user, M, is also connected to the hospital servers through direct and indirect connections. IR1 and IR2 are two intermediate routers forwarding data traffic. All these systems are residing in the same wireless LAN. The mobile user, M, running on a laptop having Intel(R) Core(TM) i5 3210M 2.5GHz CPU 6GB RAM. Rest of the systems are running on Intel(R) Core(TM) i7 3770 3.4GHz CPU and have 8 GB RAM. The operating system environment is 64-bit Ubuntu 14.04 LTS. For maintaining the topology using NDN, we have used three NDN libraries ndn-cxx [20], NFD [21] and ndn-traffic-generator [22].
5.1 Testing of the prototype mobile healthcare application In order to test the prototype, we have considered a scenario where a mobile user, M, wants to upload personal health data to HSB. Therefore, M sends an Interest packet (I1) to HSB using the request name Hospital/HospB/XYZ/Patient123/300315/1608/29.8644N77.8964E/EMG. We assume that name prefix for HSB is /Hospital/HospB. For routing I1 from M to HSB using CRoS, the FIB in M's router must be updated with information about the name prefix of HSB. In Figure 8, M's FIB has updated faceid (outgoing interface) 261 for the name prefix of HSB. In response to I1 received from M, HSB sends an Interest packet (I2) with the same name inviting M to upload the data (see Figure 9) On receiving I2, M immediately uploads his personal health data to HSB through a Data packet. The Data packet received by the HSB is shown in Figure 10.
Figure 7. Topology for proposed NDN-based health architecture
Figure 8. Mobile user M’s updated FIB
Figure 9. Screenshot of Interest received at mobile user M
interface
Figure 10. Screenshot of an Interest send and Data packet
received at hospital server B interface
49
Figure 11. Screenshot of mobile healthcare server interface
for report generation
Figure 12. Screenshot of mobile healthcare server interface for graph plotting
For better analysis of a patient's health status, hospital servers plot health data collected over a period of time and generates a report which contains doctor’s remarks related to necessary precautions and medications. The report generation at server side interface is shown in Figure 11 and the EMG-plot (using Kst [23]) of the user M is shown in Figure 12.
6. CONCLUSION Smart Healthcare systems were proposed to extend healthcare facilities outside the hospital environment. Several health sensors are deployed to record the vital signs of patients and the data is sent to the user’s smartphone. However, the IP-based smart health systems suffer from several challenging issues like security, privacy, and mobility. In this paper, we proposed to develop a smart health system using NDN which is one of the most promising future Internet architectures. NDN has inherent support for user mobility and data security and it uses unique names to pull contents irrespective of their hosting entity. We have proposed naming conventions to locate network-based healthcare services. Our experimental prototype shows the viability of our proposed model.
7. ACKNOWLEDGMENT
This work is partially supported by the following grants: MHRD (GoI) FIG (A) 100579-ECD and DST (GoI) SB/FTP/ ETA-23/2013.
8. REFERENCES [1] Rani, P., Raychoudhury V., Sandha, S.S. and Patel, D.
Mobile health application for early disease outbreak-period detection. In Proceeding of IEEE Healthcom (Natal, Brazil, Oct. 15-18, 2014), 483-488.
[2] Fan, Y.J. Yin, Y.H., Xu, L.D. Zeng, Y. Wu, F. IoT-based smart rehabilitation system. IEEE Transactions on Industrial Informatics, 10, 2 (Jan. 2014), 1568-1577.
[3] Istepanian, R.S.H. et al. The potential of Internet of m-health Things “m-IoT” for non-invasive glucose level sensing. In Proceeding of EMBC. Boston, 2011, 5264-5266.
[4] Bui, N., Zorzi, M. Health care applications: a solution based on the internet of things. In Proceedings of the 4th International Symposium on Applied Sciences in Biomedical and Communication Technologies. (Barcelona, Spain, October 26 - 29, 2011). ACM, New York, NY, 131.
[5] Lee, C-N, A home care service platform for mobile healthcare, In proceedings of ICMLC. 2012. 1927-1930.
[6] Istepanian, R. S. H. Zhang, Y. T. 2012. Guest editorial introduction to the special section: 4G health—the long-term evolution of m-health. IEEE Transactions on Information Tech. in Biomedicine. 16,1 (2012), 1-5.
[7] Cisco, https://www.cisco.com/web/about/ac79/docs/innov/IoT_IBSG_ 0411FINAL.pdf
[8] D. Uniyal, and V. Raychoudhury, Pervasive Healthcare: A Comprehensive Survey of Tools and Techniques. arXiv:1411.1821 [cs.CY], Nov. 2014.
[9] Baccelli E., et al, “Information Centric Networking in the IoT: Experiments with NDN in the Wild,” in Proceeding. of 1st ACM Conference on Information-Centric Networking (ICN). New York: ACM, 2014, pp. 77–86.
[10] Amadeo, M., et al., "Multi-source data retrieval in IoT via named data networking." Proceedings of the 1st international conference on Information-centric networking. ACM, 2014.
[11] Zhang, L., et al. Named Data Networking (NDN) Project. PARC Technical Report NDN-0001.
[12] Chen, C. et al., 2012. Making sense of mobile health data: an open architecture to improve individual-and population-level health. Journal of medical Internet research. 14(4).
[13] Burke, J., 2015. NDN Network Environment: Open mHealth. Technical Report.
[14] Torres, J. Ferraz, L. and Duarte, O. 2012. Controller-based Routing Scheme for Named Data Network. Technical Report. Electrical Engineering Program.
[15] Jacobson, V. Smetters, D.K. James, T.D. Micheal, P.F. Nicolas, B.H. Rebeeca, B.L. 2009. Networking named content. In Proceedings of CoNEXT. ACM, New York, NY, 1-12.
[16] Google Maps Geolocation API: https://developers.google.com/maps/documentation/business/geolocation
[17] Zhu, Z. Afanasyev, A. and Zhang, L. 2013. A New Perspective on Mobility Support. Named-Data Networking Project, Technical Report.
[18] Wang, L. Wakikawa, R. Kuntz, R. Vuyyuru, R. and Zhang, L. Data naming in vehicle-to-vehicle communications. In Proceedings of INFOCOM WKSHPS (Orlando, March 2012)., IEEE, FI, USA, 328-333.
[19] Hoque, A.K.M. Amin, S.O. Alyyan, A. Zhang, B and Wang, L. 2013. NLSR: Named-data Link State Routing Protocol. In Proceedings of ICN ACM SIGCOMM, New York, NY, 15–20
[20] ndn-cxx: https://github.com/named-data/ndn-cxx [21] NFD: https://github.com/named-data/NFD [22] ndn-traffic-generator:https://github.com/named-data/ndn-
traffic-generator [23] Kst: https://kst-plot.kde.org/
50