Diagnóstico de ONUs Offline

Objetivo

Orientar a equipe técnica sobre investigação de clientes offline na OLT, com foco em atendimento, operação NOC, documentação e diagnóstico em campo.

Conceito

Diagnóstico de ONUs Offline é um tema operacional importante dentro de Telecom porque influencia disponibilidade, qualidade do serviço e tempo de resolução de incidentes.
O objetivo não é apenas conhecer o termo, mas saber onde ele aparece na rede, quais sintomas provoca quando está incorreto e quais evidências devem ser coletadas.

Onde se aplica

Este conteúdo se aplica a operação de OLTs, provisionamento de ONUs, manutenção de portas PON, VLANs de serviço, leitura de potência e diagnóstico NOC.
Também deve ser usado em triagens, ativações, manutenções preventivas, correções emergenciais e validações após mudança.

Funcionamento

A OLT controla portas PON, autorização de ONU, perfis, VLANs, alarmes e encaminhamento dos serviços até o uplink.
Na prática, o técnico deve interpretar o cenário completo: equipamento, porta física, configuração lógica, medições, logs e impacto percebido pelo cliente.

Parâmetros importantes

Pontos que devem ser observados:

porta PON;
serial da ONU;
perfil de linha;
perfil de serviço;
VLAN;
potência RX/TX;
uplink;
alarme;
status;
último evento;
potência;
CTO;

Esses parâmetros devem ser comparados com o padrão da operação, histórico do cliente e comportamento esperado do equipamento.

Procedimento prático

Sequência recomendada:

identificar OLT e porta PON;
consultar ONU e alarmes;
validar perfis e VLANs;
conferir uplink e bridge/router;
registrar evidências antes da alteração;

Ao final, valide o serviço do ponto de vista do cliente e registre a ação executada.

Evidências obrigatórias

Sempre que houver atendimento, diagnóstico ou alteração, colete:

print do status da ONU;
potência óptica;
perfil aplicado;
VLAN configurada;
alarme/evento;
porta PON e uplink;

Sem evidências, fica difícil diferenciar falha física, erro de configuração, problema de backbone ou limitação do equipamento.

Falhas comuns

Sintomas e causas frequentes:

ONU autorizada com perfil errado;
VLAN ausente;
porta PON com muitas perdas;
uplink saturado;
alarme ignorado;

Essas falhas podem aparecer isoladas ou combinadas. Por isso, evite concluir o diagnóstico com base em uma única medição.

Hipóteses comuns

ONU sem energia ou com fonte defeituosa;
fibra rompida, conector sujo ou potência fora da faixa operacional;
ONU desautorizada, perfil incorreto ou serial divergente;
VLAN, bridge/router ou serviço aplicado incorretamente;
falha coletiva na PON, splitter, uplink ou OLT.

Testes recomendados

verificar status da ONU na OLT e horário do último evento;
comparar potência óptica atual com histórico;
confirmar serial, perfil, VLAN e porta PON;
testar continuidade física quando houver equipe em campo;
avaliar se outras ONUs da mesma PON têm sintoma semelhante.

Erros comuns

trocar ONU sem medir potência;
alterar perfil antes de registrar estado inicial;
analisar cliente isolado quando a falha é coletiva;
ignorar fonte de alimentação, conector ou drop;
encerrar sem validação de navegação ou autenticação.

Checklist de validação

status e evento da ONU registrados;
potência óptica coletada;
perfil e VLAN conferidos;
impacto coletivo descartado ou confirmado;
cliente validado após correção;
evidências anexadas ao chamado.

Se isso não resolver

Siga para o procedimento relacionado conforme o sintoma encontrado.

Se houver falha coletiva, trate como incidente de rede e escale com porta PON, quantidade de ONUs afetadas e horário de início. Se for falha individual recorrente, correlacione potência, fonte, drop, ONU e histórico de atendimento.

Diagnóstico em campo ou operação

A investigação deve partir do status da ONU e alarmes. Se várias ONUs na mesma PON falham, investigue porta, splitter, backbone e uplink antes do cliente final.
Escalone quando houver risco de impacto coletivo, divergência entre documentação e realidade física, falha recorrente sem causa clara ou necessidade de alteração fora da permissão do técnico.
Erro comum: alterar configuração antes de registrar o estado inicial. Isso dificulta auditoria e pode esconder a causa real.

Boas práticas

Recomendações operacionais:

padronizar perfis;
fazer backup antes de mudanças;
documentar porta e cliente;
monitorar alarmes;
evitar alterações diretas sem janela;

Boas práticas reduzem retrabalho e melhoram a rastreabilidade entre campo, NOC e gestão técnica.

Método RMEvolution de validação

Use a sequência abaixo para transformar sintoma em decisão operacional:

Evidência observada: registre o fato bruto, com print, foto, log ou medição.
Hipótese levantada: descreva a causa provável que será testada.
Teste executado: informe ferramenta, condição do teste e valor esperado.
Resultado obtido: registre o valor medido, resposta do sistema ou comportamento observado.
Hipótese descartada ou confirmada: explique o motivo técnico da decisão.
Conclusão operacional: defina correção, orientação, monitoramento ou escalonamento.
Nível de confiança: use baixo, médio ou alto conforme a qualidade das evidências.

Quando não houver evidência suficiente, não encerre o diagnóstico como confirmado. Registre a pendência e escale com contexto.

Documentos relacionados

Resumo

Diagnóstico de ONUs Offline deve ser tratado de forma prática: verificar parâmetros, coletar evidências, corrigir com critério e documentar o resultado. Esse cuidado acelera o atendimento e evita reincidência.