SDN and NFV Evolution Towards 5G

Marie Paule-Odini, HPE

IEEE Softwarization, September 2017


SDN and NFV have now been around for some years with an uptake in telecom network a bit slower than expected but these technologies are definitely shaping 5G as initiated by NGMN [1].
This article will highlight the relationships between SDN, NFV and 5G networks.

5G timeline

Standards have this reputation of being slow but standards are still the only way the telecom industry knows to guarantee interoperability, free enterprise and sustainable business to guarantee secured, open, reliable and continuously innovative worldwide communications. 3GPP, that has been shaping mobile telecom networks for years now, is no exception with its three stages approach of requirements, architecture and protocols!

Yet, in June 2017 a number of operators eager to experiment 5G new radio technologies have convinced 3GPP RAN to accelerate and ‘simplify’ the roadmap to issue a first phase a bit ahead of schedule. They agreed on a non-standalone option that will connect the new radio to an LTE network. Then, issue the second phase with standalone 5G.

In the meantime, actors in Asia, and KT in particular, has issued its own specifications to be ready for the Olympics in Korea in 2018, bringing live experience, then influence the 3GPP standard specifications and  re-align to the common standard.

Below timeline provides an overview of 5G milestones:

Figure 1

Fig 1 – 3GPP 5G timeline and other events

5G initial specifications

If we look into the initial specifications that have been published, and primarily the architecture specifications 3PP TS 23.501 [10], we discover a clear split between user plane and control plane following the SDN concepts, and consequently a number of new network elements, with new reference points and new interfaces. The requirements such as IoT or ultra low latency for instance are also driving the need for enhanced or new protocols.

Figure 2

Fig 2. 5G non roaming architecture – source 3GPP TS 23.501 [10]

  • The UPF (User Plane Function) and SMF (Session Management Function) in the control plane replaces the SGW–PGW that we know in LTE.
  • The AMF (Access and Mobility Management) replaces the MME
  • The AUSF (Authentication Server Function) replaces the MME/AAA
  • The NEF (Network Exposure Function) is a SCEF evolution and API layer
  • The NRF (Network Repository Function) plays a role of evolved DNS
  • The PCF (Policy Control Function) is a 5G PCRF
  • The UDM (Unified Data Management) is an evolution of HSS and UDR
  • The AF (Application Function) is the application layer, like gsmSCF or AS
  • The SDSF (Structured Data Storage network function) is now UDR
  • The UDSF (Unstructured Data Storage network function) would store states and other information – SDSF and UDSF may be collocated and located with UDM

Clearly from the list above, we identify a number of network elements that are a smooth evolution from LTE, ie PCRF becoming PCF, while for others the evolution is a major impact: typically for SP-GW being split in UPF for the user plane and SMF for the control plane. Similarly the AAA-HSS evolution to AUSF-UDM and storage with SDSF and UDR. More generally speaking we are moving to a Service Based Architecture, more and more IT like, and more and more stateless functions with state and other data being stored in separate components and shared data layer. As 3GPP Release 15 progresses into Stage 3, more details will be provided and of course Release 16 will even refine further for 5G Standalone.

5G and NFV

3GPP SA5, the group that is defining the management of 3GPP networks, has been working with ETSI NFV for some years now, actually starting in Release 13 with 3GPP TR 23.842 [3]. Figure 3 below, where 3GPP defines on the left hand side the Network Element (NE) that are not virtualized (PNF – Physical Network Function), the ones that are virtualized (VNF – Virtual Network Function) as defined by ETSI, the traditional vendor Element Manager (EM) which actually tend to disappear with NFV and DevOps but are still there in the picture or embedded in VNF, interfacing with the Network Management (NM) layer sitting in the OSS. On the right hand side, the NFV MANO (Management and Orchestration) as defined by ETSI NFV, that manages the virtualized infrastructure, the virtualized network functions (VNF) and the network services (NS) that span across VNF and PNF. So besides adopting NFV MANO, NFVI and VNF, 3GPP is also adopting the Os-Ma-Nfvo interface with the 3GPP NM-OSS and the Ve-Vnfm-em interface with the 3GPP PNF-EM. 

Figure 3

Fig 3 – Network Management mapping between 3GPP and ETSI NFV – source 3GPP TR32.842 [3]

 3GPP has expanded on this ETSI NFV adoption in Release 14 with TS28.525, 526, and 527 [7] specifications, with 3GPP TS28.527 [7] being the shortest 3GPP specifications published, basically referencing ETSI NFV IFA008 [12] and IFA013 [13] for Os-Ma-nfvo and Ve-Vnfm-em interfaces and information model in a couple of pages!

In parallel, ETSI NFV is expanding its work in ETSI NFV Release 3 to explore and address some of the 5G new use cases and requirements, as described by the ETSI NFV. This includes work items on Network Slicing that I personally initiated (NFV-EVE012) but also other topics such as Cloud Native addressing containers (NFV-EVE011), Real time management (NFV-IFA025), but also Policy Management (NFV-IFA023), in line with the recent ETSI ISG ENI [14].

5G and SDN

In line with previous work from IETF or ONF and projects experimenting SDN use cases or SGI-Lan service chaining, 3GPP has introduced EPC Control Plane-User Plane Separation (CUPS) in Release 14.  Typically for SGW, PGW and TDF, three new interfaces were defined: Sxa, Sxb and Sxc in TS 23.214 [5] as illustrated in Figure 4.

Figure 4

Fig 4. 3GPP User Plane – Control Plane Split – source 3GPP TS 23.214 [5]

Then in June 2017, 3GPP selected a new protocol between these control plane and user plane layers: PFCP, Packet Forwarding Control Plane, as shown in Figure 5.

While lots of work had been done in the research and industry community using Openflow and SDN controller to configure EPC user plane, 3GPP study compared a few protocols, including Forces, Openflow, GTP and Diameter against the requirements for 5G and concluded that gaps were too important and most effective was to define a new protocol, using UDP and managing Sx node procedure as well as Sx session procedures.

Figure 5

Fig 5. 3GPP PFCP protocol – source TS 29.244

Network Slicing Use Case and 5G

The network slicing concept has been introduced several years ago by NGMN 5G white paper [1]: “A network slice, namely “5G slice”, supports the communication service of a particular connection type with a specific way of handling the C- and U-plane for this service. To this end, a 5G slice is composed of a collection of 5G network functions and specific RAT settings that are combined together for the specific use case or business model”. NGMN then refined in their dedicated paper on network slicing [2] with a definition that set the stage for further work in the industry: “Network Slice Instance: a set of network functions, and resources to run these network functions, forming a complete instantiated logical network to meet certain network characteristics required by the Service Instance(s)”. At this stage, some of the key principles were set such as end to end network slice and logical instance associated to a service. To be pragmatic this slice could combine a set of virtualized and non-virtualized functions.

