Smolka et catervarii

Proliferação de padrões concorrentes

2011-11-21T00:30:00.001-02:00

Network capacity planning - exemplo de uso do algoritmo (parte 1)

2011-11-20T13:32:00.000-02:00

Conforme prometido, vou mostrar um exemplo de aplicação do algoritmo de planejamento de capacidade mostrado no artigo anterior sobre a seguinte rede hipotética:

Adicionalmente vou mostrar uma implementação do algoritmo na linguagem C. O vetor de nós de comutação tem a seguinte estrutura lógica:

Que tem a seguinte implementação (sintaxe C):

Para entrada de dados no vetor de nós de comutação vamos usar no exemplo um arquivo CSV, onde cada registro representa um elemento do vetor:

A matriz de topologia tem a seguinte estrutura lógica:

Com a seguinte descrição da estrutura de dados em C:

De forma análoga ao que fizemos para o vetor de nós de comutação, os dados de entrada para a matriz de topologia são dados no seguinte arquivo CSV (que percorre a matriz linha a linha):

A matriz de rotas tem a seguinte estrutura lógica::

E o código C para a sua estrutura de dados é:

No arquivo CSV para carga inicial percorremos os valores nesta matriz linha a linha. Observe que o valor armazenado nos elementos da matriz não é o valor de índice do vetor de nós de comutação, mas o valor numérico inteiro do Id do nó de comutação. Assim, um valor zero nesta matriz indica a inexistência de rota entre o par de nós considerado.

Na próxima parte deste artigo vamos ver a estrutura lógica, o código C e os arquivos CSV usados para definir a matriz de interesse de tráfego, e estaremos em condição de definir a implementação C do algoritmo e ver os resultados da sua execução sobre os dados de entrada que fornecemos.

Os indicadores de performance de rede no SGQ-SCM e SGQ-SMP (1)

2011-11-11T15:12:00.001-02:00

Li e reli os dois novos regulamentos sobre indicadores da qualidade do SCM e do SMP, e, sinceramente, achei a redação confusa e, às vezes, contraditória. Então decidi publicar alguns posts dedicados a tentar fazer uma apresentação inteligível dos indicadores de qualidade da rede do SCM e dos indicadores de conexões de dados do SMP (não vou tratar dos indicadores de reação do usuário - SCM e SMP, nem dos indicadores de atendimento - SCM e SMP, nem dos indicadores das conexões de voz - só SMP, e nem dos indicadores de pesquisa - SCM e SMP).

Sempre que possível vou emparelhar os indicadores que medem coisas semelhantes para o SCM e para o SMP. E vale observar logo: estes regulamentos só afetam operadores SCM ou SMP com mais de 50K assinantes (ou acessos em serviço, na terminologia dos regulamentos). Ou seja: praticamente só as operadoras de telefonia fixa e móvel entram neste critério. Os pequenos e médios operadores SCM (creio que esta categoria não exista no SMP) não são afetados por estes regulamentos.

Qualquer problema de análise de performance começa pela definição do 5W1H:

WHAT: o que vai ser medido?
WHY: porque vamos medir isso?
WHO: quem fará a medição?
WHERE: onde será feita a medição?
WHEN: quando será feita a medição?
HOW: como faremos esta medição?

Então vamos tentar organizar os indicadores de qualidade da rede para dar a melhor resposta possível a estas perguntas, com base no que está escrito nos regulamentos e com um pouco de bom senso.

Os dois regulamentos (art. 10 para o SCM e art. 24 para o SMP) prevêem que as operadoras tem que disponibilizar (para a Anatel e para os assinantes, no caso do SMP, e só para os assinantes no caso do SCM) software de medição do desempenho da rede, que deverá poder ser baixado por cada usuário interessado, e que deve ser capaz de medir os seguintes indicadores (e registrar - onde? - data/hora e local dos resultados obtidos, para possibilitar a formação de série histórica):

Taxa de transferência instantânea - indicadores SCM4 e SMP10. A taxa instantânea deve ser medida tanto no canal de download quanto no canal de upload;
Latência bidirecional (aquilo que comumente chamamos de round-trip time, medido com o programa ping) - indicador SCM6, mas sem indicador correspondente no SMP (aliás, não tem nem mesmo definição para o round-trip time no RGQ-SMP). O que levanta uma questão interessante: o software vai medir isso, mas a operadora não tem nenhuma meta estabelecida para este item de desempenho. Vai dar confusão.
Variação de latência (jitter) - indicador SCM7, e também sem indicador correspondente para o SMP. Valem as mesmas observações do caso da latência bidirecional.
Taxa de perda de pacotes (packet loss) - indicador SCM8, e também sem correspondente no SMP. Aqui temos os inconvenientes dos dois itens anteriores e mais um adicional: não é dada nenhuma definição, nem mesmo no regulamento do SCM, para este item o como calcular está completamente em aberto.

Outro fator de confusão ligado a este software de medição é que enquanto o regulamento do SCM especifica (no inciso I do art. 15) que a medição dos dados para o cálculo oficial dos indicadores deve ser feito com equipamento dedicado, na casa do assinante (na verdade de uma amostra estatisticamente significativa do conjunto dos assinantes - inciso II do art. 15 - com intervalo de confiança mínimo de 95% - por analogia com o item 4.3 do anexo III do regulamento do SCM). Já o SMP não fala nada sobre como fazer a medição, e ainda deixa aberta a possibilidade de ser usado o mesmo software que será disponibilizado para os assinantes. Muito mal definido.

Existe mais um indicador comum aos dois regulamentos: taxa de transferência média (SCM5 e SMP11). Novamente os regulamentos definem que as medidas devem ser feitas tanto no canal de download quanto no canal de upload.

E existem indicadores que são específicos para o SMP, e não tem correspondente no SCM. Talvez seja apenas a vontade de manter paralelismo com os indicadores do serviço de voz do SMP:

Taxa de completamento de conexões de dados (SMP8);
Taxa de queda das conexões de dados (SMP9);

Então podemos fazer uma tabela resumo sobre o que (what) temos que medir:

Vamos assumir que o porquê medir (why) seja auto-explicativo. E sabemos quem (who) vai medir. Será a tal da Entidade Aferidora da Qualidade, que é descrita nos artigos 33 a 37 do RGQ-SCM e nos artigos 26 a 30 do RGQ-SMP, mas com uma diferença: no SCM a Entidasde Aferidora é responsável pela coleta de dados e cálculo de todos os indicadores de rede (SCM4, SCM5, SCM6, SCM7 e SCM8), mas no SMP ela é responsável apenas pela coleta de dados e cálculo dos indicadores SMP10 e SMP11. Subentende-se, então, que a responsabilidade pela coleta de dados e cálculo dos indicadores SMP8 e SMP9 cabe às operadoras.

As questões de onde (where) e quando (when) medir também dão o que falar: tanto o SCM quanto o SMP pedem que os cálculos dos indicadores ocorra no PMT (período de maior tráfego - que é definido de forma invariável como sendo das 10:00 às 22:00 horas - o que, por si só, é uma incongruência estatística). Mas, enquanto no RGQ-SCM o art. 15 define que a medição deve ocorrer na casa dos usuários, com uma dispersão da amostrage tal que permita a representação estatisticamente significativa da diversidade do público usuário do serviço, no RGQ-SMP apenas é dito que o mesmo software que for disponibilizado para que os usuários façam suas próprias mediçoes também poderá ser usado para efetuar as medições para cálculo oficial dos indicadores. E não diz nada sobre como escolher uma amostra estatisticamente significativa dos usuários, que, no caso do SMP, tem uma dimensão a mais em relação ao SCM: a maior diversidade de equipamentos de acesso (smartphones e tablets, além dos desktops e notebooks típicos do SCM).

Para terminar esta etapa da análise, vou apenas sumarizar as metas a atingir em cada indicador, para os dois serviços (SCM e SMP).

(*) Tanto o indicador SCM6 (diretamente, pelo inciso III do art. 15 do RGQ-SCM) quanto o indicador SMP10 (indiretamente, por analogia ao que é dito sobre o software de medição a ser disponibilizado aos usuários no § 8º do art. 24 do RGQ-SMP) dizem que a medição deve ser efetuada entre o equipamento do usuário e o PTT. Só não especifica o critério para definir qual PTT usar nas medições, porque existem vários, públicos e privados.

Na próxima parte vou analisar com calma a questão do como (how) medir. Do svidanʹya tovarishchi.

To NAT or not to NAT? That's the question for HSPA/HSPA+

2011-11-09T18:10:00.000-02:00

No artigo anterior eu defendi a tese que a opção menos ruim (porque boa, boa mesmo, de verdade, não tem) para a migração do serviço de acesso móvel à Internet através das redes de acesso celulares 3G (HSPA e HSPA+) era a abordagem dual-stack (ver RFC 4213).

Nos comentários daquele artigo o Rubens Kuhl e o Juliano defenderam que a melhor opção é o uso do NAT64. Certamente que eu acho possível usar o NAT64 neste contexto, mas tenho dúvidas se ele vai funcionar tão bem.

Antes de começar a discutir prós e contras relativos de cada abordagem, pelo bem daqueles leitores que não tenham familiaridade com o assunto (afinal este blog tem uma finalidade basicamente instrutiva), vou fazer uma breve apresentação do que se trata o NAT64.

NAT significa Network Address Translation. Na Internet v4 o uso extensivo de NAT (ver RFC 2663) e dos blocos de endereçamento privado definidos na RFC 1918 permitiram um considerável aumento da sobrevida do espaço de endereçamento do IPv4, mas também criaram uma sensação de falsa segurança, e muito pouca coisa concreta foi feita para que a transição IPv4-IPv6 ocorresse de fato. Resultado: muito tempo perdido, e agora vamos ter que fazer correndo o que podia ter sido feito com calma.

Na Internet v6 não existe motivo para o uso de NAT, como é destacado na RFC 4864. Já a questão de como um host v6 pode estabelecer conexão com um host v4, e vice-versa, só pode ocorrer mediante alguma forma de NAT para fazer a "ponte" entre as duas Internets (v4 e v6).

O NAT64 permite que aplicações em um host que seja single-stack IPv6 consigam acessar aplicações que residem em hosts também single-stack, porém IPv4. Os recursos necessários para usar o NAT64 são:

Um Well-Known Prefix (WNP) IPv6. Conforme a seção 2.1 da RFC 6052, o WNP para o NAT64 é 64:ff9b::/96 (se você já penou pra entender a notação dotted decimal dos endereços IPv4, então prepare-se, porque a notação dos entereços IPv6 é bem mais críptica. Sugiro dar uma olhada aqui).
Servidor DNS que suporte as extensões DNS64 (RFC 6052 e RFC 6146)

A figura abaixo mostra o esquema geral de funcionamento do NAT64.

O fluxo de mensagens mostrado é para quando o host de destino só possui conectividade IPv4 (o que fica evidente pela resposta de erro do servidor DNS para o servidor DNS64 quando ele pede o registro AAAA do host de destino). Se o host de destino possuísse conectividade IPv6 haveria uma resposta válida para a query pelo registro AAAA no servidor DNS, e (mesmo que o host de destino fosse dual-stack e também houvesse uma resposta com o registro A associado) a conectividade IPv6 seria possível - logo o gateway NAT64 não seria usado.

Bonito, porém vejo um problema sério nesta abordagem. Ele é muito bom quando os UEs estão querendo acessar servidores IPv4 no regime client-server habitual (ex.: web surfing e verificação da caixa postal de e-mails). Mas a situação muda quando a direção do início da sessão é invertida (da Internet v4 para dentro da "ilha" IPv6 que é a rede interna da operadora). E, no quadro de funcionamento peer-to-peer típico das aplicações de telefonia (tanto na conexão bearer quanto na conexão de sinalização SIP) isto vai ocorrer a toda hora - Exemplo: o IMS de uma operadora, ainda usando IPv4, tentando negociar o estabelecimento de uma sessão com o IMS de outra operadora, que já migrou a plataforma para IPv6.

Aí a solução será o que? Incorporar suporte a NAT64 stateless, mais algum mecanismo de NAT traversal, tipo STUN ou TURN? Vai ficar complicado. E talvez não escale bem.

No geral ainda simpatizo mais com a solução puramente dual-stack apresentada no post anterior. É certo que também é necessário o suporte do DNS64, mas fica muito mais simples para as aplicações decidirem como estabelecer conexão. Se ela recebe um registro AAAA, então a conectividade é estabelecida pelo socket v6, e se recebe apenas um registro A, ela usa o socket v4. E não há obrigatoriedade que o servidor DNS64 tenha conectividade IPv6, como é o caso na solução NAT64.

