ES2425427T3

ES2425427T3 - Integración de elemento de red

Info

Publication number: ES2425427T3
Application number: ES09779610T
Authority: ES
Inventors: Siegfried Bauernfeind; Ramesh Shankar
Original assignee: Nokia Siemens Networks Oy
Current assignee: Nokia Solutions and Networks Oy
Priority date: 2009-06-02
Filing date: 2009-06-02
Publication date: 2013-10-15
Anticipated expiration: 2029-06-02
Also published as: EP2438709B1; US20120117109A1; WO2010139357A1; EP2438709A1

Abstract

Método (figura 3) para integrar un tipo de elemento de red con un sistema de gestión de elementos quecomprende: recuperar (303) una definición de tipo de elemento de red; e integrar (310) dicha definición de tipo de elemento de red con dicho sistema de gestión de elementos,estando el método caracterizado porque comprende: comprobar (301) una licencia para asegurarse de que un operador de red está autorizado a integrardicho tipo de elemento de red con el sistema de gestión de elementos; recuperar (303) una definición de alarma de tipo de elemento de red; e integrar (310) dicha definición de alarma de tipo de elemento de red con dicho sistema de gestión deelementos de manera que dicho sistema de gestión de elementos pueda soportar dicho tipo deelemento de red una vez que dicha definición de tipo de elemento de red y dicha definición de alarmade tipo de elemento de red se han integrado con dicho sistema de gestión de elementos.

Description

Integración de elemento de red

La presente invención se refiere a la gestión de elementos de red y en particular a la integración flexible de tipos de elementos de red con un sistema de gestión de elementos.

Una red de telecomunicación comprende varios elementos de red (NE), que oscilan normalmente desde unos cuantos NE a miles de NE dependiendo del tamaño de la red de telecomunicación implementada por un operador de red, que proporcionan diversos servicios y funcionalidad en la red de telecomunicación convencional. Diferentes tipos de NE proporcionan diferentes servicios y funcionalidad, por ejemplo, la red de telecomunicación puede incluir encaminadores, multiplexores, estaciones base, conexiones cruzadas, etc. Los NE en una red de telecomunicación se gestionan normalmente mediante un sistema de gestión de elementos (EMS) y la red de telecomunicación global se gestiona normalmente mediante un sistema de gestión de red (NMS).

El EMS comprende uno o más servidores que se conectan de manera operativa a los NE para proporcionar la capacidad de gestionar los NE en la red de telecomunicación. El NMS también es un servidor, o de nuevo más normalmente un grupo de servidores, que está situado jerárquicamente por encima del EMS para proporcionar una funcionalidad de gestión de red.

Para permitir que el EMS gestione los diferentes tipos de NE, el EMS se instala con una versión de lanzamiento de software que incluye al menos la definición de cada uno de los diferentes tipos de NE junto con las definiciones de alarma de cada uno de los diferentes tipos de NE.

Por consiguiente, para permitir la adición de nuevos tipos de NE a la red de telecomunicación, el operador de red debe solicitar que el productor del software de EMS incorpore el soporte para el nuevo tipo de NE en la siguiente versión de lanzamiento de software de EMS. Entonces, el productor del software de EMS desarrollará, probará y publicará una nueva versión de lanzamiento de software de EMS que incorpore los datos necesarios para que el EMS pueda soportar y gestionar el nuevo tipo de NE.

Sin embargo, un problema con el proceso de desarrollo, prueba e instalación nuevos lanzamientos de software para el EMS es que tiene un ciclo de vida a largo plazo, lo que significa que no hay flexibilidad para que el operador de red añada nuevos tipos de NE diferentes a su red de telecomunicación. En otras palabras, el operador de una red de telecomunicación tendrá que esperar una cantidad de tiempo considerable, normalmente de seis a doce meses, para que se desarrolle, se pruebe, se apruebe y se instale el nuevo lanzamiento de software de EMS en el EMS del operador de red.

Por tanto, en el sistema convencional el operador de red no tiene flexibilidad a la hora de añadir un nuevo tipo de NE diferente a su red de telecomunicación. Por ejemplo, si el operador de red desea añadir un nuevo tipo de NE adicional a su red para un proyecto específico, entonces el operador de red tendrá que esperar un periodo de tiempo sustancial hasta que se desarrolle, se apruebe y se instale un nuevo lanzamiento de software de EMS antes de poder proceder al proyecto. Esto es evidentemente desventajoso para el operador de red.

Además, para instalar un nuevo lanzamiento de software de EMS que incluya el soporte para el nuevo tipo de NE, el sistema de EMS debe ponerse fuera de servicio mientras se realiza la instalación del nuevo lanzamiento de software de EMS. Por tanto, la red de telecomunicación se interrumpirá y si se produce un error con la instalación entonces hay un riesgo de que se produzca una interrupción prolongada en la red de telecomunicación. Por tanto, es necesario permitir que un operador de red pueda añadir flexiblemente, ad hoc de manera eficaz, nuevos tipos de NE a su red de telecomunicación y tenga la capacidad de gestionar esos nuevos tipos de NE sin tener que esperar un periodo de tiempo sustancial para que se desarrolle e instale un nuevo lanzamiento de software de EMS.

El documento US 6226788 B1 da a conocer un sistema de gestión de red para gestionar una pluralidad de dispositivos de red que tienen una pluralidad de tipos de dispositivos. Cada dispositivo de red está asociado con un valor de tipo de dispositivo, y cada dispositivo de red tiene un mapeador de dispositivo asociado. Los mapeadores de dispositivos se almacenan en una estructura jerárquica que refleja una relación funcional o relación familiar de los dispositivos. Las funciones que van a llevarse a cabo por uno o más dispositivos se expresan como una pluralidad de componentes de programa ejecutable. Cada mapeador de dispositivo asocia un valor de tipo de dispositivo con una o más clases reemplazadas en la componente de programa ejecutable, y una o más clases de reemplazo. En el tiempo de ejecución se adquieren valores de tipo de dispositivo para cada dispositivo en la red gestionada. Para cada tipo de dispositivo se reúnen una o más funciones usando sólo los componentes de programa ejecutable asociados con ese tipo de dispositivo. Basándose en el mapeador de dispositivo de ese tipo de dispositivo, las clases en los componentes de programa ejecutable se reemplazan y se sustituyen las clases de reemplazo. Como resultado, en el tiempo de ejecución el sistema de gestión de red integra en su seno componentes de programa ejecutable para nuevos dispositivos.

Según un primer aspecto de la presente invención se proporciona un método para integrar un tipo de elemento de red con un sistema de gestión de elementos que comprende: recuperar una definición de tipo de elemento de red; recuperar una definición de alarma de tipo de elemento de red; integrar la definición de tipo de elemento de red con el sistema de gestión de elementos; e integrar la definición de alarma de tipo de elemento de red con el sistema de gestión de elementos de manera que el sistema de gestión de elementos pueda soportar el tipo de elemento de red una vez que la definición de tipo de elemento de red y la definición de alarma de tipo de elemento de red se han integrado con el sistema de gestión de elementos.

Por tanto, la presente invención permite integrar ventajosamente un tipo de elemento de red con el sistema de gestión de elementos de una manera sustancialmente ad hoc cuando un operador de red desea implantar el tipo de elemento de red en su red de telecomunicación.

El método para integrar el tipo de elemento de red con el sistema de gestión de elementos requiere que la definición del tipo de elemento de red se recupere junto con la definición de alarma del tipo de elemento de red. Tanto la definición como la definición de alarma se integran con el sistema de gestión de elementos de modo que pueda soportarse un elemento de red del tipo de elemento de red que el operador de red desea implantar en su red de telecomunicación. En otras palabras, para soportar, por ejemplo gestionar, el nuevo tipo de elemento de red, el sistema de gestión de elementos debe conocer la definición del tipo de elemento de red, por ejemplo para una gestión de configuración, y la definición de alarma del tipo de elemento de red, por ejemplo para una gestión de averías. Por tanto, el método de la presente invención permite ventajosamente integrar el tipo de elemento de red con el sistema de gestión de elementos sin que sea necesario desarrollar, probar, aprobar e instalar una nueva versión del software de sistema de gestión de elementos para soportar el nuevo tipo de elemento de red.

La etapa de recuperación de la definición de tipo de elemento de red puede comprender recuperar la definición de tipo de elemento de red desde una base de datos o sistema de archivos en el sistema de gestión de elementos o desde una base de datos conectada operativamente al sistema de gestión de elementos. Por tanto, la definición del tipo de elemento de red puede almacenarse en el sistema de gestión de elementos o en una base de datos externa desde la que puede recuperarse la definición.

