Gestion multicouches de la fiabilit pour multicast sur satellite

1
Gestion multi-couches de la fiabilité pour
multicast sur satellite
2
Plan de la présentation

• Problématique
• Encapsulation et fiabilité dans IP / DVB
• Multi Protocol Header Protection (MPHP) et
  MPE-lite
• Mise en uvre
• Applications à fiabilité partielle
• Applications à fiabilisation totale mécanismes
  de transport
• Conclusion

3
Problématique générale

• Le satellite GEO
• Canal de transmission peu fiable
• BER variable 10-7 à 10-2
• Transmission coûteuse
• Normes DVB
• Multicast fiable sur satellite
• Mise à léchelle
• Gestion de la fiabilité au niveau transport ?
• FEC ou FEC / ARQ
• gtApproches envisagées
• Rentabiliser le coût de transmission
• Diminuer la quantité de données transmises
• Exploiter tout le potentiel des FEC
• Faire face à nimporte quelle distribution
  derreurs

4
Architecture réseau de référence
Gateway / IP encapsulator
VSATs / IP routers
Content Server
Any IP Network
LAN
Public Internet
User Terminal
5
Encapsulation IP / DVB
Datagramme IP
20
0-MTU
Section MPE (Trame ULE)
12 (4)
4
MPE payload
Paquets MPEG-2 TS
183
184
184
4
4
4
P
184
4
En-tête MPEG-2 TS
Sync byte
Error PUSI Priority
PID
Scramb.
AFC
Cont.
AF
8b
3b
13b
2b
2b
4b
6
Position du problème
Transport
IP
MPE ULE
MPEG-2 TS

• MPEG-2 TS et MPE(ULE) assurent lintégrité de
  leurs unités de données
• Sinon, rejet des paquets à la réception
• Supprimer les paquets erronés augmente le taux
  derreur effectif de la liaison
• Surtout pour des longs paquets (max 1500
  octets)
• Dans le cas contraire, possibilité de traitement
  den-tête erronés
• Problèmes multiples (adresse, délimitation de
  trames,) non désirables
• Alors ???

7
MPE-lite (1)
Transport
IP
MPE ULE
MPEG-2 TS

• On retire la fiabilité sur les données charge
  utiles
• MPE-lite
• On modifie le CRC, seule len-tête MPE (ULE)
  restant protégée
• La corruption de len-tête fait supprimer le
  paquet
• Oui mais
• MPEG-2 TS doit supporter ce mode de livraison
• Possible daprès les normes
• Jamais implémenté pour le transport de données
• Si len-tête est corrompue ?
• Problème de mise en uvre
• Lapproche est-elle réellement intéressante ?

8
MPE-lite (2)
Transport
IP
MPE-Lite
MPEG-2 TS

• Au moins 36 (resp. 28) octets sensibles, avec
  IP/MPE (IP/ULE)
• En cas derreurs importantes, un grand nombre de
  paquets MPE-lite sont rejetés

9
MPHP
Transport
MPHP
IP
MPE ULE
MPEG-2 TS

• MPHP Multi Protection Header Protocol
• Principe on intègre un code FEC puissant afin
  de protéger spécifiquement les en-têtes
• Mécanisme au-dessus de MPEG-2 TS
• Protège au moins les en-têtes de MPE-lite et IP,
  et loctet P
• Autre protection possible (ex en-tête UDP)
• Code Reed-Solomon (MDS)
• Taux de code 1/3
• Points forts
• Seuls quelques de paquets sont rejetés
• Adapté aux grands paquets
• Faiblesses
• Gourmand en bande passante
• Mise en uvre ?

10
Mise en uvre (1)
Transport
MPHP
IP
MPE ULE
MPEG-2 TS

• Assez difficile avec MPE, plus réaliste avec ULE
• Car Adaptation Field ny est jamais utilisé
• Seuls les champs PUSI et Continuity sont à
  protéger
• PUSI indique une nouvelle section dans le
  paquet
• Continuity doit être incrémenté (réassemblage)
• Corruption du PID en
• PID inexistant
• paquet rejeté lors de la consultation de la table
• PID réservé pour la signalisation DVB/MPEG-2
• paquet rejeté car messages protégés par des CRC
• Autre PID
• Video MPEG-2 dégradation temporaire de la
  qualité
• IP Unicast/Multicast (sans MPHP) paquet rejeté
  par MPE
• IP Multicast (avec MPHP) paquet supprimé (au
  niveau du transport), et perte du prochain paquet
  IP associé au PID modifié

11
Mise en uvre (2)
Transport
MPHP
IP
MPE ULE
MPEG-2 TS

• Mise en uvre dun code détecteur portant sur les
  5 bits sensibles
• Met à profit 4 bits (ex Error / Pri / AFC)
  inutilisés dans DVB
• Code de Hamming raccourci 9, 5, 3 construit sur
  le code
