• Aucun résultat trouvé

L’architecture 404

Dans le document Architectures 3GPP et évolution vers IPv6 (Page 90-97)

CHAPITRE 3 PROPOSITION D’ÉVOLUTION VERS UNE UTILISATION

3.5 L’architecture 404

Dans cette architecture (évolution de la 403) nous avons étendu le domaine PMIPv6 aux eNodeB. Pour correspondre au fonctionnement de GTP nous avons installé un LMA sur le SGW (en plus du MAG déjà présent) et un MAG sur chaque eNodeB. Les eNodeB deviennent donc des routeurs IPv6. Les couches de protocoles sur le chemin des paquets de données sont représentées à la figure 3.24. Nous avons utilisé les mêmes options PMIPv6 que celles utilisées dans l’architecture 403. couche physique LTE MAC RLC PDCP IPv6 Application UE LTE-Uu couche physique LTE MAC RLC PDCP L1 L2 IPv6 (PMIPv6) IPv6 eNodeB S1-U L1 L2 IPv6 (PMIPv6) IPv6 L1 L2 IPv6 (PMIPv6) IPv6 SGW S5/S8 L1 L2 IPv6 (PMIPv6) IPv6 PGW SGi

Figure 3.24 – Couches de protocoles du plan de données dans un EPS suivant l’architecture 404 proposée

Pour les procédures de complétion3 de bearer, nous avons ajouté un échange de PBU/ PBA entre le eNodeB et le SGW pour modifier le tunnel au niveau PMIPv6. Les nouveaux

diagrammes de séquences sont représentés aux figures 3.25 et D.1 à D.3. Comme pour l’archi- tecture 403 nous avons fait en sorte que la modification du tunnel PMIPv6 se fasse au même moment que celle du bearer GTP dans l’architecture 23.402 [9]. Le SGW attend de recevoir le PBU et le Update Bearer Response avant de continuer la procédure, de cette façon nous nous assurons que le bearer est modifié si et seulement si toutes les informations le concernant sont disponibles sur le SGW (MBR, type, TFT, ARP, etc.).

UE eNodeB MME SGW PGW PCRF SASN

SASN Request Politic SASN Ack Request Politic Gateway Control and QoS Rules Provision

Update Bearer Request Downlink NAS Transport

Direct Transfer Direct Transfer

Uplink NAS Transport

Proxy Binding Update (update) Update Bearer Response Proxy Binding Ack (update)

Gateway Control and QoS Rules Provision Ack Proxy Binding Update (update)

Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Proxy Binding Ack (update)

SASN Response Politic SASN Ack Response Politic

Figure 3.25 – Complétion de bearer dédié non GBR avec UE QoS unaware

De la même manière les diagrammes de séquences des procédures de création de bearer dédié pour les UE QoS aware et unaware ont été modifiés et sont représentés aux figures D.5 et D.6. Le SGW attend la réception du PBU et du message Create Bearer Response avant de continuer. Pour la création et la complétion de bearer, l’action (création ou modification effective) est effectuée en fin de procédure car elle est susceptible d’être rejetée du fait de la réservation de bande passante.

Pour la connexion du UE, nous avons ajouté un échange PBU/PBA à l’activation finale du bearer (voir figure D.4). Tout comme précédemment, le SGW attend la réception du PBU

et du message Create Bearer Response avant de continuer. Les procédures de destruction de bearer représentées aux figures 3.26 et D.7, ont été modifiées pour supprimer le tunnel PMIPv6 au moment où le eNodeB envoie l’accusé de réception signifiant la destruction du

bearer radio. La suppression ne se fait pas à la réception de la requête mais de la réponse, en

effet dans le document 23.401 [8] il est indiqué que le SGW détruit ses bearers à la réception du Delete Bearer Response (dans le cas où l’on utilise seulement GTP). Cependant, le bearer entre le SGW et le PGW est supprimé au début de la procédure car dans le 23.402 [9] il est indiqué que le PGW peut être notifié de la destruction du bearer en même temps que le SGW. Nous avons donc choisi de paralléliser la notification du SGW et du PGW, ce qui implique la suppression du bearer sur le PGW en début de procédure. Pour suivre cette logique nous avons choisi de détruire le tunnel SGW-PGW avant que le SGW ne reçoive le message Delete

Bearer Response du MME.

UE eNodeB MME SGW PGW PCRF SASN

SASN Inform Service Stop Ack SASN Inform Service Stop Gateway Control and QoS Rules Provision

Proxy Binding Update (destruction)

Policy and Charging Rules Provision Policy and Charging Rules Provision Ack

