4.3 REORGANIZAÇÕES
4.3.15 Comparação com algoritmos BSF dinâmicos e single-hop
Na literatura foram propostos diferentes algoritmos BSF, conforme apresentado no Capítulo 3. Os dois principais algoritmos BSF com desco- berta dinâmica e single-hop são TSF e Law. O princípio de funcionamento destes algoritmos é o mesmo do Bluemob: componentes são unidos sucessi- vamente até que um único componente reste contendo todos os nós. Entre- tanto, a forma como este processo de união é realizado difere entre os três algoritmos.
A primeira diferença entre TSF e os outros dois algoritmos (Bluemob e Law) está na topologia do componente. Os componentes em Bluemob e Law são mantidos sob uma topologia Mesh, pois apesar da topologia resultante não conter ciclos, um nó pode possuir mais de um pai. TSF, ao contrário, impõe ao componente uma estrutura em árvore. Devido a isto, o processo de união de TSF é completamente diferente de Law e Bluemob pois deve preservar as restrições impostas por uma topologia em árvore na estruturação da rede.
A segunda diferença encontra-se na forma como o processo de busca por componentes é coordenado. No TSF os nós integrantes de um compo- nente são independentes e todos realizam o processo de busca Bluetooth (IN- QUIRY e INQUIRY SCAN) de forma autônoma e não coordenada. Portanto, não há em TSF a figura de líder como ocorre em Bluemob. Em Bluemob o processo de busca Bluetooth dentro de um componente é coordenado e ge- renciado por intermédio de um líder.
Bluemob e Law são mais semelhantes entre si, especialmente ao compará- los à TSF. Isto se deve ao fato da estrutura interna dos componentes mantidos por eles ser semelhante. São três as principais semelhanças entre a Law e Bluemob:
• Ambos fazem uso de um líder responsável por coordenar as atividades de busca por novos componentes para realizar a união.
• Ambos mantém um nó não compartilhado junto ao líder para que ele realize procedimentos Bluetooth custosos sem prejudicar a rede. • Ambos baseiam o processo de união de componente em uma tarefa
de união que se repete a cada δ segundos. Note que o processo de formação é continuo e que δ é menor que o tempo de deslocamento entre paradas de ônibus, portanto, entre paradas, ocorre mais de uma rodada de formação de rede.
Ao comparar Bluemob e Law o principal aspecto que faz com que os algoritmos possuam comportamentos diferentes está na forma como as reor-
ganizações são realizadas e como Bluemob incorpora h nestas reorganizações para melhor estruturar a topologia da rede. O impacto nas reorganizações pode ser visto diretamente no número de casos de reorganização existentes em Bluemob e o número de casos existentes em Law. Enquanto Bluemob necessita de treze diferentes casos, o algoritmo Law necessita seis reorgani- zações:
1. Se v = w (o componente possui apenas um nó v), tem-se dois casos: (a) Caso 1: |S(u)| < 7
(b) Caso 2: |S(u)| = 7
2. Se v 6= w (as Piconets de u e w são mescladas em uma Piconet), então: (a) Caso 3: |S(u)| + |S(w)| < 7
(b) Caso 4: |S(u)| + |S(w)| = 7 e |S(u)| = 1 (c) Caso 5: |S(u)| + |S(w)| = 7 e |S(u)| > 1 3. Caso 6: |S(u)| + |S(w)| > 7
Note que para cada condição em Law, existe 2 ou mais em Bluemob. Estes casos adicionais são consequência da introdução do peso h em Blue- mob, havendo um maior número de combinações de componentes a serem consideradas na reorganização. Note que:
1. Caso 1 de Law é desmembrado nos Casos 1 e 2 de Bluemob 2. Caso 2 de Law é desmembrado nos Casos 3, 4 e 5 de Bluemob 3. Caso 3 de Law é desmembrado nos Casos 6 e 7 de Bluemob 4. Caso 4 de Law é desmembrado nos Casos 8 e 9 de Bluemob 5. Caso 5 de Law é desmembrado nos Casos 10 e 11 de Bluemob 6. Caso 6 de Law é desmembrado nos Casos 12 e 13 de Bluemob
O impacto da introdução do h afeta também as provas de corretude do algoritmo. Em Bluemob foi introduzida uma nova propriedade que limita as topologias possíveis de serem formadas. Essa propriedade diz que h de mestres deve ser maior que o h de escravos não compartilhados. Isto faz com que nem toda topologia de mesh seja válida para Bluemob. Law não possui esta restrição, portanto aceita a existência destas topologias que são inválidas para Bluemob.
Ao necessitar manter esta propriedade, as provas de corretude das re- organizações são afetadas devendo ser considerada em Bluemob.
4.4 CONSIDERAÇÕES FINAIS
Neste capítulo foi apresentado o novo algoritmo de formação de Scat- ternetsBluemob. Este é um algoritmo Single-hop, com descoberta dinâmica projetado para operar em ambientes pequenos onde os nós não apresentam a mesma propensão de deixar a rede.
O algoritmo foi projetado para operar no interior de ônibus, com o objetivo de formar uma rede ad-hoc entre os passageiros de um ônibus. Com isso é viabilizada aplicações sensíveis a contexto para coleta de informações sobre os ônibus.
Entretanto, este algoritmo não é limitado ao contexto de sistema de transporte coletivo baseados em ônibus. Pode-se aplicar este algoritmo e téc- nica a outros contextos como, por exemplo, economia de energia e posici- onamento. Neste caso, o objetivo deixa de ser a diminuição no número de partições ocasionadas pelo desembarque de passageiros e seus smartphones.
Por exemplo, em Scatternets mestres e pontes consomem mais ener- gia que escravos, pois necessitam rotear mensagens. Isto implica em maior número de mensagens transmitidas e recebidas por estes nós, sendo portanto, interessante alocar nestas posições chave da rede nós com maior carga ener- gética. Este cenário poderia ser útil em uma pequena festa ou conferência, onde uma Scatternet espontânea fosse montada.
No exemplo do consumo energético, pode-se usar Bluemob fazendo com que o peso h reflita o nível energético dos nós. Desta forma, Bluemob posiciona nós com maior capacidade energética nestas posições. O objetivo é portanto aumentar a média da capacidade energética de mestres e pontes. A viabilidade de aplicação neste contexto deve ser estudada em mais deta- lhes para definir o consumo energético dos dispositivos gastos no processo de formação. Este estudo não será realizado no contexto deste trabalho.
5 VALIDAÇÃO DO ALGORITMO BLUEMOB
Avaliamos o algoritmo Bluemob levando em consideração métricas qualitativas e quantitativas selecionadas entre aqueles descritas no capítulo 2. O objetivo é validar o algoritmo Bluemob, mostrando que as características exigidas pelo ambiente de operação, e aplicações que usam a rede são aten- didas pelo Bluemob. Portanto, busca-se mostrar que o desempenho apresen- tado por Bluemob para formar a rede é suficiente para reconstruir a rede de nós a bordo de um ônibus após o embarque e desembarque de passageiros em um tempo menor que o tempo típico de viagem entre pontos de paradas. O objetivo secundário é mostrar as características estruturais das Scatternets formadas por Bluemob. Por exemplo, aspectos como diâmetro da rede e nú- mero de Piconets. Estas características intrínsecas a topologia e estrutura da Scatternetafetam a performance de aplicação que as usam. Por exemplo, di- âmetro da rede influi no número de saltos necessários para rotear mensagens na rede, e consequentemente, no tempo de transmissão de mensagens.