PROCEDIMIENTO Y DISPOSITIVOS PARA EL FUNCIONAMIENTO DE UNA RED DE GESTIÓN EN CASO DE AVERÍA DE ÜN GESTOR.
CAMPO DE LA INVENCIÓN La invención se refiere a un procedimiento para el funcionamiento de una red de gestión, que presenta un agente así como un primer y un segundo gestor. La invención se refiere además a un agente y a un gestor para una red de gestión para la realización del procedimiento.
ANTECEDENTES DE LA INVENCIÓN Según los principios de una red de gestión, también denominados principios TMN (TMN: "Telecommunications Management Network, red de gestión de telecomunicación) , existen varias capas de gestión para la gestión de un sistema de comunicaciones, tal como por ejemplo un sistema de telecomunicaciones de radiotelefonía móvil, en las que cada capa, a excepción de la más superior y la más inferior, tiene una función doble, más concretamente una función de gestor y una de agente. En el sistema gestor ( "managing system" ) cada nivel salvo el más inferior desempeña una función de gestor para el nivel que se encuentra por debajo. En el sistema gestionado ("managed system") cada nivel excepto el más superior recibe una función de agente para la capa inmediatamente superior. Los gestores inician operaciones de supervisión y control de la red enviando unas denominadas peticiones, que se llevan a cabo por agentes, y reciben las notificaciones de respuesta correspondientes ("responses") de los agentes. Los dispositivos o elementos de la red de telecomunicaciones (recursos de red) , que desempeñan el papel de un agente en una jerarquía TMN, reconocen los eventos relevantes ("events", tales como por ejemplo alarmas) en la red, generan las notificaciones ("notifications") correspondientes y las transmiten en forma de notificaciones de evento ("Notify events") al gestor para permitir una gestión de red eficiente. La comunicación gestor-agente se produce a través de denominadas interfaces de gestión o interfaces de gestión-agente, que pueden caracterizarse en un entorno orientado a objetos por un protocolo de comunicación, tal como, por ejemplo, CMIP ("Common Management Information Protocol", protocolo de información de gestión común, según ITU-T X.711) o CORBA ("Common Object Request Broker Architecture" , arquitectura común de intermediario de petición de objeto) y por un modelo de objeto. Tales interfaces existen por ejemplo entre, por un lado, el nivel de gestión del elemento de red ("Network Element Management Level") y, por otro lado, el nivel del elemento de red ("Network Element Level"). Los centros de funcionamiento y mantenimiento (OMC: "Operation and Maintenance Center") representan un ejemplo de dispositivos de red de esta interfaz de gestor-agente en el lado del nivel de gestión del elemento de red, así como en el lado del nivel del elemento de red los dispositivos tales como, por ejemplo, las estaciones base del sistema de estaciones base (BSS: "Base Station System") de una red de radiotelefonía móvil GSM, o las estaciones base de otras redes de comunicación, por ejemplo el Nodo B de una red de radiotelefonía móvil UMTS (UMTS: "Universal Mobile Telecommunication System", sistema de telecomunicaciones móviles universal) , o los puntos de acceso de radio de un sistema LAN ( LAN: "Wireless Local Área Network" , red de área local inalámbrica) , por ejemplo según uno de los estándares IEEE 812.11. Las interfaces de gestión o interfaces de gestor-agente existen también entre, por un lado, el nivel de gestión de red ("Network Management Level") y, por otro lado, el nivel de gestión del elemento de red. 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 del elemento de red representan un ejemplo de dispositivos de red para esta interfaz de gestor-agente, por ejemplo en el GSM mencionado o en otra red de radiotelefonía móvil . En un entorno de múltiples gestores, los agentes deben estar preparados para procesar, en caso necesario, peticiones que se den en paralelo de varios gestores. Un gestor puede cumplir su función de manera óptima sólo si todas las notificaciones de evento ("notify events") relevantes se reciben por los agentes de orden inferior. En condiciones normales, es decir cuando la comunicación entre un agente y el gestor de orden superior funciona correctamente, esto se produce a través de un denominado mecanismo de información de eventos ( "Event-Reporting- Mechanismus" ) . Su objetivo es encaminar al gestor sólo aquellas notificaciones de evento que cumplan criterios de filtrado determinados o que corresponden a las suscripciones del gestor respectivo. Un problema surge cuando un gestor de una red de gestión se avería o cuando la comunicación entre un agente y un gestor falla por otros motivos. Las notificaciones de evento que corresponden a la o las suscripciones del gestor pueden no transmitirse en este caso desde el agente al gestor. Sin embargo, si estas notificaciones de evento no se procesan por un gestor, así la red de gestión puede no llevar a cabo de manera óptima su función de supervisión para el sistema en cuestión. La invención se basa en el objetivo de mostrar un procedimiento para el funcionamiento de una red de gestión que, en caso de avería de un gestor, permite un desarrollo eficiente de la gestión de la red. Además se mostrarán 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 de patente, así como mediante un agente y un gestor con las características de las reivindicaciones secundarias de patente . Las configuraciones y perfeccionamientos ventajosos son objeto de las reivindicaciones dependientes. En el procedimiento según la invención para el funcionamiento de una red de gestión con un agente, así como con un primer y un segundo gestor, el agente envía al primer gestor notificaciones de evento conforme a una suscripción del primer gestor. En el caso de un fallo de la comunicación entre el agente y el primer gestor o de un fallo 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 evento conforme a la suscripción del primer gestor. Junto con el agente, el primer y el segundo gestor pueden formar parte de la red de gestión otros elementos de red de gestión. Las funciones de la red de gestión pueden encontrarse por ejemplo en la gestión de errores ("fault-management") 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 facturación ( "accounting-management" ) y/o en la gestión de rendimiento ("performance-management") . El agente envía, con motivo de la aparición de un evento determinado, notificaciones de evento al gestor. Una suscripción de un gestor define en el este caso las notificaciones de evento determinados que desea recibir el gestor respectivo del agente. Esto puede realizarse mediante la utilización de funciones de filtrado adecuadas en el agente. El agente puede reconocer un fallo o bien de la comunicación entre el agente y el primer gestor o bien un fallo del primer gestor, pudiendo originarse este reconocimiento por ejemplo mediante la llegada o especialmente mediante la ausencia de determinados mensajes desde el primer gestor al agente. A continuación del reconocimiento de los fallos se envían notificaciones de evento conforme a la suscripción del primer gestor al segundo gestor, de modo que se habilita al segundo gestor para funcionar como sustituto del primer gestor. El segundo gestor puede estar previsto de antemano especialmente para asumir la tarea del primer gestor. Es ventajoso que la habilitación del segundo gestor para sustituir al primer gestor se realice sin la acción del operador, es decir, sin que sea necesario personal que reaccione ante la avería del primer gestor. El procedimiento puede realizarse en referencia a una, a varias o a todas las suscripciones del primer gestor en el agente. Esto se aplica también a las configuraciones y perfeccionamientos que se describen a continuación. En un perfeccionamiento de la invención, tras el envío del primer mensaje el agente recibe desde el segundo gestor un segundo mensaje para pedir notificaciones de evento conforme a la suscripción del primer gestor. De este modo, el segundo gestor tras la recepción del primer mensaje pide al agente directamente el envío de notificaciones de evento conforme a la suscripción del primer gestor, de manera que el agente, en caso necesario, puede realizar ajustes para posibilitar el envío de las notificaciones de evento conforme a la suscripción del primer gestor al segundo gestor. Es ventajoso cuando el primer mensaje comprende 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 las notificaciones de evento que deben enviarse conforme a 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 envía, en caso de finalizar el fallo de la comunicación entre el agente y el primer gestor o de finalizar el fallo del primer gestor, un tercer mensaje de información sobre la finalización del fallo al segundo gestor. Posteriormente, el agente finaliza el envío de notificaciones de evento conforme a la suscripción del primer gestor al segundo gestor y retoma el envío de notificaciones de evento conforme a la suscripción del primer gestor al primer gestor. De mantera ventajosa, tras el envío del tercer mensaje el agente recibe desde el segundo gestor un cuarto mensaje para pedir la finalización del envío de notificaciones de evento conforme a la suscripción del primer gestor. Debido a esta petición directa, el agente puede, dado el caso, modificar los ajustes de manera que como resultado de este procesamiento, pueda ajustarse el envío de notificaciones de evento conforme a la o las suscripciones del primer gestor al segundo gestor. El agente puede reconocer la finalización del fallo por ejemplo mediante la ausencia o la presencia de determinados mensajes, tales como por ejemplo la petición de comunicación, desde el primer gestor. El agente informa a continuación al segundo gestor, el cual puede adoptar la función de sustitución para el primer gestor debido a las notificaciones de evento que se le envían, con lo cual el segundo gestor puede pedir al agente que se abstenga del envío de las notificaciones de evento conforme a la o las suscripciones del primer gestor. En una configuración de la invención, el agente ha almacenado antes de la aparición del fallo información de identificación del segundo gestor como el gestor asignado al primer gestor con respecto a fallos. Por tanto un agente puede tener almacenada, por ejemplo, una tabla que incluye una asignación de dos gestores en cada caso entre sí. Cada gestor al que el agente envía notificaciones de evento puede estar asignado de este modo a un gestor de apoyo o suplente o de sustitución. El agente según la invención para una red de gestión presenta medios para enviar notificaciones de evento a un primer gestor conforme a una suscripción del primer gestor, así como medios para detectar un fallo de la comunicación entre el agente y el primer gestor o un fallo del primer gestor, y medios para enviar un mensaje con información sobre la suscripción del primer gestor al segundo gestor en caso de fallo. El gestor según la invención para una red de gestión presenta medios para recibir un mensaje desde un agente con información sobre una suscripción de otro gestor, así como medios para recibir notificaciones de evento conforme a la suscripción del otro gestor desde el agente . Tanto el agente según la invención como el gestor según la invención son adecuados especialmente para realizar el procedimiento según la invención, afectando esto también aplicable a la configuración y al perfeccionamiento. Para esto pueden presentar otros medios adecuados .
BREVE DESCRIPCIÓN DE LAS FIGURAS A continuación se explica más detalladamente la invención con ayuda de un ejemplo de realización. Muestran:
la figura 1, una sección de una red de gestión, la figura 2, un diagrama del desarrollo del procedimiento según la invención, la figura 3, esquemáticamente, la estructura de un agente según la invención, la figura 4, esquemáticamente, la estructura de un gestor según la invención.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La figura 1 muestra una sección de una red de gestión de un sistema de telecomunicaciones, tal como por ejemplo 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: "Network Management Center", centro de gestión de red) . La capa de gestión del elemento de red AGENTE, como la inferior de las dos capas representadas, se compone de los dos agentes 0MC1 y 0MC2 (OMC: "Operation and Maintenance Center" , centro de funcionamiento y mantenimiento) . La invención se explica a continuación con ayuda de la interfaz representada en la figura 1 entre la capa de gestión de red y la capa de gestión del elemento de red. Sin embargo, puede aplicarse a cualquier interfaz gestor-agente, así por ejemplo a la interfaz entre la capa de gestión del elemento de red y la capa del elemento de red situada más abajo no representada en la figura 1. La red de gestión puede incluir una pluralidad de gestores y agentes adicionales, pero cuya presencia no es relevante para la comprensión de la invención. Los gestores NMC1 y NMC2 han "abonado" las notificaciones de evento relevantes para ellos en los agentes OMC1 y
OMC2 o están suscritos para éstas. Esto significa que el gestor respectivo ha enviado al agente respectivo una petición que tiene como consecuencia la creación de un mecanismo de filtrado. Un mecanismo de filtrado provoca que de la pluralidad de notificaciones de evento sólo lleguen a un gestor aquéllos que corresponden a la o las suscripciones de este gestor, de modo que un gestor puede controlar el flujo de información procedente del agente según sus peticiones individuales. Un filtro de este tipo puede crearse por ejemplo en una interfaz de gestión basada en CORBA con ayuda del denominado servicio de notificación, "Notification Service", según la especificación de servicio de notificación VI .0.1 "Notification Service Specification" del OMG (OMG: "Object Manager Group" grupo de gestor de objeto) , o en una interfaz de gestión basada en CMIP con ayuda del discriminador de reenvío de eventos "Event Forwarding Discriminators" según ITU-T X.734 "Gestión de sistemas: función de gestión de eventos de notificación" . La interfaz representada en la figura 1 entre la capa de gestión de red y la capa de gestión del elemento de red es un ejemplo de una configuración de múltiples gestores. Varios NMC pueden estar conectados a un OMC, con lo que cada NMC asume una tarea de gestión específica. 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 OMCl, mientras que el gestor NMC2 está conectado a ambos agentes OMCl y 0MC2. Esto significa que el gestor NMC1 recibe notificaciones de evento desde el agente OMCl y el gestor NMC2 de ambos agentes OMCl y 0MC2. Puesto que existen varios gestores NMC1 y NMC2, ambos gestores NMC1 y NMC2 sólo deben analizar generalmente un subconjunto de notificaciones de evento creadas por los agentes OMCl y 0MC2, de manera que para la comunicación entre los agentes OMCl y 0MC2 y los gestores NMC1 y NMC2 se ajustan los filtros correspondientes. Con este fin, el estándar 3GPP TS 32.302 ( "Notification Integration Reference Point (IRP) : Information Service", Notificación de integración de punto de referencia: servicio de información) define un denominado mecanismo de suscripción con el que un gestor puede comunicar a un agente datos precisos sobre el tipo y los valores de parámetro de las notificaciones relevantes para él. El mecanismo de suscripción puede aplicarse independientemente del protocolo de comunicación empleado para la comunicación entre el gestor y el agente. Para la iniciación de la suscripción, un gestor envía a un agente una petición de suscripción con su información de identificación, la denominada "referencia del gestor" . El agente responde a la misma con información de identificación de la suscripción, el denominado valor "Id de suscripción" , que debe emplearse para las demás operaciones del gestor con respecto a esta suscripción. Un gestor puede enviar varias veces peticiones de suscripción a un agente, por ejemplo para diferentes tipos de notificaciones de evento, con lo cual el agente adjudica en cada petición de suscripción un nuevo valor "Id de suscripción" unívoco. Tras la recepción de la información de identificación de la suscripción, el gestor puede dar lugar a operaciones con respecto a esta suscripción mediante el envío de mensajes adecuados descritos a continuación teniendo en cuenta el valor "Id de suscripción": "dar de baja" : el agente finaliza posteriormente la presente suscripción con ayuda del carácter de identificación "referencia de gestor" . "obtener Id de suscripción" : con esto el gestor pide con ayuda del carácter de identificación "referencia del gestor" todos los valores "Id de suscripción" que le ha adjudicado el agente. "obtener estado de suscripción" : el gestor recibe posteriormente con respecto a la suscripción respectiva información sobre el tipo de notificaciones de evento y del filtro actual. "cambiar filtro de suscripción" : el gestor puede modificar la estructura del filtro de la suscripción.
"suspender suscripción" : una suscripción cesará temporalmente, es decir el gestor no recibe durante algún tiempo ninguna notificación de evento conforme a esta suscripción. "reanudar suscripción" : una suscripción que anteriormente había cesado vuelve a activarse, es decir, el gestor recibe de nuevo notificaciones de evento conforme a esta suscripción. Las peticiones del gestor descritas incluyen, en cada caso, información de identificación de la suscripción, es decir el valor "Id de suscripción", e información de identificación del gestor, es decir el carácter de identificación "referencia de gestor" . De este modo, las operaciones descritas sólo pueden llevarse a cabo por el gestor que ha iniciado la suscripción y que por tanto conoce el valor "Id de suscripción" . A continuación se considera el caso en que el gestor NMC1 no puede asumir temporalmente su función de supervisión, de modo que la comunicación entre el gestor NMC1 y el agente OMCl falla. Esto puede deberse a la avería del gestor NMC1 en sí mismo o a la avería de la comunicación entre el gestor NMC1 y el agente OMCl . Según el estado de la técnica, en este caso el personal del gestor NMC1 puede ponerse en contacto, por ejemplo telefónicamente, 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 puede darse lugar a que el otro gestor, a través de las entradas de datos correspondientes del personal, puede sustituir al gestor NMC1 que se ha averiado. Esta forma de proceder tiene la desventaja de que se pierde tiempo debido a la costosa transmisión de información, durante la que, en determinadas circunstancias, no puede procesarse una pluralidad de notificaciones de evento conforme a la suscripción del gestor NMC1. Además es necesaria la presencia de personal en el lugar del gestor NMC1 y de otro gestor para poder realizar una sustitución temporal del gestor NMC1 averiado. Según la invención, el agente OMCl para el caso de la avería del gestor NMC1 tiene almacenadas información de identificación del gestor NMC2, el cual durante el fallo de la comunicación entre el gestor NMC1 y el agente OMCl deberá realizar la función de gestor del gestor NMC1 en sustitución de éste. El gestor NMC2 actúa de este modo como "gestor de apoyo" con respecto al gestor NMC1. Cuando un agente envía notificaciones de evento a una pluralidad de gestores, éste presenta una tabla en la que a cada uno de estos gestores se le asigna un gestor de apoyo. El almacenamiento se lleva a cabo preferiblemente a través de un archivo que puede configurarse por el operador de la red de gestión, de modo que pueda modificarse el gestor de apoyo asignado a un gestor. Un gestor puede estar asignado a varios gestores distintos como gestor de apoyo. Igualmente, diferentes agentes puede tener almacenados diferentes gestores de apoyo con respecto a un gestor. La figura 2 muestra el desarrollo del procedimiento según la invención. El gestor NMCl ha iniciado una suscripción en el agente OMCl y recibe conforme a esta suscripción las notificaciones de evento NOTIFICAR EVENTO. El agente OMCl detecta usando un procedimiento conocido en sí mismo, que ha fallado la comunicación entre el agente OMCl y el gestor NMCl, simbolizado por una flecha doble atravesada por un rayo. Automáticamente, es decir sin necesidad de petición, el agente OMCl envía tras la detección del fallo un mensaje de notificar suscripción deshabilitada al gestor NMC2, cuyo carácter de identificación de "referencia de gestor" ha almacenado éste como gestor de apoyo para el gestor NMCl. El mensaje de notificar suscripción deshabilitada contiene la siguiente información: el carácter de identificación de "referencia de gestor" del gestor NMCl, el valor de "Id de suscripción" como información de identificación explícita de la suscripción del gestor NMCl, un parámetro "conjunto de categorías de identificación", que indica qué tipos de notificaciones de evento NOTIFICAR EVENTO debería recibir el gestor NMCl conforme a su suscripción, una magnitud "filtro", que define la estructura de filtro para las notificaciones de evento NOTIFICAR EVENTO relacionados con el parámetro "conjunto de categorías de notificación", una magnitud "estado de suscripción", que indica si la suscripción en ese momento estaba interrumpida por el gestor NMCl ("suspended") o se estaba utilizando ("running"). En caso de que existan varias suscripciones del gestor NMCl en el agente OMCl, en el mensaje de notificar suscripción deshabilitada se comunican el valor "Id de suscripción", el "conjunto de categorías de suscripción", el "filtro", y el "estado de suscripción" para cada una de las suscripciones. Tras la recepción del mensaje de notificar suscripción deshabilitada, el gestor NMC2 envía al agente OMCl un mensaje de petición de suscripción, que pide al agente OMCl que ajuste todas las suscripciones interrumpidas en ese momento del gestor NMCl para el gestor NMC2. El mensaje de suscribir petición puede afectar a todas las suscripciones existentes del gestor NMCl. Sin embargo también es posible enviar un mensaje propio de suscribir petición por suscripción. El mensaje de suscribir petición contiene las magnitudes "referencia de gestor" del gestor NMC2, "conjunto de categorías de notificación" y "filtro" para las suscripciones correspondientes. De este modo se garantiza que para la gestión de la red no se pierdan notificaciones relevantes. Más concretamente, las notificaciones de evento NOTIFICAR EVENTO se envían conforma a la o las suscripciones del gestor NMCl por el agente OMCl al gestor NMC2. Por tanto, el gestor NMC2 puede asumir las tareas del gestor NMCl averiado. En caso de que el fallo de la comunicación entre el agente OMCl y el gestor NMCl haya finalizado, simbolizado en la figura 2 por una flecha doble atravesada por un "OK" , el agente OMCl envía sin que se le pida un mensaje de notificar suscripción habilitada, teniendo en cuenta la información de identificación del gestor NMCl, al gestor NMC2 , con el que se le comunica al gestor NMC2 que el gestor NMCl sustituido por él vuelve a estar listo para su funcionamiento. Posteriormente, el gestor NMC2 envía al agente OMCl un mensaje de petición de dar de baja, que comprende la "referencia de gestor" del gestor NMC2, así como el "conjunto de categorías de notificación" y el "filtro" para las respectivas suscripciones. Como en el mensaje petición de suscripción, puede utilizarse un único mensaje de petición de dar de baja o bien un mensaje de petición de dar de baja propio para cada suscripción del gestor NMCl. A continuación vuelven a enviarse notificaciones de evento NOTIFICAR EVENTO del agente OMCl conforme a la suscripción del gestor NMCl al gestor NMCl. En el procedimiento descrito es ventajoso que el gestor NMC2 pueda asumir automáticamente, es decir especialmente sin necesidad de una intervención humana, las tareas del gestor NMCl inactivo. El procedimiento descrito es aplicable a las redes de telecomunicaciones más variadas. Es independiente del protocolo de comunicaciones utilizado para la interfaz gestor-agente. La figura 3 muestra esquemáticamente la estructura del agente OMCl. Éste presenta los medios MEDIOS PARA NOTIFICAR EVENTOS GESTOR y MEDIOS PARA NOTIFICAR EVENTOS GESTOR DE APOYO para el envío de notificaciones de evento a un gestor o a un gestor de apoyo conforme a una suscripción del gestor. Con los medios DETECTAR ERROR / RECUPERACIÓN, el agente OMCl puede detectar la aparición o corrección de un fallo de la comunicación entre el agente OMCl y un gestor. Debido a la detección de un fallo, se genera utilizando los medios TRANSMITIR notificar suscripción deshabilitada un mensaje descrito anteriormente de notificar suscripción deshabilitada y se envía a un gestor de apoyo, cuya información de identificación está almacenada en la memoria MEMORIA GESTOR DE APOYO. En caso de que el agente OMCl detecte con los medios DETECTAR ERROR / RECUPERACIÓN que una comunicación que ha fallado anteriormente entre el agente OMCl y un gestor vuelve a estar libre de fallos, se genera utilizando los medios TRANSMITIR notificar suscripción habilitada un mensaje descrito anteriormente de notificar suscripción habilitada y se envía al gestor de apoyo, cuya información de identificación está almacenada en la memoria MEMORIA GESTOR DE APOYO. La recepción de un mensaje, explicado anteriormente, de suscribir petición desde el gestor de apoyo con los medios RECIBIR suscribir petición del GESTOR DE APOYO, controla los medios MEDIOS PARA NOTIFICAR EVENTOS GESTOR DE APOYO para el envío de notificaciones de evento al gestor de apoyo conforme a las suscripciones del gestor, mientras que la recepción de un mensaje descrito anteriormente de dar de baja petición del gestor de apoyo con los medios RECIBIR dar de baja petición del GESTOR DE APOYO, provoca que los medios MEDIOS PARA NOTIFICAR EVENTOS GESTOR DE APOYO ya no envíen notificaciones de evento conforme a la suscripción del gestor al gestor de apoyo, sino al gestor. La estructura del gestor NMC2 se muestra esquemáticamente en la figura 4. Con los medios MEDIOS PARA NOTIFICAR EVENTOS AGENTE, el gestor NMC2 recibe y procesa las notificaciones de eventos recibidas por el agente. Debido a la recepción de un mensaje explicado anteriormente de notificar suscripción deshabilitada con los medios RECIBIR notificar suscripción deshabilitada, se genera con los medios TRANSMITIR suscribir petición un mensaje descrito anteriormente de suscribir petición y se envía al agente que recibió el mensaje de notificar suscripción deshabilitada. Debido a la recepción de un mensaje explicado anteriormente de notificar suscripción habilitada con los medios RECIBIR notificar suscripción habilitada, se genera con los medios TRANSMITIR dar de baja petición un mensaje descrito anteriormente de petición de dar de baja y se envía al agente que recibió el mensaje de notificar suscripción deshabilitada.