Redes de telecomunicação (11) - Going all-IP (parte 2)

Seguindo com o assunto da conversão das redes fixas e móveis convencionais em uma estrutura convergida e all-IP, comumente denominada Next Generation Network - NGN.

A arquitetura da NGN que vimos na parte anterior deste artigo não tinha a menor condição de acontecer sozinha, ou em separado da estrutura convencional dos serviços de voz por comutação de circuitos. Três problemas fundamentais precisavam ser solucionados para que a NGN pudesse surgir como uma evolução, e não como uma ruptura com a arquitetura das redes existentes:

1. Como garantir a interoperação entre usuários do serviço convencional de telefonia e usuários do serviço de voz na NGN, que utilizam Voice over Internet Protocol (VoIP)?
2.  Como substituir a transmissão convencional TDM (veja este artigo anterior) por uma rede TCP/IP?
3. Como controlar a utilização de serviços de voz, video e dados dos usuários NGN?

Nesta parte deste artigo vamos responder às primeiras duas questões. A resposta para a terceira questão fica para a próxima parte.

Na telefonia convencional (Plain Old Telephone Service - POTS) o estabelecimento dos circuitos para tráfego de voz é mediado pela troca de sinalização entre os elementos da rede. Esta sinalização normalmente é dual-tone multifrequency (DTMF) entre os aparelhos dos usuários e as suas respectivas centrais de comutação local, e Common Channel Signaling System #7 (CCSS7 ou SS7) entre centrais de comutação.

Tanto o canal para o tráfego de voz quanto os canais de interconexão entre os elementos de sinalização SS7 (essencialmente Service Switching Points - SSPs e  Signal Transfer Points - STPs) são mapeados sobre a rede de transmissão TDM, tanto na arquitetura PDH quanto na SDH/SONET (veja artigos anteriores aqui e aqui), como no modelo abaixo.

Quando as operadoras fixas começaram a suportar o tráfego da Internet isso foi feito simplesmente usando a rede de transmissão para mapear conexões virtuais, fim a fim, entre os roteadores. Com o tempo esta estrutura passou a ser suportada sobre uma outra rede de roteadores IP, configurados para formarem um serviço agnóstico de transporte no nível da camada 2 do modelo OSI, chamado Multi-Protocol Label Switching (MPLS), que efetivamnte substituiu os serviços de comunicação de dados baseados em X.25 e Frame-Relay (veja este artigo anterior). Sobre a rede de roteadores IP/MPLS mapeiam-se redes virtuais privativas (Virtual Private Networks - VPNs) que isolam logicamente o tráfego de cada grupo de usuários. Nosso modelo operacional, agora, adquiriu a seguinte aparência.

O próximo passo do caminho é a introdução de um novo tipo de central de comutação, conhecido como softswitch. Uma softswitch é composta por dois tipos de elementos: um Media Gateway Controller (MGC) que, como diz o nome, controla um conjunto (que pode ser geograficamente disperso) de Media Gateways (MGW), responsáveis pelo transcoding e pala conectividade VoIP do tráfego de voz.

Quanto à sinalização, o MGC incorpora:

•  Um elemento SSP da sinalização SS7, o que permite que a softswitch interopere com as centrais de comutação POTS tradicionais;
• Sinalização de controle dos seus MGWs subordinados, conforme a recomendação  ITU-T H.248.1 v3 

nota histórica: O protocolo H.248 foi desenvolvido conjuntamente pela ITU-T e pela IETF (MEGACO -  RFC 3015, e GCP - RFC 3525) mas, como explicado na RFC 5125, a ITU-T assumiu integralmente a tarefa de especificação deste protocolo.

O tráfego de sinalização SS7 convencional também pode ser adaptado para transporte sobre IP através de gateways SIGTRAN, que são vistos como SCPs pelos SSPs convencionais, e tunelam entre eles as mensagens SS7 sobre a rede de transporte IP/MPLS. Falando nisso, tipicamente criam-se duas novas VPNs (ou Virtual Routing and Forwarding - VRFs, no jargão MPLS) para o transporte individualizado do tráfego de voz e do tráfego de sinalização.

Finalizando o modelo temos o tráfego TDM legado que, por algum motivo, não possa ser acomodado através das softswitches. Para isso os roteadores IP/MPLS implementam emulação de circuitos TDM sobre o transporte IP, de acordo com os padrões desenvolvidos pelo grupo de trabalho Pseudo-Wire Emulation Edge to Edge (PWE3) da IETF.

E assim chegamos, finalmente, aos dias atuais. Pelo desenho acima já deu pra perceber que gradualmente o tráfego está sendo transportado nativamente sobre IP/MPLS, e que as hierarquias de transmissão TDM (PDH e SDH/SONET, que foram explicados antes neste artigo e neste artigo) vão sendo progressivamente relegadas ao papel de suporte ao tráfego de equipamentos ou serviços legados, para os quais não existe solução prática diretamente sobre a rede de transporte IP/MPLS.

Mesmo o papel de oferecer conectividade entre os roteadores IP/MPLS está gradualmente saindo da esfera dos multiplexadores SDH, com a gradual adoção de redes ópticas de grande capacidade, que fazem FDM (falamos disso neste artigo) sobre fibras ópticas. Mas, como sempre acontece, damos um novo nome a velhas coisas, e isto passa a ser conhecido como Wavelength Division Multiplexing (WDM). A depender da quantidade de comprimentos de onda (lambdas, para os íntimos) que podem ser multiplexados sobre uma fibra óptica, estes sistemas são chamados de Coarse WDM (CWDM) ou Dense WDM (DWDM).

Existe (mais uma!) "guerra religiosa" em andamento nesta área, a respeito de como organizar o plano de controle da rede de transporte integrada formada pelos roteadores IP/MPLS e pelos elementos da rede WDM. As hipóteses disputando a dominância de mercado são:

• Usar o plano de controle dos roteadores IP/MPLS, e manter a rede óptica subjacente apenas como canais de transporte independentes. Neste modo os roteadores IP/MPLS usam interfaces IP over DWDM (IPoDWDM) para interoperar ativamente com a rede óptica, de acordo com a recomendação G.709/Y.1331 da ITU-T;
• Usar o plano de controle da rede óptica configurada como uma OTN, e interligar os roteadores IP/MPLS de forma passiva, através de transponders;
• Integrar os planos de controle IP/MPLS e óptico. As propostas mais avançads neste sentido são o MPLS-TP e o GMPLS, ambos com muito trabalho a ser feito antes de poderem ser utilizados em larga escala.

Caramba, como isso tá ficando comprido! Vou parar por aqui e, na próxima (e, possivelmente, última) parte deste artigo vou falar da arquitetura geral para uma NGN fixa e móvel, e vamos falar do IMS, como um dos elementos chave desta arquitetura convergente.