Controle de limite de buffer FAR do CUPS na função de plano do usuário

Introdução

Este documento descreve o conceito, a implementação e os benefícios do recurso FAR Buffering Limit disponível no produto Cisco CUPS.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Mobilidade LTE (Long Term Evolution, evolução de longo prazo)
• Arquitetura do plano de controle e das funções do plano do usuário (CUPS)

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Ambiente

Ambiente

Conceito básico de FAR

A Regra de Ação de Encaminhamento (FAR) determina a ação que a função Plano do Usuário (Gateway de Serviço (SGW - Serving Gateway)-U ou Gateway PDN (PGW)-U) deve tomar para pacotes que correspondam a uma Regra de Detecção de Pacote (PDR - Packet Detection Rule) correspondente. As ações possíveis especificadas em um FAR incluem:

• Encaminhar o pacote a um destino especificado (por exemplo, a Internet/Rede de Dados de Pacotes (PDN) ou o eNodeB)
• Descartar o pacote
• Duplicar o pacote (usado em Interceptação Legal ou para fins de espelhamento de tráfego)
• Colocar o pacote em buffer, caso em que uma regra de ação de colocação em buffer associada pode especificar parâmetros para colocar em buffer e notificar a função Plano de Controle 

Essencialmente, o FAR permite que o plano de controle gerencie de forma remota e dinâmica o fluxo de tráfego do plano do usuário e a aplicação de políticas, que é a chave para os benefícios de flexibilidade e escalabilidade da arquitetura CUPS.

Informações de Apoio

Quando um equipamento de usuário (UE) entra no estado ocioso, o Mobility Management Entity (MME) envia uma solicitação de portador de acesso de versão ao SGW-C para liberar todos os portadores S1-U para o UE. Ao mesmo tempo, o SGW-C informa ao SGW-U para descartar todos os pacotes de downlink e atualizar os estados do portador para ocioso enquanto a função Plano do usuário começa a armazenar em buffer os Dados de downlink para um determinado limite por padrão.

Depois que todos os planos do usuário respondem, o plano de controle atualiza o contexto do assinante e informa ao MME que os transmissores foram liberados. Esse procedimento garante que todos os recursos consumidos necessários sejam liberados durante a Inatividade do assinante. Esse mecanismo ajuda a gerenciar eficientemente as transições de estado de UE e a utilização de recursos na rede.

Descrição do problema

Em um cenário normal, sempre que um UE entra no estado ocioso, a função Plano do usuário começa a armazenar em buffer os Dados de downlink. Por padrão, na plataforma CUPS, até cinco pacotes são armazenados em buffer por FAR. Ao receber o primeiro pacote de dados de downlink no SGW-U, o SGW-C envia uma solicitação de notificação de dados de downlink (DDN) ao MME para iniciar a paginação do UE para verificar sua disponibilidade para aceitar o tráfego de downlink (DL). Em caso de êxito na paginação, o MME envia uma solicitação de modificação do portador ao SGW-C que informa ao SGW-U para desarmazenar em buffer os pacotes de dados que já estão em sua fila e começar a encaminhar pacotes DL como antes.

Caso devido a algum motivo, se o MME não puder colocar o UE na página ou o MME não puder obter uma resposta de êxito de paginação do UE antes que esse limite de buffer de cinco pacotes no SGW-U seja atingido, você poderá ver um aumento nos pacotes de descarte de estouro de buffer DDN na direção de downlink. Isso pode resultar em uma possível degradação da qualidade do serviço de dados móveis para usuários finais, possivelmente afetando o desempenho geral da rede e a experiência do usuário.

Fluxo de Chamadas do Cenário de Êxito de DDN

Fluxo de Chamadas do Cenário de Êxito de DDN

