Modeling of a Public Safety Communication System for Emergency ...

3 downloads 0 Views 268KB Size Report
ITT Corporation, Fort Wayne, IN. Abstract—This paper describes simulation work in modeling a city-wide trunked radio system and evaluating its performance.
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2009 proceedings

Modeling of a Public Safety Communication System for Emergency Response Chao Chen, Carlos Pomalaza-Ráez

Mike Colone, Robert Martin, Jim Isaacs

Department of Engineering Indiana University - Purdue University, Fort Wayne, IN

Communications System ITT Corporation, Fort Wayne, IN

Abstract—This paper describes simulation work in modeling a city-wide trunked radio system and evaluating its performance under stress. Specifically, traffic models are developed to simulate both routine background traffic and the traffic load associated with an emergency scenario of a high-rise apartment fire. An analysis of a one-month radio data log provided insights on the traffic distribution among different talkgroups, as well as building individual traffic loading profiles for the talkgroups directly involved in the emergency response. The performance of the radio system is evaluated under different traffic loading intensity levels. Initial simulation results show that this emergency response communication system provides adequate capacity even under intense traffic loading. However, one area of concern is the build-up of waiting calls within some heavily loaded talkgroup, which results in long waiting time to access the channel. Keywords- emergency communications; trunked radio system

I.

INTRODUCTION

In the event of a large scale emergency involving a populated area, emergency communication systems will be stressed to their limits. Examples of emergencies include natural disasters such as earthquakes, floods, and hurricanes, and human-caused disasters such as terrorist attacks. The stress on communication systems will result in a reduced capability to maintain vital communications and possible failure of key units within the system. Therefore, it is important to test the existing communication systems under heavy traffic load and to explore their capacity utilization. The testing procedures can help identify system bottlenecks and suggest improvements for enhanced robustness and reliability. Moreover, testing results can help design a unified emergency communication protocol under emergency scenarios. The main goal of this work is to develop a computer model of the public safety communication system in the city of Fort Wayne, Indiana and to evaluate its performance in emergency response. There are two main reasons that we choose a computer simulation model. First, although mock disaster exercises can provide valuable information on the effectiveness of emergency communication systems, these exercises are costly and require extensive and careful planning. Comparatively, computer simulation has a low cost and can test systems repeatedly under different scenarios. Second, most current municipal emergency communication systems are based on an 800MHz trunked radio system that is computer controlled. It is therefore possible to develop a computer simulation model of an 800MHz emergency response communications system. Our computer model emulates the deployment of radio assets throughout the city of Fort Wayne and the infrastructure

that enables emergency response users to communicate using the system. Along with the network model, traffic models are developed to simulate both routine background traffic and the traffic load specifically associated with an emergency scenario of a high-rise apartment fire. Moreover, a one-month real traffic log from the Fort Wayne public safety communication system is analyzed to define the traffic loading patterns for the simulation model. Traffic log analysis also helps classify the talkgroups according to their statistical features. It is found that among the total 108 talkgroups in the system, 20 talkgroups account for 91% of total calls; and 76 talkgroups participate only sporadically for specific tasks. These results help reduce the effort in simulating every talkgroup in the system yet still achieving accurate performance. To complete the apartment fire scenario, we create individual traffic loading profiles for the talkgroups directly involved in the emergency response. Simulations are executed at different levels of traffic loading intensity. The performance of the public safety communication system is characterized in terms of channel utilization, channel access delay, and the number of calls waiting. Initial simulation results show that the Fort Wayne emergency response communication system provides adequate capacity even under intense traffic loading. The only area of concern is a build-up of waiting calls within some heavily loaded talkgroup. Our computer model can be modified to simulate other trunked radio systems under various emergency response scenarios. A. Previous Work and Our Contributions Computer simulation software has been used to simulate public safety trunked radio systems. In previous work (e.g., [1][2]), however, the performance of their simulation models has not been tested under specific emergency response scenarios. Our model of the Fort Wayne trunked radio system is developed based on the APCO Project 25 standards [3]. Besides modeling the communication system, we also added different traffic to test the system performance under both normal and emergency scenarios. Unlike conventional radio systems where channel assignments are fixed, trunked radio systems use a pool of channels that can be allocated dynamically to talkgroups. Talkgroup voice traffic in trunked radio systems is usually modeled by an Erlang C model or its variations based on the assumptions of Poisson call arrivals, exponential call holding times, and independency among calls [4]. These conditions, however, were found not valid for traffic during busy periods. For example, it was found that call inter-arrival time could better be predicted using a Weibull, gamma, or lognormal distribution as opposed to an exponential distribution [5][6][7]. For call holding times, the best fit is a lognormal distribution.

