Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Création de sessions CUPS et flux de données avec le plan d’utilisateur multi-accès Junos

Avec l’introduction du CUPS, il est utile de montrer comment une session utilisateur final est créée, comment les données circulent pendant la session et comment la session est terminée avec le plan d’utilisateur multi-accès Junos.

Création de sessions CUPS

Remarque:

Avant de créer une session CUPS, la fonction de plan de contrôle (SAEGW-C, SGW-C, PGW-C) doit créer une association Sx avec la fonction du plan d’utilisateur (SAEGW-U, SGW-U, PGW-U). Le plan de contrôle envoie un message de demande de configuration d’association Sx Association et le plan d’utilisateur répond avec un message configuration de réponse à l’association Sx Association pour créer l’association. Une fois cela terminé, le plan de contrôle peut créer des sessions Sx sur le plan utilisateur.

Pour qu’un utilisateur final souhaite accéder au réseau, une session CUPS doit être créée. La Figure 1 illustre ce processus lorsqu’une association Sx est établie entre un SAEGW-C et un SAEGW-U.

Figure 1: Création de sessions CUPS pour SAEGW-C et SAEGW-U CUPS Session Creation for SAEGW-C and SAEGW-U
  1. L’équipement utilisateur (UE) envoie une demande de joindre au NodeB, qui envoie le message à l’entité de gestion de la mobilité (MME). La requête inclut l’APN.
  2. La MME envoie une demande de création de session au SAEGW-C.
  3. Le SAEGW-C effectue les actions suivantes:

    • Valide les éléments d’information reçus dans la demande.

    • Valide l’APN demandé par l’abonné.

    • Envoie une demande d’établissement de session Sxab au moteur de routage (RE) du MX SAEGW-U.

    Remarque:

    L’établissement de session Sx est la messagerie SAEGW-C des paramètres de contrôle saEGW-U sur la façon de se comporter lorsque le SAEGW-U rencontre un certain trafic. Les paramètres de contrôle minimum pour l’établissement de session Sx sont une règle de détection de paquets (PDR) et une règle d’action de forwarding (FAR) L’établissement de session Sx se connecte efficacement à l’abonné.
  4. Le re de la saEGW-U effectue les actions suivantes:

    • Identifie l’adresse IP de la session.

    • Sélectionne et ancre le PFE à utiliser pour la session.

    • Alloue les ID de tunnel GTP-U de support.

    • Ajoute la session au PFE d’ancrage.

    • Envoie une réponse à l’établissement de session Sxab au SAEGW-C.

  5. Le SAEGW-C envoie une réponse de session créer à mme.
  6. La MME envoie un message d’acceptation d’attache à l’UE qui répond par un message complet d’joindre.
  7. La MME envoie une demande de modification de support au SAEGW-C, qui envoie une demande de modification de session Sxab au re sur le SAEGW-U. Le re met à jour l’adresse IP de session et l’ID de tunnel de l’eNodeB. Enfin, une modification de la réponse Bearer est acheminée vers MME.
    Remarque:

    Sx Session Modification Request est la messagerie SAEGW-C qui permet à SAEGW-You de modifier l’une des quatre règles suivantes:

    • Règle de détection des paquets (PDR): contient des informations décrivant les paquets à recevoir quel traitement (par exemple, le forwarding et d’autres types d’application)

    • Règle d’action de forwarding (FAR): contient des informations concernant l’application du forwarding, du filtrage ou de la mise en mémoire tampon sur un paquet

    • Règle de reporting d’utilisation (URR): contient des informations qui définissent une certaine mesure à effectuer sur le trafic utilisateur et la façon dont ces mesures doivent être rapportées

    • Règle QER (Quality Enforcement Rule): contient des informations relatives à l’application QoS du trafic

    Le plan d’utilisateur multi-accès Junos ne prend pas en charge les règles d’action de mise en mémoire tampon (BAR).
  8. Le porteur par défaut est désormais actif et le trafic de données de l’abonné peut passer entre l’UE via l’eNodeB vers le SAEGW-you, puis le réseau central.

Flux de données de session CUPS

Une fois la session établie, le SAEGW-C n’est plus directement impliqué dans le flux de données. Les données circulent de l’UE en passant par l’eNodeB et le SAEGW-You, puis le réseau central. Voir figure 2.