Proxy Binding Ack (destruction)

Delete Bearer Request Deactivate Bearer Request

RRC Connection Reconfiguration RRC Connection Reconfiguration Complete

Deactivate Bearer Response Direct Transfer

Deactivate EPS Bearer Context Accept

Proxy Binding Update (destruction)

Delete Bearer Response

Proxy Binding Ack (destruction)

Gateway Gateway Control and QoS Rules Provision Ack

SASN Notify Bearer Destructed SASN Ack Notify Bearer Destructed

Figure 3.26 – Destruction de bearer dédié avec UE QoS unaware

Les procédures de réduction4 de bearer, représentées aux figures D.8 à D.11, ont été modifiées de la même façon que celle de destruction. La différence est que les PBU/PBA ne

contiennent pas une demande de destruction5 mais de modification de TFT. Ils contiennent donc des options TFT avec un champ PRO fixé à Delete packet filters from existing TFT6 et des options PFi désignant les filtres à supprimer.

Concernant la procédure de relève sans interface X2 et sans changement de SGW repré- sentée à la figure 3.27, plusieurs changements ont été apportés. Dans cette figure, les messages en rouge, incluant flèche et texte, sont ceux ajoutés par rapport à la procédure de l’archi- tecture 23.402 [9] représentée à la figure B.14. Les messages dont seule la flèche est en rouge sont ceux qui ont été déplacés.

Nous avons désactivé la possibilité de faire une redirection indirecte car PMIPv6 ne le supporte pas. Le eNodeB source n’aurait pas été en mesure de délivrer les paquets arrivés après la resynchronisation du UE ce qui aurait pu engendrer des pertes de paquets. Nous avons donc décidé de changer très tôt l’adresse de destination des bearers du UE sur le SGW, avant même la resynchronisation du UE avec le eNodeB de destination. Les paquets arrivant à cet eNodeB sont mis en cache comme c’est le cas dans les architectures précédentes ; une fois que le UE est connecté au nouveau eNodeB, le cache est vidé et le paquet envoyé au UE. Pour déplacer le changement d’adresse de destination des bearers nous avons décalé l’échange de Modify Bearer Request/Response entre le MME et le SGW au moment où le MME reçoit le Handover Request Ack du eNodeB de destination. Dans le cas où le Handover

Request Ack est négatif le SGW n’est pas notifié et la relève n’est pas faite.

Au moment où le MME reçoit le Handover Request Ack celui-ci prend connaissance des

bearers à conserver et à rejeter ; le eNodeB de destination a connaissance de la relève et a

préparé un cache pour recevoir les paquets du UE. Il est donc possible de changer le chemin des paquets downlink du UE sur le SGW à ce moment. En même temps une procédure PMIPv6 de création des nouveaux tunnels entre le eNodeB destination et le SGW, est lancée par le eNodeB. Le SGW attend d’avoir reçu le Modify Bearer Request et le PBU pour changer les adresses des bearers, de cette façon nous nous assurons que le SGW possède toutes les informations concernant les bearers. Nous avons aussi choisi de déplacer la procédure de destruction de bearer avec le message Modify Bearer Request car dans la documentation de l’architecture 23.401 [8], son lancement accompagne ce message.

Lorsque le UE se désynchronise du eNodeB source, cet eNodeB envoie un PBU de dé- connexion au SGW de façon à entériner l’information de déplacement du UE du précédent PBU envoyé par le eNodeB destination. Une fois que le UE est synchronisé avec le eNodeB destination, comme pour les architectures 23.401 [8] et 23.402 [9], un compte à rebours est lancé à la fin duquel toutes les ressources associées au UE sont libérées sur le eNodeB source. 5. Une demande de destruction de bearer ne contient aucune option TFT, l’option Flow Label est suffisante. 6. Delete packet filters from existing TFT = 5 , si l’on prend la norme du document 24.008 [10].

UE eNodeBSource DestinationeNodeB MME SGW PGW PCRF SASN Handover Required

Handover Request Handover Failure Handover Preparation Failure

Pas assez de bw dans le eNodeB destination ou sur le SGW coté eNodeB destination pour créer le Bearer par default Proxy Binding Update (connection + bearer)

Handover Request Ack

Delete Bearer Command

Gateway Control and QoS Rules Request

SASN Notify Bearer Destruction SASN Ack Notify Bearer Destruction Gateway Control and QoS Rules Reply

Proxy Binding Update (destruction)

Policy and Charging Rules Provision Proxy Binding Ack (destruction)

Gateway Control and QoS Rules Ack

Policy and Charging Rules Provision Ack

