Content-Oriented Disaster Network Utilizing Named Node Routing and Field Experiment Evaluation

SUMMARY Low Power Wide Area Network (LPWAN) is designed for low-bandwidth, low-power, long-distance, large-scale connected IoT applications and realistic for networking in an emergency or restricted situ- ation, so it has been proposed as an attractive communication technology to handle unexpected situations that occur during and / or after a disaster. However, the traditional LPWAN with its default protocol will reduce the communication e ﬃ ciency in disaster situation because a large number of users will send and receive emergency information result in communication jams and soaring error rates. In this paper, we proposed a LPWAN based decentralized network structure as an extension of our previous Disaster Information Sharing System (DISS). Our network structure is powered by Named Node Networking (3N) which is based on the Information-Centric Networking (ICN). This network structure optimizes the excessive useless packet forwarding and path optimization problems with node name routing (NNR). To verify our proposal, we conduct a ﬁeld experiment to evaluate the e ﬃ ciency of packet path forwarding between 3N + LPWA structure and ICN + LPWA structure. Experimental results conﬁrm that the load of the entire data transmission network is signiﬁcantly reduced after NNR optimized the transmission path.

(source only) and DU (dual unit) PDUs (protocol data units) in 3N, the nodes can effectively forward the data. c) We applied object detection in the camera nodes to detect and generate categorized contents, so the small size data can be transmitting in the low bandwidth network such as LPWA network.
The remaining of this paper is organized as follows. Section 2 presents our previous studies including LPWAN, ICN, 3N, object recognition and their application in disaster. In Sect. 3, we have proposed our content-oriented disaster network, which utilize node name routing. Moreover, in Sect. 4, we have designed and evaluated a field experiment held in a sea side city. In the end, we have concluded our proposal with some scope of the future work.

LPWAN
The development of LPWAN has benefited from the rapid development of the Internet of Things (IoT) in recent years (Standards by different organizations shown in Fig. 1). In comparison to LPWAN, Wi-Fi module's current cost is also very low, but the communication range is not wide enough, cellular network module is too expensive which it provides wide range coverage. LPWAN module is in the middle between Wi-Fi and cellular network so it is an ideal low-cost, low-power consume and long-distance communication device which is suitable for "IoT private network". LPWAN is used in several applications, including disaster monitoring and recovery communicating. LPWAN sensors can capture data bits and transmit them via dedicated gateways, then send them to the public network.
LPWAN has three physical features: 1. "long-distance communication", 2. "low-rate data transmission," and 3. "low power consumption" so it is very suitable for IoT applications like the disaster scenario that requires long-distance transmission, less communication data, and long-term duration. Most IoT applications usually only need to transmit a very small amount of data. For example, the sensors that control the switches in the industrial production plant only generate data when the switch is abnormal. These devices generally consume low power and can be powered by batteries for a long time. Although cellular networks can also be applied, it cannot solve the problem of high power consumption.
The LPWA communication module we used in this paper is IM920 [8], a 920MHz communication module which transmission rate at 50kbps, range at 400m and consumes power at 25mW. Unlike cellular networks, the 920MHz LP-WAN is license free. There is already an IM920 based LPWA mesh network deployed in Minami-cho, Tokushima, Japan [9], to perform field experiment for our proposed network architecture. This LPWA module uses its special communication format that combines packet header and user data. The received packet header contains node number, received signal strength indication (RSSI), sequence number, etc. This packet header can cooperate with our previous proposed Named-node networking (3N) to realize the Information-centric networking (ICN) implementation.

