WHITE PAPER

HOW ADOPTING NFV/SDN TECHNOLOGY ENABLES

TELECOMS TO EXPERIMENT WITH NEW CUSTOMER
SERVICES
WHAT WILLYOU LEARN

nn Demystifying end to end orchestration

nn The role of “model-driven” orchestration

nn How to on-board VNFs and partners’ series to enable

experimentation with new customer services

nn How to use the model to avoid heavy scripting of

business logic for new services
INNOVATION
From a business perspective, NFV/SDN technology is probably not judged on its technical capabilities, but
rather on how it can improve operational and business efficiency. In particular, it can be assessed in regard
to its capacity to boost service innovation and reduce time to market. In both cases the judgment should be
made from the customer service perspective, however exciting the technological aspects may be for network
engineers or other IT experts.

Moreover, ”time to market” and “boosting innovation” have probably become obsolete buzzwords by now, as
the new term “fail fast” has been adopted from the realm of over-the-top players (OTTs) such as Google, Apple
and the like. Adoption of this term reflects the idea that communication service providers (CSPs) need to trans-
form their “legacy” mindset and reprogram their DNA according to the templates that have proved successful
for the OTTs. “Fail fast” is by no means about failure per se, instead – it reflects a model that builds failure into
the overall framework of success. “Fail fast” in fact means the ability to experiment with new services, to find
out what works for customers and what doesn’t, and to identify what requires fine-tuning in order to raise
excitement in the customers. The key, therefore, is to be able to put new ideas to the test quickly and without
being afraid of suffering huge costs if they don’t work.

So how does the “fail fast” concept relate to NFV/SDN? The first expectation arises from the fact that SDN/NFV
simplification is about “softwarisation” of the network, so, if your network is software-based, you may be able
to replicate the success of software giants such as Google. However, you need to remember that having some-
thing based on software does not guarantee the “for free” ability to reduce the life cycle of a software-based
series. To make that dream come true, you need model-driven orchestration and life-cycle management when
adopting NFV/SDN technology. These two are closely related, as model-driven orchestration enables you to
define a model for new services, which means that you can quickly put such services to the test. These two
concepts are elaborated further on in this text.

WHITE PAPER 3
MODEL-DRIVEN END TO END ORCHESTRATION
“Orchestration” is probably one of most overused terms to be found in marketing materials and technical
descriptions of new technologies and concepts for managing modern networks. Even in technical specifications,
“orchestration” is used as a magic word which is supposed to explain everything, and in marketing materials it
is certainly used as a buzzword to suggest that the advertised product is ultra-modern compared to existing
“legacy” solutions.

NFV/SDN technology is no different, and the term “orchestration” plays a dominant role especially in the NFV
MANO (Management and Orchestration) specification. To claim that it is a buzzword in this context would be
unfair, as this specification is an attempt to define the role of an “orchestrator”. But, as NFV MANO must be put
in a broader, end to end context, especially for a hybrid network, the term and levels of “orchestration” may
need to be demystified.

An explanation of “orchestration” only makes sense when it is put in a broader perspective, which is about
reducing time to market. In the scope of a virtualized, software-defined network this means adopting the “fail
fast” paradigm from the successful software over-the-top players, as mentioned earlier in this document. The
“fail fast” model enables telecom operators to experiment with new services, to test them quickly, and, if they
work, to monetize them rapidly, thus speeding up the innovation cycle significantly. This is in fact the most
important expectation from NFV/SDN. Without reaching that goal, NFV/SDN network transformation could
hardly be called successful.

If the real value of “orchestration” can be found in The “fail fast” model
reducing time to market and enabling operators
to experiment with new services, it means that
enables telecom operators
our discussed model has to be catalog-driven. to experiment with new
The concept is that a model managed in catalogs services, to test them
should enable new services to be defined from the
perspectives of customer value, implementation, quickly, and, if they work, to
and technical capabilities. In addition, the model monetize them rapidly, thus
needs to enable collaboration between people
of different skills and even mindsets. It is crucial
speeding up the innovation
for product managers, who concentrate more on cycle significantly. This is
the value that any technology can bring to the
in fact the most important
customer than on the technology itself, to be able
to work together with engineers, who, in the main, expectation from NFV/SDN.
take the opposite view. This means that the model
managed in the catalog should have at least two
abstraction layers, which are mapped to each other: one defining the view from the customer perspective, and
the other tackling technical aspects. For anyone familiar with the TMF SID (Information Framework) model,
this should suggest the CFS-RFS-R model, the adoption of which could be a successful way of transforming
BSS/OSS systems towards managing hybrid networks.

