Monitorização de serviços baseada em contexto

Universidade do Minho

Escola de Engenharia Departamento de Inform´atica

Ricardo Emanuel Fernandes da Silva

Monitorizac¸ ˜ao de servic¸os

baseada em contexto

Universidade do Minho Escola de Engenharia Departamento de Inform´atica

Ricardo Emanuel Fernandes da Silva

Monitorizac¸ ˜ao de servic¸os

baseada em contexto

Dissertac¸˜ao de Mestrado

Mestrado em Engenharia Inform´atica

Trabalho realizado sobre a orientac¸˜ao de Professora Solange Rito Lima Professor Paulo Martins Carvalho

A G R A D E C I M E N T O S

Quero deixar um agradecimento especial `a minha orientadora Solange Rito Lima, ao meu co-orientador Paulo Martins de Carvalho e ao professor Jo˜ao Marco Silva pelo apoio pres-tado ao longo do desenvolvimento desta dissertac¸˜ao.

Um agradecimento `a Universidade do Minho, em especial ao Departamento de Inform´ati-ca, pelos servic¸os prestados ao longo da minha formac¸˜ao.

Quero agradecer tamb´em aos amigos que c´a fiz, que sempre me apoiaram e aos amigos de sempre por me ajudarem ao longo deste percurso.

Por fim, quero deixar um agradecimento muito especial `a minha namorada e `a minha fam´ılia que sempre me apoiaram ao longo do meu percurso acad´emico.

A B S T R A C T

Network monitoring is an essential task in the management and engineering of current communications networks. The configuration of a network monitoring system should con-sider the measurement requirements of a network task and the corresponding measurement parameters. This may share common needs of the infrastructure measurement, but with specific characteristics according to the type of service provided and resources involved. For example, measuring the volume of network traffic has different measurement require-ments from Distributed Denial-of-Service attacks detection. Similarly, the parameters and temporal requirements for measuring data and video services are different. Thus, it is es-sential to have a global view of the distinct aspects related to service monitoring for a better understanding of its key points, and promote the quality of services provided. Context-awareness is therefore an important aspect in the monitoring of self-configurable network services.

The theme of this work falls within the context described above as it will be studied and defined a monitoring model of services based on context. The main objective is related to the identification of the requirements and architecture for a context-aware monitoring system. Therefore, it is intended to identify and evaluate appropriate technologies to deal with the development of an ontology which aims at assisting a sampling-based monitoring system. Finally, after studying existing technologies and methods, an ontological system is developed using the selected technology that forms the basis of a monitoring system based on sampling and context.

R E S U M O

A monitorizac¸˜ao de redes ´e uma tarefa essencial na gest˜ao e engenharia das redes de comunicac¸ ˜oes atuais. A configurac¸˜ao de um sistema de monitorizac¸˜ao de rede deve consi-derar as exigˆencias da tarefa de rede a medir e os parˆametros de medic¸˜ao correspondentes, compartilhando algumas necessidades comuns na medic¸˜ao de infraestruturas, mas com especificidades de acordo com o tipo de servic¸o prestado e recursos envolvidos. Por exem-plo, medir o volume de tr´afego da rede tem requisitos de medic¸˜ao distintos da detec¸˜ao de ataques Distributed Denial-of-Service. Da mesma forma, os parˆametros e as exigˆencias temporais para medir servic¸os de dados e v´ıdeo s˜ao diferentes. Assim, ´e essencial ter uma vis˜ao global dos distintos aspetos relacionados com a monitorizac¸˜ao de servic¸os para uma melhor compreens˜ao dos pontos-chave e promover a qualidade dos servic¸os prestados. A consciˆencia do contexto ´e, portanto, um aspeto importante nos sistemas de monitorizac¸˜ao de servic¸os auto-configur´aveis.

O tema desta dissertac¸˜ao enquadra-se no contexto anteriormente descrito na medida em que vai ser estudado e definido um modelo de monitorizac¸˜ao de servic¸os baseados em contexto. O objetivo principal prende-se com a identificac¸˜ao dos requisitos e arquitetura necess´arios num sistema de monitorizac¸˜ao baseado em contexto. Por conseguinte, pretende-se identificar e avaliar tecnologias apropriadas para lidar com o depretende-senvolvimento de uma ontologia que visa apoiar um sistema de monitorizac¸˜ao baseado em amostragem. Por fim, ap ´os o estudo dos m´etodos e tecnologias existentes, um sistema ontol ´ogico ´e desenvolvido utilizando a tecnologia selecionada que forma a base de um sistema de monitorizac¸˜ao baseado em amostragem e contexto.

C O N T E ´U D O 1 i n t r o d u c¸ ˜ao 1 1.1 Enquadramento 1 1.2 Motivac¸˜ao e Objetivos 2 1.3 Estrutura da Dissertac¸˜ao 3 2 t r a b a l h o r e l a c i o na d o 4 2.1 Monitorizac¸˜ao e Amostragem 4 2.1.1 Metodologias de medic¸˜ao 5 2.1.2 T´ecnicas de amostragem 5

2.2 Conceito de contexto na ´area de redes 7

2.2.1 Definic¸˜ao de contexto 7

2.2.2 Carater´ısticas do contexto 8

2.2.3 Ciclo de vida do contexto 10

2.2.4 Generalizac¸˜ao da definic¸˜ao de um sistema baseado em contexto 10

2.3 Ontologias para a representac¸˜ao de contexto 11

2.3.1 Definic¸˜ao de ontologia 11

2.3.2 Vantagens do uso de ontologias 13

2.3.3 Como ´e constru´ıda uma ontologia 14

2.3.4 Como ´e organizada uma ontologia 15

2.4 Frameworks baseadas em contexto 15

2.4.1 Definic¸˜ao de Framework 15

2.4.2 Ektara 16

2.4.3 Stick-e Notes 16

2.4.4 Sulawesi 16

2.4.5 CALAIS 17

2.4.6 Schilit’s System Architecture 17

2.5 Arquiteturas de middleware baseadas em contexto 19

2.5.1 Definic¸˜ao de Middleware 19

2.5.2 Representac¸˜ao gen´erica de um middleware 20

2.5.3 Acoms+ 20 2.5.4 Carisma 21 2.5.5 MOCA 21 2.5.6 CA4IOT 22 2.5.7 CASF 23 2.5.8 COCAMAAL 23

CONTE ´UDO 2.5.9 SECOMAN 24 2.6 Outras iniciativas 25 2.6.1 Context Toolkit 25 2.6.2 Aura 26 2.6.3 COBRA 27 2.6.4 Gaia 27 2.6.5 SOCAM 27 2.6.6 HCOM 28 2.6.7 Campus 28 2.6.8 CAMPH 29

2.7 Comparac¸˜ao de arquiteturas de middleware baseadas em contexto 30

2.8 Sum´ario 31

3 d e f i n i c¸ ˜ao de uma arquitetura baseada em contexto 32

3.1 Arquitetura de medic¸˜ao baseada em amostragem 32

3.1.1 Descric¸˜ao do funcionamento 33

3.2 Arquitetura de monitorizac¸˜ao baseada em contexto 34

3.3 Area de Intervenc¸˜ao´ 35 3.3.1 Exemplificac¸˜ao 35 3.4 Tecnologias Previstas 36 3.5 Sum´ario 36 4 d e f i n i c¸ ˜ao da ontologia 37 4.1 Modelo Conceptual 37 4.2 Perguntas de Competˆencia 39 4.3 Representac¸˜ao da Ontologia 40 4.4 Descric¸˜ao da Ontologia 41 4.4.1 Classes 42 4.4.2 Propriedades do Objecto 44 4.4.3 Atributos 47 4.4.4 Indiv´ıduos 52 4.5 Sum´ario 54 5 c a s o s d e e s t u d o 55 5.1 Respostas da ontologia 55 5.2 Accounting 64 5.3 Classificac¸˜ao de Tr´afego 70 5.4 Sum´ario 71

6 c o n c l u s˜oes e trabalho futuro 72

6.1 Conclus˜ao do Trabalho 72

CONTE ´UDO

L I S TA D E F I G U R A S

Figura 2.1 Exemplo de amostragem sistem´atica count-based 6

Figura 2.2 Exemplo de amostragem sistem´atica time-based 6

Figura 2.3 Ciclo de vida do contexto[1] 10

Figura 2.4 Exemplo de uma ontologia representada em esquema 12

Figura 2.5 Exemplo de uma ontologia representada graficamente 13

Figura 2.6 Carater´ısticas das frameworks baseadas em contexto [2] 18

Figura 2.7 Exemplo de onde atua um middleware [3] 19

Figura 2.8 Arquitetura gen´erica de um middleware [4] 20

Figura 2.9 Arquitetura de um Sistema baseado em contexto ACOMS [5] 21

Figura 2.10 Arquitetura do middleware CA4IOT [6] 22

Figura 2.11 Arquitetura do middleware CASF[1] 23

Figura 2.12 Arquitetura do middleware SECOMAN [7] 25

Figura 2.13 Exemplo de configurac¸˜ao dos componentes do ContextToolkit [8] 26

Figura 2.14 Arquitetura Aura [8] 26

Figura 2.15 Arquitetura SOCAM [9] 28

Figura 2.16 Arquitetura CAMPUS [10] 29

Figura 2.17 Arquitetura e implementac¸˜ao do modelo CAMPH [5] 30

Figura 2.18 Classificac¸˜ao de Sistemas de middleware Context-Aware [1] 31

Figura 3.1 Descric¸˜ao da arquitetura[11] 33

Figura 3.2 Exemplo da arquitetura de monitorizac¸˜ao 34

Figura 3.3 Exemplo da tarefa Accounting 35

Figura 4.1 Modelo conceptual da ontologia 38

Figura 4.2 Modelo de classes da ontologia 40

Figura 4.3 Modelo de classes da ontologia 41

Figura 4.4 Classe Management Task 44

