Java Service Logic Execution Environment (JSLEE)

Java Service Logic Execution Environment (JSLEE)
A Service Logic Execution Environment (SLEE) is a well known concept in the telecommunications industry. A SLEE is a high throughput, low latency event processing application environment. JSLEE is the Java standard for SLEE.
JSLEE is designed to allow implementations of the standard to meet the stringent requirements of communications applications, such as network signaling applications. The JSLEE specification is designed so that implementations can achieve scalability and availability through clustering architectures.
JSLEE is an industry standard aimed at portable communications applications, i.e. a communications application can be written once and run on many different implementations of JSLEE. Application portability is made possible by the combination of a programming language API (specified using the Java programming language), an unambiguous technical specification, a Reference Implementation, and a rigorous suite of tests that a vendor must pass before their product is compliant with the JSLEE specification.
JSLEE is the point of integration for multiple network resources and protocols. Applications can use many different external network resources from within the JSLEE environment.
The JSLEE specification allows developers to write robust components as integrates the ACID properties of transactions into the programming model. Components can be composed to solve more complex problems.
JSLEE is also known as JAIN SLEE due to its initial origination under the JAIN program

OSS architecture

A lot of the work on OSS has been centred on defining its architecture. Put simply, there are four key elements of OSS:
Processes
the sequence of events
Data
the information that is acted upon
Applications
the components that implement processes to manage data
Technology
how we implement the applications
During the 1990's, new OSS architecture definitions was done by the ITU-T in its TMN model. This established a 4-layer model of TMN applicable within an OSS:
Business Management Level (BML)
Service Management Level (SML)
Network Management Level (NML)
Element Management Level (EML)
(Note: a fifth level is mentioned at times being the elements themselves, though the standards speak of only four levels) This was a basis for later work. Network management was further defined by the ISO using the FCAPS model - Fault, Configuration, Accounting, Performance and Security. This basis was adopted by the ITU-T TMN standards as the Functional model for the technology base of the TMN standards M.3000 - M.3599 series. Although the FCAPS model was originally conceived and is applicable for an IT enterprise network, it was adopted for use in the public networks run by telecommunication service providers adhering to ITU-T TMN standards.
A big issue of network and service management is the ability to manage and control the network elements of the access and core networks. Historically many efforts have been spent in standardization fora (ITU-T, 3GPP) in order to define standard protocol for network management, but with no success and practical results. On the other hand IETF SNMP protocol (Simple Network Management Protocol) has become the de-facto standard for internet and telco management, at the EML-NML communication level.
From 2000 and beyond, with the growth of the new broadband and VoIP services, also the management of the home networks is entering the scope of OSS and network management. DSL Forum TR-069 specification has defined the CPE WAN Management Protocol (CWMP), suitable for managing home networks devices and terminals at the EML-NML interface.
Most recently the TeleManagement Forum (TMF) has developed a communications domain model that provides the basis for clarifying the distinction between OSS and BSS systems. As shown in the figure the OSS supports the traditional Resource and Resource Facing Service domains. Whereas the BSS supports the more Customer Facing domains.

network management systems

This is a partial list of network management systems.

