Figure 2: Avoid Call Blocking
As already discussed, there are many possibilities to minimize call blocking, e.g. optimal VP configuration (), a dynamic CAC by taking previously monitored call intensities and call blocking constraints into consideration ( ). But even when assuming a dynamic admission control, the possibility of call blocking remains. Depending on the area the ATM network is used in, this might not be acceptable. In the LAN area, we usually want everybody to be able to communicate and so call blocking is not acceptable at all. In the WAN area, the primary aim could be to get as much money for the provided bandwidth as possible, and so call blocking could be acceptable depending on the service contract.
Assuming that we want to serve as many customers as well as possible, we have three possibilities to avoid call blocking (compare Fig. 2):
1. Control bandwidth usage
First of all, we can try to avoid the waste of bandwidth by making sure that everybody really uses the allocated bandwidth. We can do this by monitoring the used resources of the connections and compare it with the allocated resources. If the difference is greater than a selected maximum, renegotiation of the connection is initiated.
2. Squeezing connections
When a certain amount of reserved resources on a particular link is reached, indicating that the probability of a call blocking event is very high, renegotiation on selected existing connections is initiated. Thus, we are squeezing existing connections to get room for potential new ones. If no further squeezing of connections is possible and a high call blocking rate is observed, we might have reached a physical limit of our network and a redesign of the network is necessary (similar to splitting of highly loaded Ethernet segments as mentioned previously).
3. Modify CAC
We include the knowledge about usual traffic characteristics in our network to modify the CAC respectively.
It is necessary to consider some restrictions to these points. It does not make sense to renegotiate every connection. If the usage of the bandwidth is low, we could omit any action on existing connections, which includes the possibility to disturb them. Besides, some kind of services or connections of a special user probably should not get renegotiated at all. Thus, it should be obvious that the set of actions we are looking for has to be restricted by a set of 'fairness policies'.
The actions themselves should be evident. Concerning the control of bandwidth usage, we act as follows: If the used bandwidth of a connection differs more than a value for more than a time from the allocated bandwidth, this connection would get renegotiated to the observed values. If renegotiation is either not possible (paying customer) or not worth (no further usage on the link expected) due to the fairness policies, we omit renegotiation and instead give the customer a report after the connection was released.
As far as squeezing connections is concerned the following considerations apply: The probability of call blocking is very high, when the amount of free resources on a link is less than the usually requested mean bandwidth on this link and there are currently less connections active than usual. This means that we need an action value for the management parameter which is dependent on the traffic characteristics in the network. We especially need to know how many connections are usually active on this link and how many resources are usually requested. This issue will be discussed in section 4.3. Again the action to initiate after these values are reached is to renegotiate selected connections based on the policies.
The modification of the CAC is not bound to special management parameter values but is time dependent. By logging the resource requirements appearing and processing them (e.g. time dependent number of requests and amount of resources requested) the parameters of the CAC could be manipulated accordingly (for example: do not accept, respectively lower down, a request for more than 10 % of the physical bandwidth at 1 pm on Mondays as this time we usually have 10 connections each requesting 10 % of the resources; or: at 6 pm on Sundays, it is possible to accept requests for up to 50 % of the resources as this time we usually only have 5 connections each requesting 10 % of the available resources).
The control section depicted in Figure 1 has to validate that no 'call rejection' appeared.