Integration of a Mobile Node into a Hybrid Wireless Sensor Network for Urban Environments

Robots, or in general, intelligent vehicles, require large amounts of data to adapt their behavior to the environment and achieve their goals. When their missions take place in large areas, using additional information to that gathered by the onboard sensors frequently offers a more efficient solution of the problem. The emergence of Cyber-Physical Systems and Cloud computing allows this approach, but integration of sensory information, and its effective availability for the robots or vehicles is challenging. This paper addresses the development and implementation of a modular mobile node of a Wireless Sensor Network (WSN), designed to be mounted onboard vehicles, and capable of using different sensors according to mission needs. The mobile node is integrated with an existing static network, transforming it into a Hybrid Wireless Sensor Network (H-WSN), and adding flexibility and range to it. The integration is achieved without the need for multi-hop routing. A database holds the data acquired by both mobile and static nodes, allowing access in real-time to the gathered information. A Human–Machine Interface (HMI) presents this information to users. Finally, the system is tested in real urban scenarios in a use-case of measurement of gas levels.


Introduction
Wireless sensor networks (WSNs) allow for the acquisition of information when proximity from the sensors to the phenomenon and persistence over time is required [1,2]. WSNs have been applied to problems like logistics, traceability, emergency operations or urban environments [3][4][5][6][7]. In emergency response, WSNs can provide close monitoring with low cost, flexibility and scalability [8,9], as well as way of integrating robot into rescue teams [10], as a step towards Cyber-Physical Systems (CPS) for first response [11][12][13]. In urban environments, WSNs can help monitoring power systems, solid waste or water facilities [14]. But traffic has attracted most of attention, since it is generally considered as one of the main problems affecting the health of city population [15]. The number of vehicles has grown notably in recent decades; as has pollution [16]. Pollution data are usually measured using an infrastructure of fixed sites. Such an infrastructure is limited, expensive and static. As a result, pollution and air quality data are limited [17,18]. WSNs, on the contrary, are flexible and dynamic, and can be easily adapted to rural or urban environments. These features have made WSNs a valuable The system is based on a static wireless sensor network developed for urban applications, called Urban Information System (UIS) [7]. The UIS has a modular architecture to adapt the system configuration to the needs of the area of interest. Two different types of nodes were originally developed: Transmitter nodes and Receiver nodes. The basic configuration of the UIS platform comprises several Transmitter nodes and at least one Receiver node. The Transmitter nodes collect urban environment information such as Bluetooth MACs, number of vehicles crossing the ultrasound beam, gases concentration like NO x , CO, CO 2 , O 2 , NH 3 , VOC, light intensity, noise or dust. The UIS can be deployed with a different number of Transmitter nodes [58]. The Receiver node configures and manages the UIS network. Once the network has been set up, the Transmitter nodes carry out the data acquisition and processing. Then the data are sent to the Receiver node, where an internal database is updated and synchronized with the database in an external server (see Figure 1). A graphical Human-Machine Interface (HMI) presents data from the database related to their geographic position. A solar kit can be installed in all the nodes so that they can be independent from the electric power grid, and autonomous from an energy point of view. This way, deployment of the nodes gain flexibility.
The flexibility in the deployment is one of the advantages of WSNs compared with fixed infrastructure. Sensors can be positioned easily and in short time, but they can also be distributed to study a particular phenomenon. For instance, in the case of UIS, nodes can be deployed to estimate the origin-destination matrix (O-D matrix) for a particular set of points [17]. This matrix represents the number of vehicles going from origin i to destination j. To estimate this number, a relevant sample of the vehicles traveling from i to j has to be identified. The proposed UIS does so by positioning Bluetooth nodes nearby the points of interest [7]. These nodes collect the MAC address of Bluetooth devices within their range, and transmit them to the Receiver node. All this information is synchronized with the database in the server, and then the O-D matrix is estimated, given that the location of the Bluetooth nodes is known [23]. Thus, freedom to select the points where the transmitter nodes are deployed is key for this feature to be useful for traffic managers.

Implementation
The proposed system has been developed on the basis of hardware components provided by Libelium (Zaragona, Spain) [59]. The transmitter nodes share a basic module, called Waspmote V. 1.2 (Libelium, Zaragoza, Spain) The addition of an XBee Pro S2 communications module (Digi, Minnetonka, MN, U.S.A.) provides the capability of using protocols like ZigBee or DigiMesh. The Receiver node is based on a multiprotocol router named Meshlium, also from Libelium, configured to work with ZigBee, WiFi, Bluetooth, and 3G/GPRS protocols, and including a GPS. The link between the Transmitter nodes and the Receiver node has been implemented using the ZigBee protocol (2.4 GHz). It can transmit small information packages with a range of over 700 meters (depending on visibility conditions). Network setup is fast and simple, and so is adding new nodes.
As mentioned above, several Transmitter nodes have been developed, including different sensors. This way, a UIS deployment can include the following types of nodes:

Implementation
The proposed system has been developed on the basis of hardware components provided by Libelium (Zaragona, Spain) [59]. The transmitter nodes share a basic module, called Waspmote V. 1.2 (Libelium, Zaragoza, Spain) The addition of an XBee Pro S2 communications module (Digi, Minnetonka, MN, U.S.A.) provides the capability of using protocols like ZigBee or DigiMesh. The Receiver node is based on a multiprotocol router named Meshlium, also from Libelium, configured to work with ZigBee, WiFi, Bluetooth, and 3G/GPRS protocols, and including a GPS. The link between the Transmitter nodes and the Receiver node has been implemented using the ZigBee protocol (2.4 GHz). It can transmit small information packages with a range of over 700 meters (depending on visibility conditions). Network setup is fast and simple, and so is adding new nodes.
As mentioned above, several Transmitter nodes have been developed, including different sensors. This way, a UIS deployment can include the following types of nodes: All transmitter nodes are mounted in IP 67 boxes, so that the system can be deployed outdoors in adverse weather condition. Figure 2 shows different nodes of the UIS platform.
All transmitter nodes are mounted in IP 67 boxes, so that the system can be deployed outdoors in adverse weather condition. Figure 2 shows different nodes of the UIS platform.
The information gathered from the area of interest is sent to the Receiver node, and stored as tables in its internal database. These tables are synchronized with a relational database implemented with MySQL v.7.0 (Oracle, Redwood City, CA, U.S.A.) in an external server. Synchronization is performed via 3G communication, or Wi-Fi if it is available. This database is the input for an HMI developed for this application using LabVIEW, v. 2015 (National Instruments, Austin, TX, U.S.A.), where the information acquired by the sensors is displayed according to their geographic location. The HMI synchronizes with the external database through a connection string using ODBC v. 13.1 (Microsoft, Redmond, WA, U.S.A.). A more detailed review of the UIS can be found at [7].

Mobile Node
As seen in Section 1, WSN are a solution for acquiring information close to the area of interest with persistence over time. However, a successful application requires attention to network coverage, connectivity or network overhead. Hybrid wireless sensor networks can provide a solution to some of these challenges. This section presents a mobile node architecture and implementation, and its integration with a static WSN to obtain an H-WSN.

Overview
The UIS is a static WSN. As such, it provides useful information on an area of interest, since it can be deployed with speed and flexibility to adapt to each case requirements. But once the network is deployed, the nodes stay at the same location. Obtaining additional information requires installing supplementary Transmitter nodes, and depending on the distance, also Receiver nodes, due to the limited range of ZigBee communications. Some use-cases require a different approach, such as the study of gas emissions. A significant amount of emissions in urban areas is linked to motor vehicles. Obtaining up-to-date information about the levels of some gases can be very relevant for traffic managers. But deploying a sensor network large enough to cover a whole city might be impractical. A way of obtaining the relevant data that traffic managers require is by means of sensors directly The information gathered from the area of interest is sent to the Receiver node, and stored as tables in its internal database. These tables are synchronized with a relational database implemented with MySQL v.7.0 (Oracle, Redwood City, CA, U.S.A.) in an external server. Synchronization is performed via 3G communication, or Wi-Fi if it is available. This database is the input for an HMI developed for this application using LabVIEW, v. 2015 (National Instruments, Austin, TX, U.S.A.), where the information acquired by the sensors is displayed according to their geographic location. The HMI synchronizes with the external database through a connection string using ODBC v. 13.1 (Microsoft, Redmond, WA, U.S.A.). A more detailed review of the UIS can be found at [7].

Mobile Node
As seen in Section 1, WSN are a solution for acquiring information close to the area of interest with persistence over time. However, a successful application requires attention to network coverage, connectivity or network overhead. Hybrid wireless sensor networks can provide a solution to some of these challenges. This section presents a mobile node architecture and implementation, and its integration with a static WSN to obtain an H-WSN.

