BLOCO
Blog dos Coordenadores ou Blog Comunitário
da ComUnidade WirelessBrasil

Julho 2008               Índice Geral do BLOCO

O conteúdo do BLOCO tem forte vinculação com os debates nos Grupos de Discussão  Celld-group e WirelessBR. Participe!


14/07/08

• NGN e Internet (1) - Mensagem de José Smolka

----- Original Message -----
From: J.R.Smolka
To: WirelessBR
Sent: Monday, July 14, 2008 2:50 AM
Subject: [wireless.br] NGN e Internet

Colegas do grupo,

Já tem algum tempo que eu prometo este post. E não queria terminar minhas férias sem cumprir a promessa.
Meu tema de hoje tem a ver com a evolução das redes de telecomunicações para o modelo NGN (essencial para a prestação de serviços convergentes triple - ou quadruple-play), e se e como esta evolução é compatível com a preponderância que a Internet já tem na realidade quotidiana dos usuários - atuais e futuros - de acessos de banda (cada vez mais) larga, fixa e móvel.

A gente não para de ver na blogosphere e na imprensa especializada (e na não especializada também :-)) loas sendo tecidas ao nirvana que será o ambiente de telecomunicações convergido, e que as redes NGN serão a base para que tudo isto aconteça (para quem não tem familiaridade com o conceito de NGN, sugiro uma olhada neste post recente).
Só que estes bonitos papos tecnológicos escondem um fato incômodo: o que está em jogo, na verdade, é a própria sobrevivência do modelo de negócio que sustentou as operadoras de telecom até aqui.

Pare e pense. O que, exatamente, é o serviço que as operadoras de telecom vendem aos seus assinantes?
Nas redes POTS (plain old telephony service) é o aluguel temporário de um canal de comunicação entre o seu terminal (aparelho telefônico) e o terminal de destino da chamada.
O canal (de capacidade fixa) é inteiramente seu, e do seu interlocutor, por toda a duração da chamada (é por isso que a tarifação é feita por tempo). Você informa à rede (pelo teclado do seu terminal) o número do terminal de destino, e a rede intermedia (via seus protocolos de sinalização) todo o processo do estabelecimento do circuito de voz.
Você até pode usar este canal para a transmissão de "outros sinais" (na terminologia regulatória brasileira), caso você disponha de um equipamento (um modem, por exemplo) que formate o sinal a transmitir dentro da faixa dinâmica permitida pelo canal de acesso (8 Khz para acessos analógicos de par metálico).
O ponto básico é: sem a intermediação ativa da rede para o call-setup, call-control (inclusive bilhetagem do tempo de utilização) e call-teardown, não há maneira do usuário cursar chamadas telefônicas na rede.

E esta visão de mundo, este weltanschauung, entrou no DNA das operadoras de tal forma que elas não concebem uma rede de prestação de serviços sem esta intermediação ativa.
Ajuda ainda o fato (especialmente nas operadoras fixas) que o assinante, ao conectar o seu terminal à rede de uma operadora, está "ancorado" nela de forma incontornável.
Estes dois poderes das operadoras sobre os assinantes são vistos como normais. Alguém estranhou o modo como o pessoal da Abrafix reagiu quando o assunto unbundling entrou na mesa de discussão (mesmo que tenha sido apenas como "balão de ensaio")? Eu não.
Tire das operadoras qualquer um destes poderes sobre o assinante (ou os dois), e todo o modelo de negócio clássico de telecom vem abaixo. Portanto é natural que elas esperneiem o quanto puderem contra o unbundling.
Mas a maior ameaça presente é contra a intermediação obrigatória, e vem da Internet.

No modelo operacional da Internet o que o pessoal de telefonia chama de serviço é apenas uma rede. o termo serviço, no jargão informatiquês típico da Internet, atende pelo nome aplicação, e paira acima da rede.
E todas as aplicações da Internet aderem a dois princípios básicos:
(a) o end-to-end principle, que significa que todos os parâmetros de definição da sessão entre as partes que se comunicam são negociados diretamente entre elas, sem intermediação da rede, que é apenas a responsável por levar e trazer os bits da melhor forma possível; e
(b) os elementos de software que compõem a aplicação relacionam-se segundo o paradigma client-server (ou peer-to-peer, mas este é apenas um caso particular, onde os papéis de client e server são exercidos indistintamente pelos componentes de software da aplicação).

Eu falei software, não foi? Hummm...
Sinal que os componentes que agregam valor ao negócio saíram da rede e vieram cá para cima, na forma de programas de computador.
 Vamos fazer um esforço de memória. quais foram os últimos rasgos de criatividade na esfera da telefonia fixa?