La definición de tipo de elemento de red puede comprender un conjunto de atributos y parámetros que definen el tipo de elemento de red, pudiendo comprender la etapa de integración del tipo de elemento de red con el sistema de gestión de elementos: generar sentencias de lenguaje de consulta estructurado basándose en la definición de tipo de elemento de red, pudiendo comprender la definición atributos y parámetros específicos; y ejecutar las sentencias de lenguaje de consulta estructurado para integrar los atributos y parámetros con la al menos una base de datos en el sistema de gestión de elementos. El método también puede comprobar que la definición de tipo de elemento de red está en un formato de archivo correcto antes de generar las sentencias de lenguaje de consulta estructurado.

Por consiguiente, la definición del tipo de elemento de red puede ser un archivo que incluye los atributos y parámetros que definen el tipo de elemento de red y la definición del tipo de elemento de red se integra con el sistema de gestión de elementos escribiendo los atributos y parámetros en las bases de datos apropiadas en el sistema de gestión de elementos. Permitiendo que los atributos y parámetros que definen el tipo de elemento de red se escriban o se integren directamente en las bases de datos apropiadas del sistema de gestión de elementos, entonces no es necesario que el sistema de gestión de elementos se ponga fuera de línea o experimente cualquier tiempo de inactividad cuando se integra el nuevo tipo de elemento de red con el sistema de gestión de elementos.

La definición de tipo de elemento de red puede ser un archivo de lenguaje de marcado extensible (XML).

El método puede comprender además: copiar la definición de tipo de elemento de red en un directorio en el sistema de gestión de elementos en el que puede almacenarse permanentemente la definición de tipo de elemento de red. Por tanto, si es necesario, el tipo de elemento de red puede reintegrarse con el sistema de gestión de elementos, por ejemplo, después de una actualización de sistema del sistema de gestión de elementos, ya que la definición del tipo de elemento de red se almacena en un directorio en el sistema de gestión de elementos que no se ve afectado por ninguna actualización de sistema futura.

El método puede comprender además: actualizar un archivo de registro cronológico almacenado en el sistema de gestión de elementos con detalles del tipo de elemento de red integrado de modo que pueda mantenerse un registro cronológico de los cambios realizados en el sistema de gestión de elementos.

La etapa de integración de la definición de tipo de elemento de red puede comprender: comprobar que el tipo de elemento de red no existe en una base de datos en el sistema de gestión de elementos. Por tanto, para impedir que el mismo tipo de elemento de red se integre con el sistema de gestión de elementos más de una vez, el método puede comprobar que el tipo de elemento de red que va a integrarse no existe actualmente en el sistema de gestión de elementos.

El método puede comprender además: crear un conjunto de archivos de icono para el tipo de elemento de red en una base de datos en el sistema de gestión de elementos o bien renombrando un conjunto de archivos de icono por defecto renombrándose el conjunto de archivos de icono por defecto basándose en el tipo de elemento de red o bien añadiendo un nuevo conjunto de archivos de icono específico para el tipo de elemento de red. Para que el operador de red visualice una representación gráfica de su red de telecomunicación cuando realiza funciones de monitorización y gestión, se asignará preferiblemente al tipo de elemento de red un conjunto de iconos. Los iconos para el tipo de elemento de red pueden ser un conjunto de iconos por defecto que se usan para todos los tipos de elementos de red integrados con el sistema de gestión de elementos usando el método de la presente invención o un conjunto de iconos específicos para el tipo de elemento de red que está integrándose. Si va a usarse el conjunto de iconos por defecto, entonces se hace una copia del conjunto de archivos de icono por defecto que luego se renombra para incluir al menos parte del nombre del tipo de elemento de red. Si va a usarse un nuevo conjunto de iconos específico para el tipo de elemento de red, entonces se escriben en el directorio apropiado en el sistema de gestión de elementos y el nombre de archivo de los nuevos iconos incluye al menos parte del nombre del tipo de elemento de red.

El método puede comprender además: comprobar que existe una licencia que autoriza al operador de red a usar la funcionalidad para integrar un tipo de elemento de red con el sistema de gestión de elementos.

El método puede comprender además: obtener una copia de un archivo de configuración de menú desde un directorio en el sistema de gestión de elementos; actualizar la copia del archivo de configuración de menú con detalles del tipo de elemento de red; y almacenar la copia actualizada del archivo de configuración de menú en el directorio en el sistema de gestión de elementos de manera que el archivo de configuración de menú actualizado pueda cargarse a un dispositivo informático conectado operativamente al sistema de gestión de elementos. Normalmente, el personal en el centro de control de un operador de red usará un dispositivo informático externo, tal como un ordenador personal basado en UNIX o Windows, para conectarse con el sistema de gestión de elementos para monitorizar la red, recuperar datos de la red, visualizar detalles de la red, etc. Por consiguiente, la configuración de menú que define las opciones de menú a las que puede acceder el personal que usa el dispositivo informático externo se actualizará preferiblemente con detalles del nuevo tipo de elemento de red que se cargarán en su dispositivo informático externo cuando el personal inicie sesión la próxima vez en el sistema de gestión de elementos. Por tanto, el personal que usa el dispositivo informático externo podrá acceder preferiblemente al nuevo tipo de elemento de red desde su dispositivo informático externo.

El archivo de configuración de menú puede ser un archivo de lenguaje de marcado extensible (XML) y los detalles del tipo de elemento de red pueden comprender atributos que definen una interfaz de usuario gráfica (GUI) de web para el tipo de elemento de red. Por tanto, el personal puede visualizar una GUI de web para el tipo de elemento de red que se ha integrado con el sistema de gestión de elementos que permite al personal acceder e interactuar con elementos de red de este tipo de elemento de red.

La etapa de recuperación de la definición de alarma de tipo de elemento de red puede comprender recuperar un archivo zip, comprendiendo el archivo zip al menos un archivo que define al menos datos de mapeos de TRAP y datos de catálogo de alarma; y la etapa de integración de la definición de alarma de tipo de elemento de red con el sistema de gestión de elementos puede comprender: extraer el al menos un archivo del archivo zip; actualizar el sistema de gestión de elementos según datos en el al menos un archivo extraído.

Tal como se describió anteriormente en el presente documento, la definición de alarma del tipo de elemento de red debe recuperarse e integrarse con el sistema de gestión de elementos de modo que el sistema de gestión de elementos pueda realizar la gestión de averías necesaria del tipo de elemento de red. Preferiblemente, la definición de alarma para el tipo de elemento de red incluye al menos un archivo, pero más normalmente un conjunto de archivos, que definen el manejo y gestión de alarma para el tipo de elemento de red. Por tanto, la definición de alarma se proporciona preferiblemente como único archivo zip para reducir la capacidad requerida para almacenar múltiples definiciones de alarma que corresponden a varios tipos de elementos de red y empaquetar los datos que definen la definición de alarma para cada tipo de elemento de red como único archivo zip para facilitar el uso.

La etapa de recuperación de la definición de alarma TRAP de elemento de red puede comprender recuperar al menos un archivo que define al menos datos de mapeos de TRAP y datos de catálogo de alarma; y la etapa de integración de la definición de alarma de tipo de elemento de red con el sistema de gestión de elementos puede comprender: actualizar el sistema de gestión de elementos según los datos en el al menos un archivo recuperado. Alternativamente, los datos que definen la definición de alarma para el tipo de elemento de red pueden definirse por al menos uno, pero normalmente varios, archivos individuales en vez de cómo único archivo zip.

En cualquiera de los casos anteriores en los que la definición de alarma se proporciona como archivo zip o archivos individuales, los archivos de definición de alarma incluyen preferiblemente datos de mapeos de TRAP y datos de catálogo de alarma que cuando se integran con el sistema de gestión de elementos permiten que el sistema de gestión de elementos realice una funcionalidad de gestión de averías.

La etapa de actualización del sistema de gestión de elementos puede comprender: instalar los datos de mapeos de TRAP en un directorio en el sistema de gestión de elementos; e instalar los datos de catálogo de alarma en un directorio en el sistema de gestión de elementos. La definición de alarma del tipo de elemento de red puede integrarse con el sistema de gestión de elementos extrayendo los archivos de definición de alarma a los directorios apropiados en el sistema de gestión de elementos y añadiendo los datos necesarios a las bases de datos apropiadas en el sistema de gestión de elementos.

El método puede comprender además: generar la definición de alarma de tipo de elemento de red; y almacenar la definición de alarma de tipo de elemento de red en un directorio en el sistema de gestión de elementos. La etapa de generación de la definición de alarma de tipo de elemento de red puede comprender: recuperar un archivo de base de información de gestión; generar un archivo de valores separados por coma basándose en el archivo de base de información de gestión; editar el archivo de valores separados por coma para incluir valores para el tipo de elemento de red; generar un archivo de datos de mapeo de TRAP basándose en el archivo de valores separados por coma editado; y generar al menos un archivo de catálogo de alarma basándose en el archivo de valores separados por coma editado.