Overview
The UIS is a static WSN. As such, it provides useful information on an area of interest, since it can be deployed with speed and flexibility to adapt to each case requirements. But once the network is deployed, the nodes stay at the same location. Obtaining additional information requires installing supplementary Transmitter nodes, and depending on the distance, also Receiver nodes, due to the limited range of ZigBee communications. Some use-cases require a different approach, such as the study of gas emissions. A significant amount of emissions in urban areas is linked to motor vehicles. Obtaining up-to-date information about the levels of some gases can be very relevant for traffic managers. But deploying a sensor network large enough to cover a whole city might be impractical. A way of obtaining the relevant data that traffic managers require is by means of sensors directly installed on vehicles. But some other applications require also the capability to measure environmental data in an adaptable fast way, such as in disaster robotics, where the collaboration with humans or dogs can be limited by the level of some gases. For those applications requiring additional flexibility in the acquisition of information, a hybrid version of the UIS network has been developed.
These features can be achieved by transforming the static WSN into a H-WSN by adding a Mobile node. The next sections describe the Mobile node architecture and implementation, and its integration with the WSN.

Architecture and Implementation
The Mobile node has been developed to improve the range and flexibility of the UIS. It has been designed to allow installation onboard vehicles, so the area under study can be modified without the need to re-deploy the UIS nodes. A modular architecture was desirable so that the set of sensors could be modified according to mission needs. At the same time, one of the requirements was to use the original nodes with as few modifications as possible. But since the Transmitter nodes send their data using the ZigBee protocol, they have a limited range, which is affected by the obstacles between emitter and receiver. To overcome this limitation, one possibility is to configure ZigBee nodes as routers, allowing multi-hop routing to take the data from the Transmitter nodes to the Receiver node. However, this option limits the flexibility of a mobile node, since it could only move around the position of already deployed nodes. To meet all the requirements a modular architecture was designed including a Receiver node and a configurable number of standard UIS Transmitter nodes, so that no hardware changes are required. The Receiver node gathers the information from the Transmitter nodes, and synchronizes it with the database in the external server via 3G or Wi-Fi (see Figure 3). In this way, the Mobile node can acquire data from areas without the need for previously deployed ZigBee nodes between the Receiver node and the area of interest. installed on vehicles. But some other applications require also the capability to measure environmental data in an adaptable fast way, such as in disaster robotics, where the collaboration with humans or dogs can be limited by the level of some gases. For those applications requiring additional flexibility in the acquisition of information, a hybrid version of the UIS network has been developed. These features can be achieved by transforming the static WSN into a H-WSN by adding a Mobile node. The next sections describe the Mobile node architecture and implementation, and its integration with the WSN.

Architecture and Implementation
The Mobile node has been developed to improve the range and flexibility of the UIS. It has been designed to allow installation onboard vehicles, so the area under study can be modified without the need to re-deploy the UIS nodes. A modular architecture was desirable so that the set of sensors could be modified according to mission needs. At the same time, one of the requirements was to use the original nodes with as few modifications as possible. But since the Transmitter nodes send their data using the ZigBee protocol, they have a limited range, which is affected by the obstacles between emitter and receiver. To overcome this limitation, one possibility is to configure ZigBee nodes as routers, allowing multi-hop routing to take the data from the Transmitter nodes to the Receiver node. However, this option limits the flexibility of a mobile node, since it could only move around the position of already deployed nodes. To meet all the requirements a modular architecture was designed including a Receiver node and a configurable number of standard UIS Transmitter nodes, so that no hardware changes are required. The Receiver node gathers the information from the Transmitter nodes, and synchronizes it with the database in the external server via 3G or Wi-Fi (see Figure 3). In this way, the Mobile node can acquire data from areas without the need for previously deployed ZigBee nodes between the Receiver node and the area of interest. An example set of nodes included in the Mobile node is shown in Figure 3. In this case, a Gas node and an Environmental node are included as the Transmitter nodes, together with the Receiver node. It is worth notice that Transmitter nodes may contain several sensors, which can be changed from one experiment to another depending on the mission requirements. For instance, the Gas node can be equipped with different sets of gas sensors, including CO2, CO, O2, VOC or NH3.
The Mobile node has two possible working modes: local mode and networked mode. In both modes, the Transmitter nodes acquire and process data from the environment, and send them to the embarked Receiver node. The modes differ in the way that a frame is constructed prior to store it in the local table, and to synchronize it with the external database. The implementation had to meet the requirement of using the original nodes with as few modifications as possible. Thus, changes have An example set of nodes included in the Mobile node is shown in Figure 3. In this case, a Gas node and an Environmental node are included as the Transmitter nodes, together with the Receiver node. It is worth notice that Transmitter nodes may contain several sensors, which can be changed from one experiment to another depending on the mission requirements. For instance, the Gas node can be equipped with different sets of gas sensors, including CO 2 , CO, O 2 , VOC or NH 3 .
The Mobile node has two possible working modes: local mode and networked mode. In both modes, the Transmitter nodes acquire and process data from the environment, and send them to the embarked Receiver node. The modes differ in the way that a frame is constructed prior to store it in the local table, and to synchronize it with the external database. The implementation had to meet the requirement of using the original nodes with as few modifications as possible. Thus, changes have been limited to the Receiver node software. These modifications have consisted in the creation of two additional software configurations according to the two different working modes. This software configuration has to be selected offline, previously to the start of an experiment. Thus, it is possible to increase the communication range of the existing sensor nodes without the need for integration of a new radio segment with the Transmitter nodes, or the development of new connection strings with the external server according to this new communication link. At the same time, it is possible to use any type of Transmitter node already in use by the static network.
Both working modes use the same frame structure. Within the different frame types for the ZigBee protocol, an ASCII frame structure has been selected. The frame structure is shown in Figure 4 Sensor_i: Specific field of each sensor including an identifying label and the data that it provides. Its length can be variable. been limited to the Receiver node software. These modifications have consisted in the creation of two additional software configurations according to the two different working modes. This software configuration has to be selected offline, previously to the start of an experiment. Thus, it is possible to increase the communication range of the existing sensor nodes without the need for integration of a new radio segment with the Transmitter nodes, or the development of new connection strings with the external server according to this new communication link. At the same time, it is possible to use any type of Transmitter node already in use by the static network. Both working modes use the same frame structure. Within the different frame types for the ZigBee protocol, an ASCII frame structure has been selected. The frame structure is shown in Figure  4, where: Sensor_i: Specific field of each sensor including an identifying label and the data that it provides. Its length can be variable.

