PT1810523E - Método e dispositivos para reconciliação de informação entre gestor e agente numa rede de gestão - Google Patents

Método e dispositivos para reconciliação de informação entre gestor e agente numa rede de gestão Download PDF

Info

Publication number
PT1810523E
PT1810523E PT05794773T PT05794773T PT1810523E PT 1810523 E PT1810523 E PT 1810523E PT 05794773 T PT05794773 T PT 05794773T PT 05794773 T PT05794773 T PT 05794773T PT 1810523 E PT1810523 E PT 1810523E
Authority
PT
Portugal
Prior art keywords
manager
information
time
agent
objects
Prior art date
Application number
PT05794773T
Other languages
English (en)
Inventor
Lucian Hirsch
Original Assignee
Siemens Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Ag filed Critical Siemens Ag
Publication of PT1810523E publication Critical patent/PT1810523E/pt

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02Standardisation; Integration
    • H04L41/0233Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04Network management architectures or arrangements
    • H04L41/046Network management architectures or arrangements comprising network management agents or mobile agents therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q3/00Selecting arrangements
    • H04Q3/0016Arrangements providing connection between exchanges
    • H04Q3/0062Provisions for network management
    • H04Q3/0087Network testing or monitoring arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0803Configuration setting
    • H04L41/0813Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/0816Configuration setting characterised by the conditions triggering a change of settings the condition being an adaptation, e.g. in response to network events
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/085Retrieval of network configuration; Tracking network configuration history

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Telephonic Communication Services (AREA)
  • General Factory Administration (AREA)
  • Debugging And Monitoring (AREA)

Description

