Goeller on Telecom Traffic

A First Course in
Telephone Traffic Engineering

Big tie-trunk networks were generated by TELPAK, a method of bulk rental of facilities, invented by AT&T to produce economies of scale and economical as well as efficient use of the spectrum required by microwave radio. TELPAK, after a number of years, was killed by the FCC because it gave large users of telecommunication services a bargain that was not available to small users, and, further, it appeared to be subsidized by other parts of telephony, presumably enabling AT&T to provide unfair competition to those who wanted to sell private microwave systems to large business customers. Whatever the ideological advantages or disadvantages of TELPAK, it got many large users started on private voice networking.

Dial tandem networks came first, using the infinitely flexible, infinitely fast Step-by-Step equipment. By simply adding switches to existing PBXs, tie trunks could access each other, usually on a non-blocking basis, and connect to local extensions. A limited version of automatic alternate routing, using a technique called digit absorbing, added further flexibility. With the coming of more modern PBXs using such wonders as stored program control, trunk to trunk connections could not be accommodated, and CCSA networks were developed. CCSA stood for Common Control Switching Arrangement, and central office equipment was used to make tie-trunk to tie-trunk connections. The switching equipment itself was vastly more expensive than SXS and, in addition, the user had to rent expensive new facilities to get from his PBXs to the switching hubs.

CCSA was based on the No. 5 Crossbar System, the last of the big electromechanical switches developed by Bell Labs. Because No. 5 was designed to handle residential customers and not high occupancy tie-trunks for business customers, it left something to be desired. No. 1 ESS, a later Bell Labs development, was then pressed into service for tie trunk switching and EPSCS, or Enhanced Private Switch Communication Service, at even higher cost, came into being. Although EPSCS can provide 4-wire tie-trunk switching and rather good management and traffic reports, it is still based on separate tie-trunk switching machines, with expensive access lines from all PBXs using the system.

An alternate AT&T service is ETN, electronic tandem networking, based on the Dimension 2000. Here the tandem switch can also be a major PBX, eliminating much of the access line cost, but the Dimension is a 2-wire system, and the Dimension 2000 has some matrix design features that may make for difficulty in high-traffic environments. System 85 may ultimately improve this. Interconnected PBXs of the line-group and group-selector pattern, such as the Northern Telecom SL-1 and SL-100, the Nippon Electric NEAX 22, the GTD 4600, the Stromberg Carlson, Intecom, and Mitel SX-2000 also appear to offer certain advantages as combined tandem switches and PBXs. They are all 4-wire internally, and they can handle two levels of traffic density: local extensions with concentration, and high-usage facilities on an essentially non-blocking basis.

With all these options available, it is ironic that tie-trunk networks are very hard to prove in economically. The cost of tie-trunks from AT&T is quite high, and the terrestrial SCCs are making so much money using their circuits in their own networks that they are reluctant to offer them to others. Some of the satellite carriers will sell tie-trunk circuits at a bargain rate, but, generally, it is hard to get tie-trunks inexpensively enough to make them cost-effective. With large groups, you get good loading; a tie-trunk is a full period circuit, and the more you use it, the cheaper it gets per minute of use. Thus big systems at least have a chance.

One further problem, of recent origin, it the greatly increased cost of short-haul and local tie-trunks, necessary to provide centralized access to long-haul circuits from a centralized switch. To help offset the cost of these necessary circuits, a complete network design will of necessity, have to consider savings from centralized attendant service (CAS), etc.

Designing a tie-trunk network is not particularly hard if you have the necessary information. But getting that information, and putting it in useful form, is almost impossible. You have to know point-to-point traffic from each PBX to each other PBX in the system. For 50 or 60 such nodes, this is a lot of data to acquire. Toll bills are a good place to start; obviously, all bills should cover the same time period but there is no law that says that the billing date for each location will be the same. Thus it may be necessary to obtain special measurements, a costly and time-consuming business.

When collecting raw data, toll, WATS and specialized carrier bills from each location to be on the network, preferably in machine readable form, make a considerable pile of information. Although these bills (with the exception of 800 Service) are for outgoing calls only, they also allow us to find incoming traffic from other network locations, as we will see. What we will do is sort outgoing calls from each location, selecting for study only those calls that go to other locations that will be on the network. When called locations are served by Centrex or DID, we usually pick out the area and office codes, and do not sort by directory number as we would for standard PBX service. A second batch of data that a good computer sort can produce is call information to off-net regions around each called network location. If collected, this information should be stored separately.

