ES2389806T3 - Procedimiento y dispositivos para hacer funcionar una red de gestión en caso de fallo de un gestor - Google Patents

Procedimiento y dispositivos para hacer funcionar una red de gestión en caso de fallo de un gestor Download PDF

Info

Publication number
ES2389806T3
ES2389806T3 ES05735605T ES05735605T ES2389806T3 ES 2389806 T3 ES2389806 T3 ES 2389806T3 ES 05735605 T ES05735605 T ES 05735605T ES 05735605 T ES05735605 T ES 05735605T ES 2389806 T3 ES2389806 T3 ES 2389806T3
Authority
ES
Spain
Prior art keywords
manager
nmc1
agent
subscription
omc1
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.)
Active
Application number
ES05735605T
Other languages
English (en)
Inventor
Lucian Hirsch
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Application granted granted Critical
Publication of ES2389806T3 publication Critical patent/ES2389806T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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/06—Management of faults, events, alarms or notifications
    • 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/046—Network management architectures or arrangements comprising network management agents or mobile agents therefor
    • 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/052—Network management architectures or arrangements using standardised network management architectures, e.g. telecommunication management network [TMN] or unified network management architecture [UNMA]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

Procedimiento para hacer funcionar una red de gestión con un agente (OMC1), así como un primer gestor(NMC1) y un segundo gestor (NMC2), en el que el agente (OMC1)- envía al primer gestor (NMC1) notificaciones de eventos (NOTIFICACIÓN DE EVENTOS) según unasuscripción del primer gestor (NMC1), caracterizado porque- el agente (OMC1) en caso de un defecto de funcionamiento de la comunicación entre el agente (OMC1) y elprimer gestor (NMC1) o de un defecto de funcionamiento del primer gestor (NMC1) envía un primer mensaje(notifySubscriptionDisabled) con información sobre la suscripción del primer gestor (NMC1) al segundo gestor(NMC2), y- envía al segundo gestor (NMC2) notificaciones de eventos (NOTIFICACIÓN DE EVENTOS) según lasuscripción del primer gestor (NMC1).

Description