La definición de alarma que se recupera para cada tipo de elemento de red se ha generado previamente y almacenado en una base de datos o en un directorio que está o bien en el sistema de gestión de elementos o bien en un dispositivo informático conectado operativamente al sistema de gestión de elementos. El archivo de mapeo de TRAP usado por el sistema de gestión de elementos para la gestión de averías puede generarse basándose en al menos un archivo de base de información de gestión, usándose el archivo de base de información de gestión para generar un archivo de valores separados por coma que a su vez se usa para generar el archivo de mapeo de TRAP. Preferiblemente, los archivos resultantes que forman conjuntamente la definición de alarma del tipo de elemento de red se comprimen en un único archivo zip y se almacenan en un directorio en el sistema de gestión de elementos.

La etapa de generación de la definición de alarma de tipo de elemento de red puede realizarse en el sistema de gestión de elementos o puede realizarse en un dispositivo informático conectado operativamente al sistema de gestión de elementos. Preferiblemente, la definición de alarma para el tipo de elemento de red se genera en un dispositivo informático y se transfiere al sistema de gestión de elementos para cuando el tipo de elemento de red va a integrarse con el sistema de gestión de elementos. Sin embargo, la definición de alarma puede generarse en el sistema de gestión de elementos.

El método puede comprender además: comprobar que la definición de alarma de tipo de elemento de red existe en el sistema de gestión de elementos. Para integrar el tipo de elemento de red con el sistema de gestión de elementos, éste debe estar disponible para su recuperación de modo que el tipo de elemento de red pueda integrarse satisfactoriamente y por tanto el método pueda comprobar que la definición de alarma existe antes de proceder a integrar el tipo de elemento de red con el sistema de gestión de elementos.

Según un segundo aspecto de la presente invención se proporciona un servidor adaptado para: recuperar una definición de tipo de elemento de red; recuperar una definición de alarma de tipo de elemento de red; integrar la definición de tipo de elemento de red con el sistema de gestión de elementos; e integrar la definición de alarma de tipo de elemento de red con el sistema de gestión de elementos de manera que el sistema de gestión de elementos pueda soportar el tipo de elemento de red una vez que la definición de tipo de elemento de red y la definición de alarma de tipo de elemento de red se han integrado con el sistema de gestión de elementos.

La definición de tipo de elemento de red puede comprender un conjunto de atributos y parámetros que definen el tipo de elemento de red, estando el servidor adaptado adicionalmente para: comprobar que la definición de tipo de elemento de red está en un formato de archivo correcto; generar sentencias de lenguaje de consulta estructurado basándose en la definición de tipo de elemento de red; y ejecutar las sentencias de lenguaje de consulta estructurado para integrar los atributos y parámetros que definen el tipo de elemento de red en al menos una base de datos en el sistema de gestión de elementos.

La definición de alarma de tipo de elemento de red es un archivo zip, comprendiendo el archivo zip al menos un archivo que define al menos datos de mapeos de TRAP y datos de catálogo de alarma; y el servidor está adaptado además para: extraer el al menos un archivo del archivo zip; actualizar el sistema de gestión de elementos según datos en el al menos un archivo extraído.

El servidor puede estar adaptado además para: instalar los datos de mapeos de TRAP en un directorio en el sistema de gestión de elementos; e instalar los datos de catálogo de alarma en un directorio en el sistema de gestión de elementos. El servidor también puede estar adaptado para realizar todas las etapas del método de la invención descritas en el presente documento.

Un experto en la técnica apreciará que el servidor pueda adaptarse instalando el código ejecutable legible por ordenador apropiado y correspondiente que permita al servidor realizar las funciones requeridas.

Según un tercer aspecto de la presente invención, se proporciona un producto de programa informático que comprende código ejecutable legible por ordenador para: recuperar una definición de tipo de elemento de red; recuperar una definición de alarma de tipo de elemento de red; integrar la definición de tipo de elemento de red con el sistema de gestión de elementos; e integrar la definición de alarma de tipo de elemento de red con el sistema de gestión de elementos de manera que el sistema de gestión de elementos pueda soportar el tipo de elemento de red una vez que la definición de tipo de elemento de red y la definición de alarma de tipo de elemento de red se han integrado con el sistema de gestión de elementos.

La definición de tipo de elemento de red puede comprender un conjunto de atributos y parámetros que definen el tipo de elemento de red, comprendiendo el producto de programa informático además código ejecutable legible por ordenador para: comprobar que la definición de tipo de elemento de red está en un formato de archivo correcto; generar sentencias de lenguaje de consulta estructurado basándose en la definición de tipo de elemento de red; y ejecutar las sentencias de lenguaje de consulta estructurado para integrar los atributos y parámetros que definen el tipo de elemento de red en al menos una base de datos en el sistema de gestión de elementos.

La definición de alarma de tipo de elemento de red puede ser un archivo zip, comprendiendo el archivo zip al menos un archivo que define al menos datos de mapeos de TRAP y datos de catálogo de alarma; y el producto de programa informático comprende además código ejecutable legible por ordenador para: extraer el al menos un archivo del archivo zip; actualizar el sistema de gestión de elementos según datos en el al menos un archivo extraído.

El producto de programa informático puede comprender además código ejecutable legible por ordenador para: instalar los datos de mapeos de TRAP en un directorio en el sistema de gestión de elementos; e instalar los datos de catálogo de alarma en un directorio en el sistema de gestión de elementos.

Según un cuarto aspecto de la presente invención se proporciona un método para eliminar un tipo de elemento de red de un sistema de gestión de elementos que comprende: comprobar si existe cualquier instancia de tipo de elemento de red en el sistema de gestión de elementos; y si no existe ninguna instancia de tipo de elemento de red, eliminar los atributos y parámetros que definen el tipo de elemento de red de al menos una base de datos en el sistema de gestión de elementos.

Según un quinto aspecto de la presente invención se proporciona un servidor adaptado para: comprobar si existe cualquier instancia de tipo de elemento de red en un sistema de gestión de elementos; y si no existe ninguna instancia de tipo de elemento de red, eliminar los atributos y parámetros que definen el tipo de elemento de red de al menos una base de datos en el sistema de gestión de elementos.

Según un sexto aspecto de la presente invención se proporciona un producto de programa informático que comprende código ejecutable legible por ordenador para: comprobar si existe cualquier instancia de tipo de elemento de red en un sistema de gestión de elementos; y si no existe ninguna instancia de tipo de elemento de red, eliminar los atributos y parámetros que definen el tipo de elemento de red de al menos una base de datos en el sistema de gestión de elementos.

Por consiguiente, en una realización puede eliminarse un tipo de elemento de red del sistema de gestión de elementos eliminando la definición del tipo de elemento de red del sistema de gestión de elementos. El archivo de configuración de menú también puede actualizarse para eliminar los datos en relación con el tipo de elemento de red, los iconos para el tipo de elemento de red también pueden eliminarse y la definición de alarma (por ejemplo el archivo de mapeo de TRAP y los archivos de catálogo de alarma) también puede eliminarse del sistema de gestión de elementos.

Ahora se describirán realizaciones de la presente invención, sólo a modo de ejemplo, y con referencia a los dibujos adjuntos, en los que:

la figura 1 muestra un diagrama esquemático de una red de telecomunicación típica.

La figura 2 muestra un diagrama esquemático de la arquitectura de la presente invención según aspectos de la invención.

La figura 3 muestra un diagrama de flujo de mensajes para integrar un nuevo tipo de NE en un sistema de gestión de elementos según aspectos de la invención.

La figura 4 muestra un diagrama de flujo de mensajes para reintegrar los tipos de NE después de una actualización de sistema según aspectos de la invención.

La figura 5 muestra un diagrama de flujo de mensajes para borrar un tipo de NE del sistema de gestión de elementos según aspectos de la invención.

La figura 1 muestra un diagrama esquemático de una red 1 de telecomunicación típica implementada por un operador de red. Una red 1 de telecomunicación típica comprende una pluralidad de elementos 2 de red (NE), normalmente en el intervalo de cientos si no miles de NE 2, que proporcionan la funcionalidad y servicios en la red 1 de telecomunicación. Hay numerosos tipos diferentes de NE 2 disponibles, por ejemplo, encaminadores, estaciones base, multiplexores, etc., cada uno de los cuales proporciona una funcionalidad y servicios diferentes.

Los NE 2 se gestionan normalmente mediante un sistema 3 de gestión de elementos (EMS), que puede comprender uno o más servidores. El EMS 3 gestiona normalmente las funciones y capacidades en cada NE 2, lo que incluye, por ejemplo, gestión de averías, gestión de configuración, gestión de rendimiento, etc. Para gestionar la red de telecomunicación global, lo que incluye, por ejemplo, la gestión del tráfico entre los NE, el EMS se comunica con un sistema 4 de gestión de red (NMS) que se encuentra en un nivel jerárquicamente superior al EMS 3. El NMS 4 también comprende normalmente uno o más servidores y proporciona la funcionalidad para gestionar la red 1 de telecomunicación global.

