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
1 I Confidential/ Proprietary
November 22,2014
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?
2 I Confidential/ Proprietary
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.
3 I Confidential/ Proprietary
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:
•
•
4 I Confidential/ Proprietary
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.
5 I Confidential/ Proprietary
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.
3.
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%)
Calculate the number of talk paths and RF channels needed using
graphical or calculator tool methods
6 I Confidential/ Proprietary
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.
7 I Confidential/ Proprietary
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.
8 I Confidential/ Proprietary
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.
9 I Confidential/ Proprietary
Graphical Solution 3-20 Talk Paths
(easy but not very precise)
Erlangs = Active Users x User Call Rate x Average Call Duration/3600
10 I Confidential/ Proprietary
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.
11 I Confidential/ Proprietary
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.
12 I Confidential/ Proprietary
Example with/without Hang Time on all Talk Groups
P25 ID Trunking
13 I Confidential/ Proprietary
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
14 I Confidential/ Proprietary
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 onscene 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.
15 I Confidential/ Proprietary
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.
16 I Confidential/ Proprietary
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
17 I Confidential/ Proprietary
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 busyhour 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.
18 I Confidential/ Proprietary
Questions?
David Cann, Senior Systems Engineer
E.F. Johnson Technologies
1440 Corporate Drive
Irving TX 75038
19 I Confidential/ Proprietary
Office 972-819-0700
Dcann@EFJI.com