Fonctionnalités de protection contre la surcharge ASR5x00 MME

Introduction

Ce document présente les différentes méthodes et fonctions de protection contre la surcharge des entités de gestion de la mobilité (MME) disponibles sur la gamme Cisco Aggregation Services Router (ASR) 5000. Dans la gamme ASR 5000, Cisco donne au client différents moyens de contrôler et cet article explique les fonctionnalités et les commandes CLI associées.

Protection MME

Protection contre la surcharge du réseau : Limitation du taux d'attachement

La limitation du débit d'attachement protège les éléments réseau voisins tels que le serveur d'abonné domestique (HSS), la fonction PCRF (Policy and Charging Rules Function) et le serveur de facturation en ligne (OCS), ainsi que les ressources MME internes telles que imsimgr et sessmgr. La limitation du taux d'attachement traite les nouveaux appels qui arrivent à imsimgr, tels que les Attaches et la mise à jour de la zone de suivi (TAU) inter-MME/Serving GPRS Support Node (SGSN).

Cette image montre le flux de messages pour les appels et la limitation des files d'attente.

Afin de protéger MME (imsimgr et sessmgr à partir de), le taux de limitation, le temps d'attente de file d'attente et le temps de taille de file d'attente doivent être définis. Le taux de limitation dépend du modèle d'appel MME, car la capacité MME dépend du modèle d'appel.

Pour MME, le calcul du taux de limitation est relativement simple, prenez le CEPS (Call Events Per Second) standard dans le réseau plus la tolérance.  Vous devrez peut-être également tenir compte de la capacité de la base de données HSS si une protection HSS est nécessaire.

Exemple

En heures de pointe, MME gère jusqu'à 170 à 200 appels par seconde (Attaches+ Inter TAU). En cas de défaillance d'un site, jusqu'à 350 à 370 appels par seconde peuvent arriver à un MME. Sous ce taux d'appel, l'utilisation de MME augmente de près de 80 % et 400 appels par seconde est un niveau optimal pour limiter le taux de limitation afin d'éviter une charge de signalisation excessive dans la zone MME.

La durée d'attente par défaut de la file d'attente est de 5 secondes. Elle est optimale pour le CLIENT. La taille de la file d'attente par défaut est 2 500. Elle est optimale pour le CLIENT.

La commande de configuration est la suivante.

