Política 3GPP e controle de cobrança para provisionamento e contabilidade de wireline

Benefícios da política 3GPP e da arquitetura de controle de cobrança

• Fornece uma estrutura unificada para provisionamento e contabilidade de assinantes wireline.

Ambiente de acesso wireline

Para assinantes móveis, o equipamento do usuário solicita serviços; para assinantes de telefonia fixa de banda larga, o PCRF solicita serviços. No ambiente wireline, o PCRF funciona como o solicitante de serviço e o PCEF funciona como o receptor e executor de serviço.

Adaptar o modelo PCC em um ambiente wireline oferece estes benefícios:

• Conveniência

• Tecnologia avançada

• Já implementado pela filial sem fio da operadora que muitas vezes oferece um negócio muito maior do que a filial com fio

O PCRF controla o PCEF pressionando as regras de carregamento. As regras de cobrança são reutilizadas como regras de serviço (política) para políticas de push. As regras de cobrança também podem ter um grupo de classificação associado ou uma chave de cobrança. Como resultado, a configuração do PCEF deve definir regras de cobrança e mapeamento entre serviços de controle de crédito (cc-services) e grupos de classificação.

Em muitos casos, os serviços de contabilidade 3GPP do OCS e do Offline Charging System (OFCS) exigem que o número do diretório de assinantes internacionais (MSISDN) da estação móvel seja usado para identificação do assinante. O MSISDN é passado como a ID da assinatura. Embora cada dispositivo de equipamento de usuário móvel tenha um MSISDN associado, essas informações não estão disponíveis para assinantes de telefonia fixa. Para permitir que o PCRF transmita dinamicamente parâmetros de ID de assinatura e ofereça suporte a uma variedade de configurações de autenticação, autorização e provisionamento, os pares de atributo-valor (AVPs) da Juniper na Tabela 2 foram alocados a partir do atributo específico do fornecedor (VSA) do espaço de ID de fornecedor da Juniper (2636).

Observação:

Se nenhuma ID de assinatura dinâmica for recebida, nem as comunicações OCS ou OFCS serão iniciadas.

Tabela 2: AVPs da Juniper alocados

Nome do AVP	ID do fornecedor	Tipo de AVP	Tipo de diâmetro	Bandeira de diâmetro
Juniper-Dyn-Subscription-Indicator	2636	10001	Enumeração	V
juniper-dyn-subscription-id	2636	10002	Agrupado	VM
juniper-dyn-subscription-id-type	2636	10003	Inteiro32	VM
juniper-dyn-subscription-id-data	2636	10004	UTF8String	VM

O sistema cliente (roteador) envia o AVP Juniper-Dyn-Subscription-Id-Indicator para indicar suporte à atribuição dinâmica do ID da assinatura. O atributo Juniper-Dyn-Subscription-Id-Indicator tem dois valores:

• DYN_SUBSCRIPtION_NOT_SUPPORTED (0)

• DYN_SUBSCRIPTION_SUPPORTED (1)

Em seguida, o servidor envia o AVP Juniper-Dyn-Subscription-Id para o cliente que indicou o suporte. Este é um AVP agrupado que contém os valores a serem enviados como Subscription-Id-Type e Subscription-Id-Data.

Observação:

• O servidor PCRF pode usar o AVP de ID de assinatura padrão para comunicar o ID de assinatura dinâmica ao roteador.

• Se Juniper-Dyn-Subscription-Id e Subscription-Id forem enviados pelo PCRF, o valor de Subscription-Id será usado.

Em muitos casos, os assinantes de telefonia fixa suportam apenas uma família de IP, que é uma informação necessária para o serviço AAA e PCRF. Para indicar essas informações, o AVP do Juniper-Network-Family-Indicator foi alocado do espaço Juniper Vendor-ID (2636) VSA na Tabela 3.

Tabela 3: Indicador de Família AVP

Nome do AVP	ID do fornecedor	Tipo de AVP	Tipo de diâmetro	Bandeira de diâmetro
Indicador de família de rede da Juniper	2636	10010	Enumeração	V

O sistema cliente (roteador) envia o AVP Juniper-Network-Family-Indicator para indicar quais famílias de rede estão associadas à solicitação de serviço e são suportadas pelo assinante. Quando você configura o AVP do Juniper-Network-Family-Indicator para indicar a família de rede associada, o sistema envia as informações para o PCRF. O atributo Juniper-Network-Family-Indicator tem quatro valores:

• NÃO ESPECIFICADO (0)

• IPV4_FAMILY (1)

• IPV6_FAMILY (2)

• IPV4_IPV6_FAMILY (3)

