Abstract: – Thevision of 5G Mobile networks lies in the provisioning of high throughput (over10GB/s data rate), low latency (less than 1m for radio link latency) andconnecting more devices (over 1M terminal per square kilometer). This is driven by the needfor the Internet of Things (IoT) applications (e.g. smart cites smart homes),rich immersive multimedia applications (e.
g. live video streaming) and thetactile Internet. To achieve 5G targets, Mobile edge computing (MEC) isregarded as a vital solution to providesatisfactory Quality of Experience (QoE) for multimedia services. Althoughvideo streaming applications are seeking more bandwidth and exorbitant video quality.Particularly for virtual reality applications or video on demand (VoD), andadaptive streaming protocols like MPEG-DASH (dynamic adaptive streaming overHTTP) lets video quality to be flexibly adapted, means that the video qualitywill degrade when network condition is affected.
But that is not an option forthe video quality to go down when the application itself needs to assure highvideo quality all the time. In this paper we present Mobile Edge Computing(MEC) scheme for enabling video caching to the closest node of the end user,rather than going back to the cloud every time the video is requested in thisway we will reduce the traffic to the cloud and the content will be closer tothe end users, to optimize QoE to the end user. So in this way, we implemented theconcept of bringing the content closer to the user, and free the backend-corefrom traffic.Introduction: – It is becoming a Fact that innext few years video streaming application will rule the internet traffic, andCisco Visual Networking Index predicting that video applications will dominate75% of overall internet traffic by 20201, over the years video contentprovides e.
g. YouTube, have been using MPEG-DASH (Dynamic Adaptive Streaming over HTTP) standards to deliverstreaming services. 2 Meanwhile MPEG-DASH has many advantages likeflexibility through on-the-fly quality adaptation and it is simple to add itover the existing HTTP infrastructure, and the fact that MPEG-DASH usestransmission control protocol (TCP) is acting like a double-edged sword, thefirst edge is that it can avoid video degradation that is caused by losingI-Frame or other things. And the second edge is that when a wireless userequipment (EU) streams videos, there will be 2 network segments on theend-to-end path that will have different characteristics, 1) radio accessnetwork (RAN) which is wireless. 2) Mobile core network and the internet thatin most cases are wired, the wired segments have higher bandwidth-delay-product(BDP) due to the high-capacity over-provisioned backbone link and long latencydue to long distance that the data transport between the global Internet.
One of the major networkingproblems is the insufficiency of structured resource management schemes toprovide Quality of Service (QoS) and Quality of Experience (QoE) support forreal-time applications, primarily in networks that can be affected by delay or packetloss. E.g.
the video or VOIP services are not tolerant to packet loss thatshould not more than 1%, especially ifthe system is using compressed codecs e.g. G.722, and the latency is alsoplaying a major impact on the services which should be less than 150ms betweentwo end-points 3. The delivery of mobile content, especially in high definition (HD) videoswith high resolution, has become one of the maintopics to add to the context of 5G network development in the future It has become a fact that 5G is not only about increasing networkcapacity, but also about quality of service (QoE) through adding necessary network intelligence in all type ofnetwork environments. With the recentdevelopment of new networking paradigms, in particular,Mobile Edge Computing (MEC 4), it is envisaged that content awareness andintelligence can be embedded at the mobile network edge (e.
g. at eNodeBs, oreNBs in LTE networks) in order to achieve desirable user quality of experiences(QoE) against various dynamicity and uncertainty in the network ecosystem. inthe sense that the network is able to understand specific content deliveryrequirements and conditions when performing content handling operations.
The main objective of this paperis to optimize QoE to the end user using MEC regardless of the mobility thatwill be done by the end user the approach ensures that the user is alwaysserved from the closest node to him but when the network condition isdecreasing it will start serving from the next closest node to the user if itis in range which is done by cashing the content to the node that is servingthe end user Related work: -Experimentalsetup: -to show edge-based videostreaming and movement we used Ubuntu16.04 LTS desktop to and two laptops with the same host type as the desktop todo this testbed. The Desktop itself is used to simulate cloud environment usingDevstack (OpenStack) which includes all(network, storage, compute, and controller) in the same node, and then welaunched an Instance with Ubuntu cloud operating system inside it which is aminimal Ubuntu image to host the MPEG-DASH video server, for the video content we used Big Buck Bunny open movie 5, andApache as a web server. The IP was takenfrom a private IP range pool, and then we specified the route to know where togo outside the main Desktop, the Desktop is connected to a router with IP of192.
168.1.129. Since the Devstack instance ishaving a private IP address, it is necessary to make interaction with the outsidenetwork possible by defining the static routes in the first router.
As definingthe set of IP Table rules to forward the traffic from the public to privatenetwork. and to emulate the Edge serversone virtual machine is installed in each of the laptops which they use Ubuntu16.04 and the connection between the two laptops is done by using an ethernetswitch, and both of the virtual machines use thesame virtual environment to ensure thatthey both act like edge access points. Containers have been created in both virtual machines, using LXD containersand squid has been instilled inside both them to act as a web server, and it has been configured to act as a proxy to the back-end cloud with streamingand caching functionality which is hosting the MPEG-DASH video server.
And asthe first router, it is mandatory to define theset of IP Table rules to forward the traffic between the first router and thesecond router. After configuring the routers now they can realize the rightpath to take to reach their destinations. it is worth recalling that theaim of this testbed setup is to optimise the QoE to the end user using MEC andregardless of the mobility.Figure-1- Testbed setupTo perform the test, a containeris configured with all the futures mentioned above, and connected to a ethernetrouter, then a mobile phone has been used and connected to the same network asthe LXD container by Wi-Fi router, thenthe user starts to browse the video using the URL of the container , and as wementioned above that the container acts like a proxy to the backend-cloud sothe container forwards the request to the backend-cloud to deliver the contentof the video to the container, in this stage the container will start cachingthe video segment that has been sent from the backend-cloud for further uses, sonext time that the user asks for the same video the container will use it isown cashed segments regardless of thecloud if it is in range or not, by doingthat we implement the conept of bringing the content closer to the client andmaking the backend-cloud free of traffic or less traffic, the next step is the migration between twonodes which will happen according to two options, the first condition is, ifthe network condition is bad, and the second one is movement when the user isgetting closer to the next node, starting from the scenario shown in figure 1,we started to browse the video from the first node in a perfect condtion network, the node started fetching thesegements from the backend-cloud and it was cashing every segment that itgets.then we used a script to decrease the bandwidth and overload the networkand the video quality went down.
Now, we repeat the network behavior, but this time with the migration option,that means after the user starts to browse the video from the first node, aftera fixed amount of time we will overload the network and decrease thebandwidth, alongside that a script is used to check the buffer size and wheneverit reaches a critical percent that it will affect the video quality, the migrationwill start, and the user will be getting the video segments from the new node,without letting the video quality go down. Rsync was used to compare the cachedfiles between the containers, so both of the containers will have the samecached segments, in this way if another user asked for the same video the nodeswill use it is own segments rather than going back to the backend-cloud, inthis way we even reduced the traffic to the cloud so the load will be less init, and the user is totally unaware of the fact that the streaming node hasbeen changed they are just enjoying the streaming , results are discussed inthe next section. Results:-In our tests, we considered 3 majorimpacts on video quality which are Buffer size,Bitrate, And Throughput. Tests have been done without migration and withmigration as mentioned in the use cases above, as shown in figure -2- it is obvious that when there is no migration isgoing on and the network quality is reducingthe video buffer size is reducing too , andin the other hand when migration option is there,as soon as the node knows that the network condition is reduced the migrationwill happen and the buffer size will drop for a small time then go back to thenormal levels again without letting the user notice any changes on his/her side.Figure -2- buffer sizeRegarding video bitrate that theuser is watching, we did more than one test to choose the right time ofmigration without letting the user face a low-levelvideo or causing the video to pause orstop completely, the script that we generated is checking the buffer size fromthe first second that the video has been streamed so the normal buffer size fora perfect condition video in 2400 bitrateis between 29-32. And the script is always checking the buffer size and whenever it falls below 25 it will start themigration to the new node.
In this case,the buffer size will go up to the normal range after a short period of time. Asshown in figure 2, figure 3 shows thebitrate for both conditions migration andwithout migration.Figure -3- BitrateMigration has been tested to bedone at different times e.
g. when the buffer level hits 15 or less or 18,20and25. and results show that to maintain agood quality for the client the migration needs to start when the buffer sizehits 25 or fall below 25 so the user will not witnessany change in the quilty of the video. Downbelow is graph 4 which shows throughputlevels in both migrations and withoutmigration network. Graph -4- throughput Conclusion:- References:-1- “Cisco VNI mobile forecast,2015–2020,” Cisco, Syst., Inc., San Jose,CA.
, USA, 2016. Online. Available:https://www.cisco.com/c/dam/m/en_in/innovation/enterprise/assets/mobile-white-paper-c11-520862.pdf.
Accessed on: Jan. 2017.2- Information Technology—DynamicAdaptive Streaming Over HTTP(DASH)—Part 1: Media PresentationDescription and Segment Formats,ISO/IEC 23009-1:2014, 2014. Online.
Available: http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=652743- T. Szigeti and C.
Hattingh, End-to-End QoS Network Design:Quality of Service in LANs, WANs, and VPNs. Cisco Press, 2004.4- ETSI. Mobile Edge Computing: A key technology towards 5G(Whitepaper). Available at http://www.etsi.org/images/files/ETSIWhitePapers/ ETSI wp11 MECa key technology towards 5g.pdf5- ‘Big Buck Bunny movie’ http://www.bigbuckbunny.org