Figura 4.5 Propriedade objecto hasBandwidth 47

Figura 4.6 Atributo currentCpuLoad 52

Figura 4.7 Indiv´ıduo MeasurementPoint1 53

Figura 5.1 Estrutura gen´erica de uma query em SPARQL 56

Figura 5.2 Output da Query 1 57

Figura 5.3 Output da Query 2 57

Figura 5.4 Output da Query 3 58

LISTA DE FIGURAS

Figura 5.6 Output da Query 5 60

Figura 5.7 Output da Query 6 60

Figura 5.8 Output da Query 7 61

Figura 5.9 Output da Query 8 62

Figura 5.10 Output da Query 9 63

Figura 5.11 Output da Query 10 64

Figura 5.12 Especificac¸˜ao da tarefa accounting 64

Figura 5.13 Comparac¸˜ao da utilizac¸˜ao dos requisitos computacionais 65

Figura 5.14 Output da Query 11 66

Figura 5.15 Output da Query 12 67

Figura 5.16 Output da Query 13 68

Figura 5.17 Output da Query 14 69

Figura 5.18 Output da Query 15 70

L I S TA D E A C R ´O N I M O S

ACOMS Automatic Context Management System API Application Programming Interface

ARM Advanced Risc Machines

AURA Aware Energy Management Framework BSN Body Sensor Network

BTC Bulk Transfer Capacity

CA4IOT Context Awareness for Internet Of Things CAIM Context-Aware Interaction Manager

CAMPH Context-Aware Middleware for Pervasive Homecare

CAMPUS Context-Aware Middleware for Pervasive and Ubiquitous Service CARISMA Context-Aware Reflective Middleware

CASF Context-Aware Services Framework CEI Common Event Infrastructure

CIS Context Information Service CMN Context Management Node COBRA Context Broker Arquitecture

COCAMAAL Cloud Oriented Context-Aware Middleware in Ambient Assisted Living CORBA Common Object Request Broker Arquitecture

CPU Central Processing Unit DDoS Distributed Denial Of Service DPI Deep Packet Inspection

ERP Enterprise Resource Planning ESN Environmental Sensor Network GPS Global Positioning System HCOM Hybrid Context Management IETF Internet Enginnering Task Force IOT Internet Of Things

IP Internet Protocol

IPDV IP Packet Delay Variation

IPFIX Internet Protocol Flow Information Export IPLR IP Packet Loss Ratio

IPTD IP Packet Transfer Delay ISP Internet Service Provider

JCAF Java Context-Awareness Framework LP Adaptive Linear Prediction

MHz Megahertz

MOCA Mobile Collaboration Arquitecture MUST Multiadaptive Sampling

OSI Open Systems Interconnection OSN Object Sensor Network OWL Web Ontology Language PARC Palo Alto Research Center PCE Perceptual Context Engine PIA Percentage IP Service Availability PIU Percentage IP Service Unavailability QoC Quality of Context

QoS Quality of Service RAM Random Acess Memory RandC Random Count-based RCDB Relational Context Database RDF Resource Description Framework RFID Radio Frequency Identification RTT Round-Trip Time

SECOMAN Sematic web-based Context Management SOCAM Service Oriented Context-Aware Middleware SPARQL SPARQL Protocol and RDF Query Language SQL Structured Query Language

SystC Systematic Count-based SystT Systematic Time-based TCP Transmission Control Protocol TEA Technology for Enabling Awareness URL Uniform Resource Location

UWC Ubiquitous and Wearable Computing XML Extensible Markup Language

1

I N T R O D U C¸ ˜A O

1.1 e n q ua d r a m e n t o

Os sistemas de gest˜ao de redes tˆem vindo a ter um papel muito importante nas ´areas das tecnologias das comunicac¸ ˜oes, assim como das tecnologias da informac¸˜ao. Ao longo dos anos, as redes tˆem crescido n˜ao s ´o ao n´ıvel do tamanho, como ao n´ıvel tecnol ´ogico. Devido a esta evoluc¸˜ao, o processo de gest˜ao de redes torna-se mais complexo e rigoroso [12].

A diversidade do tr´afego e volume de dados que circulam nas redes tamb´em est˜ao em constante crescimento. Com esse crescimento, as redes de computadores tornaram-se mais extensas e ao mesmo tempo mais complexas o que obriga a uma evoluc¸˜ao/melhoria nos equipamentos de monitorizac¸˜ao e an´alise dos dados. Haver a noc¸˜ao de que tipo de aplicac¸ ˜oes s˜ao mais utilizadas, quem utiliza essas aplicac¸ ˜oes e com que fins, s˜ao raz ˜oes que levam a que hoje em dia haja um maior controlo sobre o tr´afego na Internet. Deste modo, um aspeto bastante importante e uma das preocupac¸ ˜oes constantes das empresas est´a relacionado com a monitorizac¸˜ao, gest˜ao das redes e servic¸os. Estas atividades permi-tem aos ISPs (Internet Service Providers) e at´e mesmo a outras entidades verificarem se as condic¸ ˜oes do contrato de servic¸o com o cliente est˜ao a ser cumpridas e dessa maneira, em caso de violac¸˜ao da Qualidade de Servic¸o (QoS), atuar conforme a violac¸˜ao do acordado. Pode ser tamb´em uma atividade importante na detec¸˜ao de ataques DOS (Denied-of-Service Attacks) ou na recolha de informac¸˜ao para tomadas de decis˜ao a m´edio e longo prazo [13].

A monitorizac¸˜ao do tr´afego nas redes ´e crucial no sentido de contabilizar o consumo de dados, assim como garantir o desempenho dessas mesmas redes ao n´ıvel da fiabilidade, as-sim como da QoS. Devido ao constante aumento do volume de dados, ´e essencial agilizar o processo de monitorizac¸˜ao n˜ao colocando em causa a sua eficiˆencia, assim como satisfazer as necessidades dos utilizadores e administradores de rede.

A utilizac¸˜ao de servic¸os baseados em contexto surge como uma soluc¸˜ao para melhorar o processo de monitorizac¸˜ao das redes.

Um sistema pode utilizar informac¸ ˜oes de contexto importantes e disponibilizar servic¸os personalizados e otimizados por forma a satisfazer as necessidades dos utilizadores. Com este tipo de servic¸os ´e poss´ıvel poupar recursos, como, por exemplo, energia,

processa-1.2. Motivac¸˜ao e Objetivos

mento e comunicac¸˜ao, criando assim disponibilidade para servic¸os mais relevantes e ´ageis [14]. Nos servic¸os baseados em contexto ´e importante a representac¸˜ao do contexto e a

qua-lidade do contexto (QoC), uma vez que as informac¸ ˜oes de contexto podem muitas vezes n˜ao ser as mais corretas ou ´uteis. Ao n´ıvel da inferˆencia de contexto, ser capaz de infe-rir contexto ´e crucial para determinar os valores para um determinado contexto. Inferˆencia tamb´em ´e usada para examinar axiomas, e inferir novo contexto, se este n˜ao est´a dispon´ıvel. Em termos de requisitos de representac¸˜ao de contexto, v´arias considerac¸ ˜oes devem ser levadas em conta ao selecionar as tecnologias que podem satisfazer os requisitos de um processador de contexto. A escolha de como armazenar, representar e inferir contexto num processador de contexto s˜ao requisitos importantes para o funcionamento de um middleware baseado em contexto [15].

O uso de ontologias surge na abordagem de representac¸˜ao de contexto, uma vez que se destacam na interac¸˜ao entre os utilizadores e a m´aquina, al´em de permitir a reutilizac¸˜ao de informac¸˜ao o que facilita o processo de representar a informac¸˜ao.

1.2 m o t i va c¸ ˜ao e objetivos

Com o constante aumento do volume de dados compartilhados nas redes de computado-res ´e essencial melhorar as ferramentas de monitorizac¸˜ao e ao mesmo tempo agilizar os m´etodos de monitorizac¸˜ao das redes, por forma a garantir o bom desempenho das redes, assim como satisfazer as necessidades dos utilizadores.

A implementac¸˜ao de um sistema ontol ´ogico mostra-se ent˜ao como uma soluc¸˜ao neste ˆambito. A an´alise das tecnologias dispon´ıveis para armazenar e representar contexto ´e uma abordagem recomend´avel por forma a selecionar a tecnologia mais eficiente para os requisitos de uma ontologia na ´area da monitorizac¸˜ao.

Este trabalho de mestrado tem como objetivo principal a definic¸˜ao de um modelo de monitorizac¸˜ao de servic¸os baseado em contexto. Este modelo assenta numa arquitetura de

monitorizac¸˜ao baseada em amostragem de tr´afego proposta em3.1Desta forma, definem-se

como objetivos a atingir os seguintes aspectos:

• identificar os requisitos e a arquitetura de um sistema de monitorizac¸˜ao baseado em contexto;

• avaliar cada uma das tecnologias existentes, relativamente aos requisitos da ontologia que se pretende criar;

• desenvolver um sistema ontol ´ogico usando a tecnologia selecionada, que seja a base de um sistema de monitorizac¸˜ao baseado em contexto.

1.3. Estrutura da Dissertac¸˜ao

1.3 e s t r u t u r a d a d i s s e r ta c¸ ˜ao

A estrutura desta dissertac¸˜ao est´a organizada em 6 cap´ıtulos. A descric¸˜ao sum´aria de cada um dos cap´ıtulos ´e a seguinte:

Cap´ıtulo 1: no presente cap´ıtulo apresenta-se o enquadramento e a contextualizac¸˜ao do trabalho. Apresenta-se tamb´em a motivac¸˜ao que originou o desenvolvimento deste trabalho, assim como os respetivos objetivos que se pretendem atingir.

Cap´ıtulo 2: neste cap´ıtulo ´e feita uma abordagem ao estado da arte na ´area da

