Ready, set calculate!

If you’re involved in the design or support of land mobile radio systems, you’ve probably heard of the “three Cs”: coverage, capacity and cost.

Designers typically try to meet coverage requirements by strategically locating sites, optimally specifying and configuring antenna systems, and controlling transmit power and other technical parameters.

System capacity, or the ability of the system to carry user messages, involves quite a different approach.

Of course, improving system coverage or capacity (or both) almost always increases system cost.

Whether you’re evaluating a potential new trunked radio system, or operating an existing system, it’s important to understand the basics of trunked system capacity.

In effectively forecasting requirements, your goal should be to provide your sites with an adequate number of channels to support peak user load. This will avoid user complaints about “not getting through” or “excessive queuing” and also allow for future expansion of your wireless network. An overall understanding of traffic planning and capacity modeling can also help identify factors that contribute to capacity problems on an existing system.

Basic concepts

Land-mobile radio systems rely on the concept of trunking to accommodate a large number of users with a small number of radio channels. It’s similar to how a small number of telephone trunk lines connecting telephone central office switches can be shared by a large number of individual users.

System control logic differentiates various trunked system architectures. Two types of trunking include: dedicated control channel (centralized trunking) and subaudible signaling control (scan-based or decentralized trunking). Com-Net Ericsson’s EDACS and Motorola’s Smartnet systems use dedicated control channels. Systems using E.F. Johnson LTR technology use subaudible signaling.

In the dedicated control-channel architecture, when the user presses the push-to-talk button, his radio requests a traffic channel (or working channel) by sending a message on a control channel for the serving site. If all available traffic channels for this site are in use, the user is usually placed in a queue until a channel becomes available. In analyzing trunked system capacity, this queuing process is usually the limiting factor.

Trunking theory definitions

Trunking theory fundamentals are applied to capacity analysis using statistical tools created by A. K. Erlang, a 19th-century Danish mathematician. Today, the measure of traffic intensity bears his name.

One Erlang is defined as the amount of traffic intensity carried by a channel that is fully occupied. For example, a channel that is completely occupied for 15 minutes during an hour timeframe carries 0.25 Erlangs of traffic.

The grade of service is a common system benchmark that provides a measure of a system’s ability to provide a user access to a trunked system during the busiest hour. The term busy hour refers to an arbitrary period but is important because it provides a worst-case result. The actual “busy hour” depends on your particular use patterns over time. For example, an urban SMR operator may specify 5 p.m. to 6 p.m. on Fridays, while the busy hour for a natural gas company using a trunked LMR system may coincide with a 3:30 p.m.-4:30 p.m. shift change on the first Monday of the month.

Specifically, for trunked architectures that support queuing, the GOS represents the probability that any given call experiences a delay greater than a specified queue time. A typical system GOS requirement might be stated as follows: “We desire that no more than 2% of our user’s call requests, or PTTs, be delayed in a queue for longer than three seconds.”

Applying the theory

To create capacity estimates that ultimately determine the number of required channels to support a specified GOS, several performance characteristics need to be provided, as shown in Table 1 at the left.

When designing a new system, these parameters come from:

• estimates provided by mobile users or dispatchers.
• engineering studies or experiments to gather over-the-air statistics from an existing system.
• published industry studies.

The first step in applying trunking theory is to calculate the offered load per user — that is, how much traffic, in Erlangs, a given talk group or individual user service generates. Using the parameters defined in Table 1, the offered load per user, Au, is expressed as:

Au = f × H

As an example, assume a user’s average PTT duration, H, is five seconds, and each user, on average, PTTs 10 times during the busy hour. Note the extra term below that converts PTTs/hr to PTTs/s:

In this example, the user offers 0.0139 Erlangs of traffic to the system. Remember that one Erlang represents a fully occupied channel during busy hour, so this user, if he had his way, would require 1.39% of one channel’s capacity during a one-hour timeframe.

For a system that contains U users, the total offered load, A, is the number of users multiplied by the offered load per user:

A = U × Au

Assume the example system is a single-site trunked system with 100 users during the busy hour, so the total offered load, A, is simply 1.39 Erlangs. Based on the definition of an Erlang, one could easily (and incorrectly) assume that at least two traffic channels would support the offered load.

But recall that one Erlang is a completely filled channel; it’s unrealistic to have competing users completely occupy a channel. Doing so would require every user to PTT every instant a channel becomes available.

To determine a more realistic channel requirement to support the offered load, an Erlang formula or table is typically used for trunking systems.

The Erlang-C model

In the Erlang-C trunking model, or blocked calls delayed, a queue is provided to hold calls that are blocked. When a channel resource is not immediately available, the PTT request may be delayed until one becomes available. The GOS for this model represents the likelihood that a call would be delayed after waiting a specific time in the queue.

