Performance impact of Mobile Cloud Computing on Wireless LAN Arun Wadhawan∗, Patrick Daehne†, Woldemar Fuhrmann‡, Bogdan Ghita§ ∗ Fraunhofer
Institut for Computer Graphics IGD Darmstadt, Germany Email:
[email protected] † Fraunhofer Institut for Computer Graphics IGD Darmstadt, Germany Email:
[email protected] ‡ Department of Computer Science University of Applied Sciences Darmstadt Darmstadt, Germany Email:
[email protected] § Centre for Security, Communications and Network Research University of Plymouth Plymouth, United Kingdom Email:
[email protected] Abstract—For convenience more and more communication is shifted to wireless networks and enterprise communication follows this general trend. With that the requirements have changed considering mobile applications and end devices. Even that the mobile devices get more resources e.g. performance (CPU), graphic power (GPU) and capacity (RAM, hard disk size), new mobile applications require more advanced resources. These new applications benefit from the cloud approach and introduce the client/server concept onto mobile devices. In this paper we will analyse today’s enterprise Wireless LAN implementations to support these new mobile applications. These upcoming applications require high processing power and a reliable network infrastructure as most of the data will be transferred between the mobile device and the cloud infrastructure. Furthermore we will analyse the capabilities in regard to QoS to identify if these QoS mechanisms can help to improve network performance and allow these new applications to work. These new applications require cloud computing where the demand on high bandwidth and low latency has to be fulfilled. Therefore investigating today’s standard on wireless communication in enterprises is highly important and the key question will be if those applications are supported in existing Wireless LAN implementations. This analysis will be shown in the form of a practical experiment where key requirements on mobile communication in enterprise environments are identified. Furthermore restrictions will be shown that limit these applications to function properly. These restrictions are a starting point to enhance or redesign wireless network infrastructures in enterprise environments.
I. M OTIVATION AND C HALLENGES Mobile devices and new applications are being introduced into the enterprise environment where we want to benefit from the anywhere and any time concept. As explained in [1] mobile applications can support the so called ”look and feel”, where information will be displayed in time, without processing every information on the device itself. With that
capability a user can move around and benefit from the remote display approach where your mobile device uses the enterprise resources to support higher calculation power to gain higher performance. In this approach client devices can use the cloud infrastructure to offload the content and process it in the cloud. The device itself displays the information that it receives and processes only user interactions. The outcome of this paper will show that data offloading has many advantages especially dealing with 3D content as mobile devices have limited resources. The challenge of this approach is that the wireless medium has to support these applications and with that bandwidth, latency and delay must be minimized. Wireless LAN (e.g. IEEE 802.11n) is the wireless communication technology that is being used in enterprise environments for mobile devices. In this paper we will analyse the performance considering the required parameters as bandwidth and delay that are required to support cloud based mobile applications. The challenges are to reduce the processing power, used bandwidth, delay and latency of mobile devices to improve user acceptance (through better capacity e.g. battery time as well as more hard disk size) and the usability of complex applications that are provided by cloud based infrastructures. The terminal itself has limited resources that have to be replaced as new technologies and requirements come up. To overcome this problem the cloud concept has been introduced. Therefore applications offload their data to process it in the cloud and interpret the result as it is been sent back to the client. Then information can be displayed on the device. With this solution the process to calculate a huge amount of data has been delegated into the cloud infrastructure where high performance servers calculate and send the data to the mobile terminal. To implement this cloud based concept for mobile terminals
we need to have a high performance and reliable network infrastructure, as data is been sent to and received from the mobile terminal. Data has to be delivered very fast to avoid loss of data and user experience. In such an application 3D content is moved via user input (finger movement on the device) onto the touch panel of an iPad or iPhone. The user should be able to move the 3D content representing a live interaction without noticing any delay. For example a phone call (voice traffic) should not have more than a maximum round trip delay of 250 ms. If the round trip delay is more than 250 ms the user experience will drop. This is difficult for dialogue and packet loss will occur resulting in a possible communication cut-off depending on the codec used and delay. It is similar for video except that caching mechanisms can be used to suppress jitter. For interaction with the application time is more critical as input/output data (e.g. moving an object on the screen) has to run without any delay or jitter. Therefore these values have to be kept to a minimum. As seen in the evaluation of the results in this paper the delay for our application has to be below 150 ms in reference to the round trip time of a packet. We figured out that for such a time critical application as the one we used for the analysis a delay of up to 100 ms and a jitter of up to 50 ms will provide the required parameters for good user experience. Under this conditions the user won’t recognise interruption or delay. II. U SE C ASE The following section will point out how these new applications work and explains the functional split between the cloud and the device. Furthermore the communication between the terminal and cloud infrastructure as well as the access on the wireless medium will be analysed with respect to performance. A. Application The application that we are referring to, deals with virtual reality where the 3D scene will be shown on an iPAD or iPhone where the user is capable to interact with the scene. With that capability the processing will be placed into the cloud where a very powerful server (with multiple GPU’s) processes this information and calculates the scene. In this application (Fig. 1.) multimedia information is exchanged between the user device and the server using the client/server communication paradigm. The wireless device (iPAD 1) receives the video stream that is being sent from the server using an Hypertext Transfer Protocol (Http) stream (Version 1.1) session. The frames are rendered on the server and displayed on the mobile device. With that the user of this wireless device can now interact via input of his finger movements to control the computed contend that is being processed on the server. Each movement will trigger the client to send input/output data to the server which than provides new coordinates for the scene that is rendered and sent back to the client. The control information and the display content result in a large amount of data to be transferred on the wireless medium (e.g.: I/O and JPEG data send over the Http 1.1 stream). Http 1.1 is used as a common application protocol
which allows the application to work on any client that has a web browser implemented. HTTP 1.1 uses Transmission Control Protocol (TCP) on the transport layer. The used device in this research is based on an iPAD 1 as it has the capabilities to use the 2.4GHz wireless spectrum. B. Communication With WLAN, the wireless medium is shared among multiple users. As described in the introduction a standard enterprise WLAN environments is considered. It uses IEEE 802.11n technology, and operates in the 2.4 GHz frequency range. In our case this architecture uses 2(Tx)x3(Rx)x2(Spatial Streams) Multiple Input and Multiple Output (MIMO) where channel bonding is not enabled on 2.4Ghz spectrum through the lack of channels. Channel bonding should not be performed in a 2.4Ghz production environment as there are only three non-overlapping channels. On the 2.4GHz frequency there is a throughput of 150Mbit/s (gross bit rate) possible considering 802.11n. MIMO assists to increase the performance as the multiple antennas allow a higher traffic utilization as well as multiple streams on the wireless link. The end devices (iPAD and iPhone) that interact with the application are only capable of using the 2.4GHz frequency and therefore we will focus on this frequency spectrum. Analysing the content and traffic that is being sent between client and server displays the requirements that have to be supported throughout the network for this application to work without any interruption. First of all we analyse the carried traffic utilization between client and server using our application. Wireshark is used for traffic analysis where we get the average traffic utilization of 4.6 MBit/sec between client and server. Furthermore Wireless LAN (802.11n on the 2.4GHz frequency) uses OFDM where two multiple streams are used considering MIMO. Wireless LAN has to use multiple channel utilisation techniques as it is a shared medium e.g. Requestto-Send (RTS) and Clear-to-Send (CTS) is implemented to overcome the near-far issue. On the wireless medium every packet is acknowledged on the MAC and possibly resent if an acknowledgement is not received. On the TCP layer delayed or missing acknowledgements would close the congestion window and lead to a significant reduction of the throughput, refer to [2]. III. WLAN C OMMUNICATION WITH Q UALITY OF S ERVICE WLAN communication with Quality of Service (QoS) is investigated in this paper as the chosen method to enhance the delay, jitter and throughput for the demanding cloud application. QoS in WLAN is achieved by introducing arbitration interframe spaces [3] that allow to differentiate and prioritize multiple access categories. Therefore stations with higher service priority could access the wireless medium and transmit their MAC frames faster than stations with lower service priority. In our scenario we mark this MAC frames with Class of Service value 7 [3] that corresponds to Access Category Voice (AC
Client
DISPLAY
Server
(HTTP 1.1) connect once
Rendering Unit HTTP 1.1 Server
Push JPG (when changed)
WebSocket Touch Screen
MOUSE Interaction
Send Event
Fig. 1.
Cloud based Application
VO) which corresponds to IP Differentiated Services marking Expedited Forwarding (EF 46) in the network. IV. E XPERIMENTAL S ETUP The experiment is performed in three scenarios each of which consists of two measurements: delay and jitter. First the WLAN radio interface is considered without applying QoS. The measurements are carried out using available tools: Wireshark (throughput), iperf (jitter) and ping (roundtrip time (RTT). The client is connected to the wireless medium using a gross bit rate of 150 Mbit/s (gross bit rate) at 2,4 GHz. (See Fig. 2.) Since the wired link in the experiment provides much higher transmission capacity and is not changed during the experiment, we can focus on the wireless connectivity and performance (delay and jitter). In the first scenario the considered cloud application is not running to measure the default delay, jitter and throughput of background traffic. Then in the second scenario the wireless client (iPAD) and the server exchange picture/video content as well as control information for user interaction. In the third scenario QoS is implemented on the wireless medium and the server that is running the application uses wired QoS settings as the application itself is not capable to provide QoS markings. The third scenario is similar to the second scenario, however, both client and server should use QoS marking in order to prioritize the cloud application. This setting of QoS classes provides problems for web application developers, since standard developing tools do not allow to classify and mark traffic using a standard browser and Http. Therefore a workaround was required in order to mark the traffic on the WLAN radio interface. On the wired network side, the QoS marking is performed by the switch, where the server is connected.
On the wireless side, the QoS marking has to be done by an access point which is used as a proxy for the mobile device. The device has a wired connection to the proxy access point and the proxy simulates the radio interface for the mobile device. Delay and jitter is analysed in the three scenarios (runs) described before. The setup for the experiments is shown in Fig. 2. The client for the cloud application is connected to an access point acting as a wireless proxy for classification and marking of packets in the direction from mobile device to access point (uplink). Two other clients generate background traffic in the form of UDP packet streams with an average transmission rate of 90 Mbit/s and 144 Mbit/s, respectively. The background traffic is categorised in three different scenarios where the wireless channel is utilised. The first run will be done at 90 Mbit/s, the second with 144 Mbit/s and the third wit two different client streams at 144 Mbit/s. There are two further wireless clients, one equipped with Wireshark for data analysis and another one sending Internet Control Message Protocol (ICMP) Echo Request messages and receiving responses for delay measurements. The access point connected to the wired network side carries the traffic exchange between the wireless clients and the fixed servers. One server implements the cloud application and the other server is used for generation of background traffic from 90 Mbit/s up to 144 Mbit/s. The switch is used for classifying and marking the packets according to their access categories in the direction from the access point to the mobile devices (downlink). Delay and jitter are analysed in three runs where UDP packets are sent over 90 Mbit/s and 144 Mbit/s to the server
Delay&Packet analyzer (ping&wireshark)
Traffic generator Client's (iperf)
Access Point Cloud Server (processing 3D content) Switch
Cloud Client
Traffic generator Server (iperf)
iPAD Cloud Client
Fig. 2.
Fig. 3.
LAB environment application and performance analysis
Delay without Application Traffic
Fig. 4.
Jitter without Application Traffic
V. R ESULTS A. Scenario 1: where we separate between 1 to 2 active UDP client streams. The values (delay and jitter) correspond to the client/server communication of the produced background traffic (using iperf) as the application itself does not provide these values. Running those tests on our measurement equipment visualises the channel quality as we are analysing and testing the link quality with and without the cloud based time critical application.
The first scenario shows the basic values (delay and jitter) that are supported in the given environment. In this scenario the wireless medium has been analysed to define the basic interference and wireless link quality. In Fig. 3 and 4 you can see that with only one client transmitting 90 Mbit/s an average delay of 36 ms and and average jitter of 0.5 ms occurs. Even if more than one client transmits at about 144 Mbit/s the delay and jitter does not change and stays about 32-36 ms (delay) and 0.5-1 ms (jitter).
Fig. 5.
Delay with Application Traffic
Fig. 7.
Delay with Application Traffic and QoS
Fig. 6.
Jitter with Application Traffic
Fig. 8.
Jitter with Application Traffic and QoS
B. Scenario 2: In the second scenario (Fig. 5. and Fig. 6.) we measure the influence of background traffic onto the cloud application traffic having a constant stream via iperf of 90 Mbit/s or 144 Mbit/s that is being sent from up to two wireless client’s to a server that is located on the wired side of the network. These values indicate that even if you have only one or two clients on the medium the delay will increase substantially as seen in Fig. 5. However jitter does not increases as displayed in Fig. 6. The average delay with 90 Mbit/s background and one client stream has a value of 101 ms and a jitter of 0.6 ms, with 144 Mbit/s a delay of 110 ms and a jitter of 0.7 ms. Having two 144 Mbit/s streams results in a delay of 196 ms and a jitter of 0.7 ms. C. Scenario 3: In the last scenario QoS mechanisms, as has been described above, are introduced to reduce delay and jitter as compared to
scenario 2. Fig. 7 and 8 show that delay and jitter values could be improved. The average delay with 90 Mbit/s background and one client stream has a delay of 17 ms and a jitter of 0.2 ms, with 144 Mbit/s a delay of 17 ms and a jitter of 0.2 ms. Having two 144 Mbit/s streams results in a delay of 20 ms and a jitter of 0.4 ms. VI. C ONCLUSION The traffic analysis shows that with only an average transmission rate of 4.6 Mbit/s (required throughput of the cloud application) delay increases significantly as background traffic increases without using QoS. The result is that with more than 144 Mbit/s of background traffic the application will not be able to transmit its information with the required delay of less then 100 ms. If the delay increases 150 ms, then movements of objects in the cloud application will be interrupted. Jitter has to be kept to minimum and should be not be to large as the delay will suffer on to much variance. If the delay is close to
150 ms and the jitter is to high (e.g. only 1-10 ms) interaction with the object of the cloud application will look inconsistent and not like a live interaction with the 3D content. In our experiment only delay was causing problems if no QoS was implemented. Jitter was always below 1 ms and therefore had no influence on our application. As a solution to this problem the standard WLAN QoS mechanisms can be introduced. However, the use case discussed in this paper brought up another problem. Mainstream developers of web applications do not have access to the classification and marking of sent packets, when they use standard web browsers. One solution would be that some kind of additional software will take care of classification and marking of packets. A better solution would be, if the WLAN enterprise network implements some policies and decides/enforces the classification and marking. Then users are not able to manipulate QoS decisions. Further issues, such as using TCP for transport of real-time applications have not been considered in this paper, since the implementation of the WLAN QoS mechanisms have already offered the required improvements. R EFERENCES [1] P. Simoens, F. De Turck, B. Dhoedt, and P. Demeester, “Remote display solutions for mobile cloud computing,” Computer, vol. 44, no. 8, pp. 46 –53, aug. 2011. [2] S. Henna, “A throughput analysis of tcp variants in mobile wireless networks,” in Next Generation Mobile Applications, Services and Technologies, 2009. NGMAST ’09. Third International Conference on, sept. 2009, pp. 279 –284. [3] IEEE, “Ieee 802.11e-2005,” November 2005. [4] N. Cranley and M. Davis, “Performance evaluation of video streaming with background traffic over ieee 802.11 wlan networks,” Proceedings of the 1st ACM workshop on Wireless multimedia networking and performance modeling, pp. 131 – 139, 2005. [5] P. M. B. M. David A. Westcott, Davic D. Coleman, CWAP Certified Wireless Analysis Professional. SYBEX, 2011. [6] IEEE, “Ieee 802.11-2007,” June 2007. [7] M. K. Jon Dugan, “Iperf,” June 2011. [Online]. Available: http://sourceforge.net/projects/iperf/ [8] N. Kryvinska, C. Strauss, B. Collin-Nocker, and P. Zinterhof, “A scenario of voice services delivery over enterprise w/lan network platform,” ACM, 2008. [9] C. Systems, “Voice over wireless lan 4.1 design guide,” March 2009. [10] H. Zen, D. Habibi, A. Rassau, I. Ahmad, and J. Wyatt, “A segregation based mac protocol for real-time multimedia traffic in wlans,” in Proc. IFIP Int. Conf. Wireless and Optical Communications Networks WOCN ’07, 2007, pp. 1–5.
