3.5 MFA Performance Management
Last update PvD

3.5.2 Capacity Management

Overview

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:

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.

Tariffs

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

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:

• Guarantee Quality of Service;
• Minimise capacity (cost).

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 forecasts

• Predict services (M&S:  market intelligence).

Network usage forecasts (traffic predictions)

• Define service/traffic characteristics (modelling traffic)
• Define Service Access Points (SAP)
• Define traffic distribution
• Define Points-Of-Presence (POP, i.e. the transit nodes)
• Define traffic matrix (with existing networks mainly predicting network usage trends from collected performance data)

Network planning & design (PM)

• Predict network usage
• Identify bottlenecks (& risks)
• Define capacity adjustments (potentially adapt network topology) {Routing & cost info, configuration of existing equipment;  design rules:  network modelling}
• Analyse & predict new usage & QoS
  if unsatisfactory, adapt capacity adjustments (iteratively)
• Provide NE capacity data + TMN (including DCN) dimensioning

NE (equipment) planning (CM)

• Plan equipment (nodes & links) capacity adjustments (dimension/sizing, either by increasing/­decreasing capacity allocations (unlock/lock) or adding/removing equipment).
  It involves equipment planning rules, generation of Material lists, update spare parts, Effort planning, ordering rules (lead time, ordering quantities), adaptations to various databases (e.g. configuration), and the generation of commands to (de-)install equipment and modify NE databases, WorkOrders, …

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)

• Get equipment from stock or order extra equipment;
• Perform installation (extensions) or de-installation (reductions);
• Return superfluous equipment (to stock).

Performance monitoring

• Monitor resource usage, collect and aggregate data.

Performance analysis

• Evaluate data, convert to information (purpose).
  Evaluation (or aggregation) is not trivial in a network with overflow routes (i.e. direct routes, primary hierarchical routes, secondary hierarchical routes, etc).

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.:

• free a particular resource (i.e. move usage away from a resource (e.g. node/trunk) for planned maintenance, or to make it available for other purposes), or minimise resource use;
• distribute usage more evenly over available resources, i.e. cyclic re-allocation over resources thereby spreading load, reducing delays & impact of failure;
• pack or group usage together (optimise, repack, 'defragment', load a particular resource as much as possible).

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.

For ATM a more refined model is expected:

• Capacity planning & Network design;
• Connection Admission Control (CAC);
• Dynamic routing;
• Dynamic compression;
• End-to-end feedback ('window size');
• Link-by-link feedback;
• Buffering.

There are two basic options for Traffic Control:

Expansive:

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:

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

• Detect problems
  e.g. focussed overload;  possible solution:  keep track of top 10 (..30) destinations causing call failures.
• Squeeze traffic
  e.g. how to restrict traffic;  broadcast 'call gapping' command, have pre-allocated (and potentially restricted) channels for some traffic types.

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 Management

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

Summary

• The evolution is to generic multi-service networks:  this makes Capacity Management essential for efficient operation, but also more complex.
• Capacity(/demand) modelling is essential but in general an unsolved area.
• Effective real-time monitoring & control is essential to guarantee Quality of Service at minimum cost.
• Automatic methods will increasingly become dominant, but there will continue to be a role for centralised manual control for emergency response (humans can process enormous amounts of data when presented in the right way) and change management (network evolution).
• Centralised and Distributed control methods can co-exist to deliver practical optimisation of multi-service networks.

=O=