MXPA01003970A

MXPA01003970A - Metodo y aparato para desplegar modulos de servicio entre nodos de servicio distribuidos en una red inteligente.

Info

Publication number: MXPA01003970A
Application number: MXPA01003970A
Authority: MX
Inventors: Andrew Dugan
Original assignee: Andrew Dugan
Priority date: 1998-10-20
Filing date: 1999-10-20
Publication date: 2003-03-10
Also published as: EP1123618B1; EP1131730A1; MXPA01003971A; AU6522099A; HK1039009B; WO2000024182A1; IL142662A0; DE69914952T2; HK1044249A1; BR9914647A; ATE279831T1; DE69910816T2; DE69921169T2; JP2002528966A; EP1157529B1; CN1338175A; AU773432B2; ATE260012T1; HK1044652B; EP1157529A1

Abstract

1. Un sistema de administracion de servicios para distribuir recursos de procesamiento de servicios entre uno o mas nodos de servicio de una red de comunicaciones inteligente, cada nodo de servicio proporcionando servicios en un recurso de la red asociado con un nodo de servicio, el sistema comprendiendo: a) un dispositivo para recibir componentes de servicio que se pueden volver a usar, para proporcionar servicios en un nodo de servicio de la red de comunicaciones inteligente, cada uno de esos componentes de servicio teniendo un perfil de servicio asociado que define los recursos del nodo de servicio que se requieren para almacenar, mantener y ejecutar ese servicio; b) un dispositivo para recibir criterios de configuracion que incluyen la capacidad de recursos fisica de cada nodo de servicio de dicha red; c) un dispositivo de base de datos para almacenar los componentes de servicio recibidos, los criterios de configuracion de nodo de servicio, y el perfil de servicio asociado con los componentes de servicio; d) un mecanismo de distribucion para distribuir copias de los componentes de servicio a uno o mas nodos de servicio, de conformidad con la informacion de perfil de servicio asociada con un servicio, y un criterio de configuracion de los nodos de servicio; y e) un mecanismo activador para activar y desactivar automaticamente el componente de servicio distribuido al nodo de servicio, en donde se optimiza la utilizacion de los recursos del nodo de servicio mediante la activacion de los componentes de servicio en los nodos de servicio, durante periodos de alta demanda para un servicio asociado, y la desactivacion de los componentes de servicio en los nodos de servicio durante periodos de baja demanda de ese servicio. 2. Un metodo para administrar componentes de servicio a uno o mas nodos de servicio, que comprende una red inteligente, cada nodo de servicio proporcionando uno o mas servicios relacionados con un evento recibido en un recurso de la red asociado con un nodo de servicio, el metodo comprendiendo los pasos de: a) recibir componentes de servicio que se pueden volver a usar, para proporcionar servicios en un nodo de servicio de la red de comunicaciones inteligente, cada uno de dichos componentes de servicio teniendo un perfil de servicio asociado que define los recursos del nodo de servicio que se requieren para almacenar, mantener y ejecutar ese servicio; b) recibir criterios de configuracion que incluyen la capacidad de recursos fisica de cada nodo de servicio de esa red; c) mantener una base de datos que incluya copias maestras de los componentes de servicio recibidos, los criterios de configuracion de nodo de servicio, y el perfil de servicio asociado con esos componentes de servicio; d) distribuir las copias de los componentes de servicio a uno o mas nodos de servicio, de conformidad con la informacion de perfil de servicio asociada con un servicio, y un criterio de configuracion de los nodos de servicio; y e) enviar un activad.

Description

