<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?> "rfc2629-xhtml.ent">

<rfc
	category="info" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-irtf-nwcrg-network-coding-satellites-15"
	ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" -->
number="8975" ipr="trust200902" obsoletes="" updates="" submissionType="IRTF" category="info"
consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true"
version="3">

<!-- ***** FRONT MATTER ***** xml2rfc v2v3 conversion 3.5.0 -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 39 characters -->

    <title abbrev="Network coding Coding for satellite systems">Network coding Satellite Systems">Network Coding for satellite systems</title> Satellite Systems</title>
    <seriesInfo name="RFC" value="8975"/>
    <author role="editor" fullname="Nicolas Kuhn" initials="N" surname="Kuhn">
      <organization>CNES</organization>
      <address>
        <postal>
          <street>18 avenue Edouard Belin</street>
          <city>Toulouse</city>
          <region></region>
          <region/>
          <code>31400</code>
          <country>France</country>
        </postal>
        <phone></phone>
        <phone/>
        <email>nicolas.kuhn@cnes.fr</email>
      </address>
    </author>
    <author role="editor" fullname="Emmanuel Lochin" initials="E" surname="Lochin">
      <organization>ENAC</organization>
      <address>
        <postal>
          <street>7 avenue Edouard Belin</street>
          <city>Toulouse</city>
          <region></region>
          <region/>
          <code>31400</code>
          <country>France</country>
        </postal>
        <phone></phone>
        <phone/>
        <email>emmanuel.lochin@enac.fr</email>
      </address>
    </author>
    <date year="2020" year="2021" month="January" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
         in the current day for you. If only the current year is specified, xml2rfc will fill
	 in the current day and month for you. If the year is not the current one, it is
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>Transport</area>

    <workgroup>NetWork Communications Research Group (NWCRG)</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine
    <workgroup>Coding for individual submissions.
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>SATCOM, coding Efficient Network Communications</workgroup>
    <keyword>SATCOM</keyword>
    <keyword>coding techniques</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

        <!-- ######################################################-->
        <!-- ######################################################-->
        <!-- Head of the document -->
        <!-- ######################################################-->
        <!-- ######################################################-->

    <abstract>

      <t>This document is one a product of the Coding for Efficient Network Communications Research Group (NWCRG). It conforms to the directions found in the NWCRG taxonomy.</t> taxonomy (RFC 8406).</t>
      <t>The objective is to contribute to a larger deployment of network coding Network Coding techniques in and above the network layer in satellite communication systems. The This document also identifies open research issues related to the deployment of network coding Network Coding in satellite communication systems.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="sec:introduction" title="Introduction"> anchor="sec_introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document is one a product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); while it is not an IETF product and not a standard standard, it intends is intended to inform the SATellite COMmunication (SATCOM) and Internet research communities about recent developments in Network Coding. A glossary is included in <xref target="sec:glossary"></xref> target="sec_glossary" format="default"/> to clarify the terminology use used throughout the document.</t>
      <t>As will be shown in this document, the implementation of network coding Network Coding techniques above the network layer, at application or transport layers (as described in <xref target="RFC1122"></xref>), target="RFC1122" format="default"/>), offers an opportunity for improving the end-to-end performance of SATCOM systems. While physical- Physical- and link-layer coding error protection is usually enough to provide Quasi-Error Free transmission quasi-error-free transmission, thus minimizing packet loss, loss. However, when residual errors at those layers cause packet losses, retransmissions add significant delays (in particular particular, in geostationary systems with over 0.7 second round-trip delays). Hence Hence, the use of network coding Network Coding at the upper layers can improve the quality of service in SATCOM subnetworks and eventually favorably impact the experience of end users.</t>
      <t>While there is an active research community working on network coding Network Coding techniques above the network layer in general and in SATCOM in particular, not much of this work has been deployed in commercial systems. In this context, this document identifies opportunities for further usage of network coding Network Coding in commercial SATCOM networks.</t>
      <t>The notation used in this document is based on the NWCRG taxonomy <xref target="RFC8406"> </xref>:<list style="symbols">
		<t>Channel target="RFC8406" format="default"> </xref>:</t>
      <ul spacing="normal">
        <li>Channel and link error correcting error-correcting codes are considered part of the error protection for the PHYsical (PHY) layer error protection and are out of the scope of this document.</t>
		<t>Forward document.</li>
        <li>Forward Erasure Correction (FEC) (also called Application-Level FEC) "Application-Level FEC") operates above the link layer and targets packet loss recovery.</t>
		<t>This packet-loss recovery.</li>
        <li>This document considers only coding (or coding techniques or coding schemes) that use uses a linear combination of packets and excludes packets; it excludes, for example example, content coding (e.g., to compress a video flow) or other non-linear operation.</t>
	</list></t>

	<!-- <t>Reliability is an inherent part of the physical-layer and usually achieved by using coding techniques. Based operations.</li>
      </ul>
	</section>

        <section anchor="sec_sat_topo" numbered="true" toc="default">
      <name>A Note on public information, coding does not seem to be widely used at higher layers.</t> -->
	<!-- <t>This memo presents use-cases where network coding schemes could improve the overall performance Topology of a SATCOM system (e.g. considering a more efficient usage of the satellite resource, delivery delay, delivery ratio).</t> -->

	<!-- <section anchor="subsec:intro_requi" title="Requirements Language">
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119">RFC&nbsp;2119</xref>.</t>
	</section> -->
	</section>

        <!-- ######################################################-->
        <!-- ######################################################-->
        <!-- Body of the document -->
        <!-- ######################################################-->
        <!-- ######################################################-->

        <!-- ######################################################-->
        <!-- New section -->
        <!-- ######################################################-->

        <section anchor="sec:sat_topo" title="A Note on Satellite Networks Topology">
		<t>There are multiple Satellite Networks</name>
      <t>There are multiple SATCOM systems, for example example, broadcast TV, point to point communication or IoT point-to point-communication, and Internet of Things (IoT) monitoring. Therefore, depending on the purpose of the system, the associated ground segment architecture will be different. This section focuses on a satellite system that follows the European Telecommunications Standards Institute (ETSI) Digital Video Broadcasting (DVB) standards to provide broadband Internet access via ground-based gateways <xref target="ETSIEN2014"></xref>. target="ETSI-EN-2020" format="default"/>. One must note that the overall data capacity of one satellite may be higher than the capacity that one single gateway supports. Hence, there are usually multiple gateways for one unique satellite platform.</t>

      <t>In this context, <xref target="fig:sat_gateway"></xref> target="fig_sat_gateway" format="default"/> shows an example of a multi-gateway multigateway satellite system, where BBFRAME stands for Base-Band FRAME, "Base-Band FRAME", PLFRAME for Physical "Physical Layer FRAME FRAME", and PEP for Performance "Performance Enhancing Proxy. Proxy". More information on a generic SATCOM ground segment architecture for bidirectional Internet access can be found in <xref target="SAT2017"></xref>.</t>

	<figure anchor="fig:sat_gateway" title="Data plane functions in a generic satellite multi-gateway system. More details can be found target="SAT2017" format="default"/> or in DVB standard documents.">
        <artwork> documents.</t>
      <figure anchor="fig_sat_gateway">

        <name>Data-Plane Functions in a Generic Satellite Multigateway System</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
