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

Setembro 2010               Í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!


24/09/10

• Como será o futuro da internet? (Texto de José Smolka no website de Ethevaldo Siqueira)

Olá, ComUnidade WirelessBRASIL!

Na visita ao website de Ethevaldo Siqueira anotei dois textos do nosso José Smolka na Seção Opinião:

Fonte: Blog do Ethevaldo Siqueira
[17/09/10]   Como será o futuro da internet? - por J. R. Smolka (transcrito mais abaixo)
O engenheiro J. R. Smolka questiona: se o futuro é um mundo totalmente IP, por que a migração das redes e serviços de telecom anda tão devagar?

Fonte: Blog do Ethevaldo Siqueira
[15/09/10]  Dá para exigir SLA de 50%? - por J. R. Smolka  (transcrito no "post" de ontem com comentário de Bruno Cabral))
O engenheiro J. R. Smolka analisa três aspectos cruciais nesta questão: a viabilidade econômica, a responsabilidade do provedor por fatos fora de seu alcance e a quantidade de usuários.

Ao debate!

Boa leitura!
Um abraço cordial
Helio Rosa

------------------

Como será o futuro da internet? (Texto de José Smolka no website de Ethevaldo Siqueira)

Fonte: Website do Ethevaldo Siqueira
[17/09/10]   Como será o futuro da internet? - por J. R. Smolka*

No dia 10/07/2010 a Jana de Paula publicou este post no Blotheco, que deixa no ar a pergunta: se todo mundo concorda com as possibilidades de negócios num mundo all-IP, particularmente no IPv6, então por que a migração de redes e serviços de telecom anda tão devagar? No dia 05/07/2010 este post no blog do Ethevaldo Siqueira comenta a guerra religiosa entre as principais tecnologias de acesso wireless candidatas a satisfazer, em algum momento do futuro (hoje ainda não são; um bom artigo sobre isto saiu no Fierce Wireless), as especificações IMT-advanced da ITU ou, popularmente, 4G: WiMax vs. LTE. Com todo respeito à opinião da fonte da Jana e à experiência do Ethevaldo, eu acho que ambos tocaram em eventos que, embora importantes, são apenas aspectos diversos de um problema muito maior. Em minha opinião (sujeita a discordâncias, claro) para entender o que acontece, e o que pode acontecer caso tudo continue no ritmo que está, precisamos começar com um pouco de perspectiva histórica e background técnico.

Como vamos atravessar uma área de turbulência, por favor mantenham os seus cintos de segurança afivelados e as mesinhas à sua frente fechadas e travadas, enquanto o sinal de atar cintos estiver aceso. Obrigado.

Quais são os problemas, afinal?

Digamos que a mãe de todas as guerras religiosas na área de telecom nasceu com o trabalho de Leonard Kleinrock, sintetizado no livro Communication Nets: Stochastic Message Flow and Delay, publicado em 1964, que prova a viabilidade do conceito de comutação de pacotes para a construção de grandes redes de comunicação, em alternativa à técnica de comutação de circuitos, que está no DNA da rede de telefonia tradicional. A partir daí começou uma disputa de posições entre os projetistas de redes de comunicação de dados, partidários naturais da tecnologia de comutação de pacotes, e os engenheiros da rede telefônica, herdeiros naturais da tradição da comutação de circuitos.

O interessante nesta disputa é que o ecossistema reunido em torno da rede telefônica (operadoras, fabricantes de equipamentos e órgãos de padronização) reconheceu, desde cedo, o potencial disruptivo que a comutação de pacotes representava para a preservação do valor da rede telefônica, e a primeira reação foi tentar incorporar e domesticar o conceito de comutação de pacotes dentro do processo evolutivo da rede telefônica, utilizando o conceito de ISDN (Integrated Services Digital Network), que evoluiria em seguida para a B-ISDN (Broadband ISDN). Todo este processo pode ser visto nas recomendações ITU-T da série X.

Esta foi a época em que se achava que a evolução natural das redes de telefonia seria em direção do ATM e do SDH (destes dois, o segundo é que conseguiu um lugar ao sol, e está por aí até hoje), mas a internet já tinha evoluído até o ponto em que era visível que o ATM, em particular, não teria um futuro tão brilhante assim. Este momento da história foi registrado com grande felicidade por Steve Steinberg no artigo Netheads vs Bellheads, publicado na edição de outubro de 1996 da revista Wired. Ainda hoje acho a leitura deste texto interessante e atual.