monitorizac¸˜ao baseada em contexto. ´E apresentada a noc¸˜ao de contexto na ´area das redes, a definic¸˜ao de monitorizac¸˜ao e amostragem de tr´afego. S˜ao apresentadas v´arias ferramentas de monitorizac¸˜ao ( frameworks e arquiteturas de middleware) que se baseiam em contexto, assim como abordagens existentes na ´area da monitorizac¸˜ao e respetivas comparac¸ ˜oes.

Cap´ıtulo 3: neste cap´ıtulo ´e considerada uma arquitetura baseada em contexto, assim como ´e proposta uma arquitetura de monitorizac¸˜ao modelo para implementar num sis-tema de monitorizac¸˜ao baseado em contexto. S˜ao apresentadas as tecnologias previstas na implementac¸˜ao desse mesmo sistema.

Cap´ıtulo 4: neste cap´ıtulo ´e apresentada a definic¸˜ao da ontologia desenvolvida, assim como uma descric¸˜ao pormenorizada da mesma.

Cap´ıtulo 5: neste cap´ıtulo s˜ao apresentadas quest ˜oes que a ontologia tem por base res-ponder, assim como resultados para casos de estudo particulares.

Cap´ıtulo 6:neste cap´ıtulo s˜ao apresentadas as principais conclus ˜oes resultantes do traba-lho realizado, assim como ´e feita uma an´alise ao trabatraba-lho futuro associado a este trabatraba-lho.

2

T R A B A L H O R E L A C I O N A D O

Neste cap´ıtulo ser˜ao descritos os conceitos relacionados com a

monitorizac¸˜ao e amostragem de tr´afego, contexto na ´area da gest˜ao de redes, representac¸˜ao de contexto atrav´es de ontologias, arquiteturas de framework e de middleware que se baseiam em contexto. Estes conceitos s˜ao muito relevantes para o desenvolvimento futuro do traba-lho, assim como para adquirir sensibilidade e conhecimentos no campo da monitorizac¸˜ao baseada em contexto.

2.1 m o n i t o r i z a c¸ ˜ao e amostragem

Os sistemas de gest˜ao de redes ganharam um papel de extrema importˆancia nas ´areas das tecnologias de informac¸˜ao e comunicac¸˜ao. Com o crescimento das redes em dimens˜ao, inovac¸˜ao tecnol ´ogica e heterogeneidade, todo o processo de gest˜ao de redes torna-se mais complexo e exigente. A implementac¸˜ao de sistemas de gest˜ao de redes mais eficientes e ao mesmo tempo com custos comport´aveis, tornou-se essencial, de modo a garantir, tarefas como qualidade de servic¸o, detec¸˜ao e prevenc¸˜ao de falhas, classificac¸˜ao de tr´afego, gest˜ao e atualizac¸˜ao das configurac¸ ˜oes de rede e de equipamentos, caraterizac¸˜ao de tr´afego entre outras.

Com o crescimento constante da diversidade e do volume de dados que circulam nas redes existe a necessidade de contabilizar o consumo de recursos, a carga na rede, as aplicac¸ ˜oes mais usadas, quem as usa e para que finalidade, por forma a garantir fiabili-dade e elevada qualifiabili-dade de servic¸o.

Para que as ferramentas de an´alise e classificac¸˜ao de dados possam lidar com tais quan-tidades de dados e ao mesmo tempo garantir a qualidade e o bom funcionamento dos servic¸os, ´e preciso que implementem de forma escal´avel e fi´avel as diferentes t´ecnicas de classificac¸˜ao de tr´afego. No entanto, devido ao crescimento do volume de tr´afego nas re-des torna-se incomport´avel analisar o tr´afego da rede na sua totalidade, sendo necess´ario conjugar mecanismos de classificac¸˜ao de tr´afego com mecanismos de amostragem.

A amostragem de tr´afego consiste em selecionar um subconjunto de pacotes do tr´afego total, de modo, a que se consiga efetuar estimativas sobre o comportamento da rede

evi-2.1. Monitorizac¸˜ao e Amostragem

tando verificar o seu tr´afego total. No entanto, esta diminuic¸˜ao na captura de volume de dados pode influenciar a acur´acia dos resultados.

Na selec¸˜ao dos pacotes que v˜ao formar a amostra de tr´afego pode ser tido em conta a posic¸˜ao do pacote, o conte ´udo, o tempo relativo ou absoluto de chegada ou uma combinac¸˜ao destes crit´erios [12] [16] [17].

2.1.1 Metodologias de medic¸˜ao

Na monitorizac¸˜ao existem algumas metodologias de medic¸˜ao distintas, nomeadamente ati-vas e passiati-vas.

Medic¸˜ao Ativa

A metodologia ativa consiste na utilizac¸˜ao de tr´afego intrusivo atrav´es da injec¸˜ao de paco-tes de prova (probes) na rede com o objetivo de fazer a medic¸˜ao de tr´afego. Esta metodologia possui como vantagem o c´alculo de QoS e a versatilidade. Contudo ´e preciso controlar o overhead do tr´afego de prova com vista a n˜ao causar interferˆencia no funcionamento normal da rede.

Medic¸˜ao Passiva

A metodologia passiva consiste em recorrer apenas ao tr´afego real da rede para efetuar a medic¸˜ao. Esta metodologia possui a vantagem de n˜ao existir intrus˜ao mas o volume de dados envolvidos ´e consider´avel, podendo ser intrat´avel.

Em combinac¸˜ao com este tipo de metodologias existem algumas t´ecnicas de medic¸˜ao, que se adequam a certos cen´arios e condic¸ ˜oes. Podemos ter a monitorizac¸˜ao a ocorrer local-mente (ex. software: SysStat), remotalocal-mente (ex. software: Nagios, Cacti, Ground Work) ou atrav´es de plataformas de gest˜ao Web (ex. RightScale, LandScape, Amazon CloudWatch, entre outras disponibilizadas por um conjunto de companhias de Cloud Monitoring).

2.1.2 T´ecnicas de amostragem

Amostragem Sistem´atica

Na amostragem sistem´atica o mecanismo de selec¸˜ao de pacotes tem o seu in´ıcio e fim definidos por uma func¸˜ao determin´ıstica [18]. A func¸˜ao determin´ıstica utilizada tem em

considerac¸˜ao a posic¸˜ao do pacote count-based ou o tempo de chegada do pacote time based [17].

2.1. Monitorizac¸˜ao e Amostragem

• count-based: esta t´ecnica permite definir um intervalo entre o in´ıcio e o fim de uma amostra tendo em conta a posic¸˜ao espacial dos pacotes, utilizando contadores para

obter essas mesmas posic¸ ˜oes. Como exemplo, a Figura2.1apresenta os pacotes que

ser˜ao considerados na amostra selecionada onde se captura um pacote a cada trˆes pacotes que chegam ao ponto de medic¸˜ao [17].

Figura 2.1: Exemplo de amostragem sistem´atica count-based

• time-based: esta t´ecnica consiste em selecionar os pacotes que fazem parte da amostra atrav´es do seu tempo de chegada ao ponto de medic¸˜ao. Neste caso, ´e definido um

intervalo de tempo para a amostragem e o per´ıodo entre as amostras [17]. A Figura

2.2 mostra a selec¸˜ao de amostras que devem iniciar a cada 10 milissegundos e tˆem

uma durac¸˜ao de 5 milissegundos.

Figura 2.2: Exemplo de amostragem sistem´atica time-based

Amostragem Aleat´oria

As t´ecnicas de amostragem aleat ´oria selecionam os pacotes de forma, a evitar as tendˆencias pr ´oprias dos processos sistem´aticos. Assim sendo, o ponto de in´ıcio do intervalo de amos-tragem ´e calculado por uma func¸˜ao aleat ´oria[17]. Existem dois m´etodos, o n-out-of-N e a

amostragem probabil´ıstica que s˜ao definidos em [18].

• n-out-of-N: neste m´etodo s˜ao selecionados n pacotes aleatoriamente de um sequˆencia de tr´afego de dimens˜ao N pacotes. Um exemplo deste m´etodo ´e a gerac¸˜ao aleat ´oria de um n ´umero n de pacotes num dado intervalo [1,N]. Posteriormente, s˜ao escolhidos os pacotes cujas posic¸ ˜oes correspondem aos n ´umeros gerados aleatoriamente. Neste

tipo de amostragem o tamanho da amostra ´e sempre fixo (n) [17].

• Probabil´ıstico: neste m´etodo a selec¸˜ao ou a n˜ao selec¸˜ao de um pacote para a amos-tra est´a dependente de uma probabilidade pr´e-definida. Um exemplo deste m´etodo, pode ser o lanc¸amento de uma moeda ao ar, onde s˜ao capturados os pacotes cujo o

2.2. Conceito de contexto na ´area de redes

lado da moeda for ”cara”[18]. Nas t´ecnicas probabil´ısticas os pacotes podem ter

pro-babilidades variadas de selec¸˜ao (amostragem probabil´ıstica n˜ao uniforme ou amostragem probabil´ıstica uniforme[17] [18]).

Amostragem Adaptativa

Este m´etodo de amostragem tenta presumir qual o comportamento futuro da rede baseando-se numa propriedade verificada em amostras anteriores. Com este tipo de funcionamento, se uma previs˜ao se verificar correta, ent˜ao a taxa de amostragem pode ser reduzida, caso contr´ario, se a previs˜ao n˜ao for a mais correta, quer dizer que houve alguma mudanc¸a no comportamento da rede. Neste caso ´e preciso aumentar a taxa de amostragem por forma a encontrar um novo padr˜ao [17] [19].

2.2 c o n c e i t o d e c o n t e x t o na ´area de redes

2.2.1 Definic¸˜ao de contexto

