eHealth Service Support in Future IPv6 Vehicular Networks

Abstract

Recent vehicular networking activities include novel automotive applications, such as public vehicle to vehicle/infrastructure (V2X), large scale deployments, machine-to-machine (M2M) integration scenarios, and more. The platform described in this paper focuses on the integration of eHealth in a V2I setting. This is to allow the use of Internet from a vehicular setting to disseminate health-related information. From an eHealth viewpoint, the use of remote healthcare solutions to record and transmit a patient’s vital signs is a special telemedicine application that helps hospital resident health professionals to optimally prepare the patient’s admittance. From the automotive perspective, this is a typical vehicle-to-infrastructure (V2I) communication scenario. This proposal provides an IPv6 vehicular platform, which integrates eHealth devices and allows sending captured health-related data to a personal health record (PHR) application server in the IPv6 Internet. The collected data is viewed remotely by a doctor and supports his diagnostic decision. In particular, our work introduces the integration of vehicular and eHealth testbeds, describes related work and presents a lightweight auto-configuration method based on a DHCPv6 extension to provide IPv6 connectivity with a few numbers of messages.

1. Introduction

Vehicular networking serves as a technology enabler for various multi-purpose mobile applications that fully integrate the vision of the future Internet [1]. Intelligent transportation systems (ITSs) [2] are envisioned to play a significant role in the future, making transportation safer and more efficient. With respect to these expectations, vehicle-to-infrastructure interactions have evolved to include various types of applications, safety-related and user-oriented.

1.1. Towards Future Internet

After successfully connecting computers (Internet protocol) and later people (World Wide Web), enabling an Internet of Things is one of the great challenges of the future Internet. According to some estimates, the size of the Internet doubles every 5.32 years, which will lead to an average of 6.58 connected devices per person by 2020 [3]. These 50 billion things [4] connected to the Internet in order to gather information for various and unattended applications that support new markets [5] will create a heavy and dense traffic on the core network. On the other hand, these new and exciting possibilities come with the requirement of a larger addressing space. The IPv4 addressing pool already exhausted [6] the transition to IPv6 with its huge numbering space (2⁹⁶ times bigger than IPv4’s) is urgent [7].

In the wide field of health informatics, the special case of eHealth relates to the use of the Internet to disseminate health related information [8]. The health-related measures are captured by small and various devices and transmitted to be stored in large databases. Further processing of this data helps to support diagnostics. The overall objective is to improve efficiency and save lives [9].

1.2. IPv6 Vehicular Networks

eHealth is one application example that can be supported by ITS. Vehicle-to-infrastructure (V2I) and vehicle-to-vehicle (V2V) settings include several other examples of eSafety and infotainment application support. These applications can be roughly classified into two major types: safety-oriented or user-oriented [10]. Safety applications are clearly time-critical tasks, where message delivery with short delay guarantee is the first design goal. In these use cases, including safety on the road, non-IP communication technologies are often considered for their reliability [11]. In contrast, non-time-critical user-oriented applications include infotainment and other preventions on road applications. The use of IP (best effort) to extend the supported geographic area for these applications is possible [12].

The use of IPv6 in current standardization work for vehicular communications technologies guarantees a better integration in the future Internet. For example, LTE technology supports IPv6 [13], which opens new V2I service perspectives [14]. In recent European Telecommunications Standards Institute (ETSI) activities, a geographic networking protocol combined with an IPv6 stack layer has been experimented upon and standardized [12]. GeoBroadcasting safety messages by relaying messages through a V2V mode in the same geographic zone using IEEE 802.11p has also been experimented upon.

1.3. Remote Healthcare

eHealth can be used for patient monitoring, remote diagnostics, activity monitoring, lifestyle suggestions and personal security to enable novel patient-physician interactions. In terms of challenges, new threats regarding ethical issues, such as online professional practice, informed agreement, privacy and equity, are posed by the remote aspect of the technology.