CCN and 3N
As one of the famous ICN solutions, the Content-Centric Network (CCN) was designed by Palo Alto Research Center (PARC) [10]. It relies on the concept of publish/subscribe paradigm (Fig. 2) as an alternative to the typical send/receive model [11]. A subscriber sends an interest message which she/he is interested in, and the interest message is only identified by the content name and routed to the publisher based on the content name. Once interest has arrived, the content message sent by the publisher will be returned to the subscriber in response and a copy of the content will be stored in each crossed router. Therefore, other subscribers can obtain this content based on the content name from the nearest router which has stored this copy instead of re-acquiring it from the publisher. Therefore, CCN proposed a thorough revision of the Internet architecture from naming hosts to naming content. On the IoT side, contents are ephemeral, short-lived, small and fresh, different priorities and from various locations [12]. Also, CCN provides the primary mechanisms for content integrity and authentication veri- fication. During the entire message transmission, the content is addressable, routable, and certifiable, regardless of its physical location [13].
The main idea behind CCN is to allow a network device to obtain specified content from a content producer (publisher) regardless of the physical location of the content producer (publisher) or from any other device that has cached the same content. The network uses some key elements to share the contents, which are Content Store (CS), Pending Interest Table (PIT) and Forwarding Interest Base (FIB), as shown and described with the working mechanism in Fig. 2. Therefore, network devices (subscribers) communicate based on content names rather than IP addresses. It makes content locations transparent to network devices and simplifies content access. Second, a copy of the named content can be cached on every intermediate node from the publisher to the subscriber. This can increase device mobility, low power operation, and content availability under intermittent connection conditions. Third, self-contained content security can be provided in the CCN. The security of content depends on the content itself, not the protection of end-to-end communication channels via IPsec or SSL.
Content name is the only identifier for content distribution in CCN. Every content's name prefix structures like URIs using "/" characters to separate different components. The first and second part of the content name provides global routing information and organizational routing information for packet routing. The last part of the name contains the segmentation functionality and the versioning, basing on the principle, one content can be fragmented into multiple segments and still be addressable [10].
In the CCN network, all data packets are forwarded hop-by-hop, while the routers maintain three basic data structures, PIT, FIB and CS. The CS serves as a local content cache for contents that passed through. The FIB helps to map content names to the output interface to reach the appropriate publisher. The PIT helps to track the incoming pending interest message interface. Once a packet reaches an interface, a longest matchmaking is performed based on its content name, and further action will be taken based on that result.
However, because the standard CCN network lacks accounting capabilities, there are doubts about controlling, managing and connecting. The lack of accounting has the unintended side issue of unable to ensure reliability in the low delay and high user mobility scenarios. In order to solve the issue, we proposed named-node networking (3N) [7], a network architecture that is an alternative to TCP/IP, as a host-centric extended solution for ICN. We aimed for efficient and flexible content sharing in environments where users are basically mobile. 3N introduces a new node namespace into basic content-centric network architecture. 3N uses a network naming scheme described by Dr. Saltzer in RFC 1498 [14], which contained separated, unique node and content namespaces. Particularly, the node namespace is managed with a topological structure designed for enrolling and dis-enrolling in the 3N network. 3N defines two  kinds of protocol data units (PDUs), mechanism PDUs and data transmission PDUs, as shown in Fig. 3. We also introduced node name signature table (NNST) as a routing table managed by node names. The PDUs and NNST affect the network configuration by offering 3N names to the nodes and using node name based routing strategy to deliver data packets.

3N PDU and NNR
The 3N architecture and 3N PDUs, as mentioned in the previous section, use known procedures of packet-switching networks. 3N still concentrates standard ICN content sharing mechanisms to decrease the server's load on particular content producers and ensure low network latency and higher network bandwidth efficiency. The naming for the nodes in 3N network ensures those types of scenarios can be managed clear and efficient. In this paper, we mainly discuss the utilization of the data transmission PDUs, source only (SO) packet and dual unit (DU) packet, in the LPWAN. The SO and DU qualified LPWAN packet architecture can be found in Figs. 4 and 5.
Data transmission PDUs are designed to transmit content using 3N names. The use of 3N data transmission PDUs requires the node to have a 3N node name. By satisfying this condition, the node can route the 3N packet with NNR (node name routing). In [15], NNR has been proofed to be valuable for use in disaster areas. The study evaluated the NNR strategy to compare with the OLSR (optimized link state routing protocol) and the DSR (dynamic source routing) strategy, and the results showed that NNR performs better regarding packet delivery, routing cost in a substantial number of users.
When a node receives a SO packet, it will first process the 3N header which contains the source node's 3N name, then process with standard ICN protocol to satisfy the requested content delivery. If a standard ICN interest packet reaches a 3N node, the node will ignore the 3N header process and deal it in standard 3N. When a DU packet is being delivered to its subscriber node, any router node will process the 3N header and trace the PIT to forward the packet through the correct interface. If a standard ICN content packet reaches a router node, the standard ICN process will be performed.
With NNR implemented in the LPWAN, a selforganized network can be set up very quickly when a disaster occurs. NNR can make sure to always forward packets to the nearest data source, because NNR can flood the network, using RSSI and delivery hops information to compare the distance and route health among all nodes, and select the best path to route data packets. This is very valuable in emergency network conditions, where users can send alarm information to the nearest area for rescue. Thus, NNR can reduce the broadcast packets compare to ICN flooding and release the network pressure.

