3 RoHC dans UMTS/LTE
3.1 Description de RoHC
La taille des paquets dans les flux multimédias associés à la voix ou la vidéo est petite (20 à 60 octets); l’encapsulation RTP/UDP/IP utilisée représente donc une part importante du paquet (40 octets pour IPv4 et 60 octet pour IPv6), la compression d’en-tête RoHC (RObust Header Compression, défini dans le RFC3095 de l’IETF) permet donc une augmentation très importante de la capacité du réseau dans le cas de flux multimédias interactifs. De plus RoHC a été adopté dans la release 4 de l’UMTS.
Le mécanisme pour la compression des en-têtes RoHC intègre des fonctionnalités de robustesse permettent de supporter des réseaux bruités. L’architecture du mécanisme de Compression RoHC est complexe, mais permet de s’adapter aux caractéristiques du lien et au flux de données. Offrant une grande flexibilité dans le mécanisme à travers les différents profils et modes d’opération. La norme 3GPP pour RoHC (TS25.323) rend obligatoire les profils 0, 1, 2 et 3[17].
Le principe à la base de la compression des en-têtes est la réduction de la redondance de l’information contenue dans un en-tête, mais aussi de la redondance entre plusieurs en-têtes consécutifs. Ainsi l’information qui ne change pas est envoyée au début de la session ou à un faible rythme; pour les autres champs, un mécanisme de prédiction ou de dépendance permet de réduire encore l’information transmise. Le principe de RoHC est d’envoyer l’information minimale pour que le décompresseur puisse reformer l’en-tête. L’élément clé est le CRC, calculé avant la compression. Il donne au décompresseur une information sur la validité de l’information qu’il possède, puisque l’information transmise est susceptible d’être modifié suite à des erreurs de transmission.
La norme RoHC a laissé ouverts de nombreux choix de mise en œuvre, entre autres : la décision du passage dans le décompresseur pour travailler dans le mode optimiste ou fiable, les valeurs des différents paramètres qui sont utilisés pour la compression.
L’étude approfondie des spécifications de RoHC, d’IPv6 et de la 3G a permis de relever quelques incohérences dans les documents, en particulier pour le protocole IPv6. Ceci a conduit à des nouveaux travaux au sein de l’IETF qui ont débouché sur une nouvelle version du protocole RoHC (RoHCv2) qui se différencie de la précédente version du protocole RoHC (ROHCv2). Elle se différencie de la précédente pour les formats de paquets qui sont utilisés.
3.2 RoHCv2
Tandis que RoHCv1 est spécifié principalement par la RFC 3095, RoHCv2 est défini par trois documents :
* La RFC 4995 décrit le framework commun à v1 et v2 pour la plus grande part.
* La RFC 4997 définit RoHC-FN, une notation formelle pour définir des profils RoHC et les méthodes de compression associées.
* La RFC 5225 définit les profils RoHCv2 proprement dits, décrits en grande partie à l’aide de RoHC-FN.
3.2.1 Motivation de proposition de RoHCv2 dans PDCP/LTE
RoHCv2 est proposée par Ericsson[21]. La proposition est basée sur trois axes principaux: la robustesse, l’efficacité, et la facilité d’implémentation. Dans la même condition de fonction, le RoHCv2 a la même efficacité de compression. RoHCv2 supporte le déséquencement de paquets entre compresseur et décompresseur qui n’est pas supporté pas RoHCv1. Cela permet à la couche PDCP de mettre en ordre paquets dans le cas de handover inter-eNodeB. Le profil de TCP/IP qui est déjà supporté par RoHC à la couche PDCP apportent des améliorations et des simplifications pour RFC 3095. Les simplifications sont utilisées pour développer le RoHCv2.
3.2.2 Améliorations et autres différences de RoHCv2 avec RoHCv1
Les formats de compression v2 sont au moins aussi performants, tant en termes de taux de compression que de robustesse, que les formats v1. De plus, comparé à RoHCv1 :
* RoHCv2, supporte le déséquencement de paquets entre compresseur et décompresseur. Le mécanisme utilisé permet en outre une meilleure tolérance au déséquencement avant le compresseur.
* RoHCv2 utilise les mêmes formats de compression dans ses deux modes de fonctionnement : unidirectionnel et bidirectionnel. Sa logique opérationnelle est plus simple et plus homogène que celle de RoHCv1.
* RoHCv2 traite les extensions IP comme les autres protocoles compressés, au lieu d’utiliser une liste compressée. Cela implique que si la liste des extensions change, le flux compressé sera affecté à un nouveau contexte.
* RoHCv2 n’utilise pas de format IR-DYN (Initialization & Refresh / Dynamic fields) ; seul le format IR peut changer le profil associé à un contexte. En revanche, elle utilise un format co_repair qui transmet tous les champs dynamiques, protégés par un CRC 7 bits, en cas de besoin (contexte décompresseur abîmé).
* La segmentation RoHC est incompatible avec les formats v2 lorsque RoHC ne peut garantir une transmission sans réordonnancement entre compresseur et décompresseur. Cela est dû au fait que le protocole de segmentation n’utilise pas de numéro de séquence, mais un simple bit pour distinguer le dernier segment.
Un point commun important avec RoHCv1 : RoHCv2 compte sur les couches basses pour donner la longueur des paquets compressés, et ne transmet donc pas dans ces paquets la taille de la charge utile.
3.2.3 Les profils de RoHCv2
RoHCv2 définit (RFC 5225) les profils suivants :
* 0x0101 rtp (IP / UDP / RTP)
* 0x0102 udp (IP / UDP / non RTP)
* 0x0103 esp (IP / ESP)
* 0x0104 ip (IP / autre)
* 0x0107 udplite_rtp (IP / UDPlite / RTP) (n’est pas utilisée dans LTE)
* 0x0108 udplite (IP / UDPlite / non RTP) (n’est pas utilisée dans LTE)
N.B. IP s’entend v4 ou v6 ; les deux versions peuvent être utilisées dans un même en- tête. Les bits de poids fort en 0x01 permettent de distinguer les profils v2 des profils v1 (0x00).
Pour chaque profil, RoHCv2 sait compresser les protocoles suivants en tant qu’extensions IP :
* ip_dest_opt (IPv6 Destination Option)
* ip_hop_opt (IPv6 Hop-by-hop Option)
* ip_rout_opt (IPv6 Routing Header)
* gre (Generic Routing Encapsulation)
* mine (Minimal Encapsulation within IP)
* ah (IP Authentication Header)
3.2.4 Compresseur et décompresseur
RoHCv2 utilise deux modes de fonctionnement :
* unidirectionnel : les compresseur envoie les paquets avec une approche optimiste. Cela consiste à répéter chaque changement de champ transmis en espérant que le décompresseur recevra au moins un des changements. Pour que cette approche fonctionne bien, il faut ajuster le facteur de répétition aux caractéristiques du lien (taux d’erreurs bit, taux de déséquencement) en visant un compromis robustesse / efficacité.
* bidirectionnel : le décompresseur peut, s’il existe un lien dans cette direction, envoyer du feedback au compresseur. Une fois que le compresseur reçoit du feedback pour un contexte donné, il passe définitivement en mode bidirectionnel pour ce contexte. Le trafic de feedback est constitué en majeure partie d’acquittements positifs et négatifs ainsi que d’options diverses. Le feedback guide ainsi le compresseur en indiquant les formats compressés que le décompresseur est capable de traiter. La synchronisation se fait par un numéro de séquence interne à RoHC (Master Sequence Number).
3.3 Recommandation de RoHC dans 3GPP