Contemporary eHealth reality consists of a combination of sensors for individual’s vital sign measurements or even tracking his position in case of an emergency. These sensors come in the form of lightweight portable (or wearable) devices for enhanced user acceptability. State-of-the-art remote monitoring is achieved by combining short-range communications (personal area network (PAN)) for the sensors and general packet radio service (GPRS) access on another device.

Most eHealth applications occur in urban operational environments. Remote management includes cases in which health practitioner intervention is required. There is necessity for high reliability, due to the sensitive nature of data. The eHealth scenario considers event-triggered connections having benefits on network signaling and scheduling. eHealth applications may use mesh routing with multi-hop connectivity. High mobility is expected because of the tracking of moving objects/persons.

1.4. Heterogeneous Networks

The Internet of Things is about small devices (which includes eHealth devices) limited in terms of computing and networking capabilities. Short-range communication technologies, such as radio frequency identification (RFID), Bluetooth, or IEEE 802.15.4 standard are much more common than long-range communication technologies (3G, LTE or WiMax). Therefore, an additional functional element, the gateway (GW), translates between both short- and long-range communication technologies and helps to expand the boundaries of the current Internet. From an addressing perspective, these gateways are called address translation gateways [15], due to their dual addressing function (IP and IEEE 802.15.4 in 6LoWPAN, for example).

With regards to this topic, this paper focuses on the integration scenario between vehicular networking (as an enabling platform) and eHealth technologies (as end user applications). The eHealth devices supported by this platform, namely electrocardiograph (ECG), spirometer, oximeter and blood glucose meters, send health-related measurements over Bluetooth to an IPv6-ready phone application. The cluster head is attached to an IPv6 mobile router (the second part of the testbed) connected to the cellular infrastructure. The cluster head sends these measurements after user review to an application server in the IPv6 Internet. The gathered data is viewed remotely by the user’s physician.

This paper describes the integration of a machine type device (M2M) from the IoT world into an IPv6 vehicular network setting. The remainder of this paper is organized as follows. Section II presents related work in the field of eHealth and vehicular networks. Section III presents auto-configuration in IPv6 networks to meet M2M requirements. Section IV describes the overall system architecture and the functional elements of the adopted solution. Section V shows the protocol messages in the system, and Section VI gives the details of the prototype implementation along with the functional element specifications. The current state of integration and future work are given in Section VII to conclude the paper. Note that this paper is an extended version of [16].

2. Related Work

Vehicular communications emerged as a promising area for the deployment of safety and infotainment applications. A detailed study of the vehicular networking requirements, standards and solutions can be found in [17]. State-of-the-art vehicular networking studies [14] consider V2I and V2V interactions as the main trend for vehicular-related use cases. Usual applications, such as eSafety, traffic efficiency and data dissemination (infotainment), may require infrastructure-based end-to-end access through V2I architectures [18]. In these environments, MIPv6/NEMO [19] is the de facto solution to the network mobility problem in V2I. With this solution, mobile routers (MR) belong to the subnet advertised by the road side units (RSU).

Figure 1 illustrates a set of enabling technologies that apply to the vehicular networking use cases, of which the coverage ranges from local area to cellular [20]. Due to higher market penetration and ubiquitous coverage with broadband throughput, some recent FP7 initiatives [21] propose to handle V2I machine-type communications through LTE. The main technical motivations involve the conservation of an IPv6 end-to-end multi-hop communication model among heterogeneous nodes for in-vehicle embedded networks.

Figure 1. Vehicular-related wireless technologies comparison (adapted from [20]).

Figure 1. Vehicular-related wireless technologies comparison (adapted from [20]).

On the other hand, the eHealth protocol messages carry sensitive data and require integrity, confidentiality and availability. Privacy is one of these security issues and has been addressed by proposing the use of pseudonyms for the medical data [22].

