BRPI0318466B1 - System for administering a communication network, and method for administering a communication network - Google Patents

Abstract

"arquitetura de sistema para administrar uma rede de telecomunicação, método para administrar uma rede de telecomunicação, rede de comunicação, e, produto de programa de computador". uma arquitetura de sistema para administrar uma rede de telecomunicação (n) incluindo equipamentos de rede e serviços de rede suportados, em que os equipamentos têm interfaces de controle associadas (if_n<244>, if_n~ w~, if_n~y~, if_n~t~). a arquitetura compreende: - uma camada de base (ra, rp) delegando as interfaces (if_n<244> if_n~ w~, if_n~ y~, if_n~ t~) e desacoplando-as a partir das funções de administração, - uma camada de suporte (aa) composta de uma comunidade de agentes coordenando a operação da dita camada de base (ra, rp) a fim de suportar funcionalidades de administração distribuídas. a camada de base e a camada de suporte constituem camadas superpostas separadas na arquitetura. as camadas (pa, rp; aa; ma na arquitetura preferivelmente incluem componentes adaptados a realizar respectivas funções baseadas em respectiva informação de instrução provida a eles. uma base de dados (mdb) é provida, armazenando a informação de instrução e a arquitetura sendo disposta para distribuir a informação de instrução da base de dados (mdb) para os componentes. preferivelmente, todas as camadas na arquitetura incluem executores de processo (pe).

Description

“SISTEMA PARA ADMINISTRAR UMA REDE DE COMUNICAÇÃO, E, MÉTODO PARA ADMINISTRAR UMA REDE DE COMUNICAÇÃO” Campo da Invenção [01] A invenção refere-se a arquiteturas para administrar redes de telecomunicações e a serviços e ferramentas para uso naquelas arquiteturas. Descrição da Arte Pertinente [02] Em disposições convencionais, a administração de redes de telecomunicações 6 executada através de sistemas/funcíonalidades separados, atualmente referidos como FCAPS (um acrônimo para Falha, Configuração, Contabilidade, Desempenho, Segurança) (Fault, Qmfigumtion, Accoimting, Performance, Security), Estes são componentes geralmente separados que exibem tanto deficiente flexibilidade quanto baixa escalabilidade. Mencionado de outra maneira, em disposições convencionais, qualquer adição/modi fie ação na rede administrada acarreta correspondentes adiçõcs/modificações a serem executadas em cada uma das FCAPS.

[03] Plataformas distribuídas de administração de rede foram, assim,, propostas nos tempos recentes, as quais essencial mente implementam arquiteturas hierárquicas de múltiplos níveis de componentes (frequentemente chamados agentes) e arquiteturas de única camada.

[04] Por exemplo, a US-A-ó 243 396 propõe uma arquitetura de múltiplas camadas de autoridades que inclui agentes. Estes agentes são especializados para as várias funcionalidades de FCPS bem como para representar recursos de rede (de proxy). Esta proposta é bastante flexível, mas falha em ser verdadeiramente satisfatória com respeito à necessidade de identificar precisamente funcionalidades nas diferentes camadas e evitar estruturas de camadas excessivas, provavelmente para originar complexidade controle e interfaceamento. Em síntese, a US-A-6 243 396 descreve agentes distribuídos e hierárquicos trocando metas. Todavia, as camadas não são especificadas em suas funções.

[05] Uma outra proposta, envolvendo uma arquitetura “plana”, é revelada no US2002/0032769 Al e na correspondente EP-A-1 150 454. Ali, um sistema de administração de rede é revelado, o qual provê serviços de processamento de tarefa e dados, distribuídos por meio do emprego de agentes autônomos distribuídos. Especificamente, a disposição revelada nestes dois documentos paralelos provê para certos componentes (novamente agentes autônomos) que mantêm uma representação distribuída das funcionalidades de FCAPS distribuídas da rede (função de proxy) e de suporte. Este tipo de arquitetura melhora escalabilidade, mas não atinge um grau de flexibilidade verdadeiramente satisfatório. A função de proxy e a função de administração são intrinsecamente entrelaçadas umas com as outras e algumas funcionalidades mostram ser difíceis de serem implementadas eficientemente de uma maneira distribuída.

[06] Mais geralmente, certas plataformas de administração de rede, da arte anterior, implementam flexibilidade na forma de capacidades de configuração mais ou menos sofisticadas e/ou por meio do oferecimento de ambientes de desenvolvimento que ajudam aos projetistas de sistema ou integradores a construir o esqueleto de novos módulos para suportar novos serviços ou novas tecnologias.

[07] Este grau de flexibilidade comum é conhecido como não sendo satisfatório. Disposições foram, desta maneira, propostas (por exemplo, o programa de TMF, designado como NGOSS, descrito, por exemplo, em “NGOSS Technology Neutral Architecture”, documento TeleManagementForum TMF053, publicação 3.0, Abril de 2003), em que a extração de lógica de processo de negócios a partir de componentes é recomendada a fim de se ter uma máquina de processo que pode orquestrar o fluxo de ações que atingem uma maior flexibilidade.

[08] Máquinas de processo também foram propostos para uso como coordenadores de fluxo de trabalho em componentes distribuídos, cada um oferecendo funcionalidades específicas: por exemplo, WO-A-01/02973, onde é demonstrada a possibilidade de uso de uma máquina de fluxo de trabalho centralizado para coordenar agentes distribuídos.

[09] Esta proposta melhora a flexibilidade somente até uma extensão parcial: um administrador de processo centralizado pode se tornar um obstáculo, enquanto um bom tratamento de lógica de processo permanece embutido nos componentes simples. Isto torna impossível concentrar em uma máquina de processo os aspectos funcionais de todos os componentes. Objetivo e Sumário da Invenção [010] O objetivo da presente invenção é, assim, dispensar as desvantagens intrínsecas das disposições da arte anterior, consideradas precedentemente.

[01 Γ] De acordo com a invenção, este objetivo é atingido por meio de arquitetura de sistema lendo as características expostas nas reivindicações que seguem. A invenção também se refere a um correspondente método bem como a produtos de programa de computador, carregáveis na memória de pelo menos um computador e compreendendo porções de código de software para executar o método da invenção. Referência a “pelo menos um computador” é evidentemente pretendida para destacar a adequabil idade para a implementação descentralizada de pelo menos parte da disposição da invenção.

[012] A disposição descrita aqui especifica urna nova plataforma para a administração distribuída de uma rede de telecomunicação e serviços desta maneira suportados, bem como uma maneira para tomar os componentes mais flexíveis e cscalávcís.

[013] A disposição aqui descrita soluciona os problemas intrínsecos nas disposições da arte anterior por oferecer tanto funcionalidades centralizadas quanto distribuídas com agentes dispostos em uma estrutura hierárquica específica por designar funções precisas a cada camada. Por exemplo, em uma arquitetura de três camadas, cada camada terá uma função específica: uma primeira camada suportará funcionalidades centralizadas/coordenação, a segunda camada suportará as funcionalidades distribuídas e a terceira camada “de proxy” faz o intermédio da rede com o objetivo de desacoplar interfaces de rede a partir de funções de administração.

[014] O grau de flexibilidade de uma tal disposição pode ser ainda mais melhorado por meio de reclassificação para ferramentas específicas. Estas podem envolver, por exemplo: a) uso de combinações de máquinas de fluxo de trabalho e máquinas de regra nos componentes em todas camadas por meio do estabelecimento de uma estrutura distribuída e hierárquica de máquinas de fluxo de trabalho mais de regras; os componentes serão, assim, totalmente “ensináveis” em termos de funcionalidades; b) definição de uma base de dados de modelo (MDB) que armazena todos processos (fluxos de trabalho e regras) e definições de modelo de dados; isto irá prover um único ponto onde as funções dos componentes de plataforma serão definidos em uma maneira centralizada; c) levar vantagem de a) e b) pela distribuição automática de definições de modelo de processo e dados através da plataforma; isto evitará a necessidade de sincronização da estrutura hierárquica distribuída de máquinas.

