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.
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.
Figura 1: Proceso de diseño de servicios del Día 0: diseño de activos de servicio
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.
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.
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:
Hay dos desafíos principales que deben abordarse:
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?