A Base de Informações de Gerenciamento (MIB) é um modelo que define precisamente as informações que estão acessíveis utilizando um protocolo de gerenciamento. Usando uma estrutura hierárquica, conforme visto em resumo na figura 5.12 e com mais detalhes no a- pêndice F, a MIB modela através de variáveis cada um dos dispositivos gerenciáveis da rede.
A MIB é definida segundo um conjunto de regras chamado SMI (do inglês, Structure of
Management Information), definida em [52] e [53]. O SMI define como as informações de
gerência são agrupadas e nomeadas, as operações e tipos de dados permitidos e a sintaxe para a definição das MIBs.
No SNMP um nó gerenciável é representado por meio da linguagem ASN.1 (do inglês,
definir as informações trocadas pelo protocolo de gerência; definir as estruturas de dados que representam os nós gerenciados;
Em essência, um modelo de informação é composto pelos seguintes elementos [55]: Modelo para a estruturação da informação;
Modelo para representação de nomes; Modelo para representação dos dados;
Modelo para representação de relacionamentos.
iso(1) org(3) dod(6) internet(1) directory(1) mgmt(2) mib-2(1) system(1) experimental(3) private(4) enterprises(1) ERB-FUZZY-NEURAL-MIB(1) interfacers(2) at(3) ip(4) icmp(5) tcp(6) udp(7) egp(8) transmission(9) snmp(10)
As MIBs apresentam três desses modelos de representação e o gerente se encarrega de im- plementar o modelo de estruturação da informação. Neste contexto, o Modelo de Estrutu- ração da Informação busca proporcionar uma organização na forma de como a informação está disposta. Já os nomes dos objetos identificam a origem e o destino das operações de gerência e das notificações. Com isto é importante que o nome identifique de modo distin- to cada um dos recursos que fazem parte do sistema.
A gerência OSI e Internet utilizam a ASN.1 como forma de definição dos tipos de dados associados com os atributos e parâmetros. A gerência OSI além da ASN.1, ainda utiliza uma sintaxe para a organização das classes dos objetos, descritas em Guidelines for Defini- tion of Managed Objects – GDMO [56]. GDMO é a linguagem de templates utilizada para definir as características de objetos gerenciados.
A grande vantagem no uso de ASN.1 é a não dependência de plataforma. Em ASN.1 as informações são distribuídas segundo um modelo baseado em árvore, onde cada objeto contém as seguintes informações:
Um OID (identificador de objetos); Um texto curto que define este objeto.
Identificadores de Objetos (OIDs) são uma seqüência de inteiros, não negativos, separados por um ponto, representando a posição do objeto na hierarquia da árvore [51]. OIDs são escritos em uma das formas seguintes:
Sintaxe:
¨{¨ { { <nome> [ ¨(¨ <número> ¨)¨ ] } | [ <nome> ¨(¨ <número> ¨)¨ ] ... ¨}¨ ou
<número> [¨.¨ <número> ] ... Exemplo:
{iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) ERB-FUZZY-NEURAL- MIB(1)}
Um objeto dessa MIB é uma abstração de uma característica da rede telefônica ou das fer- ramentas de inteligência, com sintaxe e semântica própria. A sintaxe define uma instância do objeto enquanto que a semântica define o comportamento do objeto naquele momento. Os objetos são estáticos, compilados a partir de uma linguagem de descrição para um for- mato binário que agentes e aplicações de gerência podem compreender. Um objeto instan- ciado é também conhecido como variável. O valor de uma dessas variáveis é a menor uni- dade que apresenta alguma informação gerenciável.
A construção de objetos, de forma similar, foi anteriormente proposto por [57, 58, 59] e [60]. A diferença está no fato que [57, 58, 59] faz essa abordagem sobre o gerenciamento remoto (MIB RMON) de redes TCP IP; enquanto [60] enfatiza o gerenciamento sobre re- des ATM.
As ERBs a serem gerenciadas e as ferramentas de inteligência utilizadas são modeladas como um objeto e armazenadas na MIB. A idéia é ter para cada ERB gerenciável, uma MIB que será uma abstração desta, juntamente com as ferramentas de monitoramento da mesma. Por exemplo, as informações do tráfego de uma ERB espelham seus valores na MIB e, por ser este um padrão de mercado, essas informações podem ser manipuladas por uma infinidade de plataformas de gerência.
O apêndice F apresenta toda a diagramatização, em árvore, da estruturação dessa MIB; a- lém do script de descrição da MIB de acordo com a SMIv2.
5.8 - CONSIDERAÇÕES
Nos últimos anos, tem sido impressionante o desenvolvimento dos sistemas de comunica- ção móveis. Vários serviços têm sido ofertados e em tempos de transmissão menores. A- lém da voz, os sistemas atuais permitem a troca de mensagens curtas e acesso à Internet. Exemplo disso são os sistemas GSM e IS-95 [61], comentados no capítulo 2.
Enquanto isso, as futuras gerações oferecerão serviços de faixa larga, como a multimídia. Nele, será possível a integração de serviços de voz, dados, vídeo, multimídia e acesso à Internet [62, 63, 64], cuja integração voz e dados caracteriza o foco desse trabalho.
Grandes esforços para melhorar o desempenho das redes sem fio têm sido despendidos por causa da demanda crescente de largura de banda e o aumento no número de usuários. Nes- se contexto, os serviços de voz e de Internet possuem requisitos diferenciados. Enquanto o serviço de voz tem igual largura de banda para downlink e uplink; a Internet apresenta trá- fego assimétrico, ou seja, larguras de banda diferentes para os tráfegos de uplink e down-
link.
Uma das características do tráfego nos sistemas móveis é o fato dele ser full duplex, ou se- ja, comunicação nos dois sentidos. São duas as técnicas de duplexação empregadas nos sistemas telefônicos: FDD e TDD. [65, 66, 67, 68].
Preocupados com essa diferenciação entre os serviços, surge a seguinte pergunta: Como desenvolver um CAC (Controle de Admissão de Chamadas) para sistemas de comunicação móveis multi-serviços com suporte a tráfego simétrico e assimétrico? Os trabalhos a seguir tentam responder essa questão. [69, 65, 66, 70, 71, 63, 72, 73, 74, 75, 76].
Sistemas Móveis como: AMPS, GSM, IS-95, etc.; são usados para carregar serviços simé- tricos, como telefonia, uma vez que a largura de banda do uplink e downlink não podem ser modificadas facilmente. FTP e navegação WEB são exemplos de tráfego assimétrico. Tráfego assimétrico, suportado em sistemas que são unicamente FDD, resultam em des- perdício de muita largura de banda se o tráfego uplink ou downlink forem expressivos [77]. Para esses casos, o TDD é melhor para tráfego assimétrico, uma vez que a largura de banda ou os slots de tempo atribuídos para uplink e downlink podem ser modificados mais facil- mente.
A alocação desses canais TDDs seguem o uso de diferentes técnicas que podem ser combi- nadas entre si. A combinação dessas técnicas é o foco do capítulo 6.