Upload
nguyenkhanh
View
218
Download
0
Embed Size (px)
Citation preview
Fornecimento de Serviços Push
Direccionados e Baseados em Localização
Afonso da Fonte Gomes Vaz
Dissertação para obtenção do Grau de Mestre em
Engenharia de Redes de Comunicações
Júri
Presidente: Prof. Rui Jorge Morais Tomaz Valadas
Orientador: Prof. Mário Rui Fonseca dos Santos Gomes
Acompanhante: Eng. Vítor Manuel da Silva Rodrigues
Vogal: Prof. Renato Jorge Caleira Nunes
Setembro 2009
I
Agradecimentos
Este trabalho é submetido ao Instituto Superior Técnico da Universidade Técnica de
Lisboa, completando o ciclo de Mestrado em Engenharia de Redes de Comunicações. O
trabalho foi desenvolvido em ambiente empresarial na empresa Movensis – Serviços de Apoio
a Comunicações, S.A.
Quero expressar aqui os mais sinceros agradecimentos ao Professor Mário Rui Gomes e
ao Professor Vítor Rodrigues que me proporcionaram a oportunidade de realizar este trabalho
e me orientaram ao longo do seu desenvolvimento.
Não posso deixar de agradecer à minha namorada, Rita Martins, que me apoiou quando
tudo parecia impossível, e à minha família, José Vaz, Licínia Gomes e Duarte Vaz, por todos os
sábios conselhos.
Um agradecimento especial e sentido pelo apoio de todos os meus amigos, querendo
destacar o Leandro Menezes, que tanto me ajudou nas traduções e o Diogo Simões pelo seu
apoio incondicional e tão importante contributo para este trabalho.
Lisboa, 22 de Setembro de 2008
Afonso Vaz
II
Resumo
Neste trabalho é apresentada de forma detalhada uma solução que permite o
fornecimento de Serviços Push Baseados em Localização. O trabalho desenvolvido surge
como resposta à falta de oferta de serviços Push que se observa no mercado actual.
Esta solução não é intrusiva permitindo que o utilizador subscreva à recepção do serviço e
defina as suas preferências para que a distribuição de informação seja o mais direccionada
possível. Os utilizadores podem assim receber no seu telemóvel um serviço baseado na sua
localização e nos seus interesses e preferências, sem que directamente o tenham requisitado,
como tipicamente acontece em serviços do tipo Pull.
Palavras-chave: LBS (Location Based Services), comunicações móveis, serviços Push, UMTS
(Universal Mobile Telecommunication System), Parlay X.
Abstract
This work presents, in a detailed way, a solution that allows the provisioning of a Location
Based Push Service. The developed work appears as an answer to the lack of Push Services
that exists in the current market.
This solution is non intrusive, allowing the user to subscribe the reception of the service
and define his own preferences, so that the distribution of information is as targeted as it can
be. This solution allows users to receive in their cell phone a service that is based on their
location and interests and that is not directly requested by them, as opposite to the typical Pull
Services.
Keywords: LBS (Location Based Services), mobile communications, Push Services, UMTS
(Universal Mobile Telecommunication System), Parlay X.
III
Índice
AGRADECIMENTOS ..................................................................................................................... I
RESUMO ....................................................................................................................................... II
ABSTRACT ................................................................................................................................... II
ÍNDICE .......................................................................................................................................... III
ÍNDICE DE FIGURAS .................................................................................................................. V
ÍNDICE DE TABELAS ................................................................................................................. VI
LISTA DE ACRÓNIMOS ............................................................................................................ VII
1 INTRODUÇÃO ....................................................................................................................... 1
1.1 ENQUADRAMENTO E MOTIVAÇÃO ........................................................................................ 1
1.2 OBJECTIVO ........................................................................................................................ 3
1.3 OUTRAS SOLUÇÕES EXISTENTES ....................................................................................... 4
1.4 SOLUÇÃO .......................................................................................................................... 5
1.5 ROADMAP ......................................................................................................................... 6
2 CONCEITOS E TRABALHO RELACIONADO...................................................................... 7
2.1 TÉCNICAS DE LOCALIZAÇÃO DE CURTO ALCANCE ................................................................ 7
2.1.1 Localização por Infra-Vermelhos (IR) e Ultra-Sons ................................................. 7
2.1.2 Localização por Radiofrequência (RFID) e Bluetooth ............................................. 9
2.1.3 Localização por Wireless LAN (WiFi) .................................................................... 11
2.2 SISTEMA DE POSICIONAMENTO GLOBAL (GPS) ................................................................. 11
2.2.1 GPS Assistido (A-GPS) ......................................................................................... 13
2.3 TÉCNICAS DE LOCALIZAÇÃO POR REDE TELEFÓNICA MÓVEL .............................................. 14
2.3.1 Identificação de Célula (Cell ID) ............................................................................ 15
2.3.2 Identificação de Célula Optimizado (Cell ID++) ..................................................... 16
2.3.3 Diferença de Tempo de Chegada Observado (O-TDOA) ..................................... 17
2.3.4 Diferença de Tempo Observado Optimizado ........................................................ 18
2.3.5 Ângulo de Chegada (AoA) ..................................................................................... 18
2.4 PARLAY X ....................................................................................................................... 19
2.4.1 Localização de Terminal ........................................................................................ 21
2.4.2 Mensagens Curtas ................................................................................................. 23
2.5 CONCLUSÃO .................................................................................................................... 23
3 ARQUITECTURA ................................................................................................................. 27
3.1 REDE UMTS ................................................................................................................... 28
3.1.1 UMTS Terrestrial Radio Access Network (UTRAN) .............................................. 28
IV
3.1.2 UMTS Core Network .............................................................................................. 29
3.2 SERVIDOR DE SERVIÇOS PUSH......................................................................................... 29
3.2.1 Componente de Dados .......................................................................................... 30
3.2.2 Componente Lógica ............................................................................................... 30
3.2.3 Componente de Apresentação .............................................................................. 31
3.3 DIAGRAMAS DE INTERACÇÃO ............................................................................................ 32
4 IMPLEMENTAÇÃO .............................................................................................................. 35
4.1 COMPONENTE DE DADOS ................................................................................................. 36
4.1.1 Ferramentas Utilizadas .......................................................................................... 36
4.1.2 Base de Dados....................................................................................................... 37
4.2 COMPONENTE LÓGICA ..................................................................................................... 37
4.2.1 Ferramentas Utilizadas .......................................................................................... 37
4.2.2 Gestor de Eventos ................................................................................................. 40
4.2.3 Gestor de Interesses .............................................................................................. 45
4.2.4 Gestor de Conteúdos ............................................................................................. 48
4.3 COMPONENTE DE APRESENTAÇÃO ................................................................................... 51
4.3.1 Ferramentas Utilizadas .......................................................................................... 52
4.3.2 Painel de Autenticação .......................................................................................... 52
4.3.3 Aplicação Web Cliente ........................................................................................... 54
4.3.4 Aplicação Web Administrador ................................................................................ 54
5 AVALIAÇÃO DA SOLUÇÃO ............................................................................................... 58
5.1 OBJECTIVOS DE AVALIAÇÃO ............................................................................................. 58
5.2 AMBIENTE DE AVALIAÇÃO ................................................................................................. 59
5.2.1 Componentes Utilizados ........................................................................................ 59
5.2.2 Utilização do Emulador .......................................................................................... 61
5.3 TESTES DE INTEGRAÇÃO .................................................................................................. 64
5.3.1 Definição de Preferências ...................................................................................... 64
5.3.2 Identificação de Zona ............................................................................................. 65
5.3.3 Identificação de Serviço ......................................................................................... 66
5.3.4 Criação e Envio de SMS ........................................................................................ 67
5.4 TESTES DE USABILIDADE.................................................................................................. 68
5.5 TESTES DE PERFORMANCE .............................................................................................. 69
6 CONCLUSÕES .................................................................................................................... 71
6.1 TRABALHO FUTURO ......................................................................................................... 72
BIBLIOGRAFIA ........................................................................................................................... 73
V
Índice de Figuras
FIGURA 1-1 – FACTORES CRÍTICOS DE SUCESSO PARA LBS DO TIPO PUSH ......................................... 3
FIGURA 1-2 – FUNCIONAMENTO GLOBAL DA SOLUÇÃO ....................................................................... 6
FIGURA 2-1 – TRANSMISSOR E RECEPTOR DE INFRA-VERMELHOS ....................................................... 8
FIGURA 2-2 – TRANSMISSÃO DE ULTRA-SONS [12] ............................................................................. 9
FIGURA 2-3 – LBS UTILIZANDO BLUETOOTH .................................................................................... 10
FIGURA 2-4 – TRILATERAÇÃO GPS [15] .......................................................................................... 12
FIGURA 2-5 – ERROS POR ATRASO DE PROPAGAÇÃO E MULTIPERCURSO [16] .................................... 13
FIGURA 2-6 – RECEPTOR GPS COMUM (A) E RECEPTOR A-GPS (B) [17] ......................................... 14
FIGURA 2-7 – EXEMPLO DE REUTILIZAÇÃO DE QUATRO FREQUÊNCIAS ............................................... 15
FIGURA 2-8 – POSICIONAMENTO UTILIZANDO IDENTIFICAÇÃO DE CÉLULA COM TIMING ADVANCE (TA)
[19] ........................................................................................................................................ 17
FIGURA 2-9 – TIME DIFFERENCE OF ARRIVAL [6] .............................................................................. 18
FIGURA 2-10 - ANGLE OF ARRIVAL [6] ............................................................................................. 19
FIGURA 2-11 – DESENVOLVIMENTO DE UMA APLICAÇÃO COM WEB SERVICES PARLAY X[8] ............... 21
FIGURA 3-1 - REPRESENTAÇÃO MODULAR DA ARQUITECTURA ......................................................... 28
FIGURA 3-2 - DIAGRAMA DE INTERACÇÃO PARA O REGISTO DE ZONAS E CLIENTES............................ 32
FIGURA 3-3 - DIAGRAMA DE INTERACÇÃO PARA FORNECIMENTO DE SERVIÇO PUSH .......................... 33
FIGURA 3-4 - DIAGRAMA DE INTERACÇÃO PARA ALTERAÇÃO DE INTERESSES .................................... 34
FIGURA 4-1 - FASES DE IMPLEMENTAÇÃO ........................................................................................ 35
FIGURA 4-2 – UTILIZAÇÃO DO TELECOM WEB SERVICES SDK [27] ................................................... 38
FIGURA 4-4 – PÁGINA INICIAL DO TELECOM WEB SERVICES NETWORK EMULATOR ............................ 39
FIGURA 4-5 – CHAMADA À OPERAÇÃO STARTGEOGRAPHICALNOTIFICATION ..................................... 43
FIGURA 4-6 – CHAMADA À OPERAÇÃO SENDSMS ............................................................................. 50
FIGURA 4-7 – PAINEL DE AUTENTICAÇÃO ........................................................................................ 53
FIGURA 4-8 – PAINEL DE REGISTO .................................................................................................. 53
FIGURA 4-9 – PAINEL DE GESTÃO DE SERVIÇO DE CLIENTE ............................................................... 54
FIGURA 4-10 – PAINEL CRIAR CATEGORIA ...................................................................................... 55
FIGURA 4-11 – PAINEL DE CONSULTA DE ZONAS ............................................................................. 56
FIGURA 4-12 – PAINEL DE ASSOCIAÇÃO DE SERVIÇOS A SUBCATEGORIAS ......................................... 57
FIGURA 5-1 – AMBIENTE DE TESTE .................................................................................................. 60
FIGURA 5-2 – CRIAÇÃO E TERMINAIS NO EMULADOR......................................................................... 62
FIGURA 5-3 – MAPA DE SIMULAÇÃO DE DESLOCAMENTO DE TERMINAIS ............................................. 63
FIGURA 5-4 – EMULAÇÃO DE TERMINAL ........................................................................................... 64
FIGURA 5-5 – MAPA COM DEZ UTILIZADORES ................................................................................... 65
FIGURA 5-6 – EXEMPLO DE RECEPÇÃO DE SMS .............................................................................. 68
FIGURA 5-7 – GRÁFICO DE RESULTADOS DE TESTE DE USABILIDADE ................................................ 69
VI
Índice de Tabelas
TABELA 2-1 – EXACTIDÃO DO POSICIONAMENTO POR IDENTIFICAÇÃO DE CÉLULA [19] ........................ 16
TABELA 2-2 – WEB-SERVICES PARLAY X ........................................................................................ 20
TABELA 2-3 – PARÂMETROS NECESSÁRIOS PARA NOTIFICAÇÕES GEOGRÁFICAS NUMA ZONA [20] ....... 22
TABELA 2-4 – PARÂMETROS NECESSÁRIOS PARA ENVIO DE SMS [20] .............................................. 23
TABELA 2-5 – IDENTIFICAÇÃO DAS VANTAGENS DAS TECNOLOGIAS ANALISADAS ................................ 24
TABELA 2-6 – VANTAGENS DAS TÉCNICAS DE LOCALIZAÇÃO GSM/UMTS ......................................... 25
TABELA 2-7- VANTAGENS DOS WEB SERVICES PARLAY X ................................................................ 26
TABELA 4-1 – PARÂMETROS DE SISTEMA PARA STARTGEOGRAPHICALNOTIFICATIONBEAN ................ 41
TABELA 4-2 – PARÂMETROS DE UTILIZADOR PARA STARTGEOGRAPHICALNOTIFICATIONBEAN............ 41
TABELA 4-3 – INFORMAÇÕES INCLUÍDAS NUMA NOTIFICAÇÃO GEOGRÁFICA ........................................ 44
TABELA 4-4 – PARÂMETROS DE SISTEMA PARA SENDSMSBEAN ....................................................... 49
TABELA 4-5 – PARÂMETROS DE UTILIZADOR PARA SENDSMSBEAN ................................................... 49
TABELA 4-6 – ESTADOS DE ENTREGA DE SMS ................................................................................ 51
TABELA 5-1 – ACTIVIDADES DEFINIDAS PARA AVALIAR A SOLUÇÃO .................................................... 59
TABELA 5-2 – DETALHES DA MÁQUINA DE SERVIDOR DE SERVIÇOS .................................................. 60
TABELA 5-3 – DETALHES DA MÁQUINA DE EMULAÇÃO DA PARLAYX WEB-SERVICES GATEWAY ........... 61
TABELA 5-4 – CATEGORIAS E SUBCATEGORIAS DEFINIDAS................................................................ 64
TABELA 5-5 - SERVIÇOS E ASSOCIAÇÕES......................................................................................... 66
TABELA 5-6 – SERVIÇOS E CONTEÚDO ............................................................................................ 67
TABELA 5-7 – RESULTADOS DOS QUESTIONÁRIOS ............................................................................ 68
TABELA 5-8 – TEMPO DE EXECUÇÃO DO FORNECIMENTO DO SERVIÇO ............................................... 70
VII
Lista de Acrónimos
A-GPS Assisted Global Positioning System
AJAX Asynchronous JavaScript And XML
AoA Angle of Arrival
API Application Programming Interface
CN Core Network
DB DataBase
E-OTD Enhanced Observed Time Difference
GMLC Gateway Mobile Location Center
GPS Global Positioning System
GSM Global System for Mobile Communications
GWT Google Web Toolkit
HSS Home Subscriber Server
ID Identificador
IR InfraRed
Java EE Java Enterprise Edition
JDBC Java Database Connectivity
LAN Local Area Network
LBS Location Based Services
MMS Multimedia Messaging Service
MS Mobile Station
MS-ISDN Mobile Integrated Services Digital Number
O-TDOA Observed Time Difference Of Arrival
PDA Personal Digital Assistants
RFID Radio-Frequency IDentification
RMI Remote Method Invocation
RPC Remote Procedure Calls
RTT Round Trip Time
SDK Software Development Kit
SGSN Serving GPRS Support Node
SMS Short Message Service
SOAP Simple Object Access Protocol
SQL Structured Query Language
UMTS Universal Mobile Telecommunications System
UTRAN UMTS Terrestrial Radio Access Network
WSDL Web Services Definition Language
XML eXtensible Markup Language
VIII
XWSS XML Web Services Security
1
1 Introdução
1.1 Enquadramento e Motivação
Os telefones móveis e a Internet vieram revolucionar as comunicações e,
consequentemente, o modo de vida da população. Com a Internet criou-se um sistema global
onde computadores de todo o mundo se encontram conectados entre si, formando uma rede, e
possibilitando a comunicação entre os diversos utilizadores que se encontrem ligados a este
sistema. Trata-se na verdade de uma “rede de redes” onde milhões de redes privadas,
públicas, académicas e empresariais formam uma rede global. A Internet possibilitou assim a
partilha de conhecimento e informação tornando-se na maior infra-estrutura informacional que
alguma vez existiu [1]. Novos serviços tais como o correio electrónico, as conversações online
e a transferência e partilha de ficheiros surgiram causando grande impacto na população e em
como as suas tarefas do dia-a-dia são realizadas.
A par da evolução da Internet, observa-se também um crescimento grande no mercado
das comunicações móveis. Este mercado, ao contrário do que se verificava quando o seu
aparecimento, já não se baseia única e exclusivamente na realização de chamadas móveis. Os
terminais móveis dos nossos dias, como os telemóveis, os telefones inteligentes
(Smartphones) e os Personal Digital Assistants (PDAs), fornecem já os mais variados serviços
e aplicações tais como a vídeo chamada, o envio de mensagens de texto, imagens e vídeo e a
utilização de agenda digital.
Cada vez mais terminais permitem também o acesso à Internet. Este acesso, além de
possibilitar a utilização dos serviços típicos fornecidos pela Internet como o correio electrónico
ou as conversações online, tem especial interesse na consulta de informação acerca do que
rodeia o terminal móvel. A Internet possibilita assim que um utilizador do serviço móvel, em
qualquer altura ou lugar, obtenha, não só informações de eventos (cinema, concertos, festas,
transito) mas também informações acerca de locais de interesse (restaurantes, museus,
hospitais, cidades) [2]. A localização do terminal móvel, e consequentemente do utilizador, é
assim um ponto-chave no fornecimento deste tipo de informações. A utilização de terminais
móveis ligados a uma rede permite a obtenção de informações que caracterizem a situação em
que um determinado utilizador se encontra, ou seja, é possível inserir o utilizador num
determinado contexto e assim fornecer as informações que lhe são relevantes [2].
O conhecimento da localização do terminal móvel cria um novo universo de aplicações e
serviços que podem ser fornecidos [3]. Esta classe de aplicações e serviços é denominada por
Location Based Services (LBS). Os LBS podem assim ser definidos como serviços
informacionais acessíveis através de terminais móveis ligados a uma rede móvel e que utilizam
a localização do terminal [4]. O número de aplicações baseadas em localização é muito vasto.
2
Seria impossível realizar uma lista de todas as aplicações existentes pois esta é uma área que
é alvo de muita investigação e encontra-se em forte crescimento [2].
Podem-se no entanto distinguir dois tipos de serviços de localização considerando se a
informação é fornecida com a interacção do utilizador ou não [2]:
• Pull services fornecem informações ou serviços que foram directamente
requisitados pelo utilizador.
• Push services fornecem informações ou serviços que foram indirectamente
requisitados pelo utilizador ou que não foram requisitados de todo. Os push
services são geralmente activados por um evento que foi despoletado se o
utilizador alcançou uma área ou uma altura no tempo específica. Este tipo de
serviços, como não estão relacionados com a interacção directa do utilizador,
são mais complexos de estabelecer.
A motivação deste trabalho prende-se com o facto de a grande maioria dos serviços
baseados em localização fornecidos actualmente são serviços Pull onde o utilizador requisita
directamente um determinado serviço, não se assistindo a uma oferta de serviços Push que
satisfaça as necessidades dos utilizadores.
Neste tipo de serviços não directamente requisitados pelo utilizador, é necessário
considerar a quantidade de utilizadores a que o serviço chega. Muitos serviços baseados em
localização são frequentemente fornecidos sobre tecnologias que não se encontram
disponíveis na generalidade dos terminais móveis mais frequentemente utilizados. Por outro
lado, tratando-se de um serviço do tipo Push é necessário que o serviço se realize sobre uma
tecnologia que se encontre constantemente disponível no terminal móvel, não sendo
necessária a interacção do utilizador para activar a mesma.
Muitos dos serviços baseados em localização são também muito limitados, ou seja,
existem serviços que são apenas aplicáveis caso o utilizador se encontre num determinado
meio, como por exemplo num espaço fechado ou ao a livre.
Concluindo, foram identificados os seguintes factores que são motivação para este
trabalho e que são considerados críticos para o sucesso de um serviço baseado em
localização do tipo Push (ver Figura 1-1):
• Globalidade: o fornecimento de serviços baseados em localização muitas vezes
não chega à população em geral pois são realizados sobre tecnologias pouco
utilizadas nos terminais móveis mais populares.
• Disponibilidade: a tecnologia utilizada para se fornecer um serviço baseado em
localização nem sempre está constantemente activa nos terminais móveis
utilizados mais frequentemente (telemóveis, PDAs e Smartphones) sendo
necessária a interacção dos utilizadores.
• Acessibilidade: Muitas das tecnologias utilizadas para fornecimento de serviços
baseados em localização não são acessíveis em qualquer local pois são muito
dependentes das dimensões ou cobertura do local.
Figura 1-1 – Factores críticos de sucesso para LBS do tipo
1.2 Objectivo
No decorrer dos últimos anos temos assistido a uma evolução de aplicações que utilizam
a localização do utilizador. Um dos exemplos mais marcantes é o sucesso do GPS (
Positioning System) que permite aos utilizadores receber informações de percurso, destino e
navegação.
O objectivo deste trabalho é encontrar uma solução modular e abrangente que
fornecimento de serviços baseados em localização do tipo
independentemente do tipo de espaço (fechado, aberto)
assim ser possível actualizar ou alterar cada um dos componentes da solução sem ser
necessária a alteração dos restantes componentes. Tendo em consideração os factor
críticos apresentados na Figura
abrangência suportando assim
meios (ambientes fechados, pequenos, espaços abertos).
Pretende-se ainda que o utilizador possa definir e actualizar quais
modo a que este só receba informações e serviços que se encontrem relacionados com os
seus interesses. A subscrição no serviço é opção do utilizador, não sendo o fornecimento de
serviços intrusivo. O utilizador,
interesses e preferências.
Resumindo, de uma perspectiva funcional,
possível:
• Definir zonas com diferentes características geográficas
dimensões, e diferentes meios
• Associar essas zonas
Disponibilidade
3
Factores críticos de sucesso para LBS do tipo Push
No decorrer dos últimos anos temos assistido a uma evolução de aplicações que utilizam
a localização do utilizador. Um dos exemplos mais marcantes é o sucesso do GPS (
que permite aos utilizadores receber informações de percurso, destino e
O objectivo deste trabalho é encontrar uma solução modular e abrangente que
fornecimento de serviços baseados em localização do tipo Push em zonas
ndependentemente do tipo de espaço (fechado, aberto) em que o utilizador se encontre
assim ser possível actualizar ou alterar cada um dos componentes da solução sem ser
necessária a alteração dos restantes componentes. Tendo em consideração os factor
Figura 1-1, esta modularidade da solução deve estar associada à
assim o maior número possível de terminais móveis
meios (ambientes fechados, pequenos, espaços abertos).
se ainda que o utilizador possa definir e actualizar quais o seus interesses
modo a que este só receba informações e serviços que se encontrem relacionados com os
A subscrição no serviço é opção do utilizador, não sendo o fornecimento de
utilizador, ao subscrever o serviço deve logo definir quais os seus
de uma perspectiva funcional, pretende-se encontrar uma solução onde seja
com diferentes características geográficas (áreas com difere
e diferentes meios).
r essas zonas a serviços informacionais.
LBS tipo Push
Globalidade
AcessibilidadeDisponibilidade
Push
No decorrer dos últimos anos temos assistido a uma evolução de aplicações que utilizam
a localização do utilizador. Um dos exemplos mais marcantes é o sucesso do GPS (Global
que permite aos utilizadores receber informações de percurso, destino e
O objectivo deste trabalho é encontrar uma solução modular e abrangente que suporte o
zonas específicas,
em que o utilizador se encontre. Deve
assim ser possível actualizar ou alterar cada um dos componentes da solução sem ser
necessária a alteração dos restantes componentes. Tendo em consideração os factores
, esta modularidade da solução deve estar associada à
o maior número possível de terminais móveis em diversos
o seus interesses de
modo a que este só receba informações e serviços que se encontrem relacionados com os
A subscrição no serviço é opção do utilizador, não sendo o fornecimento de
deve logo definir quais os seus
uma solução onde seja
(áreas com diferentes
4
• Identificar quando um utilizador entra numa dessas zonas e enviar informações
que sejam do seu interesse e que estejam relacionadas com a localização da
zona onde se encontre.
Os seguintes requisitos foram identificados para que a solução final cumpra os objectivos
apontados acima:
• O serviço tem de ser transparente ao utilizador, ou seja, o utilizador não deve
requisitar directamente informações e desconhece o modo como estas chegam
até ele.
• A distribuição de informação e de serviços deve ser possível em diferentes áreas
(pequenas ou grandes) e ambientes (ao ar livre ou em ambientes fechados).
• O utilizador deve poder seleccionar que serviços ou informações são do seu
interesse.
Tomando em consideração as questões que motivaram este trabalho e os objectivos e
requisitos a alcançar, formulou-se a seguinte hipótese que se pretende provar:
Utilizando tecnologias existentes que suportam serviços baseados em localização, é
possível criar uma solução, acessível a um elevado número de utilizadores, que suporte o
fornecimento de serviços Push aplicados a zonas específicas, baseados não só na localização
mas também nas preferências de cada utilizador.
De forma a alcançar o objectivo proposto, existem diversos problemas que são precisos
ter em conta. O principal problema prende-se com o facto de existirem diversas técnicas e
meios que suportam serviços de localização.
Torna-se necessário estudar as diferentes técnicas de localização suportadas pela rede
telefónica móvel, bem como as que não são suportadas por esta, de forma a verificar qual
dessas tecnologias melhor se adequa ao fornecimento de serviços Push e se é, ou não,
suportada pela rede móvel e acessível pela grande maioria dos telemóveis.
A realização deste trabalho é feita integralmente em ambiente empresarial, na Movensis,
localizada no Tagus Park e posicionada no mercado de desenvolvimento de soluções móveis
[5].
1.3 Outras Soluções Existentes
Embora existam já diversas tecnologias que suportam o fornecimento de serviços baseados
em localização, estas são, na sua generalidade, bastante limitadas, não satisfazendo as
necessidades de um serviço do tipo Push. A grande maioria destas soluções encontra-se
assim restringida a um número pequeno de utilizadores e são apenas aplicáveis em espaços
com características específicas. No entanto, existem algumas técnicas de localização que têm
bastante relevância no panorama dos serviços baseados em localização:
• Técnicas de localização de curto alcance: As técnicas de localização de curto
alcance são geralmente utilizadas em espaços de pequena dimensão. As
tecnologias mais utilizadas nestas técnicas de localização são os Infra-Vermelhos
5
(IR), os Ultra-Sons, a Radiofrequência (RFID), o Bluetooth e o Wireless LAN (WiFi).
Todas estas tecnologias são de curto alcance onde o dispositivo a ser localizado
não pode estar a uma grande distância dos sensores utilizados para o cálculo da
sua localização.
• Global Positioingn System (GPS): Trata-se de um sistema utilizado mundialmente e
que consiste numa rede de satélites colocados em diferentes órbitas e espaçados
de modo a que pelo menos cinco satélites sejam detectáveis de qualquer ponto na
terra. Estes satélites são utilizados como pontos de referência para cálculo de
posições de forma precisa [6]. Esta técnica de localização, apesar de ser já bastante
utilizada mundialmente em diversos serviços de navegação, funciona apenas ao ar
livre onde existe uma linha de visão entre o receptor e o satélite.
• Técnicas de localização por rede telefónica móvel: Neste tipo de técnicas, a rede
telefónica móvel é utilizada para determinar a posição dos telemóveis conectados à
rede. Esta técnica, apesar de ser menos precisa que o GPS, tem a vantagem de
funcionar em qualquer local em que os terminais móveis tenham rede. Um exemplo
de um serviço que utiliza a rede telefónica móvel é o Localizz da TMN é que permite
visualizar, através de uma página na Internet, a posição de vários recursos móveis
da empresa (telemóveis, viaturas, máquinas, contentores, entre outros)[7].
1.4 Solução
A utilização do telemóvel é cada vez mais comum, sendo o terminal móvel mais utilizado
nos nossos dias. Apresenta-se assim como o dispositivo mais vantajoso na distribuição de
serviços baseados em localização. Um simples telemóvel pode suportar diversas técnicas de
localização em simultâneo. Não se limita assim às técnicas de localização por rede telefónica
móvel, podendo também suportar GPS e ainda algumas técnicas de curto alcance como a
localização por Infra-Vermelhos, Bluetooth ou WiFi dependendo do modelo do telemóvel que é
utilizado.
O Parlay X define um conjunto de normas de Web Services para telecomunicações
definidos pelo Parlay Group [8], um consórcio não lucrativo. O objectivo destes Web Services é
permitir a utilização de capacidades da rede telefónica móvel de forma simples, no
desenvolvimento de aplicações, permitindo que tanto as operadoras de redes móveis, como
outros fornecedores de serviços externos desenvolvam, com facilidade, novos serviços de
telecomunicações.
Uma das capacidades de rede disponibilizada é a localização de terminais através do Web
Service Terminal Location. Este Web-Service permite a recepção de notificações de
localização na entrada de terminais em zonas pré-definidas. Desta forma, quando um utilizador
entra numa área de interesse que se encontre registada, é enviada uma notificação desse
evento com informações acerca da localização desse utilizador. A utilização deste Web-Service
permite transparência em relação à técnica de localização utilizada, ou seja, é utilizada
qualquer técnica de localização que seja suportada pela rede telefónica móvel ou pelo próprio
6
terminal. Assim, no pior cenário, será utilizada a técnica básica de localização por rede
telefónica móvel que se encontra sempre disponível nas operadoras que suportam técnicas de
localização e que satisfaz os requisitos para o fornecimento de serviços Push baseados em
localização.
Outro Web Service disponibilizado pelo ParlayX é o de Mensagens Curtas (Short
Messaging) que permite o envio e recepção de mensagens SMS (Short Message Service). O
envio deste tipo de mensagens tem grande relevância no contexto da solução pretendida pois
trata-se de um serviço suportado por praticamente todos os telefones móveis.
Com a utilização destes dois Web Services Parlay X torna-se possível o desenvolvimento
de uma solução que recebe notificações de localização acerca dos utilizadores registados e
fornece um serviço informacional, através de SMS, independentemente da marca ou modelo
do terminal (ver ).
Figura 1-2 – Funcionamento Global da Solução
1.5 Roadmap
Para além deste capítulo introdutório, este documento é composto por mais cinco
capítulos. No segundo capítulo são apresentadas as diversas tecnologias que suportam a
localização de terminais e o fornecimento de serviços baseados em localização.
No terceiro capítulo é apresentada a arquitectura da solução proposta que satisfaz os
requisitos já identificados.
O quarto capítulo foca-se na implementação da solução. Os detalhes e opções mais
relevantes a nível de implementação são assim descritos e justificados bem como os desafios
que foram surgindo nesta fase.
O capítulo cinco descreve como foi a solução avaliada a nível qualitativo e quantitativo
tendo em consideração a hipótese formulada e, por último, no sexto capítulo são apresentadas
as conclusões do trabalho bem como o trabalho futuro a desenvolver.
7
2 Conceitos e Trabalho Relacionado
Devido à grande utilidade e variedade de aplicações que podem ser fornecidas por um
serviço baseado em localização (LBS – Location Based Service), esta é uma área onde se
realiza muita investigação e se tentam encontrar cada vez mais e melhores soluções.
Existem três grandes componentes que são necessários para a implementação de LBS
[6]:
• Tecnologia necessária à determinação da localização do terminal móvel
• Mapeamento da informação obtida com uma base de dados geo-referenciada para
se conseguir obter uma posição no mapa
• Infra-estrutura de comunicação sem fios
Neste capítulo irão ser analisadas as principais tecnologias que suportam a obtenção de
informação de localização de terminais móveis de forma a se concluir qual a mais adequada
aos objectivos propostos. Para cada uma dessas tecnologias procura-se também explicitar
como cada uma delas pode ser aplicada ao conceito de serviços baseados em localização ou
LBS.
2.1 Técnicas de Localização de Curto Alcance
As técnicas de localização de curto alcance são geralmente utilizadas em espaços de
pequena dimensão. Deste modo, este tipo de técnicas é geralmente utilizado em salas de aula,
laboratórios, edifícios hospitalares e outros onde a localização possa ser realizada num curto
alcance [6].
As tecnologias de localização de curto alcance que são actualmente utilizadas são as
seguintes:
• Infra-Vermelhos (IR)
• Ultra-Sons
• Radiofrequência (RFID)
• Bluetooth
• Wireless LAN (WiFi).
2.1.1 Localização por Infra-Vermelhos (IR) e Ultra-Sons
A radiação por infra-vermelhos é realizada na gama de frequências imediatamente abaixo
da luz à qual o olho humano é sensível e, tal como esta, está confinada ao espaço fechado
onde é gerada não podendo ser detectada fora do local. Deste modo, a radiação por infra-
vermelhos não irá interferir em sistemas da mesma natureza (desde que em espaços fechados
diferentes) e, não irá também interferir com o espectro de frequências rádio dado que os
espectros utilizados são diferentes [9].
8
A técnica de localização por infra-vermelhos é realizada através de uma comunicação por
infra-vermelhos entre dispositivos denominados por Active badges (transmissores móveis de
infra-vermelhos) e sensores infra-vermelhos (receptores fixos de infra-vermelhos) (ver Figura
2-1) sendo necessária uma linha de visão entre os dois. Estes dispositivos são transportados
pelos utilizadores do serviço e transmitem Códigos de Identificação (ID codes) que são sinais
infra-vermelhos únicos que identificam cada um dos badges e, consequentemente, os
utilizadores associados a cada badge. Os sensores são estrategicamente colocados em
paredes e tectos de um determinado edifício ou sala e a sua localização é previamente
conhecida antes do cálculo da localização dos utilizadores. A função dos sensores é captar os
Códigos de Identificação enviados pelos badges e, por sua vez, comunicá-los ao software de
localização [6]. A localização do utilizador é assim determinada através da sua proximidade aos
sensores que recebem o ID code do seu dispositivo.
Figura 2-1 – Transmissor e receptor de infra-vermelhos
Os ultra-sons são sons com uma frequência acima do limite de audição humano. Na
técnica de localização através de ultra-sons, dispositivos denominados por Active Bats emitem
um som ultra sónico para receptores colocados numa determinada sala ou edifício (ver Figura
2-2). Neste tipo de técnica, três receptores irão determinar o tempo de propagação do sinal
ultra-som transmitido pelo Active Bat e, através de triangulação, é possível calcular não só a
posição do utilizador que transporta o Active Bat mas também a sua direcção, conseguindo-se
uma maior precisão que quando se utiliza Infra-Vermelhos [6] [10]. Este sistema não utiliza as
reflexões acústicas de um espaço fechado. Utiliza apenas o sinal directo de um transmissor
para um receptor para cálculo da distância entre ambos, sendo todas as reflexões ignoradas.
Deste modo, para o cálculo da distância ser bastante preciso, é necessária linha de visão entre
o transmissor e receptor, estando por isso os sensores geralmente colocados no tecto [11].
9
Figura 2-2 – Transmissão de ultra-sons [12]
Os transmissores de infra-vermelhos e ultra-sons podem também encontrar-se embutidos
noutros dispositivos, apesar de não ser comum, não sendo assim necessário o transporte
propositado dos Active badges/bats para se determinar a localização.
A utilização destas duas técnicas para determinação de localização e fornecimento de
serviços tem as seguintes limitações:
• Limitado a uma sala ou a espaços relativamente pequenos.
• Necessidade de linha de visão entre transmissores e receptores.
• Necessidade do utilizador transportar um dispositivo propositadamente para o
efeito do serviço de localização ou integrar os badges/bats noutro tipo de
dispositivo.
• Necessidade de montar uma infra-estrutura propositadamente para o fornecimento
de serviços baseados em localização.
2.1.2 Localização por Radiofrequência (RFID) e Bluetooth
RFID, que significa Rafio Frequency Identification, é um pequeno dispositivo que combina
uma antena, emissores/receptores e etiquetas. Cada etiqueta é programada com a informação
que identifica o objecto. De forma a se utilizar esta tecnologia para determinar a localização, é
necessária a instalação de etiquetas RFID de leitura em posições estudadas e é necessária
ainda uma base de dados de etiquetas RFID que determinam a sua posição no espaço [12].
Existem dois tipos distintos de etiquetas RFID [12]:
• Passivas: este tipo de etiquetas não tem fonte de energia própria. A energia
necessária ao seu funcionamento é obtida através de energia que é transmitida
pelo leitor RFID através de radiofrequência funcionando apenas a distâncias curtas
do leitor (desde alguns centímetros até um, dois metros dependendo da frequência
utilizada). Neste tipo de etiquetas a localização das mesmas é determinada no
momento da sua leitura.
• Etiquetas RFID activas: este tipo de etiquetas tem fonte de energia própria que as
alimenta continuamente permitindo uma comunicação a um alcance muito superior
que ao utilizar (pode chegar a dezenas de metros). Neste tipo de etiquetas a
10
localização pode ser determinada através da leitura de uma etiqueta por um leitor
ou ainda por dois ou mais leitores para, através de triangulação, se obter uma
localização mais precisa.
Outra forma de se localizar terminais móveis através de radiofrequência é utilizando o
Bluetooth. O Bluetooth permite a criação de redes locais sem fios e uma comunicação a uma
distância relativamente curta (poder ir tipicamente até os dez, quinze metros) [13]. A grande
vantagem na utilização do Bluetooth é que se encontra embebido em muitos terminais móveis
que se utilizam com frequência (telemóveis, smartphone, PDAs) não sendo necessário que o
utilizador transporte dispositivos específicos para se determinar a localização. Cada dispositivo
Bluetooth tem um ID (Identificação) único que permite, através de um ou mais receptores,
determinar a localização do dispositivo à semelhança do que é feito com as etiquetas RFID
activas.
Esta tecnologia é hoje em dia bastante utilizada na distribuição de conteúdos aos
utilizadores. Um exemplo prático é a sua utilização em diversos eventos onde pontos de
acesso Bluetooth conectados a um servidor multimédia enviam conteúdos relacionados com o
evento aos terminais móveis dos diversos utilizadores na área.
Figura 2-3 – LBS utilizando Bluetooth
A utilização destas técnicas para determinação de localização e fornecimento de serviços
tem as seguintes limitações face aos objectivos propostos:
• Necessidade de montar uma infra-estrutura propositadamente para o fornecimento
de serviços baseados em localização.
• No caso da utilização das etiquetas RFID há a necessidade do utilizador
transportar uma etiqueta RFID pois de um modo geral estas não se encontram
embutidas em terminais móveis utilizados frequentemente.
• No caso em que o Bluetooth se encontra embebido em telemóveis, smartphones
ou PDAs há a necessidade do utilizador o activar pois na grande maioria das vezes
este encontra-se desactivado.
11
2.1.3 Localização por Wireless LAN (WiFi)
A Wireless LAN é utilizada maioritariamente para fornecer um ponto de acesso à internet
para PDAs ou computadores portáteis. O Wi-Fi emite sinais de radiofrequência 802.11 do
router wireless que podem ser utilizados para determinar a localização de qualquer dispositivo
WiFi tais como computadores portáteis, PDAs e smartphones. Existem três formas básicas
onde a localização dos dispositivos WiFi pode ser determinada:
• Através das coordenadas da antena, isto é, os routers aos quais os dispositivos
estão conectados com precisão proporcional à densidade de antenas no sistema
• Através da triangulação da força do sinal recebida em variadas localizações de
recepção
• Mapeando a força do sinal observada nos diversos routers colocados num
determinado edifício ou área num mapa da área pretendida. Desta forma, se um
utilizador se encontra num edifício, a força do sinal de todos os pontos de acesso
ao alcance do dispositivo do utilizador podem determinar a sua localização fazendo
coincidir a força do sinal calculada com as forças mapeadas previamente [6].
Este método de localização tem a vantagem ser realizado sobre uma tecnologia que já se
encontra implementada em diversos locais não sendo sempre necessário montar uma estrutura
propositadamente para o efeito. A utilização da tecnologia WiFi para determinar a localização
tem as seguintes limitações:
• A utilização do Wi-Fi nos terminais móveis tem um elevado consumo de bateria do
terminal.
• Muitos dos terminais móveis utilizados actualmente não suportam a utilização do
WiFi.
• Nos terminais móveis que suportam Wi-Fi este pode nem sempre se encontrar
activado.
• Poderá ser necessária a implementação de uma infra-estrutura ou actualizações às
existentes.
• Os Routers Wireless podem mudar de localização o que pode levar a erros de
cálculo de posição e constantes actualizações.
2.2 Sistema de Posicionamento Global (GPS)
Entre todos os sistemas descritos o GPS (Global Positioning System) é o que apresenta
uma maior precisão. Trata-se de um sistema utilizado mundialmente e que consiste numa rede
de satélites colocados em diferentes órbitas e espaçados de modo a que pelo menos cinco
satélites sejam detectáveis de qualquer ponto na terra. Estes satélites são assim utilizados
como pontos de referência para cálculo de posições de forma precisa [6].
Cada satélite emite sinais rádio que um determinado receptor GPS utiliza para estimar a
localização do satélite bem como a distância entre o satélite e o receptor. Este cálculo é feito
12
através do tempo que o sinal rádio demora a chegar até ao receptor. Através da utilização dos
sinais rádio de pelo menos três satélites, o receptor pode determinar a sua localização através
de uma técnica conhecida frequentemente como triangulação mas mais precisamente
denominada trilateração (ver Figura 2-4) [14].
Figura 2-4 – Trilateração GPS [15]
Na trilateração, os satélites encontram-se no centro de uma esfera imaginária cujo raio é
igual à distância do receptor. Com três satélites consegue-se assim obter dois pontos na
intersecção das três esferas onde um desses pontos corresponde à localização do receptor
[14].
Com a utilização de quatro ou mais satélites, o receptor consegue determinar de forma
precisa a latitude, longitude e altitude do utilizador. Uma vez calculada a posição exacta do
utilizador, o receptor pode determinar outras informações úteis tais como a velocidade, a
distância até ao destino e o tempo estimado da viagem[14].
Posteriormente ao surgimento do GPS surgiu uma importante modificação, o Assisted
GPS para contornar os seguintes problemas:
• Atrasos de propagação devidos ao vapor de água e outras partículas na
atmosfera (ver Figura 2-5)
• Erros de multipercurso que ocorrem quando um sinal é reflectido por um
edifício ou terreno antes de alcançar a antena do receptor (ver Figura 2-5).
• Uma grande proximidade de satélites escolhidos pelo receptor aumenta
margem de erros e pode diminuir a precisão.
13
Figura 2-5 – Erros por atraso de propagação e multipercurso [16]
A localização por GPS apresenta as seguintes limitações aos objectivos propostos:
• Muito sujeito a interferências não funcionando em espaços fechados, túneis ou
até mesmo em algumas zonas de cidades muito densamente povoadas
• Existem poucos terminais móveis que sejam utilizados frequentemente que
suportem GPS (apenas alguns PDAs e smartphones).
• Os receptores específicos de GPS não são constantemente transportados
pelos utilizadores e a sua utilização muitas vezes não é pessoal nem se
encontra completamente generalizada na população.
2.2.1 GPS Assistido (A-GPS)
O GPS encontra-se concebido para ser utilizado ao ar livre e não estando preparado para
ser utilizado dentro de edifícios ou até mesmo em zonas urbanas com aglomeração densa de
edifícios, túneis e pontes. Contudo, interligar o GPS a outras infra-estruturas de redes móveis
como o Bluetooth, as redes celulares ou o WiFi pode trazer grandes vantagens na utilização do
GPS nos ambientes descritos [6].
O Assisted GPS (A-GPS) descreve assim um sistema onde fontes externas, como um
assistance server e uma rede de referência, ajudam um determinado receptor GPS a realizar
as tarefas necessárias para calcular a sua posição.[17]. O assistance server tem a capacidade
de aceder a informação proveniente da rede de referência (como a rede telefónica móvel) e
dispõe também de poder computacional muito superior ao receptor GPS. O assistance server
vai comunicar com o receptor GPS através de uma ligação wireless e, com a ajuda da rede, o
receptor consegue operar de forma mais rápida e eficiente que um receptor GPS não assistido.
Isto deve-se ao facto de um conjunto de tarefas que tradicionalmente são realizadas no
receptor GPS passam a ser partilhadas com o assistance server [17] (ver Figura 2-6).
Existem os seguintes tipos de dados que o assistance server pode fornecer ao receptor
GPS [17]:
14
• Informações precisas acerca dos satélites
• Posição inicial
• Selecção de satélites e respectiva distância, para receptores apenas A-GPS
• Computação de soluções de posicionamento do utilizador
Figura 2-6 – Receptor GPS comum (a) e Receptor A-GPS (b) [17]
Assim, enquanto num receptor comum é necessário procurar os sinais dos satélites,
descodificar as suas mensagens para posteriormente ser realizado o cálculo da sua posição (o
que requer sinais fortes), num receptor A-GPS uma rede de telefones móveis, por exemplo,
pode auxiliar o receptor fornecendo uma posição inicial estimada (através da célula em que se
encontra, por exemplo) e fornecendo também informações acerca dos satélites que se
encontram visíveis [17]. O receptor A-GPS pode assim utilizar sinais mais fracos e consegue
mais rapidamente determinar a sua posição.
A utilização do A-GPS tem a seguinte limitação:
• Muito poucos dispositivos suportam este sistema de localização
2.3 Técnicas de Localização por Rede Telefónica Móvel
A grande maioria dos telefones móveis não vem equipada para suportar o GPS. Como tal,
surgiu a necessidade de encontrar uma solução onde o telefone móvel seja suficiente para
determinar a posição de um utilizador.
As operadoras de comunicações móveis tipicamente utilizam sistemas celulares como o
GSM (Global System for Mobile Communications) e o UMTS (Universal Mobile
Telecommunications System) para realizar chamadas de voz móveis. É através deste sistema
que as principais técnicas de localização por rede telefónica móvel se baseiam.
Num sistema celular existem transmissores denominados por base stations que cobrem
uma determinada área denominada por célula. O raio de cada célula tipicamente varia entre as
dezenas de metros em edifícios, centenas em cidades e dezenas de quilómetros em áreas
rurais [18]. A forma das células nunca são círculos perfeitos ou hexágonos como é
frequentemente representado pois dependem do ambiente onde se encontram (edifícios,
montanhas, vales), das condições climatéricas e inclusivamente da quantidade de utilizadores
15
por célula. É ainda relevante referir que, para evitar interferências, diferentes base stations que
se encontrem adjacentes umas às outras utilizam frequências diferentes (ver Figura 2-7). O
número de frequências diferentes a utilizar depende do tamanho das células e também do
número de utilizadores por célula
Figura 2-7 – Exemplo de reutilização de quatro frequências
O terminal móvel, ou mobile station (MS) vai assim mover-se entre diversas células
comunicando com a respectiva base station. Neste capítulo serão estudadas as técnicas de
localização que se baseiam precisamente na comunicação entre o terminal móvel e a base
station.
2.3.1 Identificação de Célula (Cell ID)
Trata-se do método básico de posicionamento para oferecer um serviço de localização,
dado que todos os dispositivos suportam esta tecnologia [19]. Esta técnica requer a
identificação e localização da base station onde o telefone móvel se encontra conectado. A
localização da base station é assim a localização do terminal e, conforme o utilizador se vai
deslocando, a rede acompanha em que base stations o terminal se vai registando e a
localização do utilizador é actualizada [6].
A exactidão desta técnica de localização depende da infra-estrutura da rede, ou seja,
depende do tamanho e densidade das células (ver Tabela 2-1)
A precisão da localização pode ser aumentada com a utilização desta técnica
conjuntamente com as técnicas Timing advance ou a medição da força de sinal.
16
Tabela 2-1 – Exactidão do posicionamento por identificação de célula [19]
Rural Suburbano Urbano
Precisão 1 km – 35 km
Tipicamente 15 km
1 km – 10 km
Tipicamente 5 km
500 m – 5 km para
macro células
50 m – 500 m para
micro células
Esta técnica apresenta grandes vantagens na medida em que pode ser realizada pela
operadora sem necessidade de instalação de qualquer tipo de software adicional nos terminais
móveis.
2.3.2 Identificação de Célula Optimizado (Cell ID++)
O Cell ID++ compreende um conjunto de várias tecnologias: Identificação por célula,
Timing Advance (TA) e medição da força do sinal. O GSM utiliza um esquema TDMA (Time
Division Multiple Access) e, como tal, para o sistema funcionar, é necessário que todos os
sinais cheguem à base station no tempo apropriado. A altura em que o sinal é enviado do
dispositivo para a base station é variável, dependendo da distância a que o dispositivo se
encontra da base station. Para se conseguir saber qual a altura em que o dispositivo deve
enviar os seus sinais, cada base station envia um timing advance a cada um dos dispositivos
que se encontra conectado. O timing advance é assim a medida que diz quanto tempo é que o
dispositivo deve antecipar a transmissão de forma a assegurar que o sinal chegue à base
station no time slot em que é suposto chegar [19].
A distância do dispositivo à base station é dependente da duração do timming advance e,
como tal, é possível calcular informação de localização mais precisa que utilizando apenas a
técnica de identificação de célula (ver Figura 2-8). Esta técnica é utilizada apenas se o
utilizador se encontrar a 550 metros ou mais da base station dado que o ajustamento é
calculado dependendo de quantos múltiplos de 500-550 metros o dispositivo se encontra da
base station. No caso das redes de terceira geração, como o UMTS, é utilizado o Round Trip
Time (RTT) que mede o tempo que as ondas rádio demoram numa ida e volta entre a base e o
terminal móvel, sendo esta medição bastante mais precisa que o TA.
17
Figura 2-8 – Posicionamento utilizando identificação de célula com Timing Advance (TA) [19]
Complementarmente ao Timing Advance/RTT, um telefone móvel mede continuamente a
força de sinal de cada uma das base stations que detecta e reporta esta informação às
mesmas para que a comunicação entre o terminal móvel e as base stations disponha da
melhor qualidade de sinal possível. Desta forma, é possível calcular a localização aproximada
do dispositivo por identificação de célula, força de sinal e timing advance/RTT permitindo o
fornecimento de serviços para os terminais móveis de forma modo mais preciso que apenas na
identificação de célula. A medição da força do sinal não fornece só por si resultados muito
preciso pois depende fortemente das características do terreno, do material utilizado nos
edifícios e das condições climatéricas [6].
Esta solução apresenta todas as vantagens da técnica por identificação de célula
somadas ao facto de se conseguir uma maior precisão (tipicamente 80 metros). Como
limitação, esta técnica necessita de mais alterações e cálculos do lado da operadora o que
pode trazer uma reestruturação significativa na rede e, consequentemente, custos muito
elevados.
2.3.3 Diferença de Tempo de Chegada Observado (O-TDOA)
A técnica de diferença de tempo de chegada observado (O-TDOA - Observed Time
Difference of Arrival) mede o tempo de chegada (Time of Arrival) do sinal de um receptor móvel
a um número de base stations localizadas em posições exactas previamente conhecidas [19].
O método O-TDOA requer assim informações temporais obtidas através dos sinais transmitidos
por um dispositivo móvel. É assim importante que os relógios da base station e do dispositivo
se encontrem sincronizados com a maior exactidão possível, o que não é frequente [19].
Se, por exemplo, tivermos três base stations, duas medições independentes da diferença
do tempo de chegada (TDOA) podem ser realizadas e utilizadas para calcular a posição de um
receptor móvel. Cada uma destas medições vai definir uma linha hiperbólica onde o receptor se
deve encontrar. A intersecção das duas linhas, correspondentes às duas medições, vai definir
a posição do dispositivo (ver Figura 2-9)[19].
Com uma sincronização muito exacta, é possível com esta técnica conseguir uma
precisão entre 125 a 200 m [19]. A análise de custo benefício não é muito favorável à utilização
18
desta técnica pois o custo de implementação da mesma é muito elevado comparativamente
aos benefícios.
A grande limitação desta técnica prende-se no facto de serem necessárias alterações
significativas na rede da operadora de serviços de comunicações móveis. A relação custo
benefício é muito baixa na medida em que a precisão que se consegue alcançar é pouco
superior à de identificação de célula.
Figura 2-9 – Time difference of Arrival [6]
2.3.4 Diferença de Tempo Observado Optimizado
A técnica de diferença de tempo observado optimizado (E-OTD - Enhanced Observed
Time Diference) assume que os dispositivos se encontram equipados com software que irá
localmente computar a sua localização [6]. O dispositivo mede as diferenças do tempo de
chegada (Time of Arrival) dos sinais de pelo menos três base stations sincronizadas e calcula
as respectivas distâncias, conseguindo assim obter a sua posição.
Este método, requer um investimento significativo na rede e requer ainda a instalação de
software específico no dispositivo móvel. A exactidão está dependente da densidade da célula,
do planeamento das células, das interferências e das reflexões multi-percurso [19]. A precisão
deste método não é degradada dentro de edifícios mas a sua performance é baixa em
ambientes rurais onde existe uma baixa densidade de base stations.
Esta técnica apresenta as seguintes limitações:
• Necessidade de software específico no terminal móvel.
• Alterações significativas na rede telefónica móvel actual.
2.3.5 Ângulo de Chegada (AoA)
A técnica de ângulo de Chegada (AoA - Angle of Arrival) envolve a medição do ângulo de
chegada de um sinal de uma base station a um receptor ou vice-versa. Em qualquer um dos
19
casos, uma única medida produz uma linha recta entre a base station e o receptor. A medida
do ângulo de chegada com outra base station produzirá uma segunda linha recta e, a
intersecção das duas linhas, vai fornecer a posição do dispositivo (ver Figura 2-10) [6].
Figura 2-10 - Angle of Arrival [6]
Este método de localização aplica-se melhor em células grandes com antenas elevadas,
reduzindo os problemas de reflexão multi-percurso e bloqueio de sinal que se encontram na
utilização desta técnica em ambientes urbanos onde existem muitos edifícios e outros
obstáculos.
Esta técnica apresenta as seguintes limitações:
• Não aplicável a qualquer tipo de espaço. Em meios urbanos a propagação multi-
percurso limita muito a precisão.
• Necessárias antenas específicas que realizem este tipo de cálculo dado que as
redes móveis actuais não as utilizam.
2.4 Parlay X
O Parlay X trata-se um conjunto de normas de Web Services para telecomunicações
definidos pelo Parlay Group[8], um consórcio não lucrativo cujo objectivo é permitir a criação de
novas aplicações e serviços em telecomunicações, utilizando as capacidades da rede.
Desenvolve assim Interfaces de Programação de Aplicações (APIs – Application Programming
Interfaces) que permitem o desenvolvimento de aplicações que operam em redes de
telecomunicações [8]. Através dos Web Service Parlay X consegue-se uma abstracção do
modo como determinadas tarefas e capacidades são realizadas na rede móvel, permitindo que
estas sejam utilizadas de uma forma simples e rápida no desenvolvimento de aplicações para a
rede móvel.
Na tabela abaixo encontram-se as especificações de Web Services Parlay X v2.1
definidas pelo Parlay Group até à data, bem como uma breve descrição das funcionalidades de
rede que permitem realizar [20] :
20
Tabela 2-2 – Web-Services Parlay X
Third-party call Realização e gestão de chamadas inicializadas por uma
aplicação (third-party call) entre duas ou mais entidades.
Call notification Gestão de chamadas iniciadas por um subscritor de uma
rede através de uma aplicação.
Short messaging Envio e gestão de mensagens SMS.
Multimedia messaging Envio e gestão de conteúdos multimédia como MMS e
E-mail.
Payment Realização de reservas de pagamentos e pagamentos
pré-pagos e pós-pagos.
Account management Suporta a consulta e carregamento de saldo para
utilizadores com tarifários pré-pagos.
Terminal status Permite o acesso e recepção de notificações em relação
ao estado de um ou mais terminais.
Terminal location Permite acesso e recepção de notificações em relação à
localização de um ou mais terminais.
Call candling
Fornece um mecanismo que possibilita que uma
aplicação especifique como é que as chamadas para um
número específico devem ser geridas.
Audio call Permite um fornecimento flexível de mensagens de voz
sem ser necessária a realização de uma chamada.
Multimedia conference Permite a criação de conferências multimédia e a gestão
dos participantes e conteúdos envolvidos.
Address list management
Define duas interfaces que se relacionam entre si: uma
para gerir grupos já definidos e outra para gerir os
membros do grupo.
Presence
Permite registar presença e obter informações de
presença acerca de um ou mais utilizadores. Muito
utilizado para aplicações de Instant Messaging.
Este conjunto de Web Services permite o acesso uniforme a diversas capacidades de rede
de forma simples e sem ser necessário um conhecimento aprofundado de telecomunicações.
Estas capacidades podem ser utilizadas no desenvolvimento de aplicações permitindo que
tanto as operadoras de redes móveis, como outros fornecedores de serviços externos
desenvolvam, com relativa facilidade, novos serviços de telecomunicações. Este aspecto pode
ser bastante vantajoso para as operadoras de redes móveis pois, além do desenvolvimento
das suas próprias aplicações ser bastante mais rápido, a abertura a fornecedores de serviços
externos possibilita que novas ideias, aplicações e serviços sejam fornecidos pela operadora.
Na Figura 2-11 temos um exemplo de como uma aplicação que utiliza Web Services
Parlay X pode ser desenvolvida e se conecta à gateway de Web Services da operadora para
acesso às capacidades da rede.
21
Figura 2-11 – Desenvolvimento de uma aplicação com Web Services Parlay X[8]
Como já foi referido, os Web Services Parlay X possibilitam o acesso simples a diversas
capacidades de uma rede de telecomunicações. No entanto, tendo em consideração o contexto
deste trabalho e os objectivos descritos no primeiro capítulo, será dada relevância apenas às
capacidades relacionadas com os Web-Services de Terminal Location e Short Messaging.
2.4.1 Localização de Terminal
Considerando a breve descrição realizada no capítulo anterior, o Web Service de
Localização de Terminal (Terminal Location) pode providenciar acesso à localização de um ou
mais terminais dos seguintes modos [20]:
• Requisição da localização de um terminal
• Requisição da localização de um grupo de terminais
• Notificação de alterações na localização de um ou mais terminais
• Notificação de um ou mais terminais numa base periódica
É importante referir que, seja qual for o método utilizado para obtenção de localização de
um terminal, esta, é sempre expressa através de valores de latitude, longitude, altitude e
precisão, sendo a altitude o único valor opcional.
A notificação de alterações na localização de um grupo de terminais tem especial
relevância no contexto deste trabalho pois permite que uma aplicação seja notificada quando
um ou mais terminais entram ou saiam de uma determinada área geográfica. Assim, quando
um desses eventos ocorre, uma mensagem de notificação é enviada para a aplicação de forma
assíncrona.
A interface do Web Service utilizada para realizar notificações de localização é a
TerminalLocationNotificationManager que permite a configuração e gestão de notificações de
22
localização [20]. A interface define a operação StartGeographicalNotification que permite que
notificações de alteração de posição sejam enviadas acessíveis às aplicações.
Na tabela abaixo estão os parâmetros que são necessários para se realizar um pedido de
início de notificações geográficas.
Tabela 2-3 – Parâmetros necessários para notificações geográficas numa zona [20]
Parâmetro Tipo Opcional Descrição
Reference common:
SimpleReference Não
Definição do endpoint para notificações
assíncronas.
Addresses xsd: anyURI
[1..unbounded] Não
Endereços ou números de telefone dos
terminais a monitorizar. No caso de serem
números de telefone devem conter o prefixo
“tel:”.
Latitude xsd: float Não Latitude do ponto central da zona
Longitude xsd: float Não Longitude do ponto central da zona
Radius xsd: float Não Raio do círculo com centro no ponto central
da zona em metros.
TrackingAccuracy xsd: float Não Número de metros de erro aceitável ao se
localizar um terminal móvel.
Criteria EnteringLeaving
Criteria Não
Indica se as notificações devem ocorrer
quando um terminal entra ou said a area em
questão.
CheckImmediate xsd: boolean Não Verifica a localização imediatamente após
estabelecer as notificações.
Frequency common:
TimeMetric Não
Frequência máxima de notificações (pode
também ser considerado como o mínimo
entre notificações).
Duration common:
TimeMetric Sim
Quantidade de tempo que as notificações
devem ocorrer. Caso não seja especificado
será utilizado o tempo pré-definido pelo
serviço.
Count xsd: int Sim
Número máximo de notificações. No caso de
este parâmetro não ser definido, não existe
número máximo.
Considerando todos os parâmetros apresentados na Tabela 2-3, é importante esclarecer
que a área de uma zona geográfica é definida por uma latitude, uma longitude e um
determinado raio em metros. Todos os outros parâmetros são referentes a características das
notificações e aos endereços dos terminais a que as notificações devem corresponder.
23
2.4.2 Mensagens Curtas
O Web Service de Mensagens Curtas (Short Messaging) permite que aplicações possam
realizar o envio e recepção de mensagens SMS. O envio de mensagens SMS tem grande
relevância no contexto deste trabalho pois praticamente todos os telefones móveis suportam a
recepção destas mensagens permitindo assim o envio de serviços informacionais,
independentemente da marca ou modelo do terminal.
A interface do Web Service utilizada para realizar o envio de SMS é a SendSMS, que
define diversas operações para enviar mensagens curtas e, opcionalmente, verificar o estado
das mensagens [20]. A interface define assim a operação SendSMS que permite o envio de
mensagens no formato String.
Na tabela abaixo estão os parâmetros que são necessários para se realizar o envio de
mensagens SMS.
Tabela 2-4 – Parâmetros necessários para envio de SMS [20]
Parâmetro Tipo Opcional Descrição
Addresses xsd: anyURI
[1..unbounded] Não Endereços para os quais as SMS serão enviadas.
SenderName xsd: string Sim Se presente, indica o nome da entidade que envia
o SMS. É mostrado na SMS como remetente.
Charging common:
ChargingInformation Sim
Se presente, representa o valor que deve ser
cobrado por SMS enviado.
Message xsd: string Não Texto a ser enviado no SMS.
ReceiptRequest common:
SimpleReference Sim
Define os dados que serão utilizados para se
notificar a aplicação se a mensagem foi entregue
ou se foi impossivel realizar a entrega.
2.5 Conclusão
Neste capítulo foram analisadas as tecnologias que se relacionam com o problema
colocado no primeiro capítulo. A Tabela 2-5 resume as vantagens e limitações de cada uma
das tecnologias analisadas tendo em consideração os objectivos propostos.
24
Tabela 2-5 – Identificação das vantagens das tecnologias analisadas
Bluetooth WiFi Outras
técnicas GPS A-GPS GSM/UMTS
Infra-estrutura
já existente X X X
Acessível em
diversos meios X X X X
Disponibilidad
e da tecnologia X
Globalidade da
tecnologia X X
Precisão X X X
Cobertura do
País X X X
Como se pode observar nas primeiras três colunas, as tecnologias utilizadas para
localização Indoor são bastante limitadas a nível do que podem oferecer no fornecimento de
um serviço Push baseado em localização. A utilização destas tecnologias revela-se útil
exclusivamente em pequenas áreas. Em relação à globalidade das tecnologias Indoor nos
terminais móveis mais comuns, apenas o Bluetooth se encontra com alguma generalidade
disponível, sendo, no entanto, muitas vezes necessária a interacção do utilizador para activar a
tecnologia.
A utilização do GPS tem vindo a ficar cada vez mais popular essencialmente na sua
aplicação a serviços de navegação. No entanto, esta tecnologia, apesar de bastante precisa,
não é acessível em espaços fechados ou até mesmo em cidades com uma grande
concentração de edifícios. Outra desvantagem será o facto de a grande maioria dos terminais
móveis mais comuns não disponibilizar esta tecnologia.
Por último temos o A-GPS e o GSM/UMTS. O A-GPS, através da utilização de várias
tecnologias em simultâneo, consegue obter uma localização muito precisa do terminal móvel.
No entanto, esta tecnologia falha num factor crítico ao fornecimento de serviços Push
baseados em localização pois apenas se encontra disponível em muito poucos dos terminais
móveis mais comuns (alguns smartphone e PDAs).
A utilização da rede telefónica móvel (GSM/UMTS), apesar de não ser muito precisa (na
pior das hipóteses ao nível de célula), satisfaz todos os factores críticos analisados. Trata-se
de uma tecnologia que todos os terminais móveis que realizam comunicações através da rede
móvel utilizam. É assim uma tecnologia que é extremamente acessível e que abrange diversos
tipos de espaços independentemente das suas dimensões ou cobertura. Esta é, como se pode
verificar, a tecnologia mais adequada para fornecimento de serviços baseados em localização.
No entanto, e tendo em consideração a análise realizada a esta tecnologia no capítulo 2.3,
coloca-se as seguinte questões:
25
• Quais as grandes diferenças nas técnicas de localização em GSM/UMTS?
• Todas as técnicas respondem aos requisitos e factores críticos apresentados no
primeiro capítulo?
• Qual a mais adequada para responder aos objectivos apresentados?
A Tabela 2-6 resume as vantagens e limitações de cada uma das técnicas de localização
em GSM/UMTS analisadas.
Tabela 2-6 – Vantagens das técnicas de localização GSM/UMTS
Cell ID Cell ID++ AoA O-TDOA E-OTD
Sem necessidade de alterações muito significativas na infra-estrutura X X
Sem necessidade de aplicações específicas no terminal móvel X X X X
Aplicável em qualquer tipo de meio X X X X
Melhoria significativa na precisão X
Sem sobrecarga na quantidade de dados na rede sem fios X X
Como é possível verificar na tabela apresentada, a técnica Angle of Arrival (AoA) envolve
alterações significativas à rede não trazendo grandes melhorias a nível de precisão na
determinação da localização. De facto, esta técnica aplica-se mais em zonas rurais onde as
células são de raio bastante elevado conseguindo-se uma maior precisão.
Em relação às técnicas Observed Time Difference of Arrival (O-TDOA) e Enhanced
Observed Time Difference (E-OTD) é possível verificar que ambas necessitam de grandes
alterações a nível da infra-estrutura de uma rede móvel e ambas utilizam a rede sem fios para
transmitir informações adicionais que permitam a obter a localização. Deste modo, estas
técnicas não se encontram geralmente disponíveis nas operadoras. No entanto, é importante
de referir que, de todas as técnicas apresentadas apenas a E-OTD apresenta uma melhoria
significativa na precisão da localização.
Por fim, as técnicas de Cell ID e Cell ID++ são as que apresentam notoriamente o maior
número de vantagens. O que diferencia as duas é o facto de, na técnica Cell ID++, se
conseguir obter uma maior precisão, embora a custo de mais alterações na rede da operadora
móvel. Estas duas técnicas conseguem responder a todos os factores críticos analisados para
o fornecimento de serviços Push baseados em localização.
A utilização do Web Service Parlay X de Terminal Location disponibiliza qualquer técnica
de localização GSM/UMTS que seja suportada pela rede telefónica móvel ou pelo terminal
móvel. Tem ainda a vantagem de, se a rede e o terminal suportarem, utilizar as tecnologias de
GPS e A-GPS para determinar a localização. O modo com um ou mais terminais são
localizados é assim transparente à aplicação que requer essa informação, sendo a área de
uma zona definida por uma latitude, uma longitude e um raio. Deste modo, no pior cenário,
26
será apenas utilizada a técnica de Cell ID que serve de base para as restantes técnicas
GSM/UMTS e que, como já foi referido, satisfaz os requisitos e factores críticos da solução
pretendida. O Web Service de Short Messaging pode ser utilizado para complementar o
fornecimento de serviços na medida em que possibilita o envio de mensagens SMS através de
um simples Web Service. Na Tabela 2-7 podemos observar como a utilização dos Web
Services de Terminal Location e Short Messaging permitem responder a todos os factores e
objectivos apresentados no primeiro capítulo.
Tabela 2-7- Vantagens dos Web Services Parlay X
Parlay X Web Services
Globalidade No pior cenário, a técnica de localização utilizada é a localização por Cell ID que é realizada pela operadora e, logo, suportada por qualquer telemóvel ligado à rede GSM/UMTS.
Disponibilidade Sendo a técnica de localização base a localização através da rede GSM/UMTS, desde que o telemóvel se encontre ligado à rede, este é passível de ser localizado em qualquer altura.
Acessibilidade
As operadoras têm cobertura de rede sobre praticamente todo o território nacional, tanto em espaços fechados, como espaços ao ar livre. Desde que o terminal possua uma ligação à rede móvel ele é passível de ser localizado.
A utilização deste Web Service Parlay X possibilita a criação de aplicações baseadas em
localização escaláveis na medida em que podem acompanhar o desenvolvimento das técnicas
de localização da operadora, sem ser necessária a realização de alterações na aplicação. Este
Web Service permite ainda uma simplificação no desenvolvimento de aplicações na medida em
que o programador pode-se focar na lógica que pretende para a aplicação sem se ter de
preocupar com detalhes técnicos sobre o funcionamento da rede GSM/UMTS.
27
3 Arquitectura
Neste capítulo é apresentada a arquitectura definida para implementação da solução
proposta nos objectivos deste trabalho. Os requisitos identificados no capítulo 1.2 foram
tomados em consideração de forma a provar-se a hipótese formulada no mesmo.
É importante referir que o fornecimento de serviços Push baseados em localização
poderia ser fornecido tanto sobre redes GSM como UMTS. No entanto, sendo o UMTS uma
evolução do GSM, apresenta-se como a tecnologia com mais futuro na área das comunicações
móveis. Assim sendo, e considerando que as suas arquitecturas são ligeiramente diferentes,
para efeitos deste trabalho, utilizou-se a arquitectura UMTS como suporte para fornecimento
dos serviços Push.
De forma a desenhar-se uma arquitectura que forneça o tipo de serviços pretendido,
utilizando a rede UMTS para distribuição, foram colocadas diversas questões consideradas
relevantes para o cumprimento dos objectivos:
• Onde vão ser os dados armazenados?
• Qual a estrutura de dados necessária?
• Como se vai comunicar com a rede UMTS?
• Como se sabe a localização do cliente?
• Como se irão identificar que serviços se deve fornecer ao cliente?
• Como serão disponibilizados os serviços?
• Como é que o utilizador altera as suas preferências e interesses?
Após colocadas várias alternativas, considerou-se que a arquitectura representada na
Figura 3-1 cumpre os requisitos propostos.
28
Figura 3-1 - Representação Modular da Arquitectura
3.1 Rede UMTS
A rede UMTS é a rede sobre a qual o fornecimento dos serviços Push se vai realizar. Não
se trata assim de um componente da arquitectura a desenvolver mas sim a rede que suporta o
desenvolvimento da arquitectura pretendida estando por isso representada a cinzento na
Figura 3-1. Assim sendo, e de forma a se conseguir uma melhor compreensão do
funcionamento da solução a desenvolver, será dada relevância apenas aos componentes da
rede UMTS que interagem directamente com componentes da arquitectura proposta.
Como foi referido no trabalho relacionado, a rede UMTS trata-se de uma rede celular e
encontra-se dividida em duas partes distintas: A Core Network (CN) e a UMTS Terrestrial Radio
Access Network. É a esta rede que os terminais móveis vão estar ligados possibilitando assim
a distribuição dos serviços com base no local onde se encontram.
3.1.1 UMTS Terrestrial Radio Access Network (UTRAN)
A UTRAN corresponde à rede de acesso rádio de uma rede UMTS. É através da UTRAN
que a conectividade entre o terminal móvel e a Core Network é realizada. Esta rede é
composta por diversos componentes que têm como objectivo as seguintes funcionalidades
[21]:
• Controlo das células da rede e dos terminais existentes em cada célula
29
• Transmitir e receber sinais rádio dos terminais
• Realizar a conectividade e controlo entre os terminais móveis e a Core Network
Os componentes da UTRAN não se encontram especificados na arquitectura apresentada
na medida em que esta é apenas utilizada para fazer chegar ao terminal móvel, via rádio, as
informações vindas da Core Network e vice-versa.
3.1.2 UMTS Core Network
É na Core Network que é realizado o transporte de fluxos de dados necessários ao
funcionamento de uma rede UMTS. Realizam-se assim as funções de: Handover entre células,
comunicação com outras redes (como a rede de telefone fixo) e gestão de localização e
serviços a fornecer ao utilizador [18].
Esta rede é constituída pelos seguintes componentes:
• Parlay X Web Services Gateway: trata-se de um servidor que implementa Web
Services Parlay X [22]. Estes Web Services podem ser invocados por aplicações
externas à rede para aceder com segurança a funcionalidades da rede UMTS,
entre as quais a obtenção de localização e o envio de SMS.
• Gateway Mobile Location Center (GMLC): fornece uma interface que permite a
realização de pedidos relacionados com localização como a localização actual de
um determinado utilizador[23]. Permite ainda fornecer notificações de localização
caso um, ou mais utilizadores entrem ou saiam de uma determinada zona [24].
• Home Subscriber Server (HSS): contém informações acerca dos subscritores da
operadora tais como as suas identidades, a localização e os serviços em que se
encontram registados. Contém ainda informações relacionadas com a segurança
dos subscritores que permitem a sua autenticação [21].
• Serving GPRS Support Node (SGSN): o SGSN funciona como router para
transferência de dados, mantendo uma cópia local de informações acerca dos
terminais móveis registados numa área. O SGSN gere também todas as
comunicações de sinalização entre a rede e os terminais móveis registados nessa
área [21].
3.2 Servidor de Serviços Push
O servidor de serviços encontra-se dividido em três componentes distintos sendo estes a
Componente de Dados, a Componente Lógica e a Componente de Apresentação. A
Componente de Comunicação apresentada na Figura 3-1 encontra-se, na prática, também
inserida na Componente Lógica. No entanto, é apresentada em separado como forma de
diferenciar invocações distintas a diferentes Web Services implementados na Parlay X Web
Services Gateway.
30
3.2.1 Componente de Dados
Esta componente contém a base de dados Service BD necessária ao funcionamento do
servidor de serviços Push. A Service BD contém assim todos os dados relativos ao cliente,
zonas e serviços. Esta base de dados armazena ainda um histórico de serviços fornecidos aos
utilizadores do serviço permitindo que estes não recebam informações repetidas nem um
excesso de serviços por dia. O modelo de dados da base de dados Service BD encontra-se em
Anexo.
Existem algumas particularidades do modelo de dados que são importantes referir:
• Os clientes, à semelhança do que acontece na rede UMTS, são identificados pelo
seu MS-ISDN (Mobile Station Integrated Services Digital Number) que representa
o seu número de telefone.
• Os clientes têm um número de serviços máximo que podem receber por dia.
• A área de uma zona é definida por um par de coordenadas geográficas e um raio
de abrangência.
• Uma zona é ainda definida por todos os restantes parâmetros, definidos no Web
Service Parlay X de localização de terminal necessários ao registo de zonas, ver
Capítulo 2.4.1.
• Um serviço pode estar associado a várias zonas.
• Um serviço pode estar associado a várias subcategorias.
• Uma subcategoria pode estar associada a apenas uma categoria.
• Uma categoria pode estar associada a várias subcategorias.
• Um interesse é uma associação de um MS-ISDN de um cliente com uma
subcategoria, podendo existir diversos interesses por utilizador.
• Um serviço é composto, para além do identificador por um título e um conteúdo.
3.2.2 Componente Lógica
É nesta componente que se realiza toda a lógica do servidor de serviços Push. O objectivo
global desta componente é, através da utilização de Web Services Parlay X, registar diferentes
zonas e clientes na Parlay X Web Services Gateway para possibilitar a recepção de
notificações de localização caso um dos clientes entre numa dessas zonas. Estas notificações
são então utilizadas para enviar um serviço que esteja relacionado tanto com a zona onde o
utilizador se encontra como com os seus interesses. A Componente Lógica encontra-se
dividida em três componentes distintas: Gestor de Eventos, Gestor de Interesses e Gestor de
Conteúdos.
O Gestor de Eventos de tem como objectivo a realização das seguintes tarefas:
• Registar diariamente todas as zonas e clientes na Parlay X Web Services
Gateway.
31
• Escutar notificações de localização vindas da Parlay X Web Services Gateway
caso um utilizador entre numa das zonas registadas.
• Na recepção de uma notificação de localização, identificar qual a zona e o cliente
à qual a notificação corresponde.
• Enviar para o Gestor de Interesses o MS-ISDN e a identificação da zona
correspondente à notificação recebida
O Gestor de Interesses tem como objectivo a realização das seguintes tarefas:
• Verificar se o cliente é apto à recepção de um novo serviço, testando se este
ainda não recebeu o limite de serviços diário.
• Verificar se na zona onde o utilizador se encontra existe algum serviço que este
ainda não tenha recebido e que esteja dentro dos seus interesses.
• Caso exista um serviço que se adeqúe ao utilizador, o Gestor de Interesses vai
enviar para o Gestor de Conteúdos a identificação do serviço a fornecer ao
utilizador.
Finalmente, o Gestor de Conteúdos tem como objectivo a realização das seguintes
tarefas:
• Seleccionar o conteúdo a enviar segundo a identificação de serviço recebida.
• Enviar um SMS através da Parlay X Web Services Gateway.
• Escutar o estado da SMS enviada.
• Actualizar do histórico.
3.2.3 Componente de Apresentação
A Componente de Apresentação representa a interface gráfica que permite a configuração
do fornecimento de serviços Push tanto por parte dos utilizadores de serviço como por parte
dos administradores. Esta componente encontra-se assim dividida em duas partes:
• Aplicação Web Cliente: permite que o cliente altere as suas preferências em
relação à recepção de serviços. O cliente pode assim gerir não só os seus
interesses mas também o número de serviços diários que recebe. Esta aplicação
permite ainda o registo ou cancelamento de serviço.
• Aplicação Web Administrador: permite a gestão de zonas, serviços e categorias
de serviços por parte do administrador do Servidor de Serviços. Através desta
aplicação um administrador do servidor de serviços pode assim:
o Consultar, adicionar e remover categorias e subcategorias.
o Consultar, adicionar e remover zonas
o Consultar, adicionar, remover e editar serviços
o Associar serviços a subcategorias e a zonas
32
3.3 Diagramas de Interacção
Os diagramas de interacção apresentados em seguida pretendem demonstrar as
interacções existentes entre diversos actores em situações consideradas relevantes no
funcionamento do sistema pretendido.
Figura 3-2 - Diagrama de Interacção para o Registo de Zonas e Clientes
O diagrama acima ilustra as interacções existentes no registo de zonas e clientes na rede
UMTS para recepção de notificações de localização. Explicita assim como é inicialmente
realizado o registo e como é gerida a inserção de novas zonas e clientes. Trata-se assim da
fase inicial para o fornecimento de serviços Push. Como a legenda indica, o fluxo laranja
descreve a comunicação realizada entre o Gestor de Eventos a base de dados e os fluxos azul
e castanho a comunicação realizada entre o Gestor de Eventos e a rede UMTS.
33
Figura 3-3 - Diagrama de Interacção para Fornecimento de Serviço Push
A figura acima ilustra as interacções que ocorrem desde a entrada de um utilizador numa
zona registada até à recepção de um serviço via SMS relacionado com os seus interesses e a
zona em que se encontra. Representa assim como é que a solução suporta o fornecimento dos
serviços Push direccionados. As três partes que compõem a Componente Lógica encontram-se
representadas separadamente de forma a melhor explicitar as suas interacções e as tarefas
que cada uma delas realiza no fornecimento de serviços Push.
34
Figura 3-4 - Diagrama de Interacção para Alteração de Interesses
O terceiro e último diagrama apresentado na figura acima explicita como o utilizador altera
os seus interesses para a recepção de serviços Push direccionados. O fluxo laranja descreve
como é realizado o login na Aplicação Web e, deste modo, identificado e autenticado o
utilizador. O fluxo azul descreve como é apresentada ao utilizador a interface de gestão.
Finalmente, o fluxo castanho descreve como são realizadas as alterações de interesses do
utilizador.
35
4 Implementação
Neste capítulo pretende-se descrever como foi realizada a implementação de uma solução
que satisfaz os requisitos definidos nos capítulos anteriores. Será dada maior ênfase à
Componente Lógica e ao modo como a comunicação se realiza com a rede UMTS por estas
serem as componentes essenciais ao que se pretende demonstrar. A componente de
apresentação irá ser referida como um complemento à componente lógica na medida em que
permite uma melhor compreensão e gestão da mesma.
Dado a complexidade da solução a desenvolver, a implementação foi faseada. Na Figura
4-1 estão representadas as diferentes fases realizadas para o desenvolvimento da solução
pretendida.
Figura 4-1 - Fases de Implementação
A primeira fase consistiu na modelação e implementação da base de dados que suporta a
solução pretendida. Nesta fase, foram também realizados testes unitários à base de dados
sendo realizadas diversas consultas SQL. Esta fase corresponde assim à implementação da
Componente de Dados da solução.
36
A implementação da Componente Lógica foi dividida em três fases como se pode verificar
na Figura 4-1. A segunda fase de implementação da solução, primeira da componente lógica,
consistiu na implementação do Gestor de Eventos que permite gerir as notificações de
localização recebidas da rede UMTS. Nesta fase foram realizados testes unitários bem como
testes de integração desta componente com a base de dados.
A terceira fase, segunda da componente lógica, consistiu na implementação do Gestor de
Interesses que, recebendo uma identificação do utilizador determina que serviço deverá ser
enviado de acordo com os interesses do utilizador. As funcionalidades desta componente
foram validadas através de testes unitários e de testes de integração com a base de dados e o
Gestor de Eventos.
A quarta fase de implementação, e última da Componente Lógica, consistiu no
desenvolvimento do Gestor de Conteúdos que tem como objectivo ir buscar o conteúdo
relacionado com o serviço seleccionado e enviar esse conteúdo ao utilizador. Foram realizados
nesta fase tanto testes unitários como de integração de forma a garantir que cumpria as
funcionalidades pretendidas.
A componente de apresentação foi dividida em duas fases que correspondem ao
desenvolvimento da Aplicação Web para o cliente, onde este pode alterar as suas preferências
e interesses e a Aplicação Web para o administrador, onde é possível alterar as configurações
do serviço. Estas duas fases são, respectivamente, quinta e sexta fase de implementação da
solução. Em ambas as fases foram realizados testes unitários e de integração de forma a
garantir o bom funcionamento das aplicações e as respectivas alterações na base de dados.
4.1 Componente de Dados
A Componente de dados contém a base de dados necessária ao funcionamento do
servidor de serviços Push. Todos os dados referentes a zonas, utilizadores e serviços são aqui
armazenados bem como um histórico dos serviços fornecidos.
Neste capítulo serão primeiramente introduzidas as ferramentas utilizadas para o
desenvolvimento da Componente de Dados e, posteriormente, será descrito como foi esta
componente implementada.
4.1.1 Ferramentas Utilizadas
A Base de Dados foi implementada em MySQL 5.1.31 que é um sistema que permite fazer
a gestão de bases de dados e utiliza a linguagem SQL (Structured Query Language) como
interface.
De forma a facilitar a gestão, consulta e actualização da base de dados foi utilizado o
MySQL Administrator e o MySQL Query Browser. O MySQL Administrator, tal como o nome
indica, foi criado para gerir um servidor MySQL. Por sua vez, o MySQL Query Browser trata-se
de uma ferramenta gráfica, fornecida pela MySQLAB, que permite criar, executar e optimizar
37
solicitações SQL num ambiente gráfico [25]. Esta aplicação permite ainda a edição dos dados
de forma gráfica sendo mais intuitivo para quem está a utilizar a base de dados [25].
4.1.2 Base de Dados
A Base de Dados correspondente à Componente de Dados foi implementada de acordo
com o modelo relacional apresentado no capítulo anterior. Este modelo foi estudado e
desenvolvido tendo como base os requisitos da solução pretendida. A primeira solução obtida
não foi uma solução definitiva e ao longo de todo o projecto foi necessário realizar algumas
alterações de forma a satisfazer os requisitos da solução desenvolvida.
Após criação e respectivas actualizações à Base de Dados service_db, foram criados
alguns registos e efectuadas diversas consultas SQL para assim validar o modelo de dados.
Os dados de acesso à base de dados encontram-se no ficheiro de configuração
ss.properties. Estes dados vão permitir que as aplicações necessárias à solução acedam à
base de dados e obtenham assim as informações que necessitam.
4.2 Componente Lógica
A Componente Lógica é a base de toda a solução sendo através desta que se torna
possível o fornecimento de um serviço que satisfaz os requisitos definidos no capítulo inicial. A
Componente Lógica é composta pelas classes GestorEventos, GestorInteresses e
GestorConteudos que correspondem às três componentes pertencentes à Componente Lógica.
Para além destas três principais classes, existe ainda a classe Propriedades que é responsável
pela leitura do ficheiro de configuração ss.properties que contém informações globais
necessárias à realização de notificações e à ligação à base de dados. Por último, a classe
ServidorServicos é responsável por gerir todas as outras classes e definir a ordem com que
vão ser executadas.
Neste capítulo serão primeiramente introduzidas as ferramentas utilizadas para o
desenvolvimento da Componente Lógia e, posteriormente, serão descritos os detalhes de
implementação desta componente.
4.2.1 Ferramentas Utilizadas
Para implementação de toda esta componente foi utilizada a linguagem de programação
Java. Foi utilizado o eclipse, um IDE (Integrated Development Environment) Open Source [26]
e, a plataforma Java utilizada, foi o J2EE (Java Enterprise Edition).
Para a realização da Componente Lógica foi essencial o recurso aos Web Services Parlay
X de Terminal Location e Short Messaging (ver Capítulo 2.4). No entanto, a sua utilização
directa é complexa sendo necessário um conhecimento detalhado tanto dos Web Services
Parlay X como dos pedidos SOAP (Simple Object Access Protocol) utilizados para trocas de
informação em questões de segurança e de notificações de localização e de estado de SMS.
Outro problema prende-se no facto de ser necessária uma rede UMTS com suporte à
38
localização de terminais e uma Parlay X Web Services Gateway para ser viável a realização de
testes à aplicação.
Após um período de investigação foi encontrado o SDK (Software Development Kit)
Telecom Web Services da Ericsson que permite o desenvolvimento e teste de aplicações que
utilizam os Web Services Parlay X.
O Telecom Web Services SDK consiste nos seguintes componentes relevantes no
desenvolvimento da solução pretendida:
• Biblioteca de componentes Java para Web Services Parlay X.
• Emulador de funcionalidades de rede de telecomunicações para teste de
aplicações
Com a utilização dos componentes Java obtém-se uma abstracção dos Web Services
Parlay X tornando possível que, aplicações que utilizam esses Web Services, sejam
desenvolvidas em Java simples [27]. Na Figura 4-2 encontra-se uma representação de como
os componentes Java podem ser utilizados no desenvolvimento de aplicações de
telecomunicações.
Figura 4-2 – Utilização do Telecom Web Services SDK [27]
Com as componentes Java do SDK consegue-se assim desenvolver aplicações que
utilizam as funcionalidades de rede definidas pelo Parlay X recorrendo apenas a Java simples.
É ainda necessário testar a aplicação ao longo do seu desenvolvimento. A utilização de
uma operadora real de telemóveis para realização de testes não é uma solução viável, não só
porque são muito sigilosas em relação a todo o funcionamento da rede e serviços, mas
também porque nenhuma operadora em Portugal suporta, ainda, o Parlay X.
O Parlay X Network Emulator incluído no SDK implementa as capacidades de uma Parlay
X Services Gateway, simulando as funcionalidades de rede que esta disponibiliza. Torna-se
assim possível a realização de testes sem se recorrer a nenhuma operadora [27]. O emulador
39
é baseado na tecnologia Java EE (Enterprise Edition) e corre no Apache Tomcat 6 [28] sendo
simples a sua utilização. A comunicação entre a aplicação e o emulador é feita por IP e as
aplicações de telecomunicações podem ser desenvolvidas em qualquer linguagem de
programação que suporte a utilização de Web Services.
Através da utilização deste emulador torna-se possível realizar:
• Teste de aplicações.
• Demonstração de aplicações.
• Execuções locais de aplicações.
• Suporte aos Parlay X Web Services v2.1 e respectivas funcionalidades de rede.
• Emulação de terminais móveis permitindo a sua alteração de estado e o envio e
recepção de SMS e MMS.
• Registo de tráfego causado pelos Web Services.
Na Figura 4-3 é mostrada, utilizando o Apache Tomcat 6, a página inicial do Telecom Web
Services Network Emulator.
Figura 4-3 – Página inicial do Telecom Web Services Network Emulator
40
4.2.2 Gestor de Eventos
O Gestor de Eventos, como já foi referido no Capitulo 3, tem como objectivo registar os
utilizadores e zonas junto da Parlay X Gateway, e ainda realizar a gestão das notificações de
localização recebidas que correspondem à entrada de um utilizador numa das zonas
registadas.
4.2.2.1 Estudo dos Requisitos
Antes do início do desenvolvimento desta componente foi necessário identificar as tarefas
que o Gestor de Eventos deve realizar. Concluiu-se que o Gestor de Eventos deve:
• Obter dados da base de dados de todos os utilizadores aos quais se pretende
fornecer o serviço.
• Obter dados da base de dados acerca das zonas onde se pretende fornecer o
serviço.
• Utilizar dados obtidos para realizar o registo de zonas e clientes junto da Parlay X
Gateway.
• Gerir a recepção assíncrona de notificações de localização.
• Gerir a recepção assíncrona de notificações de término de notificações
geográficas.
4.2.2.2 Obtenção de Utilizadores e Zonas
Antes de se poder realizar o registo de zonas e clientes é necessário obter as informações
das mesmas na base de dados. Para isso é restabelecida uma ligação à base de dados
utilizando o JDBC (Java Database Connectivity) que é uma API em Java que permite o envio
de instruções SQL para uma base de dados relacional. Através desta API é possível obter
todas as informações de utilizadores e zonas necessárias ao registo das mesmas junto da
Parlay X Gateway.
Foram realizados testes unitários às consultas realizadas à base de dados pela aplicação
de forma a verificar que as informações obtidas eram as correctas e necessárias para o
funcionamento previsto do Gestor de Eventos.
4.2.2.3 Registo de Zonas e Utilizadores
De forma a possibilitar a recepção de notificações de localização é necessário efectuar o
registo, junto da Parlay X Gateway (ou neste caso do emulador), das zonas onde se pretende
fornecer o serviço e dos clientes que pretendem a recepção do serviço. Este registo é realizado
através do Web Service Parlay X de Terminal Location descrito no Capítulo 2.4.1. Para se
recorrer a este Web Service é utilizada a componente Java StartGeographicalNotificationBean
definida pelo Telecom Web Services SDK. Esta componente Java consiste num número de
parâmetros de sistema e de utilizador. Os parâmetros de sistema contêm informação que pode
ser utilizada para o envio de múltiplas notificações de localização de terminal. Em contraste, os
41
parâmetros de utilizador são específicos para cada registo de zona e respectivos clientes e
correspondem aos parâmetros definidos pela operação de StartGeographicalNotification
definida pelo Web Service Parlay X de Terminal Location (ver Capítulo 2.4.1).
A Tabela 4-1 apresenta os parâmetros de sistema a definir.
Tabela 4-1 – Parâmetros de sistema para StartGeographicalNotificationBean
Parâmetro Descrição
parlayxGatewayUrl Endereço para o Web Service Parlay X de Terminal Location.
xwssInputStream Ficheiro de configuração de segurança XWSS (XML Web Services Security), ou
null para desactivar segurança.
callbackUrl Endereço para recepção de notificações (Callbacks).
wsdlLocation Localização do WSDL (Web Services Definition Language).
Todas as informações necessárias aos parâmetros de sistema encontram-se no ficheiro
de configuração ss.properties e são lidas previamente pela classe Propriedades.
Ao contrário dos parâmetros de sistema, os parâmetros de utilizador são definidos
utilizando funções set antes de se enviar o pedido de inicio de notificações geográficas. Na
tabela representada em baixo encontram-se os parâmetros de utilizador a definir.
Tabela 4-2 – Parâmetros de utilizador para StartGeographicalNotificationBean
Parâmetro Descrição
notificationAddresses Lista de números de telemóvel dos quais se quer receber notificações com o
prefixo “tel:” pois pretende-se que os endereços sejam números de telefone.
latitude Latitude do centro da zona onde vão ocorrer as notificações.
longitude Longitude do centro da zona onde vão ocorrer as notificações.
radius Raio em metros, da zona onde vão ocorrer as notificações.
trackingAccuracy Número de metros de erro aceitável ao se localizar um terminal móvel.
criteria
Define se a notificação deve ser recebida quando um terminal entra ou sai de
uma determinada zona (Entering ou Leaving). Não é possível definir, no mesmo
registo os dois critérios.
checkImmediatly Define se localização dos utilizadores deve ser verificada imediatamente após
estabelecer as notificações.
callbackCorrelator
Identificador único por cada registo de zona e respectivos utilizadores. É através
deste identificador que é possível saber a que registo pertence uma determinada
notificação recebida.
duration Valor que define durante quanto tempo devem ocorrer as notificações
frequency Valor que define com que frequência se deve verificar alteração de estado dos
utilizadores e o envio de notificações.
count Define o número máximo de notificações.
42
Estes valores são definidos para cada registo de zona e respectivos utilizadores. Todos os
parâmetros de utilizador, à excepção dos notificationAddresses e do callbackCorrelator,
encontram-se armazenados na base de dados na tabela zona.
Os notificationAdresses são os mesmos para todas as zonas e correspondem a uma lista
contendo o número de telemóvel de todos os utilizadores registados para recepção do serviço.
Assim, todos os utilizadores são registados em todas as zonas permitindo a obtenção de
notificações de localização sempre que qualquer utilizador entre numa zona de interesse.
O callbackCorrelator é gerado aleatoriamente em tempo de execução. Este valor é obtido
gerando um Int aleatório de entre 232 possíveis Int sendo posteriormente concatenado com o
tempo actual em milissegundos e passado para o formato String.
Alguns dos parâmetros de utilizador, apesar de serem definidos para cada registo de
zona, são comuns a todas as zonas essencialmente devido à lógica definida para a solução:
• criteria: de forma a prever o fornecimento de serviços diferentes do especificado
(ver Capítulo 6.1 sobre Trabalho Futuro) todas as zonas são registadas duas
vezes, uma com este parâmetro a Entering e outra a Leaving. Desta forma, é
possível saber quando um utilizador entra e sai de uma zona.
• checkImmediatly: este parâmetro é do tipo boolean e é definido a true. Deste
modo, quando as notificações são iniciadas, se algum utilizador se encontrar
numa das zonas registadas, é recebida logo uma notificação localização.
• duration: este parâmetro é do tipo TimeMetric sendo possível definir a unidade e
valor deste parâmetro. Assim sendo, a unidade definida é a hora e o valor é 24,
tendo as notificações a duração de um dia. Este valor foi estipulado devido à
incapacidade de adicionar novos utilizadores aos registos já realizados. Seria
necessário criar novos registos de zona por cada novo utilizador, o que a longo
prazo, se poderia tornar insuportável. De forma a evitar este problema, foi
estipulado que os registos têm validade de vinte e quatro horas. Assim, no final de
cada dia, as zonas e respectivos utilizadores são desregistados, e um novo registo
é efectuado registando todos os clientes e zonas.
• frequency: este parâmetro é do tipo TimeMetric sendo possível definir a unidade e
valor deste parâmetro. Assim sendo, a unidade definida é o segundo e o valor é 1,
permitindo a recepção de notificações a cada segundo. Desta forma, as
notificações são recebidas em tempo útil para envio do serviço.
• count: Este parâmetro é do tipo Int e é definido a null para não haver qualquer
limite no número das notificações recebidas.
Finalmente, os parâmetros latitude, longitude, radius e trackingAccuracy são específicos
da cada uma das zonas a registar definindo a área da zona e a precisão admitida em metros.
Existem zonas de diferentes dimensões e onde a precisão tem mais ou menos importância
fazendo com que os valores destes parâmetros variem de zona para zona.
Concluindo, após definidos os parâmetros de sistema, as zonas são registadas uma a
uma de acordo com as informações específicas obtidas da base de dados. É criada uma lista
43
com os números de telefone de todos os utilizadores, sendo também utilizada, na íntegra, no
registo de todas as zonas. Os registos têm validade de vinte e quatro horas sendo necessário,
no fim desse período, adquirir os dados actuais relativos a zonas e utilizadores da base de
dados e realizar novos registos. Depois de realizados os registos de zonas e respectivos
clientes o Gestor de Eventos aguarda a recepção assíncrona de notificações.
O registo de zonas e utilizadores na Parlay X Gateway foi testado utilizando o emulador
que permite a verificação dos registos efectuados (ver Figura 4-4).
Figura 4-4 – Chamada à operação StartGeographicalNotification
Na figura acima está representado um registo realizado com sucesso de uma zona apenas
e é possível visualizar todos os parâmetros de utilizador e sistema que foram especificados
pelo Gestor de Eventos. Ao se registar as zonas e utilizadores com sucesso, foi testada a
integração da obtenção dos dados à base de dados com o registo desses dados juntos da
gateway.
4.2.2.4 Recepção de Notificações de Entrada
Caso um utilizador entre numa das zonas onde se encontra registado, a Parlay X gateway
(ou emulador) vai enviar uma notificação à entidade que registou as zonas e utilizadores, que
neste caso é o Gestor de Eventos. Ao receber a notificação, o Gestor de Eventos tem acesso a
algumas informações relativas à notificação (ver Tabela 4-3).
44
Tabela 4-3 – Informações incluídas numa notificação geográfica
Elemento Descrição
Correlator Identificador do registo de zona ao qual a notificação geográfica pertence.
Criteria Identifica se a notificação foi causada devido à entrada ou saída de um utilizador numa
determinada zona.
Address Endereço do terminal ao qual a notificação geográfica corresponde.
Timestamp Timestamp da ocorrência da notificação.
Latitude Latitude da posição do terminal quando ocorreu a notificação.
Longitude Longitude da posição do terminal quando ocorreu a notificação.
Altitude Se aplicável, altitude da posição do terminal quando ocorreu a notificação.
Accuracy Exactidão, em metros, na determinação da localização do utilizador.
ReportStatus Indica se a informação relativa ao terminal foi conseguida ou se houve erro.
ErrorInformation Caso o ReportStatus tenha devolvido erro, indica qual a razão para a ocorrência do
erro.
Com estes elementos, o Gestor de Eventos consegue, em primeiro lugar, identificar se a
notificação é causada devido à entrada de um utilizador numa zona. Se for o caso, é
necessário identificar não só o utilizador à qual a notificação pertence mas também a zona
onde a notificação ocorreu.
Para obtenção da identificação do utilizador, basta consultar o elemento Address na
notificação recebida para obter o seu MS-ISDN ou número de telefone. No entanto, não existe
nenhuma informação que identifique explicitamente a zona onde a notificação ocorreu. Como
se pode observar na tabela acima, a única informação de localização existente, é relativa à
posição do utilizador, o que só por si não identifica a zona onde se encontra. De forma a saber
em que zona o utilizador se encontra é necessário realizar uma consulta à base de dados para
obtenção dos dados das zonas e, posteriormente, realizar os seguintes cálculos para cada uma
das zonas:
• Saber qual a distância, em metros, entre o centro da zona e a localização do
utilizador. Para cálculo desta distância, foi utilizada a fórmula de Haversine que
determina a distância entre dois pares de coordenadas.
• Verificar se essa distância está dentro do raio da zona. Se for o caso, significa que
o utilizador se encontra na zona em questão.
Ao se identificar o utilizador e a zona às quais a notificação geográfica recebida
corresponde, é feita uma actualização na base de dados na tabela cliente_zona que vai
identificar que o utilizador se encontra na zona em questão. Para além desta actualização, o
Gestor de Interesses é chamado e os identificadores de cliente e de zona são enviados como
parâmetros.
A recepção de notificações de entrada foi testada utilizando o emulador que permite a
simulação de alteração de posição de terminais e, caso um terminal entre numa zona
registada, o emulador envia a notificação.
45
4.2.2.5 Recepção de Notificações de Saída
Caso um cliente saia de uma zona registada, a Parlay X Gateway envia ao Gestor de
Eventos uma notificação de saída, ou seja, o parâmetro criteria da notificação é LEAVING ao
invés de ENTERING. O Gestor de eventos, ao receber a notificação, vai utilizá-la de forma a
identificar o utilizador ao qual a notificação corresponde. Ao conseguir o seu identificador (MS-
ISDN), o Gestor de Eventos vai realizar uma actualização à base de dados e retirar a entrada
correspondente ao utilizador na tabela cliente_zona. Com a utilização de notificações de
entrada e saída é possível saber, a qualquer altura, quais os utilizadores que se encontram em
zonas registadas.
A recepção de notificações de saída foi testada utilizando o emulador que permite a
simulação de alteração de posição de terminais móveis e, caso um terminal esteja inicialmente
numa zona registada e depois saia, o emulador envia uma notificação de saída.
4.2.2.6 Recepção de Notificações de Término
Vinte e quatro horas após o registo de cada uma das zonas é enviado pela ParlayX
Gateway uma notificação de término (NotificationEnd). Como todas as zonas são registadas na
mesma altura será recebida na mesma altura uma notificação de término por cada zona
registada.
O Gestor de Eventos aguarda a recepção de todas as notificações de término (uma por
zona registada) e realiza um novo registo de toas as zonas e clientes permitindo que novos
clientes iniciem a recepção do serviço e que clientes que entretanto se tenham desregistado,
não recebam mais o serviço.
Concluindo, de vinte e quatro horas em vinte e quatro horas, a Gateway envia uma
notificação de término por cada zona registada. Ao receber todas as notificações, o Gestor de
Eventos volta a realizar a obtenção e registo de todas as zonas e clientes, dando continuidade
ao serviço.
A recepção de notificações de término foi testada alterando o parâmetro duration, no
registo de zonas e clientes para um minuto. Assim, ao fim de um minuto, foi possível observar o
desregisto e novo registo de todas as zonas e clientes.
4.2.3 Gestor de Interesses
O Gestor de Interesses, como já foi referido no Capítulo 3, tem como objectivo definir qual
o melhor serviço a enviar ao utilizador, utilizando o seu identificador e o identificador da zona
onde se encontra.
4.2.3.1 Estudo dos Requisitos
Antes do início do desenvolvimento desta componente foi necessário identificar as tarefas
que o Gestor de Interesses deve realizar. Concluiu-se que o Gestor de Interesses deve:
• Verificar se o cliente é apto à recepção do serviço.
• Verificar que serviços são do interesse do utilizador.
46
• Verificar que serviços estão disponíveis na zona onde o cliente se encontra.
• Verificar que serviços é que o cliente ainda não recebeu na última semana.
• Seleccionar um serviço a enviar ao cliente considerando as verificações realizadas
acima.
À excepção da verificação de aptidão do cliente à recepção do serviço, todas as restantes
verificações, relativas à identificação do serviço a enviar, são realizadas através de uma única
consulta à base de dados. Foi decidido realizar uma só consulta mais complexa ao invés de
múltiplas consultas simples devido ao facto de, com uma única consulta, existir apenas uma
ligação à base de dados tornando a aplicação mais eficiente. Apesar de ser uma única
consulta, esta foi separada neste capítulo e as diversas partes que a compõem são descritas
separadamente de forma a facilitar a sua exposição.
4.2.3.2 Verificação de Aptidão de Cliente
Um cliente tem um número máximo de serviços que pode receber por dia. Este valor
encontra-se na tabela cliente da base de dados service_db e é específico para cada utilizador.
Antes de se identificar um serviço para se enviar ao utilizador, é necessário verificar se o
cliente ainda não recebeu o número máximo de serviços estipulado.
Utilizando o identificador do utilizador (MS-ISDN) enviado pelo Gestor de Eventos, o
Gestor de Interesses realiza uma consulta à base de dados, comparando o valor do número
máximo de serviços definido para o utilizador e o número de serviços que o utilizador já
recebeu.
O número máximo de serviços, como já foi referido, é obtido realizando uma consulta à
tabela cliente. Para o Gestor de Interesses determinar se o utilizador já alcançou esse valor, é
realizada outra consulta à tabela histórico onde é contabilizado o número de serviços que o
utilizador já recebeu no dia corrente. Os dois valores são comparados e uma de duas situações
pode ocorrer:
• O utilizador já recebeu o seu limite diário de serviços, o processo de identificação
de serviço termina e o cliente não recebe nenhum serviço.
• O utilizador ainda não recebeu o seu limite diário e será verificado qual o serviço
que melhor se adequa a esse utilizador.
A verificação de aptidão foi testada alterando os valores correspondentes ao limite de
serviços e histórico do cliente na base de dados e realizando tentativas de entrega de serviços.
4.2.3.3 Verificação de Serviços do Interesse do Utilizador
A consulta realizada para determinar o serviço a enviar ao utilizador é conseguida através
de um STRAIGHT_JOIN entre várias tabelas e com diversas condições. O primeiro passo para
a realização da consulta é verificar, entre os serviços existentes, quais são do interesse do
utilizador. Para isso, é necessário utilizar o MS-ISDN do utilizador, fornecido pelo Gestor de
Eventos, de forma a:
• Limitar a tabela interesse às subcategorias que são do interesse do utilizador.
47
• Limitar a tabela subcategoria_servico aos serviços que estão relacionadas com as
subcategorias que são do interesse do utilizador.
Consegue-se assim obter todos os serviços que são do interesse do utilizador. De forma a
testar que a consulta estava correcta foram-se realizando testes directamente na base de
dados de forma a validar a consulta feita.
4.2.3.4 Verificação de Serviços na Zona
Após obtidos os todos os serviços que são do interesse do cliente, é preciso saber quais
desses serviços se aplicam à zona onde o utilizador se encontra. Para isso é necessário:
• Utilizar o identificador de zona enviado pelo Gestor de Eventos e obter, através da
tabela zona_servico, todos os serviços que se aplicam à zona em questão.
• Comparar esses serviços com os serviços obtidos anteriormente na tabela
subcategoria_serviço.
Consegue-se assim todos os serviços que são do interesse do utilizador e que se aplicam
à zona onde o utilizador se encontra. De forma a testar que a consulta estava correcta foram-
se realizando testes directamente na base de dados de forma a validar a consulta feita,
obtendo-se para diferentes zonas e utilizadores diferentes serviços de acordo com estas.
4.2.3.5 Verificação de Histórico
De forma a manter o fornecimento de serviços interessante, foi estipulado que o mesmo
utilizador não pode receber o mesmo serviço mais que uma vez por semana. Torna-se
necessário realizar essa verificação antes de fornecer um determinado serviço a um utilizador.
Assim, após obtidos os serviços que são do interesse do utilizador e que estão associados à
zona onde se encontra, é necessário determinar quais desses serviços ainda n foram
fornecidos na semana actual. Para tal, é necessário:
• Utilizar o MS-ISDN fornecido pelo Gestor de Eventos de forma a obter as entradas
na tabela histórico que correspondem ao utilizador.
• Das entradas resultantes, obter entradas que ocorreram na semana actual.
Como o histórico armazena que serviços foram fornecidos aos clientes e a data em que
foram fornecidos, é possível obter os serviços que foram fornecidos ao utilizador na semana
actual. De forma a testar que a consulta estava correcta foram-se realizando testes
directamente na base de dados de forma a obter os resultados pretendidos para diferentes MS-
ISDN.
4.2.3.6 Selecção de Serviço
Ao se verificar que serviços obtidos anteriormente não constam nestas entradas da tabela
histórico, ocorre uma das seguintes situações:
• A procura de serviço não devolve qualquer resultado o que significa que não
existe nenhum serviço que se adeqúe ao cliente. Quando esta situação ocorre,
48
nenhum serviço é enviado ao cliente e o ciclo de execução relativo ao utilizador
em questão termina.
• A procura de serviço devolve um ou mais resultados. Nesta situação o primeiro
resultado é identificado, sendo esse o serviço a enviar ao utilizador. O Gestor de
Conteúdos é chamado e o identificador do cliente (MS-ISDN) e do serviço são
enviados como parâmetros
A consulta global foi testada directamente na base de dados e, posteriormente na
aplicação de forma a verificar que os resultados obtidos eram os pretendidos.
4.2.4 Gestor de Conteúdos
4.2.4.1 Estudo dos Requisitos
Antes do início do desenvolvimento desta componente foi necessário identificar as tarefas
que o Gestor de Conteúdos deve realizar. Concluiu-se que o Gestor de Conteúdos deve:
• Adquirir o conteúdo a enviar
• Realizar o envio de SMS com o conteúdo especificado
• Aguardar notificação de entrega
• Actualizar a base de dados
4.2.4.2 Aquisição de Conteúdo
Através do identificador de serviço enviado pelo Gestor de Interesses, o Gestor de
Conteúdos realiza uma consulta à base de dados e, através da tabela serviço, obtém o
conteúdo a enviar ao utilizador.
4.2.4.3 Envio de SMS
O envio de SMS é realizado utilizando, uma vez mais, a Parlay X Gateway (neste caso o
emulador). Através do Web Service de Short Messaging, é possível enviar SMS a um ou mais
utilizadores. Para se recorrer a este Web Service é utilizada a componente SendSmsBean
definida pelo Telecom Web Services SDK. Esta componente pode assim ser utilizada para o
envio de SMS utilizando os Web Service Parlay X mas sem as complexidades de comunicação
exigidas por este. Esta componente consiste num número de parâmetros de sistema e de
utilizador. Os parâmetros de sistema contêm informação que permite ser utilizada para o envio
de múltiplas mensagens. Ao contrário destes, os parâmetros de utilizador são únicos para cada
mensagem SMS enviada. A Tabela 4-4 apresenta os parâmetros de sistema a definir.
49
Tabela 4-4 – Parâmetros de sistema para SendSmsBean
Parâmetro Descrição
parlayxGatewayUrl Endereço para o Web Service Parlay X de Short Messaging.
xwssInputStream Ficheiro de configuração de segurança XWSS (XML Web Services Security), ou null
para desactivar segurança.
enableCallbacks
Boolean que identifica se a notificação de recepção de mensagens deve ocorrer ou
não. O Gestor de Conteúdos define este parâmetro a true, o que significa que se
pretende a recepção de notificações de mensagens.
callbackUrl Endereço para recepção de notificações (Callbacks).
wsdlLocation Localização do WSDL (Web Services Definition Language).
chargingInfo Informações opcionais caso se pretenda efectuar taxação (não utilizado pelo Gestor
de Conteúdos).
Todas as informações necessárias aos parâmetros de sistema podem ser encontradas no
ficheiro de configuração ss.properties e são lidas previamente pela classe Propriedades. Estes
parâmetros são relativos ao modo como a comunicação entre a Parlay X Gateway e a
aplicação comunicam. Ao contrário dos parâmetros de sistema, os parâmetros de utilizador são
definidos utilizando funções set antes de se enviar o pedido de inicio de notificações
geográficas. Na
Tabela 4-5 apresentada em baixo, encontram-se os parâmetros de utilizador a definir.
Tabela 4-5 – Parâmetros de utilizador para SendSmsBean
Parâmetro Descrição
fromAddress Se presente, indica o nome da entidade que envia o SMS. É mostrado na
SMS como remetente.
toAddresses Endereços para os quais as SMS serão enviadas.
messageText Texto a ser enviado no SMS.
callbackCorrelator
Identificador único por cada SMS enviado. É através deste identificador
que é possível saber a que SMS enviada pertence uma determinada
notificação recebida.
Estes valores são definidos para cada envio de SMS. Entre os parâmetros de utilizador,
apenas os fromAddress e callbackCorrelator não se encontram especificados na base de
dados.
O parâmetro fromAddress é definido pela aplicação. Trata-se de uma String com o nome
da entidade, neste caso, o Servidor de Serviços.
O callbackCorrelator é gerado aleatoriamente em tempo de execução. Este valor é obtido
gerando um Int aleatório de entre 232 possíveis Int sendo posteriormente concatenado com o
tempo actual em milissegundos e passado para o formato String.
O parâmetro messageText é obtido utilizando o identificador de serviço, do modo descrito
no capítulo anterior, Obtenção de Conteúdo.
50
Finalmente, para o parâmetro toAddresses é utilizado o MS-ISDN enviado pelo Gestor de
Interesses para o Gestor de Conteúdos.
Concluindo, após definidos os parâmetros de sistema, os parâmetros de utilizador são
definidos utilizando funções set e a SMS é enviada para o utilizador. Todos os identificadores
das mensagens enviadas e respectivos callbackCorrelators são guardados pelo Gestor de
Conteúdos até confirmação do estado de entrega da mensagem ao terminal (ver capítulo
seguinte). É assim criado um registo de mensagens enviadas com o objectivo de identificar
qual o serviço que foi enviado quando uma notificação é recebida.
O envio de SMS foi testado utilizando o emulador que permite a verificação das
mensagens que foram enviadas para a Parlay X Gateway, neste caso enviadas para o
emulador (ver Figura 4-5).
Figura 4-5 – Chamada à operação SendSms
Na figura está representado o envio de uma SMS com sucesso e é possível visualizar
todos os parâmetros do Web Service Parlay X de Short Messaging que foram enviados
utilizando a componente do SDK.
4.2.4.4 Recepção de Notificação de Entrega de Mensagem
No envio de SMS, o valor do parâmetro de sistema enableCallbacks é true o que significa
que se pretende a recepção de notificações de entrega de mensagens de forma a tentar
garantir que uma mensagem enviada foi efectivamente entregue ao utilizador.
Após o envio de uma ou mais mensagem SMS, o Gestor de Conteúdos aguarda a
recepção assíncrona de uma notificação por mensagem. Ao receber uma notificação enviada
pela Parlay X Gateway (ou emulador), o Gestor de Conteúdos utiliza-a para identificar a que
utilizador pertence a notificação e qual o estado de entrega da mensagem.
A Tabela 4-6 apresenta os estados possíveis das mensagens enviadas e as tarefas que o
Gestor de Conteúdos realiza em cada um desses estados.
51
Tabela 4-6 – Estados de Entrega de SMS
Estado de Entrega Gestor de Conteúdos
DELIVERY_IMPOSSIBLE
Foi impossível a entrega da mensagem. Nesta
situação, o Gestor de Conteúdos considera que o
serviço não foi fornecido e apaga o registo de envio
de mensagem guardado.
MESSAGE_WAITING
Caso a mensagem fique em espera, o Gestor de
Conteúdos aguarda nova recepção de notificação e
mantém o registo de envio de mensagem.
DELIVERY_UNCERTAIN Se a entrega for incerta ou as notificações de
entregas não forem suportadas ou houver
confirmação de entrega, o Gestor de Conteúdos
considera que a mensagem foi entregue, apaga o
registo de envio de mensagem e actualiza a base de
dados.
DELIVERY_NOTIFICATION_NOT_SUPPORTED
DELIVERED_TO_TERMINAL
A recepção de notificações de entrega de mensagens foi testada utilizando o emulador
que permite a simulação da entrega de uma mensagem SMS num terminal móvel emulado e
respectivo envio de notificação de entrega da mensagem.
4.2.4.5 Actualização da Base de Dados
Se a mensagem foi entregue ao utilizador com sucesso, é necessário actualizar a tabela
histórico na base de dados. É assim adicionado um registo que contém o identificador do
serviço fornecido, o identificador do utilizador (MS-ISDN), e um TimeStamp da altura em que o
serviço foi entregue ao cliente. Termina assim o ciclo gerado pela entrada de um utilizador
numa área registada.
A actualização da tabela histórico foi testada directamente na base de dados e bem como
integrada na recepção de mensagens SMS e respectiva recepção de notificação de entrega ao
terminal.
4.3 Componente de Apresentação
A Componente de Apresentação permite a configuração do sistema tanto por parte dos
utilizadores do sistema, ou clientes, que podem alterar as suas preferências, como por parte
dos administradores que podem gerir serviços e zonas. Existem assim, na mesma aplicação
Web, duas interfaces distintas, uma para clientes e outra para administradores, dependendo da
entidade que se autentica.
Neste capítulo serão primeiramente introduzidas as ferramentas utilizadas para o
desenvolvimento da Componente de Apresentação e, posteriormente, serão descritos os
detalhes e opções de implementação tomadas para esta componente.
52
4.3.1 Ferramentas Utilizadas
Para implementação desta componente foi utilizada a linguagem de programação Java.
Foi utilizado o eclipse, um IDE (Integrated Development Environment) Open Source [26] e, a
plataforma Java utilizada, foi o J2EE (Java Enterprise Edition).
Foi também utilizada o GWT-Ext, uma biblioteca poderosa de componentes para
aplicações Web tais como tabelas, grelhas, caixas de escolha múltipla, formulários, caixas de
texto e menus, acessíveis através de uma API simples [29]. O GWT-Ext utiliza o GWT (Google
Web Toolkit) e o Ext 2.0.2.
O GWT (Google Web Toolkit) permite a criação simplificada de aplicações Web complexas
e de alto desempenho, com front end em JavaSript, na linguagem Java. Com o GWT é
possível criar um front end AJAX (Asynchronous JavaScript And XML) na linguagem de
programação Java, fazendo posteriormente a compilação para JavaScript optimizado que
funciona automaticamente com todos os principais navegadores [30]. Por sua vez, o Ext é uma
biblioteca JavaScript para a construção de aplicações Web interactivas utilizando técnicas
como o AJAX. Concluindo, o GWT-Ext vai juntar as funcionalidades do GWT com os
componentes disponíveis na biblioteca JavaScript do Ext.
No desenvolvimento de uma aplicação Web pode ser muitas vezes necessária a
comunicação com um servidor que, por exemplo, comunique com uma determinada base de
dados ou realize outro tipo de serviços à aplicação Web. Uma das funcionalidades utilizadas
pelo GWT-Ext é a comunicação com o servidor através de RPCs (Remote Procedure Calls)
muito simples. O GWT RPC torna todas as comunicações Java particularmente fáceis e
eficientes [30]. De forma semelhante ao Java RMI (Remote Method Invocation) tradicional,
basta criar uma interface que especifique os métodos remotos que se deseja invocar. O código
que se encontra do lado do servidor é frequentemente denominado de serviço (service). As
respostas do lado servidor para o lado cliente são realizadas de forma assíncrona, não
impedindo assim o fluxo de execução da aplicação Web.
4.3.2 Painel de Autenticação
O painel utilizado para autenticação é comum ao cliente e administrador de sistema.
Consiste na inserção de um identificador e uma senha que apenas é conhecida pelo utilizador
que se pretende autenticar.
No caso de se tratar de um cliente do serviço, este tem de inserir o seu MS-ISDN, que é o
seu identificador, e uma senha. No caso de se tratar de um administrador do sistema, este tem
de inserir o nome de administrador e uma senha. Este painel permite ainda o registo de novos
utilizadores. Na Figura 4-6 podemos observar o aspecto gráfico do painel de autenticação
utilizando o navegador Web Firefox.
53
Figura 4-6 – Painel de Autenticação
Um utilizador da aplicação Web é autenticado com recurso a um serviço (GWT RPC) que
comunica com a base de dados e confirma que os dados do cliente estão correctos. É
importante referir que, apesar de a segurança não ser um requisito essencial à solução,
apenas os resumos (hash value) das senhas foram armazenados na base de dados de forma a
garantir que as senhas nunca são enviadas em claro.
Na figura abaixo temos o painel de registo de um novo cliente sendo necessário um
número de telemóvel (MS-ISDN), um nome e uma senha para o cliente se registar. Mais uma
vez, o registo é realizado com recurso a um serviço de registo, que insere o cliente na base de
dados.
Figura 4-7 – Painel de Registo
54
4.3.3 Aplicação Web Cliente
Caso a autenticação seja realizada por um cliente, é apresentada a interface de cliente
que permite que este altere as suas preferências e faça gestão do seu registo no serviço. Tal
como pode ser observado na Figura 4-8, é inicialmente apresentado ao cliente os seus
interesses actuais, correspondentes às subcategorias de interesse do cliente. No menu do lado
esquerdo, encontram-se as categorias possíveis de escolha e, seleccionando cada uma das
categorias são apresentadas as subcategorias que o cliente pode escolher como seu interesse.
Figura 4-8 – Painel de gestão de serviço de cliente
O painel de cliente permite ainda, no menu de Preferências à esquerda, que o cliente
realize o desregisto do serviço e que configure o número de serviços diários que pretende
receber.
4.3.4 Aplicação Web Administrador
Caso a autenticação seja realizada por um administrador, é apresentada a interface de
administrador que permite, como foi já referido, a gestão de serviços, categorias/subcategorias
de serviços e zonas.
O menu de configurações, à semelhança da interface do cliente, encontra-se à esquerda e
está dividido em três partes ou submenus, Categorias, Zonas e Serviços, correspondentes à
gestão de cada um desses componentes.
55
No submenu Categorias é possível adicionar e remover categorias e subcategorias a que
correspondem os serviços e os interesses dos utilizadores. O painel central de qualquer opção
escolhida no submenu Categorias apresenta sempre todas as categorias e subcategorias
existentes do lado esquerdo e, do lado direito o painel correspondente a cada opção (ver
Figura 4-9).
Figura 4-9 – Painel Criar Categoria
A apresentação de categorias e subcategorias e a criação e eliminação das mesmas é
feita com recurso a diversos serviços que comunicam com a base de dados e realizam
consultas e actualizações à mesma.
No submenu de Zonas é possível consultar, criar e remover zonas. No painel central
apresentado na consulta ou criação de zonas, foi integrado o Google Maps de forma a mostrar
um mapa onde se pode consultar ou definir áreas para fornecimento de serviços (ver Figura
4-10). Na opção remover zonas á apenas apresentada uma lista com as diversas zonas e um
botão que permite chamar o serviço que procede à remoção da zona na base de dados.
56
Figura 4-10 – Painel de Consulta de Zonas
A apresentação, criação e remoção de zonas é feita com recurso a serviços que
comunicam com a base de dados para realização de consultas de informações de zonas
existentes e actualizações para adição e remoção de zonas.
Por último, no submenu de Serviços é possível realizar as seguintes operações:
• Consultar serviços existentes
• Criar serviços
• Eliminar serviços
• Editar serviços
• Associar e desassociar serviços a zonas
• Associar e desassociar serviços a categorias e subcategorias
No painel central de qualquer opção escolhida no submenu Serviços é sempre
apresentado, do lado esquerdo, as associações existentes de um determinado serviço e, do
lado direito, o painel correspondente à opção escolhida no submenu (ver Figura 4-11).
57
Figura 4-11 – Painel de associação de serviços a subcategorias
Os dados e actualizações relativas à gestão de serviços são conseguidos através do
recurso a serviços que comunicam com a base de dados e realizam as consultas e
actualizações necessárias à mesma.
58
5 Avaliação da Solução
Neste capítulo é descrito o processo de avaliação da solução implementada que permite
provar que os objectivos propostos foram alcançados. O processo de avaliação consistiu num
conjunto de testes que se dividem em três grupos distintos: Testes de Integração, Testes de
Usabilidade e Testes de Performance. Neste capítulo é também descrito o ambiente (hardware
e software) sobre o qual os testes foram realizados.
5.1 Objectivos de Avaliação
O fornecimento de serviços Push baseados em localização é conseguido essencialmente
através da Componente Lógica e respectivo modelo de dados descrito nos capítulos anteriores.
A Aplicação Web de Cliente da Componente de Apresentação é também importante na medida
em que é através desta que o utilizador pode definir as suas preferências, uma funcionalidade
necessária ao cumprimento dos objectivos. A realização de testes funcionais e de desempenho
a estas componentes e respectiva integração com a base de dados permite assim demonstrar
se os objectivos propostos foram alcançados.
Na Tabela 5-1 são apresentadas diversas actividades, retiradas dos diagramas de
interacção apresentados no Capítulo 3, definidas para a realização de uma avaliação da
solução que demonstre o cumprimento dos objectivos propostos.
59
Tabela 5-1 – Actividades definidas para avaliar a solução
Actividades Descrição
Definição de Preferências. Esta
actividade consiste na definição de
preferências por parte de um utilizador.
Identificação de Zona. Esta actividade
consiste em identificar a que zona
pertence uma determinada notificação
recebida.
Identificação de Serviço. Esta
actividade consiste em identificar qual o
serviço a enviar ao utilizador.
Criação e Envio de SMS. Esta
actividade consiste em criar e enviar
uma SMS.
5.2 Ambiente de Avaliação
Os testes realizados à solução decorreram no mesmo ambiente em que esta se
desenvolveu. Não foi possível a realização de testes utilizando uma rede UMTS real visto que
isso implicaria alterações grandes às redes existentes em Portugal bem como negociações,
difíceis e demoradas com as operadoras nacionais. Assim sendo, o Telecom Web Services
Network Emulator, incluído no Telecom Web Services SDK, foi utilizado para a realização de
testes à solução desenvolvida.
O objectivo do emulador é fornecer a possibilidade de testar o funcionamento de
aplicações de telecomunicações, antes de se realizar o contacto com uma operadora real.
Como tal, a utilização do emulador tem a desvantagem de os tempos de registo de
zonas/clientes e de envio de SMS não poderem ser devidamente avaliados devido ao facto de
estes não corresponderem minimamente aos valores reais. A solução desenvolvida é assim
avaliada com recurso ao emulador, nas actividades descritas acima.
5.2.1 Componentes Utilizados
Os testes descritos neste capítulo foram realizados com recurso aos seguintes
componentes:
• Máquina de Servidor de Serviços
60
• Máquina de emulação da ParlayX Web-Services Gateway (Telecom Web Services
Network Emulator)
• Máquina de acesso a Aplicações Web.
• Máquina de Servidor de Aplicações Web
• Máquina de Base de Dados MySQL
Na Figura 5-1 é possível observar como é que os diversos componentes comunicam entre
si.
Figura 5-1 – Ambiente de teste
Na Tabela 5-2 encontram-se os detalhes da máquina de Servidor de Serviços utilizada
para a realização de testes.
Tabela 5-2 – Detalhes da Máquina de Servidor de Serviços
Processador Intel Pentium M processor 1.73GHz
Memória 2 GB DDR2
Disco Rígido 60 GB HDD
Sistema Operativo Windows XP Professional SP3
Configurações Tomcat Apache Tomcat 6.0.18
Configurações Java JRE 1.6.0_02
A máquina de Servidor de Aplicações Web utilizada foi a mesma que a máquina de
Servidor de Serviços pois os testes efectuados sobre ambas as máquinas são distintos, nunca
sendo realizados simultaneamente.
Dado que a máquina de emulação da ParlayX Web-Services Gateway e a máquina de
Servidor de Serviços são utilizadas simultaneamente na realização dos testes, considerou-se
relevante a utilização de duas máquinas distintas. Assim, na Tabela 5-3 encontram-se os
detalhes da máquina de emulação da ParlayX Web-Services Gateway utilizada.
61
Tabela 5-3 – Detalhes da máquina de emulação da ParlayX Web-Services Gateway
Processador Intel Core 2 Duo T5250
Memória 2 GB DDR2
Disco Rígido 160 GB HDD
Sistema Operativo Ubuntu 9.04
Configurações Tomcat Apache Tomcat 6.0.18
Configurações Java JRE 1.6.0_0
A máquina de Base de Dados não será aqui especificada sendo que qualquer máquina
pode ser utilizada desde que possua o MySQL instalado e as tabelas se encontrem
devidamente criadas. O mesmo acontece com a máquina de acesso a Aplicações Web cujo
único requisito é o acesso a um navegador e a uma ligação à Internet.
Os scripts SQL utilizados para a criação da base de dados encontram-se em Anexo a este
documento.
5.2.2 Utilização do Emulador
Tal como já foi referido anteriormente, é necessário o recurso ao emulador (Telecom Web
Services Network Emulator) para a realização dos testes associados à Componente Lógica. O
emulador é utilizado para a realização das seguintes tarefas necessárias à execução das
actividades descritas:
• Simular a entrada e saída de um utilizador em diversas áreas
• Enviar notificação de localização correspondente ao evento ocorrido
• Simular a recepção de SMS em terminais emulados
• Enviar notificação de recepção de SMS
O primeiro passo necessário à realização das tarefas descritas acima é a criação dos
terminais a emular tanto para simular alterações de localização como para simular a recepção
de SMS. Na Figura 5-2 é possível observar como são criados terminais no emulador através da
opção Terminals.
62
Figura 5-2 – Criação e terminais no emulador
Os terminais criados no emulador para teste devem corresponder a terminais dos
utilizadores registados na base de dados da solução.
Após criados os terminais, torna-se possível a simulação de deslocamento dos mesmos
através da opção Show Map fornecida pelo emulador. Esta opção, como é possível visualizar
na Figura 5-3, apresenta um mapa e o conjunto de terminais registados no emulador, sendo o
seu deslocamento simulado com a alteração de posição dos terminais presentes no mapa. De
forma a tornar a solução mais realista, foi colocado um mapa de uma zona de Lisboa que
abrange alguns pontos de interesse ao fornecimento de serviços. O mapa foi retirado do
Google Maps e as coordenadas utilizadas no mapa são as coordenadas reais da zona
representada.
63
Figura 5-3 – Mapa de simulação de deslocamento de terminais
Após o registo das zonas e clientes por parte do Gestor de Eventos junto do emulador, é
possível deslocar os terminais no mapa para as zonas registadas (desde que de as zonas
estejam dentro das coordenadas do mapa) e o emulador automaticamente envia uma
notificação de localização de entrada ao Gestor de Eventos. O mesmo se passa quando se
desloca um terminal para fora de uma das zonas registadas sendo enviado ao Gestor de
Eventos uma notificação de localização de saída. A entrada e saída de terminais em diversas
áreas registadas pode assim ser simulada, bem como o envio de notificações de localização
correspondentes às mesmas.
O Telecom Web Services Network Emulator permite também a recepção de SMS em
terminais móveis emulados bastando para isso que se encontrem criados na opção Terminals
do menu do emulador. Na Figura 5-4 é possível observar a apresentação de um terminal
emulado que permite ler SMS recebidas.
64
Figura 5-4 – Emulação de terminal
5.3 Testes de Integração
Os testes de integração permitem uma avaliação qualitativa da solução e representam
todos os testes efectuados para garantir o correcto funcionamento das actividades descritas e
a sua integração no sistema. Para uma correcta avaliação de cada actividade, foram definidos
diversos cenários que se apresentam em cada um dos testes realizados.
5.3.1 Definição de Preferências
É pretendido com este teste simular a alteração de preferências por parte do utilizador. O
único requisito para esta actividade é que o utilizador se encontre registado no serviço. Ao
avaliar esta actividade, pretende-se comprovar que o utilizador pode definir e alterar os seus
interesses e que estes serão correctamente armazenados na base de dados de forma a
poderem ser utilizados pelo Gestor de Interesses.
Para a realização deste teste foi definido um conjunto de categorias (ver Tabela 5-4) e
subcategorias, apresentadas na aplicação Web do cliente.
Tabela 5-4 – Categorias e subcategorias definidas
Categorias Filmes Desporto Música Comércio
Subcategorias
Comédia Futebol Clássica Informática
Drama Andebol Heavy
Metal Tabaco
Acção Volley Gospel Livros
Thriller Tenis Rock Moda
Homem
Suspence Basquetebol Pop Moda
Mulher
Romance Natação Jazz Perfumaria
65
Foram realizadas 50 alterações aos interesses, ou preferências, de dez utilizadores. As
alterações correspondentes foram sempre verificadas com sucesso na base de dados
decorrendo a actividade como era esperado.
5.3.2 Identificação de Zona
Com a realização deste teste é pretendido que, com a recepção de uma notificação de
localização, seja identificada a zona a que a notificação pertence. Os requisitos para a
realização deste teste são que uma ou mais zonas se encontrem registadas no emulador e que
um terminal móvel entre numa dessas zonas causando o envio de uma notificação de
localização ao Gestor de Eventos. Com a realização deste teste pretende-se comprovar que
uma zona é correctamente identificada quando um utilizador entra numa zona de interesse.
Para a realização deste teste foram definidas cinco zonas distintas dentro do mapa do
emulador (ver acima Figura 5-3):
• Zona do Jardim Zoológico
• Zona do Parque Eduardo Sétimo
• Zona do Instituto Superior Técnico
• Zona do Jardim Calouste Gulbenkian
• Zona do Centro Comercial Amoreiras
Em cada uma destas zonas foram registados 10 clientes e os seus terminais móveis foram
emulados como pode ser visualizado na Figura 5-5.
Figura 5-5 – Mapa com dez utilizadores
66
Foram realizadas simulações de entradas de todos os terminais em todas as zonas
registadas, num total de 50 notificações enviadas ao Gestor de Interesses e em todas elas a
zona correspondente à notificação foi correctamente identificada.
5.3.3 Identificação de Serviço
Este teste consiste em identificar um serviço a enviar a um utilizador que se encontre
numa zona registada. O requisito para a realização deste teste é o envio, por parte do Gestor
de Eventos, do identificador do cliente e do identificador da zona onde este se encontra. Com a
realização deste teste pretende-se comprovar que o Gestor de Interesses identifica um serviço
a enviar a um determinado utilizador que seja:
• Relacionado com os interesses do utilizador.
• Relacionado com a zona onde o utilizador se encontra.
A Tabela 5-5 apresenta os serviços definidos para a realização deste teste e ainda as
suas associações com as diferentes zonas e subcategorias.
Tabela 5-5 - Serviços e associações
Serviços Zonas Subcategorias
Feira de Livros e
Software • Parque Eduardo Sétimo
• Livros
• Informática
Feira Clássica de
Música e Vídeo
• Jardim Zoológico
• Jardim Calouste Gulbenkian
• Clássica
• Gospel
• Jazz
• Drama
• Romance
• Comédia
Semana Desportiva • Instituto Superior Técnico
• Parque Eduardo Sétimo
• Futebol
• Voleibol
• Basquetebol
Descontos
Loja de Roupa • Centro Comercial Amoreiras
• Moda Homem
• Moda Mulher
Terror e Suspence à
Noite
• Jardim Calouste Gulbenkian
• Instituto Superior Técnico
• Rock
• Heavy Metal
• Thriller
• Suspence
• Terror
Na realização deste teste, foram utilizados os dez utilizadores definidos nos testes
anteriores. Para cada um desses utilizadores foi definido um conjunto de interesses
(associações a subcategorias).
67
Foram realizadas 50 entradas dos dez utilizadores nas diversas zonas e verificou-se que o
identificador do serviço obtido pelo Gestor de Interesses foi sempre correspondente a um
serviço relacionado com a zona e os interesses de cada utilizador.
5.3.4 Criação e Envio de SMS
Com este teste pretende-se obter um conteúdo a enviar ao utilizador, formar uma SMS e
realizar o pedido de envio dessa SMS. O requisito para a realização deste teste é o envio, por
parte do Gestor de Interesses, do identificador do cliente e do identificador do serviço que se
pretende enviar ao cliente. Com a realização deste teste pretende-se comprovar que o Gestor
de Conteúdos consegue criar e enviar um serviço Push, em forma de SMS, ao utilizador.
Na Tabela 5-6 são apresentados os diversos conteúdos dos serviços definidos para a
realização deste teste.
Tabela 5-6 – Serviços e conteúdo
Serviços Conteúdo
Feira de Livros e Software Venha à Feira do Livro e Software de 15 a 20 de Agosto no
Parque Eduardo Sétimo e aproveite os descontos e feira.
Feira Clássica de Música e Vídeo
Aproveite durante este fim-de-semana a feira clássica de música e
vídeo no Jardim Zoológico de Lisboa e na Fundação Calouste
Gulbenkian. Os melhores CDs e filmes aos melhores preços.
Semana Desportiva
Durante a semana de 16 a 23 de Agosto, venha participar nos
eventos desportivos que se vão realizar no Instituto Superior
Técnico e no Parque Eduardo Sétimo.
Descontos
Loja de Roupa
Aproveite os descontos de 50% em todas as marcas durante o
fim-de-semana na nossa loja no Centro Comercial Amoreiras.
Terror e Suspence à Noite
Durante as noites de verão venha ver e ouvir o que há de melhor
em Terror e Suspence. Todos os dias das 21 às 02 no Instituto
Superior Técnico e na Fundação Calouste Gulbenkian.
Para os 10 utilizadores definidos nos testes anteriores, foram simuladas 50 entradas em
diversas zonas e todos os utilizadores receberam uma SMS com o conteúdo correspondente
ao serviço identificado pelo Gestor de Interesses. Na Figura 5-6 podemos observar um
exemplo de recepção de SMS num terminal emulado. Esta mensagem foi recebida quando um
utilizador com interesses em Livros ou diferentes estilos musicais, entrou ou no Jardim
Zoológico ou no Jardim Calouste Gulbenkian.
68
Figura 5-6 – Exemplo de recepção de SMS
5.4 Testes de Usabilidade
Um dos objectivos deste trabalho é permitir que os utilizadores possam definir as suas
preferências para a recepção de serviços. Assim sendo, foi considerado relevante a realização
de testes de usabilidade à aplicação Web que permite a realização de alterações de
preferências. Os testes foram feitos com um Universo de 40 pessoas onde, após um período
experimental com limite de 10 minutos e com o objectivo de os utilizadores definirem os seus
interesses, foi aplicado um questionário que se encontra em Anexo a este documento. Do
questionário resultaram os valores apresentados na Tabela 5-7. Nesta tabela é apresentado o
número de respostas em cada opção seguido da percentagem que representa.
Tabela 5-7 – Resultados dos questionários
Muito Bom Bom Médio Fraco Muito Fraco Total
Facilidade de Utilização 9
(22,5%)
19
(47,5%)
9
(22,5%)
2
(5%)
1
(2,5%)
40
(100%)
Apresentação 1
(2,5%)
6
(15%)
12
(30%)
16
(40%)
5
(12,5%)
40
(100%)
Organização da Informação 4
(10%)
11
(27,5%)
18
(45%)
7
(17,5%)
0
(0%)
40
(100%)
Coerência de nomes e títulos 8
(20%)
19
(47,5%)
8
(20%)
4
(10%)
1
(2,5%)
40
(100%)
69
Os testes de usabilidade foram conduzidos de modo a comprovar que a solução cumpre
com o objectivo de os utilizadores poderem definir as suas preferências ou interesses de forma
simples. É considerado satisfatória qualquer resposta que corresponda a Muito Bom, Bom ou
Médio. Assim sendo, as percentagens de respostas satisfatórias para cada questão são:
• Facilidade de Utilização: 92,5%
• Apresentação: 47,45%
• Organização da Informação: 82,5%
• Coerência de nomes e títulos: 87,5%
Através da dos resultados obtidos (ver Figura 5-7), é possível concluir que apenas a
questão acerca da apresentação teve a maioria das respostas abaixo dos valores aceitáveis.
No entanto, o aspecto da aplicação não é um requisito essencial para esta aplicação pois não
impede que um utilizador, de forma simples, altere ou defina os seus interesses. As restantes
respostas tiveram uma percentagem de respostas satisfatórias bastante elevadas provando-se
que os utilizadores podem com facilidade definir as suas preferências.
Figura 5-7 – Gráfico de resultados de Teste de Usabilidade
5.5 Testes de Performance
Neste capítulo pretende-se realizar um teste de performance que permita uma avaliação
quantitativa à solução, sendo o principal foco a Componente Lógica. Apesar de a rapidez da
solução não ser um requisito crítico no cumprimento dos objectivos propostos, é importante
saber quanto tempo é necessário para o fornecimento do serviço de forma garantir que um
serviço é entregue ao utilizador em tempo útil (enquanto ele ainda está na zona registada).
Para monitorização do tempo que cada tarefa demora a ser realizada, foi utilizado o JProfiler.
Trata-se de um Java Profiler que permite a monitorização de diversas características como o
tempo ou os recursos utilizados num programa Java [31].
0.00%10.00%20.00%30.00%40.00%50.00%60.00%70.00%80.00%90.00%100.00%
Facilidade de Utilização
Apresentação Organização da Informação
Coerência de Nomes e Títulos
Respostas Satisfatórias
Respostas não Satisfatórias
70
Para a realização deste teste foi considerado que todas as zonas e utilizadores já se
encontram registadas junto do emulador. É considerado para este teste o tempo que decorre a
partir do momento que uma notificação é recebida até ao envio do serviço, via SMS, ao
utilizador. Foram realizadas 100 amostras, apresentando-se os resultados na Tabela 5-8.
Tabela 5-8 – Tempo de execução do fornecimento do serviço
Actividade Tempo Min. (ms) Tempo Médio (ms) Temp Max. (ms)
Leitura de notificação
(Gestor Eventos) 4,237 4,714 5,796
Identificação de Zona
(Gestor de Eventos) 36,418 43,815 77,765
Verificação do Cliente
(Gestor de Interesses) 16,769 23,510 49,526
Identificação de Serviço
(Gestor de Interesses) 32,826 41,269 76,627
Obtenção de Conteúdo
(Gestor de Conteúdos) 12,371 25,946 47,872
Criação e Envio de SMS
(Gestor de Conteúdos) 313.945 442,019 720,778
Total 416,566 581,273 978,364
Nos testes realizados, o Servidor de Serviços Push nunca demorou mais de 1 segundo a
identificar e enviar um serviço a um utilizador que tenha entrado numa das zonas registadas.
Na grande maioria dos casos demorou pouco mais de meio segundo, concluindo-se assim que,
no que depende do Servidor de Serviços, um serviço pode ser enviado a um cliente num
período de tempo curto, sendo muito elevada a probabilidade de ele ainda se encontrar na
zona onde ocorreu a notificação.
71
6 Conclusões
No início do trabalho foi realizada uma análise ao conceito, importância e áreas de
aplicação dos Serviços Baseados em localização na actualidade. Surge assim o conceito de
Serviços Baseados em Localização do tipo Push, onde o serviço é fornecido sem a interacção
directa do utilizador, e observa-se que não existe uma oferta deste tipo de serviço que satisfaça
as necessidades dos utilizadores. Um serviço deste tipo, para ter sucesso, deve conseguir
chegar ao maior número de pessoas possível (Globalidade), ser realizado sobre uma
tecnologia que se encontra sempre activa e disponível aos utilizadores (Disponibilidade) e
ainda ser distribuído em qualquer zona onde o utilizador se encontre (Acessibilidade).
Após um levantamento das principais tecnologias sobre as quais se fornece serviços
baseados em localização, foi definida uma arquitectura que suporta o fornecimento de serviços
Push baseados em localização sobre a rede UMTS. A arquitectura prevê que os serviços a
fornecer aos utilizadores devem ser serviços que sejam do interesse do cliente e que estejam
relacionados com a zona onde este se encontra. Foram ainda identificados diagramas de
interacção que demonstram o funcionamento da arquitectura e que permitem alcançar os
objectivos propostos. A arquitectura levou à implementação da solução de fornecimento de
serviços, que é descrita nesta tese, e explica como é possível implementar um sistema que
cumpre os factores críticos de sucesso recorrendo à utilização de Web Services Parlay X.
Associado à implementação do sistema de fornecimento de serviços Push baseados em
localização, é defendido o processo de implementação de uma aplicação Web que permite que
os clientes definam os seus interesses e configurem as suas preferências e que os
administradores realizem toda a gestão de zonas, serviços e categorias de serviços.
Numa última análise, os testes realizados à solução desenvolvida permitiram justificar a
realização desta tese, onde os objectivos que foram propostos e os factores que motivaram
este trabalho foram alcançados, definindo a solução. Analisando os resultados da avaliação,
verificou-se que a solução desenvolvida permite fornecer serviços que sejam do interesse do
utilizador e que se encontrem relacionados com zonas de interesse onde o utilizador se
encontre.
Concluindo, a solução apresentada permite fornecer um serviço que traz inovação no que
respeita a serviços baseados em localização do tipo Push, e que tem interesse tanto para os
utilizadores, que recebem serviços de acordo com os seus interesses, como para os
fornecedores de serviço que divulgam informação que consideram ser do seu interesse.
Resta salientar que este trabalho foi desenvolvido em ambiente empresarial, na Movensis,
permitindo-me obter um contacto com um meio empresarial, que desconhecia, e que considero
que foi importante para a realização desta tese.
72
6.1 Trabalho Futuro
Existe ainda um longo percurso a percorrer para que a solução proposta possa ser
implementada. Actualmente, observa-se a um grande nível de confidencialidade acerca das
redes das operadoras telefónicas móveis no nosso país o que dificulta a implementação de
soluções como a proposta. É sabido que as operadoras fornecem já alguns serviços baseados
em localização. No entanto, a utilização das capacidades de localização da rede é exclusiva à
operadora não sendo acessível a fornecedores de serviços externos. Uma solução para este
problema seria uma parceria com as operadoras e permitir a implementação do serviço não
como entidade externa à rede móvel, mas integrado nesta.
Outro problema prende-se com o facto de ainda não existir em Portugal nenhuma
operadora que implemente serviços baseados em localização utilizando o Parlay X. No entanto
o Parlay Group está a crescer, a Ericsson e a Alcatel estão a apostar fortemente neste tipo de
plataformas e cada vez mais operadoras por todo o mundo utilizam Parlay X [8]. O Parlay X
permite desenvolver uma variedade grande de serviços inovadores e o desenvolvimento de
soluções como a apresentada nesta tese pode levar as operadoras a darem o próximo passo
na implementação deste tipo de plataformas.
A nível de serviço existe também trabalho a realizar na solução implementada. Um dos
pontos de principal foco será a inclusão de mecanismos de segurança eficazes para a
implementação da solução no mercado. Este assunto não foi abordado nesta tese pois sai do
âmbito da mesma e dos objectivos definidos.
A aplicação desenvolvida pode ser utilizada para fornecimento de diversos tipos de
informação como eventos culturais e de lazer ou publicidade. No entanto, existem muitas
possibilidades de acrescentar valor à solução. Um serviço de emergência pode ser realizado
onde, em situações consideradas críticas, os utilizadores que se encontrem numa zona
afectada são avisados do que está a ocorrer e do modo como devem agir. Outra aplicação
interessante seria o fornecimento de um serviço de trânsito onde um utilizador ao entrar numa
zona recebe informações actualizadas de trânsito e de ruas que deve evitar. Apesar de não ser
necessário para o cumprimento dos objectivos propostos, a solução desenvolvida guarda
informações acerca do tempo que os utilizadores permanecem nas áreas de interesse para
possibilitar o futuro desenvolvimento destes novos serviços.
Resta salientar que, apesar de terem sido realizados testes à aplicação e de se ter
demonstrado o seu funcionamento, é importante testar a aplicação numa rede real onde se
possa medir o tempo total do fornecimento do serviço e estudar a sua escalabilidade.
73
Bibliografia
[1] Anandarajan, M., Simmers, C. and Igbaria, M. An exploratory investigation of the
antecedents and impact of Internet usage: an individual perspective. Proceedings of the Thirty-
First Hawaii International Conference on System Sciences. Vol. 4, pp. 22-30. Jan 1998. ISBN:
0-8186-8255-8.
[2] Steiniger, Stefan, Neun, Moritz and Edwardes, Alistar. Foundations of Location Based
Services. Department of Geography, University of Zurich (Switetzerland). 2006.
[3] Mohapatra, D and Suma, S.B. Survey Of Location Based Wireless Services. 2005 IEEE
International Conference on Personal Wireless Communications. pp. 358-362. Jan 2005. ISBN:
0-7803-8964-6.
[4] Virrantaus, K., et al. Developing GIS-supported location-based services. Proceedings of the
Second International Conference on Web Information Systems Engineering. pp. 66-75. Dez
2001. ISBN: 0-7695-1393-X.
[5] Movensis. Movensis: Quem Somos. movensis.com. [Online] Movensis. [Cited: Aug 4, 2009.]
http://www.movensis.com/2009/institucional/index.htm.
[6] Solanki, Prashant and Hu, Huosheng. Techniques used for Location-based Services: A
Survey. Department of Computer Science, University of Essex. Dec 2005.
[7] TMN. TMN Web site. [Online] [Cited: 7 21, 2009.]
http://www.tmn.pt/portal/site/negocios/menuitem.936b22b6652c6adaff9065df851056a0/?vgnext
oid=14bfeb0220876010VgnVCM1000005401650aRCRD.
[8] Ericsson AB. Parlay X Web Services. s.l. : Ericsson, 2006.
[9] Ramirez-Iniquez, R. and Green, R.J. Indoor optical wireless communications. IEEE
Colloquium on Optical Wireless Communications.London : IEEE, Jun 1999.
[10] Hightower, J. and Borriello, G. Location systems for ubiquitous computing. 8, Computer,
Vol. 34, pp. 57-66, Aug 2001. ISBN: 0018-9162 .
[11] Dijk, Esko O. Indoor Ultrasonic Position Estimation Using a Single Base Station.
Eindhoven : Technische Universiteit Eindhoven, 2004. ISBN 90-386-0912-4.
[12] Araklian, Hagop. Indoor & Outdoor location sensing. 2005.
[13] Weissman, Zeev. Indoor Location. 2004.
[14] Bajaj, R., Ranaweera, S.L. and Agrawal, D.P. GPS: Location-Tracking Technology.
Computer. Vol. 35, no.4, pp. 92-94, Apr 2002.
[15] Advanced Wireless Planet. [Online] Round Solutions Ltd. [Cited: Nov 24, 2008.]
http://www.gsm-modem.de/gps_tracking.html.
[16] Cayzac, Julien. The Cumulative Displacement Filter. [Online] [Cited: Nov 26, 2008.]
http://www.julien-cayzac.com/code/gps/.
[17] LaMance, Jimmy, Jarvinen, Jani and DeSalas, Javier. Assisted GPS: A Low-
Infrastructure Approach. GPS World Web site. [Online] Mar 1, 2002. [Cited: Nov 28, 2008.]
http://www.gpsworld.com/gpsworld/article/articleDetail.jsp?id=12287.
74
[18] Schiller, Jochen. Mobile Communications. 2nd Edition. Great Britain : Pearson Education,
2003. ISBN: 0-321-12381-6.
[19] Kos, T, Grgic, M and Sisul, G. Mobile User Positioning in GSM/UMTS Cellular Networks.
8th International Symposium ELMAR-2006 focused on Multimedia Signal Processing and
Communications. pp. 185-188. Jun 2006. ISBN: 953-7044-03-3.
[20] 3rd Generation Partnersgip Project. Technical Specification Group Core Network and
Terminals; Open Service Access (OSA); Parlay X Web Services; Release 6. 2006. 3GPP TS
29.199.
[21] Cox, Christopher. Essentials of UMTS. Cambridge : Cambridge University Press, 2008.
ISBN: 978-0-521-88931-5.
[22] The Parlay Group: Parlay X Working Group. Parlay X Web Services White Paper. s.l. :
The Parlay Group, 2002.
[23] Dru, M-A. and Saada, S. Location-based mobile services: The essentials. 2001. Alcatel
Communications Review.
[24] Leroy, Suresh and Faggion, Nadège. Alcatel End-to-end Location-based services
solution. s.l. : Alcatel, 2005.
[25] MySQLAB. MySQL Query Browser (revision: 235). s.l. : MySQLAB, 2009.
[26] Foundation, Eclipse. Eclipse - an open development platform. Eclipse. [Online] [Cited:
Mar 22, 2009.] http://www.eclipse.org/.
[27] Ericsson. Telecom web services v4.0. Ericsson. [Online] Apr 21, 2009. [Cited: Aug 7,
2009.]
http://www.ericsson.com/developer/sub/open/technologies/parlayx/tools/telecom_web_services.
[28] —. Telecom Web services Network Emulator. Ericsson. [Online] Sep 26, 2007. [Cited: Aug
10, 2009.]
http://www.ericsson.com/developer/sub/open/technologies/open_development_tips/tools/teleco
m_network_emulator.
[29] Google. GWT-Ext Widget Library. [Online] Google. [Cited: Aug 15, 2009.]
http://code.google.com/p/gwt-ext/.
[30] —. Google Web Toolkit: Product Overview. [Online] Google code. [Cited: Aug 15, 2009.]
http://code.google.com/intl/pt-PT/webtoolkit/overview.html.
[31] ej-technologies. JProfiler. [Online] [Cited: Aug 20, 2009.] http://www.ej-
technologies.com/products/jprofiler/overview.html.
[32] Tsalgatidou, Aphrodite, et al. Mobile E-Commerce and Location-Based Services:
Technoogy and Requirements. Athens : University of Athens, 2003.
[33] Steinfield, Charles. The development of Location Based Services in Mobile Commerce.
Department of Telecommunication, Michigan State University. 2004.
[34] Morgan-Owen, G.J. and Johnston, G.T. Differential GPS positioning. Electronics &
Communication Engineering Journal, Vol. 7, pp. 11-21, Fev 1995. ISBN: 0954-0695.
75
ANEXO I – Modelo da Base de Dados
admin
«column»*PK id_admin: INT* nome: VARCHAR(45)* password: VARCHAR(45)*FK id_papel: INT
«PK»+ PK_admin(INT)
«index»+ FK_admin_id_papel(INT)
«FK»+ FK_admin_id_papel(INT)
categoria
«column»*PK id_categoria: INT* nome: VARCHAR(45)
«PK»+ PK_categoria(INT)
cliente
«column»*PK msisdn: INT* nome: VARCHAR(25)* maxServicos: INT* password: VARCHAR(45)*FK id_papel: INT
«PK»+ PK_cliente(INT)
«index»+ FK_cliente_id_papel(INT)
«FK»+ FK_cliente_id_papel(INT)
cliente_zona
«column»*pfK msisdn: INT*FK id_zona: INT
«PK»+ PK_cliente_zona(INT)
«index»+ FK_cliente_zona_id_zona(INT)
«FK»+ FK_cliente_zona_msisdn(INT)+ FK_cl iente_zona_id_zona(INT)
historico
«column»*pfK msisdn: INT* id_servico: INT*PK data_servico: TIMESTAMP = ''CURRENT_TIMES...
«PK»+ PK_historico(INT, TIMESTAMP)
«FK»+ FK_historico_msisdn(INT)
interesse
«column»*pfK msisdn: INT*pfK id_subcategoria: INT
«PK»+ PK_interesse(INT, INT)
«index»+ FK_interesse_id_subcategoria(INT)
«FK»+ FK_interesse_id_subcategoria(INT)+ FK_interesse_msisdn(INT)
papel
«column»*PK id_papel: INT* nome: VARCHAR(45)* vista_cl iente: TINYINT* vista_admin: TINYINT* desregistado: TINYINT
«PK»+ PK_papel(INT)
serv ico
«column»*PK id_servico: INT* nome: VARCHAR(25)* conteudo: TEXT
«PK»+ PK_servico(INT)
subcategoria
«column»*PK id_subcategoria: INT* nome: VARCHAR(25)
«PK»+ PK_subcategoria(INT)
subcategoria_categoria
«column»*pfK id_subcategoria: INT*FK id_categoria: INT
«PK»+ PK_subcategoria_categoria(INT)
«index»+ FK_categoria_subcategoria_id_subcategoria(INT)+ FK_categoria_subcategoria_id_categoria(INT)
«FK»+ FK_categoria_subcategoria_id_categoria(INT)+ FK_categoria_subcategoria_id_subcategoria(INT)
subcategoria_serv ico
«column»*pfK id_servico: INT*pfK id_subcategoria: INT
«PK»+ PK_subcategoria_servico(INT, INT)
«index»+ FK_subcategoria_servico_id_subcategoria(INT)
«FK»+ FK_subcategoria_servico_id_servico(INT)+ FK_subcategoria_servico_id_subcategoria(INT)
zona
«column»*PK id_zona: INT* nome: VARCHAR(50)* latitude: DOUBLE* longitude: DOUBLE* raio* precisao* cri teria: VARCHAR(45)* checkImmediate: VARCHAR(45)* durationUnits: INT* durationMetric: VARCHAR(45)* frequencyUnits: INT* frequencyMetric: VARCHAR(45)* count: INT
«PK»+ PK_zona(INT)
zona_serv ico
«column»*pfK id_servico: INT*pfK id_zona: INT
«PK»+ PK_zona_servico(INT, INT)
«index»+ FK_zona_servico_id_zona(INT)
«FK»+ FK_zona_servico_id_servico(INT)+ FK_zona_servico_id_zona(INT)
+FK_zona_servico_id_zona
0..*
(id_zona =id_zona)
+PK_zona 1
+FK_zona_servico_id_servico
0..* (id_servico =id_servico)
+PK_servico
1
+FK_subcategoria_servico_id_subcategoria
0..*
(id_subcategoria =id_subcategoria)
+PK_subcategoria1
+FK_subcategoria_servico_id_servico 0..*
(id_servico =id_servico)
+PK_servico 1
+FK_categoria_subcategoria_id_subcategoria0..*
(id_subcategoria =id_subcategoria)
+PK_subcategoria 1
+FK_categoria_subcategoria_id_categoria 0..*
(id_categoria =id_categoria) +PK_categoria
1
+FK_interesse_msisdn
0..*
(msisdn =msisdn)
+PK_cliente
1
+FK_interesse_id_subcategoria 0..*
(id_subcategoria =id_subcategoria)
+PK_subcategoria
1
+FK_historico_msisdn
0..*(msisdn =msisdn)
+PK_cliente
1
+FK_cliente_zona_id_zona 0..*
(id_zona =id_zona)
+PK_zona
1
+FK_cliente_zona_msisdn 0..*
(msisdn =msisdn)
+PK_cliente 1+FK_cliente_id_papel
0..*
(id_papel =id_papel)
+PK_papel1
+FK_admin_id_papel0..*
(id_papel =id_papel)
+PK_papel 1
76
ANEXO II – Script SQL para criação de Tabelas
Apresentação do Script SQL para criação das tabelas e relações da Base de Dados
Service_DB.
-- Server version: 5.1.31 -- -- Database: `service_db` -- CREATE TABLE `service_db`.`admin` ( `id_admin` int(10) unsigned NOT NULL, `nome` varchar(45) NOT NULL, `password` varchar(45) NOT NULL, `id_papel` int(10) unsigned NOT NULL, PRIMARY KEY (`id_admin`), KEY `FK_admin_id_papel` (`id_papel`), CONSTRAINT `FK_admin_id_papel` FOREIGN KEY (`id_papel`) REFERENCES `papel` (`id_papel`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`categoria` ( `id_categoria` int(10) unsigned NOT NULL AUTO_INCREMENT, `nome` varchar(45) NOT NULL, PRIMARY KEY (`id_categoria`) ) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`cliente` ( `msisdn` int(10) unsigned NOT NULL, `nome` varchar(25) NOT NULL, `maxServicos` int(10) unsigned NOT NULL, `password` varchar(45) NOT NULL, `id_papel` int(10) unsigned NOT NULL, PRIMARY KEY (`msisdn`), KEY `FK_cliente_id_papel` (`id_papel`), CONSTRAINT `FK_cliente_id_papel` FOREIGN KEY (`id_papel`) REFERENCES `papel` (`id_papel`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`cliente_zona` ( `msisdn` int(10) unsigned NOT NULL, `id_zona` int(10) unsigned NOT NULL, PRIMARY KEY (`msisdn`), KEY `FK_cliente_zona_id_zona` (`id_zona`), CONSTRAINT `FK_cliente_zona_id_zona` FOREIGN KEY (`id_zona`) REFERENCES `zona` (`id_zona`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `FK_cliente_zona_msisdn` FOREIGN KEY (`msisdn`) REFERENCES `cliente` (`msisdn`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`historico` ( `msisdn` int(10) unsigned NOT NULL, `id_servico` int(10) unsigned NOT NULL, `data_servico` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`msisdn`,`data_servico`), CONSTRAINT `FK_historico_msisdn` FOREIGN KEY (`msisdn`) REFERENCES `cliente` (`msisdn`) ON DELETE NO ACTION ON UPDATE NO ACTION ) ENGINE=InnoDB DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`interesse` ( `msisdn` int(10) unsigned NOT NULL,
77
`id_subcategoria` int(10) unsigned NOT NULL, PRIMARY KEY (`msisdn`,`id_subcategoria`), KEY `FK_interesse_id_subcategoria` (`id_subcategoria`), CONSTRAINT `FK_interesse_id_subcategoria` FOREIGN KEY (`id_subcategoria`) REFERENCES `subcategoria` (`id_subcategoria`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `FK_interesse_msisdn` FOREIGN KEY (`msisdn`) REFERENCES `cliente` (`msisdn`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`papel` ( `id_papel` int(10) unsigned NOT NULL AUTO_INCREMENT, `nome` varchar(45) NOT NULL, `vista_cliente` tinyint(1) NOT NULL, `vista_admin` tinyint(1) NOT NULL, `desregistado` tinyint(1) NOT NULL, PRIMARY KEY (`id_papel`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`servico` ( `id_servico` int(10) unsigned NOT NULL AUTO_INCREMENT, `nome` varchar(25) NOT NULL, `conteudo` text NOT NULL, PRIMARY KEY (`id_servico`) ) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`subcategoria` ( `id_subcategoria` int(10) unsigned NOT NULL AUTO_INCREMENT, `nome` varchar(25) NOT NULL, PRIMARY KEY (`id_subcategoria`) ) ENGINE=InnoDB AUTO_INCREMENT=53 DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`subcategoria_categoria` ( `id_subcategoria` int(10) unsigned NOT NULL, `id_categoria` int(10) unsigned NOT NULL, PRIMARY KEY (`id_subcategoria`), KEY `FK_categoria_subcategoria_id_subcategoria` (`id_subcategoria`), KEY `FK_categoria_subcategoria_id_categoria` (`id_categoria`), CONSTRAINT `FK_categoria_subcategoria_id_categoria` FOREIGN KEY (`id_categoria`) REFERENCES `categoria` (`id_categoria`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `FK_categoria_subcategoria_id_subcategoria` FOREIGN KEY (`id_subcategoria`) REFERENCES `subcategoria` (`id_subcategoria`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`subcategoria_servico` ( `id_servico` int(10) unsigned NOT NULL, `id_subcategoria` int(10) unsigned NOT NULL, PRIMARY KEY (`id_servico`,`id_subcategoria`), KEY `FK_subcategoria_servico_id_subcategoria` (`id_subcategoria`), CONSTRAINT `FK_subcategoria_servico_id_servico` FOREIGN KEY (`id_servico`) REFERENCES `servico` (`id_servico`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `FK_subcategoria_servico_id_subcategoria` FOREIGN KEY (`id_subcategoria`) REFERENCES `subcategoria` (`id_subcategoria`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`zona` ( `id_zona` int(10) unsigned NOT NULL AUTO_INCREMENT, `nome` varchar(50) NOT NULL, `latitude` double NOT NULL, `longitude` double NOT NULL, `raio` float unsigned NOT NULL, `precisao` float unsigned NOT NULL, `criteria` varchar(45) NOT NULL, `checkImmediate` varchar(45) NOT NULL, `durationUnits` int(10) unsigned NOT NULL,
78
`durationMetric` varchar(45) NOT NULL, `frequencyUnits` int(10) unsigned NOT NULL, `frequencyMetric` varchar(45) NOT NULL, `count` int(10) unsigned NOT NULL, PRIMARY KEY (`id_zona`) ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`zona_servico` ( `id_servico` int(10) unsigned NOT NULL, `id_zona` int(10) unsigned NOT NULL, PRIMARY KEY (`id_servico`,`id_zona`), KEY `FK_zona_servico_id_zona` (`id_zona`), CONSTRAINT `FK_zona_servico_id_servico` FOREIGN KEY (`id_servico`) REFERENCES `servico` (`id_servico`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `FK_zona_servico_id_zona` FOREIGN KEY (`id_zona`) REFERENCES `zona` (`id_zona`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
79
ANEXO III – Questionário
Questionário Aplicação Web Cliente
1. Sendo:
A – Muito Bom
B – Bom
C – Médio
D – Fraco
E – Muito Fraco
Defina a nota para cada item apresentado:
a) Facilidade de Utilização ( ) b) Apresentação ( ) c) Organização da Informação ( ) d) Coerência dos nomes de campos e títulos ( )