Then ONF explained how to define and manage network slices [15] with SDN as described in Figure 6.

Figure 6

Fig 6. ONF and Network Slicing – source ONF [15]

Lately 3GPP embraced the concept in TS 23.799 [9] and is now studying the management and orchestration of slices in TR28.801 [11], with a CSP (Communication Service Provider) invoking a Communication Service that ‘uses’ a NOP (Network Operator) Network Slice. This Network Slice ‘contains’ Network Slice Subnets which contains Network Functions (virtualized or not …). These Network Functions are from Access and Core Network. However 3GPP has not defined yet the mapping between Network Slice or Subnet and ETSI NFV Network Services, but others have suggestions. In the 5G America’s paper on Network Slicing [19] that I co-authored, we agreed that network slices would invoke ETSI NFV network services via NFV MANO, and several 5G-PPP projects took the same path.

5G Projects

In parallel and fueling the standard work, many projects and initiatives also tackle the 5G topic and study the leverage of SDN and NFV technology to deliver next generation networks. I have picked a few examples in this article that illustrate different scenarios.

The European 5G Public Private Partnership (EU 5G PPP) which is sponsored by the European Commission has a series of projects with currently two running phases: a phase 1 which is nearly completed and a phase 2 that is just started. Among those, the 5G-Ex project [16] where HPE is participating along with Orange, Telefonica, and other ICT actors, is studying next generation networks and management aspects, including virtualization, SDN, slicing, and multi-domain, multi-operator domains. 5G-Ex is typically defining inter-operator interfaces for slice and resource management for more and more dynamic and automated network environments.

Figure 7

Fig 7. 5G-Ex project architecture [16]

Another interesting project is 5G Lab Germany [18] which is exploring network coding for 5G radio and SDN as well as Edge IoT use cases for connected cars and robots, addressing the requirements of 5G ultra low latency and tactile internet. This collaboration of industry players with academic research is the secret sauce to break through on some of these complex topics which involve high performance hardware, very flexible architecture and efficient software.

Figure 8

Fig 8. 5G Lab Germany project overview [17]


Overall, a lot of things are going on, too many things probably for an industry that is transforming rapidly with challenging revenue models, shrinking resources to contribute, align and implement something that will work! but lots of new opportunities coming with 5G and beyond the pure 3GPP-5G as it is shaping now. BBF (Broadband Forum) is building its own 5G roadmap with lots of SDN and NFV very likely and will align with 3GPP as shown below in Figure 9 to deliver 5G Fixe Mobile Convergence (FMC) by 2020. So more changes to come in an ever innovating world!

Figure 9

Fig 9. 5G Fixe Mobile Convergence Timeline [18]



[1] Next Generation Mobile Networks (NGMN) Alliance: 5G white paper

[2] NGMN Alliance: "Description of Network Slicing Concept", Version 1.0, January 13, 2016

[3] 3GPP TR 32.842: “Study on network management of virtualized networks”; Release 13

[4] 3GPP 23.714 v14.0.0 - Study on control and user plane separation of EPC nodes; Release 14

[5] 3GPP 23.214 v14.3.0 - Architecture enhancements for control and user plane separation of EPC nodes; Stage 2; Release 14

[6] 3GPP TS 28.500: "Telecommunication management; Concept, architecture and requirements for mobile networks that include virtualized network functions".

[7] 3GPP TS 28.527: Life Cycle Management (LCM) for mobile networks that include virtualized network functions; stage 2; release 14

[8] 3GPP TS 22.261 v2.0.0: “Service requirements for the 5G system; Stage 1”.

[9]3GPP TR 23.799 v14.0.0: “Study on Architecture for Next Generation System”. Dec. 2016.

[10] 3GPP TS 23.501: "Technical Specification Group Services and Systems Aspects; System Architecture for the 5G system; Stage 2"

[11] 3GPP TR 28.801 V1.2.0; Study on management and orchestration of network slicing for next generation network; release 15

[12] ETSI GS NFV-IFA 008 (V2.1.1): "Network Functions Virtualisation (NFV); Management and Orchestration; Ve-Vnfm reference point – Interface and Information Model Specification".

[13] ETSI GS NFV-IFA 013 (V2.1.1): "Network Functions Virtualisation (NFV); Management and Orchestration; Os-Ma-Nfvo reference point – Interface and Information Model Specification".

[14] ETSI ISG ENI – Experiential networked intelligence

[15] ONF paper on Applying SDN architecture to 5G Slicing

[16] 5G-PPP 5GEx -

[17] 5G Lab Germany -

[18] BBF – 5G Fixe Mobile Convergence

[19] 5G Americas Network Slicing White Paper



Marie-Paule OdiniMarie-Paule Odini holds a master's degree in electrical engineering from Utah State University. Her experience in telecom experience including voice and data. After managing the HP worldwide VoIP program, HP wireless LAN program and HP Service Delivery program, she is now HP CMS CTO for EMEA and also a Distinguished Technologist, NFV, SDN at Hewlett-Packard. Since joining HP in 1987, Odini has held positions in technical consulting, sales development and marketing within different HP organizations in France and the U.S. All of her roles have focused on networking or the service provider business, either in solutions for the network infrastructure or for the operation.


Overview of RFC7426: SDN Layers and Architecture Terminology

Evangelos Haleplidis, Mojatatu Networks, Canada

IEEE Softwarization, September 2017


The Software-Defined Networking (SDN) concept became the focus of the main networking research topic in academia after its resurgence in 2008[1]. SDN, in a nutshell, refers to a new approach for network programmability, that is, the capability to initialize, control, change, and manage network resources -and therefore behavior- dynamically via open interfaces.

SDN, or the concept thereof, has been in research for a very long time, but the technological advances of the networking and computing industry enabled it to fully mature and showcase major potential as a problem-solving toolset. SDN was quickly, but orthogonally, followed by Network Function Virtualization (NFV)[2], an architecture allowing network functions to be run on virtual environments; and Service Function Chaining (SFC)[3], an architecture that allows services or functions to be stitched together to perform services. NFV and SFC can both readily use the network programmability that SDN provides.

