Ahmed Naseem Alvi

Safdar Hussain Bouk

Syed Hassan
email: hassan@knu.ac.kr

Muhammad Azfar Yaqub
email: yaqub@knu.ac.kr

Influence of Backoff Period in slotted CSMA/CA of IEEE 802.15.4

Keywords: IEEE 802.15.4, CSMA/CA, Markov Chain, Backoff Period

Low rate wireless applications are under attraction since last decade. For such applications, IEEE designed a standard known as IEEE 802.15.4. The standard operates at 868, 915 and 2400MHz with or without using super frame structure. Most of the low rate Wireless PAN applications follow superframe structure. A superframe structure comprises of contention based and contention free periods by offering slotted CSMA/CA and TDMA like operation respectively. This paper analyzes the performance of slotted CSMA/CA algorithm. CSMA/CA algorithm highly depends upon backoff period that is why its impact is analyzed in this work. The performance analysis is based on probability determined by using discrete markov chain model. The performance analysis comprises of nodes waiting time before transmission, channel busy probability and ultimately throughput and reliability is calculated. Results show that network reliability along with throughput of a wireless network increases gradually with the increase in backoff period at the cost of increase in average wait time of nodes.

Introduction

Wireless technologies are developing swiftly as demand of wireless Sensor Networks (WSN) increases. There are number of WSN applications such as surveillance and monitoring. Wireless nodes in WSN are tiny in size having limited energy, computation, processing and communication capabilities. These limitations are not addressed at once by well known IEEE 802.11 and IEEE 802. [START_REF] Park | A generalized markov chain model for effective analysis of slotted IEEE 802.15.4[END_REF] as they consume more energy during idle listening. ZigBee is the most prominent alliance supporting low-power embedded systems and facilitates multiple applications. It uses IEEE 802. [START_REF] Jung | Enhanced markov chain model and throughput analysis of the slotted CSMA/CA for IEEE 802.15.4 under unsaturated traffic conditions[END_REF].4 standard at its physical and MAC (Medium Access Control) layer. IEEE 802.15.4 standard is suitable for energy efficient and low data rate applications. Some of these applications are environmental monitoring, light control systems, agricultural monitoring, automatic metering, industrial and security alarm system [1]. The standard suits well for static and low cost mobile wireless nodes having limited battery power with high reliability, as discussed in [START_REF] Callaway | Home networking with ieee 802.15.4: a developing standard for low-rate wireless personal area networks[END_REF][3] [START_REF] Zheng | Will ieee 802.15.4 make ubiquitous networking a reality?: a discussion on a potential low power, low bit rate standard[END_REF]. IEEE 802. [START_REF] Jung | Enhanced markov chain model and throughput analysis of the slotted CSMA/CA for IEEE 802.15.4 under unsaturated traffic conditions[END_REF].4 runs at 868MHz, 915MHz and 2.4GHz frequency bands. The standard operates in Beacon as well as in Non-Beacon enabled modes. Beacon mode comprises of Contention Access Period (CAP) and optional TDMA based Contention Free Period (CFP). During CAP, nodes follow slotted CSMA/CA mechanism. CSMA/CA depends upon multiple parameters, however, the most prominent one is the backoff period length. This paper contributes in analyzing the impact of varying backoff periods to determine the IEEE 802.15.4 performance. A comprehensive study of different backoff period lengths and their impact in slotted CSMA/CA, where all wireless nodes contend to access the medium and chances of collision are maximum, is also done in this work. The analysis is performed with fixed number of nodes and similar load variations.

Rest of the paper is organized as follows: In section 2, the performance analysis of different authors in this field is discussed. Next section 3 discusses the brief overview of IEEE 802.15.4 standard. Sections 4 and 4 illustrates slotted CSMA/CA algorithm and markov chain model respectively. Section 6, evaluates the effect of different parameters against varying backoff period and conclusion is described in Section 7.

Related Work

Contention access period of IEEE 802.15.4 is quite similar to IEEE 802.11. The only differences are that IEEE 802.15.4 starts sensing the availability of medium at the end of the backoff period and also it confirms the channel availability twice before transmitting its packets. Authors in [START_REF] Malone | Modeling the 802.11 distributed coordination function in nonsaturated heterogeneous conditions[END_REF][6] [START_REF] Tickoo | Queueing analysis and delay mitigation in IEEE 802.11 random access MAC-based wireless networks[END_REF] analyzed the performance of heterogeneous traffic under non saturated mode of IEEE 802.11 Distributed Coordination Function (DCF). In [START_REF] Malone | Modeling the 802.11 distributed coordination function in nonsaturated heterogeneous conditions[END_REF], authors presented an extended Bianchi model [START_REF] Bianchi | Performance analysis of the IEEE 802.11 distributed coordination function[END_REF] for unsaturated heterogeneous data traffic of IEEE 802.11 DCF. Authors in [START_REF] Engelstad | Non-saturation and saturation analysis of IEEE 802.11e EDCA with starvation prediction[END_REF] used discrete Markov chain model to find out the probability of utilization factor, throughput and delay for diverse traffic in a wireless LAN of IEEE 802.11e. Tickoo et al. in [START_REF] Tickoo | Queueing analysis and delay mitigation in IEEE 802.11 random access MAC-based wireless networks[END_REF], considered homogeneous as well as heterogeneous data traffic to analyze the service time distribution of IEEE 802.11.

Many authors have analyzed IEEE 802.15.4 in different scenarios by highlighting its duty cycle and less energy consumption. Performance analysis of unslotted CSMA/CA in different prospects of the standard is analyzed by authors in [START_REF] Latré | Throughput and delay analysis of unslotted IEEE 802.15.4[END_REF] [START_REF] Kim | Performance analysis of ieee 802.15.4 with non-beacon-enabled CSMA/CA in non-saturated condition[END_REF]. In [START_REF] Zayani | A joint model for ieee 802.15.4 physical and medium access control layers[END_REF][12] [START_REF] Jurcik | A simulation model for the ieee 802.15.4 protocol: Delay/throughput evaluation of the gts mechanism[END_REF], many simulation based studies are discussed to evaluate the performance of the standard in different prospects. Pollin et.al. in [14], used Markov chain model to determine the performance of slotted CSMA/CA of the standard with saturated traffic load. In [START_REF] Jung | Enhanced markov chain model and throughput analysis of the slotted CSMA/CA for IEEE 802.15.4 under unsaturated traffic conditions[END_REF], authors have analyzed the throughput of slotted CSMA/CA by applying enhanced Markov Chain model during un-saturated region. In this work we have explored the importance of backoff period in CSMA/CA operation of IEEE 802.15.4 and analyzed the ef- fect of varying backoff period in novel way by following discrete Markov channel model described in [START_REF] Park | A generalized markov chain model for effective analysis of slotted IEEE 802.15.4[END_REF].

IEEE 802.15.4 Overview

The standard is designed for both Physical and MAC layers by offering duty cycle even less than 0.1%. The standard operates in three different frequency bands. Detail of all these frequency bands is shown in table 1. IEEE 802.15.4 uses un-slotted CSMA/CA algorithm during non beacon enabled mode. However, superframe structure is applied in beacon enabled mode. Superframe structure comprises of active and inactive period. Beacon frame, Contention Access Period (CAP) and optional Contention Free Period (CFP) are part of active period as shown in Fig. 1, whereas the node remains in sleep mode during inactive period. Active period consists of 16 slots, out of these 16 slots, maximum 7 slots may be allocated for CFP and the rest consists of Beacon frame and CAP. All beacon enabled nodes contend to access the medium in transmitting data to its coordinator during CAP by following slotted CSMA/CA algorithm as shown in Fig. 3. PAN coordinator is responsible for generating beacon frames in the network after regular intervals. These beacon frames are used to synchronize all the associated nodes in that WPAN. Information about active Superframe duration and arrival of next Beacon frame can be calculated from different parameters highlighted in the superframe specification field present in beacon frame. Superframe

SD = 48 × 2 SO × aU nitBackof f P eriod
(1)

BI = 48 × 2 BO × aU nitBackof f P eriod (2)
Expression ( 1) and ( 2) show that the Superframe duration and Beacon Intervals mainly depend on aU nitBackof f P eriod length. Varying the length of aU nitBackof f P eriod highly affect the performance of CSMA/CA operation during active period of Superframe. That's why, the impact of varying backoff period is evaluated in this work.

Slotted CSMA/CA Mechanism

During CAP of IEEE 802.15.4, slotted CSMA/CA mechanism is used that mainly comprises of three parameters as NB,BE and CW. NB is number of times, node should wait for backoff periods. Value of NB ranges from 0 to 4. This allows a node to attempt for maximum of 5 times in order to access the channel. If a node fails to find the channel idle for maximum allowed attempts, then it reports failure to its upper layer.

Parameter BE stands for Backoff Exponent and it describes the random range of backoff periods, a node should wait before assessing the channel availability. It ranges from 0 to 2 BE -1 and default value of BE ranges from 3 to 5 by following the parameters of macM inBE and aM axBE, respectively. This results in backoff period initial range from 0 to 7 and last backoff period range from 0 to 31.

Contention Window (CW) is related to idle channel availability by using Clear Channel Assessment (CCA). Initial value of CW is 2, that is node needs to pass the channel availability for two successive times before declaring the channel idle. Detailed flow diagram of CSMA/CA is shown in Fig. 3.

Packets are transmitted only if computed frame's length along with its acknowledgment and inter-frame spacing can be completed within same active period.

A complete frame duration (CFD) consists of time required to transmit data with acknowledgment and is calculated as: 4.

W i = 2 macM inBE × 2 min{aM axBE-macM inBE,i} (3)
Some of the states mentioned in the model are described as under.

