Performance Evaluation of a Smart Remote Patient Monitoring System based Heterogeneous WSN

This paper investigates the development of a remote patient monitoring system based on WBAN Wireless Body Sensor Network. Thus, the main purpose of such design is to interconnect heterogeneous sensor networks not equipped with the HTTP / TCP / UDP stack. A novel gateway architecture is proposed to ensure interoperability and facilitate seamless access to data from different types of body sensors that communicate via different technologies, namely, Bluetooth, IEEE802.15.4 / Zigbee and IEEE 802.15.6. Moreover, an application-layer approach for a Web Service Gateway is also developed for interaction with heterogeneous WSN. The Gateway communicates with the server via the SOAP protocol and manages the service consumption. Since the proposed platform is targeted to monitor the patient health status, a preliminary link test between the sensor and the server is unavoided in terms of quality of service. To evaluate the performances of our proposed platform, a results comparison was conducted based on different communication scenarios (3G, ADSL, and LOCAL). Finding results illustrate the (QoS) constraints, namely, Latency, Packet loss and Jitter. Keywords—WSN; body sensor networks; remote patent monitoring; e-health; SOA


I. INTRODUCTION
To meet the growing needs of effective medical surveillance techniques, Intelligent Remote Patent Monitoring Systems (RPM) have received an important attention.Nowadays, RPMs constitute a multidisciplinary field of research such as microelectronics, telecommunications, signal processing, and computing.In the literature many RPM prototypes have been studied [1]- [3].A Body Sensor Networks (BAN) based RPM system, several types of sensors send collected data to a server, via a communication system, and thereafter transmitted to the medical team for an eventual realtime diagnosis.However, these systems are so diverse; and integrate different communication technologies depending on the target application.In a BAN network, sensors can interact with each other and with the hub via wired or short-range wireless communication suchas Bluetooth [4], IEEE802.15.4/Zigbee [5], MICS [6], ANT [7].WBAN Networks focus on the latest advances in technology and perfectly meet the medical surveillance systems requirements.Indeed, research is conducted to identify the technical challenges in WBAN communication stack and to propose solutions [1], [8].Recently, the IEEE802.15workgroup has launched the IEEE802.15.6 standard dedicated exclusively to WBAN networks [9]- [11].Remote medical surveillance systems raise new technological challenges in terms of reliability, quality of service [12], energy consumption [13], privacy and data security [14], [15].However a convergence between WBAN and Internet of Things (IoT) is a main key to complete these challenges and further improves the quality and efficiency of the service [16].The biggest challenge in the design of IoT is connectivity.The creation of large-scale communicating smart object networks has become the goal of many recent and diverse research activities [4], [6]- [18].Several systems allows direct sensors networks connection with the Internet network have been proposed [19]- [21], sensors are equipped with HTTP / TCP / UDP stack.However, connecting a simple sensor directly to Internet increases energy consumption and consequently reduces nodes life time [22], cost and complexity, especially if the sensor does not processes data.One approach is to interconnect the sensors network to Internet through a gateway that supports IP network connectivity [23], [24].The purpose of this paper is to develop a WBAN remote patient monitoring system and interconnecting heterogeneous sensor networks not equipped with the HTTP / TCP / UDP stack, by developing a new gateway architecture to ensure interoperability and access to data from different body sensors network protocols, including: Bluetooth, IEEE 802.15.4 / Zigbee and 802.15.6, in this architecture Only the server should have a fixed IP address and just the gateway should implement TCP/IP protocols, therefore services discovery is fast, nodes management is easy, nodes coupling is low, and the design is flexible and extensible, additionally the gateway can implement more than one WBAN protocol to support heterogeneous sensors protocols.The communication between each sensor and the gateway uses a specific protocol which is the sensor protocol, however the Gateway use SOA over internet to communicate with the server.The Gateway application-layer interacts with heterogeneous WSN and avoids interferences between heterogeneous protocols.In our proposed architecture, the gateway manages the service consumption and communicates with the server via the SOAP protocol.The proposed platform targeted to monitor and process patient health status, thus platform performances evaluation is mandatory.The paper is organized as follows.Section 2 briefly describes the architecture of BAN-based RPM systems.In Section 3, we describe details on our proposed design.In Section 4, we perform several experiments to evaluate platform performances.Finally, Section 5 concludes the paper.www.ijacsa.thesai.orgII.BAN-BASED RPM SYSTEMS General architecture of a BAN-Based RPM system that corresponds to the different approaches proposed in the literature [17], [19], [25] (Fig. 1).It consists of three levels, but it may vary depending on the intended application, and may be limited to one or two levels.The first intra-BAN level consists of a BAN network that aims to centralize all the information provided by the sensors to a central coordinator, also located on the human body.An inter-BAN level provides communication between the coordinator, one or more access points located near the coordinator, or even the coordinators of other BAN networks.Finally, an extra-BAN level is responsible for routing data to a remote server via a WAN network.Data is transmitted to the medical team to obtain a real-time diagnosis or a medical database to record them, or to additional equipment for emergency alerts.
There are generally three main categories of networks in a RPM system [17]: Body Area Network (BAN), Personal Area Network (PAN), Wide Area Network (WAN).In a selfmonitoring application intended to help patients to monitor their own fitness and health indicators using smart devices, smartphone or tablet; sensor nodes communicate directly with an intelligent device, forming a body area network (BAN) [26], [27].However, in the case where the data is not processed locally but in the "cloud", the PAN network is used to connect directly, or via an access point, different BAN networks to WAN network [28].It is also possible that the BAN coordinator sends the collected data andvia WAN network to a remote server.In the BAN network, the sensors can interact with the coordinator via wired or short-range wireless (WPAN) communication such as Bluetooth, IEEE 802.15. 4 / Zigbee [24], MICS and ANT.Recently, IEEE802.15.6workgroupis established [10], which will be dedicated only to BAN applications [29].Bluetooth and IEEE802.15.4 are two standards widely used as communication technologies between the BAN coordinator and a Network Access Point (NAP), but also as a network gateway to cover larger areas at a lower cost.The Wi-Fi network is widely deployed as a Network Access Point which allows the WBAN network to connect to the Internet.Wide area network (WAN) systems may be cellular networks such as GSM, GPRG, 3G / 3G+ [30], LTE, Wimax, or wired communication networks (ADSL, coaxial cable and optical fiber) , or satellite networks .