• 15, 11, 3
• BER de 5.10-2 en entrée, probabilité de
  non-détection est de 5.10-4
• Pourrait être associé à lexploitation des
  informations de confiance
• Quand un paquet MPEG-2 est perdu, le mécanisme
  doit reconstituer 184 octets
• Effectué à la réception du prochain paquet MPEG-2
  (même PID)
• Suivant la valeur du compteur de continuité
• Conservation de la longueur de la section

12
Mise en uvre (3) MPHP
Transport
MPHP
IP
MPE ULE
MPEG-2 TS

• Traitement par puce spécialisée
• Vitesse élevée de codage/décodage (gtgt100 Mb/s)
• Doît être paramétrable (selon la taille des
  paquets)
• MPHP nest appliqué que si
• Le PID associé à un flux multicast donné est
  reconnu
• Les conditions de propagation se dégradent
• 2 possibilités de codage
• Code RS 3k, k, 2k raccourci
• k nombre doctets den-tête à protéger contenus
  dans chaque section
• Facile à mettre en uvre
• Code RS 255, 85, 170
• Nécessite une mise en mémoire tampon
• Besoin de mémoire 4 paquets, soit 6 ko max.
• Délai pour le décodage
• Meilleure résistance aux erreurs groupées

13
Applications à fiabilité partielle
UDP-Lite
MPHP
IP
MPE Lite
MPEG-2 TS

• Applications à contraintes temporelles
• Retransmissions inutiles
• Fiabilité partielle binaire
• Implémentation recommandée avec UDP-lite
• Overhead de 5 pour L1500 octets

14
Applications à fiabilité totale

• Fiabilisation totale assurée par la couche
  transport
• Repose sur larchitecture proposée (MPHP)
• Approche hybride-ARQ type II
• Codage au niveau paquets
• Mise à léchelle
• Retard aléatoire pour lenvoi de NACK
• Entrelacement par bloc
• Disperse les erreurs groupées temporellement
• Permet de lutter contre les profils derreurs
  décorellées
• Sans pénaliser les bons récepteurs
• Induit des délais à lémission et à la réception
• Codes RS n, k, n-k poinçonné, kltlt255
• Décodage
• Décodage par erasure impossible

15
Applications à fiabilité totale Implémentation
du décodage

• Décodage mixte erreurs / erasures
• Seule une partie des mots-code est reçue
• Les parties manquantes correspondent aux paquets
  IP non reçus
• Il peut savérer impossible que le code détecte
  des erreurs
• X nombre de symboles supplémentaires de parités
  reçues
• PNonDétection 256-X 1/16 millions pour X3
• Xlt3 ??
• Ajout dun CRC horizontal par paquet, CRC-32
• Détection derreurs quand Xlt3
• Inutilisé sinon
• Si X3, tentative de décodage
• Echec possible
• Alors, le nombre de symboles erronés est inconnu

16
Applications à fiabilité totale Variation du
taux de codage
Transport fiable
MPHP
IP
ULE-Lite
MPEG-2 TS

• Comment ajuster le niveau de redondance ?
• Compromis à trouver
• Transmettre peu de nouvelles données
• OU minimiser le nombre de décodages à effectuer
• Pour chaque demande de retransmission
• On transmet G nouveaux paquets, G granularité
• Choix de G ?

17
Applications à fiabilité totale Evaluation de
performances (1)

• Critères retenus
• Nombre de paquets transmis pour décodage complet
• Nombre de retransmissions
• Hypothèses
• Seul le pire récepteur est considéré
• BER constant
• Encapsulation ULE
• Pas de pertes de paquets par congestion
• K16
• L1500 octets
• G2 et G10

18
Applications à fiabilité totale Evaluation de
performances (2)
19
Applications à fiabilité totale Evaluation de
performances (3)
20
Conclusions Suite des travaux

• Approche novatrice fiabilité partielle binaire
• Gains évidents de plusieurs ordres de grandeurs
• Mise en uvre possible mais délicate
• MPEG-2 TS
• MPHP
• Ressources du terminal utilisateur très
  sollicitées
• Evaluation pouvant être complétée
• Impact du code de len-tête MPEG-2 ?
• Influence dautres paramètres
• Taux de codage DVB, longueur de paquets
• Prise en compte de plusieurs récepteurs
• Transmissions de plusieurs blocs
• Pertes par congestions
• Estimation de la charge de calcul

21
Mise en uvre (4) MPHPCodage RS 3k, k, 2k,
k29
Transport
MPHP
IP
ULE-Lite
MPEG-2 TS
22
Mise en uvre (5) MPHP Codage RS 255, 85, 170
Transport
MPHP
IP
ULE-Lite
MPEG-2 TS
Mémoire tampon
Codage RS entrelacement
23
Entrelacement avec les FECs-paquets
Transport
MPHP
IP
ULE-Lite
MPEG-2 TS
Transmission entrelacée