Séquence

Nous nous sommes basés sur l’architecture 23.402 [9] car elle inclut déjà une portion du réseau cœur utilisant une version de PMIPv6 remaniée. Dans un premier temps nous n’avons modifié que l’interface S5/S8 (SGW-PGW) qui utilise déjà PMIPv6, et avons appelé cette nouvelle architecture 403. Nous avons transformé le SGW en un routeur IP pour qu’il apparaisse comme un vrai MAG. Les créations/modifications/destructions de bearers sont maintenant gérées au niveau PMIPv6. Nous avons supprimé GRE car il ne nous est désormais

plus utile. Les couches de protocoles du plan de données de l’architecture 403 sont représentées à la figure 3.22. couche physique LTE MAC RLC PDCP IPv6 Application UE LTE-Uu couche physique LTE MAC RLC PDCP L1 L2 UDP/IPv6 GTP-U eNodeB S1-U L1 L2 UDP/IPv6 GTP-U L1 L2 IPv6 (PMIPv6) IPv6 SGW S5/S8 L1 L2 IPv6 (PMIPv6) IPv6 PGW SGi

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

Il nous a aussi fallu modifier les diagrammes de séquences des différentes procédures de l’architecture 23.402 [9] impliquant les bearers (voir Annexe B). Ces nouveaux diagrammes de séquences sont représentés dans cette section et dans l’annexe C. Dans les procédures de complétion de bearer (ajout d’un service), représentées aux figures B.1 à B.4, nous avons ajouté un échange PBU/PBA au niveau PMIPv6 au moment où le tunnel GRE est modifié dans l’architecture 23.402 [9]. Les diagrammes de séquences de ces nouvelles procédures sont représentés aux figures 3.23 et C.1 à C.3. La bande passante des liens, la réservation et la limitation du débit des trafics sont encore gérées par le SGW, le PGW et le eNodeB et ne peuvent pas être administrées directement par PMIPv6. Nous avons donc gardé les autres messages de contrôle de ces procédures pour déployer les informations comme les politiques de facturations, les limitations à appliquer aux trafics, les réservations de bande passante, etc.

Le LMA/PGW attend de recevoir les messages PBU et Policy and Charging Rules Pro-

vision respectivement du MAG/SGW et du PCRF avant d’envoyer le PBA et l’accusé de

réception. De cette façon, nous nous assurons qu’un tunnel n’est créé que lorsque toutes les informations le concernant sont arrivées sur le PGW.

La procédure de connexion représentée à la figure B.5 n’a pas été modifiée en apparence, c’est à dire que les mêmes messages sont envoyés. Cependant, nous avons ajouté au PBU de connexion une option Flow Label pour spécifier l’identifiant du bearer par défaut.

Les procédures de création de bearer représentées aux figures B.6 et B.7 ont été modifiées de la même manière que celles de complétions (voir figures C.4 et C.5). Les procédures de destruction et de réduction de bearer, représentées aux figures B.8 à B.13, ont été modifiées

de façon à inclure un échange de PBU/PBA au moment où le tunnel GRE est modifié dans l’architecture 23.402 [9] (voir figures C.6 et C.11). La réduction ou destruction effective du

bearer se fait au début de la procédure car elle n’a pas lieu d’être rejetée contrairement à une

création ou une complétion. Le PGW attend toujours de recevoir les informations du SGW et du PCRF pour répondre.

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

Update Bearer Response

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.23 – Complétion de bearer dédié non GBR avec UE QoS unaware

Les procédures de relève sans changement de SGW avec ou sans interface X2 (liant deux eNodeB) ne changent pas. En effet aucun modification n’y est effectuée entre le SGW et le PGW. En revanche, si le eNodeB de destination ne possède pas assez de bande passante restante pour accueillir tous les bearers du UE, il y a destruction des bearers de plus faible ARP. Dans ce cas nous avons inclus une destruction de tunnel PMIPv6 comme lors d’une destruction de bearer normal (cf. figure B.14).

Dans le cas de relève avec changement de SGW représentée aux figures B.15 et B.16 nous avons modifié les PBU/PBA utilisés pour créer la connexion entre le nouveau SGW et le PGW et pour détruire l’ancienne (voir figures C.13 et C.14). Dans notre architecture le PBU de connexion est complété d’options TFT, PFi et Flow Label nécessaires à la création de tous

les anciens tunnels qui n’ont pas été détruits par la relève. Il y a donc une option TFT et une option Flow Label par tunnel, chaque TFT étant suivi d’une liste de PFi (incluant les champs optionnels) décrivant tous les services passant par le tunnel correspondant.

Pour détruire la connexion entre l’ancien SGW et le PGW nous avons ajouté un échange de PBU/PBA de déconnexion. Nous n’avons pas complété ces messages d’option particulière et avons utilisé ceux décrits par Gundavelli et al. [65]. En effet le but de ces messages est d’informer le LMA/PGW que le UE n’est plus rattaché à l’ancien SGW, il n’y a pas de notion de bearer.

Comme pour les architectures 23.401 [8] et 23.402 [9] nous avons créé un simulateur mimant le comportement de 403. Cependant nous nous sommes demandés si les changements apportés pouvaient être étendus jusqu’au eNodeB. Nous avons donc imaginé une nouvelle architecture appelé 404.