SDN and Virtualization-Based LTE Mobile Network Architectures: A Comprehensive Survey

Proposed by China Mobile [40] in 2011, the C-RAN concept spread widely in recent years as the hottest topic in the radio access part of mobile networks. Unlike the classical distributed base station system, in which a radio remote head (RRH) entity and baseband unit (BBU) entity are tightly coupled, C-RAN represents a system of distant RRH entities connected using high bandwidth front-haul links to a single centralized BBUs pool on a cloud computing system. The radio signal from/to a particular RRH can be processed by a virtual base station, which is part of the processing capacity allocated from the physical BBU pool by the virtualization technology. On the other hand, the resource for an individual RRH is dynamically and flexibly allocated. For efficient radio resource management in a multi-cells environment, C-RAN adopts the multi-cell joint radio resource management and cooperative multi-point transmission schemes. After the C-RAN concept was proposed, Hadzialic et al. [41] focused on known techniques to realize this concept. Checko et al. [42] made a survey that covers the state-of-the-art literature on C-RAN in the mobile network. This technology overview makes it easy for anyone who wants to understand the fundamentals of C-RAN and engage in research activities on C-RAN. The CONCERT [43] proposed a more flexible solution than the C-RAN in which the baseband resources can be virtualized in a hierarchical manner with three levels: local, regional and central resource pools. In addition, the front-haul network of CONCERT architecture is SDN network.

Unlike C-RAN and CONCERT, the authors in [44, 45] proposed RANaaS, a general radio resource virtualization solution, when considering the trade-off between the full centralization and decentralization. It means RANaaS partially centralizes RAN’s functionalities depending on the actual needs as well as network states.

Yang et al. [46] proposed OpenRAN, which is the integration of the C-RAN and SDN concepts. By doing so, the RAN becomes open, controllable, and flexible. OpenRAN contains three main parts: a wireless spectrum resource pool (WSRP), cloud computing resource pool (CCRP) and an SDN controller. The WSRP is composed of multiple physical remote radio units (pRRUs) to enable several virtual RRU (vRRU) to coexist in one shared pRRU via virtualization technology. The SDN controller plays a role of creating and dynamically optimizing vRRUs according to the requirements. It enables fair allocation and virtualization of radio spectrum, computing and storage resources to virtual access elements in heterogeneous RANs.

In summary, radio resource management with the concept of resource virtualization is mostly related to the migration of several RAN functions into a cloud computing system.

Unlike the resource virtualization, SoftRAN [47], PRAN [48] and V-Cell [49] introduce another new concept to tackle radio resource management, called resource abstraction. SoftRAN [47] proposed to rethink the radio access layer of current LTE infrastructure and focused on the control plane design by abstracting all the physical base stations (not only RRU) in a local geographical area into a virtual big base station. As a result, these physical base stations become simpler radio elements with minimal control logic and are controlled by a logically centralized controller. In SoftRAN, the radio resources are abstracted out as three-dimensional grids (3D grid) of time, frequency, and base station index or radio element index. Inside the controller of SoftRAN, there is a RAN information base (RIB) which is the core element of SoftRAN. The RIB consists of essential information to be updated by the controller including an interference map, flow records and network operator preferences. It is maintained by the controller and is accessed by the various control modules for radio resource management. PRAN [48] is an extension of SoftRAN which provides mechanism to dynamically reconfigure L1/L2 data plane.

While SoftRAN and PRAN focus on the abstraction of base stations and do not support multi access technology (Multi-RAT), V-Cell [49] targets cell abstraction with the ability to support multi-RAT and heterogeneous cells (macro, Pico, and femto). These cells are abstracted as a single big macro cell, and the radio resources for them are considered as a single pool of resources that is managed by a logically centralized software defined network controller (SD-RAN controller). The radio resources in V-Cell are abstracted out in a resource pool through a 3-dimensional matrix including time, frequency and space. The main role of the SD-RAN controller is to allocate radio resources, management limited spectrum, interference and power allocation and balance load across the entire pool of physical cells inside the V-Cell. In summary, the object of two approaches is to abstract the radio resources and manage them by using an SDN controller in a central manner.

