public safety trunk system capacity planning and … · 2015. 7. 7. · capacity calculator...

1 I Confidential/ Proprietary 1 I Confidential/ Proprietary

PUBLIC SAFETY TRUNK SYSTEM CAPACITY PLANNING AND FLEET MAPPING FOR GRADE OF SERVICE Dimensioning P25 Phase 1 & 2 Voice Systems using Erlang-C Model

A vendor-neutral look at:

• How to specify the right number of Talk Paths and RF channels for your new P25 trunk system

• Size limits for system Talk Groups in your fleet map

• Procedures planning for extraordinary events that threaten to overload your system

David Cann / Sr. Systems Engineer / Systems Bids & Proposals

Radio Club of America Technical Symposium November 22,2014

2 I Confidential/ Proprietary

Definition:

“Dimensioning” of the system is a term used to mean:

How many talk paths are needed, and how many RF channels must be provided?


Who should take responsibility for dimensioning a new trunk system?

Trunk system dimensioning is mainly a function of the owner’s

estimate of his current and future system demand.

Dimensioning is essentially independent of vendor equipment design. Given a design case that specifies the number of system active users, calls per hour, and average call duration -- all vendor’s capacity studies should deliver the same result.

Owners (with their consultants) should probably take ownership of system dimensioning since it depends on system load estimates that are not controlled by the vendor.


Plan for routine “busy hour”, worst-case mutual aid incident, or for Hurricane Katrina?

• None of us want to be caught short of system resources in an emergency situation, although trunk systems when overloaded usually just slow down rather than crashing.

• Dimensioning a system requires estimating the number of active users in some super-busy hour, the average number of call requests from users during that hour, and the average call duration.

• In the past, many public safety trunk systems were dimensioned for a routine “busy hour”, sometimes defined by reviewing system management reports from a legacy trunk system. This is useful for estimating call requests/user and average call duration, less so for estimating the number of active users.

• Suggestions for Active Users estimate:

•

•


Definition of terms used in Dimensioning Talk Path: The virtual connection through the trunk system and repeater channels that establishes an audio path between terminals (consoles, subscribers, call recorder). Sometimes called “Voice Path”.

Active User: A system user equipped with one subscriber radio who is communicating using the trunk radio system during a busy hour

Call: For this discussion a Call = Call Request = one PTT transaction

User Call Rate: Average number of calls per user during busy hour

Call Duration: Sum of user PTT time, call setup time (approximately 1/2 second), and call setup hang time, if any.

Allowable Delay: Maximum time in seconds for calls to be assigned talk path resources and given “go ahead” beep. Usually 2.0 seconds.

Grade of Service: Percentage of calls that are queued longer than the allowable delay. LMR trunk systems are normally designed for 1% GOS. That is, 99% of calls are handled in less than the allowable delay time.


Three-step Procedure:

1. Determine the System Load Estimate to be used for dimensioning

Estimate busy-hour Active Users (typically about 30%-50% of owned radios)

Estimate busy-hour User Call Rate (typically 3-5 Calls/Hr)

Estimate busy-hour Call Duration (typically 3-8 seconds/Call), the sum of PTT time and Hang time , if any. PTT time includes approximately 1/2 second for call setup time

Calculate System Load in Erlangs

2. Specify desired P25 trunk system performance

Specify Allowable Delay (usually 2.0 seconds, occasionally 1.0 second)

Specify desired Grade of Service (usually 1%, occasionally 2%)

3. Calculate the number of talk paths and RF channels needed using

graphical or calculator tool methods


System Load Estimate in Erlang Units

System Load = Active Users x Call Rate x Call Duration /3600

Example

One Erlang is equivalent to one talk path that is 100% busy during one hour.

Notice that system dimensioning is not an exact science. System load is the product of three estimates, or guesses.


Erlang-C Probability Calculations

Modern LMR trunk systems are queuing systems so the Erlang-C probability

model is commonly used to estimate PD the probability of delay before service

of a call request, and P(W>W0) the probability that a call delay exceeds the

allowable waiting time:

These equations characterize the probability of call arrival as a Poisson

distribution, or bell-shape curve , which is another approximation.


Solving for N, the number of needed talk paths

Because these equations are difficult to solve for N, The calculations for PD and GOS are usually performed iteratively for the range of N talk paths to be considered. There are two practical methods for solution:

(1) Graphical Solution

(2) Capacity Calculator tool.

Examples of both methods are shown below.


Graphical Solution 3-20 Talk Paths (easy but not very precise)

Erlangs = Active Users x User Call Rate x Average Call Duration/3600


Capacity Calculator Solution

System capacity can be more

precisely modeled using a

Capacity Calculator tool to ease

