Desbloqueando insights de dados dos CPEs residenciais

Por Hugo Chimello, Marcelo Sobrinho e Humberto Cornia

1- Qual o objetivo do blogpost?

Objetivo é detalhar como uma operadora que possui uma infraestrutura dedicada, com custo elevado e pouco flexível, poderia fazer a coleta de dados dos terminais de seus usuários de forma massiva, e posteriormente agregá-los para análise utilizando seus sistemas de OSS.

Muitas vezes estes dados ficam distribuídos, o que dificulta correlacionar com os demais dados de seus assinantes para gerar possíveis insights. Além disto, esta coleta massiva, muitas vezes é feita com longos intervalos de tempo em função do uso do protocolo Simple Network Management Protocol (SNMP), protocolo suportado pela grande maioria de dispositivos legados em uso na rede.

A ideia, neste blog, é mostrar como a solução da AWS poderia ajudá-los a criar 1/ Uma solução serverless na nuvem, de forma escalável e flexível. 2/ Criar um data-lake para centralizar todos os dados. 3/ Fazer uso de Analytics e Machine Learning tools da AWS. 4/ Fazer a ingestão a partir dos devices, via a solução de IoT Green Grass na solução de IoT da AWS. 5) Automatizar os processos de ações remotas no CPE via funções AWS Lambda visando remediar possíveis falhas.

2 – Qual problema queremos resolver?

Introdução

Em virtude do trabalho remoto, observou-se uma mudança de comportamento dos consumidores, que se tornaram mais exigentes por um serviço de banda larga residencial com melhor qualidade e maior estabilidade. Segundo pesquisa da Ovum, 60% dos clientes estão propensos a mudar seu provedor de serviços de banda larga pelos próximos 12 meses para um serviço de banda larga mais confiável. Adicionalmente, 31% dos clientes que possuem crianças em casa, têm encontrado dificuldade para trabalhar de forma remota como resultado da instabilidade do serviço prestado quando o consumo de dados aumenta. Como mencionado, em vista do crescimento do mercado de trabalho remoto, esta instabilidade tornou-se ainda mais sensível e perceptível pelos clientes.

Logo, as empresas de Telecomunicações precisam transformar a maneira como o dispositivo que opera em seus clientes – Customer Premises Equipment (CPE) – é gerenciado para:

• Gerar insights sobre a experiência dos usuários em tempo real, identificando possíveis problemas antes que sejam impactados;
• Aumentar a eficiência operacional através de algoritmos de Machine Learning para detectar falhas, minimizando assim as interações em seu contact center.

3 – Habilitar novos serviços e modelos de negócios, utilizando-se dos CPEs como uma plataforma de serviços e recursos de valor agregado para a empresa.

Devido a evolução das diferentes tecnologias de acesso, chipsets e gerações de gateways residenciais no mercado, tornou-se caro e lento para as empresas operarem e gerenciarem o ciclo de vida de milhares de dispositivos. Desta forma, as operadoras acabaram sendo obrigadas a manter diferentes plataformas de gerência, uma para cada tipo de protocolo, impedindo que exista um sistema unificado responsável por toda sua base de usuários.

Para simplificar este cenário, temos visto algumas iniciativas na indústria nas últimas décadas. Como por exemplo, o padrão TR-069 para ajudar no gerenciamento, monitoramento e aprovisionamento do ciclo de vida de CPEs para diferentes tipos de finalidades e protocolos de redes de acesso (STB, VoIP, Wi-Fi e outros). Mais recentemente, vimos o surgimento do User Service Platform (USP), um protocolo desenvolvido para gerenciar, monitorar, e controlar dispositivos conectados. O USP habilita a ingestão de dados em tempo real, suporte a vários controladores, aplicativos em contêineres com APIs padronizadas e extensões de modelo de dados. Porém, é importante reconhecer que a maioria dos CPEs, em uso no mercado da América Latina, é composto por equipamentos legados que somente possuem suporte via o protocolo de gerência Simple Network Management Protocol (SNMP). Somente um percentual baixo de dispositivos suportam os protocolos mais modernos como CPE WAN Management Protocol (CWMP) TR-069 ou Message Queuing Telemetry Transport (MQTT) mencionados anteriormente.