Alcatel 5620 Network Manager & Service Aware Manager
Argus open-source network and systems monitoring software
Attachmate NetIQ AppManager & SecurityManager
AutoScan-Network - AutoScan-Network is a network discovering and managing application
Blue Coat Proxy Servers for WAN Optimization and Web cache
CA Unicenter Network and Systems Management
CA Spectrum (formerly Aprisma Spectrum)
Cacti- network statistics graphing tool.
Castle Rock Computing SNMPc- Network monitoring and reporting system.
Cisco Active Network Abstraction A network resource management platform for large networks
CiscoWorks CiscoWorks Lan Management Solution Manages enterprise switching networks
Cisco Network Analysis Module Analyzes live network traffic
Comarch Comarch OSS Suite
ECI Telecom LightSoft Multidimensional Network Management System
Ericsson OSSRC - Operations Support System, Radio and Core
Ganglia - an opensource distributed monitoring system for HPC clusters and grids
Hewlett Packard OpenView framework
Hewlett Packard HP OpenView TeMIP
Hyperic Open source application, system and network monitoring software for web-based applications
IBM AURORA Network Performance Profiling System
IBM Tivoli NetView
Intellipool Network Monitor
IPHost Network Monitor Mail, web, database, and other servers monitoring tool
LabTech Affordable network management and help desk system for MSPs, IT solution providers, and Corporate IT environments.
Lucent VitalSuite Network and Service Management Software
Lucent Navis Optical Management System (OMS)
Microsoft Operations Manager (MOM)
MOATIS Wide Area Management Services (managementasaservice.com)
MRTG
Nagios open source application
NetBoss Service Assurance and Element Management
NetDirector open source change and configuration management
Netdisco Web-based network management tool targeted at large corporate and university networks.
NetQoS
NetFlow Monitor from CESNET
Nokia Open EMS
Nortel Enterprise Network and Service Management
Nortel Enterprise Network Management System
Nortel Enterprise Policy Manager
Nortel Enterprise Switch Manager
Nortel Proactive Voice Quality Management
Network Administration Visualized (NAV) from Norwegian University of Science and Technology
ODCNMS Open DataCenter Network Management System released under the GPL.
Observer (Software) Free software network monitoring platform with BSD license.
Op5 Monitor - Open Source network monitoring
OpenNMS Open-source network management platform released under the GPL.
OPNET Technologies Sentinel software for network configuration auditing and change validation
Opsware Opsware Network Automation System (NAS).
PacketTrap - Network Management Software Provider.
PathSolutions Switchmonitor Network Performance Monitoring System
PRTG Traffic Grapher
PrefixNE Network Management Software by Prefix IT Ltd.
ProCurve Manager (PCM+) Comprehensive Management Software for products by ProCurve Networking by HP (base version free)
Rackwise Data Center Manager - Management of physical datacenter infrastructire
Raritan Computer's CommandCenter NOC
ServersCheck Monitoring Software agentless & browser based systems monitoring software
Siemens Integrated Network Management Services / System by Siemens
SNM open source application
Snort (software) Open Source intrusion detection system
SolarWinds Network Management Software Provider
Spiceworks - Free Network Monitoring Software for Network Management
StorageIM - Free Network Monitoring Software for Storage Resource Management
TTI Telecom Service Assurance, Netrac Product Lines
DNA (Dynamic Network Abstraction) by Sheer Networks (acquired by Cisco Systems)
WhatsUp Gold Network monitoring solutions
ZABBIX open source application and network monitoring solution. *nix, Apache, PHP, MySQL or PostgreSQL. GPL
Zenoss commercial open source applications, server, and network management solution

Business Support Systems (BSS)

Business Support Systems (BSS) are the components that a telephone operator or telco uses to run its business operations. The term BSS is no longer limited to telephone operators offering mobile to fixed and cable services but also can apply to service providers in all sectors such as utility providers.
Typical types of activities that count as part of BSS are taking a customer’s order, managing customer data, managing order data, billing, rating, and offering B2B and B2C services. Business Support Systems are linked to Operational Support Systems (OSS) in the enhanced Telecom Operations Map (eTOM) that maps processes into the functional areas of Fulfilment, Assurance and Billing where Assurance is typically covered by OSS platform. BSS and OSS platforms are linked in the need to support various end to end services. Each area has its own data and service responsibilities.

Role of Business Support Systems
The role of Business Support Systems in a service provider is to cover four main areas:
Product Management
Customer Management
Revenue Management
Fulfillment Management
Product Management:
Product management supports the sales and management of products, offers and bundles to businesses and mass-market customers. Product Management regularly includes offering cross-product discounts, appropriate pricing and customer loyalty programmes.
Customer Management:
Service Providers require a single view of the customer and regularly need to support complex hierarchies across customer-facing applications. Customer Management also covers requirements for partner management and 24x7 Web-based customer self-service. Customer Management can also be thought of a full-fledge Customer Relationship Management systems implemented to help customer care agents handle the customers in a better and informed manner.
Revenue Management:
Revenue Management is a BSS focus on billing, charging and settlement, that can handle any combination of OSS services, products and offers. BSS Revenue Management supports OSS order provisioning and often partner settlement.
Fulfillment Management:
Fulfillment Management as part of assurance is normally associated with Operational Support Systems though Business Support Systems are often the business driver for Fulfillment Management and order provisioning.