In order to share radio resources among different mobile operators, one slicing technique was introduced in [50]. RadioVisor [50] extends the FlowVisor concept to allow each controller to access a slice of the radio access infrastructure, in particular SoftRAN architecture [47]. RadioVisor enables traffic to be steered to and from the controllers of virtual operators. It isolates radio resources, control channel messages, and CPU resources among various virtual operators. RadioVisor architecture is composed of a device and application to slice mapping, the radio resource allocation and isolation function, and slice manager. The first component is the traffic to slice mapping at RadioVisor and radio elements. The second component performs a heuristic algorithm to allocate the resource to slices in a fairness manner according to resource requests and the service agreements. The last component is in charge of slice configuration, creation, modification, deletion and multi-slice operations. It interacts with each slice through an API provided by RadioVisor. Each slice is defined based on operator, device, subscriber, and application attributes.

While RadioVisor presented a general concept for creating radio access network slices for different mobile operators, Spapis et al. [51] introduced a complete functional architecture to only share the spectrum resources among mobile network operators. Depending on the needs as identified by their operations, administration, maintenance (OAM) modules, the spectrum resources will be allocated from a central spectrum pool to eNBs in the RAN through RRM commands. In addition, the authors also presented a potential implementation model based on the combination of SoftRAN architecture [47] and MobileFlow architecture [75].

Another approach for resource sharing was proposed in [52, 53], which create virtual base stations from the shared physical base stations of multiple network operators. Zaki et al. [53] proposed a sharing solution based on the virtualization of eNodeB in the LTE access network. A key component is called Hypervisor, which is located on top of the physical eNodeB resources and is in charge of allocating these resources to each virtual eNodeB (VeNB) according to the request of different MVNOs. Costanzo et al. [52] presented OpeNB, which is also based on the virtualization of eNodeB in the LTE access network. However, the OpeNB architecture is more flexible by leveraging SDN and Openflow technologies. In OpeNB, the virtualization of eNodeB can be handled dynamically based on network state and some predefined agreements among various operators. It enables an operator to hire on-demand the physical infrastructure and resources owned by other operators. The OpeNB architecture consists of two types of physical elements: NAeNBs, OpeNBs, and two types of software entities: a main controller (MC) and OpeNB controller (OC). NAeNBs are NV aware eNodeBs, which can forward the NV signaling from the MC toward an OpeNB. OpeNBs are eNodeBs that are controlled by the MC and have the ability to create VeNBs. OpeNB sharing between multiple operators is done by NV procedure triggered from the MC. The OC located inside an OpeNB is responsible for triggering VeNBs upon the request from the MC. These works are summarized in Table 1.

Mobile traffic offloading refers to the movement of data traffic from a mobile network to a Wi-Fi network. In a mobile network, the traffic offloading is done by an access network discovery and selection function (ANDSF). This entity is used for discovering wireless networks close to the mobile user and then performing the Wi-Fi offload. In [2], the author said that the mobile traffic offloading can be done by SDN since the SDN controller can dynamically control the traffic in a mobile network based on various trigger criteria including individual flow rate, aggregate flow rate, application type, available bandwidth, etc. In [54], the authors introduced a new architecture for offloading data traffic from a mobile cellular network to a Wi-Fi network by converting network resource management (NRM) and RRM functions to software modules running on an SDN controller. The RRM application is responsible for collecting radio access network conditions such as traffic load or cell capacity while NRM (integrated PCRF) stores the subscriber and application information. In this architecture, the SDN controller is in charge of composing information of these two modules and creates a single set of policies and rules which are then installed to the local control agents in the network gateway and the RAN. This architecture enables the SDN controller to gather the real-time network condition and then decide suitable offloading policies.

