## 3 System Design and Implementation
### Proposed System  
The proposed prototype mainly includes two entities--a server and a client. The client part is integrated on the On-Board Unit (OBU) that is basically deployed in a vehicle or in a hand-held device which is used by a volunteer during rescue operations. The server part is the control room which is primarily a central entity to visualize all the statistics that are being collected in the affected area. It has a user-friendly interface for data visualization and a concurrency-based Python code that generates response against specific requests initiated by the rescue team members from their hand-held devices, hence achieving bi-directional communication based on the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of the Open Systems Interconnection (OSI) model. The received information comprises a structured data format, which includes the coordinates of the exact location acquired from a GPS sensor attached with the transmitting node. All of this will be explained in detail in the sections to follow. The proposed emergency response plan is illustrated in Figure 1. A volunteer who is moving around the affected area generates a peremptory request in a message for certain need at the incident location of a seriously injured patient. The OBU transmits a message by encapsulating the GPS coordinates of the location of interest through several hops to the destination, i.e., the Control Room. Here, the Raspberry Pi module, in addition to the GPS sensor, is used as a processing unit. The Control Room receives the message through a wireless interface, and processes the request according to its severity. Just as in a real-world scenario, as some messages can be more critical for life-saving measures than others, they shall be treated accordingly. Control room then performs the desired action by either sending the message to another entity such as a mobile hospital, or provides a notification on the user interface with messages that are less urgent. Since small-size packets like safety/alert messages move quickly and reliably in the network as compared to large-size packets, such as multimedia, safety/alert messages are mapped into codes. The alert messages, their types, and respective codes are shown in Table 1.  
Now, instead of sending the whole text message, only the message code is sent, as shown in Table 1, which is routed within the network. A typical example of how a message is formatted and sent is shown in Figure 2 using a keypad. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**No.** & **Alert** & **Type** & **Message Code** \\ \hline
1 & First Aid & Emergency Help Call & 1 \\
2 & Ambulance & Emergency Help Call & 2 \\
3 & Air-help & Emergency Help Call & 3 \\
4 & Food/Water & Help Call & 4 \\
5 & Vehicles & Help Call & 5 \\
6 & Shelter/Camp & Help Call & 6 \\
7 & Volunteers & Help Call & 7 \\
8 & Warm-clothes & Help Call & 8 \\
9 & Collapsed Land & Informative & 9 \\
10 & Broken Bridge & Informative & A \\
11 & Blocked Road & Informative & B \\
12 & Collapsed Buildings & Informative & C \\
13 & All OK/Clear & Informative & D \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Alert messages, their types, and Transferred Message Codes. Figure 1: Emergency Response Plan in Disaster Scenario. In order to use the application, a user is required to press a button according to the need--for example, a button with code 4 followed by a # sign, which is used as a separator, indicates the requirement of water or food at a certain location. Another button can then be pressed if a fixed quantity is desired--for example, a button with code 20 indicates food packages or water bottles. More than one message can also be concatenated in one go by pressing more buttons each time with a # separator between them. When the entire message is compiled, \(\mathbf{D}\) is pressed to indicate the end of a message. This entire formatted text is then wrapped in a JavaScript Object Notation (JSON) wrapper and sent to the destination.