Plataforma de prestación de servicios

Una plataforma de prestación de servicios (SDP) es un conjunto de componentes que proporciona una arquitectura de prestación de servicios (como creación de servicios, control de sesiones y protocolos) para un tipo de servicio entregado al consumidor, ya sea un cliente u otro sistema. Aunque se usa comúnmente en el contexto de las telecomunicaciones, puede aplicarse a cualquier sistema que brinde un servicio (por ejemplo, teléfono VOIP, TV por protocolo de Internet, servicio de Internet o SaaS). Aunque el TM Forum (TMF) está trabajando para definir especificaciones en esta área, no existe una definición estándar de SDP en la industria y los diferentes actores definen sus componentes, amplitud y profundidad de maneras ligeramente diferentes.

Los SDP a menudo requieren la integración de capacidades de TI y la creación de servicios que crucen los límites de la tecnología y la red. Los SDP disponibles hoy en día tienden a optimizarse para la prestación de un servicio en un dominio tecnológico o de red determinado (por ejemplo, en telecomunicaciones esto incluye: web, IMS, IPTV, TV móvil, etc.). Por lo general, proporcionan entornos para el control, la creación, la orquestación y la ejecución de servicios. Nuevamente en telecomunicaciones, esto puede incluir abstracciones para control de medios, presencia/ubicación, integración y otras capacidades de comunicación de bajo nivel. Los SDP son aplicables tanto a aplicaciones comerciales como de consumo.

Solo en el contexto de las telecomunicaciones, el objetivo comercial de implementar el SDP es permitir el rápido desarrollo y despliegue de nuevos servicios multimedia convergentes, desde servicios telefónicos POTS básicos hasta complejas conferencias de audio/video para videojuegos multijugador (MPG). En el contexto de SaaS, se logran objetivos comerciales similares pero en un contexto específico del dominio comercial particular.

La aparición de las tiendas de aplicaciones, para crear, alojar y distribuir aplicaciones para dispositivos como los teléfonos inteligentes iPhone de Apple y Android de Google, se ha centrado en los SDP como medio para que los proveedores de servicios de comunicación (CSP) generen ingresos a partir de datos. Al utilizar el SDP para exponer sus activos de red a las comunidades de desarrollo internas y externas, incluidos los desarrolladores web 2.0, los CSP pueden gestionar los ciclos de vida de miles de aplicaciones y sus desarrolladores.

Las empresas de telecomunicaciones, incluidas Telcordia Technologies, Nokia Siemens Networks, Nortel, Avaya, Ericsson y Alcatel-Lucent, han proporcionado infraestructuras e interfaces de integración de comunicaciones desde principios y mediados de los años 1990. El éxito en materia de ahorro de costos de los sistemas VoIP basados en IP como sustitutos de los sistemas propietarios de centrales telefónicas privadas (PBX) y de los teléfonos de escritorio ha provocado un cambio en el enfoque de la industria de los sistemas propietarios a las tecnologías estándar abiertas.

Este cambio hacia entornos abiertos ha atraído a empresas de telecomunicaciones centradas en software como Teligent Telecom y ha permitido a integradores de sistemas como Tieto, Accenture, IBM, TCS, HP, Alcatel-Lucent, Tech Mahindra, Infosys, Wipro y CGI ofrecer integración. servicios. Además, nuevos consorcios de empresas de productos de software de telecomunicaciones ofrecen productos de software preintegrados para crear SDP basados en elementos como servicios de valor agregado, facturación convergente y gestión de relaciones de contenido/socios.

Dado que los SDP son capaces de cruzar fronteras tecnológicas, es posible una amplia gama de aplicaciones combinadas, por ejemplo:

• Los usuarios pueden ver llamadas telefónicas entrantes (Wireline o Wireless), amigos de IM (PC) o los lugares de amigos (GPS Enabled Device) en su pantalla de televisión
• Los usuarios pueden pedir VoD (Vídeo bajo demanda) servicios desde sus teléfonos móviles o video de transmisión de relojes que han ordenado como un paquete de vídeo para el hogar y el teléfono móvil
• Los clientes de Airline reciben un mensaje de texto de un sistema automatizado en relación con una cancelación de vuelo, y luego pueden optar por utilizar una interfaz de voz o autoservicio interactivo para reprogramar

Se espera que el mercado de plataformas de prestación de servicios crezca a una tasa compuesta anual del 10% durante el período previsto 2019-2024.

Historia

A finales de la década de 1990 se produjo un período de cambios sin precedentes en las aplicaciones empresariales a medida que el dominio de las arquitecturas cliente-servidor se relajaba gradualmente y permitía la entrada de arquitecturas de n niveles. Esto representó la llegada del servidor de aplicaciones, un compromiso flexible entre los absolutos del terminal tonto y la PC cliente con mucha lógica. Aunque los participantes en el círculo de los servidores de aplicaciones eran muchos y variados, compartían ventajas comunes: abstracción del proveedor de bases de datos, modelos de programación de estándar abierto (en su mayoría orientados a objetos), características de alta disponibilidad y escalabilidad, y marcos de presentación, entre otros. Estas transformaciones fueron desencadenadas por fuerzas empresariales, incluido el maremoto que supuso el auge de Internet, pero nada de ello habría sido posible sin la proliferación de estándares como el protocolo TCP/IP, el lenguaje de programación Java y la aplicación web Java EE. arquitectura del servidor. Es en este contexto de transformación que se puso en marcha la era de rápidos cambios de las telecomunicaciones.

Hasta los primeros años de 2000, los mercados de tecnologías de telecomunicaciones comerciales y empresariales todavía estaban saturados de hardware y software propietarios. Los estándares abiertos comenzaron a volverse populares a medida que se introdujeron las tecnologías IP y con la rápida expansión de la voz sobre IP (VoIP) para la transmisión de datos de voz a través de redes de paquetes y el protocolo de inicio de sesión (SIP) para el control de medios estandarizados, especialmente en lo que respecta a la voz empresarial. comunicación.

En este nuevo entorno respaldado por estándares, la convergencia de los mundos de voz y datos se ha convertido menos en un apodo para los desastrosos intentos de integración de telecomunicaciones/TI y más en una verdadera vía para la producción de nuevos y mejores servicios para consumidores y empresas. En los últimos años se ha visto la introducción o proliferación de varias bibliotecas de programación SIP (reSIProcate, Aricent, MjSip y su puerto derivado por HSC) y productos basados en el estándar SIP relativamente nuevo, y el estándar IP Multimedia Subsystem definido por el 3GPP ha ganado terreno. un gran número de seguidores. La Plataforma de Entrega de Servicios, cuyo poder proviene en gran parte de la calidad y aceptación de estos estándares de soporte, está ganando rápidamente aceptación como un patrón arquitectónico ampliamente aplicable.

Hoy en día, en la industria se utilizan múltiples definiciones de plataforma de prestación de servicios (SDP) sin que exista un consenso establecido en cuanto a un significado común. Debido a esto, y a la necesidad de que los proveedores de servicios comprendan cómo gestionar mejor los SDP, el TM Forum (TMF) ha comenzado a estandarizar el concepto de Service Delivery Framework (SDF) y la gestión de SDF. La definición de SDF proporciona la terminología y los conceptos necesarios para hacer referencia a los diversos componentes involucrados, como aplicaciones y habilitadores, exposición de redes y servicios, y orquestación.