MÉTODO Y APARATO PARA DESPLEGAR MÓDULOS DE SERVICIO ENTRE NODOS DE SERVICIO DISTRIBUIDOS EN UNA RED INTELIGENTE La presente invención se relaciona generalmente con Redes inteligentes, y, más particularmente, con un sistema de administración novedoso para desplegar paquetes de servicios y componentes que incluyen programas ejecutables y datos para dar servicio a nodos, capaces de dar servicio al procesamiento en una red inteligente distribuida. En general, una red de comunicaciones sirve para transportar información entre muchas ubicaciones. Una red de comunicaciones comercial, tal como la red telefónica conmutada pública, le pertenece a, y le proporciona ingresos a un proveedor de servicios. Los suscriptores pagan al proveedor de servicios por el acceso a los servicios de comunicaciones que proporciona la red. Existen una diversidad de tecnologías de transporte que se usan en las redes de comunicaciones, y una diversidad de tipos de información y formatos que comúnmente se transportan. En su forma más simple, un servicio de comunicaciones envuelve el transporte en tiempo real de información, tal como señales de datos o de voz, entre ubicaciones a las que sirve la red. En una red telefónica comercial, este servicio básico típicamente llega a establecer un canal de voz en dos sentidos, entre un par de suscriptores del servicio telefónico. Más allá de las comunicaciones básicas, algunas redes pueden ofrecer servicios más avanzados. Por ejemplo, una red telefónica puede proporcionar características mejoradas tales como envío de llamadas o correo de voz. Para accesar o invocar estas características, un suscriptor usualmente interactúa con la red de alguna manera, tal como presionando una secuencia de teclas en el teclado del teléfono. Mediante esta interacción, la red realiza las funciones deseadas a solicitud de cada usuario o suscriptor. Las acciones del usuario, tales como levantar el aparato telefónico de un receptor de teléfono, o presionar teclas en un teclado del teléfono, son eventos que reconoce la red de comunicaciones. Otros eventos, tales como alarmas de falla del equipo, los puede generar internamente la red durante su operación. La inteligencia que controla la red, en cualquier forma, debe recibir y procesar estos eventos, y dirigir los elementos de manejo de tráfico de la red, para tomar la acción apropiada al proporcionar servicios, y recuperarse de fallas parciales de la red. Aunque una red telefónica sirve como un ejemplo bien entendido en el presente contexto, aquellos de experiencia en la técnica reconocerán que se pueden diseñar y operar otros tipos de redes, para proporcionar servicios de una manera análoga. Por ejemplo, se puede usar una red de datos para transportar información que representa archivos de datos o corrientes de datos de video y audio. Los ejemplos de servicios mejorados en una red de datos incluyen capacidades de almacenar - y - enviar datos y difusión múltiple. Otros tipos de servicios de la red pueden estar dirigidos a ayudar a un propietario de la red con seguridad, validación, y autentificación de usuarios y administradores de la red. Las redes de telecomunicaciones típicas están compuestas de nodos interconectados por enlaces de comunicaciones. Cada nodo es un sitio que- típicamente comprende equipo, tal como un conmutador de dominio de espacio o de - dominio de tiempo, o un encaminador de conmutación por paquetes, que se usa para dirigir el flujo de información. Muchos nodos también proporcionan equipo que interconecta a los usuarios a la red. Los nodos están conectados mediante enlaces de transmisión, de tal manera que la información pueda fluir de nodo a- nodo y, mediante lo mismo, viajar desde un nodo de origen hasta un nodo de destino, por medio de la red. El equipo de conmutación, los encaminadores, y otro equipo en los nodos en una red, deben estar apropiadamente coordinados para asegurar que el flujo de información y otros servicios se proporcionen para satisfacer las necesidades de los usuarios de la red. - Los conmutadores adentro de los nodos de una red telefónica típica se controlan por medio de procesadores integrados o incrustados, operados por software o microprogramación propietarios, mantenidos por cada fabricante de conmutadores. La adición o modificación de un servicio requiere que se hagan cambios en el software que controla una red de comunicaciones. Tradicionalmente, el software o microprogramación del fabricante del conmutador proporciona algunas o todas las funciones del procesamiento de servicios, y otros tipos de procesamiento relacionados con la red. Esto significa que cuando un propietario de la red desea implementar un nuevo servicio o modificar un servicio existente, los diferentes fabricantes de conmutadores deben revisar el software de cada conmutador en la red. El hecho de que una red grande usualmente contenga una diversidad de conmutadores de diferentes fabricantes, necesita el desarrollo, prueba y despliegue cuidadosos del nuevo software, antes de la publicación en una red que lleve tráfico vivo. El tiempo que se requiere para desarrollar, probar y desplegar el nuevo software es prolongado debido a que el tamaño del código en cada conmutador crece más grande y más complejo con cada nueva revisión. Por esta razón, los cambios de código pueden tomar muchos meses para implementarse. En adición, esta complejidad incrementada también carga los procesadores de conmutadores, incrementa las oportunidades del mal funcionamiento del conmutador, y hasta puede requerir la modificación o el reemplazo del hardware anticuado del conmutador. Además, una nueva característica o función algunas veces requiere un cambio en un modelo operativo básico o interfase que esté estandarizado dentro de la industria de comunicaciones. Los cambios de esta magnitud pueden requerir la ratificación por parte de los grupos de estándares de la industria - un proceso que puede retrasar la introducción de una nueva característica por muchos años. Existen inconveniencias adicionales al depender de componentes de software propietario en los productos de diferentes vendedores de conmutadores . El hecho de que múltiples propietarios de la red dependan de un conjunto común de fabricantes de conmutadores da como resultado situaciones indeseables que limitan la competencia. La publicación del software de un fabricante puede intentar incorporar cambios requeridos por muchos propietarios de la red, evitando de esta manera que los propietarios de la red diferencien verdaderamente sus servicios de los servicios que proporciona su competencia. Esto también obliga a algunos propietarios de la red a esperar por una nueva característica deseada mientras el fabricante incorpora solicitudes de otros propietarios de la red dentro de la nueva publicación. Además, una publicación de software de conmutador que incorpore una función según la solicite un propietario de la red, para implementar un nuevo servicio, se puede volver accesible de manera no intencional a otros propietarios de la red. Estos problemas se han vuelto intolerables a medida que se ha incrementado exponencialmente la demanda de nuevos servicios de la red, durante los últimos cinco a diez años debido a la movilidad incrementada de los suscriptores, las incrementadas diversidad y amplitud de banda de tráfico, la disolución de planes de numeración tradicionales, el despliegue de servicios más sofisticados y la competencia incrementada entre los proveedores de servicios. De esta manera, se reconoce ampliamente que las nuevas arquitecturas de control de la red necesitan incorporar una manera más flexible para crear, desplegar y ejecutar la lógica de servicios. ~~ Una nueva arquitectura de control de la red a la que se hace referencia como "IDNA" difiere de la técnica anterior en cuando menos tres aspectos importantes. Primeramente, el procesamiento de servicios se remueve completamente de elementos portadores de tráfico individuales, tales como conmutadores y encaminadores. Esto elimina la dependencia de la función del servicio del software propietario residente en el conmutador. En segundo lugar, el procesamiento del servicio ocurre en un ambiente de procesamiento de "máquina virtual", y la funcionalidad del procesamiento existe en la forma de objetos administrados adentro de este ambiente. Finalmente, se introduce una plataforma unificada para creación de servicios, prueba de servicios, y despliegue de servicios, y procesamiento de servicios, ofreciendo muchas ventajas significativas. La terminología "complejo de recursos" describe la colección de componentes de la red que debe controlar un sistema de control de red inteligente, para implementar los servicios para los usuarios. El complejo de recursos generalmente comprende conmutadores, equipo de transmisión, y similares, que directamente manejan y encaminan el tráfico de información a través de la red. L complejo de recursos también puede comprender los llamados recursos especiales tales como sistemas de respuesta de voz automatizados, sistemas de correo de voz, canceladores de eco, dispositivos de almacenamiento de datos, y componentes de conversión de datos, para nombrar algunos. En el contexto de una red que implementa servicios como objetos administrados dentro de procesadores de servicios, lo que se desea también es un elemento para coordinar el despliegue de los objetos administrados y otros componentes, para dar servicio a los procesadores, con el propósito de implementar nuevos servicios, sin tener impacto en la confiabilidad de la red. Esa coordinación puede acarrear, por ejemplo, la verificación de interdependencias entre elementos del software, que deben estar presentes en cada procesador de servicios. Además, a medida que se despliega la función de servicios a diferentes procesadores de servicios, se requiere algún elemento para sincronizar y coordinar de otras maneras la activación de nuevos servicios, de tal manera que, en el momento de la activación, un número adecuado de procesadores de servicios estén equipados para suministrar de manera cooperativa el nuevo servicio. De manera similar, se desea algún elemento para coordinar la desactivación de componentes de procesamiento de servicios, sin tener impacto en la operación de la red. También pudiera ser deseable desplegar selectivamente la funcionalidad de servicios a ciertos procesadores de servicios en base a, por ejemplo, las capacidades de hardware en ciertos sitios, o a reglas o criterios arbitrarios, establecidos por ingenieros de la red. Esas reglas o criterios pueden lograr el equilibrio de carga o el procesamiento de ubicación preferido ("pasar a página principal") entre procesadores de servicios. En donde un cierto ambiente de creación de servicios está acoplado a un despliegue de servicios y ambiente de procesamiento de servicios, se desea algún elemento para asegurar la validez de los componentes del servicio. Por ejemplo, se desea algún elemento para proporcionar tanto seguridad de acceso como control de versión de los objetos administrados, para proteger la integridad de los componentes del servicio. Además, durante el despliegue de los componentes del servicio como objetos administrados, se desea algún elemento para asegurar que se despliegue una versión correcta de cada objeto administrado, aún si pudieran existir muchas versiones de un componente dado en el sistema, en un momento dado. Esto es especialmente importante porque es probable que se mantengan las versiones más antiguas de los objetos administrados para propósitos de respaldo y regresión, y porque las versiones más nuevas no publicadas también se almacenarán en el ambiente de creación y despliegue mientras se estén desarrollando y probando. La presente invención está dirigida a un sistema de comunicaciones que comprende un administrador de servicios que controla la distribución de objetos administrados entre los nodos de procesamiento de servicios. El administrador de servicios mantiene un depositario conocido co o una "base de datos global de registro" (DBOR) , en donde se almacenan las funciones del servicio como objetos administrados. El administrador de servicios es responsable de nombrar, catalogar, distribuir, activar, auditar, desactivar y remover todos los objetos administrados y datos que se usaron para el procesamiento del servicio en una red. - En una modalidad ejemplar preferida, la red de comunicaciones, de conformidad con la presente invención, también comprende un ambiente de creación de servicios, en donde se pueden desarrollar y probar los objetos administrados. El ambiente de creación de servicios está acoplado a la red a través del administrador de servicios. El administrador de servicios proporciona tanto seguridad de acceso, como control de la versión para los objetos administrados que están almacenados en la base de datos de registro. La creación de servicios se realiza por medio de recuperar los objetos administrados de la DBOR por medio del administrador de servicios. Los objetos administrados que son recién creados o modificados en el ambiente de creación de servicios también se someten al administrador de servicios para almacenamiento en la DBOR. En una modalidad ejemplar preferida adicional, los objetos administrados que se distribuyen a cada nodo de procesamiento de servicios, se mantienen en una base de datos de registro local en cada nodo. La base de datos de registro local en cada nodo de procesamiento de servicios es un extracto de la DBOR global que mantiene el componente del administrador de servicios de la red. En todavía otra modalidad ejemplar preferida, la base de datos de registro local en cada nodo de procesamiento de servicios la mantiene cuando menos un componente de administración de datos. El componente de administración de datos hace disponibles los objetos administrados y otros datos a los procesadores de servicios, en el nodo de procesamiento de servicios. En particular, el componente de administración de datos sirve como un almacén persistente para los objetos administrados, operando datos tales como información de conexión de nodo adyacente, y otros datos creados durante el procesamiento de servicios. El componente de administración de datos también controla la duplicación de los objetos administrados dentro de diferentes ambientes de ejecución de lógico de servicios (SLEE's), en el nodo de procesamiento de servicios. . En virtud de mantener un almacenamiento local, el componente de administración de datos proporciona la restauración rápida de las operaciones normales después de, o en respuesta a, una falla del equipo de la red, cambio de mantenimiento, u otras circunstancias similares. Por ejemplo, si el elemento de hardware de procesamiento de servicios falla repentinamente, se puede duplicar el contexto del procesamiento de servicios en otro procesador, y reanudar el servicio sin interrupción. El tener los datos y los objetos administrados almacenados localmente en cada nodo de procesamiento de servicios, permite pasar sobre las fallas y recuperarse rápidamente, sin los retardos asociados con la recuperación de los objetos administrados del componente de administrador de servicios de la red. Los ingenieros de la red pueden implementar reglas adentro del componente de administración de datos, que determinan cómo y cuándo se duplican los objetos administrados. El componente de administración de datos verifica la descarga exitosa y exacta de los objetos administrados de la DBOR. Igualmente, el componente de administración de datos verifica la copia exacta de los objetos administrados entre los procesadores de servicios, según se necesite. La función de administración de servicios amplios de la red y el componente de administración de datos en cada nodo de procesamiento de servicios, cooperan para asegurar que los objetos administrados que abarcan la funcionalidad de servicio, estén correctamente distribuidos y activados. Además, los componentes de administración de servicios y de administración de datos pueden coordinar la distribución de los objetos administrados, en base a los atributos de hardware de la red, tales como la disponibilidad de equipo especializado en ciertos nodos de procesamiento de servicios. Por ejemplo, un nodo de procesamiento de servicios dado puede incluir una unidad de respuesta de voz como un recurso especial en su dominio de complejo de recursos. De conformidad con lo anterior, los objetos administrados especializados, relacionados con el control y manejo de tráfico para este recurso especializado se distribuyen selectivamente, activan y ejemplifican concretamente en este nodo de procesamiento de servicios dado. Entre otros nodos de procesamiento de servicios que no tienen este recurso, no se debe cargar la base de datos de registro local para cada nodo, con el mantenimiento de los objetos administrados especializados en apoyo de este recurso especial. En una modalidad ejemplar preferida de la presente invención, el administrador de servicios asume las mismas funciones de control y monitoreo de un sistema de administración de la red tradicional (NMS) . Por ejemplo, las alarmas de falla que normalmente reporta el equipo de la red a un sistema de administración de la res, las monitorea y procesa el administrador de servicios. Además, como con un NMS tradicional, el administrador de servicios se comunica directamente con el equipo de la red, por medio de enlaces de control, y puede desempeñar el control remoto de la operación del equipo. Desde un punto de vista práctico, el administrador de servicios comparte con mucho el mismo grado de conectividad con los elementos de procesamiento de servicios de la red, y el equipo de manejo de tráfico que el NMS tradicional. Por lo tanto, para evitar la redundancia, es conveniente el simplemente combinar la funcionalidad del NMS dentro del administrador de servicios. La misma DBOR que se usa para almacenar la función del servicio como objetos administrados, también puede almacenar datos de la red tales como información de topología e índices de identificación de equipo. Esta integración es particularmente conveniente en el sentido de que se pueden usar el conocimiento actual de la topología de la red, el despliegue del equipo y el estado de operación, para determinar de manera responsiva en dónde y cuándo desplegar los objetos administrados que implementan las funciones del servicio. En todavía otra modalidad ejemplar preferida de la presente invención, la red de comunicaciones comprende adicionalmente un sistema operativo de la red (NOS) que proporciona conectividad de comunicaciones entre los elementos funcionales de la red de comunicaciones. El NOS proporciona conectividad independiente de la plataforma e independiente de la ubicación entre los componentes de control de la red. Además, el NOS comprende algunos componentes funcionales adicionales, que generalmente están disponibles para todos los elementos de control de la red para administrar, por ejemplo, la utilización de objetos administrados ejemplificados concretamente, entre todos los ambientes de procesamiento de servicios en una red. Se pueden entender mejor las ventajas anteriores y otras de la presente invención, por medio de referirse a la siguiente descripción en conjunción con los dibujos acompañantes, en los que: La Figura 1 es un diagrama lógico y funcional de un sistema de telecomunicaciones que emplea una arquitectura de red distribuida inteligente, de conformidad con una modalidad preferida de la presente invención. La Figura 2 es un diagrama que ilustra cómo se mapean las funciones de control de la red requeridas, en componentes funcionales, de conformidad con una modalidad preferida de la presente invención. La Figura 3 (a) ilustra conceptualmente la funcionalidad del componente de administración de servicios 500. La Figura 3 (b) ilustra la arquitectura física del componente de administración de servicios. La Figura 3 (c) ilustra la arquitectura funcional general del componente de Administración de Servicios 500 del sistema IDNA/NGIN 100. La Figura 3 (d) ilustra el esquema que emplea el SA para actualizar la DBOR. La Figura 3{e) ilustra el esquema que emplea el SA para distribuir datos desde la DBOR a los componentes de administración de datos. La Figura 3(f) ilustra la arquitectura funcional del componente de Administración de Datos 600. Las Figuras 3(g)-3(i) ilustran diagramas de flujo que ilustran generalmente las fases de creación y despliegue de servicios del sistema IDNA/NGIN. - La presente invención está dirigida a un administrador de servicios que administra el desarrollo y despliegue de objetos administrados, en el contexto de una arquitectura de control de red que usa esos objetos. En particular, el administrador de servicios asegura la integridad de los objetos administrados y otros datos necesarios para el control de la red y el procesamiento de servicios. Esto, a su vez, asegura la operación confiable de la red aún a medida que se implementan nuevos servicios. En el presente contexto, se hace referencia a una arquitectura de control de la red adentro de la cual pueda estar incluida la presente invención, como la Arquitectura de Red Distribuida Inteligente/arquitectura de Red Inteligente de la Siguiente Generación, o simplemente se designa como la arquitectura o sistema IDNA/NGIN. De conformidad con lo anterior, se puede hacer referencia a un nodo de procesamiento de servicios como un nodo IDNA/NGIN. Refiriéndonos ahora a la Figura 1, se describirá y se denota generalmente como 200 un sistema de telecomunicaciones que emplea una arquitectura de red distribuida inteligente (IDNA) , de conformidad con la presente invención. La Red de Área Ancha ("WAN") 202 es un sistema de comunicaciones de datos que soporta la distribución de aplicaciones y datos a través de un área geográfica ancha. De preferencia, la red de transporte que se usa para implementar la WAN 202 se basa en la Red Óptica Sincrónica ("SONET") , y conecta los nodos de procesamiento de servicios 204, habilitando las aplicaciones adentro de esos nodos para comunicarse unos con los otros a altas velocidades. Cada nodo de procesamiento de servicios 204 incluye cuando menos un procesador de servicios 172 y un complejo de recursos. La .Figura 1 ilustra un nodo de procesamiento de servicios 204 que tiene un Complejo de Recursos A ("RCA") 206 y un Complejo de Recursos B ("RCB") 208. En la Figura 1 se muestran muchas terminales de usuario 159 de ejemplo conectadas al RCA 206. La terminal ISDN 159a, la máquina de facsímil 159b, el teléfono 159c, y el intercambio privado de ramificación (PBX) 159d son todos ejemplos del equipo mediante el cual los usuarios accesan los servicios de la red 200. Un complejo de recursos, tal como el RCA 206, comprende equipo que maneja directamente el tráfico de información del usuario que transporta la red. El equipo y otros recursos dentro del complejo de recursos los controlan los procesadores de servicios, para proporcionar transporte de información y otros servicios que necesitan los usuarios de la red. El procesador de servicios 172 puede estar conectado a uno o más Procesadores Adjuntos 210, los cuales tradicionalmente proporcionan funciones de apoyo, tales como abastecimiento, facturación, y restauración. Estas funciones las puede absorber la funcionalidad- que proporciona un Sistema de Administración de la Red ("NMS") 212. En la modalidad preferida, sin embargo, estas funciones de apoyo se pueden incluir también en un sistema de Administración de Servicios ("SA") centralizado 500, como se describe posteriormente. Como se muestra adicionalmente en la Figura 1, el procesador de servicios 172 puede estar enlazado también a otros procesadores de servicios 172 por medio de la- LAN 213, a otras redes (no se muestran) , o a otros dispositivos (no se muestran) , a través de un enlace directo 214 que tenga el enlace de señalización 216 y el enlace portador 218. El enlace directo le permite a los dispositivos enviar la señalización directamente al procesador de servicios, y evita la latencia y otras restricciones (tales como formato de datos) asociadas con la presentación de la señalización a través del complejo de recursos. El procesador de servicios 172 es el "cerebro" del nodo de procesamiento de servicios 204, y es de preferencia una computadora de uso general, que puede ir de un simple sistema de computación de un solo procesador a una red de computadoras a gran escala, dependiendo de los requerimientos de procesamiento del nodo de procesamiento de servicios 204. De preferencia, la computadora de uso general tendrá procesamiento redundante, almacenamiento de memoria y conexiones.

Cada procesador de servicios 172 opera cuando menos un ambiente de ejecución de lógico de servicio (SLEE) 173, en donde los objetos administrados se ejemplifican concretamente e interactúan para realizar la función de procesamiento de servicios. Un Periférico Inteligente ("IP") 88 proporciona la habilidad para procesar y actuar sobre la información contenida adentro de la trayectoria de transmisión de llamada actual. Los IP' s 88 generalmente están en un Complejo de Recursos separado, tal como el RCB 208, y los controlan los procesadores de servicios 172 de una manera similar al RCA 206. Por ejemplo, algunas variedades de IP' s pueden proporcionar procesamiento en tiempo real después de las señales de voz en una trayectoria de transmisión de llamada, usando tecnología de Procesamiento de Señal Digital ("DSP") . El Sistema de Administración de la Red ("NMS") 212 tradicionalmente se usa para monitorear y controlar el hardware y los servicios en el procesamiento de servicios 200. La implementación del NMS 212 puede ser una Red de Administración de Telecomunicaciones ("TMN") - construcción condescendiente que proporciona la administración de los componentes adentro de la red 200. En una modalidad preferida, por razones prácticas, el NMS 212 está incluido adentro del administrador de servicios 500. El NMS 212 puede monitorear y controlar directamente el estado operacional del RCA 206 y el RCB 208, a través del enlace de operaciones estándar 226, como es bien sabido en la técnica. Como se muestra adicionalmente en la Figura 1, un Ambiente de Creación de Objeto Administrado ("MOCE") 228 incluye subcomponentes para crear servicios que se ejecutan en la red de comunicaciones 200. El Bloque de Edificación Independiente de Servicios (SIBB) y API, representaciones que usa un diseñador de servicios para crear nuevos servicios, están incrustados adentro del subcomponente primario de MOCE, una Inferíase de Usuario Gráfica ("GUI"). El MOCE 228 es una colección unificada de herramientas albergadas en un ambiente o plataforma de un solo usuario, al que también se hace referencia como un Ambiente de Creación de Servicios (SCE) . Este representa la colección de operaciones que se requieren a lo largo del proceso de creación de servicios, tales como documentación del servicio, definición del objeto administrado, definición de la interfase, definición del protocolo y definición de entrada de datos, que están encapsuladas en los objetos administrados, y la prueba del servicio. El propietario de la red únicamente tiene que desarrollar un servicio una vez, usando el MOCE 228, porque los objetos administrados se pueden aplicar a todos los nodos en su red. Esto está en contraste con el propietario de la red que tiene cada uno de los diferentes fabricantes de conmutadores desarrollando su versión del servicio, en cuyo caso el servicio tendría que desarrollarse múltiples veces. La Figura 2 es un diagrama de Venn útil para describir cómo los elementos funcionales de la presente invención se relacionan con los elementos funcionales necesarios para administrar los datos de --a red y los recursos de computación. La Figura 2 contiene muchos elementos funcionales que se describen en detalle en otros lugares. Brevemente, el depositario 230 sirve como un punto central de almacenamiento para todos los datos, tales como objetos administrados, tablas de encaminamiento o tablas de conversión, necesarios para una red de comunicaciones. La función administrativa 595 en la Figura 2 representa el control central del despliegue de datos y objetos administrados a los procesadores de servicios de la red, asi como el abastecimiento y la activación de los servicios . La administración de recursos del nodo (NODE RM) 575 se refiere a la coordinación en tiempo real de objetos ejemplificados concretamente y recursos de datos dentro del reino de un nodo de procesamiento de un solo servicio. Esto permite la participación e invocación, independiente de la ubicación, de los objetos relacionados con el servicio. Por ejemplo, pueden estar presentes muchos procesadores en un nodo de procesamiento de servicios, y estar conectados mediante una red de datos local, tal como una Red de rea Local (LAN) . Cuando un primer objeto de servicio que se está procesando en una primera computadora necesita un segundo objeto de servicio que está disponible en otra computadora en el nodo, la NODE RM 575 es la función mediante la cual el primer objeto de servicio puede encontrar rápidamente y emplear el segundo objeto, sin importar el hecho de que el segundo objeto se esté ejecutando en una computadora diferente. De manera similar, la administración de recursos del sistema (SYS RM) 585 en la Figura 2 se refiere a la coordinación en tiempo real de objetos ejemplificados concretamente y recursos de computación en una escala en toda la red, es decir, entre nodos de procesamiento de servicios. Finalmente, en la Figura 2 está incluido un ambiente de creación de servicios, especialmente un ambiente de creación de objeto administrado (MOCE) 228, para representar el punto en donde se crean y prueban originalmente los objetos administrados. De conformidad con la arquitectura IDNA descrita anteriormente, una función administrativa 595 y la SYS RM 585 casi correspondieron a una sola entidad, a saber el NMS 212. La NODE RM 575 casi corresponde a una llamada función de agente ICP-NMS 240 descrita en la arquitectura IDNA. El depositario 230 y el MOCE 228 son esencialmente equivalentes a los elementos nombrados de manera similar descritos en la arquitectura IDNA. En una modalidad preferida de la presente invención, las funciones en la Figura 2 están agrupadas de manera diferentes, como sigue: Las funciones de coordinación de recursos en tiempo real de la SYS RM 585 y la NODE RM 575 están abarcadas por el sistema operativo de la red (NOS) 700. Mientras que el depositario 230 representa el almacenamiento persistente de los objetos de datos de la red, el perfil del administrador de datos (DM) 600 representa que el almacenamiento persistente también se distribuye entre los nodos de procesamiento de servicios. Además, de conformidad con una modalidad preferida de la presente invención, la función administrativa 595 está integrada con el depositario 230, para formar el administrador de servicios (SA) 500. Mediante este agrupamiento, el SA 500 se convierte en un guardián de puerta o bibliotecario que protege la integridad de los objetos de datos almacenados en el depositario 230. Hasta el MOCE 228 debe pasar a través del SA 500 para almacenar y recuperar objetos de datos. Como se muestra conceptualmente en la Figura 3 (a) , el componente de Administración de Servicios 500 es un componente que realiza todas las funciones necesarias para administrar, almacenar, y distribuir todos los servicios y datos del servicio que usan los nodos de procesamiento de servicios, y para configurar los componentes tanto de hardware como de software a lo largo del sistema de control de la red que se ilustra en la Figura 1. Generalmente, como se muestra en la Figura 3 (a) , el componente SA 500 es responsable de: catalogar y almacenar los objetos creados y los datos del MOCE (Creación de Servicios) 228; regresar copias oficiales de los objetos administrados y datos al MOCE 228 para propósitos de desarrollo 'del servicio; recibir paquetes de servicios terminados y probados, SIBBs, SLPs u otros componentes de servicios o datos 506 desde el MOCE 228; recibir datos de orden del cliente 502 de la entrada de orden y otros sistemas legales 229 para la provisión del sistema IDNA/NGIN para que lo usen los clientes; proporcionar nombres únicos a cada componente de servicio; y, desplegar los objetos administrados y datos a los procesadores de servicios de la red, por medio de las funciones de Administración de Datos 600, como se describirá con mayor detalle en la presente. En adición, como se muestra en la Figura 2, el componente de Administración de Servicios 500 mantiene el depositario 230. El depositario 230 incluye principalmente una Base de Datos de Registro global ("DBOR") que comprende todos los servicios de IDNA, y datos a partir de los cuales cada componente de Administración de Datos 600 recibe finalmente todos sus datos. Otras responsabilidades de la Administración de Servicios incluye: activar datos y componentes de servicio 512 para asegurar que todos los datos, SIBBs y objetos administrados o programas lógicos de servicios , SLPs, estén disponibles para los nodos, por medio del componente de Administración de Datos 600; registrar los nombres de los datos, SLPs y SIBBs 515 por medio de alimentar- sus nombres lógicos a un componente del Sistema Operativo de la Red ("NOS") 700, que se describirá en detalle posteriormente, para registro con el mismo; desactivar datos y componentes de servicio 518; y, remover datos y servicios 521 del sistema IDNA/NGIN, .por medio del componente de Administración de Datos 600. La Administración de Servicios adicionalmente realiza una función de administración de configuración por medio de mantener el estado de cada SIBB y servicio (probado previamente, probado posteriormente, desplegado, etcétera) , en adición a crear versiones a través de su proceso de nombramiento. Esto asegura que no se despliegue un servicio hasta que se hayan probado y configurado exitosamente todos los componentes de ese servicio. El componente de Administración de Servicios 500 también realiza la función de configurar y abastecer los nodos de servicio IDNA/NGIN 204, de conformidad con la información de configuración que recibe el SA. Particularmente, en base a la información de configuración recibida, el componente SA 500 determina las capacidades de cada componente en cada nodo de servicio 204, cuáles servicios y datos distribuir a qué nodos, qué servicios se ejecutarán en cuál (es) servidor (es) residente (s) en el nodo de servicio, y qué datos se pondrán en memoria caché a la memoria local residente asociada con el (os) servidor (es) de nodo IDNA/NGIN. Particularmente, el SA despliega las reglas de configuración contenidas en los archivos de perfil de servicios (configuración) 580, a un componente de Administrador de Recursos Local (nodo) ("LRM") 575 del sistema NOS 700 para almacenamiento en la memoria caché LRM local, localizada en cada nodo de servicio. Como se describirá con mayor detalle en la presente, estos archivos de configuración 580 determinan cuáles servicios ejecutar en un nodo IDNA. El LRM primero lee este archivo de perfil de servicio 580 almacenado en la memoria caché local en ese nodo, y determina un Ambiente de Ejecución de Capa de Servicio ("SLEE") específico, por ejemplo, una máquina virtual, para ejecutar un servicio de conformidad con las reglas en el archivo de perfil de servicio, cuáles servicios se van a ejecutar activamente (como objetos persistentes) en el SLEE, o se van a ejemplificar concretamente solamente sobre su demanda.

La Figura 3 (b) ilustra una arquitectura física preferida para el componente de Administración de Servicios 500. Aunque la Administración de Servicios es una función centralizada, ésta pudiera estar incluida como dos o más sitios de Administración de Servicios redundantes, por ejemplo, los sitios 550a, 550b, para confiabilidad en cada sitio SA que comprende: Servidores SA 560, que pueden comprender procesadores redundantes dobles, con una configuración de disco compartido que comprende la DBOR 230; y, una computadora personal (PC) o estación de trabajo 556a, b, residente en cada sitio respectivo 550a, 550b que tiene una interfase para habilitar acceso al usuario a todas las funciones de Administración de Servicios, y particularmente inicia la distribución de datos y servicios a nodos de servicio IDNA/NGIN especificados, que se ilustran en la Figura 3 (b) como los nodos de servicio 204. Las funciones de activación de distribución de datos y servicios mencionadas anteriormente, se ejecutan todas en uno o más servidores SA 560 que se encuentran en cada sitio. Los componentes en cada sitio SA 550a, b respectivo están conectados por medio de una LAN de Ethernet 559, que, a su vez, está enlazada a una WAN 566 para comunicación con los nodos de servicio. Refiriéndonos de nuevo a la Figura 2, el componente de Administración de Datos NGIN 600 funciona en una capacidad tanto de ciclo de vida del servicio, como de utilización del servicio. Mientras que el componente de Administración de Servicios 500 mantiene la base de datos de registro global (depositario) 230, el componente de Administración de Datos 600 proporciona las funciones de almacenamiento de datos local y administración de datos para cada nodo de procesamiento de servicios IDNA/NGIN 204. Esto incluye todos los tipos de datos necesarios para procesamiento de servicios, tales como: programas de servicios y SIBBs, datos para servicios (perfiles de clientes, números telefónicos, etcétera) , archivos de múltiples medios (tales como archivos de audio para servicios de Respuesta de Voz Interactiva ("IVR") ) , etcétera. Específicamente, el componente de Administración de Datos 600 de un nodo de servicio recibe un extracto de la DBOR global de SA, que comprende todos los datos necesarios para los servicios realizados por el nodo de servicio NGIN local, según lo especifica la Administración de Servicios. La Figura 3(c) ilustra una modalidad física preferida que resalta los componentes funcionales principales de, y las interfases externas al componente de Administración de Servicios 500 de la invención. Como se muestra en la Figura 3 (c) , el componente de Administración de Servicios 500 comprende un subcomponente de Distribución de Datos 510 que: 1) permite comunicaciones confiables con sistemas externos; 2) realiza cualesquier funciones de conversión y formateo de datos, para recibir datos desde sistemas externos, y distribuir datos del SA a sistemas externos, típicamente a través de el intermediario de una Interfase de Programa de Aplicación de Distribución de Datos (DDAPI) común 505; 3) extrae datos de los mensajes de comunicaciones recibidos desde los sistemas externos, para entrada a un subcomponente de Administrador de Inventario 516; 4) proporciona una función de distribución de múltiples puntos para paquetes de servicios/datos con una característica de almacenar y enviar, y servicios garantizados de envío y recuperación; y 5) permite el envío de conjuntos de datos en secuencia, en adición a la verificación de espacio intermedio, verificación de duplicado, reconocimientos de recepción, y asegura la seguridad de las transmisiones de datos. Como se muestra en la Figura 3 (c) , los dispositivos de alimentación de entrada al componente SA incluyen: un dispositivo de alimentación 506 desde el'MOCE/SCE 228, desde el cual "se alimentan paquetes y módulos SIBB que se usan para construir servicios; un dispositivo de alimentación de Entrada de Orden ("OE") 502, desde la cual se introducen los datos del cliente para realizar funciones de abastecimiento de servicios; y, uno o más dispositivos de alimentación del sistema de Abastecimiento de Ambiente ("EP") 508, desde los cuales se introducen las especificaciones del usuario para dirigir el SA 500, y cómo y dónde distribuir los servicios creados por el componente MOCE 228. Más particularmente, con respecto al dispositivo de alimentación del sistema de abastecimiento de Ambiente 508, cada componente de nodo de servicio que se considere parte del ambiente de procesamiento de servicios NGIN (hardware de la computadora, sistema operativo, SLEE, memorias caché locales de la Administración de Datos) se especifica con un perfil de nodo de servicio, que comprende las capacidades físicas de ese nodo (por ejemplo, capacidad de almacenamiento, capacidad de memoria, capacidad de procesamiento de computadora, etcétera) . Por medio de una versión GUI de la GUI del sistema EP 508 (no se muestra) , un usuario especifica, en base al perfil del nodo de servicio (capacidades) de cada nodo de servicio, un perfil de servicio que comprende cuáles objetos de servicio (por ejemplo, SLPs, SIBBs, datos, etcétera) se van a desplegar a cuáles SLEEs en cuáles nodos, cuáles datos se van a desplegar a cuáles nodos, y, la estrategia de colocación en memoria caché local de cada SLEE y computadora. Estas especificaciones se introducen al SA y los usa el subcomponente de Administrador de Ambientes 530, para especificar la distribución correcta de servicios y datos. Más específicamente, la interfase del sistema de Abastecimiento de Ambientes se usa para introducir los perfiles del nodo de servicio, así como para dirigir la distribución de los perfiles del servicio a los nodos de servicio apropiados. Los nodos de servicio se pueden comparar con los perfiles del servicio automáticamente, en base a las capacidades del nodo de servicio y los requerimientos del perfil del servicio, sin embargo, un perfil del servicio puede especificar que se seleccione manualmente un nodo de servicio. Si un perfil del servicio solicita que éste se compare contra los nodos de servicio manualmente, el servicio no se distribuirá hasta que se haga la comparación usando el sistema EP 508. Si el perfil del servicio solicita que el servicio se distribuya automáticamente, el servicio se puede comparar y distribuir automáticamente, sin embargo, la interfase de Abastecimiento de Ambientes puede pasar por alto esto, y cambiar la distribución en un tiempo posterior. La API de Distribución de Datos 505 proporciona la interfase estándar para utilizar todas las funciones del SA, y además interactúa con el subcomponente de Distribución de Datos, para proporcionar servicios de envio/recuperación garantizados. Particularmente, la DDAPI 505 proporciona un conjunto de mensajes estándar para que lo utilicen los clientes de administración de servicios, que son los componentes de Administración de Datos local de cada nodo de servicio. El sistema SCE y EP también están diseñados para interconectarse con la Administración de Servicios por medio de la DDAPI . Otros sistemas externos, sin embargo, tales como los sistemas OE 229, pudieran no estar diseñados para utilizar la DDAPI, y, consecuentemente, se puede usar un proceso de mediación 511 para adaptar el protocolo de comunicaciones y los formatos de mensajería de esos sistemas externos a la DDAPI 505. Como se muestra érT la Figura 3 (c) , solamente se requiere una sola DDAPI 505 y el proceso de Distribución de Datos 510 para todas las interfases externas. Todos los sistemas externos que se interconectan con la Administración de Servicios tienen acceso a todas sus funciones, dependiendo de los privilegios que se le permitan a cada uno. Esto asegura que funciones tales como las actualizaciones DBOR, por ejemplo, se manejen todas de la misma manera, sin importar quién las inicie, y, además, elimina el procesamiento de caso especial. Esto también asegura que la misma integridad de datos verifique que se proporcionen a algunos sistemas (por ejemplo, OE) , se proporcionen a otros sistemas (por ejemplo, Elementos de la Red), y además, fomenta el desarrollo de sistemas externos para que se ínterconecten con la Administración de Servicios. Como se muestra también en la Figura 3(c), el componente SA 500 comprende los siguientes subcomponentes: un Administrador de Inventario 516; un Administrador de DBOR 520; un Administrador de Ambientes 530; un Administrador de Auditoría y Reconciliación 535, y, un Administrador de Monitoreo y Registro 540. Ahora se explicarán con mayor detalle las funciones de cada uno de estos. El subcomponente de Administrador de Inventario 516 recibe todas las entidades de datos desde fuentes externas, por medio del proceso de Distribución de Datos 510. Estas entidades de datos incluyen servicios y SIBBs de la Creación de Servicios, datos del servicio, y datos del cliente de los dispositivos de alimentación del sistema de entrada de orden 502, y especificaciones de la configuración y el abastecimiento del ambiente de los dispositivos de alimentación de Abastecimiento de Ambiente 508. El Administrador de Inventario 516 proporciona un nombre único a cada entidad de datos recibida, de conformidad con un convenio de nombramiento determinado previamente. Este incluye múltiples versiones de la misma entidad de datos. El Administrador de Inventario también asegura la integridad de los datos entre los datos recibidos desde múltiples fuentes, y resuelve cualesquier conflictos. Por ejemplo, si el Administrador de Inventario recibe de dos fuentes OE diferentes, dos terminaciones de red diferentes (resueltas por haber aplicado cualesquier características de encaminamiento inteligente) para el mismo número telefónico del cliente sin cargo, el Administrador de Inventario detectará esto por medio de realizar una auditoría en cada entidad de datos recibida. Después de la detección, éste pudiera ya sea realizar un algoritmo de resolución (por ejemplo, mantener la terminación de la red con la estampa de fecha/hora más reciente) , o notificar al usuario acerca del conflicto. El Administrador de Inventario almacena entonces la entidad de datos nombrada en la DBOR 230. Este usa un Administrador de DBOR 520 para almacenar de hecho los datos en la DBOR. El Administrador de Inventario también notifica al Administrador de Ambiente de cualesquier actualizaciones a la DBOR. El Administrador de DBOR 520 proporciona una sola interfase a la DBOR 230 para los múltiples componentes funcionales de la Administración de Servicios, y realiza todas las funciones de administración de base de datos (añadir, borrar, recuperar, modificar, etcétera) . Esta es una función significativa, en el sentido de que la DBOR puede comprender de hecho múltiples bases de datos, con el propósito de almacenar múltiples tipos de datos: SLPs para servicios, SIBBs, conjuntos de datos para datos del cliente y del servicio, datos de múltiples medios para servicios IVR, etcétera. De preferencia, la DBOR comprende tanto bases de datos de objetos como bases de datos relaciónales. Estas bases de datos las pueden proporcionar diferentes vendedores, y, por lo tanto, requieren diferentes conjuntos de comandos para realizar las funciones de administración de base de datos. El Administrador de DBOR 520 encapsula estas variaciones de los otros componentes de Administración de Servicios, de tal manera que cualquier componente que necesite una función DBOR realizada, simplemente implementa un conjunto de comandos común proporcionado por el Administrador de DBOR, y un nombre de entidad de datos. El Administrador de DBOR 520 usa el nombre de entidad de datos proporcionado, y adapta el comando requerido a un formato que use el tipo de base de datos específico, para realizar la función requerida. Existen tres subcomponentes de Administración de Servicios que se interconectan con el Administrador de DBOR; el Administrador de Inventario 516, el Administrador de Ambiente 530, y un Administrador de Auditoría y Reconciliación 535. El subcomponente de Administrador de Ambiente 530 es responsable de desplegar servicios y datos de la DBOR a los componentes de Administración de Datos local en los nodos de servicio NGIN. Este hace esto por medio de determinar primero cuáles entidades de servicios/datos necesitan distribuirse a cuáles nodos; después emitir los comandos de distribución apropiados, junto con las entidades de datos extraídas de la DBOR, a la Distribución de Datos. Las especificaciones de abastecimiento de ambiente que introduce un usuario por medio de los dispositivos de alimentación del sistema EP 508, se almacenan en la DBOR y las usa el Administrador _de Ambientes para determinar la distribución. De esta manera, la Administración de Servicios distribuye a cada nodo de servicio NGIN únicamente aquellas entidades que necesitará ese nodo de servicio. Esta característica reduce los requerimientos de almacenamiento en cada nodo de servicio y amplitud de banda de la red, y el tiempo de procesamiento/transmisión necesario" para la distribución de datos. Esta habilita adicionalmente la distribución de red ancha de las funciones NGIN, mediante la simplificación de la integridad de datos, puesto que se minimiza el número de copias de una entidad de datos. Se debe entender que las funciones del Administrador de Ambiente pueden requerir procesamiento complejo por parte de la Administración de Servicios, pero esta complejidad se encapsula fácilmente en reglas de distribución, que aplica el Administrador de Ambiente. Adicionalmente, el Administrador de Ambiente 530 • presenta un nivel valioso de configuración que se proporciona a la arquitectura del sistema NGIN. Esto es, aunque se pueden desplegar todos los datos a todos los nodos de servicio, para habilitar todos los servicios en cada nodo, esto no es necesario. Un usuario puede decidir cuáles servicios presentar a cuáles nodos, para optimizar el diseño de la red, después desplegar los datos necesarios para esos servicios a esos nodos. Al Administrador de Ambiente 530 se le puede notificar adicionalmente, por medio del Administrador de Inventario o del Administrador de DBOR, siempre que se modifique la DBOR, por ejemplo, cuando se ha reemplazado un servicio con una nueva versión. El Administrador de Ambiente 530 se asegura de que cada nodo de servicio en el que se tenga impacto se actualice (es decir, reciba la nueva versión del servicio) . Cuando éste recibe la notificación de una actualización de DBOR, éste identifica cada nodo de servicio que use los datos actualizados, o que proporcione el servicio actualizado, y después distribuye las actualizaciones a los componentes de Administración de Datos local en cada nodo de servicio impactado, como se describe en la presente. El Administrador de Auditoría y Reconciliación (A/R) 535 asegura la sincronización de datos entre la DBOR y sus múltiples extractos, por medio de ejecutar rutinas de auditoría para comparar los datos en la DBOR 230, con los datos en cualquiera de los diferentes extractos de la DBOR. Este determina entonces las acciones correctivas para volver a sincronizar las múltiples bases de datos. Para implementar estas acciones, el Administrador de A/R genera un paquete de datos que contiene datos y comandos para procesar estos datos. Este paquete de datos se proporciona entonces a cualesquiera bases de datos que se necesite para implementar la acción correctiva para volver a sincronizar las múltiples bases de datos. De preferencia, esto se puede realizar como sigue: 1) durante el tiempo inactivo del sistema, éste puede ejecutar una rutina de auditoría para buscar y resolver cualesquier discrepancias entre los datos en la DBOR, y los datos en un extracto de la DBOR, que puede residir en una base de datos de Administración de Datos local en un nodo de » servicio; y, 2) durante el procesamiento de llamada en tiempo 5 real, si una aplicación" de servicio encuentra una discrepancia, por ejemplo, a una aplicación de servicio se le da una clave para una búsqueda de datos en la Administración de Datos, consulta una base de datos con esta clave, pero no encuentra ningún registro, la aplicación genera una alarma. • 10 Esta alarma se envía al Administrador de A/R 535, que resuelve la discrepancia. El subcomponente de Monitoreo e Inicio de Sesión 540 es un proceso que monitorea el funcionamiento y la estabilidad de los procesos de Administración de Servicios, y 15 registra ciertos o todos los eventos realizados, de tal manera que un usuario pueda ver posteriormente cuáles datos se desplegaron a cuáles nodos y cuándo, por ejemplo. Como se describió, la DBOR global 230 puede ser una o más bases de datos físicas, divididas para almacenar y 20 administrar los muchos tipos diferentes de datos y servicios que incluyen: SLPs, SIBBs, datos del servicio y datos del cliente, por ejemplo, perfiles del cliente que incluyen información de registro de llamada, planes de faxes y encaminamiento, y archivos de múltiples medios que incluyen 25 mensajes de correo de voz y otros archivos u objetos de audio y video para servicios interactivos. Aunque puede existir una pluralidad de DBORs para redundancia y capacidad de supervivencia, la DBOR 230 es un almacén lógico individual de todos los servicios y datos NGIN, para distribución a cualesquier y todos los otros componentes y procesos funcionales NGIN. Como se muestra adicionalmente en la Figura 3 (c) , el componente SA 500 implementa el componente NOS 700 para proporcionar comunicaciones entre los diferentes procesos de Administración de Servicios. Por ejemplo, la DDAPI 505 usa los servicios NOS para proporcionar un conjunto de mensajes que use los mecanismos de comunicaciones de NOS Para habilitar interfases entre sistemas externos y la Distribución de Datos 510, y entre la Distribución de Datos 510 y los otros subcomponentes SA. El NOS 700, sin embargo, no se requiere para comunicaciones entre los componentes de Administrador de Inventario, Administrador de Ambiente, Administrador de A/R, y Administrador de DBOR, a medida que se diseñan estos procesos, en una modalidad física preferida, para ejecutarse en el mismo sistema de computación. Se debe entender que aún en un ambiente de computación distribuido, en el que estos procesos se ejecutan en diferentes sistemas de computación, estos procesos se pueden comunicar unos con los otros, usando otras APIs internas y protocolos de comunicaciones, por ejemplo, enchufes TCP/IP. Para los técnicos expertos será evidente cómo proporcionar todos los procesos internos de la Administración de Servicios con la capacidad para usar el NOS para las comunicaciones interprocesos . Habiendo descrito la modalidad preferida del componente SA 500, ahora se proporciona una descripción más detallada de los principales servicios que realiza la Administración de Servicios 500, con referencia a las Figuras 5(c)-5(e) . Como un primer servicio principal, como se menciona, el SA 500 es responsable de nombrar y realizar la creación de versiones de servicios y datos. Esto es, el SA proporciona un nombre único a cada versión de toda entidad de servicios/datos, antes de almacenar la entidad de servicios/datos en la DBOR 230, de tal manera que se puedan mantener múltiples versiones de la misma entidad de servicios/datos. Cuando el SA distribuye los datos/servicios a la Administración de Datos, se proporciona un solo nombre lógico con cada entidad, junto con un nombre de versión único, de tal manera que procesos tales como SLPs puedan llamar una entidad de servicios/datos con un nombre lógico común, sin tener que saber cuál versión se necesita. Se debe entender que los requerimientos de registro de nombre proporcionan un entendimiento detallado de la necesidad de que los nombres de datos, SIBB, y SLP sean únicos, y para que el componente SA 500 de NGIN mantenga la copia maestra de estos diferentes componentes. A medida que se proporcionan k los datos, SIBBs y SLPs al SA, el creador de esos componentes los ha identificado usando un nombre de usuario. Este nombre 5 de usuario proporciona una manera para que el MOCE/SCE identifique el componente, en sus términos; este nombre de usuario se identifica entonces de manera única con el nombre lógico individual, (es decir, una referencia común) . De preferencia, el SA implementa un acuerdo de estructura de 10 nombramiento cuando nombra componentes nuevos y modificados y, de preferencia mantiene un mapeo entre el nombre de usuario y los nombres únicos del sistema lógico. En la realización de una solicitud de datos, SLPs, y SIBBs, el SA puede proporcionar el nombre del usuario, en adición al 15 nombre único del sistema lógico. Como un segundo servicio principal, el componente de administración de servicios 300 es responsable del abastecimiento de servicios, es decir, de abastecer servicios con los datos necesarios para proporcionar esos servicios. 20 Este tipo de datos se introducen al SA desde el dispositivo de alimentación de entrada de Orden 502, y se almacena en la DBOR global 230 antes de la distribución a la Administración de Datos 600. Este tipo de datos pueden incluir, pero no están limitados a, datos de perfil del cliente, tales como 25 opciones de servicio del cliente, nombre del cliente y datos de la cuenta, números telefónicos de terminación, datos de encaminamiento de llamadas, y cualesquier datos potencialmente necesarios para procesar y terminar una llamada para un servicio. Como un ejemplo, cuando se establece un servicio 1-800 en la Creación de Servicios para un cliente corporativo, se necesitan el nombre de ese cliente, la información de cuenta/facturación, el (os) número (s) telefónico (s) 800, las direcciones de red de terminación, las opciones de servicio (características de encaminamiento, identificadores de archivos de múltiples medios) recibidos desde el sistema OE, para abastecer el (os) servicio (s) particular (es) . En esta función, la Administración de Servicios 500 analiza sintácticamente los dispositivos de alimentación de entrada de orden apropiados, para crear un registro de entrada de orden consolidado y consistente a la NGIN, y se asegura de que se reconozca cada alimentación recibida desde un sistema de entrada de orden, o desde un sistema de abastecimiento. Como un tercer servicio principal, el componente SA 500 es responsable del abastecimiento de soporte de servicios, es decir, de configurar los ambientes de procesamiento NGIN (hardware, sistemas operativos, SLEE(s), sitios, LANs de sitio y WANs entre sitios) , y del abastecimiento de datos que especifiquen estas configuraciones. Específicamente, cada nodo de servicio IDNA/NGIN tiene un perfil de nodo de servicio asociado que se introduce al SA por medio del subcomponente de Abastecimiento de Ambiente 508 (Figura 3 (c) ) , y especifica las capacidades del sistema de computación, las funciones que asigna el sistema de computación, y los tipos de servicios que se pueden soportar en cada nodo de servicio. En la Tabla 1 se ilustra un perfil de nodo de servicio de ejemplo, que puede estar incluido como un archivo de datos formateado en el SA, como sigue: TABLA 1 Por lo tanto, en el perfil de ejemplo de la Tabla 1, se especifica: un nombre de nodo, un sistema operativo para la computadora que ejecuta los programas lógicos del servicio, la cantidad de memoria, las unidades de comunicación de disco y datos, una indicación de que el nodo es capaz de recibir datos específicos del cliente desde el SA (acceso de administración de datos) , y que el nodo puede soportar características de servicio especiales, por ejemplo, capacidad de reproducción de voz. Se debe entender que la Tabla 1 de ejemplo puede incluir otros tipos de información asociada con la cantidad de recursos y capacidades asociados con un nodo de servicio particular. Adicionalmente generado en el SA para cada servicio está un perfil de servicio, que puede estar incluido como un archivo de datos formateado en el SA, que especifica los requerimientos de ese servicio y a cuáles SLEE(s) y/o computadoras dentro de la red se deben desplegar. En la Tabla 2 se ilustra un perfil de servicio de ejemplo, para un servicio particular que se va a desplegar en la red, como sigue: TABLA 2 En la Tabla 2, se especifica: un nombre de perfil del servicio, por ejemplo, el servicio #1001 para el cliente X; la cantidad de unidades de procesamiento, memoria, y el espacio de disco requerido para ejecutar el servicio cuando se ejemplifica concretamente; un campo (s) de ejemplificación concreta del nodo, que especifica un rango de tiempo cuando se va a ejemplificar concretamente un servicio particular (incluido como un programa lógico de servicio, por ejemplo) , de conformidad con una regla (s) de negocios determinada previamente, especificada (s) en la Administración de Servicios, y un campo (s) mín/max correspondiente (s) , que indica (n) el número mínimo y máximo de aquellos objetos de servicio (SLPs) que puede ejemplificar concretamente el NOS durante el tiempo de rango especificado; un campo (s) de requerimientos especiales que indica (n) , por ejemplo, que el servicio requiere una capacidad de nodo de servicio particular, por ejemplo, reproducción de voz; y una fecha de inicio del servicio y una fecha de fin del servicio. Es fácilmente evidente que el SA puede distribuir el servicio (y el perfil del servicio) del servicio 1001 de ejemplo de la Tabla 2, al nodo de servicio que tenga el perfil de nodo de servicio que se ilustra en la Tabla 1, puesto que el nodo tiene claramente los requerimientos de memoria y el soporte de reproducción de voz. Adicionalmente es evidente que el servicio #1001 de ejemplo que se ilustra en el perfil de servicio en la Tabla 2, requiere un conjunto de datos del cliente X que comprendería, inter alia, un anuncio de servicio de reproducción de voz específico a ese servicio #1001 que proporciona el cliente X. El componente SA 500 recibirá datos por medio del dispositivo de alimentación de entrada de orden 307 que incluye el anuncio de reproducción de voz del cliente X, y el administrador de inventario del SA los asignará como un conjunto de datos #1001, por ejemplo, para almacenamiento en la DBOR 230. De esta manera, el SA puede distribuir automáticamente el conjunto de datos #1001 al (os) nodo(s) de servicio que proporcionan el servicio #1001 para el cliente X. Estos perfiles de nodo de servicio (por ejemplo, la Tabla 1) y los perfiles de servicio (por ejemplo, la Tabla 2), se introducen al SA y se almacenan en el mismo para habilitar el rastreo automático de: 1) las capacidades de cada nodo de servicio, es decir, cuántas computadoras y SLEE(s), y la capacidad de recursos de cada uno; 2) cuáles servicios y datos se van a desplegar a cuáles nodos de servicio y cuándo; y 3) la configuración de la ejecución del servicio, por ejemplo, en qué momentos un SLP debe ejecutarse persistentemente contra ejecutarse sobre la demanda, por ejemplo. Las capacidades de cada nodo y computadora en la red se mantiene, de tal manera que se pueden aplicar reglas de negocios simples y complejas, que gobiernen la distribución de datos/servicios, la activación de datos/servicios y la remoción de datos/servicios, para optimizar la ejecución de los servicios en los nodos de servicio IDNA/NGIN. De esta manera, una parte de la función de abastecimiento de soporte de servicio es determinar cuál servicio ejemplificar concretamente como un objeto persistente (para ejecutarlo activamente) en cuál SLEE, con reglas basadas en uno o más criterios que incluyan, por ejemplo, equilibrio de carga entre los nodos de servicio, eficiencias del encaminamiento de llamadas de la red, y demanda de servicios. Ahora sigue un ejemplo de esta función de abastecimiento de soporte de servicio. Puesto que algunos servicios son más sensibles al tiempo que otros, se puede usar el grado de tolerancia que pueden tener las personas que llaman por los retrasos en un cierto tipo de servicio, para determinar si ese servicio se ejecuta activamente en el SLEE como un objeto persistente, por ejemplo, y si los datos para ese servicio se van a poner en memoria caché a la memoria local para reducir la latencia.