{-1, 0, 0} idle state {k, 0, 2} node is going to perofrm CCA1 during (k+1)th time {k, 0, 1} node is about to perform CCA2 during (k+1)th time {k, 0, 0} node successfully passed the CCA1 and CCA2 {k, b, 2} node needs to wait for -1,0,0 0,0,2 0,1,2 0,w0-3,2 0,w0-2,2 0,w0-1,2 -1,L,0 0,0,0 0,0,1 b backoff counter before performing CCA1 α busy medium probabilty during CCA1 β busy medium probabilty during CCA2 γ probability of node having no data to send Suppose stationary probabilities of Markov chain is:

1,0,2 1,1,2 1,w1-3,2 1,w1-2,2 1,w1-1,2 1,0,0 1,0,1 2,0,2 2,1,2 2,w2-3,2 2,w2-2,2 2,w2-1,2 2,0,0 2,0,1 k,0,2 k,1,2 k,wk-3,2 k,wk-2,2 k,wk-1,2 k,0,0 k,0,1 -1,L-1,0 -1,1,0 α 1-α 1-β α α α 1-γ 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 γ β β β β 1-β 1-β 1-β 1-α 1-α 1-α
b k,b,c =P{NB(t)=k, BC(t)=b, CW(t) = c} ∀ k,b,c
From the markov chain model, we obtain

b k,0,2 = αb k-1,0,2 + βb k-1,0,1 kε[1, m] (4)
From the Markov chain, we know that:

b -1,0,0 = p cf + b -1,t,0 + γb -1,0,0 (5)
Here, p cf is probability of channel access failure,

p cf = αb m,0,2 + βb m,0,1 (6)
All these states are determined by following equations 7 to 14

b k,0,0 = (1 -β)b 0,0,1 (7)
b k,0,2 = b 0,0,2 (α + β -αβ) k (8) b k,0,1 = b 0,0,2 (1 -α)(α + β -αβ) k (9)
Similarly b˙k, 0, 0 is calculated as:

b k,0,0 = b 0,0,2 (1 -β)(1 -α)(α + β -αβ) k (10) b k,0,0 = b 0,0,2 (1 -(α + β -αβ) k+1 ), kε[0, m] (11) b k,0,0 = b -1,t,0 = b -1,t-1,0 , tǫ[2, T ] (12) b 0,0,2 = b -1,0,0 (1 -γ) (13) b -1,0,0 = (b 0,0,2 )/(1 -γ) (14)
b k,p,2 can be represented with b 0,0,2 as:

b k,p,2 = b 0,0,2 (α + β -αβ) k (W k -p)/(W k ), kε[1, m], pε[1, W k -1] ( 15
)
Similarly b 0,p,2 can be represented with b 0,0,2 as:

b 0,p,2 = b -1,0,0 (W 0 -p)(1 -γ)/(W 0 ) (16)
By simultaneously solving 13 and 16, we get:

b 0,p,2 = b 0,0,2 (W 0 -p)/(W 0 ), Herep ε[1, W 0 -1] ( 17
)
As sum of all the probabilities of the states is always one, we have:

(18) b -1,0,0 + m k =0 b k,0,1 + m k =1 b k,0,2 + m k =1 W k -1 p =1 b k,p,2 + W0-1 p =1 b 0,p,2 + T t =1 b -1,t,0 = 1
By replacing values of each state mentioned in eq.18 and by simplifying, we get:

(19) b0,0,2 = 1 1 1-γ + (1 -(α + β -αβ) m+1 )T + (2-α)(1-(α+β-αβ) m+1 ) (1-(α+β-αβ)) + m k=0 ( W k-1 2 )(α + β -αβ) k

Analysis with Results

It is evident from (1) and ( 2) that SD and BI depend on aU nitBackof f P eriod.

As per CSMA/CA flow chart in Fig. 3, each transmitting node has to wait for random number of backoff period. Due to the significance of backoff period length, the performance of CSMA/CA is analyzed by varying the backoff period's length. The simulation analysis includes node's average wait time before transmitting, probability of channel access busy during CCA1 and CCA2. Analysis also comrises of throughput, reliability and transmission failure probability. All these results are analyzed by increasing load. The simulation parameters are briefly summarized in Table 2.

Busy Channel Probability During CCA1

Each data transmitting node senses the medium availability after completing its random backoff count. If τ is the probability of transmitting a packet which is computed by markov chain as:

τ = T t=1 b -1,t,0 (1 -(α + β -αβ) m+1 ) × T × b 0,0,2 (20)
then busy channel probability during first attempt (α) is computed as:

α = [L(1 -(1 -τ ) N -1 )(1 -α)(1 -β)] + ... L ack N τ (1 -τ ) N -1 (1 -(1 -τ ) N -1 )(1 -α)(1 -β) 1 -(1 -τ ) N (21) α = (1 -α)(1 -β)(1 -(1 -τ ) N -1 )... [L + L ack (N τ (1 -τ ) N -1 ) 1 -(1 -τ ) N ] ( 22
)
where L is data frame length in slots, L ack is length of Acknowledgment frame and [1-(1-τ ) N -1 ] is collision probability. It happens when one of the remaining nodes also transmit data in same backoff slot. Results shown in Fig. 5 illustrates that increase in traffic load increases the α probability. This is because of busy channel for most of the time. The results further show that reduced backoff period length increases the busy channel probability during CCA1 and vice versa.

Channel Assess Busy Probability During CCA2

CSMA/CA algorithm describes that value of CW is decremented by 1 when a node finds the channel idle during CCA1. At the start of next backoff period, node senses the medium availability for the second successive time. CCA2 is computed as:

β = 1 -(1 -τ ) N -1 + N τ (1 -τ ) N -1 2 -(1 -τ ) N + N τ (1 -τ ) N -1 (23)
Here β is probability to find medium busy during CCA2. Figure 6 illustrates that there is comparably less probability of finding channel busy during CCA2 as of CCA1. This happens because CCA2 sensed the medium in very next slot instead of waiting for backoff period. Here probability of finding channel busy are similar for different backoff period lengths however it rises more with applied load where backoff period length is higher.

Wait Time

Average wait time of a network is the time for which networking nodes have to wait before transmitting the data packets due to busy medium. It is noted that node's waiting time is more when backoff period length is higher as shown in Fig. 7. This is due to the fact that nodes have to wait for longer time due to longer backoff period as of the shorter backoff period length.

Reliability

Reliability of a network is based on the successful transmission of data packets from source towards destination.Following are the two reasons of data packet failure.

1. A node could not transmit its data packet as medium remains busy for such time when NB¿macmaxcsmabackoff. 2. A node transmits the data packet again and again until the retry limits (Pcr) exceeds aM axF rameRetries and no acknowledgment frame is received.

Reliability of a network is calculated as:

Reliability = 1 -P cf -P cr (24)
Results in Fig. 8 show that a network is more reliable with reduced load and less reliable with increased load. Longer Backoff Period length increases the reliability of successful transmission.

Average Throughput

Average throughput is defined as number of successful data over total time through a medium. Figure 9 shows that the larger backoff period length achieves higher throughput compared to the smaller backoff period length.

Conclusion

The paper analyzed the effect of varying backoff period on the performance of slotted csma/ca. Discrete Markov chain model is used to determine different probabilities of slotted CSMA/CA. Effect of same load variation has been analyzed by finding the probability during CCA1, CCA2. In addition failure probability along with reliability and throughput are also analyzed. Results show that the reliability of successful transmission increases with the increase in backoff period length due to less probability of collisions. However, it increases the node's waiting time before transmitting its frame in the medium. Therefore, reduction in chances of collision increases the power efficiency of nodes, which results in longer network life-time at the cost of longer waiting time.

Fig. 1 :

 1 Fig. 1: Superframe structure with CAP and CFP

Fig. 2 :

 2 Fig. 2: Beacon frame with Superframe Specification field description

Fig. 3 :

 3 Fig. 3: Flow diagram of slotted CSMA/CA

Fig. 4 :

 4 Fig. 4: Discrete Time Markov Chain Model.

Fig. 5 :

 5 Fig. 5: Busy channel probability during CCA1

Fig. 6 :Fig. 7 :

 67 Fig. 6: Busy channel probability during CCA2

  Fig. 8: Network Reliability

Fig. 9 :

 9 Fig. 9: Network Throughput

Table 1 :

 1 Frequency Bands with Data Rate

	Frequency	Modulation	Symbols	Bits /	Symbol Du-	Data	rate
	Band (MHz)	Scheme	/ sec	symbol	ration (sec)	(bits/sec)
	868 -868.6	BPSK	20000	1	50*e-6	20000
	902 -928	BPSK	40000	1	25*e-6	40000
	2400 -2483.5 O-QPSK	62500	4	16*e-6	250000

Table 2 :

 2 Simulation Parameters

	Parameters	Value
	Number of Nodes	10
	Data Rate	250Kbps
	Offered Load (bits)	484 to 6776
	aUnitBackoffPeriod	10:10:50
	(Symbols)
	Turnaround time (Sec) 0.000192
	macAckWaitDuration	0.000864
	macMaxCSMABackoff	4
	aMaxFrameRetries	3


Christos Pollalis
email: pollalisbelg@yahoo.gr3pchara

Paris Charalampou

Efstathios Sykas
email: sykas@cn.ntua.gr

Multipath TCP Proxy: unshackling network nodes from today's end-to-end connection principle

Keywords: Multipath TCP, Protocol Conversion, Congestion Control, Policy Routing, Bandwidth Throttling

Nowadays, mobile devices are equipped with multiple radio interfaces, data centers provide redundant routing paths, and multihoming is the new tendency in existing, extensive server farms. Meanwhile, the unending growth rate of Internet traffic generation raises difficulties in meeting end user demands regarding bandwidth availability and Quality of Service standards, while TCP itself persists as a single-path transport protocol. Multipath TCP, as a set of extensions to legacy TCP, permits the simultaneous utilization of the available interfaces on a multihomed host, while preserving the standard TCP socket API. Consequently, smart terminals possess the distinct capability of leveraging path diversity in order to provide robust data transfers and enhance the overall connection performance. However, the implementation of Multipath TCP is still at a premature state. Ergo, we propose and evaluate a Multipath TCP Proxy as a mechanism towards the incremental adaptation of the extended protocol by service delivery platforms. Particularly, we examine the use of an HTTP Proxy as a protocol converter that will allow MPTCP-enabled clients to benefit from Multipath TCP even when communicating with legacy servers.