O contexto ´e a fonte de conhecimento fundamental para os sistemas alcanc¸arem a consciˆencia de contexto. O Dicion´ario Oxford d´a uma definic¸˜ao geral para o contexto como ”as cir-cunstˆancias que formam o cen´ario para um evento, declarac¸˜ao ou ideia e em termos do qual ele pode ser plenamente compreendido”. No entanto, muitos investigadores tentam definir contexto `a sua maneira, dependendo das necessidades e ambiente em causa, por exemplo:

O contexto ´e :

• ”... o conjunto de localizac¸˜ao, as identidades de pessoas pr ´oximas e objetos e alterac¸ ˜oes a esses objetos.”[20]

• ”... a localizac¸˜ao, as identidades das pessoas pr ´oximas do utilizador, a hora do dia, estac¸˜ao, temperatura, etc.”[21]

• ”... a combinac¸˜ao da localizac¸˜ao do utilizador, ambiente, a identidade e tempo.”[22]

• ”... o que est´a a acontecer neste momento.”[23]

• ”... o estado do ambiente da aplicac¸˜ao.”[24]

• ”... apenas os aspectos de uma situac¸˜ao atual.”[25]

• ”... que se estende para modelar as atividades e tarefas que est˜ao a ocorrer num local.”[26]

2.2. Conceito de contexto na ´area de redes

• o conjunto de circunstˆancias que rodeiam uma aplicac¸˜ao e que s˜ao relevantes para a sua conclus˜ao.”[27]

• ”... qualquer informac¸˜ao que pode ser usada para caracterizar a situac¸˜ao de entidades (ou seja, se uma pessoa, lugar ou objeto) s˜ao considerados relevantes para a interac¸˜ao entre um utilizador e um programa, incluindo o utilizador e a aplicac¸˜ao. O contexto ´e tipicamente a localizac¸˜ao, identidade e estado de pessoas, grupos computacionais e objetos f´ısicos.”[28]

Resumindo o contexto ´e qualquer subconjunto de informac¸˜ao que pode representar mudanc¸as da circunstˆancia (est´aticas ou dinˆamicas). Al´em disso, pode ser ´util para a com-preens˜ao da situac¸˜ao atual e previs˜ao de poss´ıveis mudanc¸as.

2.2.2 Carater´ısticas do contexto

´E poss´ıvel que diferentes tipos de contexto partilhem v´arias caracter´ısticas, em certa me-dida. Uma obtenc¸˜ao clara e precisa do contexto apresenta vantagens para os utilizadores. Um utilizador ter uma melhor percec¸˜ao das caracter´ısticas do contexto de modo a que as limitac¸ ˜oes de contexto possam ser minimizadas, ou ocultas se poss´ıvel. Van Bunningen et al. [29] identificaram oito caracter´ısticas do contexto: ´e obtido atrav´es de sensores ou redes

individuais (1); ´e detetado por dispositivos pequenos e restritos (2); ´e originado a partir de fontes distribu´ıdas (3); sofre alterac¸ ˜oes constantemente (4); prov´em de objetos m ´oveis (5); ´e temporal (6); ´e espacial (7); o car´acter espacial e temporal ´e indeterminado (8).

As caracter´ısticas de contexto resumem-se em cinco:

• Fontes de contexto • Dom´ınio do contexto • Diversidade de contexto • Validade do contexto temporal • Versatilidade de contexto Fontes de contexto

Contexto pode ser obtido a partir de diversas fontes. Geralmente, a obtenc¸˜ao de contexto pode ser classificada em hardware e fontes virtuais. Em termos de hardware, o contexto pode ser monitorizado e recolhido por uma variedade de dispositivos de detec¸˜ao. A maioria do contexto f´ısico ´e obtido por meio de sensores ou redes de sensores. O desenvolvimento de hardware tem vindo a mudar ao ponto de ser mais pequeno e barato. Com isto, pode

2.2. Conceito de contexto na ´area de redes

haver limitac¸ ˜oes ao n´ıvel da capacidade de armazenamento e da capacidade de computac¸˜ao. A capacidade da bateria ´e deve ser aumentada por forma a suportar uma vida mais longa do trabalho.

O contexto pode ser adquirido manualmente ou resultante de fontes virtuais, tais como agentes de contexto, servidores de contexto, m ´odulos de middleware, big data, etc.

Dom´ınio do contexto

O dom´ınio de tipos de contexto e os dados de contexto n˜ao est˜ao restritos a uma capacidade definida. Ou seja, tˆem um extenso dom´ınio e s˜ao dinˆamicos, tendo em conta os cen´arios em causa. Por exemplo, um conjunto de informac¸ ˜oes, incluindo luminosidade, temperatura e humidade pode ser recolhido como contexto num cen´ario de avaliac¸˜ao Passive House (casas amigas do ambiente). No entanto, essa mesma informac¸˜ao de contexto poderia ter importˆancia distinta em ambientes diferentes. Devido ao fato de os dados do contexto serem imensos em nome das mudanc¸as que refletem, os interesses levantados s˜ao de carga de computac¸˜ao e armazenamento .

Diversidade de contexto

O contexto pode ter um conjunto muito ampliado de alternativas. Contexto diferente pode contemplar, ou mesmo alterar, os mesmos t ´opicos semelhantes de um estado atual de modo a obter uma grande agilidade para que o utilizador possa decidir o contexto mais correto a usar em determinada situac¸˜ao. Por exemplo, tanto o nome, morada e as coordenadas de latitude e longitude podem registar a localizac¸˜ao de uma pessoa. No entanto, estes dados resultam numa preocupac¸˜ao extra: redundˆancia de contexto. A redundˆancia de contexto aumentando ir´a facilitar o caminho para melhorar a eficiˆencia da capacidade de computac¸˜ao, aumentar capacidade de armazenamento e refinar algoritmos de filtragem de contexto, etc.

Validade do contexto temporal

A maioria do contexto ´e caracterizado como dinˆamico. Num contexto dinˆamico, os valores dos dados de contexto apenas s˜ao ´uteis por um pequeno espac¸o de tempo. Posteriormente, s˜ao substitu´ıdos por novos valores. Por exemplo, as coordenadas de GPS em tempo real s˜ao o ´unico dado que ´e significativo para localizac¸˜ao de um telem ´ovel.

Versatilidade de contexto

O contexto ´e sens´ıvel a objetos m ´oveis (ou pessoas). Por exemplo, uma pessoa deslocar-se de um espac¸o para outro, ´e um comportamento habitual. Os dados de contexto s˜ao recolhidos dos objetos m ´oveis e apresentam as suas alterac¸ ˜oes. Desta maneira, um sistema

2.2. Conceito de contexto na ´area de redes

est´a preparado para regular o seu comportamento para um determinado cen´ario. Ou seja, o contexto ´e obtido a partir de objetos m ´oveis, e ´e utilizado para caraterizar esses mesmos objetos.

2.2.3 Ciclo de vida do contexto

A implementac¸˜ao de arquiteturas sens´ıveis ao contexto cumprem uma regra geral inde-pendentemente dos componentes e m ´odulos de contexto diferenciados que utilizam na gest˜ao do contexto, que ´e o ciclo de vida do contexto. A vida do contexto, que ´e o inter-valo de tempo entre a sua obtenc¸˜ao e eliminac¸˜ao, est´a circunscrita a seis acontecimentos significativos como aquisic¸˜ao de contexto, modelac¸˜ao de contexto, racioc´ınio de contexto, distribuic¸˜ao de contexto, reposit ´orio de contexto e visualizac¸˜ao de contexto, como ilustrado

na Figura 2.3. A forma para adquirir conhecimento de contexto comec¸a com a aquisic¸˜ao

de v´arios tipos de contexto, seguido pelo processo de formalizac¸˜ao e inferˆencia, e, final-mente, acaba com a distribuic¸˜ao de contexto ´util para as aplicac¸ ˜oes correspondentes. Na fase de modelac¸˜ao de contexto e de racioc´ınio, os dados considerados de contexto devem ser gravados para utilizac¸˜ao posterior ou consultas, podendo tamb´em ser visualizados pe-los utilizadores. Na figura que se segue, as fases principais do ciclo de vida s˜ao descritas em detalhe.

Figura 2.3: Ciclo de vida do contexto[1]

2.2.4 Generalizac¸˜ao da definic¸˜ao de um sistema baseado em contexto

Um sistema ´e context-aware se ele usa contexto para fornecer informac¸ ˜oes e/ou servic¸os relevantes para o utilizador, onde a relevˆancia depende da tarefa do utilizador. Pode ser visto como geral e preciso o suficiente, que se adapta a qualquer programa de reconheci-mento de contexto e, portanto, compartilhada neste papel. Um sistema sens´ıvel ao contexto

´e geralmente projetado para um prop ´osito particular ou focado em resolver certos proble-mas. Portanto, este sistema certamente n˜ao seria implementado como ”omnisciente”(que

2.3. Ontologias para a representac¸˜ao de contexto

sabe tudo), mas abrangendo apenas os aspetos necess´arios. Al´em disso, as diferenc¸as resi-dem no grau de sensibilizac¸˜ao, que pode ser expresso como ”n´ıveis”. Para cada aplicac¸˜ao espec´ıfica, estes n´ıveis foram definidos de diferentes formas, de modo que o primeiro ob-jetivo ´e obter uma vis˜ao geral e, em seguida, possivelmente, encontrar semelhanc¸as para conseguir uma classificac¸˜ao comum para n´ıveis ´uteis.

N´ıveis de sensibilidade ao contexto

Os diferentes modelos utilizados para expressar contexto, sensibilidade ao contexto (con-text awareness), podem ser agrupados em trˆes n´ıveis: sens´ıveis `a localizac¸˜ao, n´ıvel m´edio de consciˆencia e semˆantico. Um estudo [30] sobre a hist ´oria dos sistemas sens´ıveis ao