[015] O administrador da plataforma irá, assim, estar em posição de gerar quaisquer funções de FCAPS por defini-las na base de dados, enquanto os componentes envolvidos irão “aprender” as novas definições de processo (fluxo de trabalho e regras) e rodá-las, quando necessário.

[016] Estes processos podem cobrir qualquer funcionalidade de FCAPS, desta maneira desenvolvendo-se de plataformas correntes onde cada componente roda uma específica funcionalidade de domínio (segurança, aprovisionamento, desempenho, etc.) até plataformas onde cada componente pode ser livremente “focalizado” (possivelmente tempo de operação) em específicas funcionalidades de domínio, como requerido por correntes policiamentos, disponibilidade de recursos, estado de carga, e assim por diante.

[017] O uso de máquinas de processo, de fato, aumenta as capacidades de uma camada de proxy, como revelado na EP-A-1 150 454. Atividades de padronização extensivas em modelos de equipamento durante os anos (vertical, por exemplo, a nota técnica de Common Information Model [CIM], DMTF, Janeiro de 2003, ou a “Shared Information Data Model Specification”, documento TeleManagementForum GB922, publicação 3.0, Abril de 2003) tentaram definir modelos flexíveis e extensíveis. A disposição aqui descrita também desenvolve estes modelos por permitir modificações daqueles modelos sem alterar o código no proxy.

[018] Para resumir, a disposição aqui revelada provê uma resposta totalmente satisfatória a cinco principais problemas que afetam as plataformas correntes: - uma flexibilidade mais elevada em suportar novos serviços e modificações de serviços existentes; - uma flexibilidade mais elevada em suportar novas tecnologias de rede, incluindo novos tipos de equipamentos; - distribuição mais elevada e mais fácil de aplicativos através de mobilidade de código; - alinhamento melhorado (por exemplo, mais completo e em tempo real) de inventario de rede com estado de rede; e - melhor escalabilidade e controle de desempenho da nova rede e plataforma de administração de serviço.

[019] Significantes e preferidos pontos arquitetônicos na forma de realização presentemente preferida da invenção são os seguintes: - plataforma de administração de rede e serviço é provida baseada em agentes distribuídos rodando fluxo de trabalho hierárquico de três camadas e máquinas de regras; - fluxos de trabalho e regras são usados para não apenas coordenar aplicativos, mas também para implementar todos os aspectos comportamentais dos componentes na plataforma; - um inventário de modelo centralizado (MDB) é tomado disponível para a definição e armazenamento principal de iodas descrições de processo e modelos de informação de recurso de rede. Estas definições são então distribuídas por toda a plataforma para uso nas máquinas de processo que atingem sincronização automática de todas funcionalidades de operação da plataforma; a necessidade de se ter documentação atualizada de modelação de equipamento e processos de operação continuamente disponível é assim satisfeita; e - uma camada de proxy de inventário de rede distribuída é provida, a qual desacopla o equipamento a partir do sistema de suporte de operação (SS) provendo uma base de dados to tal mente sincronizada para iodos processos que precisam documentação em tempo real da rede.

Breve Descrição dos Desenhos Anexos [020] A invenção será agora descrita, apenas a titulo de exemplo, com referência às figuras anexas do desenho, em que: - a figura 1 é um diagrama em blocos mostrando a arquitetura geral da disposição aqui mostrada, - a figura 2 é um diagrama de blocos mostrando um cenário de aprovisionamento pertinente, - a figura 3, incluindo duas porções indicadas a) e b), respectivamente, mostra vários exemplos de fluxos de trabalho de múltiplos níveis, - a figura 4 representa um diagrama de atividade típico de uma disposição aqui exposta, - a figura 5 é um exemplo de certos processos de camada na disposição aqui exposta, - a figura 6, novamente incluindo duas partes designadas a) e b), respectivamente, retrata vários exemplos de fluxo de trabalho de múltiplos níveís com regras exemplificativas para administração de falha, - a figura 7 mostra um outro diagrama de atividade dentro do quadro da disposição aqui exposta, - a figura 8 retrata um outro cenário provavelmente para aparecer dentro do quadro da disposição aqui descrita, - a figura 9 retrata um caso de uso exemplificativo de uma disposição aqui exposta, - a figura 10 é um fluxograma de fluxos de trabalho que ocorrem dentro da disposição aqui exposta, e - a figura 11 é um outro diagrama de atividade relacionada com a disposição aqui descrita.

Descrição Detalhada de Formas de Realização Preferidas da Invenção [021] Para facilitar a apropriada compreensão dos princípios que são subjacentes à invenção, um número de definições básicas será agora provido de certos termos usados na descrição da disposição aqui exposta.

[022] Agente: um agente é um processo independente e autônomo com possível estado persistente e requerendo comunicação (por exemplo, colaboração ou competição) com outros agentes a fim de satisfazer suas tarefas. Esta comunicação pode ser implementada através de mensagem assínerona que passa e por meio do uso de linguagens bem conhecidas (isto é. Linguagem de Comunicação de Agente ou ACL) com uma semântica bem definida e de acordo comum.

[023] Administrador de elemento: em um ambiente de administração de rede, este é um aplicativo que administra um número de elementos de rede. Tipicamente, o administrador de elemento é desenvolvido pelo vendedor de elemento de rede e inclui funcionalidades como: configuração, monitoração de alarme e aprovisionamento de serviço.

[024] OSS (Sistema de Suporte de Operações): em um ambiente de administração de rede, este é o aplicativo que é o responsável por rodar tarefas, tais como destinação de confusão, administração de ordens. Tipicamente, OSSs suportam os aplicativos de serviço e de administração de rede.

[025] Inventário de rede e serviço: isto é o sistema que armazena e toma a informação de inventário disponível para os outros OSSs ou aplicativos de administração. A informação de inventário pode incluir equipamento de rede e computação, recursos lógicos, topologia e serviços.

[026] Este (sub)sistema mantém o rastreio da configuração física e de topologia da rede, inventário de equipamento (cartões, portas, etc.), conectividade física e lógica das diferentes camadas de rede. Uma porção do inventário, usualmente chamada “catálogo”, contém as descrições de todas entidades armazenadas no inventário, tanto entidades de serviços quanto de rede. O inventário mantém também o rastreio de serviços planejados, subscritos e aprovisionados. Serviços são associados com os recursos de rede lógicos e físicos.

[027] Aplicativo de Administrador: este é um aplicativo correndo em um anfitrião e adaptado para coordenar a operação de um ou mais agentes. Ele pode incluir um uma interface de usuário gráfica (GUI) e é adaptado para se comunicar com os agentes distribuídos. Por exemplo, ele pode distribuir fluxos de trabalho, chamar os agentes distribuídos para invocar uma operação em um recurso administrado e executar tarefas administrativas.