ProfileIdentifierUsageReferenceRoHC version
0x0000No compressionRFC 4995Commun à v1 et v2
0x0001RTP/UDP/IPRFC 3095, RFC 4815v1
0x0002UDP/IPRFC 3095, RFC 4815v1
0x0003ESP/IPRFC 3095, RFC 4815v1
0x0004IPRFC 3843, RFC 4815v1
0x0006TCP/IPRFC 4996v1
0x0101RTP/UDP/IPRFC 5225v2
0x0102UDP/IPRFC 5225v2
0x0103ESP/IPRFC 5225v2
0x0104IPRFC 5225v2

Tableau 1: Les profils supportés par LTE [17]
Historiquement, dans release 99, la couche de PDCP ne supporte que « IP compression header ». ROHCv1 est supporté à partir de release 4. Les tests de la performance de RoHC sont ajoutées dans release 5. Dans release 6, l’utilisation de RoHC dans les services MBMS est prise en compte, mais n’est pas obligatoire.
Dans release 8, PDCP n’utilise que RoHC pour compresser/décompresser des entêtes pour les paquets au plan utilisateur. Les profils supportés se composent des profils définis dans ROHCv1 et ROHCv2 (cf. tableau 1).
L’utilisation de la compression des entêtes peut être configurée par la couche supérieure. RRC contient des informations pour la configuration de PDCP (voir 3.5).
Les paramètres obligatoires de la configuration sont définis par RFC 4995. Mais il y a des paramètres qui ne sont pas utilisés par PDCP de cette release.

