Redes sin cadenas: el cambio hacia operaciones autónomas basadas en la intención

El sector de las telecomunicaciones, piedra angular de la conectividad global, lleva tiempo experimentando un renacimiento tecnológico impulsado por innovaciones como el 5G, el IoT, el cloud computing y la IA. Como resultado, las redes son cada vez más difíciles de gestionar. Por ello, es necesaria la automatización para gestionar las tareas rutinarias, monitorizar el estado de la red y responder a los problemas en tiempo real. Sin embargo, es posible que las competencias actuales de los proveedores de servicios de comunicaciones (CSP) no se ajusten a las cambiantes demandas de este panorama tan dinámico. Para tener éxito en la era moderna, los CSP necesitan equipos versátiles que incluyan científicos de datos para la interpretación y las operaciones con datos, desarrolladores de software para la automatización mediante interfaces de programación de aplicaciones (API) de proveedores e ingenieros de garantía de servicio para diseñar bucles cerrados que garanticen la fiabilidad del servicio.

Si bien los CSP acortan la brecha mediante la creación de equipos con experiencia diversa, también se benefician simultáneamente de los importantes avances de una tendencia paralela. Los lenguajes de programación han evolucionado hacia paradigmas low-code/no-code y, con la aparición de la IA generativa, nos encontramos en un punto en el que los modelos fundacionales pueden generar código formal basado en descripciones de las tareas en lenguaje natural. Esto dio una nueva perspectiva al concepto de redes basadas en intenciones (IBN), en las que los administradores humanos expresan objetivos de red de alto nivel en un lenguaje natural conocido como "intenciones" y que estas intenciones humanas se traducen automáticamente en políticas y configuraciones de red. IBN tiene el potencial de mejorar la gestión de la red y podría convertirse en un punto de inflexión para abordar la brecha de talento dentro de las empresas de telecomunicaciones. Yendo un paso más allá, las redes autónomas (AN) prometen utilizar las intenciones como entradas para autoconfigurarse, autoptimizarse y autorrepararse de forma autónoma a medida que cambian sus condiciones.

Aunque podemos vislumbrar un futuro brillante tanto para IBN como para AN, persisten las preocupaciones sobre su viabilidad y las aplicaciones de los programas, incluida la expresión de intenciones, la traducción precisa a la configuración de red, la transparencia del sistema y la complejidad, entre otras. En este blog, nos sumergimos en las áreas en las que su aplicación práctica tiene potencial y analizamos los desafíos que pueden encontrar en el camino.

Para comprender la necesidad de agilizar las interacciones entre los equipos de CSP y la red, utilizaremos un nuevo servicio de implementación como ejemplo.

Suponemos que el funcionamiento de la red CSP está automatizado según las especificaciones descritas en la Guía introductoria 1230 (IG1230) sobre la arquitectura técnica de las redes autónomas. En este contexto, el OSS del CSP cuenta con lo siguiente:(1) un coordinador para la prestación de servicios, el aprovisionamiento automatizado y las pruebas automatizadas; (2) un sistema de garantía con inventario de red que recopila datos y genera conocimientos sobre el estado de la red, lo que facilita la toma de decisiones basada en datos en el contexto del control de bucle cerrado; (3) un gestor de políticas que dirige el comportamiento de la red utilizando políticas predefinidas, lo que garantiza la alineación con las políticas generales del CSP. En pocas palabras, las operaciones automatizadas giran en torno al estrecho acoplamiento de los servicios con sus descriptores de servicio TOSCA diseñados por humanos, configuraciones, políticas y flujos de trabajo imperativos en los que los diseñadores de servicios añaden inteligencia y toma de decisiones durante el tiempo de diseño. Los diseñadores de servicios deben prever de forma proactiva una amplia gama de condiciones que pueden darse en la red y proporcionar instrucciones detalladas sobre cómo abordarlas. La experiencia sin intervención se consigue cuando se han previsto las condiciones futuras y existen políticas para gestionarlas.

Utilizamos los términos "día 0", "día 1" y "día 2" para referirnos a las diferentes etapas del ciclo de vida del servicio: diseño del servicio, instanciación del servicio y garantía del servicio, respectivamente.

• El diseño del servicio comprende el desarrollo de varios activos de servicio, como se muestra en la figura 1. Esta es la tarea del equipo de diseño del servicio, que necesita comprender las operaciones del día 1 y el día 2 del servicio y producir los flujos de trabajo y scripts necesarios. Las líneas rojas de la figura 2 representan el proceso de aprovisionamiento de un nuevo servicio, que ahora puede solicitarse.

Figura 1: Día 0 - Proceso de diseño del servicio: diseño de los activos del servicio