Consider the case where one base station is overloaded with many clients while a nearby base station is free of serving any client. Due to the nature of the distributed control plane in the traditional RAN network, there is no mechanism to balance the traffic load between two such base stations. In [47], the authors proved that the load balancing can be facilitated by using the SDN controller, which has the global view of the entire network and workload. Indeed, the SDN controller will trigger the handover of edge users to balance the load between one base station and its neighbors.

M2M [55] and D2D [56] are two new communication types in mobile networks. The M2M and D2D over mobile cellular network refer to the communication between two mobile nodes without traversing to the base station or mobile core network. Instead, these devices often communicate with each other through a M2M or D2D gateway. The authors in [57] proposed a framework that combines the SDN-based cellular mobile network with M2 M. The main purpose of this paper is to flexibly reconfigure the cellular network based on the monitoring information received from M2M devices. The M2M sensing devices monitor the surrounding area of eNodeBs and send the sensing data to the M2M server via the IP backbone network. The M2M server will alert the SDN control software to reconfigure the network assessments and resource allocation to avoid a disaster in the network. In order to control the congestion exposed by the M2M communication in the LTE network, the authors in [58] proposed congestion control methods based on SDN and Openflow. To verify this method, the authors deployed a test-bed framework using NetFPGA and Openflow platform.

Philip [60] proposed Openflow-based backhaul network architecture which allows one operator to share its backhaul resources with others. This solution provides mobile operators with backup links in cases of link congestion or heavy traffic condition. Thus, mobile operators can achieve better resource utilization within their own backhaul network.

In order to improve the mobility management efficiency in cases of inter-eNodeB handovers, the authors in [62] proposed SDMA, a semi-distributed mobility anchoring in LTE backhaul access network based on Openflow and SDN technologies. In this architecture, all backhaul access nodes are realized as Openflow switches and controlled by Openflow Controllers via Openflow protocol. Furthermore, the concept of service VLAN (S-VLAN) id and customer VLAN (C-VLAN) id is used to separate the traffic of the users under different Openflow controllers. Then a detail of handover procedure including initial attach, handover under the same controller or different controllers was defined. Unlike [62], the authors in [63] tried to fully realize the concept of SDN into the entire mobile backhaul network. They introduced a distributed SDN control plane. The management plane, including MME, HSS, PCRF, and billing system, is implemented within VMs that can communicate with SDN controllers. As a case study of mobility management, the authors indicated that the new architecture reduces not only the power consumption of the UE but also the signaling message overhead between entities at the backhaul side.

The authors in [64] considered IP-based routing in virtualization-based LTE EPC architecture (vEPC). In this architecture, the control plane and user plane of EPC entities also are decoupled from each other. Two new entities, namely the EPC edge router (EPC-E) and core router (RTR), were introduced. EPC-E is a router which locates at the same place as the SGW and terminates GTP tunnel between RAN and the core part. It maintains routing information of every UE that is notified by the control plane. RTRs are regular IP routers that are configured from the vEPC’s control plane by a routing protocol like BGP. In other words, BGP is used as protocol for updating the routing in formation in EPC-E and RTR from vEPC’s control plane as well as for routing between EPC-E and RTR in the data or user plane.

