The ins and outs of traffic engineering

Let’s start with a little quiz: Rocky Mountain Radio Co. operates three community repeaters, one for each of its three customers: Poudre Plumbing, Monument Mudjacking and Castle Concrete. Poudre and Monument have complained about a high rate of blocked calls during their respective busy hours. Rocky Mountain’s owner, Rick Salazar, pulled two weeks of call records on the three companies, the results of which are defined in Table 1.

Call-seconds are the average number of seconds the repeater is occupied during the busy hour. (There are 3600 seconds in one hour.) Because these customers operate exclusively during weekdays, Rick excluded the call data from the weekends.

Rick figured his only option was to acquire another frequency pair each for Poudre and Monument and ask these customers to somehow split their radio users into two smaller groups. He knew this solution would be unpopular because both companies employ a single dispatch channel, and the owners were fond of monitoring the radio channel. He also was worried that if Castle discovered their blocked call rate was 20%, they might start complaining, too.

Rick’s radio salesman offered to solve this problem by selling Rocky Mountain a trunked radio system. The salesman said he could reduce the blocked call rate to below 10% without additional radio channels. Rick was skeptical.

What should Rick do?

a. Try to get more channels. The salesman just wants to sell expensive equipment to pay for his swimming pool.

b. Ask the customers to schedule non-essential calls for periods before and after the busy hour.

c. Buy the trunked radio system.

The correct answer is (c). Why? Because the salesman knew the efficiency created by a trunked radio system (i.e., the “trunking efficiency”) would eliminate the need for more channels.

We’ll get to the math in a moment, but for now, let’s appeal to the reader’s intuition: Let’s say the trunked radio system employs one control channel and two traffic channels. Today, blocking occurs whenever two or more users attempt to access the repeater simultaneously. The probability of this event is relatively high, but with the trunked system, blocking occurs only when three or more users attempt to access the trunked system simultaneously. Even with three customers sharing two channels, the probability of blocking is reduced to less than 20%. (We’ll prove this result shortly.)

For such a small system, an alternative approach would be to employ a trunking protocol that uses overhead on each traffic channel for control signals rather than dedicate an entire radio channel for this purpose. Such a system would reduce blocking further, to less than 10% (as the salesman claimed).

Now for the math:

Traffic engineering predates land mobile radio and first was applied to telephone systems in the early 20th century by the father of tele-traffic theory, Agner Erlang (1878-1929).

Erlang graduated from the University of Copenhagen in 1901 with a degree in mathematics and taught school for several years before joining the Copenhagen Telephone Co. in 1908. There he began to apply probability theory to various telephone switching problems. He published his first paper on these problems, titled “The Theory of Probability and Telephone Conversations,” in 1909. In 1917, he published a formula for call blocking and waiting time that soon was used by telephone companies worldwide, including the British Post Office and AT&T.

The most widely accepted traffic model for mobile radio is the multiserver loss system, also called the Erlang loss system in honor of its founder. Under this model, voice users arrive at the switch according to a Poisson random process with rate λ. There are m servers (channels), each with independent, identically distributed service times. Arrivals who find all m servers busy are turned away and lost to the system. (They get a busy signal.) No queuing of arrivals is allowed. Service times (call durations) are exponentially distributed with mean 1/µ.

For an m server system, the probability that k servers are busy is given by Equation 1 on page 44. Note that Equation 1 is a function of the ratio λ/µ. This quantity is called the offered traffic, and although unitless, it is measured in Erlangs. Think of the offered traffic as the mean number of users who request service during some busy hour.

The mean number of busy servers is given by Equation 2, where P_m is the probability that m servers are busy. The probability P_m is known also as the blocking probability, P_b.

Now let’s apply Equations 1 and 2 to our previous example from the Rocky Mountain Radio Co. The offered traffic, λ/µ, is found for each customer by solving Equation 2 with the mean number of busy channels, E[K], equal to the ratio of call-seconds — as defined in Table 1 — to 3600.

Next, we will sum the offered traffic from the three customers and compute the probability of blocking for our hypothetical three-channel trunked radio system. First, we need to know the total offered traffic for a common busy hour. Poudre and Castle have the same busy hour (0800-0900), but Monument’s busy hour is different (1000-1100). Rick looked at the traffic data again and found the busiest hour for the sum of the three customers was in fact 0800-0900, but during this hour, Monument Mudjacking had just 513 call seconds with a blocking rate of 14.5%. From Equation 2, the offered traffic in this case is 0.17 Erlangs. The total offered traffic for the system-wide busy hour is (1500+600+900)/3600 = 0.83 Erlangs.

Using an offered traffic of 0.83 Erlangs and m=2 (the third channel is the control channel) in Equation 1, we get a probability of blocked calls of 16%. Not great, but an improvement nonetheless. If we employed a more efficient trunking protocol that used overhead on the traffic channel for control signaling rather than a dedicated control channel, we might increase the overall offered traffic to 1.0 Erlang, but the number of traffic channels would increase to m=3. In this case, Equation 1 gives a blocking probability of just 6.3%.

An Erlang C system is similar to Erlang B, but an Erlang C system allows queuing of incoming calls to reduce or eliminate the probability of blocking. Of course, the tradeoff is longer wait time. The Erlang C formula [1] computes the probability that a user will enter the queue as opposed to being blocked. In fact, as long as the queue size is sufficiently large, the probability of blocking is negligible.

In queuing systems, the two most important parameters are the probability of entering the queue (versus being served immediately) and the mean wait time in the queue. For a given offered traffic and number of servers, the probability of entering the queue is always higher than the probability of being blocked on an equivalent Erlang B system.

Queuing presents some implementation problems. In practice, many users cannot distinguish between a queue tone and a no-service tone, so they typically un-key the radio and must key again anyway. In this case, resources are tied up during queuing and the network might perform better without queuing. Another complication is that some users have priority queuing, making the analysis more difficult.

Jay Jacobsmeyer is president of Pericle Communications Co., a consulting engineering firm located in Colorado Springs, Colo. He holds bachelor’s and master’s degrees in Electrical Engineering from Virginia Tech and Cornell University, respectively, and has more than 20 years experience as a radio frequency engineer.

References:

1. Bell Labs, Engineering and Operations in the Bell System, AT&T, 1977.

2. D.R. Cox and W.L. Smith, Queues, London; Chapman and Hall, 1961.