978-1-4244-3435-0/09/$25.00 ©2009 IEEE

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2009 proceedings

We adopted the above models in our system to simulate the traffic load under emergency scenarios. Moreover, our effort differs from the previous work in the following aspects: First, most existing work (e.g., [5][6][7][8]) focuses on characterizing the statistical features of individual calls, so that synthetic data can be generated using statistical models and used as traffic feed to test public safety communication systems. Our work, on the other hand, focuses on the testing of the system under emergency scenarios. In this sense, the closest work to ours is [2]. Compared with the computer model in [2] that uses sample data as input, our model is tested with statistical traffic models under a specific emergency scenario. Second, our work considers the heterogeneity of talkgroups in terms of load and functionality. Our system traffic load consists of two parts: system background traffic that represents normal daily traffic and emergency scenario traffic specifically caused by the emergency response. The system background traffic is closely approximated by the accumulated traffic from major talkgroups in the system. The emergency response scenario only affects traffic from certain talkgroups. Moreover, traffic load from these talkgroups is affected in different manners and changes over time. Parameters for traffic models are set with reference to data records from the Fort Wayne public safety radio system. We believe that by using traffic models that are specific for trunked radio systems and by distinguishing talkgroups according to their roles and participation levels in the emergency scenario, we are able to test the performance of our simulation model and get realistic and reliable results. Meanwhile, we were in close contact with the Fort Wayne Fire Department, Police Department, and other city officials throughout the modeling and scenario testing procedures. Therefore, the simulation results are pertinent and helpful for the evaluation of the actual communication systems. The remainder of this paper is organized as follows. Section II introduces the design of the network model. Section III describes system traffic analysis and talkgroup classification based on a one-month real data log. Section IV explains the tested emergency response scenario and the methodology to generate background traffic and emergency scenario traffic. Section V gives the performance evaluation metrics and results. Finally, Section VI concludes this paper. II. NETWORK MODEL Our network model was developed using the OPNET network simulation software [9] and consists of a central system controller, base stations, dispatch locations, and mobile units, as shown in Fig. 1. Base stations are fixed repeaters that relay communications between mobile units as they operate in the field. They work with the system controller to receive and transmit control information. The Fort Wayne system has two base stations each supporting 18 traffic channels. A simulcast system is used where multiple base stations simultaneously transmit the same information on the same frequency. These base stations provide full RF coverage of the area of operation. Mobile units are public safety (e.g., police, fire, and emergency medical services (EMS)) vehicles and individuals equipped with push-to-talk (PTT) radios. Mobile units form groups called “talkgroups”. A mobile unit makes a group call request by pushing the PTT button. The central system controller assigns group calls from subscriber units to specific traffic channels. In our model, mobile units communicate by

Mobile Unit

Mobile Unit

Base Station

Fig. 1.

Base Station

Dispatch System Locations Controller Basic components of a typical trunked radio system.

relaying transmissions through base stations. Direct mobile-tomobile transmissions are not supported. Dispatch locations represent operators receiving 911 calls from the public telephone networks and contacting units in the system to respond to these calls. Transmission trunking is used so that a voice channel is assigned only for the duration of a radio transmission. When a transmitting unit releases the PPT button; the controller holds the channel for 2 sec before freeing it for reassignment, in case another caller from the same talkgroup responds. III.

DATA-LOG ANALYSIS

