-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-irtf-nwcrg-network-coding-satellites-06.xml
702 lines (620 loc) · 46.7 KB
/
draft-irtf-nwcrg-network-coding-satellites-06.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
<?xml version="1.0" encoding="US-ASCII"?>
<!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" ?>
<rfc
category="info"
docName="draft-irtf-nwcrg-network-coding-satellites-06"
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)" -->
<!-- ***** FRONT MATTER ***** -->
<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="Coding techniques for satellite systems">Coding techniques for satellite systems</title>
<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>
<code>31400</code>
<country>France</country>
</postal>
<phone></phone>
<email>[email protected]</email>
</address>
</author>
<author role="editor" fullname="Emmanuel Lochin" initials="E" surname="Lochin">
<organization>ISAE-SUPAERO</organization>
<address>
<postal>
<street>10 Avenue Edouard Belin</street>
<city>Toulouse</city>
<region></region>
<code>31400</code>
<country>France</country>
</postal>
<phone></phone>
<email>[email protected]</email>
</address>
</author>
<date month="August" year="2019" />
<!-- 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>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine 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 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 the product of the Coding for Efficient Network Communications Research Group (NWCRG). This document follows the taxonomy document <xref target="RFC8406"> </xref> and considers coding as a linear combination of packets that operate in and above the network layer. In this context, this memo details a multi-gateway satellite system to identify use-cases where coding is relevant. As example, coding operating in and above the network layer can be exploited to cope with residual losses or provide reliable multicast services. The objective is to contribute to a larger deployment of such techniques in SATCOM systems. This memo also identifies open research issues related to the deployment of coding in SATCOM systems, such as the interaction between congestion controls and coding techniques.</t>
</abstract>
</front>
<middle>
<section anchor="sec:introduction" title="Introduction">
<t>Guaranteeing both physical-layer robustness and efficient usage of the radio resource has been in the core design of SATellite COMmunication (SATCOM) systems. The trade-off often resided in how much redundancy a system adds to cope with link impairments, without reducing the goodput when the channel quality is good. There is usually enough redundancy to guarantee a Quasi-Error Free transmission. The recovery time depends on the encoding block size. Considering for instance geostationary satellite system (GEO), physical or link layer erasure coding mechanisms recover transmission losses within a negligible delay compared to link delay. However, when retransmissions are triggered, this leads to a non-negligible additional delay in particular over GEO link. Further exploiting coding techniques at application or transport layers is an opportunity for releasing constraints on the physical layer and improving the performance of SATCOM systems.</t>
<t>The notations used in this document are based on the taxonomy document <xref target="RFC8406"> </xref>:<list style="symbols">
<t>Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document.</t>
<t>FEC (also called Application-Level FEC) operates in and above the network layer.</t>
<t>This document considers coding (or coding techniques or coding schemes) as a linear combination and not as a content coding (e.g., to compress a video flow).</t>
</list></t>
<t><xref target="fig:existing_network"></xref> presents the status of the reliability schemes deployment in satellite systems.<list style="symbols">
<t>X1 embodies the source coding techniques that could be used at application level for instance within QUIC. This is not specific to SATCOM systems since such deployment can be relevant for broadband Internet access discussions.</t>
<t>X2 embodies the physical-layer techniques exploited in SATCOM systems (note that other coding techniques can be exploited). This is out of the scope of the document.</t>
</list></t>
<figure anchor="fig:existing_network" title="Reliability schemes in current satellite systems">
<artwork>
+------+-------+---------+---------------+-------+
| | Upper | Middle | Communication layers |
| | Appl. | ware | |
+ +-------+---------+---------------+-------+
| |Source | Network | Packetization | PHY |
| |coding | AL-FEC | UDP/IP | layer |
+------+-------+---------+---------------+-------+
|E2E | X1 | | | |
|NC | | | | |
|IntraF| X1 | | | |
|InterF| | | | X2 |
|SPC | X1 | | | X2 |
|MPC | | | | |
+------+-------+---------+---------------+-------+
</artwork>
</figure>
<t>We notice an active research activity on coding techniques and SATCOM. That being said, not much has actually made it to industrial developments. In this context, this document aims at identifying opportunities for further usage of coding in these systems.</t>
<!-- <t>Reliability is an inherent part of the physical-layer and usually achieved by using coding techniques. Based 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 of a SATCOM system (e.g. considering a more efficient usage of the satellite resource, delivery delay, delivery ratio).</t> -->
<t>The glossary of this memo extends the glossary of the taxonomy document <xref target="RFC8406"> </xref> as follows:<list style="symbols">
<t>ACM : Adaptive Coding and Modulation;</t>
<t>BBFRAME: Base-Band FRAME - satellite communication layer 2 encapsulation work as follows: (1) each 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 (4) BBFRAMEs are forwarded to the physical-layer;</t>
<t>CPE: Customer Premises Equipment;</t>
<t>COM: COMmunication;</t>
<t>DSL: Digital Subscriber Line;</t>
<t>DTN: Delay/Disruption Tolerant Network;</t>
<t>DVB: Digital Video Broadcasting;</t>
<t>E2E: End-to-end;</t>
<t>ETSI: European Telecommunications Standards Institute;</t>
<t>FEC: Forward Error Correction;</t>
<t>FLUTE: File Delivery over Unidirectional Transport;</t>
<t>IntraF: Intra-Flow Coding;</t>
<t>InterF: Inter-Flow Coding;</t>
<t>IoT: Internet of Things;</t>
<t>LTE: Long Term Evolution;</t>
<t>MPC: Multi-Path Coding;</t>
<t>NC: Network Coding;</t>
<t>NFV: Network Function Virtualization;</t>
<t>NORM: NACK-Oriented Reliable Multicast;</t>
<t>PEP: Performance Enhancing Proxy <xref target="RFC3135"></xref> - a typical PEP for satellite communications include compression, caching and TCP acceleration;</t>
<t>PLFRAME: 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>SAT: SATellite; </t>
<!--<t>EPC: Evolved Packet Core;</t>-->
<t>SATCOM: generic term related to all kind of SATellite COMmunication systems;</t>
<t>SPC: Single-Path Coding;</t>
<t>VNF: Virtual Network Function.</t>
</list></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 2119</xref>.</t>
</section> -->
<t>This document is the product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard.</t>
</section>
<!-- ######################################################-->
<!-- ######################################################-->
<!-- Body of the document -->
<!-- ######################################################-->
<!-- ######################################################-->
<!-- ######################################################-->
<!-- New section -->
<!-- ######################################################-->
<section anchor="sec:sat_topo" title="A note on satellite topology">
<t>This section describes a satellite system that follows the ETSI DVB standards to provide broadband Internet access. A high-level description of a multi-gateway satellite network is provided. There are multiple SATCOM systems, such as those dedicated to broadcasting TV or to IoT applications: depending on the purpose of the SATCOM system, ground segments are specific. In this context, the increase of the available capacity that is carried out to end users and reliability requirements lead to multiple gateways for one unique satellite platform.</t>
<t>In this context, <xref target="fig:sat_gateway"></xref> shows an example of a multi-gateway satellite system. In a multi-gateway system, some elements may be centralized and/or gathered: the relevance of one approach compared to another depends on the deployment scenario. More information on these discussions and a generic SATCOM ground segment architecture for bidirectional Internet access can be found in <xref target="SAT2017"></xref>.</t>
<t>Some functional blocks aggregate the traffic of multiple users.</t>
<figure anchor="fig:sat_gateway" title="Data plane functions in a generic satellite multi-gateway system">
<artwork>
+--------------------------+
| application servers |
| (data, coding, multicast |
+--------------------------+
^ ^
| ... |
-----------------------------------
v v v v v v
+------------------+ +------------------+
| network function | | network function |
| (firewall, PEP) | | (firewall, PEP) |
+------------------+ +------------------+
^ ^ ^ ^
| ... | IP packets | ... |
v v v v ---
+------------------+ +------------------+ |
| access gateway | | access gateway | |
+------------------+ +------------------+ |
^ ^ |
| BBFRAME | | gateway
v v |
+------------------+ +------------------+ |
| physical gateway | | physical gateway | |
+------------------+ +------------------+ |
^ ^ ---
| PLFRAME |
v v
+------------------+ +------------------+
| outdoor unit | | outdoor unit |
+------------------+ +------------------+
^ ^
| satellite link |
v v
+------------------+ +------------------+
| sat terminals | | sat terminals |
+------------------+ +------------------+
^ ^ ^ ^
| | | |
v | v |
+----------+ | +----------+ |
| end user | | | end user | |
+----------+ v +----------+ v
+------------------+ +------------------+
| end user | | end user |
+------------------+ +------------------+
</artwork>
</figure>
</section>
<!-- ######################################################-->
<!-- New section -->
<!-- ######################################################-->
<section anchor="sec:use_cases" title="Use-cases for improving the SATCOM system performance with coding techniques">
<t>This section details use-cases where coding techniques could provide interesting features for SATCOM systems. Combination of the presented use-cases could also be relevant.</t>
<t>It is worth noting that these use-cases mostly focus on the middleware and packetization UDP/IP of <xref target="fig:existing_network"></xref>. There are already lots of recovery mechanisms at the physical-layer in currently deployed systems while E2E source coding is done at the application level. In a multi-gateway SATCOM Internet access, the deployment opportunities are more relevant in specific SATCOM components such as the "network function" block or the "access gateway" of <xref target="fig:sat_gateway"></xref>.</t>
<section anchor="subsec:two-way" title="Two-way relay channel mode">
<t>This use-case considers a two-way communication between end users, through a satellite link. <xref target="fig:two_way"></xref> proposes an illustration of this scenario.</t>
<t>Satellite terminal A sends a flow A and satellite terminal B sends a flow B to a coding server. The coding server sends a combination of both terminal flows. This results in non-negligible capacity savings and has been demonstrated <xref target="ASMS2010"></xref>. In the proposed example, a dedicated coding server is introduced. Its location could be changed depending on the deployment use-case. With On-Board Processing satellite payloads, the coding operations could be done at the satellite level; although this would require lots of computational ressource on-board and may not be relevant with today's payloads.</t>
<figure anchor="fig:two_way" title="Network architecture for two way relay channel with NC">
<artwork>
-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>
</figure>
</section>
<section anchor="subsec:rel-mul" title="Reliable multicast">
<t>Using multicast servers is a way to better exploit the satellite broadcast capabilities. This approach is proposed in the SHINE ESA project <xref target="I-D.vazquez-nfvrg-netcod-function-virtualization"> </xref> <xref target="SHINE"> </xref>. This use-case considers adding redundancy to a multicast flow depending on what has been received by different end-users, resulting in non-negligible scarce resource saving. We propose an illustration for this scenario in <xref target="fig:rel_multi"></xref>.</t>
<figure anchor="fig:rel_multi" title="Network architecture for a reliable multicast with NC">
<artwork>
-Li}- : packet indicating the loss of packet i of a multicast flow M
={M== : multicast flow including the missing packets
+-----------+ +-----+
|Sat term A |-Li}-+ | |
+-----------+ | | | +---------+ +------+
^^ +-| |-Li}--| | |Multi |
|| | SAT |-Lj}--| Gateway |--|Cast |
===={M==========| |={M===| | |Server|
|| | | +---------+ +------+
vv +-| |
+-----------+ | | |
|Sat term B |-Lj}-+ | |
+-----------+ +-----+
</artwork>
</figure>
<t>A multicast flow (M) is forwarded to both satellite terminals A and B. However packet Ni (resp. Nj) gets lost at terminal A (resp. B), and terminal A (resp. B) returns a negative acknowledgment Li (resp. Lj), indicating that the packet is missing. Then either the access gateway or the multicast server includes 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 be achieved by using other multicast or broadcast systems, such as NACK-Oriented Reliable Multicast (NORM) <xref target="RFC5740"></xref> or File Delivery over Unidirectional Transport (FLUTE) <xref target ="RFC6726"></xref>. Note that both NORM and FLUTE are limited to block coding, none of them supporting sliding window encoding schemes <xref target="RFC8406"></xref>. Note that although FLUTE is defined as an unidirectional protocol, the RFC proposes a bidirectional communication method to enable full reliability transfer and for security purposes.</t>
</section>
<section anchor="subsec:hybrid" title="Hybrid access">
<t>This use-case considers the use of multiple path management with coding at the transport layer to increase the reliability and/or the total capacity (using multiple paths does not guarantee an improvement of both the reliability and the total capacity). We propose an illustration for this scenario in <xref target="fig:hyb_access"></xref>. This use-case is inspired from the Broadband Access via Integrated Terrestrial Satellite Systems (BATS) project and has been published as an ETSI Technical Report <xref target="ETSITR2017"></xref>. This kind of architecture is also discussed in the TCPM working group <xref target="I-D.ietf-tcpm-converters"></xref>.</t>
<t>To cope with packet loss (due to either end-user mobility or physical-layer impairments), coding techniques could be introduced both at the CPE and at the concentrator. Apart from packet losses, other gains could be envisioned, such as a better tolerance to out-of-order packets which occur when exploited links exhibit high asymetry in terms of RTT. Depending on the ground architecture <xref target="I-D.chin-nfvrg-cloud-5g-core-structure-yang"></xref> <xref target="SAT2017"></xref>, some equipments might be hosting both SATCOM and cellular functions.</t>
<figure anchor="fig:hyb_access" title="Network architecture for an hybrid access using coding">
<artwork>
-{}- : bidirectional link
+-----+ +----------------+
+-{}-| SAT |-{}-| BACKBONE |
+------+ +------+ | +-----+ | +------------+ |
| End |-{}-| CPE |-{}-| | |CONCENTRATOR| |
| User | | | | +-----+ | +------------+ | +------------+
+------+ +------+ |-{}-| DSL |-{}-| |-{}-|Application |
| +-----+ | | |Server |
| | | +------------+
| +-----+ | |
+-{}-| LTE |-{}-| |
+-----+ +----------------+
</artwork>
</figure>
</section>
<section anchor="subsec:varying_wifi" title="Dealing with LAN losses">
<t>This use-case considers the usage of coding techniques to cope with cases where the end user connects to the satellite terminal with a Wi-Fi link that exhibits losses. In the case of encrypted end-to-end applications based on UDP, PEP cannot operate. The Wi-Fi losses result in an end-to-end retransmission that would harm the quality of experience of the end user.</t>
<t>The architecture is recalled in <xref target="fig:varying_wifi-loss"></xref>.</t>
<t>In this use-case, adding coding techniques could prevent the end-to-end retransmission from occuring.</t>
<figure anchor="fig:varying_wifi-loss" title="Network architecture for dealing with LAN losses">
<artwork>
-{}- : bidirectional link
-''- : Wi-Fi link
C : where coding techniques could be introduced
+---------+ +---------+ +---+ +--------+ +-------+ +--------+
| | |Satellite| |SAT| |Physical| |Access | |Network |
|End user |-''-|Terminal |-{}-| |-{}-|Gateway |-{}-|Gateway|-{}-|Function|
+---------+ +---------+ +---+ +--------+ +-------+ +--------+
C C C C
</artwork>
</figure>
</section>
<section anchor="subsec:varying" title="Dealing with varying channel conditions">
<t>This use-case considers the usage of coding techniques to cope with cases where channel condition can change in less than a second and where the physical-layer codes could not efficiently guarantee a Quasi-Error-Free (QEF) transmission.</t>
<t>The architecture is recalled in <xref target="fig:varying_capa"></xref>. In these cases, the mechanisms that are exploited to adapt the physical-layer codes (Adaptative Coding and Modulation (ACM)) may adapt the modulation and coding in time: remaining errors could be recovered with higher layer redundancy packets. Coding may be applied on IP packets or on layer-2 proprietary format packets.</t>
<t>This use-case is mostly relevant when mobile users are considered or when the chosen band induces a required physical-layer coding that may change over time (Q/V bands, Ka band, etc.). Depending on the use-case (e.g., very high frequency bands, mobile users) or depending on the deployment use-cases (e.g., performance of the network between each individual block), the relevance of adding coding techniques is different.</t>
<figure anchor="fig:varying_capa" title="Network architecture for dealing with varying link characteristics">
<artwork>
-{}- : bidirectional link
C : where coding techniques could be introduced
+---------+ +---+ +--------+ +-------+ +--------+
|Satellite| |SAT| |Physical| |Access | |Network |
|Terminal |-{}-| |-{}-|Gateway |-{}-|Gateway|-{}-|Function|
+---------+ +---+ +--------+ +-------+ +--------+
C C C C
</artwork>
</figure>
</section>
<section anchor="subsec:gat_hand" title="Improving the gateway handovers">
<t>This use-case considers the recovery of packets that may be lost during gateway handovers. Whether this is for off-loading one given equipment or because the transmission quality is not the same on each gateway, changing the transmission gateway may be relevant. However, if gateways are not properly synchronized or if the algorithm that is exploited to trigger gateway handovers shows a non negligible probability of missed detection, this may result in packet losses. During these critical phases, coding can be added to improve the reliability of the transmission and allow a seamless gateway handover. Coding could be applied at either the access gateway or the network function block. A potential control plane is in charge of taking the decision to change the communication gateway and the consequent routes.</t>
<t><xref target="fig:gat_hand"></xref> illustrates this use-case.</t>
<figure anchor="fig:gat_hand" title="Network architecture for dealing with gateway handover schemes">
<artwork>
-{}- : bidirectional link
! : management interface
C : where coding techniques could be introduced
C C
+--------+ +-------+ +--------+
|Physical| |Access | |Network |
+-{}-|gateway |-{}-|gateway|-{}-|function|
| +--------+ +-------+ +--------+
| ! !
+---------+ +---+ +---------------+
|Satellite| |SAT| | Control plane |
|Terminal |-{}-| | | manager |
+---------+ +---+ +---------------+
| ! !
| +--------+ +-------+ +--------+
+-{}-|Physical|-{}-|Access |-{}-|Network |
|gateway | |gateway| |function|
+--------+ +-------+ +--------+
C C
</artwork>
</figure>
</section>
</section>
<!-- ######################################################-->
<!-- New section -->
<!-- ######################################################-->
<section anchor="sec:deploy" title="Research challenges">
<t>This section proposes a few potential approaches to introduce and use coding techniques in SATCOM systems.</t>
<section anchor="sec:deploy_pep" title="On the joint-use of coding techniques and congestion control in SATCOM systems">
<t>SATCOM systems typically feature Performance Enhancement Proxy (PEP) <xref target="RFC3135">RFC 3135</xref>. PEP usually split TCP end-to-end connections and forward TCP packets to the satellite baseband gateway that deals with layer-2 and layer-1 encapsulations. PEP contributes to mitigate congestion in a SATCOM systems. PEP could host coding mechanisms and thus support use-cases that have been discussed in this document.</t>
<t>Deploying coding schemes at the TCP level in these equipment could be relevant and independent from the specific characteristics of a SATCOM link. This leads to research questions on the interaction between coding schemes and TCP congestion controls.</t>
</section>
<section anchor="sec:deploy_coding" title="On the efficient usage of satellite resource">
<t>The recurrent trade-off in SATCOM systems remains: how much overhead from redundant reliability packets can be introduced to guarantee a better end-user QoE while optimizing capacity usage ? At which layer this supplementary coding could be added ?</t>
<t>This problem has been tackled in the past for physical-layer code, but there remains questions on how to adapt the overhead for, e.g., the quickly varying channel conditions use-case.</t>
</section>
<section anchor="sec:deploy_nfv" title="Interaction with virtualized satellite gateways and terminals">
<t>Related to the foreseen virtualized network infrastructure, coding techniques could be easily deployed as VNF. Next generation of SATCOM ground segments could rely on a virtualized environment. This trend can also be seen in cellular networks, making these discussions extendable to other deployment scenarios <xref target="I-D.chin-nfvrg-cloud-5g-core-structure-yang"> </xref>. As one example, the coding VNF deployment in a virtualized environment is presented in <xref target="I-D.vazquez-nfvrg-netcod-function-virtualization"> </xref>.</t>
<t>A research challenge would be the optimization of the NFV service function chaining, considering a virtualized infrastructure and other SATCOM specific functions, to guarantee efficient radio usage and easy-to-deploy SATCOM services. Moreover, another challenge related to a virtualized SATCOM equipment is the management of limited buffered capacities.</t>
</section>
<section anchor="subsec:dtn" title="Delay/Disruption Tolerant Networks">
<!-- <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 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> -->
<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 long delay and frequent link disruptions; indeed, contemporaneous E2E connectivity may be available only intermittently or never. 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. Moreover, DTN can also be seen as an alternative solution to transfer the data between a central PEP and a remote PEP.</t>
<t>Coding enables E2E reliable communication over DTN with adaptive re-encoding, as proposed in <xref target="THAI15"></xref>. In this case, the use-cases proposed in <xref target="subsec:varying"></xref> would legitimize the usage of coding within the DTN stack to improve the channel utilization and the E2E transmission delay. In this context, the use of 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>. A research challenge would be on how such 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 discuses some opportunities to introduce coding techniques at a wider scale in satellite telecommunications systems.</t>
<t>Even though this document focuses on satellite systems, it is worth pointing out that some scenarios proposed may be relevant to other wireless telecommunication systems. As one example, the generic architecture proposed in <xref target="fig:sat_gateway"></xref> may be mapped to 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 draft since they may be also relevant for cellular networks.</t>
</section>
<!-- ######################################################-->
<!-- ######################################################-->
<!-- Tail of the document -->
<!-- ######################################################-->
<!-- ######################################################-->
<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>
</section>
<section anchor="sec:IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="sec:ecurity" title="Security Considerations">
<t>Security considerations are inherent to any access network, and in particular SATCOM systems. The use of FEC or Network Coding in SATCOM also comes with risks (e.g., a single corrupted redundant packet may propagate to several flows when they are protected together in an Inter-Flow coding approach, see section <xref target="sec:use_cases"></xref>). However this is not specific to the SATCOM use-case and this document does not further elaborate on it.</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.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.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.RFC.8406.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"?> -->
<reference anchor="ETSITR2017">
<front>
<title>Satellite Earth Stations and Systems (SES); Multi-link routing scheme in hybrid access network with heterogeneous links </title>
<author initials="" surname="">
</author>
<date year="2017" />
</front>
<seriesInfo name="ETSI TR" value="103 351" />
</reference>
<reference anchor="SHINE">
<front>
<title>Secure Hybrid In Network caching Environment (SHINE) ESA project</title>
<author initials="S" surname="Pietro Romano">
</author>
<author initials="et" surname="al.">
</author>
<date year="2017 on-going" />
</front>
<seriesInfo name="ESA project" value="" />
</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" />
</front>
<seriesInfo name="ASMS" value="" />
</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 for use in near-earth and deep-space communications</title>
<author surname="CCSDS">
</author>
<date year="2014" />
</front>
<seriesInfo name="CCSDS Experimental specification" 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">
</author>
<author initials="R" surname="Ferrus">
</author>
<author initials="P" surname="Gelard">
</author>
<author initials="N" surname="Kuhn">
</author>
<date year="2017" />
</front>
<seriesInfo name="Int. J. Satell. Commun. Network." value="vol. 36" />
</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 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>
<seriesInfo name="IEEE Int. Symp. on Information Theory" value=""/>
</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>
<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 International Conference on Communications" value=""/>
</reference>
</references>
</back>
</rfc>