3.5 MFA Performance Management
Last update PvD

3.5.2 Capacity Management


  1. Business Model
    providing the main drivers and parameters for Capacity Management
  2. Capacity Planning
    Plan (multi-service) network extensions/­reductions
  3. Capacity Control
    Optimise service specific capacity (i.e. move capacity between resources)
  4. Traffic Control
    Optimise traffic (within assigned capacity)
  5. Integrated Capacity Management Process
    Integrating the Capacity Planning, Capacity Control and Traffic Control processes
  6. Summary
    with some conclusions.

Business model

The operator determines (at BML-level) Tariffs and QoS:

The QoS is not necessarily defined in SLAs;  there is an expected QoS which only bothers customers when not met.  I.e. Quality of Service has a threshold characteristic, above which it ceases to determine customer behaviour.
Very important, but usually not the prime factor;  success is more determined by the general service package and customer care (exception:  large customers who have their own service departments and buy in bulk;  they typically want considerable discounts).
Business model for Capacity Management

Business model for Capacity Management

Concept by J.Hind/BT, modified by PvD.

The model shows that Tariffs and QoS determine Demand/­Market share, and –as a consequence– there is a corresponding optimal level for Capacity.

Capacity sufficient for an incidental peak in demand is extremely costly;  loss of quality should be no problem when it remains incidental.  The parameters should be defined by BML, and assured by hard figures from Performance Management.
It provides the Performance Management mission:

Assuming a layered approach (generic transport network versus service specific networks), there are 3 processes to optimise capacity (nested process cycles):

  1. Capacity Planning:  create capacity 'stock' available (shared) for all service networks.  Response in months.
  2. Capacity control:  allocate capacity for a service specific network.  Response in days.
  3. Traffic control:  control service usage (within the service specific network).  Response in minutes.

Capacity Planning cycle

Capacity refers to the availability of resources, usually on shared with other uses (i.e. not user specific and preferably not service specific;  typically transport).

The service-specific notion 'capacity' (e.g. Megabits per second for Leased Lines, Erlangs for switched voice, or packets/­frames/­cells per second for X.25/­Frame Relay/­ATM) has to be translated to the unit for shared capacity (most likely Kb/s or Mb/s).  In most cases there is an accepted method to do that (e.g. Erlangs), but for some others there is no generally accepted method (e.g. the switched data services X.25, FR, ATM);  this is left as a challenge to the user.

Service forecastsCapacity planning cycle

Network usage forecasts (traffic predictions)

Network planning & design (PM)

NE (equipment) planning (CM)

For reductions, decide to either Lock or De-install equipment.
It is common to have some spare capacity available to allow immediate service activation.  This is a range N..M:  when less than N units free, start ordering extensions;  when more than M units free, order de-installation.  Note that functional extensions or reductions go –due to equipment and logistic reasons– usually by some quantity Q.

Note that if equipment acquisition response is longer than the planning cycle, there will be multiple 'planned configurations', and new WorkOrders may partly cancel pending WordOrders.

Equipment adaptations (WorkOrder)

Performance monitoring

Performance analysis

Capacity Control

When the network actually consists of service-specific sub-networks in a multi-service network, capacity can be moved from one service sub-network to another.  When a service network doesn't need the capacity, it can return the spare capacity to a 'capacity stock'.  Obviously, this will only be done when it is clear by usage predictions that the spare capacity is not required in the near future.  Other service networks may allocate capacity from the stock when required.  Sharing capacity stock is a more efficient use of (spare) capacity.

Within the allotted capacity (for a specific service), resource use can be optimised, i.e. by rearranging resource usage according to some criterion (i.e. 'cost function').  E.g.:

Note that you may have the above (re-)allocation schemes at several levels, e.g. between trunk groups and within a trunk (group).

Such schemes are a necessity when the allocation quantity is variable (i.e. not a uniform allocation value);  otherwise one may find himself in the position that the required capacity is available but can not be allocated as one chunk (hence maybe not usable).
Often such schemes are applied for some attributes, e.g. pack according to destination in the same resource group, or distribute according to quality level over the resource groups.
Above schemes are also applicable for initial resource allocation, i.e. they are actually the same (re-)allocation schemes.  There are also more detailed options (like 'first fit', 'best fit', etc.).

One may consider this Configuration Management, but it has profound impact on QoS.

Traffic Control

Traffic control can be exercised at two levels:  Call Level and Transport Level.  The following picture depicts the relationship with corresponding indicators and controls.

Traffic Control

For ATM a more refined model is expected:

There are two basic options for Traffic Control:

use additional capacity (switched services:  overflow routes;  non-switched services:  alternative paths, service restoral), also used as countermeasure/­work-around after network failures.
Restrictive (switched services):
squeeze particular traffic to keep delivering other services at acceptable quality level, or even to survive.  It is very nice when one can identify the source of the overload, but that is not always possible (e.g. focussed overload) and not always necessary.  One can define some thresholds (on bandwidth or call rates) for particular classes of traffic (type of traffic, destinations, etc. which is likely to experience 'explosive' growth) in advance, but that will always be limited to problems foreseen (i.e. bad experiences).
For the time being there is still the need for manual intervention.

Specifically Call Admission Control (CAC) can be exercised in various ways, most commonly by rate limiting (calls per minute, e.g. by 'leaky bucket') or by 'call gapping' (delayed release of resources, e.g. 20 seconds delay on trunk release).  However, you don't want the same mechanism on the overflow routes.
Obviously, for non-switched services (e.g. Leased Lines), the 'Call Level' control is not applicable (but occurs during service provisioning when creating the PVC).  Similarly, the 'Transport Level' control is not applicable for fixed bandwidth services (e.g. voice).

A simple overview on some Traffic Control methods and their appreciation:

→ preference →
CentralisedoptionsTemporary alternative routingExpert system & IN approaches
Traffic bidding
appreciationVery flexible
Responsive in emergency
Good visibility
Cost effective
Skills independent
Optimal performance
Good visibility
Fairly fast response
Multi variable
conclusionVery usefulUseful but very complex
DistributedoptionsSwitch managementDynamic (alternative) routing
Automatic call restriction
appreciationHistorical interestSkills independent
Good performance
Very resilient
Very fast response
Easily scalable
conclusionNot usefulVery useful but underdeveloped

Specific problems in traffic controls (in particular in distributed real-time switching) are:

An example by BT of a 'mass calling event' (focussed overload):

BT's Bristol exchange had at a certain moment in time 156 successful terminating calls (which was normal for that time of day) but 135.000 unsuccessful calls.  This was controlled (still manually) by 'call gapping'.  They found out that it was only one distinctive number which caused the overload:  there had been an announcement on the radio for a Tina Turner concert and people from all over UK were trying to phone the same booking office.

Integrated Capacity Management Process

Overview of integrated Traffic Control, Capacity Control and Capacity Planning:

Integrated Capacity Process

Integrated Capacity Management

Concept by J.Hind/BT, considerably modified by PvD.