minicursos sbrc 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · capítulo 3...

51
Capítulo 3 Computação Ubíqua Ciente de Contexto: Desafios e Tendências Antonio Alfredo Ferreira Loureiro, Ricardo Augusto Rabelo Oliveira , Thais Regina de Moura Braga Silva, Waldir Ribeiro Pires Júnior, Lillian Brandão RezendedeOliveira,RandeArieviloMoreira,RafaelGuimarãesSiqueira,Bruno Pontes Soares Rocha,Linnyer Beatrys Ruiz Abstract Ubiquitous computing defines a new paradigm in which devices with processing and com- munication capacity are embedded into everyday elements, providingservices in a trans- parent way to users. It is possible to notice that this kind of computing has a strong connection with physical world features, as well as those presented by its users profi- les. In this way, if ubiquitous systems are capable of using as input relevant information about entities (e.g., people, places or objects) related to the application,they can provide services that are more appropriate,dynamic and optimized, increasing the user satisfac- tion and minimizing resource consumption, such as energy, processing, communication, among others. Such information is called context and represents the basic input element for context-aware computing. The goal of this short course is to discuss research trends on the ubiquitous context-aware field, presenting and analyzing the research performed on specific challenges. Such proposal presents interesting solutions to problems ranging from physical aspects of wireless communication to the design of applications available to the users. Resumo A computação ubíqua é um novo paradigma no qual dispositivos com capacidade de processamento e comunicação são embutidos nos elementos do dia-a-dia, provendo ser- viços de forma transparente aos usuários. Pode-se observar que esse tipo de computação possui forte ligação com as características do mundo físico, bem como aquelas apresen- tadas pelos perfis de seus usuários. Assim, caso um sistema ubíquo seja capaz de utilizar como entrada informaçõesrelevantes sobre as entidades (e.g., pessoas, lugares, objetos)

Upload: others

Post on 07-Oct-2020

4 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

Capítulo

3

Computação Ubíqua Ciente de Contexto: Desafiose Tendências

Antonio Alfredo Ferreira Loureiro, Ricardo Augusto Rabelo Oliveira , ThaisRegina de Moura Braga Silva, Waldir Ribeiro Pires Júnior, Lillian BrandãoRezende de Oliveira,Rande Arievilo Moreira,RafaelGuimarães Siqueira,BrunoPontes Soares Rocha,Linnyer Beatrys Ruiz

Abstract

Ubiquitous computing defines a new paradigm in which devices with processing and com-

munication capacity are embedded into everyday elements, providing services in a trans-

parent way to users. It is possible to notice that this kind of computing has a strong

connection with physical world features, as well as those presented by its users profi-

les. In this way, if ubiquitous systems are capable of using as input relevant information

about entities (e.g., people, places or objects) related to the application, they can provide

services that are more appropriate, dynamic and optimized, increasing the user satisfac-

tion and minimizing resource consumption, such as energy, processing, communication,

among others. Such information is called context and represents the basic input element

for context-aware computing. The goal of this short course is to discuss research trends

on the ubiquitous context-aware field, presenting and analyzing the research performed

on specific challenges. Such proposal presents interesting solutions to problems ranging

from physical aspects of wireless communication to the design of applications available

to the users.

Resumo

A computação ubíqua é um novo paradigma no qual dispositivos com capacidade de

processamento e comunicação são embutidos nos elementos do dia-a-dia, provendo ser-

viços de forma transparente aos usuários. Pode-se observar que esse tipo de computação

possui forte ligação com as características do mundo físico, bem como aquelas apresen-

tadas pelos perfis de seus usuários. Assim, caso um sistema ubíquo seja capaz de utilizar

como entrada informações relevantes sobre as entidades (e.g., pessoas, lugares, objetos)

Page 2: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

relacionadas à aplicação, os mesmos poderão prover serviços de maneira mais precisa,

dinâmica e otimizada, aumentando a satisfação dos usuários e minimizando o consumo

de recursos tais como energia, processamento, comunicação, entre outros. Tais infor-

mações são chamadas de contextos e representam o elemento básico de entrada para

a computação ciente de contexto. O objetivo deste minicurso é discutir tendências de

pesquisa na área da computação ubíqua ciente de contexto por meio da apresentação e

análise de trabalhos realizados sobre desafios específicos da área. Tais resultados apre-

sentam soluções interessantes para desafios que vão desde problemas relacionados com a

parte física da comunicação sem fio utilizada, até outros ligados às aplicações oferecidas

aos usuários.

3.1. Introdução

A computação ubíqua é caracterizada pela presença de dispositivos portáteis, cada vezmais comuns devido aos avanços na fabricação de componentes eletrônicos. Esses dis-positivos possuem uma considerável capacidade de processamento, com recursos paracomunicação sem fio e armazenamento de dados. Essa última característica permitiu ocrescimento do uso de equipamentos portáteis capazes de lidar com dados multimídia. Es-ses dispositivos se popularizaram como handhelds, PDAs, e, atualmente, têm aparecidocomo smartphones e celulares de grande capacidade computacional. Além das funciona-lidades originais, como capacidade de comunicação via telefonia celular, tais dispositivostambém possuem diversas funcionalidades e interfaces como GPS, rádio e TV, tocado-res de áudio e câmeras fotográficas digitais. Esses dispositivos vêm sendo usados emaplicações que envolvem indústria, medicina, uso pessoal, etc.

Uma das principais áreas de pesquisa dentro da computação ubíqua é a computa-ção ciente do contexto (context-awareness). A computação ciente ou sensível ao contexto(Context-Aware Computing) define uma área de pesquisa relativamente recente, que pos-sui aplicações em diferentes cenários computacionais e que apresenta desafios de imple-mentação importantes, os quais têm sido o alvo da atenção de pesquisadores provenientesde diferentes partes do mundo. A proposta desta área é, em linhas gerais, elaborar umamaneira de coletar para dispositivos computacionais, entradas capazes de refletir as condi-ções atuais do usuário, do ambiente no qual o mesmo se encontra e do próprio dispositivocomputacional utilizado, considerando tanto suas características de hardware, como tam-bém de software e de comunicação. Tais entradas são os chamados contextos. Váriospesquisadores publicaram trabalhos no início da década de 90, descrevendo definiçõespara o significado do termo contexto.

Dey et al [Dey (2001)] formalizaram a definição de contexto como sendo

“Qualquer informação que possa ser utilizada para caracterizar a situa-

ção de entidades (pessoa, lugar ou objeto) que sejam consideradas relevan-

tes para interação entre um usuário e uma aplicação (incluindo o usuário e

a aplicação)".

Essa é uma das definições mais aceitas e utilizadas atualmente por pesquisadoresda área, embora várias outras tenham sido propostas e discutidas. Pode-se observar que a

100 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 3: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

definição é bastante imparcial quanto aos tipos e variedades de dados que podem ser con-siderados como contextos, sendo ampla o suficiente para aceitar as diversas necessidadesespecíficas de cada aplicação. Além disso, os autores também não restringem as fontesde contextos possíveis de serem utilizadas, permitindo que tais dados reflitam a situaçãode qualquer entidade relevante para cada caso em particular. Finalmente é interessantenotar como os autores conseguem apresentar uma definição precisa para o termo, sem anecessidade de listar tipos ou classes específicas de contextos.

Embora os primeiros artigos na área de computação sensível ao contexto tenhamsido publicados no início da década de 90, essa área de pesquisa continua ainda hojebastante ativa. Possui muitas questões em aberto, as quais demandam intenso trabalhode pesquisa para que sejam amplamente entendidas, encontrando-se as melhores e maiseficiente técnicas e soluções relacionadas. A seguir estão listados alguns dos desafios depesquisa ainda existentes divididos em algumas sub-áreas:

• Sensoriamento: Escolha e inclusão dinâmica dos contextos mais apropriados a cadaaplicação; Técnicas para coleta de contextos físicos, lógicos e virtuais; Atribuiçãode semântica uniforme aos contextos utilizados; Identificação e escolha de fontesde contextos;

• Modelagem: Modelo de arquitetura para sistemas cientes de contexto; Modelo pararepresentação uniforme da sintaxe dos dados de contexto coletados; Modelo dearmazenamento de dados contextuais; Modelo de comunicação adotado entre di-versos usuários ou aplicações;

• Qualidade: Qualidade de contexto (QoC); Qualidade de serviço (QoS); Qualidadedas fontes de contexto; Gerenciamento de aplicações cientes de contexto; Trata-mento de falhas; Automatização de tarefas; Utilização de algoritmos de aprendi-zado; Identificação e tratamento de contextos individuais conflitantes; Identificaçãoe tratamento de contextos coletivos conflitantes;

• Segurança: Segurança para troca de dados entre usuários e aplicações; Confiabili-dade das fontes de contextos; Segurança da Informação de contexto;

Existem publicados na literatura vários trabalhos descrevendo diferentes aplica-ções para a computação ciente de contexto. A seguir estão listadas algumas das principaisideias de aplicações desse tipo. No entanto muitas outras ainda podem ser elaboradas,visto que essa é uma área com potencial para ser aplicada em diversos e diferentes aspec-tos.

Uma das mais citadas aplicações cientes de contexto está relacionada ao turismo.O trabalho de Cheverst et al [Cheverst et al. (2000)] é um dentre vários que descrevemcomo utilizar elementos de contexto para tornar a experiência de turistas mais simples,personalizada e rica de informações e detalhes. Em particular, o trabalho citado apre-senta uma plataforma chamada GUIDE, construída para atender a demandas específicasde turistas que viajam para conhecer cidades diferentes. Os requisitos para a ferramenta,tais como flexibilidade, uso de informações sensíveis ao contexto, suporte para informa-ções dinâmicas e serviços interativos, foram obtidos com especialistas na área de turismo.

Livro Texto dos Minicursos 101

Page 4: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

O sistema combina tecnologias de computação móvel com uma estrutura de rede semfio para apresentar aos visitantes informações adaptadas aos seus contextos pessoais eambientais. Testes foram realizados por meio de utilização do sistema proposto por espe-cialistas e também por usuários em potencial. O objetivo principal dos testes era revelaro grau de usabilidade do sistema, bem como pontos em que melhorias diversas deveriamser realizadas.

Schilit et al [Schilit & Theimer (1994)] descrevem o “Active Map Service", umaaplicação que mantém clientes informados sobre mudanças em seus ambientes. Mapasativos descrevem a localização e as características de objetos dentro de alguma região en-quanto os mesmos se modificam com o passar do tempo. Um aspecto importante, tratadocom cuidado pelos autores do trabalho, é a questão de escala: mapas ativos devem trataratualizações e consultas sobre regiões suficientemente grandes para satisfazer o interessede clientes, assim como deve tratar picos de carga em regiões com intensa movimentaçãode usuários. Além disso, a solução proposta faz uso de endereçamentos e roteamentosmulticast, uma vez que detecta grupos de usuários com interesses por atualizações co-muns. Para garantir que não haverá sobrecarga nos canais de localização, provê limitesgarantidos no uso da largura de banda disponível.

Embora possa ser utilizada por qualquer aplicação computacional para a qual sejarelevante, o uso da sensibilidade ao contexto é especialmente importante para uma áreaem particular: a computação ubíqua e pervasiva. Este tipo de computação define umanova maneira de relacionar usuários humanos e dispositivos computacionais. Essa é umaárea recente de pesquisa que prevê a disponibilização de computação e comunicação semfio o tempo todo e em todo lugar, permitindo que tais capacidades sejam incorporadas aelementos do dia-a-dia e utilizadas de maneira transparente [Greenfield (2006)].

Especificamente, a mobilidade permitida aos usuários e seus objetos computacio-nais em aplicações ubíquas, faz com que o uso de contexto seja ainda mais importante. Ascaracterísticas utilizadas como entradas em tais soluções poderão se modificar a qualquerinstante, e essa informação é crucial para que os melhores serviços sejam oferecidos aosusuários. Tais modificações podem ser observadas em situações nas quais o próprio usuá-rio se movimenta de um local para outro, modificando-se assim as condições do ambientecorrente em variados aspectos (condições físicas, recursos físicos disponíveis, recursoscomputacionais disponíveis, fontes de contexto, conectividade, dentre outros) ou aindaquando outros usuários e/ou recursos se movimentam para dentro e para fora da área deinteresse da aplicação. Interessante notar portanto o aspecto dinâmico do ambiente dasaplicações, o qual faz da computação ciente de contexto uma aliada importante para omelhor funcionamento dos sistemas ubíquos. A restrição de recursos disponíveis paraexecução das aplicações é outro fator importante a ser considerado, sendo bastante afe-tado pela característica dinâmica das aplicações ubíquas e pervasivas. Uma vez que osrecursos e serviços disponibilizados para os usuários se modificam ao longo do tempo,e os dispositivos utilizados são em geral pequenos, com poucas capacidades computaci-onais, de energia e memória, os sistemas desse tipo devem realizar um gerenciamentode recursos consistente de maneira a prolongar o tempo de vida da aplicação, mantendoos níveis de qualidade de serviço desejados pelos usuários. O uso de contextos é maisuma vez importante de ser utilizado como forma de manter as aplicações conscientes dosrecursos disponíveis e demandados. Eles serão usados como entradas por algoritmos de

102 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 5: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

gerenciamento, capazes de comparar e escolher o que precisa e o que pode ser feito paraos usuários.

O objetivo deste minicurso é apresentar o estado da arte na pesquisa em algunscampos da pesquisa usando o computação ciente do contexto. A seção 3.2 apresentadois trabalhos sobre a identificação de fontes de contextos e duas técnicas de aquisiçãode dados contextuais através da análise do sinal de rádio usado na comunicação semfio. A seção 3.3 mostra a caracterização do usuário de dispositivos móveis através deperfis. A seção 3.4 propõe um sistema de a notificação de eventos para dispositivosmóveisbaseado no perfil e contextos do usuário. A seção 3.5 lida com o conceito de contextoscoletivos, em situações nas quais os contextos dos diferentes usuários são discordantesou incompatíveis entre si e/ou com o ambiente a ser adaptado e é necessário lidar comos problemas relacionados de maneira a maximizar a satisfação individual e coletiva dosusuários. A seção 3.6 aborda a segurança em dois tópicos, sobre confiabilidade dos dadoscompartilhados e a seleção adaptativa de protocolos de segurança. Por fim, a seção 3.7possui os comentários finais sobre o tema de pesquisa abordado.

3.2. Aquisição de Dados Contextuais

A identificação de fontes de contextos no ambiente, bem como a coleta dos dados con-textuais por parte dos dispositivos ubíquos são tarefas importantes em sistemas ubíquoscientes de contexto. Cada tipo de dado contextual a ser utilizado apresenta seus própriosdesafios de aquisição, processamento, co-relação com outros dados, verificação de quali-dade, definição de sintaxe, associação semântica, dentre outros aspectos. Em particular,essa seção descreverá trabalhos que propõe soluções para aquisição de dois tipos de con-textos importantes e frequentemente utilizados pelas aplicações: a qualidade do canal decomunicação sem fio e a localização.

• Sistema de Posicionamento Híbrido e Ubíquo para Dispositivos Móveis: Um sis-tema de posicionamento é uma ferramenta usada para determinar e registrar a loca-lização de um objeto na superfície da Terra. Existem sistemas de posicionamentopara ambientes internos e externos, alguns operam apenas em áreas delimitadasenquanto outros operam sobre toda a superfície do globo. Seu funcionamento, nor-malmente, se baseia na captura de sinais, de rádio, infra-vermelho ou de satélites,para determinar a posição de um dispositivo, de acordo com algum referencial ousistema de coordenadas. O objetivo dessa seção é desenvolver um sistema de posi-cionamento híbrido e ubíquo para dispositivos móveis. Um sistema é caracterizadocomo híbrido quando apresenta uma mistura de tecnologias diferentes, nesse caso,o uso dos sinais de celular, redes sem fio e GPS(Global Positioning System), para in-ferir a posição do dispositivo. A ubiquidade do sistema está no fato de que o mesmodeverá proporcionar informação contínua de posição, alternando entre os sinais uti-lizados, para obter localização em ambientes internos e externos, mesmo que cadatecnologia utilizada proporcione uma precisão diferente no posicionamento do dis-positivo.

