José Ribamar Smolka Ramos
Telecomunicações
Artigos e Mensagens
ComUnidade
WirelessBrasil
Julho 2010 Índice Geral
12/06/10
• Artigo de José Smolka no e-Thesis: "Meditações..."
Fonte: e-Thesis
Meditações...
Eu detesto dizer 'eu avisei' - Artigos
por Jose Smolka
12-Jul-2010
Aprove ImagemO susto que as operadoras celulares tomaram com o tráfego de dados
em suas redes 3G (HSDPA ou HSPA) produziu muitas reações. Nem todas boas. A
melhor, em minha opinião, foi acordarem para a necessidade de modernizar seus
backhauls, ainda excessivamente montados sobre rádios PDH ou, no máximo, SDH (a
maioria STM-1 ou STM-4 sobre enlaces rádio, e poucos STM-16 ou STM-32 sobre
fibra ótica). Finalmente o movimento para capilarização de redes DWDM na longa
distância e Metro Ethernet no espaço urbano ganhou corpo, e deve tornar-se o
modelo preferencial para expansão e modernização do backhaul a partir de agora.
A parte ruim fica por conta das declarações que não dá mais para sustentar
planos de serviço com tarifa flat, ao estilo all you can eat, semelhante ao
praticado nos acessos xDSL das redes fixas. A palavra de ordem, agora é tiered
pricing. Cobrança diferenciada por serviços supostamente também diferenciados.
Vejo nisto dois problemas: o primeiro, e mais evidente, é que ninguém ainda me
disse como vai conseguir explicar aos assinantes que assim vai ficar melhor do
que era antes (até porque, muito provavelmente, não vai); o segundo é mais
sutil...
Todos os esquemas de tiered pricing que tenho visto dependem de alguma
implementação - mesmo que parcial - de uma plataforma PCRF (policy charging and
rules function) para garantir que o QoS esperado para cada classe de aplicação
seja respeitado ao longo da rede. Só isso já é suficiente para entender porque
as operadoras móveis celulares tem sido tão vocais, lá fora e aqui no Brasil,
contra o conceito de net neutrality. Mas vamos tentar entender como este
elemento poderia exercer real influência sobre o QoS.
Primeiro vamos ver os trechos que os dados dos assinantes precisam percorrer.
Entre o UE (user equipment) e o node-B há a interface rádio propriamente dita.
Aqui valem as definições do 3GPP, e não vou me alongar nisto (até porque já
existem guerras religiosas suficientes com relação à interface rádio). Entre o
node-B e a RNC (radio network controller) e entre a RNC e o GGSN (GPRS gateway
service node - que eu saiba ainda chamam assim) está a rede de transporte (backhaul
+ backbone) da operadora, que normalmente é uma rede IP/MPLS integrada com as
infraestruturas de transmissão subjacentes, tanto as antigas (PDH e SDH) quando
as novas (DWDM e Metro Ethernet).
Embora as definições do 3GPP quanto a QoS (quatro classes de serviço:
conversational, streaming, interactive e background) e, especialmente,
multicasting (MBMS - multimedia broadcast multicasting service) sejam de
entendimento direto quanto ao seu suporte na interface aérea, nos trajetos node-B/RNC
e RNC/GGSN existem várias complicações na convivência com as novas tecnologias
de transporte, essencialmente baseadas em IP.
Os pacotes IP das aplicações dos usuários (e-mail, web, P2P, ou o que mais seja)
normalmente trafegam "tunelados" entre os elementos do assim chamado core PS (packet
switching). Encapsulados nos pacotes IP destes túneis, cujos cabeçalhos e demais
headers de transporte e aplicação efetivamente escondem a real natureza do
tráfego do usuário da vista dos elementos comuns da rede de transporte
(roteadores e switches IP/MPLS). Então não há como, em princípio, fazer com que
os elementos da rede de transporte apliquem o PHB (per-hop behavior) adequado à
natureza do tráfego transportado em cada pacote dos túneis, já que a rede de
transporte, em geral, usa a técnica DiffServ para garantia de QoS, e implementa
suporte a multicasting via PIM (protocol-independent multicasting) nas suas
versões DM (dense mode) ou SM (sparse mode).
A saída para compatibilizar estes dois mundos é relativamente simples, embora eu
não tenha visto, ainda, nenhum fabricante dos elementos do core PS dizer que a
suporta ou suportará. Basta que cada cabeçalho IP dos túneis node-B/RNC e RNC/GGSN
externe, nos seus DiffServ bits, o DSCP (DiffServ code point) apropriado para o
tipo de tráfego transportado, e que os elementos do core PS interajam com a rede
de transporte para o estabelecimento e "poda" das árvores de roteamento do
tráfego multicast via PM-DM e/ou PIM-SM. E, para isto ocorrer de forma
concertada, o repositório da informação sobre a forma correta de marcar os
pacotes dos túneis deve ser o PCRF, que pode comunicar estes dados aos elementos
do core PS com uma aplicação DIAMETER.
Mas, como diriam os comerciais dos produtos das Organizações Tabajara, náo é só
somente isso! Se você ainda não tem um PCRF, mas quer fazer shaping do seu
tráfego mesmo assim, você certamente irá usar uma plataforma de DPI (deep packet
inspection) para passar um pente fino nos pacotes e decidir se eles devem ou não
seguir adiante. Além disto soluções de content caching e content adaptation
também exigem que os pacotes passem através delas de forma serial com o DPI. A
impressão inicial é que isto poderia ser uma grande fonte de latência, por isso
alguns "iluminados" começaram a especular sobre a possibilidade de introduzir no
DPI, ou no GGSN, uma função de policy-based routing que, a depender da natureza
dos pacotes, encaminhe-os através somente daquelas plataformas que forem
necessárias. Complicado...
Vamos, por um momento, esquecer a existência da Lei de Moore (que,
aparentemente, também aplica-se à disponibilidade de banda), e sua consequência
natural que o custo e a latência incorridas em fazer o seu tráfego passar
serialmente por diversas etapas de análise devem ser decrescentes ao longo do
tempo. Qual deverá ser a latência que este elemento de policy-based routing
introduzirá? Em minha opinião ela sempre será maior que deixar o tráfego seguir
de forma serial pelas outras plataformas. Ademais, todos estes elementos que
queremos decidir se serão ou não cursados pelo tráfego estão upstream em relação
ao GGSN, o que significa que qualquer ganho que eles possam introduzir só será
refletido para as conexões de peering IP da operadora. Do GGSN para trás (e isto
pode representar uma distância nada desprezível) isto não traz nenhum alívio no
volume de tráfego a cursar.
Mas, talvez, todo este oba-oba sobre a necessidade de fazer shaping do tráfego
de determinadas aplicações (leia-se P2P) para garantir o QoS de outras (leia-se
vídeo) esteja mirando o alvo errado. Considere os diversos tipos de UEs
existentes e como, provavelmente, eles evoluirão. Os notebooks, netbooks e
(provavelmente) tablets, com modems externos ou internos, representam uma classe
de usuários que tende a ser mais nômade do que propriamente móvel. Eles
normalmente estabelecem uma conexão em um lugar e não se deslocam muito durante
a sessão. Alguns handovers e algumas entradas e saídas do estado de dormência da
conexão é o que se pode esperar deste tipo de UE. Já os smartphones são outra
conversa. Além da mobilidade maior, normalmente eles tem um perfil de execução
frequente de pequenas transações. E as políticas de conservação das baterias
também forçam a barra para ciclos de dormência/reativação do contexto PDP com
uma frequência maior.
O resultado disto tudo é que os smartphones, além do tráfego gerado, são uma
sobrecarga de sinalização. E não vi ainda nenhum estudo que mostre a
participação relativa destes dois componentes do tráfego. Talvez a política mais
interessante para o shaping do tráfego via DPI seja estratificando pelo tipo de
UE, e não pelo tipo de aplicação utilizada.