Interfaces do CAS - Comunicação SMS x CAS
por Bruno Tombi

Interfaces do CAS - Comunicação SMS x CAS

Artigo 003

Agora, já no terceiro artigo, vamos abordar com mais detalhes a comunicação entre o SMS e o CAS, para que possamos responder a seguinte pergunta:

Afinal, como o equipamento instalado na casa do cliente está funcionando? Ou, como, a partir de uma ligação do cliente para a central de atendimento gera uma ação/resposta no equipamento da residência?

Não foi fornecido texto alternativo para esta imagem

É justamente esta comunicação que existe entre o SMS e o CAS que permite traduzir o gerenciamento da empresa ou os pedidos dos clientes em ações que são processadas pelo decoder/smartcard instalado.

Esta conexão acontece em cima de TCP/IP, usando um protocolo definido e proprietário para cada fabricante de CAS (a norma DVB não padroniza os sistemas de CAS!), podendo usar strings textuais ou tecnologias mais recentes como REST API e SOAP. Mas o objetivo principal do protocolo é permitir criar uma sequencia de comandos que traduzem uma ação do SMS, com por exemplo: instalação de um novo cliente, mudança de produto, contratação de um produto a la carte ou PPV...

Existem duas vias de comunicação entre os sistemas:

1.     Comandos SMS: é a comunicação que tem origem no SMS, gerando comandos para serem enviados ao CAS. Pensando na arquitetura servidor-cliente, o CAS tem o papel de gerenciar as conexões com 1 ou mais SMS’s, atuando como servidor e o SMS como cliente. Assim, a responsabilidade de abrir a conexão e mantê-la viva é do cliente, ou, SMS.

2.     Comandos Feedback: é a comunicação no caminho contrário, tem origem no CAS e destino no SMS. Novamente, olhando para a arquitetura, os papéis aqui são invertidos, o SMS tem o papel de gerenciar as conexões com 1 ou mais CAS, sendo o servidor e o cliente é o CAS, que deve abrir e manter a conexão ativa.

Outra característica importante é o sincronismo desta conexão. O protocolo TCP/IP, por natureza, é um método assíncrono, os pacotes não precisam seguir o mesmo caminho e chegar ao destino na mesma ordem que saíram da origem, cabe ao destino remontar os pacotes na ordem correta. Assim, o protocolo do CAS, chamado de SMS Gateway, também é assíncrono.

Mas eu que eu quero dizer com isso? Bom, o SMS Gateway, além dos comandos, também recebe as respostas para cada comando enviado (sucesso ou não, e código de erro – ACK ou NACK). Protocolos assíncronos tem as respostas totalmente desvinculadas da sequencia de comandos enviados. Isto quer dizer que devemos tratar, em nosso gateway, o envio de comandos e as respostas de forma desvinculada, obrigando a necessidade de um terceiro processo que fará a correspondência entre envio e resposta.

Neste ponto, já é possível perceber que a maior parte do trabalho desta comunicação é feita pelo Gateway. Abaixo as principais responsabilidades desta aplicação:

  1. Traduzir as ações do SMS em uma sequencia de comandos SMS e enviar ao CAS
  2. Coletar todas as respostas enviadas pelo CAS
  3. Realizar a correspondência entre comandos enviados e respostas recebidas
  4. Repassar as respostas para o SMS – ACK ou NACK
  5. Abrir a conexão e mantê-la viva, reconectando quando necessário
  6. Realizar o tratamento inteligente de erros (NACK)
  7. Receber os comandos Feedback
  8. Encaminhar os comandos de Feedback para o SMS processar compras IPPV
  9. Respeitar o fluxo de envio de comandos, geralmente definido em quantidade de transações por segundo

O protocolo SMS Gateway implementa sequencia de comandos simples, que agrupados conseguem realizar ações complexas. Vamos citar alguns comandos: Inicializar, adicionar produto, remover produto, configurar CEP, suspender, reativar, configurar versão de software.

Por outro lado, vamos exemplificar algumas possíveis ações do SMS: Instalar equipamento, mudança de plano, falta de pagamento e pagamento realizado.

Daremos o nome de Módulo de Aprovisionamento a junção das regras de negócio do SMS com o Gateway, e neste módulo criamos o que chamamos de Matriz de Comandos, que relacionará cada ação existente no SMS para um comando ou um grupo de comandos, com uma sequência lógica definida, assim, podemos criar uma matriz como abaixo:

Não foi fornecido texto alternativo para esta imagem

Como podemos ver na figura, a entrada de comandos SMS se conecta com uma das saídas do CAS, a EMM – Entitlement Management Message.