Os clientes de telefonia fixa geralmente controlam os serviços do usuário apenas por meio do PCRF e usam o OCS como um mecanismo conveniente de monitoramento de uso em tempo real, e não como uma unidade de fiscalização. Para diminuir o número de possíveis configurações erradas do OCS, inclua a force-continue declaração no nível da [edit access ocs partition partition-name] hierarquia para forçar o PCEF de banda larga (BPCEF) a limitar o impacto de respostas negativas do OCS e expirações de cota e para impedir o envio de notificações do OCS para grupos de classificação afetados. Sempre que o PCEF recebe uma resposta negativa a qualquer grupo relatado, ele para de relatar esse grupo ao OCS.

Ambiente do Junos OS

Existem três categorias de perfis dinâmicos no ambiente do Junos OS:

• perfis dinâmicos do cliente

• cos-service-dynamic-profiles

• perfis dinâmicos de serviço de firewall

Client-dynamic-profiles e cos-service-dynamic-profiles definem largura de banda e outras características dos serviços fornecidos a um assinante; Os perfis de serviço de firewall executam filtragem e contagem de uso. Para todas as categorias de perfis dinâmicos, o nome do perfil dinâmico de serviço é usado como o valor de um AVP de nome de regra de cobrança.

Quando o perfil dinâmico de serviço não tem variáveis ou quando os padrões fornecidos na definição de perfil dinâmico de serviço são solicitados, nenhum elemento adicional é necessário. Para fornecer valores personalizados para um perfil dinâmico de serviço, use o AVP de definição de regra de cobrança com VSAs adicionais.

O PCRF usa VSAs de substituição da Juniper existentes (Vendor-ID 2636 e Tipo 2024) para fornecer atributos como pares nome-valor. O PCRF também pode incluir parâmetros como notação posicional para parte do nome da regra. O AVP de informações de redirecionamento (ID do fornecedor 10415 e tipo 1085) fornece um valor para o parâmetro URL de redirecionamento.

Para cada nome de parâmetro de perfil dinâmico de serviço possível solicitado pelos clientes, um novo VSA de parâmetro da Juniper é definido. A Tabela 4 descreve o conjunto inicial de VSAs fixos da Juniper-Parameter.

Tabela 4: Conjunto inicial de VSAs fixos de parâmetro da Juniper

Parâmetro	Nome do VSA	ID do fornecedor	Digite	Tipo de diâmetro
Cos-TCP	juniper-param-cos-tcp	2636	10005	UTF8String
V4-Firewall-Filtro-de-Entrada	juniper-param-v4-firewall-filtro-de-entrada	2636	10006	UTF8String
V4-Firewall-Saída-Filtro	juniper-param-v4-firewall-filtro de saída	2636	10007	UTF8String
V6-Firewall-Filtro-de-Entrada	juniper-param-v6-firewall-filtro-de-entrada	2636	10008	UTF8String
V6-Firewall-Filtro de Saída	juniper-param-v6-firewall-filtro de saída	2636	10009	UTF8String

Se os parâmetros ou o identificador de serviço e o grupo de classificação precisarem ser indicados pelo PCRF, o AVP de definição de regra de cobrança é usado; caso contrário, o AVP Charging-Rule-Name é usado.

Para casos em que há uma combinação de Identificador de Serviço e Grupo de Classificação, ou quando apenas o Identificador de Serviço ou apenas o Grupo de Classificação é especificado, a combinação deve ser exclusiva entre as regras instaladas para um assinante. Você configura o service-context-id no roteador.

Login de assinante

O roteador envia uma solicitação de CCR de diâmetro contendo um conjunto fixo de informações necessárias para um gerenciador de políticas (PCRF) e recebe uma resposta CCA contendo políticas e outras informações. O provisionamento Gx é habilitado para assinantes quando você inclui a provisioning-order pcrf instrução no nível de [edit access profile profile-name] hierarquia. Quando um aplicativo solicita AAA para ativar a sessão do assinante, o roteador envia uma mensagem CCR-GX-I (onde eu represento INITIAL_REQUEST) ao PCRF para solicitar um conjunto de correções de informações de provisionamento para a sessão assinante e recebe uma mensagem de resposta CCA-GX-I contendo políticas e outras informações, incluindo o AVP de código de resultado (código AVP 268).

Quando você configura a provisioning-order declaração no perfil de acesso, o módulo PCEF de banda larga (BPCEF) envia uma solicitação de provisionamento ao PCRF durante a ativação do cliente. Os exemplos a seguir mostram uma troca de pacotes CCR-GX-I e CCA-GX-I:

Exemplo de pacote CCR-GX-I

Observação:

O bit T (mensagem potencialmente retransmitida) é recalculado quando o CCR-GX-I é reenviado. Esse sinalizador é definido após um procedimento de failover de link para remover solicitações duplicadas.

Exemplo de pacote CCA-GX-I

Observação:

Se nenhum AVP de instalação de regra for definido no CCA-GX-I, a regra padrão será instalada.

Todos os gatilhos de eventos, incluindo aqueles ainda não definidos, são aceitáveis. No entanto, apenas alguns gatilhos de evento realmente geram eventos quando implementados.