1
DESCRIÇÃO "MÉTODO E DISPOSITIVOS PARA RECONCILIAÇÃO DE INFORMAÇÃO ENTRE GESTOR E AGENTE EM UMA REDE DE GESTÃO" A invenção diz respeito a um método para operar uma rede de gestão de uma rede de telecomunicações, em que o gestor e o agente comunicam um com o outro através da utilização de um objecto modelo, bem como respectivos produtos.
De acordo com os princípios de uma rede de gestão, também designados como princípios TMN (TMN: Telecommunications Management Network), existem vários níveis de gestão para a gestão de um sistema de comunicação - como por exemplo um sistema de comunicações móveis -, em que cada nível à excepção do superior e do inferior possui uma função dupla, nomeadamente uma função de gestor e uma de agente. No sistema de gestão ("managing system") cada nível fora do mais baixo exerce uma função de gestor para o nível que se encontra imediatamente abaixo. No sistema gerido ("managed system") cada nível, com excepção do superior, corresponde a uma função de agente com o nível superior.
Os gestores iniciam a supervisão da rede e o controle de operações, em que enviam os denominados „requests", que são executados por agentes, e recebem comunicações de retorno correspondentes, as denominadas «responses", dos agentes. Os elementos da rede de telecomunicações, também denominados como recursos da rede de telecomunicações, que exercem o papel de agentes na hierarquia TMN, reconhecem eventos relevantes, os denominados „events", como por exemplo alertas, geram as respectivas notificações, as denominadas „notifications", e transmitem-nas ao gestor em 2 forma de participações de evento, os denominados „event reports", para possibilitar uma gestão da rede eficaz. A gestão da rede pode abranger, entre outros, a gestão de erros (Fault-Management), e/ou a gestão de configuração (Configuration Management), e/ou a gestão de segurança (Security Management), e/ou a gestão da contabilidade (Accounting Management), e/ou a gestão de desempenho (Performance Management). Através da gestão de rede são preparados mecanismos adequados para a distribuição e gestão de informação, de forma a se encontre à disposição, sempre que necessário, uma imagem sobre o estado da rede e os objectos individuais da rede de telecomunicações possam ser eficientemente supervisionados e configurados. A comunicação gestor-agente resulta através dos denominados interfaces de gestão e interfaces gestor-agente, que se identificam por um protocolo de comunicação num ambiente orientado para o objecto, como por exemplo CMIP (Common Management Information Protocol) para ITU-T X.711 ou CORBA (Common Object Request Broker Architecture), e através de um objecto-modelo. Os objectos-modelo servem para modelar recursos da rede de telecomunicação, em que estes recursos são repartidos na modelação em classes de objectos.
Tais interfaces existem, por exemplo, entre por um lado o nivel de gestão de elementos da rede (Network Element Management Levei) e, por outro lado, o nível do elemento de rede (Network Element Levei). Um exemplo de dispositivos de rede destes interfaces gestor-agente são os centros de operação e manutenção (OMC: Operation and Maintenance Center) do lado do nível de gestão de elementos de rede, bem como do lado dos dispositivos do nível de elemento de 3 rede, como por exemplo estações base do sistema de estações base (BSS; Base Station System) de uma rede móvel GSM, ou estações base de outras redes de comunicação, como por exemplo NodeB's de uma rede de comunicação móvel UMTS (UMTS: Universal Mobile Telecommunication System), ou pontos de acesso rádio de um sistema WLAN (WLAN: Wireless Local Area Network), por exemplo segundo uma das normas IEEE 802.11.
Os interfaces de gestão e interfaces gestor-agente existem também entre, por um lado, o nível da gestão de rede (Network Management Levei) e por outro lado o nível da gestão dos elementos de rede. Um exemplo de dispositivos de rede para estes interfaces gestor-agente são os centros de gestão de rede (NMC: Network Management Center) do lado do nível de gestão de rede e os centros de operação e manutenção (OMC: Operation and Management Center) do lado do nível de gestão de elementos de rede, por exemplo os denominados GSM ou uma outra rede móvel ou de telecomunicações.
Através do registo internacional WO 99/59326 A2 é conhecido um processo para operação de uma rede de gestão de uma rede de telecomunicações, compreendendo: -um agente; -um gestor; -um objecto-modelo, no qual são ordenadas classes de objectos segundo o objecto -uma aplicação do objecto-modelo para comunicação ente o gestor e os agentes; com os seguintes passos: 4 a) Transmissão de um pedido de reconciliação da informação para os agentes, b) Transmissão do pedido de informações exclusivamente sobre os objectos e/ou alertas relativamente aos quais resulta uma alteração de um estado normal, pelos agentes ao gestor. A invenção tem por objectivo melhorar este método, fazendo com que seja transmitida menos informação na reconciliação de informação.
Este objectivo é atingido através de um método com as caracteristicas da reivindicação de patente 1, bem como através das caracteristicas das subsequentes reivindicações. Realizações vantajosas e desenvolvimentos são assuntos tratados nas reivindicações abaixo.
No método de acordo com a invenção, para a operação de uma rede de gestão de uma rede de telecomunicações contendo um gestor e um agente, o gestor e o agente comunicam um com o outro através da utilização de um objecto-modelo. As classes de objectos são ordenadas de acordo com o objecto-modelo. 0 gestor transmite aos agentes um pedido de reconciliação de informação e o agente recebe do gestor um pedido de reconciliação de informação. De acordo com a invenção, o gestor recebe dos agentes informações do pedido exclusivamente sobre objectos e/ou alertas, relativamente aos quais tenha ocorrido uma alteração desde um ponto no tempo, e o agente envia estas informações ao gestor. 0 gestor e o agente comunicam um com o outro através da utilização de um objecto-modelo. Nos objectos cujas classes de objectos são ordenadas de acordo com os objectos-modelo, 5 trata-se de abstracções de componentes físicas ou lógicas, isto é recursos de rede, da rede de telecomunicações gerida, sendo os recursos de rede modelados assim como objectos. São possíveis várias alterações em relação a um objecto, dependendo da realização concreta do objecto e o seu ordenamento numa classe de objectos.
Existe um alerta para cada evento (event) . Se um objecto despoletar um tal „alarm event", este envia um „alarm report" de notificação através do alerta. 0 alerta encontra-se associado com o objecto que envia o „alarm report". Um alerta pode apresentar vários estados, que podem ser alterados. Para além disso pode apresentar um atributo de alerta, a denominada informação de alerta, que pode ser alterado. 0 método de acordo com a invenção possibilita uma sincronização de informações entre um gestor e um agente. Trata-se aqui não de uma sincronização total, mas de uma sincronização parcial, uma vez que nem todos os objectos e/ou alertas são parte da sincronização, mas apenas aqueles que preenchem a condição que resulta de uma alteração em relação a si desde um determinado ponto no tempo. Não são abrangidas as informações exclusivamente sobre objectos e/ou alertas, em relação aos quais haja uma alteração a partir de um determinado ponto no tempo, desde que as informações sobre objectos e/ou alertas, em relação aos quais a partir do ponto no tempo determinado não se produzam alterações. À excepção destas informações sobre objectos e/ou alertas, que não se alteram a partir do ponto no tempo determinado, podem também ser transmitidas outras informações relativamente ao pedido do agente ao gestor, como as informações exclusivamente sobre objectos e/ou 6 alertas, em relação aos quais tenha ocorrido uma alteração a partir de um determinado ponto no tempo.
As informações sobre objectos e/ou alertas, relativamente aos quais se produza uma alteração a partir do ponto no tempo determinado, são preferencialmente contidas numa mensagem, sendo também contudo possível, distribui-las por mais mensagens. Para além do gestor e do agente podem fazer parte da rede de gestão outros dispositivos. É possível, que o método de acordo com a invenção seja executado por um agente em relação a vários gestores, e também por um agente em relação a vários agentes.
Num desenvolvimento da invenção, o ponto no tempo determinado é o ponto no tempo da última reconciliação de informação entre o gestor e o agente pedida pelo gestor. Com isto, o gestor é informado através do método de acordo com a invenção sobre alterações, que tenham ocorrido desde a última sincronização por ele solicitada. Esta última sincronização pode tratar-se de uma sincronização total ou de uma sincronização parcial, de acordo com a invenção em causa. Em alternativa ao ponto no tempo da última sincronização, pode também ser utilizado o ponto no tempo de um outro evento, por exemplo o ponto no tempo no qual a ligação entre o gestor e o agente foi interrompida.
Numa realização da invenção, o pedido do gestor compreende informações sobre os objectos, nos quais devem ser obtidas as informações do agente sobre os objectos e/ou alertas, relativamente aos quais tenha ocorrido uma alteração desde o ponto no tempo determinado. Com isto não são verificadas todas as alterações em todos os objectos e/ou alertas dos agentes, mas apenas aquelas que são indicadas na 7 solicitação do gestor. Em relação ao alerta, o pedido do gestor pode indicar que os alertas alterados devem dizer respeito apenas a determinados objectos. É especialmente vantajoso se as informações sobre objectos, relativamente aos quais ocorra uma alteração desde um determinado ponto no tempo, abrangerem informações sobre uma alteração ocorrida desde um determinado ponto no tempo em relação a pelo menos um atributo de pelo menos um objecto conhecido pelo gestor. 0 objecto ser conhecido do gestor pode significar, por exemplo, que o gestor tenha armazenado informações sobre este objecto, como por exemplo informações de identificação do objecto, a classe de objecto do objecto, os atributos e os valores dos atributos do objecto, e/ou que o gestor já tenha recebido mensagens dos agentes sobre este objecto ou que as tenha enviado aos agentes. Uma alteração de um atributo pode por exemplo ser realizada através da alteração de valores do atributo, através da introdução dos atributos ou da eliminação dos atributos. Preferencialmente o gestor é informado, no quadro da sincronização parcial de acordo com a invenção, sobre todos os atributos modificados desde um determinado ponto no tempo, em todos os objectos conhecidos, eventualmente aqueles especificados no pedido. As informações sobre a alteração de um atributo de um objecto compreendem preferencialmente: informação de identificação do objecto em causa, informação de identificação do atributo e o valor actual do atributo.
Adicionalmente ou em alternativa é vantajoso se as informações sobre os objectos em relação aos quais tenha ocorrido uma alteração desde determinado ponto no tempo, compreenderem informações sobre pelo menos um objecto 8 desconhecido pelo gestor, o qual se torna relevante para o gestor após o determinado ponto no tempo. Que um objecto seja desconhecido para o gestor, pode, por exemplo, significar que o gestor não tenha qualquer informação armazenada sobre este objecto, e/ou que o gestor não tenha recebido ainda qualquer mensagem sobre este objecto dos agentes ou as tenha enviado aos agentes. Um objecto pode então tornar-se relevante para um gestor quando é adicionado ao conjunto dos objectos supervisionados pelo gestor, por exemplo quando um dispositivo foi recentemente instalado deve ser controlado pelo gestor, quando um dispositivo já conhecido pelo gestor como objecto é registado como um outro objecto, ou quando um objecto, que não foi temporariamente controlado pelo gestor, por exemplo por causa de manutenção, é novamente controlado pelo gestor. As informações sobre um objecto anteriormente desconhecido pelo gestor compreendem preferencialmente: informação de identificação do objecto, informação de identificação do atributo do objecto e os valores actuais do atributo.
Adicionalmente ou em alternativa, é vantajoso se as informações sobre objectos, relativamente aos quais ocorreu uma alteração desde um determinado ponto no tempo, compreenderem informações sobre pelo menos um objecto conhecido pelo gestor, que após o ponto de tempo determinado se torna irrelevante para o gestor. Um objecto pode então tornar-se irrelevante para um gestor, quando é removido do conjunto dos objectos supervisionados pelo gestor, por exemplo quando um dispositivo é removido da rede de telecomunicações, quando um dispositivo que antes era supervisionado pelo gestor passa a ser supervisionado por um outro gestor, quando um dispositivo que o gestor já 9 conhecia como objecto é compreendido como outro objecto, ou quando um objecto não é supervisionado temporariamente pelo gestor, por exemplo por causa de manutenção.
No desenvolvimento da invenção, as informações sobre alertas, relativamente aos quais resultam alterações desde um determinado ponto no tempo, compreendem informações sobre pelo menos um alerta recebido e/ou gerado pelos agentes após o ponto no tempo determinado. Isto pode por exemplo dizer respeito a alertas que tenham sido gerados por um dos agentes subordinados ao agente, que apresente um objecto supervisionado pelo gestor, e que eventualmente tivessem sido reencaminhados pelo agente ao gestor. Para além disso este alerta pode dizer respeito aos alertas gerados pelo agente. É vantajoso se as informações sobre objectos, relativamente aos quais ocorra uma alteração desde um determinado ponto no tempo, abrangerem informações sobre uma alteração ocorrida desde um determinado ponto no tempo em relação a pelo menos um atributo, de pelo menos um estado, de pelo menos um alerta. Estados de alerta podem ser por exemplo estados como „active" e „unacknowledge", isto é a causa do alerta ainda existe e o alerta ainda não tinha sido reconhecido, „active" e „unacknowledge", isto é a causa do alarme ainda existe e o alarme já foi reconhecido, „clear" e „unacknowledge", isto é a causa do alerta foi rectificada mas o alerta ainda não foi reconhecido, "clear" e "acknowledge", isto é a causa do alerta foi rectificada e o alerta foi reconhecido. Em último caso o alerta pode ser cancelado na lista de alertas. 10
Na realização da invenção, o pedido é enviado pelo gestor periodicamente e/ou após uma reposição da comunicação entre o gestor e o agente. Se, por exemplo, a comunicação entre o gestor e o agente for interrompida temporariamente, o gestor pode, se assim o determinar, quando a interrupção da comunicação termine, enviar um pedido de reconciliação da informação ao agente. Este pedido pode também impor uma sequência geralmente periódica de pedidos. É também possível que o gestor envie o pedido para um ponto no tempo aleatório.
Um produto de acordo com a invenção apresenta meios para execução do método de acordo com a invenção.
Um outro produto de acordo com a invenção apresenta meios que são organizados de forma a que o método de acordo com a invenção seja executado por meio do produto em relação ao agente e ao gestor.
De seguida a invenção será explicada de forma mais detalhada com recurso aos exemplos de realização. Aqui mostram-se:
Figura 1: um corte numa rede de gestão de um sistema de comunicação móvel,
Figura 2: um esquema do método de acordo com a invenção. O corte representado na figura 1 de uma rede de gestão de um sistema de comunicação móvel é composto por três níveis NM-LEVEL (NM: Network Manager), NEM-LEVEL (NEM:Network Network Element Manager) e NE-Level (NE: Network Element). Os centros de gestão de rede NMC1 E NMC2 são componentes do 11 nível NM-LEVEL mais elevado, os quais se encontram ligados a ambos os centros de operação e manutenção 0MC1 e 0MC2 do nível intermédio NEM-LEVEL. Ambos os centros de operação e manutenção 0MC1 e 0MC2 servem como agentes para os centros de gestão de rede NMC1 e NMC2 opostos. 0 centro de operação e manutenção 0MC1 encontra-se ligado com os três elementos de rede NE11, NE12 e NE13 do nível mais baixo NE-LEVEL, enquanto o centro de operação e manutenção 0MC2 se encontra ligado com os dois elementos de rede NE21 e NE22. Os elementos de rede NE11, NE12, NE13, NE21 e NE22 podem ser por exemplo estações base ou dispositivos para controle das estações base.
Os recursos de rede do sistema de comunicação móvel, como por exemplo os elementos de rede NE11, NE12, NE13, NE21 e NE22 são repartidos no âmbito da gestão de rede em classes de objectos. Foi definido um objecto-modelo por 3GPP para a comunicação por interface entre um centro de gestão de rede e um centro de operação e manutenção, o qual, por exemplo, compreende as classes de objecto ManagedElement e ManagedFunction, as quais envolvem classes de objectos base com atributos gerais. Outras classes de objectos são por exemplo gsmCell, utranCell, btsSiteManager, bssFunction, mscServerFunction, rncFunction, hlrFunction, vlrFunction, sgsnFunction e ggsnFunction.
Cada classe de objectos é definida através de operações especificas, isto é através de comandos, que podem ser enviados a objectos destas classes de objectos por um gestor, bem como através de determinados atributos, isto é características, que podem ser pedidas e eventualmente processadas por um gestor, e sobre mensagens específicas, as quais podem ser enviadas por objectos da respectiva 12 classe de objectos no âmbito da gestão de rede, bem como pela descrição do significado e do comportamento da classe de objectos e as suas componentes. 0 objecto-modelo usado e as classes de objectos definidas entre centros de gestão de rede, por um lado, e centros de operação e manutenção, por outro, são em regra genéricos, para poderem integrar centros de operação e manutenção de diferentes fabricantes. Isto baseia-se em que uma parte das tarefas do gestor, as quais exercem os elementos de rede subordinados nos centros de operação e manuseamento opostos, bem como por exemplo a gestão de configuração, é dependente da configuração concreta do hardware e software dos elementos de rede e, com isto, dependente do fabricante. Uma vez que um centro de gestão de rede é frequentemente associado a uma variedade de centros de operação e manuseamento de diversos fabricantes, dá-se, nos centros de operação e manuseamento, uma conversão de mensagens do objecto-modelo relacionado com o hardware do interface OMC-NE em mensagens do objecto-modelo genérico do interface OMC-NMC.
Cada gestor supervisiona um ou mais recursos de rede, nos quais pode enviar operações, isto é solicitações, e dos quais recebe notificações. Aqui ele apresenta uma base de dados na qual são introduzidos os recursos de rede que considera relevantes, isto é por si supervisionados. Por cada recurso de rede supervisionado pelo gestor é gerada uma instância de objecto, de seguida denominada como objecto. Se for instalada por exemplo uma nova estação base, é gerado um objecto correspondente a esta nova estação base e que se encontra atribuído à classe de objecto normal das estações base. 0 novo objecto é adicionado à base de dados do gestor. De forma similar, os objectos podem também ser apagados. 13 A gestão óptima de uma rede de telecomunicações impõe que apenas sejam encaminhadas as notificações de evento relevantes dos agentes subordinados ao gestor o mais depressa possível. Em condições normais, isto é quando a comunicação entre o agente e o gestor funciona devidamente, esta pode ocorrer através de um mecanismo de filtro existente no agente (por exemplo um interface de gestão baseado em CMIP com ajuda de discriminadores Event Forwarding, os denominados EFDs, de acordo com o ITU-T X.734 „System Management: Event Report Management Function" ou num interface de gestão baseado em CORBA com ajuda de canais de notificação).
Para obter uma imagem actualizada do estado da rede, um gestor pode sincronizar as informações de gestão armazenadas por si com o agente. Para este objectivo são utilizados procedimentos de sincronização para reconciliação de informação (também designados procedimentos de „Alignment") , por exemplo para configuração de dados ou alertas. Os dados de configuração de um objecto representam o conjunto de todos os atributos e os seus valores, isto é a totalidade das características do objecto.
Processos de sincronização do género são necessários em muitos casos, como por exemplo: a) após a quebra e subsequente retoma da comunicação entre agente e gestor. b) Quando agentes específicos, os denominados agentes simples, não geram notificações relacionadas com a configuração (notifyObjectCreation / notifyObjectDeletion / notifyAttributeValueChange, 14 como definido por exemplo na norma TS 32.662 „Configuration Management (CM; Kernel CM Information Service (IS), V6.3.0") ou quando o gestor não analisa estas notificações relacionadas com a configuração, porque uma sincronização „real time" é demasiado dispendiosa. Neste caso deve ser iniciada uma sincronização, pelo menos periódica, pelo gestor, c) Quando por causa de razões do sistema se possam perder notificações relacionadas com configuração ou mesmo alertas, isto é quando é necessária uma sincronização orientada para o evento, apesar da comunicação gestor-agente não ser interrompida.
Tais procedimentos são normalmente normalizados para possibilitar sincronizações entre gestores e agentes de diferentes fabricantes. Por exemplo a norma 3GPP TS 32.602 [Configuration Management (CM); Basic CM Integration
Reference Point (IRP): Information Service (IS), V6.0.0] uma operação getMoAttributes, com a qual um gestor pode pedir dados de configuração geridos pelos agentes. Para a sincronização de alertas, a norma 3GPP TS 32.111-2 [Fault Management; Parte 2: Alarm Integration Reference Point (IRP): Information Service (IS)], define uma operação getAlarmList. Estas operações permitem a um gestor sincronizar toda a informação de gestão, isto é, realizar uma reconciliação de informação completa com os agentes. Se a reconciliação da informação se relacionar com os dados da configuração, o gestor recebe os valores actuais de acordo com o estado da técnica de todos os atributos de todos os objectos, aqueles supervisionados por si, juntamente com uma informação de identificação do objecto existentes (MOI, Managed Object Instance)e uma informação de identificação da classe de objecto existente (MOC, Managed Object Class). 15
Se a reconciliação de informação se relacionar com o alerta o gestor recebe todos os alertas que lhe são relevantes de acordo com o estado da técnica. Esta reconciliação da informação completa é também possivel em relação a uma área de rede. 0 gestor recebe as informações independentemente de já conhecer estas informações de gestão. Uma vez que o gestor não pode saber que dados isolados foram efectivamente alterados no tempo que mediou, terá que ser iniciada uma sincronização global. A consequência da sincronização total descrita é uma excessiva, e na maior parte dos casos, desnecessária duração da sincronização, que para muitos operadores, sobretudo após quebras relativamente curtas da comunicação gestor-agente, são inaceitáveis. Em face da enorme quantidade de dados a sincronizar, isto é, principalmente nos interfaces NM-EM, de especial relevância, uma vez que falhe temporariamente um centro de gestão de rede ou que não avalie notificações relacionadas com configuração, tem que ser sincronizado com todos os centros de operação e manutenção. 0 método de acordo com a invenção é descrito de seguida com a ajuda da Figura 2, a titulo de exemplo, para o interface de gestão NM-EM entre o centro de operação e manutenção 0MC1 e os centros de gestão de rede NMC1 e NMC2 em relação à sincronização de dados de configuração. 0 centro de operação e manutenção 0MC1 gere para ambos os centros de gestão de rede NMC1 e NMC2 uma lista dinâmica, de seguida designada como lista de alterações, as alterações de configuração, na qual são introduzidas informações de identificação em forma de nomes completos (DN= Distinguished Name) de todos os objectos alterados desde a última sincronização: 16 a) Para um objecto que foi alterado, uma vez que é novo, isto é um objecto que até ao momento ou estava contido na base de dados armazenada pelo aqente do objecto supervisionado pelo gestor, e apaqado da base de dados do agente e a apagar da base de dados do gestor, é produzida uma lista de entradas na lista de alterações com a informação de identificação do objecto e a etiqueta „D" (Deleted).
Na primeira ligação da comunicação gestor-agente os respectivos centros de gestão de rede NMC1 e NMC2 enviam uma solicitação para encaminhamento de uma sincronização total ao centro de operação e manutenção 0MC1. 0 centro de gestão de rede NMC1 envia assim na Figura 2, na qual o curso do tempo é indicado para baixo, para o ponto no tempo tO, uma solicitação normalizada de acordo com a 3GPP TS 32.602 getMoAttributes Request ao centro de operação e manutenção OMC1, e o centro de gestão de rede NMC2 envia uma tal operação para o ponto no tempo tl. O centro de operação e manutenção responde por sua vez com uma mensagem normalizada de acordo com a 3GPP TS 32.602 getMoAttributes Response, a qual como explicado acima contém todos os objectos supervisionados pelo respectivo gestor e os valores dos seus atributos. Após a realização desta sincronização, a lista de alteração do centro de operação e manutenção OMC1 para o respectivo gestor é iniciada, para que esteja disponível uma lista de alterações vazia no respectivo centro de gestão de rede NMC1 e NMC2 após o envio da mensagem getMoAttributtes Response.
Por exemplo após uma quebra e retoma da comunicação gestor-agente ou quando um gestor reconhece que os seus dados de 17 configuração não podem ser mais actuais, apenas precisa dos dados de configuração das alterações ocorridas desde o último processo de sincronização para poder actualizar de novo a sua base de dados. De acordo com a invenção, é executado um processo através do qual o gestor descobre as alterações ocorridas desde a última sincronização, sem que sejam transmitidas informações supérfluas pelos agentes, que não se tenham alterado desde a última sincronização. Esta sincronização dá-se por causa da mensagem, a qual se encontra confinada às modificações, de seguida denominada como sincronização Delta. Para iniciar uma sincronização Delta o centro de gestão de rede NMC1 ou NMC2 envia uma mensagem getConfigurationChanges Request com os seguintes parâmetros ao centro de operação e manutenção 0MC1: managerReference: este parâmetro identifica inequivocamente o respectivo centro de gestão de rede NMC1 ou NMC2; baseObjectInstance: este parâmetro opcional identifica um objecto com ponto de inicio na árvore de objectos para a escolha dos objectos alterados. Todos os objectos contidos na árvore de objectos sob esta referência de objecto são examinados; âmbito: este parâmetro opcional especifica, a partir do objecto de referência acima referido, para quais objectos subordinados na árvore de objectos do interface gestor-agente devem ser sincronizados os dados de configuração alterados. Os parâmetros podem assumir os mesmos valores que os da operação normalizada getMoAttributes: BASE OBJECT ONLY, Nth LEVEL SUBORDINATES, BASE Nth LEVEL, BASE ALL. 18
Através dos parâmetros baseObjectInstance e âmbito o gestor pode delimitar os objectos nos quais está interessado no quadro da sincronização Delta. Especialmente, o gestor pode utilizar como baseObjectInstance a instância superior da árvore de objectos e como âmbito o valor BASE ALL, isto é todos os objectos alterados devem ser considerados nesta sincronização Delta. Esta escolha deve ser assumida pelos agentes, quando os parâmetros opcionais baeObjectInstance e âmbito na mensagem de solicitação getConfigurationChanges não forem utilizados. 0 centro de operação e manutenção 0MC1 pesquisa na lista de alterações associada ao respectivo centro de gestão de rede NMC1 ou NMC2 pelos objectos de acordo com os parâmetros baseObjectInstance e âmbito. Após o fim do processo de pesquisa, o centro de operação e manutenção 0MC1 envia uma resposta getConfigurationChanges Response para o respectivo gestor com o seguinte conteúdo: newOb jectList: esta diz respeito a uma lista com os novos objectos criados desde a última sincronização, correspondentes à etiqueta „N" na lista de alterações, em que ficam contidos por cada objecto a classe de objecto actual, o nome do objecto em forma de „distinguished name" e a lista de atributos, isto é, por cada atributo o nome do atributo e o valor do atributo. changedObjectList: esta corresponde a uma lista com os objectos alterados desde a última sincronização, correspondente à etiqueta „M" na lista de alterações. Aqui também são especificados por cada objecto a classe de objecto actual, o nome do objecto e a lista de atributos. 19 deletedObjectList: esta corresponde a uma lista com os objectos apagados desde a última sincronização, correspondente à etiqueta „D" na lista de alterações. Por cada objecto são especificados apenas a classe de objecto e o nome do objecto.
Após o envio da mensagem getConfigurationChanges Response é iniciada a listagem de alterações associada ao correspondente centro de gestão de rede NMC1 e NMC2 do centro de operação e manutenção 0MC1.
Na Figura 2 é contemplado a titulo de exemplo o caso em que o processo descrito de sincronização Delta do centro de gestão de rede NMC1 é iniciado periodicamente, enquanto a solicitação para execução da sincronização Dela através do centro de gestão de rede NMC2 decorre após a reposição da comunicação depois de uma quebra anterior da comunicação gestor-agente. Por exemplo é possível que o centro de gestão de rede NMC1 não avalie nenhumas notificações relacionadas com configurações (como notifyObjectCreation / notifyObjectDeletion / notifyAttributeValueChange) , enquanto o centro de gestão de rede NMC2 promove estas notificações.
Como já acima explicado, ocorre uma sincronização completa nos pontos no tempo tO e tl entre o centro de operação e manutenção 0MC1 e o centro de gestão de rede NMC1 e NMC2.
No ponto de tempo t2 são identificados no passo do processo „MOCi, MOIi change" um ou mais atributos de um objecto através de MOIi (MOI: managed object instance) da classe de objecto MOCi (MOC: managed object class), 20 alterados através de uma reconfiguração automática ou do operador OMC. O centro de operação e manutenção 0MC1 regista a informação de identificação deste objecto juntamente com a etiqueta „M" nas listas de alterações associadas aos centros de gestão de rede NMC1 e NMC2. Para além disso, o centro de operação e manutenção 0MC1 gera uma mensagem para informação sobre a alteração ocorrida, preferencialmente uma notificação normalizada notifyAttributeValueChange, que é apenas analisada pelo centro de gestão de rede NMC2, uma vez que o centro de gestão de rede NMC1 não analisa notificações relacionadas com configurações. 0 centro de gestão de rede NMC2 actualiza a sua própria informação da base de dados relativa à notificação notifyAttributeValueChange. 0 agente não pode contudo reconhecer se um gestor efectivamente analisa ou não esta notificação.
No ponto de tempo t3 é identificado no passo do processo „M0Cj, MOIj create" um novo objecto identificado por MOIj da classe de objectos MOCj, gerado pelo operador OMC. 0 centro de operação e manutenção 0MC1 regista a informação de identificação deste objecto juntamente com a etiqueta „N" nas listas de alterações associadas aos centros de gestão de rede NMC1 e NMC2. Para além disso, o centro de operação e manutenção 0MC1 gera uma mensagem para informação acerca da alteração ocorrida, preferencialmente uma notificação normalizada notifyObjectCreation, que é apenas analisada pelo centro de gestão de rede NMC2, isto é o centro de gestão de rede NMC2 actualiza a correspondente informação da sua base de dados. O agente não pode contudo novamente reconhecer se um gestor efectivamente analisa ou não esta notificação. 21
No ponto de tempo t4 a comunicação entre o centro de gestão de rede NMC2 e o centro de operação e manutenção OMC1 é interrompida no passo do processo INTERRUPT, por exemplo devido a uma falha temporária do centro de gestão de rede NMC2.
No ponto de tempo t5 no passo do processo „MOCk, MOIk delete" um objecto identificado por MOIk da classe de objectos MOCk, é apagado pelo operador OMC. 0 centro de operação e manutenção 0MC1 regista a informação de identificação deste objecto juntamente com a etiqueta „D" nas listas de alterações associadas aos centros de gestão de rede NMC1 e NMC2. Para além disso o centro de operação e manutenção 0MC1 gera uma mensagem para informação acerca da eliminação ocorrida, preferencialmente uma notificação normalizada notifyObjectDeletion, que é eliminada, uma vez que a comunicação entre o centro de gestão de rede NMC2 e o centro de operação e manutenção 0MC1 seja interrompida. 0 ponto no tempo t6 corresponde a um ponto no tempo da reconciliação periódica de informação entre o centro de gestão de rede NMC1 e o centro de operação e manutenção 0MC1 de forma a que o centro de gestão de rede NMC1 envie uma mensagem de solicitação getConfigurationChanges Request ao centro de operação e manutenção 0MC1 para actualização dos seus dados de configuração. Esta mensagem de solicitação getConfigurationChanges Request pede a sincronização de todos os dados de configuração, que tenham sido alterados desde a última sincronização despoletada pelo centro de gestão de rede NMC1 no ponto de tempo tO. 0 22 centro de operação e manutenção 0MC1 encontra nas listas de alterações associadas do centro de gestão de rede NMC1 as instâncias MOI±, MOIj e MOIk, cujas alterações e da mensagem de resposta getConfigurationChanges Response enviadas ao centro de gestão de rede NMC1 pelo centro de operação e manutenção 0MC1 podem ser por exemplo divididas da seguinte forma: - newObjectsList: <MOCj, MOIj AttributeListej > - changedObjectsList: < MOCi, MOIi, AttributeListej - deletedObjectsList: <MOCk, MOIk> 0 agente apaga por fim todos os registos da lista de alterações do centro de gestão de rede NMC1.
No ponto de tempo t7 são alterados no passo do processo „MOCm, MOIm change" um ou mais atributos de um objecto, modificados por MOIm da classe de objectos MOCm. 0 centro de operação e manutenção 0MC1 regista a informação de identificação deste objecto juntamente com a etiqueta „M" nas listas de alterações associadas aos centros de gestão de rede NMC1 e NMC2 e gera uma notificação notifyAttributeValueChange, que é ignorada pelo centro de gestão de rede NMC1, enquanto o centro de gestão de rede NMC2 ainda não é alcançável neste ponto de tempo.
No ponto de tempo t8 são novamente alterados no passo do processo „MOCi, MOIi change" um ou mais atributos do objecto, identificado por MOI± da classe de objectos MOCi. 0 centro de operação e manutenção 0MC1 regista a informação de identificação deste objecto juntamente com a etiqueta „M" na lista de alterações associadas aos centros de gestão de rede NMC1. 0 centro de operação e manutenção 0MC1 23 assegura que a informação de identificação deste objecto se encontra disponivel anteriormente juntamente com a etiqueta „M" na lista de alterações dos centros de gestão de rede NMC2, pelo que não é necessária nenhuma nova entrada. A notificação notfyAttributeValueChange que se segue também é de rede NMC2 e o centro de operação e manutenção 0MC1 é perturbada.
Nas várias alterações relacionadas com o objecto entre duas sincronizações numa lista de alterações procede-se da seguinte forma:
Quando um objecto é inicialmente alterado e de seguida apagado, a informação de identificação deste objecto fica apenas com a etiqueta „D" na lista de alterações.
Quando um objecto é inicialmente gerado e subsequentemente alterado, a informação de identificação deste objecto fica para além disso com a etiqueta „N" na lista de alterações, uma vez que o objecto é novo para o respectivo gestor.
Quando um objecto começa por ser gerado e subsequentemente apagado, este objecto é afastado da respectiva lista de alterações, uma vez que para o gestor este objecto não tem importância na sincronização.
Quando o mesmo objecto começa por ser apagado e subsequentemente é novamente gerado, a informação de identificação deste objecto fica na lista de alterações com a etiqueta „M", uma vez que o gestor já conhece este objecto, mas que é eventualmente alterado através da criação de novos valores de atributo. 24
No ponto de tempo t9 a comunicação entre o centro de gestão de rede NMC2 e o centro de operação e manutenção 0MC1 é retomada. 0 centro de gestão de rede NMC2 envia conseguentemente uma solicitação getConfigurationChanges Request aos agentes para sincronização dos dados de configuração que tenham sido alterados desde a última sincronização no ponto de tempo tl. 0 agente encontra os objectos em causa na lista de alterações associada ao centro de gestão de rede NMC2 e envia uma mensagem getConfigurationChanges Response ao centro de gestão de rede NMC2 com o seguinte conteúdo: newObjectsList: <MOCj, MOIj, AttributListej>
ChangedObjectsList: <MOCi, MOIi, AttributListei>; esta contém apenas a última alteração no ponto de tempo t8, e não a alteração no ponto de tempo t2; <MOCm, MOIm, AttributListem> deletedObjectsList: <MOCk, M01k>. 0 centro de operação e manutenção 0MC1 apaga de seguida todas as entradas da lista de alterações do centro de gestão de rede NMC2. Apesar do centro de gestão de rede NMC2 ter recebido e analisado as notificações do ponto de tempo t2 (notifyAttributeValueChange) e do ponto de tempo t3 (notifyObjectCreation), estas alterações encontram-se também contidas na mensagem getConfigurationChanges Response. Isto é vantajoso, uma vez que estas notificações definidas como opcionais nas normas 3GPP (notifyAttributeValueChange e notifyObjectCreation) não são 25 suportados por muitos agentes ou gestores. Assim o processo aqui descrito é independente da implementação de agentes ou gestor. Para além disso, o agente desconhece se uma notificação relacionada com a configuração gerada por ele é efectivamente analisada.
No ponto de tempo tlO o centro de gestão de rede NMC1 inicia novamente a sua actualização de dados periódica com recurso a uma sincronização Delta para os dados de configuração alterados desde o ponto de tempo t6 através do envio de uma mensagem getConfigurationChanges Request. A resposta getConfigurationChanges Response do centro de operação e manutenção 0MC1 contém as seguintes informações: changedObjectsList: <MOCi, MOIi, AttributListei> <MOCm, MOIm, AttributListem>.
As outras partes da resposta do agente, isto é newObjectsList e deletedObjectsList, são omitidas ou encontram-se em vazio. 0 centro de operação e manutenção 0MC1 apaga de seguida todas as entradas da lista de alterações do centro de gestão de rede NMC1.
0 processo pode também ser utilizado para a sincronização Delta de uma árvore de objectos completa (MIT= Management Information Tree, isto é o conjunto de todos os objectos) ou apenas para parte de uma árvore de objectos. Na norma 3GPP TS 32.602 [Configuration Management (CM); Basic CM
Integration Reference Point (IRP): Information Service (IS), V6.0.0] existe a operação getContainment_, que efectua uma sincronização total da árvore de objectos. De acordo com a invenção, é utilizada uma operação 26 getContainmentChanges para a sincronização Delta da árvore de objectos, abrangendo uma mensagem getContainmentChanges Request do gestor e uma resposta getContainmentChanges Response do agente. Através do processo para sincronização Delta da árvore de objectos o gestor recebe uma lista dos objectos novos/alterados/apagados sem os seus atributos, isto é a mensagem de resposta getContaimentChanges Response do agente compreende apenas a informação de identificação dos objectos presentes e a sua classe de objectos. 0 processo descrito é independente do sistema de telecomunicações, e pode, por exemplo, ser utilizado em um sistema de comunicações móvel, em rede fixa ou em outros sistemas. Para além disso, o processo é independente do protocolo de comunicação entre gestor e agente, como por exemplo CMIP, CORBA, ou outros protocolos utilizáveis, e quanto ao tipo de interface de gestão pode por exemplo ser utilizado um EM-NE, NM-EM ou outros interfaces. 0 processo pode ser utilizado para uma sincronização rápida dos dados de configuração, uma vez que através da delimitação da transmissão de alterações desde a última sincronização para a transmissão de informação conhecida pelo gestor e com isto é eliminada a informação redundante. Em relação à quantidade normal de alterações de configuração em reconciliação com o conjunto total de dados de configuração, os quais com os procedimentos normalizados anteriores apenas podiam ser sincronizados como um todo, o processo descrito oferece uma redução significativa da duração da sincronização, o que significa em redes de grande dimensão por exemplo, pelo menos um factor 10 mais curto. 0 processo é especialmente vantajoso quando um agente e/ou o gestor não suportam quaisquer notificações 27 relacionadas com configurações. Em tal caso, a sincronização Delta pode ser iniciada periodicamente e não apenas após a retoma da comunicação gestor-agente, para assegurar que um gestor possa actualizar a sua informação sobre o estado actual de forma rápida e eficiente. 0 processo descrito até ao momento para sincronização Delta de dados de configuração pode também ser utilizado para a sincronização de alertas. Neste caso, a mensagem de resposta getAlarmChanges do agente a uma mensagem de solicitação getAlarmChanges Request do gestor para sincronização Delta de alertas compreende a seguinte informação: newObjectList: todos os novos alertas relevantes para o gestor, isto é alertas que recebeu pelos agentes e gerados por ele, desde a última sincronização; changedObjectList: todos os alertas relevantes para o gestor cujo estado se tenham alterado desde a última sincronização, por exemplo um alerta activo no estado „cleared" mas não confirmado pelo operador, ou confirmado mas ainda não „cleared"; deletedObjectList: todos os alertas relevantes para o gestor que tenham sido apagados desde a última sincronização, por exemplo porque entretanto foi alcançado o estado „cleared e conf irmado".
Também pode ser executada uma sincronização Delta de dados de configuração e Alertas.
Lisboa, 26 de Março de 2010

