Balanceamento de Chamadas VoIP H.323 para a Rede de Telefonia Pública

Transcrição

1 Balanceamento de Chamadas VoIP H.323 para a Rede de Telefonia Pública Anderson A. Albuquerque, Paulo H. de A. Rodrigues Núcleo de Computação Eletrônica - Departamento de Ciência da Computação/IM Universidade Federal do Rio de Janeiro (NCE/UFRJ DCC/IM/UFRJ) * Caixa Postal Rio de Janeiro RJ Brasil Laboratório de Voz Sobre IP Núcleo de Computação Eletrônica. andersonaa@posgrad.nce.ufrj.br, aguiar@nce.ufrj.br Abstract. A distributed call load balancing algorithm for routing H.323 VoIP calls to the PSTN within the fone@rnp scenario, where more than one institution can complete a call, is presented. The algorithm takes in consideration all operational limitations of RNP H.323 architecture and uses the fraction of externals calls to the number of gateway voice channels not occupied by internal calls as the optimizing metrics. Simulations with different scenarios show algorithm efficacy under varying internal VoIP traffic load. The algorithm adoption in the fone@rnp service is been evaluated. Resumo. Um algoritmo distribuído para balanceamento de chamadas H.323 destinadas à rede pública de telefonia dentro do cenário do serviço fone@rnp, é apresentado. São respeitadas as limitações operacionais da arquitetura H.323 da RNP, onde várias instituições interconectadas a um POP completam chamadas para uma mesma cidade. É utilizada a métrica representada pela fração de chamadas externas em andamento sobre o número de canais de voz não ocupados com chamadas internas para balanceamento. Simulações com diferentes cenários comprovam a eficácia do algoritmo frente a diferentes níveis de utilização interna de VoIP nas instituições. Seu uso no serviço fone@rnp está sendo avaliado. 1. Introdução A estrutura de rede da RNP (Rede Nacional de Ensino e Pesquisa) possui pontos de presença (POP-RNP) em algumas cidades brasileiras, como mostrado na Figura 1, onde se interligam instituições de ensino, pesquisa ou mesmo redes. * Suporte parcial do projeto VoIP4ALL da RNP. Paulo Rodrigues é analista do NCE e professor do DCC. Anderson Albuquerque é mestrando do Programa de Pós-Graduação em Informática do NCE/DCC.

2 A RNP oferece hoje para as instituições integrantes da sua rede o serviço fone@rnp, que implementa a transmissão de voz sobre IP, sendo utilizada a sinalização H.323 [1] do ITU-T (International Telecommunication Union - Telecommunication) para encaminhamento de chamadas interinstitucionais. Dentro do padrão H.323 existem alguns elementos essenciais como o gatekeeper (GK), que recebe chamadas de terminais H.323, e o gateway de voz, que interfaceia o PBX (Private Branch exchange) com a rede. O GK é responsável pela autorização, controle de admissão e estado das chamadas, podendo atuar como proxy de mídia e sinalização. Os terminais H.323 podem ser telefones IP em hardware ou software, sendo que tanto os terminais H.323 como os gateways de voz têm que se registrar num gatekeeper. Estes elementos se comunicam com uso da arquitetura TCP/IP, podendo estar conectados em qualquer ponto de uma rede local ou backbone IP. Um exemplo de topologia é mostrado na Figura 1, onde as instituições conectadas ao POP-RNP1 e pertencentes ao serviço fone@rnp são capazes de encaminhar chamadas VoIP para a rede de telefonia fixa comutada (RTFC) da cidade, via PBX. Uma chamada originada em outra cidade e destinada ao código de área da cidade do POP-RNP1 é roteada até este POP e depois encaminhada a um dos gatekeepers existentes, o qual irá repassá-la ao gateway, e esse, por sua vez, ao PBX. Gateways com interface E1 ISDN (Integrated Services Digital Network) conectam a troncos digitais do PBX e são capazes de suportar 30 conexões de voz simultâneas, enquanto que a interface FXO (Foreign exchange Office), usada para conexão a um ramal analógico do PBX, possibilita o estabelecimento de apenas uma única chamada telefônica. Cidade atendida pelo POP-RNP 1 RTFC PBX PBX PBX 2xFXO Gateway VOIP/PBX E1 ISDN Gateway VOIP/PBX 4xFXO Gateway VOIP/PBX Gatekeeper H.323 Gatekeeper H.323 Gatekeeper H.323 Rede Instituição 1 Rede Instituição 2 Rede Instituição N POP-RNP 3 Roteador POP-RNP 1 Roteador Rede RNP POP-RNP 2 Roteador Figura 1. Interconexão de Instituições do serviço fone@rnp ao POP-RNP