However, despite the popularity of SDN in academia and industry, until recently there was a bit of confusion regarding the layers and interfaces of an SDN architecture. In this light, the Internet Research Task Force (IRTF) IRTF Software Defined Networking Research Group (SDNRG) worked intensively on clarifying these concepts and terminology. The result of this effort is the RFC7426 [4], which addresses the questions about what exactly SDN is, what the layer structure is within the SDN architecture, and how layers interface with each other.

SDN Layered Architecture

RFC7426 follows an approach centered on network devices. Network devices are composed of resources, simple and complex, with network devices being complex resources themselves, thus allowing recursive definition and reusability. Network devices can be implemented in software and/or hardware. That is, the term resource is being used generically, irrespective of the actual instance/implementation of the resource, which can be physical or virtual. The generic use of the term resource makes the RFC7426 architectural model applicable to the NFV and SFC domains as well.

SDN, as can be seen in Figure 1, comprises several abstraction layers, interfaces and distinct planes. Planes refer to the collection of functions and resources that relate to the same functionality, such as the control or management plane. Abstraction layers refer to the abstraction of resources of specific planes and interfaces refer to the APIs between planes.

The architecture defined provides an abstract view of the various planes, which is devoid of implementation details. For example, it was customary for many implementations to implement the management plane on top of the control plane. This can be interpreted as having the control plane acting as a service to the management plane. 

Historically, in many networks, especially in Internet routers and Ethernet switches, the control plane has been usually implemented as tightly coupled with the network device.  When taken as a whole, the control plane has been distributed network-wide.  On the other hand, the management plane has been traditionally centralized and responsible for managing the control plane. However, with the adoption of SDN principles, the distinction between control and management plane is no longer so clear-cut.

Figure 1

Figure 1: The SDN layered architecture according to RFC7426

SDN Planes

RFC7426 distinguishes the following five SDN planes:

  • Forwarding Plane - Responsible for handling data packets based on the instructions received from the control plane. Actions of the forwarding plane include, but are not limited to, forwarding, dropping, and changing packets. Examples of forwarding resources are classifiers, meters, etc. The forwarding plane is also widely referred to as the "data plane" or the "data path".
  • Operational Plane - Responsible for managing the operational state of the network device, e.g., whether the device is active or inactive, the number of ports available, the status of each port, and so on. Examples of operational plane resources are ports, memory, and so on.
  • Control Plane - Responsible for making decisions on how packets should be forwarded by one or more network devices and pushing such decisions down to the network devices for execution. The control plane main job is to fine-tune the forwarding tables that reside in the forwarding plane, based on the network topology or external service requests.
  • Management Plane - Responsible for monitoring, configuring, and maintaining network devices, e.g., making decisions regarding the state of a network device. The management plane may be used to configure the forwarding plane, but it does so infrequently and through a more wholesale approach than the control plane.
  • Application Plane - The plane where applications and services that define network behavior reside. Applications that directly (or primarily) support the operation of the forwarding plane (such as routing processes within the control plane) are not considered part of the application plane.

All planes mentioned above are connected via interfaces. An interface may take multiple forms depending also on whether the connected planes reside on the same device or on different devices.  If the respective planes are designed so that they do not have to reside in the same device, then the interface can only take the form of a protocol.  If the planes are collocated on the same device, then the interface could be implemented via an open/proprietary protocol, an open/proprietary software inter-process communication API, or operating system kernel system calls. RFC7426 focuses on the north/south communication between entities in different planes but does not exclude entity communication within any one plane.

It is important to distinguish between control and management interfaces as they have their own distinct characteristics depending on the respective planes. Initially the management plane was considered out of scope for SDN, but recently published documentation by both ITU [5] and ONF [6] include the management plane and are well aligned with RFC7426.

SDN Management and Control

RFC7426 focuses on four characteristics for the distinction between SDN management and control. The first characteristic is timescale. Timescale specifies how fast a plane responds and needs to respond. The control plane responds in very small timescales while the management plane may not necessarily need to react fast to changes.

The second characteristic is persistency referring to how long the state of the device will remain stable. Control plane state usually changes rapidly whilst management plane state may remain static for a longer period of time. The third characteristic is locality; control plane usually is distributed and with the device, whilst management plane tends to be centralized and outside devices.

Finally, RFC7426 recalls the CAP theorem that states that for a distributed system, between three characteristics, Consistency, Availability and Partitioning tolerance, a designer can only select two at best. Since SDN proponents initially discussed a centralized controller, CAP provides a good tool to specify the issues that this may bring.

SDN Abstraction Layers

RFC7426 defines the following abstraction layers:

  • Device and resource Abstraction Layer - abstracts the resources of the device's forwarding and operational planes to the control and management planes. The DAL is one of the most important abstraction layers, as the services that the rest of the planes provide depend on the DAL's richness and flexibility to describe resources.
  • Control Abstraction Layer - abstracts the Control Plane Southbound Interface and DAL from the applications and services of the control plane.
  • Management Abstraction Layer- abstracts the Management Plane Southbound Interface and DAL from the applications and services of the management plane.
  • Network Services Abstraction Layer -provides access to services of the control, management, and application planes to other services and applications.


RFC7426 provides a structural and modular approach to the SDN architecture for designing networks, services and applications by giving a toolset of planes, interfaces and abstractions. Employing the layered architecture model introduced in RFC7426 can provide researchers and practitioners with useful guidelines on how to build disaggregated network system designs.





Evangelos HaleplidisEvangelos Haleplidis, Ph.D. was born in Greece in 1979, received his Diploma degree from Electrical and Computer Engineering Department of the University of Patras in 2002. For his diploma thesis he implemented part of the IPv6 protocol in hardware (VHDL). He received his Ph.D. in Computer Science from the Department of Electrical and Computer Engineering in the University of Patras in 2016. He has taken part in the successful IST projects FlexiNET and Phosphorus. He is the author/co-author of a number of RFCs and drafts in the ForCES working group in IETF and the SDNRG research group in IRTF. His main field of interest is network management, network protocols and network services.



Stefano SalsanoStefano Salsano is Associate Professor at the University of Rome Tor Vergata. His current research interests include Software Defined Networking, Information-Centric Networking, Mobile and Pervasive Computing, Seamless Mobility. He participated in 16 research projects funded by the EU, being Work Package leader or unit coordinator in 8 of them (ELISA, AQUILA, SIMPLICITY, Simple Mobile Services, PERIMETER, OFELIA, DREAMER/GN3plus, SCISSOR) and technical coordinator in one of them (Simple Mobile Services). He has been principal investigator in several research and technology transfer contracts funded by industries (Docomo, NEC, Bull Italia, OpenTechEng, Crealab, Acotel, Pointercom, s2i Italia) with a total funding of more than 1.3M€. He has led the development of several testbeds and demonstrators in the context of EU projects, most of them released as Open Source software. He is co-author of an IETF RFC and of more than 130 papers and book chapters that have been collectively cited more than 2300 times. His h-index is 27.


