Connecting the dots: o que redes 5G, Raspberry Pi e telefonia comunitária me ensinaram sobre sistemas elétricos
“You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.” — Steve Jobs, Discurso de Formatura em Stanford, 2005
Entre 2018 e 2020, passei boa parte do meu tempo no LASSE (Laboratório de Sistemas de Suporte a Software) da UFPA fazendo coisas que, na época, pareciam completamente desconectadas do que seria a minha carreira como engenheiro eletricista.
Eu programava em Python para emular redes de celular. Configurava Raspberry Pis para funcionar como estações rádio-base em comunidades rurais sem energia estável. Simulava redes 5G em software usando ferramentas de código aberto. Escrevia papers sobre topologias de rede virtualizadas.
Engenharia de telecomunicações. Sistemas embarcados. Redes definidas por software.
Nada disso está no meu cargo atual. E foi exatamente isso que fez diferença.
Os três trabalhos
Durante o período no LASSE, participei de três publicações:
1. Emulação de Rede LTE Usando OpenAirInterface e Análise de Tráfego Via Protocolo de Rede (SBRT 2019)
DOI: 10.14209/sbrt.2019.1570559016
Neste trabalho, emulamos uma rede LTE completa usando o OpenAirInterface — um framework open-source para redes celulares — e analisamos o tráfego gerado entre os nós da rede. O objetivo era entender o comportamento da rede em diferentes cenários de carga antes de implementar qualquer coisa em hardware real.
2. Virtualized C-RAN with Mininet and OAI Supporting Flexible Network Topologies (SBRT 2020)
DOI: 10.14209/sbrt.2020.1570657866
Aqui evoluímos para virtualizar a arquitetura C-RAN (Cloud Radio Access Network) usando Mininet — um emulador de redes — combinado com OpenAirInterface. A ideia era criar topologias de rede flexíveis sem precisar de hardware dedicado para cada teste. Software simulando hardware, com fidelidade suficiente para validar conceitos.
3. Redução de Consumo de Energia em Sistemas de Telefonia Comunitária Usando Raspberry Pi (Computer on the Beach 2020)
DOI: 10.14210/cotb.v11n1.p077-078
Este foi o mais próximo do mundo real: o projeto CELCOM, que levava conectividade de voz e dados para comunidades rurais isoladas da Amazônia. O problema prático era que essas comunidades não tinham energia estável — então precisávamos reduzir o consumo da estação rádio-base ao mínimo possível. A solução foi substituir o hardware tradicional por um Raspberry Pi 3, analisando o consumo em diferentes cenários de operação.
O que cada trabalho me ensinou (que eu só entendi depois)
Emulação = planejamento antes da execução
Quando você emula uma rede LTE antes de implementá-la, você está fazendo essencialmente o mesmo que faço hoje ao simular o comportamento de uma rede elétrica antes de propor uma obra.
Ninguém constrói uma subestação para ver se vai funcionar. Primeiro, você simula. Você roda o fluxo de carga, testa os cenários de contingência, valida as premissas. Só então você propõe o investimento.
A lógica é idêntica. O domínio é diferente.
Sistemas com restrições de energia ensinam a pensar em eficiência
Quando o seu hardware tem que operar com energia solar intermitente e bateria limitada, você aprende a pensar diferente sobre consumo. Cada milliwatt importa. Cada ciclo de processamento tem custo.
Essa mentalidade — de pensar no sistema inteiro, nos limites físicos, nas consequências de cada decisão de projeto — é exatamente o que diferencia um engenheiro de planejamento que propõe obras que fazem sentido técnico-financeiro de um que propõe obras que fazem sentido só no papel.
Redes definidas por software = separação entre o que é físico e o que é lógico
No C-RAN virtualizado, a ideia central é separar o processamento da transmissão: o hardware de rádio fica no campo, mas toda a inteligência roda em servidores centralizados. Você abstrai o físico.
Essa capacidade de abstração — de entender que o que parece um problema físico pode ter uma solução lógica, e vice-versa — é algo que a maioria dos engenheiros puramente formados em sistemas de potência não desenvolve naturalmente. Porque toda a formação é em circuitos, campos, máquinas. O pensamento sistêmico em camadas de abstração não é natural nesse mundo.
O que a engenharia elétrica não teria me dado sozinha
Pessoas formadas exclusivamente em sistemas de potência tendem a pensar em soluções físicas para problemas físicos. Mais cabos, mais transformadores, mais compensadores.
Não é errado. Mas é incompleto.
A experiência em telecomunicações me deu algumas ferramentas que não estão nos currículos de engenharia elétrica:
- Pensar em camadas: hardware, protocolo, aplicação. Em sistemas elétricos: física, controle, operação.
- Simulação como ferramenta de trabalho cotidiana, não como etapa burocrática do projeto.
- Código como linguagem de análise. Python não é “programação de computadores” — é a ferramenta mais eficiente para analisar grandes volumes de dados de medição, que é o que faço diariamente.
- Tolerância à ambiguidade técnica. Em telecomunicações, você frequentemente trabalha com padrões que ainda estão sendo definidos, ferramentas que ainda estão sendo escritas, topologias que nunca foram implementadas antes. Isso treina uma forma de raciocinar sob incerteza que é valiosa em qualquer área.
Connecting the dots
Quando escolhi pesquisar em telecomunicações durante a graduação, não tinha nenhum plano. Era curiosidade. Era o que estava disponível. Era onde as pessoas mais interessantes estavam trabalhando.
Hoje, quando estou analisando dados de medição de campo de uma rede elétrica com Python, ou quando estou pensando em como modelar um cenário de contingência, ou quando consigo ver rapidamente que a solução para um problema de atendimento não é necessariamente uma obra nova mas sim uma reconfiguração lógica da rede — eu sei de onde vem essa capacidade.
Vem de ter passado anos fazendo coisas que não tinham relação óbvia com onde eu iria chegar.
Jobs estava certo. Os pontos só fazem sentido quando você olha para trás.
Os trabalhos mencionados foram desenvolvidos durante minha participação no LASSE (Laboratório de Sistemas de Suporte a Software) da UFPA, entre 2018 e 2020.