3 Como a quantidade de canais disponíveis nos gateways de voz é limitada, o aumento do número de usuários com a expansão do serviço fone@rnp poderá gerar uma demanda de tráfego muito alta para ser atendida pelos gateways existentes. Quando vários GKs receberem, ao mesmo tempo, um pedido para estabelecimento de chamada com a RTFC, o GK que responder primeiro à solicitação será aquele que receberá a chamada. Esse procedimento simples da sinalização H.323 pode levar a um uso ineficiente dos gateways de voz, repassando as chamadas sempre para uma mesma instituição, provocando o congestionamento de seu gateway, e, como conseqüência, o não completamento da chamada, ainda que existam canais livres para comunicação em outras instituições da mesma cidade. Uma chamada encaminhada para um gateway VoIP/PBX que foi originada em outra instituição será denominada chamada externa; a chamada interna será aquela originada na rede da própria instituição. Caso um gateway esteja com todos os canais ocupados, naquele momento o seu PBX é inalcançável. É importante ressaltar que, quando todos os gateways de uma cidade estiverem saturados, sem canais livres, chamadas externas e internas para a cidade não serão completadas e serão descartadas. Além dessa, outras situações podem contribuir para que uma chamada não seja completada, como a ocorrência de falhas na rede local de pelo menos uma das instituições envolvidas na chamada, problemas com elementos VoIP do serviço fone@rnp ou das instituições envolvidas na chamada, dentre outras. A saturação numa instituição poderá ser contornada com o aumento do número de canais de voz com o PBX, assumindo que a instituição possa absorver o volume de tráfego VoIP pretendido. Todavia, o compartilhamento dos recursos das várias instituições de uma mesma cidade seria uma solução mais adequada. O balanceamento de chamadas tem por objetivo distribuir as chamadas entre os vários gateways, segundo alguma métrica. Com isso, uma diminuição na probabilidade de chamadas não completadas por saturação pode ser alcançada, além de haver a possibilidade de equilíbrio de custos telefônicos, relativos ao fone@rnp, entre as instituições. Cabe aqui lembrar que chamadas do serviço fone@rnp são completadas para a rede pública de telefonia de forma opcional pelas instituições, não sendo um requisito mandatório. Pela especificação do serviço fone@rnp, o GK deve funcionar tanto em modo proxy de mídia como em modo proxy de sinalização, o que obriga toda a sinalização e a mídia envolvida numa chamada a passar pelo GK, ou seja, clientes envolvidos em uma chamada não podem se comunicar diretamente. Essa configuração do GK atende a requisitos de segurança e implantação de QoS. Dessa forma, uma chamada VoIP entre instituições diferentes primeiro passa pelos seus gatekeepers antes de ir para o gateway. Quando uma instituição opera mais de um gateway com o PBX, o gatekeeper precisa controlar o encaminhamento das chamadas, evitando repassar chamadas para gateways sem canais livres. No serviço fone@rnp, o gatekeeper utilizado é o GNU Gatekeeper (GnuGk) 1, e o balanceamento entre gateways pode ser realizado com a versão do Gatekeeper GnuGk, que possui recursos para isso. Mas, para balancear o encaminhamento de chamadas entre os gatekeepers não existe uma solução a priori, e tanto algoritmos centralizados como distribuídos podem ser utilizados. 1 Site oficial do Gatekeeper GnuGk, que foi consultado em dezembro de 2005.

4 No algoritmo centralizado, existe uma entidade central [3] que precisa receber atualizações das métricas a serem utilizadas pelo algoritmo de decisão [3], e ser consultada antes do encaminhamento de uma chamada, o que provoca um atraso adicional para completamento da chamada. As informações precisam ser sincronizadas com freqüência na entidade central [8], evitando erros na tomada de decisão do algoritmo. Com a escalabilidade do serviço VoIP é inevitável que as consultas tendam a crescer [8], provocando um aumento de tráfego na rede [8] em torno deste ponto de decisão e a necessidade de aumento do poder computacional desta entidade para realizar a tomada de decisão em tempo hábil. Nesse tipo de algoritmo, a entidade central é um ponto de falha [3], que pode ter problemas no seu funcionamento ou na comunicação com a rede. Além disso, o atraso para a tomada de decisão pode ser alto, o que é crítico para esta aplicação de tempo real. A complexidade de uma arquitetura centralizada [8] é também um ponto negativo. No algoritmo distribuído cada elemento gerencia os seus próprios recursos [4], baseando-se em informações locais. Quando são utilizadas informações de outros elementos para viabilizar o funcionamento do algoritmo, ele é classificado como global [3]. Neste tipo de algoritmo não existe um elemento central a ser consultado, e o ponto de falha local é eliminado. Um ponto que deve ser levado em consideração é a escalabilidade do algoritmo distribuído [3, 4], importante em serviços onde a sua utilização é crescente. Levando em consideração o que foi exposto, a implementação de um algoritmo distribuído, que considere as limitações e versatilidades dos elementos da arquitetura H.323 no serviço fone@rnp, parece ser uma decisão conveniente. Neste artigo, uma proposta de algoritmo distribuído de balanceamento de chamadas para o cenário do serviço fone@rnp é apresentada. O algoritmo se aplica a qualquer situação onde a aceitação de chamadas depende do retorno de mensagens enviadas de um ponto central, como com DGK (Directory GK), em H.323. Situação semelhante também ocorre com a sinalização SIP (Session Initiation Protocol) [9], quando há múltiplos pedidos de estabelecimento de chamadas ( fork ) a partir de um servidor Proxy. Portanto, o algoritmo não fica restrito à topologia do serviço fone@rnp. O artigo está divido em 5 seções. Na seção 2, são apresentados aspectos básicos sobre VoIP, necessários para o entendimento da proposta. Na seção 3, o algoritmo proposto neste artigo é explicado, e os resultados de simulação são mostrados na seção 4. Finalmente, são apresentadas as conclusões e trabalhos futuros na seção Aspectos básicos sobre VoIP Nesta seção são apresentados aspectos básicos sobre VoIP que são importantes para o entendimento do funcionamento do serviço fone@rnp e do algoritmo proposto. No ambiente H.323, o servidor gatekeeper realiza a tarefa de autenticação dos clientes H.323 utilizando um nome de usuário e uma senha. Um cliente registrado recebe um identificador numérico único num determinado código de área, que é chamado de número E.164. No serviço fone@rnp os quatro primeiros números identificam uma instituição e os quatro seguintes identificam um usuário. Um usuário pode ser alcançado discando 0 <código de área> <número E.164>.