Claims (12)

1 REIVINDICAÇÕES 1. Processo para operação de uma rede de gestão de uma rede de telecomunicações, compreendendo, - um gestor (NMC1, NMC2); - um agente (0MC1); - um objecto modelo, segundo o qual são ordenados os objectos (MOIi, MOIj, MOIk, MOIm) nas classes de objectos (MOCi, MOCj, MOCk, MOCm) ; - uma utilização do objecto modelo para comunicação entre gestor e agentes; com os seguintes passos: a) Envio de pedidos do gestor aos agentes para uma reconciliação da informação; b) Envio de resposta ao pedido pelos agentes ao gestor de informação exclusivamente sobre os objectos e/ou alertas relativamente aos quais tenha ocorrido uma alteração a partir de um determinado ponto no tempo (tO, tl, t6).
2. Processo de acordo com a reivindicação acima mencionada, caracterizado por, o ponto no tempo determinado se tratar do ponto no tempo da última reconciliação de informação entre o gestor e o agente, pedida pelo gestor.
3. Processo de acordo com uma das reivindicações precedentes, caracterizado por, 2 a solicitação do gestor conter informações sobre objectos, às quais devem dizer respeito as informações do agente sobre objectos e/ou alertas, relativamente aos quais tenha ocorrido uma alteração desde um determinado ponto no tempo.
4. Processo de acordo com uma das reivindicações precedentes, caracterizado por, as informações sobre objectos, relativamente aos quais tenha ocorrido uma alteração desde um determinado ponto no tempo, compreenderem: informações sobre uma alteração ocorrida a partir de um determinado ponto no tempo relativamente a pelo menos um atributo de pelo menos um objecto conhecido do gestor. (MOI±, MOIm) .
5. Processo de acordo com pelo menos uma das reivindicações precedentes, caracterizado por, as informações sobre objectos, relativamente aos quais tenha ocorrido uma alteração desde um determinado ponto no tempo, compreenderem: informações sobre pelo menos um objecto (MOIj) desconhecido pelo gestor, que se tenha tornado relevante para o gestor a partir de determinado ponto no tempo.
6. Processo de acordo com pelo menos uma das reivindicações precedentes, caracterizado por, as informações sobre objectos, relativamente aos quais tenha ocorrido uma alteração desde um determinado ponto no tempo, compreenderem: informações sobre pelo menos um objecto (MOIk) desconhecido pelo gestor, que se 3 tenha tornado irrelevante para o gestor a partir de determinado ponto no tempo.
7. Processo de acordo com pelo menos uma das reivindicações precedentes, caracterizado por, as informações sobre alertas, relativamente aos quais tenha ocorrido uma alteração desde um determinado ponto no tempo, compreenderem: informações sobre pelo menos um alerta recebido e/ou gerado pelos agentes após um determinado ponto no tempo.
8. Processo de acordo com pelo menos uma das reivindicações precedentes, caracterizado por, as informações sobre alertas, relativamente aos quais tenha ocorrido uma alteração desde um determinado ponto no tempo, compreenderem: informações sobre uma alteração ocorrida após um determinado ponto no tempo relativamente a pelo menos um estado de pelo menos um alerta.
9. Processo de acordo com pelo menos uma das reivindicações precedentes, caracterizado por, as solicitações serem enviadas periodicamente por meio do gestor de forma periódica e/ou após a retoma da comunicação entre gestor e agente.
10. Produto compreendendo meios para realização de um processo de acordo com uma das reivindicações do processo. 4
11. Produto de acordo com a reivindicação anterior, concebido como produto de programa de computador, cujos meios são concebidos como código de programa e são assim equipados, em que o processo é realizado quando o código do programa é carregado numa memória interna e é executado pelo menos por um processador.
12. Produto compreendendo meios equipados de forma a que através do produto seja realizado um processo de acordo com uma das reivindicações do processo relativamente aos agentes ou ao gestor. Lisboa, 26 de Março de 2010
PT05794773T 2004-11-08 2005-10-06 Método e dispositivos para reconciliação de informação entre gestor e agente numa rede de gestão PT1810523E (pt)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP04026479A EP1655974A1 (de) 2004-11-08 2004-11-08 Verfahren und Vorrichtungen zum Informationsabgleich zwischen Manager und Agent in eiem Managementnetz

