ES2329570T3 - Metodo relativo a la arquitectura de un sistema y programa informatico para la gestion de redes de telecomunicaciones. - Google Patents
Metodo relativo a la arquitectura de un sistema y programa informatico para la gestion de redes de telecomunicaciones. Download PDFInfo
- Publication number
- ES2329570T3 ES2329570T3 ES03818101T ES03818101T ES2329570T3 ES 2329570 T3 ES2329570 T3 ES 2329570T3 ES 03818101 T ES03818101 T ES 03818101T ES 03818101 T ES03818101 T ES 03818101T ES 2329570 T3 ES2329570 T3 ES 2329570T3
- Authority
- ES
- Spain
- Prior art keywords
- network
- management
- architecture
- proxy
- base layer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims abstract description 109
- PWPJGUXAGUPAHP-UHFFFAOYSA-N lufenuron Chemical compound C1=C(Cl)C(OC(F)(F)C(C(F)(F)F)F)=CC(Cl)=C1NC(=O)NC(=O)C1=C(F)C=CC=C1F PWPJGUXAGUPAHP-UHFFFAOYSA-N 0.000 title 1
- 230000008569 process Effects 0.000 claims abstract description 83
- 230000006870 function Effects 0.000 claims abstract description 17
- 230000009471 action Effects 0.000 claims abstract description 16
- 238000004891 communication Methods 0.000 claims abstract description 6
- 230000000737 periodic effect Effects 0.000 claims abstract description 4
- 238000005516 engineering process Methods 0.000 claims description 10
- 238000012795 verification Methods 0.000 claims description 5
- 238000004590 computer program Methods 0.000 claims description 3
- 239000010410 layer Substances 0.000 description 58
- 239000003795 chemical substances by application Substances 0.000 description 55
- 238000007726 management method Methods 0.000 description 44
- 101150012579 ADSL gene Proteins 0.000 description 15
- 102100020775 Adenylosuccinate lyase Human genes 0.000 description 15
- 108700040193 Adenylosuccinate lyases Proteins 0.000 description 15
- 238000013499 data model Methods 0.000 description 14
- 238000010586 diagram Methods 0.000 description 9
- 230000000694 effects Effects 0.000 description 9
- 230000004048 modification Effects 0.000 description 6
- 238000012986 modification Methods 0.000 description 6
- 238000007792 addition Methods 0.000 description 5
- 238000013459 approach Methods 0.000 description 5
- 230000008859 change Effects 0.000 description 5
- 230000001419 dependent effect Effects 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 238000013461 design Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 230000018109 developmental process Effects 0.000 description 3
- 238000012544 monitoring process Methods 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 102100035373 Cyclin-D-binding Myb-like transcription factor 1 Human genes 0.000 description 2
- 101000804518 Homo sapiens Cyclin-D-binding Myb-like transcription factor 1 Proteins 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000012384 transportation and delivery Methods 0.000 description 2
- 101000878581 Aplysia californica Feeding circuit activating peptides Proteins 0.000 description 1
- 238000001994 activation Methods 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- VYLDEYYOISNGST-UHFFFAOYSA-N bissulfosuccinimidyl suberate Chemical compound O=C1C(S(=O)(=O)O)CC(=O)N1OC(=O)CCCCCCC(=O)ON1C(=O)C(S(O)(=O)=O)CC1=O VYLDEYYOISNGST-UHFFFAOYSA-N 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 239000012141 concentrate Substances 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 239000010977 jade Substances 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000007935 neutral effect Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 230000001737 promoting effect Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000010845 search algorithm Methods 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 239000002356 single layer Substances 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0062—Provisions for network management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/04—Network management architectures or arrangements
- H04L41/042—Network management architectures or arrangements comprising distributed management centres cooperatively managing the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/04—Network management architectures or arrangements
- H04L41/044—Network management architectures or arrangements comprising hierarchical management structures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/04—Network management architectures or arrangements
- H04L41/046—Network management architectures or arrangements comprising network management agents or mobile agents therefor
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Arquitectura de un sistema para gestionar una red de comunicaciones (N) que incluye unos equipos de red, teniendo dichos equipos asociadas unas interfaces de control (if_N, if_Nw, if_Ny, if_Nt), comprendiendo la arquitectura: - Una capa de base (PA, RP) para hacer de intermediario o proxy de dichas interfaces (if_N, if_Nw, if_Ny, if_Nt) y para desacoplar dichas interfaces (if_N, if_Nw, if_Ny, if_Nt) de las funciones de gestión, comprendiendo dicha capa de base ejecutores de procesos distribuidos (PE) para ejecutar de una manera distribuida los procesos concernientes a la gestión de dicha red, comprendiendo cada ejecutor de procesos por lo menos uno de un motor de flujos de trabajo, un motor de reglas y una combinación de los mismos, y - Una capa de soporte (AA) superpuesta a dicha capa de base y que comprende una pluralidad de agentes que coordinan el funcionamiento de dicha capa de base (PA, RP) para soportar funcionalidades de gestión distribuidas. Donde dicha capa de base incluye una subcapa de módulos proxy o servidores de recursos (RP), proporcionando cada módulo proxy (RP) una representación de la configuración de por lo menos un equipo de red según un modelo de información definido y siendo configurados para alinear dicha representación al por lo menos un equipo de red: - Llevando a cabo acciones de gestión en dicha red (N); - Recibiendo en dichos módulos proxy o servidores de recursos (RP) las notificaciones enviadas por el por lo menos un equipo de red; y - Llevando a cabo verificaciones periódicas de la alineación entre la representación del equipo de red y el equipo de red.
Description
Método relativo a la arquitectura de un sistema
y programa informático para la gestión de redes de
telecomunicaciones.
La invención se refiere a unas arquitecturas
para la gestión de redes de telecomunicaciones y a unos servicios y
a unas herramientas para su uso en esas arquitecturas.
En las configuraciones convencionales, la
gestión de las redes de telecomunicaciones se lleva a cabo mediante
diferentes sistemas/funcionalidades actualmente denominadas FCAPS
(acrónimo de Fallo, Configuración, Contabilidad, Rendimiento,
Seguridad). Éstos son generalmente componentes separados que
muestran tanto una pobre flexibilidad y baja escalabilidad. Dicho
de otra manera, en las configuraciones convencionales, cualquier
adición/modificación en la red gestionada conlleva que se lleven a
cabo las correspondientes adiciones/modificaciones en cada uno de
los
FCAPS.
FCAPS.
De esta manera se han propuesto plataformas de
gestión de redes distribuidas en los últimos tiempos que básicamente
implementan arquitecturas jerárquicas de múltiples niveles de
componentes (a menudo denominados agentes) y arquitecturas
monocapa.
Por ejemplo, el documento
US-A-6 243 396 propone una
arquitectura multicapa de autoridades que incluye agentes. Estos
agentes están especializados para las diversas funcionalidades FCAPS
así como para representar los recursos de la red (proxy). Este
enfoque resulta bastante flexible pero falla en cuanto a ser
verdaderamente satisfactorio en lo que respecta a la necesidad de
identificar con precisión funcionalidades en las diferentes capas y
a evitar las estructuras excesivamente estratificadas que es
probable que causen una complejidad en el control y la adaptación.
En resumen, el documento US-A-6 243
396 sí describe unos agentes jerárquicos y distribuidos
intercambiando objetivos. Sin embargo, las capas no se especifican
en sus funciones.
Otro enfoque, que implica una arquitectura
"plana", se describe en el documento US2002/0032769 A1 y en el
documento EP-A-1 150 454
correspondiente. En éstos, se describe un sistema de gestión de
redes que proporciona unos servicios de procesamiento de tareas y
datos distribuidos empleando agentes autónomos distribuidos.
Concretamente, la configuración descrita en estos dos documentos
paralelos prevé determinados componentes (nuevamente agentes
autónomos) que tienen una representación distribuida de la red
(función proxy) y unas funcionalidades FCAPS distribuidas de
soporte. Este tipo de arquitectura mejora la escalabilidad pero no
alcanza un grado de flexibilidad verdaderamente satisfactorio. La
función proxy y la función de gestión están intrínsecamente
entrelazadas la una con la otra y algunas funcionalidades resultan
ser difíciles de implementar eficientemente de una manera
distribuida.
distribuida.
De forma más general, determinadas plataformas
de gestión de redes de la técnica anterior implementan flexibilidad
en forma de capacidades de configuración más o menos sofisticadas
y/u ofreciendo ambientes de desarrollo que ayudan a los diseñadores
o integradores de sistemas a construir el esqueleto de nuevos
módulos para soportar nuevos servicios o nuevas tecnologías.
Se sabe que este grado común de flexibilidad no
resulta satisfactorio; de esta manera se han propuesto
configuraciones (véase por ejemplo el programa TMF denominado NGOSS
descrito por ejemplo en "NGOSS Technology Neutral
Architecture", documento TeleManagementForum TMF053 publicación
3.0, abril de 2003) en las que se recomienda la extracción de la
lógica del proceso de negocio de los componentes para tener un motor
de proceso externo que pueda orquestar el flujo de las acciones
alcanzando una mayor flexibilidad.
También se han propuesto los motores de proceso
para su uso como coordinadores del flujo de trabajo en los
componentes distribuidos ofreciendo cada uno funcionalidades
específicas: véase por ejemplo el documento
WO-A-01/02973 en el que se demuestra
la posibilidad de utilizar un motor de flujo de trabajo centralizado
para coordinar los agentes distribuidos.
Este enfoque mejora la flexibilidad sólo hasta
cierto punto: un gestor de procesos centralizado puede convertirse
en un cuello de botella mientras que gran parte de la lógica de
proceso permanece embebida en los componentes individuales. Esto
hace imposible concentrar en un motor de proceso los aspectos
funcionales de todos los compo-
nentes.
nentes.
De esta manera es objeto de la presente
invención deshacerse de las desventajas intrínsecas a las
configuraciones de la técnica anterior consideradas en lo
anteriormente indicado.
\newpage
Según la invención, ese objetivo se alcanza por
medio de una arquitectura de sistema que presenta las
características presentadas en las reivindicaciones que siguen. La
invención también se refiere a un método correspondiente así como a
unos programas informáticos que se pueden cargar en la memoria de
por lo menos un ordenador y que comprenden partes del código
software para llevar a cabo el método de la invención. La referencia
a "por lo menos un ordenador" pretende evidentemente resaltar
lo idóneo para la implementación descentralizada de por lo menos
parte de la configuración de la invención.
La configuración descrita en la presente memoria
especifica una nueva plataforma para la gestión distribuida de una
red de telecomunicaciones y los servicios soportados por la misma
así como una manera de hacer los componentes muy flexibles y
escalables.
La configuración descrita en la presente memoria
resuelve los problemas intrínsecos a las configuraciones de la
técnica anterior ofreciendo tanto una funcionalidades centralizadas
y distribuidas con agentes dispuestos en una estructura jerárquica
específica asignando funciones precisas a cada capa. Por ejemplo, en
una arquitectura de tres capas cada capa tendrá una tarea
específica: una primera capa soportará las funcionalidades de
coordinación/centralizadas, la segunda capa soportará las
funcionalidades distribuidas y la tercera capa hará de intermediario
o proxy de la red con el objetivo de desacoplar las interfaces de
la red de las funciones de gestión.
El grado de flexibilidad de una configuración
como ésta puede ser mejorada aún más recurriendo a herramientas
específicas. Éstas pueden implicar, por ejemplo:
- a)
- Utilizar combinaciones de motores de flujo de trabajo y motores de reglas en los componentes en todas las capas estableciendo una estructura distribuida y jerárquica de flujo de trabajo más motores de reglas; los componentes serán así completamente "educables" en términos de funcionalidades;
- b)
- Definir una base de datos modelo (MDB) que almacene todas las definiciones del proceso (flujos de trabajo y reglas) y del modelo de datos; esto proporcionará un sólo punto donde las funciones de los componentes de la plataforma serán definidas de manera centralizada;
- c)
- Aprovechar a) y b) distribuyendo automáticamente las definiciones del proceso y del modelo de datos en la plataforma; esto evitará la necesidad de sincronizar la estructura jerárquica distribuida de los motores.
El administrador de la plataforma estará de esta
manera en situación de generar cualquier función FCAPS definiéndolas
en la base de datos, mientras que los componentes involucrados
"aprenderán" las nuevas definiciones de proceso (flujo de
trabajo y reglas) y las ejecutarán cuando sea necesario.
Estos procesos pueden cubrir cualquier
funcionalidad FCAP, evolucionado de esta manera desde las
plataformas actuales donde cada componente ejecuta una
funcionalidad de un dominio específico (seguridad, suministro,
rendimiento, etc.) hasta las plataformas donde cada componente pude
ser libremente "enfocado" (posiblemente en tiempo de
ejecución) en funcionalidades de dominios específicos tal como es
requerido por las políticas actuales, disponibilidad de recursos,
estado de la carga, etcétera.
El uso de motores de proceso potencia de hecho
las capacidades de una capa proxy según se describe en el documento
EP-A-1-150 454. Las
extensas actividades de estandarización en los modelos de equipos a
lo largo de los años (véase por ejemplo la nota técnica "Common
Information Model" [CIM] (Modelo de Información Común), DMTF,
enero de 2003 o el documento "Shared Information Data Model
Specification" (Especificación del Modelo de Datos de
Información Compartida), el documento TeleManagementForum GB922
publicación 3.0, abril de 2003) han intentado definir modelos
flexibles y extensibles. La configuración descrita en la presente
memoria desarrolla estos modelos aún más posibilitando
modificaciones de aquellos modelos sin cambiar el código en el
proxy.
A modo de resumen, la configuración descrita en
la presente memoria proporciona una respuesta totalmente
satisfactoria a cinco cuestiones principales que afectan a las
plataformas actuales:
- -
- Una mayor flexibilidad en lo referente a soportar nuevos servicios y modificaciones de los servicios existentes;
- -
- Una mayor flexibilidad en lo referente a soportar nuevas tecnologías de redes que incluyen nuevos tipos de equipos;
- -
- Una distribución mayor y más sencilla de las aplicaciones a través de la movilidad de código;
- -
- Una alineación mejorada (por ejemplo más completa y en tiempo real) del inventario de una red con el estado de la red; y
- -
- Una escalabilidad y control del rendimiento mejorados de la nueva red y de la nueva plataforma de gestión de servicios.
\newpage
Los puntos arquitectónicos significativos y
preferentes de la forma de realización actualmente preferente de la
invención son los siguientes:
- -
- La plataforma de gestión de la red y de los servicios se proporciona en base a unos agentes distribuidos que ejecutan un flujo de trabajo jerárquico de 3 capas y motores de reglas;
- -
- Los flujos de trabajo y las reglas se utilizan no sólo para coordinar las aplicaciones sino también para implementar todos los aspectos de rendimiento de los componentes en la plataforma;
- -
- Se pone a disposición un inventario de modelo centralizado (MDB) para la definición y el almacenamiento general de todas las descripciones del proceso y de todos los modelos de información de recursos de la red. Estas definiciones son a continuación distribuidas por toda la plataforma para su uso en los motores de proceso que alcanzan una sincronización automática de todas las funcionalidades de operación de la plataforma; de esta manera se satisface la necesidad de tener continuamente disponibles la documentación actualizada del modelado de equipos y de los procesos de operación; y
- -
- Se proporciona una capa del inventario de la red distribuida (proxy) que desacopla los equipos del sistema de soporte a las operaciones (OSS) proporcionando una base de datos completamente sincronizada para todos los procesos que necesiten una documentación de la red en tiempo real.
La invención será descrita a continuación, sólo
a modo de ejemplo, en referencia a los dibujos adjuntos, en los
que:
- La figura 1 es un diagrama de bloques que
muestra la arquitectura global de la configuración mostrada en la
presente memoria,
- La figura 2 es un diagrama de bloques que
muestra un escenario de suministro relacionado,
- La figura 3, que incluye dos partes indicadas
como a) y b), respectivamente, muestra diversos ejemplos de flujos
de trabajo de múltiples niveles,
- La figura 4 representa un diagrama de
actividad típico de una configuración descrita en la presente
memoria,
- La figura 5 es un ejemplo de determinados
procesos de capa en la configuración descrita en la presente
memoria,
- La figura 6, que nuevamente incluye dos partes
denominadas a) y b), respectivamente, representa diversos ejemplos
de flujo de trabajo de múltiples niveles con reglas de ejemplo para
la gestión de fallos,
- La figura 7 muestra otro diagrama de actividad
dentro del marco de la configuración descrita en la presente
memoria,
- La figura 8 representa otro escenario que es
probable que surja dentro del marco de la configuración descrita en
la presente memoria,
- La figura 9 representa un caso de uso ejemplar
de una configuración descrita en la presente memoria,
- La figura 10 es un diagrama de flujo de flujos
de trabajo que se dan dentro de la configuración descrita en la
presente memoria, y
- La figura 11 es otro diagrama de actividad
relacionado con la configuración descrita en la presente
memoria.
Para facilitar una comprensión apropiada de los
principios subyacentes a la invención, se proporcionarán a
continuación una serie de definiciones básicas de determinados
términos tal como se utilizan en la descripción de la configuración
descrita en la presente memoria.
Agente: un agente es un proceso independiente y
autónomo con un estado posiblemente persistente y que requiere
comunicarse (por ejemplo la colaboración o competición) con otros
agentes para llevar a cabo sus tareas. Esta comunicación puede
implementarse a través del envío asíncrono de mensajes y mediante el
uso de lenguajes bien conocidos (es decir, Lenguaje de Comunicación
de Agentes o ACL) con una semántica bien definida y aceptada por
todos.
Elemento Gestor: en un entorno de gestión de
redes ésta es una aplicación que gestiona una serie de elementos de
red. Por lo general, el elemento gestor es desarrollado por el
proveedor del elemento de red e incluye funcionalidades como:
configuración, monitorización de alarmas y suministro de los
servicios.
\newpage
OSS (Sistema de Soporte a las Operaciones): en
un entorno de gestión de redes ésta es la aplicación que se encarga
de ejecutar tareas como los problemas de venta de billetes,
facturación, gestión de pedidos. Por lo general los OSS soportan las
aplicaciones de gestión de redes y servicios.
Inventario de redes y servicios: éste es el
sistema que almacena y pone la información del inventario a
disposición de las demás OSS o aplicaciones de gestión. La
información del inventario puede incluir equipos informáticos y de
red, recursos lógicos, topología y servicios. Este
(sub)sistema lleva un seguimiento de la configuración física
y topológica de la red, el inventario de equipos (tarjetas, puertos,
etc.), la conectividad física y lógica de las diferentes capas de
red. Una parte del inventario, habitualmente denominada
"catálogo", tiene las descripciones de todas las entidades
almacenadas en el inventario, tanto las entidades de los servicios
como de la red. El inventario también lleva un seguimiento de los
servicios planificados, suscritos y suministrados. Los servicios se
asocian con los recursos lógicos y físicos de la red.
Aplicación de Gestión: esta es una aplicación
que se ejecuta en un "host" y que se adapta para coordinar el
funcionamiento de uno o más agentes. Puede incluir una interfaz
gráfica de usuario (GUI) y está adaptada para comunicarse con los
agentes distribuidos. Por ejemplo, puede distribuir flujos de
trabajo, llamar a los agentes distribuidos para invocar una
operación en un recurso gestionado y llevar a cabo tareas
administrativas.
Modelo de Información: ésta es la recogida de
información relacionada con todos los objetos gestionados. Esta
información se configura preferentemente en tipos de información (o
categorías), estando cada una de ellas a su vez relacionada con un
tipo dado de objeto gestionado (por ejemplo un ordenador personal,
etcétera). Un objeto gestionado es una de cualquier número de
características específicas de un dispositivo gestionado. En un
entorno de gestión de redes, los dispositivos gestionados son
elementos de red y los objetos gestionados son entidades como:
tarjetas, puertos, conexiones físicas y lógicas, etc.
Proxy: un objeto proxy es un componente que
actúa de mediador en el control de acceso al objeto real, por
ejemplo un elemento de red, sobre el que recae una
funcionalidad.
Motor de Reglas: un motor de reglas es un
sistema para separar las reglas de negocio (lógicamente y/o
físicamente) de la lógica de control y compartirlas en los
almacenes de datos, en las interfaces de usuarios y en otras
aplicaciones. Una vez que se separan las reglas y se comparten, el
motor de reglas permite a los usuarios modificarlas sin hacer
cambios en otros módulos de aplicación. Un motor de reglas es
básicamente un intérprete sofisticado de la instrucción
"if/then". Las instrucciones "if/then" que son
interpretadas se denominan reglas. Las partes "if" de las
reglas contienen condiciones como, por ejemplo, "artículo.precio
> 100 \textdollar". Las partes "then" de las reglas
contienen acciones como, por ejemplo, "recomendar descuento
(5%)". Las entradas a un motor de reglas son un conjunto de
reglas y algunos objetos de datos. Las salidas desde un motor de
reglas son determinadas por las entradas y pueden incluir los
objetos de datos de entrada originales con posibles modificaciones,
nuevos objetos de datos y efectos secundarios. Un motor de reglas se
utiliza para decidir, en tiempo de ejecución, qué reglas aplicar y
cómo éstas deben ser ejecutadas.
Flujo de Trabajo: un flujo de trabajo es
básicamente la automatización total o parcial, por ejemplo de un
proceso de negocio, donde los documentos, la información o las
tareas se pasan de un participante a otro para la acción, según un
conjunto de reglas de procedimiento. Un flujo de trabajo se puede
representar a través de un diagrama de flujo con una secuencia de
tareas y unas dependencias temporales y lógicas entre las tareas
que incluyen unas ramas alternativas o paralelas. Un flujo de
trabajo también se puede describir como una máquina de estados
finitos o con lenguajes descriptivos como por ejemplo XPDL (Lenguaje
de Descripción de Procesos XML).
Motor de flujo de trabajo: un motor de flujo de
trabajo es el componente en un programa de automatización del flujo
de trabajo que posee toda la información relacionada con los
procedimientos, etapas de un procedimiento, y las reglas para cada
etapa. El motor de flujo de trabajo determina si el proceso está
listo para pasar a la etapa siguiente. En resumen, un motor de
flujo de trabajo es un componente adoptado para ejecutar flujos de
trabajo.
Como se muestra en el diagrama de la figura 1,
la configuración descrita en la presente memoria se basa en una
arquitectura que incluye diversos tipos de componentes, es
decir:
- -
- Una colección de conjuntos de proxys o servidores de recursos RP1,..., RPn; RP1..., PRm con adaptadores de protocolo asociados PA1,...PAi; PA1,...PAj,
- -
- Una colección de aplicaciones de agentes AA1,...AA2,
- -
- Una aplicación de gestión (lógica) - MA,
- -
- Un inventario de red centralizado CNI, y
- -
- Una base de datos modelo MDB.
Como se detallará mejor a continuación, la
arquitectura en cuestión (o plataformas) se adapta para gestionar
una red de telecomunicaciones N que incluye equipos de red (no
mostrados en detalle pero de cualquier tipo conocido).
Estos equipos llevan asociados interfaces de
control como por ejemplo aquellas indicadas como if_N_{\alpha},
if_N_{w}, if_N_{y}, if_N_{t} en la figura 1.
Los proxys o servidores de recursos RP1,...,
RPn; RP1..., RPm y los adaptadores de protocolo asociados
PA1,...PAi; PA1,...PAj comprenden básicamente una capa de base que
hace de intermediario o proxy de las interfaces if_N_{\alpha},
if_N_{w}, if_N_{y}, if_N_{t} desacoplándolas de las funciones
de gestión.
Los agentes AAs a su vez comprenden una
comunidad de agentes que coordinan el funcionamiento de la capa de
base (RA, RP) para soportar las funcionalidades de gestión
distribuidas.
La capa de base y la capa de soporte constituyen
capas superpuestas separadas en la arquitectura.
La base de datos MBD es el único punto (lógico)
de definición y almacenamiento de todos los aspectos de rendimiento
y funcionales de la plataforma, flujos de trabajo, reglas, modelos
de información y esquemas. La plataforma distribuye automáticamente
estas definiciones a los componentes de la plataforma. La base de
datos modelo está estrictamente unida a la parte del catálogo del
sistema de inventario de la red.
Siendo la fuente de todos los procesos y la
definición de los datos comunes la base de datos MDB está
intrínsecamente sincronizada con las funcionalidades ofrecidas por
los diferentes componentes y los modelos de información utilizados
para representar recursos y servicios. Esto representa una gran
ventaja para el operador de la arquitectura que no tiene que
recuperar la información a partir de una enorme cantidad de
documentación proporcionada por los diferentes proveedores de
componentes con el riesgo de fallar en estar alineado con todos los
componentes operacionales.
En la forma de realización mostrada, los
procesos están segmentados en tres capas con funciones específicas.
Esta elección pretende satisfacer dos necesidades: tener el menor
número posible de capas (evitando de esta manera la complejidad de
las arquitecturas convencionales) y permitir la asignación libre de
procesos entre una implementación distribuida y una implementación
centralizada.
Eso implica que la presencia de una capa 1
centralizada (que se corresponde con la aplicación de gestión MA),
una capa de soporte 2 completamente distribuida (que se corresponde
con las aplicaciones de agentes - en lo sucesivo en la presente
memoria, abreviadamente, AAs) más una capa proxy 3 independiente que
desacopla la red de la plataforma de gestión. Esta segmentación
también posibilita la provisión de diferentes vistas del servicio,
por ejemplo una vista de negocio por la capa 1, una vista de
realización por la capa 2 y una vista de ingeniería por la capa 3.
Debe entenderse que hacer referencia a la aplicación de gestión MA y
la capa compuesta por las aplicaciones de agentes AAs no excluye la
posibilidad de que los respectivos componentes puedan estar por lo
menos parcialmente dispuestos en la misma ubicación geográfica.
Los adaptadores de protocolo (en lo sucesivo en
la presente memoria, abreviadamente, PA) están dispuestos por lo
general en conjuntos, siendo cada conjunto responsable de
interconectar todos los equipos de red de un área designada que
ofrecen el mismo protocolo de interfaz de programación de
aplicaciones (API), por ejemplo SNMP ("Simple Network Management
Protocol" o Protocolo Simple de Administración de Red), Telnet,
TL1, etc. Cada PA ofrece, como un servicio prestado a los proxys o
servidores de recursos RP, la ejecución de operaciones básicas en
los equipos; ejemplos de servicios para un adaptador de protocolo
SNMP son: "get" u obtener(parámetros), "set" o
establecer(parámetros).
Cada proxy o servidor de recursos (en lo
sucesivo en la presente memoria, abreviadamente, RP) es responsable
de crear, mantener y gestionar una así denominada "imagen" de
un único equipo en la red N. La imagen es una representación de la
configuración del equipo según un modelo de información
definido.
La alineación de la imagen a la red se efectúa
de la siguiente manera:
- -
- Todas las acciones que lleva a cabo la plataforma de gestión en la red son realizadas en realidad por RPs que invocan operaciones a través de los PAs apropiados;
- -
- Todas las notificaciones (como alarmas, trampas) enviadas por los equipos son recibidas por los proxys; esto no evita que los equipos envíen notificaciones también a otros destinos;
- -
- La verificación periódica de la alineación entre la imagen del equipo y el propio equipo es llevada a cabo por los proxys o servidores de recursos (RPs).
La imagen de equipo único se puede enriquecer
mediante una información del gestor de elementos (EM) como por
ejemplo información entre equipos como la topología, para dar una
vista de extremo a extremo de los servicios repartidos entre
múltiples equipos, y otra información disponible en el EM.
Cada RP ejecuta los procesos típicos del nivel
RP utilizando un ejecutor de procesos (PE): estos procesos pueden
definirse como procesos de la "capa 3" y se pueden estructurar
en subcapas. Los procesos en la parte superior de la capa 3 se
pueden invocar externamente, de esta manera son servicios que cada
RP ofrece a la aplicación o a las aplicaciones de agentes asociadas
y a aplicaciones externas. Representan las operaciones que se
pueden llevar a cabo automáticamente (de esta manera como una única
transacción) en el equipo que gestiona el RP.
Ejemplos de servicios ofrecidos por el RP son:
configurar un puerto, crear una conexión cruzada, modificar un
atributo de conexión; cada uno de éstos puede incluir secuencias de
comandos básicos a ser enviados a y/o recibidos por los equipos.
Los procesos en la parte inferior de la capa 3
utilizan los servicios ofrecidos por los PAs. En la figura 5 se
muestra un ejemplo de un proceso de "capa 3".
La imagen manipulada por un RP se define
dinámicamente por el modelo de información del recurso representado
(por ejemplo un equipo de red dado). Este modelo es definido por la
interfaz GUI, almacenado en la base de datos MDB, a continuación
distribuido por la aplicación de gestión a los RPs. Estos cargan el
modelo y finalmente lo instancian con valores recuperados por el
recurso. Nuevamente la instanciación se lleva a cabo de manera
flexible utilizando el PE.
De esta manera los cambios y las adiciones de
los modelos de información (como la actualización de versiones, la
introducción de nuevos equipos) no requieren ningún cambio de
software apreciable en los componentes de la plataforma. Esto
consigue un alto grado de flexibilidad, en la medida en que el
protocolo API de los equipos esté soportado por el PA. La muy lenta
evolución de los protocolos (SNMP, Telnet) comparado con el alto
rendimiento exigido a los PAs hace que utilizar el PE para
implementar los PAs sea la elección menos preferente.
Como componente fundamental de la plataforma de
gestión, el inventario de red CNI se configura en dos partes, es
decir: un inventario de red distribuido (DNI) y un inventario de red
centralizado (CNI).
El primero (es decir el DNI) es la colección de
todas las virtualizaciones (imágenes) contenidas en todos los RPs;
se utiliza para todas las tareas en tiempo real o casi en tiempo
real como suministro, seguridad, rendimiento, control, etcétera,
donde es necesaria la información actualizada sobre la configuración
y el estado de la red para la precisión y efectividad de la tarea.
Estas tareas en tiempo real son difíciles de llevar a cabo
dependiendo de una base de datos centralizada lógicamente, como es
el caso en las implementaciones actuales del inventario de red.
La última parte (es decir, el CNI) se
corresponde con el concepto habitual de un componente del inventario
de red. Se utiliza para tareas en tiempo no real donde las
actualizaciones continuas no son posibles para una arquitectura
centralizada. Ejemplos de dichas tareas son el diseño de la red, la
planificación de la red, el análisis de la tendencia de la
capacidad.
El inventario de red centralizado se actualiza
periódicamente recuperando la información a partir de los RPs.
Los proxys pueden interactuar uno con otro
directamente para tareas que requieran una interrelación simple. Por
ejemplo, para establecer una ruta de extremo a extremo, una AA dada
puede utilizar la información de topología (qué equipo está
conectado a qué otro equipo) almacenada en los respectivos RPs.
Cada AA es responsable de coordinar un conjunto
respectivo de RPs y de ejecutar los procesos típicos de la capa de
agentes utilizando un PE. Estos procesos deben ser ejecutados de una
manera distribuida y se pueden estructurar en subcapas. Los
procesos en la parte superior de esta "capa 2" se pueden
invocar externamente; de esta manera, estos son los servicios que
una AA ofrece a la aplicación de gestión MA. Estos servicios se
caracterizan por ser independientes del proveedor y de la
tecnología, por ejemplo "crear un servicio DSL", resultando en
diferentes secuencias de acciones bien sea la tecnología de red ADSL
o VDSL y bien sea el proveedor el proveedor XX o el proveedor YY.
Los procesos en la parte inferior de la capa 2 utilizan servicios
(es decir, invocan procesos) ofrecidos por los RPs.
Cada AA no requiere la actualización del
software para soportar nuevos servicios y tecnologías. Esto se debe
a la flexibilidad de los procesos que son recibidos por la
aplicación de gestión MA, cargados y ejecutados por la capa de
AA.
Las AAs interactúan unas con otras mediante un
protocolo de comunidad (un mecanismo de envío de mensajes) para
soportar la ejecución distribuida de las funcionalidades de gestión,
por ejemplo el diseño del circuito distri-
buido.
buido.
Cada AA es responsable de la monitorización del
rendimiento local para informar al gestor con respecto al estado del
rendimiento.
La aplicación de gestión MA es responsable de
las siguientes tareas:
- -
- Gestionar la distribución de los procesos y los modelos de información relacionados de la "capa 2" y de la "capa 3" a partir de la base de datos MDB a las diversas AAs y RPs recuperando las definiciones de proceso desde la base de datos MDB;
\newpage
- -
- Monitorizar el estado de la plataforma con la información proporcionada por las AAs (y posiblemente los RPs), incluyendo la distribución de los componentes, la gestión del dominio (separación de la red completa entre las AAs), la monitorización del rendimiento y las acciones consiguientes como la redistribución de la carga entre las AAs para alcanzar un balanceo de carga adecuado;
- -
- Interaccionar con sistemas externos, como otros sistemas de soporte de operaciones (OSSs) y sistemas de soporte de facturación (BSSs);
- -
- Ejecutar los procesos típicos de la capa de gestión (como se detalla mejor a continuación).
Los procesos de dicha "capa 1" se pueden
disponer en subcapas y se caracterizan para proporcionar
funcionalidades que requieren la interacción con entidades externas
(diferentes de las AAs) o la coordinación entre agentes que no
puede ser llevada a cabo fácilmente o eficientemente de manera
distribuida por las AAs. La gran flexibilidad de la arquitectura
permite suavizar la evolución: por ejemplo, la mejora del protocolo
de comunidad puede posibilitar la migración de un proceso desde la
capa 1 a la capa 2.
Los ejecutores de procesos para cualquier capa
están destinados a ser un flujo de trabajo (un diagrama de flujo),
un motor de reglas, o una combinación de los dos. Por ejemplo, un
proceso de suministro se representa mejor como flujo de trabajo
mientras que una correlación de alarmas se representa mejor como una
combinación de reglas. Esta combinación permite al administrador de
la plataforma establecer cualquier funcionalidad FCAPS y dejarla
evolucionar con un alto grado de flexibilidad. Siempre que sea
posible y recomendable, es preferente utilizar flujos de trabajo ya
que evitan la complejidad de tener que ocuparse de los conflictos de
reglas y la gestión de reglas.
Los motores de proceso están embebidos dentro de
las MAs, AAs y RPs; de hecho una ubicación externa implicaría
invocaciones remotas con la probabilidad de producir degradaciones
del rendimiento.
Las diversas MAs, AAs y RPs muestran tanto un
comportamiento reactivo como proactivo, ya que se activan ante
sucesos pero también pueden comenzar procesos.
Cada una de las AAs y de los RPs así como de las
MA puede soportar cualquier funcionalidad FCAPS. Eso permite la
personalización de las tareas de los componentes y la reasignación
en base a la prioridad de las tareas y a las necesidades de
recursos, por ejemplo asignando una mayor parte de los agentes
durante el día para el suministro de servicios y una mayor parte de
los agentes durante la noche para la optimización de la red.
La movilidad de los agentes resulta útil para
mover los agentes entre las máquinas para resolver la utilización
de los agentes así como las cuestiones de tolerancia a fallos. Si
por cualquier razón un agente "deja de funcionar", se pude
instanciar y mover un nuevo agente hacia otra máquina en
funcionamiento para reemplazar al agente no disponible. La MA
monitoriza periódicamente la presencia de agentes AA; si cualquiera
de estos "deja de funcionar" a continuación la MA puede activar
una "resurrección" de agentes a través de la movilidad.
La movilidad de agentes resulta también útil
para mover agentes entre máquinas para resolver problemas de
balanceo de carga. Esto puede ocurrir cuando, por ejemplo, una AA
que está siendo vigilada continuamente por una MA para comprobar si
ejecuta un proceso, por ejemplo un proceso de activación de ADSL, se
convierte en un cuello de botella llevando a la ralentización del
funcionamiento. Se puede instanciar y mover un nuevo agente AA bien
hacia la máquina donde se está ejecutando el agente AA sobrecargado
(para distribuir las invocaciones de procesos que vienen de la MA)
o bien hacia una máquina con una menor carga de CPU.
El agente AA comunica las actuales condiciones
de carga a la MA, tras lo cual la MA ejecuta las acciones requeridas
por ejemplo implementando una movilidad de agentes. De esta manera
la MA decide si los agentes deben ser movidos o no, para mantener el
control de la difusión de los agentes.
La arquitectura descrita es de esta manera
intrínsecamente adaptativa y puede detectar y predecir la
saturación.
Una forma de realización preferente de la
configuración descrita en la presente memoria utiliza JADE ("Java
Agent Development framework" o Herramientas de Desarrollo de
Agentes Java) para implementar agentes con características de
movilidad, el modelo SID (citado en la parte introductoria de la
esta descripción) para definir el modelo común, BPML ("Business
Process Modeling Language" o Lenguaje de Modelado de Procesos de
Negocio) para la definición de procesos, y JESS ("Java Expert
System Shell" o Sistema Experto en Java) para la implementación
de PEs.
Como primer ejemplo se puede considerar un
escenario de suministro de tres capas.
Concretamente, la figura 2 representa el
establecimiento de un escenario de suministro de servicios que
muestra la flexibilidad y la escalabilidad alcanzadas.
Se enviará un servicio de banda ancha "Oferta
1" en una red TLC que incluya los dispositivos de acceso (por
ejemplo un Equipo ADSL, ADSL E), una red ATM y uno o más servidores
de acceso de banda ancha BAS para conseguir una conectividad IP.
AA1, AA2, AA3 son los agentes que gestionan,
respectivamente:
- -
- El proxy o servidor de recursos RP1 que representa la imagen del Equipo ADSL (es decir el punto extremo A del circuito de extremo a extremo),
- -
- El proxy o servidor de recursos RP2 que representa la imagen del conmutador ATM conectado al Equipo ADSL, y
- -
- El proxy o servidor de recursos PR3 que representa la imagen del BAS (es decir el punto extremo Z del circuito de extremo a extremo).
En la figura 3 se muestran los flujos de trabajo
multinivel implicados en la actividad de suministro del servicio
"Oferta 1".
Concretamente, el flujo de trabajo del nivel 1
(figura 3a, izquierda) consiste en dos etapas o tareas. La primera
(conectividad ADSL, indicada como 100) se despliega hasta un flujo
de trabajo de nivel 2 que se ejecuta en el nivel AA mientras que
una tarea de buzón (generalmente indicada como 102 pero no detallada
en este ejemplo) puede ser llevada a cabo por una plataforma OSS
externa.
De esta manera la tarea de conectividad ADSL es
un flujo de trabajo W2 del nivel 2 como se detalla en el lado
derecho de la figura 3a que consiste en una secuencia de flujos de
trabajo del nivel 3, dependientes de la tecnología y del proveedor,
que se ejecutan a nivel del proxy o servidor de recursos como se
detalla en la figura 3b.
Concretamente, la referencia 104 indica una
etapa que lleva a elegir entre los proveedores A, B y C que
proporcionan el equipo ADSL, el conmutador ATM, y el BAS de la
figura 2, respectivamente. Las etapas 106a, 106b, 106c indican la
creación de unos respectivos puertos para estos proveedores, a los
que posteriormente se les proporciona unas respectivas conexiones
virtuales (VCC) en las etapas 108a, 108b, 108c. La etapa 110 indica
la posible adición de una dirección IP a la terminación VCC de la
rama del proveedor C.
Finalmente, los flujos de trabajo del nivel 3
son secuencias de los comandos que deben ser llevados a cabo en el
equipo por el proxy o servidor de recursos a través de los
adaptadores de protocolo adecuados.
La figura 4 muestra el diagrama de actividad de
diversos componentes de software representados en la figura 2
excepto el agente AA3 y el proxy o servidor de recursos RP3.
Las acciones "Encontrar agente" y
"Encontrar Proxy" son llevadas a cabo por la aplicación de
gestión MA o por los componentes distribuidos (agente de aplicación
AA o proxy o servidor de recursos RP) en base al algoritmo de
diseño de circuitos distribuidos no detallado en esta invención
(para ese fin se puede utilizar cualquier algoritmo de búsqueda de
ruta bien conocido). Estas acciones, llevadas a cabo a través de una
estricta colaboración entre agentes de aplicaciones y proxys o
servidores de recursos son necesarias para encontrar la ruta entre
el punto extremo A y el punto extremo Z del circuito a
suministrar.
Este enfoque es muy flexible ya que implica
cambios de gestión en cada capa.
De hecho, cada cambio en la vista de negocio del
servicio es tenido en cuenta mediante la simple modificación en la
base de datos MDB de los procesos de la capa 1 implicados y
moviéndolos a la MA.
Cada cambio en la vista de red del servicio (por
ejemplo algún equipo de ADSL del Proveedor A es sustituido por un
equipo ADSL del Proveedor D) es tenido en cuenta mediante la simple
modificación en la base de datos MDB de los procesos de la capa 2
implicados (es decir, añadiendo una nueva rama) y distribuido por la
MA a las AAs.
Cada cambio en la vista de ingeniería del
servicio (por ejemplo una actualización del firmware en un nodo) es
tenido en cuenta mediante la simple modificación en la base de datos
MDB de los procesos de la capa 3 implicados.
En este escenario se da por hecho que ya está
disponible un adaptador de protocolo adecuado para el nuevo
equipo.
Como segundo ejemplo se considerará la misma
configuración descrita en lo anteriormente indicado en el caso de un
escenario de fallos: se da por hecho que el servicio "Oferta 1"
se interrumpe por algunas razones, y se visualiza un mensaje
correspondiente en la consola de la MA.
La figura 6 ilustra un ejemplo de flujos de
trabajo multinivel mezclados con motores de reglas que pueden hacer
frente a estas circunstancias.
El proceso del nivel 1 es nuevamente un flujo de
trabajo y requiere que el mensaje de alerta sea visualizado en una
consola de la MA cuando falle la conectividad ADSL 100 o el
subservicio de buzón 102 con información adicional acerca de las
razones del fallo (véase la figura 6a, izquierda).
\newpage
El proceso del nivel 2 (figura 6a, derecha) está
basado en reglas: la aplicación de agentes KB (Base de Conocimiento)
contiene todos los datos relevantes (por ejemplo el estado de los
recursos de la red, las alarmas activas) recogidos a partir de
diversos sucesos, desde los RPs pero también desde otras AAs. La
regla "Fallo en la ruta ADSL" es un ejemplo de correlación de
alarma (más concretamente, correlación de hechos). Por ejemplo,
cuando la regla se hace cierta (etapa 200) envía (en una etapa 202)
un nuevo suceso al PE del nivel 1 (dentro de la MA).
El Proceso del nivel 3 (mostrado en la figura 6b
en el caso de un fallo de verificación del puerto, por ejemplo el
equipo del Proveedor A) está nuevamente basado en reglas: se ejecuta
una regla (etapa 204) tan pronto como un RP recibe un suceso desde
un PA, como una trampa SNMP. Esta regla consigue más información
sobre el estado del puerto (etapa 206) a través de la
interoperación de PAs. Tras verificar en la etapa 208 si el estado
del puerto es operativo, ésta alerta a la AA, en caso necesario, en
la etapa 210.
La figura 7 muestra el diagrama de actividad de
diversos componentes de la plataforma.
Este caso da por hecho que el PA1 (un adaptador
de protocolo SNMP) recibe una trampa SNMP con información "Puerto
X no funciona" en un recurso reflejado por el RP1, a lo largo de
la ruta ADSL para el servicio "Oferta 1". El motor de reglas en
el RP1 activa la regla "Verificar fallo de puerto", a
continuación propaga el suceso a la AA1. La AA1 acepta el suceso y
lo almacena en la KB.
Otros sucesos, en diferente orden y en
diferentes momentos, pueden añadir hechos en forma de
KB-AA1 de cualquier RP bajo el alcance de la AA1
(por ejemplo la regla B y la regla C). Los hechos en la KB pueden
provocar reglas para enviar sucesos a otras AA (por ejemplo desde
AA2 a KB-AA1), para la correlación de alarmas entre
AAs. Cuando la condición en la regla AA1 "Verificar ruta ADSL"
se hace cierta, se ejecuta el flujo de trabajo y se envía un nuevo
suceso a la MA1, con información leída a partir de los hechos
casados por la regla.
Finalmente, el flujo de trabajo ejecutado en la
MA1 hace que aparezca en una consola conectada a la MA una alarma
como "fallo del servicio de la Oferta 1 - fallo en la unión entre
RP 1 y RP 2".
Una ventaja principal de la configuración
mostrada consiste en la reducción del tráfico en la red debido a la
señalización de alarmas. Cada componente (RP, AA y también MA) toma
parte en el procesamiento de las alarmas en diferentes niveles de
abstracción. De esa manera se puede implementar la función de
correlación de alarmas (por ejemplo en el nivel de los agentes AA)
muy próximo a las posibles fuentes de alarma. Este enfoque reduce
el tráfico en la red debido a que las alarmas tienen que ser
enviadas a un sistema central. La flexibilidad inherente a los
flujos de trabajo y la definición de reglas permite la introducción
de nuevos equipos con un mínimo esfuerzo (se ha descrito la misma
ventaja en el caso del suministro).
Un tercer ejemplo resalta la flexibilidad de la
gestión de equipos a través de la configuración del flujo de trabajo
del nivel 3.
Este ejemplo atestigua la flexibilidad en la
manipulación del modelo de datos: tras la adición de un nuevo tipo
de equipo en una red, mediante la simple redefinición (por ejemplo
mediante una GUI adaptada para gestionar archivos XML de manera
amigable, por ejemplo) del modelo de mapeo, la capa proxy crea y
mantiene automáticamente una representación sincronizada del nuevo
equipo, mientras que nunca se interrumpe el funcionamiento de de
todas las funcionalidades FCAPS en la capa distribuida.
Concretamente, este ejemplo está destinado a
mostrar cómo la configuración descrita puede manejar un cambio de
modelo de datos de manera flexible y sencilla para un equipo con
características de dependencia de su proveedor y de su tecnología.
En resumen, el proceso de reemplazar un equipo de un Proveedor A por
un equipo de un Proveedor B requiere sólo actualizar el modelo de
datos (si es que ha cambiado) y modificar los procesos del flujo de
trabajo del nivel 3. Los RPs son capaces de reconocer el nuevo
equipo y utilizar el nuevo modelo de datos y los flujos de trabajo
del nivel 3 para poblar el modelo de datos.
A modo de ejemplo se muestran en la figura 8 un
conmutador ATM y el escenario relacionado.
El modelo de datos común CMD (de conformidad con
un modelo común como el SID de TMF o el CIM de DMTF) se especifica
utilizando un archivo de esquema XML (xsd) almacenado en la base de
datos MDB junto con los procesos del nivel 3. Las tablas de datos
del catálogo en el inventario de red CNI guardan los datos del
catálogo del equipo (información característica necesaria para
describir los recursos de la red, a menudo denominada también
"metadatos" o "plantillas"). El proxy o servidor de
recursos RP representan el equipo Conmutador ATM de un proveedor
"A". Guarda la imagen El del equipo Conmutador ATM. Tanto el
dato del catálogo como la imagen del equipo son validados utilizando
el modelo de datos común especificado en el archivo xsd.
El ejemplo de modelo de datos considera el caso
representado en la figura 9. Un operador O necesita reemplazar un
conmutador ATM de un Proveedor "A" por un conmutador ATM de un
Proveedor "B".
Este proceso incluye una serie de subtareas que
el operador O debe llevar a cabo.
Una primera subtarea es instalar el equipo
hardware: esta tarea se ocupa de la instalación física del nuevo
equipo.
Una segunda subtarea es insertar el nuevo equipo
en el catálogo. Los usuarios tienen que insertar las características
del nuevo equipo en el catálogo (por ejemplo el nombre del nuevo
proveedor). Se da por hecho que los datos del catálogo común están
almacenados en un OSS de inventario de red centralizado (CNI).
Una tercera subtarea es reescribir los flujos de
trabajo del nivel 3. Esto resulta necesario para poder gestionar el
nuevo equipo (utilizando los comandos del equipo dependiente del
nuevo proveedor) y ocuparse de la imagen del nuevo equipo (por medio
de los nuevos comandos apropiados para rellenar la imagen de memoria
del proxy o servidor de recursos).
En la figura 10 se muestra una parte de los
flujos de trabajo del nivel 3, implicados en la gestión del modelo
de datos del proxy o servidor de recursos. Las partes del flujo de
trabajo mostradas se ocupan de la gestión de los datos de la tarjeta
del equipo.
Los flujos de trabajo en cuestión contienen los
siguientes tipos de comandos:
- Comando del equipo: comandos del equipo dependientes del proveedor, llevados a cabo por el proxy o servidor de recursos a través de los adaptadores de protocolo adecuados (por ejemplo conseguir una tarjeta A o conseguir una tarjeta B - Etapa 300).
- Comando CNI: los comandos llevados a cabo en el CNI (por ejemplo: inventario.obtenerInformaciónCatálogo(...) - etapa 302) para consultar información de catálogo;
- Comando de Imagen del proxy o servidor de recursos: comandos llevados a cabo por el proxy o servidor de recursos para actualizar (o crear) su imagen de equipo (por ejemplo: imagen.establecerAtributo(...) - etapa 310).
Siguiendo una verificación (etapa 304) como de
la disponibilidad en la imagen del proxy de un objeto que representa
una tarjeta (si no, el objeto que se crea en la etapa 306), la parte
del flujo de trabajo permite obtener los diversos valores de
atributos de la tarjeta (denominados Atributo 1, Atributo 2,
Atributo 3) desde el equipo (etapa 308) y a continuación actualizar
(en la etapa 310) la imagen del proxy o servidor de recursos con los
valores recuperados.
Las diferencias del equipo dependiente del
proveedor afectan al flujo de trabajo del nivel 3. Efectivamente, la
tarjeta del equipo del nuevo Proveedor B (Tarjeta B) contiene sólo
un atributo (denominado Atributo X). Por consiguiente, el nuevo
flujo de trabajo puede ser representado nuevamente con la figura 10
donde las etapas 308 y 310 contienen comandos para obtener sólo el
valor del atributo X del equipo y por consiguiente actualizar la
imagen RP.
El código XML que se incluye a continuación
muestra una versión de XML, de conformidad con el modelo de datos
común, de la imagen proxy o servidor de recursos posterior a la
ejecución del flujo de trabajo del nivel 3 para el equipo del
proveedor A.
El código XML adicional que se incluye a
continuación muestra una versión de XML, de conformidad con el
modelo de datos común, de la imagen proxy o servidor de recursos
posterior a la ejecución del flujo de trabajo del nivel 3 para el
equipo del proveedor B.
\vskip1.000000\baselineskip
La figura 11 muestra el diagrama de actividad de
los diversos componentes de la plataforma involucrados en la gestión
del modelo de datos del proxy o servidor de recursos. La GUI está
destinada a ser una interfaz de usuario gráfica utilizada por un
operador humano para trabajar en la MDB y para controlar la MA.
"Eqpt" significa "conmutador ATM" del equipo.
El nuevo equipo con sus características
dependientes del proveedor es de esta manera gestionado de una
manera flexible y simple. Por ejemplo, el proceso de reemplazar el
equipo del Proveedor A con un equipo del proveedor B implica sólo
la configuración de los datos del catálogo del inventario de red y
del nuevo flujo de trabajo del nivel 3. Los agentes son capaces de
reconocer el nuevo equipo en el catálogo y el nuevo flujo de trabajo
del nivel 3 asociado y de utilizar éstos para gestionar el nuevo
equipo y su imagen del proxy o servidor de recursos.
La configuración descrita se puede extender para
un número de capas superior a tres, donde la capa de agentes se
puede estructurar en una jerarquía. Preferentemente, la capa proxy
no se divide para evitar introducir cuellos de botella en las
interacciones de red; además, la evolución del equipo puede resultar
en que la capa proxy sea configurada en los equipos, cuando
ofrezcan interfaces estándares con un modelo de datos unificado. Si
todas las funcionalidades se pueden implementar como distribuidas,
se puede prescindir de una capa de gestión/coordinación separada
promocionando algunos agentes a tareas de comunicación externa.
Resulta por tanto evidente que, los principios
básicos de la invención que permanecen iguales, los detalles y las
formas de realización pueden variar ampliamente con respecto a lo
que ha sido descrito e ilustrado simplemente a modo de ejemplo, sin
alejarse del alcance de la invención presentada como se define en
las reivindicaciones adjuntas.
\vskip1.000000\baselineskip
Esta lista de referencias citadas por el
solicitante es solamente para conveniencia del lector. La misma no
forma parte del documento de patente europea. A pesar de que se ha
tenido mucho cuidado durante la recopilación de las referencias, no
deben excluirse errores u omisiones y a este respecto la OEP se
exime de toda responsabilidad.
\vskip1.000000\baselineskip
- \bullet US 6243396 A
- \bullet EP 1150454 A
- \bullet US 20020032769 A1
- \bullet WO 0102973 A
Claims (36)
1. Arquitectura de un sistema para gestionar una
red de comunicaciones (N) que incluye unos equipos de red, teniendo
dichos equipos asociadas unas interfaces de control
(if_N_{\alpha}, if_N_{w}, if_N_{y}, if_N_{t}), comprendiendo
la arquitectura:
- -
- Una capa de base (PA, RP) para hacer de intermediario o proxy de dichas interfaces (if_N_{\alpha}, if_N_{w}, if_N_{y}, if_N_{t}) y para desacoplar dichas interfaces (if_N_{\alpha}, if_N_{w}, if_N_{y}, if_N_{t}) de las funciones de gestión, comprendiendo dicha capa de base ejecutores de procesos distribuidos (PE) para ejecutar de una manera distribuida los procesos concernientes a la gestión de dicha red, comprendiendo cada ejecutor de procesos por lo menos uno de un motor de flujos de trabajo, un motor de reglas y una combinación de los mismos, y
- -
- Una capa de soporte (AA) superpuesta a dicha capa de base y que comprende una pluralidad de agentes que coordinan el funcionamiento de dicha capa de base (PA, RP) para soportar funcionalidades de gestión distribuidas.
Donde dicha capa de base incluye una subcapa de
módulos proxy o servidores de recursos (RP), proporcionando cada
módulo proxy (RP) una representación de la configuración de por lo
menos un equipo de red según un modelo de información definido y
siendo configurados para alinear dicha representación al por lo
menos un equipo de red:
- -
- Llevando a cabo acciones de gestión en dicha red (N);
- -
- Recibiendo en dichos módulos proxy o servidores de recursos (RP) las notificaciones enviadas por el por lo menos un equipo de red; y
- -
- Llevando a cabo verificaciones periódicas de la alineación entre la representación del equipo de red y el equipo de red.
2. Arquitectura según la reivindicación 1,
caracterizada porque dichos módulos proxy o servidores de
recursos pueden soportar funcionalidades FCAPS.
3. Arquitectura según la reivindicación 1,
caracterizada porque dicha capa de base incluye:
- -
- Una subcapa de adaptadores de protocolo (PA) para interconectar un conjunto de equipos de red que ofrecen un protocolo dado;
Y donde la etapa de llevar a cabo las acciones
de gestión se hace invocando la operación a través de por lo menos
un adaptador de protocolo asociado (PA).
4. Arquitectura según cualquiera de las
reivindicaciones anteriores donde los módulos proxy o servidores de
recursos (RP) están configurados para alinear dicha representación
al por lo menos un equipo de red llevando a cabo todas las acciones
de gestión en dicha red (N) y donde todas las notificaciones
enviadas por el por lo menos un equipo de red son recibidas en
dichos módulos proxy o servidores de recursos.
5. Arquitectura según cualquiera de las
reivindicaciones anteriores, caracterizada porque dichos
módulos proxy o servidores de recursos (RP) están configurados para
el enriquecimiento con información de gestión del elemento.
6. Arquitectura según cualquiera de las
reivindicaciones anteriores, caracterizada porque dichos
módulos proxy o servidores de recursos (RP) están configurados para
ejecutar procesos utilizando dichos ejecutores de procesos (PE).
7. Arquitectura según cualquiera de las
reivindicaciones anteriores, caracterizada porque dichos
módulos proxy o servidores de recursos (RP) están configurados para
interactuar directamente uno con otro en una relación de
interfuncionamiento.
8. Arquitectura según la reivindicación 1,
caracterizada porque dichos agentes (AA) en dicha comunidad
están configurados para ejecutar servicios independientes del
proveedor y de la tecnología.
9. Arquitectura según la reivindicación 1,
caracterizada porque incluye por lo menos una aplicación de
gestión (MA) configurada para llevar a cabo funciones seleccionadas
de entre el grupo que consiste en:
- -
- Gestionar la distribución de los procesos entre dicha capa de base y dicha capa de soporte,
- -
- Gestionar la distribución de los modelos de información entre dicha capa de base y dicha capa de soporte,
- -
- Monitorizar el estado de la arquitectura en base a la información proporcionada por dichos agentes (AA) en dicha comunidad,
- -
- Interactuar con sistemas externos, y
- -
- Ejecutar procesos de gestión.
10. Arquitectura según la reivindicación 9,
caracterizada porque dicha por lo menos una aplicación de
gestión (MA) comprende una capa superior adicional separada en dicha
arquitectura.
11. Arquitectura según la reivindicación 9,
caracterizada porque dicha por lo menos una aplicación de
gestión (MA) está por lo menos parcialmente integrada con dicha capa
de soporte (AA).
12. Arquitectura según la reivindicación 1,
caracterizada porque todas dichas capas en dicha arquitectura
incluyen ejecutores de procesos (PE).
13. Arquitectura según la reivindicación 12,
caracterizada porque cada uno de dichos ejecutores de
procesos (PE) en cada una de dichas capas comprende por lo menos uno
de un motor de flujos de trabajo, un motor de reglas y una
combinación de los mismos.
14. Arquitectura según la reivindicación 1,
caracterizada porque dicha arquitectura incluye unos agentes
(AA) albergados en diferentes máquinas, pudiéndose mover dichos
agentes entre máquinas diferentes.
15. Arquitectura según la reivindicación 1,
caracterizada porque dichas capas (PA; RP; AA; MA) en dicha
arquitectura incluyen componentes adaptados para llevar a cabo unas
respectivas funciones basadas en respectivas informaciones de
instrucciones proporcionadas a las mismas y porque se proporciona
una base de datos (MDB) que almacena dicha información de
instrucciones, estando la arquitectura configurada para distribuir
dicha información de instrucciones desde dicha base de datos (MDB) a
dichos componentes.
16. Arquitectura según la reivindicación 15,
caracterizada porque dicha información de instrucciones
comprende por lo menos una de:
- -
- Definiciones de procesos como por ejemplo los flujos de trabajo y las reglas, y
- -
- Definiciones de modelos de datos.
17. Arquitectura según la reivindicación 15,
caracterizada porque incluye por lo menos una aplicación de
gestión (MA) configurada para gestionar la distribución de los
modelos de información entre dicha capa de base y dicha capa de
soporte, y porque dicha base de datos (MDB) está asociada con dicha
por lo menos una aplicación de gestión.
18. Método de gestión de una red de
comunicaciones (N) que incluye unos equipos de red, teniendo dichos
equipos asociadas unas interfaces de control (if_N_{\alpha},
if_N_{w}, if_N_{y}, if_N_{t}), comprendiendo el método las
etapas de:
- -
- Proporcionar una capa de base (PA, RP) que hace de intermediario o proxy de dichas interfaces (if_N\alpha, if_Nw, if_Ny, if_Nt) y que desacopla dichas interfaces (if_N\alpha, if_Nw, if_Ny, if_Nt) de las funciones de gestión,
- -
- Ejecutar, en dicha capa de base (PA, RP), procesos distribuidos concernientes a la gestión de dicha red, comprendiendo cada uno de dichos procesos por lo menos uno de flujos de trabajo, reglas y combinaciones de los mismos, y
- -
- Soportar las funcionalidades de gestión distribuidas mediante una capa de soporte (AA) superpuesta a dicha capa de base (PA, RP) y que comprende una pluralidad de agentes que coordinan las operaciones de dicha capa de base (PA, RP)
- -
- Proporcionar una subcapa de módulos proxy o servidores de recursos (RP), proporcionando cada módulo proxy (RP) una representación de la configuración de por lo menos un equipo de red según un modelo de información definido y estando configurados para alinear dicha representación a el por lo menos un equipo de red;
- -
- Llevando a cabo acciones de gestión en dicha red (N);
- -
- Recibiendo en dichos módulos proxy o servidores de recursos (RP) las notificaciones enviadas por el por lo menos un equipo de red; y
- -
- Llevando a cabo verificaciones periódicas de la alineación entre la representación del equipo de red y el equipo de red.
19. Método según la reivindicación 18,
caracterizado porque incluye las etapas de incluir unas
funcionalidades FCAPS mediante dichos módulos proxy o servidores de
recursos (RP).
20. Método según la reivindicación 18 ó 19,
caracterizado porque incluye las etapas de proporcionar:
- -
- Una subcapa de adaptadores de protocolo (PA) para interconectar un conjunto de equipos de red que ofrecen un protocolo dado
Y donde la etapa de llevar a cabo las acciones
de gestión se hace invocando la operación a través de por lo menos
un adaptador de protocolo asociado (PA).
21. Método según cualquiera de las
reivindicaciones 18 a 20, donde los módulos proxy o servidores de
recursos (RP) están configurados para alinear dicha representación
al por lo menos un equipo de red llevando a cabo todas las acciones
de gestión en dicha red (N) y donde todas las notificaciones
enviadas por el por lo menos un equipo de red son recibidas en
dichos módulos proxy o servidores de recursos.
22. Método según cualquiera de las
reivindicaciones 18 a 21, caracterizado porque incluye la
etapa de configurar dichos módulos proxy o servidores de recursos
(RP) para el enriquecimiento con información de gestión del
elemento.
23. Método según cualquiera de las
reivindicaciones 18 a 22, caracterizado porque incluye la
etapa de configurar dichos módulos proxy o servidores de recursos
(RP) para ejecutar procesos utilizando un ejecutor de procesos
(PE).
24. Método según cualquiera de las
reivindicaciones 18 a 23, caracterizado porque incluye la
etapa de configurar dichos módulos proxy o servidores de recursos
(RP) para interactuar directamente uno con otro en una relación de
interfuncionamiento.
25. Método según cualquiera de las
reivindicaciones 18 a 24, caracterizado porque incluye la
etapa de configurar dichos agentes (AA) en dicha comunidad para
ejecutar unos servicios independientes de del proveedor y de la
tecnología.
26. Método según cualquiera de las
reivindicaciones 18 a 25, caracterizado porque incluye las
etapas de proporcionar por lo menos una aplicación de gestión (MA)
para llevar a cabo las etapas seleccionadas de entre el grupo que
consiste en:
- -
- Gestionar la distribución de los procesos entre dicha capa de base y dicha capa de soporte,
- -
- Gestionar la distribución de los modelos de información entre dicha capa de base y dicha capa de soporte,
- -
- Monitorizar el estado de dichas capas en base a la información proporcionada por dichos agentes (AA) en dicha comunidad,
- -
- Interactuar con sistemas externos, y
- -
- Ejecutar procesos de gestión.
27. Método según la reivindicación 26,
caracterizado porque incluye la etapa de configurar dicha por
lo menos una aplicación de gestión (MA) como una capa superior
separada además de dicha capa de base proxy y dicha capa de
soporte.
28. Método según la reivindicación 26,
caracterizado porque incluye la etapa de integrar por lo
menos parcialmente con dicha capa de soporte (AA) dicha por lo menos
una aplicación de gestión (MA).
29. Método según cualquiera de las
reivindicaciones 18 a 28, caracterizado porque incluye la
etapa de proporcionar unos ejecutores de procesos (PE) en todas
dichas capas.
30. Método según la reivindicación 29,
caracterizado porque incluye la etapa de proporcionar en
dichos ejecutores de procesos (PE) por lo menos uno de un motor de
flujos de trabajo, un motor de reglas y una combinación de los
mismos.
31. Método según cualquiera de las
reivindicaciones 18 a 30, caracterizado porque incluye las
etapas de:
- -
- Albergar por lo menos una parte de dichos agentes (AA) en diferentes máquinas, y
- -
- Mover dichos agentes entre diferentes máquinas.
32. Método según cualquiera de las
reivindicaciones 18 a 31, caracterizado porque incluye las
etapas de:
- -
- Incluir en dichas capas (PA; RP; AA; MA) unos componentes adaptados para llevar a cabo las respectivas funciones basadas en las respectivas informaciones de instrucciones proporcionadas a las mismas;
- -
- Proporcionar una base de datos (MDB) que almacene dicha información de instrucciones, y
- -
- Distribuir dicha información de instrucciones desde dicha base de datos (MDB) a dichos componentes.
33. Método según la reivindicación 32,
caracterizado porque incluye la etapa de proporcionar en
dicha información de instrucciones por lo menos uno de:
- -
- Definiciones de procesos como por ejemplo flujos de trabajo y reglas, y
- -
- Definiciones de modelos de datos.
34. Método según la reivindicación 32,
caracterizado porque incluye las etapas de:
- -
- Proporcionar por lo menos una aplicación de gestión (MA) configurada para gestionar la distribución de los modelos de información entre dicha capa de base y dicha capa de soporte, y
- -
- Asociar dicha base de datos (MDB) a dicha por lo menos una aplicación de gestión.
35. Sistema que comprende:
- -
- Una red (N) que incluye unos equipos de red, y
- -
- Una arquitectura de un sistema de gestión según cualquiera de las reivindicaciones 1 a 17 para gestionar dicha red (N).
36. Programa informático que se puede cargar en
la memoria de por lo menos un ordenador y que incluye unas partes de
código de software para llevar a cabo las etapas del método de
cualquiera de las reivindicaciones 18 a 34.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/IT2003/000511 WO2005018249A1 (en) | 2003-08-19 | 2003-08-19 | System architecture method and computer program product for managing telecommunication networks |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2329570T3 true ES2329570T3 (es) | 2009-11-27 |
Family
ID=34179283
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES03818101T Expired - Lifetime ES2329570T3 (es) | 2003-08-19 | 2003-08-19 | Metodo relativo a la arquitectura de un sistema y programa informatico para la gestion de redes de telecomunicaciones. |
Country Status (10)
| Country | Link |
|---|---|
| US (1) | US8468228B2 (es) |
| EP (1) | EP1656800B1 (es) |
| CN (1) | CN1820514B (es) |
| AU (1) | AU2003264870A1 (es) |
| BR (2) | BR0318466A (es) |
| CA (1) | CA2535440C (es) |
| DE (1) | DE60328420D1 (es) |
| ES (1) | ES2329570T3 (es) |
| IL (1) | IL173543A (es) |
| WO (1) | WO2005018249A1 (es) |
Families Citing this family (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7797459B1 (en) * | 2003-02-11 | 2010-09-14 | At&T Intellectual Property Ii, L.P. | Access independent common architecture for real-time communications services for networking environments |
| US8705518B1 (en) * | 2003-02-24 | 2014-04-22 | At&T Intellectual Property Ii, L.P. | Apparatus and method for controlling services and operations in converged communications networks |
| US20050091093A1 (en) * | 2003-10-24 | 2005-04-28 | Inernational Business Machines Corporation | End-to-end business process solution creation |
| US7346888B1 (en) * | 2004-03-01 | 2008-03-18 | Sprint Communications Company L.P. | Use case integration |
| CN101366236B (zh) | 2005-07-06 | 2011-07-06 | 意大利电信股份公司 | 用于识别通信网络中的故障的方法和系统 |
| BRPI0520475B1 (pt) | 2005-07-29 | 2019-02-05 | Telecom Italia Spa | método e sistema para gerar sinais de instrução arranjados em fluxos de trabalho, e, meio de armazenamento legível por computador |
| CA2624483C (en) | 2005-09-30 | 2017-11-21 | Telecom Italia S.P.A. | A method and system for automatically testing performance of applications run in a distributed processing structure and corresponding computer program product |
| US10027554B2 (en) * | 2005-11-18 | 2018-07-17 | Amdocs Systems Limited | Architecture for operational support system |
| US8141125B2 (en) * | 2005-11-30 | 2012-03-20 | Oracle International Corporation | Orchestration of policy engines and format technologies |
| EP1971938A1 (en) | 2005-12-28 | 2008-09-24 | Telecom Italia S.p.A. | A method for the approximate matching of regular expressions, in particular for generating intervention workflows in a telecommunication network |
| JP5095629B2 (ja) | 2005-12-28 | 2012-12-12 | テレコム・イタリア・エッセ・ピー・アー | 特に通信ネットワーク介入用としてのワークフローモデルの自動作成方法 |
| US8725674B1 (en) * | 2006-06-30 | 2014-05-13 | At&T Intellectual Property Ii, L.P. | Method and apparatus for providing a product metadata driven operations support system |
| WO2008000290A1 (en) | 2006-06-30 | 2008-01-03 | Telecom Italia S.P.A. | Fault location in telecommunications networks using bayesian networks |
| US20100142692A1 (en) * | 2006-12-19 | 2010-06-10 | Telecom Italia S.P.A. | Method and system for providing teleassistance services based on software agents executing workflows |
| CN101557314A (zh) * | 2009-05-07 | 2009-10-14 | 中兴通讯股份有限公司 | 一种分布式网管系统及数据配置管理方法 |
| CN102402776A (zh) * | 2010-09-09 | 2012-04-04 | 姜怀臣 | 保险业视频网络培训互动平台 |
| CN102739450A (zh) * | 2012-06-29 | 2012-10-17 | 深圳市博瑞得科技有限公司 | 信令监测系统分布式平台架构及其处理方法 |
| EP3090507B1 (en) | 2013-12-30 | 2020-02-12 | Telecom Italia S.p.A. | Augmented reality for supporting intervention of a network apparatus by a human operator |
| CN104811331B (zh) * | 2014-01-29 | 2018-07-03 | 华为技术有限公司 | 一种可视化网络运维方法和装置 |
| US9389901B2 (en) | 2014-09-09 | 2016-07-12 | Vmware, Inc. | Load balancing of cloned virtual machines |
| US9871702B2 (en) * | 2016-02-17 | 2018-01-16 | CENX, Inc. | Service information model for managing a telecommunications network |
| CN106502809B (zh) * | 2016-11-08 | 2019-10-08 | 上海基连网络科技有限公司 | 一种多平台应用程序适配方法、装置及终端设备 |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5522042A (en) * | 1994-01-28 | 1996-05-28 | Cabletron Systems, Inc. | Distributed chassis agent for distributed network management |
| IE77337B1 (en) | 1995-08-15 | 1997-12-03 | Broadcom Eireann Research Limi | A communication network management system |
| JP3369445B2 (ja) * | 1997-09-22 | 2003-01-20 | 富士通株式会社 | ネットワークサービスサーバ負荷調整装置、方法および記録媒体 |
| WO2001002973A1 (en) | 1999-07-02 | 2001-01-11 | Covad Communications Group, Inc. | Process fulfillment systems and methods using distributed workflow management architecture |
| US7337209B1 (en) * | 2000-04-28 | 2008-02-26 | Sheer Networks, Inc. | Large-scale network management using distributed autonomous agents |
| WO2001084329A1 (en) * | 2000-04-28 | 2001-11-08 | Sheer Networks, Inc. | Network management method and system |
| US7225250B1 (en) * | 2000-10-30 | 2007-05-29 | Agilent Technologies, Inc. | Method and system for predictive enterprise resource management |
| US6968553B1 (en) | 2001-03-01 | 2005-11-22 | Alcatel | Element manager common gateway architecture system and method |
| US20040001449A1 (en) * | 2002-06-28 | 2004-01-01 | Rostron Andy E. | System and method for supporting automatic protection switching between multiple node pairs using common agent architecture |
| US7209963B2 (en) * | 2002-07-11 | 2007-04-24 | International Business Machines Corporation | Apparatus and method for distributed monitoring of endpoints in a management region |
-
2003
- 2003-08-19 CA CA2535440A patent/CA2535440C/en not_active Expired - Lifetime
- 2003-08-19 ES ES03818101T patent/ES2329570T3/es not_active Expired - Lifetime
- 2003-08-19 WO PCT/IT2003/000511 patent/WO2005018249A1/en not_active Ceased
- 2003-08-19 US US10/568,688 patent/US8468228B2/en not_active Expired - Fee Related
- 2003-08-19 CN CN038269244A patent/CN1820514B/zh not_active Expired - Lifetime
- 2003-08-19 BR BRPI0318466-8A patent/BR0318466A/pt active IP Right Grant
- 2003-08-19 DE DE60328420T patent/DE60328420D1/de not_active Expired - Lifetime
- 2003-08-19 EP EP03818101A patent/EP1656800B1/en not_active Expired - Lifetime
- 2003-08-19 AU AU2003264870A patent/AU2003264870A1/en not_active Abandoned
- 2003-08-19 BR BRPI0318466-8A patent/BRPI0318466B1/pt unknown
-
2006
- 2006-02-05 IL IL173543A patent/IL173543A/en active IP Right Grant
Also Published As
| Publication number | Publication date |
|---|---|
| BRPI0318466B1 (pt) | 2017-06-20 |
| AU2003264870A1 (en) | 2005-03-07 |
| DE60328420D1 (de) | 2009-08-27 |
| IL173543A0 (en) | 2006-07-05 |
| CA2535440C (en) | 2012-10-09 |
| EP1656800A1 (en) | 2006-05-17 |
| CN1820514B (zh) | 2012-03-28 |
| WO2005018249A1 (en) | 2005-02-24 |
| EP1656800B1 (en) | 2009-07-15 |
| US8468228B2 (en) | 2013-06-18 |
| IL173543A (en) | 2011-02-28 |
| CN1820514A (zh) | 2006-08-16 |
| US20060203732A1 (en) | 2006-09-14 |
| BR0318466A (pt) | 2006-09-12 |
| CA2535440A1 (en) | 2005-02-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2329570T3 (es) | Metodo relativo a la arquitectura de un sistema y programa informatico para la gestion de redes de telecomunicaciones. | |
| ES2351604T3 (es) | Procedimiento para gestionar recursos en una plataforma para gestión de servicios y/o redes de telecomunicación, plataforma correspondiente y producto de programa informático asociado. | |
| US7562132B2 (en) | Method and system for restricting and enhancing topology displays for multi-customer logical networks within a network management system | |
| US8205000B2 (en) | Network management with platform-independent protocol interface for discovery and monitoring processes | |
| ES2344318T3 (es) | Procedimiento para el despliegue, repliegue y control logicos de una red ip objetivo. | |
| US8218572B2 (en) | Network element connection management within a network management system | |
| EP2815346B1 (en) | Coordination of processes in cloud computing environments | |
| US10715457B2 (en) | Coordination of processes in cloud computing environments | |
| CN109032755A (zh) | 一种容器服务托管系统及提供容器服务的方法 | |
| ES2292689T3 (es) | Sistema y metodo de gestion para el aprovisionamiento de abonos a servicios. | |
| US20020078213A1 (en) | Method and system for management of resource leases in an application framework system | |
| US20180062945A1 (en) | Method and Entities for Service Availability Management | |
| EP3639474B1 (en) | Derivation of network service descriptor from network service requirements | |
| US6877066B2 (en) | Method and system for adaptive caching in a network management framework using skeleton caches | |
| Katker | A modeling framework for integrated distributed systems fault management | |
| Reuter et al. | System and network management itineraries for mobile agents | |
| Liotta | Towards flexible and scalable distributed monitoring with mobile agents | |
| EP3729730B1 (en) | Methods and apparatus for life cycle management in virtual networks | |
| Lewis et al. | Integrating Service and Network Management Components for Service Fulfilment | |
| Boyer et al. | Methodologies for PVC configuration in heterogeneous ATM environments using intelligent mobile agents | |
| Hoang et al. | The design of a secure, extensible, and deployable-programmable network platform | |
| Kocan et al. | The SCF: A framework for application enablement service composition | |
| Khan et al. | Towards an agent-based distributed hierarchical network management system for all-optical networks | |
| Baldin et al. | A Framework for Supporting Survivability, Network Planning and Cross-Layer Optimization in Future Multi-Domain Terabit Networks | |
| Gavalas | A lightweight and flexible mobile agent platform tailored to management applications |