We were provided with a summary of radio system traffic for July 2007 collected at the control center. This real data contained daily talkgroup activity including the number of group calls, total group call duration, average call duration, and talkgroup traffic load as a fraction of the total system load. Overall, statistics for 108 talkgroups were provided. Since the radio system traffic statistics only include daily summaries, there were no records for individual calls. The summary data provided was not sufficient to do parametric data fitting to possible statistical models. Instead, a statistical analysis on the available data records was used to identify primary talkgroups and to simulate normal day-to-day background traffic load. A. Daily Distribution of System Traffic To determine how the Fort Wayne system traffic load varies from day to day, we compared the traffic load that the system handled each day to the overall daily average in July. The analysis results are shown in Fig. 2(a). Traffic load is characterized by the number of calls sent per day (i.e., call count) and the total time that those calls occupy the radio system during the day (i.e., call duration). The y-axis value is the system traffic in a day divided by the average daily traffic load. The figure shows low traffic load on Sundays (1, 8, 15, 22, and 29) and the July 4th holiday. Call duration and call count have similar patterns over the month. The results of this analysis were used to establish the background traffic for the system during the day that the disaster scenario was simulated. B. Traffic Distribution over Talkgroups Fig. 2(b) plots the Complementary Cumulative Distribution Function (CCDF) of the traffic load distribution over talkgroups. The relative load is the talkgroup traffic load divided by the total traffic load on the system. The figure shows that traffic distribution over different talkgroups is highly uneven. Among 108 talkgroups, only 20 have a relative load larger than 0.01 (or 1%) of the system load. The load of these 20 talkgroups accounts for 89% of the call duration and 91% of the call counts in the whole system.

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2009 proceedings

Traffic distribution in July (all 108 talk groups)

0.8

0.6

0.4

0.2 call duration (average: 155780 sec/day) call count (average: 15554 calls/day) 4

8

15

22

29

call duration call count

100

80

number of groups

number of talk groups (with relative load >= x)

1

relative load

108

108

average load

0 1

CDF of relative standard deviation distribution over talk groups

CCDF of load distribution over talk groups

1.2

60

40

32

Category 2

20

16

Category 1 31

0 0

0.02

0.04

day

(a) Daily traffic distribution.

0.06 0.08 relative load (x)

(b) Traffic load distribution among talkgroups. Fig. 2.

0.1

0.12

0.14

1 -2 10

-1

10

0

10

1

10

relative standard deviation (std/mean)

(c) Distribution of the relative standard deviation of call duration.

Data-log analysis for July 2007.

C. Call Duration Analysis Call duration analysis focuses on the length of time that individual calls occupy the system. It was found that the average call duration for the whole system during the month of July is 10.0 sec and the standard deviation of the daily average call duration is 0.189 sec. Since the standard deviation is very low, this indicates that the average call duration across the whole system is very stable over different days. The average call duration of individual talkgroups was also calculated. Fig. 2(c) plots the Cumulative Distribution Function (CDF) of the relative standard deviation of daily average call length for each talkgroup. The relative standard deviation measures the stability of average call duration in a group over different days and is defined as the ratio of the standard deviation and the average of call duration. As suggested by Fig. 2(c), the 108 talkgroups can be roughly divided into three categories according to the relative standard deviation of average call duration: • Category 1: Groups that handle routine traffic – This category consists of 16 talkgroups with a relative standard deviation that is less than 0.10. These groups appear to handle routine traffic everyday, and the call duration distribution is stable. • Category 2: Groups that handle less-routine traffic – This category also contains 16 talkgroups and is characterized by a relative standard deviation between 0.10 and 0.45. These groups usually generate traffic everyday but the lengths of the calls vary more than those in Category 1. • Category 3: Groups that handle sporadic traffic – This category consists of talkgroups that do not generate traffic every day. The relative standard deviation of their call durations is greater than 0.45. This category includes the remaining 76 talkgroups. They participate only under specific situations and their traffic is very task oriented. Among the 20 talkgroups that account for the majority of the load, as described in Section III-B, fourteen belong to Category 1, four are in Category 2, and two are in Category 3. IV.

Category 3

TRAFFIC MODELING

In this section, the specific emergency response scenario is first introduced. Next, a detailed overview of how the traffic is generated and input to the simulation model is covered. Parameters to support the traffic models are derived from channel utilization and talkgroup activity records in July 2007.

TABLE I

MOBILE UNITS INVOLVED IN THE EMERGENCY SCENARIO

