CUPS FAR-Puffer-Grenzsteuerung auf Benutzerebene

Einleitung

Dieses Dokument beschreibt das Konzept, die Implementierung und die Vorteile der Funktion FAR Buffering Limit, die im Cisco CUPS-Produkt verfügbar ist.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• LTE-Mobilität (Long Term Evolution)
• CUPS-Architektur (Control Plane and User Plane Functions)

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Umwelt

Umwelt

Grundkonzept der FAR

Die Weiterleitungsaktionsregel (Forwarding Action Rule, FAR) bestimmt die Aktion, die die Benutzerebenenfunktion (Serving Gateway (SGW)-U oder PDN Gateway (PGW)-U) für Pakete durchführen muss, die einer entsprechenden Paketerkennungsregel (Packet Detection Rule, PDR) entsprechen. Zu den möglichen Maßnahmen, die in einer FAR festgelegt werden, gehören:

• Leitet das Paket an ein angegebenes Ziel weiter (z. B. an das Internet/Packet Data Network (PDN) oder den eNodeB)
• Paket verwerfen
• Duplizieren Sie das Paket (wird für rechtmäßiges Abfangen oder für Datenverkehrsspiegelung verwendet).
• Puffern des Pakets; in diesem Fall kann eine zugeordnete Pufferungsaktionsregel Parameter für die Pufferung und Benachrichtigung der Kontrollebenenfunktion angeben 

Im Wesentlichen ermöglicht die FAR der Kontrollebene das Remote- und dynamische Management des Datenverkehrsflusses und der Richtliniendurchsetzung auf Benutzerebene. Dies ist ein entscheidender Faktor für die Flexibilität und Skalierbarkeit der CUPS-Architektur.

Hintergrundinformationen

Wenn ein User Equipment (UE) in den Leerlaufzustand wechselt, sendet die Mobility Management Entity (MME) eine Anforderung für den Release Access Bearer an SGW-C, um alle S1-U Bearer für das UE freizugeben. Gleichzeitig informiert SGW-C das SGW-U, dass alle Downlink-Pakete verworfen und die Trägerstatus auf Inaktivität aktualisiert werden, während die Benutzerebenenfunktion standardmäßig Downlink-Daten bis zu einem bestimmten Grenzwert puffert.

Nachdem alle Benutzerebenen reagiert haben, aktualisiert die Kontrollebene den Teilnehmerkontext und informiert die MME, dass die Träger freigegeben wurden. Mit diesem Verfahren wird sichergestellt, dass alle erforderlichen belegten Ressourcen während der Abonnenten-Inaktivität freigegeben werden. Dieser Mechanismus hilft bei der effizienten Verwaltung von EU-Zustandsübergängen und der Ressourcenauslastung im Netzwerk.

Problembeschreibung

In einem normalen Szenario beginnt die Benutzerebenenfunktion immer dann, wenn ein UE in den Leerlaufzustand wechselt, Downlink-Daten zu puffern. Standardmäßig werden auf der CUPS-Plattform bis zu fünf Pakete pro FAR gepuffert. Nach Empfang des ersten Downlink-Datenpakets auf dem SGW-U sendet der SGW-C eine Downlink Data Notification (DDN)-Anforderung an MME, um das Paging des UE zu starten und dessen Verfügbarkeit zur Annahme des Downlink (DL)-Datenverkehrs zu überprüfen. Bei erfolgreichem Paging sendet MME eine "Modify Bearer Request" (Trägeränderungsanforderung) an SGW-C, die den SGW-U darüber informiert, dass er Datenpakete, die sich bereits in der Warteschlange befinden, aus dem Puffer entfernt und mit der Weiterleitung von DL-Paketen beginnt.

