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

ingeniero en el trabajo

La industria de las telecomunicaciones, piedra angular de la conectividad global, ha estado experimentando un renacimiento tecnológico durante algún tiempo, impulsada por innovaciones como 5G, IoT, computación en la nube e IA. Como resultado, las redes se han vuelto cada vez más difíciles de administrar. Existe la necesidad de automatización para manejar tareas rutinarias, monitorear el estado de la red y responder a problemas en tiempo real. Sin embargo, es posible que los conjuntos de habilidades existentes dentro de los proveedores de servicios de comunicación (CSP) no se alineen con las demandas cambiantes de este ámbito dinámico. Para tener éxito en la era moderna, los CSP necesitan equipos versátiles, incluidos científicos de datos para la interpretación y las operaciones de datos, desarrolladores de software para la automatización a través de interfaces de programación de aplicaciones (API) de proveedores e ingenieros de garantía de servicios para diseñar bucles cerrados que garanticen la confiabilidad del servicio.

Si bien los CSP cierran la brecha al crear equipos con experiencia diversa, también se benefician simultáneamente de avances significativos en una tendencia paralela. Los lenguajes de programación han evolucionado hacia paradigmas de código bajo/sin código y, con la aparición de la IA generativa, estamos 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 la intención (IBN), donde los administradores humanos expresan objetivos de red de alto nivel en lenguaje natural conocidos 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. Dando un paso más allá, las redes autónomas (AN) prometen utilizar intenciones como entradas para autoconfigurarse, autooptimizarse y autocorregirse de forma autónoma a medida que evolucionan sus condiciones.

Si bien podemos imaginar un futuro brillante tanto para IBN como para AN, existen preocupaciones persistentes sobre su viabilidad y aplicaciones de 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 adentramos en las áreas donde su aplicación práctica tiene potencial y analizamos los desafíos que pueden encontrar en el camino.

Un caso motivador: introducción de nuevos servicios sin intenciones

Para comprender la necesidad de optimizar las interacciones entre los equipos de CSP y la red, utilizaremos un nuevo despliegue de servicios como ejemplo.

Suponemos que la operación de la red CSP está automatizada según las especificaciones descritas en la Guía introductoria 1230 (IG1230) de TMF sobre arquitectura técnica de redes autónomas. En ese contexto, el OSS del CSP tiene (1) un orquestador para el aprovisionamiento de servicios, el aprovisionamiento automatizado y las pruebas automatizadas, (2) un sistema de garantía con inventario de red que recopila datos, crea insights sobre el estado de la red y, por lo tanto, facilita la toma de decisiones basada en datos en el contexto del control de bucle cerrado y (3) un administrador de políticas que dirige el comportamiento de la red empleando políticas predefinidas y garantizando la alineación con las políticas más amplias de CSP. En pocas palabras, las operaciones automatizadas giran en torno a un estrecho acoplamiento de los servicios con sus descriptores de servicio TOSCA diseñados por humanos, configuraciones, políticas y flujos de trabajo imperativos asignados en los que los diseñadores de servicios agregan 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 ocurrir en la red y proporcionar instrucciones detalladas sobre cómo deben abordarse: la experiencia de contacto cero se logra siempre que se hayan previsto las condiciones futuras y existan políticas para manejarlas.

Empleamos los términos Día 0, Día 1 y Día 2 para las diferentes etapas del ciclo de vida del servicio, a saber, diseño del servicio, creación de instancias de servicios 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 del Día 2 del servicio y producir los flujos de trabajo y scripts necesarios. Las líneas rojas en la Figura 2 representan el proceso de aprovisionamiento de un nuevo servicio, lo que garantiza que ahora se pueda solicitar el servicio.
Proceso de diseño de servicios del Día 0: diseño de activos de servicio

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

  • La creación de instancias de 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 administrador 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 monitoreo solicitadas, los modelos de PM/FM y las políticas se desplieguen y ejecuten. Mostramos la creación de instancias de servicio en la Figura 2 en líneas verdes.
  • La garantía del servicio sigue un enfoque de bucle cerrado en el que las condiciones de los servicios desplegados se someten a un monitoreo continuo y a acciones automatizadas del ciclo de vida. Mostramos el bucle cerrado de aseguramiento en la Figura 2 en líneas azules.
