Revista Brasileira de Computadores

EVISTA BRASILEIRA
DE REDES DE COMPUTADORES
E SISTEMAS DISTRIBUDOS
Lisandro Zambenedetti Granville
Luci Pirmez
R
Nmero 01
Volume 02
Junho / 2009
ISSN 1983-4217

Nmero 1
Volume 2
J unho de 2009
ISSN 1983-4217

Laboratrio Nacional de
Redes de Computadores

Permitida somente a reproduo parcial dos artigos
publicados desde que a fonte seja citada

Revista Brasileira de Redes de Computadores e Sistemas Distribudos /
Laboratrio Nacional de Redes de Computadores (LARC), Comisso
Especial de Redes de Computadores da Sociedade Brasileira de Computao.
Rio de J aneiro: LARC; SBC, 2009.
v. 2, n. 1 (jan-jun, 2009)
v. : il. cm.
Semestral.
Texto em portugus ou ingls.
ISSN 1983-4217

1. Redes de computadores 2. Sistemas distribudos. I. Laboratrio Nacional de
Redes de Computadores (LARC) II. Sociedade Brasileira de Computao.
Comisso Especial de Redes de Computadores. III. Ttulo.

CDD 004.65

LARC - Laboratrio Nacional de Redes de Computadores

Diretor do Conselho Tcnico-Cientfico
Artur Ziviani
Laboratrio Nacional de Computao Cientfica
(LNCC)

Diretor Executivo
Clio Vincius Neves de Albuquerque
Universidade Federal Fluminense (UFF)
Vice-Diretora do Conselho Tcnico-Cientfico
Flvia Coimbra Delicato
Universidade Federal do Rio Grande do Norte
(UFRN)

Vice-Diretor Executivo
Luciano Paschoal Gaspary
Universidade Federal do Rio Grande do Sul (UFRGS)

SBC - Sociedade Brasileira de Computao
Presidente
Jos Carlos Maldonado
Universidade de So Paulo (USP)

Vice Presidente
Marcelo Walter
Universidade Federal de Pernambuco (UFPE)

Comisso Especial de Redes de
Computadores e Sistemas Distribudos
Carlos Ferraz - Coordenador
Francisco Vilar Brasileiro
Universidade Federal de Campina Grande (UFCG)
Nelson Luis S. da Fonseca, Unicamp
Universidade Estadual de Campinas (UNICAMP)

Editores Capa

Luci Pirmez
Universidade Federal do Rio de Janeiro (UFRJ)

Adriano Barros da Silva

Corpo Editorial

Antnio Jorge Gomes Abelm
Universidade Federal do Par (UFPA)
Artur Ziviani
Laboratrio Nacional de Computao
Cientfica(LNCC)
Clio Vinicius Neves de Albuquerque
Universidade Federal Fluminense (UFF)
Djamel H. Sadok
Edmundo Roberto Mauro Madeira
Universidade de Campinas (UNICAMP)
Elias Procpio Duarte Jr.
Universidade Federal do Paran (UFPR)
Fbio Kon
Joni Fraga
Universidade Federal de Santa Catarina (UFSC)
Jos Marcos Nogueira
Universidade Federal de Minas Gerais (UFMG)

Flvia Coimbra Delicato
Universidade Federal do Rio Grande do Norte (UFRN)
Luci Pirmez
Luciano Paschoal Gaspary
Luiz Fernando Gomes G. Soares
Pontifcia Universidade Catlica (PUC)
Luiz Fernando Rust da Costa Carmo
Neuman Souza
Universidade Federal do Cear (UFC)
Rossana Andrade
Universidade Federal do Cear (UFC)
Thais Vasconcelos Batista
Universidade Federal do Rio Grande do Norte (UFRN)
Laboratrio Nacional de Redes de Computadores (LARC)
Contato: Artur Ziviani
Laboratrio Nacional de Computao Cientfica (LNCC)
Av. Getlio Vargas, 333 - Quitandinha
25651-075 - Petrpolis, RJ
Sociedade Brasileira de Computao
Contato: Antnio J orge Gomes Abelm
Av. Bento Gonalves, 9500 - Porto Alegre, RS
Caixa Postal 15012 - CEP 91501-970
Contedo

Carta dos Editores ................................................................................................. 7
Luci Pirmez, Lisandro Zambenedetti Granville

Artigos

Detectando Falhas Bizantinas em Sistemas Distribudos Dinmicos .............. 9
Murilo Santos de Lima e Fabola Gonalves Pereira Greve

Um Protocolo Geogrfico para Restringir as Mensagens de Descoberta e
Resposta de Servios em Redes Mveis Cooperativas ................................... 23
Janine Kniess, Orlando Loques e Clio V. N. Albuquerque

FloorB: Mecanismo de Controle de Inundao para Redes Ad Hoc Mveis .. 35
Carlos Henrique Pereira Augusto e Jos Ferreira de Rezende

Carta dos Editores

A Revista Brasileira de Redes de
um peridico promovido conjuntamente
pelo Laboratrio Nacional de Redes de
Computadores (LARC) e Sociedade
Brasileira da Computao (SBC) atravs
de sua Comisso Especial em Redes de
(CE-RESD). Como resultado das aes da
comunidade nacional de pesquisa em redes
de computadores e sistemas distribudos, a
Revista ter por objetivo se estabelecer
como um veculo de divulgao dos
avanos cientficos e tecnolgicos da rea,
e assim estender o atual alcance do
prestigioso e tradicional Simpsio
Brasileiro de Redes de Computadores e
Sistemas Distribudos (SBRC).

Neste segundo nmero, a Revista
apresenta verses atualizadas e estendidas
de trs artigos dentre os nove artigos
ganhadores do prmio de melhor trabalho
da 27 edio do SBRC, realizado em 2009
em Recife. O primeiro artigo versa sobre
problemas de segurana em Sistemas
Distribudos Dinmicos. Segundo artigo,
versa sobre mecanismo para a seleo de
servios baseado em localizao e o
terceiro, e ltimo artigo, versa sobre o
controle da inundao em redes ad-hoc.

No primeiro artigo, "Detectando
Falhas Bizantinas em Sistemas
Distribudos Dinmicos" de Murilo Santos
de Lima e Fabola Gonalves Pereira
Greve, os autores apresentam um detector
de falhas bizantinas para sistema
distribudo dinmico. Detector de falhas
bizantinas (ou arbitrrias) uma soluo
elegante para problemas de segurana, uma
vez que separam o tratamento das falhas do
protocolo distribudo que os utiliza. No
entanto, desconhecem-se trabalhos na
literatura descrevendo solues especificas
para sistemas dinmicos. Adicionalmente,
o protocolo apresentado assncrono, isto
, no se baseia no uso de temporizadores
para a deteco das falhas, o que favorece
sua escalabilidade e adaptabilidade.

No segundo artigo, "Um Protocolo
Geogrfico para Restringir as Mensagens
de Descoberta e Resposta de Servios em
Redes Mveis Cooperativas" de autoria de
J anine Kniess, Orlando Loques e Clio V.
N. Albuquerque, apresentada uma
proposta de um mecanismo de seleo de
servios baseado em localizao para
reduzir a disseminao de mensagens de
resposta nos protocolos de descoberta de
servio. O mecanismo seleciona durante o
encaminhamento as respostas dos melhores
provedores considerando: a distncia
geogrfica entre o requisitante e os
provedores do servio, a velocidade dos
ns e o nmero de provedores do servio
solicitado. Outra contribuio deste artigo
a proposta de um mecanismo de
descoberta de servios que ajusta uma rea
de busca para cada pedido com base na
localizao onde o servio necessrio, no
tempo para atendimento do pedido e na
velocidade mxima dos ns. Os resultados
mostraram que estes mecanismos
possibilitam melhorar o desempenho da
rede atravs da reduo das mensagens de
requisio e resposta de servios.

Por fim, no artigo "FloorB:
Mecanismo de Controle de Inundao para
Redes Ad Hoc Mveis" de autoria de
Carlos Henrique Pereira Augusto e J os
Ferreira de Rezende apresentado o
mecanismo FloorB que controla a
inundao atravs do conhecimento
resumido, por ltros de Bloom, da
vizinhana de at dois saltos. Inundao
um mecanismo fundamental no
funcionamento de redes ad hoc, entretanto
tal mecanismo pode causar efeitos nocivos
no desempenho dessas redes, gerando um
nmero excessivo de mensagens
redundantes e, conseqentemente,
consumindo grandes quantidades de
energia. Em funo disto, existem diversas
propostas para minimizar esses efeitos, que
por outro lado tm baixa ecincia pelas
prprias caractersticas das redes ad-hoc,
como falta de infra-estrutura e mobilidade
dos ns. A ecincia do mecanismo
FloorB, comparativamente a outras
propostas determinsticas ou
probabilsticas, avaliada atravs de
simulao.

Luci Pirmez
Editor
Universidade Federal do Rio de Janeiro
Ncleo de Computao Eletrnica
Caixa Postal 2324 Rio de Janeiro, RJ
Editor
Universidade Federal do Rio Grande do Sul
Instituto de Informtica
Caixa Postal 15064 Porto Alegre, RS

Detectando Falhas Bizantinas em
Sistemas Distribudos Dinmicos
Murilo Santos de Lima

Departamento de Cincia da Computao
Instituto de Matemtica e Estatstica
Rua do Mato, 1010, Cidade Universitria
05508-090 So Paulo SP Brazil
mslima@ime.usp.br
Fabola Gonalves Pereira Greve
Departamento de Cincia da Computao
Instituto de Matemtica
Universidade Federal da Bahia (UFBA)
Av. Adhemar de Barros, S/N, Campus de Ondina
40170-110 Salvador BA Brazil
fabiola@dcc.ufba.br
Abstract
Byzantine failure detectors provide an elegant ab-
straction for solving security problems. However, as far
as we know, there is no complete solution for this problem
in a dynamic distributed system. This paper presents thus
a rst Byzantine failure detector for this context. The pro-
tocol has the interesting feature to be asynchronous, that
is, the failure detection process does not rely on timers to
make suspicions. This characteristic favors its scalability
and adaptability.
Keywords: failure detectors, Byzantine failures, dy-
namic distributed systems, self-organizing systems, asyn-
chronous failure detectors
Resumo
Em um sistema distribudo dinmico, no qual os ns
podem entrar e sair da rede aleatoriamente, o desao
de implementar servios conveis grande. Nesse con-
texto, um fator preocupante, em especial, a segurana.
Detectores de falhas bizantinas (ou arbitrrias) so uma
soluo elegante para problemas de segurana, uma vez
que separam o tratamento das falhas do protocolo dis-
tribudo que os utiliza. No entanto, desconhecem-se
trabalhos na literatura descrevendo solues especcas
para sistemas dinmicos. Este artigo prope um detector
de falhas bizantinas para tais sistemas. Adicionalmente,
o protocolo apresentado assncrono, isto , no se ba-
seia no uso de temporizadores para a deteco das falhas,
o que favorece sua escalabilidade e adaptabilidade.
Uma verso preliminar deste trabalho foi apresentada no SBRC 2009.

O trabalho tem apoio da FAPESB-Bahia e do CNPq-Brasil.
Murilo Bacharel em Cincia da Computao pela Universidade Fed-