Embedding eHealth systems in a vehicular network is the focus of the WEHealth architecture [23]. WEHealth provides eHealth service for medical needs on roads and enhances security and privacy by the use of the NOTICE framework (a secure and privacy-aware architecture for the notification of traffic incidents). This infrastructure includes short-range communication capable sensor belts placed along the road. The infrastructure in NOTICE uses embedded sensor belts in the road at regular intervals (e.g., every mile or so). Each belt is composed of a collection of pressure sensors and a few small transceivers. The pressure sensors in each belt allow every message to be associated with a physical vehicle passing over the belt, eliminating the need to uniquely identify vehicles in order to interact with them. The sensor belts do not communicate with each other directly and rely on passing cars to carry and forward a message between adjacent belts. Check station belts are authentication centers and pseudonyming proxies. They are placed on the roadside and attached to base stations to access the personal health record (PHR) server on the Internet. Medical queries or accident alarms can be disseminated through the system to provide health records of the patients. In addition to wireless communications with external sensor nodes on the road, the WEHealth platform assumes an underlying IPv4 Internet, and the server side (PHR server) is accessible through base transceivers. The platform presented in this paper does not rely on external interactions with sensors to carry the health-related data to the server and use a cellular long-range interface to provide the PHR server with patient health-related information.

eCall [24] is a recent European standard that brings the possibility of dialing the EU emergency number (112) in case of a serious road accident automatically without the vehicle occupants’ intervention. The European Commission adopted measures to ensure eCall will be available in new car models from 2015, although some manufacturer-specific prototypes are already deployed as proof-of-concept. Due to stringent delay requirements, eCall is to operate only on radio networks (some deployments already use GPRS cellular networks). The platform described in this paper involves non-time-critical eHealth applications; therefore, recorded data can be transported over IP (packet-switched domain).

Monitoring and dealing with a large number of casualties is an important key parameter in disaster response scenarios. The CodeBlue platform [25] provides such a protocol along with a software framework that integrates eHealth devices (such as wearable vital sign sensors, handheld computers and location-tracking tags) to handle disaster response and emergency care scenarios. The prototype proposes to integrate device discovery, robust routing, traffic prioritization, security and RF-based location tracking. In a disaster scenario, handheld computers carried by first responders receive and visualize multiple patients’ vital signs on the implemented application. Based on these observations, triage operation can help to optimize the chances of survival. Along with these objectives, security and privacy are studied according to legal ramifications specific to the USA regulations. The platform presented in this paper does not focus on disaster scenarios and considers a more general everyday health-care usage. In addition, Internet next-generation communication standards are used (IPv6 and LTE).

In a recent European project (IIP) [26], one of the priorities is to create a reliable, stable and universal implementation of IPv6 network services, including DHCPv6, DNS and mobility management mechanisms, as well as applications, including VoIP and IPTV. With respect to these objectives, one target concerns eHealth. By deploying wireless medical sensor technologies over IPv6 to enhance connectivity and security, delivering healthcare services remotely will be possible. One of the objectives is the removal of NAT to allow easy access for service and/or devices and perform remote configuration and maintenance, which is an important issue for the elderly and disabled persons living alone. Our platform also focuses on the future deployment of IPv6, but considers a vehicular setting as a special use case for integration.

3. IPv6 Communications Requirements for M2M

The perspective of machine-to-machine communications on the Internet of Things assumes that small and numerous devices beyond the scale of the number of currently deployed devices communicate in an unattended manner. The nature of the communication links varies to such an extent that only protocols from the Internet protocol family can glue them all together in a meaningful manner. Consequently, auto-configuration mechanisms of network parameters play a role of paramount importance in building these IP networks as illustrated in Figure 2.

Figure 2. Overall view of the functional elements involved in the process of network parameters configuration. The DHCPv6 server and relay are in the operator domain, while the machine-to-machine (M2M) gateway (mobile router) along with the attached devices are in the user domain.