Publications (1)

Publication Number Publication Date
PT1810523E true PT1810523E (pt) 2010-04-05

Family

ID=34927285

Family Applications (1)

Application Number Title Priority Date Filing Date
PT05794773T PT1810523E (pt) 2004-11-08 2005-10-06 Método e dispositivos para reconciliação de informação entre gestor e agente numa rede de gestão

Country Status (13)

Country Link
US (1) US9374269B2 (pt)
EP (2) EP1655974A1 (pt)
JP (3) JP4922178B2 (pt)
KR (1) KR100922040B1 (pt)
CN (1) CN101099398B (pt)
AT (1) ATE461588T1 (pt)
DE (1) DE502005009251D1 (pt)
DK (1) DK1810523T3 (pt)
ES (1) ES2341353T3 (pt)
PL (1) PL1810523T3 (pt)
PT (1) PT1810523E (pt)
SI (1) SI1810523T1 (pt)
WO (1) WO2006048362A1 (pt)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007139460A1 (en) 2006-05-30 2007-12-06 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for remote monitoring of femto radio base stations
DE102006038143A1 (de) * 2006-08-16 2008-02-21 Nokia Siemens Networks Gmbh & Co.Kg Referenzierung von Subattributen für das Netzwerkmanagement
EP2392099B1 (en) * 2009-02-02 2017-10-04 Nokia Solutions and Networks Oy Communicating a network event
CN102461067B (zh) * 2009-06-24 2015-02-25 瑞典爱立信有限公司 供通信网络的网络管理中使用的方法和系统
US20130039196A1 (en) 2010-01-12 2013-02-14 Nokia Siemens Networks Oy Operation and maintenance of a telecommunications network
CN104753692B (zh) * 2013-12-25 2018-04-27 中国电信股份有限公司 对传输网络进行智能故障定位和派单的方法和系统
KR20170073691A (ko) * 2014-11-06 2017-06-28 후아웨이 테크놀러지 컴퍼니 리미티드 정보 전송 방법, 피관리 시스템, 및 관리 시스템
WO2018228698A1 (en) * 2017-06-15 2018-12-20 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for managing wireless communications network
CN110633274B (zh) * 2018-06-22 2022-07-15 北京神州泰岳软件股份有限公司 一种告警管理方法和装置
CN112311567B (zh) * 2019-07-26 2022-04-05 华为技术有限公司 一种通信方法及装置

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6076840A (ja) * 1983-10-04 1985-05-01 Fuji Facom Corp 状態変化情報伝送方式
JPS60247347A (ja) * 1984-05-23 1985-12-07 Hitachi Ltd 計測情報伝送方式
JPH04199933A (ja) 1990-11-29 1992-07-21 Hitachi Ltd ネットワーク管理システムおよびその運用方法
JPH0514365A (ja) * 1991-06-28 1993-01-22 Nippon Steel Corp スキヤン伝送方式
JP3115110B2 (ja) * 1992-07-10 2000-12-04 マツダ株式会社 多重伝送装置のノード通信装置
JP2967897B2 (ja) 1993-07-22 1999-10-25 エヌ・ティ・ティ移動通信網株式会社 自動再送要求データ伝送方法
JP3401355B2 (ja) * 1995-02-20 2003-04-28 マツダ株式会社 多重伝送装置
JPH08265317A (ja) * 1995-03-20 1996-10-11 Pfu Ltd ネットワーク管理システム
JPH08340333A (ja) * 1995-06-12 1996-12-24 Nec Corp ネットワーク監視システムにおける中間監視方法とその装置
JP3474057B2 (ja) 1996-02-13 2003-12-08 株式会社日立製作所 ネットワーク運用管理システム
US5987018A (en) * 1996-05-02 1999-11-16 Motorola, Inc Radio unit, method of communicating between radio units over a communications channel and method of preparing a sequence of data cells for transmission over a radio channel
US6044381A (en) * 1997-09-11 2000-03-28 Puma Technology, Inc. Using distributed history files in synchronizing databases
US6212529B1 (en) * 1996-11-13 2001-04-03 Puma Technology, Inc. Synchronization of databases using filters
ES2351892T3 (es) * 1998-05-11 2011-02-11 Siemens Aktiengesellschaft Procedimiento y sistema de comunicación para el tratamiento de informaciones de estado mediante una red de gestión que presenta varios niveles de gestión.
US6363421B2 (en) * 1998-05-31 2002-03-26 Lucent Technologies, Inc. Method for computer internet remote management of a telecommunication network element
WO2000001191A1 (fr) * 1998-06-30 2000-01-06 Matsushita Electric Industrial Co., Ltd. Systeme de commande de reseau et procede correspondant
DE19831825C2 (de) * 1998-07-15 2000-06-08 Siemens Ag Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen aufweisendes Managementnetz
US6496481B1 (en) * 1998-07-16 2002-12-17 Industrial Technology Research Institute Data transfer method for wire real-time communications
CA2285168A1 (en) 1998-10-09 2000-04-09 Chris Frank Howard Channel allocation method and apparatus
EP1152625A1 (de) * 2000-05-04 2001-11-07 Siemens Aktiengesellschaft Aktualisierung von hersteller-spezifischen Hardware-Informationen an der hersteller-unabhängigen OMC-NMC-Schnittstelle im Mobilfunk
KR20020061387A (ko) * 2001-01-16 2002-07-24 박혁구 유치원 어린이용 책상
US7054316B2 (en) * 2001-04-25 2006-05-30 Nokia Corporation Method and system for interlayer control between re-sequencing and retransmission entities
ATE445270T1 (de) 2002-07-18 2009-10-15 Ericsson Telefon Ab L M Verwaltungssystem umd methode zur erbringung von abonnementdienstleistungen