5 Toda entidade H.323 registrada em um gatekeeper pertence a sua zona administrativa. Dessa forma, o gateway VoIP/PBX também precisa estar registrado para fazer parte da zona administrativa, e o gatekeeper permite que o gateway possa receber chamadas com destino ao PBX ou à RTFC, através dele. Quando um cliente H.323 deseja realizar uma chamada, ocorre uma sinalização entre ele e o seu gatekeeper, onde primeiro é enviada uma mensagem chamada ARQ (Admission Request), que solicita a admissão da chamada, informando o número E.164 de destino da chamada. O gatekeeper poderá retornar uma confirmação da chamada, através de um ACF (Admission Confirm), ou um ARJ (Admission Reject), rejeitando a chamada. Caso o número E.164 de destino não esteja registrado no GK, uma lista de vizinhos é consultada, permitindo o repasse do ARQ, e para isso é utilizada a primitiva de sinalização LRQ (Location Request). A sinalização envolvida no processo de consulta a GKs vizinhos, é exemplificada na Figura 2. Nessa figura, o Terminal A, chamador, é quem irá iniciar uma solicitação de chamada; o Terminal B, chamado, irá receber o pedido. Além disso, como é mostrado na Figura 2 os gatekeepers envolvidos estão em modo proxy de sinalização, pois os Terminais A e B não enviam sinalizações entre si diretamente. Na explicação que se segue, os números entre parênteses referem-se às mensagens de sinalização identificadas na Figura 2. Quando uma chamada é solicitada através da ARQ (1), o gatekeeper (GK Routed A) irá verificar se o usuário de destino está registrado nele, e, caso não esteja, consultará os seus vizinhos. No cenário na Figura 2 existe apenas um vizinho contatado, que é o DGK. Figura 2. Processo de localização utilizando o DGK A consulta de vizinhos no serviço fone@rnp é realizada enviando um pedido de localização LRQ (Location Request) (2) para o DGK da RNP. No pedido de localização o LRQ possui o número E.164 do terminal chamado e o endereço do gatekeeper que originou a solicitação da chamada. O DGK irá localizar o GK que atende o número E.164 de destino em sua configuração interna, e, nessa busca, são

6 utilizados o código de área e o prefixo E.164 do telefone IP. Caso o DGK não localize pelo menos um GK que atenda o prefixo E.164, será retornada uma mensagem de rejeição da chamada, LRJ (Location Reject) (3 ), para o GK que originou o pedido de localização enviado ao DGK. Uma vez que um ou mais GKs de destino tenham sido localizados, uma mensagem LRQ (3) será repassada para eles, e o próximo passo será cada servidor contatado pelo segundo LRQ (no exemplo, o GK Routed B) enviar um LCF (Location Confirm) (4), permitindo ao GK originador iniciar o estabelecimento da chamada através do envio de uma mensagem SETUP (6, 7 e 8). Quando um LRQ ao DGK não tem sucesso, a seqüência de mensagens na Figura 2 é ARQ (1), LRQ (2), LRJ (3 ) e ARJ (4 ). A seqüência ARQ (1), LRQ (2), LRQ (3) e LCF (4) representa um LRQ ao DGK com sucesso. O recebimento do SETUP (8) pelo terminal B provoca um pedido de admissão ARQ (9) ao GK de sua zona administrativa. Assim como a mensagem ACF (5) informa ao cliente chamador (Terminal A) que a chamada foi admitida, a mensagem ACF (10) confirma a admissão ao cliente Terminal B. Todos os GKs que respondem com LCF são denominados vizinhos daquele que fez a solicitação ao DGK. Na Figura 2, o GK Routed B é um dos vizinhos do GK Routed A. No serviço fone@rnp, um gateway VoIP/PBX que pertencesse à zona administrativa B, Figura 2, estaria registrado no gatekeeper GK Routed B. Caso o gateway fosse o destino da chamada, ele se comportaria como o Terminal B, ou seja, a chamada seria encaminhada para o gateway através do gatekeeper GK Routed B. Se a instituição zona administrativa B tivesse mais de um gateway, o seu gatekeeper poderia fazer o balanceamento entre esses gateways, utilizando recursos disponíveis no gatekeeper GnuGK versão , que foi citado na seção 1. Assim, é possível sempre considerar uma zona administrativa (ou instituição) como tendo apenas um gateway VoIP/PBX, que possui a soma das capacidades de canais dos gateways dessa zona administrativa. Quando existem múltiplos GKs em uma região com capacidade de encaminhar chamadas a um mesmo prefixo E.164 da RTFC, o LCF que chegar primeiro ao GK chamador indicará para qual GK a chamada será encaminhada. Assim, esse GK intermediará a chamada que será encaminhada para o seu gateway VoIP/PBX, que a aceitará se possuir canais de voz disponíveis, caso contrário a chamada será perdida. Qualquer LCF que chegue ao iniciador da chamada após o primeiro não será considerado, ou seja, GKs que tiverem os seus LCFs desconsiderados não irão receber o SETUP (7), que é enviado apenas para o GK que enviou o primeiro LCF (4) recebido pelo GK chamador. O controle do atraso para envio do LCF poderá determinar quem terá maiores chances de receber a chamada. Assim, um gatekeeper pode provocar um atraso adicional no envio do LCF, quando for desejável que ele não receba a chamada. 3. O Algoritmo de Balanceamento Para evitar que o gatekeeper mais próximo (em termos de atraso) do POP sempre receba as chamadas destinadas à cidade, um algoritmo de balanceamento é necessário. Encaminhar as chamadas sempre para uma mesma instituição não é desejável, porque o seu gateway ficaria mais sobrecarregado, do ponto de vista de ocupação de canais, além de onerar o custo telefônico de chamadas locais da instituição. Um algoritmo de

