Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Informações de Apoio

Configurar

Diagrama de Rede

Tx-Expiry

Tempo limite da resposta

Failover de Sessão de Diâmetro

Mecanismo FH

Configuração do mecanismo FH

Comportamento Padrão do Mecanismo FH

Fluxo de chamada detalhado do mecanismo FH

Mecanismo de SU

Configuração do mecanismo de SU

Fluxos de chamada do mecanismo de SU

Configurações de exemplo de FH e SU

Verificar

Troubleshoot

Informações Relacionadas

Introduction

Este documento descreve como configurar os mecanismos de Tratamento de Falha (FH - Failure-Handling) e de Servidor Inalcançável (SU - Server-Unreachable) na interface Gy para resolver problemas encontrados no Sistema de Cobrança On-line (OCS - Online Charging System) ou em relação à conectividade entre a Função de Aplicação de Política e Cobrança (PCEF - Policy and Charging Implementation Function) e o OCS. As informações descritas neste documento aplicam-se às funcionalidades Home Agent (HA), Gateway General Packet Radio Service (GPRS) Support Node (GGSN) e Packet Data Network Gateway (PGW) executadas no Cisco 5000 Series Aggregated Services Router (ASR5K).

Prerequisites

Requirements

A Cisco recomenda que seu sistema atenda a esses requisitos para usar os mecanismos FH e SU:

- O ECS (Enhanced Charging Service) está disponível

- O PCEF existe dentro do HA, GGSN ou PGW

- Há conectividade de diâmetro adequada através do banco de dados

- O Pedido de Controlo de Crédito de Diâmetro (DCCA) está disponível

Componentes Utilizados

As informações neste documento são baseadas em todas as versões do ASR5K.

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. If your network is live, make sure that you understand the potential impact of any command.

Informações de Apoio

O PCEF é conectado ao OCS pela interface Gy, que usa Diameter como o protocolo base e DCCA. Este é o fluxo de mensagem entre o PCEF e o OCS:

- Credit Control Request (CCR) â Â  Esta mensagem é enviada do PCEF para o OCS. Há três tipos de mensagens CCR: Inicial, Atualizar e Terminar.

- Resposta de Controle de Crédito (CCA) â Â  Esta mensagem é enviada do OCS para o PCEF em resposta ao CCR. Há também três tipos de mensagens CCA: Inicial, Atualizar e Terminar.

- Solicitação de Reautorização (RAR) â Â  Esta mensagem é enviada do OCS para o PCEF quando uma nova autorização de sessão é necessária.

- Resposta de autorização (RAA) â Â  Esta é a resposta ao RAR do PCEF para o OCS.

A conectividade de diâmetro é estabelecida entre o PCEF e o OCS para ativar o fluxo de mensagem. Há a possibilidade de que o OCS envie mensagens negativas, a conexão de transporte pode falhar entre o PCEF e o OCS ou a mensagem pode expirar, o que pode causar uma falha no estabelecimento da sessão do assinante. Isso pode impedir que o assinante use serviços.

Esses dois mecanismos podem ser usados para resolver esse problema:

- O mecanismo FH

- O mecanismo SU

Configurar

Esta seção descreve as configurações necessárias para suportar os mecanismos FH e SU.

Diagrama de Rede

As informações neste documento usam esta topologia:

Tx-Expiry

Este é um temporizador de nível de aplicação para o DCCA que pode ser configurado nas configurações de controle de crédito de diâmetro. O valor pode variar entre 1 e 300 segundos.

Aqui está um exemplo:

[local]host_name(config-dcca)# diameter pending-timeout

Tempo limite da resposta

Este é um tempo limite de banco de dados e pode ser configurado nas configurações de ponto de extremidade de diâmetro. O valor pode variar entre 1 e 300 segundos.

Note: O valor configurado para esse temporizador deve ser maior do que o usado para o temporizador Tx-Expiry.

Aqui está um exemplo:

[context_name]host_name(config-ctx-diameter)# response-timeout

Failover de Sessão de Diâmetro