[028] Modelo de informação: este é a coleção de informações relacionadas com todos objetos administrados. Esta informação é preferivelmente disposta em tipos (ou categorias) de informação, cada um destes sendo relacionado, por sua vez, com um dado tipo de objeto administrado (por exemplo, um computador pessoal, e assim por diante). Um objeto administrado é um de qualquer número de características específicas de um dispositivo administrado. Em um ambiente de administração de rede, dispositivos administrados são elementos de rede e objetos administrados são equipamentos tais como: cartões, portas, conexões físicas e lógicas, etc.

[029] Proxy: um objeto de proxy é um componente que media o controle de acesso para o objeto atual, por exemplo, um elemento de rede, no qual se situa uma funcionalidade.

[030] Máquina de regra: uma máquina de regra é um sistema para separar regras de negócios (logicamente e/ou fisicamente) a partir da lógica de controle e compartilhá-las através de armazenamentos de dados, interfaces de usuário e aplicativos. Estando uma vez as regras separadas e compartilhadas, a máquina de regra permite aos usuários modificá-las sem fazer alterações em outros módulos de aplicativo. Uma máquina de regra é basicamente um sofisticado interpretador de declaração if/then. As declarações if/then que são interpretadas são chamadas regras. As porções ‘if’ das regras contêm condições, tais como ‘item.príce > $100’. As porções ‘then’ das regras contêm ações, tais como “recommendDiscount (5%)’. As entradas para uma máquina de regra são um conjunto de regras e alguns objetos de dados. As saídas da máquina de regra são determinadas pelas entradas e podem incluir os objetos originais de dados de entrada com possíveis modificações, novos objetos de dados e efeitos laterais. Uma máquina de regra é usada para decidir, no tempo de operação, quais regras se aplicam e como estas devem ser executadas.

[031] Fluxo de trabalho: um fluxo de trabalho é essencialmente a automação total ou parcial, por exemplo, de um processo de negócios, onde documentos, informação ou tarefas são passadas de um participante para um outro para a ação, de acordo com um conjunto de regras procedimentais. Um fluxo de trabalho pode ser representado através de um fluxograma com uma seqüência de tarefas e dependências temporais e lógicas entre tarefas, incluindo ramos alternativos ou paralelos. Um fluxo de trabalho pode também ser descrito como uma máquina de estado finito ou com linguagens descritivas, tais como XPDL (Linguagem de Descrição de Processo XML).

[032] Máquina de fluxo de trabalho: uma máquina de fluxo de trabalho é o componente em um programa de automação de fluxo de trabalho que possui toda a informação relacionada com os procedimentos, etapas em um procedimento, e as regras para cada etapa. A máquina de fluxo de trabalho determina se o processo está pronto para se mover para a próxima etapa. Mencionado de maneira breve, uma máquina de fluxo de trabalho é um componente adotado para executar fluxos de trabalho.

[033] Como mostrado no diagrama da figura 1, a disposição revelada aqui é baseada em uma arquitetura incluindo vários tipos de componentes, mais precisamente: - uma coleção de conjuntos de proxy de recurso RP1,..., RPn; RP1..., RPm, com adaptadores de protocolo associados PAl,...PAi; PAl,...Paj, - uma coleção de aplicativos de agente AA1,... AA2, - um aplicativo de administrador (lógico) - MA, - um inventário de rede centralizado - CNI, e - uma base de dados de modelo MDB.

[034] Como melhor detalhado a seguir, a arquitetura em questão (ou plataforma), adaptada para administrar uma rede de telecomunicação N incluindo equipamentos de rede (não mostrados em detalhe, mas de qualquer tipo conhecido).

[035] Estes equipamentos têm interfaces de controle associadas, tais como aquelas indicadas como if_Na, if_Nw, if_Ny, if_Nt na figura 1.

[036] Os proxy de recurso RP1,...., RPn; RP1...., RPm e os adaptadores de protocolo associados PAl,...PAi; PAl,...Paj, essencialmente compreendem uma camada de base que faz o proxy das interfaces if_Na, if_Nw, if_Ny, if_Nt por meio do desacoplamento delas a partir das funções de administração.

[037] Os agentes AAs, por sua vez, compreendem uma comunidade de agentes que coordenam a operação da camada de base (PA, RP) a fim de suportar funcionalidades de administração distribuídas.

[038] A camada de base e a camada de suporte constituem camadas superpostas separadas na arquitetura.

[039] A base de dados MDB, o ponto simples (lógico) de definição e armazenamento de todos aspectos comportamentais e funcionais da plataforma, fluxos de trabalho, regras, modelos de informação e esquemas. A plataforma automaticamente distribui estas definições para os componentes de plataforma. A base de dados de modelo é estritamente ligada com a parte de catálogo do sistema de inventário de rede.

[040] Sendo a fonte de todos processos e definição de dados comum, a base de dados MDB é inerentemente sincronizada com as funcionalidades oferecidas pelos diferentes componentes e os modelos de informação usados para representar recursos e serviços. Isto representa uma propriedade principal para o operador da arquitetura, do qual não é requerido recuperar informação a partir de uma enorme quantidade de documentação provida pelos diferentes vendedores de componentes, com o risco de falhar em ser alinhada com todos os componentes de operação.

[041] Na forma de realização mostradas, processos são segmentados em três camadas com funções específicas. Esta escolha é pretendida para satisfazer duas necessidades: tendo o menor número possível de camadas (desta maneira evitando a complexidade das arquiteturas convencionais) e permitindo livre alocação de processos entre uma implementação distribuída e uma centralizada.

[042] Isto implica na presença de uma camada centralizada 1 (que corresponde ao aplicativo de administrador MA), uma camada totalmente distribuída 2 (que corresponde aos aplicativos de agente - daqui por diante, resumidamente, AAs) mais uma camada de proxy independente 3 que desacopla a rede a partir da plataforma de administração. Esta segmentação também permite a provisão de duas visões de serviço diferentes, por exemplo, uma visão de negócios pela camada 1, uma visão de realização pela camada 2 e uma visão de engenharia pela camada 3. Será apreciado que, com referência ao aplicativo de administrador MA e à camada composta dos aplicativos de agente AAs, AAs não excluem a possibilidade que os componentes respectivos possam ser pelo menos parcialmente dispostos no mesmo local geográfico.

[043] Adaptadores de protocolo (daqui por diante, resumidamente, PA) são tipicamente dispostos em conjuntos, cada conjunto sendo responsável por interfacear todos os equipamentos de rede de uma área designada que oferece o mesmo protocolo de interface de programação de aplicativo (API), por exemplo SNMP (Simple NetWork Management Protocol), Telnet, TL1, etc. Cada PA oferece, como um serviço proporcionado aos proxy de recurso RP, a execução de operações básicas no equipamento; exemplo para um adaptador de protocolo SNMP são: conseguir (parâmetros), ajustar (parâmetros).

[044] Cada proxy de recurso (daqui por diante, resumidamente, RP) é responsável pela criação, manutenção e administrar de uma assim chamada “imagem” de um único equipamento na rede N. a imagem é uma representação da configuração do equipamento de acordo com um definido modelo de informação.

[045] O alinhamento da imagem com a rede é efetuado da seguinte maneira: - todas as ações que a plataforma de administração executa na rede são atualmente feitas por RPs chamando operações através de apropriados PAs; - todas as notificações (como alarmes, armadilhas) enviadas pelos equipamentos são recebidas pelos proxy\ isto não previne que equipamentos enviem notificações também para outros destinos; - verificação periódica de alinhamento entre a imagem do equipamento e o equipamento propriamente dito é executada pelos proxy de recurso (RPs).