7 balanceamento que nos traga alternativa de encaminhamento é fundamental. O da Figura 1 é aquele em que o algoritmo irá atuar. cenário O DGK, como mostrado na Figura 2, é utilizado para localizar os GKs de instituições que podem encaminhar chamadas com um determinado prefixo E.164 destino. No fone@rnp, uma zona administrativa pode ter vários GKs para encaminhamento de chamadas à telefonia pública da cidade, e, nessa situação, cada GK será informado da tentativa de uma chamada pela primitiva LRQ, que possui informações como o número E.164 destino e o endereço do GK originador da chamada. Cada gatekeeper que receber este LRQ e que tiver gateways com canais disponíveis com PBX responderá com um LCF, que confirmará sua disponibilidade de receber a chamada. Todavia, a chamada será encaminhada para o GK do primeiro LCF que chegar. Os outros LCFs não serão considerados, e inclusive os seus gatekeepers não serão informados que a chamada foi enviada para outro. Mesmo que houvesse uma falha, que impedisse o início da chamada, um outro GK não seria contatado, e a tentativa de estabelecimento dessa chamada não ocorreria, sendo a chamada descartada. O gatekeeper que irá receber a chamada é determinado pelo atraso sofrido pelo LCF, e essa premissa será utilizada pelo algoritmo, a fim de influenciar qual gatekeeper irá receber a chamada destinada à RTFC. A idéia principal do algoritmo é trabalhar com atrasos no envio do LCF, de modo a permitir que ocorra uma distribuição balanceada das chamadas entre os gatekeepers que completam chamadas para uma mesma cidade. Na Figura 3 é mostrado um diagrama da sinalização envolvendo dois gatekeepers que podem encaminhar chamadas para a RTFC, porém relembrando que isso é realizado através dos seus gateways VoIP/PBX. A Figura 3 mostra qual percurso influenciaria no atraso dos LCFs. Entre o PBX chamador e o POP RNP 1, onde estão os gatekeepers que podem encaminhar a chamada, não existe diferença no percurso da sinalização, mas o tempo de ida e volta (RTT ou Round Trip Time) entre o POP-RNP e os GKs B e C são diferentes. Esta diferença de tempo é básica para o algoritmo, pois é determinante de quem terá sucesso em ter seu LCF chegando primeiro. Figura 3. Percursos envolvidos na localização dos gatekeepers Para balancear as chamadas bastará adicionar atrasos no envio do LCF. O atraso adicional deverá ser função de uma métrica que leve em conta a quantidade de canais de

