Ngen oss bss - architecture evolution

1

Gr a z i o Pa n i c oO S S / B S S S o l u t i o n D e l i v e r y

[email protected]

NGEN OSS/BSS

Architecture evolution

2

Content• Next Generation OSS/BSS

• Business Process Management (BPM)

• IP Multimedia Subsystem (IMS)

• Cloud Computing

3

Next GEN OSS/BSS• Telecom Management Network

• Next Generation Operation Systems & Software

44

OSS & BSS: a definitionOperation Support System

• suite of software designed specifically to manage a large network infrastructure,

connecting individual sub-systems

• supporting processes

• maintaining network inventory,

• Provisioning services

• configuring network components

• managing faults

Business Support System

• complementary to OSS, typically refers to "business systems" dealing with customers

• supporting processes

• Order Management,

• Billing and Payments processing

• Customer care

• Sales support

• …

55

OSS & BSS: evolution history

Before 1970

• OSS activities were performed by manual administrative processes

Then come

computers

• Specialized Legacy Applications

• Swivel Chair Integration

1990s

TMN

2000

Next Generation OSS/BSS

66

OSS/BSS: early needs Saving Investments

• For many operations, operational costs for network and service management are higher than

equipment costs

• Changing service and equipment needs within operational platforms are common practice

(competition)

Competition

• Enable Time-to market

• Do More with Less

Interoperability

Integration

• Most as swivel chair integration

Management

• Networks, Service and Business

77

TMN Reference Model (Hierarchical) Telecommunication Management Network

Joint effort by ITU-T and ISO (from 1988 to 1996) - Recommendation M3010

Objective

• 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

Other TMN

Data Communcation

Network

Telecommunication

Network

88

TMN Architecture Functional architecture

• Functional modules

• Reference points between modules

Physical architecture

• Physical Building Blocks

• Physical interfaces between blocks

Informational architecture

• Information exchange between entities

• Object oriented

Logical Leyered architecture

• Responsabilities

Architecture

Funzional Physical Informational Logical Layerd

99

TMN Architecture Functional architecture

• Role that a function performs

• OSF, NEF, MF, WSF, QAF

• Management function that is

performed

• Falt, Configuration, Accounting, Performance,

Security

• Reference points between modules

• Interface

• OSF (Operations System Functions): NMS, testing, accounting, trouble

tracking

• NEF (Network Element Functions): NM agent, MIB, collision rate

• MF (Mediation Function): Operations on the information between network

elements; e.g. filtering, protocol conversion. MF can be shared between

multiple OSSs; e.g. RMON

• WSF (Workstation Functions): Human-TMN activities interface; e.g., GUI

• QAF (Adapter Functions): to accommodate non-TMN entities; e.g. proxy

server, SNMP-to-CMIP

No TMN system

1010

TMN Architecture Informational architecture

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

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

• Two type of communication services: interactive (rpc) and file oriented (ftp):

Managed object are identified by

• the attributes visible at its boundary

• the management operations which may be applied to it

• The behavior exhibited by it in response to management

operations or in reaction to other types of stimuli (e.g.,

threshold crossing)

• The notifications emitted by it

1111

TMN Architecture Phisical architecture

• Identifies physical build block

• Define how function blocks and reference point can be implemented (maps)

• OS: Operations Systems

• MD: Mediation Device

• QA: Q-Adapter

• NE: Network Elements

• DCN: Data Communications Network

• WS: Work Station

1212

TMN Architecture Logical Layered architecture

• The most valuable idea of TMN model

• Hierarchy of management responsibilities

• Layers of management functionality

• To deal with the management complexity

1313






Element Management Layer

• Function of NE are managed by OPFs in EML

• EML deal with vendor specific functions

• Hide NE function to NML

Example

• Detection of equipment errors,

• Measuring the temperature of equipment,

• Measuring the resources that are being used, like CPU-

time, buffer space, queue length etc.,

• Updating firmware

1414






Network Management Layer

• manages interaction between equipments

• is vendor independent

• provision, terminate, modify network capabilities

• Provide to SML informatio about performance, usage,

availability, etc.

Example

• creation of the complete network view,

• monitoring of link utilization,

• optimizing network performance, and

• detection of faults

1515






Service Management Layer

• Responsible for aspect facing directly with with

Customer or other Providers

Example

• Quality of Service (delay, loss, etc.),

• Accounting,

• Addition and removal of users

The most valuable contribute to other framework

1616






Business Management Layer

• Responsible for management of whole Enterprise

• Define Policies and Strategies to manage services

(and networks)

• Deal with Legislation, Economics factors (pricings,

competitors, etc.)

1717

TMN Architecture: an example

1818

TMN strengths/weakness Strengths

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

• It identifies different abstraction levels

• It is component based

• It forces a structured 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

• Hight Interoperability, by standardizing

• Protcols, Information models, Services

