# An Adaptive Video Transmission Mechanism over MEC-Based Content-Centric Networks

Authors: Longzhe Han; Jia Zhao; Xuecai Bao; Guangming Liu; Yan Liu; Taras Maksymyuk
Journal: Wireless Communications and Mobile Computing
 (2021)

---

## Abstract

The rapid growth of video traffic poses serious challenges to the current Internet. Content-Centric Networking (CCN) as a promising candidate has been proposed to reengineer the Internet architecture. The in-network caching and named content communication model of CCN can enhance the video streaming applications and reduce the network workload. Due to the bandwidth-consuming characteristic of video streaming, the aggressive transmission of video data will cause a reduction of overall network efficiency. In this paper, we present an adaptive video transmission mechanism over Mobile Edge Computing- (MEC-) based CCN. The computation and storage resources of the MEC server are utilized to facilitate the video delivery. Our mechanism adopts a scalable video coding scheme to adaptively control transmission rate to cope with the network condition variation. To analyse the equilibrium property of the proposed mechanism, an analytical model is deduced by using network utility function and convex programming. We also take into account the packet loss in wired and wireless links and present a MEC assistant loss recovery algorithm. The experiment results demonstrate the performance improvement of our proposed mechanism.


---

## Body

## 1. Introduction

With the continuous progress of wireless communication technology and mobile devices, emerging multimedia services (e.g., mobile TV, user-created video, video game, and mobile video calling) have gradually become people’s daily applications, and dominated mobile Internet traffic [1–3]. According to Cisco’s report, 79 percent of global mobile IP traffic will be video by 2022. The explosive growth of video traffic will bring huge pressure to the mobile network operators [4]. Although several technical solutions (e.g., peer-to-peer network and content delivery network) have been carried out to relieve the network transmission burden, the problem cannot be solved completely [5]. The current Internet protocols, TCP/IP, were designed in the 1960s. The principle of TCP/IP is to interconnect two hosts across multiple physical links and exchange data. At that time, the main applications were for resource sharing, such as FTP and Telnet. The evolution of Internet applications makes TCP/IP inefficient for the new requirement, which is content sharing [6].To address the shift of Internet use, Content-Centric Networking (CCN) has been proposed as a new network architecture of the Internet [7]. The major difference between TCP/IP and CCN is changing the protocol core from IP to named content. Instead of connecting two end hosts, the key design goal of CCN is to deliver the requested content to the user [8]. In CCN, every node is equipped with a data cache. The user announces the name of interested information to the network, and any node possessing the data can respond [9]. Focusing on content sharing, CCN is able to dramatically improve the network transmission efficiency. Due to its promising characteristics, plentiful research efforts have been dedicated to video streaming over CCN. In [10–12], adaptive video streaming schemes in a wireless network environment are presented. The management of the data cache directly affects the availability of content; efficient cache management algorithms have been proposed [13–15].Another crucial technique to cope with the challenge of the Internet is Mobile Edge Computing (MEC). In contrast to centralized cloud computing, MEC adopts a distributed architecture. To improve the data transmission rate, reduce network latency, and the workload of backhaul, MEC migrates the computing and storage capability of the central cloud to the edge of the network. By deployment of resource close to the end user, MEC can provide location-aware and high-speed data services. In [16, 17], algorithms are proposed to dynamically adjust the quality of experience for video streaming application in MEC. To utilize the computing resource of the MEC server, adaptive bitrate streaming approaches are presented in [18–20]. By the estimation of wireless channel and assistance of the MEC server, video quality is adapted to the wireless channel variations.In this paper, we present an adaptive video transmission mechanism, which considering the advantages of both CCN and MEC. The main contributions of the proposed mechanism are as follows. To explore the in-network caching capability and coexist with different network applications, we introduce a transmission control algorithm to dynamically regulate the transmission rate. To adapt the network condition variation, the scalable video coding (SVC) technique is used. The encoded video has a layered structure, and various video qualities (e.g., frame rate, resolution, and fidelity) can be provided by selectively extracting enhancement layers. An analytical model is presented to verify the proposed transmission control algorithm. In addition, we identify the packet loss in wired and wireless links and propose a recovery algorithm for overcoming wireless link error.The remainder of this paper is organized as follows. Section2 discusses the main differences between IP network and CCN. Section 3 describes our proposed adaptive transmission control mechanism. In Section 4, the experiment environment and result analysis are presented. Finally, the summary of our work and our future research plan are described in Section 5.


## 2. TCP/IP Network vs. Content-Centric Network