Lo que se necesita para ofrecer una combinación de servicios personalizados de múltiples SDP a los usuarios finales es un medio para interconectar esos SDP a través de habilitadores de servicios y recursos de red comunes. Sin embargo, el fundamento de estos aspectos del servicio ha sido el concepto fundamental de que los atributos del usuario y los servicios que reciben requieren un repositorio común y un modelo de datos común, como los proporcionados por un directorio LDAP/X.500 o una base de datos HSS. Las primeras implementaciones de SDP de esta naturaleza comenzaron a mediados o finales de la década de 1990 para servicios convergentes de ISP. En los últimos cinco años se han implementado SDP más grandes y complejos en entornos tipo MSO y para operadores móviles.

Contexto

Los SDP se consideran comúnmente para entornos de tipo telecomunicaciones como un sistema central que interconecta el acceso y la infraestructura de red del cliente con los sistemas OSS y BSS. Los SDP en este contexto suelen estar asociados con un régimen de servicio particular, como los teléfonos móviles o los servicios convergentes.

Los PDS también se consideran en el contexto de programas muy grandes de transformación, convergencia e integración que requieren un presupuesto considerable. La dificultad en este tipo de proyectos es que puede haber que tomar cientos de miles de decisiones de diseño e implementación, una vez que se acuerda la arquitectura. Naturalmente, esta cuestión por sí sola dicta la necesidad de desarrollar software y tener habilidades de ingeniería operativa. Probablemente la mejor manera de reducir estos problemas de diseño e integración es simular el SDP en un sistema de pequeña escala antes de que realmente comience el proyecto principal. Esto permite verificar que la arquitectura cumple con los requisitos operativos, de prestación de servicios y comerciales.

Los SDP también deben considerarse no solo como una función central dentro de un operador, sino como una serie de nodos de servicios distribuidos e interconectados (por ejemplo) por razones de redundancia y para diferentes perfiles de servicio para diferentes sectores comerciales y de mercado. Muchos operadores ofrecen productos de escala/calidad comercial, como paquetes de voz, alojamiento web, VPN, servicios de correo, conferencias y mensajería para clientes gubernamentales y corporativos. La evolución de estos paquetes de servicios podría pasar de sistemas de gestión fragmentados a un "entorno de servicios privados virtuales" donde el operador ejecuta un SDP dedicado para cada uno de sus clientes que requieren sus servicios bajo demanda y bajo su control.

Los SDP también se pueden utilizar para gestionar recintos independientes con capacidad inalámbrica, como centros comerciales, aeropuertos, residencias para jubilados y centros de asistencia sanitaria.

Elementos

Entorno de creación de servicios

A menudo, el punto de acceso principal de un desarrollador de software de telecomunicaciones, el entorno de creación de servicios (SCE, también entorno de creación de aplicaciones o entorno de desarrollo integrado), lo utiliza el desarrollador para crear software, scripts y recursos que representan los servicios que se van a utilizar. expuesto. Estos pueden variar en complejidad, desde complementos básicos de Eclipse hasta aplicaciones de modelado de aplicaciones de telecomunicaciones completamente abstractas y basadas en metadatos (como el producto descontinuado CRM Central de Avaya).

El objetivo de la SCE es facilitar la rápida creación de nuevos servicios de comunicación. Haciendo caso omiso de factores como el marketing por el momento, cuanto más fácil sea para los desarrolladores crear servicios para una plataforma determinada, mayor será el número de servicios disponibles y, por tanto, la aceptación de la plataforma por parte del mercado de telecomunicaciones en general. Por lo tanto, un proveedor de infraestructura de telecomunicaciones puede obtener una ventaja significativa con un SDP que proporcione una rápida creación de servicios.

El aprovechamiento de los entornos convergentes de creación de servicios Java EE y SIP aceleró la adopción de plataformas de prestación de servicios. Los desarrolladores de aplicaciones basadas en Java, tradicionalmente centrados en aplicaciones de TI, desarrollan aplicaciones de comunicaciones en tiempo real utilizando Java EE y protocolos de conexión de red como servicios web SIP y Parlay X. Los proveedores de software están combinando estas tecnologías (por ejemplo, Oracle Jdeveloper y Oracle Communication and Mobility Server con el complemento básico de Eclipse) para llegar a una base de desarrolladores más amplia.

