Experimental Evaluation of an SDN-basedDistributed Mobility Management Solution

M. Isabel Sanchez∗, Antonio de la Oliva†, and Vincenzo Mancuso†‡∗ SIMULA Research Laboratory, Norway

isabel@simula.no†Universidad Carlos III de Madrid, Spain

aoliva@it.uc3m.es‡IMDEA Networks Institute, Spain

vincenzo.mancuso@imdea.org

Abstract—The current wireless network architecture needs tobe re-thought to support mobility in very dense and hetero-geneous network deployments. We propose and experimentallyevaluate a novel SDN-based architecture which makes use ofDMM concepts to deploy fast, flexible, reliable, and scalablemobility management mechanisms at both local and regionalscopes. Our solution is compatible with existing protocols de-ployed in wireless access and backhaul networks, and is thereforetechnology transparent to the user. Although our architecture isgeneric and can be used with heterogeneous wireless networks,we prove the validity of our approach in a lab prototype, byimplementing our distributed mobility management mechanismon a set of OpenFlow-controlled IEEE 802.11 networks.

I. INTRODUCTION AND MOTIVATION

Recently, mobile users demand on data traffic is increasingdramatically. Operators statistics show that the usage of mobiledata traffic has doubled during the last year, and it is estimatedthat, in three years, mobile data traffic will incur a 13-foldincrease with respect to the traffic level reached in 2012 [1].Mobile and IEEE 802.11 devices are expected to account for55% of such traffic. In view of the expected growth in usersand traffic, wireless network operators are moving towards adense deployment of cellular base-stations and 802.11 accesspoints, so to be able to cope with the demand generated by 7billion people and 7 trillion objects under very heterogeneousand mobile conditions, as stated by the 5G PPP.1

In this framework, mobile multimedia is the next killerapplication, and quality of experience represents the primarymetric for network planning and design. Therefore, there is anurgent need for innovation in wireless networking solutionsto support mobility at unprecedented levels. This includesthe creation of a reliable and energy-efficient wireless mobileinternet architecture.Specifically, to achieve network-wide reli-ability and energy-efficiency in very dense and heterogeneousdeployments, mobility mechanisms have to be distributed,flexible, and scalable. In fact, mobility mechanisms cannot becentralized, otherwise reliability would suffer the well knownsingle point of failure issue; they cannot be rigid, otherwisethey would not allow for time- and traffic-dependent energy

1The 5G-Infrastructure-PPP is a joint initiative between the European ICTindustry and the European Commission. For more details consult the officialwebpage at http://5g-ppp.eu/

optimization; and they cannot be unscalable, otherwise archi-tecture and mobile mechanisms would not be of any practicaluse in dense networks of realistic size. Therefore, the solutionfor mobility management in future dense and heterogenous net-works requires distributed monitoring and control mechanisms,to implement dynamic network optimizations in a scalablemanner. Moreover, to reduce costs, a novel architecture shouldbe designed to introduce changes incrementally, possibly in away that is transparent to customers.

The Distributed Mobility Management (DMM) paradigm—currently under investigation in IETF [2]—presents most of theaforementioned characteristics, and specifically accounts fordistributed IP flow mobility managed via distributed anchoring.However, DMM does not manage layer-2 mechanisms andlacks control plane mechanisms for updating forwarding rulesdynamically in the various network elements in the backhauland in access networks, e.g., network switches and wirelesspoints of access. In this work, we propose an architecture thatexploits the DMM paradigm in a Software-Defined Network-ing (SDN)-based control framework [3], so that the resultingarchitecture presents all the tools needed to support mobility ina reliable and energy-efficient manner at both protocol layers2 and 3. Indeed, while layer-3 (IP) mobility mechanisms areconvenient for macro-mobility (at a regional scope), we showthat SDN-enabled layer-2 mobility mechanisms yield quitefaster and reliable solutions in the micro-mobility case, i.e.,when the mobility of the terminal is geographically limitedto a district. Here, the district represents an isolated single-technology domain consisting in a dense set of neighboringcells, while a region is the composition of districts, each ofwhich does not necessarily adopt the same wireless technology.In line with the distinction between districts and regions, theproposed architecture presents a two-tier control structure,with local and regional controllers responsible for districts andregions, respectively. Note that, interestingly, both DMM andSDN paradigms reuse existing data-plane protocols and do notaffect the legacy operation of wireless access and backhaultechnologies, so that they can be suitably used to define aroadmap towards a fast but smooth network evolution, whichwould be technologically transparent to the customers.