O PCRF retorna uma mensagem CCA-GX-I que inclui o AVP de código de resultado (código AVP 268) que mapeia para as categorias de resultado listadas na Tabela 5.

Tabela 5: Categorias de código de resultado AVP

Valor de Result-Code-AVP	Categoria de resultado
SUCCESS(2001), LIMITED_SUCCSS(2002) e mensagem válida	Concessão
AUTHENTICATION_REJECTED(4001), UNKNOWN_SESSION_ID(5002), AUTHORIZATION_REJECTED(5003) e USER_UNKNOWN(5030)	Negar
UNABLE_TO_DELIVER(3002), REALM_NOT_SERVED(3003), TOO_BUSY(3004), LOOP_DETECTED(3005) e REDIRECT_INDICATION(3006)	Falha
Todos os outros AVPs de código de resultado de falha permanente de diâmetro maiores e iguais a 5000, e todos os AVPs de código de resultado de erro de protocolo de diâmetro maiores e iguais a 3000 e menores que 4000	Falha permanente
Outros AVPs com código de resultado para mensagem inválida ou sem resposta	Falha

Conforme mostrado na Tabela 6, o processamento da resposta CCA-GX-I depende de três fatores:

• Se o tempo limite da decisão local expirou

• A definição da decisão local

• A categoria de resultado

A Tabela 6 também contém ações de expiração de tempo limite de decisão local do PCRF.

Tabela 6: Processamento de resposta CCA-GX-I

Tempo limite de decisão local do PCRF	Decisão local do PCRF	Categoria de resultado	Ação
Não expirado	–	Concessão	Limpe o temporizador de decisão local, aplique as regras do CCA-GX-I, notifique o Sistema de Cobrança Online (OCS) e, em seguida, confirme a ativação do assinante.
Não expirado	–	Negar	Limpe o temporizador de decisão local e falhe na ativação do assinante.
Não expirado	–	Falha	Repita o CCA-GX-I até que a decisão local expire.
Não expirado	Concessão	Falha permanente	Limpe o temporizador de decisão local, aplique a regra padrão, confirme a ativação do assinante e, em seguida, continue repetindo o CCA-GX-I.
Não expirado	Negar	Falha permanente	Falhar na ativação do assinante e iniciar o processo de logout do assinante.
Ao expirar	Concessão	–	Aplique a regra padrão, continue repetindo o CCA-GX-I indefinidamente e confirme a ativação do assinante.
Ao expirar	Negar	–	Falhar na ativação do assinante e iniciar o processo de logout do assinante.
Expirado	Concessão	Concessão	Se o CCA-GX-I contiver regras, remova as regras padrão e instale as regras recebidas e, em seguida, notifique o OCS e confirme a ativação do assinante.
Expirado	Concessão	Negar	Faça logout do cliente.
Expirado	Concessão	Falha	Continue repetindo o CCA-GX-I indefinidamente.
Expirado	Concessão	Falha permanente	Faça uma pausa longa e reinicie novamente o CCA-GX-I.
Expirado	Negar	Negar	Se o assinante ainda estiver saindo, ignore o assinante; caso contrário, nenhuma ação será necessária.

Um login de assinante inicia a seguinte sequência de eventos:

1. Um aplicativo cliente — como DHCP, PPP ou sessões de assinante estáticas — solicita ao AAA para autenticar o assinante.

2. A autenticação começa se o perfil de acesso do assinante especificar a autenticação RADIUS. O login continua quando a autenticação é bem-sucedida. O login falha quando a authentication-order instrução no perfil não especifica a autenticação RADIUS ou nenhuma autenticação. O logon também falha quando a autenticação falha.

3. Os serviços padrão são ativados para o assinante. Todos os serviços que o servidor de autenticação inclui na concessão de autenticação são ativados. Além disso, um serviço padrão pode ter sido configurado para o aplicativo cliente.