Therefore, the term “orchestration” is closely related to managing hybrid networks and adapting BSS/OSS
environments to manage NFV. In fact, the outline concept suggests using catalog-driven OSS to manage NFV
“natively”, as a natural extension of the RFS-R model to the virtual domain, rather than introducing NFV MANO
as a completely separate “silo” (as some vendors who want to enter the market are suggesting).

To explain this in more detail, the NFV concept must be mapped onto the TMF SID CFS-RFS-R model. Starting
from the bottom, virtual network functions (VNFs) and physical network functions (PNFs) correspond to logical
resources from the TMF SID model. VNFs and PNFs modeled in a unified manner as logical resources differ in
the implementation details, as PNFs are hosted by a dedicated physical resource, while VNFs should be hosted
by a virtual machine, a hypervisor, and finally by a commodity blade (physical resource). Having VNFs and PNFs
modeled as (logical) resources, the ETSI NFV Network Service should be understood as a TMF SID Resource
Facing Service (RFS) composed from VNFs and PNFs. Finally, customer facing services (CFS) can be constructed
from resource facing services (RFS), which act as “building blocks”. CFS then can be used to create products
and product offers.

4 WHITE PAPER
So the idea is that, with VNFs (and PNFs) on-boarded to the catalog as resources, engineers may define each
RFS (understood as technical services corresponding to NFV network services), which can be used by product
managers to innovate in the customer facing service space and thus introduce new products to the market.

End to end “orchestration” can be divided into the following abstraction layers:

nn Service orchestration driven by CFS-RFS decomposing,

nn NFV orchestration driven by RFS-R (VNF,PNF),

nn VNF instantiation driven by R->R (logical resource ->VMs->hypervisors->blades in NFVI PoP).

This concept is depicted in Figure 1, which assumes employing an OSS catalog-driven fulfillment solution
which, prior to the advent of NFV/SDN technology, could orchestrate a traditional network using CFS-RFS-R
modeling and is adapted to orchestrate a hybrid network.

SERVICE
«CFS»
ORCHESTRATION
CFS
MODEL

MANO
«RFS» «RFS» «RFS»
RFS1 RFS2 RFS3
ORCHESTRATION
MODEL

«Resources» «Resources»

Network Function / Logical Dev ice Network Funciton / Logical Dev ice Virtual Function / Virtual Dev ice Virtual Function / Virtual Dev ice

GENERIC NFV
MANAGER
«R» «R» «R» «R» «R» MODEL
Physical Physical Virtual Virtual Virtual
Device Device Machine Machine Machine

«R»
Physical Physical Physical
Device Device Device

Figure 1. Service Orchestration vs. NFVI-O vs. Generic VNF Manager

MODEL-DRIVEN LIFE-CYCLE MANAGEMENT – EXPERIMENTING

WITH MANY SERVICE VERSIONS
Adopting model-driven orchestration enables model-driven life-cycle management and thus reduces the time
required to introduce or experiment with new services. In essence, this means that you can launch a new
service quickly, by introducing a new model into the service catalog (and product catalog to manage the
commercial aspects of the service) and then having this model drive the orchestration to enable the delivery
and management of the new services once they are running.

However, true freedom to experiment with new ideas requires the ability to introduce not only new services but
also new versions of services, in order to fine-tune those you have already defined. Another important aspect

WHITE PAPER 5
is the ability to “experiment” with new services or versions, without any impact on the existing services, which
already bring in money. On the contrary, you need to be able to introduce a new version safely, and offer it to
early adopters first on a small scale. Only when a new service or version is ready for full-blown adoption by the
market, can you start thinking about retiring existing services. Lacking such a capability has in fact been the
major factor preventing CSPs from introducing new services quickly, due to fear of failures that may impact
millions of customers and thus damage the business.