In this paper we present and experimentally validate adistributed mobility management solution designed to meetthe flexibility requirements of next generation networks. In

particular, we propose a network-based mobility solution,which benefits of flexibility and scalability properties of DMMand SDN. Our solution is transparent to the mobile terminaland provides a two-fold mobility support: first, our solutionsupports fast layer-2 mobility within a district; second, ourproposal includes a DMM-based SDN mobility solution de-signed for the inter-district mobility (layer-3 mobility). Weimplement our mobility management mechanism in IEEE802.11 networks, and demonstrate the very promising featuresof our solution—in terms of mobility support, data path re-configuration, and transparency to the mobile devices—usingthe celebrated OpenFlow protocol [4] to control access pointsand network switches. However, our approach is designedso that it can encompass other technologies (e.g., LTE) andheterogeneous access networks.

The rest of the paper is organized as follows. Section IIintroduces the main technologies in our architecture, which ispresented in Section III. The experimental results are presentedin Section IV. The related work found in the literature isdiscussed in Section V and Section VI concludes the paper.

II. BACKGROUND

In this section we describe the main technologies involvedin our mobility management solution, namely SDN (withOpenFlow) and DMM.

A. SDN and OpenFlow

Software Defined Networking (SDN) has implied aparadigm shift in the network management. The concept ofSDN refers to the dynamic reconfiguration of the functionsof an operational network, without changes in hardware andbasic software of its elements. SDN decouples the data andcontrol planes in the network, relying on an external controllerthat manages the behavior of the network elements. As it isoften linked to OpenFlow, some times these two terms areused as synonyms, but actually, they are not exchangeable.While SDN refers to the concept of decoupling the dataand control planes in the switching elements of the network,OpenFlow is the mechanism that enables the SDN operationby standardizing the communication between switches andcontrollers, which is commonly known in the field as thesouthbound interface. OpenFlow, standardized by the OpenNetworking Foundation2 (ONF), has become the protocolof reference and it has been integrated into a number ofSDN frameworks with wider scope and objectives, includingNetwork Function Virtualization (NFV) (e.g., OpenNaaS3,Project Floodlight4, OpenDaylight5). OpenFlow, currently inits version 1.5.0, can be added to switches, wireless accesspoints and routers and some vendors already commercializeOpenFlow-enabled switches. Each OpenFlow switch maintainsat least one flow table with entries formed by a set of fields tomatch and an action to be performed when there is match.When a data packet does not match any entry, the switchnotifies the controller, which decides how to handle that packet.The flexibility of OpenFlow has led to the implementation of

2https://www.opennetworking.org/index.php3http://www.opennaas.org/4http://www.projectfloodlight.org/5http://www.opendaylight.org/

numerous controllers—e.g., NOX, POX, Ryu, FloodLight—tointeract with OpenFlow switches, developed in a wide rangeof programming languages and supported in many platforms.

B. Distributed Mobility Management

Traditionally, IP mobility management relies on a central-ized mobility anchor, such as the Home Agent (HA) in MIPv6or the LMA in PMIPv6, being that central entity the onethat manages all the bindings. However, such a centralizedarchitecture may encounter scalability and performance issuesas the number of mobile nodes and the volume of data trafficincreases. In order to define a distributed mobility managementmechanism that can adapt the rigid previously existing solu-tions, IETF chartered the DMM working group in 2012 [2].The major difference with respect to traditional IP mobilitymanagement is that DMM distributes the mobility anchoringat the edge of the access network, effectively flattening thenetwork by removing hierarchies. When the mobile nodechanges its point of attachment to the network, the ongoingsessions keep anchored to the previous anchor while the newsessions will be managed by the anchor in the target network.Data traffic is tunneled between both anchors and forwardedto the mobile node, which can deregister from the previousanchor once the ongoing sessions are terminated. Assumingthat most of the sessions are relatively short, most of the datatraffic is routed optimally without tunneling. DMM extendsand adapts already existing IP mobility protocols to facilitatethe networking architecture migration. In our solution, weconsider a PMIPv6 approach together with SDN concepts. Inthis way, the SDN controller manages the binding of a mobilenode that attaches to the network and handles its mobilityby coordinating with the controller in the target domain. Thisapproach enables the controller to modify the data paths so thedata flows are delivered to the actual location of the terminal,without the need of going through a central node, such as theHA or the LMA.