Esse recurso é usado para habilitar ou desabilitar o failover da sessão de controle de crédito de diâmetro, que permite que o sistema use um servidor secundário quando o servidor primário se tornar inalcançável. Isso é configurável nas configurações de controle de crédito de diâmetro.

Aqui está um exemplo:

local]host_name(config-dcca)# diameter session failover

Mecanismo FH

O mecanismo FH só opera se houver failover de sessão de diâmetro. O FH permite que o sistema escolha se deseja continuar a sessão e convertê-la em off-line ou encerrar a sessão quando ocorrer um erro de conexão ou de nível de mensagem.

Note: O FH está ativado e configurado por padrão.

Configuração do mecanismo FH

O mecanismo FH pode ser configurado nas configurações de controle de crédito de diâmetro. Esta é a sintaxe usada na configuração FH:

failure-handling { initial-request | terminate-request | update-request } { continue

[ go-offline-after-tx-expiry | retry-after-tx-expiry ] | retry-and-terminate,

[ retry-after-tx-expiry ] | terminate }

A primeira seção especifica o tipo de solicitação: Inicial (CCR-I), Atualizar (CCR-U) e Terminar (CCR-T).

A segunda seção especifica a ação que deve ser executada quando o mecanismo FH é ativado. Essas três ações são possíveis com o mecanismo FH:

- Continue â Â  Isso permite que a sessão continue e a converta para off-line. Esta função usa duas opções relacionadas à expiração de transmissão:

- Go-offline-after-tx-expire â Â  Isto começa a carregar offline após a expiração de Tx.

- Repetir após tx-expiração â Â  Isso repete o servidor secundário após a expiração de Tx.

- Tente novamente e termine â Â  Isso encerra a sessão após o sistema tentar novamente o servidor secundário, se o servidor secundário também não estiver disponível. Isso também usa a opção Repetir após tx-expirar, que repete o servidor secundário após a expiração de Tx.

- Encerre â Â  Isso encerra a sessão sem nenhuma tentativa de entrar em contato com o servidor secundário.

Comportamento Padrão do Mecanismo FH

Esta seção descreve o comportamento padrão do FH quando não há configuração presente. Por padrão, o mecanismo FH é ativado durante um Tempo Limite de Resposta (RT), exceto quando a ação Terminar é configurada.

Se um Credit-Control-Failure-Handling Attribute Value Pair (AVP) for recebido do servidor, as configurações recebidas serão aplicadas.

Aqui estão alguns exemplos:

- Solicitação inicial > Terminar

- Update-Request > Retry-and-Terminate

- Terminate-Request > Retry-and-Terminate

Fluxo de chamada detalhado do mecanismo FH

Esta seção descreve o fluxo de chamada detalhado do mecanismo FH com todas as opções possíveis.

Solicitação inicial

Configuração do CCFH

Comando CLI

Comportamento no Tx

Comportamento na RT

O secundário está ativo

Secundário está inativo

Continuar

requisição inicial

continuar

N/A

Continuar

Secundário

assume depois

RT

Offline após outro RT.

Não são executadas mais solicitações de cota

para qualquer grupo de classificação na sessão

após falha de DCCA (mesmo que

a conectividade com DCCA é restaurada)

requisição inicial

continue a ficar offline após

tx-expire

Off-line

N/A

Offline no Tx

Offline no Tx

requisição inicial

continue repetindo após

tx-expire

Continuar

N/A

Secundário

assume depois

Tx

Offline após outro Tx

Repetir e terminar

requisição inicial

repetir e terminar

N/A

Repetir

Secundário

assume depois

RT

Terminar após outro RT

requisição inicial

repetir e terminar

retry-after-tx-expire

Repetir

N/A

Secundário

assume depois

Tx

Terminar após outro Tx

Terminar

requisição inicial

terminar

Terminar

N/A

Terminar após Tx

Terminar após Tx

Atualizar-Solicitar

Configuração do CCFH

Comando CLI

Comportamento no Tx

Comportamento na RT

O secundário está ativo

Secundário está inativo

Continuar

update-request

continuar

N/A

Continuar

Secundário

assume depois

RT

Offline após outro RT

update-request

continue a ficar offline após

tx-expire

Off-line

N/A

Offline no Tx