O que eles agrupam genericamente sob o título de Intelligent Network (IN), que basicamente suportam serviços de atendimento com (prefixos 0800) ou sem (prefixos 4000) tarifação reversa, e o redirecionamento de chamadas para plataformas de voice mail quando o número discado está ocupado ou não atende? Tô me contendo para não rolar de rir... LOL :-) .
Nas operadoras móveis a situação é melhor. Não maravilhosa, mas melhor. Talvez porque aqui exista competição de verdade. Mas, ainda assim, muita coisa ainda está ancorada em cima do SMS (short message service) e do WAP (wireless application protocol). É pouco.

Boa parte da culpa por esta falta de inovação é da complexidade do ambiente de telecom.
Interfaces difíceis, documentadas no estilo "escrito por computadores para ser lido por máquinas de calcular", implementações disparatadas entre fornecedores diferentes do mesmo produto, and so on.
No ambiente da Internet, por outro lado, é muito mais fácil de fomentar a inovação.
É uma verdadeira paráfrase do lema do Cinema Novo: "uma idéia na cabeça e uma câmara na mão".
Qualquer idéia nova pode ser posta em prática, literalmente, no quartinho dos fundos ou na garagem da sua casa, com um PC velho rodando Linux, software livre e alguns discos rígidos.
Se der certo, a idéia pode ser escalada com facilidade para ambientes com maior capacidade para atendimento à demanda de tráfego.
Se der muito certo você pode ganhar uma grana preta vendendo a sua empresinha start-up para algum dos pesos-pesados da Internet.
E se der errado, o que você perdeu? Tempo e algumas centenas de reais, mas sempre pode começar de novo.

Agora, conjugando esta efervescência natural da Internet com a facilidade de uso sem intermediação (um verdadeiro unbundling virtual), que papel resta aos provedores da rede?
Eu já respondi isto antes, mas vou repetir: dumb pipes ou, no máximo, idiot-savant pipes.
E isto é o fim da picada (pra dizer pouco) para as operadoras. Elas cairiam na vala comum dos provedores de commodities, onde não há possibilidade de diferenciação ou agregação de valor, e a única maneira de garantir margens de lucro é através de uma brutal administração de custos operacionais.

Mas as telcos não ficaram paradas com um cartaz de kick me preso nas costas.
Elas foram à luta e pariram várias proposições para manter um papel de destaque na ordem das coisas.
 NGN é certamente a mais vistosa, mas o núcleo duro desta luta pela sobrevivência está em dois elementos muito comentados e pouco entendidos: o IMS (IP multimedia subsystem) e o SDP (service delivery platform).
Mas, antes de analisar o que estes elementos agregam ao cenário NGN, precisamos entender quais são as dificuldades para o provimento de serviços sofisticados (ex.: IPTV) via Internet, e qual a janela de oportunidade que esta situação cria.

Fala-se muito em QoS (quality of service) como um grande obstáculo para o provimento consistente de serviços real-time na Internet.
Pois eu tenho uma novidade pra lhes contar: não é!
O mecanismo de garantia de QoS em um ambiente TCP/IP grande e com administração federativa (como é a Internet) chama-se DiffServ (RFC 2475 e RFC 3260), e funciona muito bem, obrigado!
O "espantalho" do QoS costuma ser levantado periodicamente pelos fornecedores tradicionais de equipamentos de telecom, mas o real significado por trás dos alertas deles é: "eu ainda não sei como lidar direito com isto".
A verdade é que, se a transição para NGN andar rápido demais, estas empresas irão passar pelo mesmo processo de "desmanche e recriação" que a IBM teve de passar na década de 90 do século passado.
Então elas tentam de toda forma modular o andamento da introdução destas tecnologias na rede, até que elas se sintam em condição de competir com novos entrantes. E o "espantalho" só surte efeito porque a maioria da operadora não tem um "plano de batalha" próprio.
Os planejadores das redes das operadoras, em sua maioria, apenas consultam seus fornecedores tradicionais para ver qual é o roadmap deles, e depois colocam estas features no seu próprio roteiro de planejamento estratégico.
Eu acho isto uma burrice, que beira a irresponsabilidade. Minha visão de planejamento é: eu, operadora X, pretendo evoluir minha rede desta forma e neste prazo. O Sr, fornecedor X, se puder me ajudar nisto com os seus produtos, seja bem-vindo ao barco.
Caso contrário, saia da frente e dê lugar a quem possa fornecer o que eu preciso.
Até agora a única grande operadora que eu vi fazer isto de forma consistente foi a British Telecom, com o seu projeto 21CN.