TableVisor 2.0: Towards Full-Featured, Scalable and Hardware-Independent Multi Table Processing

Stefan Geissler, University of Wuerzburg, Germany; Stefan Herrnleben, University of Wuerzburg, Germany; Robert Bauer, Karlsruhe Institute of Technology, Germany; Steffen Gebert, University of Wuerzburg, Germany; Thomas Zinner, University of Wuerzburg, Germany; and Michael Jarschel, Nokia Bell Labs, Germany

IEEE Softwarization, September 2017


The original idea of Software Defined Networking (SDN) is to control a network consisting of COTS (Commercial-Off-The-Shelf) hardware switches by programming their forwarding behavior via a standardized southbound interface such as OpenFlow. However, this vision of a unified interface towards the data plane has not always been held up in practice. SDN-enabled devices are often shipped with different hardware capabilities and configurations, e.g., with a varying number of flow tables or support for certain data plane features. Furthermore, complexity and feature requirements of control plane applications have increased significantly since the SDN concept has first been introduced.

While new and updated versions of the OpenFlow control protocol aim to provide the features required to fulfil control plane requirements, the challenging device heterogeneity inherent to the evolving and changing landscape of software defined networks remains. Due to this device heterogeneity, network application developers currently have no other choice than either restrict the compatibility of their control software to a set of well-known devices or to provide feature-limited solutions for a wider range of devices on the market. Both approaches essentially negate the original vision of SDN as the clear separation of concerns between control and data plane gets softened.

At the same time, many modern SDN applications rely on sophisticated packet processing features such as multi-stage pipeline processing that are a) unavailable in most COTS hardware switches and b) hard to realize if the feature is not supported. Therefore, missing hardware features and hardware heterogeneity is a growing problem for software-based networks. This can be characterized as a general mismatch between control plane requirements and data plane capabilities and is a significant problem for network operators as well as network application developers.

Several approaches try to address these problems by introducing more flexibility into the data plane, e.g., programmable switches [1], OpenFlow Table Type Patterns (TTP) [2], or high-level programming languages for packet processing [3]. Another proposed solution includes further extensions of the OpenFlow protocol in order to achieve a more powerful data plane. While these Programmable Data Plane (PDP) [4] solutions partially solve the mismatch, two fundamental problems remain. First, PDP based solutions are -- by design -- limited to the resources and capabilities of a single device. Control plane requirements going beyond what is provided by the device cannot be satisfied, even if two devices together could easily fulfill the request through their combined functionality. Furthermore, real world SDN deployments are quickly evolving systems that are expected to be composed of heterogeneous devices.

With TableVisor, we propose a novel approach that is able to leverage this device heterogeneity in order to alleviate the current mismatch between control plane requirements and data plane functionalities. TableVisor is based on the concept that multiple physical hardware switches can be pooled together to emulate a device with extended capabilities and capacity. Therefore, a transparent abstraction layer is introduced into the SDN architecture in order to allow the interception of control channel messages. Figure 1 shows the OpenFlow control channel using TableVisor.

Figure 1

Figure 1. OpenFlow Control Channel Using TableVisor.

The abstraction layer allows the modification of messages between the control and data plane in order to realize the combination of multiple physical data plane devices into a single emulated hardware accelerated device. The transparency of the approach allows the usage of a standard SDN controller as well as standard OpenFlow capable data plane devices without the need for any modifications. TableVisor thereby provides controller functionality towards involved data plane devices while emulating a single switch towards the control plane. Depending on the use case, this emulated switch is now able to expose different capabilities to the controller. The feature set of the TableVisor abstraction layer includes, among other use cases, the concatenation of hardware devices to form a feature rich and hardware accelerated multi table switch. Thereby, we are able to exploit the mentioned device heterogeneity by pooling together switches with different capabilities. This functionality, to combine heterogeneous hardware devices, significantly increases the capabilities that can be provided by the data plane without the need to a) modify the control plane and b) develop new switching hardware.

In the future, the introduction of more flexible programmable data plane solutions, like P4, may, at least in part, alleviate the issue of lacking data plane features. The introduction of further types of devices into the data plane landscape, however, will increase the heterogeneity of devices even more. And while these flexible solutions might enable the deployment of more complex control plane applications, the inherent limitations of these devices to their own resources remains, while the power of the TableVisor approach scales with the power of available data plane devices. Furthermore, the functionality of the TableVisor abstraction layer could be extended in the future to include, e.g., a more dynamic feature pooling, in which the control plane application specifies the needed functionality and TableVisor dynamically provisions the required hardware capabilities by selecting appropriate switches. Another possible extension is the translation of control protocols between the control plane instance and the data plane devices. This would not only allow the integration of OpenFlow hardware into legacy networks but also the usage of legacy data plane devices in modern SDN-enabled networks.


[1] R. Ozdag, “Intel Ethernet Switch FM6000 Series - Software Defined Networking,” 2013.

[2] The Open Networking Foundation, “OpenFlow Table Type Patterns (Version 1.0),” Aug. 2014.

[3] ] P. Bosshart, D. Daly, G. Gibb, M. Izzard, N. McKeown, J. Rexford, C. Schlesinger, D. Talayco, A. Vahdat, G. Varghese, and D. Walker, “P4: Programming protocol-independent packet processors,” SIGCOMM Comput. Commun. Rev., vol. 44, no. 3, pp. 87–95, Jul. 2014. [Online]. Available:

[4] D. Perino, M. Gallo, R. Laufer, Z. B. Houidi, and F. Pianese, “A programmable data plane for heterogeneous nfv platforms,” in 2016 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), April 2016, pp. 77–82.



Stefan GeisslerStefan Geissler is working towards his Ph.D at the University of Würzburg, Germany, where he also completed his Master's degree in 2016. He is a researcher in the "Next Generation Networks" research group at the Chair of Communication Networks in Würzburg. His research topics include software defined networking and network function virtualization with focus on performance evaluation.




Stefan HerrnlebenStefan Herrnleben finished his apprenticeship as IT specialist for system integration in 2006 at the IBM Deutschland GmbH. In 2015 he completed his Bachelor thesis, with the first version of TableVisor as main contribution, at the University of Würzburg, Germany. After finishing his Master's degree on analysis and optimization of networks in 2017 he is working as doctoral researcher at the Chair of Software Engineering in Würzburg.