• Scalability

• using the power of OSI systems management and the associated object approach

• Security, which is essential at Element Management Layer (EML)

Weakness

• Implementation of TMN isn’t so easy

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

bottom layers of the pyramid

• TMN is particularly strong at the bottom layers

19

Next GEN OSS/BSS• Telecom Management Network

• Next Generation Operation Systems & Software

2020

OSS/BSS: new challenges

2121


Pressure

• More productivity

No time for new systems

• More Customers and Services

System overloaded

• More authomation

Business Process Management & re-ingineering

2222


Pressure

• More functionalities

• Tailored services

Systems become patchwork of functionalities

2323


Pressure

• Short time-to market

No time to build new infrastructure, simply adapting old systems to new requirement

2424


Pressure

• New network technology are quickly introduced

• Each has its own management system

More complexity to manage

Configuration, Activation, … become a challenge

2525


Pressure

• New Technology are available

Need for a new approach

2626

OSS/BSS: system health Legacy OSS systems

• Proliferation

• High cost to maintain and evolve

• No clear scope

• No open interface

No integration infrastructure

• Point to point integration

• spaghetti integration

• Swivel chain Integration

2727

OSS/BSS: system health Silos of OSS end BSS

• New Technology New OSS Silos

• New Service New OSS Silos

High manpower costs

• because of a lack of automated process flow-through

• Duplication of Systems, Functions, Data

• Much more maintenance cost

It is much more convenient to build an entire set ofOSS system instead of integrating or extend existingones!!

2828

OSS/BSS: system health High manpower costs

• because of a lack of automated process flow-through

Poor time-to-revenue

• because of have rigid and inflexible business processes

Weak customer service

• because of poorly integrated & systems with inaccurate data

Slow growth

• because processes and systems can’t scale

Slow new service introduction

• because of high risks & costs to make system changes

Poor economies of scale

• because of using hundreds of suppliers

2929

OSS/BSS: process automation landscape

Process

Automation is

not optimized

Thousands

of

discrete

processes

Hundreds or

thousands of

discrete

OSS/BSS

applications

Integration of

multiple

Applications

to achieve

automation

of a single

process

Limited by

complexity of

changing systems

to keep up with

process

enhancements

Changes not

affordable# process

# application

integration

change

30

Flexible, Automated Business Processes

Optimizing processes requires a multi-

step approach

• Defining and engineering processes

• Defining information in a common fashion

• Defining systems to implement processes

• Defining the interfaces between systems

• Defining the way the systems plug together(architecture)

The tools to achieve these steps are provided by NGOSS

from end-to-end

TMF Views

31

Who Needs a New Way to Do OSS?

Service Providers

• Operational agility

• Cost effective OSS/BSS implementations

• Long term direction for IT strategy

• IT systems that support rapidly evolving integrated services

OSS Software Vendors

• Affordable development costs

• Supportable Software

• Fitting into the OSS/BSS puzzle

Systems Integrators

• Predictable, repeatable, scalable, implementation projects

• Broader ISV portfolio without steep learning curve

32

NGOSS framework: Tools and Lifecycle

New Generation Operations Systems and Software

TM Forum program since 2000

• International non-profit Association

• Organize, guide, design and develop

Next Generation Management Systems

33


The way (Lifecycle)

Business View

• Identification of Business Needs(Business Requirement)

• Artifacts:

• eTOM (Process)

• SID (Information)

34


The way (Lifecycle)

Business View

System View

• Modeling the system solution

• System as “grey box”

• Interoperability

• COTS capabilities and policy

• Process flow between systems

• Artifacts:

• SID (Information)

• TNA (Distributed Architecture)

35


The way (Lifecycle)

Business View

System View

Implementation view

• Validating the proposed solution

• COTS mapping

• Thecnology mapping

• Pilot

• Artifacts:

• Proposed solution

• Proposed architecture

36


The way (Lifecycle)

Business View

System View

Implementation view

Deployment View

• Realizing the solution

3737


eTOM (Tool)

Business Process Framework for Enterprise

process

Common language between Service Providers

and their suppliers about what problem they are

trying to solve

• Define classification system for businessprocesses

• Inventory how processes are done today

• Design how SP wants processes to work

Problems to solve

• Define and prioritize problems in terms of business processes

• Where are the lines drawn around products?

ITU Standad!

38

Enterprise

Management

Strategy, Infrastructure & Product Operations

Customer

Fulfillment Assurance BillingProductLifecycleManagement

InfrastructureLifecycleManagement

OperationsSupport andReadiness

Customer Relationship Management

Service Management & Operations

Resource Management & Operations

Supplier/Partner Relationship Management

Strategic &EnterprisePlanning

Financial & AssetManagement

Enterprise QualityManagement, Process & ITPlanning & Architecture

Stakeholder & ExternalRelations Management

Strategy &Commit

Marketing & Offer Management