con-texto mostra o que acontece para se representar um n´ıvel. O primeiro n´ıvel ´e fornecido meramente de acordo com a localizac¸˜ao do utilizador. No segundo n´ıvel, mais tipos de informac¸ ˜oes de contexto s˜ao utilizados para permitir que os sistemas possuam mais conhe-cimento sobre determinado cen´ario. No entanto, devido `a ambiguidade, apenas um n´ıvel m´edio de consciˆencia ´e atingido nestes parˆametros. Mais tarde, foram adotadas tecnologias semˆanticas comuns (por exemplo, ontologia) para representar de forma inequ´ıvoca estrutu-ras de contexto e suas relac¸ ˜oes na 3a gerac¸˜ao. Aqui, a sensibilidade ao contexto pode tirar vantagem de t´ecnicas semˆanticas para garantir a formalidade, agilidade, interoperabilidade e escalabilidade.

2.3 o n t o l o g i a s pa r a a r e p r e s e n ta c¸ ˜ao de contexto

2.3.1 Definic¸˜ao de ontologia

Uma ontologia ´e um conjunto de termos organizados com uma hierarquia associada, ou seja, de forma sistem´atica. Uma das principais utilidades de uma ontologia ´e poder ser uti-lizada como um esquema para uma base de conhecimento. Assim, uma ontologia fornece uma estrutura b´asica na qual se pode construir uma base de conhecimentos. A ontologia coloca `a disposic¸˜ao um conjunto de conceitos e termos para descrever um determinado dom´ınio.

Uma ontologia n˜ao se altera, desde que o dom´ınio que a ela representa tamb´em n˜ao se altere. [31].

As Figuras2.4e2.5, apresentam uma ontologia esquematizada com a ferramenta Prot´eg´e

2.3. Ontologias para a representac¸˜ao de contexto

2.3. Ontologias para a representac¸˜ao de contexto

Figura 2.5: Exemplo de uma ontologia representada graficamente

2.3.2 Vantagens do uso de ontologias

As ontologias possuem muitas vantagens no que diz respeito `a representac¸˜ao de conhe-cimento. A seguir, ´e apresentada uma lista com as principais vantagens da utilizac¸˜ao de ontologias:

• fornecem um vocabul´ario para representac¸˜ao do conhecimento. Esse vocabul´ario tem por detr´as um conjunto de conceitos organizados que o sustenta, evitando assim interpretac¸ ˜oes amb´ıguas desse vocabul´ario;

• permitem a partilha de conhecimento. Assim sendo, caso exista uma ontologia que modele um determinado dom´ınio de conhecimento, essa pode ser partilhada e usada por pessoas que desenvolvam aplicac¸ ˜oes dentro desse dom´ınio;

• fornece uma descric¸˜ao exata do conhecimento. ´E diferente da linguagem natural em que as palavras podem ter uma semˆantica totalmente diferente tendo em conta o seu contexto. A ontologia por ser escrita em linguagem formal, evitando a ambiguidade entre palavras;

2.3. Ontologias para a representac¸˜ao de contexto

• ´e poss´ıvel fazer o mapeamento da linguagem da ontologia sem ser necess´ario alterar a estrutura da ontologia, podendo esta ser expressa em v´arias l´ınguas;

• ´e poss´ıvel expandir o uso de uma ontologia gen´erica de forma a que ela seja adap-tada a um dom´ınio espec´ıfico, por exemplo, ´e poss´ıvel utilizar uma ontologia sobre modalidades e expandir para uma ontologia sobre futebol.

2.3.3 Como ´e constru´ıda uma ontologia

A criac¸˜ao de uma ontologia ´e um processo iterativo que ´e baseado em seis fases:

• Identificac¸˜ao do dom´ınio e especificac¸˜ao de requisitos: Esta ´e a primeira atividade realizada na construc¸˜ao de ontologias em que o principal objetivo ´e identificar conhe-cimento da ontologia, ou seja, quais os objetivos e utilidade da ontologia, por forma a sintetizar o que interessa para a ontologia e o que n˜ao interessa. Ap ´os definir a competˆencia, devem ser especificados os requisitos da ontologia. Essa especificac¸˜ao inclui a descric¸˜ao do dom´ınio e quais os usos da ontologia, isto ´e, a definic¸˜ao das quest ˜oes que a ontologia deve ser capaz de responder (perguntas de competˆencia). Estas quest ˜oes permitem justificar a existˆencia da ontologia, assim como futuramente avaliar se a ontologia responde aos prop ´ositos definidos.

• Captura da Ontologia: Esta ´e a fase mais importante cujo o objetivo ´e identificar o conjunto de elementos de um dom´ınio que podem ser representados numa ontologia, com base nas perguntas de competˆencia.

• Formalizac¸˜ao da Ontologia: A formalizac¸˜ao da ontologia corresponde a especificar a ontologia numa determinada linguagem. Uma ontologia pode ser representada atrav´es de uma linguagem natural (n˜ao formal). No entanto, a representac¸˜ao formal ´e considerada a mais apropriada na maioria dos casos por forma a evitar ambiguidades. • Integrac¸˜ao com Ontologias Existentes: Durante o desenvolvimento da ontologia pode surgir a necessidade de incorporar uma ontologia que est´a relacionada com um determinado conceito pretendendo aproveitar especificac¸ ˜oes previamente estabe-lecidas.

• Avaliac¸˜ao: Avaliar uma ontologia significa verificar se a mesma satisfaz os requi-sitos definidos na sua construc¸˜ao. A avaliac¸˜ao de uma ontologia deve realizar-se em simultˆaneo com as fases de captura e formalizac¸˜ao. Nesta fase devem existir crit´erios para orientar o desenvolvimento e a avaliac¸˜ao da qualidade das ontologias constru´ıdas. As perguntas de competˆencia devem ser utilizadas para avaliac¸˜ao dos axiomas.

2.4. Frameworks baseadas em contexto

• Documentac¸˜ao: Todo o desenvolvimento da ontologia deve ser documentado. Esta fase inclui os prop ´ositos, requisitos e cen´arios de motivac¸˜ao, as descric¸ ˜oes textuais dos conceitos, a ontologia formal e os crit´erios de avaliac¸˜ao adotados na ontologia.

2.3.4 Como ´e organizada uma ontologia

Ao construir uma ontologia deve ser definido inicialmente o dom´ınio e a finalidade da ontologia [32].

A estrutura de uma ontologia possui alguns elementos b´asicos que s˜ao:

• Classes: s˜ao normalmente estruturadas de forma hier´arquica e representam algum tipo de relac¸˜ao entre a ontologia e o dom´ınio definido.

• Relac¸ ˜oes: representam a relac¸˜ao/interac¸˜ao entre as classes que definem o dom´ınio da ontologia.

• Axiomas: s˜ao utilizados para delinear decis ˜oes consideradas sempre verdadeiras. • Instˆancias: s˜ao utilizadas para representar elementos espec´ıficos que pertencem ao

dom´ınio da ontologia.

• Func¸ ˜oes: s˜ao eventos que podem ocorrer no contexto da ontologia.

2.4 f r a m e w o r k s b a s e a d a s e m c o n t e x t o

Nesta Secc¸˜ao ser˜ao apresentadas v´arias arquiteturas baseadas em contexto e respetivas ca-rater´ısticas, por forma a compreendermos como estas funcionam e quais os seus requisitos.

2.4.1 Definic¸˜ao de Framework

Uma framework estabelece um conjunto de diretivas e funcionalidades para a resoluc¸˜ao de um problema. Em particular, fornece uma base (normalmente constitu´ıda por um conjunto de bibliotecas) sobre a qual os programadores de software podem construir programas ou soluc¸ ˜oes para uma plataforma espec´ıfica.

´E comum uma framework encapsular os comportamentos da API em implementac¸˜oes mais complexas permitindo o seu uso de forma mais flex´ıvel, atrav´es de extens ˜oes, confi-gurac¸ ˜oes e invers ˜oes de controlo.

2.4. Frameworks baseadas em contexto

2.4.2 Ektara

A Ektara Gopichand ´e uma framework vocacionada para a construc¸˜ao de aplicac¸ ˜oes na ´area da computac¸˜ao ub´ıqua e wearable (UWC). Nesta framework, o contexto ´e armazenado em v´arios servidores. O armazenamento do contexto n˜ao estar concentrado em apenas um local, permite poupar recursos na altura em que se readquire o contexto para um deter-minada aplicac¸˜ao baseada em contexto. Em termos de fontes de contexto, esta framework utiliza essencialmente sensores de v´arios tipos que captam o contexto. Posteriormente, esse contexto ´e analisado num motor de inferˆencia de contexto.

A gest˜ao da interac¸˜ao entre o utilizador e aplicac¸˜ao fica ao cargo de um gestor (agente) de interac¸˜ao de contexto. Em termos de seguranc¸a, o contexto armazenado nos servidores est´a criptografado e ´e garantido pelo utilizador quem ´e que consegue descodificar esse contexto atrav´es de uma chave p ´ublica disponibilizada [33].

2.4.3 Stick-e Notes

O stick-e note ´e uma framework que visa apoiar os utilizadores na criac¸˜ao de sistemas sens´ıveis ao contexto. O desenvolvimento de um servic¸o baseado nesta framework passa pela criac¸˜ao de um documento com v´arias anotac¸ ˜oes denominadas etiquetas.

Em termos de funcionamento do stick-e note, o utilizador indica o contexto que pretende utilizar e ´e disponibilizado uma linguagem muito semelhante ao HTML (HyperText Mar-kup Language) em que utilizador pode escrever regras para especificar as ac¸ ˜oes a executar quando determinado acontecimento descrito no contexto se verifica. Por exemplo, numa aplicac¸˜ao de monitorizac¸˜ao de uma casa, temos uma regra “Quando o ar condicionado est´a ligado”, o sistema deve indicar informac¸ ˜oes do tipo “Manter as portas fechadas”. Um sistema baseado no stick-e note, ´e no entanto muito limitado, pois ´e vocacionado para dar apoio a utilizadores aprendizes na ´area da inform´atica.

Em termos gerais, o stick -e note ´e muito limitado na escrita de regras e n˜ao suporta a constante mudanc¸a dos dados de contexto. O funcionamento atrav´es de regras que verifi-quem determinado comportamento origina limitac¸ ˜oes ao n´ıvel da escabilidade da aplicac¸˜ao [34] [2].

2.4.4 Sulawesi

O Sulawesi ´e uma framework vocacionada para a interac¸˜ao entre o utilizador e os servic¸os existentes no computador. Esta framework utiliza sensores de v´arios tipos para adquirir con-texto. Em termos de funcionamento, o Sulawesi tem na sua estrutura agentes que fazem a gest˜ao de dados inseridos pelo utilizador via teclado e os dados apresentados no

compu-2.4. Frameworks baseadas em contexto

tador, que ´e o resultado da interac¸˜ao. Nesta framework existe um mecanismo que verifica o ambiente em que o utilizador se encontra, por forma a decidir qual a melhor forma do utilizador receber as informac¸ ˜oes. As informac¸ ˜oes tanto podem ser apresentadas visual-mente no computador (ambiente gr´afico), como podem ser produzidas atrav´es de voz. A incorporac¸˜ao de agentes para aquisic¸˜ao de conhecimento durante o tempo de execuc¸˜ao ´e limitada.

Esta framework ´e limitada ao n´ıvel de aquisic¸˜ao de contexto, inferˆencia de contexto e armazenamento de contexto [35][2].

2.4.5 CALAIS

A Calais ´e uma framework orientada para monitorizar ambientes interiores, como por exem-plo uma casa. Esta framework baseia-se essencialmente na localizac¸˜ao de pessoas e objetos. Para isso, s˜ao utilizados diversos dispositivos tais como, sensores de movimento, cˆamaras de videovigilˆancia, monitores de computadores, etc. Estes dispositivos obtˆem informac¸ ˜oes (aquisic¸˜ao de contexto) que s˜ao utilizadas para identificar a localizac¸˜ao de um determi-nado objeto ou pessoa, quais as principais movimentac¸ ˜oes de uma determinada pessoa e identificar qual o objeto mais pr ´oximo.

Existe uma interface nesta framework que tem como func¸˜ao ocultar as informac¸ ˜oes recebi-das pelos dispositivos de aquisic¸˜ao de contexto. Esta framework n˜ao disponibiliza o armaze-namento e interpretac¸˜ao do contexto, o que possibilita os programadores personalizar a sua base de conhecimento. Esta framework permite aos utilizadores monitorizar uma sequencia de acontecimento por forma a serem avisados se determinada sequˆencia se verificou.

A framework Calais possui mecanismos muito eficientes ao n´ıvel da aquisic¸˜ao e an´alise de contexto para os programadores [36][2].

2.4.6 Schilit’s System Architecture

A Schilit’s System Architecture ´e a uma framework orientada para a computac¸˜ao m ´ovel ba-seada em contexto. Esta arquitetura foi desenvolvida com base numa pesquisa feita por Schilit e o grupo Xerox Parc. A framework Schilit foi constru´ıda com o intuito de monitorizar localizac¸ ˜oes de pessoas e dispositivos, assim como os seus comportamentos com a possi-bilidade de informar o utilizador sobre determinada alterac¸˜ao atrav´es de notificac¸ ˜oes. Os elementos principais desta framework s˜ao os agentes que fazem a monitorizac¸˜ao e gest˜ao dos dispositivos. Estes contˆem as informac¸ ˜oes personalizadas dos utilizadores e os esquemas das localizac¸ ˜oes dos dispositivos e das pessoas.

Em termos de aquisic¸˜ao de contexto, esta framework disponibiliza agentes que se adaptam aos sensores que cada utilizador e dispositivo utiliza. Esta framework ´e limitada ao n´ıvel de

2.4. Frameworks baseadas em contexto

aquisic¸˜ao de contexto, uma vez que essa aquisic¸˜ao ´e feita apenas pelos sensores j´a imple-mentados e geridos pelos agentes, o que dificulta a inserc¸˜ao de mais contexto. Ao n´ıvel da inferˆencia de contexto, esta n˜ao ´e suportada.

A framework n˜ao suporta o armazenamento de contexto o que contribui para a inviabili-zac¸˜ao de utilizar contexto que j´a foi processado [20][2].

A Figura2.6 apresenta de forma sucinta as vantagens e desvantagens de frameworks

ba-seadas em contexto que foram anteriormente descritas e outras que ser˜ao apresentadas na Secc¸˜ao 2.6.

2.5. Arquiteturas de middleware baseadas em contexto

2.5 a r q u i t e t u r a s d e m i d d l e wa r e b a s e a d a s e m c o n t e x t o

Nesta secc¸˜ao s˜ao apresentadas v´arias arquiteturas de middleware na ´area do context-aware e as respetivas caracter´ısticas. ´E dada especial relevˆancia a arquiteturas de middleware que est˜ao mais vocacionados para a ´area das redes.

2.5.1 Definic¸˜ao de Middleware

O middleware ´e um conceito que denomina um software que agrega servic¸os ou programas distintos, que muitas vezes j´a existem e s˜ao complexos. Um middleware encontra-se entre a aplicac¸˜ao que um determinado utilizador est´a a ver e as fontes de informac¸ ˜oes.

Este elemento de software tem como func¸˜ao intermediar a interac¸˜ao entre a aplicac¸˜ao final e as fontes de informac¸˜ao. De seguida, ´e apresentada uma figura onde podemos ver onde atua este tipo de software.

2.5. Arquiteturas de middleware baseadas em contexto

2.5.2 Representac¸˜ao gen´erica de um middleware

Figura 2.8: Arquitetura gen´erica de um middleware [4]

A figura acima apresentada mostra que existem 4 blocos essenciais que s˜ao: sistemas de identificac¸˜ao de localizac¸˜ao; sistemas de informac¸˜ao de localizac¸˜ao consciente; sistemas espec´ıficos das aplicac¸ ˜oes; e a arquitetura gen´erica de um middleware.

2.5.3 Acoms+

O Acoms+ ´e uma arquitetura de middleware baseada em contexto orientada para a gest˜ao de servic¸os de detec¸˜ao. Esta arquitetura permite a gest˜ao dos dados de contexto autom´atico para computac¸˜ao pervasiva. Nesta arquitetura, o contexto ´e obtido atrav´es de sensores que permitem a integrac¸˜ao de informac¸ ˜oes de qualidade de contexto, funcionando como indicadores do sistema. O Acoms+ cont´em um m ´odulo que faz o pr´e–processamento do contexto que ´e obtido pelos v´arios sensores. Posteriormente, a adaptac¸˜ao do contexto a cada ambiente para o qual foi escolhido ´e feita com a ajuda de axiomas adequados `a situac¸˜ao em causa.

