Figure 5: Basic elements of the self-regulating system
Due to the analysis above the self-regulating system can be complemented as shown in Figure 5.
The network state is continuously written down in a history database (A). This history information is processed (B) and leads to the definition of action values (C) for the set 1 of parameters. When these thresholds are reached, a well-defined set of action is performed (D), manipulating the second set of parameters. Afterwards, the correctness of the operations is checked by the control part (E), in validating values of the third parameter set. A negative response of the control part indicates necessary modifications of the parts B and D.
The processing of history information is discussed in the next section. The necessary set of actions was informally described in above considerations. The key actions were identified to be the renegotiation of traffic contracts and the modification of CAC parameters. Neither is possible with existing equipment, renegotiation is not even standardized. A more detailed specification of the action set has to be performed as soon as these features are available.
However, quick renegotiation in upcoming problem situations, as described above, requires that candidates are marked already at call setup time. I.e. if we detect the necessity to renegotiate in expectation of a congestion, we must already know which concrete connections are candidates subject to the given fairness policy.
The control part (E) in Figure 5 is either implicit given (a user telling us, that problems occur) or can be explicitly implemented (e.g. in terms of the number of call rejections). The automatic manipulation of the parts B and D in Figure 5 after negative responses is therefore case dependent.
The most important point and the base for further work is the collection of relevant traffic data and the processing of this data to get action values. This will be depicted in the next section.