The TCP/IP protocol suit is the de facto Internet standard [20, 21]. The success of the TCP/IP protocol suit owes to its preeminent network architecture design as depicted in Figure 1. The TCP/IP protocol suit adopts a layered structure, and intricate tasks for the data communication process are encapsulated into each layer [22, 23]. Each layer provides certain functions to its neighbour layers, such as routing, flow control, error detection, and session management. The interactions between adjacent layers are through predefined interfaces. The layered encapsulation makes the TCP/IP protocols can flexibly deal with the constant change of communication techniques [24, 25]. There are several protocols in each layer for different communication purposes, for example, TCP and UDP in the transport layer. However, the network layer only runs IP protocol, which unifies the packet forward process and builds the basis for the protocols in higher layers [26, 27].Figure 1
The comparison of TCP/IP protocols with CCN protocols.CCN inherits the layered design principle of TCP/IP protocol suit as shown in Figure1 [7]. The most important difference is that CCN has replaced the IP at the network layer with the named content. In TCP/IP, the function of the IP address is to virtually bind sender, receiver, and transmission packets. According to the IP address, the IP routers can forward the packets from the sender to the receiver. Nevertheless, the focus of CCN is to deliver the content to the request instead of connecting the sender and receiver. The named content is the core communication component, and CCN unbinds the content from its location. The advantage of unbinding is that the requested content can be retrieved from any node that holds the content [28].In order to achieve the goal, CCN introduces new packet types and node structure as presented in Figure2. A series of interest packets are generated and sent into the network by the receiving node, when the user wants to obtain certain content, for example, listening to a music or watching a movie. The content is encapsulated into data packets. Any CCN node holding the content can send corresponding data packets back to the request node. The CCN packets are processed only based on the name field in the packet header. The content name is recommended to take a form of tree structure, such as the form of Uniform Resource Identifier [29].Figure 2
The comparison of TCP/IP protocols with CCN protocols.A typical CCN node has three data modules: Pending Interest Table (PIT), Content Store (CS), and Forwarding Information Base (FIB). The PIT records every interest packet that the node forwarded and the forwarded interface. When the interest packet arrives at the content holder node, the PIT entries of the forwarding nodes set up a virtual path for the data packet traveling back. The PIT also has a role of transmission rate control and loss recovery. Since content is unbended with its location, the CCN node can reutilize the forwarded data packets other than eliminate them [30]. The CS is a memory space of a CCN node for buffering data packets. To improve the efficiency, memory replacement algorithms are used to manage the CS. The FIB has the same function as the routing table in the IP router. The CCN node references the FIB to forward interest packets to successive nodes and periodically updates the FIB according to routing algorithms.Figure2 shows three steps when a CCN node receives an interest packet. The first step is to search the CS by using the name field as the key [7]. If the matched data packet is found, then the data packet is sent back through the incoming network interface, and the interest packet is abandoned. This means that the content has been transmitted by this node and the content is reutilized. If there are no matched data packets in the CS, the second step is searching the PIT. If there is a matched entry in the PIT, then the same request has been forwarded before. The CCN node appends the incoming network interface to the existing entry and waits the return of the data packet. In the case of no matched entry in the PIT, the third step is to look up the FIB. If an entry with the same name is found in FIB, then the interest packet is forwarded to the subsequent node. Otherwise, the interest packet is abandoned [30].There are also three steps for the incoming data packet. The first step is to look up the PIT. If there is a match, then the data packet has been requested. The CCN node sends the data packet to each network interface listed in the entry, and the entry is removed from the PIT after sending. In case of no match in the PIT, the data packet is abandoned and the process is finished. The reason is that malicious nodes may broadcast junk content into the network, which causes the contamination of the CS and useful content cannot be stored. In the second step, the content is buffered in the CS for future reuse. The third step is to check the FIB by using the name of the data packet. If there is no match, the name and incoming interface are added into the FIB. The third step can help the routing algorithm to update the FIB in a distributed manner. After that, the whole process is finished [31].The content caching capability of CCN nodes is crucial for video streaming applications. In [32], the authors present a progressive caching algorithm for video streaming over CCN. The algorithm generates a metafile that includes the content priority information, and the CCN nodes can decide the cache policy based on the metafile. In [8], a multisource video streaming algorithm is proposed. Due to the caching capability of CCN nodes, the receivers might receive the data from different nodes. By considering the quality of experience, the proposed algorithm switches to different sources. [13] utilizes a scalable video coding scheme and proposes caching algorithms to improve the video delivery services. The content centric communication model is used not only for static networks but also for high dynamic networks [33–35]. In [36], the authors show the feasibilities of video streaming over CCN-based vehicular networks.


