**3.3.2 SLA violation**

The SLA violation scenario begins with a simple verification as above, but in this case a threshold violation occurs. In this case the eTOM provides an escalation mechanism: first, the Resource Layer attempts to solve the problem locally, while warning the Service Layer in order to plan alternative solutions. If the trouble persists, Service processes must perform an alternative service configuration produced by an Ordering operation; this new configuration may be the best solution and is followed by a return to normal SLA verification. The operation chronology consists of three stages: detection and attempted correction, reconfiguration, return to normal verification of SLA.




1. When a client requests an IMS service (eg video streaming VoD), the provisioning or "ordering" operation activates all agents in the network to monitor performance

2. Resource Data Collection & Distribution retrieves KPIs and metrics collected from different entities in the network. Afterwards, it communicates with the RPM (Resource Performance Management) to identify the existence of critical values and generate

3. The performance indicators KPIs collected are sent as XML to Service Quality Management, which identifies indicators KQIs and realize mapping function, and

4. The Customer QoS / SLA Management uses the loaded profile of customer to identify product thresholds to apply to data collected prior to drafting of audit report of SLA

5. The process Billing & Collection Management performs charging functions and taxation

The SLA violation scenario begins with a simple verification as above, but in this case a threshold violation occurs. In this case the eTOM provides an escalation mechanism: first, the Resource Layer attempts to solve the problem locally, while warning the Service Layer in order to plan alternative solutions. If the trouble persists, Service processes must perform an alternative service configuration produced by an Ordering operation; this new configuration may be the best solution and is followed by a return to normal SLA verification. The operation chronology consists of three stages: detection and attempted

of QoS degradation such a resources failure or lack of capacity in SLA violation. - **Customer QoS/SLA Management**: is responsible for checking SLA thresholds against measured QoS. After retrieving the KQIs from the Service Quality Management processes and receiving a preliminary report, the process imports the customer profile and SLA parameters to identify thresholds for comparison. It also manages reports of management systems and provides a comprehensive report on the service (metrics,

KQIs, key performance indicators, resource use, etc. ...). The workflow of the SLA verification consists of following steps:

comparing with thresholds are specific to requested service.

correction, reconfiguration, return to normal verification of SLA.

indicators and retrieve their values in log files.

with received information to make bills.

performance reports.

against QoS.

**3.3.2 SLA violation** 

The SLA verification involves following processes:

after aggregation and structuring.

detection of exceeded thresholds.

A real-time continuous monitoring of provided services allows early alerts concerning exceeded thresholds and resource failure alarms, which are main causes of violations and SLA unconformity. Most interactions occur within Assurance processes, but interactions are also concerning the Fulfilment processes, and violation is considered for reimbursement through the Billing processes.

Two specific processes handle the escalation mechanism depicted above: the *Service problem Management* and *Resource Trouble Management* processes (Figure 6).

Fig. 6. Active processes in SLA violation.

The goal of these two processes is to perform a restoration of services and resources in short time, and to locate troubles before their expansion, with an optional notification to the user.

The operation is initiated by a usual collection of data by the **RDC&P** process when detecting and exceeded threshold. The process sends relevant information to **RPM** to alert the **RTM** process; in case of a component failure the communication is done directly between **RDC&P** and **RPM**.

The RPM process sends details to the Service Quality Management (SQM) and to the RTM process, depending on the type of trouble, trying to start procedures for resource restoration; for each attempt it notifies the Service Problem Management (SPM) process to synchronize their information about troubles (Figure 7).

eTOM-Conformant IMS Assurance Management 61

A first step in this undertaking is to match IMS functionality with eTOM processes. The resulting set has furthermore to be enriched by eTOM processes relevant to Assurance and Fulfilment. This broader set forms the basis to select different SID entities necessary to carry out these processes. The SLA execution procedure as defined in eTOM model requires the cooperation of several processes belonging to Assurance and Fulfilment of the 'FAB' area, and spanning the three business layers: Customer, Resource, and Service. These eTOM

The processes belonging to the Assurance layer correspond to the monitoring aspect of this operation, related to Fulfilment for restoration and supply. In order to link eTOM processes to the IMS network, a new component entitled Monitoring, Configuration, Data Collection is

In the IMS network, the diversity of entities and their various communication protocols require multi-protocol components which can implement all the necessary monitoring and correction operations. An additional constraint is that performance data collection and

The WSOA (Web Service Oriented Architecture) appears as a valid choice for such a distributed system. The SOA (Mark and Hansen, 2007) concepts will allow to implement EJB (Rima, Gerald, and Micah, 2006) based SOA modules supporting the processes of each component, exposing web services communications via XML/SOAP (Simple Object Access Protocol) /HTTP (Newcomer E., 2002). Three SOA modules have been designed, each of which supporting a part of the targeted eTOM business processes and their associated SID

required, which clusters the core modules to communicate with these entities.

detection of services should be executed in real time or near real.

**5. Functional architecture** 

Fig. 8. eTOM and IMS interactions.

**5.1 Design** 

processes will be activated sequentially (Figure 8).

Fig. 7. Processes Flow in SLA execution with violation.

The communication between **SPM** and **SQM** aims to correlate their information about troubles whether solved or not; the **SQM** process sends details of impact on services and alarms to **Customer QoS / SLA Management** (**CQoS / SLAM**), a process that specifies SLA violation and customer importance by obtaining all this information from **Retention & Loyalty**, and finally notifies the customer about QoS degradation according to its importance.

If the cooperation between the Service Problem Management and the Resource Management Trouble processes is unsuccessful, the SC&A process will be activated to perform its own corrective action, such as a new configuration. The new configuration will take into account all resource constraints and infrastructure development and service contract terms.

The reconfiguration proposed by SC&A follows exactly the steps of the Ordering operation, and is finalized by launching normal SLA verification, and tries to close all open troubles reports in SPM and RTM. The CQoS / SLAM process can inform the customer about service restoration and quality with the possibility of sending a QoS report.