Job Description: Senior Consultant

TMF Consensus

TMF Consensus

• •Web/Java user interface
• •CORBA to link business application
• •SNMP manage the network

TMF Direction

•Interoperable OSS: as the de-facto standard.

–Multi-Service Providers, Vendors, Technologies, .…

–Common Business process and Components

•Source of new technologies for OSS developments.

–COTS, CORBA, XML, SOAP, JINI, …

•International Promotion for OSS products.

–Catalyst Showcase，Product　Expo…

TMF Products

•TMN/C++API

• –TMN AP Development Environment
• –GDMO/C++ Information Model API
• –CMIS/C++ Protocoｌ; API
• –ASN.1/C++ ASN.1 API

•A CORBA-CMIP-SNMP Inter-working

• –CMIP/GDMO to CORBA IDL
• –CORBA IDL to CMIP/GDMO
• –SNMP MIB to CORBA IDL

OSS Architecture Case Studies

XML over CORBA

OSS/J Focus areas

Multi Domain Management

Interoperable OSS : TMF Direction

•Interoperable OSS: as the de-facto standard.

–Multi-Service Providers, Vendors, Technologies, .…

–Common Business process and Components

•Source of new technologies for OSS developments.

–COTS, CORBA, XML, SOAP, JINI, …

•International Promotion for OSS products.

–Catalyst Showcase，Product　Expo…

TMF Consensus

•Web/Java user interface

•CORBA to link business application

•SNMP manage the network

TMF Products

•TMN/C++API

–TMN AP Development Environment

–GDMO/C++ Information Model API

–CMIS/C++ Protocoｌ; API

–ASN.1/C++ ASN.1 API

•A CORBA-CMIP-SNMP Inter-working

–CMIP/GDMO to CORBA IDL

–CORBA IDL to CMIP/GDMO

–SNMP MIB to CORBA IDL

Members’ Target of TMF Activities

•Products Promotion

Proof of Interoperability

　 Products Exhibition

by

•Obtaining New Technologies and Know-how

Business Process

Software Architecture, COTS, PnP　

•Establishing Partnership/Networks

Service Providers

ISVs, System Integrators, OSS vendors

Relationships between Telecommunication Network and TMN

Telecommunications Management Network (TMN)

•Telecommunications Management Network (TMN)
•TMN project started fall 1985
•Initial recommendation CCITT M.30 (published in 1988) included work of several Study Groups
•Renamed to recommendation M.3010 in 1992 which defines basic principles for TMN
•The objective for the TMN specifications is to provide a framework for telecommunications network and service management

•Why TMN?

•

To survive in a highly innovative and competitive telecommunications market, use of a robust architecture for network and service management is a must.

The TMN Framework:
•ensures interoperability
•ensures scalability
•is mature (large amount of telecom standards in GDMO)
•provides security
•

•TMN Principles

•TMN Recommendations from ITU-T
•Objectives
•Relationship of a TMN to a Telecom Network
•TMN Functional Architecture
•TMN Information Architecture
•CMIP/CMIS
•TMN Physical Architecture
•Logical Layered Architecture
•

•TMN Recommendations from ITU-T

M.3010	Principles for a telecommunications management network
M.3100	Generic network information model
M.3200	TMN management services
M.3300	TMN management capabilities at the F interface
M.3400	TMN management functions

•The M.3010 recommendation defines “general architectural requirements for a TMN to support the management requirements of administration to plan, provision, install, maintain, operate and administer telecommunication networks and services”
•
•The basic concept behind a TMN is to provide a organized architecture to achieve the interconnection between various types of OS’s and/or telecommunications equipment for the exchange of management information using an agreed architecture with standardized interfaces including protocols and messages
•

•TMN Functional Architecture

