The linking between individual elements of either application process or policy process is accomplished by publishing or subscribing to messages. These control flow messages are generated and set as process post conditions (published), or consumed (subscribed) triggering a process pre condition.

The combination of PDP and PEP provide the functionality to encode, evaluate and execute appropriate rules based on observed behavior within the managed environment. The triggers for rule execution are observed behavior and this requirement is predicated on a mechanism to evaluate conditions within the managed environment. Typically, these triggers are specified as notifications issued by a NE (i.e. managed object) describing a situation or condition within the NE.    

Implications of Policy elements in OSS

It is apparent that intelligence within the NE poses a new situation that a ‘centralized’ OSS may not need to operationally address an event or incident. This is due to the capability of the NE to execute particular actions to overcome the subject event or incident. However, it is foreseeable that the OSS still would like to control and manage the autonomous behavior of the entities in order to avoid chaotic situation. To achieve that, special capabilities (in form of policy server) need to be incorporated within the 4G OSS.

In this context, the introduction of policy management presumes the appropriate “know-how” within the organization, e.g., so that rules and policies can be created and established, as well as the adaptation of operational processes to include the policy management, plus the introduction of PDP as a decision-supporting system within the 4G OSSS and the implementation of policy elements for the entities that need to be governed by the 4G OSS.

Moreover, these policy elements (PEP, PDP) within the 4G OSS are an additional task when compared to the current OSS. Although the policy elements aim to simplify the relatively mundane operations of the network, their implementation requires substantial expertise and effort. This "know-how" must first be acquired by the operator before the automation potential can be exploited.   

With the introduction of automation, the 4G OSS takes a new responsibility that governs the autonomous actions of the network, since the network elements are capable of performing certain functions (e.g., fault prevention and remedy) that were initially performed by the OSS. And finally, the OSS functionality moves from “what” must be done to address the incident/situation to “when” must this action be done. This transition requires a deep understanding of the action to be performed and its causal effects, not only in the NE itself, but for the collective environment (network and organization policy) within which the NE exists.