# A Multi-Technology Communication Platform for Urban Mobile Sensing
## 3 Architecture Overview
### Platform Software Architecture Overview  
As stated previously, our multi-technology platform addresses different network elements. Figure 5 overviews the platform software architecture of each element, as well as the overall connections established between them in order to achieve our platform requirements. This way, it is possible to better understand the overall complexity between the several network elements and perceive the platform's intercommunication procedures.  
Figure 4: Gateway software architecture.  
Figure 3: Mobile node software architecture. mOVE: mobile Opportunistic VEhicular.  
A brief description about the distinct software modules that assemble the platform architecture is now detailed:  
**Sensor Controller:**: Module responsible for establishing and managing all the direct interactions between the controller board and the element's inner sensors.
**Multi-technology Communication Manager:**: Module responsible for establishing the behavior of each communication interface, WiFi, and LoRa. It has the authority of defining the most suitable technology to deliver its stored data packets (built-in Sensor Controller), according to the information type and the interface availability, until they reach a LoRa gateway or are transfered to a mobile node.
**LoRa Communication Manager:**: Module responsible for handling all the behavior regarding the LoRa communication interface. Unlike what happens in a DCU, where we have the Multi-technology Communication Manager, this software module only has to deal with the LoRa technology, since the WiFi is managed under the DTN operating processes.
**DTN:**: Module responsible for implementing the disrupted and delay-tolerant network architecture.
**4. Multi-Technology Communication**:  
Multi-technology exploitation has the purpose of providing a more resourceful and flexible architecture, since it allows for covering some technology inconsistencies with another form of  
Figure 5: Proposed software architecture overview.  
communication technology. LoRa and WiFi were the chosen technologies to be employed over the proposed scenario, mainly because they present distinct capabilities in terms of connectivity range and bit rate, among others. Thus, besides the implementation of a LoRa network, it was decided to configure the platform with an additional urban sensor network based on a DTN. The DTN will be supported by the WiFi technology, namely IEEE 802.11b/g/n.  
With the multi-technology communication, an agent had to be designed in order to manage the behavior of the communications. The definition of when, how, and which technology should dispatch the data are some of the tasks under its responsibility. In order to achieve such goal, several sub-modules were implemented, namely the WiFi Manager and LoRa Manager. Figure 6 gives an overview of our multi-technology communication manager organization by giving the hierarchical design of the several implemented sub-modules.  
WiFi ManagerThis sub-module is responsible for managing the WiFi interface and how its connection should be handled. It performs an active WiFi scan, in order to discover any mobile node (DTN node) in its vicinity.  
**Network Manager:** This sub-component searches and identifies mobile nodes within a DCU's vicinity.  
**Data Manager:** This sub-component manages how the waiting data is handled when the DCU has an available destination to forward the data.  
LoRa ManagerThis sub-module is responsible to handle the LoRa communication interface.