Cuando se considera la demanda del servicio, un cierto servicio puede ver demandas pico, por ejemplo, en la noche.

Entonces el SA 500 le permite a un usuario especificar un SLP para que este servicio se ejecute activamente (se ejemplifique concretamente como un objeto persistente en el SLEE) de 5:00 pm a 12:00 media noche, tiempo local para cada sitio, por ejemplo, y que se ejemplifique concretamente solamente sobre la demanda en otras horas. Una regla en el archivo de perfil de servicio (Tabla 2_) generado por el SA reflejará esto. Como un cuarto servicio principal, el componente SA 500 es responsable de distribuir los servicios y datos al componente funcional de Administración de Datos local, en los nodos del sistema IDNA/NGIN seleccionados, de conformidad con las estrategias especificadas por el usuario. Estas estrate ias están incluidas como especificaciones en el paquete de servicios creado en el Ambiente de Creación de Servicios 228, y además como especificaciones introducidas por el usuario por medio del SA 500, como parte de su función de abastecimiento de soporte de servicio. Incluida en esta función está la habilidad del SA para rastrear el estado actual (por ejemplo, probado, desplegado) de los datos, SIBBs, y SLPs. No solamente rastrea éste el estado, sino que adicionalmente rastrea las versiones actuales de datos, SIBBs, y SLPs y los diferentes componentes (es decir, datos, SIBBs, y SLPs) necesarios para crear una versión específica (incluyendo las diferentes dependencias) de un servicio. En la DBOR global, el SA almacena cada versión de un servicio (es decir, incluyendo todos los SLPs encapsulados en un SLP de servicio) y, además, rastrea la configuración (por ejemplo, la dirección física) de los diferentes depositarios de Administración de Datos, por ejemplo, extractos de DBOR, a través de la red IDNA/NGIN Además, el componente SA 500 rastrea los servicios y datos que se han distribuido, con el propósito de asegurar la integridad. Por ejemplo, si un servicio se despliega exitosamente a un nodo, pero falla la distribución de los datos necesarios para ese servicio, el SA detecta esto y, ya sea reintenta la distribución de los datos, o le notifica al usuario. Si después de un número definido previamente, que se puede configurar de reintentos, el depositario designado es incapaz de recibir la distribución, el SA genera una alarma y almacena la distribución pendiente. Además de la función de distribución del SA para distribuir datos, SIBBs y SLPs a la Administración de Datos, el SA también es responsable de: 1) distribuir SLPs, SIBBs y datos a un ambiente de prueba de integración de la red para prueba de extremo a extremo; 2) habilitar a un usuario autorizado para configurar un tiempo preestablecido para una distribución; por ejemplo, ahora (sobre la demanda) , hoy al mediodía, mañana a las 3 p.m.; 3) iniciar las distribuciones en base a un tiempo preestablecido; por ejemplo, desplegar un archivo de voz mañana a la 1:15 a.m.; 4) definir reglas de distribución que designen cuáles depositarios de administración de datos NGIN van a recibir SLPs, SIBBs y datos; 5) determinar las ubicaciones para distribuir los datos en base a reglas de distribución definidas previamente; 6) verificar el estado de un depositario designado (por medio de consultar el componente NOS de NGIN) antes de una distribución; 7) intentar la distribución de todos los depositarios designados que reporten una indicación en línea y, si un depositario designado está reportando una indicación fuera de línea, almacenar la distribución para ese depositario para envío futuro; 8) enviar todas las distribuciones pendientes a un depositario, una vez que se reciba una indicación en línea desde un depositario designado que previamente estaba fuera de línea; 9) monitorear las distribuciones a la Administración de Datos. Por ejemplo, si una distribución es para una versión nueva de una entidad de SLP, SIBB o datos existente, el SA asegura que cuando se reciba la distribución, no se escriba sobre los datos existentes en la Administración de Datos; 10) recibir indicaciones del estado de distribuciones exitosas y no exitosas de la Administración de Datos y, actualizar el estado de todos los datos en base a las indicaciones de estado de distribución exitosa/no exitosa, recibidas desde la Administración de Datos; y 11) registrar todas las distribuciones a la Administración de Datos. En este punto, es necesario distinguir entre los procesos internos que se requieren para actualizar la DBOR 230, como se ilustra en la Figura 3 (d) , y los procesos internos que se requieren para distribuir paquetes de servicios y extractos de datos de la DBOR, como se ilustra en la Figura 3 (e) . Se requieren procesos Separados, ya que el formato de los datos mantenidos en la DBOR 230 difiere del formato de los datos introducidos desde las fuentes externas, y del formato de los datos en los extractos para distribución. De esta manera, para realizar auditorías significativas- y asegurar la integridad y sincronización de los datos, el proceso de actualización de la DBOR que se ilustra en la Figura 3 (d) requiere la invocación del proceso de administrador de Inventario 516 y el proceso de administrador de la DBOR 520. Cuando se extraen datos de ia DBOR a los diferentes agentes SA (clientes DM) , se requiere la invocación del proceso de administrador de Ambiente 530 y el proceso de administrador de la DBOR 520, como se ilustra en la Figura 3 (e) . De esta manera, la implementación de estos procesos separados permite auditorías de la DBOR con datos de sistemas de entrada, y auditoria?' de la DBOR con datos extraídos que se están o se han estado distribuyendo al NGIN) , antes de enviar las solicitudes de activación; 5) intentar la activación en todos los depositarios designados que reporten una indicación en línea, y, si un depositario designado está reportando una indicación fuera de línea, almacenar la solicitud de activación para ese depositario para envío futuro, y no intentar la activación en ese depositario. Si un depositario designado reporta una indicación en línea, y por alguna razón es incapaz de procesar la solicitud de activación, el SA vuelve a intentar la activación a ese depositario. Si después de un número de reintentos definido previamente, que se puede configurar, el depositario designado es incapaz de procesar la solicitud de activación, el SA genera una alarma y almacena la activación pendiente. Una vez que se recibe una indicación en línea desde un depositario designado que previamente estaba fuera de linea, la Administración de Servicios envía todas las distribuciones y activaciones pendientes a ese depositario; y &) recibir las respuestas de activación de una Administración de Datos. Si una solicitud de activación indica un éxito en todos los depositarios designados, el SA registra el nombre único del sistema de los datos, SIBB o SLP, y las ubicaciones físicas de la información con el NOS. Se debe entender que el nombre de ubicación física incluye una identificación del nombre de componente de hardware. En la modalidad preferida, el SA determina, en base a NGIN) , antes de enviar las solicitudes de activación; 5) intentar la activación en todos los depositarios designados que reporten una indicación en línea, y, si un depositario designado está reportando una indicación fuera de línea, almacenar la solicitud de activación para ese depositario para envío futuro, y no intentar la activación en ese depositario. Si un depositario designado reporta una indicación en línea, y por alguna razón es incapaz de procesar la solicitud de activación, el SA vuelve a intentar la activación a ese depositario. Si después de un número de reintentos definido previamente, que se puede configurar, el depositario designado es incapaz de procesar la solicitud de activación, el SA genera una alarma y almacena la activación pendiente. Una vez que se recibe una indicación en línea desde un depositario designado que previamente estaba fuera de línea, la Administración de Servicios envía todas las distribuciones y activaciones pendientes a ese depositario; y &) recibir las respuestas de activación de una Administración de Datos. Si una solicitud de activación indica un éxito en todos los depositarios designados, el SA registra el nombre único del sistema de los datos, SIBB o SLP, y las ubicaciones físicas de la información con el NOS. Se debe entender que el nombre de ubicación física incluye una identificac ón del nombre de componente de hardware. En la modalidad preferida, el SA determina, en base a las reglas de distribución definidas previamente y a las respuestas de activación recibidas desde la Administración de Datos 600, si los datos se han activado en suficientes ubicaciones para hacerlos disponibles a los objetos administrados de control del servicio. Si la Administración de Servicios determina que los datos se pueden hacer disponibles al control del servicio, el SA registra el nombre de datos único del sistema y las ubicaciones de datos físicas de todas las ubicaciones de distribución y activación exitosas con el NOS. Si los datos activados van a reemplazar los datos existentes en la red, el SA asegura un proceso de transición suave para terminar el procesamiento del servicio existente en los datos antiguos, mientras que inicia nuevo procesamiento del servicio en los nuevos datos. Los datos antiguos se desactivan una vez que se completa en éstos todo el procesamiento del servicio, como se explicará con mayor detalle en la presente. Más específicamente, como parte del paso de activación de servicios/datos, el SA implementa un activador que provoca la descarga del perfil del servicio en el momento apropiado. Cuando se descarga un perfil de servicio (por ejemplo, como se muestra en la Tabla 2) a un nodo de servicio, el perfil de servicio incluye las horas de inicio y fin del servicio. El perfil de servicio se descarga al nodo de servicio, por medio de proporcionar la información en la Administración de Datos, como se describirá con más detalle con respecto a la Figura 3(f) . Al NOS, actuando como un cliente DM, se le notifica del cambio en la información de perfil de servicio por medio de la API DM. En una modalidad preferida, el SA envía un mensaje a una función de Conversión de Nombre NOS en cada SLEE en el cual se ejecutará el servicio, para dirigir una función de conversión de nombre para volver a apuntar el nombre lógico para el servicio a la dirección- física o referencia de objeto de la versión que se está activando. Finalmente, el SA rastrea las características de la plataforma depositaría, para asegurar que cuando se activen los datos, SIBBs o SLPs, éstos trabajen en la plataforma apropiada; actualiza el estado de los datos, SIBB o SLP, en base a una activación o desactivación; y, registra todas las activaciones de datos, SLPs y SIBBs con el componente lógico de monitoreo 540 (Figura 3 (c) ) . De conformidad con esta quinta función del SA, ahora se proporciona una explicación de cómo el sistema IDNA/NGIN maneja las fases de construcción y despliegue del servicio, con referencia a las Figuras 5 (g) y 5 (h) , que ilustran un escenario de pasos para construir y desplegar un SLP para el sistema IDNA/NGIN, por ejemplo, para un servicio 1-800-Cobrar ("1-800-C") . Como se indica en el paso 812 en la Figura 3 (g) , el programa de aplicación de MOCE/SCE le permite al usuario accesar desde el SA todos de SIBB, SLP, datos y otros bloques de edificación que son necesarios para la creación dei SLP 1-800-C. en el contexto de ejemplo del servicio 1-800-, esos bloques de edificación pueden incluir: un bioque de edificación de audio de reproducción, un bloque de edificación de dígitos de cobrar y un bloque de edificación de reconocimiento de voz. Las copias de estos bloques de edificación apropiados se extraen de la DBOR 230 global, por medio del SA dentro deJ MOCE/SCE, para proporcionar cl fundamento para desarrollar el Programa Lógico de Servicio 1-800-C, como se indica en el paso 814, Figura 3 (g) . Después, como se indica en el paso 819, el Programa Lógico de Servicio 1-800-C y todos los datos asociados tales como archivos de voz, se prueban como unidad adentro del ambiento MOCE/SCE. Después, como se indica en el paso 820, el Programa Lógico de Servicio 1-800-C se prueba de extremo a extremo en un ambiente de laboratorio, que se asemeja mucho a la red MCI en tiempo real, para asegurar que el Programa Lógico de Servicio se ejecute correctamente una vez distribuido en la red. Después, como se indica en el paso 823, el programa Lógico de Servicio 1-800-C se presenta a la Administración de Servicios para nombramiento y catalogación de la manera descrita con detalle en la presente, antes de su distribución. Como se describe en la presente, el componente de Administración de Servicios permite la introducción de reglas que gobiernan la distribución de datos e información, la activación de datos y la remoción de datos. De esta manera, como se indica en el paso 826, el componente SA verifica las reglas que especifican los depositarios de la Administración de Datos, que van a recibir el Programa Lógico de Servicio y, las reglas respecto al número mínimo de depositarios que deben recibir la distribución, antes de permitir la activación del SLP 1-800-C. para hacer esto, como se indica en el paso 830, la Administración de Servicios verifica el estado de los depositarios de la Administración de Datos, por medio de accesar la función de Administración de Recursos de la Red NOS. Después, como se muestra en el paso 832, Figura 3 (h) , el componente de Administración de Servicios determina aquellos depositarios DM que indican el estado "En linea" y, en el paso 835, distribuye el SLP 1-800-C a todos los depositarios DM que estén en línea. Para aquellos depositarios que reportan' un estado fuera de línea, la Administración de Servicios almacena la distribución para envío futuro al depositario fuera de línea, como se indica en el paso 837. Después, como se indica en el paso 840, el componente de Administración de Servicios espera hasta que la Administración de Datos regresa un estado para cada depositario, que indica el éxito o la falla de la distribución. En el paso 842 se hace una determinación para determinar si se ha recibido la confirmación del depositario DM respectivo. Si no se recibe la confirmación, el SA espera la confirmación, como se indica en el paso 844. Una vez que se recibe la confirmación, el proceso continúa al paso 845, en donde la Administración de Servicios hace una determinación en cuanto a si se puede activar el SLP 1-800-C en todos los depositarios en donde se recibió exitosamente la distribución. Particularmente, la Administración de Servicios hace la determinación de si se puede activar el SLP 1-800-C, en base a la combinación de los siguientes criterios de activación: 1) el estado de distribución, 2) el estado de dependencia de datos y 3) reglas definidas previamente. Esto es porque la Administración de Servicios 500 realiza la función de asegurar, que se completen todas las dependencias de datos del programa lógico del servicio; es decir, que estén distribuidos y activados, antes de permitir la activación de un SLP dependiente de esos datos. De esta manera, en el contexto del ejemplo, si el SLP 1-800-C usa otro Programa Lógico de Servicio (por ejemplo, un SLP interconectado a una Base de Datos de Información en Línea) durante su ejecución, la Administración de Servicios asegura que el otro SLP o base de datos se haya distribuido y activado antes de permitir la activación del SLP 1-800-C. Se debe entender que algunos servicios se pueden activar aún si todos los depositarios designados no reciben la distribución del Programa Lógico de Servicio. Esto es dependiente de muchos factores que incluyen: el volumen de llamada esperado, y la calidad del servicio, según se especifique en las reglas de distribución y activación en el SA. Por ejemplo, pudiera ser suficiente que un servicio de volumen de llamadas bajo particular se almacene únicamente en dos depositarios DM en la red, antes de ser activado, mientras que otros requieren que el servicio esté ubicado en todos los depositarios designados, antes de que éste se pueda activar para recibir el tráfico. De esta manera, en la Figura 3 (h) , paso 847, se hace entonces una determinación en base a la satisfacción de los criterios de activación. Si no se puede activar el SLP, el SA esperará hasta que se satisfagan los criterios de activación del SLP, como se indica en el paso 848. De otra manera, como se indica en el paso 852, el SA envía una solicitud de activación a todos los depositarios de Administración de Datos designados. Después, como se indica en el paso 854, la Administración de Datos procesa la solicitud de activación, y envía una respuesta de activación para cada depositario a la Administración de Servicios, que indica el éxito o la falla de la activación. En base a las respuestas de activación exitosas, recibidas desde la Administración de Datos, la Administración de Servicios registra el nombre único del sistema SLP 1-800-C, y las ubicaciones de datos físicas con el NOS, como se indica en el paso 855 y, en el contexto del ejemplo, ahora está disponible el Servicio 1-800-C para utilización. Cualesquier depositarios de datos que fueron incapaces de recibir la distribución y/o activación del SLP 1-800-C no se registran con el NOS como una ubicación de datos física válida para este Programa Lógico de Servicio. Como un sexto servicio principal, precisamente cuando el SA habilita la distribución y activación de los componentes del servicio, - el componente SA 500 permite la descomisión y remoción de los componentes del servicio, de los nodos de servicio. Los principales pasos envueltos son la planeación, desactivación, desinstalación y/o descomisión de sus partes asociadas, y la prueba para ver las consecuencias adversas. Por ejemplo, después de un período de inactividad del servicio, o según lo especifique el usuario, cuando ya no se necesita un servicio en un nodo particular, la administración de servicios removerá, es decir, desactivará el servicio, tipicamente por medio de enviar un mensaje al NOS, la NT habilita la remoción de un servicio de los nodos de servicio IDNA/NGIN por medio de enviar un mensaje al componente de Administración de Datos local, para borrar ese servicio. Los requerimientos respecto a la función SA de la desactivación y remoción de servicios/datos incluyen: 1) habilitar a un usuario autorizado para solicitar la desactivación de una entidad SLP, SIBB o de datos, y para especificar un tiempo para una desactivación; 2) verificar las dependencias de estado y datos del SLP, SIBB, o datos, antes de enviar una solicitud de desactivación a la Administración de Datos. Si el estado del SLP, SIBB, o de los datos está activo y no existen dependencias de datos, el SA des - registra el SLP, SIBB o los datos con el NOS después de llegar al tiempo especificado que proporciona el SLP, SIBB o los datos, como ya no disponibles para el Procesamiento de Servicios; 3) después de la terminación del des - registro del nombre con el NOS, enviar una solicitud de desactivación del ítem SLP, SIBB o de datos a la Administración de Datos. Si el estado del SLP, SIBB o de los datos es no activo, o si existen dependencias de datos, el SA ignora la solicitud de desactivación y se lo notifica al solicitante; 4) registrar todas las desactivaciones de datos, SLPs, y SIBBs; 5) habilitar a un usuario autorizado para solicitar la remoción de una entidad de SLP, SIBB o de datos, y especificar un tiempo para la remoción; y 6) verificar el estado del SLP, SIBB o de los datos, antes de enviar una solicitud de remoción a la Administración de Datos. Si el estado del SLP, SIBB o de los datos es desactivado, el SA envía la solicitud de remoción a la Administración de Datos, después de llegar al tiempo especificado. Si el estado del SLP, SIBB o de los datos no es desactivado, el SA ignora la solicitud de remoción y le notifica al solicitante; y 7) registrar todas las remociones de datos, SLPs y SIBBs de la Administración de Datos . Como se describió anteriormente con respecto a la activación de servicios/datos, un activador en el SA 500 provoca- que el SA descargue el comando para remover el perfil de servicio del nodo de servicio en el momento apropiado. Este comando se envía al nodo de servicio, mediante un comando, a la Administración de Datos 600. La Administración de Datos actualiza sus tablas, lo que da como resultado el NOS, que actúa como un cliente DM, para recibir la notificación del cambio de servicio. La Figura 3 (i) ilustra el proceso de desactivación de servicio con referencia al ejemplo de un servicio SLP 1-800-Cobrar proporcionado. Como se muestra en la Figura 3 (i), el primer paso 860 envuelve la decisión de retirar el Programa Lógico del Servicio 1-800-C y la utilización del MOCE/SCE para probar el impacto de remover el Programa Lógico del Servicio 1-800-C. Después, como se indica en el paso 862, el SA verifica las reglas respecto al retiro del Programa Lógico del Servicio 1-800-C. Particularmente, la Administración de Servicios verifica para asegurarse de que no haya dependencias de otros Programas Lógicos de Servicio activos en el Programa Lógico del Servicio 1-800-C. Si existen dependencias, se requiere investigación adicional para determinar si son verdaderamente necesarios los Programas Lógicos de Servicio dependientes, y se repite el paso de planeación. Si no existen dependencias, la Administración de Servicios permitirá que un usuario autorizado especifique un tiempo para la desactivación. Una vez que se determina que se puede retirar el SLP, el SA envía una solicitud de desactivación a todos los depositarios de Administración de Datos que contengan el SLP 1-800-C, como se indica en el paso 865. La Administración de Datos procesa la solicitud de desactivación, como se indica en el paso 867, y envía una respuesta de desactivación al SA, que indica el éxito o la falla de la desactivación. Después de una desactivación exitosa del SLP 1-800-C, el SA des - registra el SLP 1-800-C con el NOS, como se indica en el paso 868, para asegurarse de que el SLP 1-800-C ya no esté disponible para el procesamiento del servicio. Las solicitudes de servicio futuras, por lo tanto, no serán capaces de usar el SLP 1-800-C. Entonces, como se indica en el paso 869, el SA permite que un agente autorizado especifique un tiempo para remover todos los SLPs 1-800-C de todos los depositarios de la Administración de Datos en donde éstos residen. Una vez que llega el tiempo especificado, el SA envía una solicitud de remoción a todos los depositarios de la Administración de Datos que contengan el SLP 1-800-C y, como se indica en el paso 870, la Administración de Datos borra el Programa Lógico del - Servicio 1-800-C de sus depositarios, haciendo al servicio 1-800-C ya no disponible. Como un séptimo servicio principal, el componente SA 500 es responsable de realizar auditorías. Antes de que introduzca una entidad de servicios o datos dentro de la DBOR, la Administración de Servicios audita esa entidad con otras entidades de servicios/datos ya en uso, para asegurarse de que no existan conflictos. De la misma manera, antes de que se distribuya una entidad de servicios/datos a los nodos de servicios, ésta se audita para asegurarse de que no existan conflictos. La administración de servicios proporciona tanto auditorías activadas por el proceso, como auditorías activadas por planificación, tanto de servicios como de datos en la DBOR 230, que se despliega a los nodos de servicio. Una auditoría activada por el proceso es una auditoría que se inicia como un resultado de una falla inesperada. Por ejemplo, si el SA trata de descargar un perfil de servicio, y se rechaza la descarga porque el perfil ya existe, el SA inicia una auditoría para determinar qué hacer. Por ejemplo, el SA compara el servicio que ya existe contra el que se supone que se va a descargar, para determinar si son iguales, o diferentes. Si son iguales, la auditoría pudiera detenerse allí. Si son diferentes, el proceso de auditoría inicia un borrado del perfil existente y después descarga el correcto. Las auditorías activadas por planificación se activan de conformidad con una planificación definida previamente, o de conformidad con reglas programadas que lanzan rutinas auditoras durante el tiempo inactivo del sistema, o sobre la demanda por parte de un usuario. Estas reglas de auditoría del SA se mantienen como código compilado en el sistema SA 500, y como reglas interpretadas que se procesan adentro del sistema SA. Refiriéndonos ahora a la Figura 3(f), allí se muestra el componente de Administración de Datos 600 del componente SA que proporciona funciones de almacenamiento y administración de datos locales para cada nodo de servicio IDNA/NGIN. Particularmente, la Administración de Datos almacena los datos recibidos desde la Administración de Servicios en una o más bases de datos, y hace a los servicios/datos fácilmente disponibles para el ambiente de Control de Servicios, por medio de poner en memoria caché los datos necesarios a la memoria, residente en las computadoras de Control de Servicios, o en un servidor de base de datos colocalizado, de tal manera que los servicios/datos se puedan proporcionar a un servicio de Control de Servicios con mínima latencia. Más generalmente, el componente de Administración de Datos 600 realiza el almacenamiento, duplicación, sincronización, y disponibilidad en tiempo real de los datos, sea que se reciban desde la Administración de Servicios o que se reciban como un resultado del procesamiento de servicios. Estas funciones de Administración de Datos se pueden categorizar adicionalmente como: 1) una función Depositaría de Datos; 2) una función de Manipulación de Datos; 3) una función de Utilidad de Datos; y 4) una función de Generación de Registros de Facturación.