eral da Bahia e este trabalho resultado do seu projeto de nal de curso.
Parte deste trabalho foi desenvolvido por Murilo no Instituto Recncavo
de Tecnologia Salvador Bahia Brasil.
Palavras-chave: detectores de falhas, falhas bizanti-
nas, sistemas distribudos dinmicos, sistemas auto-
organizveis, detectores de falhas assncronos
1. INTRODUO
Um sistema distribudo dinmico [1] composto por
uma populao de ns
1
que podem entrar e sair da rede
aleatoriamente, a qualquer momento da execuo do sis-
tema. Comumente, as seguintes caractersticas so ap-
resentadas: (1) a latncia na transmisso das mensagens
imprevisvel, (2) a rede no est totalmente conectada,
(3) no existem elementos centralizadores na rede, (4)
no possvel prover aos processos uma viso global da
topologia da rede, de forma que cada n tem um conhec-
imento parcial da composio do sistema e (5) os ns
podem alterar sua posio quanto topologia da rede.
Constata-se, portanto, que os protocolos distribudos cls-
sicos, que supem uma rede com composio esttica e
conhecida, no so mais adequados neste novo contexto,
caracterstico das redes entre pares (P2P), redes mveis
auto-organizveis (Manets) e redes de sensores sem o.
Um fator preocupante em sistemas distribudos
dinmicos, em especial, a segurana. A dinamicidade
da populao dos ns e o uso comum de redes sem o
ou da Internet como meios de comunicao facilitam a
ao de agentes maliciosos sobre o sistema. O modelo de
falhas bizantinas [2] lida com este tipo de ataque ao con-
siderar a existncia de processos corruptos, que podem se
comportar de maneira arbitrria na tentativa de impedir
que o sistema funcione conforme a sua especicao. Um
processo bizantino pode, por exemplo, tentar assumir a
1
Neste trabalho, os termos n e processo sero utilizados indistin-
tamente.
Murilo de Lima e Fabola Greve Detectando Falhas Bizantinas em Sistemas
Distribudos Dinmicos
identidade de outro, enviar mensagens com valores in-
corretos, duplicar mensagens ou simplesmente no enviar
mensagens que o protocolo em execuo especicar. O
desenvolvimento de sistemas tolerantes a faltas bizantinas
[3], isto , que mantenham o seu funcionamento correto
apesar do comportamento maligno de alguns de seus pro-
cessos, portanto de especial interesse.
A abstrao de detectores de falhas [4] prov uma
forma modular de tratar as falhas em sistemas assn-
cronos, isto , sistemas que no atendam a restries tem-
porais. O detector separa o tratamento das falhas e os req-
uisitos de sincronia do protocolo distribudo que o utiliza,
de forma que este pode lidar apenas com a tarefa a que se
prope. O problema do consenso [5], por exemplo, que
sumariza diversos problemas de acordo distribudo, no
pode ser resolvido num sistema sem quaisquer suposies
de sincronia, mesmo se apenas um processo falhar por
colapso (crash) [6]. Se o sistema dispe, no entanto, de
um detector da classe S [4], o consenso pode ser re-
solvido para falhas por colapso semlidar diretamente com
questes de sincronia.
A grande maioria das implementaes para detectores
de falhas considera a existncia de uma rede esttica, cuja
composio dos ns conhecida [7]. Mais recentemente,
algumas propostas foram feitas para sistemas mveis e
auto-organizveis. Em [8], Gupta et al. consideram uma
populao dinmica dos ns; j Friedman e Tcharny [9]
toleram a mobilidade dos ns. Todas essas propostas uti-
lizam um mecanismo de temporizao para deteco das
falhas, i.e., os ns monitorama vivacidade dos demais ns
da rede atravs da troca de mensagens do tipo eu estou
vivo". Esse mecanismo, no entanto, no se adqua muito
bem a sistemas distribudos dinmicos, devido impre-
visibilidade na latncia da transmisso das mensagens.
Detectores de falhas assncronos no fazem uso do re-
curso de temporizao. Nessa linha, um trabalho pioneiro
foi apresentado por Mostefaoui et al. [10]. Entretanto,
ele considera uma rede esttica com composio dos ns
conhecida. Em [11], Sens et al. apresentam uma imple-
mentao assncrona de um detector de falhas que trata
tanto a dinamicidade da composio da rede quanto a mo-
bilidade dos ns. Todos esses trabalhos, no entanto, so
focados na deteco de falhas por colapso, i.e., quando
um processo se comporta de maneira benigna at falhar e
haver o trmino da execuo.
Alguns trabalhos [12, 13] so voltados para deteco
de falhas bizantinas. Entretanto, nenhum deles lida com
a dinamicidade do sistema e mobilidade dos seus ns.
Alm disso, todos fundamentam-se no uso de tempo-
rizadores. Os autores desconhecem, portanto, trabalhos
que proponham detectores de falhas bizantinas espec-
cos para sistemas distribudos dinmicos e tambm de-
sconhecem detectores de falhas bizantinas que sejam as-
sncronos. Existem trabalhos voltados para problemas es-
peccos, como o caso de Awerbuch et al. [14], que
resolvem a deteco para o roteamento, ou ento, o de
Aguilera et al. [15] que s toleram falhas de omisso e
no consideram falhas de segurana.
Este artigo apresenta, ento, o primeiro protocolo para
deteco de falhas bizantinas em sistemas dinmicos e
que, alm disso, tem a caracterstica de ser assncrono.
O protocolo tem por base as abordagens descritas por
Kihlstrom et al. [12] para falhas bizantinas e Sens et al.
[11] para a deteco assncrona. Assim, as falhas de segu-
rana so detectadas atravs da denio de um formato
preestabelecido para as mensagens trocadas pelos proces-
sos. Estas devem ser autenticadas e seu contedo certi-
cado. Quanto s falhas de omisso, a deteco se baseia
no padro de mensagens imposto pelo algoritmo que uti-
liza o detector, o que razovel, uma vez que as falhas
bizantinas so denidas como desvio do comportamento
especicado pelo algoritmo [16]. A deteco assncrona
possvel graas ao padro de troca de mensagens,
topologia da rede e a certas propriedades comportamen-
tais seguidas pelos processos no sistema. O protocolo no
tolera, entretanto, a mobilidade dos ns.
A deteco assncrona, na qual o protocolo se ba-
seia, evidenciou dois importantes resultados. Primeiro,
conjectura-se ser impossvel projetar algoritmos distribu-
dos assncronos tolerantes a falhas bizantinas sem que o
padro de troca de mensagens entre os processos seja dis-
tribudo. Alm disso, conclui-se que o uso da difuso lo-
cal em canais conveis, comum em redes sem o, sim-
plica o tratamento das falhas de segurana, de forma que
determinadas classes de falhas no se conguram no sis-
tema.
O restante deste artigo encontra-se estruturado da
seguinte forma: na Seo 2, dene-se o modelo de sis-
tema. Uma caracterizao do modelo de falhas bizanti-
nas apresentada na Seo 3. As Sees 4-6 apresen-
tam o protocolo desenvolvido, as propriedades comporta-
mentais que o sistema deve atender para que o protocolo
funcione corretamente e sua implementao. A prova da
sua correo exibido na Seo 7. Por m, na Seo 8
apresentam-se as concluses e propostas de trabalhos fu-
turos.
2. MODELO DE SISTEMA
Supe-se um sistema distribudo composto por um
conjunto = {p
1
, p
2
, . . . , p
n
} com n > 4 proces-
sos. Ns podem entrar e sair da rede aleatoriamente,
a qualquer momento da execuo do sistema. No so
feitas quaisquer restries sobre a velocidade dos proces-
sadores, sobre o desvio relativo dos relgios ou sobre os
atrasos de transmisso das mensagens; isto , supe-se
um sistema assncrono. Supe-se a ocorrncia de falhas
10
bizantinas: os processos podem falhar de maneira arbi-
trria, inclusive maliciosa; supe-se entretanto a existn-
cia de um mecanismo de autenticao de mensagens. Os
processos no tm conhecimento de ou n, apenas de
um subconjunto de com os quais estabeleceram comu-
nicao anteriormente. O nmero mximo de falhas tol-
erado f conhecido por todos os processos. Supe-se,
para simplicao das denies e demonstraes apre-
sentadas, a existncia de um tempo global t, embora o
mesmo no seja conhecido pelos processos. Cada pro-
cesso identicado unicamente e processos faltosos no
podem obter mais de um identicador, de forma que
impossvel a ocorrncia de ataques sybil [17].
Os processos trocam mensagens por difuso local
(broadcast) atravs de uma rede de comunicao sem
o. Supe-se a existncia de canais locais conveis,
de forma que as mensagens difundidas so recebidas em
algum momento no futuro por todos os processos cor-
retos dentro da rea de cobertura (range) do transmis-
sor. Os canais no duplicam, alteram ou inserem novas
mensagens e todo processo correto autentica suas men-
sagens de forma incorruptvel. Implementaes de comu-
nicao por difuso em canais conveis para redes sem
o encontram-se em [18, 19].
O sistema pode ser representado por um grafo no-
direcionado G(V, E), sendo V = e {p
i
, p
j
} E se
p
i
e p
j
encontram-se no range um do outro (p
i
e p
j
so
denominados vizinhos). A rea de cobertura range
i
de
um n p
i
denida pelo conjunto range
i
:= {p
j
:
(p
i
, p
j
) E}. Note-se range
i
corresponde vizinhana
de p
i
em G, |range
i
| equivale ao grau de p
i
em G e que
p
i
range
j
p
j
range
i
. Ou seja, a comunicao
entre os processos simtrica.
Denio 1 (Densidade da rea de cobertura (d))
A densidade d de um grafo de comunicao G(V, E)
consiste no tamanho do menor range da rede, isto :
d := min {|range
i
| : i {1, 2, ..., n}}. d portanto o
grau mnimo do grafo G.
Considera-se que o parmetro d da rede conhecido por
todos os processos.
Denio 2 (Rede com f-cobertura bizantina) Uma
rede de comunicao representada pelo grafo G(V, E)
tem f-cobertura bizantina se e somente se G (f + 1)-
conexo e d 2f + 1.
Um grafo k-conexo possui k caminhos distintos nos vr-
tices entre quaisquer par de vrtices, o que leva seguinte
observao:
Observao 1 Em uma rede com f-cobertura bizantina,
apesar da presena de f < n processos faltosos, existir
pelo menos um caminho formado apenas por ns corretos
entre cada par de ns corretos.
3. FALHAS BIZANTINAS
A identicao das falhas bizantinas caracterizada
pela satisfao de dois requisitos: (1) os processos cor-
retos devem possuir uma viso coerente das mensagens
enviadas por cada processo e (2) os processos corretos
devem poder vericar se as mensagens enviadas pelos de-
mais processos esto consistentes com os requisitos do al-
goritmo sendo executado, o que evidencia que a deteco
de falhas bizantinas denida em funo de determinado
algoritmo ou protocolo. O primeiro requisito pode ser
atendido utilizando duas tcnicas distintas: a redundn-
cia da informao e o uso de assinaturas digitais no-
forjveis [2]. O segundo, pela adio de informao s
mensagens, na forma de certicados, que possam ser uti-
lizados para validar o contedo sendo transmitido [12].
A Figura 1 ilustra as classes de falhas bizantinas de-
scritas por Kihlstrom et al. [12], distinguindo-se duas su-
perclasses: detectveis, quando comportamento externo
do processo faltoso fornece evidncias de que o mesmo
falhou e no-detectveis, caso contrrio. Falhas no-
detectveis podem ser subdivididas em no-observveis,
quando os demais processos no podem notar a ocorrn-
cia da falha (por exemplo, um processo faltoso informa
um parmetro fornecido pelo usurio incorretamente) e
no-diagnosticveis, quando no possvel identicar o
processo que gerou a falha (por exemplo, os processos
recebem uma mensagem no assinada).
As falhas detectveis so classicadas em falhas
de progresso (ou falhas por omisso) e falhas de segu-
rana (ou falhas por comisso). Falhas de progresso
atrapalham a terminao da computao, uma vez que o
processo faltoso no envia mensagens requeridas por sua
especicao ou as envia a apenas parte dos processos
do sistema. Falhas de segurana violam propriedades
invariantes s quais os processos devem atender, podendo
ser denidas como o no-cumprimento de uma das
seguintes restries: (1) um processo deve enviar as
mesmas mensagens para todos os outros (um processo
faltoso poderia, portanto, enviar a mesma mensagem
com valores distintos para processos distintos); (2)
as mensagens enviadas devem estar de acordo com o
algoritmo sendo executado.
Propriedades do detector de falhas. Kihlstrom et al.
[12] tambm denem classes de detectores de falhas
bizantinas que diferem das descritas por Chandra e Toueg
[4], uma vez que ali so detectadas apenas falhas por co-
lapso. Seja A um algoritmo que utiliza o detector de fa-
lhas como mdulo subjacente. A classe S(Byz, A), que
o foco deste trabalho, denida pelas seguintes pro-
priedades:
(i) Completude forte bizantina (para algoritmo A): em al-
gum momento no futuro todo processo correto suspeita
permanentemente de todo processo que se desviou de A
11
Figura 1. Categorizao das falhas bizantinas [12]
de forma detectvel;
(ii) Preciso fraca aps um tempo: em algum momento
no futuro, um processo correto no ser suspeito por qual-
quer processo correto.
4. PRINCPIOS BSICOS DO PROTO-
COLO DE DETECO ASSNCRONA DE FA-
LHAS BIZANTINAS
Nesta seo so apresentados os princpios funda-
mentais para o projeto do detector assncrono para falhas
bizantinas.
4.1. PADRO DE TROCA DE MENSAGENS
Grande parte dos protocolos de deteco de falhas por
colapso baseiam-se num mecanismo de troca de men-
sagens do tipo eu estou vivo (Im alive). Entretanto,
no modelo bizantino, devido ocorrncia de processos
maliciosos, tal mecanismo no mais suciente. Um pro-
cesso faltoso pode responder corretamente s mensagens
do detector de falhas sem no entanto garantir o progresso
e a segurana do algoritmo sendo executado. Conseqen-
temente, a deteco das falhas deve se basear no padro
das mensagens enviadas na execuo do algoritmo A que
utiliza o detector de falhas. Assim sendo, de forma sim-
ilar ao feito por Kihlstrom et al. [12], as suspeitas so
levantadas em funo das mensagens requeridas por A.
Entretanto, neste trabalho tais suspeitas so identicadas
de maneira assncrona, sem recorrer ao uso de tempo-
rizadores (mecanismos de timeout) para detectar falhas
de omisso. Alm disso, a deteco segue um padro de
troca de mensagens local, ou seja, entre os ns que se en-
contram na vizinhana.
A deteco assncrona das falhas feita aguardando-
se a recepo de determinada mensagem a partir de (d
f) remetentes distintos. (df) corresponde quantidade
mnima de ns corretos na vizinhana de determinado n
na rede. Esta estratgia a mesma seguida por Sens et
al. [11]. Entretanto, o padro de mensagens QUERY-
RESPONSE, no qual eles se fundamentam, no adequado
ao modelo bizantino, pois, como dito anteriormente, um
processo faltoso pode enviar mensagens RESPONSE sem
no entanto atender aos requisitos de progresso do algo-
ritmo A. O protocolo aqui apresentado ir, portanto, efe-
tuar as suas suspeitas com base na troca de mensagens
requeridas por A. Assim, prope-se que os processos
aguardem a recepo das mensagens de A a partir de
pelo menos (d f) remetentes distintos, suspeitando-se
da omisso dos demais processos. importante observar
que para que tal suspeita possa ser feita, o padro de co-
municao do algoritmo A deve ser distribudo. Ou seja,
em cada passo, todos processos devem trocar mensagens
entre si, seguindo o padro n n. Protocolos com esse
padro so denominados simtricos. Como o detector
segue um padro local de troca de mensagens, essa co-
municao deve ocorrer pelo menos entre os processos
que esto na mesma vizinhana. Algoritmos de consenso
simtricos que utilizam um detector de falhas S foram
sugeridos por Guerraoui e Raynal [20].
Um outro aspecto importante a considerar que a
deteco segue um padro assncrono. Como as sus-
peitas so feitas com base no padro de troca de men-
sagens do algoritmo, conjectura-se ser impossvel realizar
a deteco de falhas por omisso se tal padro do tipo
1 n. Ou seja, se, em algum momento da execuo
do algoritmo, requer-se que apenas um processo envie
mensagens. Isto porque no haveria como diferenciar
uma falha por omisso de um retardo na recepo da
mensagem proveniente de tal processo, dado que o sis-
tema subjacente assncrono [4]. Portanto, identicamos
a seguinte conjectura, que se correta deriva o seguinte
corolrio:
Conjectura 1 Num sistema assncrono, impossvel de-
tectar falhas bizantinas por omisso, de forma assn-
crona, caso o padro de troca de mensagens do algoritmo
A seja do tipo 1 n; isto , se em determinado mo-
mento, o algoritmo A determina que apenas um processo
envia mensagens aos demais (n).
Corolrio 1 A forma assncrona da deteco de falhas
12
bizantinas s pode ser adotada por protocolos simtricos,
nos quais todos os ns executam o mesmo papel.
4.2. GERAO DE SUSPEITAS E EQUVOCOS
Gerao de suspeitas. Cada suspeita (suspicion) sobre
um processo p
i
associada a uma mensagem m requerida
por A. Requer-se, portanto, que as mensagens recebam
identicadores nicos. As suspeitas so propagadas na
rede e um processo correto adotar uma suspeita no
gerada por ele prprio se e somente se receber pelo
menos f + 1 ocorrncias devidamente autenticadas
provenientes de processos distintos. O requisito de
pelo menos f + 1 ocorrncias impede que processos
maliciosos imponham suspeitas sobre processos corretos.
A Figura 2 ilustra esse mecanismo para determinada
poro da rede, supondo f = 1. Os vizinhos de um
processo p1, faltoso por omisso, percebero que p1 no
est enviando as mensagens que deveria. Numa rede
com f-cobertura bizantina, pelos menos dois (f + 1)
dos processos vizinhos a p1, neste caso p2 e p3, sero
corretos e divulgaro uma suspeita de falha S para seus
respectivos vizinhos. Qualquer processo correto da rede,
por exemplo, p10, ter pelo menos um caminho para
p2 (p10p9 p5p2) e p3 (p10p3) formado apenas por
processos corretos (vide Observao 1), recebendo pelo
menos duas (f + 1) ocorrncias de S, adotando portanto
a suspeita.
Gerao de equvocos. Seja p
i
um processo suspeito
de no ter enviado uma mensagem m. Se em algum
momento um processo correto p
j
receber m de p
i
, p
j
declarar um equvoco (mistake) sobre a suspeita e di-
fundir a mensagem m aos demais, a m de que faam
o mesmo. Na Figura 3, um processo lento p1, sobre o
qual foi levantada uma suspeita, envia a mensagem re-
querida m (representada pelo envelope) a um processo
correto p2. Numa rede com f-cobertura bizantina, haver
pelo menos um caminho formado apenas por processos
corretos de cada processo correto at p2. Por exemplo,
para p10, temos o caminho p2p5 p9p10. Logo p10 (e
qualquer outro processo correto) receber m e poder re-
tirar sua suspeita correspondente.
Esse procedimento permite que um processo mali-
cioso, de forma intermitente, provoque uma suspeita e
em seguida a revogue, levando-se a um mascaramento
de parte das falhas por omisso e a uma degradao do
desempenho do detector de falhas. No possvel, no
entanto, distinguir um processo com este comportamento
de um processo lento ou de um perodo de instabilidade
no canal de comunicao.
4.3. DETECO DE FALHAS DE SEGURANA
Para ser possvel a deteco das falhas de segurana,
um formato de mensagens deve ser estabelecido. Cada
mensagem deve tambm incluir um certicado que pos-
sibilite aos demais processos vericar a coerncia da
mesma com o algoritmo A. Caso um processo correto
detecte a invalidade de uma mensagem recebida, seja por
no atender ao formato ou por no estar devidamente jus-
ticada, suspeitar permanentemente do processo reme-
tente e encaminhar a mensagem original aos demais
processos, de forma que a suspeita seja propagada. A
Figura 4 representa essa situao: um processo faltoso
p1 comete uma falha de segurana divulgando uma men-
sagem corrompida m (representada pelo asterisco). A
falha detectada por um vizinho correto p2, que encam-
inha a mensagem corrompida para o restante da rede.
Uma vez que para cada processo correto h um caminho
formado apenas por processos corretos at p2 (para p10,
o caminho p10p9 p5p2), todos suspeitaro permanen-
temente de p1.
No protocolo, suspeitas, equvocos e provas de fa-
lhas de segurana so todos encaminhados atravs de uma
nica mensagem do tipo SUSPICION, as quais no pre-
cisam ser certicadas. Mensagens que no estejam devi-
damente autenticadas so descartadas, uma vez que con-
guram uma falha no-diagnosticvel (ver Seo 3). O
detector, portanto, no comete erros na deteco das fa-
lhas de segurana do algoritmo A.
No protocolo de Kihlstrom et al. [12], adicional-
mente, necessrio detectar quando um processo encam-
inha duas verses diferentes da mesma mensagem, ou
seja, mensagens mutantes. Para isto requer-se, de um
lado, que os processos corretos reencaminhem para to-
dos os demais cada mensagem recebida, e, por outro lado,
seja gerado um histrico das mensagens provenientes de
cada processo. Supe-se, no entanto, que a comunicao
entre os processos ponto a ponto. No modelo aqui pro-
posto, em que os processos se comunicam apenas por di-
fuso local em canais conveis, natural supor que uma
mensagem transmitida ser recebida, com contedo idn-
tico, por todos os processos corretos, de forma que im-
possvel a ocorrncia de mensagens mutantes. Chega-se,
portanto, seguinte observao:
Observao 2 Em um ambiente de falhas bizantinas, a
suposio de comunicao por difuso (broadcast) em
canais conveis simplica o tratamento das falhas de
segurana, uma vez que os processos vizinhos do reme-
tente tm uma viso consistente das mensagens enviadas
pelo mesmo.
5. PROPRIEDADES COMPORTAMENTAIS
13
Figura 2. Gerao de suspeitas no protocolo proposto (f = 1)
Figura 3. Gerao de equvocos no protocolo proposto (f = 1)
Figura 4. Deteco de falhas de segurana no protocolo proposto (f = 1)
14
DO SISTEMA
Para que o protocolo proposto neste trabalho de-
tecte as falhas de maneira assncrona e satisfaa as
propriedades denidas para a classe S(Byz, A),
necessrio que o sistema atenda a certas propriedades
comportamentais.
Propriedade 1 (Incluso Bizantina (ByzMP)) Seja t
um instante de tempo e KB
t
i
o conjunto de processos
que receberam uma mensagem SUSPICION de p
i
at o
instante t. Um processo p
i
satisfaz a propriedade de in-
cluso bizantina ByzMP se:
ByzMP(p
i
) := t 0 : |KB
t
i
| 2f + 1
Esta propriedade garante que um processo novo p
i
no
sistema em algum momento no futuro ser conhecido por
pelo menos 2f +1 processos, dos quais pelo menos f +1
sero corretos. Para tanto, necessrio que p
i
se comu-
nique compelo menos 2f+1 processos dentro de sua rea
de cobertura, enviando-lhes uma mensagem SUSPICION
por difuso. Dessa forma, se p
i
falhar, em algum mo-
mento no futuro pelo menos f +1 processos corretos sus-
peitaro de p
i
e transmitiro a suspeita para o restante do
sistema, de forma que a propriedade de completude forte
bizantina do detector S(Byz, A) seja atendida. Note-se
que essas comunicaes devem ser realizadas antes do in-
cio do prximo passo do algoritmo A, de forma a garan-
tir a propriedade de completude forte bizantina do detec-
tor de falhas; antes disso, p
i
no deve ser considerado
participante da computao. Se um processo novo no
se comunicar com nenhum outro, impossvel atender
propriedade de completude fraca [21].
Para que a propriedade de preciso fraca aps um
tempo da classe S(Byz, A) seja atendida, necessrio
que exista um processo correto p
i
cujas mensagens a par-
tir de algum momento estejam sempre entre as d f
primeiras recebidas pelos seus vizinhos, a cada requisio
de A. Assim sendo, aps um tempo p
i
no ser mais
suspeito por nenhum processo correto e ter quaisquer
suspeitas anteriores revogadas atravs de mensagens de
equvocos. Logo, a rede deve possuir um n correto que
atenda propriedade de receptividade bizantina, denida
como:
Propriedade 2 (Receptividade Bizantina (ByzRP))
Sejam t e u instantes de tempo e seja rec_from
t
j
o
conjunto de pelo menos d f processos dos quais p
j
recebeu a mensagem requerida por A no ltimo passo
em execuo at o instante t. A propriedade ByzRP do
processo correto p
i
denida como:
ByzRP(p
i
) := u : t > u, p
j
range
i
, p
i

rec_from
t
j
6. PROTOCOLO DE DETECO ASSN-
CRONA DE FALHAS BIZANTINAS EM SIS-
TEMAS DINMICOS
Os Algoritmos 1 e 2 implementam um detector de
falhas da classe S(Byz, A), desde que a rede atenda s
propriedades de f-cobertura bizantina, incluso bizantina
e receptividade bizantina descritas anteriormente e que
o protocolo executado pelo algoritmo A seja simtrico.
Cada processo executa trs tarefas em paralelo, descritas
a seguir. Posteriormente so descritas as variveis,
primitivas e procedimentos para cada processo p
i
.
T1. Gerao de novas suspeitas (linhas 5-14, Algoritmo
1). Quando o algoritmo A requer que os processos
troquem entre si uma mensagem m (linha 6), cada
processo p
i
aguarda receber m de pelo menos d f
processos, cujos identicadores so armazenados no con-
junto rec_from
i
(linhas 7-8). Para os demais processos
conhecidos por p
i
, adicionada uma suspeita interna de
falha por omisso (linhas 9-11). Cada mensagem ento
vericada quanto sua formao e certicao (linhas
12-14, Algoritmo 1 e 5-16, Algoritmo 2). Mensagens in-
corretas levam a suspeitas de falhas de segurana (linhas
9-10, Algoritmo 2) e atualizao da sada do detector;
mensagens corretas levam gerao de equvocos de
possveis suspeitas de falhas por omisso (linhas 12-13,
Algoritmo 2).
T2. Recepo de mensagens de processos lentos e de
mensagens SUSPICION (linhas 16-18, Algoritmo 1).
Uma vez que as mensagens enviadas por um processo
lento podem ser recebidas aps a gerao das suspeitas
pelos seus vizinhos, necessrio que estes identiquem
tais eventos separadamente, o que feito por esta tarefa.
As mensagens so tratadas de forma similar tarefa T1.
O tratamento das mensagens SUSPICION ser explanado
adiante.
T3. Divulgao do novo estado de suspeitas e equvo-
cos (linhas 20-23, Algoritmo 1). Tarefa executada
periodicamente para enviar aos vizinhos de p
i
(linha 22)
a viso de p
i
quanto s suspeitas (internas e externas),
equvocos e provas de falhas de segurana. Os vizinhos
de p
i
recebero esta mensagem na tarefa T2 e trat-la-o
da seguinte forma:
Atualizao do estado interno (linhas 15 e 18-40, Algo-
ritmo 2). Ao receber uma mensagem SUSPICION de um
vizinho q (linha 19), um processo p
i
atualiza seu estado
interno com novas informaes. Suspeitas internas e
externas de q so adicionadas ao conjunto de suspeitas ex-
ternas de p
i
(linhas 20-31), possivelmente gerando novas
suspeitas internas (linhas 32-34, Algoritmo 1). Note-se
15
Algoritmo 1 Detector Assncrono de Falhas Bizantinas
em Sistemas Dinmicos
1: init:
2: output
i
known
i
; extern_susp
i
[][]
3: intern_susp
i
mistake
i
[]; byzantine
i

4:
5: Task T1: /* gerao de novas suspeitas */
6: when p
i
requer uma mensagem m do
7: wait until receber m devidamente autenticada pela
primeira vez de pelo menos (d f) processos distin-
tos
8: rec_from
i
{p
j
| p
i
recebeu uma mensagem de
p
j
na linha 7}
9: for all p
j
(known
i
\ rec_from
i
) do
10: AddInternalSusp(p
j
, m)
11: end for
12: for all m
j
recebida na linha 7 from p
j
do
13: ValidateReceived(p
j
, m
j
)
14: end for
15:
16: Task T2: /* recepo de mensagens de processos
lentos e do estado interno de outro processo */
17: upon receipt of m devidamente autenticada from p
j
do
j
, m)
19:
20: Task T3: /* difuso do estado das suspeitas */
21: loop
22: broadcast SUSPICION, byzantine
i
, mistake
i
,
intern_susp
i
, extern_susp
i
23: end loop

