3.5 MFA Performance Management
Last update PvD
3.5.2 Capacity Management
The operator determines (at BML-level) Tariffs and QoS:
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):
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.
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)
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 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:
There are two basic options for Traffic Control:
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:
|Centralised||options||Temporary alternative routing||Expert system & IN approaches|
Responsive in emergency
Fairly fast response
|conclusion||Very useful||Useful but very complex|
|Distributed||options||Switch management||Dynamic (alternative) routing|
Automatic call restriction
|appreciation||Historical interest||Skills independent|
Very fast response
|conclusion||Not useful||Very 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.
Overview of integrated Traffic Control, Capacity Control and Capacity Planning:
Integrated Capacity Management
Concept by J.Hind/BT, considerably modified by PvD.