Analyses du standard LTE

Le délai induit par le backhaul satellite est la caractéristique la plus néfaste pour les procédures de

handover. En effet, la principale contrainte liée à ce mécanisme réside dans la rapidité de sa

réalisation. Son exécution doit être terminée avant que le signal en provenance de l’eNB source ne devienne trop faible. Dans LTE, cette procédure repose sur des liens de backhaul à haut-débit et à faible latence. Le lien satellite va à l’encontre de ces deux caractéristiques et met en péril le bon déroulement du handover. Ainsi, ce paragraphe met en relief deux dangers causés par le backhaul satellite : que sont le ralentissement de la phase de préparation du handover et l’inefficacité du mécanisme de Forward traditionnel.

2.4.1 Ralentissement de la phase de préparation du handover

Le premier effet néfaste du délai est causé par l’envoi de messages de signalisation sur le lien satellite ; ce qui a pour conséquence de retarder la phase de préparation du handover. Ainsi, suivant le type de handover, cette étape conduit à un ou deux allers-retours sur le lien satellite (Tableau 9), alors que la phase de préparation dure en moyenne 50ms pour un handover terrestre (Nokia, Nokia- Siemens Networks, May 2009).

Handover

Message envoyé sur le lien satellite

Délai ajouté

HO intra-satellite

Handover Required

Handover Request

Handover Response

Handover Command

4 . 𝐷é𝑙𝑙𝑖

1200 ms

HO inter-satellite-terrestre

Handover Required

Handover Command

2 . 𝐷é𝑙𝑙𝑖

600 ms

HO inter-terrestre-satellite

Handover Request

Handover Response

2 . 𝐷é𝑙𝑙𝑖

600 ms

Les paramètres des mesures permettent de compenser une partie du ralentissement de la phase de préparation. Par exemple, le TTT, qui définit la durée pendant laquelle la condition de l’événement doit être valide pour déclencher un rapport de mesures à l’eNB, est très important. Il permet d’éviter

40

des rapports et des handovers intempestifs. Une valeur faible du TTT pourrait ainsi compenser une partie du délai de la préparation. Cependant, cela augmenterait dans le même cas les risques de débuter des handovers inutilement.

Par conséquent, ce ralentissement de la phase de préparation induit une augmentation des risques d’échec du handover. En effet, la probabilité, que l’UE perde le signal avant que la phase de préparation soit terminée, devient beaucoup plus importante. La perte de ce signal prend le nom de

Radio Link Failure (RLF) dans LTE. Les spécifications définissent différents types de RLF (Tableau 10).

Ce tableau souligne les différences entre ces RLF et, en particulier, il précise que le Too-Late For

Measure RLF (type 1) est la perte de connexion qui engendre l’effet néfaste le plus important.

L’interruption due à ce type de RLF est allongée de 200 ms par rapport aux autres (NTT DoCoMo, Inc., March 2009).

RLF

Description

Commentaire

Type 1 Too-Late For Measure

Radio Link Failure survient avant le

déclenchement du handover. L’interface radio tombe avant que le rapport de mesures ne puisse être envoyé (Figure 26).

Ce type de RLF est le plus néfaste, car aucune préparation ne va être réalisée. Ainsi le rétablissement de la connexion avec une nouvelle eNB est plus long.

Type 2 Too-Late For Command

Radio Link Failure avant le message Handover

Command (RRC Connection Reconfiguration). L’interface radio tombe pendant la préparation du handover. Le handover ne peut être exécuté, car l’UE ne reçoit jamais la commande qui déclenche la phase d’exécution (Figure 27).

Le temps du rétablissement est diminué, car les probabilités que l’UE choisisse l'eNB cible déjà préparé comme eNB de récupération sont importantes.

Type 3

Too-Early Handover Failure causé par l’échec de la synchronisation avec l’eNB cible. Ainsi, la phase d’exécution ne peut être menée à son terme (Figure 28).

Dans ce cas-là, l’UE va réaliser une tentative de rétablissement de la connexion avec l’eNB source.

Tableau 10 Description des différentes Radio Link Failure

Figure 26 Too-Late For Measure

RLF (type 1). Figure 27 Too-Late For Command RLF (type 2).

41 Les échecs de handover sont reconnus comme une nuisance en particulier lors de fortes mobilités et dans des environnements urbains denses (Ericsson, February 2009). Cet aspect est exacerbé par des paramètres de handover de plus en plus agressifs, en particulier le TTT, qui devient de plus en plus faible jusqu’à atteindre 0 ms. En effet, une faible valeur de TTT augmente de manière significative le nombre et la fréquence des handovers. Ce paramètre permet de diminuer les occurrences des Too-

