# Integration of a Mobile Node into a Hybrid Wireless Sensor Network for Urban Environments +
## 3 Mobile Node
### 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 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  
Figure 3: Architecture of the Mobile node. 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, where:  
(A) Start delimiter [3 bytes]: It is made by three characters \"<=>\". (B) Frame-type indicator byte [1 byte]: This field defines if the frame is binary (0 \(\times\) 00) or ASCII form (0 \(\times\) 80). (C) Number of sensor fields [1 byte]: It specifies the number of sensor fields included in the frame, in hexadecimal. (D) Separator [1 byte]: The start of each field is marked by a character \"#\", as well as the end of the frame. (E) SerialID [10 Bytes]: This field is made by a 10-bit-long numeric string which identifies uniquely the device. (F) NodeID [0-16 bytes]: String of characters labelling the node. (G) Frame sequence [1-3 bytes]: It indicates the sequence number of any frame sent.