MXPA01011034A - Disposicion y metodo de manejo de recurso de red de telecomunicaciones. - Google Patents

Abstract

Un manejador de recurso para uso en una estructura de soporte operativo para manejar una red de telecomunicaciones comprende una base de datos de servicio y recurso que contiene informacion con respecto a los recursos de red. La disposicion de base de datos esta estructurada de manera que cada recurso en la red tiene un tiempo de existencia asi como un lugar en una jerarquia de relaciones padre/hijo(s). El recurso esta definido por los siguientes datos: un identificador de punto que tiene caracteristicas asociadas con el mismo en la forma de una descripcion abstracta de sus capacidades; una abstraccion del elemento de red comun en el sentido de un grupo de puntos que estan considerados para estar unidos; y una conexion que esta definida por dos puntos conectados.

Description

DISPOSICIÓN Y MÉTODO DE MANEJO DE RECU RSO DE RED DE TELECOMUN ICACION ES CAMPO TÉCNICO La presente invención se refiere a un manejador de recursos para uso en una estructura de soporte para manejo de una red de telecomunicaciones, que comprende una disposición de base de datos de servicio y recurso que contiene información con respecto a los recursos de la red. La invención se refiere también a un método de estructuración de información en una disposición de base de datos manejadora de recurso para uso en dicha estructura de soporte operativo. Asimismo, la invención se refiere a un uso de un manejador de recurso para un manejador de tipo servicio en una estructura de soporte operativo para una red de telecomunicaciones , para crear y mantener los modelos de tipo servicio y sus relaciones.

ESTADO DE LA TÉCNICA El manejo de recurso en sistemas de soporte operativo para telecomunicación es difícil debido al tamaño y complejidad de esos tipos de redes. Una red de telecomunicación normalmente cambia de manera constante conforme se agregan recursos/servicios y conforme se eliminan o reemplazan recursos/servicios superfluos y ^^^^^^^^^ti. antiguos. Frecuentemente, una falta de información con respecto a los recursos disponibles/redundantes conduce a soluciones verticales descendentes para servicios particulares o redes con altos niveles de duplicación. La falta de información actualizada y la duplicación resultante conducen a mayores costos de manejo para el operador de la red. En ocasiones las inversiones de recurso son innecesarias debido a que los recursos redundantes pueden estar realmente disponibles. Puede haber recursos que supuestamente están acoplados por viejos servicios que ya no están activos o han sido reemplazados por nuevos servicios que usan otros recursos. Una estructura de soporte técnico operativo para una red de telecomunicaciones se describe por ejemplo en el documento US 5,640,505. Esta estructura de soporte está dividida en un conjunto de dominios cada uno de los cuales proporciona una función de manejo particular para la red. Este documento enseña una estructura de soporte general aunque proporciona muy pocos detalles para la implementación de dicha estructura. Por lo tanto, no hay solución definitiva para el problema de cómo manejar los recursos de la red de manera que se evita la duplicación. El documento EP-A-0 820 203 muestra un método y una disposición para hacer uso de los recursos en una red de telecomunicaciones. Sin embargo, ésta disposición/método no son satisfactorios por varias razones. Por ejemplo, no toma en cuenta de manera satisfactoria el tiempo que existe un recurso. Para hacer esto, tendrían que agregarse atributos que contienen información -fc , acerca del tiempo de existencia; sin embargo, esto tendría que hacerse parta cada recurso a fin de hacerlo representativo lo cual reduciría considerablemente el rendimiento. Además, no da una solución para el problema de agregar atributos completamente nuevos. Hay también una desventaja en que no puede ser utilizado por procesos arbitrarios sino que está específicamente diseñado para soportar el proceso SDI orientado a objetos. La solución del documento EP-A-0 820 203 no es suficientemente flexible. De manera ideal la base de datos de servicios y recurso debe ser capaz de representar todos los tipos existentes y futuros de equipo de telecomunicación y topologías de red en un modelo de datos simple a fin de ser capaz de manejar los recursos de u na red arbitraria.