Punción Depositaría de Datos La función Depositaría de Datos comprende toda la funcionalidad requerida para el almacenamiento de datos IDNA/NGIN. Generalmente, un depositario es un dispositivo físico que almacena todos los tipos diferentes de información; por ejemplo, archivos de voz, objetos, SLPs, SIBBs, y bases de datos. En la administración de los depositarios de datos, la funcionalidad de Administración de Datos toma en cuenta la administración de seguridad, fallo y configuración de los depositarios. El aspecto de almacenamiento de depositarios de la Administración de Datos incluye la habilidad para: 1) almacenar datos persistentes, SIBBs, SLPs, archivos de audio, datos de contexto de llamada, datos de planificación, datos de configuración, datos de servicio de nombre, archivos de texto, por ejemplo, faxes; 2) retener datos especificados durante un período de tiempo que se pueda configurar, por ejemplo, se pueden almacenar los datos de contexto de llamada durante un par de días, antes del borrado de los depositarios; 3) borrar automáticamente los datos especificados de sus depositarios, después de la expiración del período de retención; y 4) proporcionar soporte para múltiples versiones de datos depositarios. Como parte de la función de almacenamiento, la Administración de Datos 600 puede verificar el estado de sus depositarios para asegurarse de que las consultas y distribuciones se hagan únicamente a los depositarios en línea. De esta manera, si se pone fuera de línea un depositario, no se intentarán consultas ni distribuciones en ese depositario. Como parte de esta función, la Administración de Datos puede: consultar el estado de los depositarios, por ejemplos, averiguar un estado de utilización que proporcione una indicación de cuan ocupado está cada depositario, en términos del número de transacciones que esté procesando en ese momento; enviar la información del estado del depositario al NOS 700 en la inicialización, y a medida que ocurran cambios de estado, proporcionar una alarma si se pone fuera de línea, o no es funcional un depositario; y notificar al NOS 700 que no se deben enviar más consultas ni actualizaciones al depositario que reporta una indicación fuera de línea. Además, como parte de la función de almacenamiento, la Administración de Datos permite la administración de configuración, la administración de fallos, y la administración de registros de los depositarios de datos. La función DM respecto a la administración de configuración que habilita a un usuario autorizado a: definir y extender el esquema de los depositarios de datos; consultar y modificar los recursos del sistema asignados para un depositario; y consultar y modificar las estrategias de indexación del depositario. La función DM respecto a la detección de fallos y la generación de reportes, para el mantenimiento de depositarios de datos incluye: habilitar la definición de umbrales y notificaciones de fallos para los recursos del sistema asignados a un depositario; habilitar la detección y reporte de fallas del medio dentro de un depositario; habilitar la definición de umbrales y notificaciones de fallos para el porcentaje completo de la capacidad de un depositario; habilitar la definición de umbrales y notificaciones de fallos para el porcentaje completo del registro de un depositario; y proporcionar una notificación de cuándo se corrompe un depositario o uno de sus componentes (por ejemplo, esquema, datos del depositario) . Las funciones DM respecto al establecimiento y administración de registros en los depositarios que posee la Administración de Datos incluyen: la habilidad para registrar las capacidades en los depositarios, incluyendo los siguientes tipos de registros: (a) registros de Transacción; (b) registros de Errores; y (c) registros de Eventos, y salvar estos registros en un medio externo. Con respecto a la función de registro, la Administración de Datos puede retener los datos de registro durante un período de tiempo que se pueda configurar, antes de volver a inicializar el registro. Adicionalmente, un usuario autorizado puede consultar y modificar las características (por ejemplo, tamaño, descripciones de campos, reporte de eventos) de los registros en un depositario, y especificar los datos que se van a escribir en cada registro. Por ejemplo, debido al volumen de las transacciones, un usuario pudiera únicamente desear capturar las transacciones "escritas" en el registro de transacciones contra todas las transacciones.