M2M Network and Disaster
In recent years, the IoT network benefits from the rapid machine to machine (M2M) network development. In a disaster network, people worked hard on technological details for no-disconnection network and disaster information sharing system (DISS).
Recently, some studies were also proposed on disaster networks based on ICN as well as IoT networks based on ICN. Arshad et al. [12] developed an ICN based hybrid naming scheme for IoT based smart campus. They aim to update categorization of IoT applications, operate to assign names to contents and better request satisfaction rate for IoT smart campus. Chen et al. [5] developed a notification service for managing disasters, which can significantly reduce network load, network latency, and benefits from the simplified operation, security and appropriate prioritization. Yagyu et al. [16] proposed a demo to show the integrated framework of push and pull type ICN communication and applied it in a disaster scenario. Hannan et al. [17] designed the ICN and IoT based disaster management system and showed its effectiveness of scalability and ICN infrastructure. They also proposed push support in the system with simulation results.
There are also some ICN based disaster network proposed related to our previous works. Shibata [9] organize and performed the experiment of ICN based LPWA network to demonstrate the evacuation and alarm information sharing system. Wen et al. [15], [18] developed an ICN based ad-hoc content sharing network and the extended version of using NNR to solve the multiple-name problems in both 3N ad-hoc networks and TCP/IP ad-hoc network. My previous work [6] proposed a content-oriented surveillance network architecture, and evaluate the system's performance on reducing the network load by generating named contents using object detection.
While in a content-oriented network, the content name is a vital element to the whole data delivery system. Who/what is naming the contents becomes an important part of the system. In this paper, we used tensorflow platform [20] and region-based convolutional neural network (RCNN) [19] to detect objects, categorize the generated contents and name them. Figure 6 is the example of human detection in the experiment. This down resolution image is authorized by MIC.

Content-Oriented Disaster Network Utilizing Node
Name Routing

System Overall
Our proposed disaster network architecture is a combination of several parts, the LPWA mesh communication network, and the DISS Box units. The LPWA network was deployed in the field experiment area in Minami-cho, Tokushima, Japan. In the experiment area, there were many LPWA forwarding nodes, working on the same frequency (LPWA channel), covering the place. The mesh network automatically repeats the packets and broadcast them to every receiver by default. However, we managed to implement the nodes with 3N basic functions to recognize the ICN packets and the ability to maintain the routing table with NNR, which will be discussed in the next subsection. The LPWA nodes formed a mesh network and can be managed as one information distribution platform. A Disaster Information Sharing System Box (DISS Box) is assembled with several components: a central processing platform powered by a compute stick [21], an image capturing unit powered by a camera, wireless communication modules and a battery module (topology shown in Fig. 7). The high performance compute stick provides the real-time image processing power to generate useful information based on the captured image, which includes people count information and intercepted images of interested objects. The Wi-Fi and Bluetooth module included in the compute stick provides the connectivity to the client users for disaster information publishment, and Bluetooth tag for evacuating individual tagging, which was used in the previous experiment [9].