BREVE DESCRIPCIÓN DE LA INVENCIÓN U n objeto de la presente invención es proporcionar un manejador de recurso flexible y método que se relaciona con el mismo que puede ser utilizado por procesos arbitrarios Otro objeto es habilitar la fácil adición de nuevos atributos (de preferencia dinámicamente) bajo operación, así como nuevos tipos de servicios y nuevos tipos de recursos. En particular es un objeto permitir el modelado y manejo de equipo con propiedades trans misivas y no transmisivas .

De acuerdo con un primer aspecto de la invención, se proporciona un manejador de recurso para uso en una estructura de soporte operativo para manejar una red de telecomunicaciones, que comprende una disposición de base de datos de servicio y recurso que contiene información con respecto a los recursos de la red. La disposición de base de datos está estructurada de manera que cada recurso en la red tiene un tiempo de existencia así como un lugar en una jerarquía de relaciones padre/hijo(s). El recurso está definido por los datos siguientes: un identificador de punto que tiene características asociadas al mismo, en la forma de una descripción abstracta de sus capacidades; una abstracción de elemento de red común en el sentido de un grupo de puntos que se consideran que se pertenecen ; y una conexión que está definida por dos puntos de contacto. Preferiblemente, el identificador de punto posee también características asociadas con el mismo, en la forma de una lista de pares etiqueta/valor. De acuerdo con una modalidad ventajosa de la invención, el elemento actúa como un recipiente para puntos, con la característica implícita que los puntos sobre elementos son posibles para interconexión. La disposición de base de datos puede estructurarse para modelar una vista topológica, es decir, como se conectan juntos los recu rsos. También puede estructurarse para modelar una vista de tiempo, es decir cuando existe el recurso La disposición de base de datos puede estructurarse para modelar una vista de jerarquía, es decir como se relacionan los recursos en las relaciones padre/hijo. Puede estructurarse también para modelar una vista característica, es decir, por medio de una lista de características de cada recurso. Asimismo, la base de datos está estructurada para modelar una vista de uso, es decir que recursos se combinan para formar una instancia de servicio completa y el tiempo cuando existe esa instancia de servicio. Preferiblemente, la vista topológica, la vista de tiempo, la vista de jerarquía, y la vista de uso están integradas en un modelo de datos para permitir el control de cada recurso y el uso de este en las instancias de servicio. De preferencia la disposición de base de datos comprende una primera base de datos separada y una segunda base de datos separada. U na de las bases de datos es utilizada por los tipos de recurso y las instancias de recurso en tanto que la otra base de datos es usada por los tipos de servicio y las instancias de servicio.