Então, onde estão as verdadeiras dificuldades?
Na introdução de mecanismos de autenticação forte e criptografia para gestão da user privacy e para prevenir user identity spoofing, na introdução de mecanismos eficazes (sem ser excessivamente pesados) para gestão de IPR (intellectual property rights), e na gestão do call-control e billing para garantir seamless roaming entre ambientes fixos e móveis (qualquer que seja a tecnologia de acesso utilizada).
Nos dois primeiros as telcos não levam muita vantagem sobre o pessoal da Internet, mas no último a expertise delas é muito maior. E é principalmente aqui que se ancora o IMS.

Essencialmente o IMS é um hiper-mediador de sessões entre as partes client e server de uma aplicação, fazendo o que se chama de session border control.
Descrições gerais da arquitetura IMS podem ser vistas aqui e aqui.
Só que, ao contrário de um equipamento telecom tradicional, o IMS não vai ser apenas uma coleção de placas montadas em um bastidor-padrão de 19", e que funciona em regime de "caixa preta". Ele vai ser uma coleção de computadores (tá bom... eles até podem ser blades montados em racks padrão), geograficamente distribuída, com Sistemas Operacionais e Bancos de Dados off-the shelf, e as aplicações que compõem a arquitetura usam toda uma "sopa de letrinhas" que não faz parte da terminologia típica de telecom.
Na verdade, coisas como OSA (open service architecture), Parlay X, Web Services e (tchan tchan tchan tchan!) SOA (service-oriented architecture) estão muito mais no reino do pessoal de TI, e isto causa uma desorientação brutal nos bellheads (veja explicação do termo aqui ).
Nada instransponível, é claro (embora ensinar truque novo a cachorro velho seja uma empreitada difícil :-) ).
Mas enquanto os prováveis fornecedores (tradicionais ou não) de soluções IMS para as operadoras ficam demonstrando o quanto suas aplicações são buzzword-compliant, o tempo vai passando...

E o passar do tempo é crítico. Porque se o IMS for usado apenas para as funções de controle do seamless roaming da sessões dos assinantes então estamos no reino dos idiot-savant pipes (sem IMS é dumb pipes mesmo).
Enquanto o tempo passa, o pessoal da Internet ganha mind share dos usuários.
Se demorar demais, quando as telcos vierem com seu lindo IMS completinho, os usuários não estarão interessados, porque já se acostumaram com o serviço prestado ao modo Internet-like.
Se você prestar bem atenção, dá pra ouvir o Google, a Microsoft, a Apple, a Oracle (e outras menos votadas) cantando baixinho, em coro, Time Is On My Side :-) .

O verdadeiro pulo-do-gato do IMS é permitir que as telcos ofereçam esta plataforma como um front-end para aplicações desenvolvidas por terceiros, desafogando os desenvolvedores destas aplicações de ter que incluir nelas toda a parafernália de autenticação, segurança e billing - porque isto pode ser terceirizado com as telcos através do IMS.
Ou seja, o que ser quer é criar um "ecossistema" de suporte a aplicações que possa competir com o pessoal da Internet em pé de igualdade (e até suplantá-los, quem sabe?).
O problema é que o IMS cuida basicamente do dia-a-dia operacional do uso destas aplicações. Ele não diz nada com relação a como estas third-party applications vão conectar-se à rede da operadora.
Precisamos de um conjunto coerente de interfaces publicadas, de tal forma que qualquer desenvolvedor que queira plugar a sua aplicação no IMS possa fazê-lo sem maior dificuldade. Ou seja: precisamos de APIs (application programming interfaces) abertas para interoperar com a rede de telecomunicações.

Aqui entra o SDP.
A idéia do SDP envolve duas frentes: as APIs e os SDKs (software development kits) para a interoperação das aplicações de terceiros com a rede, e a visão de todos estes recursos (próprios e de terceiros) como serviços SOA.
Um serviço SOA não tem nada a ver com o conceito tradicional de serviço em telecom (ou em quase nenhuma outra área).
Este é um conceito derivado e expandido das técnicas de desenvolvimento de aplicações OOP (object-oriented programming).
No contexto OOP, um objeto é uma entidade lógica que encapsula todos os procedimentos (algoritmos) e dados necessários para a execução de uma função específica dentro de um programa.
De certa forma, um objeto pode ser entendido como uma sub-rotina com esteróides.
Pois bem, imagine agora que você crie uma entidade lógica que encapsula todo um processo de negócio da organização.
Conseguiu? Beleza! Isto é um serviço SOA (um objeto com esteróides).