For a 20 node network, a 20x20 matrix will result when all the out-going calls from each node to all other nodes are arranged line by line. When we add off-net traffic, we get a 20x40 matrix. Each line in such a matrix represents monthly traffic (calls, hours or whatever) from each location to each other location, on net and, separately, off net. A subtotal for on and off-net traffic, plus a grand total, shows the amount of network traffic each node can generate. When we add across, total originating network traffic is at the right-hand side of the matrix.

Because this should be done on a computer, perhaps using something like VisiCalc or SuperCalc, and computers like to add things, one also adds down each column as well as along each row. The totals at the bottom of each column are, surprise!, the terminating traffic, on-net and off-net to each node. This still seems like magic to me.

A new matrix, combining like cells of on- and off-net traffic to get total traffic can be formed next. Looking at this combined matrix, we see another surprising thing: there is a diagonal of cells, from upper left to lower right, that is blank. Mathematicians call such cells the "principal diagonal;" the reason we find our principal diagonal blank is that we will not use tie-trunks for any location to call itself. However, if we use the principal diagonal as a mirror and add together cells on opposite sides, we will get the two-way traffic between specific pairs of locations. Because there is no point in showing two-way traffic twice, we only keep the upper right hand part of the matrix, a large triangle which illustrates a somewhat more compact view of our network calling.

In laying out a matrix of this sort, it helps to group the nodes geographically. The first six rows and columns might contain the southern California locations, while the next four might handle those in the Bay Area. Locations in the Denver area might come next, followed by the locations in Texas, Chicago, Atlanta and New York. In many networks, there is more traffic within a given geographical area than there is among areas. Further, many nodes will have virtually no community of interest with others, whether for geographical or other reasons. If our matrix is arranged properly, we can see these patterns immediately just by looking. Further, in each geographical area we will usually find one location that originates and terminates a great deal more traffic than the other nodes. It may be a regional or national headquarters, a major factory, or some such. But it is obviously a focal point. And such locations lead us to the first actual stage of our design effort.

It is obviously possible to use our matrix to design trunk groups between all possible pairs of nodes, but that would be madness. For N nodes, we would have up to N*(N-1)/2 groups, most quite small and uneconomical. A much better approach is to pick out our major nodes in each geographical region, and use them as hubs for switching connections among other nodes. The first requirement of a hub is that it be a major source and destination of network calls; then, if we have several choices in a given area, we choose the one that originates and terminates the most traffic from geographically adjacent nodes, trading this off against originating and terminating traffic to station users at other tentatively selected hubs.

We have to be careful here. If we have many hubs, the average distance from hubs to nodes will be lower, but the trunking among the hubs, because there are more hubs, will tend to be greater. Further, for reasons of transmission, we want to try to limit most of our connections to three trunks in tandem: access trunk, inter-tandem trunk, access trunk. We want to minimize the need for connections between inter-tandem trunks. This suggests that a small number of hubs is desirable.

After selecting our hubs, we have to use our data to make a new matrix based on the hubs alone. Each node is homed on the appropriate (usually nearest) hub, and all its network traffic is assumed, for the time being, to go through the hub. What we want now is a new matrix that assumes that each hub originates all its own traffic plus all the traffic originated by its connected nodes. Then we sort on the basis of the traffic from each hub to (and via) each of the other hubs. Once again we end up with a pair of rectangular matrices, one for on-net and one for off-net traffic, but now our matrices are much smaller. Fig. 8-1a and b are an example: they are 5 by 5, plus subtotals and totals.

The first thing we note in Fig. 8-1 is that there are no longer blanks on the principal diagonals. We have numbers there. What are they? They are composed of two parts: two way traffic between each node and its hub, and traffic from one node to another via the hub. The node-hub traffic uses a single access trunk, while node-node traffic uses only two; neither type of call uses intertandem trunks and must, as a result, be left out of long-haul trunk calculations. Traffic off the principal diagonal is, of course, traffic from each hub and its nodes to the other hubs, their nodes and, in the second matrix, to off-net areas.

Again we can add the on-net and off-net long haul traffic (omitting the local traffic on the principal diagonal) to get the traffic among the several nodes, as shown in Fig. 8-2, and then add across the principal diagonal to get the two-way traffic between each pair of hubs (Fig. 8-3). Obviously, the more traffic we make local and handle to and through a single hub, the less traffic we will have for the inter-tandem trunk groups between hubs.

If we connect all five hubs with direct trunk groups, we will have 10 groups (N*(N-1)/2), some almost certainly handling appreciably less traffic than others. What we want to do is see if we can eliminate the lightly used trunk groups by routing their traffic through other hubs.

