oss bss_futures_overview

Frameworx Exploratory Report
OSS/BSS Futures Overview
Why OSS needs to change
TM Forum 2014. All Rights Reserved.
IG1117
Release 14.5.0
October 2014
Latest Update: Frameworx Release 14.5 Member Evaluation
Version 14.0.5 IPR Mode: RAND

© TM Forum 2014. All Rights Reserved. Page 2 of 32
Notice
Copyright © TM Forum 2014. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative
works that comment on or otherwise explain it or assist in its implementation may be
prepared, copied, published, and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this section are included on all such
copies and derivative works. However, this document itself may not be modified in any way,
including by removing the copyright notice or references to TM FORUM, except as needed
for the purpose of developing any document or deliverable produced by a TM FORUM
Collaboration Project Team (in which case the rules applicable to copyrights, as set forth in
the TM FORUM IPR Policy, must be followed) or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be revoked by TM FORUM
or its successors or assigns.
This document and the information contained herein is provided on an “AS IS” basis and TM
FORUM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Direct inquiries to the TM Forum office:
240 Headquarters Plaza,
East Tower – 10th Floor,
Morristown, NJ 07960 USA
Tel No. +1 973 944 5100
Fax No. +1 973 944 5110
TM Forum Web Page: www.tmforum.org

Table of Contents
Notice .................................................................................................................................. 2
Table of Contents ................................................................................................................. 3
Table of Figures.................................................................................................................... 5
Executive Summary .............................................................................................................. 6
1 Business Drivers ............................................................................................................... 7
1.1 Agility .................................................................................................................... 7
1.2 Partnering and Openness ........................................................................................ 7
1.3 Customer Experience .............................................................................................. 7
2 Why virtualization changes OSS/BSS management............................................................. 9
2.1 Impact on OSS Realization ...................................................................................... 9
2.2 Impact on OSS Functionality .................................................................................... 9
3 How OSS/BSS technical approaches need to adapt............................................................11
3.1 Agility Drivers – technical approaches .......................................................................11
3.1.1 Processes – Dev Ops ......................................................................................11
3.1.2 Technical Best Practices for Agility.....................................................................13
3.2 Partnering Drivers – technical approaches.................................................................15
3.2.1 Partnering ......................................................................................................15
3.3 Agility Drivers - Standards Design Approaches...........................................................16
3.3.1 What kind of standards? ...................................................................................17
3.3.2 An analogy is useful. ........................................................................................17
3.3.3 How does this help timeliness?..........................................................................18
3.3.4 Integration technologies ...................................................................................18
4 OSS/BSS support for future operations .............................................................................19
4.1 Evolving Operations ...............................................................................................19
4.1.1 Implication of Dev Ops on OSS/BSS Futures ......................................................19
4.1.2 Implication of Net Ops DevOps convergence ......................................................19
4.2 Technical Capabilities .............................................................................................20
4.2.1 Support for multi-partner changing business models.............................................20
4.2.2 Agile multi-vendor, multi-technology integration....................................................21
4.3 Technical Methodology ...........................................................................................21
4.3.1 Organizational Impacts.....................................................................................21
4.3.2 Merging of cultures across multiple businesses....................................................21
4.3.3 ZOOM Technical Standards..............................................................................22
4.4 Deployment environment ........................................................................................22
4.4.1 Migration to a hybrid virtualized environment .......................................................22
5 Results from ZOOM Fx 14-5 ..............................................................................................23
5.1 NFV Readiness Theme #3 ......................................................................................23
5.1.1 Virtualization Procurement and Operations Impacts .............................................23
5.1.2 Hybrid current and virtualized networks ..............................................................23
5.2 End to end Management Theme #2 .........................................................................24
5.3 Impact of Policy .....................................................................................................24
5.3.1 Changes to policy management ........................................................................24
5.3.2 Changes to how SLAs are delivered ..................................................................25
5.3.3 Changes to how we think about security .............................................................25
5.4 Relevant TM Forum catalyst results and studies .........................................................26
6 Future areas of study ........................................................................................................28
6.1.1 Orchestration ..................................................................................................28
6.1.2 Service chaining..............................................................................................28
6.1.3 Virtualization Maturity Model .............................................................................28
7 References .......................................................................................................................29
7.1 References ...........................................................................................................29
8 Administrative Appendix ...................................................................................................32

8.1 Document History ..................................................................................................32
8.1.1 Version History................................................................................................32
8.1.2 Release History...............................................................................................32

Table of Figures
Figure 1 Introduction of explicit Virtualization 9
Figure 2 Traditional Telco OSS/BSS Landscape 11
Figure 3 Application, Product and Service lifecycle processes 12
Figure 4 Shift form Vertical product service stacks to platforms 13
Figure 5 Components support multiple views 14