Para que el EMS 3 pueda gestionar los diferentes tipos de NE que están presentes en la red 1 de telecomunicación, la definición y la definición de alarma del tipo de NE deben integrarse con el EMS 3. Tal como se describió anteriormente en el presente documento, esto se consigue convencionalmente desarrollando e instalando una versión de lanzamiento de software de EMS en el EMS 3 que incluya la información requerida.

Por consiguiente, si un operador de red deseara implantar un nuevo tipo de NE que no se soporta actualmente por el EMS 3, entonces el operador de red convencionalmente tendría que presentar una petición de cambio al proveedor de software de EMS para que el nuevo tipo de NE se incorpore en y se soporte por el EMS 3. El proveedor de software de EMS incorporará entonces el nuevo tipo de NE solicitado en el siguiente lanzamiento del software de EMS que tendrá normalmente un ciclo de vida de seis a doce meses. Por tanto, el operador de red tendrá que esperar un periodo de tiempo sustancial antes de poder usar el nuevo tipo de NE que necesita para un proyecto particular o proporcionar una funcionalidad particular en su red 1 de telecomunicación. Este proceso es evidentemente desventajoso para el operador de red ya que no hay flexibilidad a la hora de realizar adiciones nuevas a su red de telecomunicación. Además, una vez que el nuevo lanzamiento de software de EMS se ha aprobado para su lanzamiento e instalación en el EMS 3, entonces para instalar el nuevo lanzamiento de software de EMS, el EMS debe ponerse fuera de servicio para instalar el software, lo que provocará una interrupción en la red. Por tanto, si hay cualquier problema con la instalación del nuevo lanzamiento de software de EMS, entonces puede producirse un periodo prolongado de interrupción de la red dado que el EMS 3 estará fuera de línea durante ese periodo prolongado.

Por consiguiente, existe la necesidad de métodos y aparatos que permitan a un operador de red integrar nuevos tipos de NE en su red 1 de telecomunicación de una manera sustancialmente ad hoc sin necesidad de esperar a que se desarrolle, apruebe e instale un nuevo lanzamiento de software de EMS.

En las realizaciones de la presente invención, y con referencia a la figura 2, se proporciona un kit 5 de herramientas de integración de tipo de NE que proporciona la funcionalidad para integrar nuevos tipos 6 de NE en el EMS 3 cuando lo requiera el operador de red. El kit 5 de herramientas de integración de tipo de NE en las realizaciones se implementa como herramienta de línea de comandos en el EMS 3 que puede ser una herramienta de línea de comandos de aplicación Java.

Para integrar un nuevo tipo 6 de NE en el EMS 3, de modo que el nuevo tipo de NE pueda implantarse y usarse por el operador de red de una manera sustancialmente ad hoc, el kit 5 de herramientas de integración de tipo de NE realiza varias funciones que permiten integrar las definiciones del nuevo tipo 6 de NE con el EMS 3 actual sin necesidad de esperar a que se desarrolle, se pruebe y se instale un nuevo lanzamiento de software de EMS. Además, el kit 5 de herramientas de integración de tipo de NE de las realizaciones puede usarse para integrar el nuevo tipo 6 de NE mientras el EMS 3 está funcionando y por tanto el EMS 3 no tiene que ponerse fuera de línea tal como es el caso cuando se instala una nueva versión de lanzamiento de software de EMS. Por consiguiente, durante la integración del nuevo tipo 6 de NE en el EMS 3, el rendimiento, el funcionamiento, el uso esperado de recursos de sistema o capacidades del EMS 3 ventajosamente no se verán afectados.

En las realizaciones de la presente invención, para integrar el nuevo tipo de NE en el EMS 3, entonces deben proporcionarse al EMS 3 los datos de definición del tipo de NE y, para la gestión de averías, los datos de definición de alarma del tipo de NE. El kit 5 de herramientas de integración de tipo de NE también puede realizar una comprobación de licencia, para asegurarse de que está disponible la licencia necesaria que permite al operador de red añadir nuevos tipos 6 de NE en el tiempo de ejecución, la provisión y generación de los archivos de definición de alarma incluyendo, por ejemplo, archivos de mapeo de TRAP y de catálogo, la instalación de iconos y la actualización de configuraciones de menú en el EMS 3.

El kit 5 de herramientas de integración de tipo de NE controla el procedimiento de integrar un nuevo tipo 6 de NE y se invoca en el EMS 3 preferiblemente a través de una herramienta de línea de comandos de Java.

El kit 5 de herramientas de integración de tipo de NE requiere dos componentes principales para poder integrar el nuevo tipo 6 de NE con el EMS 3. El primer componente es una definición del nuevo tipo de NE que va a añadirse, siendo la definición del tipo de NE preferiblemente en forma de archivo de lenguaje de marcado extensible (XML). El segundo componente principal requerido por el kit 5 de herramientas de integración de tipo de NE es la definición de alarma que incluye preferiblemente archivos de catálogo de alarma y archivos de mapeo de TRAP para el nuevo tipo 6 de NE.

La definición del tipo de NE se genera preferiblemente como archivo XML y se almacena en una base de datos en el EMS 3 o en una base de datos que está conectada operativamente al EMS 3. El archivo XML contiene diversos elementos de datos que definen el tipo 6 de NE en forma de parámetros y atributos que cuando se integran con el EMS 3 permiten que el EMS 3 gestione, soporte o identifique el nuevo tipo 6 de NE. A continuación se proporciona una plantilla para un archivo XML típico según una realización de la presente invención, en la que los marcadores de posición marcados con “$...” deben sustituirse por los valores reales asociados con el nuevo tipo 6 de NE.

<neType name=”$NE_TYPE”> <comment> $COMMENT </comment> <snmpPort value=”$SNMP_PORT”/> <shellAccess>

/> </webGuiData> </neType>

Los archivos XML para los nuevos tipos de NE se almacenan en una base de datos que está conectada operativamente al EMS, que permite al kit 5 de herramientas de integración de tipo de NE localizar y/o recuperar el archivo de definición cuando el tipo 6 de NE está integrándose con el EMS 3.

Además de los atributos y parámetros descritos anteriormente, el archivo XML también puede comprender varias características, atributos y parámetros adicionales que definen el tipo de NE. Estos atributos y parámetros adicionales mostrados a continuación están provistos de valores estandarizados que se añaden automáticamente al conjunto de atributos para un nuevo tipo de NE.

El archivo de definición para el nuevo tipo 6 de NE también puede contener un atributo <productLine value=“OEM”/> que permite agrupar los tipos de NE integrados usando el kit 5 de herramientas de integración de tipo de NE según líneas de producto. El archivo de definición también puede contener un atributo <asynclntegratedType value=“true”/> que identifica el tipo 6 de NE como uno que se ha integrado con el EMS 3 usando el kit 5 de herramientas de integración de tipo de NE.

El kit 5 de herramientas de integración de tipo de NE se usa para integrar el nuevo tipo 6 de NE en el EMS 3 mientras el EMS 3 está operativo y siempre que el operador de red desee implementar el nuevo tipo 6 de NE en su red 1 de telecomunicación. El kit 5 de herramientas de integración de tipo de NE localiza la definición en cuestión del tipo 6 de NE, que está preferiblemente en forma de archivo XML, desde la base de datos, o más normalmente desde un sistema de archivos local que almacena los archivos de definición de tipo de NE. El kit 5 de herramientas de integración de tipo de NE comprueba el archivo XML frente a una definición de esquema de XML (XSD) correspondiente para determinar que el archivo XML están en el formato correcto. Si el archivo XML está en el formato apropiado, el kit de herramientas de integración de tipo de NE genera sentencias de lenguaje de consulta estructurado (SQL) basándose en los parámetros, características y atributos proporcionados en el archivo XML.

El EMS 3 comprende preferiblemente una o más bases 8 de datos que contienen diversos elementos de información y datos que permiten al EMS 3 funcionar y gestionar los NE 2 en la red 1 de telecomunicación. Una o más de estas bases de datos pueden comprender un espacio de tablas de gestión de configuración local (LCM) que incluye los diversos detalles de configuración de los tipos de NE que el EMS 3 soporta y puede gestionar. El espacio de tabla puede incluir, por ejemplo, una tabla “neFeatures” que almacena para cada tipo de NE un conjunto de atributos y parámetros de características que pueden usarse para determinar un perfil único para todas las instancias de NE del mismo tipo de NE. El espacio de tablas también puede incluir, por ejemplo, una tabla “neTypeCredentials” que almacena las credenciales por tipo de NE. El espacio de tablas puede incluir además, por ejemplo, una tabla “neTypeWebGui” para almacenar datos para lanzar una GUI (interfaz de usuario gráfica) de web para el tipo de NE si el tipo de NE soporta una o más GUI de web.