Li et al. [65] proposed SoftCell, which aims at designing a revolutionary architecture for mobile networks to support numerous fine-grained policies in a scalable manner. The SoftCell architecture is composed of commodity switches, which are simpler and cheaper than specialized network elements (SGW, PGW) and just perform packet forwarding, and relegate complicated packet processing to middleboxes; a set of middleboxes, which act as transcoders, web caches or firewall; access switches, which classify fine-grained packets on traffic from UEs; and a central controller, which is responsible for computing and installing switch-level rules based on subscriber attributes and application types. In order to deal with the challenges of data explosion in the data plane or the scalability problem in the flow table, the authors proposed the use of multi-dimensional aggregation and tag-based routing. In particular, the forwarding rules in SoftCell are aggregated on three dimensions: policy, location ID, and UE ID. For example, the policy tag allows for aggregating flows that share a common policy. CellSDN [66], the prior work of SoftCell, leverages SDN into both access and core networks. In this work, the author mainly focused on describing use cases that can benefit from CellSDN, such as network control and billing monitoring, seamless subscriber mobility, and remote control of the base station. The routing mechanism is the same as SoftCell by using tag-based routing. Moradi et al. [67, 68] proposed SoftMoW to address the challenges in a very large cellular network or mobile WAN. The challenges derive from suboptimal routing, lack of support for seamless inter-region mobility, scalability, reliability, and the rise of new applications (e.g., M2M, IoT). SoftMoW is composed of distributed programmable switches and middleboxes instead of expensive and inflexible gateways (SGW, PGW). SoftMoW is constructed in a hierarchical control plane for the core and radio access networks with L levels. The physical data plane is divided into several logical regions, each of which is controlled by a leaf controller. Leaf controllers abstract their topologies and expose logical components to the next level, including a gigantic switch (G-switch), an abstraction of all physical switches; a gigantic base station (G-BS), an abstraction of a group of physical base stations; and a gigantic middlebox (G-Middlebox). As a consequence, the entire network is controlled by a highest-level parent controller at the root region. The routing mechanism in SoftMoW is also performed by an alternative method of tag-based routing called label-based routing. The parent controller pushes a global label into each traffic group while the child controllers perform label swapping at ingress and egress switches. Openflow protocol is assumed as the southbound interfaces in CellSDN and SoftCell as well as SoftMoW architecture.

In [70, 71], the authors proposed CROWD, an SDN-based solution for dense heterogeneous wireless networks. The main target of this solution is to deal with various challenges in dense heterogeneous wireless network in terms of mobility management, interference management, and energy consumption. The CROWD architecture consists of two-tier SDN controller hierarchy with two types of controllers: a local controller (CLC) and regional controller (CRC). The CLC requires data from the network at a more granular time scale while the CRC requires aggregate data from the network and takes responsibility for management of the CLCs. The data plane of CROWD architecture is composed of DMM gateways (DMM-GWs), which are interconnected using an Openflow-based transport network. Therefore, the data traffic will be routed using a flow-based routing mechanism.

Trivisonno et al. [72, 73] proposed an SDN-based plastic architecture for 5G networks consisting of unified control plane and a clean-slate forwarding plane. The control plane is represented through three logical controllers: edge controller I for processing signaling messages for access nodes and installing forwarding rules into non-access nodes, edge controller II for processing signaling messages between UEs and access nodes, and an orchestration controller which is responsible for resource management and allocation of both 5G control and data plane entities. The data traffic between access and non-access nodes are routed using a flow-based routing mechanism. In addition, the authors also showed the backward compatibility with the legacy systems.

The authors in [74] also proposed an approach for LTE mobile core network relying on the concept of SDN. In this architecture, the MME entity still exists and is responsible for mobility management. The MME communicates with an Openflow controller to trigger forwarding path setup in Openflow switches, routers according to the UE’s state. The routing in the data plane is relied on flow-based routing mechanism.

Compared to the above approaches, the GTP-based routing approach is the most popular solution for routing user data packets in SDN and virtualization-based mobile core networks. This approach refers to the evolution of mobile core networks where the tunnel between core network entities is still kept and the tunnel setup is facilitated by the use of an SDN controller. MobileFlow [75] proposed a software-defined mobile network (SDMN) architecture. In MobileFlow, the control and data plane are also decoupled from each other. Two main components of MobileFlow are the MobileFlow forwarding engine (MFFE) and MobileFlow controller (MFC). MFFEs are interconnected by an underlying Openflow-based transportation network. MFFEs must support carrier-grade functionality, such as tunnel processing and charging. The MFC has some necessary functions for managing the entire network, such as topology discovery, network resource monitoring or network resource virtualization. In addition, the MFC consists of function blocks for tunnel processing, mobility anchoring, routing and charging. The mobile network applications, including the control functions of all current EPC entities (e.g., eNB-C, SGW-C, PGW-C, MME, etc.) are implemented on top of the MFC. The MFC computes and sets up GTP tunnels into MFFEs by using a lightweight protocol called Smf.