Offline no Tx

update-request

continue repetindo após

tx-expire

Continuar

N/A

Secundário

assume depois

Tx

Offline após outro Tx

Repetir e terminar

update-request

repetir e terminar

N/A

Repetir

Secundário

assume depois

RT

Envia CCR-T após outro RT

update-request

repetir e terminar

retry-after-tx-expire

Repetir

N/A

Secundário

assume depois

Tx

Envia CCR-T após outro Tx

Terminar

update-request

terminar

Terminar

N/A

Envia CCR-T após Tx

Envia CCR-T após Tx

Terminate-Request

Configuração do CCFH

Comando CLI

Comportamento no Tx

Comportamento na RT

O secundário está ativo

Secundário está inativo

Continuar

terminate-request

continuar

N/A

Repetir

CCR-T é enviado

para secundário

após RT

Terminar após outro RT

terminate-request

continue a ficar offline após

tx-expire

Repetir

N/A

CCR-T é enviado

para secundário

após Tx

Terminar após outro Tx

terminate-request

continue repetindo após

tx-expire

Repetir

N/A

CCR-T é enviado

para secundário

após Tx

Terminar após outro Tx

Repetir e terminar

terminate-request

repetir e terminar

N/A

Repetir

CCR-T é enviado

para secundário

após RT

Terminar após outro RT

terminate-request

repetir e terminar

retry-after-tx-expire

Repetir

N/A

CCR-T é enviado

para secundário

após Tx

Terminar após outro Tx

Terminar

terminate-request

terminar

Terminar

N/A

Terminar após

Tx

Terminar após Tx

Mecanismo de SU

O mecanismo SU é semelhante ao mecanismo FH, mas fornece um controle mais granular sobre procedimentos de falha. Além da continuação da sessão após as falhas de nível de mensagem e conexão (transporte), esse mecanismo pode ser usado quando as respostas são lentas do OCS. Ele também fornece as opções para continuar a sessão por um período de tempo/esgotamento de cota antes do término, ou usar cota temporária configurável (volume e tempo) e novas tentativas de servidor configuráveis antes de uma sessão ser convertida para off-line ou encerrada.

Configuração do mecanismo de SU

O mecanismo SU pode ser configurado nas configurações de controle de crédito de diâmetro. A sintaxe usada na configuração da SU varia de acordo com a versão usada.

Para as versões 12.1 e anteriores, esta é a sintaxe usada para a configuração do mecanismo SU:

servers-unreachable { initial-request { continue | terminate [ after-timer-expiry

<timeout_period> ] } | update-request { continue | terminate [ after-quota-expiry

| aftertimer-expiry <timeout_period> ] } }

Para as versões 12.2 e posteriores, esta é a sintaxe usada para a configuração do mecanismo SU:

servers-unreachable { behavior-triggers { initial-request | update-request }

result-code { any-error | <result-code> [ to <end-result-code> ] }

| transport-failure [ response-timeout | tx-expiry ] | initial-request

{ continue [ { [ after-interim-time <timeout_period> ] [ after-interim-volume

<quota_value> ] } server-retries <retry_count> ] | terminate [ {

[ after-interim-time <timeout_period> ] [ after-interim-volume <quota_value> ]

} server-retries <retry_count> | after-timer-expiry <timeout_period> ] }

| update-request { continue [ { [ after-interim-time <timeout_period> ]

[ after-interim-volume <quota_value> ] } server-retries <retry_count> ]

| terminate [ { [ after-interim-time <timeout_period> ] [ after-interim-volume

<quota_value> ] } server-retries <retry_count> ] | after-quota-expiry |

after-timer-expiry <timeout_period> ] } }

Note: Em versões anteriores à versão 12.2, havia flexibilidade para configurar os mecanismos FH e SU de forma independente; no entanto, nas versões 12.2 e posteriores, o mecanismo SU tem precedência sobre o mecanismo FH quando configurado.

Se o servidor retornar o AVP CC-FH e o mecanismo SU for configurado para um conjunto de acionadores de comportamento, a configuração do SU será aplicada; caso contrário, o valor de AVP CC-FH é aplicado. Por padrão, os códigos de resultado como 3002, 3004 e 3005 estão sob falha de entrega e são tratados como RTs.

