Date: Thu, 19 Mar 92 09:44:01 CST
From: varney@ihlpf.att.com (Alan L Varney)
Subject: Re: Rock Concert Stars Jam Local Phone Service
Organization: AT&T Network Systems

> deej@cbnewsf.cb.att.com (david.g.lewis) writes:

> I'm not a NET network traffic engineer, but I would say it is very
> likely that the majority of traffic destined outside of your local
> exchange goes through a tandem.  While some traffic to adjacent
> exchanges may go through HU (High Usage = direct) trunks, most
> intra-LATA interoffice, as well as all inter-LATA and operator traffic
> probably goes to a tandem.

   Dave, I'm not a traffic engineer either, but I deal with their
mistakes often.  Some areas (higher density) use "direct" trunks for
the majority of intra-LATA calls, particularly within a metro area.
Tandem switching of such calls is useful only to carry unusual peaks
(e.g., high outgoing traffic peaks to/from one switch to many others
that is not during peak times elsewhere) or to save on some long
facility routes (e.g., cross-LATA trunks may be more expensive than
the cost of a few more tandem trunks + added tandem costs).  It's a
non-trivial engineering problem to trade off the cost of added tandem
capacity and two short circuits used XX% of the time with a longer
direct circuit used YY% of the time.

Steven S. Brack wrote:

> Could overflow calls be routed through these HU trunks to another
> tandem?  Of course, I don't know that it would be the best way to
> handle things, but surely 911 and operator could be routed so that you
> can actually reach help.

   One could certainly route overflow calls indirect through any
number (within reason) of other COs.  Modern End Offices (COs) can
tandem calls and overflow in fairly complex ways.  BUT one must keep
in mind that the "focused overload" on a single number is a relatively
rare occurrence, compared to the "mass overload" that natural
disasters, etc. can generate.  For example, if the switch was smart
enough to overflow calls to HU trunks, how would it "know" that a
high-volume number wasn't to route that way also?

   And the last thing you want to do in a "mass overload" is try
multiple alternate routes to reach destinations that are busy or
un-reachable.  Since the two types of overload look the same to a
given switch, it can only respond in a manner designed to handle the
more severe "mass overload" situation.  Network Management's job is to
assess the true cause of overload and inform the COs of the proper
response -- this could include "gapping" calls to a particular DN, or
NPA, or NPA-NXX at a high percentage, such that most are quickly
rejected at the originating CO.

   Your suggestion that 911 and operator traffic be routed in a
different manner is a good one.  In fact, in many LECs, specific
circuits are dedicated to 911 calls -- this is both a necessity to get
full "E911" functionality and a reasonable means of allocating the
"costs" of 911 service.  LEC operator access is also usually over
dedicated circuits, but in many cases unsuccessful callers to a
particular "concert ticket" number will attempt to use the LEC
operator to complete the calls.  So those circuits get busy as well.
In addition, the ability to reach an operator may not help if the
operator's access to the desired number is through the same set of
switches undergoing the circuit overload.

> Also, isn't it generally a provision in the phone company's contract
> with you that if your telephone use adversely affects their network,
> they can disconnect you?  Is that done in situations like this?

   As usual, the size/power of the "affecting user" can influence the
type of actions available to an LEC.  A large university with
disconnected service would cause lots of PR problems for all those
involved.  In these situations, a series of discussions with the
university would usually lead to a reasonable solution -- such as
managing the load by staggering it in time.  Or, if the calling
population is restricted to a small area, "call gapping" or other
network management controls could be activated in advance in the
affected switches.


Al Varney -- my own opinions, not AT&T's

Date: Fri, 20 Mar 92 14:11:23 CST
From: varney@ihlpf.att.com (Alan L Varney)
Subject: Re: Congestion Control (was Rock Concert)
Organization: AT&T Network Systems

In article <telecom12.243.1@eecs.nwu.edu> deej@cbnewsf.cb.att.com
(david.g.lewis) writes:

> In article <telecom12.238.7@eecs.nwu.edu> pdh@netcom.com (Phil Howard)
> writes:

>> To start out with, I don't know how the switches work so I don't know
>> what can be done, or what excuses programmers of them might use, but
>> the following concept seems simple enough:

   EXCUSE ME!  Those aren't excuses you hear -- it's reality ...

>> Simply set a maximum number of calls that can be placed to a single
>> number over a given trunk, as a percentage of that trunk capacity
      Per David Lewis, ^^^^^ is a "trunk group"
>> regardless of the ultimate capacity for the phone number.  A
>> reasonable percentage might be 25%.  Thus for a trunk with a capacity
>> of 80 calls to the exchange where the number is going, the 21st call
>> will get either a busy signal or be delayed if the switch can deal
>> with delaying it.  Then it would take more than one such number to
>> overload the trunk just from the mass calls.  Percentages might differ
>> for different exchanges.

While such a technique is "feasible", congestion isn't always at the
originating switch.  To be effective, every tandem switch (and
InterLATA carrier's switch) would require a list of all in-progress
call destinations, searched on every outgoing/tandem call.  If a large
tandem supports around 50K simultaneous calls, either the search is
expensive in real-time or huge hardware support would be required.
Some switches use on the order of CPU 7000 cycles to completely handle
a call (total of setup, billing and disconnect).  Such a search for
such rare problems is not cost effective.  And it still doesn't solve
the much harsher problem of dealing with events that generate large
call volumes to many numbers (earthquakes, etc.).

> Call gapping on NPA-NXX can be more valuable that gapping on an
> individual DN, because it then allows for overload controls during
> natural disasters and other events causing a large number of call
> attempts to a given area, as opposed to just a given DN.  For a slight
> loss of precision, the capability is more generally useful and, not
> incidentally, probably costs considerably less.

> [Disclaimer - this does not necessarily represent the implementation
> of call gap controls in AT&T's network or products or those of any
> other vendor ...]

Ditto.  But I should point out that LEC switches typically can deal
with NPA-NXX-XXXX call gaps (manually placed) as well as the NPA-NXX
versions.  And SS7 will probably evolve to support some form of
automatic notification of the need for "up-stream" gaps.  The proposed
implementation of "portable" 800 numbers supports a notification
(manually or automatically initiated) to switches to gap calls to
specific 800 numbers, for example.

>> Is it possible for the target exchange to signal the source exchange
>> that the line is busy, so the busy signal sound is generated from the
>> callers own exchange and free up the trunk line immediately?

> This is done with SS7.  When the terminating exchange determines that
> the terminating DN is busy, it sends a RELease message in the backward
> direction with cause = user busy.  This releases the reserved trunk
> and indicates to the originating switch to apply busy tone inband.

(Or display "BUSY" on ISDN sets.:-) ) Yes, this works well for both
cases of "user busy" and for "no circuit available" from intermediate
switches.  While efficient on a per-call basis, it also has the side
effect of allowing even MORE unsuccessful attempts per hour over the
same number of circuits.  So, by itself, this capability of SS7
doesn't reduce the impact of either form of call congestion.


Al Varney -- my opinions; AT&T hasn't approved them.

Date: Sun,  5 Jul 92 22:07:12 CDT
From: varney@ihlpf.att.com (Alan L Varney)
Subject: Re: Concert-Goers Blast 911 Service
Organization: AT&T Network Systems, Inc.

In article <telecom12.530.1@eecs.nwu.edu> rice@ttd.teradyne.com
writes:

> In article <telecom12.522.1@eecs.nwu.edu>, bakerj@gtephx.UUCP (Jon
> Baker) writes:

>> Excepting a very poorly engineered CO, this also should not be a
>> problem unless you have a very significant percentage of your
>> subscribers going offhook all at the same time.  This is not the case
>> in a concert ticket hotline, or a radio station giveaway, but might
>> occur during some sort of emergency (power failure, weather disaster,
>> large nearby explosion, etc.)

   But the problem really IS that a significant percentage go off-hook