Mas, afinal, qual é o grande cisma que divide estas duas comunidades? Só a questão circuit switching vs. packet switching, embora séria, seria insuficiente para provocar tamanha animosidade e disputa técnica, comercial e política. Os verdadeiros pomos da discórdia são dois, e costumam ficar na sombra da briga pacotes vs. circuitos. O primeiro grande fator de discórdia é networking vs. internetworking; e o segundo, mas não menos importante, é o end-to-end principle. Um de cada vez...

Homogeneidade ou heterogeneidade?

Agora é a hora adequada para lembrarmos do modelo de referência OSI. Pesquisando por aí encontramos a sigla OSI (Open Systems Interconnection) traduzida como "interconexão de sistemas abertos". Na minha opinião a tradução correta deveria ser "interconexão aberta de sistemas", para explicitar que o objetivo do modelo é descrever um modo aberto de interconexão entre sistemas que não precisam, intrinsecamente, ser abertos (se você não tem familiaridade com os conceitos de "aberto" e "fechado" ou "proprietário", dê uma olhada aqui e aqui).

Em termos do modelo de referência OSI, uma conjunto de redes pode ser homogêneo (se todas elas usarem a mesma tecnologia na camada 2 - data link layer) ou heterogêneo (diversas tecnologias de camada 2). A razão da existência da camada 3 do modelo (network layer) é justamente servir de cola para harmonizar os diversos segmentos  (enlaces de longa distância, redes locais etc.) dentro de uma mesma rede de comunicação, mesmo que as tecnologias de camada 2 não sejam compatíveis entre si.

Muito bem. Então podemos definir o problema networking vs. internetworking da seguinte forma: a tradição da rede telefônica é a construção de redes homogêneas na camada 2. Ou seja, networking. A rede telefônica só conseguiu alcance e interoperabilidade mundial porque ela é uma rede homogênea. Enquanto isso, a internet, baseada desde o nascimento (em respeito aos puristas, desde janeiro de 1983) na pilha de protocolos TCP/IP, é intrinsecamente preparada para a heterogeneidade, para a interconexão de redes disparatadas, para o internetworking, enfim.

Neste momento vejo um braço levantado ali na terceira fila. Sim? Qual sua pergunta? Ahã... sim... entendi. Vou repetir para que todos consigam entender o que você perguntou: "Mas a rede telefônica já não abraçou o TCP/IP como sua nova arquitetura básica de construção de redes de serviços integrados?" A resposta é sim, ela adotou (a contragosto, diga-se) o TCP/IP, porém, as redes de telecomunicações foram encaminhando-se para um modelo operacional que ainda impõe homogeneidade na camada 2.

Vamos ver... Antigamente, as redes de telefonia fixa e de telefonia celular eram coisas distintas, sem quase nada a ver umas com a outras. Todavia, as pressões de mercado levaram as duas a um processo de fusão, ou, para satisfazer os desejos de buzzword compliance, à convergência. E a rede fixa-móvel convergida quadruple-play (capaz de trafegar voz, dados e video, tudo isto com mobilidade) transforma a rede fixa, essencialmente, num apêndice da rede móvel.

Explico: basicamente o usuário é visto como podendo estar numa de duas situações: dentro da sua bolha de cobertura doméstica ou transitando pelas bolhas de cobertura pública (substitua "doméstica" por "empresarial" e tudo isto também vale para os contratos corporativos). Idealmente, a bolha de cobertura doméstica será provida por uma femtocell da mesma tecnologia utilizada na cobertura pública, mas ainda existe algum espaço de manobra aqui para outras tecnologias (WiFi, por exemplo).

O papel da rede de acesso fixa (DSL, PON, HFC, DOCSIS ou o que seja) será apenas para servir de backhaul da cobertura doméstica. O ponto fundamental é que, assim como ocorre entre as células da cobertura pública, também deve ser provido seamless handover entre a cobertura doméstica e a cobertura pública. Hoje em dia, a tecnologia que implementa isto na arquitetura de telecom (definida pelo 3GPP - 3rd Generation Partnership Project) exige homogeneidade na camada 2. E a adoção do IPv6, como pretendo mostrar, não trará muita melhora a este quadro.