4. Se o perfil de acesso do assinante especificar o provisionamento Gx, o roteador inicia a troca de mensagens Gx enviando uma mensagem CCR-GX-I ao PCRF. O roteador espera que o PCRF responda com uma mensagem CCA-GX-I dentro de um período de tempo limite não configurável.

   Quando o PCRF responde dentro do período de tempo limite e inclui o AVP Charging-Rule-Install na mensagem CCA-GX-I, o login do assinante é atrasado enquanto o roteador desativa todos os serviços padrão e tenta ativar os serviços especificados.

   • Se todos os serviços especificados estiverem ativados, o login será concluído.

   • Se algum dos serviços não puder ser ativado, o roteador envia ao PCRF uma mensagem CCR-GX-U (onde U representa UPDATE_REQUEST) com o status dos serviços (um relatório de regra). O PCRF responde a essa mensagem com um CCA-GX-U que pode conter um novo conjunto de serviços para ativação.

   • O roteador ignora todos os serviços padrão, mesmo que a mensagem CCA-GX-I não inclua nenhum serviço. Nessa circunstância, nenhum serviço é ativado.

   Se o PCRF não retornar um CCA-GX-I dentro do período de tempo limite, o login do assinante será concluído.

   • O roteador procura primeiro os serviços retornados do servidor de autenticação e ativa os que encontra. Se nenhum desses serviços for encontrado, o roteador ativará todos os serviços padrão configurados localmente. O login do assinante é concluído quando a ativação do serviço padrão é bem-sucedida, mas falha quando qualquer serviço padrão falha ao ser ativado. Como os serviços padrão não precisam estar presentes, o logon também é concluído quando nenhum serviço padrão é encontrado.

   • Se o login for concluído (com ou sem um serviço padrão), o roteador reenvia periodicamente a mensagem CCR-GX-I para o PCRF. Se o PCRF retornar subsequentemente um CCA-GX-I, o roteador desativa o serviço padrão, se houver, e então ativa todos os serviços incluídos no CCA-GX-I. Se a mensagem não incluir nenhum serviço, nenhum serviço será ativado, nem mesmo um serviço padrão.

   • Se algum dos serviços contidos no CCA-GX-I não puder ser ativado, o roteador envia ao PCRF uma mensagem CCR-GX-U com o status dos serviços (um relatório de regras). O PCRF responde a essa mensagem com um CCA-GX-U que pode conter um novo conjunto de serviços para ativação.

Recuperação de erro de login do assinante

A partir do Junos Release 20.1R1, você pode configurar o roteador para se recuperar de certos erros do servidor PCRF reinicializando a sessão do assinante para ressincronizar os estados do roteador e do servidor PCRF. Alguns servidores PCRF podem não lidar adequadamente com uma situação em que as mensagens CCA-GX-I enviadas ao roteador são perdidas. Quando o roteador tenta enviar novamente o CCR-GX-I para o PCRF, o servidor fica fora de sincronia com o roteador porque já enviou uma resposta e não está ciente de que o roteador não recebeu a mensagem. Essa incompatibilidade de estado pode levar a um dos seguintes erros:

• O servidor PCRF responde à nova tentativa com um CCA-GX-I que contém o Código de Resultado de Diâmetro AVP (Código 268) com um valor de 5012 (DIÂMETRO INCAPAZ DE CUMPRIR). Isso é considerado uma falha permanente (Tabela 5).

• O servidor PCRF envia um RAR. O servidor espera que a sessão esteja ativa porque enviou o CCA-GX-I para o roteador e não sabe que a mensagem não foi recebida. O servidor pode enviar qualquer uma das seguintes mensagens RAR:

  • RAR-GX-D para desconectar a sessão porque considera a sessão inválida

  • RAR-GX-A para ler informações sobre a sessão incorreta

  • RAR-GX-U para atualizar a sessão porque considera que a sessão está operando normalmente.

Você pode usar a configuração do PCRF local-decision para reinicializar a sessão do assinante em resposta a um ou ambos os erros.

• Inclua a reinit-on-failure opção para o erro de falha permanente.

• Incluir reinit-on-rar opção para o erro RAR.

Observação:

A operação de reinicialização tem estes requisitos de configuração adicionais:

• Você deve configurar a opção de decisão grant local.

• Você deve configurar o roteador para usar um ID de sessão estendido para que ele possa manter o estado da sessão original e da nova vinculada ao mesmo evento de login. Para fazer isso, configure a opção PCRF use-session-stamp .

A operação de reinicialização consiste nas seguintes etapas em ambos os casos:

1. O roteador envia uma solicitação de encerramento de sessão, CCR-GX-T, ao PCRF para encerrar a sessão. Isso é feito na tentativa de fazer com que o roteador e o servidor PCRF tenham o mesmo estado para esta sessão.

2. O roteador aguarda um período de tempo limite de reinicialização para receber um CCA-GX-T. Você pode usar a reinit-timeout opção para especificar um período diferente do padrão.

3. Se o roteador receber um CCA-GX-T dentro do período de tempo limite ou um CCA-GX-T não chegar antes que o tempo limite expire, então o roteador envia um CCR-GX-I para o PCRF com um novo ID de sessão estendido. O ID de sessão estendido é transmitido no Diameter Session-ID AVP (AVP código 263).

   O roteador forma o ID de sessão estendido anexando um carimbo de sessão que consiste na hora UTC em que o roteador cria o CCR-GX-I. Por exemplo, considere o seguinte AVP de ID de sessão de diâmetro. O ID da sessão é 23 e use-session-stamp não está configurado:

   Com use-session-stamp configurado, o carimbo de data/hora da sessão é anexado ao valor AVP:

A Tabela 7 fornece detalhes sobre como o roteador reage a esses erros com base no estado atual do PCRF local.

Tabela 7: Ações do roteador com base no estado local do PCRF