Essas ações são possíveis com o mecanismo SU:

- Comportamento-Disparo â Â  Especifica o tipo de mensagem que pode ser Solicitações iniciais (CCR-I) ou Solicitações de atualização (CCR-U). Há três opções disponíveis para esses acionadores:

- Result-Code â Â  Isso permite a configuração de códigos de resultado específicos, intervalo de códigos de resultado (3000-5999) ou qualquer erro junto com o tipo de mensagem.

- Transport-Failure â Â  Esta especificação ativa o comportamento em caso de falha de transporte, que é retrocompatível com a versão 12.0. Há duas opções disponíveis para esta configuração:

- Response-Timeout â Â  Esta opção aciona o comportamento em relação à RT e deve sempre ser usada com falhas de transporte.

- Tx-Expiry âÂ  Â  Esta opção aciona o comportamento após Tx-expiração e deve sempre ser usada com falha de transporte.

- Ações â Â  Especifica a ação que é executada quando ocorre um disparo de SU para CCR-I ou CCR-U. Essa ação varia de acordo com o tipo de mensagem e a versão do software.

- Continue â Â  Isso permite que a sessão seja convertida para off-line e continue. Não há mais opções disponíveis para o uso desta ação em versões anteriores à versão 12.2. Nas versões 12.2 e posteriores, as opções de cota temporária, novas tentativas de servidor e expiração de temporizador estão disponíveis para configuração com esta ação.

- Terminar â Â  Isso resulta no encerramento da sessão quando o servidor se torna inalcançável. Essa ação permite as opções de cota temporária, novas tentativas de servidor e expiração após o temporizador.

Essas opções podem ser usadas com a ação Continuar ou Terminar:

- Após o tempo interino â Â  Esta opção permite a continuação ou encerramento da chamada após o período de tempo limite interino. Isso é semelhante a uma cota de tempo antes da ação ser executada. O valor é formatado em segundos e pode variar entre 1 e 4.294.967.295.

- Após o volume interino â Â  Esta opção atribui a cota temporária e permite a continuação ou o término da sessão antes do esgotamento do volume configurado. O valor é formatado em bytes e pode variar entre 1 e 4.294.967.295.

- Repetir o servidor â Â  Esta opção permite que o PCEF repita o OCS antes da continuação ou do término da sessão. A contagem de novas tentativas pode ser configurada e o valor varia entre 0 e 65.535. Se o valor for zero, a nova tentativa não ocorrerá e a ação será aplicada imediatamente.

Note: As opções de tempo interino e de volume interino são sempre usadas com a opção server-retries, ou todas as três podem ser usadas simultaneamente e aplicadas às ações de continuação e de término. As opções de tempo intermédio e de volume intermediário também atribuem tempo, bem como cota de volume, e a cota que está esgotada primeiro aciona a nova tentativa do servidor.

-  Â  pós-expiração do temporizador Esta opção especifica a duração (em segundos) para a qual as sessões permanecem no status offline antes que ocorra a terminação. Os valores podem variar entre 1 e 4.294.967.295. Esta opção só se aplica a ações de término.

- Após a expiração da cota â Â  Esta opção encerra a sessão após o esgotamento da cota já atribuída.

Aqui estão algumas informações importantes para lembrar:

- As opções pós-interino, pós-intercalação-volume e servidor-repetições podem ser usadas individualmente ou em combinação, e são aplicáveis às ações de continuação e término.

- A opção de expiração de cota só é aplicável para o disparador de comportamento Update-Requests.

- A opção pós-expiração só é aplicável para a ação de fim.

- As opções pós-interino, pós-intercalação-volume e servidor-repetições só se aplicam às versões 12.2 e posteriores.

- Se houver suporte para failover de sessão de diâmetro (e configurado), o servidor secundário será sempre contatado antes que o mecanismo SU seja acionado.

