Mobile Netw Appl (2015) 20:337–347 DOI 10.1007/s11036-015-0616-1
Software Defined Mobile Cloudlet Lingxia Liao1 · Meikang Qiu2 · Victor C. M. Leung1
Published online: 20 May 2015 © Springer Science+Business Media New York 2015
Abstract Using cloudlets in mobile networks mitigates the resource limitation of mobile devices to process the applications with rich media content and highly interaction. However, this approach changes the original traffic routing path of mobile networks and causes integration complexity that cannot be easily solved without modifying the current mobile network elements and routing policies over current IP transport network. OpenFlow based SDN architecture can use its centralized control plane to oversee its data paths and enable flexible traffic routing. Combining SDN to cloudlets creates possibilities to reduce this complexity. In this article, we propose a novel SDN based cloudlet approach that deploys cloudlets in a Mobile Telephone Switch Office, where a SDN based transport network that supports an enhanced OpenFlow 1.3 protocol is enabled. With this enhanced OpenFlow 1.3 protocol, each switch/ router and controller within this transport network can extract the source IP of a user packet encapsulated by a GTP header, so that the user packets from a particular remote
Lingxia Liao
[email protected] Meikang Qiu
[email protected] Victor C. M. Leung
[email protected] 1
Department of Electrical and Computer Engineering, University of British Columbia, Vancouver, BC, Canada
2
Department of Computer Science, Pace University, New York, NY, USA
mobile service front end can be identified and redirected to a local cloudlet without modifying the existing mobile network elements and routing paths. A proof-of-concept prototype is provided, and its functionality and performance is evaluated over a small test bed emulated by Mininet. Keywords SDN · Cloudlet · Mobile cloud computing
1 Introduction As new mobile devices developing, the use of rich media content and highly interactive mobile applications over mobile devices has been a trend in recent years. These contents and applications have very different way to generate traffic and interact with the network from current voice service, and hence cause significant overhead on mobile devices and lead to inefficient resource usage and high latencies over current mobile transport network. Mobile Cloud Computing (MCC) is a concept in presence of Cloud Computing(CC). Its goal is to provide computation and storage resource for mobile devices to support such rich media content and highly interactive mobile applications. To achieve it, MCC combines the technologies of CC, the Internet, and mobile computing. A Mobile Cloud (MC) can be built on top of a mobile network and the Internet via MCC technologies. Current mobile networks use standardized specifications to define network elements and maintain the finegrained Quality of Service (QoS) over IP transport network. Because current IP network lacks flexibility, it results in significant integration issue on combining mobile network, Internet, and mobile network. Specifically, simply moving mobile services to a remote cloud can improve the scalability and availability of mobile services, but the network
338
latencies are also increased. This increased network latencies can be mitigated by using local cloudlets to reduce the network distance and offload the work load of mobile devices. However, deploying cloudlets causes a change in packet routing among mobile network elements, which can not be easily resolved over current IP transport network. Present research has proposed many approaches, some of them are focused on developing offloading mechanisms for particular mobile applications to mitigate the resource limitation of mobile devices, and others are focused on building a MC over a fully redesigned mobile network architecture through Network Function Virtualization (NFV) to achieve the flexible network management and routing. To the best of our knowledge, there is hardly an effort on addressing the network management and routing issues without modifying the existing mobile network elements. Software Defined Networking (SDN) is an layered structure with decoupled network control plane and data plane [1]. The control plane is represented as a centralized controller and the data plane is distributed to multiple switches/routers [2]. With OpenFlow protocols [3, 4], the centralized controller generates per-flow based forward flow entries and distributes them to each switch/router, while the switches/routers differentiate flows using flow matching fields and processes them based on the flow entries generated by the controller. The OpenFlow flow matching fields include up to 40 fields covering the major fields from layer 2 to layer 4 headers, which provides primitives for optimized packet routing and QoS management over SDN architecture. Therefore, OpenFlow based SDN can be used to address the integration issue in building a MC via MCC technologies. In this article, we discuss the three possibilities in combining SDN and MCC technologies, and propose a Software Defined Mobile Cloudlet (SDMC) solution, which targets to mitigate the integration issue without redesigning the current mobile network elements and the existing routing paths. The proposed SDMC is used in a Mobile Telephone Switching Office(MTSO), where a SDN based mobile transport network that supports an enhanced OpenFlow 1.3 protocol to differentiate mobile network packets is enabled. We provide a proof-of-concept prototype with implementation details based on CPqD OpenFlow1.3 softswitch [5]. We also evaluate this prototype through a simple test bed emulated by Mininet [6]. The rest of this article is organized as follows: the background such as MCC, EPC, and SDN, are introduced in Section 2; and the multiple ways to combine SDN to MCC are discussed in Section 3; the SDMC is proposed in Section 4, where an enhanced OpenFlow 1.3 and CPqD softswitch are introduced to enable cloudlets without modifying the current mobile network elements and routing
Mobile Netw Appl (2015) 20:337–347
paths; we evaluate the proposed SDMC through a simple test bed in Section 5; and conclusions are drawn in Section 6.
2 Background As MCC combines the CC, mobile computing, and the Internet technology over mobile networks, in the rest of this section, we introduce the background of MCC, EPC, and SDN. 2.1 MCC MCC is an approach that combines mobile networking, mobile computing, and the Internet technology. It is used to mitigate the resource limitation in processing applications such as image processing, sharing GPS/Internet data, multimedia search, social networking, and sensor data applications. According to the ways how MCs are built, MCC can be categorized into the following three types: [7, 8] •
•
•
Run a mobile service on remote resource rich servers provided by a private data center or a public cloud while the mobile devices act as thin clients connecting to the remote servers through mobile network. For example: Goole’s Gmail for mobile, Facebook’s location services, and Twitter for mobiles. Construct a mobile cloud themselves through peer-topeer networking to share resource to the other devices within the same mobile cloud. This approach makes each mobile device be the resource providers as well as the resource consumers. The peer-to-peer mechanism is adopted for self-organizing. This type of MC can be an inter-operable local component system with ability to support user mobility and sensor information collecting. Offloading jobs to local mobile resources is still opened. Use cloudlets to offload workload. Cloudlets are comprised of several local computers that connect to the remote mobile application servers, so that mobile devices can connect or function as a thin client to the cloudlets, and the cloudlets delegate mobile devices to connect to the remote servers to reduce delay and bandwidth limitations.
The first type of MCC moves mobile services from local servers to remote virtual servers, which increases the application scalability and availability but leads to longer network latencies caused by the increased distance between mobile devices and mobile service servers. Running a mobile service on remote virtual servers are suitable for those latency-insensitive applications such as mobile emailing and mobile social networking, but cannot meet the
Mobile Netw Appl (2015) 20:337–347
requirements of rich content or highly interactive applications [9]. Running such kind of applications on remote virtual servers has to leverage the third type of MCC approach, cloudlets, to offload the work load of mobile devices and reduce the distance between mobile devices and mobile services. However, cloudlets have to be integrated to mobile network, which changes the existing mobile network architecture and routing path. Therefore, it results in significant integration complexity. The second type of MCC is a mobile cloud that mobile devices are resource providers as well as resource consumers. Although mobile devices can be connected by using current mobile network, wireless network, or peer-to-peer network, running mobile services on multiple mobile devices is very challenging since mobile device operation systems are closed and no general protocols can be used for a mobile device to access to the resources of another mobile device presently. 2.2 LTE/EPC Mobile network uses standardized specifications to define, organize, and manage its network elements with guaranteed QoS for voice service as well as data services. Current mobile services can run on virtual machines located in remote clouds and mobile devices can access to them through the Internet. The Long Term Evolution (LTE) / Evolved Packet Core (EPC) is one of the mobile networks providing such kind of functionality [10]. LTE/EPC is a fullIP system, as shown in Fig. 1, its packet system consists of three components: the User Equipment (UE), the Radio Access Network (RAN), and the EPC Network. LTE RAN consists of the enhanced NodeB (eNodeB) while the EPC packet core consists of the MME, the Serving Gateway (SGW), the Packet Data Network Gateway(P-GW), and the Home Subscriber Server(HSS). •
•
•
ENodeBs are the base stations, which communicate with UEs via the radio link and forward user packets to a S-GW as well as manage radio resource and mobility through cooperating with the MME. MME is the control plane of EPC. It is responsible for user authentication by interacting with the HSS and manages mobility conditions such as roaming, paging, an handovers. It also assigns S-GW to each request and interacts with S-GW for data session establishment/release. S-GW and P-GW are the data paths of EPC. Their main functions are to route/forward packets. They also support traffic accounting and policy enforcement. A S-GW is the mobility anchor point for roaming users during inter-mobility handovers and decides which PGW serves the user. A S-GW is also responsible for routing and forwarding user data packets from and
339
•
to the eNodeB. A P-GW is the gateway to route the packets to the Internet. HSS is the central user information database. It provides information about user authentication and authorization for different network functions.
LTE/EPC uses the concept of bearer to maintain the traffic priority and QoS between an UE and a P-GW. LET/EPC defines two types of bearers, default bearer and dedicated bearer. A default bearer is created when a UE attaches to the network for signaling or other traffic without Guaranteed Bandwidth Rate(GBR), while a dedicated bearer with GBR specific is setup if an UE requires. Dedicated bearers have priority over the default bearers. LTE/EPC uses GPRS Tunneling Protocol(GTP) [11] to map bearers and route packets among core components. The data path from an UE to the Internet consists of two GTP tunnels - one is between an eNodeB and a S-GW and the other is between a S-GW and a P-GW. An user data (IP) packet from an UE is sent to a eNodeB via the RAN, where it is encapsulated in a GTP header and sent to a S-GW. The S-GW, in turn, extracts the original IP packet and encapsulates it again in another GTP header to send it to a P-GW. The P-GW decapsulates the original IP packet and sends it to the public Internet.The reverse traffic from the Internet follows the same path back to the UE via the P-GW, the S-GW, and the eNodeB. As illuatrated in Fig. 2a, LET/EPC uses GTP to encapsulate mobile signaling packets and user packets. GTP packets run on top of UDP with registered destination port numbers. Therefore, LTE/EPC transport network can use IP address to route the GTP packets among core network elements. However, the traffic from P-GW to the Internet is the user IP packets, the QoS capabilities carried by bearers in GTP packets are lost. When we move mobile services from local servers to virtual machines in a remote cloud to increase scalability, the QoS can be significantly affected over current Internet. This is how cloudlets should be used to address the QoS issues. 2.3 SDN The Software Defined Networking (SDN) architecture is a layered network architecture, as illustrated in Fig. 2b. It consists of a centralized control plane and a distributed data plane [1, 2]. The control plane maintains network-wide dynamics and enables network-wide management. It also provides northbound Application Programming Interfaces (APIs) for implementing third-party applications and southbound protocols for overseeing the data plane. The data plane consists of multiple switches or routers that proceed simple flow forwarding or routing based on flow entries generated by the control plane.
340
Mobile Netw Appl (2015) 20:337–347
Fig. 1 Standard LTE/EPC architecture
OpenFlow is a southbound protocol, which defines data structures, messages, and procedures to describe all the physical and logical elements within a data path. A controller uses OpenFlow to communicate with its switchs/ routers to maintain network topologies, setup new flows, and collect network-wide statistics, while a switch/router uses OpenFlow to differentiate flows and forward them based on flow entries. Flow entries are generated by controllers when they received packet-in messages sent by a switch/router for new flow entry setups [3, 4]. Flow entries include a flow matching data structure that consists of up to 40 flow matching fields from layer 2 to layer 4 to differentiate flows. Flow entries also include a set of instructions that are executed when a packet finds its matched flow entry and gets forwarded. These instructions consist of a set of actions, for example: popping or pushing a field, configuring QoS actions, modifying a field, and setting an output port. Executing of these actions leads to a packet modification or pipeline processing. These flow
Fig. 2 The GTP protocol stack and the architecture of SDN
entries can be used to provide fine-grained QoS management and flexible routing as well as flow forwarding.
3 Combine SDN to MCC As illustrated in Section 2, a MC can be presented as a remote cloud, a local mobile cloud, or a local cloudlet. In the rest of this section, we apply SDN technology to each of these three MCs, and discuss their potential benefits and problems. 3.1 Apply SDN in remote cloud Moving mobile services from local servers to remote virtual machines within a cloud with elastic computation and storage resources allows mobile services to support more mobile devices with higher availability. However, the distance between the mobile service servers and mobile
Mobile Netw Appl (2015) 20:337–347
devices is increased, which causes longer network latency and affects the mobile user experience when running content rich and highly interactive applications over current IP network [9]. This increased network latency can be mitigated through deploying cloudlets or enforcing QoS routing over the Internet. The former reduces the physical distance between a mobile service server and its users while the latter reduces the network latencies through optimizing the routing path. We discuss the latter in the rest of this subsection and leave the former to be analyzed in the next subsection. Current IP network support IntServ [12] and DiffServ [13] QoS management models. IntServ physically reserves network resources for each flow and manages reservation states in each network node through a resource reservation protocol. Therefore, it provides QoS with strict bandwidth guarantees but not scalable. DiffServ uses DS field to aggregate packets. With packets classified at network boundary and packets forwarded based on DS field at network core, DiffServ provides simple but scalable coarse-grained QoS management. However, current distributed hop-by-hop routing network architecture lacks a global network picture, which causes huge complexity in QoS configuration and reconfiguration for both IntServ and DiffServ models. Therefore, current there is no practical QoS solution proposed in both research and industry. However, OpenFlow based SDN provides fine-grained flow differentiation and centralized network management, which can be used for fined-grained QoS management. Specifically, OpenFlow protocols provide the following built-in mechanisms for QoS management: • • •
Have up to 40 flow matching fields for flow differentiating. Support bandwidth guarantee queues and enqueue actions for matching a flow to a port with bandwidth guaranteed queues attached. Maintain real-time global network view to enable network-wide routing path and queue assignment optimization.
Therefore, OpenFlow based SDN architecture can use its centralized control plane to collect the real time network dynamics, based on which, the controller calculates per-flow based routing path to provide QoS capabilities. OpenFlow based SDN architecture supports DiffServ based fine-grained QoS management with centralized QoS configuration and reconfiguration. Current research has proposed many solutions to provide fine-grained QoS over OpenFlow based SDN infrastructure through QoS routing, where bandwidth, delay, and packet loss are considered for path optimization [14–17]. However, the end-to-end delay estimation remains challenging and the overall network throughput under QoS routing is the major concern in this research area [15, 16].
341
3.2 Apply SDN in local mobile cloud Mobile devices themselves can be organized to form a mobile cloud. This connected collection of mobile devices creates a distributed computational environment for mobile applications. To enable such a MC, we need to address two issues: device connecting and resource sharing. Currently, there are three ways to enable the connection of mobile devices: base stations (eNodeBs in LTE/EPC), WiFi, and peer-to-peer. A base station is a basic element of mobile RAN to connect a mobile device to a mobile network; WiFi uses access points to connect mobile devices as well as laptops and computers; and peer-to-peer facilitates a self-organized network without employing any other infrastructure. Resource sharing assures a mobile application to run on multiple devices within this connected network. Therefore, the way that mobile devices uses to connect may affect how the resources are shared. Currently, there is no approaches proposed to enable resource sharing through base station and WiFi. However, some literatures propose peer-to-peer based information sharing [18, 20, 21] using inter-operable local components [19]. Offloading workload to local MC is still opened in this research area. Applying SDN in local mobile cloud is a new research problem that has not been deeply studied currently. Present research has proposed some approaches to build software defined WiFi [22], software defined mobile RAN [23], or software defined mobile core network [24, 25]. However, all of them target to provide centralized or flexible network-wide management, no resource or information sharing mechanism has been provided. To facilitate distributed mobile service, current software defined WiFi or RAN has to be advanced enhanced. This resource sharing mechanism can be mobile service dependent, this dependency results in complex application implementation and network management. Since peer-to-peer mobile network doesn’t need extra network infrastructure, SDN technology cannot be applied over it. 3.3 Apply SDN in local cloudlet Cloudlets are several local computers to offload the jobs of mobile devices. These local computers have more computation and storage resources with connectivity to the mobile application servers located in a remote cloud. Current study is focused on the cloudlet middle-ware architecture, for example, reference [26] introduces VM based cloudlets and reference [27] and [28] propose component based cloudlets. Cloudlets and mobile service servers can access to the Internet via satellites [29] or WiFi [26–28]. However, satellites are expensive while WiFi has limited coverage. This limited coverage causes big issue in cloudlets deployment and
342
placement. Placing cloudlets in mobile RAN also has been investigated in current research [31]. This approach puts cloudlets in a Mobile Telephone Switching Office(MTSO) that covers a large geographical area and has wide bandwidth to connect the core network, so that each mobile device inside this area can use cloudlets with reduced network latencies. However, this approach change the original routing path where cloudlets are not applied. Developing a new routing path to enable cloudlets located in MTSO network can cause traffic redirection and function modification in MME, S-GW, and P-GW of EPC, which cannot be easily resolved without significantly enhancing the existing Mobile RAN elements. Running cloudlets over SDN architecture generates a big benefit that uses OpenFlow controller to manage the new routing path. However, current research on combining SDN and mobile network intends to use Network Function Virtualization technology to virtualize mobile core network elements and integrate them to a controller or a switch/router of the SDN [30]. This approach has flexible network management and routing policies to allow cloudlets to be integrated with or without modifying the existing mobile network elements. However, this virtualization is a full redesign of mobile core network, which can be very complicated and hard to be realized. There are also proposals that target to integrate cloudlets without or with miner modification of existing mobile network elements. However, since current OpenFlow based network infrastructure cannot identify the source and destination IP addresses of user IP packets that encapsulated by GTP, OpenFlow middle boxes are used to enforce the offloading policies and manage the packet routing among current core network elements [31]. These middle boxes increase the complexity of mobile network and become a single point of failure in the network. Based on these observations, we propose a SDN based local cloudlet approach, where all the related mobile network elements and original routing paths remain unchanged over SDN transport network that enables an enhanced OpenFlow protocol to identify the inner source IP address encapsulated by a GTP header.
4 SDN based cloudlet architecture As illustrated in Fig. 3, we assume a mobile application splits its functionality into an application front end and an application server engine(cloudlet). The front end is placed in a remote cloud and the cloudlet is placed in a local MTSO with connection to the front end through the Internet. The front end receives the user requests and redirects them to the local cloudlet to process the user requests locally. Our proposed approach uses SDN infrastructure to form the MTSO transport network, where EPC com-
Mobile Netw Appl (2015) 20:337–347
ponents and the cloudlet are connected through OpenFlow switches/routers, and an OpenFlow controller is used to supervise all the switches/routers within MTSO transport network. Instead of using virtualized network functions to redesign the core network elements or using OpenFlow middle boxes to modify the routing path of user packets in current approaches, our approach uses OpenFlow switchs/routers to inspect, modify, and redirect packets, and hence enforce the offloading policies without modifying the existing EPC elements and routing paths. Since the cloudlets only affect the traffic routing in user downlink traffic, where the packets from the remote mobile front end first come to the P-GW, then they are encapsulated by GTP headers and redirected to the cloudlet before reach the S-GW. In order to make this redirection work without modifying the existing EPC elements and routing paths, we need to do two things, 1) redirect packets from the P-GW to the cloudlet to offload the work; and 2) modify the packets from the cloudlet to the S-GW to pretend that they are directly sent from the P-GW. To achieve it, we have to inspect the inner IP packet that is encapsulated by a GTP-U header. If the inner source IP address matches the IP address of the mobile service front end, the OpenFlow switch enforces the redirecting and packet header modification; if not, the OpenFlowswitch follows the original routing path of the mobile network without the cloudlet to forward them to the S-GW directly. Since OpenFlow based SDN architecture has a centralized control plane, which can oversee all the data paths within the network, the traffic routing/forwarding among data paths is controlled by flow entries generated by the control plane and loaded to each data path. Because our proposed approach has to differentiate packets with particular inner IP address while current OpenFlow protocols do not support GTP protocol and inner IP header decoding, we need to enhance the current OpenFlow 1.3 protocol and enable them in both switches/routers and controllers, so that each switch/router can differentiate flows using the inner source IP address(it is in the user IP packet encapsulated by a GTP header), lookup and execute their flow entries that are generated by the controller for packet redirecting and header modifying. With this enhanced OpenFlow 1.3 protocol supported by controllers and switches/routers, our approach can mitigate the routing issue of current cloudlet approaches without modifying current EPC elements and routing paths. In another word, our proposed SDN based cloudlet architecture can deploy a cloudlet in a MTSO, where existing LET/EPC core network elements (without any functionality and routing modification) and the cloudlet run over a SDN based transport network that supports enhanced OpenFlow 1.3 for GTP traffic and inner source IP extracting.
Mobile Netw Appl (2015) 20:337–347
343
Fig. 3 SDN based cloudlet architecture
5 Prototyping We use CPqD OpenFlow1.3 softswitch to prototype the redirecting and header modifying mechanism. In the rest of this section, we first analysis the GTP-U stack, then enhance the OpenFlow 1.3 protocol to support the inner source IP extracting and header modifying, and finally introduce the implementation details in enhancing the OpenFlow 1.3 softswitch. 5.1 GTP-U stack GTP protocol has three flavors, GTP-U, GTP-C, and GTP’. GTP-U tunnels user IP packets between an eNodeB and a P-GW in LTE/EPC; GTP-C is used in the control plane of mobile core network, where S-GW and P-GW nodes are not participated; and GTP’ is for accounting. Our approach affects the GTP-U traffic, which runs on top of UDP with registered destination port number of 2152. A GTP-U packet has a protocol stack as illustrated in Fig. 2a, and can be identified using outer source ip, outer destination ip, udp port number, and tunnel end port identification. The header of GTP-U consists of a field named message type. It is set to 255 means a user IP header is followed. The inner IP addresses are located in this user IP header. 5.2 Enhanced OpenFlow 1.3 To find out the flows that are sent by a remote mobile front end, our switches and controllers have to be able to extract the source IP address from an inner IP packet encapsulated by a GTP-U header. Since current OpenFlow 1.3 protocol does not support to extract fields from inner IP packets, we add GTP-U MSGTYPE, GTP-U IP SRC, and GTP-U IP DST fields to its flow matching fields as shown in Table 1. We need to slightly modify the related .h and .c files in
CPqD OpenFlow 1.3 softswitch source code to enable the GTP packet decoding and flow entry lookup. 5.3 Enhanced OpenFlow switch/router CPqD OpenFlow1.3 softswitch [5] is an open sourced OpenFlow user base soft switch, it supports OpenFlow 1.3 and has a local control tool, dpctl, which can generate flow entries for CPqD switch locally. Since LTE/EPC encapsulates user packet traffic between an eNodeB and a P-GW through GTP-U, and transfers GTP-U through UDP, IP address is used to route these traffic over our SDN transport network infrastructure. The flow entries for the user uplink traffic between an eNodeB and a P-G and for the user down link traffic between an eNodeB and a S-GW only need to use outer source and destination IP addresses to differentiate packets, while the flow entries for those downlink traffic between a P-GW and a S-GW have to include outer source and destination IPs, IP protocol number, UDP destination port number, inner source IP address in their matching fields. CPqD OpenFlow 1.3 softswitch uses a xml based network protocol database, NETPDL.XML [32], to describe protocol stack and adopts NETBEE [33] library to parse network packet. Since the latest NETPDL.XML network database does not support GTP protocol, we have to modify the NETPDL.XML database as well as the packet parsing functions and OpenFlow 1.3 library in OpenFlow 1.3 softswitch source code to support the inner IP differentiation. As shown in Fig. 4, we develop a new protocol named GTP and link it to UDP through checking the UDP destination port number in NETPDL.XML, if it is 2152, then the next header is GTP. To link an inner IP header to a GTP header, we let NETPDL.XML to check the message type field in a GTP header, if it is 255, then the next header is a user IP header.
344
Mobile Netw Appl (2015) 20:337–347
Table 1 Extended match field Field
Bits
Mask
Pre-requisite
Description
OFPXMT OF GTPU MSGTYPE OFPXMT OFB GTPU IP SRC OFPXMT OFB GTPU IP DST
8 32 32
yes no no
UDP DST=2152 GTPU MSGTYPE=255 GTPU MSGTYPE=255
The message type of GTP-U The source IP address of user IP packet The destination IP address of user IP packet
NETBEE library provides packet reader and decoder functions to extract fields defined in NETPDL.XML database from a packet. Current OpenFlow 1.3 softswitch implementation uses NETBEE library to first extract all matching fields that are defined in OpenFlow 1.3 matching fields, then to lookup a matched flow entry table by table. The inner source and destination IP addresses can be extracted from a packet through slightly modifying the existing NETBEE library. For the down link traffic from a P-GW to a S-GW, our switch needs to 1) redirect it to the cloudlet and 2) modify the packet headers from the cloudlet to make sure the outer IP header is carefully configured for routing and processing without modifying the current EPC elements and routing paths (we assume that the GTP-U header and inner IP header are correctly packeted by the cloudlet). Instead of using a remote controller to generate flow entries for each switch/router, we use dpctl tool of CPqD softswitch to generate the flow entries locally. Assuming the IP address of the P-GW, the Cloudlet, and the S-GW are 10.0.0.1, 10.0.0.2, and 10.0.0.3, and the IP address of the mobile front end is 10.10.10.10; and the P-GW uses port 1,
Fig. 4 NETPDL xml file with GTP protocol
the S-GW uses port 3, and the Cloudlet uses port 2 to connect to a switch. We can use the following commands to generate the flow entries for the user down-link traffic: •
•
•
for the packets that from the P-GW(generated by mobile front end) to the S-GW, we use the command: dpctl unix:/var/run/s1.sock flow-mod cmd=add,table=0,idle=5,hard=300,prio=2048 eth type=0x800,ip src=10.0.0.1, ip dst=10.0.0.3, udp src=2152, gtpumsgtype=255, innersrcip=10.10.10.10 apply: set field=ip dst:10.0.0.2, output=2 for the packets that from the P-GW(generated not by mobile front end) to the S-GW, we use the command: dpctl unix:/var/run/s1.sock flow-mod cmd=add,table=0, idle=5, hard=300, prio=2048, eth type=0x800, ip src=10.0.0.1, ip dst=10.0.0.3 apply: output=3 for the packets that from the cloudlet to the S-GW, we use the command: dpctl unix:/var/run/s1.sock flowmod cmd=add,table=0,idle=5,hard=300,prio=2048 eth type=0x800,ip src=10.0.0.2, ip dst=10.0.0.3 apply:set field=ip src:10.0.0.1, output=3
Mobile Netw Appl (2015) 20:337–347
It is apparent that the first command processes the route redirection and header modification for the traffic from the P-GW to the S-GW with inner source IP matching the remote mobile service front end; the second command processes the original routing for those traffic not sent from the remote mobile service front end to the S-GW via the P-GW; and the third one processes the header modification through rewriting the outer source ip from the cloudlet to the P-GW. This way, we address the cloudlet redirecting issue using Openflow switches without modifying the current EPC elements and routing paths.
6 Evaluation Since the extraction of inner IP address and modification of outer IP address are the key of our SDN based cloudlet solution, we test its functionality and performance in the rest of this section through a simple test bed emulated by Mininet. Our test bed runs on a Virutalbox virtual machine with Ubuntu12.04 OS, and it consists of an OpenFlow switch and three hosts. We run CPqD OpenFlow1.3 softswitch at the switch node, and a GTP packet generator at host1 (P-GW), a GTP packet relay at host2 (cloudlet), and a GTP packet receiver at host3 (S-GW). To simulate the traffic redirecting and header modifying in our proposed SDN based cloudlet solution, we let the GTP packet generator at host1 to generate GTP packets with particular inner source IP address(10.10.10.10) and send them to host3. When the traffic from host 1 arrives at the switch, it extracts the inner source IP and matches it to 10.10.10.10. If the inner source IP is matched, the switch modifies the packet’s outer destination IP address to host2 and forwards the packet to host2, otherwise forwards it to host3 without packet modifying. When the GTP packet relay at host2 receives the packet, it packs this packet with
Fig. 5 Wireshark packet screenshots in our test bed
345
a new outer IP header and sent to host3. When this packet arrives at the switch, the switch modifies its outer source IP from host2 to host1 and send to host3. Figure 5 shows a packet sent from host1(10.0.0.1) to host3(10.0.0.3). It is received by host2 and resent by host2 to host3. When this packet first arrives at the switch from host1, the switch modifies its destination IP address to 10.0.0.2 but remains its destination MAC address unchanged and sends it to host2. Therefore, the packet received by host2 has the destination IP address as 10.0.0.2 and the MAC address as 00:00:00:00:00:03 (the MAC address of host3). When this packet secondly arrives at the switch from host2, the switch modifies its source IP address to 10.0.0.1 to pretend it being sent by host1. Therefore, the packet received by host3 has source IP address as 10.0.0.1 but source MAC address as 00:00:00:00:00:02(the MAC address of host2). It is apparent that the switch redirects the packet to the host2 (the cloudlet) without modifying the current packet generator, relay, and receiver, which means the OpenFlow switch with enhanced OpenFlow 1.3 protocol and inner IP header decoding can enforce the new routing path without modifying the current EPC elements and existing routing path among them. Since the enhanced OpenFlow 1.3 protocol increases the overhead of an OpenFlow switch for parsing and matching a GTP packet, we also test the flow process delay of our enhanced CPqD OpenFlow1.3 softswitch. We use the same test bed and record the time cost for host1 to send a GTP packet to and receive the response packet from host 3. We consider two network databases, one is with GTP and the other is not. We use two packet forwarding methods, one is flow matching and the other is traditional forwarding based on MAC learning. For each test scenario, we test 10 times and each time we let host1 sends and receives 10000 packets and calculate the average time cost for each packet sending and receiving. Since the process that host1 sends a packet
346
Mobile Netw Appl (2015) 20:337–347
Fig. 6 time cost for a switch to process a GTP packet
and receives its response triggers the switch twice, we use half of the average time cost for host1 to send a packet and receive its response to represent the time cost for a switch to process a GTP packet. Figure 6 shows the average time cost for our CPqD switch to process a packet under each test scenario. It is apparent that the time cost for a switch to process a GTP packet when using a network database with GTP support is larger than the one when using network database without GTP support, and the time cost for a switch to lookup a flow entry increases when more matching fields need to be matched in a flow entry. Using a network database with GTP support causes at least two more headers decoding (a GTP packet with a user IP packet encapsulated), which consumes switch CPU resource; and matching a flow entry with more matching fields costs more loops in CPqD softswitch implementation. Although the absolute value of the time cost in our testing can be significantly reduced by using core base soft switch such as Open Virtual Switch running on a high configured computer, and our emulated test bed is not accurate enough for a performance testing, our test demonstrates the packet decoding and flow matching are two key factors that affect the packet forwarding rate of an OpenFlow soft switch. Although a physical OpenFlow switch can use Ternary Content Addressable Memory(TCAM) to accelerate the flow matching performance, the packet decoding has to be done by switch software and decoding a packet with more headers costs more CPU time, and hence decreases the packet forwarding rate of a switch. In practice, we should carefully develop the network database and packet decoding functions to avoid decoding unnecessary headers.
7 Conclusions and future work This article introduces a novel SDN based cloudlet approach to mitigate the integration complexity in current cloudlet
solutions. It uses an enhanced OpenFlow 1.3 protocol to extract the source IP address of an inner IP packet encapsulated by a GTP header. Through enabling this enhancement in each switch/router and controller within our SDN based mobile transport network, the traffic from a remote mobile service front end can be redirected to a local cloudlet located in a MTSO without modifying the existing mobile network core elements and routing paths; and the traffic from the cloudlet can be modified to pretend being sent by the PGW, so that the S-GW can process the packets correctly without modifying the functionality of the existing mobile core network elements. It also analyzes the possibilities to combine SDN to MCC, and develops a proof-of-concept prototype of our proposed SDN based cloudlet approach. We also evaluate the functionality and performance of this prototype through a simple test environment emulated by Mininet. The test results show the traffic redirecting can be realized in an CPqD softswitch without modifying the existing LTE/EPC elements and routing path, but the CPqD softswitch has a decreased packet forwarding rate caused by GTP packet decoding and flow matching. Our approach should be advanced tested over an fully functional EPC network with core base softswitch or physical switch in our future research. Acknowledgments This research work is supported by the Canadian Natural Sciences and Engineering Research Council through grant STPGP 447230. Prof. M. Qiu is supported by NSF 1457506, USA.
References 1. Open Data Center Alliance. Open Data Center Alliance Master Usage Model: Software Defined Networking Rev 1.0, Internet: http://www.opendatacenteralliance.org/docs/Software DefinedNetworkingMasterUsageModelRev1.0.pdf 2. Open Networking Foundation. Software-Defined Networking: The New Norm for Networks. White paper. April 13, 2012. Retrieved August 22, 2014
Mobile Netw Appl (2015) 20:337–347 3. OpenFlow Switch Consortium. OpenFlow Switch Specification Version 1.0. 0. (2009). Internet: archive.OpenFlow. org/documents/OpenFlow-spec-v1.0.0.pdf 4. OpenFlow Switch Consortium. OpenFlow Switch Specification, version 1.3.0 (2012). Internet: https://www.opennetworking. org/images/stories/downloads/sdn-resources/onf-specifications/ OpenFlow/OpenFlow-spec-v1.3.0.pdf 5. CPqD, OpenFlow 1.3 software switch, Internet: https://github. com/CPqD/ofsoftswitch13OpenFlow-13-software-switch 6. Lantz B, Heller B, McKeown N (2010) A network in a laptop: rapid prototyping for software-defined networks. In: Proceedings of the 9th ACM SIGCOMM workshop on hot topics in networks. ACM 7. Chen M, Mao S, Liu Y (2014) Big Data: A Survey. ACM/Springer Mobile Networks and Applications 19(2):171–209 8. Chen M, Hao Y, Li Y, Lai C, Wu D (2015) On The Computation Offloading at Ad Hoc Cloudlet: Architecture and Service Models. IEEE Communications 53(3):20–27 9. Hassan MA, Chen S (2012) An investigation of different computing sources for mobile application outsourcing on the road. In: Venkatasubramanian N, Getov V, Steglich S (eds) Mobile wireless middleware, operating systems, and applications. Springer, Heidelberg, pp 153–166 10. Dahlman E, Parkvall S, Skold J (2013) 4G: LTE/LTE-advanced for mobile broadband. Academic Press 11. 3GPP TS 29.281 v10.3.0, General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)(Release 10), 2011-09 12. Braden SSR, Clark D (1994) Integrated services in the internet architecture: an overview, RFC 1633 13. Carlson M, Weiss W, Blake S, Wang Z, Black D, Davies E (1998) An architecture for differentiated services, IETF RFC 2475 14. Civanlar S, Parlakisik M, Tekalp AM, Gorkemli B, Kaytaz B, Onem E (2010) A qos-enabled openflow environment for scalable video streaming. In: IEEE GLOBECOM Workshops (GC Wkshps), 2010. IEEE 15. Kim W, Sharma P, Lee J, Banerjee S, Tourrilhes J, Lee SJ, Yalagandula P (2010) Automated and scalable QoS control for network convergence. Proc INM/WREN 10:1–1 16. Egilmez HE, Dane ST, Gorkemli B, Tekalp AM (2012) Openqos: Openflow controller design and test network for multimedia delivery with quality of service. Proc NEM Summit, Implementing Future Media Internet Towards New Horiz:22–27 17. Sonkoly B, Guly´as A, N´emeth F, Czentye J, Kurucz K, Novak B, Vaszkun G (2012) On qos support to ofelia and openflow. In: European workshop on software defined networking (EWSDN), 2012. IEEE 18. Marinelli EE (2009) Hyrax: cloud computing on mobile devices using MapReduce. Masters Thesis, Carnegie Mellon University 19. Zachariadis S, Mascolo C, Emmerich W (2004) Satin: a component model for mobile self organization. In: Meersman R, Tari Z (eds) On the move to meaningful internet systems 2004: CoopIS, DOA, and ODBASE. Lecture notes in computer sci-
347
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
ence, vol 3291. Springer, Berlin, Heidelberg, pp 1303–1321. doi:10.1007/978-3-540-30469-2-31 Heinemann A, Kangasharju J, Lyardet F, M¨uhlh¨auser M (2003) iclouds-peer-to-peer information sharing in mobile environments. In: Euro-Par 2003 parallel processing. Springer, Berlin Heidelberg, pp 1038–1045 Hoang DB, Chen L (2010) Mobile cloud for assistive healthcare (MoCAsH). In: IEEE Asia-Pacific services computing conference (APSCC), 2010. IEEE Ali-Ahmad H, Cicconetti C, De la Oliva A, Mancuso V, Reddy Sama M, Seite P, Shanmugalingam S (2013) An SDN-based network architecture for extremely dense wireless networks. In: IEEE SDN for future networks and services (SDN4FNS), 2013. IEEE Yang M, Li Y, Jin D, Su L, Ma S, Zeng L (2013) OpenRAN: a software-defined ran architecture via virtualization, In: ACM SIGCOMM computer communication review, vol 43. ACM Kempf J, Johansson B, Pettersson S, Luning H, Nilsson T (2012) Moving the mobile evolved packet core to the cloud. In: IEEE 8th international conference on wireless and mobile computing, networking and communications (WiMob), 2012. IEEE Basta A, Kellerer W, Hoffmann M, Hoffmann K, Schmidt ED (2013) A Virtual SDN-enabled LTE EPC Architecture: a case study for S-/P-Gateways functions. In: IEEE SDN for future networks and services (SDN4FNS), 2013. IEEE Satyanarayanan M, Bahl P, Caceres R, Davies N (2009) The case for VM-based cloudlets in mobile computing. IEEE Pervasive Comput 8:14–23 Cuervo E, Balasubramanian A, Cho D, Wolman A, Saroiu S, Chandra R, Bahl P (2010) Maui, making smartphones last longer with code offload. In: Proceedings of the 8th international conference on mobile systems, applications, and services, MobiSys 2010, pp 49–62 Verbelen T, Simoens P, De Turck F, Dhoedt B (2012) Cloudlets: Bringing the cloud to the mobile user. In: Proceedings of the 3rd ACM workshop on mobile cloud computing & services, MCS 2012 Soyata T, Muraleedharan R, Langdon JH, Funai C, Kwon M, Heinzelman WB (2012) Mobile cloud-based compute/communications infrastructure for battlefield applications. In: SPIE defense, security, and sensing 2009. Modeling and simulation for defense systems and applications VII, vol 8403. SPIE Pentikousis K, Wang Y, Hu W (2013) Mobileflow: toward software-defined mobile networks. IEEE Commun Mag 51(7):44– 53 Banerjee A, Chen X, Erman J, Gopalakrishnan V, Lee S, Van Der Merwe JL (2013) MOCA: a lightweight mobile cloud offloading architecture. In: Proceedings of the 8th ACM international workshop on mobility in the evolving internet architecture. ACM Risso F, Baldi M (2006) NetPDL: an extensible XML-based language for packet header description. Comput Netw 50(5):688– 706 The NetBee Library, Internet: www.nbee.org/doku.php