De acuerdo con un segundo aspecto de esta invención, se proporciona un método para estructurar la información en una disposición de base de datos manejadora de recurso para uso en una estructura de soporte operativo a fin de manejar una red de telecomunicaciones, que comprende las etapas de asignara a cada recurso en la red un tiempo de existencia así como un lugar en una jerarqu ía de relaciones padre/hijo, y definir cada recurso mediante los siguientes datos: un identificador de punto que tiene características asociadas con el mismo, en la forma de una descripción abstracta de sus capacidades; una abstracción del elemento de red común en el 'sentido de un grupo de puntos que son considerados como unidos; y una conexión que está definida por dos puntos conectados. De acuerdo con un tercer aspecto de esta invención, se proporciona un uso de un manejador de recurso para un manejador de tipo de servicio en una estructura de soporte operativo para una red de telecomunicaciones, para crear y mantener los modelos de tipo de servicio y sus relaciones. Preferiblemente, los modelos de tipo de servicio proporcionan una estructura para tipos de servicio, operaciones sobre tipos de servicio, parámetros sobre tipos de servicio, relaciones de jerarquía entre los tipos de servicio, relación de parámetro de jerarquía y transferencia de tipos de servicio y valores de parámetros asociados en requerimientos de recurso y requerimientos de tipo de servicio. El manejador de tipo de servicio puede utilizarse para seleccionar entre diferentes tipos de servicios requeridos, diferentes tipos de recursos requeridos y diferentes instancias de servicio. De manera ventajosa, los requerimientos de recurso seleccionados son transferidos hacia un manejador de recurso que efectúa la asignación de recurso real BREVE DESCRIPCIÓN DE LOS DIBUJOS La figura 1 ilustra esquemáticamente la relación entre los conceptos de instancia de (servicio) producto/tipo e' instancia de recurso/tipo, La figura 2 ilustra esquemáticamente la relación entre elementos, puntos y conexiones, La figura 3 muestra el ambiente del sistema de la disposición de base de datos de servicio y recurso de la configuración de servicio, La figura 4 es un diagrama de bloque que ilustra la estructura de relación de una disposición de base de datos de servicio y recurso, y La figura 5 ilustra las relaciones de cuadro y definiciones de tipo de producto.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN Ya que existen muchos aspectos de un sistema de telecomunicaciones, una estructura de la información tiene que hacerse en partes para interacción entre los tipos de producto/servicio y las instancias de producto/servicio. Por ejemplo, es posible tener una parte del sistema que maneja los tipos de producto/servicio y su transferencia a las instancias de producto/servicio y/o las referencias a recursos, una segunda parte para unir la información acerca de los tipos de producto/servicio y la fijación de precios del tipo de producto/servicio, una tercera parte para las instancias de producto/servicio y una cuarta parte para mantener el rastreo de todo código de procedimiento para manipulación de datos. Esta idea de modelado básica se ilustra en la figura 1 , y comprende cuatro áreas básicas (dominios), el tipo de producto/servicio, la instancia de producto/servicio, el tipo de recurso y la instancia de recurso. Las áreas de tipo se verán como están colocados los dibujos y las especificaciones de diseño y las áreas de instancia están donde se ubican el material original y los productos/servicio listos. Por tanto, es muy importante hacer una clara distinción entre el tipo de un producto/servicio y la instancia de un producto/servicio así como entre un tipo de recurso y una instancia de recurso. Cada tipo de producto/servicio está definido por nombre, parámetros, nivel de revisión y comportamiento. Por lo tanto, el tipo de producto/servicio puede verse como una plantilla con parámetros para una instancia de producto/servicio. Cada tipo de producto/servicio tiene una o más revisiones. Ya que un tipo de producto/servicio puede constar de otros tipos de producto/servicio, algunos tipos de producto/servicio están colocados en una jerarquía de relaciones padre/hijo . Es de la mayor importancia que un tipo de producto/servicio no tenga conocimiento de los tipos de producto de los que es parte. Puede saber cosas acerca de los tipos de producto/servicio de los que consta. Un tipo producto/servicio padre puede tener la posibilidad de bifurcarse a uno o varios tipos de producto hijo. Una instancia de producto/servicio es la realización de un producto/servicio con todos los valores de parámetro establecidos para sus valores finales. Ya que los tipos de producto/servicio tienen una jerarquía, las instancias de producto/servicio deben poseer también una jerarquía. El proceso de producto/servicio es el procedimiento referido por el tipo de producto/servicio. Contiene las instrucciones completas y precisas de cómo manipular una instancia de producto/servicio. El concepto de recursos se utiliza para tener un concepto para todas las cosas "reales" en el sistema. Es muy importante distinguir entre dos cosas , creación de recurso , es decir la instalación de una nueva línea telefónica y asignación recurso, por ejemplo cambiar el estado de una línea telefónica existente de no utilizada a utilizada. El tipo de recurso es la identidad de una descripción abstracta del recurso necesaria para implementar un tipo de producto. Los tipos de producto/servicio que tienen hijos pueden poseer referencias a tipos de recursos. Los tipos de producto/servicio que no tienen hijos deben tener referencias a tipos de recursos. La instancia de recurso es la instalación real de un ti po de recurso. Las instancias de producto/servicio, que tienen hijos pueden poseer referencias a instancias de recursos. Las instancias de producto/servicio que no tienen hijos deben tener referencias a instancias de recurso. La relación entre los elementos, puntos y conexiones se ilustran en la figura 2 la cual es una vista gráfica abstracta de una red de telecomunicación. Cada uno de los cuadros en la figura 2 representa un elemento 10, los puntos son los puntos 1 1 y las líneas gruesas son conexiones 12. Las líneas delgadas en el elemento izquierdo inferior también son conexiones, solamente reducidas a escala en anchura para ajustar el elemento. Esto está representado en la Base de Datos de Tipo e Instancia de Recurso (SRDB) de acuerdo con esta invención, en la forma de cuadros en una base de datos de relación. El tener una SRDB es poseer un modelo formal y abstracto para describir una red de telecomunicación, sus partes, sus capacidades, como se conectan las partes, por parte de quien y cuando se utiliza una pieza y así sucesivamente. Cuando las existencias en la SRDB son listas de elementos, los puntos sobre esos elementos, las capacidades/atributos de cada punto y como se conectan los puntos. Esas listas (en la forma de tablas de bases de datos) son llenadas con información de que equipo existe (y cuando existe), que se puede hacer y si es utilizado por alguien. El punto 1 1 es conocido en el mundo real con muchos nombres , tales como puerto, punto de terminación, punto de acceso externo, poste de unión etc. En SRDB se abstraen a un concepto, el punto que en esencia es un identificador. Para distinguir entre diferentes tipos de puntos, cada punto debe tener un tipo que es una descripción abstracta formal de sus capacidades. Un tipo de punto puede tener una o más capacidades. U n punto debe pertenecer siempre a un elemento, no puede existir por si solo. El elemento 10 es en esencia un grupo de puntos que se consideran unidos. Para ser un elemento, los puntos que están unidos al mismo debe tener conectividad total entre sí, es decir, cualquier punto debe tener la posibilidad de interconectarse a cualquier otro punto dentro del mismo elemento. Esta conectividad debe restringirse un bit ya que los tipos de capacidad/atributo de los puntos pueden tener el requerimiento de que la misma capacidad/atributo debe existir en ambos puntos a fin de ser capaz de intercon exión . La conexión es la verdadera información que dice que punto está conectado a otro punto. En realidad es un par de puntos .