Entorno de ejecución

Los entornos de ejecución de servicios (SEE) se utilizan para ejecutar los servicios de comunicación desarrollados en SCE. Los entornos de ejecución suelen estar diseñados para imitar el hardware en el que se espera que se ejecute el servicio en particular. SEE puede incluirse con SCE como IDE

Control de medios

Presencia y ubicación

Un aspecto de un SDP es que debe centrarse en el nuevo "punto de presencia". Este es el punto de acceso de los usuarios a sus servicios convergentes donde sus preferencias y derechos se evalúan en tiempo real. El procesamiento de preferencias y derechos garantiza que los servicios del usuario en sus contextos de dispositivo/ubicación se entreguen correctamente. Como los derechos están relacionados con los regímenes de gestión de productos y servicios del operador, la arquitectura central de un SDP debe definir los productos, servicios, usuarios, preferencias y procesos de derechos gestionados.

La implementación de estándares sigue siendo un factor crítico en las aplicaciones de Presencia. La implementación de estándares como SIP y SIMPLE (Protocolo de inicio de sesión para mensajería instantánea y extensiones de aprovechamiento de presencia) es cada vez más frecuente. SIMPLE Presence proporciona una interfaz estándar portátil y segura para manipular información de presencia entre un cliente SIMPLE (vigilante) y un servidor de presencia (agente de presencia). Consulte JSR 164 para presencia SIMPLE. Los proveedores de servidores SIMPLE Presence incluyen Oracle e Italtel.

Integración

El uso de estándares para la exposición de interfaces entre los SDP y dentro del SDP debería minimizar la necesidad de integración en tres áreas principales: (1) hacia el sur hasta los componentes centrales de la red subyacente (2) entre aplicaciones de soporte como CRM, facturación y activación de servicios (3) aplicaciones y servicios de terceros. La implementación de una arquitectura orientada a servicios (SOA) puede utilizar interfaces estándar y servicios web.

Los proveedores de software incluyen microsistemas HP, wwite, IBM, Oracle y Sun. Los proveedores de equipos de red también ofrecen SDP como IMS, IPTV, TV móvil, etc. y ofrecen la evolución de estos SDP.

Relación con SOA

En los últimos años se ha hablado mucho del concepto de arquitectura orientada a servicios (SOA). Las discusiones que alguna vez se centraron en tecnologías y conceptos de integración de aplicaciones empresariales (EAI) se han trasladado al dominio SOA, favoreciendo ideas como la composición de servicios sobre la simple adaptación de mensajes y técnicas de extracción, transformación y carga.

Las SOA se pueden utilizar como tecnología de integración de aplicaciones dentro de un SDP, pero funcionan mejor cuando se utilizan en funciones de menor rendimiento, como conexiones entre las aplicaciones transaccionales OSS y BSS y el SDP. Las SOA necesitan una consideración cuidadosa si quieren satisfacer las demandas en tiempo real impuestas al SDP por los servicios convergentes de tipo evento.

Un concepto análogo al SDP que se encuentra en el ámbito de SOA es el de ecosistema de servicios web (también conocido como mercado de servicios web) y la plataforma SaaS. Un ecosistema de servicios web es un entorno alojado en el que los participantes exponen sus servicios utilizando tecnologías web comunes como HTTP, XML, SOAP y REST. Este entorno alojado proporciona una serie de componentes de prestación de servicios que cubren aspectos como autenticación, gestión de identidad, medición y análisis de uso, adaptación de contenido, conversión de formato de datos, cobro y pago. Esto permite a los proveedores de servicios centrarse en su funcionalidad principal y subcontratar la prestación de servicios a terceros. Los servicios implementados a través de ecosistemas de servicios web pueden ser críticos para el negocio, pero generalmente no tienen los requisitos de alto rendimiento y tiempo real asociados a los servicios de telecomunicaciones para los cuales se conciben tradicionalmente los SDP. Por lo general, respaldan funciones comerciales comunes, como cotizaciones, gestión de pedidos, gestión de campañas de marketing o atención al cliente. SOA también se puede utilizar para estandarizar procesos operativos y reutilizarlos en todos los SDP.

