See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/311461376

On telecommunication architectures: From Intelligent Network to Network

Functions Virtualization

Conference Paper · October 2016

DOI: 10.1109/ICUMT.2016.7765366

CITATIONS READS

3 850

2 authors:

Manfred sneps-sneppe Dmitry Namiot

Ventspils University College Lomonosov Moscow State University
115 PUBLICATIONS   832 CITATIONS    126 PUBLICATIONS   940 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Pentagon communications (AIN, IP, cybersecurity, etc), digital railway (GSM-R, LTE/4G, 5G) View project

AI in software engineering View project

All content following this page was uploaded by Manfred sneps-sneppe on 22 October 2018.

The user has requested enhancement of the downloaded file.

 2016 8th International Congress on Ultra Modern Telecommunications and Control Systems and Workshops (ICUMT)

On Telecommunication Architectures: from

Intelligent Network to Network Functions
Virtualization

Manfred Sneps-Sneppe Dmitry Namiot

Ventspils International Radioastronomy Centre Faculty of Computational Mathematics and Cybernetics
Ventspils University College Lomonosov Moscow State University
Ventspils, Latvia Moscow, Russia
manfreds.sneps@gmail.com dnamiot@gmail.com

Abstract—The paper discusses the undergoing network
architecture massive transformation, primarily by virtualization
and Software Defined Network (SDN) technologies. Network
Functions Virtualization consolidates many network equipment
types onto industry standard high volume servers, switches, and
storage, which could be located in Data ɋenters, Network Nodes
and in the end user premises. However, the question arises: are
these concepts implementable from software developer point of
view? The future of NFV approach depends on software
developer activities. To talk about the NFV destiny, we try to
overview the changes in telecom technologies: from ISDN and
SS7, as well as All-IP concept, to SDN and its relationship with
NFV. The conclusion is devoted to the discussion of NFV future
from the software development point of view.
Keywords— software defined network; network functions
virtualization; intelligent network; software standards; middleware.
as required, without the need for installation of new equipment
[2].
This is the concept of network slicing. Network slices are
designed individually to meet a specific set of performance
requirements tailored to the application running on the slice.
The virtual infrastructure of a slice is isolated from other slices
to ensure that all slices of the network run efficiently and
performance targets are met. The NFV approach provides the
flexibility needed to provision network resources on demand,
and to tailor slices to specific use cases, enabling operators to
deliver networking as a service.

I. INTRODUCTION
The network architecture is undergoing a massive
transformation, primarily by virtualization and Software
Defined Network (SDN) technologies. This process, in turn, is
having an impact on the role of the Central Office (CO). The
term next generation central office (NGCO) has been adopted
by the telecom industry to refer to the future central offices that
will support both fixed and mobile operations. Compared with
its current CO counterpart, the NGCO will be able to serve
more subscribers, implement access functions in a more IT-
centric mode, and support and locally house new, flexible data
services. The NGCO will function like a highly automated mini
data center, requiring less space, power, and cooling than the
set of traditional COs it replaces [1]. In the NGCO, the Figure 1: Network Functions Virtualization Relationship with Classical
traditional network functions will run as virtualized network Networks [2].
functions on the widely available hardware on the market. Network Functions Virtualization (NFV) is applicable to
Network Functions Virtualization aims to transform the any data plane packet processing and control plane function in
networks architecture by evolving standard IT virtualization mobile and fixed networks. Potential examples include as
technology to consolidate many network equipment types onto follows:
industry standard high volume servers, switches, and storage, • Switching elements: BNG, CG-NAT, routers.
which could be located in Data ɋenters, Network Nodes and in
the end user premises, as illustrated in Figure 1. It involves the • Mobile network nodes: HLR/HSS, MME, SGSN,
implementation of network functions in software that can run GGSN/PDN-GW, RNC, Node B, eNode B.
on a range of industry standard server hardware, and that can
be moved to, or instantiated in, various locations in the network

978-1-4673-8817-7/16/$31.00 ©2016 IEEE 251

 2016 8th International Congress on Ultra Modern Telecommunications and Control Systems and Workshops (ICUMT)