asr5k(config)#network-overload-protection mme-new-connections-per-second
 new_connections action attach { drop | reject-with-emm-cause
 { congestion | network-failure | no-suitable-cell-in-tracking-area}
 tau { drop | reject-with-emm-cause { congestion | network-failure
 | no-suitable-cells-in-tracking-area | no-sec-ctxt-in-nw} fwd-reloc
 { drop | reject} }{wait-time  <wait-time>} {queue-size <queue-size>}

nouvelles_connexions
Définit le nombre de nouvelles connexions MME à accepter par seconde. Doit être un entier compris entre 50 et 5000. Il est défini par défaut à 500.

action
Définit l'action à effectuer lorsque la file d'attente de traitement devient pleine. Chaque fois que de nouvelles connexions sont reçues au MME, elles sont mises en file d'attente dans la file d'attente de traitement et imsimgr traite les messages de la file d'attente au débit configuré. Lorsque la file d'attente déborde (en raison d'un taux d'entrée élevé), en fonction de l'« action » configurée, les paquets sont abandonnés ou rejetés.

queue-size
Définit la taille maximale de la file d'attente de mise en mémoire tampon utilisée pour mettre les paquets en mémoire tampon. Doit être un entier compris entre 250 et 25 000. Il est défini par défaut à 2500.

Exemple de configuration

network-overload-protection mme-new-connections-per-second 400 action attach
  reject-with-emm-cause no-suitable-cell-in-tracking-area tau
 reject-with-emm-cause no-suitable-cell-in-tracking-area fwd-reloc drop 

Maintenant, le taux d'appel par seconde est défini sur 400 et l'action est un rejet intelligent avec la cause 15 pour rendre l'équipement utilisateur (UE) reconnecté à différentes technologies d'accès radio (RAT). La durée d'attente est définie sur la valeur par défaut (5 secondes) et la taille de la file d'attente est de 2 500.

Note: L'action « rejeter » avec la cause EMM #15 « aucune cellule appropriée dans la zone de suivi » est préférée, car les appels rejetés avec #15 ne reviendront généralement pas à MME et iront à différentes couches RAT (3G, 2G). L'action « Abandonner » pour le déplacement du sous-système de réseau radio de service (SRNS) est destinée à une utilisation future et évitera une réassociation rapide au MME après le rejet.

Protection contre la surcharge du réseau : Limitation de pagination

Paging Throttling protège les ressources MME internes (mmemgr) en tant que ressources eNodeB/radio (si nécessaire). Ce seuil limite de débit doit être applicable à tous les eNodeB associés à MME pour un châssis ASR 5000 donné. Les demandes de radiomessagerie S1 adressées à un eNodeB doivent être limitées à ce taux à cette valeur seuil. Les requêtes de radiomessagerie S1 adressées à un eNodeB qui dépassent ce seuil sont abandonnées.

Pour MME, le calcul du débit de régulation est relativement simple, prenez le taux de pagination de sortie standard dans le réseau plus la tolérance. (Ceci est basé uniquement sur la décision de l'équipe de conception.)

Exemple

En heures de pointe, chaque MME gère jusqu'à 35 000 messages de radiomessagerie par seconde. En cas de défaillance d'un site, jusqu'à 70 000 pages par seconde peuvent passer d'un MME. Sous ce taux de pagination, l'utilisation MME (mmemgr) augmente de près de 80% et 70000 à 80000 pages par seconde serait un niveau optimal pour limiter le taux de limitation afin d'éviter une signalisation S1 excessive sur mmemgr.

Cependant, le débit est limité par eNodeB moyen. Le taux moyen par eNodeB (dans le cas de 6 500 eNodeB) est de 10 pages par seconde. Cependant, les zones de suivi (TA) ne sont pas égales en nombre d'abonnés et les différents eNodeB TA/membre sont chargés avec pagination différemment. Dans le cas d'une différence de taille de TA deux fois supérieure au nombre moyen d'abonnés par TA, le taux par eNodeB serait de 20. Dans le cas d'une différence de 20 fois plus grande entre la taille de l'AT et le nombre moyen d'abonnés par AT, le taux par eNodeB serait de 200. Cela signifie que la fonctionnalité devient plus efficace dans les cas où les TA (en nombre d'abonnés) sont chargés uniformément.

Une autre action qui doit être entreprise en parallèle consiste à activer la radiomessagerie intelligente. Reportez-vous à la section « TAI mgmt db and LTE Paging » du Guide d'administration ASR 5000 MME.

La commande de configuration est la suivante :

asr5000(config)# network-overload-protection mme-tx-msg-rate-control enb s1-paging
 
     
     

• network-overload-protection identifie la protection contre la surcharge du réseau
• mme-tx-msg-rate-control enb identifie le contrôle du débit des messages MME par eNodeB moyen
• s1-paging identifie le contrôle du débit des messages pour la radiomessagerie S1
• <rate> spécifie le seuil de débit des messages par seconde par eNodeB - plage (1 à 65 535)

Exemple de configuration

network-overload-protection mme-tx-msg-rate-control enb s1-paging 200

Remarques :
- La limite de taux est le sujet de la poursuite du réglage, dans une direction décroissante. La base du réglage est le nombre d'abonnés (nombre de radiomessagerie) sur les TA (des statistiques de niveau TA sont requises).

- La fonctionnalité devient plus efficace dans les cas où les TA (en nombre d'abonnés/téléavertissement par TA) sont chargés de manière égale.

Protection contre la surcharge du réseau : Limitation DDN (fonctionnalité de Serving GateWay, protection MME)

La limitation DDN (Downlink Data Notification) est une fonction permettant de contrôler le taux de requêtes DDN vers MME du côté de Serving GateWay (SGW). Il protège les ressources MME telles que mmemgr et sessmgr contre les surtensions DDN (c'est-à-dire, les requêtes de pagination en entrée).

Cette fonctionnalité comporte deux parties, l'une pour les MME conformes à la norme Rel-10 et l'autre pour les MME non conformes à la norme Rel-10 :

• Pour les MME conformes à la norme Rel-10, définissez le filigrane ARP (DDN Throttling Allocation and Conservation Priority) dans le service SGW afin d'activer la fonctionnalité.
• Pour les MME non conformes Rel-10, d'autres paramètres doivent être définis avec le filigrane ARP (comme le facteur de limitation, le temps de limitation, le temps de stabilisation, l'intervalle d'interrogation, etc.) dans le service SGW.

Lorsque cette fonctionnalité est activée sur SGW, elle envoie un filigrane ARP dans la requête DDN au MME. En réponse, MME envoie une unité de délai de régulation, une valeur de délai de régulation et un facteur de régulation. La combinaison de la valeur de délai et de l'unité de délai calcule le temps de limitation. Dès réception de ces valeurs, SGW abandonne DDN Req pour ARP particulier jusqu'à l'expiration du compteur de limitation.

Pour les MME non conformes à la norme Rel-10 qui utilisent la configuration locale, SGW limite le besoin en DDN avec un filigrane ARP particulier.

Les versions 16 et 17 de Cisco ASR5x00 MME ne prennent pas en charge la limitation DDN automatique. Elle fonctionne donc comme non conforme à la norme Rel 10 en termes de limitation DDN.

Note: La limitation DDN fournit une granularité supplémentaire sur le dessus de la limitation de pagination MME côté entrée (S11) plutôt que côté sortie (S1). Cisco ne vous demande pas d'implémenter la limitation DDN si la limitation de pagination est configurée, mais elle fournit une détection et une élimination plus précoces de la surcharge.

Spécifications techniques (TS) 23.401, référence pour MME :

Limitation des requêtes DDN

Dans des circonstances inhabituelles (par exemple lorsque la charge MME dépasse un seuil configuré par l'opérateur), le MME peut restreindre la charge de signalisation que ses SGW génèrent sur lui, si configuré pour le faire.

Le MME peut rejeter les requêtes DDN pour le trafic de faible priorité pour les UE en mode inactif ou pour décharger davantage le MME. Le MME peut demander aux SGW de réduire sélectivement le nombre de requêtes DDN qu'il envoie pour le trafic de faible priorité de liaison descendante reçu pour les UE en mode inactif, conformément à un facteur de limitation et pour un délai de limitation spécifié dans le message DDN Ack.

Le SGW détermine si un support est destiné au trafic de faible priorité ou non en fonction du niveau de priorité ARP du support et de la politique de l'opérateur (c'est-à-dire la configuration de l'opérateur dans le SGW des niveaux de priorité ARP à considérer comme trafic prioritaire ou non prioritaire). Le MME détermine si une demande DDN concerne le trafic de faible priorité ou non en fonction du niveau de priorité ARP reçu de la stratégie SGW et de l'opérateur.

Si la réduction de la signalisation en état d'inactivité (ISR) n'est pas active pour l'UE, pendant le délai de limitation, le SGW abandonne les paquets de liaison descendante reçus sur tous ses porteurs de faible priorité pour les UE connus comme n'étant pas un plan utilisateur connecté (c'est-à-dire que les données de contexte SGW indiquent qu'aucun TEID (Tunnel End Identifier) du plan utilisateur de liaison descendante n'est fourni par ce MME en proportion au facteur de régulation, et envoie un message DDN au MME uniquement pour les porteurs non-limités.

Si ISR est actif pour l'UE pendant le délai de limitation, le SGW n'envoie pas de DDN au MME et envoie uniquement le DDN au SGSN. Si MME et SGSN demandent tous deux une réduction de charge, le SGW abandonne les paquets de liaison descendante reçus sur tous ses supports de faible priorité pour les UE connus comme plan utilisateur non connecté (c'est-à-dire que les données de contexte SGW indiquent qu'aucun TEID de plan utilisateur de liaison descendante n'est reçu) en proportion des facteurs de limitation.

Le SGW reprend les opérations normales à l'expiration du délai de limitation. La dernière valeur reçue du facteur de limitation et du délai de limitation remplace toutes les valeurs précédentes reçues de ce MME. La réception d'un délai de limitation redémarre le minuteur SGW associé à ce MME.

Pour SGW et MME, le calcul du taux de limitation est relativement simple. Prenez le taux maximal autorisé d'entrée, qui est de 1 100 messages par seconde par zone MME.

Les commandes de configuration sont les suivantes :

#configure

#context saegw-gtp

#sgw-service sgw-svc

#ddn throttle arp-watermark <arp_value> rate-limit <limit> time-factor <seconds>
 throttle-factor <percent> increment-factor <percent> poll-interval <second>
 throttle-time-sec <seconds> throttle-time-min <minutes> throttle-time-hour <hour>
 stab-time-sec <seconds> stab-time-min <minutes> stab-time-hour <hour>

limitation arp-watermark arp_value
Si le filigrane ARP est configuré et si un MME/SGSN envoie le facteur de limitation et le délai dans un message ACK DDN, tous les DDN dont la valeur ARP est supérieure à la valeur configurée seront limités par le facteur de limitation du délai spécifié.
arp_value est un entier compris entre 1 et 15.

limite de débit
Configure la limite de débit (utilisez ce jeton et les jetons suivants pour définir la limite de débit uniquement si le MME est un MME non disponible de 10 MME).
limit est un entier compris entre 1 et 9999999999.

durée-facteur secondes
Configure la durée pendant laquelle le SGW prend des décisions de limitation.
secondes est un entier compris entre 1 et 300.

pourcentage de facteur de régulation
Configure le facteur de limitation DDN. Saisissez le pourcentage de DDN à abandonner lors de la détection d'une surtension DDN.
pourcentage est un entier compris entre 1 et 100.

pourcentage de facteur d'incrément
Configure le facteur d'incrément de limitation DDN. Saisissez le pourcentage d'augmentation de la limitation DDN.
pourcentage est un entier compris entre 1 et 100.

poll-interval seconds
Configure l'intervalle d'interrogation dans la limitation DDN.
secondes est un entier compris entre 2 et 9999999999.

durée de régulation secondes
Configure le temps de limitation DDN en secondes. Saisissez la période en secondes pendant laquelle le DDN est limité au SGW.
secondes est un entier compris entre 0 et 59.

durée-min
Configure le temps de limitation DDN en minutes. Saisissez une période en minutes au cours de laquelle les DDN sont limités au niveau SGW.
minutes est un entier compris entre 0 et 59.

heure de régulation
Configure le temps de limitation DDN en heures. Saisissez la période en heures pendant laquelle le DDN est limité au SGW.
heure est un entier compris entre 0 et 310.

stab-time-sec secondes
Configure le temps de stabilisation de limitation DDN en secondes. Entrez une période en secondes pendant laquelle si le système est stabilisé, la limitation sera désactivée.
secondes est un entier compris entre 0 et 59.

stab-time-min minutes
Configure le temps de stabilisation de limitation DDN en minutes. Entrez une période en minutes pendant laquelle si le système est stabilisé, la limitation sera désactivée.
minutes est un entier compris entre 0 et 59.

heure de pointe
Configure le temps de stabilisation de limitation DDN en heures. Entrez une période en heures pendant laquelle la limitation sera désactivée si le système est stabilisé.
heure est un entier compris entre 0 et 310.

Exemple de configuration

ddn throttle arp-watermark 1 rate-limit RATE time-factor 120 throttle-factor 50
 increment-factor 10 poll-interval 30 throttle-time-sec 0 throttle-time-min 1
 throttle-time-hour 0 stab-time-sec 0 stab-time-min 2 stab-time-hour 0

• 1 100 pages/secondes est le débit d'entrée maximal autorisé (DDN inclus)
• 1 100 pages/secondes en cas de surtension DDN correspond à 1 100 DDN/s
• Régions avec 4xSGW par site MME > RATE = 275 DDN/seconde par SGW maximum autorisé
• Régions avec 3xSGW par site MME > RATE = 366 DDN/seconde par SGW maximum autorisé
• Régions avec 2xSGW par site MME > RATE = 550 DDN/seconde par SGW maximum autorisé
• Régions avec 1xSGW par site MME > RATE = 100 DDN/seconde par SGW maximum autorisé

Protection contre la surcharge du réseau : Limitation des échecs de chemin EGTP

Cette fonctionnalité protège les ressources MME (sessmgr, mmemgr) ainsi que les ressources 4G contre les surtensions de chemins d'accès du protocole de tunnellisation GPRS amélioré (EGTP) en cas de pannes de transmission dans IP Backbone et IP BackHaul, ainsi que la fonctionnalité d'élément de réseau latéral failures/restarts.The active par session la limitation des événements de défaillance du chemin EGTP détectés et définit une granularité supplémentaire pour la gestion des abonnés, en plus haut de la fonction de régulation de paging S1. En fonction de la division entre les abonnés inactifs et connectés, les limites doivent être définies. Il est très spécifique au réseau et nécessite un ajustement par rapport au statut eUTRAN et UE.

Exemple

Les abonnés sont divisés vers 80:20 IDLE à CONNECTED. Dans le pire des cas, le protocole EGTP PF pour les abonnés IDLE provoque une surtension de pagination qui peut provoquer la surcharge de mgr, le goulot d'étranglement le plus étroit de la chaîne. Une telle poussée de facteur de pagination EGTP (PF) (pour les abonnés IDLE) provoque d'abord une poussée de pagination et cette poussée touche le goulot d'étranglement de mmemgr, donc vous devez protéger mmemgr contre cette première. Ainsi, le protocole EGTP PF pour IDLE peut être considéré comme une surtension inattendue de pagination d'entrée autorisée à un maximum de 100 pages/seconde.

• La limite de limitation recommandée est de 1 000 msg/seconde pour les abonnés IDLE.
• Le nombre de sous-sections CONNECTED est de ~ 5 à 7 fois inférieur à IDLE.
• Les surtensions de radiomessagerie ne se produisent pas avec les abonnés CONNECTED. Par conséquent, 2 000 msg/s est recommandé pour être appliqué en toute sécurité aux abonnés CONNECTED.

Note: La limitation EGTP PF fournit une granularité plus grande sur le dessus de la limitation de pagination MME côté entrée (S11, Sv) plutôt que côté sortie (S1). Cisco ne vous demande pas d'implémenter la limitation EGTP PF si Paging Throttling est configuré, mais il fournit une détection et une élimination plus précoces de la surcharge.

Cette configuration s'applique à un service EGTP dont le type d'interface est « interface-me ».

La commande de configuration est la suivante :

asr5000(config)# network-overload-protection mme-tx-msg-rate-control egtp-pathfail ecm-idle
 < rate in sessions per second > ecm-connected < rate in sessions per second >

• network-overload-protection identifie la protection contre la surcharge du réseau
• mme-tx-msg-rate-control identifie le contrôle du débit des messages MME
• egtp-pathfail identifie le contrôle du débit des messages lors de la défaillance du chemin EGTP
• ecm-idle identifie le taux pour les sessions UE MME en mode ECM-Idle
• ecm-connected identifie le débit des sessions MME UE en mode ECM-Connected
• < débit en sessions par seconde> spécifie le seuil de débit en sessions par seconde, la plage est comprise entre 1 et 5 000

Exemple de configuration

network-overload-protection mme-tx-msg-rate-control egtp-pathfail ecm-idle
 1000 ecm-connected 2000

Contrôle d'encombrement amélioré

Grâce à la fonctionnalité de contrôle d'encombrement amélioré, le MME peut émettre un signal vers les eNodeBs auxquels il est connecté afin de rediriger le trafic vers d'autres MME du pool MME. Pour ce faire, utilisez la procédure de surcharge d'interface S1 (TS 36.300 et TS 36.413).

Lorsque le contrôle de surcharge est configuré et qu'un seuil d'encombrement est atteint, le MME peut être configuré pour envoyer un message de démarrage de surcharge de l'interface S1AP à un pourcentage des eNodeBs auxquels le MME est connecté. Afin de refléter la quantité de charge que le MME souhaite réduire, ce pourcentage est configurable. Dans l'élément d'informations de réponse de surcharge (IE) envoyé aux eNodeBs, le MME peut demander à eNodeB de rejeter ou d'autoriser des types de sessions spécifiques, notamment :

• rejeter les sessions non urgentes
• rejeter les nouvelles sessions
• autoriser les sessions d'urgence
• Autoriser les sessions hautement prioritaires et les services terminés par des terminaux mobiles
• rejeter l'accès à tolérance de délai

La fonction de contrôle de congestion vous permet de définir des politiques et des seuils et de spécifier la manière dont le système réagit lorsqu'il est confronté à une charge lourde. Le contrôle d'encombrement surveille le système pour détecter les conditions susceptibles de dégrader les performances lorsque le système est soumis à une charge élevée. En règle générale, ces conditions sont temporaires (par exemple, utilisation élevée du processeur ou de la mémoire) et sont rapidement résolues. Cependant, un nombre continu ou important de ces conditions dans un intervalle de temps spécifique peut avoir un impact sur la capacité du système à traiter les sessions d'abonnés. Le contrôle de la congestion permet d'identifier de telles conditions et d'invoquer des politiques pour remédier à la situation.

Seuils de condition de congestion

• Utilisation du processeur système
• Utilisation du processeur du service système (utilisation du processeur Demux-Card)
• Utilisation de la mémoire système
• Utilisation des licences
• Nombre maximal de sessions par service

Seuils et niveaux de tolérance

Lorsque vous configurez des seuils et des tolérances pour les niveaux d'encombrement critiques, majeurs et mineurs, les niveaux de seuil et de tolérance ne doivent jamais se chevaucher. Considérez ces exemples de configuration, où les niveaux de seuil ne se chevauchent pas :

• La congestion critique se déclenche à 95 % et se dissipe à 90 %
• La congestion majeure se déclenche à 90 % et se dissipe à 85 %
• Déclencheurs mineurs de congestion à 85 % et effacement à 80 %

Seuils CPU du contrôle de service

Ce seuil est calculé à partir du processeur de démultiplexage du système. Le seuil est calculé sur la base d'une utilisation moyenne du processeur de cinq minutes.

La valeur d'utilisation CPU la plus élevée de deux coeurs de CPU du processeur de multiplexage est prise en compte. Par exemple, si le coeur de CPU 0 a une utilisation de CPU de 5 minutes de 40 % et que le coeur de CPU 1 a une utilisation de CPU de 5 minutes de 80 %, alors le coeur de CPU 1 est pris en compte pour le calcul du seuil.

Seuils du processeur système

Ce seuil est calculé à l'aide de la moyenne d'utilisation du CPU de cinq minutes de tous les CPU (sauf le CPU de secours et le CPU SMC).

La valeur d'utilisation CPU la plus élevée de deux coeurs de CPU de tous les CPU est prise en compte.

Seuils de mémoire système

Ce seuil est calculé avec la moyenne d'utilisation de la mémoire de cinq minutes de tous les processeurs (à l'exception du processeur de secours et du processeur SMC).

Configurer un profil d'action de congestion

Les profils d'action de congestion définissent un ensemble d'actions qui peuvent être exécutées après le dépassement du seuil correspondant.

Associer un profil d'action de congestion aux stratégies de contrôle de congestion

Chaque stratégie de contrôle de congestion (critique, majeure, mineure) doit être associée à un profil de contrôle de congestion.

Configurer le contrôle de surcharge

Lorsqu'une condition de surcharge est détectée sur un MME, le système peut être configuré pour signaler la condition à un pourcentage spécifié d'eNodeBs et pour effectuer l'action configurée sur les sessions entrantes.

Ces actions de surcharge sont également disponibles (en plus de rejeter les nouvelles sessions) :

• permit-Emergency-sessions-and-mobile-termination-services
• permit-high-priority-sessions-and-mobile-termination-services
• rejet-delay-tolérant-access
• rejeter-non-urgences-sessions

Exemple d'explication de configuration

Ceci active la fonctionnalité de contrôle de congestion :

congestion-control

This monitors the overall CPU Utilization including the sessmgr and demux mgrs

congestion-control threshold system-cpu-utilization critical 90

congestion-control threshold system-cpu-utilization major 85

congestion-control threshold system-cpu-utilization minor 80

 

Memory utilization thresholds:

congestion-control threshold system-memory-utilization critical 85

congestion-control threshold system-memory-utilization major 75

congestion-control threshold system-memory-utilization minor 70

 

CPU utilization on DEMUX card:

congestion-control threshold service-control-cpu-utilization critical 85

congestion-control threshold service-control-cpu-utilization major 75

congestion-control threshold service-control-cpu-utilization minor 70

 

Defining tolerance margins:

congestion-control threshold tolerance critical 5

congestion-control threshold tolerance major 5

congestion-control threshold tolerance minor 5

Définir les profils d'action de congestion (Critique, Majeure et Mineure)

lte-policy

congestion-action-profile criticalCogestionProfile

   reject s1-setups time-to-wait 60

   drop handovers

   drop combined-attaches

   drop service-request

   drop addn-brr-requests

   drop addn-pdn-connects

   exclude-voice-events

   exclude-emergency-events

   report-overload permit-emergency-sessions-and-mobile-terminated-service enodeb-percentage 50

congestion-action-profile majorCogestionProfile

   report-overload permit-emergency-sessions-and-mobile-terminated-service enodeb-percentage 50

congestion-action-profile minorCogestionProfile

   report-overload permit-emergency-sessions-and-mobile-terminated-service enodeb-percentage 30

end

Appliquer les stratégies d'encombrement

configure

congestion-control policy critical mme-service action-profile criticalCogestionProfile

congestion-control policy major mme-service action-profile majorCogestionProfile

congestion-control policy minor mme-service action-profile minorCogestionProfile

end

.

Informations connexes

• Guide d'administration des entités de gestion de la mobilité Cisco ASR 5000
• Support et documentation techniques - Cisco Systems