Outro problema óbvio para a solução dual-stack no ambiente das redes de acesso HSPA/HSPA+ é que cada UE precisa receber endereçamento IPv4 e IPv6, só que nenhuma operadora tem (nem vai ter) pool de endereços IPv4 públicos suficientes para atender à demanda de todos os clientes conectados. Neste caso creio que a saída menos ruim (porque também tem problemas de escalabilidade) é a proposta Dual-Stack Lite (DS-Lite, RFC 6333). Veja a figura abaixo.

Na proposta DS-Lite o endereçamento IPv4 dos UEs (que são dual-stack) é feito com endereços de alguma das faixas privadas definidas na RFC 1918 (ex.: 10.0.0.0/8). O tráfego IPv4 é destinado para a Internet v4 através de um Carrier-Grade NAT (CGN) gateway de forma muito parecida com o que já é feito hoje. E o tráfego IPv6 é encaminhado diretamente à Internet v6. Possivelmente a "ilha" IPv6 da operadora estará conectada às demais "ilhas" IPv6 por mecanismos de tunelamento sobre a Internet v4. Destes todos, o que me parece mais utilizado no momento é, como já disse no post anterior, o Teredo (RFC 4380), mas também existem outras opções, como, por exemplo, o 6rd (RFC 5569 e RFC 5969).

E, para não alongar muito, se for o caso deixo para mais tarde a análise do SIIT (Stateless IP/ICMP Translation - RFC 6052, RFC 6144 e RFC 6145) no contexto das redes de acesso HSPA/HSPA+.

Para fechar, então. um resumão do problema, conforme a minha opinião (o 3GPP e os fornecedores podem divergir - só que a operadora deve ter suas próprias idéias, não andar a reboque do que dizem os fornecedores), e é o que eu recomendaria às operadoras:

O grande fator decisivo da estratégia é o roadmap de disponibilidade do IPv6 pelos fornecedores dos UEs. Computadores convencionais não são problema, porque todos os sistemas operacionais relevantes (MS-Windows, Apple MacOS, Linux em vários "sabores", Solaris, HP-UX, AIX, zOS, etc.) já oferecem suporte ao dual-stack. O problema são os smartphones e os tablets. Todo o resto, para mim, é legacy.
Se a questão da duplicidade dos PDP contexts não for um problema, minha sugestão é: vá para uma solução dual-stack. Se o pool de endereços IPv4 apertar, cá para DS-Lite.
Se UEs dual-stack forem escassos, ou a duplicidade dos PDP contexts for um problema, vá para o NAT64. Separe os UEs legacy para usarem apenas PDP contexts IPv4, e, para todos que suportarem, use apenas PDP contexts IPv6.

Por ora é isso. Mas este é o tipo do assunto que ainda pode render mais posts, então até a qualquer momento, em edição extraordinária.

IPv6 e as redes de acesso HSPA/HSPA+

2011-11-08T20:44:00.000-02:00

Eu sei que ainda estou devendo para vocês o exemplo prático do algoritmo de planejamento de capacidade, mas a notícia que eu vi hoje, falando da preparação da TIM para o uso do protocolo IPv6, me causou uma preocupação: até que ponto o pessoal de marketing está consciente do que está fazendo ao usar este tipo de migração da rede como argumento para fazer posicionamento?

Migrar o serviço de acesso à internet de uma operadora celular 3G para IPv6 tem uma série de aspectos peculiares, além daqueles que afetam a migração de qualquer ISP para o IPv6. Talvez o maior deles seja o problema dos PDP contexts.

Para entender este problema temos que entender antes como funciona o acesso de um dispositivo móvel à Internet através de uma rede celular 3G. A figura abaixo dá um sumário disso.

Uma conexão PSD (Packet-Switching Domain) ocorre entre o UE (user equipment) e o GGSN (Gateway GPRS Support Node - eu sei... embora estejamos falando de HSPA e HSPA+, o nome do gateway ainda refere-se ao velho GPRS). Fisicamente essa conexão é mediada pelo Node-b onde o UE estiver concectado e pela RNC (Radio Network Controller) onde o Node-b estiver registrado. Como o UE é móvel, tanto o Node-B quanto a RNC que atendem o UE podem mudar ao longo da duração da conexão. Faz parte do processo de handover manter a conexão física UE-GGSN estável durante as trocas de Node-b e/ou RNC.

Logicamente a conexão UE-GGSN é associada a uma entidade chamada PDP (Packet Data Protocol) context. Na prática o PDP context funciona como um túnel lógico, e se comporta como se fosse uma interface de nível 2 para cada um dos equipamentos nas extremidades.

E isto é um problema por quê? Porquê, até que se complete a transição de todos os sites, serviços e aplicações da Internet para IPv6, nós teremos que conviver com duas Internet separadas logicamente: A Internet "clássica" IPv4 e a nova Internet IPv6. O processo de transição vai passar por duas etapas distintas, e nós estamos começando a entrar na primeira delas. E não tem prazo definido para a duração de cada fase.

A única forma prática (e recomendada pela IETF - Internet Engineering Task Force) para conviver com este processo de migração é que todos os hosts conectados possuam as duas pilhas de protocolos, IPv4 e IPv6 funcionando simultaneamente. Esta estratégia é chamada de dual-stack, e funciona da seguinte forma (para entender a figura você tem que ter familiaridade com o modelo TCP/IP)..

Desta forma cada host pode ter acesso às duas "Internets" enquanto durar a transição. Mas continua a regra: uma aplicação v4 não consegue dialogar diretamente com uma aplicação v6, e vice-versa. Vejamos as consequências disso para o modelo operacional da nossa rede de acesso 3G HSPA ou HSPA+.

Cada PDP context só pode estar associado a um único protocolo de nível 3. Portanto se o UE e o GGSN tem que funcionar em modo dual-stack, cada conexão PSD vai precisar de dois PDP contexts: um para o IPv4 e outro para o IPv6. Isto vai ter consequências em termos de memória e capacidade de processamento da platafoma que suporta o GGSN, e vai resultar em mais sinalização entre UE / Node-b / RNC / GGSN, o que pode ser problemático na HMM de algumas células. Portanto o planejamento de capacidade da interface aérea e do backhaul dos cell-sites tem que considerar esta carga extra.

Outra coisa é que, em geral, os fornecedores de soluções de GGSN cobram da operadora por número máximo de PDP contexts abertos (ativos ou dormentes), então tem que haver uma briga comercial feia aqui, senão o preço do GGSN vai quase dobrar de uma hora para outra.

E, como dizem os anúncios das Organizações Tabajara (do Casseta e Planeta), não é só somente isso: ainda é muito incipiente a disponibilidade de UEs (exceto notebooks e desktops) capazes de funcionar em modo dual-stack. Mesmo que a operadora tenha todo o seu lado preparado e testado, poucos UEs estão prontos para desfrutar disso.

Por último temos a questão de como será a conexão, física e lógica, do GGSN às duas Intenets, v4 e v6. A solução mais básica é: duas interfaces físicas separadas (ou, pelo menos, duas interfaces lógicas separadas sobre a mesma interface física), cada uma delas conectada a roteadores diferentes (ou portas físicas ou lógicas diferentes de um mesmo roteador), cada uma delas servindo como uplink para uma das Internets.

Mas, como os diagramas da transição mostram, cada etapa é formada por "ilhas" de uma das Internets conectadas via tunelamento através do "mar" da outra internet (neste momento o IPv4 é o mar, e o IPv6 as ilhas, depois os papéis se invertem). Então existe a questão de quem vai prover o tunelamento do tráfego IPv6 da operadora (na fase 1)?

A resposta mais simples é: o fornecedor do(s) uplinks cuida disso. Neste caso, a depender do grau de separação física e lógica entre as interfaces e uplinks de acesso às Internets, a operadora pode não ter que fazer nada ou pode ter que configurar seu(s) roteadores de borda com as Internets - ou o próprio GGSN, e isso vai ter que ser outro item de negociação com o fornecedor - para fazer o tunelamento do tráfego IPv6 sobre pacotes IPv4. O mecanismo de tunelamento recomendado no momento é o Teredo (RFC 4380, RFC 5991 e RFC 6081).

A figura abaixo mostra o caso onde o tuelamento Teredo é implementado no roteador de borda com a Internet v4.

Esta figura é apenas uma visão simplificada. Ainda teriam que ser acrescentados os inevitáveis Firewalls e servidores DPI (Deep Packet Inspection) e, caso a arquitetura de serviços da operadora os use, servidores CDN (Content Delivery Network).

vocês percebem que isto é apenas um arranhão no problema completo de projetar a migração do acesso aos serviços de acesso a Internet (e aos serviços internos da operadora) para IPv6. E este é o motivo pelo qual achei engraçado a TIM ficar tocando tambores em público. Será que ela já resolveu dodos estes aspectos? Se algum dos leitores tiver conhecimento sobre o assunto e quiser entrar em contato comigo para conversar sobre isso eu agradeço.

História de terror para jovens administradores de rede

2011-10-29T14:30:00.000-02:00

Network capacity planning - um algoritmo

2011-10-27T19:19:00.003-02:00

Vamos primeiro definir: o que é fazer planejamento de capacidade? É garantir que os recursos da sua rede (enlaces de comunicação e nós de comutação de pacotes) sejam capazes de cursar o tráfego previsto sem entrar em congestionamento.

Neste artigo vou apresentar um algoritmo simples para, conhecido o interesse de tráfego (em K/M/Gbps e K/M/Gpps) bidirecional entre todos os pontos de ingresso e egresso de tráfego na rede, calcular o volume de tráfego na HMM (Hora de Maior Movimento) em cada enlace e em cada nó da rede.

Vetor dos nós de comutação:

Os nós de comutação de pacotes da rede (roteadores e switches) são descritos como um vetor (array unidimensional) de estruturas de dados. Cada estrutura S(i) contém um acumulador do volume de tráfego cursado em K/M/Gbps (bits/s) e um acumulador do volume de tráfego cursado em K/M/Gpps (packets/s), para cada hora do dia, conforme o modelo abaixo.

Como regra geral vou usar sempre a seguinte convenção para os itens de hora: cada rótulo hh:00 acumula o tráfego desde a hora hh:00:00 até a hora hh:59:59. Exemplo: o rótulo 13:00 representa os valores desde 13:00:00 até 13:59:59.

Outra dúvida comum é: porque os volumes de tráfego em K/M/Gbps e em K/M/Gpps? Aplicações diferentes geram tamanhos médios de pacote diferentes. Aplicações tipo VoIP geram um K/M/Gpps alto, porém com um K/M/Gbps modesto. O contrário acontece com aplicações como, por exemplo, transferência de arquivos. Como a capacidade dos elementos de comutação não depende somente dos K/M/Gbps trafegados, mas tem um limite muito mais sensível para o K/M/Gpps máximo, ambos os números são importantes.

Matriz de topologia da rede:

Para representar a topologia da rede vamos usar uma matriz (array bidimensional) de estruturas de dados. A numeração dos elementos nas dimensões i e j da matriz de topologia replicam a numeração da dimensão i do vetor de nós de comutação. Desta forma cada estrutura T(i,j) representa a existência (ou não) de um enlace de comunicação entre os elementos i e j do vetor de nós de comutação e o volume de tráfego esperado, em K/M/Gbps e K/M/Gpps, a cada hora, na direção de i para j. Obviamente, se existe o enlace T(i,j) então também tem que existir o enlace T(j,i), que representa o tráfego na direção reversa (de j para i) do enlace.

Abaixo temos um modelo para o elemento T(i,j)

Matriz de interesse de tráfego:

Cada estrutura I(i,j) desta matriz (array bidimensional) indica o particionamento do tráfego, em K/M/Gbps e K/M/Gpps, por hora do dia, originado no nó de comutação i e direcionado ao nó de comutação j, conforme o modelo abaixo.

Uma situação comum é a existência concomitante do tráfego dos serviços A, B, C, ... cursando pela rede. Neste caso é necessário montar uma matriz de interesse de tráfego para cada serviço individual, e depois executar o algoritmo com a matriz de interesse de tráfego total, ou seja, se IA(i,j), IB(i,j), IC(i,j), ... são as matrizes de interesse de tráfego, respectivamente, para os serviços A, B, C, ..., então o algoritmo deve ser executado sobre a matriz de interesse de tráfego obtida pela operação

Matriz de rotas:

A matriz de rotas é um array tridimensional que descreve a sequência dos nós de comutação que deve ser percorrida pelo tráfego. Visualmente podemos imaginar esta matriz como um cubo.

As dimensões i e j definem, respectivamente, os nós de comutação de início e fim da rota. cada instância da dimensão k declara a identificação (numérica, correspondente à numeração dos nós de comutação) de um dos nós de comutação na rota que vai do nó de comutação i até o nó de comutação j. Consequentemente o primeiro nó de comutação em cada rota é dado, implicitamente, pelo valor da dimensão i. E rota encerra´se quando localizamos um elemento na dimensão k cujo valor seja igual a j.