Em função deste cenário restrito, muitas operadoras precisam fazer uso de um serviço de proxy server, que é responsável pela tradução entre as requisições feitas via o padrão TR-069 e os dispositivos que suportam apenas o protocolo SNMP. Entretanto, este cenário apresenta alguns desafios, uma vez que o dispositivo SNMP apenas responde de forma passiva as requisições feitas via proxy, sem a capacidade de notificar e gerar dados de forma proativa mediante triggers pré-determinados em suas configurações.

Neste blogpost, apresentaremos uma arquitetura que permitirá as operadoras extraírem insights dos seus CPEs legados, mesmo que sejam baseados em SNMP, de forma massiva utilizando-se de serviços serverless da AWS para: 1/coleta ou ingestão, 2/armazenamento dos dados na nuvem, 3/processamento ou consulta e 4/análise e visualização dos dados.

XYZ Telecom

Neste blog, utilizaremos uma operadora fictícia para exemplificar nosso caso de uso. A XYZ Telecom, opera em centenas de cidades no país, possui cerca de 20 milhões de clientes banda larga residencial, e possui um mix de tecnologias de acesso como fibra óptica (xPON/FTTx), cabo coaxial (Tecnologia HFC) e rede xDSL. A XYZ Telecom vem observando um crescimento no churn de usuários nos últimos meses, muito em função da instabilidade de seu serviço de banda larga, e uma maior insatisfação de seus clientes. Então, como parte de um plano estratégico, a empresa priorizou iniciativas que possam identificar problemas em sua rede, de forma rápida e proativa, e que ajudem a reduzir o custo de sua infraestrutura de monitoramento da base de CPEs (OPEX).

Atualmente, a XYZ Telecom utiliza centenas de servidores de gerência SNMP, em sua arquitetura de rede, que fazem o processo de pooling para coleta de dados de telemetria dos CPEs em intervalos programados de 60 minutos, e que posteriormente são armazenados em bancos de dados relacionais. Estes bancos de dados são integrados a uma aplicação de front-end, usada pelo time de operação para análise e resolução de problemas. Neste fluxo de gerência, somente quando um cliente do serviço de banda larga aciona o suporte, é que o analista acessa o front-end para executar uma query SQL em busca dos dados históricos dos últimos 7 dias no CPE do cliente em questão.

Como atualmente os dados são armazenados em diferentes bancos de dados, e que estão distribuídos por diferentes cidades, isto acarreta uma latência próxima a cerca de 1 minuto para cada consulta, afetando a experiência dos clientes finais. Tendo em vista esta situação e visando minimizar o tempo médio de atendimento por cliente, a XYZ Telecom acaba onerando seus custos ao manter uma equipe de operação maior, recursos financeiros e intelectuais preciosos que poderiam ajudar em outras atividades da empresa.

3 – Qual a solução proposta?

Migrando para Nuvem

Os times da XYZ Telecom e AWS trabalharam em uma arquitetura em nuvem, que visa atender os seguintes requisitos:

• Arquitetura Serverless ou sem-servidor: XYZ Telecom não deseja ter a responsabilidade pelo gerenciamento da infraestrutura, liberando suas equipes de TI e engenharia para outras atividades mais valiosas internamente.
• Time-To-Market: Automatizar os serviços, que devem ser configurados como código para acelerar a implementação de seus serviços em novas cidades, e ao mesmo tempo fazer uso dos mais de 200 serviços disponíveis na AWS para inovar em seus processos.
• Pagamento sob demanda: modelo de pagamento conforme o uso, sem a necessidade de pagamento upfront (Capex);
• Melhorar a experiência do cliente: Reduzir a latência para consulta.
• Análises avançadas: Utilizar ferramentas de BI que permita criar relatórios analíticos em base a diferentes cenários, possibilitando gerar insights automáticos;

Considerando que a XYZ Telecom, recém começou sua jornada para nuvem, e levando-se em conta sua base de equipamentos legados, o projeto foi dividido em duas fases.

Neste blog, falaremos sobre a primeira fase do projeto, onde a XYZ Telecom: 1/ continuará fazendo pooling ou coleta dos dados através dos seus servidores SNMP on-premises; 2/ fará ingestão dos dados para a nuvem da AWS através do protocolo SFTP (Secure File Transport Protocol); 3/ armazenará na AWS os dados para análise e visualização.

Notem que nesta fase, os servidores de banco de dados on-premisses deixarão de ser utilizados reduzindo o Total Cost of Ownership (TCO), as consultas aos dados serão feitas diretamente na AWS em um banco de dados serverless de alta-performance (melhoria da experiencia do cliente), e os serviços de análise de dados serão utilizados para identificar padrões e tendências (insights).