Función de Manipulación DM La función de Manipulación de Datos de DM comprende toda la funcionalidad específica que se requiere para recibir las distribuciones de datos, duplicar datos a través de los depositarios, consultar, recuperar, y actualizar datos en los depositarios, iniciar transacciones de aborto y reanudación, y realizar auditorías de datos. Esta funcionalidad se puede dividir en las siguientes áreas: a) Distribución de Datos; b) Duplicación de Datos; c) Recuperación y Actualización de Datos; d) Transacciones de Datos; y e) Auditorías de Datos, cada una de las cuales se describe en la presente.

Distribución de Datos La Distribución de Datos, como se define en la presente, se refiere al dispendio de datos o servicios desde la Administración de Servicios hasta la Administración de Datos 600. Con respecto a la función de Distribución de Datos, el DM recibe distribuciones de datos de la Administración de Servicios; reporta sobre el estado de los datos desplegados en el sistema; hace disponibles los datos para que los usen los servicios; y desactiva y remueve los datos almacenados por la Administración de Datos. Particularmente, como lo incluye el servidor de datos, la DDAPI, el depositario de extractos de la DBOR y los componentes del administrador de extractos de la DBOR (Figura 3(f)) del DM 600, la Administración de Datos está habilitado para recibir distribuciones de - datos, definiciones de archivos, SLPs y SIBBs de la Administración de Servicios. Si se ha excedido la capacidad del depositario, cualquier intento por recibir las distribuciones de datos fallará, sin embargo, sin bloquear el acceso a los datos en el depositario. En respuesta a una distribución de datos al DM desde el SA, los procesos que se ejecutan en el servidor DM responden al SA con una señal que indica el éxito o la falla de la distribución. Si existe una falla de distribución de datos, el DM puede deshacer cualquier porción de la distribución que se terminó. Como se describió, una señal de solicitud de activación se distribuye desde el SA, para indicar que los datos se han distribuido exitosamente a un número mínimo de depositarios, y se va a hacer "activo" para el procesamiento de Servicios. La Administradón de Datos responde a la recepción de una solicitud de activación, con una respuesta de activación que indica éxito o falla, que se envía de regreso a la Administración de Servicios después de una activación exitosa/no exitosa respectiva de los datos, el SIBB o el SLP. El DM también es capaz de recibir y procesar una solicitud de desactivación de la Administración de Servicios, la cual se envía desde el SA para hacer unos datos, SLP o SIBB específicos, no disponibles para el procesamiento de Servicios. La Administración de Datos responde a una solicitud de desactivación, con una respuesta de desactivación, que indica el éxito o la falla de la desactivación solicitada, a la Administración de Servicios. De la misma manera, el DM es adicionalmente capaz de recibir y procesar una señal de solicitud de remoción de la Administración de Servicios, que especifica que el DM va a remover datos específicos del depositario designado. El DM envía una respuesta de remoción que indica el éxito o la falla de una solicitud de remoción, de regreso a la Administración de Servicios. Se debe entender que las solicitudes de activación, desactivación, y remoción pueden ser para un SLP, SIBB o una entidad de datos. i Duplicación de Datos La' función de Duplicación de Datos del DM incluye toda la funcionalidad específica que se requiere para duplicar datos a ubicaciones específicas, es decir, depositarios de datos de nodo de servicio, es decir, memorias caché del servidor local, y para notificar al NOS de duplicaciones exitosas/no exitosas. El sistema IDNA/NGIN duplica los datos en base a las políticas de duplicación definidas que proporcionan los archivos de configuración de SA. Como se describe en la presente, el término "duplicación" se refiere al acto de copiar datos de un depositario a otro,' para datos escritos como parte del procesamiento de servicios . Por ejemplo, la Administración de Datos duplica los datos a otros depositarios cuando se actualizar. los datos durante el Procesamiento del Servicio. Primeramente, la Administración de Datos determina un conjunto de ubicaciones en donde se van a duplicar ios datos, en base a reglas de duplicación establecidas que proporciona el SA en archivos de configuración para la entidad de datos y, se asegura de que fallarán los intentos de duplicar datos del depositario cuando se haya excedido „ la capacidad del depositario objetivo, sin bloquear el acceso a los datos existentes en el depositario. Si la duplicación falla debido a la capacidad excesiva, la Administración de Datos notifica al componente NOS que los datos específicos no están disponibles en este depositario, para asegurarse de que no se realice ningún intento adicional para volver a intentar la duplicación a ese depositario. Si una duplicación a un depositario falla por razones diferentes a la capacidad, la Administración de Datos puede reintentar la duplicación fallida en el depositario. Si después de un número de reintentos definido previamente, que se puede configurar, el depositario todavía es incapaz de recibir la duplicación, la Administración de Datos genera una alarma y notifica al componente NNOS que los datos específicos que se están duplicando no están disponibles en este depositario. Esto asegura que no se hagan consultas sobre estos datos en esta ubicación. De esta manera se puede implementar una utilidad de sincronización, para tener los depositarios de nuevo en sincronización.