Condições normais de tráfego x condições de contingência:

A forma mais simples de executar este algoritmo é considerar o conteúdo das estruturas de dados que representem a situação normal de operação. Caso queira-se analisar também o comportamento da rede em situações de contingência é necessário criar novas versões das estruturas de dados, uma para cada situação de contingência que se deseje testar.

Neste caso os valores de tráfego em HMM em cada enlace e em cada nó de comutação será o pior caso obtido em cada ponto da rede, considerados todos os cenários testados.

Como definir o conteúdo da matriz de rotas?

Esta é, talvez, a parte mais complexa da utilização prática deste algoritmo, porque exige o conhecimento prévio da estrtura de rotas negociada entre os nós de comutação, geralmente pelo uso de algum protocolo de roteamento dinâmico (OSPF, IS-IS, etc.). Mesmo nos casos onde seja usada alguma forma de "circuitização de pacotes" (ex.: MPLS-TE) nem sempre é fácil saber com antecedência as rotas correspondentes ao cenário considerado (normal ou contingência).

Em termos práticos é necessário observar o comportamento real da rede em cada situação desejada, ou simular o comportamento dos algoritmos de roteamento dinâmico para definir quais rotas devem ser inseridas na matriz.

Que valores usar na(s) matriz(es) de interesse de tráfego?

Uma vez que buscamos o dimensionamento dos elementos da rede de tal forma que, mesmo em HMM, eles não apresentem congestionamento (e, talvez, para que não entrem em congestionamento mesmo em certas situações de contingência), temos que pensar um pouco sobre que valores de tráfego devemos considerar para cada hora do dia (por serviço, se for o caso).

O comportamento do tráfego medido em uma determinada hora não é constante. Existem diferenças, para a mesma hora, entre os diferentes dias da semana, feriados, etc. Quando tabhulamos estas variações obtemos (muito provavelmente) uma distribuição de frequência normal, para a qual calculamos o valor médio e o desvio padrão.

Minha sugestão, já que estamos projetando para o pico de tráfego em HMM, em cada hora considere como valor do tráfego (em bps e pps) o valor médio mais quatro desvios-padrão. Desta forma a probabilidade que qualquer tráfego observado seja menor ou igual a este valor é de, aproximadamente 99,69%

O algoritmo:

Pois bem... agora podemos iniciar o processamento dos dados.

Tudo começa pelo percurso sistematicamente da matriz de interesse de tráfego e, para cada par (i,j) de origem e destino de tráfego, Acumular (para todas as horas do dia) o tráfego nos nóe e links ao longo da rota que une o nó de comutação i ao nó de comutação j.

Vou representar os trechos do algoritmo usando a linguagem REXX. A sintaxe é muito simples e intuitiva. Não creio que isso venha a dificultar a compreensão pelos interessados. Não está mostrada a parte inicial de leitura dos dados nas respectivas estruturas.

Um detalhe da implementação mostrada: a linguagem REXX permite que o contexto das variáveis de um procedimento seja ou não visível para os procedimentos que ele invoca. A forma sintática que estou apresentando expõe todo o espaço de variáveis do procedimento invocador para os procedimentos invocados.

Como o primeiro nó de comutação na rota de i para j é o próprio nó i, a primeira coisa a fazer é acumular o tráfego (de todas as horas) no nó de comutação i. A seguir fazemos o percurso da rota até encontrar o elemento que contém o valor j, que marca o final da rota. Para cada elemento ao longo da rota (nós de comutação e enlaces) acumulamos o tráfego de i para j indicado na matriz de interesse de tráfego.

Uma observação sintática: a construção "DO WHILE" na linguagem REXX executa o teste da condição de controle no final do loop, o que resulta em pelo menos uma execução das instruções contidas no loop. O loop será executado enquanto o resultado da condição de controle for o valor lógico "VERDADEIRO"

Resta agora detalhar cada um do procedientos de acumulação do tráfego. Vejamos primeiro a acumulação por nó.

O nó alvo da acumulação é passado para o procedimento como um parâmetro, que é recuperado pela instrução "PARSE ARG". A variável índice da variação das horas começa do valor 1 (indicando o período das 00:00:00 às 00:59:59), somente porque a linguagem REXX não aceita valores de índice iguais a zero.

Aliás, o uso da hora como índice transforma, na prática, o vetor de nós de comutação em um array bidimensional, e a matriz de interesse de tráfego em um array tridimensional.

O procedimento de acumulação por enlace é logicamente semelhante ao procedimento de acumulação de tráfego por no, com a diferença que os parâmetros de entrada são dois: ponta A e ponta B do enlace. Da mesma forma que no procedimento anterior, a matriz de topologia transforma-se, na prática, em um array tridimensional, com o acréscimo do indice de hora.

Não estão mostrados os procedimentos para exibição/impressão dos resultados.

Como avaliar os resultados?

Após a execução do algoritmo o vetor dos nós de comutação e a matriz de topologia contém o tráfego acumulado sobre cada elemento, conforme indicado pela matriz de interesse de tráfego.

Para cada elemento representado nestas estruturaas de dados a sequência temporal dos valores indicará qual hora representa a HMM daquele elemento (que não é, necessariamente, a mesma sobre toda a rede).

O valor a ser considerado para dimensionamento dos nós de comutação é o valor de K/M/Gbps e K/M/Gpps na HMM daquele elemento. A especificação do roteador ou switch para este ponto da rede deve atender, no mínimo, a esta demanda de tráfego.

Para o dimensionamento dos enlaces é necessário comparar os valores de K/M/Gbps em HMM de cada enlace nas duas direções (porque o volume de tráfego sobre o enlace pode ser assimétrico). O valor para dimensionamento do enlace (i,j) deve ser o maior valor de HMM entre esta direção e a direção reversa (j,i).

No próximo artigo vou apresentar um caso-exemplo de utilização deste algoritmo. Inté...

Para engenheiros eletricistas

2011-10-21T19:49:00.001-02:00

Redes de telecomunicação (13) - Going all-IP (parte 3)

2011-10-21T19:06:00.000-02:00

Estive pensando sobre os assuntos que prometi, no final da parte anterior deste artigo, abordar aqui. Cheguei à concusão que preciso, antes, contextualizar melhor as mudanças de paradigma (ô terminologia batida, sô) envolvidas na prestação de serviços de nova geração. Sem isso não dá para arquitetar uma repartição racional de responsabilidades entre os três grupos atuantes no ecossistema NGN:

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.

Coloquei os fornecedores (vendors) junto com as operadoras de telecom e com os ISPs porque, até certo ponto, eles possuem um "carma compartilhado", no sentido que o fracasso do modelo de negócio (e, consequentemente, do próprio negócio) das operadoras ou ISPs leverá também ao fracasso os fornecedores que deles dependam.

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.

Este tipo de cenário exige três coisas principais: a integração funcional de vários tipos de redes de acesso, backhaul e core de forma transparente para o usuário; a capacidade de construir redes e serviços ditos carrier class (como isso tem sido usado pelos fornecedores tradicionais para criar barreiras de entrada neste mercado!) usando componentes COTS (Commercial, Off-The-Shelf); e a capacidade de um mesmo tipo de aplicação ser executado a partir de vários tipos de dispositivo, com as características da sessão podendo ser ajustadas on the fly;

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...

Teste de afinidade com programação Assembly - entendendo o exemplo

2011-10-01T13:30:00.000-03:00

Se você estiver na lamentável situação de nem sequer iniciar o teste porque não conseguiu entender o funcionamento do programa apresentado no exemplo, e porque ele é uma solução válida para o problema, não desespere.

Sua situação, na verdade, corresponde à maioria das pessoas que fazem o teste sem nenhum conhecimento prévio de linguagens de programação de baixo nível e/ou toria da computação e/ou arquitetura de computadores.

Para facilitar a sua vida vou fazer algo bem fora de moda hoje em dia: um teste de mesa. Vamos simular (por escrito) a execução passo a passo do programa e verificar se o efeito produzido corresponde ao que se pede.

Cada passo do programa será representado da seginte forma:

Vamos começar. Esta é a situação inicial (válida para todos os casos): cabeçotes de leitura e gravação posicionados no início da mídia e primeira instrução a executar no endereço de memória 0.

Após a execução da instrução T, como o caracter lido na mídia foi um *, a próxima instução a executar estará no endereço de memória 0 + 2 = 2. Observe a nova posição do cabeçote de leitura.

Agora a instrução executada é H, que grava um - na mídia e reposiciona o cabeçote de gravação. Próxima instrução a executar está no endereço de memória 3.

Desvio incondicional para a instrução no endereço de memória 0.

Voltamos à instrução T. Após execução o cabeçote de leitura é reposicionado e, como o caraccter lido foi um -, a próxima instrução a executar está no endereço de memória 0 + 1 = 1.

Desvio incondicional para a instução no endereço de memória 4.

Executa a instrução A, que grava um * na mídia e reposiciona o cabeçote de gravação. Próxima instrução a executar está no endereço 5.

O desvio para a instrução na posição de memória 0 voltará a executar a instrução T. A esta altura já dá para perceber toda a mecânica de execução do programa, que vai percorrer toda a mídia (supostamente de comprimento infinito) substituindo os caracteres * por -, e vice versa, como pedido.

Se ainda assim você não consegue entender como escrever os programas para solucionar os problemas propostos, então realmente é melhor você se dedicar a linguagens com sintaxe mais abstrata.

Gabarito do teste de afinidade com programação Assembly

2011-09-30T19:43:00.000-03:00

Rapaz! o post do teste de habilidade para programação Assembly me surpreendeu. Em apenas dois dias conseguiu chegar no 3º lugar geral de visualizações do blog, com 240 acessos até agora, sendo que o 1º colocado tem 381 visualizações. Impressionante.

De qualquer forma, aqui vai o gabarito dos problemas propostos, conforme prometido. Quem quiser discutir alguma das soluções apresentadas, ou quiser apresentar alguma outra solução, melhor ou alternativa (pense bem antes de fazer isso - em mais de 20 anos não apareceu nada melhor que isso), sinta-se à vontade em usar a área de comentários deste post, e eu digo o que acho da sua idéia, ok? Então vejamos:

Problema 1: AHAT12 ou AHT0A2 (duas soluções, com 6 instruções). Pontuação: 2 pontos para cada solução válida que você tenha encontrado.

Problema 2: T5AT7H0H3 (9 instruções). Pontuação: 2 pontos para a solução correta.

Problema 3: T0T0T097HT8AT8AT8A7 (19 instruções). Pontuação: 2 pontos pela estrutura lógica geral do programa, e mais 2 pontos se você acertou a "pegadinha" de colocar o programa em loop para forçar a parada (no sentido do programa não fazer mais nada, não da máquina não executar nenhuma instrução).

Meu critério pessoal de avaliação dos candidatos que fazem este teste é que, para ter futuro nesta área, a nota mínima neste teste é 6. Se você conseguiu, parabéns! Você proavelmente não terá diificuldade em habituar-se com a programação Assembly em qualquer arquitetura de hardware.

Se não conseguiu, paciência. Sugiro que você tente outras linguagens de programação, que não Assembly.

Correlação estatística entre câncer e celulares!

2011-09-29T22:01:00.001-03:00

Finalmente alguém teve uma idéia nova nesta área tão controversa.

Será que você leva jeito para programação Assembly?

2011-09-28T20:12:00.001-03:00

Cerca de 25 anos atrás, em uma das minhas encarnações anteriores como systems programmer, meu gerente surgiu com um teste de aptidão para avaliar a competência dos candidatos ao cargo de programador na área de raciocínio lógico.

Depois eu passei a ver este teste como uma forma legal de avaliar se um determinado candidato tinha potencial pra trabalhar na área de systems programming, porque o teste tem muito a ver com programação Assembly: entender a arquitetura da máquina e saber usar as instruções de máquina.

Se você tiver curiosidade sobre sua possível habilidade para esta área da Informática, sugiro que tente fazer o teste abaixo. As regras são as seguintes:

Você tem, no máximo, uma hora para fazer o teste;
Todas as informações necessárias para responder às questões estão no texto;
A interpretação das questões faz parte do teste.

Se você não se der bem, não se desespere. Eu mesmo, quando fiz o teste, não consegui terminar corretamente a terceira questão. E até hoje eu só encontrei uma pessoa que "gabaritou" o teste, e ele fez isso com requintes de crueldade: as duas primeiras questões ele fez de cabeça, e a terceira só precisou de um pouco de rascunho. Demorou, no total, uns 10 minutos.

Enfim, vamos ao enunciado. Depois publico o gabarito. Quem tiver um pouco de familiaridade com a teoria da computação vai reconhecer que o que vamos usar no teste é uma máquina de Turing.

Um computador hipotético é composto por:

a) Unidade de fita magnética cujos cabeçotes de leitura e gravação possuem acionamento independente (ou seja: é possível estar lendo e gravando em posições físicas diferentes da mídia montada na unidade) e, quando acionados, sempre atuam na direção progressiva de leitura/gravação da mídia;

b) Memória de tamanho infinito, com cada posição de memória sendo capaz de armazenar uma única instrução de máquina, e endereçamento das posições de memória de forma sequencial, crescente, iniciando em 0 (zero), com todos os endereços expressos em decimal;

c) CPU que sempre inicia a execução dos programas a partir da posição de memória com endereço 0 (zero) e que, com exceção dos casos previstos no instruction set, executa as instruções de máquina de forma sequencial em ordem crescente dos endereços de memória;

d) Instruction set:
d.1) Instrução A - causa a gravação de um caracter * (asterisco) na mídia montada na unidade de fita magnética;
d.2) Instrução H - causa a gravação de um caracter - (hífen) na mídia montada na unidade de fita magética;
d.3) Instrução T - causa a leitura de um caracter na mídia montada na unidade de fita magnética e: se o caracter lido for - (hífen) executa a seguir a instrução no endereço de memória x + 1; se o caracter lido for * (asterisco) executa a seguir a instrução no endereço de memória x + 2; onde x é o endereço de memória onde reside a instrução T;
d.4) Instrução n (onde n = 0,1,2,3,4,5,6,7,8 ou 9) - causa desvio incondicional para a instrução de máquina no endereço de memória n.

Para cada um dos exemplos apresentados e problemas propostos supõe-se que:

1) Existe mídia montada na unidade de fita magnética, cujo conteúdo inicial é uma sequência aleatória dos caracteres * (asterisco) e - (hífen), e tanto o cabeçote de leitura quanto o cabeçote de gravação da uidade de fita magnética estão posicionados no início físico da mídia;

2) Todas as posições da memória estão preenchidas com uma sequência aleatória de instruções de máquina válidas;

3) Não é possível codificar instruções de máquina inválidas;

4) Todos os programas par asolução dos problemas iniciam-se na posição de memória de endereço 0 (zero).

EXEMPLO:

Trocar, na mídia de fita magnética, cada caracter * (asterisco) por - (hífen), e vice-versa.

Resposta: T4H0A0

Com estas informações, elabore programas com o menor número possível de instruções de máquina que solucionem os problemas propostos.

PROBLEMAS PROPOSTOS:

P.1) Gravar, na mídia de fita magnética, o padrão de caracteres: *-**-***- ... (um asterisco, um hifen, dois asteriscos, um hífen, três asteriscos, um hífen, ...).

P.2) Trocar, na mídia de fita magnética, cada segundo caracter * (asterisco) encontrado pelo caracter - (hífen).

P.3) Localizar, na mídia de fita magnética, a primeira ocorrência do string *** (três asteriscos consecutivos) copiar, a partir do início da mídia de fita magnética, todos os caracteres que se seguem ao string localizado até encontrar a próxima ocorrência do string *** (três asteriscos consecutivos), copiando-os, inclusive, e depois parar.

Boa sorte!

O que aprender com Marie Curie, Lise Meitner e Emmy Noether?

2011-09-22T18:34:00.000-03:00

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

2011-09-11T13:51:00.000-03:00

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:

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)?
Como substituir a transmissão convencional TDM (veja este artigo anterior) por uma rede TCP/IP?
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.

Como me sinto hoje...

2011-09-10T20:42:00.001-03:00

Essa música do John Lennon resume tudo... Perfeito...

People say I'm crazy doing what I'm doing,
Well they give me all kinds of warnings to save me from ruin,
When I say that I'm o.k. they look at me kind of strange,
Surely you're not happy now you no longer play the game,

People say I'm lazy dreaming my life away,
Well they give me all kinds of advice designed to enlighten me,
When I tell that I'm doing Fine watching shadows on the wall,
Don't you miss the big time boy you're no longer on the ball?

I'm just sitting here watching the wheels go round and round,
I really love to watch them roll,
No longer riding on the merry-go-round,
I just had to let it go,

People asking questions lost in confusion,
Well I tell them there's no problem, only solutions,
Well they shake their heads and they look at me as if I've lost my mind,
I tell them there's no hurry... I'm just sitting here doing time,

I'm just sitting here watching the wheels go round and round,
I really love to watch them roll,
No longer riding on the merry-go-round,
I just had to let it go.

Redes de telecomunicação (10) - Going all-IP (parte 1)

2011-09-08T16:57:00.000-03:00

Muy bueno... depois de ver a evolução das redes de acesso celular é hora de voltarmos atrás no tempo e retomar a história da rede fixa, para cobrir novamente as décadas de 90 do século XX e a primeira década do século XXI, mas agora focando na evolução das redes de telefonia fixa e sua convergência com as redes de telefonia móvel, com foco principalmente na forma como a família de protocolos TCP/IP estabeleceu-se como padrão para todo este cenário.

Em um artigo anterior falamos sobre o surgimento da ARPANET, e como esta rede foi essencial na demonstração da viabilidade do conceito de comutação de pacotes. Mas, além disso, a ARPANET também foi o berço para o modelo mais bem-sucedido de arquitetura de redes até hoje: o TCP/IP, que permitiu o surgimento da Internet em 1983 (a ARPANET tornou-se, então, apenas mais uma das várias redes TCP/IP interconectadas pela Internet).

Não fossem por dois eventos críticos, a Internet provavelmente contiuaria a ser essencialmente um brinquedinho de acadêmicos. O primeiro evento foi a popularização do uso corporativo dos computadores pessoais e sua interligação por redes locais (Local Area Networks - LANs); e o segundo foi o surgimento do primeiro serviço realmente popular na Internet, que acabou conduzindo à sua abertura (depois de muita chiadeira pelos acadêmicos mais puristas) para usos comerciais: a WorldWideWeb - WWW ou W3.

No período de 1995 a 2000 ocorreu a famosa "bolha da Internet". Neste período as redes de telefonia fixa viram-se compelidas, primeiro a suportar o crescimento da Internet (como fornecedores básicos de conectividade entre os vários provedores de serviço e de acesso, e entre os provedores de acesso e os usuários), e depois a entrar no jogo da construção e expansão da rede, assumindo elas mesmas papéis cada vez mais destacados como provedores de serviços e de acesso.

Cristalizou-se a visão que, em muito pouco tempo (segundo a percepção da época) a Internet seria a únca rede que interessava, a Information Superhighway (ou Infobahn), e que todos os tipos de aplicação, inclusive a telefonia tradicional, migrariam naturalmente para o ambiente TCP/IP. Os estrategistas da evolução da rede de telecomunnicações (inclusive a ITU-T) incorporaram este conceito, e começaram a trabalhar em uma nova proposta de rede multisserviço: Next Generation Network - NGN. Esta percepção pode ser sintetizada na figura abaixo, que está na Recomendação Y.110 da ITU-T: Global Information Infrastructure Principles and Framework.

Ainda nesta mesma recomendação, e adaptando um pouco, o modelo arquitetural para a GII (Global Information Infrastructure) tem a seguinte aparência:

Obsere-se que a Intrnet é considerada como parte da camada "funções de telecom". Isto implica a visão (controversa) da Internet como mais uma rede de telecom, gerida e regulada por princípios semelhantes aos das demais redes de telecom. Então o que poderíamos esperar como situação final da evolução deste modelo seria que a camada "funções de telecom" da arquitetura GII tivesse a seguinte estrutura:

é claro que a realização de um modelo assim transformaria todas ass redes de telecom (e, na verdade, todos os tipos de redes) em uma única Internet, com os usários tendo acesso a todos os tipos de aplicações e serviços através de seus terminais. Uma visão deste tipo era (e ainda é) extremamente disruptiva para o modelo de negócio clássico de telecom e, particularmente, para o modelo de negócio dos fornecedores de equipamentos de telecom.

Eles viram-se na contingência de competir com empresas que, até então, só eram percebidas como fornecedoras de equiapamentos para redes corporativas. Estes novos entrantes possuíam uma postura fundamentalmente diferente, e foram percebidos de imediato como uma ameaça muito séria. A reação coletiva da indústria de equipamentos de telecom foi retardar ao máximo a adoção do TCP/IP, exacerbando sempre que possível a sensação de insegurança natural de um ambiente em transição, enquanto desenvolviam eles próprios linhas alternativas de equipamentos para competir nesta área.

Além disso há o problema da cultura corporativa das operadoras de telecom, extremamente reticente em adotar novos procedimentos. Isto acabou traduzindo-se, em minha opinião, em uma tendência em acomodar conceitos clássicos de telecom dentro da moldura de gerência de uma rede NGN, principalmente a questão do provisionamento.

Provisionar, em telecom, é o ato de alocar recursos para um determinado usuário ou finalidade. Por exemplo: para que um usuário de acesso fixo em banda larga possa utilizar o serviço as seguintes atividades de provisionamento tem que ser executadas:

Designar e alocar um par de fios da casa do usuário até a central mais próxima;
Providenciar o entroncamento do par de fios designado em uma porta de acesso DSLAM;
Configurar a existência deste usuário (criar um par userid/senha) no BRAS;
Enviar alguém até a casa do usuário para instalar e configurar o modem xDSL e testar o acesso ao serviço.

O problema é que, embora algumas atividades de provisionamento já tivessem caráter estatístico, como o provisionamento de recursos de transmissão para o entroncamento de centrais (veja o que já falamos antes sobre Erlang), as fórmulas e a postura para provisionamento estatístico em um ambiente puro de comutação de pacotes são diferentes. Isto altera a maneira de planejar a expansão da rede, e isto é percebido pela comunidade de engenharia de telecom como um fator de insegurança.

A reação natural foi tentar preservar ao máximo conceitos que tornavam a mudança de paradigma menos ameaçadora. Daí, creio eu, a ênfase exagerada no uso de circuitos virtuais, em um processo que eu apelidei de circuitizaçao de pacotes.

Seja como for, o processo de transformação da infra estrutura de telecom em uma rede all-IP já está bastante adiantado. Na próxima parte deste artigo vou tratar da interface da NGN com o serviço legado de telefonia, as mudanças que isto traz à hierarquia tradicional das centrais de comutação e à sinalização, e pelo menos iniciar a conversa sobre o elemento (chamá-lo assim é um caso de understatement) chave para a operação convergente de serviços fixos e móveis em modo de comutação de pacotes: o IP Multimedia Subsystem (IMS).

Internet é ou não é Telecom?

2011-09-05T23:17:00.001-03:00

Em 15/06/2011 o Edmundo Matarazzo publicou este artigo no site e-Thesis, salientando (e justificando com a hermenêutica da LGT) as diferenças entre serviços de telecom e de Internet. Em 02/09/2011 o Silvio Meira publicou o post Internet não é Telecom no seu blog, dia a dia, bit a bit, defendendo ponto de vista semelhante, mas apoiando-se essencialmente em uma argumentação sobre a conveniência política da separação.

Isto me deu o que pensar: porque será que representantes destas duas linhagens técnicas, antagônicas desde longa data (veja, por exemplo, o artigo Bellheads vs Netheads publicado originalmente na revista Wired em outubro de 1996), estão tão interessados em salientar as diferenças entre os serviços de telecom e de Internet? E demarcar a necessidade de continuarmos a gerir e regular estes dois domínios de forma totalmente separada?

Com o devido respeito que estas opiniões merecem, peço licença para defender, com base na convergência tecnológica e no interesse dos usuários, o ponto de vista diametralmente oposto: Internet e telecom devem, sim, ser consideradas em conjunto, e devem posuir marcos regulatórios coerentes entre si.

Tenho, assim como o Silvio Meira, sérias restrições quanto à intervenção governamental nestes assuntos. Mas não acredito que minha descrença que qualquer governo (especialmente o atual) deva atuar acima e além do papel de agente regulador do mercado seja impeditivo para a convergência dos marcos regulatórios de telecom e da Internet. E, sobretudo, não acho que um marco regulatório sensato para a Internet tenha que, necessariamente, assumir o aspecto de um "AI-5 digital", como são acusadas as iniciativas em andamento sobre este assunto.

Eu já apresentei esta argumentação antes, pelo menos em parte, no artigo do e-Thesis onde comentei a posição do Edmundo Matarazzo, e vou repisar o mesmo caminho aqui, só que agora eu posso fazer desenhos :o)

Vejamos... todo o contexto tecnológico e psicológico envolvendo o surgimento da Internet e a promulgação da LGT supõem uma estrutura da rede e dos serviços por ela suportados, com a seguinte aparência:

Neste contexto a definição da Internet como serviço de valor agregado à rede de telecom faz todo o sentido, uma vez que os componentes da Internet (modems de acesso, roteadores/switches, computadores clientes e servidores) são usuários do serviço de aluguel de circuitos de comunicação de dados e/ou do serviço de comunicação de dados por comutação de pacotes.