O advento do conceito de mobilidade causou problemas para os usuários da arquitetura TCP/IP. A forma mais simples de mobilidade é a nomadicidade, na qual o usuário ora se encontra conectado em uma rede, ora em outra, mas se desconecta completamente durante o período de transição. Exemplo típico desta situação: você está usando o seu notebook na conexão WiFi do seu hotel enquanto espera o táxi para o aeroporto; seu táxi chega e você desliga o notebook, e volta a ligá-lo na conexão WiFi do aeroporto. A solução padrão de configuração dinâmica via DHCP funciona perfeitamente para estes casos.

Entretanto, a mobilidade plena é outra conversa, porque exige que as suas sessões de aplicação (consultas a páginas web, envio e recepção de e-mail, streaming de áudio e/ou vídeo etc.) persistam, mesmo se a sua localização física mudar. E o mecanismo de sessões de aplicação na arquitetura TCP/IP tradicional, apoiado no modelo de sockets, não admite que o endereço IP do usuário mude durante a sessão.

A IETF (Internet Engineering Task Force) propôs resolver isso na Internet IPv4 por meio do mecanismo de mobile IP, especificado na RFC 3344 e na RFC 4721. Um host IPv4 visitante que implementa mobile IP age da seguinte forma: usando mensagens ICMP (para os puristas e detalhistas: extensões das mensagens de router discovery do ICMP), ele descobre quem exerce o papel de foreign agent na rede visitada, obtém dele um enderço IPv4 válido na rede visitada (chamado de CoA - care-of address), e informa a ele o endereço IPv4 do seu home agent; o foreign agent se comunica com o home agent do host visitante e informa a ele que este se encontra na sua área de administração; o home agent comunica ao foreign agent o home address IPv4 do host visitante e estabelece um túnel IP entre os dois; e, finalmente, o foreign agent estabelece um túnel IP com o host visitante, e este se configura com o seu home address.

A partir daí todo o tráfego de aplicação originado ou destinado ao host visitante é transportado em pacotes IPv4 que usam o home address como sua identificação. Estes pacotes trafegam entre o host visitante e o foreign agent encapsulados em pacotes IPv4 que usam o CoA e o endereço IPv4 do foreign agent, e entre o foreign agent e o home agent encapsulados em pacotes IPv4 que usam os endereços IPv4, respectivamente do foreign agent e do home agent. O home agent do host visitante age como o seu proxy server, enviando e recebendo os pacotes IPv4 endereçados com o home address atribuído a este (que pode, em tese, mas não obrigatoriamente, ser diferente para cada nova sessão mobile IP aberta pelo mesmo host visitante).

Eu acho que, como o IPv4 já estava marcado para morrer, não era razoável que a IETF fizesse nada muito diferente na questão da mobilidade. Porém para o IPv6 eles poderiam (e deveriam) fazer melhor. Acho, inclusive, que caberia ao IESG (Internet Engineering Steering Group) ter dado um "puxão de orelhas" nos working groups sobre mobilidade IPv6, avisando que eles estavam desviando-se da, digamos, "pureza doutrinária" do TCP/IP.

Entretanto, a especificação do mobile IPv6 que está publicada na RFC 3775 parece apenas uma versão requentada do mobile IPv4. Mais ou menos assim como pegar um fusca e turbinar o motor, colocar aerofólio, spoilers etc. e tal. Vai ficar tecnologicamente atualizado e bacana, porém, a essência ainda é de fusca. As principais diferenças do mobile IPv6 em relação ao mobile IPv4 são: o papel do foreign agent resume-se a atribuir o CoA ao host visitante e comunicar este fato ao home agent deste; e a comunicação entre o host visitante e o seu home agent é feita diretamente entre eles, sem a intermediação do foreign agent.

Se alguém estiver tendo sensações de dejà vu com estas descrições do mobile IPv4 e mobile IPv6 provavelmente é porque já viu, realmente, algo parecido: o GPRS (General Packet Radio Service), cuja especificação é feita pelo 3GPP. Troque foreign agent por SGSN (serving GPRS support node) e home agent por GGSN (gateway GPRS support node) nas descrições acima e fica tudo certo, com a exceção que o GPRS inclui a definição do seu próprio protocolo de encapsulamento, o GTP (GPRS tunneling protocol).

