Commande zero-touch sous contrôle humain : une seule commande BSS, des activations sur les réseaux mobile, fixe et TV

Le problème

Un opérateur convergent vend la téléphonie mobile, la téléphonie fixe, l’internet sur GPON (Gigabit Passive Optical Network) et sur cuivre, et la TV par satellite à partir d’un seul BSS. Une seule commande commerciale implique des interventions sur plusieurs éléments de réseau : une nouvelle ligne postpayée touche le HLR (Home Location Register), la PCRF (Policy and Charging Rules Function), l’OCS et la plateforme de messagerie vocale, et chacun parle son propre protocole — MML (Man-Machine Language) sur SSH, SOAP, CLI, HTTP.

Lorsque le gestionnaire de commandes commerciales doit connaître tout cela, une nouvelle offre devient une modification dans plusieurs systèmes, et une panne sur un élément laisse la commande à moitié exécutée sans que personne ne voie où elle s’est arrêtée.

Ce qui est commandé

• Mobile : nouvelle ligne, changement de numéro, changement de SIM ou d’IMEI (International Mobile Equipment Identity), options data et voix, suspension et réactivation dans les deux sens, blocages administratifs, résiliation de ligne, mise sur liste noire d’un terminal.
• Fixe et internet : activation de ligne, coupure et rétablissement, messagerie vocale, présentation du numéro et renvoi d’appel, internet pour les clients résidentiels et entreprises, comptes AAA (Authentication, Authorization and Accounting) et leurs verrouillages.
• TV : réactivation après paiement, suspension pour impayé, décodeur supplémentaire, ordres de travaux d’installation et de désinstallation.

Ce qui change

1. Le BSS envoie un product order via les TM Forum Open API. Le catalogue produits le décompose en lignes de commande jusqu’aux services orientés client et orientés ressource.
2. Le service order management prend en charge le service order (TMF641 Service Order), enregistre le service dans le service inventory et construit un plan d’orchestration à partir des lignes de commande et de leurs dépendances.
3. Pour chaque ressource, il ouvre un resource order : le profil provient de l’inventory des profils de ressource, l’activation (TMF640 Service Activation and Configuration) s’exécute comme template réseau exécutable — un processus BPMN par type d’élément, via HTTP, SSH ou Telnet.
4. Lorsque les éléments confirment, les inventaires de ressources et de services sont mis à jour et le BSS reçoit « completed » sous forme d’événement ; chaque équipe voit en cours de route le statut de chaque ligne de commande.
5. Les modifications en cours d’exécution — ajout, modification, résiliation, suspension, reprise, et révision d’une commande déjà révisée — entrent dans le même plan au lieu d’une nouvelle commande.
6. Lorsqu’un élément échoue ou qu’une étape nécessite une personne, l’étape devient une tâche de provisioning manuel ou un ticket d’incident : une personne modifie la commande et le processus se poursuit. Les ordres de travaux d’installation et de désinstallation sont transmis aux systèmes partenaires.

Ce que cela apporte

• Le BSS envoie une commande et reçoit une réponse ; les protocoles et les jeux de commandes du réseau restent dans le service order management, si bien qu’une nouvelle offre est une modification du catalogue et des templates, et non du BSS.
• Chaque opération est auditée et la connexion à chaque plateforme est surveillée, avec des alarmes à l’écran et par e-mail.
• Objectif de conception : délais d’expiration, utilisateurs, permissions et paramètres de service se modifient dans un écran de configuration avec rôles, sans modification de code.
• Les priorités et le traitement parallèle évitent aux commandes critiques d’attendre derrière une file ; l’objectif de conception est de 30 secondes par activation, désactivation ou modification de service.

Périmètre de la solution

Scénario cible : une solution pour un opérateur convergent couvrant le mobile, le fixe, l’internet et la TV — architecture, décomposition des commandes, adaptateurs vers les éléments de réseau et haute disponibilité sur deux sites, en actif-actif ou actif-passif, sur Kubernetes. Le périmètre est convenu dans le projet, par ligne de service.

Scénario cible pour un service order management renforcé par l’AI : templates réseau sur modèles IETF YANG conjointement avec TMF641 Service Order et TMF640 Service Activation and Configuration, et Knowledge Graph reliant les services orientés client aux ressources réseau — décomposition Customer Facing Service (CFS) et Resource Facing Service (RFS), inventaire et topologie sur modèles YANG. Le modèle est construit dans le projet sur les données de l’opérateur.

Ce qu’apporte MEF.DEV

Service order management sur Enablement & Monetization Platform avec MEF.DEV BPMN Low-code : BPMN Flow Designer, moteur d’orchestration, configuration du catalogue et adaptateurs d’intégration vers les éléments de réseau sous forme de plugins backend, avec l’activation des services et les inventories issus de WideCoup Convergent BSS. Le partenaire BSS et l’opérateur conservent la commande commerciale et la logique métier ; MEF.DEV construit le backend et les adaptateurs.