Solução Técnica

Para nosso projeto, vamos seguir as seguintes etapas de um pipeline de dados: 1/coleta ou ingestão, 2/armazenamento dos dados na nuvem, 3/processamento ou consulta e 4/análise e visualização dos dados.

Coleta ou Ingestão

• Como a XYZ Telecom já utiliza o protocolo SFTP para transferência de arquivos entre seus datacenters, optamos por fazer uso do serviço AWS Transfer Family (SFTP). O AWS Transfer Family é um serviço gerenciado pela AWS que executa a transferência de arquivos via SFTP permitindo o envio de arquivos com mecanismo de segurança e agilidade, e possibilita a integração de forma nativa com o serviço de armazenamento Amazon Simple Storage Service (Amazon S3). Amazon S3 é serviço gerenciado de armazenamento de dados como objetos da AWS. Então resumidamente, os arquivos são transferidos via STFP e armazenados em buckets no Amazon S3, que têm a função de repositórios para organização dos arquivos.

Armazenamento dos dados na nuvem

Na camada de armazenamento, usaremos o Amazon S3 como descrito na etapa de coleta ou ingestão. O Amazon S3 é um serviço de armazenamento de objetos que oferece escalabilidade líder do setor, disponibilidade de dados, segurança e performance. Clientes de todos os tamanhos e setores podem usar o Amazon S3 para armazenar e proteger qualquer volume de dados para uma variedade de casos de uso, como data lakes, sites, aplicações móveis, backup e restauração, arquivamento, aplicações corporativas, dispositivos IoT e análises de big data. O Amazon S3 fornece recursos de gerenciamento para que você possa otimizar, organizar e configurar o acesso aos seus dados para atender aos seus requisitos específicos de negócios, organizacionais e de compatibilidade.

Processamento ou Consulta

Para realizar o processamento dos arquivos recebidos e armazenados em buckets do Amazon S3, utilizaremos o serviço AWS Lambda. O AWS Lambda é um serviço de computação que permite executar código sem o provisionamento ou gerenciamento de servidores.

O Lambda executa seu código em uma infraestrutura de computação de alta disponibilidade e executa toda a administração dos recursos computacionais, incluindo manutenção do servidor e do sistema operacional, provisionamento e escalabilidade automática da capacidade e registro em log do código. Com o Lambda, tudo o que você precisa fazer é fornecer seu código em um dos runtimes de linguagens compatíveis com o Lambda. Você organiza seu código em Funções do Lambda. O serviço do Lambda executa a função somente quando necessário e escala automaticamente e você paga apenas pelo tempo de computação consumido.

Este processamento dos arquivos ocorrerá em duas etapas pelo serviço AWS Lambda: 1/ quebra dos arquivos recebidos em arquivos menores e recolocados no próprio Amazon S3, e 2/ inserção destes arquivos em um banco de dados não relacional como o serviço Amazon DynamoDB. O Amazon DynamoDB é um serviço que por meio de chamadas de API, possibilitaria a realização de consultas dos dados de forma simples por meio da aplicação que a XYZ Telecom já possui via linguagem PartiQL do Amazon DynamoDB. PartiQL é uma linguagem de consulta compatível com SQL de código aberto que facilita a consulta de dados com eficiência, independentemente do local ou do formato em que estejam armazenados. Com PartiQL, é possível processar facilmente dados estruturados de bancos de dados relacionais, dados semiestruturados e aninhados em formatos de dados abertos e até mesmo dados sem esquema no NoSQL ou em bancos de dados de documentos que permitam atributos diferentes para linhas diferentes. Para obter mais informações, consulte Linguagem de consultas PartiQL.

A razão para dividir esta etapa em duas fases ocorre devido ao cenário descrito abaixo.

• Os arquivos coletados dos CPEs, muitas vezes possuem um tamanho grande em virtude da quantidade de equipamentos monitorados, então é preciso fazer a quebra do arquivo original em arquivos menores para posterior processamento.
• Uma vez feita a quebra do arquivo original em arquivos menores, utilizamos uma segunda função lambda que será responsável pela inserção da informação no banco de dados não relacional Amazon DynamoDB.

Neste link é possível consultar o código utilizado pelas funções lambda para executar estas tarefas.

Análise e Visualização dos dados