III. ARCHITECTURE

In this section we provide the detailed description of ourarchitecture for distributed mobility management. We proposea network-based mobility solution, which inherits the flexibil-ity and scalability typical of SDN, and which is transparent tothe mobile terminal. Our mobility management architecturerelies on two main entities, the Local Controller (LC) andthe Regional Controller (RC), and provides mobility at twodifferentiated levels, which we present next. In particular, wepresent first the mechanisms enabling fast layer-2 mobilitywithin a domain (the so called district); afterward, we presentthe SDN-based DMM solution designed for the inter-district(regional), layer-3 mobility.

We define a district as an isolated single-technology do-main, similar to the localized mobility domains of ProxyMobile IPv6. A district is composed of a dense deploymentof APs connected together by a switched network of SDN-enabled interconnection nodes (OpenFlow switches). A districtincludes, at least, one gateway (DMM-GW) that connects thedistrict to the Internet and plays a central role in the inter-district mobility solution. In Fig. 1 we present an exampleof the complete architecture with two districts and the flowdiagram for the initial connection of a mobile node (MN)

MN1 LC1Network DMM GW1 CNAP

Association

OF[LLC(Bcast, MAC MN1)]

MN1 already in local BC?

OF[RS]RS

Signalling(MAC MN1)

RA

Compute data path reconfiguration

Reconfigure datapath

NS

NA

Uplink IP data trafficDownlink IP data traffic

OF []: Message encapsulated using OpenFlowRS: IPv6 Router SolicitationRA: IPv6 Router AdvertisementNS: IPv6 Neighbor SolicitationNA: IPv6 Neighbor Advertisement

RC

OF[RA]

Signalling(MN in BC=0)

Assign prefix and DMM-GW

PBU(prefix, MAC MN1, DMM GW1)

PBA

Install prefix on selected DMM-GW

MN1

CN

Internet

DMM-GW1

LC1

DMM-GW2

LC2

RC

Operator Core

Specific Signaling

Fig. 1. Initial attachment.

to the network. In this case, the districts are composed ofIEEE 802.11 Access Points, an OpenFlow-capable backhaulconnecting the APs to the DMM-GW and a local controller(LC). The regional controller (RC) is located at the operatorcore network and coordinates the attachment of a mobileterminal to a district as well as the inter-district mobility.

Upon attachment of the terminal (MN1 in Fig. 1), standardAPs (bridged to a wired network) generate a Logical LinkControl (LLC) message that serves as the mechanism toupdate the forwarding tables in the switched network. Asall the network is OpenFlow capable, this LLC message isencapsulated in an OpenFlow message and sent to LC1. TheLLC message contains the MAC address of the terminal andthe MAC address of the AP. In the case depicted in Fig. 1, LC1

does not have any previous entry of the terminal on its BindingCache (BC)6, hence it has not been previously attached to itscontrolled district. In order to check if the node is alreadyregistered in a previous district, LC1 will contact the RC. Inthis first example, the terminal has not been attached previouslyto any district, so LC1 assigns an IPv6 prefix and a DMM-GWto the terminal, stores this information on its BC and notifiesthe RC about the assigned prefix, DMM-GW and MN identifier(e.g., MAC address). In this way, the RC is able to keep trackof every MN attachment. After successfully attaching to a newnetwork, the standard procedure for the terminal is to send aRouter Solicitation (RS) to configure its IP address using IPv6SLAAC. As in the case of the LLC message, the networkencapsulates the RS message and sends it to LC1. The LCanswers the RS with a Router Advertisement (RA) message,providing the prefix and default router DMM-GW1 selectedbefore. Hence, through the mediation of the LC, hijacking theRA functionality of the network, we are able to control the IPlevel attachment of the terminal within the network. Note that,although we assume the MN sends a RS message every time itattaches to a new point of attachment, in our solution we cantrigger the RA message even if the RS is not sent, which is avery useful feature in case the MN does not completely followthe standard (most Linux boxes do not send RS messagesunless the interface goes down). At this point in time, LC1