• Identificação de Eventos no Canal de Comunicação em Redes IEEE 802.11: A qua-lidade da comunicação em sistemas de comunicação sem fio depende de diversosfatores e ajustar e/ou alertar o usuário sobre as condições da rede é um importante

Livro Texto dos Minicursos 103

Page 6: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

serviço para este tipo de dispositivos. A qualidade percebida pelo usuário dependedo contexto de rede, o qual pode ser definido como os eventos que possuem um im-pacto significativo na comunicação sem fio. A identificação do comportamento docanal de comunicação é necessária para obter a descrição deste contexto. Devido àscaracterísticas intrínsecas da propagação do sinal transmitido, é difícil medir e infe-rir o contexto básico das redes sem fio, como por exemplo, predizer quando a baixaqualidade do sinal de rádio é causada por interferência ou efeitos de atenuação de-vido ao ambiente da comunicação. Essa sub-seção apresenta um novo método parao gerenciamento centrado no usuário em redes sem fio que usam o padrão IEEE802.11b/g, determinando a presença de mobilidade e interferência na comunicação.O método usa dois gráficos de controle estatístico, MCEWMA (Moving Centerline

Exponential Weighted Moving Average) e o MCEWMV (Moving Centerline Expo-

nential Weighted Moving Variance), associados com a análise de resolução múltiplacom a transformada de wavelets [Hansen & Meno (1977), Judd et al. (2008)].

3.2.1. Sistema de Posicionamento Híbrido e Ubíquo para Dispositivos Móveis

Um sistema de posicionamento é uma ferramenta usada para determinar e registrar a lo-calização de um objeto na superfície da Terra. Existem sistemas de posicionamento paraambientes internos [Priddge (2000), Kaemarungsi & Krishnamurthy (2004), Hightower& Borriello (2001), Bahl & Padmanabhan (2000)] e externos [Hightower & Borriello(2001), Haeberlen et al. (2005), Cheng et al. (2005)], alguns operam apenas em áreas de-limitadas [Priddge (2000), Kaemarungsi & Krishnamurthy (2004), Bahl & Padmanabhan(2000)] enquanto outros operam sobre toda a superfície do globo [Dittmer (2005)]. Seufuncionamento, normalmente, se baseia na captura de sinais, de rádio, infra-vermelho oude satélites, para determinar a posição de um dispositivo, de acordo com algum referencialou sistema de coordenadas.

Muitos dispositivos móveis mais recentes já possuem capacidade de posiciona-mento através do Global Positioning System (GPS) [Dittmer (2005)], porém, o funcio-namento correto do mesmo está praticamente restrito a ambientes externos pois não épossível receber o sinal dos satélites quando dentro de alguma construção ou com visi-bilidade reduzida do céu [Dittmer (2005)]. Devido à essa limitação do GPS e ao fato degrande parte dos dispositivos ainda não serem compatíveis com o sistema GPS, torna-sejustificável a implementação de um Wireless Positioning System (WPS). Esse sistemautilizará a densa malha de redes sem fio dos padrões IEEE 802.11b e 802.11g já insta-ladas nas cidades para prover informações de posição. Também deverá funcionar dentrode construções e exigir pouco ajuste, ao contrário de alguns sistemas de localização paraambientes internos [Priddge (2000)] e [Kaemarungsi & Krishnamurthy (2004)].

3.2.1.1. Estado da arte

A primeira iniciativa conhecida de uso de sinal Wi-Fi como sinal de localização é o pro-jeto [Bahl & Padmanabhan (2000)], que registrava impressões digitais de sinais de redesWi-Fi para determinar a posição de um dispositivo dentro de uma construção. A partirdesse trabalho, surgiram outras tentativas de se determinar a posição de dispositivos uti-lizando sinais de Wi-Fi, e mais recentemente, essas iniciativas passaram a tentar mapear

104 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 7: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

ambientes externos desde campi de universidades, bairros e até cidades inteiras.

O número de algoritmos de posicionamento aplicáveis é bem menor quando sedesconhece a real posição dos pontos de acesso da rede, uma vez que muitos se baseiamem métodos probabilísticos [Haeberlen et al. (2005)], e requerem um grande volume deinformações que não podem ser obtidos nesse caso.

Com a posição dos pontos de acesso desconhecida existe um projeto da Intel cha-mado Placelab que comparou três algoritmos de posicionamento ao mapear três bair-ros com características diferentes em cidades distintas dos Estados Unidos [Cheng et al.(2005)].

Dentre os sistemas de posicionamento implementados para dispositivos móveisespecificamente, podemos citar o [Ericsson (n.d.)], que utiliza informações de sinais decelular GSM [GSMWORLD (n.d.)], para prover informação de posição, porém com umaprecisão menor do que no caso de um WPS. Mas principalmente, podemos citar o [Na-vizon (n.d.)], que utiliza informações de GPS, WPS e de redes de celular para proverinformações de posição. Seu funcionamento está praticamente restrito aos Estados Uni-dos, porém a idéia de utilizar as três abordagens em um mesmo sistema é relevante econstituiu um dos objetivos deste trabalho.

Outro desafio deste projeto foi o mapeamento da região amostral, já que o fun-cionamento do algoritmo está aliado a esses mapas. A ideia é um mapeamento cola-borativo, pelo uso de aparelhos que possuam dispositivos de GPS e um servidor paraarmazenamento e sincronização dos mapas. Para tal, foi implementado um cliente cujofuncionamento é transparente e não influencia no uso normal do aparelho. Parte do tra-balho [Akella et al. (2007)] consistiu em comprovar que a criação de um número imensode redes sem fio, não-planejadas e não-gerenciadas, gerou um ambiente caótico, no qualpraticamente toda rede sem fio sofre interferência de outra. Além disso, o artigo tambémexplicita interferências de outras tecnologias sem fio, como telefonia celular ou Bluetooth,que afetam os valores de intensidade de sinal no momento da medição, assim como fato-res climáticos e outros praticamente desconhecidos. Por essas razões, também é de sumaimportância que o mapeamento filtre alguns resultados de pouca confiabilidade devido àocorrência de interferências.

3.2.1.2. Desenvolvimento

Depois de uma revisão da bibliografia mencionada sobre sistemas de posicionamento, foinecessário um estudo prévio de detalhes de implementação da plataforma Android, de-vido a algumas peculiaridades acerca da programação para esta plataforma. Em seguida,a primeira etapa da implementação, que corresponde ao cliente de mapeamento, pôde serdesenvolvida. Essa aplicação basicamente coleta as seguintes informações em cada pontomapeado através de coordenadas de GPS, redes Wi-fi detectadas naquele ponto, principal-mente endereço Mac, Received Signal Strength Indicator (RSSI) e informações de célulade celular, principalmenteMobile Country Code (MCC), Mobile Network Code (MNC) eCell Tower ID (CID);

Além dessas informações, uma parte importante da aplicação é a inserção de mar-

Livro Texto dos Minicursos 105

Page 8: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

cadores que em conjunto representam a localização simbólica de um conjunto de pontos,como por exemplo: país - estado - cidade - bairro - estabelecimento. O cliente devepossibilitar a inserção e remoção desses marcadores, que junto com as informações deambiente, citadas anteriormente, representam a "impressão digital"de determinado ponto,e que será usada para o posicionamento, posteriormente. A Figura 3.1 mostra o emuladordo Android executando o cliente de mapeamento.

Figura 3.1. Cliente de Mapeamento

Após construídos os mapas, o cliente de mapeamento os submete para o servidor,quando o usuário utilizar a funcionalidade Submit Scan. A interface do servidor respon-sável por esta operação de submissão e armazenamento dos mapas, foi a segunda etapade implementação. Ao receber os mapas de um cliente, o servidor deve armazená-los deforma que possam ser encontrados facilmente, quando for necessário consultá-los. Paralimitar o espaço de busca do algoritmo de posicionamento, foi utilizada uma combinaçãoentre o MNC, MCC e o CID, que é única para qualquer célula GSM no mundo, paraindexar os arquivos de mapas. Nesse momento, o servidor também deve atualizar umarepresentação gráfica de todos os mapas já coletados, que utiliza sobreposição de mapase uma API do Google Maps [Google (n.d.)], para a representação dos mapas. A Figura3.2 demonstra a representação em tempo real dos pontos mapeados ao redor do Institutode Ciências Exatas (ICEX) da Universidade Federal de Minas Gerais (UFMG):

A próxima etapa no desenvolvimento do sistema é a implementação do clientede posicionamento. Ele basicamente interage com o servidor, enviando as informaçõesdo ambiente onde se encontra, para depois receber as informações de posição, calcula-das pelo servidor. Depois de receber suas informações de localização, o cliente desenhasua posição em um mapa, utilizando funcionalidades integradas na própria plataformaAndroid para realizar sobreposição de mapas. A Figura 3.3 e 3.4 mostram o cliente deposicionamento em execução no emulador.

Finalmente, a última etapa do desenvolvimento é a implementação da interfacedo servidor que trata as requisições de posição do cliente de posicionamento. Ao rece-ber uma requisição, o servidor executa um algoritmo que atribui pontos e pesos, paraos pontos mapeados, de acordo com a similaridade com os dados de ambiente, enviadospelo cliente na requisição de posição. Baseado na soma dessas pontuações, ele determina

106 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 9: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

Figura 3.2. Mapas em tempo realFigura 3.3. Cliente de

Posicionamento

qual o ponto de maior probabilidade de representar a posição atual do dispositivo e re-torna as coordenadas e posição simbólica para o cliente, que por sua vez as exibe na tela,como visto na Figura 3.4. O servidor também registra a posição do dispositivo através dasobreposição de mapas, como pode ser visto na Figura 3.5.

Após essas etapas de desenvolvimento, o sistema de posicionamento já é capaz demanter o mapeamento colaborativo funcional e sempre atualizado e inferir posições paraos dispositivos que as requisitarem. Os testes realizados são descritos na seção seguinte.

3.2.1.3. Resultados

O funcionamento do sistema é aliado ao mapeamento prévio da área sobre a qual o mesmodeve operar. Como área para testes preliminares, optou-se por mapear as redes sem fio aoredor do prédio do ICEX, no campus da UFMG. Comprovou-se que esta era uma regiãoboa para a realização dos testes, devido à densidade de pontos de acesso nessa área, o quecontribui para a precisão do sistema.

O processo de testes do sistema foi prejudicado pela falta de um dispositivo reale portátil que executasse o sistema operacional Android, porque as informações de redessem fio, sinais de celular e GPS não podiam ser obtidas diretamente através do emulador.Foram realizados alguns testes preliminares de precisão para o sistema, representados naTabela 3.1:

Em 88% dos casos o sistema retornou como posição para o dispositivo o ponto querepresentava aquele mais próximo de sua posição real. Em 8% dos casos ele retornou umponto imediatamente vizinho, o que representa um erro de aproximadamente 10 metrospara a densidade de pontos do mapeamento usada. Outros dois testes encontraram umaprecisão menor do que a de 10 metros, porém em nenhum dos casos o erro superou os40 metros. As variações na precisão do sistema são observadas porque existem pontos no

Livro Texto dos Minicursos 107

Page 10: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

Figura 3.4. Sobreposi-

ção de mapas no cliente

Figura 3.5. Posição

de um dispositivo em

tempo real

Número de testes Erro (em número de pontos de distância)44 04 11 21 3

Tabela 3.1. Testes preliminares de precisão do sistema

mapeamento, nos quais os pontos de acesso detectados são os mesmos de outros pontos,e as medidas de intensidade de sinal durante o mapeamento foram diferentes das obtidasdurante os testes de posicionamento, o que é provocado por interferências diversas, e atéfatores climáticos.

3.2.2. Identificação de Eventos no Canal de Comunicação em Redes IEEE 802.11

A comunicação ubíqua tem como objetivo permitir o acesso à informações, serviços eaplicações em qualquer lugar e a qualquer momento. Sua utilização deve prover o usuá-rio com acesso permanente à uma rede fixa ou móvel independentemente de sua posiçãofísica. Dispositivos móveis com várias interfaces de rede para acesso a diferentes tecno-logias de rede sem fio estão cada vez mais populares e isso introduz a flexibilidade daseleção e acesso aos diferentes tipos de redes. Das tecnologias de redes sem fio pode-seidentificar as redes da telefonia celular, como por exemplo: GPRS, UMTS, CDMA2000;as redes sem fio metropolitanas, definidas pelo padrão IEEE 802.16; e as redes sem fiolocais, definidas no IEEE 802.11. Um usuário portando um smartphone com diferentesinterfaces de rede pode usar as conexões disponíveis que melhor atendam a sua demanda.

Uma vez conectado, o usuário utiliza os serviços disponíveis, mas a maneira como

108 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 11: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

é atendido depende de diversos fatores, que não são encontrados na comunicação comfio. Por exemplo, a variação do nível do sinal recebido que causam perdas de dados emudanças continuas na velocidade das interfaces de rede sem fio. Somado a isso, osdispositivos possuem restrições com relação ao consumo de energia. O resultado final sãonovos requisitos para o funcionamento adequado das aplicações. Dadas essas diferençasna comunicação da rede com fio, o desenvolvimento de aplicações deve ser feito com focoem atender esses requisitos. Para isso, as informações do ambiente da comunicação sãoessenciais.

3.2.2.1. Motivação

Para classificar a qualidade da comunicação, primeiro é necessário identificar as métricaspara medir e qual o tipo de impacto que o ambiente de comunicação sem fio causa sobreela. Essas métricas descrevem a relação entre o nível de energia do sinal recebido e aintegridade dos dados transmitidos. As variações na qualidade da comunicação possuemdiferentes impactos sobre o desempenho da aplicação, pois as interfaces de rede sem fiopossuem variadas estratégias para lidar com os quadros perdidos. As seguintes métricasidentificam esses efeitos:

Vazão Ideal: a velocidade máxima do modem utilizado pela interface de rede sem fio,medida em MBps, selecionado de acordo com o canal de comunicação. Cada in-terface de rede sem fio possui um conjunto de modems, que são selecionados deacordo com as características do ambiente da comunicação;

Vazão Efetiva: a vazão dos dados efetiva percebida pela aplicação durante a comunica-ção, medida em MBps. Este leva em conta a sobrecarga causada pelas retransmis-sões dos quadros e das mensagens de controle dos protocolos de rede, assim comoa mudança do modem utilizado;

Atraso: medida do impacto causado pelas sucessivas retransmissões e as mudanças nasinterfaces de rede sem fio, como por exemplo a escolha dos modems, falhas derecebimentos de quadros e etc.;

Variação no atraso: variação do atraso, que é associada a diferentes atrasos, geradospela variabilidade presente na comunicação sem fio. A variação de atraso aumentaquando existe uma grande variabilidade na qualidade da comunicação.

Aqui define-se o conceito de contexto da comunicação. Este contexto é compostopelo ambiente no qual receptor e transmissor se encontram e por suas interfaces de redesem fio do padrão IEEE 802.11 usadas para a comunicação. Esse ambiente pode ser des-crito pelos impactos que são causados no sinal recebido na interface de rede sem fio du-rante a comunicação. As interfaces de rede sem fio possuem parâmetros e programaçõesinternas que reconfiguram seu funcionamento automaticamente, em resposta ao ambiente.Por exemplo, a especificação do IEEE 802.11 deixa a cargo do fabricante da interface derede a escolha do algoritmo de seleção de velocidade. A escolha da velocidade pode serfeita com o objetivo de manter a comunicação ativa, pois velocidades menores permitem

Livro Texto dos Minicursos 109

Page 12: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

o funcionamento da interface em modo mais robustos, que suportam melhor as variaçõesno sinal. Em outras situações, a velocidade maior pode ser preferida em detrimento dapermanência da conexão.

A otimização da qualidade da comunicação numa rede sem fio é essencial paraa melhoria do desempenho das aplicações que usam a comunicação ubíqua. Dentre asestratégias usadas para tal, a adaptação é o elemento central. A implementação das es-tratégias adaptativas pode ocorrer em diversos níveis, sobre os dados transmitidos, sobrealguma funcionalidade da aplicação ou na reconfiguração da interface de rede sem fio. Asestratégias envolvidas, podem ser, por exemplo, a escolha de algoritmos adequados paraa compressão dos dados, o uso de diferentes algoritmos nas aplicações dependendo dascondições da comunicação e o ajuste do funcionamento da placa de rede sem fio.

