## 4 Random Linear Network Coding for Mobile Video Delivery
### RLNC: Where Should It Be?
#### 4.1.1 End-to-end Solutions for RLNC  
**Application Layer RLNC:** The simplest and easiest approach to integrate RLNC sublayer into mobile video delivery is to perform application-layer RLNC (AL-RLNC). In particular, for multicast/broadcast scenario (eMBMS), the required infrastructure is already in place, as eMBMS provides native support for AL-FEC [9]. However, in this case, RLNC provides similar performance as compared to already proposed AL-FEC solutions such as Raptor codes [57] or LDPC triangle/staircase codes [58], providing limited benefit since no re-encoding at intermediate nodes is typically assumed in multicast/broadcast setup. Nevertheless, a large number of academic studies considered application and optimization of RLNC for mobile multicast video delivery demonstrating various benefits in different scenarios [59; 60; 61; 62]. Besides notable benefits of AL-RLNC in terms of flexibility and ease of implementation, there are several drawbacks of AL-RLNC worth emphasizing. AL-RLNC introduces redundancy either at the content server or BM-SC (eMBMS) thus adding significant communication overhead across the entire end-to-end IP multicast session, including typically reliable and over-provisioned core network optical links. In addition, AL-RLNC is transparent to lower layers and, in practice, it is hard to provide cross-layer optimized solution, e.g., at unreliable eNB/UE interface, that takes into account AL-RLNC. For unicast video streaming services, AL-RLNC is usually not considered as the most popular ABR/PD streaming solutions rely on HTTP via TCP, which already provides reliable packet delivery. However, this might change as more and more ABR traffic moves to Quick UDP Internet Connections (QUIC) protocol which relies on UDP [63]. However, note that most of the current unicast video traffic is encrypted, which might introduce practical limitations in applying RLNC at all layers below the application layer.  
**Transport Layer RLNC:** Another possibility for end-to-end RLNC is integration of RLNC sublayer in transport layer protocols. In the case of TCP, a groundbreaking idea has been investigated in which, instead of source packets, TCP transmits coded packets, and where instead of acknowledgement of individual source packets, the TCP receiver acknowledges received \"degrees of freedom\", i.e., the rank of the decoding matrix currently available at the receiver [64; 65]. Clearly, coded TCP is suitable solution for unicast ABR/PD video services which rely on TCP, thus any throughput improvements of coded TCP over traditional TCP would reflect on OTT video traffic. In addition, with VO platform in-the-middle (Section 3.2), it is possible to split TCP connection between the ABR/PD streaming client and the content server, thus independently optimizing each of the two resulting TCP connections: the one between the UE and the VO platform, and the one between the VO platform and the content server. As a potential obstacle to coded TCP, its impact on TCP congestion control has yet to be better understood [66].  
Figure 4: RLNC sublayer position options for mobile video delivery.