8 voz livres e o número de chamadas externas já sendo atendidas pela instituição. Quando a quantidade de canais livres diminui, o GK deve atrasar um pouco mais o envio do LCF para diminuir sua probabilidade de ser escolhido para receber a chamada, evitando assim congestionar mais ainda o seu sistema. A ordem de grandeza desses atrasos não pode gerar um atraso para o recebimento do LCF no GK originador da ordem de minutos, pois isso causaria a desistência da chamada por timeout na sinalização H.323. Na Figura 3, caso o LCF do GK B receba um atraso adicional, e chegue no GK A após o LCF do GK C, o GK B não receberá a chamada, que será enviada para o GK C. No algoritmo, o atraso para envio do LCF por um GK i será dependente da utilização U(GK i ), dada por: U X i ( GKi ) = Ui = (1), Ci Yi Esta utilização é a fração de chamadas externas em andamento sobre o número de canais de voz não ocupados com chamadas internas. Na fórmula (1), C i representa capacidade de encaminhar chamadas simultâneas, sendo a soma das capacidades dos gateways conectados ao GK i ; X i é o número de chamadas externas em andamento; e Y i é o número de chamadas internas em andamento. Além disso, o valor de i indica o GK para o qual a utilização está sendo calculada. Temos sempre X i C i Y i. Quando todos os canais de voz estiverem ocupados, C i = Y i + X i, e o gatekeeper não retornará LCF, pois não pode mais receber chamadas. No caso de C i = Y i e X i = 0, quando todas as chamadas em andamento são internas, a utilização ficará indeterminada e será assumido o valor 1. A equação (1) foi escolhida por representar simples e adequadamente o compromisso voluntário de cada instituição de completar chamadas externas, e caso a utilização fosse calculada segundo uma outra fórmula, isso não afetaria o algoritmo em si, mas apenas a prioridade ou ordem de recepção das chamadas num determinado contexto de chamadas internas e externas. Seja um POP com n instituições conectadas, onde GK 1 é o GK mais próximo, e GK n é o mais distante. O POP é o ponto comum de passagem das primitivas de sinalização com os GKs chamados, seja elas provenientes do DGK ou do GK chamador. Sejam: τ i, o atraso unidirecional entre o POP e o GK i ; τ ni = τ n τ i, a diferença de atraso ao POP entre GK n e GK i ; C, a capacidade máxima de canais de voz em um determinado GK; LCF i, o location confirm emitido pelo GK i ; D i (U i ), o atraso para envio do LCF i em função de U i. Quando GK i atinge uma determinada utilização U i = A < 1, o algoritmo forçará GK i a se alinhar com GK n, ou seja, LCF i será atrasado de um valor D i de modo a chegar simultaneamente com LCF n ao POP, iniciando o processo de balanceamento entre o GK i e GK n. Para isso, é preciso ter D i (A) = T i = 2 τ ni, função da topologia. D i (A) será designado por Ti, por simplicidade. O algoritmo calcula D i segundo a fórmula Ti. U i Di ( U i ) = (2), A

9 fazendo com que o atraso varie linearmente com a utilização. Esta dependência linear é suficiente e adequada, como será mostrado na seção 4. Quando a utilização for 1, o atraso sofrido será de T i /A, como indicado no gráfico da Figura 4, que representa a equação (2). Com U i < A, i, GK n certamente não recebe chamadas, pois elas são enviadas a algum GK mais próximo do POP. À medida que as utilizações chegam a A, os GKs se alinham com GK n, e as confirmações de chamadas são enviadas de forma mais demorada, inclusive pelo próprio GK n, que passa a usar também o atraso adicional. O valor de A será o mesmo para todos os GKs, a princípio. Todavia, caso uma instituição resolva utilizar um valor acima deste especificado, ela poderá fazê-lo, mostrando estar propensa a receber uma porcentagem maior de ligações externas. O valor de A não deve ser demasiadamente pequeno a ponto de provocar um valor exagerado de T i /A, que seria o atraso máximo adicional a ser impingido ao LCF. Todavia, como nos cenários reais do serviço fone@rnp a diferença de atraso entre GKs é da ordem de milissegundos, a escolha de A não deverá ser crítica. Empiricamente, espera-se que A seja escolhido entre 20% e 50%. Figura 4. Gráfico de Atraso D i x Utilização U i A Figura 5 apresenta três GK i s com atrasos bem variados ao POP, e ela será usada para explicar a operação do algoritmo. Os GK i s têm capacidade de 4 canais de voz, sendo inicialmente o número de chamadas externas e internas iguais a zero, sem atraso para envio dos LCFs. Neste exemplo, será assumido A = 50%. Figura 5. Topologia exemplo Quando se tentar estabelecer a primeira chamada, o DGK enviará um LRQ para cada um dos três GKs, sendo que o LRQ destinado ao GK 1 chegará primeiro, pois os outros GKs estão mais distantes. LCF 1 chegará primeiro ao GK chamador e, assim, a chamada será encaminhada para GK 1. Após esta primeira chamada, U 1 será de ¼ e o próximo LCF 1 será atrasado de 40 ms, como mostrado no gráfico da Figura 6a. Quando ocorrer uma segunda chamada externa, LCF 2 será enviado primeiro e chegará ao POP-RNP antes que os outros, fazendo com que a chamada seja encaminhada para GK 2 e não para GK 1, como ocorreria na ausência do algoritmo.