Local Mode
In this mode, the Mobile node is seen by the network as a single, multi-sensor node. To do so, an enhanced frame is constructed containing the information from all the sensors present in the Transmitter nodes within the Mobile node.
Once data from all the sensors have been received, the Receiver node builds an enhanced frame with data from all of them, includes location data and updates the internal database. Synchronization is then performed with the external database (via 3G or Wi-Fi, if available), where the information appears as data from a single node. A simplified protocol message flow diagram for this working mode is shown in Figure 5. Figure 6 shows an example of part of an enhanced frame built integrating information from different Transmitter nodes. In this case, a Gas node including several gas sensors is installed. Location data are included by the Receiver node in an additional sensor field.
The local mode limits the communications, but only in the 3G/Wi-Fi segment. Thus, the number of data available at the external database is reduced: since a frame is updated in the database only when all Transmitter nodes have sent their data, the dynamics of the data acquisition is as slow as the slowest sensor present. Transmitter nodes keep their own pace sending their data to the Receiver node, but only the most recent data from every sensor are used to construct the enhanced frame. Depending of the types of nodes, real-time presentation of the data might be difficult to attain.

Local Mode
In this mode, the Mobile node is seen by the network as a single, multi-sensor node. To do so, an enhanced frame is constructed containing the information from all the sensors present in the Transmitter nodes within the Mobile node.
Once data from all the sensors have been received, the Receiver node builds an enhanced frame with data from all of them, includes location data and updates the internal database. Synchronization is then performed with the external database (via 3G or Wi-Fi, if available), where the information appears as data from a single node. A simplified protocol message flow diagram for this working mode is shown in Figure 5. Figure 6 shows an example of part of an enhanced frame built integrating information from different Transmitter nodes. In this case, a Gas node including several gas sensors is installed. Location data are included by the Receiver node in an additional sensor field.
The local mode limits the communications, but only in the 3G/Wi-Fi segment. Thus, the number of data available at the external database is reduced: since a frame is updated in the database only when all Transmitter nodes have sent their data, the dynamics of the data acquisition is as slow as the slowest sensor present. Transmitter nodes keep their own pace sending their data to the Receiver node, but only the most recent data from every sensor are used to construct the enhanced frame. Depending of the types of nodes, real-time presentation of the data might be difficult to attain.

Networked mode
In the networked mode, when data from any of the Transmitter nodes are available, a frame is constructed and sent to the embarked Receiver node. A frame may contain information from one or several sensors from the same Transmitter node. The Receiver node updates its internal database, and then synchronization with the external database takes place via 3G, or Wi-Fi if it is available. A simplified protocol message flow diagram for this working mode is shown in Figure 7. Figure 8 shows examples of frames with data from a Gas node. In Figure 8a, the frame includes CO2 and O2 measurements. In Figure 8b, the frame contains measurements from three sensors: NH3, temperature and humidity. Location is obtained by means of a GPS node, acting as an additional Transmitter node. This way, more positioning data are available.

