Mécanismes de fiabilisation pro-actifs - ISAE

More documents

Recommendations

Info

40 Chapitre 2. Etat de l'art et principales notionsvoie de retour et faible latence, un mode basé sur les acquittements sera plus ecaceen termes de compression qu'un mode unidirectionnel. Cependant, si le réseau utilisécomporte une forte latence, ces mécanismes seront pénalisés au prot d'un modeunidirectionnel, indépendant de la latence du réseau.Des mécanismes permettant le basculement dynamique d'un mode de compressionà un autre sont également dénis dans le standard, mais ne seront pas détaillés ici.Tout comme les mécanismes de compression précédemment étudiés, ROHC dénit5 types de champs, selon leur variabilité : Les champs INFERRED non communiqués car déductibles d'autres paramètres. Les champs STATIC qui ne varient pas pour un ux de paquet. Lorsque un deces champs varie, un paquet IR est envoyé. Les champs STATIC-DEF similaires, qui permettent l'identication d'un ux depaquets (comme les adresses). Les champs STATIC-KNOWN qui sont des valeurs connues car caractéristiquesd'un protocole Les champs CHANGING considérés comme variables.Par exemple, dans le cas de RTP/UDP/IP, la répartition de ces diérents champsest présentée dans la Table 2.1 :IPv6 (octets) IPv4 (octets)INFERRED 4 6STATIC 1.75 1.875STATIC-DEF 42.5 16STATIC-KNOWN 0.25 2.625CHANGING 11.5 13.5Total 60 40Table 2.1 Répartition des champs RTP/UDP/IP dans ROHCAinsi, pour le protocole ROHC, seuls 34% de l'en-tête RTP/UDP/IP en IPv4 et19% en IPv6 sont considérés comme variables. Tout comme les protocoles précédents,ROHC permet de discriminer parmi les champs CHANGING diérents types dechamps variables, notamment les champs variant d'un delta quasi-constant. Ces mécanismespermettent ainsi d'obtenir des performances de compression similaires auxautres protocoles.Lorsque le décompresseur détecte une erreur résiduelle dans le paquet courantreçu, celui-ci rejette simplement le paquet sans envoyer d'acquittement négatif (dansles modes O et R) ou changer d'état. Le décompresseur considère alors l'échec duCRC comme une erreur binaire dans le paquet reçu. Conformément à la machine àétats du décompresseur dénie sur la Figure 2.16, lorsque k 1 des n 1 derniers paquetsont vu leur CRC échouer, celui-ci passe de l'état Full Context à l'état Static Context.Dans ce cas, le décompresseur rejette tous les paquets jusqu'à réception d'un paquet
2.3. La compression d'en-têtes 41transportant un contexte dynamique entier. De la même manière, si le décompresseurse trouve dans l'état Static Context et si k 2 des n 2 derniers paquets transportant uncontexte dynamique entier échouent, le décompresseur se met dans l'état No Context.Dans l'état No Context, le décompresseur élimine tous les paquets jusqu'à réceptiond'un en-tête complet.Un des points important du décompresseur ROHC est donc une bonne paramétrisationdes valeurs k et n. En eet, si des valeurs trop sensibles sont utilisées, parexemple k 1 = n 1 = k 2 = n 2 = 1, le décompresseur réagira de manière excessive àtoute erreur, et entrainera une perte conséquente de paquets suite à ce changementd'état soudain. Ceci sera d'autant plus marqué que les timeouts sont importants dansles modes U et O et le RTT long dans les modes O et R. De même, un manque desensiblité entraînera un manque de réaction et une longue invalidation en conséquence.Comme mécanisme de abilisation, ROHC propose une amélioration du mécanismede type LSB. Dans un mécanisme de type LSB, lorsque une modication est àtransmettre, on envoie les k bits ayant été modiés, ou alors la plus petite valeur supérieureà k lorsque l'ensemble des tailles permises est limité, par exemple des champssur un ou deux octets. Le fonctionnement de ce mécanisme est garanti lorsque lecompresseur et le décompresseur utilisent la même valeur de référence. Cependant,deux scénarios peuvent empêcher le fonctionnement correct de ce codage. Dans unpremier cas, des pertes de paquets peuvent apparaître. Dans ce cas, au prochain paquetreçu par le décompresseur, celui-ci et le compresseur n'ont plus forcément lamême valeur de référence pour le codage LSB. Il n'est donc pas garanti ici que ledécodage fonctionne ce qui entraîne un perte de synchronisation. Dans un secondcas, des erreurs bits résiduelles peuvent avoir modié le LSB porté par un paquet. Enconséquence, les prochains paquets reçus ne se baseront pas sur la même valeur deréférence que le compresseur et entraineront une propagation de l'erreur et une pertede synchronisation.An d'éliminer les erreurs d'interprétations dues à des valeurs diérentes de référencede chaque côté, ROHC utilise un schéma appelé Window-LSB (W-LSB). Avecce mécanisme, le compresseur conserve en mémoire une fenêtre glissante de valeursde référence. Lors de l'envoi d'un paquet original, le codage W-LSB va coder sur lenombre minimal k 0de bits tels que l'interprétation de la valeur originale soit unique surl'intervalle couvert par l'ensemble des valeurs de référence de la fenêtre. Ceci permetd'assurer que la décompression est correcte si tant est que le décompresseur a reçuune des valeurs de référence de la fenêtre. Ceci permet donc de garantir de manièreecace la transmission des valeurs, au prix d'une perte de compression mesurée.Le mécanisme W-LSB est illustré sur l'exemple suivant. Prenons l'exemple de latransmission des valeurs : 124, 252, 276, 278 et supposons que la valeur 252 soitperdue lors de la transmission. Avec un codage de type LSB, le compresseur envoieles valeurs : 124, 252, 76, 8. Le codage a donc coûté ici 9 caractères. Cependant,le décompresseur décodera : 124, 176, 178. Avec un codage de type W-LSB et unetaille de fenêtre de deux, le codeur enverra 124, 252, 276, 78 soit 11 caractères mais
Page 1 and 2: THÈSEEn vue de l'obtention duDOCTO
Page 4 and 5: iiannée de thèse : Julien, Paul,
Page 6 and 7: ivTable des matières4.3 Analyse th
Page 8 and 9: viTable des gures4.2 Matrice de par
Page 11 and 12: Chapitre 1IntroductionLes thèses l
Page 13: 1.2. Organisation du document 3une
Page 16 and 17: 6 Chapitre 2. Etat de l'art et prin
Page 18 and 19: 8 Chapitre 2. Etat de l'art et prin
Page 20 and 21: 10 Chapitre 2. Etat de l'art et pri
Page 54 and 55: 44 Chapitre 3. Modélisation d'un p
Page 81 and 82: Chapitre 4Codes à eacements à dé
Page 83 and 84: 4.2. Construction des codes à matr
Page 89 and 90: 4.3. Analyse théorique 79décalage
Page 91 and 92: 4.4. Résultats obtenus 81 Les code
Page 93 and 94: 4.5. Conclusion 83véritable comple
Page 95 and 96: Chapitre 5Codes de Reed-Muller pour
Page 97 and 98: 5.2. Présentation du code 87Une m
Page 99 and 100: 5.2. Présentation du code 89Figure
Page 101 and 102:
5.2. Présentation du code 91invers
Page 103 and 104:
5.3. Résultats de simulation 93Fig
Page 105:
5.4. Conclusion 955.4 ConclusionNou
Page 108 and 109:
98 Chapitre 6. Codes à eacements M
Page 110 and 111:
100 Chapitre 6. Codes à eacements
Page 112 and 113:
Page 114 and 115:
Page 116 and 117:
Page 118 and 119:
Page 120 and 121:
Page 122 and 123:
Page 124 and 125:
Page 126 and 127:
116 Chapitre 7. Conclusion et persp
Page 129 and 130:
Bibliographie[1] C. E. Shannon, A m
Page 131 and 132:
Bibliographie 121[32] ETSI IP Datac
Page 133 and 134:
Bibliographie 123[55] E. N. Gilbert
Page 135:
Bibliographie 125[87] S. Li and J.
show all

Mécanismes de fiabilisation pro-actifs - ISAE

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?