is able to compute the required matching rules and data pathmodifications to forward the terminal’s packets to DMM-GW1.These modifications are configured into the network through

6Inherited from PMIPv6, this table stores bindings between terminals andpoints of attachment in our architecture.

MN1

InternetMN1

DMM-GW1

LC1

LC1NetworkDMM GW1 CNNew

APAssociation

OF[LLC(Bcast, MAC MN1)]

If MN1 is already in BC and it has moved, obtain prefix and DMM-GW from

BC

Compute data path reconfiguration

Reconfigure datapath

Uplink IP data traffic

Downlink IP data trafficOF []: Message encapsulated using OpenFlow

CN

Fig. 2. Intra-district handover.

the OpenFlow protocol, requiring several message exchangesamong LC1 and the different switches conforming the pathbetween the terminal and DMM-GW1. Once the data pathis configured, packets originated at the terminal with layer-2destination the DMM-GW are transparently forwarded at layer-2. For the layer-3 stack of the terminal the path to the DMM-GW is a single hop. Finally, after performing a NeighborDiscovery procedure, the terminal is able to exchange packetswith any CN through DMM-GW1.

A. Intra-district Mobility

The intra-district handover is illustrated in Fig. 2, wherethe mobile terminal MN1 attaches to a second AP withinthe same district. In this case the only required change isto modify the data path, so packets are forwarded betweenthe new AP and DMM-GW1. The flow diagram depicted inFig. 2 represents the procedure. The new AP, upon attachmentof MN1, generates an LLC message. Upon reception of thismessage, LC1 is able to notice the movement of the terminallooking up in its BC the MAC address of the AP the terminalwas connected to.7 With this information, the LC is able tocompute the required modifications to the data path for theterminal’s packets. Accordingly, the OpenFlow configurationin the district is modified, and the terminal’s packets willflow from the new AP to the old DMM-GW, i.e., DMM-GW1

(we assess the re-configuration and handover-related delays inSection IV).

The advantages of this approach over traditional layer-2mobility mechanisms are many-fold:

• Through the control of the prefix delegation by thecontroller, the MN can be attached to any of theDMM-GWs in the district, or even to several of themat the same time. This allows a new degree of freedom,since the network can balance the load at the differentexchange points to the Internet.

• The control of the data path, operated by the controller,enables the network to provide fast mobility of theterminal. The data path reconfiguration scales betterwith the number of switches than standard spanningtree approaches, whose reaction time can be measuredin seconds for large networks [5].

7Note that using the MAC address represents just a practical example forterminal identification, although any other kind of terminal identifier could beused instead.

OF []: Message encapsulated using OpenFlowRS: IPv6 Router SolicitationRA: IPv6 Router AdvertisementNS: IPv6 Neighbor SolicitationNA: IPv6 Neighbor Advertisement

MN1

Internet

LC1

DMM-GW2

LC2

RC

Operator Core

Signaling

MN1Handover

SignalingDMM-GW1

MN1 LC2NetworkDMM GW1 CNAP

Association

OF[LLC(Bcast, MAC MN1)]

MN1 already in Local BC?

OF[RS]RS

Signaling(MAC MN1)

RA

Compute data path configuration

Configure datapath

NS

NAUplink IP data traffic

Downlink IP data traffic

RC

OF[RA]

Signaling(MN in BC=1, prefix, DMM GW1)

PBU(prefix, MAC MN1, DMM GW2)

PBA

LC1DMM GW2

Assign prefix to DMM GW, setup tunnelSetup tunnel

IP in IP tunnel

Assign DMM-GW to MN1

Signaling(MN in BC=1, prefix, DMM GW2)

District 1 District 2

CN

Fig. 3. Inter-district handover.