Dispositivos que utilizam outras interfaces ou a presença de muitas redes sem fionas proximidades são fontes de interferência. Os próprios objetos presentes no ambienteonde a comunicação acontece afetam as características da comunicação. A mobilidadedos dispositivos expõe as interfaces à diferentes efeitos de propagação e atenuação dosinal. Contudo, é muito difícil inferir a partir do sinal recebido, quando a queda na qua-lidade se deve à interferência ou à mobilidade. A informação sobre o contexto da co-municação é essencial para uma adaptação da mesma, no intuito de se atingir o melhordesempenho das aplicações.

A descrição do contexto da comunicação é um fator importante para se atingiruma boa qualidade na comunicação. Neste caso, a Figura 3.6(a) mostra a situação inicial,no qual o usuário está próximo ao ponto de acesso se comunicando a uma velocidade de11MBps. Os círculos verdes mostram a potência do sinal, a cor mais escura indica maisenergia e a mais clara, menos energia. O deslocamento do usuário para longe do pontode acesso causa uma queda de velocidade de comunicação, devido à variação deste sinal,como mostrado na Figura 3.6(b). Em situações como essa, a Figura 3.6(c) mostra umaestratégia de melhoria que pode ser feita: aumentar da potência da antena do ponto deacesso, de maneira que o usuário continue sendo atendido com uma velocidade adequada.

Mas caso a perda de velocidade seja causada por uma interferência, a mesma es-tratégia de adaptação pode causar resultados adversos. A Figura 3.7 mostra este cenário,onde um usuário se encontra no alcance de dois pontos de acesso e estabelece a comu-nicação com um deles. O sinal que chega sobre este usuário é a soma do sinal oriundodos dois pontos de acesso. Neste caso, como não está conectado ao segundo ponto deacesso, o usuário não pode evitar a interferência causada, como é mostrado na Figura3.7(a). A Figura 3.7(b) mostra o impacto da presença de interferência na velocidade decomunicação, a qual diminui devido às sucessivas perdas. Caso não seja identificado queesta diminuição de velocidade é causada pela interferência, a Figura 3.7(c) mostra que amesma estratégia adotada na solução anterior pode gerar mais interferência, acarretandoem problemas de comunicação em outros elementos na rede.

A importância de conhecer os efeitos destes eventos é acentuada pela necessidadede identificar quando a interface de rede sem fio pode mudar seus modos de funciona-mento, possibilitando assim para melhor lidar com essas situações limite. Quando a inter-face identifica uma qualidade ruim do sinal recebido, ela aciona o algoritmo que escolhea velocidade, modificando a vazão ideal. Esta mudança causa um impacto também na

110 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 13: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

(a) Usuário próximo ao ponto de acesso. (b) Deslocamento para longe do ponto deacesso, queda de velocidade.

(c) Aumento da potência de transmissão, re-cuperação da velocidade.

Figura 3.6. Adaptação da potência da antena do ponto de acesso

(a) Usuário em região sob efeito de interferên-cia.

(b) Queda na velocidade devido a erros de co-municação causados pela interferência

(c) Aumento da potência de transmissão, inter-ferência causa perda de conexão em outros ele-mentos .

Figura 3.7. Adaptação da potência da antena do ponto de acesso.

vazão efetiva e no atraso presente. Em ambientes com muita interferência, esse algoritmopode ser ativado diversas vezes, ocasionando mais mudanças nos modems e aumentandocom isso a variação do atraso. Em ambientes com mobilidade, e sem interferência, essaescolha dos modems pode mudar de maneira gradual, com a velocidade diminuindo pro-porcionalmente ao deslocamento. De posse dessa informação, os usuários e as aplicaçõespodem adaptar a interface, de maneira a melhorar essa vazão, como por exemplo, aumen-tar da potência de transmissão em situações de deslocamento. A decisão adequada develevar em conta as restrições dos dispositivos e os requisitos da aplicação.

Livro Texto dos Minicursos 111

Page 14: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

Para auxiliar na identificação da estratégia correta de adaptação, neste ponto sãodefinidos os eventos do contexto da comunicação. Esses eventos são a presença de mo-bilidade e de interferência, de maneira não exclusiva, no contexto da comunicação. Adistinção destes eventos se faz necessária por causa das possíveis estratégias a serem ado-tadas na melhoria da comunicação.

A justificativa em se utilizar somente a variação do sinal para a detecção da movi-mentação é devido ao fato que existe uma relação direta entre essa variação e a qualidadeda comunicação percebida pelas aplicações. Além disso, nem todo sistema computacionalé dotado de ferramentas de localização. Por exemplo, considerando somente a variaçãodo sinal, existem situações onde tal movimentação não efetua nenhum impacto. O impor-tante para este trabalho é identificar que a variação do sinal pode ser associada a algumtipo de movimentação e que não seja não relacionada com a presença de interferência.Assim como, na presença de interferência ou de mobilidade, as respectivas variações dosinal sejam identificadas.

Para uma identificação mais precisa destes eventos, é considerado o ambiente decomunicação interno, no qual a velocidade de deslocamento entre o receptor e o trans-missor é limitada e as fontes de interferência são as mais comuns de se encontrar em umambiente interno. Apesar desta restrição, que se faz essencial nessa caracterização, este éo cenário mais comum de utilização das redes sem fio do padrão IEEE 802.11.

No sentido de melhorar a tomada de decisão de tais mecanismos, esta tese forneceum mecanismo que permite distinguir em tempo real e com alta precisão eventos de mo-bilidade e interferência a partir do monitoramento constante dos valores de sinal medidona interface.

3.2.2.2. Propagação de sinais

A partir da visão geral da física de propagação em ambientes sem fio, a comunicação édescrita como dependente da separação que existe entre o transmissor e o receptor. Essaseparação pode ser associada à distância, à velocidade de deslocamento, às característicasdo ambiente da comunicação e às fontes de interferência. O sinal transmitido chega aoreceptor como uma ou mais ondas que foram afetadas pelos efeitos de propagação no am-biente, sendo este fenômeno conhecido como multipath. Dessa maneira, essas ondas sãocomponentes que formam o sinal recebido. Se não existirem obstáculos entre o receptore o transmissor, algumas dessas ondas serão consideradas como principais na transmis-são, somadas com as outras geradas pelos efeitos da reflexão, dispersão e refração. Essesefeitos podem causar mudanças de fase e atenuações em cada componente. A Figura3.8 ilustra este cenário. Considerando um transmissor e um receptor separados por umadistância d em um instante de tempo t ′, as ondas de sinal emitidas percorrem diferentescaminhos e o resultado final que chegam no receptor é um somatório destas ondas.

112 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 15: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

Figura 3.8. Múltiplos caminhos da propagação da onda transmitida

3.2.2.3. Interferência

Considerando um transmissor e um receptor, que utilizam a interface de rede IEEE 802.11,é possível dividir as fontes de interferência em dois grupos. O primeiro é o das interfe-rências geradas por outros elementos de rede que também usam a interface IEEE 802.11,mas não estão participando diretamente da comunicação. O segundo são aparelhos co-muns que também trabalham na faixa de freqüência ISM usada pelo IEEE 802.11.

Em relação ao primeiro grupo é possível identificar as seguintes interferências:

• Co-canal: ocorre no momento em que outros elementos fisicamente próximos uti-lizam canais adjacentes e possuem uma potência de transmissão elevada, causandointerferência. A recomendação do próprio padrão para esse caso é o uso de canaisque não se sobrepõem, como os canais 3, 6 ou 11;

• Direta: ocorre quando outros elementos não conhecidos utilizam o mesmo canalde comunicação. Por exemplo, vizinhos que utilizam o mesmo canal em sua redesem fio doméstica. Dada a grande popularidade do IEEE 802.11 é um caso comum.

Considerando o contexto de redes internas em casas e escritórios, sobre o segundogrupo, é possível identificar as seguintes fontes de interferência:

• Telefones sem fio: Trabalham na faixa de freqüência de 2.4GHz e 5.4GHz. Suaprincipal característica é o uso constante do canal de transmissão, para manter aqualidade da comunicação de voz, e da alta potência, já que o alcance de uso é umadas principais características deste tipo de aparelho;

• Bluetooth: Este padrão tem se tornado cada vez mais popular, presente em mui-tos dispositivos portáteis. Ele não possui grande potência de transmissão, uma vezque tem o foco em economizar energia e utiliza uma técnica de envio com saltode freqüência, trocando os canais de uso a uma taxa de aproximadamente 3200ms,para minimizar o uso de canais que sofrem interferência. Em contrapartida, a inter-ferência que causa sobre o IEEE 802.11 já é bem conhecida, como visto em [Pun-noose et al. (2001)] e [Jung-Hyuck & Jayant (2003)];

Livro Texto dos Minicursos 113

Page 16: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

• Microondas: Outro elemento relativamente comum em ambientes internos é oforno de microondas, que possui uma margem de fuga de energia, a qual interferenas interfaces IEEE 802.11 que se encontram próximas a estes aparelhos.

3.2.2.4. Qualidade da Comunicação

Define-se qualidade da comunicação em uma interface de rede IEEE 802.11 como a rela-ção da quantidade de bits alterados ao comparar o quadro transmitido e o mesmo quadrorecebido. O quadro transmitido é uma seqüência de bits que compõe os dados, o cabeça-lho e o preâmbulo enviados pelo transmissor e o quadro recebido é a seqüência recebidano receptor. Este quadro recebido pode ser alterado pelos efeitos que atuam sobre o sinal,descritos na seção 3.2.2.2. Uma boa qualidade de comunicação é descrita como o casoonde os efeitos do canal não afetem o quadro recebido, ficando este o mais próximo doquadro que foi enviado.

Neste trabalho, para se inferir essa qualidade é usada a medida do RSSI – ReceiverSignal Strength Indicator – que mede a intensidade do sinal do último quadro recebido.Esse valor é mensurado no preâmbulo do quadro e indica a quantidade de energia presentena interface. Esse valor pode ser recuperado acessando funções específicas do driver dodispositivo.

3.2.2.5. Identificação de eventos

Ométodo de identificação de eventos efetua a análise sobre os dados amostrados na placade rede sem fio. Essas amostras das medidas do RSSI são uma janela de dez medidasconsecutivas, espaçadas com um intervalo de tempo de 10ms. A série temporal quedescreve o canal de comunicação sem fio é não-linear, não gaussiana e não estacionária.A Figura 3.9 mostra todas as etapas envolvidas no processo.

Figura 3.9. Metodologia de identificação

Essas características foram consideradas no modelo de maneira a fazer viável adescrição da assimetria forte entre as amostras e as variações da média e da dispersão. Acomplexidade da série temporal prevê o uso de modelos simples de previsão, justificando

114 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 17: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

o uso das estratégias de médias móveis exponenciais nos gráficos de controle (os gráficosde controle clássicos utilizam modelos mais simples e menos expressivos). Também, cabenotar que a variabilidade e assimetria são melhor caracterizados pela análise de multi-resolução. Dessa forma, o uso conjunto dos dois métodos é justificado pelos seguintespontos:

• Análise Temporal: O gráfico de controle MCEWMA identifica eventos fora de con-trole que aparecem na média das amostras das medidas de RSSI e o gráfico decontrole MCEWMV identifica as situações fora de controle sobre a variância. Uti-lizando esses gráficos de controle, o controle estatístico de processos permite ainvestigação da amplitude do sinal identificando tendências de situações fora decontrole. Mas a informação sobre a variabilidade entre as diferentes amostras dasmedidas de RSSI não são totalmente identificadas, sendo necessário uma análiseespectral entre essas medidas;

• Análise Espectral: A transformada de wavelets permite identificar a variabilidadede um conjunto de amostras sucessivas das medidas de RSSI. Aplicada sobre os da-dos suavizados na saída do MCEWMA, o resultado da transformada é usado paradescrever a variabilidade entre as diferentes amostras. A transformada é aplicadasobre as medidas suavizadas e não sobre as medidas para evitar o ruído presentenas medidas. O ruído e a amplitude do sinal são verificados pelos gráficos de con-trole. Relaciona a variabilidade das medidas. Descreve as frequências presentes emcada janela δ t. Numa janela δ t, níveis maiores indicam um transiente relativo amobilidade. Níveis menores indicam presença de interferência

A partir dos vetores gerados pelos gráficos de controle, xε , suε e slε , associadoscom o escalograma e a identificação do módulo feitos na análise de wavelets, armazena-dos nos vetores E e M, é possível identificar o comportamento da série temporal e comisso associar este comportamento aos eventos presentes no ambiente da rede sem fio.

Com esta informação, e após uma série de testes, feitos para garantir um intervalode confiança de 95%, a informação dos eventos foi usada para criar a Tabela 3.2. Estatabela enumera os eventos, associados com interferência e mobilidade e apresenta a des-crição. Esta informação é utilizada para mostrar ao usuário a descrição no momento queé feita a identificação de cada evento.

3.2.2.6. Identificação de Eventos

Estes testes foram conduzidos em um ambiente interno de uma casa, considerando ocenário de baixa densidade de usuários e uma distribuição não planejada de pontos deacesso na vizinhança. Associado a isso, foram utilizados telefones sem fio e dispositivosBluetooth como fonte de interferência.

Toda a mobilidade foi feita em aproximadamente 0.5m/s, uma velocidade parauma pessoa andando e usando um dispositivo móvel (a noção de mobilidade humanaainda é um tópico para pesquisas; como pode ser visto em, González et al. 2008).

Livro Texto dos Minicursos 115

Page 18: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

Tabela 3.2. Classificação de Eventos

Evento Detectado Descrição

1 Perda de Conexão2 Perda de Conexão devido Interferência3 Aproximando do AP4 Interferência Fraca5 Afastando do AP6 Interferência Média7 Movendo8 Interferência Forte

Em todos os gráficos, cada experimento foi feito com a duração de 300 seconds,e a resolução de tempo no eixo x é associada a taxa de amostragem de 10ms. Para cadaevento detectado, o mecanismo pode ser usado para alertar o usuário, usando as descriçõesmostradas na Tabela 3.2.

A Figura 3.10 mostra o primeiro caso, onde não existe mobilidade ou interfe-rência. Todas as flutuações dos sinais são devido ao ruído causado pelo decaimento emmulti-caminho, o qual é ignorado pelo sistema de detecção e nenhum evento é registrado.

0 500 1000 1500 2000 2500 3000

−70

−50

−30

Measures

time

RSSI(dbm)

time

Detected Event

Figura 3.10. Investigação da comunicação em um dispositivo parado, sem a pre-

sença de interferência. Nenhum evento é identificado.

A Figura 3.11 mostra a detecção de uma comunicação Bluetooth, que causa inter-ferência sobre a comunicação WiFi. Para este tipo de interferência, uma interface Blue-tooth foi ativada e usada com o Lan Profile, para acessar um ponto de acesso Bluetooth.Os eventos identificados estão nos pontos ressaltados no gráfico. No gráfico é mostrado otempo onde os eventos foram detectados e o número que indica o evento, como mostradona Tabela 3.2.

O cenário de mobilidade é mostrado na Figura 3.12. Neste teste, o usuário moveafastando do ponto de acesso, a partir do instante 10000ms até 15000ms, e o evento 5é detectado, como é mostrado no gráfico. Quando a movimentação é feita em direçãoao ponto de acesso, até o tempo 24400ms, outros eventos associados com mobilidade

116 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 19: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

0 500 1000 1500 2000 2500 3000

−70

−50

−30

Measures

time

RSSI(dbm)

time

Detected Event

1760

1920

2080

2240

2400

2560

2720

2880

48

04

8

Figura 3.11. Investigação da comunicação em um dispositivo parado em um

ambiente com interferência.

também são detectados. Neste caso, duas outras identificações associadas a interferên-cia foram feitas, causadas pelos pontos de acesso na região. Com isso, o cenário final émostrado na Figura 3.13, onde a mobilidade e a interferência aparecem: o usuário movi-menta para um lugar onde existe a presença de interferência oriunda de diferentes pontosde acesso. Neste caso, esta informação mostra ao usuário a condição na qual se encontraa região que ele esta se deslocando. A importância deste resultado é oferecer ao usuárioa informação sobre as condições do ambiente de comunicação, oferecendo ao usuário aopção de movimentar para fora da região de interferência.

