Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
AUF DIESER SEITE
 

CUPS-Sitzungserstellung und Datenfluss mit Junos Multi-Access-Benutzerebene

Mit der Einführung von CUPS ist es nützlich, um zu veranschaulichen, wie eine Endbenutzersitzung erstellt wird, wie Daten während der Sitzung fließen und wie die Sitzung mit der Junos Multi-Access-Benutzerebene beendet wird.

Erstellung von CUPS-Sitzungen

Hinweis:

Bevor eine CUPS-Sitzung erstellt werden kann, muss die Control Plane-Funktion (SAEGW-C, SGW-C, PGW-C) eine Sx-Assoziation mit der Benutzerebenenfunktion (SAEGW-U, SGW-U, PGW-U) erstellen. Die Steuerungsebene sendet eine Sx Association Setup Request-Nachricht, und die Benutzerebene antwortet mit einer Antwortnachricht zum Einrichten der Sx-Assoziation, um die Zuordnung zu erstellen. Sobald dies erledigt ist, kann die Steuerungsebene Sx-Sitzungen auf der Benutzerebene erstellen.

Wenn ein Endbenutzer auf das Netzwerk zugreifen möchte, muss eine CUPS-Sitzung erstellt werden. Abbildung 1 veranschaulicht diesen Prozess, sobald eine Sx-Assoziation zwischen einer SAEGW-C und einer SAEGW-U hergestellt wird.

Abbildung 1: Erstellung von CUPS-Sitzungen für SAEGW-C und SAEGW-U CUPS Session Creation for SAEGW-C and SAEGW-U
  1. Die Benutzerausrüstung (UE) sendet eine Attach Request an die eNodeB, die die Nachricht an die Mobility Management Entity (MME) weiterleitt. Die Anfrage enthält den APN.
  2. Das MME sendet eine Sitzungsanforderung erstellen an die SAEGW-C.
  3. Die SAEGW-C führt die folgenden Aktionen aus:

    • Validiert informationselemente, die in der Anforderung empfangen werden.

    • Validiert den vom Abonnenten angeforderten APN.

    • Sendet eine Sxab Session Establishment Request an die Routing-Engine (RE) der MX SAEGW-U.

    Hinweis:

    Die Sx-Sitzungseinrichtung ist die SAEGW-C, die die SAEGW-U-Steuerungsparameter über das Verhalten vorschreibt, wenn die SAEGW-U auf bestimmten Datenverkehr trifft. Die mindesten Steuerungsparameter für die Einrichtung der Sx-Sitzung sind eine Paketerkennungsregel (PDR) und eine Forwarding Action Rule (FAR). Die Einrichtung der Sx-Sitzung protokolliert effektiv im Abonnenten.
  4. Die RE der SAEGW-U führt die folgenden Aktionen aus:

    • Identifiziert die IP-Adresse für die Sitzung.

    • Wählt und ankert PFE für die Sitzung.

    • Weist die trägernden GTP-U-Tunnel-IDs zu.

    • Fügt die Sitzung der Anker-PFE hinzu.

    • Sendet eine Sxab Session Establishment Response zurück an die SAEGW-C.

  5. Die SAEGW-C sendet eine Sitzungsantwort erstellen zurück an die MME.
  6. Das MME sendet eine Attach Accept-Nachricht an die UE, die mit einer "Attach Complete"-Nachricht antwortet.
  7. Das MME sendet eine Änderungs-Anforderung an die SAEGW-C, die eine Sxab Session Modification Request an die RE auf der SAEGW-U sendet. Die RE aktualisiert die Sitzungs-IP-Adresse und die Tunnel-ID der eNodeB. Schließlich wird eine Änderungs-Bearer-Antwort zurück an die MME geroutet.
    Hinweis:

    Sx Session Modification Request ist die SAEGW-C, die SAEGW-you ansagert, um eine der folgenden vier Regeln zu ändern:

    • Packet Detection Rule (PDR): enthält Informationen, die beschreiben, welche Pakete welche Behandlung erhalten sollen (z. B. Weiterleitung und andere Arten der Durchsetzung)

    • Forwarding Action Rule (FAR): enthält Informationen darüber, ob das Weiterleiten, Ablegen oder Puffern auf ein Paket angewendet wird.

    • Nutzungsberichtsregel (URR): enthält Informationen, die eine bestimmte Messung definieren, die für den Datenverkehr des Benutzers und wie diese Messung gemeldet werden soll

    • Quality Enforcement Rule (QER): enthält Informationen zur QoS-Durchsetzung des Datenverkehrs

    Junos Multi-Access-Benutzerebene unterstützt keine Pufferaktionsregeln (Buffering Action Rules, BARs).
  8. Der Standard-Bearer ist jetzt aktiv und der Abonnentendatenverkehr kann zwischen der UE durch die eNodeB hin und her zum SAEGW-you und dann zum Core-Netzwerk geleitet werden.

CUPS Sitzungsdatenfluss

Sobald die Sitzung eingerichtet ist, ist die SAEGW-C nicht mehr direkt an den Datenfluss beteiligt. Die Daten fließen direkt von der UE über die eNodeB hin und her zum SAEGW-you und dann in das Core-Netzwerk. Siehe Abbildung 2.