• The algorithm used for controlling the data path canbe arbitrarily complicated, allowing complex trafficengineering operations. The data path forwarding de-cision engine can consider load balancing metrics, oreven complex mechanisms minimizing the number ofnodes requiring changes in their forwarding tables.In addition, we could employ different forwardingdecision engines for different nodes or traffic classes,prioritizing specific metrics, such as delay or availablebandwidth along the path (leveraging the OpenFlowmonitoring capabilities).

• Standard mobile nodes, such as Linux boxes, do notsend Router Solicitation (RS) messages unless theinterface goes down, hence they do not typically do itwhen performing a handover. This forces developersto add the transmission of this RS message or specificattachment-detection traps to the access points. Thisis the case of PMIPv6, for example. By leveragingthe SDN approach, our architecture does not requirethe transmission of the RS message, hence making thedeployment easier than standard PMIPv6 approaches.

B. Inter-district Mobility

Fig. 3 presents the procedure of a handover between twodistricts. This procedure relies on the communication amongLCs being orchestrated by the RC. Basically, the RC behavesas a data-base containing the list of DMM-GWs to be consid-ered while performing a handover. The configuration of the IPlayer on the DMM-GWs and the tunnel setup between them

is handled locally by the LCs in each district. The procedurestarts when the MN attaches to an access point in a differentdistrict. As in the previous cases, this event triggers the LC(LC2) to check if the node is registered on its internal BC. Asthis is the first time the terminal attaches to this district, LC2

asks the RC for previous registrations. In this case, the RC hasinformation regarding the terminal, which is transmitted to theLC2 that choses the DMM-GW to be used within this district(DMM-GW2) and returns this information to the RC. The RCstores this information on its local BC for future reference. Atthis point in time several procedures are performed in parallel.First, the RC informs LC1 of the new location of MN1. Withthis information, LC1 configures DMM-GW1 with an IP-in-IPtunnel connection to DMM-GW2 and changes the routes atDMM-GW1 so that the prefix used by the terminal is routedthrough the tunnel. In parallel, LC2 configures the new prefixin DMM-GW2 and sets up the IP-in-IP tunnel towards DMM-GW1. Once the tunnel is established, the configuration of thedata path in the new network is performed as in previous cases.When all the procedure is complete, packets from the corenetwork to MN1 are forwarded first to DMM-GW1, whichtunnels them to DMM-GW2. After DMM-GW2, the OpenFlowconfigured data path takes care of forwarding the packets tothe appropriate location of MN1 within the district.

The key advantage of this procedure over non-SDN DMMapproaches is the flexibility on selecting the most appropriateDMM-GW to be used for each terminal. Since the LC is ableto decide and attach the prefix used by the terminal to anyof the DMM-GWs available at the district, with our approach,the target network is able to implement any load balancingor complex algorithm to decide the best DMM-GW to use.In addition, the data path forwarding within the district isdecoupled from the layer-3 mobility. In order to minimizethe security implications of this approach, our design enforcesthat the only entity talking with the DMM-GWs belongingto a certain district is the local controller of that district.In such scenario it is possible to think of specific securityassociations between the LC and DMM-GWs of the district.Finally, although we have not implemented or included thisfunctionality in the current design, it is worth highlightingthat the same design can be used to provide IPv4 DMMcapabilities to the network by using the Address ResolutionProtocol (ARP) instead of IPv6 Neighbor Discovery protocol.

IV. IMPLEMENTATION AND EXPERIMENTAL EVALUATION

From Fig. 1, where we present the architecture of oursolution, we can identify the main architectural elements,splitting our testbed into three kinds of entities: i) the regionaland local SDN controllers manage the forwarding rules in theOpenFlow-enabled backhaul and handle the mobility of theMN; ii) the OpenFlow switches, which include, due to thefact that the wireless interfaces in the APs are controlled as innormal OpenFlow switches, both wired backhaul and wirelessaccess network elements; iii) the DMM Gateway, which is theonly entity not related to OpenFlow and acts as the gatewayin the district. Table I gathers the main characteristics of theseelements. Specifically, in our testbed we have two 802.11-OpenFlow enabled APs, an OpenFlow switch, and a DMM-GW in each district. Additionally, each district is managed byits own controller (LC), and LCs are coordinated by a RC.