Porém a evolução tecnológica para um ambiente de redes all-IP já introduziu profundas mudanças na configuração descrita aí em cima. A figura que vale hoje é a seguinte:

Neste contexto a Internet ainda pode ser vista como um serviço de valor agregado, já que ela pode ser entendida como usuária do serviço de provimento de VPN L2/L3. Os serviços da operadora (voz, vídeo, etc.) já estão quase todos sobre uma base de transporte all-IP, e podem ser enxergados como aplicações, de forma semelhante ao que ocorre na Internet, mas eles ainda podem ser percebidos como distintos das aplicações da Internet, já que os ambientes IP públicos (a Internet) e privados (a rede interna de prestação de serviços da operadora) tem fronteiras bem marcadas.

Com a disseminaçao do IPv6 o cenário mudará novamente, e a distinção entre aplcações providas dentro ou fora da rede da operadora perde nitidez. Do ponto de vista do usuário existirão aplicações que ele pode acessar porque tem assinatura daquele provedor (de serviço, não de rede) e aplicações públicas, disponíveis sem custo. Os serviços da operadora são apenas mais um site dentre inúmeros outros acessíveis pela estrutura integrada que, do ponto de vista do usuário, é a Internet, embora seja formada fisicamente pela concatenação dos recursos de rede e de serviços de diversos provedores..

Portanto o que eu vejo como necessáro neste contexto final é a existência de dois domínios de regulação. Um que tratará de garantir a coerência e a interoperação de cada serviço IP disponível para os usuários. Os gestores dos servidores destes serviços terão que seguir estas regras para garantir serviços com interoperação global garantida (algo semelhante ao que a ITU sempre fez para a telefonia). O outro domínio tratará dos aspectos de construção e interoperação da infra-estrutura de transporte em todos os níveis, desde o provedor local de acesso até os provedores de interconexão tier 1. O objetivo deste domínio é garantir conectividade (e, possivelmente, níveis diferenciados de QoS) entre quaisquer pontos de conexão.

Neste sentido, não vejo mais diferença entre o que hoje chamamos Internet e os serviços locais ofertados por cada provedor de acesso (operadoras de telecom aí incluídas). Portanto acho que o melhor que podemos fazer é reconhecer que a evolução neste sentido é inexorável, e começar a preparar nosso marco regulatório de acordo com isso.

Piadinha para engenheiros

2011-09-04T20:38:00.001-03:00

Já que falamos tanto de séries e transformadas de Fourier ultimamente...

Redes de telecomunicação (9) - Telefonia celular (parte 3)

2011-09-04T20:11:00.001-03:00

Como prometido, nesta terceira e última parte deste artigo vamos ver os desenvolvimentos da telefonia celular (e da transmissão de dados wireless em banda larga) ocorridos na primeira década do século XXI, com a entrada em operação dos sistemas padronizados no IMT-2000 da ITU, também conhecidos como terceira geração (3G) da telefonia celular.

Como falamos na parte anterior deste artigo o processo de migração da 2G para 3G foi como uma corrida, com os dois principais concorrentes (3GPP e 3GPP2) apressando-se em apresentar o mais antecipadamente possível suas features, em busca de um melhor posicionamento de mercado.

Como uma solução de consenso não era possível, a ITU, então, tomou a decisão de tornar as duas propostas padrões aceitáveis para o IMT-2000. Ainda não vi descrição melhor para este tipo de comportamento dos órgãos de padronização do que esta tirinha do Scott Adams.

Enfim... os padrões aceitos pela ITU para o IMT-2000 foram:

A proposta UMTS (Universal Mobile Telecommunications System) do 3GPP, com três "sabores" para a UTRA (UMTS Terrestrial Radio Access):
a) W-CDMA ou UTRA-FDD (Frequency Division Duplex)
b) TD-CDMA ou UTRA-TDD HCR (Time Division Duplex - High Chip Rate)
c) TD-SCDMA ou UTRA-TDD LCR (Time Division Duplex - Low Chip Rate);
A proposta CDMA2000 do 3GPP2.

Até onde eu sei as opções de interface aérea UMTS diferentes do W-CDMA são utilizadas apenas na China (embora isto possa representar "apenas" algumas dezenas de milhões de usuários).

Mas a guerra religiosa não parou por aí. Os dois grupos engajaram-se na corrida para atingir novos patamares de desempenho e adiantar as características do que poderia vir a ser a quarta geração (4G) da telefonia celular, embora nem a ITU, àquela altura, soubesse dizer como seria isso. Então, da mesma forma que tivemos uma "geração intermediária" 2,5G, fruto da disputa de mercado, também apareceu uma 3,5G cujas caracerísticas gerais estão resumidas na tabela abaixo.

As taxas de downink e uplink mostradas na tabela são máximos teóricos. O desempenho de uma rede real dependerá de vários fatores, e certamente será menor que o indicado aqui.

Até meados da década tudo parecia perfeito para as famílias de padrões do 3GPP, que ganharam uma óbvia vantagem mercadológica sobre os padrões do 3GPP2. Porém o aparecimento de um novo combatente - o IEEE (Institute of Electrical and Electronical Engineers) - esquentou novamente a "corrida armamentista" e provocou o aparecimento de novas propostas por parte do 3GPP e do 3GPP2.

A proposta disruptiva feita pelo IEEE foi o WiMAX (Worldwide Interoperability for Microwave Access - IEEE 802.16). O 3GPP respondeu com a proposta LTE (Long Term Evolution), e o 3GPP2 tentou manter-se no jogo com a proposta UMB (Ultra Mobile Broadband). Digo tentou porque a Qualcomm, principal patrocinadora da tecnologia UMB, desistiu formalmente do seu desenvolvimento em 2008 e passou a adotar o padrão LTE.

Todas estas propostas tem em comum a utilização do OFDMA (Orthogonal Frequency Division Multiple Access), também conhecido como DMT (Discrete Multi-Tone Modulation) como técnica básica de multiplexação, portanto cabe aqui uma descrição básica deste método, assim como fiz para o FDMA (na primeira parte deste artigo), TDMA e CDMA (na segunda parte deste artigo). Entretanto, assim como no caso do CDMA, não podemos escapar de um pouco de matemática para entender os princípios de funcionamento do OFDMA. Interessante que, embora as idéias que vamos ver sejam conhecidas desde o final da década de 60 do século XX, para usar efetivamente esta técnica foi necessário esperar pelo aparecimento de ASICs (Application-Specific Integrated Circuits) capazes de executar rapidamente algoritmos de processamento de sinais digitais.

Um sinal modulado em QAM (veja este artigo anterior) possui seu espectro de frequência com a forma de uma função sync (sen x/x), que tem a seguinte aparência:

Se escolhermos um conjunto de portadoras QAM de tal forma que os seus espectros de frequência possuam todos os seus zeros comuns, como na figura abaixo, este conjunto de funções satisfaz à condição de ortogonalidade (também descrito na parte anterior deste artigo, quando tratamos do CDMA).

Podemos então desdobrar no tempo o sinal a transmitir, atribuindo grupos de n bits para cada uma das subportadoras w1, w2, ... de tal forma que cada um destes grupos pode ser representado como um dos símbolos de uma constelação QAM que mantenha a subportadora abaixo do baud rate máximo permitido pelo teorema de Shannon-Hartley (veja neste artigo anterior).

A questão do processamento de sinais aparece pelo seguinte motivo: cada subportadora modulada QAM pode ser representada como um número complexo (cos wt + i.sen wt), e o conjunto das subportadoras representa a transformada discreta de Fourier de um sinal.

A transformada de Fourier pode ser entendida como uma operação que, quando aplicada sobre um sinal no domínio tempo, produz um sinal correspondente no domínio frequência. Analogamente a transformada inversa de fourier transforma sinais no domínio frequência em sinais no domínio tempo. Os sinais nos domínios tempo e frequência estão relacionados pela expansão em série de Fourier. Então (se você não tem estômago para matemática, pule a figura que vem a seguir) se f(t) é um sinal no domínio tempo e F(w) é a sua transformada de Fourier, então:

A primeira expressão é a transformada direta (ou simplesmente a transformada) de Fourier, e a segunda expressão é a transformada inversa de Fourier. A terceira expressão é a fórmula de Euler, que correlaciona as formas retangular e exponencial para representação de números complexos (se você ainda não tinha visto nenhuma aplicação prática para os números complexos que você estudou - ou devia ter estudado - no ensino médio, acabou de achar).

Tipicamente, quando falamos de processamento de sinais, estaremos trabalhando sobre os valores (geralmente expressos em binário) de amostras discretas dos sinais. Cada um destes procedimentos matemáticos pode ser codificado como um algoritmo a ser executado sobre as amostras. Conforme a direção em que o algoritmo opere ele é chamado de FFT (Fast Fourier Transform) ou IFFT (Inverse FFT). Então o esquema geral para a codificação e decodificação de sinais OFDM pode ser representado como na figura abaixo.

Eu me estendi em mais detalhes sobre o OFDM porque ele é utilizado em quase todas as formas de transmissão de dados em banda larga atualmente, então vale a pena entendê-lo um pouco melhor. Quanto às implementações atuais para os padrões LTE e WiMAX, a tabela abaixo resume as suas características principais.

Pelo que parece, dadas as indicações de mercado hoje, tudo indica que o padrão LTE (mais especificamente o LTE-advanced) deverá ser o padrão dominante para a implementação de redes celulares 4G (o alvo de desempenho definido pela ITU na especificação IMT-advanced - que é a definição oficial de 4G - é de taxas de pico de download de 1 Gbps para usuários estacionários e 100 Mbps para usuários em movimento rápido).

Daqui em diante vou retomar (e voltar um pouco ao passado, cerca de 10 anos) o desenvolvimento da rede fixa, mas sem distingui-la mais da rede móvel. Vocês devem ter notado que discuti somente a interface de rádio da rede celular, e não falei nada sobre o chamado core da rede. Daqui em diante isto muda. No próximo artigo o assunto será a "invasão" da tecnologia TCP/IP na construção das redes fixas e móveis.

Redes de telecomunicação (8) - Telefonia celular (parte 2)

2011-09-01T18:09:00.001-03:00

Nesta parte deste artigo vamos apreciar uma das maiores "guerras religiosas" na área de telecom: a disputa pela dominância tecnológica do mercado, nos anos 90 do século XX, quando da digitalização das redes de acesso, que caracterizou a transição da primeira geração (1G) para a segunda geração (2G) da telefonia celular.

Esta foi uma época onde claramente a ITU ficou para trás no seu papel de estabelecer padrões, superada por dois polos antagônicos formados por empresas, operadoras e organizações interessadas na defesa técnica e comercial de cada um dos padrões envolvidos na disputa. Um destes polos formou-se na Europa, em torno da ETSI (European Telecommunication Standards Institute). O outro congregou-se nos Estados Unidos, com foco na EIA/TIA (Electronics Industry Alliance/Telecommunications Industry Association).

O objetivo inicial das propostas 2G era permitir compatibilidade com as redes 1G. O que foi feito, basicamente, foi superpor multiplexação no tempo (TDM) sobre a estrutura de multiplexação em frequência (FDM) típica das redes 1G (veja a primeira e a segunda parte deste artigo anterior, bem como a primeira parte deste artigo, para revisar os conceitos de FDM e TDM). Esta forma de acesso é conhecida como TDMA (Time Division Multiple Access), e está ilustrado na figura abaixo.

O canal de comunicação TDMA é, então, definido por um par de time slots, um em um dos canais de frequência de uplink, e o outro em um dos canais de frequência de downlink. A tecnologia TDMA foi adotada em dois "sabores" principais:

EIA/TIA interim standards IS-54 e IS-136, também conhecidas como D-AMPS (Digital AMPS) ou, simplesmente, TDMA (como ficaram conhecidas no Brasil);
GSM (originalmente Groupe Spécial Mobile, depois Global System fos Mobile Communications)

A tabela abaixo resume e compara as características gerais dos sistemas IS-136 (D-AMPS) e GSM.

Em paralelo com estes dois sistemas, foi desenvolvido outro, baseado na tecnologia spread spectrum. O método de compartilhamento CDMA (Code Division Multiple Access). Vou procurar explicar, simplificadamente, o funcionamento do CDMA sem recorrer a muita matemática.

O conceito fundamental que justifica o funcionamento do CDMA é a ortogonalidade. Na álgebra vetorial dois vetores a e b são ortogonais se o seu produto escalar é igual a zero.

O conceito de ortogonalidade pode ser estendido para as funções, com uma definição um pouco mais complicada. Duas funções f(x)e g(x) são ortogonais no intervalo [x1,x2] se:

Para não complicar mais a vida daqueles que não tem inclinação para a matemática vamos apenas assumir que existem famílias de funções que satisfazem a esta condição. O interessante destas funções ortogonais é que elas podem ser usadas para codificar de forma unívoca os sinais dos usuários, que são então transmitidos simultaneamente, portanto o sinal transmitido representa a soma de todos os sinais codificados dos usuários, e cada uma das funções ortogonais usadas na codificação é chamada código (code). Na recepção o código unívoco de cada usuário é aplicado sobre o sinal somado, produzindo como saída o sinal isolado daquele usuário.

Exemplos para famílias de funções ortogonais são as linhas ou colunas das matrizes de Walsh (Walsh codes) e os Gold codes (sequências pseudo-aleatórias - pseudo-random sequences). Por razões técnicas (ligadas a questões de sincronismo) os Walsh codes são usados para codificar o sinal do downlink, enquanto os Gold codes são usados para codificar o sinal do uplink.

O processo de codificação e decodificação envolvem o uso da função lógica eXclusive OR (XOR). Na codificação ela é usada sobre o sinal (com seu bit rate original) e sucessivas repetições do código alocado para aquele usuário, porém com um bit rate mais elevado, conhecido como chip rate, o que provoca o aumento de frequência e consequente espalhamento espectral (spectrum spreading) do sinal codificado. A figura abaixo ilustra este processo.

Na decodificação a função XOR é aplicada sobre o sinal superposto (somado) de todos os usuários e sucessivas repetições do código de cada usuário no mesmo chip rate usado na codificação, extraindo o sinal transmitido pelo usuário, ou zeros binários quando não há dados a decodificar.

O padrão inicial para redes CDMA foi a norma provisória EIA/TIA IS-95 e suas subsequentes revisões, baseada na especificação feita pela Qualcomm, e comercializada com o nome CdmaOne.

Podemos então resumir as três formas básicas de multiplexação usadas na rede de acesso de telefonia celular da seguinte forma:

A esta altura estamos com o cenário da "guerra religiosa" finalmente formado: das tecnologias TDMA o GSM tornou-se claramente dominante, por várias razões (técnicas e comerciais), enquanto o CdmaOne destacava-se por permitir uma melhor taxa de transmissão para usuários de dados. E os sistemas IS-136 (D-AMPS) chegaram a um beco sem saída tecnológico e de mercado.

Neste ponto da história a ITU-T especificou que características seriam desejáveis para os sistemas celulares de terceira geração (3G), no que ficou conhecido como IMT-2000 (International Mobile Telecommunications-2000). Isto provocou a coalescência dos principais concorrentes em dois organismos de padronização e lobby: o 3rd Generation Partnership Program (3GPP) com as tecnologias GSM e Wideband CDMA (WCDMA); e o 3rd Generation Partnership Program 2 (3GPP2) com a tecnologia Cdma2000.

A questão é que ninguém estava disposto a esperar uma decisão da ITU sobre qual padrão 3G deveria ser adotado. A batalha pelos corações e mentes das operadoras celulares mundo afora foi deflagrada de imediato, com ambas as partes oferecendo antecipadamente suas features capazes de conquistar a clientela.

No caso do CdmaOne, enfatizava-se o caminho natural da migração para Cdma2000, na sua versão inicial chamada 1xRTT ( 1x Radio Technology Transmission) e, logo após, evoluída para a versão 1xEV-DO (1x EVolution - Data Only). A principal característica destacada pelo 3GPP2 era a maior capacidade de transmissão de dados (taxa máxima teórica de download de 153 Kbps para o 1xRTT e 2,4 Mbps para o 1xEV-DO)

No caso do GSM tratou-se de evoluir os sistemas de transmissão de dados enquanto não havia ainda a disponibilidade efetiva da tecnologia WCDMA. Aí surgiram o GPRS (General Packet Radio Service - 60 Kbps de taxa máxima teórica de download) e o EDGE (Enhanced Data rates for GSM Evolution - 476,6 Kbps de taxa máxima teórica de download). Enfatizando também a compatibilidade com os sistemas GSM já implantados.

Vamos parar, por enquanto, neste cenário das chamadas tecnologias 2,5G (Cdma2000 1xRTT e 1xEV-DO, GSM/EDGE/GPRS), para tratar da terceira geração (3G), e da proposta IMT-advanced da ITU (que deverá ser a quarta geração - 4G) na próxima (e quiçá última) parte deste artigo.

Redes de telecomunicação (7) - Telefonia celular (parte 1)

2011-08-27T11:38:00.000-03:00

Neste artigo (em várias partes) vou tratar do surgimento e evolução das redes de telefonia celular, inicialmente como um serviço de voz, complementar ao serviço de voz oferecido pela rede fixa, e posteriormente assumindo uma dinâmica própria, e assumindo um papel até mais destacado que a telefonia fixa.

A telefonia móvel trouxe um novo problema, que não existia na telefonia fixa. Para garantir mobilidade os usuários teriam que conectar-se à rede usando enlaces de rádio. Então, como organizar o uso (isto significa essencialmente como controlar eventuais interferências) dos recursos de rádio na rede de acesso?

Para solucionar este problema foram experimentadas várias opções, mas a que se mostrou mais prática foi dividir a geografia da área a cobrir com o serviço em pedaços menores, chamados células. Dentro de cada célula uma estação transmissora/receptora de sinais de rádio é encarregada de manter comunicação com os usuários ali presentes. Esta estação é denominada Base Transceiver Station - BTS, ou, no jargão nacional, Estação de Rádio-Base - ERB.

A área de cobertura de cada célula depende de vários fatores, tais como a potência de transmissão, a topografia e o tipo de cobertura do terreno (água, vegetação rasteira, vegetação densa, edificações, etc.). Quando é feito o projeto de cobertura de uma determinada área usam-se programas de computador especializados para calcular o alcance previsto para os sinais de rádio em função dos dados conhecidos sobre o terreno e os parâmetros de frequência e potência de transmissão. Entretanto, como se costuma dizer neste ramo da engenharia, transmissão de rádio é ciência, mas recepção é bruxaria. Por isso é indispensável verificar, após a instalação, as diferenças entre a distribuição geográfica prevista e real da intensidade do sinal de rádio das BTS, e fazer ajustes para compensar os erros. Este processo é conhecido como drive test. Como a configuração do terreno pode sofrer modificações (novos prédios, demolições, reflorestamentos, deflorestamentos, aterros, terraplenagens, etc.), existe a necessidade de efetuar verificações periódicas (e ajustes) do desempenho de recepção de rádio via drive test.

O projeto de cobertura também procura manter uma certa superposição (overlapping) entre as áreas de cobertura das BTSs adjacentes, para que um usuário em movimento não encontre uma zona de "sombra" do sinal de rádio, o que provocaria a interrupção do serviço. O padrão real da cobertura é complexo, mas pode ser exemplificado de forma simplificada pela figura abaixo.

Para efeito de projeto (e para nosso consumo aqui), costuma-se usar uma representação mais simples ainda, considerando a área de cobertura das células como hexágonos regulares iguais, sem superposição, e sem espaços (gaps) entre eles, conforme o exemplo abaixo.

A qualquer momento o sinal do handset do usuário pode (e, normalmente, vai) ser recebido em mais de uma BTS. Cabe ao plano de controle da rede de acesso (vamos conversar sobre isso em outra parte deste artigo) decidir qual BTS será efetivamente utilizada pelo usuário (normalmente será aquela onde ocorre a maior potência de recepção do sinal do usuário). Quando o usuário se movimenta a potência do seu sinal recebida pelas BTSs também varia. Em algum momento o plano de controle da rede de acesso tem que decidir pela mudança da BTS onde o usuário está conectado. Este evento é chamado handoff ou handover. E pode ocorrer, basicamente, de duas formas: soft handover, quando o novo canal de comunicação é estabelecido antes do rompimento do canal antigo (make before break), ou hard handover, quando o novo canal de comunicação é estabelecido após o rompimento do canal antigo (break before make). Ambas as formas são utilizadas na prática. A possível desvantagem do soft handover é o fato de utilizar mais recursos de rádio, e o hard handover tem como desvantagem a possível percepção do momento da troca de canais pelo usuário.

Cada operadora do serviço celular utiliza (conforme as regras de acesso ao espectro de rádio em cada país) uma faixa de frequências (banda) para a transmissão do usuário para a BTS (uplink) e outra banda para a transmissão da BTS para o usuário (downlink). O conjunto destas duas bandas constitui uma portadora (carrier) para o serviço celular. Para efeito de alocação de espectro para o provimento do serviço cada país define faixas de frequência (ou bandas) para operação, normalmente identificadas por letras. Cada banda de operação pode acomodar, normalmente, mais de uma portadora. A figura abaixo ilustra sumariamente a alocação das bandas de operação (uplink e downlink) para cada uma das bandas de serviço celular no Brasil.

O que resta explicar é como ocorre o compartilhamento do acesso às bandas de uplink e downlink pelos usuários dentro da mesma célula. Historicamente a tecnologia usada para este compartilhamento separa as diversas gerações da telefonia celular. A primeira geração (1G) surgiu no início da década de 80 do século XX, e já se encontra descontinuada. Caracterizava-se pelo uso de transmissão analógica, e houveram dois padrões principais: AMPS (Advanced Mobile Phone System) e TACS (Total Access Communications System). O AMPS foi originado nos Estados Unidos, enquanto o TACS foi desenvolvido na Europa. No Japão a NTT usou um sistema semelhante ao TACS, denominado JTACS (Japan TACS).

Todos os sistemas 1G usavam multiplexação em frequência para permitir o compartilhamento de acesso no downlink e no uplink. Esta forma de acesso é conhecida como FDMA (Frequency Division Multiple Access). Embora a modulação utilizada seja FM (Frequency Modulation) e não AM (Amplitude modulation), os mesmos princípios básicos do deslocamento em frequência na multiplexação FDM que apresentei neste artigo anterior ainda são válidos.

A idéia geral do FDMA é dividir, tanto o downlink quanto o uplink, em subfaixas. Um par de subfaixas do uplink e do downlink formam um canal (channel) de acesso. O que diferencia cada um dos padrões 1G é a quantidade e largura de banda dos canais de acesso Na figura abaixo está representado o esquema geral de funcionamento do FDMA, e, logo a seguir uma tabela mostra as características principais dos padrões 1G mais utilizados.

Em uma rede de acesso FDMA, não é possível utilizar todos os canais simultaneamente em todas as células, porque existe a possibilidade de interferência entre usuários da mesma célula que estejam usando canais adjacentes em frequência, e entre usuários em células adjacentes no espaço que estejam utilizando utilizando o mesmo canal. Para resolver isso adota-se o planejamento de reutilização de frequências (frequncy reuse plan). A forma mais comum de execução deste tipo de planejamento é a divisão dos canais de comunicação em sete grupos distintos, e alocá-los a grupos de sete células adjacentes de tal forma que nunca duas células que usam o mesmo grupo de frequências são adjacentes no espaço. No exemplo abaixo cada grupo de frequências é identificado pelas letras de A a F.

Grupo básico de sete células

Cobertura geográfica com grupos adjacentes de sete células

Na próxima parte deste artigo vamos prosseguir com este assunto, chegando aos anos 90 do século XX, o processo de digitalização das redes de acesso da telefonia celular e os padrões da segunda geração (2G) da redes de acesso para telefonia celular.

Redes de telecomunicação (6) - A busca pela rede multisserviço

2011-08-17T19:39:00.000-03:00

Chegamos aos trepidantes anos 80 do século XX. Três coisas fundamentais mudaram no cenário das redes telefônicas nesta época:

O processo tradicional de padronização seguido pelo CCITT (depois ITU-T), com seus ciclos de estudos e publicação das recomendações a cada quatro anos, mostrou-se inadequado para acompanhar o ritmo de desenvolvimento de novas tecnologias, e o CCITT viu-se na situação de, cada vez mais, apenas ratificar padrões de facto, elaborados por consórcios ou grupos de interesse da indústria;
Entraram em funcionamento as primeiras redes modernas (1G) de telefonia celular;
O desenvolvimento de redes e serviços de comunicação de dados por comutação de pacotes, especialmente o surgimento da Internet com a adoção da pilha de protocolos TCP/IP pela ARPANET em 1º de janeiro de 1983, bem como o surgimento de serviços especializados como fax e videoconferência, mostrou que o futuro pertenceria a redes capazes de transportar serviços de voz, vídeo e dados de forma integrada.

Cada um destes tópicos, por si só, já rende uma boa conversa (e vou dedicar o próximo artigo desta série ao surgimento e evolução da telefonia celular). Vamos nos concentrar por enquanto na questão da evolução da rede telefônica para uma rede totalmente digitalizada e capaz de acomodar todos os tipos de serviço.