Interacciones del Día 0/Día 1/Día 2

Figura 2: Interacciones del Día 0/Día 1/Día 2

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

¿Qué son las intenciones?

En IBN, las intenciones se refieren a objetivos de alto nivel que CSP quiere lograr en su red. En lugar de lidiar con configuraciones de red complejas de bajo nivel durante las operaciones del Día 0 como se mencionó anteriormente, los equipos de ingeniería expresan los objetivos con intenciones y la lógica que sustenta las intenciones los traduce en la configuración de red requerida que cumple con el objetivo de la intención.

Después de la aplicación de las configuraciones a la red, la AN monitorea continuamente los servicios desplegados y adapta la configuración para garantizar que la operación permanezca alineada con las intenciones especificadas. La AN amplía el uso de intenciones a las operaciones del día 2.

Perspectivas de IBN y AN

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

  • Operaciones del Día 0:
    • Preparación para nuevos servicios: aproveche la IA generativa para procesar entradas 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 de atención médica" o "habilitar la comunicación de dispositivos IoT en toda la infraestructura de la ciudad inteligente" y aprovechar la IA generativa para la generación automática de los activos de servicio necesarios.
    • Generación automatizada de impulsadores de recursos específicos del proveedor: utilice IA generativa para crear impulsadores de recursos específicos del proveedor, basados en la documentación del proveedor.
  • Operaciones del Día 1:
    • Simplificación de la orden de servicio:permite a los clientes solicitar servicios utilizando lenguaje natural. Este enfoque fácil de usar permite una experiencia novedosa de pedido de servicios, como mezclar y combinar 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 redes, una validación de servicios más rápida y un despliegue más ágil y receptivo.
  • Operaciones del Día 2:
    • Garantía dinámica del servicio: permite que las redes respondan de manera inteligente a las condiciones cambiantes y a las necesidades de los usuarios. Las políticas flexibles basadas en la intención mejoran la agilidad, garantizando la confiabilidad y la capacidad de respuesta en tiempo real de los servicios de red.

Los desafíos con IBN y AN

Hay dos desafíos principales que deben abordarse:

  1. ¿Cómo expresar y transmitir una intención?
  2. Cómo ejecutar una intención: ¿cómo se ve el intent handler?

TM Forum presentó la API de redes basadas en intenciones TMF921, que ofrece una infraestructura 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, objetivos y restricciones dadas a un sistema técnico”. Sin embargo, la especificación formal parcial introduce 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 intenciones con especificación formal no necesariamente reducen la cantidad de parámetros que deben proporcionarse con ellas. Este aspecto desafía la racionalización anticipada de la gestión de red que normalmente se asociaría con IBN.

Además, al formalizar la especificación de la intención, el intent handler, el componente central de IBN que contiene la lógica para la interpretación de la intención, se convierte simplemente en un intérprete determinista del lenguaje formal de la intención. La pregunta que surge es cómo evolucionamos el intent handler hacia un sistema autónomo con una forma de operación declarativa en la que los humanos no están obligados a anticipar cada condición potencial de la red y proporcionar instrucciones específicas para su resolución. De lo contrario, la operación del sistema no puede pasar con éxito de automatizada a autónoma (TMF IG1230).

En futuros blogs abordaremos los desafíos y oportunidades de IBN y AN con más detalle. ¿Quiere aprender más?

 

Autor

Maja Curic

Telco Network Cloud Architect at IBM

Chris van Maastricht

Associate Partner & Industry Expert - Network & OSS Transformation

IBM Consulting

Thomas Tattis

VP and Senior Partner Global Telco & Media Industry CoE IBM Consulting

IBM Consulting