Several proposals [76‐80] leverage the SDN concept into mobile core gateways. In [76], the authors made an analysis of all mobile core gateways’ functions and then mapped them into four alternative deployment frameworks based on SDN and Openflow including full cloud migration, control-plane cloud migration, signaling control cloud migration and scenario-based cloud migration. The authors clearly presented the pros and cons of each deployment decision. In addition, several SDN frameworks for GTP tunnel processing and charging control function are also proposed. Next, in [77] these authors continue their work in [76] by addressing the function placement problem. In this work, the authors grouped four deployment models in [76] into two main categories: a virtualized gateway (NFV) and decomposed gateway (SDN). The first category refers to fully virtualizing SGW and PGW into a data center, and an off-the-shelf network element (NE) is used to direct the data traffic from the transport network to the data center. The second category refers to decomposing gateway functions, meaning that only the control plane function is shifted to the data center and integrated with SDN controllers while the data plane is processed by enhanced SDN network elements (NE+). To find the most optimal deployment solution, the authors formed a model by taking the control-plane load and data-plane latency into account, and then tried to minimize these parameters. By doing so, the operators will have a tool to make their own deployment decision: virtualizing all gateways or decomposing all gateways or a combination of two. As an extension of the work in [77, 78] proposed power saving models to maximize power savings by adapting the datacenter operation according to the time-varying traffic patterns and datacenter resources. The authors in [79, 80] similarly adopted SDN and NFV into EPC S/PGWs. In these works, the control function of an S/P integrated gateway (S/PGW) is decoupled from the user plane. While virtualized S/PGW control is realized as VMs in a cloud computing system, S/PGW user plane can be realized either by VM or dedicated hardware. The dedicated hardware is located possibly close to the access network and is responsible to fast path processing. Another network function implemented in VM in cloud is router functionality. It is used to run routing protocol and advertise UE IP prefixes via the SGi interface. The last element is the SDN controller, which is responsible for allocating UE IP addresses and GTP TEIDs and installing UE specific flow entries to the switch during an attachment procedure and modifies them during a handover. The main objective of this work is to dynamically switch the GTP termination point of an active session between the cloud and fast path in dedicated devices.

Regarding the implementation aspect, several efforts have been made to design appropriate protocols for software defined mobile networks [81‐84]. Considered the first approach that adopted the SDN and Openflow concept into the LTE EPC environment, the authors in [81‐83] introduced an evolution of mobile core network architecture based SDN and Openflow, which allows the entire control plane to be moved into a data center. In these works, the authors mainly focused on enhancements of Openflow 1.2 for supporting the process of GTP tunnel in the cloud-based mobile core network. While [81, 82] clearly describe how to manipulate Openflow 1.2 to implement GTP TEID routing in EPC architecture, [83] takes 3G packet core network architecture into account. Alternatively, [84] presented the detail design, implementation, and evaluation of a software defined telecommunication controller (OFC), switch (OFS) and protocol (OFP) according to the latest Openflow standards [6] (i.e., Openflow version 1.4) in regard to the EPC. The software defined telecommunication network (SDTN) architecture presented in this work also relies on the separation of the control plane and user plane. The design of OFS in SDTN is done by using a table-lookup pipeline with multiple table support, virtual port for GTP/GRE matching and Openflow agent for communicating with the OFC. The control functions, such as PGW-C and SGW-C, can be deployed as higher layer network applications upon the controller.