24:
25: /* PROCEDIMENTOS AUXILIARES */
26: procedure AddInternalSusp(q, m):
27: intern_susp
i
[q] intern_susp
i
[q] {m.id}
28: output
i
output
i
{q}
29:
30: procedure AddExternalSusp(q, idm, p
s
):
31: extern_susp
i
[q][idm] extern_susp
i
[q][idm]
{p
s
}
32: if |extern_susp
i
[q][idm]| f + 1 then
33: AddInternalSusp(q, message(idm))
34: end if
35:
36: procedure AddMistake(q, m):
37: mistake
i
[q] mistake
i
[q] {m}
38: extern_susp
i
[q][m.id]
39: intern_susp
i
[q] intern_susp
i
[q] \ {m.id}
40: if intern_susp
i
[q] = and q, byzantine
i
then
41: output
i
output
i
\ {q}
42: end if
Algoritmo 2 Detector Assncrono de Falhas Bizantinas
em Sistemas Dinmicos (continuao)
1: procedure AddByzantine(q, m):
2: output
i
output
i
{q};
3: byzantine
i
byzantine
i
{q, m}
4:
5: procedure ValidateReceived(q, m):
6: if m foi enviada diretamente por q then
7: known
i
known
i
{q}
8: end if
9: if m no est devidamente formada or m no est
devidamente justicada then
10: AddByzantine(q, m)
11: else
12: if m.id intern_susp
i
[q] or m foi reencamin-
hada then
13: AddMistake(q, m)
14: end if
15: UpdateSuspicions(q, m)
16: end if
17:
18: procedure UpdateSuspicions(q, m):
19: if m = SUSPICION, byzantine
q
, mistake
q
,
intern_susp
q
, extern_susp
q
then
20: for all p
x
keys(extern_susp
q
) do
21: for all idm
x
keys(extern_susp
q
[p
x
])
devidamente autenticado | idm
x
/
ids(mistake
i
[p
x
]) do
22: for all p
y
extern_susp
q
[p
x
][idm
x
] do
23: AddExternalSusp(p
x
, idm
x
, p
y
)
24: end for
25: end for
26: end for
27: for all p
x
keys(intern_susp
q
) do
28: for all idm
x
intern_susp
q
[p
x
] devidamente
autenticado | idm
x
/ ids(mistake
i
[p
x
]) do
29: AddExternalSusp(p
x
, idm
x
, q)
30: end for
31: end for
32: for all p
x
keys(mistake
q
) do
33: for all m
x
mistake
q
[p
x
] devidamente auten-
ticada do
x
, m
x
)
35: end for
36: end for
37: for all p
x
, m
x
byzantine
q
| m
x
est devida-
mente autenticada do
x
, m
x
)
39: end for
40: end if
16
que ser gerada uma suspeita de falha de segurana do
processo q (linhas 9-10) caso a mensagem SUSPICION m
esteja malformada ou no justicada. Provas de falhas
de segurana e informaes de equvoco so tratadas
de forma similar s mensagens recebidas diretamente
do remetente (linhas 34 e 38). Algumas otimizaes
nesse procedimento foram removidas nesta verso
do protocolo, a m de simplicar as demonstraes da
Seo 7. Oleitor interessado poder encontr-las em [22].
VARIVEIS:
output
i
: armazena a sada do detector de falhas, isto
, o conjunto de identicadores dos processos de que p
i
suspeita terem falhado;
known
i
: armazena o conjunto dos processos que se
comunicaram com p
i
, isto , sua suposta vizinhana.
atualizada a cada recepo de mensagem m, seja m do
tipo SUSPICION ou uma mensagem inerente a A;
extern_susp
i
: matriz que armazena suspeitas externas
(geradas por outros processos). A matriz indexada por
um identicador de processo q e por um identicador
de mensagem idm. Cada entrada armazena o conjunto
de processos dos quais p
i
recebeu suspeitas de q no ter
enviado a mensagem com identicador idm;
intern_susp
i
: vetor de suspeitas internas. Uma
suspeita interna gerada pela no-recepo de uma
mensagem requerida por A ou pela existncia de pelo
menos f + 1 suspeitas externas sobre um mesmo par
processo-mensagem;
mistake
i
: vetor que armazena, para cada processo
aplicvel p
j
, o conjunto de equvocos relacionados a p
j
,
na forma de mensagens requeridas por A sobre as quais
foram levantadas suspeitas;
byzantine
i
: conjunto de duplas do tipo processo,
mensagem que provam comportamento bizantino do
processo associado. A notao p, indica qualquer
dupla associada ao processo p;
rec_from
i
: conjunto de processos dos quais p
i
recebeu a mensagem requisitada por A.
PRIMITIVAS:
m.id - retorna o identicador da mensagem m;
message(idm) - retorna a mensagem associada ao
identicador idm;
vericao de boa formao, justicao (certicao
do contedo) e autenticao das mensagens;
requisio por A de uma determinada mensagem;
broadcast m - difunde a mensagem m para os vizinhos
de p
i
;
keys(v) - retorna o conjunto de ndices de um vetor
dinmico v;
ids(s) - retorna o conjunto de identicadores associados
s mensagens do conjunto s.
PROCEDIMENTOS AUXILIARES:
AddInternalSusp(q, m) (linhas 26-28, Algoritmo 1):
adiciona uma suspeita interna sobre o processo q em re-
lao mensagem m;
AddExternalSusp(q, idm, p
s
) (linhas 30-34, Algo-
ritmo 1): adiciona uma suspeita externa sobre o pro-
cesso q proveniente do processo p
s
em relao men-
sagem com identicado idm. Adicionalmente, caso exis-
tam f + 1 ou mais suspeitas externas sobre q em relao
a message(idm), gera uma suspeita interna equivalente,
caso ainda no exista;
AddMistake(q, m) (linhas 36-42, Algoritmo 1): adi-
ciona um equvoco sobre a suspeita de q no ter enviado
m, retirando todas as suspeitas internas e externas associ-
adas. Caso q no tenha outras suspeitas nem tenha apre-
sentado comportamento bizantino, remove-o da sada do
detector de falhas;
AddByzantine(q, m) (linhas 1-3, Algoritmo 2): adi-
ciona q permanentemente lista de processos maliciosos
(e, conseqentemente, sada do FD), juntamente com a
mensagem m associada falha bizantina, servindo como
prova da falha;
ValidateReceived(q, m) (Algoritmo 2, linhas 5-16): ver-
ica a validade (boa formao e justicao) da men-
sagem m recebida de q, retirando quaisquer suspeitas as-
sociadas ao par (q, m), caso m seja vlida, e gerando
uma suspeita de falha de segurana, caso contrrio. Adi-
cionalmente, atualiza o conjunto de ns conhecidos por
p
i
(known
i
) e repassa as mensagens ao procedimento a
seguir, de forma a atualizar o estado de suspeitas;
UpdateSuspicions(q, m) (Algoritmo 2, linhas 18-40):
caso m seja do tipo SUSPICION, atualiza o estado interno
de p
i
com as informaes de falhas contidas em m.
7. PROVA DE CORREO
A correo do algoritmo denida em funo das pro-
priedades de completude forte bizantina e preciso fraca
aps um tempo da classe S(Byz, A) de detectores de
falhas. Dessa forma, os argumentos so exibidos para
cada propriedade separadamente.
7.1. COMPLETUDE FORTE BIZANTINA
Lema 1 Se um processo p
i
nunca enviar uma mensagem
m, jamais algum processo correto efetuar uma chamada
ao procedimento AddMistake com parmetros (p
i
, m).
Prova: Suponha-se, por contradio, que algum pro-
cesso correto p
j
efetue uma chamada a AddMistake com
parmetros (p
i
, m). Note-se que a nica chamada ao pro-
cedimento AddMistake est no procedimento ValidateRe-
ceived, na linha 13 do Algoritmo 2. O procedimento Val-
idateReceived, por sua vez, chamado nos seguintes ca-
sos: (1) na recepo de mensagens requeridas por A, seja
17
durante o mecanismo de espera da tarefa T1, seja poste-
riormente na tarefa T2 (linhas 13 e 18 do Algoritmo 1,
respectivamente); (2) na recepo de mensagens SUSPI-
CION, na tarefa T2; (3) na atualizao do estado interno
com informaes de vizinhos (procedimento UpdateSus-
picions, linhas 34 e 38 do Algoritmo 2). Em todos os
casos, a autenticao de m vericada (respectivamente,
nas linhas 7 e 17 do Algoritmo 1 e nas linhas 33 e 37 do
Algoritmo 2). Desse fato e do uso de canais conveis,
um processo bizantino no pode enviar m em lugar de
p
i
. O caso (2), especicamente, no poderia causar uma
chamada a AddMistake, j que no existemsuspeitas rela-
cionadas a mensagens SUSPICION e mensagens SUSPI-
CION corretas no so reencaminhadas.
Em todos os casos, chega-se contradio de ser
necessrio que p
i
envie m em algum momento, do que o
lema segue.
Lema 2 Seja p
i
um processo faltoso por omisso. Em
algum momento no futuro, todo processo correto p
j
em
incluir p
i
permanentemente em output
j
.
Prova: Seja m a primeira mensagem requerida por Ano
enviada por p
i
. Seja t o instante em que A requer m de
p
i
e u o primeiro instante tal que |KB
u
i
| 2f +1, sendo
KB
u
i
como denido na Propriedade 1; um tal instante u
existe devido a ByzMP. Tem-se que t u, pois antes
de u p
i
no participava da computao distribuda (ver
Seo 5).
Se p
j
est em KB
t
i
, ento p
j
recebeu uma mensagem
do tipo SUSPICION de p
i
at o instante t, e portanto p
i
est
em known
j
, conforme as linhas 17-18 do Algoritmo 1 e
6-8 do Algoritmo 2. Quando A requerer m a p
j
, este
aguardar somente at receber m de d f processos dis-
tintos (linhas 6-7 do Algoritmo 1); esse evento acontecer
em algum momento, j que no mximo f processos so
faltosos e |range
j
| d. Como p
i
no envia m, no ser
includo em rec_from
j
(linha 8 do Algoritmo 1). Con-
forme as linhas 9-11 e 27-28 do Algoritmo 1, m.id ser
includo em intern_susp
j
[p
i
] e p
i
em output
j
. Uma vez
que p
i
tambm no enviar m em outro momento poste-
rior, pelo Lema 1 e pelas linhas 39-42 do Algoritmo 1,
m.id nunca ser removido de intern_susp
j
[p
i
] nem p
i
de output
j
.
Se p
j
no est em KB
t
i
, no entanto, uma vez que a
rede possui f-cobertura bizantina, existe ao menos um
caminho P formado apenas por processos corretos en-
tre p
j
e cada p
k
correto em KB
t
i
; se houver mais de um
tal caminho, tome-se o de latncia total mnima. Prova,
por induo no comprimento de P, de que em algum mo-
mento p
k
adicionado a extern_susp
j
[p
i
][m.id]: se P
tem comprimento 1, p
j
vizinho de p
k
; nesse caso, em
algum momento p
k
difunde (linha 22 do Algoritmo 1)
uma mensagem SUSPICION s com a informao auten-
ticada de que m.id intern_susp
k
[p
i
]; como os canais
so conveis, em algum momento p
j
recebe s na linha
17 do Algoritmo 1. Como p
k
correto, s estar devida-
mente autenticada, formada e justicada; pelo Lema 1,
m / mistake
j
[p
i
]; assim, pela linha 18 do Algoritmo
1 e pelas linhas 15 e 27-31 do Algoritmo 2, p
k
adi-
cionado a extern_susp
j
[p
i
][m.id] na linha 31 do Algo-
ritmo 1 e a armao vale. Se o comprimento de P
maior que 1, pode-se supor por hiptese de induo que
a armao vale para o caminho P p
j
entre p
k
e um
processo correto p
l
, visto que tal caminho possui com-
primento menor que P. Notadamente p
l
vizinho de p
j
em P; por hiptese de induo, em algum momento p
k
adicionado a extern_susp
l
[p
i
][m.id] e, futuramente, p
l
difunde (linha 22 do Algoritmo 1) uma mensagem SUSPI-
CION s com essa informao autenticada por p
k
; como os
canais so conveis, em algum momento p
j
recebe s na
linha 17 do Algoritmo 1. Como p
l
correto, s estar dev-
idamente autenticada, formada e justicada; pelo Lema 1,
m / mistake
j
[p
i
]; assim, pela linha 18 do Algoritmo 1
e pelas linhas 15 e 20-26 do Algoritmo 2, p
k
adicionado
a extern_susp
j
[p
i
][m.id] na linha 31 do Algoritmo 1 e a
armao vale.
Desse fato, de |KB
t
i
| 2f + 1 e de existirem
no mximo f processos faltosos segue que em algum
momento p
j
executa a linha 33 do Algoritmo 1 e, pelas
linhas 27-28, adiciona m.id a intern_susp
j
[p
i
] e p
i
a
output
j
. Novamente, segue do Lema 1 que p
i
nunca ser
removido de output
j
.
Lema 3 Seja p
i
um processo faltoso por comisso (isto
, que cometa uma falha de segurana detectvel). Em
algum momento no futuro, todo processo correto p
j
em
, adiciona permanentemente p
i
a output
j
.
Prova: Uma falha por comisso consiste no envio por p
i
de uma mensagem m em desacordo com A, isto , uma
mensagem mal formada ou no justicada (ver Seo 3);
o uso de comunicao por difuso impede a ocorrncia de
mensagens mutantes (ver Seo 4). Alm disso, m uma
mensagem autenticada; caso contrrio, congura-se uma
falha no-diagnosticvel (ver Seo 3).
Devido propriedade de f-cobertura bizantina, ex-
iste um caminho P, entre p
i
e cada processo correto p
j
,
formado apenas por processos corretos, exceto por p
i
;
se houver mais de um tal caminho, tome-se o de latn-
cia total mnima. Prova, por induo no comprimento
de P, de que em algum momento p
j
adiciona p
i
, m a
byzantine
j
e p
i
a output
j
: se o comprimento de P
1, ento p
j
range
i
e, j que os canais so conveis
e m autenticada, p
j
recebe m em algum momento na
linha 7 ou na linha 17 do Algoritmo 1. Em ambos os
18
casos, feita uma chamada ao procedimento ValidateRe-
ceived (linhas 13 e 18 do Algoritmo 1), que verica na
linha 9 do Algoritmo 2 a invalidade de m. O proced-
imento AddByzantine (linhas 1-3 do Algoritmo 2), por
sua vez, adiciona p
i
a output
j
e p
i
, m a byzantine
j
, do
que a armao segue. Se o comprimento de P maior
que 1, a armao vlida por hiptese de induo para
o caminho P p
j
entre p
i
e algum processo correto p
k
vizinho de p
j
. Nesse caso, p
i
, m est em byzantine
k
e, em algum momento posterior, p
k
difunde (linha 22 do
Algoritmo 1) uma mensagem SUSPICION s com essa in-
formao; como os canais so conveis, em algum mo-
mento p
j
recebe s na linha 17 do Algoritmo 1. Como
p
l
correto, s estar devidamente autenticada, formada
e justicada; assim, por m ser autenticada, pela linha 18
do Algoritmo 1 e pelas linhas 15 e 37-39 do Algoritmo 2,
p
j
efetua uma chamada a ValidateReceived que conrma
a invalidade de m; portanto p
i
adicionado a output
j
e
p
i
, m a byzantine
j
e a armao vale.
Desse fato e uma vez que p
j
s remove p
i
de output
j
se no houver um par p
i
, em byzantine
j
(linhas
40-42 do Algoritmo 1), p
i
adicionado denitivamente a
output
j
e o lema segue.
7.2. PRECISO FRACA APS UM TEMPO
Lema 4 Se p
i
e p
j
so processos corretos ento, du-
rante toda a computao, p
j
jamais efetua uma chamada
ao procedimento AddByzantine tendo p
i
como primeiro
parmetro.
Prova: Note que a nica chamada a AddByzantine est
na linha 10 do Algoritmo 2, no procedimento ValidateRe-
ceived. Conforme a linha 9, essa chamada s efetuada
por um processo correto se p
i
enviar uma mensagem mal
formada ou no justicada, o que no possvel, uma vez
que p
i
correto. Se um processo bizantino enviar uma tal
mensagem no lugar de p
i
, p
j
a descartar, uma vez que
os canais de comunicao so conveis e p
j
verica a
autenticao de toda mensagem que recebe (linhas 7 e 17
do Algoritmo 1 e linhas 33 e 37 do Algoritmo 2), logo o
lema segue.
Lema 5 Seja p
i
um processo correto e m uma mensagem
requerida por A. Se todo n em range
i
receber m de p
i
na linha 7 do Algoritmo 1, jamais algum processo correto
p
j
em efetuar uma chamada a AddInternalSusp com
parmetros (p
i
, m).
Prova: O procedimento AddInternalSusp chamado em
duas situaes: (1) na tarefa T1, durante a recepo de
mensagens requeridas por A e (2) no procedimento Add-
ExternalSusp, ao identicar a ocorrncia de f + 1 ou
mais suspeitas externas de p
i
no ter enviado m. Pela
hiptese do lema, processos em range
i
adicionam p
i
a
rec_from
j
na linha 8 do Algoritmo 1, logo no chamam
AddInternalSusp na linha 10 com parmetros (p
i
, m).
Um processo p
j
fora de range
i
no pode receber men-
sagens diretamente de p
i
, logo no adiciona p
i
a known
j
em nenhum momento (linhas 6-8 do Algoritmo 2) nem
efetua a chamada a AddInternalSusp da linha 10 com
parmetros (p
i
, m). Em ambas as situaes, o caso (1)
conrma o lema.
Quanto ao caso (2), note-se que chamadas a AddEx-
ternalSusp s so realizadas nas linhas 23 e 29 do Al-
goritmo 2. Uma vez que um processo correto s atu-
aliza seu conjunto extern_susp no procedimento Add-
ExternalSusp, toda suspeita externa proveniente de um
processo correto foi gerada como uma suspeita interna
(ver linhas 22 e 28 do Algoritmo 1). Pelo argumento
do caso (1), um processo correto p
j
nunca adiciona m.id
a intern_susp
j
[p
i
] atravs tarefa T1; se um processo
bizantino p
k
adicionar p
j
a extern_susp
k
[p
i
][m.id], um
processo correto no adotar tal suspeita, uma vez que
sua autenticao vericada na linha 21 do Algoritmo 2.
Um processo faltoso p
j
pode, no entanto, adicionar m.id
a intern_susp
j
[p
i
] e autenticar essa informao, mas s
existem no mximo f processos faltosos, logo nenhum
processo correto chama AddInternalSusp na linha 33 do
Algoritmo 1 com parmetros (p
i
, m).
Uma vez que todos os casos possveis foram analisa-
dos, o lema segue.
Lema 6 Seja p
i
um processo correto. Se existe um men-
sagem m e um processo correto p
j
tal que m.id
intern_susp
j
[p
i
] em algum instante da computao, en-
to em algum momento no futuro p
j
efetua uma chamada
a AddMistake com parmetros (p
i
, m).
Prova: Se p
j
est em range
i
, como p
i
correto, em al-
gum momento p
j
recebe m de p
i
(devidamente autenti-
cada, formada e justicada) na linha 17 do Algoritmo 1.
Pela hiptese do lema, m.id intern_susp
j
[p
i
], assim,
pelas linhas 18 do Algoritmo 1 e pelas linhas 9 e 12 do
Algoritmo 2, p
j
efetua uma chamada a AddMistake com
parmetros (p
i
, m) na linha 13 do Algoritmo 2.
Se p
j
no est em range
i
, por argumento semel-
hante ao feito no lema anterior, p
i
/ known
j
. Ento,
algum outro processo correto p
k
em range
i
gerou
a suspeita, isto , existe p
k
em range
i
tal que m.id
intern_susp
k
[p
i
]. Como a rede possui f-cobertura
bizantina, existe um caminho P formado apenas por
processos corretos entre p
k
e p
j
; se houver mais de um
tal caminho, tome-se o de latncia total mnima. Prova,
por induo no comprimento de P, de que em algum
momento cada processo p
l
em P chama AddMistake
com parmetros (p
i
, m) e portanto m mistake
l
[p
i
]:
se o comprimento de P zero, P contm apenas p
k
e,
19
pelo argumento do pargrafo anterior, a armao vale.
Se o comprimento de P maior que zero ento, por
hiptese de induo, a armao vale para o caminho
P p
j
entre p
k
e um processo p
l
e, em algum momento,
m mistake
l
[p
i
]. Futuramente, p
l
difunde uma
mensagem SUSPICION s com m devidamente autenticada
em mistake
l
[p
i
]; como os canais so conveis, em
algum momento p
j
recebe s na linha 17 do Algoritmo
1. Como p
l
correto, s estar devidamente autenticada,
formada e justicada e, pela linha 18 do Algoritmo 1
e pelas linhas 19 e 32-36 do Algoritmo 2, p
j
chama
ValidateReceived com parmetros (p
i
, m). Como p
i

correto, m est devidamente formada e justicada. Como
m foi reencaminhada por p
l
, p
j
chama AddMistake com
parmetros (p
i
, m) na linha 13 do Algoritmo 2 (ver linhas
9 e 12-14) e a armao vale; portanto, o lema segue.
Lema 7 Seja p
i
um processo correto que atenda a
ByzRP. Em algum momento no futuro, todo processo
correto p
j
em tal que p
i
/ output
j
.
Prova: Do Lema 4, arma-se que p
i
jamais ser adi-
cionado a output
j
na linha 2 do Algoritmo 2. Pela
propriedade ByzRP, existe um instante t aps o qual
toda mensagem m requerida por A recebida pelos
vizinhos de p
i
na linha 7 do Algoritmo 1; do Lema 5
verica-se que p
j
no adiciona p
i
a output
j
em uma
chamada a AddInternalSusp com parmetros (p
i
, m).
Para toda mensagem m
requerida por A antes de t, se

em algum instante m
intern_susp
j
[p
i
], pelo Lema
6, em algum momento futuro p
j
chama AddMistake com
parmetros (p
i
, m
). Assim, pela linha 39 do Algoritmo

1, em algum momento tem-se que intern_susp
j
[p
i
] = ;
pelo Lema 4, no existe p
i
, em byzantine
j
, logo p
i
removido de output
j
na linha 41 do Algoritmo 1 e o
lema segue.
Teorema 1 Os Algoritmos 1 e 2 implementam um detec-
tor de falhas da classe S(Byz, A).
Prova: O teorema segue dos Lemas 2, 3 e 7 e da
denio da classe S(Byz, A) (ver Seo 3).
8. CONCLUSO E TRABALHOS FUTUROS
Este trabalho apresentou um detector de falhas
bizantinas com duas caractersticas inovadoras: (i) ele
foi projetado para sistemas distribudos dinmicos, cujo
conjunto de participantes na rede desconhecido e, alm
disso, (ii) tema caracterstica de ser assncrono, isto , no
se utiliza de temporizadores para a deteco das falhas de
progresso. Para que a deteco seja realizada de forma
assncrona, conjectura-se ser necessrio que o algoritmo
que utiliza o detector de falhas seja simtrico, isto , que
a cada passo todos os processos troquem mensagens en-
tre si. Um aspecto interessante que a comunicao por
difuso (broadcast), tpica das redes sem o, simplica
o tratamento de falhas bizantinas, uma vez que os pro-
cessos vizinhos de um remetente tm uma viso uniforme
das mensagens por ele enviadas. Especicamente, no
necessrio tratar a ocorrncia de mensagens mutantes, isto
, quando um mesmo processo envia a mesma mensagem
com contedos diferentes para diferentes processos.
Objetivam-se como trabalhos futuros (i) estender o
protocolo para prover tolerncia mobilidade dos ns; (ii)
implementar o protocolo, com o objetivo de avaliar seu
desempenho e viabilidade prtica; (iii) provar ou contra-
exemplicar a impossibilidade de realizao de deteco
de falhas de forma assncrona em sistemas sujeitos a fa-
lhas bizantinas com comunicao do tipo 1 n.
Referncias
[1] A. Mostefaoui, M. Raynal, C. Travers, S. Patter-
son, D. Agrawal, and A. El Abbadi. From Static
Distributed Systems to Dynamic Systems. In Proc.
of the 24th IEEE Symp. on Reliable Distributed
Systems, pages 109118, Los Alamitos, CA, USA,
2005. IEEE Computer Society.
[2] L. Lamport, R. Shostak, and M. Pease. The byzan-
tine generals problem. ACM Trans. Program. Lang.
Syst., 4(3):382401, 1982.
[3] M. Castro and B. Liskov. Practical Byzantine Fault
Tolerance and Proactive Recovery. ACM Transac-
tions on Computer Systems, 20(4):398461, 2002.
[4] T. D. Chandra and S. Toueg. Unreliable failure de-
tectors for reliable distributed systems. J. ACM,
43(2):225267, 1996.
[5] M. Correia, P. Verssimo, and N. F. Neves. Byzan-
tine Consensus in Asynchronous Message-Passing
Systems: a Survey. In Resilience-building Tech-
nologies: State of Knowledge, Deliverable D12, Part
Algo, chapter 1. RESIST Network of Excellence,
September 2006.
[6] M. J. Fischer, N. A. Lynch, and M. S. Paterson. Im-
possibility of distributed consensus with one faulty
process. J. ACM, 32(2):374382, 1985.
[7] M. Larrea, A. Fernndez, and S. Arvalo. Opti-
mal implementation of the weakest failure detector
for solving consensus. In Proc. of the 19th IEEE
20
Symp. on Reliable Distributed Systems, pages 52
59, Washington, DC, USA, 2000. IEEE Computer
Society.
[8] I. Gupta, T. D. Chandra, and G. S. Goldszmidt. On
scalable and efcient distributed failure detectors.
In Proc. of the 20th Annual ACM Symp. on Princi-
ples of Distributed Computing, pages 170179, New
York, NY, USA, 2001. ACM Press.
[9] R. Friedman and G. Tcharny. Evaluating failure de-
tection in mobile ad-hoc networks. Int. Journal of
Wireless and Mobile Computing, 1(8), 2005.
[10] A. Mostefaoui, E. Mourgaya, and M. Raynal. Asyn-
chronous Implementation of Failure Detectors. In
Proc. of the 2003 Int. Conf. on Dependable Systems
and Networks, page 351, Los Alamitos, CA, USA,
2003. IEEE Computer Society.
[11] P. Sens, F. Greve, L. Arantes, M. Bouillaguet, and
V. Simon. Um Detector de Falhas Assncrono para
Redes Mveis e Auto-Organizveis. In Anais do
Simpsio Brasileiro de Redes de Computadores e
Sistemas Distribudos, Rio de Janeiro, RJ, Brazil,
2008. Sociedade Brasileira de Computao.
[12] K. P. Kihlstrom, L. E. Moser, and P. M. Melliar-
Smith. Byzantine Fault Detectors for Solving Con-
sensus. The Computer Journal, 46(1):1635, 2003.
[13] R. Baldoni, J.-M. Hlary, and S. T. Piergiovanni.
A Component-Based Methodology to Design Arbi-
trary Failure Detectors for Distributed Protocols. In
Proc. of the 10th IEEE Int. Symp. on Object and
Component-Oriented Real-Time Distributed Com-
puting, pages 5161, Washington, DC, USA, 2007.
IEEE Computer Society.
[14] B. Awerbuch, D. Holmer, C. Nita-Rotaru, and
H. Rubens. An on-demand secure routing protocol
resilient to byzantine failures. In Proc. of the 1st
ACM Workshop on Wireless Security, pages 2130,
New York, NY, USA, 2002. ACM.
[15] M. K. Aguilera, W. Chen, and S. Toueg. Heartbeat:
A Timeout-Free Failure Detector for Quiescent Re-
liable Communication. In Proc. of the 11th Int.
Workshop on Distributed Algorithms, pages 126
140, London, UK, 1997. Springer-Verlag.
[16] D. Malkhi and M. Reiter. Unreliable intrusion detec-
tion in distributed computations. In Proc. 10th Com-
puter Security Foundations Workshop, pages 116
124, Rockport, MA, 1997. IEEE Computer Society
Press, Los Alamitos, CA.
[17] J. R. Douceur. The sybil attack. In Revised Papers
from the First Int. Workshop on Peer-to-Peer Sys-
tems, pages 251260, London, UK, 2002. Springer-
Verlag.
[18] K. Tang and M. Gerla. MAC reliable broadcast in
ad hoc networks. In IEEE Military Communica-
tions Conference, 2001. MILCOM 2001. Communi-
cations for Network-Centric Operations: Creating
the Information Force, volume 2, pages 10081013,
2001.
[19] M.-T. Sun, L. Huang, A. Arora, and T.-H. Lai. Re-
liable MAC Layer Multicast in IEEE 802.11 Wire-
less Networks. In ICPP 02: Proceedings of the
2002 International Conference on Parallel Process-
ing, pages 527536, Washington, DC, USA, 2002.
IEEE Computer Society.
[20] R. Guerraoui and M. Raynal. The Information
Structure of Indulgent Consensus. IEEE Trans.
Comput., 53(4):453466, 2004.
[21] A. Fernndez, E. Jimnez, and S. Arvalo. Mini-
mal system conditions to implement unreliable fail-
ure detectors. In 12th Pacic Rim Int. Symp. on De-
pendable Computing, pages 6372, Los Alamitos,
CA, USA, 2006. IEEE Computer Society.
[22] M. S. de Lima and F. G. P. Greve. Protocolo Assn-
crono para Deteco de Falhas Bizantinas em Sis-
temas Distribudos Dinmicos. In Anais do Simp-
sio Brasileiro de Redes de Computadores e Sistemas
Distribudos, pages 887900, Recife, PE, Brazil,
May 2009. Sociedade Brasileira de Computao.
21
Um Protocolo Geogrco para
Restringir as Mensagens de
Descoberta e Resposta de Servios
em Redes Mveis Cooperativas
Janine Kniess
1,2
, Orlando Loques
1
& Clio V. N. Albuquerque
1
1
Instituto de Computao Universidade Federal Fluminense UFF
Rua Passo da Ptria 156 - Niteri, RJ - Brasil
{jkniess | loques | celio }@ic.uff.br
2
Departamento de Cincia da Computao Universidade do Estado de Santa Catarina UDESC
Campus Universitrio Prof. Avelino Marcante s/n - Joinville, SC Brasil
{janine}@joinville.udesc.br
Abstract
Service Selection in service discovery protocols has
an important effect on wireless multi-hop ad hoc networks
(MANETs) performance. This work proposes a service
selection mechanism based on localization to reduce the
redundant replies in these protocols. The mechanism dy-
namically selects the best resource providers during the
reply transmissions. This solution takes into account the
following aspects: geographic position of the requesting
node and of the service providers, nodes speed and the
number of service providers requested. Another issue ad-
dressed in this work is a service discovery mechanismthat
adjusts the search area for each request. This mechanism
consider the requesting node localization, the request re-
sponse time and the maximum nodes speed. Our results
show that both mechanisms make it possible to reduce the
message request and reply overhead from the network.
Keywords: Discovery and Seletion Service, Coopera-
tive Wireless Ad Hoc Networks
Resumo
Seleo de servios em protocolos de descoberta de
servio tem um efeito substancial no desempenho de re-
des ad hoc mveis sem o de mltiplos saltos (MANETs).
Neste artigo proposto um mecanismo de seleo de
Uma verso preliminar deste trabalho foi publicada no SBRC 2009

