Zero-touch ordering com pessoas no controlo: uma encomenda do BSS, ativações nas redes móvel, fixa e de TV

O problema

Um operador convergente vende serviços móveis, telefonia fixa, internet sobre GPON (Gigabit Passive Optical Network) e cobre, e TV por satélite a partir de um único BSS. Uma única encomenda comercial implica trabalho em vários elementos de rede: uma nova linha pós-paga envolve o HLR (Home Location Register), o PCRF (Policy and Charging Rules Function), o OCS e a plataforma de correio de voz, e cada um fala o seu próprio protocolo — MML (Man-Machine Language) sobre SSH, SOAP, CLI, HTTP.

Quando o gestor da encomenda comercial tem de conhecer tudo isto, um novo pacote torna-se uma alteração em vários sistemas, e uma falha num elemento deixa a encomenda a meio sem que ninguém veja onde parou.

O que é encomendado

• Móvel: nova linha, mudança de número, mudança de SIM ou de IMEI (International Mobile Equipment Identity), pacotes adicionais de dados e voz, suspensão e reativação em ambos os sentidos, bloqueios administrativos, remoção de linha, colocação de equipamentos em lista negra.
• Fixo e internet: ativação de linha, corte e religação, correio de voz, identificação de chamadas e reencaminhamento de chamadas, internet para clientes residenciais e empresariais, contas AAA (Authentication, Authorization and Accounting) e os respetivos bloqueios.
• TV: reativação após pagamento, suspensão por falta de pagamento, um descodificador adicional, ordens de trabalho de instalação e de desinstalação.

O que muda

1. O BSS envia uma product order através da TM Forum Open API. O product catalog decompõe-na em order items até aos serviços customer-facing e resource-facing.
2. O service order management recebe a service order (TMF641 Service Order), regista o serviço no service inventory e constrói um plano de orchestration a partir dos order items e das dependências entre eles.
3. Para cada recurso, abre uma resource order: o perfil vem do inventory de perfis de recursos, e a ativação (TMF640 Service Activation and Configuration) corre como um template de rede executável — um processo BPMN por tipo de elemento, via HTTP, SSH ou Telnet.
4. Quando os elementos confirmam, o resource inventory e o service inventory são atualizados e o BSS recebe «completed» como evento; todas as equipas veem, ao longo do percurso, o estado de cada order item.
5. As alterações em curso — adicionar, alterar, desligar, suspender, retomar e a revisão de uma encomenda já revista — entram no mesmo plano, em vez de uma nova encomenda.
6. Quando um elemento falha ou um passo precisa de uma pessoa, o passo torna-se uma tarefa de provisioning manual ou um trouble ticket: uma pessoa edita a encomenda e o processo prossegue. As ordens de trabalho de instalação e de desinstalação seguem para os sistemas dos parceiros.

O que vale

• O BSS envia uma encomenda e recebe uma resposta; os protocolos e os conjuntos de comandos da rede ficam no service order management, pelo que um novo pacote é uma alteração de catálogo e de templates, não do BSS.
• Todas as operações são auditadas e a ligação a cada plataforma é monitorizada, com alarmes no ecrã e por e-mail.
• Meta de desenho: timeouts, utilizadores, permissões e definições de serviço mudam num ecrã de configuração com funções, sem alterações de código.
• As prioridades e o processamento paralelo evitam que as encomendas críticas fiquem à espera numa fila; a meta de desenho é de 30 segundos por ativação, desativação ou alteração de serviço.

Âmbito da solução

Cenário-alvo: uma solução para um operador convergente que abrange móvel, fixo, internet e TV — arquitetura, decomposição de encomendas, adaptadores para os elementos de rede e alta disponibilidade em dois sites, ativo-ativo ou ativo-standby, em Kubernetes. O âmbito é acordado no projeto, por linha de serviço.

Cenário-alvo para service order management potenciado por AI: templates de rede sobre modelos IETF YANG em conjunto com TMF641 Service Order e TMF640 Service Activation and Configuration, e Knowledge Graph a ligar os serviços customer-facing aos recursos de rede — decomposição Customer Facing Service (CFS) e Resource Facing Service (RFS), inventory e topologia sobre modelos YANG. O modelo é construído no projeto com os dados do operador.

O que a MEF.DEV traz

Service order management na Enablement & Monetization Platform com MEF.DEV BPMN Low-code: BPMN Flow Designer, motor de orchestration, configuração do catálogo e adaptadores de integração para os elementos de rede como backend plugins, com a ativação de serviços e os inventories do WideCoup Convergent BSS. O parceiro de BSS e o operador mantêm a encomenda comercial e a lógica de negócio; a MEF.DEV constrói o backend e os adaptadores.