Gestión a través de capacidades SS7 para servicios avanzados de telecomunicaciones sobre RDSI JARAMILLO HÉCTOR F.

MARTINEZ JOSÉ F.

MOYA ANA C.

Dept. de Telemática, Universidad del Cauca Popayán, Cauca, Colombia email: [email protected]

Depto. de Telemática, Universidad del Cauca Popayán, Cauca, Colombia email: [email protected]

Depto. de Telemática, Universidad del Cauca Popayán, Cauca, Colombia email: [email protected]

Resumen En la actualidad los servicios avanzados de telecomunicaciones son cada vez más multimediales, lo cual crea nuevas necesidades para su prestación, dado que un extremo de la conexión del servicio esta sobre una red IP (Internet Protocol), la red de transporte requiere un mayor ancho de banda, y una mejor gestión de sus recursos, y los servicios deben ser personalizables y configurables en tiempo real. Existen arquitecturas, plataformas y tecnologías que ofrecen soluciones a este tipo de necesidades pero de forma parcial, ya que no integran la gestión del servicio y de red como un todo, de forma que los servicios no pueden ser gestionados en tiempo real, aunque son de fácil migración, mientras los niveles de red se pueden gestionar en tiempo real pero son de difícil migración a otra red de trasporte. En el trabajo presentado se plantea una arquitectura solución donde se integran los niveles de gestión de red y gestión de servicio con interfaces de gestión abiertas que son implementadas con tecnologías Java, para facilitar la gestión, migración, escalabilidad y control en tiempo real de la red y los servicios, todo soportado por SS7(Sistema de Señalización # 7) como protocolo de señalización que nos provee los datos de monitoreo y facilidades para gestión. Palabras clave: Gestión de servicio, JMX, MBean, RIA, RDSI, Servicios multimediales, SS7. Abstract Today advance telecommunications services are trend to multimedia, therefore new requirements are needed to release those services, because one edge of connection is on IP network, network carriers need more band width and better management of their resources, and services most be real time customize and configurable. Market is plenty of platforms, architectures and technologies bringing solutions to those requirements but no one solve the whole problem, because they don’t have an integrated management for services and network, making services hard to manage at real time, however they have easily migration, otherwise real time is a common feature in network management, but it have a difficult migration to

other carrier network. This article shows an architecture like solution where are integrated network and service management, and have open management interfaces developed using Java technologies to get easily management, migration, grow, and real time control in both network and service, all over SS7 (Signaling System #7) like signaling protocol and management protocol to get monitoring and configuration facilities. Key words: AIN, JMX , ISDN , MBean SS7, Multimedia services, Service management. INTRODUCCIÓN En el mundo de las telecomunicaciones es cada vez más importante ofrecer servicios adaptados a las necesidades del cliente, servicios totalmente personalizados, que puedan desplegarse rápidamente y ser removidos sin grandes inversiones económicas; desde el punto de vista del operador estos servicios deben aprovechar al máximo los recursos disponibles, de forma que no haya que montar nuevas infraestructuras constantemente, y obtener la máxima rentabilidad al corto plazo. [1] La mayor parte de los servicios que actualmente se proveen tienen un extremo en redes IP (Internet Protocol), pero su conectividad a través de la RTPC (Red Telefónica Pública Conmutada) no siempre es la mejor oferta; sin embargo es la RTPC la red de mayor alcance que existe a nivel mundial y con mayor penetración en el mercado [2], por eso se hace necesario la incorporación de arquitecturas RI (Red Inteligente) para la prestación de servicios avanzados de telecomunicaciones para el hogar común. Las arquitecturas de RI, y en particular las tendencias en las RIA (Red Inteligente Avanzada) nos permiten una mayor flexibilidad y capacidad para creación, liberación y modificación de servicios de telecomunicaciones independientes de la red de transporte. Pero la red de transporte realmente puede llegar a poner límites a nuestros servicios, debido a su ancho de banda (BW – Band Width) y los costos que puede conllevar la implementación de su infraestructura, es por esto que nuestro trabajo ha buscado reutilizar las redes de cobre (Cu) existentes a través de

RDSI (Red Digital de Servicios Integrados), además que así no comprometemos al usuario con la adquisición de nuevos terminales para su uso, como lo sería un PC con un modem ADSL (Asymmetric Digital Subscriber Line) Lastimosamente la RDSI no tuvo la penetración que se esperaba en el mercado de las telecomunicaciones, y hoy en día ha sido desplazada por otras tecnologías, pero sigue siendo una constante en la mayoría de equipos de telefonía, como centrales y concentradores remotos, de Latino América, lo cual facilitaría su uso por parte de suscriptores de hogar, teniendo líneas RDSI con rata básica (2B+1D = 128 + 16 Kbps) con la cual podríamos ofrecer servicios multimediales para el suscriptor, utilizando técnicas de compresión de datos en el transporte. Otra de las ventajas que aprovechamos en este proyecto es el soporte que ofrece el SS7 para el manejo de las llamadas RDSI, además muchos de los mensajes intercambiados a través de SS7 pueden ser utilizados para monitorear el estado de la red, e incluso gestionar sus recursos, para mantener un buen nivel en la calidad del servicio prestado. La prestación de un servicio avanzado de telecomunicaciones soportado con RI, a través de líneas RDSI, nos permitiría realizar gestión del servicio sin tener que añadir infraestructura a la red ya que la gestión puede llevarse a cabo a través de la misma red de señalización con SS7, lo cual nos garantiza total cobertura dado que es un estándar internacional. Cuando se definió SS7 como sistema de señalización, se pensó en sus capacidades de gestión, pero estas han sido aprovechadas básicamente para gestionar las llamadas y la señalización en sí misma, pero sus capacidades nos permitirían realizar la gestión de los servicios de la RI y hacer el control básico de llamada; actualmente no existen muchas herramientas para realizar dicha tarea, pero utilizando las facilidades que nos puede ofrecer una plataforma abierta para gestión podemos crear un verdadero sistema de gestión para el servicio que nos permita realizar el control básico de llamada RI, controlar su tarificación y mantener la calidad del servicio prestado, y para esto ha sido llamada la JMX (Java Management eXtensions). Una de las plataformas más populares que ha entrado al mercado, para cubrir las necesidades que nosotros deseamos satisfacer, constituye toda una red de monitoreo y gestión para redes telefónicas e IP (Internet Protocol), es la plataforma NetQuest de Tekno Telecom [3]; pero además de cubrir las funciones de dicha plataforma, nuestra solución propende por mantener las interfaces de gestión de un modo más abierto, de manera que cualquier desarrollador pueda implementar nuevas funcionalidades de gestión soportadas sobre las interfaces que proveemos, dando así mayor libertad a los proveedores de servicios.

Las pequeñas y medianas empresas del sector de las telecomunicaciones pueden mantener su competitividad a nivel de servicios, con una pequeña inversión, utilizando una solución como la que proponemos, en la que se integran la RI, RDSI, SS7 y JMX para crear una plataforma RIA para prestación de servicios multimediales que sean gestionables utilizando las capacidades de SS7 a través de una interfaz abierta de gestión. En la sección 1 del artículo tocaremos algunos de los antecedentes tecnológicos que dieron pie a este proyecto, las capacidades y posibilidades de los servicios multimediales a través de RDSI serán expuestas en la sección 2, mientras la sección 3 estará enfocada en el uso de una plataforma de gestión abierta para utilizar las capacidades que en este campo nos ofrece SS7, una reseña acerca del caso de uso que se trabaja, vídeo por demanda a través de RDSI, será tratado en la sección 4, y por último en la sección 5 encontraremos las posibilidades para trabajos futuros relacionados con este proyecto y las conclusiones acerca de él. 1. ANTECEDENTES Desde sus inicios RDSI ha intentado proveer a los usuarios de un mayor número de servicios, integrados sobre una misma red, para ello ha tratado de explotar al máximo los recursos existentes con el fin de proveer un mayor ancho de banda, que permita una completa y adecuada prestación de estos servicios. Sin embargo para la prestación de servicios con calidad, no es suficiente obtener alto rendimiento de los recursos de una red, también es necesario gestionar estos recursos de una manera flexible y abierta con el fin de que sean utilizados racionalmente y además que puedan ser adaptados a las necesidades de cada usuario. Para gestionar la calidad de nuevos servicios, RDSI-BE se soporta en la infraestructura de red más difundida del mercado como lo es la RTPC (Red Telefónica Pública Conmutada), pues aunque esta no provea por si misma el suficiente ancho de banda necesario para la prestación de nuevos servicios avanzados, con la ayuda de métodos de compresión de video, módems y una buena gestión, puede lograrse que se introduzca estos servicios con un rendimiento aceptable, al menos por algún tiempo. Específicamente para la RTPC la UIT ha definido un estándar completo para el transporte y la señalización entre sus nodos, este estándar se denomina SS7 (Sistema de Señalización Número 7) y hoy en día es el más difundido a nivel mundial para redes de este tipo, tanto así que a pesar de que SS7 no resulta tan eficiente a nivel de trasporte como los nuevos protocolos de comunicación como ATM, TCP/IP y Frame Relay estos no lo han desplazado sino que han buscado la manera de adaptarse para interactuar con él. Por lo anterior y teniendo en cuenta que SS7 también fue concebido para darle soporte a RDSI, se puede concluir que para gestionar los recursos de RDSI-BE se deben adaptar

los sistemas de gestión de servicios para que interactúen con la RTPC por medio de SS7. La Red Inteligente (RI) se define como una arquitectura independiente de la red de transporte para redes de telecomunicaciones, que permite la introducción de nuevos servicios o la modificación de los servicios existentes de una manera eficiente y flexible. La arquitectura de RI es una arquitectura abierta y genérica que soporta múltiples servicios de telecomunicaciones de valor agregado y facilita su control y administración [4] La RI fue planteada como una solución para aumentar la eficiencia de la prestación de servicios sobre la red telefónica y para ofrecer una independencia proveedorvendedor, su principal característica es que su arquitectura está basada en una separación lógica entre el servicio y la red que lo soporta (red de trasporte). Es por ello que esta arquitectura es preferida para la prestación de servicios sobre la RDSI, pues al ser una arquitectura independiente del proveedor de servicios básicos de telecomunicaciones, la hace muy flexible, permitiendo una fácil y rápida introducción y disponibilidad de nuevos servicios, ofreciendo las siguientes ventajas: Servicios de alta calidad, confiabilidad, seguridad, y competitividad, acceso universal a los servicios, facilidad para la introducción de nuevas tecnologías y aumento de control por parte de los subscriptores. Teniendo en cuenta los escasos recursos con los que contamos para la implementación de un servicio de este tipo y la inminente necesidad de realizar un adecuado control sobre este, se hace fundamental la introducción de un sistema completo de gestión que permita el máximo aprovechamiento de los recursos de las redes. Además, la variedad de los componentes que constituyen los sistemas de telecomunicaciones que integran la computación y telefonía para prestar servicios avanzados de RI, hace necesario la creación de interfaces abiertas de gestión y es ahí donde encontramos en las extensiones de gestión para Java una buena alternativa ya que brinda grandes facilidades para la creación de estas interfaces. Las extensiones de gestión para Java (JMX) [5] han sido creadas para reunir los requerimientos de gestión dinámica que exige el mercado y para ofrecer herramientas a los diseñadores y desarrolladores de soluciones de gestión, para que las aplicaciones sean dinámicas, flexibles y portables, esto significa que un recurso puede ser administrable sin importar cómo está implementado su gestor. El Java Dynamic Management Kit (JDM) es una herramienta basada en Java que permite a los desarrolladores crear rápidamente agentes inteligentes basados en JMX. Este incorpora inteligencia directamente en los agentes para que estos puedan desarrollar tareas de gestión autónomamente, lo que trae los siguientes

beneficios: Reducción del tráfico de gestión de red y en el número de alarmas controladas por administradores, rápida respuesta a eventos, reducción en los costos de administración, entre otros. El framework de gestión es completamente compatible con las plataformas personales de Java, así como con la mayoría de los servicios de gestión, por lo tanto las aplicaciones de JDM pueden conectarse a una variedad de dispositivos de consumo y productos futuros En la actualidad se han desarrollado algunos servicios y aplicaciones soportadas en JMX, las ventajas que le presenta a estas aplicaciones se presentan a continuación, entre otras tenemos: Servicios de red en tiempo real: JMX permite proveer servicios justo a tiempo, esto hace a la red y al negocio más sensible, permitiendo catalizar incluso la más débil oportunidad de ingreso y ayuda a retener incluso a los clientes más exigentes. Servicios justo a tiempo: JMX permite diferenciar los servicios a la medida de los clientes individuales. Esto habilita a los usuarios a que puedan cambiar su configuración en cualquier momento, descargando automáticamente los servicios apropiados en el dispositivo del usuario. Comunicaciones de datos: JMX facilita que los servicios puedan habilitar a los usuarios para descargar sus perfiles de usuario en tiempo real, al igual que permite que los cambios en dicho perfil puedan ser implementados inmediatamente. 2. SERVICIOS MULTIMEDIA DESDE RI SOBRE RDSI Las mayores capacidades que puede brindar RDSI, permiten pensar en montar sobre ella servicios más avanzados, donde el objetivo más cercano se encuentra en la prestación de servicios multimediales que faciliten la vida del usuario y a la vez den una solución tecnológica a problemas sociales, como por ejemplo servicios de Teleeducación, Tele-medicina y Tele-entretenimiento. Sin embargo en nuestro medio se hace necesario la explotación de los recursos existentes al máximo, hecho que nos obliga a utilizar la red existente de telefonía, limitando así las capacidades consideradas ideales para la prestación de este tipo de servicios. Es por ello que se hace necesario utilizar técnicas avanzadas de compresión y transmisión que permitan proveer estos servicios con una calidad aceptable. Entre los servicios que se pueden proveer encontramos: 2.1. Vídeo por Demanda Este servicio provee transferencia de información de video, codificada y comprimida digitalmente, a través de una red

de telecomunicaciones. La fuente se denomina un servidor de Video y el destino un set-top box (STB). Los comandos del usuario son transmitidos a través de la red al servidor de video por medio de un canal de control. El flujo de video reverso es desplegado, luego de decodificado y convertido, en un monitor (usualmente un televisor). El servicio permite al usuario acceder a librerías de películas o a sistemas de almacenamiento digital remoto. El servidor de video actúa como un depósito de videos codificados, el cual, como respuesta, envían el video seleccionado al STB utilizando un canal de ancho de banda a pedido. [6] El requerimiento inicial es transmitido por el usuario a través de su STB, el cual envía mensajes en respuesta a las peticiones del usuario. El STB ofrece al usuario básicamente la misma funcionalidad de un VCR (como adelantar, retroceder, parar y pausar) con la capacidad adicional de decodificar el video y la información de señalización y presentársela al usuario. Para la prestación de este servicio, es necesario el mejor aprovechamiento del canal de transmisión, debido a la alta calidad y fidelidad que se espera en un servicio de video por demanda en el que sus usuarios desean una calidad de imagen, lo más cercana posible a un VCR normal. 2.2. Vídeo Teléfono Este servicio provee transferencia de información de video, codificada y comprimida digitalmente y la información de voz que se transmite en una conversación convencional, a través de la Red Telefónica Pública Conmutada. El flujo de video es desplegado, luego de decodificado y convertido, en un videoteléfono en cada extremo de la comunicación. Para la prestación de este servicio es necesario utilizar técnicas de compresión que permitan reducir los recursos necesarios para la prestación del servicio, en este caso existen sistemas de compresión, que gracias a la redundancia de imágenes, transmiten mayormente la información cambiante de la imagen y con menos frecuencia la información que permanece, como las imágenes de fondo. La calidad esperada por los usuarios no se considera tan alta como para un servicio de video por demanda 2.3. Tele-medicina La Tele-medicina es la utilización de tecnologías de información y comunicación para brindar asistencia médica a quien lo requiera en sitios distantes. Básicamente consiste en la transferencia de información médica a través de redes de comunicación, y se encarga de brindar ayuda en los procesos de toma de decisiones en el diagnóstico, facilitar la transmisión de información de pacientes a distancia, colaborar en tiempo real para el manejo de pacientes a distancia y soportar labores de enseñanza para la salud.

Sus servicios son muy variados, entre ellos encontramos servicios como teleradiología, tele-endoscopía y teledermatología, en los cuales, se envían los resultado de los diferentes exámenes, que son realizados desde puestos de salud en regiones apartadas, hasta el lugar en donde se encuentra el personal de salud especializado, en donde se puede hacer un análisis exhaustivo de los resultados para que se puedan tomar medidas preventivas sobre resultados oportunos y se puedan formular tratamientos adecuados. [7] Igualmente, servicios de telemedicina para educación se soportan en servicios de video-conferencias, para la realización de foros o conferencias interactivas sobre diversos problemas de salud, y así implementar soluciones efectivas con la participación de la comunidad, especialmente en cuanto a prevención de enfermedades. Para realizar un adecuado soporte a este tipo de servicios, es necesario hacer un adecuado uso del canal de transmisión, para poder soportar la transmisión de voz, video, datos e imágenes en tiempo real y con una buena calidad, debido al tipo de información crítica que se maneja. 2.4. Tele-enseñanza Este servicio incorpora información significativa que puede ser de tipo texto, audio, imágenes fijas y móviles (animaciones y video), la cual es accedida y manipulada en tiempo real a través de la RTPC y cuya finalidad es soportar el proceso de formación planificado sin que todos los participantes se encuentren simultáneamente en el mismo lugar, especialmente para personas que no pueden acceder fácilmente a centros educativos, debido a falta de recursos económicos o a que se encuentran en regiones apartadas de los centros urbanos. Adicionalmente, les permite acceder a foros, conferencias, exposiciones, dirigidas por expertos, que se encargan de orientar a los estudiantes remotamente. Para una adecuada prestación de este servicio, se hace necesario soportar el envío de voz, video, datos e imágenes a través de la red, para que los estudiantes y sus docentes puedan intercambiar la información necesaria para una adecuada capacitación y evaluación de resultados en diversos temas. Para este servicio, se hace necesario utilizar un adecuado sistema de compresión de video, que haga uso de redundancia de imágenes y que permita el envío de voz, video, datos e imágenes con una calidad y confiabilidad aceptable. 2.5. Video-conferencia Este servicio permite la transmisión de audio y video, a través de la red, para facilitar el intercambio de información y realizar exposiciones remotas. En este servicio, no solamente se permite una comunicación punto a punto entre dos usuarios, sino la comunicación entre varios usuarios simultáneamente, adicionalmente los integrantes de la

video-conferencia pueden enviar información de datos, que pueda ser de interés de los participantes. Al igual que en el servicio de video-teléfono se pueden utilizar sistemas de compresión de video, que hagan uso de la redundancia de imágenes, igualmente, la calidad de video que se espera no es tan alta como lo sería en un servicio de video por demanda. 2.6. Transmisión de Voz, datos y videos multimedia de alta calidad Este servicio permite el envío de voz, datos y videos multimedia a través de la Red Telefónica Pública Conmutada, de acuerdo a los requerimientos del cliente y con una alta calidad. Utilizando para ello técnicas avanzadas de compresión y transmisión de datos. 3. INTERFAZ DE GESTIÓN CON JMX PARA SS7 3.1. Capacidades de gestión de SS7 SS7 incorpora una gran cantidad de mensajes de gestión de señalización que son controlables desde la OMAP (Operation, Maintenance and Administration Part) y muchos más mensajes para realizar control de llamadas sobre RDSI. Estos mensajes que originalmente se concibieron para dar fiabilidad a los enlaces de señalización, y para ofrecer servicios RDSI, respectivamente, pueden ser utilizados para conocer el estado de la red de telecomunicaciones y de la mayoría de sus equipos terminales y de conmutación. Si deseamos conocer el estado de funcionamiento de un enlace E1 en particular podríamos realizar la siguiente rutina a nivel de señalización: (Suponemos que la señalización se está transmitiendo sólo por el IT16 y no a través de un E1 dedicado sólo a señalización). • • •

•

Enviar un CQM (Circuit group Query Message) para conocer el estado general del enlace. Solicitar la toma de un IT con retorno para una llamada de prueba IAM (Inicial Adress Message). Despachar el mensaje COT (Continuity Message) y CCR (Continuity Check request Message) para establecer y probar las condiciones de conectividad sobre la petición de llamada. Enviar los mensajes de liberación de recursos para finalizar el proceso, REL (Release Message).

Los mensajes anteriores son un bosquejo general de lo que se podría hacer para verificar el estado de operación de un enlace, podrían incluirse otros mensajes de consulta y verificación, y además entre cada uno de ellos se esperan mensajes de respuesta o confirmación, si alguno no llegara dentro de los tiempo determinados eso ya sería una respuesta del estado del enlace. Para la realización de las pruebas de gestión sobre los enlaces de comunicación se debe tener un adecuado manejo

de los posibles mensajes a utilizar, su lógica de operación y el sentido de las respuestas (o ausencia de estas) de acuerdo a la información solicitada; Aunque los mensajes de los niveles MTP (Message Transfer Part) e ISUP (Integrated Services digital network User Part) se utilizan para gestionar la señalización, podemos utilizar esos mismos mensajes (en diferentes secuencias) para poder obtener datos de gestión de fallas sobre los equipos de la red, tarificación de servicios utilizados, manejo de tráfico sobre las rutas y estadísticas de desempeño. [8] Los aspectos sobre los que se desarrolla la arquitectura propuesta son los orientados a la gestión básica de llamada RDSI o llamadas No RDSI (analógicas), para determinar sus condiciones de tarificación y estadísticas de desempeño (# de intentos de llamada, # de llamadas exitosas, # de llamadas cursadas, entre otros), y conocer las condiciones de tráfico de los enlaces, a nivel de MTP, donde podremos obtener los datos concernientes al nivel de congestión de un enlace, uso de las líneas de desborde para tráfico y # de mensajes perdidos por congestión (entre otros) para conocer el aprovisionamiento y operación de los E1 de la red y sus interconexiones. Por ejemplo podemos realizar una prueba de verificación sobre un terminal en particular, bloqueando un enlace sobre él, y solicitando asignación de un canal sobre su equipo, y aunque no obtendremos una respuesta explícita de error obtendremos los desbordes de los “timers de espera de respuesta” que al hacerlo en un ciclo repetitivo (p.e. 3 pruebas en 2 minutos) nos permitirá inferir que dicho terminal está inoperante por fallas de equipo. Al igual que esta simple prueba se pueden analizar datos de desempeño del sistema y aislar problemas potenciales que pueden ser verificados con pruebas como la mencionada y así poder mantener un mayor nivel de control y respuesta a fallas sobre el sistema. 3.2. Modelo de la plataforma JMX Para la implementación de la interfaz de gestión abierta hemos analizado las capacidades que nos ofrecen arquitecturas como TINA [9] [10], o modelos como CCM [11], en los cuales encontramos grandes ventajas para la implementación de sistemas distribuidos abiertos para gestión basada en TMN; sin embargo dentro de estas referencias vimos la dificultad de manejar sistemas en tiempo real, como lo son los equipos de red de una empresa de telecomunicaciones, que normalmente operan sobre plataformas SORT (Sistema Operativo de Tiempo Real) [12], pero al tener JMX como interfaz de acceso a la gestión podemos implementar beans con RTJ (Real Time Java) [13] que nos permiten acceder a las capacidades de gestión de los MBeans de JMX pero actuando con restricciones de tiempo real. Cabe anotar que los modelos basados en CCM nos ofrecen la ventaja de facilitar la migración de componentes SW y elementos de red, pero para nuestro objetivo es mucho más

relevante contar con un sistema que tenga capacidades de tiempo real para no alterar los flujos de datos sobre las redes de telecomunicaciones ya que una falla sobre la señalización puede causar muchas pérdidas sobre la comunicación y por ende la tarificación de las llamadas y servicios. Las extensiones de gestión Java han sido creadas para reunir los requerimientos de gestión dinámica en el mercado y para ofrecer las herramientas correctas a los diseñadores y desarrolladores de soluciones de gestión. JMX da un camino simple y liviano para implementar objetos java. La implementación con JMX tiene muy pocos contratiempos porque es totalmente independiente de la infraestructura de gestión. Esto significa que un recurso puede ser administrable sin importar cómo está implementado su gestor, por ejemplo este puede estar bajo el paradigma de gestión TMN o ser un NMS que utilice SNMP para interactuar con los agentes. Dentro de la arquitectura de JMX existen 5 componentes básicos que permiten la implementación de esta, a saber: • • • • •

Recurso gestionable JMX. Agente JMX. Servidor de Mbeans. Gestor JMX. APIs adicionales para los protocolos de gestión.

Un recurso gestionable JMX es un recurso que puede ser una aplicación comercial, un dispositivo, o la implementación software de un servicio o una política. Para ser implementado, un recurso puede escribirse totalmente en Java o simplemente ofrecer su capa superficial basada en Java. Algo que necesita ser gestionado, ahora o en el futuro puede implementarse y puede ser considerado como un recurso potencial. Un bean gestionado, o MBean, es un objeto Java que representa un recurso JMX gestionable. Por diseño, los MBeans también siguen el modelo de componentes de JavaBeans, proporcionando un mapeo directo entre los componentes de JavaBeans y la gestionabilidad. Debido a que los MBeans proporcionan implementación de recursos gestionados de una manera regularizada, ellos pueden ser introducidos en cualquier agente de JMX. Un agente JMX es una entidad de compuesta de un servidor MBean, un juego de MBeans representando los recursos gestionados, y por lo menos un protocolo adaptador o conector. Un agente de JMX también puede contener servicios de gestión, también representados como MBeans. El servidor de MBean es un registro para los MBeans en el agente, este es el componente que proporciona los servicios permitiendo la manipulación de MBeans. Todas las

operaciones hechas sobre los Mbeans se hacen a través de interfaces basadas en Java sobre el servidor MBean. Los adaptadores de protocolo y los conectores permiten que las aplicaciones de gestión accedan a un agente JMX y manipulen los MBeans que contiene. Los adaptadores de protocolos dan una representación del MBeans directamente en otro protocolo, como HTML o SNMP. Los conectores incluyen un componente que provee comunicaciones extremo-a-extremo con el agente sobre una variedad de protocolos (por ejemplo HTTP, HTTPS, IIOP). Desde que todos los conectores tienen la misma interface basada en Java, las aplicaciones de gestión usan el conector mas ajustado a su ambiente de red e incluso cambian los conectores transparentemente cuando necesiten evolucionar. Un gestor JMX es una entidad de gestión que provee una interfase para que las aplicaciones de gestión interactúen con el agente, distribuyan o consoliden información de gestión y proporciona seguridad. Los gestores JMX pueden controlar cualquier número de agentes, simplificando las estructuras de gestión altamente distribuidas y complejas. Los agentes y gestores JMX integran servicios que les brindan autonomía e inteligencia. Estos servicios habilitan a los agentes para manejar sus recursos y permiten a los gestores enviar información de un lado a otro entre agentes y aplicaciones de gestión. En la arquitectura JMX, los servicios están como Mbeans que pueden ser adicionados y quitados según las necesidades. Esto brinda escalabilidad a agentes y gestores, que son críticos cuando son desplegados ante los clientes. Las APIs adicionales del protocolo de gestión están pensadas para proveer una comunicación estándar en la interacción de las aplicaciones de gestión Java con las tecnologías de gestión existentes. Típicamente, una aplicación usa una de estas APIs para acceder a un sistema heredado y exponer sus atributos como un recurso JMX gestionable. Este recurso permitirá que cualquier aplicación de gestión acorde con JMX gestione el sistema heredado a través de un agente JMX. Estas APIs, por lo tanto, crean un puente entre las tecnologías existentes y las futuras. Basados en la experiencia y la realimentación de la comunidad que utiliza la tecnología Java, la especificación JMX incluirá una API Gestora SNMP, una Gestora WBEM, una Gestora TMN y APIs de Alarma y Topología. 3.3. MBeans para la gestión con SS7 Existe una arquitectura modelo, basada en un sistema empotrado, que permite el acceso a la información transportada por la red de SS7, y su comunicación se realiza a través de los Mbeans que al registrarse en el servidor de Mbeans ofrecen sus interfaces desde la plataforma JMX para ser accedidas por aplicaciones de gestión, esto lo

podremos ver mejor en el diagrama de dicha arquitectura (Fig. 1). Los mensajes de señalización que se envían a la central para gestionar un servicio, son solicitados directamente desde la interfaz de JMX que cubre al SCP (Service Control Point) de la RIA, desde esta interfaz se accede de manera local, o a través de una red IP, a la plataforma SMART (Sistema Modular para Aplicaciones de Redes inteligentes y Telemáticas) y es ella la que envía los mensajes de SS7 a la central a través de una TITD (Tarjeta de Interfaz de Troncal Digital) que se conecta a la central a través de E1s.

exponen los MBeans a través de sus interfaces. Los MBeans actúan de manera directa con el HW de soporte que permite monitorear, extraer e insertar los mensajes de SS7 que sean necesarios para cualquier función prevista. Los Mbeans que hemos definido (de manera no exclusiva) para la gestión soportada con SS7 son: Gestión de tarificación, gestión de tráfico y gestión de elemento de red. Aunque entre ellos existen similitudes, y redundancia en los mensajes, cada uno es completo e independiente en su función, de manera que en cualquier momento cualquiera puede ser removido, modificado o reemplazado sin afectar la operación del sistema completo.

Este trabajo gira alrededor de la plataforma que ofrece JMX para realizar conexiones a los métodos y atributos que

Figura 1. Arquitectura del sistema de gestión basado en SS7 a través de JMX

Dentro del componente de gestión para tarificación se pueden invocar métodos para registrar inicio y terminación de llamada, identificación de abonado A y abonado B, ruta utilizada, duración de llamada y modificaciones a la tarificación. En el componente de gestión de tráfico se pueden conocer el # de llamadas cursadas, el # de llamadas exitosas, # de llamadas por determinado enlace (o grupo de enlaces), # rutas congestionadas, fecha y hora de los eventos, # enlaces de desborde y # de llamadas desbordadas, entre otras. En el MBean para gestión de elemento de red se pude consultar si el elemento está o no activo y si es un elemento de transporte o señalización. Todas las invocaciones a los métodos de los MBeans se pueden hacer como llamadas RMI (Remote Method Invocation) dinámicas o invocaciones dinámicas de CORBA (Common Object Request Broker Architecture) a través de un ORB (Object Request Broker) o como llamadas de funciones desde Internet, esto para facilitar la implementación de la

aplicación de gestión de acuerdo a las capacidades del desarrollador y los recursos técnicos de que dispongan. En el mercado encontramos otras plataformas de Gestión Integrada para Telecomunicaciones (GIT) soportadas sobre SS7, pero con la diferencia de que sus interfaces son muy cerradas, lo que liga al proveedor con la empresa desarrolladora, además que lo supedita a la disponibilidad de capacitación para manejo de sus productos. Dentro de este trabajo se han realizado pruebas preliminares utilizando prototipos de MBeans que pueden ser accedidos desde la Web, estos MBeans realizan modificaciones básicas sobre atributos de operación (como si fueran variables de MIB – Management Information Base) y ejecutan métodos básicos a través de pulsación de botones sobre la página Web, todo lo cual se puede verificar sobre los datos de configuración para la TITD.

4. ESTUDIO DE UN CASO PRÁCTICO: VoD SOBRE RDSI Luego de hacer un análisis sobre las posibilidades de la implementación de servicios multimedia desde RI sobre RDSI, se ha visto en el servicio de video por demanda un buen ejemplo de implementación, debido a los requerimientos que se pedirían a la red para la prestación del servicio y a las posibilidades que tiene este servicio de tener una amplia difusión en el mercado para cualquier tipo de usuarios. Teniendo en cuenta las capacidades de manejo de SS7 a través de JMX, encontramos que esta es una buena opción para realizar una adecuada gestión de servicios a través del manejo de los recursos de la RDSI, aprovechando la infraestructura de señalización existente. Actualmente estamos desarrollando la implementación de un servicio de VoD desde RIA sobre RDSI, para ser gestionado con SS7 a través de las interfaces creadas para utilizar JMX. Para una adecuada prestación de este servicio se definen los siguientes casos de uso que debe prestar el sistema a desarrollar: •

•

•

•

Iniciar: Es el requerimiento básico de cualquier servicio, en la que se realiza una autenticación de usuario, que permita darle confiabilidad al sistema y realizar una adecuada separación de cada uno de los perfiles de usuario. Seleccionar video: Esta funcionalidad le permite al suscriptor del servicio seleccionar el video que desea visualizar dentro de una lista de videos que se adecue a su perfil definido. Controlar reproducción: Esto habilita al suscriptor a modificar la ejecución del video seleccionado, permitiéndole pararlo, pausarlo, retrocederlo, adelantarlo o ejecutarlo Modificar calidad: Le permite al suscriptor del servicio modificar la calidad del video que se está ejecutando, permitiéndole mejorar o disminuir la calidad del servicio que se encuentra ejecutando de acuerdo a sus necesidades; veamos este caso un poco más en detalle: En el momento en que el módulo de gestión detecta el mensaje en el que el usuario solicita una modificación de su calidad, este se debe comunicar a través de los MBeans con la plataforma SMART, para que esta envíe los mensajes de SS7 a la central a través de una TITD que se conecta a la central a través de un E1. La central RTPC, verifica la disponibilidad de canales B para dicha conexión y si hay canales disponibles confirma el éxito de la operación y la central SMART reasigna las capacidades de sus circuitos y confirma al sistema de gestión la reasignación exitosa, para que finalmente este pueda reasignar los flujos de datos de acuerdo a la nueva capacidad solicitada; en caso de no

• •

• •

•

•

cumplirse las condiciones de disponibilidad de canal se buscan opciones de mayor compresión en los datos y si esto falla entonces se reporta la imposibilidad de mejorar la calidad y se crea un registro de reporte del evento. Finalizar: Habilita a un suscriptor para que finalice la conexión al servicio para liberar los recursos de los que había dispuesto. Suspender Suscripción: Con esta funcionalidad el administrador del servicio puede suspender temporalmente la suscripción de un usuario al servicio. Inicializar configuración: Le permite al administrador del servicio definir las características iniciales para la prestación del servicio a todos los usuarios. Eliminar suscripción: Este caso le facilita al administrador del servicio la eliminación definitiva de la suscripción de un usuario al servicio, impidiéndole acceder nuevamente a este. Suscribir: Capacita al administrador para suscribir un nuevo usuario al servicio, definiendo el perfil del usuario o habilitar nuevamente a un usuario que ha sido suspendido. Gestionar videoteca: Permite al administrador del servicio gestionar la lista de videos que se encuentran en la videoteca.

5. CONCLUSIONES Y TRABAJOS FUTUROS A partir de los conocimientos y experiencias adquiridas durante el desarrollo de este proyecto podemos concluir: La utilización de componentes CORBA y EJB (Enterprise Java Beans) es una excelente opción en la implementación de servicios sobre plataformas RIA, ya que esto introduce facilidades adicionales para la migración de la lógica de gestión y servicio hacia otras redes de comunicación, como puede ser IP. La utilización de una red como RDSI, en vez de una red IP para la prestación de los servicios multimediales sobre RIA, nos permite obtener una mayor facilidad de penetración en el mercado, especialmente en los estratos bajos de la economía, ya que la contratación del VoD sobre RDSI no conlleva la compra de PC para utilizarlo como terminal de acceso al servicio, sino que se utiliza un teléfono y un televisor como terminales. La gestión con SS7 a través de JMX, nos da la oportunidad de aprovechar al máximo la red de señalización para realizar las tareas de gestión de la red y el servicio, lo cual relaciona estos dos niveles de la gestión de una manera más simple y práctica, porque realizamos gestión de red para modificar las características de prestación del servicio, y gestionamos el servicio para modificar el uso que hago de la red.

Trabajar con sistemas abiertos como JMX, nos mantiene las puertas para la incorporación de nuevos sistemas de gestión y servicios, que nos permitan mantener y actualizar de manera rápida y económica la plataforma para RIA. Los MBeans utilizados para las invocaciones de secuencias de mensajes de SS7 para realizar gestión, nos facilitan la incorporación de nuevas secuencias de mensajes, que nos permitan expandir las capacidades de gestión de la plataforma, sin tener que preocuparnos por las interfaces JMX de los SCP, dado que la misma plataforma de JMX nos adapta los conectores a los MBeans permitiendo realizar cambios a los servicios de estos dinámicamente. Dentro de las posibilidades para trabajos futuros, cabe mencionar la adaptación de la plataforma a nivel de servicio, para el SCP principalmente, y su interfaz de gestión, sobre un SOTR para así tener acceso a todas las funcionalidades de gestión que puede requerir un servicio y que deben ser atendidas en tiempo real, para lo cual ya hemos creado un primer avance al utilizar la plataforma JMX, de forma que facilite la incorporación de Beans para RTJ. REFERENCIAS [1] Drake Chris, Pinnes Ed “Thinking outside the box”. Telecommunications Magazine. Mayo 2003. [2] Buckley Sean “Allied forces” Telecommunications Magazine”. Febrero 2003. [3] Tekno Telecom. Net(s) CCS. http://www.teknotelecom.com/Products_NetCCS .htm, 2003. [4] Arteaga Giovanny. “Redes Inteligentes”. Universidad del Cauca. Diciembre 1998 [5] Sun Microsystems, “JAVA[tm] DYNAMIC MANAGEMENT KIT”, http://www.sun.com/products-nsolutions/nep/software/java-dynamic/index.html, 2003 [6] EURESCOM Project P607, “Top-down Approach Applied to Multimedia Services”, Deliverable 1 Volumen 2, Capitulo 2, Junio 1997 [7] Dulcey M.F., López D.M., Shoemaker R., Bohórquez F., Zambrano L. y Rendón A.

[8] [9] [10] [11]

[12] [13]

Proyecto EHAS-Silvia. Servicios de Información Sanitaria para las Zonas Rurales del Cauca. “Implementación de los servicios EHAS” Abril 2003 International Telecommunication Union, Recomendación Q.762, Septiembre de 1997. TINA-C, “Service Architecture”, Version 4.0, 28 October 1996 TINA-C, “Computational Modelling Concept”, Version 3.2, 17 May 1996 OMG, “CORBA Components, Versión 3.0” Adopted specification of the object management group, Inc. Junio de 2002. Yodaiken Victor, “RTLinux manifesto”, New Mexico Institute of technology, 1997 Bollella Greg, “The Real-Time Specification for Java”. Addison-Wesley. 2000. http:www.rtj.org

Reseñas biográficas de los autores Héctor Fabio Jaramillo: Ingeniero en Electrónica y Telecomunicaciones y candidato a Magister en Telemática en la Universidad del Cauca. Profesor del Departamento de Telemática de la Universidad del Cauca. Coordinador del semillero en Sistemas empotrados del Grupo de Ingeniería Telemática, e investigador vinculado al proyecto SMART III (Sistema Modular para Aplicaciones de Red Inteligente y Telemáticas, fase III) del mismo grupo. Sus temas de interés son los sistemas empotrados para aplicaciones telemáticas y los sistemas de gestión para telecomunicaciones. Ana Cristina Moya: Estudiante de X semestre de Ingeniería Electrónica y Telecomunicaciones de la Universidad del Cauca. Perteneciente al semillero en Sistemas empotrados del Grupo de Ingeniería Telemática. Vinculado al proyecto Sistema E-Menú (1er puesto, concurso internacional de diseño estudiantil, área de Telecomunicaciones ISTEC UTP 2002). Martinez José Fernán: Ph.D. en Telecomunicaciones del Departamento de Ingeniería de Sistemas Telemáticos de la Universidad Politécnica de Madrid (España). Profesor del Departamento de Telemática de la Universidad del Cauca (Colombia). Actualmente dirige proyectos de investigación y desarrollo de relevancia nacional e internacional en el dominio de la telemática.