• La instanciación del servicio se produce cuando llega la orden de servicio, tras una solicitud del suscriptor. Hoy en día, en los CSP, la orden de servicio suele llegar a través de la interfaz TMF 641 desde el gestor de órdenes de servicio (SOM). Cuando el orquestador de servicios recibe la orden de servicio, se asegura de que los flujos de trabajo se ejecuten y de que las configuraciones de monitorización solicitadas, los modelos de PM/FM y las políticas se implementen y ejecuten. Mostramos la instanciación del servicio en la figura 2 con líneas verdes.

• La garantía del servicio sigue un enfoque de bucle cerrado, en el que las condiciones de los servicios implementados se someten a monitorización continua y a acciones automatizadas a lo largo de su ciclo de vida. Mostramos el bucle cerrado de garantía en la figura 2 con líneas azules.

Figura 2: Interacciones día 0/día 1/día 2

En resumen, la fase de diseño implica una gran cantidad de trabajo manual, ya que es necesario proporcionar a la red las instrucciones para el nuevo servicio.

En IBN, las intenciones se refieren a los objetivos de alto nivel que el CSP quiere alcanzar en su red. En lugar de lidiar con complejas configuraciones de red de bajo nivel durante las operaciones del día 0, como se ha comentado anteriormente, los equipos de ingeniería expresan los objetivos mediante intenciones, y la lógica que sustenta dichas intenciones se traduce en la configuración de red necesaria para cumplir el objetivo.

Tras la aplicación de las configuraciones a la red, la AN monitoriza continuamente los servicios implementados y adapta la configuración para garantizar que las operaciones se mantengan alineadas con las intenciones especificadas. La AN amplía el uso de intenciones a las operaciones del día 2.

A continuación, presentamos algunos de los aspectos en los que las intenciones podrían revolucionar las prácticas establecidas en la era anterior:

• Operaciones de día 0:
  • Preparación para nuevos servicios: aproveche la IA generativa para procesar la entrada de lenguaje natural y complementar de forma autónoma los requisitos del servicio.
  • Introducción de nuevos servicios: defina nuevos servicios utilizando lenguaje natural, como "proporcionar una solución de conectividad personalizada para la comunicación segura dentro de las instituciones sanitarias" o "habilitar la comunicación de dispositivos IoT en toda la infraestructura de las ciudades inteligentes", y aproveche la IA generativa para generar automáticamente los activos de servicio necesarios.
  • Generación automatizada de controladores de recursos específicos del proveedor: ­utilice la IA generativa para crear controladores de recursos específicos del proveedor basados en su documentación.
• Operaciones de día 1:
  • Simplificación de la orden de servicio: permite a los clientes solicitar servicios utilizando lenguaje natural. Este enfoque intuitivo permite disfrutar de una experiencia novedosa a la hora de solicitar servicios, como combinar y mezclar ofertas del catálogo.
  • Comprobaciones de viabilidad: agiliza las comprobaciones de validación a medida que los clientes expresan sus intenciones mediante la evaluación eficiente de factores críticos como la disponibilidad de la línea de fibra óptica. El resultado es una carga reducida para los ingenieros de red, una validación del servicio más rápida y una implementación más ágil y con mayor capacidad de respuesta.
• Operaciones de día 2:
  • Garantía de servicio dinámica: permite a las redes responder de forma inteligente a las condiciones cambiantes y a las necesidades de los usuarios. Las políticas flexibles basadas en intenciones mejoran la agilidad, garantizan la fiabilidad y la capacidad de respuesta en tiempo real de los servicios de red.

Hay dos retos principales que deben abordarse:

1. ¿Cómo expresar y transmitir una intención?
2. Cómo ejecutar una intención: ¿cómo es el controlador de intenciones?

TM Forum presentó la API de redes basadas en intenciones TMF921, que ofrece un marco estructurado para definir intenciones de red de alto nivel. TM Forum define la intención de la siguiente manera: " La intención es la especificación formal de todas las expectativas, incluidos los requisitos, los objetivos y las restricciones que se imponen a un sistema técnico". Sin embargo, la especificación formal plantea una preocupación: los ingenieros de redes tendrían que familiarizarse con este lenguaje formal para aprovechar todo el potencial del concepto de intención. Además, las especificaciones formales no reducen necesariamente el número de parámetros que deben proporcionarse con ellas. Este aspecto desafía la racionalización prevista de la gestión de redes que normalmente se asociaría con IBN.

Además, al formalizar la especificación de intenciones, el controlador de intenciones, el componente central de IBN que contiene la lógica para la interpretación de intenciones, se convierte simplemente en un intérprete determinista del lenguaje formal de intenciones. La cuestión es cómo convertir el gestor de intenciones en un sistema autónomo con un modo de funcionamiento declarativo, de modo que los seres humanos no tengan que anticipar todas las posibles condiciones de la red y proporcionar instrucciones específicas para su resolución. De lo contrario, el funcionamiento del sistema no puede pasar con éxito de automatizado a autónomo (TMF IG1230).

En futuros blogs, abordaremos con más detalle los retos y oportunidades de IBN y AN. ¿Desea obtener más información?