Estado local	Ação quando ocorre um erro de PCRF
local-active— O assinante está ativo com serviços padrão.	O roteador faz o seguinte: Transições para o local-reinit estado. Envia um CCR-GX-T para o PCRF. Inicia o temporizador de reinicialização de decisão local e aguarda a resposta CCA-GX-T do PCRF.
local-grant— O provisionamento de serviço padrão está em andamento.	Quando o provisionamento padrão é concluído, o roteador faz o seguinte: Transições para o local-reinit estado. Envia um CCR-GX-T para o PCRF. Inicia o temporizador de reinicialização de decisão local e aguarda a resposta CCA-GX-T do PCRF.
started— O temporizador de decisão local ainda está em execução.	O roteador faz o seguinte quando nenhum serviço padrão está configurado: Transições para o local-reinit estado. Envia um CCR-GX-T para o PCRF. Inicia o temporizador de reinicialização de decisão local e aguarda a resposta CCA-GX-T do PCRF. O roteador faz o seguinte quando os serviços padrão são configurados: Transições para o local-reinit-early estado. Comece a provisionar os serviços padrão. Quando o provisionamento padrão é concluído, o roteador faz o seguinte: Transições para o local-reinit estado. Envia um CCR-GX-T para o PCRF. Inicia o temporizador de reinicialização de decisão local e aguarda a resposta CCA-GX-T do PCRF.

Atualização do assinante

Sempre que ocorre um evento de disparo no roteador, uma solicitação de atualização é enviada ao PCRF. Os exemplos a seguir mostram uma troca de pacotes CCR-GX-U (em que U representa UPDATE_REQUEST) e CCA-GX-U:

Exemplo de pacote CCR-GX-U

Observação:

O bit T é recalculado quando o CCR-GX-U é reenviado.

Exemplo de pacote CCA-GX-U

O PCRF retorna uma mensagem CCA-GX-U que inclui o código de resultado AVP (código AVP 268) que mapeia para as categorias de resultados listadas na Tabela 8.

Tabela 8: Categorias de código de resultado - AVP

Valor de Result-Code-AVP	Categoria de resultado
SUCCESS(2001), LIMITED_SUCCSS(2002) e mensagem válida	Sucesso
UNABLE_TO_DELIVER(3002), REALM_NOT_SERVED(3003), TOO_BUSY(3004), LOOP_DETECTED(3005) e REDIRECT_INDICATION(3006)	Falha
Todos os outros AVPs de código de resultado de falha permanente de diâmetro maiores e iguais a 5000, e todos os AVPs de código de resultado de erro de protocolo de diâmetro maiores e iguais a 3000 e menores que 4000	Sucesso
Outros AVPs com código de resultado para mensagem inválida ou sem resposta	Falha

Logout do assinante

Quando o aplicativo cliente envia um aviso de logout assinante para AAA, o Gx envia uma mensagem CCR-GX-T (em que T representa TERMINATION_REQUEST) para notificar o PCRF de que a sessão de assinante provisionada está sendo encerrada.

Sempre que ocorre um evento de disparo no roteador, uma solicitação de encerramento é enviada ao PCRF. Os exemplos a seguir mostram uma troca de pacotes CCR-GX-T e CCA-GX-T:

Exemplo de pacote CCR-GX-T

Observação:

O bit T é recalculado quando o CCR-GX-T é reenviado.

Exemplo de pacote CCA-GX-T

O PCRF retorna uma mensagem CCA-GX-T que inclui o código de resultado AVP (código AVP 268) que mapeia para as categorias de resultado listadas na Tabela 9.

Tabela 9: Categorias de código de resultado AVP

Valor de Result-Code-AVP	Categoria de resultado
SUCCESS(2001), LIMITED_SUCCSS(2002) e mensagem válida	Sucesso
UNABLE_TO_DELIVER(3002), REALM_NOT_SERVED(3003), TOO_BUSY(3004), LOOP_DETECTED(3005) e REDIRECT_INDICATION(3006)	Falha
Todos os outros AVPs de código de resultado de falha permanente de diâmetro maiores e iguais a 5000, e todos os AVPs de código de resultado de erro de protocolo de diâmetro maiores e iguais a 3000 e menores que 4000	Sucesso
Outros AVPs com código de resultado para mensagem inválida ou sem resposta	Falha

Se o valor Result-Code for Success, o Gx notificará a AAA e a AAA notificará o aplicativo de que o logout foi concluído. Se o Gx não receber uma mensagem CCA-GX-T ou se o AVP do código de resultado tiver qualquer outro valor ou estiver ausente, a solicitação de encerramento será repetida até que a mensagem CCA-GX-T seja retornada com sucesso. O roteador notifica o PCRF sobre logouts de assinantes enviando outra solicitação de CCR para ser confirmada por uma resposta CCA. O PCRF também pode usar solicitações RAR para forçar o logout do assinante ou para alterar os serviços aplicados.

Se o valor Result-Code for Failure, a solicitação será repetida.