Procedimiento y dispositivos para hacer funcionar una red de gestión en caso de fallo de un gestor
La invención se refiere a un procedimiento para hacer funcionar una red de gestión, que presenta un agente así como un primer y un segundo gestor. Además la invención se refiere a un agente y a un gestor para una red de gestión para la realización del procedimiento.
Según los principios de una red de gestión, también designados como principios TMN (TMN: red de gestión de telecomunicaciones, Telecommunications Management Network), existen varias capas de gestión para la gestión de un sistema de comunicación (como por ejemplo, de un sistema de comunicación de radiotelefonía móvil), teniendo cada capa a excepción de las capas superior e inferior una doble función, en concreto una función de gestor y una de agente. En el sistema de gestión (“managing system”) cada nivel salvo el inferior ejerce una función gestora para el nivel que se encuentra por debajo. En el sistema gestionado (“managed system”) a cada nivel salvo el superior le corresponde una función de agente para la siguiente capa superior.
Los gestores inician operaciones para la vigilancia y el control de la red, al enviar denominadas peticiones (Requests), que se realizan por agentes, y obtienen respuestas correspondientes (Responses) de los agentes. Dispositivos o elementos de la red de telecomunicación (recursos de red), que en una jerarquía TMN desempeñan el papel de un agente, reconocen eventos relevantes (events, como por ejemplo, alarmas) en la red, generan notificaciones correspondientes (notifications) y las transmiten en forma de notificaciones de eventos (Notify Events) al gestor, para posibilitar una gestión de red eficaz.
La comunicación gestor-agente tiene lugar a través de las denominadas interfaces de gestión o interfaces de gestoragente, que pueden caracterizarse en un entorno orientado a objetos por un protocolo de comunicación, como por ejemplo, CMIP (Protocolo de información de gestión común según ITU-T X.711) o CORBA (arquitectura de negociación de petición de objetos comunes), y un modelo de objeto.
Interfaces de este tipo las hay por ejemplo, entre por un lado el nivel de gestión de elemento de red (Network Element Management Level) y por otro lado del nivel de elemento de red (Network Element Level). Un ejemplo para dispositivos de red de esta interfaz de gestor-agente lo representan los centros de funcionamiento y mantenimiento (OMC: Operation and Maintenance Center) en el lado del nivel de gestión de elemento de red, así como en el lado del nivel de elemento de red dispositivos como por ejemplo, estaciones base del sistema de estaciones base (BSS: Base Station System) de una red de radiotelefonía móvil GSM, o estaciones base de otras redes de comunicación, por ejemplo, nodos B de una red de radiotelefonía móvil UMTS (UMTS: Sistema de telecomunicación móvil universal), o puntos de acceso de radio de un sistema WLAN (WLAN: red de área local inalámbrica) por ejemplo, según una de las normas IEEE 812.11.
También existen interfaces de gestión o interfaces de gestor-agente entre por un lado el nivel de gestión de red (Network Management Level) y por otro lado el nivel de gestión de elemento de red. Un ejemplo de dispositivos de red para esta interfaz de gestor-agente lo representan los centros de gestión de red (NMC: Network Management Center) en el lado del nivel de gestión de red y los centros de funcionamiento y mantenimiento (OMC: Operation and Maintenance Center) en el lado del nivel de gestión de elemento de red por ejemplo, en la mencionada red de radiotelefonía móvil GSM o en otra.
En un entorno de múltiples gestores los agentes deben poder procesar en determinadas circunstancias solicitudes que discurren en paralelo de varios gestores. Un gestor sólo puede cumplir su función de manera óptima, cuando se reciben todas las notificaciones de eventos (Notify Events) relevantes del agente de orden inferior. En condiciones normales, es decir, cuando la comunicación entre un agente y los gestores de orden superior funciona correctamente, esto sucede a través de un denominado mecanismo de notificación de eventos. Su objetivo es encaminar hacia el gestor sólo aquellas notificaciones de eventos que cumplen determinados criterios de filtro o que corresponden a la o las suscripciones del gestor respectivo.
Se produce un problema cuando falla un gestor de una red de gestión o cuando la comunicación entre un agente y un gestor es defectuosa por otros motivos. Las notificaciones de eventos que corresponden a la suscripción o las suscripciones del gestor en este caso ya no pueden transmitirse desde el agente hacia el gestor. Sin embargo, si estas notificaciones de eventos no se procesan por un gestor, entonces la gestión de red ya no puede llevar a cabo de manera óptima su función de vigilancia para el sistema en cuestión.
El documento US 2002/0174207 A1 describe un sistema de gestión jerárquico. Los gestores en un nivel se juntan en grupos. Los gestores de un grupo determinan continuamente, si alguno de ellos ya no funciona bien. Si se realiza una determinación de este tipo, se selecciona otro gestor del grupo, que asume la función del gestor que ya no funciona bien.
El documento US 2004/0085894 A1 describe un procedimiento para la detección de un fallo en una conexión de comunicación. Cuando un dispositivo determina un fallo en una conexión de comunicación, pasa al “modo de fallo” (failure mode) y desvía el tráfico de la conexión que ha fallado a una conexión que funciona.
La invención se basa en el objetivo de indicar un procedimiento para hacer funcionar una red de gestión, que en el caso fallo de un gestor posibilite un desarrollo eficaz de la gestión de red. Además debe indicarse un agente y un gestor para la realización del procedimiento.
Este objetivo se soluciona mediante un procedimiento con las características de la reivindicación 1, así como mediante un agente y un gestor con las características de las reivindicaciones independientes.
Configuraciones y perfeccionamientos ventajosos son objeto de las reivindicaciones dependientes.
En el caso del procedimiento según la invención para hacer funcionar una red de gestión con un agente, así como un primer y un segundo gestor el agente envía al primer gestor notificaciones de eventos según una suscripción del primer gestor. En el caso de un defecto de funcionamiento de la comunicación entre el agente y el primer gestor o de un defecto de funcionamiento del primer gestor el agente envía un primer mensaje con información sobre la suscripción del primer gestor al segundo gestor. El agente envía además al segundo gestor notificaciones de eventos según la suscripción del primer gestor.
Además del agente, del primer y del segundo gestor otros elementos de red de gestión pueden formar parte de la red de gestión. Las funciones de la red de gestión pueden encontrarse por ejemplo, en la gestión de errores (faultmanagement) y/o en la gestión de configuración (configuration-management) y/o en la gestión de seguridad (security-management) y/o en la gestión de contabilidad (accounting-management) y/o en la gestión de rendimiento (performance-management).
El agente envía, debido a la aparición de determinados eventos, notificaciones de eventos al gestor. Una suscripción de un gestor define a este respecto determinadas notificaciones de eventos, que desea recibir el respectivo gestor del agente. Esto puede realizarse utilizando funciones de filtro adecuadas en el agente. El agente puede reconocer un defecto de funcionamiento o bien de la comunicación entre el agente y el primer gestor o bien un defecto de funcionamiento del primer gestor, pudiendo producirse este reconocimiento por ejemplo, por la llegada o en particular por la no llegada de determinados mensajes del primer gestor al agente. A continuación del reconocimiento de los defectos de funcionamiento se envían notificaciones de eventos según la suscripción del primer gestor al segundo gestor, de modo que al segundo gestor se le habilita para funcionar como sustitución del primer gestor. El segundo gestor puede haberse previsto en particular para asumir la tarea del primer gestor de antemano. Es ventajoso que el hecho de habilitar al segundo gestor para la sustitución del primer gestor tenga lugar sin acción de operadores, es decir, sin que se requiera personal que reaccione al fallo del primer gestor.
El procedimiento puede llevarse a cabo con respecto a una, varias o todas las suscripciones del primer gestor en el agente. Esto afecta también a las configuraciones y los perfeccionamientos descritos a continuación.
En el perfeccionamiento de la invención el agente recibe tras el envío del primer mensaje del segundo gestor un segundo mensaje para solicitar notificaciones de eventos según la suscripción del primer gestor. De este modo debido a la recepción del primer mensaje se solicita directamente al agente del segundo gestor que envíe notificaciones de eventos según la suscripción del primer gestor, de modo que el agente dado el caso pueda realizar ajustes, para posibilitar el envío de las notificaciones de eventos según la suscripción del primer gestor al segundo gestor.
Es ventajoso que el primer mensaje comprenda lo siguiente: información de identificación del primer gestor, información de identificación de la suscripción del primer gestor, así como información sobre notificaciones de eventos que deben enviarse según la suscripción del primer gestor. El último punto puede realizarse por ejemplo mediante una descripción de un filtro empleado por el agente para la suscripción del primer gestor.
En un perfeccionamiento de la invención el agente, en caso de finalizar el defecto de funcionamiento de la comunicación entre el agente y el primer gestor o de finalizar el defecto de funcionamiento del primer gestor, envía un tercer mensaje para informar sobre la finalización del defecto de funcionamiento al segundo gestor. Además el agente finaliza el envío de notificaciones de eventos según la suscripción del primer gestor al segundo gestor, y retoma el envío de notificaciones de eventos según la suscripción del primer gestor al primer gestor. De manera ventajosa el agente recibe tras el envío del tercer mensaje del segundo gestor un cuarto mensaje para solicitar la finalización del envío de notificaciones de eventos según la suscripción del primer gestor. Provocado por esta solicitud directa, dado el caso, el agente puede modificar los ajustes, de modo que como resultado de este procesamiento pueda ajustarse el envío de las notificaciones de eventos según la o las suscripciones del primer gestor al segundo gestor. La finalización del defecto de funcionamiento puede reconocerse por el agente por ejemplo, mediante la no llegada o la presencia de determinados mensajes, como por ejemplo, solicitud de comunicación, del primer gestor. El agente informa a continuación al segundo gestor, que puede realizar la función de sustitución del primer gestor debido a las notificaciones de eventos enviadas al mismo, tras lo cual el segundo gestor puede solicitar al agente que deje de enviarle notificaciones de eventos según la o las suscripciones del primer gestor.
En una configuración de la invención el agente antes de la aparición del defecto de funcionamiento ha almacenado información de identificación del segundo gestor como gestor asignado al primer gestor con respecto a defectos de funcionamiento. Así un agente puede haber almacenado por ejemplo una tabla que contenga una asignación de en cada caso dos gestores entre sí. A cada gestor, al que el agente envía notificaciones de eventos, puede asignarse de esta manera un gestor de reserva o de repuesto o de sustitución.
El agente según la invención para una red gestión presenta medios para enviar notificaciones de eventos a un primer gestor según una suscripción del primer gestor, así como medios para determinar un defecto de funcionamiento de la comunicación entre el agente y el primer gestor o un defecto de funcionamiento del primer gestor, y medios para enviar un mensaje con información sobre la suscripción del primer gestor a un segundo gestor en caso de un defecto de funcionamiento.
El gestor según la invención para una red de gestión presenta medios para recibir un mensaje de un agente con información sobre una suscripción de otro gestor, así como medios para recibir notificaciones de eventos según la suscripción del otro gestor del agente.
Tanto el agente según la invención como el gestor según la invención son apropiados en particular para llevar a cabo el procedimiento según la invención, siendo aplicable esto también a la configuración y el perfeccionamiento. Para ello pueden presentar medios adecuados adicionales.
A continuación se ilustra la invención más en detalle por medio de un ejemplo de realización. A este respecto muestran:
la figura 1: un fragmento de una red de gestión,
la figura 2: un diagrama de flujo del procedimiento según la invención,
la figura 3: esquemáticamente la construcción de un agente según la invención,
la figura 4: esquemáticamente la construcción de un gestor según la invención.
La figura 1 muestra un fragmento de una red de gestión de un sistema de telecomunicación como por ejemplo, de un sistema de comunicación de radiotelefonía móvil. La capa de gestión de red GESTOR como la superior de las dos capas representadas se compone de los dos gestores NMC1 y NMC2 (NMC: centro de red de gestión). La capa de gestión de elemento de red AGENTE como la inferior de las dos capas representadas se compone de los dos agentes OMC1 y OMC2 (OMC: centro de operación y mantenimiento). La invención se ilustra a continuación por medio de la interfaz representada en la figura 1 entre la capa de gestión de red y la capa de gestión de elemento de red.
No obstante puede aplicarse a cualquier otra interfaz de gestor-agente, así por ejemplo, a la interfaz entre la capa de gestión de elemento de red y la capa de elemento de red que se encuentra más abajo, no representada en la figura
1. La red de gestión puede contener una pluralidad de gestores y agentes adicionales, cuya presencia no es sin embargo relevante para la comprensión de la invención.
Los gestores NMC1 y NMC2 se han “abonado” en los agentes OMC1 y OMC2 a las notificaciones de eventos relevantes para ellos o están suscritos a éstas. Esto significa que el respectivo gestor ha enviado una solicitud al respectivo agente, lo que tiene como consecuencia la generación de un mecanismo de filtro. Un mecanismo de filtro provoca que de la pluralidad de notificaciones de eventos sólo lleguen a un gestor las que corresponden a la o a las suscripciones de este gestor, de modo que un gestor pueda controlar el flujo de información procedente del agente según sus requisitos individuales. Un filtro de este tipo puede generarse por ejemplo en una interfaz de gestión basada en CORBA con ayuda del denominado “servicio de notificación” según la “Notification Service Specification V1.0.1” de OMG (OMG: grupo de gestión de objetos), o en una interfaz de gestión basada en CMIP con ayuda de “discriminadores de envío de eventos” (Event Forwarding Discriminators) según la norma ITU-T X.734 “Systems Management: Notify Event Management Function”.
La interfaz representada en la figura 1 entre capa de gestión de red y capa de gestión de elemento de red es un ejemplo de una configuración de múltiples gestores. Varios NMC pueden estar conectados a un OMC, asumiendo cada NMC un objetivo de gestión específico. En la figura 1 (simbolizado en cada caso por una línea entre los elementos de la red de gestión) el gestor NMC1 está conectado al agente OMC1, mientras que el gestor NMC2 está conectado a los dos agentes OMC1 y OMC2. Esto significa que el gestor NMC1 recibe notificaciones de eventos del agente OMC1, y el gestor NMC2 de los dos OMC1 y OMC2. Puesto que existen varios gestores NMC1 y NMC2, los dos gestores NMC1 y NMC2 deben evaluar por regla general en cada caso sólo un subconjunto de las notificaciones de eventos generadas por los agentes OMC1 y OMC2, de modo que para la comunicación entre los agentes OMC1 y OMC2 y los gestores NMC1 y NMC2 existen filtros correspondientes.
Para este fin la norma de 3GPP TS 32.302 (“Notification Integration Reference Point (IRP): Information Service”) define un denominado mecanismo de suscripción, con el que un gestor puede comunicar a un agente indicaciones precisas sobre el tipo y los valores de parámetros de las notificaciones relevantes para él. El mecanismo de suscripción puede utilizarse independientemente del protocolo de comunicación empleado para la comunicación entre gestor y agente. Para iniciar la suscripción un gestor envía a un agente una solicitud de suscripción con su información de identificación, la denominada “managerReference”. El agente responde con información de identificación de la suscripción, el denominado valor “subscriptionId”, que debe emplearse para las operaciones de gestor adicionales con respecto a esta suscripción. Un gestor puede enviar varias veces solicitudes de suscripción a un agente, por ejemplo, para distintos tipos de notificaciones de eventos, tras lo cual el agente en cada solicitud de suscripción adjudica un nuevo valor inequívoco de “subscriptionId”.
A continuación de la recepción de la información de identificación de la suscripción el gestor mediante el envío de mensajes adecuados realizados a continuación haciendo referencia al valor “subscriptionId” puede ordenar distintas operaciones con respecto a esta suscripción:
“unsubscribe”: el agente finaliza a continuación por medio del carácter de identificación “managerReference”la suscripción existente.
“getSubscriptionIds”: con esto el gestor solicita por medio del carácter de identificación “managerReference” todos los valores “subscriptionId” adjudicados al mismo por el agente.
“getSubscriptionStatus”: el gestor recibe a continuación con respecto a la respectiva suscripción información sobre el tipo de notificaciones de eventos y el filtro actual.
“changeSubscriptionFilter”: el gestor puede modificar la estructura de filtro de la suscripción.
“suspendSubscription”: una suscripción se interrumpe temporalmente, es decir, el gestor no recibe durante un periodo de tiempo ninguna notificación de eventos según esta suscripción.
“resumeSubscription”: una suscripción interrumpida anteriormente se reactiva, es decir, el gestor recibe de nuevo notificaciones de eventos según esta suscripción.
Las solicitudes de gestor descritas contienen en cada caso información de identificación de la suscripción, es decir, el valor “subscriptionId”, e información de identificación del gestor, es decir, el carácter de identificación “managerReference”. Por tanto las operaciones descritas pueden ordenarse sólo por el gestor, que ha iniciado la suscripción y conoce por tanto también el valor “subscriptionId”.
A continuación se observa el caso en que el gestor NMC1 no puede realizar su función de vigilancia temporalmente, de modo que la comunicación entre el gestor NMC1 y el agente OMC1 está defectuosa. Esto puede estar condicionado por el fallo del gestor NMC1 en sí o por un fallo de la comunicación entre el gestor NMC1 y el agente OMC1. Según el estado de la técnica en este caso el personal del gestor NMC1 puede contactar por ejemplo, por teléfono con el personal de otro gestor. La información relevante para las suscripciones del gestor NMC1 se comunica al personal del otro gestor, de modo que el otro gestor mediante entradas correspondientes del personal puede llegar a sustituir al gestor NMC1 que ha fallado. Este modo de proceder tiene la desventaja de que mediante la complicada transmisión de información se pierde un tiempo, durante el cual dado el caso no puede procesarse una pluralidad de notificaciones de eventos según la suscripción del gestor NMC1. Además se requiere la presencia de personal in situ del gestor NMC1 y de otro gestor, para poder realizar un reemplazo temporal del gestor NMC1 que ha fallado.
Según la invención el agente OMC1 ha almacenado para el caso de fallo del gestor NMC1 información de identificación del gestor NMC2, que durante el defecto de funcionamiento de la comunicación entre el gestor NMC1 y el agente OMC1 debe realizar la función de gestor del gestor NMC1 en sustitución de éste. El gestor NMC2 hace por tanto de “gestor de reserva” con respecto al gestor NMC1. Si un agente envía notificaciones de eventos a una pluralidad de gestores, presenta una tabla, en la que a cada uno de estos gestores está asignado un gestor de reserva. El almacenamiento tiene lugar preferiblemente a través de un fichero de datos configurable por el operador de la red de gestión, de modo que puede modificarse el gestor de reserva asignado a un gestor. Un gestor puede estar asignado a varios otros gestores como gestor de reserva. Distintos agentes también pueden haber almacenado distintos gestores de reserva con respecto a un gestor.
La figura 2 muestra el desarrollo del procedimiento según la invención. El gestor NMC1 ha iniciado en el agenteOMC1 una suscripción y según esta suscripción recibe notificaciones de eventos NOTIFICACIÓN DE EVENTOS. El agente OMC1 empleando procedimientos en sí conocidos, determina que la comunicación entre el agente OMC1 y el gestor NMC1 es defectuosa, simbolizado por una flecha doble interrumpida por un rayo. Automáticamente, es decir, sin que se pida, el agente OMC1 tras determinar el defecto de funcionamiento envía un mensaje notifySubscriptionDisabled al gestor NMC2, cuyo carácter de identificación “managerReference” ha almacenado como gestor de reserva para el gestor NMC1. El mensaje notifySubscriptionDisabled contiene la siguiente información: el carácter de identificación “managerReference” del gestor NMC1, el valor “subscriptionId”como información de identificación inequívoca de la suscripción del gestor NMC1, un parámetro “notificationCategorySet”,que indica, qué tipos de notificaciones de eventos NOTIFICACIÓN DE EVENTOS debería recibir el gestor NMC1 según su suscripción, una magnitud “filter”, que define la estructura de filtro para las notificaciones de eventos NOTIFICACIÓN DE EVENTOS relacionadas con el parámetro “notificationCategorySet”, una magnitud “subscriptionState”, que indica, si la suscripción en este momento estaba interrumpida (suspended) por el gestor NMC1 o se había empleado (running). Si existen varias suscripciones del gestor NMC1 en el agente OMC1, en el mensaje notifySubscriptionDisabled se comunican el valor “subscriptionId”, “notificationCategorySet”, “filter”, y “subscriptionstate” para cada una de las suscripciones.
Tras la recepción del mensaje notifySubscriptionDisabled el gestor NMC2 envía al agente OMC1 un mensaje subscribe-Request, que solicita al agente OMC1 que configure todas las suscripciones del gestor NMC1 no interrumpidas en este momento para el gestor NMC2. El mensaje subscribe-Request puede referirse a todas las suscripciones existentes del gestor NMC1. Sin embargo también es posible, que por suscripción se envíe un mensaje propio subscribe-Request. El mensaje subscribe-Request contiene las magnitudes “managerReference”del gestor NMC2, “notificationCategorySet”y“filter” para las respectivas suscripciones. Por tanto se garantiza que parala gestión de red no se pierdan notificaciones relevantes. Es más, las notificaciones de eventos NOTIFICACIÓN DE EVENTOS según la o las suscripciones del gestor NMC1 se envían desde el agente OMC1 al gestor NMC2. Por ello el gestor NMC2 puede asumir las tareas del gestor NMC1 que ha fallado.
Si el defecto de funcionamiento de la comunicación entre el agente OMC1 y el gestor NMC1 ha finalizado, simbolizado en la figura 2 mediante una flecha doble interrumpida por un “OK”, el agente OMC1 envía sin pedírselo un mensaje notifySubscriptionEnabled con referencia a la información de identificación del gestor NMC1 al gestor NMC2, con el que se comunica al gestor NMC2, que el gestor NMC1 al que sustituye vuelve a estar en servicio. A continuación el gestor NMC2 envía un mensaje unsubscribe-Request al agente OMC1, que comprende la “managerReference” del gestor NMC2, así como “notificationCategorySet”y“filter” para las respectivas suscripciones. Como en el caso del mensaje subscribe-Request puede emplearse un único mensaje unsubscribe-Request o un mensaje propio unsubscribe-Request para cada suscripción del gestor NMC1.
A continuación se envían de nuevo notificaciones de eventos NOTIFICACIÓN DE EVENTOS del agente OMC1 según la suscripción del gestor NMC1 al gestor NMC1.
Es ventajoso en el procedimiento descrito, que el gestor NMC2 automáticamente, es decir, en particular sin requerir intervención humana, pueda asumir las tareas del gestor NMC1 inactivo. El procedimiento descrito puede aplicarse a las redes de telecomunicación más diversas. Es independiente del protocolo de comunicación utilizado para la interfaz de gestor-agente.
La figura 3 muestra esquemáticamente la construcción del agente OMC1. Éste presenta los medios MEDIOS DEGESTOR DE NOTIFICACIÓN DE EVENTOS y MEDIOS DE GESTOR DE RESERVA DE NOTIFICACIÓN DE EVENTOS para el envío de notificaciones de eventos a un gestor o a un gestor de reserva según una suscripción del gestor. Con los medios DETECTAR ERROR/RECUPERAR el agente OMC1 puede determinar, que ha aparecido
o se ha subsanado un defecto de funcionamiento de la comunicación entre el agente OMC1 y un gestor. Provocado por la determinación de un defecto de funcionamiento empleando los medios TRANSMITIR notifySubscriptionDisabled se crea un mensaje notifySubscriptionDisabled descrito anteriormente y se envía a un gestor de reserva, cuya información de identificación está almacenada en la memoria MEMORIA DE GESTOR DE RESERVA. Si el agente OMC1 determina con los medios DETECTAR ERROR/RECUPERAR, que una comunicación entre el agente OMC1 y un gestor defectuosa anteriormente vuelve a ser correcta, empleando los medios TRANSMITIR notifySubscriptionEnabled se crea un mensaje notifySubscriptionEnabled descrito anteriormente y se envía al gestor de reserva, cuya información de identificación está almacenada en la memoria MEMORIA DE GESTOR DE RESERVA. La recepción de un mensaje subscribe-Request explicado anteriormente del gestor de reserva con los medios RECIBIR subscribe-Request GESTOR DE RESERVA activa los medios MEDIOS DE GESTOR DE RESERVA DE NOTIFICACIÓN DE EVENTOS para enviar notificaciones de eventos al gestor de reserva según la suscripción del gestor, mientras que la recepción de un mensaje unsubscribe-Request explicado anteriormente del gestor de reserva con los medios RECIBIR unsubscribe-Request GESTOR DE RESERVA ordena a los medios MEDIOS DE GESTOR DE RESERVA DE NOTIFICACIÓN DE EVENTOS que ya no envíe más notificaciones de eventos según la suscripción del gestor al gestor de reserva, sino al gestor.
La construcción del gestor NMC2 está representada esquemáticamente en la figura 4. Con los medios MEDIOS DEAGENTE DE NOTIFICACIÓN DE EVENTOS el gestor NMC2 recibe y procesa notificaciones de eventos recibidas por agentes. Provocado por la recepción de un mensaje notifySubscriptionDisabled explicado anteriormente con los medios RECIBIR notifySubscriptionDisabled con los medios TRANSMITIR subscribe-Request se crea un mensaje subscribe-Request descrito anteriormente y se envía al agente, que recibió el mensaje notifySubscriptionDisabled. Provocado por la recepción de un mensaje notifySubscriptionEnabled explicado anteriormente con los medios RECIBIR notifySubscriptionEnabled con los medios TRANSMITIR unsubscribeRequest se crea un mensaje unsubscribe-Request descrito anteriormente y se envía al agente, que recibió el mensaje notifySubscriptionDisabled.