Networked mode
In the networked mode, when data from any of the Transmitter nodes are available, a frame is constructed and sent to the embarked Receiver node. A frame may contain information from one or several sensors from the same Transmitter node. The Receiver node updates its internal database, and then synchronization with the external database takes place via 3G, or Wi-Fi if it is available. A simplified protocol message flow diagram for this working mode is shown in Figure 7. Figure 8 shows examples of frames with data from a Gas node. In Figure 8a, the frame includes CO2 and O2 measurements. In Figure 8b, the frame contains measurements from three sensors: NH3, temperature and humidity. Location is obtained by means of a GPS node, acting as an additional Transmitter node. This way, more positioning data are available.

Networked Mode
In the networked mode, when data from any of the Transmitter nodes are available, a frame is constructed and sent to the embarked Receiver node. A frame may contain information from one or several sensors from the same Transmitter node. The Receiver node updates its internal database, and then synchronization with the external database takes place via 3G, or Wi-Fi if it is available. A simplified protocol message flow diagram for this working mode is shown in Figure 7. Figure 8 shows examples of frames with data from a Gas node. In Figure 8a, the frame includes CO 2 and O 2 measurements. In Figure 8b, the frame contains measurements from three sensors: NH 3 , temperature and humidity. Location is obtained by means of a GPS node, acting as an additional Transmitter node. This way, more positioning data are available.

Networked mode
In the networked mode, when data from any of the Transmitter nodes are available, a frame is constructed and sent to the embarked Receiver node. A frame may contain information from one or several sensors from the same Transmitter node. The Receiver node updates its internal database, and then synchronization with the external database takes place via 3G, or Wi-Fi if it is available. A simplified protocol message flow diagram for this working mode is shown in Figure 7. Figure 8 shows examples of frames with data from a Gas node. In Figure 8a, the frame includes CO2 and O2 measurements. In Figure 8b, the frame contains measurements from three sensors: NH3, temperature and humidity. Location is obtained by means of a GPS node, acting as an additional Transmitter node. This way, more positioning data are available.   This working mode makes available a larger amount of data, through a higher number of updates with the external database. Data are also available to the user faster, since the synchronization of the databases takes place as soon as new data are collected.

Integration with the H-WSN
The data acquired by the sensors on the Mobile node are available to any user through the database, like the data from any other sensor in the static network. The Wireless Sensor Network is then transformed into a Hybrid Wireless Sensor Network (H-WSN), managing data from both static and mobile nodes indifferently. Figure 9 shows the integration of the Mobile node (in the right-hand side) with a static WSN (in the left-hand side), resulting in a H-WSN. The Receiver node acts as a mobile sink, granting coverage for the Transmitter nodes whenever 3G or Wi-Fi coverage is available without the need for multi-hop routing or dynamic relocation methods, which can reduce operating lifetime of the nodes due to increased communication. By transforming the WSN into H-WSN the resulting system gains flexibility, since a Mobile node can be deployed to obtain data from an area not covered by static nodes (for instance, in cases where some pieces of evidence make the area worth studying after the original deployment of the network). Robustness can also be increased with the use of a Mobile node to substitute malfunctioning static nodes.  This working mode makes available a larger amount of data, through a higher number of updates with the external database. Data are also available to the user faster, since the synchronization of the databases takes place as soon as new data are collected.

Integration with the H-WSN
The data acquired by the sensors on the Mobile node are available to any user through the database, like the data from any other sensor in the static network. The Wireless Sensor Network is then transformed into a Hybrid Wireless Sensor Network (H-WSN), managing data from both static and mobile nodes indifferently. Figure 9 shows the integration of the Mobile node (in the right-hand side) with a static WSN (in the left-hand side), resulting in a H-WSN. The Receiver node acts as a mobile sink, granting coverage for the Transmitter nodes whenever 3G or Wi-Fi coverage is available without the need for multi-hop routing or dynamic relocation methods, which can reduce operating lifetime of the nodes due to increased communication. By transforming the WSN into H-WSN the resulting system gains flexibility, since a Mobile node can be deployed to obtain data from an area not covered by static nodes (for instance, in cases where some pieces of evidence make the area worth studying after the original deployment of the network). Robustness can also be increased with the use of a Mobile node to substitute malfunctioning static nodes. This working mode makes available a larger amount of data, through a higher number of updates with the external database. Data are also available to the user faster, since the synchronization of the databases takes place as soon as new data are collected.