O Acoms+ tem como uma das suas grandes vantagens, possibilitar configurac¸˜ao au-tom´atica de sensores e a substituic¸˜ao desses em tempo de execuc¸˜ao. A substituic¸˜ao de sensores em tempo real facilita a aquisic¸˜ao de contexto tolerante a falhas em aplicac¸ ˜oes [4][37].

2.5. Arquiteturas de middleware baseadas em contexto

Figura 2.9: Arquitetura de um Sistema baseado em contexto ACOMS [5]

2.5.4 Carisma

O Carisma ´e uma arquitetura de middleware vocacionada para aplicac¸ ˜oes m ´oveis. Os sis-temas m ´oveis caracterizam-se por serem sissis-temas muito dinˆamicos, o que faz com que a adaptac¸˜ao seja um dos pontos fulcrais desta arquitetura. O contexto que ´e adquirido ´e ar-mazenado em notac¸˜ao XML e organizado em duas classes: ativa e passiva. A classe passiva descreve ac¸ ˜oes que a arquitetura p ˜oe em pr´atica em determinado evento, atrav´es do uso de regras. Um dos problemas que pode ocorrer ´e quando dois perfis representam duas regras diferentes para a mesma situac¸˜ao. A classe ativa descreve os relacionamentos existentes en-tre os servic¸os utilizados nas aplicac¸ ˜oes. Estas informac¸ ˜oes permitem `a arquitetura Carisma enquadrar-se ao n´ıvel do ambiente em que est´a inserido e ao n´ıvel do perfil do utilizador.

O Carisma utiliza um sistema de leil˜ao para resolver os casos em que h´a conflito de regras onde, s˜ao utilizados agentes que estabelecem restric¸ ˜oes `as regras por forma a potenciar as decis ˜oes tomadas [38] [3].

2.5.5 MOCA

MOCA ´e uma arquitetura de middleware que se baseia num servic¸o dividido em v´arios m ´odulos, que utiliza as ontologias para a representac¸˜ao e gest˜ao do contexto. O m ´odulo principal ´e onde se encontra o n ´o de gest˜ao de contexto, que tem como func¸˜ao gerir o contexto de um determinado dom´ınio. Em termos de gest˜ao de contexto, os principais elementos desta arquitetura s˜ao: fornecedores de contexto,que tˆem como func¸˜ao a criac¸˜ao

2.5. Arquiteturas de middleware baseadas em contexto

ou recuperac¸˜ao de contexto obtido de outras fontes de contexto implementadas nesta ar-quitetura, com vista a serem utilizadas pelo m ´odulo de gest˜ao de dados; os utilizadores de contexto, que usam o contexto obtido e processado pelo sistema; e o servic¸o de contexto; que tem como func¸˜ao, adquirir, armazenar e transmitir as informac¸ ˜oes de contexto).

Esta arquitetura utiliza um modelo orientado para a manipulac¸˜ao de contexto, por forma a n˜ao p ˆor em causa a escalabilidade e o desempenho do sistema, como acontece no caso das ontologias. O contexto ´e representado em notac¸˜ao XML que ser´a, posteriormente, processado com o intuito de ser verificado e validado [39][3].

2.5.6 CA4IOT