Abbildung 2: CUPS Session Data Flow CUPS Session Data Flow
  1. Die UE sendet Daten an die eNodeB, die die Daten als GTP-U-Paket codiert und über die S1-U-Schnittstelle an den Anker PFE auf der SAEGW-U weiterleitt.
  2. Der AnkerPFE der SAEGW-U führt die folgenden Aktionen aus:

    • Entkapselt das GTP-U-Paket.

    • Führt PCC-Regelsuche aus, um QoS- und Berichtsaktionen anzuwenden.

    • Leitet das entkapselte IPv4-Paket über die SGi-Schnittstelle an das Core-Netzwerk weiter.

  3. Die SAEGW-U empfängt ein Downlink-IPv4-Paket vom Core-Netzwerk.
  4. Die Ankerpfe führt die folgenden Aktionen aus:

    • Führt eine PCC-Regelsuche aus, um den Träger-GTP-U-Tunnel zu bestimmen.

    • Wendet QoS- und Berichtsaktionen an.

    • Verkapselt das IPv4-Paket in GTP-U.

    • Leitet das GTP-U-Paket an die eNodeB weiter, die das Paket entkapselt und an die UE weiterleitt.

  5. Die SAEGW-U erstellt auch einen Nutzungsbericht für die Sitzung und sendet den Bericht über die Sxab-Schnittstelle an die SAEGW-C.

Lade- und Nutzungsberichte

Junos Multi Access User Plane unterstützt Lade- und Nutzungsberichte gemäß 3GPP TS 23.203, Richtlinie und Ladesteuerungsarchitektur. Junos Multi Access-Benutzerebene unterstützt die folgenden Nutzungsberichte:

  • Nur Volumenschwellenwert

  • Nur Volumenkontingent

  • Volumenschwellenwert und Volumenkontingent

Junos Multi Access-Benutzerebene verwendet den folgenden Prozess, um Nutzungsberichte zu erstellen:

  1. Die SAEGW-U erstellt für jeden Träger (Standard oder dedizierte) eine Bewertungsgruppe. Routing-Gruppen können pro Session Data Flow (SDF) oder für einen ganzen Träger aus vielen SDFs erstellt werden.
  2. Die SAEGW-C ordnet eine Nutzungsberichtsregel-ID (URR) einem PDR zu und sendet die URR-ID über die Sx-Schnittstelle.
  3. Die SAEGW-U ordnet die URR-ID einer Bewertungsgruppe zu.
  4. Die SAEGW-C meldet auch, welche Art von Bericht für die URR-ID generiert werden muss (nur Volumenschwellenwert, nur Volumenkontingent, Volumenschwellenwert und Kontingent).
  5. Die Standardaktion, wenn das Volumenkontingent erreicht ist, besteht darin, den gesamten Datenverkehr für den Sitzungsdatenfluss zu löschen.
  6. Wenn die Abonnentensitzung endet, generiert die SAEGW-U einen endgültigen Nutzungsbericht und sendet ihn an die SAEGW-C.
    Hinweis:

    Die SAEGW-U unterstützt die Unterbrechung von Lademessungen für jede URR-ID, bei der die SAEGW-C die Inaktive Messflagge der Measurement Information IE des URR setzt. Die SAEGW-U unterstützt auch das Senden sofortiger Berichte an die SAEGW-C über eine URR-Abfrage oder eine Entfernungsanfrage von der SAEGW-C; sendet die SAEGW-U den Nutzungsbericht in der Antwort ändern.

Übergabe zwischen eNodeBs und keine SGW- oder SAEGW-Änderung

Ab Junos OS 20.4R1 unterstützt die Junos Multi Access-Benutzerebene UE-Mobilität.

Abbildung 3 zeigt den gesamten Übergabeprozess, wenn ein UE von einem eNodeB zu einem anderen wechselt, ohne dass eine SGW- oder SAEGW-Änderung erforderlich ist (d. h. beide eNodeBs werden von derselben SGW bedient). Dies ist die einfachste Version der Mobilitätsübergabe.

Abbildung 3: Übergabe zwischen eNodeBs Handover between eNodeBs

In den folgenden Schritten werden nur die Interaktionen zwischen der Steuerungsebene und den Funktionen der Benutzerebene von SGW und PGW beschrieben (Schritte 15-17 in Abbildung 3).

Step 15: Target MME to Target SGW Modify Bearer Request

  1. SGW-C sendet Anfrage zur Änderung der Sx-Sitzung an MX SGW-U. Die Nachricht enthält F-TEIDus entsprechend der neuen eNodeB. Es kann auch MX SGW-You anweisen, eine "Endmarker"-Nachricht an die neue eNodeB zu senden.
  2. Wenn Sie dazu aufgefordert werden, sendet MX SGW-U eine "Endmarker"-Nachricht auf der S1-U-Schnittstelle in Richtung der alten eNodeB für alle Träger, auf die durch die Sx Session Modification Message verwiesen wird.
  3. MX SGW-U aktualisiert Downlink Peer F-TEID in den Trägern zu F-TEIDus, die in der Änderungsanfrage für Sx Session erhalten wurden.
  4. MX SGW-U sendet Sx Session Modification Response an SGW-C

