Contrôle de limite de mise en mémoire tampon CUPS FAR au niveau de la fonction du plan utilisateur

Introduction

Ce document décrit le concept, la mise en oeuvre et les avantages de la fonctionnalité de limite de mise en mémoire tampon FAR disponible dans le produit Cisco CUPS.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Mobilité LTE (Long Term Evolution)
• Architecture CUPS (Control Plane and User Plane Functions)

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Environnement

Environnement

Concept de base des FAR

La règle FAR (Forwarding Action Rule) dicte l'action que la fonction User Plane (Serving Gateway (SGW)-U ou PDN Gateway (PGW)-U) doit effectuer pour les paquets qui correspondent à une règle de détection de paquet (PDR) correspondante. Les actions possibles spécifiées dans un FAR sont les suivantes :

• Transférer le paquet vers une destination spécifiée (par exemple, Internet/PDN (Packet Data Network) ou eNodeB)
• Supprimer le paquet
• Dupliquer le paquet (utilisé dans l'interception légale ou pour la mise en miroir du trafic)
• Mettre le paquet en mémoire tampon, auquel cas une règle d’action de mise en mémoire tampon associée peut spécifier les paramètres de mise en mémoire tampon et notifier la fonction du plan de contrôle 

Le FAR permet essentiellement au plan de contrôle de gérer à distance et de manière dynamique le flux de trafic du plan utilisateur et l'application des politiques, ce qui est essentiel pour les avantages de flexibilité et d'évolutivité de l'architecture CUPS.

Informations générales

Lorsqu'un équipement utilisateur (UE) passe à l'état inactif, l'entité de gestion de la mobilité (MME) envoie une demande de support d'accès de libération à SGW-C afin de libérer tous les supports S1-U pour l'UE. En même temps, SGW-C informe le SGW-U de supprimer tous les paquets de liaison descendante et de mettre à jour les états du support en état d'inactivité tandis que la fonction du plan d'utilisateur commence à mettre en mémoire tampon les données de liaison descendante à une certaine limite par défaut.

Une fois que tous les plans utilisateur ont répondu, le plan de contrôle met à jour le contexte de l'abonné et informe le MME que les supports ont été libérés. Cette procédure garantit que toutes les ressources consommées nécessaires sont libérées pendant l'inactivité de l'abonné. Ce mécanisme permet de gérer efficacement les transitions d'état UE et l'utilisation des ressources dans le réseau.

Description du problème

Dans un scénario normal, chaque fois qu'un UE passe à l'état inactif, la fonction du plan utilisateur commence à mettre en mémoire tampon les données de liaison descendante. Par défaut, sur la plate-forme CUPS, jusqu'à cinq paquets sont mis en mémoire tampon par FAR. Dès réception du premier paquet de données de liaison descendante sur le SGW-U, le SGW-C envoie une demande de notification de données de liaison descendante (DDN) au MME afin de commencer à appeler l'UE pour vérifier sa disponibilité afin d'accepter le trafic de liaison descendante (DL). En cas de succès de la radiomessagerie, MME envoie une requête Modify Bearer à SGW-C qui informe le SGW-U de supprimer la mémoire tampon des paquets de données déjà dans sa file d'attente et de commencer à transférer les paquets DL comme précédemment.

Dans le cas où, pour une raison quelconque, si MME n'est pas en mesure d'appeler UE ou si MME n'a pas pu obtenir une réponse de réussite de pagination de UE avant que ce seuil de limite de mémoire tampon de cinq paquets sur le SGW-U soit atteint, vous pouvez voir une augmentation du dépassement de capacité de la mémoire tampon DDN abandonner des paquets dans la direction de liaison descendante. Cela peut entraîner une dégradation potentielle de la qualité du service de données mobiles pour les utilisateurs finaux, ce qui peut affecter les performances globales du réseau et l'expérience utilisateur.

Flux d'appels du scénario de réussite DDN

Flux d'appels du scénario de réussite DDN

1. MME envoie une demande de libération de porteuse d'accès à SGW-C afin de libérer les identificateurs de point d'extrémité de tunnel (TEID) distants de liaison descendante de toutes les porteuses pour cet UE.
2. Lors de l'arrivée de la demande de support d'accès de libération, SGW-C en informe SGW-U en mettant à jour FAR avec l'action d'application comme tampon dans la demande de modification de six pour tous les PDN.
3. SGW-U envoie une réponse de modification Sx après l'application de la mise en mémoire tampon dans SGW-U pour le PDN correspondant.
4. SGW-C envoie une réponse Release Access Bearer à MME.
5. Les premières données de liaison descendante arrivant dans SGW-U déclenchent une demande de rapport Sx (avec le type de rapport Rapport de données de liaison descendante) vers SGW-C.
6. À l'arrivée du message de demande de rapport Sx, le SGW-C lance un message de demande DDN vers MME.
7. SGW-C envoie un message de réponse de rapport Sx vers SGW-U.
8. Si MME est en mesure d'envoyer une requête de radiomessagerie vers UE, il définit la cause comme 'Requête acceptée' dans le message d'accusé de réception DDN et l'envoie à SGW-C.
9. En cas de pagination réussie, MME envoie une requête Modify Bearer au S-GW avec des TEID eNodeB qui configure la connexion S1-U au SGW.
10. SGW-C envoie à SGW-U une demande de modification Sx avec une mise à jour de FAR pour les nouvelles informations TEID. SGW-U peut maintenant transférer toutes les données mises en mémoire tampon à UE via eNodeB.
11. SGW-U envoie une réponse de modification Sx à SGW-C.

Flux d'appels du scénario d'échec DDN

Flux d'appels du scénario d'échec DDN

1. MME envoie une demande de libération de porteuse d'accès à SGW-C afin de libérer les TEID distants de liaison descendante de toutes les porteuses pour cet UE.
2. Lors de l'arrivée de la demande de support d'accès de libération, SGW-C en informe SGW-U en mettant à jour FAR avec l'action d'application comme tampon dans la demande de modification de six pour tous les PDN.
3. SGW-U envoie une réponse de modification Sx après l'application de la mise en mémoire tampon dans SGW-U pour le PDN correspondant.
4. SGW-C envoie une réponse Release Access Bearer à MME.
5. Les premières données de liaison descendante arrivant dans SGW-U déclenchent une demande de rapport Sx (avec le type de rapport Rapport de données de liaison descendante) vers SGW-C.
6. À l'arrivée du message de demande de rapport Sx, le SGW-C lance un message de demande DDN vers MME.
7. SGW-C envoie un message de réponse de rapport Sx vers SGW-U.
8. Si MME ne parvient pas à appeler UE, il peut rejeter la requête DDN avec la cause appropriée.

ou
Si MME accepte la requête DDN, il envoie ultérieurement une indication DDN Failure afin d'indiquer à SGW-C que l'UE n'a pas répondu à la radiomessagerie.

9. SGW-C a reçu une défaillance DDN et, par conséquent, afin d'arrêter immédiatement l'envoi du DDN suivant, SGW-C démarre le minuteur de défaillance DDN. SGW-C envoie l'indicateur DROBU (Sx Modification Request with Drop Buffered) afin d'éliminer les paquets mis en mémoire tampon et l'option Apply Action en tant que « drop » afin d'éliminer les paquets suivants.
10. SGW-U envoie une réponse de modification Sx à SGW-C.
11. Lors de l'expiration du temporisateur d'échec DDN, SGW-C lance la modification Sx avec l'action Appliquer comme tampon afin de recommencer la mise en mémoire tampon.
12. Les étapes suivantes se poursuivent à partir de l'étape 3. dans le flux d'appels Scénario de réussite DDN.

Présentation de la solution

Le nombre de paquets mis en mémoire tampon par FAR sur le plan utilisateur est configurable sur le plan de contrôle Cisco CUPS. Ainsi, vous pouvez dépasser cette limite de cinq paquets de mémoire tampon grâce à une limite de mémoire tampon CLI far-max-packets <num> disponible sous le sous-système Active Charging Service (ACS). L'opérateur peut décider d'une valeur comprise entre 1 et 128 afin de contrôler la limite de tampon FAR en fonction de son modèle d'appel afin d'optimiser la qualité de service (QoS) et de réduire les abandons de paquets, améliorant ainsi l'expérience de l'UE et améliorant les performances globales du réseau.

Configuration

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

Vérification

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 

Comparez le compteur « DDN buffer overflow drop packets » avec la valeur par défaut buffering-limit far-max-packets (qui est cinq) à une autre valeur supérieure à cinq avec la même saveur et la même durée de modèle d'appel. Vous devez voir une diminution dans ce compteur lorsque la valeur est supérieure à cinq.

Informations connexes

• 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

• Assistance technique de Cisco et téléchargements