Vou fazer uma pequena pausa na minha linha de argumentação, apenas para explicar porque a migração IPv4-IPv6 não ocorreu na velocidade esperada, e só está ganhando ímpeto agora, quando o esgotamento do address space IPv4 já esta à vista.

Quando foi feita a migração do NCP para o TCP/IP entre janeiro de 1982 e janeiro de 1983 (ver RFC 801), a internet era bem menor, e com muito menos tráfego e diversidade de serviços. A única estratégia válida para migrar do IPv4 para o IPv6 é o dual stack. Isto significa que, durante o período de migração (que pode levar vários anos para se completar) os hosts têm de conviver com duas pilhas de protocolos simultâneas, para permitir conexão tanto com serviços já migrados para o IPv6 quanto com serviços que ainda usam apenas o IPv4.

Outra grande diferença entre aquela migração e esta é que a internet era, naquela época, principalmente um empreendimento da comunidade acadêmica, e hoje é quase totalmente um empreendimento comercial. Isto significa que, como todos os outros empreendimentos comerciais, os provedores de serviços estão sempre de olho nos seus custos operacionais. E fazer a migração dual stack representa custo.

Vou usar como exemplo as próprias operadoras celulares e seus packet cores GPRS, EDGE ou HSPA. Se o UE (user equipment), que pode ser um smartphone, um tablet, um netbook etc., tiver de funcionar em modo dual stack, ele terá de manter dois contextos PDP (packet data protocol) simultâneos, um para a conexão IPv4 e outro para a conexão IPv6. E isto tem consequências para a sinalização na interface aérea e para o dimensionamento (e custo) dos SGSN e GGSN. Por isso é que a migração só está sendo feita quando, com perdão da expressão chula, a água fria começou a bater na bunda.

Mas chega de distrações. Por que, exatamente, eu falei que esta forma de prover mobilidade não é a que deveria ter sido perseguida no IPv6, e por que ela, sendo como é, prejudica os interesses dos usuários? Existe o argumento trivial da ineficiência do encaminhamento do tráfego do host visitante sempre até o home agent, daí até o serviço realmente desejado pelo usuário e de volta pelo mesmo caminho. O impacto disto depende muito da amplitude média dos deslocamentos que os usuários fazem. Se apenas uma pequena fração dos usuários se mover para localidades realmente longe dos seus home agents, então o impacto econômico deste argumento é desprezível. O problema real que eu vejo é mais profundo, e tem dois aspectos.

Primeiro, neste modo de prover mobilidade, está implícita a ideia (que fica ainda mais forte por causa da abundância do address space IPv6) que o endereço IP é uma espécie de identificação unívoca do usuário. Este é um conceito transplantado da rede telefônica, e mesmo lá já estava sendo usado de forma errada.

Como a rede telefônica é homogênea e provê apenas um serviço (comutação de circuitos temporários de voz), parecia natural que o número do terminal identificasse o próprio usuário. Afinal de contas, ter múltiplos telefones era coisa para empresas ou pessoas muito ricas. Pessoas comuns tinham uma única linha, e o número da linha ficava associado inerentemente à pessoa. Mas isto é uma distorção que só ficou visível recentemente, quando alguém teve a brilhante ideia de garantir a portabilidade dos números de telefone quando o usuário mudar de operadora. Para garantir a portabilidade numérica os processos de call setup e billing da rede telefônica tiveram de subir para novo patamar de complexidade (como se eles já não fossem complexos o suficiente).

Só que existe uma distinção filosófica importante entre os conceitos de endereço e nome. Endereço é algo que informa “onde você está”, e nome é algo que informa “quem você é”. Os números da rede telefônica sempre foram endereços, e não nomes. Mas isso só ficou evidente com o advento da telefonia móvel e da possibilidade de o usuário trocar de operadora (e, consequentemente, de endereço na rede).

Só que quiseram atribuir a um endereço características de nome, daí a portabilidade numérica tornar-se uma dor de cabeça em termos de sinalização. Na internet esta distinção ficou evidente desde cedo, e o problema foi evitado pelo uso de um serviço que informa o endereço IP associado ao nome (URI - universal resource identifier) de qualquer recurso: o DNS (domain naming system), cuja definição básica está na RFC 1035.