Durante os ciclos de estudos e recomendações 1981-1984 e 1985-1988 do CCITT foi formalizado o conceito de uma Integrated Services Digital Network (ISDN). Os conceitos principais estão descritos nas recomendações I.120 e I.310. A figura abaixo (retirada da recomendação I.120) mostra as diversas recomendações que tratam da descrição da ISDN.

Como vimos neste artigo anterior, nesta época a digitalização da comutação e da transmissão já estavam bem adiantadas. Então o aspecto a chamar mais atenção nas especificações da ISDN, e o primeiro a ser implantado na prática, foi a digitalização do acesso do assinante. Foram definida duas interfaces digitais de assinante: Basic Rate Interface (BRI, descrita na recomendação ITU-T I.430) e Primary Rate Interface (PRI, descrita na recomendação ITU-T I.431).

A BRI funciona sobre dois pares de fios de cobre da rede de acesso convencional e fornece dois canais de tráfego (bearer channels - B) de 64 Kbps cada um, e um canal de sinalização (data channel - D) de 16 Kbps. Por causa desta configuração esta interface também é conhecida como 2B+D, e pode ser usada para suportar simultaneamente duas chamadas de voz ou dados a 64 Kbps nos canais B mais uma conexão de dados a 16 Kbps no canal D, ou uma conexão de dados de 128 Kbps usando os dois canais B mais uma conexão de dados a 16 Kbps no canal D.

Enqunto a BRI é adequada para usuários residenciais ou pequenos negócios, a PRI é voltada para usuários de maior porte. Projetada para funcionar sobre canais T1 (Estados Unidos) ou E1 (ITU-T G.703). Neste artigo anterior tem uma descrição genérica das hierarquias de multiplexação plesiócronas T e E. Conforme o caso, a interface PRI também é chamada de 23B+D (23 bearer channels + data channel, todos de 64 Kbps, equivalente a um canal T1 de 1,544 Mbps) ou 30B+2D (30 bearer channels + data channel, mais um canal para sincronismo e alarmes, todos de 64 Kbps, equivalente a um canal E1 de 2,048 Mbps).

Embora bem articulada, o problema com a proposta ISDN foi o tempo que ela demorou para ser efetivamente implementada pelas operadoras, o que deu espaço para a fixação de uma tecnologia alternativa para linhas digitais de assinante, literalmente: digital subscriber line ou DSL.

Utilizando a faixa de frequência mais alta (acima de 25 KHz) sobre os mesmos pares de fios de cobre da rede de acesso analógica convencional os primeiros modems DSL (mais especificamente HDSL, ITU-T G.991.1) podiam oferecer comunicação de dados a 1,544 Mbps (T1) ou 2,048 (E1) Mbps, simultânea com uma conexão de voz convencional. E sem a necessidade de fazer alterações pesadas e caras no estágio de assinantes das centrais de comutação. Previsivelmente eles foram um sucesso de público e crítica, e o interesse das operadoras na implantação do modelo ISDN começou a diminuir. E os modems DSL continuaram evoluindo: ADSL, ADSL2, ADSL2+, VDSL e VDSL2.

A reação natural dos desenvolvedores de tecnologia tradicionais de telecom foi evoluir a proposição ISDN para uma rede com taxas de transmissão mais elevadas, que foi denominada Broadband ISDN (B-ISDN). O aspecto marcante da arquitetura B-ISDN é a adoção do protocolo ATM (Asynchronous Transfer Mode) para o transporte de todos os tipos de tráfego encapsulado em pequenos pacotes chamados células (figura retirada da recomendação ITU-T I.361).

Para permitir a correta segmentação e remontagem (Segmentation And Reassembly - SAR) dos diversos tipos de tráfego em células ATM e vice-versa é necessária a utilização de uma camada de adaptação ATM (ATM Adaptation Layer - AAL), conforme o modelo abaixo (retirado da recomendação ITU-T I.321).

Existem os seguintes padrões definidos para a camada AAL:

AAL1 - Serviço Constant Bit Rate (CBR) orientado a conexão e com sincronismo, para emulação de circuitos convencionais (ITU-T I.363.1);
AAL2 - Serviço Variable Bit Rate (VBR) orientado a conexão e com sincronismo, para suporte a tráfego sensível a delay, como vídeo (ITU-T I.363.2);
AAL3/4 - Serviço VBR orientado a conexão e assíncrono, para suporte a interfuncionamento de serviços de dados como X.25 e frame-relay (ITU-T I.363.3);
AAL5 - Serviço VBR orientado a conexão e assíncrono, para suporte a funcionalidades como IP over ATM - IPoATM, Ethernet over ATM, Switched Multimegabit Data Service - SMDS, e LAN emulation - LANe (ITU-T I.363.5).

O protocolo ATM ainda estabelece circuitos virtuais (permenentes ou comutados) entre os terminais que se comunicam. Um circuito virtual é identificado, em cada trecho da rede, pelo par VCI + VPI (Virtual Circuit Identifier + Virtual Path Identifier). VCs e VPs são multiplexados nos enlaces de transmissão que conectam os elementos da rede ATM, conforme as figuras abaixo (retiradas da recomendação ITU-T I.311).

Para completar o modelo B-ISDN era necessário resolver dois problemas da hierarquia de multiplexação PDH: taxas de transmissão relativamente baixas e a impossibilidade de extrair canais individuais sem ter que demultiplexar e remultiplexar todo o sinal agregado. Além disso era necessário que a nova hierarquia de multiplexação fosse agnóstica para o transporte de tráfego ATM e do tráfego legado da hierarquia PDH tradicional.

As propostas para solução destes problemas vieram em dois "sabores" que depois foram devidamente convergidos. O primeiro deles foi proposto pela Telcordia/ANSI, e chama-se Synchronous Optical Network (SONET), e o outro foi proposto na ITU-T e chama-se Synchronous Digital Hierarchy (SDH). Como ambos os sistemas encontram-se convergidos, hoje podemos falar em SONET/SDH ou SDH/SONET, conforme a preferência de cada um.

Os níveis da hierarquia de multiplexação são chamados Optical Carrier - OC (nomenclatura SONET) ou Synchronous Transport Module - STM (nomenclatura SDH).

A razão para a existência de overhead na transmissão SDH/SONET é porque os dados são estruturados em um quadro de transmissão composto de header e payload. Agora que vimos isto tudo, podemos fazer um diagrama genérico para a estrutura da rede B-ISDN.

Na figura vemos os dois elementos que compõem a mutiplexação SDH/SONET: Add-Drop Multiplexers (ADMs), responsáveis pela inserção e retirada de canais de tráfego, de múltiplas taxas, nos quadros de transmissão SDH; Optical Cross-Connects (OXCs), responsáveis pela inserção e remoção dos quadros de transmissão SDH no sinal óptico na fibra. Quando estes dois elementos são implementados em um único equipamento ele é chamado Optical Add-Drop Multiplexer (OADM). Tipicamente os OXCs (ou OADMs) são interligados formando um duplo anel, para garantir máxima resiliência a falhas.

Finalmente, por tráfego legado entenda-se agregados de tráfego PDH convencionais (tipicamente na forma de canais E1).

Tudo isto parece muito coerente. Pena que não aconteceu na prática. A hierarquia de multiplexação digital síncrona SDH/SONET alcançou grande sucesso, virtualmente substituindo a multiplexação PDH no backbone das redes das operadoras de telefonia. Já a sua penetração nos estratos de agregação e acesso foi em grande parte contida pela expansão da tecnologia Ethernet e das redes IP/MPLS. E a evolução das redes ópticas de transporte (Optical Transport Networks - OTNs) ameaça o futuro do SDH/SONET.

Já o ATM teve um relativo sucesso inicial, mas a crescente adoção das redes IP/MPLS como suporte universal de transporte para voz, vídeo e dados tornou-o obsoleto atualmente.

Como disse antes, no próximo artigo vou tratar das redes de telefonia celular. Depois disso volto para tratar da "invasão" do TCP/IP (e do MPLS e Ethernet) nas redes de telecomunicação.

Redes de telecomunicação (5) - Comunicação de dados (parte 2)

2011-08-13T19:33:00.000-03:00

Apenas para termos um posicionamento cronológico do que falamos até aqui sobre a evolução tecnológica da rede telefônica, estamos agora aproximadamente na divisa dos anos 60 e 70 do século XX (do ponto de vista dos centros mais avançados, e meados dos anos 70, se pensarmos em termos brasileiros).

No artigo anterior comentamos sobre as desvantagens econômicas do uso de circuitos dedicados da rede telefônica (comutados ou permanentes) para comunicação de dados. Ao longo dos anos 60 do século XX um novo conceito começou a ganhar força: a comutação de pacotes. Os trabalhos acadêmicos pioneiros nesta área são de autoria de Leonard Kleinrock (na sua tese de doutorado: Information Flow in Large Communication Nets - 1961, e no livro Communication Nets: Stochastic Message Flow and Delay - 1964) e de Paul Baran (nos artigos Reliable Digital Communications Systems Using Unreliable Network Repeater Nodes - 1960, e On Distributed Communications Networks - 1962).

Até esta época o uso típico de circuitos de comunicação de dados era a conexão de estações de acesso remoto a computadores em modo time-sharing (neste artigo eu apresento uma descrição da forma que o sistema operacional de um computador suporta esta forma de funcionamento), usando terminais do tipo teletipo e (depois) vídeo. A partir dos resultados obtidos por Kleinrock e Baran ganhou força a idéia de interligar diversos computadores formando uma rede, buscando aumentar a capacidade de processamento e a resiliência a sinistros (na época isto significava sobreviver a um ataque nuclear).

O que ficou claro, a partir de então, foi a vantagem da utilização de uma nova forma de multiplexação do tempo de acesso aos canais de comunicação. Em vez de cada canal de entrada ter direito a um time slice fixo e periódico do tempo do canal compartilhado (TDM), os dados a transmitir são organizados em unidades independentes chamadas pacotes (packets). Cada transmissor tem acesso exclusivo ao canal compartilhado apenas durante o tempo de transmissão dos seus pacotes (não necessariamente de forma consecutiva). Como o tamanho de cada pacote é variável, o tempo de posse do canal compartilhado não é constante, e o tempo de espera para transmissão entre pacotes consecutivos também é variável. Esta forma de multiplexação estatística tem como vantagem a possibilidade de superutilização (oversubscribing) do canal compartilhado, e como desvantagem a possibilidade de ocorrência de congestionamento caso múltiplos transmissores que competem por acesso ao canal compartilhado excedam momentaneamente a sua capacidade máxima de transmissão.

As pesquisas sobre redes de computadores tinham duas vertentes principais: uma explorava a construção de redes com abrangência geográfica limitada e altas velocidades de transmissão - as redes locais (Local Area Networks - LANs); a outra buscava formas para padronizar a interconexão de sistemas heterogêneos usando principalmente enlaces de dados, comutados ou permanentes, mapeados sobre a rede telefônica ou via satélite - as redes de longa distância (Wide Area Networks - WANs).

Da enorme variedade de tecnologias para construção de LANs nos interessa (mas só trataremos dela mais à frente) uma que foi desenvolvida no PARC e patenteada pela Xerox em 1975: Ethernet. Ela passou a ser amplamente conhecida a partir do artigo Ethernet: Distributed Packet Switching for Local Computer Networks, publicado por Robert Metcalfe e David Boggs. Em 1980, por influência de Metcalfe, a Digital Equipment Corporation (DEC), a Intel e a Xerox publicaram um padrão conjunto (chamado DIX) para implementação de redes Ethernet no documento The Ethernet, A Local Area Network. Data Link Layer and Physical Layer Specifications. Em fevereiro de 1980 o IEEE iniciou o projeto 802 para estabelecer padrões para LANs. A especificação DIX foi apresentada ao IEEE como candidata a padronização, e teve o seu padrão (IEEE 802.3) publicado em 1985.

Estamos mais interessados, no momento, nas redes WAN baseadas em comutação de pacotes. A primeira demonstração prática do conceito de comunicação de dados na forma de comutação de pacotes foi feita em 1965 por Donald Davies no National Physical Laboratory (NPL), na Inglaterra. Em 1969 foi implantada a primeira versão da ARPANET, com apenas quaatro computadores conectados. O diagrama abaixo é uma cópia de um desenho (manuscrito) feito naquela época descrevendo a topologia da rede.

Os computadores estão representados pelos retângulos, e os elementos de comutação de pacotes (que chamaríamos, hoje em dia, de roteadores) pelos círculos. Os comutadores de pacotes eram chamados Interface Message Processors (IMPs) e foram construídos pela Bolt, Beranek and Newman (BBN). Os enlaces de dados entre os IMPs eram circuitos dedicados de comunicação de dados sobre a rede telefônica, e os modems suportavam uma taxa de transferência de 50 Kbps. A fotografia abaixo mostra Leonard Kleinrock e a primeira versão do IMP, desenvolvida por ele.