Integration with the H-WSN
The data acquired by the sensors on the Mobile node are available to any user through the database, like the data from any other sensor in the static network. The Wireless Sensor Network is then transformed into a Hybrid Wireless Sensor Network (H-WSN), managing data from both static and mobile nodes indifferently. Figure 9 shows the integration of the Mobile node (in the right-hand side) with a static WSN (in the left-hand side), resulting in a H-WSN. The Receiver node acts as a mobile sink, granting coverage for the Transmitter nodes whenever 3G or Wi-Fi coverage is available without the need for multi-hop routing or dynamic relocation methods, which can reduce operating lifetime of the nodes due to increased communication. By transforming the WSN into H-WSN the resulting system gains flexibility, since a Mobile node can be deployed to obtain data from an area not covered by static nodes (for instance, in cases where some pieces of evidence make the area worth studying after the original deployment of the network). Robustness can also be increased with the use of a Mobile node to substitute malfunctioning static nodes.  The external database is the input for an HMI developed for this application using LabVIEW (see Figure 10), making possible to present the information obtained by the different sensors, and related to their locations. The user can configure what sensors' information is shown, according to the deployed nodes, including static nodes. For instance, Figure 10 shows how the user can see the available measurements for CO 2 , CO, O 2 , NH 3 , ozone (O 3 ), atmospheric pressure, relative humidity and temperature, at the beginning of a route.
The data gathered from the Transmitter nodes are presented to the user associated to their locations. In the case of the Mobile node this location is dynamic, but from the point of view of the WSN it is presented as another node. The HMI has been designed to be compatible with ruggedized tablets running Windows 7. This way, users can also move, either with the Mobile node, or on another vehicle. The external database is the input for an HMI developed for this application using LabVIEW (see Figure 10), making possible to present the information obtained by the different sensors, and related to their locations. The user can configure what sensors' information is shown, according to the deployed nodes, including static nodes. For instance, Figure 10 shows how the user can see the available measurements for CO2, CO, O2, NH3, ozone (O3), atmospheric pressure, relative humidity and temperature, at the beginning of a route.
The data gathered from the Transmitter nodes are presented to the user associated to their locations. In the case of the Mobile node this location is dynamic, but from the point of view of the WSN it is presented as another node. The HMI has been designed to be compatible with ruggedized tablets running Windows 7. This way, users can also move, either with the Mobile node, or on another vehicle. The use-case in this article is based on measuring gas levels in an urban scenario, but some other applications are feasible. The Mobile node has been designed to accept as many types of Transmitter nodes as possible, without any modifications in hardware. The Mobile node provides an interface with the network, via an additional Receiver node, and power supply by using a battery bank. Although power supply by photovoltaic panels is still possible, depending on the application it might be unpractical. So far, only the Laser node is to be integrated in the mobile node. This flexibility in the configuration of the sensor suite allows for adaptation to other applications through the modification of the set of sensors and the selection of the platform to carry the Mobile node, allowing for collaborative efforts towards Cyber-Physical System integrating sensors, vehicles or humans. For instance, search and rescue applications present opportunities for this approach [60].

Experiments
A series of experiments has been designed to validate the concept of mobile node. This validation includes using different combinations of nodes and sensors. The experiments have been performed for the two working modes: local and networked. The mobile node was installed in the modified top carrier of a test vehicle. The selected test vehicle was an electric passenger car (Nissan Leaf, Yokohama, Japan) to prevent perturbation of gas and noise measurements (see Figure 11). The experiments consisted in a series of routes along the city of Malaga, in Spain. The Receiver node within the mobile node synchronized its internal database with the database in an external server. A The use-case in this article is based on measuring gas levels in an urban scenario, but some other applications are feasible. The Mobile node has been designed to accept as many types of Transmitter nodes as possible, without any modifications in hardware. The Mobile node provides an interface with the network, via an additional Receiver node, and power supply by using a battery bank. Although power supply by photovoltaic panels is still possible, depending on the application it might be unpractical. So far, only the Laser node is to be integrated in the mobile node. This flexibility in the configuration of the sensor suite allows for adaptation to other applications through the modification of the set of sensors and the selection of the platform to carry the Mobile node, allowing for collaborative efforts towards Cyber-Physical System integrating sensors, vehicles or humans. For instance, search and rescue applications present opportunities for this approach [60].

Experiments
A series of experiments has been designed to validate the concept of mobile node. This validation includes using different combinations of nodes and sensors. The experiments have been performed for the two working modes: local and networked. The mobile node was installed in the modified top carrier of a test vehicle. The selected test vehicle was an electric passenger car (Nissan Leaf, Yokohama, Japan) to prevent perturbation of gas and noise measurements (see Figure 11). The experiments consisted in a series of routes along the city of Malaga, in Spain. The Receiver node within the mobile node synchronized its internal database with the database in an external server. A graphical Human-Machine Interface (HMI), running on a laptop, allowed for monitoring in real-time the gathered data related to their geographic position. graphical Human-Machine Interface (HMI), running on a laptop, allowed for monitoring in real-time the gathered data related to their geographic position.