the calculation work.

EFJohnson’s Trunk System

Channel Capacity Planner tool

delivers Erlang, GOS, average

call delay predictions, and talk

path duty cycle for a range of

talk path options.

Enter the system variables

shown in red. The tool will

return a range of results, with

the rows around 1% Grade of

Service highlighted in green.


P25 ID Trunking vs. Message Trunking (Impact of Hang Time Specification)

Trunk systems can be configured for P25 ID Trunking (call setup hang time = 0) or for Message Trunking (call setup hang time = several seconds).

In P25 ID trunking, each call is individually set up with allocated system resources so each call request will see an approximately ½-second delay before the “go-ahead” beep. P25 ID trunking will maximize busy-hour system capacity and will minimize system cost.

Configuring the system for message trunking with several seconds hang time on each call setup allows rapid exchanges on a talk group to be accomplished without individual setup delays for each call -- the call setup (talk path setup) is held for them until the hang timer times out.

Message trunking will slightly improve the system responsiveness as perceived by the user. However, calculation of the required number of busy-hour talk paths (and therefore system cost) is very sensitive to hang time, since it has a large effect on the system load in Erlangs.

Most trunk system designs allow setting hang time by talk group so you can set hang time into some talk groups (Police & Fire Dispatch, for example) but not all.


Example with/without Hang Time on all Talk Groups

P25 ID Trunking Message Trunking with Hang Time on all Talk Groups


Why worry about Fleet Mapping and Talk Groups?

The Erlang-C probability model assumes that all users have equal access to talk path resources. However:

Users in the field perceive the system as a single “channel”, the talk group selected on their radio.

If too many users are assigned to a talk group, they will not all be able to access their talk group in 3600 seconds, and they will complain that the system is overloaded. Meanwhile, other system talk paths may go unused.

Simple formulas:

Max TG Size = 3600 / (Call Rate)(Call Duration)

Min Number of Talk Groups = Active Users / Max TG Size


Procedures Planning for System Overload To a point, trunking systems can cope with some increase in the number of call requests above the busy hour predictions used for capacity planning -- users may notice slightly longer wait times for a “go-ahead” beep, but the system will otherwise operate normally.

Beyond that point, the problem and solution will generally be one of the following:

A. Talk group(s) overloaded: One or more talk groups may experience more call requests than can be accommodated. Users will complain that the system is too busy and they “can’t get the channel”.

The procedural solution to this problem is for dispatchers to move some users to special “incident” talk groups that are not overloaded, or to on-scene simplex channels.

B. Way too many active users: All talk groups may experience a deterioration in grade of service as evidenced by unacceptable queue times for all subscriber call requests.

One solution to this problem is to temporarily constrain call volume by reducing the number of active talk groups using console talk group patching or built-in system tools (next slide). This solution may create some talk group overload (as described in A above) but will facilitate communication by other talk groups.


System Tools for Overload Planning

EFJohnson and other trunk system manufacturers provide system management tools, for example:

•

•

•

These tools enable merging of many less-active talk groups into fewer (more heavily populated) dispatch talk groups for the duration of an incident or event.

Using the EFJohnson StarGate® console, Group/Regroup can be invoked easily by dispatchers using standard console patching controls and is probably the easiest technique to manage sudden extraordinary increases in system demand.


EF Johnson Capacity Planner posted on website

The Trunk System Channel Capacity Planner tool is posted on the EF Johnson website. You will be asked to register before downloading.

The posted version 8 includes data entry for P25 GPS functionality. [Beta]

Direct Link is:

http://go.efjohnson.com/systemdesign


Summary and Key Points • Coverage studies are used to determine how many sites are needed for a system;

capacity studies identify the dimensions (talk paths and RF channels) that are needed at each site.

• Owners must decide on the busy-hour scenario to be used for system dimensioning. Dimensioning is very dependent upon the owner’s estimate of busy-hour system load –active users, call rate, and call duration.

• Dimensioning is not an exact science; capacity studies are inherently approximate.

• Calculating system load in Erlangs is easy but the Erlang-C equations are messy so we use graphical or calculator tool methods.

• Message trunking configuration is seductive, but should be used carefully since it can drive up system costs.

• Fleet mapping of users into assigned talk groups should recognize talk group size limits

• System overload during an incident should not cause a system crash but may cause noticeable slow down in “go-ahead” beeps.


Questions?

David Cann, Senior Systems Engineer E.F. Johnson Technologies 1440 Corporate Drive Irving TX 75038

Office 972-819-0700 [email protected]

http://www.efjohnson.com/

mailto:[email protected]

public safety trunk system capacity planning and … · 2015. 7. 7. · capacity calculator...

Documents