- O servidor que foi contatado pela última vez antes do mecanismo SU ser disparado é sempre contatado quando o tempo temporário ou o volume temporário é esgotado e a opção de novas tentativas do servidor é configurada com um valor maior que zero. Por exemplo, se o OCS1 for tentado primeiro e o OCS2 for tentado após um erro no OCS1, a comunicação com o OCS2 acionará o mecanismo SU. Durante a tentativa de nova tentativa do servidor, o OCS2 é contatado primeiro e depois o OCS1 se uma resposta negativa for recebida do OCS2.

Fluxos de chamada do mecanismo de SU

O mecanismo SU pode ser acionado por uma falha do CCR-I ou do CCR-U, e a causa pode ser um código de erro, falha de transporte, Tx-expiração ou RT. A ação pode ser uma alocação de cota temporária (tempo e/ou volume), contagem de novas tentativas do servidor, valor do temporizador (faz com que a sessão fique off-line durante um tempo especificado e somente para término) ou expiração da cota (somente para o CCR-U e término) antes que a sessão fique off-line ou termine.

A cota temporária é fornecida por sessão, não por grupo de classificação (RG) em cenários de controle de crédito de vários serviços (MSCC).

Há uma possibilidade de que o servidor primário dispare a falha de transporte e o servidor secundário acionem o Tx-expire ou o response-timeout. Nesse cenário, o erro mais recente é considerado o disparador da falha.

Se o mecanismo SU não estiver configurado para nenhum disparador de falha, o mecanismo FH será acionado.

Note: As seções a seguir fornecem alguns exemplos de fluxo de chamada relacionados ao mecanismo SU. Esses fluxos de chamada são fornecidos sob o pressuposto de que o failover de sessão de diâmetro é suportado e o servidor secundário é configurado com um valor de expiração de Tx inferior ao valor de RT. Além disso, supõe-se que o mecanismo SU esteja configurado para falha de transporte, Tx-expiração e RT.

Solicitação inicial sem desconexão de sessão

Aqui está o fluxo de mensagens para este cenário:

1. O PCEF envia um CCR-I ao OCS.

2. Foi detectado um tempo limite ou uma falha de transporte. Se a falha de transporte for detectada, o PCEF imediatamente repetirá com o servidor secundário; caso contrário, a expiração de Tx é acionada.

3. Se o servidor secundário também tiver uma falha de transporte ou tempo limite, o mecanismo SU será acionado. Isso ocorre imediatamente em caso de falhas de transporte ou após o tx-expiração por um tempo limite.

4. Se o volume e/ou o tempo intermediários estiverem configurados, a cota temporária será atribuída à sessão.

5. Após esgotamento da cota temporária (tempo ou volume) e se o valor de novas tentativas do servidor for maior que zero, o CCR-I será novamente enviado ao servidor que acionou o mecanismo SU. Se houver outra falha, o CCR-I será enviado para outro servidor.

6. Se a falha de transporte ou Tx-timeout for detectada novamente, as Etapas 2 a 5 serão repetidas até que o valor de novas tentativas do servidor seja esgotado ou uma resposta bem-sucedida não venha do OCS.

7. Se o problema ainda existir, a sessão será continuada (convertida para off-line) ou encerrada de acordo com a configuração.

Note: A cota temporária consumida enquanto a sessão entra no modo SU devido ao CCR-I não é relatada no próximo CCR-I. Todo o contingente provisório utilizado é comunicado na CCR-U, que se segue ao êxito da CCA-I.

Solicitação inicial com desconexão de sessão

Aqui está o fluxo de mensagens para este cenário:

1. O PCEF envia um CCR-I ao OCS.

2. Foi detectado um tempo limite ou uma falha de transporte. Se a falha de transporte for detectada, o PCEF imediatamente repetirá com o servidor secundário; caso contrário, a expiração de Tx é acionada.

3. Se o servidor secundário também tiver uma falha de transporte ou tempo limite, o mecanismo SU será acionado. Isso ocorre imediatamente em caso de falhas de transporte ou após o tx-expiração por um tempo limite.

4. Se o volume e/ou o tempo intermediários estiverem configurados, a cota temporária será atribuída à sessão.