Node Name Routing
In the LPWAN communication protocol, a node name (serial number) is utilized in the packet header of each sent packet. In this paper, we proposed a node name protocol to combine the LPWA's device name with the 3N's node name, in order to implement 3N NNR mechanism in the network, optimizing the packet routing efficiency for the entire network. To achieve this goal, we formatted the LPWA packet structure into 3N qualified structure (related 3N qualified SO and DU packets are shown in Figs. 4 and 5). Using this packaging format, we can utilize NNR mechanism to maintain the network and optimize the traffic routing actively during the data transmission.
NNR is a routing strategy which maintained by node names. In the packet transmission of the network, the DISS content name prefix is organized in a hierarchical URI style similar to the CCN standard style. DISS uses a name prefix by combining Message Type, Geographical Names and Coordinates. For instance, Fig. 8 presents an example of the name prefix. When a user wants to generate a name prefix, the GPS device generates a GPS coordinate and the node performs geographical information look up with the reverse geocoder, powered by small size offline database of the region. Then the node combines the enriched geographical information with the GPS coordinate to generate the named content. The coordinates information can be found from a database like Open Street Map (OSM).
In a general 3N network, there are enrollment procedures for nodes (fixed or mobile) that do not have a preset name. In our experiment below, we pre-assigned node name to each node. During the initialization of the network, the system would flood the network with 3N SO packets and retrieve the DU packets. The nodes would update and maintain its NNST, tracing the last and the next hop to determine the best route. The NNR routing strategy is designed to find the best route between the subscriber and the publisher. Like the DSR (dynamic source routing) and AODV (Ad-Hoc on-demand distance vector) methods in TCP/IP, NNR show more advantages in optimizing routing table in ICN network [15].
The forwarding mechanism in Fig. 9 represents the packet forwarding mechanism. When a node receives a source only (SO) packet, it will first check its Content Store (CS) to see if there is already matching content stored. If there is no cached content, it will check Pending Interest Table (PIT) if there is already an entry in PIT, then the node will add a new entry or update an existing one. At last, if no existing PIT entry found, then the node will log the information in Forwarding Interest Base (FIB) and continue flooding the SO packet to the other nodes. The DU packet will help the node tracing the last hop.

Evaluation
In this section, we performed a series of field experiments to evaluate the actual performance of NNR in the LPWAN. We have taken the experiment in Minami-cho, Tokushima, Japan, in Dec. 13th, 2017. As a matter of fact, this place very much values the disaster precaution and emergency response. The experiment is an extension of the previous LPWA IoT system experiment for tsunami disaster prevention [9], which performed an evacuation drill authorized by MIC. There were approximately 40 people observed from the street view, during the experiment. The experiment took place for 4 hours in the day, with the powered of rechargeable batteries. Figure 10 shows the node distribution map. We have set DISS Boxes at node 41 through 46, marked red in the figure. Based on the map of our experiment area, the city is surrounded by water by the south and east side. So, during a tsunami evacuation, people will have to move in the direction of the northwest. The yellow roads on the map represent for the main road of the city, which are also the life-lines during a disaster. In general, node 44 and 45 represent the evacuation locations, a hospital and a government building with a school next to it. Node 21 is also a highaltitude tower, the emergency control center, which can be a shelter, but it lacks accessible life-lines. Because of this patent, we can generate experiment database on the camera nodes in the main roads. We aimed to compare the network load between ICN routing and 3N node name routing, which didn't need to perform large scale of evacuation drill, which also needs complicated application and preparation. The contents were generated from street view, in order to protect public privacy, unauthorized image data wouldn't be stored.

