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?
É 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:
- Traduzir as ações do SMS em uma sequencia de comandos SMS e enviar ao CAS
- Coletar todas as respostas enviadas pelo CAS
- Realizar a correspondência entre comandos enviados e respostas recebidas
- Repassar as respostas para o SMS – ACK ou NACK
- Abrir a conexão e mantê-la viva, reconectando quando necessário
- Realizar o tratamento inteligente de erros (NACK)
- Receber os comandos Feedback
- Encaminhar os comandos de Feedback para o SMS processar compras IPPV
- 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:
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!
TV Systems | Broadcasting | Video Ops
2 aEstão sendo bastante úteis sim. Muito obrigado!
Especialista de Infra e Vídeo | Claro Brasil
5 aMundo complexo! Mas tá ótimo.