Después de que el kit 5 de herramientas de integración de tipo de NE haya generado las sentencias de SQL basándose en el archivo de definición de XML, establece una conexión con la base 8 de datos en el EMS 3 que incluye el espacio de tablas de LCM. Preferiblemente, la conexión a la base de datos es a través de conectividad con bases de datos desde Java (JDBC). Las sentencias de SQL se ejecutan de modo que todas las características, atributos y parámetros del nuevo tipo de NE se integran con las tablas de base de datos de LCM. Para conservar la integración del nuevo tipo de NE después de futuras mejoras de versiones de lanzamiento de software de EMS, el archivo XML que describe la definición del nuevo tipo 6 de NE también se copia en un directorio en el EMS 3 que no se ve afectado por ninguna actualización de sistema del EMS 3. Este archivo de definición almacenado permitirá reintegrar el tipo de NE con el EMS 3 después de cualquier actualización de sistema de este tipo, por ejemplo, la instalación de una nueva versión de lanzamiento de software de EMS, tal como se describirá a continuación adicionalmente.

Dado que los datos se recuperan de la base de datos de LCM dinámicamente por el EMS 3, entonces no hay necesidad de volver a arrancar o reiniciar el EMS para que el EMS 3 pueda soportar y gestionar el nuevo tipo 6 de NE que está integrándose con el EMS 3. Por tanto, la definición del nuevo tipo de NE puede integrarse ventajosamente con el EMS 3 sin ningún tiempo de inactividad del EMS 3.

Tal como se mencionó anteriormente, el kit 5 de herramientas de integración de tipo de NE también necesita integrar las definiciones de alarma, que incluyen preferiblemente archivos de catálogos de alarma y de mapeo de TRAP generados previamente para el nuevo tipo 6 de NE, en el EMS 3 de modo que el EMS 3 pueda realizar gestión de averías para el nuevo tipo de NE cuando esté operativo en la red 1 de telecomunicación del operador de red. Por ejemplo, en la gestión de averías el EMS 3 debe poder procesar alarmas y eventos entrantes desde instancias 6 del tipo de NE.

La gestión de averías en la red 1 de telecomunicación convencional se realiza normalmente usando el protocolo de gestión de red simple (SNMP) conocido. Por tanto, para que el EMS realice gestión de averías, también es necesario que se integren los archivos de catálogo y de mapeo de TRAP de alarma para el nuevo tipo 6 de NE con el EMS 3.

En SNMP, el NE usa un TRAP para informar de que se ha producido una alarma o evento en el NE a los sistemas de gestión. Tal como sabrá un experto en la técnica, el TRAP también puede conocerse simplemente como notificación en algunas versiones de SNMP y por consiguiente cualquier referencia a TRAP también se refiere a las notificaciones, dependiendo de la versión de SNMP que se implemente. El archivo de mapeos de TRAP es preferiblemente un archivo XML que contiene información que permite convertir las alarmas y eventos entrantes del tipo de NE en el formato X.733 conocido y permite al EMS 3 recibir y almacenar los eventos y alarmas en una base de datos de eventos en el EMS 3 a través de un gestor de eventos. Por consiguiente, tiene que especificarse un archivo de mapeo de TRAP para que cada nuevo tipo de NE para permita al EMS 3 gestionar el tipo 6 de NE.

Los archivos de catálogo de alarma contienen la información de catálogo de alarma para el nuevo tipo 6 de NE que se está integrando con el EMS 3. En las realizaciones, los archivos de catálogo de alarma comprenden cinco archivos de los cuales tres son cadenas de mensajes que comprenden compatibilidad con el idioma nacional (NLS) binarias que incluyen información con respecto a un TRAP particular y dos son archivos de texto secundarios que contienen información de restablecimiento de alarma. Por tanto, los archivos de catálogo de alarma pueden incluir contenido de descripción de alarma tal como texto largo, texto de reparación, texto corto y texto de alarma que pueden presentarse visualmente en una interfaz de usuario gráfica (GUI) de información de eventos junto con la alarma disparada correspondiente.

El archivo zip de definición de alarma para el nuevo tipo 6 de NE se transfiere preferiblemente a un directorio arbitrario en un servidor de EMS. El archivo zip puede transferirse al EMS 3 desde una base de datos en el momento de la integración del nuevo tipo 6 de NE o el archivo zip puede transferirse al EMS 3 antes de la integración del nuevo tipo 6 de NE. El archivo zip puede generarse con anterioridad a la integración del nuevo tipo 6 de NE o bien en el servidor de EMS o bien en un dispositivo 7 informático tal como un ordenador que es externo al EMS 3. Tal como apreciará un experto en la técnica, los archivos de alarma generados no tienen que comprimirse en un archivo zip aunque es preferible para reducir los recursos necesarios para almacenar los archivos de alarma generados para cada tipo 6 de NE que puede integrarse con el EMS 3.

El kit 5 de herramientas de integración de tipo de NE localiza y/o recupera un archivo zip de definición de alarma, que incluye preferiblemente un archivo de mapeos de TRAP generado previamente y archivos de catálogo de alarma generados previamente, para el nuevo tipo 6 de NE que está integrándose con el EMS 3.

Durante la integración del nuevo tipo 6 de NE el kit 5 de herramientas de integración de tipo de NE desempaqueta el archivo zip que contiene los diversos archivos de definición de alarma que permitirán al EMS 3 realizar gestión de averías para el nuevo tipo 6 de NE. El kit 5 de herramientas de integración de tipo de NE ejecuta una secuencia de comandos shell usando, por ejemplo, el comando deply.sh que realiza la integración de los archivos de definición de alarma en el EMS 3. Por ejemplo, los archivos XML de mapeos de TRAP se copian a un directorio de instalación en el EMS 3, los archivos de catalogo de eventos de alarma se extraen a los directorios necesarios en el EMS 3, los archivos de catálogo de alarma de NLS se generan en el directorio correcto en el EMS 3 y el archivo de propiedades de ID de evento en el EMS 3 se actualiza con detalles del nuevo tipo 6 de NE. Los directorios en los que se integran los archivos de definición de alarma no se verán afectados preferiblemente por una actualización de sistema del EMS 3 y por tanto están presentes siempre y cuando se requiera reintegrar el tipo de NE con el EMS 3. Alternativamente, los archivos de definición de alarma pueden copiarse a otro directorio en el EMS 3 que no se vea afectado por una actualización de sistema y pueden recuperarse y reintegrarse con el EMS 3.

En las realizaciones, es preferible usar archivos XML para el archivo de mapeos de TRAP del nuevo tipo 6 de NE que va a integrarse puesto que proporcionan flexibilidad para actualizar los detalles de mapeo en el tiempo de ejecución y por tanto ventajosamente no requieren poner el EMS 3 fuera de línea durante la integración del nuevo tipo 6 de NE.

Por consiguiente, en esta realización puede integrarse un nuevo tipo 6 de NE con el EMS 3 mientras el EMS 3 está operativo y sin necesidad de esperar a que se desarrolle, se apruebe y se instale una nueva versión de lanzamiento de software para el EMS 3 antes de que pueda soportarse el nuevo tipo 6 de NE por el EMS 3. El kit 5 de herramientas de integración de tipo de NE de estas realizaciones integra los archivos de definición y los archivos de alarma del nuevo tipo 6 de NE en el EMS 3.

Tal como se describió anteriormente, para integrar el nuevo tipo 6 de NE en el EMS 3, se usa un archivo zip de alarma para el nuevo tipo 6 de NE para integrar la gestión de averías (FM) que se encarga del nuevo tipo 6 de NE en el EMS 3. En realizaciones adicionales de la presente invención, el archivo zip de alarma para el nuevo tipo 6 de NE se genera usando un kit 9 de herramientas de FM que puede formar parte del kit 5 de herramientas de integración de tipo de NE. El archivo zip de alarma puede generarse antes de o en el momento de la integración del nuevo tipo 6 de NE en el EMS 3. El archivo zip de alarma puede generarse en el EMS 3 pero más preferiblemente los archivos de alarma se generan en un dispositivo 7 informático externo y el archivo zip de alarma se transfiere al EMS 3 para cuando el nuevo tipo 6 de NE va a integrarse con el EMS 3.

El kit 9 de herramientas de FM usa archivos de base de información de gestión (MIB) de SNMP para el nuevo tipo 6 de NE, comprendiendo los archivos de MIB normalmente objetos que se usan para gestionar los tipos 6 de NE en una red 1 de telecomunicación. El kit 9 de herramientas de FM genera un archivo de valores separados por coma (CSV) basándose en los archivos de MIB para el nuevo tipo 6 de NE ejecutando, por ejemplo, la secuencia de comandos del kit 9 de herramientas de FM con una opción “-gc”. El archivo de CSV generado a partir de los archivos de MIB puede editarse entonces manualmente para incluir los valores reales para diversos atributos X.733 que pueden usarse para mapear TRAP de SNMP con objetos X.733. X.733 es una norma ITU ampliamente conocida que define funciones de notificación de alarma en una red de telecomunicación.

El kit 9 de herramientas de FM puede generar entonces los archivos XML de mapeo de TRAP y los archivos de catálogo de alarma basándose en el archivo de CSV actualizado ejecutando, por ejemplo, la secuencia de comandos del kit de herramientas de FM con una opción “-gx”.