[046] A única imagem de equipamento pode ser enriquecida pela informação de administrador de elemento (EM), tal como, por exemplo, informação inter-equipamentos, como topologia, para dar uma visão de final-a-final de serviços espalhados através de múltiplos equipamentos, e outra informação disponível no EM.

[047] Cada RP roda processos típicos do nível de RP usando um executor de processo (PE): estes processos podem ser definidos processos de “camada 3” e podem ser estruturados em subcamadas. Processos no topo da camada 3 podem ser chamados extemamente, assim eles são os serviços que cada RP oferece ao aplicativo (s) de agente associado (s). Eles representam as operações que podem ser executadas atomicamente (desta maneira como uma única transação) no equipamento que o RP administra.

[048] Exemplos de serviços oferecidos pelo RP são: configurar porta, criar conexão cruzada, modificar atributo de conexão; cada um destes pode incluir seqüências de comandos básicos a serem enviados e/ou recebidos para/pelos equipamentos.

[049] Processos no fundo da camada 3 usam serviços oferecidos por PAs. Um exemplo de um processo de “camada 3” é mostrado na figura 5.

[050] A imagem manipulada por um RP é dinamicamente definida pelo modelo de informação do recurso representado (por exemplo, um dado equipamento de rede). Este modelo e definido pela interface de GUI, armazenado na base de dados MDB, então distribuído pelo aplicativo de administrador para os RPs. Estes carregam o modelo e finalmente instantiate o mesmo com valores recuperados pelo recurso. Novamente, a instancialização é executada de uma maneira flexível usando o PE.

[051] Desta maneira, alterações e adições dos modelos de informação (como atualização de versão, introdução de novo equipamento) não requerem qualquer alteração apreciável de software nos componentes de plataforma. Isto atinge um alto grau de flexibilidade, na medida em que o protocolo de equipamento API é suportado pelo PA. A evolução muito lenta de protocolos (CNMP telnet) em comparação com o alto desempenho requerido a partir de PAs, faz o uso de PE para implementar PAs uma escolha menos preferida.

[052] Como um componente fundamental da plataforma de administração, o CNI de inventário de rede é disposto em duas partes, mais precisamente: um inventário de rede distribuído (DNI) e um inventário de rede centralizado (CNI).

[053] O último (isto é, o DNI) é a coleção de todas virtualizações (imagens) contidas em todos os RPs; ele é usado para todas tarefas em tempo real ou quase em tempo real, como aprovisionamento, seguro, desempenho, controle, e assim por diante, onde informação atualizada na configuração e estado da rede é necessária para a precisão e efetividade da tarefa. Estas tarefas em tempo real são difíceis de realizar por contar com uma base de dados logicamente centralizada, como é o caso em implementações correntes de inventário de rede.

[054] A última parte (isto é, o CNI) corresponde ao conceito usual de um componente de inventário de rede. Ela é usada para tarefas em tempo real onde atualizações contínuas não são possíveis para uma arquitetura centralizada. Exemplo de tais tarefas são desenho de rede, planejamento de rede, análise de tendência de capacidade.

[055] O inventário de rede centralizado é periodicamente atualizado, recuperando informação a partir dos RPs.

[056] Proxies podem interagir uma com a outra diretamente para serviços que requerem simples inter-trabalho. Por exemplo, para ajustar um percurso de final-para-final, um dado AA pode usar a informação de topologia (qual equipamento é conectado com outro), armazenada nos respectivos RPs.

[057] Cada AA é responsável pela coordenação de um conjunto respectivo de RPs e pela execução de processos típicos da camada de agente por meio do uso de um PE. Estes processos têm que ser executados em uma maneira distribuída e podem ser estruturados em subcamadas. Processos no topo desta “camada 2” podem ser extemamente chamados; assim estes são os serviços que um AA oferece para o aplicativo de administrador MA. Estes serviços são caracterizados por serem independentes de vendedor e de tecnologia, por exemplo, “criar um serviço de DSL”, resultando em diferentes seqüências de ações, se a tecnologia de rede é ADSL ou VDSL e se o vendedor é o vendedor XX ou o vendedor YY. Os processos no fundo da camada 2 usam serviços (isto é, chamam processos) oferecidos pelos RPs.

[058] Cada AA não requer atualização de software para suportar novos serviços e tecnologias. Isto é devido à flexibilidade dos processos que são recebidos pelo aplicativo de administrador MA, carregado e executado pela camada AA.

[059] AAs interagem uns com os outros através de um protocolo de comunidade (um mecanismo que passa mensagens) para suportar a execução distribuída de funcionalidades de administração, por exemplo, projeto de circuito distribuído.

[060] Cada AA é responsável pela monitoração de desempenho local a fim de informar o administrador com respeito ao estado de desempenho.

[061] O aplicativo de administrador MA é responsável pelas seguintes tarefas: - administrar a distribuição de processos e os modelos de informação correlatos de “camada 2” e “camada 3” a partir da base de dados MDB para os vários AAs e RPs por meio da recuperação de definições de processo a partir da base de dados MDB; - monitoração do estado da plataforma com informação provida pelos AAs (e possivelmente os RPs), incluindo distribuição de componentes, administração de domínio (partição de toda a rede entre os AAs), monitoração de desempenho e conseqüentes ações, tais como distribuição de carga entre os AAs, a fim de atingir o balanço de carga apropriado; - interações com sistemas externos, como outros sistemas de suporte de operação (OSSs) e sistemas de suporte de fatura (BSSs); - execução de processos típicos da camada de administrador (como melhor detalhado a seguir).

[062] Processos de tal “camada 1” podem ser dispostos em substancialmente-camadas e são caracterizados para prover funcionalidades que requerem interação com equipamentos externos (diferentes dos AAs) ou coordenação entre agentes que não podem ser facilmente ou eficientemente executados em uma maneira distribuída pelos AAs. A maior flexibilidade da arquitetura permite suave evolução: por exemplo, a melhoria do protocolo de comunidade pode permitir a migração de um processo da camada 1 para a camada 2.