+--------------------------+
| application servers      |
| (data, coding, multicast)|
+--------------------------+
       | ... |
       -----------------------------------
       |     |   |             |   |     |
+--------------------+     +--------------------+
+---------------------+     +---------------------+
| network function    |     | network function    |
|(firewall, PEP, etc)| etc.)|     |(firewall, PEP, etc)|
+--------------------+     +--------------------+ etc.)|
+---------------------+     +---------------------+
    | ... | IP packets             |  ...   |
                                                ---
+------------------+         +------------------+ |
| access gateway   |         | access gateway   | |
+------------------+         +------------------+ |
       | BBFRAME                         |        | gateway
+------------------+         +------------------+ |
| physical gateway |         | physical gateway | |
+------------------+         +------------------+ |
                                                ---
       | PLFRAME                         |
+------------------+         +------------------+
| outdoor unit     |         | outdoor unit     |
+------------------+         +------------------+
       | satellite link                  |
+------------------+         +------------------+
| outdoor unit     |         | outdoor unit     |
+------------------+         +------------------+
       |                                 |
+------------------+         +------------------+
| sat terminals    |         | sat terminals    |
+------------------+         +------------------+
       |        |                  |        |
+----------+    |            +----------+   |
|end user 1|    |            |end user 3|   |
+----------+    |            +----------+   |
          +----------+               +----------+
          |end user 2|               |end user 4|
          +----------+               +----------+
        </artwork>
        ]]></artwork>
      </figure>
    </section>

        <!-- ######################################################-->
        <!-- New section -->
        <!-- ######################################################-->

        <section anchor="sec:use_cases" title="Use-cases anchor="sec_use_cases" numbered="true" toc="default">
      <name>Use Cases for Improving SATCOM System Performance Using Network Coding"> Coding</name>
      <t>This section details use-cases use cases where network coding Network Coding techniques could improve SATCOM system performance.</t>
      <section anchor="subsec:two-way" title="Two-way anchor="subsec_two-way" numbered="true" toc="default">
        <name>Two-Way Relay Channel Mode"> Mode</name>
        <t>This use-case use case considers two-way communication between end-users, end users through a satellite link link, as seen in <xref target="fig:two_way"></xref>.</t> target="fig_two_way" format="default"/>.</t>
        <t>Satellite terminal A sends a packet flow A A, and satellite terminal B sends a packet flow B B, to a coding server. The coding server then sends a combination of both flows instead of each individual flows. flow. This results in non-negligible capacity savings that savings, which has been demonstrated in the past <xref target="ASMS2010"></xref>. target="ASMS2010" format="default"/>. In the example, a dedicated coding server is introduced (note that its location could be different based on deployment use-case). use case). The network coding Network Coding operations could also be done at the satellite level, although this would require a lot of computational resources on-board onboard and may not be supported by today's satellites.</t>
        <figure anchor="fig:two_way" title="Network anchor="fig_two_way">
          <name>Network Architecture for Two-way Two-Way Relay Channel using NC">
        <artwork> Using Network Coding </name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
-X}-   : traffic from satellite terminal X to the server
={X+Y= : traffic from X and Y combined sent from
         the server to terminals X and Y

+-----------+        +-----+
|Sat term A |--A}-+  |     |
+-----------+     |  |     |      +---------+      +------+
    ^^            +--|     |--A}--|         |--A}--|Coding|
    ||               | SAT |--B}--| Gateway |--B}--|Server|
    ===={A+B=========|     |={A+B=|         |={A+B=|      |
    ||               |     |      +---------+      +------+
    vv            +--|     |
+-----------+     |  |     |
|Sat term B |--B}-+  |     |
+-----------+        +-----+
        </artwork>
        ]]></artwork>
        </figure>
      </section>
      <section anchor="subsec:rel-mul" title="Reliable Multicast"> anchor="subsec_rel-mul" numbered="true" toc="default">
        <name>Reliable Multicast</name>
        <t>The use of multicast servers is one way to better utilize satellite broadcast capabilities. As one example example, satellite-based multicast is proposed in the SHINE ESA Secure Hybrid In Network caching Environment (SHINE) project of the European Space Agency (ESA) <xref target="I-D.vazquez-nfvrg-netcod-function-virtualization"> target="I-D.vazquez-nfvrg-netcod-function-virtualization" format="default"> </xref> <xref target="SHINE"> target="SHINE" format="default"> </xref>. This use-case use case considers adding redundancy to a multicast flow depending on what has been received by different end-users, end users, resulting in non-negligible savings of the scarce SATCOM resources. This scenario is shown in <xref target="fig:rel_multi"></xref>.</t> target="fig_rel_multi" format="default"/>.</t>
        <figure anchor="fig:rel_multi" title="Network anchor="fig_rel_multi">
          <name>Network Architecture for a Reliable Multicast using NC">
        <artwork> Using Network Coding</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