Step 16: Target SGW to PGW Modify Bearer Request

Hinweis:

Dieser Schritt hat keine Auswirkungen auf F-TEIDu-Zuweisungen auf einen der Träger. Es kann jedoch andere Weiterleitungs- und Ladeparameter basierend auf dem neuen Standort der UE aktualisieren.

  1. PGW-C sendet Anfrage zur Änderung der Sx-Sitzung an MX PGW-U.

  2. MX PGW-U aktualisiert die entsprechenden Träger und sendet Sx Session Modification Response an PGW-C.

Übergabe mit SGW-Änderung

In Anbetracht des CUPS-Modells gibt es zwei Arten von Verfahren, die eine SGW-Änderung beinhalten:

  • Type 1: Während der Änderung der SGW wird nur die Nachricht "Session Request erstellen" von MME/SGSN an SGW-C gesendet.

  • Type 2: Session Request-Nachricht erstellen, gefolgt von Der Anforderung ändern wird während der SGW-Änderung von MME/SGSN an SGW-C gesendet.

Für MX SGW-U besteht der Hauptunterschied zwischen diesen beiden Typen darin, dass in der ersten die neue SGW-C sowohl mit eNodeB als auch mit PGW F-TEIDu(s) innerhalb der Sitzungsanfrage bereitgestellt wird, während im zweiten die F-TEIDus der eNodeB in der Anfrage für Den Träger geändert werden, was zu einem zusätzlichen Sx Session Modify Request/Response-Austausch zwischen SGW-C und SGW-U übersetzt wird. Da Typ 1 als Teilmenge von Typ 2 betrachtet werden kann, stellen wir hier den Prozess für die Typ-2-Übergabe vor.

Abbildung 3 zeigt den gesamten Übergabeprozess, wenn ein UE von einem eNodeB zum anderen wechselt und eine SGW-Änderung erfordert. In den folgenden Schritten werden nur die Interaktionen zwischen der Steuerungsebene und den Funktionen der Benutzerebene von SGW und PGW beschrieben (Schritte 4,4a, 15-17 und 19 in Abbildung 3).

Step 4: Target MME to Target SGW Create Session Request

  1. Die Ziel-SGW-C sendet Sx Session Establishment Request an das Ziel MX SGW-U. Wenn PGW-U ein anderer physischer Knoten als der Ziel-SGW-U ist, enthält die Nachricht F-TEIDu(s) der PGW-U für jeden Träger der Sitzung. Es umfasst nicht lokale F-TEIDu(s), da MX SGW-U nur up-Funktion zugewiesene lokale F-TEIDu unterstützt.
  2. Das Ziel MX SGW-U erstellt eine neue Sitzung und weist lokale F-TEIDus für alle Träger zu, die in der Anfrage für die Einrichtung von Sx-Sitzungen angegeben sind. Wenn die Nachricht F-TEIDs von PGW-U enthält, verwenden wir diese, um Uplink-Peer F-TEIDus für alle Träger einzurichten, auf die verwiesen wird.
  3. Die Ziel-MX-SGW-U sendet eine Sx Session Establishment Response-Nachricht an die Ziel-SGW-C.

Step 15: Target MME to Target SGW Modify Bearer Request

  1. Die Ziel-SGW-C sendet die Anfrage zur Änderung der Sx-Sitzung an das Ziel MX SGW-U. Die Nachricht enthält F-TEIDus für alle Träger, die der neuen eNodeB entsprechen.

  2. Das Ziel MX SGW-U aktualisiert Downlink Peer F-TEID in den Trägern zu F-TEIDus, die in der Änderungsanfrage für Sx Session erhalten wurden.

  3. MX SGW-U sendet Sx Session Modification Response an SGW-C.

Step 16: Target SGW to PGW Modify Bearer Request

  1. PGW-C sendet Anfrage zur Änderung der Sx-Sitzung an MX PGW-U. Die Nachricht enthält F-TEIDus des Ziels SGW-U für alle Träger. Es kann auch MX PGW-You anweisen, eine "Endmarker"-Nachricht zu senden.

  2. Wenn sie dazu aufgefordert wird, sendet MX PGW-U eine "Endmarker"-Nachricht an die alte SGW-U.

  3. MX PGW-U aktualisiert Downlink Peer F-TEID für alle Träger, auf die in der Sx-Änderungsanfragenachricht an F-TEIDu(n) verwiesen wird

  4. MX PGW-U sendet Sx Session Modification Response an das Ziel SGW-C.

Step 19: Source MME to Source SGW Delete Session Request

  1. Quelle SGW-C sendet Sx Session Delete Request an die Quelle MX SGW-U.

  2. Quelle MX SGW-U löscht alle Träger und die Sitzung.

  3. Quelle MX SGW-U sendet Sx Session Delete Response an die Quelle SGW-C.

Tabelle "Versionshistorie"
Release
Beschreibung
20.4R1
Ab Junos OS 20.4R1 unterstützt die Junos Multi Access-Benutzerebene UE-Mobilität.