Service Development & Management

Resource Development and Management

Supply Chain Development and Management

Brand Management,Market Research &Advertising

Human ResourcesManagement

(Application, Computing and Network)

Disaster Recovery,Security & FraudManagement

Research &Development,TechnologyAcquisition

(Application, Computing and Network)

eTOM: the big picture

39

eTOM: Ops horizontal Level 1 processes

eTOM (Tool) – e Telecom Operation Map

Customer Management

• Acquisition

• Up selling

Service Management

• Service Configuration

• Service Assurance

Resource Management

• Resource provisioning

Partner/Supplier Management

• Supply chain processes

40

eTOM: Ops vertical Level 1 processes

eTOM (Tool)

Fulfillment (or provisioning)

• Customer Need into Solution

Assurance

• Network monitoring

• SLA management

• Trouble Ticketing

• Problem handling

Billing

• Rating

• Billing

• Usage collections

Operation Support & Readiness

41


42


43

eTOM: process flow: Ordering (Fulfillment)

4444

SID(Tool) – Shared Information Data

Common language of NGOSS-based

OSS/BSS systems

A reference manual defining the thousands

of pieces of information needed to map out

business processes


4545

SID: an example - Customer

Customer is one of the SID

“things” called “entities”

“Entities” under customer

46

SID: example of bad Information modeling

Customer:

1. Last Name, First Name

2. Customer ID number

3. Street Address, Zip code

4. Social Security number

Billing

Translator

Customer:

1. First name, middle init, last name


3 Last 4 digits SSN

4. Customer Account number

CRM

Translator

Customer:



3. First name, last name


Trouble Ticketing

Translator

Customer:


2. Last name, first name, middle

init

3. Zip code, street address

Service Ordering

Translator

47

SID: applying NGOS principle

Customer:





Billing CRM

Trouble Ticketing Service Ordering

Customer:





Customer:





Customer:





Customer:





48

The SID Framework

49

TNA(Tool) – Technology Neutral Architecture

Guidelines support the analysis, design,

implementation and deployment of

NGOSS-based open distributed

computing solutions

Defines contracts, the fundamental unit of

interoperability within an NGOSS solution


50

The NGOSS supports the following TNA

requirements

1. An NGOSS system must have re-useablesoftware entities that offer their services via open,well-defined interfaces known as contracts.

2. An NGOSS system must have all its externaldependencies explicitly defined.

3. An NGOSS system must be characterized by aseparation of the services offered by theconstituent components from the software thatautomates business processes across thecomponents.

4. An NGOSS system must support datastewardship. For each datum, there is a stewardthat controls access and modification of the datum.

5. An NGOSS system must support a commoncommunication mechanism like Java MessageService (JMS).

TNA: principles

51

Traditional OSS/BSS Architecture

Complex systems (overloaded)

Data + Process

Tightly coupled with each other (pair-wide

interfaces)

No communication BUS

No data ownership

A small change in one system typically would affect

all the systems which interfaced with the system

where the change was made.

52

TNA OSS/BSS Architecture

WiTech BPM.-enabled architecture

Communication Bus (ESB)

Application Services

Framework Services

BPMS (SOA)

Portals

Open Source Ready!

Cloud Ready!

53


Compliance

Tests for Compliance to eTOM, SID and

Architecture

Can test against parts or whole NGOSS

elements

Tests products and solutions

5454

NGOSS Compliance Testing

Focused on defining what is

testable in NGOSS and how to

test it

Working on defining an industry

testing commercial strategy

5555

NGOSS Sample Applications

• Business process redesign• Map and analyze business processes to improve efficiency

• Component development • Software engineering to create a new OSS component

• Component integration• Integrating disparate OSS components

• RFP process• Design and specify new OSS solutions using NGOSS

• Create a new service• Modify OSS/BSS to add or change service parameters

56

Who’s backing NGOSS?

/

http://www.motorola.com/t900/

http://www.motorola.com/v22xx/

http://www.motorola.com/t900/

http://www.bt.com/index.jsp?BV_SessionID=@@@@0395949565.0979914516@@@@&BV_EngineID=ialjljlmmgfbekfcfkcfcgfo.0

http://www.hp.com/Redirect/gw/useng_welcome/logo/=http:/welcome.hp.com/country/us/eng/welcome.htm

/

http://www.nokia.com/

/

http://www.nec.com/index.html

http://www.jacobsrimell.com/jrhome.htm

57

WiTech SpaVia Giuntini 25

56023 Cascina Loc. Navacchio (PISA)Italy

www.witech.it

Phone: +39 050 775 056Fax: +39 050 75 47 22

Mobile: +39 347 516 44 01E-mail: [email protected]

Thank you for your interest!

For more information, please visit our web site, call us or send us an e-mail!

Grazio PanicoNGOSS solution delivery [email protected]

http://www.witech.it/