To determine the GOS, two calculations are needed. The first is the probability that a call will be delayed, which is derived from the following Erlang-C formula:

The second formula provides the probability that, once the call is in a queue, the delay will be t seconds:

The GOS is merely the product of the Erlang-C probability and the conditional probability, QDelay, of exceeding a delay of t seconds:

GOS = ErC × QDelay

Computer programs can readily compute these formulas. To help make capacity analysis easy, I have implemented these calculations into a Microsoft Excel spreadsheet that you can request by email from MRT (email: [email protected]). It makes use of Excel’s built-in Poisson function, the underlying basis for the Erlang models.

It should be noted that an Erlang-B model also exists to calculate the probability that a blocked call would be dropped. This formula should be used when trunking systems do not use a queue.

Bringing it all together

In the preceding example, a set of 100 users presented a total offered load of 1.39 Erlangs. Assuming the GOS requirement restricts a maximum of 2% of calls to be delayed in a queue for longer than three seconds, the simple calculator portion of the spreadsheet can be used to specify the input parameters (H = 5s and t = 3s) as well as U and f:

The spreadsheet calculates the offered load and the corresponding GOS for a range of systems having one to 10 channels. The results, shown below, show that, to meet a 2% GOS requirement, four traffic channels are required:

Assumptions

The preceding example, as capacity planning does in general, makes several assumptions. The Erlang models were designed with the assumption that call arrivals will follow what’s known as a Poisson distribution. A random process characterizes this type of distribution and requires that the times between successive events (or PTTs) be exponentially distributed.

Another key requirement in modeling traffic behavior is to determine an average call transmission length. Statistics gathered from an FCC study (under contract RC10056) support five seconds as a reasonable average transmission length. Your actual average may vary depending on user needs and the actual mix of voice, data and interconnect calls.

One point to remember about traffic analysis, as in many disciplines, is that the results you obtain are estimates of the assumptions that you’ve provided. The “answer” can only be as good as your assumptions. The more detailed your investigations are to acquire the input parameters, the more accurate your results will be.

Modeling a wide-area system

Estimating capacity for a wide-area trunked system requires special consideration. Several complex, and debatable, factors contribute to user load.

Your initial task should be to determine the quantity of users (whether mobile, portable or fixed) and their anticipated operational service area. For many systems, this can become subjective.

For each system talk group, estimate the number of users, and determine a reasonable estimate for the average call duration, H, and the anticipated number of PTTs per user, f, during the busy hour. The wide-area spreadsheet calculator includes an example, shown in Table 2 on page 48, that lists six such talk group sets for electric and gas divisions in three counties (Oakland, Macomb, and Wayne). The spreadsheet calculates the offered load, A, for each talk group set.

The example analysis is for a fictitious five-site trunked system and includes the Pontiac, Northville, Macomb, Armada, and Howell sites. Under each site in the spreadsheet is a cell to distribute the offered load, as a percentage, from a given source to each individual site.

Talk groups deserve special consideration when analyzing capacity. This is because, unlike in cellular, users of trunked system talk groups can load a site with traffic even if they’re just “logged-in” and listening.

The spreadsheet distribution percentages, then, reflect the probability that at least one user will log into that particular site and bring with it the corresponding traffic load of all talk group users for the entire busy hour. Be certain to take overlapping coverage into consideration; neighboring sites will almost always receive a portion of each other’s traffic.

Other types of calls that typically load a trunked system include data, individual and private calls, and telephone interconnect calls. The example in Table 2 includes private call users, interconnect users and data users, who are assumed to be equally distributed throughout the system.

Finally, the spreadsheet sums the offered load for each site to determine the site’s total offered load. Table 3, as shown on page 50, then presents a GOS matrix, calculated from the ErC and QDelay equations, for the maximum acceptable queue delay, t, of three seconds.

From the table, we can conclude that to meet or exceed a 2% GOS, there should be six traffic channels at Pontiac and Northville, five at Macomb and Howell, and four at the Armada site.

Other considerations

Exploring the specifics of your trunked technology (EDACS, Smartnet, MPT-1327 or LTR) may help you to understand how the spreadsheet calculator can be customized for the services and traffic sources of your particular system.

Some areas that require further work to provide a more thorough analysis may include:

• factoring-in call setup time (typically between 250ms and 400ms).
• considering hang time (if used).
• providing data calls to be specified in terms of individual application messages or bytes.
• addressing application-specific packet and network-layer data overhead.

This analysis does not account for two main aspects of capacity. One is that, in dedicated control channel systems, the carrier-sense multiple-access scheme for the control channel itself can limit capacity. The second factor involves the blocking probabilities of central switching and network equipment. Usually, however, unless you’re dealing with a large system, user load itself vs. the available channels is the major concern.

Gutowski is senior RF engineer at Consumers Energy Company in Jackson, MI. He can be reached by email at: [email protected]