ES2281357T3 - Procedimiento generico para el alineamiento en un entorno multigestor. - Google Patents
Procedimiento generico para el alineamiento en un entorno multigestor. Download PDFInfo
- Publication number
- ES2281357T3 ES2281357T3 ES00967531T ES00967531T ES2281357T3 ES 2281357 T3 ES2281357 T3 ES 2281357T3 ES 00967531 T ES00967531 T ES 00967531T ES 00967531 T ES00967531 T ES 00967531T ES 2281357 T3 ES2281357 T3 ES 2281357T3
- Authority
- ES
- Spain
- Prior art keywords
- data
- manager
- adjustment
- agent
- filtering
- 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 57
- 238000001914 filtration Methods 0.000 claims abstract description 43
- 238000004891 communication Methods 0.000 claims description 18
- 230000005540 biological transmission Effects 0.000 claims description 8
- 238000007726 management method Methods 0.000 description 75
- 230000008569 process Effects 0.000 description 30
- 230000009228 embryo fetal development Effects 0.000 description 15
- 238000012423 maintenance Methods 0.000 description 14
- 230000000875 corresponding effect Effects 0.000 description 12
- 230000006870 function Effects 0.000 description 11
- 230000009471 action Effects 0.000 description 10
- 238000010295 mobile communication Methods 0.000 description 7
- 230000004044 response Effects 0.000 description 7
- 230000008859 change Effects 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 230000011664 signaling Effects 0.000 description 2
- 101000864232 Euglena gracilis Delta(8)-fatty-acid desaturase Proteins 0.000 description 1
- 230000008033 biological extinction Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000001276 controlling effect Effects 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000012913 prioritisation Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000007704 transition Effects 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
- H04Q3/0075—Fault management techniques
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Mobile Radio Communication Systems (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Procedimiento en una red de telecomunicaciones para el ajuste de datos mediante una red de gestión que presenta al menos dos niveles de gestión (A, B, C), transmitiéndose, para el ajuste de datos entre al menos un agente (AG) de un nivel de gestión (B, C) y al menos un gestor (MA1, MA2) de un nivel de gestión siguiente superior (A, B), datos para el ajuste de datos desde el agente (AG) al gestor (MA1, MA2), en el que el gestor (MA1, MA2) envía al agente (AG) uno o varios mensajes de solicitud (M-ACTION Request) para transmitir los datos de ajuste de datos, el gestor (MA1, MA2) transmite informaciones de correlación (managerHandle, 78) para una asignación de la correspondiente solicitud a los datos de ajuste de datos enviados a continuación por el agente (AG), utilizándose los equipos de filtrado (EFD) que reciben datos de varios gestores (MA1, MA2) y dejan pasar a su través los datos de ajuste de datos en función de las informaciones de correlación (managerHandle, 78) sólo al gestor (MA1, MA2) que solicita los correspondientes datos de ajuste de datos, caracterizado porque los equipos de filtrado (EFD) eliminan por filtrado, utilizando un ajuste de filtrado, todos los datos de comparación de datos en base a informaciones de un campo adicional (Additional Text) de mensajes (M-EVENT-REPORT) que contienen los datos de ajustes de datos.
Description
Procedimiento genérico para el alineamiento en
un entorno multigestor.
La invención se refiere a un procedimiento y a
un sistema de comunicaciones para el ajuste de datos mediante una
red de gestión que presenta al menos dos niveles de gestión, según
las particularidades características del concepto general de la
reivindicación 1, transmitiéndose en particular para por ejemplo un
ajuste de datos de alarmas genérico, entre un agente de un nivel de
gestión y un gestor del siguiente nivel de gestión superior, los
datos de alarma de las alarmas activas.
Los principios de una red de gestión, que
también se denominan principios TMN (TMN: Telecommunications
Management Network, red de gestión de las telecomunicaciones),
definen varios niveles de gestión para la gestión de un sistema de
comunicaciones - por ejemplo de un sistema de comunicaciones móviles
- teniendo cada nivel una función doble. En el sistema gestor tiene
cada nivel, a excepción del más inferior, una función de gestor
para el nivel siguiente inferior. En el sistema gestionado tiene
cada nivel, a excepción del más alto, una función de agente para el
siguiente nivel superior.
La gestión de errores ("Fault Management")
es por ejemplo una parte importante de la gestión TMN. Por lo
general juega en este caso el agente el papel activo, detectando
sucesos de error del propio nivel de gestión a tiempo y con
precisión y transmitiéndolos al gestor del siguiente nivel superior
como informes de sucesos o bien los llamados "event reports"
(por ejemplo alarm reports). La transmisión de datos de sucesos del
agente al gestor no es crítica, mientras el mecanismo de
comunicación entre estos sistemas no esté perturbado. Cuando el
enlace entre ambos niveles de gestión, es decir, entre agente y
gestor, ya no esté asegurado durante un determinado tiempo, debe
memorizar transitoriamente el agente los sucesos que se presentan
durante este intervalo, para asegurar que tras restablecerse la
posibilidad de comunicación se pone a disposición del gestor por un
lado, con la mayor rapidez posible una visión general del estado
actual de la red - por ejemplo para alarmas activas en forma de una
lista - y el gestor puede construir por otro lado una historia con
las menores lagunas posibles de los sucesos ("event history"),
por ejemplo tanto de las alarmas activas como también de las
finalizadas ("cleared alarms").
Para este fin se realiza un ajuste de datos
(data realigment) entre agente y gestor para cada establecimiento
de enlace tras una interrupción del enlace o tras una inicialización
del agente o del gestor. Todos los datos de alarma de las alarmas
activas respecto a las cuales los errores no hayan sido eliminados
aún en el agente -reconocibles porque no están caracterizadas como
"cleared alarms" - han de ponerse por lo tanto por la mayor
rapidez posible e íntegramente a disposición del siguiente nivel
superior de gestión.
En la DE 197 52 614 y la DE 198 01 784 se
indican tales procedimientos y sistemas de comunicaciones para el
tratamiento de alarmas que describen una funcionalidad básica para
el gestor para solicitar todas las alarmas del agente. Al respecto
envía el agente las alarmas activas como secuencia de
M-EVENT-REPORTS (informes de
sucesos) estandarizados, que está alojada en una solicitud iniciada
al principio por el gestor
M-ACTION-Request (solicitud de
acción) y en una respuesta iniciada al final por el agente
M-ACTION-Response (respuesta de
acción). Estos son procedimientos genéricos estandarizados CMISE
(Common Management Information Service Element, elemento del
servicio de información de gestión común), definidos según
ITU-T X.710 (ITU-T: International
Telecommunication Union - Telecommunication Sector, Unión
Internacional de Telecomunicaciones, sector de telecomunicaciones).
La ITU-T X.733 define el contenido de una
transmisión de alarmas estandarizada (alarm report), que se ejecuta
según los M-EVENT-REPORTS Services
(servicios de informes de sucesos). Todos los
M-EVENT-REPORTS definidos en el
marco de esta M-ACTION (acción) están
correlacionados inequívocamente en relación con la correspondiente
solicitud mediante la utilización de informaciones de correlación.
Esto permite al gestor asignar estos
M-EVENT-REPORTS a una determinada
solicitud y además distinguirla de otros
M-EVENT-REPORTS
"regulares".
En la DE 198 01 785 se parte de que para un
ajuste de datos de alarma entre un agente de un nivel de gestión y
al menos un gestor de un nivel de gestión siguiente superior se
transmiten los datos de alarma de las alarmas activas. Además,
envía el gestor uno o varios mensajes de solicitud para transmitir
los datos de alarmas al agente, así como informaciones de
correlación para una asociación de la correspondiente solicitud a
los mensajes enviados a continuación por el agente con los datos de
alarmas.
Debido a que el ajuste de los datos de alarmas
es controlado allí por el gestor en función de al menos un
parámetro enviado al agente, puede parametrizarse el ajuste de los
datos de alarma para el gestor respecto a la funcionalidad básica.
Es decir, ya no debe enviar el agente forzosamente todas las alarmas
activas, sino sólo las definidas con más precisión por los
parámetros transmitidos. De ello resulta para el gestor una función
de elección para un subconjunto de todas las alarmas. Para ello se
utilizan mensajes estandarizados.
Con este proceder puede llamar específicamente
el gestor a las alarmas especialmente críticas en cuanto a la
funcionalidad y con ello importantes para él, y con ello descargar
de manera importante la interfaz con el agente mediante el flujo de
información restringido sólo a determinadas alarmas, en comparación
con el procedimiento tradicional de la señalización automática de
todas las alarmas.
En un entorno multigestor, debe estar el agente
en general en condiciones de dominar tareas de varios gestores
simultáneamente. Por otro lado, puede cumplir un gestor su función
sólo óptimamente cuando todos los sucesos relevantes ("Event
reports") sean recibidos rápidamente de los agentes subordinados.
Bajo condiciones normales, es decir, cuando la comunicación entre
agente y gestor(es) funciona, esto se realiza mediante un
mecanismo de Event Reporting o informe de sucesos. Al respecto
genera el agente tras detectar un suceso el correspondiente
mensaje. Además de los ya citados mensajes de alarma, se trata por
ejemplo de mensajes o notificaciones relativas a una modificación
del estado (State change), generación de objeto, extinción de objeto
(Object creation/Object deletion) o modificaciones del valor del
atributo (Attribute value change Notification). Éstos se envían a
discriminadores de retransmisión de sucesos (discriminadores Event
Forwarding) eventualmente existentes en el agente, los llamados
EFDs.
La tarea de un EFD consiste en transmitir o
enrutar al gestor sólo aquellos informes de sucesos que cumplen
determinados criterios de filtrado. El gestor está en condiciones de
colocar tales EFDs en el agente o bien borrarlos y fijar los
criterios de filtrado. De esta manera puede controlar cada gestor en
todo momento el flujo de informaciones según sus exigencias
individuales.
En un entorno orientado al objeto, como por
ejemplo entre gestor y agente en una red de telefonía móvil, se
pone a disposición toda funcionalidad de agente de un determinado
objeto como instancia de una clase de objetos. El objeto resulta
como resultado de una actividad de modelización (definición de un
modelo de información) y es conocido tanto por el gestor como
también por el agente ejecutor.
Tal como se ha descrito, hay diversas
situaciones en las que es necesario un ajuste general de datos -
llamado Alignment o alineamiento - en relación especialmente con
alarmas, estados, modificaciones de configuración entre
gestor(es) y agente(s), que va más allá del mecanismo
normal del informe de sucesos, por ejemplo tras la interrupción de
un enlace o tras una inicialización del agente o gestor. Este
alineamiento se inicia la mayoría de las veces a solicitud del
gestor (manager request).
En particular para su utilización en un sistema
de telefonía móvil de la tercera generación, como UMTS (Universal
Mobile Telecommunication System, sistema universal de
telecomunicaciones móviles), debe cumplir un procedimiento de
alineamiento óptimo y preferentemente susceptible de estandarización
entre gestor(es) y agente(s) cuanto más mejor de los
siguientes criterios:
- 1.
- El procedimiento debe utilizar lo más posible sólo servicios/protocolos estandarizados y ser de naturaleza genérica, para evitar implementaciones específicas de gestor o bien agente.
- 2.
- La información de alineamiento debe - al menos para los llamados parámetros "mandatorios" - incluir el mismo contenido que la notificación original, lo cual es importante sobre todo para las llamadas informaciones dinámicas, como alarmas o estados.
- 3.
- El gestor debe determinar el arranque del alineamiento en ajustes de datos a controlar por el gestor y debe poder detectar inequívocamente la finalización del alineamiento.
- 4.
- El gestor debe poder distinguir entre una notificación "on-line" (normal) y una notificación que se recibe como consecuencia de un proceso de alineamiento previamente iniciado.
- 5.
- Las notificaciones enviadas por el agente mediante el proceso de alineamiento utilizan los mismos EFDs que las notificaciones "normales".
- 6.
- Para las notificaciones enviadas por el agente mediante el procedimiento de alineamiento, rigen los mismos ajustes Log que para las notificaciones "normales".
- 7.
- El gestor puede solicitar un proceso de alineamiento completo o sólo parcial, por ejemplo en función de determinados valores de parámetros.
- 8.
- En un entorno multigestor debe recibir cada gestor sólo aquellas notificaciones que se envían como consecuencia de un proceso de alineamiento activado por él mismo, incluso cuando se ejecutan por parte de varios gestores alineamientos que corren en paralelo.
- 9.
- El gestor puede también distinguir entonces entre notificaciones cuando corren simultáneamente varios procesos de alineamiento propios, por ejemplo para distintos datos o regiones de red.
Hasta ahora hay dos tipos básicos de procesos de
ajuste de datos o bien procesos de alineamiento:
- a)
- el gestor envía al agente una solicitud (M-ACTION-Request o bien solicitud de acción según el estándar ITU-T X. 710), que contiene los parámetros de alineamiento y un número inequívoco. El agente envía primeramente una llamada notificación "Start alignment" (iniciar alineamiento) - para la correlación de todas las notificaciones enviadas con el Manager-Request (solicitud del gestor) - y a continuación las notificaciones de alineamiento a todas las instancias EFD. El final del proceso de alineamiento se comunica al gestor mediante una M-ACTION-Response o respuesta de acción estandarizada CMISE o bien mediante una notificación separada "End alignment" o final del alineamiento (CMISE: Common Management Information Service Element, elemento del servicio de información de gestión común).
- Este procedimiento ya utilizado en sistemas de telefonía móvil es no obstante desventajoso, ya que no se introducen notificaciones estandarizadas ("Start alignment"/"End alignment", comienzo del alineamiento/final del alineamiento). En un entorno multigestor se reciben además, desventajosamente, las notificaciones enviadas mediante un determinado proceso de alineamiento también de todos los otros gestores, lo que trae como consecuencia notificaciones innecesarias o bien recibidas repetidamente. Con ello no se cumplen los criterios anteriores 1 y 8.
- b)
- El gestor envía una solicitud, una M-ACTION-Request estandarizada CMISE, que contiene los parámetros de alineamiento, entre ellos también los criterios de filtrado para este proceso de alineamiento. El agente debe entonces determinar primeramente las notificaciones correspondientes a los criterios. A continuación forma el agente una M-ACTION-Response con todas estas notificaciones y envía éstas al causante de la solicitud (Request) o bien gestor.
- Este procedimiento es igualmente desventajoso, ya que significa una implementación específica, porque el agente debe comprobar primeramente todas las notificaciones potenciales según los criterios de filtrado contenidos en la M-ACTION-Request. Esto da lugar a un mal comportamiento en el tiempo del proceso de alineamiento. Además, no utilizan las notificaciones de alineamiento los mismos filtros respecto al informe de sucesos o bien "Event reporting" (en el EFD) y a la protocolización de sucesos o bien "Event logging" (LOG) que las notificaciones "normales". En consecuencia, no se cumplen los criterios anteriores 1, 5 y 6.
La tarea de esta invención consiste en proponer
un procedimiento y sistema de comunicaciones como el indicado para
el ajuste de datos en una red de gestión que presenta varios
niveles de gestión, que sea adecuado para distintos datos de
gestión y mediante el cual mejore aún más un ajuste de datos entre
un agente y al menos un gestor.
Esta tarea se resuelve en cuanto al
procedimiento mediante las particularidades de la reivindicación 1 y
en cuanto al sistema de comunicaciones mediante las
particularidades de la reivindicación 9. Ventajosos
perfeccionamientos son objeto de las reivindicaciones
secundarias.
El procedimiento propuesto es un procedimiento
genérico para que corra un proceso de alineamiento que cumpla todos
los criterios mencionados. Es decir, es en particular independiente
de la información transmitida y de las implementaciones
gestor/agente.
Además, no es necesaria ninguna notificación
adicional aún no definida en los estándares. Esto significa una
implementación sencilla, conforme a los estándares en el agente y
una correlación sencilla en el gestor entre Request (solicitud) y
notificaciones de Alignment (alineamiento).
El intercalado de las unidades de filtrado entre
las unidades funcionales propiamente dichas de gestores y agentes
descarga a éstos de sus tareas rutinarias. Ya no son necesarias las
funciones de filtrado autónomas en gestores y agentes para la
asignación de datos para el ajuste de datos para determinados
gestores.
La colocación de unidades de filtrado en las
zonas de salida o emisión de los agentes descarga la red de
comunicaciones que se encuentra entre agentes y gestores o bien
sus equipos intercalados de manera especialmente ventajosa.
La utilización de campos adicionales opcionales,
en particular del campo "Additional text" (texto adicional)
permite la utilización de los estándares existentes sin nuevas
definiciones. En el caso ideal, son necesarias simplemente
modificaciones técnicas del programa en el software de control en
gestores y agentes.
A continuación se describirá más en detalle la
invención en base a ejemplos de ejecución con referencia a las
figuras. Se muestra en
Fig 1 el diagrama de bloques de circuitos de
una red de gestión para un sistema de comunicaciones móviles con
relación agente-gestor entre un centro de servicio y
mantenimiento y uno o varios centros de gestión de red,
Fig 2 el diagrama de bloques de circuitos de la
red de gestión según la figura 1 con relación
agente-gestor entre un sistema de estaciones de
base y un centro de servicio y mantenimiento para realizar al menos
dos aplicaciones para el sistema de estaciones de base,
Fig 3 el diagrama de bloques de circuitos de
agente y gestores para el tratamiento de los sucesos para ajustes
de datos que corren en paralelo o en serie,
Fig 4 el flujo de mensajes entre un gestor y el
agente para el control del filtrado de datos en el ejemplo de
alarmas en el ajuste de datos.
El ejemplo de ejecución describe la invención en
base a un concepto TMN a modo de ejemplo para la gestión de un
sistema de comunicaciones móviles, que presenta por ejemplo equipos
de red de una red de telefonía móvil según el estándar UMTS o GSM.
El concepto no queda no obstante limitado a redes de telefonía
móvil, sino que puede utilizarse sobre redes de telecomunicaciones
de todo tipo que utilizan una red de gestión TMN.
Un sistema de comunicaciones móviles es un
sistema estructurado jerárquicamente de diversos equipos de red, en
el que el escalón de jerarquía más bajo está formado por las
estaciones móviles. Estas estaciones móviles se comunican a través
de una interfaz de radio con las estaciones de radio que forman el
siguiente nivel jerárquico, denominadas estaciones de base. Las
estaciones de base que por ejemplo alimentan estaciones móviles en
una zona de radio de una célula de radio están reunidas,
ventajosamente, para cubrir un sector de radio más grande y
conectadas con equipos de red superiores, los equipos de control de
estaciones de base. Las estaciones de base y los equipos de control
de estaciones de base pertenecen a un sistema de estaciones de base
(Base Station Subsystem) del sistema de comunicaciones móviles. Los
equipos de control de estaciones de base se comunican a través de
interfaces definidas con uno o varios equipos de conmutación, los
equipos de conmutación móvil, a través de los cuales se realiza
también entre otros la transición a otras redes de comunicaciones.
Los puestos de conmutación móvil forman junto con múltiples bancos
de datos el sistema de conmutación (Switching Subsystem) del
sistema de comunicaciones móviles.
Además de los citados equipos de red, existen
uno o varios centros de operación y mantenimiento (Operation and
Maintenance Centres), que entre otros sirven para configurar y
vigilar los equipos de red. Las medidas de vigilancia y las medidas
de configuración se telecontrolan para ello la mayoría de las veces
desde el centro de operación y mantenimiento, dispuesto usualmente
en la zona de los puestos de conmutación móvil. Un centro de
operación y mantenimiento comunica entonces en cada caso con un
sistema de estaciones de base o sistema de conmutación a través de
una interfaz definida. Otra tarea del sistema de operación y
mantenimiento es la realización de la gestión de configuración
(Configuration Management), que junto a la gestión de errores
representa una de las cinco zonas funcionales de gestión que
identifican los principios TMN. La gestión de configuración define
una serie de servicios, que posibilitan una modificación de la
estructura y con ello del comportamiento de una red de
telecomunicaciones por parte del operador. Estos servicios se
refieren siempre a instancias de objetos gestionados, que en su
conjunto forman la base de información de gestión específica de la
red.
Un objeto gestionado en el sentido de la gestión
de configuración es una abstracción lógica de un recurso en el
sistema de comunicaciones móviles. Aquí se distingue entre objetos
gestionados referidos a hardware, que describen una realización
específica del fabricante de una función y objetos gestionados
referidos a funciones, en los que se trata en cada caso de la
abstracción de una funcionalidad independiente del fabricante.
Para la gestión del sistema de comunicaciones
móviles, que se describirá a continuación en base al "Fault
Management" (gestión de errores), definen los principios TMN
varios niveles ("Levels"), de los cuales en el presente
ejemplo se describirán a continuación tres niveles con referencia a
las figuras 1 y 2.
Las figuras 1 y 2 muestran en cada caso tres
niveles A, B y C de la red de gestión, de los cuales el nivel de
gestión C contiene el nivel de equipos de red ("Network Element
Level"), con varios sistemas de estaciones de base BSS11, BSS12
… BSS1N, así como BSS21, BSS22 … BSS2M. El nivel de gestión B
caracteriza el nivel de gestión de equipos de red ("Network
Element Management Level"), en el que los centros de operación y
mantenimiento OMC1 y OMC2 ponen a disposición en cada caso la
funcionalidad de gestión específica del fabricante para subsistemas
individuales, como en el presente ejemplo el sistema de operación y
mantenimiento OMC1 para los sistemas de estaciones de base BSS11,
BSS12 … BSS1N y el sistema de operación y mantenimiento OMC2 para
los sistema de estaciones de base BSS21, BSS22 … BSS2M. El nivel de
gestión A caracteriza el nivel de gestión de red ("Network
Management Level"), en el que los centros de gestión de red NMC1
y NMC2 realizan en cada caso una funcionalidad de gestión
integrada, independiente del fabricante. Entonces pueden tener
acceso varios centros de gestión de red al mismo equipo de red del
nivel de gestión B siguiente inferior, en el presente ejemplo los
centros de gestión de red NMC1 y NMC2 del siguiente nivel de
gestión superior C al centro de operación y mantenimiento OMC1 del
siguiente nivel de gestión inferior B. Entre los equipos de red de
distintos niveles de gestión se prevén interfaces definidas para la
transmisión de informaciones.
La diferencia entre las representaciones
correspondientes a las figuras 1 y 2 reside en que existe una
relación agente-gestor para el tratamiento de
alarmas para uno o varios ajustes de datos de alarmas en la figura 1
entre el centro de operación y mantenimiento OMC1 (agent) y un
centro de gestión de red NMC1 (gestor) o varios centros de gestión
de red NMC1, NMC2 (gestor) - físicamente separados -, así como en la
figura 2 entre el sistema de estaciones de base BSS11 (agente) y
dos aplicaciones distintas OF1 y OF2 (gestor) en el centro de
operaciones y mantenimiento OMC1 o entre el centro de operación y
mantenimiento OMC1 (agente) y dos aplicaciones distintas NF1 y NF2
(gestor) en el centro de gestión de red NMC1. Para asegurar en los
centros de gestión de red NMC1, NMC2 en cada momento una visión
general sobre la situación en cuanto a errores, se ponen a
disposición desde el centro de operación y mantenimiento OMC1 los
datos de alarma memorizados de alarmas activas, en base a los
errores que se presentan por ejemplo dentro de los sistemas de
estaciones de base BSS11... BSS1N gestionados y se envían en
paralelo a ambos gestores sobre demanda. Esto tiene lugar
ventajosamente tras una interrupción del enlace o tras una
inicialización del agente o del gestor. Igualmente pueden dirigirse
varias solicitudes también una detrás de otra de un único gestor,
por ejemplo del centro de gestión de red NMC1, al agente, por
ejemplo el centro de operación y mantenimiento OMC1. La figura 1
muestra la estructura para solicitudes enviadas de manera múltiple,
según la invención, para el ajuste de datos de alarma, que en el
presente ejemplo corren en paralelo entre el nivel de gestión B, en
el que se encuentra el agente en forma del centro de operación y
mantenimiento OMC1, y el siguiente nivel superior de gestión A, en
el que se forman los gestores de al menos dos centros de gestión de
red NMC1, NMC2.
Para asegurar también en el nivel de gestión B,
por ejemplo en el centro de operación y mantenimiento OMC1, en cada
caso una visión general sobre la situación en cuanto a errores, se
ponen a disposición por el sistema de estaciones de base BSS11 los
datos de alarma memorizados de alarmas activas, en base a los
errores que se han presentado por ejemplo dentro de las estaciones
de base gestionadas y los equipos de control de estaciones de base,
y se envían en paralelo a al menos dos gestores del centro de
operación y mantenimiento OMC1 en forma de las distintas
aplicaciones OF1 y OF2, que son ejecutadas ambas por el mismo equipo
físico OMC1. Esto se realiza igualmente de manera ventajosa tras
una interrupción del enlace o tras una inicialización del agente o
del gestor. Una transmisión serie de solicitudes iniciadas de manera
múltiple por un único gestor, por ejemplo el centro de operación y
mantenimiento OMC1, al agente, por ejemplo el sistema de estaciones
de base BSS11, es igualmente posible. Alternativa o adicionalmente
puede existir una relación agente-gestor también
entre el centro de operación y mantenimiento OMC1 (un agente) y el
centro de gestión de red NMC1 (un gestor) para el intercambio en
serie de solicitudes y datos de alarma o para el intercambio en
paralelo de solicitudes y datos de alarma para al menos dos
aplicaciones distintas NF1 y NF2 (dos gestores) en el centro de
gestión de red NMC1. La figura 2 muestra la estructura para ajustes
de datos de alarmas que corren en paralelo según la invención entre
el nivel de gestión B, el que se encuentran los gestores como
aplicaciones OF1 y OF2, y el siguiente nivel inferior de gestión C,
en el que se encuentra el agente.
Tan pronto como una interfaz interna que ha
fallado en el nivel de gestión C está de nuevo preparada para el
servicio, se inicia a solicitud del gestor/de los gestores el ajuste
de los datos de alarmas, también denominado procedimiento de
Realignment o realineamiento, controlando según la invención el
gestor el ajuste de los datos de alarmas en función de los
parámetros. Al respecto, el ajuste de los datos de alarmas comienza
en el presente ejemplo primeramente entre el sistema de estaciones
de base, por ejemplo BSS11, y las aplicaciones OF1, OF2 en el
centro de operación y mantenimiento OMC1 en paralelo y sigue a
continuación entre el centro de operación y mantenimiento OMC1 y
los centros de gestión de red superiores NMC1, NMC2 en paralelo. Al
final de estos procesos está de nuevo actualizada la situación en
cuanto a errores tanto en el OMC como también en el NMC. El proceso
de realineamiento puede evidentemente estar limitado también a la
actualización de los datos de alarma entre agente y gestores en dos
niveles de gestión inmediatamente contiguos, por ejemplo nivel B y
nivel A.
La figura 3 muestra, en representación
esquemática, la estructura de agente AG y gestor MA1, MA2 con los
equipos necesarios para ejecutar simultáneamente - para dos o más
gestores - o en serie - para sólo un gestor - los procesos de
realineamiento que corren. Cada gestor MA1, MA2 y agente AG dispone
de un equipo de control M-CTR o bien
A-CTR, que puede generar y evaluar los mensajes para
el ajuste de datos de alarmas. Igualmente presentan equipos
emisores/receptores - no representados - para emitir y recibir
mensajes, así como equipos de memoria para memorizar los datos de
alarmas y otras informaciones útiles y de señalización.
Entonces insertan los equipos de control
M-CTR de los gestores MA1, MA2 en el correspondiente
mensaje de solicitud para transmitir los datos de alarma a través
del agente una información de correlación, que es inequívoca,
utilizada para asignar la solicitud a mensajes enviados a
continuación y da lugar a la transmisión al agente. Además,
insertan los equipos M-CTR de los gestores MA1, MA2
para el control del ajuste de los datos de alarma uno o varios
parámetros par en cada mensaje de solicitud individualmente, para
solicitar específicamente alarmas caracterizadas por diversos
valores de parámetros. El correspondiente mensaje de solicitud se
envía con los parámetros par al agente AG. Sólo mediante la
funcionalidad de alineamiento parametrizable según la invención
pueden lograrse por ejemplo una priorización de las alarmas y/o un
control activo de la secuencia de las alarmas solicitadas.
El equipo de control A-CTR del
agente AG recibe el correspondiente mensaje con los parámetros par,
los evalúa e inicia el realineamiento con los gestores MA1, MA2,
enviando de retorno las alarmas solicitadas específicamente por los
gestores. Entonces se utiliza la información de correlación
inequívoca inscrita por los gestores MA1, MA2 en el mensaje de
solicitud, para la correlación de las solicitudes, y se envía en
cada caso un mensaje con otra información de correlación para
asignar los mensajes (alarm notifications) enviados a continuación
por el agente al alineamiento iniciado en cada caso en el siguiente
nivel de gestión superior. También la restante información de
correlación es inequívoca. Mediante la utilización de las
informaciones de correlación es posible una asignación inequívoca
de realineamientos realizados simultáneamente o en serie con varios
gestores o un gestor individual.
Especialmente la combinación de la funcionalidad
básica - utilización de las informaciones de correlación - con la
funcionalidad de alineamiento parametrizable da lugar a un
procedimiento y sistema de comunicación especialmente efectivo, que
da lugar a un aprovechamiento óptimo de los recursos de transmisión
sobre la interfaz de la relación agente-gestor, así
como a una puesta a disposición lo más rápida posible sólo de los
datos de alarma de las alarmas activas deseados por el gestor para
el siguiente nivel de gestión superior. El aprovechamiento de
recursos, la duración y la flexibilidad siguen optimizándose en
consecuencia en el sistema de comunicaciones perfeccionado según la
invención respecto a la funcionalidad básica. Esto es válido además
no sólo para la gestión de alarmas, sino en general para un ajuste
de datos.
A elección pueden utilizarse a la vez en el
agente AG varias funciones de filtrado EFD1, EFD2 (Event Forwarding
Discriminators, discriminadores de retransmisión de sucesos) que
pueden asignarse en cada caso a los gestores MA1, MA2 y controlarse
por los mismos con criterios de filtrado para los mensajes generados
por el agente AG, con lo que los mensajes con los datos de alarma
sólo pueden enrutarse cuando se cumplen los criterios de filtrado
relativos a los gestores MA1, MA2. El equipo de control
M-CTR del gestor es capaz de establecer tales
funciones de filtrado en el agente AG, de borrarlas y de fijar los
criterios de filtrado para poder controlar el flujo de mensajes en
función de sus exigencias individuales. Por ello puede presentarse
el caso de que el ajuste de las funciones de filtrado sea distinto
de gestor a gestor, con lo que mediante los procesos de
realineamiento que corren simultáneamente pueden tratarse en cuanto
a contenido diversas alarmas con los correspondientes datos de
alarma.
La figura 4 muestra el flujo de mensajes entre
un agente AG, en el ejemplo representado en la figura 1 el centro
de operación y mantenimiento OMC1, o en el ejemplo representado en
la figura 2 el sistema de estaciones de base BSS11 - y los gestores
MA1, MA2 … MAn - en el ejemplo de la figura 1 los distintos centros
de gestión NMC1, NMC2 o en el ejemplo de la figura 2 las distintas
aplicaciones OF1, OF2.
El flujo de mensajes se realiza ventajosamente
utilizando mensajes estandarizados
M-EVENT-REPORT, que se envían como
consecuencia de una "solicitud"
M-ACTION-Request iniciada al
principio. Estos son servicios genéricos estandarizados CMISE
(Common Management Information Service Element, elemento del
servicio de información de gestión común) definidos según
ITU-T X.710. La ITU-T X.733 define
el contenido de una transmisión de alarmas estandarizada (alarm
report), que se ejecuta según los servicios
M-EVENT-REPORT. Las informaciones de
correlación se inscriben en los mensajes o bien en determinados
campos de mensajes. El ejemplo de la figura 4 muestra el flujo de
mensajes sólo en base a mensajes individuales, pudiendo transmitirse
los mismos en paralelo entre el agente AG y los gestores MA1, MA2 o
en serie entre el agente AG y el gestor individual MA1, tal como se
sabe ya por ejemplo por la DE 198 01 785.
Aquí se utilizan en el ejemplo de ejecución aquí
representado, por ejemplo un ejemplo de alineamiento de alarmas, en
particular las siguientes características especificadas en el
estándar ITU X.721.
- \bullet
- Cualquier notificación estandarizada relativa a un procedimiento de alineamiento (notificación de alarma, notificación de cambio de estado, notificación de cambio de valor de atributo, notificación de creación de objeto, notificación de borrado de objeto) contiene como parámetro (atributo) opcional el texto adicional (Additional text).
- \bullet
- La definición del parámetro "Additional text" (del tipo GraphicString, es decir, secuencia de caracteres) contiene la cláusula "Conceptos de coincidencia para igualdad, secuencias secundarias" (“MATCHES FOR EQUALITY, SUBSTRINGS”).
Según el estándar ITU-T X.722,
puede probarse este atributo en cuanto a si existe una determinada
secuencia secundaria de caracteres (SUBSTRING). El resultado de la
prueba puede utilizarse, en particular en instancias EFD o LOG,
también como criterio de filtrado para aquellas notificaciones que
contienen este atributo.
La secuencia del proceso de alineamiento a modo
de ejemplo se describirá ahora en base a las órdenes utilizadas.
En el funcionamiento normal contiene el ajuste
de filtrado por defecto o bien de consigna de cada instancia EFD en
el agente la cláusula aquí descrita como texto explícito:
- <Toda notificación con la secuencia de caracteres "ALIGNMENT" (alineamiento) en el campo de texto adicional, es eliminada por filtrado>.
Utilizando esta cláusula se evita, en particular
mediante los EFDs, que un gestor reciba aquellas notificaciones que
se envían como consecuencia de un proceso de alineamiento iniciado
por otro gestor.
Cada vez que un gestor (por ejemplo gestor 2)
inicia un proceso de alineamiento, sustituye el ajuste de filtrado
por defecto de su instancia EFD en el agente por un ajuste de
filtrado de alineamiento del tipo de la siguiente cláusula, que
aquí se describe de nuevo como texto explícito:
- <Toda notificación con los SUBSTRINGS (cadenas secundarias) "(aaaa- ALIGNMENT" o "(aaaa-ENDALIGNMENT" (alineamiento final) en el campo "Additional text" (texto adicional), no se elimina por filtrado>,
siendo aaaa un número que
caracteriza inequívocamente al gestor actual. Este número puede ser
otorgado por ejemplo por el agente cada vez que se establece un
enlace con el gestor
actual.
Cada vez que se establece de nuevo la
comunicación entre gestor (por ejemplo gestor 2) y agente, por
ejemplo tras una interrupción del enlace, envía este gestor una
instrucción estandarizada CMISE M-ACTION con los
siguientes parámetros al agente:
- Tipo de acción: (Action type:
- {}\hskip0.9cm\asteris"Solicitar sincronización de datos"{}\hskip1.3cm"requestDataSynchronisation").
\newpage
\global\parskip0.910000\baselineskip
- Información de acción: (Action information)
- \asteris"Manager-Handling" (managerHandle), (Operación del gestor), por ejemplo el valor {}\hskip0.4cm previamente definido aaaa). Este número inequívoco lo utiliza el agente como respuesta {}\hskip0.4cm a la Manager-Request (solicitud del gestor) actual para la identificación de todas las no- {}\hskip0.4cm tificaciones enviadas a continuación.
- *
- "Alignment-Handling" (operación de alineamiento) (alignmentHandle), por ejemplo con un valor abc. Este parámetro identifica para el gestor 2 inequívocamente el proceso actual de alineamiento. Tal como especifica el criterio 9 antes mencionado, debe asignar el gestor las notificaciones recibidas, referidas al alineamiento, al proceso de alineamiento correcto, aún cuando corran varios procesos de alineamiento propios simultáneamente.
- *
- "Datentyp" (tipo de datos) (dataType).
- \quad
- Este parámetro especifica el tipo de datos que deben sincronizarse entre agente y gestor, es decir, por ejemplo alarmas, estados o variaciones de configuración.
- *
- "unidades relacionadas" (relatedEntities)
- \quad
- Este parámetro indica de qué unidades de red proceden los datos solicitados (por ejemplo de una determinada región de red).
- *
- "intervalo de tiempo relacionado" (relatedTimeInterval).
- \quad
- Este parámetro especifica el marco de tiempo en el que han aparecido las notificaciones a enviar por el agente, por ejemplo todas las alarmas entre 18:00 y 22:00 horas.
- *
- "parámetros específicos" (specificParameters).
- \quad
- En función de los parámetros antes definidos "tipo de datos" (dataType), se definen en este campo parámetros específicos, por ejemplo para alarmas, sólo aquéllos con un determinado valor de perceivedSeverity (gravedad percibida).
Tras la confirmación de la solicitud mediante
una "M-ACTION Response", envía el agente una
tras otra todas las notificaciones correspondientes a todas las
instancias EFD existentes (según ITU-T estándar
X.734). A excepción de la última notificación, contiene cada
notificación enviada para el ajuste de datos o bien Alignment al
inicio del campo de texto adicional "Additional text", la
secuencia de caracteres
"(aaaa-ALIGNMENT-abc)",
teniendo aaaa y abc el significado antes explicado.
La última notificación enviada por el agente
para este proceso de alineamiento contiene al principio del campo
de texto adicional "Additional text" la secuencia de caracteres
"(aaaa-ENDALIGNMENT-abc)".
El ajuste de filtrado separado de la instancia
EFD del gestor 2 asegura que las notificaciones enviadas por el
agente para el alineamiento sólo puedan atravesar este único
discriminador. Incluso cuando otro gestor (gestor 1) inicie
simultáneamente un proceso de alineamiento, por ejemplo con el
inequívoco "alignmentHandle" = "bbbb", recibe el gestor 2
sólo "sus" notificaciones con el distintivo aaaa.
La figura 4 muestra un intercambio de mensajes a
modo de ejemplo entre un gestor a y un agente para un proceso de
alineamiento de alarmas, teniendo los parámetros
"managerHandle" por ejemplo el valor 78 y alignmentHandle por
ejemplo el valor 123.
Durante el proceso de alineamiento todas las
notificaciones que aparecen como nuevas y que no se envían como
consecuencia de un proceso de alineamiento en marcha en ese momento
y por lo tanto no contienen ninguna secuencia especial, pueden
atravesar básicamente todas las instancias EFD (por ejemplo
notificación 3 en la figura 4), es decir, llegan a todos los
gestores superiores.
El gestor a está también en condiciones de
reconocer el final de su proceso de alineamiento, aquí de la
notificación n con el distintivo inequívoco
"(aaaa-ENDALIGNMENT-abc)".
Al final del proceso de alineamiento, es decir,
tras recibir la notificación con el SUBSTRING (secuencia secundaria)
"(aaaa-ENDALIGNMENT-abc)",
repone el gestor a el ajuste de filtrado por defecto.
Cuando en el instante de la solicitud del gestor
no es necesario ningún alineamiento, porque por ejemplo no existe
ninguna alarma activa, recibe el gestor a en el
"M-ACTION-response" (Parameter
Action reply, respuesta de acción de parámetros) la correspondiente
indicación.
Alternativamente pueden ser también los EFDs
parte integrante de los correspondientes gestores o bien de una
unidad conectada entre gestor y agente. El propio gestor se descarga
así, debido a que eliminan por filtrado las informaciones no
destinadas a él antes de la llegada a él mediante el EFD asignado al
mismo.
El mismo proceder puede utilizarse también para
discriminadores LOG o estar configurado en otras unidades
comparables con capacidad de filtrado o bien ser parte de las
mismas.
Claims (11)
1. Procedimiento en una red de
telecomunicaciones para el ajuste de datos mediante una red de
gestión que presenta al menos dos niveles de gestión (A, B, C),
transmitiéndose, para el ajuste de datos entre al menos un agente
(AG) de un nivel de gestión (B, C) y al menos un gestor (MA1, MA2)
de un nivel de gestión siguiente superior (A, B), datos para el
ajuste de datos desde el agente (AG) al gestor (MA1, MA2), en el
que
el gestor (MA1, MA2) envía al agente (AG) uno o
varios mensajes de solicitud (M-ACTION Request) para
transmitir los datos de ajuste de datos,
el gestor (MA1, MA2) transmite informaciones de
correlación (managerHandle, 78) para una asignación de la
correspondiente solicitud a los datos de ajuste de datos enviados a
continuación por el agente (AG),
utilizándose los equipos de filtrado (EFD) que
reciben datos de varios gestores (MA1, MA2) y dejan pasar a su
través los datos de ajuste de datos en función de las informaciones
de correlación (managerHandle, 78) sólo al gestor (MA1, MA2) que
solicita los correspondientes datos de ajuste de datos,
caracterizado porque los equipos de
filtrado (EFD) eliminan por filtrado, utilizando un ajuste de
filtrado, todos los datos de comparación de datos en base a
informaciones de un campo adicional (Additional Text) de mensajes
(M-EVENT-REPORT) que contienen los
datos de ajustes de datos.
2. Procedimiento según la reivindicación
1,
en el que los datos de ajuste de datos a ajustar
durante el ajuste de datos son datos de alarmas, en particular de
alarmas activas, variaciones de estado o variaciones de
configuración.
3. Procedimiento según la reivindicación 1 o
2,
en el que las informaciones de correlación
(managerHandle, 78) se incluyen por el agente (AG) antes de la
transmisión de los mensajes
(M-EVENT-REPORT) que contienen los
datos de ajuste de datos a los equipos de filtrado (EFD) en un
campo adicional opcional (Additional Text) de los mensajes
(M-EVENT-REPORT) que contienen los
datos de ajuste de datos.
4. Procedimiento según una de las
reivindicaciones precedentes,
en el que se utilizan como equipos de filtrado
(EFD) discriminadores de retransmisión de sucesos o discriminadores
LOG.
5. Procedimiento según una de la
reivindicaciones 1 a 4,
en el que el ajuste del filtrado del gestor
(MA1, MA2) que solicita un ajuste de datos se repone, con referencia
a las informaciones del campo adicional (Additional Text) tras el
ajuste de datos, al ajuste de filtrado por defecto.
6. Procedimiento según una de las
reivindicaciones precedentes,
en el que se realiza un ajuste de filtrado del
equipo de filtrado (EFD) del gestor (MA1, MA2) que solicita un
ajuste de datos con referencia a informaciones de un campo adicional
(Additional Text) de los mensajes
(M-EVENT-REPORT) que contienen los
datos de ajuste de datos para eliminar por filtrado todos los datos
de ajuste de datos de otros gestores (MA1, MA2).
7. Procedimiento según una de la
reivindicaciones precedentes,
en el que todos los agentes (AG) que envían
datos de ajuste de datos, transmiten mensajes
(M-EVENT-REPORT) que contienen
datos de ajuste de datos con la información de correlación
(managerHandle, 78) en un campo adicional a los equipos de filtrado
(EFD) de todos los gestores (MA1, MA2).
8. Sistema de comunicaciones con una red de
gestión que presenta al menos dos niveles de gestión (A, B, C) como
gestores (MA1, MA2) y agentes (AG) para el ajuste de datos,
elementos de los agentes (AG) para enviar datos de ajuste de datos
a gestores superiores (MA1, MA2),
existiendo equipos de filtrado (EFD) que dejan
pasar datos de ajuste de datos, en función de informaciones de
correlación (managerHandle, 78) recibidas previamente de un gestor
(MA1, MA2), sólo al gestor (MA1, MA2) que solicita los
correspondientes datos de ajuste de datos,
caracterizado porque
\newpage
los equipos de filtrado (EFD) tienen un ajuste
de filtrado para eliminar por filtrado todos los datos de ajuste de
datos en base a informaciones de un campo adicional (Additional
Text) de mensajes (M-EVENT-REPORT)
que contienen los datos de ajuste de datos.
9. Sistemas de comunicaciones según la
reivindicación 8,
en el que en los gestores (MA1, MA2) están
puestos a disposición equipos para ajustar informaciones de filtrado
o bien de correlación (managerHandle, 78) en los equipos de
filtrado (EFD) asociados por parte de agentes.
10. Sistema de comunicaciones según la
reivindicación 8 ó 9,
en el que en los agentes (AG) están puestos a
disposición equipos para incluir las informaciones de correlación
(managerHandle, 78) en campos adicionales de datos de ajuste de
datos (M-EVENT-REPORT) que contienen
datos de ajuste de datos, que han de transmitirse a través de al
menos un equipo de filtrado (EFD) a un gestor (MA1, MA2).
11. Sistema de comunicaciones según una de las
reivindicaciones 8 a 10,
en el que los equipos de filtrado (EFD) son
discriminadores de retransmisión de sucesos o discriminadores
LOG.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| DE19940048 | 1999-08-24 | ||
| DE19940048A DE19940048A1 (de) | 1999-08-24 | 1999-08-24 | Generisches Alignment-Verfahren in einer Multi-Manager-Umgebung |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2281357T3 true ES2281357T3 (es) | 2007-10-01 |
Family
ID=7919390
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES00967531T Expired - Lifetime ES2281357T3 (es) | 1999-08-24 | 2000-08-18 | Procedimiento generico para el alineamiento en un entorno multigestor. |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US7047295B1 (es) |
| EP (1) | EP1206883B1 (es) |
| JP (1) | JP4673532B2 (es) |
| CN (1) | CN1214658C (es) |
| DE (2) | DE19940048A1 (es) |
| ES (1) | ES2281357T3 (es) |
| WO (1) | WO2001015461A1 (es) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE10337450A1 (de) * | 2003-05-31 | 2004-12-23 | Siemens Ag | Verfahren zur Behandlung von Parameteränderungen in einem Managementnetz eines zellularen Kommunikationssystems und Kommunikationssystem |
| DE10337464A1 (de) * | 2003-06-01 | 2004-12-23 | Siemens Ag | Verfahren zur Behandlung von Alarmen in einem Managementsystem eines Kommunikationsnetzes |
| DE102004015558A1 (de) * | 2004-03-30 | 2006-01-26 | Siemens Ag | Verfahren und Einrichtungen zur Verteilung von Management-Informationen in einem Managementnetz eines Kommunikationssystems |
| DE102004032208B4 (de) * | 2004-07-02 | 2008-04-03 | Nokia Siemens Networks Gmbh & Co.Kg | Verfahren zur gesicherten Datenübertragung in einem Managementsystem |
| US7647596B2 (en) * | 2005-12-08 | 2010-01-12 | Newisys, Inc. | Method for sharing a data store across event management frameworks and system comprising same |
| CN100579147C (zh) * | 2006-06-20 | 2010-01-06 | 中兴通讯股份有限公司 | 一种快速处理告警筛选的方法 |
| DE102006036566B4 (de) * | 2006-08-04 | 2009-02-19 | Nokia Siemens Networks Gmbh & Co.Kg | Vorabinformation von Managern über die Itf-N Schnittstelle |
| US7418710B1 (en) * | 2007-10-05 | 2008-08-26 | Kaspersky Lab, Zao | Processing data objects based on object-oriented component infrastructure |
| WO2020097808A1 (en) | 2018-11-14 | 2020-05-22 | Nokia Shanghai Bell Co., Ltd. | Trace management |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5706508A (en) | 1993-04-05 | 1998-01-06 | International Business Machines Corporation | System and method for monitoring SNMP tables |
| JP3465331B2 (ja) * | 1993-12-24 | 2003-11-10 | 株式会社日立製作所 | 階層型ネットワーク管理システム |
| IT1271326B (it) | 1994-12-23 | 1997-05-27 | Sits Soc It Telecom Siemens | Procedimento per il riallineamento automatico nel riporto di evento in un sistema di gestione e relativo sistema |
| GB2308777A (en) | 1995-12-28 | 1997-07-02 | Nokia Telecommunications Oy | Telecommunications network management |
| US5856999A (en) * | 1996-01-24 | 1999-01-05 | Motorola Inc. | Apparatus and method for data transmission on bonded data channels of a communications network utilizing a single serial communications controller |
| USH1896H (en) * | 1997-09-26 | 2000-10-03 | Dsc/Celcore, Inc. | Network management system server and method for operation |
| DE19752614C2 (de) | 1997-11-27 | 2000-04-13 | Siemens Ag | Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz |
| DE19801784C2 (de) | 1998-01-19 | 2000-03-30 | Siemens Ag | Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz |
| DE19801785C2 (de) * | 1998-01-19 | 2000-04-27 | Siemens Ag | Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz |
-
1999
- 1999-08-24 DE DE19940048A patent/DE19940048A1/de not_active Ceased
-
2000
- 2000-08-18 US US10/069,292 patent/US7047295B1/en not_active Expired - Lifetime
- 2000-08-18 WO PCT/DE2000/002827 patent/WO2001015461A1/de active IP Right Grant
- 2000-08-18 JP JP2001519054A patent/JP4673532B2/ja not_active Expired - Lifetime
- 2000-08-18 DE DE50014243T patent/DE50014243D1/de not_active Expired - Lifetime
- 2000-08-18 ES ES00967531T patent/ES2281357T3/es not_active Expired - Lifetime
- 2000-08-18 CN CN00814254.8A patent/CN1214658C/zh not_active Expired - Lifetime
- 2000-08-18 EP EP00967531A patent/EP1206883B1/de not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| CN1214658C (zh) | 2005-08-10 |
| US7047295B1 (en) | 2006-05-16 |
| DE50014243D1 (de) | 2007-05-24 |
| JP4673532B2 (ja) | 2011-04-20 |
| WO2001015461A1 (de) | 2001-03-01 |
| EP1206883B1 (de) | 2007-04-11 |
| EP1206883A1 (de) | 2002-05-22 |
| JP2003507976A (ja) | 2003-02-25 |
| CN1379959A (zh) | 2002-11-13 |
| DE19940048A1 (de) | 2001-08-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2258828T3 (es) | Procedimiento y sistema de comunicaciones para el tratamiento de alarmas mediante una red de gestion que presenta varios niveles de gestion. | |
| EP0880863B1 (en) | Routing of short messages for telecommunications networks | |
| US7215970B2 (en) | Messaging applications router | |
| US7865242B2 (en) | Patient device | |
| EP1116121A1 (en) | Interface system for integrated monitoring and management of network devices in a telecommunications network | |
| ES2281357T3 (es) | Procedimiento generico para el alineamiento en un entorno multigestor. | |
| EP0962105A1 (en) | An arrangement, a system and a method relating to management communication | |
| USH1897H (en) | Merged operations and maintenance center and method for operation | |
| ES2271016T3 (es) | Actualizacion de informaciones de harware especificas del fabricante en la interfaz independiente del fabricante omc-nmc en telefonia movil. | |
| KR20010034223A (ko) | 다수의 관리 층을 가진 관리 네트워크를 사용한 알람 처리방법 및 통신 시스템 | |
| US20030145037A1 (en) | Network management system using sms | |
| 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. | |
| ES2272833T3 (es) | Servidor para un sistema de telecomunicaciones y procedimiento para establecer una conexion de telecomunicaciones. | |
| CN113259185B (zh) | 网管代理以及网元管理平台 | |
| ES2293547T3 (es) | Procedimiento y equipos para la distribucion de informaciones de gestion en una red de gestion de un sistema de comunicaciones. | |
| Cisco | Other Network Management Tasks | |
| ES2221151T3 (es) | Sistema de conmutacion de telecomunicaciones con un control de supervision facilmente configurable. | |
| ES2259175T3 (es) | Procedimiento para el tratamiento de alarmas mediante una red de gestion con varios niveles en un sistema de comunicaciones. | |
| ES2389806T3 (es) | Procedimiento y dispositivos para hacer funcionar una red de gestión en caso de fallo de un gestor | |
| CN112887960B (zh) | 一种事件监控方法及装置 | |
| WO1999016274A1 (en) | Merged operations and maintenance center and method of operation | |
| ES2291781T3 (es) | Procedimiento y equipos para cambiar el modo de funcionamiento de un agente de una red de gestion. | |
| ES2656399T3 (es) | Gestión de red mejorada | |
| ES2639563T3 (es) | Sistema de procesamiento de eventos | |
| US7701860B2 (en) | Control plane stability in communications networks |