Claims (9)

  1. REIVINDICACIONES
    1. Procedimiento para hacer funcionar una red de gestión con un agente (OMC1), así como un primer gestor (NMC1) y un segundo gestor (NMC2), en el que el agente (OMC1)
    -
    envía al primer gestor (NMC1) notificaciones de eventos (NOTIFICACIÓN DE EVENTOS) según una suscripción del primer gestor (NMC1), caracterizado porque
    -
    el agente (OMC1) en caso de un defecto de funcionamiento de la comunicación entre el agente (OMC1) y el primer gestor (NMC1) o de un defecto de funcionamiento del primer gestor (NMC1) envía un primer mensaje (notifySubscriptionDisabled) con información sobre la suscripción del primer gestor (NMC1) al segundo gestor (NMC2), y
    -
    envía al segundo gestor (NMC2) notificaciones de eventos (NOTIFICACIÓN DE EVENTOS) según la suscripción del primer gestor (NMC1).
  2. 2.
    Procedimiento según la reivindicación 1, en el que el agente (OMC1) tras el envío del primer mensaje (notifySubscriptionDisabled) recibe desde el segundo gestor (NMC2) un segundo mensaje (subscribe-Request)para solicitar notificaciones de eventos (NOTIFICACIÓN DE EVENTOS) según la suscripción del primer gestor (NMC1).
  3. 3.
    Procedimiento según la reivindicación 1 ó 2, en el que el primer mensaje (notifySubscriptionDisabled) comprende:
    -
    información de identificación del primer gestor (NMC1),
    -
    información de identificación de la suscripción del primer gestor (NMC1), e
    -
    información sobre notificaciones de eventos (NOTIFICACIÓN DE EVENTOS) que deben enviarse según la suscripción del primer gestor (NMC1).
  4. 4. Procedimiento según una de las reivindicaciones 1 a 3, en el que el agente (OMC1) en caso de finalizar el defecto de funcionamiento de la comunicación entre el agente (OMC1) y el primer gestor (NMC1) o de finalizar el defecto de funcionamiento del primer gestor (NMC1)
    -
    envía un tercer mensaje (notifySubscriptionEnabled) para informar sobre la finalización del defecto de funcionamiento al segundo gestor (NMC2),
    -
    finaliza el envío de notificaciones de eventos (NOTIFICACIÓN DE EVENTOS) según la suscripción del primer gestor (NMC1) al segundo gestor (NMC2), y
    -
    retoma el envío de notificaciones de eventos (NOTIFICACIÓN DE EVENTOS) según la suscripción del primer gestor (NMC1) al primer gestor (NMC1).
  5. 5.
    Procedimiento según la reivindicación 4, en el que el agente (OMC1) tras el envío del tercer mensaje (notifySubscriptionEnabled) recibe desde el segundo gestor (NMC2) un cuarto mensaje (unsubscribe-Request)para solicitar la finalización del envío de notificaciones de eventos (NOTIFICACIÓN DE EVENTOS) según la suscripción del primer gestor (NMC1).
  6. 6.
    Procedimiento según una de las reivindicaciones 1 a 5, en el que el agente (OMC1) antes de la aparición del defecto de funcionamiento ha almacenado información de identificación del segundo gestor (NMC2) como gestor asignado al primer gestor (NMC1) con respecto a defectos de funcionamiento.
  7. 7.
    Agente (OMC1) para una red de gestión, con
    -
    medios (MEDIOS DE GESTOR DE NOTIFICACIÓN DE EVENTOS) para enviar notificaciones de eventos(NOTIFICACIÓN DE EVENTOS) a un primer gestor (NMC1) según una suscripción del primer gestor (NMC1),
    -
    medios (DETECTAR ERROR/RECUPERAR) para determinar un defecto de funcionamiento de la comunicación entre el agente (OMC1) y el primer gestor (NMC1) o un defecto de funcionamiento del primer gestor (NMC1), caracterizado por
    -
    medios (TRANSMITIR notifySubscriptionDisabled) para enviar un mensaje (notifySubscriptionDisabled) con información sobre la suscripción del primer gestor (NMC1) a un segundo gestor (NMC2) en el caso de un defecto de funcionamiento.
  8. 8.
    Agente (OMC1) según la reivindicación 7 con
    -medios (DETECTAR ERROR/RECUPERAR) para determinar la finalización de un defecto de funcionamiento
    de la comunicación entre el agente (OMC1) y el primer gestor (NMC1) o de un defecto de funcionamiento del
    5
    primer gestor (NMC1),
    -medios (TRANSMITIR notifySubscriptionEnabled) para enviar un mensaje (notifySubscriptionEnabled)para
    informar sobre la finalización de un defecto de funcionamiento al segundo gestor (NMC2) en caso de finalizar un
    defecto de funcionamiento.
    10
  9. 9.
    Gestor (NMC2) para una red de gestión, caracterizado por
    -medios (RECIBIR notifySubscriptionDisabled) para recibir un mensaje (notifySubscriptionDisabled) desde un
    agente (OMC1) con información sobre una suscripción de otro gestor (NMC1),
    15
    -medios (MEDIOS DE AGENTE DE NOTIFICACIÓN DE EVENTOS) para recibir notificaciones de eventos(NOTIFICACIÓN DE EVENTOS) según la suscripción del otro gestor (NMC1) desde el agente (OMC1).