•The TMN functional architecture explains the distribution of functionality within a TMN

•Distinction must be made between:

–Role that a function performs (controlling, mediator role, management user oriented, information transport)

–Actual function that is performed (configuration management, fault management, etc.)

•Recommendation M.3010 concentrates on roles whereas M.3400 deals with functions

•

The TMN functional architecture is defined by:

•TMN function blocks, being the roles in which functions operate (coordinate, mediate, etc.)

•

•TMN function points, being the service boundary between two communication management function blocks

•Function blocks defined within M.3010:

•

–OSF Operation Systems Function

–MF Mediation Function

–WSF Work Station Function

–NEF Network Element Function

–QAF Q Adaptor Function

•Reference points defined within M.3010 (g and m are located outside the TMN):

–q class between OSF, QAF, MF and NEF

–f class for attachment of a WSF

–x class between OSFs of two TMNs or between TMN OSF and OSF-like

function in other network

–g class between WSF and users

–m class between QAF and non-TMN managed entities

•

•In order to allow effective definition of managed resources, TMN makes use of OSI Systems Management principles and is based on an object-oriented paradigm.

•

•Management systems exchange information modeled in terms of managed objects (MO)

•

•Because the environment being managed is distributed, network management is a distributed application which requires exchange of information.

•For a specific management association, the management processes will take one of two possible roles:

–Manager, which issues operation directives and receives notifications

–Agent, responds to directives and emits notifications (deals with the MO’s)

•

•The element management layer (EML) manages each network element on an individual basis and supports an abstraction of the functions provided by the NE layer.

•Each element manager has the following principle roles:

–control and coordination of a subset of network elements

–provide a gateway function to permit the network management layer to interact with network elements

–maintaining statistical, log and other data about elements

•OSFs in the element layer always interface with OSFs in the network management layer through the q3 reference point

•

•The network management layer (NML) has the responsibility for the management of all the NE’s, as presented by the EML, both individually and as a set.

•The NML has the following principle roles:

–control and coordination of the network view of network elements within its scope or domain

–the provision, cessation or modification of network capabilities for the support of service to customers

–interact with the service management layer on performance, usage, availability, etc.

•OSFs in the NML always interface with OSFs in the service management layer through the q3 reference point

•

•Service management layer (SML) is concerned with, and responsible for, the contractual aspects of services that are being provided to customers or available to potential new customers.

•Principle roles for the SML:

–customers facing and interfacing with other administrations

–interaction with service providers

–interaction with the SML

–maintaining statistical data (e.g., QoS)

–interaction with the business management layer

–interaction between services

•

•The business management layer (BML) includes all the functions necessary for the implementation of policies and strategies within the organization which owns and operates the services (and possibly the network)

•The BML:

–interacts with the service management layer

–Is influenced by high levels of control such as legislation or macro-economic factors (e.g., tariffing policies, quality maintenance strategies)

•

•FCAPS !

• •Fault management

• •Configuration management

• •Accounting management

• •Performance management

• •Security management

•TMN Strengths

•TMN is a very suitable framework for telecommunications management purpose since:

–It identifies different abstraction levels

–It forces a structure approach when faces with the problem of network and service management

–It is a widely adopted standard, which ensures that everyone speaks the same language

•TMN is particularly strong at the bottom layers of the TMN pyramid, using the power of OSI systems management and the associated object approach

•

•High interoperability by standardizing

–protocol

–information model

–services

–MIBs

•scalability by well-developed reliable “event channel” (notifications with EFD discriminators)

•complex types (structures)

•scoping and filtering (OSI modeling)

•TMN offers security, which is essential at EML and X interface

•

•TMN weaknesses

•Implementation of TMN isn’t so easy

•TMN Q3 interface is based on a full OSI stack (solutions for stacks with reduced functionality are developed, e.g., CMIP on TCP/IP)

•GDMO and ASN.1 are very complex (solution is the use of tools that hide GDMO and ASN.1). ASN.1 is designed for completeness, not simplicity.

•TMN functional architecture does not map very well to service management. It originates from the bottom layers of the pyramid

•

•