III. PROPOSED REMOTE PATIENT MONITORING PLATFORM DESIGN
In this section, we propose a platform architecture for Remote Patent Monitoring systems, based on wireless sensor networks.First, we present the hardware, software platform components, and operating modes.Our RPM platform design is composed of Wireless Body Sensor Networks (WBAN) and a back-end system (Fig. 1, 2, and 3).A BAN network consists of a Gateway and a set of heterogeneous sensors.The Gateway connects the BAN to Internet; the Gateway process, storage and transfer patient data.Communication between BAN entities is an Intra-BAN communication, it is wireless and supports different communication protocols.Communication between the BAN and the server (Back-End System) is considered as an Extra-BAN communication.The extra-BAN communication can be wired or wireless via Internet using Simple Object Access Protocol (SOAP).The sensors periodically collect and send data to the gateway, which in turn transmits them to the server over Internet.Medical staff can view the patient's history after an alert or at any time.Biomedical signals can be processed locally in the BAN network or remotely in the Frond-End system.A Frond-End system supports the tracking of multiple patients, i.e. multiple BANs are served by a single Fornd-End system.The Frond-End system includes the back-end server and additional applications whose functions include the processing of received biomedical signals.The idea of outsourcing digital resources to remote servers offers very large computing and storage capabilities, unlike traditional Gateway hosting.