Number of mobile units involved 62 firefighters 18 emergency medical service (EMS) units 16 police units 4 public information officers gathered at the joint information center * It is assumed that each public safety unit has its own mobile device.

A. Emergency Response Scenario To evaluate the performance of the emergency response communication system, a scenario involving a high-rise fire at a residential apartment building in the Fort Wayne downtown area was selected. The scenario begins with a 911 call to the dispatch center at 6:00 A.M. on a weekday morning reporting smoke in the apartment building. The fire department responds with an initial dispatch of 22 fire fighters. Within a short time, a second alarm is called, and 20 additional firefighters are dispatched. Other agencies responding to the emergency include an ambulance as well as several police units to handle traffic and crowd control. As the fire spreads, approximately 30 people are forced to stay in their apartments due to the blockage of escape routes. Another 10 are unable to get back into their apartments. A third alarm is called for more firefighters, additional ambulances and police units. During the scenario, surrounding township ambulances are called to the scene to help with the injured. Local hospitals and others in outlying areas are also contacted for availability and treatment. This scenario was proposed by the Fort Wayne Fire Department as a realistic and traceable disaster case to test the performance of the computer model. Table I lists the number of mobile units utilizing the public safety communication system in this scenario. B. Traffic Modeling under Emergency Scenario Next, we describe the methods employed to simulate voice traffic in the Fort Wayne emergency response communications system under the fire scenario. For the simulation of the apartment fire, traffic supported by the communications system consists of two components. One component is the typical random background traffic that takes place as emergency personnel handle routine daily events. The other component is the traffic load specifically associated with the response to the fire scenario. The approaches used to model these traffic components are discussed in detail below.

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2009 proceedings

In simulating background traffic, classical models that assume exponential distributions for call duration and call inter-arrival time are used, since data is not available for the parameters required to support the advanced models as suggested in [6][7]. The July data log was analyzed to provide the average call duration and the average call inter-arrival time for each active talkgroup included in the simulation model. The accuracy of the background traffic model was validated by comparing simulation results and actual channel loading data. The number of calls and the sum of call durations for each major talkgroup closely matches the actual system record. Details of the validation are omitted because of the space limitation. 2) Emergency Scenario Traffic Model Scenario specific traffic was generated using a model that closely emulates the conversational nature of emergency communications. In a conversational model, individual calls related to the same topic make up a conversation. Each call may be from a different user, and the time between calls is typically very short (2 to 3 sec). The number of calls that make up a conversation varies from conversation to conversation and depends on how many users need to comment on the topic. At the end of a conversation, the system goes idle until the start of the next conversation. The idle time between conversations is typically longer than that between calls. We used the three-state semi-Markov model and statistical distributions identified in [8], as shown in Fig. 3. The conversation idle state (λconv_IDLE) represents the time intervals between conversations. The call idle state (λcall_IDLE) represents time intervals between calls within a conversation. The call channel hold time (λcall_CHT) represents the time that an individual call occupies the channel. In this model, a call in a conversation is followed by a short idle time and then another call 70% of the time. 30% of the time a call is followed by a longer idle time interval which ends the conversation. Probability distributions associated with the three states are summarized as follows. • Conversation Idle Time: A lognormal distribution with a time shift (≥ 3 sec) is used to model the conversation idle time. The actual distribution parameters are adjusted with respect to the normal traffic load of different talkgroups and traffic loading profile in each talkgroup, where the normal talkgroup load is retrieved from the July data log, and the traffic loading profile is designed to reflect the intensity of the traffic level. • Call Channel Holding Time: It is assumed that all calls last longer than 1 sec. For this reason, a lognormal distribution (μ=2.2, σ=0.5) with a 1-sec shift is used for call channel hold times. With this setting, the average call duration is 10 sec, and 50% of the call channel hold times are less than 10 sec. This is set according to the data analysis of the Fort Wayne radio system in Section III-C.

1

conv_IDLE

λ

0.3 Fig. 3.

1

λcall_CHT

λcall_IDLE

0.7

A three-state semi-Markov model [8].

