## 5 Simulation Model and Assumptions  
We use an agent-based discrete-event simulator, namely the Distributed Building Evacuation Simulator (DBES), to evaluate the effectiveness of the novel navigation algorithm, as well as the AHCPN-based energy-efficient protocol in a fire-related emergency evacuation. The physical area is hypothesised as a graph: vertices are positions with landmarks by which evacuees can easily identify their locations by uploading snapshots and querying the server; edges are physical links by which evacuees can move inside the building. The graph can be downloaded from the cloud when a hazard occurs. The building model we employed is a large canary wharf shopping mall with relatively wide paths for evacuees to move in clusters. The shopping mall is a three-story building with two exits on the ground floor, as shown in Figure 2. Initially, evacuees are randomly scattered in the building, and they are assumed to be equipped with smart phones with random remaining battery power. When the battery power of smart phone is depleted, the evacuee will wander or follow other evacuees in the line of sight to the exits.  
We assume that no related sensors are pre-installed in the built environment. Hence, hazards can only be discovered by residents in the building. When an evacuee discovers a hazard, he/she will inform the server by using the smart phone, and then, the server will alarm all of the related civilians. Civilians can locate themselves by taking image snapshots and matching them with pre-known landmarks, which are stored in cloud severs. The photos are taken by built-in cameras on the mobile phones and then uploaded to the cloud. The image-based localization algorithms [18] are performed in cloud severs. The spreading of the hazard is reported by evacuees and predicted by hazard models in the cloud.  
In the simulation, the indoor Wi-Fi access points are presumed to have malfunctioned due to hazards or the outage of the power supply. Hence, the portable devices can only communicate with the cloud severs through UMTS. To maintain the 3G communication between the cloud and smart handsets, we hypothesise that during an emergency, a few cloud access points can be quickly deployed in the vicinity of the building. We also assume that smart phones provide the Bluetooth communication mode to conduct short-range communications. The size of the image taken by smart phones is set to 100 kilobytes, and the header of the AHCPN packets is 12 bytes [8]. The smart phone identification uses a IP address space which is four bytes. The initial battery power of smart phones yields a normal distribution, and the battery capacity of smart phones is set to 16,000 joules.  
The energy consumption model of smart phones is based on the previous literature [54; 55; 56; 57]. We assume that smart phones have three states: suspended state, idle states and high-power state. When in a suspended state, the application processor of smart handsets is idle and the communications processor performs a low level of activity [54]. When in an idle case, the smart phone is fully awake, but no application is active. Finally, the high-power case is the state when the portable device interacts with the cloud. The power utilisation of different states with regard to the elapsed time can be seen in Table 3, which is based on the average system power of specific smart phones for a selection of benchmarks in [55].  
Figure 2: Graph representation of the building model. The two black stars on the ground floor mark the position of the building’s exits.  
The energy utilization of different communication modes with respect to the amount of transferred data, as well as the associated transmission rate are shown in Table 4. This model is based on the energy consumption ratios presented in [57] and the measurement study of energy consumption over 3G and Wi-Fi in [56].