SASN Notify Bearer Destructed SASN Ack Notify Bearer Destructed Si un bearer à été rejeté

Modify Bearer Request Proxy Binding Ack (connection + bearer) Modify Bearer Response Handover Command

Handover Command

Proxy Binding Update (termination) Proxy Binding Ack (termination) Handover Confirm

Handover Notify

lancement du timer expiration du timer UE Context Release Command

UE Release Context Complete

Les bearers qui n’ont pas pu être portés sur le nouvel eNodeB sont supprimés grâce à la même procédure que celle utilisée dans l’architecture 403.

Pour la procédure de relève sans interface X2 avec changement de SGW représentée à la figure 3.28 nous avons ajouté un échange de PBU/PBA entre le SGW et le PGW lors du détachement du UE de l’ancien eNodeB et donc de l’ancien SGW. Le message Modify Bearer

Request est aussi suivi d’une procédure de connexion/création de bearers, entre le SGW et le

PGW comme c’est le cas lors de ce type de relève dans l’architecture 23.402 [9].

En ce qui concerne la procédure de relève avec interface X2 sans changement de SGW représentée à la figure D.12 la présence de l’interface X2 nous autorise à changer le Proxy CoA7 du UE sur le SGW après que celui-ci ait changé de eNodeB. En effet l’interface X2 permet de rediriger les paquets directement du eNodeB source vers le eNodeB destination, où ils seront mis en cache en attendant que le UE se resynchronise. Nous avons donc préféré conserver l’ordre des messages de l’architecture 23.402 [9], ce qui veut dire que les paquets ne sont redirigés vers le eNodeB destination qu’au moment où le UE se détache du eNodeB source.

Du fait de l’ajout de PMIPv6 entre le eNodeB et le SGW, nous avons ajouté des échanges de messages PBU/PBA. Comme pour la procédure de relève précédente nous y avons ajouté un échange accompagnant le message Modify Bearer Request pour changer le Proxy CoA des

bearers du UE sur le SGW. Un autre, lancé par le eNodeB source en toute fin de procédure

vient entériner ce changement.

La procédure de relève avec interface X2 et changement de SGW est représentée à la figure D.13. Par rapport à celle sans changement de SGW, nous avons ajouté un échange de PBU/PBA de déconnexion entre le SGW source et le PGW au moment où le SGW reçoit le PBU de déconnexion du eNodeB source. De cette façon, les tunnels entre ce eNodeB, le SGW et le PGW sont supprimés l’un après l’autre. Les messages PBU et PBA entre le SGW destination et le PGW ont été modifiés pour contenir les informations nécessaires à la création des bearers, c’est à dire une option TFT par bearer et une liste de PFi. Nous n’avons pas rattaché l’envoi du PBU de déconnexion de l’ancien SGW à la réception du message Delete

Session Request comme c’est le cas dans l’architecture 403. Nous avons préféré l’attacher à

la réception du PBU de déconnexion du eNodeB source pour rester au niveau PMIPv6. Ce que nous ne pouvions pas faire dans l’architecture 403 étant donné que le lien S1-U était géré par GTP.

Nous avons implémenté les architectures décrites précédemment dans le simulateur NS-2 pour pouvoir les comparer et les avons opposées en fonction des performances du réseau au

UE eNodeBSource DestinationeNodeB SourceMME DestinationMME SourceSGW DestinationSGW PGW PCRF Handover Required

Forward Relocation Request

Create Session Request Create Session Response Handover Request

Proxy Binding Update (connection + bearer) Handover Request Ack

procédure de destruction de bearer Modify Bearer Request Proxy Binding Acknowledgement (connection + bearer)

Gateway Control Session Establishment Acknowledge Gateway Control Establishment Proxy Binding Update(connection + bearer) Proxy Binding Acknowledgement(connection + bearer) Modify Bearer Response

Forward Relocation Response Handover Command

Handover Command

Proxy Binding Update (termination)

Proxy Binding Update (termination) Proxy Binding Ack (termination) Proxy Binding Ack (termination)

Handover Confirm

Handover Notify

Forward Relocation Complete Notification lancement du timer

Forward Relocation Complete Acknoledge expiration du timer

UE Context Release Command

Delete Session Request

UE Release Context Complete Gateway Control Session Termination

Acknowledge Gateway Control Termination

Policy and Charging Rules Provision Policy and Charging Rules Provision Ack Delete Session Response

niveau du UE. Pour ce faire nous avons recherché quelles seraient les meilleures métriques à utiliser.

Dans le document Architectures 3GPP et évolution vers IPv6 (Page 90-97)