A possible approach suggests we should try having a tree-type connection between hubs so that there are no loops we can traverse and there is only one route between any two hubs. We can handle this quite easily with a "measle diagram." What we do is get a map and put a spot on the map for each hub. Then, we construct a "minimum spanning tree." This will be a line that connects all the hubs and uses up the minimum pencil lead. That is, it will be the shortest path interconnecting the hubs.

Here's how we build a minimum spanning tree. We start with any hub, and connect it to its nearest neighbor (use a compass, and swing it in a circle around the selected hub and through the one that looks to be the nearest. If any other hub is inside the circle, we know our first choice was wrong. Now, we look for a third hub, the one that is nearest to either hub 1 or hub 2. Our compass will again help out. With the third hub found, we connect it, so that three hubs are tied together with lines we know are the shortest. We keep looking for the next hub that is the minimum distance from one of the hubs we have already selected, and we soon have our minimum spanning tree.

Using a map and compass gives us a feel for distances, but we can also do the job with MINTREE on our computer. We need the "V & H" coordinates of our hubs; V and H stand for Vertical and Horizontal, and if one knows the coordinates of two locations, the distance between them can easily be calculated. Representative V and H coordinates for major cities are included in Appendix II. MINTREE asks first for the number of nodes (or hubs, as we have been calling them), and then the V&H coordinates of each. Let's use New York, Atlanta, Chicago, Los Angeles and San Francisco as nodes 1 through 5 respectively, as in Figs. 8-1,2 and 3. We enter for each a four-digit number pair, separated by a comma (see Printout 8-1). For New York, this would be 4997, 1406.

After receiving the last V&H, MINTREE immediately calculates the distance between each pair of nodes and presents its results in a matrix. The next screen selects the minimum spanning tree. We see that it will connect New York to Chicago, Chicago to Atlanta and Los Angeles, and Los Angeles to San Francisco.

We now actually have our whole network connected together. The nodes are all tied to the nearest hub, and the hubs are interconnected by a minimum spanning tree. But do we want to use this network? Probably not. There is no reason to assume that geographical propinquity defines inter-hub community of interest. We have to consider not only distance, but also the amounts of traffic involved. What we do now is construct a "maximum spanning tree," using not distance, but quantity of traffic between hubs. Let's run MAXTREE with the values in Fig. 8-3. Again, the program asks for the number of nodes and then for the two-way traffic between each pair. When the data is entered, it duplicates Fig. 8-3. (See Printout 8-2). The next screen shows the heaviest traffic routes. New York's heaviest traffic is with Atlanta and San Francisco, and San Francisco has the next heaviest routes to Los Angeles and Chicago; we now have a tree of the heaviest routes connecting all our hubs. Fig. 8-4 shows the minimum distance in solid lines while the maximum traffic is shown dashed.

When we are lucky, we find one hub acting as sort of a super-hub, with dashed lines to most of the other hubs. If we are even luckier, it is geographically centralized to minimize trunk distances which affect directly trunk costs. In the present example, however, we see that Chicago is not a major center while New York and San Francisco, with heavy traffic between them, are. Thus the minimum distance routes, from Los Angeles to Chicago and from Chicago to Atlanta and New York, are ignored for the moment, and we have a first cut network among the five nodes: LA and Chicago homed on Francisco, Atlanta homed on New York, and New York and San Francisco connected together.

For transmission reasons, completely unrelated to traffic theory, we know that we will find routing even the small amounts of Chicago-New York traffic via San Francisco to be highly undesirable, and going "around the horn" from Atlanta to New York to San Francisco to Los Angeles to be equally poor. Even worse, routing the relatively large Atlanta-Chicago traffic around the horn will be impossible. It is evident that transmission will force us to home Chicago on both San Francisco and New York. Now we have a rational starting point for our network design.

To finish up, we need to estimate the traffic on each trunk group. For example, on the Atlanta-New York route, the entire Atlanta traffic is included. For New York-Chicago, we have the sum of Atlanta's and New York's Chicago traffic. The Los Angeles-San Francisco group will carry the entire LA traffic with the rest of the network, and the Chicago-San Francisco group will handle the traffic between Chicago and the two west coast locations. Finally, the New York-San Francisco group will carry the east-west traffic excluding the special case of Chicago. Fig. 8-5 summarizes.

For a first cut at sizing access-trunk groups from nodes to hubs, we can take each node's monthly traffic, divide by 132 to get busy hour traffic, and use ERL-B. When we find the number of access trunks, we can multiply by the cost to find this portion of the total network cost. We should also estimate cost per minute for each group. Short-haul trunk costs are going up rapidly, and this item of cost may blow us out of the water.