Figure 2: Flux de données de session CUPS Session Data Flow CUPS
  1. L’UE envoie des données à l’eNodeB, qui encode les données en tant que paquet GTP-U et les envoie au PFE d’ancrage sur le SAEGW-U par l’interface S1-U.
  2. Le PFE d’ancrage du SAEGW-U effectue les actions suivantes:

    • Décape le paquet GTP-U.

    • Effectue la recherche de règles PCC pour appliquer QoS actions de reporting et de contrôle.

    • Il permet de faire avancer le paquet IPv4 décapant vers le réseau central sur l’interface SGi.

  3. Le SAEGW-U reçoit un paquet IPv4 de liaison descendante depuis le réseau central.
  4. Le PFE d’ancrage effectue les actions suivantes:

    • Effectue une recherche de règles PCC pour déterminer le tunnel GTP-U de porteur.

    • Application des QoS actions et des rapports.

    • Encapsule le paquet IPv4 dans GTP-U.

    • Il transporte le paquet GTP-U vers l’eNodeB, qui décape le paquet et les transporte vers l’UE.

  5. Le SAEGW-U crée également un rapport d’utilisation pour la session et l’envoie au SAEGW-C par l’interface Sxab.

Rapports de facturation et d’utilisation

Junos Multi Access User Plane prend en charge les rapports de facturation et d’utilisation conformément à l’architecture 3GPP TS 23.203, de contrôle des stratégies et de la facturation. Le plan d’utilisateur multi-accès Junos prend en charge les rapports d’utilisation suivants:

  • Seuil de volume uniquement

  • Quota de volume uniquement

  • Seuil de volume et quota de volume

Junos Multi Access User Plane utilise le processus suivant pour générer des rapports d’utilisation:

  1. Le SAEGW-U crée un groupe de notation pour chaque ours (par défaut ou dédié). Il est possible de créer des groupes de routage par flux de données de session (SDF) ou pour tout un porteur constitué de nombreuses SDF.
  2. Le SAEGW-C associe un ID de règle de reporting d’utilisation (URR) à un PDR et envoie l’ID d’URL sur l’interface Sx.
  3. Le SAEGW-U associe l’ID de l’URR à un groupe de notation.
  4. Le SAEGW-C indique également le type de rapport à générer pour l’ID de l’URR (seuil de volume uniquement, quota de volume uniquement, seuil de volume et quota).
  5. Lorsque le quota de volume est atteint, l’action par défaut consiste à abandonner tout le trafic pour le flux de données de session.
  6. Une fois la session d’abonné terminée, le SAEGW-U génère et envoie un rapport d’utilisation final au SAEGW-C.
    Remarque:

    Le SAEGW-U prend en charge les mesures de mise en pause pour tout ID d’URR où le SAEGW-C définit l’indicateur de mesure inactif de l’IE des informations de mesure de l’URR. Le SAEGW-U prend également en charge l’envoi de rapports immédiats au SAEGW-C sur une requête URR ou supprime la demande auprès du SAEGW-C ; le SAEGW-U envoie le rapport d’utilisation dans la réponse Modifier.

Pas de modification SGW ou SAEGW entre les eNodeBs

Depuis sa Junos OS 20.4R1, le plan d’utilisateur multi-accès Junos prend en charge la mobilité UE.

La Figure 3 montre l’ensemble du processus de transfert lorsqu’un commutateur UE d’un réseau d’eNodeB à un autre sans nécessiter de modification SGW ou SAEGW (c.-à-d. que les deux eNodeB sont servis par le même SGW). Il s’agit de la version la plus simple de la mobilité.

Figure 3: Pas de dos entre les NodeBs Handover between eNodeBs

Les étapes suivantes décrivent uniquement les interactions entre les fonctions du plan de contrôle et des fonctions du plan utilisateur de SGW et PGW (étapes 15-17 de la Figure 3).

Step 15: Target MME to Target SGW Modify Bearer Request

  1. SGW-C envoie une demande de modification de session Sx à MX SGW-U. Le message inclut les F-TEIDu (s) correspondant au nouvel eNodeB. Il peut également demander à MX SGW-you d’envoyer un message « end marker » vers le nouvel eNodeB.
  2. Si c’est le cas, le MX SGW-U envoie un message « end marker » sur l’interface S1-U en direction de l’ancien eNodeB pour tous les porteurs mentionnés par le message de modification de session Sx.
  3. MX SGW-U met à jour les E-TEID de liaison descendante dans le ou les(s) support(s) à F-TEIDu(s) reçus dans la demande de modification de session Sx.
  4. MX SGW-U envoie une réponse à la modification de session Sx à SGW-C