[10]
servios baseado em localizao para reduzir a dissem-
inao de mensagens de resposta nestes protocolos. O
mecanismo seleciona durante o encaminhamento as re-
spostas dos melhores provedores considerando: a dis-
tncia geogrca entre o requisitante e os provedores do
servio, a velocidade do ns e o nmero de provedores
do servio solicitado. Outra contribuio deste artigo
um mecanismo de descoberta de servios que ajusta uma
rea de busca para cada pedido com base na localizao
onde o servio necessrio, no tempo para atendimento
do pedido e na velocidade mxima dos ns. Os resultados
mostraram que estes mecanismos possibilitam melhorar
o desempenho da rede atravs da reduo das mensagens
de requisio e resposta de servios.
Palavras-chave: Descoberta e Seleo de Servios,
Redes Ad Hoc Mveis Sem Fio Cooperativas
1. INTRODUO
Redes ad hoc mveis sem o (Wireless Mobile Ad
Hoc Network-MANETs) so constitudas por dispositivos
mveis e operam na ausncia de uma infraestrutura xa.
Uma MANET pode ser criada rapidamente e com baixo
custo em reas onde a infraestrutura de comunicao no
existe ou precria. Comparada com as redes xas e in-
fraestruturadas, MANETs tm caractersticas singulares.
A formao da topologia de rede dinmica e indepen-
Janine Kniess, Orlando Loques e Clio V. N.
Albuquerque
Um Protocolo Geogrco para Restringir as
Mensagens de Descoberta e Resposta de
Servios em Redes Mveis Cooperativas
dente, podendo os dispositivos computacionais participar
ou sair da rede a qualquer momento, formando cenrios
de compartilhamento temporrios. Essa perspectiva de
compartilhamento cria formas inovadoras de utilizao
dos dispositivos sem o em vrios mbitos: campos de
batalha, servios de emergncia, e de busca e resgate
ps-desatres naturais, tais como inundaes ou terremo-
tos [15]. Com a demanda de aplicaes para MANETs,
o nmero e a variedade de servios proporcionados por
essas redes esto aumentando continuamente.
Um componente essencial para a usabilidade dessas
redes a descoberta de servios. Em outras palavras,
preciso dotar os dispositivos mveis de meios para lo-
calizar os servios oferecidos por qualquer n da rede,
anunciar seus prprios servios, bem como, selecionar e
invocar o servio mais apropriado. Uma vez localizado o
servio, o usurio poder acess-lo.
A descoberta de servios em MANETs envolve vrios
desaos impostos pela instabilidade da rede (mobilidade
e falhas) e pela escassez de recursos dos dispositivos
mveis, como, por exemplo, memria, processamento,
energia e variabilidade do canal de comunicao (taxa
de dados, atraso, entre outros). Os desaos relaciona-
dos a MANETs so ainda maiores quando se consideram
cenrios com mltiplos saltos.
Em MANETs formadas por grupos de colaborao
temporrios (equipes de resgate), os dispositivos mveis
podem ter uma faixa de transmisso limitada pela tec-
nologia do dispositivo ou por obstculos no caminho, im-
pedindo alguns ns de se comunicarem diretamente com
outros. Nesses cenrios [14], a comunicao pode ocorrer
atravs de mltiplos saltos e cada n da MANET tem a re-
sponsabilidade de atuar como um roteador. Em MANETs
de mltiplos saltos, a disponibilidade de servios e recur-
sos pode apresentar uma alta volubilidade, em compara-
o aos cenrios de redes xas e redes sem o ad hoc de
salto nico.
Uma abordagem comum usada pelos protocolos ex-
istentes para descoberta de servios em MANETs para
encaminhar a mensagem de requisio usar os mecan-
ismos de difuso por broadcast ou por multicast na ca-
mada de aplicao. Assim, atravs de broadcast, as men-
sagens so enviadas para todos os ns da rede, ou, atravs
de multicast, um mecanismo de disseminao seletiva de-
termina que um grupo de ns receba a mensagem. Essa
tcnica comumente empregada porque a localizao
dos provedores de servio no previamente conhecida.
Alm disso, pode facilmente garantir a distribuio das
mensagens para os provedores. Algumas ideias para de-
scoberta de servio propem integrar as funcionalidades
da descoberta de servio com o mecanismo de rotea-
mento das MANETs, a m de minimizar o nmero de
mensagens de descoberta transmitidas. Entretanto, essa
abordagemlimita a interoperabilidade do protocolo de de-
scoberta em relao ao protocolo de roteamento.
Nesse sentido, apesar das vantagens de usar um
mecanismo por difuso, como independncia quanto as
informaes de roteamento e distribuio da mensagem
de requisio para o maior nmero de provedores aptos
possveis, o resultado de uma requisio para um servio
pode conter informaes de vrios provedores do mesmo
servio. Neste contexto, o ideal que o(s) melhor(es)
provedor(es) seja(m) selecionado(s), sem que haja a ne-
cessidade de interferncia do usurio.
Muitos esforos foram concentrados na rea de de-
scoberta de servio. Entretanto, poucos protocolos con-
sideram o desenvolvimento de mecanismos de descoberta
comseleo de servios. Seleo de servios pode ser cat-
egorizada em seleo automtica ou seleo assistida pelo
usurio. Na seleo automtica, o mecanismo escolhe au-
tomaticamente um ou mais servio(s) entre os que aten-
dem consulta. Na seleo assistida pelo usurio, ou
manual, o mecanismo retorna ao cliente a lista dos prove-
dores que atendem consulta, e o prprio cliente quem
deve realizar a seleo do mais adequado. A seleo de
servios apresenta-se como um aspecto importante no de-
senvolvimento de um protocolo de descoberta de servios
em ambientes dinmicos, como das MANETs com mlti-
plos saltos.
Para atender essa demanda, neste artigo proposto e
avaliado um protocolo de descoberta de servios baseado
em localizao, denominado Location Aware Discovery
Service (LADP). O protocolo LADP integra um mecan-
ismo de seleo de servios, automtico, distribudo e
ciente de localizao (Location Aware Service Selection
- LASS) com o objetivo de reduzir as mensagens de re-
spostas em protocolos de descoberta para MANETs.
O cenrio alvo deste trabalho considera o uso de
MANETs auxiliando equipes na busca e resgate em reas
vtimas de desastres naturais. Neste cenrio identicou-
se que alguns aspectos so essenciais para o sucesso do
atendimento, tais como: localizao geogrca onde um
servios solicitado; o tempo limite especicado para
atendimento deste pedido (assume-se que o provedor tem
que chegar no local do pedido dentro de um tempo mx-
imo prdeterminado); a velocidade de deslocamento do
n provedor do servio at o local onde o servio re-
querido; e o nmero de provedores de servios que devem
ser disponibilizados.
O mecanismo LASS leva em conta os aspectos cita-
dos para eliminar respostas excedentes da rede. Ao re-
ceber uma resposta, o n verica se a quantidade de re-
spostas j tratadas por ele, associada a mesma requisio
de servios maior que o nmero de provedores dese-
jados. Alm do nmero de provedores, o n compara o
tempo de deslocamento do provedor da ltima resposta
anteriormente armazenada. Se um valor menor for obtido
o n encaminha a resposta.
24
Albuquerque
Outra contribuio deste artigo o mecanismo de
descoberta de servios ciente de localizao (Location
Aware Discovery Service - LADS). O mecanismo ajusta
uma rea de busca independente para cada pedido com
base na localizao de onde o servio solicitado, no
tempo mximo para atendimento de uma requisio e na
velocidade mxima dos ns. Este esquema pode auxiliar
o mecanismo de seleo de servios, LASS, na reduo
de mensagens da rede, uma vez que somente os ns aptos,
isto , aqueles que tm velocidade suciente para chegar
ao local onde o servio est sendo solicitado em tempo
hbil enviam resposta.
Este artigo, alm da introduo est organizado da
seguinte forma. A Seo 2 apresenta o cenrio de moti-
vao e as principais propostas em descoberta de servios
existentes para MANETs. A Seo 3 introduz os mecan-
ismos: Location Aware Discovery Service (LADS) e Lo-
cation Aware Service Selection (LASS). A Seo 4 de-
screve a avaliao e os resultados. A Seo 5 apresenta as
concluses nais do trabalho.
2. MOTIVAO
Esta seo apresenta um cenrio de aplicao alvo
dos mecanismos propostos neste artigo. Com base neste
cenrio, os desaos da pesquisa sero discutidos. Uma
viso geral dos trabalhos relacionados ser apresentada
em seguida.
2.1. CENRIO ALVO DE APLICAO
O terremoto que ocorreu na China em maio de 2008
usado neste trabalho como um exemplo de cenrio de
aplicao. Um grande terremoto medindo 8.0 na escala
Richter teve seu epicentro em Wenchuan, na provncia de
Sichuan, China. Wenchuan tem uma rea de 4084 km
2
e
uma populao de 106,119 habitantes. As estradas que
conduzem ao local do epicentro foram bloqueadas por
rochas que desabaram e a comunicao foi perdida. Mil-
hares de toneladas de produtos qumicos foram expostas
e houve vazamento de material radioativo [2].
Nesse cenrio, tanto o acesso s reas isoladas, quanto
a identicao de sobreviventes, e de eventos(focos de in-
cndio, vazamento de gs, etc.) bastante difcil. Equipes
especializadas em salvamento e resgate encontram-se dis-
tribudas na rea afetada. Neste contexto, conjectura-se
que as equipes de resgate (formadas por humanos, vecu-
los ou mesmo robs) interconectadas por uma rede ad hoc
mvel sem o, poderia contribuir de forma signicativa
na identicao de eventos, bem como para o resgate de
sobreviventes.
Cada elemento mvel da equipe de resgate (denomi-
nado aqui de n da rede), transporta um dispositivo para
comunicao e pode atuar como um provedor ou requi-
sitante de servios, ou somente como participante da co-
municao. Os provedores so os ns que disponibilizam
recursos e os requisitantes os que solicitam servios. Um
recurso pode ser um carro do Corpo de Bombeiros, uma
ambulncia, um rob com a habilidade de alcanar reas
inacessveis para um humano, ou um paramdico trans-
portando um medicamento, entre outros. Os mecanismos
propostos neste artigo focam em descoberta de servio
neste tipo de cenrio.
2.2. DESAFIOS
No cenrio alvo, os ns da rede conhecem sua posio
geogrca atravs de um sistema de localizao semel-
hana de um GPS e e assume-se que os ns possuem rel-
gios sincronizados.
Admitindo-se que no local da calamidade exista um
sensor coletando informaes do ambiente, os dados obti-
dos a partir da identicao de um fenmeno, por ex-
emplo, o vazamento de algum tipo de gs, sero trans-
formados em uma descrio do evento observado. Em
seguida, partindo de algoritmos especializados, o sensor
deduz que necessrio um provedor capaz de atuar em
poucos minutos naquela rea. Aps a identicao do re-
curso necessrio, o sensor envia para a rede a mensagem
de requisio, buscando o recurso necessrio. Um req-
uisitante pode solicitar na mensagem de descoberta um
ou mais provedores para o atendimento do pedido e es-
pecicar o tempo mximo para o atendimento da requi-
sio. No cenrio alvo, o tempo de atendimento, ou seja,
o tempo que os provedores levam para chegar ao local do
evento, essencial para o sucesso do atendimento.
Adescoberta de servio nesse contexto envolve alguns
desaos. O primeiro garantir a transmisso e a recepo
da informao de descoberta, considerando a imprevisi-
bilidade da topologia da rede. O segundo desao lidar
com o desconhecimento mtuo dos ns quanto sua lo-
calizao. E o terceiro desao que somente os ns ca-
pazes de se deslocar ao local onde o recurso necessrio,
dentro de um tempo limite, sero teis no processo de de-
scoberta, enviando a resposta para o requisitante.
2.3. TRABALHOS RELACIONADOS
Diversos trabalhos na literatura tratam do problema
da descoberta de servios. Cronologicamente, podem ser
citados os protocolos para redes xas, Jini [8], Saluta-
tion [19] e SLP [6], outros como, Bluetooth SDP [16] e o
DEAPspace [17] para redes sem o ad hoc de salto nico.
Essas solues no so viveis para ambientes de larga
escala e descentralizados, como por exemplo, o cenrio
apresentado na Seo 2, nos quais, existe a possibilidade
de formao de redes ad hoc de saltos mltiplos.
Nesta ltima classe, destacam-se os protocolos GSD
(Group-based Service Discovery) [3], Allia (Alliance)
[18], Konark Gossip [7], ORION (Optimized Routing In-
25
Albuquerque
dependent Overlay Network) [9], o protocolo FTA (Field
Theoretic Approach) [11], o protocolo P2PDP [13] e as
abordagens cross-layer, de Varshavsky et al. [2005] [21],
de Lamont et al. [2005] Lightweight Service Discovery
[12] e de Athanaileas et al. [2007] [1].
Uma estratgia geralmente no considerada na maio-
ria das abordagens para descoberta de servios a seleo
automtica de servios. Um mecanismo eciente de se-
leo de servios pode exercer um importante papel no
desempenho da rede, pois possibilita que as melhores re-
spostas sejam ltradas entre todas possveis antes destas
alcanarem o n requisitante.
Dentre as abordagens para MANETs de mltiplos
saltos mencionadas, somente os protocolos oferecidos
por: [1], [11], [13] e [21], disponibilizam um mecanismo
para seleo automtica de servios. A abordagem FTA
baseia-se na teoria de campos eletrostticos. As requi-
sies para uma instncia de um dado tipo de servio so
encaminhadas seletivamente na direo do provedor que
gerou o maior gradiente de campo, de forma similar ao
roteamento de mensagens anycast. Contudo, essa abor-
dagem no escala bem quando so disponibilizados difer-
entes tipos de servios. Esta limitao resultado do fato
que os provedores necessitam trocar periodicamente men-
sagens de atualizao do valor da capacidade do servio
por meio de um mecanismo de inundao. Cada tipo de
servio tem uma capacidade especca. Outra limitao
dessa proposta que apenas uma resposta para o servio
requisitado enviada ao n que emitiu o pedido. Em [1]
e [21], a funo de seleo de servios integrada ao
mecanismo de roteamento em uma abordagem denom-
inada de cross-layer. Em [21], o critrio de seleo
a menor distncia em nmero de saltos entre o requisi-
tante e provedor, e a seleo ocorre somente quando as
respostas chegam ao n que originou a requisio. O
protoloco descrito por [1] realiza a seleo de servios
atravs de duas mtricas: distncia em nmero de saltos e
a energia residual dos ns. Neste protocolo o requisitante
tambm recebe uma nica resposta.
O trabalho proposto por [13] o que mais se
assemelha com a proposta deste artigo. Em Lima et al.
[2007] apresentado o mecanismo SbV (Suppresion by
Vicinity) que permite suprimir automaticamente durante
o encaminhamento as respostas excedentes. Entretanto,
esse mecanismo no considera aspectos que so essen-
ciais para o cenrio de motivao apresentado na Seo
2, como por exemplo, a velocidade de deslocamento dos
ns, o tempo mximo para deslocamento do provedor ao
local onde o recurso necessrio e a localizao geogr-
ca entre requisitantes e provedores. Outro aspecto que
diferencia a abordagem proposta neste artigo com o SbV,
que no SbV as respostas so encaminhadas at o dis-
positivo requisitante por broadcast salto a salto no nvel
da aplicao. No esquema de broadcast salto a salto, to-
dos os vizinhos do dispositivo respondente escutam sua
resposta. Essa resposta, porm, s pode ser retransmi-
tida, tambmpor broadcast pelos dispositivos ao longo do
caminho reverso percorrido pela requisio. Os demais
dispositivos, descartam a resposta. Em MANETs envol-
vendo topologias altamente dinmicas, a rpida mudana
da topologia de rede e a presena de falhas de hardware
ou software, pode inviabilizar a aplicabilidade desse con-
ceito. No LASS o encaminhamento das respostas ca a
cargo do protocolo de roteamento, contudo, o mecanismo
no guarda informaes sobre os ns que participaram do
processo de descoberta (por onde a mensagem passou)
para ltrar as respostas.
3. PROTOCOLO PARA DESCOBERTA DE
SERVIOS BASEADO EM LOCALIZAO
Nesta seo, apresentam-se os mecanismos para de-
scoberta e seleo de servios propostos no LADP. O
primeiro um mecanismo que atua na fase de descoberta
de servios, denominado Location Aware Discovery Ser-
vice (LADS). O segundo, um mecanismo de seleo de
servios automtico e distribudo, denominado Location
Aware Service Selection (LASS), que escolhe, de forma
seletiva, as melhores respostas e descarta as excedentes
durante o seu encaminhamento pela rede.
3.1. Location Aware Discovery Service (LADS)
Esta seo descreve a estratgia adotada pelo mecan-
ismo de descoberta de servios LADS para limitar o es-
copo da busca para cada pedido individualmente e para
reduzir o nmero de mensagens de descoberta.
Seja S o conjunto de ns pertencentes rede, o mecan-
ismo de descoberta Location Aware Discovery Service
(LADS) dimensiona o raio de busca R
i
, com base na ve-
locidade mxima, v
max
(parmetro com valor conhecido
para cada tipo de provedor de recurso), que um n pode
atingir e no tempo mximo para atendimento da requi-
sio, t
max
. LADS compe um subconjunto S
S para
cada requisio de descoberta enviada por umrequisitante
i S
diante da necessidade de promover uma descoberta

de servios para outros ns na rede. O raio R dado pela
equao:
R
i
= v
max
t
max
. (1)
O mecanismo dene o raio de busca com base em v
max
para que o raio inclua o maior nmero de provedores ap-
tos possveis. A mensagem somente ir trafegar pela rea
limitada por R
i
. Dado o par (i,j), sendo i S
o n requisi-
tante, e j S
o n provedor, assumiu-se que a velocidade