We price out the inter-tandem trunks between nodes in pretty much the same way. But we may wish to use POISSON rather than ERL-B. With ERL-B, a grade of service of B.05 is probably about right, but with POISSON, if the hub switches are able to hold a call for 15 seconds or so when all trunks are busy, in the hope that one will come free, we can use D2 at 15 seconds or a little less as our Grade of Service rather than P1. This should get slightly better occupancy without too many of the troubles involved with queuing on 2-way facilities.

We want the access trunks to have a somewhat better grade of service than the inter-tandem trunks so that we will minimize the number of times we tie up a tandem connection non-productively by not being able to complete a call to the called PBX. However, the increasing cost of local short-haul trunks sometimes makes this an expensive procedure.

Our first cut at the network is now complete, and we have some idea of the cost per minute on each trunk group. The actual cost per call is the sum of the cost on each trunk in the connection. If we come from one node to a hub, go to another hub, and then connect to the terminating node, we have the costs of the three trunks to add, plus the cost for switching at each of the two hubs. Even with high occupancies brought about by building up our group sizes, this cost may be formidable.

We may, as a result, wish to refine our design by adding additional direct trunk groups. These are called high-usage trunk groups, and their intent is to skim the cream from one node to another or from one hub to another where traffic permits. One starts with the non-hub nodes. If any of these has a lot of traffic with some other non-hub node, a direct trunk group (probably of a single trunk) should be investigated. First, the cost of a direct trunk is found, and a swooping gull diagram is plotted. Then the cost per minute of the built-up "back bone" connection from node to hub (to a second hub, perhaps), and then to the terminating node is found by adding up the costs per minute on each segment including the hub switches. This gives us a fair idea of how heavily our direct trunk group must be loaded so that its least used trunk is carrying traffic cheaper than the backbone. We can then use B3-MONTH to see if this loading is possible.

If we follow this procedure for the heaviest inter-node calling patterns, we may be able to pull a lot of traffic out of the backbone. This will make its cost per minute go up, but we may be able to get some of the money back by reducing the size of the several backbone groups along the way. Reducing the access trunks may produce the most savings.

Once we have investigated direct or high-usage trunk groups between non-hub PBXs, we can do the same thing for inter-hub groups. We already the heaviest usage groups included, but there may be a few more possibilities that are almost as big. Here, however, the insertion of direct groups may have a much bigger effect on the backbone groups, so costs must be recalculated frequently. For simplicity of routing, we want to try to have only one "super hub" for our backbone routes; if we can't get from one hub to another on a high-usage group (if there is no high-usage group between the particular hub pair), we want to minimize the ambiguity that two or more alternate paths might produce.

It is possible to buy tie-trunks via satellites at relatively low cost. However, because of the great delays introduced by satellites, two "bird hops" in tandem must be avoided in private as well as public networks. The undesirability of tandem satellite connections, however, has lead to better ways of using satellite facilities. In addition to eliminating the delay of a second satellite trunk in a tandem connection, it is possible to make much better use of satellites simply because they are satellites.

The name for effective satellite use is DAMA or TDMA for demand assignment multiple access or time division multiple access. There may even be a few other similar names floating around. But the general principle involved is to have one group of channels via the satellite that can be assigned as needed on a per call basis between any pair of earth stations. All earth stations can send to the satellite and, more important, all of them receive everything the satellite sends back to earth. Thus all that is needed to go from any earth station to any other is a way to send so as not to interfere with other people who are sending, and a way to pick up what you want to receive, rejecting all else.

Both analog and digital techniques can be used. Frequency division has the satellite system assign a separate sub-carrier frequency to each direction of transmission, while time division assigns particular time-slots. When the call is over, the carrier frequencies or time slots are returned to the "available" pool for assignment to another call, perhaps between completely different earth stations. It can be seen that the satellite acts not only as a transmission system, but as a sort of super hub in the sky.

Design for a system of this sort starts just as before, up through the point where hubs are selected and groups of access lines are priced out and sized, using whatever terrestrial facilities are available. But the inter-tandem trunking between hubs is completely different. There should be an earth station at or near each hub, and each hub should have one satellite group from the switch to the earth station. This hub-satellite group must be big enough to handle the total traffic from the hub in question to and from all the other hubs.

It will be appreciably smaller than the sum of the groups that might be designed for terrestrial service for two reasons. First, one large group is always smaller than a number of smaller groups handling the same traffic at the same grade of service. And second, busy hours on trunk groups do not always coincide. Thus the sum busy hour traffic, obtained on an hour by hour basis from a number of trunk groups, will almost certainly be smaller than the sum of the busy hours on each individual group. As for the equivalent of inter-hub trunks themselves, the actual satellite channels, the same principles hold. One large group is designed, capable of handling the peak load among all pairs of hubs, based on the sum of the outgoing hub traffic only to prevent counting each call twice. From our principle of building up group size, it is evident that this group of channels through the satellite will handle the traffic with a smaller maximum number of circuits for the same grade of service than would a number of terrestrial groups.