• Functions contained in home routers and set-top boxes to
create virtualized home environments.
• Tunneling gateway elements: IPSec/SSL VPN gateways.
• Traffic analysis: DPI, QoE measurement.
• Service Assurance, SLA monitoring, Test,
Diagnostics.
• NGN signaling: SBCs, IMS.
• Converged and network-wide functions: AAA servers,
policy control, and charging platforms.
• Application-level optimization: CDNs, Cache Servers,
Load Balancers, Application Accelerators.
• Security functions: Firewalls, virus scanners, intrusion
detection systems, spam protection.
The future of NFV approach bases, on great extent, on
software developer activities. To talk about the NFV destiny,
we try to overview the changes in telecom technologies: from
ISDN and SS7 (in Section 2) and All-IP concept (in Section 3)
to SDN and its relationship with NFV (Sections 4 and 5).
Section 6 is devoted to the discussion on NFV future from the
software development point of view.
II. ISDN AND IN
Integrated Services for Digital Network (ISDN) lines,
which offer up to 128 Kbps are a set of communication
standards for simultaneous digital transmission of voice, video,
and data over a pair of standard telephone copper wires. The
key feature of ISDN is that it integrates speech and data on the
same lines (Figure 2A).
Figure 2. A) ISDN design. B) IN basic design.
The Intelligent Network (IN) architecture, the highest
achievement in the art of circuit switching, was developed by
Bell Labs in the 1970s (Figure 2B). It allows operators to
provide value-added services in addition to the standard
telecom services such as PSTN, ISDN and GSM services on
mobile phones. IN is supported by the Signaling System #7
(SS7) protocol between telephone network switching centers
and other network nodes owned by network operators. The
basic IN design is including STP (Signaling Transfer Point),
SSP (Service Switching Point), SCP-DB (Service Control
Point with Database), each Central Office (CO) contains
Signaling Point (SP).
III. ON THE ALL-IP CONCEPT: THE DISN CASE
Communication specialists around the world are facing
nowadays the same problem: shifting from circuit switching to
packet switching, from ISDN signaling and IN architecture to
All-IP world.
and The Defense Information Systems Network (DISN)
belonging to the Pentagon is the world's largest departmental
network. This global network is intended to provide
communication services by transmitting different types of
information (voice, data, video, and multimedia) in order to
perform the efficient and secure control of the military,
communications, intelligence, and electronic warfare media.
In 1996, the 15-year program of weapons development
Joint Vision 2010 was adopted. Regarding the means of
communication, the Advanced Intelligent Network (AIN) was
chosen. Note that the breakup of the Bell System was
mandated in 1982, long time before the DISA solution.
In 2006, the Pentagon adopted a new plan for the next 15
years entitled Joint Vision 2020. The plan announced the DISN
paradigm shift: the transition from SS7 signaling to IP
protocol. It is assumed that the IP protocol will be the only
means of communication between the transport layer and
applications. The most important step for DISN modernization
is the replacing of channel switching electronic Multifunctional
switches (MFS) by packet switching routers under AS-SIP
signaling. The transition phase is based on Multifunctional Soft
Switches (MFSS), as in Figure 3.
Figure 3. Reference model for Multifunction Soft Switch: the future AS-SIP
based MFSS, but with ISDN based DRSN included [3].
The MFSS provides all required PSTN/ISDN interface
functions, including ISUP, CCS7/SS7, and CAS signaling and
media conversion, under signaling gateway (SG) and
interworking function (IWF) control. The MFSS also operates
as a media gateway (MG) between TDM circuit switching and
IP packet switching under the control of the media gateway
controller (MGC) while communications control protocol like
H.248 is used between MG and MGC. Besides, there are EI
(End Instrument) and AEI (Assured Services End Instrument),
following AS-SIP, as well as PIE (Proprietary Internet Protocol
Voice End Instrument). H.323 is the leading protocol for
video-conferencing.
The Service Control Function (SCF) cooperates with 19
servers and many protocols: SOAP, HTTP, LDAP, SQL,
RADIUS, DIAMETER, WAP, ITIP, SMTP, AAA, TCAP,
252
 2016 8th International Congress on Ultra Modern Telecommunications and Control Systems and Workshops (ICUMT)

