Controllo del limite di buffer CUPS FAR sulla funzione User Plane

Introduzione

Questo documento descrive il concetto, l'implementazione e i vantaggi della funzione FAR Buffering Limit disponibile nei prodotti Cisco CUPS.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Mobilità LTE (Long Term Evolution)
• Architettura Control Plane e User Plane Functions (CUPS)

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Ambiente

Ambiente

Concetto di base di FAR

La regola d'azione inoltro (FAR) determina l'azione che la funzione User Plane (Serving Gateway (SGW)-U o PDN Gateway (PGW)-U) deve eseguire per i pacchetti che corrispondono a una regola di rilevamento pacchetti (PDR) corrispondente. Le possibili azioni specificate in un FAR includono:

• Inoltrare il pacchetto alla destinazione specificata, ad esempio Internet/Packet Data Network (PDN) o eNodeB
• Elimina il pacchetto
• Duplica il pacchetto (usato nell'intercettazione legale o per il mirroring del traffico)
• Memorizzare il pacchetto nel buffer. In questo caso, una regola di azione associata può specificare i parametri per il buffering e la notifica della funzione Control Plane. 

Essenzialmente, il FAR consente al Control Plane di gestire in remoto e in modo dinamico il flusso del traffico e l'applicazione delle policy, il che è fondamentale per la flessibilità e la scalabilità dell'architettura CUPS.

Premesse

Quando un'apparecchiatura utente (UE) passa allo stato di inattività, Mobility Management Entity (MME) invia una richiesta di rilascio del supporto di accesso a SGW-C per rilasciare tutti i supporti S1-U per l'UE. Allo stesso tempo, SGW-C comunica all'SGW-U di eliminare tutti i pacchetti di downlink e di aggiornare gli stati del bearer in modo che siano inattivi, mentre la funzione User Plane inizia a memorizzare i dati in downlink ad un certo limite per impostazione predefinita.

Quando tutti i piani utente rispondono, il piano di controllo aggiorna il contesto del sottoscrittore e informa l'MME che i portatori sono stati rilasciati. Questa procedura garantisce che tutte le risorse necessarie consumate vengano liberate durante l'inattività del sottoscrittore. Questo meccanismo consente di gestire in modo efficiente le transizioni di stato UE e l'utilizzo delle risorse nella rete.

Descrizione del problema

In uno scenario normale, ogni volta che un UE passa allo stato di inattività, la funzione Piano utente avvia la memorizzazione dei dati di downlink. Per impostazione predefinita, sulla piattaforma CUPS vengono memorizzati nel buffer fino a cinque pacchetti per FAR. Al ricevimento del primo pacchetto di dati in downlink sull'SGW-U, SGW-C invia una richiesta di notifica dei dati in downlink (DDN) all'MME per avviare il paging dell'UE e verificare la sua disponibilità ad accettare il traffico in downlink (DL). Una volta completato il paging, MME invia una richiesta di modifica del bearer a SGW-C che informa l'SGW-U di eliminare il buffer dei pacchetti di dati già presenti nella coda e iniziare a inoltrare i pacchetti DL come prima.

Se per qualche motivo MME non è in grado di eseguire la pagina UE o MME non è riuscito a ottenere una risposta di completamento del paging da UE prima che venga raggiunta la soglia dei cinque limiti del buffer dei pacchetti sull'SGW-U, si può notare un aumento dei pacchetti di overflow del buffer DDN nella direzione di download. Ciò può causare un potenziale peggioramento della qualità del servizio dati mobile per gli utenti finali, con possibili ripercussioni sulle prestazioni complessive della rete e sull'esperienza utente.

Flusso chiamata scenario riuscito DDN

Flusso chiamata scenario riuscito DDN

1. MME invia una richiesta di Release Access Bearer a SGW-C per rilasciare i TEID (Remote Tunnel Endpoint Identifier) di tutti i bearer per l'UE.
2. All'arrivo della richiesta di Release Access Bearer, SGW-C informa lo stesso a SGW-U aggiornando FAR con l'azione di applicazione come buffer nella richiesta di modifica Sx per tutte le PDN.
3. L'SGW-U invia una risposta di modifica Sx dopo aver applicato la memorizzazione nel SGW-U sulla PDN corrispondente.
4. SGW-C invia a MME la risposta di Release Access Bearer.
5. I primi dati di downlink in arrivo in SGW-U attivano la richiesta di report Sx (con tipo di report come Downlink Data Report) verso SGW-C.
6. All'arrivo del messaggio Sx Report Request, l'SGW-C avvia il messaggio DDN Request verso MME.
7. SGW-C invia un messaggio di risposta Sx Report all'SGW-U.
8. Se MME è in grado di inviare una richiesta di paging verso UE, imposta la causa come 'Richiesta accettata' nel messaggio di conferma DDN e la invia a SGW-C.
9. Una volta completato il paging, MME invia una richiesta di modifica del supporto al S-GW con TEID eNodeB che imposta la connessione S1-U al SGW.
10. SGW-C invia a SGW-U una richiesta di modifica della Sx con FAR aggiornato per ottenere nuove informazioni TEID. L'SGW-U può ora inoltrare tutti i dati memorizzati nel buffer all'UE tramite eNodeB.
11. L'SGW-U invia una risposta di modifica Sx all'SGW-C.

Flusso di chiamata scenario di errore DDN

Flusso di chiamata scenario di errore DDN

1. MME invia una richiesta di Release Access Bearer all'SGW-C per rilasciare i TEID remoti di tutti i bearer per l'UE.
2. All'arrivo della richiesta di Release Access Bearer, SGW-C comunica lo stesso a SGW-U aggiornando FAR con Apply Action come buffer in Sx Modification Request per tutte le PDN.
3. L'SGW-U invia una risposta di modifica Sx dopo aver applicato la memorizzazione nel SGW-U sulla PDN corrispondente.
4. SGW-C invia a MME la risposta di Release Access Bearer.
5. I primi dati di downlink in arrivo in SGW-U attivano la richiesta di report Sx (con tipo di report come Downlink Data Report) verso SGW-C.
6. All'arrivo del messaggio Sx Report Request, l'SGW-C avvia il messaggio DDN Request verso MME.
7. SGW-C invia un messaggio di risposta Sx Report all'SGW-U.
8. Se MME non è in grado di eseguire la pagina UE, può rifiutare la richiesta DDN con la causa appropriata.

o
Se l'MME accetta la richiesta DDN, in seguito invia l'indicazione Errore DDN per indicare all'SGW-C che l'UE non ha risposto al paging.

9. SGW-C ha ricevuto un errore DDN e quindi per interrompere immediatamente l'invio del DDN successivo, SGW-C avvia il timer dell'errore DDN. L'SGW-C invia una richiesta di modifica Sx con il flag Drop Buffered (DROBU) per scartare i pacchetti nel buffer e un'azione di applicazione come "drop" per scartare i pacchetti successivi.
10. L'SGW-U invia una risposta di modifica Sx all'SGW-C.
11. Alla scadenza del timer per errori DDN, SGW-C avvia Sx Modification with Apply Action come buffer per avviare di nuovo il buffer.
12. I passaggi successivi proseguono dal passaggio 3 nel flusso di chiamata Scenario riuscito DDN.

Panoramica della soluzione

Il numero di pacchetti memorizzati nel buffer per FAR sul piano utente è configurabile sul piano di controllo Cisco CUPS. In questo modo, è possibile superare questo limite di cinque pacchetti buffer tramite un limite di buffer CLI far-max-packets <num> disponibile nel sottosistema ACS (Active Charging Service). L'operatore può scegliere un valore compreso tra 1 e 128 per controllare il limite del buffer FAR a seconda del modello di chiamata, in modo da ottimizzare la qualità del servizio (QoS) e ridurre le perdite di pacchetti, migliorando l'esperienza dell'UE e le prestazioni complessive della rete.

Configurazione

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

Verifica

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 

Confrontare il contatore 'DDN buffer overflow drop packets' con il valore predefinito di limite di buffer far-max-packets (cinque) rispetto a un altro valore superiore a cinque con la stessa proprietà Call-Model e la stessa durata. Quando il valore è superiore a cinque, è necessario che il contatore diminuisca.

Informazioni correlate

• 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

• Supporto tecnico Cisco e download