Experiments in Local Mode
In these experiments, the mobile node was configured around the Gas and EP nodes, including sensors for gas concentrations and environmental parameters, providing measurements for concentration of O2, CO2, VOC as well as temperature, humidity, dust, luminance, and noise. GPS data were obtained from the Receiver node.
The embedded Gas and EP nodes worked acquiring and processing the respective data and sent them to the embarked Receiver node. Once all sensors had provided data, a full set was completed adding localization via the Receiver node's GPS. The internal database was updated and synchronized with the external database at the server.
The experiments consisted in deploying the test vehicle along several routes in the city of Malaga. Figure 12 shows a screenshot of the HMI at the end of one of the routes in the city center. The followed path has been signaled with a red line. Numeric labels have been added to mark the locations where an enhanced frame was completed according to the local working mode. This particular experiment had a length of 5 km and took 47 minutes to be completed. Table 1 presents the gathered data for the route showed in Figure 12. The item number matches with the labels in the Figure mentioned before. In the local mode, an enhanced frame is constructed once data from all present nodes are acquired, annexing GPS data provided by the Receiver node. Thus, every row in this Table displays the data gathered up to that location. This strategy produces as many frames as the slowest installed sensor. In this particular experiment, the limits were imposed by the dynamics of the CO2 sensor. This can be noticed in Figure 12, where locations for frames 1 to 4 are closer than for frames 4 to 7, because the test vehicle could move at a slower velocity in the former, due to traffic jams. Preliminary results from this working mode were described in [58].

Experiments in Local Mode
In these experiments, the mobile node was configured around the Gas and EP nodes, including sensors for gas concentrations and environmental parameters, providing measurements for concentration of O 2 , CO 2 , VOC as well as temperature, humidity, dust, luminance, and noise. GPS data were obtained from the Receiver node.
The embedded Gas and EP nodes worked acquiring and processing the respective data and sent them to the embarked Receiver node. Once all sensors had provided data, a full set was completed adding localization via the Receiver node's GPS. The internal database was updated and synchronized with the external database at the server.
The experiments consisted in deploying the test vehicle along several routes in the city of Malaga. Figure 12 shows a screenshot of the HMI at the end of one of the routes in the city center. The followed path has been signaled with a red line. Numeric labels have been added to mark the locations where an enhanced frame was completed according to the local working mode. This particular experiment had a length of 5 km and took 47 minutes to be completed. Table 1 presents the gathered data for the route showed in Figure 12. The item number matches with the labels in the Figure mentioned before. In the local mode, an enhanced frame is constructed once data from all present nodes are acquired, annexing GPS data provided by the Receiver node. Thus, every row in this Table displays the data gathered up to that location. This strategy produces as many frames as the slowest installed sensor. In this particular experiment, the limits were imposed by the dynamics of the CO 2 sensor. This can be noticed in Figure 12, where locations for frames 1 to 4 are closer than for frames 4 to 7, because the test vehicle could move at a slower velocity in the former, due to traffic jams. Preliminary results from this working mode were described in [58].

Experiments in Networked Mode
In the experiments for the networked mode, the mobile node was configured to include the Gas and GPS nodes. The gas sensors for the former node were NH3, O2, CO2, VOC as well as temperature and humidity.
The Gas and GPS nodes acquired, processed and sent data to the embarked Receiver node according to their own dynamics. Upon data reception from any sensor, the Receiver node updated its internal database and synchronized it with the external database at the server. GPS data was treated as another sensor, updating the location in the database as soon as new data were received according to a programmed rate.
The experiments were designed to consider a greater diversity in the routes, including highways and longer distances. They were performed in the city of Malaga. Figure 13 presents a screenshot of the HMI showing the route of one of these experiments, as well as labels for selected locations. The path started at the campus of the University of Malaga (red square) and reached the eastern limit of the city (label 6) to finally go back to the campus. This route was performed in 1 hour and 24 minutes, for a total of 28.3 kilometers covering highways in the western part of the route (labels 1 and 2) as well as urban areas for the rest. Table 2 presents some of the data obtained by the mobile node together with the geo-located labels in the route marked in Figure 13. The measurements recorded by the different sensors were shown in real-time at the HMI, allowing the user to visualize a plot with the evolution of a certain sensor by selecting it in the interface. Figure 14

