Messages are represented as Erlang tuple data structures that consist of message identifier, a sender identifier, a message body and a timestamp. We implemented two message filtering rules that apply the principle of combining static with temporal filtering, as discussed in Section 3. Both rules were coded so that they execute in constant memory space. This makes possible to handle high volumes of message traffic without exceeding the phone’s available memory. All received messages are stored in an ordered list that is reordered each time a new message is received, using a modified version of the Quicksort algorithm. The list is pruned periodically by applying the sliding time window principle, i.e., removing broadcast messages over 2 minutes old and team messages over 5 minutes old.
Another design objective was to ensure that the messaging system can cope with high volumes of constant message traffic, but also with occasional bursts, without dropping or failing to filter messages. We model the background communication message flow as a random uniform distribution where the number of inter-team messages transmitted by the network grows linear with the size of the emergency response organisation. Thus, for an organisation of size n we simulate a message traffic of an average of n/2 messages per minute. For an organisation of 1000 members, this would amount to an average of 500 messages per minute, or approximately 8.3 messages per second. In addition to broadcast messages, we simulate intra-team messages. We assume that the arrival of such messages follows a Poisson rather than a uniform distribution. We have experimented with an emergency response team size of 10, and with event frequencies λ, ranging from 1 event per minute to 1 event per 10 minutes. When an event occurs, we simulate the intra-team communications with a random burst of between 0 and n2 messages per λ, which for a team size of 10 and λ = 10, equates to an average rate of 50 messages per 10 minutes. We carried out repeated simulations by varying the values of parameters discussed in the previous section. Each simulation run takes place in real-time and lasts for 120 minutes. For an organisation size of 1000, an average of 60,000 messages are sent to the mobile during each simulation run. Messages are auto-generated by the simulation environment, by selecting at random, a message sender, a message body from a list of preset choices, and by time-stamping the message. The refresh rate of the message list was set to between 0.2 and 1 updates per second. Although if it is unlikely that a responder is going to check her phone every few seconds for updates, a high refresh rate means that when she decides to do so she will obtain the most up to date list of the messages.
A message list update begins with a header that contains the time of the update and the total number of new messages, followed by the filtered list of messages (if any). Each message consists of the time it was received (thus showing how recent the message is), followed by the team name of the sender, and then by the message body. Figure 2 shows a message sent by a member of another team (‘otherbuddy6’) informing that ‘the staircase in Zone 2 has collapsed’. Due to the filtering methods applied, both the identity of the sender as well as the subject of the message will be relevant to the responder’s current mental state, thus helping her to maintain situation awareness.
Throughout the entire simulation, no message loss or incorrect filtering of received messages was observed. Thus, for the implemented set of filtering rules and sustained message rate (an average of 8 messages per second), both reflecting realistic emergency response conditions, the mobile phone seems capable of coping with both message reception and filtering.