Robert BauerRobert Bauer received his Diploma in Computer Science from Karlsruhe Institute of Technology (KIT) in 2014. Since then, he worked as a research assistant and PhD Candidate at the research group of Prof. Zitterbart (Institute of Telematics, KIT). He is involved in several teaching activities related to software-based networking. In April 2016, he joined the CELTIC EUREKA project SENDATE-PLANETS, where he is working on the coexistence of multiple communication paradigms and user-tailored services that are incorporated into the network. His research interests focus on advanced communication systems based on Software Defined Networking and Network Functions Virtualization.


Steffen GebertSteffen Gebert  received his Ph.D at the University of Würzburg Germany in 2017, where he also received his Diploma degree in 2011. His research interests include softwarized networks and agile network operations.





Thomas ZinnerThomas Zinner received his Diploma and Ph.D. degrees in computer science from the University of Würzburg, Germany, in 2007 and 2012, respectively. His habilitation thesis titled “Performance evaluation of novel network and application paradigms and management approaches.” was finished in 2017. He is heading the “Next Generation Networks” Research Group at the Chair of Communication Networks, University of Würzburg and has published more than 80 research papers in major conferences and journals, receiving six best paper and best student paper awards.



Michael JarschelMichael Jarschel is working as a research engineer in the area of Network Softwarization and Connected Driving at Nokia Bell Labs in Munich, Germany. He finished his Ph.D. thesis, titled “An Assessment of Applications and Performance Analysis of Software Defined Networking'', at the University of Würzburg in 2014. His main research interests are in the applicability of SDN and NFV concepts to next generation networks as well as distributed telco cloud technologies and their use cases.



Francesco BenedettoFrancesco Benedetto was born in Rome, Italy, on August 4th, 1977. He received the Dr. Eng. degree in Electronic Engineering from the University of ROMA TRE, Rome, Italy, in May 2002, and the PhD degree in Telecommunication Engineering from the University of ROMA TRE, Rome, Italy, in April 2007.

In 2007, he was a research fellow of the Department of Applied Electronics of the Third University of Rome. Since 2008, he has been an Assistant Professor of Telecommunications at the Third University of Rome (2008-2012, Applied Electronics Dept.; 2013-Present, Economics Dept.), where he currently teaches the course of "Elements of Telecommunications" (formerly Signals and Telecommunications) in the Computer Engineering degree and the course of "Software Defined Radio" in the Laurea Magistralis in Information and Communication Technologies. Since the academic year 2013/2014, He is also in charge of the course of "Cognitive Communications" in the Ph.D. degree in Applied Electronics at the Department of Engineering, University of Roma Tre.

The research interests of Francesco Benedetto are in the field of software defined radio (SDR) and cognitive radio (CR) communications, signal processing for financial engineering, digital signal and image processing in telecommunications, code acquisition and synchronization for the 3G mobile communication systems and multimedia communication. In particular, he has published numerous research articles on SDR and CR communications, signal processing applied to financial engineering, multimedia communications and video coding, ground penetrating radar (GPR) signal processing, spread-spectrum code synchronization for 3G communication systems and satellite systems (GPS and GALILEO), correlation estimation and spectral analysis.

He is a Senior Member of the Institution of Electrical and Electronic Engineers (IEEE), and and a member of the following IEEE Societies: IEEE Standard Association, IEEE Young Professionals, IEEE Software Defined Networks, IEEE Communications, IEEE Signal Processing, IEEE Vehicular Technology. Finally, He is also a member of CNIT (Italian Inter-Universities Consortium for Telecommunications). He is the Chair of the IEEE 1900.1 WG on dynamic spectrum access, the Chair of the Int. Workshop on Signal Processing fo Secure Communciations (SP4SC), and the co-Chair of the WP 3.5 on signal processing for ground penetrating radar of the European Cost Action YU1208.


SD-WAN Strategy to Address Key Trends and Scalability

Fan Gu, VeloCloud Networks, Inc.

IEEE Softwarization, September 2017


A Software Defined Wide Area Network (SD-WAN) applies SDN architectural principles to a WAN network, with innovative extensions to focus on the practical realities of the “wide area” part of the network, such as minimizing delays over long distances between geographically dispersed nodes and guaranteeing predictable service quality over dissimilar and unpredictable links.

WAN Trends

The accelerating digital business transformation has rendered legacy WAN architectures suboptimal, and industry analysts have recently distilled several key trends that WAN architectural strategy must address.

  • The Cloud is The Network: An estimated 30-50% of large Enterprise traffic is shifting to the cloud to achieve easy and global any-to-any connectivity, radically disrupting traditional remote-office-to-data-center traffic flows.
  • Enterprise Applications Move to the Cloud: Analysts project that by 2030 80% of new applications will be deployed in the cloud, demanding that traffic and bandwidth planning must increasingly optimize cloud application access.
  • Bandwidth Requirements Rise: An explosion of IoT devices, applications moving from local to cloud hosting, and ever-increasing video and content services have become part of the daily application diet of branch office users.
  • Infrastructure Refresh is Coming: The pace of change in technology and traffic is accelerating, while costs and budgets remain limited or decline. Virtual and software-delivered services will allow enterprises to keep pace.
  • Bring Your Own Link: Bandwidth increases to support IoT and cloud applications require the use of flexible, cost-effective, easily available and easily upgradable aggregate access link strategies.
  • Security is Top-of-Mind: User mobility, BYOD, IoT devices, and increased use of Internet links to access cloud applications as an aggregate will increase the pressure on network security, while hackers and fraudulent events become ever more sophisticated and widespread.