Other approaches [85‐88] leverage Openflow into the LTE/EPC architecture with some procedure analyses. In [85, 86], the authors introduced a new control plane in 3GPP LTE/EPC architecture for supporting on-demand connectivity services such as load balancing and resiliency and then proved the reduction of signaling load by providing a procedure analysis. The architecture in these works only adopted SDN and Openflow into SGW entities. It means that only the control function in SGW is separate from the data forwarding function in SGW. The SGW control function (SGW-C) and MME function are packaged as applications running on top of the Openflow controller. Similarly, the authors in [87, 88] also made a procedure analysis in Openflow-enabled LTE/EPC architecture and evaluated in terms of signaling load. However, compared to [86, 88] proposed a solution that is fully realized in SDN and Openflow technologies. In other words, in [88], all control functions of both SGW and PGW are packaged together with MME as applications on top of the mobile controller. By doing so, the signaling load can be reduced more than that in [86]. These approaches still require the GTP processing at the data plane elements.

Instead of redesigning the mobile core network, K. Gomez et al. [89, 90] present a new distributed entity, named a flexible management entity (FME), which leverages virtualized EPC functionalities in 4G LTE architecture. The main goals of FME are to embed the most fundamental EPC operations close to the radio access network (eNB) and make coexistence possible between virtual and physical EPCs. The FME is composed of a virtual EPC, link management unit (LMU), routing management unit (RMU) and topology management unit (TMU). The virtual EPC represents all normal EPC operations: user plane processing by EPC-Agent (EPC-A) and control plane processing by MME-Agent (MME-A). In summary, the FME units (LMU, RMU, and TMU) interact in order to create and maintain the vS1 interface while FME agents (EPC-A and MME-A) create and maintain the bearers. ProCel [91] is another approach that does not modify the current EPC architecture. Instead, ProCel introduces new entities, including ProCel switches and a ProCel controller, to dynamically process the traffic whether it goes through the cellular core network or can be steered down to a fixed IP network. In the control plane, the ProCel controller computes and installs forwarding rules in ProCel switches based on policies from operator databases. In the data plane, ProCel switches perform packet classification with three categories: core flow, to be routed toward mobile core networks; non-core flow, to be steered down to fixed networks; and controller-traffic, to be forwarded to the ProCel controller. Some proposals just introduced SDN and Openflow in the transportation network [92, 93] while other parts are still kept the same as the current mobile network architecture. The routing mechanism in the EPC is still based on the GTP tunnel.