Existen básicamente dos tipos de conexiones, la conexión de infraestructura, es decir un cable y una interconexión, la cual es controlable . La capacidad es una colección de atributos. Cada tributo es en esencia u n par que consta del nombre de un parámetro y el valor del parámetro. Esta es la manera formal para describir las características de un tipo de punto. La instancia de servicio es la entidad que en si misma posee todos los datos comunes con respecto a los recursos utilizados por el mis mo y tiene referencias a esos recursos.

Los atributos particulares son conectados solamente a puntos y las relaciones se usan para conectar puntos a elementos y conectar puntos a conexiones. Sin embargo, puede haber también algunos atributos fijos en los elementos y conexiones. Se seleccionan muy cuidadosamente ya que deben estar siempre como tiempo de existencia, nombre del recurso, etc. el punto principal es que no hay posibilidad para conectar opcionales o cualesquiera atributos, atributo a elementos o conexiones. En vez de ello todos los rasgos característicos están en los puntos donde es posible proporcionar una conexión a un número arbitrario de atributos. Los elementos solamente funcionan en realidad como "soportes de colocación" a los cuales pueden conectarse los puntos. El funcionamiento de las conexiones es similar, es decir su funcionamiento es para indicar que se conectan dos puntos. Aún más, en la disposición de base de datos de la presente invención , cada recurso (elemento, punto, conexión) tiene preferiblemente un tiempo de existencia, el cual subraya fuertemente la consciencia acerca del significado del tiempo. En una implementación particular la disposición de base de datos comprende campos que permiten el uso de un código regular (por ejemplo C, Java™) si es necesario, el cual proporciona mayor flexibilidad. De acuerdo con la invención no todo recurso tiene necesariamente una conexión (explícita) . En una implementación más ventajosa de la invención es posible distinguir entre diferentes tipos de atributos, representando -t i primero, que esos objetos son "tecleados", y en segundo lugar, que puede distinguirse entre dichos tipos. Es preferible por lo menos distinguir entre atributos del tipo "transmisivo" y del tipo "no transmisivo". U n ejemplo en un recurso con atributos nó transmisivos es una cuenta de correo electrónico, tiene una memoria aunque no atributos transmisivos como por ejemplo ancho de banda. A través del "tecleo" resulta fácil modelar los atributos y manejar el equipo que tiene propiedades transmisivas y no transmisivas, es decir equipo que en principio queda fuera del alcance común de la red de telecomunicaciones, como servidores. El concepto de jerarquía se usa en muchos lugares en la SRDB de forma que esos elementos 10, puntos 1 1 y conexiones 12 pueden tener hijos, es decir pueden tener una estructura interna. Esto se describe en la forma de una relación padre/hijo en un cuadro. De preferencia y de acuerdo con la invención, el modelo es claramente jerárquico con relaciones padre/hijo en elementos, puntos y conexiones. La figura 3 muestra el ambiente del sistema donde la Configuración del Servicio (SC) consta principalmente del sistema de activación 13, el Procesador de Petición de Servicio (SRP) 14 para comunicación del sistema en sentido ascendente, el Procesador de Elemento de Red (N EP) 15 para comunicación del sistema en sentido descendente, Base de Datos de tipo e Instancia de Recursos (SRDB) 16 para información acerca de los recursos de red y Base de Datos de Tipo e I nstancia de Datos (STDB) 17 , ver figura 5, para la jerarquía de tipo e instancia de servicio. En forma interna, el sistema de activación 13 consta del Manejador de Petición de Activación de Servicio (SARM) 18 una parte de un Programa de Activación de Servicio Automático (ASAP) y el Manejador de Instancia de Servicio y Recurso (SRI M) 19. En una implementación ventajosa de esta invención la disposición de base de datos está separada en dos bases de datos (SRDB y STDB) , una de las cuales, SRDB, contiene los tipos de recurso y las instancias de recurso, la otra, STDB que contiene los tipos de servicio y las instancias de servicio . La conexión entre STDB y SRDB es tal que para usos externos de la disposición de base de datos, los mensajes acerca de cuyos atributos se desean , son enviados desde el tipo de servicio y la parte de instancias (STDB) (descendente) hacia el tipo de recurso y la parte de instancia (SRDB). Existe por lo tanto un acoplamiento muy suelto. La intención de utilizar dicho acoplamiento o conexión suelta es que algunas veces no se desea la complejidad involucrada con los tipos de servicio. En vez de tipos/instancias de recurso "naturales" o "puros" pueden obtenerse directamente desde la parte de recurso (SR DB) de la disposición de base de datos. A través de la separación de la disposición de base de datos como se refirió antes es posible definir tipos de servicio utilizando tipos de recurso (con nuevos atributos) que aún no están definidos en la parte de recurso.

