Integrating IEEE 11073 and Constrained Application Protocol for Personal Health Devices Danilo F. S. Santos
Frederico M. Bublitz
Signove Tecnologia S.A. Campina Grande, Brazil
Center for Strategic Technologies in Health
[email protected] State University of Paraiba Campina Grande, Brazil
[email protected]
ABSTRACT
Categories and Subject Descriptors D.2.0 [Software]: Software Engineering; J.3 [Computer Applications]: Life and Medical Sciences
General Terms Protocol integration and evaluation
Keywords m-Health, Personal Health Devices, IEEE 11073, CoAP
2.
[email protected] [email protected]
IEEE 11073 AND COAP PROPOSAL
In terms of architecture, the IEEE 11073 defines two types of devices: agents and managers. Agents are data producers, such as sensor devices. Managers are data collectors. Connection may happen in either direction, but usually the agent takes the initiative to start the connection when new data is available e.g. when a patient takes a blood pressure measurement. The IEEE 11073 is transport-agnostic, meaning that it can be carried by almost any packet-based technology, such as TCP/IP, Bluetooth, USB, etc. There are some formal requirements on transport layer for IEEE 11073, such as IEEE 11073 relies on connection oriented channels. Therefore, the transport layer technology must be able to establish a logical (or virtual) channel between the agent and manager, where they can exchange Application Protocol Data Units (APDU). This requirement for channels could be a problem in the Internet, where the concept of services provided by a resource server is wide deployed. The Constrained Application Protocol (CoAP) is a RESTful Web transfer protocol for use with constrained resources devices and networks. CoAP is designed to be used over UDP, and its model is similar to a client/server HTTP model. In fact, it is possible to use CoAP in an HTTP-CoAP proxy
INTRODUCTION
Year after year, we are starting to witness personal health devices capable of transmitting collected data using shortrange wireless technologies like Bluetooth, NFC, ANT+ or the newest Bluetooth Low Energy (BLE), to mention some. Now a set of factors like cheaper components, new standards and the increase of connected devices, created a capable environment to use medical data sensors near our couches. Therefore, in the Connected Health vision, patients are the ones that take control of their health and wellness by being responsible for monitoring themselves using connected
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’14 March 24-28, 2014, Gyeongju, Korea. Copyright 2014 ACM 978-1-4503-2469-4/14/03 ...$15.00.
http://dx.doi.org/10.1145/2554850.2555145
Federal University of Campina Grande Campina Grande, Brazil
devices and the Internet, enabling a true scenario for the Internet of Things (IoT) for healthcare. Based on this Connected Health vision, one current trend from wellness devices manufacturers is to define and implement their own protocols, therefore, creating vertical solutions where their devices only communicate with their services. To avoid the multiplication of propriety solutions, there is an expressive effort from companies and individuals to create standards for Personal Health Devices. One of these effort groups created the IEEE 11073 set of standards declaring how those devices should talk to each other (IEEE 11073-20601 [2]) and how each entity should behave. In parallel, and based on the IoT vision and the increasing number of constrained devices connected with the Internet, the Constrained Application Protocol (CoAP) [3] is being defined by IETF. CoAP is based on the HTTP model, and can be considered a real enabler for IoT. Therefore, its use in a connected health scenario should be evaluated and developed. Following this trend, this article presents an evaluation and proposal for the use of the IEEE 11073 standard over CoAP protocol. It is evaluated how IEEE 11073 communication model should be adapted for CoAP, and what limitations are created. This proposal would enable PHDs to communicate in a standardized way, enabling them to share information across different services and other connected devices.
Nowadays, new challenges are presenting new opportunities for healthcare services in the Internet. The increasing availability of connected Personal Health Devices (PHDs) enables a new type of information to be available in the Internet: health information. However, most of these devices use proprietary protocols, creating vertical solutions where one device just talks to one service. In this context, this paper presents a proposal for the use of the Constrained Application Protocol (CoAP) for PHDs communication, using IEEE 11073 as base health protocol. It is discussed how to carry IEEE 11073 information over CoAP messages and, at the end, evaluation results are presented in comparison with other transport mechanisms.
1.
Hyggo O. Almeida and Angelo Perkusich
466
[1], enabling an interaction between already deployed entities in the Internet and new constrained devices of the Internet of Things. Although CoAP is designed to be carried by UDP packets, it supports confirmable messages, which is a requirement for health data transport layer. Another CoAP attractive feature is its resource discovery capability [4] which allows clients to discover resources hosted by servers.
2.1
every ACK packet carries the response of the request. Network performance tests were executed to validate the retransmission feature of CoAP. In a simulation environment, a loss rate of 10% was added to the channel. This value was chosen to force loss of packets more often. The graph in Figure 1 shows the total amount of packets exchanged in every simple transaction.
IEEE 11073 Client/Server Model
As CoAP model is similar to the HTTP model, requests methods similar to GET, POST, PUT and DELETE are available. However, the IEEE 11073 communication model is based on a bidirectional channel, where the agent and manager exchange APDUs. Having this feature in mind, the first step for integration of CoAP and IEEE 11073 is to map the IEEE 11073 communication model into a CoAP client/server model. This proposal maps IEEE 11073 managers as CoAP servers, and IEEE 11073 agents as CoAP clients, where communication is always started by the PHD. It was considered that the IEEE 11073 Manager and CoAP Server (11073Server) receive POST messages from the IEEE 11073 Agent and CoAP Client (11073Client) in a pre-defined URL. These POST messages carry IEEE 11073 APDUs. This proposal will focus only on the following transactions: Association; Get PHD attributes; Report Events and Observations; Disassociation. Based on this mapping and definition of transactions, it is possible for 11073Clients to report events to 11073Servers using CoAP messages and, at same time, follow IEEE 11073 Communication model.
2.2
Figure 1: Packets exchange in a channel with 10% of loss The main point to observe now is how many packets it takes to complete a transaction when packets are lost. The graph shows that even when losing and retransmitting packets, the CoAP solution exchanges fewer packets than the TCP/IP solution in an ideal channel.
Implementation and Evaluation
3.
For evaluation of the proposed solution, a reference implementation was developed using two open-source tools: Antidote IEEE 11073 Library1 and libCoAP2 . It was developed a CoAP plugin for Antidote using libCoAP. Both implementations were developed and executed on a Linux environment. Evaluation tests were executed in order to validate requirements needed for PHDs, as also, compare the CoAP solution with a solution based on TCP/IP. The first set of tests were executed to show how lightweight is CoAP REST model in comparison to TCP/IP sockets. For these tests, the same set of messages were exchanged between IEEE 11073 agent and manager for TCP and CoAP. This way it is possible to see how many packets and bytes are exchanged in total, and then, clearly see the overhead difference between protocols. Two transactions were compared: a full transaction in a total of nine (9) IEEE 11073 APDUs and 425 bytes; and a simple transaction in a total of five (5) IEEE 11073 APDUs and 172 bytes. The Table 1 resumes the comparison results for each protocol and transaction.
4.
TCP/IP Socket
Full Trans. 12 packets 1295 bytes 24 packets 2039 bytes
5.
Simple Trans. 6 packets 599 bytes 16 packets 1244 bytes
2
REFERENCES
[1] A. Castellani, S. Loreto, A. Rahman, T. Fossati, and E. Dijk. Best practices for http-coap mapping implementation. IETF work in progress. [2] IEEE. ISO/IEEE 11073-20601: Health informatics Point-of-care medical device communication - Part 20601:Optimized exchange protocol Standards, first edition edition. [3] B. F. Shelby, K. Hartke. Constrained application protocol (coap) draft-ietf-core-coap-13. IETF work in progress, 2013. [4] Z. Shelby, S. Krco, C. Bormann, et al. Core resource directory. IETF work in progress, 2012.
It is clear the advantages of CoAP model compared to standard TCP/IP sockets. Besides the use of UDP, one of the main reasons for this reduced number of packets is the use of piggybacked messages in CoAP acknowledgments (ACK) packets. In the CoAP IEEE 11073 implementation, 1
ACKNOWLEDGMENTS
The authors would like to thank the Center for Strategic Technologies in Health (NUTES) at the State University of Paraiba (UEPB) and Signove Tecnologia S.A., for the partial support in the development of this work.
Table 1: Comparison for IEEE 11073 Transactions Transport Protocol CoAP REST
CONCLUSIONS
This paper presented a proposal for use of CoAP and IEEE 11073-20601 as transport method for PHDs. This proposal aims to increase awareness and availability of this medical device standard in many dimensions, making possible to PHDs to exchange information in a standardized and Internet ready way. The preliminary results showed the feasibility of the proposal. The comparison results made clear the lightweight feature of CoAP against the use of TCP/IP. As also, features such as confirmable messages proved to fulfill the requirements for health information exchange. As future work, the evaluation of the security features of CoAP will be studied, as also, scalability studies for the deployment of CoAP in services in cloud, using HTTP-proxies or not.
http://oss.signove.com http://sourceforge.net/projects/libcoap/
467