ENUM, IM, MMS, SMS (Figure 4). Take an attention to the
AS-SIP protocol. The well-known SIP protocol is the basic one
in IP telephony. SIP has regularly deployed alongside SOAP,
HTTP, XML, VXML, WSDL, UDDI, SDP, RTP and others.
However, SIP, as a signaling protocol, does not have the ability
to break into ongoing calls, e.g. used for emergency calls. The
support for Multi-Level Precedence and Preemption (MLPP)
has used instead. For this reason, particularly, Assured Services
SIP protocol was invented [4]. To implement Unified
Capabilities requirements [3], AS-SIP got many features and
had required support by up to 200 RFCs.
network resources. Resource Control Interface (SouthBound
Interface) - Interface between an SDN controller and SDN
resources - it is used to control network resources. Typically,
NorthBound interaction is a negotiation with four stages:
Request, Response, Selection, and Confirmation. These
functions are rather simple compared with traditional telephony
API e.g., Intelligent network or Parlay API.

Figure 5. SDN Stack

The SDN is highly promising now for Internet services and

the All-IP move at all. However, the very inventors of SDN,
particularly, prof. Nick McKoewn [5], have delivered the very
important controversial case. They have compared two
architectures for AT&T US IP core network (Figure 6): (1)
traditional All-IP version used MPLS backbone routers (BR)
and (2) the hybrid packet and circuit core, building on the ideas
from SDN (Figure 7A). The overall number of core ports was
Figure 4. Service Control Function and its 19 servers. reduced significantly in IP-and-DCS (Dynamic Circuit
Switching) when compared to the reference design (from 2564
As expected, the TDM switching portion of the MFSS will to 1480). As a result, nearly 60% in overall Capex savings have
be retired as soon as all users/systems migrate to IP, but there been achieved when compared to the reference IP-over-WDM
are some obstacles. design (Figure 7B). Most of these savings come in the
DRSN (The Defense Red Switch Network) is a dedicated backbone switches, which see an 85% reduction in cost.
telephone network, which provides global secure
communication services for the command and control structure
of the United States Armed Forces. Secure Terminal
Equipment (STE) is the encrypted telephone communications
system for wired communications and designed to use ISDN
telephone lines. It has also a slot for Crypto PC Card and four
buttons, which are used to select the four priority levels. This
allows users to make phone calls that get precedence over ones
with a lower priority.

IV. ON SOFTWARE-DEFINED NETWORKS AND CONTROVERSIONS

Recommendation ITU-T Y.3300 defines SDN as “a set of
techniques that enables to directly program, orchestrate, control
and manage network resources, which facilitates the design,
delivery and operation of network services in a dynamic and
scalable manner”. Most SDN-labeled solutions relocate the
control of network resources to dedicated network elements,
namely SDN controllers and the 3-layers reference model
(Figure 5).
Application Control Interface (NorthBound Interface) -
interface between an SDN controller and an SDN application -
it provides an application programmatic control of abstracted
Figure 6. AT&T US IP core network: 16 PoPs across the U.S. are aggregating
the traffic from 89 other cities.
These results have lead to the following:
(1) Packet switching will continue to exist at the edge of
the network. The packet-switched network should ideally
gather traffic from disparate sources, and multiplex it together.
(2) At the core of the network, the circuit switched
transport network should remain as a means to interconnect the

253
 2016 8th International Congress on Ultra Modern Telecommunications and Control Systems and Workshops (ICUMT)
