- Operadoras de telecom e seus fornecedores de equipamentos e serviços carrier-class tradicionais;
- Provedores de serviço na Internet (Internet Service Providers - ISPs) e seus fornecedores de equipamentos e serviços Internet-class (que podem ou não ser, também, participantes do grupo anterior de fornecedores);
- Os usuários dos serviços prestados pelos outros grupos.
E isto é uma das principais dificuldades para analisar com isenção o cenário de evolução das redes de telecom em direção à NGN. É difícil separar o que é uma genuína inovação técnica, ou uma verdadeira tendência, do "ruído de fundo" criado pelo intenso bombardeio de propaganda dos fornecedores de equipamentos e serviços. Principalmente aqueles que tem seu próprio destino umbilicalmente ligado ao destino das próprias operadoras (como, por exemplo, os fornecedores de equipamentos SDH e DWDM).
Se a migração das redes para o modelo NGN ocorrer muito rápido eles ficarão "na chuva". Basicamente eles ouvirão dos seus atuais clientes algo parecido com: "segura aí no pincel, que eu tô levando a escada embora". E a consciência disso (por parte deles) aliada a uma postura leniente (em minha opinião) das operadoras de telecom, que, em vez de traçarem seus próprios roadmaps de evolução tecnológica e de serviços (e, depois disso, selecionarem os vendors capazes de satisfazer suas necessidades), meio que "terceirizam" isso para seus fornecedores. Na maioria dos casos o planejamento das operadoras depende demais daquilo que os fornecedores dizem que dá pra fazer, ou não, e quando. No meu conceito, isso é um caso do rabo abanando o cachorro.
Enfim... isso justifica o ambiente de FUD (fear, uncertainty and disinformation) com relação a redes e serviços all-IP que vemos na maioria das operadoras de telecom. Em grande parte ele é criado e disseminado pelos fornecedores, que tem muito a perder. Mas vou tentar não me deixar levar por isso na minha argumentação.
O ponto principal que temos que reconhecer é que, mais do que uma mudança na filosofia e tecnologia de transporte dos dados (e tudo é dados, inclusive a voz), o que caracteriza uma NGN é a capacidade de prover serviços realmente inovadores aos seus usuários. O que vai caracterizar quais modelos de negócio serão vencedores, ou não, neste contexto será sua real capacidade em suportar estes novos tipos de interação dos usuários.
Falamos muito de novos serviços, de serviços avançados, mas quase ninguém entende direito o que isto significa. Vou tentar dar dois exemplos:
- Você está no seu escritório usando um equipamento desktop, em videoconferência com alguns colegas, e a reunião se alonga a ponto de você correr o risco de perder o vôo marcado para o fim da tarde. Então você transfere a sessão de videoconferência do seu desktop (que está usando a rede LAN e o acesso Internet compartilhado do escritório) para o seu laptop/tablet usando acesso wireless 3G/4G e segue para o aeroporto mantendo a videoconferência ativa. Ao chegar no aeroporto você continua com a sessão de videoconferência ativa, porém utilizando a cobertura WiFi do aeroporto como meio de acesso.
- Você usa uma aplicação (no desktop, laptop, tablet ou smartphone - normalmente teremos versões das aplicações adequadas a todos os tipos de plataforma) para programar a sua smart house - ligar o ar condicionado, ativar o microondas onde você deixou o jantar congelado, ligar o aquecedor de água, fechar as cortinas, etc. Mas, em vez de usar um horário específico para cada evento você especifica que todos eles devem ser iniciados após intervalos determinados, contados a partir do recebimento de um sinal disparador. E programa o sistema multimídia do seu carro (que também está conectado) a controlar seu posicionamento em relação à sua casa, e disparar o sinal de acionamento se o tempo estimado de chegada (considerando a rota adotada e as informações de tráfego recebidas) for menor ou igual a, por exemplo, meia hora.
As diversas tecnologias de rede que devem ser integradas e harmonizadas para este cenário estão resumidas no diagrama abaixo (retirado da Recomendação ITU-T Y-110):
O desenho é meio velho (1998), daí ainda mencionar N-ISDN e B-ISDN (respectivamente Narrowband e Broadband Integrated Services Digital Network) como alternativas para o segmento core da NGN. Isto, como vimos em artigo anterior, já foi superado. Mas a ideia geral da variedade de redes de acesso a convergir sobre um core NGN comum (agora all-IP) ainda é válida.
Para o problema de construção de plataformas de redes e serviços de telecom usando componentes COTS a ITU-T produziu um framework chamado CGOE (Carrier-Grade Open Environment), descrito na Recomendação ITU-T Y-2901. O diagrama abaixo (retirado da Recomendação Y-2901) mostra os elementos gerais deste framework.
Arquiteturalmente as NGNs devem separar claramente o estrato de serviço (service stratum) e o estrato da rede de transporte (transport stratum), sendo que cada estrato possui um user plane (onde trafegam os dados de aplicação), um control plane (onde trafegam os dados de sinalização) e um management plane (onde trafegam os dados das aplicações de gerência). Este é o NGN BRM (Basic Reference Model), descrito na Recomendação ITU-T Y.2011, de onde foi retirada a figura abaixo:
Observem que a divisão entre os planos de usuário, controle e gerenciamento dentro de cada estrato é puramente lógica, servindo mais para propósitos administrativos (ex.: determinação dos critérios de QoS aplicáveis a cada caso) do que indicando segregação rígida dos diversos tipos de tráfego dentro de cada estrato.
E assim chegamos, finalmente, no ponto principal para o sucesso da idéia das NGNs: conseguir criar um ecossistema de aplicações que reconheçam um mesmo padrão para a troca de sinalização de controle entre elas. O 3GPP (3rd Generation Partnership Program) fez a primeira proposta abrangente para suportar um ecossistema de aplicações IP que utilizam o protocolo de sinalização SIP (Session Initiation Protocol - veja RFC 3261): o IMS (IP Multimedia Subsystem).
Embora o IMS tenha surgido no contexto das redes móveis, ele mostrou-se bastante adequado para o cenário convergente da NGN, então a ITU-T, na Recomendação Y.2021, adotou o IMS como solução padrão de sinalização SIP para serviços convergentes e all-IP para NGNs.
Vou apresentar a seguir o modelo de referência básico para o IMS, tal como aparece na Recomendação Y.2012, mas aviso logo: tanto a recomendação ITU quanto as especificações do 3GPP que se referm ao IMS causam em mim a impressão que elas foram escritas por computadores, com a intenção de que fossem lidas por máquinas de calcular. Vou (na medida do possível) tentar abrandar isso.
Muito bem... Sem pânico. O primeiro elemento importante a observar é aquela caixinha despretensiosa na parte inferior esquerda do diagrama, marcada UE (User Equipment). Ela representa qualquer tipo de dispositivo que o usuário possa estar utilizando para concetar-se à NGN. A linha do UE para a direita apenas indica que ele tem conectividade IP à NGN, através do estrato de transporte (que, claro, incorpora os segmentos de acesso, backhaul e core).
Os outros relacionamentos importantes do UE são com o AS-FE (Application Server Functional Entity), que é o elemento de tratamento de sinalização no servidor de aplicação que o usuário está tentando acessar (esta comunicação é regida conforme o protocolo de interface Ut - não vou nem tentar detalhar estes protocolos de interface); e com o elemento principal da estrutura do IMS, o CSCF (Call Session Control Function).
O CSCF executa todas as funções que, tradicionalmente, são chamadas de call control: o estabelecimento da sessão (call initiation), os eventos durante a sessão - inclusive aqueles ligados a tarifação (o call control propriamente dito), e o término da sessão (call termination).
O UE entra em contato, usando o protocolo de interface Gm, com o proxy CSCF (P-CSCF). Este elemento pode ser um dos CSCFs nativos da NGN de registro do usuário (nada impede que o CSCF seja implementado de forma distribuída), ou um dos CSCFs da NGN visitada pelo usuário (se ele estiver em roaming em outra NGN). O P-CSCF vai selecionar um serving CSCF (S-CSCF) para executar de fato as funções de call-control. Não vi nenhuma restrição (e acho lógico) que, no caso de um UE dentro da sua própria NGN de registro, as funções de P-CSCF e S-CSCF não possam ser acumuladas por uma única instância do CSCF.
Se a sessão de serviço demandada pelo UE implique em troca de sinalização com servidores que utilizem perfis de sinalização SIP diferentes do IMS, ou outros protocolos de sinalização utilizados em ambiente IP (ex.: H.323), o P-CSCF e o S-CSCF utilizam o serviço de intermediação de um IBC-FE (Interconnection Border gateway Controller Functional Entity), usando o protocolo de interface Mx.
Para os casos de UEs em roaming, ou de tráfego de sinalização que esteja apenas em trânsito através de uma NGN, aparece uma nova variedade de para o CSCF: o interrogating CSCF (I-CSCF), que faz o meio de campo da comunicação entre o P-CSCF e o S-CSCF. A comunicação entre todas estas variantes funcionais do CSCF são regidas pelo protocolo de interface Mw.
O S-CSCF interage com o AS-FE no servidor de aplicação demandado pelo UE através do protocolo ISC (IMS Service Control) e pelo protocolo de interface Ma. Para a correta designação e acesso do S-CSCF ao AS-FE existe a intermediação de elementos de localização (SL-FE - Subscription Locator Functional Entity) e autorização/autenticação (SAA-FE - Service Authentication and Authorization Functional Entity; e SUP-FE - Service User Profile Functional Entity).
Se a sessão de serviço demandada pelo usuário necessita utilizar recursos específicos do estrato de transporte da NGN (ex.: classe de QoS, registro/retirada em grupos de multicast, etc.) o CSCF usa um outro elemento do IMS, o MRFC (Multimedia Resources Control Function), que aciona o elemento MRP-FE (Multimedia Resources Processor Functional Entity) para a implementação das ações específicas de suporte à sessão do serviço no estrato de transporte da NGN.
Para a interoperação de serviços NGN com redes de telecomunicação legadas (PSTN/ISDN) o S-CSCF interage com o MGCF (Media Gateway Control Function). No caso de haver necessidade de trânsito do tráfego entre a NGN e a PSTN/ISDN o S-CSCF utiliza o BGCF (Breakout Gateway Control Function) para determinar qual TMG-FE (Trunking Media Gateway Functional Entity) no estrato de transporte deve ser usado para efetuar o "salto" do tráfego entre as redes. A troca de sinalização fim a fim (SIP/SS7) é mediada por um SG-FE (Signalling Gateway Functional Entity).
Só para terminar, caso vocês ainda não tenham percebido, elementos responsáveis pelo processo de sinalização IMS são chamados Control Functions. Elementos que interagem com o IMS para determinar como executar suas funções corretamente são chamados Functional Entities.
E chega! Acho até que, para um texto introdutório, fui até complexo demais. Isto encerra a série de artigos sobre a evolução das redes (e serviços) de telecom. Espero que tenham gostado da viagem, e até breve.
Auf wiedersehen...
Nenhum comentário:
Postar um comentário