Seria relativamente fácil estender o DNS, ou mesmo criar um serviço análogo ao DNS, que servisse como diretório para localização do endereço IPv6 temporariamente associado ao nome de um usuário. Mas preferiram continuar usando o modelo de mobilidade usado no IPv4, e isto leva inerentemente à ideia de que o endereço IP é uma espécie de identificação pessoal do usuário, o que ele não é, nem vai ser. Se continuar assim, certamente teremos problemas mais à frente.

O segundo aspecto problemático desta abordagem para a mobilidade é que, muito embora as especificações do 3GPP para a evolução do UMTS (Universal Mobile Telecommunications System) digam que o evolved packet core poderá ser usado com outras redes de acesso além da evolved UTRAN (UMTS Terrestrial Radio Access Network), o máximo que eu consigo ver acontecendo neste sentido será a integração (isto quer dizer a garantia de seamless roaming) das tecnologias que vierem a ser expressivas para a bolha de cobertura doméstica, caso o modelo das femtocells não consiga atingir a maioria deste mercado.

Mas seamless roaming entre a rede de acesso convergida e outras eventuais redes de acesso disponíveis para o usuário? Duvido que façam. Mesmo com o WiMax, que é primo irmão do LTE (ambos usam a tecnologia OFDM - Orthogonal Frequency-Division Multiplexing), não creio que seja feito. Isto porque o desejo de preservação da rede como um valor intrínseco dos serviços de telecomunicações é muito importante para as operadoras, mas mais importante ainda para os fabricantes de equipamentos de telecom.

Mais adiante ainda falaremos mais deste processo de erosão de valor, por enquanto basta observar que esta abordagem comodista em relação à mobilidade leva a um esquema monocromático de acesso para os usuários, que só é interessante para as operadoras e para seus fornecedores de equipamentos.

Ufa! E tudo isto foi só para o problema networking vs. internetworking! Ainda temos o end-to-end principle.

Inteligência e valor

Quando a rede telefônica começou a ser construída, era virtualmente impossível, por razões tanto técnicas quanto econômicas, que os terminais dos assinantes possuíssem qualquer forma de inteligência, salvo o mínimo necessário para a sinalização de call setup.

Com o tempo firmou-se um paradigma que ninguém mais discutia: o terminal do assinante deve, sempre, ser o mais simples possível, e a complexidade deve ser absorvida e administrada pela própria rede, sem que o usuário fique exposto a ela. O corolário desta forma de pensar é a crença em que a rede é algo que tem um valor intrínseco e indissociável do serviço prestado. Tudo muito bom para ambientes homogêneos e monosserviços, mas as coisas começaram a mudar.

Em 1981 Jerome Saltzer, David Reed e David Clark publicaram o artigo End-to-End Arguments in System Design, no qual são apresentadas as justificativas para que a inteligência na rede seja implementada, sempre, o mais próximo possível das bordas. Idealmente no próprio host conectado. Este princípio foi incorporado na arquitetura da internet, primeiro na RFC 1958 e depois atualizado na RFC 3439. Neste novo paradigma a rede não tem nenhum valor per se, a não ser como transporte mais ou menos confiável para os pacotes de dados. A percepção de valor, neste caso, desloca-se totalmente do hardware da rede para o software nos computadores conectados.

Como qualquer iniciante no estudo do marketing pode confirmar, percepção de valor é tudo que interessa. Ela é que define quanto as pessoas (ou empresas) estão dispostas a pagar em troca de algum produto ou serviço. E não nos vamos iludir: a internet sempre foi (usando outro conceito caro aos marquetólogos) posicionada para ser o substituto, não o complemento, das redes de serviços de telecomunicações tradicionais.

A percepção da internet era de que, muito em breve, toda aquela arquitetura jurássica das redes de telecomunicações baseadas em hardware especializado, proprietário e caríssimo seria substituída por uma estrutura muito mais leve e flexível, baseada quase totalmente em software, e com arquitetura aberta. Parecia certo que a história da derrota da IBM pela Microsoft, da queda dos mainframes e da ascensão dos personal computers iria repetir-se, e muito em breve os grandes nomes da indústria de telecomunicações seriam empresas como a Cisco Systems e a Juniper. Isto, como sabemos, levou ao nascimento, expansão e subsequente estouro da bolha da internet.