0 500 1000 1500 2000 2500 3000

−70

−50

−30

Measures

time

RSSI(dbm)

time

Detected Event

04

83

7

1120

1280

1440

1600

1760

1920

2080

2240

Figura 3.12. A identificação do dispositivo movimentando.

3.2.2.7. Arquitetura e Implementação

A implementação da metodologia proposta nessa tese, através de um software, foi feitacom o foco em permitir que as aplicações sejam notificadas sobre a identificação da mo-

Livro Texto dos Minicursos 117

Page 20: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

0 500 1000 1500 2000 2500 3000

−70

−50

−30

Measures

time

RSSI(dbm)

time

Detected Event

800

960

1120

1280

1600

1760

1920

2080

2240

2400

2560

2720

2880

04

8

Figura 3.13. Identificação de um dispositivo movendo em um ambiente sujeito a

interferências.

bilidade e interferência. Diferente de uma API, que necessita apenas oferecer o acesso adeterminadas funcionalidades do sistema, essa identificação é um sistema reativo, assín-crono. Dada essa característica, é necessário que essa implementação verifique constan-temente a interface e, em seguida, disponibilize essa informação para as aplicações.

A disponibilização das informações sobre a ocorrência de eventos pode ser feitade maneira ativa, onde é feita a notificação para as aplicações sobre alguma atualização nocontexto, ou pode ser feita de maneira passiva, onde as aplicações buscam a informaçãosobre o contexto. Devido à necessidade de uma rápida reação ao contexto da comunica-ção sem fio, a disponibilização ativa desta informação permite uma adaptação adequadaao ambiente. A partir deste requisito, foi criado um middleware, integrado a diferentessistemas operacionais, com o objetivo de permitir uma base de testes sólida, além de umaintegração deste middleware de maneira mais transparente com as aplicações.

O objetivo deste middleware é permitir a identificação dos eventos de mobilidadee interferência em diferentes tipos de sistemas operacionais. Os seus componentes sãodescritos a seguir:

• Amostragem: implementa uma interface com a API de cada sistema operacional,que permite a leitura das medidas de RSSI. Este módulo tem sua implementaçãoespecífica para cada sistema operacional, atendendo às restrições de memória eprocessamento.

• Controle Estatístico: efetua o cálculo do MCEWMA e MCEWMV e a identifica-ção dos eventos fora de controle;

• Filtro de Wavelet: efetua a transformada de wavelets e o cálculo do escalogramasobre os dados da janela amostral;

• Agente: efetua o cálculo do scoreboard e gera a identificação do evento. Tam-bém é específico para cada sistema operacional, uma vez que utiliza os sistemas degeração de eventos e de sinalização disponíveis.

118 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 21: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

A implementação ocorreu para os sistemas operacionais Linux e Windows XP.Até o momento da finalização deste trabalho, uma nova versão, para o sistema operacio-nal Android estava em desenvolvimento. Para permitir que essa metodologia seja imple-mentada em diferentes sistemas operacionais, a Tabela 3.3 mostra uma breve descriçãodos requisitos de cada sistema e o que foi adotado para essa implementação.

Tabela 3.3. Técnicas de Implementação

Requisito Windows XP Linux Android

RSSI Acesso ao WMI, Microsoft (2008) Acesso ao PROC Acesso aodiretório proc WifiManager

Implementação Serviço Daemon Serviço doApplication framework

Integração Conexão via socket com agente Escrita no diretório proc Geração de evento e RPC

Livro Texto dos Minicursos 119

Page 22: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

3.3. Serviço de Caracterização e Gerenciamento de Perfis de Usuários Móveis

O principal objetivo da seção é demonstrar os benefícios de caracterizar o usuário de dis-positivos móveis através de perfis. A computação móvel é uma área em crescimento. Ousuário deseja obter informações em qualquer lugar e em qualquer instante. Por esse mo-tivo, aplicações dependentes do contexto são desenvolvidas para atender aos desejos dousuário. Uma forma de representar esses desejos é através de um perfil, que no caso dousuário móvel é muito dinâmico. Pode ser alterado devido a mudanças de ambiente, dis-positivo, infra-estrutura e interesses. Logo, ele deve ser representado de maneira simplespara facilitar a comunicação entre a aplicação dependente de contexto e o perfil. O traba-lho apresentado nessa seção propõe a criação de um serviço de identificação de usuáriosmóveis, construindo um perfil para cada um deles. Para isso, é necessário utilizar servi-ços auxiliares (serviço de configuração da rede, serviço de configuração do dispositivo,serviço de gerenciamento de interesses e serviço de localização) para compor o perfil.O desenvolvimento do trabalho foi realizado na plataforma Android a fim de verificar aaplicabilidade da solução proposta [Buszko et al. (2001)].

3.3.1. Visão Geral

A computação dependente do contexto tem crescido proporcionalmente ao crescimentodo uso de dispositivos móveis. Isso porque o usuário deseja obter informações em qual-quer lugar, a qualquer momento e em qualquer dispositivo, mesmo que esse esteja emmovimento [Devlic & Jezic (2005)]. O perfil de usuário é uma técnica utilizada para ca-racterizar um usuário num dado contexto. Para isso, ele integra as informações do usuáriomóvel, o seu dispositivo utilizado e o ambiente em que ele se encontra. Para definir operfil do usuário deve-se tratar de assuntos como questões espaciais, temporais, lógicase relacionamentos com outros usuários. Esse perfil pode ser representado através de on-tologias, isto é, modelos de dados que representam um conjunto de conceitos e relaçõesentre eles dentro de um domínio de conhecimento. O perfil de usuário pode ser facilmentealterado devido às mudanças de localização ou alteração de interesse.

3.3.2. Motivação

Utilizando o serviço, será possível desenvolver aplicações que são cientes do contexto.Existe também a possibilidade de criar publicidade ou cupons de descontos para clientesque visitam uma determinada loja ou departamento. Um exemplo do uso do serviço se-ria o seguinte caso. Um médico, aficionado por futebol, deseja receber uma notificaçãono seu celular quando o seu time marcar um gol. Suponha que ele comece a fazer umacirurgia e o seu time está jogando. Nesse contexto, o seu trabalho não deve ser interrom-pido caso o seu time faça um gol. No entanto, se ele estivesse andando de carro naqueleinstante, ele poderia receber essa notificação. Ou seja, dependendo do contexto em queo usuário se encontra, a aplicação deveria ser projetada para ter um comportamento dife-rente. Esse é um ponto fundamental que distingue o paradigma de computação móvel doparadigma tradicional de sistemas distribuídos.

3.3.3. Solução proposta

A solução proposta nesse trabalho consiste em retirar da aplicação a responsabilidade decriar o perfil do usuário. Comumente, a aplicação dependente do contexto deve sempre

120 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 23: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

solicitar informações ao usuário para definir o que deve ser feito. Essa forma é mais tra-balhosa e exige interação entre a aplicação e usuário a todo instante, o que pode tornara aplicação mais lenta. A solução proposta consiste em estabelecer uma comunicaçãoapenas entre a aplicação e o perfil. A aplicação não precisa se comunicar com os demaisserviços que compõem o perfil. Esse perfil já foi construído previamente por serviçosauxiliares (serviço de localização, serviço de configuração de dispositivo, serviço de ge-renciamento de interesses (contexto) serviço de configuração da rede e serviço de confi-guração do dispositivo). Uma representação da solução proposta pode ser vista na Figura3.14.

Figura 3.14. Modelagem da solução proposta. O perfil é composto por informa-

ções fornecidas pelos serviços auxiliares. A aplicação se comunica apenas com

o perfil.

O serviço de gerenciamento proposto consiste em armazenar os perfis de usuáriosjá construídos de forma que a aplicação acesse facilmente o perfil do usuário que já foidefinido previamente.

3.3.4. Perfil

O perfil é uma forma de representar as características e interesses de um usuário em umdeterminado contexto. Esse perfil é de grande importância para aplicações dependentesdo contexto porque elas determinam seu fluxo de acordo com o perfil do usuário. Paracada aplicação pode ser necessário identificar certas características. Após estudar as ca-racterísticas essenciais utilizadas pelas aplicações para identificar um usuário móvel, foidefinido que o perfil será composto de:

• Informações de localização - Descreve onde o usuário está localizado no momento.Identifica a latitude, longitude, nome e descrição do local onde o usuário está.

• Configuração da rede - Descreve as características da rede, incluindo dados sobrebanda e latência.

• Configuração do dispositivo - Descreve as características do dispositivo. As infor-mações essenciais do dispositivo são bateria, memória, modelo e processamento.Essas são as informações mais importantes que a aplicação móvel precisa saber so-bre os dispositivos móveis. A bateria, memória e processamento pois são recursos

Livro Texto dos Minicursos 121

Page 24: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

escassos nesses aparelhos. O modelo é uma informação importante para identificaras funcionalidades do dispositivo.

• Interesses do usuário - Descreve os temas em que o usuário tem interesse em receberinformações. No caso mais genérico, basta o nome e a descrição do interesse.Entretanto, caso seja necessário identificar melhor os interesses, deve-se definirnovos conceitos de interesse que estendam a classe de interesse mais genérica.

O perfil do usuário móvel é muito dinâmico. Devido a sua mobilidade, o usuáriopode alterar rapidamente sua localização e, por esse motivo, mudar os seus interesses.Essa dinamicidade do perfil dificulta a representação do perfil. A forma de representaçãodo perfil escolhida para o trabalho será através de um arquivo XML devido a sua facili-dade de alterar as informações. Pode ser considerado também mais fácil para a aplicaçãorecuperar as informações contidas no perfil.

122 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 25: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

3.4. Serviço Móvel de Notificação de Eventos Baseado em Contexto

A utilização de serviços diversificados baseados em contexto é muito limitada ou inexis-tente para um conjunto pré-determinado de serviços de grande utilidade como informa-ções de tráfego, clima, comércio, turismo, medicina, emergências e veicular. Os disposi-tivos atuais possuem pouca ou nenhuma interatividade com eventos externos localizadosno ambiente em que este se encontra. A razão disto se deve ao fato do contexto ser poucousado para atividades desempenhadas por dispositivos e usuários. Alguns poucos casosde utilização atualmente envolvem informações de localização, energia e identificação(endereço IP, dados de coordenadas GPS), coletadas a partir do ambiente e do usuário.Essa seção apresenta um trabalho que propõe uma especificação de modelo de sistemae a construção de um protótipo com o objetivo de prover a notificação de eventos paradispositivos móveis (aplicações e usuários) baseado no perfil e contextos do usuário e dodispositivo/aplicação. O objetivo é prover a notificação de eventos como uma funcionali-dade agregável no desenvolvimento de aplicações móveis.

3.4.1. Visão Geral

Em um futuro bem próximo, diversos ambientes serão capazes de fornecer informações eserviços para usuários e aplicações móveis através da comunicação entre estes, a sensibi-lidade e responsividade. Para isto, elementos computacionais terão este objetivo, fazendoparte destes ambientes inteligentes. A computação ubíqua e a interação voltada para ousuário definem o alicerce nesta área de ambientes inteligentes. Algumas das tecnologiase sistemas relacionadas incluem: 1) elementos computacionais embutidos, onde diversosdispositivos conectados em rede são integrados ao ambiente; 2) sensibilidade ao con-texto, adaptabilidade e antecipação de tarefas, onde dispositivos possuem a capacidade dereconhecer o usuário e seu contexto atual, mudar em resposta deste e prever o seu com-portamento respectivamente e 3) a personalização de serviços, onde dispositivos podemser adaptados de acordo com as necessidades do usuário.

3.4.2. Objetivos

Aqui é apresentada a especificação de um servidor de eventos com o objetivo de geren-ciar a notificação de eventos em aplicações móveis. O servidor de eventos é tambémresponsável por fornecer os SeRBIs (Serviços Remotos Baseados em Informações) paraaplicações móveis. As mudanças de perfil e contexto em aplicações móveis utilização oserviço de eventos para a criação de eventos que podem ser processador e, em forma denotificação, informando aplicações e serviços a sua ocorrência. A notificação, neste caso,em forma de mensagem, reportará a ocorrência destes eventos para que a aplicação ou ousuário possa tomar alguma iniciativa de adaptação.

3.4.3. Estado da Arte

Os serviços ubíquos, em geral, buscam prover características importantes para dispositi-vos móveis. Algumas destas incluem: disponibilidade, transparência na utilização e natransição (localização e tecnologia), sensitividade e confiança. A disponibilidade definepara aplicações acessibilidade independente do contexto e mudanças de estado, neces-sidades e preferências do usuário, levando em consideração o contexto, a conectividadecom os serviços e a energia do dispositivo. O cientista Mark Weiser, considerado o pai da

Livro Texto dos Minicursos 123

Page 26: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

computação ubíqua Weiser (1993a), apresenta em uma única frase o conceito de trans-parência: uma boa ferramenta é exatamente aquela que está invisível para o usuário, nãoinvadindo sua consciência. O foco do usuário deve ser maior na atividade ao invés daferramenta, e a execução de tarefas deve ser feita sem a necessidade de atenção e ciênciada tecnologia por trás.

O modelo de comunicação baseado em eventos descreve um paradigma aplicávelna interconexão de elementos que compõem aplicações em ambientes ubíquos Weiser(1993b), Dearle (1998) de uma maneira assíncrona. Estes ambientes em geral contemaplicações e elementos de rede que são em geral heterogêneos e distribuídos. Eles sãoheterogêneos devido ao fato destes poderem executar tipos de tarefas diferentes para ousuário, requerendo conjuntos variados de componentes de hardware e software. Elestambém são distribuídos de tal forma que um único elemento de rede pode possuir umadependência sobre outros elementos, tais como obter informações do ambiente e executartarefas pelo usuário.

3.4.4. Serviço Móvel de Notificação de Eventos

O processo de gerenciamento de eventos e os resultados de um protótipo são apresentadosneste trabalho com o objetivo de demonstrar a viabilidade deste serviço em aplicaçõesmóveis e também sua importância na computação ciente de contexto.

3.4.4.1. Arquitetura

O servidor de eventos utiliza uma arquitetura cliente-servidor composta de um compo-nente localizado no dispositivo móvel e um servidor de dados remoto. A razão de osistema possuir dois componentes distribuídos está no fato da necessidade em se captareventos em ambos os lados. O servidor de eventos localizado no dispositivo recebe oseventos gerados por outros serviços ou aplicações em execução e os envia para o servidorde eventos localizado no servidor de dados (SDE). Este servidor de eventos é responsávelpor receber os eventos gerados no dispositivo, receber os eventos gerados no próprio ser-vidor e enviar notificações de eventos ocorridos no lado do servidor de interesse a partirde SeRBIs para as aplicações em execução ou diretamente para o usuário.

3.4.5. DroidGuide

Para fins de demonstração da viabilidade no gerenciamento de eventos em aplicaçõesubíquas, o sistema proposto neste trabalho foi incorporado em uma aplicação turística de-nominada DroidGuide. O DroidGuide utiliza uma arquitetura cliente-servidor compostade clientes móveis na plataforma de software e sistema operacional Android e um servi-dor de dados remoto na plataforma de desenvolvimento de aplicações Web App Engine

(GAE ) também da Google, executando sobre o ambiente de execução Python. Clientesmóveis comunicam com o servidor através de mensagens de requisição/resposta sobre oprotocolo HTTP. Dados são enviados do cliente para o servidor através de requisições dotipo GET . Ao receber estas requisições, o servidor as processa e responde para o cli-ente através do envio de documentos XML sobre HTTP. Neste protótipo, assume-se queo dispositivo móvel possui capacidade de se conectar ao servidor utilizando um ponto de

124 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 27: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

Figura 3.15. A arquitetura do servidor de eventos para aplicações ubíquas.

acesso em uma das redes sem fio disponíveis (wireless LAN ou GPRS/EDGE/HSDPA).

