fornecimento de serviços push - fenix.tecnico.ulisboa.pt · ii resumo neste trabalho é...

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.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.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


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


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


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


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


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


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

http://en.wikipedia.org/wiki/UMTS

http://en.wikipedia.org/wiki/UMTS

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.


desenvolvimento da Componente Lógia e, posteriormente, serão descritos os detalhes de

implementação desta componente.


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


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.



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



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


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


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.


desenvolvimento da Componente de Apresentação e, posteriormente, serão descritos os

detalhes e opções de implementação tomadas para esta componente.

52


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..*


+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..*


+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`.àdmin` ( ìd_admin` int(10) unsigned NOT NULL, `nome` varchar(45) NOT NULL, `password` varchar(45) NOT NULL, ìd_papel` int(10) unsigned NOT NULL, PRIMARY KEY (ìd_admin`), KEY `FK_admin_id_papel` (ìd_papel`), CONSTRAINT `FK_admin_id_papel` FOREIGN KEY (ìd_papel`) REFERENCES `papel` (ìd_papel`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`categoria` ( ìd_categoria` int(10) unsigned NOT NULL AUTO_INCREMENT, `nome` varchar(45) NOT NULL, PRIMARY KEY (ìd_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, ìd_papel` int(10) unsigned NOT NULL, PRIMARY KEY (`msisdn`), KEY `FK_cliente_id_papel` (ìd_papel`), CONSTRAINT `FK_cliente_id_papel` FOREIGN KEY (ìd_papel`) REFERENCES `papel` (ìd_papel`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`cliente_zona` ( `msisdn` int(10) unsigned NOT NULL, ìd_zona` int(10) unsigned NOT NULL, PRIMARY KEY (`msisdn`), KEY `FK_cliente_zona_id_zona` (ìd_zona`), CONSTRAINT `FK_cliente_zona_id_zona` FOREIGN KEY (ìd_zona`) REFERENCES `zona` (ìd_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, ìd_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`.ìnteresse` ( `msisdn` int(10) unsigned NOT NULL,

77

ìd_subcategoria` int(10) unsigned NOT NULL, PRIMARY KEY (`msisdn`,ìd_subcategoria`), KEY `FK_interesse_id_subcategoria` (ìd_subcategoria`), CONSTRAINT `FK_interesse_id_subcategoria` FOREIGN KEY (ìd_subcategoria`) REFERENCES `subcategoria` (ìd_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` ( ìd_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 (ìd_papel`) ) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`servico` ( ìd_servico` int(10) unsigned NOT NULL AUTO_INCREMENT, `nome` varchar(25) NOT NULL, `conteudo` text NOT NULL, PRIMARY KEY (ìd_servico`) ) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`subcategoria` ( ìd_subcategoria` int(10) unsigned NOT NULL AUTO_INCREMENT, `nome` varchar(25) NOT NULL, PRIMARY KEY (ìd_subcategoria`) ) ENGINE=InnoDB AUTO_INCREMENT=53 DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`subcategoria_categoria` ( ìd_subcategoria` int(10) unsigned NOT NULL, ìd_categoria` int(10) unsigned NOT NULL, PRIMARY KEY (ìd_subcategoria`), KEY `FK_categoria_subcategoria_id_subcategoria` (ìd_subcategoria`), KEY `FK_categoria_subcategoria_id_categoria` (ìd_categoria`), CONSTRAINT `FK_categoria_subcategoria_id_categoria` FOREIGN KEY (ìd_categoria`) REFERENCES `categoria` (ìd_categoria`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `FK_categoria_subcategoria_id_subcategoria` FOREIGN KEY (ìd_subcategoria`) REFERENCES `subcategoria` (ìd_subcategoria`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`subcategoria_servico` ( ìd_servico` int(10) unsigned NOT NULL, ìd_subcategoria` int(10) unsigned NOT NULL, PRIMARY KEY (ìd_servico`,ìd_subcategoria`), KEY `FK_subcategoria_servico_id_subcategoria` (ìd_subcategoria`), CONSTRAINT `FK_subcategoria_servico_id_servico` FOREIGN KEY (ìd_servico`) REFERENCES `servico` (ìd_servico`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `FK_subcategoria_servico_id_subcategoria` FOREIGN KEY (ìd_subcategoria`) REFERENCES `subcategoria` (ìd_subcategoria`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`zona` ( ìd_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 (ìd_zona`) ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=latin1; CREATE TABLE `service_db`.`zona_servico` ( ìd_servico` int(10) unsigned NOT NULL, ìd_zona` int(10) unsigned NOT NULL, PRIMARY KEY (ìd_servico`,ìd_zona`), KEY `FK_zona_servico_id_zona` (ìd_zona`), CONSTRAINT `FK_zona_servico_id_servico` FOREIGN KEY (ìd_servico`) REFERENCES `servico` (ìd_servico`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `FK_zona_servico_id_zona` FOREIGN KEY (ìd_zona`) REFERENCES `zona` (ìd_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 ( )

fornecimento de serviços push - fenix.tecnico.ulisboa.pt · ii resumo neste trabalho é...

Documents