Implementación de SDP

Se requieren cambios considerables en la arquitectura de red y TI al implementar SDP operativos de servicios convergentes en tiempo real y en el mundo real. Muchos SDP están diseñados como marcos abstractos con diagramas que utilizan etiquetas como "Capa de abstracción de servicios", etc. Dentro de sistemas reales, tales "capas" en realidad no existen. Además, es difícil comprender a partir de diagramas abstractos cuál es el modelo de datos operativo del mundo real y cuántos servidores, bases de datos o directorios podrían usarse o integrarse para formar servicios convergentes SDP y funciones de autocuidado. Los operadores pueden enfrentarse a facturas anuales de electricidad multimillonarias por sus sistemas. De ello se deduce que los SDP de múltiples servidores y múltiples bases de datos no son ecológicos ni rentables, si se pueden integrar las mismas funciones y utilizar mucha menos energía.

Gestión de identidad e información: Para especificar o diseñar un SDP debemos determinar cuáles son las dimensiones de servicio al cliente y al dispositivo. Si el diseño del SDP necesita acomodar, digamos, 1 millón de usuarios así como administrar sus dispositivos y cada elemento identificado requiere de 5 a 10 objetos de información, el SDP central probablemente esté manejando 20 millones de objetos en tiempo real. Dado que la gestión de estos objetos dicta los procesos centrales de gestión de identidades de la plataforma, se debe prestar atención crítica a la forma en que se implementan. La experiencia ha demostrado que un único usuario en un SDP de servicios convergentes puede requerir 100 objetos de información y algunos objetos, como las preferencias, contienen 100 atributos. Los requisitos de capacidad para 10 millones de usuarios indicarían que la plataforma necesita admitir mil millones de objetos y hasta 50 mil millones de atributos.

Identidad y derechos de grupo: Tradicionalmente hemos tratado la administración de identidades como un único usuario o dispositivo que inicia sesión con un nombre y contraseña y hemos asumido que un servidor de identidad que contiene nombres y contraseñas resuelve el problema. Sin embargo, en la práctica, en el mundo MSO, tenemos titulares de cuentas, titulares de cuentas secundarias (los hijos de la familia), invitados, obsequios, contenido, dispositivos y preferencias que deben vincularse para recibir un servicio administrado. Los servicios que recibe la identidad agrupada pueden autorizarse mediante nombre y contraseñas, pero solo deben habilitarse mediante derechos relacionados con el aprovisionamiento de productos. Las arquitecturas SDP deben adaptarse a las funciones de gestión de identidades de grupo y de derechos de productos/servicios.

Presencia y Eventos: La presencia es la gestión del estado de todos los activos en línea. Pero ¿qué significa esto para las arquitecturas de sistemas? Tradicionalmente hemos aplicado una estrategia "transaccional" paradigma en el que, por ejemplo, un usuario inicia sesión y crea una transacción en un conmutador de red, un servidor web o una aplicación de base de datos. Los servicios de presencia significan que gestionamos eventos de estado a tasas mucho, mucho más altas que nuestros sistemas transaccionales tradicionales. La pregunta es: ¿cómo se gestionan millones, si no miles de millones, de eventos en sistemas fragmentados, múltiples arquitecturas de bases de datos o, de hecho, marcos? Las arquitecturas SDP también deberían tener un sistema de gestión de eventos coherente y altamente integrado como función principal.