Entretanto, mesmo no ambiente mais racional pós-bolha, o deslocamento da percepção de valor para o software nas pontas já era permanente, e restou para quem estava no meio – as operadoras e seus fornecedores tradicionais – um papel que não agrega quase nenhum valor: o de dumb bitpipe ou, vá lá, o de idiot-savant bitpipe. Mas quem disse que eles estavam dispostos a deixar-se arrastar? Coletivamente, a indústria de telecomunicações mostrou ter uma casca bem mais dura do que parecia à primeira vista.

Estamos agora completando praticamente 20 anos desde que a comunidade tradicional de telecom reconheceu e abraçou (pelo menos nominalmente) o conceito de uma global information infrastructure, que está descrita na série Y das recomendações da ITU-T. Mas, em termos práticos, a adoção do TCP/IP nos processos de negócio de telecom foi feita sempre com o máximo de reticência possível, sempre sob a cobertura do argumento de que não se podia arriscar levianamente a qualidade do serviço prestado ao assinante, blá.. blá... blá...

Na verdade, eles nunca tiveram a intenção de conformar-se com o papel de meros fornecedores da infraestrutura de comunicação. A ambição é bem maior. Eles querem ser os atores centrais do processo, sem os quais nem usuários nem provedores de serviços podem transacionar livremente. Em outras palavras, eles desejam ferrenhamente acabar com o end-to-end principle, e plantarem-se irrevogavelmente entre as duas pontas do processo de comunicação, cobrando pedágio de ambas as pontas pelo privilégio de poder fazer negócios através deles. Parece exagerado? Vamos ver...

O modelo operacional para os novos serviços de telecom, proposto pelo 3GPP, baseia-se na arquitetura IMS (IP Mobile Subsystem). Curioso... Embutido naquela barafunda de acrônimos esquisitos existem algumas coisas interessantes. Vejamos: UPSF (user profile server function), IMPI (IP multimedia private identity) e IMPU (IP multimedia public identity). O que vocês acham que estas coisas são?

Exatamente... São aquela famosa extensão do DNS, que eu citei anteriormente, e que a IETF esqueceu de detalhar na arquitetura da internet IPv6. Só que, para tirar proveito desta facilidade, os usuários e os serviços têm de entrar em conformidade com toda a arquitetura do IMS. E o que significa isto? Que toda e qualquer sessão entre um usuário e um serviço, para poder ser iniciada e mantida, precisa ser avaliada, autenticada e liberada pelo IMS. Portanto, não somente os assinantes dos serviços da rede terão obrigações com ela. Os provedores de serviços, caso desejem participar do esquema, terão de entrar em conformidade com as interfaces padronizadas do IMS. E isto seria o dobre de finados para o end-to-end principle.

Tudo isto vem embrulhado em uma linda embalagem de argumentos de marketing: como os provedores de serviços podem usufruir de uma API (application programming interface) que facilite o desenvolvimento de aplicações que incluam nativamente os recursos da rede; e como todos terão garantia de segurança e qualidade dos serviços. Lindo. Mas esta visão idílica ainda sofre para ser implementada na prática. Parece que, como naquele (talvez mítico) incidente entre Garrincha e Vicente Feola na Copa do Mundo de 1966, esqueceram de combinar com os russos...

Aparentemente, as operadoras de telecom imaginavam que, com o lançamento das suas redes 3G (HSDPA e HSPA), o tráfego de dados fosse crescer, mas com um perfil semelhante ao que elas vinham observando nas redes 2G (GPRS e EDGE). Enquanto isso, a Apple lançou o iPhone acoplado com a sua própria loja de venda de downloads, calçada no serviço iTunes, e o conceito de smartphone e a ideia das app stores decolaram de vez. Eu consigo visualizar o Steve Jobs imitando o Chapolim Colorado: "Eles não contavam com a minha astúcia!"

E não contavam mesmo. O impacto de tráfego de dados 3G representado pelo iPhone e, logo em seguida, por toda uma constelação de aparelhos com o mesmo conceito pegou as operadoras de calças curtas no mundo todo. Confrontadas com o tamanho do CapEx necessário para expandir o backhaul da rede de acesso 3G, as operadoras preferem dar uma no prego e outra na ferradura: estão apressando a ampliação e modernização da infraestrutura de transmissão (algo que vinha sendo negligenciado há algum tempo), mas, em paralelo, subiram de tom e começaram a cortar os planos comerciais que prometiam acesso de dados ilimitado (o que, aliás, sempre foi uma mentira). Tudo em nome da qualidade do serviço. Give me a break...