Como o objetivo de simplificar e facilitar a integração das diversas funcionalidadesdo sistema, o DroidGuide foi logicamente dividido em módulos com responsabilidades erelacionamentos bem definidos. Cada módulo em geral é composto de um componentelocalizado tanto no dispositivo móvel (em forma de cliente) quanto no servidor de dados(em forma de serviço). Os principais módulos da aplicação são: 1) aplicação, responsá-vel por gerenciar as principais telas, comandos da aplicação e define o relacionamentofuncional entre todos os outros módulos do sistema; 2) perfil, responsável por gerenciaras informações e interesses do usuário; 3) contexto, que gerencia as informações sobre oestado do usuário, informações climáticas e de localização; 4) comunicação, que provêa comunicação de todos os módulos entre o cliente e o servidor; 5) escalonador, respon-sável por apresentar atrações turísticas baseadas nas informações de perfil e contexto dousuário; 6) servidor de eventos, responsável por obter informações de mudança de da-dos de perfil e contexto e notificar o usuário de serviços relacionados a estas mudanças;7) adaptação, responsável pela apresentação do conteúdo baseado em dados de perfil econtexto.

3.4.5.1. O Processo de Gerenciamento de Eventos

O DroidGuide utiliza o servidor de eventos na captação e processamento de eventos in-ternos (no dispositivo) e externos (no servidor de dados) e na entrega de mensagens denotificação a partir de SeRBIs para aplicações e serviços interessados. O servidor de even-tos localizado no dispositivo recebe as requisições de mudança de perfil e contexto dosprincipais módulos do DroidGuide, as processa, criando assim um conjunto de eventos.O módulo de comunicação é utilizado no envio e recepção de eventos para o servidor de

Livro Texto dos Minicursos 125

Page 28: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

dados, onde os eventos serão também processados pelo serviço de eventos.

Todos os eventos criados por serviços e aplicações em execução no dispositivomóvel são capturados pelo gerenciador de eventos e enviados ao SDE em períodos cícli-cos configuráveis e adaptáveis de acordo com as necessidades das aplicações. Quando oservidor de dados recebe os eventos vindos do dispositivo, o serviço de eventos os avalia eefetua uma busca por SeRBIs relacionados que foram inicialmente subscritos pelo usuáriodurante a aplicação. Por exemplo, quando o usuário subscreve em um serviço de clima,ele estará apto a receber notificações deste a partir de eventos que forem gerados durantea execução da aplicação. Suponha que a próxima atividade turística a ser executada pelousuário exija uma condição climática na qual o clima não pode estar chuvoso. Quando ousuário se deslocar para a tal atividade turística, o servidor de eventos no dispositivo iráreceber uma requisição de mudança de contexto, neste caso relacionado à sua localizaçãoe execução da atividade. Um evento será criado para representar a mudança de contextoe será enviado para o servidor de dados, onde será processado. No processamento, oSeRBI específico de clima será consultado, verificando o interesse por tal evento. Comoo serviço de clima subscrito pelo usuário possui um interesse pelo evento (tipo clima), oSeRBI verificará as condições climáticas do local da atividade turística a ser visitada peloturista. Em caso de tempo chuvoso, o SeRBI criará uma notificação que será repassadado servidor de dados para o dispositivo. Desta forma, o turista receberá uma notificaçãoinformando-o da condição climática do destino, oferecendo-o, neste caso, alternativaspara a substituição da atividade em questão. As notificações em geral podem ser apre-sentadas de diversas formas, desde uma simples notificação em texto para o usuário atéuma operação a ser executada por componentes ou serviços internos de aplicações. Esteprocesso pode ser visualizado na Figura 3.16.

3.4.6. Resultados

No protótipo desenvolvido, o servidor de eventos foi capaz de capturar mudanças de perfile contexto da aplicação. Os eventos foram capturados no dispositivo e enviados para oserviço de eventos remoto. A partir dos interesses definidos pelo usuário no perfil, o esca-lonador de atividades no servidor foi acionado para definir atividades turísticas de acordocom os interesses do turista. A subscrição de SeRBIs também mostrou a viabilidade nautilização destes em aplicações ubíquas. Os SeRBIs foram capazes de enviar mensagensde notificação para o dispositivo em situações onde eventos remotos foram criados nolado do servidor de dados.

3.4.7. Conclusões e Trabalhos Futuros

Conforme apresentado neste trabalho, o servidor de eventos possibilitou ao turista a subs-crição de SeRBIs e a notificação de eventos relacionados às suas atividades que, no casodo protótipo apresentado, as atividades turísticas executadas sobre uma determinada re-gião. O servidor de eventos também foi capaz de receber eventos gerados a partir de ati-vidades que foram selecionadas ou executadas pelo usuário, informando assim o servidorde dados de eventos (SDE) mudanças de perfil e contexto do usuário como localização,interesses, condições do usuário e informações de adaptação e de atividades. Os SeRBIssubscritos pelo usuário foram capazes de receber eventos vindos do dispositivo móvel eenviar notificações de volta para o dispositivo contendo informações úteis para o usuário

126 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 29: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

Figura 3.16. Demonstração do processamento de eventos ocorrendo no dispo-

sitivo e no servidor de dados do DroidGuide. Em (A), mudanças no ambiente

ou nos dados de perfil e contexto do usuário causam a ativação do servidor de

eventos (B). O serviço cria eventos e os envia para o servidor de dados (C), onde

o servidor de eventos os processa (D). O servidor busca por SeRBIs interessa-

das nos eventos (E). Caso os SeRBIs subscritos pelo usuário dependam destes

eventos, eles serão ativados. Os SeRBIs também podem gerar eventos em situ-

ações onde ocorram mudanças de contexto remoto (F), criando assim eventos

no lado do servidor de dados(G). Estes eventos criados no servidor de dados

e ativações de SeRBIs causam a criação de mensagens de notificação (H) que

serão entregues ao cliente (I). O dispositivo então recebe a mensagem de notifi-

cação, onde esta é repassada para o componente ouvinte ou diretamente para o

usuário (J).

e para a aplicação em execução.

Dentre várias melhorias no modelo proposto inclui a configuração do perfil de pro-cessamento de eventos no dispositivo e no servidor remoto com o objetivo de aperfeiçoara utilização dos recursos presentes nos dispositivos móveis como bateria e processador ecusto de transmissão de dados na rede. Este perfil de processamento incluiria a opção dedefinir os nós responsáveis pelo processamento de eventos mediante as condições em queo dispositivo se encontra, tais como o acesso á rede (qualidade do canal, tipo), custo detransmissão (valor, consumo de energia), densidade de eventos sendo gerados.

Livro Texto dos Minicursos 127

Page 30: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

Figura 3.17. a) interface commapas apresentando as atrações turísticas, b) mapa

mostrando uma possível rota entre as atividades turísticas.

Figura 3.18. c) notificações de mensagens e d) apresentação de conteúdo ao

usuário a partir de atrações.

128 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 31: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

3.5. Tratamento de Contextos Coletivos em Aplicações Cientes de Contexto

Existem diversas aplicações em que ações para um grupo de usuários deverão ser reali-zadas. Dentre elas podemos imaginar os cenários de uma casa inteligente compartilhadapor uma família, apresentações públicas (concertos, teatros, palestras), escritórios com-partilhados, guias turísticos utilizados em excursões, dentre outras. Todas as aplicaçõescitadas possuem a seguinte característica em comum: embora cada entidade de um grupopossua contextos individuais, as ações realizadas pelas suas aplicações cientes de con-texto devem levar em consideração não só tais entradas, mas também os contextos deoutros elementos do grupo e do ambiente ao qual o indivíduo pertence [Roy et al. (2006),Shin &Woo (2005)]. Nas aplicações coletivas problemas podem ser encontrados em situ-ações onde os contextos dos diferentes usuários são discordantes ou incompatíveis entresi e/ou com o ambiente a ser adaptado. Esses são precisamente os problemas que deverãoser resolvidos em um trabalho sobre o tratamento de contextos coletivos em aplicaçõescientes de contexto. O objetivo geral do trabalho é o de conseguir soluções inteligentes,que consigam identificar a ocorrência dos problemas relacionados e resolvê-los de formaa maximizar a satisfação individual e coletiva dos usuários.

3.5.1. Introdução

Existem diversas aplicações cientes de contexto nas quais adaptações de serviços para umgrupo de usuários simultâneos deverão ser realizadas. Essas são as chamadas aplicaçõescientes de contexto coletivas, e a ocorrência das mesmas em cenários ubíquos geram situ-ações particularmente interessantes. Os problemas típicos da colaboração entre usuáriosde uma mesma aplicação são agregados a todos os desafios específicos da computaçãoubíqua, tais como escassez de recursos e dinamicidade das configurações.

3.5.2. Conceitos Relacionados

As aplicações coletivas ocorrem em sistemas cientes de contexto que consideram paraa adaptação de suas tarefas os interesses e dados contextuais de cada membro de umgrupo de usuários simultaneamente associados. É interessante notar que não importa qualo tipo de aplicação considerada ou mesmo como os usuários se associaram à mesma.Importa apenas que a aplicação reconheça que em um dado momento, existem dois oumais usuários interessados em suas tarefas, e que as mesmas devem ser adaptadas deacordo com os contextos coletivos adquiridos.

Contextos coletivos podem ser definidos como as informações sobre os ambientescompartilhados bem como os dados que refletem as condições próprias de cada elementode um grupo. Tais contextos são utilizados pelas aplicações coletivas para realizarem suasadaptações. Existem dois tipo de dados contextuais coletivos: (i) Contextos ambientais:são dados que representam os ambientes (físico e/ou computacional) e seus elementos,compartilhados pelos usuários envolvidos. Representam também a relação entre o grupode usuários e o ambiente, caracterizando situações tais como propriedades, compartilha-mentos, associações temporárias ou permanentes, dentre outras. Apresentam o mesmovalor para todos os usuários associados. Condições climáticas, estação do ano e a uti-lização de elementos do ambiente são exemplos de contextos desse tipo; (ii) Contextospróprios: são dados referentes ao usuário, os quais refletem suas características, preferên-

Livro Texto dos Minicursos 129

Page 32: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

cias e situações pessoais. Devem explicitar ainda a relação entre o usuário e os demaiselementos de seu grupo. Cada usuário pode apresentar um valor próprio. Fome, sono egrau de parentesco são alguns tipos possíveis de contextos próprios.

A combinação de dados contextuais coletivos deve ser utilizada para realizar aadaptação das tarefas da aplicação. No entanto, a divergência entre os mesmos pode le-var à ocorrência de conflitos de interesse. Ao analisar os valores de entrada de contextoscoletivos apresentados por cada um dos usuários, bem como os recursos e característicascorrentes dos ambientes físicos e computacionais compartilhados, a aplicação poderá en-trar em um estado de inconsistência, incapaz de decidir o que deverá ser feito quanto àsadaptações a serem realizadas de maneira a atender as demandas individuais e coletivasao mesmo tempo. Nesse caso, diz-se que ocorreu na aplicação um conflito coletivo.

Identificada a ocorrência de um conflito coletivo, a aplicação deverá encontrarformas, simples ou sofisticadas, para resolver a inconsistência ou impasse. A execuçãode uma técnica ou algoritmo que permita atender de maneira inteligente e conveniente asdiferenças geradas pelos dados contextuais coletivos utilizados é denominada tratamentode contextos coletivos.

Para tratar conflitos coletivos é necessário que a solução de conciliação propostamodifique de alguma maneira o conjunto de tarefas da aplicação. Nesse caso, deve-seescolher em quais aspectos das tarefas serão realizadas tais alterações, permitindo assim aescolha do algoritmo de conciliação mais adequado. Tais aspectos são chamados os níveisde atuação e alguns exemplos para os mesmos são os parâmetros, a ordem, o agrupamentoe a composição das tarefas. Vale ressaltar que alterações nas tarefas podem levar emúltima instância a modificações nos ambientes físicos e/ou computacionais.

3.5.3. Trabalhos Relacionados

Os trabalhos encontrados em [Masthoff (2004)] e [McCarthy & Anagnost (2000)] podemser considerados relacionados ao objetivo geral deste trabalho: realizar tratamento deconflitos coletivos. No entanto, enquanto tais trabalhos estão focados em uma única apli-cação, um conjunto fechado de contextos e arquiteturas de implementação específicas, aproposta deste trabalho possui uma visão mais ampla e dinâmica, não sendo portanto par-ticular para aplicações ou contextos e pretendendo oferecer uma gama de possibilidadesde implementação.

Roy et al. em [Roy et al. (2006)] apresentam uma solução para construção de umacasa inteligente que considera as atividades e localizações de múltiplosmoradores. A con-tribuição desse trabalho está em oferecer suporte aos diferentes participantes capturandoas correlações e interações entre seus movimentos e atividades, e proporcionando um am-biente adaptado a todos, sem conceder preferências. Ao contrário da proposta apresentadapor Roy et al., este trabalho apresenta uma solução para tratamentos de conflitos coletivosgenérica, possível de ser implementada para qualquer aplicação e adaptável às condiçõescorrentes das mesmas. Shin et al. [Shin & Woo (2005)] discutem também o problemada adaptação de ambientes ubíquos em situações de compartilhamento de aplicações, ser-viços e recursos por múltiplos usuários. A solução para tais conflitos apresentada pelosautores foi a atribuição de prioridades para cada usuário. O trabalho utiliza um tipo desolução que emprega sempre a mesma maneira simples e rígida para resolver o problema

130 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 33: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

em questão. Ardissono et al. [Ardissono et al. (2002)] apresentam um sistema Web paraelaboração de lista de tarefas para grupos heterogêneos de turistas. Cabe a um dos usuá-rios interagir com o sistema para informar o número de pessoas no grupo e dividi-las emsub-grupos relevantes, considerando critérios tais como idades, interesses, capacidadesvisuais e deficiências físicas. Com base nas informações fornecidas, o sistema escolhe asmelhores tarefas para cada sub-grupo, podendo apresentá-las em listas separadas ou emuma versão única. O sistema descrito por esse trabalho é diferente de aplicações cien-tes de contexto uma vez que seu objetivo é ajudar usuários a escalonar o passeio, e nãoguiá-los durante as visitas.

3.5.4. Tratamento de Conflitos Coletivos: Uma Abordagem Dinâmica

No processo de desenvolvimento de uma solução para tratamento de conflitos coletivos,verificou-se a necessidade de modelar todo o ciclo de vida de aplicações ciente de contextode forma a entender quais seriam as principais ações necessárias de serem projetadas paraa implementação e execução das mesmas. A visão geral desse ciclo permite uma maiorcompreensão da dinâmica de funcionamento dessas aplicações, identificação dos princi-pais desafios associados e em especial a percepção dos pontos nos quais ações específicaspara aplicações coletivas devem ser executadas.

Uma vez que não foram encontrados pelos autores na literatura trabalhos que abor-dem tal assunto, em particular considerando aplicações com caráter coletivo, um diagramade atividades para o ciclo de vida de aplicações ubíquas, cientes de contexto e coletivasfoi projetado. Tal diagrama é composto por fases e suas respectivas atividades. Cadafase configura um momento do ciclo de vida de uma aplicação ciente de contexto, e cadaatividade representa para a fase associada uma operação importante a ser executada parao correto e completo funcionamento da aplicação.

Embora proposto para modelar aplicações coletivas, o diagrama pode ser utilizadotambém no projeto de aplicações individuais, uma vez que todos os módulos a seremdesenvolvidos apenas para as primeiras foram encapsulados em um único bloco, chamadoConflict Engine, o qual é executado em uma única atividade.

3.5.5. O Ciclo de Vida das Aplicações Coletivas

A abordagem escolhida para a construção do diagrama está baseada na distribuição deatividades a serem executadas em três fases distintas do ciclo de vida de uma aplicaçãoubíqua e ciente de contexto: (i) Pré-aplicação, (ii) Aplicação e (iii) Pós-aplicação. AFigura 3.19 ilustra o diagrama.

A fase Pré-aplicação envolve a preparação de todos os aspectos necessários aocorreto e completo funcionamento de uma aplicação ubíqua e ciente de contexto comtratamento de conflitos em contextos coletivos. Desse modo, deverão ser executadas asseguintes atividades:

• Configurar ambientes inteligentes: os ambientes a serem utilizados devem ser ins-trumentados com toda e qualquer forma de oferecer para a aplicação dados con-textuais diversos, recursos físicos e computacionais demandados pelas aplicações eainda os meios necessários para comunicação entre os dispositivos instalados;

