A Software Defined Semi Distributed Mobility

A Software Defined Semi Distributed Mobility Management System Based on Layer 2 Backhaul Network Jyotirmoy Banik∗ , Yiding Luo∗ , Jonathan Seawright∗ , Junjie Xu∗ , Marco Tacca∗ , Andrea Fumagalli∗ , Behcet Sarikaya† , and Li Xue‡ ∗ Open Networking Advanced Research (OpNeAR) Lab, The University of Texas at Dallas, Richardson, TX, USA {jyotirmoy.banik, yxl100920, jrs095120, jxx094020, mtacca, andreaf}@utdallas.edu

† Huawei Technologies Limited Plano, TX, USA [email protected]

Abstract—This paper presents a software defined networking (SDN) based semi-distributed mobility management system. By both using an SDN approach and leveraging layer 2 technology, i.e., carrier grade Ethernet and the 802.1ad standard, it is possible to simplify the network architecture by removing the need for the relatively complex GPRS tunneling protocol currently in use in the user plane. An analytical model is used to evaluate the control overhead of the proposed approach and a proof of concept testbed based on OpenFlow running the Floodlight controller is presented. Obtained results demonstrate that, as long as the SDN controller can quickly react to user mobility, frame loss can be mitigated and the proposed architecture is viable.

I. I NTRODUCTION Cellular data traffic is growing every day at a fast pace. A staggering 81% growth of cellular data traffic was reported in 2013 [1]. Long Term Evolution (LTE), an all-IP networking technology, is playing a key role in keeping pace with this increasing mobility demand. The idea of separating control plane and data plane is increasingly becoming popular, which enables independent and efficient resource provision in each plane [2]. Native IP does not inherit any real-time mobility support by design, therefore, specific mobility handling mechanisms must be identified for cellular communication. 3GPP has identified one such mechanism, named, GPRS Tunneling Protocol (GTP). By using Tunnel Endpoint Identifier (TEID), GTP tunnels enable a cellular user to move seamlessly between different eNodeBs, while allowing the User Equipment (UE) to retain the same IP address. Every time a user moves from one eNodeB to another, its assigned TEID must be updated. With the rapid increase in cellular traffic demand, deployments based on small cells are gaining momentum as they offer increased network capacity through space diversity. A side effect of this approach is that small cells increase the frequency of handovers between cells, which in turn causes GTP updates to occur more frequently. This procedure imposes a significant signaling burden on the mobile core network (also known as Evolved Packet Core or EPC). Additionally, when using GTP at the UDP/IP layer, a packet header overhead of 36 bytes for IPv4 and 56 bytes for IPv6 further contribute to overheads. The header overhead can be as high as 14% and 22%, for IPv4 and IPv6, respectively [3].

‡ Huawei Technologies Limited Haidian, Beijing, China [email protected]

To partially overcome these challenges, this paper describes a distributed mobility management solution based on a SDN controlled layer 2 network. The objective of the proposed solution is first and foremost to prevent the use of GTP-U tunnels. In addition, instead of tracking mobility in a centralized fashion, the proposed solution delegates the function to backhaul nodes. The motivation behind this approach is to keep the EPC unaware of user mobility except when it is essential, i.e., when the handover involves S-GW relocation or MME relocation. Notice that this approach can coexist with GTP control (GTPC) tunnels, thus allowing all the functionalities of GTP-C to remain available and compliant to the 3GPP standard. Another desirable goal of the proposed solution is to contain the number of changes required in Evolved Packet System (EPS) to a minimum, thus easing its practical deployment. The design proposed in this paper requires only basic OpenFlow primitives. Since 3GPP control packets are not processed by the SDN controller, its computational resources are minimized. Some prior work has been done in this direction. In [3], TRILL (Transparent Interconnection of Lots of Links) and Distributed Hash Table (DHT) are leveraged to handle user mobility. However, in this approach, some Ethernet broadcasting functions are required, thus leading to undesirable signaling overhead. In [4], SDN/OpenFlow is applied to support user mobility in the backhaul network. The proposed approach assigns additional functions to the SDN controller. For example, the tasks of handling and interpreting 3GPP control packets, differentiating between them, and taking proper actions make the SDN controller relatively complex. Moreover, the proposed approach affects both user (GTP-U) and control (GTP-C) plane. In this case, the MME must be aware of Service VLAN (S-VLAN) assignment. As a result, the approach in [4] requires major changes in the 3GPP standard procedures. The solution proposed in this paper expands on the concept introduced in [3]. An analytical model is developed to evaluate the signaling load on EPC for both the proposed method and standard LTE. In addition, a proof-of-concept testbed is built to validate the feasibility of the proposed solution. Obtained results show that an SDN based solution is a viable one.