Introduction

Computer networks are continuously evolving. When the TCP/IP stack was originally designed, hosts were equipped with a single network interface. On modern epoch terminals, however, multiple wired and/or wireless interfaces are available. Despite its age, the Transmission Control Protocol (TCP) remains the dominant transport mechanism on the Internet in an era when smart devices crave to exploit their numerous, usually underutilized, interfaces and harvest the available network resources.

A number of protocols have been proposed to provide multihoming functionalities to end user devices without the use of legacy routing protocols, such as BGP. Two main categories can be identified: (a) host based solutions -where modifications should be implemented on user handsets and devices, and (b) router based solutionswhere end devices are left unchanged and new protocol implementations are fulfilled on router networking stack. Since multihoming and simultaneous usage of network interfaces should be agnostic of the basic network connectivity, solutions that are based on the introduction of middle-boxes seem more appropriate in multivendor and multi-ISPs environments. Ιn this paper we try to address the issues imposed from higher bandwidth requirements, especially on mobile nodes.

The first and more widely adopted approach is the SCTP (Stream Control Transmission Protocol). SCTP is a message-oriented protocol like UDP that requires SCTP associations over diverse network paths. SCTP is based on delivering chunks of information from different network interfaces, transported on different paths inside an IP network and finally multiplexed on host level. Even though SCTP is adopted from the vast majority of Operating Systems and is already used in the telecom industry as a replacement to the SS7 signaling protocol, SCTP cannot be consider as the optimal way forward for end-devices. The main drawback of SCTP implementations [START_REF] Dainotti | SCTP Performance Evaluation over Heterogeneous Networks[END_REF] is the high complexity and the negative effect on computing resources, which are relatively expensive on mobile nodes. Furthermore, existing experimental analysis of SCTP in heterogeneous networks demonstrates poor performance in high packet and bandwidth rates.

Another approach is the Loc/ID (Locator and Identity) separation method. In this context, the nodes have both an identity that uniquely distinguishes the end host and an associated locator that describes the network connectivity structure. This concept separates the two name spaces (identities and addresses), which are combined in traditional IP networks. In Loc/ID separation architectures the IDs are used for end to end communications, whereas the locators are assigned to different network interfaces. The main representative in this category is the LISP implementation for mobile nodes, described as Lisp-MN [START_REF] Menth | Improvements to LISP Mobile Node[END_REF]. LISP is not yet implemented on large scale networks and requires significant changes in the infrastructure of Internet Service Providers (ISPs). Furthermore, it lacks the functionality to parallel use multiple interfaces on the same dialogue maximizing throughput and user experience.

A third approach is Multipath TCP (MPTCP) [START_REF]MultiPath TCP -Linux Kernel Implementation[END_REF]. Multipath TCP enables an Internet device to efficiently use its multiple interfaces by installing a set of extensions on top of traditional TCP, which permit the establishment of additional TCP subflows under the umbrella of a single MPTCP session. Consequently, supplementary capabilities are introduced to the protocol's core functionality empowering features such as enhanced robustness against network malfunction, bandwidth aggregation, as well as dynamic data offloading. Moreover, cellular networks leveraging MP-TCP can enhance Quality of Experience (QoE) by providing robustness towards data communication technology availability and cell-to-cell service degradation. At the same time, MPTCP preserves the standard socket API and maintains backward compatibility with Legacy TCP at both the network and application levels. This fallback procedure serves also as a fail-safe mechanism, since MPTCP deployment is at a premature state and/or middle-boxes may strip down the MPTCP signaling options.

In an attempt to achieve effective "resource pooling" [START_REF] Wischik | The Resource Pooling Principle[END_REF] and aggregate the bandwidth available, MPTCP implements a congestion control mechanism coupled at the MPTCP-level of the transport layer [START_REF] Wischik | Design, implementation and evaluation of congestion control for multipath TCP[END_REF], consequently creating a coalescence of links effectively behaving as a shared channel of higher capacity. As a result, hosts are able to ceaselessly monitor the dynamic state of the network routes involved in data transfers and shift Internet traffic from degraded paths to more efficient ones according to the available bandwidth per utilized link. On the other hand, in order to ensure con-tinuous packet transmissions, unaffected by individual malfunctioning connections or link-related congestion phenomena, a unique receive window shared across all the TCP subflows is implemented at the recipient. Additionally, a buffer of adequate space is required [START_REF] Raiciu | How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP[END_REF], so as to assure in-order delivery of the information segments to the application layer. The buffering space should accommodate an increased amount of packets, compared to legacy TCP systems, in an effort to cope with the head-ofline blocking caused by the dissimilar transmission delays of the diverse routing paths.

Nonetheless, the deployment of MPTCP solutions is still lagging behind. Currently, a host can benefit from Multipath TCP only if its peer possesses MPTCPcapability as well. This requirement raises barriers in the deployment of MPTCP, since service delivery platforms dawdle as far as protocol installation is concerned [START_REF] Mehani | An Early Look at Multipath TCP Deployment in the Wild[END_REF]. While the multipath functionality can be introduced quite seamlessly to user equipment due to the frequent OS updates of personal computers and smart devices, such changes are more complex to conduct inside an Internet Service Provider's core infrastructure, especially on application servers handling a myriad of requests on a constant basis. The inset of an intermediate node as a protocol converter, aiming at the creation of a split TCP-MPTCP connection between the MPTCP-enabled clients and MPTCP-unaware systems, as illustrated in Fig. 1, may serve as a stepping stone towards the gradual incorporation of MPTCP, partially sidestepping initial compatibility issues and consequently user QoE degradation.

Multipath TCP Proxy

Deploying proxies as a middle-box is often not considered best practice by researchers [START_REF] Sherry | Making Middleboxes Someone Else's Problem: Network Processing as a Cloud Service[END_REF] regarding traditional network architectures and datacenter topologies [START_REF] Potharaju | Demystifying the Dark Side of the Middle: A Field Study of Middlebox Failures in Datacenters[END_REF]. Such deployments reduce the overall service availability, downgrade service performance by creating bandwidth bottlenecks, and increase the operational costs. Even though middle-boxes impose all these drawbacks, service providers are still keen on deploying them as a way to enforce network policies for charging or traffic steering purposes. Furthermore, installing middle-boxes is relatively common in order to benefit from new technologies without waiting to be adopted by terminals and network devices [START_REF] Yap | Making Use of All the Networks Around Us: A Case Study in Android[END_REF][START_REF] Fayazbakhsh | Enforcing Network-Wide Policies in the Presence of Dynamic Middlebox Actions Using FlowTags[END_REF].

Our proposal aims at the introduction of a protocol converter in the form of a Multipath TCP Proxy in order to provide multipath functionality on behalf of traditional TCP systems, bypassing compulsory protocol adaptation in the ISP core infrastructure [START_REF] Pollalis | HTTP Data Offloading Using Multipath TCP Proxy[END_REF]. As a result, MPTCP-capable hosts will be able to effectively take advantage of their enhanced, multipath features, while the established path redundancy will give network operators the opportunity to more efficiently distribute traffic load and mitigate bottleneck occurrences.

In addition, our MPTCP Proxy is enhanced with a bandwidth throttling [START_REF]Bandwidth Throttling[END_REF] mechanism as a reactive means for network traffic regulation and congestion minimization. The bandwidth manipulation algorithm, which runs inside the MPTCP Proxy, permits the application of load control policies, compatible with the specifications of Multipath TCP with regard to traffic engineering and billing purposes, while aiming at the satisfaction of Quality of Service (QoS) standards. The mechanism utilizes a Scapy [START_REF] Secdev | Scapy[END_REF] sniffer, which is responsible for monitoring the characteristics of incoming connections by parsing the options field of the TCP header. As soon as an MPTCP connection is established consisting of at least two active TCP subflows, the MPTCP Proxy throttles the desired TCP connection based on pre-determined criteria. The eventual traffic redirection is feasible due to the insertion of packet mangling rules on top of the Netfilter Framework [START_REF]netfilter: firewalling, NAT, and packet mangling for Linux[END_REF].

The overall scheme allows operators to get in the middle of the process of outgoing data scheduling by virtually sub-dividing a packet queue into multiple ones and re-configuring them using classful queuing disciplines. Each independent queue is responsible for the management and forwarding of packets of a predetermined destination, allowing network operators to manipulate Internet traffic by assigning the most fitting packet queue to specific TCP subflows based on routing policy criteria. The concurrent utilization of diverse wired and/or radio access technologies in conjunction with the application of capacity limitation techniques creates the illusion of less suitable routing paths, ergo resulting in a force-steering of the forwarded traffic. As a result, it becomes possible to re-allocate network load and alleviate bottleneck phenomena, while harnessing the excess, available bandwidth, as well as offer MPTCP-enabled clients enhanced QoE due to the traversal of less congested areas.

Experimental Evaluation

We have evaluated our proposal in an experimental environment similar to the aforementioned Fig. 1, consisting of a Raspberry Pi Model B running Debian Wheezy on top of a custom, MPTCP-compatible 3.12.35+ Linux kernel, an MPTCP Proxy with kernel version 3.14.0 and Squid Proxy installed, equipped with the stable release v0.89.2 of the extended protocol, and a MPTCP-unaware HTTP server with Apache2 running on port 80. During our experimental scenarios we have disabled Squid's caching mechanism in order to measure pure forwarding performance. In particular, we examined the impact of memory space allotment with regards to the MPTCP attainable bandwidth, the responsiveness of our bandwidth throttling mechanism, as well as the packet forwarding delay inserted due to the protocol conversion process.

