Embed Size (px)
Citation preview
1
UNIVERSIDADE ESTADUAL DE MARINGÁ
CENTRO DE TECNOLOGIA
DEPARTAMENTO DE INFORMÁTICA
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
ELAINE AUGUSTO PRAÇA
HANDPROV: Um modelo de controle de acesso a provedores de conteúdo
baseado em informações de contexto
Maringá
2012
2
ELAINE AUGUSTO PRAÇA
HANDPROV: Um modelo de controle de acesso a provedores de conteúdo
baseado em informações de contexto
Dissertação apresentada ao Programa de
Pós-Graduação em Ciência da Computação do
Departamento de Informática, Centro de Tecnologia
da Universidade Estadual de Maringá, como requisito
parcial para obtenção do título de Mestre em Ciência
da Computação.
Orientadora: Profª. Dra. Valéria Delisandra Feltrim.
Maringá
2012
3
Dados Internacionais de Catalogação-na-Publicação (CIP)
(Biblioteca Central - UEM, Maringá – PR., Brasil)
Praça, Elaine Augusto P895h HANDPROV : um modelo de controle de acesso a provedores
de conteúdo baseado em informações de contexto / Elaine
Augusto Praça. -- Maringá, 2012. 94 f. : il., figs., tabs.
Orientadora: Prof.a Dr.a Valéria Delisandra Feltrim.
Dissertação (mestrado) - Universidade Estadual de
Maringá, Centro de Tecnologia, Departamento de Informática,
Programa de Pós-Graduação em Ciência da Computação, 2012.
1. Controle de acesso - Autenticação. 2. Informática -
Controle de acesso. 3. Redes sem fio. 4. Handover. 5.
Informações cientes de contexto. 6. Context-aware. 7.
Serviços WEB. I. Feltrim, Valéria Delisandra, orient. II.
Universidade Estadual de Maringá, Centro de Tecnologia,
Departamento de Informática, Programa de Pós-Graduação em
Ciência da Computação. III. Título.
CDD 22.ed. 005.8
SOI-000229
4
5
OFERECIMENTO
Aos meus pais, irmãos e a toda a minha família,
pelo amor, gratidão e respeito que sinto por eles.
6
AGRADECIMENTOS
A DEUS, por ter me acompanhado e protegido em todas as viagens “solitárias” pela
PR-323, pela minha vida, saúde e disposição.
À Professora Dra. Luciana Andréia Fondazzi Martimiano, pela orientação, confiança,
paciência, compreensão e grande apoio dados ao longo do Mestrado e à Professora Dra.
Valéria Delisandra Feltrim, por assumir a orientação na finalização deste trabalho.
Aos meus pais, “Brandão” e “Verônica” e meus irmãos, “Tiago e Vanessa”, pelo
carinho, incentivo e estímulo que sempre me deram em todo o meu período acadêmico.
A minha segunda família, “Paula e Celso Rocha”, “Neusa e Oswaldo Rugo”, que me
cuidaram carinhosamente em todo o período residente em Maringá, um especial
obrigada, sem vocês perto de mim seria muito difícil a minha estadia nessa cidade.
As minhas avós, Maria e Dulcelina, tios, primos, cunhados, amigos e vizinhos, por
sempre se alegrarem com as minhas alegrias e, a minha sobrinha Mariana que veio ao
mundo para iluminar nossas vidas.
A minha amiga, Professora M. Sc. Thelma Elita Colanzi Lopes, pelos anos de
convivência, desde a graduação até o mestrado, a qual me incentivou e forneceu
primeiras informações de seleção e inscrição no Stricto Sensu da UEM.
A nossa querida secretária do departamento, Maria Inês Davanço Laccort, que sempre
esteve pronta para sanar todas as minhas dúvidas burocráticas e acadêmicas
proativamente.
A todos os amigos do mestrado, pela grande amizade formada nestes dois anos de curso
e, a todos os amigos do departamento, “calouros e veteranos” do curso de Mestrado da
UEM.
Ao professor Dr. Edson Moreira dos Santos e Roberto Sadao Yokoyama, pelas
orientações e atenção dadas nos dias em que fiquei no ICMC-USP – São Carlos e a
professora Dra. Renata Maria Porto Vanni do IFSP – Araraquara, pela orientação,
carinho e hospitalidade.
Aos amigos da UNIPAR, ALFA e IFPR, pelo apoio e compreensão de minhas ausências
nas jornadas de trabalho.
A todos aqueles, que direta ou indiretamente me apoiaram e me ajudaram neste projeto.
À CAPES, pelo apoio financeiro.
7
EPÍGRAFE
“Jamais considere seus estudos como uma obrigação, mas como uma oportunidade
invejável para aprender a conhecer a influência libertadora da beleza do reino do
espírito, para seu próprio prazer pessoal e para proveito da comunidade à qual seu
futuro trabalho pertencer.”
(Albert Einstein)
8
HANDPROV: Um modelo de controle de acesso a provedores de conteúdo
baseado em informações de contexto
RESUMO
Atualmente, tem acontecido a grande (r)evolução do uso de dispositivos móveis, não
somente entre usuários de maior poder aquisitivo, já que no lançamento dos primeiros
telefones celulares, o acesso a eles era mais evidente em um grupo seleto de usuários
(empresários, políticos e outras classes de interesse com possibilidades econômicas
compatíveis à aquisição – já que eram de alto custo). O baixo custo desses aparelhos
tem beneficiado milhares de pessoas na oportunidade de aquisição de um dispositivo
cuja função não seja exclusivamente efetuar e receber ligações. Os dispositivos móveis
antes utilizados exclusivamente para comunicação por voz, hoje dispõem de
funcionalidades que apóiam diversas aplicações, tais como acesso à Internet, a
conteúdo multimídia, a redes sociais, blogs, envio de SMS, etc. Essas aplicações na
maioria das vezes necessitam da autenticação junto a servidores. A autenticação,
geralmente concebida a partir de informações particulares (identificação e senha por
meio da interação do usuário com a interface) pode ser substituída, em algumas
aplicações, por informações de contexto (obtidas do ambiente, da aplicação, do
dispositivo e/ou do próprio usuário) ou ainda por métodos de identificação/autenticação
diferenciados, como geração automática de “senhas” (tokens) sem que o usuário tenha
nenhum tipo de interação direta na autenticação, facilitando o mecanismo de AAA
(Authentication, Authorization And Accounting – Autenticação, Autorização e
Auditoria). Neste trabalho de mestrado é descrito um modelo de autenticação baseado
em informações de contexto, denominado HANDPROV, no qual o usuário efetua
handover de provedor de serviço de forma transparente, ou seja, sem interagir
diretamente no AAA do sistema. Para validar o modelo descrito, foi desenvolvida uma
aplicação exemplo, com função de efetuar streaming de áudio em provedores dispostos
em uma rede sem fio.
Palavras-Chaves: Autenticação, Informações de contexto, Handover, Redes sem Fio,
Token.
9
HANDPROV: A model for access control to content providers based on
context information
ABSTRACT
Nowadays, the great (r)evolution of the mobile devices is taking place, not solely among higher
purchasing users, since the launch of the first cell phones, access to them was more evident in a
classified group of users (businessmen, politicians and other stratum with economic opportunities
compatibles to the acquisition of these devices - as they were expensive). The low cost of these
devices has supported thousands of people the opportunity to purchase a device whose function is not
only making and receiving calls. The first mobile devices used exclusively for voice communication,
but today they have features that support various applications such as access to the Internet,
multimedia content, social networks, blogs, sending SMS, etc.. These applications most often require
authentication on the server side. Authentication, usually conceived from private information (ID and
password through the user interaction with the interface) can be replaced in some applications, for
context information (obtained from the environment, application, device and / or the user's own) or by
differentiated methods of identification/authentication, such as automatic generation of "password"
(tokens) with no direct interaction from user, facilitating the AAA (Authentication, Authorization and
Accounting). In this dissertation is described an authentication model based on context information,
called HANDPROV, in which the user performs handover of content provider in a transparent
manner, without interacting directly to the AAA system. To validate the model described, we
developed an application, having individual functions of performing audio stream from service
providers arranged in a wireless network.
Keywords: Authentication, Context Information, handover, wireless network, token.
10
LISTA DE ILUSTRAÇÕES
Figura 1a: Rede sem fio infraestruturada. 22
Figura 1b: Rede sem fio ad hoc. 22
Figura 2 a e b) Dois modelos distintos de Digital Tablets. 28
Figura 2c: Palm. 28
Figura 2d: Netbook. 28
Figura 3: Nível de embarcamento da Computação Ubíqua (Lyytinen et al., 2002). 29
Figura 4: Aplicações dependentes de contexto conectadas ao CxFramework (Tosin, 2009). 48
Figura 5: Componentes da Arquitetura de Gerenciamento de Contexto (Gondor et al.,
2011).
51
Figura 6: Arquitetura SOHand (Vanni, 2009). 54
Figura 7: Arquitetura do modelo HANDPROV. 59
Figura 8: Modelo de Validação HANDPROV executado para apoio a Audio Streaming
Service.
68
Figura 9: Interface WEB do Broker, utilizado para confirmar a execução do mesmo. 69
Figura 10: Interface WEB do administrador do CP utilizado para o mesmo inserir o custo
monetário.
70
Figura 11a: Tela de login do usuário. 73
Figura 11b: Tela de preferências e busca do arquivo para streaming. 73
Figura 11c: Tela de execução do streaming de música. 73
Figura 12: Esquema da ocorrência de dois handovers em uma mesma solicitação de
streaming.
80
Figura 13: Diagrama de sequência da autenticação. 82
11
LISTA DE TABELAS
Tabela 1: Características entre tecnologias de redes sem fio (adaptado de Peterson e
Davie, 2007).
25
Tabela 2: Perspectivas para ocorrência de handover (Yokoyama, 2009). 26
Tabela 3: Fontes e Informações de Contexto (adaptado de Yokoyama, 2009). 55
Tabela 4: Descrição do caso de uso Controle de Acesso. 74
Tabela 5: Plataforma de desenvolvimento do HANDPROV. 76
12
LISTA DE ABREVIATURAS E SIGLAS
AAA Authentication, Authorization And Accounting
(Autenticação, Autorização e Tarifação)
API Application Programming Interface
(Inteface de Programação de Aplicativos)
APP Application (Aplicação)
APP Application (Aplicação)
BR Broker (Negociador)
CP Content Provider (Provedor de Conteúdo)
CP Content Provider (Provedor de Conteúdo)
CSCL Computer Supported Collaborative Learning
(Aprendizagem Colaborativa Suportada por Computador)
DGPS Diferential Global Positioning System
(Sistema Diferencial de Posicionamento Global)
DOHand Domain Ontology for Handovers
EaD Educação a Distância
GPRS General Packet Radio Service (Serviço de Rádio de Pacote Geral)
GPS Global Positioning System (Sistema de Posicionamento Global)
GSM Global System for Mobile Communications
(Sistema Global para Comunicação Móvel)
HANDPROV Handover em Provedor de Conteúdo
IEEE Institute of Electrical and Electronics Engineers
IMEI International Mobile Equipment Identity
(Identificação Internacional de Equipamento Móvel)
IP Internet Protocol (Protocolo Internet)
J2ME Java 2 Micro Edition
MD Device Mobile (Dispositivo Móvel)
MD Mobile Device (Dispositivo Móvel)
PDA Personal Digital Assistant (Assistente Pessoal Digital)
PIN Personal Identification Number (Número de Identificação Pessoal)
QoS Quality of Service (Qualidade de Serviço)
SMS Short Message Service (Serviço de Mensagens Curtas)
SOHand Service Oriented Handover (Serviço Orientado a Handover)
SP Service Provider (Provedor de Serviço)
TIC Tecnologia da Informação e Comunicação
UMTS Universal Mobile Telecommunication System
(Sistema Universal de Telecomunicação Móvel)
WEP Wired Equivalent Privacy
WiFi Wireless Fidelity
WiMAX Worldwide Interoperability for Microwave Access
WLAN Wireless Local Area Network (Área de Rede Sem Fio Local)
WMAN Wireless Metropolitan Area Network
WPA Wi-Fi Protected Access
WPAN Wireless Personal Area Network (Área de Rede Sem Fio Pessoal)
WWAN Wireless Wide Area Network (Área de Rede Sem Fio Mundial)
13
SUMÁRIO
CAPÍTULO 1 ......................................................................................................................... 15
INTRODUÇÃO ...................................................................................................................... 15
1.1 CONSIDERAÇÕES INICIAIS ................................................................................... 15
1.2 CONTEXTO E MOTIVAÇÃO .................................................................................. 17
1.3 OBJETIVOS ......................................................................................................... 19
1.4 ORGANIZAÇÃO DA DISSERTAÇÃO ........................................................................ 19
CAPÍTULO 2 ......................................................................................................................... 21
FUNDAMENTAÇÃO TEÓRICA ......................................................................................... 21
2.1 CONSIDERAÇÕES INICIAIS ................................................................................... 21
2.2 REDES SEM FIO .................................................................................................. 21
2.3 HANDOVER ........................................................................................................ 26
2.4 COMPUTAÇÃO MÓVEL, COMPUTAÇÃO PERVASIVA E COMPUTAÇÃO UBÍQUA ......... 27
2.5 COMPUTAÇÃO CIENTE DE CONTEXTO .................................................................. 30
2.6 SEGURANÇA DA INFORMAÇÃO ............................................................................ 35
2.7 SEGURANÇA NA COMPUTAÇÃO MÓVEL E UBÍQUA ................................................ 37
2.8 AUTENTICAÇÃO DE USUÁRIOS ............................................................................ 39
CAPÍTULO 3 ......................................................................................................................... 41
TRABALHOS RELACIONADOS ....................................................................................... 41
3.1 SMART CHAT GROUP: FERRAMENTA CIENTE DE CONTEXTO PARA FORMAÇÃO DE
GRUPOS .................................................................................................................. 41
3.2 AUTENTICAÇÃO AVANÇADA DE USUÁRIOS PARA DISPOSITIVOS MÓVEIS ............... 43
3.3 GAIAOS ............................................................................................................ 45
3.4 CXFRAMEWORK ................................................................................................ 47
3.5 PREVISÃO DE MÚSICAS PREFERIDAS BASEADAS EM CONTEXTO ............................ 50
3.6 ADAPTAÇÃO DINÂMICA DA CAPACIDADE DE REDES TELEFÔNICAS MÓVEIS USANDO
INFORMAÇÕES DE CONTEXTO ................................................................................... 51
3.7 SOHAND E DOHAND ......................................................................................... 52
3.8 CONSIDERAÇÕES FINAIS ..................................................................................... 56
14
CAPÍTULO 4 ......................................................................................................................... 57
O MODELO HANDPROV .................................................................................................... 57
4.1 ARQUITETURA DO MODELO HANDPROV ........................................................... 58
4.1.1 Autenticação via token ......................................................................................... 61
4.1.2 Broker (BR), Aplicação (APP) e Provedor de Serviços (SP) ........................... 62
4.2 CONSIDERAÇÕES FINAIS ..................................................................................... 63
CAPÍTULO 5 ......................................................................................................................... 65
UM SERVIÇO DE STREAMING DE ÁUDIO .................................................................... 65
BASEADO NO MODELO HANDPROV............................................................................. 65
5.1 INFORMAÇÕES DE CONTEXTO ............................................................................. 66
5.2 DESCRIÇÃO DAS PREFERÊNCIAS BASEADAS NO PERFIL DOS PROVEDORES ............. 67
5.3 DESCRIÇÃO DA VALIDAÇÃO DO MODELO HANDPROV ....................................... 68
5.4 DIAGRAMAS DE CASOS DE USO ........................................................................... 74
5.5 DIAGRAMA DE CLASSES ..................................................................................... 74
5.6 DESCRIÇÃO DO AMBIENTE DE DESENVOLVIMENTO .............................................. 75
5.6.1 Implementação do token ....................................................................................... 76
5.6.2 Implementação do handover ................................................................................ 78
5.6.3 Implementação da autenticação do usuário ...................................................... 82
5.7 RESULTADOS ..................................................................................................... 83
CAPÍTULO 6 ......................................................................................................................... 85
CONCLUSÕES ........................................................................................................... 85
6.1 TRABALHOS FUTUROS ........................................................................................ 86
REFERÊNCIAS...................................................................................................................... 89
ANEXOS ................................................................................................................................. 92
15
CAPÍTULO 1
Introdução
1.1 Considerações Iniciais
Atualmente, os dispositivos de comunicação sem fio, tais como Celulares,
SmartPhones, Palms, além de seu uso principal que é prover comunicação de voz entre
seus usuários, estão se tornando equipamentos computacionais com maior espaço de
armazenamento e maior capacidade de processamento.
A disseminação da banda larga, o acelerado crescimento no desenvolvimento
e a fácil acessibilidade aos dispositivos portáteis, vêm contribuindo para que a
comunicação entre usuários e sistemas seja mais comum nos ambientes onde
principalmente a comunicação sem fio esteja disponível, possibilitando assim a
transmissão de dados (principalmente multimídia) entre os usuários que estejam
conectados à rede.
Além de conexão de telefonia, outros serviços também podem ser
disponibilizados, como correio eletrônico, navegação na Internet (incluindo os diversos
sites de redes sociais, blogs, postagem de mensagens instantâneas e demais arquivos
multimídia – vídeo/foto), download e upload de arquivos na WEB, conexão com
servidores de banco de dados, paging1, transmissão de dados, fax, mensagens curtas de
até 160 caracteres - SMS (Short Message Service), WAP (Wireless Application
Protocol) para acesso a serviços de escalas de vôo, tempo atual e previsão do tempo,
informações de trânsito, cotação de ações, reservas de hotel, etc. Tudo isso se deve ao
fato de que as Tecnologias da Informação e Comunicação (TICs) estão cada vez mais
transparentes ao nosso cotidiano, e muitos conceitos têm surgido em novos nichos.
1 Sistema de transmissão de mensagens por radiofrequência (FM) para assinantes individuais.
16
O acesso às redes sociais e o oferecimento de serviços multimídia são alvos
principais dos fabricantes de celulares. Destes, o segundo está se tornando possível na
medida em que se aumentam a implantação e a abrangência das redes sem fio de maior
capacidade de largura de banda, juntamente com o potencial de processamento dos
microprocessadores e a capacidade das baterias destes dispositivos.
Além dos dispositivos sem fio padrão (àqueles que têm como principal
função a comunicação por voz), outros tipos de dispositivos, como canetas, crachás e
câmeras digitais, também estão apresentando funcionalidades por conexão sem fio,
muitas vezes utilizando-se da tecnologia Bluetooth. Desse modo, englobam-se os
serviços disponibilizados pelas redes ubíquas – redes estas nas quais a conexão do
usuário a um sistema de computação é feita a qualquer momento e em qualquer lugar,
por meio de um software ou uma interface específica, sem que o usuário perceba que
está utilizando tal sistema.
Um exemplo usual destes dispositivos é na identificação e autenticação de
usuários que se conectam em redes ubíquas simplesmente ao se apresentarem em um
espaço com cobertura, ou seja, o ambiente é sensitivo à presença do dispositivo que
emite ondas de rádio-frequência, identificando-o juntamente com o usuário (dono do
aparelho) no sistema.
A Computação Pervasiva proporciona uma interação natural entre a pessoa e
o ambiente, que requer uma mínima intervenção humana e acontece de forma
autônoma, interativa e relevante (Satyanarayanan, 2001). Essa mínima intervenção
humana pode ser provida por meio de informações monitoradas como: identificação,
preferências e histórico das atividades dos usuários. Essas informações são
armazenadas, processadas, comparadas e compartilhadas entre diversas aplicações em
diferentes domínios e em ambientes ubíquos, e geralmente em redes de comunicação
sem fio.
Nesses ambientes sem fio é interessante manter de forma transparente, tanto
a conectividade do usuário quanto a continuidade dos serviços disponibilizados durante
a conexão e principalmente ao se efetuar um handover.
17
Quando ocorre um handover (troca de conexão de um ponto de acesso para
outro sem perda ou interrupção dos serviços) é importante manter configurações de
identificação e autenticação do usuário dentro de ambos os sistemas. Esse processo de
autenticação nas conexões pode tornar-se uma tarefa repetitiva ao usuário, pois o
mesmo deverá informar seus dados todas as vezes que um handover for realizado (ação
que pode ser efetuada quando o usuário móvel conectado a um ponto de acesso Y se
aproxima de um ponto de acesso X com melhor qualidade de sinal se comparado ao
primeiro).
Em um cenário de redes sem fio composto por provedores de serviços e
conteúdos juntamente com dispositivos móveis dotados de aplicações que usufruam das
funcionalidades dessas redes, é interessante que haja mecanismos eficientes de
identificação e autenticação de usuários. Além da eficiência, é necessário manter a
transparência, tendo em vista que, dependendo dos contextos do sistema, handovers
podem ser efetuados constantemente e, pode-se tornar oneroso ao usuário, a cada
handover, ter que interagir com o sistema para efetuar sua identificação e autenticação.
Essa onerosidade decorre de situações em que o usuário é obrigado a, por exemplo,
digitar seu nome e senha, processo padrão de identificação e autenticação utilizado na
maioria dos sistemas de computação.
1.2 Contexto e Motivação
As inovações e evoluções em hardware e software que apóiam as TICs –
como o crescente mercado de dispositivos móveis (smartphones e tablets
principalmente) – vêm disponibilizando aos usuários dispositivos, serviços e aplicações
que têm despertado o interesse dos pesquisadores, principalmente no desenvolvimento
de arquiteturas e ambientes que usufruam das funcionalidades das redes sem fio e das
informações contidas nesses ambientes.
As aplicações estão sendo projetadas para automatizar as interações que
antes eram obrigatórias ao se executar um “programa de computador”, tais como busca
18
automática de redes e equipamentos disponíveis, conexão em ambientes, identificação e
autenticação de usuários, dentre outros.
Interações sempre são necessárias quando se pretende acessar sistemas de
computação. Em se tratando de redes sem fio, tem-se que num ambiente disponível e
visível a todos pode ser obrigatório que um usuário (via dispositivo móvel) efetue a
conexão mediante um mecanismo de AAA (Authentication, Authorization and
Accounting) – Autenticação, Autorização e Auditoria.
Para um usuário, essas interações acabam se tornando cansativas. Imagine
um ambiente sem fio em que um usuário já autenticado no provedor de acesso à rede
deseja se conectar a um provedor de conteúdo disponível para consumir os
serviços/conteúdos existentes neste provedor usando seu dispositivo móvel. Esse
usuário possui algumas informações particulares (identificação, senha, preferências,
atividades registradas em históricos) configuradas em seu aparelho, assim como os
provedores de serviços também dispõem de informações (status, latência, número de
clientes conectados, custo da conexão, tipo de serviço ofertado, etc.) que podem ser
contextualizadas no ambiente, formando assim o conjunto de informações de contexto
do ambiente descrito. Uma análise dessas informações de contexto é feita para auxiliar
o usuário em qual desses provedores disponíveis deve ser efetivada a sua conexão.
Esses contextos são importantes na decisão da conexão inicial e também em
momentos oportunos em que, havendo mudança em contextos atuais, pode-se haver a
necessidade de troca de provedor durante o serviço (handover). Essa troca pode ser
feita em virtude do surgimento de provedores que melhor atendam às necessidades do
usuário.
Essas decisões juntamente com os handovers, seguidas das devidas
identificações e autenticações, devem ser executadas de maneira automática e
transparente, sem que o usuário necessite interagir diretamente nessas ações, pois essas
atividades podem ser executadas periodicamente, causando muitas interações diretas
com o usuário, o que pode se tornar um tipo de atividade repetitiva.
A arquitetura SOHand (Moreira et al, 2003) descrita na Seção 3.7 é uma das
motivações deste trabalho, em que são identificadas as usabilidades das informações de
19
contexto para decisões automáticas de conexão em ambientes sem fio. Na SOHand, o
contexto é utilizado para decisão de conexão nos provedores de acesso. No
HANDPROV, o contexto é utilizado para decisão de conexão nos provedores de
conteúdo (serviços).
1.3 Objetivos
Diante do exposto, este trabalho propõe um modelo de controle de acesso de
usuários baseado em informações de contexto com o intuito de automatizar o processo
de identificação e autenticação dos mesmos a cada conexão ou handover. Esse
mecanismo deve ser executado de forma transparente ao usuário, ou seja, sem que o
mesmo interaja com o sistema ao se associar aos provedores de serviço que porventura
sejam escolhidos para a conexão do usuário e posterior execução do serviço.
Para validar o modelo, foi desenvolvida uma aplicação para um dispositivo
móvel que permite a execução de um streaming de áudio. Esse arquivo de áudio está
armazenado em provedores de conteúdo disponíveis na rede WiFi, na qual o dispositivo
móvel já se encontra autenticado no ponto de acesso, fazendo assim parte desta rede.
A autenticação do dispositivo móvel para acesso aos provedores de conteúdo
é feita por meio de um token gerado a partir de informações de contexto (do usuário e
do dispositivo móvel) e a decisão para efetuar a conexão (ou handover) nos referidos
provedores é auxiliada por meio de um Broker (gerente) que disponibiliza esse token
aos provedores, bem como informa ao dispositivo móvel (aplicativo) qual desses
provedores atendem às preferências do usuário, configuradas no próprio aplicativo de
streaming pelo usuário do serviço.
1.4 Organização da Dissertação
Esta dissertação está organizada em sete capítulos.
20
Neste primeiro capítulo foram apresentados os objetivos, o contexto e
motivação e uma introdução sobre assuntos abordados durante o trabalho.
No segundo capítulo, é apresentada a fundamentação teórica elucidando os
conceitos necessários para o desenvolvimento deste trabalho.
No terceiro capítulo, são abordados trabalhos relacionados em andamento ou
já concluídos, que abordam informações de contexto, utilizando-as em diversos
processos nos ambientes/arquiteturas propostos nos referidos trabalhos.
No quarto capítulo, é apresentado o modelo HANDPROV, objeto deste
trabalho, documentando requisitos e descrevendo a arquitetura do modelo.
No quinto capítulo, é apresentado o mecanismo de validação do modelo
proposto, em que é simulado um serviço de streaming com autenticação por token,
seguindo as premissas do modelo HANDPROV, assim como a descrição das
preferências e do ambiente de desenvolvimento. Também são apresentados os
resultados obtidos nas simulações feitas no ambiente sem fio preparado para validar o
modelo HANDPROV.
No sexto capítulo, têm-se a conclusão deste trabalho, apresentando uma
visão das abordagens, desenvolvimento, análise do trabalho realizado e os trabalhos
futuros.
Por fim, têm-se as referências dos trabalhos, sites, livros e/ou outros
materiais utilizados para a elaboração desta dissertação de mestrado seguido dos
anexos.
21
CAPÍTULO 2
Fundamentação Teórica
2.1 Considerações Iniciais
Para introdução e aprofundamento do conhecimento dos assuntos abordados,
foi realizada revisão bibliográfica acerca dos conceitos envolvidos neste trabalho, tais
como Redes sem Fio, Computação Móvel, Computação Pervasiva, Computação Ubíqua,
Computação Ciente de Contexto, Informações de Contexto, Segurança da Informação,
dentre outros.
2.2 Redes sem Fio
Para Tanenbaum (2003), redes sem fio são redes de computadores e de
telecomunicação que utilizam ondas eletromagnéticas para transmitir informações por
meio do ar, sendo assim sem cabeamento estruturado.
As redes sem fio possibilitam a conexão móvel, disponibilizando serviços e
informações aos usuários em quaisquer locais, estando estes em área abrangente do
sinal favorecido pelos pontos de acesso. Essa tecnologia tem sido amplamente utilizada
no auxílio a sistemas de redes de sensores, monitoramento ambiental, vigilância,
automação predial (temperatura, ventilação e condicionamento de ar, etc), automação
industrial (controle de processos – pressão, temperatura, vibração, velocidade,
iluminação, etc), automatização de pedágios rodoviários, medicina, dentre outras
aplicações que são beneficiadas pelo uso da comunicação sem fio, seja pelo fato da não
possibilidade de implantação de cabos estruturados ou meramente por força maior de
dissipação e fornecimento do acesso em raios maiores por difusão do sinal sem fio.
22
Nas redes móveis sem fio é possível encontrar basicamente dois tipos de
redes: as infraestruturadas e as ad hoc.
Na primeira arquitetura, como ilustra a Figura 1a, um host móvel (HM) está
em contato direto com um access point (AP), sendo este conectado a uma rede fixa.
Este access point centraliza todos os hosts móveis. Sendo assim, mesmo que dois hosts
móveis estejam mais próximos entre si do que do access point, eles obrigatoriamente
devem se interconectar passando antes pelo AP, ou seja, não pode haver comunicação
direta entre eles.
Nas redes ad hoc - também conhecidas por MANET (Mobile Ad hoc
NETwork) – os dispositivos móveis conectam-se diretamente, ou seja, não há
necessidade de um access point centralizando as conexões, como ilustrado na Figura
1b. Essas redes são utilizadas dinamicamente em ambientes em que há a necessidade de
uma rápida instalação de uma rede de comunicação e/ou em ambientes onde não há uma
infraestrutura (cabeada) já instalada. Todos os hosts móveis são dependentes entre si
para manter a conectividade da rede.
Com a mobilidade, os hosts movem-se frequente e imprevisivelmente,
acarretando a constante reconfiguração da rede preestabelecida, tendo em vista que
alguns hosts podem ficar inalcançáveis uns aos outros.
Figura 1a: Rede sem fio
infraestruturada. Figura 1b: Rede sem fio ad hoc.
23
Atualmente, as redes sem fio já estão disseminadas na maioria dos
ambientes comerciais, educacionais, sejam públicos ou privados, a um custo razoável.
Isto possibilita que as pessoas que possuem equipamentos com tecnologias de conexão
sem fio tornem-se usuários dessas redes, podendo usufruir dos serviços disponíveis.
Essa característica propicia a disseminação dos dispositivos móveis, tornando seus
preços mais atrativos e aumentando a gama de aplicações desenvolvidas para os
mesmos.
Além do uso profissional, as redes de sensores sem fio também estão
presentes em sistemas simples, nos quais usuários comuns podem usufruir dos serviços
e facilidades, como por exemplo, pela utilização da tecnologia Bluetooth para redes
pessoais facilmente percebidas quando usuários de dispositivos com essa tecnologia
trocam e compartilham dados entre si.
Bluetooth é uma das tecnologias mais utilizadas em redes WPAN (Wireless
Personal Area Network) – padrão IEEE 802.15 – para conexão entre dispositivos
populares como telefones celulares, videogames, câmeras digitais, impressoras,
scanners, por meio de uma banda de frequência de rádio de curto alcance (2,4 GHz)
podendo ter uma taxa de transferência de até 1 Mbps alcançando em média conexões
distantes até 10 metros.
Outra tecnologia amplamente utilizada é a WiFi (Wireless Fidelity) – padrão
IEEE 802.11 – com a qual a maioria dos dispositivos móveis já estão providos de
fábrica, tendo em vista a redução do custo de fabricação bem como pelo fato desse
padrão não necessitar de licença de instalação/operação, tornando-a bastante atrativa.
Além disso, WiFi oferece cobertura de transmissão maior, favorecendo assim as WLAN
(Wireless Local Area Network). Opera nas faixas de frequência de 2,4 GHz, 3,6 GHz e
5 GHz, sendo que em 2,4 GHz não há interferência pelo Bluetooth pelo fato das duas
tecnologias utilizarem métodos de multiplexação distintos.
A tecnologia WiMax (Worldwide Interoperability for Microwave Access) –
padrão IEEE 802.16 – já forma uma rede de amplitude maior, podendo chegar a até 50
Km, caracterizando-a como uma WMAN (Wireless Metropolitan Area Network).
Utiliza várias frequências espectrais: a versão IEEE 802.16 especificou a faixa de 10 a
24
66 GHz; a versão IEEE 802.16a inclui a faixa de 2 a 11 GHz suportando Redes Mesh2;
a versão IEEE 802.16e utiliza a faixa de 2 a 6 GHz (excluindo as Redes Mesh).
Além dessas tecnologias, a tendência crescente da utilização de aparelhos
celulares com suporte a redes sem fio instigou a especificação da tecnologia
UMTS/GSM/GPRS (Universal Mobile Telecommunications System/ Global System for
Mobile Communications/ General Packet Radio Service), tornando-a líder no mercado
em sistemas digitais para comunicação móvel. Isso é reflexo do baixo custo e demanda
no mercado, tendo em vista a gama de serviços, aplicativos e qualidade disponíveis
nestes dispositivos. Por meio de GPRS, os aparelhos celulares usando UMTS podem
enviar e receber dados por meio da mesma estrutura de comunicação digital de voz.
O conceito de redes sem fio 4G (Fourth Generation) tem abrangido redes de
comunicação sem fio de diferentes tecnologias nos ambientes de comunicação. Dessa
forma, a intercomunicação destas diversas tecnologias deve garantir a disponibilização
de serviços e o compartilhamento de recursos entre os usuários de forma transparente e
automática quando efetuado um handover. Para Berndt (2008), a quarta geração é
pautada no modelo de negócios centrado no usuário. Portanto, esta nova geração deverá
oferecer essencialmente: alta qualidade de voz, vídeo com alta definição, elevada taxa
de transmissão, conexão mais apropriada entre as redes disponíveis, uma interface
personalizada e amigável para o usuário levando em consideração a diversidade dos
dispositivos móveis (tamanho de tela, memória, autonomia da bateria, etc), serviços
personalizados (perfis, preferências e informações de contexto) e uma arquitetura aberta
que favoreça os interessados (operadoras, provedores de serviços, clientes, etc) e tenha
como base o protocolo IP.
A Tabela 1 resume algumas características das diferentes tecnologias.
2 Redes sem Fio ad hoc fixas, em que cada nó funciona não só como um host, mas também como um roteador, encaminhando
pacotes diretamente por meio de uma conexão em “malha”.
25
Tabela 1: Características entre tecnologias de redes sem fio
(adaptado de Peterson e Davie, 2007).
Bluetooth [802.15]
WiFi [802.11g]
WiMax [802.16e]
Celular 3G UMTS/GSM
Classificação WPAN WLAN WMAN WWAN
Consumo de energia do dispositivo
Baixo Alto Alto Baixo
Transmissão Dados e voz Dados Dados e voz Dados e voz
Taxa máxima de transferência de
dados 1 Mbit/s 54 Mbit/s 75 Mbit/s 2 Mb/s
Freqüência de operação
2.4 GHz 2.4 / 5.86 GHz 10 a 60 GHz
2 a 11 GHz
900 / 1800 /
1900 GHz
Alcance aproximado 10 a 100 m
30 m em
ambientes
fechados; 100 m
em ambientes
abertos
10 Km 1 a 5 km em
cidades
Aplicações
Substituição de
cabos para
interconexão
de dispositivos,
compartilhando
dados dentro
de Redes
Pessoais
Conectar
computadores e
dispositivos
móveis/portáteis
a Redes Locais
Conectar
computadores e
dispositivos
móveis/portáteis
a Redes
Metropolitanas
Conectar
celulares às
estações de
telefonia
móvel,
mensagem
multimídia e
acesso à
Internet
Tem-se ainda que as redes sem fio 4G são cada vez mais necessárias, devido
ao crescimento da demanda por serviços móveis de dados, em que os usuários não mais
se conectam a um só tipo de tecnologia. Além disso, devido à mobilidade, esses
serviços devem estar sempre disponíveis ao acesso independentemente da tecnologia
utilizada.
Para Vanni (2009), o termo Redes 4G é utilizado para descrever sistemas de
comunicação sem fio de alto desempenho – com vazão de dados muito alta. Além disso,
as redes 4G podem ser vistas como redes convergentes em que redes heterogêneas
coexistem harmonicamente. Essa heterogeneidade deve alcançar aplicações em nível de
tecnologia de comunicação, ao domínio de gerenciamento e ao serviço oferecido pelas
redes, fazendo com que os diversos tipos de usuários possam desfrutar do uso das redes
4G de forma o mais transparente possível.
26
2.3 Handover
Para Manner e Kojo (2004), handover ou handoff é o processo no qual o nó
móvel troca o ponto de conexão à rede ou quando ocorre uma tentativa dessa troca.
Um nó móvel é um dispositivo com capacidade de se locomover em
ambientes cujo espaço disponibiliza redes com pontos de conexão sem fio,
possibilitando ao usuário se conectar à rede, utilizando ou não serviços de roteamento
de pacotes.
Nos trabalhos são encontradas várias classificações para a ocorrência de
handover. Yokoyama (2009) descreve uma tabela de handover por várias perspectivas.
Tabela 2: Perspectivas para ocorrência de handover (adaptado de Yokoyama, 2009).
Perspectiva Tipo Definição
Tecnologia
Horizontal ou
Homogêneo
Quando o nó móvel é deslocado entre pontos de acesso de
mesma tecnologia de comunicação.
Vertical ou
Heterogêneo
Quando o nó móvel é deslocado entre pontos de acesso de
diferente tecnologia de comunicação.
Decisão
Assistido pelo
nó móvel
Informação e medidas obtidas do nó móvel são passadas
para o roteador de acesso que decide sobre a execução do
handover.
Assistido pela
rede
Quando a rede de acesso recolhe informações que podem
ser utilizadas pelo nó móvel na decisão do handover.
Não assistido Nenhuma informação para ajudar na decisão do handover é
trocada entre o nó móvel e o roteador de acesso.
Procedimento
Proativo
É caracterizado por ser uma troca planejada por meio da
monitoração de parâmetros da rede, ou seja, feita antes da
desconexão.
Reativo É uma transição inesperada, não são feitas indicações para
auxiliar na passagem para a nova rede.
Conexão
Soft handover
Permite o nó móvel conectar ao mesmo tempo no próximo
ponto de acesso e continuar com o original durante o
handover.
Hard handover
Somente se conecta a um ponto de acesso por vez, ou seja,
desconecta do ponto de acesso atual para depois se
conectar ao próximo.
27
Além da classificação acima, Moreira et al. (2007) também relaciona a
ocorrência do handover atendendo às preferências do usuário, o que visa a melhorar a
experiência do mesmo durante a utilização de um serviço disponível na rede. É nessa
perspectiva que o HANDPROV foi desenvolvido, ou seja, não relacionado ao ponto de
acesso, mas sim às preferências do usuário ao utilizar um serviço.
2.4 Computação Móvel, Computação Pervasiva e
Computação Ubíqua
A Computação Móvel baseia-se no aumento de capacidade de mover
fisicamente serviços computacionais, ou seja, o computador torna-se um dispositivo
sempre presente que expande a capacidade do usuário em utilizar os serviços que um
computador oferece, independentemente de sua localização.
Contudo, uma limitação da computação móvel é que o modelo
computacional não muda enquanto os usuários se movem, isso porque o dispositivo não
é capaz de obter automaticamente informações sobre o contexto (características do
ambiente, usuário, dispositivo, etc) no qual a computação deve ocorrer e ajustá-la
conforme a necessidade do usuário e do próprio sistema.
Loureiro e Mateus (2004) afirmam que a Computação Móvel é um
paradigma computacional que tem como objetivo prover ao usuário acesso permanente
a uma rede fixa ou móvel independentemente de sua posição física, com capacidade de
acessar informações, aplicações e serviços a qualquer lugar e a qualquer momento.
Além da mobilidade que é uma propriedade inerente aos dispositivos móveis
conectados a redes sem fio, foram também adicionadas algumas funcionalidades para
incrementar o uso dos dispositivos móveis além da comunicação sem fio, surgindo
assim o termo pervasivo.
Para Araujo (2003), a Computação Pervasiva implica que o computador está
embarcado no ambiente de forma invisível para o usuário. Nessa concepção, o
computador tem a capacidade de obter informação do ambiente no qual ele está
embarcado e utilizá-la para dinamicamente construir modelos computacionais, ou seja,
28
controlar, configurar e ajustar a aplicação para melhor atender às necessidades do
dispositivo do usuário.
O ambiente também pode e deve ser capaz de detectar outros dispositivos
que venham a fazer parte dele. Dessa interação surge a capacidade de computadores
agirem de forma “inteligente” no ambiente no qual os usuários se movem, sendo que o
ambiente é povoado por sensores e serviços computacionais.
Já a Computação Ubíqua (Ubicomp) beneficia-se dos avanços da
Computação Móvel e da Computação Pervasiva. Mark Weiser (1991) idealizou a
expressão Computação Ubíqua ao perceber que as interações tradicionais entre usuário
e máquina – via dispositivos como mouse, teclado e monitor – iriam além desse simples
modelo padrão, em que o ser humano utiliza de dispositivos de entrada para interagir
diretamente com um computador.
Em virtude disso, diversos dispositivos eletrônicos providos de interfaces de
interação não muito convencionais como PDAs (Personal Digital Assistants, Digital
Tablets (Pranchetas sensíveis ao toque), Lousas Eletrônicas, Telefones Celulares,
Palms, Notebooks, Netbooks e outros (Figura 2) com recursos multimídia começaram a
ser desenvolvidos com arquiteturas e funcionalidades acessíveis às aplicações baseadas
na UbiComp.
Figura 2: a e b: Dois modelos distintos de Digital Tablets. c: Palm. d: Netbook.
A Computação Ubíqua surge então da necessidade de se integrar mobilidade
com a funcionalidade da Computação Pervasiva, ou seja, qualquer dispositivo
computacional, enquanto em movimento, pode construir, dinamicamente, modelos
29
computacionais dos ambientes enquanto que os usuários se movem e configurar seus
serviços dependendo da necessidade.
Para Abowd et al. (2002), o entendimento dos hábitos humanos, a criação de
novos dispositivos interativos e a interação entre os dispositivos para permitirem uma
experiência realística são fatores essenciais para a evolução das diferentes maneiras de
captura de informações exigidas em computação ubíqua.
Lyytinen e Yoo (2002) ilustram as dimensões da Computação Ubíqua
conforme mostra a Figura 3. O nível de embarcamento indica, de maneira geral, o grau
de inteligência dos computadores, embutidos em um ambiente pervasivo para detectar,
explorar e construir dinamicamente modelos de seus ambientes.
Figura 3: Nível de embarcamento da Computação Ubíqua (Lyytinen et al., 2002).
Sendo assim, a Computação Ubíqua pode ser vista como a junção dos altos
graus das dimensões da Computação Pervasiva e da Computação Móvel, pois um
dispositivo embarcado em algum ambiente não necessariamente é também um
dispositivo móvel. Ainda pode-se dizer que na Computação Ubíqua tem-se uma visão
de conectividade sem fronteiras, na qual os dispositivos e suas apl icações movem-se
juntamente com o usuário, de forma transparente entre diversos tipos de redes, tais
como redes sem fio de longa, média ou curta distância.
30
2.5 Computação Ciente de Contexto
Para Dey e Abowd (2000), contexto é qualquer informação que pode ser
utilizada para caracterizar a situação de uma entidade que é considerada relevante entre
o usuário e a aplicação.
Outra definição (Satyanarayanan, 2001) diz que o contexto do usuário de
uma aplicação ciente de contexto consiste de atributos, como localização física, estado
fisiológico, estado emocional, histórico pessoal, padrões diários de comportamento,
entre outros, que se fornecidos para um sistema podem ser usados para tomada de
decisões sem necessidade de interromper o usuário a todo momento. Por exemplo, em
um hospital, um médico carregando um PDA ligado a um sistema ciente de contexto, ao
aproximar-se do leito de um de seus pacientes, tem os dados clínicos mais relevantes
desse paciente mostrados automaticamente nesse PDA (Bardram, 2004).
Schilit e Theimer (1994) definem contexto como a indicação da localização
e a identificação de pessoas e objetos ao redor, situações sociais e condições
ambientais, como iluminação e barulho, apontando três aspectos importantes de
contexto: onde o usuário está, com quem o usuário está e quais os recursos próximos ao
usuário.
A Computação Ciente de Contexto se refere à ideia dos computadores
poderem tanto perceber quanto reagir ao ambiente em que estão inseridos para facilitar
as atividades humanas. Os dispositivos teriam informações sobre as circunstâncias em
que se encontram e, baseados em regras ou estímulos inteligentes, eles reagiriam de
acordo a essas circunstâncias.
Mark Weiser (1991) já prevera o desenvolvimento de dispositivos capazes
de reconhecer seus donos e se adaptar às mudanças do ambiente em que se encontram.
Para que haja esse reconhecimento, são necessários alguns parâmetros e que os
dispositivos sejam capazes de capturar e disponibilizar tais informações para que os
sistemas se adaptem a cada usuário.
Para Dey (2001), Ciência de Contexto é um meio de atenuar a sobrecarga de
informação, já que sistemas que usam essa tecnologia ajudam a localizar e apresentar
dados relevantes aos seus usuários, baseando-se em informações contextuais (por
31
exemplo: identificação do usuário, papel que este desempenha, sua localização,
dispositivo que está usando). Com base na combinação dessas informações, aplicações
podem adaptar-se a diferentes situações e comportar-se de forma ótima para cada uma
delas.
Abowd e Mynatt (2000) apresentam as dimensões contextuais como sendo:
a) Quem (Who): informação referente à entidade que realiza alguma ação ou
operação podendo essa entidade ser um usuário, um dispositivo, uma aplicação, um
sistema ou até mesmo um agente de software (um serviço). O usuário é o elemento
central de um ambiente pervasivo e a resposta do ambiente depende da pessoa. O
sistema tem que identificar o usuário e conhecer suas preferências e intenções .
b) Onde (Where): informação sobre a localização das entidades e dos
objetos (dispositivos, sensores) em um determinado espaço ou ambiente. Diz também
respeito à relação espacial entre lugares, objetos e pessoas.
c) Quando (When): informações temporais das atividades das entidades e os
eventos que acontecem em um ambiente pervasivo. Como exemplo, têm-se a duração
das atividades, o tempo que um determinado evento inicia e termina, definição das
rotinas de uma pessoa por meio de um histórico de atividades; podem determinar certas
preferências.
d) O Que (What): informações relacionadas às atividades ou às ações feitas
pelas entidades ou dispositivos. Esta é uma dimensão de contexto mais complexa que
as anteriores, pois está relacionada com elas e não é facilmente fornecida por um
sensor, sendo inferida ou derivada usando outras informações de contexto. Uma
atividade é executada em um determinado local (where) e momento (when). De acordo
com o domínio de aplicação, existe um conjunto de atividades a serem efetuadas pelas
entidades (who), por exemplo: cozinhar, caminhar, assistir TV, estudar.
e) Por Que (Why): estabelece uma relação com o motivo pelo qual é feita
uma determinada ação. As motivações das pessoas, por exemplo, podem ser inferidas
em geral combinando outras dimensões contextuais e considerando parâmetros do
usuário como seu estado emocional, seu batimento cardíaco, entonação de voz, entre
outras.
32
Dentre estas dimensões, a informação de localização tem sido amplamente
utilizada em sistemas cientes de contexto devido ao fato de que os modos de
localização (por exemplo, GPS – Global Positioning System) interagem com mais
facilidade com sistemas pervasivos.
O GPS é um sistema de geolocalização que cobre toda a superfície do globo
terrestre oferecendo um erro de estimativa máximo de 10 metros em áreas abertas,
podendo este erro ser reduzido para a ordem de centímetros com o uso de uma estação
de referência, em um sistema de DGPS (Diferential Global Positioning System)
(Wübbena et al., 1996).
Para Brosso (2006), a definição de contexto e das dimensões contextuais e
semânticas ajuda a decidir quais informações são relevantes para um determinado
sistema, porém, é necessário analisar os requisitos e modelar as informações
necessárias que cada dimensão pode fornecer. Em geral, há uma tendência para o
desenvolvimento de um modelo de contexto de usuário que sobrepõe problemas
associados, e com isso há uma generalização ao classificar contexto em aspectos
temporais, estático e dinâmico.
Outra classificação para informações de contexto está baseada em suas
associações, as quais podem ser estáticas ou dinâmicas (Henricksen et al., 2002). O
contexto estático corresponde às informações que permanecem fixas durante o tempo
de vida da entidade, como os números de CPF (Cadastro de Pessoa Física) ou RG
(Registro Geral) de uma pessoa, que são documentos únicos, pessoais e intransferíveis.
O contexto dinâmico tem características de persistência relacionadas à forma como as
informações de contexto são obtidas, podendo ser obtidas por sensores, definidas por
usuários ou serviços ou de outras fontes. Como exemplos, têm-se:
a) Percebida por sensores ou sentida: informação gerada por meio de
sensores com alguma precisão, por exemplo: localização de um usuário, luminosidade,
umidade e temperatura de um ambiente.
b) Definida pelo usuário ou explícita: o usuário fornece alguns valores à
aplicação durante uma configuração, sendo que valores padrão devem sempre estar
disponíveis, por exemplo: senhas de acesso ou dados de uma agenda pessoal.
33
c) Fornecida por algum serviço: a informação é dada por algum fornecedor
de serviços, por exemplo, um sistema no qual há uma lista de atividades da pessoa.
d) Derivada: a qual pode ser aprendida ou inferida, por exemplo, utilizando
sistemas de inteligência artificial, que analisam as informações e caracterizam um
contexto baseado nos dados de entrada e/ou pela análise de um conjunto de
comportamentos do usuário.
Segundo Dey et al. (2000) existem ainda três categorias de características
que aplicações cientes de contexto podem suportar:
- Apresentação de informações e serviços ao usuário: fornecer de forma
apropriada informação e serviços que o usuário requeira. É conveniente ressaltar que o
usuário tem que ser assistido e não deve ser interrompido ou incomodado com o
serviço. Ex.: atualização de uma lista de impressoras disponíveis e próximas a um
usuário que esteja se deslocando em um ambiente.
- Execução automática dos serviços do usuário: a execução dos serviços
pode acontecer de forma automática e personalizada. Ex. controle de luminosidade
enquanto há (ou não) pessoas em um determinado recinto.
- União de informações de contexto para uso posterior: aproveita a
informação anterior juntamente com a situação atual, permitindo que o ambiente
encontre relações na informação e forneça novos serviços baseados nos anter iores. Ex.:
um usuário ou entidade cria uma mensagem virtual e a associa a um dispositivo
compartilhado (visor), outro usuário ao se aproximar desse visor em outro momento
poderá visualizar tal mensagem.
Esses dados de contexto coletados corretamente e informados aos sistemas
podem prover ótimas interações humano-computador. Essa característica é uma das
principais abordadas em sistemas cientes de contexto, nos quais tais informações são
utilizadas de forma transparente com um mínimo de intervenção possível do usuário,
além de determinar quais ações ou serviços serão executados de maneira personalizada
a partir das informações de contexto particulares de cada usuário.
Alguns requisitos são definidos por Dey (2001) como sugestão para o
desenvolvimento de aplicações cientes de contexto e infraestruturas de suporte a tais
aplicações:
34
- Especificação de informações de contexto: deve haver um mecanismo
que permita aos desenvolvedores expressarem informações de contexto em fragmentos
simples ou múltiplos, expressarem relacionamentos entre informações contextuais,
notificarem a disponibilização de informações de contexto atualizadas e proverem
suporte a especificações originadas de diversas aplicações.
- Captura e uso de informações de contexto: aplicações cientes de
contexto devem utilizar técnicas de implementação eficientes para facilitar o reúso e a
generalização das informações capturadas, implementando, por exemplo, técnicas de
consulta e notificação de informações atualizadas. As informações devem ser também
classificadas de acordo com sua relevância.
- Interpretação de informações de contexto: as informações de contexto
devem ser interpretadas antes de serem utilizadas por aplicações, bem como devem ser
classificadas corretamente para que a recuperação das informações seja facilitada
quando necessária.
- Comunicação distribuída e transparente: os sensores responsáveis pela
captura de informações de contexto devem disponibilizá-las de maneira transparente e
por meio de protocolos de comunicação e sistemas de codificação e decodificação
padronizados.
- Disponibilidade de componentes de captura de informações de
contexto: os componentes responsáveis pela captura de informações contextuais devem
estar sempre disponíveis, executando a captura de forma independente e com
capacidade de disponibilização de informações para diversas aplicações
simultaneamente.
- Armazenamento de informações de contexto: a importância de manter
informações históricas é um requisito relacionado à disponibilidade dos componentes
responsáveis pela captura de informações de contexto. As aplicações devem ser capazes
de inferir outros valores de contexto ou estabelecer tendências baseadas em históricos.
Para manter um histórico contextual, os componentes devem estar aptos a capturar
informações contextuais continuamente, mesmo quando as informações não são
solicitadas.
35
- Descoberta de recursos: dispositivos de captura de informações de
contexto devem especificar quais tipos de informações de contexto eles disponibilizam,
sua localização e interfaces. O mecanismo de descoberta de recursos pode ser
combinado com o mecanismo de especificação e com os componentes de captura, com
o objetivo de determinar quais situações podem ser capturadas ou se uma determinada
requisição de informação de contexto pode ser realizada pela infraestrutura em
execução.
Essas características devem ser consideradas para que as informações de
contexto possam ser utilizadas de maneira dinâmica e personalizada, garantindo assim
que as aplicações (sistemas) possam inferí-las em tempo hábil e consumí-las o máximo
possível.
2.6 Segurança da Informação
Segundo a norma NBR ISO/IEC 17999:2005 (ABNT, 2005), os conceitos
principais que definem segurança são: preservação da confidencialidade, da integridade
e da disponibilidade da informação; adicionalmente, outras propriedades, como
autenticidade, autorização, não repúdio e confiabilidade, podem também estar
envolvidas. Para garantir a segurança seguindo essas especificações, são utilizados
vários mecanismos como: criptografia, assinatura digital, funções hash, certificações,
firewalls, replicação de dados, dentre diversas outras ferramentas e controles lógicos no
auxílio do cumprimento e garantia de que os dados realmente estão seguros.
Confidencialidade consiste na proteção contra leitura ou cópia da
informação por quem não está explicitamente autorizado pelo seu proprietário. Essa
proteção deve incluir informações de propriedade do usuário bem como as geradas em
razão do uso de algum sistema e que possam permitir a inferência de informações
confidenciais, por exemplo, registros de acesso ou identificações de estações de
trabalho. Sigilo e privacidade são sinônimos de confidencialidade. Segundo CERT.BR,
a criptografia é a ciência e arte de escrever mensagens em forma cifrada ou em código.
É parte de um campo de estudos que trata das comunicações secretas , visando a manter
a confidencialidade dos dados. Os métodos de criptografia atuais são seguros e
36
eficientes e baseiam-se no uso de uma ou mais chaves. A chave é uma sequência de
caracteres que pode conter letras, dígitos e símbolos (como uma senha), e que é
convertida em um número, que é utilizado pelos métodos de criptografia para codificar
e decodificar mensagens. Há vários algoritmos criptográficos, dentre eles MD5, AES,
DES, RC2, RC4, RC5, RSA, etc.
Integridade consiste na proteção de qualquer informação ou sistema contra
remoção ou alteração de qualquer espécie sem a permissão explícita de seu proprietário.
Dentre as informações a serem protegidas podem constar desde o nome e a
identificação de um usuário até, por exemplo, arquivos de sua propriedade.
Disponibilidade consiste na proteção de qualquer serviço ou sistema contra
degradação ou não disponibilidade sem autorização. Há casos em que a disponibilidade
de informação deve ser considerada vital, por exemplo, em sistemas de tempo real ou
de varejo online.
Não repúdio visa garantir que o autor não negue ter criado e assinado um
documento, nesse caso, uma mensagem ou um arquivo digital.
Autenticidade visa estabelecer a validade da transmissão, da mensagem e
do seu remetente. O objetivo é que o destinatário possa comprovar a origem e autoria
de um determinado documento.
Em sistemas em que o usuário é reconhecido e/ou autenticado
automaticamente (sem que ele perceba essa atividade) é extremamente importante
manter a segurança dos dados, principalmente dados do próprio usuário que porventura
estejam trafegando em sistemas ubíquos.
Para Stajano (2001), um sistema ubíquo deve estar ciente das preferências
do usuário e sensível à sua presença, devendo servir ao usuário como um mordomo,
reconhecendo informações sensíveis e mantendo-as em segredo. Diante disso, ele
apresenta algumas ameaças à privacidade de usuários de sistemas ubíquos:
- Se a computação ubíqua permite a tecnologia pervasiva e de forma
transparente, cada vez mais atividades humanas comuns devem então ser conduzidas
por meio de dispositivos eletrônicos. Dessa forma, será mais fácil coletar informações
37
de comportamento e preferências de usuários, facilitando o dia a dia, bem como
reduzindo a sua privacidade.
- Se sistemas ubíquos permitem que os ambientes sejam sensíveis e
personalizados, um dos objetivos principais desses sistemas é obter o máximo de
informações possíveis sobre seus usuários e suas preferências, o que pode ser crítico se
não for bem controlado.
- A computação ubíqua adiciona a questão da escala de uso das informações.
Se forem considerados dados pessoais parciais que podem ser coletados em sistemas
computacionais, geralmente não é possível inferir muito sobre tal pessoa, por exemplo,
em contas bancárias e operações com cartão de crédito. No entanto, se houver uma
integração entre esses sistemas, com objetivo de criação de um sistema ubíquo, grande
parte da informação que precisaria ser inferida em sistemas não monolíticos já estará
disponível.
- Não será incomum o uso de tecnologias criadas originalmente para um uso
aceitável de forma ilegal, como por exemplo, espionagem ou mensagens não solicitadas
– spam.
Dessa forma, pode-se notar que os princípios descritos visam a reduzir ao
máximo ou eliminar a coleta de informações pessoais. No entanto, os sistemas
computacionais que necessitam de tais informações devem garantir que seus usuários
ajam anonimamente (Fisher-Hübner, 2001).
2.7 Segurança na Computação Móvel e Ubíqua
Enquanto as informações eram fixas, ou seja, locais, a segurança dos dados
era mais suscetível à responsabilidade dos usuários, tendo em vista que esses dados não
eram compartilhados como são quando estão em redes, sejam elas cabeadas ou sem fio,
locais ou móveis.
Para Schneier (1996), durante alguns anos, a criptografia e a garantia da
integridade de dados foram consideradas premissas para a segurança de um sistema
computacional. Com a evolução dos sistemas computacionais interligados por redes, o
38
surgimento de novas necessidades e a consequente evolução de paradigmas em
segurança computacional, novas ameaças à informação passaram a acompanhar a
necessidade primária de garantia de integridade.
Atualmente, as pesquisas em desenvolvimento em computação ubíqua focam
nas questões de construção de infraestruturas, conexão de redes ad hoc ou criação de
aplicações para explorar as novas funcionalidades dos ambientes ubíquos. No entanto,
os aspectos de segurança não têm sido tratados a fundo e, segundo pesquisadores da
área, esses aspectos no novo paradigma computacional já são problemáticos.
Uma questão que tem sido tratada nos trabalhos sobre segurança em
ambientes ubíquos e móveis é que, ao mesmo tempo em que esses recursos podem
mediar a interação humano-computador, facilitando os métodos de autenticação,
também podem potencializar ameaças à segurança das informações que são solicitadas
e utilizadas nesses sistemas cuja autenticação tende a ser feita automaticamente, sem
que o usuário interceda no processo.
A garantia de integridade das mensagens, o controle de acesso e a
autenticação das partes que se comunicam em um sistema computacional são tarefas
difíceis. Há novas condições que devem ser consideradas na segurança de sistemas
dessa natureza, como a ausência de servidores centralizados para autenticação.
Uma restrição identificada em dispositivos móveis é que geralmente estes
têm tamanho reduzido, desencadeando menor capacidade de processamento e
armazenamento se comparados aos computadores pessoais, podendo restringir a
complexidade dos algoritmos criptográficos aplicáveis nestes sistemas. Além da
garantia de sigilo nas informações transmitidas, o tratamento específico das
informações que são armazenadas nos dispositivos portáteis deve ser considerado.
Os dispositivos móveis devem fornecer informações ao ambiente de forma
transparente, enviando tais informações principalmente via sem fio. Dessa forma, pode
ser que sistemas não autorizados possam interceptar e acessar estes dados, caso os
mesmos não estejam utilizando algum método seguro de transmissão e/ou
armazenamento.
39
2.8 Autenticação de Usuários
Segundo Araujo (2003), no processo de autenticação, um usuário prova que
é quem ele diz ser (dispositivo e servidor podem sofrer autenticação também).
Dependendo da aplicação, apenas uma senha não é suficiente ou não é viável.
Em todos os sistemas computacionais em que a identificação e autenticação
do usuário são premissas na segurança de transações e processos, é interessante manter
mecanismos que ofereçam aos usuários, meios confiáveis no estabelecimento dessas
conexões.
Frequentemente são utilizados três fatores:
(a) algo que o usuário sabe – uma senha, a resposta de uma pergunta
particular, um PIN;
(b) algo que o usuário tem – um cartão magnético ou com código de barras,
um crachá;
(c) algo que o usuário é – baseado em características biométricas.
Principalmente (a) e (b) podem ser passíveis de fraude, tendo em vista que
alguém possuindo tais informações/objetos pode facilmente se autenticar no sistema
como se fosse o verdadeiro usuário. Além disso, esses fatores necessitam da interação
direta do usuário, isto é, o usuário deve informar estes dados ante a autenticação,
geralmente via dispositivos de entrada comuns, como microfone, teclado e mouse.
Diante dessa situação, as informações de contexto podem ser amplamente
utilizadas durante a identificação-autenticação sem que os usuários interajam no
momento da mesma, tornando esse mecanismo transparente (automático),
principalmente durante handovers.
Um exemplo prático é dado quando um usuário necessita efetuar vários
handovers durante um serviço. A autenticação pode se tornar uma ação repetitiva, ao
passo que o usuário seja obrigado a informar manualmente seus dados (identificação -
ID e senha) em todos os handovers.
Analisando esse enfoque, sistemas cientes de contexto devem prover meios
de captura e análise de informações de contexto, sem que o usuário perceba, ou seja, as
40
informações devem ser capturadas e analisadas conforme o perfil de cada usuário para
assim fornecer meios suficientes para interagir essas informações automaticamente com
o sistema. Além disso, vale destacar que as informações são privadas e é importante
dispor de métodos que preservem a confidencialidade e permitam verificar a
integridade das mesmas.
41
CAPÍTULO 3
Trabalhos relacionados
O estado da arte de aplicações que utilizam informações de contexto tem
trazido diversas soluções nas áreas educacionais, comerciais, empresariais, residenciais,
dentre outras áreas, o que tem aguçado grande interesse no desenvolvimento de projetos
que usufruam dessa característica.
O que tem sido pouco abordado são questões de segurança, ao passo que,
quanto mais o sistema automatiza os mecanismos de privacidade, mais o usuário fica
dependente do sistema, sem saber de forma clara se há garantia de que seus dados
pessoais estejam realmente sendo capturados e/ou utilizados em sistemas autorizados.
Neste capítulo são apresentados alguns trabalhos que utilizam informações
de contexto em vários processos aplicados à áreas diversas.
3.1 Smart Chat Group: Ferramenta Ciente de Contexto
para Formação de Grupos
O trabalho de Felix e Tedesco (2008) propõe um ambiente de aprendizado
CSCL (Computer Supported Collaborative Learning), o Aprendizado Colaborativo
Auxiliado por Computador. O CSCL propõe uma forma de interação entre alunos
trabalhando em grupos via EaD (Educação a Distância), modalidade educacional que já
está amplamente difundida entre os diversos graus de qualificação profissional.
Na EaD tem-se uma característica de compartilhamento de conhecimento e
ajuda mútua entre alunos para a resolução de problemas e discussões comumente
encontradas no ambiente de ensino-aprendizagem.
42
É importante ressaltar que cada grupo de alunos pode apresentar diferentes
níveis de aprendizado, tornando a formação dos grupos uma tarefa difícil devido à
algumas variáveis como tamanho do grupo, nível de conhecimento de cada integrante,
interação entre os membros.
Para Moscovici (2003), além dessas variáveis constituintes dos grupos, os
próprios membros também diferem na forma de pensar, de sentir e de agir nas mais
diversas situações. Por isso, espera-se que os ambientes CSCL interpretem as
informações relevantes ao grupo e ao próprio ambiente que está sendo utilizado para a
realização de uma atividade colaborativa.
Para Whatley (2004), a diversidade de habilidades e deficiências por parte
dos aprendizes é um fator muito importante no processo de formação destes grupos,
haja vista a necessidade desses integrantes lidarem com seus problemas de maneira
equitativa. Diante desse problema, a ferramenta colaborativa e ciente de contexto Smart
Chat Group foi desenvolvida para a formação e acompanhamento destes grupos de
aprendizado.
O Smart Chat Group tem como características fornecer ao professor um
ambiente no qual ele pode testar várias composições de formação de grupos em
diferentes cenários de aprendizagem, e permitir o acompanhamento individual do aluno
durante toda a sessão colaborativa. Regras de inferência são utilizadas para calcular o
desempenho do aprendiz por meio de informações de contexto (habilidades,
deficiências, reputação do aprendiz em um determinado assunto), classificando-o em
cada sessão em que ele tenha participado.
O Smart Chat Group auxilia os aprendizes de diversas formas por meio do
agente companheiro. Uma delas é por meio de mensagens motivacionais, cujo conteúdo
das mesmas é decidido por meio do monitoramento da qualidade das interações
realizadas em cada sessão colaborativa (por exemplo, se o aprendiz partic ipou/atuou na
sessão, motivando-o a melhorar o desempenho). Essas mensagens utilizam contextos de
estereótipo, faixa etária (superior a 17 anos) e sexo.
Outra forma de auxílio é a recomendação de material didático relacionado
pelo próprio professor, tendo como informações de contexto para tal recomendação o
43
nível de conhecimento do aprendiz (que é medido por meio da sua classificação
histórica e o idioma), podendo ser disponibilizados sites, livros, artigos, revistas, etc.
Para validar a proposta e demonstrar as funcionalidades do Smart Chat
Group, foi elaborado um experimento com alunos de pós-graduação da UFPE
(Universidade Federal de Pernambuco) para avaliar o comportamento desses alunos
com e sem a presença do agente companheiro proposto pela ferramenta.
Com o experimento objetivou-se a demonstração das funcionalidades da
ferramenta avaliando o desempenho dos aprendizes mediante o acompanhamento e a
formação dos grupos, realizados pelos agentes do ambiente Smart Chat Group, sendo
que este experimento foi realizado em três etapas: (a) treinamento para uso da
ferramenta, (b) utilização da ferramenta com acompanhamento do agente companheiro
e (c) utilização da ferramenta sem acompanhamento do agente companheiro proposto
no trabalho.
A duração de cada sessão foi de 15 minutos tendo observado que, na sessão
com presença do agente companheiro e formador de grupos, as mensagens do assunto
se mantiveram dentro do assunto proposto, ao passo que na ausência do agente os
participantes começaram a divagar do assunto proposto.
Outra etapa foi a aplicação de um questionário para verificar as dificuldades
encontradas pelos participantes durante o uso da ferramenta, destacando alguns
aspectos relevantes pelos participantes como a qualidade do feedback, recomendação de
material didático, sugestão e formação de pequenos grupos e uso de mensagens
motivacionais.
3.2 Autenticação Avançada de Usuários para Dispositivos
Móveis
A ideia principal de Bardram et al. (2003) foi desenvolver uma tecnologia
para autenticar usuários (por exemplo médicos e enfermeiras) em ambientes
hospitalares, devido principalmente à grande quantidade de logins que os mesmos
44
tinham que efetuar no sistema distribuído de computadores utilizados no hospital a cada
acesso aos prontuários eletrônicos dos pacientes.
Como esses logins eram "trabalhosos", era comum o compartilhamento de
senhas entre os usuários a fim de diminuir a necessidade de efetuar logins e logoffs do
sistema. Essa característica impedia que cada usuário fosse único e que cada sessão
fosse particular devido a esse tipo de autenticação (senha) ser facilmente
compartilhada, tendo em vista a minimização do trabalho de efetuar login no sistema.
A autenticação baseada em informações de contexto permite a interação
entre os usuários e os diversos dispositivos, efetuando devidas autenticações e
disponibilizando em cada sessão cada perfil único sendo reconhecida a identidade do
usuário pelo simples uso do dispositivo.
No projeto foram utilizados cartões inteligentes como token físico de
autenticação aliados a um protocolo de autenticação entre o usuário e o computador
juntamente com uma infraestrutura sensível ao contexto para efetivar o mecanismo de
autenticação dos usuários.
O protocolo de autenticação é executado em um JavaCard contendo: a
identificação de cada usuário, a senha do usuário e os pares de chaves (secreta e
pública) para autenticação do protocolo. Além disso, cada grupo de usuário só pode ter
acesso a dados permitidos, por exemplo, médicos acessam dados clínicos de seus
pacientes e não de pacientes alheios.
A arquitetura do sistema consiste em: (a) Monitores de contexto - registram
os contextos do ambiente, tais como temperatura, atividades previstas por certos
usuários, identificação de voz, etc, utilizando dispositivos para reter tais informações, e
(b) Servidor de contexto - armazena informações de contexto das entidades (pessoas,
lugares, objetos) presentes no ambiente.
A segurança neste mecanismo de autenticação diz respeito às informações
armazenadas de cada usuário assim como nos dados de cada cartão inteligente. Além
disso, a comunicação entre os monitores e os servidores de contexto também são
levados em conta quando de ataques, que podem ser passivos ou ativos.
Nos ataques passivos o fraudador pode monitorar todas as comunicações
entre o smartcard e o terminal. Por exemplo, se um fraudador "roubar" o cartão
45
inteligente é possível que aquele falsifique a real localização do legítimo usuário do
cartão, por isso pode ser que o uso de senhas seja necessário para a autenticação. No
segundo caso – ataques ativos, o atacante intercepta mensagens entre o monitor de
contexto e os tokens de contexto, podendo assim criar seu próprio smartcard, utilizando
as informações que obtiver.
No projeto foram implementadas chaves RSA de 512 bits para proporcionar
a criptografia, fazendo uso de um hardware – uma caneta pessoal incorporada num
JavaCard – tendo uma camada sensível ao toque no display, podendo assim identificar
o usuário toda vez que este fizer uso do visor multimídia.
3.3 GaiaOS
Hess et al. (2002) desenvolveram um aplicativo para facilitar a integração de
um "Espaço Virtual de Usuário", o qual contém informações de contexto, além de
tarefas e dispositivos associados tal qual ao seu usuário.
No ambiente de desenvolvimento do GaiaOS, os usuários interagem com
vários dispositivos móveis simultaneamente, registrando seus próprios dispositivos e
recursos do ambiente, efetuando adaptações às aplicações de acordo com o ambiente,
acessando dados locais remotamente e também executando aplicações com intervalos,
podendo retornar execuções posteriormente na sequência em que a aplicação foi
suspensa neste espaço virtual.
Motivado pelos ambientes ubíquos, em que as informações de contexto estão
em evidente uso nas aplicações, o GaiaOS visa gerenciar informações de contexto,
comunicação, adaptabilidade e mobilidade dos usuários enquanto pertencentes ao
espaço virtual.
Essa gerência no armazenamento de dados ciente de contexto é feita por
servidores distribuídos de arquivos, em que cada servidor gerencia seus dados, sendo
estes divididos em cinco serviços básicos:
46
(a) Gerenciador de eventos nos espaços virtuais de usuário (alterações no
contexto).
(b) Serviço de contexto (que permite consultas às informações contextuais,
habilitando assim que aplicações sejam registradas e possam acessar tais informações).
(c) Serviço de presença (detecta e mantém informações sobre o estado das
entidades - pessoas, dispositivos, softwares).
(d) Repositório de espaços (armazena informações sobre todas as entidades
de software e hardware no espaço, permitindo assim que as aplicações recuperem
entidades com base em atributos identificáveis).
(e) Sistema de arquivos de contexto (repositório gerenciador de informações
de contexto que são disponibilizadas quando da presença de usuários, além de
disponibilizar essas informações de acordo com cada tipo de dispositivo envolvido no
espaço virtual).
Um exemplo de aplicação que utiliza o GaiaOS é a execução de arquivos de
música em que o usuário ouve músicas conforme sua preferência e sua mobilidade
dentro de espaços virtuais, sendo estas informações de preferência e localidade
gerenciadas pelo sistema de arquivos de contexto.
A contribuição do GaiaOS foi de extrema importância no estudo e aplicação
da computação ciente de contexto, tendo em vista que o mesmo estendeu o conceito dos
tradicionais sistemas operacionais devido a contextualização das informações das
entidades diante das suas aplicabilidades e usabilidades.
Outro ponto importante foi a implementação do sistema de arquivos de
contexto, organizando assim os dados de acordo com cada atividade dos usuários e
provendo às aplicações, as informações de contexto destinadas e necessárias à cada
requisição dos espaços virtuais, identificando assim, perfis e autorizando acesso aos
serviços pré-definidos à cada usuário dentro do seu contexto.
47
3.4 CXFramework
Tosin (2009) propõe uma arquitetura genérica para a integração de
informações de contexto em uma plataforma distribuída por meio de definição de um
modelo de suporte baseado em um serviço de inferência, fazendo com que as
informações sejam disponibilizadas às aplicações, transferindo assim grande parte da
complexidade de detecção de mudanças de contexto a uma infraestrutura genérica.
CxFramework foi desenvolvido na linguagem JAVA sobre a plataforma CORBA
utilizando ontologias3 de modelagem de informações de contexto, sendo baseado em
serviços que suportam aplicações dependentes de contexto. É composto pelos seguintes
elementos:
a) Sensor Management Service: faz a comunicação entre os sensores
externos (sensors) e a infraestrutura, possuindo um conjunto de Sensor Adapters. Esses
sensores podem ser dispositivos físicos (temperatura, calendários, relógios, etc.) ou
virtuais (outras aplicações), que podem fornecer informações de contexto. O Sensor
Adapter encapsula o código de comunicação com os sensores. Havendo alteração de
estado de algum contexto, o Sensor Adapter responsável por esta informação notifica o
seu ID e o seu novo estado para o Context Reasoning Service.
b) Registry Service: registra serviços da infraestrutura assim como eventos
de mudança de contexto, para que as aplicações dependentes de contexto sejam
notificadas quando houver uma alteração de contexto.
c) Context Reasoning Service: serviço que recebe e processa os eventos
vindos dos Sensor Adapters.
d) Context Notification Service: notifica aplicações quando de mudanças de
contexto.
e) Proxy: é uma API (Application Programming Interface) que esconde da
aplicação o código específico da plataforma distribuída usada na implementação do
CxFramework. Assim, toda a comunicação feita entre a aplicação dependente de
contexto e a infraestrutura passa pelo Proxy. Ele também permite que a infraestrutura
3 A Ontologia permite a abstração dos conceitos concretos e inclusão de relacionamentos entre estes conceitos (semântica), e
pode ser descrita em uma linguagem interpretada por computadores e máquinas de inferência.
48
seja multiplataforma, assim o CxFramework não precisa ser alterado toda vez que o
mesmo for implementado em plataformas diferentes.
f) Security Service: controla o acesso às informações de contexto.
g) Application Sensor Adapter: similar ao Sensor Adapter, no entanto, esses
são criados e gerenciados pelas aplicações dependentes de contexto, assim ao registrar
uma nova aplicação, esta também assume o papel de Sensor, podendo alterar o contexto
do ambiente.
h) Coletor de Lixo: é um agente que age de tempos em tempos coletando
informações defasadas, ou seja, que não são mais relevantes para uso das aplicações.
O CxFramework foi então implementado para tratar alguns acontecimentos
que ocorrem em um supermercado, tendo como cenário: (i) carrinhos de compra
equipados com display que transmite informações aos clientes (por exemplo, de
promoções próximas ao local em que o carrinho se encontra); (ii) quando o cliente se
aproxima das filas dos caixas, também é mostrado no visor qual caixa o mesmo deverá
se dirigir para um atendimento mais ágil, e (iii) quando carrinhos são abandonados
dentro do supermercado, a localização destes carrinhos é enviada para os PDAs dos
funcionários para que estes façam a busca e organização destes carrinhos na área de
armazenamento específica para isso.
Figura 4: Aplicações dependentes de contexto conectadas ao CxFramework
(Tosin, 2009).
49
As aplicações ilustradas na Figura 4 estão associadas ao contexto, estando
elas conectadas ao CxFramework a fim de garantir: comunicação entre o cliente (para
envio de promoções); direcionamento do cliente ao caixa respectivo para atendimento
(por meio de critérios como tempo médio de atendimento, número médio de pessoas
aguardando, etc.); localização de carrinhos abandonados na área de compras do
mercado para que os funcionários responsáveis façam o seu resgate.
Cada carrinho de compra é uma entidade dependente de contexto que recebe
em seu visor, notificações dos Gerenciadores de Promoções e de Fila. Para isso, cada
carrinho fornece três informações ao CxFramework: (i) sua localização dentro do
supermercado (coordenadas), (ii) tempo em que o carrinho está parado (para prever
abandono ou não do carrinho), (iii) massa total do carrinho (massa própria mais
possíveis produtos dentro do mesmo). Os carrinhos usam os seus Application Sensor
Adapters para notificar o CxFramework a respeito das mudanças de contexto.
Uma ontologia foi criada juntamente com regras de inferência para a
modelagem das informações de contexto. A ontologia é formada por sete classes inter -
relacionadas (caixa, área, coordenada, carrinho, seção, promoção, produto) tendo cada
uma seus próprios atributos que definem as informações manipuladas pelo
CxFramework.
As regras de inferência são utilizadas pelo Context Reasoning Service para
inferir informações de contexto de alto nível (vindas dos Sensor Adapters e das
Application Sensor Adapters) que são interessantes para as aplicações de contexto. Por
exemplo, uma regra que define a área de compras pode ser especificada por meio das
coordenadas (x, y) em que se encontra o carrinho, comparando esta coordenada com a
área abrangente predefinida como “Área de Compras”, verificando assim qual a
localização do carrinho e por meio do resultado disparando então o evento específico.
O CxFramework se diferencia por dar suporte à reflexividade, o que
possibilita que o CxFramework seja capaz de ser influenciado pelo contexto que ele
representa. Além disso, a reflexividade permite a utilização de federação de contextos –
contextos diferentes (representados por instâncias do CxFramework diferentes) podem
se comunicar.
50
3.5 Previsão de Músicas Preferidas baseadas em Contexto
Baltrunas et al. (2010) desenvolveram um sistema baseado em RS
(Recommender Systems) para fornecer sugestões de itens que sejam úteis a um
determinado usuário. Essas sugestões são baseadas em preferências musicais dos
usuários, que podem ser influenciadas pela atividade ou humor do próprio usuário.
A obtenção e avaliação dos contextos foram realizadas na Universidade Ben-
Gurion Banegev em Beersheba – Israel, onde 82 alunos de graduação de Engenharia de
Sistemas de Informação foram submetidos ao experimento. Cada participante avaliou
100 faixas de música, classificando-as de 1 a 5 por meio de um software específico para
esta finalidade. Nessa classificação, o usuário também define para que condições
contextuais a música seria melhor indicada nas seguintes dimensões: (i) Atividade
(trabalho, festa, relaxamento e esporte), (ii) Tempo (sol, chuva, frio), (iii) Hora do dia
(manhã, tarde, noite), (iv) Humor (feliz, triste), (v) Disposição ao despertar (calmo,
agitado). Assim, além do sistema ser capaz de prever o melhor contexto para cada item,
o mesmo também recomenda itens a um determinado usuário em particular baseado em
seu próprio contexto.
Quatro métodos de referência de predição (i- Melhor média de contextos; ii-
Baseado em notações de similaridade; iii- Melhor vetor de contexto baseado em
similaridade e iv- Melhor contexto baseado em similaridade) são usados para cada
música baseados na média das classificações dadas pelos usuários, atribuindo assim um
valor de probabilidade para cada dimensão de contexto ou pela similaridade baseada
nas avaliações dos dados obtidos no levantamento dos contextos.
Experimentos foram realizados a fim de comparar o desempenho dos
diferentes métodos de melhor previsão de contexto, fazendo com que o resultado seja o
mais verdadeiro possível e atribuído pelo grupo de usuários na classificação das
músicas. Para cada método de avaliação, foi feita uma validação cruzada comparando a
previsão de cada método com o contexto realmente atribuído pelos usuários.
51
3.6 Adaptação Dinâmica da Capacidade de Redes
Telefônicas Móveis usando Informações de Contexto
Gondor et al. (2011) desenvolveram uma arquitetura de gerenciamento
distribuída de informações de contexto em áreas de telefonia móvel a fim de otimizar
áreas de cobertura por meio de técnicas de raciocínio.
A Figura 5 ilustra os componentes da arquitetura proposta.
Figura 5: Componentes da Arquitetura de Gerenciamento de Contexto.
A arquitetura provê coleta, armazenamento, tratamento e gerenciamento de
dados de contexto de diversas entidades (por exemplo, smartphones, torres de celular
ou roteadores), determinando componentes ociosos ou excedentes, remodelando assim
o ambiente com o intuito de otimizá-lo. É composta por (i) fonte de contexto: entidades
que podem ser instrumentalizadas como fonte de informações de contexto (ex.
roteadores, switches, servidores web, smartphones); (ii) agente de coleta de contexto:
daemons especiais em execução em dispositivos nos quais o contexto pode ser
adquirido diretamente do hardware, drivers ou softwares/serviços (ex. serviços da
Web); (iii) gerenciador de contexto: agregam dados de múltiplos agentes de coleta de
contextos (posição GPS de um dispositivo móvel ou a corrente de carga de uma estação
base UMTS); (iv) entidade de aplicação de contexto: aplicação responsável pela
execução efetiva da otimização da rede.
52
São inferidos dados de contexto de mais alto nível às informações já
existentes garantindo maior disponibilidade, conectividade e largura de banda aos
provedores de acesso, procurando otimização e adaptação dos recursos disponíveis na
rede, para diminuir o consumo de energia usado na alimentação dessas torres de
comunicação e consequentemente a emissão de dióxido de carbono4.
3.7 SOHand e DOHand
A arquitetura SOHand (Service Oriented Handover) proposto por Moreira et
al (2007) apóia o gerenciamento de handovers em sistemas ubíquos, permitindo que o
usuário tenha controle de sua sessão e possa migrar, de forma transparente, de uma
tecnologia sem fio para outra. Nessa arquitetura várias redes são interconectadas por
meio da Internet, permitindo que um usuário ao utilizar um dispositivo móvel possa
usufruir das diversas tecnologias sem fio para utilizar os serviços e informações
disponíveis na rede, sendo isso feito por meio dos handovers entre as diversas redes
disponíveis ao alcance do usuário.
A arquitetura SOHand utiliza um conjunto de ontologias denominado
DOHAND (Domain Ontology for Handovers) proposto por Vanni (2009), cuja proposta
é gerenciar o armazenamento e compartilhamento das informações que são gerenciadas
pelos provedores durante os handovers, mantendo as políticas de privacidade e os
requisitos de segurança das informações e serviços utilizados pelos usuários da
arquitetura SOHand.
As informações contextuais contidas na ontologia (DOHand) serão
compartilhadas entre as diversas entidades envolvidas na prestação de serviços, em uma
maneira orientada a serviços. Os serviços (por exemplo, jogos, vídeo, troca de
mensagens) são oferecidos por provedores de conteúdo durante uma conexão do
usuários, sendo que este provedor também pode oferecer simultaneamente acesso e
conteúdo. Vanni (2009) exemplifica, por exemplo, um serviço de streamer de áudio ou
uma conexão para jogos, oferecido por um provedor de conteúdo para um usuário
4 Segundo edição de 10/05/2007 do Jornal Deutsche Welle, na Alemanha, as usinas termoelétricas estão entre as mais
poluentes da União Européia. Disponível em < http://www.dw-world.de/dw/article/0,,2509368,00.html>
53
conectado a este provedor. Durante a utilização do serviço, o usuário pode mudar de
provedor de acesso de forma transparente. A interação entre os provedores de acesso
durante os handovers deve permitir a troca de informações gerenciáveis (contexto) que
mantenha a boa percepção do usuário na utilização do sistema, ou seja, o usuário
poderá trocar de provedor de acesso sem que o mesmo necessite interagir diretamente
(fornecendo informações de autenticação, como ID e/ou senhas), preservando o
contexto das suas conexões.
Ao passo que os usuários necessitam executar handovers, as políticas de
privacidade e requisitos de segurança devem ser mantidas, de forma que permaneçam
transparentes aos usuários quando ocorrem os handovers.
A ideia central da arquitetura SOHand é disponibilizar uma plataforma 4G
para dar suporte à prestação de serviços avançados de rede. A base do sistema é uma
estrutura de informação versátil para comunicação entre provedores de serviço e
clientes. O cliente possui módulos capazes de capturar informações de várias fontes,
como do usuário, da rede, do dispositivo, do ambiente, entre outras. O provedor de
acesso pode ser classificado em categorias de serviço tradicional (por ex., rede celular
ou Wi-Fi) ou comunitário (por ex., redes Mesh). Em ambas as categorias, o usuário é
beneficiado com a associação e correlação das informações contextuais para enriquecer
a sua experiência durante o uso do ambiente da rede (Moreira et al., 2007).
A arquitetura SOHand (Figura 6) é composta por três classes: Cliente
(dispositivo), Provedor e um Broker. As Fontes de Contexto (FC) fornecem
informações passíveis de serem capturadas pelos dispositivos móveis dos usuários
(clientes). Há também o Gerenciador de Contexto (GC) que é responsável por processar
as informações de contexto, armazená-las em um Banco de Dados Local (BDL) e
monitorar as condições atuais da rede, dos dispositivos móveis e das preferências dos
usuários. As informações de contexto são analisadas pelo Gerenciador de Handover
(GH), que a partir dessa análise decide qual das redes disponíveis para conexão é a
mais apropriada para efetivar o handover – geralmente essa escolha é feita baseada na
qualidade do sinal de conexão (RSSI – Received Signal Strength Indication). Essa
decisão originada pela análise do contexto também pode ser, por exemplo, definida
pelas preferências do usuário relativas a preço, segurança ou qualidade de serviço,
dentre outros aspectos inerentes ao sistema. O Módulo de Negociação utiliza os
serviços disponibilizados pelos provedores de acesso para negociar o acesso por meio
54
das políticas já pré-definidas e informações de contexto de cada ambiente de rede em
questão.
Figura 6: Arquitetura SOHand (Vanni, 2009).
O provedor de acesso possui um Gerenciador de Negociação (GN) formado
por dois gerentes: i) Gerenciador de Políticas – que informa as políticas de acesso de
acordo com a posição geográfica do cliente e ii) AAA Local – que é responsável pela
autenticação, autorização e tarifar o cliente nas conexões/handovers.
O Broker é a classe da arquitetura que disponibiliza informações de
negociação de diferentes provedores e as centraliza em um AAA Home e, além disso,
há no Broker, uma Base de Dados Centralizada (BCD) com informações de contexto
dos diversos clientes. Quando um cliente acessa um novo provedor, esse provedor irá
buscar no AAA Home as informações da conta desse cliente fornecidas pelo provedor
de origem (home), para então autorizar a conexão.
A Tabela 3 abaixo descreve como o gerenciador de contexto obtém as
informações necessárias para efetuar os handovers.
55
Tabela 3: Fontes e Informações de Contexto (adaptado de Yokoyama, 2009)
Fontes de
Contexto
Informações de
Contexto
relacionadas
Método de Recuperação da Informação Motivação
Usuário
Localização
Hora
Data
Preferências
A localização (coordenadas
geográficas) do usuário, hora e data
são obtidas por meio do receptor GPS.
As preferências são configuradas pelo
usuário, que ordena uma lista de
provedores, e se deseja minimizar ou
maximizar segurança, preço e energia
(sim/não). Indicando quando o SOHand
deve considerar essas preferências na
seleção da rede.
Todas as preferências serão fornecidas
pelo usuário por meio de interface.
Localização é importante para o handover
pró-ativo considerando as preferências do
usuário e também para os LBS. A data e
hora, o provedor pode combinar com
outras informações para personalizar os
serviços, proporcionar QoS, etc. O usuário
pode usar as preferências para criar perfis,
por exemplo, de segurança para realizar
uma operação financeira, escolhendo os
provedores com maior nível de segurança,
ou ainda, um perfil de economia de tarifas
para selecionar o de menor custo.
Rede
IP/Prefixo
Gateway
DNS
MAC Address do
AP
Modo de Operação
Canal de operação
SSID
Segurança
Qualidade do sinal
Redes vizinhas
As informações de IP/Prefixo, Gateway
e
DNS são obtidas por meio de
chamadas a API do Sistema
Operacional (SO).
As redes vizinhas e as demais
informações são capturadas durante o
processo de scan da interface.
O IP/Prefixo, Gateway e DNS da rede atual
podem ser armazenados e utilizados em
uma conexão futura (na
mesma rede) para préconfigurar a
interface e eliminar o tempo de
mecanismos de autoconfiguração
(e.g. DHCP) na camada de rede, assim
reduzindo o tempo para o handover.
As demais informações são aplicadas ao
procedimento de seleção do próximo ponto
de acesso.
Dispositivo
Interfaces de rede
Tempo restante da
bateria
Por meio de chamadas a API do SO
são retornadas as informações do nível
da bateria em mA e os nomes das
interfaces que estão ativas.
As informações do nível da bateria e
interfaces ativas podem ser associadas a
preferência do usuário, por exemplo, um
perfil de economia de energia, que como
alternativa pode utilizar uma conexão via
Bluetooth (IEEE 802.15).
Ambiente
Praça
Universidade
Restaurante
Shopping, etc.
O ambiente pode ser recuperado por
meio de algum serviço que mapeie os
locais e relacione com a posição
geográfica obtida pelo GPS.
Relacionar o local com a disponibilidade de
redes abre novas oportunidades de
negócios. Pode-se inferir que o local não
possui cobertura de uma determinado
provedor.
Aplicação
Navegador Web
Player de vídeo
E-mail (imap, pop)
FTP, etc.
Informações da aplicação podem ser
obtidas por meio de chamadas a API
do SO.
Conhecer a aplicação que utiliza a rede é
importante para proporcionar QoS,
segurança e provisionamento de
recursos.
A conexão pode ser executada em quatro casos: (i) usuário parado
desconectado querendo conectar-se; (ii) usuário parado, mas que pode eventualmente
realizar um handover; (iii) usuário em movimento e desconectado por não haver rede
disponível e (iv) usuário em movimento conectado. Neste último caso é que o handover
torna-se complexo, pois exige processos de negociação, descoberta e associação ao
novo ponto de acesso (Vanni, 2009).
56
3.8 Considerações Finais
Muitos trabalhos em diversas áreas têm sido desenvolvidos com o propósito
de utilizar informações cientes de contexto. A segurança na centralização e
padronização dessas informações é extremamente importante para que os sistemas que
as utilizam possam usufruir destes dados com confidencialidade, integridade e
disponibilidade, características essenciais quando se trata de dados de usuários
(principalmente quando se tratam dos usuários móveis). Nos trabalhos apresentados não
são abordados ambientes abertos, mas sim ambientes fechados e específicos para a
aplicação e uso das informações de contexto na autenticação dos usuários.
O modelo HANDPROV se integra ao SOHand no auxílio das conexões e/ou
handovers em provedores de conteúdo, no qual o cliente (usuário) faz uso de serviços.
O acesso ao ambiente é controlado e posteriormente autorizado o serviço, por meio da
análise de informações de contexto ora capturadas e disponibilizadas ao sistema, com o
intuito de aprimorar a experiência do usuário no ambiente.
Essa experiência do usuário se embasa em conexões e handovers efetuados
conforme as suas preferências – que são informações de contexto primordialmente
usadas para comparação de provedores disponíveis e que atendam ao gosto do usuário.
57
CAPÍTULO 4
O Modelo HANDPROV
Em um ambiente sem fio podem estar dispostos diversos provedores de
serviços (download, streaming, e-mail, transferência de arquivos, backup) em que um
usuário móvel (provido de um dispositivo sem fio, tal como um notebook, um
smartphone, um celular, um palm, um tablet, etc), utilizando tecnologias sem fio
compatíveis à conexão, possa solicitar tais serviços, mediante autenticação ou não
nestes servidores (provedores). Para consumir tais serviços, geralmente é necessário
que o usuário – por meio do seu dispositivo móvel – efetue autenticações, pois os
provedores geralmente possuem algum mecanismo de controle de acesso.
As autenticações podem ser consideradas como métodos de controle de
acesso e podem ser feitas por meios de mecanismos padrões, como digitação de um
login e senha. No entanto, o HANDPROV propõe um modelo de autenticação
automática baseado em informações de contexto obtidas do ambiente por meio das
entidades envolvidas e dispostas na rede, tais como informações do usuário, do
dispositivo móvel, do provedor de serviço, de aplicações, etc., em que o usuário faz uso
de uma aplicação para acessar os serviços de um provedor.
Neste capítulo são apresentadas: (i) a arquitetura do Modelo HANDPROV –
Handovers em Provedores, em que um dispositivo móvel disposto em uma rede sem fio
se conecta a provedores de serviços, (ii) descrevendo as entidades envolvidas no
modelo (MD – Dispositivo Móvel, BR – Broker e SP – Provedor de Serviços) e (iii) as
relações entre essas entidades para a autenticação e disponibilização do serviço aos
usuários.
58
4.1 Arquitetura do Modelo HANDPROV
Para que um dispositivo móvel faça uso de diversos serviços disponíveis em
uma rede de comunicação, seja esta rede fornecida por quaisquer tecnologias de
conexão sem fio, é necessário que o usuário esteja autenticado em um provedor de
acesso. O provedor de acesso pode oferecer serviços gratuitos ou tarifados, podendo
este custo variar com a tecnologia utilizada, o tipo de serviço oferecido, a taxa de
velocidade de transmissão de dados, dentre outras características.
No modelo proposto neste trabalho, adota-se que o usuário já se encontra
devidamente autorizado e autenticado em seu provedor de acesso para fazer uso dos
serviços disponíveis na rede.
O HANDPROV é um modelo de controle de acesso a provedores de serviços
baseado em informações de contexto em que Dispositivos Móveis (MD – Mobile
Device) se conectam nesses provedores de serviços (SP – Service Provider) sem utilizar
meios padrão de controle de acesso (autenticação).
Com base na arquitetura SOHand descrita na Seção 3.7 em que o usuário
efetua conexões e/ou handovers em provedores de acesso baseado em suas informações
de contexto, o HANDPROV se integra nesta arquitetura aperfeiçoando o acesso de
acordo com as preferências do usuário, que são identificadas como informações de
contexto do ambiente. Estas preferências são informações de contexto coletadas e
analisadas do próprio ambiente pelo qual o modelo HANDPROV está integrado aos
SPs.
Os SPs estão dispostos em uma rede sem fio de mesma tecnologia. A
autenticação definida pelo HANDPROV não utiliza processos usuais (padrão) como
inserção do login e senha via interação direta pelo usuário (digitação no acesso ou no
momento da autenticação). No HANDPROV a autenticação é feita por meio de um
token, que é gerado a partir de informações de contexto provenientes das entidades do
modelo.
59
Além disso, autenticação é feita de modo transparente ao usuário, sem que
ele perceba que está se conectando inicialmente a um SP ou até mesmo efetuando um
handover, visto que a autenticação estará sendo supervisionada por um gerente
(Broker). As conexões entre o(s) MDs e o(s) SPs são executadas com base nas
preferências dos usuários (configuradas na aplicação/cliente que é a interface do
usuário com os SPs) e efetuadas de forma transparente, pois a decisão de qual SP o
usuário – por meio da aplicação do dispositivo móvel – solicitará e realmente executará
o serviço, fica a cargo do negociador – Broker (BR) que informará a aplicação qual é o
melhor SP para se conectar.
Na Figura 7, tem-se o modelo HANDPROV, com suas principais entidades
relacionadas entre si, em que um gerente (Broker) é responsável pela negociação e
autenticação entre o cliente (APP – aplicação hospedada em um MD) e o(s) SPs,
disponibilizando então ao cliente o serviço do qual o mesmo tem interesse em contratar.
Figura 7: Arquitetura do modelo HANDPROV.
60
O modelo é composto pelas seguintes entidades:
i) USER: Usuário do sistema – solicita serviço/conteúdo a um SP. Destaca-
se a característica de que o MD é um objeto pessoal e particular, ou seja, pertence a um
User somente. No entanto, um User poderá ter vários MDs, tais como notebooks,
celulares, palms, tablets, etc, que podem ter acesso via conexão sem fio ao ambiente
onde SPs estão disponíveis.
ii) APPLICATION (APP): Aplicação disponível no MD – interface para o
usuário solicitar um serviço junto a um SP. Ao executar a aplicação, uma interface de
identificação do usuário é disponibilizada para que o mesmo tenha acesso às
funcionalidades da APP e assim possa efetivar a contratação do serviço. Na aplicação
há métodos de identificação e autenticação do usuário ao efetivar acesso à APP e na
conexão com algum SP, por meio do token (e não por uso de senha para autenticar o
serviço) que também é gerado na APP.
iii) MOBILE DEVICE (MD): Dispositivo Móvel – celular/smartphone
com acesso à rede sem fio já autenticado em um provedor de acesso, pelo qual o
usuário obtém acesso ao ambiente do modelo HANDPROV.
iv) BROKER (BR): Gerente – negocia junto ao MD o acesso ao SP. O
Broker é independente do tipo de aplicação e do serviço, sendo ele responsável por
centralizar as informações de contexto de todas as entidades, podendo assim fornecer
informações durante as negociações. A cada ocorrência de alteração de contexto do
sistema, o Broker deverá ser informado e atualizado, para prover informações
atualizadas mediante as conexões. A cada conexão (ou handover) solicitada pela
aplicação, o Broker informa à mesma, qual é o melhor SP, baseado em preferências já
pré-configuradas pelo usuário na APP.
v) SERVICE PROVIDER (SP): Provedor (servidor) de Serviços. O usuário,
por meio da APP do MD solicita a execução do serviço. O SP autentica o User por
mecanismo de autenticação gerenciado pelo Broker a cada sessão inicializada pela APP
em busca de um serviço. O SP pode mudar seus contextos (status) a qualquer momento.
Na ocorrência dessas mudanças, o mesmo deverá enviar essas novas informações ao
Broker, para que este sempre seja mantido atualizado em tempo real das informações de
61
contexto dos SPs, informações estas que são essenciais para atender preferências do
usuário na escolha de qual SP efetivar conexão e usufruir do serviço.
vi) ACCESS POINT (AP): Ponto de Acesso sem fio – disponibiliza a
conexão sem fio para o(s) MD(s), SP(s) e Broker, que compõem o ambiente.
vii) SERVICE: serviço/conteúdo disponibilizado/armazenado nos
provedores de serviços cujo acesso é visível aos Users por meio da rede sem fio com
uso de seu MD.
4.1.1 Autenticação via token
Conforme já apresentado, tanto na conexão ou no handover, o processo de
autenticação do HANDPROV não segue o padrão interativo, em que usuário ao solicitar
um serviço, utiliza login e senha a cada efetivação do serviço. Sendo assim, a
autenticação é feita automaticamente por meio de um token, que é gerado na aplicação
do MD.
O token é gerado quando ocorre o acesso do usuário na APP do MD com o
objetivo de buscar um serviço disponível no ambiente.
Na geração do token, são necessários os seguintes passos básicos:
(i) obter as informações de contexto do usuário e do MD;
(ii) concatenar esses dados;
(iii) retornar o resultado dessa concatenação como dado de entrada para ser
utilizado no método de geração do hash (token), via algoritmo MD5 (RIVEST, 1992).
Com o token gerado, a APP o envia para o BR para que este possa
disponibilizá-lo aos SPs (quando há uma efetiva conexão para utilização do serviço).
Posteriormente, a APP dispara a busca pelo serviço (o BR gerencia os provedores
disponíveis na rede), baseando-se nas preferências configuradas pelo usuário na APP.
O BR envia informações do usuário e o hash para os SPs disponíveis, uma
vez que, na ocorrência da conexão principal ou de um handover, os SPs já terão estas
informações previamente conhecidas. Isto é feito antes da comparação dos status entre
os SP(s) para evitar a ocorrência de envios duplicados das informações de autenticação
(usuário e token), quando no surgimento de handovers em ciclo.
62
Quando o provedor de serviço preferencial é encontrado, o BR faz o envio
do token, possibilitando então a comparação entre tokens – gerado na APP e informado
pelo BR para ser utilizado no processo de autenticação do serviço junto ao SP.
4.1.2 Broker (BR), Aplicação (APP) e Provedor de Serviços (SP)
O Broker (BR) é uma entidade centralizadora do modelo HANDPROV, cuja
principal função é gerenciar as negociações entre o MD e os SPs disponíveis na rede.
Ele é o gerente de todas as informações de contexto utilizadas do início ao fim dos
serviços, tendo como principais funções:
(i) receber login, senha e preferências do usuário cadastrados na APP,
garantindo que o usuário seja direcionado a um SP cujo status esteja conforme a sua
preferência;
(ii) coletar os status dos SPs e compará-los, verificando qual é o melhor
deles;
(iii) receber o token da APP e enviá-lo para o SP preferencial para posterior
autenticação, seja no início da conexão ou na ocorrência de um handover;
(iv) possibilitar histórico das conexões efetuadas nos SPs;
(v) retornar o endereço IP (Internet Protocol) do SP preferencial à APP para
que se possa efetivar a conexão e posterior disponibilização do serviço ao usuário.
A utilização do BR no modelo HANDPROV agiliza as negociações entre o
MD e os SPs, haja visto que, a utilização das informações de contexto acarretam
análises e comparações (de preferências e de status) das entidades envolvidas no
modelo.
Centralizar essas análises no Broker minimiza que o MD fique realizando
varreduras na rede por busca de SPs que condizem com a preferência do usuário e
comparando os status dos mesmos sem necessidade, uma vez que com o BR realizando
essas tarefas, as contratações dos serviços com os SPs são aprimoradas. Também
possibilita que o token seja enviado somente ao SP atualmente preferencial, já que, se
durante a execução de um serviço ocorre de um outro SP disponível na rede atender
melhor à preferência do usuário configurada na APP, o BR analisa essa ocorrência e
63
então dispara informações no ambiente (envia o IP do novo SP à APP) para que seja
efetuada a troca (handover).
A APP é a interface direta e disponível entre o usuário e o MD. Nela são
encontrados os seguintes métodos:
(i) geração do token (para ser utilizado na autenticação);
(ii) compartilhamento do token para o ambiente HANDPROV;
(iii) configuração da preferência do usuário;
(iv) execução ou entrega do serviço ao usuário.
O SP possui algumas características de conexão que podem interferir na
escolha do usuário ou na qualidade do serviço, tais como: custo monetário da conexão,
quantidade de usuários conectados simultaneamente, tecnologia utilizada nos tráfegos
de dados, tipo do serviço, latência, etc. O SP possui basicamente os seguintes métodos:
(i) reconhecimento do seu próprio endereço IP;
(ii) configuração manual pelo administrador do custo monetário da conexão;
(iii) reconhecimento da sua própria latência;
(iv) organização do conteúdo nas pastas de armazenamento;
(v) envio do serviço para a APP, quando da solicitação do usuário;
(vi) recebimento do par “usuário – token” para ser utilizado no momento de
possíveis autenticações;
(vii) disponibilização do serviço.
Além dos métodos descritos, o SP também pode oferecer outras
funcionalidades, dependendo do tipo de serviço disponibilizado.
4.2 Considerações Finais
O Modelo HANDPROV minimiza a interação do usuário nos processos de
autenticação, já que é prevista a possibilidade de ocorrer conexões (handovers) tantas
quantas vezes aparecerem SPs com melhores condições (preferências) para a conexão e
execução do serviço.
Nos trabalhos relacionados, é possível observar a utilização das informações
de contexto em áreas e funcionalidades distintas aplicadas ao uso simultâneo (ou não)
64
de vários usuários. Também se observou que os contextos são utilizados para
tratamento, análise e adequação do ambiente para que o usuário seja atendido conforme
o objetivo de cada trabalho.
O modelo HANDPROV se assemelha aos trabalhos relacionados no aspecto
do uso das informações de contexto, em que o serviço é disponibilizado a usuários que
previamente são autorizados por um gerente (Broker), por meio da confirmação do
login e senha, a se conectarem no ambiente onde estão os SPs. Desse modo, é possível
utilizar-se ativamente dos serviços, efetuando conexões com autenticação via token –
alvo do HANDPROV – nos SPs.
65
CAPÍTULO 5
Um serviço de streaming de áudio
baseado no Modelo HANDPROV
No modelo HANDPROV, tem-se a premissa de que o MD já está
autenticado em um Provedor de Acesso à Internet. Assim, o foco deste capítulo é
descrever o processo de validação do modelo HANDPROV.
Para validar o modelo HANDPROV, foi desenvolvida uma aplicação
executável em um dispositivo móvel que utiliza informações de contexto para
direcionar conexões e/ou handovers e também a autenticação dessas conexões via
geração de um token a partir de informações de contexto.
Dentre os vários serviços disponíveis em rede, definiu-se o streaming de
áudio como aplicação exemplo, uma vez que se trata de um serviço multimídia podendo
se aproveitar das funcionalidades multimídia do smartphone em tempo real, já que o
objetivo da validação está focado na autenticação via informações de contexto e não no
serviço – streaming – em si.
Vários componentes são envolvidos para ouvir o áudio streaming (adaptado
de Luini e Whitman, 2002). Tendo um servidor de streaming de áudio hospedado em
um site, então se inicia com a conexão de Internet (via qualquer tecnologia de
transmissão de dados) e um navegador Web. Usando o navegador em um computador, o
usuário visita um Website que oferece áudio, podendo ser uma música, uma narrativa,
etc. Quando se clica num link para um conteúdo, um aplicativo começa a tocar
automaticamente.
Adaptando essa definição no HANDPROV, substitui-se o computador pelo
smartphone e o navegador pela aplicação do MD, assim como a disponibilização do
conteúdo é feita por meio de um Provedor de Conteúdo (CP – Content Provider)
66
pertencente à rede no qual o usuário já se encontra conectado (e não por um WebSite) –
uma vez que esses são entidades descritas no modelo.
O serviço de streaming é um tipo de transmissão de dados com fluxo
constante em tempo real, não categorizando um download em que o usuário transmite o
conteúdo/arquivo para seu dispositivo e, somente após a conclusão dessa transferência
é que se faz o acesso/consumo do mesmo, uma vez que no streaming, enquanto o
serviço é entregue, a aplicação já começa a executar o conteúdo.
Luini e Whitman (2002) ainda dizem que o que realmente ocorre é que o
aplicativo conecta-se com um servidor de streaming e solicita os conteúdos escolhidos
de áudio streaming. O servidor de streaming reconhece o áudio streaming – um arquivo
estático pré-processado ou uma alimentação direta contínua – e começa a enviar o áudio
pela conexão de Internet do usuário. Depois de um breve processo de “buffering”, o
áudio é tocado por meio das caixas de som do usuário como este é recebido. Sendo
assim, o streaming permite execução dos dados – neste caso a execução de músicas no
dispositivo móvel – ao mesmo tempo em que os pacotes de dados estão sendo recebidos
por ele.
Como a execução da música é perceptível ao usuário tão logo os pacotes
estão sendo recebidos no MD, é necessário haver a bufferização desses pacotes, a fim
de garantir que a execução do serviço tenha qualidade e boa percepção pelo usuário, ou
seja, não haja atraso na entrega dos pacotes subsequentes, acarretando “cortes” durante
o streaming (execução da música).
5.1 Informações de Contexto
Seguindo a classificação descrita por Henricksen et al. (2002) no Capítulo 2,
as informações de contexto utilizadas no processo de geração do token (para a
autenticação e para o controle de acesso) e no gerenciamento dos handovers foram
definidas. Sendo assim, foram identificadas as seguintes informações de contexto para a
geração do token: (a) percebidas por sensores – localização GPS do MD do usuário; (b)
definidas pelo usuário ou explícita – login e senha do usuário cadastradas na aplicação
67
do MD; (c) fornecida por algum serviço – data e hora do sistema operacional do MD,
IMEI do MD.
5.2 Descrição das Preferências Baseadas no Perfil dos
Provedores
As informações de contexto que são utilizadas como preferências são
utilizadas para a decisão de qual CP a APP irá se conectar para inicializar e executar o
serviço de streaming. O usuário seleciona uma dentre as duas preferências disponíveis
na aplicação, sendo elas: custo da conexão com o CP ou latência da conexão.
As duas preferências adotadas neste trabalho são distintas entre si,
denominando-se cada uma delas:
(a) Custo (Cost): custo em unidade monetária da conexão com o CP. O
custo levado em consideração é somente da conexão, ou seja, da APP inicializar uma
sessão com o CP indicado pelo Broker, independentemente do tempo que essa conexão
tenha até o seu término.
(b) Latência (Latency): também conhecida como atraso, trata-se de um
parâmetro de desempenho de redes de computadores. É o tempo necessário para um
pacote de dados ser transmitido de um host para outro host dentro de uma rede de
computadores. Uma forma de se medir a latência é enviando um pacote de dados de um
ponto a outro, sendo este pacote devolvido à sua origem, calculando-se então (em
milissegundos, por exemplo) o tempo completo desse percurso de ida e volta. Para
Cheshire (1996), latência é o atraso de tempo entre o momento que um evento iniciou e
o momento que os efeitos iniciam. A palavra deriva do fato que durante o período de
latência, os efeitos do evento estão latentes, ou seja, potenciais ou não ainda
observados.
As preferências e podem fazer com que handovers sejam realizados a
qualquer momento quando da execução do streaming, tendo em vista as mudanças
destes parâmetros nos CPs dispostos na rede. O custo da conexão pode variar conforme
a demanda e oferta de conteúdos (músicas) nos CPs, sendo isso gerenciado pelo
68
administrador do CP. A latência está relacionada às condições de desempenho da rede
em que as entidades envolvidas estão conectadas, podendo variar com a carga de dados
imposta à rede.
No ambiente de validação – para efeito das execuções dos streamings – os
CPs contêm conteúdos exatamente iguais, ou seja, são cópias idênticas.
5.3 Descrição da Validação do Modelo HANDPROV
Na validação do HANDPROV, foram definidos os aspectos inerentes à
arquitetura do modelo, desenvolvendo assim o ambiente necessário à validação,
conforme apresentado na Figura 8.
A autenticação do usuário é feita automaticamente por meio de um token
gerado pela aplicação. Esse token é disponibilizado ao Broker para que este o
encaminhe para o(s) CP(s) que venha(m) a efetivar a disponibilização do conteúdo ao
usuário.
Figura 8: Modelo de Validação HANDPROV executado para apoio ao Audio Streaming
Service.
69
A APP efetua uma conexão com o CP, busca e executa um serviço de
streaming de áudio.
O Broker é o gerente de informações de contexto e um mediador das
solicitações do MD, principalmente nos processos de negociação das conexões com os
CPs. Na Figura 9 pode-se observar a interface WEB do BR que sinaliza que o mesmo se
encontra corretamente em execução e aguardando solicitações da APP e dos CP(s).
Figura 9: Interface WEB do Broker, utilizado para confirmar a execução do mesmo.
O Broker deve assegurar a atualização das informações de contexto de todo
o ambiente (Provedores de Conteúdo, Dispositivos Móveis, Usuários, Conteúdos),
comparar essas informações de contexto, principalmente dos CPs – pois serão
analisadas e utilizadas para a efetivação da conexão ou handover, conforme as
preferências do usuário configuradas na APP.
O Broker mantém a APP informada de qual CP é o mais indicado em todo
momento de disponibilização dos serviços de streaming – isto é, no início e/ou durante
a execução do mesmo, podendo viabilizar handover de CP, caso haja um CP disponível
melhor que o atual. Também envia o token gerado pela APP ao CP indicado a prestar o
serviço.
Os CPS disponibilizam arquivos de áudio (músicas) sob forma de streaming.
Todos os CPs disponíveis na rede contêm os mesmos conteúdos (arquivos), podendo ou
não, estes arquivos serem diferenciados quanto ao bitrate (taxa de bits).
70
Além disso, os CPs possuem uma interface WEB, como mostrado na Figura
10, para que o administrador do serviço faça a inserção manualmente a qualquer
momento via teclado, do valor monetário (custo) tarifado para disponibilização do
serviço aos usuários do HANDPROV. Após a inserção do custo, o administrador ao
clicar no botão “salvar”, faz com que o custo do referido CP seja atualizado e enviado
ao BR para posterior análise e comparações com os custos dos demais CPs da rede.
A resposta da comparação fará com que a APP continue conectada no
mesmo CP ou efetue um handover – caso haja identificação de um outro CP de custo
menor do que o custo do CP já em uso pela APP.
A latência é medida internamente por métodos específicos do CP (já que se
trata de um parâmetro dependente das condições da rede e não do administrador do
CP), métodos estes que fazem as devidas comparações caso o usuário faça opção de
preferência de CP com menor latência.
Figura 10: Interface WEB do administrador do CP utilizado para o mesmo inserir o
custo monetário.
Seguem definições das entidades da validação do modelo:
i) MOBILE DEVICE (MD): O dispositivo móvel é um smartphone pelo
qual o usuário solicita o serviço utilizando-se de uma aplicação específica desenvolvida
para essa finalidade por meio de conexão sem fio. O smartphone utilizado na validação
é um exemplar Nokia N95 com conexão WiFi.
ii) SERVICE: O serviço escolhido para a validação do HANDPROV foi o
streaming de áudio por meio de arquivos em formato mp3. Sendo assim, o SP definido
71
foi um CP de áudio. O streaming é executado diretamente no MD, por meio de funções
de bufferização que garantem uma boa qualidade auditiva do mesmo.
iii) USER: Usuário do sistema – interage no ambiente usando a APP
instalada no MD, solicitando serviço de streaming junto ao CP, por meio da busca do
conteúdo (música) desejado pelo usuário.
iv) APPLICATION (APP): Aplicação disponível no MD – interface para o
usuário solicitar serviço junto ao CP. Ao executar a APP, a mesma irá gerar um token a
partir de informações de contexto: do User (login e senha) e do MD (IMEI –
International Mobile Equipment Identity, localização GPS – Global Positioning System,
data e hora locais da solicitação do serviço de streaming), por meio de concatenação e
hash dessas informações. Esse token é enviado ao Broker, que o compartilha com os
CPs a cada conexão ou handover requisitado pela APP.
v) CONTENT PROVIDER (CP): Provedor (servidor) de conteúdos – sua
função é armazenar o conteúdo – músicas em formato mp3 – e assim disponibilizá-las
aos usuários por meio do streaming. Características variáveis dos CPs, como latência e
custo da conexão, são utilizadas para definição de preferências do usuário quando da
sua efetiva contratação do serviço, portanto, esses dois parâmetros quando atualizados,
são retornados ao sistema para que o Broker fique atualizado dessas informações e
assim faça análise e comparação entre os CPs disponíveis para então poder atender
corretamente à solicitação do User. Os CPs preferencialmente devem ter o mesmo
conteúdo, ou seja, as mesmas músicas disponíveis aos usuários. A autenticação do User
no CP é feita por meio do token.
vi) PREFERENCES: Preferências do User – o usuário deve configurar a
sua prioridade de escolha da conexão com os CPs. Esta preferência poderá ser: menor
custo da conexão no CP em unidade monetária ou menor latência da conexão com o
CP. Outra preferência que pode também ser utilizada pelo usuário é o bitrate do
conteúdo (taxa de bits da música), no entanto, para que esta última seja usada, é
necessário fazer um checksum (comparação que garanta que os arquivos são os mesmos
em CPs distintos) a fim de que na ocorrência de um handover, o usuário continue a
receber o mesmo conteúdo (atributos de conteúdos em CPs distintos podem ser os
mesmos, como: data de criação do arquivo, duração em minutos, nome do arquivo,
título do álbum, nome do artista, tamanho do arquivo em Mbytes, etc., no entanto a
música em si pode estar disposta em versões diferentes, como acústica, remix, etc).
72
vii) BROKER (BR): Negocia junto ao MD o acesso ao CP. É ele que
centraliza todas as informações de contexto do ambiente, tanto dos CPs disponíveis
(latência e custo), dos conteúdos (bitrate da música), do usuário (login e senha), do MD
(GPS, IMEI, data, hora) e da APP (preferência que o User configurou para efetivar suas
conexões e handovers), podendo assim gerenciar corretamente o streaming conforme as
preferências do usuário. O BR também é responsável por receber o objeto de
autenticação do serviço – token – e fornecê-lo ao(s) CP(s) cuja APP efetuará sua
conexão ou eventual handover.
viii) ACCESS POINT (AP): Roteador de acesso sem fio, cujo exemplar
utilizado na validação foi o TP-LINK WIRELES 300 MBps Advanced Wireless N-
Router TL-WR941DND.
ix) CONTENT: Conteúdo (músicas em formato mp3) armazenado nos CPs
disponíveis para os Users solicitarem o streaming via APP instalada no MD.
Dessa forma, percebe-se que a conexão é orientada às preferências do
User, ou seja, ele é quem define qual característica fará com que a APP efetue a
detecção, a atribuição, a transferência e a atualização do handover, caso este seja
necessário.
Estão sendo utilizadas bibliotecas e APIs JAVA na APP para obter as
informações de contexto (IMEI, localização GPS via latitude/longitude/altitude, data e
hora do dispositivo móvel, login e senha do usuário) necessárias para a geração do
token, assim como uma implementação do código de geração de hash MD5 customizada
por Macinta (2011).
A APP disponibiliza uma tela inicial (Figura 11) em que o usuário insere
seu login e senha para fazer uso do mesmo. Estes dados iniciais não têm como função
principal autenticar o usuário na aplicação/ambiente, mas sim são fontes de dados de
contexto para a geração do token. Após inserção dos dados iniciais, o usuário configura
sua preferência de conexão com os CPs e informa o nome da música (completo ou parte
dele). Na terceira tela é enviada uma mensagem confirmando a execução do streaming
enquanto o usuário ouve a música solicitada na tela anterior.
As informações de contexto utilizadas na validação do modelo e coletadas
do MD, da APP e do CP, são elementos que inferem ao sistema as decisões da conexão
73
do MD com o CP. Para isso, o BR sempre é informado quando ocorrem atualizações
desses parâmetros nas entidades envolvidas no ambiente.
Figura 11: Interfaces da aplicação de validação.
a: Tela de login do
usuário.
b: Tela de preferências e
busca do arquivo para
streaming.
c: Tela de execução do
streaming de música.
74
5.4 Diagramas de Casos de Uso
O diagrama de caso de uso ilustrado no Anexo I é utilizado para mostrar as
funcionalidades da APP, oferecendo uma visão geral de como as entidades definem
suas ações e interações dentro do sistema.
Para um melhor entendimento, segue a descrição do fluxo normal do caso de
uso envolvido no controle de acesso, denotando assim os eventos ocorridos entre as
entidades principais do sistema e descrevendo as funcionalidades desempenhadas por
elas na interação com o sistema.
Tabela 4: Descrição do caso de uso Controle de Acesso.
FLUXO NORMAL
ENTIDADE AÇÃO
APLICAÇÃO Envia a preferência e o token do usuário para o Broker
BROKER Envia “usuário e token” para os CP disponíveis
BROKER Busca qual é o melhor CP, efetuando comparações entre as informações
de contexto (custo e latência) dos CPs disponíveis
BROKER Envia endereço IP do melhor CP para a Aplicação
APLICAÇÃO Recebe informações de identificação do CP (IP) e envia “usuário –
token” para o referido CP, solicitando conexão
PROVEDOR Compara se os dados (usuário – token) recebidos pelo Broker e pela
Aplicação são os mesmos
PROVEDOR Autentica o usuário por meio do token
PROVEDOR Entrega o serviço à Aplicação
5.5 Diagrama de Classes
O diagrama de classes permite uma visualização das classes envolvidas na
composição do modelo juntamente com seus atributos (campos) e métodos (funções),
demonstrando o inter-relacionamento das classes por meio das associações existentes
entre as mesmas. O diagrama de classes, ilustrado no Anexo II, contém os
relacionamentos entre as entidades do sistema, em que:
Um User (usuário) pode ter nenhum ou muitos MDs, e um MD é somente
de um User;
75
Um User pode ter uma ou muitas Preferences (preferências), e uma
Preference pode estar configurada para nenhum ou muitos Users;
Um MD pode ter uma ou muitas Applications (aplicações), e uma
Application pode estar instalada em nenhum ou muitos Mobiles Devices;
Um Content (conteúdo – áudio, vídeo, imagem, texto, etc) pode estar em
um ou muitos CPs, e um CP pode ter nenhum ou muitos Contents;
Um Broker (negociador) pode ter nenhum ou muitos Logs (registros de
acesso), e um Log deve estar somente em um Broker;
Um MD, ao solicitar serviço um CP, necessariamente mantém uma
conexão com o Broker, para que este informe o melhor CP ao MD, o que poderá gerar
um Log para registrar os acessos MD – CP juntamente com os handovers (troca de CPs
durante o serviço).
5.6 Descrição do Ambiente de Desenvolvimento
No desenvolvimento da aplicação de validação do modelo HANDPROV
foram utilizadas várias ferramentas de apoio a ambientes de serviços WEB, já que o
modelo visa a disponibilizar serviços via rede.
A princípio estudou-se a possibilidade de trabalhar com datagramas via
sockets para dar suporte ao envio dos pacotes do streaming. No entanto, optou-se por
utilizar WebServices já que estes provêm melhor desempenho, maior facilidade de
implementação e integração com outras aplicações, maior mobilidade e suporte ao
desenvolvimento para aplicações Web.
Contudo, o uso de sockets não foi totalmente descartado, tendo em vista a
necessidade de se manter comunicações (cliente/servidor) constantes entre as entidades
(APP-BR-CP) garantindo o compartilhamento de novas informações de contexto. Isto
se deve ao fato do BR e CPs necessitarem de um canal aberto de comunicação, ficando
disponíveis a receberem “mensagens” via socket a qualquer momento, informando essas
atualizações.
76
Uma vez que há alteração de alguma informação de contexto (por exemplo,
preferência do usuário ou status do CP), o BR é prontamente informado, possibilitando
então a análise e comparação entre os CPs disponíveis, providenciando a correta
conexão (ou handover) da APP no CP, conforme preferência configurada.
Dentre as ferramentas, vale relatar a escolha Servidor WEB, já que as outras
ferramentas (IDE - Integrated Development Environment ou Ambiente Integrado de
Desenvolvimento, Linguagem de Programação e Simulador) são comuns à maioria dos
trabalhos desenvolvidos.
Foram feitos testes das funcionalidades suportadas em outro servidor de
aplicação (TomCat7), no entanto, com resultados pouco satisfatórios devido à forma de
suporte oferecido para se trabalhar com o JEE6, oferecendo um ambiente de trabalho
mais complexo e necessitando inserir algumas bibliotecas.
O GlassFish foi testado e então escolhido para esta finalidade
(servidor/gerenciador de aplicação WEB) por já vir integrado à IDE NetBeans, oferecer
suporte integral ao JEE6 e por realizar um deploy da aplicação de forma mais fácil.
A Tabela 5 mostra um resumo das ferramentas utilizadas.
Tabela 5: Plataforma de desenvolvimento do HANDPROV.
Ferramenta Plataforma
IDE NetBeans 7.0.1
Servidor Web GlassFish OpenSource 3.1.1
Linguagem de Programação Java JDK 1.6.update 27
Simulador Java(TM) Platform Micro Edition SDK 3.0
Sistema Operacional Symbian OS 9.2 S60
5.6.1 Implementação do token
O token é gerado a partir da concatenação dos dados do MD (IMEI,
localização GPS – altitude/longitude/latitude, data e hora) e do usuário (login e senha).
77
No momento em que o usuário digita seu login e senha pela primeira vez na
interface da APP e finaliza esse cadastro, essas duas informações são enviadas e salvas
no BR para que o respectivo usuário possa vir a fazer uso do serviço. Havendo um
segundo acesso à APP, quando o usuário informa seu login e senha novamente, o BR
analisa se este usuário já está cadastrado para utilizar o sistema.
Caso login e senha sejam inválidos, ou seja, login e senha não conferem, o
BR impede a execução da APP e envia mensagem de erro ao usuário na interface da
APP. Não são permitidos cadastros duplicados de usuários (com logins idênticos), pois
o HANDPROV prevê nomes de usuários únicos para a utilização dos serviços
disponíveis nos CPs, independentemente se estão fazendo acesso ao serviço por MDs
diferentes.
Caso login e senha sejam válidos, ou seja, já exista cadastro desse usuário
no BR e a sua senha confere, o BR permite a continuação da execução da APP,
passando para a interface das preferências.
Antes de o usuário configurar a sua preferência (bitrate, custo ou latência), o
token é gerado por uma classe pertencente à APP (já que login e senha já foram
reconhecidos) e, tendo o usuário o seu token, o mesmo é utilizado até a próxima vez
que seja efetuado novo acesso na APP. O token é composto por dados variáveis, ou
seja, mudam com tempo e deslocamento geográfico do MD (data, hora, GPS) e também
por dados constantes (IMEI do MD, login e senha do usuário).
No desenvolvimento da APP, foi percebida a importância de não
sobrecarregar a classe Aplicação com as funções custosas de obtenção e concatenação
direta dos dados utilizados para gerar o hash, uma vez que o objetivo da APP é realizar
o streaming. Além disso, pela existência de dados de composição do token (IMEI, GPS,
data e hora) serem independentes do usuário, julgou-se interessante manter uma
proteção de acesso direto da Aplicação, já que são dados obtidos por funções internas
diretamente ligadas ao MD.
Diante disso, foram criadas duas classes distintas (i) Usuário e (ii) Token
para receber as funcionalidades de gerência do token (obtenção e concatenação dos
dados e geração do token). Essas duas classes também têm o objetivo de não
sobrecarregar a classe Aplicação, protegendo os dados (IMEI, GPS, data e hora) da
78
própria APP (que pode sofrer comportamentos inesperados – travar – ou até mesmo
interferir nos valores desses dados, causando inconsistência no valor do hash criado no
instante da autenticação do MD pelo CP).
Na classe (i) são retornados os dados do usuário digitados na interface da
APP (login e senha) e posteriormente concatenados. Na classe (ii) são obtidos os dados
do MD (IMEI, data, hora, GPS).
Após a concatenação dos dados do usuário (na classe Usuário), este
resultado é enviado à classe Token para ser anexado e posteriormente concatenado com
os dados obtidos na mesma classe, finalizando assim a geração do hash. Esse hash é
retornado para a classe Aplicação, ficando disponível para envio ao BR e ao(s) CP(s) na
ocorrência de conexões/handovers. O token somente é alterado quando o usuário efetua
um novo acesso à APP, devido às atualizações da combinação dos dados variáveis
(GPS, data e hora), a princípio nunca serem iguais.
Os dados GPS (latitude, altitude e longitude) estão sendo somente utilizados
como elementos para implementação do hash. Ou seja, mesmo que o usuário com seu
MD se desloque várias vezes (alterando o GPS) durante os intervalos de tempo que
compreendem a obtenção dos dados GPS, a geração do token, o compartilhamento do
token entre APP, BR e CP e por fim a autenticação do usuário no CP, as informações
contidas serão aquelas obtidas no início do processo de geração do token, uma vez que
o modelo HANDPROV prevê um token estático a cada acesso à APP, independente de
haver handover ou não durante a execução do serviço.
5.6.2 Implementação do handover
O handover entre CPs ocorre quando é observada a existência de um CP
disponível para conexão na rede que atenda melhor às preferências do usuário do que o
CP já conectado à APP. Isto é possível porque o BR tem conhecimento prévio da
preferência configurada na APP, ficando ele constantemente “atento” e pronto para
receber informação de qualquer alteração dos status dos CPs (custo ou latência).
79
As atualizações dos CPs em si não são categorizadas como um serviço, mas
sim como uma atualização de dados. Por isso, foi necessário separar os métodos que
correspondem aos serviços web, dos métodos que correspondem às comunicações de
repasse de informações de contexto (dados) entre as entidades, uma vez que a
atualização do CP é o que inicializa a ocorrência do handover.
Após as atualizações, a APP se comunica com o BR por meio de requisições
de serviço web (solicitando o streaming) e o CP se comunica com o BR por meio de
socket (enviando atualizações de seus status para o BR fazer as comparações).
No BR foram desenvolvidos os métodos de gerência dos serviços web.
Métodos estes que dão apoio à comparação das informações de contexto dispostas no
ambiente, já que é o BR quem recebe a solicitação da APP em busca de um serviço de
streaming (e não de um dado).
Uma classe foi criada para implementar e gerenciar as comunicações entre as
entidades via socket, possibilitando então que BR e CPs mantenham um canal de
comunicação sempre com status de “pronto para receber nova mensagem”. Essa
mensagem se refere a uma possível atualização de informação de contexto, ou seja,
passando parâmetros (novos status dos CPs – custo ou latência) quando ocorrem essas
atualizações.
A Figura 12 apresenta um esquema ilustrando as interações entre as
entidades do HANDPROV, inclusive como são estabelecidas as comunicações entre
elas, que podem ser via socket, ws (webservice) ou http (protocolo).
80
Figura 12: Esquema da ocorrência de dois handovers em uma mesma solicitação de
streaming.
Na figura é exemplificada a ocorrência de dois handovers. Vale ressaltar que
inicialmente, o CP “A” é o mais barato e o BR já sabe dessa informação, pois já houve
uma prévia comparação entre os custos dos dois CPs disponíveis.
Para melhor entendimento, segue explicação dos passos:
1: O usuário requisita o serviço de streaming ao BR, enviando seu token e
sua preferência para análise do BR – via serviço web;
2: BR envia token recebido pela APP para os CPs – via serviço web;
3: BR compara os status dos CPs disponíveis para analisar qual deles atende
à preferência recebida pela APP no passo 1;
81
4: Após identificação do melhor CP, o BR envia o IP deste CP para a APP
inicializar a conexão com o CP “A” preferencial – via serviço web;
5: APP efetua conexão com o CP “A” e envia o token para ser utilizado na
autenticação neste CP – via http;
6: CP “A”compara se o token enviado pelo BR é o mesmo enviado pela
APP, autenticando então a APP e autorizando a execução do serviço;
7: CP “A” envia o serviço de streaming para a APP – via http;
8: O administrador do CP “B” atualiza seu custo, fazendo com que seja mais
barato que o CP “A” e envia esse dado ao BR – via socket;
9: BR compara os valores dos custos dos CPs “A” e “B” e verifica que o CP
“B” é o mais barato atualmente;
10: BR envia o IP do CP “B” para a APP – via socket;
11: APP efetua conexão com o CP “B” preferencial e envia o token para ser
utilizado na autenticação neste CP – via http;
12: CP “B”compara se o token enviado pelo BR é o mesmo enviado pela
APP, autenticando então a APP e autorizando o serviço;
13: CP “B” envia o serviço de streaming para a APP – via http.
Vale ressaltar que o BR envia o token para os CPs disponíveis antes da
comparação, visto que o token é estático, ou seja, é gerado no momento da solicitação
do serviço pela APP e mesmo na ocorrência de vários handovers, o token continuará
sendo o mesmo neste caso. Dessa forma, os CPs já ficam informados e preparados caso
haja uma solicitação de conexão (via handover), evitando que o mesmo token seja
enviado várias vezes desnecessariamente para o mesmo CP.
82
5.6.3 Implementação da autenticação do usuário
Na Figura 13 é apresentado um diagrama de sequência da autenticação do
usuário.
Figura 13: Diagrama de sequência da autenticação.
O BR recebe o token do usuário juntamente com a preferência,
imediatamente após o usuário configurar a preferência na APP. Após o recebimento
dessa preferência, o BR busca qual é o melhor CP, comparando os status
(latência/custo) dos CPs dispostos na rede. Após o reconhecimento do melhor CP, o BR
envia o par “usuário – token” para o CP preferencial e também retorna à APP, o
endereço IP deste CP para que a APP efetue a conexão.
Tendo a APP o conhecimento do IP do CP preferencial, a APP solicita a
conexão com este CP. Nessa solicitação a APP envia “usuário – token” para o CP para
83
que este faça a comparação (validação) se estes dados enviados pela APP conferem com
os dados recebidos pelo BR na etapa anterior. Se os dados são autênticos, o CP autoriza
a conexão da APP, disponibilizando o serviço. Se os dados não conferem, ou seja, não
são autênticos, o CP nega a entrega do serviço à APP, enviando uma mensagem de
rejeição.
5.7 Resultados
Para a validação do modelo HANDPROV, foram simulados/executados na
prática os processos entre as entidades descritas.
Foi configurado um ambiente de rede composto por: um dispositivo móvel
com a aplicação devidamente instalada, três desktops, sendo desktops A e B com
funções de hospedagem dos Provedores de Conteúdo 1 e 2, desktop C com função de
hospedagem do Broker e um access point disponibilizando sinal de rede sem fio (wifi)
interconectando todas as entidades já autenticadas em provedores de acesso .
Tendo em vista que o escopo do trabalho está relacionado à autenticação e
não ao serviço em si, durante as simulações foram percebidos os seguintes resultados:
(i) a autenticação ocorreu satisfatoriamente, tanto no início da conexão com
o primeiro CP quanto na necessidade da ocorrência de um handover, tendo em vista que
o BR garantiu o compartilhamento e o uso correto do token gerado pela APP nos
instantes das autenticações com os CPs;
(ii) o handover ocorreu de maneira transparente, ao passo que o BR era
informado e executava as comparações entre informações de contexto dos CPs,
possibilitando repassar à APP, o IP correspondente ao CP que satisfazia o contexto – a
preferência – configurada pelo usuário, sem que este tivesse conhecimento de que local
a música estava sendo executada;
(iii) a bufferização foi satisfatória, ao passo que na ocorrência de handover
ficou pouco perceptível à mudança na conexão da APP entre os CPs, garantindo uma
qualidade desejável do streaming de áudio;
84
(iv) o BR conseguiu atender às solicitações (comunicações) com as demais
entidades (APP e CPs), sem comportamentos inesperados e não ficou sobrecarregado,
visto que o mesmo atendia a apenas um usuário. Isto também pode ser acurado fazendo
uma melhor avaliação quando do surgimento de novos MDs na rede, solicitando serviço
simultaneamente.
85
CAPÍTULO 6
Conclusões
Sistemas Cientes de Contexto têm trazido agilidade em algumas
funcionalidades contidas em ambientes computacionais. Notam-se que várias pesquisas
têm sido desenvolvidas nesta área, abrangendo melhores meios de obtenção, análise ,
compartilhamento e otimização do uso dessas informações contextuais.
Dispositivos sensoriais também têm sido estudados e desenvolvidos para
obter melhor percepção de características locais e pessoais dos usuários, a fim de
agilizar processos de identificação, principalmente em ambientes ubíquos.
O que não se tem discutido a contento é sobre as características intrusivas
destes sistemas, que se interconectam e “descobrem” informações pessoais dos
usuários. Quão positivo ou negativo essa interação traz à privacidade dos usuários, pois
ao passo que é facilitada a interação nos sistemas, pode-se fazer descobertas ou
proposições sobre a vida pessoal dos mesmos, o que pode acarretar muita exposição da
privacidade do ser humano (usuário).
O HANDPROV contribui com as TICs no assessoramento de conexões e
handovers decorrentes da experiência de usuários que utilizam dispositivos móveis para
acessar provedores de conteúdo e utilizar serviços disponíveis nos mesmos.
Estas conexões automatizadas facilitam o uso da aplicação e tornam a
experiência do usuário uma atividade menos cansativa, devido a minimização das
interações durante estas conexões – o que diferencia pelo controle de acesso baseado
em informações de contexto coletadas e analisadas das próprias entidades do ambiente
(usuário, dispositivo móvel, provedor de conteúdo).
Uma tendência é tornar as aplicações cada vez menos dependentes dos
usuários, isto é, a própria aplicação se encarrega de configurar o ambiente, a conexão, o
86
serviço, disponibilizando aos usuários transparência e facilidade no manuseio das
informações utilizadas no controle de acesso dos CPs.
Assim como na SOHand em que as informações de contexto do ambiente
apoiam a experiência do usuário ao se conectar em provedores de acesso, o
HANDPROV apoia a conexão a provedores de conteúdo, que disponibilizam serviços
baseados no contexto que o usuário tenha decidido ao solicitar o serviço. Deste modo, a
SOHand e o HANDPROV utilizam informações de contexto para direcionar conexões
e/ou handovers entre dispositivos móveis e provedores (de acesso e serviço) sem que o
usuário perceba a ocorrência dos handovers.
Na validação do modelo proposto foi desenvolvida uma aplicação que
permite aos usuários de um ambiente sem fio executar streaming de áudio de diferentes
provedores de acordo com contexto (custo ou latência do provedor) configurado como a
sua preferência na aplicação desenvolvida para implantação no dispositivo móvel .
Com a evolução dos sistemas operacionais e das funcionalidades
encontradas nos dispositivos móveis associados ao perfil do usuário, também já é
possível perceber a usabilidade das informações de contexto (por exemplo, localização
GPS e ID do usuário, preferências, etc) aplicada ao uso em redes sociais, o que tem
desencadeado o desenvolvimento de aplicações móveis e um crescente banco de dados
das mesmas no compartilhamento de informações de contexto de usuários móveis.
6.1 Trabalhos Futuros
Durante o desenvolvimento da validação do modelo HANDPROV, foi
possível identificar alguns aspectos que podem ser aprimorados e/ou desenvolvidos
para melhorar o uso de informações de contexto, podendo aumentar as possibilidades
de uso de outros tipos de aplicações que venham a ser implantadas no dispositivo
móvel.
O HANDPROV apresenta algumas limitações que devem ser otimizadas em
trabalhos futuros, como por exemplo: aprimorar as funcionalidades do Broker, usar uma
gama maior de informações de contexto inseridas no ambiente sem fio e aplicá-las em
87
diversas atividades das entidades no efetivo uso em conjunto para tomada de decisões e
aperfeiçoar o ambiente.
No modelo HANDPROV, a aplicação pode ficar efetuando handover em
ciclos, isto é, diante de vários usuários utilizando o sistema simultaneamente e com o
mesmo contexto configurado como preferência, pode gerar trocas contínuas de contexto
no provedor de conteúdo. Por exemplo, quando vários usuários estão conectados em um
Provedor X, este Provedor ficará sobrecarregado, então o Broker avisará a todos os
usuários que o Provedor Y tem melhor qualidade. Diante disso, todos os usuários irão
efetuar handover para o Provedor Y, tornando-o sobrecarregado e voltando assim, para
uma situação idêntica ao do Provedor X. No entanto, a evolução do Broker pode sanar
esta limitação.
A validação atual apresenta algumas limitações dependentes do MD e não do
modelo HANDPROV. Alguns MDs não possuem interfaces de áudio e vídeo com boas
qualidades e resoluções, o que deixaria o usuário descontente com o serviço, mesmo
que o problema seja nativo de seu próprio MD.
O custo de uso de bateria ao se efetuar muitos handovers (no caso de,
durante o serviço, haver várias mudanças de contexto que interfiram nas preferências
do usuário configuradas na APP), pode levar o usuário a não querer utilizar o melhor
CP, e sim, escolher àquele que estiver ao alcance do MD – o que leva a não utilização
do contexto para a escolha de qual CP acessar e efetuar a autenticação do mesmo no
ambiente.
A princípio, no HANDPROV, os CPs devem ter conteúdos (arquivos)
idênticos, ou seja, os mesmos arquivos. Um contexto relacionado à qualidade do
conteúdo (música mp3) que pode ser utilizado para a definição de qual CP a APP deve
se conectar, é o contexto baseado na taxa de bits (bitrate) que cada música apresenta.
Assim o usuário pode escolher em se conectar em CPs que disponibilizam conteúdo
(música mp3) com melhor qualidade. No entanto, no uso dessa informação de contexto,
é importante realizar checksum do conteúdo, para garantir que, no surgimento de um CP
com melhores bitrates, seja realizado handover garantindo a execução da mesma
música na APP.
88
Trabalhos futuros podem ser propostos ampliando a gama de serviços
disponibilizados por meio de informações de contexto e visando também a solucionar
as limitações encontradas. Uma funcionalidade que pode ser desenvolvida é relacionada
à localização do usuário (via GPS), podendo autorizar o uso dos serviços somente a
usuários que estejam dispostos em um limite espacial.
É interessante também controlar o débito (custo) da conexão, seja por bytes
transmitidos, por tempo da conexão, por tipo ou quantidade de serviço disponibilizado,
etc., para uma posterior análise se é realmente compensatório efetuar handovers durante
o serviço ou inicializar e finalizar o serviço a partir do mesmo CP, já que para a
preferência “custo” adotada no HANDPROV, a execução do serviço passando por
vários CPs (por meio dos handovers) pode acarretar tarifação maior do que se a APP
inicializasse e finalizasse o serviço utilizando um único CP numa única conexão.
Além disso, pode-se fazer uma análise de quão seguro é disponibilizar
informações pessoais na rede e como garantir que estas informações não sejam
acessadas, furtadas ou adulteradas por sistemas externos.
89
REFERÊNCIAS
ABOWD, G. D.; MYNATT, E. D.; RODDEN, T.; The Human Experience. IEEE Pervasive
Computing, v. 1, n. 1, p. 48-57, 2002.
ABOWD, G. D.; MYNATT, E. D. Charting Past, Present, And Future Research In
Ubiquitous Computing. ACM Trans. Comput.-Hum. Interact, USA, V.7, N.1, p. 29 – 58,
2000.
ARAUJO, R. B. Computação Ubíqua: Princípios, Tecnologias e Desafios. XXI Simpósio
Brasileiro de Redes de Computadores, p. 45 – 115. Natal: 2003.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 17799: Código de
Prática para a Gestão da Segurança da Informação, 2005.
BALTRUNAS, L.; KAMINSKAS, M.; RICCI, F.; ROKACH, L.; SHAPIRA, B.; LUKE, K.
Best Usage Context Prediction for Music Tracks, 2nd Workshop on Context-Aware
Recommender Systems (CARS-2010), Barcelona, Spain - September 26, 2010.
BARDRAM, J. E. Applications of Context-Aware Computing in Hospital Work – Examples
and Design Principles. In Proceedings of the 2004 ACM Symposium on Applied Computing,
Cyprus. p. 1574-1579, 2004.
BARDRAM J. E.; KJAER, R. E.; PEDERSEN , M. O. Context-Aware User Authentication -
Supporting Proximity - Based Login in Pervasive Computing, p. 107-123, UbiComp 2003:
ubiquitous computing: 5th International Conference, 2003.
BERNDT, H. Towards 4G Technologies: service with iniciative. Jonny Wiley, 2008.
BROSSO, M. I. L. Autenticação Contínua de Usuários em Redes de Computadores, Tese de
Doutorado – Universidade de São Paulo. USP: São Paulo, 2006.
CERT.BR, Cartilha de Segurança para Internet, Versão 3.1, 2006.
CHESHIRE, S. Latency and the Quest for Interactivity. Disponível em:
<http://www.stuartcheshire.org/papers/LatencyQuest.html>. Acesso em: 11 ago. 2010.
DEY, A. K. Understanding and Using Context. Personal Ubiquitous Computing, London,
UK, V.5, n.1, p. 4–7, 2001.
DEY, A. K.; ABOWD, G. D. Towards a Better Understanding of Context and Context-
Awareness. In: Workshop On The What, Who, Where, When, And How Of Context-
Awareness, As Part Of The 2000 Conference On Human Factors In Computing Systems (CHI
2000), 2000, Netherlands. Anais [S.l.: s.n.], 2000.
90
FELIX, Z. C; TEDESCO, P. A. Smart Chat Group: Ferramenta Ciente de Contexto para
Formação de Grupos, XIX Simpósio Brasileiro de Informática na Educação:
Fortaleza – CE, 2008.
FISCHER-HÜBNER, S., IT-Security and Privacy - Design and Use of Privacy-Enhancing
Security Mechanisms, Springer Scientific Publishers, Lecture Notes of Computer Science,
LNCS 1958, May 2001.
GONDOR, S., UZUN, A., KUPPER, A. Towards a dynamic adaption of capacity in mobile
telephony networks using context information - ITS Telecommunications (ITST), 2011 11th
International Conference on , vol., no., pp.606-612, 23-25 Aug. 2011
doi: 10.1109/ITST.2011.6060128. Disponível em:
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6060128&isnumber=6060032>.
Acesso em: 13 out. 2011.
HENRICKSEN, K.; INDULSKA, J.; RAKOTONIRAINY, A. Modeling Context Information
in Pervasive Computing Systems, Proc. of the First International Conference on Pervasive
Computing, Pervasive'2002, Zurich, August 2002, F. Mattern, M. Naghsineh (eds). Lecture
Notes in Computer Science, Springer Verlag, LNCS 2414, p. 167-180.
HESS, C. K.; ROMÁN, M.; CAMPBELL, R. H.; CERQUEIRA, R.; RANGANATHAN, R.
H.; NARHRSTEDT, K. Gaia: A Middleware Infrastructure to Enable Active Spaces., IEEE
Pervasive Computing, p. 74-83, Oct-Dec 2002.
LOUREIRO, A. A. F.; MATEUS, G. R.; Introdução à Computação Móvel, 11ª Escola de
Computação, COPPE/Sistemas, NCE/UFRJ, 1998, versão preliminar da 2ª edição, 2004.
LUINI, J. R.; WHITMAN, A. E.; Streaming Audio: The FezGuy’s Guide. EUA: New
Riders Publishing, 2002.
LYYTINEN, K.; YOO, Y.; Issues and Challenges in Ubiquitous Computing,
Communications of the ACM, vol.45, no. 12, Dez.: 2002.
MACINTA´S WebSite. Timothy W. Macinta. Disponível em:
<http://www.twmacinta.com/myjava/fast_md5.php>. Acesso em: 12 dez. 2011.
MANNER, J.; KOJO, M. Mobility Related Terminology. IETF RFC 3753, Jun., 2004.
MOREIRA, E. D. S.; COTTINGHAM, D. N.; CROWCROFT, J.; PAN HUI, M. R. M. P.
Exploting contextual handover information for versatile services in NGN environments,
Digital Information Management, 2007. ICDIM 2007. 2nd
International Conference on, vol. 1,
no., pp. 506-512, 28-31, Oct. 2007.
MOSCOVICI, F. Desenvolvimento Interpessoal: Treinamento em grupo. 13.ed. Rio de
Janeiro: José Olympio, 2003.
PETERSON, L. L., DAVIE, B. S. Computer Networks: A Systems Approach, 4. ed.,
Morgan Kaufmann, 2007.
91
RIVEST, R. The Message-Digest Algorithm, RFC 1321 MIT MIT Laboratory for Computer
Science and RSA Data Security, Inc, 1992, Disponível em: <http://people.csail.mit.edu/rivest/Rivest-
MD5.txt>, Acesso em: 13 nov. 2010.
SATYANARAYANAN, M. Pervasive Computing: Vision and Challenges. [S.l.]: IEEE
Personal Communications, v.8, n.4, p 10-17, 2001.
SCHILIT, B.; THEIMER, M. Disseminating Active Map Information to Mobile Hosts. IEEE
Network, v.8, n.5, p 22-32, 1994.
SCHNEIER, B. Applied Cryptography. Second Edition: Protocols, Algorithms, And Source
Code In C., John Wiley & Sons Inc. 1996.
STAJANO, F. The Resurrecting Duckling – What Next?; Proceedings of the 8th
Security
Protocols Workshop, Springer-Verlag, Notes in Computer Science, 2001.
TANENBAUM, A. S. Computer Networks. 4. ed. Indiana: Prentice Hall PTR, 2003.
TOSIN, C. E. G. Uma Infraestrutura Reflexiva Para Aplicações Dependentes De Contexto.
Dissertação de Mestrado – Pontifícia Universidade Católica. Curitiba: PUC-PR, 2009.
VANNI, R. M. P. Integração De Serviços Em Ambientes Heterogêneos: Uso De Semântica
Para Comunicação Entre Entidades Em Mudanças De Contexto. Tese de Doutorado –
Universidade de São Paulo. Instituto de Ciências Matemáticas e de Computação (ICMC). São
Carlos: ICMC-USP, 2009.
WEISER, M. The Computer for the 21st Century, Scientific American, vol.265, n.3: 1991.
WHATLEY, J. An Agent System to Support Student Teams Working Online. Journal of
Information Technology Education, Vol. 3, 2004.
WÜBBENA, G.; BAGGE, A.; SEEBER, G.; BÖDER, V.; HANKEMEIER, P.: Reducing
Distance Dependent Errors for Real-Time Precise DGPS Applications by Establishing
Reference Station Networks. In: ION GPS-96, Kansas City, Missouri, 1996, p. 1845-1852.
YOKOYAMA, R. S. Gerenciamento de handovers em next generation networks com
agregação de contexto. Dissertação de Mestrado. Universidade de São Paulo (USP) -
Instituto de Ciências Matemáticas e de Computação. São Carlos: ICMC, 2009.
92
Anexos
93
Anexo I: Diagrama de Caso de Uso do Controle de Acesso
94
Anexo II: Diagrama de Classes do Modelo HANDPROV