La STDB 17, ver figura 5, contiene toda la información sobre como transferir un tipo de servicio específico a recursos, para permiti r la creación de nuevas instancias de servicio. La SRDB 16 es la fuente de información y depositaría de SC. Una vista simplificada del flujo de la información es que se envía un comando de Capa de Descripción de Servicio Común (CSDL) mediante el SRP 14 hacia SARM 18 donde es transferido a un comando de Capa de Descripción de Servicio Atómico ASDL y enrutado hacia SRi M 19. SR IM solicita entonces a STDB 17 y SRDB información adicional que es utilizada para hacer que un nuevo comando CSDL sea trasladado hacia un comando ASDL y enrutado hacia el N EP 15. La respuesta desde el N EP sigue en principio el mismo sentido hacia atrás, done el estatus de retorno y los datos se utilizan para actualizar SRDB 16. La creación de una instancia DuoCom se usa ahora como un ejemplo de cómo utilizar la información en las estructuras de datos. Se asume que el producto DuoCom consta de subproductos ISDN Access, E-mai l , Personal Home Page y 020-connection . Estos cinco productos, junto con todos los parámetros relevantes, valores de parámetro , definiciones de recurso, información de producto, costo del tipo de producto, niveles de revisión, etc. , y el control de suministro asociado se considera que son registrados en la estructura de datos de «tipo de producto. La etapa cero es aquella en la que un indicador, probablemente un sistema de cuidado del cliente (en algún momento conveniente) ha obtenido el acceso a un Portafolios de Producto de Operador (OPP) y sabe por lo menos los nombres de los productos disponibles. Cuando un usuario final hace contacto con el sistema de cuidado del cliente, el cliente recibe una lista de tipos de producto/servicio para 5 selección . En este caso el producto DuoCom es interesante, de manera que se hace una petición para más información acerca del tipo de producto/servicio. En la etapa 1 el OPP, utilizando el nombre del producto y el hecho que se desea la información del producto como parámetros, 10 busca en la tabla de información de tipo producto/servicio donde se encuentran todos los aspectos de información y donde buscarlos. En la etapa 2, asumiendo que el cliente desea el producto, se refiere a continuación un producto, debe quedar claro sin embargo que también cubre un servicio , se hace una revisión de viabilidad 15 para verificar si es posible i mplementar el producto con las condiciones existentes, es decir si se cumplen todos los requisitos previos. Se hace ahora una "llamada" para este código. Conforme inicia la ejecución, este código que utiliza el tipo de producto es introducido para buscar en la jerarquía de tipo de Producto. 20 Buscando aqu í es posible encontrar de cuales (sub)productos está compuesto el producto DuoCom. En este caso se encontrarán los cuatro tipos de producto ISDN Access, E-mai l , Personal Homepage y 020-connection . A su vez pueden consistir de productos más simples, la jerarqu ía de tipo de Producto es examinada una vez más para ver iáteS.»~t ¿a- . uj t. si los nuevos productos tienen subproductos y así sucesivamente hasta que no se encuentren más tipos de producto. Ya que algunos de los (sub)productos pueden ser opcionales, es decir, se pregunta al cliente final si los desea y se le informa acerca de posibles opciones. Esto resulta en un ciclo interactivo en el cual el cliente selecciona los (sub)productos deseados. Ya que se seleccionan estos subproductos, los parámetros de operación del tipo de Producto y las tablas de parámetro de tipo de Producto son examinados para encontrar que parámetros son necesarios. Ya que esta selección de (sub)productos es dinámica para su naturaleza, la tabla de relaciones de tipo de Producto es examinada para verificar que combinaciones de tipo de producto incompatible no se crean accidentalmente. Cuando se termina este ciclo, los requisitos previos del tipo de Producto y las tablas de requisitos previos de recurso de tipo de Producto son examinados con respecto a datos de instancia de Producto y datos de recursos, si la cantidad suficiente de recursos o instancias de producto existentes están disponibles , de manera que es posible iniciar esta nueva instancia de producto. En la etapa 3 el costo de tipo de Producto y las tablas de jerarquía de tipo de Producto se examinan para obtener el costo de todos los (sub)productos individuales. Sin embargo se deja al sistema de cuidado del cliente la interpretación y adaptación de esta información para el cliente. Este sistema de fijación de precios puede estar en una moneda de curso legal i nterno y el sistema de cuidado de cliente puede transformar esta moneda de curso legal en una moneda de curso legal local. En la etapa 4, asumiendo que la viabilidad mostró que era posible la implementación, la orden de la instancia creada puede emiti rse, es decir para tomar todos los datos de viabilidad y crear una o varias órdenes de instalación de producto. Esto insertará una o más órdenes de producto en las tablas de orden de Producto y resulta en un árbol de instancias de producto en las tablas de instancias de Producto. En la etapa 5, cuando llega el tiempo de entrega, finalmente es responsabilidad del procesador de aprovisionamiento para activar el producto, es decir traspasando las instancias de producto en la jerarquía de instancia de producto y para leer todos los datos y dar órdenes a los manejadores de recurso subyacentes para activar los recursos reservados. Todos los datos están almacenados en una(s) base(s) de datos de relación, ver figura 4 que muestra solamente los nombres de tabla y los campos en cada tabla que tiene relaciones hacia/desde ellas. Las tablas pueden crearse mediante lectura desde archivos de texto estándar con comandos SQL.