Figure 2. Overall view of the functional elements involved in the process of network parameters configuration. The DHCPv6 server and relay are in the operator domain, while the machine-to-machine (M2M) gateway (mobile router) along with the attached devices are in the user domain.

3.1. Basic IP Parameters

Several mechanisms exist for the auto-configuration of basic IP parameters (address, mask, default route) for a device. A rough classification groups them depending on their capacity to maintain a state related to the parameters assigned to a device. For example, DHCPv6 protocol falls within a stateful group, since it maintains an address assigned to a device, at a specific DHCPv6 server. The alternative stateless group does not maintain such a state: a router provides a prefix to the device to form an address without further assistance from other entities.

The vehicular eHealth scenario considers IP devices deployed in a vehicle equipped with a gateway offering long-range connectivity. In such a scenario, auto-configuration mechanisms are needed: the gateway needs not only one address for itself, but a set of addresses for the IP eHealth devices. The mechanisms to achieve such auto-configuration are named prefix delegation. This is an extension to the DHCPv6 protocol [27]. In addition to the typical functionality of DHCPv6 to assign an IP address, this extension allows the assignment of a set of prefixes to a client. The DHCPv6 protocol is specified to work with relay and server entities as described in this recent reference [28].

Prefix delegation for network mobility [29] is a specification of the behavior for the existing DHCPv6 prefix delegation in the context of network mobility. Network mobility (NEMO) is an extension to the mobile IP protocol to support groups of devices moving together; such a group can be understood as a capillary network and/or as a vehicular network. This particular prefix delegation mechanism specifies the roles of the requesting router (mobile router) and of delegating router (home agent), as well as the placement of the DHCPv6 relay (mobile router).

3.2. Routing

In addition to assigning addresses to IP eHealth devices in a vehicular network, routing must be set up. Identifying and configuring routes in a system comprising a huge number of devices may quickly become a communication- and computation-intensive task, overcoming the capacity of the existing Internet. The concept of default route (the route to be chosen from a routing table when no other route is matching a destination address) provides partial resolution to this problem; it is sufficient for the gateway to hold a single default route (the IP address of the next hop) instead of numerous routes towards too many specific destinations. Default route auto-configuration mechanisms exist basically under two distinct forms. The first is router advertisement (RA)-based (the use of stateless address auto-configuration), and the second is a dynamic routing protocol, such as OSPF [30]. Currently, these two mechanisms are the only Internet Engineering Task Force (IETF) mechanisms to assign a default route to an end node.

Devices with limited CPU and memory capacities can benefit from the sole presence of a default route in their routing tables: it is sufficient to store only the default route in order to be able to reach any other node on the Internet. This is especially advantageous for machine-type communications.

Whereas stateless address auto-configuration offers a default route to an end device, it does not offer a set of prefixes. Similarly, the prefix delegation part of the stateful address auto-configuration does offer a set of addresses to the gateway (in order to further deliver them to the IP eHealth devices), but does not offer a default route.

For a limited capacity device (a constrained vehicular gateway or a constrained eHealth device), it is advantageous to use a lightweight auto-configuration protocol offering both parameters:

• an IPv6 route to be used as a default route in the routing table of the gateway.
• a set of IPv6 addresses (addresses or prefixes) to be used for address auto-configuration on the IP eHealth devices on board the vehicle.

4. Platform Overview

The platform described in this paper integrates a vehicular setting with eHealth technology using next-generation IPv6 communication protocols. This section describes the functional elements and roles of the components involved in our platform.

Figure 3 depicts the overall platform architecture of the integrated testbed. The system includes four functional elements and two types of interactions (short- and long-range).

Figure 3. Platform overview. First step of the testbed integration.

Figure 3. Platform overview. First step of the testbed integration.

From left to right, these functional elements are:

• The eHealth device provides real time health-related measurements. These measurements can be of a different nature, such as blood glucose levels or oxygen saturation levels. These M2M devices are provided with Bluetooth technology to send recorded data to another authorized peer.
• The cluster head is in the middle of two different communication technologies. On the one hand, short-range Bluetooth technology is used to communicate with M2M Devices and capture the eHealth data. On the other hand, short-range WiFi technology is used to send secure IPv6 packets to the server via the gateway. The cluster head allows us to process the gathered data before sending it to the server along with user comments, which is not possible with a standalone gateway.
• The mobile router provides IPv6 connectivity to in-vehicle devices and a default-route towards the server on the Internet. The gateway uses WiFi to advertise the internal IPv6 prefix to the attached nodes. For long-range communication technology (the path towards the server), only LTE provides a full IPv6 path from end to end. The MR has a powerful CPU and provides some resources demanding networking applications (using cellular interface), which are not available to run on a limited battery power device, like a smartphone.
• The application server collects the data from patients and provides a web interface for doctors to support diagnostics. The software running on the server includes a web server accessed over a secure connection (SSL) and a limited-access database server to gather the data by patients. A Java applet is required to view electrocardiography (ECG) graphs on the doctor’s screen.

Vehicular networking and eHealth technologies are combined (Figure 4) in the form of an ambulance equipped with special telemedicine devices that can record and transmit the patient’s vital signs (body temperature, pulse rate, respiration rate, blood pressure) and critical physiological parameters (ECG, blood glucose levels, oxygen saturation levels) to the nearest hospital in order for the resident health professionals to optimally prepare the patient’s admittance.

Figure 4. eHealth mobile operational scenario. Vital signs recorded by the patient are sent to the expert for diagnosis.

Figure 4. eHealth mobile operational scenario. Vital signs recorded by the patient are sent to the expert for diagnosis.

Assuming a road accident where a serious trauma should be taken into consideration, the ambulance crew has in its disposition a set of handheld lightweight devices that can transfer emergency data to the hospital. The objective in such a situation is to maximize clinical value through a limited set of measurements. All involved devices communicate via Bluetooth to an Android smart phone (cluster head) providing IPv6 connectivity. Figure 5 summarizes the end-to-end message exchange performed during normal use of the platform. The next section describes the gateway configuration phase that does not appear on the latter message exchange.

Figure 5. End to end message exchange diagram. Once the eHealth device is paired to the cluster head (and recognized by the application), the cluster head can be attached to the mobile router and obtain his configuration. The validity of this configuration is assured by the mobile router lightweight configuration protocol presented in Section 5. The cluster head registers at the electronic health record (EHR) and transmit eHealth-related data over TCP/SSL.

Figure 5. End to end message exchange diagram. Once the eHealth device is paired to the cluster head (and recognized by the application), the cluster head can be attached to the mobile router and obtain his configuration. The validity of this configuration is assured by the mobile router lightweight configuration protocol presented in Section 5. The cluster head registers at the electronic health record (EHR) and transmit eHealth-related data over TCP/SSL.

5. Auto-Configuration Protocol

As exposed in Section 3, our auto-configuration protocol is lightweight and provides IP addresses to the eHealth devices (via prefix delegation), as well as a default route to the gateway deployed in the vehicle. The protocol is based on DHCPv6, as illustrated in Figure 6. This protocol takes place on the MR before the cluster head attaches to it. Further details about the protocol are documented in [32].

Figure 6. Auto-configuration protocol messages. A comparison of the number of messages between current auto-configuration methods and the proposed one. DR stands for Default Route, P for prefix and ORO for option request option.

Figure 6. Auto-configuration protocol messages. A comparison of the number of messages between current auto-configuration methods and the proposed one. DR stands for Default Route, P for prefix and ORO for option request option.

Figure 6 describes the extended message exchange performed by the vehicular gateway and the DHCPv6 entities in the infrastructure. In the original DHCPv6 protocol, to obtain a set of addresses and a default route, 10 messages are necessary (including neighbor discovery messages). The initial RS (router solicitation)/RA (router advertisement) offer the default route, whereas the subsequent DHCPv6 solicit/advertize/request/reply offers the set of addresses to the gateway (to advertise for the eHealth devices).