Field Experiment
In the field experiment, we extended the previous ICN based LPWAN network [9] to a 3N based LPWAN network. The experiment aimed to measure the performance between ICN routing and 3N node name routing, rather than a real-life evacuation drill. Around this region, we have arranged 40 DISS nodes, at the lamp posts in the streets and main roads (location details are shown in Fig. 10 and experiment parameter are shown in Fig. 11). The DISS nodes were embedded with ICN and 3N stack [23] in order to forward communication packets, and they use LPWA network to communicate. Additional 6 DISS Boxes were distributed on the main roads, and the nodes 41-46 were on the main road of the city. In the experiment, people would take the main road and captured by the camera nodes eventually, ensuring that the collected tracking data was accurate on the evacuation route from the previous experiment.
The experiment uses an IoT platform with data processing capabilities. For ICN routing we used CCNx0.8.2 in the 6 DISS Boxes, and for 3N NNR routing we used 3N application version 0.1. During the experiment, the nodes along the street actively collect data to obtain useful information by machine learning during the experiment. By using node names, it is possible to push to the disaster prevention center's server or terminals of affected people. In the disaster scenario, the nodes also have a built-in HTTP server to output the real-time human recognition processed image visually.
When the tsunami evacuation alarm is in effect, the residents will take refuge in the places safe on high grounds. The general evacuation route is to move from the streets to the roads and finally upon the high-altitude shelters. The DISS Boxes are on the roads of the evacuation routes. The nodes identify the evacuating people individually and generate related information and send it to the client or evacuation command center, and the command center is assumed allocated at node 21, on top of a hill. We use this scenario to generate contents and let the LPWAN to forward them to the command center with NNR and with ICN routing strategy.

Results
Figures 12 and 13 are the network traffic heat-maps using normal ICN flooding routing and NNR rouging. Figure 13 also contains a delivery route topology, indicating a content delivery route used in the network. The delivery topology shows how the packets are forwarded in the network. Because the LPWA connection might be lost and reconnected, the 3N nodes might need to reflood the network to create a new forwarding route. The system had generated approximately 13230 packets and we verified and compared 3N with standard ICN in packet transmission efficiency. From these two heat-maps, we can see that 3N network consumes less network resource than standard ICN network. Based on the traffic data gathered in the experiment, we were able  to calculate the overall traffic ratio is at 40.58%, compares 3N to ICN. The overall packet ratio received at the emergency control center is 5.29% and 2.15%, in 3N and ICN. The network consumption in 3N network is significantly smaller compared with that in ICN network when the same size packet is transmitted. The difference between the two figures is that based on LPWA mesh network topology, the ICN flooding routing method will broadcast interest packet to every node possibly containing content and then when the content packet is being transmitted, the packet will follow the PIT entry to be delivered to every node. The ICN flooding routing causes waste data traffic in the mesh network, and this leads to multiplied bandwidth consumption and in the figure the whole area in high traffic load. Instead of blindly flooding packets to mesh network nodes, NNR actively updates the NNST in the nodes and finds the best route for the content delivery. This method means only the related nodes in the path of the content delivery route consume network bandwidth, the excluded part of the nodes will remain in low traffic consumption because only SO packet will be flooded in the whole network to determine the best route. From the two heat-maps, we can see that 3N network consumes less network resource.
In Fig. 14, there is the traffic comparison of NNR and ICN forwarding mechanism. In the experiment, the emergency control center requires named content from the network. When a matched content is found, the content will be forwarded to the control center. Together with the heat-map above the compare of our proposed NNR and the ICN mechanism we can notice the difference in those nodes excluded in the optimized routes of the whole content delivery topology. In the ICN mechanism, those nodes were flooded with the packets and this caused almost all the bandwidth of the LPWAN system and unnecessary traffic load to them. On the other hand, our NNR system optimized the content delivery mechanism and only utilized the best delivery route, based on the number of hops and RSS information, to handle the packets. This is very important for LPWAN to deliver most valuable information out of least costly communication network as more valid information can be distributed, and the rescue power can be deployed most effectively.

Conclusions
An NNR-based LPWA disaster network is proposed in this paper. By applying NNR, the low bandwidth utilization problem in LPWAN is solved with its optimized routing ability. Field experiment results demonstrate that NNR expresses a better performance regarding the overall network bandwidth usage and content deliver efficiency. This is very valuable in the disaster area where mainstream networks are down, by using LPWAN+NNR based self-optimized network an emergency network can take place. However, future practical solutions require practical experience. Future research and experiment are required because we need more result data for further inspection to conclude more solutions.