Nesta encarnação tecnológica a ARPANET cresceu até 1983, quando foi introduzida a pilha de protocolos TCP/IP e ela tornou-se a primeira subnet do que passaria a ser conhecida como a Internet. Em 1971 a ARPANET já cobria os Estados Unidos de costa a costa.

E a topologia dos nós conectados, em 1977, era como na figura abaixo.

Com a ocorrência destas evoluções tecnológicas era apenas questão de tempo que surgissem propostas para a criação de redes públicas para comunicação de dados baseadas em comutação de pacotes. A idéia comercial básica era reduzir significativamente o componente distância no custo de conexões de dados comutadas ou permanentes, tirando partido da multiplexação estatística inerente à comutação de pacotes.

Em 1976 a recomendação X.25 da ITU-T (então CCITT) foi publicada - versão mais recente pode ser baixada em PDF aqui. Esta foi a primeira proposta a formalizar as funcionalidades da rede em camadas (layers), ainda antes da edição do modelo de referência OSI, e as camadas do modelo de rede X.25 mantém uma correspondência muito grande com as três camadas inferiores do modelo de referência OSI.

Os elementos da rede X.25 são os equipamentos terminais de dados (Data Terminal Equipment - DTE) e equipamentos de comunicação de dados (Data Communication Equipment - DCE). A funcionalidade DTE é implementada no terminal do usuário, existindo a previsão de terminais incapazes de executar a função DTE conectarem-se através de um Packet Assembler-Disassembler (PAD). Neste caso a conexão entre o PAD e o DCE local é definida pela recomendação ITU-T X.28, e a conexão entre o PAD e o DCE remoto é definida pela recomendação ITU-T X.29. A funcionalidade do próprio PAD é definida na recomendação ITU-T X.3) O DCE é o responsável por dialogar com os DTEs conectados a ele e encaminhar adiante os pacotes de dados. Não existe padronização formal para a comunicação DTE-DTE, exceto no caso da interface entre domínios administrativos X.25 diferentes (o que, geralmente, significa a interface entre operadoras) regulada pela recomendação ITU-T X.75, onde os DCEs de borda dos domínios X.25 que se comunicam são denominados Signaling Terminal Equipment (STE).

As conexões lógicas estabelecidas fim a fim (DTE-DTE) são chamados circuitos virtuais, e podem ser estabelecidos de forma comutada (Switched Virtual Circuit - SVC) ou permanente (Permanent Virtual Circuit - PVC). Como dá para perceber, velhos hábitos são difíceis de romper. Estes tais de circuitos virtuais ainda vão nos seguir até os dias de hoje. As conexões físicas DCE-DCE são mapeadas sobre a estrutura de transmissão, como circuitos permanentes de comunicação de dados (veja o conceito disso no artigo anterior).

O próximo passo na evolução dos serviços de comunicação de dados foi a padronização da arquitetura frame-relay pelo Frame-Relay Forum (hoje incorporado dentro do Broadband Forum), pelo comitê T1 da ANSI (que foi desativado em 2004) e pela ITU-T. O frame-relay foi desenvolvido para ser uma solução mais leve que o X.25, especialmente onde os enlaces físicos fossem de maior confiabilidade. Além disso o frame-relay oferece apenas circuitos virtuais, SVC e PVC, no nível da camada 2 do modelo de referência OSI, servindo como transporte agnóstico para qualquer protocolo de camada 3, ou mesmo para outros protocolos de camada 2. Os documentos que definen os padrões do frame-relay são:

Normas ANSI T1.606, T1.617 e T1.618 (incorporados nas recomendações ITU-T);
Recomendações ITU-T I.233, Q.922 e Q.933;
Implementation Agreements do Frame-Relay Forum (vários documentos, disponíveis para download nesta página do Broadband Forum).

A terminologia do frame-relay é muito semelhante à do X.25. Continuam os DTEs e DCEs, continuam os SVCs e PVCs, e os antigos PADs agora são chamados FRADs (Frame-Relay Access Device). As novidades são a possibilidade de sinalização explícita de congestionamento e marcação de tráfego elegível para descarte em caso de ocorrência de congestionamento.

Muitas operadoras ainda oferecem serviços X.25 e frame-relay. Então podemos atualizar a figura final do artigo anterior para incluir, além do serviço de voz e dos circuitos de comunicaçao de dados comutados e permanentes, os serviços de dados X.25 e frame-relay. Isto basicamente mostra a topologia típica da rede de uma operadora de telefonia fixa nos anos 80 do século XX.

Toda esta conversa sobre comunicação de dados puxa, naturalmente, o próximo passo da evolução da rede telefônica, na busca de tornar-se uma rede integrada multisserviço, e não um "empilhamento" de redes de serviços diferentes mapeadas sobra a infraestrutura básica de transmissão. No próximo artigo trataremos deste assunto.

Redes de telecomunicação (4) - Comunicação de dados (parte 1)

2011-08-09T11:29:00.000-03:00

A história do uso da rede física de telefonia para a transmissão de dados tem dois capítulos distintos: o uso de circuitos comutados ou permanentes da rede telefônica como enlaces entre usuários de comunicação de dados; e a construção de redes de serviço de comunicação de dados por comutação de pacotes que compartilham o uso dos enlaces de transmissão da rede telefônica. A conversão da própria rede telefônica para o modelo de comutação de pacotes, e não mais de circuitos, será assunto para mais adiante.

Os primeiros usuários de comunicação de dados sobre a rede telefônica não foram computadores, mas máquinas de telégrafo e teletipo (TELEX). E elas evidenciaram um problema, que ficou ainda mais agudo com a digitalização da comutação e da transmissão.

Sinais de entrada discretos no tempo geram espectros de frequência muito amplos, e isso cria severos problemas de distorção do sinal durante a transmissão, além de, com a transmissão digitalizada, os circuitos pressuporem que o sinal de entrada está todo contido na faixa de 0 a 4 KHz (veja os dois artigos anteriores, aqui e aqui, para a apresentação destes conceitos).

A soluçao para isso foi introduzir dispositivos capazes de representar o sinal digital de entrada via modulação de um sinal analógico compatível com a banda passante da rede telefônica: os modems (MODulator/DEModulator).

Modulação significa que vamos fazer uma ou mais características da portadora variar proporcionalmente ao sinal de entrada. As características passíveis de uso são: amplitude, frequência e fase da portadora.

A amplitude e a frequência são fáceis de reconhecer. A fase é um pouco mais sutil. Considere dois sinais de mesma frequência. Se os dois estão "alinhados" no tempo, com seus pontos de máximo, mínimo e zeros de amplitude ocorrendo simutaneamente, então eles são ditos em fase, ou coerentes. Se este alinhamento não existe, então eles são ditos fora de fase, ou incoerentes. O tempo de deslocamento entre dois pontos correspondentes (máximo, mínimo ou zero) dos dois sinais é a diferença de fase (phase shift), que pode ser expressa, também, como um ângulo.

Na primeira parte do artigo sobre multiplexação e digitalização mostrei como fazer modulação em amplitude (AM) de um sinal analógico. A diferença, no caso de sinais de entrada digitais, é que a característica da portadora a ser modulada (amplitude, frequência ou fase) varia entre valores discretos. O problema é que, para poder discriminar corretamente na recepção, os níveis discretos sucessivos precisam de um afastamento mínimo no tempo para minimizar a probabilidade de erro de decodificação. Isto é uma consequência do Teorema de Shannon-Hartley:

Conforme a característica da portadora modulada pelo sinal de entrada, os modos básicos de modulação de sinais digitais são conhecidos como:

ASK (Amplitude-Shift Keying) - modulação da amplituda da portadora;
FSK (Frequency-Shift Keying) - modulação da frequência da portadora;
PSK (Phase-Shift Keying) - modulação da fase da portadora.

Reparem que, nos exemplos da figura acima, temos uma transição de estado correspondente a cada bit. Ou seja: o baud rate da portadora modulada é igual ao bit rate do sinal de entrada. Considerando que a banda passante do canal e a relação sinal/ruído na recepção não possam ser indefinidamente aumentados, como conseguir transportar bit rates mais elevados?

A solução é aumentar o número de estados possíveis para a portadora modulada, e associar um conjunto de bits a cada um destes símbolos. A maneira mais comum de executar isso é através da modulação em quadratura de amplitude e fase (QAM - Quadrature Amplitude Modulation). São usadas duas portadoras de mesma frequência, em quadratura (diferença de fase de pi/4 rad = 90°), e cada portadora transporta um valor discreto para, respectivamente, a parte real e a parte imaginária de um número complexo (o símbolo) que representa um conjunto de bits do sinal de entrada.

Os exemplos abaixo mostram as constelações de símbolos para 8-QAM (3 bits/símbolo) e 16-QAM (4 bits/símbolo).

O bit rate transmitido é igual a três vezes o baud rate no caso do 8-QAM, e quatro vezes o baud rate no caso do 16-QAM. E não é incomum encontrarmos constelações ainda maiores: 32-QAM, 64-QAM, 128-QAM, 256-QAM, ...

Os padrões para modems que usam circuitos de voz para interconexão (voice modems) estão publicados na série V de recomendações da ITU-T. Os mais significativos são:

A modulação PCM (Pulse-Coded Modulation, recomendação ITU-T G.703) foi apresentada no artigo anterior desta série. A velocidade de transmissão também pode ser aumentada pelo uso de algoritmos de compressão integrados ao modem. Com o algoritmo BTLZ (British Telecom Lempel-Ziv) especificado na recomendação ITU-T V.42bis usado em conjunto com modems V.90 pode-se atingir até 220 Kbps de bit rate no download, a depender do tipo de dado transmitido (texto simples, imagens, sons ou dados já comprimidos, em ordem decrescente de eficiência na compressão). Analogamente o algoritmo LZJH (Lempel-Ziv-Jeff-Heath) da recomendação ITU-T V.44, usado em conjunto com modems V.92 pode-se atingir até 320 Kbps de bit rate no download, também dependendo do tipo de dado transmitido.

Não vou tratar agora nem dos modems de banda larga (xDSL) nem dos modems para conexões de dados sobre redes de acesso celulares. Isto fica para outra ocasião. Para encerrar esta parte precisamos apenas entender como é feito o encaminhamento do circuito de comunicação de dados, comutado ou permanente, através da rede telefônica (acesso, comutação e transmissão). Observe a figura abaixo.

As "caixas" pontilhadas representam os prédios da operadora de telefonia. Dentro deles temos as centrais de comutação (as caixinhas com um X estilizado dentro); bancos de conversores analógico-digital (e vice-versa) e os multiplexadores PDH (os triângulos).

A linha pontilhada verde representa um circuito de dados comutado (discado, ou dial-up). Para estabelecer um circuito deste tipo é necessário a existência de aparelhos telefônicos (explícitos ou não) nas duas pontas do circuito. O seu estabelecimento é feito como uma chamada telefônica normal, que é encaminhada através das centrais de comutação. Uma vez estabelecido o circuito de voz, os modems assumem o controle e enviam o sinal digital modulado através do circuito. Como estamos considerando que a comutação e a transmissão da rede já foram digitalizadas, é necessária a conversão do sinal de áudio analógico gerado pelos modems em sinal digital PCM. Isto é feito por conversores A/D integrados com as portas de acesso dos assinantes na central de comutação.

A linha pontilhada marrom representa um circuito de dados permanente. É chamado assim porque ele persiste na rede, mesmo se os modems das pontas estiverem desligados, ao contrário do que ocorre com um circuito comutado, que é desfeito sempre que qualquer das duas pontas seja desligada, e tem que ser renegociado a cada vez que for estabelecido.

Esta persistência dos circuitos permanentes é obtida por configuração manual (dos modems, conversores A/D e MUXes) e interconexão física dos equipamentos envolvidos (dos modems, através da rede de acesso até uma porta de conversos A/D, da porta de saída do conversor A/D até uma porta de entrada do MUX e entre as portas de saída dos MUXes), criando um canal permanente de interconexão entre os modems.

O problema é que estas formas de estabelecimento de circuitos para comunicação de dados ficam caras para o assinante. No caso dos circuitos comutados, paga-se pelo tempo de conexão, como em uma chamada telefônica comum (e com os devidos acréscimos se a chamada for de longa distância, nacional ou internacional). E no caso dos circuitos permanentes a operadora estabelece um preço que leva em conta a receita cessante de voz que ele presumivelmente tem por alocar aquele recurso permanentemente para uma única conexão.

Isto estimulou o nascimento de novas tecnologias dedicadas à construção de serviços dedicados à comunicação de dados em paralelo com a rede telefônica tradicional. Mas este é o assunto da próxima parte deste artigo.