Livro Texto dos Minicursos 131

Page 34: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

Pré-aplicação Aplicação Pós-aplicação

Configurar AmbientesInteligentes

Configurar Hardwaredo Usuário

Desenvolver Software(Aplic., Arq., Engine)

Executar Tarefas deStartup

Obter Entradas

Pré-processamento Sintático eSemântico das Entradas

Classificação de Tarefas

Executar TarefasIndividuais

Processamentode TarefasColetivas

Executar TarefasColetivas

Avaliar Qualidade

Executar Tarefas de

Finalização

Executar Ações de

Aprendizado

Construir / AtualizarBases de Dados

Figura 3.19. Diagrama de atividades: O ciclo de vida das aplicações coletivas.

• Configurar hardware dos usuários: todo usuário necessita de dispositivos de hard-ware para interagir com a aplicação, sejam eles sensores introduzidos, computado-res vestíveis ou mesmo os tradicionais computadores de mão ou celulares. Umavez que existem diversos modelos e configurações para dispositivos utilizados nes-ses casos, é necessário não só detalhar requisitos mínimos de funcionamento, mastambém escolher uma estratégia para lidar com a potencial heterogeneidade obser-vada;

• Desenvolver software: inclui as implementações da aplicação, de todos os módulosde suporte da arquitetura de software escolhida e do bloco responsável pelo trata-mento de conflitos coletivos.

• Executar tarefas de Startup: atividade na qual serão executadas todas as ações ne-cessárias para iniciar a aplicação, os módulos componentes da arquitetura de soft-ware e o bloco para tratamento de conflitos coletivos utilizado.

A fase da Aplicação é aquela em que os usuários, portando seus dispositivos cor-retamente escolhidos e configurados, se inserem em uma diversidade de ambientes inte-ligentes previamente instrumentados e executam, de acordo com suas necessidades, umasérie de tarefas disponibilizadas pela aplicação. Nessa fase, os usuários desejam ser ser-vidos de tarefas da melhor maneira possível de acordo com seus dados contextuais, dosdemais elementos do grupo e os do ambiente a sua volta. Nesse caso, as seguintes ativi-dades são executadas:

• Obter entradas: nessa atividade, a aplicação obtém junto à arquitetura de softwareutilizada as três entradas básicas necessárias para sua execução: dados contextuaisindividuais, dados contextuais do ambiente e a lista de tarefas disponibilizadas paraseus usuários;

• Pré-processamento semântico e sintático: dados contextuais e tarefas da aplicaçãodevem ser pré-processados, de forma a adquirirem associações semânticas e sinta-xes padronizadas. Essas ações viabilizarão melhor armazenamento, intercâmbio eutilização final dos mesmos. Além disso, será necessário associar contextos às ta-refas, de maneira que apenas aqueles dados que sejam realmente importantes para

132 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 35: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

as adaptações executadas sejam coletados e considerados. Outras tarefas de pré-processamento específicas para cada aplicação podem ainda ser executadas;

• Classificação de tarefas: as tarefas da aplicação são separadas em individuais oucoletivas. As tarefas individuais podem ser prontamente ofertadas aos usuários,uma vez que sua execução não possui relação direta com contextos e tarefas deoutros usuários. As tarefas coletivas, entretanto, só devem ser ofertadas aos usuáriosapós passarem por um bloco de avaliação. Diferentes técnicas podem ser utilizadaspara realizar a classificação, como a análise dos dados semânticos associados, doscontextos utilizados, troca de mensagens entre usuários participantes, dentre outras;

• Processamento de tarefas coletivas: o sistema procurará por conflitos entre os con-textos coletivos apresentados pelos diversos usuários participantes, considerando oestado corrente dos ambientes físicos e computacionais compartilhados, bem comoo conjunto de tarefas a serem processadas. Caso tal conflito não seja detectado, oconjunto de tarefas está liberado e poderá ser executado. Se um conflito for de-tectado, o mesmo deverá ser ajustado em algum nível, antes de ser ofertado. Valeressaltar que o conjunto de tarefas processados poderá conter apenas uma ou atémesmo todas as tarefas disponibilizadas pela aplicação. Essa atividade é executadaapenas para tarefas classificadas previamente como coletivas.

Em algum momento, a aplicação ciente de contexto será finalizada pelo usuárioou espontaneamente uma vez que todas as tarefas já foram executadas. Nesse ponto seinicia a fase chamada Pós-aplicação, a qual possui algumas atividades associadas, utili-zadas para encerrar a aplicação, verificar a qualidade das ações realizadas e armazenardados e informações obtidas ao longo do período de utilização. Essa fase em particular ébastante dependente da aplicação, uma vez que cada uma poderá apresentar necessidadesespecíficas de finalização.

3.5.5.1. Conflict Engine: Detecção e Tratamento de Conflitos

Um conjunto de módulos deve ser implementado junto à aplicação de maneira a permitir,sempre que necessário, o processamento das tarefas coletivas. Esse conjunto pode servisto como um arcabouço de software e é chamado Conflict Engine. Seus componentessão apresentados a seguir, juntamente com uma discussão sobre as possibilidades de im-plementação para o mesmo. A organização dos módulos do arcabouço conforme mostra aFigura 3.20 é uma contribuição deste trabalho e foi proposta para funcionar com diferen-tes arquiteturas de software para sistemas cientes de contexto e de maneira independentedas aplicações utilizadas.

O módulo de verificação de conflitos realiza uma análise tri-dimensional conside-rando como eixos os perfis dos usuários envolvidos, o perfil do ambiente e as tarefas daaplicação. Pode ser programado para utilizar todos os dados disponíveis nessas dimen-sões para análise, bem como apenas um subconjunto desses. A escolha de como será feitaa análise depende basicamente dos níveis de atuação escolhidos, os quais indicam comoas tarefas podem ser processadas na busca pela ocorrência de conflitos e como as mesmaspodem ser alteradas em casos de conciliação.

Livro Texto dos Minicursos 133

Page 36: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

Detecção de Conflitos - Análise Tri-dimensional

Executar Tarefas Coletivas

Conflict Engine

Arquitetura

de Software

Perfis

Tarefas

Conciliação - Metodologia para Resolução de Conflitos Coletivos

Outros

BDs

ClassificarAlgoritmos

IniciarAcordos

ExecuçãoSupervisionada

Re-S

tartup

NíveisAtuação

Figura 3.20. Módulos componentes da Conflict Engine.

O módulo de conciliação recebe como entradas as tarefas conflitantes, os per-fis dos usuários envolvidos, o perfil do ambiente, os níveis de atuação da conciliação,algoritmos ou técnicas disponíveis para o tratamento e demais informações necessáriasarmazenadas em bases de dados da arquitetura de software utilizada. Esse módulo deveexecutar algoritmos que resolvam o conflito detectado para determinado nível de atuação.Uma vez que as aplicações em foco são ubíquas, tal módulo deverá executar técnicasde conciliação vinculadas a limites para consumo de recursos e/ou qualidade de serviço.Como resultado tarefas adaptadas são produzidas atendendo aos interesses da coletivi-dade, mas procurando considerar ao máximo as demandas individuais e as possibilidadescontextuais correntes.

O módulo de Re-Startup é invocado em alguns casos, como parte do processo deanálise para verificação de conflitos ou dos ajustes necessários para a adaptação de tarefasque envolvem contextos coletivos. Permite re-executar as ações que foram previamenterealizadas pela atividade de Startup na fase de Pré-aplicação.

3.5.5.2. Uma Metodologia para Resolução de Conflitos Coletivos

O módulo de conciliação da Conflict Engine pode ser implementado de maneiras dife-rentes, utilizando diversos algoritmos capazes de ofertar uma solução para os conflitosdetectados. Alguns trabalhos na literatura já abordaram o assunto, oferecendo soluçõesespecíficas para determinadas situações, aplicações e contextos [Masthoff (2004), Mc-Carthy & Anagnost (2000)]. No entanto, por representarem abordagens particulares, asmesmas não seriam facilmente aplicáveis em cenários diferentes daqueles inicialmentepropostos.

O presente trabalho, além da proposta do diagrama para o ciclo de vida das apli-cações ubíquas, coletivas e cientes de contexto, bem como do arcabouço de software paraprocessamento de tarefas coletivas, define uma nova metodologia de implementação parao módulo de conciliação de conflitos, dinâmica o suficiente para se adequar a diferentesaplicações de acordo com a situação corrente das mesmas. Tal metodologia visa orientara execução das ações necessárias para, em caso da ocorrência de conflitos, classificar eescolher automaticamente algoritmos de resolução que realizem o tratamento de conflitos

134 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 37: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

dentro de parâmetros previamente acordados para o consumo de recursos e índices dequalidade de serviço.

Dentro do módulo de conciliação, implementado de acordo com a metodologiaproposta, está definida a execução das seguintes ações: classificação e escolha do algo-ritmo a ser utilizado, parametrização do mesmo segundo os acordos para consumo derecursos e níveis de qualidade e execução supervisionada.

A classificação e escolha de algoritmos poderá ser implementada de maneira sim-ples ou sofisticada. Exemplos de implementações interessantes seriam a utilização depolíticas pré-programadas e instaladas para guiar a escolha, ou a utilização de técnicasde aprendizado de máquina. De qualquer maneira, para que essa ação seja realizada,inicialmente deverá ser executada uma monitoração de parâmetros da aplicação e dos am-bientes compartilhados. Em seguida, uma análise dos dados monitorados deve fornecero conhecimento necessário sobre a situação corrente da aplicação, de maneira a permitirum planejamento sobre a escolha e configuração de um algoritmo de conciliação maisadequado.

Em relação aos possíveis algoritmos a serem utilizados, diferentes opções já des-critas na literatura podem ser consideradas. Tais opções divergem uma da outra pelonível de sofisticação e complexidade, e podem ser obtidas junto as mais diversas áreas,tais como sistemas distribuídos, teoria dos jogos, computação biologicamente inspirada,otimização, dentre outras. Em comum dentre todas essas áreas, está o fato de utilizaremtécnicas específicas para lidar com situações em que um conjunto de usuários trabalhandode forma cooperativa desejam compartilhar os recursos de uma mesma aplicação. Umavez escolhido, o algoritmo deverá passar por uma etapa de configuração para que possa seadequar ao planejamento realizado anteriormente, considerando os resultados de concili-ação desejados e o consumo de recursos possível. Finalmente, a execução da estratégiade conciliação será realizada. No entanto, tal execução se dará de maneira supervisionadacom o objetivo de impedir que os limites para os acordos de nível de serviço estabelecidossejam excedidos ou violados de alguma maneira.

A metodologia proposta neste trabalho possui como vantagem sobre as demaisopções para resolução de conflitos coletivos, um perfil de funcionamento capaz de se ade-quar à diferentes situações. Ela conhece e respeita a quantidade de recursos disponíveis etenta encontrar a solução que trará a melhor qualidade de serviço possível. Essa caracte-rística é bastante vantajosa para sistemas ubíqüos, considerando a restrição de recursos ea dinamicidade das configurações dos mesmos.

3.5.6. Conclusão

Esse trabalho apresentou uma discussão sobre um problema específico encontrado emsistemas ubíqüos cientes de contexto compartilhados por grupos de usuários. Conceitosrelacionados ao tema foram formalizados e, para resolver o problema em questão, forampropostos um diagrama de atividades para o ciclo de vida de aplicações ubíqüas cientes decontexto, um arcabouço contendo módulos responsáveis por processar tarefas coletivas euma metodologia para execução de técnicas para o tratamento de conflitos coletivos. Umestudo de caso baseado na implementação de um guia turístico coletivo foi apresentadocomo forma de ilustrar o conceito de aplicações coletivas, assim como validar as propostas

Livro Texto dos Minicursos 135

Page 38: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

apresentadas para o tratamento de conflitos em aplicações ubíquas coletivas e cientes decontexto. Como direções futuras de pesquisa para o trabalho apresentado, pode-se citara implementação de outros estudos de caso como forma de avaliar a ocorrência de maiornúmero de conflitos em diferentes áreas de atuação e a implementação e avaliação deoutros algoritmos para tratamento de conflitos coletivos.

136 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 39: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

3.6. Utilização de Dados Contextuais para Segurança em Aplicações Ubíquas

A segurança é um tema de pesquisa considerado atual e de grande importância para di-versas áreas da computação. Em particular, a computação ubíqua necessita com urgênciado desenvolvimento de mecanismos de segurança próprios, uma vez que suas característi-cas, tais como dispositivos, aplicações, redes de comunicação, dentre outros, são bastanteespecíficas e em geral diferentes da computação tradicional. Além disso, os dados com-partilhados por sistemas ubíquos são bastante sensíveis, uma vez que refletem o estadocorrente de pessoas, lugares e objetos. Dados contextuais podem mais uma vez seremusados por aplicações ubíquas, desta vez em suas soluções de segurança, como forma deadaptar tais mecanismos às necessidades reais e correntes, diminuindo a sobrecarga nosdispositivos e na rede e aumentando a eficiência de atuação. Esta seção apresentará doistrabalhos neste tópico:

• Confiança de Dados: uma rede móvel ad hoc é uma rede em que os nós são respon-sáveis pela criação, operação e gerenciamento da rede. Este tipo de rede é tambémconhecida como rede auto-configurável, que não apresenta uma infra-estrutura fixa.As próprias entidades componentes da rede são responsáveis, por exemplo, pelo ro-teamento de pacotes. Assim, para que a rede funcione bem, é necessário que hajacooperação entre os nós. Entretanto, desta necessidade de cooperação, e mais ainda,de confiança entre os nós, surge uma vulnerabilidade a ataques por nós maliciosos.As soluções atuais para garantir a segurança e evitar ataques baseiam-se em umaentidade centralizadora que cuida, por exemplo, do gerenciamento de chaves ou daemissão de certificados para as entidades componentes. Entretanto, esta não é arealidade das redes móveis ad hoc. Essa seção descreve um trabalho no qual ospróprios nós determinam o nível de confiança dos nós vizinhos levando em consi-deração fatores como o número de vizinhos confiáveis e número de rotas confiáveis.Uma vez que estes fatores mudam com o passar do tempo, o mecanismo é capaz dese adaptar ao ambiente, seja ele mais ou menos hostil [Schweitzer et al. (2006)].

• Seleção adaptativa de protocolos de segurança: essa seção também descreve umtrabalho que propõe um serviço de segurança, que funciona como um middleware,com a habilidade de alterar dinamicamente os protocolos de segurança usados entreduas entidades computacionais. Mudanças são feitas de acordo com variações nosparâmetros do meio sem fio e do uso de recursos do sistema, capacidades de hard-ware, métricas de qualidade de serviço e níveis desejados de segurança definidospela aplicação. Também apresentamos uma extensão que permite ao middlewareconsiderar o valor semântico de pacotes sendo transmitidos com o objetivo de es-colher melhor o protocolo a ser usado para cada trecho do fluxo de dados. Com-paramos a solução com alguns protocolos estáticos de segurança bem difundidose mostramos como o middleware é capaz de se adaptar em diferentes condiçõesde meio e sistema, além de como ele consegue prover um ganho de desempenhoatravés do uso da descrição da semântica de dados.

3.6.1. Confiança de Dados

O conceito de confiança é bastante comum aos seres humanos e está relacionado, direta-mente, à percepção e ao conhecimento que um indivíduo tem a respeito de outro, através

Livro Texto dos Minicursos 137

Page 40: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

do seu comportamento ou sua reputação. Baseado neste conhecimento, este indivíduoé capaz de aceitar riscos e conceder privilégios a alguém em quem confie. Este mesmoconceito é empregado em ambientes de redes ad hoc, pois as entidades que participamdeste ambiente interagem diretamente entre si, havendo a necessidade de se definir umarelação de confiança para viabilizar esta interação.

A avaliação de confiança é efetuada através da observação do comportamento des-tas entidades de acordo com os tipos de serviços providos e requisitados. Esta avaliaçãode confiança em uma rede ad hoc não é uma tarefa fácil devido à mobilidade das entidadese à interação temporária com outras entidades, sem a presença de um elemento centrali-zador capaz de auxiliar no processo de atribuição de confiança [Schweitzer (2006)].