-Li}- : packet indicating the loss of packet i of a multicast flow M
={M== : multicast flow including the missing packets

+-----------+       +-----+
|Terminal A |-Li}-+ |     |
+-----------+     | |     |      +---------+  +------+
    ^^            +-|     |-Li}--|         |  |Multi |
    ||              | SAT |-Lj}--| Gateway |--|Cast  |
    ===={M==========|     |={M===|         |  |Server|
    ||              |     |      +---------+  +------+
    vv            +-|     |
+-----------+     | |     |
|Terminal B |-Lj}-+ |     |
+-----------+       +-----+
        </artwork>
        ]]></artwork>
        </figure>

        <t>A multicast flow (M) is forwarded to both satellite terminals A and B. However packet M is composed of packets Nk (not shown in <xref target="fig_rel_multi" format="default"/>). Packet Ni (respectively Nj) gets lost at terminal A (respectively B), and terminal A (respectively B) returns a negative acknowledgment Li (respectively Lj), indicating that the packet is missing. Using coding, either the access gateway or the multicast server can include a repair packet (rather than the individual Ni and Nj packets) in the multicast flow to let both terminals recover from losses.</t>

        <t>This could also be achieved by using other multicast or broadcast systems, such as NACK-Oriented Reliable Multicast (NORM) <xref target="RFC5740"></xref> target="RFC5740" format="default"/> or File Delivery over Unidirectional
Transport (FLUTE) <xref target ="RFC6726"></xref>. target="RFC6726" format="default"/>. Both NORM and FLUTE are limited to block coding; neither of them support supports more flexible sliding window encoding schemes that allow decoding before receiving the whole block block, which is an added delay benefit <xref target="RFC8406"></xref><xref target="RFC8681"></xref>.</t> target="RFC8406" format="default"/> <xref target="RFC8681" format="default"/>.</t>
      </section>
      <section anchor="subsec:hybrid" title="Hybrid Access"> anchor="subsec_hybrid" numbered="true" toc="default">
        <name>Hybrid Access</name>
        <t>This use-case use case considers improving multiple path multiple-path communications with network coding Network Coding at the transport layer (see <xref target="fig:hyb_access"></xref>, target="fig_hyb_access" format="default"/>, where DSL stands for Digital "Digital Subscriber Line, Line", LTE for Long "Long Term Evolution Evolution", and SAT for SATellite). "SATellite"). This use-case use case is inspired by the Broadband Access via Integrated Terrestrial Satellite Systems (BATS) project and has been published as an ETSI Technical Report <xref target="ETSITR2017"></xref>.</t> target="ETSI-TR-2017" format="default"/>.</t>
        <t>To cope with packet loss (due to either end-user mobility or physical-layer residual errors), network coding Network Coding can be introduced. Depending on the protocol, network coding Network Coding could be applied at each of the Customer Premises Equipment (CPE) and at (CPE), the concentrator concentrator, or both.

Apart from coping with packet losses, loss, other gains from benefits of this approach include a better tolerance to for out-of-order packet delivery delivery, which occur occurs when exploited links exhibit high asymmetry in terms of Round-Trip Time (RTT). Depending on the ground architecture <xref target="I-D.chin-nfvrg-cloud-5g-core-structure-yang"></xref> target="I-D.chin-nfvrg-cloud-5g-core-structure-yang" format="default"/> <xref target="SAT2017"></xref>, target="SAT2017" format="default"/>, some ground equipment might be hosting both SATCOM and cellular network functionality.</t>
        <figure anchor="fig:hyb_access" title="Network anchor="fig_hyb_access">
          <name>Network Architecture for a Hybrid Access Using Network Coding">
        <artwork> Coding</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
-{}- : bidirectional link

                        +---+    +--------------+
                   +-{}-|SAT|-{}-|BACKBONE      |
+----+    +---+    |    +---+    |+------------+|
|End |-{}-|CPE|-{}-|             ||CONCENTRATOR||
|User|    +---+    |    +---+    |+------------+|    +-----------+
+----+             |-{}-|DSL|-{}-|              |-{}-|Application|
                   |    +---+    |              |    |Server     |
                   |             |              |    +-----------+
                   |    +---+    |              |
                   +-{}-|LTE|-{}-+--------------+
                        +---+
        </artwork>
        ]]></artwork>
        </figure>
      </section>
      <section anchor="subsec:varying_wifi" title="LAN anchor="subsec_varying_wifi" numbered="true" toc="default">
        <name>LAN Packet Losses"> Losses</name>
        <t>This use-case use case considers using network coding Network Coding in the scenario where a lossy WIFI WiFi link is used to connect to the SATCOM network. When encrypted end-to-end applications based on UDP are used, a Performance Enhancing Proxy (PEP) cannot operate hence operate; hence, other mechanism mechanisms need to be used. The WIFI WiFi packet losses will result in an end-to-end retransmission that will harm the end-user quality of the end user's experience and poorly utilize SATCOM bottleneck resource resources for non-revenue generating traffic. traffic that does not generate revenue. In this use-case, use case, adding network coding Network Coding techniques will prevent the end-to-end retransmission from occurring since the packet losses would probably be recovered.</t>
        <t>The architecture is shown in <xref target="fig:varying_wifi-loss"></xref>.</t> target="fig_varying_wifi-loss" format="default"/>.</t>
        <figure anchor="fig:varying_wifi-loss" title="Network anchor="fig_varying_wifi-loss">
          <name>Network Architecture for dealing Dealing with LAN Losses">
        <artwork> Losses</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
-{}- : bidirectional link
-''- : Wi-Fi WiFi link
C : where network coding Network Coding techniques could be introduced

+----+    +--------+    +---+    +-------+    +-------+    +--------+
|End |    |Sat.    |    |SAT|    |Phy    |    |Access |    |Network |
|user|-''-|Terminal|-{}-|   |-{}-|Gateway|-{}-|Gateway|-{}-|Function|
+----+    +--------+    +---+    +-------+    +-------+    +--------+
   C          C                                  C            C
        </artwork>
        ]]></artwork>
        </figure>
      </section>
      <section anchor="subsec:varying" title="Varying anchor="subsec_varying" numbered="true" toc="default">
        <name>Varying Channel Conditions"> Conditions</name>
        <t>This use-case use case considers the usage of network coding Network Coding to cope with sub second subsecond physical channel condition changes where the physical-layer mechanisms (Adaptive Coding and Modulation (ACM)) may not adapt the modulation and error-correction coding in time: time; the residual errors lead to higher layer higher-layer packet losses that can be recovered with network coding. Network Coding. This use-case use case is mostly relevant when mobile users are considered or when the satellite frequency band introduces quick changes in channel condition (Q/V bands, Ka band, etc.). Depending on the use-case use case (e.g., bands with very high frequency bands, frequency, mobile users), the relevance of adding network coding Network Coding is different.</t>
        <t>The system architecture is shown in <xref target="fig:varying_capa"></xref>.</t> target="fig_varying_capa" format="default"/>.</t>
        <figure anchor="fig:varying_capa" title="Network anchor="fig_varying_capa">
          <name>Network Architecture for dealing Dealing with Varying Link Characteristics">
        <artwork> Characteristics</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