Our proposal is based on DHCPv6 messages only and provides the default route in addition to a distinct set of IPv6 addresses. As depicted in Figure 6, the total number of messages in the earlier exchange (gateway-infrastructure) is reduced from 10 to eight. Eventually, (2*RTT) configuration time is saved. The actual duration depends on the cellular link quality. In our laboratory setting, the round trip time (RTT) for an experimental IPv6 3G deployment (further details within Section 6.2) varies between 300–500 ms.

In a solicit/request packet, a client lists the wanted options in the option request option (ORO), composed of a list of option codes. The DHCPv6 Server answers those packets with advertise/reply packets containing values for the options asked for by the client. The relay receives the message from the client (if the server is more than one hop away) and forwards it to the server in a relay-forward message. The server replies to the relay with an advertise/reply message encapsulated in a relay-reply message. The content of this message is extracted by the relay and sent to the client.

In its DHCPv6 requests, the client sends a list of required options within the ORO option. This option contains three mandatory fields: OPTION_ORO, option-len and requested-option-code, followed by new option fields. The proposed option is named here OPTION_DEFAULT_ROUTER_LIST. It is possible to concatenate this value with several other existing requested-option-codes. The value of this code in this option is to be assigned. Obviously, this option needs to be understood by the server, as well.

On the server side, the default router list option of DHCPv6 (Figure 7) contains: OPTION_DEFAULT_ROUTER_LIST, option-len, router-address, router-lifetime, lla_len (link-layer address length) and, optionally, router_link_layer_address. As this option contains a list, the pattern containing router_address, router_lifetime, lla_len and optionally router_link_layer_address can be repeated.

Figure 7. DHCPv6 default router list option fields. This option is used by the server to answer option request option (ORO) option sent by the client.

Figure 7. DHCPv6 default router list option fields. This option is used by the server to answer option request option (ORO) option sent by the client.

6. Prototype Implementation and Evaluation

This section describes the testbed integration performed as part of the FP7 EXALTED project (Expanding LTE for Devices) [31] to demonstrate the capability to disseminate eHealth specific data on the next-generation Internet from a vehicular setting. The underlying network communication protocols used were relying exclusively on IPv6 as the next generation of Internet protocols. The application layer protocols included, but were not limited to, HTTP and HTTPS.

6.1. Hardware Specifications

The Kerlink Wirma Road (Figure 8) is an energy-efficient ARM926EJ-S platform provided with a 2.6.27 Linux kernel. The ARM926EJ-S processor is one of the most popular ARM processors. The MR includes some M2M services and provides several communication capabilities. An integrated chipset provides GSM/GPRS cellular network service. An integrated WiFi module provides IEEE 802.11b/g connection. An integrated GPS module provides accurate geographic coordinates. GPRS, WiFi and GPS antennas are unified in one vehicle roof antenna. Unfortunately, no 3G support was natively implemented, so an additional USB-modem has to be plugged in for this end. According to the manufacturer, 10% of the regional bus companies in Paris (France) are equipped with this gateway.

Figure 8. Kerlink Wirma Road gateway.

Figure 8. Kerlink Wirma Road gateway.

For testbed purposes, an additional NETGEAR access point (AP) is plugged into the MR with a USB-Ethernet converter. Its purpose is to ease mobile phone attachment to the network advertised by the AP (Extended Service Set Identification (ESSID) “EXALTED”, WEP Key).

The eHealth devices (Figure 9) used for the testbed are manufactured by CardGuard [33]. The oxygen saturation level is measured by OxyPro, a wireless pulse oximeter. It provides for real time measurements and can be operated in continuous mode. It also provides pulse monitoring. It displays oxygen saturation and pulse rate averages with the absolute maximum and minimum measurements.