• Call Idle Time: Call idle times are modeled using a gamma distribution. The parameters in [8] (shape parameter α=1.530391, rate parameter β=1.606532) are used. With this setting, the average interval between calls is roughly 2 sec. We consider a fire scenario that starts at 6:00 A.M. on a weekday and lasts for 3 hours. Based on the event timeline described in Section IV-A, the 28 talkgroups directly involved in the scenario are identified, as well as the time at which each talkgroup initiated its response to the emergency. This information is then used to develop a loading profile for each talkgroup, which defines how its traffic changes as the events in the scenario unfold. Fig. 4 shows the traffic loading profiles for two example talkgroups directly involved in the apartment fire scenario. The traffic load is referenced to the average random background traffic typically supported by each talkgroup. A time interval that shows 100% loading for a specific talkgroup indicates that only random background traffic is present. 200% loading indicates twice the level of daily random background traffic. We assume that as the traffic load increases, the internal characteristics of a conversation do not change, i.e., the same distribution parameters for call channel hold time and call idle time are used for different traffic load levels. Scaling of the traffic load in a talkgroup is achieved by adjusting the parameters that determine conversation idle time. 3) Combined Traffic Load To simulate the comprehensive traffic load associated with the apartment fire scenario, we combine the traffic load generated using the emergency response conversational model with the background traffic model. Since the background traffic loading for the Fort Wayne system is based only on summary traffic logs from July 2007. To address the uncertainty in predicting the traffic level that occurs during the actual scenario, we tested our system model under different load levels. Increasing intensities of traffic level is achieved by scaling the distribution parameters that determine conversation idle times. After consulting with Fort Wayne Fire Department and Police Department and other city officials, we selected three different traffic levels of 1, 10, and 20 times the baseline rates and traffic loading profiles, designated as “scenario_x1”, “scenario_x10”, and “scenario_x20”, respectively. Traffic loading profiles 700

talkgroup 1 talkgroup 2

600

500

traffic load (%)

1) Background Traffic Model The simulation model generates background traffic on 76 talkgroups, including 20 groups with the heaviest load, 32 groups that handle routine and less-routine traffic, and 28 groups directly involved in the scenario (i.e., those in Table I). Note that there are overlaps among the three talkgroup classes mentioned above. We assume that the traffic on the remaining groups is negligible.

400

300

200

100

0

6:00

6:30

7:00

7:30

8:00

8:30

time (AM)

Fig. 4.

Traffic loading profiles for two talkgroups.

9:00

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 2009 proceedings

V. SYSTEM PERFORMANCE This section presents the measurement metrics and performance evaluations using the system model with the anticipated traffic load for the apartment fire scenario. In responding to the apartment fire scenario, we evaluate the performance of the Fort Wayne emergency response system in terms of three metrics: channel utilization, channel access delay, and number of calls waiting. The simulation results are summarized in Table II and explained as follows. Channel utilization is the percentage of radio channels utilized to support the traffic load. On average, with only background traffic present, channel utilization varies from 5% to 35%, where 5% represents the control channel which is always active. During the emergency response scenario, channel utilization significantly increases as the traffic loading intensity increases from 1 to 20. At a traffic intensity level of x1, the peak channel utilization in the apartment fire response shows up as a brief increase to 55%. At traffic levels of x10 and x20, peak channel utilization reaches 65% and 85%, respectively. This data shows that even under intense loading the system capacity is sufficient to support the users. Channel access delay measures the amount of time taken for a user to access a channel from when he initiates a PPT button to the time he is granted channel access to talk. In the Fort Wayne system model, normally a unit will be granted access in less than 0.1 sec. However, when the system becomes busy and multiple units simultaneously try to access the control channel, their transmitted packets may collide at the base station receiver. When this happens, the units will retry their requests resulting in additional access delay. The simulation results show that mobile units periodically experience longer than normal access delays; but even under the heaviest traffic load these delays never exceed 1 sec. Under more intense traffic load like “scenario_x20”, users experience a higher frequency of longer access delays, but always under 1 sec. While a 1-sec access delay might be discernable to the user, it would certainly still be considered acceptable. Number of calls waiting records the number of units in a talkgroup waiting in a queue to access the channel. A call waiting indicates that a unit on a particular talkgroup wishes to talk but must wait until the talkgroup is clear of voice traffic from other users. Many of the talkgroups involved in the fire scenario do not experience any waiting calls. For these groups, the traffic load is low enough to permit a user to communicate at almost any time. During the height of the fire, a few talkgroups experience one or more calls waiting. In the worst case, one group has 5 calls waiting. This represents a serious operational problem since on average a call typically lasts 10 sec. With one call waiting in a talkgroup, a user may have to wait 10 sec or more. With 5 calls waiting, the delay to talk may be more than 50 sec for some users. In an emergency response scenario, these delays may be unacceptable. TABLE II