TABLE I. MAIN HW AND SW CHARACTERISTICS OF THE TESTBEDEntity Device (OS, kernel version) OF-enabled

Switched backhaul Linksys WRT54GL �(OpenWrt Backfire, 2.6.32)

IEEE 802.11 APs Alix 2d3 �DMM-GW (Ubuntu 12.04, 3.2.0) X

Regional and local controllers Desktop (Debian 7.4, 3.2.0) Ryu controller

0

0.2

0.4

0.6

0.8

1

0 0.05 0.1 0.15 0.2 0.25 0.3

F(x)

time (s)

SDN-DMM delay CDF

Intra-district handoverInter-district handover

Fig. 4. CDF of the different handover delays

The OpenFlow signalling is distributed between theswitches and the controllers in an out-band connection. Thewireless access is part of the OpenFlow-enabled network, sothe connection between MN and DMM-GW is a single-hopconnection at network layer (IP). Since the solution worksat layer-3, it is necessary to define new APIs to control theIP layer configuration of the terminal’s session anchor point(DMM-GW). Specifically, we need two new APIs: one toconvey information on the mobile node to the RC, such as theIPv6 prefix and DMM-GW assigned to it, and a second one toconfigure the IP layer of the DMM-GW, the prefixes reachablethrough the interfaces and to setup an IP-in-IP tunnel. We haveimplemented our local and regional controllers using the Ryuframework.8 Ryu provides a comprehensive API that eases thenetwork management. In particular, our RC has been developedin 150 lines of code and our LC is coded in about 1000 lines.

To characterise the performance of our prototype we run 30repetitions of every experiment. Fig. 4 shows the CDF of thedelay due to the intra- and inter-district handovers, measuredas the interruption in data traffic, which also includes the linklayer association. The intra-district case shows a lower latency,because the MN is already known in the district and thereforea simple change in the point of attachment to the network inneeded in that case. The inter-district handover implies changesat layer-3 level, including the configuration of the IP-in-IPtunnel between the two DMM-GWs involved. However, thedelay is very similar to the intra-district handover, becausethe controller runs the configuration of the gateways and theestablishment of the OpenFlow data-path in parallel.

Following with the evaluation of the performance of ourSDN solution, we measure the throughput we can achieve forTCP traffic, using the iperf traffic generator. We compare thecase the MN is attached to one of the districts and the case thatit has performed a handover and its traffic is tunnelled betweenthe current and former DMM-GWs. The average throughputis 8.6 Mb/s and 8.1 Mb/s, respectively, confirming that the

8http://osrg.github.io/ryu/index.html

impact of this tunnelling is very low (the IP-in-IP tunnel justadds 40 bytes of headers). It is noticeable that the maximumthroughput available in the SDN framework is quite limitedfor the moment. This is a well-known open issue and veryheavily influenced by the use of the Linksys WRT54GL routeras OpenFlow-switches.9

It is worth to mention that the signalling due to OpenFlowdoes not impact the data traffic performance, as we use out-of-band signalling within the SDN elements, and the datatransmission from the MN is only delayed at the first packet,when the matching rules are firstly installed in the OpenFlowswitches. To evaluate the impact of the SDN operations, wehave measured the delay introduced by the operations carriedout by the controlled required for our SDN-based DMMsolution. From our experience, the choice of the device runningthe controller has a significant impact on the performance ofthe prototype, especially in the case of handover.

V. RELATED WORK

SDN has raised in popularity very recently, and it hasattracted the attention of the research community, as it easestesting protocols and networking algorithms. The flexibilityand programmability of SDN architectures has contributed tothe proliferation of several large deployments designed byleading research institutions. Among the first deploymentswe find B4 [6], which is Google’s SDN-based wide areanetwork (WAN) to interconnect its data centers around theworld. For B4, an extensive analysis is available on how tomanage the routing and traffic engineering through OpenFlowand the designers of B4 provide interesting insights on design,performance, scalability and failure resilience of their solution.Although providing mobility is not within the objectives of B4,we have leveraged the knowledge provided by the B4 largescale implementation example to design our solution.