El resultado del kit 9 de herramientas de FM es un archivo zip que contiene los archivos de mapeo de TRAP y los otros archivos de alarma, por ejemplo los archivos de catálogo, requeridos por el EMS 3 cuando el nuevo tipo 6 de NE se integra con el EMS 3. Tal como se comentó anteriormente en el presente documento, el archivo zip de alarma generado se transfiere al EMS 3 para cuando se ejecuta el kit 5 de herramientas de integración de tipo de NE para integrar las capacidades de manejo de alarma para el nuevo tipo 6 de NE en el EMS 3.

En realizaciones adicionales, el kit 5 de herramientas de integración de tipo de NE puede realizar varias funciones y procesos adicionales cuando se integra un nuevo tipo 6 de NE en el EMS 3. Por ejemplo, el kit 5 de herramientas de integración de tipo de NE puede comprobar que el operador de red tiene una licencia para añadir nuevos tipos 6 de NE, que el kit 5 de herramientas de integración de tipo de NE puede instalar iconos en el EMS 3 para el nuevo tipo 6 de NE y que el kit 5 de herramientas de integración de tipo de NE puede actualizar la configuración de menú en el cliente 7 de EMS para incluir el nuevo tipo 6 de NE.

Para que un operador de red integre nuevos tipos 6 de NE en su red de telecomunicación, es necesario que el operador de red obtenga una licencia que le permita realizar esto. Por tanto, el kit 5 de herramientas de integración de tipo de NE puede realizar una comprobación de licencia a través de una interfaz de programación de aplicaciones (API) de licencia para asegurarse de que el operador de red está autorizado a integrar un nuevo tipo 6 de NE en su red 1 de telecomunicación. El kit 5 de herramientas de integración de tipo de NE comprueba si está disponible una licencia para usar el kit de herramientas y si no está disponible una licencia entonces se dispara un error mediante la función que comprueba una licencia activa válida y se detiene el proceso de integración del nuevo tipo 6 de NE.

Cuando se integra un nuevo tipo 6 de NE con el EMS 3, éste debe representarse preferiblemente mediante un icono en la representación gráfica de la red disponible para el operador de red a través de una interfaz de usuario gráfica (GUI) en su centro de control. Por tanto, un conjunto de archivos de icono deben estar disponibles para cada tipo de NE para que las instancias de cada tipo de NE implementado en la red de telecomunicación estén representadas en la GUI. Por consiguiente, cuando el kit 5 de herramientas de integración de tipo de NE integra el nuevo tipo 6 de NE con el EMS 3, también puede instalar un conjunto de archivos de icono, que comprenden un conjunto de archivos gif, que permiten representar gráficamente el nuevo tipo 6 de NE.

Los nuevos tipos 6 de NE integrados con el EMS 3 pueden estar representados por un conjunto de iconos por defecto almacenados en un conjunto de archivos de icono por defecto. Para proporcionar el conjunto de archivos de icono para el nuevo tipo 6 de NE, el kit 5 de herramientas de integración de tipo de NE copia preferiblemente el conjunto de archivos de icono por defecto en el directorio apropiado, por ejemplo, el directorio $TI_FSPOOL, en el EMS 3 y renombra el conjunto de archivos de icono basándose en el nombre del nuevo tipo de NE. Para usar los iconos, el tipo de NE también se añade a la tabla de base de datos apropiada, por ejemplo, la tabla de base de datos FileServerPool, escribiendo una entrada en la tabla de base de datos.

Alternativamente, cada nuevo tipo 6 de NE puede tener sus propios iconos que pueden copiarse al directorio apropiado en el EMS y escribirse en la tabla de base de datos apropiada de una manera similar al proceso descrito anteriormente para proporcionar el conjunto de archivos de icono por defecto.

Es preferible que la configuración de cliente 7 de EMS se actualice para incluir el nuevo tipo 6 de NE cuando el nuevo tipo 6 de NE se integra con el EMS 3. Los clientes 7 de EMS son normalmente dispositivos informáticos, tales como un ordenador basado en Unix o Windows, que permiten a los operadores humanos acceder a datos desde e interaccionar con el EMS 3 y los tipos de NE soportados y gestionados por el EMS 3. Por tanto, una vez que el nuevo tipo 6 de NE se ha integrado con el EMS 3, la configuración de cliente 7 de EMS también puede actualizarse de modo que los ítems de menú presentados al operador humano incluyan opciones para el nuevo tipo 6 de NE.

Por consiguiente, el kit 5 de herramientas de integración de tipo de NE puede realizar además la función de actualizar la configuración de menú en el servidor de EMS de modo que la configuración de menú actualizada esté disponible entonces para cargarse a los clientes 7 de EMS cuando los clientes 7 de EMS inicien sesión la próxima vez en el EMS 3.

Normalmente, el EMS 3 tendrá capacidades y funcionalidad de servidor web mediante las cuales los clientes 7 de EMS actúan de interfaz con el EMS 3. Preferiblemente, se usa un archivo XML para definir los detalles de configuración de menú que incluyen, por ejemplo, etiquetas para permitir activar una GUI de web en los clientes 7 de EMS para cada uno de los tipos 6 de NE. El kit 5 de herramientas de integración de tipo de NE obtiene una copia estática del archivo de configuración de menú de XML desde el directorio apropiado en el EMS 3 en el que está ubicado el archivo de configuración de menú de XML. La copia estática del archivo de configuración de menú de XML se modifica entonces para incluir los atributos y parámetros del nuevo tipo 6 de NE que está integrándose con el EMS 3.

Por ejemplo, el archivo de configuración de menú de XML estático copiado se modifica localizando en primer lugar una etiqueta <action> con la ID “configuration.localAdmin” que define el menú de administración local. El contenido de la etiqueta <action> puede entonces modificarse para incluir una nueva etiqueta <context> que contiene los identificadores y atributos requeridos para definir la GUI de web para el nuevo tipo de NE. Por ejemplo, la nueva etiqueta <context> puede incluir identificadores y atributos que identifican el tipo de NE, detalles de la GUI de web del nuevo tipo de NE, la ubicación en el LCM desde la cual puede obtenerse cualquier dato adicional para la GUI de web, etc. Un ejemplo de la parte modificada del archivo de configuración de XML se muestra a continuación.

…

<id

configuration.localAdmin

</id>

…

netype=<newNeType>

netype=<newNeType> node

</contextId>

<class>

WebGuiAction

</class>

Local Administration

</applName>

-: ne, -node

</argParam>

</context>

…

</action>

…

El archivo de configuración de menú de XML se guarda entonces en el directorio apropiado en el EMS 3 de modo que cuando un usuario del cliente 7 de EMS inicia sesión la próxima vez en el EMS 3 se carga el nuevo menú basándose en el archivo de configuración de menú de XML modificado. Por tanto, el usuario del cliente 7 de EMS podrá acceder e interaccionar con la GUI de web para el nuevo tipo 6 de NE que se ha integrado con el EMS 3.

Tal como se describió anteriormente en el presente documento, el kit 5 de herramientas de integración de tipo de NE puede realizar varias funciones cuando integra un nuevo tipo 6 de NE en el EMS 3. Por consiguiente, tomando el ejemplo del kit 5 de herramientas de integración de tipo de NE que realiza todas las funciones (aunque un experto en la técnica apreciará que no tienen que realizarse todas las funciones para integrar un nuevo tipo 6 de NE en el EMS 3), entonces en una realización se describirá el proceso y flujos de mensajes con referencia a la figura 3.

En esta realización, se invoca el kit 312 de herramientas de integración de tipo de NE y realiza una serie de etapas para integrar el nuevo tipo de NE en el EMS. En la etapa 301, se realiza una comprobación de una licencia activa válida que permite al operador de red realizar las etapas para integrar un nuevo tipo de NE con el EMS. Si una licencia está activa entonces en la etapa 302 se realiza una comprobación de la base 313 de datos en el EMS para asegurarse de que el tipo de NE no existe ya en el EMS. Si el tipo de NE no existe ya en el EMS entonces en la etapa 303 se localiza el archivo de definición de XML del tipo de NE y se obtiene de la base 314 de datos en la que se almacena el archivo de definición de XML. El archivo de definición de XML del tipo de NE se verifica y en la etapa 304 se genera un archivo XML de acceso shell apropiado. Un archivo XML de acceso shell puede generarse para automatizar el inicio de sesión a una instancia del tipo de NE implantado en la red de telecomunicación. Por consiguiente, el archivo de definición de tipo de NE también puede comprender datos de credenciales, por ejemplo, detalles de cuenta de inicio de sesión, contraseña, etc., que se requieren para iniciar sesión en el elemento de red de ese tipo de NE (es decir una instancia del tipo de NE) cuando se implanta en la red de telecomunicación. Por tanto, un usuario en el centro de control del operador de red puede iniciar sesión automáticamente en la instancia del tipo de NE invocando el archivo XML de acceso shell generado.