Late For Measure RLF, mais augmente les probabilités de subir des Too-Late For Command RLF et des Too-Early RLF.

2.4.2 Le mécanisme de Forward et d’ordonnancement inefficace

Le mécanisme de Forward, réalisé entre les eNB et la SGW pendant la phase de préparation, est inefficace. En effet, ces tunnels sont établis au niveau du backhaul dans le but de transférer les paquets de l’eNB source à l’eNB cible. Ce lien est assuré par un système satellite. Par conséquent, au lieu de subir une fois le délai d’une transmission satellite, les paquets utilisant les tunnels souffrent de trois émissions sur le lien satellite dans le cadre d’un handover intra-satellite et de deux pour les

handovers inter-segments (Figure 29).

Figure 29 Différenciation entre le tunnel source et cible.

Handover

Tunnel satellite

Source cible

Avant Pendant Après Délai (ms) induit par le satellite

Inter-satellite-terrestre   _{300 600 0}

Inter-terrestre-satellite   _{0 300 300}

Intra-satellite   _{300 900 300}

Tableau 11 Conséquences du backhaul satellite sur le mécanisme de Forward

Tout d’abord, ce délai est néfaste pour les protocoles de transport et applicatifs. En effet, les applications de transport de la voix et de la vidéo sont sensibles au délai de la transmission. C’est par ailleurs, la gigue qui engendre une baisse importante de la qualité de l’application. Les buffers dans ces applications peuvent compenser cette gigue. Mais dans notre cas, le handover cause une variation très importante du délai de 300ms à 600ms (Tableau 11). Cette fluctuation immédiate de la gigue entraîne des pertes et une diminution de la qualité de l’application. Pour les flux qui reposent sur le protocole de transport TCP, cette variation du délai a aussi des conséquences néfastes. Les

42

mécanismes implantés dans TCP dépendent en grande partie de l’estimation du RTT (Round Trip Time). Le changement brusque de cette valeur ne peut être pris en compte immédiatement ; ce qui peut causer des congestions ou bien encore des détections de congestion erronées.

En outre, ce mécanisme de Forward implique une surconsommation des ressources au niveau du lien satellite, dans le cadre de deux handovers. En effet, si le segment source est un segment satellite, le même paquet subit un aller-retour sur le lien satellite. Ce phénomène est acceptable dans le réseau terrestre, car le lien de backhaul permet d’écouler des débits très élevés, et le mécanisme de

Forward est utilisé pendant une durée réduite. Ces deux caractéristiques ne sont plus vraies avec le

segment satellite et, par conséquent, cette surconsommation a un impact plus important, qui affecte les performances des applications de l’UE qui subit le handover mais aussi ceux qui sont actifs à cet instant dans le segment satellite.

Le mécanisme d’ordonnancement est lui aussi affecté par le backhaul satellite. Il se fonde sur le transfert du contexte PDCP lors de l’exécution du handover. Ce contexte est transmis de l’eNB source à l’eNB cible par l’intermédiaire de la SGW et donc du backhaul satellite (2 dans la Figure 30). De la même manière que pour la phase de préparation, ce transfert est ralenti par le lien satellite, avec un aller et retour pour le handover intra-segment satellite et un aller simple pour le handover du segment satellite vers le terrestre. Cependant, la latence induite par le lien satellite transforme les données contenues dans le contexte en informations obsolètes. En effet, la phase d’exécution du

handover est très rapide d’un point de vue de l’UE, de quelques dizaines de millisecondes au

maximum. C’est à la fin de cette étape que l’eNB cible doit configurer sa couche PDCP (1 dans la Figure 30). L’eNB cible n’ayant pas encore obtenu le contexte PDCP, elle remet à zéro la couche PDCP et l’ordonnancement devient impossible.

Figure 30 Transfert du contexte PDCP dans le cadre d’un handover intra-satellite

Ce chapitre met en relief les défauts des spécifications du handover LTE intégrant un backhaul satellite. Deux axes d’améliorations sont ainsi tracés, avec l’optimisation de la phase de préparation pour prendre en compte le délai induit par le satellite et la définition d’un nouveau mécanisme de

43 Le chapitre suivant proposera des optimisations de la phase de préparation pour contrer son ralentissement par le lien satellite.

44

Chapitre 3 : Réseaux hybrides LTE-