packet switched routers, and as a means to provide high
reliability and performance guarantees.
Figure 7A. Replacing BRs in core PoPs with hybrid MPLS-OTN (packet-
optical) switches.
Figure 7B. Capex results for two designs.
V. NFV RELATIONSHIP WITH SDN
According to the ETSI definition, an NFV architectural
framework [6] is operating on the principle of separating
network functions from the hardware they run on by using
virtual hardware abstraction. The major components of this
framework are (Figure 8):
• Network Functions Virtualization Infrastructure (NFVI):
subsystem, which encompasses Compute, Network, and
Storage resources.
• Management and Orchestration: subsystem, which
includes the Network Functions Virtualization Orchestrator,
the Virtualized Infrastructure Manager (VIM) and Virtual
Network Function Manager.
• Virtual Network Functions (VNFs): deployed in the
NFVI.
What about NFV and SDN relationship, besides two above
-mentioned interfaces (NorthBound and SouthBound), there is
Orchestration Interface – the interface between an SDN
controller and an NFV Orchestrator. It might need to pass
254
information between the two entities, such as topology
information in both directions. The same interface might be
used also between an SDN application and an NFV
Orchestrator.
From an SDN controller perspective, consider in more
detail NorthBound Interface functions. From an NFV
architectural framework perspective, the NorthBound Interface
might be considered as the Application Control Interface
provided by the SDN controller if that layer is embedded in the
SDN controller, or it could be considered as an SDN
application if it seats on top of the SDN controller. Figure 8
below shows the different combinations between the different
components of SDN controller.
Figure 8. SDN Resource Control Interface Options in NFV.
The similar kind of figures are given in [6] for SDN
Controller/Application Orchestration, SDN Application
Control, and SDN Controller to Controller Interface Options in
NFV. All these many options should be implemented as Virtual
Appliances developed by Independent Software Vendors (see
Figure 1). This is the basic idea for SDN and NVF relationship!
And it is a doubtful idea, speaking honestly.
VI. DISCUSSION ON NFV IMPLEMENTABILITY
The discussed above SDN and NFV concepts are extremely
attractive projects, however, it seems, their main target is still
the community of hardware vendors. The question arises: are
these concepts implementable from software developer point of
view? It is actually a key question. It is optimized hardware
architecture, but its success depends on the programming.
Let us go back to telecom software history and recall
several big projects, failed due to software and programming
related issues.
Efficient service life cycle depends on two key factors:
short time to market and deployment flexibility. Time to
 2016 8th International Congress on Ultra Modern Telecommunications and Control Systems and Workshops (ICUMT)
market might be minimized through a homogeneous software
environment that enables deployment on existing network
infrastructure without the need for hardware modification.
Let us start with Intelligent Network. According to
standards, SCE (Service Creation Environment) and SIB
(Service Independent Block) library were invented to simplify
software development and 3d parties work. There are 17 SIBs
(in ITU standard) and 21 SIBs (from ETSI). In reality, telecom
vendors had used up to 100 vendors specific SIBs. The very
idea failed: software developers were asked to know too many
telephony details.
TINA project was an unsuccessful attempt (started back in
1992) by several main actors in the telecommunication world
to define the new software architecture. The next was Parlay
Group (founded 1998) that specified APIs for the telephone
network. Parlay project ended unsuccessfully around 2007. In
2003, the Parlay Group released a new set of web services
called Parlay X. There are a much simpler set of APIs intended
to be used by a larger community of developers. Parlay X
ended without any wide use.
Now we talk about SDN. We think the formal description
for any public API (including Northbound SDN API) is very
important. Of course, the idea of a public API for network
nodes is not entirely new. As a direct analogue, we can
mention Parlay, for example. Telephone switching system
(PBX) is also a network node, and Parlay (Parlay X) API [7]
plays the same role as the Northbound SDN API. It is a public
API, provides an open programming interface to network’s
hardware for application programs (for applied services). The
lessons from Parlay’s failure are important. Its main problems
were connected with the difficulty of adopting API to the
developers [8]. The development of services with Parlay API,
in fact, did not save time for developers. It is the same time to
market factor. Vice versa, it takes usually more time than the
deployment of non-portable (closed) APIs. Again, time to
market is a key indicator for software development tools. This
is the main purpose of using the metadata for Northbound SDN
API [9] [10] [11].
The transition from TDM technology to IP switches brings
the extra software expenditures (Table 1). Compare two large
TDM and packet switches of the same bandwidth – 640 Gbps
(10 million TDM calls simultaneously): the operation systems
demonstrate the significant difference – up to three times
(about 10 times in cost).
ETSI document on NFV Architectural Framework [12]
points out many software-related issues. For example, we can
mention here the security tasks.
Traditionally, physical network functions assume a tight
coupling of network functions hardware and software, which,
in most cases, is provided together by a single vendor. In the
NFV scenario, multiple vendors are expected to be involved in
the delivery and setup of different NFV elements. As a result,
new security issues need to be named:
• The use of hypervisors may introduce additional
security vulnerabilities,
255
• The usage of shared storage and shared networking
may also add additional vulnerabilities,
• The interconnection among NFV end-to-end
architectural components can create new security threats,
• The execution of diverse VNFs over the NFV
infrastructure can also create additional security issues.
Table 1. Comparison of TDM and packet switches, 2012 [5].
TDM Switch Packet Switch
Ciena Cisco CSR-1
CoreDirector
B/W 640 Gbps 640 Gbps
Power 1440 W 9630 W
Price $84, 000 $884, 000
Software (M lines) 3 M lines 8 M lines
On the all above mentioned, the reasonable question arises: can
we count on the success of the NFV project?
Interesting, that development tools in NFV area actually
reproduce the above-mentioned problems with generic telecom
APIs. For example, Open Platform NFV [13] focuses on
building NFV Infrastructure (NFVI) and Virtualized
Infrastructure Management (VIM) by integrating components
from upstream projects such as OpenDaylight, OpenStack,
Ceph Storage, KVM, Open vSwitch, and Linux. These
components, along with application programmable interfaces
(APIs) to other NFV elements form the basic infrastructure
required for Virtualized Network Functions (VNF) and
Management and Network Orchestration (MANO)
components. The mess of Service Independent Blocks has
replaced simply with the mess of different APIs.
VII. CONCLUSION
The key moment, in our opinion, is automation of SDN
programming and automation for any REST API (including
SDN, of course) depends on meta-data. The typical model for
REST-based API deployment includes the “manual” consulting
(reading) with the API manual. Thus, without the metadata,
there is no way to automate programming [14]. That is why
we can conclude that metadata for Northbound API
(application API) is a key problem. Of course, the lack of
meta-data in REST model is not a specific SDN problem.
Actually, it is a payment for the simplicity of REST model.
However, the network programming (network management,
for example) really requires automated solutions. In REST
programming, only meta-data allow programmatic API
discovery. In this connection, we can conclude that the real
problem for application level API in SDN is the way for
describing meta-data. The question is how to expand this
information to REST API. In our opinion, it is what
Northbound (or Application level) API standardization should
be about.
 2016 8th International Congress on Ultra Modern Telecommunications and Control Systems and Workshops (ICUMT)

