A Software-Defined Networking Solution for Transparent Session and Service Continuity in Dynamic Multi-Access Edge Computing
Pablo Fondo-Ferreiro, Felipe Gil-Castiñeira, Francisco Javier González-Castaño, David Candal-Ventureira
AA Software-Defined Networking Solution for
Transparent Session and Service Continuity in DynamicMulti-Access Edge Computing
Pablo Fondo-Ferreiro, Felipe Gil-Castiñeira, Francisco J. González-Castaño, David Candal-Ventureira atlanTTic Research Center, University of VigoE.E. Telecomunicación, Rúa Maxwell s/n, Campus, 36310 Vigo, Spain.Tel.:+34 986 818684; email: {pfondo,xil,javier,dcandal}@gti.uvigo.es
This work has been submitted to the IEEE for possible publication. Copyright may be transferred withoutnotice, after which this version may no longer be accessible.
Abstract
Multi-Access Edge Computing (MEC) is one of the prominent 5G concepts that willallow service requirements that were not feasible so far due to the high communicationslatency and rigidness of cellular networks. The ETSI and the 3GPP are working towardsthe standardization of MEC applications integration in 5G networks, and how to routeuser traffic to a Local Area Data Network where local applications are deployed. Nev-ertheless, there are no practical implementations that facilitate the dynamic relocationof applications from the core to a MEC host, or from a MEC host to another with-out interruption and transparently to User Equipment (UE). Furthermore, the MECconcept can also be included in a 4G network to provide new advanced services withexisting infrastructures. In this paper we propose to use Software-Defined Networking(SDN) to create a new instance of the IP anchor point to dynamically redirect the UEtraffic to a new physical location (e.g. an edge infrastructure) while maintaining sessionand service continuity. We also present a novel, completely distributed approach basedon SDN to maintain the previous context of the connection in the new instance of theIP anchor point, and we analyze the performance of this mechanism in comparison toother possible alternatives to keep the session state. This approach can be used toimplement edge services in a 4G or 5G network.
Index terms—
5G networks include technology improvements that provide low latency and improve flexibility,agility, and network and context awareness to increase the Quality of Experience (QoE) of endusers [1]. Virtualization and cloud computing have proved to be essential tools to build flexible and a r X i v : . [ c s . N I] S e p fficient architectures but the traditional centralized mode has limitations in terms of availability,performance, scalability, latency, etc. Hence the efforts to take cloud capabilities to the networkedge in different approaches such as Fog Computing, cloudlets, and the MEC paradigm.MEC is specially relevant in 5G scenarios, as it was specifically designed by ESTI for mobilecommunications environments. In 2014 the ETSI launched the Mobile Edge Computing IndustrySpecification Group (MEC ISG) to standardize the integration of third party applications in multi-vendor platforms at the edge of mobile networks [2]. This group defined a framework and referencearchitecture and a set of APIs. It considered that MEC components and Mobile Edge (ME) appli-cations would be implemented on top of the Network Functions Virtualization (NFV) architectureto share the same infrastructure and management functions. This would allow operators to maxi-mize the return of the investments in virtualization [3], and at the same time provide new servicesthat were not feasible before, such as high-quality augmented reality image generation at the edge(with graphic engines that cannot be embedded in smartphones nowadays) and low-latency remotegaming.In [4] the ETSI studied how a MEC system can be deployed into 4G architectures, and describedone of the main challenges that should be addressed: how to route IP packets to MEC applicationsin a distributed architecture. This traffic steering is closely related to the location of the MECinfrastructure, and the document describes five different alternatives:• “Bump in the wire”: The MEC platform is installed between the base station and the corenetwork. The MEC platform can be part of the eNB. In that case the system can decide ifpackets have to be routed to the local MEC application or if they have to be encapsulatedusing the GTP (GPRS Tunneling Protocol) protocol and sent to the Serving Gateway (S-GW). Alternatively, the MEC platform can be located somewhere on the S1 interface. If so,it is necessary to handle user traffic encapsulated in GTP-U packets.• Distributed EPC: The MEC includes all or part of the 3GPP Evolved Packet Core (EPC)components. This way, the MEC controls the PDN Gateway (P-GW), which is the point ofentry/exit of traffic for the UE, and can handle the DNS to provide the local IP of the MECapplication.• Distributed S/P-GW: Instead of deploying the complete EPC, only the S-GW and the P-GWare deployed at the edge site. The selection of the S/P-GW is performed by the central MMEbased on the location of the UE.• Distributed S-GW with Local Breakout (SGW-LBO): In this case it is possible to select ifthe user traffic should reach MEC applications or core applications in a selective manner.• Control/User Plane Separation (CUPS): 3GPP Release 14 standardized the CUPS paradigm,separating the control and user planes. This new architecture can be used to distribute theEPC gateways at the edge.These alternatives must address several challenges. For example, the different components haveto be MEC aware in order to manage the session and perform the right traffic routing for eachUE, and the MEC needs to be aware of the mobility of the UE to maintain service continuity, evenperforming MEC handovers (which may result in a service interruption). ETSI also points out thatthe system should be able to relocate a mobile edge application between a cloud environment and MEC host, but they note that this is still an open issue [5]. In this paper we propose a solutionfor this problem.MEC can be integrated in a 4G network by following one of the previous alternatives, butin 5G it has been identified as one of the key technologies for supporting low latency since thebeginning. Therefore, the 5G system specification defines the enablers for edge computing, andits Service Based Architecture (SBA) facilitates the deployment and integration of MEC. Otherrecent ETSI white paper [6] departs from this architecture to analyze the challenges MEC will facein 5G networks, such as traffic steering and UE and application mobility. That is, when a MECapplication is instantiated, the traffic from a particular UE has to be directed to that applicationto take advantage from its location. Also, when the user moves to a new location, the applicationand its traffic should also move to the closer MEC infrastructure.Summing up, current proposals to integrate MEC in 4G networks require a complex setup wherethe different components, such as the gateways, must be aware of their location. Furthermore, 4Gand 5G networks have also to be designed to steer the traffic to the most appropriate application,located in the core or in any of the different MEC infrastructures, in order to achieve the requiredlatency or any other feature that benefits from the proximity between the UE and the application.In this paper we take advantage of virtualization and SDN to propose an architecture that canbe used to steer UE traffic to the core of the network or to one of the MEC infrastructures. Thedestination of the traffic may change dynamically, in case the UE moves, the state of the networkchanges, the application is relocated, or the requirements of the UE are different. To achieve thisobjective, we create new instances of the P-GW (the termination point of UE traffic) in the desiredlocation (core or MEC infrastructure). Nevertheless, since the P-GW has a state, the user contextmust also be transferred. Therefore we also have designed and evaluated a new mechanism totransfer and synchronize P-GW contexts between the original instance and the new one using SDN.This mechanism is completely transparent for the UE and the P-GW, not requiring any kind ofmodification or adaptation. In addition, as shown in our Proof of Concept (PoC) implementation,this proposal can be used to easily integrate MEC infrastructures in 4G networks.
MEC technology is considered a key 5G enabler. The idea behind is to provide IT service envi-ronments and cloud-computing capabilities at the edge of the mobile network in close proximity tomobile subscribers. One of its main goals is latency reduction, which has been identified as one thekey requirements of 5G networks [7].MEC implementations involve several functions described in the 3GPP specification of the 5Gsystem architecture [8]. For example, the architecture allows concurrent access to different datanetworks (e.g., a central and a local –or edge– data network), and it is possible to define rulesto send the traffic to the IP anchor points (or User Plane Function –UPF– in 5G terminology)connected to the different Data Networks (DNs). The 5G Core Network may select a UPF andexecute the traffic steering to a DN based on UE’s subscription data, location, or following arequest from the Application Function (AF). The AF can influence traffic routing via a requestto the Session Management Function (SMF), including requesting traffic steering for single UEsor groups of them in particular areas or locations. The “UL CL” (Uplink classifier) or the IPv6multi-homing functionalities can be used to divert traffic according some traffic matching trafficfilters, but the mechanisms that enable traffic steering in the local access to the DN are not defined n the standard. Applications can also indicate that they can be relocated, or that they should benotified about certain traffic events or the traffic of UEs in a particular location. Finally, the sessionand service continuity features can be used to enable UE and application mobility.Thus, the 3GPP specification of 5G system architecture provides a detailed description of therequired functions to implement MEC in 5G and how they operate, but many mechanisms are stillnot defined in detail. Also, although the standard allows UEs to select a session and service continu-ity mode to ensure an uninterrupted service, this may require the active collaboration from the UEto maintain the connectivity when the IP address changes or a new application server is selected.Therefore, dynamic relocation of applications would not be possible without the collaboration ofthe UE. Our proposal, which includes a practical implementation of a MEC architecture with SDN,allows applications to be relocated dynamically, as it makes possible to deploy new UPFs in differentlocations keeping the IP address and the connection transparently to the UE.As introduced in Section 1, integrating the MEC architecture in 4G networks may also be ofvalue, and the ETSI and other researchers are studying this topic. For example, in [9], the authorsemphasize its interest for creating a common layer of integration for the Internet of Things (IoT).At a rather conceptual level, including a discussion of possible use cases, they mention server/proxyDomain Name Server (DNS) configuration as a way to redirect traffic to edge applications. There-fore, they do not consider the possible role of SDN technology as an enabler. They also mentionthat MEC standardization is still at a very early stage and that it should be coordinated with ETSINFV standardization (the ETSI, indeed, is driving MEC standardization and implementation withdifferent white papers, proofs of concept to demonstrate the MEC concept, Group Reports (GR)and Group Specifications (GS) ).Other researchers, instead of following the standardization, have studied how SDN, NFV andcloud technologies could be used for mobile edge applications and innovative services. For example,the mobile networks branch of Central Office Re-architected as Datacenter (CORD) [10], M-CORD[11], built a SDN scalable connectionless core with these technologies. This way, they sought toreduce the excessive signaling overhead in Long Term Evolution (LTE) networks. However, theconnectionless approach they proposed required modifying the EPC entities.Telecommunication operators have also shown interest in leveraging NFV and SDN technologiesto improve the capacity of EPCs in a cost-effective way. The PoC in [12], whose results have beenpublished in the wiki of the ETSI ISG for NFV [13], demonstrated an EPC SGW and a PGW basedon SDN and NFV technologies that splitted the control and user planes, in which the control planeresided in the SDN controller and the user plane in an SDN fabric. This preserved GTP-ControlPlane (GTP-C) and GTP-User Plane (GTP-U) protocols from the points of view of the eNB andthe Mobility Management Entity (MME). The PoC illustrated how operator network rules can bemanaged with SDN. Our approach also relies on SDN to handle user traffic.Regarding SDN control of packet cores, in [14], the authors, who participate in the Wireless &Mobile Working Group of the Open Networking Foundation (ONF), pointed out the flexibility andelasticity shortcomings of current architectures. They defined Openflow extensions to handle PacketData Network (PDN) connections while keeping Quality of Service (QoS) support, accounting andonline charging. More specifically, they identified the need of two extensions of the OpenFlowprotocol to manage GTP-U packets, matchings and actions. We have not followed this approachbecause at the time this paper was written, such extensions of the OpenFlow protocol were notimplemented. Moreover, we do not consider the possibility of modifying the OpenFlow protocol, https://portal.etsi.org/tb.aspx?tbid=826&SubTB=826 ince it is not guaranteed that such approach would be included in the OpenFlow standard, nor inSDN controller updates of existing devices.There exist different proposals for diverting traffic in 5G networks. In [15], the authors intro-duced a virtualized Evolved Packet Core (EPC) gateway that dynamically switched the data planefor each user to a fast-path dedicated element near the evolved node B (eNB), using an OpenFlowgateway with General Packet Radio System Tunneling Protocol (GTP) extensions that kept activesessions. Since GTP is not supported in the OpenFlow protocol natively, the authors needed aworkaround to analyze the content of the packets inside GTP-U tunnels. As described in [16], thisis still under discussion and has not been standardized yet. In [17], the authors also identified theneed of analyzing traffic inside GTP-U tunnels. They applied a patch to Open VSwitch (OVS)devices that is not fully compatible with OpenFlow [18], so they programmed the flows by settingSecure Shell (SSH) connections with the devices. They concluded that further work is necessary tointegrate SDN in 5G networks with the desired flexibility.Therefore, previous approaches leveraged SDN flexibility for diverting the traffic of specificusers to the network edge. Some of these approaches have identified the need to analyze thecontent inside GTP-U tunnels in the Radio Access Network (RAN), which is not directly availableto SDN devices. To overcome this limitation, it has been proposed to apply patches to OVS thatallow encapsulating and decapsulating the GTP-U protocol. We have selected this same feasibleapproach for its satisfactory performance.Edge intelligence has been highlighted as a key aspect to achieve low-latency 5G communicationsfor applications such as self-driving vehicles, industrial automation, tele-medicine, Virtual Reality(VR) and Augmented Reality (AR) [19]. Unlike the previous approaches that have simply consideredtraffic redirection to specific applications running on edge servers, we propose to deploy the S/P-GWat the network edge and reconfigure the network dynamically to move some users or flows to thenew S/P-GW instance, thus reducing latency and congestion in the core network. To achieve thatgoal, the state of the original S/P-GW must be replicated in the new S/P-GW transparently to3GPP protocols, which, as stated in [16], have not been designed with such flexibility in mind. Statereplication of mobile network functions (mainly control plane entities, such as the MME) has alreadybeen explored in the literature, using the classical three-layered architecture with a load balancerfront-end; a layer of stateless workers and a database layer with session context information [20, 21].In [22] this database layer was removed by embedding the state in the workers. Obviously, thistwo-layer approach required proactive state synchronization among the workers, which was solvedwith a custom protocol over TCP, and it still introduces delay to retrieve the state, compromisingultra low latency requirements.Generic state replication for mobile edge clouds has already been addressed. In [23], the authorspresented a layered framework for migrating active applications of virtual machines or containers.It involved dumping the entire RAM memory of the source entity, transferring it to the targetand restoring it at destination. The MEC proposal in [24] described EPC-as-a-service statefulcomponents, as well as a method to keep states among different EPC instances that replicated thewhole EPC, that is the MME, the S/P-GW and the Home Subscriber Server (HSS).Summing up, previous state replication schemes imposed high latencies and overheads.In this work, therefore, we propose a low-latency MEC computing solution that migrates S/P-GW modules to the edge without interrupting user sessions. It keeps the state of S/P-GW modulesby simply replicating 3GPP messages. Unlike previous approaches, it is generic, efficient and com-patible with all communication and network management standards involved. State replication is ightweight and fully distributed.We close this section with a note on Low Latency Multi-Access Edge Computing (LL-MEC) [25],an open source control plane platform for MEC applications part of the Mosaic5G project [26] inwhich SDN switches carry out the user plane. Even though it has similarities with our proposal,it is obviously not intended for interoperability with existing core network entities, since these arecompletely replaced by new ones.
5G networks will support a rich variety of services, many of them with stringent latency requirements(e.g. high quality augmented reality renderings, real time teleoperation, etc.). At some point aconnection through the core network will be unable to satisfy one of such demands, so it will benecessary to make use of the MEC system and deploy the service at the edge, at a location that willbe closer to the user. That may even be a dynamic scenario, in which a service that was initiallyinstantiated in the core of the network should be relocated at the edge.Our main goal is to provide a seamless solution for this scenario. If the latency of some particularflow is too high, it will be necessary to take the IP connection termination to a location with a lowertransmission delay, yet we wish to attain so without any session interruption. Besides, we assumethat custom network functions that are aware of the location of the applications are not desirable.To achieve our goal we dynamically deploy a new virtualized S/P-GW module at the network edge(i.e. close to the users), and reprogram the network automatically in a fully distributed way byrelying on the SDN paradigm, to divert the flows dynamically to the replicated S/P-GW.We remark that we seek to leverage current network entities without any modification, and torespect 3GPP and control management protocols as they are. This way, our proposal could bequickly deployed in a real network.We have identified two key challenges that must be addressed:• S/P-GW replication• Diverting traffic at individual user levelSince we want to keep existing connections undisturbed, the existing S/P-GW should continueoperating all of them except those we move to the edge. Then we need to replicate the S/P-GW,so that multiple S/P-GWs will be available in the network. A first barrier is that, at the momentof writing this paper, Evolved Packet Core implementations such as that by the OpenAirInter-face Software Alliance did not allow the same MME to manage multiple S/P-GWs nor multipleS/P-GWs to be connected to the same eNodeB. Even though the LTE standard considers this lastpossibility, it is only considered a static setting in which each UE is assigned an S/P-GW at con-nection establishment. Besides, the original S/P-GW has a context for each user, which identifieshow the user traffic should be exchanged with the eNodeB through the S1-U interface. This trafficis encapsulated using the GTP-U protocol. The MME manages the endpoints of this tunnel usingthe GTP-C protocol, which communicates with the S/P-GW through the S11 interface.Thus, somehow, the newly deployed S/P-GW must have access to that context information tobe able to handle the packets of the users. That is to say, the context of the original S/P-GW mustbe replicated into the new one for the latter to establish the tunnels and become fully operational. On the other hand, we want to divert the traffic of specific users to the edge of the network, i.e.as soon as possible once the eNodeB transmits the packets. At this point, they are encapsulatedwith GTP headers where the outer IP headers of the packet correspond to the endpoints of theGTP-U tunnel: the eNodeB and the S/P-GW. Therefore, the UEs cannot be identified by onlyanalyzing the outer IP or UDP headers, as they will be identical for all users connected to the sameeNodeB. To divert the traffic of specific UEs, inner IP packets inside the GTP tunnels (i.e., thepackets sent by the UE) must be analyzed. Figure 1 shows the GTP-U protocol stack, as used inthe S1-U and S5/S8 interfaces of the EPC, to help the reader visualize this problem.
We propose an SDN based architecture that is able to dynamically change the endpoint of a IPconnection for a particular UE. It makes it possible to deploy applications at the edge, and even torelocate applications that were previously running in other locations.First, we include an SDN device in the architecture to handle the communications between theRAN and the EPC (HSS, MME and S/P-GW) as shown in Fig. 2. Initially, an SDN controllermanages the forwarding decisions of the device with a simple reactive learning application.Then, we implement a framework for edge-assisted latency reduction with two modules: (i)an application that dynamically deploys a new S/P-GW entity and (ii) an SDN application thatreplicates the state of the S/P-GW and configures the SDN fabric to divert the traffic of specificUE flows.The workflow of the solution is as follows:1. The module in charge of deploying S/P-GWs dynamically launches a new S/P-GW VirtualMachine (VM) at the edge of the network. This is performed via REST API exposed byOpenStack using Heat Orchestration Templates (HOT).2. Once the S/P-GW VM is up and running, the SDN application is called via REST APIexposed through the SDN controller.
3. The SDN application then replicates the state of the original S/P-GW into the newly createdS/P-GW.4. Once the state has been replicated, the SDN controller instructs the SDN device that com-municates the eNodeB with the EPC to divert the traffic of the specific users that must bemigrated to the new S/P-GW to meet their traffic requirements.The following subsections describe in detail how we have addressed S/P-GW replication anddivertig traffic at individual user level.
Our solution launches an S/P-GW VM in a server located in a datacenter that is physically close tothe eNodeB to which the UE is connected. The first challenging step is making this replicated S/P-GW fully operational. As we have previously mentioned, the replicated S/P-GW must have accessto the state of the original S/P-GW. As discussed in Section 2, the proposals in the literature eitheremploy fully stateless modules whose state information is centralized in an external database orkeep the state inside the modules but must synchronize their states (and thus need custom moduleswith an ad-hoc signaling protocol). Our goal is to address this step without any centralized ad-hocelement and transparently to EPC network entities.Note that the S/P-GW is a reactive entity. In particular, after analyzing it as well as theprotocols involved in the EPC network, we found out that its internal state is completely determinedby the messages it receives from the MME. The latter is in charge of instructing the S/P-GW toestablish data path GTP-U tunnels (S1-U interface) with the eNodeBs. Therefore, we propose toreplicate the state of the original S/P-GW by sending to the newly deployed one the same GTP-Cmessages that the MME sent to the original S/P-GW.To accomplish this, the SDN controller stores the GTP-C messages that the MME sent to theoriginal S/P-GWs. When the SDN controller is instructed to replicate into a newly deployed S/P- W the state of the original S/P-GW, the SDN controller sends to the new S/P-GW all thosemessages. From this moment on, any GTP-C message that the MME sends to the original S/P-GW(which is also received at the SDN controller), is sent to the new S/P-GWs as well.This process requires the GTP-C messages sent by the MME to be forwarded through theSDN controller. We have addressed this by creating a lightweight OVS switch in the MME virtualmachine, with just one port besides the LOCAL one. This OVS will treats all non-GTP-C packetsin a completely transparent way, by sending those received at the LOCAL port to the other portand vice versa. A high-priority flow rule is installed in this switch, so that the GTP-C packets sentby the MME are forwarded through the SDN controller. In addition, another high-priority flowrule is also installed when the traffic diversion is enabled, so that the GTP-C packets generatedby replicated S/P-GWs that are addressed to the MME will be discarded. This way, replicatedS/P-GWs will be completely transparent to the original mobile network entities.
The packets at the network edge are encapsulated inside GTP-U tunnels. Redirecting the traffic ofall the users to the replicated S/P-GW would be fairly simple: we could simply set a flow rule in theswitch that is closer to the eNodeB to match all GTP-U traffic (i.e. UDP traffic for port 2152 [27])that is addressed to the original S/P-GW and replace the destination IP and MAC addresses bythose of the replicated S/P-GW.However, we are interested in only diverting the traffic of specific users, applications or eventhe traffic between specific users. Since the packets are GTP-U-encapsulated, user-specific informa-tion is contained inside the GTP-U header. To differentiate users it is necessary to match the IPaddresses of the inner IP header. At the time this paper was written, the OpenFlow protocol [28]could not match fields in layers above the transport protocol (UDP in this case). Our solutionconsists in encapsulating and decapsulating GTP-U packets in the switch to access the inner UE IPpackets. After analyzing several options to implement this we chose Open vSwitch (OVS) [29], themost extended OF-enabled switch. OVS defines special tunnel ports that allow encapsulating anddecapsulating packets. Its current version supports tunnels such as VXLAN, GRE and LISP, butnot GTP. However, the open source patch at [30, 31] (also used in the LL-MEC platform [25]) ex-tends OVS to support GTP tunnel ports in the same way as natively supported tunnels, leveragingthe GTP linux kernel module.The patch allows us creating an OVS switch that is directly connected to the eNodeB through avirtual GTP port that decapsulates inbound GTP packets and encapsulates outbound ones. Whena packet is encapsulated, the destination endpoint of the GTP tunnel can be set in a flow by usingOVS extensions that are fully supported by OpenFlow and most SDN controllers, such as ONOS.Our proposed solution uses three flow tables in the OVS switch that are managed by the SDNcontroller.• Flow table 0: a classification table.• Flow table 1: a GTP encapsulation table.• Flow table 2: a forwarding table.The SDN controller executes a a forwarding application to manage normal packet forwarding,and a diverting application to manage diverted traffic to a replicated S/P-GW. he forwarding application applies the following flow rules: the low-priority flow rule in table 0matches any packet and its action is sending the packet to table 2. Table 2 is a regular forwardingtable with a low-priority flow rule that sends any packet to the controller. Besides, other medium-priority flow rules in table 2 match source and destination MAC addresses with an action to forwardpackets to the proper port. The SDN controller installs these medium-priority flow rules in theswitches as classical reactive learning switch applications: whenever the controller receives a packet,the source MAC address is learned and associated to the corresponding switch input port. Then,if the port associated to the destination MAC address is known, a medium-priority flow rule isinstalled in table 2 of the switch, so that the switch directly forwards the remaining packets of theflow at line rate. Otherwise, the packet is flooded and no flow rule is installed in the switch yet.On the other hand, when traffic is diverted, for example for moving UE1 , which is connectedto eNodeB
ENB , from the original S/P-GW
S/P-GW1 to the replicated one
S/P-GW2 , the divertingapplication installs the following flow rules in the GTP-enabled OVS switch that is closer to theeNodeB:1. a medium-priority flow rule in table 0 that will identify the GTP-U packets originated at theOVS switch (that is, encapsulated by this OVS switch). It will then change the source IPaddress to that of the
ENB and send the packet to table 2, to be forwarded as a normal packet.2. a high-priority flow rule in table 0 that will identify the packets decapsulated by the OVSswitch (i.e. those received at the
GTP virtual port of the switch) and send them to table 1, sothat these packets will be adequately re-encapsulated to their destination S/P-GW.3. a low-priority flow rule in table 1 that will match any packet and send it to the input port ithas been received at, that is, to the
GTP virtual port, for that packet to be encapsulated. Thisflow rule sets the tunnel destination IP to the
S/P-GW1 address. This way, the packets thatdo not have to be diverted are encapsulated with a GTP-U leading to the original S/P-GW,with the same GTP Tunnel Endpoint Identifier (TEID) as the original packet.4. a high-priority flow rule in table 1 that will match the packets sent by
UE1 and send themto the input port they have been received at, that is, to the
GTP virtual port, for them to beencapsulated. This flow rule sets the tunnel destination IP to the
S/P-GW2 address. This way,the packets of
UE1 are encapsulated with a GTP-U header leading to the replicated S/P-GW,with the same GTP TEID as the original packet.5. Finally, a medium-priority flow rule in table 0 that will identify the GTP-U packets originatedat
ENB for
S/P-GW1 . It will then change the destination IP and MAC addresses to those ofthe OVS switch, and send the packets to their
LOCAL port, for them to be decapsulated. Thenetwork stack of the OVS switch will then receive the GTP-U packets and its GTP kernelmodule will decapsulate them. The
GTP virtual port of the OVS switch will then receive thedecapsulated packets. We modify the MAC and IP addresses of the GTP packets becausedecapsulation can only take place if the OVS switch is their final destination.Tables 1 and 2 summarize the flow rules installed in flow tables 0 and 1 of the OVS switch,respectively, after diverting the traffic of UE
UE1 . Note that table 2 is a forwarding table that iscompletely managed by the forwarding application, which is not affected by the diverting applica-tion.
Priority Match Action
HIGH IN_PORT=GTP GOTO_TABLE(1)MEDIUM IPv4,NW_SRC=ENB_IP,NW_DST=S/P-GW1_IP,UDP,TP_DST=2152 SET_IP_DST=OVS_IP,SET_ETH_DST=OVS_ETH,OUTPUT=LOCALMEDIUM IPv4,NW_SRC=OVS_IP,UDP,TP_DST=2152 SET_IP_SRC=ENB_IP,GOTO_TABLE(2)LOW ANY GOTO_TABLE(2)
Table 2: Flow rules installed in table 1.
Priority Match Action
HIGH IPv4,NW_SRC=UE1_IPSET_TUN_DST=S/P-GW2_IP,IN_PORTLOW ANY SET_TUN_DST=S/P-GW1_IP,IN_PORT
Figure 3: Packet processing inside the GTP-enabled OVS.11 he block diagram in Figure 3 shows the processing of a user plane packet in a GTP-enabledOVS that is close to the eNodeB. The following steps are depicted in the diagram:1. The GTP-U packet is received at the physical port of the device (Port 1 in the figure).2. The device checks for matches with flows in table 0.3. The packet matches a flow in table 0 that sets the destination IP and MAC addresses to thethose of the OVS and the output for the packet to the LOCAL port.4. The packet is now in the networking stack of the host, which forwards the packet to the GTPkernel module.5. The GTP kernel module decapsulates the packet, and then it forwards the inner packet tothe bridge through the GTP port.6. The packet checks for matches with the flows in table 0.7. The packet matches a flow in table 0 that forwards the packet to table 1.8. The packet matches a flow in table 1 that sets the tunnel destination IP to the desired S/P-GW and the output for the packet to the GTP port.9. The packet is forwarded from the GTP port to the GTP kernel module.10. The packet is now encapsulated with the desired S/P-GW as the destination GTP endpoint,with the same TEID as the original tunnel, and then inserted into the bridge through theLOCAL port.11. The packet checks for matches with the flows in table 0.12. The packet matches a flow in table 0 that sets the source IP and MAC addresses to those ofthe ENB and forwards the packet to table 2.13. The packet matches a flow in table 2 that takes the packet to the proper physical port.14. The GTP-U packet is forwarded through the physical port of the device (Port 2 in the figure).
We have implemented a fully operative solution with the following characteristics:• The location of the traffic exit and entry points for the UE can be modified dynamically,thanks to the dynamic replication of a fully operational stateful 3GPP-compliant S/P-GWby replicating the GTP-C messages that the MME sends to the original S/P-GW throughthe S11 interface.• User plane traffic can be diverted with existing technology to another S/P-GW at the networkedge. No OpenFlow GTP extensions are necessary. An existing Open vSwitch patch can beused to encapsulate and decapsulate GTP packets transparently to OpenFlow. • The process of replicating a 3GPP-compliant S/P-GW and dynamically diverting per-usertraffic to it is completely transparent to the network, without any modification of currententities, leveraging SDN flexibility. As a result, our solution can be quickly deployed on anyexistent 4G network and is completely interoperable with existing entities.Therefore, our solution is fully 3GPP compliant and can be deployed on a real network withoutany changes in the OpenFlow protocol nor in the SDN controller. It only requires patching an OVSdevice to extend OVS tunnel virtual ports in order to support the GTP-U protocol.
As shown in the previous sections, our proposal can be easily integrated in existing 4G networksor included in new 5G deployments to provide a operative MEC architecture that can even handleapplication session continuity after handovers or MEC application relocations. In this section weanalyze the performance of the solution to demonstrate that it does not affect the operation of thenetwork. We analyze separately its control and data planes, since they are independent.
The control plane handles the replication of the default S/P-GW context into the new S/P-GWs.Our solution implies that the GTP-C packets sent by the MME are forwarded through the SDNcontroller and that the SDN controller must store these packets. Then the stored GTP-C packetsare sent to the new S/P-GW. Fig. 4 depicts the path of the GTP-C packets from the MME to theS/P-GW through the SDN controller. In this section we study the impact of this approach in depth.First, we must consider the impact of MME GTP-C packet forwarding through the SDN con-troller. This increases the amount of control traffic in the OpenFlow channel between the SDNcontroller and the MME OVS switch. TP-C packet forwarding clearly introduces some control communications overhead betweenthe MME and the S/P-GW . Passing through the SDN controller may delay these packets. Thetotal latency of a control GTP-C packet that the MME sends to the S/P-GW will increase withrespect to a normal packet transmission. This extra latency will be given by the contributions ofpacket transmission delay from the OVS switch to the controller; the processing delay of the GTP-Cpacket at the controller; and the transmission delay from the controller to the OVS switch. The onlyprocessing at the controller is obtaining the destination IP address of the packet (i.e. the S/P-GWaddress), and storing the packet in the list of messages associated to that S/P-GW, whose elapsedtime is negligible, in the order of microseconds. The time to send the packet to the controller is thetransmission delay of an OpenFlow
PACKET_IN message containing the GTP-C packet. Analogously,the time to transfer the packet from the controller to the OVS device is the transmission delay ofan OpenFlow
PACKET_OUT message containing the GTP-C packet. The total measured latency forthe communication is in the order of 10 milliseconds, which is coherent with previous studies on thelatency of the control plane of SDN-enabled switches [32].Even though this may look acceptable, we studied how to reduce this delay: Instead of sendingeach GTP-C packet to the SDN controller, storing it and then sending the GTP-C packet back tothe switch for normal forwarding to the S/P-GW, we also considered the possibility of sending thepacket to the controller and forwarding it directly to the S/P-GW (e.g. using two output actionsinside one flow rule, or an OpenFlow ALL Group Action that outputs to the proper port of thedevice and to the SDN controller). This way, we can totally avoid the SDN controller overhead inGTP-C communications and store packets in the SDN controller asynchronously.The next relevant metric is the amount of information that must be stored in the system . In ourmessage replication proposal, the SDN controller is the most affected entity by state replication,since it must store the GTP-C messages that the MMEs send to the S/P-GWs.In principle we considered that the SDN controller stored all GTP-C packets from each MMEup to that moment. This simplest approach is valid for a proof-of-concept, but it clearly does notscale well. From some moment on, some GTP-C packets stored at the SDN controller should bedropped or transferred to another storage system. However, dropping these packets would affectthe context of future S/P-GWs deployments. For example, it would not be possible to completelyestablish the GTP-U tunnel of a user in a new S/P-GW, and therefore we would not be able tomove that user to a newly deployed S/P-GW.To avoid this drawback we propose the following modifications beyond the simplest version:• Only storing messages associated to active MMEs. That is, when a MME gets disconnected,all received messages from that MME are removed.• Only storing messages associated to active S/P-GWs. That is, when a S/P-GW gets discon-nected, all received messages that are related to that S/P-GW are removed.By doing so, our solution does not lose any context information and we reduce the amount ofstored information in the SDN controller. We remark that GTP-C packet size is relatively small.For example, two basic GTP-C messages that must be stored for each UE are
Create Session Request and
Modify Bearer Request , which the MME sends when the users get connected to the network.Their sizes are less than 150 and 50 bytes, respectively.Another metric that we consider for the control plane is the time for state replication . Afterlaunching the VM with the S/P-GW, the SDN controller will send all the stored GTP-C messagesthat are associated to the original S/P-GW. The time to send these packets is the time it takes he SDN controller to send them using PACKET_OUT
OpenFlow messages. After the first packet istransmitted, the rest are transmitted sequentially. The S/P-GW must have finished processing theprevious message when it receives a new one. In the OpenAir-CN implementation, this processingtakes less than 10 milliseconds for
Create Session Request messages and about 1 millisecond for
Modify Bearer Request messages.We remark that moving a user flow does not affect the data plane traffic at all, since data planetraffic will be forwarded through the original S/P-GW while the replicated S/P-GW is not ready.Hence, the initial control plane delay that we have described should be understood as the elapsedtime since traffic diversion is triggered until it is operational.Finally, the control information overhead in the network , is the amount of control informationthat must be transmitted through the network during the state replication process. As we havepreviously described, our solution must send all the packets between the MME and the S/P-GWthat were previously stored. This is less than
200 bytes per each user that is connected to theS/P-GW.Despite the described improvements, the replication scheme in this section still requires storingthe GTP-C messages that are received at the original S/P-GW in the SDN controller and transmit-ting them to the new S/P-GW. For this reason we refer to it as naive message replication . In thefollowing section we present further improvement that increase the scalability of our solution.
The first additional improvement we propose is to only store messages associated to active UEs.That is, when a UE gets disconnected, all messages received regarding that UE are removed. Inother words, the amount of information that needs to be stored is proportional to the number ofactive UEs. However, the transmission delay of all stored GTP-C packets may still be unacceptablefor an extremely dynamic scenario with many users connected to an S/P-GW. To mitigate this, weintroduce another improvement: we only send the GTP-C packets that are associated to the UEswe want to move. If later on we need to move any other UEs, it would suffice to send the GTP-Cpackets of those new UEs. Therefore, both the information overhead of the migration process andthe state replication delay are independent from the amount of stored GTP-C messages. Indeed,they are proportional to the number of users to be migrated.We refer to the strategy that results from applying these two additional improvements to thenaive message replication as selective message replication . This strategy scales much better. How-ever, it requires some modifications in the implementation of our proposal:1. For each UE, after sending the
Create Session Request , the SDN controller must extract fromthe
Create Session Response the S/P-GW GTP TEIDs corresponding to the S11 and S1Uinterfaces as well as the IP address assigned to the replicated UE. This information must alsobe stored in the SDN controller. Then, when the SDN controller replicates the state of theoriginal S/P-GW for a user in a new S/P-GW instance, the SDN controller needs to modifythe S11 GTP-C TEID used in the
Modify Bearer Request message for the new S/P-GW inorder for the latter to accept the message. The overhead due to this header modification isalmost negligible.2. Two additional modifications must be applied to the data plane traffic that is forwarded tothe replicated S/P-GW, for the latter to be operational. First, the S1U GTP-U TEID in he packets from the eNodeB to the S/P-GW (uplink direction) must be modified with thevalue stored in the SDN controller. Second, the original network address of the UE must betranslated to the address that the replicated S/P-GW assigns to the UE in the uplink trafficand vice versa in the downlink.The first modification can be easily implemented in the SDN controller. It just requires a simpleheader change in control plane traffic. We can extend our data plane solution in a similar way tosupport the other two modifications, which involve header changes in data plane traffic, at line rate.We can leverage the GTP-enabled OVS device, which we have already introduced, to decapsulatethe packets, perform the network address translations and encapsulate them again by setting theproper TEID.Note that these modifications need some information to be stored in the SDN controller. Inaddition to the GTP-C packets associated to each active UE, the SDN controller must store, for theUEs that migrate to the replicated S/P-GW, the S11 and S1U GTP TEIDs and the new IP addressassigned by that S/P-GW. However, note that this information is proportional to the number ofmigrated UEs, which will obviously be less than the active UEs. One of the main contributions of this paper, is a fully distributed technique based on SDN toseamlessly maintain the connections even when endpoint of the GTP tunnel (the S/P-GW) is a newinstance. That is, we use SDN to replicate the state of an old instance of an S/P-GW into a newone. Therefore, it is specially relevant to analyze the performance of this technique, and to compareit with some alternative schemes found in the literature to replicate the state of an application ora network function.In this comparison we consider the naive and selective message replication solutions versusstateless S/P-GWs [20, 21], RAM replication [23] and a custom protocol [22]:• Naive message replication: Replication of all received GTP-C messages in the original S/P-GW into the new S/P-GW.• Selective message replication: Replication of the GTP-C messages of the UEs to be movedinto the new S/P-GW.• RAM replication: RAM dump of the original S/P-GW into the new one.• Stateless S/P-GWs with centralized state: Stateless S/P-GW entities whose states are cen-tralized in a database.• Custom protocol to replicate the state of the S/P-GW.First, we compared the schemes qualitatively by checking if they:• required to modify any of the EPC entities.• allowed for selective replication.• implied service downtime.
Approach References Modification of EPC entities? Selective replication? Downtime? Overhead in control plane?
Naive message replication Our proposal No No No NoSelective message replication Our proposal No Yes No NoRAM replication [23] No No Yes NoStateless S/P-GWs [20,21] Yes Yes No YesCustom protocol [22] Yes Yes No No • introduced control plane overhead.The approach combining stateless S/P-GW modules and a centralized state requires modifyingthe S/P-GW modules and storing their state in a centralized database. The latter introduces over-head in control plane communications. However, it allows for selective replication without servicedowntime. The RAM replication strategy does not require any modification of curent EPC entitiesbut, since it replicates the whole RAM of a VM, it does not allow for partial state replications.Also, as described in [23], this approach needs to stop the service before dumping the RAM, andthus it incurs in downtime. Finally, a custom protocol for state replication optimized for movingindividual user flows to the edge would require modifying the S/P-GW to support the regenerationof specific GTP tunnels, to allow for selective replication without any downtime.Our message replication proposals do not require any modification of S/P-GW entities andthere is no downtime because the original S/P-GW entity does not participate in the replication(i.e. it continues operating uninterruptedly during the replication process). Besides, the overhead incontrol plane communications can be mitigated by sending the packets asynchronously to the SDNcontroller, as we have previously explained. The naive strategy involves complete state replication,but the selective version allows for a fine-grained replication.Table 3 summarizes the qualitative comparison.The solutions that need to modify EPC entities are not interoperable with existing deployments.Since interoperability is a basic requirement for us, we only carried out a quantitative benchmark-ing of the three interoperable alternatives. In it we evaluated the main metrics involved in statereplication: a) amount of information that must be stored in the system, b) time needed for statereplication and c) network overhead. Moreover, we studied the scalability of these alternatives, byanalyzing their performance as the number of registered and moved users growed.The testbed for these experiments consisted of four VMs (1 vCPU,
RAM,
10 GB
Disk) inan OpenStack cloud, interconnected through a / s network. These VMs ran an ONOS SDNcontroller, one MME and two S/P-GWs from OpenAir-CN, respectively. The results average 10independent executions.Fig. 5 shows the amount of information that must be stored in the system as the number of UEsincreases. The first we observe is that the RAM approach does not require storing any informationin the system, since when the replication is triggered the current RAM of the default S/P-GW isdumped and transferred to the new one. On the other hand, the information stored in the messagereplication proposals grows linearly with the number of users. Particularly, the naive approachrequires
189 bytes per each registered UE, whereas the selective approach requires
16 bytes per eachmoved user plus
189 bytes per registered user. The former correspond to the S11 & S1U GTP TEIDsand the IP address of the UE in the new S/P-GW, and the latter to two GTP-C messages.Fig. 6 represents the network overhead (amount of control information transmitted) during acomplete state replication. We can see that it is considerably larger for the RAM dump, rangingfrom
160 MB for a single user to for 1,000 registered users. Moreover, with this strategy the N o . r e g i s t e r e d U E s N o . m o v e d U E s I n f o r m a t i o n ( k B ) Figure 5: Amount of information stored in the system.18 N o . r e g i s t e r e d U E s N o . m o v e d U E s O v e r h e a d ( M B ) Figure 6: Overhead introduced in the network. amount of information stored does not depend on the number of moved users but on the numberof registered ones. Note that the overhead does not increase linearly with the number of registeredusers, but quadratically. Conversely, message replication approaches introduce a minimum overhead,introducing just
189 bytes per registered user in the naive version and
189 bytes per moved one inthe selective version. For 1,000 registered and moved users, it is three orders of magnitude lessthan for the RAM replication. This highlights the potential of our message replication strategies,specially of the selective version, due to their minimum impact in the network.Fig. 7 represents the elapsed time for a complete state replication. The time needed with theRAM replication strategy is much longer than with our proposals, for any number of registered ormoved UEs. Again, RAM replication does not allow for a selective replication in case of movingless than all registered UEs. The difference is specially relevant when replicating the state forjust a single registered user: it takes less than
50 milliseconds with message replication approachesand over
26 seconds with the RAM replication strategy. A breakdown of the times involved in theRAM replication approach yields the following results: about 16.5 seconds to dump the RAM todisk, about 1 second to transfer
160 MB of dumped RAM to the replicated S/P-GW and about8.5 seconds to restore the RAM from disk. We have also observed that the processes of dumpingand restoring the RAM do not depend on the amount of used RAM, but on the total RAM of the N o . r e g i s t e r e d U E s N o . m o v e d U E s T i m e ( s ) Figure 7: Elapsed time for state replication.
VM. The time needed for transferring the dumped RAM increases quadratically with the numberof registered users, because it depends on the amount of transmitted information (as studied inFig. 6). Conversely, the elapsed time of naive message replication grows linearly with the number ofregistered users whereas the selective version does so with just the number of moved users, allowingfor a faster replication. A breakdown of the time of these approaches shows that the time needed totransmit a message is less than and the S/P-GW takes between 1 and 10 millisecondsto process a received message and create the proper context.
Regarding the data plane, our solution requires an OVS switch patched with GTP-U capabilities,which should be close to an eNodeB. The main impact is the processing load in that switch todecapsulate a packet and re-encapsulate it again. Nevertheless, this is only performed in the uplink.Downlink packets are forwarded as normal traffic.We analyzed experimentally the overhead in data plane performance. The metrics that westudied were TCP throughput and packet delay. We took as baseline the scenario without GTPprocessing , in which GTP-U traffic is forwarded normally (i.e. without applying our solution). This scenario determines the best possible performance. We compared it with an scenario with GTPprocessing , whose performance is necessarily lower.The tesbed in this experiment recreated a realistic setup with VirtualBox VMs (1 CPU and 2GB RAM). Four VMs represented the eNodeB, the S/P-GW, the OVS switch and the ONOS SDNcontroller. The eNodeB, the S/P-GW and the SDN controller had network interfaces that wereconnected to the OVS switch VM through different internal networks. This way, the traffic betweenthe eNodeB and the S/P-GW had to traverse the OVS switch. Fig. 8 depicts the architecture ofthe testbed. We created a GTP tunnel between the eNodeB and the S/P-GW for the traffic to beGTP-encapsulated when traversing the OVS switch. Since GTP is a raw IP encapsulation protocolwe added static ARP entries in the eNodeB and the S/P-GW to enable connectivity between theGTP interfaces that were created at both endpoints.The first experiment studied communication latency between the eNodeB and the S/P-GW.Fig. 9 shows boxplots of the round-trip time (RTT) of ICMP packets generated with the ping tool.The whiskers correspond to the th percentile and outliers have been omitted for clarity. Fig. 10shows the histogram of the RTT of those packets. We can see that the distribution of the delayin both scenarios was similar and approximately normal. The only difference is that the median isabout . without GTP processing and . with it. This indicates that the RTT overhead ofour solution is about . . The first conclusion from this result is a lower bound on achievablelatency with our solution of . .The next experiment studied the maximum TCP throughput achieved with our data planesolution. We used the iperf3 tool to generate an intended traffic rate between the eNodeB and theS/P-GW and measured how much of this rate was achievable. We also analyzed CPU usage of theOVS switch VM ito study its relationship with the overhead of our solution. Fig. 11 shows TCPdownlink throughput and CPU usage for intended throughputs between 0 and / s . As wecan see, target throughputs up to / s were reached. From that point on, throughput gotsaturated at about / s for the scenario without GTP processing and at a slightly lowerrate for the scenario with GTP processing. This slight difference in the downlink was also reflected R TT ( m s ) Figure 9: Boxplot of packet delay in the VirtualBox testbed.
Figure 10: Histogram of packet delay in the VirtualBox testbed.22 n CPU usage: for the same target throughput, the scenario with GTP processing took up to
10 % more CPU.Even though the impact of our solution in downlink throughput was relatively low, we couldappreciate an increase of CPU consumption of the OVS switch. To further understand the relation-ship between consumed CPU and achieved throughput, we calculated a linear fit regression betweenboth metrics for each execution. Fig. 12 depicts the results. The correlation between the parameterswas about 0.98 in both scenarios, confirming a strong linear relationship between the metrics. Theslope was practically the same, except for slight differences due to the TCP ACKs in the uplink, butthe offset was noticeably higher in the scenario without GTP processing (about
37 Mbit / s ). That is,for a given level of consumed CPU, the scenario without GTP processing achieved about
37 Mbit / s extra throughput. The offset corresponded to the processing mechanism and did not depend ontraffic rate.Fig. 13 shows achieved TCP uplink throughput and CPU usage for intended throughputs be-tween 0 and / s . The intended throughput was achievable up to / s in the baselinescenario, whereas with GTP processing it got saturated at
700 Mbit / s . This different behavior wasagain also observed in CPU usage, which grew rapidly with GTP processing to
100 % at about
700 Mbit / s . Unlike in the downlink, GTP processing had noticeable impact on maximum achiev-able throughput in the uplink. Nevertheless, we remark that this is only due to the CPU processingin the OVS switch, which in our experiments was implemented in a VirtualBox VM. Therefore, ina real deployment with a physical SDN switch or a specialized computer, the behavior would besimilar at much higher rates.We analyzed again the relationship between CPU usage and maximum achievable throughput bymeans of linear fit regressions between both metrics for each execution. Fig. 14 depicts the results.In this case there is also a strong linear relationship between both metrics, with correlations above0.99 in both scenarios. The linear fit without GTP processing was similar to that of the downlink,as expected. Again, the fixed difference due the GTP processing mechanism was about
37 Mbit / s ,but now the slopes were clearly different. A increase in CPU yielded a .
88 Mbit / s increasein achievable throughput in the baseline scenario, whereas there was only a .
98 Mbit / s increasewith GTP processing. We can interpret these results as that GTP processing in the OVS switchrequires an increase in CPU usage that affects mainly the uplink. This CPU overhead has a linearrelationship with traffic rate, so that just . . ×
100 = 64 % of the target throughput is achievablefor a given CPU usage. We remark that this overhead is needed for flow-specific traffic diversion,which requires packet decapsulation and reencapsulation.
Edge computing is one of the key technologies for 5G, bringing applications closer to the user toensure low-latency responses, avoid transmitting large data stream volumes through the network oreliminate potential bottlenecks in the core of the network. Although this concept was not consideredduring the design of 4G networks, it can be integrated into them to attain the same benefits.In this paper we have presented a proposal that simplifies the integration of MEC applications.It allows deploying a new S/P-GW in the edge for particular users and diverting their traffic tothat endpoint. This way, an orchestrator can launch a MEC application at the edge and redirectuser traffic to that application using SDN. Furthermore, with our system the application could bealready running in another location (e.g. the cloud, the core of the network, other edge location), A c h i e v e d t h r o u g h p u t ( M bp s ) Intended throughput (Mbps)Without GTP processingWith GTP processing (a) Achieved throughput C o n s u m e d C P U ( % ) Intended throughput (Mbps)Without GTP processingWith GTP processing (b) CPU usage
Figure 11: TCP downlink throughput: Achieved throughput and CPU usage for differenttarget throughputs. 24
200 0 200 400 600 800 1000 1200 0 10 20 30 40 50 60 70 80 90 100 A c h i e v e d t h r o u g h p u t ( M bp s ) Consumed CPU (%)Without GTP processingLinear fit: 10.80x + 25.28With GTP processingLinear fit: 10.31x - 12.44
Figure 12: TCP downlink throughput: Relationship between achieved throughput and CPUusage. and be relocated to the new MEC host.In 4G networks our solution is directly applicable to S/P-GW replication. In 5G networks theUPF, which includes the S-GW ad the P-GW, anchors the IP address for a UE the same way aP-GW does in 4G, and it can include the “UL CL” (Uplink classifier) functionality to divert sometraffic by matching traffic filters. In that scenario there are multiple session anchors that can beused to direct the traffic from the UE to different locations (DN or Data Networks). Then, oursolution can be also viewed as a practical implementation of the UL CL functionality that usesSDN to facilitate advanced features such as the dynamic deployment of new session anchors andthe relocation of applications.SDN is the key technology for our proposal. It is used to redirect the desired traffic from a UEto the new endpoint (probably located at the network edge in the cases when we want to reducethe latency). To avoid disrupting existing connections the new S/P-GW must maintain the contextof the previous instance, so we have used SDN in a novel way to replicate its state. We capturethe control messages that are sent to the S/P-GW and resend them when we want to replicate thecontext in the new instance. We have analyzed the performance of this fully distributed approachand compared it with other possible alternatives to replicate the state. Our solution is highlycompetitive both quantitative and quantitatively.
Acknowledgements
This work has been supported by “la Caixa” Foundation (ID 100010434) fellowship LCF/BQ/ES18/11670020,MINECO grant TEC2016-76465-C2-2-R, and Xunta de Galicia grant GRC 2018/053, Spain. A c h i e v e d t h r o u g h p u t ( M bp s ) Intended throughput (Mbps)Without GTP processingWith GTP processing (a) Achieved throughput C o n s u m e d C P U ( % ) Intended throughput (Mbps)Without GTP processingWith GTP processing (b) CPU usage
Figure 13: TCP uplink throughput: Achieved throughput and CPU usage for varying targetthroughput. 26 A c h i e v e d t h r o u g h p u t ( M bp s ) Consumed CPU (%)Without GTP processingLinear fit: 10.88x + 35.57With GTP processingLinear fit: 6.98x - 1.33
Figure 14: TCP uplink throughput: Relationship between achieved throughput and CPUusage.
References [1] Y. C. Hu, M. Patel, D. Sabella, N. Sprecher, and V. Young, “Mobile Edge Computing - A keytechnology towards 5G,”
ETSI white paper , vol. 11, no. 11, pp. 1–16, 2015.[2] F. Giust, X. Costa-Perez, and A. Reznik, “Multi-Access Edge Computing: An overview ofETSI MEC ISG,”
IEEE 5G Tech Focus , vol. 1, no. 4, 2017.[3] “ETSI GR MEC 017 v1.1.1. Mobile Edge Computing (MEC); Deployment of Mobile EdgeComputing in an NFV environment,” February 2018.[4] F. Giust, G. Verin, K. Antevski, J. Chou, Y. Fang, W. Featherstone, F. Fontes, D. Frydman,A. Li, A. Manzalini et al. , “MEC deployments in 4G and evolution towards 5G,”
ETSI, WhitePaper No. 24 , February 2018.[5] “ETSI GS MEC 002 v2.1.1. Multi-access Edge Computing (MEC); Phase 2: Use Cases andRequirements,” October 2018.[6] S. Kekki, W. Featherstone, Y. Fang, P. Kuure, A. Li, A. Ranjan, D. Purkayastha, F. Jiangping,D. Frydman, G. Verin, K.-W. Wen, K. Kim, R. Arora, A. Odgers, L. M. Contreras, andS. Scarpina, “MEC in 5G networks,”
ETSI, White Paper No. 28 , June 2018.[7] A. Osseiran, F. Boccardi, V. Braun, K. Kusume, P. Marsch, M. Maternia, O. Queseth,M. Schellmann, H. Schotten, H. Taoka et al. , “Scenarios for 5G mobile and wireless com- unications: the vision of the METIS project,” IEEE Communications Magazine , vol. 52,no. 5, pp. 26–35, 2014.[8] 3GPP, “System Architecture for the 5G System; Stage 2 (Release 15),” 3rd Generation Part-nership Project (3GPP), Technical Specification (TS) 23.501, 12 2018, version 15.4.0. [Online].Available: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144[9] D. Sabella, A. Vaillant, P. Kuure, U. Rauschenbach, and F. Giust, “Mobile-Edge Comput-ing architecture: The role of MEC in the Internet of Things,”
IEEE Consumer ElectronicsMagazine , vol. 5, no. 4, pp. 84–91, 2016.[10] L. Peterson, A. Al-Shabibi, T. Anshutz, S. Baker, A. Bavier, S. Das, J. Hart, G. Palukar, andW. Snow, “Central office re-architected as a data center,”
IEEE Communications Magazine
IEEE Communications Magazine , vol. 53,no. 2, pp. 107–115, 2015.[15] J. Heinonen, T. Partti, M. Kallio, K. Lappalainen, H. Flinck, and J. Hillo, “Dynamic tunnelswitching for SDN-based cellular core networks,” in
Proceedings of the 4th workshop on Allthings cellular: operations, applications, & challenges . ACM, 2014, pp. 27–32.[16] V.-G. Nguyen, A. Brunstrom, K.-J. Grinnemo, and J. Taheri, “SDN/NFV-based mobile packetcore network architectures: a survey,”
IEEE Communications Surveys & Tutorials , vol. 19,no. 3, pp. 1567–1602, 2017.[17] A. Zabala, E. Rojas, J. M. Roldan, and L. Pulido, “Towards per-user flexible management in5G,” arXiv preprint arXiv:1801.08191 , 2018.[18] “GTP-U tunnel support: OvS kernel module extension.” [Online]. Available: https://github.com/pa5h1nh0/GTP-U_OvS-kernel-extension[19] M. Simsek, A. Aijaz, M. Dohler, J. Sachs, and G. Fettweis, “The 5G-enabled tactile internet:Applications, requirements, and architecture,” in
Wireless Communications and NetworkingConference (WCNC), 2016 IEEE . IEEE, 2016, pp. 1–6.[20] J. Prados-Garzon, J. J. Ramos-Munoz, P. Ameigeiras, P. Andres-Maldonado, and J. M. Lopez-Soler, “Latency evaluation of a virtualized MME,” in
Wireless Days (WD), 2016 . IEEE, 2016,pp. 1–3.
21] G. Premsankar, K. Ahokas, and S. Luukkainen, “Design and implementation of a distributedmobility management entity on OpenStack,” in
Cloud Computing Technology and Science(CloudCom), 2015 IEEE 7th International Conference on . IEEE, 2015, pp. 487–490.[22] A. Banerjee, R. Mahindra, K. Sundaresan, S. Kasera, K. Van der Merwe, and S. Rangarajan,“Scaling the LTE control-plane for future mobile access,” in
Proceedings of the 11th ACMConference on Emerging Networking Experiments and Technologies . ACM, 2015, p. 19.[23] A. Machen, S. Wang, K. K. Leung, B. J. Ko, and T. Salonidis, “Live service migration inMobile Edge Clouds,”
IEEE Wireless Communications , vol. 25, no. 1, pp. 140–147, 2018.[24] E. Cau, M. Corici, P. Bellavista, L. Foschini, G. Carella, A. Edmonds, and T. M. Bohnert,“Efficient exploitation of Mobile Edge Computing for virtualized 5G in EPC architectures,” in
Mobile Cloud Computing, Services, and Engineering (MobileCloud), 2016 4th IEEE Interna-tional Conference on . IEEE, 2016, pp. 100–109.[25] N. Nikaein, X. Vasilakos, and A. Huang, “LL-MEC: Enabling low latency edgeapplications,” in
CLOUDNET 2018, IEEE International Conference on Cloud Networking,22-24 October 2018, Tokyo, Japan
Proceedings of the 1st ACMSIGCOMM Symposium on Software Defined Networking Research . ACM, 2015, p. 25.. ACM, 2015, p. 25.