En las etapas 305 y 306 se comprueba la existencia de archivos de catálogo y de mapeo de TRAP de alarma válidos para el tipo de NE. Si estas comprobaciones son satisfactorias entonces en la etapa 307 se crea el conjunto de archivos de icono de tipo de NE, en la etapa 308 se almacenan el archivo de definición de tipo de NE y el archivo de acceso shell generado en un directorio en el EMS que no se ve afectado por ninguna futura actualización de sistema y en la etapa 309 se actualiza el archivo de configuración de menú para los clientes de EMS con la entrada de nuevo tipo de NE. En la etapa 310 el nuevo tipo de NE se integra entonces con las bases 313 de datos de EMS y en la etapa 311 el cambio en la configuración de tipo de NE se registra cronológicamente en un archivo de registro cronológico en el EMS.

Tal como se describió anteriormente en el presente documento, cuando se integra un nuevo tipo de NE con el EMS usando el kit de herramientas de integración de tipo de NE, se guarda una copia del archivo de configuración de XML y los archivos de definición de alarma, por ejemplo los archivos de catálogo y de mapeo de TRAP, en los directorios apropiados en el EMS que no se ven afectados por ninguna actualización de sistema del EMS. Por tanto, si se instala una nueva versión de software de EMS en el EMS o cualquier otra forma de actualización de sistema que incluye, por ejemplo, siempre que se instale un nuevo paquete personalizado en el EMS, los nuevos tipos de NE instalados entre actualizaciones de sistemas pueden automáticamente reintegrarse y reimplantarse de nuevo en el EMS. La reintegración de los tipos de NE puede ser necesaria si, por ejemplo, la actualización de sistema es una nueva versión de lanzamiento de software de EMS que no incluye el soporte para el tipo de NE que el operador de red ha implantado en su red de telecomunicación. En este caso, los tipos de NE se reintegrarán con el EMS para garantizar que los tipos de NE continúen soportándose por el EMS, lo que permite que el operador de red continúe usando e implantando esos tipos de NE en sus redes de telecomunicación.

El archivo de definición de XML y los archivos de definición de alarma de los tipos de NE que ya se han integrado con el EMS se guardan en un directorio en el sistema de archivos de EMS que no se ve afectado durante ninguna forma de actualización de sistema y por tanto no se producirá ninguna pérdida de los datos de configuración para la integración de tipos de NE que se realizaron entre actualizaciones de sistema.

Dado que los tipos de NE se integraron con el EMS antes de cualquier actualización de sistema o software, entonces no es necesario comprobar que existe una licencia activa válida ya que esta comprobación se habrá realizado cuando se integró el tipo de NE con el EMS la primera vez.

La reintegración de los tipos de NE en el EMS usando el kit 406 de herramientas de integración de tipo de NE se describirá ahora con referencia a la figura 4. En la etapa 401 todos los archivos de definición de XML están ubicados en el directorio en el EMS en el que se guardaron los archivos de definición de XML. Luego se introduce un bucle 408 en el que se comprobará si cada uno de los archivos de definición de XML ubicados debe reintegrarse con el EMS y, de ser así, se reintegran. En la etapa 402 el kit de herramientas de integración de tipo de NE comprueba si el tipo de NE que corresponde al archivo de definición de XML que se considera existe ya en la base 407 de datos de EMS. El tipo de NE puede existir ya si, por ejemplo, la actualización de sistema fue la instalación de una nueva versión de software de EMS que incorporaba soporte para el tipo de NE.

Si el tipo de NE que corresponde al archivo de configuración de XML no existe, entonces en la etapa 403 el kit de herramientas de integración de tipo de NE comprueba que estén disponibles los archivos de definición de alarma necesarios para el tipo de NE. Tal como se describió anteriormente en el presente documento, cuando el nuevo tipo de NE se integró originalmente por primera vez en el EMS, los archivos de alarma, o bien el archivo zip de alarma o bien los archivos de alarma extraídos, se copiaron o bien en un directorio en el EMS que tampoco se ve afectado por una actualización de sistema o bien en los directorios en los que se integraron los archivos de definición de alarma que no se ven afectados por una actualización de sistema. Por consiguiente, si tanto los archivos de configuración de XML como los archivos de alarma para el tipo de NE están disponibles, entonces el tipo de NE puede reintegrarse con el EMS. Efectivamente, el kit de herramientas de integración de tipo de NE realiza un proceso y un procedimiento similar al que se describió anteriormente en cuanto a la integración del tipo de NE en el EMS por primera vez, aunque preferiblemente se requieren sólo algunos los procesos. Por consiguiente, en la etapa 404, el conjunto de archivos de icono se actualiza con los iconos del tipo de NE reintegrado y en la etapa 405 el tipo de NE se integra con las bases 407 de datos apropiadas en el EMS. No es necesario que los archivos de definición de alarma se reintegren puesto que se integraron originalmente con directorios y bases de datos que no deben verse afectados por una actualización de sistema. Sin embargo, tal como se apreciará, si por cualquier motivo los archivos de definición de alarma sí requieren una reintegración entonces puede seguirse el mismo procedimiento que se describió anteriormente en el presente documento para realizar la reintegración de los archivos de definición de alarma.

Una vez que todos los archivos de definición de XML almacenados en el EMS se han reintegrado con el EMS, entonces en la etapa 406 el archivo de configuración de menú se actualiza con detalles de todos los tipos de NE que se han reintegrado con el EMS de modo que los clientes de EMS puedan acceder a la GUI de web para cada uno de los tipos de NE reintegrados.

Para gestionar los tipos de NE que pueden añadirse a través del kit de herramientas de integración de tipo de NE, entonces es preferible que el kit de herramientas de integración de tipo de NE también pueda usarse para borrar los tipos de NE que se han integrado con el EMS a través del kit de herramientas de integración de tipo de NE.

El proceso de borrar los tipos de NE del EMS se describirá ahora con referencia a la figura 5. El kit 509 de herramientas de integración de tipo de NE se invoca con una opción ‘delete’, que incluye el nombre del tipo de NE que se borrará del EMS. En la etapa 501, el kit de herramientas de integración de tipo de NE comprueba que el tipo de NE que va a borrarse existe en la base 510 de datos de EMS. En la etapa 502, el kit 509 de herramientas de integración de tipo de NE comprueba entonces si alguna instancia de NE relacionada con el tipo de NE que va a borrarse también existe en la base 510 de datos de EMS. En otras palabras, el kit de herramientas de integración de tipo de NE comprueba si elementos de red reales del tipo de NE (es decir instancias del tipo de NE) están actualmente implantadas de manera activa en la red de telecomunicación comprobando si existe alguna instancia del tipo de NE en la base de datos de EMS. Si existe alguna instancia de NE relacionada con el tipo de NE en la base de datos de EMS, entonces no puede borrarse el tipo de NE y se detiene el proceso de borrado. Sin embargo, si no existe ninguna instancia de NE relacionada con el tipo de NE, entonces el tipo de NE puede borrarse del EMS.

Por consiguiente, en la etapa 503 el conjunto de archivos de icono para el tipo de NE se elimina del sistema de archivo de EMS. Por ejemplo, las entradas para los archivos gif de icono del tipo de NE se eliminarán de la tabla de base de datos “FileServerPool” y el conjunto de archivos de icono de tipo de NE se borrará en el sistema de archivos $TI_FSPOOL. En la etapa 504 el archivo de definición del tipo de NE que se está borrando se elimina del sistema de archivos de EMS. En la etapa 505 los archivos de acceso shell también se eliminan del EMS.

En la etapa 506 el kit de herramientas de integración de tipo de NE también puede modificar el archivo de configuración de menú para eliminar las etiquetas, parámetros y atributos asociados con el tipo de NE del archivo de configuración de menú de XML. Por tanto, el operador que usa los clientes de EMS para acceder al EMS ya no podrá acceder, por ejemplo, a la GUI de web del tipo de NE borrado.

En la etapa 507 el kit de herramientas de integración de tipo de NE elimina los datos de definición de la base 510 de datos de EMS. Para borrar el tipo de NE del EMS es necesario borrar toda la información del tipo de NE de la bases de datos en el EMS. Por ejemplo, los atributos de características del tipo de NE se eliminarán de la tabla de base de datos “neFeatures”, las credenciales se eliminarán de la tabla de base de datos “neTypeCredentials” y las entradas de GUI de web se eliminarán de la tabla de base de datos “neTypeWebGui”.

Si el borrado del tipo de NE es satisfactorio, entonces en la etapa 508 se escribirá un fichero de registro cronológico de cambio de configuración en el archivo de registro cronológico de EMS.

El kit de herramientas de integración de tipo de NE también puede borrar los archivos de catálogo y de mapeo de alarma correspondientes para el tipo de NE de las bases de datos apropiadas y directorios en el EMS usando, por ejemplo, una secuencia de comandos shell “undeploy.sh” invocada con el nombre de tipo de NE de parámetros que se está borrando.