Despite the usage of a wired structure to transfer the Open-Flow signalling in our network, we focus on the wireless accessand the mobility management. In that regard, one of the mostremarkable SDN deployments applied to wireless networkingis OpenRoads [7] (also known as OpenFlow Wireless), opento researchers for running their algorithms concurrently bymeans of virtualisation at Stanford University. OpenRoadsincorporates different wireless technologies, namely WiFi andWiMAX, and one of its early proofs of concept was basedon providing mobility across multiple technologies [8]. Inaddition, the performance of OpenRoad has been demonstratedby means of an n-casting transmission solution [9]. All theseapproaches are based on the same principle as our layer-2 mobility approach, reconfiguring the data-path, althoughthey do not consider IP mobility or the design of a scalablearchitecture as we do. All the tools used by OpenRoads areopen source, so as to make the infrastructure reproducible byother research groups in their own networks. Likewise, ourimplementation shows the flexibility of current SDN softwaretools available as open source and is built upon commercial-off-the-shelf devices. At the moment we only focus on IEEE802.11 access points, but we are planning to extend our testbedto include heterogeneous access technologies in the short term.

9http://archive.openflow.org/wk/index.php/Pantou : OpenFlow 1.0 forOpenWRT#Performance

A full software-defined mobile network (SDMN) is definedin MobileFlow [10], and its authors provide a comparisonto the current Evolved Packet Core (EPC) architecture. Aprototype implementation is also proposed in [10], based onthe concept of the MobileFlow Forwarding Engine (MFFE),which encompasses all the user plane protocols and functions,and the MobileFlow Controller (MFC), which is a logicallycentralised entity that configures dynamically the MFFEs (i.e.,the data plane). Although MobileFlow is OpenFlow-based,MFFEs must also support operations that are not carried out atthe switch-level, as layer-3 tunnelling, for instance. Mobilitymanagement can be supported as the controller can updateforwarding rules according to the tunnel encapsulation ordecapsulation requirements. This approach is also followedin our implementation, where we can set the tunnelling andforwarding rules above link layer and the controller updatesthe forwarding rules in the OpenFlow domain. A differentapproach presented in [11] proposes to move the EPC tothe cloud by means of virtualisation and implementing GTPextensions for OpenFlow for mobility management. The mo-bility solutions proposed by both works are based on the samemobility concepts currently used in cellular networks, henceinheriting the scalability issues commented in Section II-B.

In order to mitigate the impact of the re-association tothe new AP during a handover, Odin [12] proposes an SDNframework for enterprise WLANs that leverages light virtualaccess points (LVAPs) as an abstraction to the associationto the wireless AP. In this way, each client appears to beconnected to its own AP, so the physical AP hosts an LVAPfor each attached client (note that an LVAP is not a virtualinterface). When there is a need for handover, the Odin Mastermigrates the corresponding LVAP to the new physical AP.This approach differs highly from our work, since in the firstplace it requires modifications at the APs that are burdenedwith the need of running virtual APs. In addition, in ourprototype, we have focused on improving performance of theSDN configuration and layer-3 mobility, as our measurementsproved those were the dominant factors in the attachment andhandover delays.

An architecture to support flow-based routing in wire-less mesh networks by means of OpenFlow is proposed in[13], which has been evaluated with a mobility managementimplementation that focuses on network-initiated handoverstriggered by IEEE 802.21 MIH Events. This implementationincludes an OpenFlow controller and a Monitoring and Con-trolling Server (MCS) that decides to which Mesh AccessPoints (MAP) the mobile node should connect and updatethe forwarding rules. During the handover, the controllerconfigures temporary routes that forward the traffic to the twoMAPs involved and will be removed when the handover iscomplete. The minimum outage due to handover that theyachieve is on average 200 ms and their results also confirm thatthe main contribution to this delay is due to the association tothe new MAP. A similar approach is followed in [14], but inthis case with in-band signalling and relying on a centralisedcontroller for data rules and a local distributed controller thattakes care of the control rules. In our architecture, we alsopropose two hierarchy levels for the controller deployment,namely the local controller (LC) and the regional controller(RC) with the aim of managing the mobility between differentdomains. However, we go beyond and provide mechanisms for

IP mobility continuity while roaming to different domains.

VI. CONCLUSION