ES05735605T 2004-05-18 2005-04-20 Procedimiento y dispositivos para hacer funcionar una red de gestión en caso de fallo de un gestor Active ES2389806T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP04011811 2004-05-18
EP04011811A EP1598979A1 (de) 2004-05-18 2004-05-18 Verfahren und Einrichtungen zum Betreiben eines Managementnetzes bei Ausfall eines Managers
PCT/EP2005/051747 WO2005114908A1 (de) 2004-05-18 2005-04-20 Verfahren und einrichtungen zum betreiben eines managementnetzes bei ausfall eines managers

Publications (1)

Publication Number Publication Date
ES2389806T3 true ES2389806T3 (es) 2012-10-31

Family

ID=34925046

Family Applications (1)

Application Number Title Priority Date Filing Date
ES05735605T Active ES2389806T3 (es) 2004-05-18 2005-04-20 Procedimiento y dispositivos para hacer funcionar una red de gestión en caso de fallo de un gestor

Country Status (7)

Country Link
EP (2) EP1598979A1 (es)
KR (1) KR101146836B1 (es)
CN (2) CN1954550A (es)
ES (1) ES2389806T3 (es)
MX (1) MXPA06013446A (es)
PL (1) PL1749369T3 (es)
WO (1) WO2005114908A1 (es)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006036566B4 (de) * 2006-08-04 2009-02-19 Nokia Siemens Networks Gmbh & Co.Kg Vorabinformation von Managern über die Itf-N Schnittstelle

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE510485C2 (sv) * 1997-02-24 1999-05-25 Ericsson Telefon Ab L M En anordning, ett system och ett förfarande avseende hanteringskommunikation
US6094416A (en) * 1997-05-09 2000-07-25 I/O Control Corporation Multi-tier architecture for control network
EP1323040A4 (en) * 2000-09-08 2005-08-03 Goahead Software Inc SYSTEM AND METHOD FOR MANAGING CLUSTERS WITH MULTIPLE NODES
US7013084B2 (en) * 2001-02-28 2006-03-14 Lambda Opticalsystems Corporation Multi-tiered control architecture for adaptive optical networks, and methods and apparatus therefor
US7260066B2 (en) * 2002-10-31 2007-08-21 Conexant Systems, Inc. Apparatus for link failure detection on high availability Ethernet backplane