SDN Controller

II. O PEN F LOW AND U SER M OBILITY This section presents the details on how OpenFlow is used to replace the use of GTP-U tunnels to handle user mobility in the mobile network backhaul. A. Network Architecture The proposed solution makes the following assumptions: • The entire mobile backhaul network is based on CarrierEthernet technology. • Each eNodeB should be capable of translating C-VLANs to user traffic profiles. Similarly, the S-GW should be capable of doing the opposite, i.e., translating the 3GPP defined traffic profiles to C-VLAN IDs. • Each eNodeB should be capable of generating gratuitous ARP. • Each eNodeB should be capable of intercepting 3GPP control messages, to get the information about UE IP address, whenever a UE attachment is made. • The S-GW should be capable of storing the source MAC address for each UE, detecting it from a UE packet destined to P-GW. By design, IP does not provide location information. However, the Medium Access Control (MAC) address of the eNodeB in conjunction with the IP address of the UE provides a complete information about a user location. This information can be disseminated in the entire backhaul network by utilizing OpenFlow. The IEEE 802.1ad standard of Virtual Local Area Network (VLAN) — commonly known as Q-in-Q — can also be used to differentiate between different eNodeB groups and to differentiate between different user traffic types. IEEE 802.11ad provides an outer VLAN tag, referred to as S-VLAN, and an inner VLAN tag, referred to as C-VLAN. The reference architecture is based on a layer 2 end-toend transport network, as shown in Fig. 1. Sets of eNodeBs are clustered in different groups. Each group of eNodeBs is connected to an Ethernet switch, which is referred to as egress switch, and acts like a Cell Site Gateway (CSG). An S-VLAN ID is assigned to the group of eNodeBs, which belong to the same egress switch. The switches adjacent to S-GW(s) are referred to as ingress switches, and act like Mobile Aggregation Site Gateway (MASG). Ingress and egress switches are connected via a network of switches to form a connected graph. Switches are controlled by one or more OpenFlow controllers. Multiple controllers can be used to achieve higher availability and scalability. When using multiple controllers, schemes like FlowVisor [5] can be utilized to distribute the load among the controllers. An S-VLAN tag is assigned to create one or more VLAN paths to offer layer 2 transport capabilities between every pair of egress switch and ingress switch. The established paths are quasi-static and are used to carry UE traffic between the connecting eNodeB and the S-GW. B. Uplink and Downlink Data Packet Flow As mentioned earlier, the proposed solution keeps the control plane unchanged, which implies that procedures such

eNodeB Group 1

Egress

Egress

Ingress

Ingress

S-GW

P-GW

Internet/ IMS/Other PDN

eNodeB Group 2