5. Após esgotamento da cota temporária (tempo ou volume) e se o valor de novas tentativas do servidor for maior que zero, o CCR-I será novamente enviado ao servidor que acionou o mecanismo SU. Se houver outra falha, o CCR-I será enviado para outro servidor.

6. Se a falha de transporte ou Tx-timeout for detectada novamente, as Etapas 2 a 5 serão repetidas até que o valor de novas tentativas do servidor seja esgotado ou uma resposta bem-sucedida não venha do OCS. Neste ponto, a sessão é desconectada sem o consumo de toda a cota provisória.

7. Após o término da sessão, o PCEF envia novamente o CCR-I para iniciar uma nova sessão. Se isso for bem-sucedido, o PCEF envia o CCR-T, que relata toda a cota temporária que foi usada.

Atualizar-Solicitar sem Desconectar Sessão

Aqui está o fluxo de mensagens para este cenário:

1. O PCEF envia um CCR-U ao OCS.

2. Foi detectado um tempo limite ou uma falha de transporte. Se a falha de transporte for detectada, o PCEF imediatamente repetirá com o servidor secundário; caso contrário, a expiração de Tx é acionada.

3. Se o servidor secundário também tiver uma falha de transporte ou tempo limite, o mecanismo SU será acionado. Isso ocorre imediatamente em caso de falhas de transporte ou após o tx-expiração por um tempo limite.

4. Se o volume e/ou o tempo intermediários estiverem configurados, a cota temporária será atribuída à sessão.

5. Após esgotamento da cota temporária (tempo ou volume) e se o valor de novas tentativas do servidor for maior que zero, o CCR-U será enviado novamente ao servidor que acionou o mecanismo SU. Se houver outra falha, um CCR-U será enviado para outro servidor que contém a cota consumida não relatada inteira.

6. Se a falha de transporte ou Tx-timeout for detectada novamente, as Etapas 2 a 5 serão repetidas até que o valor de novas tentativas do servidor seja esgotado ou uma resposta bem-sucedida não venha do OCS.

7. Toda a cota consumida é informada ao OCS com o CCR-U bem-sucedido.

8. Se o problema ainda existir, a sessão será continuada (convertida para off-line) ou terminada de acordo com a configuração após o esgotamento do valor máximo de repetição.

Atualizar-Solicitar com Desconexão de Sessão

Aqui está o fluxo de mensagens para este cenário:

1. O PCEF envia um CCR-U ao OCS.

2. Foi detectado um tempo limite ou uma falha de transporte. Se a falha de transporte for detectada, o PCEF imediatamente repetirá com o servidor secundário; caso contrário, a expiração de Tx é acionada.

3. Se o servidor secundário também tiver uma falha de transporte ou tempo limite, o mecanismo SU será acionado. Isso ocorre imediatamente em caso de falhas de transporte ou após o tx-expiração por um tempo limite.

4. Se o volume e/ou o tempo intermediários estiverem configurados, a cota temporária será atribuída à sessão.

5. Após esgotamento da cota temporária (tempo ou volume) e se o valor de novas tentativas do servidor for maior que zero, o CCR-U será enviado novamente ao servidor que acionou o mecanismo SU. Se houver outra falha, um CCR-U será enviado para outro servidor que contém a cota consumida não relatada inteira.

6. Se a falha de transporte ou Tx-timeout for detectada novamente, as Etapas 2 a 5 serão repetidas até que o valor de novas tentativas do servidor seja esgotado ou uma resposta bem-sucedida não venha do OCS. Neste ponto, a sessão é desconectada antes de consumir toda a cota temporária.

7. O PCEF envia um CCR-T ao OCS para relatar toda a cota consumida.

8. Se o OCS responder com um código de resultado 2002, os relatórios adicionais não serão necessários.

Atualizar-Solicitar com Sessão Desconhecida

Aqui está o fluxo de mensagens para este cenário:

1. O PCEF envia um CCR-U ao OCS.

2. Foi detectado um tempo limite ou uma falha de transporte. Se a falha de transporte for detectada, o PCEF imediatamente repetirá com o servidor secundário; caso contrário, a expiração de Tx é acionada.