-{}- : bidirectional link
C : where network coding Network Coding techniques could be introduced

+---------+    +---+    +--------+    +-------+    +--------+
|Satellite|    |SAT|    |Physical|    |Access |    |Network |
|Terminal |-{}-|   |-{}-|Gateway |-{}-|Gateway|-{}-|Function|
+---------+    +---+    +--------+    +-------+    +--------+
     C                       C            C           C
        </artwork>
        ]]></artwork>
        </figure>
      </section>
      <section anchor="subsec:gat_hand" title="Improving anchor="subsec_gat_hand" numbered="true" toc="default">
        <name>Improving Gateway Handover"> Handover</name>
        <t>This use-case use case considers the recovery of packets that may be lost during gateway handover. Whether for off-loading a given equipment or because the transmission quality differs from gateway to gateway, switching the transmission gateway may be beneficial. However, packet losses can occur if the gateways are not properly synchronized or if the algorithm used to trigger gateway handover is not properly tuned. During these critical phases, network coding Network Coding can be added to improve the reliability of the transmission and allow a seamless gateway handover.</t>
        <t><xref target="fig:gat_hand"></xref> target="fig_gat_hand" format="default"/> illustrates this use-case.</t> use case.</t>
        <figure anchor="fig:gat_hand" title="Network anchor="fig_gat_hand">
          <name>Network Architecture for dealing Dealing with Gateway Handover">
        <artwork> Handover</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
-{}- : bidirectional link
!   : management interface
C : where network coding Network Coding techniques could be introduced
                                        C             C
                      +--------+    +-------+    +--------+
                      |Physical|    |Access |    |Network |
                 +-{}-|gateway |-{}-|gateway|-{}-|function|
                 |    +--------+    +-------+    +--------+
                 |                        !       !
+---------+    +---+              +---------------+
|Satellite|    |SAT|              | Control plane Control-plane |
|Terminal |-{}-|   |              | manager       |
+---------+    +---+              +---------------+
                 |                        !       !
                 |    +--------+    +-------+    +--------+
                 +-{}-|Physical|-{}-|Access |-{}-|Network |
                      |gateway |    |gateway|    |function|
                      +--------+    +-------+    +--------+
                                        C             C
        </artwork>
        ]]></artwork>
        </figure>
      </section>
    </section>

        <!-- ######################################################-->
        <!-- New section -->
        <!-- ######################################################-->

        <section anchor="sec:deploy" title="Research Challenges"> anchor="sec_deploy" numbered="true" toc="default">
      <name>Research Challenges</name>
      <t>This section proposes a few potential approaches to introduce introducing and use network coding using Network Coding in SATCOM systems.</t>
      <section anchor="sec:deploy_pep" title="Joint-use anchor="sec_deploy_pep" numbered="true" toc="default">
        <name>Joint Use of Network Coding and Congestion Control in SATCOM Systems"> Systems</name>
        <t>Many SATCOM systems typically use Performance Enhancing Proxy (PEP) <xref target="RFC3135">RFC&nbsp;3135</xref>. target="RFC3135" format="default" />. PEPs usually split end-to-end connections and forward transport or application layer application-layer packets to the satellite baseband gateway. PEPs contribute to mitigate mitigating congestion in a SATCOM systems system by limiting the impact of long delays on Internet protocols. A PEP mechanism could also include network coding Network Coding operation and thus support the use-cases use cases that have been discussed in the <xref target="sec:use_cases"></xref> target="sec_use_cases" format="default"/> of this document.</t>
        <t>Deploying network coding Network Coding in the PEP could be relevant and be independent from the specifics of a SATCOM link. This however This, however, leads to research questions dealing with the potential interaction between network coding Network Coding and congestion control. This is discussed in <xref target="I-D.irtf-nwcrg-coding-and-congestion"></xref>.</t> target="I-D.irtf-nwcrg-coding-and-congestion" format="default"/>.</t>
      </section>
      <section anchor="sec:deploy_coding" title="Efficient anchor="sec_deploy_coding" numbered="true" toc="default">
        <name>Efficient Use of Satellite Resources"> Resources</name>
        <t>There is a recurrent trade-off in SATCOM systems: how much overhead from redundant reliability packets can be introduced to guarantee a better end-user QoE Quality of Experience (QoE) while optimizing capacity usage? At which layer should this supplementary redundancy should be added?</t>
        <t>This problem has been tackled in the past by the deployment of physical-layer error-correction codes, but there remains questions remain on adapting the coding overhead and added delay for, e.g., the quickly varying channel conditions use-case use case where ACM may not be reacting quickly enough enough, as was discussed in <xref target="subsec:varying"></xref>. The target="subsec_varying" format="default"/>. A higher layer with network coding Network Coding does not react more quickly than the physical layer, but it may operate over a packet-based time window that is larger than the physical one.</t>
      </section>
      <section anchor="sec:deploy_nfv" title="Interaction anchor="sec_deploy_nfv" numbered="true" toc="default">
        <name>Interaction with Virtualized Satellite Gateways and Terminals"> Terminals</name>

        <t>In the emerging virtualized network infrastructure, network coding Network Coding could be easily deployed as Virtual Network Functions (VNF). (VNFs). The next generation of SATCOM ground segments will rely on a virtualized environment to integrate to with terrestrial networks. This trend towards Network Function Virtualization (NFV) is also central to 5G and next generation next-generation cellular networks, making this research applicable to other deployment scenarios <xref target="I-D.chin-nfvrg-cloud-5g-core-structure-yang"> target="I-D.chin-nfvrg-cloud-5g-core-structure-yang" format="default"> </xref>. As one example, the network coding Network Coding VNF deployment in a virtualized environment has been presented in <xref target="I-D.vazquez-nfvrg-netcod-function-virtualization"> target="I-D.vazquez-nfvrg-netcod-function-virtualization" format="default"> </xref>.</t>
        <t>A research challenge would be the optimization of the NFV service function chaining, considering a virtualized infrastructure and other SATCOM specific SATCOM-specific functions, in order to guarantee efficient radio-link usage and provide easy-to-deploy SATCOM services. Moreover, another challenge related to a virtualized SATCOM equipment is the management of limited buffered capacities in large gateways.</t>
      </section>
      <section anchor="subsec:dtn" title="Delay/Disruption Tolerant Networking (DTN)">