ParamètreObligatoireDescription
MAX_CIDOuiLe nombre maximal de CID (Contexte Identifier) est utilisé. Il faut réserver au moins un contexte pour lesflux non-compressés. C’est-à-dire, il faut que
MAX_CID < « Maximum Number of RoHC Context
Sessions »
LARGE_CIDSOuiElle est déduite du paramètre MAX_CID par la règle : If MAX_CID > 15 then LARGE_CIDS = TRUE elseLARGE_CIDS = FALSE.
PROFILESOuiLes profils sont utilisés par l’UE. Les profils autorisés sont disponibles dans le tableau 1.
FEEDBACK_FORNon utiliseLe canal de « feedback »
MRRUNon utiliseL’utilisation de segmentation

Tableau 2: Les paramètres sont définis par la couche supérieure de PDCP[17]
3.4 Support de RoHC au terminal
Les UE qui supportent RoHC doivent supporter le profil non-compression, 0x0000. Pour les UE qui sont capables de supporter le service de voix via IMS (‘IMS capable UEs supporting voice’), il faut supporter les profile suivants de RoHC 0x0000, 0x0001, 0x0002, 0x0004.[22] (annexe Support de RoHC dans l’UE (3GPP TS 36.306 V8.3.0)). C’est-à-dire les profils de ROHCv1 ont la priorité sur ceux de RoHCv2. Le support de RoHC pour UE non- capable de IMS est optionnel [23].
L’eNodeB peut recevoir des profils de RoHC que l’UE supportent par l’interrogation de l’UE, ou par la réception du message de « Initial Context Setup Request » de MME. Il sauvegarde les informations afin d’établir les connexions radio avec l’UE.
Pour interroger l’UE, l’eNodeB envoie le message RRC de « UECapabilityEnquiry » qui force l’UE à transmette le message de « UECapacityInformation » qui contient les profils supportées par l’UE (annexe UE-EUTRA-Capability). Pour plus de détails, on peut consulter le chapitre 5.6.3 de [24].
Le message de « UECapacityInformation » contient les autres informations de la capacité radio que l’UE supportent. Après la réception de l’UE, l’eNodeB va transmettre ce message à MME. Le MME sauvegarde les informations jusqu’à ce que l’UE lance la procédure d’attacher ou de détacher le réseau (chapitre 5.11.2 de [25]). Le MME va transmettre les informations au nouveau eNodeB pendant le handover, afin de réduire l’overhead, car la taille de message « UECapacityInformation » peut atteindre 510 octets.
Lire le mémoire complet ==> (Utilisation de la compression des entêtes dans les réseaux cellulaires de type 4G)
Institut de la Francophonie pour l’Informatique – NEXTTV4ALL
Mémoire de fin d’études – Intégration de RoHC dans l’architecture de LTE
Master Informatique, option Systèmes et Réseaux

Rechercher
Télécharger ce mémoire en ligne PDF (gratuit)

Laisser un commentaire

Votre adresse courriel ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Scroll to Top