In our opinion, the unified API for application-level
interfaces in unlikely. It is a more realistic scenario to create a
unified format for meta-data and automate the programming.
Otherwise, the manual redesign and programming for NVF
architecture would be very time-consuming and costly.
REFERENCES
[1] Nail Kavak et al. (2016) The central office of the ICT era: agile, smart
and autonomous. Ericsson Technology Review, May, 2016.
[2] ETSI Network Functions Virtualisation – Introductory White Paper
October 22-24, 2012 at the “SDN and OpenFlow World Congress”,
Darmstadt-Germany. http://portal.etsi.org/NFV/NFV_White_Paper.pdf .
Retrieved: Jun, 2016
[3] US Department of Defense. Unified Capabilities Framework 2013.
January 2013.
[4] US Department of Defense. Assured Services (AS) Session Initiation
Protocol (SIP). Errata-1, July 2013.
[5] Das, Saurav, Guru Parulkar, and Nick McKeown. "Rethinking IP core
networks." Journal of Optical Communications and Networking 5.12
(2013): 1431-1442.
[6] ETSI GS NFV-EVE 005 V1.1.1 (2015-12) Network Functions
Virtualisation (NFV); Ecosystem; Report on SDN Usage in NFV
Architectural Framework.
[7] Magedanz, Thomas, Niklas Blum, and Simon Dutkowski. "Evolution of
SOA concepts in telecommunications." Computer 40.11 (2007): 46-50.
[8] Schneps-Schneppe, M., & Namiot, D. (2012, May). Open API for M2M
Applications: What is Next?. In AICT 2012, The Eighth Advanced
International Conference on Telecommunications (pp. 18-23).
[9] Sneps-Sneppe, Manfred, and Dmitry Namiot. "Metadata in SDN API for
WSN." New Technologies, Mobility and Security (NTMS), 2015 7th
International Conference on. IEEE, 2015.
[10] Namiot, D., & Sneps-Sneppe, M. (2014, June). On software standards
for smart cities: API or DPI. In ITU Kaleidoscope Academic
Conference: Living in a converged world-Impossible without
standards?, Proceedings of the 2014 (pp. 169-174). IEEE.
[11] Namiot, D., & Sneps-Sneppe, M. (2014). On M2M Software.
International Journal of Open Information Technologies, 2(6), 29-36.
[12] ETSI GS NFV 002 V1.1.1 (2013-10). Network Functions Virtualisation
(NFV); Architectural Framework.
[13] Open Platform NFV https://www.opnfv.org/ Retrieved: Jun, 2016
[14] Namiot, D., & Sneps-Sneppe, M. (2014). On IoT Programming.
International Journal of Open Information Technologies, 2(10), 25-28.

View publication stats

256