3. Se o servidor secundário também tiver uma falha de transporte ou tempo limite, o mecanismo SU será acionado. Isso ocorre imediatamente em caso de falhas de transporte ou após o tx-expiração por um tempo limite.

4. Se o volume e/ou o tempo intermediários estiverem configurados, a cota temporária será atribuída à sessão.

5. Após esgotamento da cota temporária (tempo ou volume) e se o valor de novas tentativas do servidor for maior que zero, o CCR-U será enviado novamente ao servidor que acionou o mecanismo SU. Se houver outra falha, um CCR-U será enviado para outro servidor que contém a cota consumida não relatada inteira.

6. O OCS responde com um código de resultado 5002 (ID de sessão desconhecida) para o CCR-U, o que é possível no cenário em que o OCS reiniciou e perdeu as informações de ID da sessão.

7. O PCEF inicia uma nova sessão com o CCR-I e recebe o CCA-I.

8. O PCEF relata toda a cota temporária consumida via CCR-U em mensagens subsequentes.

Atualização-solicitação com vários RGs (cenário MSCC)

Aqui está o fluxo de mensagens para este cenário:

1. O PCEF envia o CCR-U para RG1 ao OCS.

2. Foi detectado um tempo limite ou uma falha de transporte. Se a falha de transporte for detectada, o PCEF imediatamente repetirá com o servidor secundário; caso contrário, a expiração de Tx é acionada.

3. Se o servidor secundário também tiver uma falha de transporte ou tempo limite, o mecanismo SU será acionado. Isso ocorre imediatamente em caso de falhas de transporte ou após o tx-expiração por um tempo limite.

4. Se o volume e/ou o tempo intermediários estiverem configurados, a cota temporária será atribuída à sessão

5. Neste ponto, o RG2 também esgota toda a cota atribuída, mas não inicia o CCR-U porque a sessão já está no modo SU e começa a consumir a cota temporária.

6. Após esgotamento da cota temporária (tempo ou volume) e se o valor de novas tentativas do servidor for maior que zero, o CCR-U será enviado novamente ao servidor que acionou o mecanismo SU. Se houver outra falha, um CCR-U será enviado a outro servidor que contém a cota consumida não relatada inteira para ambos os RGs.

7. Se a falha de transporte ou Tx-timeout for detectada novamente, as Etapas 2 a 6 serão repetidas até que o valor de novas tentativas do servidor seja esgotado ou uma resposta bem-sucedida não venha do OCS.

8. Toda a cota consumida é informada ao OCS com o CCR-U bem-sucedido.

9. Se o problema ainda existir, a sessão será continuada (convertida para off-line) ou terminada de acordo com a configuração após o esgotamento do valor máximo de repetição.

Terminate-Request

Aqui está o fluxo de mensagens para este cenário:

1. O PCEF envia um CCR-T ao OCS.

2. Foi detectado um tempo limite ou uma falha de transporte. Se a falha de transporte for detectada, o PCEF imediatamente repetirá com o servidor secundário; caso contrário, a expiração de Tx é acionada.

3. Se o servidor secundário também tiver uma falha de transporte ou tempo limite, a sessão será removida.

Tratamento de código de erro CCR

Aqui está o fluxo de mensagens para este cenário:

1. O PCEF envia um CCR ao OCS e o OCS responde com um código de erro.

2. O código de erro é configurado estaticamente no mecanismo SU.

3. O PCEF fornece a cota temporária sem uma nova tentativa para o servidor secundário.

Configurações de exemplo de FH e SU

Esta seção fornece um exemplo de configuração para os mecanismos FH e SU. Quando os mecanismos FH e SU são configurados, a SU tem precedência sobre a FH para o mesmo disparador de comportamento.

Aqui está um exemplo:

credit-control group test

diameter origin endpoint test

diameter peer-select peer test

quota volume-threshold percent 10

diameter pending-timeout 80 deciseconds msg-type any

diameter session failover

trigger type rat lac

apn-name-to-be-included virtual

quota request-trigger exclude-packet-causing-trigger

failure-handling initial-request continue retry-after-tx-expiry

servers-unreachable initial-request terminate after-interim-volume 200

after-interim-time 3600 server-retries 0

