ngen oss bss - architecture evolution
DESCRIPTION
TRANSCRIPT
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
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
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
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
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
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
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
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
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
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
OSS/BSS: new challenges
Pressure
• More productivity
No time for new systems
• More Customers and Services
System overloaded
• More authomation
Business Process Management & re-ingineering
2222
OSS/BSS: new challenges
Pressure
• More functionalities
• Tailored services
Systems become patchwork of functionalities
2323
OSS/BSS: new challenges
Pressure
• Short time-to market
No time to build new infrastructure, simply adapting old systems to new requirement
2424
OSS/BSS: new challenges
Pressure
• New network technology are quickly introduced
• Each has its own management system
More complexity to manage
Configuration, Activation, … become a challenge
2525
OSS/BSS: new challenges
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
NGOSS framework: Tools and Lifecycle
The way (Lifecycle)
Business View
• Identification of Business Needs(Business Requirement)
• Artifacts:
• eTOM (Process)
• SID (Information)
34
NGOSS framework: Tools and Lifecycle
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
NGOSS framework: Tools and Lifecycle
The way (Lifecycle)
Business View
System View
Implementation view
• Validating the proposed solution
• COTS mapping
• Thecnology mapping
• Pilot
• Artifacts:
• Proposed solution
• Proposed architecture
36
NGOSS framework: Tools and Lifecycle
The way (Lifecycle)
Business View
System View
Implementation view
Deployment View
• Realizing the solution
3737
NGOSS framework: Tools and Lifecycle
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
eTOM: Ops horizontal Level 2 processes
42
eTOM: Ops horizontal Level 3 processes
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
NGOSS framework: Tools and Lifecycle
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
2. Street Address, Zip code
3 Last 4 digits SSN
4. Customer Account number
CRM
Translator
Customer:
1. Customer ID number
2. Social Security number
3. First name, last name
4. Street Address, Zip code
Trouble Ticketing
Translator
Customer:
1. Customer ID number
2. Last name, first name, middle
init
3. Zip code, street address
Service Ordering
Translator
47
SID: applying NGOS principle
Customer:
1. Last Name, First Name
2. Customer ID number
3. Street Address, Zip code
4. Social Security number
Billing CRM
Trouble Ticketing Service Ordering
Customer:
1. Last Name, First Name
2. Customer ID number
3. Street Address, Zip code
4. Social Security number
Customer:
1. Last Name, First Name
2. Customer ID number
3. Street Address, Zip code
4. Social Security number
Customer:
1. Last Name, First Name
2. Customer ID number
3. Street Address, Zip code
4. Social Security number
Customer:
1. Last Name, First Name
2. Customer ID number
3. Street Address, Zip code
4. Social Security number
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
NGOSS framework: Tools and Lifecycle
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
NGOSS framework: Tools and Lifecycle
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?
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]