Baseline Scenario

In our initial experimental scenario, we depict the performance accomplished by Legacy TCP during direct communication between our Raspberry Pi and the MPTCPunaware HTTP server. Since the MPTCP Proxy is not explicitly introduced to our client-side device, the negotiation of multipath functionality fails between the end hosts. As the MPTCP options embedded inside the TCP header cannot be interpreted by the legacy server-side system, multipath support is not advertised by the HTTP server causing the RPi to fall back to regular TCP and only establish a single -traditional -TCP connection. Fig. 2 illustrates the achieved throughput for two types of TCP sessions, a wired and a wireless connection, respectively.

Fig. 2. Legacy TCP performance

Dyna mic Load Balancing

Since in our current setup the MPTCP-enabled Raspberry Pi is still unable to simultaneously utilize both its network interfaces, we inset our MPTCP Proxy as an intermediate node in order to provide multipath functionality on behalf of the legacy TCP server. The MPTCP session terminates on the client-side of the protocol converter, while a regular TCP connection is initiated on the server-side towards the desired destination. Fig. 3 depicts the aggregated throughput achieved under MPTCP's modified congestion control algorithm.

Fig. 3. Multipath TCP performance

As the Ethernet interface offers a higher link capacity alongside a smaller Round Trip Time (RTT) value compared to the wireless connection, the respective subflow's congestion window tends to inflate faster, ergo allowing for the largest percentage of packets to be forwarded via the wired routing path. On the other hand side, the wireless link remains almost fully underutilized, since MPTCP perceives it as an inferior alternative for load balancing or data offloading in the absence of congestion on the wired connection. Therefore, the observations above come to confirm MPTCP's capability to strip data across the most efficient of the available paths, while offering no less capacity compared to a legacy TCP session.

TCP Buffer Size Impact on M PTCP Performance

TCP Memory Allocation. One of the major challenges arising as a consequence of the deployment of MPTCP solutions is the allocation of adequate buffering space in order to cope with the increased demands regarding packet reordering at the receiver [START_REF] Barré | Multipath TCP: From Theory to Practice[END_REF]. The disparate propagation delays along the utilized network links create discontinuities in the re-assembled information stream, since TCP segments often reach their final destination out of sequence. In such case, the head-of-line blocking effect becomes quite noticeable, temporarily interrupting the final in-order delivery to the application layer. Fig. 4 illustrates the performance of MPTCP corresponding to two distinct receive buffer configurations. According to MPTCP specifications, the required accommodation space for TCP segments amounts to a maximum of 0.48 ΜΒ. As clearly shown in Fig. 4a, adopting a lower bound results in data loss at the receiver, leading to unavoidable packet retransmissions and an overall service degradation. On the other hand, Fig. 4b depicts a much more efficient data transfer. Besides the naturally stable behavior of the wired access link, the wireless interface achieves a satisfactory throughput rate, as well, especially if we additionally consider the potential randomness of the wireless transmission environment resulting in elevated propagation delays. The TCP memory allocation is adequate enough to sustain a constant delivery rate of segments to the application layer, minimizing the impact of head-ofline blocking. In general, MPTCP paths of commensurate delays tend to decrease receiver memory consumption even close to zero, since packets routed over different paths arrive timely at their destination without causing extensive gaps in the packet sequence at the recipient. Fig. 5. MPTCP performance degradation as a result of decreasing MTU size down to 1000 bytes, while keeping buffer size at 0.72 MB Maximum Transmitted Unit Size Adjustment. Similar considerations apply in case of Maximum Transmitted Unit (MTU) size variations. Intuitively, a large MTU size leads to higher data rates, since the number of interrupts, which need to be processed by the receive system, diminishes. On the other hand, a small MTU size compels the recipient to handle an increased amount of TCP segments provoking packet dropping, as depicted in Fig. 5, and overall destabilizing the MPTCP session compared to Fig. 4b. Default MTUs carry enough payload so as to cause no impairment during the data transmission, while gradual size reduction leads more swiftly to service degradation compared to legacy TCP systems. This more abrupt impact derives from a combination of reasons, including the increased number of packets that need to be handled and their dissimilar transfer delays. Since more packets are accommodated inside the receive buffer, the re-ordering process becomes more intense due to the different arrival periods of consequent segments. Practically, in case of MTU size variations, a proportionate TCP memory extension should be allocated in order to cope with buffering demands and avoid service quality downgrading.

Bandwidth Throttling M echanism

While Multipath TCP is capable of pooling the accessible network resources per interface, spreading load over a wider network, as well as achieving dynamic data offloading, the parallel application of bandwidth throttling allows for further traffic manipulation. Administrators are capable of further managing the MPTCP sessions and force-shifting data across eclectic routing paths, while offering the multipath connection no less capacity than a single-path TCP session. This is all feasible via the prioritization of the TCP subflows by applying the desired levels of bandwidth restriction per available network interface, ergo outsmarting MPTCP into perceiving select TCP connections as less efficient paths for packet routing, even though their potential link capacity indicates otherwise. As a result, packet flows can be redirected away from congested areas, while concurrently alleviating bottlenecks. Fig. 6a illustrates the effect of the bandwidth restriction introduced on the Ethernet interface of our Raspberry Pi. The process completion delay alongside the moderate utilization of the available resources tends to cause a miniature impact on delivery time. However, even if the queuing disciplines are not configured timely in case of transfers of minimal size, a tolerable scenario for network-friendly communications in terms of congestion, the desired control policies will be already installed in order to support future multipath transmissions without the original process overhead, as depicted in Fig. 6b. As soon as the control policies have been established, the MPTCP congestion control algorithm tends to offload data to the wireless connection, which manages to achieve a higher throughput rate compared to throttling-free transmissions (Fig. 4b). Moreover, the overall connection performance becomes slightly inferior to regular data transfers (Fig. 4b) due to the extreme underutilization of the Ethernet link, a differentiation that can be undone by the proper reconfiguration of the capacity limitation levels. Nevertheless, the bottom line is that MPTCP still outperforms legacy TCP, as well as meets its design goals.

Protocol Conversion Delay

Table 1 presents the chain-performance of the MPTCP Proxy regarding protocol conversion and packet forwarding. The measurements were attained via the insertion of IPtables mangling rules on top of the Netfilter Framework, which targeted corresponding packets of specific characteristics on both communication ends. As a matter of fact, our middle-box tends to synchronize one session at a time. Therefore, the MPTCP-to-TCP SYN segment conversion delay is equivalent to the time between the client-side connection establishment and the server-side 3-way-handshake initialization. Moreover, data segments are reconstructed internally, meaning they are converted and forwarded, after they have been received by the application layer. Of course, such interaction between low-level kernel and user space tends to introduce additional conversion delay, as packets are processed along the entire TCP/IP stack. Furthermore, since the system is actually hosted inside an ESXi hypervisor, the server is also running on constrained memory resources and computation power, ergo its proportionate underperformance. Undoubtedly, an application-level solution cannot ensure effective service delivery in real world networks compared to -preferably application agnostic -highly performing kernel module implementations [START_REF] Detal | Multipath in the Middle(Box)[END_REF]. Such solutions can provide efficient protocol conversion by minimizing unnecessary memory allocations and costly read()write() system calls.

Conclusion

The traditional TCP protocol obeys rigorously to the end-to-end connection principle, thus deterring smart terminals from efficiently exploiting their numerous network access interfaces. While TCP is upper bounded by the available capacity of the bottleneck link, Multipath TCP permits the concurrent distribution of traffic load over a wider network. As a consequence, MPTCP enhances user experience by providing improved performance alongside redundancy, as well as mitigates congestion via dynamic data offloading between the available network links.

Since MPTCP capability still remains to be implemented on the server side, the deployment of a MPTCP Proxy at the ISP infrastructure can provide multipath functionality on behalf of legacy TCP systems, as well as allow MPTCP-enabled clients to achieve effective "resource pooling", without the requirement for service providers to undergo major changes inside their core network. However, technical and economic concerns emerge regarding protocol adaptation, such as increased buffer space demands, which may lead to infrastructure upgrades and more expensive implementations; re-evaluation of existing mechanisms, such as TCP's re-ordering algorithm in order to effectively handle re-ordering events and lessen head-of-line blocking phenomena, as well as revision of today's routing policies in order to cope with MPTCP path utilization.

Thereupon, we emphasized the importance of memory allocation sufficiency and how inadequate buffer space can lead to performance degradation. In addition, we introduced a bandwidth throttling technique as a means to apply traffic engineering schemas compatible with MPTCP path utilization without downgrading service quality. Finally, we underlined the importance of application-agnostic, kernel module implementations in order to efficiently cope with real world networks' demands by minimizing superfluous system processes and overall protocol conversion overhead.

Fig. 1 .

 1 Fig. 1. Creation of the split TCP-MPTCP connection, after insertion of the MPTCP Proxy in between the communication ends.

Fig. 4 .

 4 Fig. 4. MPTCP performance based on different receive buffer configurations. Max memory allocation set at (a) 0.18 MB, (b) 0.72 MB

Fig. 6 .Fig. 7 .

 67 Fig. 6. Application of bandwidth throttling on the wired network interface (a) initial 5 MB file transfer, (b) 5 MB file re-transmitted

Table 1 .

 1 Conversion time within the MPTCP Proxy between the MPTCP and TCP connections

		SYN	Data
	Time (sec.)	0.0078341 ± 0.0006805	0.0153311 ± 0.0080645


Ahmed Abujoda

Razzaghi Hadi

Panagiotis Kouchaksaraei

Papadimitriou
email: panagiotis.papadimitriou@ikt.uni-hannover.derazzaghi.kouchaksaraei@stud.uni-hannover.de