Fig. 1: Network architecture with Distributed Mobility Management in backhaul. as Initial Attachment (IA) and Tracking Area Update (TAU) follow the 3GPP standard. The IA or TAU procedures are not covered in the packet flow description. The uplink direction (UE → PDN) is considered first. After the IA procedure completes, the target eNodeB sends a gratuitous ARP to the connected egress switch. With gratuitous ARP requests, the backhaul mobile network is informed about the handover in the following way. The target eNodeB generates a modified gratuitous ARP request, in which the IP address field contains the IP address of the UE. Whenever an egress switch receives a gratuitous ARP packet, the switch forwards it to the OpenFlow controller. As a result, the OpenFlow SDN controller can extract the IP address of the UE and the MAC address of the sending eNodeB. The information collected is stored at a table in the SDN controller, referred to as Mobility Table. Additionally, the Mobility Table contains the S-VLAN ID of the eNodeB, and the MAC addresses of both the ingress and egress switch assigned to the UE. By using the information in the Mobility Table, the OpenFlow controller(s) can assign traffic to existing S-VLANs between egress and ingress switches. As a result, packets from the UE can reach the S-GW without the need of using GTP-U tunnels. The ingress switch can then send data packets to the S-GW. When receiving the UE packet from ingress switch, S-GW keeps a record of the ingress switch interface MAC address. In the case of downlink traffic (PDN → UE), the S-GW forwards the packet to the ingress switch interface based on the stored information. By using the S-VLAN ID for bidirectional communication between ingress and egress switch, packets in the downlink direction can reach the UE. C. Transients During Mobility Events Once a successful radio handover is completed, the procedure described in the previous section handles mobility in the mobile backhaul network. Due to signaling latencies, there can be transient scenarios. When a handover procedure takes place, uplink traffic does not suffer any transient effects. However,

UE

Src eNodeB

Src Egress

Dst eNodeB

Dst Egress

Controller

Ingress

S-GW

1. Mobility Event 2. Handover Request 3. Incoming Packet for UE 4. Handover Ack 5. Gratuitous ARP 6. Buffered Packet Sent Back to Dst eNodeB 8. Location Update Message (Forwarding Gratuitous ARP)

7. Packet Sent to UE

9. Delete Flow

9. Add Flow

9. Modify Flow

10. Incoming Packet to UE 11. Sent Back to Proper Egress 12. Packet sent to UE

13. Packet sent to Ingress 14. Packet sent to Proper Egress 15. Packet sent to UE

Fig. 2: Mobility diagram: downlink direction. downlink traffic might be affected, i.e., there is a short transient during which downlink traffic is still directed towards the source eNodeB. Two cases are possible. The first case happens when the source egress switch is not yet aware of the handover completion. In this case, data packets intended for the UE are still sent to the source eNodeB. The source eNodeB forwards such data packets to the destination eNodeB directly over X2 interface tunnel. The other case happens when the source ingress switch is not yet aware of handover completion but the source egress switch is. In this case, data packets are continued to be sent to the source egress switch, which in turn sends them to the target egress switch using an S-VLAN created by the OpenFlow controller. These transient scenarios are illustrated in Fig. 2 III. A NALYTICAL M ODELING OF S IGNALING L OAD ON EPC This section presents an analytical model which is used to estimate the control overhead associated with the proposed solution. The analytical model presented in [4] is modified to fit the solution proposed in this paper. Results obtained from the model are then compared with results from standard LTE system. The model approximates the user mobility using the Gauss Markov Mobility Model as detailed in [6]. A circular shaped cell is assumed. It is also assumed that time is slotted. The average load on the LTE system, LI (packets/second), is defined as the addition of two components, packets sent to the EPC due to initial attachment procedure, LIA , and packets send to the EPC due to handover, LHO ,  LI = LIA + LHO =

1 λ+ 2k

 N

(1)

where N is the number of UEs and k is the average number of time slots a UE stays in a cell before the next handover takes place. The time interval between initial attachment (IA) and the network detachment (and vice versa) is modeled as an exponential random variable, with parameter λ.

Fig. 3: EPC control overhead for both standard LTE and proposed solution. At an arbitrary time slot n, let p indicate the probability that the UE remains in the same cell till the next time slot n + 1 The value for p can be calculated as: 4 p= 2 πr

Zr

√

rZ2 −x2

Zπ P (Sn ≤ d)fθn (φ) dφ dy dx

0

0

(2)

−π