## 3. Adaptive Video Transmission Mechanism

### 3.1. Architecture of Video Streaming System

The system architecture of our proposed mechanism is presented in Figure3. For the flexible configuration of network resources, the proposed video streaming system integrates the SDN scheme. SDN consists of the control plan, data plan, and application layer. The application layer includes various types of application servers, for example, video streaming server, web server, and mail server. The different applications have different requirements for quality of service. In addition, CCN is independent from particular transport protocols; any protocol with the function of packet transmission, such as TCP, UDP, IP, and P2P, can be used. The SDN control plan uniformly and flexibly schedules network resources and provides a unified programming interface for the management program to support programmable control. The data plane including the backhaul network and access network is only responsible for data forwarding. Through the encapsulation of control functions and the abstraction of applications and networks, SDN treats the network as a logical or virtual entity to form an architecture similar to a computer operating system. The data plane provides a standardized and open interface for the control plane. In this way, the control plane can achieve more flexible control capabilities based on the global network view, and the data plan and application layer can be flexibly and independently expanded according to actual requirements to meet changing needs.Figure 3
The system architecture of MEC-based Content-Centric Network.


### 3.2. Adaptive Transmission Control Algorithm

CCN follows the receiver-driven model, where the receiver takes a major role during the video transmission. Because CCN does not assume the transport layer protocols offering reliable data communication service, flow control, congestion control, etc. It is the receiver’s responsibility to regulate its communication policy to respond to network condition variation. Our proposed transmission control algorithm is based on the receiver-driven model and TCP flow control and congestion control scheme. According to the video bitrate, the receiver periodically sends interest packets for retrieving video data. The ongoing interest packets are stored in the PIT. For each PIT entry, there is a timer with a value called LifeTime. If no data packet is received within LifeTime, either interest or data packet is lost. We consider the time between sending an interest packet and receiving the corresponding data packet as the round trip time (RTT) of the transmission. The control variableWPIT indicates the length of the PIT, which is the number of ongoing interest packets allowed to be sent. When the number of PIT entries reaches WPIT, the sending of interest packets is suspended until receiving a data packet. Initially, the WPIT is set to satisfy the required bitrate of the base layer denoted Wbase. When a data packet is received, the WPIT is increased proportionally to its current value.As shown in Figure4, the communication path between the receiver and the video server contains wired and wireless links. The loss of interest and data packet can happen in any links. In wired links, the CCN nodes use queue management algorithms that actively dropping packets to prevent network congestion, for instance, random early detection, random exponential marking, and stochastic fair BLUE. In wireless links, the packet loss is mainly caused by transmission errors. To distinguish between wired and wireless link loss, the MEC server traces the wireless loss rate denoted as Pwireless and sets into the data packet header. The receiver can obtain the total packet loss rate Ptotal, by observing the event of the PIT timeout. If there is a timeout and Ptotal is equal to Pwireless, it means that packet loss is at wireless links and WPIT remains unchanged. If Ptotal is larger thanPwireless, then certain nodes along the links are expected to encounter congestion. The receiver needs to reduce the transmission rate; therefore, WPIT is set to Wbase. We can use ordinary differential equation to model the dynamics of the proposed transmission algorithm as(1)WPIṪ=xt1−Ptotal+PwirelessαWPIT−xtPtotal−PwirelessWbase,where xt is the transmission rate of the receiver and xt=WPIT/RTT.α is the increasing rate of WPIT. With the replacement, the derivative of the transmission rate is(2)xṫ=1−Ptotal+PwirelessαRTT2−xtPtotal−Pwirelessxbase,where xbase=Wbase/RTT is the transmission rate of the base layer.Figure 4
Data offloading and computation offloading for video streaming over MEC-based Content-Centric Network.


### 3.3. Analytical Model of Proposed Algorithm