The failure of busy hours to coincide through the satellite is even more pronounced than it is on individual hub-satellite trunk groups. Thus building up group size, by having one satellite inter-hub group handle traffic among a number of PBXs, leads to major economies. Time zone differences also become a factor. The totality of its circuits can be used in the east up until 11 AM eastern time when California starts to come on stream. Similarly, after 2 in California, all circuits are available for use by locations on the west coast. In between, the same circuits are available for east-west communication.

To take advantage of this, it is necessary to break out traffic by the hour, with all hours expressed in terms of the same time zone (all Eastern Standard Time, for instance). Then the relationships between peaks and valleys will show up correctly. The ability to fit one hub-pair's busy hour traffic into another hub-pair's side hour over such a wide scale is a major factor in the use of satellites.

In addition to group size economies and the ability to take advantage of non-overlapping busy hours, satellite systems have one additional advantage: they permit the use of more hubs, reducing the average node-hub access line length and cost. Further, because there is only one inter-tandem trunk between any pair of hubs (no "going around the horn"), transmission can be greatly improved. With all these advantages, it is surprising that satellite systems have not made more of an impact in the field of large user networks.

If a private tie-trunk network is properly designed, the great majority of calls will use only one tie-trunk: either an access line from one of the many smaller nodes to a station user on a hub, or from station user to station user on two hubs; it is not unusual for local offices to call their regional offices, and for regional offices to call one another. However, there will also be calls that traverse two, three or more trunks in tandem. This is where thing get sticky.

It is fairly easy to find the cost per minute on any one tie-trunk. One simply divides the monthly cost by the monthly usage. But when several trunks are connected in tandem, the sum of the costs may turn out to be surprisingly high. The distance from Philadelphia to San Diego is less than from New York to Los Angeles, but with nodes in Philadelphia and San Diego and hubs in NY and LA, the actual cost for the node-node call would be more than a hub-hub call. This difference is accentuated by the higher average cost per mile for short-haul trunks than long-haul, a difference that will increase with time as competition continues to push up prices.

The telephone industry has always used rate averaging for toll calls, basing costs on distance between callers and duration of call, independent of the way the call is routed. And although ideological advocates of the "free market" may object, rate averaging is probably the best way to bill back within private networks as well. Billing based on some discounted factor over toll will be easy to explain and defend, and will give a telecommunications department considerable freedom to design optimal networks. Reducing the total cost is the important thing.

The "discount factor" itself can be obtained in a fairly straight-forward way. Simply price out calls as though they were toll and get the total cost; then, divide that cost into the total monthly cost of the network. When figuring the network cost, switching and trunks must be considered, and off-net message units, tolls, and other charges must be added in. Further, the administrative costs for system management, Call Detail Recording, user billing, etc., must also be included.

If your private network costs more than toll, it's not a bargain. However, with proper design, tie-trunk networks can still do a pretty good job where there is sufficient volume to support them.

Tie-trunk networks are powerful tools for reducing telecommunication costs, but only if the price is right for the facilities from which they are constructed. The passing of TELPAK made private voice networking shift to WATS and specialized carrier service; increasing cost of switching with the passing of Step By Step and the coming of electronic PBXs has hastened the process. But there are instances, particularly for very large businesses and institutions, where tie-trunk networks are the right way to go.

To design a network, one must first obtain the required traffic information. This is the hardest part of the job. With a measure of the calling available between all possible pairs of nodes, hubs can be selected and trunk groups planned. Once all hubs and nodes are connected with a basic configuration, the possibility of high-usage direct trunk groups can be investigated.

Network design is not complete until its administrative system is established. Bill-back to different users, departments and divisions is almost always required, and even when it is not, the cost of the network relative to other alternatives such as toll, WATS and specialized carriers must be continuously available to help in developing new savings and eliminating non-economical segments. Obtaining traffic information independent of bill-back data is another whole area of vital importance. It is almost impossible to manage tie-trunk networks on the basis of Call Detail Recording information alone.

Much of this goes well beyond a first course in telephone traffic, but traffic makes no sense if designers and administrators are not aware of the larger context in which they work.

[ Top ] [ Next Chapter ] [ Table of Contents ]

Copyright 2006 Lee Goeller. All Rights Reserved.