CA4IOT (Context Awareness for Internet of Things) ´e uma arquitetura de middleware que permite a selec¸˜ao autom´atica de sensores tendo em conta a tarefa com que determinado utilizador se depara. Nesta arquitetura o contexto ´e obtido atrav´es de sensores e, poste-riormente esse contexto ´e processado com o intuito de inferir conhecimento. O objetivo desta arquitetura passa pelos utilizadores apresentarem o problema com que se deparam e as informac¸ ˜oes que possuam relacionadas com esse mesmo problema para que o sistema CA4IOT, atrav´es de mecanismos de tratamento e inferˆencia de contexto, consiga extrair ainda mais conhecimento que permita a resoluc¸˜ao do problema.

A arquitetura CA4IOT est´a dividida em 5 camadas, que s˜ao apresentadas na Figura2.10

[6] [1].

2.5. Arquiteturas de middleware baseadas em contexto

2.5.7 CASF

CASF ´e uma arquitetura de middleware baseada em contexto cuja principal inovac¸˜ao ´e a utilizac¸˜ao de servic¸os de web semˆantica, o que permite uma melhor e mais pormenorizada definic¸˜ao sobre determinada informac¸˜ao. Esta arquitetura utiliza principalmente sensores para adquirir o contexto.

A arquitetura CASF est´a dividida em trˆes camadas: a camada onde se encontram os sensores para aquisic¸˜ao de contexto, a camada onde est˜ao localizadas outras fontes de contexto e a camada onde est˜ao os servic¸os que processam e utilizam o contexto por forma

a formar uma base de conhecimento sobre determinado problema. A Figura2.11apresenta

a arquitetura CASF [40][1].

Figura 2.11: Arquitetura do middleware CASF[1]

2.5.8 COCAMAAL

COCAMAAL (Cloud-oriented Context-Aware Middleware in Ambient Assisted Living) ´e uma arquitetura baseada em contexto que est´a orientada para ambientes em que as pessoas necessitam de ser permanentemente monitorizadas por problemas de sa ´ude. Esta arquite-tura utiliza sensores para a aquisic¸˜ao de conhecimento. Os sensores s˜ao escolhidos tendo em conta as necessidades personalizadas do utilizador.

O sistema COCAMAAL est´a todo estruturado num sistema de nuvem, onde ´e armaze-nada a informac¸˜ao de cada utilizador. Nesse mesmo sistema de nuvem, existem agregado-res e fornecedoagregado-res de contexto que, atrav´es dos dados de cada utilizador, transformam essa informac¸˜ao em representac¸˜ao de contexto abstrata, por forma a ser poss´ıvel que todos os

2.5. Arquiteturas de middleware baseadas em contexto

servic¸os do sistema processar esse contexto. A estrutura em nuvem possui mecanismos de inferˆencia para aplicar sobre o contexto, com o objetivo de enriquecer a base de conheci-mento sobre determinado utilizador. O sistema de nuvem permite o processaconheci-mento, o ar-mazenamento e a recuperac¸˜ao de contexto. Possui tamb´em, servic¸os de gest˜ao sens´ıveis ao contexto, assim como, mecanismos de entrega de recomendac¸ ˜oes de apoio aos utilizadores que verificam se a informac¸˜ao ´e entregue corretamente e atempadamente. Posteriormente, foi criada uma extens˜ao do COCAMAAL denominada BDCAM com o intuito se de adaptar