<!--	<t>In the context of deep-space communications, establishing communications from terrestrial gateways to satellite platforms can be a challenge. Indeed, reliable end-to-end (E2E) communications over such links must cope with long delay and frequent link disruptions. Delay/Disruption Tolerant anchor="subsec_dtn" numbered="true" toc="default">
        <name>Delay/Disruption-Tolerant Networking <xref target="RFC4838"></xref> is a solution to enable reliable internetworking space communications where both standard ad-hoc routing and E2E Internet protocols cannot be used. The transport of data over such networks requires the use of replication, erasure codes and multipath protocol schemes <xref target="WANG05"></xref> <xref target="ZHANG06"></xref> to improve the bundle delivery ratio and/or delivery delay. For instance, transport protocols such as LTP <xref target="RFC5326"></xref> for long delay links with connectivity disruptions, use Automatic Repeat-reQuest (ARQ) and unequal error protection to reduce the amount of non-mandatory re-transmissions. The work in <xref target="TOURNOUX10"></xref> proposed upon LTP a robust streaming method based on an on-the-fly coding scheme, where encoding and decoding procedures are done at the source and destination nodes, respectively. However, each link path loss rate may have various order of magnitude and re-encoding at an intermediate node to adapt the redundancy can be mandatory to prevent transmission wasting. This idea has been put forward in <xref target="I-D.zinky-dtnrg-random-binary-fec-scheme"></xref> and <xref target="I-D.zinky-dtnrg-erasure-coding-extension"></xref>, where the authors proposed an encoding process at intermediate DTN nodes to explore the possibilities of Forward Error Correction (FEC) schemes inside the bundle protocol <xref target="RFC5050"></xref>. In this context, the use of erasure coding inside a Consultative Committee for Space Data Systems (CCSDS) architecture has been specified in <xref target="CCSDS-131.5-O-1"></xref>.</t> --> (DTN)</name>
	<t>Communications among deep-space platforms and terrestrial gateways can be a challenge. Reliable end-to-end (E2E) communications over such paths must cope with very long delays and frequent link disruptions; indeed, E2E connectivity may only be available intermittently, if at all. Delay/Disruption Tolerant Delay/Disruption-Tolerant Networking (DTN) <xref target="RFC4838"></xref> target="RFC4838" format="default"/> is a solution to enable reliable internetworking space communications where both neither standard ad-hoc ad hoc routing and nor E2E Internet protocols cannot can be used. Moreover, DTN can also be seen as an alternative solution to transfer data between a central PEP and a remote PEP.</t>
        <t>Network Coding enables E2E reliable communications over a DTN with potential adaptive re-encoding, as proposed in <xref target="THAI15"></xref>. target="THAI15" format="default"/>. Here, the use-cases use case proposed in <xref target="subsec:varying"></xref> target="subsec_varying" format="default"/> would encourage the usage of network coding Network Coding within the DTN stack to improve utilization of the physical channel utilization and minimize the effects of the E2E transmission delays. In this context, the use of packet erasure coding techniques inside a Consultative Committee for Space Data Systems (CCSDS) architecture has been specified in <xref target="CCSDS-131.5-O-1"></xref>. target="CCSDS-131.5-O-1" format="default"/>. One research challenge remains on remains: how such network coding Network Coding can be integrated in the IETF DTN stack.</t>