Executive Summary
Virtualization is a trend that is sweeping across the IT and Communications
industries and in its wake it is bringing radical change to technical solutions,
development methods and operations practices.
Recent publications from ETSI1 on Network Functions Virtualization (NFV) have
provided early insight as to how Network Functions can be virtualized by adaptions
of virtualization techniques for Compute, Storage, and Network developed by the
IT industry.
In the initial ETSI work, a decision was taken to assume that existing legacy OSS
/BSS was out of scope, and that NFV would be supported by additional functions
added to both Networks and OSS /BSS solutions.
However TM Forum studies in the ZOOM Project have shown that the ultimate
impact of NFV on OSS/BSS will be significant, and that it will require a
transformation of both OSS/BSS solutions, and Service Provider (SP) operational
practices.
The reasons for this are that the ultimate goals of NFV are improving agility in
introduction of services together with saving operational costs It turns out that
current OSS and BSS solutions are a significant barrier to achieving overall service
agility, unless they too are re-engineered. This document overviews the necessary
changes to OSS/BSS design and implementations that are further developed in the
OSS/BSS Futures Framework [23], reviews some of the related results from Fx 14-
5 studies and catalysts demonstrations at TM forum Live Nice 2014.
The evolution of OSS/BSS Futures is needed to support the ZOOM requirements
of:
o Theme #1: DevOps Transformation Framework for the Digital
Ecosystem
o Theme #2: Blueprint for End-to-End Management
o Theme #3 NFV Readiness for Procurement and Operations
Interestingly the studies have shown that two pieces of prior work conducted by the
TM Forum are highly relevant to OSS/BSS Futures:
o Cloud Service management – the Digital Service Reference Architecture
–DSRA [4] has developed some relevant frameworks for cloud
virtualization and the concept of a’ well enabled Service’. The ZOOM
OSS/BSS Futures framework has shown a simple extension of this
notion to a ‘well enabled Virtual Network Function’ e.g. weVNF.
o B2B2X Partnering Accelerator [8] [and associated APIs [7] has shown
how both business and technical partnering can be realized in an
industrialized agile way by adopting a set of business and design
patterns that lead to agile re-usable solutions and APIs.
This document is aimed at managerial and technical people interested in TM Forum
strategic directions of ZOOM and specifically management of virtualization.
Further information on the objectives of the ZOOM project is in the ZOOM Overview
[1].
1 ETSI European Telecommunications Standards Institute

1 Business Drivers
OSS/BSS Futures is driven by recognition of a number of business and technical
drivers that are impacting service provider OSS/BSS systems, operations
processes and organization.
Four themes have been identified by the ZOOM program as needing to be
addressed by the industry:
o Theme #1: DevOps Transformation Framework for the Digital
Ecosystem
o Theme #2: Blueprint for End-to-End Management
o Theme #3: Operations and Procurement Readiness
o Theme #4: Open Source and open Systems Direction
The detail of these themes is driven by User Stories captured in the TR 229 ZOOM
User Stories (which as an evergreen document is updated from time to time).
The OSS/BSS Futures framework addresses changes that support the needs of
Themes #1 and #2, and is impacted by requirements identified in Theme #3.
As SPs look to transform their business operations – a popular phrase is ‘becoming
a Telco 2.0’ – three business drivers have emerged2:
1.1 Agility
SPs are concerned to grow top line revenue by introducing profitable new services,
possibly in competition or co-operation with Over the Top (OTT) Providers. To
achieve this objective they need agile processes and systems for developing and
operating new services, and the organization structures to enable this to happen.
What is needed is a clear view of best practice processes for product and service
lifecycle management, and how to adopt and adapt IT best practice for developing
and operating new services.
1.2 Partnering and Openness
Reducing time to market and costs for new services requires SP to establish their
core value and partner with other enterprise to co-provide services. This is most
noticeably required for cross industry solution such as those needed for the Internet
of Things (IoT), Smart TV, Smart Home, Smart Cities, Smart Grids, and e-Health.
The consequences of the need for partnering in new services is that a repeatable,
agile and industrial scale solution to partnering is required; based on reuse of
components and open APIs through configuration rather than by programming.
1.3 Customer Experience
Notwithstanding the other business drivers an overriding business driver is to
maintain and improve customer experience and engagement. Whilst agility and
partnering contribute to improved customer experience they are in themselves not
2 All of these are strongly influenced by regulation and legal differences in different territories for example data protection
law ful interception, etc.

enough; and the disciplines of customer experience need to be maintaining and
improved during business transformation. The TM Forum has an extensive body of
tried and tested methods for Customer Experience Management in its Customer
Engagement Program [3] which addresses e2e management of services.
Customer Self Service
One emerging need is customer defined and controlled networking where the
customer can self-configure services to meet their exact needs. This places
stringent demands for zero touch operation on the technical solutions for OSS/BSS,
particularly a need for high levels of automation.

2 Why virtualization changes OSS/BSS management
In addition to the business drivers impacting OSS/BSS Futures there are specific
drivers arising from the introduction of IT virtualization techniques and technologies
into NFV.
Virtualization technology developed by the IT industry creates two types of impacts/
opportunities for OSS/BSS Futures.
2.1 Impact on OSS Realization
OSS/BSS are intrinsically IT applications, and therefore can be realized by as
Software as a Service on industry standard server virtual machines. This facilitates
considerable flexibility in deploying these applications by both supplier and SP
providers using a range of business models.
2.2 Impact on OSS Functionality
Current network services are typically provided in physical network appliances or
equipment racks where there is a direct static relationship between the Network
Service and the Physical Resources. – see left hand side Figure 1.
Figure 1 Introduction of explicit Virtualization
Whilst these current Network Service applications typically include some form of
internal hypervisor or virtualization layer they are rarely explicitly exposed for direct
management control.
When virtualization is introduced – right hand side Figure 1 – the relationship
between the Virtualized Network Services / NFV Virtual Network Functions and the

Virtualization Infrastructure is directly exposed since the suppliers of these two
layers may be different. The relationship between virtualized and virtualization layer
is dynamic and have an M to 1 relationship to support virtualization requirements
for multi-tenancy, and scaling out /in.
The virtualization infrastructure is designed so that it can distribute Virtualized
Network Service workloads dynamically across multiple distributed compute,
storage and networks resources. This is needed to support the scale out and in
requirements whilst improving operational agility, flexibility and economy.
Clearly the management of work load demands, and their assignment to physical
resources has to be supported by management /control applications since it is this
ability to support dynamically changing relationships that provides the flexibility,
agility and cost saving potential of virtualization.
This requirement to manage dynamic workloads impacts OSS processes, tool
support and also organization, as there has to be explicit organizational
responsibility for planning and managing capacity dynamically at run time.
A further challenge is that these new network services have to be virtualized
services used in combination with current network services leading to a need to
manage Hybrid Network Service shown by the 1:X relationship above.

3 How OSS/BSS technical approaches need to adapt
3.1 Agility Drivers – technical
approaches
To support the business drivers of agility, and lower operations costs (OPEX),
modified technical approaches for OSS /BSS are needed covering: processes and
best practice techniques, technologies, and standards.
3.1.1 Processes – Dev Ops
Agility in technical solutions is a product of both the technical and architectural
design principles, and the processes that are used to develop technical solutions.
The traditional SP waterfall model of: selecting a supplier’s supporting system,
writing a 100+ page requirements document, then waiting for the supplier to
develop the solution, and then testing with them – is a process that takes typically
6-12 months. This has led to traditional OSS/BSS solutions being complex mesh
of proprietary products:
Figure 2 Traditional Telco OSS/BSS Landscape
Agile IT operations has evolved to a best practice called DevOps supported by a
number of industry tools – Service Mesh, CohesiveFT, Chef, Puppet, SevOne, Salt,
CF Engine, etc. – which are based on development and operation people working
in a single concurrent activity rather than sequentially as in the Waterfall model. The
key principles are:
o Incremental service definition
o Continuous integration
o Automated testing
o Automated interfaces to applications that facilitate continuous integration
and testing.
Within service providers there are product and service development lifecycle
models which need to be adapted to support these DevOps technique. However

these need to be extended to support complex service chains and performing
DevOps concurrently across multiple partner organizations.3
Figure 3 Application, Product and Service lifecycle processes
To achieve the operational efficiencies targeted by NFV and SDN, traditionally
separated operational processes need to become more closely linked and require
a high level of automation.
NFV basically turns Network Elements (NE) into pure software applications,
referred to as the Virtualized Network Functions (VNFs). The Application Lifecycle
Management for VNFs needs to apply and extends IT management practices to
Telco capabilities, and thus require TM Forum Frameworx to interwork with
standards & practices of IT management bodies such as ITIL4 and DMTF5.
For example, ITIL integration with Business Process Framework processes/best
practices needs to go beyond the Enterprise Management domain and should fully
link to or cover parts of the Application Lifecycle Management processes
everywhere across the Business Process Framework (aka eTOM).
Also, NFV and SDN introduce new capabilities (e.g. compute, storage, switch) and
components (NFV Orchestrator, SDN controller, etc.) which lead to additional
resources , services, processes, etc., where possible taken from existing bodies, or
else to be defined.
In TR229 ZOOM/ NFV User Stories [2] there are a number of user stories related
to DevOps that set out the actors and the process needs that they have for a
DevOps style of product and service lifecycle management.
3 For Fx14-5 we have put in place the enablers for DevOps to be applied to Network Functions Virtualization (NFV).
Examples of DevOps use in will be developed- for example – in catalysts before fully specifying the FX ZOOM DevOps
extension.
4 ITIL Information Technology Inf rastructure Library
5 DMTF Distributed Management Task Force

IG1100 Product Lifecycle Management Introductory Guide [26] provides a
comprehensive overview of the key principles and concepts for product lifecycle
management, and how Frameworx and specifically the Business Process
Framework and KPIs support effective Product/Application Lifecycle Management.
For ZOOM and virtualization/NFV these processes need to be automated, operate
faster and work with other partners.
3.1.2 Technical Best Practices for Agility
3.1.2.1 Platforms/Modules based on exposed Service APIs
This approach moves OSS/BSS design from the traditional waterfall model:
o To a model whereby these target OSS/BSS capabilities are packaged
as modular components with exposed APIs,
o That enable solution teams to use and configure them without any
support from the target OSS/BSS teams.
This is illustrated in the following example that shows a move from vertical
integrated Network and OSS stacks to horizontal layered modular platforms.
Figure 4 Shift form Vertical product service stacks to platforms
The critical thing to notice is that this affects both the platforms to provide services
offered to end customer e.g. Networks and control, and their supporting OSS and
BSS. Thus the impact and drivers are broader than just OSS/BSS change they
affect all applications including networking applications. The underpinning concepts
are based on service oriented design principles and are applicable to all
applications including OSS/BSS. This model is needed for common OSS /BSS
services such as: customer portal, API Gateway, billing, provisioning, etc., if they
are to be flexibly used by solution engineering teams.
Benefits include
o Greater flexibility and agility of solutions

o Clearly defined API interfaces that can be published and change
managed (governed) by the provider of the API. For example Amazon
EC2 can be used without having to write requirements for and interlock
with Amazon development teams
o Business Process workflow can be changed without re-coding the
business logic behind the APIs.
The TM Forum Digital Services Reference Architecture (DSRA) [4] [5] is based on
these principles.6
3.1.2.2 Composability of manageable services
ZOOM and DSRA [4] [5] studies have shown that for real world examples of new
digital services that it is necessary to compose services from other services and at
the same time be able to manage the composite service.
For networks it is necessary to create abstracted services that are layered of
composed from lower level services. At each layer of abstraction manageability is
needed.
The DSRA model introduces the notion of a ‘well enable service’ where every
service at whatever layer has a standard set of management services that are
designed to be composable.
So for example: a composite set of VNF services comprising: firewall, web
accelerators, and MPLS edge router; when each is realized with ‘well enabled
management interfaces’ could be composed into an enterprise access network
service function, which could be managed as a composite also using ‘well enabled
management interfaces’.
Figure 5 Components support multiple views
It shows one implication of this approach which is that the granularity of
management and the network service has to be aligned if it is to be possible to
compose services from other services. In current OSS/BSS practice the granularity
of management and the service is not always so clear. Note that management of a
service particularly in a legacy situation might be via a proxy rather than directly,
and literally, on the service component. This and other practical consideration are
6 The IG 1118 OSS/BSS Futures [23] Future Mode of Operations (FMO) and the subset of focused on OSS/BSS and
Control called Management Control Continuum (MCC) is based on proposals to enhance the DSRA.

described in the DSRA [4] and prior Service Delivery Framework [5] documents
and the IG1118 Future Mode of Operations (FMO) and Management Control
Continuum (MCC) enhancements.
Benefits of this approach are:
o Supports multi-vendor multi technology integrations
o Leads to a consistent way to manage any service at any layer of
abstraction
o Possible to dynamically create these composed management APIs i.e.
they are configured, not coded, leading to greater agility in creating
solutions.78
3.1.2.3 Separation of Business Process Workflow from application logic
This principle changes the common model for programming processes:
o from embedded process in applications i.e. move from a traditional
integration model of implementing processes in Applications, e.g. App A
calls code in App B which calls code in App C
o to a model based on “main loop calling app subroutines” as opposed to
‘goto’ style programming; Orchestration is one implementation approach
to this but not the only one.
Benefits include:
o Greater flexibility and agility of solutions as solution teams can change
Workflow without recoding applications.
3.1.2.4 Integration API Design Principles
Design of APIs needs to be based on well-established software design patterns
including:
o Loose Coupling, including inter-application ‘eventing’ infrastructure
supported via an event broker
o API Contracts
o and use Shared Information Model.
Many of these requirements are satisfied by the TM Forum Framework Integration
Framework Interfaces [6] and APIs [7].
A further Integration API design principle is that OSS management has to support
multi-technology, multi-vendor and multi-partner solutions. Simple to say but has
significant implication on how industry agreement are formed, managed, and
governed.
3.2 Partnering Drivers – technical
approaches
3.2.1 Partnering
Frequently with new digital services, the challenge is to set up arrangements
amongst multiple partners quickly to co-provide services.
7 TM Forum Live 14 Nice June 2104 Catalyst: Service Bundling in a B”B”X Marketplace Catalyst
8 TM Forum Live 14 Nice June 2104 Catalyst: Cloud NFV: Dynamic, data-driven Management and Operations

TM Forum B2B2X Partnering program [8] has created a method that allows the
establishment of agile business and technical partnerships on a repeatable
industrial scale. It is based on members’ operational experiences (including BT,
NBN Co, NTT, Orange and others) and requires:
o Business people to capture a partnership model definition in a
systematic way using a set of templates based on reusable concepts
and components.
o Developers to use the partnership model definition to quickly configure
pre-defined reusable concepts, components, (Gateways) and APIs.
These focus on operational processes between partners such as
ordering, configuration, catalog information exchange, trouble or incident
management, billing and capacity scaling management processes.
It has been practically demonstrated in multiple TM Forum Catalyst projects [9] [10].
The key elements of the Partnership Model are five aspects or perspectives:
1. Customer market proposition aspect captures the unique business
concept for the agreement to be created. This stage uses the industry
standard Osterwalder Business Model Canvas9 analysis method to
capture the business model requirements as inputs to creation of the
Partnership Agreement. This is where the products to be developed or
supplied by each partner are defined.
The Customer and Market Neutral Partnership Agreements address:
2. Business Model: including business roles, service interactions and
product/service relationships that partners hold within a value chain or
fabric e.g. instant messaging, access networks, cloud service, etc.
3. Commercial Model: including business rules and policies, terms and
conditions
4. Financial Model: including revenue principles and flows including
rebates and dispute resolution
5. Operational Model: including both functional and non-functional
requirements – such as process performance, reliability, etc. It is
based upon defining a set of Touchpoints that can be implemented as
APIs –working examples in WS and REST have been specified.
In the ZOOM catalyst projects [9] [10], it has been demonstrated that the touch
points can be defined using a standard verbs set, and that the API payload can be
dynamically rendered from a definition in a catalog of the product being offered.
3.3 Agility Drivers - Standards Design
Approaches
Traditionally Standards Defining Organization (SDO) activities have been
considered in the context of defining an industry model from requirements ,and then
defining and standardizing interfaces between the components in that model. This
presumes that standards are used in a traditional development model where
specifications are created, and that subsequently developers in suppliers build to
those interface specifications.
9 Business Model Canvas http://businessmodelgeneration.com/canvas/bmc

The challenge for this approach is that implementable standards have rarely been
developed in less than 18 months, unless the input to the process is a complete de
facto standards specification, which is simply endorsed.
3.3.1 What kind of standards?
In a continuous development model the question to be asked is what standards
should be developed – noting that an 18 month standards cycle is infeasible in any
real world development.
The key requirements on a standard for agile development are:
o Interoperability: Standards for interoperability have been traditionally
defined by creating a detailed set of requirement and a single specific
implementation of that set of requirements with supporting test tools.
This assumes that all the requirements are known at the outset which is
rarely correct.
o Timeliness: Standards need to be timely and the current approach is to
develop a large body of requirements and then expect them to be all
implemented.
What is needed is a standards approach that is deliberately designed to
be incremental, each increment being limited in scope and time.
TM Forum Catalysts at June 2014 [10] [11] have shown an alternative way to
achieving interoperability in an agile incremental manner, which is based upon
defining metamodels and fragment of models that can be readily enhanced based
on those metamodels.
The key observation is that not all the specification work needs to be done within
the SDO, some can be done by implementers themselves following standardized
patterns and metamodels. This means that the standards required are different to
those traditionally defined by SDOs.
3.3.2 An analogy is useful.
The common example used is the need to develop a building block modular
approach to designing solutions:
o The kind of components /modules that that are needed are not arbitrary
building blocks but component /modules based on a common form and
structure that allows them to be combined flexibly. To achieve this all
components have to conform to a common architecture and rules.
o For Lego™ blocks, what makes them flexible is that they all conform to
rules about shape, pitch increments and pin and socket sizes, i.e. the
design rules for all Lego™ blocks.
o The equivalent for OSS/BSS Futures [23] is to agree and define the
metamodels for components and their interfaces so that user can create
their models for interfaces based on a metamodel pattern. This leads to
interoperability as all the component and interfaces follow common
pattern and the variability is managed where it is needed – by the
implementer, not by the SDO. This is elaborated in Ref [23] and [27].
o For example: in the TM Forum June 2014 catalysts [10] [11] the
interface verbs were standardized and the payload was based on a core
common information model (TM Forum Information Framework)
together with metamodel rules for extending the data payload to meet
the needs of the specific module/component being managed.

3.3.3 How does this help timeliness?
The availability of a metamodel and a core information model and rules for
extension means that component and interface developer have:
o A framework that allows them to develop their own interfaces at the pace
that suits them
o Solutions that they know will interoperate with others
o Interfaces that can be published in catalog with supporting API tools so
that potential users can try them out in a safe environment before
committing to development.
The result is that the SDO facilitates the creation of well-structured modules/
components and interfaces that are defined by implementers themselves.
Timeliness is achieved because:
o The implementer has fewer dependencies on SDO to create
interoperable interfaces.
o Metamodels usually allow for pragmatic workarounds to be identified,
and identify better long term approaches to be identified and evaluated,
i.e. Extensions to Metamodel and core information model capabilities are
typically easier to spot well before they are needed.
o The Common Information models leads to a core shared set of
semantics for the key managed entities e.g. Products, VNF, etc.
These concepts are also the basis of the TM Forum DSRA approach to service
lifecycle management [12] and the IG1118 OSS/BSS Futures [23] PMO and MCC
architecture extensions to Frameworx and DSRA.
3.3.4 Integration technologies
Use of metamodels, design patterns and core information models allow developers
and SDOs to evolve best practice from one generation of integration technologies
to another, and facilitate easy interworking of solutions in one technology with those
using earlier integration technologies. Solutions therefore are less brittle and easier
to evolve.

4 OSS/BSS support for future operations
This section relates to the business issues described in the ZOOM eBook on
Theme #2 DevOps transformation framework for the digital ecosystem [29].
In creating a vision of a future OSS/BSS there is a temptation to produce a better
solution to the previous generation of OSS/BSS requirements. TM Forum studies
show that OSS/BSS Futures need to have characteristics suited to the needs of
future operations, not historical operations, and that these require different and
novel technical approaches described in IG1118 [23].
Based on the business and technical drivers, and the expected impact on
operations the following characteristics need to be implemented:
Evolving Operations
o Enhancement of IT operations and Dev Ops practices
o New ways of managing SLAs and end to end security
Technical capabilities
o Support for multi partner changing business models.
o Agile multi-vendor, multi-technology integration.
Technical methodology
o Organizational Impacts
o Merging of cultures across multiple businesses
o ZOOM Technical standards.
Deployment environment:
o Support from the outset a hybrid management environment because
that is where Service provider deployments will start.
The following sections examine some of these requirements in more detail.
4.1 Evolving Operations
4.1.1 Implication of Dev Ops on OSS/BSS Futures
Adoption of virtualization in the enterprise space has led to the development of agile
and efficient ways of developing and operating applications that is generally
referred to DevOps. The key to DevOps are a few succinct best practices including:
o Continuous integration
o API centric – Model Driven Integration with Automated Management
interfaces
o Automated testing – sandboxes.
4.1.2 Implication of Net Ops DevOps convergence
Current NetOps management is commonly based on manual techniques so
potentially there is much to be gained by adopting and enhancing DevOps best
practices for management of NFV and virtualized services.
However DevOps is generally applied to discreet services, frequently web
delivered, and early NFV trials and catalysts are showing that there are additional

challenges that need to be addressed for network virtualization beyond that
covered by current IT virtualization methods:
o NFV Services and VNF are chained thus creating strong dependencies
between VNFs to deliver e2e virtualized services. This means that much
stronger version control and compatibility testing is needed between
separate VNF deployments to ensure e2e service is maintained, than
would be typical for enterprise applications.
o Networks are layered to support abstraction for different types of network
services and different scope. Development and Operations methods
need to support management of composition from lower level services.
o NFV services are often ‘mission critical’ creating a need for high levels of
resilience and rapid fallback capabilities.
o Sandbox test environments are more complex to set up.
o The NFV VNF workloads are rather different from typical enterprise
applications. E.g. some are long running.
o Services are often co-provided by multiple operators which require that
Dev Ops and Net Ops best practices are evolved to support concurrent
synchronized development and integration across multiple partners.
o Agile development methodology has to be evolved to support services
provided using current network service platforms and virtualized
services.
o Virtualized services will cover a diverse range of network functions and
technologies so consistent frameworks and interfaces are needed to
support integration as a configuration rather than a development activity.
o Requirements for multi-tenancy limit the physical deployment of
workloads and in some case the types of virtualization containers e.g.
Docker, when strong isolation is required, or there are regulatory
constraints.
Some of these lessons have been learned from the TM Forum Live 14 Catalyst
scenarios: Orchestrating SDN and NFV while Enforcing an SLA over a WAN[19].
4.2 Technical Capabilities
4.2.1 Support for multi-partner changing business models
Many services are based upon integrating services from multiple suppliers. This is
sometimes called Cross Domain integration and management.
The OSS/BSS Futures modular service model is designed so that any interface
between two services that cross an administration domain can be formed in an
agility and repeatable manner at industrial scale. The OSS/BSS Futures framework
uses the B2B2X Accelerator [8] and TR211 Online Partnering Guide [21] which
allows any service interface to be ‘wrapped’ by a partnership agreement.
The B2B2X Accelerator approach is designed so that the decisions that are product
dependent are decoupled from those that are partnership or business model
dependent. These decisions are designed to be systematic by selection from a list
of available choices; thus Partnerships are a configuration activity rather than a
bespoke development activity. For Operational Processes this is achieved using
reusable B2B2X touch points realized as APIs in multiple technologies.

4.2.2 Agile multi-vendor, multi-technology integration
The ZOOM NFV vision is based on the ability to flexibly integrate solutions covering
multiple technologies and multiple vendors. Of these two challenge the most
immediate is the Multi-technology integration challenge.
A number of standards initiatives around management of virtualized services have
sprung up but inevitably they are diverging; meaning that multi-technology
integration is becoming an adaptor and coding challenge, rather than plug and play
or simple configuration activity. It is clear that some umbrella activity needs to be in
place to establish and drive the multi technology converged management agenda.
Historically activities such as NGMN have ‘a postori’ initiated remedial convergence
activities that have arisen from multiple incompletely coordinated activities.
The OSS/BSS Futures [23] framework leverages best practice and experience
from many catalyst demonstrations, and studies between NGMN, the TM Forum
and 3GPP, The TM Forum DSRA [4] proposes a simple set of modelling principles
and API patterns which if widely adopted would considerably alleviate the current
integration challenge and lay the foundation for automated APIs that can be
integrated by configuration rather than coding to support DevOps for Network
Functions Virtualization.
Such a capability is an essential pre-requisite for achieving a DevOps style of
automated development and integration. Without widespread adoption of these
principles, solutions will be unable to support the necessary levels of automation to
meet the NFV agility goal.
4.3 Technical Methodology
4.3.1 Organizational Impacts
Given that future operations will evolve to be radically different form today’s and
that Product / Service Lifecycle Management needs to be highly automated this will
impact organizations processes and structure.
Following the DevOps experiences would suggest that separate development,
operations and QA organizations will need to be replaced by multi skilled functional
teams where development is structured as incremental enhancement with
continuous integration and testing, and where the whole team is focused on
business goals.
4.3.2 Merging of cultures across multiple businesses
ZOOM NFV operations will need to adopt and adapt IT DevOps practices. As
described in Sec 4.1.2 there are some additional challenges for ZOOM NFV to
achieve the necessary agility.
A future challenge will arise for integration across suppliers and administration
domains. This implies that the agile incremental development in multiple suppliers
needs to be coordinated and synchronized. Current DevOps practice does not
address across enterprise development synchronization, and clearly there are best
practices and standards needed for the exchange of product and service
definitions, lifecycle state and other development and operations metadata.
These approaches means that DevOps teams need to work in a systematic way
with other suppliers, that requires the establishment of best practice guidelines for
governance mechanisms between suppliers.

ZOOM OSS/BSS Future framework adopts the TM Forum Integration program
approach to developing APIs which included changes to the practices for
governance of development of APIs between organizations. ZOOM catalysts on
Service Bundling [10] and Catalog have shown how product and service
information can be shared and integrated across multiple organizations.
4.3.3 ZOOM Technical Standards
As services move to be constructed as mashups composed from multiple
independent service suppliers (and from different parts of an enterprise) a set of
methods and tools will be need to capture those designs throughout the complete
service realization lifecycles.
The DSRA models [4] [5] [12] augmented by the OSS/BSS Futures models [23]
provide these best practices and the minimum standards need to establish Product
and Service catalog, exchange and synchronize catalog information and metadata,
and coordinate the lifecycle of multiple services from suppliers.
Previously for DevOps typical situations, these catalogs, repositories and metadata
could be decided within a single tool or by a single enterprise. To achieve DevOps
efficiencies across multiple partners requires that the core of this information is
standardized.
4.4 Deployment environment
4.4.1 Migration to a hybrid virtualized environment
A specific realization challenge is that the first step for service providers is to
introduce virtualized services into a traditional current network environment. i.e. the
initial operations, will be of hybrid networks not purely virtualized.
This has impacts on operations processes and organization and sets requirement
on APIs between current OSS/BSS and the OSS needed for hybrid and virtualized
service.
An NFV Readiness briefing on migration and operation of hybrid networks has been
developed [14].

5 Results from ZOOM Fx 14-5
5.1 NFV Readiness Theme #3
A number of studies were carried out to support the NFV Readiness Theme that do
influence both requirements and technical realization of future OSS/BSS.
5.1.1 Virtualization Procurement and Operations Impacts 10
There are a number of areas where virtualization impacts OSS/BSS
implementations:
o Procurement: Virtualization enables entirely novel disruptive supply
chain arrangements to be considered by service provider. It allows in
principle separation of supply of computing infrastructure from Network
Service and Virtualized Function, and for maintenance to be provided by
third party maintainers.
o Operations and organizations need to embrace the new supply chain
arrangements and work out processes for operating the virtualized
Network Service and the Virtualization Infrastructure. It raises operations
question such as:
o When a VNF is delivered, how do I manage on boarding into my
organization? i.e. ‘what is in the box’? What management tools
does it support? And how will I manage it automatically within my
IT and network operations? How will support be coordinated
between NFVI and VNF suppliers?
These considerations are explored in more depth in the briefing IG1121 NFV
Readiness: VNF Procurement and Lifecycle Management [13]. This examined the
procurement and operational impact throughout the complete service lifecycle [13]
including license management.
5.1.2 Hybrid current and virtualized networks
A number of migration challenges have been identified including:
o SP Change Management: SPs cannot move in one step to full NFV
implementation, because of cost and operational constraints (processes,
change management, culture, organization, training, etc.).
o NFV Maturity As initial phases of NFV are starting to rollout, various
technologies will evolve and vendors will improve their implementation.
Therefore, the versioning of implementations as well as inter-operability
will need to be addressed.
o BSS/OSS Impacts Existing OSS and integration with BSS will need new
architecture to a new set of supporting systems, which may also be
virtualized. This is a focus of the OSS/BSS Futures Framework [23].
o Effortless Customer Experience During migration SPs need to maintain
current customer services without degrading customer experience such
as zero or minimum down-time and minimum “learning” experience,
while maintaining integrated service features.
o E2E management views across current networks and virtualized
networks are critical to supporting high quality Customer Experience.
10 This section does not cover all the procurement impact

The document identifies through a set of migration exemplars areas which will
require technical change to support migration and hybrid networks including:
o Managing Virtualization infrastructure layer including Optimization
Functionality to allow dynamic configuration.
o Dynamic operations of integration interfaces to support agile change to
products and compositions of products.
o Flow of control over APIs between current and virtualized networks.
o Data of Record: in some migration scenarios the data of record moves
from the current Network to the hybrid Network Service Management
systems.
5.2 End to end Management Theme
#2
This section relates to the business issues described in the ZOOM eBook on
Blueprint for end to end management [28].
There are two end to end management requirements:
o The first is the e2e management of new services introduction (Product
Lifecycle management or Concept to Market) described in Section 4 on
DevOps.
o The second is the e2e management of the service offered to the end
customer. OSS/BSS Futures provides the OSS Framework
management of modular virtualized services for two types of e2e
management services:
o End to end performance of the services. By defining a set of
Performance and SLA interfaces on VNF that allow consistent
measurements to be obtained on which SLA performance can
be judged.
o End to end security of the services. By defining standards based
security service available on every VNF.
5.3 Impact of Policy
5.3.1 Changes to policy management
The ZOOM OSS/BSS Futures framework [23] and ZOOM Policy Management
Architecture [24] include a policy management model which is based on a number
of observations:
o The distributed nature and complexity of NFV ZOOM solutions is such
that a centralized management model requires substantial real time
exchange of information between the virtualized functions and the
management systems.
o The processing and information transfer demand can be mitigated by
using a closed control loop Policy management approach, where
policies are distributed out to local decision points and controlled and
end to end goal are measured e.g. SLA security. When these fall are
outside the intended targets, corrections are made to policies to bring
the behavior of the overall service back to meet the intended targets.

Two catalysts at TM Forum Live 14 demonstrated exactly this approach (described
later):
o Closing the Loop: Data-driven Network Performance Optimization for
NFV and SON: [18]
o Orchestrating SDN and NFV while Enforcing an SLA over a WAN: [19]
The ZOOM Policy Management Architecture also supports some additional styles
of closed control loop Policy Management.
5.3.2 Changes to how SLAs are delivered
As was demonstrated in two ZOOM catalysts (described later) the approach to
managing e2e SLA moves from:
o a static design of an e2e service that allocates statically targets for each
component.
o to a model where the e2e SLA targets are set by setting policies and the
individual policies are dynamically adjusted to achieve the design target
at run time.
The reason this architectural change is needed is that the introduction of
virtualization breaks the static relationship between the service and the resources
used to support it; and replaces it by a dynamic relationship through virtualization
infrastructure to get the required scaling and agility; Which means traditional static
‘a priori’ design approach will not work.
Virtualization also changes the assurance approach from localizing a fault which is
impacting the overall SLA, to one where policies are adjusted dynamically so that
the delivered service adapts, and converges on the target design SLA.
Two results have been creted that address these needs:
o E2E SLA Management for Cloud The SLA Management program and
the work in TR178 [15] investigates how the SLA Principles and
Business Metrics [16] can be used to support End to End SLA for cloud
services provided by multiple cooperating providers, each operating as
separate Administrative Domains..
o A White paper analyzing the impacts of NFV virtualization [17]
captures from TM Forum Live June 2014 catalysts and other studies the
additional challenges and requirements for managing Performance and
SLAs for NFV.
5.3.3 Changes to how we think about security
The ZOOM Security Fabric [20] Framework proposes a lightweight security model
for configuring and monitoring e2e security of Virtualized Services including NFV
VNFs. It is based on a notion from the ZOOM DSRA Framework for a well enabled
(virtualized) service where every service / VNF has a standard set of management
API functionality. It also leverages existing virtualization stack security APIs to link
the security mechanisms of the virtualized services layer with those of the
virtualization Infrastructure.
The Security User Stories IG1124 [20] are derived from ETSI [25], ATIS and TM
Forum Studies TR 229 [2]. They show that a security policy based approach is
needed which is based on a closed control loop of setting security policies and hen
monitoring to check that those polices are being applied correctly, and if not,
applying necessary corrections.

The studies show that the ZOOM Policy Management Architecture [24] is directly
applicable and that the test methods for SLA and Security can be quite similar;
provided that all virtualized services are well enabled with Management interfaces
supporting SLA and performance management, and security management. DSRA
work on Simple Management APIs [22] cover most of the requirements and can be
extended to provide security management functions that meet the security User
Stories Essentially the Security Management interface is a policy based extension
of the Simple Management APIs for configuration and health.
5.4 Relevant TM Forum catalyst
results and studies
OSS/BSS Futures leverages the results of a number of catalysts and studies by the
TM Forum on the likely requirements on the OSS Future framework. Demonstrated
at TM Forum Live 2014! :
o Closing the Loop: Data-driven Network Performance Optimization
for NFV and SON: [18] This Catalyst demonstrated how to build a
closed control loop using KPIs (including network performance,
customer experience, and service quality data) to enable network
changes, optimization and self-healing. The TM Forum Performance
Management interface was used aside 3GPP interfaces to enable this in
the context of ETSI’s NFV orchestration and 3GPP’s Self-Optimizing
Network (SON) scenarios.
o Orchestrating SDN and NFV while Enforcing an SLA over a WAN:
[19] This Catalyst demonstrates for ODCA’s Software Defined
Networking Usage Model examples the use of a cloud orchestrator with
OpenStack integration to provision a virtualized network topology (VMs
& VNFs) while monitoring and enforcing SLAs via SDN-OpenFlow,
across legacy MPLS WAN. It also demonstrated how virtual machines
can be managed by monitoring SLA information in a closed control loop.
Service quality metrics can be captured from virtual applications hosted
by virtual machines, passed to a cloud service manager, which then
determines if SLAs have been violated.
o CloudNFV™: Dynamic, data-driven Management and Operation
[11] working demonstration that showed that the higher-level objectives
of both ETSI NFV and the TM Forum are practically achievable today.
This Catalyst delivered a metamodel for event-driven management and
operations, and a live demonstration of a dynamic implementation with
IMS as virtual network function deployed via OpenStack and optimized
based on network telemetry to maintain quality of service.
o NFV Management Ecosystem [30] An implementation of management
and orchestration (MANO) as defined by the ETSI NFV ISG is the
platform to demonstrate real-time, dynamic management of capacity,
performance, quality of service (QoS) and service level agreements
(SLA) as well as enabling real-time billing and compensation.
o Service Bundling in a B2B2X Marketplace [10] showed how a buyer
can bundle a collection of services sourced from different suppliers and
deliver them seamlessly to a customer. These components could
include traditional network access products, as well as NFV and IaaS
products. Concrete business roles and process touchpoints enable a
well-defined relationships among players in the value chain to ensure

seamless delivery. This demonstration was made possible through the
use of established ebXML interfaces and newly-added REST APIs
For Digital Disruption 2014
o Multi-Cloud SDN-NFV Service Orchestration: A forthcoming Catalyst
at Digital Disruption 2014. This project will demonstrate seamless
management for services relying on virtualized resources residing in a
public cloud. The project leverages experience form operating real time
streaming service at the Sochi Olympics and is exploring the feasibility of
moving to a “software defined everything” where controlling functions
can be hosted as needed on cloud infrastructures, and orchestration and
management can be achieved across heterogeneous multi-cloud
environments.

6 Future areas of study
In the current phase the team decided explicitly to defer some topics because there
were foundational topics that need to be addressed first.
6.1.1 Orchestration
To model orchestration architectural two things were recognized by the team to be
necessary:
o NFV Entity Information Model: One cannot effectively orchestrate
entities and their relationships without having a robust and reasonable
stable information model for those entities. Information Modelling the
NFV entities has been a priority for the current phase which will be used
as a foundation for the next phase.
o Policy based Orchestration: based on TM Forum Live 14 June 2014
Catalyst results it seems that orchestration of NFV might be better
achieved by explicit use of a policy model rather than using simpler
statically defined scripting or procedural approaches to orchestration.
The focus for the current phase has been to develop a policy based
framework and model which include a closed control loop rather than the
simpler open loop approach of some orchestration solutions. Exploiting
Policy based model will be used as a foundation for the next phase of
work on orchestration.
For the next phase of ZOOM the Policy Management Architecture and Information
Model can be used to explore a policy based orchestration approach.
6.1.2 Service chaining
Service chaining is about how the relationships between NFV entities are formed
and change dynamically. It was decided to address the relationships after the Core
Information model for NFV entities and policy management had been completed.
6.1.3 Virtualization Maturity Model
Virtualization inevitably will be introduced gradually to networks and there will be a
need to operate hybrid networks for quite some time.
As the industry will be learning and evolving best practice, there is a need for shared
metrics and methods for assessing organization maturity in adopting operating
virtualization. A Virtualization Maturity Model shared and adopted across the
industry would be helpful for:
o Exchanging best practice experiences
o Evaluating what works well
o Allow service providers to benchmark themselves with other providers to
establish which areas need priority attention.

7 References
7.1 References
Referen
ce
Description Source Brief Use Summary
[1] Zoom Overview
http://www.tmforum.org/zoom/16335/hom
e.html
TM
Forum
Overview of ZOOM benefits, goals
and principles
[2] TR229 ZOOM/NFV User Stories
http://www.tmforum.org/TechnicalReport
s/TR229ZOOMNFVUser/54793/article.ht
ml
https://collab.tmforum.org/sf/go/doc2617
3?nav=1
TM
Forum
ATIS
ETSI
Evergreen compendium of ZOOM /
NFV/ Virtualization User Stories. Uses
a consistent template for capturing all
User Stories and organizes them into
a service lifecycle
[3] Customer Engagement Program TM
Forum
Addresses best practice and metrics
for Improving Customer Engagement.
[4] Introduction to the DSRA
http://www.tmforum.org/IntroductoryGuid
es/Introductiontothe/52079/article.html
TM
Forum
Overview of Digital Services
Reference Architecture originally
developed for multi cloud multi
provider management integration.
Evolved to support Digital services
and their ecosystems
[5] TMF061, Service Delivery Framework
Reference Architecture
http://www.tmforum.org/TechnicalSpeci fi
cations/TMF061ServiceDelivery/55197/ar
ticle.html
TM
Forum
Precursor to DSRA [4] – provides a
more detailed architectural
specification specifically on service
lifecycle management
[6] Standardized Interfaces & APIs
http://www.tmforum.org/StandardizedInte
rfaces/10414/home.html
TM
Forum
Interfaces for managing resources
and for use between management
applications.
[7] API Zone
http ://www.tmforum.org/APIZone/15739/
home.html
TM
Forum
API based integration interfaces – part
of Fx Integration Framework focused
on REST technology and documented
on GitHub and Apigee for developers.
[8] B2B2X Partnering Accelerator
http://www.tmforum.org/B2B2XPartnering
Accelerator/15671/home.html
TM
Forum
Describes a systematic industrial
approach to forming and operating
B2B2X partnerships. Based on
member operational experiences and
TM Forum APIs.
[9] Catalyst: Implementing an Open
Wholesale B2B Marketplace
http://www.tmforum.org/Implementingan
Open/14909/home.html
TM
Forum
Demonstration of B2B2X Accelerator
best practice based on BT and NBN
co et al operational deployment~200
implementations.
[10] Catalyst: Service Bundling in a B2B2X
Marketplace
http://www.tmforumlive.org/service-bundling-
in-a-b2b2x/
TM
Forum
Demonstration of B2B2X Accelerator
best practice based applied to
composition of Cloud NFV and
broadband access service. Showed

how to design and deploy
manageable composite service by
configuration in minutes.
,[11] Catalyst: CloudNFV™: Dynamic, data-driven
Management and Operations
http://www.tmforumlive.org/cloudnfv/
TM
Forum
Demonstration of mashup of
enterprise services into a manageable
compositions. Showed how to design
and deploy manageable composite
service by configuration in minutes.
Similar approach to [11].
[12] TMF617, Software Enabled Services
Management Interface Information
Agreement, Version 1.6
http://www.tmforum.org/InformationAgree
ments/TMF617SoftwareEnabled/46850/a
rticle.html
TM
Forum
API requirements for Simple
Management API for well enabled
services /modules. Basis of
management in DSRA.
[13] IG1121 NFV Readiness: VNF
Procurement and Lifecycle Management
TM
Forum
Assesses impact of virtualization and
NFV on procurement and operations
management of the service sourcing
lifecycle.
[14] IG1122 NFV Operational Readiness:
Operating a hybrid virtualization network
infrastructure
TM
Forum
Proposes management dashboard for
managing hybrid networks and
studies a number of exemplar
migration scenarios and best practice
for migration step planning.
[15] TR178, Enabling End-to-End Cloud SLA
Management
http://www.tmforum.org/TechnicalReport
s/TR178EnablingEndtoEnd/50148/article.
html
TM
Forum
Report on how to manage e2e SSL
across multi-cloud multi-provider
deployments.
[16] Business Metrics Solution Suite 2.0
http://www.tmforum.org/DownloadReleas
e13/14772/home.html
TM
Forum
TM forum Metrics suite for business
management and operations and
customer experience.
[17] IG1120 Virtualization Impact on SLA
Management
TM
Forum
Assess the additional impacts on SLA
of moving to virtualized environment
as compared to TR 178.
[18] Catalyst: Closing the Loop: Data-driven
Network Performance Optimization for
NFV and SON
http://www.tmforumlive.org/closing-the-loop/
TM
Forum
Investigates use of closed control loop
for managing NFV and SON based
networks solutions. Uses TMF r
Performance management interface
and uses a policy management
approach.
[19] Catalyst Orchestrating SDN and NFV
while Enforcing an SLA over a WAN
http://www.tmforumlive.org/enforcing-sla/
TM
Forum
Investigation of management of SA
over multi cloud multi-data center
multi-technology environment.
[20] IG1124 ZOOM NFV Security Fabric
Overview
TM
Forum
Initial scope of a approach to
mangling e2e Security of virtualized
services that sets scope and
functional requirements on two
Security Management APIs

[21] TR211 On line Partnering Step by step
Guide
http://www.tmforum.org/PartnershipWork
space/16188/home.html
TM
Forum
ON line step by step guide to the
B2B2Accerator pack [8] with
templates and completed examples.
[22] Developer Pack: Simple Management
API
http://www.tmforum.org/DeveloperPackSi
mple/14254/home.html
TM
Forum
Developer focused material for Simple
Management API
[23] IG1118 OSS/BSS Futures – Preparing
the Future Mode of Operation
TM
Forum
Companion document with a deeper
dive on the impacts of Virtualization or
OSS and BSS.
[24] TR235 Policy Model and Architecture
Snapshot
TM
Forum
Policy management framework for
inclusion in future TM Forum
Information Framework that support
know Policy management
Requirements for NFV.
[25] Draft ETSI GS NFV-SEC 001
V0.2.1Network Functions Virtualisation
(NFV); NFV Security; Problem Statement
ETSI Core requirement for NFV e2e
Security.
[26] IG1100 Product Lifecycle Management
Introductory Guide, Version 1.1
http://www.tmforum.org/browse.aspx?link
ID=50699&docID=18745
TM
Forum
Provides comprehensive description
and model for Product and service
lifecycle management.
[27] TR234 ZOOM Information Model
Snapshot
http://www.tmforumlive.org/catalysts/
TM
Forum
Proposed update to Information
Framework model to support
virtualization. Key assets are:
integration with existing deployed non
virtualized networks: supports all key
ETIS NFV MANO Concepts: supports
modelling of non-functional
requirements on the NFVI
(Hypervisors, Virtual Machines)
[28] eBook: Blueprint for end to end
management
TM
Forum
TM Forum Quick Insight guide
[29] eBook: DevOps transformation
framework for the digital ecosystem
TM
Forum
TM Forum Quick Insight guide
30 NFV Management Ecosystem
An implementation of management
and orchestration (MANO) as defined
by the ETSI NFV ISG is the platform
to demonstrate real-time, dynamic
management of capacity,
performance, quality of service (QoS)
and service level agreements (SLA)
as well as enabling real-time billing
and compensation. This rapid
implementation of a NFV ecosystem
is enabled through use of
standardized APIs from TM Forum
and other organizations

8 Administrative Appendix
This Appendix provides additional background material about the TM Forum and
this document. In general, sections may be included or omitted as desired;
however, a Document History must always be included.
8.1 Document History
8.1.1 Version History
<This section records the changes between this and the previous document version as it is
edited by the team concerned. Note: this is an incremental number which does not have to
match the release number and used for change control purposes only>
Version Number Date Modified Modified by: Description of
changes
<<Version Number
>>
DD/MMM/YY <<name>> Description e.g. first
issue of document
V 14.0.2 30/10/2014 D Milham Draft with team
informal review
comments
incorporated.
V14.0.3 31/10/2014 D Milham On line edits from
review call
V14.0.4 4/11/2014 D Milham Verbal edits
proposed from
review call 31st Oct
V14.0.5 6/11/2014 D Milham Adjustments to
address final editorial
comment review
period
8.1.2 Release History
< This section records the changes between this and the previous Official document release.
The release number is the ‘Marketing’ number which this version of the document is first being
assigned to >
Release Number Date Modified Modified by: Description of
changes
<<Release Number
>>
DD/MMM/YY <<name>> Description e.g. first
issue of document

oss bss_futures_overview

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to oss bss_futures_overview

Similar to oss bss_futures_overview (20)

Recently uploaded

Recently uploaded (20)

oss bss_futures_overview