The blood glucose and pressure measurement is performed by an Easy2Check device. Blood glucose is measured with the use of an amperometric biosensor, where fresh capillary blood is deposited. Its accuracy ranges from ±15 mg/dL, when glucose <75 mg/dL, to ±20%, when glucose >75 mg/dL. Accordingly, for the pressure measurements, the accuracy is ±3 mmHg or ±2% of reading.

Self-check ECG offers one to 12 leads ECG event monitoring. It is intended for monitoring symptoms that may suggest abnormal heart function: skipped beats, palpitations, racing heart, irregular pulse, faintness, lightheadedness or a history of arrhythmia. The recording period is set at 32 s, while the bandwidth is 0.05–35 Hz for the 12 leads and 0.4–35 Hz for the one lead.

Spiro Pro is a spirometer that records volume (time and volume) flow curves according to international performance standards. It measures lung ventilatory functions during forced vital capacity (FVC) tests. The recording lasts for 17 s, and its accuracy for the FVC and FEV 1 is +5% or +0.1 L. It is mostly used for asthma or COPD monitoring.

Figure 9. Vidavo eHealth devices.

Figure 9. Vidavo eHealth devices.

A medical application is installed on an Android smartphone (IPv6-capable), which receives the vital signs from the portable monitoring devices via Bluetooth. The recorded data from the devices have to be transferred to a designated web center. The application provides a simple electronic health record (EHR) for disease management and treatment and initiates patients’ active involvement in healthcare. Analytically, it features browsing on the exam history, viewing of the recorded data, downloading of a diagnosis or advice from a doctor, comments addition and more. The final destination of these data is the EHR of the patient. This data is hosted in a dedicated server from where it is accessible for reviewing under secure credentials by the treating physicians.

6.2. System Evaluation

Although the experimentation was performed in a laboratory setting, the hardware equipment is deployable in a vehicle as is: Kerlink’s Wirma Road (IPv6 Gateway) is a low-consumption PC platform dedicated to vehicles, whereas eHealth devices are used by professionals of health for periodic check-up and continuous monitoring. The IPv6 kernel support and its associated protocol extensions are implemented in the gateway (not off-the-shelf technology).

In the joint testbed, the MR runs router advertisement daemon (radvd), version 1.8.5, compiled for ARM platforms and available for Debian distributions [34]. The radvd is configured to advertise at regular intervals or immediately on solicitations, two different prefixes for two different interfaces. On the air interface (AP), which is bridged to the MR, the 2001:DB8:B:2::/64 prefix is advertised for the devices, which connect to the “EXALTED” ESSID. This is the ingress interface of the MR. On the Ethernet side, the 2001:DB8:A:1::/64 prefix is announced for the connected devices. This is the egress interface of the MR. The server is connected on this side of the MR, and the traffic is routed through the gateway from one end to the other. These devices form the basis of what will be deployed in a vehicle, such as an ambulance. Figure 10 shows a snapshot of the eHealth sub-testbed of our platform and Figure 11 shows the detail of the network configuration obtained on the cluster head once connected to the mobile router.

Figure 10. eHealth testbed snapshot. On the left, the Android cluster head of our setting running the Vida24 eHealth application that collects measurements from the oximeter device (on the right). Multiple devices can be paired and monitored, for example, the Spirometer device on the top of the figure.

Figure 10. eHealth testbed snapshot. On the left, the Android cluster head of our setting running the Vida24 eHealth application that collects measurements from the oximeter device (on the right). Multiple devices can be paired and monitored, for example, the Spirometer device on the top of the figure.

Figure 11. Android Cluster Head connected to the MR. The Request for Comments (RFC) 4941 privacy extension IPv6 addresses are used to issue connections towards the personal health record (PHR). This is a privacy-related precaution completed by the use of a secure SSL connection on the application layer.

Figure 11. Android Cluster Head connected to the MR. The Request for Comments (RFC) 4941 privacy extension IPv6 addresses are used to issue connections towards the personal health record (PHR). This is a privacy-related precaution completed by the use of a secure SSL connection on the application layer.