Baseado nos requisitos de negócio, podemos considerar soluções diferentes para análise dos dados: 1/ solução baseada em aplicações que fazem uso de Business Inteligent (BI) para consulta, como por exemplo o Amazon QuickSight. 2/ solução baseada em um serviço de banco de dados não relacional, como por exemplo o Amazon DynamoDB. 3/ Solução baseada na combinação dos métodos propostos anteriormente.

Forma 1:

Serão utilizados os seguintes serviços:

• AWS Transfer Family (SFTP)
• Amazon S3
• Amazon QuickSight

Após a criação e alimentação do data-lake no Amazon S3, a XYZ Telecom utilizará o Amazon QuickSight, que é um serviço de business intelligence promovido por machine learning, para a criação de dashboards interativos com insights e que possibilita realizar querys nos dados coletados de seus clientes. O Amazon Quicksight por exemplo, conseguiria proativamente saber quando um dispositivo não estiver atuando dentro dos parâmetros aceitáveis de funcionamento.

Forma 2:

Serão utilizados os seguintes serviços:

• AWS Transfer Family (SFTP)
• Amazon S3
• AWS Lambda
• Amazon DynamoDB
• Amazon API Gateway

Na segunda forma, a XYZ Telecom pretende acessar os dados coletados por meio de uma solução existente para que seus colaboradores possam tomar medidas proativas em relação ao status apresentados pelos dispositivos. Assim como na Forma 1, o envio de dados para a AWS também ocorrera por meio do AWS Transfer Family, e os arquivos serão inseridos no data-lake criado no serviço Amazon S3. Da mesma forma que é possível acessar os dados no bucket no Amazon S3 utilizando ferramentas de business intelligence para analisar os dados, também é possível inseri-los por meio de uma função Lambda em outros serviços, como um banco de dados não relacional. Neste caso, a XYZ Telecom utilizará o serviço Amazon DynamoDB, um serviço de banco de dados não relacional totalmente gerenciado que fornece uma performance rápida e previsível com escalabilidade integrada.

Para que os dados sejam consumidos por aplicações externas a nuvem AWS, será criado uma API no serviço Amazon API Gateway, que ficará responsável pela autenticação e autorização entre a solução externa e os serviços da AWS. Por meio desta arquitetura suas aplicações atuais podem consumir os dados que foram transferidos para a nuvem. Por exemplo, podem realizar buscas dos dados relativos aos equipamentos de seus clientes durante a chamada de atendimento via integração da aplicação de atendimento e o banco de dados não relacional, Amazon DynamoDB da AWS.

Forma 3:

Existe ainda a opção de utilizar as duas formas mencionadas anteriormente, de maneira concorrente, neste caso, conseguir-se-ia utilizar ferramentas de business intelligence e ao mesmo tempo consumir os dados via banco de dados não relacional Amazon DynamoDB, conforme a imagem abaixo.

A Vantagem desta arquitetura híbrida é que esta arquitetura permite uma clara separação entre os grupos que podem acessar as informações. Informações mais detalhadas poderiam ser obtidas diretamente via o serviço Amazon DynamoDB para equipes de engenharia, enquanto relatórios gerenciais poderiam ser facilmente visualizados via Amazon Quicksight por seus gerentes e diretores.

Conclusão

Com esse blogpost, demonstramos como a AWS consegue ajudar empresas como a XYZ Telecom a coletar, analisar e utilizar os dados disponíveis em seus gateways residenciais (CPEs, sem a necessidade de instalar um agente ou mesmo efetuar um upgrade nos equipamentos, permitindo a centralização desta informação na nuvem AWS.

Sobre os autores

Hugo Chimello é um arquiteto de soluções com mais de 4 anos de experiencia em AWS. Com múltiplas certificações AWS, Hugo utiliza seus 9 anos de experiencia no mercado de tecnologia para atender a maior empresa de telecomunicação da América Latina.

Marcelo Sobrinho é um arquiteto de soluções para o mercado de telecomunicações na AWS. Marcelo possui mais de 23 anos de experiência no mercado de tecnologia, sendo reconhecido como um técnico advisor por seu conhecimento no setor, tendo participado em muitos projetos com entregas de soluções para redes móveis.

Humberto Cornia é um Consultor DevOps com quase 4 anos de experiência na AWS. Com 7 certificações AWS, Humberto utiliza seus 9 anos de experiência no mercado de tecnologia para atender a clientes líderes em diversos setores.