A. Server
The basic services offered by the platform are previously installed on the server which has a fixed IP address, accessible from the public Internet.The Web Services Description Language (WSDL) file, provided by the server, describes the full usage of the service (methods, parameters, and return values).With the discovery service, the server detects automatically new Gateways in the network.The server database contains approved Gateways list and their attached sensors.The server receives data from the various sensors via the Gateway and stores them in a database for statistical and further examination.The server also keeps track of all transactions and medical data.It provides authentication, privacy and security.Fig. 4 shows the general protocols and services stack of the server.

B. Gateway
Gateway is developed to integrate wireless sensors deployed and web applications; it is used to connect the BAN network to Internet.The Gateway enable connectivity between heterogeneous WSN protocols (Zigbee, Bluetooth, UWB, BAN), the gateway is completely transparent; it uses the standard communication protocols of the Web, like HTTP/HTTPS, to communicate with the Web server.XML files are used for the connection configuration, including web server address, http protocol, authentication, data priority etc..The connection to the web server is not permanent, it is established only when the gateway wants to send data.
As shown in Fig. 5, the gateway protocols and services stack includes several PHY physical layers (Bluetooth, UWB, Bluetooth, ZigBee, WIFI ...).The application layer contains several modules that allow the gateway to manage attached nodes.The bridge layer allows the possibility to interconnect and heterogeneous sensors.The bridge layer establishes communication between two different access protocols.For example, to execute an emergency rule, a Bluetooth sensor can communicate a measurement to a ZigBee actuator.In this case every node should have several addresses like the number of supported access protocols (this information is stored in the gateway an handled by the bridge layer).www.ijacsa.thesai.orgFor proof of concept, we have implemented services on remote server which communicate with the gateway via HTTP and SOAP.We have evaluated the experimental performance of the proposed platform in a real world environment under different scenarios.A typical testbed for evaluating the performance is illustrated in Fig. 6.The testbed includes three different technologies: LAN, Wifi and 3G.Here, we have used two types of test plans: request-response delay and availability test.www.ijacsa.thesai.orgWe ran the tests with following Quality of Service (QoS) constraints: Latency, Packet loss and Jitter.We use open source packet analyzer "Wireshark" to capture packets that are being sent and received across the network.
We also ran for each scenario, a large number of request responses.The test results are shown in Table I.We notice that the average latency in the local test case is around 2s.This value is lower than those recorded in the two test scenarios 3G (2.47s) and ADSL (2.15s).The average latency in the 3G test is higher than those recorded in both the Local and ADSL test scenarios, this is mainly due to congestion caused by the HTTP priority configuration and network equipment.We can also observe that the packet loss rate observed during the local test equal to 2.3% is lower than those observed during 3G (13.6%) and ADSL (15%) tests.Fig. 10, 11 and 12 plot the probability distribution function of latency for the three test scenarios: Local, ADSL and 3G.As www.ijacsa.thesai.orgwe can see, the latency distribution takes a Gaussian form whose standard deviation depends on the jitter.High jitter means that delays are highly variable, disrupting protocols in real time.The stability of the bandwidth on the local network has meant that the jitter is significantly lower compared to the jitter resulting from the ADSL or 3G test.

V. CONCLUSION
In this paper, an application-layer approach for a WebService Based Gateway is designed.Our proposed Gateway is a communication bridge between heterogeneous sensors networks.The Gateway application layer makes sensors able to adapt and understand the various proprietary protocols.The designed Gateway uses Web standard communication protocols to communicate with the Web Server.The proposed system proves good scalability and low delay.In summary, results show that our design supports several communication modes depending on the RPM system objective (Speed, QoS, DataRate, Range).
As future steps, continued efforts are needed to complete system validation, and integration of additional sensor elements will be performed.

Fig. 1 .
Fig. 1.General Architecture of a Body Area Network (BAN)-based RPM System.

Fig. 3 .
Fig. 3. General Architecture for Our Remote Patient Monitoring Platform.

Fig. 7 ,
Fig. 7, 8 and 9 show the latency variation using 1000 request messages for three test scenarios: Local, ADSL and 3G.

TABLE I
Fig. 10.Probability Distribution Function -Local Test.