1. Introdução

O  presente artigo foi baseado na utilização da plataforma do sistema ACCESS#7, disponível em toda a planta de telefonia da operadora OI. A principal perspectiva deste projeto é a utilização da função DSTD (Direct Store to Disk) geradora de arquivos de tráfego de chamadas de sinalização de canal comum. Esta função permite a programação da seleção de tráfego dos CSP’s, em intervalos de tempo de 10 minutos, inicializadas e sincronizadas com uma hora-minuto “cheia” (por exemplo, 15h20min, 15h30min, esc.), garantindo que os dados coletados correspondam sempre ao mesmo intervalo de tempo. Os resultados de cada intervalo de tempo são automaticamente registrados em arquivos através da função DSTD, sendo exatamente esta capacidade de exportar os resultados on-line que viabiliza o uso da plataforma acceSS7 para a supervisão de intenção de tráfego e monitoração do completamento de chamadas através da sinalização de canal comum.

Estes arquivos depois de gerados, são compilados pelo programa de supervisão de intenção e monitoração de CSP’s, permitindo a visualização gráfica da intenção de tráfego e a taxa de completamento de chamadas, emitindo alarmes e planos de ação quando necessário.

Inicialmente, verificou-se se toda a rede de telefonia da operadora OI, estava sendo monitorado pela plataforma de sinalização Access#7. Esta rede de telefonia compreende centrais Gateways, plataformas de serviço, interconexões com outras operadoras com os respectivos PTS da rede.

Após confirmado que toda a rede de telefonia está sendo monitorado pelo AcceSS7, inclusive as centrais de nível 3 que hierarquicamente ficam abaixo das centrais N2, iniciou-se o trabalho de pesquisa  de completamento de chamadas para a identificação da intenção de tráfego e monitoramento dos CSP’s através das mensagens do protocolo ISUP.

A monitoração do completamento de chamadas através da sinalização canal comum está baseada nos conceitos de Taxa de Ocupações Completadas, definidos pelas recomendações do ITU-T, onde são computadas somente aquelas tentativas que resultam na ocupação de um circuito.

Esta ocupação é definida como uma tentativa de chamada que foi direcionada a uma rota de saida da central trânsito (níveis 2 e 1) e que resultou na ocupação de um juntor desta rota. Inclui-se nesta ocupação a necessidade de que além de ter ocupado um juntor de saída, a central trânsito tenha iniciado os procedimentos de sinalização com a central à frente para o estabelecimento da chamada, sendo este o critério adotado.

1.1.      Avaliação da taxa de completamento de chamadas

A avaliação da taxa de completamento de chamadas é feita através da quantidade de mensagens de “Endereço Completo” (ACM – Address Complete Message), “Atendimento” (ANM – Answering Message) e “Desconexões de Chamadas” (REL – Releases), transmitidas pela central em um determinado intervalo de tempo.

As mensagens de “Endereço Completo” (ACM) equivalem às chamadas onde o terminal de destino foi acionado e está sendo chamado (ringing). Nestes casos, a chamada poderá vir a ser atendida pelo usuário quando então enviada à mensagem de “Atendimento” (ANM).

Para entendermos a partir da sinalização, que uma chamada foi completada, basta observar a existência da mensagem de atendimento (ANM), sendo as mensagens de sinalização enviadas “para frente”, isto é, do PTS para a central Nível 2, irrelevantes. Também são desconsideradas as mensagens que produzem a desconexão da chamada após o término da conversação, como o Rel#16 (desconexão normal) e o RLC (release complete – desconexão completada).