In an effort to evaluate the throughput expected on the 3G uplink (infrastructure access) of the mobile router, we performed a comparison using two different services on the cellular interface. The graphic in Figure 12 shows the throughput for the 3G high speed uplink packet access (HSUPA, LTE-Release 6) infrastructure link in two conditions: enterprise public IPv4 access point name (APN) connection and an experimental IPv6 APN. Of course, IP version does not determine the obtained throughput, but the quality of the cellular deployment does (in particular, the provision for adequate quality of service).

Figure 12A shows a throughput measure performed using a public Enterprise IPv4 APN. From the server perspective, the throughput is measured for a total amount of 15.6 Mb data received over a period of 64.1 s, which sets the overall throughput to 2.04 Mbits/sec (that is an average of 0.255 Mb/s).

Figure 12B shows the throughput measured over an experimental IPv6 APN specially deployed for our V2I experiments. From the server perspective, a total amount of 17.4 Mb data over 60.6 s is received, which sets the overall throughput to 2.40 Mbits/sec (that is, an average of 0.3 Mb/s).

This highlights the delay and throughput performance of the experimental IPv6 APN (not public), which are equivalent to those of a public IPv4 APN regarding these criteria. This also demonstrates the feasibility of IPv6 end-to-end communications over the already deployed technologies (3G+).

Figure 12. Throughput comparison (testbed conditions) on the mobile router using public IPv4 and experimental IPv6 high-speed downlink packet access (HSDPA) (3G+) APN. Both deployments provided by Orange France.

Figure 12. Throughput comparison (testbed conditions) on the mobile router using public IPv4 and experimental IPv6 high-speed downlink packet access (HSDPA) (3G+) APN. Both deployments provided by Orange France.

The server, which is located on the Internet side (Egress interface), configures an IPv6 addresses on the 2001:DB8:A:1::/64 prefix. The server is then ready to receive the data. The server application runs over Java (tomcat webserver) and includes a MySQL database, where the collected data is stored and organized per user ID. The physician can then issue a remote access to the server in order to observe the data as depicted in Figure 4. In order to observe these measurements (path from the viewer to the server), IPv4 and IPv6 access to the application server are possible.

The energy spent on sending a message from an eHealth end device through the Android cluster head has been measured using the Vida24 application (client application) on an Android 2.3-Gingerbread phone. The results show an average smartphone energy consumption at a minimum usage of 5% energy consumed per hour. The eHealth end device (oximeter, for instance) consumes 60 mW in a typical operating mode (off-the-shelf, manufacturer default configuration). Figure 11 shows the IPv6 configuration of the Android phone in a typical setting behind the mobile router [21].

7. Conclusions

The infrastructure of the Internet is continuously evolving to support new services. Intelligent transportation systems will play a fundamental role in the future, helping to preserve lives and making transportation safer and efficient. eHealth, if supported by vehicular networks, could be one of the applications improving vehicle passengers’ safety.

This paper describes the integration process of vehicular and eHealth testbeds. The vehicular network is designed to work over a fully deployed IPv6 network. eHealth testbed collects, stores and sends health-related measurements to a PHR server located in the infrastructure, where the results can be viewed remotely by a doctor. Performed experimentation demonstrates the capability of eHealth specific data to be sent on IPv6 from a vehicular setting using an experimental IPv6 deployment over high-speed packet access (HSPA) (3G+). The underlying network communication protocols used were relying exclusively on IPv6. The application layer protocols included, but were not limited to, HTTP and HTTPS. The hardware used in this configuration is deployable, as is, in a vehicle.

In the future, two scenarios are possible based on the availability of LTE coverage. Live demonstrations can be done thanks to LTE’s IPv6 support [13] when deployed by the operators. In the meantime, in-vehicle demonstrations are possible over existing IPv4 3G networks thanks to encapsulating and decapsulating gateways on the edges of the link for network traversal.