[063] Os executores de processo para cada camada são destinados a ser um fluxo de trabalho (um fluxograma, uma máquina de regra, ou uma combinação dos dois. Por exemplo, um processo de aprovisionamento é melhor representado como um fluxograma, enquanto uma correlação de alarme é melhor representada como uma combinação de regras. Esta combinação permite ao administrador da plataforma ajustar qualquer funcionalidade de FCAPS e deixá-la evoluir com um alto grau de flexibilidade. Quando possível e recomendável, o uso de fluxos de trabalho é preferido, pois isto evita a complexidade de se comportar com conflitos de regras e administração de regras.

[064] As máquinas de processo são embutidos nos MAs, AAs e RPs; de fato, um local externo causaria chamadas remotas, provavelmente para produzir degradações de desempenho.

[065] Os vários MAs, AAs e RPs mostram tanto um comportamento reativo quanto um comportamento proativo, pois eles são disparados em eventos, mas podem também iniciar processos.

[066] Cada um dos AAs e dos RPs bem como o MA podem suportar qualquer funcionalidade de FCAPS. Isto permite a customização de tarefa de componentes e realocação com base em prioridade de tarefa e necessidades de recurso, por exemplo, por meio de alocação de uma maioria de agentes durante o turno matinal para prestar serviço ao aprovisionamento e uma maioria de agentes durante o turno noturno para a otimização da rede.

[067] A mobilidade de agente é útil para mover agente entre máquinas a fim de solucionar o entendimento de agente bem como problemas de tolerância de falha. Se, por alguma razão, um agente “esgotar”, um novo agente pode ser instanciado e movido para uma outra máquina em funcionamento para substituir o agente não disponível. O MA periodicamente monitora a presença de agentes AA; se qualquer um destes “esgotar”, então o MA pode ativar a “ressurreição” do agente através de mobilidade.

[068] A mobilidade de agente é também útil para mover agentes entre máquinas para solucionar problema de balanço de carga. Isto pode ocorrer quando, por exemplo, um AA continuamente verificado por meio de um MA para rodar um processo, por exemplo, um processo de ativação de ADSL, pode se tomar um estorvo, levando à lentidão de operação. Um novo agente AA pode ser instanciado e movido ou para a máquina onde o agente AA supercarregado roda (a fim de distribuir chamadas de processo que provêm do MA) ou para uma máquina com uma menor carga de CPU.

[069] O agente AA comunica as condições correntes de carga ao MA, após o que o MA executa as ações requeridas, por exemplo, por meio da implementação de mobilidade de agente. O MA, desta maneira, decide se agentes devem ser movidos ou não, para manter o controle da disseminação de agentes.

[070] A arquitetura descrita é, desta maneira, intrinsecamente adaptiva e pode detectar e predizer saturação.

[071] Uma preferida forma de realização da disposição aqui descrita usa JADE (Framework Java Agent Development) para implementar agentes com características de mobilidade, o modelo SID (citado na porção introdutória desta descrição) para definir o modelo comum, BPML (Bussiness Process Modeling Language) para definição de processo, e JESS {Java Expert System Shell) para implementação de PE.

[072] Como um primeiro exemplo, um cenário de aprovisionamento de três camadas pode ser considerado.

[073] Especificamente, a figura 2 representa a preparação de um cenário de aprovisionamento de serviço mostrando a flexibilidade e escalabilidade atingidas.

[074] Um serviço de banda larga “Oferta 1” deve ser fornecido em uma rede TLC, que inclui dispositivos de acesso (ex. ADSL Equipamento ADSL E), um backbone ATM e um ou mais servidores de acesso de banda larga BAS a fim de atingir conectividade de IP.

[075] AA1, AA2, AA3 são os agentes que administram, respectivamente: - o proxy de recurso RP1 que representa a imagem do Equipamento ADSL (isto é, isto é, o ponto final do circuito final-a-final), - o proxy de recurso RP2 que representa a imagem do comutador ATM conectado com o Equipamento ADSL, e - o proxy de recurso RP3 que representa a imagem do BAS (isto é, o ponto final Z do circuito de final-a-final).

[076] Os fluxos de trabalho de múltiplos níveis envolvidos na atividade de aprovisionamento do serviço “Oferta 1” são mostrados na figura 3.

[077] Especificamente, o fluxo de trabalho de nível 1 (figura 3a, à esquerda) consiste de duas etapas ou tarefas. A primeira (conectividade ADSL, designada com 100) é explodida em um fluxo de trabalho de nível 2 que é executada no nível AA, enquanto uma tarefa de caixa de correio (geralmente designada com 102, mas não detalhada neste exemplo) pode ser executada por uma plataforma OSS externa.

[078] A tarefa de conectividade ADSL é, desta maneira, um fluxo de trabalho de nível 2 W2, como detalhado na porção à direita da figura 3a, que consiste de uma seqüência de fluxos de trabalho de nível 3, dependente de tecnologia e de venda, os quais são executados no nível de proxy de recurso, como detalhado na figura 3b.

[079] Especificamente, a referência 104 denota uma etapa que leva a uma escolha entre os vendedores A, B e C, provendo o equipamento ADSL, o comutador ATM, e o BAS da figura 2, respectivamente. As etapas 106a, 106b, 106c, indicam a criação de respectivas portas para estes vendedores, as quais são subseqüentemente providas com respectivas conexões virtuais (VCC) nas etapas 108a, 108b, 108c. A etapa 110 designa a possível adição de um endereço de IP ao término de VCC para o ramo do vendedor C.

[080] Finalmente, os fluxos de trabalho de nível 3 são seqüências dos comandos que têm que ser executados no equipamento por meio do proxy de recurso através dos adequados adaptadores de protocolo.

[081] A figura 4 mostra o diagrama de atividade dos vários componentes de software, representados na figura 2, exceto para o agente AA3 e o proxy de recurso RP3.

[082] As ações “Encontrar agente” e “Encontrar o proxy” são executadas pelo aplicativo de administrador MA ou pelos componentes distribuídos (agente de aplicativo AA ou proxy de recurso RP) na base de algoritmo de desenho de circuito distribuído, não detalhado nesta invenção (qualquer bem conhecido algoritmo que encontra percurso pode ser usado para esta finalidade). Estas ações, executadas através de uma estrita colaboração entre agentes de aplicativo e proxy de recurso são necessárias para encontrar o percurso entre o ponto final A e o ponto final Z do circuito a ser aprovisionado.

[083] Esta proposta é muito flexível com respeito a alterações de administrar em cada camada.

[084] De fato, qualquer alteração na visão de negócios do serviço é levada em conta por meio de apenas modificação na base de dados MDB, a camada 1 os processos envolvidos e modificando-os para o MA.

[085] Cada alteração na visão da rede do serviço (por exemplo, algum equipamento é substituído pelo equipamento ADSL D) é levado em consideração por apenas modificar na base de dados MDB os processos de camada 2 envolvidos (isto é, por meio da adição de novo ramo) e distribuídos por MA para os AAs.

[086] Cada alteração na visão de engenharia do serviço (por exemplo, uma atualização de firmware em um nó) é levada em conta apenas por meio da modificação nos dados de MDB dos processos de camada de base 3 envolvidos.

[087] Neste cenário, é considerado que um adaptador de protocolo, adequado para o novo equipamento, já está disponível.

[088] Como um segundo exemplo, a mesma disposição descrita precedentemente será considerada no caso de um cenário de falha: o serviço "Oferta 1" é considerado que está interrompido por algumas razões, e uma correspondente mensagem de múltiplas funções é exibida no console de MA.

[089] A figura 6 ilustra um exemplo de fluxos de trabalho de múltiplos níveis, misturados com máquinas de regra que podem arranjar-se com estas circunstâncias.

[090] O processo de nível 1 é novamente um fluxo de trabalho e requer que a mensagem de alerta seja exibida em um console do MA quando a conectividade ADSL 100 ou o sub-serviço de Caixa de Correio 102 falha com informação adicional acerca das razões de falha (ver a figura 6a, esquerda).

[091] O processo de nível 2 (figura 6a, direita) é propelido por regra: o aplicativo de agente KB (Base de Conhecimento) contém todos dados relevantes (por exemplo, status de recursos de rede, alarmes ativos) coletados de vários eventos, da Rpa, mas também de outros AAs. A regra "Falha no percurso ADSL" é um exemplo de correlação de alarme (mais precisamente, correlação de fato). Por exemplo, quando a regra se tomar verdadeira (etapa 200) ela envia (em uma etapa 202) um novo evento para o nível 1 PE (dentro do MA).

[092] O processo de nível 3 (mostrado na figura 6b no caso de verificação de falha de porta, por exemplo, do equipamento do Vendedor A) é novamente propelido por regra: uma regra é executada (etapa 204) tão logo o RP receber um evento a partir de PA, como uma armadilha de SNMP. Esta regra obtém uma maior informação do estado de porta (etapa 206) através de interoperação de PA. Após a verificação na etapa 208, se o estado de porta está operacional, ele alerta o AA, se necessário, na etapa 210.

[093] A figura 7 mostra o diagrama de atividade para os vários componentes de plataforma.

[094] Este caso considera que PAI (um adaptador de protocolo SNMP) recebe uma armadilha SNMP com informação "Port X deficiente" em um recurso espelhado por RP1, ao longo do percurso ADSL para o serviço "Oferta 1". A máquina de regra em RP1 ativa a regra "Verificar falha de porta", então propaga o evento para AA1. AA1 aceita o evento o armazena em KB.

[095] Outros eventos, em diferentes ordens e tempos, podem adicionar fatos no IM-AALa partir de quaisquer RPs sob o escopo AAI (por exemplo, regra B e regra C). Fatos em KB podem criar regras a fim de enviar eventos para outro A A (por exemplo, de AA2 para KBAA1), por meio de correlação de alarmes inter-AA. Quando a condição na regra AA1 "Verificar percurso ADSL" se tornar verdadeira, o fluxo de trabalho c executado e um novo evento é enviado para MA1, com informação lida a partir de fatos adaptados pela regra, [096] Finalmente, o fluxo de trabalho executado em MAI causa com que um alarme, como "Offer 1 Service fault link between RPl e RP2 fault", apareça no console conectado com MA.

[097] Uma vantagem principal da disposição mostrada se situa na redução de tráfego de rede em virtude de sinalização de alarme. Cada componente (RP, AA e também MA) toma parte em processamento de alarme em diferentes níveis de abstração. Desta maneira, a função de correlação de alarme pode ser implementada (por exemplo, no nível dos agentes A As) muito próxima das possíveis fontes de alarme. Esta proposta reduz o tráfego de rede em virtude dos alarmes terem que ser enviados para um sistema central. A flexibilidade inerente na definição de fluxos de trabalho e regras permite a introdução de novo equipamento com mínimo esforço (mesma vantagem descrita no caso de aprovisionamento).

[098] Um terceiro exemplo destaca a flexibilidade da administração de equipamento através da configuração de fluxo dc trabalho de nível 3.

[099] Este exemplo é testemunha da flexibilidade na modulação de modelo de dado: após a adição de um novo tipo de equipamento em uma rede, por meio de exatamente redefinição (por exemplo, por meio de um GUI adaptado para administrar em arquivos XML, de modo amigável ao usuário, por exemplo) o modelo de mapeamento, a camada de proxy automaticamente cria e mantém uma representação sincronizada do novo equipamento, enquanto a operação de todas as funcionalidades de FCAPS é da camada distribuída nunca é descontinuada.

[0100] Especificamente, este exemplo é pretendido para mostrar como a disposição exposta pode manipular flexivelmente e facilmente uma torça de modelo de dados para um equipamento com características dependentes de vendedor e tecnologia. Em suma, o processo de substituir um equipamento de Vendedor A por um equipamento de Vendedor B requer apenas atualização do modelo de dados (se alterado) e modificação dos processos de fluxo de trabalho de nível 3. Os RPs são capazes de reconhecer o novo equipamento e utilizar o novo modelo de dados e os fluxos de trabalho de nível 3 para povoar o modelo de dado.

[0101] A título de exemplo, um comutador ATM e o cenário pertinente são mostrados na figura 8.

[0102] O modelo de dados comum CMD (complacente com um modelo comum, como TMFs SID ou DMTF's CIM) é especificado usando um arquivo de esquema XML (xsd) armazenado na base de dados MDB juntamente com processos de nível 3. As tabelas de dados de catálogo no inventário de rede de um CNI contêm os dados de catálogo de equipamento (informação característica necessária para descrever os recursos de rede, freqüentemente referidos também como " “metadata” ou "templates). O proxy de recurso RP representa o equipamento de Comutador ATM de um vendedor "A". Ele contém a imagem EI do equipamento de ATM. Tanto os dados de catálogo quanto a imagem de equipamento são validados usando um modelo de dados comum, especificado no arquivo xsd.

[0103] O exemplo de modelo de dados TM considera o caso representado na figura 9. Um operador precisa substituir um comutador ATM do vendedor "A" por um comutador ATM do Vendedor "B".

[0104] Este processo inclui um num de subtarefas que o operador tem que realizar.

[0105] Uma primeira subtarefa é instalar o equipamento de hardware com o qual esta tarefa trabalha, com a instalação física da nova peça de equipamento.

[0106] Uma segunda subtarefa é inserir o novo equipamento no catálogo. Usuários têm que inserir a nova característica de equipamento no catálogo (por exemplo, o nome de novo vendedor). É considerado que os dados de catálogo comuns são armazenados em um Inventário de rede (CNI) centralizado OSS.

[0107] Uma terceira subtarefa é reescrever os níveis de trabalho de nível 3. Isto é necessário a fim de se poder administrar o novo equipamento (usando os novos comandos de equipamento, dependentes de vendedor) e trabalhar com a nova imagem de equipamento (por meio dos adequados novos comandos para encher a imagem de memória de proxy de Recurso.

[0108] Uma porção dos fluxos de trabalho de nível 3, envolvida na administração de modelo de dados de proxy de recurso, é mostrada na figura 10. As porções de fluxo de trabalho mostradas se ocupam com a administração de dados de cartões de equipamento.

[0109] Os fluxos de trabalho em questão contêm os seguintes tipos de comandos: [0110] Comando de equipamento: comandos de equipamento, dependentes de vendedor, executados por meio do proxy de Recurso através de adequados adaptadores de protocolo (por exemplo, conseguir cartão A ou conseguir cartão B - etapa 300).

[0111] Comando CNI: os comandos executados na CNI (por exemplo, inventário conseguir Info de catálogo (... etapa 302) para perguntar informação de catálogo;

[0112] Comando de Imagem de proxy de Recurso: comandos executados pelo proxy de recurso para atualizar (ou criar) sua imagem de equipamento (por exemplo: image.setAttribute (...) etapa 310).

[0113] Em seguida à verificação (etapa 304) quanto à disponibilidade de um objeto que representa um cartão (caso negativo, o objeto sendo criado na etapa 306), a porção de fluxo de trabalho permite se chegar aos vários atributos de cartão (denominados valores de Attributol, Attributo2, Attributo3) a partir do equipamento (etapa 308) e então atualizar (na etapa 310) a imagem de proxy de recurso com os valores recuperados.

[0114] As diferenças de equipamento dependentes de vendedor, afetam o fluxo de trabalho de nível 3. Na verdade, o novo cartão de equipamento do Vendedor B (Cartão B) contém apenas um atributo (denominado atributo X). Por conseguinte, o novo fluxo de trabalho pode ser representado novamente com a figura 10, onde as etapas 308 e 310 contêm comandos para se chegar apenas ao valor X de atributo a partir do equipamento e atualizar a imagem de RP conseqüentemente.

[0115] O código XML abaixo mostra uma versão XML, complacente com o modelo de dados comum, da imagem de proxy de recurso, subsequentemente à execução do fluxo de trabalho de nível 3 para o equipamento do vendedor A. <Card id= “ID2333” name ="Card A”> <Additional Attribute name ="Vendor" value = “A”/> Additional Attribute name =" Attribute 1” value=111117> <Additional Attribute name ="Attribute 2” value= “222"/> <Additional Attribute name ="Attribute 3” value= “333”/> <Physical Port id =”IDI" name ="Port A"> <Additional Attribute name ="Attribute 1” value= “1117> <AdditionaI Attribute name ="Attribute 2" value=”222"/> <AdditionaI Attribute name ="Attribute 3” value ”333 /> </Physical Port> <Physical Port id= “ID2" name ="Port B”> <AdditionaI Attribute name ="Attribute 1” value = “aaa"/> <AdditionaI Attribute name ="Attribute 2” value = “bbb"/>

Additional Attribute name ="Attribute 3” Value = “ccc"/> </Physical Port> </Card>

[0116] O outro código XML abaixo mostra uma versão XML, complacente com o modelo de dados comum, para a imagem de proxy de recurso, subsequentemente à execução do nível 3 do equipamento de vendedor B. <Card id= “ID4503” name ="Card B” > <Additional Attribute name ="Vendor" value = “B”/> <Additional Attribute name = “Attribute X” value = “XXX"/> <Physical Port id = “ID1” name ="Port A"> <Additional Attribute name ="Attribute X” value= “1117>

Physical Port> <Physical Port id= “ID2" name ="Port B"> <Additional Attribute name ="Attribute X” Value = “aaa"/> </Physical Port>

Physical Port id="ID3" name ="Port C"> <Additional Attribute name ="Attribute X” value = “yyy"/> </Physical Port> </Card>

[0117] A figura 11 mostra o diagrama de atividade dos componentes de plataforma de análise, envolvidos na administração de modelo de dados de proxy de recurso. O GUI é destinado para ser a interface gráfica de usuário, usada por meio de um operador humano para trabalhar na MDB e para controlar o MA. "Eqpt" está para o equipamento "ATM comutador".

[0118] O novo equipamento com suas características dependentes de vendedor é, deste modo, administrado de uma maneira flexível e simples. Por exemplo, o processo de substituir um equipamento de Vendedor A equipamento de vendedor E envolve somente a configuração dos dados de catálogo do inventário e do fluxo de trabalho do novo nível 3. Os agentes são capazes de reconhecer o novo equipamento no catálogo de novo fluxo de trabalho de nível 3, associado, e usar estes para administrar o novo equipamento e sua imagem de proxy de recurso.

[0119] A disposição descrita pode ser estendida para um num de camadas maior que três, onde a camada de agente pode ser estruturada em uma hierarquia. Preferivelmente, a camada de proxy não é dividida a fim de evitar a introdução de estorvos nas interações de rede; também, a evolução de equipamento pode resultar na camada de proxy ser disposta nos equipamentos, quando eles irão oferecer interfaces-padrão com um modelo de dados unificado. Se todas funcionalidades puderem ser implementadas quando distribuídas, uma camada separada de administrador/coordenador pode ser também dispensada por promover alguns agentes para tarefas de comunicação externas.

[0120] É, assim, evidente que, os princípios básicos da invenção permanecem os mesmos, os detalhes e formas de realização podem variar amplamente com respeito ao que foi descrito e ilustrado puramente por exemplo, sem fugir do escopo da invenção apresentada, como definida nas reivindicações anexas.

REIVINDICAÇÕES

Claims (34)

1. Sistema para administrar uma rede de comunicação (N) incluindo equipamentos de rede, ditos equipamentos tendo interfaces de controle associadas (if_Nd, if_Nw, if_Ny, if_Nt), caracterizada pelo fato de que o sistema compreende: - uma camada de base (PA, RP) para realizar o proxy das ditas interfaces (if_Na, if_Nw, if_Ny, if_N,) e para desacoplar as ditas interfaces (if_Nü, if_Nw, if_Nj, if_N|) a partir das funções de administração, dita camada de base compreendendo executores de processo (PE) distribuídos para executar, de uma maneira distribuída., processos referentes à administração de dita rede, cada executor de processo compreendendo pelo menos uma de uma máquina de fluxo de trabalho, uma máquina de regra e uma combinação das mesmas, e - uma camada de suporte (AA) sobreposta à dita camada de base c composta por uma pluralidade de agentes coordenando a operação da dita camada de base (PA, RP) a fim de suportar funcional idades de administração distribuídas, em que dita camada base inclui uma subcamada de módulos de proxy de recurso (RP), cada módulo de proxy (RP) provendo uma representação da configuração de pelo menos um equipamento de rede, de acordo com um modelo de informação definido, e sendo configurado para alinhar dita representação para pelo menos um equipamento de rede por: - executar ações de administração em dita rede (N); - receber em ditos módulos de proxy de recursos (RP) as notificações enviadas por pelo menos um equipamento de rede; e - executar verificações periódicas de alinhamento entre a representação do equipamento de rede e o equipamento de rede.

2. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que ditos módulos de proxy de recursos podem suportar funcionalidades FCAPS.

3. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que a camada de base inclui: - uma subcamada de adaptadores de protocolo (PA) para interfacear um conjunto de equipamentos de rede oferecendo um dado protocolo; e em que a etapa de executar ações de administração é feita invocando operação através de pelo menos um adaptador de protocolo (PA) associado.

4. Sistema, de acordo com qualquer uma das reivindicações 1 a 3, caracterizado pelo fato de que os módulos de proxy de recurso (RP) são configurados para alinhar dita representação com o pelo menos um equipamento de rede, executando todas as ações de administração na dita rede (N), e em que todas as notificações enviadas por pelo menos um equipamento de rede são recebidas em ditos módulos de proxy de recurso.

5. Sistema, de acordo com qualquer uma das reivindicações 1 a 4, caracterizado pelo fato de que os ditos módulos de proxy de recurso (RP) são configurados para enriquecimento com informação de administrador de elemento.

6. Sistema, de acordo com qualquer uma das reivindicações 1 a 5, caracterizado pelo fato de que os ditos módulos de proxy de recurso (RP) são configurados para rodar processos usando ditos executores de processo (PE).

7. Sistema, de acordo com qualquer uma das reivindicações 1 a 6, caracterizado pelo fato de que os ditos módulos de proxy de recurso (RP) são configurados para interagir diretamente um com o outro em uma relação de inter-trabalho.

8. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que os ditos agentes (AA) na dita comunidade são configurados para rodar serviços independentes de venda e de tecnologia.

9. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que inclui pelo menos um aplicativo de administrador (MA) configurado para executar funções selecionadas do grupo consistindo de: - administrar distribuição de processos entre a dita camada de base e a dita camada de suporte, - administrar distribuição de modelos de informação entre a dita camada de base e a dita camada de suporte, - monitorar o estado da arquitetura na base de informação provida pelos ditos agentes (AA) na dita comunidade, - interagir com sistemas externos, e - executar processos de administração.

10. Sistema, de acordo com a reivindicação 9, caracterizado pelo fato de que o dito pelo menos um aplicativo de administrador (MA) compreende uma camada superior adicional, separada, no dito sistema.

11. Sistema, de acordo com a reivindicação 9, caracterizado pelo fato de que o dito pelo menos um aplicativo de administrador (MA) é pelo menos parcialmente integrado na dita camada de suporte (AA).

12. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que todas as ditas camadas na dita arquitetura incluem executores de processo (PE).

13. Sistema, de acordo com a reivindicação 12, caracterizado pelo fato de que cada um dos ditos executores de processo (PE), em cada uma das ditas camadas, compreender pelo menos uma de uma máquina de fluxo de trabalho, uma máquina de regra e uma combinação das mesmas.

14. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que o dito sistema inclui agentes (AA) recebidos em diferentes máquinas, os ditos agentes sendo móveis entre diferentes máquinas.

15. Sistema, de acordo com a reivindicação 1, caracterizado pelo fato de que as ditas camadas (PA, RP; AA; MA) no dito sistema incluem componentes adaptados para executar respectivas funções baseadas em respectiva informação de instrução provida a eles e de que uma base de dados (MDB) é provida armazenando a dita informação de instrução, o sistema sendo disposto para distribuir a dita informação de instrução a partir da dita base de dados (MDB) para os ditos componentes.

16. Sistema, de acordo com a reivindicação 15, caracterizado pelo fato de que a dita informação de instrução compreende pelo menos um de: - definições de processo, tais como fluxos de trabalho e regras, e - definições de modelo de dados.

17. Sistema, de acordo com a reivindicação 15, caracterizado pelo fato de que inclui pelo menos um aplicativo de administrador (MA) configurado para administrar distribuição de modelos de informação entre a dita camada de base e a dita camada de suporte, e de que a dita base de dados (MDB) é associada com o dito pelo menos um aplicativo de administrador.

18. Método para administrar uma rede de comunicação (N) incluindo equipamentos de rede, os ditos equipamentos tendo interfaces de controle associadas (if_N«, if_Nw, if_Ny, if_Nt), caracterizado pelo fato de que o método compreende as etapas de: - prover uma camada de base (PA, RP) realizando proxy das ditas interfaces (if_Na, if_Nw, if_Ny, if_Nt) e desacoplando as ditas interfaces (if_N«, if_Nw, if_Ny, if_Nt) a partir das funções de administração, - executar, em dita camada de base (PA, RP), processos distribuídos relativos à administração de dita rede, cada um dos ditos processos compreendendo pelo menos um fluxos de trabalho, regras e combinação dos mesmos, e - suportar funcionalidades de administração distribuídas através de uma camada de suporte (AA) sobreposta a dita camada de base (PA, RP) e composta por uma pluralidade de agentes coordenando a operação da dita camada de base (PA, RP); - prover uma subcamada de módulos de proxy de recurso (RP), cada módulo de proxy (RP) provendo uma representação da configuração de pelo menos um equipamento de rede de acordo com um modelo de informação definido e sendo configurado para alinhar dita representação para pelo menos um equipamento de rede por: - executar ações de administração em dita rede (N); - receber em ditos módulos de proxy de recurso (RP) as notificações enviadas por pelo menos um equipamento de rede; e - executar verificações periódicas de alinhamento entre a representação do equipamento de rede e o equipamento de rede.

19. Método, de acordo com a reivindicação 18, caracterizado pelo fato de que inclui as etapas de incluir funcionalidades de FCAPS por meio de ditos módulos de proxy de recurso (RP).

20. Método, de acordo com a reivindicação 18 ou 19, caracterizado pelo fato de que inclui as etapas de prover: - uma subcamada de adaptadores de protocolo (PA) para interfacear um conjunto de equipamentos de rede oferecendo um dado protocolo; e em que a etapa de executar ações de administração é feita invocando operação através de pelo menos um adaptador de protocolo (PA) associado.

21. Método, de acordo com qualquer uma das reivindicações 18 a 20, caracterizado pelo fato de que os módulos de proxy de recurso (RP) são configurados para alinhar dita representação com pelo menos um equipamento de rede por executar todas as ações de administração na dita rede (N) e em que todas as notificações enviadas por pelo menos um equipamento de rede são recebidas em ditos módulos de proxy de recurso.

22. Método, de acordo com qualquer uma das reivindicações 18 a 21, caracterizado pelo fato de que inclui a etapa de configurar os ditos módulos de proxy de recurso (RP) para enriquecimento com informação de administrador de elemento.

23. Método, de acordo com qualquer uma das reivindicações 18 a 22, caracterizado pelo fato de que inclui a etapa de configurar os ditos módulos de proxy de recurso (RP) para rodar processos usando um executor de processo (PE).

24. Método, de acordo com a qualquer uma das reivindicações 18 a 23, caracterizado pelo fato de que inclui a etapa de configurar os ditos módulos de proxy de recurso (RP) para interagir diretamente um com o outro em uma relação de inter-trabalho.

25. Método, de acordo com qualquer uma das reivindicações 18 a 24, caracterizado pelo fato de que inclui a etapa de configurar ditos agentes (AA) na dita comunidade para rodar serviços independentes de venda e de tecnologia.

26. Método, de acordo com qualquer uma das reivindicações 18 a 25, caracterizado pelo fato de que inclui as etapas de prover pelo menos um aplicativo de administrador (MA) para executar etapas selecionadas do grupo consistindo de: - administrar distribuição de processos entre a dita camada de base e a dita camada de suporte, - administrar distribuição de modelos de informação entre a dita camada de base e a dita camada de suporte, - monitorar o estado das ditas camadas com base na informação provida pelos ditos agentes (AA) na dita comunidade, - interagir com sistemas externos, e - executar processos de administração.

27. Método, de acordo com a reivindicação 26, caracterizado pelo fato de que inclui a etapa de configurar o dito pelo menos um aplicativo de administrador (MA) como uma camada superior separada em adição à dita camada de proxy de base e da dita camada de suporte.

28. Método, de acordo com a reivindicação 26, caracterizado pelo fato de que inclui a etapa de pelo menos parcialmente integrar à dita camada de suporte (AA) o dito pelo menos um aplicativo de administrador (MA).

29. Método, de acordo com qualquer uma das reivindicações 18 a 28, caracterizado pelo fato de que inclui a etapa de prover executores de processo (PE) em todas as ditas camadas.

30. Método, de acordo com a reivindicação 29, caracterizado pelo fato de que inclui a etapa de prover nos ditos executores de processo (PE) pelo menos uma de uma máquina de fluxo de trabalho, uma máquina de regra e combinações das mesmas.

31. Método, de acordo com qualquer uma das reivindicações 18 a 30, caracterizado pelo fato de que inclui as etapas de: - receber pelo menos parte dos ditos agentes (AA) em diferentes máquinas, e - mover os ditos agentes entre diferentes máquinas.

32. Método, de acordo com qualquer uma das reivindicações 18 a 31, caracterizado pelo fato de que inclui as etapas de: - incluir nas ditas camadas (PA, RP; AA; MA) componentes adaptados para executar respectivas funções baseadas em respectiva informação de instrução provida a eles; - prover uma base de dados (MDB) armazenando dita informação de instrução, e - distribuir dita informação de instrução a partir da dita base de dados (MDB) para os ditos componentes.

33. Método, de acordo com a reivindicação 32, caracterizado pelo fato de que inclui a etapa de prover na dita informação de instrução pelo menos um de: - definições de processo, tais como fluxos de trabalho e regras, e - definições de modelo de dados.

34. Método, de acordo com a reivindicação 32, caracterizado pelo fato de que inclui as etapas de: - prover pelo menos um aplicativo de administrador (MA) configurado para administrar distribuição de modelos de informação entre a dita camada de base e a dita camada de suporte, e- associar a dita base de dados (MDB) com o dito pelo menos um aplicativo de administrador.