at about the same time, over and over.  The TELCo can gap "concert"
calls at the originating switches and, at least for repeating numbers
such as the radio station, use a choke trunking network to prevent
tying up normal inter-office circuits.  But until you get dial tone
and dial your number, there is NO WAY to determine if the next call
you make is somehow more important than the ticket caller.  So dial
tone delays are a fact of life for such high-volume call demands -- no
one would want to engineer a CO for two-second holding time calls and
line occupancy near one Erlang for 20% of the lines.

>> In such a case, certain lines within
>> the neighborhood can be designated to be 'hot' lines, or 'A' lines,
>> which get preferential treatment.

> Well, I'd sure hate to be one of the 80%-90% trying to call for an
> ambulance for my parent with a heart attack. Who decides who get's
> 'preferental' service?  In my opinion, the 'Concert Ticket' phoenomena
> is 'misuse' of the phone system (right up there with telemarketing and
> charity solicitation).

   Preferential service is usually given to hospitals, doctors, police
and other emergency-related services.  Maybe a few high-profile
officials?  But not the average residential line.

> In article <telecom12.522.2@eecs.nwu.edu>, williamsk@gtephx.UUCP
> (Kevin W. Williams) writes:

>> In article <telecom.12.512.4@eecs.nwu.edu>, rice@ttd.teradyne.edu
>> writes: 

  [ regarding overload of circuits ]

>>> I'd have to disagree. Proper design of a "Life and Death" emergency
>>> system should preclude ANY intruption of that service based on trunk
>>> loading. 911 trunks should be Independent of any other traffic.

>> Let's be a little realistic here. I could, indeed, design a 911 system
>> which was indpendent of any other request for service. Unfortunately,
>> I would have to run a separate phone to each house which only served
>> the emergency service bureau.

   Making 911 trunks independent isn't hard, since most of the current
E911 systems require special signaling on the circuits to a central
tandem.  But trunks aren't the problem -- dial tone is.

>> Choke prefixes, call gapping, and similar network management
>> treatments are a compromise for an insoluble problem. No switch
>> manufacturer can sell totally non-blocking line equipment, because the
>> telcos won't pay the costs. We cannot predict who is going to call 911
>> and who is going to call Larry King. The best we can do is make the
>> machine survive the peaking, give fairly distributed service to all
>> originators, and try to deal with the problem during routing and
>> termination.

> My original comment related to 'Trunk Blockage' not whether the
> subscriber could receive dial tone. In the 'Concert Ticket' scenario,
> it's more likely that all outgoing trunks are blocked. It's the
> 'natural disaster' scenario in which dial tone becomes hard to get. I
> stand by my original statement.

   Believe me, dial tone is a problem even for the "concert ticket"
scenarios.  I've seen the traffic numbers for one of the "Garth Brooks
ticket hour" events.  Wow!  And this was with the ticket number call-
gapped at almost every switch.  Unfortunately, with current call gap
methods, the caller knows almost immediately that the call was killed.
So they hang up, wait for dial tone and hit "REDIAL".  The switch that
was the target for all these calls handled about 2X engineered busy
hour incoming attempts, with most receiving busy tone.

   Still not convinced?  Let's say a given switch can handle 360K
calls per hour with 60,000 lines.  That's 100 calls/second.  If half
are originating calls (needing dial tone), we need to provide 50 dial
tone/ digit receivers for each second it takes for the average caller
to dial.  If that's six seconds, we need 300 receivers (this is
back-of-envelope engineering, not Erlang-B).  But it takes less than
1000 ticket callers with a three-second holding time to use up all
those receivers.  That's less than 2% of the lines.  Many ticket
callers ask their friends to call, just to increase their odds of
getting some.  Result?  Severe dial tone delay.

   A friend in telco support agrees the best we can do with today's
switches is route the gapped calls to a very quiet announcement, with
some background clicking, so that callers believe their call is going
to EVENTUALLY complete.  But denying them an equal shot at dial tone
when they re-originate is expensive in real time, and might lead to as
many lawsuits as it solves.


Al Varney -- just MY opinion, and not an official AT&T opinion.