10 A utilização do GK 2 que era de zero passará a ser de ¼, e o próximo LCF 2 enviado por esse GK será atrasado de 35 ms. Isso é mostrado no gráfico da Figura 6b. O LRQ de uma terceira chamada externa chegará primeiro no GK 1, que atrasará o envio do LCF em 40 ms. O envio do LCF 2 sofrerá um atraso de 35 ms, que, somado aos 5 ms do seu percurso totalizará 40 ms. Isso fará com que o LCF 2 seja enviado ao mesmo tempo do LCF 1, porém, como GK 1 está mais próximo do POP, LCF 1 chegará 5 ms antes no GK chamador, fazendo com que o GK 1 receba sua segunda chamada. Com essa segunda chamada externa a utilização do GK 1 pela fórmula (1) será de ½, e assim o envio do próximo LCF 1 será atrasado de 80 ms, conforme mostrado na Figura 7a. Atraso Atraso Figura 6. Utilização após a primeira e segunda chamadas externas O LRQ de uma quarta chamada externa chegará antes no GK 1 e o envio do seu LCF será atrasado 80 ms. Quando o GK 2 receber o LRQ desta quarta chamada, 5 ms depois de GK 1, o envio do seu LCF será atrasado de apenas 35 ms e chegará ao GK originador com 35 ms de folga em relação aos LCFs de GK 1 e de GK 3. Apesar de LCF 3 ser enviado ao mesmo tempo que LCF 2, ele está 35 ms mais distante em relação a GK 2. Assim, esta quarta chamada será enviada para o GK 2, cuja utilização passará a ser de ½, com um atraso para envio do próximo LCF de 70 ms, como mostrado na Figura 7b. Atraso Atraso Figura 7. Utilização para as próximas chamadas externas Quando a quinta chamada chegar, o LCF do GK 1 será atrasado de 80 ms, o LCF do GK 2 será atrasado de 70 ms e o LCF de GK 3 será gerado de imediato. O LCF dos três GKs passarão pelo POP-RNP ao mesmo tempo e chegarão aproximadamente ao mesmo tempo no GK chamador. Um deles chegará primeiro. Se GK 1 receber a chamada, ele passa a ter uma utilização de ¾, e o atraso para envio do LCF será de 120 ms. No caso de GK 2 receber a chamada, o atraso será de 105 ms. Será arbitrado que o GK 1 receba essa chamada. Assim, quando um sexto LRQ for enviado, os GKs 2 e 3 enviarão os seus LCFs, que chegarão juntos no GK chamador,

11 com 40 ms de folga sobre o LCF do GK 1. Para esta sexta chamada é arbitrado, nesse exemplo, que o GK 2 receberá a chamada, e assim o seu atraso para envio do LCF será de 105 ms, como mostrado na Figura 7b. As chamadas seguintes serão encaminhadas para o GK 3, pois os GKs 1 e 2 terão os seus LCFs tão atrasados que eles chegarão depois no GK chamador. Como o GK 3 é o último, ele não tem uma reta de utilização, e, assim, as próximas chamadas externas não são balanceadas com os outros GKs, e seu gateway acabará saturado e as chamadas serão descartadas. Para evitar esta situação, foi concebido um GK virtual, mais distante do POP do que todos os outros, o que permite que o GK real mais distante tenha suas chamadas externas também balanceadas com os outros GKs. Resta obter a restrição no atraso ao POP para este GK virtual, para que o balanceamento ocorra adequadamente Posicionamento do GK Virtual Seja δ rede, a variação máxima de atraso na comunicação entre os GKs e o POP, devido a variações de carga na rede. Seja τ v, o atraso do POP ao GK virtual. Será preciso determinar a restrição no valor de τ v para garantir o balanceamento das chamadas. A situação mais crítica para o balanceamento ocorre quando todos os GKs operam numa certa utilização acima de A, exceto GK 1 e GK n, que estão com um número a menos de chamadas, e não existem chamadas internas estabelecidas, apenas externas. Nestas condições, supõe-se que a chamada mais recente tenha sido encaminhada a GK n. Para que a próxima chamada seja encaminhada para GK 1, é necessário que seja satisfeita a 2( τ v τ1) U1 2( τ v τ n ) U n desigualdade < 2( τ τ ) + (3). O lado esquerdo corresponde A n j A ao atraso para a geração de LCF 1 a partir da chegada do LRQ e o lado direito indica quando LCF n aconteceria na posição de GK 1. Se o LCF n acontece depois, então a chamada será encaminhada para GK 1, como desejado. Observando que U = n U1 + 1 / C, obtém-se, após simplificar, ( τ v τ n ) > C( U1 A) τ n1 (4). Fazendo U 1 A = 1, pode-se obter um limite inferior para τ v dado por τ v τ n + Cτ + δ (5). n1 rede Usando esta condição no posicionamento do GK virtual, o atraso máximo adicional que um LCF pode sofrer é dado por ( C + 1) τ n1 + δ rede Atraso adicional máximo = (6). A Para um exemplo numérico, usando C=30, A = 0,40, τ n1 = δ rede = 5ms, obtém-se um atraso adicional de 400 ms. Convém salientar que essa situação só irá ocorrer quando todos os GKs estiverem na saturação, o que não será freqüente numa rede com boa engenharia de tráfego Determinação dos Atrasos ao POP Inicialmente cada gatekeeper de uma região terá que conhecer o atraso do percurso de cada GK da sua região até o POP-RNP, e para a viabilização do algoritmo foram estudadas algumas possíveis alternativas. A primeira forma é utilizar um medidor no DGK, que realizaria as medidas de atraso aos GKs utilizando PING, e, num segundo passo, enviaria para os GKs as medidas obtidas em campos de extensão do usuário nas