Experiments in Networked Mode
In the experiments for the networked mode, the mobile node was configured to include the Gas and GPS nodes. The gas sensors for the former node were NH 3 , O 2 , CO 2 , VOC as well as temperature and humidity.
The Gas and GPS nodes acquired, processed and sent data to the embarked Receiver node according to their own dynamics. Upon data reception from any sensor, the Receiver node updated its internal database and synchronized it with the external database at the server. GPS data was treated as another sensor, updating the location in the database as soon as new data were received according to a programmed rate.
The experiments were designed to consider a greater diversity in the routes, including highways and longer distances. They were performed in the city of Malaga. Figure 13 presents a screenshot of the HMI showing the route of one of these experiments, as well as labels for selected locations. The path started at the campus of the University of Malaga (red square) and reached the eastern limit of the city (label 6) to finally go back to the campus. This route was performed in 1 hour and 24 minutes, for a total of 28.3 kilometers covering highways in the western part of the route (labels 1 and 2) as well as urban areas for the rest. Table 2 presents some of the data obtained by the mobile node together with the geo-located labels in the route marked in Figure 13. The measurements recorded by the different sensors were shown in real-time at the HMI, allowing the user to visualize a plot with the evolution of a certain sensor by selecting it in the interface. Figure 14 shows the evolution of the measurements obtained by the NH 3 sensor along the route covered by the experiments.
In contrast with the local mode in the networked mode the strategy allows for acquiring a larger amount of data, since the update and synchronization of the databases takes place every time a new data is obtained by any sensor. Thus, the slow dynamics of a sensor does not limit obtaining more data with a faster one. In this way, Table 2 presents a summary of the data, while a more extensive set of measurements is presented in Appendix A. Table 2 presents the last data obtained for every sensor when the test car reached the locations labelled on Figure 13. shows the evolution of the measurements obtained by the NH3 sensor along the route covered by the experiments.
In contrast with the local mode in the networked mode the strategy allows for acquiring a larger amount of data, since the update and synchronization of the databases takes place every time a new data is obtained by any sensor. Thus, the slow dynamics of a sensor does not limit obtaining more data with a faster one. In this way, Table 2 presents a summary of the data, while a more extensive set of measurements is presented in Appendix A. Table 2 presents the last data obtained for every sensor when the test car reached the locations labelled on Figure 13.   shows the evolution of the measurements obtained by the NH3 sensor along the route covered by the experiments.
In contrast with the local mode in the networked mode the strategy allows for acquiring a larger amount of data, since the update and synchronization of the databases takes place every time a new data is obtained by any sensor. Thus, the slow dynamics of a sensor does not limit obtaining more data with a faster one. In this way, Table 2 presents a summary of the data, while a more extensive set of measurements is presented in Appendix A. Table 2 presents the last data obtained for every sensor when the test car reached the locations labelled on Figure 13.

Conclusions
A modular mobile node has been implemented, capable of using different sensors according to mission needs. The mobile node has been integrated with an existing static network, adding flexibility and range to it and transforming it into a Hybrid Wireless Sensor Network. Integration has avoided the need for multi-hop routing, which can reduce the operating lifetime of the nodes due to increased communication. Two different integration modes have been developed: local mode and networked mode. Data gathered with the mobile node have been presented to the user in real-time, by means of a Human-Machine Interface showing data from a database synchronizing the information gathered by the mobile node, which may include information from other static nodes as well. Finally, the system has been tested in real urban scenarios in a use-case of measurement of gas levels and environmental data.
The tests have comprised both working modes: local and networked. In local mode, the database is updated only after all present Transmitter nodes have sent their data. The dynamics of the Mobile node is then driven by that of the slowest node. Results with the local mode have shown a limited amount of data, as expected. In particular, the slow dynamics of the CO 2 sensor has produced a low rate of new data arriving to the external database, and then to the user interface. In networked mode, an update of the database takes place every time that a Transmitter node captures data and sends it to the Receiver node. This strategy allows acquisition of a larger amount of data, as evidenced by the experiments carried out.
The architecture is flexible enough to change easily the number and type of sensors. Experiments have been performed with different sets of sensors, showing no compatibility problems. The modular design of the Mobile node allowed an easy reconfiguration. The flexibility of the system makes it easy to be adapted to other use-cases, like search and rescue missions. The proposed system provides a vehicle with a tailored set of sensors, configured for the needs of the mission. The acquired data are accessible to other vehicles or participants of the mission, allowing collaborative efforts towards a Cyber-Physical System integrating sensors, vehicles or humans. Future lines of work advance in this direction. For instance, an improvement can be planning the motion of the Mobile node according to the acquired data, in order to get an improved coverage or amount of data. This line may be particularly interesting in other use cases, like emergency response. In this case, the set of sensors might be defined according to data gathered by the static part of the WSN, thanks to the modular architecture. Another future line of work includes the study of the robustness of the H-WSN, comparing its performance with a static WSN. Additionally, technologies like LoRaWAN can be an alternative to develop this kind of application. An interesting line is the evaluation of the performance of an alternative implementation based on a different technology, and its comparison with the approach proposed in this paper.