Contents Telektronikk - Telenor

able basis for control decisions (processor
load, queue length, call arrivals, call
categories, etc.)? How should control
algorithms using these data be designed?
Should different services be controlled
individually or by a common algorithm?
In a distributed environment, should the
overload control mechanism be implemented
in each processor or should this
mechanism be centralised?
Other basic requirements on mechanisms
for overload control are: The amount of
processor capacity needed to reject calls
must be small. Thereby as much as possible
of the processor capacity can be
used for useful jobs. Call delays should
not increase due to the overload control
mechanism under periods of normal load.
The overload control mechanism should
be straightforward, robust and predictable
and system performance not too sensitive
to different parameter settings.
There are other major internal functions
in the control system that may interact
with the overload control mechanism.
The monitor that handles the variety of
tasks and sees to it that time critical tasks
are given a higher priority than others is
perhaps the most striking example. It is
important to grasp the impact and limitations
on overload control mechanisms
from such a monitor. This in turn emphasises
that the design of overload control
mechanisms should be done in parallel
with the design of the control system
itself and not as late “patches”. Good
real-time performance can best be
achieved by careful consideration of realtime
issues early in the design process.
2 The new challenge
Most existing overload control schemes
in public switches derive from pure telephone
switch applications. These
schemes are normally not well suited to
cope with data traffic nor with a mix of
ISDN traffic including packet switched
signalling. In many of today’s ISDN
switches overload control schemes handle
D-channel traffic and signalling only
in a rudimentary way. The great variety
of traffic load mixes to be handled by the
switches may talk in favour of individual
solutions for different exchanges based
on individually controlled services. For
obvious reasons, however, such designs
are far from attractive: very detailed data
collection is required; many control
parameters must be defined and adjusted
to a varying traffic mix. Indeed, it seems
that great efforts should be spent searching
for control principles that are not
only efficient but also as robust and simple
as possible.
Future control systems will in many
cases be implemented in terms of a distributed
architecture with a number of
processing elements. In general, each
processor has its own overload detection
and control mechanism, since different
overload situations may affect
different processors. Then it is important
to consider a global efficiency of
the control system. In the case of a fully
distributed architecture with loosely coupled
processors, where each processor
may be able to handle any task or service
request to the system, the load sharing
procedure has a strong impact on the
overload control mechanism. In earlier
papers [1] we have shown that certain
load sharing principles, like Shortest
Queue First, may under some circumstances
lead to an undesired behaviour
of the control systems. Heavy oscillations
might appear in the job queues at
each processor, which lead to a large
increase in the mean waiting times.
Again, good real-time performance can
best be achieved by careful consideration
of real-time issues early in the design
process.
In Intelligent Networks the definitions of
services reside in a few nodes in the network
called Service Control Points
(SCP). (See Figure 3.) It is very important
to protect the SCPs from being overloaded.
A network where call control,
service control and user data reside in not
only different nodes requires the support
of a powerful signalling system capable
of supporting real-time transaction
oriented exchange of information between
the nodes dedicated to different
tasks. SS No. 7 is used for this purpose.
Due to the construction of the involved
communication protocols, the throttling
of new sessions must be done at their origin,
i.e. not at the SCPs, but in the SSPs
(Signal Service Points). To manage the
transfer of information between different
nodes in an IN, SS No. 7 uses a set of
protocols and functions on OSI-level 7
called Transaction Capabilities Application
Part (TCAP). TCAP makes it possible
to set up dialogues between nodes
and to interchange information. Quite a
lot of processing time must be spent on
unwrapping the SS No. 7 protocol and
TCAP before the contents of a message
can be read. For example, in the freephone
service, about half of the total processing
time in the SCP is used to unwrap
the protocols. Under overloads, the
SCP will spend its real time capacity on
Figure 3
SCP
Transport
network
Signalling
network
just unwrapping the protocol of arriving
messages and discarding queries. Thus
the SCP cannot protect itself from being
overloaded. A node can only protect
itself if the processing time needed to
decide if a query should be accepted or
not is small. Traditional approaches to
load control will not be sufficient for the
SCP nodes. Some of these difficulties
can be solved by placing throttles in the
nodes that initiate the work to be done by
the SCP nodes instead of placing the
throttles in the SCP nodes themselves.
The flow control and rerouting in SS
No. 7 are believed to have less influence
on overload control implementation since
these work on a shorter time scale than
the overload control. Within the coming
three to five years we will see STPs (Signal
Transfer Points, i.e. switches in the
signalling network) switching hundreds
of thousands packets per second corresponding
to some thousands of new sessions
per second. If not properly protected
from overload, the precious real-time
capacity of the control system in the
STPs will fade away.
A part of the SPC capacity might be
reserved to one or several service providers
or customers for a certain period of
time. In other cases this reservation is
permanent. Under periods of overload it
is important to portion out the SCP
capacity according to the reservations
made. The service provider that can give
SCP
STP
SSP
83