Desconexão do assinante

Para realizar desconexões do assinante, o PCRF envia um RAR-GX-D (onde D representa DISCONNECT) e o BPCEF responde com uma mensagem RAA-GX-D.

Os exemplos a seguir mostram uma troca de pacotes RAR-GX-D e RAA-GX-D:

Exemplo de pacote RAR-GX-D

Exemplo de pacote RAA-GX-D

O PCRF retorna uma mensagem RAA-GX-T que inclui o código de resultado AVP (código AVP 268) que mapeia para as categorias de resultados listadas na Tabela 10.

Tabela 10: Categorias Result-Code-AVP

Valor de Result-Code-AVP	Categoria de resultado
DIAMETER_SUCCESS (2001)	A desconexão do assinante está em andamento ou o assinante não foi encontrado
DIAMETER_UNABLE_TO_COMPLY(5012)	O assinante não é removível
DIAMETER_TOO_BUSY(3004)	Muitas solicitações de desconexão pendentes

Observação:

O BPCEF contém espaço de buffer para pelo menos 512 mensagens RAR-GX-D ou RAA-GX-D.

Recuperação de falhas de conectividade

O Gx não depende do estado de conexão entre dispositivos para detectar interrupções do roteador ou PCRF, porque alguns eventos não afetam o estado da conexão e outros não são detectados quando há um relé de diâmetro ou proxy entre os dispositivos.

Para mitigar falhas de conectividade com o PCRF, o roteador usa os seguintes procedimentos de recuperação de falhas:

• Se o PCRF não estiver disponível e se você instalou e configurou um serviço padrão, o login do assinante continuará de acordo.

• As solicitações de provisionamento não confirmadas são reproduzidas indefinidamente ou até que o assinante faça logout.

• As solicitações de logout aguardam a conclusão do interrogatório final do OCS e, em seguida, todas as solicitações de logout não confirmadas são reproduzidas por 24 horas.

• O roteador usa a redundância de transporte de diâmetro padrão para se comunicar com PCRFs redundantes.

Um aspecto importante da tolerância a falhas do Gx é que as solicitações de login e encerramento do assinante são repetidas (repetidas) 24 horas até que uma resposta satisfatória seja recebida do PCRF. Você pode emitir o comando para limpar todos os assinantes do clear network-access pcrf subscribers PCRF.

Primeiro interrogatório ao OCS

Durante a primeira interrogação, o roteador envia uma solicitação de CCR de diâmetro contendo um conjunto fixo de informações necessárias para o servidor de carregamento do OCS. O servidor de cobrança do OCS responde com tempo de validade, grupos de classificação e cotas de uso.

Observação:

Para essa fase de implementação, o roteador permite o acesso do assinante sem esperar que o OCS responda, e o OCS sempre concede as cotas necessárias.

Para configurar uma lista de serviços de cobrança para comunicar informações com o OCS pelo protocolo Gy, configure a charging-service-list ocs declaração no nível da [edit access profile profile-name] hierarquia. Os exemplos a seguir mostram uma troca de pacotes CCR-GY-I e CCA-GY-I:

Observação:

O bit T (mensagem potencialmente retransmitida) é recalculado quando o CCR-GY-I é reenviado. Esse sinalizador é definido após um procedimento de failover de link para ajudar na remoção de solicitações duplicadas.

Exemplo de pacote CCR-GY-I

Exemplo de pacote CCA-GY-I

Interrogatório Intermediário para o OCS

Depois que o roteador envia um conjunto fixo de informações necessárias ao servidor de cobrança do OCS, o servidor de cobrança do OCS responde com tempo de validade, grupos de classificação e cotas de uso. O tempo de validade e as expirações de cota acionam eventos de interrogação intermediários.

Sempre que ocorre um evento de gatilho no roteador, uma solicitação de atualização é enviada ao OCS. Os exemplos a seguir mostram uma troca de pacotes CCR-GY-U (em que U representa UPDATE_REQUEST) e CCA-GY-U:

Exemplo de pacote CCR-GY-U

Exemplo de pacote CCA-GY-U

Interrogatório final ao OCS

Quando o aplicativo cliente envia um aviso de logout assinante para AAA, o Gy envia uma mensagem CCR-GY-T (em que T representa TERMINATION_REQUEST) para notificar o OCS de que o assinante provisionado está sendo encerrado.

Sempre que ocorre um evento de disparo no roteador, uma solicitação de encerramento é enviada ao OCS. Os exemplos a seguir mostram uma troca de pacotes CCR-GY-T e CCA-GY-T:

Exemplo de pacote CCR-GY-T

Exemplo de pacote CCA-GY-T

Recuperação de falhas de conectividade

O Gy não depende do estado de conexão entre dispositivos para detectar interrupções do roteador ou do OCS, porque alguns eventos não afetam o estado da conexão e outros não são detectados quando há um relé ou proxy de diâmetro entre os dispositivos.