To analyse the equilibrium behaviour of the proposed transmission control algorithm, we introduce a network utility functionUixi for the ith receiver. The network utility function is a mapping of user benefit to the transmission rate. By increasing the transmission rate, the user can acquire more enhancement layers, and the user benefit is also increased. Hence, the network utility function is assumed to be concave and differentiable. Consider a wireless network with N receivers and K links, the transmission control problem is presented as network utility maximization [37]:(3)maximizexr>0∑i=1NUixi,subjectto∑i=1Kdjixi≤Cj,whereCj is the link capacity and the inequality constraint means that the total transmission rate should be not greater than the link capacity. dji is the portion of transmission flow carried by the link j. Let λj be the Lagrange multiplier for the capacity constraint of the link j. The Lagrangian is defined as(4)Lx,λ=∑i=1NUixi−∑j=1Kλj∑i=1Ndjixi−Cj,where the last term can be considered as the penalty if the total transmission rate exceeds the link capacity. Because the object function of (3) is concave and the inequality constraint is linear, the network utility maximization forms a convex optimization problem. From Karush–Kuhn–Tucker (KKT) conditions, we can derive from taking the derivative of Lx,λ respect to xi:(5)Ui′xi∗−∑j=1Kλj∗dji=0.At the equilibrium point, the derivative of the transmission rate (2) is zero. The packet loss caused by the congestion is also a penalty; with (5), we can obtain(6)Ui′xi=1α+RTT2xbasexi.Then, the utility function is(7)Uixi=logα+RTT2xbasexiRTT2xbase.Although there are different optimization algorithms [38–40], with the analytical expression of the utility function, the convex optimization algorithm is carried out to find the optimal solution.


### 3.4. MEC Assistant Link Loss Recovery

As explained in the previous section, the packet loss can happen in wired and wireless links. Usually, the loss in the wired link is caused by the routing nodes proactively dropping packets to prevent the link congestion. On the other hand, the loss in the wireless link is due to wireless link error. The packet loss can be recovered by Automatic Repeat reQuest (ARQ) or forward error correction. In our proposed system scheme as shown in Figure4, the MEC server, routing nodes, and the video server are able to store the video content. The receiver may obtain data packets from different nodes; hence, the ARQ is improper. Our proposed mechanism adopts the FEC approach to recover packet loss in the wireless link. The generation of the FEC packet is offloaded to the MEC server from the video server. Since all data packets must go through the wireless base station to the receiver. The MEC server collects the video data and generates FEC packets. The FEC packet is retrieved from the MEC server instead of the video server; the workload of wired links is vastly reduced. When the receiver gets the wireless loss rate from the MEC server, the minimum number of FEC packets required to overcome the loss is(8)WFEC=WPITPwireless1−Pwireless,where WPITPwireless is the expected number of packet loss. Depending on the current transmission rate WPIT, the receiver sends interest packets for FEC. The detailed steps of our proposed mechanism are presented in Algorithm 1.Algorithm 1: Adaptive Transmission Control Algorithm.
1:if arriving data packet then2: obtain packet loss ratePwireless from packet header3:WPIT=1+αWPIT4: clear timeout countern=0.5:end if6:if PIT timeout then7: calculate total packet loss ratePtotal.8: increase timeout countern=n+19:ifPtotal>Pwirelessthen10:ifWPIT>Wbasethen11:WPIT=Wbase12:else13:WPIT=βnWbase14:end if15:else16: calculate number of FEC packetWFEC17: send FEC interest packets to overcome loss18:end if19:end if


## 3.1. Architecture of Video Streaming System

The system architecture of our proposed mechanism is presented in Figure3. For the flexible configuration of network resources, the proposed video streaming system integrates the SDN scheme. SDN consists of the control plan, data plan, and application layer. The application layer includes various types of application servers, for example, video streaming server, web server, and mail server. The different applications have different requirements for quality of service. In addition, CCN is independent from particular transport protocols; any protocol with the function of packet transmission, such as TCP, UDP, IP, and P2P, can be used. The SDN control plan uniformly and flexibly schedules network resources and provides a unified programming interface for the management program to support programmable control. The data plane including the backhaul network and access network is only responsible for data forwarding. Through the encapsulation of control functions and the abstraction of applications and networks, SDN treats the network as a logical or virtual entity to form an architecture similar to a computer operating system. The data plane provides a standardized and open interface for the control plane. In this way, the control plane can achieve more flexible control capabilities based on the global network view, and the data plan and application layer can be flexibly and independently expanded according to actual requirements to meet changing needs.Figure 3
The system architecture of MEC-based Content-Centric Network.


## 3.2. Adaptive Transmission Control Algorithm