Recuperación y Actualización de Datos La funcionalidad de Recuperación y Actualización de Datos incluye la habilidad para accesar a datos almacenados por la Administración de Datos durante el procesamiento del servicio. En la modalidad preferida, en cualquier nodo de servicio particular, la Administración de Datos recibe solicitudes de una instancia de objeto administrado en ejecución en el SLEE, por ejemplo, a través del NOS, durante el procesamiento del servicio. La Administración de Datos notifica específicamente al solicitante (por ejemplo, el objeto administrado) si ésta no es capaz de entender la solicitud de datos. Si la solicitud de datos es para la recuperación de una entidad de datos, la Administración de Datos regresa los datos solicitados al solicitante (por ejemplo, por medio del NOS) . Se debe entender que cualquier soporte que se necesite para manipular y consultar datos en un solo depositario, o a través de múltiples depositarios, lo proporciona el DM. La Administración de Datos adicionalmente soporta la reunión e intercalación de los resultados de las consultas que abarcan múltiples depositarios. Si el DM es incapaz de localizar el nombre de la entidad solicitada en la solicitud de recuperación de datos, el DM lo notifica al componente NOS. Al componente NOS también se le notificará si ocurre una falla de la base de datos durante la recuperación de una entidad de datos. La Administración de Datos adicionalmente le notifica al solicitante (que ejecuta el objeto de control de servicio) de la incapacidad para recuperar una entidad de datos especítica a partir de un nombre válido. Si la solicitud de datos es para una actualización de una entidad de datos, la Administración de Datos actualiza la entidad de datos y determina si se requiere la duplicación. El DM le notifica al solicitante si ésta es incapaz de actualizar una entidad de datos especificada en una solicitud de datos, y adicionalmente le notifica al NOS si ésta es incapaz de localizar el nombre de la entidad solicitada en la solicitud de actualización de datos. En cualquier momento durante la operación NGIN, el DM le notifica al NOS de la falla de una base de datos durante la actualización de una entidad de datos. Si la solicitud de datos es para el borrado de una entidad de datos, el DM borra el ítem de datos y determina si se necesita iniciar la transacción en otros depositarios.