Also Published As

Publication number Publication date
ES2341353T3 (es) 2010-06-18
ATE461588T1 (de) 2010-04-15
DK1810523T3 (da) 2010-06-28
EP1810523B1 (de) 2010-03-17
SI1810523T1 (sl) 2010-06-30
WO2006048362A1 (de) 2006-05-11
JP2011024253A (ja) 2011-02-03
JP5074567B2 (ja) 2012-11-14
PL1810523T3 (pl) 2010-08-31
US20070276936A1 (en) 2007-11-29
KR20070068462A (ko) 2007-06-29
KR100922040B1 (ko) 2009-10-19
JP4922178B2 (ja) 2012-04-25
JP5074568B2 (ja) 2012-11-14
JP2008519517A (ja) 2008-06-05
EP1810523A1 (de) 2007-07-25
US9374269B2 (en) 2016-06-21
DE502005009251D1 (de) 2010-04-29
JP2011024252A (ja) 2011-02-03
CN101099398B (zh) 2010-12-29
EP1655974A1 (de) 2006-05-10
CN101099398A (zh) 2008-01-02

Similar Documents

Publication Publication Date Title
PT1810523E (pt) Método e dispositivos para reconciliação de informação entre gestor e agente numa rede de gestão
KR100999307B1 (ko) 통신 단말기 장치 관리 방법, 통신 단말기 및 통신 시스템
KR100978726B1 (ko) 장치 관리에서 소정 동작을 구현하기 위한 장치 및 방법
EP0529787B1 (en) Network management agent with user created objects
JP4350410B2 (ja) ネットワーク・デバイスの構成を管理する方法、システム、そのためのプログラムおよび記録媒体
US7991878B2 (en) Method, system and terminal for maintaining capability management object and for managing capability
WO2008046429A1 (en) Method for logical deployment, undeployment and monitoring of a target ip network
WO2009100632A1 (zh) 设备管理的方法和终端、装置、系统
US20030162537A1 (en) Update of producer-specific hardware information on the producer-independent omc-nmc interface in a mobile radio network
JP2005237018A (ja) ネットワークマネージメントシステムへのデータ送信
US7062646B2 (en) Generic interface and framework to publish and monitor platform configuration
Cisco Simple Network Management Protocol
KR100621596B1 (ko) 네트워크 시스템의 모니터링 방법
JP2000357145A (ja) ネットワークデバイス管理装置および方法
JP2011526119A (ja) 通信ネットワークシステムにおける方法及び装置
KR100316841B1 (ko) 관리 대행자의 재실행방법 및 장치
CN118337643A (zh) 一种基于配置的数联网核心元素运维系统
WO2019206234A1 (zh) Nfv策略协商方法及系统
JP2002157176A (ja) ネットワーク管理装置およびネットワーク管理方法および記憶媒体
JPH09247149A (ja) ネットワーク管理システム
JP2004533669A (ja) 分散型システムの管理のための方法および装置