Introducing SDN Technology into a Mobile Core Network

Motivations
During the evolution of the mobile PS domain from 2G/3G to LTE evolved packet core (EPC), the control plane has been separated from the user plane. The mobility management entity (MME) in the EPC has signaling-plane functions, and the signaling gateway (SGW) and packet gateway (PGW) forward data on the user plane. This division of responsibilities is sufficient for meeting demands created by booming mobile data usage.
However, from the perspective of device implementation, the control and forwarding functions in the EPC are not completely separate. EPC gateway devices have route-forwarding modules and signal and service processing modules. These two types of modules are tightly coupled and communicate with each other. The structures of EPC devices are different from those of both general computational telecom devices, such as ATCA and Blade server, and routers and switching devices, which are widely used in networks. Poor device universality leads to prolonged R&D, testing, network access, and O&M. It also leads to poor scalability of functions and increased costs. Generally, traditional gateways have the following problems:
●  User data streams are mainly processed at PDN exit gateway, which resulted in verbose functions and poor scalability.
●  The forwarding plane needs to be expanded more frequently than the control plane. However, a high degree of coupling between the control and forwarding planes causes synchronized expansion, short cycle for device renewal, and high composite costs. Therefore, a high degree coupling is contrary to core network evolution.
●  In overlay mode, user data is transmitted from eNodeB to PGW. In the network layer, data can only be forwarded according to QoS from the upper layer, not according to user and service features. On the one hand, oversupply of network resources results in inefficient resource utilization. On the other hand, data flow cannot be controlled in the network layer without user and service features.
● Many policies require manual configuration and constant optimization, and this increases errors, management complexity, and opex.

Given this, the control function of the PS domain gateway needs to be further separated from the forwarding function. In this way, general forwarding devices can be controlled using standard interfaces to achieve mobility management, QoS, and charging functions of PS domain. Therefore, improvement of functions and performance of the forwarding plane is related to improvement of functions and performance of the mobile PS domain. Convergence and resource sharing between the transport network, mobile PS domain, and IP bearer network can be promoted on the forwarding plane. The general forwarding plane can be used as needed to simplify network deployment.

 

Separation of Control from Forwarding
Some key issues in separating control from forwarding are:
● tunneling. One of the most basic functions of the mobile PS domain is to construct a GTP tunnel on the forwarding plane. Separating control from forwarding causes interfaces definition problems. The SGW and PGW use the GTP-U protocol on the user plane, but SDN southbound interface protocols, such as OpenFlow, are cannot process the GTP-U protocol (e.g., cannot establish or terminate GTP-U tunnels) or monitoring data streams within GTP-U tunnels. Regardless of whether dedicated hardware or virtualized software is used for devices on the forwarding plane that supports GTP-U processing, interfaces between the controller and forwarding-plane devices still need to be standardized.
● QoS on the forwarding plane. Traditionally, mobile networks ensure QoS according to the bearer and ensure high-quality services according to dynamic policy control. QoS processing, such as bearer and service flow granularity QoS processing, must be ensured in a mobile soft network architecture. There are two issues that need to be studied in relation to mobile soft-switch networks: 1) routing and forwarding data according to the QoS strategy of the mobile network, and 2) providing user experience equivalent to that of traditional networks for upper layer applications.
● redistributing the gateway function. Traditional EPC gateway devices are capable of IP packet tunnel encapsulation and forwarding as well as session and mobility management (including IP address assignment, triggering and paging on the user plane). In a mobile soft-network architecture, these functions need to be redistributed for optimization.
● selecting gateway devices on the forwarding plane. After the control plane is separated from the forwarding plane, forwarding plane devices need to be selected according to criteria such as capacity, load, and UE location to forward IP flows. This maximizes the utilization of forwarding devices and makes transferring user traffic more efficient.
● optimizing route flow entry on the general forwarding plane. The GTP protocol the OSI’s application layer, where GTP-U encapsulation and decapsulation, TEID maintenance, and tunnel association from different segments are completed. The application layer also maintains lots of forwarding information for GTP tunnels. The underlying route entries are converged according to such standard route protocols as RIP, OSPF, and ISIS. After the control function is separated from the forwarding function, the general forwarding plane needs to support GTP-U tunnel encapsulation and decapsulation, and piecewise tunnel association. The GTP-U tunnel forwarding information is maintained in the flow table of the general forwarding plane devices. Therefore, general forwarding plane NEs are required to optimize the number of flow table entries to improve forwarding performance.

 

Industry-Related Research
Currently, research is being conducted in the following areas:
● EPC in a cloud computer with OpenFlow data plane. This architecture was patented by Ericsson on in November 2012. It integrates the control plane into the cloud computing system, which contains a cloud controller and cloud manager. The cloud controller includes multiple control-plane modules that correspond to the original EPC control-plane entities. The cloud manager monitors traffic and resource utilization of control-plane modules. These modules transmit signaling to the data plane through OpenFlow protocol to establish traffic rules and perform corresponding actions.
● EPC extensions that support mobility schemes. The latest version of this architecture was published on January 31, 2013, as part of the MEVICO project. The architecture integrates all functions into a centralized gateway element that is the termination for 3GPP signals. This element also assigns IP addresses, saves UE contexts, and runs route-selection protocols. Although the architecture uses new methods to divide SGW and PGW, it has to comply with original 3GPP interfaces and protocols.

 

● cloud EPC. The cloud EPC is an SDN-based soft EPC architecture proposed by ZTE (Fig. 1). The SDN-based soft EPC architecture completely separates control from forwarding in mobile core network NEs and strips control from forwarding-plane NEs. In this way, the control plane, not the forwarding plane, is responsible for mobility and session management. The new SDN controller on the mobile core network controls unified forwarding devices and constructs control logic for the mobile application protocol layer and functional layer. This enables basic applications of converged mobile networks. In addition, the APP can provide control functionality and service orchestration functionality (i.e., MME, P-GW-C, S-GW-C, and PCRF) of NEs as well as newly introduced service functionality after interfaces have been opened. The SDN controller connects the APP by using either internal interfaces or NBI interfaces.

To smoothly evolve existing networks, SDN technology can be introduced to gateway devices during the first stage. Traditional PGW and SGW functions can be implemented through cooperation between the GW-C and controller, both of which are on the control plane, and the UGW, which is on the forwarding plane. The GW-C can function as a separate NE, in order to communicate with the controller through NBIs, or it can be located with the controller so that internal interfaces can be used. Internal interfaces should be used in the first stage given the international standardization work on NBI done by ONF and given the performance overhead created by NE interaction.
The cloud EPC follows 3GPP protocols so that 3GPP protocol-based interfaces remain unchanged. The MME, HSS, PCRF, and OCS on the EPC network can be either traditional NEs or NE functions implemented through virtualization technology. The southbound interfaces between the SDN controller and UGW use the OF protocol based on EPC extensions.

 

Conclusion
All three architectures mentioned here separate the control plane from the forwarding plane. However, a cloud EPC does this more thoroughly. It splits the PGW and SGW functions, integrates the data plane into UGW, and updates the control plane to controller. The cloud EPC is designed to simplify network deployment and maintenance and expand network functionality. Cloud EPC enables future network requirements to be handled more flexibly and efficiently.