CCN follows the receiver-driven model, where the receiver takes a major role during the video transmission. Because CCN does not assume the transport layer protocols offering reliable data communication service, flow control, congestion control, etc. It is the receiver’s responsibility to regulate its communication policy to respond to network condition variation. Our proposed transmission control algorithm is based on the receiver-driven model and TCP flow control and congestion control scheme. According to the video bitrate, the receiver periodically sends interest packets for retrieving video data. The ongoing interest packets are stored in the PIT. For each PIT entry, there is a timer with a value called LifeTime. If no data packet is received within LifeTime, either interest or data packet is lost. We consider the time between sending an interest packet and receiving the corresponding data packet as the round trip time (RTT) of the transmission. The control variableWPIT indicates the length of the PIT, which is the number of ongoing interest packets allowed to be sent. When the number of PIT entries reaches WPIT, the sending of interest packets is suspended until receiving a data packet. Initially, the WPIT is set to satisfy the required bitrate of the base layer denoted Wbase. When a data packet is received, the WPIT is increased proportionally to its current value.As shown in Figure4, the communication path between the receiver and the video server contains wired and wireless links. The loss of interest and data packet can happen in any links. In wired links, the CCN nodes use queue management algorithms that actively dropping packets to prevent network congestion, for instance, random early detection, random exponential marking, and stochastic fair BLUE. In wireless links, the packet loss is mainly caused by transmission errors. To distinguish between wired and wireless link loss, the MEC server traces the wireless loss rate denoted as Pwireless and sets into the data packet header. The receiver can obtain the total packet loss rate Ptotal, by observing the event of the PIT timeout. If there is a timeout and Ptotal is equal to Pwireless, it means that packet loss is at wireless links and WPIT remains unchanged. If Ptotal is larger thanPwireless, then certain nodes along the links are expected to encounter congestion. The receiver needs to reduce the transmission rate; therefore, WPIT is set to Wbase. We can use ordinary differential equation to model the dynamics of the proposed transmission algorithm as(1)WPIṪ=xt1−Ptotal+PwirelessαWPIT−xtPtotal−PwirelessWbase,where xt is the transmission rate of the receiver and xt=WPIT/RTT.α is the increasing rate of WPIT. With the replacement, the derivative of the transmission rate is(2)xṫ=1−Ptotal+PwirelessαRTT2−xtPtotal−Pwirelessxbase,where xbase=Wbase/RTT is the transmission rate of the base layer.Figure 4
Data offloading and computation offloading for video streaming over MEC-based Content-Centric Network.


## 3.3. Analytical Model of Proposed Algorithm

To analyse the equilibrium behaviour of the proposed transmission control algorithm, we introduce a network utility functionUixi for the ith receiver. The network utility function is a mapping of user benefit to the transmission rate. By increasing the transmission rate, the user can acquire more enhancement layers, and the user benefit is also increased. Hence, the network utility function is assumed to be concave and differentiable. Consider a wireless network with N receivers and K links, the transmission control problem is presented as network utility maximization [37]:(3)maximizexr>0∑i=1NUixi,subjectto∑i=1Kdjixi≤Cj,whereCj is the link capacity and the inequality constraint means that the total transmission rate should be not greater than the link capacity. dji is the portion of transmission flow carried by the link j. Let λj be the Lagrange multiplier for the capacity constraint of the link j. The Lagrangian is defined as(4)Lx,λ=∑i=1NUixi−∑j=1Kλj∑i=1Ndjixi−Cj,where the last term can be considered as the penalty if the total transmission rate exceeds the link capacity. Because the object function of (3) is concave and the inequality constraint is linear, the network utility maximization forms a convex optimization problem. From Karush–Kuhn–Tucker (KKT) conditions, we can derive from taking the derivative of Lx,λ respect to xi:(5)Ui′xi∗−∑j=1Kλj∗dji=0.At the equilibrium point, the derivative of the transmission rate (2) is zero. The packet loss caused by the congestion is also a penalty; with (5), we can obtain(6)Ui′xi=1α+RTT2xbasexi.Then, the utility function is(7)Uixi=logα+RTT2xbasexiRTT2xbase.Although there are different optimization algorithms [38–40], with the analytical expression of the utility function, the convex optimization algorithm is carried out to find the optimal solution.


## 3.4. MEC Assistant Link Loss Recovery