Las realizaciones preferidas de la presente invención permiten integrar un nuevo tipo de NE con el EMS de una manera sustancialmente ad hoc y sin ningún tiempo de inactividad del EMS. Esto es particularmente ventajoso ya que un operador de red puede implantar nuevos tipos de NE en su red de telecomunicación sin tener que esperar a que se desarrolle, se pruebe, se apruebe y se instale una nueva versión de lanzamiento de software de EMS que incorpore el soporte para el nuevo tipo de NE en el EMS. Además, para instalar una nueva versión de lanzamiento de software de EMS, el EMS debe ponerse fuera de línea, lo que provoca la interrupción de la red, y por tanto las realizaciones de la presente invención tienen la ventaja adicional de que cuando se integra un nuevo tipo de NE en el EMS, esto puede realizarse sin afectar al funcionamiento y a las capacidades del EMS.

Aunque se han mostrado y descrito realizaciones preferidas de la invención, se entenderá que tales realizaciones se describen sólo a modo de ejemplo. A los expertos en la técnica se les ocurrirán numerosas variaciones, cambios y sustituciones sin apartarse del alcance de la presente invención según se define mediante las reivindicaciones adjuntas.

Claims

REIVINDICACIONES

1. Método (figura 3) para integrar un tipo de elemento de red con un sistema de gestión de elementos que comprende: recuperar (303) una definición de tipo de elemento de red; e integrar (310) dicha definición de tipo de elemento de red con dicho sistema de gestión de elementos,

estando el método caracterizado porque comprende: comprobar (301) una licencia para asegurarse de que un operador de red está autorizado a integrar dicho tipo de elemento de red con el sistema de gestión de elementos;

recuperar (303) una definición de alarma de tipo de elemento de red; e integrar (310) dicha definición de alarma de tipo de elemento de red con dicho sistema de gestión de elementos de manera que dicho sistema de gestión de elementos pueda soportar dicho tipo de elemento de red una vez que dicha definición de tipo de elemento de red y dicha definición de alarma de tipo de elemento de red se han integrado con dicho sistema de gestión de elementos.
2.

Método (figura 3) según la reivindicación 1, en el que dicha etapa de recuperación (303) de dicha definición de tipo de elemento de red comprende recuperar dicha definición de tipo de elemento de red desde una base de datos o sistema de archivos en el sistema de gestión de elementos o desde una base de datos conectada operativamente a dicho sistema de gestión de elementos.
3.

Método (figura 3) según la reivindicación 1 ó 2, en el que dicha definición de tipo de elemento de red comprende un conjunto de atributos y parámetros que definen dicho tipo de elemento de red, en el que dicha etapa de integración (310) de dicho tipo de elemento de red con dicho sistema de gestión de elementos comprende:

generar sentencias de lenguaje de consulta estructurado basándose en dicha definición de tipo de elemento de red; y

ejecutar dichas sentencias de lenguaje de consulta estructurado para integrar dichos atributos y parámetros que definen dicho tipo de elemento de red en al menos una base de datos en dicho sistema de gestión de elementos.
4. Método (figura 3) según una cualquiera de las reivindicaciones anteriores, en el que dicha etapa de recuperación (303) de dicha definición de alarma de tipo de elemento de red comprende recuperar un archivo zip, comprendiendo dicho archivo zip al menos un archivo que define al menos datos de mapeos de TRAP y datos de catálogo de alarma; y

dicha etapa de integración (310) de dicha definición de alarma de tipo de elemento de red con dicho sistema de gestión de elementos comprende:

extraer dicho al menos un archivo de dicho archivo zip;

actualizar dicho sistema de gestión de elementos según datos en dicho al menos un archivo extraído.
5.

Método (figura 3) según la reivindicación 4, en el que dicha etapa de actualización de dicho sistema de gestión de elementos comprende:

instalar dichos datos de mapeos de TRAP en un directorio en dicho sistema de gestión de elementos; e instalar dichos datos de catálogo de alarma en un directorio en dicho sistema de gestión de elementos.
6.

Método (figura 3) según una cualquiera de las reivindicaciones anteriores, que comprende además: generar dicha definición de alarma de tipo de elemento de red; y almacenar dicha definición de alarma de tipo de elemento de red en un directorio en dicho sistema de

gestión de elementos.
7.

Método (figura 3) según la reivindicación 6, en el que dicha etapa de generación de dicha definición de alarma de tipo de elemento de red comprende:

recuperar un archivo de base de información de gestión;

generar un archivo de valores separados por coma basándose en dicho archivo de base de información de gestión;

editar dicho archivo de valores separados por coma para incluir valores para dicho tipo de elemento de red;

generar un archivo de datos de mapeo de TRAP basándose en dicho archivo de valores separados por coma editado; y

generar al menos un archivo de catálogo de alarma basándose en dicho archivo de valores separados por coma editado.
8. Servidor (3) adaptado para: recuperar una definición de tipo de elemento de red; integrar dicha definición de tipo de elemento de red con un sistema (3) de gestión de elementos; estando el servidor caracterizado porque está adaptado para: comprobar una licencia para asegurarse de que un operador de red está autorizado a integrar dicho tipo de elemento de red con el sistema de gestión de elementos;

recuperar una definición de alarma de tipo de elemento de red; e integrar dicha definición de alarma de tipo de elemento de red con dicho sistema de gestión de elementos de manera que dicho sistema de gestión de elementos pueda soportar dicho tipo de elemento de red una vez que dicha definición de tipo de elemento de red y dicha definición de alarma de tipo de elemento de red se han integrado con dicho sistema de gestión de elementos.
9. Servidor (3) según la reivindicación 8, en el que dicha definición de tipo de elemento de red comprende un conjunto de atributos y parámetros que definen dicho tipo de elemento de red, estando dicho servidor adaptado además para:

generar sentencias de lenguaje de consulta estructurado basándose en dicha definición de tipo de elemento de red; y

ejecutar dichas sentencias de lenguaje de consulta estructurado para integrar dichos atributos y parámetros que definen dicho tipo de elemento de red en al menos una base de datos en el sistema de gestión de elementos.
10. Servidor (3) según la reivindicación 8 ó 9, en el que dicha alarma de tipo de elemento de red es un archivo zip, comprendiendo dicho archivo zip al menos un archivo que define al menos datos de mapeos de TRAP y datos de catálogo de alarma; estando dicho servidor adaptado además para:

extraer dicho al menos un archivo de dicho archivo zip;

actualizar dicho sistema de gestión de elementos según datos en dicho al menos un archivo extraído.
11.

Servidor (3) según la reivindicación 10, adaptado además para: instalar dichos datos de mapeos de TRAP en un directorio en dicho sistema de gestión de elementos; e instalar dichos datos de catálogo de alarma en un directorio en dicho sistema de gestión de elementos.
12.

Producto de programa informático que comprende código ejecutable legible por ordenador para:

comprobar (301) una licencia para asegurarse de que un operador de red está autorizado a integrar dicho tipo de elemento de red con un sistema de gestión de elementos; recuperar (303) una definición de tipo de elemento de red; recuperar (303) una definición de alarma de tipo de elemento de red;

integrar (310) dicha definición de tipo de elemento de red con dicho sistema de gestión de elementos; e

integrar (310) dicha definición de alarma de tipo de elemento de red con dicho sistema de gestión de elementos de manera que dicho sistema de gestión de elementos pueda soportar dicho tipo de elemento de red una vez que dicha definición de tipo de elemento de red y dicha definición de alarma de tipo de elemento de red se han integrado con dicho sistema de gestión de elementos.
13. Producto de programa informático según la reivindicación 12, en el que dicha definición de tipo de elemento de red comprende un conjunto de atributos y parámetros que definen dicho tipo de elemento de red, comprendiendo además dicho producto de programa informático código ejecutable legible por ordenador para:

generar sentencias de lenguaje de consulta estructurado basándose en dicha definición de tipo de elemento de red; y

ejecutar dichas sentencias de lenguaje de consulta estructurado para integrar dichos atributos y parámetros que definen dicho tipo de elemento de red en al menos una base de datos en el sistema de gestión de elementos.
14. Servidor (3) según la reivindicación 12 ó 13, en el que en dicha alarma de tipo de elemento de red es un archivo zip, comprendiendo dicho archivo zip al menos un archivo que define al menos datos de mapeos de TRAP y datos de catálogo de alarma; y dicho producto de programa informático comprende además código ejecutable legible por ordenador para:

extraer dicho al menos un archivo de dicho archivo zip;

actualizar dicho sistema de gestión de elementos según datos en dicho al menos un archivo extraído.
15. Producto de programa informático según la reivindicación 14, que comprende además código ejecutable legible por ordenador para:

instalar dichos datos de mapeos de TRAP en un directorio en dicho sistema de gestión de elementos; e

instalar dichos datos de catálogo de alarma en un directorio en dicho sistema de gestión de elementos.