Diagnóstico y Prevención de Fallos en Redes de
Telecomunicaciones Basado en Arquitectura de Microagentes
Luis López1, Francisco Javier López2, José Morcillo2 y Antonio Fernández1
1Laboratorio de Algoritmia Distribuida y Redes.
Grupo de Sistemas y Comunicaciones.
Universidad Rey Juan Carlos [email protected], [email protected]
2Network System Engineering Group Motorola
[email protected], [email protected] Resumen
La evolución de las Tecnologías de la Información y las Comunicaciones ha producido que las redes de telecomunicación sean cada día sistemas más complejos y difíciles de gestionar. En estas condiciones, es importante disponer de mecanismos avanzados de detección y diagnóstico de fallos que garanticen la máxima disponibilidad. Este requisito se vuelve imprescindible cuando se trata de redes de carácter crítico como las asociadas a los servicios de telefonía básica y móvil, en los que la continuidad del servicio es esencial.
Siguiendo esta línea, en este artículo proponemos una arquitectura para la realización de sistemas de localización y diagnóstico de fallos en redes de móviles basada en micro-agentes cooperativos. Finalmente, describimos una implementación de dicha arquitectura para una gran red GSM y presentamos los resultados obtenidos.
1. Introducción
En los últimos años, el tamaño y la complejidad de las redes de telecomunicaciones se ha incrementado de forma dramática. Por este motivo, se está realizando un importante esfuerzo en la concepción de nuevos mecanismos de gestión de redes que posibiliten alcanzar los niveles de eficiencia, fiabilidad y disponibilidad requeridos por la sociedad [4]. Aunque, en última instancia, los fallos son inevitables, su detección y corrección rápida contribuye a que las redes sean más robustas y a incrementar el nivel de confianza que se deposita sobre los servicios que estas ofrecen.
Cuando se trata con grandes redes de telecomunicaciones, lo tradicional es que la gestión de fallos sea realizada por un operador que dispone de consolas en las que puede visualizar el estado de los diferentes elementos de la red. De este modo, el diagnóstico de fallos se basa fundamentalmente en la intervención humana: un ingeniero experto utiliza sus conocimientos del sistema y su experiencia para localizar el fallo a partir de un conjunto de síntomas determinados. Sin embargo, en los últimos años, este tipo de solución está presentando numerosas carencias. La primera es la baja escalabilidad que hace que los costes de soporte se incrementen de manera proporcional al tamaño de la red. La segunda es que, la propia evolución del estado del arte hace necesaria la introducción constante de nuevos servicios. Esto, unido a la convergencia de
las diferentes tecnologías, hace que la complejidad de las redes sea tal que se ha vuelto imposible que un solo operador pueda conocer y comprender las interacciones entre los diferentes componentes del sistema, por lo que el diagnóstico y la solución se retrasan. Finalmente, esta aproximación dificulta la automatización de los procesos asociados a la detección, evaluación y corrección de errores.
Por este motivo, están surgiendo numerosas iniciativas [1-3] dirigidas a la automatización de las labores de localización y diagnóstico de fallos. En esta dirección, se han propuesto diferentes soluciones que van desde modelos teóricos de interacción basados en métodos probabilistas [9]
hasta la aplicación de sistemas expertos basados en conocimiento [7], sistemas multiagente [5-6], u otros tipos de soluciones basadas en técnicas derivadas de la inteligencia artificial [8].
En este artículo, proponemos una de estas iniciativas basándonos en la tecnología de microagentes. De este modo, tratamos de conservar toda la capacidad de diagnóstico de las técnicas más avanzadas y, al mismo tiempo, lograr que la introducción de conocimiento en el sistema sea rápida y sencilla.
2. Descripción del problema
El proceso que se suele utilizar en la actualidad para el diagnóstico de fallos en grandes redes de telecomunicaciones es el que se representa en la Fig. 1.
Tal y cómo se observa en la citada figura, dicho proceso puede sintetizarse en la secuencia siguiente:
1- Los dispositivos de red implementan un conjunto de chequeos de razonabilidad que permiten detectar transiciones hacia estados de error. La presencia de dichos estados se notifica al elemento de red correspondiente.
2- El elemento de red consolida la detección del error. Para ello, toma las acciones oportunas para su solución, si ésta puede alcanzarse, el error no se notifica; en caso contrario, se eleva una alarma dirigida hacia un centro de soporte.
3- En el centro de soporte, un servidor de gestión recibe las alarmas elevadas por los elementos de red, las consolida y las prioriza. Las alarmas más críticas que no pueden ser tratadas de manera automática son reportadas a un operador (humano) a través de una consola de control.
4- El operador (humano) recibe la alarma a través de la consola y la interpreta. Para ayudarle en esta labor, el operador dispone de un sistema de gestión de conocimiento (esencialmente una base de datos) en el que puede tratar de localizar problemas similares y recuperar las acciones correctivas que se tomaron para solucionarlos en el pasado. En caso de que el problema sea conocido, el operador puede llevar a cabo las labores de
Network element
Network Device Network Device
ND Mng
NE Mng
Core SW
2.- Consolidación
1.- Deteción de transiciones Network
element
Network element
Servidor de gestión (OMCR)
ENLACE ANÁLISIS
Alamacenamiento CONSOLA
3.- Consolidación y priorización
OPERADOR
4.- Acción de mantenimiento a criterio del operador
Acción
Base de datos de problemas
DESARROLLO Nuevo Registro
9.- Búsqueda de un nuevo problema en base a los sintomas detectados
CONOCIDO COMPARA
Búsqueda Visualización
SI
ANÁLISIS
Figura 1
mantenimiento oportunas para solucionarlo.
No obstante, en caso de que el problema sea desconocido, el operador no suele conocer un procedimiento de recuperación válido, por lo que eleva un informe de error a un segundo nivel de soporte, que está más en contacto con el desarrollo del sistema 5- En el segundo nivel de soporte se analiza el
problema, pudiendo llegar hasta su reproducción en una red de pruebas. Una vez que se ha comprendido la naturaleza del problema, se concibe un procedimiento de recuperación. El citado procedimiento se incluye en la base de conocimientos junto con la descripción del problema, para que quede disponible en caso de que el error vuelva a reproducirse.
Este proceso en cinco pasos se ha mostrado eficiente a la hora de detectar, diagnosticar y corregir fallos simples, es decir, fallos que están siempre asociados definidos y con un patrón simple. Un ejemplo de este tipo de fallos son los producidos por disfunciones hardware en los equipos o líneas de comunicación, que suelen estar perfectamente documentados en los sistemas de gestión de conocimiento y para los que existen procedimientos de recuperación precisos. Sin embargo, la gestión de fallos complejos no siempre se resuelve de manera tan satisfactoria. Los fallos complejos son aquellos asociados a patrones complejos que involucran a varios elementos en interacción. En muchas ocasiones no están asociados a un patrón de alarmas.
En los casos más patológicos, no se reporta alarma
alguna y el error sólo puede percibirse a través de disfunciones en los sistemas de red que suelen redundar en la pérdida de prestaciones. Este tipo de fallos suelen estar asociados a errores en el software y son cada día más frecuentes.
Para la gestión de los fallos complejos, existe una necesidad creciente de satisfacer los siguientes requerimientos:
• Automatizar la detección. Es decir, deben existir procedimientos automáticos que permitan asegurar o descartar la presencia de un tipo de fallo particular de manera automática y sin intervención humana.
• Describir los fallos una sola vez y detectar las ocurrencias subsiguientes de manera precisa. La primera vez que aparece un fallo, se invierte un esfuerzo notable para lograr comprenderlo y definir un procedimiento de recuperación.
Consiguientemente, uno de los objetivos que planteamos es el de lograr que, una vez que el citado procedimiento se ha definido para un patrón de fallo determinado, este pueda ser reutilizado en las siguientes apariciones del mismo. Por este motivo, existe una importante necesidad de establecer mecanismos que permitan caracterizar la presencia de un tipo de fallo particular de manera precisa.
• Minimizar el tiempo de respuesta ante incidencias. Es evidente que lo que los proveedores de red desean es minimizar el tiempo de respuesta ante incidencias, de forma que se garantice la satisfacción de los clientes. En este sentido, la detección automática y la descripción y detección precisa y rápida de los patrones de fallo son los ingredientes esenciales.
• Permitir la integración del conocimiento de diferentes expertos y de diferentes fuentes.
En la actualidad, los sistemas de red se han vuelto tan complejos que es imposible que un solo experto en una sola localización geográfica pueda acumular todo el conocimiento necesario para la detección y el diagnóstico preciso de fallos. Por este motivo podemos afirmar que existe una necesidad creciente de herramientas que permitan integrar el conocimiento de diferentes expertos de manera uniforme.
Para lograrlo, en este artículo planteamos el desarrollo de una herramienta software de soporte que satisfaga los siguientes requisitos:
• La introducción del conocimiento debe ser sencilla y rápida. En este caso, ese conocimiento consiste en la descripción de los patrones de comportamiento que pueden considerarse síntomas de la presencia de un fallo determinado, así
como los procedimientos precisos a través de los que la presencia del fallo puede asegurarse o descartarse, una vez que los síntomas han aparecido
• La inserción de un patrón de fallo o modelo no debe requerir conocer el resto. En este sentido, lo que se pretende es que los diferentes patrones de descripción sean independientes entre sí. Es decir, cada uno de los procedimientos de detección de síntomas o de aserción de presencia de fallos debe funcionar “como si” fuese el único. De este modo, no es necesario considerar interacciones entre los diferentes patrones. Para desarrollar un patrón dado, no es necesario conocer ningún otro ni tener en cuenta cuáles serán chequeados concurrentemente con el mismo.
• Un patrón de fallo debe poder aprovechar el resultado de otro. Aunque queremos que los diferentes patrones sean independientes, en determinadas ocasiones es interesante que las conclusiones obtenidas a través de una unidad de conocimiento puedan ser utilizadas por otra. Por este motivo, es necesario contar con un mecanismo que permita que dos patrones cooperen, pero sin violar su independencia. Más adelante se establecerán los mecanismos a través de los cuales es posible realizarlo.
• La herramienta debe funcionar de modo centralizado y eficiente. La herramienta software que deseamos desarrollar debe ser centralizada y residir en el centro de soporte (OMCR), ejecutándose en uno de los ordenadores presentes en el mismo. Su realización distribuida supondría introducir los patrones de error sobre los propios elementos de red. Aunque evidentemente esto dotaría de una mayor potencia a la herramienta, supondría alterar el software de los dispositivos de red, lo cual sería extremadamente invasivo y costoso tanto en términos de esfuerzo como de tiempo.
Dado que la aplicación debe ejecutar de manera centralizada, el volumen de datos y de patrones de fallo que hay que chequear es muy elevado. Por ese motivo, uno de los requisitos que imponemos es el del funcionamiento eficiente. Es decir, la herramienta debe escalar de manera apropiada de modo que se puedan verificar los patrones de fallo correspondientes a una gran red de móviles compuesta de centenares e incluso miles de celdas. Esto significa que cientos de miles de patrones diferentes deben chequearse de manera aislada y simultánea.
3. Una arquitectura basada en microagentes
La arquitectura que proponemos está inspirada en los modelos multiagente tradicionales pero con una clara orientación hacia la atomización de las tareas de diagnóstico. En este sentido, la unidad fundamental de la misma es el microagente.
Conceptualmente, un microagente cuenta con todas las propiedades que normalmente son asignadas a los agentes (autonomía, capacidad de interacción con el entorno, capacidad de comunicación con otros agentes, etc.). Sin embargo, desde el punto de vista de la implementación, el microagente ha sido diseñado para consumir el mínimo posible de recursos del sistema (todos los microagentes comparten un mismo thread de ejecución y su modelo de comportamiento es común y se basa en una máquina de estados programable).
Los microagentes cooperan entre sí, de manera directa, a través del intercambio de mensajes o, de manera indirecta, a través del entorno (activando o modificando variables en las estructuras de datos que representan la red). A este tipo de comunicación basada en señales sobre el entorno se le conoce como estigmergia y es la base sobre la que se asientan numerosos sistemas complejos tales como los insectos sociales o el sistema inmunológico de los seres vivos. Todo microagente tiene capacidad para leer cualquier atributo del entorno y para activar cualquier comando de recuperación de información de la red.
El entorno es representado a través de un conjunto de estructuras jerárquicas susceptible de almacenar el estado de la red en un instante dado. Al conjunto de estas estructuras se le denomina el skeleton de la aplicación. En cada nivel jerárquico se representa un elemento lógico del sistema. Cada uno de estos elementos lógicos es susceptible de contener uno o varios atributos, que pueden ser utilizados para describir su estado.
Los comandos, recuperan la información sobre el estado del sistema y la almacenan en una estructura jerárquica, denominada bone, que comparte su espacio de nombres con el skeleton. Los bones generados por los comandos se insertan posteriormente en el skeleton modificando o activando el valor de los atributos afectados.
Cuando la aplicación arranca, el skeleton está vacío.
A medida que se van insertando bones, se van generando las estructuras de datos apropiadas para contenerlos. De este modo, podemos decir que la aplicación va “descubriendo” los elementos de red a medida que va recibiendo la información desde los comandos.
Este tipo de aproximación dinámica resulta muy útil dado que contener una estructura estática con todos los posibles atributos del sistema sería muy costoso en términos de recursos de computación y restaría flexibilidad al sistema. Sin embargo, con la solución elegida, sólo se representan los recursos de la red que están involucrados de manera directa o indirecta con una condición de fallo o sospechosa de contenerlo.
D a ta A g e n t K n o w le d g e
A g e n t K E (B r a in )
T T Y S Q L F S
C O L L E C T IO N A P P L IC A T IO N S S I (M u s c le s )
B S C C o n s o le C o n fig u ra tio n
S ta tis tic s D B
E v e n ts M M I
S Y S T E M IN T E R F A C E S W o rk a ro u n d
A g e n t
D a ta A g e n t
D a ta A g e n t K n o w le d g e
A g e n t K n o w le d g e
A g e n t
S p in a l C o rd R e p o r t L a y e r
DATA T RANSFER
C u s to m e r P re m is s e s C e n tra l M o to ro la
S y s te m A c c e s s
Figura 2
Estas condiciones “sospechosas” se detectan a través de un conjunto de microagentes denominados nativos, que toman ese nombre porque existen (están instanciados) desde el nacimiento de la aplicación.
Los microagentes nativos pueden subscribirse al conjunto de atributos del skeleton de su interés, de modo que, cuando el valor de cualquiera de estos atributos cambia, se envía un mensaje al microagente informando de dicha modificación. A través de esos atributos, los microagentes nativos chequean el estado de la red buscando condiciones sospechosas que puedan estar asociadas a fallos.
Cuando una de estas condiciones se localiza, el microagente nativo instancia un microagente especialista en el tipo de fallos del que se sospecha, que puede indagar con más precisión en el problema. Este microagente especialista tiene un ciclo de vida limitado y es destruido una vez que ha realizado su trabajo, bien descartando el fallo, o bien localizándolo y tomando las acciones oportunas.
Dado que la aplicación funciona con un solo hilo de ejecución, ha sido necesario establecer un conjunto de colas que gestionen los diferentes mensajes que se envían entre los microagentes, el skeleton y el propio sistema. De este modo, existen tres gestores de mensajes que se implementan como una cola FIFO: el gestor de comandos, el gestor de bones y el gestor de eventos de esqueleto. La aplicación comienza siempre procesando los eventos disponibles (avisos a agentes de que un determinado atributo ha cambiado), después procede con los bones (insertándolos en el skeleton) y finalmente con los comandos. Evidentemente, la ejecución de cada nuevo comando podrá producir la inserción de nuevos bones, que se traducirán en nuevos eventos que procesar.
Para que la aplicación pueda comenzar a analizar el estado de la red, la cola de comandos es inicializada con un conjunto de instrucciones que permiten descargar ciertas informaciones básicas sobre el estado de la red. Esta información es utilizada por los microagentes nativos, quienes la analizarán e instanciarán a agentes especialistas siempre que sea necesario. Una vez que todas las condiciones han sido analizadas, la aplicación destruye el skeleton y todos los microagentes y se duerme durante un periodo de tiempo hasta que vuelve a comenzar la siguiente verificación.
4. Distribución de la herramienta prototipo Los microagentes, tal y como se ha descrito anteriormente y puede apreciarse en la Fig 2, son las piezas fundamentales de una supraestructura que es lo que podríamos llamar la aplicación en sí misma y que es la que se comunica con el sistema, en este caso una red compleja de Telecomunicaciones GSM.
Puede observarse que las funciones están distribuidas, según el tipo de tarea a desarrollar. Para nombrarlas se utilizó el símil del cuerpo humano de ahí por ejemplo el nombre de skeleton. Dichas funciones son:
- KE (Knowledge Engine) o cerebro (Brain).
Los agentes de esta sección se encargan de tomar las decisiones importantes desde el punto de vista de mantenimiento y soporte de la red, como la decisión de cuándo un problema está ocurriendo, qué datos son necesarios para la toma de la decisión, cuándo hay que aplicar un workaround, etc.
- SI (System Interface) o músculos (Muscles). Esta es la parte que interactúa con el sistema, la red de Telecomunicaciones en este caso. Se encarga de recoger los eventos, alarmas, estadísticas; así como introducir comandos.
Dicho de otra manera es quien extrae la información necesaria para que el KE tome decisiones y quien aplica las conclusiones a las que ha conducido el KE.
- Spinal Cord o espina dorsal, podríamos decir por analogía con el cuerpo humano que es el interfaz de comunicación entre las distintas partes de la aplicación. Provee de una comunicación e interfaz seguros y fiables lo que permite que, llegado el caso, las distintas partes de esta aplicación pudieran residir en máquinas o emplazamientos distintos.
Respecto a la figura representada sólo queda por comentar el entorno con el que la herramienta va a interactuar y que evidentemente dependerá del tipo de red al que se vaya a conectar, es decir si se trata de una red de Telecomunicaciones móviles, fija, IP, etc. En este caso se ha dividido en las aplicaciones de recolección de datos y en los interfaces del sistema, que en la mayoría de las ocasiones dependerán del fabricante del equipo.
Existe una tercera capa muy importante pero que en este caso es de salida de la aplicación y es la denominada capa de reportes en la que aparecerá toda la información relativa a los problemas o sucesos encontrados en la red como por ejemplo:
datos de la ocurrencia, información relevante para el estudio de las causas, workarounds aplicados, etc.
5.
ConclusionesEn el presente artículo se ha pretendido poner de manifiesto la problemática que afronta cualquier operador de telecomunicaciones al intentar operar la red debido al ingente número de eventos que recibe por minuto de todos los elementos de red, desde simples tarjetas o programas software, centrales de
conmutación, servidores de aplicaciones, pasarelas y un largísimo etcétera.
Se ha buscado un sistema mediante el cual la respuesta a situaciones críticas de mantenimiento sea mínima y totalmente automática, donde el factor humano esté lo menos presente posible para así aumentar la fiabilidad de las decisiones y maximizar el ahorro e inversiones.
De las posibles alternativas que se han estudiado se ha optado por la de microagentes para conservar toda la capacidad de diagnóstico y lograr que la introducción de conocimiento en el sistema sea rápida, sencilla y económica.
La aplicación desarrollada, a la que se ha llamado NHP (Network Health Programme), es un prototipo que está funcionando con éxito en una gran red GSM europea y está a punto de ser probada en otras dos a petición de los propios operadores.
Debido a la forma en que ha sido diseñada, además de ser totalmente independiente del proveedor de equipos de red donde va a funcionar, su escalabilidad y sencillez para aplicar nuevas reglas a su base de conocimientos permitirían una rápida migración a todo tipo de redes, no solo de telecomunicaciones, como redes de transporte de energía, control de tráfico rodado o ferroviario, unidades de cuidados intensivos en hospitales, etc.
Referencias
[1] M. Chen, A.X. Zheng, J. Lloyd, M.I. Jordan, and E. Brewer. Failure Diagnosis Using Decisión Trees.
Int. Conference on Autonomic Computing, New York, 2004.
[2] M. Steinder, and A.S. Sethi. End-to-End Service Failure Diagnosis Using Belief Networks. Networ Operations and Management Symposium (NOMS), Florence, Italy, 2002.
OMCR
BSS
GSL
BSC BTS
BTS
PCU RSL
BSS
GSL
BSC BTS
BTS
PCU RSL
BSS
GSL
BSC BTS
BTS
PCU RSL
NMC (X.25)
OML
OML
PDN (IP) Consola de operador
Consola de operador
Config Estadísticas
Figura 3
[3] A. Bouloutas. Modeling Fault Management in Communication Networks. PhD thesis, Graduate School of Arts and Sciences, Columbia University, 1990.
[4] I. Katzela, and M. Schwartz. Schemes for Fault Identification in Communication Networks.
IEEE/ACM Transactions on Networking, vol. 3, no.
6, pp. 753-764, Dec 1995.
[5] C.A. Iglesias, M. Garijo, and J. C. González. A Survey of Agent-Oriented Methodologies In Intelligent Agents V: Agent Theories, Architectures, and Languages, Rao, A., Singh, M. y Wooldridge, M. (eds), pp. 317-331. Springer-Verlag, München, Germany, 1.999.
[6] The MultiAgent Systems Tool information page:
http://www.gsi.dit.upm.es/~mast/.
[7] K-W. E. Lor. A Customized Network Diagnostic Expert System Based on General Diagnostic Strategies. Journal of Netwok and System Management: Vol. 1, No. 2, 1993.
[8] P. Fröhlich, W. Nejdl, . Jobmann, and H.
Wietgrefe. Model-Based Alarm Correlation in Cellular Phone Networks. Proceedings of the MASCOTS '97 - 5th International Workshop on Modeling, Analysis, and Simulation of Computer and Telecommunications Systems, 1997.
[9] I. Katzela, and M. Schartz. Schemes for Fault Identification in Communication Networks.
IEEE/ACM Transactions on Networking 3(6): 753- 764, 1995.