Por sua vez, as chamadas que encontram o terminal de destino ocupado, com defeito, inexistente, ou mesmo que enfrentam congestionamento na rede, são indicadas através das mensagens de “Desconexão de Chamada” (REL), sendo que cada release possui um indicativo da causa da desconexão, por exemplo, causa 17 (REL#17) indica o terminal ocupado.

Com estes dados, caracterizam-se os seguintes valores:

Total de Chamadas terminadas na central: é o total de mensagens “ACM” mais o total de mensagens “REL”, ou seja, o total de chamadas que chegaram ao terminal de destino mais o total de chamadas perdidas.

Total de Chamadas completadas: equivale ao total de chamadas ANM, ou seja, aos atendimentos no terminal de destino.

Total de Chamadas “Não Responde”: é calculado subtraindo-se a quantidade de mensagens ANM da quantidade de mensagens ACM, ou seja, daquelas chamadas que chegaram ao terminal de destino, mas que não receberam o sinal de atendimento.

Total de Chamadas Perdidas por “Linha Ocupada”, “Congestionamento”, etc.: equivalem às quantidades de mensagens “REL”, com as suas respectivas causas que indicam cada evento na rede. Alguns eventos podem ter associados dois ou mais Releases.

As trocas de sinalização entre o PTS e a central Nível 2 compreendem as indicações de congestionamento ou falha na chamada.  Estas indicações sempre dizem respeito a eventos na central Nível 2 ou na rede de telecomunicações que se encontra abaixo desta, pois uma vez que a mensagem de sinalização para trás (release) é gerada a partir da central Nível 2, a chamada efetivamente chegou a esta central e o insucesso ocorreu a partir deste ponto.

Simulando uma ligação telefônica, onde segue a troca de mensagens de uma chamada em que o resultado final é o assinante B ocupado. Inicialmente, o assinante A retira o telefone do gancho, iniciando a discagem e enviando para a rede de telefonia o CSP, a ANUF e o número completo de B. Estas informações são encapsuladas em octetos, formando a mensagem IAM que envia diversas outras informações para a central de destino. A central de destino por sua vez, envia a mensagem de endereço completo, ou seja, esta central informa a central de origem que recebeu todas as informações que necessitava para destinar a ligação para o assinante B. À central de origem do assinante B encaminha a chamada e recebe o retorno elétrico de linha em curto circuito. A central de destino interpreta este estado e envia para trás a mensagem REL que significa uma solicitação de liberação da chamada com uma informação em binário que corresponde que neste caso o assinante encontra-se momentaneamente em outra ligação. A central de origem do assinante A identifica este estado e envia para a central de destino a mensagem RLC de confirmação de liberação de chamada.

Tabela 1 – Associação entre os Releases ISUP e os eventos de telefonia

Então, os congestionamentos e falhas indicados podem ser:

·         Congestionamento ou falha interna na central Nível 2;

·         Congestionamento de rota entre a central Nível 2 e a rede à frente;

·         Falha na troca de sinalização entre a central Nível 2 e a rede à frente;

·         Congestionamento interno ou falha da central autônoma ou estágio remoto abaixo da central Nível 2.

1.2      Intenção de Tráfego por CSP

A intenção de tráfego por CSP é feita diretamente pela coleta de dados extraídos na mensagem IAM. Esta mensagem de endereço inicial fornece o número completo do assinante de origem e de destino da chamada, imprescindível para o desenvolvimento do proposto trabalho, além de fornecer diversas outras informações como pontos de origem e destino das centrais, natureza da chamada, protocolo de compactação utilizado e etc. No apêndice B, um exemplo de mensagem IAM, utilizado na coleta de intenção de tráfego e em destaque os campos que foram utilizados para a realização do programa em PHP.

Dentre os diversos CSP’s programados nas operadoras de telefonia do estado do Rio Grande do Sul, foram monitorados apenas os CSP’s que apresentam maior interesse de tráfego e por conseqüente maior ameaça comercial e financeira para a operadora OI. O quadro da tabela abaixo ilustra os CSP’s com as suas relativas empresas e em destaque os CSP’s programados para coleta no Access7 e compilação para o proposto programa.

Tabela 2 – CSP’s válidos no Rio Grande do Sul

Caso seja identificado um crescente interesse de tráfego por algum outro CSP, monitoração esta feita mensalmente por meio de relatórios extraídos mensalmente do MXDR, equipamento responsável pelo processamento de bilhetagem, o mesmo pode ser inserido no programa online de monitoração de tráfego pelo Access7. Para isto, basta incluir a monitoração do CSP pretendido na função DSTD do Access7 e a linha referente a este CSP no programa em PHP (igual a dos outros CSP’s), incluindo na tabela da base de dados mySQL a correlação com o número do CSP.

A inclusão ou exclusão de um CSP no programa em PHP é feito de forma simples e rápida, não necessitando de nenhum processo ou programação “pesada” para a monitoração da intenção de tráfego por CSP.

O apêndice B ilustra a mensagem IAM do protocolo ISUP, onde ocorre o encapsulamento dos números de origem e destino de chamada.

1.2      Desenvolvimento do Programa em PHP

O programa foi desenvolvido com o uso do software EasyPHP 2.0.0.0, que utiliza o servidor local Web Apache para alocar a página do supervisório desenvolvida através da linguagem PHP e auxiliada pelo banco de dados mySQL. A criação de script do lado servidor da Web cuida principalmente da conexão de sites da Web aos servidores back-end, como o banco de dados mySQL. Isso permite dois modos de comunicação:

·         Servidor para cliente: páginas da Web podem ser montadas a partir da saída do servidor de back-end.

·         Cliente para servidor: informações inseridas pelo cliente podem ser influenciadas.

Utilizando-se do editor de programa Dreamweaver, foi criado três principais arquivos de programas que se conectam entre eles e com outros pequenos arquivos de programas auxiliares e com o banco de dados mySQL. A divisão das tarefas em programas separados é importante para reduzir a quantidade de memória do computador solicitada pelo programa, tornando todo o processo de carregamento da página e compilação mais veloz.

Nestes arquivos, foram usados vários tipos de comandos de execução na linguagem PHP, dentro os principais se encontram citados abaixo:

·         Closedir: Fecha o caminho para o diretório;

·         Count: Conta o número de elementos de uma variável;

·         Echo: Exibe uma ou mais strings;

·         Else: Comando precedido do comando IF. Caso o resultado da expressão seja falsa, então o fluxo entra no else e executa outras comandos;

·         Elseif: Comando precedido do comando IF. Caso uma expressão seja falsa, pode-se comparar antes de entrar nos comandos else.

·         For: Avalia incondicionalmente a expressão inicial uma vez. Se a verificação de término for verdadeira, avalia a instrução e realiza a expressão de término de loop e repete estes loop até que a verificação de término se torne falsa;

·         Include: Função que pode ser usada em qualquer situação de inclusão de arquivos para o script em php;

·         If: Avalia a condição, se for verdadeiro executa a instrução 1, se for falsa executa a instrução 2;

·         Print: Mostra uma string.

·         Fclose: Fecha um ponteiro de arquivo aberto.

·         Switch: Avalia a expressão e compara o seu valor ao valor em cada cláusula case;

·         While : É um loop que avalia a expressão condição como um booleano, ou seja, se verdadeira for a instução: executa e inicia novamente e se for falsa: o loop é encerrado;

Para a contagem manual, foi coletada cem amostras de chamadas de dados “brutos” de sinalização e manualmente foram contadas as chamadas destinadas aos CSP’s 14, 21, 23 e 25 e os valores absolutos de chamadas OK, NR, LO e CO.

Na validação através do relatório emitido pela bilhetagem, é utilizado o software do processador de bilhetagem MXDR. Neste relatório, pode-se verificar o indicativo percentual de completamento de chamadas da filial da OI do Estado do Rio Grande do Sul. Este relatório é referente a todas as origens desta empresa, não importanto o destino das chamadas.

Como o percentual do completamento de chamadas com as centrais operando sem anormalidade pouco difere no decorrer do dia, pode-se tomar como o base o completamento de chamadas para todas as origens e referenciá-las ao completamento dos principais CSP’s da região disposto neste projeto. A figura 3.1 ilustra o completamento de chamada da filial do Rio Grande do Sul no dia 26/11/2009 das 10:05 às 11:05, lembrando que a solicitação deste relatótio foi às 13:05 do mesmo dia (02:00 de defasagem).

A programação da correlação entre as mensagens do protocolo ISUP e a marcação do indicador de completamento de chamada é feito pela central telefônica. Por tanto, o relatório acima depende da correta programação das centrais telefônicas dentro da sua ANUF . Diferentemente, o relatório emitido pelo Supervisório por Canal Comum é comum a todas as centrais telefônicas.

Os indicadores OU5, OU7 e OU8, no Supervisório por Canal Comum  foram analisados como chamadas NR,  pois não são mais controlados pela Anatel.

A tabela 3, mostra a comparação entre os dois relatório.

Tabela 3 – Comparativa entre Relatórios

Levando em consideração que o relatório do MXDR corresponde a toda ANUF 54, sendo assim computadas as centrais CSL-D, IMI-D, BGV-D, PAS-D e ERE-D e os possíveis erros de programação destas centrais, os números comparativos condizem com a realidade do completamento de chamadas desta operadora.

O único relatório existente na empresa de Intensão de Tráfego por CSP é emitido mensal e leva em consideração o tráfego por Estado. Este relatório está muito distante do proposto trabalho que é a emissão do relatório dentro de um período de cinco minutos e por central N2.

Como a facilidade e a confiabilidade de contarmos manualmente o Interesse de Tráfego por CSP a partir dos dados brutos de sinalização, pode-se afirmar que o relatório emitido pelo Supervisório ilustrado na figura 3é de grande confiabilidade.

2.      Realizar e apresentar um estudo sobre os protocolos TUP e ISUP e a integração das plataformas do analisador de protocolo Access#7 na planta de telefonia.

3.      Apresentar um estudo sobre os códigos de falha da rede de telefonia e como as mensagens utilizadas nos projeto indicarão a intenção de tráfego e as taxas completamento de chamadas: “OK”, “LO”, “NR” e “CO”.

4.      Implementar um software em PHP capaz de ler as informações brutas da sinalização de canal comum, compilar as mensagens relevantes e exportar ao banco de dados mySQL, importando deste mesmo banco de dados para a página, informações das mensagens ISUP que apontam a intenção de tráfego dos CSP’s 14, 21, 23 e 25 e o percentual do desempenho de completamento de chamadas (CO, NR, LO e OK), de cada CSP em forma gráfica.

5.      Apresentar o método de teste e validação da funcionalidade do supervisório, bem como os resultados obtidos.

Vencidas as etapas acima e verificando a eficácia do algoritmo implementado que torna este Supervisório uma importante ferramenta para alcançar os propósitos de lucratividade da empresa, integridade da planta de telefonia e de melhor desempenho operacional no completamento de chamada pelos motivos que seguem abaixo:

·         Concorrência entre empresas: após a privatização das telecomunicações, a concorrência visando preço e qualidade está cada vez mais acirrada. Desta forma, tornam-se necessárias novas ferramentas de supervisão de rede para que a operadora possa obter das centrais telefônicas o melhor desempenho com o menor custo possível de obras de melhorias e ampliação de equipamentos;

·         Indicadores Anatel: as empresas privatizadas do antigo Sistema Telebrás têm obrigações contratuais de manter os indicadores de completamento de chamada dentro dos índices estipulados pela Anatel sob pena de severas multas;

·          Velocidade na intervenção técnica de correção: através da monitoração da sinalização das centrais, pode-se verificar qualquer comportamento estranho, seja por erro de programação, queda dos meios de transmissão ou outros problemas que venham a ocorrer e que necessite uma rápida intervenção técnica;

·         Integridade da planta de telefonia: o projeto contempla a análise do desempenho dos CSP’s mais utilizados na rede de telefonia, podendo externar alarmes, emitir bilhetes de anormalidades para os técnicos de manutenção da planta quando as taxas de completamento de chamada se mostrar abaixo da meta estabelecida pela operadora;

·         Congestionamento de rotas: através da monitoração da taxa de congestionamento (CO), pode-se verificar a necessidade de ampliação de voz para um determinado destino.

O Supervisório desenvolvido atendeu todos os requisitos acima, podendo receber adições de muitas outras monitorações de intenções de tráfego como portabilidade, chamadas para clientes DDR, tráfego internacional e etc. O projeto também deixa um legado de base técnica para o desenvolvimento de Supervisórios com outros protocolos que estão em implantação ou que estarão em desenvolvimento dentro da área de telefonia.