Falls MME aus irgendeinem Grund keine UE-Paging-Anfrage senden kann oder MME vor dem Erreichen dieses Grenzwerts für fünf Paketpuffer auf dem SGW-U keine erfolgreiche Paging-Antwort von UE erhalten konnte, können Sie eine Zunahme der DDN-Pufferüberlauf-Drop-Pakete in Downlink-Richtung beobachten. Dies kann zu einer potenziellen Verschlechterung der Qualität mobiler Datenservices für Endbenutzer führen und sich möglicherweise auf die Netzwerkleistung und das Anwendererlebnis insgesamt auswirken.

DDN-Erfolgsszenario - Anruffluss

DDN-Erfolgsszenario - Anruffluss

1. MME sendet eine Release Access Bearer-Anforderung an SGW-C, um Downlink Remote Tunnel Endpoint Identifiers (TEIDs) aller Träger für diese UE freizugeben.
2. Bei Eingang der Anforderung des Release Access Bearer informiert SGW-C das gleiche über SGW-U, indem FAR aktualisiert wird, wobei die Anwenden-Aktion als Puffer in Sx Modification Request für alle PDNs erfolgt.
3. SGW-U sendet Sx-Modification-Antwort nach Anwendung der Pufferung in SGW-U für die entsprechende PDN.
4. Der SGW-C sendet eine Release Access Bearer-Antwort an MME.
5. Die ersten Downlink-Daten, die im SGW-U eingehen, lösen eine Sx-Berichtsanforderung (mit dem Berichtstyp "Downlink Data Report") an den SGW-C aus.
6. Bei Eintreffen der Sx Report Request-Nachricht initiiert der SGW-C eine DDN-Anforderungsnachricht an MME.
7. SGW-C sendet Sx Report Response-Nachricht an SGW-U.
8. Wenn MME in der Lage ist, eine Paging-Anforderung an UE zu senden, wird die Ursache in der DDN-Bestätigungsmeldung als "Request Accepted" festgelegt und an SGW-C gesendet.
9. Bei erfolgreichem Paging sendet MME eine Modify Bearer-Anforderung an das S-GW mit eNodeB TEIDs, die die S1-U-Verbindung am SGW einrichten.
10. SGW-C sendet Sx-Modification-Request mit aktualisierter FAR für neue TEID-Informationen an SGW-U. Der SGW-U kann nun alle gepufferten Daten über eNodeB an UE weiterleiten.
11. SGW-U sendet Antwort "Sx Modification" an SGW-C.

DDN-Fehlerszenario Anrufablauf

DDN-Fehlerszenario Anrufablauf

1. MME sendet eine Release Access Bearer-Anforderung an SGW-C, um Downlink-Remote-TEIDs aller Träger für diese UE freizugeben.
2. Bei Eintreffen der Release Access Bearer-Anforderung informiert SGW-C SGW-U das Gleiche, indem FAR mit Apply Action als Puffer in Sx Modification Request für alle PDNs aktualisiert wird.
3. SGW-U sendet Sx-Modification-Antwort nach Anwendung der Pufferung in SGW-U für die entsprechende PDN.
4. Der SGW-C sendet eine Release Access Bearer-Antwort an MME.
5. Die ersten Downlink-Daten, die im SGW-U eingehen, lösen eine Sx-Berichtsanforderung (mit dem Berichtstyp "Downlink Data Report") an den SGW-C aus.
6. Bei Eintreffen der Sx Report Request-Nachricht initiiert der SGW-C eine DDN-Anforderungsnachricht an MME.
7. SGW-C sendet Sx Report Response-Nachricht an SGW-U.
8. Wenn die MME den Paging-Vorgang für UE nicht ausführen kann, kann sie die DDN-Anforderung mit der relevanten Ursache ablehnen.

Oder
Wenn MME eine DDN-Anforderung akzeptiert, sendet sie später eine DDN-Fehleranzeige, um SGW-C anzuzeigen, dass UE nicht auf Paging reagiert hat.