de deslocamento dos ns provedores conhecida. O Al-
goritmo 1 descreve este mecanismo.
26
Albuquerque
Algoritmo 1 Descoberta de servios (LADS) n j
1: ProcessDiscovery(i, coord
X
, coord
Y
, t
max
, s)
2: j recebe mensagem (msg) ServDisc() do n i, requisi-
tando o servio s
3: if d
ij
> R then
4: Discard(msg)
5: else if d
ij
/v
j
<= t
max
then
6: if FindResource(s) then
7: if not (busy) then
8: Send ServResponse()
9: end if
10: end if
11: end if
Na mensagem de descoberta ServDisc(), o n requisi-
tante envia as seguintes informaes: uma identicao
do n; sua coordenada geogrca, coord
X
, coord
Y
; o
tempo mximo para atendimento da requisio, t
max
; o
servio procurado, s; e o nmero de provedores desejado.
LADS prov um mecanismo de descoberta reativo. Os
ns atendem aos pedidos sob demanda.
Por exemplo, na Figura 1, caso o n i identique a
necessidade de um recurso, envia uma mensagem de de-
scoberta de servio(1) para a rede. Os ns vizinhos de i
recebem a mensagem e a reencaminham sucessivamente,
porm, somente os ns aptos respondem. Neste cenrio,
supondo que o n j receba a requisio(2) do n i, o algo-
ritmo LADS vericar a distncia euclidiana
1
(d
ij
) entre
os dois ns. Se d
ij
> R, a requisio descartada por j,
admitindo-se que esse n esteja fora do raio de interesse.
Caso contrrio, se d
ij
R, o algoritmo verica se o n
j tem velocidade de deslocamento suciente para chegar
ao local do evento dentro do tempo limite, se possui o
recurso procurado e se o n est disponvel no momento.
A equao 2 garante que somente os ns com veloci-
dade de deslocamento suciente para atender o pedido
dentro do tempo mximo respondam requisio envi-
ada por i. Se a restrio dada por 2 for satisfeita, o n j
envia uma mensagem de resposta(4), para o n i.
d
ij
/v
j
<= t
max
. (2)
Admite-se que os ns da rede tm velocidade mxima
de deslocamento conhecida. Se j tem o recurso, mas v
j
insuciente, j no envia resposta para i, e apenas en-
caminha a mensagem de requisio para seus vizinhos na
rede. Esse mecanismo evita transmisses de mensagens
de resposta desnecessrias na rede.
1
O uso da distncia euclidiana uma simplicao do clculo da tra-
jetria. O desenvolvimento de um modelo mais apurado que inclui, por
exemplo, obstculos no caminho est em andamento.
Figura 1. Funcionamento do protocolo.
3.2. Location Aware Selection Service (LASS)
Como resultado do processo de descoberta, mltiplos
provedores podem responder a uma requisio de servio.
O mecanismo LASS usa a informao de localizao dos
ns, o nmero de provedores solicitado pelo requisitante
e a velocidade de deslocamento do ns para selecionar e
descartar as respostas.
Por exemplo, na Figura 1, quando o n k(n inter-
medirio), recebe a resposta(5) do n m para uma dada
requisio, verica se j encaminhou o nmero mximo
de respostas (n
provedores
) solicitado pelo requisitante. Se
o nmero mximo foi alcanado, o n k descarta essa re-
sposta. Caso contrrio, o n k compara o tempo de deslo-
camento do n m com o tempo de deslocamento da l-
tima resposta encaminhada para aquela requisio, por
exemplo, do n j(4). O n k tem as respostas de j ar-
mazenadas. Se (d
im
/v
m
)(d
ij
/v
j
), a resposta encamin-
hada para o n requisitante i(6). Essa restrio possibilita
que o mecanismo LASS reduza o nmero de mensagens
de resposta que trafegam na rede. Os resultados apresen-
tados na Seo 4, demonstram que a taxa de sucesso de
descoberta de servio no foi afetada negativamente pelo
mecanismo de seleo de servios.
O mecanismo de seleo de servios apresentado no
Algoritmo 2. Na mensagem de resposta, ServResponse(),
o provedor envia sua coordenada geogrca e sua veloci-
dade de deslocamento. Se as restries dadas nas lin-
has 6 e 7 do Algoritmo 2 forem atendidas, o n recep-
tor reencaminha a mensagem de resposta para seus vizin-
hos. Quanto ao encaminhamento das respostas pelos ns
receptores, vale ressaltar, que as respostas repetidas (j
tratadas para um determinado provedor) so descartadas.
O mecanismo LASS pode ser usado de forma in-
dependente do mecanismo LADS em protocolos de de-
scoberta de servios para MANETs. Por exemplo, o
27
Albuquerque
Algoritmo 2 Seleo de servios (LASS) n k
1: ProcessResponse(m, coord
X
, coord
Y
, v
j
,
max
provedores
)
2: k recebe mensagem (msg) ServResponse do n m
3: k armazenou ltima resposta do n j
4: if n
provedores
>= max
provedores
then
5: Discard(msg)
6: else if d
im
/v
m
<= d
ij
/v
j
then
7: n
provedores
= n
provedores
+1
8: Forward (msg)
9: else
10: Discard(msg)
11: end if
mecanismo de seleo poderia atuar sobre um protocolo
de descoberta por difuso do tipo broadcast ou multi-
cast. Nenhuma informao adicional seria necessria.
Para garantir que somente os ns aptos respondam req-
uisio, cada n, antes de enviar uma resposta, deve ver-
icar se tem velocidade de deslocamento suciente para
atender ao pedido. A nica restrio que os ns requisi-
tantes e provedores devem estar cientes de suas localiza-
es geogrcas.
4. RESULTADOS
Para avaliar o protocolo proposto, realizaram-se ex-
perimentos computacionais com o simulador de redes
Network Simulator(NS-2) [20]. A meta dessa avaliao
validar a eccia do mecanismo de seleo de servios na
reduo do nmero de mensagens de resposta sem preju-
dicar o processo de descoberta. Neste sentido, o mecan-
ismo ser avaliado em diferentes cenrios, incluindo
diferentes velocidades e tempo mximo de atendimento.
Quanto ao desempenho, foram comparados os mecanis-
mos de descoberta com seleo, sem seleo, e os de in-
undao tradicional.
4.1. AMBIENTE DE SIMULAO
Para ns de simulao, mapeou-se o cenrio apresen-
tado na Seo 2 para uma rea de 25km
2
considerando
que uma dada equipe de resgate atuar em uma regio
afetada por um terremoto. Nesse conjunto de experimen-
tos no foi considerada a presena de obstculos no cam-
inho. No cenrio de simulao, a velocidade dos ns
pode variar de 2,0 m/s (uma pessoa caminhando) at 15,0
m/s (um veculo com velocidade moderada) e usou-se o
modelo de mobilidade Gauss-Markov [5]. Este modelo
elimina mudanas bruscas de direo e paradas abruptas
dos modelos randmicos possibilitando uma maior aprox-
imao do movimento real dos usurios. A Tabela 1 ap-
resenta os parmetros de rede simulados.
Tabela 1. Parmetros do Sistema.
Parmetro Valor
Terreno 5000m x 5000m
Nmero de ns 50, 100, 150, 200, 250
Tempo de Simulao 300s
Alcance da antena 250m
Tamanho do pacote 120 bytes
Velocidade dos ns 7,2 km/h > 2,0 m/s
18,0km/h > 5,0 m/s
36,0km/h > 10,0 m/s
54,0km/h > 15,0 m/s
Cada n disponibiliza no mximo um recurso.
Realizou-se uma distribuio aleatria de recursos entre
os ns, ou seja, foram realizados testes em que foram
atribudos recursos para 1%, 5%, 10%, 15%, 20% e 30%
dos ns da rede. Assume-se que cada n conhece sua lo-
calizao corrente.
Nas simulaes realizadas, usou-se o protocolo de
roteamento OLSR (Optimized Link State Routing)[4]
como protocolo de roteamento de mltiplos saltos sobre
o protocolo da camada MAC IEEE 802.11. OLSR uma
otimizao do clssico algoritmo de estado de enlace. O
conceito chave deste protocolo o uso de multipoint re-
lays (MPRs)[4], que so os nicos ns que encaminham
as mensagens. Os demais ns apenas recebem tais men-
sagens, mas no as retransmitem. Os MPRs so sele-
cionados de forma que todos os ns que estiverem a dois
saltos do emissor possam ser alcanados. Essa tcnica re-
duz de maneira substancial a sobrecarga de mensagens,
quando comparada a um mecanismo de inundao tradi-
cional. Essa caracterstica a torna particularmente apro-
priada para a rede representada pelo cenrio proposto
neste trabalho.
4.2. MTRICAS
Foram analisadas as mtricas: taxa mdia de de-
scoberta (SD), qualidade das respostas (TQoS) e sobre-
carga das mensagens do protocolo de descoberta na rede
(NMD). Denio das mtricas: (1) SD = Nmero de re-
spostas recebidas/ Nmero de requisies enviadas; (2)
TQoS = Tempo mdio de atendimento/Nmero total de
respostas recebidas; e (3) NMD =Nmero de mensagens
de descoberta de servios transmitidas/Nmero total de
mensagens transmitidas.
Para manter a integridade dos experimentos,
adotaram-se os mesmos parmetros em todos os
cenrios. Nos experimentos realizados, cada n faz 290
pedidos durante 300s de simulao. O nmero mnimo
de provedores (nmero de recursos desejado) que deve
ser entregue foi estipulado em 1(um). Todos os ns
28
Albuquerque
da rede so mveis, incluindo o que realiza consultas.
O que diferencia os cenrios o tempo mximo para
atendimento do pedido (que varia em 1,5 e 5,5 minutos),
o percentual de recursos dos ns e o nmero de ns na
rede. O intervalo de conana apresentado nos resultados
de 95%.
4.3. ANLISE DE RESULTADOS
Os experimentos representados pelas Figuras 2 e 3 ap-
resentam a taxa mdia de descoberta (nmero mdio de
respostas) (SD) obtida pela comparao dos mecanismos
de descoberta com seleo, descoberta sem seleo e in-
undao. A mtrica SD dene se o requisitante encontrou
ou no o recurso. Para este experimento, deniu-se que
10% dos ns da rede tm o recurso procurado. O nmero
de ns na rede varia de 50 a 250 ns e o tempo de atendi-
mento de 5,5 minutos. Na Figura 2, a velocidade de
deslocamento dos ns de 2,0 m/s e, na Figura 3, a ve-
locidade de deslocamento de 15,0 m/s.
Os resultados mostraram que a taxa mdia de de-
scoberta de 100% (para cada pedido enviado, pelo
menos uma (1) resposta foi recebida) para todas as quan-
tidades de ns na rede e para ambas as velocidades
com o mecanismo LASS. Para ambas as velocidades, os
cenrios de rede mais densos apresentaram uma taxa de
descoberta maior. Por exemplo, usando o mecanismo de
descoberta sem seleo, com 50 ns e velocidade de 2,0
m/s, a taxa mdia de descoberta foi de 1,38 para 1,76 com
250 ns e com a mesma velocidade. O mesmo compor-
tamento pode ser observado no cenrio da Figura 3, onde
a velocidade de deslocamento de 15,0 m/s. Nesse ex-
perimento, com 50 ns, a taxa mdia de descoberta foi de
1,45 para 2,10 em um cenrio com 250 ns. A taxa m-
dia de descoberta foi melhor para todos os casos com o
mecanismo de inundao, porm todos os ns que tm o
recurso respondem, inclusive os que no atendem ao per-
l da requisio.
Na Figura 4, apresenta-se uma anlise da taxa mdia
de descoberta (SD) pela variao do percentual de recur-
sos dos ns. O nmero de ns na rede de 150 e o per-
centual de recursos varia em 1%, 5%, 10%, 15%, 20% e
30%. A velocidade mxima de deslocamento dos ns
de 15,0 m/s e o tempo de atendimento de 5,5 minutos.
Para esse experimento, o mecanismo de descoberta
com seleo, quando comparado ao mecanismo de in-
undao, possibilitou reduzir a taxa mdia de respostas
excedentes de 3,74 para 1,12, quando o percentual de re-
cursos de 10%. Outra concluso que pode ser obtida
com esse experimento, que o mecanismo LASS reduz o
nmero de respostas a medida que o percentual de recur-
sos aumenta.
Na Figura 5, mostrado o efeito da mobilidade dos
ns sobre a taxa mdia de descoberta (SD). Para esse ex-
perimento, deniu-se que 10% dos ns da rede tm o re-
curso procurado. A velocidade de deslocamento dos ns
varia de 2,0 m/s para 15,0 m/s. Foram usados 200 ns e
o tempo de atendimento de 1,5 e 5,5 minutos.
Os resultados apresentados mostram que pelo menos
uma resposta foi recebida em todos os cenrios, exceto
para os cenrios onde o tempo de atendimento de 1,5
minutos e a velocidade de deslocamento dos ns de 2,0
m/s e 5,0 m/s. No experimento com tempo de atendi-
mento de 1,5 minuto e velocidade de 2,0 m/s, a taxa de
sucesso de descoberta foi de 0,91. Com velocidade de
deslocamento de 5,0 m/s, a taxa mdia de descoberta foi
de 0,93. Esse resultado justica-se pelo fato de o mecan-
ismo LADS limitar a rea de busca com base na veloci-
dade mxima dos ns. Para esses casos, quando os ns
tm velocidade de 2,0 m/s, a rea de busca de 180 met-
ros e, quando tem velocidade de 5,0 m/s, a rea de 450
metros. Dentro desse raio, no foi encontrado um prove-
dor apto para atender ao pedido dentro do tempo limite.
Conclui-se que alguns fatores, como a velocidade de
deslocamento e o raio R, inuenciaramos resultados neste
ltimo cenrio. Quanto mais baixos o tempo de atendi-
mento e a velocidade, menor ser a probabilidade de
um n encontrar novos vizinhos que disponibilizem o re-
curso, salvo em alguns casos especcos em que haja uma
concentrao de ns em uma regio.
Na Figura 6 avalia-se a qualidade das respostas perce-
bidas pelo n requisitante, ou seja, o tempo mdio de
atendimento (TQoS) em funo do nmero de ns na
rede. O tempo de atendimento dado pela frmula,
dij/vj. Neste cenrio, o tempo de atendimento de 5,5
minutos, a velocidade dos ns de 15,0 m/s, o percentual
de recursos de 10% e o nmero de ns na rede varia
entre 50 e 250 ns. Os resultados mostram que a quali-
dade das respostas recebidas pelo n requisitante aumen-
tou com o uso do mecanismo LASS para todas as quanti-
dades de ns, quando comparada com os outros mecanis-
mos investigados. Isso porque o mecanismo LASS sele-
ciona, durante a fase de transmisso de respostas, os mel-
hores provedores e descarta aquelas com o maior tempo
de atendimento.
O uso da tcnica de inundao no adiciona vantagem
ao cenrio simulado, considerando a mtrica TQoS. Alm
de aumentar o nmero de transmisses de respostas na
rede, distribui mensagens de ns que no esto aptos
para atender ao pedido. J o mecanismo de descoberta
sem seleo possibilita que somente os provedores dentro
do raio R enviem a mensagem de resposta. Entretanto,
nesse caso, todas as possveis respostas sero transmi-
tidas, provocando uma diminuio na qualidade das re-
spostas. Outro aspecto observado neste experimento
que, medida que o nmero de ns cresce, aumenta o
tempo de atendimento. Esse comportamento justica-se
porque nos cenrios mais densos um nmero maior de re-
spostas gerado.
29
Albuquerque
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
5.5
6
6.5
7
7.5
8
50 100 150 200 250
T
a
x
a

M
d
i
a

d
e

D
e
s
c
o
b
e
r
t
a
Nmero de Ns
Velocidade dos Ns (2m/s)
Descoberta com Seleo
Descoberta sem Seleo
Inundao
Figura 2. Anlise da taxa mdia de descoberta, em funo do nmero total de ns na rede para um cenrio com velocidade mxima de 2,0 m/s.
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
5.5
6
6.5
7
7.5
8
50 100 150 200 250
T
a
x
a

M
d
i
a

d
e

D
e
s
c
o
b
e
r
t
a
Nmero de Ns
Velocidade dos Ns (15m/s)
Inundao
Figura 3. Anlise da taxa mdia de descoberta, em funo do nmero total de ns na rede para um cenrio com velocidade mxima de 15,0 m/s.
Alm disso, no mecanismo LASS o envio de respostas
para o n requisitante ca a cargo o protocolo de rotea-
mento e, em alguns casos, o n requisitante pode receber
por algum caminho um nmero de respostas maior que o
limite mximo estipulado.
Os resultados da Figura 7 mostram o efeito da mo-
bilidade dos ns versus tempo mdio de atendimento
(TQoS). A rede tem 200 ns, o tempo de atendimento
de 5,5 minutos, o percentual de recursos de 10% e
a velocidade de deslocamento varia de 2,0 m/s at 15,0
m/s.
Nesse experimento, constatou-se que, para todas as
velocidades, o mecanismo de descoberta com seleo de
servios possibilitou uma melhora signicativa na qual-
idade das respostas recebida pelo requisitante. Esse re-
sultado demonstra a efetividade do mecanismo LASS na
reduo de respostas dos ns menos aptos da rede antes
de alcanarem o n requisitante. Atravs desse experi-
mento tambm constatou-se que, medida que a veloci-
dade dos ns aumenta, o tempo mdio de atendimento
cresce. Esse comportamento se deve ao fato de o tamanho
do raio estar relacionado com a velocidade de desloca-
mento. As maiores velocidades de deslocamento resul-
tam em um raio maior e, consequentemente, um nmero
maior de respostas ser obtido.
O grco da Figura 8 ilustra o efeito da mobilidade
dos ns em relao sobrecarga (NMD) de mensagens da
rede com seleo de servios e com inundao. Para esse
30
Albuquerque
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
5.5
6
6.5
7
7.5
8
1 5 10 15 20 30
T
a
x
a

M
d
i
a

d
e

D
e
s
c
o
b
e
r
t
a
Percentual de Recursos
Nmero de Ns (150)
Inundao
Figura 4. Anlise da taxa mdia de descoberta, em funo do percentual de recursos para um cenrio com velocidade mxima de 15,0 m/s.
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
2 5 10 15
T
a
x
a

M
d
i
a

d
e

D
e
s
c
o
b
e
r
t
a
Velocidade dos Ns (m/s)
Nmero de ns (200)
Descoberta com Seleo 1.5 min
Descoberta com Seleo 5.5 min
Inundao
Figura 5. Anlise da taxa mdia de descoberta, em funo da mobilidade dos ns para um cenrio com 200 ns.
experimento, considera-se que 30% dos ns tm o recurso
procurado, a velocidade de deslocamento varia de 2,0 m/s
at 15,0 m/s, o tempo de atendimento de 1,5 minutos e
5,5 minutos e o nmero de ns na rede de 250.
Os resultados mostraram que, para todas as veloci-
dades e tempo de atendimento, o mecanismo de de-
scoberta com seleo de servios possibilitou uma re-
duo signicativa no nmero de mensagens em relao
ao mecanismo de inundao. Por exemplo, com uma ve-
locidade de 10,0 m/s e com o tempo de atendimento de
5,5 minutos, foi obtido um desvio percentual de 10% na
reduo das mensagens.
5. CONCLUSES
Neste artigo, apresentou-se o protocolo de descoberta
de servio baseado em localizao (LADP). O protocolo
LADP composto por dois mecanismos: um mecanismo
para descoberta de servios, LADS, e ummecanismo para
seleo automtica e distribuda de servios, LASS. O
mecanismo LADS reduz o escopo da inundao das men-
sagens de descoberta, uma vez que s enviam mensagens
os ns aptos, aqueles que tmvelocidade de deslocamento
suciente para chegar em tempo hbil ao local onde o
servio est sendo solicitado, e o mecanismo LASS re-
duz de forma signicativa as mensagens de respostas sem
prejuzo do processo de descoberta, mesmo nas redes com
31
Albuquerque
0
20
40
60
80
100
120
140
160
180
200
220
240
260
280
300
320
340
360
380
50 100 150 200 250
T
e
m
p
o

M
d
i
o

d
e

A
t
e
n
d
i
m
e
n
t
o

(
s
)
Nmero de Ns
Velocidade dos ns 15 m/s
Tempo de Atendimento com seleo 5.5 min
Tempo de Atendimento sem Seleo 5.5 min
Inundao
Figura 6. Anlise do tempo mdio de atendimento em funo do nmero de ns na rede para um cenrio com velocidade mxima de 15,0 m/s.
0
20
40
60
80
100
120
140
160
180
200
220
240
260
280
300
320
340
360
380
2 5 10 15
T
e
m
p
o

d
e

A
t
e
n
d
i
m
e
n
t
o

(
s
)
Nmero de Ns (200)
Tempo de Atendimento com Seleo 5.5 min
Tempo de Atendimento sem Seleo 5.5 min
Inundao
Figura 7. Anlise do tempo mdio de atendimento em funo da velocidade dos ns para um cenrio com 200 ns.
alta mobilidade dos ns.
Com base na anlise dos resultados, comprovou-se
que o uso dos dois mecanismos, LADS e LASS, possi-
bilitou uma reduo na sobrecarga de mensagens da rede,
quando comparados com um mecanismo que encaminha
as mensagens por difuso, mais especicamente, atravs
de inundao. O mecanismo LASS melhorou o desem-
penho da rede por meio da supresso de respostas exce-
dentes sem comprometer o processo de descoberta.
Os resultados obtidos tambm mostraram que o per-
centual de reduo de respostas variou conforme o au-
mento da velocidade de deslocamento e o nmero de
ns. Justica-se esse comportamento pelo aumento do
nmero de mensagens que trafegam na rede dos cenrios
com maior velocidade e nas redes mais densas, devido
s frequentes mudanas da topologia da rede e da troca
de mensagens. Alm de melhorar o desempenho da rede,
o mecanismo LASS tambm contribuiu para aumentar a
qualidade das respostas recebidas pelo usurio da apli-
cao.
Por m, conclui-se que os dois mecanismos podemser
usados de forma independente, desde que os ns prove-
dores e requisitantes sejam cientes das suas localizaes
geogrcas, e as informem nas mensagens de resposta e
de descoberta.
32
Albuquerque
0
4
8
12
16
20
2 5 10 15
S
o
b
r
e
c
a
r
g
a

d
e

M
e
n
s
a
g
e
n
s