SDN-based Source Routing for Scalable Service Chaining in Datacenters

The migration of network functions (NFs) to datacenters, as promoted by Network Function Virtualization (NFV), raises the need for service chaining (i.e., steering traffic through a sequence of NFs). Service chaining is typically performed by installing forwarding entries in switches within datacenters (DCs). However, as the number of service chains in DCs grows, switches will be required to maintain a large amount of forwarding state. This will raise a dataplane scalability issue, due to the relatively small flow table size of switches. To mitigate this problem, we present a software-defined network (SDN) based source routing architecture for scalable service chaining, at which the NF-path path is encoded into the packet header obviating the need for any forwarding state and lookup in the switches. We assess the feasibility and efficiency of our architecture using a prototype implementation.

Introduction

Network Function Virtualization (NFV) is an emerging concept aiming to replace special-purpose and hardware-based middleboxes with software-based network functions (NFs) deployed on virtualized infrastructures [START_REF] Dobrescu | RouteBricks: Exploiting Parallelism To Scale Software Routers[END_REF] [8] [START_REF]T-NOVA Project[END_REF] [21] [START_REF] Sherry | Making Middleboxes Someone Elses Problem: Network Processing as a Cloud Service[END_REF]. Inspired by the success of cloud computing, NFV strives to introduce new business models to the network operators (e.g., NF as a service (NFaaS)), enabling the migration of middleboxes to Network Function Providers (NFPs) in a pay-peruse manner. This can lead to a significant reduction in capital and operational expenses, while enabling elastic provisioning based on service demand. Opting to support NFV and offer NFaaS, many Internet Service Providers (ISPs) have already started to deploy micro-datacenters on their networks for NFaaS offerings to their clients [START_REF] Frank | Collaboration Opportunities for Content Delivery and Network Infrastructures[END_REF].

To implement security and access control policies, middleboxes are deployed in certain locations in enterprise networks, such that traffic can traverse them in a particular order (e.g., a firewall should be deployed before a load balancer to filter malicious traffic). This order needs to be maintained when migrating NFs to NFPs' datacenters (DCs). In other words, there is a need for steering traffic through NFs deployed in DCs to ensure compliance with the client's policy. The so-called service chaining can be performed in DCs via the installation of forwarding entries in switches, such that the traffic traverses the NFs in the exact order specified by the client (i.e., as prescribed in the service chain [START_REF] Gember | Stratos: Virtual middleboxes as first-class entities[END_REF], [START_REF] Quinn | Problem Statement for Service Function Chaining[END_REF]). We refer to this approach as rule-based service chaining. Several studies have investigated rule-based service chaining in enterprise and wide-area networks [START_REF]CISCO Policy-based routing[END_REF], [START_REF] Qazi | SIMPLE-fying middlebox policy enforcement using SDN[END_REF], [START_REF] Zhang | StEERING: A Software-Defined Networking for Inline Service Chaining[END_REF]. However, an increasing number of service chains will require a substantial amount of forwarding state in switches, which, in turn, will raise a dataplane scalability issue for NFPs, due to the relatively small flow table size of switches (i.e., a switch flow table can typically store a few thousand entries).

To mitigate this problem, we employ source routing to steer traffic through the NFs of a service chain. In particular, the NF-path is encoded into the packet header obviating the need for any forwarding state and lookup in the switches, i.e., switches forward packets based on the information carried in the packet header. Source routing is an attractive solution for DCs where the number of hops is relatively small (typically there are three switches between access gateways and any server in a DC) in comparison to ISP and enterprise networks [START_REF] Soliman | Exploring source routed forwarding in SDN-based WANs[END_REF], [START_REF] Ashwood-Smith | SDN State Reduction[END_REF], [START_REF] Hari | Path Switching: Reduced-State Flow Handling in SDN Using Path Information[END_REF]. Furthermore, as opposed to the wide-area, source routing does not raise any serious security concerns within DCs, since only switches and hypervisors (on virtualized servers) managed by the DC network operator can insert or remove paths from packet headers. However, source routing raises a set of challenges in terms of scalability and performance. More specifically, the encoded path may increase the packet size beyond the maximum segment size (e.g., 1500 bytes for Ethernet). As such, there is a need to minimize the packet header space used for source routing. Furthermore, source routing should yield packet forwarding rates as high as in rule-based forwarding.

Service chaining with source routing raises the following requirements: (i) the discovery of switch output ports based on the NF-path in order to compose the source routing header, (ii) the encapsulation of the source routing header into the incoming packets, and (iii) traffic steering based on the source routing header. To meet these requirements, we present a software-defined network (SDN) based source routing architecture for scalable service chaining in DCs. We rely on a centralized controller to collect information about the switch ports and subsequently derive the sequence of output ports for each service chain. In this respect, we assume the presence of service mapping techniques, i.e., the assignment of service chains to DC networks [START_REF] Dietrich | Network service embedding across multiple providers with nestor[END_REF], [START_REF] Abujoda | DistNSE: Distributed Network Service Embedding Across Multiple Providers[END_REF]. The controller uses Open-Flow [START_REF] Mckeown | OpenFlow: Enabling Innovation in Networks[END_REF] to insert the service routing header in the incoming packets at the core switches. We have further implemented a datapath using Click [START_REF] Kohler | The Click Modular Router[END_REF] for packet forwarding using the source routing header. We study the feasibility of our architecture using a prototype implementation. Our experimentatal results show that our source-routing based approach for service chaining yields high packet forwarding rates, low header insertion delay (i.e., flow setup time), and a significant reduction in the control communication overhead in DCs.

The remainder of the paper is organized as follows. Section 2 presents our architecture for source routing within DCs using SDN. Section 3 discusses the implementation of our architecture components. In Section 4, we evaluate the performance of our source routing datapath and controller. Finally, Section 5 highlights our conclusions.

Service Chaining Architecture

In this section, we elaborate on our source routing based approach for service chaining. Consider the example in Fig. 1 where traffic needs to be routed through three NFs deployed on servers within a DC for service chaining. A straightforward approach is to install a forwarding entry in each switch on the path connecting the NFs, for each service chain. Despite its simplicity, this approach requires maintaining the state of each service chain on multiple switches (in this example, 7 entries for one chain are required) which restricts the number of service chains that can be deployed on a DC (given the small flow table size in switches). Using source routing instead, the path between the NFs can be encoded into the packet header at core switches, eliminating the need for inserting forwarding state on each switch on the path.

Along these lines, we propose to encode the sequence of switch output ports into the header of each packet. For instance, to steer traffic through NF1 and NF2, each packet should carry the port numbers 1, 3, and 5. As such, each switch can merely extract the output port number from the packet and forward it accordingly (e.g., switch A will extract and forward to port number 1). To allow the switches to identify the corresponding port numbers (out of a sequence of port numbers encoded into the packet), we add a counter field to the routing header. This counter identifies the next port number to be read by the next switch on the path, i.e., the counter field specifies the location of the corresponding port number from the beginning of the routing header. For example, when reaching switch B, the counter will carry the value of 6 indicating that switch B should read the sixth field on the port number starting from the beginning of the routing header (Fig. 1). The value of the counter is decremented at each switch to indicate the next port number to be read. In the following, we describe a source routing based architecture for service chaining leveraging on SDN. Our architecture consists of four main components (Fig. 2):

-Source Routing Encapsulation (SRE) switch is an OpenFlow [START_REF] Mckeown | OpenFlow: Enabling Innovation in Networks[END_REF] switch which inserts the source routing header into each incoming packet based on the configuration provided by the source routing controller. In a DC we consider SRE switch functionality at the core level.

-Source routing controller provides support for: (i) topology discovery to keep track of the different links and switches on DC network, (ii) path-toports translation to identify the corresponding switch output ports for the NF-path, and (iii) flow table configuration on SRE switches for the insertion of source routing headers on incoming packets.

-Source routing switch extracts the output port from the source routing header and forwards the packet accordingly. This role is mainly fulfilled by aggregation and top-of-the-rack (ToR) switches.

-Southbound interface provides an interface for the controller to install flow entries on SRE switches and perform topology discovery (i.e., collect information about the switch port numbers and active links).

-Northbound interface enables the NFV orchestrator to submit the service chain mapping to the source routing controller.

Inserting the port numbers of the entire path on the packet headers may significantly increase the packet size leading to high bandwidth consumption and/or packet sizes beyond the maximum segment size (MSS). For instance, a service chain consisting of 10 NFs which are assigned to different racks requires a routing header with 30 port numbers. Assuming each port number is carried on 8-bits field, a routing header adds 31 extra bytes (1 byte is needed for the counter field) to each incoming packet. This would lead to the consumption of 48% more bandwidth for packets with the size of 64 bytes and the fragmentation of packets with a size larger than 1470 bytes (with Ethernet).

To mitigate this problem, we use more than one SRE switches along the path. In this respect, the service chain is subdivided into pathlets where each pathlet starts and ends with an SRE switch. The location and number of SRE switches are identified by the DC network operator based on the DC network topology and the employed service mapping algorithm. Minimizing the number of racks used for each service chain reduces the number of hops and consequently, the number of SRE switches per chain.

An alternative approach is to deploy both SRE switch and source routing functionality within all DC switches, allowing the DC operator to dynamically install routing headers on packets in different locations of the network. To identify packets reaching the end of their pathlet, we use the zero value of the counter field (indicating no further ports to read). While this approach provides more flexibility, it increases the complexity of the switch design. To quantify the benefits of source routing, we calculated the amount of forwarding state required to steer traffic across a service chain's path using source routing (with a single and multiple SRE switches -1 SRE switch for 10 hops) and rule-based forwarding. According to Fig. 3, source routing with a single and multiple SRE switches achieves a significant reduction in the state compared to rule-based forwarding.

Implementation

In this section, we discuss the implementation of our architecture components:

-Source routing header. To insert the routing header into the incoming packets, we use the destination MAC address and further add a VLAN tag and a MPLS label stack to each packet. In particular, we encode the port numbers in the destination MAC address, the VLAN ID, and the MPLS label (OpenFlow 1.0, which we use for our implementation, does not allow modifying other VLAN and MPLS fields). By combining these fields, we can store 10 port numbers per packet, where each field is 8-bit long and supports switches with up to 256 ports. To store the counter value, we use the TTL field of the MPLS header. We can further increase the number of encoded ports by inserting more MPLS stack labels in each packet. -Source routing controller. We use POX [START_REF] Pox | [END_REF] to implement the different components of our controller. Using OpenFlow, the controller collects and stores the port numbers of each switch. Based on this information, the controller extracts the switch ports for each service chain path. Subsequently, the controller inserts the port numbers into a bit vector. This bit vector is further broken down into the MAC destination address, the VLAN ID and the MPLS label. Next, a flow entry is installed in the SRE switch using OFPT VENDOR [START_REF]OpenFlow Switch Specification v1.0[END_REF] message. This message carries the flow matching fields (e.g., source/destination IP, source/destination port numbers and protocol), the VLAN tag, the MPLS stack, the destination MAC address as well as the output port number.

-SRE switch. We rely on OpenvSwitch [START_REF] Openvswitch | [END_REF] to insert routing headers on the arriving packets. OpenvSwitch exposes an OpenFlow interface to the controller to install forwarding rules. As such, the controller inserts the routing headers on the packets by adding a VLAN tag and a MPLS label stack to each packet and updating its destination MAC address.

-Source routing datapath. We extend Click Modular Router [START_REF] Kohler | The Click Modular Router[END_REF] with a new element, SourceRouter, which extracts the values of the VLAN ID, MPLS label, MPLS TTL, and the destination MAC address and subsequently combines them into the routing header (see Fig. 1). Based on the counter value, the element reads the corresponding port number through which the packet is forwarded. Combining our element with existing Click elements for packet I/O, we implement a source routing datapath (Fig. 4).

Experimental Evaluation

In this section, we evaluate the performance of our source routing datapath and controller. In particular, we use our emulab-based testbed to measure the packet forwarding rate and the computational requirements of our source routing switch, as well as the setup time and communication overhead of our controller. We run our experiments on 4 servers equipped with an Intel Xeon E5520 quadcore CPU at 2.26 GHz, 6 GB DDR3 RAM and a quad 1G port network interface cards (NICs) based on Intel 82571EB.

Source Routing Switch Performance

To measure the packet forwarding rate, we deploy our source routing datapath on one server and use two other servers as traffic source and sink. The switch and destination servers run Click modular router 2.0 in kernel space on Linux kernel 2.6.32. To generate traffic, we use a NetFPGA-based [START_REF]NetFPGA[END_REF] packet generator which is installed on and controlled through our source server. Since the switch on our testbed filters packets with VLAN and MPLS header, we encapsulate our packets in IP-in-IP header. We measure the forwarding rate of our switch with packet sizes of 85 bytes including the source routing header and the IP encapsulation header. We further compare our switch performance with rulebased forwarding where we forward packets based on packets' destination IP address using a routing table with 380K entries. Fig. 5 shows that our source routing switch achieves more than 30% higher forwarding rate than rule-based routing. This performance is achieved using a single CPU core. Furthermore, we use Oprofile 1.1.0 [17] to measure the computational overhead of our switch in terms of CPU cycles per packet. As depicted in Table 1, our source routing datapath consumes less than 8% of the total CPU cycles per packet. On the other hand, packet I/O operations represent the dominant share of the CPU cycles/packet. Similar results for packet I/O operations are shown in [START_REF] Abujoda | Profiling Packet Processing Workloads on Commodity Servers[END_REF].

Controller Performance

To evaluate the performance of our controller, we use 4 servers, two of which act as traffic source and sink, while the other two servers host the controller and the SRE switch. Initially, we measure the flow setup time (i.e., the time required to insert the source routing header at the SRE switch) which we define as the time elapsed from the flow's first packet arrival at the SRE switch ingress port till its departure from the egress port.

As depicted in Fig. 6, the flow setup time does not change significantly across the various flow arrival rates. We further break down the setup time into multiple components. In particular, we measure the time required for the source routing header computation, the time the control packet takes to traverse the POX and kernel stack on the controller server in both directions (between the controller and the switch), the RTT (between the controller and the SRE switch) and the SRE switch processing time. As shown in Table 2, source routing header computation consumes less than 29% of the total setup time. Instead, most of the setup time is spent in POX, kernel stack, and the SRE switch processing. We also compare source routing with rule-based forwarding in terms of control communication overhead. We first measure the communication overhead on a single switch for different flow arrival rates. In this respect, we measure the control traffic between the switch and controller per direction (noted as uplink and downlink overhead). Our measurements show that both source routing and rule-based forwarding consume the same amount of bandwidth at the uplink (Fig. 7(a)), since both approaches use the same packet size and format (i.e., OFPT PACKET IN [START_REF]OpenFlow Switch Specification v1.0[END_REF]) to transfer the packet fields to the controller. On the other hand, for downlink, source routing consumes more bandwidth than rulebased forwarding (Fig. 7(b)), due to the extra packet fields (i.e., VLAN and MPLS) required to install the source routing header.

Using the results we obtained for a single switch, we further calculate the communication overhead with a diverse number of switches. For our calculation, we consider DCs with a fat-tree topology [START_REF] Al-Fares | A scalable, commodity data center network architecture[END_REF] (Fig. 8). The DC components in a fat-tree topology can be modeled based on the number of ports per switch. More precisely, a fat-tree topology with k-port switches has (5(k 2 ))/4) switches where (k/2) 2 of these switches are core switches and k 2 are aggregation and edge switches. We calculate the control overhead of source routing and rule-based forwarding for fat-tree topologies with a diverse number of ports per switch. As shown in Fig. 9, source-routing introduces significantly lower communication overhead in comparison to rule-based forwarding. We observe that the savings in communication overhead increase with the size of the DC network, since the source routing controller needs to communicate only with the core switches of the DC (Section 1).

Conclusions

In this paper, we presented SDN-based source routing architecture for service chaining within DCs. Our architecture encodes the path of each service chain into the packet headers leading to reduction in the forwarding state per switch and better dataplane scalability. To insert the source routing header into the incoming packets, we implemented a centralized controller that extracts switch output ports from the chain's path and subsequently encodes the port numbers into the packet headers by configuring SRE switches with OpenFlow. We further implemented a source routing datapath for packet forwarding based on the source routing header. Using our prototype implementation, we showed that our source routing datapath achieves high packet forwarding rates and incurs low computational overhead. In addition, we showed that our controller incurs low flow setup delay and achieves a significant reduction in communication overhead in comparison rule-based forwarding, for different DC network sizes.

In future we will seek to coordinate service mapping (e.g., using our service chain-to-DC mapping algorithm in Nestor [START_REF] Dietrich | Network service embedding across multiple providers with nestor[END_REF]) with SRE switch placement to achieve savings in terms of forwarding state and provide support for NFV deployments at massive scale.

Fig. 1 .

 1 Fig. 1. Example of service chaining using source routing.

Fig. 2 .

 2 Fig. 2. Source routing architecture.

Fig. 3 .

 3 Fig. 3. Forwarding state with source routing and rule-based forwarding.

Fig. 4 .

 4 Fig. 4. Source routing datapath implementation with Click.

Fig. 5 .

 5 Fig. 5. Packet forwarding rate of our source routing datapath with a single CPU core.

Fig. 6 .

 6 Fig. 6. Setup time per flow.

Fig. 7 .

 7 Fig. 7. Controll overhead for a single switch.

Fig. 8 .

 8 Fig. 8. Fat tree DC network topology.

Fig. 9 .

 9 Fig. 9. Control overhead for multiple switches.

Table 1 .

 1 Average CPU cycles/packet

	Element	cycles/packet Percentage
	Source Routing Switch	156	7.9%
	Packet I/O	1008	51.3%
	Encapsulation	259	13.2%
	Decapsulation	81	4.2%
	Others	458	23.4%
	Total	1965	100%

Table 2 .

 2 Flow setup time

	Element	Time (milliseconds)
	Source routing header computation	0.25
	POX processing + kernel stack	0.24
	RTT	0.1
	SRE switch processing	0.3
	Total	0.89

Acknowledgments

This work was partially supported by the EU FP7 T-NOVA Project (619520).


Mohammad Javad Shamani
email: m.shamani@student.unsw.edu.au

Weiping Zhu
email: w.zhu@adfa.edu.au

Saeid Rezaie
email: s.rezaie@wtiau.ac.ir

On the Energy Inefficiency of MPTCP for Mobile Computing

Keywords: MPTCP, Mobile device, Energy, MDP

Mobile devices have embraced Multi-Path TCP (MPTCP) for leveraging the path diversity. MPTCP is a double-edged sword since mobile phones are suffering excessively from short battery life span. In order to find energy efficiency of MPTCP, the signal quality and the transferred file size have been taken into account. We formulate the above problem as a Markovian Decision Process (MDP) for symmetric and asymmetric network traffic. Numerical and simulation results surprisingly show that MPTCP is not efficient in any selected scenarios and the proposed scheme can save 56% of energy compared to the conventional MPTCP.

Introduction

