Procédure de déclenchement de RoHC – RoHC, MBMS et handover

3.5 Procédure de déclenchement de RoHC
Cette partie décrit des étapes pour établir un service au plan de contrôle, dans lesquels le déclenchement de RoHC est montré (source principale [24]). En résumé, le RoHC est déclenché dans la procédure d’établissement de connexion de données DRB (Data Radio Bearer). Cette procédure est réalisé après l’établissement de connexion de signalisation SRB (Signalling Radio Bearer) et la procédure d’authentification. RoHC sera déactivé après la suppression des connexions DRB. Ci-dessous, les étapes sont développées en détails.
Procédure pour configurer et déclencher RoHC dans l'interface radio
Illustration 12: Procédure pour configurer et déclencher RoHC dans l’interface radio
Premièrement, la connexion de signalisation SRB qui sert à transmettre des messages RRC entre UE et E-UTRAN est établie par la procédure de « RRC Connextion Etablisement ». Cette procédure est déclenchée par la couche supérieure de l’UE, lorsque l’UE veut répondre un appel de paging, faire un appel, ou transmettre des messages de NAS (qui sont « piggybacked » dans les messages de RRC). L’UE envoie un message de « RRCConnectionRequest » vers eNodeB. La connexion SRB est établie lorsque l’UE reçoit un message de « RRCConnectionSetup » d’eNodeB. L’entité PDCP sera établie, en observant la configuration courante de sécurité. Ici, il n’y a pas de compression. Ensuite, tous les messages d’authentification et de NAS transmis sont protégés (intégrité/chiffrement) par PDCP. Si l’E-TRAN est surchargé, il peut refuser la requête de l’UE par le message « RRCConnectionReject » qui contient le temps d’attente.
Deuxièmement, ce sont la procédure d’authentification et d’autres procédures de NAS qui ne sont pas précisées dans le cas de ce document.
Troisièmement, la procédure de re-configuration sera lancée afin de contrôler le handover, de transmettre des messages NAS d’eNodeB vers l’UE, ou d’établir/modifier la connexion de données DRB au plan d’utilisateur. Pour le dernier but, le message de « RRCConnectionReconfiguration » contient des informations pour configurer la sous-couche PDCP, PDCP-config (qui s’appelle PDCP-info dans la release précédante de release 8, annexe PDCP-info ). En conséquence, l’instance de RoHC est établie. Tous les entêtes de paquets IP au plan d’utilisateur sont compressés par RoHC. L’UE répond à l’E-UTRAN par le message de « RRCConnectionReconfigurationComplete « .
PDCP-config se compose des paramètres qui définissent l’utilisation/non-utilisation de RoHC, le nombre maximal de contexte utilisé (MAX_CID), les profils supportés. Si les deux profils supportés ont en commun les 8 bits de pois faible, celui dont la valeur est la plus élevée est sélectionné. RoHCv2 est donc privilégié par rapport à RoHCv1. De plus, dans les releases précédentes de la releases 8, la configuration de PDCP regroupe d’autre paramètre telle que la « Target Mode », qui décide le mode de RoHC (annexe PDCP-info ).
Si l’UE ne peut pas appliquer une partie de la configuration dans le message de « RRCConnectionReconfiguration », il lancera la procédure de re-établissement. Il envoie un message de « RCC Connection Reestablisement » qui indique le refus par la configuration, ou par le handover, mais n’indique pas des paramètres qui causent ce refus. L’idée principale est de réduire la complexité d’eNodeB. L’entité PDCP est ré-établie selon la configuration précédente.
Enfin, le message de « RRCConnectionRelease » va supprimer toutes les connexions de SRB et de DRB établies si l’UE est inactif pendant longtemps ou passe à un autre eNodeB.
L’entité de PDCP, et l’instance de RoHC sera alors libérée.
PDCP-Config information element
Texte 1: PDCP-Config information element [24]
3.6 RoHC et handover
Selon les études dans de la couche PDCP (cf. 2.4.1), on remarque LTE utilise « hard handover ». Il y une court interruption de services quand le réseaux exécute le handover. S’il y a pas l’interface X2 entre l’eNodeB de source et de destination. Le handover cause un taux de perte de paquets.
L’utilisation de RoHC causse une perte de la capacité de très peu d’importance, en comparaison avec l’effet de la mobilité. A la vitesse de 120 km/h, la mobilité causse 63% de perte, et le « typical RoHC » causse 3% de perte. Cependant, n’utilisant pas de RoHC cause une perte de 66% à la vitesse de 30 km/h[26].
Discussions: Transfert (relocation) de contexte de RoHC dans le cas de handover. Le transfert de contexte de RoHC est un mécanisme de transmettre le contexte de RoHC de source à destination. A destination, le RoHC va re-construire le contexte. Cela permet RoHC de continuer fonctionner avec le contexte actuelle, de ne pas envoyer des packets IR pour construire un nouveau contexte, et réduire la perte cassée par l’interruption de contexte. On peut donc économiser la bande passante de 1.9% quand la fréquence de handover est haute, et de 0.5 quand la fréquence de handover est base [R2-072045]. Le transfert de contexte est donc supportée par UMTS. Mais, LTE ne supporte pas le transfert. Pour implémentation de transfert de contexte, il faut modifier l’interface X2 pour gérer les informations de contexte, et modifier significativement le protocole RoHC. Cependant, l’idée principale de LTE est de mettre moins complexité. De plus, si le transfert de contexte est supporté, l’implémentation de différentes fournisseurs de RoHC peut ne pas traiter le même lors qu’il y a le problème de déconséquence ou la perte de paquets.
3.7 RoHC et MBMS
L’avantage de Broadcast/Multicast par rapport à l’unicast est que les données sont transmises une fois sur un lien pour plusieurs destinataires. Cet avantage est plus important sur l’interface radio quand nous avons un large nombre d’utilisateurs. Il ne bloque pas cette interface pour de multiples transmissions des mêmes données.
3.7.1 MBMS
Les services MBMS (Multimedia Broadcast/Multicast Service) permettent aux opérateurs 3G de fournir plus efficacement les applications média en concurrence avec DVB- H. Ils diminuent le débit dans réseaux coeur et utilisent efficacement des ressources radio au réseau d’accès. Ils ont deux modes de fonctionnement : mode broadcast et multicast. Ces deux modes utilisent une transmission unidirectionnelle [27].
Le mode broadcast permet de diffuser des données média d’un nœud (un opérateur) vers multiples nœuds (multiples utilisateurs) dans la zone de services. Dans le mode multicast, le réseau n’envoie des données qu’aux cellules où il y a des abonnées (un groupe). Le mode multicast ressemble au mode broadcast, à cela près qu’il propose des mécanismes d’abonnement (subscripstion) et rejoindre/disjoindre du groupe [28]. Le mode multicast de 3GPP est différent du multicast IP d’IETF. Il prend en compte l’utilisation efficace des ressources radio. Cependant, il peut être compatible avec le multicast IP.
Depuis le release 7, 3GPP apporte une nouvelle notion de SFN (Single Frequency Network). SFN permet aux transmissions de plusieurs cellules d’être synchronisées pour transmettre un même contenu. Le protocole SYNC et un serveur de MBMS-GW (e-MBMS Gateway) sont utilisés pour diffuser le même contenu vers les eNodeBs. Une entité de MCE (MBMS Coordination Entity) coordonne les allocations de ressources radio aux couches RLC/MAC de ces eNodeBs. Dans la suite, 3GPP a décidé de compléter l’architecture de MBMS dans release 9 [29].
3.7.2 RoHC et Broatcast/Multicast
Dans les releases précédentes, la compression des entêtes est réalisée soit au RNC, soit BM-SC, et soit aux les deux (la compression au RNC remplace la compression a BM-SC). A la couche PDCP, RoHCv1 (RFC 3095) U-mode est utilisé [28].
La performance de RoHC est meilleur si le canal de feedback est utilisé. Mais le service de MBMS diffuse le contenu de point aux multiple utilisateurs, c’est difficile ou impossible de traiter tous les feedback [30]. Le taux d’erreur de lien radio est plus élevé. La perte de feedback pousse le compresseur à passer à un bas niveau de compression, même au niveau de non-compression. De plus, lorsqu’il y a un utilisateur disjoint le groupe de multicast, le RoHC doit passer à l’état IR. Les paquets d’envoyer aux d’autres utilisateurs ne sont pas compressés. Cela diminue donc notablement l’efficacité de RoHC.
Selon la release 9, BM-SC supporte la compression des entêtes dans le mode broadcast. C’est une solution plus simple. Mais il y a une duplication de RoHC dans le réseaux du coeur (une au BM-SC, et l’autre à l’eNodeB). L’autre solution qui ne met que la compression à la couche PDCP de l’eNodeB est plus complequée, car la difficulté de synchronisation de contenu. L’implémentation de RoHC de fournisseurs différents n’est pas identique, et ne traite pas la même façon dans le cas de perte, et de déséquencement de paquets [31].
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