(
%
)
Percentual de Recursos (30%)
Sobrecarga com Seleo 1.5 min
Sobrecarga com Seleo 5.5 min
Inundao
Figura 8. Anlise da sobrecarga de mensagens da rede em funo da mobilidade dos ns para um cenrio com 250 ns.
Referncias
[1] S.E. Athanaileas, C.N. Ververidis, and G.C. Poly-
zos. Optimized service selection for manets us-
ing an aodv-based service discovery protocol. In
thAnnual Mediterranean Ad Hoc Networking Work-
shop (MEDHOCNET 2006), Corfu, Greece, June,
2007.
[2] D. Barboza. One week later, a nation pauses to share
its mourning and grief. The New York Times, May,
2008.
[3] D. Chakraborty, A. Joshi, Y. Yesha, and T. Finin.
Toward Distributed Service Discovery in Pervasive
Computing Environments. IEEE TRANSACTIONS
ON MOBILE COMPUTING, pages 97112, 2006.
[4] T. Clausen and P. Jacquet. RFC3626: Optimized
Link State Routing Protocol (OLSR). RFC Editor
United States, 2003.
[5] C. de Waal and M. Gerharz. Bonnmotion: A
mobility scenario generation and analysis tool.
Communication Systems group, Institute of Com-
puter Science IV, University of Bonn, Ger-
many. Website: http://web. informatik. uni-bonn.
de/IV/Mitarbeiter/dewaal/BonnMotion, 2003.
[6] E. Guttman. Service location protocol: Automatic
discovery of IP network services. 3(4):7180, 1999.
[7] S. Helal, N. Desai, and V. Verma. Konark-a ser-
vice discovery and delivery protocol for ad-hoc net-
works. Wireless Communications and Networking,
2003. WCNC 2003. 2003 IEEE, 3, 2003.
[8] S.M. Inc. Jini Architectural Overview. Technical
White Paper,January, 1999.
[9] A. Klemm, C. Lindemann, and OP Waldhorst. A
special-purpose peer-to-peer le sharing system for
mobile ad hoc networks. In Vehicular Technology
Conference, 2003. VTC 2003-Fall. 2003 IEEE 58th,
volume 4, 2003.
[10] J. Kniess, O. Loques, and C. V.N. Albuquerque. Um
protocolo baseado em localizao para restringir as
mensagens de descoberta e resposta de servios em
redes ad hoc mveis com ns cooperativos. Proc. of
the XXIX Brazilian Symposium on Computer Net-
works (SBRC 2009),Recife, 2009.
[11] V. Lenders, M. May, and B. Plattner. Service dis-
covery in mobile ad hoc networks: A eld theo-
retic approach. Pervasive and Mobile Computing,
1(3):343370, 2005.
[12] L. Li and L. Lamont. A lightweight service dis-
covery mechanism for mobile ad hoc pervasive en-
vironment using cross-layer design. In Pervasive
Computing and Communications Workshops, 2005.
PerCom 2005 Workshops. Third IEEE International
Conference on, pages 5559, 2005.
[13] dos S. L. Lima, T. A. G. Azevedo, A. Ziviani,
M. Endler, L. G. S. Fernando, and B. S. Bastos. Re-
duzindo a imploso de respostas em protocolos de
descoberta de servios para redes sem o ad hoc
de saltos mltiplos. Proc. of the XXV Brazilian
Symposium on Computer Networks (SBRC 2007),
Belm, 2007.
33
Albuquerque
[14] R. Marin-Perianu, P. Hartel, and HScholten. A Clas-
sication of Service Discovery Protocols. Centre for
Telematics and Information Technology, University
of Twente, 2005.
[15] M. Mauve, A. Widmer, and H. Hartenstein. A sur-
vey on position-based routing in mobile ad hoc net-
works. IEEE Network, 15(6):3039, 2001.
[16] B.A. Miller and C. Bisdikian. Bluetooth Revealed:
The Insiders Guide to an Open Specication for
Global Wireless Communications. Prentice Hall,
2000.
[17] M. Nidd. Service discovery in DEAPspace. Per-
sonal Communications, IEEE [see also IEEE Wire-
less Communications], 8(4):3945, 2001.
[18] O. Ratsimor, D. Chakraborty, A. Joshi, T. Finin, and
Y. Yesha. Service Discovery in Agent-Based Per-
vasive Computing Environments. Mobile Networks
and Applications, 9(6):679692, 2004.
[19] Consortium Salutation. Salutation
architecture specication (part 1).
http://systems.cs.colorado.edu/grunwald/MobileCom-
puting/Papers/Salutation/s21a1a21.pdf, 1999.
[20] N. Simulator. 2 (NS2). URL: http://www. isi.
edu/nsnam/, January, 2005.
[21] A. Varshavsky, B. Reid, and E. de Lara. A cross-
layer approach to service discovery and selection in
manets. In The 2nd IEEE International Conference
on Mobile Adhoc and Sensor Systems Conference,
pages 459466, 2005.
34
FloorB: Mecanismo de Controle de
Inundao para Redes Ad Hoc
Mveis
Carlos Henrique Pereira Augusto
1
, Jos Ferreira de Rezende
1
1
GTA - PEE - COPPE Universidade Federal do Rio de Janeiro (UFRJ)
Caixa Postal 68.504 21.945-970
Rio de Janeiro RJ Brasil
{chenrique | rezende}@gta.ufrj.br
Abstract
Flooding is a basic mechanism for ad hoc networks.
However, it can bring some drawbacks such as broadcast
storm due to a huge number of message retransmissions.
This can impair the network performance and cause a
large consumption of power. Thus, there are several pro-
posals to reduce these effects, but ad hoc networks cha-
racteristics, such as lack of infrastructure and nodes mo-
bility, impose restrictions to their efciency. To overcome
this problem, this paper proposes the FloorB mechanism
that controls ooding through a summarized 2-hop neigh-
borhood knowledge using Bloom lters. The FloorB ef-
ciency are presented and compared by simulation with
other deterministic and probabilistic proposals.
Keywords: Ad hoc Networks, Flooding, Bloom lters
Resumo
Inundao um mecanismo fundamental no funcio-
namento de redes ad hoc, entretanto tal mecanismo pode
causar efeitos nocivos no desempenho dessas redes, ge-
rando um nmero excessivo de mensagens redundantes
e, conseqentemente, consumindo grandes quantidades
de energia. Em funo disto, existem diversas propos-
tas para minimizar esses efeitos, que por outro lado tm
baixa ecincia pelas prprias caractersticas das redes
ad hoc, como falta de infra-estrutura e mobilidade dos
ns. Para suplantar este problema, este artigo prope
o mecanismo FloorB que controla a inundao atravs
do conhecimento resumido, por ltros de Bloom, da vizi-
nhana de at dois saltos. A ecincia de tal mecanismo,
comparativamente a outras propostas determinsticas ou
probabilsticas, avaliada atravs de simulao.
Palavras-chave: Redes ad hoc, Inundao, Filtros de
Bloom
1. INTRODUO
Nas redes ad hoc, por suas caractersticas de topolo-
gia dinmica, escassez de recursos e ausncia de infraes-
trutura, o processo de inundao se torna um mecanismo
fundamental, por permitir a coleta, distribuio ou disse-
minao de informao na rede, sendo largamente utili-
zado em protocolos de roteamento [10, 25], descoberta
de servios [19, 15], e para disseminao ou busca de in-
formao de uma forma geral [16]. Entretanto, um dos
problemas introduzidos pela inundao a chamada tem-
pestade de broadcast [23], que implica em transmisses
redundantes, alto nvel de disputa no meio e aumento de
colises, consumindo desta forma os j escassos recursos
disponveis.
Para controlar estes efeitos nocivos da inundao, di-
versas solues foram propostas na literatura [14, 18, 23,
9, 11]. Estas solues podem ser agrupadas basicamente
em probabilsticas e determinsticas. Os mecanismos de-
terminsticos dependem do conhecimento da topologia
existente, pelo menos de forma limitada, por exemplo da
vizinhana de dois saltos. Entretano, por apresentarem
diculdade na obteno deste conhecimento, acabam re-
caindo em algum tipo de inundao ou troca adicional de
mensagens, aumentando a sobrecarga de controle.
Por outro lado, os mecanismos probabilsticos no de-
pendem do conhecimento da topologia, mas apresentam
limitaes de desempenho quando aplicados a redes que
no correspondem s hipteses probabilsticas iniciais do
mecanismo [27], por exemplo, quando so aplicados em
redes com distribuio no uniforme dos ns.
Assim sendo, a proposta descrita neste artigo, cha-
mada FloorB, inicialmente apresentada em [1], baseia-se
em um mecanismo hbrido, que assume um conhecimento
da topologia em at dois saltos, de forma resumida, e uti-
liza um mtodo probabilstico para realizar o reencami-
Carlos Henrique Pereira Augusto e
Jos Ferreira de Rezende
FloorB: Mecanismo de Controle de Inundao
para Redes Ad Hoc Mveis
nhamento das mensagens de inundao. Para resumir a
representao da vizinhana de dois saltos, o mecanismo
faz uso de ltros de Bloom. Tais ltros apresentam pro-
priedades que permitem reduzir a quantidade de informa-
es trocadas entre vizinhos e facilitama manipulao das
informaes de vizinhana coletadas.
O mecanismo proposto avaliado por simulao,
comparativamente a outros mecanismos, tais como inun-
dao cega (Blind), inundao probabilstica simples
(Gossip), Gossip Adaptativo e MPR, tanto em termos de
taxas de entrega, como em reencaminhamentos evitados,
utilizando-se cenrios com rede em grade sem mobili-
dade, mobilidade do tipo Random Waypoint e mobilidade
do tipo social.
Para apresentar a proposta, o restante do texto est or-
ganizado da seguinte maneira. Na Seo 2, so apresen-
tados os trabalhos relacionados. A Seo 3 descreve a
proposta e alguns conceitos utilizados na sua elaborao,
tais como a avaliao de vizinhana de 1 e 2 saltos e os
conceitos de ltros de Bloom, e no nal descreve o algo-
ritmo utilizado. A Seo 4 enumera as premissas usadas
no desenvolvimento do simulador prprio, utilizado nas
primeiras avaliaes, descreve os cenrios de simulao
e discorre sobre os resultados obtidos, e nalmente apre-
senta os resultados obtidos a partir da implementao no
simulador ns-2 [24]. A Seo 5 traz as concluses, in-
dicando as principais contribuies deste artigo, e sugere
alguns trabalhos futuros.
2. TRABALHOS RELACIONADOS
A soluo tima para o problema de inundao e-
ciente a partir de um n calcular a MLST - Maximum
Leaf Spanning Tree - do grafo, escolhendo como raiz o
n origem da inundao, ou seja, obter a rvore geradora
do grafo com o maior nmero de folhas. Esta soluo
tima em termos de nmero de mensagens reencaminha-
das, pois uma vez que as folhas da rvore no precisam
reencaminhar as mensagens, quando o nmero de folhas
mximo, o nmero de mensagens ser mnimo.
Entretanto, esta soluo no prtica, uma vez que o
problema NP-difcil [13], e portanto o algoritmo possui
alta complexidade, alm de ser de difcil implementao
de forma distribuda. Por exemplo, o algoritmo proposto
em [13] para obteno da MLST de um grafo tem como
passo inicial a realizao de uma busca em largura, que de
forma distribuda deve ser implementada como uma inun-
dao cega. Alm disto, a MLST deveria ser calculada a
cada instante que seja realizada a inundao, por conta da
mobilidade, e para cada fonte que inicie a inundao.
Para solucionar esta diculdade, diversas solues so
propostas na literatura, procurando obter inundaes com
boa cobertura da rede, atraso limitado e nmero reduzido
de mensagens reencaminhadas. Por exemplo, em [23],
os efeitos da tempestade de broadcast e alguns esquemas
para controle de inundao, classicados em probabils-
ticos, baseado em contagem, baseado em distncia, base-
ado na localizao e baseado em agrupamento, so avali-
ados. Os resultados por simulao apresentados indicam
a efetividade dos mecanismos, mas os mesmos no so
projetados para se adaptar a redes com caractersticas di-
versas, como por exemplo, redes onde a distribuio dos
ns no seja uniforme.
Em [14], so apresentados detalhadamente, em diver-
sos cenrios, os conceitos do reencaminhamento proba-
bilstico, chamado Gossip, e outros esquemas auxiliares
para melhoria das taxas de entrega. O funcionamento b-
sico do Gossip semelhante inundao cega, somente
alterando o fato de que a mensagem reencaminhada na
primeira vez que recebida com uma probabilidade p,
parmetro do mecanismo. J em [27], h uma ampla ava-
liao do mecanismo probabilstico, frente a diversos pa-
rmetros da rede, como mobilidade, carga, densidade de
ns e probabilidade de reencaminhamento. Em ambos os
trabalhos, no so considerados outros esquemas de con-
trole de inundao, tais como mtodos determinsticos.
O mecanismo RAPID, proposto em [11], apresenta
um esquema conjugado de Gossip Adaptativo com um
esquema semelhante ao baseado em contagem de [23].
No Gossip Adaptativo, a probabilidade de reencaminha-
mento calculada como funo do nmero de vizinhos
atravs da frmula

N
, onde N o nmero de vizinhos e
um parmetro do mecanismo. O aprendizado de vizi-
nhana ocorre pela troca de mensagens de hello simples.
A associao destes esquemas apresenta uma boa taxa de
entrega e grande economia de transmisso em redes com
mobilidade no muito elevada, ao custo de introduo de
um atraso considervel para a entrega das mensagens.
O trabalho em [9] prope um Gossip Adaptativo base-
ado no conhecimento de vizinhana de 1 salto do receptor,
obtido por mensagens de hello simples, e da vizinhana
do emissor, divulgada junto com a mensagem de inunda-
o. Esta proposta apresenta a vantagem de simplicar
e reduzir o tamanho das mensagens de hello, entretanto,
provoca o crescimento da mensagemde inundao, e tam-
bm toma decises probabilsticas baseadas somente na
comparao das vizinhanas do emissor e receptor, no
atuando adequadamente em redes com caractersticas no
homogneas.
Outra alternativa para disseminar informao em re-
des ad hoc utilizar redes sobrepostas [7]. Com estas
estruturas, possvel transmitir uma mensagem para toda
a rede de forma econmica, ao encaminhar as mensagens
somente pela rede sobreposta. Entretanto, a construo e
manuteno de redes sobrepostas em ambientes mveis,
ou muito dinmicos, custosa e normalmente baseada em
mensagens de inundao, recaindo no problema inicial.
36
Solues determinsticas so possveis, tais como a
obteno de conjuntos dominantes e outros [3, 2, 26, 17].
Entretanto, novamente, a construo e manuteno destas
estruturas, e os algoritmos envolvidos, apresentam com-
plexidade elevada, tanto em tempo quanto em mensagens.
Deste modo, uma alternativa muito usual a adoo de
MPRs (Multi Point Relays), proposta em [18] e avaliada
em alguns trabalhos [5, 6, 22]. Esta talvez seja a soluo
mais adotada para o controle de inundao, sendo a alter-
nativa utilizada no protocolo de roteamento para redes ad
hoc OLSR [10].
Tanto os resultados obtidos neste trabalho, quanto os
trabalhos citados, indicam que esta soluo apresenta al-
tas taxas de reencaminhamentos evitados, adaptando-se
bem as mais diversas topologias. A seleo de MPRs con-
siste na aplicao de uma heurstica baseada somente na
informao de 2 saltos, que obtida atravs da troca de
mensagens de hello, que carregam a tabela de vizinhos do
n que a emite, e do algoritmo simplicado abaixo:
Algoritmo de seleo de MPR
1: Envio de hellos com lista de vizinhos (recepo de hellos)
2: Selecionar como MPR os vizinhos de 1 salto que so nicos no
alcance de algum vizinho de 2-saltos
3: Remover da lista os vizinhos de 2-saltos que foram cobertos
4: Escolher como MPR o vizinho de 1 salto que cobre o maior
nmero de vizinhos de 2-saltos ainda no cobertos
5: Remover da lista os vizinhos de 2-saltos que foram cobertos e,
caso a lista no esteja vazia, retornar ao passo anterior
Oobjetivo deste algoritmo de seleo de MPRs obter
um conjunto reduzido de vizinhos de 1 salto que permite
alcanar todos os vizinhos de 2 saltos. Este algoritmo
constri os conjuntos de vizinhos de 1 e de 2 saltos a partir
da recepo dos hellos, e faz buscas simultneas nos dois
conjuntos, como quando se obtm os vizinhos de 1 salto
que so nicos no alcance de algum vizinho de 2 saltos, e
por este motivo a complexidade de tempo O(
2
), onde
o grau mximo na rede.
3. FLOORB - REPRESENTAO DE VI-
ZINHANA POR FILTROS DE BLOOM
Nesta seo, apresentada a idia bsica e os concei-
tos envolvidos na proposta. O mecanismo, denominado
FloorB (Flooding control through neighborhood Repre-
sentation by Bloom lters), utiliza um conhecimento li-
mitado da vizinhana de dois saltos e um mtodo proba-
bilstico para o encaminhamento das mensagens.
3.1. VIZINHANA DE 1 E 2 SALTOS E REENCAMI-
NHAMENTO DE MENSAGEM
Um dos conceitos adotados na proposta o de obter
um conhecimento limitado sobre a vizinhana de 1 e 2
saltos do n receptor, e sobre a vizinhana de 1 salto do
n emissor. Algumas premissas so utilizadas nesta ava-
liao, que so posteriormente relaxadas. Considere uma
rede densa com distribuio uniforme dos ns, onde as
transmisses so omnidirecionais, com mesma potncia,
e propagao homognea, portanto produzindo uma rea
de cobertura circular de raio constante. Neste caso, pode-
se representar a interao entre dois ns, e emissor e r
receptor, atravs da Figura 1.
e r
a
lc
a
n
c
e