Step 16: Target SGW to PGW Modify Bearer Request

Remarque:

Cette étape n’affecte pas les attributions F-TEIDu pour l’un ou l’autre des porteurs de projets. Elle peut toutefois mettre à jour d’autres paramètres de forwarding et de facturation en fonction du nouvel emplacement de l’UE.

  1. PGW-C envoie une demande de modification de session Sx à MX PGW-U.

  2. MX PGW-U met à jour les ours correspondants et envoie une réponse à la modification de session Sx au PGW-C.

Over avec le changement SGW

Le modèle CUPS peut prendre en compte deux types de procédures impliquant une modification de la sgw:

  • Type 1: pendant le changement de SGW,un message de demande de session uniquement est envoyé de MME/SGSN à SGW-C.

  • Type 2: créez un message de demande de session suivi d’un message de demande de modification (Modify Bearer Request) envoyé par MME/SGSN à SGW-C pendant le changement SGW.

Pour le MX SGW-U, La principale différence entre ces deux types est que dans le premier cas, le nouveau SGW-C est fourni avec eNodeB et PGW F-TEIDu (s) dans Create Session Request, tandis que dans le second, les F-TEIDu (f-TEIDu) de l’eNodeB sont fournis dans la requête Modify Bearer, ce qui se traduit par un échange extra Sx Session Modify Request/Response exchange entre SGW-C et SGW-U. Étant donné que le type 1 peut être considéré comme un sous-ensemble de type 2, nous présentons ici le processus de passation de type 2.

La Figure 3 montre l’ensemble du processus de basculement lorsqu’un commutateur UE d’un eNodeB à un autre nécessite une modification SGW. Les étapes suivantes décrivent uniquement les interactions entre les fonctions du plan de contrôle et des fonctions du plan d’utilisateur de SGW et PGW (étapes 4,4a, 15-17 et 19 sur la figure 3).

Step 4: Target MME to Target SGW Create Session Request

  1. La SGW-C cible envoie une demande d’établissement de session Sx au MX SGW-U cible. Si le PGW-U est un nœud physique différent de la SGW-U cible, le message inclut le ou les F-TEIDu (s) du PGW-U pour chaque support de la session. Il n’inclut pas le ou les F-TEIDu (s) locaux car la MX SGW-U ne prend en charge que la fonction UP allouée F-TEIDu locale.
  2. Le MX SGW-U cible crée une nouvelle session et alloue les EDU locaux à tous les porteurs indiqués dans la demande d’établissement de session Sx. Si le message inclut les TEID F-TED de PGW-U, nous les utilisons pour configurer le ou les F-TEIDu (pairs) de liaison de liaison pour tous les ours référencés.
  3. Le MX SGW-U cible envoie un message de réponse à l’établissement de session Sx au SGW-C cible.

Step 15: Target MME to Target SGW Modify Bearer Request

  1. La SGW-C cible envoie une demande de modification de session Sx au MX SGW-U cible. Le message inclut les F-TEIDu (s) pour tous les porteurs correspondant au nouvel eNodeB.

  2. La MX SGW-U cible met à jour le peer F-TEID de liaison descendant dans le ou les(s) support(s) à F-TEIDu(s) reçus dans la demande de modification de session Sx.

  3. MX SGW-U envoie une réponse à la modification de session Sx à SGW-C.

Step 16: Target SGW to PGW Modify Bearer Request

  1. PGW-C envoie une demande de modification de session Sx à MX PGW-U. Le message inclut les F-TEIDu (s) de la SGW-U cible pour tous les porteurs. Il peut également demander à MX PGW-you d’envoyer un message « signet de fin ».

  2. Si vous êtes invité à le faire, le MX PGW-U envoie un message « end marker » en direction de l’ancienne SGW-U.

  3. MX PGW-U met à jour le peer F-TEID de liaison descendant pour tous les supportés du ou des F-TEIDu (s) reçus dans le message de demande de modification Sx

  4. MX PGW-U envoie une réponse à la modification de session Sx à la SGW-C cible.

Step 19: Source MME to Source SGW Delete Session Request

  1. La SGW-C source envoie une demande de suppression de session Sx à la MX SGW-U source.

  2. La MX SGW-U source supprime tous les ours et la session.

  3. La source MX SGW-U envoie la réponse Sx Session Delete à la SGW-C source.

Tableau d’historique des publication
Libération
Description
20.4R1
Depuis sa Junos OS 20.4R1, le plan d’utilisateur multi-accès Junos prend en charge la mobilité UE.