Transacciones de Datos Una transacción se define como una secuencia de operaciones en un conjunto de datos, que transforma los datos de un estado " consistente a otro estado consistente. Los ejemplos de transacciones incluyen: introducir datos, actualizar datos existentes, borrar datos, y copiar datos. En el contexto del sistema IDNA/NGIN, el DM es capaz de iniciar una transacción en un depositario, abortar una transacción que se haya iniciado, proporcionar notificación si ocurre una falla de la transacción, y, registrar todas las fallas de la transacción. La Administración de Datos adicionalmente implementa una estrategia de recuperación por medio de regresar los datos controlados por una transacción, a su estado previo, como un resultado de una falla de la transacción, y volver a ejecutar una transacción fallida, como un resultado de una falla de la transacción. Cualquier estrategia de recuperación implementada se puede definir al momento de iniciar una transacción, o cuando ocurra la falla. La Administración de Datos también está abastecida para habilitar una transacción para tiempo fuera y en consecuencia falla, de conformidad con un parámetro de tiempo fuera determinado previamente, especificado en el momento de iniciar una transacción. Además la funcionalidad de transacción de datos incluye: la capacidad para participar en múltiples transacciones al mismo tiempo; la provisión de mecanismos de resolución de concurrencia de transacción, que soportan el bloqueo de colisiones de concurrencia con la colocación en lista lineal de transacciones pendientes; la generación de una señal de indicación si cualquiera de los datos de transacción llega a modificarse fuera del contexto de la transacción (es decir, se corrompe) ; la capacidad para reanudar el estado de sus datos, mientras participa en una transacción; y, la capacidad para " reanudar todas las operaciones realizadas mientras participa en una transacción.

Auditoría de Datos La " funcionalidad de Auditoría de Datos del sistema IDNA/NGIN incluye la provisión de un ambiente de auditoría/recuperación para datos del depositario. En el contexto de la Administración de Datos, una "auditoría" es un proceso para probar la sincronización entre dos o más copias de datos depositarios, y reportar los resultados. "Recuperación" es el conjunto de acciones que se toman como un resultado de una auditoría para poner las copias en sincronización. Como se describe en la presente, todos los datos que se hacen persistentes y/o se duplican, se pueden auditar. Adicionalmente, se asume que un modelo de copia primario se establece y considera que es correcto para los propósitos de auditoría y recuperación. La Administración de Datos es capaz, por lo tanto, de designar la copia primaria de un depositario. En el contexto de NGIN, el DM también está habilitado para auditar datos a través de múltiples depositarios, registrar todas las discrepancias de auditoría, proporcionar una notificación de d screpancias de auditoría, y proporcionar recuperación automática en base a un conjunto definido de reglas relacionadas con una discrepancia identificada. En la modalidad preferida, la Administración de Datos puede planificar auditorías de datos.

Función de Utilidad de Datos En el contexto del sistema IDNA/NGIN, ia utilidad de datos se refiere a la funcionalidad requerida para cerrar e inicializar un depositario, respaldar datos almacenados, recuperar datos después de un evento catastrófico, sincronizar datos entre depositarios, y monitorear y mantener 71 depositarios de datos. La Administración de Datos está adicionalmente habilitada para cerrar (poner fuera de línea) un depositario para propósitos de mantenimiento o recuperación. Al determinar si se debe cerrar un depositario, se proporciona un mecanismo para monitorear el porcentaje de utilización de un depositario de datos. Por lo tanto, se proporcionan utilidades que le permiten a un usuario autorizado mantener los depositarios de datos, incluyendo una utilidad para optimizar el espacio del disco y para la limpieza de registros. La Administración de Datos adicionalmente puede respaldar y restaurar un depositario, usando los comandos del archivo del sistema operativo' local.

Un depositario se puede recuperar sin pérdida de información. La Administración de Datos se proporciona con una utilidad adicional para archivar datos del depositario a un medio externo; sincronizar datos del depositario a través de múltiples depositarios; sincronizar un subconjunto de datos (sincronización parcial) a través de múltiples depositarios, y poner un depositario en línea.

Requerimientos de Generación de Registro de Facturación La funcionalidad de Generación de registro de Facturación para el sistema NGIN incluye la reunión de eventos de la red, el formateo de eventos de la red dentro de los registros apropiados (historia de llamadas) , transmitir los registros formateados a la ubicación apropiada, e identificar las llamadas potencialmente fraudulentas. Puesto que la función de Generación de Registro de Facturación es responsable de formatear y transmitir la información que se usará para facturar a los clientes por los servicios, su exactitud está certificada.

Reuniendo Eventos de la Red Los eventos de la red en bruto que se usan para propósitos de facturación, se reúnen de los depositarios de la Administración de Datos, y se revisan para verificar su integridad. En la creación de registros de historia de llamadas que utilizan los diferentes tipos de sistemas de facturación corriente abajo, se proporciona un identificador de red único para cada registro de historia de llamadas, de tal manera que los registros se puedan manipular subsecuentemente para procesamiento adicional. En la modalidad preferida, los registres de historia de llamadas se pueden usar para capturar información que se usa para la generación de los siguientes tipos de registros: registros de detalle de llamadas (CDRs), que capturan información de eventos de la red en líneas compartidas; registros de red privada (PNRs), que capturan información de eventos en líneas privadas (por ejemplo, VNET) ; registros de servicios de operadora (OSRs) que se usan para capturar información cuando se usan líneas compartidas para servicios de operadora; y, registros de servicio de operadora privada (POSRs), que capturan información cuando se usan líneas privadas para servicios de operadora. De preferencia, cada uno de los tipos anteriores de registros de facturación se pueden expandir. Por lo tanto, se pueden generar registros de detalle de llamadas expandidos (ECDRs) , registros de red privada expandidos (EPNRs) , registros de servicios de operadora expandidos (EOSRs), y registros de servicio de operadora privada expandidos (EPOSRs) . Los registros adicionales que se pueden generar a través del DM incluyen registros de eventos de conmutador (SERs) que identifican un evento de conmutador (por ejemplo, recuperación del sistema, cambio de hora) y registros de datos de facturación ~(BDRs) . Esta función adicionalmente incluye almacenar los registros de historia de llamadas en un medio de almacenamiento y recuperación a largo plazo (por ejemplo, cinta) .

Transmitir Requerimientos de Registros de Historia de Llamadas Después de que se genera cada uno de estos registros de historia de llamadas, éstos se transmiten al sistema corriente abajo apropiado. Por ejemplo, en ia modalidad preferida, todos los CDRs, PNRs, OSRs, POSRs, sus versiones expandidas correspondientes ECDRs, EPNRs, EOSRs, EPOSRs, y SERs y BDRs, se envían a un Elemento de Almacenamiento y Verificación "SAVE" (no se muestra) del sistema, para distribución eventual a un Concentrador de Información de la Red (NIC) . Una función del sistema DM proporciona una verificación de que el SAVE ha recibido exitosamente cada uno de estos registros de historia de llamadas.

