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

net/publication/308019946

Challenges on IP-RAN networks for the successful evolution of SDN

Article · July 2016

CITATIONS READS

0 4,437

2 authors:

Kastuv M. Tuladhar Bashanta Sharma

University of South Dakota Lamar University
7 PUBLICATIONS   62 CITATIONS    1 PUBLICATION   0 CITATIONS   

SEE PROFILE SEE PROFILE

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

Vehicular Ad-hoc Networks View project

Software Defined Networking View project

All content following this page was uploaded by Kastuv M. Tuladhar on 12 September 2016.

The user has requested enhancement of the downloaded file.

 Challenges on IP-RAN networks for the successful
evolution of SDN
Kastuv Mani Tuladhar
Datacom Engineer, Huawei Technologies Co., Pvt. Ltd. Nepal, B.E. Electrical and Electronics Engineering, Kathmandu
University
[email protected]

Bashanta Sharma
Transmission Engineer, Huawei Technologies Co., Pvt. Ltd. Nepal, B.E. Electronics and Communication Engineering,
Kathmandu Engineering College
[email protected]

Abstract—In recent years, we have witnessed major such issues by automating the network and changing the
transitions on wireless networks which have been upgraded traditional way of network management. SDN architecture
from 2G, 3G to long-term evolution (LTE). Similarly, mobile currently employing open northbound interfaces (NBIs) and
backhaul networks migrated from synchronous digital unified southbound interface (SBI) which will be the
hierarchy/multi-service transmission platform (SDH/MSTP) to foundation for the evolution of WAN from proprietary to
IP radio access network (IP RAN). IP RAN is a key solution for openness. Additionally, SDN-based centralized management
mobile backhaul due to its advantages in better network and control allow for automatic network optimization,
stability, service scalability, multi-service bearer capacity. The reduced O&M costs, and improved network utilization.
hierarchical virtual private network (H-VPN) in IP-RAN not
Thus, IP-RAN lay out the driving force for the requirement
only fulfills the requirements of S1 services over the shortest
of WAN to SDN transition.
path but also used as a Route Reflector (RR) that ensures
network to reach high availability(HA).

After succeeding the mature LTE technology, industries II. SDN REQUIREMENTS:
have now started to consider a transition to 4.5G and 5G
networks. So, there will be a new bearer requirement that A. Requirement of auto sense and service deployment
needs to consider such future advancement. Software Defined
Networking (SDN) and network functions virtualization (NFV) The evolving NFV technology will account the cloud-
is a new networking paradigm that will continue to deliver far- based Virtualized-Evolved Packet Core (vEPC) in the future.
reaching impacts on IP-RAN to anticipate future network Furthermore, in upcoming 5G services, EPC will deal
changes. multiple services like Internet of Things (IoT), demanding
There has been tremendous research carried out in this voice services and other multiple services with varying
technology. Through the requirements and challenges that requirements on network service level agreement (SLA),
have been faced in the current IP-RAN networks, this paper vary in service path selection and quality of service (QoS)
aims at bringing the successful development and deployment of requirements. For the cloud-based future EPC, IP-RAN is
SDN. using L3VPN to provide vEPC interconnection, however,
L3VPN cannot meet the deployment efficiency in the NFV
era as it requires a lot of manual intervention and time. Thus,
Keywords—SDH, MSTP, H-VPN, LTE, RR, HA, SDN, NFV, to meet the SLA for rapid generation of VPN deployment in
MBB, NBI, NE, vEPC, SLA, QOS, IoT, CDN, PoP, IoV, VR, AR, the mobile backhaul network, IP RAN needs to provide
CDN, CLI, SNC, GUI, NQA, PMS, AS, LSP, NE, SNMP, LLDP, network connection on demand. Hence, there requires a
VLL, L3VPN collaboration of wireless and network side to sense the
automatic service requirement and VPN deployment.
I. INTRODUCTION

IP-RAN provides features for network openness, B. Requirement of low delay

automatic service provisioning, and optimization for the The delay is the main concern when it comes to 5G. To
transformation of WAN towards SDN. The multi-vendor improve better user experience and to meet the specific
environment where end-to-end services are managed by requirement of the Internet of Vehicles (IoV), virtual reality
different NMSs has complexities arising in the carriers’ (VR) and augmented reality (AR) the network must not be a
WANs. Service deployment is dependent on the manual bottleneck. Besides, the use of Content delivery network
planning and configurations, which is prone to errors and (CDN) will help to reduce the transmission delay as it stores
leads to low troubleshooting efficiency. SDN will overcome
 a cached version of its content in multiple geographical Resource conflicts may occur during service