Para atenuar falhas de conectividade com o OCS, o roteador usa os seguintes procedimentos de recuperação de falhas:

• Se o OCS não estiver disponível, você poderá configurar para permitir o tráfego de assinantes definindo a force-continue declaração no nível da [edit access ocs partition partition-name] hierarquia.

  Observação:

  A force-continue declaração é uma declaração de configuração necessária.

• Os primeiros interrogatórios e intermediários não confirmados são repetidos indefinidamente ou até que o assinante se desconecte.

• Os interrogatórios finais não reconhecidos são repetidos por até 24 horas.

• O roteador usa a redundância de transporte de diâmetro padrão para se comunicar com OCSs redundantes.

• Você pode configurar eventos de redundância de transporte para disparar falhas no tráfego do aplicativo.

Um aspecto importante da tolerância a falhas do Gy é que as solicitações de logon e encerramento do assinante são repetidas (repetidas) 24 horas até que uma resposta satisfatória seja recebida do OCS. Você pode emitir o comando para limpar todas as estatísticas do clear network-access ocs statistics OCS.

Abortar solicitações de sessão

O OCS pode emitir um ASR (Abort-Session-Request) quando o roteador da Série MX receptor coleta dados finais e publica a interrogação final. Depois que o roteador da Série MX recebe a resposta, ele para de atualizar o OCS para a sessão envolvida.

Backup SFTP do OCS

O stfp-backup é o primeiro mecanismo de backup implementado. As operações são controladas pelos seguintes parâmetros:

• accumulation-timeout – Os arquivos são gravados após o tempo de acúmulo de arquivos do primeiro envio do CCR-GY-T.

• accumulation-count: os arquivos são gravados depois que o número de solicitações é atendido para a contagem de contas de arquivos.

• accumulation-size – Os arquivos são gravados depois que seu tamanho atinge o limite de tamanho de acumulação.

• retry-interval – Cada operação de gravação com falha é repetida após esse intervalo até que o tempo limite de backup seja acumulado.

• response-timeout – O tempo limite na resposta do comando sftp individual.

Observação:

O servidor OCS SFTP-Backup é configurado por seu endereço, login, senha, diretório e prefixo de arquivo. Um diretório de destino existe por padrão, caso contrário, o diretório é criado. Se um arquivo de destino com o mesmo nome já existir, ele será substituído.

Benefícios do backup de arquivos Gy

• Fornece ainda outra maneira de lidar com a instabilidade da rede interna.

Interações de login

Essa sequência de eventos de logon é disparada pela detecção do fluxo de dados de serviço no PCEF. Normalmente, é um pacote DHCP DISCOVER ou PPPoE PADI enviado pelo assinante (o CPE):

1. O PCEF envia um CCR-GX-I ao PCRF com informações que identificam o assinante.

2. O PCRF responde com um CCA-GX-I ao PCEF com instruções sobre quais regras aplicar ao assinante.

3. O PCEF instala os serviços/regras solicitados para o assinante.

4. Se o OCS estiver sendo usado, o PCEF enviará a primeira interrogação ao OCS usando uma mensagem CCR-GY-I e o OCS enviará relatórios aplicáveis ao PCRF usando uma mensagem CCA-GY-I.

   Se configurado, o PCEF envia uma notificação por meio de uma mensagem CCR-GX-U para o PCRF após o processamento dos serviços/regras solicitados.

   • A regra é relatada ao PCRF como inativa quando ambos os itens a seguir são verdadeiros:

     • A instanciação do perfil dinâmico de serviço falha.

     • Resource-Allocation-Notification (ENABLE_NOTIFICATION) é definido para a regra de cobrança.

     Quando a regra é relatada como inativa, ela não afeta o login do assinante ou outras regras.

   • A regra é relatada ao PCRF como ativa quando todos os itens a seguir são verdadeiros:

     • A instanciação do perfil dinâmico de serviço é bem-sucedida.

     • Resource-Allocation-Notification (ENABLE_NOTIFICATION) é definido para a regra de cobrança.

     • O gatilho do evento SUCCESSFUL_RESOURCE_ALLOCATION é definido na solicitação.

   • O relatório não é enviado quando não há regras para relatar.

5. O PCRF responde com uma mensagem CCA-GX-U.

6. O PCEF ativa os serviços para o assinante.

Atualizar interações

Essa sequência de eventos de atualização é acionada por uma mensagem RAR-GX-U recebida pelo PCEF do PCRF.

1. Se a solicitação de atualização contiver qualquer instalação ou modificação de regras com grupos de classificação, o PCEF rejeitará a solicitação; caso contrário, ele confirma a solicitação enviando uma mensagem RAA-GX-U ao PCRF.

2. O PCEF inicia o processo de remoção e instalação do serviço.