where, r denotes the radius of the cell, Sn and θn denote speed and direction of the UE. According to the Gauss-Markov model, at time slot n, d is the distance from any point in the circle to a point on the circle, which makes an angle φ with the x axis, and fθn is the probability density function of the direction. Once the value for p is calculated, the average number of time slots that the UE stays inside a cell before handover, k, is 1/(1 − p). In the proposed solution, EPC is informed about the handover only when the handover involves S-GW relocation. As a result, the EPC signaling load for the proposed solution is estimated as:   PSGW −Reloc LII = LIA + LHO = λ + N (3) 2k where PSGW −Reloc denotes the probability of S-GW relocation, given that a handover has taken place. Fig. 3 shows the EPC control overhead for both standard LTE and the proposed solution. Curves are obtained assuming that the cell radius is 10 km, the average user speed is 4 m/s, the direction angle is π/2, and the memory parameter in the Gauss-Markov model is α = 0.75. The curves quantify the expected reduction of EPC control overhead (when compared to standard LTE) for 3 possible S-GW relocation probabilities. IV. E XPERIMENTS AND R ESULTS A. Testbed Description This section describes the details of the experimental setup that is used to collect the presented results. The testbed developed for this research consists of: 1)four physical hosts running Open vSwitch, 2) a PC running the floodlight SDN controller,

Fig. 6: Handover sequence with X2 interface tunnel. Fig. 4: Testbed layout. 3) two hosts, one acting as UE, and another as destination node. Fig. 4 shows the testbed layout. The testbed consists of two isolated networks: a data network and a management network. Data network links are solid lines in the figure, while management network links are dotted lines in the figure. The management network is used to connect (SSH) to client H1 and client H2, as well as OpenFlow traffic between the switches and the controller. The testbed is used to emulate the behavior of the real network. Switch SW1 represents eNodeB group 1, while switch SW2 represents eNodeB group2. Switch SW3 represents the S-GW. Client H1 acts like a mobile user (UE). Mobility is emulated by having switch SW4 to send/receive traffic to either SW1 or SW2. Client H2 emulates a destination server in the core network or beyond. C1 is the SDN controller. The link between SW1 and SW2 is used to emulate the X2 interface tunnel. (Section II-C). B. Experiment Setup The experiment is intended to present handover performance. Similar experiments for WiFi and WiMAX networks are presented in [7]. Conventional hard handover is emulated in this experiment for two cases, namely, 1) without an X2 interface tunnel, and 2) with an X2 interface tunnel. The first case is one where there is no X2 interface tunnel. Fig. 5, illustrates the sequence of network states and directions of each flow in the system. The starting state (left side), is referred to as VLAN X state. As the UE moves, uplink traffic uses SW2, while downlink traffic is lost (center). After a delay D1 the network updates the UE position (right side), the state is referred as VLAN Y state.

Fig. 5: Handover sequence without X2 interface tunnel.

(a)

(b)

(c)

Fig. 7: Packet loss for UDP traffic. The second case, where there is an X2 interface tunnel, uses a similar approach. Fig. 6, illustrates the sequence of network states. The only difference is — during handover when the UE moves to SW2 —, the downlink traffic is redirected from SW2 to SW1, using the X2 interface tunnel. This tunnel is not available immediately. Instead, it becomes available for downlink traffic after a delay D2 . After a delay D1 > D2 the network updates the UE position (right side). The experiment consists of a sequence of cycles: each cycle has a period of 10 seconds, followed by a transition from VLAN X state to VLAN Y state (or vice versa). C. Results This section reports the experimental results obtained with a number of scenarios for both the cases with and without the X2 interface tunnel. Results are obtained using two different types of traffic: UDP traffic and TCP traffic. In order to obtain network performance indicators under a variety of conditions, the values for D1 and D2 are arbitrarily changed in the experiments. 1) UDP Traffic: UDP is a unidirectional protocol. As a result, the uplink and downlink traffic are tested independently. UDP traffic is generated using NetPerf [8]. Fig. 7(a) and Fig. 7(b) report the obtained results for uplink and downlink UDP traffic, respectively, without the X2

shows that the total transmission time is significantly reduced when the X2 interface tunnel is used. Fig. 8(c) and Fig. 8(d) report results obtained when D2 = 0.25s and D2 = 0.5s, respectively. Curves in the figures show that the duration of the data transfer is independent from D1 even when there is a secondary delay before the X2 interface tunnel becomes available. (a)

(b)

(c)

(d)

