Automatizar el análisis de causa raíz en una red GPON
Cuando una ONU se apaga, la respuesta suele estar en la potencia óptica, el puerto de OLT y los vecinos. Aquí verás cómo la IA lo rastrea en segundos, y cómo evaluar cualquier motor de RCA.
Un abonado se cae a las 21:14. A las 21:15 el cliente está al teléfono. A las 21:17 un agente de Tier-1 ha registrado el síntoma en un ticket. A las 21:23 un ingeniero de NOC está en cinco herramientas a la vez tratando de averiguar si es una avería real, un bloqueo de facturación o un simple parpadeo. A las 21:40 se envía un camión. En el 60 % de los casos, ese camión no hacía falta.
Este es el coste diario del análisis de causa raíz manual. No es culpa de los técnicos. Los datos existen; el flujo de trabajo no. El cambio con mayor apalancamiento que un operador GPON puede hacer en 2026 es automatizar este bucle de extremo a extremo. Aquí verás cómo debería ser ese bucle y cómo evaluar cualquier motor de RCA que afirme hacerlo.
La física de un fallo GPON
En una Red Óptica Pasiva, las señales accionables se concentran en un pequeño conjunto de mediciones. Conocerlas es el cimiento del RCA automatizado, porque la IA tiene que saber a qué mirar.
- Potencia óptica Rx/Tx en la ONT y en el puerto PON del OLT (dBm).
- Estado del puerto OLT (activo/inactivo, último flap, contadores de errores).
- Vecinos del árbol PON: ONT hermanas en la misma cadena de splitter.
- Estado de autenticación y sesión (inform TR-069, RADIUS, DHCP).
- Cambios de configuración recientes (último envío de ACS, actualización de firmware).
- Correlación con historial de campo: ¿ha tenido esta ONT alguna queja en los últimos 30 días?
- Señales meteorológicas cuando estén disponibles: eventos de frío/calor que afectan a fibras de planta externa.
El rastreo hacia atrás de cinco segundos
Un motor de RCA automatizado mira todo eso al mismo tiempo. No ejecuta un script secuencial; recorre un grafo dirigido hacia atrás desde el síntoma. "ONU offline" se convierte en "autenticación ausente". Eso se convierte en "¿hubo LOS?". Eso se convierte en "¿cuál es la potencia Rx y cómo se compara con el último buen conocido?". Eso se convierte en "¿están también caídas las hermanas del splitter?". Cada rama aporta evidencia con un peso.
Cómo razona el RCA Engine de Netxol (típicamente 1,8 s de extremo a extremo)
- Extraer la telemetría más reciente conocida de la ONT, su puerto de OLT, sus hermanas, sus últimas 30 días de quejas y su historial de configuración.
- Recorrer un grafo de hipótesis: pérdida de energía, corte de fibra, flap de puerto OLT, pérdida de splitter, fallo de hardware de ONU, problema de autenticación, bloqueo de facturación.
- Puntuar cada rama contra la evidencia.
- Agregación probabilística. La confianza es un porcentaje real, no una etiqueta como "alta".
- Mapear la hipótesis principal a una remediación: reiniciar, re-autenticar, enviar perfil, despachar.
- Estimar el coste de equivocarse (p. ej. salida de camión innecesaria).
- Si la confianza supera el umbral de política y la acción es reversible, ejecutar y verificar.
- De lo contrario, presentarlo al NOC con toda la evidencia.
Qué debería significar la "confianza"
Un modo de fallo común de las primeras herramientas de RCA era un número de confianza que no significaba nada: un peso ajustado a mano sobre una regla. Un motor de RCA moderno debe darte una probabilidad que sobreviva a los sanity-checks bayesianos: 50 % significa que es genuinamente una moneda al aire dada la evidencia actual; 95 % significa que actuar sin revisión humana es razonable para acciones de bajo coste.
Prueba de calibración
Muestrea 100 salidas de RCA marcadas como "92 % de confianza". De esas, aproximadamente 92 deberían ser correctas al revisarlas. Si solo 70 son correctas, el modelo está sobre-confiado y aún no deberías permitirle auto-actuar.
El papel de la topología
La mitad de las salidas de camión innecesarias que vemos en campo podrían haberse evitado con un solo dato de contexto: "esta es la tercera ONT en el mismo puerto PON que hace flap en 30 minutos". Un solo reporte de ONT parece un problema del cliente; tres hermanas caídas parece un corte de fibra. El patrón solo emerge cuando la topología está en el mismo plano de consulta que la telemetría.
Por eso Netxol construye un grafo de topología en vivo derivado de LLDP/CDP como un objeto de primera clase en la plataforma. Cada alarma lleva su posición en el grafo. Cada hipótesis de RCA puede preguntar "¿quién más está aguas abajo de este dispositivo?" sin salir del motor.
Evaluar un motor de RCA: preguntas para hacer
- 1¿Qué modalidades fusiona? (telemetría / topología / historial / facturación / clima)
- 2¿Está calibrada la "confianza"? Pide la gráfica de calibración.
- 3¿Puede actuar, no solo recomendar? ¿Bajo qué política se permite la acción?
- 4¿Se explica a sí mismo? Deberías poder leer el rastro de evidencia para cualquier conclusión.
- 5¿Cómo maneja los modos de fallo desconocidos? ¿Escala con elegancia en lugar de adivinar?
- 6¿Su plano de datos es multi-proveedor? GPON sin soporte multi-proveedor es una pieza de museo.
Resultados medidos
Cuando este bucle corre de extremo a extremo, los números que observamos en despliegues de operadores son consistentes. El MTTR cae entre un 40 % y un 60 %. Las salidas de camión caen entre un 30 % y un 50 %. Las quejas de clientes asociadas a fallos diagnosticados caen aún más, porque muchos fallos se remedian antes de que el cliente los note.
−47 %
Tiempo medio de reparación
−38 %
Quejas entrantes por fallos
−42 %
Salidas de camión evitables