3. O PCEF aguarda a conclusão do processo de remoção e instalação do serviço e, se aplicável, inicia o processo final de coleta de dados para relatórios ao OCS. Quando as estatísticas finais são coletadas, o PCEF envia uma solicitação CCR-GY-U para notificar o OCS. Isso faz parte do processo de remoção de um serviço existente em cada um dos seguintes casos:

   • Quando o serviço que está sendo removido tem um grupo de classificação.

   • Quando uma nova regra com um grupo de classificação foi adicionada.

   • Quando as regras com um grupo de classificação foram removidas e adicionadas.

4. O PCEF envia relatórios aplicáveis ao PCRF usando uma mensagem CCR-GX-U.

   • A regra é relatada ao PCRF como inativa quando ambos os itens a seguir são verdadeiros:

     • A instanciação do perfil dinâmico de serviço falha.

     • Resource-Allocation-Notification (ENABLE_NOTIFICATION) é definido para a regra de cobrança.

     Quando a regra é relatada como inativa, ela não afeta a atualização ou outras regras.

   • A regra é relatada ao PCRF como ativa quando todos os itens a seguir são verdadeiros:

     • A instanciação do perfil dinâmico de serviço é bem-sucedida.

     • Resource-Allocation-Notification (ENABLE_NOTIFICATION) é definido para a regra de cobrança.

     • O gatilho do evento SUCCESSFUL_RESOURCE_ALLOCATION é definido na solicitação.

   • O relatório não é enviado quando não há regras para relatar.

Interações de expiração de cota e tempo de validade

Para expirações de cota e interações de tempo de validade, o roteador envia uma interrogação intermediária ao OCS usando uma mensagem CCR-GY-U e processa a resposta do OCS.

Interações de conexão e monitoramento

Ao estabelecer uma conexão com o servidor PCRF, OCS ou Diameter Relay/Proxy, o daemon Diameter executa uma transação padrão de Capability Exchange Request (CER)/Capability Exchange Answer (CEA). Você usa a infraestrutura existente do Junos OS Diameter para configurar uma topologia apropriada com os recursos de redundância necessários. Além disso, você pode usar a mesma conexão de diâmetro para comunicações PCRF e OCS e outros aplicativos.

Os exemplos a seguir mostram dois cenários diferentes de conexão de comunicação:

Exemplo de CER com uma conexão dedicada usada para se comunicar com o PCRF

Observação:

Se você definir a send-origin-state-id declaração para o roteador no [edit access pcrf partition partition-name] nível de hierarquia ou [edit access ocs partition partition-name] , o Origin-State-Id será incluído nas mensagens de nível de diâmetro, como: CER, Device Watchdog Request (DWR)/Device Watchdog Answer (DWA) e Disconnect Peer Request (DPR)/Disconnect Peer Answer (DPA).

Exemplo de CER com uma conexão dedicada usada para se comunicar com o PCRF e o OCS

Observação:

O campo e o valor Auth-Application-Id: 4 são a ID do aplicativo de autenticação para o OCS. Essa é a diferença entre o primeiro e o segundo exemplos.

Você monitora e gerencia conexões usando mensagens DWR/DWA e DPR/DPA padrão.

Interações de logout

Essa sequência de eventos de logout é acionada por um dos seguintes:

• Uma solicitação de logout do assinante, como um pacote DHCP RELEASE ou PPPoE PADP.

• O PCEF recebe um RAR do PCRF com uma solicitação para encerrar uma sessão de assinante.

A seguinte sequência ocorre quando o logout é acionado:

1. A infraestrutura do sistema notifica o OCS de que o logout do assinante foi iniciado.

2. Se aplicável, o OCS inicia o processo final de coleta de dados.

   • Se o serviço que está sendo removido tiver um grupo de classificação, os dados finais desse serviço deverão ser relatados. O OCS inicia a coleta final de dados conforme necessário.

3. Tanto o PCRF quanto o PCEF aguardam a conclusão do processo final de interrogatório.

4. O PCEF envia uma solicitação de encerramento (mensagem CCR-GX-T) ao PCRF e aguarda a resposta (mensagem CCA-GX-T) do PCRF.

5. O PCEF conclui o processo de logout do assinante.

Mensagens Comuns de Upstream

As mensagens upstream para Credit Control Response for Initiation, Update and Termination (CCR-GX-I, CCR-GX-U e CCR-GX-T) e RAA-GX podem incluir as seguintes regras, parâmetros e dados:

• AVP de carimbo de data/hora do evento
• Notificações de instalação de regras de cobrança
• Comandos de acionamento de eventos

Mensagens comuns de downstream

As mensagens downstream para Credit Control Answer for Initiation and Update (CCA-GX-I e CCA-GX-U) e RAR-GX podem incluir as seguintes regras predefinidas com parâmetros e dados:

Observação:

A mensagem CCA-GX-T (Terminação) não está incluída como uma mensagem downstream.

• Comandos de instalação da regra de cobrança
• Comandos de remoção de regra de cobrança
• Comandos de acionamento de eventos