9. Der SGW-C hat einen DDN-Fehler empfangen. Um daher das Senden des nächsten DDN sofort zu beenden, startet der SGW-C den DDN Failure Timer. Der SGW-C sendet eine Sx-Modifizierungsanforderung mit Drop Buffered (DROBU)-Markierung, um gepufferte Pakete zu verwerfen, und Apply Action as 'drop' (Aktion als 'Drop' anwenden, um die nachfolgenden Pakete zu verwerfen).
10. SGW-U sendet Antwort auf sechs Änderungen an SGW-C.
11. Nach Ablauf des DDN-Fehler-Timers initiiert SGW-C die Sx-Änderung mit "Aktion anwenden" als Puffer, um die Pufferung erneut zu starten.
12. Die weiteren Schritte werden mit Schritt 3 im Anruffluss für das DDN-Erfolgsszenario fortgesetzt.

Lösungsüberblick

Die Anzahl der Pakete, die pro FAR auf der Benutzerebene gepuffert werden, kann auf der Cisco CUPS-Kontrollebene konfiguriert werden. Sie können diese Puffergrenze von fünf Paketen durch eine CLI-Puffergrenze überwinden, die im ACS-Subsystem (Active Charging Service) für far-max-Pakete zur Verfügung steht. Der Betreiber kann einen beliebigen Wert im Bereich von 1 bis 128 festlegen, um die FAR-Puffergrenze in Abhängigkeit von seinem Anrufmodell zu steuern und so die Quality of Service (QoS) zu optimieren und Paketverluste zu reduzieren. Dies verbessert die UE-Erfahrung und die Netzwerkleistung insgesamt.

Konfiguration

local]hostname# configure

[local]hostname(config)# active-charging service ecs

[local]hostname(config-acs)# buffering-limit far-max-packets <num>

[local]hostname(config-acs)# end

[local]hostname#

[local]hostname# push config-to-up all

Verifizierung

show user-plane-service statistics drop-counter 
	Packet Drop Data Statistics:
	-----------------------------------------------
	NAT packets processing failure:
	    NAT on demand handling:                 0
	    IP allocation is in progress:           0
	    ICMP Packet translation:                0
	    Invalid Callid:                         0
	    Invalid Header:                         0
	    ICMP Payload Parse Failure:             0
	FIREWALL packets processing failure:
	    Policy not found:                       0
	No Matching GX rule found:                  32362
	Flow apply action:
	    Discard:                                0
	    Readdress Failure:                      0
	    Redirect-URL:                           0
	Packet exceeds the MTU size:                1007742185
	Failure in processing FAR Buffer packets:   21
	FAR Apply Action Drop:                      28792512
	Traffic Steering Failure:                   0
	QER Gate Status Closed:                     0
	Content-filtering Discard Action:           0
	IP Header Validation Failed:                6020295
	ADF level failure:
	    UL TEID/QFI key mismatch:               0
	    DL TFT mismatch:                        0
	    DL QFI mismatch:                        0
	URL Blacklisting Discard Action:            0
	DDN buffer overflow drop packets:           11 
	APN AMBR Packets Drop:                      5
	ITC Packets Drop:                           263040006
	ACL Drop:                                   31149173
	CC Dropped Packets:                         1513522
	FastPath Misc Drops:
	    Overload Protection:                    0
	    Invalid Client:                         0
	    Stream ID 0:                            0
	    Invalid Stream ID:                      145
	OHR Mismatch Packet Drops:                  7091753 

Vergleichen Sie den Zähler "DDN buffer overflow drop packages" mit dem Standardwert "buffering-limit far-max-packages" (fünf) im Vergleich zu einem anderen Wert, der höher als fünf ist und dieselbe Anrufmodell-Variante und -dauer aufweist. Wenn der Wert größer als fünf ist, muss dieser Leistungsindikator verringert werden.

Zugehörige Informationen

• https://www.cisco.com/c/en/us/td/docs/wireless/upc/21-28/cups-cp-admin/21-28-upc-cups-cp-admin-guide/m_saegw-idle-buffering.html

• Technischer Support und Downloads von Cisco