O CAS ao receber um comando, inicia a validação gramatical e semântica, depois são realizadas as alterações no banco de dados e por fim são gerados os comandos criptografados que efetivamente são enviados ao smartcard, as EMM’s. Portanto EMM nada mais é que o comando enviado pelo SMS montado e criptografado no formato que o smartcard entende, encaminhado para o multiplexador, que está no headend onde por fim será transmitido para a rede e entregue ao smartcard. A criptografia do comando garante que somente o smart endereçado processará a ação.

A validação gramatical garante que a estrutura do comando está correta, enquanto a semântica garante que os parâmetros passados nos comandos são válidos.

A matriz de comandos deve ser pensada e repensada, pois ela deve garantir que todas as movimentações que acontecem com o cliente via SMS devem ser possíveis de serem desfeitas... para toda ação devemos ter o antídoto. Uma representação em máquina da estados pode ser muito útil para evitar cenários que não possam ser defeitos, impactando diretamente o serviço do cliente.

Conceitualmente é importante lembrar que o CAS controla apenas smartcards! Logo, todo o aprovisionamento é feito usando o número do smartcard (o decoder é um mero coadjuvante). Apesar que garantir que o fluxo de envio de comandos pelo SMS não ultrapasse a capacidade de processamento do CAS é vital para evitar o “travamento” do CAS por sobrecarga.

Agora sim podemos responder à pergunta inicial: quando um cliente liga para a central de atendimento, o atendente disparará uma ação SMS que está mapeada na matriz de comandos, gerando então a sequencia de comandos adequada que será enviada ao CAS pelo Gateway. Já o CAS validará e processará os comandos recebidos, fazendo as alterações em banco de dados necessárias, e, por fim, gerará a EMM (comando criptografado) que será encaminhada ao smartcard através do multiplexador.

Uma pergunta pessoal agora: estes artigos estão sendo úteis? Estão esclarecendo um pouco este ambiente? E, qualquer dúvida, podem questionar nos comentários!

André Tenório

TV Systems | Broadcasting | Video Ops

2 a

Estão sendo bastante úteis sim. Muito obrigado!

Ingrid Bonet

Especialista de Infra e Vídeo | Claro Brasil

5 a

Mundo complexo! Mas tá ótimo.

Entre para ver ou adicionar um comentário

Outros artigos de Bruno Tombi

  • A potente média gerência

    A potente média gerência

    Há muito tempo tenho pensado no papel da média gerência, e, recentemente tenho vistos alguns textos que vão de encontro…

    5 comentários
  • Trabalho remoto e a COVID-19

    Trabalho remoto e a COVID-19

    Hoje fazem 14 dias que estou trabalhando remoto, junto com minha família. Posso garantir que os desafios são enormes…

    2 comentários
  • Para você, o que é gestão?

    Para você, o que é gestão?

    Seria possível definir gestão em uma única palavra? Claro que isto pode depender de uma centena de possibilidades e…

    13 comentários
  • Empreendedorismo no CAS

    Empreendedorismo no CAS

    Artigo 009 Bruno: empreendedorismo no CAS, esta certo isso? Que relação é essa? Aparentemente pode não existir uma…

    2 comentários
  • Interfaces do CAS - Aplicativos

    Interfaces do CAS - Aplicativos

    Artigo 008 Neste 8º artigo, vamos finalizar nossas interfaces com o CAS falando um pouco sobre os aplicativos de…

    1 comentário
  • Interfaces do CAS - Tabelas DVB

    Interfaces do CAS - Tabelas DVB

    Artigo 007 Neste sétimo artigo vamos mudar bem o foco do que vínhamos falando nos artigos anteriores e passar para…

    4 comentários
  • Interfaces do CAS - Comunicação CAS x MUX

    Interfaces do CAS - Comunicação CAS x MUX

    Artigo 006 Se voltarmos aos artigos 001 - O Básico da TV por Assinatura e 002 - Interfaces do CAS/Entradas e Saídas…

    2 comentários
  • Interfaces do CAS - Provedor de EPG

    Interfaces do CAS - Provedor de EPG

    Artigo 005 Neste novo artigo vamos abordar a abrangente interface entre o CAS e o provedor de EPG, passando pela…

    3 comentários
  • Interfaces do CAS - Comunicação CAS x SMS

    Interfaces do CAS - Comunicação CAS x SMS

    Artigo 004 No artigo 003 falamos um pouco sobre a comunicação SMS x CAS, agora vamos inverter as siglas para falar da…

    1 comentário
  • Interfaces do CAS

    Interfaces do CAS

    Entradas e Saídas – Artigo 002 Por enquanto, ainda vamos tratar o CAS como uma caixa preta, e assim, falarmos um pouco…

    5 comentários

Outras pessoas também visualizaram

Conferir tópicos