12 mensagens de LRQ. A vantagem deste procedimento é que o DGK tem conhecimento completo dos IPs e prefixos de todos os GKs, além de processar as mensagens LRQ, tornando simples a implementação desta solução. A desvantagem é que o DGK pode estar muito distante do POP correspondente, e as medidas podem ter uma ordem de grandeza bem maior que a diferença entre os atrasos dos GKs, induzindo a erro, se a variância de atraso na rede for grande. A segunda forma é utilizar um medidor nos POPs, que poderia obter o endereço IP e prefixos dos gatekeepers de uma região no DGK, e realizar as medidas utilizando PING, e, num segundo passo, enviar para os GKs as medidas obtidas. A vantagem desta solução seria a maior precisão na medida do atraso do POP aos GKs. A desvantagem é que o repasse das informações teria que ser feito fora da sinalização H.323, possivelmente usando a porta de gerência do gatekeeper e/ou aplicação rodando no GK, o que tem implicações de segurança para acesso privilegiado. Uma terceira forma seria tentar realizar as medidas a partir de cada GK i. Inicialmente a relação dos GK i da região é obtida do DGK. A partir desse momento, cada GK i de uma região utilizaria o PING para medir o seu atraso até os outros GK i da sua região. Estas medidas deveriam ser obtidas nos vários GKs em um mesmo intervalo de tempo, para evitar erros grosseiros, o que é uma desvantagem e um complicador. A quarta forma envolve a própria sinalização LRQ entre o DGK e o gatekeeper que pretende iniciar uma chamada destinada à RTFC. Assim que um GK i enviar um pedido de localização para o DGK, uma mensagem chamada RIP (Request in Progress) seria enviada do DGK para o gatekeeper que enviou o LRQ. Dessa forma, esse GK i conhecerá o RTT entre ele e o DGK. Esse RTT será subtraído do tempo que o LCF de cada um dos outros GK i levar para chegar, obtendo assim o tempo de ida e volta de cada GK i até o POP. Esse procedimento seria falho se houver rotas fortemente assimétricas no backbone, mas isso não é o caso hoje em dia. 4. Cenários simulados Nesta seção, são apresentados os cenários utilizados nas simulações no MatLab e os gráficos dos resultados. Os gráficos apresentam a variação da métrica de utilização definida na equação (1) ao longo do tempo, para os vários GKs. O primeiro cenário simulado, mostrado na Figura 8, apresenta três GKs numa mesma cidade (prefixo=10), e igualmente distanciados do POP-RNP de 100 ms. Figura 8. Cenário da primeira simulação

13 Os gatekeepers GK 1 e GK 2 têm capacidade de 4 canais de voz, enquanto GK 3 tem capacidade de 8. Na simulação são disparadas 15 chamadas, com um tráfego de fundo de uma chamada interna nos gateways dos GKs 1 e 2, e não existirá chamadas internas no GK 3. Para esse cenário o valor estipulado de A, a taxa de utilização para alinhamento dos GKs será de 0,25. O objetivo é verificar o equilíbrio no encaminhamento de chamadas, quando os GKs têm a mesma capacidade, e estão igualmente distantes do POP. Na simulação do cenário da Figura 8, todos os canais de voz dos gateways foram ocupados com chamadas, e a situação de chamadas não completadas por saturação de um gateway é evitada. A Figura 9 mostra a evolução da métrica de utilização em cada GK após o estabelecimento das chamadas. Figura 9. Resultado da primeira simulação Na Figura 9, é mostrado que as métricas dos três GKs tendem a se aproximar e, na última chamada, as utilizações convergem para 1, como esperado. A atuação do algoritmo para forçar o equilíbrio pode ser observada através da oscilação dos valores de utilização, mas que tendem sempre a convergir em torno da diagonal do gráfico, mostrando assim o balanceamento. Figura 10. Cenário da segunda simulação

14 No segundo cenário, mostrado na Figura 10, GK 3 está afastado de 200 ms do POP, e os GKs 1 e 2 continuaram afastados do POP de 100 ms. Na simulação continuam a ser disparadas 15 chamadas, com um tráfego de fundo de uma chamada interna nos gateways dos GKs 1 e 2, e não existirão chamadas internas no GK 3, como no exemplo anterior. Além disso, o valor de A será mantido em 0,25. Nesse cenário, as utilizações dos canais de voz tendem a ficar iguais, ou seja, o mesmo comportamento do cenário anterior é observado. Porém, o GK 3 demora um pouco mais a se alinhar com os outros, pois ele possui mais canais de voz. Figura 11. Resultado da segunda simulação O próximo cenário é mostrado na Figura 12, e ele apresenta três GKs, agora com distâncias diferentes em relação ao POP-RNP. A capacidade de cada um é diferente, assim o resultado poderá mostrar o comportamento do algoritmo quando a capacidade e distâncias do POP são diferentes, o que seria uma realidade no serviço fone@rnp, pois as instituições necessariamente não possuem uma disponibilidade de recursos homogênea. Para este cenário a taxa de utilização para alinhamento foi modificada para 0,20, forçando os GKs a atingirem o equilíbrio com uma quantidade menor de chamadas. O tráfego de fundo foi de uma chamada interna para o GK 1, duas chamadas internas para o GK 2 e três chamadas internas para o GK 3. Figura 12. Cenário da terceira simulação