Figura 1. Comunicao entre dois ns
Seja N
h
(x) o conjunto de ns que distam h saltos
do n x, pode-se estabelecer que o conjunto de vizinhos
diretos de e N
1
(e) (Figura 2(a)), que possui |N
1
(e)|
elementos. Analogamente, o conjunto de vizinhos de r
N
1
(r) (Figura 2(b)). Porm, o conjunto de ns que
no recebem diretamente uma mensagem enviada por e,
mas podem receb-la caso r a reencaminhe, dado por
M = N
1
(r) (N
1
(e) N
1
(r)) (Figura 2(d)). A partir
das premissas iniciais, pode-se armar que as cardinalida-
des destes conjuntos so proporcionais s reas cobertas,
conforme descrito em [9].
Com estas consideraes, a simples comparao en-
tre a lista de vizinhos do emissor e a lista de vizinhos do
receptor fornece uma estimativa da necessidade do recep-
tor encaminhar a mensagem ou no. Entretanto, existe
uma informao que no avaliada, uma vez que podem
existir ns vizinhos do emissor, que no so vizinhos do
receptor, mas tambm podem fornecer uma cobertura, ao
menos parcial, dos vizinhos do receptor no cobertos pelo
emissor, ou seja, alcanar elementos do conjunto M.
Alm disto, pode ocorrer em algumas topologias o
fato de que alguns ns que so vizinhos do emissor e re-
ceptor simultaneamente, ou seja, pertencentes a N
1
(e)
N
1
(r) (Figura 2(c)), no permitam alcanar nenhum dos
ns em M. Tais ns, portanto, deveriam ser descartados
pelo receptor, na sua avaliao se ele deve reencaminhar
a inundao ou no.
Portanto, o FloorB amplia a avaliao inicial, e a par-
tir da lista completa de vizinhos de cada n do conjunto
N
1
(r) estabelece o conjunto unio dos vizinhos de 1 salto
37
dos ns pertencentes a M como U = {
N
1
(x) | x
M}, representado na Figura 2(e).
Realizando a interseco deste conjunto U com os vi-
zinhos de e obtm-se o conjunto I = U N
1
(e), com-
posto por todos os ns vizinhos de e que podem alcan-
ar elementos de M. Com as consideraes de distribui-
o uniforme, rede densa e transmisso ominidirecional,
podemos ver que para os ns receptores posicionados no
limite do alcance de transmisso do emissor, as cardina-
lidades destes conjuntos I e M so muito prximas, e
neste caso o n receptor deve encaminhar a mensagem
recebida.
Para relaxar as premissas de distribuio uniforme e
rede densa, adotamos umencaminhamento probabilstico,
onde a probabilidade de transmisso para receptores que
possuem vizinhana muito similar a do transmissor, ou
seja |M| 0 e I N
1
(e), deve ser aproximadamente
nula e a probabilidade de transmisso para receptores no
limite de alcance, ou seja |M| |I|, deve ser aproxima-
damente 1, e portanto foi utilizada a Equao 1.
p =
|M|
|I|
(1)
Para os casos onde |I| = 0 ou que esta razo superior
a 1, utiliza-se p = 1. J nos casos onde |M| = 0, adota-
se, de forma conservadora, a Equao 2.
p =
0.333
(|N
1
(e) N
1
(r)|)
2
(2)
Esta Equao 2 aplicada no caso onde no existem
novos ns que recebam a mensagem, caso ela seja reenca-
minhada, e portanto deveria-se esperar uma probabilidade
nula. Entretanto, a equao apresenta um decaimento
mais agressivo do que o adotado no Gossip Adaptativo,
ao utilizar o quadrado do nmero de ns na interseco, e
tambm ao adotar um valor de probabilidade inicial me-
nor que 1 ( < 1). Com a adoo desta segunda equao,
pretende-se ter uma probabilidade residual de reencami-
nhamento para aqueles ns que no possuem vizinhos no
cobertos. Este procedimento pode reduzir a economia ob-
tida pelo mecanismo, porm permitindo a ocorrncia de
reencaminhamentos em situaes onde ainda no h um
aprendizado adequado da vizinhana, tornando o meca-
nismo mais gil e robusto.
A principal implicao desta forma de calcular a pro-
babilidade de encaminhamento pela relao entre o n-
mero de elementos destes dois conjuntos, comparativa-
mente a outras, a captura mais precisa de situaes ex-
cepcionais na topologia da rede. Por exemplo, considere
a situao extrema de uma rede composta por dois con-
juntos de ns interligados por somente um n interme-
dirio, como representado na Figura 3. Neste caso, o n
b possui um grande nmero de vizinhos, o que levaria a
uma baixa probabilidade de reencaminhar a mensagem no
Gossip Adaptativo.
No entanto, os conjuntos U e N
1
(e) so disjuntos, e
portanto obtm-se p = 1, conforme desejado. Por ra-
ciocnio semelhante, e pela observao de outros cen-
rios, possvel concluir que a obteno de p ser sempre
adequada, mesmo quando ocorre variao de densidade,
topologia especca, redes com alta ou baixa densidade,
ou transmisses no-omnidirecionais ou com obstculos,
conforme observado nos resultados apresentados na Se-
o 4.
Figura 3. Topologia com corte em um n
Um questionamento que pode ser feito quanto a este
mecanismo sobre a obteno, manuteno e divulgao
da tabela de vizinhos de cada n. Entretanto, este um
procedimento realizado em diversos mecanismos atravs
da troca peridica de mensagens de hello. Para se obter a
lista de vizinhos de dois saltos (N
2
(x)) necessrio que
cada n informe sua tabela de vizinhos na mensagem de
hello, como realizado no mecanismo MPR. Porm, em
redes muito densas essas mensagens se tornam extensas e
cada n dever manter tais listas em memria e process-
las para computar os conjuntos propostos.
Para minimizar este problema, de enviar a lista e ob-
ter os conjuntos de vizinhos, utilizando menos recursos,
de banda da rede e computacionais, o FloorB realiza uma
aplicao de Filtros de Bloom, que so descritos na Se-
o 3.2.
3.2. FILTROS DE BLOOM
Filtros de Bloom [4] so estruturas de dados probabi-
lsticas com espao reduzido utilizadas para representar
um conjunto, e que permitem vericar se um dado per-
tence ou no a ele de forma rpida. Falsos positivos so
possveis, entretanto com probabilidades controlveis. Os
ltros de Bloom tm ampla aplicao em redes de com-
putadores [20, 12].
Um ltro de Bloom constitudo de um vetor de m
bits, e um conjunto de k funes hash, onde cada uma
delas mapeia um elemento em uma posio no vetor. Um
ltro vazio equivale ao vetor com todos os bits em zero.
38
(a) Vizinhos do Emissor (b) Vizinhos do Receptor (c) Interseo de Vizinhos (N
1
(e) N
1
(r))
(d) M (e) U (f) I
Figura 2. Conjuntos de Vizinhana
X
Hash 2
Hash 1
Hash k
filtro - m bits
1
1
1
bits ligados na insero
Figura 4. Funcionamento do ltro de Bloom
Para adicionar um elemento ao ltro, aplica-se cada uma
das k funes hash ao elemento, obtendo k posies do
vetor que devem ser alteradas para 1, conforme Figura 4.
Para consultar se um elemento pertence ao conjunto,
calcula-se os k hashes deste elemento, e verica-se se os
bits correspondentes esto ligados no ltro. Caso pelo
menos um deles no esteja, tal elemento no pertence ao
conjunto. Conforme apresentado em [20], a probabili-
dade de um falso positivo, ou seja, de que todos os bits
correspondentes estejam ligados e de que o elemento no
pertena ao conjunto de n elementos dada pela Equa-
o 3, apresentada na Figura 5, para valores de m iguais
a 128 e 256, e para k igual a 1, 2 ou 3, com nmero de
elementos (vizinhos) variando de 0 a 200.
Nesta gura, podemos observar que os ltros de
Bloom com estas conguraes apresentam uma proba-
bilidade de falso positivo relativamente baixa quando o
nmero de vizinhos inferior a 50, e que a escolha de
valores maiores de k permitem menores probabilidades
quando o nmero de vizinhos pequeno, mas ao custo de
probabilidades mais elevadas quando h aumento deste
nmero. Entretanto, estes falsos positivos, quando limi-
tados a baixos valores, no so signicativos para o de-
sempenho do mecanismo FloorB, uma vez que ele utiliza
uma razo entre o nmero de elementos de dois conjun-
tos, e tais erros acabam compensados neste clculo.
P
false
=
1
1
m
kn
k
(3)
Tambmsegundo o trabalho em[20], o nmero de ele-
mentos de um conjunto |S| pode ser estimado, a partir do
ltro correspondente, contando-se o nmero de bits em 0
(#bits0) no ltro e aplicando a Equao 4.
39
0
0.2
0.4
0.6
0.8
1
0 50 100 150 200
P
r
o
b
a
b
i
l
i
d
a
d
e

d
e

f
a
l
s
o

p
o
s
i
t
i
v
o
Nmero de vizinhos (elementos no conjunto)
m=128, k=1
m=128, k=2
m=128, k=3
m=256, k=1
m=256, k=2
m=256, k=3
Figura 5. Probabilidade de falso positivo
|S| =
log(
#bits0
m
)
klog(1
1
m
)
(4)
Outra propriedade importante dos ltros de Bloom
a facilidade para se obter o ltro correspondente unio
ou interseco de conjuntos, quando se utiliza o mesmo
nmero de bits m e as mesmas funes hash. O ltro cor-
respondente unio dos conjuntos obtido pela aplicao
simples da operao lgica OU (OR) bit a bit entre os l-
tros. Analogamente, a interseco obtida atravs da ope-
rao E (AND). Estas propriedades sero utilizadas pelo
FloorB para computar os conjuntos U e I, apresentados
na Seo3.1.
3.3. FLOORB - ALGORITMO
O algoritmo adotado pelo FloorB para executar as ta-
refas descritas na Seo 3.1, utilizando os conceitos de
ltro de Bloom descritos na Seo 3.2, apresentado a
seguir.
O passo 1 deste algoritmo corresponde troca peri-
dica de mensagens de hello, onde cada n x passa a in-
formao filtro(N
1
(x)) para seus vizinhos. O conjunto
N
1
(x) construdo localmente pela recepo dos mes-
mos hellos. Em seguida, todas as informaes descritas
na Seo 3.1 so obtidas das propriedades dos ltros de
Bloom. Ao receber uma inundao (passo 2), feita a
vericao de pertinncia de e nos ltros armazenados no
receptor (passos 3 e 4), e populado o conjunto M (passo
5). Com este conjunto calculado, so obtidos os ltros
correspondentes aos conjuntos U e I (passos 9 e 11), es-
timada a cardinalidade dos conjuntos M e I (passo 12) e
calculada a probabilidade p (passo 13).
Tal algoritmo apresenta algumas vantagens sobre ou-
tros mtodos para controlar inundao. Inicialmente, ele
produz mensagens de hello de tamanho xo para divul-
gar a relao de vizinhos. Este tamanho xo pode ser
menor que uma lista completa, quando a rede for densa,
uma vez que com o ltro pode-se resumir a vizinhana.
Por exemplo, ao utilizar um ltro de 128 bits para rela-
Algoritmo do FloorB
Notao:
e = n emissor; r = n receptor;
filtro(A) = ltro de Bloom do conjunto A;
N
h
(x) = conjunto de ns que distam h saltos do n x;
M= N
1
(r) (N
1
(e) N
1
(r));
U = {
N
1
(x)|x M};
I= U N
1
(e);
Valores iniciais:
filtro(U) = filtro();
M =
Algoritmo
1: Envio de hellos com ltro de Bloom calculado a partir da lista
de vizinhos (recepo de hellos)
2: Ao receber uma mensagem de inundao de e,
3: Para cada v N
1
(r), faa:
4: Se e no vizinho de v (bits correspondentes no ligados
em filtro(N
1
(v))), faa:
5: Adicionar v a M
6: m Se
7: m Para cada
8: Para cada m pertencente a M, faa:
9: filtro(U) = filtro(U) OU filtro(N
1
(m))
10: m Para cada
11: filtro(I) = filtro(U) E filtro(N
1
(e))
12: estimar |M| e |I| (equao 4)
13: calcular p de reencaminhamento (equao 1 ou equao 2)
14: realizar reencaminhamento com probabilidade p
cionar uma vizinhana de 10 ns, teremos um reduo
de 60% no tamanho da mensagem, em relao mensa-
gem completa, quando considerados endereos de 32 bits
(10 32bits = 320bits). Alm disto, o algoritmo mais
simples que o adotado pelo MPR, pois percorre uma nica
vez a lista de vizinhos dos ns, e portanto sua complexi-
dade de tempo O().
Por outro lado, o algoritmo do FloorB captura caracte-
rsticas de topologias diversas, o que no ocorre nos me-
canismos do Gossip ou Gossip Adaptativo, que tm de-
sempenho reduzido em situao de redes densas mas que
possuam algum n responsvel pela interligao de duas
parties da rede, como a topologia apresentada na Fi-
gura 3.
4. AVALIAO
Esta seo enumera as premissas usadas no desenvol-
vimento do simulador prprio, descreve os cenrios utili-
zados e avalia os resultados obtidos.
4.1. SIMULADOR
Para avaliar o controle de inundao realizado pela
proposta, foi implementado um simulador em linguagem
tcl, sem a adoo de uma camada de enlace especca,
no existindo portanto conteno ou coliso. Cada trans-
misso atmica e instantnea, chegando a todos os vi-
zinhos determinados pelo alcance de transmisso. Na re-
cepo, possvel introduzir uma probabilidade de perda
40
de mensagens, tanto de inundao quanto de hellos. O
simulador modular, permitindo o acrscimo de diversos
mecanismos de inundao, e os seguintes mecanismos fo-
ram implementados:
Blind - cada n reencaminha a mensagem na pri-
meira vez que a recebe. A implementao corres-
ponde a uma Busca em Largura, e se a rede for co-
nexa, e no houver perdas, todos os ns recebero a
inundao.
Gossip - cada n reencaminha a mensagem na pri-
meira vez que a recebe, com probabilidade p.
MPR ideal - cada n executa o algoritmo de escolha
de MPRs no instante que envia (ou reencaminha) a
mensagem e o clculo de MPRs baseado no conhe-
cimento preciso e imediato do posicionamento dos
ns da rede.
MPR real - cada n executa o algoritmo de escolha
de MPRs no instante que envia (ou reencaminha) a
mensagem, mas o clculo de MPRs realizado base-
ado no conhecimento de vizinhana obtido pelo re-
cebimento de hellos.
Gossip Adaptativo - cada n reencaminha a mensa-
gem na primeira vez que a recebe com probabilidade
p, conforme proposto no mecanismo RAPID [11],
descrito na Seo 2, mas sem utilizar mecanismo de
temporizao.
FloorB - implementao da proposta descrita na Se-
o 3.
Alguns parmetros dos mecanismos foram previa-
mente estudados, avaliados e escolhidos. Para o Gossip
adotou-se p = 0, 7. Este valor semelhante aos principais
valores utilizados na proposta original do Gossip [14], de
0, 60, 0, 65 e 0, 72. Alm disto, importante observar o
comportamento do mecanismo, que apresenta economia
constante e uma taxa de entrega reduzida em redes espar-
sas. Outros valores de p alterariam os resultados obtidos,
sem alterar, no entanto, a tendncia do mecanismo.
J para o Gossip Adaptativo, foi selecionado o valor
de = 6, diferente do proposto em [11], onde = 2, 5.
Esta escolha foi realizada a partir de simulaes e de uma
avaliao sobre o modelo apresentado na proposta do RA-
PID. Devido a equao utilizada para clculo da probabi-
lidade, fazendo-a inversamente proporcional ao nmero
de vizinhos, ocorre que a probabilidade de que nenhum
do ns pertencentes a N
1
(e) reencaminhe a mensagem
ser dada pela Equao 5, uma vez que em redes com
distribuio uniforme os valores de N
1
(e) e N
1
(r) sero
aproximadamente iguais.
p
not
=
1

|N
1
(r)|
|N
1
(r)|
(5)
A Equao 5 possui limite igual a e
quando o n-
mero de vizinhos tende a innito, fazendo que com pro-
babilidade e
a mensagem j deixe de ser encaminhada

logo no primeiro salto, restringindo o desempenho deste
mecanismo para redes muito densas. importante notar
que esta Equao 5 possui uma convergncia muita r-
pida para os limites, e por exemplo, com 20 vizinhos o
valor de p
not
, com = 6, aproximadamente de 0, 08%,
enquanto que com = 2, 5 de 6, 9%.
Os parmetros do ltro de Bloom do mecanismo Flo-
orB tambm foram atravs de simulaes iniciais, e pelo
estudo da Figura 5. Foram utilizados ltros com 256 bits
(m = 256) e 2 funes hash (k = 2), por apresentarem
baixas probabilidades de falso positivos para redes com
poucos ns, e tambm no possuir um tamanho muito ele-
vado para ser colocado nas mensagens.
Para avaliar os mecanismos propostos foram utiliza-
dos 3 tipos de cenrios, enumerados a seguir:
Grade - ns dispostos em grade, com distncia xa,
sem mobilidade, e vizinhana estabelecida pelo al-
cance de transmisso.
Aleatrio mvel - cenrio gerado atravs da ferra-
menta setdest do ns-2 [24], com ns distribudos ale-
atoriamente numa rea e com movimentao do tipo
random waypoint. Foram utilizados os seguintes pa-
rmetros: rea de 800m800m, 300 ns, alcance de
80m, pausa de 10s, e velocidade mnima de 0m/s.
Mobilidade social - cenrio gerado atravs da fer-
ramenta proposta em [21], onde os ns se agrupam
em comunidades e se deslocam dentro do seu grupo,
seguindo alguma forma de movimentao baseada
em modelo social. Foram criados cenrios com 100
ns, alcance de 80m e dois grupos em uma rea de
400m400m. Estes cenrios representam redes se-
melhantes a apresentada na Figura 3, onde dentro do
grupo h uma alta densidade, mas a comunicao en-
tre os grupos ocorre somente atravs de alguns pou-
cos ns na fronteira entre ambos.
Em seguida, os mesmos mecanismos, exceto MPR
real, foram implementados no simulador ns-2 [24], per-
mitindo realizar uma avaliao quando os mecanismos
so aplicados sobre uma camada de enlace com caracte-
rsticas reais, no caso IEEE 802.11. Uma diferena im-
portante na implementao do mecanismo MPR no ns-2
ocorre no processo de seleo dos MPRs. No simulador
prprio, esta seleo denida no momento de envio da
mensagem de inundao, enquanto a implementao rea-
lizada no ns-2 mais prxima do mecanismo de MPR do
41
OLSR, onde a mensagem de hello informa o conjunto de
MPRs selecionados.
4.2. RESULTADOS
As duas medidas de desempenho utilizadas para com-
parao dos mecanismos foram a taxa de entrega, ou al-
canabilidade, expressa pela Equao 6 e a taxa de reen-
caminhamentos evitados, expressa pela Equao 7.
tx entrega =
# msg recebidas
# ns na rede # msgs enviadas
(6)
reenc evitados = 1
# msg reencaminhadas
# msg recebidas
(7)
Alm destas medidas, em alguns cenrios tambm foi
avaliada a distribuio do nmero de ns com as diver-
sas taxas de reencaminhamentos realizados, de 0 a 1, em
intervalos de 0,1. O objetivo desta medida obter a dis-
tribuio da economia do mecanismo nos diversos ns,
sendo melhor o mecanismo que promove uma distribui-
o mais igualitria, fazendo com que a maior parte dos
ns possuam a mesma taxa de reencaminhamento.
Este fator importante por duas consideraes: meca-
nismo que sobrecarregue alguns ns com muitos reenca-
minhamentos estar sujeito a problemas de desempenho
no caso de falha deste n; ao concentrar os reencami-
nhamentos em alguns ns, caso exista limitao quanto
a energia, comum em redes ad hoc, mais rapidamente a
energia de tal n se esgotar, levando falha do mesmo.
Alguns parmetros tambm foram modicados nas di-
versas avaliaes, em particular o alcance dos ns, para
alterar o nmero de vizinhos e a densidade das redes, a
velocidade dos ns, para diversos graus de mobilidade, e a
taxa de perda na recepo, para simular o comportamento
dos mecanismos frente a perdas decorrentes das camadas
de enlace (coliso) e fsica. Em todas as avaliaes, 10
fontes iniciam inundaes peridicas, realizadas a cada
20s, aps um tempo de transiente de 45s e at o nal da
simulao em 500s. So calculadas mdias e intervalos
de conana de 95%.
Ainda para avaliar a mobilidade, foram realizadas si-
mulaes onde foi variado o intervalo entre as mensagens
de hello enviadas. Esta uma forma indireta de avaliar a
robustez dos mecanimos frente mobilidade.
O primeiro cenrio avaliado foi o de rede em grade.
Ele composto de 400 ns em uma grade de 20 20,
equidistantes de 10m cada, sem mobilidade e sem per-
das. O alcance de transmisso utilizado foi variado de 11
at 41m, possibilitando avaliar a escalabilidade dos me-
canismos com o aumento da vizinhana, que variou de
4 (11m) at 72 vizinhos (41m). Os resultados obtidos
quanto a taxa de entrega podem ser vistos na Figura 6(a).
0.5
0.6
0.7
0.8
0.9
1
41 31 29 21 15 11
T
a
x
a

d
e

e
n
t
r
e
g
a
Alcance (m)
Blind
Gossip
MPR ideal
MPR real
Gossip Adaptativo
FloorB
(a) Taxa de Entrega
0
0.2
0.4
0.6
0.8
1
41 31 29 21 15 11
T
a
x
a

d
e

r
e
e
n
c
a
m
i
n
h
a
m
e
n
t
o
s

e
v
i
t
a
d
o
s
Alcance (m)
(b) Reencaminhamentos Evitados
Figura 6. Cenrio em grade, sem perdas
Este um cenrio esttico e com distribuio uni-
forme dos ns, e portanto teoricamente facilmente tratvel
por todos os mecanismos. Entretanto, pode-se observar
que o Gossip apresenta queda na taxa de entrega quando
a rede esparsa, conrmando resultado j esperado e des-
crito em outros trabalhos [27].
J o Gossip Adaptativo apresenta o resultado espe-
rado de reduo da taxa de entrega quando a rede se torna
densa. Isto devido a Equao 5, conforme j citado.
Os mecanismos Blind, MPR ideal e MPR real apre-
sentam taxa de entrega de 100% com todos os alcances,
uma vez que a rede conectada e no h perdas e nem
mobilidade. J o FloorB apresentou taxa de entrega supe-
rior a 99,9% em todos os alcances.
Na Figura 6(b), so mostrados os reencaminhamentos
evitados para cada mecanismo. Pode-se notar que para
esta medida o Blind e o Gossip tm desempenho cons-
tante, equivalente a 1 p, a probabilidade de no reen-
caminhar, que no Blind igual a 0. Os mecanismos de
MPR, tanto ideal quanto real, apresentaram desempenho
superior ao FloorB e ao Gossip Adaptativo, exceto com
alcance de 41m, onde o Gossip Adaptativo reencaminhou
menos, porm ao custo de uma reduo considervel na
taxa de entrega.
Por este grco pode-se notar que o mecanismo Flo-
orB conservador, e no apresenta o mesmo desempenho
42
0
50
100
150
200
250
300
0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
N
m
e
r
o

d
e

n
s
Taxa de reencaminhamento
MPR ideal
MPR real
Gossip Adaptativo
FloorB
Figura 7. Cenrio em grade, sem perdas
que o MPR no nmero de reencaminhamentos evitados, a
no ser nas redes muito densas. Entretanto, justamente
nestas redes que o problema de tempestade de broadcast
se torna mais grave, ou seja, que o mecanismo deve ser
mais atuante.
Alm disto, na Figura 7 observa-se a distribuio da
quantidade de ns em funo das taxas de reencaminha-
mentos realizados, para os mecanismos Gossip Adapta-
tivo, MPR ideal, MPR real e FloorB, quando o alcance
de transmisso de 41m. Neste grco, pode-se notar
que apesar dos mecanismos MPR terem uma boa taxa de
reencaminhamentos evitados, isto ocorre custa de que
alguns ns faam mais de 90% de reencaminhamentos
por mensagem de inundao. A mdia de reencaminha-
mentos do mecanismo MPR torna-se reduzida porque um
grande nmero de ns, da ordem de 120 neste cenrio, re-
encaminham menos de 10% das mensagens de inundao
recebidas.
J os mecanismos Gossip Adaptativo e FloorB apre-
sentam uma distribuio mais equilibrada, no tendo ns
com taxas de reencaminhamento superiores a 50% e 90%,
respectivamente. Este resultado indica que nestes meca-
nismos no haver ns sobrecarregados com a tarefa de
reencaminhar quase todas as inundaes, enquanto outros
permanecem ociosos. Uma grande vantagem deste com-
portamento, conforme j citado, a sobrevida da rede,
uma vez que os ns com taxas de reencaminhamento
muito alta podem esgotar rapidamente sua energia.
Outro fator que ao concentrar o trfego em poucos
ns, ao ocorrerem perdas, elas se tornam mais graves,
afetando a taxa de entrega, como observado na Figura 8,
onde utilizada taxa de perda na recepo de 0,2. Nota-
se que no MPR ideal, onde as perdas no inuenciam na
escolha dos MPRs, h uma reduo na taxa de entrega nas
redes mais esparsas. J no MPR real, como as perdas in-
uenciamno aprendizado da vizinhana, a taxa de entrega
pouco se altera, mas h uma reduo nos reencaminha-
mentos evitados. O FloorB, neste cenrio, apresenta-se
mais estvel, com melhores taxas de entrega em redes es-
parsas e taxas de reencaminhamentos evitados em redes
0.5
0.6
0.7
0.8
0.9
1
41 31 29 21 15 11
T
a
x
a

d
e

e
n
t
r
e
g
a
Alcance (m)
MPR ideal
MPR real
FloorB
(a) Taxa de Entrega
0
0.2
0.4
0.6
0.8
1
41 31 29 21 15 11
T
a
x
a

d
e

r
e
e
n
c
a
m
i
n
h
a
m
e
n
t
o
s

e
v
i
t
a
d
o
s
Alcance (m)
Figura 8. Cenrio em grade, perdas=0,2
densas equivalentes ao MPR real.
O segundo tipo de cenrio avaliado foi o cenrio com
posicionamento e mobilidade aleatrios. Para este tipo
de cenrio, variou-se a velocidade mxima dos ns para
se observar o comportamento dos mecanismos de acordo
com o grau de mobilidade da rede. Os resultados obti-
dos podem ser vistos na Figura 9 onde observa-se que as
taxas de entrega se reduzem para o Gossip Adaptativo e
para o MPR real, com o aumento da mobilidade. Isto se
deve principalmente ao fato de que o aprendizado de vizi-
nhana responde mais rapidamente na incluso do que na
excluso de ns.
Quando um novo vizinho entra na rea de alcance,
basta o recebimento de um hello para que o mesmo passe
a fazer parte da lista de vizinhos. Entretanto, quando um
n sai do alcance, somente aps a perda de um nmero
consecutivo de hellos ele sair da lista. Nestas simula-
es, foram utilizados intervalos de hellos de 3s, e uma
perda consecutiva de 3 hellos para remoo da lista.
Uma soluo possvel para que os mecanismos res-
pondam melhor mobilidade a reduo do intervalo en-
tre hellos. Entretanto, isto aumenta o nmero de men-
sagens de controle, e pode inclusive provocar o aumento
da taxa de perdas, em funo do crescimento de colises.
Por outro lado, conforme j citado, o mecanismo FloorB
se apresenta mais estvel com aumento da mobilidade,
43
0.5
0.6
0.7
0.8
0.9
1
20 10 3 1 0.1
T
a
x
a

d
e

e
n
t
r
e
g
a
Velocidade (m/s)
Blind
Gossip
MPR ideal
MPR real
Gossip Adaptativo
FloorB
(a) Taxa de Entrega
0
0.2
0.4
0.6
0.8
1
20 10 3 1 0.1
T
a
x
a

d
e

r
e
e
n
c
a
m
i
n
h
a
m
e
n
t
o
s

e
v
i
t
a
d
o
s
Velocidade (m/s)
Figura 9. Cenrio com mobilidade Random Waypoint, sem perdas
uma vez que utiliza uma razo entre o nmero de elemen-
tos em dois conjuntos, e ambos cam submetidos a erros
na contagem de elementos na mesma proporo, pratica-
mente anulando este efeito.
Para comprovar esta hiptese, ainda com cenrio alea-
trio, foram realizadas outras simulaes, neste caso com
grau de mobilidade constante, de velocidade de 0m/s at
5m/s, e foi variado o intervalo entre hellos, desde 2s
at 15s. Estes resultados podem ser vistos na Figura 10.
Observa-se que mesmo com intervalos de 15s o FloorB
mantma taxa de entrega estvel. Odesempenho do MPR
Real com intervalo de 5s nos hellos equivalente ao do
FloorB com intervalos de 10s ou 15s, indicando que a
proposta tanto mais robusto a variaes de velocidade,
como pode ter seu nmero de mensagens de controle re-
duzido ao se adotar intervalos maiores no envio dos hel-
los.
J quanto aos reencaminhamentos evitados, nota-se
nas Figuras 9(b) e 10(b) que os desempenhos de todos
mecanismos so bem semelhantes, com o FloorB apre-
sentando resultado um pouco inferior. Tambm nota-se
que todos os mecanismos no apresentam alterao sig-
nicativa nesta mtrica com o aumento da mobilidade ou
do intervalo entre hellos.
O terceiro tipo de cenrio avaliado consiste de cenrio
do tipo mobilidade social, onde os ns se movimentam
0.5
0.6
0.7
0.8
0.9
1
15 10 7 5 3 2
T
a
x
a

d
e

e
n
t
r
e
g
a
Intervalo entre hellos (s)
MPR Real
Gossip Adaptativo
FloorB
(a) Taxa de Entrega
0
0.2
0.4
0.6
0.8
1
15 10 7 5 3 2
T
a
x
a

d
e

r
e
e
n
c
a
m
i
n
h
a
m
e
n
t
o
s

e
v
i
t
a
d
o
s
Figura 10. Cenrio com mobilidade Random Waypoint, variao do
intervalo entre hellos
em grupo de acordo com uma predisposio para agrupa-
mento, conforme proposto em [21].
Nestes cenrios, existe uma variao muito grande
do nmero de vizinhos dos ns, de forma semelhante ao
apresentado na Figura 3, e por este motivo os mecanismos
tipo Gossip Adaptativo no obtm altas taxas de entrega.
Conforme a Figura 11, quando no h perdas, as taxas de
entrega dos mecanismos MPRs ideal e real e FloorB so
semelhantes, e novamente o FloorB apresenta-se conser-
vador, com menor nmero de reencaminhamentos evita-
dos, apesar do alto desempenho de todos.
Entretanto, da mesma forma que no cenrio em grade,
quando h uma taxa de perdas de 0,2, como na Figura 12,
o desempenho do FloorB superior em termos de taxa
de entrega, aproximando-se do Blind, e mantm a taxa de
reencaminhamentos evitados. Observa-se tambm que a
introduo de perdas afeta principalmente o mecanismo
MPR ideal, que passa a ter desempenho inferior ao MPR
real. Isto se deve a escolha mais restrita dos MPRs rea-
lizada pelo MPR ideal, que no depende das mensagens
de hello. Ao ter, por exemplo, um nico MPR realizando
a ligao dos dois grupos representados pela rede social,
as falhas de recepo deste n representam um impacto
maior nas taxas de entrega.
Como continuidade da avaliao, os mesmos meca-
nismos tambm foram implementados no ns-2 e avalia-
44
0.5
0.6
0.7
0.8
0.9
1
120 100 80 60
T
a
x
a

d
e

e
n
t
r
e
g
a
Alcance (m)
Blind
Gossip
MPR ideal
MPR real
Gossip Adaptativo
FloorB
(a) Taxa de Entrega
0
0.2
0.4
0.6
0.8
1
120 100 80 60
T
a
x
a

d
e

r
e
e
n
c
a
m
i
n
h
a
m
e
n
t
o
s

e
v
i
t
a
d
o
s
Alcance (m)
Figura 11. Cenrio com mobilidade Social (Comunidade), sem perdas
dos com os mesmos cenrios em grade e aleatrio mvel,
utilizando camada de enlace IEEE802.11, com taxa de
transmisso de 11 Mbps. Nesta avaliao, no foram in-
troduzidas perdas, entretanto, elas ocorrem naturalmente
devido a interferncias e colises, que se tornam mais in-
tensas em ambientes com vizinhana elevada [8].
Alm disto, as questes temporais, tais como sincro-
nizao e conteno no acesso ao meio, se tornam im-
portantes, uma vez que as transmisses no ocorrem de
forma atmica e instntanea. Isto faz com que o tamanho
das mensagens interra no desempenho dos mecanismos,
bem como o prprio uso de hello ou no.
Com esta implementao no ns-2, pode-se observar na
Figura 13 o desempenho dos mecanismos no cenrio em
grades. Nota-se que o resultado bastante semelhante ao
obtido com o simulador prprio, anteriormente apresen-
tado na Figura 6, tendo as mesmas tendncias. A prin-
cipal diferena ocorre pelo fato dos mecanismos estarem
submetidos a perdas e atrasos nas mensagens.
A Figura 14 apresenta o resultado das simulaes no
ns-2 com cenrio mvel aleatrio. Observa-se que a taxa
de entrega apresentou a mesma tendncia obtida com o
simulador prprio (Figura 9), entretanto, com degradao
mais acentuada dos mecanismos MPR e Gossip Adapta-
tivo com o aumento da mobilidade.
0
0.2
0.4
0.6
0.8
1
120 100 80 60
T
a
x
a

d
e

e
n
t
r
e
g
a
Alcance (m)
Blind
Gossip
MPR ideal
MPR real
Gossip Adaptativo
FloorB
(a) Taxa de Entrega
0
0.2
0.4
0.6
0.8
1
120 100 80 60
T
a
x
a

d
e

r
e
e
n
c
a
m
i
n
h
a
m
e
n
t
o
s

e
v
i
t
a
d
o
s
Alcance (m)
Figura 12. Cenrio com mobilidade Social (Comunidade), perda=0,2
0.5
0.6
0.7
0.8
0.9
1
41 31 29 21 15 11
T
a
x
a

d
e

e
n
t
r
e
g
a
Alcance (m)
Blind
Gossip
MPR
Gossip Adaptativo
FloorB
(a) Taxa de Entrega
0
0.2
0.4
0.6
0.8
1
41 31 29 21 15 11
T
a
x
a

d
e

r
e
e
n
c
a
m
i
n
h
a
m
e
n
t
o
s

e
v
i
t
a
d
o
s
Alcance (m)
Blind
Gossip
MPR
Gossip Adaptativo
FloorB
Figura 13. Cenrio em grade, ns-2
45
0.5
0.6
0.7
0.8
0.9
1
20 10 3 1 0.1
T
a
x
a

d
e

e
n
t
r
e
g
a
Velocidade (m/s)
Blind
Gossip
MPR
Gossip Adaptativo
FloorB
(a) Taxa de Entrega
0
0.2
0.4
0.6
0.8
1
20 10 3 1 0.1
T
a
x
a

d
e

r
e
e
n
c
a
m
i
n
h
a
m
e
n
t
o
s

e
v
i
t
a
d
o
s
velocidade (m/s)
Blind
Gossip
MPR
Gossip Adaptativo
FloorB
Figura 14. Cenrio com mobilidade Random Waypoint, ns-2
Pelo mesmo motivo anterior, a avaliao com altera-
o entre intervalos entre hellos foi realizada, e obteve-
se novamente a mesma tendncia, entretanto, novamente
com degradao mais acentuada dos mecanismos MPR e
Gossip Adaptativo com o aumento dos intervalos, como
pode-se observar na Figura 15. Nota-se que as taxas
de entrega so da ordem de somente 0,4 e 0,7 para os
mecanismos MPR e Gossip Adaptativo, respectivamente,
quando o intervalo entre hellos de 15s, sensivelmente
inferior taxa de aproximadamente 0,9 obtida pelo Flo-
orB com o mesmo intervalo.
Ainda com a implementao no ns-2, foi realizada
uma nova avaliao, que no era possvel ser realizada
com o simulador prprio, uma vez que este realiza trans-
misses instantneas e portanto no permite avaliar si-
tuaes de carga na rede. Para isto, foi adicionado aos
cenrios aleatrios mveis 16 pares de comunicao do
tipo fonte-destino, UDP/CBR, dispostos uniformemente
na rede conforme a Figura 16. Estes 32 ns no partici-
pam das tarefas de inundao, no emitindo, recebendo
ou reencaminhando mensagens, s atuando na gerao de
carga. Da forma como foram dispostos, permitem provo-
car conteno em toda a rea da rede, concorrendo por-
tanto com todos os hellos e mensagens de inundao en-
viados ou reencaminhados.
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
15 10 7 5 3 2
T
a
x
a

d
e

e
n
t
r
e
g
a
MPR
Gossip Adaptativo
FloorB
(a) Taxa de Entrega
0
0.2
0.4
0.6
0.8
1
15 10 7 5 3 2
T
a
x
a

d
e

r
e
e
n
c
a
m
i
n
h
a
m
e
n
t
o
s

e
v
i
t
a
d
o
s
MPR
Gossip Adaptativo
FloorB
intervalo entre hellos, ns-2
800 m
200 m
120 m
80m
1
2
0

m
2
0
0

m
8
0
0

m
Figura 16. Disposio dos ns geradores de carga

O trfego CBR gerado inicia-se aps 20s de simula-
o, permitindo a troca inicial de mensagens nos meca-
nismos, e possui pacote de 1000 bytes. A taxa gerada
foi variada conforme apresentado na Figura 17, desde um
valor inicial de 100kbps at 6Mbps correspondentes sa-
turao da rede.
Pode-se observar pela Figura 17(a) que em relao
ao comportamento da taxa de entrega dos mecanismos,
quando submetidos a carga, o desempenho do Blind foi
46
superior, seguido do FloorB, Gossip, Gossip Adaptativo
e MPR, nesta ordem. Em relao aos reencaminhamen-
tos evitados, todos obtiveram desempenho semelhante,
exceto o MPR que se apresentou ligeiramente superior
aumentando a economia obtida quando h aumento da
carga, entretanto, ao custo de reduzir a taxa de entrega.
0
0.2
0.4
0.6
0.8
1
6Mbps 5Mbps 4Mbps 3Mbps 2Mbps 1Mbps 100kbps
T
a
x
a

d
e

e
n
t
r
e
g
a
Taxa de cada fonte CBR
Blind
Gossip
MPR
Gossip Adaptativo
FloorB
(a) Taxa de Entrega
0
0.2
0.4
0.6
0.8
1
6Mbps 5Mbps 4Mbps 3Mbps 2Mbps 1Mbps 100kbps
T
a
x
a

d
e

r
e
e
n
c
a
m
i
n
h
a
m
e
n
t
o
s

e
v
i
t
a
d
o
s
Taxa de cada fonte CBR
Blind
Gossip
MPR
Gossip Adaptativo
FloorB
intervalo entre hellos, ns-2
interessante observar que o FloorB obteve desem-
penho em entrega superior ao do Gossip, que no de-
pendente de hellos, mesmo obtendo uma taxa de reenca-
minhamentos evitados igual ou superior ao mesmo. Este
resultado indica mais uma vez a robustez do FloorB a per-
das nas mensagens de hello.
5. CONCLUSO
Uma importante contribuio deste trabalho a ava-
liao comparativa entre diversos mecanismos de inun-
dao, alguns determinsticos tais como Blind e MPR, e
outros probabilsticos, tais como Gossip, Gossip Adapta-
tivo e FloorB. Nestas avaliaes foram utilizados alguns
tipos de cenrios, incluindo mobilidade do tipo social. No
entendimento dos autores, no h na literatura avaliaes
comparativas entre mecanismos determinsticos e proba-
bilsticos, e com cenrios com topologias no uniformes.
Alm disto, foi proposto um mecanismo de controle
de inundao, FloorB, que apresentou diversas vantagens
frente a outros mecanismos probabilsticos, como o Gos-
sip e Gossip Adaptativo.
O FloorB tambm apresentou algumas vantagens em
relao ao mecanismo MPR, tais como:
Tamanho xo e reduzido das mensagens de hello;
Algoritmo com complexidade de tempo inferior, em
O();
Maior estabilidade na taxa de entrega, tanto em rela-
o a mobilidade quanto a perdas de mensagens.
Possibilidade de reduo no nmero de mensagens
de controle ao utilizar hellos com intervalos maiores.
Ainda em relao ao MPR, apesar do FloorB apresen-
tar taxas de reencaminhentos evitados ligeiramente infe-
riores, seu desempenho foi quase equivalente, principal-
mente em redes com maior densidade, onde o efeitos no-
civos da inundao so mais graves. Por outro lado, ainda
se encontra em estudo o acrscimo de um mecanismo de
contagem de mensagens, semelhante ao adotado em [11],
com o intuito de melhorar o desempenho em termos de
economia, sem alterar a taxa de entrega do FloorB.
Outra importante contribuio deste trabalho o de-
senvolvimento de um simulador genrico, no qual outros
mecanismos podem ser acrescentados. Como trabalho
futuro, est prevista a incluso do mecanismo sugerido
em [9]. Tambm foi realizada a converso do cdigo para
o ns-2, permitindo validar os resultados j obtidos, e ve-
ricar o desempenho dos mecanismos quando utilizados
sobre uma camada de enlace tal como a do IEEE802.11.
Como trabalho futuro, estuda-se a implementao de
um protocolo de roteamento genrico, do tipo estado de
enlace, e aplicar todos os mecanismos implementados
para a execuo da inundao das mensagens de tal proto-
colo, avaliando os efeitos provocados pelos desempenhos
dos mecanismos s rotas calculadas pelo protocolo de ro-
teamento.
Referncias
[1] Carlos Henrique Pereira Augusto and Jos Ferreira
de Rezende. Inundao probabilstica em redes ad
hoc utilizando sumrio de vizinhana atravs de l-
tros de bloom. In XXVII Simpsio Brasileiro de Re-
des de Computadores - SBRC2009, May 2009.
[2] Stefano Basagni, Michele Mastrogiovanni, Alessan-
dro Panconesi, and Chiara Petrioli. Localized proto-
cols for ad hoc clustering and backbone formation:
A performance comparison. In Parallel and Distri-
buted Systems, IEEE Transactions on, volume 17,
pages 292306, April 2006.
47
[3] Stefano Basagni, Michele Mastrogiovanni, and Chi-
ara Petrioli. A performance comparison of protocols
for clustering and backbone formation in large scale
ad hoc networks. In Mobile Ad-hoc and Sensor Sys-
tems, 2004 IEEE International Conference on, pa-
ges 7079, October 2004.
[4] Burton H Bloom. Spacetime trade-offs in hash co-
ding with allowable errors. In Communications of
the ACM, volume 13, pages 422426, New York,
NY, USA, 1970. ACM.
[5] A. Busson, N. Mitton, and E. Fleury. An analysis of
the MPR selection in OLSR. In Spatial Stochas-
tic Modeling of Wireless Networks, SpasWIN 05,
Trento, Italy, April 2005.
[6] A. Busson, N. Mitton, and E. Fleury. An analysis of
the MPR selection in OLSR and consequences. In
The fourth Annual Mediterranean Ad Hoc Networ-
king Workshop, MED-HOC-NET 05, Ile de Porque-
rolles, France, June 2005.
[7] Sandrine Calomme and Guy Leduc. Efcient and
resilient overlay topologies over ad hoc networks. In
International Workshop on Self-Organizing Systems
(IWSOS 2007), pages 4458, September 2007.
[8] Kleber Vieira Cardoso and Jos Ferreira de Re-
zende. Adaptaco automtica de taxa em redes
802.11 densas. In XXVI Simpsio Brasileiro de Re-
des de Computadores - SBRC2008, May 2008.
[9] Julien Cartigny and David Simplot. Border node re-
transmission based probabilistic broadcast protocols
in ad-hoc networks. In Telecommunication Systems,
volume 22, pages 189204. Kluwer Academic Pu-
blishers, January 2003.
[10] T. Clausen and P. Jacquet. RFC 3626 - Optimized
Link State Routing protocol OLSR. IETF Request
for Comments, October 2003.
[11] Vadim Drabkin, Roy Friedman, Gabriel Kliot, and
Marc Segal. Rapid: Reliable probabilistic dissemi-
nation in wireless ad-hoc networks. In SRDS 07:
Proceedings of the 26th IEEE International Sympo-
sium on Reliable Distributed Systems, pages 1322,
October 2007.
[12] Natalia Castro Fernandes, Marcelo Dufes Donato
Moreira, and Otto Carlos Muniz Bandeira Duarte.
An efcient lter-based addressing protocol for au-
toconguration of mobile ad hoc networks. In IEEE
INFOCOM 2009, April 2009.
[13] Tetsuya Fujie. An exact algorithm for the Maximum
Leaf Spanning Tree problem. Computers and Ope-
rations Research, 30(13):1931 1944, 2003.
[14] Zygmunt Haas, Joseph Y. Halpern, and Li Li.
Gossip-based ad hoc routing. In INFOCOM 2002.
Twenty-First Annual Joint Conference of the IEEE
Computer and Communications, volume 3, pages
1707 1716, June 2002.
[15] Sumi Helal, Nitin Desai, Varun Verma, and Choo-
nhwa Lee. Konark - a service discovery and delivery
protocol for ad-hoc networks. In Third IEEE Confe-
rence on Wireless Communications and Networking
(WCNC), volume 3, pages 21072113, March 2003.
[16] Gautham Karumanchi, Srinivasan Muralidharan,
and Ravi Prakash. Information dissemination in par-
titionable mobile ad hoc networks. In Proceedings
of IEEE Symposiumon Reliable Distributed Systems
(SRDS), pages 413, October 1999.
[17] Ulas C. Kozat, Leandros Tassiulas, George Kondy-
lis, Bo Ryu, and Mahesh K. Marina. Virtual dy-
namic backbone for mobile ad hoc networks. In
IEEE International Conference on Communicati-
ons, 2001. ICC 2001., volume 1, pages 250255,
June 2001.
[18] Anis Laouiti, Amir Qayyum, and Laurent Viennot.
Multipoint relaying: An efcient technique for o-
oding in mobile wireless networks. In 35th Annual
Hawaii International Conference on System Scien-
ces (HICSS2002), January 2002.
[19] Vincent Lenders, Martin May, and Bernhard Platt-
ner. Service Discovery in Mobile Ad Hoc Networks:
A Field Theoretic Approach. In IEEE Internatio-
nal Symposium on a World of Wireless, Mobile and
Multimedia Networks (WoWMoM), pages 120130,
June 2005.
[20] Michael Mitzenmacher and Andrei Broder. Network
applications of bloom lters: (a survey). In Internet
Mathematics, volume 1, pages 485509, 2004.
[21] Mirco Musolesi and Cecilia Mascolo. A
Community based Mobility Model for Ad Hoc
Network Research. In Proceedings of the
2nd ACM/SIGMOBILE International Workshop on
Multi-hop Ad Hoc Networks: from theory to reality
(REALMAN06). ACM Press, May 2006.
[22] Dang Nguyen and Pascale Minet. Analysis of MPR
selection in the OLSR protocol. In AINAW 07:
Proceedings of the 21st International Conference on
Advanced Information Networking and Applications
Workshops, pages 887892, 2007.
48
[23] Sze-Yao Ni, Yu-Chee Tseng, Yuh-Shyan Chen, and
Jang-Ping Sheu. The broadcast storm problem in a
mobile ad hoc network. In MobiCom 99: Proce-
edings of the 5th annual ACM/IEEE international
conference on Mobile computing and networking,
pages 151162, New York, NY, USA, 1999. ACM.
[24] NS-2. The network simulator - ns-2, 1995.
http://www.isi.edu/nsnam/ns/ - ltimo acesso em
17/12/2008.
[25] C. Perkins, E. Belding-Royer, and S. Das. RFC3561
- Ad hoc On-demand Distance Vector AODV rou-
ting. IETF Request for Comments, July 2003.
[26] Peng-Jun Wan, Khaled M. Alzoubi, and Ophir Fri-
eder. Distributed construction of connected domi-
nating set in wireless ad hoc networks. In INFO-
COM 2002. Twenty-First Annual Joint Conference
of the IEEE Computer and Communications Soci-
eties. Proceedings. IEEE, volume 3, pages 1597
1604, June 2002.
[27] M. Bani Yassein, M. Ould-Khaoua, and S. Papanas-
tasiou. On the performance of probabilistic ooding
in mobile ad hoc networks. ICPADS, 11th Interna-
tional Conference on Parallel and Distributed Sys-
tems, 02:125129, 2005.
49
LARC - Laboratrio de Redes de Computadores
SBC - Sociedade Brasileria de Computao
Universidade Federal do Rio de Janeiro
Ncleo de Computao Eletrnica
Revista Brasileira de Redes de Computadores
e Sistemas Distribudos

Revista Brasileira de Computadores

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Revista Brasileira de Computadores

Enviado por

Direitos autorais:

Formatos disponíveis

EVISTA BRASILEIRA

Murilo Santos de Lima

Uma verso preliminar deste trabalho foi apresentada no SBRC 2009.

Murilo Bacharel em Cincia da Computao pela Universidade Fed-

23: end loop

requerida por A antes de t, se

). Assim, pela linha 39 do Algoritmo

Uma verso preliminar deste trabalho foi publicada no SBRC 2009

diante da necessidade de promover uma descoberta

o n provedor, assumiu-se que a velocidade

a mensagem j deixe de ser encaminhada

Figura 16. Disposio dos ns geradores de carga

Você também pode gostar