Pedidos zero-touch con personas al mando: un pedido en el BSS, activaciones en redes móviles, fijas y de TV

El problema

Un operador convergente vende móvil, telefonía fija, internet por GPON (Gigabit Passive Optical Network) y cobre, y TV satelital desde un único BSS. Un solo pedido comercial implica trabajo en varios elementos de red: una nueva línea pospago afecta al HLR (Home Location Register), la PCRF (Policy and Charging Rules Function), el OCS y la plataforma de buzón de voz, y cada uno habla su propio protocolo — MML (Man-Machine Language) sobre SSH, SOAP, CLI, HTTP.

Cuando el gestor del pedido comercial tiene que conocer todo esto, un nuevo paquete se convierte en un cambio en varios sistemas, y un fallo en un elemento deja el pedido a medio ejecutar sin que nadie vea dónde se detuvo.

Qué se pide

• Móvil: nueva línea, cambio de número, cambio de SIM o de IMEI (International Mobile Equipment Identity), paquetes adicionales de datos y voz, suspensión y reactivación en ambos sentidos, bloqueos administrativos, baja de línea, inclusión de dispositivos en lista negra.
• Fijo e internet: activación de línea, corte y reconexión, buzón de voz, identificación de llamadas y desvío de llamadas, internet para clientes residenciales y corporativos, cuentas AAA (Authentication, Authorization and Accounting) y sus bloqueos.
• TV: reactivación tras el pago, suspensión por falta de pago, un decodificador adicional, órdenes de trabajo de instalación y desinstalación.

Qué cambia

1. El BSS envía una product order mediante TM Forum Open API. El catálogo de productos la desglosa en order items hasta los servicios customer-facing y resource-facing.
2. Service order management recibe la service order (TMF641 Service Order), registra el servicio en el service inventory y construye un plan de orchestration a partir de los order items y de las dependencias entre ellos.
3. Para cada recurso abre una resource order: el perfil proviene del inventario de perfiles de recursos, y la activación (TMF640 Service Activation and Configuration) se ejecuta como una plantilla de red ejecutable — un proceso BPMN por tipo de elemento, mediante HTTP, SSH o Telnet.
4. Cuando los elementos confirman, se actualizan el resource inventory y el service inventory, y el BSS recibe “completed” como evento; cada equipo ve el estado de cada order item durante el proceso.
5. Los cambios en curso — add, change, disconnect, suspend, resume y la revisión de un pedido ya revisado — entran en el mismo plan en lugar de generar un pedido nuevo.
6. Cuando un elemento falla o un paso requiere a una persona, el paso se convierte en una tarea de provisioning manual o en un trouble ticket: una persona edita el pedido y el proceso continúa. Las órdenes de trabajo de instalación y desinstalación se envían a los sistemas de los socios.

Qué valor aporta

• El BSS envía un pedido y recibe una respuesta; los protocolos y los conjuntos de comandos de la red permanecen en service order management, por lo que un nuevo paquete es un cambio de catálogo y de plantillas, no del BSS.
• Cada operación queda auditada y la conexión con cada plataforma se supervisa, con alarmas en pantalla y por correo electrónico.
• Objetivo de diseño: los tiempos de espera, los usuarios, los permisos y los ajustes de servicio se modifican en una pantalla de configuración con roles, sin cambios de código.
• Las prioridades y el procesamiento en paralelo evitan que los pedidos críticos esperen en una cola; el objetivo de diseño es de 30 segundos por activación, desactivación o cambio de servicio.

Alcance de la solución

Escenario objetivo: una solución para un operador convergente que abarca móvil, fijo, internet y TV — arquitectura, descomposición de pedidos, adaptadores hacia los elementos de red y alta disponibilidad en dos sitios, active-active o active-standby, sobre Kubernetes. El alcance se acuerda en el proyecto, por línea de servicio.

Escenario objetivo para un service order management potenciado por AI: plantillas de red sobre modelos IETF YANG junto con TMF641 Service Order y TMF640 Service Activation and Configuration, y Knowledge Graph vinculando los servicios orientados al cliente con los recursos de red — descomposición de Customer Facing Service (CFS) y Resource Facing Service (RFS), inventario y topología sobre modelos YANG. El modelo se construye en el proyecto con los datos del operador.

Qué aporta MEF.DEV

Service order management sobre Enablement & Monetization Platform con MEF.DEV BPMN Low-code: BPMN Flow Designer, motor de orchestration, configuración del catálogo y adaptadores de integración hacia los elementos de red como plugins de backend, con la activación de servicios y los inventarios de WideCoup Convergent BSS. El socio del BSS y el operador conservan el pedido comercial y la lógica de negocio; MEF.DEV construye el backend y los adaptadores.