Wide coverage oriented cellular base stations and WiFi hot-spots coverage go hand in hand with arming mobile phones by different transmission interfaces such as cellular and WiFi, enhance the users' ubiquitous connectivity. Due to the error-prone nature of wireless channels, poor wireless signal quality is frequently experienced spatially and temporally by end users. It has been shown that the signal quality in WiFi or cellular-based networks dips in most cases. For instance, 43% and 21% of mobile phone data traffic is transmitted during low cellular and WiFi signal strength, respectively [START_REF] Ding | Characterizing and modeling the impact of wireless signal strength on smartphone battery drain[END_REF]. In addition, low signal strength could drain the mobile device battery. Due to the limited nature of mobile phone batteries, meeting high quality of service (QoS), while maintaining reasonable level of energy consumption, is of great importance for end-users. It is noteworthy that reaching high QoS and energy efficiency is not possible, in many cases, due to their conflicting requirements. Thus, designing a proper scheme to obtain reasonable levels of QoS and energy efficiency is critical.

Recently, MPTCP is introduced to enhance TCP performance by exploiting the path diversity [START_REF] Ford | Architectural guidelines for multipath tcp development[END_REF][START_REF] Wischik | Design, implementation and evaluation of congestion control for multipath tcp[END_REF]. However, base MPTCP suffers from energy inefficiency in mobile phones. For instance, when a mobile phone experiences poor signal quality, not only is an adverse effect on energy consumption inevitable, but also QoS degradation is unavoidable. In [START_REF] Shamani | Signal aware multi-path tcp[END_REF] we show that the available bandwidth could be estimated by getting the signal quality as an observation and applying hidden Markov model; however, throughput is a more trustworthy metric to understand the different platforms energy consumption. In order to estimate the throughput accurately it is also important to consider the transferred file size. We explore how file size affects the throughput and how to estimate the file size by queue dynamics. The objective of this paper is to investigate whether MPTCP is more energy efficient than WiFi and LTE in real scenarios by leveraging simultaneous uploads and downloads in symmetric and asymmetric traffic pattern. Therefore, we proposed Signal Aware MPTCP (SA-MPTCP) to enhance MPTCP energy efficiency. The contribution of this paper is threefold as follows:

• We make a tight relation between signal quality, file size and energy consumption; besides the optimization problem is formulated as a Markovian decision making problem by employing buffer size dynamics to better understand transferring file sizes.

• We endeavor to minimize energy consumption by exploiting diverse characteristics of interfaces, and for the first time we have found that MPTCP is not energy efficient in real scenarios, particularly in simultaneous uploading and downloading.

• We investigate the effect of energy consumption on asymmetric and symmetric data traffic for a mobile user facing variety of signal strength on different interfaces.

The paper is organized as follows. Section 2 introduces the energy model, and shed light on the effect of file size on MPTCP throughput. Section 3 describes the problem formulation. Section 4 outlines the simulation results, and Section 5 reviews the related works. Finally, we conclude in Section 6.

proposed model

The proposed model aims to optimize the transmission energy consumption as a utility function based on signal strength and transferring file size. In the following, we describe the underlying network model and assumptions for the problem at hand.

Energy model

The energy model used here addresses energy consumption for uploading and downloading by taking throughput into account. Where throughput would be estimated in our optimization problem by the interface's signal-to-noise ratio (SNR) and the transferring file size. To the best of our knowledge, the energy model introduced in [START_REF] Lim | Improving energy efficiency of mptcp for mobile devices[END_REF] is the only proposed model that analyses energy consumption for WiFi, cellular networks and MPTCP. Considering this, we use the same concept in describing network model. We assume that the mobile device is equipped with two interfaces to transmit data. Let i denote the interface, where i = w and i = l represent the WiFi and LTE interface, respectively. Available uplink and downlink throughput for interface i is denoted by T h u,i and T h d,i , respectively.

The energy consumption in uploading data for interface i which is based on Joule (J) per byte (B), and is defined by

E u i E u i = (α u i × T h β u i u,i ) (µJ/B), (1)
where α u i and β u i are upload packet transfer coefficients of interface i, which are obtained through regression model in [START_REF] Lim | Improving energy efficiency of mptcp for mobile devices[END_REF]. Similarly, for downloading, we have

E d i = (α d i × T h β d i d,i ) (µJ/B), (2)
where α d i and β d i are download packet transfer coefficient in interface i. Hence, total energy consumption of interface i in downlink and uplink can be formulated as E i which is equal to

E i = E u i × L u i + E d i × L d i (J), (3)
where L u i and L d i are the size of uploading and downloading files in bytes for interface i, respectively. In [START_REF] Lim | Improving energy efficiency of mptcp for mobile devices[END_REF], it has been shown that due to the concurrent use of interfaces (WiFi and LTE) in MPTCP, the energy consumption is less than total energy consumption of WiFi and LTE, if they are not used jointly. MPTCP energy consumption, denoted as E m , can be written as

E m = (E w + E l ) -θ, (4)
where θ represents the shared component energy. In MPTCP about 13% ∼16% energy would be consumed simultaneously [START_REF] Lim | Improving energy efficiency of mptcp for mobile devices[END_REF]. Thus, in this paper we consider θ as a fixed number 14.5%. Packet transfer coefficients for different platforms based on uplink and downlink are shown on table 1.

Effect of file size on throughput

Estimating the available bandwidth by knowing the signal quality is possible. For instance, Fig. 1 shows the uplink and downlink throughput as a function of received signal strength indicator (RSSI), where data is extracted from [START_REF] Schulman | Bartendr: a practical approach to energy-aware cellular data scheduling[END_REF], [START_REF] Ding | Characterizing and modeling the impact of wireless signal strength on smartphone battery drain[END_REF], and [START_REF] Lim | Cross-layer path management in multi-path transport protocol for mobile devices[END_REF]. However, the amount of transfer size has a significant effect on MPTCP throughput. In Fig. Based on the available signal quality state and file size, the uplink and downlink throughputs could be estimated by a regression model. We have calculated the uplink and downlink coefficient for the noted RSSI states in table 2 and table 3. The uplink throughput for interface i is defined as

T h u,i = κ u i * (L u ) η u i + ι u i , ( 5
)
where κ u i and η u i are uplink coefficients for interface i. Downlink throughput is equal to

T h d,i = κ d i * (L d ) η d i + ι d i , (6)
where κ d i and η d i are defined as downlink coefficients for interface i. It is noteworthy that the number of selected states uplink and downlink tables should be calculated prior to the simulation.

Definitions

A mobile device decision making is based on the assumption that the system dynamics are determined by an MDP. MDP consists of the following elements:

= [p ri (r k i |r j i ), r 1 i ≤ r j i , r k i ≤ r n i ].
In [START_REF] Shamani | Signal aware multi-path tcp[END_REF] we have shown that how to find the most probable signal quality states by getting RSSI as an observation and in this paper we assume the signal quality state is known. Let S = R 1 ×R 2 = {(r 1 1 , r 1 2 ), (r 1 1 , r 2 2 ), ..., (r n 1 , r n 2 )} = {s 1 , s 2 , ..., s N } represent the total state space, where N = |R 1 | × |R 2 |. The action space A = {(on, on), (on, of f ), (of f, on)} denotes a set of all possible actions for both interfaces. Without loss of generality, let LTE be the first interface and WiFi be the second; consequently, (on, of f ) means LTE interface is active and the WiFi interface is idle.

The transition probability for the next state is p(s t+1 |s t , a t ). Since the state transition probability is the product of all state transition probabilities, we can rewrite it as where ζ(s t ) gives the signals quality state of the compound state s t . At time-slot t, when the action a t is taken, the system shifts to the state s t+1 ; therefore, the system incurs costs expressed as c(s t , a t , s t+1 ).

p(s t+1 |s t , a t ) = p ri (ζ(s t+1 )|ζ(s t ))p rj (ζ(s t+1) |ζ(s t )), (7)
Before discussing decision rules and policies, we have to shed light on cost calculation. In order to get the benefit of high accuracy of throughput estimation we need to have information about file size. Therefore, we use the backlog queue to have a better understanding of transferring file size.

Consider the proposed scheme operates n slotted times with time slots t ∈ {0, 1, 2, ...}. The uplink and downlink queues as defined as Q u and Q d , respectively. At the beginning of each time slot, new packets arrive randomly. Let λ t = λ 1 t , λ 2 t , λ N t be the arrival rate vector. The service rate vector at each time slot t is defined as

µ t = µ 1 t , µ 2 t , ..., µ N t .
The rate is calculated based on the selected action at time t. Let's define the queue backlog as Q t , then the next backlog state are driven by stochastic arrival and service rates. Thus, the backlogs dynamics are given by

Q t+1 = max[Q t -µ t , 0] + λ t . ( 8
)
In the proposed scheme at each time slot we only observe the arrival rate and the quality of signal strength. Then we employ Q t+1 to estimate the transfer file size in uploading and downloading. Let's define the expected immediate cost as

t (s t , a t ) =      E w + E l a = (on,on) E l a = (on,off). E w a = (off,on) (9)
In the explained MDP problem, the objective is minimizing the expected longterm cost which is defined as

v π (s) = min π E π { T t=1 γ t c π t (s t , a π t (s t ))}. ( 10
)
Solving (10) would be computationally expensive; therefore, Let's define a policy by π, which maps states to actions. MDP endeavorers to find a policy π that minimizes some cumulative function of the stochastic costs. Given a cost criterion, a policy has an expected value for every state, specifying the cost of mobile phone receiving from following a policy in that state. Policy π * is an best policy if there is no policy π ′ , and no state s such that value of π ′ be lower than the value of π.

Letting value of being at state s t+1 as v t+1 (s t+1 ), then in each time step we aim for an action which has the minimum cost. let's express it as

a * t (s t ) = arg min at∈At (c t (s t , a t ) + γv t+1 (s t+1 ), ( 11
)
where γ is a discount factor (0 ≤ γ < 1). Because this value shows the cost a mobile device incurs during one time period in the future, we may discount it by a factor γ. By using optimal action a * t (s t ), the optimal value is equal to

v t (s t ) = arg min at∈At c t (s t , a t ) + γv t+1 s t+1 (s t , a t )) = c t s t , a * (s t ) + γv t+1 s t+1 (s t , a * (s t )) . ( 12
)
Because the problem is a decision problem with stochastic components and the new information would be available after The decision is made, we need to add uncertainty to ( 12)

