Telecom Performance Management System: Overview

Uploaded on

This is an overview of the concept of Telecom Performance Management System for Tier-1 and Tier-2 operators. …

This is an overview of the concept of Telecom Performance Management System for Tier-1 and Tier-2 operators.
The main features of this concept are:
- full coverage of all TMN model layers
- the ability for extension to full FCAPS model
- integration with any third-party systems
- distributed and fault-tolerant database model optimized for very large data volumes

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. TelecomPerformance ManagementSystem:System Description
    October 2010
    This document is licensed under CC BY.
  • 2. Operators need PM system to:
    Predict, analyze and investigate network and service performance degradations
    Generate and present network and service performance reports to company management
    Forecast network and service performance in case of events (Exhibitions/Trade Shows, New Year, Olympic games) or new product launches
    Control compliance with SLA on outsourced equipment
    October 2010
    TPMS: System Description
  • 3. General requirements for PM system - 1
    Near real-time system
    Support different data sources like performance counters, CDRs, probes, field/drive test results
    Scalable for any volumes of input data and retention periods
    System availability 99,999%
    Flexible for customization and extension
    Have open southbound and northbound interfaces
    Support object-level and domain-level security
    October 2010
    TPMS: System Description
  • 4. General requirementsfor PM system - 2
    Support multi-vendor, vendor-dependent, multi-service and service-dependent models for data and hierarchy. Support a service-network relation
    Keep history of changes of network hierarchy, KPIs and reports
    Support standard telecom functions and methods like Busy Hour, DAV, Erlang etc. Flexible for extension with user-defined functions.
    Support data forecasting and profiling
    October 2010
    TPMS: System Description
  • 5. High-levelSystem architecture
    As most other systems PM system contains:
    RAW data collection and parsing layer
    Data storage and managementlayer
    Application layer
    Presentation layer (User interface)
    October 2010
    TPMS: System Description
  • 6. RAW data collection and parsing
    Collect data using FTP, SNMP, CORBA, X.25, SQL, custom scripts
    Store collected data in input files
    Unpack files (if needed)
    Rename files to unified file name (if needed)
    Identify corrupted files
    Feed files to parsers
    Store processed files (may be needed for future data re-load)
    October 2010
    TPMS: System Description
  • 7. RAW data collection and parsing
    Dump files to unified format
    Process variable file structure and contents
    Un-peg data
    Validate and filter data (formula-based)
    Normalize data
    Aggregate, accumulate and enrich data
    Collect and report it’s own performance counters
    October 2010
    TPMS: System Description
  • 8. Data storage and managementlayer
    Data warehouse based on industrial standard DBMS (Oracle or Sybase IQ) optimized for VLDB
    Distributed data storage structure split by source (domain/technology/vendor/version) and location (region)
    Designed for parallel processing
    Historical class-object-relation model for all system entities
    Scalable for network growth and regional splits/merges
    Secure data storage
    Flexible for customization and extension
    Embedded programming language for data access and modification
    October 2010
    TPMS: System Description
  • 9. Application layer
    Multi-threaded access to DB for parallel processing
    Provide open integration interface (Web-services, OSS/J, SNMP)
    Events generation
    Data aggregation, correlation and profiling
    Scheduled report generation
    Store and share generated KPIs and reports
    Threshold actions (alarms, notifications, etc.)
    Extendable with optional modules
    Optional clustered architecture and redundancy
    Automatic health-check reporting
    October 2010
    TPMS: System Description
  • 10. Presentation layer (User interface)
    Rich web-based user interface
    Report and KPI designer/browser for end-users without knowledge of SQL
    Dashboards and real-time reports
    Ad-hoc reporting with interactivity and drill-up, drill-down and drill-same capabilities
    Object-based and domain-based security
    Export report results to CSV, XML, PDF, etc.
    Provide an administrative UI for all system components
    October 2010
    TPMS: System Description
  • 11. System architecture in details
    October 2010
    TPMS: System Description
  • 12. Data Collection and Parsing
    Collect data using FTP, SNMP, CORBA, X.25, SQL, custom scripts
    Validate data
    Dump, validate and filter data
    Normalize, aggregate, accumulate and enrich data
    October 2010
    TPMS: System Description
  • 13. Data Loading & Validation
    Load parsed data into the DB
    Validate data gaps and data re-loads
    Transform and normalize late data
    Initiate data processing and KPI calculation mechanisms
    October 2010
    TPMS: System Description
  • 14. Data storage
    Keep RAW and aggregated performance data and KPIs, network hierarchy, KPI and report templates
    Distributed data storage structure split by source (domain/technology/vendor/version) and location (region)
    1 data context = 1 DB instance or schema or database
    Optimized for parallel processing
    Designed for very large volumes of data with unstable structure
    October 2010
    TPMS: System Description
  • 15. Data abstraction
    Provide access to data in different contexts for presentation layer components making the data location-independent.
    Automatically locates requested data, builds parallelized queries and retrieves collected results.
    Correctly retrieves data in case of context unavailability
    October 2010
    TPMS: System Description
  • 16. KPI engine
    Store KPI/PI hierarchy for root-cause analysis
    Create KPIs by template
    Calculate KPIs as user-defined formulas or scripts (for complex KPIs)
    Aggregate KPIs by time and hierarchy
    Keep history of changes of KPI definitions
    Create personal and ad-hoc KPIs
    October 2010
    TPMS: System Description
  • 17. Report engine
    Store reports hierarchy
    Create reports by template
    Create batch reports or report chains
    Create master-detail reports
    Create personal and ad-hoc reports
    Calculate reports by request, scheduler, event
    Support time zones in calculations. Report may be calculated for local or central time zone
    Save pre-calculated report results for review and investigation without need of recalculation
    Save report results as XML, CSV, PDF, XLS, etc.
    Keep history of report definition changes
    October 2010
    TPMS: System Description
  • 18. Inventory
    Keep hierarchy of network elements (NE)
    Manage a class-object model
    Support vendor-specific and vendor-neutral hierarchies
    Keep history of changes of network hierarchy
    Manage virtual and logical network elements and groups (like region or data-center)
    Automatically discover network elements
    Group NEs by properties (like number of ports)
    October 2010
    TPMS: System Description
  • 19. Security engine
    Manage users, roles and domains
    Allow user access to the system functions or objects (NEs, KPIs, Reports)
    Provide a Single-Sign-On to the system
    Can be integrated with LDAP, AD, RADIUS, etc. for user authentication and authorization
    Log all user activities
    October 2010
    TPMS: System Description
  • 20. Alarm engine
    Automatically calculate KPI thresholds with minimal latency
    Send threshold alarms to Fault/Event Management Systems
    Alarms with conditions (alarm is raised in case of 2 or more threshold crosses during 1 hour)
    Threshold zones for different alarm severities
    Time-dependent thresholds
    Automatically clear the alarm in FM system in case of return to normal operation
    October 2010
    TPMS: System Description
  • 21. System administration
    System is managed from a single user interface as well as from the command line
    Allow system administrator to manage:
    System security
    Data in DB
    System components
    October 2010
    TPMS: System Description
  • 22. High-level roadmap
    October 2010
    TPMS: System Description
  • 23. First steps
    As a first step the Performance Monitoring core functions shall be done:
    Data Collection and Parsing,
    Data aggregation and normalization,
    KPI engine,
    Reporting (tables and charts)
    Components to be done first:
    Report viewer,
    Report designer,
    KPI editor,
    User GUI
    October 2010
    TPMS: System Description
  • 24. Next steps
    Following Performance Management functions and components shall be added later:
    Alarm engine,
    Northbound interface,
    Administration GUI,
    Collection and parsing visual designer,
    Decision Support System,
    Forecast (What-If),
    Root-cause analysis
    October 2010
    TPMS: System Description
  • 25. Thank you.
    October 2010
    TPMS: System Description
    October 2010
    This document is licensed under CC BY.