Uma vez que todas as suas funções básicas de negócio (providas pela sua própria rede ou providas por aplicações de terceiros) estejam mapeadas na forma de um conjunto coerente de serviços SOA, definir um novo serviço (no sentido tradicional da palavra) pode ser feito em modo lego-like, alinhavando serviços SOA na seqüência necessária (muito parecido com as aplicações de business process modeling).
E este novo serviço pode depois ser descrito como um novo serviço SOA, que pode ser reaproveitado na montagem de novos serviços, und so weiter... Esta á a camada de service creation do SDP.

Mas o realmente complicado é que, uma vez definido o portfolio de serviços suportados (na forma de coleções de serviços SOA interligados), toda esta tranqueira tem de ser comunicada ao lado operacional da rede (controlado pelo IMS) para que recursos de rede possam ser provisionados (embora, provavelmente, muito mais de forma estatística que determinística) e os usuários possam utilizá-los.
Esta é a camada de service orchestration do SDP e, no meu entender, é a de maior complexidade de execução, porque tem de lidar não só com a rede NGN. Tem que interoperar com a rede legacy também. Isto envolve um reshape geral de toda a estrutura de OSS (operations support systems) e BSS (business support systems) da operadora.
Quem acha que dá para implementar o service orchestration somente "jogando um cobertor" de software por cima da estrutura atual, definindo uma meia dúzia de APIs, está em rota de colisão com a realidade.

Se tudo isto funcionar como se espera, as operadoras de telecom podem cooptar uma boa fatia do tráfego das aplicações mais "saborosas" da Internet, e perpetuar seu modo de vida por muito tempo. Só que, para isto, além do problema do time-to-market, elas tem de mudar de foco.
Hoje as telcos são essencialmente empresas hardware-centric, e tem de tornar-se software-centric em ritmo acelerado.
E esta idéia não é original minha. Recomendo enfaticamente a leitura deste artigo, de 1° de maio deste ano.

Além do mais, repisando um tema que eu também já falei em outros posts, a transformação da forma de prestar serviços de telecom vai causar transformações em outras indústrias também, especialmente a indústria da publicidade.
Em um ambiente onde os serviços podem ser prestados de forma hiper-customizada, e o assinante é parte ativa na definição de como, quando e onde ele quer receber estes serviços, é ilusão achar que os modelos atuais de publicidade estática, inserida compulsoriamente junto com o conteúdo, vão sobreviver.
A publicidade vai ter que se adaptar para atender às exigências de um consumidor muito mais sofisticado e volátil.
Nesta situação, a capacidade de fazer data mining das informações de CRM (customer relationship management), para identificar tendências e preferências de indivíduos ou grupos, vai valer o seu peso em ouro.
E adivinhem quem estará de posse da melhor fonte para montar as bases de dados de CRM?
As telcos, que mediam tudo (ou, pelo menos, os serviços mais fashion) via IMS.

Também existe um lado meio sinistro neste cenário de cooptação significativa dos serviços na Internet pelas operadoras de telecom.
Dado o histórico de comportamento passado delas, em me preocuparia muito em ter órgãos reguladores que efetivamente controlassem o mercado em favor do consumidor de serviços, em vez de ficar cultivando bedfellowships com as operadoras.

Por outro lado, se as telcos perderem o bonde da história (meu palpite é que a janela de oportunidade delas dure mais uns cinco anos), elas entrarão em lento declínio (que pode levar até uns vinte anos para se completar) na direção de tornarem-se apenas provedores de transporte de bits.
Mas, também, quem disse que neste cenário não podem aparecer outros players com intenções sinistras?
Novamente a bola volta para o campo de um sistema de regulação que consiga adaptar-se às exigências do momento. O tempo dirá. Tempo é o fator chave.
E, para finalizar, já que eu tenho que voltar ao batente amanhã (ops... hoje) de manhã e já estou meio kaput de sono, uma citação anônima...

Every morning in Africa a gazelle wakes up. It knows that it must run faster than the fastest lion, or it will be killed.
Every morning in Africa a lion wakes up. It knows that it must run faster than the slowest gazelle, or it will starve to death.
So, when the sun goes up, it doesn't matter if you're a lion or a gazelle. You'd better run like hell!

[ ]´s
J. R. Smolka

[Procure "posts" antigos e novos sobre este tema no Índice Geral do BLOCO]

ComUnidade WirelessBrasil                     Índice Geral do BLOCO