locations. Each point of presence (PoP) contains a number of configuration and deletion of NE; such problems will directly
caching servers responsible for content delivery to visitors affect the success rate of service configuration.
within its proximity. The smart delay mechanism can be used
to manage path control capabilities so that forwarding paths
can be calculated and controlled based on delay constraint.
Such a smart delay mechanism can also be implemented
using SDN.

III.LEASED LINE SERVICES NEW REQUIREMENTS ON SDN IP

RAN NMS

SNMP/Netconf SNMP/Netconf
IP RAN has the features of complete coverage, high SNMP/Netconf
reliability, and guaranteed QoS. Lots of carriers have already
begun to deploy leased line services on IP RANs. During the
process, they also encountered new requirements and some Mobile Bearer services
difficulties. or Enterprise services

Leased line services have large service deployment time SNMP/Netconf SNMP/Netconf
as the deployment relies on manual planning and SNMP/Netconf
configuration. Particularly in cross-AS and cross-vendor
scenarios, the management collaboration among different
carrier departments and the service interconnections in the
multi-vendor environment simply lead to low deployment SDN Controller
efficiency and poor customer satisfaction. Leased line service
Figure 1: Co-existence of traditional NMS and SDN Controller
deployment will also face difficulties in SLA guarantee and
account reconciliation.
SDN can mitigate the above deficiencies. The carriers are
now focusing on the openness of network resource and The resource usage of services on the NMS may fail to
capability and integration, which makes it possible for synchronize to the SNC in real time and SNC might fail to
enterprise customers to provision leased line services on their deliver the configurations of only partial configuration might
own. This greatly improves the leased line service have delivered.
provisioning efficiency and enhances the enterprise customer
satisfaction while at the same time ensuring leased line
service SLA based on SDN-based path computation.

On such conditions, any modification on the NMS during

O&M may lead to inconsistency between NE data and SNC
IV. CHALLENGE ON IMPLEMENTING SDN CONTROLLER ALONG data.
WITH NMS

Till now, IPRAN services are deployed and maintained

However, the above issues could be solved by isolating
using NMS or command line interface (CLI). During the
NE resources. NE resources are allocated on the basis of user
SDN implementation (before migration), IP RAN devices
accounts of each service. completely isolating NE resources
will co-managed and co-controlled by SDN controller (SNC)
to the NMS and SNC will cause to use their own resources
and NMS.
and services. But this solution is not suitable for large scale
IPRAN as it requires many changes in NMS and NE. The
alternative is to avoid co-management and co-control issue
With the placement of both traditional service NMS and by migrating all the services and O&M to the SNC as SDN
new SNC, the network will face issue to resource conflicts solution will put into wide use.
and inconsistent data. As both services share the
infrastructure and resources like tunnel id, the
implementation need to consider the co-management and co-
control issues. The coexistence of two control servers in such
conditions may lead the following problems:
 V. ARCHITECTURE OF SDN IN IP RAN

The key components of SDN architecture are:

 APP: The simplified graphical user interface

(GUI) is the entry of the network function
APP
automation that allows the user to rapidly restconf

complete the service provisioning and automatic NetMatrix Traffic Optimization App

path optimization. It will replace and enhance restconf restconf

many features of traditional OSS functions like NMS restconf SNC restconf Network performance analyzer

creating automatic network topology, associated BGP-LS/PCEP/Netconf

fault detection, managed alarms and notification

and related network quality analyzer (NQA) for
performance monitoring system (PMS). Thus, it BTS / NodeB IP- RNC / BSC

includes traffic optimization app and automated ACCESS AGGREGATION

service provisioning app for the leased line RING RING
SGW/MME
services. eNodeB

H-VPN
Enterprise
Enterprise

 Netmatrix:It offers two types of functions: L3VPN L3VPN

2G Service VRF1 2G Service VRF1

orchestration and service abstraction. The 3G Service VRF2 3G Service VRF2
3G O&M VRF3 3G O&M VRF3
orchestration is between IP RAN and the optical
network, NFV network (vEPC and cloud LTE S1 VRF4
LTE O&M VRF5
LTE S1 VRF4
LTE O&M VRF5
services) and wireless RAN controller as well as LTE X2 VRF6
Tunnel 1 Tunnel 2
LTE X2 VRF6

inter-autonomous system (AS). Leased Line Leased Line

VLL VSI VSI

 SNC: It is the core component of SDN Figure 2: SDN architecture along with IP RAN backhaul
architecture that is responsible for network
access control and breaks down end-to-end
services by NE. The service configurations are
delivered to forwarders through SBIs. It also
controls and adjusts the BGP label switched VI. KEY ISSUES WITH SERVICE AUTOMATION
paths (LSP) across the domain.
a) Reporting physical inventories and resources

 NMS: As a traditional O&M for existing NE,

NMS system is responsible for network O&M. Physical network resources and service data
inventories are the requirements for the service provisioning.
Physical resources and inventories are reported by NMS NBI
 Network performance analyzer: Typical in the existing IP RAN solution. In the SDN IP RAN