<!-- The objective is to extend the CCSDS File Delivery Protocol (CFDP) <xref target="CCSDS-FDP"></xref> with erasure coding capabilities where a Low Density Parity Check (LDPC) <xref target="RFC6816"></xref> code with a large block size is chosen. Recently, on-the-fly erasure coding schemes <xref target="LACAN08"></xref> <xref target="SUNDARARAJAN08"></xref> <xref target="TOURNOUX11"></xref> have shown their benefits in terms of recovery capability and configuration complexity compared to traditional FEC schemes. Using a feedback path when available, on-the-fly schemes can be used to enable E2E reliable communication over DTN with adaptive re-encoding as proposed in <xref target="THAI15"></xref>. -->

	</section>

	</section>

        <!-- ######################################################-->
        <!-- New section -->
        <!-- ######################################################-->
        <section anchor="sec:conclu" title="Conclusion">

        <t>This document introduces some wide-scale network coding technique opportunities in satellite telecommunications systems.</t>

        <t>Even though this document focuses on satellite systems, it

	</section>
    </section>

        <section anchor="sec_conclu" numbered="true" toc="default">
      <name>Conclusion</name>
      <t>This document introduces some wide-scale Network Coding technique opportunities in satellite telecommunications systems.</t>
      <t>Even though this document focuses on satellite systems, it is worth pointing out that some scenarios proposed here may be relevant to other wireless telecommunication systems. As one example, the generic architecture proposed in <xref target="fig:sat_gateway"></xref> target="fig_sat_gateway" format="default"/> may be mapped onto cellular networks as follows: the 'network function' block gathers some of the functions of the Evolved Packet Core subsystem, while the 'access gateway' and 'physical gateway' blocks gather the same type of functions as the Universal Mobile Terrestrial Radio Access Network. This mapping extends the opportunities identified in this document document, since they may also be relevant for cellular networks.</t>
    </section>

        <!-- ######################################################-->
        <!-- ######################################################-->
        <!-- Tail of the document -->
        <!-- ######################################################-->
        <!-- ######################################################-->

	<section anchor="sec:glossary" title="Glossary"> anchor="sec_glossary" numbered="true" toc="default">
      <name>Glossary</name>

      <t>The glossary of this memo extends the glossary definitions of the taxonomy document <xref target="RFC8406"> target="RFC8406" format="default"> </xref> as follows:<list style="symbols">
	<t>ACM : Adaptive follows:</t>

      <dl newline="false" indent="12">
        <dt>ACM:</dt><dd>Adaptive Coding and Modulation;</t>
	<t>BBFRAME: Base-Band Modulation</dd>
        <dt>BBFRAME:</dt><dd>Base-Band FRAME - -- satellite communication layer Layer 2 encapsulation work works as follows: (1) each layer Layer 3 packet is encapsulated with a Generic Stream Encapsulation (GSE) mechanism, (2) GSE packets are gathered to create BBFRAMEs, (3) BBFRAMEs contain information related to how they have to be modulated modulated, and (4) BBFRAMEs are forwarded to the physical-layer;</t>
        <t>CPE: Customer physical layer.</dd>
        <dt>COM:</dt><dd>COMmunication</dd>
        <dt>CPE:</dt><dd>Customer Premises Equipment;</t>
        <t>COM: COMmunication;</t>
	<t>DSL: Digital Equipment</dd>
        <dt>DSL:</dt><dd>Digital Subscriber Line;</t>
        <t>DTN: Delay/Disruption Tolerant Networking;</t>
	<t>DVB: Digital Line</dd>
        <dt>DTN:</dt><dd>Delay/Disruption-Tolerant Networking</dd>
        <dt>DVB:</dt><dd>Digital Video Broadcasting;</t>
	<t>E2E: End-to-end;</t>
        <t>ETSI: European Broadcasting</dd>
        <dt>E2E:</dt><dd>End-to-End</dd>
        <dt>ETSI:</dt><dd>European Telecommunications Standards Institute;</t>
	<t>FEC: Forward Institute</dd>
        <dt>FEC:</dt><dd>Forward Erasure Correction;</t>
	<t>FLUTE: File Correction</dd>
        <dt>FLUTE:</dt><dd>File Delivery over Unidirectional Transport <xref target="RFC6726"></xref>;</t>
	<t>IntraF: Intra-Flow Coding;</t>
	<t>InterF: Inter-Flow Coding;</t>
	<t>IoT: Internet target="RFC6726" format="default"/></dd>
        <dt>IntraF:</dt><dd>Intra-Flow Coding</dd>
        <dt>InterF:</dt><dd>Inter-Flow Coding</dd>
        <dt>IoT:</dt><dd>Internet of Things;</t>
	<t>LTE: Long Things</dd>
        <dt>LTE:</dt><dd>Long Term Evolution;</t>
	<t>MPC: Multi-Path Coding;</t>
	<t>NC: Network Coding;</t>
        <t>NFV: Network Evolution</dd>
        <dt>MPC:</dt><dd>Multi-Path Coding</dd>
        <dt>NC:</dt><dd>Network Coding</dd>
        <dt>NFV:</dt><dd>Network Function Virtualization - -- concept of running software-defined network functions;</t>
	<t>NORM: NACK-Oriented functions</dd>
        <dt>NORM:</dt><dd>NACK-Oriented Reliable Multicast <xref target="RFC5740"></xref>;</t>
        <t>PEP: Performance target="RFC5740" format="default"/></dd>
        <dt>PEP:</dt><dd>Performance Enhancing Proxy <xref target="RFC3135"></xref> - target="RFC3135" format="default"/> -- a typical PEP for satellite communications include includes compression, caching and caching, TCP ACK spoofing spoofing, and specific congestion control tuning;</t>
	<t>PLFRAME: Physical congestion-control tuning.</dd>
        <dt>PLFRAME:</dt><dd>Physical Layer FRAME - -- modulated version of a BBFRAME with additional information (e.g., related to synchronization);</t>
	<t>QEF: Quasi-Error-Free;</t>
	<t>QoE: Quality-of-Experience;</t>
	<t>QoS: Quality-of-Service;</t>
	<t>RTT: Round-Trip Time;</t>
	<t>SAT: SATellite; </t>
        <!--<t>EPC: Evolved Packet Core;</t>-->
        <t>SATCOM: generic synchronization)</dd>
        <dt>QEF:</dt><dd>Quasi-Error-Free</dd>
        <dt>QoE:</dt><dd>Quality of Experience</dd>
        <dt>QoS:</dt><dd>Quality of Service</dd>
        <dt>RTT:</dt><dd>Round-Trip Time</dd>
        <dt>SAT:</dt><dd>SATellite</dd>
        <dt>SATCOM:</dt><dd>Generic term related to all kinds of SATellite COMmunication systems;</t>
	<t>SPC: Single-Path Coding;</t>
	<t>VNF: Virtual SATellite-COMmunication systems</dd>
        <dt>SPC:</dt><dd>Single-Path Coding</dd>
        <dt>VNF:</dt><dd>Virtual Network Function - -- implementation of a network function using software.</t>
	</list></t>
	</section>

	<section anchor="sec:acknowledgements" title="Acknowledgements">
	<t>Many thanks to John Border, Stuart Card, Tomaso de Cola, Vincent Roca, Lloyd Wood and Marie-Jose Montpetit for their help in writing this document.</t> software.</dd>
      </dl>
    </section>
    <section anchor="sec:IANA" title="IANA Considerations"> anchor="sec_IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This memo includes document has no request to IANA.</t> IANA actions.</t>
    </section>
    <section anchor="sec:ecurity" title="Security Considerations"> anchor="sec_ecurity" numbered="true" toc="default">
      <name>Security Considerations</name>

      <t>Security considerations are inherent to any access network, and in particular SATCOM systems. Such as it is done in As with cellular networks, over-the-air data can be encrypted using e.g. using, e.g., the algorithms in <xref target="ETSITS2011"></xref>. target="ETSI-TS-2011" format="default"/>. Because the operator may not enable this <xref target="SSP-2020"></xref>, target="SSP-2020" format="default"/>, the applications should apply cryptographic protection. The use of FEC or Network Coding in SATCOM comes with risks (e.g., a single corrupted redundant packet may propagate to several flows when they are protected together in an Inter-Flow interflow coding approach, approach; see section <xref target="sec:use_cases"></xref>). target="sec_use_cases" format="default"/>). While this document does not further elaborate on this, the security considerations discussed in <xref target="RFC6363"></xref> target="RFC6363" format="default"/> apply.</t>
    </section>
  </middle>

	<!--  *****BACK MATTER ***** -->

	<back>
	<!-- References split into informative and normative -->
	<!-- There are 2 ways to insert reference entries from the citation libraries:
	1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
	2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
	(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
	Both are cited textually in the same manner: by using xref elements.
	If you use the PI option, xml2rfc will, by default, try to find included files in the same
	directory as the including file. You can also define the XML_LIBRARY environment variable
	with a value containing a set of directories to search.  These can be either in the local
	filing system or remote ones accessed by http (http://domain/dir/... ).-->

	<!-- <references title="Normative References">
		&RFC2119;
	</references> -->

	<references title="Informative References">
		<?rfc include="reference.RFC.1122.xml"?>
		<?rfc include="reference.RFC.3135.xml"?>
		<?rfc include="reference.RFC.4838.xml"?>
		<!-- <?rfc include="reference.RFC.5050.xml"?> -->
		<!-- <?rfc include="reference.RFC.5326.xml"?> -->
		<?rfc include="reference.RFC.5740.xml"?>
		<!-- <?rfc include="reference.RFC.5865.xml"?> -->
		<!-- <?rfc include="reference.RFC.6816.xml"?> -->
		<?rfc include="reference.RFC.6363.xml"?>
		<?rfc include="reference.RFC.6726.xml"?>
        	<!-- <?rfc include="reference.I-D.ietf-tcpm-converters"?> -->
		<?rfc include="reference.I-D.chin-nfvrg-cloud-5g-core-structure-yang.xml"?>
		<?rfc include="reference.I-D.irtf-nwcrg-coding-and-congestion.xml"?>
        	<?rfc include="reference.RFC.8406.xml"?>
        	<?rfc include="reference.RFC.8681.xml"?>
        	<?rfc include="reference.I-D.vazquez-nfvrg-netcod-function-virtualization.xml"?>
        	<!-- <?rfc include="reference.I-D.zinky-dtnrg-random-binary-fec-scheme.xml"?> -->
		<!-- <?rfc include="reference.I-D.zinky-dtnrg-erasure-coding-extension.xml"?> -->

<displayreference target="I-D.chin-nfvrg-cloud-5g-core-structure-yang" to="5G-CORE-YANG"/>
<displayreference target="I-D.irtf-nwcrg-coding-and-congestion" to="NWCRG-CODING"/>
<displayreference target="I-D.vazquez-nfvrg-netcod-function-virtualization" to="NETCOD-FUNCTION-VIRT"/>

	<references>
      <name>Informative References</name>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3135.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4838.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5740.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6363.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6726.xml"/>

      <xi:include
href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.chin-nfvrg-cloud-5g-core-structure-yang.xml"/>

      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-nwcrg-coding-and-congestion.xml"/>

      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8406.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8681.xml"/>

      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.vazquez-nfvrg-netcod-function-virtualization.xml"/>

<reference anchor="SSP-2020">
  <front>
    <title>A Tale of Sea and SkyOn Sky On the Security of Maritime VSAT Communications</title>
    <author initials="J" surname="Pavur (et al.)">
                    </author>
                    <date year="2020" surname="Pavur" />
    <author initials="D" surname="Moser" />
    <author initials="M" surname="Strohmeier" />
    <author initials="V" surname="Lenders" />
    <author initials="I" surname="Martinovic" />
    <date year="2020"/>
  </front>
                    <seriesInfo name="IEEE
  <refcontent>IEEE Symposium on Security and Privacy" value="10.1109/SP40000.2020.00056" /> Privacy</refcontent>
  <seriesInfo name="DOI" value="10.1109/SP40000.2020.00056"/>
</reference>

      <reference anchor="ETSITS2011"> anchor="ETSI-TS-2011">
        <front>
          <title>Digital Video Broadcasting (DVB);Content (DVB); Content Protection and Copy Management (DVB-CPCM);Part (DVB-CPCM); Part 5: CPCM Security Toolbox</title>
          <author initials="" surname="">
	    <organization>ETSI</organization>
                    </author>
          <date year="2011" /> month="February"/>
        </front>
        <seriesInfo name="ETSI TS" value="102 825-5" /> 825-5 V1.2.1"/>
      </reference>

      <reference anchor="ETSITR2017"> anchor="ETSI-TR-2017">
        <front>
          <title>Satellite Earth Stations and Systems (SES); Multi-link routing scheme in hybrid access network with heterogeneous links </title>
          <author initials="" surname="">
	    <organization>ETSI</organization>
                    </author>
          <date year="2017" /> month="July"/>
        </front>
        <seriesInfo name="ETSI TR" value="103 351" /> 351 V1.1.1"/>
      </reference>

      <reference anchor="ETSIEN2014"> anchor="ETSI-EN-2020">
        <front>
          <title> Digital Video Broadcasting (DVB); Second Generation DVB Interactive Satellite System (DVB-RCS2); Part 2: Lower Layers for Satellite standard </title> standard</title>
          <author initials="" surname="">
	    <organization>ETSI</organization>
			</author>
          <date year="2014" /> year="2020" month="July"/>
        </front>
        <seriesInfo name="ETSI EN" value="301 545-2" /> 545-2 V1.3.1"/>
      </reference>

      <reference anchor="SHINE"> anchor="SHINE" target="https://ieeexplore.ieee.org/document/8530996">
        <front>
                    <title>Secure
          <title>SHINE: Secure Hybrid In Network caching Environment (SHINE) ESA project</title>
</title>
          <author initials="S" surname="Pietro Romano">
		    </author> initials="S." surname="Romano" />
          <author initials="et" surname="al.">
		    </author>
                    <date year="2017 on-going" initials="C." surname="Roseti" />
          <author initials="A" surname="Tulino" />
          <date month="June" year="2018"></date>
        </front>
<refcontent>International Symposium on Networks, Computers and Communications (ISNCC)</refcontent>

<seriesInfo name="ESA project" value="" name='DOI' value='10.1109/ISNCC.2018.8530996' />
      </reference>

      <reference anchor="ASMS2010">
        <front>
          <title>Demonstration at opening session of ASMS 2010</title>
          <author initials="T" surname="De Cola">
		    </author>
                    <author initials="et" surname="al.">
		    </author>
                    <date year="2010" />
          <date year="2010"/>
        </front>
                    <seriesInfo name="Advanced
        <refcontent>5th Advanced Satellite Multimedia Systems (ASMS) Conference" value="" /> Conference</refcontent>
      </reference>

                <!-- <reference anchor="IEEEVT2001">
                    <front>
                    <title>Statistical modeling of the LMS channel</title>
                    <author initials="F.P" surname="Fontan">
                    </author>
                    <author initials="M" surname="Vazquez-Castro">
                    </author>
                    <author initials="C.E" surname="Cabado">
                    </author>
                    <author initials="J.P" surname="Garcia">
                    </author>
                    <author initials="E" surname="Kubista">
                    </author>
                    <date year="2001" />
                    </front>
                    <seriesInfo name="BEER Transactions on Vehicular Technology" value="vol. 50 issue 6" />
                </reference> -->

<reference anchor="CCSDS-131.5-O-1">
        <front>
          <title>Erasure correcting codes Correcting Codes for use Use in near-earth Near-Earth and deep-space communications</title>
                    <author surname="CCSDS"> Deep-Space Communications</title>
          <author>
	    <organization>The Consultative Committee for Space Data Systems
	    </organization>
                    </author>
          <date year="2014" /> month="November"/>
        </front>
        <seriesInfo name="CCSDS Experimental specification" value="131.5-0-1" /> name="Experimental Specification CCSDS" value="131.5-0-1"/>
      </reference>

      <reference anchor="SAT2017">
        <front>
          <title>Software-defined satellite cloud RAN</title>
          <author initials="T" surname="Ahmed">
                    </author>
          <author initials="E" surname="Dubois">
                    </author>
          <author initials="JB" surname="Dupe"> surname="Dup&#233;">
                    </author>
          <author initials="R" surname="Ferrus"> surname="Ferr&#250;s">
                    </author>
          <author initials="P" surname="Gelard"> surname="G&#233;lard">
                    </author>
          <author initials="N" surname="Kuhn">
                    </author>
          <date year="2017" /> month="February" day="2"/>
        </front>
                    <seriesInfo name="International
        <refcontent>International Journal on Satellite Communnications and Networking" value="vol. 36 - https://doi.org/10.1002/sat.1206" />
                </reference>
                <!-- <reference anchor="WANG05">
		    <front>
		    <title>Erasure-coding based routing for opportunistic networks</title>
		    <author initials="Y" surname="Wang">
		    </author>
                    <author initials="et" surname="al.">
		    </author>
                    <date year="2005" />
                    </front>
                    <seriesInfo name="Proceedings of the ACM SIGCOMM workshop on Delay-tolerant networking" value=""/>
                </reference> -->
                <!-- <reference anchor="ZHANG06">
		    <front>
		    <title>On the benefits of random linear coding for unicast applications in disruption tolerant networks</title>
		    <author initials="X" surname="Zhang">
		    </author>
                    <author initials="et" surname="al.">
		    </author>
                    <date year="2006" />
                    </front>
                    <seriesInfo name="Proceedings of the 4th International Symposium on Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks" value=""/>
                </reference>
                -->
		<!-- <reference anchor="TOURNOUX10">
		    <front>
		    <title>On the benefits of random linear coding for unicast applications in disruption tolerant networks</title>
		    <author initials="P" surname="Tournoux">
		    </author>
                    <author initials="E" surname="Lochin">
		    </author>
                    <author initials="J" surname="Leguay">
		    </author>
                    <author initials="J" surname="Lacan">
		    </author>
                    <date year="2010" />
                    </front>
                    <seriesInfo name="Proceedings of the IEEE International Conference on Communications" value=""/>
                </reference> -->
                <!-- <reference anchor="COLA11">
                    <front>
		    <title>Reliability options for data communications in the future deep-space missions</title>
                    <author initials="T" surname="De Cola">
                    </author>
                    <author initials="E" surname="Paolini">
                    </author>
                    <author initials="G" surname="Liva">
                    </author>
                    <author initials="G" surname="Calzolari">
                    </author>
                    <date year="2011" />
                    </front>
                    <seriesInfo name="Proceedings of the IEEE" value="vol. 99 issue 11"/>
                </reference> -->
                <!-- <reference anchor="CCSDS-FDP">
                    <front>
                    <title>CCSDS File Delivery Protocol, Recommendation for Space Data System Standards</title>
                    <author initials="" surname="">
                    </author>
                    <date year="2007" />
                    </front>
                    <seriesInfo name="CCSDS 727.0-B-4, Blue Book" value="num. 3" />
                </reference> -->
                <!-- <reference anchor="LACAN08">
                     <front>
                     <title>Rethinking reliability for long-delay networks</title>
                     <author initials="J." surname="Lacan">
                     </author>
                     <author initials="E." surname="Lochin">
                     </author>
                     <date month="October" year="2008"/>
                     </front>
                     <seriesInfo name="International Workshop on Satellite Communications and Space Communications" value=""/>
        	</reference> -->
                <!-- <reference anchor="SUNDARARAJAN08">
                     <front>
                     <title>ARQ for network coding</title>
                     <author initials="J." surname="Sundararajan">
                     </author>
                     <author initials="D." surname="Shah">
                     </author>
                     <author initials="M." surname="Medard">
                     </author>
                     <date month="July" year="2008"/>
                     </front> Networking, Vol. 36</refcontent>
	<seriesInfo name="IEEE Int. Symp. on Information Theory" value=""/> name="DOI" value="10.1002/sat.1206"/>
      </reference> -->

		<!-- <reference anchor="TOURNOUX11">
                     <front>
                     <title>On-the-fly erasure coding for real-time video applications</title>
		     <author initials="P" surname="Tournoux">
                     </author>
                     <author initials="E." surname="Lochin">
                     </author>
                     <author initials="J." surname="Lacan">
                     </author>
                     <author initials="A." surname="Bouabdallah">
                     </author>
                     <author initials="V." surname="Roca">
                     </author>
                     <date month="August" year="2011"/>
                     </front>
                     <seriesInfo name="IEEE Trans. on Multimedia" value="vol. 13 issue 4"/>
        	</reference> -->

                <reference anchor="THAI15">
        <front>
          <title>Enabling E2E reliable communications with adaptive re-encoding over delay tolerant networks</title> Delay Tolerant Networks</title>
          <author initials="T" surname="Thai">
                     </author>
          <author initials="V." surname="Chaganti">
                     </author>
          <author initials="E." surname="Lochin">
                     </author>
          <author initials="J." surname="Lacan">
                     </author>
          <author initials="E." surname="Dubois">
                     </author>
          <author initials="P." surname="Gelard">
                     </author>
          <date month="June" year="2015"/>
        </front>
                     <seriesInfo name="Proceedings of the IEEE
	<refcontent>IEEE International Conference on Communications" value="http://dx.doi.org/10.1109/ICC.2015.7248441"/> Communications</refcontent>
	<seriesInfo name="DOI" value="10.1109/ICC.2015.7248441"/>
      </reference>
    </references>
    <section anchor="sec_acknowledgements" numbered="false" toc="default">

      <name>Acknowledgements</name>
      <t>Many thanks to <contact fullname="John Border"/>, <contact fullname="Stuart Card"/>, <contact fullname="Tomaso de Cola"/>, <contact fullname="Marie-Jose Montpetit"/>, <contact fullname="Vincent Roca"/>, and <contact fullname="Lloyd Wood"/> for their help in writing this document.</t>
    </section>

  </back>
</rfc>