`a descoberta de conhecimento [41][1].

2.5.9 SECOMAN

SECOMAN (Semantic Web-based Context Management) ´e uma arquitetura de middleware baseada em contexto que est´a vocacionada para a manutenc¸˜ao da privacidade dos da-dos existentes em aplicac¸ ˜oes inteligentes e sens´ıveis ao contexto. Esta arquitetura uti-liza um modelo composto por ontologias e regras semˆanticas definidas pelo utiuti-lizador para a representac¸˜ao e descric¸˜ao do contexto, assim como, para adquirir conhecimento da informac¸˜ao j´a obtida. O SECOMAN utiliza inferˆencia para a obtenc¸˜ao de conhecimento sobre determinado dom´ınio.

A arquitetura SECOMAN est´a estruturada em v´arias camadas: a camada aplicacional, a camada de gest˜ao de contexto e a camada onde se encontram sistemas de localizac¸˜ao e outros servic¸os. De salientar, que na camada de gest˜ao de contexto existem v´arios m ´odulos que processam o contexto, onde se situam nomeadamente o reposit ´orio de ontologias e o sistema de inferˆencia de contexto. A Figura 2.12apresenta a arquitetura SECOMAN [7][1].

2.6. Outras iniciativas

Figura 2.12: Arquitetura do middleware SECOMAN [7]

2.6 o u t r a s i n i c i at i va s

Nesta secc¸˜ao ser˜ao apresentados outros exemplos de arquiteturas de middleware e framework que resultaram de projetos desenvolvidos na ´area do context awareness.

2.6.1 Context Toolkit

Context Toolkit ´e uma framework que visa apoiar o desenvolvimento de aplicac¸ ˜oes baseadas em contexto. Esta framework ´e basicamente constitu´ıda por widgets que lidam com o con-texto e que permitem a interac¸˜ao entre o utilizador e as aplicac¸ ˜oes. A aquisic¸˜ao de concon-texto

´e feita atrav´es de sensores, sendo estes encapsulados em widgets. Existe outro tipo de widgets denominados “interpreters” que tˆem como func¸˜ao aprofundar o conhecimento a partir do contexto existente. Existe um m ´odulo designado por “aggregator” cuja func¸˜ao ´e reunir todas as informac¸ ˜oes de contexto que est˜ao relacionadas entre si e de forma coerente, e armazen´a-las num local disponibilizado no software. Num determinado momento, se determinadas condic¸ ˜oes s˜ao verificadas, um componente denominado “service” executa uma ac¸˜ao que est´a definida para aquelas condic¸ ˜oes. Nesta framework existe um m ´odulo designado por “discoverer” que monitoriza todo o sistema, por forma a saber quais os componentes que est˜ao ativos. A framework Context Toolkit permite o armazenamento de contexto, a utilizac¸˜ao de uma informac¸˜ao de contexto por m ´ultiplas aplicac¸ ˜oes e a inferˆencia de mais informac¸ ˜oes

2.6. Outras iniciativas

de contexto atrav´es de m ´ultiplas fontes de contexto. A Figura 2.13apresenta os principais

componentes desta framework [42][8].

Figura 2.13: Exemplo de configurac¸˜ao dos componentes do ContextToolkit [8]

2.6.2 Aura

Aura ´e uma arquitetura de middleware vocacionada para a computac¸˜ao ub´ıqua. Esta arquite-tura tem como objetivo executar em v´arios dispositivos tarefas que os utilizadores utilizam no quotidiano, por forma a poder monitorizar essas mesmas tarefas nos v´arios dispositivos. Uma das virtudes desta arquitetura ´e que o utilizador pode estar a trabalhar numa deter-minada tarefa e mudar de local (ambiente), que n˜ao p ˜oem em causa o trabalho que est´a a realizar.

Na arquitetura Aura existe um agente denominado gestor de tarefas que se ocupa com as v´arias mudanc¸as que existem com os ambientes, as tarefas, as pessoas e o contexto.

A linguagem XML ´e utilizada nesta arquitetura para criac¸˜ao de esquemas de marcac¸˜ao, que s˜ao utilizados para descrever servic¸os. Nesta arquitetura a aquisic¸˜ao de contexto e a

manipulac¸˜ao de contexto s˜ao efetuados em diferentes componentes. A Figura 2.14

apre-senta os principais componentes desta arquitetura [43][3].

2.6. Outras iniciativas

2.6.3 COBRA

COBRA (Context Broker Architecture) ´e uma arquitetura baseada em contexto vocacionada para ambientes inteligentes, como por exemplo um escrit ´orio. Esta arquitetura baseia-se em agentes denominados “brokers”. Estes agentes tˆem como func¸ ˜oes: a aquisic¸˜ao de contexto, armazenar as informac¸ ˜oes de contexto, inferir contexto atrav´es do motor de inferˆencia sobre as informac¸ ˜oes de contexto armazenadas e administrar as informac¸ ˜oes de contexto, por forma a decidir quem tem acesso e a que dados.

A arquitetura COBRA permite que v´arios agentes operem sobre a mesma informac¸˜ao de contexto [44] [3].

2.6.4 Gaia

Gaia ´e uma arquitetura de middleware orientada para a monitorizac¸˜ao de dispositivos de software num determinado espac¸o f´ısico. A aquisic¸˜ao de contexto nesta arquitetura ´e feita atrav´es de sensores ou de outras fontes de dados. As informac¸ ˜oes de contexto s˜ao repre-sentadas atrav´es de ontologias. A arquitetura Gaia integra um servic¸o de inferˆencia de contexto que ´e baseado em regras. Esta arquitetura cont´em um m ´odulo que tem como func¸˜ao guardar todas as caracter´ısticas sobre um determinado local, para que as aplicac¸ ˜oes ao serem executadas num determinado ambiente que esteja caraterizado nesse m ´odulo, possam aceder a informac¸ ˜oes sobre o local com o objetivo de se adaptarem a esse mesmo local.

A arquitetura GAIA possui servic¸os para detetar a presenc¸a e o estado de dispositi-vos e pessoas num determinado ambiente. Os dados s˜ao organizados tendo em conta as informac¸ ˜oes de contexto, ou seja, os dados ao serem adquiridos s˜ao classificados quanto ao tipo de entidade que est˜ao relacionados [45][3].

2.6.5 SOCAM

SOCAM (Service Oriented Context-Aware Middleware) ´e uma arquitetura de middleware que utiliza ontologias para representar o contexto. Nesta arquitetura as ontologias podem representar conceitos espec´ıficos de um determinado dom´ınio ou conceitos mais gerais.

A linguagem OWL (Web Ontology Language) ´e utilizada para a criac¸˜ao das ontologias. A aquisic¸˜ao de contexto numa arquitetura SOCAM ´e feita atrav´es de sensores ou de outras fontes de contexto que sejam internas ou externas ao sistema. Posteriormente, os dados adquiridos s˜ao representados numa ontologia atrav´es da linguagem OWL. Seguidamente, s˜ao enviados a um motor de inferˆencia que, por sua vez, armazena os dados que foram processados numa base de conhecimento. Esta base de conhecimento ´e armazenada

junta-2.6. Outras iniciativas

mente com a ontologia numa base de dados tendo associado a si um dom´ınio. A Figura

2.15apresenta os principais componentes da arquitetura SOCAM [9] [3].

Figura 2.15: Arquitetura SOCAM [9]

2.6.6 HCOM

A arquitetura HCOM (Hybrid Context Management) utiliza um comportamento h´ıbrido no modo de tratar o contexto, onde esse ´e representado em ontologias e diagramas relacionais. A estrutura desta arquitetura est´a dividida em 5 camadas: camada de aquisic¸˜ao, camada de pr´e-processamento, camada de armazenamento, camada de gest˜ao de dados e a camada de utilizac¸˜ao.

O contexto adquirido ´e representado em ontologias, com vista a serem armazenadas num reposit ´orio. Existe um m ´odulo cuja func¸˜ao ´e reunir os dados sobre determinado contexto que envia para o motor de inferˆencia, com vista a obter mais conhecimento a partir do contexto existente. O gestor de colaborac¸˜ao determina se as informac¸ ˜oes de contexto s˜ao ou n˜ao suficientes para que o motor de inferˆencia possa depreender mais conhecimento dos dados existentes. Existe tamb´em um m ´odulo que cont´em um reposit ´orio de regras que devem ou n˜ao ser executadas quando determinada situac¸˜ao se verifica por forma a que o sistema se adapte ao contexto [46] [3].

2.6.7 Campus

CAMPUS ´e uma arquitetura de middleware orientada para o desenvolvimento de aplicac¸ ˜oes sens´ıveis ao contexto. Nesta arquitetura as fontes de contexto s˜ao obtidas atrav´es de bases de dados ou sensores.

A arquitetura CAMPUS permite tamb´em a aquisic¸˜ao de contexto atrav´es da rede onde se encontra implementada, por meio de sensores e bases de dados. Esta arquitetura est´a

2.6. Outras iniciativas

estruturada em trˆes n´ıveis: o n´ıvel de conhecimento, n´ıvel de decis˜ao e o n´ıvel de progra-mac¸˜ao. O n´ıvel de programac¸˜ao tem como func¸˜ao criar aplicac¸ ˜oes sens´ıveis ao contexto tendo em conta indicac¸ ˜oes dadas a partir do n´ıvel de decis˜ao. O n´ıvel de conhecimento tem como objetivo atrav´es dos dados de contexto adquiridos extrair conhecimento, que depois ser´a transmitido ao n´ıvel de decis˜ao para ajudar nas decis ˜oes de qual a melhor alternativa

para uma determinada tarefa. A Figura 2.16 apresenta os principais componentes desta

arquitetura. [10] [1].

Figura 2.16: Arquitetura CAMPUS [10]

2.6.8 CAMPH

CAMPH (Context-Aware Middleware for Pervasive Homecare) ´e uma arquitetura de mid-dleware orientada para ambientes onde haja cuidados de sa ´ude, ou seja, a arquitetura CAMPH possibilita a monitorizac¸˜ao de pacientes, assim como os locais onde estes pacientes se encontrem. A aquisic¸˜ao de contexto nesta arquitetura ´e feita atrav´es de consultas basea-das em SQL que, com a ajuda de sensores, obt´em as informac¸ ˜oes requisitabasea-das na consulta. As fontes de contexto s˜ao classificadas e posteriormente organizadas tendo em conta ao dom´ınio a que pertencem.

A principal virtude desta arquitetura ´e a possibilidade de os servic¸os poderem interagir com as fontes de contexto independentemente do local onde se encontram. Os servic¸os de gest˜ao de contexto s˜ao organizados em duas perspetivas: uma perspetiva tendo em conta o local e a outra ´e uma perspetiva geral, ou seja, independente da localizac¸˜ao.

A arquitetura CAMPH est´a estruturada em v´arias camadas que est˜ao apresentadas na Figura 2.17[5].

2.7. Comparac¸˜ao de arquiteturas de middleware baseadas em contexto

Figura 2.17: Arquitetura e implementac¸˜ao do modelo CAMPH [5]

2.7 c o m pa r a c¸ ˜ao de arquiteturas de middleware baseadas em contexto

Existe uma grande variedade de arquiteturas de middleware context-aware. Posteriormente, ser´a apresentada uma tabela comparativa dessas arquiteturas, algumas delas j´a descritas neste documento, tendo em considerac¸˜ao: arquitetura do sistema, modelac¸˜ao do contexto, racioc´ınio do contexto, linguagem de consulta do contexto, armazenamento do contexto, seguranc¸a, privacidade e qualidade do contexto.

2.8. Sum´ario

Figura 2.18: Classificac¸˜ao de Sistemas de middleware Context-Aware [1]

2.8 s u m´ario

Neste cap´ıtulo foram abordados temas que est˜ao relacionados com o tema da dissertac¸˜ao. Este cap´ıtulo cont´em informac¸˜ao sobre o que ´e amostragem e suas vantagens, e apresenta as t´ecnicas de amostragem e respetiva definic¸˜ao.

Outro tema abordado ´e a monitorizac¸˜ao, o papel essencial da monitorizac¸˜ao na gest˜ao de redes e os tipos de monitorizac¸˜ao utilizados.

As ontologias s˜ao outro tema que ´e abordado, assim como as vantagens das ontologias na representac¸˜ao de contexto.

Finalmente, ´e apresentada uma comparac¸˜ao entre as v´arias frameworks e arquiteturas de middleware baseados em contexto que foram estudados apresentando as vantagens e desvantagens de cada uma deles.

3

D E F I N I C¸ ˜A O D E U M A A R Q U I T E T U R A B A S E A D A E M C O N T E X T O

Neste cap´ıtulo ser´a apresentada a arquitetura de monitorizac¸˜ao que se pretende desenvol-ver neste projeto, assim como em que ´area dessa mesma arquitetura se vai desenvoldesenvol-ver o sistema ontol ´ogico.

3.1 a r q u i t e t u r a d e m e d i c¸ ˜ao baseada em amostragem

Nesta Secc¸˜ao ser´a apresentada uma arquitetura de monitorizac¸˜ao baseada em amostragem que relaciona as tarefas de monitorizac¸˜ao (ex: Accounting) que s˜ao configuradas num sis-tema de monitorizac¸˜ao com as v´arias t´ecnicas de amostragem que se quer implementar

nos pontos de medic¸˜ao [17]. Nesta arquitetura pretende-se, posteriormente, introduzir e

especificar a noc¸˜ao de contexto.

Na Figura 3.1 est´a representada essa arquitetura que est´a dividida em trˆes camadas: a

3.1. Arquitetura de medic¸˜ao baseada em amostragem

Figura 3.1: Descric¸˜ao da arquitetura[11]

3.1.1 Descric¸˜ao do funcionamento

No plano de dados, o tr´afego ´e coletado das interfaces de rede (por exemplo, routers) ado-tando as regras de amostragem definidas no plano de controlo. Os pacotes coletados s˜ao transferidos ao plano de controlo para serem processados.

O plano de controlo permite uma selec¸˜ao e configurac¸˜ao adapt´avel das t´ecnicas de amos-tragem. No plano de controlo, os pacotes amostrados recebidos a partir do plano de dados s˜ao processados e os conte ´udos dos campos relevantes s˜ao extra´ıdos tendo em conta a tarefa de rede e as necessidades de medic¸˜ao. Estes valores s˜ao ent˜ao agregados (tanto em tempo e espac¸o) e exportados seguindo as especificac¸ ˜oes IPFIX (Internet Protocol Flow Information Export) IETF (Internet Engineering Task Force).

O plano de gest˜ao inclui tarefas implantadas diretamente nos pontos de medic¸˜ao ou em entidades de gest˜ao externas. Com base nos requisitos de cada tarefa da rede, as necessidades de medic¸˜ao s˜ao identificadas, a t´ecnica de amostragem mais apropriada ´e designada, e um ou mais pontos de medic¸˜ao s˜ao selecionados para participar no processo de amostragem. Isto tamb´em envolve a identificac¸˜ao de um modelo de informac¸˜ao capaz de definir objetos geridos na rede independentemente das implementac¸ ˜oes ou protocolos espec´ıficos em uso. O plano de gest˜ao tamb´em ´e respons´avel por estimar as m´etricas

3.2. Arquitetura de monitorizac¸˜ao baseada em contexto

relevantes usando relat ´orios de dados enviados pelo plano de controlo. O processamento requerido pode envolver resultados de medic¸ ˜oes simples ou multiponto.

As func¸ ˜oes que comp ˜oem o plano de gest˜ao podem ser implantadas diretamente no ponto de medic¸˜ao, compartilhando o mesmo dispositivo e recursos, ou em uma entidade externa, respons´avel por coordenar um ou mais pontos de medic¸˜ao de acordo com as necessidades de medic¸˜ao e restric¸ ˜oes.

3.2 a r q u i t e t u r a d e m o n i t o r i z a c¸ ˜ao baseada em contexto

A presente proposta de trabalho tem como objetivo principal a definic¸˜ao de um modelo de monitorizac¸˜ao de servic¸os baseado em contexto. Ou seja, pretende-se desenvolver um sistema ontol ´ogico usando uma tecnologia selecionada incluindo um middleware de contexto e um processador num quadro de monitorizac¸˜ao aut ´onomo. Com o desenvolvimento desta arquitetura tenciona-se criar um mecanismo de contexto (middleware de contexto) que ao selecionar uma tarefa de monitorizac¸˜ao, possa escolher a t´ecnica que melhor se aplica `a tarefa definida.

A Figura3.2ilustra a arquitetura que se pretende desenvolver com este trabalho.