Capítulo 1
Introdução
Gerenciar um sistema consiste em supervisionar e controlar o seu funcionamento para que ele satisfaça aos requisitos tanto dos seus usuários quanto dos seus proprietários [Sloman, 1994]. No caso dos sistemas de telecomunicações, que por natureza são grandes, complexos, heterogêneos e altamente distribuídos, esta é uma tarefa bastante difícil e que vem atraindo a atenção de um número crescente de pesquisadores nos últimos anos. Dois motivos podem ser citados para esse interesse. O primeiro deve-se à relevância do assunto em termos econômicos: uma grande rede de telecomunicações representa um investimento de vários bilhões de dólares. Uma gerência eficaz dessa rede pode implicar em significativo acréscimo na sua produtividade, através da melhor utilização dos recursos disponíveis. A melhoria na gerência da rede pode dar como resultados [Meira e Lages, 1988]:
Gerência de redes de telecomunicações envolve a transferência e o processamento de informações de gerência ( ou seja, informações referentes à estrutura e ao funcionamento dessas redes) com o objetivo de auxiliar uma empresa de telecomunicações a conduzir com eficiência o seu negócio [ITU- T , 1996] .Os padrões e recomendações já emitidos pelos organismos normativos que tratam do assunto cobrem apenas os aspectos ligados à estrutura e aos protocolos para transferência de informações de gerência, deixando de fora as atividades de gerência propriamente ditas [Fink et al., 1993].
0 ITU- T , setor normativo de telecomunicações da União Internacional de Telecomunicações (ITU), anteriormente conhecido como CCITT (Comitê Consultivo Internacional de Telefonia e Telegrafia), editou as especificações de uma rede de gerência de telecomunicações (Telecommunications Management Network -TMN). Essas especificações em conta apenas os aspectos tecnológicos, dedicando pouca atenção às necessida gerência dos serviços e dos negócios de telecomunicações [Milham e Pai, 1994].
Dos aspectos tecnológicos enfocados pela TMN, a maioria diz respeito ao funcionamento: integrado e harmônico entre sistemas, redes e operadoras. A implementação de SI sistêmicas para a gerência de redes e serviços de telecomunicações não é tratada no da TMN [Furley, 1996].
Mesmo fora do ambiente normativo, até há pouco tempo, a maior parte do dispendido no desenvolvimento de gerência de redes vinha sendo destinada aos aspectos relacionados à transferência de informações. Neste contexto se encaixa a grande polêmica em torno das virtudes e limitações dos protocolos CMIP ( Common Management Information Protocol) [ITU- T , 1991b] e SNMP (Simple Network Management Protocol) I al., 1990] [Gering, 1993]. Por mais importante, necessária e complexa que seja, Coleta de informações não é gerência de rede, mas apenas um pré-requisito para essa gerência.
Uma das áreas mais importantes na gerência de redes de telecomunicações consiste da gerência das falhas engendradas durante o funcionamento dessas redes. Segundo o ITU, gerência de falhas engloba detecção, isolação e correção de falhas [ITU- T , 1992i]. C; dessas três funções só pode ser realizada a partir da adição de valor [Mansfield et al, 1993] aos dados brutos coletados da planta.
Para uma planta de telecomunicações típica o problema relacionado à carência de informações no centro de gerência de rede está gradativamente perdendo relevância. De fato, com o crescimento da planta gerenciada, associado à implantação de modernos de gerência, está havendo um grande aumento no volume de informações recebidas nos centros de gerência, tornando praticamente inviável o processamento "manual" de todas elas [Nygate, 1995].
Portanto, é de interesse das operadoras de serviços públicos
de telecomunicações o desenvolvimento de soluções
para o processamento das informações de gerência disponibilizadas
aos sistemas de gerência de rede, de forma a entregar para os operadores
apenas as informações de maior relevância para as suas
tomadas de decisão.
Definição: Correlação de alarmes consiste na interpretação conceitual de múltiplos alarmes, resultando na atribuição de um novo significado aos alarmes originais [Jakobson e Weissman, 1993].
Como parte do processo de correlação, dados brutos
são interpretados e analisados, levando em consideração
um conjunto de critérios pré-estabelecidos, ou definidos
dinamicamente em função do processo de gerência. Dessa
forma, a correlação adiciona valor aos mes originais e é
um importante mecanismo de gerência de redes de telecomunicações.
Ao reduzir o tempo necessário para a identificação das falhas causadoras dos alarmes, permitindo a rápida restauração dos serviços afetados, a implantação de correlação de alarmes em um centro de operação americano típico pode trazer benefícios anuais de até 1 milhão [Nygate, 1995]. A importância deste assunto é reconhecida pelo ITU-T, que ,classifica a correlação de alarmes como um dos problemas a serem resolvidos para que sistema de gerência de redes produza os resultados que dele se deseja. Apesar desta importância, o ITU- T ainda não definiu sua posição quanto à matéria, que se encontra aberta a estudos [ITU- T , 1996].
Diversas propostas interessantes podem ser encontradas na literatura sobre correlação de alarmes em redes de telecomunicações ( cf. capítulo 2). A maioria dessas propostas visa a correlação de alarmes em algum segmento dessas redes, ou mesmo em elementos isolados de uma sub-rede.
Nenhuma das propostas estudadas poderia ser diretamente aplicada na correlação dos alarmes gerados no âmbito de uma rede de telecomunicações como um todo.
Um dos principais obstáculos à correlação de alarmes no âmbito de toda uma rede de telecomunicações decorre da dificuldade associada ao entendimento das próprias redes, pois existe uma carência de ferramentas que facilitem a modelagem de uma rede de telecomunicações, nos aspectos referentes à propagação dos efeitos de falhas em suas sub-redes.
Como contribuição para suprir essa carência, o presente trabalho oferece um modelo de redes de telecomunicações através do qual as dependências funcionais entre sub-redes podem ser especificadas (cf. capítulo 3).
O modelo é geral, podendo ser utilizado para facilitar o entendimento, como um todo, na rede de telecomunicações qualquer. Além disso, o modelo também é robusto, sendo facilmente adaptável a alterações arquiteturais ou tecnológicas nas redes modeladas.
A partir do modelo geral de uma rede de telecomunicações, desenvolvido no capítulo 3, é proposto um modelo geral para correlação de alarmes nessas redes, o qual constitui uma outra contribuição deste trabalho ( cf. capítulo 4). O modelo proposto adota, como estratégia abordar a complexidade do problema de correlação de alarmes, uma técnica denominada correlação multifocal recursiva, também desenvolvida neste trabalho. A técnica é suficientemente geral para permitir que, a princípio, quaisquer dos métodos e algoritmos disponíveis na literatura possam ser adotados para fazer a correlação dos alarmes de uma rede de telecomunicações ou de um segmento dela.
Uma outra contribuição desta pesquisa é o estudo comparativo entre as diversas abordagens para correlação de alarmes encontradas na literatura, tendo como parâmetro principal a natureza da aplicação a que se destina a correlação ( cf. capítulo 2) .
Também é contribuição deste trabalho a classificação dos modelos de redes de telecomunicações encontrados na literatura, segundo os objetivos e o escopo desses modelos (cf. capítulo 3).
Este trabalho tem como tema a correlação de alarmes em redes de telecomunicações. Isto não implica em perda de generalidade em relação ao estudo do mesmo assunto redes de computadores, pois, segundo (Tanenbaum, 1996], uma rede de computadores pode ser vista como um conjunto de computadores autônomos interconectados, isto é, aptos a trocarem informação entre si. Desta forma, muitos dos sub-sistemas de telecomunicações modernos como, por exemplo, as redes de sinalização (ITU- T , 1993b], as redes inteligentes (ITU- T , 1992h] e as redes de gerência (ITU- T , 19961, podem ser vistos como grandes redes de computadores.
O restante deste trabalho está estruturado em cinco capítulos. O capítulo 2 fornece uma base para o estudo de correlação de alarmes, através da discussão dos principais conceitos envolvidos, provê uma visão panorâmica das principais abordagens existentes na literatura e compara essas abordagens segundo critérios ligados à natureza das aplicações a que se destina a correlação. O capítulo 2 também faz uma revisão dos principais produtos, soluções e plataformas para correlação de alarmes encontrados na literatura. No capítulo 3 é feito um estudo sobre modelagem de redes de telecomunicações, que inclui uma classificação das principais abordagens encontradas na literatura sobre modelagem de redes de telecomunicações, conforme os objetivos e o escopo dos modelos. O capítulo 3 também estabelece um modelo geral para redes de telecomunicações, que pode ser usado como base para o estudo de correlação de alarmes e gerência de falhas nessas redes. No capítulo 4 são desenvolvidos os conceitos de correlação multifocal recursiva e de limitação de escopo e, a partir deles, propõe-se um modelo para correlação de alarmes no âmbito de uma rede de telecomunicações. No capítulo 5 é feita a modelagem de uma rede de telecomunicações canônica e é desenvolvido um protótipo para correlação de alarmes no âmbito de uma rede. No Capítulo 6 são relacionados os resultados obtidos neste trabalho, suas limitações e os possíveis trabalhos futuros.
Capítulo 2
Uma Revisão Sobre Correlação de Alarmes em Redes de Telecomunicações
Este capítulo provê um estudo prospectivo sobre correlação de alarmes, incluindo o estabelecimento de um conjunto de conceitos básicos sobre o assunto (seção 2.1). A seção 2.2 oferece uma visão panorâmica das principais abordagens existentes na literatura. Na seção 2.3 é feita uma comparação entre as diversas abordagens, tendo como parâmetro a natureza da aplicação a que se destina a correlação. A seção 2.4 reúne alguns dos principais produtos, soluções e plataformas comerciais para correlação de alarmes encontrados na literatura. Na seção 2.5 são feitas algumas considerações à guisa de síntese dos resultados obtidos do estudo realizado no capítulo.
2.1 Conceitos Básicos
Em 1985, para permitir a implementação de redes de gerência
a partir de equipamentos e sistemas multivendedores, o ITU- T iniciou a
especificação de sua Rede de Gerência de Telecomunicações,
mais conhecida como TMN [Mines, 1987] [ITU- T , 1996]. TMN é o modelo
geral de uma rede para dar suporte às necessidades de gerência
de uma companhia de telecomunicações para planejar, prover,
instalar, manter, operar e administrar redes e serviços de telecomunicações.
Definição: Um sistema de suporte à operação ("Operations Support System" -OS) é um programa que processa informações relacionadas à gerência de telecomunicações, com o objetivo de monitorar, coordenar e/ou controlar as funções de telecomunicações. Um OS caracteriza-se por implementar funções de gerência denominadas OSFs ( "Operations Systems Functions" ) (ITU- T , 1996].
Definição: Denomina-se elemento de rede um equipamento que se comunica com a TMN, segundo padrões definidos pelo ITU-T, com o propósito de ser monitorado e/ou controlado.
Definição: Um objeto gerenciado é definido como uma visão de um recurso ( rede de telecomunicações, sob o ponto de vista do sistema de gerência [ITU- T 1992i].
Um dos objetivos básicos da TMN é possibilitar a interconexão
entre diferentes sistemas de suporte à operação e
a planta de telecomunicações, essencialmente constituída
de elementos de rede heterogêneos.
Para que pudesse ser implementada a partir de blocos funcionais adquiridos de múltiplos vendedores, a especificação da TMN envolveu o estabelecimento de pontos de referência que representam "fronteiras" entre blocos funcionais) cujo propósito é identificar as formações trocadas entre esses blocos. Em geral, cada ponto de referência representa uma interface entre dois blocos funcionais), para efeito de implementação.
Para permitir o intercâmbio de informações através dessas interfaces, o ITU-T, em associação com a ISO (International Organization for Standardization), definiram padrões tanto para os protocolos quanto para os modelos de informações a serem adotados na comunicação.
O esforço de padronização realizado pelo ITU- T resultou na edição de um de recomendações. A Recomendação M.3000 [ITU- T ) 1994a] apresenta uma visão geral dos padrões do ITU-T referentes à TMN) servindo de um "guarda-chuva" para o desenvolvimento e o uso de outras Recomendações. A Recomendação M.3010 [ITU descreve a arquitetura TMN) incluindo os aspectos referentes à troca de informações entre os elementos da rede e os aspectos físicos e funcionais. Diversas outras Recomendações descrevem com detalhes os princípios [ITU- T, 1992i] [ITU- T, 1992j] [ITU- T, 1992m], as arquiteturas [ITU- T, 1995b] [ITU- T , 1992k], as definições [ITU- T, 1992d] [ITU. [ITU- T, 1991a] [ITU- T, 1992l] e as especificações [ITU- T, 1992b] [ITU- T, 1992f] [ITU-T, 1992f] [ITU-T, 1992g] [ITU-T, 1993c] [ITU-T1993d], UTU-T1991b] [ITU-T, 1992n] [ITU-T, 1992o] [ITU-T 1993f] necessárias à implementação de uma TMN.
Uma das maiores dificuldades encontradas na implementação de TMNs deve-se ao fato de que uma parte significativa dos equipamentos e sistemas de telecomunicações tentes não está preparada para implementar as funções de elemento de rede da TMN [Meira et al., 1995]. Em futuro próximo, entretanto, com a crescente digitalização da rede e o aumento da "inteligência" de seus elementos, a TMN deverá se consolidar como o grande arcabouço arquitetural para a gerência das redes de telecomunicações, pelas suas qualidades de elegância conceitual, robustez e consistência.
2.1.1 Áreas Funcionais de Gerência
As necessidades de gerência de uma rede podem ser agrupadas em cinco áreas funcionais distintas [ITU- T , 1992i]1:
2.1.2 Arquitetura Lógica em Camadas
Como forma de facilitar o entendimento da funcionalidade dos sistemas
de gerência de telecomunicações, o ITU- T definiu uma
arquitetura lógica em camadas ( "Logical Layered Architecture" -LLA)
[ITU-T, 1996] .Segundo esse modelo, alguns dos aspectos mais importantes
do processo de gerência são utilizados como critérios
para agrupamento da funcionalidade dos sistemas de suporte à operação
(ou seja, das OSFs) segundo quatro camadas lógicas de gerência:
1 A partir do trabalho desenvolvido pelo ITU- T , o programa europeu RACE (Research and Techno- logy Development in Advanced Communications Technologies in Europe) redefiniu as áreas funcionais de gerência de telecomunicações de forma a incluir, além dos aspectos "em-serviço" da gerência, também alguns aspectos "pré-serviço" .Como resultado, o programa RACE identificou nove áreas funcionais: projeto; planejamento; instalação; provisionamento; manutenção; desempenho; segurança; contabilização; consulta e controle, pelo usuário.
Por disporem de uma visão global da rede gerenciada, as OSFs desta camada são capazes de conhecer, monitorar e controlar a utilização dos recursos da rede, garantindo o seu funcionamento segundo padrões adequados de desempenho e de qualidade de serviço.
Esta camada provê o principal ponto de contato dos clientes com o prestador ( serviço e, portanto, deve dispor de informações precisas e atualizadas sobre a ativação e a desativação de serviços, a qualidade desses serviços e a ocorrência de falhas na prestação dos serviço (independentemente das causas).
A classificação das OSFs pode ser feita utilizando-se um gabarito bi-dimensional, semelhante ao apresentado em [ITU-T, 1992e] (figura 2.1).
Numa das dimensões da grade são representadas as áreas
funcionais de gerência, enquanto que na outra dimensão são
representadas as camadas da arquitetura lógica. Uma dada OSF deve
se encaixar em uma das células da grade apresentada; por exemplo,
a interseção de "Gerência de Falhas" com "Gerência
de Elementos" deverá conter todas as OSFs referentes a gerência
de falhas no nível de elemento de rede. Um OS pode conter diversas
OSFs e, portanto, pode se encaixar em uma ou mais posições
de grade.
| Gerência de Falhas | Gerência de Configurações | Gerência de Contabilização | Gerência de Desempenho | Gerência de Segurança | |
| Gerência de Negócios | |||||
| Gerência de Serviços | |||||
| Gerência de Redes | |||||
| Gerência de Elementos |
Figura 2.1: Áreas Funcionais e Camadas Lógicas de Gerência
2.1.3 Correlação de Alarmes
Um objeto gerenciado, que pode ser visto como uma representação de um recurso real, pode emitir notificações em resposta à ocorrência de algum evento interno a ele. As notificações, 'em como as informações nelas contidas, são definidas pela classe de objetos gerenciados Ia qual o objeto gerenciado é uma instância [ITU- T , 1992k]: Uma notificação pode ser transmitida para fora do objeto gerenciado, ou simplesmente armazenada internamente ao ,objeto [ITU-T, 1992p].
Relatórios de eventos são utilizados para, através
do uso de protocolos de comunicação, reportar a ocorrência
de eventos em um objeto gerenciado [ITU-T, 1991a].
Definição: No contexto de gerência de redes, uma falha é definida como uma causa de um mau funcionamento. Falhas são responsáveis por dificultar ou impedir o funcionamento normal de um sistema e se manifestam através de erros, ou seja, desvios em relação à operação normal do sistema.
Definição: Um alarme consiste de uma notificação sobre a ocorrência de um evento específico, que pode ou não representar um erro. Um relatório de alarme é um tipo de relatório de evento, usado no transporte de informações de alarme [ITU- T , 19920] .
Alguns autores [Kehl e Hopfmiiller, 1993] definem correlação
como
um processo no qual se cria um conjunto mínimo de hipóteses
de falhas para um dado conjunto de alarmes. Esta definição
pode ser adequada para o contexto de diagnóstico de falhas (cf.
item 2.1.4) mas, considerando que um alarme nem sempre está associado
a uma falha (por exemplo, nas aplicações de gerência
de tráfego, um alarme pode informar sobre o aumento do tráfego
em um tronco, o que não caracteriza uma falha), prefere-se adotar
a definição dada por [Jakobson e Weissman, 1993] segundo
a qual correlação de alarmes consiste na interpretação
conceitual de múltiplos alarmes, levando à atribuição
de um novo significado aos alarmes originais. A correlação
geralmente tem como objetivo reduzir a quantidade de notificações
de alarmes transferidas aos operadores do sistema de gerência de
rede, aumentando o conteúdo semântico das notificações
resultantes.
Correlação de alarmes pode ser aplicada a qualquer das cinco áreas funcionais de gerência definidas pelo ITU- T , quais sejam, falhas, configuração, contabilização, desempenho e segurança (ITU- T , 1992i1. Contudo, a maioria das aplicações encontradas na literatura está na área de gerência de falhas, que é a mais elementar e, por isto mesmo, talvez a mais importante. Entretanto, existem outras áreas onde, devido ao grande volume de informações envolvidas, a correlação de alarmes pode ser útil. Gerência de tráfego por exemplo, é uma aplicação que demanda a coleta e o processamento de informações em tempo real, com o objetivo de detectar anomalias nos padrões de tráfego da rede e tomar as providências necessárias para remediá-Ias. Dentre as anomalias ou condições exceção mais importantes destacam-se as sobrecargas aleatórias, os troncos "killer" e sobrecargas de tráfego geradas por eventos excepcionais, tais como catástrofes, promoções, de vendas por telefone e datas especiais (Goodman et al., 19931. Um tronco é denominado "Killer" se ele sistematicamente aceita as chamadas que lhe são oferecidas e as libera (mata) logo em seguida.
O principal requisito para se fazer gerência de falhas de forma integrada é a disponibilização, em um centro de gerência, de informações sobre o funcionamento da rede, tempo real. As anormalidades que ocorrem durante a operação da rede provocam a emissão automática de notificações de alarmes, as quais são recebidas no centro de gerência de rede. A partir das notificações de alarmes recebidas, o operador humano deve tentar identificar a falha ocorrida e, se necessário, emitir um bilhete de anormalidade, que é utilizado como referência para o acionamento das equipes de manutenção. Uma vez sanado o problema o bilhete de anormalidade é "fechado" , ficando disponível apenas para consulta.
Com o crescimento da planta gerenciada, estima-se que, a médio prazo, o centro de gerência de uma empresa regional de médio porte estará recebendo dezenas de milhares de notificações de alarmes por dia, o que tornará praticamente inviável o processamento "manual" de todas elas (Nygate, 1995].
Além disso, muitas das notificações recebidas não
contêm informação original. De a ocorrência de
uma única falha na rede supervisionada às vezes resulta no
recebimento múltiplas notificações. Diversos fatores
contribuem para esta situação. [Houck et al.,1995
]
Ainda que, a princípio, a correlação possa
ser feita "manualmente" pelos operadores dos centros de gerência
de rede, no contexto deste trabalho a expressão correlação
de alarmes, ou a expressão equivalente "correlação
de eventos", subentende o uso de recursos computacionais no processo
de correlação.
2.1.4 Diagnóstico de Falhas
Definição: Diagnóstico de Falhas é uma etapa no processo de gerência de falhas que consiste em descobrir qual a causa original para os sintomas (representados pelos alarmes) recebidos. Antes de se chegar à causa original, pode ser necessária a formulação de um conjunto de hipóteses de falhas, as quais precisarão ser validadas através de testes.
É desejável que um sistema para diagnóstico
de falhas possua um modelo da configuração gerenciada, processe
o fluxo de alarmes em tempo real e seja capaz de trabalhar com dados incompletos.
Além disto, espera-se que ele seja capaz de identificar mudanças
na aparência e na importância dos problemas em função
do tempo (e.g., horário, dia da semana, estação do
ano), de separar causa de efeitos e resolver os problemas por ordem de
severidade (i.e., os problemas mais graves devem ter prioridade). Na seleção
dos testes a serem aplicados, o sistema deve escolher os mais baratos e
mais eficazes. Na medida do possível, os testes diagnósticos
devem ser automatizados. Finalmente, é desejável que o sistema
consiga, de alguma forma, interpretar os resultados dos testes [Sutter
e Zeldin, 1988].
O problema de localização de falhas é NP-completo [Katzela e Schwartz, 1995], o que significa que não se conhece um algoritmo polinomial que o resolva. Entretanto, através de heurísticas [Pearl, 1984], em alguns casos pode-se desenvolver algoritmos polinomiais que dêem soluções aproximadas ou, em outros casos, que deem uma solução correta, com uma dada probabilidade [Katzela et al., 1995].
As necessidades de recebimento e armazenamento centralizado de alarmes, de conhecimento da configuração do sistema gerenciado no momento da falha e de conhecimento sobre como uma falha em um componente afeta componentes adjacentes na configuração são algumas das barreiras que precisam ser ultrapassadas antes que uma solução prática para o problema de correlação de alarmes possa ser implementada. No caso mais geral, a correlação pode demandar outras informações, tais como resultados de testes executações na rede, dados obtidos em bancos de dados externos e junto aos usuários. A dificuldade na obtenção destas informações constitui um obstáculo à implementação comercial de correlação de alarmes e justifica o fato de que, dentre diversas abordagens que têm sido porpostas, poucas têm aplicações práticas na gerência integrada de redes de telecomunicações.
Além da complexidade inerente a qualquer problema NP-completo,
o projeto e o desenvolvimento dos algoritmos necessários para fazer
a correlação, assumindo que as barreiras citadas sejam transpostas,
precisam levar em consideração os seguintes aspectos adicio
[Houck et al., 1995]:
2.1.5 Tipos de correlação
Diversos tipos de correlação podem ser identificados [Jakobson
e Weissman, 1995], em função das operações
executadas sobre os alarmes disponíveis. As mais importantes destas
operações são detalhadas a seguir:
Compressão
Compressão consiste em detectar, a partir da observação dos alarmes recebidos em uma dada "janela" de tempo, múltiplas ocorrências de um mesmo evento, substituindo os alarmes correspondentes por um único alarme, possivelmente indicando quantas vezes o evento ocorreu durante o período de observação.Supressão Seletiva
Supressão Seletiva é a inibição temporária dos alarmes referentes a um dado evento, segundo critérios - continuamente avaliados pelo sistema de correlação - relacionados ao contexto dinâmico do processo de gerência de rede. Os critérios de supressão geralmente estão vinculados à presença de outros alarmes, ao relacionamento temporal entre alarmes ou a prioridades estabelecidas pelos gerentes da rede.Filtragem
Filtragem consiste em suprimir um determinado alarme, em função dos valores de um conjunto de parâmetros, previamente especificados. Em um sentido estrito, a filtragem leva em consideração apenas os parâmetros do alarme que estiver sendo filtrado. Em um sentido mais amplo, a filtragem pode levar em consideração quaisquer outros critérios. Nesse caso, que poderia ser caracterizado como uma filtragem inteligente, o conceito de filtragem se expande, podendo englobar diversos outros tipos de operações, tais como compressão e supressão.Contagem
Contagem consiste em gerar um novo alarme a cada vez que o número de ocorrências de um determinado tipo de evento ultrapassar um limiar previamente estabelecido.Escalação
Escalação é uma operação na qual, em função do contexto operacional, um alarme é suprimido, sendo criado em seu lugar um outro alarme, no qual um parâmetro {p.ex., o parâmetro severidade) assume um valor mais alto. O contexto operacional inclui, dentre outros fatores, a presença de outros alarmes, o relacionamento temporal entre alarmes, o número de ocorrências de um evento em uma dada "janela" de tempo e as prioridades estabelecidas pelos gerentes da rede.Generalização
Generalização consiste em substituir um alarme, em função do contexto operacional, pelo alarme correspondente a sua super-classe [Bapat, 1994]. Como exemplo, na ocorrência simultânea de alarmes correspondentes a todas as rotas que utilizam como meio físico um determinado cabo, cada um dos alarmes originais pode ser substituído por um alarme indicando defeito no cabo; em seguida, através de uma operação de compressão, todos os alarmes repetidos podem ser substituídos por um alarme único.Essa operação está baseada no raciocínio do tipo indutivo, o qual foi originalmente estudado por Aristóteles no século IV A.C. [benton, 1952]. O raciocínio indutivo permite a ampliação do escopo do conhecimento, às custas do aumento da complexidade do problema e da introdução de um certo grau de incerteza no resultado da correlação.
Dois tipos principais de generalização podem ser identificados: generalização por simplificação de condições e generalização baseada em instâncias [Holland et al., 1986]. No primeiro caso, para que o alarme de classe mais baixa seja substituído por um outro de classe mais alta, são ignoradas ou desprezadas uma ou mais das condições definidas como necessárias à sua identificação. No segundo caso, um novo alarme pode ser gerado a partir da associação das informações correspondentes a dois ou mais alarmes recebidos.
Especialização
Especialização é uma operação inversa à generalização, que consiste em substituir um alarme por um outro, correspondente a uma sub-classe [Bapat, 1994]. Esta operação, baseada em raciocínio do tipo dedutivo, não acrescenta novas informações em relação às que já estavam implicitamente presentes nos alarmes originais e na base de dados de configuração, mas é útil no evidenciamento das conseqüências que um evento numa determinada camada de gerência [ITU- T , 1996] pode ocasionar nas camadas de gerência superiores.Como exemplo de uma possível especialização, o sistema de correlação pode gerar, sempre que determinada rota for interrompida, um alarme para cada um dos serviços afetadas pela interrupção. Desta forma, através da especialização, estarão sendo evidenciadas conseqiiências de uma falha na camada de gerência de rede de telecomunicações sobre entidades da camada de gerência de serviços de telecomunicações.
Relacionamento Temporal
Relacionamento Temporal é uma operação na qual o critério para correlação depende da ordem ou do tempo em que são gerados ou recebidos os alarmes. Diversas relações temporais podem ser definidas, utilizando conceitos tais como: DEPOIS-DE, EM-SEGUI[ A, ANTES-DE, PRECEDE, ENQUANTO, COMEÇA, TERMINA, COINCIDE-COM, SOBREP( SE-A [Jakobson e Wei~sman, 1995].Aglutinação
Aglutinação consiste na geração de um novo alarme a partir da verificação do atendimento pelos alarmes recebidos, de padrões complexos de correlação. A operação de aglutinação também pode levar em consideração o resultado de outras correlações e o resultado de testes realizados na rede.
2.1.6 Aspectos Arquiteturais
Na definição da arquitetura de um sistema de correlação de alarmes para uma rede de telecomunicações devem ser levados em consideração, entre outros, os seguintes aspectos:
Após definidos os objetivos da correlação, deverá ser definida a topologia ( cf. item 2.1.7) do sistema de correlação, ou seja, onde devem ser localizados os dispositivos correlatores e que tipo de relacionamento deve existir entre eles. Outros aspectos a serem delineados pela arquitetura envolvem a definição do tipo de correlação que deve ser feita (cf. item 2.1.5) e aonde. Igualmente importante é a definição das abordagens a serem adotadas, dentre aquelas disponíveis ou que possam ser implementadas, para cada tipo de correlação ( cf. seção 2.2).
2.1.7 Topologia
Em uma rede de telecomunicações, a correlação pode ser feita em diversos níveis da configuração, incluindo desde o nível de elemento de rede individual, até o nível máximo, que envolve toda a rede. Quando a correlação dá-se em um nível mais baixo, ela geralmente constitui-se de processos mais simples e, consequentemente, mais rápidos. Por outro lado, por não levar em consideração o contexto mais amplo, esta classe de correlação sofre de uma acentuada "miopia" , que a impede de detectar possíveis reflexos que problemas locais podem ocasionar na rede como um todo. Quando a correlação é feita no nível mais alto, todas as informações relevantes podem, em tese, ser oferecidas ao mecanismo correlator , que desta forma tem uma ampla visão do sistema gerenciado e pode diagnosticar problemas através dos seus reflexos sobre a rede como um todo. Em contrapartida, a grande quantidade de informações disponíveis provoca um aumento da complexidade do problema, que muitas vezes torna-se intratável.
2.2 Métodos e Algoritimos Para Correlação de Alarmes
Esta seção provê uma visão panorâmica sobre correlação de alarmes em redes de telecomunicações, através da reunião das principais abordagens existentes na literatura, classificadas segundo os métodos e algoritmos utilizados no processo de correlação [Meira, 1997] e Nogueira, 1997a].
Apenas dois tipos de abordagens foram identificados por [Lazar et al., 1992] ] problema de detecção e identificação de falhas em redes de telecomunicações: as abordagens probabilísticas de um lado e, do outro lado, as abordagens nas quais as entidades da rede eram modeladas como máquinas de estados finitos.
Hoje, o número de abordagens disponíveis é bem maior. Algumas dessas abordagens, são probabilísticas, outras utilizam paradigmas tradicionais de inteligência artificial (IA) e outras tantas aplicam princípios definidos em lógicas não-convencionais [Smets 1988]. Também existem abordagens que adotam métodos ad hoc para o tratamento do problema de correlação de alarmes.
2.2.1 Correlação Baseada em Regras
Das diversas propostas apresentadas na literatura sobre correlação de alarmes em si de telecomunicações, uma parcela significativa constitui-se de variações em torno da abordagem baseada em regras. Nessa abordagem, o conhecimento geral sobre determinada área está contido em um conjunto de regras e o conhecimento específico, relevante para uma situação particular, constitui-se de fatos, expressos através de asserções e armazenadas em um banco de dados. Uma regra consiste de duas expressões -fórmulas bem formadas do cálculo de predicados [Nilsson, 1980] - ligadas por um conectivo de implicação que operam sobre um banco de dados global. O lado esquerdo de cada regra contém um pré-requisito que precisa ser satisfeito pelo banco de dados para que a regra seja aplicável. O lado direito descreve a ação a ser executada se a regra for aplicada. A aplicação regra altera o banco de dados.
Todo sistema baseado em regras ( ou sistema de produção) possui uma estratégia de controle que determina em que ordem as regras aplicáveis serão aplicadas e que computação quando uma condição de término é satisfeita pelo banco de dados.
Existem dois modos de operação em um sistema de produção. O primeiro deles é o modo direto ("forward") , no qual parte-se de um estado inicial e se constrói uma seqüência de passos que leva até a solução do problema ("goal" ) .Em se tratando de um sistema de diagnóstico de falhas, as regras seriam aplicadas a um banco de dados contendo todos os alarmes recebidos, até se atingir uma condição de término envolvendo uma falha. No segundo modo de operação, denominado modo reverso ("backward"), parte-se da configuração correspondente à solução do problema e se constrói uma seqüência de passos que leva até a configuração correspondente ao estado inicial. Tomando-se novamente como exemplo um sistema de diagnóstico de falhas, as regras seriam aplicadas a um banco de dados contendo todas as falhas possíveis, até que fosse atingida uma condição de término na qual todos os alarmes recebidos estivessem presentes. Um mesmo conjunto de regras pode ser usado para os dois modos de operação [Rich, 1983].
Em comparação com os programas tradicionais, que contém
em seu código tanto o conhecimento especializado quanto as informações
de controle - o que contribui para torná-los extremamente complexos
e de difícil manutenção - um sistema especialista
baseado em regras é mais simples, mais modularizado e mais fácil
de manter, por ser organizado em três níveis [Cronk et
al., 1988]:
a) Uma máquina de inferência, que contém a estratégia para resolver uma determinada classe de problemas;A despeito das vantagens que apresenta em relação aos programas tradicionais, os sistemas baseados em regras apresentam algumas limitações no que se refere à aquisição do conhecimento necessário, que se baseia, a princípio, em entrevistas com especialistas humanos. Este procedimento é demorado, caro e sujeito a erros, o que tem incentivado pesquisas no sentido de automatizá-lo e torná-lo mais rápido, através de técnicas de aprendizado ("machine learning") [Michalski et al., 1983] [Goodman e Latin, 1991].b) Uma base de conhecimento, contendo um conjunto de regras com o conhecimento sobre uma tarefa específica, ou seja, uma instância daquela classe de problemas;
c) Uma memória de trabalho, contendo os dados sobre o problema sendo tratado.
Outra limitação destes sistemas é o não aproveitamento de experiências passadas no processo dedutivo, ou seja, a falta de "memória" .Assim, um sistema puramente baseado em regras que tenha disparado milhares de regras para, a partir de um dado conjunto de alarmes, deduzir a ocorrência de determinada falha, irá disparar novamente todas aquelas regras sempre que for submetido ao mesmo conjunto de alarmes, chegando mais uma vez à mesma conclusão. O programa não se "lembra" da ocorrência de uma situação similar no passado.
Por não fazer uso de experiências passadas, os sistemas baseados em regras estão sujeitos a repetir sempre os mesmos erros, o que contribui negativamente para a precisão e o desempenho desses sistemas.
Tendo seu conhecimento limitado às regras do seu banco de dados, o sistema não consegue lidar com as situações nas quais estas regras não se aplicam. Isso afeta sua robustez [Lewis e Dreo, 1993] já que o sistema pode ficar sem alternativas ante a muitas situações comuns de um ambiente de gerência integrada de rede.
Em domínios que se modificam rapidamente, como é o caso das redes de telecomunicações, sistemas baseados em regras tendem rapidamente a se tornarem obsoletos [Lewis, 1993]
2.2.2 Lógica Difusa
Devido à complexidade das redes gerenciadas, nem sempre é possível construir-se modelos precisos dessas redes, nos quais sejam evidenciadas todas as situações em que a ocorrência de um dado conjunto de alarmes indica falha de um determinado equipamento.
O conhecimento sobre as relações de causa e efeito entre falhas e alarmes é geral incompleto. Além disto, freqüentemente alguns dos alarmes gerados por uma falha são tornados disponíveis ao sistema de correlação, em tempo hábil, em virtude de perda ou atraso no percurso desde o elemento de rede que lhes deu origem. Finalmente, devido ao fato de que a configuração muda freqüentemente, quanto mais detalhado for um m mais rapidamente ele ficará desatualizado.
Uma grande dificuldade, muitas vezes, consiste na imprecisão das informações fornecidas pelos especialistas. Num exemplo hipotético, um especialista em gerência de rede poderia formular as seguintes regras:
1. Se o tráfego na rota A estiver muito alto e o tráfego na rota B estiver norma desvie 1/4 do tráfego da rota A para a rota B;2. A ocorrência do alarme C às vezes indica falha do equipamento D.
As expressões "muito alto" , "normal" e "às vezes"
são inerentemente imprecisas e podem ser diretamente incorporadas
à base de conhecimento de um sistema baseado em regras convencional.
Lógica difusa ( "fuzzy logic" ) é uma alternativa para lidar com a incerteza e a imprecisão que caracterizam algumas aplicações de gerência de redes de telecomunicações.
De acordo com [Zadeh, 1988], a lógica difusa contém, como
casos especiais, o sistema lógico tradicional, os sistemas lógicos
multivalorados, a teoria das probabilidades e lógica probabilística.
Por outro lado, apesar de ser possível constatar empiricamente que
um dado sistema baseado em lógica difusa opera de acordo com que
dele se esperavava, ainda não existem ferramentas que permitam provar,
a
priori) que esse sistema funciona e Kumar, 1994], o que indica que
os conceitos introduzidos por [Zadeh) 1965] ainda não contam com
suficiente respaldo matemático.
| Tráfego (Erglang) | Grau de pertinência ao Conjunto |
| Até 30 | 0 |
| 30 a 40 | 0,2 |
| 40 a 50 | 0,4 |
| 50 a 60 | 0.6 |
| 60 a 70 | 0,8 |
| 70 a 80 | 0,9 |
| 80 a 90 | 0,95 |
| 90 a 100 | 1 |
Tabela 2.1: Definição de um Conjunto Difuso
Alguns pesquisadores argumentam que todos os problemas que podem ser resolvidos através de lógica difusa podem igualmente ser resolvidos através de modelos probabilísticos como, por exemplo, redes bayesianas (cf. item 2.2.3), com a vantagem de se contar, neste último caso, com uma sólida base matemática, o que falta à lógica difusa [Luna, 1994].
O conceito básico por trás da lógica difusa são os conjuntos difusos ( "fuzzy sets" ) .N a lógica clássica, um conjunto A apresenta a propriedade de que, dado um elemento X, a expressão "X pertence a A" sempre assume um dentre dois valores possíveis: verdadeiro ou falso. Em se tratando de conjuntos difusos, cada elemento X tem, em relação ao conjunto, um certo grau de pertinência, que pode assumir qualquer valor entre 0 ( quando definitivamente o elemento não pertence ao conjunto) e 1 ( quando certamente o elemento é um membro do conjunto). O conceito de conjunto difuso traz consigo a novidade de que uma proposição qualquer não precisa mais ser apenas verdadeira ou falsa, mas que possa ser parcialmente verdadeira, em qualquer grau na escala de 0 a 1.
A título de exemplo, seja de 100 Erlang a capacidade máxima de tráfego em uma dada rota. Pelos critérios da lógica clássica, "tráfego muito alto" poderia ser arbitrariamente definido como aquele que superasse, diga-se, 85 Erlang. Assim, um tráfego de 84,9 Er- lang não seria considerado "muito alto", enquanto que um tráfego de 85,1 Erlang seria definitivamente enquadrado naquela categoria.
Na abordagem da lógica difusa, o conjunto difuso "tráfego muito alto" pode ser representado pela função definida na tabela 2.1.
Através de uma álgebra especial, são definidas diversas operações (por exemplo, complementação, interseção e união) sobre conjuntos difusos.
Sistemas especialistas difusos ( "fuzzy systems" ) permitem que as regras sejam diretamente utilizando variáveis lingüísticas do tipo "muito alto" ou "normal, o que simplifica bastante o desenvolvimento do sistema
Numerosas aplicações de sistemas difusos têm sido implementadas, em diversas áreas tais como: planejamento estratégico [Hall, 1987], engenharia de minas [Meech e Jord 1993], geologia [Lebailly et al., 1987], medicina [Henkind et al., 1987], ciências ambientais [Veiga e Meech, 1994], engenharia elétrica [Chen e Rao, 1993] e gerência de redes [Lirov,1993].
Uma boa introdução aos sistemas difusos é apresentada em [Negoita, 1984]. Os aspectos teóricos dos sistemas especialistas baseados em lógica difusa são explorados em [Gupt; al., 1985], que também traz diversas aplicações desses sistemas.
2.2.3 Redes Bayesianas
Redes Bayesianas [Wright, 1921] apud [I-Ieckerman et al.,
1995b]
constituem uma interessante abordagem para tratamento de incerteza. Através
delas é possível a realização de inferências
mesmo quando as informações disponíveis são
incompletas e imprecisas.
Definição: Uma rede bayesiana é um grafo acíclico dirigido no qual cada nodo representa uma variável aleatória à qual são associadas probabilidades condicionais, dadas todas as possíveis combinações de valores das variáveis representadas pelos nodos predecessores diretos; uma aresta nesse grafo indica a existência de influência causal direta entre as variáveis correspondentes aos nodos interligados.
Uma probabilidade subjetiva expressa o grau de crença
(
"degree of belief" ) de um especialista em relação à
ocorrência de um dado evento, a partir das informações
de que pessoa dispõe até o momento [Henrion et al., 1991].
O uso de probabilidades subjetivas muitas vezes é o único
recurso, em situações onde a obtenção de dados
analíticos ou experimentais é muito difícil, ou mesmo
impossível [Charniak, 1991] [Pearl, 1991] [Deng e; 1993] [Kirsch
e Kroschel, 1994].
Algumas vezes é possível avaliar as probabilidades condicionais a partir de dados empíricos, levantados através do estudo do comportamento manifestado no passado sistema em estudo.
Dada uma rede Bayesiana e um conjunto de evidências - isto é, nodos cujas correspondentes variáveis foram instanciadas -é possível avaliar a rede, ou seja, calcular a probabilidade condicional associada a cada nodo, dadas as evidências observadas ; momento. No caso geral, este é um problema NP-difícil mas, com o uso de heurísticas apropriadas, e dependendo do problema tratado, redes contendo milhares de nodos podem ser avaliadas em tempo aceitável [Cooper, 1987] [Charniak, 1991].
Um estudo mais detalhado sobre redes bayesianas é mostrado no item 4.2.
2.2.4 Raciocínio Baseado em Modelos
Raciocínio baseado em modelos ("Model-Based Reasoning" -MBR) é um paradigma da área de inteligência artificial que tem diversas aplicações na correlação de alarmes. Os princípios de MBR foram originalmente propostos em [Davis et al., 1982]. MBR consiste em se representar um sistema através de um modelo estrutural e de um modelo funcional, em contraste com os sistemas baseados em regras tradicionais, onde as regras se baseiam em associações empíricas. No caso de um sistema de gerência de redes de telecomunicações, a representação estrutural inclui a descrição dos elementos de rede e da topologia (i.e., conectividade e relações de inclusão -"containment"). A representação do comportamento funcional descreve os processos de propagação e de correlação de eventos [Jakobson e Weissman, 1995].
2.2.5 Quadro-negro
Diversos sistemas especialistas para gerência de redes e, particularmente, para correlação de alarmes, têm sido implementados utilizando uma arquitetura denominada quadro-negro ("blackboard") [Goyal e Worrest, 1988] [Sasisekharan et al., 1993b] [Frontini et al., 1991]. A arquitetura consiste de um banco de dados global, denominado quadro-negro, diversas fontes de conhecimento ( "knowledge sources" -KS) e um mecanismo de agenda ( "sche- duler" ) .
O quadro-negro [Hayes-Roth, 1987] é responsável por armazenar elementos de solução ("solution elements") produzidos pelo sistema durante o processo de resolução do problema. Os elementos de solução são organizados no quadro-negro segundo dois eixos, representando níveis de abstração e intervalos de solução, respectivamente.
Fontes de conhecimento são processos responsáveis por gerar elementos de solução e armazená-los no quadro-negro. Cada KS é definida por uma condição e por uma ação. A condição normalmente caracteriza-se por uma dada configuração do quadro-negro e especifica em que situações a KS estará apta a contribuir na solução do problema através de uma ação. Geralmente, um dos efeitos de uma ação consiste na modificação do conteúdo do quadro-negro. As fontes de conhecimento são independentes entre si, ou seja, uma KS não pode invocar outras KSs, nem tem conhecimento sobre a funcionalidade, ou mesmo a existência dessas KSs.
Cada mudança no conteúdo do quadro-negro constitui um evento, capaz de ativar uma ou mais KS, dependendo das informações armazenadas no quadro-negro. O mecanismo de agenda é responsável, entre outras coisas, por selecionar, dentre as KS que tiveram sua condição satisfeita, quais as que serão disparadas. Através do uso de heurísticas oportunistas, o mecanismo de agenda pode escolher, em casa ciclo, qual a ação potencial mais adequada para a situação presente.
A arquitetura em quadro-negro contempla, entre outros, os seguintes objetivos [H Roth, 1987]: redução do espaço de pesquisa, através do raciocínio em múltiplos níveis de abstração, do uso de KS independentes e de agendamento oportunista; integração ( diferentes tipos de conhecimento; operação simultânea de KSs redundantes, como estratégia (para compensar a falta de confiabilidade do conhecimento disponível; independência entre os trabalhos das equipes de desenvolvimento de KSs; facilidade de modificação evolução.
2.2.6 Filtragem
Alguns sistemas de gerência de redes dispõem de filtros que selecionam as notificações alarmes a serem exibidas, a pedido do operador, segundo critérios tais como área geográficas onde o alarme foi originado, área técnica (i.e., transmissão, comutação, etc.) ou grau de severidade do alarme. Nesses sistemas, o conceito de filtro é similar à definição do ITU-T, segundo o qual um filtro é um conjunto de asserções sobre a presença ou os vala atributos em um objeto gerenciado [ITU- T , 1991a]. Os critérios de filtragem independem do contexto e baseiam-se exclusivamente nas características do próprio alarme [Meira, 1995]. Apesar de conseguirem reduzir bastante a quantidade de informações exibidas, os critérios de corte desses filtros às vezes não contribuem para facilitar a identificação de falhas que causaram a emissão das notificações de alarme, podendo até mesmo impedir apresentação de informações necessárias à identificação dessas falhas.
Existe uma modalidade de correlação de alarmes, que poderia ser chamada filtragem inteligente, na qual o critério de seleção é mais elaborado, sendo calculado dinamicamente: pelo sistema, em função de informações obtidas externamente ao alarme sendo filtrado [Mõller et al., 1995]. Esta técnica é apropriada para lidar com uma situação conhecida como "tempestade de eventos" [Hewlett Packard, 1995b], na qual são gerados, em curto espaço de tempo, centenas ou até milhares de eventos, a partir de um único problema. Este fenômeno ocorre com freqiiência em sistemas que usam tecnologias de alta velocidade como, por exemplo, ATM (Asynchronous Transfer Mode) [de Pricker, 1995] e SDJ chronous Digital Hierarchy) [ITU- T , 1993a], e precisa ser minimizado através de COI de alarmes.
2.2.7 "Event Forwarding Discriminator" -EFD
Na Recomendação X.734, o ITU- T define os serviços, os protocolos e as unidades funcionais de um sistema de gerência no que se refere à função relatório de eventos ( "event report") [ITU- T , 1993f]. No modelo recomendado, antes de serem transferidas para fora de um objeto gerenciado, sob a forma de relatórios de eventos, as notificações localmente são pré-processadas, dando origem a relatórios de eventos em potencial.
Um Discriminador de Eventos a serem Transmitidos ("Event Forwarding Discriminator" - EFD), tal como definido na Recomendação X.734, determina quais os relatórios de evento em potencial devem ser transferidos, sob a forma de relatórios de eventos para um destino e durante o intervalo de tempo especificados.
As condições a serem satisfeitas para que um relatório de evento em potencial possa ser transferido são especificadas através de um atributo denominado discriminator constr1/'ct, que atua como um mecanismo de filtragem sobre os objetos apresentados à entrada do EFD. Os seguintes atributos de um objeto gerenciado podem ser especificados em um discriminator construct, para serem avaliados por um EFD:
2.2.8 Raciocínio Baseado em Casos
Como alternativa à abordagem baseada em regras, alguns autores propõem uma técnica denominada raciocínio baseado em casos ( "case-based reasoning" -CBR) [Slade, 1991] [Weiner et al., 1995]. Aqui, a unidade básica de conhecimento é um caso, e não uma regra. Casos consistem de registros contendo os aspectos mais relevantes de episódios passados e são armazenados, recuperados, adaptados e utilizados na solução de novos problemas. A experiência obtida com a solução destes novos problemas constitui novos casos, que são acrescentados ao banco de dados, para uso futuro. Desta forma, o sistema é capaz de adquirir conhecimento por seus próprios meios, sem a necessidade de se entrevistar especialistas humanos. Outra característica marcante de sistemas CBR é a capacidade de modificar seu comportamento futuro em função dos erros cometidos. Além disto, um sistema baseado em casos pode construir soluções para problemas inéditos, através da adaptação de casos passados à nova situação.
O desenvolvimento de sistemas CBR teve início na década de 1980 e, desde então, vários desafios têm estimulado a criatividade dos pesquisadores: como representar os casos; como indexá-Ios, de forma a permitir sua recuperação quando necessário; como modificar um caso antigo, para adaptá-Io a uma nova situação e gerar uma solução original; como testar a solução proposta, classificando-a como sucesso ou fracasso; como explicar a falha de uma solução sugerida e repará-Ia, dando origem a uma nova proposta.
O problema de adaptação de casos foi estudado por [Lewis e Dreo, 1993], que descrevem uma técnica denominada adaptação parametrizada) que se baseia na existência, em um bilhete de anormalidade, de certa relação entre as variáveis que descrevem um problema e as variáveis que especificam a correspondente solução. O sistema CBR leva em conta os parâmetros desta relação na proposição de uma solução para o caso que está sendo analisado. Para a representação dos parâmetros é proposto o uso de variáveis lingüísticas (ou seja, que assumem valores linguísticos, ao invés de valores numéricos) e o provimento de funções que traduzem os valores numéricos dos parâmetros em graus de pertinência um conjunto nebuloso (cf. item 2.2.2).
Para armazenamento e recuperação de conhecimento sobre a solução de problemas passados) [Dreo e Valta) 1995] apresentam o conceito de master ticket que) ao invés de conter informações sobre uma única falha ( caso) , contém uma generalização das informa, sobre a falha. Assim, ao se recuperar um master ticket) ele deve ser instanciado antes que a informação que contém possa ser aplicada a um caso particular. O objetivo é facilitar o acesso às informações sobre a solução de problemas. A generalização consiste em substituir por parâmetros todas as informações específicas da falha que originou o bilhete, tais como informações do usuário e endereços dos nodos envolvidos. Instanciar um masterticket consiste em substituir seus parâmetros pelos valores reais do caso que estiver sendo considerado.
2.2.9 Correlação por Codificação
Na abordagem de codificação ("coding approach") [Kliger et al.) 1995] a maior do processamento necessário à correlação dos alarmes é realizada previamente, dando origem a uma base de dados denominada livro de código ( "codebook" ) .O livro de código pode ser visto como uma matriz, onde cada linha corresponde a um sintoma (ou evento, ou alarme) e cada coluna corresponde a um problema (ou falha) ou defeito). Se n sintomas distintos (são representados no livro de código) cada elemento do vetor Pi = (S1,S2,...Sn) contém a medida de causalidade do problema Pi em relação ao sintoma correspondente. Assim, se no vetor Pi) 81 = O) o sintoma 81 nunca deverá ocorrer como conseqiiência do problema Pij por outro lado) se 81 = 1) o sintoma 81 sempre deverá ocorrer como conseqüência problema Pi [Yemini et al., 1996] [System Management ARTS) 1996a].
Não é exigido que os valores das medidas de causalidade pertençam ao conjunto (0,1); o modelo admite que estes valores pertençam a qualquer semi-anel, que constitui uma classe especial de conjuntos parcialmente ordenados. Isto deixa aberta a possibilidade do uso de diversas abordagens para descrição da verssimilhança ("likelihood")da causalidade, tais como modelos determinísticos, probabilísticos, fuzzy logic e modelos temporais [Lirov, 1993] [Luna e Corrêa Filho, 1992].
Em tempo real, cada situação de anormalidade pode ser descrita através de um vetor de alarmes a = (a1, a2...an), onde cada elemento indica a ocorrência ou não do alarme correspondente. A correlação é feita através da escolha, no livro de código, do problema p, cujo código se aproxima de a, em termos de distância de Hamming [Hamming, 1950].
Como a maior parcela da computação é realizada antecipadamente, apenas as operações mais simples são feitas em tempo real. Isto permite que o desempenho do "coding approach", em termos de eventos processados por segundo, possa ser de duas a quatro ordens de grandeza maior do que o desempenho de outras abordagens de correlação de alarmes encontradas na literatura [Yemini et al., 1996] [Nygate, 1995] [Jakobson e Weissman, 1993].
O paradigma da orientação a objetos é adotado na abordagem de codificação para representar as classes de objetos da rede modelada, bem como seus atributos, relacionamentos e informações de eventos. Uma classe é um gabarito ("template") para um conjunto de instâncias de objetos, no qual são descritas as propriedades comuns a estes objetos, no que se refere à estrutura e ao comportamento.
A definição dos eventos e a modelagem da propagação de seus efeitos na rede gerenciada são feitos através de uma linguagem especial, denominada MODEL [Ohsie et al., 1997].
Uma das principais motivações para o uso de orientação a objetos é permitir a interoperabilidade entre um sistema de correlação de alarmes e outras aplicações, executando em ambientes distribuídos heterogêneos. Para haver interoperabilidade entre duas aplicações é necessário que elas obedeçam aos mesmos padrões de interface, tais como, por exemplo, os definidos em [OMG e X/Open, 1995].
Os pontos fortes da abordagem do livro de códigos são: desempenho, robustez, computação automática das regras de correlação e versatilidade na adaptação do sistema a mudanças ocorridas na topologia da rede [Yemini et al., 1996].
2.2.10 Localização Explícita
A maioria dos alarmes recebidos em um centro de gerência de rede não traz qualquer informação explícita sobre a localização da falha que Ihes deu origem. Na proposta apresentada em [Bouloutas et al., 1994], a cada alarme é explicitamente associada uma informação sobre localizações de falhas, consistindo de um conjunto que contém todas as localizações possíveis.Esta proposta guarda alguma semelhança com o modelo recomendado pelo ITU- T em [ITU- T , 19920], o qual cada notificação de alarme pode conter, entre outras informações, um parâmetro denominado orrelated notifications. Quando presente, este parâmetro contém um conjunto de identificadores de notificações e, se necessário, os respectivos nomes das instâncias de objetos gerenciados. Este conjunto contém )das as notificações às quais se considera que a presente notificação esteja relacionada.
Inicialmente é suposto que os alarmes sejam confiáveis
e que haja apenas uma falha na rede. Desta forma, a falha se localizará
na interseção dos conjuntos de localizações
indicados pelos diversos alarmes. Em seguida, este cenário é
estendido para cobrir as múltiplas falhas, em um ambiente mais realístico
onde os alarmes recebidos até podem não ser confiáveis.
O problema inicial evolui para um problema de otimização
discreta, onde o objetivo é descobrir o conjunto de falhas e o conjunto
de alarmes que minimizam uma certa função de custo. Sendo
este um problema NP-difícil [Bouloutas et ai., 1994], sua
solução envolve o uso de heurísticas.
2.2.11 Correlação por Votação
Correlação por votação é uma técnica conceitualmente similar à técnica de localização explícita (cf. item 2.2.10). A principal diferença é que, ao invés de conter informações sobre a exata localização da falha - dadas por um conjunto contendo todas as possíveis localizações -como acontece na localização explícita, na correlação por votação cada ( alarme contém um número inteiro de votos, apontando a direção (em relação ao elemento que reporta o alarme) na qual pode estar o problema que o causou [Houck et ai., 1995].
Segundo esta técnica, um alarme não contém votos para cada nodo individual, mas para todos os nodos de uma dada direção. Portanto, é necessário que o sistema de correlação conheça a topologia da rede gerenciada para que, ao saber o número de votos de um alarme para uma dada direção, cada um dos nodos daquela direção receba aquele número de votos. Em seguida é possível fazer uma totalização dos votos de cada nodo, seguida da escolha daqueles nodos mais votados como possíveis localizações da falha.
A técnica de correlação por votação pode ser associada a outras técnicas como, por exemplo, pesquisa em árvores de dependência [Houck et ai., 1995], que permitam identificar, dentre os componentes dos nodos mais votados, qual aquele que mais provavelmente é responsável pela falha que causou os alarmes. Através desta pesquisa pode também ser determinado se a falha é imputável aos nodos identificados, ou se esses nodos falharam devido a um problema em componentes dos quais eles são dependentes.
2.2.12 Correlação "Proativa"
Nem sempre deve ser visto negativamente o fato de a rede gerenciada gerar um grande volume de alarmes, quando em situação de falha. É sabido que o processamento manual dessa massa de dados tende a tornar-se inviável à medida que aumenta a quantidade ( sistemas de alta velocidade na rede. As técnicas mais comuns de correlação de alarmes procuram trabalhar, em tempo real, diretamente sobre o fluxo de alarmes oriundo ( planta, buscando eliminar a maioria deles, ou pelo menos "escondê-los" dos operadores gerentes da rede, facilitando assim a identificação de falhas que já ocorreram.
Através das técnicas de garimpagem de dados ( "data mining" ) e de descobrimento conhecimento ("knowledge discovery") [Sasisekharan et ai., 1996] [Hãtonen et ai., 1996], é possível descobrir padrões que caracterizam o comportamento atual e as tendências de comportamento futuro da rede. A técnica consiste em se varrer os dados disponíveis, sistemática e exaustivamente, aplicando técnicas de correlação e de aprendizado [sasisekharan et al., 1994].
Desta forma, é possível identificar problemas em potencial antes que eles se materializem, o que permite a manutenção "proativa" da rede [Sasisekharan et al., 1993a].
A abordagem consiste em examinar o comportamento dos elementos da rede
ao longo do tempo, considerando padrões de comportamento comuns
a elementos da mesma classe. Tendo um forte componente empírico
(representado pelos dados coletados), a abordagem também inclui
conhecimento sobre os elementos e a topologia da rede. A computação
pode ser dividida em três passos:
a) Classificação dos elementos de rede e de seu comportamento ao longo do tempo;
b) Correlação das informações de toda a rede e formulação de hipóteses;
c) Resolução e verificação, para confirmar a verdadeira causa do problema e solucioná-lo. A necessidade de envolvimento humano no processo de identificação de falhas é enfatizado por [Sasisekharan et al., 1996], devido ao fato de que o problema não se encontra ainda completamente resolvido.
Propostas mais recentes de solução para o problema
de correlação "proativa" envolvem o uso de redes bayesianas
( cf. item 2.2.3) [Hood e Ji, 1997].
2.2.13 Correlação Distribuída
Com o crescimento das redes de telecomunicações, tanto em tamanho quanto em complexidade, pode ser recomendável o particionamento do ambiente de gerência em um certo número de domínios de gerência, para que sejam alcançados os requisitos de qualidade desejados na operação e manutenção do sistema. Um exemplo desta arquitetura organizacional pode ser encontrado em [Nogueira e Meira, 1996].
A adoção de uma arquitetura distribuída para o sistema de gerência de rede facilita a implementação de esquemas de localização distribuída de falhas e justifica o desenvolvi- mento de algoritmos distribuídos para essa localização.
[Katzela et al., 1995] apresentam um modelo da rede de telecomunicações gerenciada no qual é assumida a abordagem de gerência distribuída. A rede é particionada em diversos domínios estáticos, disjuntos e logicamente autônomos, cada um deles gerenciado por um único centro de gerência. Cada centro de gerência tem uma visão limitada do estado dos demais domínios. Entretanto, gerentes de diferentes domínios comunicam-se entre ,i e trocam informações sobre o estado de seus domínios. Como os alarmes gerados em conseqüência de uma determinada falha podem não se restringir a um único domínio, os centros de gerência têm que colaborar no sentido de inferir o estado real do sistema. assumido que os processos de transferência de informações entre gerentes e as demais partes da TMN não são afetados por falhas.
No modelo apresentado) o conjunto dos objetos gerenciados cuja falha pode causar u determinado alarme é definido como o domínio do alarme. Antes de iniciar o processo de localização da falha, o centro de gerência deve descobrir o domínio de cada um dos alarmes recebidos - o que pode ser feito através de localização explícita [Bouloutas et al., 199 (cf. item 2.2.10). Um agrupamento ("cluster") de alarmes é um conjunto de alarmes cujos domínios têm uma interseção diferente de 0 (conjunto vazio).
Cada agrupamento de alarmes pode ter uma ou mais causas possíveis. O algoritmo de localização de falhas deve descobrir a "melhor" ( ou seja, a mais provável) dentre estas causas possíveis. Isto poderia ser feito a partir da atribuição de uma probabilidade de falha a cada objeto gerenciado. A partir daí, a "melhor') causa para o agrupamento de alarme poderia ser definida como sendo o conjunto de objetos gerenciados cuja probabilidade , falha combinada fosse máxima. Ao invés de se atribuir uma probabilidade de falha a cal objeto gerenciado, [Katzela et al., 1995] associam a cada um desses objetos um "custo de informação" , definido como o logaritmo negativo da probabilidade de falha do objeto. Então, a "melhor" causa, ou seja, a mais provável, será dada pelo conjunto de objetos gerenciados cuja soma de custos de informação é mínimo.
Como a localização de falhas é um problema NP-completo, não se conhece um algoritmo polinomial que dê uma solução exata para o problema, no caso geral. Entretanto, sendo dados um agrupamento de alarmes recebidos (A) e o conjunto de objetos gerenciados associados a A, pode ser demonstrado que existe um algoritmo polinomial que acha uma solução exata se o número máximo de falhas simultâneas for menor que um parâmetro Portanto, pode ser assumido que existe um algoritmo centralizado que descobre as falhas mais prováveis em um conjunto de objetos gerenciados, dado um conjunto de alarmes e custos de informação associados a cada objeto gerenciado [Katzela et al., 1996]. Seja ç probabilidade de haver mais de k falhas simultâneas no sistema. Neste caso) Q é também a probabilidade de o algoritmo não fornecer uma solução para o problema.
Com relação à distribuição do processo
de correlação, são identificadas três abordagens
para localização de falhas:
1. Localização centralizada. Assume a existência de um gerente central, que tem uma visão global da rede e cuja área de atuação inclui os domínios de todos os demais gerentes. O gerente central resolve diretamente qualquer problema que afeta mais um domínio de gerência.2. Localização descentralizada. Neste caso, os problemas que afetam mais de um domínio são resolvidos através de uma colaboração entre o gerente e os gerentes dos domínios afetados.
Cada gerente de domínio é responsável por calcular as soluções parciais para o problema, contendo as possíveis causas dos alarmes cujos domínios incluam objetos de mais de um domínio de gerência, e enviá-las ao gerente central, que deverá descobrir , dentre estas soluções parciais, quais são as soluções compatíveis. Duas soluções par- ciais são compatíveis se todos os alarmes recebidos por todos os gerentes de domínio são explicados pela solução final.
Finalmente, o gerente central seleciona a solução global compatível que tenha o mínimo custo de informação.
3. Localização distribuída. Esta abordagem consiste em tentar descobrir as causas dos alarmes sem a interveniência de um gerente central.
Seja a rede de telecomunicações dividida em dois domínios, 1 e 2. Do ponto de vista do gerente do domínio 1, para cada alarme cujo domínio cruza a fronteira, seria desejável associar-se a probabilidade de que ele seja explicado pelo domínio 2. Para isto, todos os objetos gerenciados que pertencem ao domínio 2 e estejam associados com o alarme são associados a um "nodo procurador" ( "proxy node" ) .A falha de um nodo procurador indica que um ou mais objetos do domínio 2 falhou.
Pode ser demonstrado que o cálculo da probabilidade de falha de um nodo procurador é um problema NP-completo [Katzela et al., 1996]. O melhor que pode ser feito é uma estimativa desta probabilidade, o que introduz um erro, que por sua vez impede que se possa garantir uma solução global ótima.
[Katzela et al., 1995] comparam os algoritmos de identificação
de falhas para essas três abordagens, com respeito aos aspectos de
complexidade de tempo e de precisão. A complexidade é
função do número de objetos gerenciados associados
aos agrupamentos de alarmes, do número de alarmes que atravessam
as fronteiras entre os domínios e do parâmetro k (número
máximo de falhas simultâneas) admitido. Por outro lado, a
precisão
de
cada abordagem depende do erro na estimativa das probabilidades de falha
dos objetos gerenciados associados ao agrupamento de alarmes recebido.
Demonstra-se que a abordagem descentralizada geralmente tem menor complexidade
que a abordagem centralizada e provê soluções iguais
ou melhores no que se refere à precisão. A abordagem distribuída
tem complexidade menor que qualquer das outras duas, mas nem sempre garante
solução ótima. Entretanto, ela provê soluções
quase tão precisas quanto as soluções providas pelas
outras duas abordagens.
2.2.14 Redes Neurais Artificiais
Uma rede neural artificial ("Artificial Neural Network" -ANN) é um sistema constituído de elementos ("neurônios") interconectados segundo um modelo que procura reproduzir a rede neural existente no cérebro humano. Conceitualmente, cada neurônio pode ser considerando como uma unidade de processamento autônoma, dotada de memória local e de canais unidirecionais de comunicaçao com outros neurônios. O funcionamento de um canal de entrada em uma ANN inspira-se no funcionamento de um dendrito nos neurônios biológicos. De maneira análoga, um canal de saída tem como padrão um axônio. Um neurônio possui apenas um axônio, mas pode possuir um número arbitrário de dendritos (em um neurônio biológico existem da ordem de dez mil). O "sinal" de saída de neurônio pode ser utilizado como entrada para um número arbitrário de neurônios [ME e Kumar, 1994] [Mead, 1989].
Na sua forma mais simples, o processamento realizado em um neurônio consiste em efetuar a soma ponderada dos sinais presentes em suas entradas e gerar um sinal de saída se o resultado da soma ultrapassar um certo limite ("limiar"). No caso mais geral, o processamento pode incluir qualquer tipo de operação matemática sobre os sinais de entrada levando-se também em consideração os valores armazenados na memória local do neurônio [Meira Júnior, 1993].
Uma das principais motivações para o desenvolvimento das ANN é a utilização de computadores para tratar de uma classe de problemas que são facilmente resolvidos pelo cérebro humano, mas que não conseguem ser tratados com eficácia com a utilização exclusiva dos paradigmas de programação convencionais.
Devido à frustração da grande expectativa que se avolumou a partir das primeiras pesquisas sobre modelagem do sistema nervoso nos anos quarenta, o interesse pelas A reduziu-se sensivelmente ao final da década de sessenta, quando estudos teóricos revelaram fortes limitações desse paradigma [Michalski et al., 1983]. O interesse pela área renasceu a partir do início dos anos oitenta, quando o desempenho dos computadores passou a per implementações práticas, as quais têm um alto custo computacional. Também contribuiu para este "renascimento" o descobrimento de novas aplicações para as ANNs.
Controle e armazenamento distribuído de dados e paralelismo são características marcantes das ANN. Além disso, uma ANN não requer conhecimento prévio do relacionar matemático entre entradas e saídas, que pode ser aprendido automaticamente, dura operação normal do sistema. Isso as torna, a princípio, uma boa alternativa para aplicações ( tais como correlação de alarmes e diagnóstico de falhas ) onde as relações entre falhas e alarmes nem sempre são bem definidas ou compreendidas, e onde os dados disponíveis às vezes são ambíguos ou inconsistentes [Covo et al., 1989].
Uma excelente introdução às redes neurais pode ser encontrada em [Meira Júnior, 1993].
2.2.15 Diagnóstico por Comparação de Resultados de Testes
[Nussbaumer e Chutani, 1995] propõem uma técnica geral para diagnóstico de falhas em redes de comunicação, aplicável tanto a sistemas centralizados quanto a sistemas distribuídos. A técnica baseia-se em um "paradigma de teste por comparação" , que consiste em se fazer os nodos da rede executarem uma série de tarefas conhecidas. O diagnóstico dos nodos ou enlaces defeituosos é feito a partir das discrepâncias observadas nos resultados dos testes; a precisão do diagnóstico pode ser controlada através do número de vezes que a tarefa é repetida.
2.2.16 Outras Abordagens
Em virtude da importância que o assunto vem ganhando nos últimos anos, diversas novas abordagens têm sido recentemente propostas para o problema de correlação de alarmes. Como exemplo dessas novas abordagens, pode-se mencionar a técnica apresentada em [Ohta et al., 1997], baseada no paradigma "dividir para conquistar" ("divide and conquer"), através da qual os alarmes de interesse são isolados por filtros construídos dinamicamente, o que permite a simplificação do mecanismo a ser utilizado na correlação.
[Sabin et al., 1997] utilizam o paradigma conhecido como "problema da satisfação de restrições" ( "constraint satisfaction problem -CSP" ) no diagnóstico de falhas em redes de computadores. Segundo esse método, um sistema é considerado no estado de falha se algumas restrições não podem ser satisfeitas; o conhecimento de quais restrições foram violadas permite identificar a natureza da falha.
2.3 Comparação Entre as Abordagens Disponíveis
Não existe uma solução única que seja a "melhor", em termos de precisão e/ou de complexidade, para resolver um problema genérico de correlação de alarmes. Trabalhos recentes indicam uma tendência para a adoção de combinações de abordagens diferentes para a solução do problema em redes complexas [Frey e Lewis, 1997] [Katker e Paterok, 1997].
A opção a ser adotada em um caso específico deve ser escolhida tendo em vista as virtudes e as limitações das diversas abordagens aplicáveis àquele caso. Um levantamento englobando algumas das principais soluções, plataformas e produtos para correlação de alarmes encontra-se na seção 2.4 deste trabalho.
A comparação entre os métodos e algoritmos apresentados na seção 2.2 é um processo difícil e deve levar em consideração os seguintes fatores, entre os quais, em geral, existe uma relação de compromisso: (1) facilidade de modelagem teórica da rede objeto, ou seja, a rede que irá gerar os alarmes a serem correlacionados; (2) facilidade de implementação; (3) facilidade de adaptação a mudanças na rede objeto; ( 4) desempenho; (5) precisão.
Embora seja possível, em princípio, quantificar esses fatores para uma rede objeto específica, é difícil imaginar como isso poderia ser feito para uma rede objeto genérica. Portanto, uma comparação entre as abordagens para correlação de alarmes deve levar em conta as características da rede objeto – ou, no mínimo, a classe de rees objetos: SDH, ATM, comulação digital, etc.
Em geral, abordagens baseadas em regras são indicadas para correlação em elemento de redes, ou em redes cuja configuração raramente se altera; os altos custos de implementação e de adaptação a mudanças na rede objeto dificultam a aplicação dessas estratégias em grandes redes de telecomunicações. Outras abordagens, tais como aquelas baseadas em casos, são menos sensíveis a mudanças na rede objeto, mas ainda carecem de um embasamento teórico que permita a sua utilização em redes comerciais de grande porte (cf. item 2.2.8).
A natureza da aplicação a que se destina a correlação (por exemplo, redução da quantidade de informação a ser analisada pelo operador; identificação das falhas que deram origem aos alarmes; previsão quanto à ocorrência de falhas no futuro determina o tipo de correlação a ser efetuada (cf. item 2.1.5), o qual, por sua vez, deve ser levado em consideração na escolha do método ou algoritmo a ser adotado em uma dada situação.
Compressão de alarmes, supressão seletiva, filtragem simples, contagem e especialização são exemplos de tipos de correlação que podem ser facilmente implementados utilizando abordagens convencionais baseadas em regras (cf. item 2.2.1).
Aplicações envolvendo filtragem inteligente, escalação ou relacionamento temporal também podem ser implementadas através da abordagem descrita em 2.2.1, ou de suas variações. Entretanto, o aumento na complexidade do problema traz como conseqüência o surgimento de exceções, as quais nem sempre são adequadamente tratadas por essas abordagens, que não possuem um mecanismo eficaz para a implementação de raciocínio não-monotônico [Pearl, 1991]. Assim, na fase de desenvolvimento, cada exceção identificada exige a reformulação das regras já estabelecidas e/ ou a criação de novas regras, o que implica em acréscimo da complexidade da solução e em redução de desempenho. Além disso, a possibilidade de ocorrência de exceções não identificadas afeta a robustez do sistema, que não tem alternativas para lidar com essas situações. Outras abordagens, tais como o Raciocínio Baseado em Modelos ou a arquitetura em Quadro-negro ( cf. itens e 2.2.5), apresentam uma estruturação adicional em relação aos sistemas baseados em regras "puros" , o que facilita o desenvolvimento das aplicações mas não as torna substancialmente mais atrativas para a implementação de tipos mais complexos de correlação devido à tendência de redução de desempenho.
As aplicações mais interessantes da correlação de alarmes, tais como, por exemplo, diagnóstico de falhas ( cf. item 2.1.4), geralmente envolvem generalização ou aglutinação (cf. item 2.1.5). nesses casos, a complexidade do problema torna extremamente difícil a obtenção de soluções exatas [Katzela et al., 1996] , fazendo da incerteza um fator sempre presente no processo de correlação.
Dentre as diversas abordagens para se lidar com a incerteza na correlação de alarmes, merecem destaque a lógica difusa ( cf. item 2.2.2), as redes bayesianas ( cf. item 2.2.3), o raciocínio baseado em casos (cf. item 2.2.8), a correlação por codificação (cf. item 2.2.9) e as redes neurais artificiais ( cf. item 2.2.14) .Existe muita controvérsia envolvendo as vantagens e desvantagens de cada uma dessas alternativas. Os defensores das abordagens baseadas em lógica difusa, por exemplo, argumentam que elas simplificam bastante o desenvolvimento das aplicações e resultam em produtos que funcionam e que têm excelente desempenho; por outro lado, a inexistência de uma sólida base matemática que lhes dê suporte é um fator que inibe a adoção dessa alternativa em um maior número de aplicações.
Correlação por codificação é uma alternativa bastante interessante sob os aspectos de desempenho e robustez, mas exige um grande esforço na modelagem da rede objeto, tornando-a pouco recomendável para redes complexas.
Métodos baseados em redes bayesianas foram utilizados pela primeira vez em 1921, i na análise de resultados de colheitas [Wright, 1921] apud [Heckerman et al., 1995b], e ~ contam com sólida base matemática. A cada dia esses métodos ganham mais aceitação, na comunidade de cientistas da computação, como uma opção adequada à solução de problemas envolvendo incerteza [Heckerman et al., 1995b]. Esses fatores contribuiram para a adoção de redes bayesianas no modelo proposto no capítulo 4.
2.4 Produtos, Soluções e Plataformas Para Cor- relação de Alarmes
Esta seção apresenta uma revisão dos principais produtos, soluções e plataformas para correlação de alarmes encontrados na literatura.
Um grande número de aplicações de inteligência artificial e, mais especificamente, de sistemas especialistas, já foi desenvolvido com o intuito de auxiliar a gerência de redes de telecomunicações. Algumas destas aplicações foram reunidas em [Liebowitz, 1988], que contém casos clássicos, tais como o ACE (Automated Cable Expertise) [Wright et al., 1988] e o SMART (Switching Maintenance Analysis and Repair Tool) [Slawsky e Sassa, 1988]. Diversas outras aplicações de inteligência artificial em gerência de redes de telecomunicações podem ser encontradas em [Goyal e Worrest, 1988]. Um levantamento mais recente pode ser encontrado em [Hedberg, 1996].
No que se refere especificamente aos sistemas baseados em regras, [Cronk et al., 1988] fazem um apanhado dos principais sistemas, já disponíveis ou em desenvolvimento destinados à monitoração, controle, diagnóstico e reparo de redes de telecomunicações.
Dos produtos existentes, entretanto, poucos são capazes de correlacionar, em tempo real os fluxos de alarmes engendrados pelas modernas redes de telecomunicações, as quais se caracterizam pela grande quantidade de informações que são capazes de gerar e encaminhar aos centros de gerência de rede durante situações de anormalidade.
Não se pretende que o levantamento apresentado a seguir seja exaustivo, mas que seja representativo da aplicação das técnicas e métodos e algoritmos discutidos na seção 2.2.
2.4.1 Event Correlation Services (HP)
A HP desenvolveu como parte de sua plataforma Open View, um produto denominado ECS ("Event Correlation Services") [Hewlett Packard, 1995b]) que se propõe a processar centenas de eventos por segundo, visando lidar com o fenômeno denominado "tempestade de eventos") descrito no item 2.2.6.
O ECS é um sistema baseado em regras as quais são agrupadas em elementos de processamento denominados "nodos", cada um dos quais é responsável por certa funcionalidade no processo de correlação ( entrada, saída, filtragem, atraso, contagem, combinação, modificação,etc.). No sistema ECS, combinação consiste em formar um único de saída a partir de dois fluxos de eventos de entrada, enquanto que modificação consiste em um processo através do qual se modifica o valor de qualquer atributo dos eventos de entrada. Nesse último caso, os novos valores dos atributos são copiados ou calculados partir de qualquer dado disponível "publicamente" .
Os nodos são interligados em "circuitos", pelos quais passam os "fluxos" de alarmes gerados pela planta gerenciada. Um nodo composto pode ser definido a partir de um segmento de circuito e adicionado à biblioteca de nodos, para contemplar uma certa funcionalidade definida pelo usuário [Hewlett Packard) 1996b]. Através desta metáfora, parte da complexidade inerente a um sistema de correlação de alarmes pode ser escondida do usuário. O sistema ECS conta ainda com uma interface gráfica de usuário que possibilita o desenvolvimento de regras de correlação através da seleção, conexão e configuração dos "nodos" da biblioteca.
O sistema ECS possui uma arquitetura distribuída, o que permite a distribuição da correlação de eventos, contribuindo para reduzir o tráfego de informações de gerência na rede [Hewlett Packard, 1996a].
A arquitetura do ECS provê dois bancos de dados opcionais denominados "Data Store" e "Fact Store", que são úteis quando, por questões de reusabilidade e confiabilidade dos circuitos de correlação, deseja-se manter certas informações fora das regras de correlação gerais. Enquanto o "Data Store" contém um conjunto de pares de valores nome-nome, tais como, por exemplo, "Tamanho Tabela=20", o "Fact Store armazena informações na forma entidade 1-relacionamento- entidade 2, tais como, por exemplo, "Equipamento 15 está_contido_em bastidor 5". Estes bancos de dados podem ser utilizados para construir um modelo da rede gerenciada, permitindo que os relacionamentos entre eventos sejam avaliados dinamicamente. Alternativamente o modelo poderia ser construído utilizando apenas o circuito de correlação[Hewlett Packard, 1996b].
O sistema ECS suporta eventos primitivos dos tipos CMIP [ITU- T , 1991 b] e SNMP :ase et al., 1990]. Como o processamento interno não depende do formato dos eventos primitivos, o sistema pode receber eventos de entrada SNMP e, como resultado da correlação, emitir notificações CMIP, ou vice-versa.
Segundo a HP, o sistema ECS está disponível desde junho de 1996, a um preço inicial, !ssa data, de US$ 8000 [Hewlett Packard, 1996a].
2.4.2 U ma Implementação de Filtragem Inteligente (Philips)
Mõller et al., 1995] apresentam uma implementação de filtragem inteligente que atua sobre um sistema de gerência de rede SDH e utiliza o paradigma de correlação baseada em regras.
Um filtro é dividido em módulos, cada um deles responsável por um segmento da rede por uma certa funcionalidade. Um módulo compõe-se de três partes: informação sobre topologia, descrição das dependências entre eventos e regras para o processo de filtra- m. Da implementação constam três tipos de módulos, com as seguintes funcionalidades: impressão, supressão seletiva e aglutinação.
Para uma rede com 13 NEs (elementos de rede) e 13 linhas, numa simulação realizada por [Mõller et al., 1995], o filtro processou 1000 notificações por segundo durante um minuto, com um atraso máximo de 5s. Este bom desempenho pode ser parcialmente complicado pelo fato de que o compilador adotado instancia todas as regras que contêm variáveis com todas as possíveis combinações de valores dessas variáveis. Isto traz como conseqiiência um grande consumo de memória (1,5 MByte para o caso citado).
4.3 NerveCenter Pro (Seagate)
sistema NerveCenter Pro, da Seagate [Hewlett Packard, 1995a] [Seagate, 1996] utiliza "modelos de comportamento" para identificar problemas críticos, fazer correlação de alarmes e executar ações sobre a rede. As informações recebidas pelo sistema podem incluir mensagens SNMP ( "traps" e "polls" ) quanto mensagens emitidas pelos sistemas HP Open View OperationsCenter ou Seagate LANAlert.
As informações contidas nas mensagens recebidas são continuamente monitoradas para determinar a ocorrência de situações anormais, conforme antecipadamente definido. Se uma destas situações ocorre, o perfil de comportamento correspondente vai para um novo estado, executando as ações e emitindo as notificações correspondentes. O perfil de comportamento é atualizado a cada nova mensagem recebida, até que a situação seja resolvida. Neste momento, o perfil de comportamento volta ao estado inicial, apagando todos os alarmes a ele associados.
2.4.4 Sinergia
Sinergia é um sistema especialista baseado em regras, utilizado no diagnóstico de falhas da rede de telecomunicações italiana. Através de correlação, em tempo real, de alarmes das redes de transmissão e de comutação, o sistema reduz em uma ordem de grandes quantidade de informações apresentadas aos operadores [Brugnoni et al., 1993].
O objetivo do Sinergia é localizar falhas nos caminhos ( "paths" ) digitais da rede transmissão, constituídos de linhas, terminações de linhas, multiplexadores e demultiplexadores, "cross connects" e outros dispositivos. O sistema é capaz de identificar falhas intermitentes, assim como a ocorrência de múltiplas falhas simultâneas, mas não está apto a identificar falhas internas em centrais de comutação ou em "cross connects" .
Duas estratégias são utilizadas pelo Sinergia para lidar com a complexidade do problema de diagnóstico de falhas. A primeira consiste em não levar em consideração os alarmes do tipo AIS (Alarm Indication Signal) [ITU- T , 1995a], considerados de pouco valor para o diagnóstico e responsáveis pelo aumento da área de influência das falhas. A segunda estratégia consiste em valorizar a característica de localidade temporal dos alarmes em relação às falhas que lhes deram origem.
A operação do sistema estriba-se no paradigma gerar e testar, que estabelece passos no processo de identificação de falhas. O primeiro passo, baseado em um conjunto de regras, instancia um conjunto de hipóteses de falhas. O segundo passo consta de pesquisa heurística clássica [Nilsson, 1980], através da qual é escolhida a melhor solução dentre as hipóteses apresentadas no primeiro passo.
Uma versão mais elaborada do Sinergia é apresentada em [Manione e Paschetta, 1994]. Nessa nova versão, o sistema consegue lidar com algum grau de inconsistência no banco de dados de topologia, apresentando, neste caso, uma degradação suave ( "graceful degradation" ) no seu desempenho.
Para validação do Sinergia foi utilizado um simulador de redes de transmissão plesiócrona denominado sprinter, que gera padrões de teste para o sistema de correlação de alarmes [Manione e Montanari, 1995].
2.4.5 TASA
O sistema TASA (Telecommunication Alarm Sequence Analyzer) trabalha sobre o fluxo de alarmes gerado por um sistema de telecomunicações, buscando descobrir regularidades, ou seja, seqüências de alarmes que se repetem freqüentemente e, a partir daí, propondo regras que podem ser incorporadas a um sistema de correlação [Hãtõnen et al., 1996].
O processo completo de descobrimento de conhecimento pode ser dividido em cinco l tarefas distintas: escolha dos métodos de descoberta dos padrões, coleta dos dados, descoberta dos padrões, apresentação e seleção do conhecimento descoberto e utilização do conhecimento (por exemplo, em um sistema especialista). O TASA suporta apenas as fases de descoberta dos padrões e de apresentação e seleção do conhecimento descoberto.
A descoberta das regularidades é feita automaticamente, a partir de uns poucos parâmetros fornecidos pelo usuário. Já a fase de apresentação e seleção do conhecimento descoberto não pode dispensar o especialista humano, que é considerado vital nesta etapa do processamento [Hãtõnen et al., 1996].
As regras propostas são do tipo: "se alarmes dos tipos alarme de enlace e falha de enlace ocorrem dentro de um intervalo de 5 segundos, então um alarme do tipo alta taxa , de falhas ocorre dentro de 60 segundos, com probabilidade 0.7".
Através de uma interface hipertexto, o sistema TASA apresenta grande conjuntos de sugestões de regras (correspondendo às regularidades descobertas pelo sistema), dos quais diferentes visões podem ser oferecidas ao operador. As seleções das regras é feita interativamente, utilizando filtragem, ordenação e agrupamento.
2.4.6 InCharge (SMARTS)
InCharge é um sistema completamente automático para diagnóstico de falhas em redes de telecomunicações ou de dados [System Management ARTS, 1996a]. O sistema foi desenvolvido pela empresa norte-americana System Management ARTS Inc. -SMARTS e utiliza uma máquina de correlação baseada na abordagem de codificação, patenteada pela SMARTS [Kliger et al., 1995] [System Management ARTS, 1996b] [Riordan, 1996]. Além de uma máquina de correlação, cada sistema InCharge mantém, em tempo de execução, um repositório de componentes modelados.
A arquitetura do InCharge é distribuída, contando com duas versões de sistemas em Itempo de execução: Mid Level Managers -MLMs e Enterprise Managers -EMs. A diferença principal entre as duas versões é que Sem podem se comunicar com aplicações externas, o que não é possível no caso dos MLMs. Uma aplicação típica do InCharge consiste de um EM no nível mais alto e uma ou mais camadas de MLMs, formando uma hierarquia de sistemas de correlação.
Além dos módulos em tempo de execução ("runtime systems"), o InCharge contém um ambiente para desenvolvimento dos modelos de diagnóstico. Para este ambiente foi desenvolvida uma linguagem de especificação formal denominada "Managed Object Defini Language- MODEL" [Ohsie et al., 1997], que é uma extensão da linguagem CORBA IDL ("Common Object Request Broker Architecture Interface Definition Language») [ON X/Open, 1995], com a adição de novas construções sintáticas para especificar propriedades semânticas que não podem ser especificadas em IDL, tais como: relacionamentos, eventos, problemas e propagação causal. O ambiente de desenvolvimento também contém compilador de MODEL para C++, além de ferramentas de depuração ("debugging") em conjunto de bibliotecas em MODEL.
O processo de identificação de problemas é dividido em duas partes: na primeira e são gerados os códigos, o que é feito no ambiente de desenvolvimento. Na segunda e é executada a decodificação de problemas, em tempo de execução.
InCharge é utilizado pela Motorola no projeto Iridium, que é um sistema de telecomunicações baseado em uma constelação de satélites de baixa órbita. Segundo a gerência deste projeto [Duffy, 1996], tentou-se inicialmente utilizar o sistema baseado em regras NerveCenter, da Seagate, mas, depois de três anos com este sistema, a Motorola o pela tecnologia SMARTS, devido a defeitos ( "bugs" ) e outros tipos de deficiência do NerveCenter.
O sistema InCharge estava cotado, em 1996, em aproximadamente US$ 7000 por servidor [Duffy, 1996].
2.4.7 NetFACT (IBM)
Através de correlação de alarmes, o sistema IBM NetFACT (Network Fault and A Correlator and Tester) [Houck et al., 1995] executa o diagnóstico e o acompanhamento da propagação de falhas em redes de telecomunicações. O sistema utiliza a técnica de correlação por votação ( cf. item 2.2.11) , combinada com a pesquisa em árvores de dependências.
O NetFACT opera no ambiente de gerência de rede NetView, da IBM. Seu funcionamento baseia-se na normalização de todos os alarmes recebidos e na existência de um modelo da rede, contendo informações sobre os elementos da configuração, bem como os relacionamentos entre eles (conectividade, dependências, fluxo de dados).
Cada alarme normatizado provê uma indicação, através de um número inteiro de votos, da direção na qual pode estar o problema que o causou, em relação ao nodo que reporta o alarme. Um alarme normatizado contém também um "time stamp’, a identificação do objeto ao qual o alarme se refere e informações acerca do impacto do alarme sobre o comportamento do objeto.
A pesquisa em árvores de dependências leva em consideração tanto as evidências diretas ( ou seja, alarmes) , como evidências indiretas (por exemplo, quantos usuários de um componente de nível inferior estão tendo dificuldades) .As evidências indiretas têm que ser usadas porque os componentes que falham nem sempre geram alarmes. Nos casos em que a falha de um dado componente possa ter sido causada por falhas em diversos componentes de nível inferior distintos, para os quais existam apenas evidências indiretas, são usadas heurísticas para escolher o componente com maior probabilidade de ter causado a falha. Testes diagnósticos, se disponíveis, podem também ser usados para ajudar a resolver tais ambiguidades.
A implementação foi feita em um sistema MVS/390 e utilizou, para modelagem de configuração, o sistema RODM ("Resource Object Data Manager") do NetView, que é um gerente de dados orientado a objetos, de alto desempenho. Por não estar disponível no ambiente MVS, a linguagem C++ não foi utilizada no desenvolvimento da aplicação de diagnóstico, a qual foi escrita em ANSI C [Houck et al., 1995].
Para que sistemas como o NetFACT se tornem práticos e comerciais, é necessário o desenvolvimento de padrões adequados de relatório de alarmes ( "alarm report" ) , tornando dispensável a "tradução" de cada alarme individual para a forma normalizada. Por requerer conhecimento a respeito da semântica de cada alarme individual, esta tradução é um procedimento caro e difícil, inviabilizando a implementação de produtos comerciais, exceto para contextos muito limitados.
2.4.8 IMPACT (GTE)
IMPACT (Intelligent Management Platforms for Alarm Correlation Tasks) [Jakobson e Weissman, 1993] é um sistema desenvolvido pela GTE utilizando a abordagem baseada em modelos (cf. item 2.2.4). A implementação tem como suporte um sistema especialista denominado ART- IM , conta com uma máquina de correlação baseada em regras e usa um , algoritmo de encadeamento direto.
As condições de disparo das regras de correlação levam em conta as relações temporais entre os eventos. [Jakobson e Weissman, 1995] exploram os aspectos temporais do modelo adotado, dos quais fazem parte conceitos tais como janela de correlação e vida útil ("Iifespan"). Uma janela de correlação pode variar desde alguns segundos (para processos muito rápidos, tais como rajadas de alarmes em sistemas de alta velocidade) até alguns dias. Como seria o caso de uma análise de tendência a partir de dados de um"log" de eventos. O mesmo tipo de variação pode ocorrer com a vida útil de uma correlação.
Além de criar um modelo para a correlação de alarmes, foi também criado um sistema de suporte de software orientado para o usuário final, ou seja, que permite que a especificação da correlação de alarmes seja feita pelos próprios especialistas do domínio.
Sendo um sistema MBR, a solução proposta contém um componente estrutural e um componente estrutural e umcomportamental. O primeiro inclui o modelo de configuração da rede e hierarquia de classes de elementos de rede. O componente comportamental, por sua vez, é composto por uma hierarquia de classes de mensagens, uma hierarquia de classes ( correlações e diversas regras de correlação. As correlações são feitas em um intervalo de tempo fixo que pode ser absoluto ou relativo. No último caso, o intervalo de tempo implementado como uma janela de tempo deslizante, na qual a correlação é executa( continuamente.
O IMPACT trabalha em conjunto com o sistema de gerência de rede em tempo real NetAlert e foi usado nas unidades de negócio da GTE para o desenvolvimento de duas aplicações de correlação de alarmes: CORAL, para a rede celular e AMES, para a rede telecomunicações convencional.
O sistema pode ser dividido em duas partes principais: um ambiente de desenvolvimento de aplicações e um ambiente de aplicação em tempo de execução. O ambiente de desenvolvimento de aplicações dá suporte à aquisição de conhecimentos, à edição e à apresentação provê as ferramentas a serem utilizadas pelo pessoal de operação na criação e manutenção da base de conhecimento. O ambiente de aplicação em tempo de execução monitora eventos da rede em tempo real) faz o "parsing" das mensagens que chegam a executar procedimentos de correlação de alarmes e provê interfaces para o pessoal de operação de rei Este ambiente é composto de quatro módulos principais: a interface gráfica de usuário ( GUI) ) o processador de comandos e mensagens, o processador de ações e a máquina decorrelação de alarmes.
O sistema IMP ACT conta com uma base de conhecimento da rede) criada pelo ambiente de desenvolvimento de aplicações que contém a configuração estrutural da rede e modelos dinâmicos de correlação de alarmes. A base de conhecimento contém as classes e as regras de correlação, as classes e as instâncias dos objetos gerenciados e as classes de mensagens. Também armazena modelos de configuração da rede, objetos gráficos para visualização de ícones de correlação e "scripts" procedurais a serem executados pelo processador de ações.
O sistema funciona em uma estação de trabalho SUN Sparc 10 e correlaciona de 12 a 15 alarmes por segundo. O modelo de correlação apresentado é determinístico, mas futuros desenvolvimentos poderão dotar o IMPACT de capacidade de fazer correlacionamentos inexados ("fuzzy"), visando atender a necessidades específicas [Jakobson e Weissman, 1993].
2.4.9 GMS
[Kehl e Hopfmtiller, 1993] discutem a aplicação do raciocínio baseado em modelos na área de gerência de redes de telecomunicações, tomando como base o trabalho realizado nos projetos AIM (Advanced Information Processing (AIP) Application to IBCN (Integrated Broadband Communication Network) Maintenance) e GEMA (Generic Maintenance Ap- plication) do programa europeu RACE. No projeto AIM foi desenvolvido um sistema de gerência de falhas baseado em modelos denominado GMS (Generic Maintenance System), para a manutenção corretiva on-line de falhas de hardware. O GMS pode ser aplicado na manutenção de qualquer sistema de telecomunicações, desde que se use uma base de dados de conhecimento ( modelo) específica para cada sistema.
O GMS foi utilizado, sob a forma de protótipo, em duas redes: na rede BERKOM ("Berlinen Kommunikationssystem"), que é uma rede de teste B-ISDN; e em um modelo de rede metropolitana (MAN) construído a partir de conhecimentos sobre uma MAN de teste, em operação em Stuttgart.
Para explicar os sintomas de uma falha o GMS precisa de um modelo funcional da rede de telecomunicações. Este modelo é constituído de informação estrutural (modelo estrutural) e de conhecimento comportamental.
O modelo estrutural baseia-se no conceito unidade-porta ("unit-port"), segundo o qual uma unidade é um objeto constituído de atributos internos e de portas. Os atributos internos definem o estado da unidade, enquanto que as portas são usadas para fazer a conexão entre unidades. Cada unidade é uma instância de uma classe de unidades. Denomina-se entidade funcional (FE) uma unidade usada na modelagem de uma função do sistema de r telecomunicações. A topologia da rede modelada é refletida na maneira como as FEs são interconectadas, o que determina as dependências funcionais entre FEs. Deve haver um mapeamento entre as FEs e as entidades do modelo físico.
O modelo estrutural é organizado em camadas funcionais, segundo os princípios do modelo OSI. Assim, a conexão entre FEs situadas em camadas adjacentes é feita através de ligações entre portas fornecedoras de serviços e portas que usam serviços. Esta carac- terística facilita a modelagem do mecanismo de propagação de erros.
O conhecimento comportamental é uma descrição de como a rede modelada se comporta, notadamente nos aspectos que se referem a falhas. Este conhecimento contempla três tipos de informação:
2.4.10 ECXpert (AT&T)
[Nygate, 1995] Descreve um produto denominado ECXpert, cuja função é ajudar os operadores de centros de gerência de rede na análise de alarmes e na tomada de decisões sob as ações corretivas a serem adotadas. ECXpert faz parte da família de produtos denomina( TNM (Total Network Management) [IF Computer, 1996], que constitui uma plataforma de gerência de rede desenvolvida pela AT&T e incorporada aos centros de gerência de regras de diversas empresas, incluindo NYNEX, PacBell, Bell South, SNET e Bell Atlantic.
O ECXpert adota uma estrutura de dados denominada esqueleto de árvore de correlação ( correlation tree sketelon) para representar um conjunto de alarmes que têm entre si uma relação de causa e efeito. Nestas árvores, uma ligação do tipo pai-filho equivale a um relacionamento causa-efeito entre alarmes. Mensagens equivalentes são representadas mesmo nodo. Os esqueletos são usados como base para construir instâncias de árvores correlação ( correlation tree instances) , a partir dos alarmes recebidos da planta, em tempo real. Portanto, o papel principal do ECXpert é receber alarmes e criar, dinamicamente árvores de correlação baseadas em esqueletos de árvore de correlação. Para facilitar a configuração do sistema em campo, foram definidos grupos de correlação, que guardam uma correspondência de um para um com os esqueletos de árvore de correlação. Cada grupo de correlação pode ser visto como um modelo de um problema da rede particular.
Tal como outros sistemas de gerência de rede [Nogueira e Meira, 1996], o TNM também permite que os usuários especifiquem a visão que pretendem ter da rede (por exemplo, por tipo de equipamento ou por região). Como sempre, esta filtragem deve ser feita com prudência porque, quando a visão do operador é muito restritiva, é geralmente difícil correlacionar alarmes gerados por problemas que afetam uma grande parte da rede. Por outro lado, se não forem feitas restrições, o volume de alarmes apresentados ao operador será grande que não será possível tomar conhecimento destes alarmes em tempo hábil
Do pacote ECXpert consta uma linguagem de descrição usada para especificar grupos de correlação, incluindo informações tais como: quando um novo alarme pertence a um grupo de correlação; quando um novo alarme se correlaciona com um alarme anterior que pertencia a este grupo; relações de causa e efeito entre alarmes; ações a tomar; janela de tempo dentro da qual os alarmes podem ser correlacionados.
ECXpert é constituído de quatro módulos principais: um compilador de grupos de correlação, uma interface .de usuário, um processo de teste de correlação e um processo de correlação.
O compilador de grupos de correlação, escrito em Prolog, converte as regras de cor- relação definidas pelo usuário em cláusulas Prolog. Cada grupo de correlação típico contém em torno de 100 linhas, que dão origem, após a compilação, a cerca de 250 linhas de código Prolog.
A interface de usuário apresenta, para um dado ,alarme escolhido, uma janela onde são mostradas todas as árvores de correlação às quais o alarme pertence, sob a forma de listas de alarmes ativos, onde a cada alarme é associada uma informação de precedência, que permite ao usuário reconstruir a árvore de correlação.
O processo de teste de correlação permite aos administradores do sistema verificar a correção semântica do grupo de correlação. Isto é feito enviando-se ao processo de teste, um a um, uma série de alarmes. O processo de teste irá informar por que certos alarmes pertencem a um dado grupo de correlação e como eles se correlacionaram com outros alarmes mais antigos no grupo. Este procedimento deverá ser realizado para validar cada grupo de correlação, antes de sua efetiva instalação.
O processo de correlação é composto de um objeto C++ para coleta de alarmes do sistema TNM, um objeto Prolog que executa o algoritmo de correlação e um objeto C++ que manipula a base de dados que contém as árvores de correlação. O algoritmo de correlação, baseado em regras (cf. item 2.2.1), pode ser visto como uma máquina de encadeamento direto que recebe cada alarme, verifica as regras às quais ele se aplica e aciona estas regras para atualizar as árvores de correlação. Cada alarme recebido é adicionado a todas as árvores de correlação relevantes.
Com dez grupos de correlação ativos, a versão do ECXpert apresentada pode correlacionar cerca de 1000 alarmes por hora, executando em um computador Tandem FT .
Devido à redução do tempo de identificação das falhas e à rápida restauração dos serviços afetados, ECXpert propiciou aumento e redução de custos de mão-de-obra, que redundaram em centenas de milhares de dólares em benefícios anuais.
2.4.11 SCOUT (AT&T)
SCOUT é um sistema desenvolvido pelos Laboratórios Bell, da AT&T, para automatizar o diagnóstico de problemas de transmissão em redes de telecomunicações [Sasisekharan et al., 1993a] [Sasisekharan et al., 1994] [Sasisekharan et al., 1996]. Um dos objetivos do produto é detectar e prever a ocorrência de problemas crônicos no sistema de transmissão, através do uso de técnicas de aprendizado, possibilitando a manutenção proativa desse sistema ( cf. item 2.2.12).
O sistema não faz aquisição de dados da planta, e portanto precisa comunicar-se com outros sistemas para obter estas informações. O processamento é feito em três etapas: na primeira etapa, as informações coletadas na planta são usadas para possibilitar a classificação dos circuitos em diferentes categorias, conforme os tipos dos erros observados. Em seguida, os alarmes são correlacionados, chegando-se a diversas hipóteses de falhas. Final- mente, a partir das hipóteses de falha, é determinada a causa do problema e ele é resolvido. Esta última etapa é feita com a participação do usuário do SCOUT .
A arquitetura do SCOUT baseia-se no paradigma do quadro-negro (cf. item 2.2.5} [Sasisekharan et al., 1993b].
2.4.12 NOAA
NOAA (Network Operations Analyzer and Assistant) é um sistema utilizado em gerência de tráfego na rede telefônica da Pacific Bell, no Estado da Califórnia (EUA) [AGL Systems Inc., 1996] [Goodman et al., 1995]. O sistema executa em uma estação de trabalho Sun e interliga-se ao sistema de gerência de rede NTMOS (NetMinderjNTM OS), da AT&T, através de uma rede local Ethernet.
NOAA é um sistema baseado em regras (cf. item 2.2.1), que também faz uso de técnicas de redes neurais (cf. item 2.2.14). A versão apresentada tem 120 regras e conta com um algoritmo, denominado ITRULE ("Information Theoretic Rule Induction") para aquisição automática de regras a partir dos bancos de dados de gerência de rede [ Goodman e Latin, 1991]. Também foram desenvolvidos recursos para lidar com as situações nas quais nenhuma regra se aplica. Nestes casos, o operador é convidado a entrar com novas regras ou a marcar aquela situação como um "caso especial" .
Quatro módulos de software compõem o NOAA, com as funções de coletar dados,' executar cálculos de tráfego, propor alternativas de ação e implementar uma interface gráfica de usuário, respectivamente [Goodman et al., 1993].
Os dados oferecidos ao NOAA consistem de contagens de alguns tipos de eventos para cada grupo de troncos, durante um período de cinco minutos. São exemplos desses eventos: ocupação de tronco, transbordamento (tentativa de tomada de tronco mal sucedida) e relatórios sobre a ocupação de troncos em um dado instante. Os seguintes parâmetros são calculados a partir dos dados coletados:
ACH Tentativas de chamada por circuito por hora
CCH Conexões por circuito por hora
OFL Percentagem de tentativas que transbordaram
USG Percentagem de troncos ocupados, na média
HT Tempo de retenção das chamadas
Através do uso de redes neurais, o NOAA prevê a capacidade de tráfego que estará disponível em uma rota, em um instante de tempo futuro, a partir de várias leituras, anteriormente realizadas, da taxa de ocupação dessa rota [Goodman et al., 1993]. Também são indicados pontos de problemas em potencial e executados automaticamente controles expansivos visando re-roteamento de tráfego para rotas alternativas. Comandos restritivos (por exemplo, bloqueio seletivo do tráfego em sua central de origem) são executados pelo operador, com o auxílio do sistema.
O trabalho de interfaceamento do NOAA com o restante do sistema de gerência de rede da Pacific Bell e a construção da infraestrutura para o sistema especialista duraram três anos. Desenvolvimentos adicionais ainda precisaram ser feitos para possibilitar ao sistema a realização de correlação de eventos e diagnóstico de falhas.
2.4.13 CRITTER
CRITTER [Lewis, 1993] é um sistema de bilhetes de anormalidades que utiliza raciocínio j baseado em casos (CBR, cf. item 2.2.8) para o diagnóstico de falhas na rede. Aqui, cada bilhete de anormalidade fechado constitui um caso. Um banco de dados de bilhetes de anormalidades é uma bilioteca de casos. O componente CBR do sistema CRITTER provê mecanismos para se recuperar um bilhete útil, adaptá-lo (se isto for necessário para gerar uma recomendação de solução para o problema atual) e acrescentar o novo bilhete à biblioteca de casos.
Para a recuperação de um bilhete útil, faz-se uso de um conjunto de "determinators" , contendo informações sobre a relação entre classes de problemas da rede e um dado conjunto de atributos registrados no bilhete. O "determinator" aponta para um conjunto de atributos relevantes a serem observados na ocorrência de um certo problema na rede.
Pode acontecer que uma conclusão constante de um bilhete recuperado seja diretamente , aplicável ao problema em pauta. No caso mais geral, entretanto, para solucionar o problema o sistema precisa adaptar o bilhete recuperado.
A arquitetura do sistema CRITTER consiste de cinco módulos:
O sistema denominado FIXIT (Fault Information Extraction and Investigation Too ner et al., 1995] é uma arquitetura baseada em casos (cf. item 2.2.8) na qual a experiência adquirida em gerenciamento de falhas é codificada e colocada à disposição do pessoal: operação. FIXIT foi implementado experimentalmente como um sistema de apoio à decisão de controladores de um sistema de satélites da NASA. A implementação foi em C++, executando em uma estação UNIX e utilizando um banco de dados Oral armazenamento dos casos.
2.4.15 OPA
Gensym Corporation desenvolveu um produto denominado "Operations Assistant" que funciona em conjunto com um outro software produzido pela empresa e denominado G2 [Gensym Corp., 1995]. Segundo anuncia o seu fornecedor, OPA é um sistema baseado em regras ( cf. item 2.2.1) que pode analisar, filtrar, correlacionar e priorizar alarmes, o diagnóstico de falhas e a recomendação de ações corretivas aos operadores. Também é possível o reconhecimento de padrões, o que permite a manutenção proativa da rede
OPA pode ser interfacetado com plataformas de gerência de rede tais como HP Open-View e IBM Net View. A AT&T desenvolveu um sistema integrado de gerência de rede utilizando Open View, junto com os softwares G2 e OPA.
2.5 Considerações Finais
Pela importância do assunto, muito ainda precisa ser desenvolvido na área de correlação de alarmes para que as necessidades de uma rede de telecomunicações sejam atendidas.
O estudo realizado neste capítulo demonstra a existência de diversas soluções aplicáveis à correlação de alarmes em segmentos específicos da rede (sub-redes ou elementos de rede) mas também demonstra, por outro lado, uma grande carência de propostas objetivando correlacionar alarmes no âmbito de toda a rede de telecomunicações. Isso poderia ser explicado pela própria dificuldade em se entender o relacionamento funcional entre as sub-redes que compõem uma rede de telecomunicações moderna. Esse entendimento é condição essencial para que um esquema geral de correlação de alarmes possa ser proposto. O próximo capítulo tem como objetivo contribuir para facilitar esse entendimento.