v t (s t ) = min c t (s t , a t ) + γ st+1∈S p(s t+1 |s , a t )v t+1 (s t+1 )) . ( 13
)
(13) is widely known as the standard bellman equation [START_REF] Puterman | Markov decision processes: discrete stochastic dynamic programming[END_REF]. We seek the best action in each state minimizing over policies. Thus, the expected cost provided by a policy π from time t onward is defined as

F π t (s t ) = E T -1 t+1 c t+1 (s t+1 , a π t+1 (s t+1 )) + c t (s t ) s t , ( 14
)
where F π t (s t ) represents the expected total cost in state s followed by a policy π from time t onward. To find ( 14) solution, we need to recursively calculate v π t . It has been shown that ( 14) is equal to v π t (s t ) [START_REF] Powell | Approximate Dynamic Programming: Solving the curses of dimensionality[END_REF]. By letting v t (s t ) as a solution for (13), we will have

F * t = min π∈Π F π t (s t ) = v t (s t ). (15)
There are several ways to solve the infinite horizon optimization problems. For example, value iteration, or policy iteration algorithms [START_REF] Powell | Approximate Dynamic Programming: Solving the curses of dimensionality[END_REF]. The value iteration algorithm estimates the value function iteratively. At each iteration the best decision will be selected by a policy. In fact, value iteration begins at the end, and then goes backward to find out the best policy. The iteration counter starts at 0, and goes up until the algorithm satisfies the left-hand-side of (16). Thus, v is the largest absolute value, and the value iteration algorithm stops if the largest modify in the value of being in any state is less than the right-hand-side of (16).

∥v n -v n-1 ∥ < ϵ(1 -γ)/2γ, ( 16
)
where ϵ is an error tolerance parameter [START_REF] Powell | Approximate Dynamic Programming: Solving the curses of dimensionality[END_REF].

Simulation and results

In order to appraise the proposed algorithm, we have performed the simulations by ns-3 (https://www.nsnam.org). The simulation parameters are included in table 4. We have considered three LTE and three WiFi signal quality states. Based on the selected states, we found nine spots on the simulation field as it noted in Fig. 4. We calculated nine upload and download tables as in table 2 Comparing SA-MPTCP to MPTCP, WiFi, and LTE, SA-MPTCP saves 56%, 16% and 65% energy, respectively. On the other hand, MPTCP is 23% more throughput efficient than SA-MPTCP. However, SA-MPTCP achieves a higher throughput compared to WiFi and LTE.

Related works

MPTCP has been investigated widely from different perspective; nonetheless, energy efficiency attracts the growing interest of researchers. Comparison of TCP over LTE and WiFi with MPTCP in terms of energy efficiency have been discussed in [START_REF] Peng | Energy efficient multipath tcp for mobile devices[END_REF] by modeling, measuring and simulating. The authors proposed eMPTCP, which manages subflows expected energy efficiency based on available throughput. In fact eMPTCP is the most similar work to us, but the difference is eMPTCP only considered the downloading case and doesn't take the uploading energy into account. In addition, to estimate the available throughput eMPTCP sampled downloaded bytes, which introduces the overhead to a network.

GreenBag [START_REF] Bui | Greenbag: Energyefficient bandwidth aggregation for real-time streaming in heterogeneous mobile wireless networks[END_REF] was proposed as a bandwidth aggregate middleware on wireless links. It estimates the available bandwidth on wireless links and specifies the amount of traffic allocation while taking QoS into account. GreenBag reduces energy consumption between 14% to 25%; however, it needs major applications modification which is not feasible. Peng et al. [START_REF] Peng | Energy efficient multipath tcp for mobile devices[END_REF] designed a MPTCP algorithm, decreasing energy consumption up to 22% by intelligently compromising between throughput and energy. However, they only considered bulk data applications such as video streaming and file transfer, and they did not consider the effect of signal strength on throughput. Markov decision process has been applied by [START_REF] Powell | Approximate Dynamic Programming: Solving the curses of dimensionality[END_REF] to utilize the optimal interface for different applications. Nevertheless, authors only considered throughput and stationary applications which is infeasible in dynamic environment. For instance, each application has different traffic patterns, and modeling all applications traffic is not practical. Furthermore, the optimal throughput performance is only achieved by one path, and more importantly the system performance would dwindle immensely when the optimal path is the most congested one. Energy aware MPTCP is proposed in [START_REF] Puterman | Markov decision processes: discrete stochastic dynamic programming[END_REF] to balance the increasing throughput with the energy consumption. Unfortunately, data has been offloaded simply to WiFi whenever possible since they assumed WiFi consumes less energy than LTE. That assumption may not be true in many scenarios. In fact, when a mobile device experiences a weak WiFi signal, not only a huge amount of packet loss and delay would be irrefutable [START_REF] Lim | Cross-layer path management in multi-path transport protocol for mobile devices[END_REF], but also as we showed, energy cost would increase sharply.

Lim et al. [START_REF] Lim | Cross-layer path management in multi-path transport protocol for mobile devices[END_REF] proposed an inspiring algorithm, MPTCP-MA, which manages the path establishment by taking cross layer information, such as Mac layer behavior. They endeavored to increase the WiFi throughput efficiency up to 70%; nonetheless, energy efficiency hasn't been taken into account, and they haven't addressed cellular networks behavior. In contrast to most studies, Tailless MPTCP (TMPTCP) [START_REF] Shamani | Tmptcp: Tailless multi-path tcp[END_REF] showed that MPTCP energy efficiency could be enhanced by the tail energy minimization. Since the tail energy has a enormous impression on the energy contribution, TMPTCP optimizes jointly energy and delay. However, TMPTCP deals with static bandwidth and the offline experiment demands more investigation.

Conclusion

In this paper, we studied the problem of energy efficiency in the context of multipath TCP. We proposed a control mechanism based on Markov Decision Process to distribute traffic over diverse paths while optimizing energy. Performance of the proposed control mechanism was evaluated and compared with the different platforms. The results indicate that the proposed control mechanism significantly outperforms other schemes in all considered scenarios and MPTCP is not energy efficient in any selected cases. Even though we have applied our approach to LTE, the model could simply extend to 3G networks. The effect of delay would be investigated in future work.

  2 and Fig.3throughputs for MPTCP, WiFi and LTE have been plotted based on the transferred file size if the WiFi and LTE RSSI are (-76,-90) and (-106,-135), respectively. As it can be seen as the file size increases, the

Figure 1 :

 1 Figure 1: Average throughput based on signal strength

Figure 2 :

 2 Figure 2: Platforms throughput for different file sizes

Figure 3 :

 3 Figure 3: MPTCP throughput for different file sizes

Figure 4 :

 4 Figure 4: Simulation topology

Figure 5 :

 5 Figure 5: 256 KB upload and 256 KB download energy consumption

Figure 6 :

 6 Figure 6: 256 KB upload and 32 MB download energy consumption

Figure 7 :

 7 Figure 7: 32 MB upload and 256 KB download energy consumption

Figure 8 :

 8 Figure 8: 32 MB upload and 32 MB download energy consumption

Figure 9 :

 9 Figure 9: Different platforms throughput and energy efficiency

Table 1 :

 1 Packet transfer coefficients[START_REF] Lim | Improving energy efficiency of mptcp for mobile devices[END_REF]

		LTE WiFi
	α d 10.04 4.64 Download β d -0.89 -0.81
	Upload	α u 13.34 3.61 β u -0.83 -0.66

Table 2 :

 2 Upload coefficients decision epochs, states, states transition probabilities, actions and costs. The mobile device can make a decision about tuning one or both interfaces from idle to active mode in each time epoch, where T = {1, 2, .., y} represent a set of decision epoch. The signal quality states are introduced by the following: firstly, a set of signal quality states for interface i, R i = {r 1 i , r 2 i , ..., r n i }, where r 1 i is minimum and r n i is maximum signal quality state. It is worth adding here that each signal quality corresponds to specific uplink and downlink bandwidth. Secondly, signal quality states transition probability matrix for interface i, P ri

		κ u	η u	ι u
	TCP over WiFi	-23.35 -0.16 29.48
	TCP over LTE	-27.38 -0.08 29.62
	MPTCP WiFi -27.58 -0.14 32.57
	MPTCP over LTE 205.7 0.0052 -203.3

Table 3 :

 3 Download coefficients

		κ d	η d	ι d
	TCP over WiFi	-24.1 -0.17	30
	TCP over LTE	541 0.0055 -539
	MPTCP over WiFi -95 -0.039 98.22
	MPTCP over LTE -14.05 -0.15 18.59

Enable MPTCP in full mode end End and 3. Before the simulation the best policy in each state for different arrival rates have been calculated . After that the traffic has been generated between two nodes, and the mobile node (UE-1) moves from one spot to another by using the most efficient policy in each state.

In order to compare the proposed scheme to other platforms, we have simulated the same scenario using MPTCP, WiFi, and LTE in all spots. Also to have a practical perspective and general view of how the system works, two different file sizes have been selected for uploading and downloading in symmetric and asymmetric traffic scenarios.

From Fig. 5 to Fig. 8, the optimal policies have been marked by a red arrow. Taking the advantage of the packet capture feature of NS3, we have plotted the energy consumption behavior of other policies in each state. SA-MPTCP optimal decision was completely compatible with real simulation and surprisingly MPTCP has not been chosen in any scenario. In fact, this is the first time that uploading and downloading have been considered together, and the results contrast prior research such as [START_REF] Lim | Improving energy efficiency of mptcp for mobile devices[END_REF] and [START_REF] Peng | Energy efficient multipath tcp for mobile devices[END_REF]. Most of the time either WiFi or LTE are the best policy and even according to Fig. 6 WiFi is the best option for