Also Published As

Publication number Publication date
CN102594593A (zh) 2012-07-18
WO2005114908A1 (de) 2005-12-01
KR20070012686A (ko) 2007-01-26
PL1749369T3 (pl) 2012-11-30
CN1954550A (zh) 2007-04-25
EP1749369A1 (de) 2007-02-07
EP1749369B1 (de) 2012-06-06
MXPA06013446A (es) 2007-03-01
KR101146836B1 (ko) 2012-05-21
EP1598979A1 (de) 2005-11-23

Similar Documents

Publication Publication Date Title
US8726068B2 (en) Intra-realm AAA fallback mechanism
ES2411909T3 (es) Método, dispositivo elemento de red y sistema de red para establecer la conexión entre una estación de mantenimiento y una estación base
EP2866378A1 (en) Apparatus and method for protecting and switching packet transport network
CN102315961A (zh) 执行路径导向的***管理
ES2341353T3 (es) Procedimento y productos para la alineacion de informaciones entre gestor y agente en una red de gestion.
JP4560506B2 (ja) コールサーバの障害に対して保護を与えるクラスタ形成コールサーバ
BR102019008266A2 (pt) método para arquiteturas de redes de comunicação sem fio de aviônica, e, sistema para arquiteturas de comunicação aviônica sem fio
US7822872B2 (en) Multi-location distributed workplace network
CN109120446A (zh) 一种零配置启动方法及设备
ES2389806T3 (es) Procedimiento y dispositivos para hacer funcionar una red de gestión en caso de fallo de un gestor
US20030145037A1 (en) Network management system using sms
WO2020192938A1 (en) Network entity and method for supporting network fault detection
CN102457868A (zh) 在通信***中报告
ES2293547T3 (es) Procedimiento y equipos para la distribucion de informaciones de gestion en una red de gestion de un sistema de comunicaciones.
EP3069474A1 (en) Correlation of event reports
JP4673532B2 (ja) マルチマネージャ環境における包括アライメントプロセス
CN215956666U (zh) 5g组网***
ES2808918T3 (es) Método para rendimiento mejorado de una red de telecomunicaciones que comprende al menos un grupo de entidades de gestión de la movilidad agrupadas, red de telecomunicaciones, agrupación de entidades de gestión de la movilidad, programa y producto de programa informático
ES2286046T3 (es) Procedimiento para la transmision asegurada de mensajes de alarma desde un elemento de red hasta un sistema de gestion de la red.
WO2020166425A1 (ja) ネットワーク装置、ネットワークシステム、ネットワーク接続方法、およびプログラム
ES2259175T3 (es) Procedimiento para el tratamiento de alarmas mediante una red de gestion con varios niveles en un sistema de comunicaciones.
ES2351892T3 (es) Procedimiento y sistema de comunicación para el tratamiento de informaciones de estado mediante una red de gestión que presenta varios niveles de gestión.
ES2291781T3 (es) Procedimiento y equipos para cambiar el modo de funcionamiento de un agente de una red de gestion.
CN110024423B (zh) 一种错误指示的处理方法、设备及***
EP2028893A1 (en) Proxy network element and method of performance management in a network