3.6.1.1. Desenvolvimento

Ao longo dos anos, vários trabalhos foram feitos na tentativa de trazer para o ambientecomputacional o conceito de confiança. A maioria desses trabalhos tem como objetivoproporcionar aos nós uma forma de identificar e excluir nós maliciosos da rede.

Pirzada e McDonald [Pirzada, A. and McDonald, C. (2004)] propõem um modeloque seja capaz de julgar a confiabilidade de uma determinada rota. Para avaliar o modelo,eles propõem uma extensão para o protocolo DSR (Dynamic Source Routing). O modeloé simples e, segundo os autores, flexível para uso em MANETs, podendo ser adaptadopara outros protocolos de roteamento. Contudo, depende do funcionamento dos nós emmodo promíscuo (modo da placa de rede), o que acarreta problemas como o aumentosignificativo do número de colisões. Outro problema do modelo é que a “escuta” porconfirmação de pacotes fica restrita ao alcance da transmissão. Mais um ponto negativo éo fato de desconsiderar a limitação de recursos dos nós (por exemplo, energia, memória eespaço de armazenamento).

Schweitzer et al. [Schweitzer et al. (2006)] descreve um mecanismo distribuídopara propagação e consolidação do grau de confiança em redes ad hoc, construindo rela-ções de confiança e tornando as entidades autônomas e capazes de tomar decisões inde-pendente de um elemento central de rede. O modelo considera três operações fundamen-tais para a atualização e propagação dos valores de confiança: (i) composição simples (deum nó i com respeito a um nó j); (ii) composição transitiva (de um nó i sobre um nó k

baseado na opinião de um nó intermediário j); (iii) composição consensual (dois nós, i ej, concordam sobre a opinião com relação a um nó k). Com essas operações, é possívelque dois nós estabeleçam uma relação de confiança quando se encontrarem pela primeiravez. A desvantagem desse modelo é que o processo de propagação pode ser lento e gerarum overhead alto na rede.

Um conceito interessante abordado por Velloso et al. [Velloso et al. (2006)] é ode maturidade do relacionamento, que acrescenta mais um nível de informação sobre ograu de confiança existente entre os nós. Para a atribuição do valor inicial de confiança,são adotadas duas estratégias: (i) prudente, adequada para ser utilizada em um ambientemais hostil; (ii) amigável/ingênua, própria para ambientes já conhecidos. Outra particu-laridade do trabalho é a sugestão de um protocolo para troca de recomendações (REP -Recomendation Exchange Protocol). Este protocolo é bastante flexível com relação às

138 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 41: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

tabelas que devem ser armazenadas e aos parâmetros que são considerados.

A fim de se realizar um experimento prático para concretizar esse conceito, realizou-se um trabalho composto de duas partes: a elaboração de um modelo que incorporassevários das abordagens sobre confiança (discutidas ao longo do texto) e a implementaçãode módulos no NS que fossem capazes de refletir as ideias do modelo elaborado.

Como pontos principais do modelo proposto, pode-se destacar que ele é capaz deestabelecer e atualizar os valores de confiança a fim de fornecer as informações neces-sárias para identificar nós maliciosos, que são entidades que não colaboram para o bomfuncionamento da rede. Ele também é capaz de identificar a rota mais confiável paratransmissão de dados entre dois nós quaisquer da rede. O modelo também explora a ideiade grafos, o que permite a definição de relações transitivas entre os nós. Além destes, osprotocolos de roteamento para redes ad hoc geram custos para os nós. Estes custos podemser divididos em custos de hardware (consumo de energia, memória e bateria) e custos derede (throughput). O modelo proposto leva em conta os dois fatores. O modelo propostotambém explora o conceito de maturidade de uma relação: nós que estão em contato entresi a mais tempo devem possui mais confiança/desconfiança um no outro, dependendo dohistórico de interação entre eles. O modelo também oferece recomendações que permi-tem que um nó consiga informação a respeito de um outro nó com o qual ele não tenhatido um contato prévio.

Na listagem a seguir, serão explicados cada um dos módulos do NS e suas respec-tivas responsabilidades:

Trust Formater: Neste módulo, são implementadas as decisões relacionadas com o es-tabelecimento de relações de confiança entre os nós. Quando um nó i descobreuma rota para um determinado nó j, todos os nós pertencentes à rota que ainda nãosão conhecidos pelo nó i recebem um valor inicial. Esse valor é calculado como arecomendação que os vizinhos de i tem a oferecer sobre cada um dos nós da rota.No caso dos vizinhos não serem capazes de fornecer uma recomendação, o nó des-conhecido recebe um valor padrão previamente definido. Em um ambiente hostil,com muitos nós maliciosos, é esperado que esse valor seja baixo, indicando queinicialmente a desconfiança é alta.

Trust Manager: Esse módulo é responsável pelo gerenciamento dos valores de confi-ança de cada um dos nós da rede. Uma das operações realizadas por esse módulo éa de armazenamento das informações de confiança sobre os nós conhecidos duranteo tempo de execução. Oferece também métodos para recuperar a informação arma-zenada. Ele funciona como uma ponte entre a implementação do DSR e os demaismódulos (Trust Updater e Trust Formatter).

Trust Updater: Esse componente implementa as funções para atualização dos valoresde confiança. A confiança é um conceito subjetivo e depende da experiência dosnós em uma dada situação. Isso significa que não é aconselhável construir ummétodo geral de atualização que seja aplicável em todos os domínios. Sendo assim,a função projetada nesse trabalho destina-se a domínios com vários nós maliciosos.

Livro Texto dos Minicursos 139

Page 42: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

Route Selector: A principal função deste componente (Seletor de Rota) é avaliar as ro-tas baseado nos valores de confiança dos nós que constituem a rota e selecionar amelhor baseado nesta avaliação. As rotas são avaliadas e aquela com o maior graude confiança é utilizada. Algumas vezes, uma rota que sabidamente é boa pode seravaliada como uma rota ruim e outra com um nó malicioso pode ser avaliada comoboa. Por isso, a estratégia de seleção da rota é uma tarefa bastante difícil e poderiaconsiderar outros fatores, como latência. Entretanto, por questões de simplicidade,a estratégia utilizada avalia a confiança da rota utilizando relações de transitividade(a confiança de um nó i em um nó j é calculada levando em conta o valor da con-fiança entre todos os nós que estão na rota de i até j). Como melhoria sobre omecanismo de escolha de rotas original do NS, pode-se citar o fato de que, se umarota é avaliada com o valor máximo, as demais rotas não são verificadas, havendoassim um ganho em tempo de execução.

Acknowledgment Monitor: Para realizar a atualização dos valores de confiança dos nós,é utilizado um mecanismo de confirmação (do inglês, acknowledgment) de mensa-gens. Com o intuito de diminuir o overhead da rede, são utilizados acknowledg-ments apenas para pacotes de dados, e não para pacotes de roteamento. O propósitodo mecanismo de confirmação é usar os acknowledgments recebidos ou a falta delespara ajustar os valores de confiança. Uma requisição de confirmação é armazenadaquando o pacote é enviado e, se uma confirmação é recebida dentre de um tempolimite, os nós da rota tem seu valor incrementado. Se uma confirmação não forrecebida dentro do tempo limite, então os nós pertencentes à rota terão seus valoresde confiança reduzidos.

3.6.1.2. Conclusões e Trabalhos Futuros

Sem a existência do modelo de confiança embutido no protocolo, uma rota que possuaum nó malicioso pode ser usada constantemente. Como os pacotes serão, na maior partedas vezes, descartados, é esperado que o throughput diminua. Por outro lado, se existe oconceito de confiança e as rotas são escolhidas levando-o em consideração, serão evitadasaquelas rotas que contenham nós maliciosos. Assim, o throughput utilizando o protocolomodificado é maior quando comparado ao protocolo original.

Uma possível melhoria no modelo é a elaboração de uma forma justa e eficientede calcular a recomendação. Atualmente, as recomendações consideram todos os nósconhecidos, e não somente os nós vizinhos. Além disso, qualquer nó é capaz de fornecerrecomendação, mesmo que seja um nó malicioso. Portanto, uma mudança no mecanismode cálculo da recomendação pode melhorar consideravelmente o modelo.

3.6.2. Seleção adaptativa de protocolos de segurança

Com toda a heterogeneidade da computação móvel, é difícil criar especificações estáticaspara qualquer tipo de hardware e software de computação móvel. Projetistas e desen-volvedores devem considerar limitações no hardware, demandas de segurança e QoS dosoftware e propriedades do protocolo de comunicação. QoS (Quality of Service), tra-dução de “qualidade de serviço”, significa métricas que devem ser respeitadas para que

140 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 43: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

uma aplicação provenha suas funcionalidades mínimas. Como toda essa informação nemsempre está disponível, soluções integradas e adaptativas para dispositivos móveis sãodesejáveis.

Neste contexto, a especificação de protocolos de segurança se torna uma preo-cupação importante. Do ponto de vista do sistema, cada aplicação pode não apenas terdiferentes necessidades de segurança, como também diferentes demandas de QoS. Já doponto de vista da aplicação, ela pode estar sendo executada em hardware com diferentescapacidades, bem como sobre diferentes protocolos de comunicação. As atuais soluçõesnativas dos protocolos de comunicação, como as presentes no IEEE 802.11 e no Blue-tooth, propõem soluções conhecidamente incompletas ou falhas [Karygiannis & Owens(2002)], além de serem focadas apenas na camada de enlace da pilha de protocolos.

Com isso foi proposto um middleware de segurança adaptativo que altera dina-micamente os protocolos de segurança usados entre dois pares comunicantes, de acordocom variações em um conjunto de parâmetros. O serviço em questão, nomeado ASec-Mid, sigla para o termo em inglês Adaptive Security Middleware, monitora parâmetrosrelacionados às condições do meio sem fio, uso de recursos do sistema, capacidades dehardware e definições da aplicação quanto a métricas de QoS e níveis de segurança deseja-dos. É mantida uma grande coleção de protocolos de segurança que podem ser usados, e omais viável para cada transmissão é escolhido de acordo com os parâmetros monitorados.Aplicações acessam o middleware de uma forma transparente, como um soquete de redetradicional, não ciente dos protocolos de segurança aplicados. Além disso, a aplicaçãopode prover uma descrição semântica do fluxo de dados a ser transmitido, de forma quea o nível de segurança de cada parte da transmissão seja definido individualmente paradiferentes blocos de dados. A ideia deste trabalho não é desenvolver novos algoritmos desegurança, mas sim usar os existentes da maneira mais eficiente possível, com base no“Princípio de Proteção Adequada”, que afirma que se deve aplicar a segurança adequadapara cada tipo de dado e contexto. Os resultados obtidos mostram a eficácia da solução.

As principais motivações para este trabalho surgem da heterogeneidade de dispo-sitivos, aplicações e protocolos de comunicação existentes no meio móvel e sem fio, comoexplicitado no começo deste capítulo. Diante disso, o desenvolvimento do middleware jáé benéfico no sentido de prover uma única camada de segurança para diferentes contextosde hardware, software e comunicação.

Além disso, o trabalho toca num ponto importante ao se prover segurança paraaplicações móveis: a relação custo/benefício entre prover segurança e manter a qualidadede comunicação e desempenho do sistema. O middleware tem o objetivo de trabalharsobre essa relação, mantendo o equilíbrio entre segurança e desempenho de acordo como configurado pela aplicação sobrejacente.

As características do meio em que um dispositivo está inserido muitas vezes sãopoderosas fontes de informação [Li et al. (2006)]. Com isso, a utilização de parâmetros dediversas fontes (aplicação, meio sem fio, recursos do sistema) é uma abordagem interes-sante para se criar um mecanismo adaptativo e que seja sensível às mudanças no contexto.Este trabalho foi publicado em [Rocha & Loureiro (2007)].

Livro Texto dos Minicursos 141

Page 44: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

3.6.2.1. Desenvolvimento

Como discutido anteriormente, o principal objetivo do middleware proposto neste traba-lho é o de escolher dinamicamente o protocolo de segurança mais adequado para comu-nicação entre dois pares. O protocolo escolhido pode ser trocado durante a execução,caso as condições de contexto variem. Em termos gerais, o middleware busca esse obje-tivo mantendo uma biblioteca de algoritmos de segurança existentes, avalia-os de acordocom as seis métricas definidas e monitora parâmetros de contexto para serem usados noprocesso de tomada de decisões.

Um arquivo de configuração é lido pelo middleware toda vez que ele é iniciali-zado. Esse arquivo contém a biblioteca de possíveis algoritmos de segurança a seremusados. Cada entrada no arquivo representa um algoritmo e informações sobre ele, in-cluindo aí os valores das seis métricas. Os valores das métricas de uso de recursos sãoautomaticamente calculados e gerados durante a instalação do middleware.

Cada algoritmo de segurança é associado a seis propriedades definidas por métri-cas. Dessas, três são métricas de força de segurança (ou força criptográfica): confiden-cialidade, integridade e autenticação, e outras três são métricas relacionadas a uso derecursos: uso de memória, tabelas de tempo de processamento e de overhead de rede(em quanto o pacote de dados original aumenta de tamanho). As métricas de força desegurança são representadas por números inteiros, de 0 a 100, cuja utilidade é comparardiferentes algoritmos. Esses valores são definidos pelo administrador do sistema, atravésdo arquivo de configuração.

O middleware monitora parâmetros de diferentes fontes: meio sem fio, capaci-dades de hardware, uso de recursos do sistema e diretivas de QoS e níveis de segu-rança vindas da aplicação. Os parâmetros usados no sistema proposto são listados naTabela 3.4, que mostra também quais métricas dos algoritmos são afetadas por cada pa-râmetro. As unidades usadas têm como finalidade facilitar no processo de decisão deprotocolos. Dessa forma, são privilegiadas unidades percentuais, por consistirem de va-lores com mínimos e máximos conhecidos.

O middleware é dividido em três partes fundamentais: conexão segura, máquinade segurança e controle de parâmetros. A conexão segura fornece a API para a aplicaçãoacessar o middleware. Sua interface é muito similar a uma biblioteca de rede padrão(sockets) e múltiplas instâncias podem ser executadas ao mesmo tempo. A máquina desegurança é responsável por executar a lógica de tomada de decisões, bem como aplicaros protocolos de segurança em pacotes enviados ou recebidos pelas conexões seguras.O controle de parâmetros monitora todos os parâmetros e os torna disponíveis para amáquina de segurança. A Figura 3.21 ilustra a arquitetura do sistema.

Além dos parâmetros monitorados pelo middleware, a aplicação também podeprover um arquivo que descreve a semântica do fluxo de dados a serem transmitidos.A descrição é feita através de uma linguagem de anotação baseada em XML chamadaLACS (Language for Annotation and Configuration of data Security) [Costa & Loureiro(2008)]. A linguagem permite a definição de configurações de segurança (conjuntos deparâmetros relativos à restrições de QoS e níveis de segurança), declarações de padrõesde bytes que constituemmensagens especiais e o modelo de transmissão, escrito na forma

142 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 45: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

Parâmetro Métricas

Mobilidade Confidencialidade e AutenticaçãoQualidade do canal Confidencialidade, Integridade e RedeLatência ProcessamentoRoteamento Confidencialidade e AutenticaçãoCapacidade de memória MemóriaInformação do rádio Confidencialidade, Integridade e AutenticaçãoConsumo de memória MemóriaUso de CPU ProcessamentoBateria Processamento, Rede e MemóriaLatência máxima (QoS) ProcessamentoMemória máxima (QoS) MemóriaMáximo overhead de rede (QoS) RedeMáximo overhead em negociações (QoS) RedeNível de confidencialidade ConfidencialidadeNível de integridade IntegridadeNível de autenticação Autenticação

Tabela 3.4. Mapeamento de parâmetros e métricas afetadas

Figura 3.21. Arquitetura do middleware proposto

de uma sequência de comandos imperativos, contendo comandos condicionais e de con-trole de fluxo, tal qual uma linguagem de programação, que descreve o fluxo de dadosa ser transmitido, associando diferentes partes a diferentes configurações de segurança.Quando o arquivo descritor de semântica é utilizado, o middleware suprime os parâme-