Identificar Llamadas Potencialmente Fraudulentas El sistema NGIN tiene un mecanismo interconstruido para identificar llamadas potencialmente fraudulentas. De esta manera, el componente DM 600 proporciona la habilidad para monitorear el uso de la red para fraudes, y reportar un posible fraude a un sistema de Detección de Fraudes apropiado. Como un ejemplo, la función de Generación de Registro de Facturación: 1) obtiene perfiles de un sistema de Detección de Fraudes (no se muestra) para identificar eventos de la red que se deben enviar a la Detección de Fraudes; 2) evalúa los eventos de la red contra los perfiles de fraude; y 3) transmite las llamadas potencialmente fraudulentas a un sistema de Detección de Fraudes en tiempo real. La Figura 3(f) ilustra generalmente la arquitectura funcional del componente de Administración de Datos 600, que comprende: un componente de servidor de control de servicio 605, para hacer los datos de servicio de llamada disponibles en jel nodo de servicio, para procesamiento de llamadas en tiempo real; y un componente de base de datos 607, incluido como un servidor de base de datos discreto, para almacenar y distribuir el subconjunto seleccionado de datos mantenidos por el SA. Específicamente, el componente de servidor de control de servicio 605 incluye un Cliente de Administración de Datos (DM) 610, el cual es la aplicación de administración de datos real; una API de DM 612 que está enlazada con la aplicación DM, y es la interfase que usa la aplicación DM para obtener datos del SA; la memoria caché local 615 que es una memoria compartida en un servidor de control de servicio, que se usa para almacenar algunos o todos los datos del Extracto de la DBOR disponible para procesamiento de llamadas, de conformidad con una estrategia de colocación en memoria caché local, y un Administrador de Memoria Caché 620, que mantiene el estado de la memoria caché local mediante la implementación de una estrategia de colocación en memoria caché local, y se comunica con el servidor DM para recuperar datos del extracto de la DBOR. El componente de base de datos 607 incluye un Extracto de la DBOR 627, que comprende una o más bases de datos que tienen datos que van a usar las instancias de objetos administrados durante la ejecución del servicio en ese nodo; un Administrador de Extractos de DBOR 626 que realiza las mismas funciones que el Administrador de la DBOR 520 en la Administración de Servicios (Figura 3 (d) ) , pero maneja un subconjunto seleccionado de la información que contiene el SA; un cliente SA 622, el cual introduce los datos recibidos desde la administración de servicios al Administrador de Extractos de DBOR 626; una DDAPI 624 que es la interfase del proceso entre el cliente SA 622 y el proceso de distribución de datos del SA; y un servidor de administración de datos 625, que generalmente maneja los extractos de datos del Administrador de Extractos de DBOR 626. Ahora se describirá con mayor detalle la operación de administración de datos, con respecto a la Figura 3(f) . adentro de un SLEE, muchos _ tipos de funciones pudieran necesitar datos de la Administración de Datos 600 que incluyen, pero no se limitan a objetos administrados (SIBBs, SLPs, etcétera) y NOS. Cada uno de éstos está representado en la Figura 3 (f) como un Cliente DM, que se ejecuta en el SLEE de control de servicios. Un Cliente DM 610 usa la API de DM 612 para hacer una solicitud de datos, a medida que la API de DM 612 proporciona un conjunto de mensajes común para todos los Clientes DM para que se interconecten con la Administración de Datos. La API de DM 612 también encapsula del Cliente DM la ubicación específica en donde se necesitan los datos, puesto que estos datos se pueden almacenar en una Memoria Caché Local 615, o solamente en el Extracto de la DBOR 627. El Cliente DM solicita datos "por medio de un nombre lógico, y la API de DM 612 determina si se pueden recuperar esos datos de la memoria caché local o, si éste necesita solicitar los datos del extracto de la DBOR por medio del Servidor DM. De preferencia, la memoria caché local 615 es una memoria caché compartida, disponible para cada proceso que se ejecuta en cada SLEE proporcionado en el servidor de control 605, es decir, puede haber una o más memorias caché locales proporcionadas para diferentes aplicaciones, por ejemplo, memoria caché de proceso 1-800, memoria caché de administrador de encaminamiento, etcétera, con cada memoria caché compartida teniendo su propio administrador de memoria caché respectivo. Cuando un cliente DM 610 hace una solicitud de datos, la API de DM primero verifica la memoria caché local 615 para ver si están almacenados allí los datos solicitados. Si los datos solicitados están almacenados en la memoria caché local 615, la API de DM recupera los datos solicitados y se los proporciona al cliente DM 610, usando cualquier técnica estándar de recuperación de datos, tal como claves y algoritmos de direccionamiento calculado, o métodos de acceso secuencial indexado. Si los datos solicitados no están almacenados en la memoria caché local 615, el Administrador de Memoria Caché 620 asociado recupera los datos del Extracto de la DBOR 627, por medio del Servidor DM 625. Particularmente, la API de DM 612 le notifica al Administrador de Memoria Caché 620 que ésta necesita ciertos datos, y el Administrador de Memoria Caché responde por medio de enviar una solicitud al Servidor DM 625. El Servidor DM 625, a su vez, recupera los datos solicitados del Extracto de la DBOR, usando el Administrador de Extractos de DBOR 626 para acceso a la base de datos. El Servidor DM __625 envía los datos solicitados de regreso al Administrador de Memoria Caché 620, y el Administrador de Memoria Caché proporciona los datos al Cliente DM 610 por medio de la API de DM 612. El Administrador de Memoria Caché también puede escribir los datos solicitados a la memoria caché local 615, dependiendo de la estrategia de colocación en memoria caché local, que es dependiente tanto de las demandas del servicio, como de las capacidades de las computadoras en las que se ejecutan, notablemente la capacidad de memoria. Estas especificaciones se obtienen de los perfiles de servicio y computadora generados por la Administración de Servicios. En la modalidad preferida, el componente de administrador de memoria caché de datos para el DM 600 del IDNA/NGIN emplea una estrategia de ^Cliente al Lado de Colocación en Memoria Caché' en cada nodo de servicio. De conformidad con esta estrategia, las rutinas y el lógico del administrador de memoria caché se implementan esencialmente de la siguiente manera: 1) la memoria caché local se mantiene como una configuración estática al principio de la rutina; 2) la rutina verifica primero para ver si los datos solicitados están en la memoria caché local; 3) si los datos están en la memoria caché local, éstos se formatean y regresan a la persona que llama; 4) si los datos no están en la memoria caché local, se recuperan~íos datos del Servidor de Datos usando una rutina común de "ServidorConsulta"; y 5) cuando se regresan los datos del Servidor de Datos, éstos se almacenan en la memoria caché, se formatean, y después se regresan a la persona que llama. Más particularmente, la rutina de "ServidorConsulta" formatea una consulta al Servidor de Datos, envía la solicitud, y si no recibe una respuesta, ésta envía otra solicitud. Esto continúa hasta que ya sea se recibe una respuesta, o hasta un número establecido de intentos, momento en el cual la rutina regresará con un error. En la modalidad preferida, el lógico del código existe en un proceso separado llamado el ^administrador de la memoria caché' , el cual asigna el espacio de la memoria caché dinámicamente y no como una ^variable estática' . Además, en la modalidad preferida, el administrador de la memoria caché es una rutina genérica, es decir, ésta no contiene referencias a tablas ni elementos de datos específicos. Por otra parte, el administrador de la memoria caché de la modalidad preferida implementa el lógico para manejar muchas estrategias para colocación en memoria caché, e implementa el lógico para manejar mensajes de datos no solicitados del servidor de datos. Las estrategias de colocación en memoria caché local varían desde almacenar todos los datos en la Memoria Caché Local, hasta no almacenar nada pero, típicamente incluyen una estrategia de "más recientemente usado" o "más frecuentemente usado". Puesto que el abastecimiento de una memoria caché local es para permitir la recuperación de datos rápida (usando memoria compartida) para servicios frecuentemente usados, la estrategia de colocación en memoria caché local está muy ligada con la función de abastecimiento de soporte del servicio SA, que determina cuáles servicios ejecutar en cuáles Servidores de Control de Servicios. Más particularmente, existen tres niveles para colocar en memoria caché en el sistema los datos, dependientes de las características de los datos y los servicios con los que están asociados los datos: 1) datos de nivel local que implementan el esquema de colocación en memoria caché local descrito en la presente, utilizando la DMAPI, el Administrador de Memoria Caché y el servidor DM y dispositivos de extractos de DBOR; 2) datos de nivel de nodo o sitio, en donde la DMAPI, el Administrador de Memoria Caché y los componentes del servidor DM se implementan para actualizar la DBOR, y enviar el cambio de regreso a través del -servidor DM, a todos los administradores de memoria caché en el nodo; y 3) datos de nivel de la red, en donde la DMAPI, el Administrador de Memoria Caché y los componentes del servidor DM se implementan para enviar los datos hasta el SA, y se aplican a la base de datos central y de regreso a través del SA y todos los servidores DM, a todas las memorias caché locales en la red. Se debe entender que también existen dos niveles de permanencia de datos: 1) datos permanentes que se pretende que se escriban dentro de la DBOR; y 2) datos transitorios que se van a escribir a las memorias caché locales, dependiendo de las características de los datos. Como se muestra adicionalmente en la Figura 3(f), como un ejemplo de la colocación en memoria caché de datos local de datos transitorios, cuando un SLP para un servicio se va a ejecutar activamente, es decir, se va a ejemplificar concretamente como un objeto persistente en el SLEE basado en la demanda anticipada del servicio, la estrategia de colocación en memoria caché local especifica el almacenamiento de datos para este servicio en la Memoria Caché Local, para la duración de tiempo especificada, de conformidad con el archivo de configuración, es decir, un perfil de archivo desde el SA. El Servidor DM envía los datos para ese servicio al Administrador de Memoria Caché 620 para almacenar la memoria caché local 615 durante el tiempo activo. Particularmente, cuando se llega a abastecer un ambiente SLEE, el Administrador de Memoria Caché 620 se registra a sí mismo con el Servidor DM 625, por medio de especificar cuáles servicios se realizarán. En base a esto, el Servidor DM 625 recupera del Extracto de la DBOR 627 y descarga al Administrador de Memoria Caché 620, los datos necesarios para realizar la estrategia de colocación en memoria caché local para los servicios para los cuales se ha registrado el Administrador de Memoria Caché. De preferencia, el Servidor DM 625 conoce la estrategia de colocación en memoria caché local para cada memoria caché local y el administrador de memoria caché en su sitio. De esta manera, el Servidor DM 625 también puede proporcionar datos no solicitados al Administrador de Memoria Caché. Por ejemplo, cuando ocurre una actualización iniciada de la red, la actualización la puede dirigir el servidor DM directamente dentro de su extracto de DBOR y/o a la administración de servicios para validación y distribución a otras plataformas de administración de datos. Si el Servidor DM recibe del SA una actualización, éste enviará esta actualización al administrador de memoria caché para actualizar la memoria caché local. Se debe entender que en este caso, el Cliente SA y el Administrador de Extractos de la DBOR 626 actualizarán el Extracto de la DBOR. La Administración de Datos proporciona una interfase del proceso entre el Cliente SA y el Servidor DM, para notificar al Servidor DM de las actualizaciones del Extracto de la DBOR.

En la modalidad física preferida, el componente de Administración de Datos 600 usa productos de bases de datos comerciales, la mayoría de los cuales proporciona un mecanismo de interconexión tal como una API, un agente de solicitud de objetos ("ORB") o un servicio de archivo de la red. Como tal, la Administración de Datos no usa el componente NOS 700, sin embargo, la interfase de Control de Servicios a la Administración de Datos se puede adaptar para usar el NOS. Puesto que la función de Administración de Datos es local a cada nodo de servicio, esta función se puede realizar físicamente mediante diferentes sistemas/productos de base de datos de objetos y relaciónales, a lo largo de la red. Los productos de base de datos relaciónales de ejemplo incluyen aquellos disponibles con Oracle, Informix, y Sybase, en adición a los productos de Base de Datos Orientados a los Objetos Experimentados. La interfase entre el Control de Servicios y la Administración de Datos la puede soportar cualquier sistema/producto de base de datos que se use en un nodo de servicio particular, y puede ser diferente en diferentes nodos. El procesamiento distribuido que se habilita mediante el NOS ocurre entre los procesos en el SLEE, con cada proceso interconectándose con su componente de Administración de Datos local, usando cualquier interfase que esté en su lugar en el nodo local. Se han descrito con detalle unas pocas modalidades preferidas, anteriormente en la presente. Se entenderá que el alcance de la invención también abarca modalidades diferentes de aquellas descritas, pero dentro- del alcance de las reivindicaciones . Por ejemplo, se entiende que la computadora de uso general es un dispositivo de computación que no está hecho específicamente para un tipo de aplicación. La computadora de uso general puede ser cualquier dispositivo de computación de cualquier tamaño, que pueda realizar las funciones requeridas para implementar la invención. Un ejemplo adicional es que el lenguaje de programación "Java" se puede reemplazar con otros lenguajes de programación equivalentes que tengan características similares, y que realicen funciones similares, según se requiera para implementar la invención. Aunque se ha descrito y discutido la presente invención en conexión con la modalidad descrita anteriormente, para aquellos expertos en la técnica será evidente que son posibles numerosos cambios, variaciones y modificaciones dentro del espíritu y alcance de la invención. De conformidad con lo anterior, se pretende, por lo tanto, que las siguientes reivindicaciones incluyan esas variaciones y modificaciones.

Claims

REIVINDICACIONES

1. Un sistema de administración de servicios para distribuir recursos de procesamiento de servicios entre uno o más nodos de servido de una red de comunicaciones inteligente, cada nodo de servicio proporcionando servicios en un recurso de la red asociado con un nodo de servicio, el sistema comprendiendo: a) un dispositivo para recibir componentes de servicio que se pueden volver a usar, para proporcionar servicios en un nodo de servicio de la red de comunicaciones inteligente, cada uno de esos componentes de servicio teniendo un perfil de servicio asodado que define los recursos del nodo de servicio que se requieren para almacenar, mantener y ejecutar ese servicio; b) un dispositivo para recibir criterios de configuración que incluyen la capacidad de recursos física de cada nodo de servicio de dicha red; c) un dispositivo de base de datos para almacenar los componentes de servicio recibidos, los criterios de configuración de nodo de servicio, y el perfil de servicio asociado con los componentes de servicio; d) un mecanismo de distribución para distribuir 'copias de los componentes de servicio a uno o más nodos de servicio, de conformidad con la información de perfil de servicio asociada con un servicio, y un criterio de configuración de los nodos de servicio; y e) un mecanismo activador para activar y desactivar automáticamente el componente de servicio distribuido al nodo de servicio, en donde se optimiza la utilización de los recursos del nodo de servicio mediante la activación de los componentes de servicio en los nodos de servicio, durante períodos de alta demanda para un servicio asociado, y la desactivación de los componentes de servicio en los nodos de servicio durante períodos de baja demanda de ese servicio.

2. Un método para administrar componentes de servicio a uno o más nodos de servicio, que comprende una red inteligente, cada nodo de servicio proporcionando uno o más servicios relacionados con un evento recibido en un recurso de la red asociado con un nodo de servicio, el método comprendiendo los pasos de: a) recibir componentes de servicio que se pueden volver a usar, para proporcionar servicios en un nodo de servicio de la red de comunicaciones inteligente, cada uno de dichos componentes de servicio teniendo un perfil de servicio asociado que define los recursos del nodo de servicio que se requieren para almacenar, mantener y ejecutar ese servicio; b) recibir criterios de configuración que incluyen la capacidad de recursos física de cada nodo de servicio de esa red; c) mantener una base de datos que incluya copias maestras de los componentes de servicio recibidos, los criterios de configuración de nodo de servicio, y el perfil de servicio asociado con esos componentes de servicio; d) distribuir las copias de los componentes de servicio a uno o más nodos de servicio, de conformidad con la información de perfil de servicio asociada con un servicio, y un criterio de configuración de los nodos de servicio; y e) enviar un activador a dicho nodo de servicio para activar y desactivar automáticamente un componente de servicio distribuido al nodo de servicio, por medio de lo cual se activa un componente de servicio distribuido a ese nodo de servicio, durante períodos de alta demanda para un servicio asociado, y se desactiva en los nodos de servicio durante períodos de baja demanda de ese servicio.

3. Un sistema de procesamiento de servicios para controlar una red de comunicaciones que tiene una pluralidad de nodos de servicio, cada nodo de servicio comprendiendo cuando menos un ambiente de ejecución lógico que alberga objetos administrados, el sistema de procesamiento de servicios comprendiendo: un administrador de datos para mantener en cada nodo de servicio un almacenamiento local de objetos administrados y datos, necesarios para el procesamiento del servicio dentro del nodo de servicio; cuando menos un administrador de servicios que controla el despliegue y la activación de los servicios dentro del sistema de procesamiento de servicios, mediante la distribución, desde un depositarios global de objetos administrados y datos a uno o más administradores de datos, asociados con esos nodos de servicio en la red de comunicaciones . . Un método para controlar el despliegue y la activación de servicios en una red de comunicaciones que tiene una pluralidad de nodos de servicio, cada nodo de servicio .comprendiendo cuando menos un ambiente de ejecución lógico que alberga objetos administrados, el método comprendiendo los pasos de: mantener en cada uno de dichos nodos de servicio un almacén de datos local de objetos administrados y datos necesarios para el procesamiento del servicio dentro del nodo de servicio; distribuir selectivamente, desde un depositario global, objetos administrados y datos a uno o más de los almacenes locales asociados con esos nodos de servicio en la red de comunicaciones, con el propósito de controlar en dónde y cuándo se despliegan y activan los servicios en la red de comunicaciones. - TODO Y APARATO PARA DESPLEGAR MÓDULOS DE SERVICIO ENTRE NODOS DE SERVICIO DISTRIBUIDOS EN UNA RED INTELIGENTE RESUMEN Un método y aparato para desplegar y activar servicios en una red de comunicaciones (202) . En el contexto de una red de comunicaciones (202) que despliega funcionalidad de servicio mediante objetos de software administrados en distribución hacia los nodos de procesamiento de servicio (204) , la presente invención se relaciona con la dosificación selectiva de objetos administrados desde un depositario (230) , y con la coordinación de la activación o desactivación instantánea de los servicios a través de la red de comunicaciones (202) . Además, en donde se acopla un medio ambiente de creación de servicio de objetos administrados (228) con la red de comunicaciones (202) , el método y aparato de la presente invención proporciona seguridad, respaldo, y control de versión de los objetos administrados, y otros datos de red almacenados en el depositario (230) .