network analyzer is required that is responsible solution, automated service provisioning is performed
to implementing network and service through Netmatrix+APP. Netmatrix can obtain such data
performance statistics and analysis to provide either from the database of SNC or the from the database of
the input information for traffic optimization. It the OSS. Similarly, physical topology information can be
will be like Netflow cisco or uTraffic or obtained by running Link Layer Discovery Protocol (LLDP)
uNetBulider of Huawei. The SLA data is in the forwarders and report it to the SNC or NMS through
provided to the SNC for path computation Simple Network Management Protocol (SNMP) traps.
where NMS will be interconnected with SNC
via RESTful NBIs for automated service
provisioning. b) Service Deployment

The user in the GUI may request for the Point to

Point(P2P) or Point to MultiPoint(P2MP) connection
services. However, netmatrix will convert such connection
services to the virtual leased line (VLL) or Layer 3 Virtual
Private Network (L3VPN) services. Thus, the SNC is
required to create the VPN and the associated tunnels. If the
existing tunnels from the traditional NMS does not meet the REFERENCES
SLA requirement or does not exist, then the SNC have to
create the new tunnels between the Provider Edge (PE).
[1] Cisco Systems, Inc. “Migration to All-IP Radio Access Network (RAN)
Transport”, Webtutorials, white paper, April 2009. [Online]
There are a variety of tunnels for deployment namely: http://www.webtorials.com/content/2009/04/migration-to-all-ip-radio-
LDP LSP, RSVP-TE, BGP-LSP and service router (SR). access-network-ran-transport.html [Accessed March 18, 2016]
LDP LSP is the basic tunnel protocol that creates full meshed
N*N tunnels. However, only RSVP and SR can support the [2] Antonio Sanchez-Monge & Krzysztof Grzegorz Szarkowicz “MPLS in
bandwidth reservation and path control ability. However, to the SDN Era,” O’Reilly Media, Inc , pp. 573-616, December 2015.
prevent from unwanted network resource usage, CAR or
[3] Ian F. Akyildiz , Ahyoung Lee , Pu Wang , Min Luo , Wu Chou , “A
traffic shaping can be applied at the entrance.
roadmap for traffic engineering in SDN-OpenFlow networks, ” Elsevier ,
computer Network , 19 June 2014
c) SBI implementation
[4] Thomas D. Nadeau, Ken Gray “Software Defined Networks,” O’Reilly
Media, Inc , pp. 241-260, August 2013.
IP RAN may contain devices of different version and
different vendors with varying specifications and capacity. [5] Kevin Riley “The New Network Management Tactic: Bandwidth On
So, it is a big challenge to apply SNC. IP RAN uses SBIs of Demand”, Network Computing, Information week, December 2015.
the NMS to connect to the NE and NBIs of the NMS to [Online] http://www.networkcomputing.com/networking/new-network-
connect to the SNC. SDN forwarders use NETCONF or management-tactic-bandwidth-demand/592428015 [Accessed June 18,
OpenFlow SBIs to deploy configurations and entries to 2016]
forwarders.
[6] Cui Jiang, Huawei Technologies. “Mobile back haul’s road to IP RAN
and FMC evolution”, Publications, July 2008, Issue 42. [Online]
VII. GLOBAL NETWORK OPTIMIZATION http://www1.huawei.com/en/about-huawei/publications/communicate/hw-
081172.htm [Accessed June 27, 2016]

In the existing IP-RAN solution, all NE are distributed [7] Huawei Technologies. “Net Matrix Production Description”, [Online]
with their control and forwarding plane. Thus, the path http://developer.huawei.com/en/ict/Products/SDN/Components/Forum/Ba
computation is local with the NE and the solution is nner/en-NetMatrix_Production_Description [Accessed July 9, 2016]
distributive. All the calculation of the shortest path from
source node to the sink node is based upon either strict or
loose explicit path, which is manually specified path
constraints.
It has raised the problem that the path selected may not
be globally optimized path. The network load balancing is
not considered in this case. Traditional IP-RAN solves this
issue through manual intervention by specifying the explicit
paths through the specified LSP by equally dividing the
traffic nodes to its Route Reflectors (RR). If the centralized
route calculation is applied in SDN IP-RAN, then the
automatic global network path optimization can be achieved.

VIII. BANDWIDTH ON DEMAND (BOD)

In the case of enterprise services, it is important to meet

the demands of the increasing bandwidth requirement for the
customers and tenants. It is required to observe the real-time
service performance reports of the systems like traffic usage,
packet loss, jitter, and delay which will also be provided to
the tenants in the SDN era. Thus, in the case of excess
bandwidth usage and resource requirement, it could be very
useful to get the notification for bandwidth expansion.

View publication stats