Anil+Rao%2C+Principal++Analyst+and+Lead+Analyst+for+Network+and+Service+at+Analysys+MasonAnil Rao é o analista principal e chefe de pesquisas de automação de serviços e rede na Analysys Mason, abrangendo uma variedade de tópicos sobre os sistemas operacionais existentes e novos que impulsionarão as transformações digitais das operadoras. Suas principais áreas de pesquisa incluem a automação de criação, provisionamento e operações de serviços em IoT, redes baseadas em NFV/SDN, nuvens de borda e 5G, o uso de análise de dados, aprendizado de máquina e inteligência artificial para aumentar a eficiência e agilidade das operações e outras práticas obrigatórias mais amplas sobre redes sem interação e automação de operações.

Padrões da indústria fragmentados desaceleraram a adoção em larga escala da SDN de transporte

O setor de telecomunicações depende de padrões, que permitem aos provedores de equipamento de rede, fornecedores de software, integradores de sistema e operadoras de rede rapidamente criar e comercializar produtos e serviços em escala, prevenir problemas de interoperabilidade e reduzir o risco de troca de fornecedor. No entanto, quando se trata de automação de rede de transporte e SDN, o setor fez pouco progresso na padronização. As entidades representativas do setor, como a IETF, MEF, ONF e TM Forum, fizeram um enorme esforço para definir estruturas, arquiteturas de controle de rede e especificações de interface para redes de transporte programáveis e habilitadas para SDN. No entanto, esse empenho foi muito independente e resultou em implementações patenteadas e padrões fragmentados.

Um grupo com seis operadoras líderes do mercado está colaborando para enfrentar esse problema. O resultado dos seus esforços é o fluxo de trabalho MUST (Mandatory Use Case Requirements for SDN for Transport) no grupo atuante TIP OOPT.

O MUST visa harmonizar a abordagem do setor de telecomunicações para automação e controle de SDN de transporte

O fluxo de trabalho MUST funciona com base em três princípios:

  • Estabelecer uma arquitetura de referência definida em conjunto para o controle de SDN de transporte. A arquitetura definida consistirá na hierarquia de controladores de SDN. Cada domínio de rede de transporte (micro-ondas, óptico e IP) terá um controlador de SDN de vários fornecedores específico para domínio. Um controlador de SDN de vários domínios e de camada superior fornecerá outro nível de abstração em controladores de SDN de vários fornecedores, permitindo o gerenciamento unificado de várias camadas de todas as redes de transporte. O controlador de vários domínios se comunicará com os sistemas de suporte de operação (OSS) usando APIs abertas com base em padrões para reunir as informações necessárias para orquestração de serviço, execução de pedidos e gerenciamento de inventário unificado (Figura 1).
Figure+1%3A+Transport+SDN+reference+architecture+used+by+Telef%C3%B3nica

Figura 1: arquitetura de referência SDN de transporte usada pela Telefónica

 

  • Fazer curadoria de modelo de serviço/dados e interfaces relevantes. As interfaces northbound (NBIs) entre os controladores de SDN de vários fornecedores e o controlador de SDN de vários domínios serão baseadas em RESTCONF. YANG e NETCONF serão usados para modelos de dados. A IETF está desenvolvendo a NBI para redes IP/MPLS, a API de transporte ONF foi escolhida para rede óptica e a padronização da NBI para rede de micro-ondas ainda está em andamento.

  • Adotar uma abordagem ágil orientada por caso de uso para operacionalizar a SDN de transporte. Os CSPs continuarão a definir e priorizar os casos de uso para implementação, permitindo que eles alcancem benefícios contínuos. As especificações técnicas de caso de uso (por exemplo, para interfaces northbound e southbound) também se tornarão uma parte central de documentos de exigências dos fornecedores (como uma RFP) e do processo de desenvolvimento de solução. Assim, os CSPs poderão exigir que os fornecedores cumpram com seu roteiro.

Os princípios, junto com especificações técnicas de caso de uso, serão a base para os CSPs, órgãos reguladores e fornecedores trabalharem na criação de uma arquitetura padronizada em comum.

A Telefónica está usando a estrutura MUST como parte da estratégia iFUSION para automatizar suas redes de transporte

Em conformidade com a estrutura MUST, a Telefónica Deutschland implementou uma arquitetura de controlador de SDN hierárquico para sua rede óptica parcialmente desagregada, o que inclui terminais abertos separados (OTs) e um sistema de linha aberta (OLS). Ela implantou o MDSO da Blue Planet como o controlador da rede de transporte definida por software (SDTN) de vários fornecedores para gerenciar a rede óptica de vários fornecedores. O CSP implementou cinco casos de uso de automação de rede essenciais com base na estrutura MUST: descoberta de rede automatizada, gerenciamento de topologia de serviço, gerenciamento de alarmes, descoberta de inventário de OT e gerenciamento de serviço.

Saiba mais sobre essa implantação no Estudo de caso da Analysys Mason: Telefónica Deutschland forma parceria com a Blue Planet para realizar sua estratégia de SDN de transporte, iFUSION

CSPs podem controlar seu próprio destino com o fluxo de trabalho MUST

A variedade de estruturas de automação e padrões de SDN gerou confusão e atrasou o andamento da automação de rede de transporte. Porém também permitiu aos CSPs aprender lições valiosas e adquirir experiência em primeira mão na criação e operacionalização de redes de transporte baseadas em SDN. Com base nessa experiência, os CSPs devem fazer um esforço conjunto para acelerar o ritmo da automação de rede, não apenas para fornecer serviços de conectividade ágeis e diferenciados, mas também para criar a base da compatibilidade com os novos serviços 5G, como serviços corporativos baseados em network slicing (fatiamento de rede).

O sucesso dos CSPs na automação depende dos fornecedores parceiros, que, por sua vez, precisam de uma direção clara para conduzir suas estratégias de produtos. A fragmentação do setor forçou os fornecedores a criarem produtos em conformidade com diversos padrões e especificações, o que atrasou o ritmo da inovação em geral. Ao mesmo tempo, eles desenvolveram soluções patenteadas para se manterem competitivos e atenderem às demandas dos CSPs que querem prosseguir com as implementações para alcançar objetivos corporativos imediatos. Porém, os CSPs e os fornecedores perceberam que essa não é uma forma eficiente de dimensionar seus negócios.

O fluxo de trabalho MUST equilibra as necessidades dos CSPs e fornecedores e pode oferecer todos os benefícios da padronização. No entanto, isso só será possível se fornecedores e CSPs tomarem as decisões corretas. Isso dá aos CSPs pleno controle sobre suas estratégias de automação de rede de transporte e permite que eles acelerem o ritmo do processo sem comprometer os padrões. Além disso, os fornecedores passam a ter certeza e clareza da direção a seguir para alocar recursos com eficiência para o desenvolvimento, visando acelerar a inovação e criar um negócio rentável.