VI.

The purpose of this study was to develop a computer model of the Fort Wayne emergency response communications system and to evaluate the capability of this system to respond to a large-scale disaster. An emergency scenario involving a high-rise apartment fire is considered. A timeline of events is constructed, specifying the number of units that would participate from each authority and the utilization of talkgroups on the trunked radio system. Traffic models are developed to simulate both routine background traffic and the emergency scenario traffic load. The model was used to evaluate and predict the performance of the Fort Wayne public safety communications system under an apartment fire scenario. Simulation results show that the system provides adequate capacity even under intense traffic loading. One area of concern is the build-up of waiting calls in some heavily used talkgroups. Such issue may be alleviated by operational procedures that determine the number of users in a single talkgroup as well as procedures that offload users onto operational groups in an efficient manner. The computer model can be used to evaluate the Fort Wayne public safety communication system under other emergency response scenarios, given the timeline, talkgroups involved, and traffic loading profiles of talkgroups. The same simulation method can also be adapted for similar trunked radio systems of other cities. An extension of this work is to obtain detailed data record including call-by-call traffic under normal scenario and realworld emergency responses, so that more refined statistical analysis and parametric data fitting can be done. This will enhance the simulation model and further improve its accuracy to predict the performance of the communication system to support a large-scale disaster response. REFERENCES [1]

[2]

[3] [4]

[5]

[6]

[7]

SUMMARY OF PERFORMANCE RESULTS

Metric Channel utilization (average, peak) Channel access delay (peak, # of times > 0.1 sec) Number of calls waiting (in one heavy-loaded group)

Scenario_x1

Scenario_x10

19%

55%

21%

65%

24%

85%

0.18 sec

3

0.25 sec

3

0.52 sec

12

2

3

Scenario_x20

5

CONCLUSIONS

[8]

[9]

Y. Wang, et al., “Research and software development of TETRA & TETRAPOL network models for IP-based data services using OPNET,” in Proc. of OPNETWORK 2006, Washing D.C., Aug. - Sept. 2006. N. Cackov, J. Song, B. Vujičić, S. Vujičić, and L. Trajković, “Simulation and performance evaluation of a public safety wireless network: case study,” Simulation, vol. 81, iss. 8, Aug. 2005, pp.571585. APCO Project 25, http://www.apcointl.org/frequency/project25/. G. Hess and J. Cohn, “Communications load and delay in mobile trunked systems,” in Proc. of IEEE Vehicular Technology Conference, Washington D.C., April 1981, pp. 269-273. D. Sharp, N. Cackov, N. Lasković, Q. Shao, and L. Trajković, “Analysis of public safety traffic on trunked land mobile radio systems,” IEEE JSAC, vol. 22, no. 7, Sept. 2004, pp. 1197-1205. B. Vujičić, N. Cackov, S. Vujičić, and L. Trajković, “Modeling and charaterization of traffic in public safety wireless networks,” in Proc. of SPECTS 2005, Philadephia, PA, July 2005, pp. 214-223. N. Aschenbruck, M. Frank, and P. Martini, “Statistical analysis of traffic measurements in a disaster area scenario considering heavy load periods,” in Proc. of the Second International Workshop in Wireless Adhoc Networks (IWWAN 2005), London, UK. N. Aschenbruck, M . Gerharz, M. Frank, and P. Martini, “Modeling voice communication in disaster area scenarios,” in Proc. of IEEE Conference on Local Computer Networks (LCN 2006), pp. 211-220. OPNET Network Modeler 12.0, http://www.opnet.com.