1. O MME envia a solicitação Release Access Bearer ao SGW-C para liberar os Identificadores de Endpoint de Túnel (TEIDs - Tunnel Endpoint Identifiers) remotos de downlink de todos os portadores desse UE.
2. Na chegada da solicitação do portador de acesso de liberação, o SGW-C informa o mesmo ao SGW-U atualizando o FAR com a ação de aplicação como buffer na solicitação de modificação Sx para todos os PDNs.
3. SGW-U envia a resposta Sx Modification após aplicar o buffer em SGW-U para o PDN correspondente.
4. O SGW-C envia a resposta do portador de acesso de versão ao MME.
5. Os primeiros dados de downlink que chegam no SGW-U acionam a solicitação de relatório Sx (com o tipo de relatório como Relatório de dados de downlink) em direção ao SGW-C.
6. Na chegada da mensagem Sx Report Request, o SGW-C inicia a mensagem de solicitação DDN em direção ao MME.
7. O SGW-C envia a mensagem Sx Report Response para o SGW-U.
8. Se o MME puder enviar uma solicitação de paging para UE, ele definirá a causa como 'Solicitação aceita' na Mensagem de confirmação DDN e a enviará ao SGW-C.
9. Na paginação bem-sucedida, o MME envia uma solicitação de Modificação do Portador ao S-GW com TEIDs eNodeB que configura a conexão S1-U no SGW.
10. SGW-C envia Sx Modification Request com FAR atualizado para novas informações TEID para SGW-U. SGW-U agora pode encaminhar todos os dados em buffer para UE através do eNodeB.
11. SGW-U envia a resposta de Modificação Sx para SGW-C.

Fluxo de Chamadas do Cenário de Falha de DDN

Fluxo de Chamadas do Cenário de Falha de DDN

1. O MME envia a solicitação do portador de acesso de liberação ao SGW-C para liberar TEIDs remotos de downlink de todos os portadores para esse UE.
2. Na chegada da solicitação do portador de acesso de liberação, o SGW-C informa o mesmo ao SGW-U atualizando o FAR com ação de aplicação como buffer na solicitação de modificação Sx para todos os PDNs.
3. SGW-U envia a resposta Sx Modification após aplicar o buffer em SGW-U para o PDN correspondente.
4. O SGW-C envia a resposta do portador de acesso de versão ao MME.
5. Os primeiros dados de downlink que chegam no SGW-U acionam a solicitação de relatório Sx (com o tipo de relatório como Relatório de dados de downlink) em direção ao SGW-C.
6. Na chegada da mensagem Sx Report Request, o SGW-C inicia a mensagem de solicitação DDN em direção ao MME.
7. O SGW-C envia a mensagem Sx Report Response para o SGW-U.
8. Se o MME não puder colocar o UE na página, ele poderá rejeitar a Solicitação DDN com a causa relevante.

or
Se o MME aceitar a solicitação de DDN, ele enviará posteriormente a indicação de falha de DDN para indicar ao SGW-C que o UE não respondeu à paginação.

9. O SGW-C recebeu uma falha de DDN e, portanto, para parar de enviar o próximo DDN imediatamente, o SGW-C inicia o Temporizador de falha de DDN. SGW-C envia Sx Modification Request with Drop Buffered (DROBU) flag para descartar pacotes em buffer e Apply Action como 'drop' para descartar os pacotes subsequentes.
10. SGW-U envia Resposta de Modificação Sx para SGW-C.
11. Na expiração do temporizador de falha DDN, o SGW-C inicia a modificação Sx com Apply Action como buffer para iniciar o buffer novamente.
12. Outras etapas são continuadas na Etapa 3. do fluxo de chamadas do Cenário de êxito de DDN.

Visão geral da solução

O número de pacotes armazenados em buffer por FAR no plano do usuário é configurável no plano de controle do Cisco CUPS. Dessa forma, você pode superar esse limite de buffer de cinco pacotes por meio de um limite de buffer distante-máximo-de-pacotes <num> da CLI disponível no subsistema do Ative Charging Service (ACS). O operador pode decidir qualquer valor no intervalo de 1 a 128 para controlar o limite de buffer FAR dependendo do modelo de chamada para otimizar a Qualidade de Serviço (QoS) e reduzir quedas de pacotes, aprimorando assim a experiência da UE e melhorando o desempenho geral da rede.

Configuração

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ção

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 

Compare o contador 'DDN buffer overflow drop packets' com o valor default de buffering-limit far-max-packets (que é cinco) em relação a outro valor superior a cinco com o mesmo tipo e duração de Call-Model. Você deve ver uma diminuição nesse contador quando o valor for superior a cinco.

Informações Relacionadas

• 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

• Suporte técnico e downloads da Cisco