A cloud-delivered SD-WAN architecture addresses these trends effectively through architectural components and key features:

  • Transport Independent: SD-WAN creates an overlay network connecting all enterprise branches via IPSec tunnels, regardless type and number of WAN links at the branches. For example, a branch can deploy MPLS private link, Internet link and LTE at the same time, and SD-WAN is able to aggregate all the link bandwidth to increase the total throughput for the branch.
  • Application Abstraction: SD-WAN integrates with deep packet recognition mechanisms and recognizes 2,500+ applications. Quality of Service (QoS) policies, network services and firewall rules can be customized and applied based on granular applications.
  • Dynamic Multi-Path Optimization (DMPO): SD-WAN delivers a resilient overlay network by taking into account real-time performance of WAN links - each physical link is monitored at the branches dynamically and scored based on link conditions, such as jitter, packet loss, delay, etc. Applications packets will be steered dynamically based on business priority and link conditions. In addition, in scenarios where it may not be possible to steer the traffic flow onto the better link, i.e., single link deployment, or multiple links having issues at the same time, error correction will be applied for the duration of the disruption.
  • Unified and Automated VPN: A Cloud-Delivered SD-WAN offers globally distributed cloud gateways which reside at the door steps of the major SaaS/IaaS/PaaS providers to provide an accelerated access for enterprise branches to the cloud. This simplifies overall deployments and configurations, as instead of creating a full mesh between branches and cloud providers, with cloud gateways, only one tunnel needs to be created from cloud gateways to each cloud provider which will be shared by all the branches. In addition, it reduces the network load for the regional hub by eliminating the backhaul traffic.
  • Flexible Service Insertion: SD-WAN normally has a built-in stateful firewall to meet requirements of smaller branches. Additional security can be achieved by service insertion via stitching UTM, Anti-Virus, URL filtering functions as VNF on the branch, or steering towards the cloud providers of choice.
  • Zero Touch Deployment: SD-WAN provides Zero Touch Deployment to simplify the deployment rollout and reduce IT costs. When branch edges are shipped to branches and connected to power/Internet, the branch edge receives IP address via DHCP and automatically calls home to the SD-WAN management plane in the cloud to receive configurations and start forwarding traffic.  
  • All-In-One Management: SD-WAN offers a single pane of glass management portal, which centralizes all the configurations, monitoring and troubleshooting for the entire SD-WAN network.

SD-WAN Scalability Requirements and how SD-WAN can address them

Large networks—generally classified as organizations comprised of more than 10,000 sites—exacerbate the challenges of smaller networks. Cloud-delivered SD-WAN architecture, technology and features are also uniquely able to satisfy the requirements of scale.

  • Thousands of sites: Everything becomes massive and complex when multiplied by thousands. SD-WAN delivers automation, centralized control with visual dashboards, auto-discovery and zero-touch procedures.
  • Variety of transports: A plethora of carriers, technologies, costs, contracts, and inscrutable routing increases network complexity. SD-WAN technology offers a transport-independent overlay with flawless, enterprise-grade quality of experience (QoE) delivered by continuous link monitoring, bandwidth measurement and discovery, per-packet steering around outages, and automatic link remediation.
  • Many Data Centers including the cloud: Complex management becomes the norm in an environment of multiple legacy and cloud data centers, security, traffic backhauling, and a tangle of regulatory demands. SD-WAN technology provides virtualized, scalable, auto-load-balanced hub clusters for the data center access over any link type, hosted gateways to SaaS/IaaS, hub-less designs for legacy data centers, and multi-source inbound QoS.
  • Legacy sites and equipment: Varying equipment profiles, significant prior investment, and long-term carrier contracts. SD-WAN technology offers an overlay for new traffic and services, flexible last-mile/access into the private mid-mile network, and multi-link, multi-transport integration.
  • Services delivery: Increasing cloud-based services, complex service deployment, policy coordination, and service delivery to branches. SD-WAN technology delivers simplified, distributed security insertion, on virtualized, scalable platforms, easy integration, and guaranteed performance with cloud-based services.
  • Scalable security: Segmentation, VPN meshes, complexity to secure IaaS integration. SD-WAN technology delivers the scalability and security of PKI, with the ease of centralized, integrated orchestration, an integrated CA, dynamic and automatic VPN tunnels including branch-to-branch, enterprise-scale network segmentation, multi-tenancy, and service chain firewalling.
  • Global locations: Varying levels of transport quality and reliability per region, limited regional IT support, region-specific regulations and compliance requirements, and diverse cloud sources. SD-WAN technology delivers a hybrid “regional WAN” topology, flexibility in service insertion, “regionalized” cloud access, and coordination of policies.

In summary, a cloud-delivered SD-WAN is a practical, compelling, cost-effective technology for enterprises and service providers—based on standards-based software defined networking (SDN) concepts—to replace or augment customer edge equipment at remote sites, integrate new network services, virtualize services, load-share over multiple links of any type, provide dramatically simplified configuration and policy management, and optimize real-time application performance.



Fan GuFan Gu is a Product Manager at VeloCloud Networks, Inc., leading the design of key technologies and architecture of the Cloud-Delivered Software-Defined WAN solution for Service Providers and Enterprises. Before joining VeloCloud, Fan designed and implemented cutting edge technologies at Cisco Systems, Inc. in the Data Center, Cloud, Collaboration and Mobility groups. Fan holds two Cisco Certified Internet Expert (CCIE) for Routing & Switching and Service Provider. Fan has a Masters Degree in ECE from Cornell University.



Elio SalvadoriDr. Elio Salvadori is the Director of CREATE-NET Research Center within Fondazione Bruno Kessler (FBK); he is responsible for managing, organizing, executing and monitoring of the activities of the Center.

He joined CREATE-NET in 2005 and since then he has served different roles within the organization: from 2007 to 2012 he has been leading the Engineering and Fast Prototyping (ENGINE) area. From 2012 to 2014 he has been acting as SDN Senior Advisor while holding a position as CEO in Trentino NGN Srl. He then moved fully back to CREATE-NET acting as Research Director and then as Managing Director until the incorporation within FBK at the end of 2016.

Prior to CREATE-NET, Dr. Salvadori has developed a mixed industrial and academical background: he graduated in 1997 at Politecnico di Milano through an internship pursued at CoreCom, a research lab funded by Politecnico and Pirelli Optical Systems (now Cisco Photonics). Afterward he has worked as systems engineer at Nokia Networks in Milan and then at Lucent Technologies in Rome. In 2001 he won a research grant at the University of Trento to pursue his PhD on Information and Communication Technologies. He received his PhD degree in March 2005 with a thesis on traffic engineering for optical networks.

During his research career, he has been involved in several national and European projects on SDN and optical networking technologies as well as on Future Internet testbeds.

His current research interests include software-defined networking (network virtualization and distributed controller architectures), Network Functions Virtualization (NFV) and next generation transport networks. He has published in more than 100 International refereed journals and conferences. He is a member of IEEE and ACM.


Intent-Based Management and Orchestration of Heterogeneous OpenFlow/IoT SDN Domains

Walter Cerroni, Chiara Buratti, Simone Cerboni, Gianluca Davoli, Chiara Contoli, Francesco Foresta, Franco Callegati, and Roberto Verdone, DEI - University of Bologna, Italy

IEEE Softwarization, September 2017