As explained in the previous section, the packet loss can happen in wired and wireless links. Usually, the loss in the wired link is caused by the routing nodes proactively dropping packets to prevent the link congestion. On the other hand, the loss in the wireless link is due to wireless link error. The packet loss can be recovered by Automatic Repeat reQuest (ARQ) or forward error correction. In our proposed system scheme as shown in Figure4, the MEC server, routing nodes, and the video server are able to store the video content. The receiver may obtain data packets from different nodes; hence, the ARQ is improper. Our proposed mechanism adopts the FEC approach to recover packet loss in the wireless link. The generation of the FEC packet is offloaded to the MEC server from the video server. Since all data packets must go through the wireless base station to the receiver. The MEC server collects the video data and generates FEC packets. The FEC packet is retrieved from the MEC server instead of the video server; the workload of wired links is vastly reduced. When the receiver gets the wireless loss rate from the MEC server, the minimum number of FEC packets required to overcome the loss is(8)WFEC=WPITPwireless1−Pwireless,where WPITPwireless is the expected number of packet loss. Depending on the current transmission rate WPIT, the receiver sends interest packets for FEC. The detailed steps of our proposed mechanism are presented in Algorithm 1.Algorithm 1: Adaptive Transmission Control Algorithm.
1:if arriving data packet then2: obtain packet loss ratePwireless from packet header3:WPIT=1+αWPIT4: clear timeout countern=0.5:end if6:if PIT timeout then7: calculate total packet loss ratePtotal.8: increase timeout countern=n+19:ifPtotal>Pwirelessthen10:ifWPIT>Wbasethen11:WPIT=Wbase12:else13:WPIT=βnWbase14:end if15:else16: calculate number of FEC packetWFEC17: send FEC interest packets to overcome loss18:end if19:end if


## 4. Experiment Results and Analysis

To analyse the performance of our proposed mechanism, a series of experiments were carried out with NS-3 simulator [41]. We used H.264/scalable video coding to compress the raw video sequences “Elephants Dream” [42]. The proposed mechanism was compared with DL-LRM [35] and CCN default approach [7] with the same network conditions. The encoded video consisted of one base layer and three enhancement layers. The network topology of experiments included wired and wireless links. The links from the video server to the base stations were wired and the bandwidth was 1 Gigabit per second. The base stations communicated with end nodes through wireless link, and the bandwidth was 100 Megabits per second. There were 200 end nodes, and the nodes were divided into 10 groups. Each group node requested the same video content to simulate network congestion. The experiments were conducted under different packet loss rates to simulate wireless link error.Figure5 shows the video quality of receivers with no wireless link error. Because the DL-LRM and CCN default approach have no control of transmission rate, even the network is congested, the two approaches still aggressively send interest packets. This results in numerous packets being dropped by routing nodes and decreasing video quality.Figure 5
Video quality with no wireless link error.With increasing wireless link error rate, the number of packet loss is also increased. As described in Section2, each PIT entry has a timer which value is called LifeTime. The LifeTime is set by the receiver, and it should be larger than the upper bound of RTT samples. The reason is that every node in CCN has a PIT. If a timeout arises at an end node, the node may retransmit the interest packet. If a timeout arises at a routing node, the PIT entry is deleted. Later, if the data packet arrives, and there is no corresponding PIT entry, then the data packet is abandoned. On account of the in-network caching function of CCN, the data packets may be retrieved from different nodes and the RTT value has high fluctuation. The default CCN approach for packet loss is ARQ, and the LifeTime is set to a constant value. The video streaming application is delay sensitive. If the loss packet is recovered, nonetheless it exceeds the playtime, then the packet is useless. From experiment results shown in Figures 6 and 7, the performance of the default CCN approach drops dramatically with the increase of the error rates.Figure 6
Video quality with 8% wireless link error rate.Figure 7
Video quality with 12% wireless link error rate.Our proposed mechanism distinguishes the cause of packet loss. If the network is congested, then the transmission is limited to the request for the base layer only to relieve the congestion. If the loss is caused by wireless link error, FEC packets are requested. The DL-LRM does not identify the reason of packet loss and just sends FEC packets to respond to the PIT timeout. As presented in Figure8, our proposed mechanism outperforms the DL-LRM and default CCN approach under different network conditions.Figure 8
Average video quality with various wireless link error rates.


## 5. Conclusions

In this paper, we have presented an adaptive video transmission mechanism in Mobile Edge Computing- (MEC-) based CCN. The main contribution of our mechanism is to adaptively control transmission rate to adapt to the network conditions variation, instead of greedily acquiring video content. Therefore, it can friendly coexist with different types of applications and improve overall network efficiency. We adopt scalable video coding (SVC) scheme to balance the video quality and transmission rate. In addition, the MEC assistant loss recovery algorithm is suggested to reduce the burden of the video streaming server and backhaul network. The experiment results show that our proposed mechanism outperforms the existing approaches. For future work, we will study the scalability issue and analyse the performance in a large network environment.



---

*Source: 9968550-2021-07-17.xml*