Regarding the virtualization aspect only, works in [94‐96] discuss the potential benefits of NV, NFV and cloud computing concepts in the mobile core network. The authors in [94] presented the vision of the Mobile Cloud Network project [14], an EU FP7 Large-Scale Integrating Project funded by the European Commission. This work showed a new architecture relying on the cloud computing concept for the entire mobile network. In the mobile core part, several virtualization strategies and models are proposed. Hawilo et al. [95] presented the challenges and implementation of NFV in next generation mobile networks. In this paper, the authors proposed an approach to group several vEPC entities based on their interactions, workload and functionalities to achieve less control-signaling traffic and less congestion in the data plane. There are four grouping strategies, namely segment one, segment two, segment three, and segment four. Segment one is the group of MME and HSS front-end (HSS FE), which implements all HSS function without containing a user information database. Segment two is the group of SGSN and HLR FE. Segment three is the group of PGW and SGW. And the segment four is the group of UDR, PCRF, online charging system (OCS and offline charging system (OFCS). SoftEPC [96] introduced a general purpose node (GPN), which leverages the cloud technology concept into the EPC architecture. A GPN is a core-class server which has a hypervisor to provide virtual instances of EPC entities. In this work, the authors’ object is to analyze the performance of utilizing the softEPC and to illustrate the improvement of network utilization and service delivery enhancement provided by softEPC. Since the mobile network functions, such as SGW, PGW and MME, are kept unchanged in the cloud computing system compared to the traditional mobile network, the GTP tunnels are still used for packet routing. The authors in [97] proposed a new telecom architecture by extending the concept of SDN. In this architecture, the control plane consists of MME and the control functions of SGW and PGW while the user plane is composed of SDN forwarding entities (SDN-FEs). The authors used the term “vertical forwarding” to refer to the use of GTP tunneling over an SDN forwarding domain. It means that SDN-FEs in their architecture are enable to encapsulate and decapsulate GTP header of the packet. Table 2 summaries and compares these aforementioned works on user traffic routing in SDVMN.

The current mobility management in the mobile network relies on two central anchor points—SGW and PGW. It results in non-optimal routing path, high handover latency, and a single point of failure. Nowadays, distributed mobility management (DMM) [105] is considered as a promising solution to solve these above challenges. Inspired by the benefits of DMM, several proposals [70, 93, 106‐108] tried to redesign mobile network architecture by leveraging SDN and Openflow with the support of DMM. The authors in [70] presented a DMM implementation in the CROWD architecture [71] which was discussed before, to optimize mobility management not only in WLAN networks but also in LTE networks. In this architecture, DMM-GW is the substitution of SGW and PGW and acts as the terminal’s session anchor point. The mobility management logic functions are executed by control applications, either local or remote to the CLC. For example, in the intra-handover case, the CLC is responsible for computing the required match rules and data path modifications to forward the user packet to the selected DMM-GW via the Openflow protocol. In the inter-handover, the mobility management task relies on both the CLC and the CRC. It is required to define new APIs to control the DMM-GWs at IP layer. The detailed design of this solution is described in [106]. Karimzadeh et al. [93, 107, 108] presented a solution to support DMM in the virtual LTE system. The virtual LTE system is composed of virtual S/PGWs running on VMs that are hosted on data centers. A new DMM transportation network was introduced in these works. The SDN/Openflow controller is responsible for controlling both the DMM transport network and EPC transport network. The use of DMM in the virtualized LTE system can enable the session continuity for UEs and redirect the traffic in case the virtual S/PGWs are migrated from one data center to another. The detail performance evaluation is shown in [108].

Kuklinski et al. [109] presented several scenarios for handover management in an SDN-based mobile network. These scenarios include full centralized, semi-centralized, and hierarchical approaches. The third scenario is similar to the mobility management in CROWD approach [70].

Trivisonno et al. [73] which was discussed earlier also provides some procedures for handover management in their SDN-based 5G network architecture.

The content delivery network (CDN) is a system relies on the traditional host-to-host communication model to deliver requested data to users based on their geographic locations with high content availability and performance. Information centric networking (ICN) [110] is the new technology for the future Internet, which advocates a redesign of the current Internet infrastructure around the concept of content rather than around the concept of addresses, as in traditional Internet infrastructure. Several proposals [111‐113] investigated the cases of CDN and ICN in the SDVMN. Karimzadeh et al. [111, 133] proposed a solution, which integrates ICN into the virtualized LTE system to support service and VM migration. In this solution, all of the virtualized LTE entities are ICN capable, while the routers in the transportation network are non ICN capable. In [112], the authors focused on video delivery services in the SDVMN. The main purpose of this work is to integrate SDN with the LTE network element for optimal video streaming. Concretely, the authors used SDN switches in a transportation network and integrated an SDN controller with an MME element in the LTE network. Video-on-demand is taken as a use case to demonstrate the benefits of this architecture. Haw et al. [113] introduced a framework for efficient content delivery in an SDN-based LTE network. The authors integrated an SDN controller with MME and deployed SDN-based SGW/PGW and SDN switches in the data forwarding plane. A CCN gateway is used to distinguish the arrived packets whether forwarded to the Internet or CCN network.

As discussed before, nowadays the MTC traffic including M2M or D2D is imposing challenges for current LTE mobile network. Several proposals [91, 114‐116] have been proposed to support these types of communication over SDN and virtualization based LTE architecture as well as to solve the challenges. Samdanis et al. [114] proposed a solution to eliminate the signaling overhead by adopting the NFV concept to machine type communication (MTC) devices (i.e., D2D or M2M devices). This paper introduced the concept of virtual bear, which can be shared by a specified set of MTC devices and the virtualization of gateway devices. Yazici et al. [115] proposed a new programmable 5G control plane architecture which supports D2D communication between two UEs. In particular, it solves mobility management of UEs in case of the movement of individual UE or both. Tableb et al. [116] proposed LightEPC, a lightweight EPC to support the communication between two MTC devices. It is enable to dynamically create scalable instances of MTC functions on demand. Similar to [116], the research work [91], which was discussed previously, supports D2D communication via a D2D agent included in FME entity.

Liyangage et al. [117] investigated the security problem in the control channel of SDMN and then proposed a solution to prevent the control channel of the SDMN from some potential attacks (e.g., TCP SYN Dos attack, TCP reset attack). The SDMN architecture consists of an Openflow-based data plane and a network controller. The network controller includes all control functions such as MME, PCRF, HSS, AAA, etc. To deal with the aforementioned potential attacks, the authors introduced three new entities: a security gateway (SecGW), security entity (SEC Entity), and local security agent (LSA). SecGWs are located between the controller and the rest of the network and are responsible for IPsec tunnels establishment with Openflow switches and for authentication and registration of new switches. The SEC Entity is a new control entity located in the network controller and in charge of controlling SecGWs. The LSA is a security module that is implemented on the switch. It is mainly responsible for establishing the secure channel with SecGWs (Table 3).

In [3], the basic model for virtualizing the IMS system based on the NFV concept was introduced. The network functions of the IMS system are deployed in VMs, which have scalable hardware resources and can be dynamically relocated in cases of a VM’s overload or failure. Thus, the operator desired service continuity and service availability can be obtained. Similarly, Lu et al. [118] also proposed a cloud-based IMS architecture, with a load balancing algorithm and a mechanism for dynamic resource allocation. Ito et al. [119, 120] proposed a new EPC/IMS system based NFV concept where each service can be processed by a particular virtual network to reduce the signaling load.

Several proposals [121‐123] follow another approach, which integrates the Openflow into the IMS system. Ito et al. [121] used Openflow-based routing to migrate call session state in the IMS system, which allows minimizing the number of servers as well as restoring call sessions subject to the halted server. The authors in [122] designed a novel QoE-aware IMS-based IPTV network architecture, deployed with the underlying Openflow network infrastructure. This architecture improves TV sessions and end-to-end QoS to satisfy the users. [123] presented IMS test-beds for future Internet research and experimentation, which are enhanced with Openflow mechanism.

Carella et al. [124] presented a design for IMS system over cloud computing system (e.g. OpenStack). The authors introduced several potential models for deploying such cloud-based IMS system and evaluated the system’s performance over their OpenSDNCore architecture [125].

In this part, we consider the works [126‐129] which leverage SDN into the set of middleboxes placed behind the SGi-LAN of the mobile network. StEERING [126] relied on the SDN concept to route the traffic through a series of middleboxes. StEERING allows steering different types of traffic through a sequence of desired middleboxes according to per-subscriber and per-application policies. Gember et al. [127, 128] introduced the concept of software defined middlebox networking to address some challenges in traditional middlebox networks, such as complex management, middlebox scaling. OpenNF [129] is a control plane architecture that allows quick and safe flows’ allocation across virtual middlebox instances by combining NFV and SDN concepts. The OpenNF controller consists of a network function (NF) state manager and flow manager. The NF state manager monitors the state of virtual middle instances while the flow manager manages the forwarding rules of SDN switches.