Identidades convergentes: Surge un problema operativo con 3G IMS y SIP y los servicios convergentes. SIP puede aplicar direcciones IP (IPv4 o v6), URI de SIP (direcciones de correo electrónico) y URI de TEL SIP (números de teléfono) en los campos de mensaje Para, De, Vía y Contacto. Estos identificadores pueden apuntar a un dispositivo telefónico, la puerta de un frigorífico, una granja de contenidos, un único contenido, un usuario o incluso un grupo de usuarios. Esta flexibilidad significa que se puede realizar una llamada SIP desde prácticamente cualquier cosa a cualquier otra cosa, siempre que tenga derecho a hacerlo. Como SIP puede aplicar una combinación de estos identificadores de sistemas de Internet y telefonía en el proceso de llamada, se deduce que el SDP debe acoplar estrechamente su procesamiento SIP con el sistema DHCP y DNS, la base de datos móvil HSS, el sistema de autorización de usuario, el sistema de eventos de presencia. , la libreta de direcciones del usuario, el procesamiento de funciones de llamadas telefónicas y la gestión de servicios/productos del operador con su sistema de derechos, todo en tiempo real. De ello se deduce que dicha funcionalidad sería muy difícil de aplicar a muchas funciones interconectadas y bases de datos fragmentadas que utilizan "SOA".

Las tecnologías y los kits de herramientas del SDP deben abordar tres cuestiones fundamentales:

1. ¿Cuáles son los bienes y servicios que se ofrecen y gestionan en tiempo real por el operador y por los sistemas de autocuidado del cliente - y esto incluye la gestión de los servicios basados en la presencia (el mundo del Internet impulsado por el evento) y cómo se procesan los derechos de usuario en tiempo real.
2. ¿Cuál es el modelo convergente de información de servicios utilizado en el diseño SDP que representa el negocio en línea del operador que tiene suscriptores, dispositivos, llamadas telefónicas, preferencias, derechos, libros de direcciones, etc. para tratar. En muchos casos, las OSM con sólo 10 millones de clientes requieren un SDP con 500 millones de artículos de información - y para que estos artículos sean accedidos miles de veces por segundo por muchas funciones SDP diferentes.
3. Qué es la arquitectura de gestión de eventos / presencia utilizada en el diseño SDP que maneja la velocidad de los eventos de negocios en línea. La situación podría ser que la población de una ciudad que llega a casa por la noche podría generar miles de millones de eventos de estado en línea. ¿Cómo serán procesados por el SDP?

Estos tres requisitos principales del sistema en realidad dictan la arquitectura de un SDP operativo en el mundo real, independientemente de las "etiquetas abstractas" uno se aplica a sus modelos lógicos, SOA, protocolos de bus de mensajes e interconexiones de servidores. Si estos requisitos fundamentales se omiten en el diseño del SDP, el operador tendrá que abordar muchos problemas comerciales, de gestión de servicios y operativos, tales como:

• gestión de identidad (de toda la información del SDP que representa los activos en línea del operador),
• la agilidad de servicio del SDP (es decir, el producto y los servicios que se ofrecen se codifican duro en el SDP para que los nuevos servicios causen actualizaciones de código) y;
• facilidades de auto-cuidado (sin flexibilidad ni consideración de los usuarios de SDP como el idioma, la edad, la vista, las preferencias, etc.).

En algunas situaciones, los MSO tienen millones de líneas de flujos de gestión de productos y servicios codificados en sus sistemas y no pueden pasar fácilmente a las nuevas dimensiones de servicios convergentes.

Una prueba rápida del diseño de un SDP es evaluar su modelo de información y ver si se basa en los entornos de usuario de los servicios convergentes, y ver cómo ese modelo es utilizado y gestionado por todos los sistemas que necesitan incluir su presencia y Funciones de gestión de eventos.

Para apoyar el desarrollo de SDP y la evolución hacia la prestación de servicios ágiles y en tiempo real, se deben considerar los sistemas de próxima generación.