The recent innovations brought about by network “softwarization” paradigms, such as Network Function Virtualization (NFV) and Software Defined Networking (SDN), foster flexible and cost-effective service provisioning by taking advantage of vendor-independent hardware platforms as well as fully programmable network infrastructures via standardized, open, southbound interfaces (SBIs). End-to-end services provided to customers are typically delivered across different network administrative and/or technological domains, making it a challenging task and, at the same time, an opportunity when SDN/NFV solutions are adopted, because of the more advanced control features offered by such new paradigms. In particular, a very critical aspect to be dealt with is how to achieve unified management and orchestration of end-to-end services across multiple domains. To this purpose, an open, vendor-agnostic, and interoperable northbound interface (NBI) should be defined, through which applications are allowed to control the underlying heterogeneous NFV and SDN infrastructures and take advantage of dynamic service chaining.

Although a standard NBI definition is not available yet, a commonly accepted approach is to adopt a so-called “intent-based” interface that allows to declare high-level service policies rather than specify detailed networking mechanisms. In fact, the powerful abstraction level offered by an intent-based NBI would allow to specify end-to-end service composition policies by taking advantage of some kind of formalism that is close to the customer’s natural language. We believe that this approach is one of the best candidate solutions to solve the issue of management and orchestration of heterogeneous SDN/NFV domains.

In  our paper presented at NetSoft 2017 [NetSoft 2017], we first introduce a reference network architecture suitable for orchestrating end-to-end service chains deployed across heterogeneous SDN/NFV domains. Then, we define a related high-level, vendor-agnostic, intent-based NBI. We demonstrate the feasibility of the proposed approach through proof-of-concept implementation and experimental validation, considering the use case of an Internet of Things (IoT) infrastructure deployment and the corresponding cloud-based data collection, processing, and publishing services with quality of service (QoS) differentiation.

The reference multi-domain SDN/NFV architecture considered in this paper is shown in Fig. 1, including a software-defined IoT domain and a wired SDN infrastructure to reach a cloud computing domain. Data collected from sensors and actuator devices installed in the IoT domain are dispatched across the SDN domain toward a set of suitable consumers, implemented by means of virtual network functions (VNFs) and deployed within the cloud domain. Although the reference architecture in Fig. 1 is specialized for the use case assumed here, our approach to intent-based orchestration could be generalized to any SDN/NFV technology domain.. Considering the nature of the end-to-end service orchestration features we are interested in, our reference architecture is inspired by the ETSI NFV specifications, with particular reference to the Management and Orchestration (MANO) framework. The rationale behind this choice is that, on one hand, the proposed architecture has the advantage of being consistent with the most relevant NFV standard initiative to date; on the other hand, the architecture itself can be seamlessly extended to include any further SDN/NFV domain and technology as part of the underlying virtualized infrastructure.

Figure 1

Figure 1. Reference multi-domain SDN/NFV architecture, specialized for the use case of IoT data collection and related cloud-based consumption.

Each SDN/NFV domain in Fig. 1 consists of a technology-specific infrastructure, including:

  • data plane components, such as IoT nodes and gateways, SDN switches, virtual machines running in cloud computing nodes, physical and virtual interconnecting links; these components provide the network, compute, and storage resources to be orchestrated;
  • control plane components, such as SDN and cloud controllers with related data stores and interfaces; these components are responsible for proper VNF deployment and traffic steering across VNFs and domains;
  • management plane components, such as Virtualized Infrastructure Managers (VIMs) specialized for managing resources in the IoT-based SDN infrastructure, the wired SDN infrastructure, and the cloud infrastructure; based on the available implementations, some of these components could be in charge of multiple domains, as in the case of the SDN/cloud VIM in Fig. 1.

The overarching VNF Manager (VNFM) and NFV Orchestrator (NFVO) components are responsible for consistently programming the underlying SDN/NFV domains by means of the proposed intent-based NBI. While technology- and domain-specific NBIs and SBIs are used inside each domain to efficiently control and manage the relevant components, the design of the overarching VNFM and NFVO should be as technology-agnostic as possible, so that a service chain to be deployed can be specified by a customer using a high-level, intent-based description of the service itself. This would also allow the proposed architecture to be more general and capable of being extended to different SDN technologies and domains.

To reach this goal, each domain is required to expose general abstractions and capabilities according to the reference NBI, and map them into technology-specific resources and control mechanisms. We argue that the act of decoupling service abstractions from the underlying technology should be performed mainly by the VIM, as we consider it the most appropriate component where high-level management and domain-specific control can co-exist. Therefore, we extend the concept of interactions based on vendor-agnostic intents to the NBI offered by the VIM. This approach could also allow different administrative domains to expose only service abstractions via the VIM, without disclosing sensitive details related to the underlying infrastructures.

Figure 2

Figure 2. The NFV/SDN test bed setup developed to demonstrate multi-domain SDN/NFV management and orchestration. Information flow in the management and control planes is displayed in blue. Information flow in the data plane is displayed in red.

As a demonstration of the feasibility of the multi-domain SDN/NFV management and orchestration solution proposed here, we developed a test bed to implement the reference architecture illustrated in Fig. 1 of the cloud-based IoT data collection service with quality differentiation. Both IoT and cloud network infrastructures are based on specific SDN solutions. The former adopts a centralized path computation mechanism that allows to program the forwarding functions of each IoT device, whereas the latter is based on OpenFlow-capable switches controlled by the ONOS framework. The complete test bed setup is shown in Fig. 2.

The customer on the top-right corner requests the service to the high-level management and orchestration functions, specifying the desired QoS feature. The orchestrator then forwards the request to the VIM REST NBIs of the relevant domains, according to the JSON format specified in our paper [NetSoft 2017]. Each VIM performs the operations required in the respective domain and programs the underlying controllers according to the requested service and QoS feature. Data generated by the IoT devices are sent by the relevant gateway via HTTP POST to the collecting/processing/publishing server in the cloud, where the customer can retrieve it.

The latency values measured at both data and control/management planes allowed us to get a first insight to the performance levels of the overall system, resulting in reasonable response times for service setup and QoS requirement satisfaction. Scalability tests on the ONOS-based VIM also gave promising results. The use case reported here represents a working example of a more general approach to properly define high-level interfaces and develop the related control and management components to unify orchestration capabilities across multiple SDN/NFV domains.

Further details on the proposed NBI, test bed setup, and results of the experimental validation can be found on our NetSoft 2017 paper [NetSoft 2017].