In this paper we have presented an SDN-based architec-ture for supporting distributed mobility management in densewireless networks. Our architecture presents the flexibilityand scalability provided by both SDN and DMM approaches.Although it is an early-stage prototype, our implementationshows very promising features in terms of mobility support,load balancing, data path re-configuration and transparency tothe user, as no modification of terminals is required.

ACKNOWLEDGMENT

This article has been partially funded by the Spanish Min-istry of Economy and Competitiveness through the DRONEXTproject (TEC2014-54335-C4-2-R) and the EU H2020 5G-Crosshaul Project (grant no. 671598).

REFERENCES

[1] Cisco, “The Zettabyte Era.” [Online]. Avail-able: http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/VNI Hyperconnectivity WP.pdf

[2] “IETF DMM WG: http://datatracker.ietf.org/wg/dmm/charter/ .”[3] H. Ali-Ahmad, C. Cicconetti, A. de la Oliva, V. Mancuso,

M. Reddy Sama, P. Seite, and S. Shanmugalingam, “An SDN-BasedNetwork Architecture for Extremely Dense Wireless Networks,” inIEEE SDN4FNS, Nov. 2013, pp. 1–7.

[4] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson,J. Rexford, S. Shenker, and J. Turner, “OpenFlow: Enabling Innovationin Campus Networks,” SIGCOMM Comput. Commun. Rev., vol. 38,no. 2, pp. 69–74, Mar. 2008.

[5] A. Myers, E. Ng, and H. Zhang, “Rethinking the service model: Scalingethernet to a million nodes,” in Proc. ACM SIGCOMM Workshop onHot Topics in Networking, 2004.

[6] S. Jain, A. Kumar, S. Mandal, J. Ong, L. Poutievski, A. Singh,S. Venkata, J. Wanderer, J. Zhou, M. Zhu, J. Zolla, U. Holzle, S. Stuart,and A. Vahdat, “B4: Experience with a Globally-deployed SoftwareDefined WAN,” in SIGCOMM ’13. New York, NY, USA: ACM, 2013,pp. 3–14.

[7] K.-K. Yap, M. Kobayashi, D. Underhill, S. Seetharaman, P. Kazemian,and N. McKeown, “The Stanford OpenRoads Deployment,” in WIN-TECH ’09. New York, NY, USA: ACM, 2009, pp. 59–66.

[8] K.-K. Yap, R. Sherwood, M. Kobayashi, T.-Y. Huang, M. Chan,N. Handigol, N. McKeown, and G. Parulkar, “Blueprint for IntroducingInnovation into Wireless Mobile Networks,” in ACM SIGCOMM VISAWorkshop 2010. New York, NY, USA: ACM, 2010, pp. 25–32.

[9] K.-K. Yap, M. Kobayashi, R. Sherwood, T.-Y. Huang, M. Chan,N. Handigol, and N. McKeown, “OpenRoads: Empowering Research inMobile Networks,” SIGCOMM Comput. Commun. Rev., vol. 40, no. 1,pp. 125–126, Jan. 2010.

[10] K. Pentikousis, Y. Wang, and W. Hu, “Mobileflow: Toward software-defined mobile networks,” Communications Magazine, IEEE, vol. 51,no. 7, pp. 44–53, July 2013.

[11] J. Kempf, B. Johansson, S. Pettersson, H. Luning, and T. Nilsson,“Moving the mobile Evolved Packet Core to the cloud,” in WiMob2012, IEEE, Oct 2012, pp. 784–791.

[12] L. Suresh, J. Schulz-Zander, R. Merz, A. Feldmann, and T. Vazao,“Towards Programmable Enterprise WLANs with Odin,” in HotSDN’12. New York, NY, USA: ACM, 2012, pp. 115–120.

[13] P. Dely, A. Kassler, and N. Bayer, “OpenFlow for Wireless MeshNetworks,” in Computer Communications and Networks (ICCCN), 2011Proceedings of 20th International Conference on, July 2011, pp. 1–6.

[14] A. Detti, C. Pisa, S. Salsano, and N. Blefari-Melazzi, “Wireless MeshSoftware Defined Networks (wmSDN),” in WiMob 2013, IEEE, Oct2013, pp. 89–95.