Este artículo necesita citas adicionales para su verificación . ( septiembre de 2024 ) |
Los sistemas de soporte de operaciones ( OSS ), sistemas de soporte operativo en el uso británico, u Operation System ( OpS ) en NTT [1] son sistemas informáticos utilizados por los proveedores de servicios de telecomunicaciones para gestionar sus redes (por ejemplo, redes telefónicas). Apoyan funciones de gestión como inventario de red , provisión de servicios , configuración de red y gestión de fallas .
Junto con los sistemas de soporte empresarial (BSS), los sistemas de soporte de operaciones respaldan diversos servicios de telecomunicaciones de extremo a extremo. Los BSS y los OSS tienen sus propias responsabilidades en materia de datos y servicios. Los dos sistemas juntos suelen abreviarse como OSS/BSS, BSS/OSS o simplemente B/OSS.
El acrónimo OSS también se utiliza en forma singular para referirse a todos los Sistemas de Soporte de Operaciones considerados como un sistema completo .
El TM Forum , los laboratorios de investigación industrial y los proveedores de OSS han propuesto distintas subdivisiones del OSS . En general, un OSS cubre al menos las siguientes cinco funciones:
Antes de 1970, muchas actividades de OSS se realizaban mediante procesos administrativos manuales. Sin embargo, se hizo evidente que gran parte de esta actividad podía ser reemplazada por computadoras . En los siguientes 5 años aproximadamente, las compañías telefónicas crearon una serie de sistemas informáticos (o aplicaciones de software ) que automatizaron gran parte de esta actividad. Este fue uno de los factores impulsores del desarrollo del sistema operativo Unix y el lenguaje de programación C. Bell System compró su propia línea de productos de computadoras PDP-11 de Digital Equipment Corporation para una variedad de aplicaciones OSS. Los sistemas OSS utilizados en Bell System incluyen AMATPS , CSOBS, EADAS , Remote Memory Administration System (RMAS), Switching Control Center System (SCCS), Service Evaluation System (SES), Trunks Integrated Record Keeping System (TIRKS) y muchos más. Los sistemas OSS de esta era se describen en Bell System Technical Journal , Bell Labs Record y Telcordia Technologies (ahora parte de Ericsson ) SR-2275. [2]
Muchos sistemas OSS no estaban conectados entre sí y a menudo requerían intervención manual. Por ejemplo, considere el caso en el que un cliente quiere solicitar un nuevo servicio telefónico. El sistema de pedidos tomaría los datos del cliente y los detalles de su pedido, pero no podría configurar la central telefónica directamente; esto lo haría un sistema de gestión de conmutadores. Los detalles del nuevo servicio tendrían que transferirse del sistema de gestión de pedidos al sistema de gestión de conmutadores, y esto normalmente lo haría un técnico que volvería a introducir los datos de una pantalla a otra, un proceso que a menudo se denomina "integración de silla giratoria". Esto era claramente otra fuente de ineficiencia, por lo que el enfoque durante los siguientes años se centró en la creación de interfaces automatizadas entre las aplicaciones OSS: la integración OSS. La integración OSS barata y sencilla sigue siendo un objetivo principal de la mayoría de las empresas de telecomunicaciones.
Gran parte del trabajo sobre el OSS se ha centrado en definir su arquitectura. En pocas palabras, hay cuatro elementos clave del OSS:
Durante la década de 1990, el Sector de Normalización de las Telecomunicaciones de la UIT (UIT-T) realizó nuevas definiciones de arquitectura de OSS en su modelo de Red de Gestión de las Telecomunicaciones (RGT). Esto estableció un modelo de 4 capas de RGT aplicable dentro de un OSS:
En ocasiones se menciona un quinto nivel, que son los elementos mismos, aunque las normas sólo hablan de cuatro niveles. Esto sirvió de base para trabajos posteriores. La gestión de red fue definida con más detalle por la ISO utilizando el modelo FCAPS (fallo, configuración, contabilidad, rendimiento y seguridad). Esta base fue adoptada por las normas TMN de la UIT-T como modelo funcional para la base tecnológica de las normas TMN de la serie M.3000 a M.3599. Aunque el modelo FCAPS fue concebido originalmente y es aplicable para una red empresarial de TI, fue adoptado para su uso en las redes públicas gestionadas por proveedores de servicios de telecomunicaciones que se adhieren a las normas TMN de la UIT-T.
Un tema importante en la gestión de redes y servicios es la capacidad de gestionar y controlar los elementos de red de las redes de acceso y de núcleo. Históricamente, se han hecho muchos esfuerzos en foros de normalización (ITU-T, 3GPP) para definir un protocolo estándar para la gestión de redes, pero sin éxito ni resultados prácticos. Por otro lado, el protocolo SNMP (Simple Network Management Protocol) de la IETF se ha convertido en el estándar de facto para la gestión de Internet y las telecomunicaciones , a nivel de comunicación EML-NML.
A partir del año 2000, con el crecimiento de los nuevos servicios de banda ancha y VoIP, la gestión de redes domésticas también entra en el ámbito de los OSS y la gestión de redes. La especificación TR-069 de DSL Forum ha definido el protocolo de gestión de WAN CPE (CWMP), adecuado para gestionar dispositivos y terminales de redes domésticas en la interfaz EML-NML.
Esta sección puede resultar demasiado técnica para la mayoría de los lectores . ( Septiembre de 2008 ) |
El TM Forum , anteriormente TeleManagement Forum, es una organización internacional de miembros que agrupa a proveedores de servicios de comunicaciones y proveedores de la industria de las comunicaciones. Si bien el OSS está dominado generalmente por tecnologías patentadas y personalizadas, el TM Forum promueve estándares y marcos en OSS y BSS.
En 2005, los avances en la arquitectura de OSS fueron el resultado del programa New Generation Operations Systems and Software (NGOSS) del TM Forum, que se estableció en 2000. Este estableció un conjunto de principios que la integración de OSS debería adoptar, junto con un conjunto de modelos que proporcionan enfoques estandarizados. El NGOSS pasó a llamarse Frameworx.
El Foro TM describe a Frameworx como una arquitectura que es:
Los componentes interactúan a través de un vehículo de comunicación común (utilizando una infraestructura de intercambio de información; por ejemplo, EAI , Web Services , EJB ). El comportamiento se puede controlar mediante el uso de la gestión de procesos y/o la gestión de políticas para orquestar la funcionalidad proporcionada por los servicios ofrecidos por los componentes.
El trabajo inicial de NGOSS del TM Forum se centró en la creación de modelos de referencia para respaldar la visión de las partes interesadas de la empresa sobre la interacción entre procesos, información y aplicaciones. En paralelo, se llevaron a cabo actividades que respaldaron la visión de las partes interesadas de la implementación sobre las especificaciones de interfaz para proporcionar acceso a la capacidad OSS (principalmente MTNM). El trabajo MTNM evolucionó hacia un conjunto de servicios web que proporcionan interfaces de sistemas operativos multitecnología MTOSI . Más recientemente, [ ¿cuándo? ] la iniciativa OSS a través de Java (OSS/J) se unió al TMF para proporcionar API BSS/OSS basadas en NGOSS .
La arquitectura digital abierta (ODA) ofrece un modelo, un lenguaje y un conjunto de principios de diseño clave acordados por la industria. Proporcionará vías pragmáticas para el recorrido desde el mantenimiento de soluciones de software heredadas y monolíticas hasta la gestión de capacidades ágiles basadas en la nube que se pueden orquestar mediante IA . Es una arquitectura de referencia que mapea las API abiertas de TM Forum con las funciones técnicas y de la plataforma comercial. [3]