Livro Texto dos Minicursos 143

Page 46: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

tros globais de restrições de QoS e níveis de segurança, usando aqueles especificados nodescritor semântico.

A lógica de seleção de algoritmos de segurança consiste em 4 estágios: instalação,inicialização, conexão e transmissão. Segue uma breve descrição da lógica aplicada emcada estágio.

1. Instalação: Durante o processo de instalação o middleware lê o arquivo de confi-guração, que nesse ponto ainda não possui as métricas de uso de recursos de cadaalgoritmo, e calcula os valores dessas métricas. Para isso, cada algoritmo é tes-tado com diferentes combinações de dados e chaves gerados aleatoriamente e dediferentes tamanhos. Os tamanhos de blocos e o número de execuções para cadatamanho podem ser configurados. Durante esses testes o middleware mede o uso dememória, tempo de processamento e overhead em bytes de cada algoritmo. Para ouso de memória é considerada a média de todas as execuções, enquanto que para astabelas de processamento e overhead são consideradas as médias de execuções paracada tamanho de dados. Os resultados das medições são então escritos no arquivode configuração, de forma que esse processo não tenha que ser repetido (a não serque o sistema sofra uma modificação de hardware, o que invalidaria os resultadosanteriores).

2. Inicialização: Quando o middleware é inicializado pela aplicação, sua principaltarefa é ler e processar o arquivo de configuração. Com isso, o middleware lê as de-finições de algoritmos do aquivo e então gera um conjunto com todos os possíveisprotocolos de segurança. O procedimento de geração dos protocolos respeita regrasbásicas de consistência, como não gerar um protocolo que inclua dois algoritmos domesmo tipo (como uma função hash). Além disso, são disponibilizados protocolosque não contêm algoritmos de todos os três serviços criptográficos tratados (con-fidencialidade, integridade e autenticação), incluindo protocolos com somente umalgoritmo. Finalmente, durante a inicialização, o controle de parâmetros adquire osparâmetros fixos. As capacidades de hardware são obtidas do sistema operacional enesta fase espera-se que a aplicação chame as diretivas para definição de restriçõesde QoS e níveis de segurança.

3. Conexão: Para cada conexão estabelecida, o middleware executa quatro passosbásicos: (1) combinar os parâmetros fixos, (2) selecionar o conjunto de protoco-los a serem usados durante aquela conexão, (3) selecionar algoritmos para troca dechaves e (4) gerar e trocar as chaves. O primeiro passo é um processo simples queconsiste em os dois pares transmitirem seus parâmetros fixos e manterem, para cadaparâmetro, o valor mais restritivo. A seleção de protocolos é feita através de umafiltragem inicial, que elimina protocolos incompatíveis com parâmetros fixos (capa-cidades de hardware dos pares, restrições de QoS e níveis de segurança mínimos),e depois utiliza uma estratégia gulosa para selecionar um conjunto de protocolosde segurança que cobre diferentes aspectos (mais/menos seguros, que economizamemória, que proporciona baixo overhead de rede, etc...). A seleção e a execuçãode algoritmos de troca de chaves é um processo direto, e algoritmos são escolhidosde acordo com os protocolos escolhidos no passo anterior e com restrições de QoSquanto a máximo overhead do processo de negociação de chaves.

144 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 47: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

4. Transmissão: O passo final é executado a cada transmissão de dados. Quando umpar decide transmitir um pacote, o middleware analisa os parâmetros de tempo realpara escolher o melhor protocolo naquele momento, aplica-o sobre a mensageme concatena o pacote gerado com o número do protocolo utilizado e os tamanhosde cada segmento, de modo que o outro lado possa aplicar o mesmo protocolo deforma reversa. Nesse ponto, o middleware possui um pequeno conjunto de protoco-los (número depende das constantes ni), cada um com suas seis métricas, e o grupode parâmetros que pode influenciar em quais métricas devem ser mais importantesnaquela situação. O fato dessa escolha ser crítica em termos de tempo caracte-riza essa parte do processo como um algoritmo online, tornando impraticável o usode técnicas pesadas computacionalmente, como aquelas baseadas em otimizaçãoe pesquisa operacional. Para uma computação rápida e eficaz, nosso método ob-tém uma pontuação para cada protocolo. Usando constantes de configuração quedeterminam o quanto cada parâmetro do meio influencia em cada métrica, o mid-dleware calcula a pontuação de cada protocolo relativa ao específico momento detransmissão, usando o protocolo que obtiver a maior pontuação.

3.6.2.2. Conclusão

A implementação deste trabalho é robusta no sentido de poder ser configurada em relaçãoas pesos das decisões tomadas. O middleware proposto é também configurável tanto pelaaplicação que o utiliza (restrições de QoS e segurança), quanto pela entidade que mantémo sistema, através das configurações da biblioteca de algoritmos. Até onde se sabe, essa éuma abordagem inovadora para o problema.

Os resultados alcançados mostraram que a técnica proposta é adaptável a diversoscontextos e traz benefícios em desempenho e facilidade, uma vez que a aplicação deixade se preocupar com aplicações de algoritmos e protocolos de segurança. Os principaisfatores que estimulam o uso do middleware são a presença da alta variabilidade de parâ-metros de contexto, além de aplicações que permitem maior flexibilidade na escolha deprotocolos.

Além disso, foi testada ummiddleware com uma extensão que permite à aplicaçãodeterminar valores semânticos para cada trecho de dado transmitido. Com isso, o poder deadaptação aos parâmetros de contexto do middleware se soma à possibilidade de aplicarsegurança de acordo com o real valor de cada dado. Dessa forma, o middleware consegueum ganho de desempenho considerável quando é possível descrever o formato de dados aser transmitido.

Livro Texto dos Minicursos 145

Page 48: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

3.7. Conclusão do Minicurso

Neste minicurso foi apresentado o estado da arte de uma área de pesquisa importantee atual chamada computação ubíqua ciente de contexto. Essa área representa a junçãode dois universos de trabalho: a computação ubíqua e a computação ciente de contexto.O primeiro lida com o desenvolvimento de sistemas capazes de serem embutidos noselementos do dia-a-dia e que interagem de forma transparente com os usuários finais,oferecendo computação e comunicação sem fio o tempo todo e em todo lugar. Já o uni-verso da computação ciente de contexto trata da aquisição, processamento e utilizaçãode informações relevantes sobre os ambientes físicos e computacionais relacionados adeterminada aplicação, bem como dos dados de seus usuários. Esses valores, chamadascontextos, são utilizadas por tais aplicações para tornar seus serviços mais adaptados àsreais necessidades dos usuários finais. A utilização de valores contextuais em aplicaçõesubíquas leva ao desenvolvimento de sistemas inteligentes e integrados ao seus ambientesde execução. Tais sistemas serão capazes de ofertar aos usuários serviços altamente per-sonalizados, considerando as melhores estratégias e configurações correntes, de maneiraintegrada, automática e transparente.

Embora seja uma área de pesquisa relativamente recente, a computação ciente decontexto tem sido estudada e explorada por grupos de pesquisa de diferentes localidadeshá alguns anos. Dessa forma muitos trabalhos publicados na literatura puderam ser en-contrados e serviram como referência para a definição de conceitos básico. Em particularforam encontrados muitos trabalhos especificamente relacionados a visões gerais da área,propostas de arquiteturas e middlewares, definições de aplicações para a computação ci-ente de contexto e mais recentemente artigos relacionados com qualidade de contexto,gerenciamento, automatização de tarefas, dentre outros aspectos.

Foram apresentados trabalhos de pesquisa relacionados a temas importantes eainda pouco explorados no desenvolvimento de sistemas ubíquos e cientes de contexto.Tais trabalhos foram discutidos de maneira ampla, e soluções concretas para os problemasrelacionados foram descritas. A abrangência dos temas apresentados mostra que existemainda muitas frentes de trabalho ainda pouco exploradas, em diversas sub-áreas especí-ficas, relacionadas ao tema. Espera-se que o amadurecimento dos trabalhos existentes,bem como o surgimento de novas propostas, levem ao crescimento e à solidificação dosconceitos e soluções para essa área de pesquisa.

Referências

Akella, A., Judd, G., Seshan, S. & Steenkiste, P. (2007), ‘Self-management in chaoticwireless deployments’,WIRELESS NETWORKS 13(6), 737–755.

Ardissono, L., Goy, A., Petrone, G., Segnan, M. & Torasso, P. (2002), Tailoring the re-commendation of tourist information to heterogeneous user groups, in ‘Revised Papersfrom the International Workshops OHS-7, SC-3, and AH-3 on Hypermedia: Openness,Structural Awareness, and Adaptivity’, Springer-Verlag, London, UK, pp. 280–295.

Bahl, P. & Padmanabhan, V. (2000), ‘Radar: An in-building rf-based user location andtracking system’, IEEE INFOCOM 2, 775–784.

146 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 49: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

Buszko, D., Lee, W. & Helal, A. (2001), ‘Decentralized ad-hoc groupware api and fra-mework for mobile collaboration’.URL: citeseer.ist.psu.edu/article/buszko01decentralized.html

Cheng, Y.-C., Chawathe, Y., LaMarca, A. & Krumm, J. (2005), ‘ccuracy characterizationfor metropolitan-scale wi-fi localization’,MobiSys .

Cheverst, K., Davies, N., Mitchell, K., Friday, A. & Efstratiou, C. (2000), Developing acontext-aware electronic tourist guide: some issues and experiences, in ‘CHI ’00: Pro-ceedings of the SIGCHI conference on Human factors in computing systems’, ACM,New York, NY, USA, pp. 17–24.

Costa, D. N. & Loureiro, A. A. (2008), Adaptação de mecanismos de segurança paracomunicação em ambientes móveis, Master’s thesis, Universidade Federal de MinasGerais.

Dearle, A. (1998), ‘Toward ubiquitous environments for mobile users’, IEEE Internet

Computing 2(1), 22–32.

Devlic, A. & Jezic, G. (2005), ‘Location-aware information services using user profilematching’, Telecommunications, 2005. ConTEL 2005. Proceedings of the 8th Interna-

tional Conference on .

Dey, A. K. (2001), ‘Understanding and using context’, Personal Ubiquitous Comput.

5(1), 4–7.

Dittmer, J. (2005), ‘Solving the gps urban canyon problem.’, Frost and Sullivan Market

Insight .

Ericsson (n.d.), ‘Mobile positioning system’.URL: http://www.ericsson.com/mobilityworld/sub/open/technologies/mobile_positioning/index.html

González, M. C., Hidalgo, C. A. & Barabási, A.-L. (2008), ‘Understanding individualhuman mobility patterns’, Nature 453(7196), 779–782.

Google (n.d.), ‘Google maps advanced programming interface’.URL: http://code.google.com/apis/maps

Greenfield, A. (2006), Everyware : The Dawning Age of Ubiquitous Computing, NewRiders Press.URL: http://www.amazon.ca/exec/obidos/redirect?tag=citeulike09-

20&path=ASIN/0321384016

GSMWORLD (n.d.), ‘Gsm’.URL: http://www.gsmworld.com/technology/index.shtml

Haeberlen, A., Flannery, E., Ladd, A., Rudys, A., Wallach, D. S. & Kavraki, L. E. (2005),Practical robust localization over large-scale 802.11 wireless networks, in ‘Proceedingsof the 10th annual international conference on Mobile computing and networking’.

Livro Texto dos Minicursos 147

Page 50: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

Hansen, F. & Meno, F. I. (1977), ‘Mobile fading-rayleigh and lognormal superimposed’,IEEE Transactions on Vehicular Technology 26, 332–335.

Hightower, J. & Borriello, G. (2001), ‘Location systems for ubiquitous computing’,COMPUTER -LOS ALAMITOS- 34, 57–66.

Judd, G., Wang, X. & Steenkiste, P. (2008), Efficient channel-aware rate adaptation in dy-namic environments., inD. Grunwald, R. Han, E. de Lara & C. S. Ellis, eds, ‘MobiSys’,ACM, pp. 118–131.

Jung-Hyuck, J. & Jayant, N. (2003), Performance Evaluation of Multiple IEEE 802.11bWlan Stations in the Presence of Bluetooth Radio Interference, in ‘IEEE InternationalConference on Communications’, Vol. 2, pp. 1163–1168.

Kaemarungsi, K. & Krishnamurthy, P. (2004), ‘Modeling of indoor positioning systemsbased on location fingerprinting’, IEEE Infocom .

Karygiannis, T. & Owens, L. (2002), ‘Wireless network security: 802.11, Bluetooth, andhandheld devices’, NIST Special Publication 800-48 .

Li, Z., Xu, W., Miller, R. & Trappe, W. (2006), Securing wireless systems via lowerlayer enforcements, in ‘Proceedings of the 5th ACM workshop on Wireless security(WiSe’06)’, ACM Press, New York, NY, USA, pp. 33–42.

Masthoff, J. (2004), ‘Group modeling: Selecting a sequence of television items to suit agroup of viewers’, User Modeling and User-Adapted Interaction 14(1), 37–85.

McCarthy, J. E. & Anagnost, T. D. (2000), Musicfx: an arbiter of group preferences forcomputer supported collaborative workouts, in ‘Proceedings of the ACM conferenceon Computer Supported Cooperative Work’, New York, USA, p. 348.

Microsoft (2008), ‘Wmi - windows management instrumentation’,http://msdn.microsoft.com/en-us/library/aa394582.aspx.

Navizon (n.d.), ‘Virtual gps’.URL: http://www.navizon.com/

Pirzada, A. and McDonald, C. (2004), Establishing trust in pure ad hoc networks, in ‘27thAustralian Computer Science Conference’.

Priddge, E. (2000), ‘An indoor absolute positioning system with no line of sight restric-tions and building-wide coverage’, IEEE International Conference on Robotics and

Automation 2, 1015–1022.

Punnoose, R., Tseng, R. & Stancil, D. (2001), Experimental Results for InterferenceBetween Bluetooth and IEEE 802.11b DSSS Systems, in ‘IEEE VTS Vehicular Te-chnology Conference’, Vol. 1, pp. 67–71.

Rocha, B. P. & Loureiro, A. A. (2007), Middleware de segurança adaptativo para compu-tação móvel, Master’s thesis, Universidade Federal de Minas Gerais.

148 27º Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos

Page 51: Minicursos SBRC 2009 - ce-resd.facom.ufms.brce-resd.facom.ufms.br/sbrc/2009/082.pdf · Capítulo 3 ComputaçãoUbíquaCientedeContexto:Desafios eTendências AntonioAlfredoFerreiraLoureiro,RicardoAugustoRabeloOliveira,Thais

Roy, N., Roy, A. & Das, S. K. (2006), Context-aware resource management in multi-inhabitant smart homes: A nash h-learning based approach, in ‘Proceedings of theFourth Annual IEEE International Conference on Pervasive Computing and Commu-nications’, Washington, DC, USA, pp. 148–158.

Schilit, B. N. & Theimer, M. M. (1994), ‘Disseminating active map information to mobilehosts’, Network, IEEE 8(5), 22–32.URL: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=313011

Schweitzer, C. M. (2006), Mecanismo de consolidação de confiança distribuída para redesad hoc, PhD thesis, Escola Politécnica da Universidade de São Paulo.

Schweitzer, C. M., Carvalho, T. C. M. B. & Ruggiero, W. V. (2006), ‘A Distributed Me-chanism for Trust Propagation and Consolidation in Ad Hoc Networks’, InternationalConference on Information Networking .

Shin, C. & Woo, W. (2005), Conflict resolution method utilizing context history forcontext-aware applications, in ‘Proceedings of the 1st International Workshop on Ex-ploiting Context Histories in Smart Environments (ECHISE’05)’, Munich, Germany,pp. –.

Velloso, P. B., Laufer, R. P., Duarte, O. M. & Pujolle, G. (2006), ‘Um Novo Modelo paraConfiança em Redes ad hoc’, XXIV Simpósio Brasileiro de Redes de Computadores .

Weiser, M. (1993a), ‘Some computer science issues in ubiquitous computing’, Commun.ACM 36(7), 75–84.

Weiser, M. (1993b), ‘Ubiquitous computing’, Computer 26(10), 71–72.

Livro Texto dos Minicursos 149