From the technology point of view, NFV/SDN enables network functions (VNFs and SDN controller applications)
in different software versions to co-exist in the production environment. But it is essential to be able to manage
versions of network functions in the context of the correct version of a customer service. It is also important
that, when instantiating a new service that is being tested by early adopters, an “experimental” version of
VNFs should be in place. When an established service is being mass-delivered to customers, the well-tested
service version would be used to avoid disruption being caused by the new service or version. Only in these
circumstances can you experiment fearlessly, as you can be sure that new services won’t disrupt the old ones
which still bring your company profits.

To efficiently manage service life cycles and to gain the ability to introduce new services faster, telecoms also
need to easily model a new service, without coding or even heavy scripting. This is especially true as new services
may require collaboration between engineers and product managers – the latter understand customer needs
but may not necessarily be able to program in YANG or another scripting language, or code in Java.

That’s why catalog-based modeling with GUI (graphical user interface) for product managers, who are not
technical, is so important (Figure 2).

«CFS»
CFS-RFS-R modeling via ETSI NS on-boarding:
CFS
GUI Service Catalog NS descriptors in
(No scripting in Yang, etc.) Yang, TOSCA, etc.

«RFS» «RFS» «RFS»

RFS1 RFS2 RFS3

ETSIVNF On-boarding:
VNF Descriptors in Yang,
or TOSCA, etc.

«Resources» «Resources»

Network Function / Logical Dev ice Network Funciton / Logical Dev ice Virtual Function / Virtual Dev ice Virtual Function / Virtual Dev ice

«R» «R» «R» «R» «R»

Physical Physical Virtual Virtual Virtual
Device Device Machine Machine Machine

«R»
Physical Physical Physical
Device Device Device

Figure 2. Catalog-based life cycle management – avoiding „YANG” or other script-based coding

6 WHITE PAPER
The idea assumes that VNF vendors should provide True freedom to experiment
the VNF descriptors in YANG or any modeling lan-
with new ideas requires the
guage, which can be parsed and on-boarded into
the service catalog in such a way, that the new VNF ability to introduce not only
version can be managed as a component in the cat- new services but also new
alog. Similarly, partners’ network services could be
on-boarded as high level service components (ETSI
versions of services, in order
Network Services modeled as TMF RFS). The main to fine-tune those you have
assumption is that a non-technical product manag-
er (that is, someone who can’t program in YANG),
already defined. Another
who should concentrate more on the technology’s important aspect is the
value to the customers than on the technology it- ability to “experiment” with
self, can easily create new customer services using
the service catalog GUI. new services or versions,
without any impact on the
SUMMARY existing services, which
already bring in money
From the business perspective, a key benefit of NFV/
SDN adoption is that it allows CSPs to experiment
with new services and thus reduce the innovation cycle to keep pace with OTT players such as Google. In other
words, NFV/SDN should enable telecom operators to introduce new services to market, faster and cheaper
than before. NFV/SDN technology should enable operators to adopt the “fail fast” mindset, meaning that new
services can be put to the test with early adopters, and fine-tuned without the risk of impacting existing services
and damage the business. The key to this is model-driven orchestration, and a catalog-managed life cycle in
which new models and versions can easily be created without the need for heavy scripting by less technology
savvy product managers.

ABOUT COMARCH
Comarch is a provider of complete IT solutions for telecoms. Since 1993 the company has helped CSPs on 4 continents optimize costs, increase
business efficiency and transform BSS/OSS operations. Comarch solutions combine rich out-of-thebox functionalities with high configurability
and are complemented with a wide range of services. The company’s flexible approach to projects and a variety of deployment models help
telecoms make networks smarter, improve customer experience and quickly launch digital services, such as cloud and M2M. This strategy has
earned Comarch the trust and loyalty of its clients, including the world’s leading CSPs: Vodafone, T-Mobile, Telefónica, E-Plus, KPN and MTS.

Copyright © Comarch 2016. All Rights Reserved

telco-enquiries@comarch.com | telecoms.comarch.com