servers-unreachable behavior-triggers initial-request transport-failure

tx-expiry

servers-unreachable update-request continue after-interim-volume 200

after-interim-time 3600 server-retries 50

servers-unreachable behavior-triggers update-request transport-failure

tx-expiry

Verificar

Para verificar se sua configuração funciona corretamente, insira o comando show ative-charge service <service name>:

# show active-charging service name test

Service name: test

TCP Flow Idle Timeout : 300 (secs)

UDP Flow Idle Timeout : 300 (secs)

ICMP Flow Idle Timeout : 300 (secs)

ICMP Flow Idle Timeout : 300 (secs)

ALG Media Idle Timeout : 120 (secs)

TCP Flow-Mapping Idle Timeout : 300 (secs)

UDP Flow-Mapping Idle Timeout : Not Configured

Deep Packet Inspection: Enabled

Passive Mode : Disabled

CDR Flow Control : Enabled

CDR Flow Control Unsent Queue Size: 75

Unsent Queue high watermark: 56

Unsent Queue low watermark: 18

Content Filtering: Disabled

Dynamic Content Filtering: Disabled

URL-Blacklisting: Disabled

URL-Blacklisting Match-method: Exact

Content Filtering Match-method: Generic

Interpretation of Charging-rule-base-name: active-charging-group-of-ruledefs

Selection of Charging-rule-base AVP : Last

Credit Control:

Group         : test

Mode                   : diameter

APN-name-to-be-included: gn

Trigger-Type           : N/A

Failure-Handling:

Initial-Request  : continue retry-after-tx-expiry

Update-Request   : retry-and-terminate

Terminate-Request: retry-and-terminate

Server Unreachable Failure-Handling:

Initial-Request  : terminate

Update-Request   : continue

Troubleshoot

Insira o comando show ative-charge credit-control statistics para exibir as estatísticas relacionadas aos mecanismos SU e FH. Veja um exemplo de saída:

#show active-charging credit-control statistics

...

OCS Unreachable Stats:

Tx-Expiry:               2291985       Response-TimeOut:        615

Connection-Failure:      2             Action-Continue:         0

Action-Terminated:       0             Server Retries:          2023700

Assumed-Positive Sessions:

Current:                 2             Cumulative:              2196851

Aqui estão algumas observações importantes sobre este exemplo de saída:

- Tx-Expiry â Â  Indica uma condição SU devido a um Tx-expire.

- Response-Timeout â Â  Indica uma condição de SU devido a um RT.

- Connection-Failure â Â  Indica uma condição SU devido a uma falha de transporte.

- Action-Continue â Â  Este campo indica o número de sessões off-line.

- Action-Terminate â Â  Este campo indica o número de sessões terminadas.

- Server Retries â Â  Este campo indica o número de vezes que o OCS foi repetido.

- Sessões presumidas positivas:

- Current â Â  Este campo indica o número de sessões que estão atualmente na condição SU.

- Cumulativo â Â  Este campo indica o número total de sessões que foram movidas para o status SU.

Insira o comando show ative-charge sessions full all para exibir informações relacionadas ao estado SU da sessão. Veja um exemplo de saída:

#show active-charging sessions full all

..

..

Current Server Unreachable State:                           CCR-I

Interim Volume in Bytes (used / allotted):                 84/ 200

Interim Time in Seconds (used / allotted):                 80/ 3600

Server Retries (attempted / configured):                    1/ 50

Aqui estão algumas observações importantes sobre este exemplo de saída:

- Estado inalcançável do servidor atual â Â  Especifica se o estado atual da SU é devido ao CCR-I ou CCR-U.

- Volume provisório em bytes (usados/alocados) â Â  Mostra o volume provisório em bytes usados versus bytes alocados.

- Tempo provisório em segundos (usado/colocado) â Â  Mostra o volume intermédio em segundos usado versus segundos alocados.

- Tentativas de Tentativas de Servidor (configuradas/tentadas)  Â  Este é o número de tentativas de repetição de servidor versus configurado.

Informações Relacionadas

- Referência de interface de linha de comando, StarOS versão 16

- Suporte técnico e documentação  Â  Cisco Systems