Fig. 8: Total transmission time for TCP traffic. interface tunnel. Fig. 7(a) (uplink traffic) shows the baseline loss of the system, while Fig. 7(b) (downlink traffic) shows that packet loss that grows proportionally to the delay time D1 . This is as expected, as the UE can always connect to the server, no matter which eNodeB it is on. Fig. 7(c) show results obtained with downlink UDP traffic using the X2 interface tunnel and D2 = 0s. As expected, the packet loss stays relatively constant, averaging close to 1%. 2) TCP Traffic: Unlike UDP, TCP is a bidirectional protocol, which offers better reliability with the cost of additional transmission time used to retransmit the lost segments. Thus, the total transmission time is used as a metric to evaluate the performance of the proposed solution. The D-ITG (Distributed Internet Traffic Generator) [9] tool is used to generate TCP traffic. Tests are run to compare the trend of the transmission duration in the system with and without X2 interface tunnel. Two sets of data were collected for each experiment. The value for delay D1 is varied in the interval [0s, 8s] in 1s steps. Three values for the delay D2 are considered: D2 = 0s, D2 = 0.25s, and D2 = 0.5s. Fig. 8(a) and Fig. 8(b) show obtained results. Both figures show a staircase type of behavior. This is due to a combined effect of the periodic delay D1 and an increasing TCP wait time caused by packet losses during D1 . During D1 , no ACK packets make it back to the sender until the X2 interface tunnel is activated. As D1 is incremented, the delay in receiving ACK packets increases, and after a certain threshold, TCP extends its wait time. In Fig. 8(b), for D1 between 3 to 6 seconds, the TCP wait time is consistent because it is longer than the total delay time. Once the total delay time exceeds the TCP wait time, TCP reacts by further extending its wait time, which results in the increase between 6 and 7 seconds. This process is expected to continue generating the staircase-shaped plot, when D1 keeps increasing beyond 8s until a maximum threshold is received and the TCP connection is reset. Fig. 8(b)

V. C ONCLUSION This paper presented an alternative solution to GTP tunnels for handling user mobility in the mobile backhaul network. SDN is a key enabling technology for the proposed solution. The proposed solution requires changes in the user plane only, leaving the current 3GPP control plane unchanged. Additionally, the proposed solution is based on OpenFlow, an SDN solution that offers a simple and efficient mechanism to provide connectivity between the switches in the mobile backhaul network. First, an analytical model was used to estimate the EPC control overhead reduction achievable by the proposed solution. Then, a proof-of-concept testbed based on the floodlight SDN controller was built to investigate the feasibility of the proposed solution. Obtained results demonstrate that the proposed combination of SDN and layer 2 routing is a viable solution for handling user mobility in the mobile backhaul network without requiring GTP-U tunnels in the data plane. R EFERENCES [1] “Cisco visual networking index: Global mobile data traffic forecast update, 2014-2019, white paper,” 2013. [2] S. Matsushima and R. Wakikawa, “Stateless user-plane architecture for virtualized epc (vepc),” Work in Progress, draft-matsushima-statelessuplane-vepc-03, 2014. [3] N. Varis et al., “A layer-2 approach for mobility and transport in the mobile backhaul,” in ITS Telecommunications (ITST), 2011 11th International Conference on, 2011. [4] P. Gurusanthosh et al., “Sdma: A semi-distributed mobility anchoring in lte networks,” in Mobile and Wireless Networking (MoWNeT), 2013 International Conference on Selected Topics in, 2013. [5] R. Sherwood et al., “Flowvisor: A network virtualization layer,” OpenFlow Switch Consortium, Tech. Rep, 2009. [6] B. Liang and Z. Haas, “Predictive distance-based mobility management for multidimensional pcs networks,” Networking, IEEE/ACM Transactions on, vol. 11, no. 5, 2003. [7] K.-K. Yap et al., “Blueprint for introducing innovation into wireless mobile networks,” in Proceedings of the second ACM SIGCOMM workshop on Virtualized infrastructure systems and architectures, 2010. [8] R. Jones et al., “Netperf: a network performance benchmark,” Information Networks Division, Hewlett-Packard Company, 1996. [9] S. Avallone et al., “D-itg distributed internet traffic generator,” in Quantitative Evaluation of Systems, 2004. QEST 2004. Proceedings. First International Conference on the, 2004.