As app stores associadas às marcas dos fabricantes dos aparelhos representam outra espécie de ameaça, porque roubam das operadoras o valor da sua própria marca. A fidelidade dos usuários liga-se à marca dos fabricantes de aparelhos. O curioso é que, dentro da comunidade de telecom, há algum tempo está sendo arquitetada a mãe de todas as app stores: o SDP (Service Delivery Platform).

Concebido para ser o complemento natural do IMS, com o SDP as operadoras podem criar seus próprios ecossistemas de desenvolvimento rápido de aplicações e novos serviços. Entretanto, como o SDP está tendo uma decolagem lenta, as operadoras decidiram investir numa estratégia mais simples, mas potencialmente de resultados mais imediatos: criar a sua própria arquitetura de app store, que pode ser adaptada para garantir o branding de cada operadora que a utilizar na sua estrutura de negócio.

Esta proposta atende pelo nome de WAC (Wholesale Applications Community), mas, como seu lançamento ocorreu há pouco tempo (no Mobile World Congress 2010 em Barcelona), ainda não dá para dizer se dará certo ou não, embora a maioria dos pesos-pesados da área (AT&T, Verizon, Vodafone, Telefónica et caterva) esteja, pelo menos nominalmente, apoiando a proposta.

Isto mais ou menos representa o estado de coisas hoje. Chega de explicações e vamos às conclusões.

Rounding up

Falando em termos bem gerais, podemos ver que a disputa bellheads vs. netheads vai muito bem, obrigado, já com, pelo menos, 20 anos de idade, e com gás para durar ainda bastante tempo. Todavia, apesar dos sucessos visíveis recentes da comunidade nethead, capitaneada pela Apple, Google, Amazon e assemelhados, eu acho que a comunidade bellhead conseguiu algumas vantagens estratégicas que podem vir a fazer significativa diferença nos próximos anos.

A principal delas é o virtual monopólio da rede pública de acesso móvel (só um momento aqui, para evitar confusões desnecessárias: uso a palavra pública, neste contexto, com o significado de disponível no espaço público, não no sentido de pertencente ao povo ou ao governo). Mesmo que as redes de acesso privadas não venham a ficar tão homogêneas quanto a rede pública, a necessidade de interoperação e seamless roaming entre os dois espaços garantirá que as operadoras estarão em posição dominante neste jogo.

Com a adoção cada vez mais maciça ao IPv6 (em minha opinião este é um processo que se acelera em 2011 e estará quase completo lá por 2016) ficará indistinta a separação entre a internet em geral e a rede das operadoras.

A tentação lógica para elas é começar a fazer seus próprios acordos de peering IPv6, passando ao largo dos players tradicionais desta área, e incorporando nestes acordos cláusulas de garantia de QoS e de interoperabilidade do roteamento de tráfego multicast (essencial para a distribuição de serviços de streaming de vídeo e áudio). Se um cenário como este se confirmar, e as operadoras forem bem sucedidas em conter o avanço dos grandes prestadores de serviços na internet (principalmente o Google), então elas conseguiriam o seu maior sonho, que é transformar toda a internet em um walled garden sob sua administração.

A perseguição deste cenário é, em minha opinião, a principal razão pela qual as operadoras têm reclamado, em todos os locais e de todas as formas possíveis, contra o conceito de net neutrality. Elas podem ter sucesso nesta empreitada? Eu acho que têm mais de 50% de chances de conseguirem o que querem. Este cenário seria realmente vantajoso para os usuários? Eu creio que não, porque toda a competitividade do setor poderia ser modulada simplesmente pelo gosto (ou desgosto) das operadoras de telecom.

Cabe a nós, usuários, bem como aos órgãos de regulação entender estes fatos e expressar nossas opiniões, para que o espaço da internet possa continuar a ser plural e favorável ao desenvolvimento de novas ideias.


*José de Ribamar Smolka Ramos é engenheiro eletricista (UFBa 1982), com especialização em gestão da qualidade (CETEAD/UFBa 1994) e MBA executivo (FGV RJ/Grupo Telefônica 2001). Trabalha na área de informática desde 1980, tendo atuado em empresas das áreas financeira, industrial e de serviços, estando desde 1989 na área de telecomunicações. Área principal de interesse: projeto, implantação e gestão operacional da infra-estrutura e serviços de comunicação baseados na arquitetura TCP/IP.


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