Wiki Wiki

Case Study Asian Mobile Service Provider

Introduction#

This is the #1 wireless operator in a major South East Asian country with over 30M subscribers. They use an existing fault management for the resource level management functions as defined by the TMF and the OSSera solution for service level management across operations as well as the SIP (Strategy, Infrastructure, Product) business process domain (see blog).

Both their planning and monitoring department are using OSSera's solution for service specification, definition, implementation and monitoring.

Resource alarms come from the fault system through Corba to the OSSera Service Manager. Now, each day there are about 28M alarms across the systems. The OSSera system will filter the alarms that do not impact any services. Then, other alarms will go through a service impact analysis process to identify service problems. The custmer is planning to use OSSera's performance system to monitor performance on services and the resources that support the service.

Value Proposition:#

As outlined by the customer, here are the following value propositions:
  • A standard process from planning to operations and monitoring
  • information is shared among all departments in a unified manner.
    • Unified Management Frameworx
      • One Service Inventory Management system
    • Unified Data Model
    • Unified Monitoring
  • Centralized documentation for service configuration and service dependencies
    • Service dependencies are modeled within Service blueprints
  • Great value is being realized with the Sequence Diagram
    • Key features, users can modify the diagrams using a modular process flow as needed while other flows are untouched (this feature was not available in Visio)
  • Service impact across different teams
    • Service Impact presentation is now available based upon different aspects within our NOC. E.g. group by service type, location, inbound/outbound, etc
    • Service Impact analysis is a feature we are planning for the Activity Management team as well.

Here is how OSSera Service Manager is used at a very high level:#

When the Service Planner plans for a new service, they start with a sequence diagram to define the resource and systems involved in a service, as well as their interactions in providing the service. The resources and systems are defined with classes and each instance is recorded within an excel file which then can be imported into our system as MOs.

After the MOs are imported in our system, the user then can associate MOs to the diagram components. The service defining sequence diagram (aka service flow diagram) can then can be automatically converted to a service topology (TMF term, aka service path). These service topologies can be edited to add networking devices to form the network topology that the service topology is relying on.

Another diagram, service impact diagram, is used to define how resources impact services as well as how services impact each other.

The service flow diagram, service topology and network topology diagram are mostly for the planning department to define, specify and implement the services (SIP). The service impact diagrams are mostly for the SOC/NOC to monitor services though all other diagrams also help the SOC/NOC to see more details of the impact during monitoring.

How many operators are using the Service Manager solution?#

About 30 operators in planning - increasing to 50. About another 30 operators in the SOC/NOC.

We have another product built on top of our platform supporting 1700 users with two sun servers.

How may service models do they have?#

2000 service models and 2500 service nodes

Any resources modeled?#

Resources are lightly modeled except for the server area. They have modeled the Node, NodeGroup, NodeFramework. The data model is different from TMF (which is customer – product – service – resource where service includes customer facing and resource facing services, resources include physical and logical).

Their data model is: Service – subservice – Node Framework – NodeGroup – Node. In NodeGroup and Node we have added a node type attribute to tell if it is logical or physical node. After we looked into different data modeling tools, we decided not to restrict the data model and let the user design and apply their data model.

Do they have other data feeds other than fault management?#

No, not yet. We don’t restrict data feeds but for now they only use faults. We are developing a DMP (Data Mediation Platform) to simplify the data feed process for all of our products (target 2011)

For Performance Management would they take data from network elements or a database performance repository?#

We did some testing on this but it is not in production yet. The performance data is mostly from NE's while some from files. The complexity we have seen here includes:

1. Sometimes data does not come completely i.e. part of the performance report could come on time and the rest may be received much later. The KPI and TCA engine needs to handle that.

2. The KPI is calculated using data from multiple performance reports

3. Be able to show KPI/TCA (threshold crossing alarm) on the topology

4. Be able to unify the performance data model and fault data model

Specifications#

  • Sun Server handling 28M alarms
  • 50 planners
  • 30 operators
  • 2000 service models
  • 2500 service nodes
  • Distributed server not yet added for load balancing and High Availability
0 Attachments
15841 Views
Average (0 Votes)
Comments