Claims (1)

1. REIVI N DICACIONES 1 . Un manejador de recurso para uso en una estructura de soporte operativo para manejar una red de telecomunicaciones, que comprende una disposición de base de datos de servicio y recurso que contiene información con respecto a los recursos de la red , caracterizado en que la disposición de base de datos está estructurada de manera que cada recurso en la red tiene un tiempo de existencia así como un lugar en una jerarquía de relaciones padre/hijo, y que el recurso está definido por los siguientes datos: un identificador de punto que tiene características asociadas con el mismo, en la forma de una descripción abstracta de sus capacidades, una abstracción del elemento de red común en el sentido de un grupo de puntos que son considerados para estar unidos; y una conexión que está definida por dos puntos conectados. 2. U n manejador de recurso de conformidad con la reivindicación 1 , caracterizado en que el identificador de punto posee también características asociadas con el mismo, en la forma de una lista de pares de etiqueta/valor. 3. U n manejador de recurso de conformidad con la reivindicación 1 o 2, caracterizado en que el elemento actúa como un recipiente para puntos , con la característica impl ícita que los puntos en los elementos son posibles para interconexión . 4. Un manejador de recurso de conformidad con una de las reivindicaciones 1 a 3, caracterizado en que la disposición de base de datos está estructurada para modelar una vista topológica, por ejemplo como se conectan juntos los recursos. 5. Un manejador de recurso de conformidad con una de las reivindicaciones 1 a 4, caracterizado en que la disposición de base de datos está estructurada para modelar una vista de tiempo, por ejemplo cuando existen los recursos. 6. Un manejador de recurso de conformidad con una de las reivindicaciones 1 a 5, caracterizado en que la disposición de base de datos está estructurada para modelar una vista de jerarquía, por ejemplo como están relacionados los recursos en relaciones padre/hijo. 7. Un manejador de recurso de conformidad con una de las reivindicaciones 1 a 6, caracterizado en que la disposición de base de datos está estructurada para modelar una vista característica, por ejemplo por medio de una lista de características de cada recurso. 8. Un manejador de recurso de conformidad con una de las reivindicaciones 1 a 7, caracterizado en que la disposición de base de datos está estructurada para modelar una vista de uso, es decir que recursos están combinados para formar una instancia de servicio completa y el tiempo cuando existe esa instancia de servicio. 9. Un manejador de recurso de conformidad con una de las reivindicaciones 4-8, caracterizado en que la vista topológica, la vista de tiempo, la vista jerárquica y la vista de uso están integradas en un modelo de datos para habilitar el control de cada recurso y el uso de este en las instancias de servicio. 10. Un manejador de recurso de conformidad con cualquiera de las reivindicaciones anteriores, caracterizado en que la disposición de base de datos está separada en una primera base de datos que contiene tipos de recurso e instancias de recurso y una segunda base de datos que contiene tipos de servicios e instancias de servicio. 1 1 . Un manejador de recurso de conformidad con cualquiera de las reivindicaciones anteriores, caracterizado en que los atributos de recurso y/o servicio son tecleados y en que a través de dicho tecleo es posible distinguir entre los tipos de atributo. 12. Un método de estructuración de información en una base de datos manejadora de recurso para uso en una estructura de soporte operativo para manejar una red de telecomunicaciones, que comprende una disposición de base de datos de servicio y recurso que contiene información con respecto a los recursos de red, caracterizado en las etapas de asignar a cada recurso en la red un tiempo de existencia así como un lugar en una jerarquía de relaciones padre/hijo(s) y definir cada recurso por los siguientes datos: un identificador de punto que tiene características asociadas al mismo, en la forma de una descripción abstracta de sus capacidades; una abstracción del elemento de red común en el sentido de un grupo de puntos que están considerados para estar unidos; y una conexión que está definida por dos puntos conectados. 13. Un método de conformidad con la reivindicación 12, caracterizado en la etapa de asociación del identificador de punto con características, en la forma de una lista de pares etiqueta/valor. 14. Un método de conformidad con la reivindicación 12 o 13, caracterizado en la etapa de permitir que el elemento actúe como un recipiente para puntos , con la característica impl ícita que los puntos en elementos son posibles para interconexión. 15. Un método de conformidad con cualquiera de las reivindicaciones 12 a 14, caracterizado en la etapa de estructurar la disposición de base de datos para modelar una vista topológica, es decir como se conectan juntos los recursos. 16. U n método de conformidad con cualquiera de las reivindicaciones 12 a 15, caracterizado en la etapa de estructurar la disposición de base de datos para modelar una vista de tiempo, es decir cuando existen los recursos. 17. U n método de conformidad con cualquiera de las reivindicaciones 12 a 16, caracterizado en la etapa de estructurar la disposición de base de datos para modelar una vista jerárquica, es decir como se relacionan los recursos en las relaciones padre/hijo. 18. Un método de conformidad con cualquiera de las reivindicaciones 12 a 17 , caracterizado en la etapa de estructurar la disposición de base de datos para modelar una vista característica, es decir por medio de una lista de características de cada recurso. - 19. Un método de conformidad con cualquiera de las reivindicaciones 12 a 18, caracterizado en la etapa de estructurar la disposición de base de datos para modelar una vista de uso, es decir que recursos están combinados para una instancia de servicio completa y el tiempo cuando existe esa instancia de servicio. 20. Un método de conformidad con cualquiera de las reivindicaciones 12 a 18, caracterizado en la etapa de integrar la vista topológica, la vista de tiempo, la vista jerárquica, la vista característica y la vista de uso en un modelo de datos para habilitar el control de cada recurso y el uso de este en instancias de servicio. 21. Un método de conformidad con una de las reivindicaciones 12-20, caracterizado en que comprende las etapas de: separar la disposición de base de datos en dos bases de datos separadas. mantener los datos de tipo de recurso y datos de instancia de recurso en una de las bases de datos separadas, mantener los datos de tipo de servicio y los datos de instancia de servicio en la otra de las bases de datos separada. 22. Un método de conformidad con cualquiera de las reivindicaciones 12-20, caracterizado en que comprende las etapas de: asignar tipos de recurso y/o atributos de servicio, utilizar los tipos de atributo para distinguir entre diferentes tipos de atributos. 23. U n uso de un manejador de recurso de conformidad con cualquiera de las reivindicaciones 1 a 1 1 para un manejador de tipo de servicio en una estructura de soporte operativo para una red de telecomunicaciones, para crear y mantener los modelos de tipo de servicio y sus relaciones. 24. U n uso de conformidad con la reivindicación 23, en donde los modelos de tipo de servicio proporciona una estructura para tipos de servicio, operaciones sobre tipos de servicio, parámetros sobre tipos de servicio, relaciones jerárquicas entre tipos de servicio, relación de parámetro jerárquico y transferencia de tipos de servicio y valores de parámetros asociados en requerimientos de recurso y requerimientos de tipo de servicio. 25. U n uso de conformidad con cualquiera de las reivindicaciones 23-24, para seleccionar entre diferentes tipos de servicios requeridos, diferentes tipos de recursos requeridos y diferentes instancias de servicio. 26. Un uso de conformidad con la reivindicación 25, en donde los requerim ientos de recursos seleccionados son transferidos a un manejador de recurso que ejecuta la asignación de recurso real . ! i 25 ' V RESUMEN DE LA INVENCIÓN Un manejador de recurso para uso en una estructura de soporte operativo para manejar una red de telecomunicaciones comprende una base de datos de servicio y recurso que contiene información con respecto a los recursos de red. La disposición de base de datos está estructurada de manera que cada recurso en la red tiene un tiempo de existencia así como un lugar en una jerarquía de relaciones padre/hijo(s). El recurso está definido por los siguientes 10 datos: un identificador de punto que tiene características asociadas con el mismo en la forma de una descripción abstracta de sus capacidades; una abstracción del elemento de red común en el sentido de un grupo de puntos que están considerados para estar unidos; y una conexión que está definida por dos puntos conectados. 15 20 25 ., ^««-matfbtí**^** . , , . . n ^..^^-Wí] t íli'