15 A Figura 13 mostra o resultado da terceira simulação, onde foram disparadas 21 chamadas. Nota-se que para esse cenário ocorre o balanceamento das chamadas, assim como aconteceu nas simulações anteriores. Figura 13. Resultado da terceira simulação Como o GK 1 possui uma quantidade menor de canais de voz ele fica muito tempo sem receber chamadas, e isso é observado na Figura 14 porque a sua utilização se mantém constante durante várias chamadas. Para avaliar a situação em que chamadas são terminadas, assuma na Figura 13 que os GKs estão em equilíbrio, com 15 chamadas externas em andamento. No caso de várias chamadas serem repentinamente terminadas em um GK, a utilização desse GK diminuiria, e, pelo algoritmo implementado, o atraso para envio do LCF desse GK voltaria a um estado anterior, aumentando sua prioridade de receber chamadas. Esse GK, que teve as suas chamadas terminadas repentinamente, receberia as próximas chamadas, que voltariam a ser balanceadas quando a sua métrica alcançasse o equilíbrio com a de outro GK. Dessa forma, não é necessário acompanhar o término de chamadas e o algoritmo se mostra robusto para diferentes cenários. 5. Conclusão Um algoritmo distribuído para balanceamento de chamadas H.323 destinadas à rede pública de telefonia dentro do cenário do serviço fone@rnp, onde várias instituições interconectadas a um POP completam chamadas para uma mesma cidade, foi apresentado. O algoritmo também se aplica a qualquer situação onde a aceitação de chamadas depende do retorno de mensagens enviadas de um ponto central, como com o uso de DGK, em H.323, e em SIP, quando se utiliza o encaminhamento múltiplo para estabelecimento de chamada por servidor proxy. Dessa forma, o algoritmo proposto pode ser aplicado a outras topologias diferentes daquela do serviço fone@rnp.

16 A métrica representada pela fração de chamadas externas em andamento sobre o número de canais de voz não ocupados com chamadas internas é utilizada para balanceamento. A partir de um determinado valor da métrica as confirmações de chamadas são atrasadas e o balanceamento é alcançado. O algoritmo usa o artifício de colocação de um GK virtual e a restrição ao posicionamento deste GK, que pode afetar o atraso na admissão das chamadas. Resultados de simulações demonstram a eficácia do algoritmo em diferentes cenários. Nota-se, através da simulação, que a velocidade de convergência dos valores de utilização dos canais de voz dos GKs é influenciada pela capacidade dos gateways VoIP/PBX e pela distância dos GKs até o POP. Todavia, o mecanismo é bastante robusto, pois opera adequadamente frente a localizações variadas dos GKs institucionais e diferentes demandas de tráfegos interno e externo. No momento, visando o uso em produção, procura-se aprimorar o algoritmo para incorporar procedimentos automáticos de reavaliação dos atrasos do POP aos GKs e incorporar otimizações para minorar o efeito do atraso adicional na aceitação das chamadas, principalmente após o alinhamento com o GK mais distante ter acontecido. 6. Bibliografia [1] ITU-T H.323 Telecomunication Standardization Sector of ITU (07/2003), series H: AudioVisual and Multimidia Systems. [2] Zhou, Q., Shirmohammadi, D. e Liu Edwin, W.-H., "Distribution Feeder Reconfiguration For Service Restoration And Load Balancing", IEEE Transactions on Power Systems, Vol. 12, No. 2, May [3] Ghanem, J., Implementation of Load Balancing Policies in Distributed Systems, The University of New Mexico, New Mexico, tese de mestrado. June, Site consultado em fevereiro de [4] Floyd, S. e Jacobson V., Random Early Detection Gateways for Congestion Avoidance, IEEE/ACM Transactions on networking. vol I. N O 1. August [5] Riedl, R. e Richter, L., Classification of Load Distribution Algorithms, Department of Computer Science University of Zurich, Zurich, Switzerland, 1996 IEEE. [6] Harchol-Balter, M. e Downey, A., Exploiting Process Lifetime Distributions for Dynamic Load Balancing, University of California, Berkeley, ACM Transactions on Computer Systems, August 1997, Pages [7] Zhang, L., "Scheduling Algorithm for Real-Time Application in Grid Environment", Departmenrt of Computer Science and Technology, Guangdong, Chine. IEEE SMC, [8] Rhee, W.-S., Lee, J.-H., Yu, J.-H. e Kim, S.-H., "Scalable Quasi-Dynamic-Provisioning-Based Admission Control Mechanism in Differentiated Service Networks", ETRI Journal, Volume 26, Number 1, February [9] IETF RFC 3261, SIP: Session Initiation Protocol, Junho 2002.