[NetSoft 2017] W. Cerroni, C. Buratti, S. Cerboni, G. Davoli, C. Contoli, F. Foresta, F. Callegati, R. Verdone, “Intent-Based Management and Orchestration of Heterogeneous OpenFlow/IoT SDN Domains,” Proc. of 3rd IEEE Conference on Network Softwarization (NetSoft 2017), Bologna, Italy, July 2017.



Walter CerroniWalter Cerroni ( is an assistant professor of communication networks at the University of Bologna. His most recent research interests include design, implementation, and performance evaluation of virtual network function chaining in cloud computing platforms (e.g. OpenStack); modeling and design of inter- and intra-data center interconnection networks for cloud computing infrastructures; design of programmable, software-defined hybrid optical network architectures; and performance evaluation of dynamic spectrum allocation techniques in flexible optical networks.


Chiara BurattiChiara Buratti ( received the M.Sc. degree in telecommunication engineering and the Ph.D. degree from the University of Bologna in 2003 and 2009, respectively. Since 2011, she has been an Assistant Professor with the University of Bologna. She has coauthored over 80 technical papers. Her research interests are on wireless sensor networks and Internet of Things, with particular attention to MAC and routing protocols. She collaborated in many European projects, and she has been responsible for the Bologna site of the EuWIn platform developed within the NoE Newcom# and the Co-Chair of the EWG-Internet of Things of the Cost Action IRACON.


Simone Marco CerboniSimone Marco Cerboni ( received his bachelor degree in Electronics and Computer Science Engineering from University of Perugia, Italy, in 2014. In 2016, he received his M.Sc. degree in Telecommunications Engineering from University of Bologna, Italy, with a thesis about software defined networking applied on IoT networks (SWIoT).




Gianluca DavoliGianluca Davoli ( received his M.Sc. Degree in Telecommunications Engineering from the University of Bologna in April 2017, with a thesis on “Intent-based approach to virtualized infrastructure management in SDN/NFV deployments,” focused on the development of a QoS-enabled northbound interface for the SDN controller ONOS. He currently works as Research Fellow at the same University, as part of the regional project SACHER, on the control and management of Software Defined Networks on Cloud Computing platforms. His main field of interest is dynamic Service Function Chaining in SDN/NFV environments.


Chiara ContoliChiara Contoli ( graduated in Computer Engineering from the University of Bologna, Italy in 2013. In the same year she was research scientist at the University of California at Los Angeles, where she worked on Content Delivery Networks for automotive applications. In 2016, she was a visiting scholar at Saint Louis University, where she worked on network architecture and protocols design. She received the PhD degree in Electronic, Telecommunications and Information Technologies from the University of Bologna in 2017, where she is currently a post-doctoral researcher. Her research interests are in programmable networks, SDN, NFV and more generally on advanced networking architectures and protocols.


Francesco ForestaFrancesco Foresta ( is a graduating Master Student in Telecommunications Engineering at the University of Bologna, Italy, where he also got his Bachelor Degree in Electronics, Computer Science and Telecommunications Engineering in 2015. Since November 2014 he has been working at the University of Bologna performing research on SDN-based cloud computing solutions. In 2017, he was an Intern at Huawei in Shenzhen, China and was awarded with the Certificate of Honor as one of the Top 10 Italian graduating students in the IT area. His current research interest is in the integration among SDN frameworks and cloud computing platforms, in particular for orchestration purposes.


Franco CallegatiFranco Callegati ( is an associate professor of telecommunication networks at the University of Bologna, Italy. His research interests are in the field of teletraffic modeling and performance evaluation of telecommunication networks. He is currently working on performance evaluation and experimental validation of SDN/NFV-based networking solutions. He has been active in EU-funded research projects since FP4, where he led activities and participated in various steering committees.


Roberto VerdoneRoberto Verdone ( received the M.Sc. degree in electronics engineering and the Ph.D. degree from the University of Bologna in 1991 and 1995, respectively. Since 2001, he has been a Full Professor of telecommunications with the University of Bologna. He has authored or coauthored over 100 research papers, mostly in IEEE journals or conferences. His research activity is concerned with both infrastructure-based radio networks and infrastructureless radio networks. Main topics investigated in the last ten years are radio resource management for cellular systems, and MAC, routing, and topology aspects of wireless sensor networks.



Shashikant PatilShashikant Shantilal Patil is a prominent educationist and Teacher. He is a renowned Engineer, researcher and scientist. He has received numerous accolades for his valuable contributions and achievements in education and research. Prof. Patil graduated Electronics Engineering from North Maharashtra University in 1997 and joined as a Lecturer in Government Polytechnic Mumbai in 1999. After completing his Masters in from Dr Babasaheb Ambedkar Technological University Lonere, he joined NMIMS and later on appointed as an Associate Professor and Head of the Department. He is currently serving as an Associate Editor, Editorial Board Member, Technical Advisory Board Member, Potential Peer Reviewer and Journal Referee on at least 50 Journals. He is also having an association with Elsevier Editorial Series, Taylor and Francis, SpringerLink Journals as a potential Peer Reviewer and Journal Referee. He is also associated with IEEE, ACM, CSI, ISTE, NHRDN, E4C and IETE as Professional member and nominated as an affiliate member on various committees of IEEE SPS and ComSoc.  He has participated in 36 Teacher Training Programs/ Refresher courses like STTPs/ CEPs/QIPs/Conferences / Workshops in IITs and reputed institutes. A stickler for quality, team builder to the core and a natural motivator with perseverance and integrity. Commands excellent communication skills that have been honed through interacting with people at various levels. He is recipient of Best Researcher Award 2014 of SVKMs NMIMS Shirpur. In addition to this he had been nominated as IEEE Day 2015 Section Ambassador for region 10. Recently has been selected as a Member Executive Committee on IEEE CSI India Council as well as Core Team Member of Social Media and Online Content Management Team, Visibility Committee of IEEE SPS Society at International Level. He has published around 31 articles in various conferences and journals at National and International level. This year he has been selected as Regional Lead Ambassador for region 10 for IEEE Day 2015 event. He is also heading SVKMs NMIMS Bosch Centre of Excellence in Automation Technologies Shirpur Campus. He is member IEEE RFID Technical Council and SIG Member of IOT. His research interests are Signal Processing and Imaging. He is also heading SVKMs NMIMS Bosch Centre of Excellence in Automation Technologies Shirpur Campus. He is member IEEE RFID Technical Council and SIG Member of IOT. His research interests are Signal Processing and Imaging. He is also serving as an Associate Editor on IEEE RFID Journal; IEEE SDN Journal; IEEE RFID Steering Committee.